에이전트들이 우연히 발견한 '블랙보드': 저장소가 협업 채널이 될 때

소트웍스(Thoughtworks) 유럽·중동·인도 지역 CTO인 자일스(Giles)가 회사의 '젠 AI 탐구' 연재에 남긴 이번 기록은 다수의 AI 코딩 에이전트를 한 저장소에서 동시에 굴려본 실험 노트다. 소트웍스 유럽 팀은 바르셀로나 사무실에 엔지니어 10명을 모아, 에이전트 기반 개발에 최대한 '몰빵'하면 어디까지 얼마나 빨리 갈 수 있는지 확인하는 실험을 진행했다. 이들은 이를 '하이퍼 에이전틱(hyper-agentic)'이라 불렀다. 그 과정에서 의도치 않게, 자율 에이전트를 조율하는 오래된 패턴 하나를 다시 발견하게 됐다.

실험 과제는 항공사 IROps 시스템을 만드는 것이었다. IROps는 항공기 결함, 승무원의 갑작스러운 병가처럼 운항에 문제가 생겼을 때 관제 센터가 어떤 항공편을 취소하고, 어떤 기체를 교체하며, 어떤 승객을 내려 호텔에 배정할지를 결정하는 시스템이다. 수백 대의 항공기, 수십만 명의 승객, 여러 공항에 흩어진 승무원을 한꺼번에 다뤄야 하는 대단히 어려운 문제다. 팀은 시뮬레이션된 가상 항공사와 명세서를 출발점으로 삼아 나흘 만에 시스템을 완성했다. 그런데 이 글의 핵심은 '어떻게 나흘 만에 만들었나'가 아니라, 그 과정에서 튀어나온 협업 방식이다.

커밋 규율이 만들어낸 뜻밖의 소통 채널

여러 에이전트가 하나의 모노레포에서 동시에 작업하자 빌드 파이프라인이 흔들렸다. 이를 다스리기 위해 팀은 '지속적으로 커밋하고 메인에서 리베이스하라'는 규율을 도입했다. 커밋 후 리베이스하고 모든 빌드 검사를 거쳐 푸시하도록 해, 빌드 실패를 로컬에서 조기에 잡으려는 의도였다. 그런데 여기에 부수 효과가 따라왔다. 에이전트들은 명세서의 번호가 매겨진 섹션 단위로 작업을 계획하고, 그 계획을 저장소에 저장하도록 지시받고 있었다. 모든 에이전트가 같은 명세와 같은 섹션 번호를 기준으로 움직였고, 진행 상황을 계획 파일에 기록했다. 이 기록이 잦은 커밋과 함께 저장소 전체에 퍼지면서, 에이전트들이 서로의 진행 상황을 볼 수 있게 된 것이다.

구체적인 장면은 이렇다. 한 에이전트는 특정 복구 계획이 하드·소프트 제약을 위반하는지 판정하는 '평가기(evaluator)'를 만들고, 다른 에이전트는 문제를 풀 계획을 찾는 '탐색(search)' 알고리즘을 만들었다. 탐색은 평가기에 의존하며, 둘 사이에는 공유 인터페이스가 있다. 계획 파일에는 이 통합 지점이 기록됐다. 한쪽은 '이 시점에서 실제 검증기를 호출하도록 호출부를 수정해야 한다'고 적었고, 다른 쪽은 '실제 검증기가 도착하면 이 시점에 호출을 삽입한다'고 적었다. 한 에이전트가 계획의 한 줄을 '진행 중'으로 표시하면 다른 에이전트는 그 줄을 건드리지 않았고, 완료 표시가 뜨면 작업이 풀렸다는 신호와 함께 그것이 어떻게 구현됐는지에 대한 메모까지 전달받았다.

40년 전의 '블랙보드'가 되살아나다

팀은 이 우연한 협업을 곧 능동적으로 활용하기 시작했다. 예컨대 검증기 담당 에이전트에게 '누군가 비용 모델을 계속 커밋하고 있으니 계획과 소스, 저장소를 감시하다가 비용 모델 작업이 안착하면 통합을 시작하라'고 지시했더니, 실제로 그렇게 동작했다. 자일스는 이 현상에 이름이 있다고 말한다. 바로 '블랙보드 시스템'이다. 자율 에이전트들이 스키마 없이 최소 구조에 원하는 만큼의 필드를 덧붙인 튜플을 공유 메모리에 읽고 쓰며, 각자 분해된 부분을 풀어 라벨을 붙여 공유 공간에 던져두면 다른 탐색자가 그것을 찾아 자기 작업에 쓰는 구조다. 이 패턴은 1980년 Hearsay-II 시스템 개발에서 처음 발견됐고, 1986년 겔런터(Gelernter) 등이 튜플 공간(tuple space) 개념으로 정형화했다. 자일스 본인도 대학 시절 계층적 센서로 에이전트 행동을 유도하는 논문을 쓰며 이 패턴을 핵심 조율 구조로 채택한 바 있다.

중요한 것은 이 모든 게 '사고'였다는 점이다. 일련의 결정이 겹쳐 우연히 저장소가 블랙보드처럼 쓰였을 뿐, 의도된 설계가 아니었고 완전히 구조화되지도 않았으며 블랙보드의 핵심 요소 몇 가지는 빠져 있었다. 자일스는 사후 분석으로 이 연쇄 반응을 촉발한 단일 프롬프트를 짚어냈지만, 그럼에도 같은 행동을 안정적으로 다시 유도할 수 있을지는 자신하지 못한다고 솔직히 인정한다. 지시된 행동이 아니라 창발적(emergent) 행동이었기 때문이다.

실무자에게 남는 함의와 한계

실무적으로 곱씹을 대목은 통합 채널을 소스 관리와 분리해야 한다는 관찰이다. 이번에는 잦은 푸시 주기를 강제해 채널을 만들었지만, 그 잦은 커밋이 CI 파이프라인에 과부하를 일으켜 결국 '좀 더 응집된 변경 덩어리가 완성됐을 때만 푸시'하는 방식으로 물러섰다. 그러자 에이전트들은 진행 상황의 연속적 흐름을 잃었다. 협업 신호 전달을 저장소와 CI에 얹으면 파이프라인 부담과 소통 밀도가 정면으로 충돌한다는 뜻이다. 여러 에이전트를 한 저장소에서 운용하려는 팀이라면, 진행 상태 공유 채널을 버전 관리와 독립적으로 설계하는 편이 낫다는 실전 교훈으로 읽을 만하다.

자일스는 이 우연을 의도적 설계로 옮기기 위해 'Talwrn'이라는 프로젝트를 시작했다. 웨일스어로 타작 마당, 즉 논쟁과 충돌을 풀어내는 공간을 뜻하는 이름이다. 프로젝트에 그대로 얹으면 곧바로 에이전트 간 협업 채널을 제공하는 단순한 도구를 목표로 하며, 첫 단계는 Talwrn이 자기 자신의 개발을 지원할 수 있는 수준에 도달하는 것이라고 한다. 다만 현재로서는 구상 단계이고 구체적인 기능이나 성과가 제시된 것은 아니라는 점, 그리고 이번 실험 자체가 실제 고객 프로젝트가 아닌 연습이었다는 점은 감안해서 읽어야 한다. 그럼에도 다중 에이전트 조율이라는 당면 과제를, 40년 된 분산 협업 이론에 비추어 다시 바라보게 한다는 점에서 이 기록은 곱씹을 가치가 있다.