개발자 존 크리켓은 엑스(X)에 약간의 빈정거림을 담아 다음과 같은 글을 올렸다.

“소프트웨어 엔지니어 : 컨텍스트 스위칭은 생산성을 죽인다. 또 다른 소프트웨어 엔지니어 : 이제 19개 AI 에이전트를 관리하면서 하루에 1,800건을 커밋한다.”

크리켓의 이 농담이 정확히 꽂히는 이유는 실제로 농담이 아니기 때문이다. 크리켓의 발언은 앞으로 벌어질 관리 트렌드의 예고편이며, 코드 줄 수라는 나쁜 생산성 지표를 더 나쁜 지표인 에이전트 출력으로 바꿔치기한 뒤 품질이 망가져서 놀라는 흐름을 보여준다.

물론 유의미한 커밋을 1,800건씩 하는 사람은 없다. 하지만 핵심은 바로 거기에 있으며, 지표는 이미 조작되고 있고 에이전트는 조작을 손쉽게 만든다. 어떤 기업이 에이전트 시대에 ‘커밋 속도’를 칭송하기 시작하면, 그 기업은 생산성을 측정하는 것이 아니라 팀이 얼마나 빨리 기술 부채를 만들어 내는지 측정하는 셈이다.

생성형 AI에서 가장 기대되는 부분은 마침내 백로그를 정리해 준다는 데 있었다. 코딩 에이전트가 초인적인 속도로 표준 템플릿 코드를 찍어내고, 팀은 비즈니스가 원하는 것을 정확히 출시한다는 이야기였다. 하지만, 2026년으로 접어들며 불편한 진실이 드러난다. AI는 개발자 생산성을 구해주지 못했는데, 소프트웨어 엔지니어링에서 병목은 코드 작성이 아니었기 때문이다. 진짜 병목은 검증이고 통합이며, 시스템에 대한 깊은 이해이기 때문이다. 엄격한 검증 프레임워크 없이 코드를 생성하는 행위는 엔지니어링이 아니며, 단지 기술 부채를 대량 생산하는 일이다.

그렇다면 무엇을 바꿔야 할 것인가?

코드를 올바르게 바라보기

필자가 최근 주장했듯이, 코드를 독립된 자산으로 생각하는 습관을 버려야 한다. 코드 한 줄 한 줄은 보안, 관측, 유지보수, 주변 모든 요소와의 연결이 필요한 표면적이다. 그래서 코드를 더 싸게 쓰면 전체 업무량이 줄어드는 것이 아니라, 시간당 더 많은 책임을 만들어내면서 오히려 업무량이 늘어난다.

수년 동안 업계는 개발자를 고임금 지라(Jira) 티켓 번역가처럼 다뤘다. 명확히 정의된 요구사항을 문법으로 바꿔 출시하면 된다는 가정이었다. 크리켓은 이런 일이 전부라면 대체 가능하다는 점을 정확히 짚었다. 기계는 기본 번역을 할 수 있고, 기계는 불평 없이 하루 종일 그런 일을 한다.

하지만 기계가 할 수 없는 일도 있다. AI는 컴플라이언스 실수의 재무적 비용을 ‘체감’할 수 없고, 고객 워크플로우를 보면서 근본 요구사항이 틀렸다는 사실을 본능적으로 알아차릴 수도 없다. 그 역할에는 사람이 필요하며, 사람은 AI에게 무엇을 시킬지 신중하게 고민해야 한다.

크리켓은 이런 전환을 사양 중심 개발로의 불가피한 이동으로 설명한다. 크리켓의 말이 맞지만, 에이전트 시대에 사양이 무엇을 뜻하는지 매우 명확히 해야 한다. 에이전트 시대의 사양은 지라 티켓 하나를 더 만드는 일이 아니라, LLM이 빠져나갈 수 없을 만큼 충분히 촘촘한 제약 조건의 집합이다. 다시 말해 테스트, API 계약, 엄격한 프로덕션 신호로 온전하게 뒷받침되는 실행 가능한 완료 기준 정의다. 하지만, 지난 수십 년 동안 이런 기반 작업에 대한 투자는 충분하지 않았다. 이유는 단순하다. 기반 작업은 순수 산출물처럼 보이지 않고 프로세스처럼 보이기 때문이다. 말하자면, 속도를 늦추는 ‘지루한 일’처럼 보인다.

크리켓의 트윗 댓글만 봐도 갈등이 실시간으로 벌어지는 장면을 확인할 수 있다. 댓글에는 에이전트 개발의 모순을 억지로 맞춰보려는 사람이 보인다. 어떤 댓글은 혼란을 ‘아키텍처 대 엔지니어링’으로 재구성하려 한다. 또 다른 댓글은 19개의 에이전트를 관리하는 일이 컨텍스트 스위칭이 아니라 오케스트레이션이라고 우긴다. 세 번째 댓글은 5개를 넘겨 동시에 돌리면 바이브 코딩처럼 보이기 시작하며, 바이브 코딩은 프로덕션 시스템을 도박에 거는 일을 점잖게 표현한 말이라고 못 박는다. 모든 댓글이 드러내는 핵심 문제가 있다. 바로 업무가 사라진 게 아니라 구현에서 감독과 리뷰로 옮겨갔을 뿐이다.

