개발에 진심이었던 사람이 AI 발전을 보고 개발자의 정체성이 바뀜을 인정. Agentic coding로 흥미로운 실험(Gas town-클로드 코드 팀 에잉전트에 영감을 줬다고)을 하고 있는 Yolo 빌더 Steve. 올해 말 상당히 많은 부분이 실현될듯.
왜 AI 생산성이 바로 제품 결과로 안 보이냐?
첫 번째 이유: 기업은 “비결정성”을 정말 싫어한다
AI는 본질적으로 비결정적이라 같은 목표를 줘도 매번 똑같이 움직이지 않고, 그래서 기업은 AI를 기존 고객-facing 시스템이나 핵심 운영 시스템에 바로 꽂아 넣기를 꺼린다는 겁니다. 사람도 틀리지만, 기업은 “사람이 틀리는 것”과 “소프트웨어가 틀리는 것”을 다르게 받아들입니다. 그래서 개인은 이미 체감상 엄청 빨라졌는데, 조직 차원의 제품 변화는 훨씬 천천히 드러납니다. 이 해석은 최근 엔터프라이즈 AI 운영 문서들과도 맞닿아 있습니다. OpenAI는 “모든 엔터프라이즈가 AI를 도입하고 싶지만 동시에 잘못 배포할까 두려워한다”고 쓰고, Anthropic은 에이전트는 유용한 만큼 평가가 어려워서, 평가 체계가 없으면 문제를 프로덕션에서 뒤늦게 잡는 “reactive loop”에 빠진다고 설명합니다.
두 번째 이유: 생산성 증가는 먼저 “내부 효율”로 나타나고, “새 제품”으로는 늦게 나타난다
Steve는 바깥에서 “왜 앱이 갑자기 10배 좋아지지 않았지?”라고 느끼는 이유가, 기업 안에서 생긴 AI 효과가 먼저 마진, 내부 운영 속도, 지원 업무, 반복 업무에 숨어 들어가기 때문이라고 봅니다. 실제 조사도 비슷합니다. Deloitte는 현재 기업들이 AI로 가장 많이 얻는 효과가 생산성과 효율 향상(66%)이라고 보고하지만, 제품/서비스 개선과 혁신(20%), 매출 증가(20%)는 훨씬 낮다고 봅니다. McKinsey도 AI 사용은 넓게 퍼졌지만, 아직 기업 전체 EBIT 영향을 봤다고 답한 비율은 39%에 그쳤고, 대부분 조직은 여전히 실험·파일럿에서 스케일 단계로 넘어가는 중이라고 봤습니다.
세 번째 이유: 큰 회사는 AI 생산성을 “흡수”하지 못한다
문제가 모델 성능이 아니라, 조직이 그 생산성을 삼켜서 제품으로 바꾸는 능력이라는 겁니다. 엔지니어는 빨라졌는데, downstream에서 디자인 리뷰, 보안, 법무, 컴플라이언스, 승인, 릴리즈 프로세스가 병목이 되면 바깥에서 보이는 제품 속도는 거의 안 바뀝니다. 그래서 그는 “우리가 큰 회사들을 보면서 왜 아무 것도 안 나오지? 하고 있는데, 사실은 이미 죽어 있는 회사들을 보고 있는 것일 수도 있다”고 말합니다. TeamDay의 요약도 같은 포인트를 짚는데, 큰 회사는 엔지니어가 덜 생산적인 게 아니라 조직이 그 출력(output)을 흡수하지 못한다는 해석입니다. McKinsey 역시 고성과 조직과 아닌 조직을 가르는 요소로 workflow redesign과 human validation process를 꼽았습니다.
네 번째 이유: 그래서 큰 회사 안에서는 “정체”, 바깥에서는 “폭발”이 동시에 일어난다
큰 회사는 AI 생산성이 올라가도 제품 변화가 안 보이고, 반대로 2명, 5명, 20명짜리 AI-native 팀은 그 생산성을 거의 바로 제품에 반영합니다. 그래서 혁신은 내부에서 균등하게 퍼지기보다 가장자리(edge)에서 먼저 폭발합니다.
그래서 “기업의 비결정성을 해결하는 솔루션”이 유망하냐?
제 답은 예스인데, framing이 중요합니다.
정확히 말하면 유망한 건 “비결정성을 없애는 솔루션”이 아니라,
“비결정성을 통제 가능한 운영 문제로 바꾸는 솔루션”입니다.
즉 엔터프라이즈는 “AI를 deterministic하게 만들어 주세요”를 사는 게 아니라, 아래를 삽니다.
어떤 입력/출력/툴 사용이 허용되는지 정하는 guardrails
에이전트가 실제로 잘 작동하는지 점검하는 evals
어느 단계에서 왜 잘못됐는지 보여주는 tracing / observability
사람이 어디에서 승인하고 개입해야 하는지 정하는 human-in-the-loop
나중에 감사 가능한 audit trail / policy / validation
개인 개발자의 “코딩 공장”이 기업을 바꿀까?
이것도 예스입니다. 다만 다른 시간축의 이야기입니다.
단기(가까운 돈): 엔터프라이즈의 두려움을 줄여 주는 control/governance/evals 계층
중기~장기(더 큰 upside): 작은 AI-native 팀이 기존 SaaS/기존 내부툴을 바깥에서부터 갈아엎는 것
저는 둘 중 하나만 맞는 게 아니라, 둘 다 맞고 순서가 다르다고 봅니다.
엔터프라이즈는 내부적으로는 guardrails·evals·audit 없이 못 갑니다. 하지만 시장 전체는 결국 작은 팀들이 더 빠르게 제품을 만들어 외부 경쟁 압력으로 큰 회사를 바꾸게 될 가능성이 큽니다.
“향후 새로운 IDE”는 정확히 어떤 모습인가?
2-1. 코드 편집기에서 “에이전트 관제실”로 바뀐다
Gas Town은 “2026년 IDE의 새로운 형태”이고, 여러 Claude Code 인스턴스를 돌릴 때 “누가 뭘 하고 있는지 추적하기 어려운” 문제를 대신 처리해 준다고 말합니다. 즉 새 IDE의 핵심은 텍스트 편집이 아니라 에이전트 상태 관리입니다.
1번 축: 대화형 인터페이스
새 IDE는 code-first가 아니라 conversation-first입니다.
Steve의 단계 구분에서도 초반엔 IDE 안 사이드바 에이전트, 이후엔 에이전트가 화면을 점점 더 차지하고, 나중에는 아예 CLI/멀티에이전트로 넘어갑니다. 즉 코드는 점점 “직접 쓰는 것”이 아니라 diff를 확인하거나, 정말 필요할 때만 내려가 보는 결과물이 됩니다. 그의 글에서도 “당신은 Product Manager이고, Gas Town은 Idea Compiler”라고까지 표현합니다.
2번 축: 에이전트 모니터링과 스티어링
새 IDE에서 인간의 역할은 “타이핑”보다 모니터링하고 방향을 틀어 주는 것에 가깝습니다.
Anthropic의 Claude Code agent teams 문서를 보면, 한 세션이 team lead가 되어 작업을 나누고, 각 teammate는 독립 context에서 일하며, 사용자는 중간에 각 에이전트와 직접 상호작용할 수 있습니다. 문서도 “monitor and steer”를 best practice로 강조합니다. Steve가 말한 미래 IDE는 정확히 이런 류의 fleet management UI에 가깝습니다.
3번 축: 작업 orchestration
Anthropic은 병렬화(parallelization)와 orchestrator-workers 패턴을 공식적으로 설명하면서, 복잡한 코딩 변경이나 멀티소스 검색은 중앙 orchestrator가 태스크를 쪼개서 worker에게 맡기고 합치는 방식이 잘 맞는다고 적습니다. OpenAI도 manager-agent와 decentralized multi-agent 패턴을 공식 가이드에 넣었습니다. 즉 새 IDE는 단일 에디터가 아니라 작업 분해, 위임, 합성, 품질 게이트가 들어간 운영체제가 됩니다.
Steve의 맥락을 최대한 풀어 쓰면, 미래 IDE는 대략 이런 모습입니다.
가운데에는 대화창이 있고
옆에는 에이전트 목록이 있으며
각 에이전트가 지금 어느 파일/태스크를 만지는지 보이고
충돌, 중복 작업, 막힌 태스크를 사람이 개입해서 재지시하고
마지막에 코드 diff를 보는 건 “주 작업”이 아니라 “최종 확인”이 됩니다.
여기에 더해 실전에서는 아래 기능이 붙을 가능성이 높습니다.
trace / eval / replay
merge queue
policy / quality gates
context compaction / summarization
file ownership / conflict avoidance
token burn / cost view