IRC로 돌아간 에이전트 하네스 전쟁 — 오르카는 무겁고, 가재는 OMP를 빼닮았다

저녁 7시 44분, 한 참여자가 무심코 던진 한마디가 방을 발칵 뒤집었다.

"omp 돌리다가 서브에이전트들끼리 통신하는거 로그에 IRC가 적혀있는데 이 IRC가 제가 옛날에 알고 있던 그 IRC일지..."

곧바로 반응이 쏟아졌다. "IRC 는 일대일 통신 프로토콜인데 설마 요즘 시대에요"라는 놀라움에 이어, "mIRC 이런거 들어가고 그랬던 기억이"라는 추억담, "Irc.. 하시던분들.백골이 진토된거 아닌가요"라는 농담까지 붙었다. 서브에이전트들끼리 작업을 주고받는 통신 방식으로 하필 1990년대 채팅 프로토콜의 이름이 로그에 찍혀 나온 것이다.

진짜 IRC는 아니었다

궁금증을 못 참은 참여자들이 직접 문서를 뒤지기 시작했다. 한 참여자가 실제 구조를 확인해 정리했다.

"inter agent irc라고" "실제 irc를 그대로 쓰는건 아니고" "pseudo irc라고 채널 닉네임 메시지 대기를 가져와서 채팅서버 비슷하게 만들어서 상호작용하도록 구성해놨네요"

다른 참여자는 이를 "채팅서버에 여러 클라이언트가 1:n으로 묶이는 구조"라고 요약했다. 즉 실제 IRC 표준을 그대로 구현한 게 아니라, 여러 서브에이전트가 한 채팅방에 모여 메시지를 주고받는 구조를 옛 개념에 빗대 이름 붙인 것에 가까웠다.

"오르카 야 무겁다 너" — 메모리 불만

같은 시각 다른 한쪽에서는 오르카(Orca)를 향한 불만이 터져 나오고 있었다.

"Orca 야 무겁다 너 .."

맥북 24GB 메모리로도 버거워하는 참여자도 있었다.

"오르카 계속 뻗어요.. 내 맥북 24g인데.."

또 다른 참여자는 "orca + cli 로 하는데 orca 가 개노답무겁"이라며 CLI로 돌려도 무거운 건 마찬가지라고 토로했다. 이 불만은 밤늦게까지 이어졌다. 새벽 시간대 한 참여자는 발열 문제까지 언급했다.

"오르카에서 omp 돌리니까 무릎이 뜨거워져서 여름에는 힘드네요 ㅋㅋㅋ (맥북 발열..)"

다음 날 낮에도 두 도구를 함께 돌리는 이들의 메모리 부담은 여전했다. 한 참여자가 "orca +. omp" 조합 화면을 공유하자, 다른 참여자는 "저도 orca omp 쓰는중 (2일됨)"이라고 맞장구쳤고, 이를 지켜본 참여자는 "최고입니다 그 조합, 대신에 메모리도 최고 한도로 써버리죠 ㅠ"라며 씁쓸한 웃음을 지었다.

팀모드가 예고한 것 — 하이퍼플랜

메모리 불만과 별개로, OMO의 다음 기능을 향한 기대도 뜨거웠다. 아직 정식 공개 전인 팀모드 기능을 미리 활용해보고 있다는 한 참여자는 이렇게 소개했다.

"팀모드 나오면 오모에 있는 하이퍼플랜이라는 기능이 들어가는데 gpt 5.6 sol / kimi / fable / glm / opus / grok 이 토론해서 플랜이 나옵니다"

같은 참여자는 "본질적으로 gpt 5.6 sol pro 보다 좋을수밖에없음"이라고 덧붙였다. 여러 모델이 한 자리에서 계획을 놓고 토론한 뒤 합의된 플랜을 내놓는 방식이라는 설명이었다. 도구 호출 방식에 대한 소개도 이어졌다. 같은 참여자는 파이썬 코드로 도구를 호출하는 기능을 소개하며 "20개씩 막 동시에 호출하기도합니다"라고 전했고, 정작 병목은 "제 노트북 램과 cpu"라는 자조 섞인 진단도 함께 내놨다.

"가재가 omp 거의 포크 수준이었군요"

다음 날 오후, 대화는 국내에서 널리 쓰이는 '가재코드' 하네스로 옮겨갔다. OMP를 처음 써본 한 참여자가 놀라움을 감추지 못했다.

"omp를 처음 써봤는데 가재가 omp거의 포크 수준이었군요"

같은 참여자는 TUI 화면부터 낯익다고 말했다.

"엄청 비슷하네요 tui가" "딱 omp tui 처음 들어가서 보는데 낯익은거임"

다른 참여자도 가세해 OMP로 넘어온 소감을 전했다.

"저솔직히 가재 쓰다가 오류가너무많아서" "연규님이 omp쓴다길래 넘어왓는데" "진짜 너무만족중"

