최근 개발자 커뮤니티나 커피챗에서 가장 뜨거운 화두를 하나 꼽으라면, 단연 ‘에이전트(Agent)’가 아닐까 합니다. 이제는 단순히 코드를 한 줄 추천해 주는 수준을 넘어, 터미널에 직접 들어가 파일 구조를 뜯어고치고 명령어를 실행하는 ‘진짜 일하는 AI’들이 등장했기 때문이죠. 그 흐름의 중심에 서 있는 도구가 바로 OpenCode와 이를 한 단계 더 진화시킨 OMO(Oh My OpenCode)입니다.
단순히 “이 기능이 좋다”는 스펙 나열이 아니라, 10년 차 개발자의 시선에서 이 도구들이 우리의 실전 워크플로우를 어떻게 바꾸고 있는지, 그리고 왜 우리가 이 생소한 ‘하네스(Harness)’라는 개념에 주목해야 하는지 정리해 보았습니다.
1. OpenCode, 단순히 똑똑한 비서일까요? 아니면 현장 대리인일까요?
우리가 그동안 썼던 AI 툴들이 내 옆에서 타이핑을 도와주는 ‘보조 작가’였다면, OpenCode는 내 대신 현장에 투입되는 ‘대리인’에 가깝습니다. IDE 안에 갇혀 있지 않고 터미널과 데스크톱을 넘나들며 프로젝트 전체의 맥락을 읽어내죠.
‘일단 멈춤’과 ‘실행’ 사이의 균형: Plan vs Build
실제 프로젝트에서 OpenCode를 돌려보면 가장 인상적인 지점이 바로 모드의 분리입니다.
- Plan 모드 (설계의 시간): 처음부터 코드를 수정하라고 시키는 건 위험하기 마련입니다. Plan 모드는 파일을 읽기만 하고 수정은 차단합니다. “이 프로젝트 구조를 분석해서 리팩토링 계획을 세워줘”라고 말하면, 선무당이 사람 잡듯 코드를 헤집어놓는 대신 정갈한 설계도를 먼저 내놓죠.
- Build 모드 (실행의 시간): 설계가 끝났다면 이제 실제 손을 더럽힐 차례입니다. Build 모드는 파일 수정과 Bash 명령어 실행 권한을 가집니다.
이런 흐름은 마치 시니어 개발자가 화이트보드에 구조를 먼저 그리고 키보드를 잡는 것과 닮아 있습니다. 무작정 코드를 뱉어내는 AI의 조급함을 ‘워크플로우’로 제어했다는 점에서 신뢰가 가더군요.
2. 왜 OpenCode 하나로 부족해서 OMO까지 찾게 될까?
OpenCode가 훌륭한 ‘개인 요원’이라면, OMO(Oh My OpenCode)는 이 요원들을 지휘하는 ‘작전 통제실’입니다. 개발자들 사이에서는 이를 에이전트 하네스(Agent Harness)라고 부르기 시작했죠.
에이전트 하네스: 고삐를 쥐어주는 운영 체계
에이전트에게 큰 작업을 맡겨보신 분들은 아실 겁니다. 한참 일하다가 중간에 흐름을 놓치거나, 엉뚱한 방향으로 삽질을 시작하는 순간의 허탈함을요. OMO는 이런 현상을 막기 위해 AI에게 ‘하네스(안전벨트)’를 채웁니다.
- 전문가 팀의 오케스트레이션: OMO는 혼자 북 치고 장구 치게 두지 않습니다. UI 전문가는 Gemini가, 문서와 코드 분석은 Claude가 맡는 식으로 역할을 분담(Oracle, Librarian 등)시키죠.
- 맥락의 파편화 방지: LSP(Language Server Protocol)나 AST(구조적 코드 분석) 도구를 패키징해서 제공합니다. 덕분에 에이전트가 코드를 단순한 텍스트가 아니라 ‘의미 있는 구조’로 이해하게 돕습니다.
전략적으로 솔직해지자면, 모든 소규모 작업에 OMO를 쓰는 건 과할 수 있습니다. 하지만 수십 개의 파일이 얽힌 거대 프로젝트를 리팩토링해야 한다면, 혼자 일하는 에이전트보다는 잘 짜인 팀 시스템인 OMO가 훨씬 든든한 법입니다.
3. 내 도구 상자에 어떤 연장을 넣어야 할까?
현재 AI 코딩 도구 시장은 지향점에 따라 크게 두 갈래로 나뉩니다. 어떤 도구를 고를지는 성능의 문제가 아니라 ‘내가 어떤 리듬으로 일하고 싶은가’의 문제입니다.
| 분류 | 도구 예시 | 철학적 지향점 | 추천 워크플로우 |
|---|---|---|---|
| 지능형 펜 (Editing) | Cursor, Copilot | 편집의 완결성. 개발자의 타이핑 경험을 극대화하는 데 집중합니다. | 내가 주도권을 잡고 한 땀 한 땀 코드를 짤 때 |
| 자율 요원 (Agentic) | OpenCode, Claude Code | 작업의 완결성. 개발자가 지시한 ‘목표’를 달성하는 데 집중합니다. | 터미널에서 큰 단위의 기능을 한 번에 구현할 때 |
| 운영 체계 (Harness) | OMO | 팀워크와 재현성. 여러 에이전트를 조율해 복잡한 문제를 해결합니다. | 대규모 리팩토링이나 팀 단위의 표준화가 필요할 때 |
4. 그래서, 어떤 순간에 도입하면 좋을까요?
무조건 최신 툴이라고 덥석 잡기보다는, 지금 내가 겪고 있는 고통의 종류를 먼저 살펴보세요.
- 이런 분께는 OpenCode를 추천합니다:
“IDE 창을 왔다 갔다 하는 게 번거롭고, 터미널 환경에서 빠르게 코드베이스를 탐색하고 수정하고 싶다.” - 이런 분께는 OMO가 정답입니다:
“AI가 작업 중간에 자꾸 길을 잃어서 답답하다. 혹은 프론트/백엔드/문서화 등 각 분야에 특화된 모델들을 팀처럼 부리고 싶다.”
물론 주의할 점도 있습니다. 에이전트에게 터미널 권한을 준다는 건, 언제든 내 로컬 환경을 엉망으로 만들 수도 있다는 뜻이니까요. 그래서 우리는 여전히 ‘운전대’를 잡고 있어야 합니다. 다만 예전처럼 페달까지 밟느라 고생하는 대신, 이제는 경로를 이탈하지 않는지 지켜보는 ‘감독관’의 역할로 옮겨가는 과정에 있는 것이죠.