재학습 없는 자가 개선 에이전트 — Warp가 인간의 피드백을 스킬 파일로 전환하는 방법 (2026)

Warp는 Claude Platform을 기반으로 구축된 AI 구동 터미널이자 에이전트 개발 환경입니다. 규모를 살펴보면, 7,300만 달러 투자 유치, 월간 개발자 80만 명, Fortune 500 기업의 56% 사용, 4,000만 건의 Warp Agent 대화, 그리고 놀라운 수치인 "현재까지 Warp 내에서 실행된 Claude Code 세션 1,000만 건 돌파, 매주 40만 건 이상 실행" 등이 있습니다.

문제는 인기가 없었던 내부 에이전트였습니다

Warp의 코드 리뷰 에이전트는 자체 엔지니어들을 짜증 나게 하고 있었습니다. 엔지니어들은 "에이전트가 도움이 되지 않는 의견을 남기고 저품질의 결과물을 만들어낸다며 불평했습니다." 이 기사는 이러한 일반적인 형태를 명료하게 서술합니다. "작업의 80%를 올바르게 수행하는 첫 번째 프롬프트는 사용자에게 노이즈가 많고 짜증 나는 경험을 선사할 수 있습니다."

처음에는 두 가지 임시방편이 도입되었으며, 이는 대부분의 팀이 시도하는 방법들입니다. 실패가 관찰될 때마다 프롬프트를 수동으로 다시 작성하는 것은 "출력물을 더 쓸만하게 만들었지만 확장성이 없었습니다." AGENTS.md와 같은 컨텍스트 파일을 개선하는 것도 "도움은 되었지만 완전한 해결책과는 거리가 멀었습니다." 이러한 한계의 일반적인 버전은 왜 에이전트가 당신이 작성한 지침 파일을 무시하는가에서 다루고 있습니다.

내부 스킬은 지식을 보유합니다

기본 스킬은 "기능적 도메인 지식과 지침을 보유합니다." PR이 열리면 Warp의 코드 에이전트가 해당 스킬을 기반으로 실행되어 리뷰를 생성합니다.

Warp의 창립자인 Zach Lloyd는 파일 형태가 중요한 이유를 다음과 같이 설명합니다. "파일 기반 스킬은 지식을 프롬프트에 직접 넣지 않고도 에이전트를 위해 지식을 인코딩하는 방법으로, 에이전트가 작업을 수행하는 과정에서 간단히 찾아볼 수 있는 무언가입니다."

개선자 스킬은 참여자가 아닌 관찰자입니다

이 부분이 루프를 작동하게 만드는 핵심이며, 스케줄러 세부 사항은 놓치기 쉽습니다. 외부 스킬은 "작업당 실행되는 것이 아니라 일정(schedule)에 따라 실행되는 관찰자 에이전트 역할을 합니다. 누적된 인간의 피드백을 가져와 에이전트가 제안한 내용과 인간이 반응한 내용을 비교하고, 기본 스킬에 대해 작고 집중적인 수정을 제안합니다."

작업당 실행되는 것이 아닙니다. 일정에 따라 실행됩니다. 이는 매 실행마다 결합되는 반성(reflection) 단계가 아니라, 코퍼스(corpus)를 바라보는 별도의 작업입니다.

이 스킬이 인간에게 원하는 것은 구체성입니다. Lloyd의 예시: "사람은 '이것은 좋고 유용한 의견이었다'라고 긍정할 수 있습니다. 하지만 코드 리뷰가 왜 좋지 않았는지 구체적인 이유를 제공할 수도 있습니다. '이 변수의 이름을 바꾸라고 제안했지만, 우리 코드베이스 컨벤션에서는 이러한 유형의 전역 변수가 이 특정 명명 컨텍스트를 사용합니다'와 같은 구체적인 내용은 에이전트에게 다음에 올바르게 수행하는 방법을 알려줍니다."

루프는 코드 리뷰를 통해 닫힙니다

