글로벌 칼럼 | AI 특이점은 이미 도래했다

메아 쿨파(Mea culpa)! 필자의 글(블로그ㅣAI에게는 여전히 인간의 전문성이 필요하다)은 틀렸다. 인공지능 특이점(artificial intelligence (AI) singularity)이 이미 현실에 도래했다. AI는 이제 먼 훗날 소프트웨어 개발에 ‘아마도’ 영향을 미칠 수 있는 무엇이 아니다. 이 상황은 현재 일어나고 있다. 바로 지금. 

물론 모든 개발자가 코드 구축 혹은 테스트를 위해 대형 언어 모델(large language models, LLM)을 활용하는 것은 아니다. 오히려 대다수는 그렇지 않다. 그러나 활용하는 이들의 경우, AI가 소프트웨어 개발 방법을 극적으로 변화시키고 있다. 챗GPT와 같은 LLM을 활용해 자신 혹은 개발팀의 생산성을 향상시키는 방법을 파악하기 위해 이들이 이러한 도구를 활용하는 방법을 살펴볼 필요가 있다. 
 

AI가 견인하는 꿈

LLM-인핸스드(LLM-enhanced) 개발의 적극적인 옹호자 중 한 명은 데이터셋 오픈소스 프로젝트(Datasette open source project)의 사이먼 윌리슨이다. 윌리슨은 “AI를 통해 나의 프로젝트에 더욱 야심을 갖고 임할 수 있다”라고 언급한 바 있다. 

어떻게 그렇다는 것일까? 그는 “챗GPT(그리고 깃허브 코파일럿) 덕분에 ‘무엇을 파악하는’ 시간을 상당히 절약할 수 있었다. 배시(Bash)에서 루프를 작성하는 것부터 자바스크립트에서 도메인 간 CORS 요청 방법을 기억하는 것에 이르는 모든 것을 위해 더 이상 검색할 필요가 없으며, 프롬프트를 실행하면 80%의 경우 정답을 얻는다”라고 설명했다.

윌리엄스가 말하는 ‘파악’하는 프로세스의 극적인 단축은, 저수준의 잡무보다 더 높은 가치를 지닌 개발에 집중할 수 있음을 의미한다. LLM이 생성할 수 있는 불완전한 코드나 명백한 거짓 정보를 우려하는 이들에게 윌리엄스는 걱정할 필요가 없다고 팟캐스트에서 단언했다. 

물론 우려가 터무니없는 것은 아니다. 그러나 사소하지 않은 문제임과 별개로 그는 “생산성과 맡은 프로젝트 종류의 청사진 측면에서 엄청난 도약을 할 수 있을 것이다. 결함 및 거짓말이 있을 수 있고 문제가 발생할 수 있다는 점과 생산성 또한 크게 향상시킬 수 있다는 점 모두를 수용할 수 있다면 말이다”라고 말했다.

실용적인 조언이 있다면 LLM을 다루고 필요한 것으로 만드는 방법을 학습하는 것이다. 윌리엄스는 “가치를 최대한 이끌어내고 무지한 사용자를 위해 설정된 많은 함정을 피하기 위해서는 LLM과 함께 시간을 보내 이들이 어떻게 작동하는지, 어떤 기능이 있는지, 어디서 오류가 날 가능성이 가장 높은 지에 대한 정확한 멘탈 모델(mental model)을 구축해야 한다”라고 강조했다. 

예를 들어, 챗GPT와 같은 LLM은 코드를 생성하는 데 유용할 수 있으나, 코드(LLM이 생성한 코드를 포함한) 테스트에 더욱 유용할 수 있다. 이는 깃허브 개발자인 자나 도건이 주장해온 바다. 다시 언급하지만, 핵심은 자신의 작업을 해달라고 단순히 요청하고 작업이 완료되는 동안 해변에서 기다리는 것이 아니라 LLM을 활용하는 것이다. LLM은 개발자의 작업을 도울 수 있을 뿐 특정 작업에서 개발자를 대신할 수는 없다. 
 

