코딩 에이전트가 코드를 빨리 써도, 제품은 저절로 좋아지지 않는다

이 글은 The bottleneck was never the code와 claude code is not making your product better를 읽고 개인적인 해석을 덧붙인 글입니다. 두 글의 주장을 산업 전체에 입증된 사실로 받아들이지는 않습니다.

요즘 Claude Code, Codex, Cursor 같은 코딩 에이전트를 쓰다 보면 코드가 예전보다 훨씬 빠르게 만들어진다는 것이 확실히 느껴진다. 반나절은 걸릴 것 같던 구현 초안이 몇십 분 만에 나온다. 테스트와 문서 초안도 함께 만들어준다.

하지만 구현 초안이 빨리 나왔다는 경험과 제품의 가치가 빨리 커졌다는 결론 사이에는 확인해야 할 단계가 있다.

코딩 에이전트가 코드를 빨리 쓰게 해준다면, 제품도 그만큼 빨리 좋아지고 있을까?

내가 두 글에서 가져온 질문은 이것이다. 코딩 에이전트를 덜 쓰자는 이야기가 아니다. 절약한 구현 시간이 사용자 문제를 해결하는 데까지 이어지는지 보자는 이야기다.

병목은 팀과 작업마다 다르다

The bottleneck was never the code는 여러 사람이 무엇을 만들지 합의하고 그 맥락을 공유하는 비용에 주목한다. 구현이 빨라질수록 요구사항과 수용 기준을 정하는 일이 병목으로 드러날 수 있다는 관점이다.

다만 제목을 그대로 일반 법칙으로 삼고 싶지는 않다. 구현 인력이 부족한 작은 팀이나, 해야 할 일이 명확한 마이그레이션에서는 코드 작성이 실제 병목일 수 있다. 그 구간을 에이전트가 단축하면 제품 개선도 빨라질 여지가 있다.

반대로 요구사항이 계속 바뀌거나 배포 승인이 오래 걸리는 팀이라면 구현만 빨라져서는 전체 대기 시간이 크게 줄지 않을 수 있다. 어느 구간이 느린지 확인하기 전에 “병목은 판단이다”라고 결론 내리는 것도 성급하다.

예를 들어 다음은 실측이 아닌 단순한 계산이다.

한 변경의 소요 시간	에이전트 도입 전	구현 시간이 절반이 된 뒤
요구사항 확인	2일	2일
구현	2일	1일
리뷰·배포 대기	6일	6일
전체	10일	9일

구현은 두 배 빨라졌지만, 순차적으로 진행된다는 이 가정에서 전체 시간은 10% 줄었다. 이 정도 개선도 가치가 있다. 다만 “개발 속도가 두 배가 됐다”와는 다른 주장이다. 실제 업무에서는 단계가 겹치기도 하므로 자신의 작업 이력으로 확인해야 한다.

경쟁 제품 비교만으로 생산성을 알 수는 없다

두 번째 글은 Claude Code 개발팀이 코딩 에이전트의 이점을 먼저 누렸다면 경쟁 제품과의 격차가 압도적으로 벌어져야 하는 것 아니냐고 묻는다.

흥미로운 질문이지만, 나는 이 논증에는 동의하지 않는다. 경쟁사도 비슷한 도구를 쓸 수 있고, 모델 성능·팀 규모·유통·사용자 피드백이 함께 영향을 준다. 제품 간 격차를 관찰하는 것만으로 특정 팀의 도구 도입 효과를 분리할 수는 없다.

그럼에도 코드 생산량과 제품 개선을 구분해야 한다는 문제 제기는 유효하다. PR이 늘었더라도 사용자가 서명 요청을 끝내는 데 더 오래 걸린다면 제품이 좋아졌다고 말하기 어렵다. 반대로 코드는 늘었어도 오류를 복구할 수 있게 되어 업무 중단이 줄었다면 가치 있는 변경이다.

기능을 요청받았을 때 먼저 확인할 것

가상의 문서 서비스에서 “검색 필터를 더 추가해달라”는 요청을 받았다고 해보자. 바로 필터 UI를 구현하는 것은 쉽다. 하지만 사용자가 문서를 못 찾는 이유는 서로 다를 수 있다.

가능한 원인	먼저 확인할 증거	원인이 맞을 때의 개입
현재 필터로 업무 조건을 표현할 수 없음	사용자가 찾던 문서와 실제 검색 조건	필요한 조건 추가
파일명 검색 자체가 일부 입력에서 실패함	저장값·검색어·응답 비교	검색 결함 수정
기존 필터를 찾거나 이해하기 어려움	사용자가 검색하는 과정 관찰	위치·레이블 개선
접근 권한이 없는 문서를 찾고 있음	권한 정책과 해당 요청	권한 안내 또는 정책 검토

이 표는 실제 개선 실적이 아니라 문제를 구분하기 위한 예다. 기능 추가가 맞는 답일 수도 있다. 다만 다른 원인이면 필터를 빨리 만들수록 유지할 기능만 늘어날 수 있다.

그래서 작업 전에 나는 최소한 네 가지를 정리하고 싶다.