이것이 단순한 영리한 트릭 이상이 되게 만드는 속성이 있습니다. "스킬은 평문 파일이기 때문에 에이전트는 이를 업데이트하는 데 매우 능숙합니다. 검토, 승인, 병합이 가능한 이러한 업데이트는 일반적인 PR/코드 리뷰 워크플로우를 통해 흐를 수 있으며, 일단 병합되면 내부 스킬의 다음 실행은 개선 사항을 상속받습니다."

Warp의 이슈 분류(triage) 에이전트는 이를 처음부터 끝까지 보여줍니다. GitHub Action이 새 이슈의 복잡성과 실현 가능성을 분석하고, 라벨을 할당하고, 방향을 제안하는 에이전트를 실행합니다. 한 이슈에서 이 에이전트는 ready to spec 라벨을 놓쳤습니다. 메인테이너는 이슈 자체에—"정확히 작업이 일어나고 있는 곳"에—그가 기대한 바와 그 이유를 모두 설명하는 피드백을 남겼습니다.

그 후 개선자(improver)는 Warp의 에이전트 오케스트레이션 플랫폼인 Oz에서 예약된 "업데이트 분류" 에이전트로 실행되었습니다. GitHub에 인증하고, 스킬과 함께 번들로 제공되는 Python 스크립트를 실행하여 피드백이 포함된 최근 이슈를 가져와 JSON 파일로 요약한 다음, 이를 다시 컨텍스트로 읽어 들였습니다. 그런 다음 "정확한 UI나 UX 형태가 아직 정의되지 않았더라도 이슈가 실제 문제를 설명할 때 'ready to spec' 라벨을 적용하도록 내부 스킬을 수정하는 PR을 열었습니다."

그리고 사람이 이를 병합했습니다. Anthropic은 이 단계를 다음과 같이 프레임화합니다. "그 마지막 인간의 단계가 루프를 닫고 실제로 무엇이 변경되는지를 사람이 통제할 수 있게 해줍니다."

Warp는 이제 이를 전체 오픈 소스 리포지토리에 걸쳐 실행하고 있으며, 사양 작성, 리뷰, 분류 에이전트가 각각 자체 루프를 수행하고 있습니다. "수백 명의 사람들이 기여하고 있으며 우리는 수천 개의 코드 리뷰를 진행하고 있습니다."

이 패턴은 설득력이 있습니다. 다만 그 증거는 벤더의 케이스 스터디이며, 그 차이에 대해 정확히 짚고 넘어갈 가치가 있습니다.

전후 비교 수치가 제공되지 않습니다. 이 기사는 리뷰 품질, 분류 정확도 또는 불만 건수에서 측정된 개선 사항을 보고하지 않습니다. 개발자 80만 명, Claude Code 세션 1,000만 건이라는 인상적인 수치는 Warp의 비즈니스를 설명하는 것이지, 루프의 효과 크기를 나타내는 것이 아닙니다. 에이전트가 얼마나 더 나아졌는지를 정량화하는 내용은 여기에 없습니다.

Warp는 이를 위해 이례적으로 우수한 환경을 갖추고 있습니다. 이미 수백 명의 기여자가 PR 댓글을 남기고 있는 공개 리포지토리는 대부분의 팀이 가지고 있지 않은 피드백 코퍼스입니다. Oz는 예약된 에이전트를 위한 사내 오케스트레이션 플랫폼입니다. 둘 중 하나라도 제외하면 이 루프는 직접 구축한 무언가로 대체되어야 합니다.

선택된 도메인은 다루기 쉬운 편에 속합니다. 코드 리뷰와 이슈 분류는 기존의 검토 리추얼(ritual)이 존재하고 대략적으로 확인 가능한 결과물을 가집니다. Warp 자체 가이드에서도 어려운 사례를 직접 인정하며, "당신의 도메인은 검증 가능한가요?"라고 자문하고, 그렇지 않다면 "골든 아웃풋(golden outputs)에 대한 결정론적 평가(deterministic evals)가 존재하는 곳이라면 어디든 이에 의존하라"고 조언합니다.

자율적인 자가 개선이 아닙니다. 모든 변경 사항은 사람이 병합하는 PR입니다. "자가 개선"은 제안이 어디서 오는지를 설명할 뿐, 누가 결정하는지를 설명하지 않습니다.

