오늘 GeekNews에서 두 개의 글이 동시에 상위권에 올라왔습니다.

하나는 matklad의 “소프트웨어 아키텍처 배우기”였습니다. 62포인트. 핵심 결론은 이겁니다.

“아키텍처는 책에서 배우는 게 아니다. 책임지는 순간 배운다. 그리고 조직 구조가 코드 구조를 결정한다.”

다른 하나는 JayaGup10의 “AI 분야의 다음 최대 해자는 조직이다”였습니다. 26포인트. 모델이 수렴할수록 승부는 기능이 아니라 권한·판단·구조에서 갈린다는 주장입니다.

같은 날, 같은 커뮤니티에서 두 글이 동일한 결론을 가리켰습니다.

코딩 에이전트 시대의 진짜 레버리지는 코드 속도가 아닙니다. 팀이 어떻게 결정하고 어떻게 검증하는가입니다.

에이전트를 도입했는데도 병목이 그대로인 이유

코딩 에이전트를 도입한 팀에서 자주 나오는 말이 있습니다. “생산성이 올라간 것 같은데 왜 배포 속도는 그대로냐.”

이 질문에 대한 답이 GeekNews에서 나온 적 있습니다. “병목은 결코 코드가 아니었다.” (thetypicalset.com, 10포인트) 코딩 에이전트를 팀에 도입한 실무자의 솔직한 회고였습니다.

에이전트가 코드를 빠르게 만들었습니다. 그런데 리뷰, 의사결정, 맥락 공유, 명세 정리 — 이 인간의 영역은 그대로 남았습니다. 오히려 코드 속도가 올라가면서 이 영역의 병목이 더 선명하게 드러났습니다.

Andrew Ng은 deeplearning.ai/the-batch에서 이 현상을 더 구체적으로 정리했습니다. 코딩 에이전트가 내는 가속은 팀 영역별로 다릅니다.

영역가속 수준
프론트엔드가장 큼
백엔드신중함 필요, 그보다 작음
인프라거의 무가속
리서치마지막

팀 전체가 동일한 속도로 빨라지지 않습니다. 시스템의 실제 속도는 느린 영역이 결정합니다. 에이전트를 도입했는데도 팀 속도가 그대로인 이유가 여기 있습니다. 병목이 이동했을 뿐, 사라진 게 아닙니다.

PM이 해야 할 첫 번째 일은 에이전트 선택이 아닙니다. 팀 영역별 가속 차등을 먼저 파악하고, 어디서 병목이 새로 생기는지를 예측하는 것입니다.

Conway의 법칙이 에이전트 시대에 다시 작동한다

matklad의 글이 62포인트를 받은 이유는 Conway의 법칙을 다시 꺼냈기 때문입니다.

“조직 설계는 소프트웨어 아키텍처에 반영된다. 역할 경계가 모호한 팀이 만드는 코드는 경계가 모호하다.”

에이전트 환경에서 이 법칙이 그대로 재현됩니다. 권한 구조가 불명확한 팀은 에이전트 간 역할도 불명확합니다. 의사결정 흐름이 막힌 팀은 에이전트 오케스트레이션도 막힙니다.

여기서 PM이 빠지기 쉬운 함정이 있습니다. 좋은 에이전트를 도입하면 팀 운영도 자연히 좋아진다는 착각입니다.

GeekNews에서 44포인트로 압도적 1위를 차지한 글(yanivpreiss.com, “최고의 직원이 최악의 관리자가 되는 이유”)이 이 함정을 정확히 짚었습니다. 개별 기량이 뛰어난 사람이 팀을 잘 운영하는 건 다른 역량이라는 것입니다.

에이전트에도 동일한 원리가 적용됩니다. 잘하는 에이전트가 좋은 오케스트레이터는 아닙니다. 오케스트레이션은 에이전트 성능의 문제가 아닙니다. 역할 경계 설계와 의사결정 구조의 문제입니다.

PM이 팀 구조를 먼저 설계하지 않으면, 에이전트 속도가 오히려 혼란을 가속시킵니다.

ROI 검증도 팀 구조 문제다

2026년, CLAUDE.md와 관련된 두 논문이 같은 시기에 상반된 결론을 냈습니다. 하나는 작업 시간이 28% 단축됐다고 했고, 다른 하나는 정확도가 떨어지고 비용이 20% 증가했다고 했습니다.

같은 도구, 같은 설정, 반대되는 결과.

SAS는 이 무렵 공개적으로 말했습니다. “벤치마크 등 기술 지표만으로는 AI 예산을 확보할 수 없다.”

세 신호가 가리키는 것은 같습니다. AI 도입의 ROI는 도구가 결정하지 않습니다. 팀이 어떻게 사용하는지, 어떤 의사결정 구조 안에서 운영되는지가 결정합니다.

