사라지는 피드백을 스킬로 붙잡다: 워프의 자기개선 에이전트 패턴

AI 에이전트를 실무에 투입해 본 팀이라면 비슷한 벽에 부딪힌다. 첫 프롬프트로 과제의 80% 정도를 처리하는 에이전트는 그럴듯해 보이지만, 나머지 20%가 반복적으로 어긋나면서 오히려 사용자를 피곤하게 만든다. AI 터미널이자 에이전트형 개발 환경을 표방하는 워프(Warp)는 자사 내부 코드 리뷰 에이전트에서 정확히 이 문제를 겪었다. 엔지니어들은 에이전트가 쓸모없는 코멘트를 달고 품질이 낮은 결과를 낸다고 불평했고, 워프는 이 경험을 제품 전략으로 전환해 전 세계 약 100만 명 규모의 개발자를 대상으로 개선된 경험을 만들었다고 설명한다.

임시방편이 드러낸 진짜 문제

워프가 처음 택한 대응은 흔한 방식이었다. 관찰된 리뷰 실패 사례를 보고 프롬프트를 사람이 직접 다시 써주는 것이었다. 출력은 나아졌지만 확장되지 않았다. AGENTS.md 같은 컨텍스트 파일을 손보는 방법도 도움은 됐지만 완전한 해법과는 거리가 멀었다. 결국 팀이 도달한 진단은 프롬프트 품질 자체가 아니라 피드백의 휘발성이었다. 에이전트에 주어지는 피드백은 목적이 무엇이든 세션이 끝나면 대개 사라지고, 그 과정에서 에이전트 루프에 꼭 필요한 맥락이 함께 증발한다. 사람이 매번 같은 지적을 반복하지만 에이전트는 매번 처음부터 시작하는 셈이다.

두 개의 스킬과 그 사이의 사람

워프의 해법은 '스킬(Skills)'을 활용한 자기개선 루프다. 스킬은 지식을 파일 형태로 인코딩해 원본 프롬프트 바깥에 두고, 에이전트가 작업 중에 필요할 때 찾아보게 하는 방식이다. 구조는 의외로 단순하다. 안쪽의 기반 스킬은 도메인 지식과 지시를 담는다. 예컨대 PR이 열리면 코드 에이전트가 이 기반 스킬과 컨텍스트를 이용해 리뷰를 생성한다. 그리고 바깥쪽의 개선(improver) 스킬은 관찰자 역할을 하는 별도 에이전트로, 과제마다가 아니라 스케줄에 따라 실행된다. 이 에이전트는 누적된 사람의 피드백을 끌어와 에이전트가 제안한 내용과 사람이 실제로 어떻게 반응했는지를 비교한 뒤, 기반 스킬에 대한 작고 초점이 분명한 수정안을 제안한다.

여기서 사람의 피드백은 루프의 핵심 재료다. 워프 창업자 잭 로이드(Zach Lloyd)는 코드 리뷰의 경우 단순한 '좋아요' 표시로도 시작할 수 있지만, 구체적일수록 좋다고 말한다. 그는 사람이 "이건 유용한 코멘트였다"고 확인해 줄 수도 있지만, 왜 리뷰가 좋지 않았는지 상세히 설명할 수도 있다고 덧붙인다. 예를 들어 "이 변수 이름을 바꾸라고 제안했는데, 우리 코드베이스에서 이런 종류의 전역 변수는 이런 명명 규칙을 따른다" 같은 지적은 다음번에 제대로 하는 법을 에이전트에 알려준다는 것이다. 스킬이 평범한 파일이기 때문에 에이전트가 이를 수정하는 데 능하고, 그 수정은 검토·승인·병합이 가능한 일반적인 PR 워크플로를 그대로 탄다. 병합되고 나면 다음번 기반 스킬 실행이 그 개선을 물려받는다.

이슈 트리아지에서 작동하는 방식

