Claude Code & OpenCode 에이전트 통합 구성 §ohmyopencode

관련메타

• †#에이전틱코딩#라이브코딩#에이전트코딩

히스토리

• [2026-01-23 Fri 16:24] 오마이코드에 대해서 이사님의 이야길들으며 통합
• [2025-11-21 Fri 20:46] 클로드코드 오픈코드 에이전트 통합에 대한 생각

관련노트

• §OPENCODE: #오픈코드 TUI ACP LSP
• §GAS-TOWN 가스타운

code-yeongyu/oh-my-opencode

(“Code-Yeongyu/Oh-My-Opencode” 2026)

YeonGyu-Kim 2026 The Best Agent Harness. Meet Sisyphus: The Batteries-Included Agent that codes like you.

|2026-01-23 Fri 16:23|

@user oh-my-opencode 조사해보자. §GAS-TOWN 가스타운 이랑 비교 해보자. 옆에 채이사님이 관심가지시네. 나도 이건 안써봤다. Claude Code & OpenCode 에이전트 통합 구성

@assistant

Claude Code & OpenCode 에이전트 통합 구성

개요

Claude Code와 OpenCode에서 사용할 전문 에이전트 시스템을 일관성 있게 구성했습니다. 총 12개의 에이전트를 개발 라이프사이클 전반을 커버하도록 설계했으며, 각 플랫폼의 양식에 맞춰 동일한 에이전트 세트를 적용했습니다.

에이전트 구성 철학

명확한 역할 분담

• 각 에이전트는 하나의 명확한 책임을 가짐
• 역할 간 중복 최소화
• 전문성 극대화

모델 전략적 배치

• Haiku (2개): 빠른 응답이 필요한 작업 (git, tester)
• Sonnet (10개): 표준 작업, 품질 중시

Temperature 최적화

• 0.1: 정확성 최우선 (5개)
• 0.2: 체계적 일관성 (2개)
• 0.3: 구조적 창의성 (1개)
• 0.4: 자연스러운 문서 (1개)
• 0.6: 탐색적 조사 (1개)
• 0.7: 창의적 설계 (1개)
• 0.8: 자연스러운 표현 (1개)

전체 에이전트 목록 (12개)

기본 개발 워크플로우 (6개)

reviewer (sonnet, 0.1)

• 역할: 코드 품질/보안 리뷰
• 도구: Read, Grep, Glob (읽기 전용)
• 특징: 정확한 분석, 보안 취약점 탐지
• 사용 시점: 코드 작성 후 품질 검토

refactor (sonnet, 0.3)

• 역할: 코드 리팩토링
• 도구: Read, Write, Edit, Grep, Glob, Bash
• 특징: 구조 개선, 성능 최적화
• 사용 시점: 코드베이스 개선

debugger (sonnet, 0.2)

• 역할: 버그 추적 및 디버깅
• 도구: Read, Grep, Glob, Bash
• 특징: 체계적 근본 원인 분석
• 사용 시점: 에러 조사, 버그 해결

architect (sonnet, 0.7)

• 역할: 시스템 아키텍처 설계
• 도구: Read, Write, Grep, Glob + WebSearch, Context7
• 특징: 창의적 시스템 설계, 기술 의사결정
• 사용 시점: 시스템 설계, 기술 스택 선택

researcher (sonnet, 0.6)

• 역할: 기술 조사 및 라이브러리 비교
• 도구: Read, Grep + WebSearch, WebFetch, Context7
• 특징: 탐색적 조사, 베스트 프랙티스 발견
• 사용 시점: 기술 선택, 솔루션 탐색

tester (haiku, 0.1)

• 역할: 시스템 테스트, 로그 분석
• 도구: Read, Write, Bash, Grep, Glob
• 특징: 빠른 로그 분석, 원격 시스템 관리
• 사용 시점: 테스트 실행, 모니터링

문서화 워크플로우 (2개)

docs (sonnet, 0.4)