완성도 비교도 나왔다. "omp가 완성도가 훨씬 좋긴하네요 UX입장에서"라는 평가에, 가재코드 쪽 사용자를 놀리듯 "가재 귀막아!!"라는 농담이 붙기도 했다. 다만 원조 격인 OMP에는 없는 기능도 지적됐다. 가재코드 사용자는 "물론 딥인터뷰 울트라 플랜 뭐그런건 없지만" "진짜 속뻥뚤ㄹ림"이라며 기능은 부족해도 체감 만족도는 높다고 정리했다.

완성된 랜딩페이지, 계획 단계의 PPT

하네스 비교는 곧 실전 사례로 이어졌다. 한 참여자는 자기 전에 지시 하나만 던져놓고 잠들었다고 전했다.

"자기전에 돈벌 랜딩페이지하나 만들어라 했는데 omo native 가 만들어줬습니다"

같은 참여자는 결과물의 완성도에 놀라며 "kimi3 omo 에 태우니까 Fable 급이네요"라고 평가했다. 이 랜딩페이지는 실제로 밤사이 완성된 결과물이었다. 반면 PPT 쪽은 아직 계획 단계였다. 월요일 발표를 앞둔 다른 참여자는 자료를 준비해야 하는 상황을 전하며 이렇게 밝혔다.

"월욜에 쓸 ppt" "omo native + slides grab으로 뽑아봐야겟네요"

같은 참여자는 "ulw research 돌려두고" 있다며 아직 결과물을 뽑기 전, 준비 중인 단계임을 분명히 했다. 리서치 기능을 먼저 써본 다른 참여자는 "딥리서치돌린거보다 조은 결과물이" 나온다고 기대감을 보탰다.

비용에 대한 냉정한 평가도 함께였다. 플래닝 단계에만 활용해도 "건당 api 비용으로도 20불 안넘지않나요"라는 계산이 나왔지만, 실제 써본 참여자는 "그렇긴한데 막 다른애들이랑 비교해보면" "확실히 비싼거 같기는해요 근데 퀄리티가 충분해서 좋긴한데"라며 비용과 품질 사이에서 여전히 저울질하는 모습을 보였다.

커서와 데빈, 그 사이의 온도차

에이전트 하네스 논쟁은 국내 커뮤니티를 넘어 커서(Cursor)와 데빈(Devin) 이야기로도 번졌다. 커서를 실제로 써본 참여자는 만족감을 이렇게 전했다.

"커서 좋아요 ui ux 최적화 잘되어있는데다가 plan -> executor까지 경로가 아주 맘에 듭니다 투두리스트 수정도 좋고 괘니 인수된게 아닌 듯. 그리고 커서도 나름 자기들만의 철학으로 long running agent 구축해서 시스템적인 접근도 좋더라구요."

데빈을 둘러싼 평가는 엇갈렸다. "데빈은 신" "데빈이 요즘 엄청 좋아졌어요"라는 호평이 나온 반면, 다른 참여자는 시장 포지션을 두고 이렇게 짚었다.

"Devin 이 제일 기대받는회사엿는데 커서가 밀어버려서 글치"

같은 참여자는 구글의 윈드서프 인력 인수와 코그니션의 데빈 이식을 얽어 업계 뒷이야기도 전했다.

"구글이 윈드서프 핵심인력 인수해서 안티그라비티를 내놧습니다 여러분" "그런 뒤 빈껍데기를 코그니션이 인수해서 데빈에 이식햇다고 조리돌림 당햇습죠"

이 흐름에서도 결국 OMP가 다시 언급됐다. 한 참여자는 "omp에서 데빈 로그인이 되거든요"라며, 하네스 하나로 여러 외부 에이전트 서비스까지 끌어와 쓸 수 있다는 점을 소개했다.

왜 주목할 만한가

이날 방을 관통한 흐름은 하나였다. 오르카의 무게, OMP의 정체 모를 IRC, 가재코드의 포크 논란, 완성된 랜딩페이지와 계획 단계의 PPT, 커서·데빈 비교까지 — 모두 결국 "어떤 하네스에 무엇을 태울 것인가"라는 질문으로 수렴했다. 특정 모델의 성능 자체보다, 여러 모델을 어떻게 조합하고 어떤 그릇에 담아내느냐가 실사용자들의 체감을 더 크게 좌우하고 있었다.

특히 가재코드가 "omp 거의 포크 수준"이라는 지적은 곱씹을 만하다. 국내 커뮤니티에서 익숙하게 써온 도구가 해외 오픈소스 하네스의 구조를 상당 부분 이어받았다는 사실이 그 자리에서 처음 알려진 셈이다. 그럼에도 완성도 차이를 인정하면서도 "진짜 너무만족중"이라는 반응이 동시에 나온 것은, 원조냐 아니냐보다 지금 손에 익은 도구가 실제로 얼마나 잘 굴러가는지가 더 중요하다는 실사용자들의 태도를 보여준다. 자는 사이 지시 한 줄로 완성된 랜딩페이지와, 아직 리서치를 돌려두는 단계에 머문 PPT 계획은 — 이 하네스 경쟁이 이미 손에 잡히는 결과물과 앞으로의 기대가 뒤섞인 채로 진행되고 있음을 보여준다.