처음엔 모델이 문제인 줄 알았다.
근데 실제로는 대부분 모델보다 기대치가 먼저 문제였다.
OpenCode + oh-my-opencode 조합은 처음 붙이면 꽤 세 보인다.
실제로도 세다.
근데 초반 실패담을 모아보면 대부분은 기능 부족보다 운영 착각에서 시작된다.
Quick Answer
OpenCode + oh-my-opencode 초반 실패는 대개 여섯 군데에서 나온다.
이름 전환 혼선,설치 기대치,공유 설정,권한 과개방,에이전트 과다,Claude Code와 같은 체급으로 바로 기대하는 문제다.
즉 도구가 멍청해서보다, 우리가 너무 빨리 많은 걸 기대해서 삐끗하는 경우가 많다.
이 글이 필요한 사람
- 설치는 했는데 생각보다 매끈하지 않아서 당황한 사람
- OpenCode + oh-my-opencode를 Claude Code 대체제로 바로 상상한 사람
- 팀에 소개하기 전에 “어디서 넘어질지” 먼저 알고 싶은 사람
- 시행착오를 덜 내고 시작하고 싶은 사람
지금 결론
- 이 조합의 초반 실패는 기능이 없어서보다 기대치와 운영 설계가 안 맞아서 생긴다.
- 가장 흔한 실수는 “바로 팀 생산성 도구”로 보는 것이다.
- 초반에는 화려한 기능보다 설치 루트, 권한, 공유, wrapper 같은 기본기부터 고정해야 덜 망한다.
- 실패담을 미리 보면 실망은 줄고 파일럿 성공률은 올라간다.
실패담이 왜 가치가 있나
기술 글은 대체로 잘되는 장면만 보여주기 쉽다.
근데 이런 류 도구는 잘되는 장면보다 어디서 삐끗하는지를 먼저 보는 쪽이 실무에 더 도움이 된다.
왜냐면 OpenCode 진영은 자유도가 높은 만큼 실패 패턴도 꽤 예측 가능하기 때문이다.
즉 같은 함정을 남들도 비슷하게 밟는다.
그럼 미리 보면 된다.
괜히 영웅서사 만들 필요 없다.
사람은 원래 설치하다가도 삐끗하고, 공유 켰다가도 아차 하고, 에이전트 많이 돌렸다가 로그에 파묻힌다.
정상이다.
1. 이름이 바뀌는 과도기라는 사실을 모르고 시작하는 실패
이건 생각보다 흔하다.
지금 GitHub README를 보면 프로젝트는 oh-my-openagent 쪽으로 가고 있고, 패키지와 일부 호환 레이어는 여전히 oh-my-opencode 이름을 쓴다.
문서에도 기존 이름과 새 이름이 같이 보인다.
이건 과도기라 자연스럽다.
근데 사용자는 여기서 헷갈린다.
흔한 증상
- 검색 결과마다 이름이 다름
- 설치 문서가 서로 달라 보임
- 설정 파일 이름이 다름
- “내가 다른 걸 깐 건가?” 싶어짐
실제 문제
설치가 틀린 게 아니라 이름 전환기 문맥을 놓친 경우가 많다.
덜 삐끗하는 법
- 팀 위키에 설치 기준 문서 1개만 적기
- “우리는 이 이름과 이 명령만 쓴다”를 박아두기
- 레거시 호환은 알아도 되지만 운영 표준엔 하나만 쓰기
초반엔 다양성이 아니라 통일성이 답이다.
2. 설치가 끝나면 곧바로 잘 굴러갈 거라고 생각하는 실패
이건 너무 흔해서 사실 실패담이라기보다 입문 코스 같다.
OpenCode 설치는 비교적 쉽다.
oh-my-opencode도 에이전트에게 설치 문서를 먹여서 처리하게 하라는 식으로 접근이 꽤 적극적이다.
여기까진 좋다.
문제는 많은 사람이 설치 완료를 운영 준비 완료로 착각한다는 거다.
실제로 필요한 것
- provider 선택
- permission 결정
- share 정책 결정
- 팀 공통 명령 정리
- 실패 시 복구 순서
즉 설치는 1막이고, 운영은 2막이다.
근데 많은 사람이 1막 끝나고 박수친다.
그러면 2막에서 지친다.
덜 삐끗하는 법
- 설치 완료 후 바로 파일럿 체크리스트 작성
- 첫 주엔 읽기/탐색 태스크만
- 편집/실행은 ask
처음부터 다 하려 하지 마라.
진짜다.
3. share 기능을 편의 기능으로만 보는 실패
OpenCode Share docs를 보면 기본은 manual이다.
이 설정은 꽤 의미심장하다.
왜냐면 공유 링크는 단순 편의가 아니라 노출 범위와 연결되기 때문이다.
그런데 초반엔 “팀끼리 보려면 auto가 편하지 않나?” 하고 바로 올리기 쉽다.
여기서 문제는 편한 것과 안전한 것이 다를 수 있다는 거다.
실패 패턴
- auto share 켬
- 세션 안에 예민한 컨텍스트 들어감
- 나중에 정리하려 함
- 나중에 안 함
세상 많은 문제가 여기서 시작된다.
덜 삐끗하는 법
- 기본은 manual
- 데모용 repo만 예외
- 민감 repo는 disabled 고려
초반엔 귀찮아도 수동이 오히려 건강하다.
4. 권한을 널널하게 열어두고 “나중에 줄이자” 하는 실패
OpenCode는 tool permission이 세밀하다.
좋다.
문제는 초반에 귀찮아서 다 열어두는 경우다.
이렇게 되면 도구가 강한 만큼 사람도 금방 겁난다.
왜냐면 팀원마다 행동이 달라지기 때문이다.
흔한 상황
- 어떤 사람은
bash allow - 어떤 사람은
edit allow - 어떤 사람은
ask - 프롬프트는 같은데 결과가 다름
그럼 그 순간부터 “도구가 이상하다” 는 말이 나오는데, 사실 설정이 제각각인 거다.
덜 삐끗하는 법
초기값은 boring하게 가야 한다.
- read/grep/list: allow
- edit/bash: ask
- webfetch: allow
멋없어 보이지만 초반 생존율은 올라간다.
5. 에이전트 수를 늘리면 자동으로 고급 팀이 되는 줄 아는 실패
oh-my-openagent README의 매력 중 하나는 배경 에이전트와 강한 오케스트레이션 서사다.
진짜 멋있다.
문제는 사람 마음이 금방 커진다는 거다.
“오, 그럼 우리도 5개 돌려보자.”
여기서 로그 지옥이 열린다.
왜 삐끗하나
- 결과를 누가 읽을지 안 정함
- 충돌 난 내용을 누가 판단할지 안 정함
- 비용 상승을 체감하기 전에 호출 수가 늘어남
즉 에이전트 수가 늘어난다고 조직 능력이 자동으로 생기지 않는다.
덜 삐끗하는 법
처음엔 2개면 충분하다.
- 메인 1
- 탐색 1
그리고 둘 다 분명히 다른 역할을 맡겨라.
그게 훨씬 덜 피곤하다.
6. Claude Code와 똑같은 감각을 기대하는 실패
이건 비교글을 이미 본 사람일수록 더 잘 빠진다.
왜냐면 머릿속에 기준점이 생겼기 때문이다.
근데 기준점이 생기면 장점도 잘 보이지만, 기대치도 같이 부풀어 오른다.
흔한 착각
- 세션 메모리도 비슷하겠지
- 팀 오케스트레이션도 비슷하겠지
- 설치만 하면 바로 같은 질감이겠지
실전은 그렇지 않다.
철학도 다르고, 기본 강점도 다르다.
OpenCode + oh-my-opencode는 자유도와 하네스성이 강하고, 그 대가로 운영 결정이 더 필요하다.
즉 같은 체급의 도구라기보다 다른 운영 감각을 요구하는 도구라고 보는 쪽이 맞다.
이 차이를 인정하면 실망이 줄어든다.
인정 안 하면 초반에 “왜 이건 저렇게 안 되지?”가 계속 생긴다.
7. wrapper 없이 바로 팀에 뿌리는 실패
이건 생각보다 크게 아프다.
팀원이 모두 터미널 친화적이고 설정 파일도 잘 읽는다면 괜찮을 수 있다.
근데 대부분은 그렇지 않다.
그래서 wrapper가 중요하다.
예를 들면 ./scripts/agent-run.sh 하나만 있어도 체감이 다르다.
왜 중요한가
- 실행 명령 통일
- 환경 변수 통일
- 기본 config 위치 통일
- 장애 재현 쉬움
wrapper 없이 시작하면 다들 “나는 이렇게 켰는데?”를 말하게 된다.
그다음부터는 디버깅이 아니라 인터뷰다.
가장 덜 아픈 시작 방식
실패담을 줄이는 가장 쉬운 방법은 도구를 덜 화려하게 쓰는 거다.
초반 2주 기준으로는 이게 제일 낫다.
1주차
- 2명 파일럿
- manual share
- edit/bash ask
- 에이전트 2개 이하
- 설치 문서 1장
2주차
- wrapper 1개
- 공통 config 샘플 1개
- 실패 사례 3개 기록
- 어떤 작업에 안 맞는지도 같이 기록
이렇게 가면 멋은 조금 덜해도 운영은 훨씬 덜 아프다.
그리고 솔직히 실무는 멋보다 재현성이 더 중요하다.
실수 TOP 5
1. 이름 전환기를 무시하고 문서를 뒤섞어 읽는 실수
검색 결과만 섞어 읽으면 내가 잘못 설치한 줄 안다.
2. 설치 완료를 도입 완료로 착각하는 실수
이게 제일 흔하다.
3. 공유를 너무 쉽게 켜는 실수
수동 공유가 귀찮아 보여도 초반엔 그게 건강하다.
4. 에이전트를 많이 돌리는 게 더 성숙한 운영이라고 믿는 실수
초반엔 오히려 더 피곤해질 수 있다.
5. wrapper와 런북 없이 팀에 던지는 실수
그 순간부터 도구보다 팀원마다 다른 습관을 디버깅하게 된다.
FAQ
Q. 그럼 OpenCode + oh-my-opencode는 초반에 별로인가요?
아니다.
오히려 잘만 시작하면 꽤 강하다.
다만 기대치를 잘못 잡으면 실망이 빨리 온다.
Q. 실패담을 미리 보면 너무 겁먹지 않나요?
조금 겁먹는 게 낫다.
아무 생각 없이 넓게 도입하는 것보다 훨씬 싸다.
Q. 가장 먼저 하나만 고르라면 뭘 고정해야 하나요?
실행 명령 1개다.
그다음이 share, 그다음이 permission이다.
Q. Claude Code와 비교하면 결국 어느 쪽이 낫나요?
그건 팀 문화에 달렸다.
예측 가능성과 통일성이 우선이면 Claude Code 쪽이 편할 수 있고, 자유도와 커스터마이징이 중요하면 OpenCode 진영이 훨씬 재밌다.
다음에 읽을 글
- OpenCode + oh-my-opencode 운영 체크리스트 2026 — 팀에서 실제로 굴릴 때 먼저 막히는 5가지
- OpenCode + oh-my-opencode 비용 구조 비교 2026 — 붙이면 뭐가 늘고 뭐가 줄어드나
- LLM Wiki 2026 — RAG 안 붙이고도 개인 위키가 굴러가는 조건, second brain 운영 체크리스트