에이전트는 왜 같은 일을 반복하는가
Claude Code든 Cursor든, 코딩 에이전트를 며칠만 써보면 불편한 패턴이 눈에 들어온다. 어제 세션에서 42/42 테스트를 통과시킨 인증 모듈을, 오늘 아침 새 세션의 에이전트가 다시 읽고, 다시 돌리고, 같은 결론을 내린다. 수천 토큰을 써서 이미 존재하는 상태를 재발견하는 것이다. 멀티 에이전트 파이프라인에서 파일 수와 세션 수를 곱하면, 이 낭비는 순식간에 청구서로 돌아온다.
문제의 본질은 간단하다. 에이전트에게는 '이미 검증된 것'을 기억하는 메모리가 없다. 모든 세션이 백지에서 시작한다. dev.to에 공유된 AKF(Artifact Knowledge Format) 사례는 이 문제를 정면으로 겨냥한다. 핵심 아이디어는 파일에 ~15토큰짜리 JSON 스탬프를 붙이는 것이다. 스탬프를 한 번 찍는 비용이 15토큰이라면, 재검증 비용은 15,000토큰이다. 1,000배 차이다.
신뢰는 이진법이 아니다—설계해야 할 세 가지 레이어
AKF가 흥미로운 이유는 단순한 캐싱이 아니라 신뢰를 점수로 모델링하기 때문이다. '에이전트가 생성했다'는 스탬프만으로는 신뢰 점수가 낮다(0.21). 테스트 통과 증거가 붙으면 올라가고(0.65), 사람이 리뷰하면 더 올라간다. 파일이 스탬프 이후 수정되면 자동으로 STALE 처리되고, 오래된 메모리 파일은 시간이 지날수록 신뢰 점수가 감쇠한다.
이 구조가 팀 입장에서 실용적인 이유가 있다. 에이전트가 생성한 코드를 '믿을 수 있는가'의 판단 기준을 팀이 명시적으로 설계하게 만든다는 것이다. 벤더 벤치마크에 기대는 대신, 우리 코드베이스에서 어떤 증거가 쌓였을 때 재검증을 스킵할 수 있는지를 구조로 정의한다. git post-commit 훅과 Claude Code 훅으로 자동 스탬핑을 붙이면 사람이 매번 개입하지 않아도 된다.
물론 한계도 솔직하게 짚어야 한다. 스탬프는 증명이 아니라 주장이다. 개발자가 커밋 메시지를 거짓으로 쓸 수 있듯, 에이전트도 스탬프를 잘못 찍을 수 있다. 현재 staleness 체크가 mtime 기반이라 git checkout 시 오탐이 발생하는 것도 알려진 문제다. 하지만 '완벽한 구조가 없으면 아무것도 하지 않는다'는 접근보다, 불완전하더라도 재검증 비용을 구조적으로 줄이는 설계를 지금 시작하는 것이 현실적이다.
생성은 쉽고 증명은 어렵다—해커톤이 드러낸 AI 코딩의 진짜 문제
Port Mortem 2026은 이 문제를 다른 각도에서 조명한다. Hackathon Raptors가 주최하는 72시간 온라인 해커톤으로, C→Rust, TypeScript→Go, Python→Rust 등 실제 오픈소스 프로젝트를 다른 언어로 포팅하는 것이 미션이다. 그런데 평가 기준이 독특하다. 코드를 얼마나 많이 생성했느냐가 아니라, 포팅된 코드가 원본과 동일하게 동작함을 증명할 수 있느냐를 40%(기능/신뢰성)와 30%(행동 동등성)로 나눠 채점한다.
AI 코딩 어시스턴트 사용은 허용된다. GitHub Copilot, Cursor, Claude Code, Aider 모두 쓸 수 있다. 하지만 AI가 생성한 코드만으로는 수상할 수 없다. 팀은 원본 테스트 스위트 호환성, 동시성 시맨틱 보존, 성능 특성 유지, 관용적 구현 방식을 모두 문서화해야 한다. 이 해커톤이 던지는 메시지는 명확하다. 코드 생성 속도는 이미 해결된 문제다. 다음 병목은 검증이다.
반복 업무를 스킵하는 세 번째 방법: 워크플로우를 스킬로 인코딩하라
검증 반복 외에 또 다른 형태의 낭비가 있다. 매주 같은 업무를 처음부터 다시 만드는 것이다. dev.to에 공개된 agencykit 사례는 창의 에이전시가 매주 반복하던 8개 워크플로우—프로젝트 브리프 작성, 클라이언트 승인 요청, 월간 보고서, 견적서, 촬영 패키지, 소셜 캘린더, 사후 검토, 상태 업데이트—를 Claude Agent Skills로 인코딩한 사례다.
기술적으로 흥미로운 지점은 client-approval 스킬이 대화 내 리비전 횟수를 외부 데이터베이스 없이 프롬프트 사이드에서만 추적한다는 것이다. 리비전 3회 이상이면 자동으로 추가 청구 플래그가 붙는다. 계약서에는 명시된 규칙인데 아무도 실제로 집행하지 않던 것을, 에이전트 구조로 강제한 것이다. 규칙을 기억하는 부담을 사람에서 구조로 이전한 사례다.
지금 팀이 설계해야 할 것
세 사례를 묶으면 하나의 설계 원칙이 도출된다. 에이전트가 반복하는 모든 것은 팀이 구조화할 기회다.
- 검증 반복: 이미 통과한 테스트를 다시 돌리는 에이전트를 보고 있다면, 검증 결과를 파일에 스탬핑하는 구조를 지금 붙여라. AKF처럼 정교할 필요도 없다. VERIFIED.json 하나로 시작해도 된다.
- 행동 동등성 증명: AI가 생성한 코드를 '동작하는 것'으로 넘기는 팀이라면, Port Mortem이 요구하는 기준—원본 테스트 스위트 호환성, 차분 테스팅, 벤치마크—을 내부 코드 리뷰 체크리스트에 이식하는 것을 고민해라.
- 워크플로우 반복: 에이전트가 매번 같은 질문을 받고 같은 형식의 산출물을 만든다면, 그 패턴은 스킬 파일로 인코딩될 수 있다. agencykit처럼 SKILL.md 하나로 시작할 수 있다.
전망: 에이전트 효율화의 다음 단계
지금 당장 팀에서 실행 가능한 순서로 보면, 워크플로우 스킬화가 가장 진입 장벽이 낮다. SKILL.md 파일을 .claude/skills/에 넣는 것은 오늘 오후에 시작할 수 있다. 검증 캐싱은 git 훅 설정이 필요하지만 일주일 안에 붙일 수 있다. 행동 동등성 증명은 테스트 인프라와 문서화 기준을 팀 전체가 합의해야 하므로 가장 시간이 걸린다.
하지만 순서는 중요하다. 에이전트가 생성하는 코드의 양이 늘수록, 그 코드가 실제로 올바른지를 증명하는 비용도 함께 올라간다. 지금 검증 구조를 설계하지 않으면, 에이전트는 더 빠른 코드 생성기가 아니라 더 빠른 검증 부채 생성기가 된다. 속도를 얻으려면 반복을 없애는 구조를 먼저 설계해야 한다.