Offcanvas

AI / 개발자 / 머신러닝|딥러닝 / 비즈니스|경제

칼럼 | AI 코딩 도구는 대체제가 아니라 '인턴'이다

2024.05.14 Matt Asay  |  InfoWorld
AI는 형편없는 개발자를 대체할 수 없다. '뛰어난' 개발자에게만 잘 작동하기 때문이다. LLM이 내놓은 코드의 오류를 알려면 기술과 경험이 필요하다.
 
ⓒ Getty Images Bank

엔지니어인 데이비드 쇼월터는 "오늘날 AI 모델은 코더가 주어진 시간 내에 더 많은 작업을 하도록 돕는 데 탁월하다"라고 말했다. 하지만 과연 그럴까? 쇼월터는 대규모 언어 모델(LLM)을 코딩 보조 도구로서 신뢰할 수 없다는 산티아고 발다라마의 주장에 반박하며 이같이 말했다. 앞서 발다라마는 "컴퓨터가 명령에 일관되게 응답하도록 하는 프로그래밍 언어와 동일한 수준을 보장할 때까지 LLM은 대부분의 중요 애플리케이션에서 쓸모없지만 '멋진 데모'라는 비난을 계속 받을 것"이라고 주장했다. 프롬프트에 대한 응답 방식이 일관적이지 않다는 발다라마의 말이 맞다. 같은 프롬프트가 주어져도 응답은 서로 다른 LLM에서 출력된다. 그리고 쇼월터가 틀릴 가능성이 높은 이유는, AI 모델이 일반 개발자가 더 많은 코드를 생성하도록 돕는 데는 탁월할 수 있지만 이것이 사용 가능한 코드를 생성한다는 의미는 아니기 때문이다.

AI 및 소프트웨어 개발의 핵심은 문제가 어디에 있는지 파악하는 역량에 있다. 많은 개발자가 그렇게 못하며, LLM의 결과물에 지나치게 의존한다. 한 해커뉴스 평론가는 "오류가 명백하지 않은 사례에서 챗GPT에 대한 특정 사용자의 신뢰도가 얼마나 될지 궁금하다"라고 말했다. 소프트웨어 개발에 AI를 효과적으로 쓰려면 LLM에서 언제 오류가 배출되는지 알 수 있는 충분한 경험이 필요하다.

간단한 해결책은 없다
이 글을 쓰는 지금도 많은 개발자가 동의하지 않을 것이다. 위에 언급된 해커뉴스 스레드의 댓글을 읽어보라. 일반적으로 반론의 요지는 "스택 오버플로우, IDE 등에서 찾은 코드를 완전히 신뢰할 수 없듯이 당연히 LLM 결과물을 완전히 신뢰할 수 없다"로 요약된다.

여기까진 사실이다. 하지만 때로는 원하는 대로 되지 않을 수도 있다. 예를 들어 개발자가 자신의 IDE를 절대 믿어서는 안 된다고 말하긴 어렵겠지만, 우리는 그것이 '프로그램을 망치지는 않을 것'이라고 가정할 수 있다. 하지만 리스프(Lisp) 괄호를 망치지 않는 것 같은 기본적인 작업이라면 어떨까? 챗GPT는 잘못할 수 있지만 IDE는 그럴 확률이 없는가? 아닐 것이다.

스택 오버플로우 코드는 어떤가? 물론 일부 개발자는 별 생각 없이 코드를 복사하고 붙여넣기 하겠지만, 현명한 개발자라면 추천 수와 댓글을 먼저 확인할 가능성이 높다. LLM은 그런 신호를 주지 않는다. 그냥 믿거나 그렇지 않거나다. 한 개발자의 말처럼 "스택 오버플로우와 LLM 출력 값은 모두 잘못됐을 가능성이 있기 때문에 '경험이 부족한 개발자'가 작성한 것으로 간주"하는 것이 현명하다. 하지만 그는 "오류가 있더라도 그 코드가 최소한 '올바른 방향'으로는 안내할 수 있다"라고 덧붙였다.