워프의 이슈 분류(triage) 에이전트는 이 패턴을 잘 보여준다. 누군가 새 깃허브 이슈를 등록하면 깃허브 액션이 에이전트를 실행해 복잡도와 실현 가능성을 분석하고, 라벨을 붙이고, 수정 방향을 제안한다. 한 샘플 이슈에서 이 에이전트는 대체로 잘 처리했지만 'ready to spec' 라벨 하나를 놓쳤다. 이 라벨은 기여자가 해당 이슈를 대상으로 제품·기술 스펙 작성을 시작할 수 있다는 신호다. 워프 팀의 한 메인테이너가 이 누락을 발견하고, 작업이 벌어지는 이슈에 직접 피드백을 남겼다. 중요한 점은 그가 무엇을 기대했는지뿐 아니라 왜 그렇게 기대했는지까지 설명했다는 것이다. 나중에 에이전트가 흡수하기 쉬운 실행 가능한 형태의 피드백이었다.

이후 바깥쪽 개선 스킬은 워프의 에이전트 오케스트레이션 플랫폼 Oz에서 예약된 'update triage' 에이전트로 실행됐다. 이 에이전트는 깃허브에 인증한 뒤 스킬에 번들된 파이썬 스크립트를 돌려 피드백이 달린 최근 이슈를 수집하고, 이를 JSON 파일로 요약해 다시 컨텍스트로 읽어들였다. 매번 새로 코드를 작성하는 대신 스킬이 참조하는 리소스 파일을 두는 것 자체가 하나의 모범 사례로 제시된다. 그 결과 에이전트는 메인테이너 코멘트에서 구체적인 신호를 식별하고, 이를 담아내는 가장 작은 수정을 제안했다. UI나 UX의 정확한 형태가 아직 정의되지 않았더라도 실제 문제를 서술한 이슈라면 'ready to spec' 라벨을 붙이도록 기반 스킬을 고치는 PR이었다. 사람이 검토하고 승인·병합하면서 최종적으로 루프가 닫히고, 무엇이 실제로 바뀌는지에 대한 통제권은 사람에게 남는다.

실무자가 눈여겨볼 지점과 한계

국내 개발 조직 관점에서 이 접근의 매력은 새로운 인프라가 아니라 기존 워크플로를 재활용한다는 데 있다. 스킬 수정이 결국 파일 변경이므로 코드 리뷰, 승인, 병합이라는 이미 익숙한 절차를 그대로 통과하고, 모든 변경이 추적·되돌리기 가능하다. 지식을 프롬프트에 직접 욱여넣는 대신 별도 파일에 두는 구조는 프롬프트 비대화를 막고, 스펙 작성·리뷰·트리아지처럼 성격이 다른 에이전트가 각자의 개선 루프를 갖도록 분리하기에도 유리하다. 워프는 실제로 이 패턴을 오픈소스 저장소 전반에 적용하고 있다고 밝힌다.

다만 이 구조가 저절로 굴러가지는 않는다는 점은 분명히 짚을 필요가 있다. 루프의 품질은 사람이 남기는 피드백의 구체성에 전적으로 좌우된다. '좋아요' 한 번으로도 시작은 되지만, 왜 그런지를 함께 적지 않으면 개선 스킬이 학습할 신호가 빈약해진다. 또한 개선 에이전트가 스킬을 스스로 수정하도록 두더라도 병합 단계에는 반드시 사람이 남아 통제권을 쥔다는 점이 이 설계의 전제다. 원문은 이 패턴을 웨비나 데모와 함께 소개하며 처음부터 피드백 포착 루프를 심어두면 일회성 도우미였던 에이전트가 조직 전반에서 복리로 성장하는 시스템이 된다고 강조한다. 결국 관건은 도구가 아니라, 흩어지는 피드백을 붙잡아 자산으로 축적하는 규율을 팀이 갖출 수 있느냐다.