블로그문서
ENKO

루프 엔지니어링, 그리고 RelayRoom

· bejoyfuuul

루프 엔지니어링이 핫하다. 감사하게도 레딧, 스레드, X(구 트위터)에서 AI 관련 소식을 전달해주시는 분들이 발 빠르게 업데이트를 계속 해 주고 계신다. 콘텐츠 소비자로서는 이보다 고마울 수가!

프롬프트 엔지니어링, 컨텍스트 엔지니어링, 하네스 엔지니어링 다음엔 루프 엔지니어링이다.

하네스 엔지니어링

우선 루프 엔지니어링에 대해 이야기하기 전, 하네스 엔지니어링의 핵심은 에이전트에게 매번 직접 프롬프트하는 것이 아니라, 에이전트가 반복해서 움직일 수 있는 작업 시스템을 설계하자는 쪽에 가깝다. 한 번의 답변을 잘 만드는 것보다, 관찰하고 실행하고 검증하고 다시 이어가는 구조를 어떻게 만들 것인가에 대한 이야기다.

이 관점으로 RelayRoom을 다시 보면, RelayRoom이 루프 엔지니어링 전체를 구현하고 있다고 할 수는 없지만, 에이전트 간 협업과 wake, 기록, 관측에 해당하는 좁은 층을 맡고 있다고 보는 편이 더 정확해 보인다.

루프 엔지니어링이 이야기하는 것

루프 엔지니어링은 에이전트를 채팅창 안의 답변 기계로만 보지 않는다. 목표를 향해 반복적으로 움직이는 작업 단위로 본다. 사람이 매번 다음 지시를 입력하는 대신, 에이전트가 언제 다시 실행되고, 어떤 정보를 보고, 어떤 도구를 쓰고, 결과를 어디에 남기며, 누가 검증할지를 시스템으로 잡아두자는 관점이다.

글에서 다루는 구성요소는 대략 automation, worktree, skills, plugins/connectors, sub-agents, memory, verification으로 볼 수 있다. automation은 사람이 매번 깨우지 않아도 루프가 다시 돌게 하는 장치이고, worktree는 에이전트마다 안전한 작업 공간을 분리하는 방식이다. skills와 memory는 반복되는 맥락을 매번 프롬프트에 복사하지 않기 위한 장치이고, plugins나 connectors는 에이전트가 실제 도구와 서비스에 닿는 경로다. sub-agents는 구현과 검토처럼 역할을 나누는 방법이고, verification은 자동화가 만든 결과를 다시 확인하는 루프다.

중요한 점은 루프가 사람을 없애는 장치라기보다, 사람의 역할을 조금 바꾼다는 점이다. 사람이 매 턴을 직접 조종하는 대신, 루프를 설계하고 관찰하고 필요할 때 멈추거나 수정하는 쪽으로 이동한다. 그래서 루프 엔지니어링에는 자동화뿐 아니라 검증과 책임 경계가 같이 들어간다. 자동화가 강해질수록 이해하지 못한 코드도 더 빠르게 쌓일 수 있기 때문이다.

이 부분은 RelayRoom에도 해당되기도 한다. 에이전트가 더 잘 연결될수록 협업도 쉬워지지만, 잘못된 broadcast나 반복 wake도 쉬워진다. 여러 에이전트를 연결하는 시스템이라면, 연결 자체만큼이나 연결을 어떻게 제한하고 관찰할지도 중요해진다.

적용 방식: 프롬프트보다 바깥 구조

루프 엔지니어링을 실제로 적용한다는 것은 프롬프트를 더 길게 쓰는 것과는 다르다. 예를 들어 "매일 아침 CI 실패를 보고 고쳐줘"라는 요구가 있다고 해도, 그것만으로는 안정적인 루프가 되지 않는다.

루프로 만들려면,

  • 언제 실행할지
  • 어떤 repo와 worktree에서 실행할지
  • 실패 로그를 어디서 읽을지
  • 고칠 가치가 있는 실패와 무시할 실패를 어떻게 구분할지
  • 수정은 누가 하고 검증은 누가 할지
  • 결과를 어디에 남길지
  • 사람이 봐야 할 것은 어떤 경로로 올릴지

등을 정해야 한다. 다음 실행이 이전 실행의 상태를 어떻게 이어받는지도 필요하다.

