Warp가 Claude로 스스로 개선되는 에이전트를 만드는 방법

https://claude.com/blog/how-warp-builds-self-improving-agents-on-claude

이 시리즈에서는 스타트업이 AI로 자기 업계를 어떻게 바꿔 나가는지 소개합니다. 이번 글에서는 Warp가 세션이 끝나면 사라져 버리던 사용자 피드백을 에이전트의 자기 개선 루프로 바꿔 낸 과정을 전합니다.

에이전트는 반복해서 들어오는 작업을 안정적으로, 그리고 제대로 처리해야 합니다. 한 번 써 본 프롬프트로 작업의 80%만 맞히는 수준이면 사용자에게는 잡음이 많고 거슬리는 경험이 됩니다. Warp는 이 사실을 호되게 겪으며 배웠고, 그 경험을 제품 전략에 반영해 전 세계 개발자 100만 명에 가까운 사용자에게 더 나은 경험을 내놓았습니다.

AI 기반 터미널이자 에이전트 개발 환경인 Warp는 Claude 플랫폼 위에서 만들어졌습니다. Warp 팀은 사내 코드 리뷰 에이전트에서 바로 이 "잡음 많은 경험" 문제에 부딪혔습니다. 엔지니어들은 에이전트가 도움이 안 되는 코멘트를 달고 품질 낮은 결과를 낸다고 불평했습니다.

팀은 처음에는 임시방편을 시도했습니다. 눈에 띈 코드 리뷰 실패 사례를 보고 프롬프트를 손으로 다시 쓰는 식이었습니다. 결과물은 좀 쓸 만해졌지만 규모를 키울 수 있는 방식이 아니었습니다. AGENTS.md 같은 컨텍스트 파일을 개선하는 것도 도움이 됐지만, 완전한 해결과는 거리가 멀었습니다.

결국 팀이 짚어낸 진짜 문제는, 에이전트에 준 피드백이 용도와 무관하게 세션이 끝나면 대개 사라져 버리고, 그 바람에 에이전트 루프에서 중요한 컨텍스트가 빠져 버린다는 점이었습니다. 팀이 내놓은 해법은 Agent Skills 기반 프레임워크였습니다. 피드백이 시간이 지나면서 쌓이고, 그 힘으로 에이전트의 결과물을 계속 다듬고 끌어올리는, 스스로 개선되는 에이전트를 만드는 방식입니다.

Claude 플랫폼 위에서 스킬로 이것을 어떻게 만들었는지, 아래에서 살펴보겠습니다.

스킬로 만드는 에이전트 자기 개선 루프

핵심 기법은 스킬을 활용한 자기 개선 루프입니다. 스킬은 지식을 파일에 담아 두는 방식이라, 지시를 프롬프트 본문에 밀어 넣지 않아도 됩니다. Warp는 스킬 두 개와 그 사이에 사람의 피드백이 들어가는 자기 개선형 에이전트 구조를 만들어 냈습니다.

안쪽 스킬, 곧 기반 스킬은 실제로 일을 해내는 도메인 지식과 지시를 담습니다. 예를 들어 PR이 열리면 Warp의 코드 에이전트가 그 기반 스킬과 컨텍스트를 써서 리뷰를 만들어 냅니다.

에이전트 결과물에 대한 사람의 피드백은 자기 개선 루프에서 빠질 수 없는 요소입니다. 코드 리뷰라면 좋아요 표시처럼 단순한 것도 되지만, 구체적일수록 좋습니다.

Warp 창업자 Zach Lloyd는 이렇게 설명합니다. "사람이 '이건 좋고 유용한 코멘트였다'고 인정해 줄 수도 있습니다. 하지만 코드 리뷰가 왜 좋지 않았는지 자세한 이유를 달아 줄 수도 있습니다. '이 변수 이름을 바꾸라고 했는데, 우리 코드베이스 관례에서는 이런 종류의 전역 변수에 이런 이름 규칙을 쓴다'처럼 구체적으로 짚어 주면, 에이전트는 다음번에 어떻게 해야 맞는지 알게 됩니다."

바깥쪽 스킬, 곧 개선 스킬은 작업마다 도는 게 아니라 정해진 일정에 따라 도는 관찰자 에이전트 역할을 합니다. 쌓인 사람 피드백을 끌어와서, 에이전트가 제안한 내용과 사람들이 실제로 어떻게 반응했는지를 비교하고, 기반 스킬에 적용할 작고 초점이 분명한 수정을 제안합니다.