다시 말하지만, 이를 위해서는 개발자가 스택 오버플로우 코드 샘플이나 LLM 출력 코드가 잘못됐음을 인식할 수 있을 만큼 숙련돼 있어야 한다. 또는 '리액트(React) 페이지의 빅 테이블처럼 일상적인 작업을 위한 200줄짜리 상용구 코드 덩어리' 같은 경우에만 LLM 출력 코드를 사용할 정도로 현명해야 할 수도 있다. 결국 여기서는 "믿지 말고 완료된 후에 테스트해 보라"라고 말하고 싶다.

한 개발자는 이런 코드를 "주니어 개발자나 인턴 정도로만 신뢰한다. 내가 할 줄 알고, 제대로 했는지 확인할 수 있지만 시간을 들이고 싶지 않은 작업을 맡기면 된다. 그게 바로 최적의 지점이다"라고 말했다. AI를 잘 활용할 수 있는 개발자란 AI가 잘못됐을 때를 알아차릴 만큼 똑똑하지만 그 유용성은 활용할 필요가 있는 이들일 것이다.

잘못된 사용
데이터셋의 설립자 사이먼 윌리슨의 초기 주장으로 돌아가 본다. 그는 "AI로부터 최상의 결과를 얻으려면 실제로 많은 지식과 경험이 필요하다. 많은 부분이 직관에 달려있기 때문이다"라고 언급했다. 그는 숙련된 개발자에게 다양한 LLM의 한계를 테스트해 상대적인 장단점을 파악하고, 작동하지 않는 경우에도 효과적으로 활용할 방법을 평가하라고 조언했다.

더 많은 주니어 개발자는 어떻게 해야 할까? 이들이 AI를 효과적으로 사용할 방법이 있을까? 아마존 코드위스퍼러의 제너럴 매니저이자 아마존Q의 소프트웨어 개발 디렉터인 더그 세븐은 그럴 수 있다고 말했다. 그는 코딩 어시스턴트 같은 도우미가 경험이 적은 개발자에게 유용할 것이라면서 "개발자들은 어디로 가고 있는지 파악하기 위해 필요한 제안을 받을 수 있다. 도움을 요청하기 위해 다른 사람을 방해하는 일도 줄어든다"라고 설명했다.

아마도 정답은 늘 그렇듯 "상황에 따라 다르다"일 것이다.

그리고 중요한 점은 더 많은 코드를 더 빨리 작성하는 게 소프트웨어 개발의 정답이 아니라는 것이다. 정반대다. 최고의 개발자는 코드를 작성하는 시간을 줄이고 그만큼의 시간을 해결하려는 문제와 그 문제에 접근할 최선의 방법을 생각하는 데 쓴다. 이때는 윌리슨이 제안한 것처럼 LLM이 유용할 수 있다. 그는 "챗GPT 및 깃허브 코파일럿(GitHub Copilot)을 사용하면 문제를 파악하는 시간을 크게 절약할 수 있다. 배시에서 '포 루프(for loop)'를 작성하는 것부터 자바스크립트(JavaScript)에서 도메인 간 CORS 요청을 만드는 방법을 기억하는 것까지, 더 이상 찾아볼 필요도 없이 그냥 물어보면 80%의 정답을 얻을 수 있다"라고 말했다.

앞서 언급했듯, 이 '80%'의 선을 어떻게 그을지 아는 기술은 경험에 달려 있다. 하지만 'LLM을 사용해 스칼라(Scala)로 뭔가를 작성하는 방법' 같은 일반적인 아이디어를 얻는 연습은 모두에게 도움이 될 수 있다. LLM의 결과물을 한 번만 주의 깊게 살펴볼 수 있다면 그렇다.

* Matt Asay는 몽고DB의 개발자 관계 업무를 담당하고 있다. 그러나 본 글은 몽고DB의 입장이 아니다. ciokr@idg.co.kr
 
 
CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

발행인 : 박형미 편집인 : 천신응 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.