• 역할: 기술 문서 작성
• 도구: Read, Write, Edit, Grep, Glob
• 특징: 명확하고 간결한 문서
• 사용 시점: README, API 문서, 가이드 작성

translator (sonnet, 0.8)

• 역할: 한영 번역 및 현지화
• 도구: Read, Write, Edit
• 특징: 자연스러운 표현, 문화적 맥락 고려
• 사용 시점: 문서 번역, 블로그 현지화

관리 워크플로우 (4개)

pm (sonnet, 0.2)

• 역할: 프로젝트 관리, 메모리 관리
• 도구: Read, Write, Grep, Glob, Bash
• 특징: 능동적 메모리 스캔, 문서 정리
• 사용 시점: 프로젝트 상태 점검, 문서 통합

org (sonnet, 0.1)

• 역할: Org-mode PKM 관리
• 도구: Read, Write, Edit, Grep, Glob, Bash
• 특징: 구조적 파싱, Denote 표준 준수
• 사용 시점: Org-mode 파일 작업, 지식 관리

git (haiku, 0.1)

• 역할: Git 커밋 전문
• 도구: Bash, Read, Grep + MCP git
• 특징: 전문적인 커밋 메시지, 빠른 처리
• 사용 시점: 변경사항 커밋

security (sonnet, 0.1)

• 역할: 보안 포렌식 분석
• 도구: Read, Write, Grep, Glob, Bash
• 특징: 취약점 분석, 로그 포렌식
• 사용 시점: 보안 감사, 사고 조사

Temperature 분포 전략

온도	개수	에이전트	특징
0.1	5개	reviewer, org, git, security, tester	정확성 최우선
0.2	2개	pm, debugger	체계적 일관성
0.3	1개	refactor	구조적 창의성
0.4	1개	docs	명확한 문서
0.6	1개	researcher	탐색적 조사
0.7	1개	architect	창의적 설계
0.8	1개	translator	자연스러운 표현

플랫폼별 구성

Claude Code 구성

위치

~/.claude/agents/

양식

---
name: agent-name
description: 설명
tools: Tool1, Tool2, Tool3
model: haiku | sonnet | opus
temperature: 0.1-0.8
---

특징

• 간단한 YAML frontmatter
• 쉼표로 구분된 도구 목록
• Claude 모델명 직접 사용 (haiku, sonnet)

OpenCode 구성

위치

~/claude-config/opencode/agent/

양식

---
description: 설명
mode: subagent
model: anthropic/claude-[model]-4-5
temperature: 0.1-0.8
tools:
  read: true/false
  write: true/false
  edit: true/false
  grep: true/false
  glob: true/false
  bash: true/false
  list: true/false
---

특징

• mode: subagent 필수
• 명시적인 모델 경로 (anthropic/claude-*)
• 도구별 boolean 객체 구조

모델 및 도구 매핑

모델 매핑

Claude Code	OpenCode
haiku	anthropic/claude-haiku-4-5
sonnet	anthropic/claude-sonnet-4-5

도구 매핑

Claude Code	OpenCode
Read	read: true
Write	write: true
Edit	edit: true
Grep	grep: true
Glob	glob: true
Bash	bash: true
-	list: true (OpenCode 전용)

에이전트 파일 크기

Claude Code (~/.claude/agents/)

파일	크기
debugger.md	9.2K
translator.md	8.0K
researcher.md	7.6K
architect.md	6.2K
tester.md	5.7K
security.md	5.4K
docs.md	3.5K
git.md	3.4K
org.md	3.0K
pm.md	2.8K
refactor.md	2.3K
reviewer.md	1.9K

OpenCode (~/claude-config/opencode/agent/)

파일	크기
translator.md	3.5K
researcher.md	3.4K
debugger.md	3.1K
architect.md	2.9K
tester.md	2.4K
security.md	2.3K
pm.md	2.2K
org.md	2.1K
docs.md	2.1K
reviewer.md	2.0K
refactor.md	1.8K
git.md	1.8K

사용 예시

Claude Code