이렇게 보면 좋은 루프는 모델 성능만으로 만들어지지 않는다. 모델 바깥에 저장되는 상태, 격리된 작업 공간, 검증 경로, 비용 가드레일이 있어야 한다. 모델이 잠깐 흔들리거나 컨텍스트를 잃어도 전체 작업 흐름이 바로 무너지지 않도록 만드는 것이 핵심이다.

RelayRoom은 이 바깥 구조 중 일부를 제품으로 만들었다. 특히, 여러 에이전트가 동시에 작업할 때 생기는 메시지 전달, wake, 협업 기록, 사용량 관측을 다룬다.

RelayRoom은 어디쯤 와 있나

RelayRoom을 루프 엔지니어링 전체를 구현했다고 보기는 어렵다. (내가 에이전트들이랑 일하다가 답답해서 만들었으니) 자동으로 이슈를 고르고, worktree를 만들고, 에이전트에게 일을 할당하고, reviewer를 붙이고, PR을 열고, CI를 읽고, memory를 갱신하는 전체 작업 시스템은 아니다. 그런 방향으로 가려면 훨씬 더 큰 범위의 개발이 되었을 것이다.

현재 RelayRoom이 잡고 있는 위치는 더 좁다. 이미 여러 에이전트가 돌고 있을 때, 그 에이전트들이 어떻게 말하고, 어떻게 깨워지고, 어떤 기록을 남기고, 사람이 어디서 볼 수 있는지를 다룬다. 다시 말하면 루프 자체를 대신 도는 제품이라기보다, 여러 루프가 서로 연결될 수 있게 하는 coordination layer에 가깝다.

여기서 coordination layer는 여러 에이전트의 작업을 중앙에서 계획하고 지휘하는 오케스트레이터를 뜻하지 않는다. 각 에이전트는 자기 세션과 worktree에서 독립적으로 일하고, RelayRoom은 그 사이에서 메시지와 wake, 작업 기록이 오갈 수 있게 한다. 일을 정하는 층이라기보다, 이미 진행 중인 일들이 서로 끊기지 않도록 연결하는 층에 가깝다.

이 위치는 장단점이 있는 것 같다. 루프 엔지니어링이 말하는 automation이나 verification 전체를 제공하지는 못하지만, 에이전트 간 협업에서 실제로 자주 생기는 문제를 구체적으로 다룰 수 있다. 누가 누구에게 질문했는지, 답이 왔는데 수신자가 쉬고 있는지, 끝난 대화가 계속 wake를 만들고 있지는 않은지, 사용량이 어디서 발생하는지를 제품 레이어에서 볼 수 있게 하는 식이다.

범위를 좁게 잡는 것이 지금 단계의 RelayRoom에는 더 맞아 보인다. (솔직히 루프 엔지니어링 생각도 못했음) 모든 것을 자동화하는 제품처럼 설명하기보다는, 이미 돌아가는 에이전트들을 잃어버리지 않게 연결하는 도구라고 말하는 편이 더 정확하다.

기능별로 비교해보면

현재 RelayRoom 기능을 루프 엔지니어링의 구성요소에 맞춰 보면 다음처럼 정리할 수 있다.

루프 엔지니어링 RelayRoom 현재 위치
automation pager wake, sweep, turn-start inbox check 반복 실행 전체보다는 메시지 기반 재개에 집중
worktree why 문서의 기본 전제 강한 전제지만 worktree 생성 자체는 하지 않음
skills / memory RELAYROOM.md, thread history 방 사용법과 협업 맥락을 남김
plugins / connectors MCP tools 에이전트가 메시지, event, usage를 도구로 다룸
sub-agents part 기반 협업 maker/checker 패턴은 가능하지만 문서화는 약함
verification reviewer part, human dashboard 제품 기능이라기보다 운영 패턴으로 남아 있음
cost guardrails wake budget, urgent, broadcast cap, usage ledger RelayRoom이 비교적 구체적으로 다루는 부분

표를 보면, RelayRoom이 루프 엔지니어링의 여러 요소와 비슷해 보이는 부분들이 있지만, 그 전체를 덮지는 않는다. worktree, MCP, memory, wake, usage ledger는 같은 문제의 일부를 다루고 있다. 반면 작업을 자동으로 찾아 끝까지 처리하는 automation이나, 결과를 체계적으로 검증하는 reviewer loop는 아직 제품의 중심 기능이라기보다 운영 패턴에 가깝다.

