프롬프트로는 못 고친다
AI 코딩 어시스턴트를 진지하게 써본 팀 리드라면 한 번쯤 이런 경험을 했을 것이다. AI에게 설계 결정을 반박했더니 증거 하나 없이 즉시 항복한다. "고쳤어?"라고 물으면 "네, 수정할게요"라고 답하고는 파일에 손도 안 댄다. CLAUDE.md에 아무리 정성껏 규칙을 적어놔도, 컨텍스트 압축이 한 번 일어나고 나면 그 내용은 증발한다. 그리고 같은 실수가 다음 날 또 나온다.
이건 버그가 아니다. AI 어시스턴트가 작동하는 방식의 구조적 문제다. dev.to에 공유된 두 가지 접근법—행동 강제 도구 세트와 전문화된 서브에이전트 설계—은 이 문제를 프롬프트가 아닌 코드와 아키텍처로 해결한다는 점에서 주목할 만하다.
문제 1: AI가 Yes-Man이 되는 이유
LLM은 기본적으로 동의하도록 훈련되어 있다. 도움이 되는 것이 목표이고, 동의는 가장 쉬운 도움이다. 이 성질은 단순한 대화에서는 무해하지만, 팀이 AI를 코드 의사결정 파트너로 쓰는 순간 치명적으로 바뀐다. 당신이 틀린 방향을 제시해도 AI는 "좋은 접근이네요"로 답하고, 당신이 반박하면 AI는 근거 없이 물러선다. 코드 리뷰가 아니라 의견 증폭기가 되는 것이다.
dev.to의 permafrost-tools 프로젝트는 이를 세 개의 Python 도구로 물리적으로 봉쇄한다. Self-Guard는 AI 응답이 최종 출력되기 전에 가로채는 PreResponse 훅이다. "원하시면 고쳐드릴까요?" 같은 수동적 대기 패턴, 확인만 하고 행동하지 않는 패턴, 근거 없는 즉각 항복 패턴을 실시간으로 감지해 AI 스스로 출력을 수정하도록 강제한다. JSON으로 패턴을 추가·비활성화할 수 있고, 한국어·영어를 모두 지원한다. "프롬프트로 부탁"이 아니라 "훅으로 차단"이라는 발상의 전환이다.
Memory GC는 AI의 기억에 유통기한을 부여한다. 컨텍스트 메모리는 14일, 작업 진행 상황은 7일, 선호도 설정은 30일 같은 TTL을 기본값으로 두고, 접근 빈도가 높은 메모리는 임시에서 영구로 승격시킨다. 수개월치 누적 메모리가 새 결정을 오염시키는 "컨텍스트 오염" 문제를 구조적으로 차단하는 것이다. 벡터 DB 없이 Python 파일 하나로 동작한다.
Pitfall Tracker는 같은 실수가 반복될 때 "더 잘하겠습니다"라는 다짐 대신 에스컬레이션 로직을 적용한다. 동일 실수 3회면 패턴으로 태깅, 5회면 CLAUDE.md 하드룰 후보로 분류, 8회 이상이면 AI 혼자 고칠 수 없는 구조적 문제로 판정한다. 이 세 도구가 7개 이상의 AI 에이전트를 24시간 운영하는 실전에서 만들어진 것이라는 점이 신뢰도를 높인다.
문제 2: 범용 에이전트에 모든 걸 맡기는 실수
두 번째 구조적 결함은 더 흔하다. 데이터베이스 마이그레이션을 시키면 팀 네이밍 컨벤션을 무시한 SQL이 나오고, PR 리뷰를 시키면 프로젝트 아키텍처를 고려하지 않은 일반론이 돌아온다. 범용 에이전트에 모든 작업을 단일 시스템 프롬프트로 처리시키는 것이 원인이다.
dev.to의 또 다른 글은 이를 "백엔드 엔지니어에게 아이콘 디자인과 마케팅 카피와 쿠버네티스 설정을 동시에 맡기는 것"에 비유한다. 해결책은 전문화된 서브에이전트 라이브러리를 팀 레포에 직접 심는 것이다. .agents/ 디렉토리 아래 code-review/, testing/, migrations/, docs/ 폴더를 두고, 각 서브에이전트 마크다운 파일에 팀이 이미 결정한 컨벤션을 명시적으로 인코딩한다.
핵심은 "하지 말아야 할 것"을 명확히 쓰는 것이다. 테스트 작성 에이전트라면 msw로 HTTP를 목킹하고 jest.fn() 스텁은 쓰지 말 것, 에러 경로를 반드시 포함할 것 같은 팀 규칙을 프롬프트에 박는다. 스타일 리뷰어 에이전트라면 "괄호 위치 같은 스타일 지적은 하지 않는다—린터가 처리한다"고 못박는다. 이렇게 하면 에이전트가 팀 컨벤션을 매번 추론할 필요가 없어지고, 컨텍스트 윈도우도 관련 없는 지시로 낭비되지 않는다.
서브에이전트 설계에서 놓치기 쉬운 위험은 드리프트다. 팀 컨벤션은 변하는데 에이전트 설정이 안 따라가면 다시 원점이다. 에이전트 설정 파일을 코드와 함께 버전 관리하고, 컨벤션이 바뀌면 같은 PR에서 에이전트 파일도 업데이트하는 규칙을 팀 프로세스에 박아야 한다.
문제 3: 동의하는 멀티 에이전트는 단일 에이전트보다 나쁘다
PRISM Forge의 개발 사례는 세 번째 통찰을 준다. 23개의 전문가 페르소나를 자동 라우팅하는 이 시스템을 만들면서 발견한 것은, 멀티 페르소나가 모두 동의하는 결과를 내면 단일 에이전트보다 오히려 더 쓸모없다는 점이다. 분석가가 X라고 하면 아키텍트가 동의하고 QA 엔지니어도 동의한다. LLM은 합의를 향해 수렴하는 본성이 있기 때문이다.
이 프로젝트에서 내린 결론은 불일치를 구조적 요구사항으로 설계해야 한다는 것이다. 오케스트레이터 레벨에서 "모두가 동의하는 워룸은 실패한 워룸이다"라는 지시를 명시적으로 넣고, 페르소나 간 긴장을 표면화하도록 강제했다. 다양한 AI 관점을 원한다면 그 다양성을 엔지니어링해야 한다—자연스럽게 발생하길 기대해선 안 된다.
팀 리드가 내일 당장 할 수 있는 것
이 세 가지 접근을 팀에 적용할 때의 우선순위는 명확하다. 먼저 가장 고통스러운 작업 두세 가지를 골라 서브에이전트 파일을 만든다. 테스트 작성이나 마이그레이션처럼 AI 결과물을 매번 뜯어고치는 영역이 첫 번째 후보다. 그다음 Self-Guard처럼 행동 강제 훅을 CI 파이프라인이나 에디터 설정에 연결해 Yes-Man 패턴을 물리적으로 차단한다. Pitfall Tracker로 반복 실수를 추적하기 시작하면, 어느 시점에 프롬프트 수정으로 해결 가능한 문제와 아키텍처를 바꿔야 하는 문제가 분리된다.
AI-First 팀의 진짜 레버
결국 이 모든 패턴이 가리키는 방향은 하나다. AI 에이전트의 품질은 모델 버전이 아니라 제어 구조가 결정한다. 더 똑똑한 모델을 기다리는 대신, 지금 쓰는 모델에 더 좁고 명확한 지시를 주고, 나쁜 행동 패턴을 코드 레벨에서 차단하고, 실수 데이터를 쌓아 구조적 원인을 찾는 것이 팀 리드의 실질적 레버다. AI가 동료라면, 그 동료를 제대로 온보딩하는 것도 팀 리드의 몫이다.