잘못된 질문

어떤 기술 피드(tech feed)를 열어도 누군가는 새로운 "최고의 AI"를 추대하고 있습니다. 한 모델이 리더보드(leaderboard) 1위를 차지하면 게시물이 바이럴(viral)되고, 일주일 후에는 다른 모델이 다른 리더보드 1위를 차지합니다. 만약 이런 방식으로 도구를 선택한다면, 당신은 당신의 업무와 전혀 상관없는 숫자를 위해 최적화하고 있는 것입니다.

유용한 질문은 "어떤 모델이 가장 똑똑한가"가 아닙니다. "이 작업이 잘못되었을 때 무엇이 문제가 되는가?"입니다. 마케팅 이메일은 로봇 같은 말투가 문제가 됩니다. 마이그레이션 스크립트(migration script)는 빌드 실패가 문제가 됩니다. 재무 시트는 열 하나가 어긋나는 것이 문제가 됩니다. 로고는 평범해 보이는 것이 문제가 됩니다. 이것들은 네 가지 서로 다른 실패 유형이며, 각각 네 가지 서로 다른 도구를 가리킵니다.

작업을 분류한 다음, 도구를 선택하세요

채팅 창을 열기 전에 두 가지를 명시하세요. 작업의 유형과, 작업이 실패했다는 것을 어떻게 알 수 있는지입니다. 실패 모드(failure mode)가 대부분의 선택을 대신 해줄 것입니다.

여기에 간략한 지도가 있습니다. 특정 순위는 몇 달마다 바뀌므로, 도구 이름은 절대적인 진리가 아닌 하나의 범주(families)로 취급하십시오.

표 뒤에 숨겨진 패턴

여기에는 두 가지 핵심 아이디어가 있습니다.

첫째, 작업이 용납할 수 없는 실패 유형에 도구를 맞추십시오. 만약 작업에 엄격한 검증(컴파일이 되는지, 숫자가 맞는지, 사실인지)이 필요하다면, 해당 검증과 연결되는 도구(코드 실행, 저장소(repo) 액세스, 웹 검색)를 선택하십시오. 추측을 하는 모델은 초안 작성에는 괜찮지만, 급여 계산 공식에는 위험합니다.

둘째, 범용 채팅 모델(general chat models)은 제너럴리스트입니다. 글쓰기나 생각을 말로 표현하는 것과 같이 모호한 기준(soft criteria)을 가진 개방형 작업에는 적절한 기본값입니다. 하지만 작업에 기계적인 정답(mechanical ground truth)이 존재하는 순간, 이들은 잘못된 기본값이 됩니다. 왜냐하면 그 시점에는 리더보드(leaderboard) 점수가 가장 높은 도구가 아니라, 정답을 보유한 도구가 필요하기 때문입니다.

간단한 예시를 들어보겠습니다. 붙여넣은 데이터에 대해 일반 채팅 모델에게 "지역(region)이 EU인 C열의 합계를 구하라"고 요청하면, 종종 자신만만하지만 약간 틀린 숫자를 내놓을 것입니다. 반면, 코드 실행 도구(code-executing tool)에 동일한 요청을 하면 다음과 같이 작성합니다:

df[df.region == "EU"]["C"].sum()

그 후 코드를 실행하여 신뢰할 수 있는 숫자를 반환합니다. 요청은 같지만, 실패하는 양상(failure surface)이 다릅니다.

유일하게 의미 있는 벤치마크: 당신의 실제 작업

공개 벤치마크(Public benchmarks)는 당신의 것이 아닌 작업들을 평균 낸 결과입니다. 코딩 벤치마크에서 승리한 모델이 당신의 코드베이스(codebase), 당신의 명명 규칙(naming conventions), 혹은 당신의 기묘한 레거시 모듈(legacy module)에서는 패배할 수도 있습니다.

따라서 당신이 실제로 수행하는 작업으로 작은 대결(bake-off)을 진행해 보십시오. 오후 시간 정도만 투자하면 되며, 그 결과는 다른 모든 사람의 평균이 아닌 당신의 업무를 반영합니다.

1. 당신이 실제로 수행하는 실제 작업 3개를 선정하십시오. 당신에게 중요한 카테고리당 하나씩 선택합니다.
2. 동일한 프롬프트(prompt)를 사용하여 후보 도구 2~3개에서 각각 실행하십시오.
3. 당신이 중요하게 생각하는 기준(정확성, 필요한 수정 횟수, 절약된 시간)으로 점수를 매기십시오. 느낌(vibes)이 아니라 데이터로 판단하십시오.
4. 어떤 도구가 어떤 카테고리에서 승리했는지 기록해 두십시오. 그 기록이 당신만의 진짜 리더보드입니다.

일 년에 두 번 정도, 또는 사용하는 도구가 주요 업데이트를 출시할 때 다시 실행해 보십시오. 순위는 변할 수 있지만, 당신의 테스트 방식은 변하지 않으므로 재검증 비용은 저렴합니다.

이 프레임워크의 한계

두 가지 솔직한 주의사항이 있습니다.

카테고리가 모호해질 수 있습니다. 많은 실제 작업은 혼합되어 있습니다. 예를 들어, 데이터 작업이 서면 요약으로 끝나거나, 최신 라이브러리 문서가 필요한 코딩 작업 등이 있습니다. 혼합된 작업의 경우, 업무를 분할하여 각 부분을 라우팅(route)하거나, 하나의 도구가 모든 면에서 '매우 뛰어남' 대신 '적당히 좋음' 수준에 머무는 것을 받아들여야 합니다.

그리고 "적합한 경향이 있다"는 것은 시작 단계의 가설일 뿐, 확정된 판결이 아닙니다. 위의 라벨들은 이러한 도구군(tool families)이 어떻게 구축되었는지를 반영하는 것이지, 귀하의 정확한 프롬프트에 대한 보증이 아닙니다. 만약 귀하가 직접 수행한 비교 테스트(bake-off) 결과가 표와 다르다면, 귀하의 테스트 결과를 믿으십시오. 그것이 바로 테스트를 실행하는 핵심 이유입니다.

작업(task)에 따라 선택하고, 귀하의 실제 작업으로 검증하십시오. 리더보드(leaderboards)가 누구를 1위로 crowning 하든 상관하지 마십시오.

저는 AI를 채팅용 장난감에서 실무용 도구로 전환하는 것에 대해 글을 씁니다. 저는 실제 실습을 통해 Claude를 배우는 게임 기반 아카데미인 AGINE Academy를 구축하는 것을 돕고 있습니다. 이는 독립적인 제품이며 Anthropic과 관련이 없습니다.