[황승진의 AI칼럼] 코딩하는 LLM-우버 이야기
언어, 그림과 소리를 이해하고 쓸 수 있는 기능 외에도 거대언어모델(LLM)은 '코딩'이라는 놀라운 능력을 갖고 있다. 나의 스탠포드 MBA 강의 '모델링 및 최적화' 수업에서는 학생들에게 영어로 사업 상황을 설명하고 경영 결정을 하는 1 쪽짜리 연습 문제를 준다. 학생들은 수학적 모델을 세우고, 이를 해결하기 위해 파이선(Python) 코드를 작성한다. 쿨하다. 사실 코딩은 논리와 창작력을 소유한 인간만이 하는 고급 활동이라고 생각했다. 아니다. 일개 소프트웨어 조각인 LLM은 내 학생들처럼 코딩을 할 수 있다. 이 연습 문제를 영어 그대로 작은 LLM 채팅 창에 넣으면 LLM은 Python 코드를 즉석에서 제공한다. (다만 한 가지 주의할 점은 LLM은 때로는 터무니없는 실수를 할 수 있다는 것이다.) 오픈AI의 공동창업자인 앙드레 카파시는 이렇게 의도(intent)를 밝히고, LLM이 코딩하게 하고, 체크하는 방식을 '바이브 코딩(vibe coding)' 이라 부른다. 이 기능은 전문가 스케일에서도 통한다. 커서(Cursor)나 코파일럿(Copilot) 같은 소프트웨어 개발 플랫폼(IDE)을 쓰면 챗 하듯이 코드를 써 내려간다. 내 코드에 비평이나 수정도 가능하다. 대부분 기가 막히게 좋다고 말하지만, 일부는 스타일이 틀렸다고 디버그를 잘 못한다고 시비를 걸기도 한다. 또 어떤 프로그래머는 그런 방식으로 코딩한 비행기는 안 타겠다고 단언한다. 분명한 것은, 우리가 코딩 역사의 새로운 단계에 들어왔다는 점이다. 인간과 기계는 각자의 언어를 가지고 태어났다. 서로 소통하기 위해, 처음에는 어셈블리라는 기계어 비슷한 프로그램을 쓰며 인간이 기계를 흉내 냈다. 다음엔 포트란(Fortran),코볼(Cobol), 파스칼(Pascal), C, 파이선(Python)을 거쳐가며 기계와 인간이 중간에서 만나곤 했다. 이제 기계가 인간을 흉내 내, 인간어로 통일됐다. 기계어, Python, 인간어를 다 다룰 수 있는 LLM 덕택이다. Python같은 전산 언어 외에도, LLM은 SQL을 쓸 수 있다. 소위 말하는 Text-to-SQL이란 기능이다. SQL은 관계형 DB용 데이터 언어인데, 평시에는 간단하다가 때로는 매우 복잡해진다. 다음은 우버의 경험담이다. 2023년 5월 우버의 '생성 AI Hackday'에서 한 팀은 '쿼리GPT'라는 이름의 Text-to-SQL를 위한 LLM-RAG-에이전트 시스템을 개발했다. 이 시스템 개발의 동기는 쿼리 작성하는데 생산성을 높이기 위함이었다. 우버는 매달 약 120만 개의 대화형 쿼리를 처리하는데, 사용자들은 SQL 쿼리 작성에 평균적으로 10분을 소비한다. 팀은 사용자들이 SQL 대신 자연어를 사용할 수 있다면 작성 시간을 3분으로 줄일 수 있다고 추산했다. 이는 사용자의 귀중한 시간을 매달 14만 시간이나 절약할 수 있다는 것을 의미한다. 쿼리GPT의 목표는 다음과 같은 대화였다. 사용자 프롬프트: 다음 문장의 SQL을 주십시요. "지난 주 로스앤젤레스에서 운전 기사가 취소한 여행 횟수는 얼마입니까?" LLM 출력: 여기 원하는 SQL이 있습니다. "SELECT COUNT('Cancelled') FROM .. WHERE .." 우버 팀은 LLM이 Text-to-SQL을 혼자 잘 수행하리라 생각했다. 허나, 문제는 우버의 DB가 오백 개의 테이블과 수천 개의 열로 구성된 거대한 규모였다는 점이다. LLM은 주어진 SQL에 맞게 어느 테이블과 열을 불러야 할 지를 몰라서, 최종 결과의 정확도가 떨어지곤 했다. 그래서 팀은 쿼리GPT의 작동 방식을 20회 이상 개선했다. 최신 버전은 멀티에이전트 모델로, '의도(intent) 에이전트', '테이블 에이전트', '열(Column) 제거 에이전트'라는 세 LLM 에이전트가 하나의 마스터 LLM의 지휘를 받는다. 의도 에이전트는 관련된 비즈니스 도메인(예: 광고, 모빌리티, 코어 서비스 등)을 파악하기 위해 LLM을 호출한다. 이는 인간과의 대화형으로 진행하며, 사용자가 승인해야 쿼리GPT는 다음 단계로 진행한다. 테이블 에이전트도 대화형으로 쿼리에 포함될 적절한 테이블을 선택한다. 마지막 열 재거 에이전트는 쿼리와 관련 없는 열을 제거해 쿼리의 범위를 더욱 좁힌다. 이로써, 드디어 3분의 예상 응답 시간을 달성할 수 있었다. 여기서 우리는 LLM, 에이전트, 인간 에이전트, RAG가 어떻게 결합돼 엔터프라이즈 AI 시스템을 만들어내는지 볼 수 있다. 에이전트는 모두 마스터 LLM의 호출에 따르고, 각 에이전트 역시 LLM이다. 이들이 같은 LLM일 필요는 없으며, 예를 들어 하나는 챗GPT(ChatGPT)이고 다른 하나는 라마(Llama)일 수 있다. 이 우버 사례는 'AI 설계 및 구현'에 대한 귀중한 교훈을 제공한다. 첫째, 여기서 AI는 사용자와 대화로 작동한다. 의료 시스템이나 회계 시스템에서도 이러한 '인간-기계 인터페이스'로 작동할 수 있다. 그러나 내재된 편견이 있을 수 있으므로 주의해야 한다. 일단 기계의 의견을 들으면 전문가가 그에 영향을 받을 것이기 때문에 독립성이 떨어질 수 있다. 혹은 자존심 때문에 아예 무시할 수도 있다. 둘째, 쿼리GPT는 제안이나 최종 답변에 "다음과 같은 이유로 이러한 열을 제외했습니다"와 같은 '설명'을 추가한다. 인간과의 분쟁요소를 제거하고, AI의 생각 방식을 알 수 있다. 마지막으로, 최종 시스템은 반복적인 개선의 결과였다. 그들은 이를 여정(journey)이라고 부르며, 이를 위해 그들은 여러 평가 지표를 추적한다. 아마도 그들은 지금도 개선을 위해 노력하고 있을 것이다. 참고로, 최근에는 구글-스탠포드 CHASE-SQL과 알리바바 XiYan-SQL 같은 멀티에이전트 일반 해법이 발표됐다. 그들도 완벽하지 않아, 정확도가 90%를 넘지 못 한다. 여하튼 Text-to-SQL은 매우 힘든 문제임에 틀림없다. 하지만 1979년 IBM이 SQL을 출시한 이래, 질문하기 힘들어 답을 못 얻었던 시대는 이제 저무는 듯하다.