Warp는 피드백이 가끔 틀릴 수 있다고 가정합니다. 이 글에서 가장 유용한 구절이기에 전문을 인용합니다. "틀릴 것이라고 가정하세요. 에이전트가 피드백을 맹목적으로 수용하게 두지 마세요. 온전성 검사(sanity-check)를 할 수 있는 컨텍스트를 제공하고, 누구의 입력이 유효한지 필터링하며, 필터링 단계나 최종 검토 단계 중 하나에는 인간을 루프에 참여시키세요."

그리고 이것은 절차적 루프이지, 메모리 시스템이 아닙니다. 이 점은 매우 중요하여 Anthropic도 기사 자체 FAQ의 첫머리에 "스킬과 메모리를 혼동하고 계신가요?"라는 제목으로 다루었습니다. 답변은 다음과 같습니다. "스킬은 절차적이고 안정적입니다. 즉, 'X를 수행하는 방법'으로, 실행에 구애받지 않고 의도적으로 변경됩니다. 메모리는 추론 시점에 에이전트에 의해 자동으로 작성되며 끊임없이 변화합니다."

이것은 우리가 왜 에이전트 스킬이 메모리가 아닌가에서 주장했던 것과 동일한 구분이며, 벤더에 의해 명시되었습니다. 여기서 이것이 중요한 이유는 루프가 개선하는 대상이 무엇인지 알려주기 때문입니다. 즉, 에이전트가 작업을 수행하는 방식이지, 프로젝트에 대해 알고 있는 지식이 아닙니다.

"이제 스킬이 곧 메모리다." 기사는 헤드라인에서 정반대로 말합니다. 스킬은 의도적으로 변경하는 안정적인 절차이며, 메모리는 추론 시점에 작성되고 끊임없이 변화합니다. Warp의 루프는 검토를 통해 의도적으로 절차를 개선합니다.

"에이전트가 스스로를 개선한다." 모든 변경 사항은 사람이 병합합니다. 이 단계를 제거하면 감독 없이 에이전트가 자신의 지침을 직접 수정하게 되며, 이는 전혀 다르고 더 나쁜 시스템입니다.

"두 개의 파일이면 충분하다." 피드백이 도달하는 공간, 스케줄러, 그리고 코퍼스를 컨텍스트로 가져오는 무언가(Warp의 경우 GitHub Action, Oz, 번들로 제공되는 Python 스크립트)도 필요합니다.

"피드백은 많을수록 좋다." Warp의 입장은 품질 우선입니다. "에이전트가 다른 방법으로는 얻을 수 없었을 도메인 특정 지식에 대해 사람이 제공하는 매우 상세한 피드백이라면, 상대적으로 작은 샘플 크기에서도 정말 좋은 신호를 얻을 수 있습니다." 그리고 검증 불가능한 도메인의 경우 "도메인 전문가로 제한하고, 무분별하게 문을 열어두지 마세요."

"이것이 기록하는 행위를 대체한다." 이것은 기록하는 행위를 산업화합니다. 개선자의 모든 역할은 피드백을 지속 가능한 파일로 전환하는 것입니다.

Warp의 설정 외부에서 이를 모방하려고 할 때 두 가지 격차가 발생하며, 두 가지 모두 스킬보다는 코퍼스에 관한 것입니다.

첫 번째는 개선자가 도달할 수 있는 피드백에서만 작동할 수 있다는 점입니다. Warp의 피드백은 PR 댓글에 있는데, 그곳이 그들의 작업이 일어나는 공간이기 때문입니다. 만약 당신의 수정 사항이 Slack 스레드, 검토 회의, 그리고 누군가의 머릿속에 머물러 있다면, 예약된 작업이 가져올 수 있는 것이 아무것도 없습니다.

두 번째는 벤더 자체의 구분이 가리키는 지점입니다. 스킬은 절차를 담습니다. 스킬은 수정 사항에 보통 포함되는 사실들—왜 그 컨벤션이 존재하는지, 이미 무엇을 시도했는지, 어떤 제약 조건 때문에 뻔한 답이 틀렸는지 등—을 담기에는 부적절한 컨테이너입니다. Warp의 수정 예시에는 명명 컨벤션, 그것이 적용되는 카테고리, 그리고 그 이유라는 세 가지가 모두 포함되어 있습니다. 절차는 스킬로 들어갑니다. 하지만 이유는 갈 곳이 없습니다.