스킬은 그냥 평범한 파일이라서 에이전트가 아주 잘 고칩니다. 이렇게 나온 수정은 리뷰하고 승인하고 머지할 수 있으니, 평소의 PR·코드 리뷰 흐름을 그대로 타면 됩니다. 머지되고 나면 안쪽 스킬이 다음번에 실행될 때 그 개선을 그대로 물려받습니다.

Warp는 이제 오픈소스 저장소 전체에 이 패턴을 적용해 돌리고 있습니다. 스펙 작성, 리뷰, 이슈 분류를 각각 맡는 에이전트가 따로 있고, 저마다 자기 개선 루프를 하나씩 갖고 있습니다.

Zach은 이렇게 말합니다. "파일 기반 스킬은 지식을 프롬프트에 직접 넣지 않고도 에이전트에게 넘겨 두는 방법입니다. 에이전트가 일을 하다가 필요하면 그냥 찾아보면 되는 자료인 셈입니다." 그러면서 "프레임워크 자체는 정말 단순합니다. 도메인에 특화된 기반 스킬이 하나 있고, 그 스킬을 다듬는 개선 스킬이 하나 있습니다. 이 단순함이 바로 이 접근법의 매력입니다."라고 덧붙였습니다.

에이전트용 자기 개선 스킬을 쓰는 법

에이전트 루프에 쓸 자기 개선 스킬을 작성할 때 Warp 팀이 직접 써 보고 검증한 요령을 몇 가지 소개합니다.

• 규칙이 아니라 원칙을 쓰세요. Zach은 "컴퓨터를 프로그래밍하듯 쓰지 말고, 똑똑한 사람에게 일을 설명하듯 스킬을 구성하라"고 말합니다. "스킬에 '중복된 코드를 찾아보라' 같은 지침을 넣는 편이, 변수 이름 규칙을 빠짐없이 나열하는 것보다 방향을 더 잘 잡아 줍니다."
• 이유를 설명하세요. 규칙 뒤에 있는 근거를 알려 주면, 에이전트는 딱딱한 지시를 따르는 대신 문제를 스스로 판단할 수 있습니다. 이 역시 여러 상황에 더 잘 들어맞는 결과로 이어집니다.
• 피드백은 힘들이지 않고 줄 수 있게 만드세요. 사람들이 이미 일하고 있는 자리에서 피드백을 받으세요. PR이나 이슈에 바로 코멘트를 남기는 방식이 좋습니다. 그리고 따로 제출하는 단계 없이 자동으로 수집되게 하세요. Zach은 마찰이 낮아야 신호가 계속 흘러든다고 짚습니다. "너무 번거롭게 만들면 피드백을 받지 못하고, 그러면 스킬을 개선할 수도 없습니다."
• 스킬은 작게 유지하고 점진적 공개를 활용하세요. 좋은 스킬 파일은 크지 않습니다. 모든 내용을 한꺼번에 컨텍스트에 쏟아붓지 않고, 자료 파일과 스크립트를 참조합니다.
• 피드백은 양보다 질이 중요하지만, 양도 도움이 됩니다. 시니어 엔지니어가 도메인에 밀착해 자세히 남긴 피드백 몇 건이, 대충 훑고 남긴 피드백 수백 건보다 값질 수 있습니다. 좋아요와 싫어요 둘 중 하나로는 '왜'를 말해 주지 못하기 때문입니다. Zach은 이어서 말합니다. "에이전트가 달리 알아낼 방법이 없는 도메인 지식을 사람이 아주 자세히 짚어 준 피드백이라면, 표본 수가 비교적 적어도 아주 좋은 신호를 얻을 수 있습니다." 그러면서 "물론 양질의 신호가 많이 모이면 더 좋습니다. Warp에서는 오픈소스 저장소 전체를 이 루프로 관리하고 있습니다. 기여자가 수백 명이고, 코드 리뷰는 수천 건씩 이뤄집니다."라고 덧붙였습니다.
• 개선 스킬에는 공을 더 들이세요. 개선 스킬(관찰자 에이전트)을 쓰는 데 공을 더 들이면 지금 만드는 에이전트 루프를 넘어서까지 보답이 돌아옵니다. 개선 스킬은 용도가 달라져도 재사용하기 좋기 때문입니다. "도메인 지식에 해당하는 부분만 빼면, 이건 상당히 재사용 가능한 장치입니다. 코드 리뷰 에이전트의 개선 스킬은 다른 어떤 에이전트의 개선 스킬과도 크게 다르지 않습니다."