• 문제: 누가 어떤 상황에서 무엇을 못 하는가?
• 증거: 실제 사례인가, 요청자의 추정인가?
• 성공 기준: 사용자의 어떤 행동이나 결과가 달라져야 하는가?
• 제약: 유지해야 할 권한·호환성·기존 흐름은 무엇인가?

처음부터 긴 기획서를 쓰자는 뜻은 아니다. 작은 결함 수정이면 재현 조건과 기대 동작만으로 충분하다. 불확실한 제품 변경일수록 구현 전에 확인할 질문이 많아진다.

코드는 자산이면서 비용이다

새 코드에는 검토하고 유지해야 할 부분이 생긴다. 옵션이 늘면 사용자의 선택도 늘어난다. 그렇다고 줄 수를 최소화하는 것이 항상 좋은 설계는 아니다. 테스트나 명확한 함수 분리는 코드를 늘려도 이후 변경 비용을 줄일 수 있다.

중요한 것은 “얼마나 적은 코드인가”보다 그 코드가 해결하는 문제에 비해 유지 비용이 적절한가다.

예전에는 구현 비용이 높아 미뤘던 기능을 이제 쉽게 만들 수 있다. 이 변화는 실험의 기회이기도 하다. 짧게 써보고 버릴 프로토타입과 장기간 운영할 기능을 같은 기준으로 다룰 필요는 없다. 다만 실험으로 만든 코드를 운영 기능으로 남길 때는 소유자, 실패 처리, 제거 조건을 다시 결정해야 한다.

문서는 판단의 이유를 남기는 곳이다

조직의 중요한 맥락은 코드에 전부 드러나지 않는다. 왜 특정 고객사 예외가 남았는지, 어떤 마이그레이션 때문에 낡은 동작을 유지하는지, 과거에 검토한 대안을 왜 버렸는지 같은 정보다.

에이전트가 이용할 수 있는 맥락은 전달받거나 접근 가능한 기록에서 찾아낸 정보에 달려 있다. 그래서 문서가 중요하다. 다만 문서가 많아지는 것과 맥락이 좋아지는 것은 다르다. 오래된 문서가 현재 코드와 충돌하면 오히려 잘못된 확신을 줄 수 있다.

나는 기능 설명을 반복하는 문서보다 아래와 같은 짧은 결정 기록이 더 유용하다고 생각한다.

결정: 이번 변경은 이름 검색 결함만 수정한다. 필터는 추가하지 않는다.

근거: 실패한 검색 사례에서 입력 표현 차이를 확인했다는 가정이다. 실제 작업에서는 이 자리에 재현 이슈를 연결한다.

제약: 기존 권한과 검색 조건의 의미는 유지한다.

다시 볼 조건: 결함 수정 후에도 조건을 표현하지 못하는 사용자 사례가 남으면 필터 요구를 재검토한다.

이 역시 기록 형식의 예다. 근거 링크와 작성 시점을 남기면 다음 사람이나 에이전트가 결정의 유효성을 다시 확인할 수 있다. 추정은 추정이라고 적어야 한다.

무엇을 측정하면 좋을까

코딩 에이전트 도입 효과를 확인한다면 나는 작업 종류가 비슷한 변경끼리 비교하겠다. 쉬운 문서 수정과 복잡한 권한 변경을 섞어 PR 개수만 세면 의미를 해석하기 어렵다.

확인할 층위	볼 만한 신호	함께 확인할 것
구현	작업 시작부터 리뷰 가능한 변경까지의 시간	범위 축소나 누락이 있었는가
전달	요청부터 실제 배포까지의 시간	리뷰·승인 대기가 어디에 쌓이는가
품질	재수정·롤백·같은 결함의 재발	더 많이 배포해서 건수가 늘었는가
제품	해당 사용자 작업의 성공률·소요 시간	사용자 구성이나 정책도 바뀌었는가

전후 수치가 좋아졌다고 곧바로 AI 덕분이라고 확정할 수는 없다. 작업 난이도, 인력, 테스트, 배포 정책 변화도 함께 기록해야 한다. 그래도 이 구분은 최소한 어디에서 시간이 절약되고 어디에 비용이 옮겨갔는지 보여준다.

내가 가져가고 싶은 기준

코딩 능력이 덜 중요해진다고 생각하지 않는다. 결과를 읽고 검증할 수 있어야 위임도 잘할 수 있다. 다만 경력이 길다고 자동으로 판단이 좋거나, 짧다고 에이전트의 도움을 덜 받는 것은 아니다. 해당 시스템에 대한 이해와 검증 방식이 중요하다.

앞으로는 “에이전트가 얼마나 많이 만들었는가”보다 “이번 변경으로 사용자의 무엇이 좋아졌는가”를 더 자주 묻고 싶다. 답이 불분명하면 다음 구현을 늘리기 전에 그 불확실성부터 줄인다.

코드를 빨리 만드는 능력을 제품을 빨리 이해하는 능력과 연결할 때, 구현 속도의 이점이 실제 가치로 이어질 수 있다.