AI 코딩 에이전트를 팀에 붙이는 데 성공했다고 가정하자. Claude Code가 돌아가고, Codex가 PR을 열고, 대시보드는 초록불이다. 바로 그 순간부터 진짜 설계가 시작된다. 도입 전 설계—컨텍스트 구조, 역할 분리, 거버넌스—는 이미 많이 다뤘다. 오늘 짚어야 할 건 그다음이다. 에이전트가 돌아가는 동안 우리는 무엇을 보고 있는가?
에이전트는 투명하지 않다
에이전트가 버그를 고쳤다. 터미널에 결과가 떴다. 그런데 그 에이전트가 모델에 실제로 무엇을 보냈는지 아는가? 시스템 프롬프트가 의도대로 전달됐는지, 이전 턴의 툴 결과가 컨텍스트에 포함됐는지, 어느 요청에서 토큰이 폭발했는지—대부분의 팀은 모른다. dev.to에 소개된 오픈소스 도구 ccglass가 해결하려는 문제가 정확히 이것이다.
ccglass는 로컬 프록시로 동작하면서 Claude Code, Codex, OpenCode 등 에이전트가 모델 API에 보내는 모든 요청을 가로채 웹 대시보드에 시각화한다. 시스템 프롬프트, 메시지 히스토리, 툴 스키마, 툴 콜과 결과, 토큰 사용량, 캐시 히트율, 추정 비용, 레이턴시—한 화면에서 볼 수 있다. npm install -g ccglass 한 줄로 설치하고, ccglass claude 또는 ccglass codex로 실행하면 끝이다.
실용적 관점에서 이 도구가 가치 있는 건 '설치 장벽이 낮다'는 점이다. TLS 인증서를 설치하거나 클라이언트 소스를 수정할 필요 없이, ANTHROPIC_BASE_URL 같은 환경변수만 프록시 주소로 바꿔주면 된다. 팀에서 AI 에이전트를 진지하게 쓰기 시작했다면, 이 수준의 관찰성 레이어는 선택이 아니라 필수다. 에이전트가 왜 그 결정을 내렸는지 물어볼 수 없다면, 디버깅은 결국 추측이 된다.
생산성 10배 신화의 실체
관찰성 문제와 별개로, 우리가 AI 도구에 기대하는 생산성 지표 자체를 다시 봐야 한다. dev.to에 올라온 한 창업자의 글은 불편한 진실을 직격한다. Atlassian의 2025년 설문(3,500명 대상)에 따르면 개발자의 절반이 주당 10시간 이상을 비코딩 업무—불명확한 요구사항, 회의, 의사결정 대기—에 쓴다. 코드를 타이핑하는 속도는 처음부터 병목이 아니었다.
수치는 더 냉정하다. DX(400개사 분석)는 AI 사용량이 65% 증가했지만 실제 아웃풋은 10% 늘어나는 데 그쳤다고 보고했다. METR의 무작위 대조 실험에서 숙련 개발자들은 AI가 자신을 24% 빠르게 할 거라 예측했지만, 실제로는 19% 느려졌다. Google DORA 팀의 표현이 가장 정확하다. "AI는 증폭기다. 이미 잘하는 사람을 조금 더 빠르게 만들고, 그렇지 않은 사람은 AI 슬롭 머신으로 만든다."
팀 리드 입장에서 이 데이터가 의미하는 건 명확하다. AI 라이선스 예산을 태우기 전에, 팀의 실제 병목이 어디 있는지 먼저 측정해야 한다. 코딩 속도가 느린 팀인가, 아니면 무엇을 만들지 결정하는 속도가 느린 팀인가? 전자라면 AI 코딩 도구가 ROI를 낸다. 후자라면 아무리 좋은 도구를 줘도 병목은 그대로다.
드리프트: 아무도 알림을 보내지 않는 장애
세 번째 문제가 가장 까다롭다. 에이전트가 고장나지 않았는데 품질이 떨어지는 상황이다. dev.to의 또 다른 글은 이를 드리프트(drift)라고 정의한다. 예외도, 500 에러도, 헬스체크 실패도 없다. 에이전트는 매일 실행되고 매번 답을 돌려보낸다. 그런데 6주에 걸쳐 측정 가능한 수준으로 품질이 나빠졌고, 팀은 모니터가 아닌 고객한테서 이 사실을 알게 된다.
드리프트가 발생하는 원인은 코드 변경과 무관하다. 모델 제공자가 핀 버전 뒤에서 조용히 체크포인트를 교체하고, 퓨샷 예시들은 작성 당시 현실에 맞춰져 있지만 시간이 지나면서 세계가 달라지며, 검색 인덱스가 재임베딩되거나 툴이 필드명을 바꾼다. git 히스토리는 변화가 없는데 사용자 경험은 조용히 무너진다.
이를 감지하려면 단일 임계값('점수가 0.8 아래면 알림') 방식으론 안 된다. 점수가 0.91에서 0.82로 5주에 걸쳐 떨어지면 절대 기준선을 한 번도 건드리지 않는다. 필요한 건 베이스라인 대비 변화의 통계적 유의성이다. agent-eval로 프로덕션 출력을 지속적으로 스코어링하고, AgentLens로 각 실행의 트레이스를 붙여두면, 드리프트 알림이 떴을 때 '품질이 6% 하락했고 어느 스텝에서 시작됐는지'까지 바로 파고들 수 있다. 알림만 있고 트레이스가 없으면 그건 불안 생성기일 뿐이다.
세그먼트 분리도 빼먹으면 안 된다. 전체 평균 점수가 0.90으로 안정적으로 보여도, 특정 언어권이나 특정 입력 유형의 트래픽이 0.61까지 무너지는 걸 집계가 가려버릴 수 있다. 전체 지표가 초록이라고 안심하는 순간, 드리프트는 이미 8%의 사용자를 잃고 있다.
운영 감시 없는 AI-First는 반쪽짜리다
세 기사가 가리키는 방향은 하나로 수렴한다. AI 코딩 에이전트를 도입한 팀이 다음으로 투자해야 할 곳은 더 좋은 모델도, 더 많은 라이선스도 아니다. 운영 단계의 관찰성과 감시 체계다. 에이전트가 무엇을 보내는지 보이지 않으면 디버깅이 추측이 되고, 생산성 기대치가 잘못 설정되면 투자 판단이 틀어지며, 드리프트를 감지하지 못하면 고객이 먼저 장애를 신고한다.
AI-First 워크플로우를 선언하는 팀은 많아졌다. 하지만 '켠 뒤'를 설계한 팀은 여전히 드물다. 도입은 이벤트고, 운영은 상태다. 에이전트는 지금 이 순간도 돌아가고 있고, 당신이 보지 않는 곳에서 조용히 달라지고 있다.