@reviewer 이 코드 검토해줘
@architect 마이크로서비스 아키텍처 설계해줘
@researcher Python 비동기 프레임워크 비교해줘
@translator 이 README 영어로 번역해줘
@debugger 스택 트레이스 분석해줘

OpenCode

@reviewer 코드 리뷰
@git 커밋 메시지 작성
@tester 로그 분석

주요 개선 사항

이전 구성 (OpenCode)

• 8개 에이전트
• 특정 기술 중심 (임베디드, OpenWrt)
• 불명확한 네이밍 (code-reviewer, openwrt-manager)
• Opus 모델 사용

현재 구성 (통합)

• 12개 에이전트
• 범용적 역할 정의
• 간단하고 명확한 네이밍 (reviewer, tester)
• Haiku/Sonnet 전략적 배치
• Temperature 최적화
• 양쪽 플랫폼 일관성

개발 라이프사이클 커버리지

설계 단계

• architect: 시스템 설계
• researcher: 기술 조사

개발 단계

• refactor: 코드 개선
• reviewer: 품질 검토
• debugger: 버그 수정

테스트 단계

• tester: 테스트 실행, 모니터링

문서화 단계

• docs: 기술 문서
• translator: 다국어화

관리 단계

• pm: 프로젝트 관리
• org: 지식 관리
• git: 버전 관리
• security: 보안 감사

작업 이력

2025-11-21 초기 구성

1. Claude Code 에이전트 디렉토리 생성
2. 기본 8개 에이전트 생성
   • reviewer, refactor, pm, org, git, docs, security, tester
3. 모델 최적화 (opus → sonnet, reviewer haiku → sonnet)
4. tester 모델 변경 (sonnet → haiku)
5. 전체 에이전트에 temperature 설정 추가
6. 4개 에이전트 추가
   • architect, researcher, translator, debugger
7. OpenCode 양식으로 12개 에이전트 변환
8. 기존 OpenCode 에이전트 삭제 및 신규 생성

향후 고려사항

잠재적 추가 에이전트

• optimizer: 성능 최적화 전문
• deployer: 배포 및 운영 관리
• teacher: 기술 학습 및 교육 콘텐츠

개선 방향

• MCP 도구 통합 활용
• 에이전트 간 협업 워크플로우
• 프로젝트별 커스텀 에이전트

결론

통일된 에이전트 시스템을 통해 Claude Code와 OpenCode 양쪽에서 일관된 워크플로우를 구축했습니다. 각 에이전트는 명확한 역할을 가지며, 전체적으로 소프트웨어 개발 라이프사이클을 완전히 커버합니다.

모델과 temperature의 전략적 배치를 통해 품질과 성능의 균형을 맞췄으며, 앞으로 필요에 따라 추가 에이전트를 쉽게 확장할 수 있는 구조입니다.

Task: Research oh-my-opencode and compare with GAS-TOWN

[2026-01-23 Fri 16:25]

Let me search for information about oh-my-opencode and then compare it with GAS-TOWN.## Oh-My-OpenCode vs GAS-TOWN 비교 분석

Oh-My-OpenCode

개요

• OpenCode를 위한 올인원 플러그인
• Sisyphus 에이전트를 중심으로 다중 AI 모델 오케스트레이션
• “The Best Agent Harness”를 표방

핵심 특징

• 다중 모델 활용: Claude Opus 4.5, GPT 5.2 Medium, Gemini 3 Pro 등 특화된 모델들을 동시 활용
• 전문 에이전트:
  • Sisyphus (Claude Opus 4.5): 메인 오케스트레이터
  • Oracle (GPT 5.2): 아키텍처 및 디버깅
  • Frontend Engineer (Gemini 3 Pro): UI/UX 개발
  • Librarian (Claude Sonnet 4.5): 문서화 및 코드 탐색
  • Explore: 빠른 코드베이스 검색

기술 스택

