지난 주말 많은 사람이 슈퍼볼을 시청하며 수많은 광고를 접했다. 그러나 온라인에서는 사람과 광고의 상호작용이 적다. 온라인에서는 AI 에이전트가 광고와 상호작용하는 경우가 점점 더 많아지고 있다. 이와 관련해 그랩(Grab)의 지역 마케팅 디렉터 켄 맨델은 “콜라 주문을 사람이 아닌 AI가 결정한다면, 왜 인스타그램 노출을 위해 광고 입찰에 참여해야 하는가? 에이전트가 브랜드와 상호작용하는 세상에서 게임의 판도는 광고가 아니라 AI의 영향력과 최적화가 좌우한다”라고 말했다.

광고 업계를 뒤흔들 이런 변화가 개발자 도구 분야에서도 일어나고 있다. 과거 개발자 관계에서는 소프트웨어 기업이 디벨로퍼 애드버케이트(developer advocate)를 두고 스택 오버플로우나 레딧 같은 커뮤니티에서 사람들의 질문에 답하거나 튜토리얼을 작성하는 것이 필수적이었다. 하지만 점점 더 많은 개발자가 깃허브 코파일럿과 같은 코딩 어시스턴트를 활용해 답변과 가이드를 얻고 있는 상황이라면, 특정 제품에 대한 LLM의 “생각”에 영향을 미치는 것이 중요하다. 그러나 이를 효과적으로 구현하는 방법은 아직 불분명하다.

이제는 AI가 어떻게 특정 제품이나 기술을 이해하도록 만들 것인지에 대한 전략이 필요하다는 점은 분명하다. 하지만 이를 어떻게 실현해야 할까?

AI를 훈련하는 주체는 누구인가?

LLM에 영향을 미칠 수 있는 능력은 상당히 제한적이다. 만약 LLM과 그에 연계된 도구를 직접 소유하고 있다면 그 출력에 상당한 영향을 미칠 수 있을 것이다.

예를 들어 AWS는 아마존 Q를 훈련시켜 AWS 서비스 관련 질문에 답하도록 만들 수 있다. 이때 아마존 Q가 AWS 서비스에 “편향성”을 보일지는 별도의 논의가 필요하지만, 이것은 부차적인 문제다. 실제로는 AWS 관련 문서와 정보가 더 많고 잘 정리되어 있으므로 개발자를 레디스 대신 아마존 엘라스틱캐시로 유도할 가능성이 크다.

궁극적인 핵심은 양질의 학습 데이터를 충분히 확보해 이들 도구가 개발자에게 잘못된 방향을 제시하지 않도록 보장하는 것이다.

몽고DB의 개발자 관계를 담당하는 필자는 AWS 및 다른 회사와 협력해 코드 샘플, 문서 등으로 LLM을 훈련시킨 적이 있다. 우리가 하지 않은 (또는 할 수 없었던) 일은 LLM이 올바른 응답을 생성하도록 하는 것이었다.

만약 스택 오버플로우 Q&A에 몽고DB를 분산하는 방법에 대한 잘못된 예제 10개와 올바른 예제 3개가 있다면, 깃허브 코파일럿과 같은 도구가 올바른 예제 3개를 기반으로 답변하도록 보장하는 방법이 있을까? LLM은 인터넷에 공개된 온갖 종류의 데이터, 즉 좋은 데이터와 나쁜 데이터를 모두 학습했기 때문에 개발자가 올바른 조언을 받을 수 있을지는 다소 불확실하다.

마이크로소프트의 빅터 디비아는 이 문제에 대해 “개발자가 코드 생성 모델에 점점 더 의존하는 만큼, 이런 모델이 특정 라이브러리나 프레임워크, 툴을 얼마나 잘 지원하는지 고려해야 한다”라고 말했다. 몽고DB에서도 다양한 LLM이 여러 주제를 얼마나 잘 처리하는지를 정기적으로 평가하며, 이를 바탕으로 LLM 제공업체와 협력해 성능을 개선하려고 노력하고 있다. 하지만 여러 LLM이 개발자에게 올바른 지침을 제공하도록 보장하는 방법은 여전히 불투명하다.

LLM 훈련법에 대한 조언은 차고 넘치지만, 이는 어디까지나 해당 LLM을 직접 소유한 경우에 해당한다. 오픈AI의 모델이 아파치 아이스버그와 관련한 최상의 데이터를 학습하기 위해 아파치 아이스버그 개발팀이 할 수 있는 일은 무엇일까? 현재로서는 불가능하다. 서드파티 LLM에 질문을 하거나 코드 완성을 기대하는 개발자가 신뢰할 수 있는 답변을 받을 것이라고 확신할 방법이 전혀 없다.

모델에 책임 부여

한 가지 방법은 벤치마크를 공개하는 것이다. LLM 제공업체들은 궁극적으로 결과물을 개선해야 할 것이다. 그렇지 않으면 개발자가 더 나은 결과를 지속적으로 제공하는 다른 툴로 눈을 놀릴 것이다. 오픈소스 프로젝트, 상용 벤더, 혹은 LLM을 주요 지식 매개체로 활용하는 기업이라면 어떤 LLM이 좋은 성능을 내고 어떤 LLM이 그렇지 못한지 보여주는 벤치마크 결과를 정기적으로 발표해야 한다. 이를 통해 업계 전체가 발전할 수 있다.

또한 깃허브 코파일럿이나 아마존 Q 같은 코딩 어시스턴트에 의존하는 개발자라면 긍정적이든 부정적이든 자신의 경험을 공유해야 한다. 현재 LLM 제공업체들은 개발자의 신뢰를 얻기 위한 경쟁을 벌이고 있다. 따라서 개발자의 생산성을 저해하는 툴을 공개적으로 비판하고 신뢰할 수 있는 툴을 적극 추천할 필요가 있다.

앞으로는 기업이 코드 추천에 영향을 미치기 위해 비용을 지불하는 시대가 올 가능성도 있다. 필자는 이전에도 코딩 툴을 위한 SEO 개념을 언급한 바 있다. 아직 이런 움직임이 본격적으로 나타나지는 않았지만, 맨델이 광고 산업에서 본 트렌드가 소프트웨어 개발 분야로 옮겨갈 가능성은 충분하다. 맨델은 “구글 광고가 ‘구글 AI 선호 입찰’로 바뀌고 AI 에이전트가 선호하는 제안이 되기 위해 입찰하는 상황을 상상해 보라”라고 말했다.

비슷한 일이 AI 기반 코딩 어시스턴트에서도 일어날 수 있을까? 물론이다. 그런 상황이 오더라도 정기적인 벤치마크와 커뮤니티의 적극적인 피드백을 통해 최상의 가이드를 얻을 수 있기를 바란다.
dl-itworldkorea@foundryco.com