장기 실행 AI 에이전트 설계 - 결과 평가의 한계와 행동 명세로 과정을 감독하는 법

핵심 메시지

• 평가 100개를 모두 통과해도 실제 운영 환경으로 일반화된다고 믿을 수는 없다. 결과만 맞히는 방식으로도 과정을 건너뛸 길은 얼마든지 있기 때문이다.
• Basis는 에이전트가 어떻게 행동해야 하는지를 마크다운 문서로 적어두고, 궤적을 들여다보는 심판 에이전트가 그 행동이 실제로 나타났는지 채점하게 한다.
• 언어 모델은 작업 기억은 거대하지만 단기·장기 기억이 사실상 없다. 긴 작업을 버티게 하려면 하네스와 문맥 설계로 그 빈자리를 메워야 한다.
• 실제 업무에 필요한 건 천재적인 한 수가 아니라 일관성과 신뢰성이다. 회계 법인이 사는 것은 '역대 최고의 세무 신고서'가 아니라 믿고 맡길 수 있다는 확신이다.
• 코딩 에이전트가 먼저 성공한 이유는 검증 가능한 보상 때문만이 아니다. 실행하는 순간 값싸게 결과를 확인할 수 있고, 각 연구소가 고품질 코드 학습 데이터에 집중했기 때문이다.

쉽게 이해하기

이 대화의 주인공은 회계 업무를 처음부터 끝까지 처리하는 에이전트를 만드는 Basis의 공동창업자 미치 트로야노프스키다. 이 회사의 에이전트는 몇 시간, 때로는 며칠씩 사람의 확인 없이 돌아가며 복잡한 세무 신고서를 완성한다. 여기서 '자율'은 결과물을 아무도 안 본다는 뜻이 아니다. 오히려 신입 엔지니어가 코드 리뷰를 요청하듯 '여기서 이런 큰 결정을 내렸고 이런 가정을 세웠으니 함께 검토하자'며 넘기는 상태에 가깝다.

긴 작업을 버티는 게 왜 어려운지에 대한 그의 설명이 명쾌하다. 언어 모델은 작업 기억은 아주 큰데 단기 기억도 장기 기억도 사실상 없다. 그는 크리스토퍼 놀런의 영화 '메멘토'를 예로 든다. 매일 아침 기억이 초기화되는 주인공은 목표를 향해 나아가려면 스스로에게 메모를 남기고 다음 날 그 메모를 읽어 상태를 복원해야 한다. 에이전트도 마찬가지여서, 문맥창을 넘어서는 순간부터는 다음 추론 단계가 필요한 것을 갖도록 스스로 환경을 정리하는 추론이 핵심이 된다.

왜 코딩 에이전트가 먼저 잘됐을까. 흔히 검증 가능한 보상 때문이라고 하지만 그는 조금 다르게 본다. 코드는 실행하는 즉시, 그것도 아주 싸게, 어디서든 검증된다는 점이 결정적이다. 아무리 뛰어난 엔지니어라도 한 번도 실행해 보지 못한 코드는 어딘가 틀리기 마련이다. 여기에 각 연구소가 엔지니어로 가득한 조직인 만큼 고품질 코드 학습 데이터에 특별히 공을 들였다는 점이 겹쳤다. 반면 회계처럼 코딩 바깥의 영역은 무엇이 '좋은 결과'인지부터 불분명하고, 데이터도 턱없이 부족하며, 피드백 주기가 지나치게 길다.

그래서 Basis가 택한 방향이 결과가 아니라 과정을 보는 것이다. 트로야노프스키는 세무 리서치를 예로 든다. 어떤 세무 질문에 에이전트가 100번 다 정답을 맞혔다고 해보자. 그런데 그 근거가 사전학습된 지식이나 어디선가 읽은 블로그라면, 사람이 위키백과를 보고 답을 맞힌 것과 같다. 회계 법인이라면 그런 사람을 고용하지 않을 것이고, 그렇다면 자기 회사의 에이전트도 고용하지 말아야 한다는 것이다. 실제 세무사가 그러듯 1차 출처를 직접 확인하는 과정 자체가 요구 사항이 된다.

