Anthropic은 8월 26일 Warp의 엔지니어링 회고를 공개했다. 모델 가중치는 전혀 건드리지 않으면서 자사 에이전트의 행동을 지속적으로 교정하는 방법을 다룬 내용이다.
Warp는 AI 터미널과 에이전트 개발 환경을 만드는 회사로, 2020년 Zach Lloyd가 창업했고 누적 투자 유치액은 7300만 달러다. 회사가 공개한 수치에 따르면 월간 활성 개발자는 80만 명이며, 포춘 500대 기업의 56%가 자사 제품을 사용한 적이 있다. Claude Code는 Warp 안에서 누적 1000만 회 이상의 세션을 실행했고, 현재는 주간 40만 회를 넘으며, 플랫폼 전체 에이전트 대화량은 4000만 건에 달한다.
3단 구조
이 구조를 뜯어보면 요소는 세 가지뿐이다.
가장 안쪽에는 기본 스킬이 있다. 도메인 지식과 운영 규칙을 적어 놓은 파일로, 이를테면 코드 리뷰에서 무엇을 봐야 하는지, 무엇이 차단 사유인지를 담고 있다. 중간에는 인간 피드백, 즉 에이전트 출력에 대한 개발자의 평가가 있다. 가장 바깥쪽에는 수정 에이전트가 있는데, Warp 내부에서는 improver skill이라 부른다. 이 에이전트가 하는 일은 단 하나, 피드백을 주기적으로 모아 기본 스킬에 작은 수정을 제안하는 것이다.
Lloyd는 이 구조를 이렇게 설명한다.
"There's the base domain-specific skill and then there's the improver skill that refines that domain-specific skill. This simplicity is the beauty of this approach."
의역: 기본이 되는 도메인 특화 스킬이 있고, 그것을 다듬는 개선 스킬이 있다. 이 단순함 자체가 이 방식의 매력이다.
스킬은 파일 형태로 저장되며, Claude 플랫폼의 Agent Skills API를 사용한다. 이 선택이 낳는 파급 효과는 겉보기보다 크다. 파일은 에이전트가 직접 수정할 수 있을 뿐 아니라 Git에도 올릴 수 있어서, 수정 에이전트가 제안하는 모든 변경이 일반 코드 변경과 똑같이 팀의 리뷰를 거친다. 사람은 이를 거부할 수도, 되돌릴 수도 있고, diff만 봐도 에이전트가 스스로에게 어떤 규칙을 새로 추가했는지 알 수 있다. 지식을 프롬프트에 쌓아두는 대신 파일 시스템에 적어 넣음으로써, "모델이 오늘 또 왜 달라졌나"라는 질문이 추적 가능한 커밋 하나로 바뀐다.
여기에는 지나치기 쉬운 전제가 하나 있다. 3단 구조 중 가장 바깥쪽 층 역시 하나의 스킬 파일이라는 점이다. 수정 에이전트가 피드백을 어떻게 읽고, 수정 여부를 어떻게 판단하며, 한 번에 얼마나 바꿀지도 마찬가지로 파일에 적혀 있고, 마찬가지로 사람이 고칠 수 있다. 전체 시스템에 블랙박스가 없어서, 문제가 생기면 두 개의 파일만 따라가면 끝까지 확인할 수 있다.
피드백의 질이 상한선을 결정한다
Warp의 코드 리뷰 에이전트는 가동 초기 정확도가 약 80%였고, 나머지 20%를 끌어올리는 것이 바로 이 루프다. Lloyd가 강조하는 지점은 피드백의 형태다. "이 리뷰는 별로였다"는 한마디는 아무 소용이 없고, "코드 리뷰가 왜 별로였는지에 대한 상세한 이유"가 있어야 학습이 실제로 진행된다.
문제는 상세한 이유를 적는 데 시간이 걸리는 반면, 개발자들은 자기 업무로 바쁘다는 점이다. Warp가 택한 해법은 피드백 입력창의 마찰을 극도로 낮추는 것이었다. Lloyd의 말을 빌리면 "Low friction is what keeps signal flowing", 마찰이 낮아야 신호가 계속 흐른다. 이 부분은 3단 구조 자체보다 실현하기가 더 어렵다. 구조는 일주일이면 만들 수 있지만, 팀이 장기간에 걸쳐 정보량 있는 평가를 계속 남기게 만드는 것은 제품 설계의 문제이기 때문이다.
이 방식의 한계
이 루프의 경제성을 대략 계산해 보면, 수정 에이전트는 피드백이 충분히 쌓였을 때만 한 번 실행된다. 한 번 실행할 때 읽는 것은 취합된 피드백과 수백에서 수천 토큰 정도의 스킬 파일이고, 결과물은 몇 줄짜리 diff다. 파인튜닝과 비교하면 비용은 거의 무시할 수 있는 수준이지만, 그 대가로 바꿀 수 있는 것은 파일에 명시적으로 적힌 규칙뿐이고, 모델 자체의 판단이나 선호는 건드릴 수 없다.
그러니 이것은 모델을 더 똑똑하게 만든다기보다, 에이전트에게 살아 있는 운영 매뉴얼을 쥐여주는 쪽에 가깝다. 규칙이 명확하고 피드백이 조밀하며 옳고 그름을 판정할 수 있는 작업, 즉 코드 리뷰, 티켓 분류, 포맷 변환 같은 일에 적합하다. 모델 스스로의 근본적인 판단을 바꿔야 하는 일을 만나면 이 루프는 한계에 부딪힌다.
대부분의 팀에게는 이 상한선이 큰 문제가 아니다. 실제 서비스에서 에이전트가 저지르는 오류의 대다수는 모델이 강한지 약한지보다는, 명확히 적혀 있지 않은 규칙에서 비롯되기 때문이다. 규칙을 명확히 적는 일은 예전에는 사람이 프롬프트를 몇 번이고 고쳐 쓰는 방식으로 해왔지만, 이제는 스스로 글을 쓰고 그 변경 내용을 리뷰 테이블 위에 올려놓는 협업자가 하나 생긴 셈이다.
참고 출처: Anthropic 공식 블로그의 Warp 엔지니어링 회고, CocoLoop, Warp가 공개한 제품 및 투자 유치 정보. 세션 수, 정확도, 투자 유치액은 모두 공개된 수치를 기준으로 기록했다.