콘웨이의 법칙을 AI 에이전트에 적용하면 그대로 들어맞지 않음. 에이전트는 통신 속도는 빠르지만 세션마다 리셋되는 고정된 컨텍스트 윈도우 때문에 인간처럼 프로젝트별 공유 지식을 축적하지 못함
인간-에이전트 상호작용의 병목은 인간이 에이전트의 출력을 읽고 판단하는 속도임. 텍스트 생성 지연이 0에 수렴하는 상황에서 최적화할 대상은 인간의 읽기와 의사결정 시간뿐임
코드는 에이전트보다 그것을 읽는 인간을 위해 언어가 선택되어야 하며, 코드는 쓰이는 것보다 읽히는 일이 많으므로 커뮤니케이션 비용을 줄이는 방향이어야 함
함수를 잘게 쪼개는 것은 오히려 인간의 탐색 부담을 늘림. Linus Torvalds의 "좋은 취향" 예시처럼 엣지 케이스 자체를 없애는 설계가 인간의 판단 시간을 줄임
이 분석이 유효하다면(그리고 인간이 계속 개입한다고 가정하면) 인간을 위해 설계된 프로그래밍 언어의 르네상스가 올 수 있다고 전망함
콘웨이의 법칙과 에이전트
Casey의 콘웨이 법칙 언급을 계기로 원 논문을 읽어보면, Conway는 설계자 간 정보 흐름과 시스템 구조의 관계를 다루고 있음
인터페이스(API, 문서 등)는 인간이나 팀 사이의 경계를 넘어야 하는 지점에 형성되므로, 프로그램의 인터페이스 전체는 프로그래머 간 커뮤니케이션 그래프를 반영하고, 결과적으로 제품이 조직도를 닮게 됨
같은 모델을 에이전트에 적용하면 분석 자체는 타당해도 깔끔하게 맞지 않음
에이전트는 인간보다 훨씬 빠르게 통신하지만, 인간의 기억이 시간에 걸쳐 누적되는 것과 달리 에이전트의 컨텍스트 윈도우는 세션마다 리셋되는 고정 토큰 예산임
학습이 끝난 에이전트는 도구 호출과 컨텍스트에 로드된 것으로만 환경을 파악할 수 있음
커뮤니케이션 비용과 컨텍스트 오염
커뮤니케이션을 전달 속도와 공유 선행지식으로 나누면, 조직은 합리적으로 스스로를 최적화하다 인터페이스에서 병목이 생기며, 콘웨이의 조직도 거울은 이 제약이 눈에 보이는 형태임
공유 지식과 최대 대역폭이 있어도 한 팀에 인원(인간이든 에이전트든)을 더하는 것은 병렬 팀만큼 확장되지 않음. 인지 예산의 한계가 작동하고, 공통 목표로 정렬되지 않은 추가 인원은 도움보다 해가 됨
에이전트에서는 같은 효과가 컨텍스트 오염으로 나타남
멀티 에이전트 시스템에서 특히 두드러지며, 멀티 에이전트 모드가 고성능 단일 에이전트보다 나쁜 경우가 많은 이유임
인간-인간 인터페이스는 수십 년의 실험 끝에 열린 시스템과 닫힌 팀이라는 형태로 어느 정도 정착했지만, 에이전트-에이전트나 인간-에이전트 통합은 여전히 열린 문제라 "AI 팀원"을 표방하는 것은 사실상 뱀 기름 장사(효능이 없는 것을 과장 광고로 파는 가짜 만병통치약을 뜻함)이며 써보면 누구나 알게 된다고 함
인간이 병목이라면 무엇을 최적화해야 하는가
인간-에이전트 상호작용은 인간이 에이전트의 산출물을 읽는 속도와 이해 후 내려야 하는 결정에서 병목이 생김
"코드를 읽을 필요 없다"는 주장도 있지만, Joel Spolsky 식으로 말하면 채팅은 코드의 추상화 누수(leaky abstraction)이고, 코드는 도메인의 새는 추상화임
오류가 누적되면 결국 코드를 처음부터 읽어야 하며, 인간의 누적형 기억을 활용해 점진적으로 읽을지, 전체 컨텍스트를 머리에 올릴 수 있는 AI인 척할지의 선택이 됨
인간의 읽기 속도는 거의 상수이고 텍스트 생성 지연은 0으로 수렴 중이므로, 최적화할 유일한 대상은 인간이 읽고 판단하는 시간임. 인간은 산문의 품질(Claude 말투에 대한 반감이 나오는 이유)과 코드가 쓰인 언어의 표현력에 병목이 걸림
어떤 언어가 필요한가
에이전트를 위한 프로그래밍 언어 논의가 많지만, 언어 선택은 에이전트보다 코드를 읽는 인간에게 더 중요함. 코드는 인간과 에이전트 사이의 문서 인터페이스이기 때문임
흔한 답은 순환 복잡도지만, 실제로는 함수 수를 늘리는 것이 도구를 통해 코드를 탐색해야 하는 인간의 부담을 오히려 키움
Linus Torvalds의 "코드의 좋은 취향" 사례처럼, 엣지 케이스를 설명하는 코드가 많은 것보다 엣지 케이스가 적어 코드가 적은 편이 나음. 엣지 케이스에 대한 결정 자체가 필요 없는 설계가 인간의 판단 시간을 줄임
다만 대부분은 Linus가 아니고 일상 업무에서 C를 쓰고 싶어 하지도 않음
저자는 불변 데이터로 버그 부류를 통째로 제거하는 Clojure가 그런 언어에 가깝다고 보지만, 함수형 프로그래밍의 캡슐화는 아쉬운 부분임
Rust는 메모리 관리 내부를 코드에 노출해 내려야 할 결정 수를 늘리므로 해답이라고 확신하지 못함
저자에게는 온전한 기본값만으로는 부족하며, 엣지 케이스를 명시적으로 드러내고 시각적으로 쳐낼 수 있는 언어가 필요함
AI가 프로그램 흐름을 선형 텍스트 대신 2D ASCII 다이어그램으로 제시하면 커뮤니케이션 대역폭이 한 차원 늘어나는 것과 같은 방식임
이 분석이 유효하다면, 인간을 위해 설계된 프로그래밍 언어의 새로운 르네상스를 보게 될 수 있음