이를 구현한 장치가 '행동 명세'다. 에이전트가 어떻게 행동해야 하는지를 마크다운에 적어두는 단순한 형식인데, 사양이자 채점 기준이라는 이중 역할을 한다. 사람들 사이에 '우리 제품의 에이전트는 이렇게 행동해야 한다'는 합의를 만드는 도구이기도 하다. 흥미로운 점은 이 문서를 에이전트에게 보여주지 않는다는 것이다. 대신 궤적을 들여다보는 심판 에이전트가 해당 조건이 발생했는지, 발생했다면 그 행동이 실제로 나타났는지를 채점한다. 유지 비용이 크기 때문에 모든 모범 사례를 적는 대신 영향이 크고 일반화가 잘 되는 소수만 고른다.

그는 문맥을 '프롬프트'가 아니라 '런타임 학습 데이터'로 볼 것을 권한다. 이 관점을 받아들이면 문맥의 품질 관리가 곧 모델 학습 데이터의 품질 관리와 같은 무게를 갖는다. 그가 꼬집는 대목이 재미있다. 많은 엔지니어가 추상화가 어설픈 코드 파일 하나에는 펄쩍 뛰면서 정작 자신의 문맥은 엉망으로 방치한다는 것이다. 논리가 같다면 코드 구조는 런타임 성능에 영향을 주지 않지만 문맥은 곧바로 영향을 준다. 그의 표현대로라면 이 세계에서는 코드보다 영어가 더 귀하다.

주요 인사이트

• 사람은 이미 비결정적 시스템과 일하는 데 익숙하다. 다만 그 시스템이 컴퓨터가 아니라 동료였을 뿐이다. 기업의 조직과 프로세스는 결국 비결정적 주체들이 협력해 문제를 풀도록 설계한 장치이고, 이 사실을 깨닫는 순간 조직 설계의 노하우가 그대로 에이전트 설계로 넘어온다.
• 이른바 '수 37' 같은 천재적 한 수는 실제 업무에서 오히려 곤란할 수 있다. 회사의 절차를 무시하고 1000줄짜리 PR을 통째로 들고 온 엔지니어가 CTO보다 나은 설계를 했더라도 그 결과가 환영받지는 않는다. 고객이 사는 것은 개별 결과물의 탁월함이 아니라 조직 단위로 확장 가능한 일관성이다.
• 온톨로지, 즉 에이전트가 사는 세계의 구조와 언어를 설계하는 일이 중요해진다. 코딩 에이전트는 런타임 학습 데이터에 해당하는 코드베이스를 자기가 소유하지 못하므로 같은 에이전트라도 저장소에 따라 성능이 크게 갈린다. 반대로 코딩 바깥의 에이전트는 그 데이터를 직접 소유하므로 설계 책임도 온전히 만드는 쪽에 있다.
• 조직 안에서 에이전트를 쓰려면 무엇이 '정본'인지 명확해야 한다. 2년 치 영업 통화 기록을 다 들어도 지금의 영업 전략은 알 수 없다. 사람은 옆자리에 물어 알아내지만 에이전트에게는 그 경로가 없으므로, 회사의 정본 문서를 코드처럼 최신 상태로 관리하는 일이 핵심 역량이 된다.
• 그는 기술이 해자가 되지 못한다고 잘라 말한다. Basis의 장기 가치 중 남들이 못 찾은 강화학습 비법에서 나오는 몫은 없다는 것이다. 하네스 수준의 작업은 결국 모델에 흡수될 텐데, 그 시점을 2년 안쪽은 아니고 5년 안쪽으로 본다. 그때까지 시장에 깊이 자리 잡는 것이 실제 경쟁력이라는 계산이다.

자주 묻는 질문

관련 AI 소식