• LSP(Language Server Protocol) 완벽 지원
• AST-Grep 통합(구문 인식 코드 검색)
• MCP(Model Context Protocol) 내장: Exa(웹 검색), Context7(문서), GitHub 검색
• Todo Continuation Enforcer(작업 미완성 방지)

장점

• 8,000+ ESLint 경고를 하루 만에 처리
• 45,000줄 애플리케이션을 하룻밤 사이에 변환
• 병렬 백그라운드 에이전트로 컨텍스트 부하 감소
• “ultrawork” 키워드로 전체 기능 자동 활성화

이슈

• 2026년 1월 현재 Anthropic의 제3자 OAuth 접근 제한으로 차단 문제 발생

GAS-TOWN

개요

• Claude Code를 위한 다중 에이전트 오케스트레이터
• Git 기반 작업 상태 관리(Beads)
• Tmux 세션 기반 에이전트 실행

핵심 특징

• 작업 영속성: 충돌, 압축, 재시작 후에도 작업이 훅(Hook)에 유지
• 구조화된 조정: 메일박스, 신원, 구조화된 핸드오프
• 확장성: 20-30개 에이전트까지 편안하게 확장 가능
• Git 기반 원장: Beads(Git 기반 이슈 트래커)에 모든 작업 상태 저장

역할 구조

• Mayor: 타운 전체 AI 코디네이터(Claude Code)
• Polecat: 작업 실행 에이전트(일시적)
• Witness: 작업자 모니터링, 라이프사이클 관리
• Refinery: 병합 큐, PR 검토, 통합
• Deacon: 데몬 프로세스, 에이전트 라이프사이클 관리

MEOW 워크플로우

• Formula → Protomolecule → Mol/Wisp
• Cook, Pour, Wisp, Squash, Burn 연산자
• 충돌 복구: 어떤 에이전트든 다른 에이전트가 중단한 지점부터 계속 가능

장점

• Tmux 기반 세션 관리로 에이전트 간 전환 용이
• 웹 대시보드 제공(포트 8080)
• 상태 영속성이 강력(Git 기반)
• 모듈식 설계: 필요한 역할만 실행 가능

핵심 차이점

항목	Oh-My-OpenCode	GAS-TOWN
기반	OpenCode 플러그인	Claude Code 오케스트레이터
모델 전략	다중 모델(Claude, GPT, Gemini)	단일 모델(Claude Code)
작업 추적	컨텍스트 기반	Git 기반(Beads)
인터페이스	CLI + 자동화	Tmux + Mayor 세션 + CLI
전문화	모델별 역할 분담	역할별 에이전트 분담
영속성	컨텍스트 관리	Git Major + Hook
규모	병렬 에이전트	20-30 에이전트 확장
워크플로우	LSP + AST-Grep	MEOW(Formula → Mol)
현황	OAuth 접근 제한 이슈	안정적

어느 것을 선택할까?

Oh-My-OpenCode 추천 상황

• 다양한 AI 모델의 강점을 활용하고 싶을 때
• 빠른 대규모 코드 리팩토링이 필요할 때
• LSP와 AST 기반 정밀 코드 분석이 필요할 때
• ⚠️ 단, 현재 Anthropic OAuth 제한 문제 해결 필요

GAS-TOWN 추천 상황

• 작업 상태의 영속성과 복구가 중요할 때
• Git 기반 워크플로우를 선호할 때
• Tmux 환경에서 에이전트 관리를 원할 때
• 장기 프로젝트에서 안정적인 오케스트레이션이 필요할 때

---

Sources:

• Oh My OpenCode GitHub
• Oh My OpenCode 한국어 가이드 (Velog)
• Oh My OpenCode Medium 소개
• 파이토치 한국 사용자 모임 토론
• GeekNews - Oh-My-OpenCode 경험담
• OpenCode & Oh My OpenCode 가이드

📊 Tokens: 19989 in, 10238 out

@user 폴더에서 gastown 관련 문서 찾아봐. 내 방향과 오픈코드 플러그인과 비교하자.