그것이 바로 MemoryLake가 담고 있는 것입니다. 에이전트가 쿼리하는 레이어에 프로젝트의 지속 가능한 사실들을 보관하므로, 절차적 지식과 사실적 지식이 동일한 파일을 두고 경쟁하는 것을 방지합니다. 설정은 세 단계로 이루어집니다.

1단계: API 키 생성

로그인하고 API 키를 생성합니다. 연결하는 도구 전반에 걸쳐 하나의 자격 증명만 사용됩니다.

2단계: 첫 번째 메모리 업로드

각각 하나의 주장만 담긴 짧은 항목들입니다. 이미 제공한 수정 사항들이 가장 좋은 소스 자료가 됩니다.

컨벤션과 그 이유. "전역 설정 값은 로더가 부팅 시 grep하기 때문에 CFG_ 접두사를 사용합니다." 규칙은 스킬에 보관할 수 있습니다. 이유는 규칙이 되돌려지는 것을 방지합니다.

이미 거부된 접근 방식. 어떤 스킬 파일이나 커밋 메시지에도 나타나지 않아 매 세션마다 새로 제안되는 카테고리입니다.

두 번 이상 제공한 수정 사항. 두 번 이상 말했다면, 그것은 해당 작업에 대한 선호도가 아니라 프로젝트에 대한 사실입니다.

아무도 알려주지 않는 환경적 제약. CI에서만 실패하는 테스트, 문서화되지 않은 속도 제한, 두 작업 간의 순서 의존성 등입니다.

3단계: AI 및 에이전트 연결

MemoryLake는 MCP 및 API를 통해 접근할 수 있으므로, Claude, Claude Code, Codex, OpenClaw를 포함한 MCP 네이티브 에이전트들은 MCP 서버를 가리켜 연결하고, 다른 어시스턴트들은 API를 통해 동일한 메모리를 읽습니다. 개선자 스타일의 작업은 변경을 제안하기 전에 컨텍스트를 위해 이를 쿼리할 수 있으며, 이는 정확히 Warp가 권장하는 온전성 검사(sanity-check)입니다.

세 가지 솔직한 한계가 있으며, 첫 번째가 여기서 가장 중요합니다. 이것은 루프의 대체재가 아닙니다. Anthropic의 구분은 양방향으로 작용합니다. 메모리 레이어는 절차를 담지 않으며, 스킬은 사실을 담지 않습니다. 에이전트가 작업을 더 잘 수행하도록 만들고 싶다면 루프를 구축하세요. Warp의 디자인은 훌륭하며 PR 검토 단계는 메모리 레이어가 가지지 못한 진정한 장점입니다. MemoryLake는 스킬 파일을 작성하지 않으며 에이전트의 실행을 들여다보지 않습니다. 그리고 오직 당신이나 에이전트가 입력한 내용만 보관하므로, 2단계는 의도적으로 수행되어야 합니다.

피드백이 일회용이 되지 않습니다. 댓글은 누군가 그냥 지나치는 메시지가 아니라 파일 수정이 됩니다.

개선 사항이 풀 리퀘스트(PR)로 도달합니다. 검토 가능하고, 되돌릴 수 있으며, 추적 가능합니다. 이는 대부분의 에이전트 튜닝이 제공하는 것 이상입니다.

"이유를 설명하는 것"이 업무 습관이 됩니다. 규칙이 아닌 원칙을 작성하라는 Warp의 조언은 그 이유가 기록될 때만 결실을 맺습니다.

개선자가 재사용 가능해집니다. Lloyd의 말에 따르면, "코드 리뷰 에이전트를 위한 개선자 스킬은 다른 에이전트를 위한 개선자 스킬과 크게 다르지 않습니다."

