오르카 AI(Orca)를 설치했다가 하루 만에 접은 분, 생각보다 많을 거예요. 저도 첫날엔 “그래서 이걸로 뭘 하라는 거지” 하고 창을 닫았거든요. 그래도 2주를 다시 붙어서 써 보고 내린 결론은 분명해요. 에이전트 하나 띄워 놓고 끝나기를 지켜보던 습관을 버리고, 작업을 쪼개 여러 에이전트에 나눠 맡기기 시작하면 그때부터 값을 해요.
어디에서 쓸모가 생겼고 어디에서 막혔는지, 윈도우 데스크톱에 Claude Code를 물려 쓴 2주의 기록을 그대로 정리했어요.
오르카 AI는 뭐 하는 도구인가요 — IDE가 아니라 ADE
오르카 AI는 Y Combinator가 투자한 스타트업 Stably AI가 만든 오픈소스 ADE(Agent Development Environment)예요. IDE가 사람이 코드를 치라고 만든 환경이라면, ADE는 사람이 에이전트를 부리라고 만든 환경이에요. Claude Code·Codex·OpenCode 같은 CLI 코딩 에이전트를 40종 넘게 지원하고(2026년 8월 공식 저장소 기준), 에이전트마다 격리된 git worktree를 붙여 나란히 돌리는 게 핵심이에요.
도구 자체는 MIT 라이선스라 무료예요. 대신 에이전트 구독(Claude, Codex 등)은 각자 가진 걸 그대로 씁니다. 반응은 뜨거운 편이라 Orca GitHub 저장소의 스타가 2026년 8월 기준 38,000개를 넘겼어요. 맥·윈도우·리눅스 데스크톱에 iOS·안드로이드 컴패니언 앱까지 나와 있어서, 밖에서 폰으로 에이전트 상태만 확인하는 것도 돼요.
왜 다들 설치만 하고 접을까요
접는 이유는 단순하다고 봐요. 단일 에이전트 습관을 그대로 가지고 들어가면 오르카는 그냥 무거운 터미널이거든요. 에이전트 하나만 띄우면 기존 터미널과 다를 게 없는데 램은 수백 MB를 더 먹으니, 지울 이유만 남는 거예요.
저도 처음 며칠은 그랬어요. Claude Code 창 하나를 띄워 놓고 끝날 때까지 지켜보는 습관 그대로였으니까요. 체감으로는 지시하는 시간이 40이면 기다리는 시간이 60이었는데, 그 60을 그대로 둔 채 도구만 바꾼 셈이에요. 도구가 아니라 습관이 바뀌어야 쓸모가 생기는 물건이라, 첫인상에서 갈릴 수밖에 없어요.
2주 써 보니 실제로 쓸모 있던 장면
가장 컸던 건 서로 안 밟는 병렬 작업이에요. 한쪽 작업 창(pane)에는 회사 프로젝트의 API 조사를, 다른 쪽에는 개인 블로그 자동화 백엔드의 버그 수정을 맡겨 뒀어요. worktree로 격리돼 있으니 한쪽이 파일을 갈아엎어도 다른 쪽과 안 섞여요. 터미널 탭을 오가며 “지금 어디까지 했더라”를 되뇌던 피로가 확 줄었어요.
두 번째는 상태 추적이에요. 어느 에이전트가 일하는 중이고 어느 쪽이 끝나서 기다리는지 한 화면에서 보여요. 제 환경에서는 Claude Code의 훅(hook)이 세션 시작·종료 이벤트를 오르카로 보내게 되어 있어서, 끝난 창부터 돌아가 결과를 검토하면 돼요.
지켜보는 개발에서, 돌아보는 개발로.
시행착오도 있었어요. 처음엔 훅이 툴 호출 한 건마다 붙어 있어서, 오르카 밖 일반 터미널에서 Claude Code를 쓸 때도 호출마다 프로세스가 떴다 사라지기를 반복했어요. 보내는 데이터도 없이 오버헤드만 생기는 구조라, 세션 단위 이벤트만 남기고 정리하니 해결됐고요. 이런 것들은 직접 파 보기 전엔 모르는 부분이에요.
한계도 분명해요 — 쿼터, 램, 그리고 검토 병목
가장 현실적인 한계는 사용량이에요. 에이전트를 3개 돌리면 구독 쿼터도 3배로 빠져요. 오르카가 사용량을 아껴 주는 게 아니라, 소모를 병렬로 늘려 주는 도구에 가깝거든요. 구독 한도가 빠듯한 분이라면 이 부분을 먼저 계산해 보는 편이 좋아요.
실행이 빨라져도 검토는 여전히 사람 몫이에요. 에이전트 셋이 동시에 결과를 내놓으면 읽고 판단하는 쪽이 병목이 돼요. 95점짜리 결과 하나를 검토하는 것과 80점짜리 셋을 검토하는 건 전혀 다른 일이더라고요. 지시를 잘게 쪼개는 요령이 없으면 병렬이 오히려 혼란이 되기도 해요.
| 구분 | 2주 실사용 체감 |
|---|---|
| 병렬 실행 | worktree 격리로 작업이 안 섞임 — 가장 큰 쓸모 |
| 상태 추적 | 끝난 에이전트부터 돌아가 검토하는 흐름이 생김 |
| 비용 | 도구는 무료, 에이전트 구독 소모는 병렬 수만큼 배수 |
| 자원 | 해외 리뷰 실측 기준, 에이전트 몇 개 띄운 유휴 상태 램 400~800MB |
| 안정성 | 매일 배포라 개선이 빠른 만큼 가끔 거친 구석 |
램 수치와 쿼터 배수 문제는 해외 실사용 리뷰에서도 똑같이 지적돼요. 이 리뷰에 따르면 병렬 Claude Code 3개는 토큰 소모도 정확히 3배고, 매일 새 버전이 나오는 만큼 버그도 가끔 섞여 나오는데 수정은 보통 24시간 안에 나온다고 해요. 개선 속도가 빠른 대신 어수선한 날도 있다는 점은 감안해 두면 좋아요.
어떤 사람에게 맞고, 누구는 안 써도 될까요
- 레포·프로젝트 여러 개를 오가며 일하는 분 — 병렬 격리의 이득이 가장 커요.
- Claude Code 같은 CLI 에이전트를 이미 쓰고 있는 분 — 진입 비용이 거의 없어요.
- 에이전트 기다리는 시간이 아까웠던 분 — 그 시간이 다른 에이전트의 작업 시간이 돼요.
반대로 프로젝트 하나에 에이전트 하나로 충분하다면 굳이 안 옮겨도 돼요. Cursor처럼 GUI 안에서 끝내는 흐름이 몸에 맞는 분도 마찬가지고요. 도구를 바꾸는 데도 비용이 드니, 기다림이 아깝다고 느껴지는 순간에 여는 편이 자연스러워요.
접었다가 다시 열어볼 분들을 위한 체크리스트
- 서로 안 겹치는 작은 작업 두 개를 먼저 골라 두세요. 버그 수정 하나에 문서 정리 하나 정도면 충분해요.
- 에이전트는 2개부터 시작해 보세요. 처음부터 4~5개를 띄우면 검토가 밀려요.
- 끝난 작업을 검토할 시간을 따로 잡아 두세요. 병목은 실행이 아니라 검토예요.
- 구독 사용량을 먼저 확인해 두세요. 병렬 수만큼 소모가 배로 늘어요.
저는 이 흐름이 되돌아가지 않을 거라고 봐요. 2주 만에 에이전트 하나를 지켜보던 시절이 이미 어색해졌거든요. 오르카가 끝까지 살아남을지는 모르겠지만, IDE에서 ADE로 넘어가는 방향 자체는 분명해 보여요.
도구를 바꾸는 게 아니라, 일하는 방식을 바꾸는 일이에요.