에이전트를 켜는 것은 쉽다. 문제는 그다음이다. Claude Code든 Cursor든, 도구를 붙인 순간부터 진짜 설계 과제가 시작된다. 최근 dev.to에 올라온 세 편의 글이 각각 다른 각도에서 같은 질문을 다루고 있다. AI 코딩 도구를 실무에 붙인 뒤, 품질을 어떻게 유지할 것인가.
에이전트는 명세가 있어야 일을 한다
첫 번째 글은 DataCamp 개발자가 육아 중 Claude Code를 운영하며 쌓은 경험이다. 핵심은 단순하다. 에이전트는 "잘 만들어줘"라는 요청을 받으면 제품의 방향, 제약, 완료 기준을 동시에 추론해야 한다. 그 추론 비용이 고스란히 품질 저하로 이어진다.
그가 만든 Harness 워크플로우는 이 문제를 정면으로 해결한다. /ideate → /product-plan → /dev-plan으로 이어지는 흐름에서, 코드 한 줄 쓰기 전에 이미 아이디어 검증, 포지셔닝, 아키텍처 결정, 기능별 수용 기준이 문서로 확정된다. 에이전트가 받는 것은 "구현하라"가 아니라 "이 수용 기준을 통과하는 결과물을 만들어라"다.
차이는 작아 보이지만 결과는 크게 갈린다. 그가 제시한 예시처럼, "SP-404 팩 내보내기 흐름을 구현하라—샘플은 최대 16개, 하드웨어 프로파일 명명 규칙을 따라야 하며, 소스 샘플을 변경하지 않아야 한다. 잘못된 팩은 파일이 쓰이기 전에 명확한 오류를 보여야 한다"는 스펙은 에이전트가 검증 가능한 결과물을 생성하게 만든다. 모호한 요청이 줄어들면 에이전트의 추론 부담이 줄고, 리뷰어가 볼 차이도 명확해진다. /qa 단계에서 curl, Playwright 같은 도구로 수용 기준 자체를 검증하는 구조는 이 흐름의 자연스러운 완성이다.
실패는 한 번에 오지 않는다, 서서히 밀려온다
두 번째 글은 더 근본적인 문제를 짚는다. AI 작업은 한 번에 망가지지 않는다. 드리프트(drift)한다. 테스트가 한 시간째 실패하는데 에이전트는 계속 다음 시도를 한다. 요구사항이 조금씩 초점을 잃는다. 범위가 소리 없이 늘어난다. 같은 결정이 다시 내려진다. 세션 로그만 보면 에이전트는 바쁘고, 파일은 바뀌고, 커밋은 쌓인다. 그러나 실제 전진은 없다.
저자는 이 현상을 제조업의 안돈(Andon) 시스템에 빗댄다. 안돈은 생산 라인에서 문제가 생기는 순간, 교대 끝이 아니라 지금 당장 신호를 보낸다. AI 작업도 마찬가지 감시 레이어가 필요하다는 주장이다. 반복 편집, 결정 번복, 같은 컨텍스트를 계속 다시 요청하는 패턴—이것들은 노이즈가 아니라 드리프트 신호다.
그가 개발 중인 Holistic + Andon 조합은 이 신호를 실시간으로 감지하는 시도다. 아직 실험적이지만 방향은 명확하다. "어제 세션에서 뭐가 잘못됐는지" 사후 분석도 필요하지만, 그것만으로는 부족하다. 드리프트는 회수 불가능해지기 전에 잡아야 한다. Microsoft의 AI Engineering Coach가 세션 후 패턴을 분석하는 것과 달리, 실시간 감시는 문제가 아직 회복 가능할 때 개입할 수 있게 한다. 이 차이가 낭비를 막는다.
실패를 기록하지 않으면, 에이전트는 같은 실수를 반복한다
세 번째 글은 가장 실천적인 레이어를 다룬다. SKILL.md와 함께 PITFALLS.md를 쌍으로 두라는 제안이다. 구조는 단순하다. SKILL.md는 무엇을 해야 하는지를 담고, PITFALLS.md는 무엇을 하면 안 되는지를 담는다. 각 항목은 트리거, 잘못된 행동, 올바른 행동의 세 부분으로 구성된다.
왜 분리하는가. SKILL.md에 모든 예외를 쑤셔 넣으면 문서가 노이즈로 가득 차고, 에이전트가 핵심 흐름을 읽는 데 방해가 된다. 분리하면 해피 패스는 짧고 명확하게, 실패 지식은 축적 가능하게 유지된다. Anthropic 내부 스킬 제작자들도 이 실패 기록 섹션을 "스킬 내에서 신호 밀도가 가장 높은 콘텐츠"라고 부른다.
핵심은 "추가만 하고 삭제하지 않는다"는 원칙이다. 해결된 실패도 스킬 업데이트 후 재발할 수 있다. 세션이 끝날 때마다 에이전트가 틀렸던 것을 한 항목씩 기록하면, 다음 세션의 에이전트는 이전에 가르친 것을 다시 가르칠 필요 없이 시작한다. 이것은 단순한 메모가 아니라 에이전트의 제도적 기억이다.
세 설계를 하나의 흐름으로 읽어야 한다
이 세 편의 글은 각각 독립적이지만, 함께 읽으면 AI 에이전트 워크플로우의 품질 유지 구조가 드러난다. 스펙 설계가 실행 품질의 천장을 결정하고, 드리프트 감지가 진행 중인 낭비를 차단하며, 실패 기록이 다음 실행의 바닥을 높인다. 이 세 레이어 중 하나라도 빠지면 루프가 끊긴다.
빠른 프로토타이핑이 가능해진 지금, 병목은 생성 속도가 아니다. 생성된 결과물이 의도와 얼마나 일치하는지 확인하는 속도, 드리프트를 조기에 포착하는 능력, 그리고 실패 지식을 세션 간에 유지하는 구조가 실제 개발 속도를 결정한다.
에이전트 품질 설계의 다음 단계
세 글이 가리키는 방향은 하나다. 에이전트 워크플로우의 성숙도는 도구 선택이 아니라 실행 후 설계로 측정된다. 어떤 스펙 형식을 쓸지, 드리프트 신호를 어떤 기준으로 정의할지, 실패 기록을 언제 세션 루틴으로 만들지—이 결정들이 쌓이면서 워크플로우가 단단해진다.
당장 할 수 있는 가장 작은 시작은 다음 기능을 구현하기 전에 수용 기준 세 줄을 먼저 쓰는 것이다. 그리고 에이전트가 틀렸을 때, 그것을 대화창이 아닌 파일에 기록하는 것이다. 이 두 습관이 자리를 잡으면, 드리프트 감지는 그 다음 자연스러운 질문이 된다.