코드 생성을 병렬화할수록 ‘리뷰 부채’가 더 쌓인다.

관측성이 해법이다

여기서 허니콤(Honeycomb) 공동 설립자 겸 CTO 채리티 메이저스가 답답함을 드러낸다. 메이저스는 수년 동안 코드가 작동하는지 알려면 실제 부하, 실제 사용자, 실제 장애 양상 아래 프로덕션에서 실행해봐야 한다고 주장해 왔다. AI 에이전트를 쓰면 개발 부담은 작성에서 검증으로 완전히 이동한다. 사람은 큰 풀 리퀘스트를 읽기만 하면서 코드를 검증하는 데 악명이 높을 만큼 서툴다. 우리는 실제 환경에서의 동작을 관측하는 것으로 시스템을 검증한다.

이 아이디어를 에이전트 시대로 한 걸음 더 밀어붙여 보자. 수십 년 동안 가장 흔한 디버깅 기법 가운데 하나는 철저히 사회적이었다. 프로덕션 알람이 울리면 버전 관리 히스토리를 보고 코드를 작성한 사람을 찾은 뒤, 그 사람이 무엇을 하려 했는지 묻고, 아키텍처 의도를 재구성하는 방식이었다. 하지만 아무도 코드를 실제로 작성하지 않는 상황에서는 이 워크플로우는 어떻게 될 것인가? 사람이 3,000줄짜리 에이전트 생성 풀 리퀘스트를 대충 훑고 머지 버튼을 누른 뒤 다음 티켓으로 넘어간 상황을 상상해 보자. 장애가 나면 예전에는 작성자 머릿 속에 있던 지식이 어디에 남아 있겠는가?

이 때문에 에이전트 시대에는 풍부한 관측성이 필수다. 풍부한 관측성은 사라진 사람을 대체할 수 있는 유일한 수단이다. 에이전트 시대에는 무언가가 일어났다고 말하는 일반 로그가 아니라 의도와 비즈니스 성과를 포착하는 계측이 필요하다. 정확히 무엇이 바뀌었는지, 무엇에 영향을 줬는지, 왜 실패했는지 답할 수 있을 만큼 풍부한 분산 추적과 다양성 높은 이벤트가 필요하다. 그렇지 않으면 다른 블랙박스가 만든 블랙박스를 운영하는 셈이다.

메이저스는 운영 측면에서 꼭 필요한 조언도 내놓는다. 배포 중지는 임시방편에 불과하다. 변화가 위험해 보이면 배포를 멈추려는 것이 인간의 본능이다. 하지만 배포를 하지 않은 채 에이전트 생성 코드를 계속 병합하면 위험을 줄이는 것이 아니라 위험을 한꺼번에 묶어두는 일이다. 나중에 배포를 실행하면 어떤 AI 환각이 결제 게이트웨이를 무너뜨렸는지 전혀 알 수 없다. 그러니 프로세스를 중단하고 싶다면, 배포가 아니라 병합을 중단해야 한다. 더 나아가 병합과 배포가 하나의 원자적 행동처럼 느껴지게 만들어야 한다. 그 루프가 빠를수록 변동성이 줄고, 무엇이 깨졌는지 특정하기 쉬워진다.

골든 패스가 답이다

다가오는 혼란을 막는 해법은 영웅적 엔지니어에게 기대는 방식이 아니다. 메이저스가 지적하듯이, 회복탄력적 엔지니어링은 플랫폼 엔지니어링과 골든 패스에 대한 헌신이 필요하다. 필자 역시 같은 주장을 한 바 있다.

골든 패스는 올바른 행동을 매우 쉽게 만들고, 잘못된 행동을 매우 어렵게 만든다. 다음 10년 가장 생산적인 팀은 에이전트가 제안한 어떤 프레임워크든 마음껏 쓰는 자유가 가장 큰 팀이 아니라, 최선의 제약 안에서 안전하게 움직이는 팀이다.

그렇다면 에이전트 시대의 성공은 어떻게 측정할 것인가?

에이전트 시대에도 중요한 지표는 여전히 지루한 지표이며, 지루한 지표가 실제 비즈니스 성과를 측정하기 때문이다. DORA 메트릭은 전달 속도를 시스템 안정성과 직접 연결하기 때문에, 업계가 가진 최선의 건전성 점검표로 남아 있다. 배포 빈도, 변경 리드 타임, 변경 실패율, 서비스 복구 시간을 측정한다. AI 에이전트가 오늘 몇 건의 커밋을 만들었는 지에는 관심이 없다. DORA 메트릭이 보는 것은 시스템이 깨지지 않고 변화를 흡수할 수 있는지 뿐이다.

그러니 코딩 에이전트를 쓰자. 코딩 에이전트를 과감하게 쓰자. 하지만 코드 생성과 생산성을 혼동하지 말자. 생산성은 코드 생성 이후에 일어나며, 코드는 제약되고, 검증되고, 관측되고, 배포되고, 롤백되고, 이해돼야 한다. 그 과정이 엔터프라이즈 안전성과 개발자 생산성의 핵심이다.
dl-itworldkorea@foundryco.com