요즘 에이전트 담론에서 쓰는 단어가 루프(loop)에서 그래프(graph)로 넘어가고 있습니다.
"우리가 아직 루프 얘기를 하는 건가요, 아니면 이미 그래프로 넘어간 건가요?" 누군가 이렇게 물었을 때 많은 사람이 무릎을 쳤습니다. RelayRoom이 어디에 서 있는지 정리해 둘 좋은 시점이라 생각해 이 글을 씁니다.
루프 엔지니어링
루프는 원자입니다. 에이전트 하나가 한 가지를 반복해서 개선하죠.
시도한다 → 결과를 확인한다 → 조정한다 → 다시 간다
강력하지만 알려진 한계가 있습니다. 루프는 자기 지표만 봅니다. 고객지원 봇에 "티켓 해결률"이라는 지표 하나를 물려두면 몇 달간 숫자는 오르는데 만족도는 떨어집니다. 봇이 "문제 해결"이 아니라 "티켓 빨리 닫기"를 학습한 거죠. Goodhart의 법칙입니다. 루프는 목표가 옳은지, 자기 측정이 흘러내리는지 스스로 묻지 못합니다.
그래프 엔지니어링
해답은 더 나은 루프가 아니라 루프들의 그래프, 곧 서로 감시하고 교정하는 사이클의 망입니다.
작업을 직선(step 1 → 2 → 3)으로 그리는 대신 모양(shape)으로 봅니다.
- 노드는 생각하는 단위(에이전트 하나, 입력 하나, 출력 하나)
- 엣지는 데이터 의존(다음 노드가 이전 출력을 실제로 읽을 때만 엣지)
여기서 폭이 나옵니다. 서로 의존하지 않는 일은 넓게 펼치고(fan out) 신뢰가 중요한 엣지엔 검증자를 세웁니다(gate). 진실을 쥔 노드는 얼립니다(freeze). 진지한 에이전트 그래프의 주력 모양은 팬아웃 → 리듀스 → 신서사이즈입니다.
루프가 한 가지를 잘하는 깊이라면 그래프는 여러 개를 한 번에 다루는 폭입니다. 둘은 서로를 대체하지 않고 다른 축에 놓입니다.
Claude Code는 dynamic workflows로 이걸 세션 안에서 직접 다룹니다. 한 창 안에서 그래프를 그리고 서브에이전트 함대를 조율해 결과를 합칩니다.
그럼 RelayRoom은 무엇을 하나요
지금의 RelayRoom은 그래프 아래에 놓이는 기층입니다. 그래프를 실행하는 엔진은 아닙니다. (더 나은 아키텍처나 엔지니어링 기법이 그 역할에 더 맞다면 우리는 언제든 방향을 바꿀 준비가 되어 있습니다. 다만 지금의 힘은 여기 있습니다.)
세션 안의 그래프는 Claude가 이미 잘 풉니다. 하지만 세션과 머신에 걸친 것들은 한 창 안의 그래프에 담기지 않습니다. 함대가 여러 워크트리, 여러 대의 기계에 흩어져 며칠에 걸쳐 일할 때 창 하나로는 아래 일들이 안 됩니다.
- 지속되는 정체성 - 누가 어느 part이고 재시작 후에도 그대로인가
- 메시지 지속성 - 대화가 사라지지 않고 남는가
- 깨움(wake) 전달 - 놀고 있는 에이전트를 그의 세션 안에서 깨우는가
- 관찰성 - 대시보드에서 함대 전체가 지금 뭘 하는지 보이는가
- 안전한 조종 - 사람이 하나를 조종하고 나머지가 협업하는가
RelayRoom이 하는 일이 바로 이것입니다. 오케스트레이션은 Claude와 오퍼레이터의 몫이고 RelayRoom은 그래프 아래에서 커뮤니케이션, 정체성, 상태, 지식, 전달, 가시성을 세션과 머신을 넘어 보존합니다.
RelayRoom의 설계에는 그래프 엔지니어링이 강조하는 규율 몇 가지가 이미 들어 있습니다.
- 격리 - part 하나당 워크트리 하나. 두 에이전트가 같은 파일을 건드리다 서로 덮어쓰는 사고를 구조적으로 막습니다.
- 앵커(못 건드리는 것) - RelayRoom 0.5.0의 Project Knowledge에서 지식을
trusted로 승격할 수 있는 건 오직 비-에이전트 발행자(서명된 CI 또는 사람)뿐입니다. 에이전트는 후보를learn할 수 있어도 스스로 승격하진 못합니다. 최적화되는 대상이 자기를 평가하는 기준을 움직이지 못하게 막는 장치가 앵커입니다. 그래프 엔지니어링이 "frozen 규칙"이라 부르는 것과 같은 모양이죠. - 깨끗한 컨텍스트의 검증 - 자기가 한 일을 자기 맥락에서 검토하면 "다른 폰트로 자기 자신에게 동의하는 것"일 뿐입니다. 검증은 신선한 눈에 맡깁니다.
0.5.0: 루프를 RelayRoom에 들이다
방금 나온 0.5.0은 루프 엔지니어링을 RelayRoom에 들인 릴리스입니다. 함대가 이미 만들어 낸 메시지와 이벤트 스트림을 축적되는 프로젝트 지식으로 증류합니다. 에이전트는 행동하기 전에 recall하고 배운 걸 learn합니다. 그래서 쓸수록 팀의 맥락이 조금씩 나아집니다. 그 개선은 마케팅용 벤치마크 대신 당신 프로젝트의 실제 지표로 증명합니다. 이게 깊이 축입니다.
루프·그래프 대비 RelayRoom의 장단점
어떤 기법도 만능은 아닙니다. RelayRoom을 두 흐름과 나란히 놓고 정직하게 봅니다.
루프 엔지니어링과 견주면
- 강점: 루프의 학습이 한 창 안에 갇히지 않고 지속되고 공유됩니다. 세션 안 루프는 창이 차면 잊지만 RelayRoom(0.5.0)의 지식은 세션을 넘어 남습니다. 한 에이전트의 교훈이 다른 에이전트의
recall이 됩니다. - 약점: 에이전트 하나가 한 가지를 반복 개선할 뿐이라면 RelayRoom은 불필요한 무게입니다. 타이트한 반복 속도는 세션 안이 더 빠릅니다.
그래프 엔지니어링과 견주면
- 강점: 그래프를 세션, 머신, 시간을 넘어 확장합니다. 한 창을 벗어나지 못하는 세션 안 그래프와 달리 여러 대의 기계에 흩어진 함대를 지속적 정체성으로 묶고 대시보드로 관찰하며 안전하게 조종합니다.
- 약점: 그래프를 실행하진 않습니다. 자동 팬아웃·검증·머지·토폴로지는 여전히 Claude와 오퍼레이터의 몫입니다. 한 창에 들어가는 폭이라면 Claude workflows가 더 가볍고 거기에 RelayRoom이 보탤 것은 없습니다.
그래서 지금 RelayRoom은 어디에 맞나요. 방금 나온 0.5.0으로 RelayRoom은 루프 엔지니어링(깊이)을 직접 소유합니다. 함대의 스트림을 축적되는 지식으로 바꾸는 것이 정확히 루프입니다. 그래프 엔지니어링(폭)에는 엔진이 아니라 기층으로 맞습니다. 세션 안 그래프가 머신을 넘어 지속되도록 아래에서 받칩니다. 스윗스팟은 그 사이의 지속·조정 계층입니다. 둘 다에 필요한데 세션 도구가 머신을 가로질러 주지 못하는 부분이죠.
우리가 가는 방향
지금 RelayRoom의 힘은 그래프 실행 아래에 놓인 기층에 있습니다. 기층이 흔들리지 않아야 그 위의 그래프를 믿을 수 있으니까요. 그래서 당분간은 정체성·지속성·깨움 전달·관찰성 같은 기층의 신뢰성을 더 단단히 다집니다.
경계를 정리하면 이렇습니다.
Claude와 오퍼레이터: 다음에 무엇을 돌릴지, 증거가 충분한지 결정한다. RelayRoom: 세션과 머신을 가로질러 커뮤니케이션, 정체성, 상태, 지식, 전달, 가시성, 안전한 조종을 보존한다.
동시에 우리는 이 경계를 교리로 여기지 않습니다. 더 나은 아키텍처나 엔지니어링 기법이 RelayRoom을 더 유용하게 만든다면 언제든 핸들을 돌릴 준비가 되어 있습니다. 지금의 판단은 지금의 증거에서 나왔을 뿐이고 다음 증거는 방향을 바꿀 수 있습니다.
프롬프터는 질문을 하고 아키텍트는 그래프를 그립니다. RelayRoom은 그 아키텍트가 딛고 설 바닥을 흔들리지 않게 잡아 둡니다. 더 나은 바닥이 보이면 주저 없이 그리로 옮겨 갑니다.