핵심 이슈: 에이전트는 코드를 쓴다, 그런데 누가 감시하는가
AI 에이전트가 PR을 올리고, 버그를 고치고, 테스트를 통과시키는 시대다. 문제는 '통과'가 곧 '올바름'을 의미하지 않는다는 점이다. 이번 주 눈에 띈 세 편의 글—MCP Server를 QA 엔지니어로 활용한 실전 사례, AI 코딩 모델의 Over-Editing 현상을 정량화한 연구, 그리고 Codex·Claude Code 위에 Supervisor를 얹은 아키텍처 설계기—은 각각 다른 각도에서 같은 문제를 가리킨다. 에이전트가 코드를 잘 쓰는 것과, 팀이 그 코드를 안전하게 받아들일 수 있는 것은 전혀 다른 문제다.
맥락 1: MCP Server는 고용하지 않은 QA 엔지니어다
Dev.to에 올라온 한 SaaS 팀의 사례는 흥미롭다. 118개의 MCP 툴을 구축하고 Claude와 대화하며 722개의 수동 테스트 시나리오를 돌렸더니, 기존 유닛 테스트가 전혀 잡지 못한 버그 5개 유형이 드러났다. Zod 스키마 강제 변환 실패, 부분 업데이트 시 필수 필드 오류, IDOR 취약점 2건, 메서드 이름 불일치, 아카이브된 엔티티 노출이 그것이다.
특히 IDOR 취약점은 인상적이다. 웹 UI는 사용자 본인 데이터만 보여주는 암묵적 보안에 의존했지만, MCP 툴은 raw API이기 때문에 명시적 소유권 검사가 없으면 타 팀의 데이터에 접근할 수 있었다. 코드 리뷰를 통과했고, 테스트도 통과했다. MCP 레이어를 통한 크로스도메인 쿼리가 없었다면 발견하지 못했을 버그들이다.
이 팀이 발견한 핵심은 단순하다. AI에게 읽기 권한과 복수 도메인 접근을 주면, 그것은 자연스럽게 감사 엔지니어가 된다. "30일 이상 Sent 상태인 인보이스를 보여줘"라는 질문 하나가 스케줄 잡 실패를 잡아낸다. 단위 테스트는 코드가 '쓴 대로' 작동하는지 검증하지만, MCP 기반 쿼리는 데이터가 '의미 있게' 존재하는지를 검증한다.
맥락 2: 테스트를 통과한다고 끝이 아니다—Over-Editing 문제
AI 에이전트가 버그를 고칠 때 정말 최소한으로만 바꾸고 있는가? nrehiew.github.io에 발표된 연구는 이 질문에 냉정한 답을 내놓는다. BigCodeBench 400개 문제를 프로그램적으로 손상시켜 '정답이 단 하나의 최소 수정'인 평가셋을 만들고, 주요 프론티어 모델들을 테스트했다.
결과는 불편하다. 최신 모델 전반에서 Over-Editing이 확인됐다. range(len(x) - 1)을 range(len(x))로 바꾸면 되는 오프바이원 버그에서 GPT-5.4는 None 검사, 배열 타입 변환, finite-value 마스킹, 배열 크기 검증, 플로팅 로직 교체까지 수행했다. 테스트는 통과한다. diff는 거대하다.
이것이 brown-field 코드베이스에서 왜 위험한지는 분명하다. 팀이 의도적으로 작성한 코드 구조가 이유 없이 바뀐다. 리뷰어는 무엇이 왜 바뀌었는지 파악하기 어려워진다. 코드는 점점 낯설어진다. 그리고 이 '편집 충실도 실패'는 테스트 스위트에 잘 드러나지 않는다.
그나마 좋은 소식은 두 가지다. 첫째, 프롬프트에 원본 보존을 명시하면 모든 모델에서 Levenshtein Distance가 감소했고, 특히 추론 모델에서 효과가 컸다. 둘째, 강화학습(RL)으로 파인튜닝한 모델은 일반 코딩 성능 저하 없이 최소 편집 행동을 일반화할 수 있었다. SFT가 특정 손상 패턴을 암기하는 데 그친 반면, RL은 행동 자체를 학습했다.
맥락 3: 에이전트를 다시 만들지 말고, 기존 에이전트의 Supervisor를 만들어라
Dev.to의 또 다른 글은 다른 종류의 깨달음을 공유한다. 저자는 코딩 에이전트를 직접 만들려다가 멈췄다. Claude Code와 Codex가 이미 있는데 왜 더 못한 버전을 만드는가? 그는 대신 이 두 실행기 위에 Supervisor를 올렸다.
설계의 핵심은 Control Plane과 Execution Plane의 분리다. Execution Plane(Codex, Claude Code)은 실제 파일을 쓰고 명령을 실행한다. Control Plane(Supervisor)은 어느 실행기를 쓸지 결정하고, 세션을 관리하고, 승인 프롬프트를 처리하고, 메모리를 범위별로 관리한다. Supervisor의 규칙은 단순하다: 코드를 직접 쓰지 않는다. 쓰고 싶어지면 그건 구조가 무너지는 신호다.
또 하나의 핵심 결정은 구조화된 관찰(Structured Observation)이다. Codex의 raw 로그를 Supervisor 컨텍스트에 그대로 주입하면 수십 메가바이트짜리 stdout이 들어온다. 대신 `{"kind": "awaiting_approval