omp (Oh My Pi) + JoinGonka Gateway: 모델 역할을 갖춘 에이전트

1단계: omp 설치하기.프로젝트 README의 공식 방법:

# macOS and Linux
curl -fsSL https://omp.sh/install | sh

# Homebrew
brew install can1357/tap/omp

# via Bun (requires Bun 1.3.14 or newer)
bun install -g @oh-my-pi/pi-coding-agent

# Windows (PowerShell)
irm https://omp.sh/install.ps1 | iex

2단계: 키 발급받기.gate.joingonka.ai/register에서 등록하고, 주소를 확인한 뒤 「API 키」 섹션에서 jg- 접두사가 붙은 키를 생성하세요. 하나의 키와 하나의 잔액이 네트워크의 모든 모델에 적용됩니다.

3단계: 설치 프로그램 실행하기.

npx @joingonka/setup --tool omp

설치 프로그램이 키를 물어봅니다 — 셸 히스토리에 남지 않도록 명령줄 인자로는 전달되지 않습니다 — 그리고 네 가지를 수행합니다:

• ~/.omp/agent/models.yml에 프로바이더 joingonka를 기록합니다: 게이트웨이 주소, 프로토콜 openai-completions, 리터럴 키, 그리고 실제 컨텍스트 윈도우와 응답 상한을 가진 세 개의 네트워크 모델. 파일에는 600 권한이 부여됩니다.
• 기본 모델 — ~/.omp/agent/config.yml의 modelRoles.default — 을 DeepSeek V4 Flash로 설정합니다. 단, 해당 역할이 비어 있거나 네트워크에서 제거된 모델을 가리키는 경우에만: 다른 사람의 선택을 가로채지 않고 전환 방법을 안내합니다.
• 기록 전에 이전 파일을 백업하고, 나머지 프로바이더, 역할, 주석은 그대로 둡니다.
• 마지막으로 게이트웨이에 실제 요청을 보내고 키, 주소, 모델이 수락되었는지 명확히 알려줍니다.

다른 기본 모델은 --model 플래그로 지정합니다. 축약형은 deepseek, glm, minimax — 명시적으로 지정된 모델은 항상 기록됩니다. 닷파일과 서버용으로 질문 없는 모드가 있으며, 그 모드에서는 키를 환경 변수에서 가져옵니다:

JOINGONKA_API_KEY=jg-your-key npx @joingonka/setup --tool omp --model glm --non-interactive

비표준 설정 위치도 설치 프로그램이 알아서 처리합니다: 명명된 프로필(OMP_PROFILE)과 이동된 에이전트 디렉터리(PI_CODING_AGENT_DIR). 상속된 models.json은 omp 자체가 했을 방식대로 models.yml로 이전합니다 — 기존 프로바이더는 사라지지 않습니다. 그리고 config.yml 없이 오래된 settings.json이 옆에 있으면, 설치 프로그램은 config.yml을 생성하지 않습니다. omp가 자체 설정 이전을 건너뛰지 않도록 하기 위해서입니다: 한 번 omp를 실행하고 명령을 다시 실행하라고 안내합니다.

설치 프로그램이 하는 모든 일은 직접 손으로 작성할 수 있습니다. 파일은 두 개뿐이고, 각자 역할이 있습니다. models.yml은 프로바이더와 모델을 기술하고, config.yml은 설정을 보관합니다 — 어떤 모델이 어떤 역할에 배정되는지도 포함해서요.

# ~/.omp/agent/models.yml
providers:
  joingonka:
    baseUrl: https://gate.joingonka.ai/v1
    api: openai-completions
    apiKey: jg-your-key
    models:
      - id: deepseek-ai/DeepSeek-V4-Flash-0731
        name: DeepSeek V4 Flash (Gonka)
        input: [text]
        contextWindow: 380000
        maxTokens: 32768
        reasoning: true
      - id: zai-org/GLM-5.3-Flash
        name: GLM-5.3 Flash (Gonka)
        input: [text]
        contextWindow: 390000
        maxTokens: 8192
        reasoning: true
      - id: MiniMaxAI/MiniMax-M2.7
        name: MiniMax M2.7 (Gonka)
        input: [text]
        contextWindow: 200000
        maxTokens: 8192

# ~/.omp/agent/config.yml
modelRoles:
  default: joingonka/deepseek-ai/DeepSeek-V4-Flash-0731

