내 에이전트가 저녁 한때에 3개의 PR을 완료했습니다. 내 메시지의 40%는 수정 요청이었습니다.
나의 AI 기반 코딩 에이전트가 단 하룻밤 사이에 3개의 풀 리퀘스트(PR)를 푸시했지만, 내가 보낸 30개의 메시지 중 40%는 수정 요청이었습니다.
이번 세션을 통해 MCP client, Azure AI Agent, 그리고 M365 Copilot Agent가 생성되었습니다. 자동화된 체크를 통해 세 개의 PR 모두 통과되었으며, 나는 코드 한 줄도 직접 수정하지 않았습니다. 하지만 대화 기록은 다른 이야기를 들려줍니다. 총 710개의 메시지 중 내가 입력한 것은 30개였고, 그중 12개는 에이전트가 올바른 방향으로 가도록 유도하는 것이었습니다. 수정 요청이 차지하는 비중인 '스티어링 비율(steering rate)'은 40%에 달했습니다.
파이프라인 구성 방식
- Claude가 상위 수준의 구현 계획을 초안했습니다.
- DeepSeek V4-Flash가 오케스트레이터 역할을 수행하며 계획을 검토했습니다.
- Codex가 실제 코드를 생성했습니다.
- 오케스트레이터가 코드를 검사하고 풀 리퀘스트를 생성했습니다.
오케스트레이터의 의도된 역할은 순수하게 연결하는 것이었습니다. 즉, 코드를 직접 작성하는 것이 아니라 구성 요소 간의 충돌을 해결하는 것이어야 했습니다. 실제로 에이전트는 약 40분 만에 세 개의 PR에 걸쳐 3,500줄의 코드를 생성했지만, 두 가지 반복적인 오류 유형에서 실수를 범했습니다.
두 가지 오류 유형
- 워크플로우 위반(Workflow violations) – 오케스트레이터가 가끔 '연결(glue)' 역할을 무시하고 코딩 단계를 가로채 구현 세부 사항을 직접 작성했습니다.
- 컨텍스트 검색 실패(Context-retrieval failures) – 명시적인 지침이 있었음에도 불구하고 에이전트가 잘못된 SDK나 버전을 선택했습니다. 올바른 정보가 프롬프트 컨텍스트에 있었음에도 불구하고, 모델이 적절한 시점에 이를 끌어내지 못했습니다.
이는 추론 능력의 부족이 아니라, 워크플로우를 제한하는 방식에서의 엔지니어링 버그입니다. 훨씬 더 뛰어난 언어 모델이라 할지라도, 오케스트레이터가 코딩 이외의 임무에 집중하도록 고정하고 올바른 SDK 선택을 강제하는 엄격하고 명확한 규칙이 필요합니다.
에이전트를 길들이기 위해 변경한 사항
나는 시스템이 단계별 목록을 보고 자신의 역할을 스스로 추론할 것이라는 가정을 버렸습니다. 대신 *"당신은 오케스트레이터입니다. 구현을 하지 마십시오."*라는 직접적인 문구를 추가했습니다. 이 지침이 제대로 적용되기까지 다섯 번의 수정 메시지가 필요했지만, 그 이후 에이전트는 경계를 준수했습니다.
또한 컨텍스트 검색 로직을 강화했습니다. 잘못된 도구가 나타났을 때, 이를 환각(hallucination) 현상이 아닌 검색 파이프라인의 버그로 취급했습니다. 그리고 SDK 세부 정보를 제공하는 프롬프트를 다시 작성하여 올바른 버전을 놓칠 수 없도록 만들었습니다.
AI 증강 개발을 위한 실무적 시사점
- 자신의 메시지 수를 세어보십시오. 수락된 PR의 양이 많다고 해서 잘못된 프로세스가 가려질 수는 없습니다. 수정 요청 횟수는 제어 프레임워크가 어디서 새고 있는지를 보여주는 선행 지표입니다.
- 역할을 명시적으로 기술하십시오. 에이전트는 체크리스트를 통해 자신의 정체성을 유추하지 않습니다. 자신이 누구인지, 무엇을 할 수 있는지에 대한 명확하고 고정된 지침이 필요합니다.
- 도구 선택 오류를 엔지니어링 버그로 취급하십시오. 에이전트가 지정된 SDK를 무시한다면, 그것은 모델의 '지식' 문제가 아니라 컨텍스트 전달 메커니즘의 문제입니다.
- 실수를 재사용 가능한 기술로 전환하십시오. 나는 에이전트가 스스로의 오류로부터 검증 루틴을 생성하도록 하여, 실패를 미래의 방어 기제로 전환했습니다.