기능 하나를 3일에서 3시간으로 줄였다는 숫자는 솔직히 눈길을 끈다. dev.to에 올라온 한 CTO의 사례는 agentic SDLC를 실제 MVP 빌드에 적용해 종단간 개발 시간을 약 10배 단축했고, 비용은 287K달러에서 128K달러로 55% 줄였다고 밝혔다. 엔지니어 4명이 2명으로 줄었지만, 사라진 게 아니라 에이전트 파이프라인을 운영하는 역할로 전환됐다. 이 정도면 AI-First 워크플로우의 실증 사례로 손색이 없다.
그런데 나는 이 숫자보다 그 뒤에 붙은 단서에 더 주목한다. "외부 감사 사이클은 자연 속도로 흐른다. FDA 사전 검토는 60~90일, IRB 승인은 2~3개월, 규제 기관 미팅은 여전히 일정을 잡아야 한다." 이 문장이 핵심이다. AI는 당신 팀의 코드베이스와 컴플라이언스 발견을 가속할 뿐, 다른 조직의 캘린더를 앞당기지 않는다. 속도가 붙는 구간과 붙지 않는 구간을 구분하지 못하면, 빨라진 구간만 보고 전체 흐름을 잘못 설계하게 된다.
이 구조적 이해가 없을 때 무슨 일이 벌어지는지는 Amazon 사례가 잘 보여준다. 긱뉴스를 통해 국내에도 알려진 이 보도에 따르면, Amazon 내부에서 AI 사용 압박이 커지면서 일부 직원들이 내부 도구 MeshClaw를 생산성 향상이 아닌 AI 활동량 부풀리기에 사용하기 시작했다. 토큰 소비량이 추적되고 주간 80% 사용 목표가 거론되자, 사람들은 일을 잘하는 방향이 아니라 숫자를 맞추는 방향으로 행동을 바꿨다. 한 직원은 쓸모없는 에이전트를 만들어 토큰을 소모했고, 동료보다 10배 많은 사용량으로 오히려 표창을 받았다. 지표가 행동을 설계한다. 잘못된 지표는 잘못된 행동을 만든다.
이건 Amazon만의 문제가 아니다. Hacker News 스레드에는 다른 FAANG 직원들의 유사한 증언이 줄을 잇는다. "토큰 사용 순위표에는 인사평가에 반영되지 않는다는 면책 문구가 붙어 있지만, 그 뒤에 암묵적인 눈짓과 윙크가 따라온다." 리더십이 공식적으로는 부인하면서 비공식적으로는 압박을 가하는 구조가 만들어지면, 팀원들이 느끼는 신호는 명확하다—토큰을 태워라. 이 상황에서 AI 도입의 ROI를 측정하는 지표로 토큰 소비량이나 PR 건수를 쓰는 팀이라면, 지금 당장 지표 설계를 다시 봐야 한다.
그렇다면 올바른 구조는 어떻게 생겼을까. 같은 dev.to에서 QA 엔지니어가 공개한 mk-qa-master 사례는 하나의 답을 제시한다. Claude가 100번째 테스트에 # TODO를 남겼을 때, 이 엔지니어는 모델을 탓하거나 프롬프트를 다듬는 대신 구조를 바꿨다. LLM이 # TODO를 쓰는 이유는 능력이 부족해서가 아니라, 라이브 DOM과 모바일 뷰 계층, 최근 10회 테스트 이력, 반복 실패 중인 스펙 파일 같은 것들을 볼 수 없기 때문이다. 모델이 추측하는 것들을 실제 도구 접근으로 대체한 것이 MCP 기반 mk-qa-master의 핵심이다.
이 도구의 설계에서 눈여겨볼 것은 '3계층 QA 지식 아키텍처'다. ISTQB 방법론을 내장한 레이어 1, 프로젝트별 비즈니스 규칙과 히스토리컬 버그를 담는 qa-knowledge.md 레이어 2, 테스트 파일 내부에 비즈니스 컨텍스트를 인라인으로 박는 레이어 3. 이 구조가 없으면 AI는 "빈 필드는 에러여야 한다"는 수준의 노이즈를 생성하는 데 그친다. 구조가 AI의 출력 품질을 결정한다는 것, 이 원칙이 QA 자동화에도 그대로 적용된다.
세 사례를 엮으면 하나의 설계 원칙이 보인다. AI-First 워크플로우를 팀에 도입할 때, 가장 먼저 설계해야 할 것은 속도 목표가 아니라 측정 구조다. 무엇을 측정하느냐가 팀이 무엇을 최적화하느냐를 결정하기 때문이다. agentic SDLC가 기능당 개발 시간을 10배 단축해도, 그 절감이 더 많은 리뷰 사이클로 소진되거나 잘못된 기능을 더 빠르게 만드는 데 쓰인다면 ROI는 마이너스다. MCP 기반 테스트 자동화가 # TODO 없는 테스트를 생성해도, 그 테스트가 비즈니스 규칙을 모른다면 노이즈다. 토큰 사용량을 KPI로 잡으면, 팀은 AI로 일을 잘하는 법 대신 토큰을 태우는 법을 학습한다.
테크 리드로서 내가 AI-First 팀 리빌딩에서 가장 먼저 확인하는 질문은 세 가지다. 첫째, 우리가 측정하는 지표가 산출물의 품질을 반영하는가, 아니면 활동량을 반영하는가. 둘째, AI가 가속하는 구간과 가속하지 않는 구간을 팀이 정확히 구분하고 있는가. 셋째, AI 도구에 우리 팀의 컨텍스트가 제대로 주입되어 있는가—아니면 도구가 여전히 추측에 의존하고 있는가. 이 세 질문에 답하지 못한 채 속도 지표를 목표로 세우는 팀은 조만간 더 빠른 속도로 잘못된 방향을 향해 달리고 있다는 사실을 발견하게 된다.
전망은 낙관적이지만 조건부다. 3일→3시간은 달성 가능한 숫자다. 하지만 그 숫자는 agentic SDLC 아키텍처, 명확한 human gate 설계, 컨텍스트가 탑재된 AI 도구, 그리고 올바른 측정 지표가 동시에 갖춰졌을 때 나온다. 토큰 소비량을 리더보드에 올리는 것부터 시작하는 팀과, 어느 구간에서 AI가 실질적 가치를 만드는지를 먼저 정의하는 팀 사이의 격차는 시간이 지날수록 벌어질 것이다. 속도를 올리기 전에 무엇을 측정할 것인지를 먼저 설계하라.