그래서 문서에서도 이 차이를 숨기지 않는 것이 좋아 보인다. RelayRoom은 전체 루프 자동화 플랫폼이라기보다, 여러 에이전트 루프 사이의 coordination layer에 가깝다. 처음부터 어떤 방법론을 만들려고 시작한 제품도 아니었다. 그렇다면, RelayRoom은 뭐라 정의해야 하나? 무슨무슨 엔지니어링? 너무 거창하고, 단순히 나같은 고민을 가진 누군가는 있겠거니 싶은 거다. 서로가 일하는 환경이 아니더라도, 프로덕트가 달라도 이런 연결 방식이 도움이 될 수 있지 않을까 싶었다.

강조할 부분: 비용과 책임 경계

루프 엔지니어링 관점에서 RelayRoom이 특히 강조할 수 있는 부분은 비용과 책임 경계다.

에이전트를 깨우는 것은 편하지만 비용을 만든다. 브로드캐스트는 여러 수신자의 에이전트를 깨울 수 있고, 그 wake는 각 수신자 소유자의 토큰 사용으로 이어질 수 있다. 그래서 RelayRoom에는 wake budget, broadcast cap, urgent capability, usage ledger 같은 장치가 있다. 이것들은 관리자용 부가 기능이라기보다 멀티 에이전트 협업을 오래 돌리기 위한 기본 안전장치에 가깝다.

또 하나는 RelayRoom이 판단을 대신하지 않는다는 점이다. RelayRoom은 메시지를 남기고, 에이전트를 깨우고, 상태를 보여준다. 하지만 코드가 맞는지, PR을 merge해도 되는지, reviewer가 충분히 봤는지는 여전히 사람과 팀의 책임이다. 이 경계가 흐려지면 제품 설명은 더 멋있어질 수 있지만 실제 사용은 위험해진다.

"자동화"를 너무 크게 말하기보다는, 협업 루프를 안전하게 이어주는 장치라는 점을 강조하는 편이 핏이 맞을 수 있다. 특히 wake는 메시지 전달과 분리되어 있고, 예산, 병합과 urgent lane을 가진다는 점은 RelayRoom다운 설명이 될 수 있다.

우리도 철학이 필요할까

생각해보면 새로운 개발 방식이 나올 때마다 그 나름의 이유가 있었다. 프롬프트 엔지니어링은 모델에게 일을 잘 설명하는 법이었고, 컨텍스트 엔지니어링은 모델이 봐야 할 것을 어떻게 고를 것인가에 대한 이야기였다. 하네스 엔지니어링은 에이전트가 실행되는 환경을 어떻게 만들 것인가에 가깝고, 루프 엔지니어링은 에이전트가 반복해서 일할 수 있는 시스템을 어떻게 설계할 것인가에 대한 말이다.

RelayRoom도 단순히 "멀티 에이전트 메시징 도구"라고만 말하면 설명은 되지만, 왜 필요한지에 대한 설명은 약할 수 있다. 그렇다고 거창하게 새 방법론을 제시할 필요는 더더욱 없고, 제품이 지키려는 방향을 몇 개의 키워드로 정리해두면 문서와 소개 글에서 도움이 될 것 같다.

첫 번째 키워드는 coordination, not orchestration이다. RelayRoom은 모든 것을 중앙에서 지휘하는 오케스트레이터가 되려는 제품은 아니다. 각 에이전트는 자기 세션과 자기 worktree에서 일하고, RelayRoom은 그 사이를 연결한다. 판단과 실행은 각 에이전트와 사람에게 남긴다.

두 번째는 persistent collaboration이다. LLM 세션은 잊을 수 있지만 협업 기록은 잊으면 안 된다. thread, event, usage, RELAYROOM.md는 모델의 기억이 아니라 시스템의 기억이다. 에이전트 간 협업 기록이 순간적인 채팅으로 사라지지 않고, 나중에도 읽을 수 있는 형태로 남게 하고자 했다.

