AI 도구가 넘쳐나는 시대, 개발자들이 공통적으로 빠지는 함정이 있다. AI를 '쓰는' 것과 AI를 '설계하는' 것을 혼동하는 것이다. 프롬프트를 잘 쓰는 것, 적절한 모델을 고르는 것—이건 사용이다. 하지만 AI가 내 워크플로우 안에서 어떤 상태를 가지고, 어떤 경계에서 멈추고, 어떤 출력을 신뢰할 수 있는지를 정의하는 것—이건 설계다. 최근 세 편의 실전 사례가 이 구분을 아주 구체적으로 보여준다.
MCP 커넥터가 드러낸 것: 도구를 연결하면 보이지 않던 것이 보인다
dev.to에 공유된 SlimSnap MCP 커넥터 구축기는 표면적으로는 'Claude Code와 Cursor에서 스크린샷을 직접 읽게 만든 이야기'지만, 진짜 통찰은 다른 곳에 있다. 개발자 Bickov는 MCP 커넥터를 만들면서 처음으로 자신의 앱 출력을 '에이전트 눈높이'로 직접 들여다봤고, 그 결과 수개월째 프로덕션에 숨어 있던 버그 두 개를 발견했다.
첫 번째는 거리 측정 로직의 오류였다. 어노테이션 화살표가 어떤 UI 요소를 가리키는지 판단할 때, 코드는 요소의 중심점까지의 거리를 재고 있었다. 하지만 실제로 화살표 끝이 버튼 가장자리에 닿아 있을 때, 그 버튼의 중심보다 위쪽 헤딩의 중심이 더 가까울 수 있다. 결과적으로 AI 에이전트는 "이 화살표는 헤딩을 가리킨다"고 잘못 이해하고 있었다. 수정은 단 세 줄—중심 거리에서 사각형 경계까지의 거리로 바꾸는 것이었다. 그런데 이 버그는 누구도 리포트하지 않았다. 커넥터를 만들어 자신의 출력을 직접 에이전트에 흘려보내기 전까지는.
두 번째는 토큰 낭비였다. 좌표값이 64비트 부동소수점으로 직렬화되면서 0.048이 0.04800000041723251로 내보내지고 있었다. 수백 개 요소가 담긴 페이지 하나에서 이 오버헤드가 수백 개 반복되면, 토큰 비용과 파싱 노이즈는 무시할 수 없는 수준이 된다. 이 역시 MCP 커넥터를 통해 실제 출력을 '모델이 소비하는 방식'으로 읽기 전까지는 드러나지 않았다.
이 사례가 던지는 핵심 메시지는 하나다. AI와 연결하는 행위 자체가 새로운 검증 레이어가 된다. 유닛 테스트도, 사용자 리포트도 잡지 못한 버그를, MCP 커넥터라는 새로운 소비자가 찾아냈다. 도구를 연결한다는 것은 단순히 기능을 확장하는 게 아니라, 기존 시스템을 다른 시선으로 다시 보게 만드는 행위다.
Codex로 앱 개발하기: 제어권을 유지하는 구조 설계
두 번째 사례는 Eleonora Rocchi가 dev.to에 공유한 Codex 워크플로우 이식 실험이다. Cole Medin의 Claude Code 기반 에이전틱 개발 방법론을 Codex 환경으로 포팅하면서, 그가 발견한 핵심은 도구가 달라져도 '설계 레이어'의 책임은 동일하다는 것이었다.
원 워크플로우의 핵심은 'AI Layer'라는 개념이다. 저장소 안에 AI 에이전트가 참조할 수 있는 구조화된 정보—PRD, 전역 룰, 참조 문서, 워크플로우 명령어—를 체계적으로 배치하는 것이다. Claude Code에서는 이것이 .claude/commands/ 디렉토리의 마크다운 파일들로 구현되고, Codex에서는 .agents/skills/ 구조의 SKILL.md 파일들로 매핑된다.
특히 주목할 설계 결정은 암묵적 호출 비활성화다. allow_implicit_invocation: false를 설정해, Codex가 컨텍스트를 보고 스스로 워크플로우를 실행하지 않도록 막는다. $prime, $execute, $commit 같은 핵심 워크플로우는 반드시 개발자가 명시적으로 호출해야만 동작한다. AI가 자율적으로 너무 많은 것을 결정하게 두지 않겠다는, 의도적인 마찰의 설계다.
실험 결과도 흥미롭다. 간단한 투두 앱을 만들면서, PRD 작성($create-prd) → 룰 생성($create-rules) → 기능 계획($plan-feature) → 실행($execute) → 커밋($commit)의 흐름을 Codex에서 그대로 재현하는 데 성공했다. 이 흐름의 가치는 단계마다 개발자가 검증 포인트를 갖는다는 데 있다. AI가 한 번에 전체를 만들어버리는 게 아니라, 각 페이즈가 충분히 작아서 확인하고 조정할 수 있다.
에이전트 루프 방지: 상태를 설계하지 않으면 에이전트는 원을 그린다
세 번째 사례는 멀티 에이전트 시스템에서 실제로 발생한 루프 장애다. dev.to의 Yashwanth Kasi가 공유한 경험에 따르면, 고객 지원 봇이 Agent A → Agent B → Agent C → Agent A로 무한히 순환하며 같은 응답을 반복하는 현상이 발생했다. 에이전트를 여러 개 연결했지만, 그 사이의 전이 조건을 설계하지 않았기 때문이었다.
해결책은 LangGraph의 StateGraph를 활용한 명시적 상태 정의였다. 대화가 가질 수 있는 상태(initial, question_asked, response_received, followup_asked)를 먼저 열거하고, add_conditional_edges로 각 전이가 성립하는 조건을 코드 수준에서 명시했다. 에이전트는 이 그래프 위에서만 움직이고, 정의되지 않은 전이는 발생하지 않는다.
이 패턴이 주는 교훈은 단순하다. 에이전트의 자율성은 상태의 경계 안에서만 허용되어야 한다. 전이 조건이 너무 넓으면 루프가 생기고, 너무 좁으면 흐름이 막힌다. 적절한 상태 설계가 에이전트의 행동 범위를 규정하고, 그 범위 안에서만 자율성이 의미를 갖는다.
세 사례가 수렴하는 하나의 원칙
세 이야기는 서로 다른 도구와 문제를 다루지만, 결론은 하나로 수렴한다. AI 도구를 잘 쓰는 것은 AI를 더 많이 믿는 게 아니라, AI가 작동하는 구조를 더 정밀하게 설계하는 것이다.
- MCP 커넥터는 AI와의 연결 자체를 시스템 검증 레이어로 만들었다.
- Codex Skills의 명시적 호출 구조는 개발자가 각 단계의 제어권을 유지하게 했다.
- LangGraph의 StateGraph는 에이전트의 자율성에 명확한 경계를 부여했다.
세 설계 모두 AI에게 더 많은 권한을 준 게 아니다. 오히려 AI가 움직일 수 있는 공간을 명시적으로 정의함으로써, 그 안에서의 자율성이 신뢰 가능해졌다. 이것이 'AI를 생산성 도구로 쓰는 것'과 'AI를 설계 동반자로 통합하는 것'의 차이다.
앞으로 AI 에이전트는 더 많은 권한을 요구할 것이고, 더 많은 자율성으로 더 복잡한 작업을 처리하게 될 것이다. 그럴수록 설계자의 역할은 줄어드는 게 아니라 오히려 커진다. 어디서 멈출지, 어떤 상태를 가질지, 어떤 출력을 신뢰할지—이 질문들에 먼저 답하는 개발자가, AI와 함께 만드는 시스템의 품질을 결정하게 된다.