에이전트 100개가 동시에 코딩하는 시대, 팀 규모의 정의가 바뀐다

소프트웨어 개발에서 '작은 팀'이라는 개념이 흔들리고 있다. 개발자 저자는 코딩 에이전트를 병렬로 운영하는 방식이 확산되면서, 인원 수로 팀의 생산 규모를 가늠하던 오랜 상식이 더 이상 성립하지 않는다고 주장한다. 다섯 명, 열 명이 나란히 앉아 코드를 쓰던 팀과, 소수의 인원이 수십 개의 에이전트를 동시에 돌리는 팀은 겉보기엔 같은 '소규모 팀'이지만 코드베이스에 가하는 부하의 성격이 전혀 다르다는 것이다.

숫자로 보면 차이가 분명하다. 저자의 추정에 따르면 바쁜 하루에 전통적인 소규모 팀은 대략 50건의 커밋, 20건의 푸시, 10건의 풀 리퀘스트를 만들어낸다. 반면 20~100개의 에이전트를 병렬로 돌리는 오늘날의 소규모 팀은 같은 하루에 500건의 커밋, 200건의 푸시, 100건의 풀 리퀘스트를 쏟아낼 수 있다. 사람의 손이 열 배 늘어난 것이 아니라, 사람 한 명 뒤에 붙은 자동화된 실행 단위가 열 배로 늘어난 결과다. 문제는 이 변화가 기존의 협업 구조를 그대로 둔 채 일어난다는 점이다.

우버의 극단적 선택이 새로운 표준이 되는 이유

저자는 우버의 사례를 실마리로 삼는다. 우버가 수천 개의 마이크로서비스를 운영하게 된 것은 기술적 취향 때문이 아니라, 수백 명의 엔지니어가 하나의 거대한 머지 큐에서 순서를 기다리는 대신 각자의 일정에 맞춰 배포하고 자기 코드에 대한 명확한 소유권을 갖고 싶어 했기 때문이다. 당시에는 이 정도의 잘게 쪼개기가 과도하게 보였을 수 있지만, 저자는 이 방식이 앞으로의 기본값이 될 수 있다고 본다. 사람 수백 명이 만들던 동시성 압력을, 이제는 에이전트 수십 개가 소규모 팀 안에서 재현하기 때문이다.

핵심은 병렬성에 대한 코드베이스의 태도다. 모든 변경을 조심스럽게 조율해야 하는 거대한 모놀리식 서비스에서는, 두 개의 의미 있는 작업이 서로를 밟고 지나가면서 머지 충돌과 리팩터링을 강요할 가능성이 높다. 반대로 우버처럼 수천 개의 마이크로서비스로 나뉘어 있으면 코드 작업이 이른바 '난감할 정도로 병렬적인(embarrassingly parallel)' 성격을 띤다. 서비스마다 에이전트를 하나씩 띄워 '성능을 개선하라'고 지시하면, 전반에 걸쳐 의미 있는 개선을 한꺼번에 반영할 여지가 생긴다.

모듈성이 병렬 에이전트 수의 상한을 정한다

다만 100개가 넘는 에이전트를 동시에 돌린다는 것은, 그것들이 서로 독립적으로 잘 작동해야 한다는 조건을 전제한다. 에이전트들이 시간의 대부분을 머지 충돌 해소, 깨진 빌드 수정, 배포 난맥상 정리에 쓴다면 결과적으로 순생산성이 마이너스가 될 수 있다. 병렬성은 공짜가 아니라, 코드베이스가 충돌 없이 흡수할 수 있는 범위 안에서만 이득으로 돌아온다는 뜻이다.

흥미로운 점은 잘게 쪼개는 일의 비용 구조 자체가 달라졌다는 것이다. 과거에는 서비스를 하나 나눌 때마다 보일러플레이트, 배관 코드, CI 설정이 늘어나 분할이 매우 비쌌다. 그러나 이제는 에이전트가 그 모든 것을 대신 써주기 때문에 이 오버헤드의 무게가 크게 줄었다. 여기에 더해 에이전트는 컨텍스트 창이 극도로 제한적이라는 본질적 한계를 갖는다. 서비스든 라이브러리든, 컨텍스트 창 안에 통째로 들어갈 만큼 작은 모듈은 에이전트의 코딩 성능을 극적으로 끌어올린다. 분할의 비용은 내려가고, 분할의 이득은 오히려 커진 셈이다.

실무자 관점에서 정리하면, 코드베이스의 모듈성이 곧 효과적으로 병렬 운영할 수 있는 에이전트의 수를 결정한다. 그렇기 때문에 저자는 모듈성을 나중에 개선할 사치가 아니라 처음부터 설계에 반영해야 할 요소로 다룬다. 팀의 코딩 역량을 인원 채용으로 확장하던 시대에서, 코드 경계를 잘 그어 병렬 실행 단위를 늘리는 방식으로 확장하는 시대로 축이 옮겨가고 있다는 진단이다.

물론 이 글은 개인 개발자의 관찰과 추정에 기반한 것으로, 제시된 커밋·푸시 수치는 실제 측정치가 아니라 상황을 설명하기 위한 어림값이라는 점은 감안할 필요가 있다. 모든 조직이 우버식 마이크로서비스 극단으로 가야 한다는 주장으로 읽기보다는, 에이전트 병렬화가 늘어날수록 모듈 경계 설계와 소유권 분리가 조기에 중요해진다는 방향성으로 받아들이는 편이 합리적이다. 아직 에이전트를 소수만 활용하는 팀이라도, 향후 병렬화를 염두에 두고 서비스와 라이브러리의 경계를 컨텍스트 크기에 맞춰 다듬어두는 일은 미리 해둘 만한 준비다.