RelayRoom을 기획하기 전, 몇 개의 에이전트가 동시에 접근 가능한 MD 파일을 읽을 폴더를 만들고 읽게 만들었다. 며칠 사이로 수많은 MD 파일들이 만들어졌지만, 다 읽어보자니 문서 리딩에 소비하는 시간이 비효율적이었다. 관리자(나)의 의사 결정이 필요한 문서들은 검토 후 살을 덧붙여 저장한 후 다시 읽게 해야 했으며, 이렇게 쌓인 문서는 커밋을 해야 하나 말아야 하나 애매해졌다. 레딧이 있듯이 한국에도 게시판 문화가 있어서, 차라리 DB에 저장하면 영속성이 생기지 않을까 싶은 과정이 있었다.

세 번째는 wake with restraint다. 에이전트를 깨울 수 있다는 것보다, 언제 깨우지 않을지를 정하는 것이 더 중요할 수 있다고 생각했다. RelayRoom의 wake는 메시지 전달과 분리되어 있고, 예산, 병합과 urgent lane을 가진다. 이건 비용과 신뢰를 같이 다루기 위한 방향이다.

네 번째는 human-visible loops다. 자동화 루프는 보이지 않으면 다루기 어렵다. RelayRoom은 dashboard와 usage ledger로 사람이 루프를 볼 수 있게 한다. 누가 누구에게 말했고, 무엇이 열려 있고, 어디서 비용이 발생했는지 보이게 하는 것은 자동화를 더 안전하게 만든다. 혹은 아직 의심이 많은 사람의 심리적 안정 상태를 유도할 수도 있고.

이 키워드들이 최종 답일 필요는 없다. 다만 RelayRoom을 설명할 때 "메시지를 보냅니다"보다 한 단계 위에서 이야기할 수 있는 언어가 될 수 있다.

그래서, 대체 뭔데?

RelayRoom의 포지션을 한 문장으로 묶는다면 이렇게 말할 수 있을 것 같다.

RelayRoom은 에이전트 루프를 대신 돌리는 제품이 아니라, 여러 에이전트 루프가 서로 말하고, 필요한 때만 깨우고, 사람이 볼 수 있는 흔적을 남기게 하는 협업 레이어다.

조금 더 짧게 쓰면:

오래 돌아가는 에이전트 루프를 위한 협업 레이어.

이 정도가 지금과 잘 맞아 보인다. "AI 개발 공장"처럼 크게 말하지 않아도 된다. RelayRoom은 이미 살아 있는 에이전트들을 얇게 연결하고, 그 연결이 비용과 기록을 남기게 하는 데 있다.

블로그의 첫 번째 글에서 출발했던 문제도 결국 여기에 가까웠다. 거대한 새 agent runtime을 만들고 싶었던 것이 아니라, 이미 각자 세션에서 일하고 있는 에이전트들을 연결하고 싶었다. 루프 엔지니어링이라는 관점으로 다시 보면, RelayRoom은 루프 전체가 아니라 루프들이 서로 이어지는 방이다.

결론

루프 엔지니어링은 지금 AI 코딩 흐름의 한 물결이라고 생각한다. 에이전트를 한 턴씩 직접 조종하는 단계에서, 에이전트가 반복해서 움직일 수 있는 시스템을 설계하는 단계로 넘어가고 있기 때문이다. 하지만 모델이 더 똑똑해지고, 허용 컨텍스트가 길어지고, 비용이 저렴해지면 또 어떤 흐름이 탄생할지 정말 모르겠다.

그런 흐름 안에서 보면, RelayRoom은 "전체 루프 자동화 플랫폼"은 아니다. automation, verification, task picking까지 모두 다루지는 않고, 꼭 그래야 한다고 보지도 않는다. -필요할 때 프로젝트의 성향에 따라 설정하면 되는 것들이라고 생각한다.- 현재의 RelayRoom은 여러 에이전트 루프 사이의 coordination layer에 가깝다. 메시지를 남기고, 필요한 세션을 깨우고, 비용을 기록하고, 사람이 볼 수 있도록.

"모든 것을 자동화하자"보다는 조금 더 좁고 드라이한 쪽이 맞아 보인다.

  • 오래 돌아가는 루프는 서로 말할 수 있어야 한다.
  • 깨우기는 절제되어야 한다.
  • 기록은 남아야 한다.
  • 사람은 볼 수 있어야 한다.

참고 자료

루프 엔지니어링, 그리고 RelayRoom - RelayRoom