키를 리터럴로 쓰는 게 가장 문제 없는 방법입니다. omp는 어떤 환경에서든 실행되고, 파일은 chmod 600 ~/.omp/agent/models.yml 명령으로 잠그면 충분합니다. 키를 파일 밖에 두고 싶다면 apiKey에 환경 변수 이름(예: JOINGONKA_API_KEY)을 적고, omp를 실행하는 셸에서 export하세요 — 이 키 확인 순서는 프로젝트 문서에 설명된 그대로입니다.

선택 사항인 cost 필드(백만 토큰당 가격)는 omp UI에서 세션 비용을 추정하는 데만 필요합니다. 설치 프로그램은 설치 시점의 게이트웨이 실시간 가격을 기록합니다. 수동 설정에서는 이 필드를 생략해도 됩니다 — 이 추정치는 청구와 무관하고, 실제 사용량은 대시보드에서 확인할 수 있습니다.

모델 셀렉터는 provider/model-id로 작성합니다. 프로바이더 이름은 첫 번째 슬래시로 구분되므로, 자체 슬래시가 있는 네트워크 ID는 그대로 씁니다: joingonka/deepseek-ai/DeepSeek-V4-Flash-0731. config.yml을 고치는 대신 세션 안에서 /model 명령어를 쓰거나 omp setup 마법사에서 역할을 지정할 수 있습니다.

omp에서는 모든 작업에 단일 모델을 사용하는 것이 아니라 역할(롤)별로 모델을 선택하며, 이것이 설정의 핵심입니다. 내장된 대화용 역할: default, smol, slow, plan, commit, task, tiny, memory, advisor 및 vision. 모든 항목을 지정할 필요는 없습니다. 지정되지 않은 smol과 slow는 먼저 default 역할의 모델을 사용하며, task 역할이 없는 하위 에이전트는 현재 세션의 모델에서 실행되고, commit과 tiny는 smol을 따릅니다. default 한 줄만 설정해도 완벽하게 작동합니다.

네트워크 내의 모델 간에 역할을 나누는 것은 비용 절감 때문이 아니라(DeepSeek V4 Flash, GLM-5.3 Flash, MiniMax M2.7의 가격은 동일함), 동작과 용량을 위한 것입니다. 추론 모델은 계획 수립에 뛰어나고 긴 답변 모델은 글쓰기에 뛰어나므로, 백그라운드의 사소한 작업을 주요 작업과 같은 대기열에 넣을 필요가 없기 때문입니다.

# ~/.omp/agent/config.yml
modelRoles:
  default: joingonka/deepseek-ai/DeepSeek-V4-Flash-0731
  slow: joingonka/zai-org/GLM-5.3-Flash
  plan: joingonka/zai-org/GLM-5.3-Flash
  tiny: joingonka/MiniMaxAI/MiniMax-M2.7

retry:
  fallbackChains:
    default:
      - joingonka/zai-org/GLM-5.3-Flash

