---
title: "코딩 에이전트 시대의 병목은 코드가 아니라 로드맵이라는 주장"
published: 2026-05-04T10:46:15.000Z
canonical: https://jeff.news/article/2248
---
# 코딩 에이전트 시대의 병목은 코드가 아니라 로드맵이라는 주장

이 글은 코딩 에이전트가 개인의 구현 속도를 크게 올리더라도, 소프트웨어 산업 전체가 같은 비율로 빨라지지는 않는다고 말해. 진짜 병목은 코드 작성이 아니라 무엇을 만들지 합의하고, 그 합의를 에이전트가 실행할 수 있을 만큼 명확한 맥락으로 만드는 일이라는 주장이다.

## 개인 생산성보다 협업이 더 큰 단위임

- 글쓴이는 Codex에게 미뤄두던 실험 방법을 30분 정도 설명했고, 몇 시간 뒤 동작하는 첫 버전을 얻었다고 함
  - 실험 주제는 구조화 생성 알고리즘을 더 현실적인 방식으로 평가하는 것
  - 단순히 “이 문자열을 받아들이나?”가 아니라 “올바른 토큰 분포를 생성하나?”에 가까운 문제였음

- 그런데 글쓴이는 여기서 바로 ‘산업 전체가 엄청 빨라질 것’이라는 결론으로 가지 않음
  - 코딩 에이전트가 개인의 코드 작성 방식을 바꾸는 건 이미 일어난 일에 가깝다고 봄
  - 하지만 영향력 있는 소프트웨어는 보통 여러 사람이 협업해서 만들고, 협업의 병목은 코드 타이핑이 아니라고 봄

- 프레드 브룩스의 『맨먼스 미신』과 제럴드 와인버그의 고전까지 끌고 와서 말하는 핵심은 이거임
  - 소프트웨어는 사람들이 “이 시스템이 뭘 해야 하는지” 협상하고 난 뒤 남는 결과물임
  - 코드는 중요하지만, 더 어려운 일의 부산물에 가깝다는 시각

## 로드맵이 새로운 병목이 됨

- 에이전트가 구현을 맡는 팀에서 느려지는 지점은 명세 생산임
  - 로드맵, 인수 조건, 테스트, 티켓, 설계 문서처럼 “우리가 진짜 원하는 것”을 정확히 써야 함
  - 에이전트가 집어 들고 달릴 수 있을 만큼 정밀해야 하니, 대충 말하고 대충 맞추던 방식이 잘 안 통함

- 병목은 코드를 쓰는 사람에서 어떤 코드가 존재해야 하는지 결정하는 사람으로 옮겨감
  - 글쓴이는 이걸 사실상 매니지먼트 병목이라고 봄
  - 기능 구현은 빠른데 다음에 할 잘 정리된 스펙을 기다리는 상황이 생김

> [!IMPORTANT]
> 코드 작성 비용이 내려가면 팀이 자동으로 빨라지는 게 아님. 무엇을 만들지 명확히 정하고, 그걸 실행 가능한 명세로 바꾸는 능력이 더 비싼 자원이 됨.

## 코드가 싸지면 기능은 더 늘어남

- 글쓴이는 Jevons Paradox를 코드에 적용함
  - 어떤 것이 싸지면 덜 쓰는 게 아니라 더 많이 쓰게 된다는 얘기
  - 코드 작성이 10배 싸졌다고 같은 결과를 10분의 1 노력으로 끝내는 게 아니라, 예전엔 만들 가치가 없던 것까지 만들게 됨

- 그래서 프로토타입과 내부 도구가 폭증할 수 있음
  - 석 달 전엔 “시간 아까움”이었을 아이디어가 오후 하나에 만들어짐
  - 딱히 큰 문제를 해결하지 않는 내부 도구도 생기고, 잊힘
  - “12개 기능이 있는 바이브 코딩 제품은 훌륭해지려면 11개 기능을 덜어내야 한다”는 문장이 꽤 찌름

- 기능을 많이 내는 것과 사용자가 흡수하는 것은 별개임
  - 팀이 10개를 ship하든 50개를 ship하든, 사람이 기능을 이해하고 받아들이는 속도는 크게 변하지 않음
  - 스티브 잡스가 1997년에 애플 제품군 약 70%를 정리한 사례를 들며, 집중은 결국 거절하는 능력이라고 말함

## 에이전트에게 컨텍스트는 공짜가 아님

- 조직은 공유 맥락으로 굴러감
  - 왜 만들고 있는지, 전에 뭘 시도했는지, 누가 어떤 결정을 했는지, 어디가 건드리면 안 되는 부분인지 같은 것들
  - 시니어가 PR에서 “이거 마이그레이션 깨짐”이라고 말할 때, 그 배경은 문서에 없는 경우가 많음

