대시보드는 거짓말을 하지 않는다. 티켓은 빠르게 닫히고, PR 볼륨은 늘었고, 사이클 타임은 줄었다. 그런데 어느 날 2주 전에 배포된 코드가 특정 부하 조건에서만 발생하는 방식으로 재시도 메커니즘을 조용히 망가뜨리고 있었다는 걸 알게 됐다. dev.to에 공개된 한 엔지니어링 리더의 회고가 이 상황을 정확히 짚는다. 그 코드는 테스트를 통과했고, 리뷰를 통과했고, 배포도 깔끔하게 됐다. 단지 안전하지 않았을 뿐이다.
문제는 도구가 아니었다. 가정이었다. 빠르게 움직인다는 것이 곧 잘 이해하고 있다는 의미라는 가정. AI 코딩 어시스턴트가 초안을 작성하고, 테스트가 통과하고, 리뷰어는 그게 맞아 보이니까 승인한다. 하지만 "다운스트림 서비스가 느려지면 어떻게 되나요?"라는 질문은 누구도 하지 않았다. AI가 핸들링 코드를 작성했고, 그 질문이 나오기 전에 이미 배포됐다.
이건 속도의 문제가 아니다. 학습 메커니즘의 문제다. 과거에는 새벽 11시에 스택 트레이스를 3시간 들여다보며 이해해야 했다. 그 마찰이 "이건 동작하긴 하는데 뭔가 이상한 것 같다"는 직관을 만들었다. 데이터를 6시간 동안 조용히 오염시킨 마이그레이션, 스테이징에서는 멀쩡하다가 금요일 오후 프로덕션에서 터진 캐싱 레이어—그 고통이 메커니즘이었다. AI가 첫 번째 초안을 무료로 제공하는 순간, 그 메커니즘이 멈춘다.
이 역설이 AI-First 팀 리빌딩을 주도하는 입장에서 가장 불편한 지점이다. AI는 팀이 실제로 더 유능해지기 전에 더 유능해 보이게 만들 수 있다. 리뷰 품질이 먼저 떨어진다. 한 명의 엔지니어가 이전에 세 명이 처리하던 PR 볼륨을 생성하면, 리뷰어는 빠르게 읽고 "테스트 통과했으니 괜찮겠지"라고 넘어간다. 그다음은 디버깅이 얕아진다. 에러를 붙여넣고 30초 만에 수정안을 받으면, 왜 깨졌는지는 묻지 않게 된다. 그리고 몇 달 뒤 비슷한 실패가 다른 형태로 나타났을 때, 둘을 연결하지 못한다.
아이러니는 여기서 더 심해진다. 바로 지금 Cursor의 멀티모달 프롬프트 워크플로우가 주목받고 있다. velog에서 소개된 PromptShot 방식처럼, 브라우저 화면을 드래그로 캡처해 Cursor 프롬프트 창에 직접 붙여넣으면 AI에게 전달되는 컨텍스트 밀도가 높아진다. "왼쪽 사이드바가 모바일에서 overflow됩니다"라고 설명하는 대신 화면을 그대로 보여주는 것. 앱 전환 한 번, 파일 저장 없음. 속도는 더 빨라진다. 그런데 바로 그 흐름의 매끄러움이, 엔지니어가 문제를 글로 서술하며 사고를 정리하는 구간을 지워버린다.
모델 선택 전략도 같은 방향으로 진화하고 있다. dev.to의 Claude Sonnet 5 vs Opus 5 실무 비교에 따르면, 지금의 현명한 접근은 "Sonnet 5를 기본으로 쓰고, 판단이 중요한 경로에서만 Opus 5로 에스컬레이션하라"는 것이다. Sonnet 5는 일상적인 코딩, 리팩터, 테스트 작성에서 SWE-bench 72.7%로 이전 세대 Opus에 근접했고 비용은 훨씬 낮다. Opus 5는 자율 에이전트 작업, 아키텍처 결정, 틀렸을 때 되돌리기 어려운 작업에 쓴다. 이 라우팅 로직 자체는 합리적이다. 문제는 "판단이 중요한 경로가 어디인지"를 팀이 알아야 한다는 것이다. 그리고 그 판단력은 AI가 생성해주지 않는다.
그래서 실제로 뭘 해야 하나. 앞서 언급한 회고가 시도한 것들이 힌트를 준다. 코드 리뷰를 게이트에서 사고 훈련 공간으로 전환했다. "이 코드가 동작하는가"가 아니라 "가장 걱정되는 실패 모드가 뭔가"를 묻는 것으로. 인증, 결제, 데이터 마이그레이션, 외부 의존성을 건드리는 PR에는 "무엇이 잘못될 수 있는가" 단락을 PR 설명에 의무화했다. 처음에는 느리게 느껴졌다. 실제로는 느리지 않았다. PR의 질이 올라갔고, PR을 열기 전에 던지는 질문의 수준도 올라갔다.
주니어를 인시던트 대응에 일찍 참여시킨 것도 의미 있는 변화였다. 나는 오랫동안 인시던트 대응은 경험으로 벌어야 접근할 수 있는 공간이라고 생각했다. 지금은 반대로 생각한다. 새벽 2시에 세 가지 잘못된 가설을 거쳐 결국 맞는 답을 찾아가는 과정을 지켜보는 것—그게 어떤 훈련으로도 복제되지 않는다. AI가 30초에 수정안을 주는 환경에서는 그 과정이 일어나지 않는다. 의도적으로 만들어줘야 한다.
테크 리드로서 가장 냉정하게 직시해야 할 지점은 이것이다. 생산성 지표는 오르고, 팀의 깊이는 측정되지 않는다. Cursor 멀티모달 워크플로우로 UI 버그 수정 루프가 매끄러워지고, Sonnet 5로 테스트 커버리지가 빠르게 올라가고, 모델 라우팅 최적화로 인프라 비용이 줄어드는 동안—조용히 진행되는 것은 엔지니어들이 시스템의 실패 모드를 스스로 추론하는 능력을 연습할 기회를 잃어가고 있다는 것이다.
AI-First 팀 리빌딩은 도구를 도입하는 것과 팀이 그 도구를 통제하는 능력을 유지하는 것을 동시에 설계해야 한다. Cursor로 개발 속도를 올리면서도 코드 리뷰를 사고 훈련 공간으로 운용하고, Claude 라우팅 전략으로 비용을 최적화하면서도 "판단이 필요한 경로"를 팀이 직접 식별할 수 있어야 한다. 속도는 도구가 올려준다. 깊이는 여전히 팀이 지켜야 한다. 그리고 그 두 가지가 지금 동시에 요구되고 있다.