병목은 결코 코드가 아니었다

• Codex는 .txt에서 1년 넘게 미뤄온 구조화 생성 알고리듬 실험의 첫 작동 버전을 몇 시간 만에 만들었지만, 핵심 변화는 개인 코딩 속도보다 협업 병목이 드러난 데 있음
• 에이전트가 구현을 맡으면 팀의 속도를 늦추는 것은 코드 작성자가 아니라 로드맵, 인수 기준, 설계 문서처럼 에이전트가 바로 실행할 수 있는 정밀한 명세를 만드는 일로 바뀜
• 코드 작성 비용이 낮아지면 이전에는 만들지 않았을 프로토타입과 내부 도구가 늘어나며, 사용자가 흡수할 수 있는 속도는 그대로라서 무엇을 만들지 않을지 정하는 집중의 규율이 더 중요해짐
• 에이전트는 Slack, PR, 이슈, 커밋, 설계 문서에서 암묵적 결정과 관례를 추출해 지식베이스를 만들 수 있지만, 사람이 직접 쌓는 공유 맥락을 완전히 복원하지는 못함
• 다음 10년의 우위는 최고의 모델보다 50명, 200명, 2,000명 규모에서도 줄어드는 결정 집합에 정렬되는 조직적 일관성을 유지하는 회사에 있을 가능성이 큼

코딩 에이전트가 바꾼 병목

• .txt에서 1년 넘게 미뤄온 실험은 구조화 생성 알고리듬과 오픈소스 대안을 테스트하고, 단순히 “이 문자열을 받아들이는가”가 아니라 “올바른 토큰 분포를 생성하는가”에 가까운 문제를 확인하는 작업이었음
• 이 실험은 로드맵에 계속 남아 있었지만, Codex에 접근법을 30분가량 설명한 뒤 몇 시간 만에 작동하는 첫 버전이 만들어짐
• 코딩 에이전트는 개인이 코드를 쓰는 방식을 이미 크게 바꾸고 있지만, 개인 생산성 향상이 곧바로 소프트웨어 산업 전체의 속도 증가로 이어진다고 보기는 어려움
• 영향력 있는 소프트웨어는 여러 사람이 협업해 만드는 경우가 많으며, 분석의 더 흥미로운 단위는 개인 생산성이 아니라 협업임
• 소프트웨어는 사람들이 시스템이 무엇을 해야 하는지 협상한 뒤 남는 결과물에 가깝고, 코드는 중요하지만 더 어려운 작업의 잔여물임

로드맵이 한계가 됨

• 에이전트가 구현을 맡는 팀에서 속도를 늦추는 것은 에이전트가 바로 집어 실행할 수 있을 만큼 정밀한 명세를 만드는 일임
• 로드맵, 인수 기준, “우리가 실제로 원하는 것”은 테스트 스위트, 티켓, 설계 문서 같은 형태로 명확하게 적혀야 함
• 기능은 매우 빠르게 구현되고, 엔지니어가 다른 엔지니어를 기다리는 대신 다음에 올바르게 작성된 명세를 기다리는 상황이 생김
• 병목은 코드를 쓰는 사람에게서 어떤 코드가 존재해야 하는지 결정하는 사람에게로 이동하며, 이는 곧 관리의 문제임

더 싸진 코드는 더 많은 합의를 요구함

• 코드 작성 비용이 낮아지면 같은 결과를 위해 10%만 노력하는 것이 아니라, 이전에는 할 가치가 없던 결과에 같은 노력을 쓰게 됨
• 3개월 전에는 “시간 낭비”로 여겨졌을 프로토타입이 오후 한 번에 만들어지고, 명확한 수요가 없던 내부 도구가 만들어졌다가 잊히기도 함
• 사용자가 흡수할 수 있는 기능의 속도는 팀이 10개를 출시하든 50개를 출시하든 대체로 그대로임
• Steve Jobs가 1997년에 말한 것처럼 “집중은 거절하는 것”이며, Apple은 그해 제품군의 약 70%를 정리했음
• 에이전트가 있으면 새 기능을 출시하는 감각이 더 쉬워지기 때문에, 무엇을 만들지뿐 아니라 무엇을 만들지 않을지 정하는 규율이 더 어려워짐

맥락이 핵심 자원이 됨

• 협상과 합의는 조직 안의 공유 맥락 위에서 돌아감
• 맥락은 무엇을 만들고 있는지, 왜 중요한지, 무엇을 시도했는지, 누가 무엇을 결정했는지, 무엇이 핵심이고 무엇이 남은 흔적인지를 포함함
• 팀의 인간은 같은 방에 있고, 같은 Slack 채널을 읽고, 새벽 2시에 같은 장애를 디버깅하면서 맥락을 자연스럽게 쌓음
• 이 맥락의 대부분은 문서화되지 않으며, 시니어 엔지니어가 PR 리뷰에서 “이건 마이그레이션을 깨뜨릴 것”이라고 말할 때도 문서 없는 맥락을 쓰는 경우가 있음
• 에이전트는 그런 식의 삼투를 할 수 없고, 방 안에 있거나 계획 대화를 반쯤 듣거나 지난 장애의 기억을 지닌 채 맥락을 얻지 못함
• 프롬프트, 파일 트리, 도구, 명시적 지시 안에 넣지 못한 맥락은 에이전트가 안정적으로 갖고 있지 않음
• 맥락이 없으면 에이전트는 조금 잘못된 질문에 대해 그럴듯한 답을 만들 수 있음
• .txt에서 에이전트가 유용한 일을 했을 때도 실제로는 사람이 맥락 작업을 해둔 것이며, 다음 10명의 엔지니어가 그 그림을 자동으로 갖게 되는 것은 아님
• 조직이 늘 암묵적으로 의존해온 맥락은 이제 속도를 제한하는 입력이 되었고, 사람은 명시적 버전을 읽을 대상이 없었기 때문에 이를 암묵적으로 남기는 경향이 있음

