Offrun - 모든 코딩 에이전트를 하나의 작업 공간에서 관리
요약
본 글은 다양한 코딩 에이전트 오케스트레이터의 현황과 한계를 분석하며, 이상적인 개발 환경(ADE)에 대한 요구사항을 제시합니다. 사용자는 로컬/클라우드 등 분산된 자원을 통합하고, 작업 흐름을 '작업-목표-세션' 구조로 관리하는 에이전트 오케스트레이터를 필요로 합니다.
핵심 포인트
- 분산 환경(로컬/클라우드)의 자원 통합 및 관리가 핵심 요구사항입니다.
- 에이전트 활동 그래프보다, 작업 흐름을 시각화하고 상태 전환을 지정하는 기능이 중요합니다.
- 단순한 대화 기록 나열 대신, 질문-계획-발견 등 구조화된 UI 요소가 필요합니다.
- 안정성과 신뢰성 측면에서 기존 IDE(IntelliJ IDEA 등) 수준의 완성도가 요구됩니다.
도구가 이렇게 많다는 게 놀라우면서도 놀랍지 않음. paperclip, multica, perplexity computer도 추가를 고려해 보면 좋겠음.
필터도 추가할 계획인가요?
써 본 도구들은 모두 프로젝트·디렉터리·머신을 서로 결합해서 다루는데, 내 작업에는 다른 구조가 필요함. 최상위 프로젝트 아래 작업·목표·세션을 두고, 각각이 서로 다른 워크트리나 디렉터리, 심지어 다른 머신에서 실행되는 에이전트들로 뻗어 나가면 좋겠음.
메모와 맥락 자료는 로컬에 많고, 저장소와 빌드 도구는 다른 머신에 있음. 프런트엔드와 백엔드도 디렉터리는 다르지만 하나의 결과물을 만드는 데 모두 필요할 수 있음. 이런 구조를 지원하는 에이전트 오케스트레이터가 있나요?
목록에 추가할 도구가 더 있음. https://orchestrator.inc/, https://gitkraken.com/kepler, https://emdash.com/, https://superset.sh/, https://www.conductor.build/, https://nimbalyst.com/, https://parallelcode.app/, https://www.jetbrains.com/air/.
단일 하네스와 더 긴밀하게 통합하는 도구도 있음. ACP가 꽤 기본적인 기능만 제공하므로 솔직히 이쪽이 더 나아 보임. https://openchamber.dev/.
개인적으로 Paseo는 쓰기 좋았지만 가끔 하위 에이전트가 멈췄음. Kepler의 이슈 추적 도구 통합은 훌륭했지만, UI는 바이브 코딩으로 대충 만든 듯했음. 칸반 보드에서 작업을 직접 옮기거나 에이전트에게 상태 전환 방법을 지정하는 기본 기능보다, 에이전트 활동 그래프처럼 불필요한 기능을 계속 추가하는 느낌임.
그래도 이슈 통합 자체는 모든 하네스가 고려할 만함. 티켓을 고르면 워크트리가 생성되고, 에이전트가 조사·계획을 수행한 뒤 /grill-me 같은 방식으로 계획을 검토받고, 작업 묶음이 끝나면 원하는 시점에 워크트리를 병합할 수 있으면 좋겠음.
대부분 직접 써 보지는 않았지만, 어느 것도 확실히 안정적이라는 느낌이 들지 않아 놀라움. IntelliJ IDEA나 Rider는 자원을 많이 먹어도 작성·리팩터링·디버깅·빌드를 믿고 맡길 수 있음. 반면 현재 하네스들은 에이전트에게 지시하는 기본 기능부터 버그가 있고, 기존 제품의 복제에 그치는 경우도 많음. 마지막으로 확인했을 때 OpenCode는 하위 에이전트 내부를 보며 직접 지시하거나, 일시 정지하거나, 프롬프트를 바꾸는 것도 어려웠음.
그렇다고 하네스 자체의 데스크톱·웹 앱이 충분한 것도 아님. OpenCode 등은 Claude Code Desktop이나 Codex(ChatGPT 앱)보다 사용성이 떨어짐. 가로 탭이 30개쯤 되면 어떻게 탐색하라는 건지, UI에서 자동 모드 전환은 왜 안 되는지 의문임. 그러니 에이전트 개발 환경(ADE)은 분명 필요함.
5년 뒤에는 절반이 사라질지, 완성도와 차별성이 높아질지 궁금함. RooCode가 사실상 VSC 플러그인을 버리고 클라우드에 집중했듯, 어느 제품이 클라우드 전용으로 갈지도 궁금함.
근본적인 차이는 사람이 개입하는 구조(human-in-the-loop) 에 집중한다는 설계 철학임. 다른 메타 하네스가 에이전트의 참여에 초점을 맞춘다면 우리는 나머지 절반에 집중함. 앞으로 2개월 안에 기능을 완비할 예정이며, 클라우드와 Offrun 모바일 앱도 곧 출시할 계획임.
이런 도구는 많은데, 대부분 코딩 에이전트의 작업을 대화 기록으로 보여줌. 왜 그래야 하나요? 내부 대화 자체는 작업과 별개이고, 컨텍스트 창이 하나라는 건 구현 세부 사항일 뿐임.
직접 만든 도구에서는 질문·계획·발견·가정을 별도 UI 요소로 보여주고 대화는 숨김. 집중할 대상은 ‘다음에 무엇을 해야 하는가’임. 같은 접근을 취하는 메타 하네스가 있나요? 직접 만드는 일을 멈추고 이미 나온 제품을 쓰고 싶음!
계속 직접 만들면 어떨까요? 이런 도구의 99%와 비슷하거나 더 나을 수 있음.
나도 개별 에이전트와의 대화를 작업 관리의 중심으로 삼는 데 관심이 적음. 개인 대시보드는 프로젝트와 그 아래 워크트리를 보여주지만, 대화의 90%는 총괄 에이전트와 나눔. 이 에이전트가 여러 프로젝트 관리 에이전트의 정보를 요약하고, 내가 실제로 행동해야 할 때만 직접 답할 수 있는 질문 형태로 대시보드 타일을 갱신함.
작업 방식에 대한 선호를 추가할수록, 총괄 에이전트가 스스로 처리할 수 있는 일을 내게 묻는 빈도가 줄어듦.
Offrun을 개발하면서 그 접근을 염두에 두겠음.
Conductor를 쓰는 모습을 보고 찾아 쓰기 시작한 Orca가 개발 방식을 크게 바꿔 줌. 이런 관리 도구는 워크트리 생성 등 PR 관리를 자동화하고, 여러 기능을 병렬로 개발할 때 작업 전환도 크게 가속함. Offrun과 댓글에 나온 대안들이 내게 더 잘 맞는지 써 보고 싶음.
나는 에이전트가 Git 쓰기 작업을 전혀 하지 못하게 함.
이 시장은 아직 주인이 정해지지 않은 영역이라고 봄. 세부 시장마다 어떤 수요가 있는지, 누가 이를 제대로 충족할지도 불분명함. 시장과 틈새 수요, 앞으로의 방향 자체를 아직 잘 이해하지 못하는 듯함.
변화도 매우 빨라서 익숙하게 굳어진 작업 흐름조차 새로운 UX나 도구가 나오면 급격히 교체됨. 나도 이 분야에서 무언가 만들고 있지만 안개 속을 걷는 느낌이고 목표도 자주 움직임. 이 영역을 정리한 좋은 조사 자료나 분석이 있나요?
몇 가지를 써 봤지만 겉보기에는 멋져도 결국 버그·특이 동작·제약이 있었음. 충돌 한 번에 모든 세션을 잃을 수 있는 도구에 진행 중인 작업을 너무 많이 밀어 넣는 느낌이었음.
내게는 Herdr 터미널 멀티플렉서와 자체 오케스트레이터를 분리하는 방식이 잘 맞음. 오케스트레이터는 실제 필요에 따라 키웠고, 처음에는 wt(worktrunk)의 최소 재구현이었지만 이제는 Herdr API로 실행과 탐색을 돕는 여러 TUI가 통합된 형태임.
ccwt를 고칠 때는 에이전트에게 수정을 맡기고 병합·재빌드하면 Herdr 탭에서 자동 갱신·재시작됨. 변경할 때마다 에이전트의 바깥 실행 환경까지 교체할 필요가 없음. Herdr 자체를 재설치할 때도 기존 세션에 다시 연결되는 경우가 많지만, 가끔은 에이전트를 모두 재시작해야 하고 진행 알림 상태도 잃게 됨.
다른 사람이 바로 쓸 도구라기보다 이런 구조가 가능하다는 예시임. https://github.com/mkmik/acmik.
이번 주 초에도 에이전트에게서 비슷한 제품을 제안받았음. 내게 맞는 제품은 아니지만, 이것도 Apple Silicon Mac 전용이라는 같은 제약이 있음. Linux·Windows·Intel Mac은 지원하지 않음. 다른 댓글에 나온 Herdr는 이 플랫폼을 모두 지원하고 600만 달러를 투자받은 듯함.
이런 도구를 볼 때 또 묻게 되는 건 내 자체 하네스와 통합되는가, 그리고 직접 바이브 코딩해서 만들 수 없는 무엇을 제공하는가임.
현재는 Apple Silicon과 Intel Mac 모두 지원하며, Windows와 Linux 버전도 곧 출시할 예정임. Herdr·Pi·Opencode 통합과 사용자 정의 하네스 추가 기능도 작업 중임.
물론 직접 만들 수도 있음. 우리는 Claude·Codex·Pi·Opencode 등을 쓰면서 부족하다고 느낀 부분을 바탕으로 만들고 있음.
직접 만들거나 마음에 드는 도구를 골라 수정하면 됨. 제품마다 충족하는 요구가 다르고, 사용자의 사고방식과 목표에 따라 각자 장점이 있음.
나도 한 달이 채 안 돼 자체 도구를 만들기 시작했고, 일주일 뒤 Show HN에 올렸음. 내 필요에 맞춰 기능을 추가했더니 여러 프로젝트를 관리하는 피로가 크게 줄었음. 특히 에이전트보다 프로젝트 중심으로 반복 작업을 하고, 사람이 완전히 통제하도록 설계했음. 같은 날 몇 시간 먼저 올라온 다른 도구가 더 큰 관심을 받고 HN 첫 페이지에 올랐는데, 그 도구도 훌륭할 거라 생각함.
어제는 같은 조직의 개발자도 기존 도구나 내가 만든 것을 모른 채 비슷한 걸 만들고 있었음. 서로 겹치는 부분이 보여 참고할 프로젝트도 알려줬음. 이렇게 많은 사람이 이 영역을 탐색하는 게 멋짐.
최신 모델은 능력이 뛰어나서 결과물을 검토할 필요를 점점 덜 느끼고, 신뢰도 커지고 있음. 앞으로는 개발자가 자기 방식대로 도구를 만들거나, 오픈소스를 복제해 자신만의 버전으로 수정하고 원본에 기여하지 않은 채 갈라져 나가는 일이 늘어날 것 같음.
완제품의 편의를 택하는 사람도 있겠지만, 프롬프트로 불편한 부분을 고칠 수 있다면 설정 항목이나 남의 수정을 며칠씩 기다릴 필요가 없음. 로컬에서 빌드할 수만 있으면 원하는 방식으로 동작하는 버전을 만들 수 있음. 업계 관점에서는 가끔 무섭지만 동시에 놀라운 변화임.
내 도구: https://github.com/pausan/agenttik.
2주 전 Show HN: https://news.ycombinator.com/item?id=49720222.
같은 날 더 큰 관심을 받은 Show HN: https://news.ycombinator.com/item?id=49713894.
작업 도중 막힌 뒤가 아니라, 작업을 보내기 전에 계정별 사용 한도 잔여량을 보여주면 좋겠음.
Offrun의 핵심은 사용자가 몰입을 유지하도록 하는 데 있음. 세션·계정 한도에 도달하더라도 클릭 한 번으로 다른 계정으로 전환해 끊김 없이 작업을 이어갈 수 있음.
“and what every account has left.”라는 문구는 왜 LLM이 쓴 글처럼 느껴질까요?
LLM이 쓴 문장에는 무생물을 능동적인 주체로 놓는 경향이 있다는 글을 읽은 적이 있음.
이 웹페이지 전체를 Claude가 썼기 때문임.
사람이 방향을 제시하고 LLM이 작성한 게 맞음. 우리가 향하는 미래가 그런 모습 아닌가요?
“이것이 핵심”, “당신이 놓치고 있는 것” 같은 낚시성 LLM 특유의 문구와 비슷하게 느껴짐.
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기