블로그5분 읽기

워프가 자기 스킬을 스스로 고치는 에이전트를 실전에 씁니다

에이전트가 일하고, 사람이 피드백을 남기고, 그 피드백으로 스킬이 고쳐지는 자기진화 루프를 워프가 코드 리뷰·스펙 작성·이슈 트리아지 세 가지 업무에 이미 씁니다.

워프는 자기 스킬을 스스로 고치는 에이전트를 이미 실전에 씁니다. 에이전트가 일하고, 사람이 피드백을 남기고, 그 피드백으로 에이전트 스킬 자체가 고쳐지는 루프예요.

클로드가 글을 올려 추천한 방식이고, 이 구조를 소개한 트윗 하나가 조회 6.8만을 넘겼습니다. 워프 CEO 잭 로이드도 같은 방식을 정리한 아티클을 X에 직접 올렸어요.

이름을 붙이자면 "자기진화 에이전트"입니다.

말만 들으면 흔한 자동화 구호 같지만, 뜯어보면 설계가 꽤 절제돼 있습니다. 어디가 절제됐는지, 순서대로 따라가 보겠습니다.

출발점은 무엇인가요?

평범한 피드백입니다. 에이전트가 일을 마칠 때마다 사람은 평소처럼 피드백을 남겨요. 잘했다, 여기가 틀렸다, 이건 다시 해라. 특별한 절차가 아닙니다.

사람에게 새로 시키는 일이 없다는 점이 중요합니다. 학습용 데이터를 따로 만들라거나, 평가 양식을 채우라거나 하지 않아요. 원래 하던 리뷰가 그대로 원료가 됩니다.

바뀌는 건 그다음이에요. 이 피드백이 그냥 흘러가지 않고 차곡차곡 쌓입니다. 다른 에이전트가 읽을 원료로요.

임프루버 에이전트는 무엇을 하나요?

개선 전담 에이전트, 임프루버가 등장합니다. 임프루버는 쌓인 피드백을 주기별로 꺼내 읽고, 원래 에이전트가 어디서 반복해서 틀리는지 찾아요.

한 번 틀린 건 넘어가고, 자꾸 틀리는 자리를 짚는 겁니다. 일회성 실수와 구조 결함을 구분하는 눈을 사람이 아니라 에이전트에게 맡긴 셈이에요.

찾은 다음 동작이 절제돼 있습니다. 스킬을 통째로 갈아엎는 게 아니라, 원래 스킬에 작은 수정 하나를 제안해요.

반복되는 실수 하나에 작은 수정 하나. 이 보폭이 이 구조를 지탱합니다. 수정이 작아야 사람이 읽고 판단할 수 있고, 틀렸을 때 되돌리기도 쉬우니까요.

수정은 어떻게 반영되나요?

여기가 이 설계에서 핵심입니다. 임프루버가 낸 제안은 곧장 깃 PR로 올라가고, 사람이 리뷰하고 머지해야만 반영됩니다. 머지가 끝나면 다음 작업부터 에이전트가 그 경험을 갖고 일해요.

에이전트 학습이 코드와 똑같은 관문을 통과하는 겁니다. 무엇이 바뀌는지 diff로 보이고, 언제 왜 바뀌었는지 커밋 기록에 남고, 마음에 안 들면 리버트하면 돼요.

에이전트 메모리를 다루는 흔한 방식과 대비하면 차이가 선명합니다. 많은 시스템이 학습한 내용을 내부 어딘가에 불투명하게 쌓아요. 무엇을 배웠는지 사람이 들여다볼 수 없고, 잘못 배운 걸 골라 지울 수도 없습니다.

이 구조는 학습을 버전 관리 대상으로 끌어냈습니다. 에이전트가 배운 모든 것이 텍스트 파일이고, 파일이니까 리뷰가 되고, 리뷰가 되니까 통제가 됩니다.

팀 차원에서도 이득이 있어요. 한 사람이 남긴 피드백이 스킬 수정으로 머지되면, 그 경험이 그 사람 머릿속이 아니라 팀 전체가 쓰는 에이전트에 남습니다. 개인 노하우가 조직 자산으로 바뀌는 경로예요.

새 인프라를 깔 필요가 없다는 점도 눈에 들어옵니다. 깃, PR, 리뷰, 머지. 개발팀이 십수 년 다듬어 온 관문을 그대로 재활용해요. 학습 파이프라인을 새로 짓는 대신, 이미 있는 신뢰 장치에 학습을 태운 겁니다.

워프는 이 구조를 어디에 쓰나요?

실험이 아니라 실전입니다. 워프는 이 구조를 이미 세 가지 업무에 써요. 코드 리뷰, 스펙 작성, 깃허브 이슈 트리아지입니다.

