스펙 기반 에이전트 코딩이 에이전트 감독 능력을 은밀하게 저하시키고 있다

약 6개월 동안 중형 TypeScript 모노레포에서 에이전트 중심 워크플로우를 운영해왔음. 오케스트레이터가 상단에 있고, 코드 생성을 위한 하위 에이전트들이 있으며, 인간(주로 나)이 스펙을 작성하고 diff를 검토함. 핵심은 명확했음: 나는 아키텍트 자리에 머물고, 에이전트가 타이핑을 처리하는 것. 생산성은 올라가고 내 뇌는 어려운 부분에 집중할 수 있을 거라 생각했음.

그게 아니었음.

실제로 일어난 일은 내가 반사적으로 하던 일들이 퇴화하기 시작했다는 것임. 거창한 아키텍처 결정이 아니라, 작은 결정들 말임. 애초에 코드 리뷰를 잘하게 만들어주는 그런 결정들.

지난 분기의 구체적인 사례 몇 가지:

• 하위 에이전트가 사용자 조직을 루프 돌면서 N+1을 유발하는 Drizzle 쿼리를 작성함. 내가 승인했음. 테스트 픽스처에는 조직이 두 개뿐이라 테스트를 통과함. 스테이징에서 해당 엔드포인트의 p95가 40ms에서 1.8s로 튀는 걸 보고 잡아냄. 2년 전이었다면 그런 코드 형태를 보자마자 읽기도 전에 움찔했을 텐데, 이번엔 움찔하지 않았음.

• 에이전트가 핫패스에 Zod를 사용한 런던 검증을 선택함. 예전에는 Zod의 파싱 비용이 플레임 그래프에 나타나서 의도적으로 직접 만든 가드를 사용했었음. 스펙에는 이전 결정에 대한 언급이 없었고, 나도 기억하지 못했음. 에이전트는 알 방법이 없었음.

• 인증 미들웨어 리팩토링. diff는 400줄이었고 깔끔해 보였으며 타입 체크도 통과함. 에이전트 결과물을 수백 개 검토하다 보니 습관적으로 훑어봤음. 한 라우트에서 CSRF 체크가 조용히 빠진 걸 놓침. 펜 테스트에서 발견됨.

이 중 어느 것도 흥미로운 의미에서의 에이전트 실패가 아님. 이건 감독자인 나의 실패이며, 그게 바로 이 모델의 핵심임.

사람들이 언급하지 않는 루프는 다음과 같음:

1. 코드를 작성하는 것에서 스펙을 작성하고 diff를 검토하는 것으로 이동함.
2. 스펙 작성은 코딩과는 다른 근육을 사용함. 주로 구현 추론이 아닌 제품 및 인터페이스 추론임.
3. 에이전트 속도(하루에 수십 개)로 diff를 검토하면 실행 과정을 추적하는 게 아니라 표면적인 타당성을 패턴 매칭하도록 훈련됨.
4. 날카로운 스펙과 리뷰를 작성하게 해주는 기술들(어떤 쿼리가 비싼지, 어떤 라이브러리에 함정이 있는지, 어떤 미들웨어 순서가 중요한지)은 수년간 직접 코드를 작성하고 디버깅하면서 얻은 것임.
5. 작성과 디버깅을 멈추면 몇 달 만에 그 기술들이 퇴화함. 조용히. 에이전트가 그 기술들을 표면화하던 작업을 대신해주기 때문에 눈치채지 못함.
6. 이제 당신은 점점 감독할 자격을 잃어가는 시스템을 감독하게 됨.

우리 팀의 시니어들은 10년 치의 캐시된 직관이 있어서 당분간은 괜찮음. 미들급 개발자들이 카나리임. 그들은 약 1년 동안 에이전트 중심 작업을 해왔고, 리뷰 코멘트가 눈에 띄게 나빠졌음. 덜 구체적이고, 더 '느낌' 위주임. 어떤 라인에서 왜 문제가 되는지에 대한 후속 조치 없이 "이거 좀 이상한데"라고만 함.

나는 반(反) 에이전트가 아님. 처리량은 확실하고 포기할 생각도 없음. 하지만 "인간은 스펙을, 에이전트는 코드를"이라는 프레임은 12~18개월이 지나야 드러나는 방식으로 잘못되었다고 생각함. 인간은 에이전트가 작성할 수 있는 코드라도 직접 작성해야 함. 감독자의 감각을 날카롭게 유지하기 위해서임. 파일럿들이 자동 조종 장치가 평균적으로 더 잘함에도 불구하고 여전히 직접 비행을 연습하는 것과 같은 이유임.

우리가 지금 시도하고 있는 것들(효과가 있는지는 아직 모름):

• 일주일에 하루는 에이전트를 끄는 날. 버그가 나더라도 직접 코드를 작성함.
• 엔지니어 한 명이 에이전트가 생성한 PR 하나를 골라 모든 호출 경로를 추적하고 발견한 내용을 기록하는 '심층 리뷰' 순번제. 일부러 느리게 진행함.