[사례] 피드백이 세션과 함께 사라지지 않게: Warp의 자기개선 에이전트

Anthropic이 2026년 8월 26일 공개한 「How Warp builds self-improving agents on Claude」를 정리하고, 국내 개발 조직이 같은 구조를 적용할 때의 조건을 덧붙입니다. 작성자는 Michael Segner이고, 스타트업의 AI 활용을 다루는 연재의 한 편입니다.

Warp이 어떤 회사인지

항목	내용
설립	2020년
창업자	Zach Lloyd (CEO)
제품	AI 기반 터미널 및 에이전틱 개발 환경
스택	Rust, Golang, GitHub Actions, 자체 에이전트 오케스트레이션 플랫폼 Oz, Claude Platform
규모	누적 투자 7,300만 달러, 월 80만 개발자, Fortune 500의 56% 사용
사용량	Warp 내부에서 실행된 Claude Code 세션 누적 1,000만 건, 주당 40만 건 이상, Warp Agent 대화 누적 4,000만 건

80%가 만드는 소음

기사의 출발점은 정확도 80%짜리 첫 프롬프트가 사용자 경험을 망친다는 관찰입니다. Warp 내부 코드리뷰 에이전트가 그 문제를 겪었습니다. 엔지니어들은 그 에이전트가 도움이 되지 않는 코멘트를 달고 품질이 낮은 결과를 낸다고 불평했습니다.

Warp은 먼저 임시방편을 시도했습니다. 관찰된 실패 사례를 보고 프롬프트를 손으로 다시 쓰는 방식이었습니다. 결과물은 쓸 만해졌지만 확장되지 않았습니다. AGENTS.md 같은 컨텍스트 파일 개선도 도움은 됐지만 완전한 해법과는 거리가 멀었습니다.

Warp 팀이 도달한 진단은 다음과 같습니다. 에이전트에게 준 피드백은 세션이 끝나면 대개 사라지고, 그러면서 에이전틱 루프에서 결정적인 맥락이 빠져나갑니다. 해법은 그 피드백이 시간이 지나며 누적되도록 만드는 것이었습니다.

스킬 두 개와 그 사이의 사람

구조는 단순합니다. 스킬 두 개와 그 사이에 사람이 있습니다.

구성 요소	역할	실행 시점
내부 기본 스킬	도메인 지식과 실행 지침 보유	작업이 발생할 때마다
사람의 피드백	결과의 좋고 나쁨과 그 이유를 남김	결과를 검토할 때
외부 개선 스킬	피드백을 모아 기본 스킬 수정안 제안	정해진 주기로

Zach Lloyd는 피드백의 밀도가 핵심이라고 말합니다. "사람이 '이건 유용한 코멘트였다'고 확인해 줄 수도 있습니다. 하지만 왜 그 코드리뷰가 좋지 않았는지 구체적으로 설명해 줄 수도 있습니다. '이 변수 이름을 바꾸라고 제안했는데, 우리 코드베이스에서 이런 종류의 전역 변수는 이런 명명 규칙을 씁니다' 같은 구체성이 다음번에 제대로 하는 법을 알려줍니다."

개선 스킬은 관찰자 에이전트로서 개별 작업과 무관하게 정해진 일정에 따라 돕니다. 누적된 사람 피드백을 끌어와 에이전트가 제안한 것과 사람이 반응한 것을 비교하고, 기본 스킬에 대한 작고 좁은 수정안을 냅니다.

핵심은 스킬이 평범한 파일이라는 점입니다. 수정안은 일반적인 PR과 코드리뷰 절차를 그대로 통과하고, 병합되면 다음 실행부터 그 지식을 물려받습니다. Lloyd의 표현으로는 "파일 기반 스킬은 지식을 프롬프트에 직접 넣지 않고, 에이전트가 일하는 도중에 그냥 찾아볼 수 있는 것으로 인코딩하는 방법"입니다.

이슈 트리아지 에이전트에서의 동작

기사가 든 실제 예시는 GitHub 이슈 분류 에이전트입니다. 새 이슈가 등록되면 GitHub Action이 에이전트를 띄우고, 에이전트는 복잡도와 실현 가능성을 분석해 라벨을 붙이고 수정 방향을 제안합니다.

한 사례에서 기본 스킬은 대체로 잘했지만 ready to spec 라벨 하나를 놓쳤습니다. 유지보수 담당자가 그 이슈에 직접 피드백을 남기면서 자기가 무엇을 기대했고 왜 그랬는지를 함께 적었습니다.