오늘 Anthropic이 Claude 유료 플랜에서 3rd-party 에이전트 사용분(Cline, OpenClaw 등)을 월 구독 한도와 별개로 분리 청구하는 구조를 도입했습니다. ServiceNow, Uber 같은 기업들이 연간 AI 토큰 예산을 이미 소진한 것도 개인 사용 패턴이 아니라 팀 단위의 집약적 에이전트 활용에서 비롯됐습니다.

에이전트 비용은 이제 팀 레벨 예산 항목입니다. PM이 관리해야 하는 영역이 됐습니다.

PM이 먼저 해야 할 세 가지

코딩 에이전트를 팀에 도입하기 전에, PM이 먼저 설계해야 할 것들이 있습니다.

첫째, 의사결정 경계를 명시합니다.

에이전트가 어디까지 자율 실행하고 어디서부터 인간이 개입하는지를 먼저 정합니다. 이 경계 없이 에이전트 속도만 올리면 리뷰 부채가 쌓입니다. simonwillison이 지적한 대로 에이전트는 이제 프로덕션 책임 영역입니다. 검토·책임·가드레일 설계가 PM의 새로운 1차 책임입니다.

예를 들어, PR 생성까지는 에이전트가 자율로 수행하되 머지는 반드시 인간이 승인한다는 규칙을 명시합니다. 이 경계가 없으면 에이전트가 만든 코드가 리뷰 없이 프로덕션에 올라가는 사고가 생깁니다.

둘째, 팀 영역별 가속 기대치를 분리합니다.

“에이전트 도입했는데 왜 빠르지 않냐”는 질문은 대부분 잘못된 전제에서 나옵니다. Andrew Ng의 프레임을 팀에 적용합니다. 프론트엔드 팀은 빠른 가속을 기대할 수 있고, 백엔드는 주의가 필요하며, 인프라와 리서치는 다른 기준으로 측정합니다.

팀별 기대치를 분리하지 않으면 불만이 생깁니다. 프론트엔드는 “에이전트 덕분에 3배 빨라졌다”고 하는데 인프라팀은 “별 차이 없다”고 합니다. 둘 다 맞는 말입니다. PM이 이 차등을 먼저 설명하지 않으면 팀 신뢰가 무너집니다.

셋째, 에이전트 역할 경계를 문서화합니다.

멀티 에이전트 환경에서 각 에이전트의 권한, 메모리 접근 범위, 다른 에이전트와의 인터페이스를 명시하지 않으면 충돌이 발생합니다. Databricks가 Unity Catalog를 멀티 에이전트 거버넌스의 첫 레이어로 강조한 이유가 여기 있습니다. 에이전트 수가 늘어날수록 거버넌스 없이는 속도가 아니라 혼란이 쌓입니다.

예를 들어 이런 식으로 정의합니다.

에이전트 A (코드 작성):
  - 권한: src/ 디렉터리 읽기/쓰기
  - 메모리: TASK.md 읽기 전용
  - 인터페이스: 에이전트 B에게 PR 초안 전달

에이전트 B (코드 리뷰):
  - 권한: 읽기 전용
  - 메모리: REVIEW_CRITERIA.md 읽기 전용
  - 인터페이스: 승인/거부 판단만 반환, 수정 불가

이 문서가 없으면 에이전트가 서로의 영역을 침범하거나 중복 작업이 발생합니다.

모델이 수렴할수록, 조직이 해자가 된다

JayaGup10의 글 제목이 이 포스트의 결론이기도 합니다.

Claude, GPT, Gemini — 이 모델들은 비슷한 문제를 비슷한 수준으로 풀기 시작했습니다. 모델 성능의 차별화는 좁아지고 있습니다.

차이가 나는 곳은 다른 데 있습니다. 에이전트를 실제로 쓰게 만드는 설계. 인간이 개입해야 하는 순간을 명시하는 구조. 팀 영역별로 다른 가속을 예측하고 관리하는 역량. 이 모든 것이 PM의 영역입니다.

코드를 빠르게 만드는 건 에이전트가 합니다. 그 에이전트들이 팀 안에서 어떻게 작동하는지를 설계하는 건 PM의 일입니다.

코딩 에이전트 시대, PM의 1차 레버리지는 개인 생산성 도구 선택이 아닙니다. 팀이 어떻게 결정하고 어떻게 검증하는지를 설계하는 것입니다.

오늘 두 글이 62포인트와 26포인트를 받은 이유가 있습니다. 이 질문은 이미 많은 사람이 속으로 고민하고 있기 때문입니다.

당신의 팀에서 코딩 에이전트를 도입한 후, 가장 먼저 드러난 병목은 어디에 있었나요?