@assistant 먼저 GAS-TOWN 관련 문서를 찾아보겠습니다.GAS-TOWN 관련 문서를 읽었습니다. 이제 현재 Claude Code & OpenCode 통합 에이전트 구성 노트와 비교하여 분석을 정리하겠습니다.

내 방향 vs Oh-My-OpenCode vs GAS-TOWN 비교 분석

1. 내 현재 에이전트 구성 (Claude Code & OpenCode 통합)

철학:

• 12개의 전문화된 에이전트
• 개발 라이프사이클 전체를 커버
• Temperature 전략적 배치 (0.1~0.8)
• Haiku/Sonnet 모델 전략 분배
• 플랫폼 간 일관성 (Claude Code ↔ OpenCode)

특징:

• 명확한 역할 분담 (reviewer, refactor, debugger, architect, researcher 등)
• 각 에이전트의 도구 권한 명확히 정의
• 독립 실행 에이전트 (오케스트레이션 없음)
• 수동 워크플로우 관리

한계:

• 에이전트 간 협업/조정 메커니즘 부재
• 작업 영속성 없음 (세션 종료 시 컨텍스트 손실)
• 10개 이상 에이전트 사용 시 관리 어려움
• 작업 상태 추적 수동

---

2. Oh-My-OpenCode

철학:

• “The Best Agent Harness”
• OpenCode를 위한 올인원 플러그인
• 다중 모델 오케스트레이션 (Claude Opus 4.5 + GPT 5.2 + Gemini 3 Pro)
• Sisyphus 에이전트가 메인 오케스트레이터

강점:

• LSP(Language Server Protocol) 완벽 지원
• AST-Grep 통합 (구문 인식 검색)
• MCP 내장 (Exa 웹 검색, Context7 문서, GitHub 검색)
• Todo Continuation Enforcer (작업 미완성 방지)
• 병렬 백그라운드 에이전트
• “ultrawork” 키워드로 전체 기능 자동 활성화

실적:

• 8,000+ ESLint 경고를 하루 만에 처리
• 45,000줄 애플리케이션 하룻밤 변환

현재 이슈:

• Anthropic OAuth 접근 제한 문제 (2026-01-23 현재)

---

3. GAS-TOWN

철학:

• “2026년을 겨냥한 IDE의 새로운 해석”
• 20~30개 Claude Code 인스턴스 동시 관리
• Git 기반 작업 영속성 (Beads)
• Tmux 세션 기반 에이전트 오케스트레이션
• “바이브 코딩(Vibe Coding)” 철학

핵심 개념:

역할 구조:

• Mayor: 타운 전체 AI 코디네이터 (Claude Code)
• Polecat: 작업 실행 에이전트 (일시적)
• Witness: 작업자 모니터링, 라이프사이클 관리
• Refinery: 병합 큐, PR 검토, 통합
• Deacon: 데몬 프로세스, 에이전트 라이프사이클
• Overseer: 인간 사용자 (전략 설정)

MEOW 워크플로우:

• Formula → Protomolecule → Mol/Wisp
• Cook, Pour, Wisp, Squash, Burn 연산자
• 충돌 복구: 어떤 에이전트든 다른 에이전트가 중단한 지점부터 계속 가능

기술 스택:

• Beads: Git 기반 이슈 트래커 (작업 상태 원장)
• Tmux: 에이전트 세션 관리
• Go 1.23+, Git 2.25+

강점:

• 작업 영속성 (충돌, 재시작 후에도 보존)
• 구조화된 에이전트 간 통신 (Mailbox, Handoff)
• 20-30개 에이전트 확장 가능
• 웹 대시보드 (포트 8080)
• Formula 기반 워크플로우 자동화
• MAKER 문제 (20개 원판 하노이 탑) 해결 가능

요구 사항:

• 7~8단계 진화 수준 (10개 이상 에이전트 수동 관리 경험)
• Tmux 사용 필수
• 높은 비용 (여러 Claude Code 계정 필요)
• 바이브 코딩 철학 수용

---

핵심 차이점 비교표