- 사람은 방에 같이 있고, 슬랙을 보고, 새벽 장애를 같이 겪으며 맥락을 흡수함
  - 에이전트는 그런 삼투압식 학습을 못 함
  - 프롬프트, 파일 트리, 도구, 명시적 지시 안에 넣지 않은 맥락은 안정적으로 갖고 있지 않음
  - 그 결과 살짝 틀린 질문에 대해 꽤 그럴듯한 답을 만들어낼 수 있음

## 문서화 싫어하는 인간을 에이전트가 도울 수도 있음

- 흥미로운 반전은 에이전트가 읽는 데는 비정상적으로 강하다는 점임
  - PR 댓글, 닫힌 이슈, 커밋 메시지, 오래된 설계 문서, 슬랙 아카이브를 전부 읽고 패턴을 뽑을 수 있음
  - 사람이 아무도 안 읽을 거라서 정리하지 않았던 암묵지를 에이전트가 끌어낼 가능성이 있음

- 글쓴이의 팀은 실제로 이런 루프를 만들기 시작했다고 함
  - 코드베이스, 이슈, PR, 스레드를 크롤링해서 지식 베이스를 만듦
  - 단순히 “이 모듈이 있다”가 아니라 “이 모듈이 이상한 이유는 예전 마이그레이션에서 기존 동작을 보존해야 했기 때문” 같은 맥락을 기록함
  - 다른 에이전트가 코드베이스에서 작업할 때 이 지식 베이스를 다시 사용함

- 다만 완전한 복구는 아니라고 선을 그음
  - 마이클 폴라니의 “우리는 말할 수 있는 것보다 더 많이 안다”는 말을 인용함
  - 글로 남지 않은 맥락 중 일부는 애초에 말로 바꾸기 어렵고, 쓰는 순간 성격이 바뀔 수도 있음
  - 그래도 유용한 출발점이 될지는 실험해볼 가치가 있다고 봄

## 새 해자는 모델이 아니라 조직 정렬일 수 있음

- 앞으로 이기는 회사가 꼭 가장 좋은 모델이나 에이전트 인프라를 가진 회사는 아닐 수 있음
  - 50명, 200명, 2000명이 되어도 적은 수의 중요한 결정에 정렬된 채 더 많은 산출을 낼 수 있는 회사가 유리하다는 주장
  - 결국 문화와 매니지먼트 문제임

- 도구는 조직의 일관성을 대체하지 않고 증폭함
  - IDE, 버전 관리, CI, 마이크로서비스, 데브옵스도 협업 문제를 해결해준다고 했지만 실제로는 기존 조직 역량의 증폭기였음
  - 작은 팀은 기본 정렬이 좋아서 에이전트 효과가 크게 좋게 보일 수 있음
  - 큰 조직에서는 정렬이 좋으면 더 좋아지고, 나쁘면 더 빠르게 망가질 수 있음

---

## 기술 맥락

- 이 글의 기술적 선택은 에이전트를 단순 구현 도구로만 볼지, 조직의 맥락을 읽고 생산하는 시스템으로 볼지예요. 이유는 에이전트가 코드는 빠르게 만들 수 있지만, 무엇을 만들어야 하는지는 조직의 명시적 지식에 의존하기 때문이에요.

- 그래서 로드맵, 인수 조건, 설계 결정 기록이 중요해져요. 예전에는 사람이 회의와 코드 리뷰를 거치며 암묵적으로 맞췄던 부분을, 이제는 에이전트가 읽을 수 있는 형태로 남겨야 하거든요.

- 글쓴이가 말한 지식 베이스 루프는 단순 문서 자동 생성이 아니에요. PR 댓글, 이슈, 커밋 메시지에서 “왜 이 구조가 됐는지”를 뽑아 다음 에이전트 작업의 입력으로 쓰는 구조라서, 에이전트가 반복적으로 같은 맥락 실수를 줄일 수 있어요.

- 다만 이건 문서화 문화를 대체하는 마법은 아니에요. 조직이 무엇을 중요하게 여기는지, 어떤 결정은 바꿔도 되고 어떤 결정은 건드리면 안 되는지 같은 기준을 계속 관리해야 해요. 에이전트는 그 기준을 증폭할 뿐이에요.

## 핵심 포인트

- 코딩 에이전트는 구현 비용을 낮추지만 협업 비용을 없애지는 못함
- 팀의 병목은 코드 작성자에서 명세와 우선순위를 정하는 사람으로 이동함
- 코드가 싸지면 기능과 프로토타입이 늘어나 선택과 집중이 더 어려워짐
- 에이전트는 조직의 암묵지를 자연스럽게 흡수하지 못하므로 명시적 맥락이 중요함
- 새로운 해자는 모델 성능이 아니라 조직의 정렬과 문서화 능력일 수 있음

## 인사이트

이 글은 코딩 에이전트 논의를 ‘개발자 한 명이 얼마나 빨라졌나’에서 ‘조직이 얼마나 명확하게 생각을 글로 만들 수 있나’로 옮겨놓음. 한국 개발팀에서도 에이전트 도입의 승패는 프롬프트 스킬보다 로드맵, 이슈, 설계 결정 기록의 품질에서 갈릴 가능성이 큼.