에이전트가 맥락을 생산하는 루프

• 사람이 쉽게 소비할 수 있는 맥락을 만드는 일은 사람들이 좋아하지 않는 작업임
• 에이전트는 PR 댓글, 닫힌 이슈, 커밋 메시지, 오래된 설계 문서, Slack 아카이브를 빠짐없이 읽고, 아무도 문서화하지 않았던 패턴을 추출하는 데 강점이 있음
• .txt에서는 코드베이스, 이슈, PR, 스레드를 크롤링해 암묵적 결정, 관례, “왜 이렇게 했는지”를 지식베이스로 만드는 에이전트를 구축하기 시작했음
• 이 지식베이스는 단순히 “이 모듈이 존재한다”가 아니라, “마이그레이션이 기존 동작을 보존해야 해서 이 모듈이 이상하다”거나 “이 벤치마크는 이전 최적화가 분포를 조용히 바꿨기 때문에 중요하다” 같은 맥락을 담음
• 다른 에이전트는 코드베이스에서 행동해야 할 때 이 지식베이스를 사용함
• 사람이 비공식적으로 수행하던 삼투가 에이전트와 사람 모두 읽을 수 있는 형태로 외부화됨
• 맥락을 소비하는 에이전트에는 맥락을 생산하는 에이전트가 필요하며, 이 루프가 돌아가면 조직은 스스로 만들지 않았을 문서화된 기반을 갖게 됨
• 다만 이 루프가 만드는 것은 언제나 부분적인 그림임
• Michael Polanyi의 말처럼 “우리는 말할 수 있는 것보다 더 많이 알고” 있으며, 어떤 핵심 맥락은 말로 적힌 적이 없기 때문에 존재하고, 적는 순간 달라질 수 있음
• 사람이 직접 만나 쌓는 삼투 층은 문서화된 부산물만으로 완전히 복원될 수 없음
• 결과물은 완전한 복원이 아니라 유용한 출발점에 가까우며, 그것이 누적 효과를 내기에 충분한지는 아직 실험적인 질문으로 남아 있음

새로운 해자는 기술보다 조직에 있음

• 다음 10년의 승자는 반드시 최고의 모델이나 최고의 에이전트 인프라를 가진 회사가 아니라, 50명, 200명, 2,000명으로 커지면서도 줄어드는 결정 집합에 정렬된 채 1인당 더 많은 산출을 내는 회사일 가능성이 큼
• 이런 회사는 에이전트가 오기 전부터 가장 어려운 문제가 일관성이라는 점을 알고 있었던 조직임
• 이는 문화와 관리의 문제이며, 항상 그래왔음
• IDE, 버전 관리, CI, 마이크로서비스, DevOps 같은 이전 세대 도구는 더 나은 도구로 조정을 해결하겠다고 약속했지만, 실제로는 이미 존재하던 조직적 일관성을 증폭하는 역할을 했음
• 작은 팀은 일관성을 거의 공짜로 얻기 때문에 증폭 효과가 대체로 긍정적이며, 에이전트를 강하게 지지하는 목소리가 작은 팀에서 많이 나오는 이유도 그들의 맥락에서는 대부분 맞기 때문임
• 일정 규모를 넘으면 일관성은 만들어지고 유지되어야 하며, 증폭 효과는 양방향으로 날카로워짐
• 좋은 조직은 더 좋아지고, 나쁜 조직은 더 빠르게 망가지는 방향으로 움직임
• 에이전트는 이전 도구들보다 훨씬 큰 증폭기이며, 개인이 코드를 더 빨리 쓰게 하는 수단으로는 과대평가되고 조직이 아는 것을 외부화하게 만드는 수단으로는 과소평가됨

회사 문화의 확장으로서의 에이전트

• 에이전트는 자기 생각의 확장처럼 느껴질 수 있고, 그 감각은 강력함
• 더 어려운 과제는 에이전트를 회사 문화의 확장으로 만드는 것임
• 이를 위해서는 글쓰기 문화, 자신이 여전히 맥락 병목인 지점을 식별할 만큼 사려 깊은 관리, 일관성을 유지해야 할 실제 산출물로 다루는 사람이 필요함
• 새로워진 점은 이런 것들 중 일부를 이제 구축할 수 있다는 점임
• 읽고 추출하는 루프는 그 한 형태이며, 다른 형태도 나올 수 있음