그다음 개선 스킬이 Oz에서 예약 실행됩니다. GitHub에 인증하고, 스킬에 함께 담긴 파이썬 스크립트로 피드백이 달린 최근 이슈를 끌어와 JSON으로 요약한 뒤 다시 읽어 들입니다. 스크립트를 스킬에 동봉하는 것 자체가 권장 관행입니다. 실행할 때마다 코드를 새로 짜는 대신 리소스 파일을 참조하기 때문입니다.

에이전트는 피드백에서 구체적 신호를 뽑아 가장 작은 수정을 제안했습니다. 문제가 실재하지만 UI나 UX 형태가 아직 정해지지 않은 경우에도 ready to spec을 붙이라는 내용으로 기본 스킬을 고치는 PR이었습니다. 사람이 검토하고 승인하고 병합하는 마지막 단계가 루프를 닫고, 무엇이 바뀌는지에 대한 통제권을 사람에게 남깁니다.

Warp 팀이 정리한 작성 원칙

원칙	내용
규칙보다 원리	컴퓨터를 프로그래밍하듯 말고 똑똑한 사람에게 지시하듯 작성
이유 명시	근거를 함께 적으면 에이전트가 상황에 맞게 추론
피드백 마찰 제거	PR이나 이슈에 코멘트하는 등 이미 일하는 자리에서 수집
스킬은 작게	전부 담지 말고 리소스 파일과 스크립트를 참조
품질 우선	시니어의 상세한 피드백 소수가 형식적 다수보다 나음
개선 스킬에 투자	개선 스킬은 다른 용도에도 그대로 재사용 가능

Lloyd는 마지막 항목을 특히 강조합니다. 도메인 지식 부분을 빼면 개선 스킬은 상당히 재사용 가능한 장치이고, 코드리뷰 에이전트용 개선 스킬과 다른 에이전트용 개선 스킬이 크게 다르지 않다는 것입니다.

기사가 스스로 붙인 경계 조건

기사 말미의 문답이 오히려 실무에 가깝습니다.

질문	Warp 팀의 답
스킬과 메모리를 혼동하는가	스킬은 절차적이고 안정적이며 의도적으로 바뀜, 메모리는 추론 시점에 자동으로 계속 쓰임
개선 루프는 몇 개인가	공통 부분은 템플릿 기본 루프로, 도메인별 가중치만 얹음
피드백이 틀리면	틀린다고 가정할 것, 맹목적 수용 금지, 사람을 필터 단계나 최종 검토에 남김
도메인이 검증 가능한가	검증 하네스를 먼저 만들고 에이전트가 거기에 맞춰 튜닝
검증이 어렵다면	골든 출력 기반 결정적 평가를 쓰고, 사람 피드백은 도메인 전문가로 제한
시스템 전체가 나아지는지	병합까지 걸린 시간, 기여자 수, 비용 같은 전역 지표를 개선 에이전트에 되먹임

국내 조직에서 무너지는 지점

이 구조는 전제가 꽤 많습니다. 전제가 없는 조직에서 도입하면 개선 스킬이 학습할 신호 자체가 만들어지지 않습니다.

전제	어긋나는 형태	결과
PR 기반 리뷰 문화	승인만 누르고 코멘트를 남기지 않음	개선 스킬이 읽을 피드백이 없음
이유를 적는 습관	수정 요청은 구두나 메신저로 전달	신호가 기록에 남지 않음
코딩 컨벤션 문서화	관행은 있으나 문서가 없음	기본 스킬에 넣을 도메인 지식이 없음
시니어의 검토 시간	리뷰가 소수에게 몰려 병목	피드백 품질이 확보되지 않음
스킬 변경의 검토 권한	누가 승인하는지 미정	에이전트가 스스로 규칙을 바꿔도 아무도 모름

세 번째 줄이 국내에서 가장 흔합니다. 리뷰 기준이 사람 머릿속에만 있는 조직에서는 기본 스킬을 쓰는 일 자체가 첫 번째 과제가 됩니다. 이 작업은 에이전트 도입과 무관하게 가치가 있으므로 순서상 먼저 하는 편이 낫습니다.

다섯 번째 줄은 보안 검토 대상입니다. 에이전트가 자기 행동 규칙을 바꾸는 PR을 올리는 구조이므로, 그 PR의 승인 권한과 병합 이력이 통제 대상에 들어가야 합니다. 기사도 마지막 사람 검토 단계가 통제권을 남기는 지점이라고 명시합니다.

코텍시스는 에이전트 구축에서 행동 허용 범위를 정의하고 위반을 차단하는 가드레일을 파이프라인에 내장하며, 실패나 불확실한 판단에서 사람이 개입하는 승인 지점을 설계 단계에 배치합니다. 자기개선 루프를 쓰는 경우 그 승인 지점 목록에 스킬 파일 변경이 반드시 포함돼야 합니다.

출처

• How Warp builds self-improving agents on Claude, Michael Segner, Anthropic, 2026-08-26