프록시 끊기자 하네스 전체가 자동으로 갈아탔다

16일 아침 9시 15분, 에르메스단에서는 직접 짜거나 개조한 에이전트 하네스(Harness, 여러 모델을 붙여 실행하는 도구 틀)를 둘러싼 운용기가 올라왔다. 한 참여자는 omo를 쓰다가 결국 다시 코덱스로 돌아왔다고 전했다.

omo 쓰다가 돌고 돌아 다시.. 코덱스로갑니다

오후 3시 5분에는 다른 참여자가 예상치 못한 장애 상황을 전했다. 오픈코덱스(OpenCodex) 프록시 연결이 끊기면서, 오케스트레이터(Orchestrator, 여러 에이전트의 작업을 조율하는 상위 에이전트)와 워커 에이전트들이 전부 자동으로 다른 모델로 전환돼 컴팩트(Compact, 대화 맥락을 요약해 압축하는 처리)된 상태로 작업이 계속됐다는 사례였다.

오픈코덱스 프록시 연결 끊겨서 오케스트레이터랑 워커들 죄다 자동으로 루나 리버스로 바뀌는 바람에 일괄 compact 되고 그 상태로 루나가 오케스트레이팅하고 루나 워커가 일하고

저녁 5시 12분과 13분에는 또 다른 참여자가 자신이 쓰는 도구를 소개했다. 어사이드(Aside)가 지원하지 않는 프로젝트별 채널·스레드 관리 기능을 키마키가 대신해준다는 설명이었다.

키마키는 어사이드가못하는걸해줘요

키마키는. 프로젝트별 채널관리, 스레드관리가돼서

여러 도구 이름이 짧은 시간 안에 오갔다는 사실 자체도, 이 방의 참여자들이 특정 하네스 하나에 정착하기보다 상황에 따라 도구를 갈아타는 데 익숙하다는 것을 보여준다. 예기치 않은 프록시 장애 앞에서도 당황하기보다 사례를 공유하며 대응 경험을 축적해 나가는 모습도 눈에 띈다.

이 화두에는 190건의 메시지에 22명이 참여했다. omo·코덱스·키마키 등 도구 이름은 저마다 달랐지만, 공통적으로 드러난 건 참여자 대부분이 기성 제품 하나에 정착하지 않고 여러 하네스와 오케스트레이터를 오가며 쓰고 있다는 점이다. 특히 프록시 장애로 오케스트레이터와 워커가 사용자 개입 없이 다른 모델로 자동 전환됐다는 사례는, 이런 커스텀 구성이 편의성만큼이나 예기치 않은 장애에도 취약할 수 있음을 시사한다. 동시에 그 장애 속에서도 작업이 끊기지 않고 이어졌다는 점은, 자동 전환·컴팩트 같은 장애 대응 체계가 이미 일상적인 운용 경험의 일부로 자리 잡았다는 뜻으로도 읽힌다. 어사이드처럼 잘 알려진 도구가 다루지 못하는 세부 기능을 별도 도구로 보완하는 모습도, 단일 제품보다 여러 도구를 조합해 쓰는 이 커뮤니티의 운용 성향과 맞닿아 있다.