셋을 나란히 놓으면 공통점이 보입니다. 반복이 잦고, 매번 사람 피드백이 자연스럽게 발생하는 업무들이에요.

이슈 트리아지를 생각해 보면 감이 옵니다. 분류가 틀리면 담당자가 라벨을 고쳐 달고, 그 정정 자체가 피드백으로 쌓여요. 임프루버가 패턴을 찾을 원료가 매일 생산되는 자리입니다.

피드백이 쌓여야 루프가 도니까, 루프가 돌기 좋은 자리부터 깐 거예요. 어디에나 통하는 만능 구조라고 선전하는 대신, 통할 자리를 골라 붙였다는 점에서 실전 냄새가 납니다.

파인튜닝이나 프롬프트 손질과는 뭐가 다른가요?

에이전트를 개선하는 기존 방법 둘과 나란히 놓으면 이 구조가 고른 자리가 보입니다.

한쪽 끝에 파인튜닝이 있습니다. 모델 가중치를 다시 굽는 방식인데, 비용이 크고, 무엇이 어떻게 달라졌는지 사람이 읽을 수 없어요. 되돌리기도 어렵습니다.

반대쪽 끝에 수동 프롬프트 손질이 있어요. 에이전트가 틀릴 때마다 사람이 지시문을 고치는 방식인데, 읽을 수는 있지만 사람 손이 병목입니다. 실수를 모아 패턴을 찾는 일은 아무도 안 하게 돼요.

워프 방식은 그 사이에 섭니다. 패턴 찾기와 수정안 작성은 에이전트가 맡아 병목을 풀고, 최종 반영은 사람이 쥐어 가독성과 가역성을 지켰어요. 양쪽 단점을 하나씩 잘라낸 배치입니다.

남는 생각

저는 승인선 위치가 바뀐 게 이 구조에서 진짜 뉴스라고 봅니다.

지금까지 PR 리뷰는 코드를 통제하는 장치였습니다. 여기선 에이전트 학습을 통제하는 장치가 됐어요.

사람이 에이전트 프롬프트를 한 줄 한 줄 고치지 않아도, 머지 버튼 하나로 에이전트가 배우는 방향을 쥡니다. 가르치는 노동은 에이전트가 하고, 사람은 가르침을 승인하는 자리로 올라간 거예요.

에이전트를 부리는 쪽에서 보면 일 자체가 달라진다는 뜻이기도 합니다. 지시문을 잘 쓰는 능력에서, 에이전트가 올린 수정 제안을 판독하는 능력으로 무게가 옮겨가요.

이 판독이 만만치 않을 겁니다. "이 수정을 머지하면 에이전트가 앞으로 어떻게 달라지는가"를 읽어야 하니까, 코드 리뷰보다 한 층 추상도가 높은 리뷰예요.

그래도 방향은 맞다고 봅니다. 에이전트가 똑똑해질수록 사람이 쥐어야 할 건 작업 하나하나가 아니라 학습 경로고, 학습 경로를 쥐는 가장 검증된 도구가 지금으로선 PR 리뷰니까요.

저는 이 리뷰 자리가 앞으로 에이전트 운영에서 본 업무가 된다고 봅니다.


원문·소스

FAQ

자주 묻는 질문

출발점은 무엇인가요?
에이전트가 일을 마칠 때마다 사람이 평소처럼 남기는 피드백입니다. 학습용 데이터를 따로 만들지 않고, 원래 하던 리뷰가 그대로 원료로 쌓입니다.
임프루버 에이전트는 무엇을 하나요?
쌓인 피드백을 주기별로 꺼내 읽고, 원래 에이전트가 반복해서 틀리는 자리를 찾습니다. 그리고 스킬을 갈아엎는 대신 원래 스킬에 작은 수정 하나를 제안합니다.
수정은 어떻게 반영되나요?
임프루버의 제안은 곧장 깃 PR로 올라가고, 사람이 리뷰하고 머지해야만 반영됩니다. 무엇이 바뀌는지 diff로 보이고, 커밋 기록에 남고, 마음에 안 들면 리버트하면 됩니다.
워프는 이 구조를 어디에 쓰나요?
코드 리뷰, 스펙 작성, 깃허브 이슈 트리아지 세 가지 업무에 이미 씁니다. 셋 다 반복이 잦고 매번 사람 피드백이 자연스럽게 발생하는 자리입니다.
파인튜닝이나 프롬프트 손질과는 뭐가 다른가요?
파인튜닝은 비용이 크고 사람이 읽을 수 없으며 되돌리기 어렵고, 수동 프롬프트 손질은 사람 손이 병목입니다. 워프 방식은 패턴 찾기와 수정안 작성을 에이전트에 맡기고 최종 반영만 사람이 쥐어 양쪽 단점을 하나씩 잘라냈습니다.