41개의 저장소, 452개의 통과 테스트, 두 달간의 초록색 체크마크. Todd Linnertz가 5개월 만에 쌓아올린 숫자들은 인상적이다. 그런데 그가 7월 1일 감사를 실행했을 때 드러난 숫자는 단 하나였다—0. 어댑터 적합성 검사가 실제로 통과한 횟수. continue-on-error: true 단 한 줄의 YAML 키가 두 달간의 검증 결과를 '장식'으로 만들어버렸다.
이 이야기는 단순한 CI/CD 설정 실수가 아니다. 그것은 AI 시대의 개발 속도가 만들어내는 구조적 맹점을 날카롭게 드러낸다. 생성은 이미 '값싼' 행위가 됐다. 진짜 비용은 검증과 판단으로 이동했다. 그리고 우리는 아직 그 이동을 충분히 따라가지 못하고 있다.
구현이 쉬워질수록 멈추기가 어려워진다
GeekNews를 통해 공유된 한 프로덕트 전략 글은 이 문제를 다른 각도에서 꺼낸다. 2년 반 동안 네 차례 제품을 처음부터 다시 만든 어떤 팀의 이야기다. 음성 인터페이스, 세련된 웹 앱, 고품질 문제 해결 엔진까지 구현했지만 단 하나의 질문에 끝내 답하지 못했다—이 제품은 누구를 위한 것인가?
구현이 비쌌던 시절, 예산과 시간이라는 제약은 역설적으로 '검증 강제 장치'로 작동했다. 15만 달러와 6주, 단 한 번의 기회로 바를 열어야 했다면 주변 경쟁 업장을 철저히 조사할 수밖에 없다. 틀렸을 때의 비용이 너무 크기 때문이다. 그런데 AI가 그 마찰을 제거해버렸다. 아이디어가 좋은지 확인하지 않아도 다음 반복으로 넘어갈 수 있고, 각각의 결과물이 완성품처럼 보이니 팀은 이를 '진행 상황'으로 오인한다.
Cloud Native Patterns이 정리한 것처럼, 실험 비용이 낮아질수록 실패한 아이디어를 포기하게 만드는 압력도 함께 약해진다. 모든 과정을 빠르게 만들면 올바른 목적지에만 빨리 도착하는 게 아니라, 완성품처럼 보이는 잘못된 목적지에도 더 빨리 도착한다.
'초록 체크마크'는 진실이 아니었다
Linnertz의 사례로 돌아오면, 그가 발견한 것은 단순한 버그가 아니었다. 13개 어댑터 중 하나는 pytest 자체가 설치되지 않아 실행할 수 없었고, 나머지 11개는 테스트 하네스가 보내지도 않은 입력 키를 읽으려다 KeyError로 4월부터 계속 실패하고 있었다. 그런데 파이프라인은 내내 초록불을 켜고 있었다. continue-on-error: true가 실패를 성공으로 보고하도록 설정돼 있었기 때문이다.
그는 이 상황을 '검증 부채(verification debt)'라고 정의했다—에이전트가 생산한 것과 실제로 검증된 것 사이의 간극. 문제는 그가 이 개념을 정의하는 글을 쓰는 동안에도 2개월치 검증 부채를 쌓고 있었다는 사실이다. AI 기반 개발에서 속도와 검증의 간극이 얼마나 조용히, 그리고 깊이 벌어질 수 있는지를 보여주는 장면이다.
수정은 놀랍도록 단순했다. YAML 한 줄을 삭제하고, 실제 실패는 빌드를 명시적으로 깨뜨리도록 바꿨다. 그 순간부터 초록 체크마크는 비로소 무언가를 의미하게 됐다. 증거(evidence)와 장식(decoration)의 차이는 설정 한 줄이었다.
잘 만든 것과 만들 가치 있는 것은 다른 질문이다
두 이야기가 수렴하는 지점이 있다. AI는 'How to build'의 비용을 극적으로 낮췄다. 하지만 'What to build'와 'Whether it works'라는 질문은 여전히 사람의 판단 영역에 남아 있다. 더 정확히는, AI가 속도를 높일수록 이 두 질문의 무게가 오히려 커진다.
Clayton Christensen의 Jobs to Be Done 프레임처럼, 고객은 제품 자체를 사는 것이 아니라 특정 일을 수행하기 위해 제품을 '고용'한다. 맥도날드 밀크셰이크의 진짜 경쟁 상대가 다른 밀크셰이크가 아니라 베이글과 지루함이었듯, 누구의 어떤 문제를 해결하는지 모른 채 AI로 계속 새로운 밀크셰이크를 만들 수 있다. 더 빠르게, 더 매끄럽게.
Skift의 Rafat Ali가 콘텐츠 전략의 '네 다리'를 두 다리로 잘라낸 과정도 시사적이다. 당시에는 네 가지 요소를 구현하는 데 실제 비용이 들었기 때문에, 성과를 꼼꼼히 관찰하고 작동하지 않는 부분을 제거할 수 있었다. AI 시대에 같은 출시를 한다면? 며칠 만에 네 가지 기능뿐 아니라 요청하지 않은 기능까지 완성된다. 그리고 모든 것이 완성품처럼 보이면서, '무엇을 잘라야 하는가'를 알려주던 신호가 쉬운 구현 과정에 묻혀버린다.
병목이 이동한 곳에서 요구되는 능력
이제 디자이너, 개발자, PM이 공통으로 마주하는 질문은 하나다. 속도가 주어진 시대에, 나는 무엇을 판단하고 있는가? 업계의 논의 대부분이 여전히 '어떻게 더 잘 만드느냐'—역할 재정의, 안목(taste), 표준 연합—에 머물러 있지만, 아무도 원하지 않는 제품을 아무리 완벽한 품질로 만들어도 시장은 무시한다. 시장은 팀이 얼마나 노력했는지 고려하지 않는다.
Linnertz가 스스로 내린 결론은 명쾌하다. "AI는 기꺼이 41개의 저장소를 만들어줄 것이다. 그것을 신뢰할 수 있는지는 여전히 당신의 몫이다." 프로덕트 전략 글의 결론과 정확히 포개진다. Roman Pichler의 프레임으로 압축하면: 제품은 누구를 위한 것인가, 그 사람이 왜 그것을 원해야 하는가—이 두 질문은 로드맵이나 출시 절차가 대신할 수 없다.
AI가 구현의 병목을 제거한 지금, 남은 핵심 레버리지는 세 가지 결정 능력으로 수렴한다. 무엇이 존재할 가치가 있는가. 누구를 위한 것인가. 왜 지금 필요한가. 빠른 프로토타이핑이 일상이 된 시대일수록, 이 질문들을 구현보다 먼저 꺼내는 습관이 팀의 진짜 경쟁력이 된다. 초록 체크마크가 무언가를 의미하려면, 먼저 올바른 것을 측정하고 있어야 한다.