코딩 에이전트 시대의 병목은 코드가 아니라 로드맵이라는 주장

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

• 글쓴이는 Codex에게 미뤄두던 실험 방법을 30분 정도 설명했고, 몇 시간 뒤 동작하는 첫 버전을 얻었다고 함

  • 실험 주제는 구조화 생성 알고리즘을 더 현실적인 방식으로 평가하는 것
  • 단순히 “이 문자열을 받아들이나?”가 아니라 “올바른 토큰 분포를 생성하나?”에 가까운 문제였음

• 그런데 글쓴이는 여기서 바로 ‘산업 전체가 엄청 빨라질 것’이라는 결론으로 가지 않음

  • 코딩 에이전트가 개인의 코드 작성 방식을 바꾸는 건 이미 일어난 일에 가깝다고 봄
  • 하지만 영향력 있는 소프트웨어는 보통 여러 사람이 협업해서 만들고, 협업의 병목은 코드 타이핑이 아니라고 봄

• 프레드 브룩스의 『맨먼스 미신』과 제럴드 와인버그의 고전까지 끌고 와서 말하는 핵심은 이거임

  • 소프트웨어는 사람들이 “이 시스템이 뭘 해야 하는지” 협상하고 난 뒤 남는 결과물임
  • 코드는 중요하지만, 더 어려운 일의 부산물에 가깝다는 시각

로드맵이 새로운 병목이 됨

• 에이전트가 구현을 맡는 팀에서 느려지는 지점은 명세 생산임

  • 로드맵, 인수 조건, 테스트, 티켓, 설계 문서처럼 “우리가 진짜 원하는 것”을 정확히 써야 함
  • 에이전트가 집어 들고 달릴 수 있을 만큼 정밀해야 하니, 대충 말하고 대충 맞추던 방식이 잘 안 통함

• 병목은 코드를 쓰는 사람에서 어떤 코드가 존재해야 하는지 결정하는 사람으로 옮겨감

  • 글쓴이는 이걸 사실상 매니지먼트 병목이라고 봄
  • 기능 구현은 빠른데 다음에 할 잘 정리된 스펙을 기다리는 상황이 생김

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

• 글쓴이는 Jevons Paradox를 코드에 적용함

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

• 그래서 프로토타입과 내부 도구가 폭증할 수 있음

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

• 기능을 많이 내는 것과 사용자가 흡수하는 것은 별개임

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

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

• 조직은 공유 맥락으로 굴러감

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

• 사람은 방에 같이 있고, 슬랙을 보고, 새벽 장애를 같이 겪으며 맥락을 흡수함

  • 에이전트는 그런 삼투압식 학습을 못 함
  • 프롬프트, 파일 트리, 도구, 명시적 지시 안에 넣지 않은 맥락은 안정적으로 갖고 있지 않음
  • 그 결과 살짝 틀린 질문에 대해 꽤 그럴듯한 답을 만들어낼 수 있음

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

• 흥미로운 반전은 에이전트가 읽는 데는 비정상적으로 강하다는 점임

  • PR 댓글, 닫힌 이슈, 커밋 메시지, 오래된 설계 문서, 슬랙 아카이브를 전부 읽고 패턴을 뽑을 수 있음
  • 사람이 아무도 안 읽을 거라서 정리하지 않았던 암묵지를 에이전트가 끌어낼 가능성이 있음

• 글쓴이의 팀은 실제로 이런 루프를 만들기 시작했다고 함

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

• 다만 완전한 복구는 아니라고 선을 그음

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

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

• 앞으로 이기는 회사가 꼭 가장 좋은 모델이나 에이전트 인프라를 가진 회사는 아닐 수 있음

  • 50명, 200명, 2000명이 되어도 적은 수의 중요한 결정에 정렬된 채 더 많은 산출을 낼 수 있는 회사가 유리하다는 주장
  • 결국 문화와 매니지먼트 문제임

• 도구는 조직의 일관성을 대체하지 않고 증폭함

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

---

기술 맥락

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

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

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

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