‘월드 와이드 웹 이후 가장 큰 사건’

소스그래프(Sourcegraph) 개발자인 스티브의 표현에 따르면 “LLM은 소셜, 모바일 혹은 클라우드 이후 가장 큰 변화일 뿐만 아니라 월드 와이드 웹 이후 가장 큰 사건이다. 또한 코딩 측면에서 LLM은 IDE 및 스택 오버플로(Stack Overflow) 이후 가장 큰 사건이며, 이 둘 모두를 능가할 수도 있다.”  

에게는 뛰어난 개발자다. 따라서 그가 “아직 엄청난 흥분을 느끼지 못하고 있고 우려하고 있지 않는가? 다시 생각해봐야 한다”라고 언급한 점을 비중 있게 수용할 필요가 있다. LLM을 진지하게 받아들이고 이를 자신과 자신의 회사에 유용하게 활용할 수 있는 방법을 파악해야 할 때다.   

에게의 경우, LLM 및 소프트웨어와 관련해 큰 우려 사항 중 하나는 그리 유의미하지 않다. 필자조차도 LLM에서 생성된 코드가 얼마나 불완전한지를 감안할 때 문제가 있어 보이는 코드에 대해 LLM에 의존하는 개발자들이 책임을 져야 한다고 우려를 표시해왔다. 

그러나 이는 어리석은 걱정이라고 에게는 이야기한다. 다음과 같은 그의 의견이 옳다.
 

어떤 상황에서든 절대로 코드를 신뢰할 수 없다. 소프트웨어 엔지니어링이 하나의 학문으로 존재하는 이유다. 우려를 집중하는 이들이 간과하는 부분이다. 그래서 리뷰어가 있는 것이다. 린터(linters), 디버거(debuggers), 유닛 테스트(unit tests), 통합 테스트(integration tests), 스테이징 환경(staging environments), 런북(runbooks)도 있다. 그리고 모든 운영 우수성(Operational Excellence)이 있다. 시큐리티 체커(security checkers), 컴플라이언스 스캐너(compliance scanners) 등도 있다. 

윌리슨의 주장을 따르자면, 프리스틴(pristine) 코드를 생성하는 게 핵심은 아니다. 프리스틴 코드를 만드는 데 더 많은 시간을 할애할 수 있도록 개발자의 시간을 절약하는 게 핵심이다. 도건이 언급한 것처럼, 그다지 프리스틴 상태가 아닌 코드의 모든 결함을 발견하는 테스트 및 리뷰 생성을 위해 LLM을 활용하는 게 핵심이다. 

에게는 “LLM이 80%의 완성도 및 정확도를 갖춘 코드 초안을 만들도록 하고 나머지 20%를 직접 수정하는 것이다”라고 요약했다. 이는 생산성이 5배 개선된 것이다. 누가 이를 원하지 않을까?

코드 구축 및 테스트를 LLM에게 요청하는 방법과 가능한 최고의 아웃풋을 얻기 위해 LLM을 코드 샘플과 같은 컨텍스트로 훈련시키는 방법 학습을 위한 개발자들의 경쟁은 시작됐다. “나의 일을 대신해주면서도 즉석에서 가르쳐주는 유능한 해커로 이루어진 작은 군대를 얻은 것 같다. 그저 기쁘고 신기할 따름이다”라고 하이어그라운드(Higherground)의 매트 베이트맨은 말했다. 

개발자가 플랫폼(LLM에 훈련 자료를 제공하는)을 통해 생산성을 더욱 향상시킬 수 있는 방법을 AWS 및 기타 회사들이 앞다퉈 고안하고 있는 이유다. LLM이 가능케하는 소프트웨어 개발 없는 미래는 상상하지 말자. 그 대신 지금 당장 시작하자. 

* Matt Asay는 몽고DB의 개발자 관계 업무를 담당하고 있다. 그러나 본 글은 몽고DB의 입장이 아니다.
ciokr@idg.co.kr