항목	내 방향	Oh-My-OpenCode	GAS-TOWN
타겟 플랫폼	Claude Code + OpenCode	OpenCode	Claude Code
에이전트 수	12개	5개 핵심 (Sisyphus, Oracle, Frontend Engineer, Librarian, Explore)	20-30개
오케스트레이션	없음 (독립 에이전트)	Sisyphus 중심	Mayor + Witness + Refinery
작업 영속성	없음	컨텍스트 기반	Git 기반 (Beads)
모델 전략	Haiku/Sonnet 분배	다중 모델 (Claude/GPT/Gemini)	Claude Code 단일 모델
워크플로우	수동	자동 (Todo Enforcer)	Formula 기반 자동화
인터페이스	CLI	CLI + ultrawork	Tmux + Mayor 세션 + 웹 대시보드
협업 메커니즘	없음	병렬 백그라운드	Mailbox, Handoff, Hook
규모 확장	10개 미만	중간 규모	20-30개
진입 장벽	낮음	중간	매우 높음 (7단계+ 필요)
비용	보통	높음	매우 높음
현황	안정적	OAuth 제한 이슈	안정적 (3주된 프로젝트)

---

나의 방향성 제안

현재 구성 (12개 에이전트)에서 발전 방향:

Phase 1: 경량 오케스트레이션 추가 (GAS-TOWN 영감)

• pm 에이전트를 “Mayor” 역할로 확장
• 작업 상태를 Org-mode + Denote로 영속화 (Git 기반)
• 에이전트 간 메시지 전달 메커니즘 추가 (Org-mode 헤더 활용)

Phase 2: 워크플로우 자동화 (Oh-My-OpenCode 영감)

• Org-mode TODO 키워드를 Formula처럼 활용
• Todo Continuation 메커니즘 추가
• MCP 도구 통합 (Context7, Exa 검색)

Phase 3: 규모 확장 준비

• Tmux 세션 관리 스크립트 추가 (선택적)
• 작업 모니터링 대시보드 (Org-mode Agenda 활용)
• 충돌 복구 메커니즘

Phase 4: 하이브리드 접근

• 독립 에이전트 (1-5개 작업): 현재 방식 유지
• 복잡한 프로젝트 (5개 이상): 경량 오케스트레이션 활성화
• 대규모 작업 (10개 이상): GAS-TOWN 스타일 도입

---

결론: 나의 포지셔닝

현재 위치

• 진화 단계: 6단계 (CLI, 멀티 에이전트, YOLO)
• 강점: 플랫폼 독립성, 명확한 역할 분담, 낮은 진입 장벽
• 약점: 오케스트레이션 부재, 작업 영속성 부족

발전 방향

1. Org-mode 네이티브 오케스트레이션

   • GAS-TOWN의 Beads처럼 Org-mode + Denote를 작업 원장으로 활용
   • 기존 PKM 워크플로우와 자연스럽게 통합

2. 경량 Mayor 구현

   • pm 에이전트를 Mayor로 확장
   • Org-mode Agenda를 대시보드로 활용
   • Tmux 선택적 도입 (필수 아님)

3. 점진적 확장

   • 1-5개: 독립 에이전트 (현재 방식)
   • 5-10개: 경량 오케스트레이션
   • 10개+: GAS-TOWN 영감 받은 시스템

차별화 포인트

• Org-mode 네이티브: Emacs/Org-mode/Denote 생태계와 완벽 통합
• 플랫폼 독립: Claude Code + OpenCode 양쪽 지원
• 점진적 복잡도: 필요에 따라 오케스트레이션 수준 선택
• 재현 가능: NixOS + Emacs + Digital Garden 철학과 일치

다음 단계:

1. Oh-My-OpenCode 설치 및 테스트 (OAuth 문제 해결 후)
2. GAS-TOWN 로컬 설치 및 학습
3. pm 에이전트를 경량 Mayor로 확장
4. Org-mode 기반 작업 원장 프로토타입

---

📊 Tokens: 40356 in, 7891 out

@user 좋아.