4편 — OMO에 연결하기

OMO는 OpenCode의 대체재가 아니다. OpenCode가 제공하는 에이전트, 커맨드, 스킬, 권한 시스템이라는 물리적 토대 위에 Sisyphus 중심의 오케스트레이션 레이어를 얹는 플러그인이다. 따라서 OMO를 활성화하더라도 기존에 구축한 .opencode/ 하위의 모든 설정 체계는 그대로 살아 있으며, 오히려 OMO가 제공하는 전문화된 내장 에이전트들과 협력하며 시너지를 낸다.

성공적인 에이전트 시스템을 구축하려면 OpenCode 커스텀 에이전트와 OMO 내장 에이전트의 역할을 명확히 나누는 전략이 필요하다. 프로젝트 고유의 비즈니스 로직이나 코딩 컨벤션을 검토하는 일은 커스텀 에이전트에게 맡기고, 코드베이스 전체의 구조를 탐색하거나 외부 라이브러리 문서를 읽어오는 범용적인 지능은 OMO 내장 에이전트의 힘을 빌리는 것이 효율적이다.

역할 분담: 전문가와 범용 지능의 협업

OMO를 사용하면 우리가 직접 만들지 않아도 사용할 수 있는 전문화된 내장 에이전트들이 추가된다. 코드베이스 전체를 훑으며 파일 위치를 찾아내는 explore, 방대한 외부 라이브러리 문서를 읽고 핵심을 짚어주는 librarian, 복잡한 아키텍처 결정을 내리거나 난해한 버그의 근본 원인을 추론하는 oracle 등이 대표적이다.

작업 유형	추천 역할	이유
특정 파일과 패턴 탐색	`explore`	현재 코드베이스 구조를 빠르게 좁힌다
외부 API와 라이브러리 조사	`librarian`	공식 문서와 public example을 함께 본다
구현	custom builder 또는 Sisyphus	프로젝트 규칙에 맞춰 변경한다
설계 판단/리뷰	`oracle` 또는 custom reviewer	구현자와 판단자를 분리한다

여기서 커스텀 에이전트는 프로젝트 고유의 맥락을 담당한다. 예를 들어 “우리 블로그 API는 PATCH에 변경 필드만 보낸다”거나 “시리즈 글은 일반 피드에 노출되지 않는다” 같은 규칙은 범용 에이전트가 알 수 없다. 이런 규칙은 skill이나 custom agent에 넣고, OMO 내장 에이전트는 더 넓은 탐색과 판단에 집중하게 하는 편이 좋다.

호출 전략: task()와 @mention

OMO에서 핵심은 역할을 언제 어떻게 호출할지다. 즉흥적으로 “아무 에이전트나 불러서 해봐”라고 하면 오케스트레이션이 아니라 단체 채팅이 된다. 단체 채팅은 즐겁지만, 운영 시스템은 대체로 즐거우면 안 된다. 지루할수록 안전하다.

간단한 구현 작업은 아래처럼 나눌 수 있다.

TXT

1. explore: 관련 파일, 기존 패턴, 테스트 위치를 찾는다.
2. librarian: 외부 라이브러리나 공식 문서를 확인한다.
3. builder: 두 결과를 바탕으로 변경한다.
4. reviewer/oracle: 요구사항, 보안, 아키텍처 위험을 확인한다.
5. verifier: 테스트, 타입체크, 빌드 결과를 확인한다.

task() 호출을 설계할 때는 프롬프트에 최소한 여섯 가지가 들어가야 한다. 작업, 기대 결과, 사용할 도구, 반드시 할 일, 절대 하지 말 일, 그리고 컨텍스트다. 이 정보가 빠지면 서브에이전트는 똑똑하게 움직이지만 엉뚱하게 움직일 수 있다. 똑똑한 엉뚱함은 보통 평범한 버그보다 찾기 어렵다.

TXT

TASK: opencode-omo-permission-command-skill-tool 글에서 tool/MCP 설명 보강점 찾기
EXPECTED OUTCOME: 추가할 섹션 제목과 요약
MUST DO: 현재 글 구조를 기준으로 삽입 위치 제안
MUST NOT DO: 글을 직접 수정하지 않기, 토큰 출력하지 않기
CONTEXT: 이 글은 시리즈 3편이며 permission/command/skill/tool을 다룬다

병렬 호출과 중복 검색 방지

OMO의 장점 중 하나는 explore와 librarian을 병렬로 움직일 수 있다는 점이다. 하지만 병렬 호출은 “같은 일을 여러 명에게 시키는 것”이 아니다. explore는 우리 코드베이스를 보고, librarian은 외부 문서와 오픈소스 예제를 본다. 둘의 질문이 겹치면 결과가 늘어나는 것이 아니라 소음이 늘어난다.

좋은 병렬 호출은 이렇게 역할을 분리한다.

TXT

explore
  - 현재 저장소의 비슷한 구현
  - 테스트와 설정 파일 위치
  - 기존 네이밍과 에러 처리 패턴

librarian
  - 공식 문서의 권장 사용법
  - public repo의 실제 예시
  - 버전별 주의점

오케스트레이터는 두 결과가 모인 뒤에만 구현 결정을 내려야 한다. 특히 외부 라이브러리 사용법이나 보안에 영향을 주는 판단을 librarian이나 oracle에게 맡겼다면, 그 결과를 받기 전에 구현을 밀어붙이지 않는 편이 좋다. 기다림도 설계의 일부다. 물론 우리는 기다림을 싫어하지만, 장애도 싫어한다.

실전 규칙 주입: Project-Workflow Skill

OpenCode의 skill은 OMO와 결합될 때 특히 강력해진다. 프로젝트마다 반복되는 워크플로우를 skill로 만들고, OMO가 필요할 때 해당 skill을 로드하게 하면 에이전트 간의 작업 방식이 안정된다. 예를 들어 블로그 운영 skill은 다음 규칙을 담을 수 있다.

TXT

- 먼저 GET으로 현재 글을 확인한다.
- PATCH에는 변경된 필드만 보낸다.
- publish는 명시 요청이 있을 때만 한다.
- 토큰은 출력하지 않는다.
- 수정 후 다시 GET으로 status와 content를 확인한다.

이 규칙은 특정 에이전트 하나의 성격이 아니라 프로젝트의 운영 방식이다. 그래서 agent 파일에 복사하기보다 skill로 분리하는 편이 좋다. OMO는 이 skill을 writer, reviewer, publisher 흐름에 필요한 순간 주입하고, 각 역할은 같은 규칙을 공유한 상태로 자기 일을 한다.

연결의 기준

OpenCode와 OMO를 연결할 때 마지막으로 점검할 것은 “권한은 OpenCode에, 순서는 OMO에, 지식은 skill에, 반복 절차는 command에 두었는가”다. 이 경계가 지켜지면 시스템은 작게 고쳐도 전체가 무너지지 않는다.

반대로 OMO 프롬프트 하나에 모든 규칙과 모든 예외와 모든 API 호출 방식을 넣으면 다시 만능 프롬프트로 돌아간다. 시리즈의 목표는 더 큰 프롬프트를 만드는 것이 아니라, 작은 규칙들이 서로 맞물려 안전하게 움직이는 구조를 만드는 것이다.