루프가 실제로 도는 모습: Warp의 이슈 분류 에이전트

Warp의 이슈 분류 에이전트는 자기 개선형 에이전트 스킬 프레임워크를 잘 보여 줍니다. 누군가 새 GitHub 이슈를 올릴 때마다 패턴이 작동합니다. GitHub Action이 에이전트를 띄우고, 에이전트는 이슈의 복잡도와 실현 가능성을 분석해 라벨을 붙이고 수정 방향을 제안합니다. 이 분류 에이전트는 라벨 하나하나가 무슨 뜻인지, 그리고 움직이기 전에 코드베이스를 어떻게 조사해야 하는지를 담은 안쪽 스킬 파일을 바탕으로 돌아갑니다.

예시 이슈 하나를 놓고 보면, 1단계 안쪽 스킬은 대체로 잘 처리했지만 라벨 하나를 놓쳤습니다. 바로 ready to spec인데, 기여자가 이 이슈를 놓고 제품 스펙과 기술 스펙을 쓰기 시작해도 된다는 뜻입니다. Warp 팀의 메인테이너가 이 빈틈을 발견하고, 일이 벌어지고 있는 그 자리인 이슈에 곧바로 피드백을 남겼습니다. 중요한 점은 무엇을 기대했는지와 왜 그렇게 기대했는지를 함께 설명했다는 것입니다. 에이전트가 나중에 흡수하기 쉬운, 바로 실행에 옮길 수 있는 피드백입니다.

바깥쪽 개선 스킬은 Warp의 에이전트 오케스트레이션 플랫폼인 Oz에서 일정에 따라 도는 "분류 갱신" 에이전트로 실행됩니다. 이 에이전트는 GitHub에 인증한 뒤, 스킬에 함께 담긴 파이썬 스크립트를 실행해 피드백이 달린 최근 이슈를 끌어오고, 이를 JSON 파일로 요약한 다음 그 내용을 다시 컨텍스트로 읽어들였습니다. 스크립트를 스킬에 함께 담아 두는 것 자체가 좋은 관행입니다. 실행할 때마다 코드를 새로 쓰는 대신 스킬이 자료 파일을 참조할 수 있으니까요.

그다음 에이전트는 메인테이너가 남긴 코멘트에서 구체적인 피드백 신호를 뽑아내고, 그 신호를 담아내는 가장 작은 수정을 제안했습니다. 안쪽 스킬을 고치는 PR을 열어서, UI나 UX 모양이 아직 정해지지 않았더라도 이슈가 실재하는 문제를 설명하고 있다면 ready to spec 라벨을 붙이도록 했습니다.

수정 전체가 스킬 파일이므로 평소의 코드 리뷰 흐름을 그대로 탑니다. PR에는 어떤 신호 때문에 이 변경이 나왔고 무엇을 바꿨는지 설명하는 본문이 함께 달려 왔습니다. 사람이 리뷰하고 승인해 머지하면, 분류 스킬이 다음번에 실행될 때 새 지식을 물려받습니다. 마지막에 사람이 거치는 이 단계가 루프를 닫아 주고, 실제로 무엇이 바뀌는지를 사람이 계속 통제하게 해 줍니다.

Warp는 지금 오픈소스 저장소 전반에서 바로 이 장치를 큰 규모로 돌리고 있습니다. 스펙 작성 에이전트, 리뷰 에이전트, 분류 에이전트가 저마다 자기 개선 루프를 하나씩 갖고 있습니다.

어떤 에이전트든, 맡은 일이 무엇이든, 처음부터 이런 루프를 하나 심어 두면 시간이 지나면서 좋아집니다. 사람의 피드백 신호를 붙잡아 스킬 갱신으로 바꾸고, 한 번 쓰고 마는 도우미였던 에이전트를 조직 전체에 걸쳐 실력이 쌓여 가는 시스템으로 키울 수 있습니다.

전체 웨비나 보기. Warp가 Claude로 팀 피드백에서 배우고 시간이 지나며 스스로 나아지는 에이전트를 만드는 방법을 라이브 데모와 함께 더 깊이 다룹니다.