retry.fallbackChains 블록은 피크 시간대의 보험입니다. 메인 모델이 429 에러를 지속적으로 반환하면, omp는 나머지 작업을 체인의 다음 항목으로 넘기고 잠시 후 메인 모델로 복귀합니다. 체인의 키에는 역할, 특정 모델 또는 전체 공급자(joingonka/*)를 지정할 수 있습니다.

실행 시 플래그를 사용하여 역할을 재정의할 수 있습니다. omp --model slow는 slow 역할 모델로 세션을 시작하며, --smol, --slow 및 --plan은 각 역할의 모델을 대체합니다. 세션 내에서 Ctrl+P로 역할 모델을 전환할 수 있고, /model로 선택 창을 열 수 있습니다. 같은 탭의 'Roles'에서 역할과 예비 모델을 설정할 수 있습니다.

역할 값에 추론 레벨(:low, :medium, :high)을 추가할 수 있습니다. 이는 omp의 문법이며, 특정 모델이 이 레벨을 어떻게 이해하는지는 모델 자체에 달려 있습니다. 예를 들어 GLM-5.3 Flash의 경우 이는 이진 스위치입니다. 자세한 내용은 모델 개요를 참조하십시오. 또 다른 유용한 기능으로, <repo>/.omp/config.yml 파일을 생성하고 동일한 modelRoles 블록을 포함하여 저장소별로 역할을 재정의할 수 있습니다. 공급자와 키는 홈 디렉토리에 유지되므로 키가 저장소에 포함되지 않습니다.

먼저 omp가 프로바이더를 인식하는지 확인하세요:

omp models joingonka

응답으로 models.yml의 컨텍스트 윈도우와 최대 출력 토큰을 천 단위로 반올림한 3행짜리 표가 돌아옵니다 (출력은 축약본입니다. omp에는 thinking과 images 컬럼도 있습니다):

joingonka (3)
model                                context  max-out
deepseek-ai/DeepSeek-V4-Flash-0731      380K      33K
MiniMaxAI/MiniMax-M2.7                  200K     8.2K
zai-org/GLM-5.3-Flash                   390K     8.2K

다음은 인터페이스 없이 단발로 실행하는 방법입니다. 빈 디렉터리에 명백한 버그가 있는 파일을 넣고 찾아달라고 요청하세요:

omp -p "Read calc.py and tell me in one sentence whether it has a bug."

에이전트는 스스로 읽기 도구를 호출하고, 오류가 있는 표현식을 짚어가며 본질적인 답변을 해야 합니다. 2026년 9월 21일 테스트에서 이 사이클(요청 → 도구 호출 → 결과 → 응답)을 DeepSeek V4 Flash와 GLM-5.3 Flash가 문제없이 통과했습니다. MiniMax M2.7에 대해서는 아래 표의 마지막 행을 참고하세요.

세 번째 검증은 게이트웨이 쪽에서 합니다. 대시보드의 "사용량" 섹션에서 요청이 "모델별" 분석에 나타나고, "키별" 블록에서 마지막 요청 시간이 갱신됩니다. 비어 있다면 omp가 다른 프로바이더로 연결되고 있는 것입니다. omp config get modelRoles 명령으로 역할에 무엇이 설정되어 있는지 확인하세요.

문제가 생겼을 때는 보통 오류 메시지에서 원인을 바로 읽을 수 있습니다:

에이전트 도구는 일반 채팅과 다르게 토큰을 소비합니다. omp는 사용자의 각 문장에 시스템 프롬프트와 도구 설명을 추가하며, 작업은 보통 여러 턴의 과정을 거치기 때문입니다. 저희가 테스트했을 때, 읽기 도구 하나만 켜두어도 턴당 약 3,500개의 입력 토큰이 발생했으며, 전체 도구를 사용하면 훨씬 더 늘어납니다. 따라서 여기서 토큰 비용이 매우 중요합니다.

JoinGonka Gateway를 통하면 토큰 가격은 입력 100만 토큰당 $0.0069, 출력 100만 토큰당 $0.021입니다. 이 가격은 네트워크의 모든 모델에 동일하게 적용되며, 이 페이지에서 실시간 소스를 통해 불러옵니다.

오른쪽 열의 추정치는 2026년 9월 가격 기준입니다. 참고로, omp에서 모델 비용을 지불하는 방법은 다음과 같습니다:

omp 상태 표시줄에는 세션 예상 비용이 표시됩니다. 이는 models.yml의 cost 필드를 기준으로 계산됩니다. 설치 프로그램이 설치 시점의 게이트웨이 가격을 입력하지만, 네트워크의 달러 가격은 GNK 환율에 따라 변동되므로 대략적인 지표로 보아야 합니다. 정확한 소비량과 잔액은 계정의 '사용량(Usage)' 및 '결제(Billing)' 섹션에서 확인하십시오. 기본값으로 DeepSeek V4 Flash가 선택된 이유는 모델 리뷰에서 자세히 다루고 있습니다.

승인 모드. 기본적으로 omp는 yolo 모드로 동작합니다. 읽기, 쓰기, 명령 실행을 스스로 승인합니다. 자기 프로젝트에서는 편리하지만, 남의 코드에서는 모드를 강화하거나 컨테이너로 피해야 할 이유가 됩니다:

omp config set tools.approvalMode write

write 모드에서 에이전트는 명령 실행에 대해서만 권한을 묻고, always-ask에서는 쓰기에 대해서도 묻습니다. 한 번의 실행에 대해서는 --approval-mode 플래그로도 같은 설정을 지정할 수 있습니다. 이는 omp 자체의 속성이며 모델 제공자와는 무관합니다.

Pi와 omp는 설정이 다른 사촌. 한 도구의 설정은 다른 쪽에 전달되지 않습니다. 디렉터리, 포맷, 필드 이름이 각자 다릅니다.

여러 환경. 이름 있는 프로필(omp --profile work 또는 OMP_PROFILE 변수)은 모든 설정을 ~/.omp/profiles/<name>/agent로 옮깁니다. 업무용과 개인용 키를 분리하기에 편리합니다. 현재 에이전트 디렉터리는 omp config path로 출력됩니다.

에디터에서 에이전트가 필요하다면. omp는 ACP 프로토콜을 통해 Zed 안에서 동작할 수 있습니다. 동일한 설정의 같은 에이전트이므로 제공자와 역할을 다시 설정할 필요가 없습니다.