블로그코딩 에이전트4분 읽기

워프의 에이전트가 사람 피드백을 모아 자기 스킬을 고쳐쓰고 있습니다

워프는 사람 피드백을 모아 에이전트가 자기 스킬 수정 PR을 올리게 했습니다.

워프의 에이전트가 사람 피드백을 모아 자기 스킬을 고쳐쓰고 있습니다 대표 이미지

에이전트가 PR 리뷰를 마쳤습니다. 담당자가 라벨을 고쳐 달았습니다. 일주일 뒤 임프루버 에이전트가 그 고침을 스킬 수정 PR로 올려뒀습니다.

워프는 이 구조를 코드 리뷰·스펙 작성·이슈 트리아지 세 업무에 이미 씁니다. 사람들은 소개 트윗을 6.8만 번 넘게 봤고, 워프 CEO 잭 로이드도 아티클을 X에 직접 올렸습니다.

출발점은 무엇인가요?

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

워프는 사람에게 새 일을 하나도 시키지 않았어요. 학습용 데이터를 따로 만들라거나, 평가 양식을 채우라거나 하지 않습니다. 사람이 원래 하던 리뷰를 그대로 원료로 씁니다.

워프가 손을 대는 건 그다음이에요. 이 피드백을 흘려보내지 않고 모아 둡니다. 다른 에이전트가 읽을 원료로요.

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

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

한 번 틀린 건 넘어가고, 자꾸 틀리는 부분만 짚습니다. 일회성 실수와 구조 결함을 구분하는 일을 에이전트에게 맡겼어요.

찾은 뒤에도 임프루버는 크게 손대지 않습니다. 원래 스킬에 작은 수정 하나만 제안해요.

반복되는 실수 하나에 작은 수정 하나. 워프는 수정을 일부러 작게 잡았습니다. 작아야 사람이 읽고 판단할 수 있고, 틀렸을 때 되돌리기도 쉬우니까요.

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

저는 이 부분을 설계의 핵심으로 봅니다. 임프루버는 제안을 곧장 깃 PR로 올리고, 사람이 리뷰하고 머지해야만 스킬에 반영됩니다. 머지가 끝나면 다음 작업부터 에이전트가 그 경험을 갖고 일해요.

에이전트가 배운 내용도 코드처럼 리뷰를 거칩니다. 무엇을 바꾸는지 diff로 보고, 언제 왜 바꿨는지 커밋 기록으로 확인하고, 마음에 안 들면 리버트하면 돼요.

에이전트 메모리를 다루는 흔한 방식과 비교해 보면 이렇습니다. 많은 시스템이 학습한 내용을 내부 어딘가에 보이지 않게 저장해요. 무엇을 배웠는지 사람이 들여다볼 수 없고, 잘못 배운 걸 골라 지울 수도 없습니다.

워프는 학습을 버전 관리 대상으로 끌어냈습니다. 에이전트가 배운 내용은 전부 텍스트 파일로 남아서 사람이 리뷰하고 통제할 수 있어요.

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

워프는 새 인프라도 깔지 않았어요. 깃, PR, 리뷰, 머지. 개발팀이 십수 년 다듬어 온 관문을 그대로 재활용합니다. 학습 파이프라인을 새로 짓는 대신, 이미 있는 신뢰 장치에 학습을 태운 거죠.

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

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

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

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

피드백이 모여야 루프가 도니까, 워프는 피드백이 자주 생기는 업무부터 골랐어요. 어디에나 통하는 만능 구조라고 선전하는 대신, 통할 업무를 골라 먼저 적용했다는 점이 실전답습니다.

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

에이전트를 개선하는 기존 방법 둘과 나란히 놓으면 워프가 어느 쪽을 택했는지 보입니다.

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

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

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

남는 생각

저는 워프가 승인선을 옮겼다는 점을 이 구조에서 가장 큰 뉴스로 봅니다.

지금까지 팀들은 PR 리뷰로 코드를 통제했습니다. 워프는 PR 리뷰로 에이전트 학습까지 통제합니다.

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

에이전트를 부리는 사람은 앞으로 다른 능력을 더 많이 쓰게 됩니다. 지시문을 잘 쓰는 능력보다 에이전트가 올린 수정 제안을 판독하는 능력이에요.

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

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

저는 이 리뷰를 앞으로 에이전트 운영의 본 업무로 봅니다.


원문·소스

FAQ

자주 묻는 질문

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

SEASON 3

시즌3 「콘텐츠로 팔기」

AI와 콘텐츠를 만들고 고객에게 연결하는 4주

제가 에이전트로 조사하고 쓰고 파는 과정을 그대로 보여 드려요. 그다음 각자의 주제로 같이 만들어 봐요.

10월 2일 OT · 10월 5일부터 월·수 4주 · 10월 31일 오프라인

시즌3 커리큘럼 보기