스킬은 의도적으로 작게 유지됩니다. 하나의 거대한 문서가 아니라 점진적 공개(progressive disclosure)와 번들 리소스 파일을 사용합니다. 이는 코딩 에이전트가 실제로 읽는 것에서 설명한 것과 동일한 압박입니다.

사실과 절차가 더 이상 싸우지 않습니다. 스킬은 방법을 말하고, 다른 무언가가 그 이유를 보관합니다.

기존의 검토 리추얼이 있는 도메인을 선택하세요. 코드 리뷰와 분류가 작동하는 이유는 이미 누군가가 살펴볼 예정이었기 때문입니다.

작업이 일어나는 곳에서 피드백을 캡처하세요. Warp의 규칙: "낮은 마찰력이 신호의 흐름을 유지합니다."

단순한 판정뿐만 아니라 이유를 요구하세요. 싫어요(thumbs-down) 버튼은 무엇을 변경해야 하는지 말해주지 않습니다. Warp 자체의 수정 예시는 한 문장 길이로 규칙, 카테고리, 이유를 모두 포함하고 있습니다.

개선자를 예약 실행하고, 작업당 실행하지 마세요. 단일 상호작용이 아니라 비교할 수 있는 코퍼스가 필요합니다.

병합 단계에 인간을 유지하세요. 이것이 전체 프로세스를 안전하게 실행할 수 있게 만드는 단계입니다.

일부 피드백은 틀릴 수 있다고 가정하세요. 누구의 입력이 유효한지 필터링하고 에이전트가 온전성 검사를 수행할 수 있는 컨텍스트를 제공하세요.

규칙이 아닌 원칙을 작성하세요. "컴퓨터를 프로그래밍하는 것이 아니라 똑똑한 사람에게 지시하는 것처럼 스킬을 구성하세요."

도메인이 허용한다면 검증 하네스(verification harness)를 먼저 구축하세요. 그런 다음 에이전트가 이에 맞춰 튜닝하도록 하세요.

스킬 파일에서 사실을 제외하세요. 절차는 안정적이고 의도적이지만, 사실은 누적되고 변화합니다. 가치가 낮은 사실들을 활성 상태로 유지하는 비용은 보존 점수 기반 메모리 트리가 보여준 것에서 측정됩니다.

Warp의 패턴은 최근 자가 개선 에이전트에 대해 발표된 내용 중 가장 실용적입니다. 그 이유는 적절한 부분에서 지루할 정도로 기본에 충실하기 때문입니다. 내부 스킬은 도메인 지식을 보유합니다. 외부 스킬은 일정에 따라 실행되어 누적된 인간의 피드백을 읽고, 에이전트가 제안한 내용과 인간이 실제로 원했던 내용을 비교한 다음, 내부 스킬을 수정하는 풀 리퀘스트를 엽니다. 사람이 이를 병합합니다. 다음 실행은 변경 사항을 상속받습니다.

이것이 신뢰할 수 있는 이유는 모델이 더 나아지는 것에 의존하지 않기 때문입니다. 스킬은 평문 파일이고, 에이전트는 평문 파일을 수정하는 데 능숙하며, 풀 리퀘스트에는 이미 검토 문화가 형성되어 있습니다. 다만 객관적으로 바라보아야 할 점은 전후 비교 수치가 발표되지 않았고, Warp가 대규모 피드백 코퍼스와 사내 스케줄러를 문제 해결에 동원했다는 점이며, 그들 자체 가이드에서도 피드백이 가끔 틀릴 수 있음을 가정하라고 조언한다는 점입니다.

그리고 기사가 FAQ 첫머리에서 강조한 구분을 기억하세요. 스킬은 절차적이고 안정적이며 의도적으로 변경됩니다. 메모리는 추론 시점에 작성되며 끊임없이 변화합니다. 피드백 루프는 에이전트가 작업을 더 잘 수행하도록 만듭니다. 프로젝트를 기억하게 만들지는 않습니다. 서로 다른 컨테이너에 두 가지 모두가 필요하며, 가장 빠르게 시작하는 방법은 다음 수정 사항에 그 이유를 포함하여 나중에 이를 읽는 무엇이든 보존할 가치가 있는 정보를 얻을 수 있도록 하는 것입니다.