에이전트의 성장은 스킬 수가 아니라 학습 파이프라인에서 결정된다

에이전트를 많이 붙인다고 조직이 자동으로 똑똑해지지는 않는다. 실행 경험을 보존하고, 반복되는 실패를 정리하고, 검증된 변화만 다시 실행층에 돌려보내는 구조가 있어야 성능이 누적된다.

TL;DR

에이전트 운영의 병목은 모델 호출 수보다 경험을 재사용하는 구조에 있다.
실행 기록, 지식, runtime skill을 분리하면 실패한 개선안을 추적하고 되돌릴 수 있다.
스킬 변경은 느낌이 아니라 고정된 대표 태스크의 성공률·비용·재시도율로 채택해야 한다.

왜 지금 중요한가

에이전트가 개인의 실험 도구를 넘어 팀의 일상 업무로 들어오고 있다. GeekNews가 소개한 Uber 사례는 로컬·클라우드 에이전트가 개발 과정의 상당 부분을 맡고, 수천 개의 스킬이 반복 실행되는 운영 규모를 보여준다. 숫자 자체는 원문 보도에 기반한 수치지만 방향은 분명하다. 에이전트가 많아질수록 “새 스킬 하나 추가”보다 “어떤 경험을 시스템에 남길 것인가”가 중요해진다.

핵심 흐름

1. 실행 기록은 원본으로 남긴다

입력, 도구 호출, 결과, 실패, 사용자 수정, 검증 점수를 원본 그대로 보존한다. 나중에 지침을 고치더라도 당시 무슨 일이 있었는지 다시 볼 수 있어야 한다.

2. 반복 패턴은 지식으로 정리한다

여러 실행에서 반복된 실패와 성공 전략을 별도의 지식층에 기록한다. 이 층은 답을 직접 제공하는 치트시트가 아니라, 다음 스킬을 설계할 때 참고하는 변경 이력이다.

3. 검증된 패턴만 실행 스킬로 승격한다

지식층의 모든 문장을 실행 지침으로 만들면 품질이 흔들릴 수 있다. 대표 태스크를 고정하고 변경 전후의 성공률, 비용, 재시도율을 비교한 뒤 통과한 패턴만 runtime skill로 승격한다.

실행 → 원본 기록 → 패턴 정리 → 평가셋 검증 → 스킬 승격
  ↑                                      ↓
  └──────────── 실패·롤백·새 실행 ──────┘

실제 사례 / 신호

Uber 규모의 소프트웨어 팩토리를 효율적으로 운영하는 법은 에이전트가 개발 전 과정에 들어오면서 스킬 실행량과 사용량이 커지는 사례를 소개한다. 이 정도 규모에서는 개인의 기억이나 대화 기록만으로 운영하기 어렵다.

오늘 수집된 WikiSkill 관련 게시물도 원본 기록·지식·스킬을 분리하는 구조를 강조한다. 게시물에 인용된 벤치마크 수치는 원 논문을 직접 확인하기 전까지 source-reported로 봐야 한다. 다만 “스킬을 고치는 과정 자체를 기록해야 한다”는 설계 원칙은 독립적으로 실험할 수 있다.

실전 활용 팁: 작은 평가셋부터 고정한다

다음 순서로 시작한다.

자주 반복되는 태스크 10개를 고른다.
각 태스크에 성공 조건과 export 형식을 적는다.
현재 스킬로 실행한 결과와 비용을 저장한다.
스킬을 한 가지씩 바꾸고 같은 평가셋을 다시 실행한다.
점수가 오르고 비용·재시도율이 허용 범위면 승격한다.
실패한 변경도 diff와 사유를 남기고 되돌린다.

핵심은 평가셋을 거창하게 만드는 일이 아니다. 다음 주에도 같은 기준으로 비교할 수 있게 만드는 일이다.

바로 해볼 실험

1~3일 안에 다음 미니 하네스를 만들 수 있다.

입력: SQL 스키마 또는 업무 요청
출력: 결과 파일, 경고 목록, 검증 점수
기록: 원문 입력, 생성 결과, 사용자 수정, 소요 시간, 토큰 비용
판정: 대표 태스크 10개 중 통과한 경우에만 지침 변경을 채택

ERD 생성기처럼 결과의 정확성과 export 품질을 함께 봐야 하는 도구라면 특히 유용하다. 한 번 생성하고 끝내지 말고, 관계 추론이 틀린 사례와 사용자가 고친 결과를 다음 검증 케이스로 남긴다.

리스크 / 반론

스킬 수와 실행량이 많다고 실제 생산성이 높다고 단정할 수 없다. 재작업과 장애 비용을 함께 측정해야 한다.
지식과 스킬을 분리해도 평가셋이 나쁘면 잘못된 개선을 채택할 수 있다.
모델별로 잘 작동하는 지침이 다르므로 다른 모델에 스킬을 복사할 때 계약 테스트가 필요하다.
원본 기록에는 민감한 입력이 포함될 수 있으므로 보존 범위와 접근 권한을 먼저 정해야 한다.

결론

에이전트의 경쟁력은 보유한 스킬 개수가 아니라 실행 경험을 안전하게 학습 자산으로 바꾸는 속도에서 나온다. 새 기능을 추가하기 전에 최근 실패 10건부터 원본 기록과 평가 케이스로 남겨보자.

다음 에이전트 작업에서 먼저 물어볼 질문은 이것이다. 이 결과는 다시 실행할 수 있고, 실패했을 때 무엇을 고쳐야 하는지 남아 있는가?