여고생쨩⭐️ 개발공부

AI로 개발하는 모노레포에서, Hono를 쓰면 스웨거가 더 이상 필요 없는 이유

고생쨩 — Mon, 20 Jul 2026 08:59:50 +0900

AI 에이전트로 개발하는 모노레포 환경에서 Hono를 쓰면 스웨거(Swagger/OpenAPI)가 사실상 불필요해짐. 이유는 하나임 — 타입 자체가 API 명세가 되기 때문. 서버 타입을 클라이언트가 직접 import 하니 별도 명세 문서가 필요 없고, AI는 그 타입을 곧바로 읽어 코드를 생성함. 스웨거가 하던 "명세 공유"와 "문서화" 역할을 타입 시스템이 대신함.

원래 스웨거가 왜 필요했나

스웨거의 본질은 명세 공유(spec sharing)임. 서버와 클라이언트가 물리적으로, 조직적으로 분리돼 있을 때 필요한 계약서 역할.

백엔드팀과 프론트팀이 다른 저장소, 다른 언어로 개발함.
그래서 "이 엔드포인트는 뭘 받고 뭘 뱉는지"를 적은 문서가 필요함.
그 문서가 바로 OpenAPI 스펙(JSON/YAML)이고, Swagger UI로 렌더링함.

핵심 문제는 이 명세가 실제 코드와 따로 논다는 것(drift). 코드를 고쳐도 스펙을 안 고치면 문서가 거짓말을 함. 데코레이터나 zod-openapi 같은 도구로 코드에서 스펙을 뽑아내는 방식도 있지만, 어쨌든 "코드 → 스펙 → 클라이언트 코드 생성"이라는 중간 단계가 존재함.

Hono RPC가 이 구조를 뒤집음

Hono RPC는 명세 공유 문제를 문서가 아니라 TypeScript 타입으로 해결함. 이게 핵심 전환.

서버는 라우트 정의의 타입만 export 함.

// server.ts
import { Hono } from 'hono'
import { zValidator } from '@hono/zod-validator'
import { z } from 'zod'

const route = new Hono()
  .post(
    '/posts',
    zValidator('json', z.object({ title: z.string(), body: z.string() })),
    (c) => {
      const { title } = c.req.valid('json')
      return c.json({ id: 1, title }, 201)
    }
  )

export type AppType = typeof route

클라이언트는 이 타입만 가져와서 hc로 감쌈.

// client.ts
import { hc } from 'hono/client'
import type { AppType } from './server'

const client = hc<AppType>('http://localhost:8787/')

// 입력 타입, 출력 타입, 상태 코드까지 전부 자동 추론됨
const res = await client.posts.$post({
  json: { title: 'hello', body: 'world' },
})

여기서 일어나는 일:

코드 생성 없음. openapi-generator 같은 빌드 단계가 아예 없음. typeof route를 import 하는 게 전부임.
타입이 곧 단일 진실 공급원(single source of truth). 서버 코드를 고치는 순간 클라이언트 타입이 자동으로 바뀜. drift가 원천적으로 불가능함.
zValidator가 스키마 역할. zod로 정의한 입력 스키마가 그대로 클라이언트 입력 타입이 됨. 문서를 따로 쓸 필요가 없음.
응답도 타입 안전. c.json(data, 201)의 상태 코드와 페이로드가 판별 유니온(discriminated union)으로 클라이언트에 전달됨. 성공/에러 분기까지 타입으로 잡힘.

Hono 개발자 본인도 RPC가 "OpenAPI나 gRPC로 하고 싶었던 걸 대신 채워줄 수 있다"고 말함. 즉 보완재가 아니라 대체재로 본 것.

모노레포가 이걸 완성함

Hono RPC가 진짜 빛나는 조건이 바로 모노레포임. 서버와 클라이언트가 같은 저장소, 같은 언어(TypeScript)에 있을 때 타입을 직접 import 할 수 있기 때문.

프론트가 import type { AppType } from '@/server/app' 한 줄로 서버 계약을 그대로 씀.
네트워크 경계를 넘어도 IDE 자동완성, 타입 체크가 전부 살아있음.
TypeScript Project References(composite: true + references)를 걸어주면 대형 모노레포에서도 타입이 any로 뭉개지지 않고 제대로 추론됨.

정리하면, 스웨거는 "분리된 두 세계를 잇는 다리"였는데, 모노레포는 애초에 세계가 하나임. 다리가 필요 없어짐.

AI 개발이 결정타를 날림

여기에 AI 에이전트 개발이 더해지면 스웨거의 마지막 존재 이유까지 사라짐.

스웨거 UI의 또 다른 용도는 사람이 눈으로 읽는 문서였음. "이 API가 뭘 받는지" 개발자가 브라우저로 확인하는 용도. 그런데 AI 에이전트는 브라우저로 문서를 볼 필요가 없음.

AI는 소스 코드와 타입을 직접 읽음. zod 스키마, 라우트 핸들러, AppType을 그대로 컨텍스트로 넣으면 됨.
타입이 곧 스펙이니, AI에게 정확하고 검증 가능한 계약이 이미 코드 안에 있음. 별도 OpenAPI 파일을 만들어 먹일 이유가 없음.
오히려 중간에 낀 OpenAPI 스펙은 drift 위험이 있는 부정확한 2차 정보임. AI 입장에서 원본 타입이 더 신뢰할 만함.
AI가 클라이언트 코드를 짤 때도 hc<AppType>가 컴파일 타임에 검증해 줌. 타입이 안 맞으면 즉시 에러가 남 → AI의 환각(hallucination)을 타입 시스템이 잡아줌.

즉 AI 시대에는 "AI가 읽을 문서"를 따로 유지하는 게 아니라, AI가 읽을 코드(타입)를 잘 짜는 것이 문서화임. Hono RPC가 정확히 그 방향임.

그래도 스웨거가 필요한 경우

균형을 위해 짚음. 스웨거가 여전히 유효한 상황도 분명히 있음.

외부 공개 API. 우리 타입을 import 할 수 없는 제3자(다른 회사, 다른 언어 클라이언트)가 소비자라면 OpenAPI 스펙이 여전히 표준 계약서임.
비(非) TypeScript 클라이언트. 모바일 네이티브, Python, Go 등에서 붙는다면 언어 중립적인 스펙이 필요함.
공식 문서 포털. 대외적으로 렌더링된 API 문서(Swagger UI, Scalar 등)를 제공해야 하는 제품이라면 필요함.
계약 기반 테스트/목킹. OpenAPI 스펙 기반으로 mock 서버를 돌리거나 계약 테스트를 하는 조직 관행이 있다면 유지 가치 있음.

참고로 Hono도 이걸 버리라고 강요하지 않음. @hono/zod-openapi로 필요할 때 OpenAPI 스펙을 뽑아낼 수 있게 열어둠. 즉 스웨거를 기본값이 아니라 선택지로 격하시킨 것.

결론

정리하면 이거임:

스웨거의 역할은 "분리된 서버·클라이언트 간 명세 공유 + 사람이 읽는 문서"였음.
모노레포는 서버·클라이언트를 하나로 합쳐 명세 공유를 타입 import로 대체함.
Hono RPC는 코드 생성 없이 AppType 하나로 이걸 실현함 — drift 제로, 단일 진실 공급원.
AI 에이전트는 문서가 아니라 타입을 직접 읽어 코드를 짜고, 타입 시스템이 그 결과를 검증함.
결국 내부용 모노레포 + Hono + AI 조합에선 스웨거가 불필요한 중간 레이어로 남음.
단, 외부 공개·비TS 클라이언트·공식 문서가 필요하면 여전히 유효함. 기본값이 아니라 선택지일 뿐.

한 줄 요약: 타입이 곧 문서이고 계약인 시대. Hono 모노레포에선 스웨거를 기본으로 깔 이유가 없음.

Ponytail — AI 에이전트를 "제일 게으른 시니어 개발자"로 만드는 스킬

고생쨩 — Wed, 24 Jun 2026 08:55:39 +0900

ponytail은 Claude Code, Codex, Gemini CLI 같은 AI 코딩 에이전트한테 "안 써도 되는 코드는 쓰지 마라"를 주입하는 스킬 플러그인임. 콘셉트는 회사 다닌 지 버전 관리 시스템보다 오래된, 긴 머리 묶고 둥근 안경 쓴 전설의 시니어임. 코드 50줄 보여주면 아무 말 없이 1줄로 바꿔버리는 그 사람을 에이전트 안에 넣은 거임.

핵심 철학은 단순함. 안 쓴 코드가 최고의 코드(The best code is the code you never wrote)임.

GitHub 별 5만 개 넘게 받은 화제의 레포임.

왜 필요함?

AI 에이전트한테 "날짜 선택기 만들어줘" 하면 보통 이렇게 함:

flatpickr 라이브러리 설치함
래퍼 컴포넌트 작성함
스타일시트 추가함
타임존 논의 시작함

근데 ponytail 깔려 있으면 이렇게 끝남:

<!-- ponytail: browser has one -->
<input type="date">

404줄짜리가 23줄 됨. 브라우저에 이미 있는 걸 왜 다시 만드냐는 거임.

어떻게 동작함?

코드 쓰기 전에 에이전트가 사다리를 위에서부터 타고 내려오다가 먼저 걸리는 칸에서 멈춤:

1. 이거 존재할 필요 있음?   → 없으면 스킵 (YAGNI)
2. 표준 라이브러리에 있음?   → 그거 씀
3. 네이티브 플랫폼 기능임?    → 그거 씀
4. 이미 깔린 의존성에 있음?   → 그거 씀
5. 한 줄로 됨?              → 한 줄
6. 그제서야: 동작하는 최소한

중요한 건 게으른 거지 부주의한 게 아니라는 점임. 신뢰 경계(trust boundary) 검증, 데이터 유실 처리, 보안, 접근성은 절대 자르지 않음. 코드가 작아지는 이유는 줄여서가 아니라 그만큼만 필요해서임.

사용 예시

전부 실제 벤치마크 출력에서 가져온 거임. 같은 모델(Claude Haiku 4.5)이 스킬 없을 때 vs ponytail 켰을 때를 비교한 거임.

예시 1 — 정렬 (24줄 → 1줄)

// ponytail: this exists
numbers.sort((a, b) => a - b)

모든 런타임에 정렬만 평생 파는 사람들이 튜닝해둔 sort가 이미 들어있음. 직접 퀵소트 짤 이유 없음.

예시 2 — API 엔드포인트 (5개 파일 → 9줄)

# ponytail: drop the layers; keep the response schema, it whitelists what leaves the API
class UserOut(BaseModel):
    id: int
    name: str
    email: str

@app.get("/users/{user_id}", response_model=UserOut)
def get_user(user_id: int, db: Session = Depends(get_db)):
    user = db.get(User, user_id)
    if not user:
        raise HTTPException(404)
    return user

리포지토리 패턴, 서비스 레이어, 커스텀 예외 클래스는 다 의식(ceremony)에 불과했음. 근데 response_model=UserOut은 안 자름. 이게 어떤 필드가 API 밖으로 나가는지 화이트리스트로 거르는 신뢰 경계라서임. 그냥 return user 하면 노출하면 안 되는 컬럼까지 다 새버림. 이게 ponytail이 긋는 선임 — 레이어는 잘라도 신뢰 경계는 지킴.

예시 3 — 날짜/색상 선택기

앞에서 본 것처럼 네이티브 <input type="date">, <input type="color">로 끝남. 날짜 선택기 404줄 → 23줄, 색상 선택기 287줄 → 23줄임.

숫자로 보는 효과

실제 오픈소스 레포(FastAPI + React 풀스택 템플릿)를 헤드리스 Claude Code 세션이 직접 수정하게 하고, 남긴 git diff로 채점한 결과임. 기능 티켓 12개, 같은 에이전트로 스킬 있을 때/없을 때 비교, n=4, Haiku 4.5 기준임.

무(無)스킬 기준 대비	코드량(LOC)	토큰	비용	시간	안전성
ponytail	-54%	-22%	-20%	-27%	100%
caveman (간결 프롬프트)	-20%	+7%	+3%	+2%	100%
"YAGNI + 한 줄" 프롬프트	-33%	-14%	-21%	-30%	95%

ponytail은 모든 지표를 다 깎으면서도 안전성 100%를 유지한 유일한 방식임. 과하게 만드는 함정이 있는 작업에서 효과가 제일 크고, 이미 최소한인 코드에선 거의 0임.

⚠️ 주의: 초기엔 80~94% 감소라고 홍보했는데, 그건 단발성(single-shot) 생성 기준이라 맨모델 답변이 설명·옵션으로 길어진 탓도 있었음. 위 표가 공정한 에이전트 기준으로 보정한, 더 방어 가능한 수치임. 이런 솔직함이 오히려 신뢰 가는 포인트임.

설치

플러그인이 노드 라이프사이클 훅 2개를 돌려서 node가 PATH에 있어야 함(없어도 스킬은 동작하고 항상 켜진 활성화만 조용해짐).

Claude Code

/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail

Codex

codex plugin marketplace add DietrichGebert/ponytail

/plugins에서 Ponytail 설치하고, /hooks에서 훅 2개 신뢰 처리하면 됨.

Gemini CLI

gemini extensions install https://github.com/DietrichGebert/ponytail

이 외에도 GitHub Copilot CLI, OpenCode, pi, OpenClaw, Antigravity CLI까지 14개 에이전트 지원함. Cursor·Windsurf·Cline·Zed·Aider·Kiro 같은 룰 기반 도구는 레포의 룰 파일만 복사하면 됨. AGENTS.md만 읽는 호스트(CodeWhale, Codex 확장 등)는 그 파일 하나로 무설정 동작함.

기본 강도는 full임. PONYTAIL_DEFAULT_MODE 환경변수나 config 파일로 lite/full/ultra/off 설정 가능함.

커맨드

커맨드	하는 일
`/ponytail [lite\|full\|ultra\|off]`	강도 설정 또는 끄기
`/ponytail-review`	현재 diff를 과설계 관점으로 리뷰, 삭제 목록 줌
`/ponytail-audit`	diff뿐 아니라 레포 전체를 과설계 감사
`/ponytail-debt`	미뤄둔 `ponytail:` 단축들을 장부로 모아 "나중에"가 "영영 안 함" 되는 걸 방지
`/ponytail-gain`	벤치마크 기반 효과 스코어보드 표시
`/ponytail-help`	커맨드 요약

/ponytail ultra는 코드베이스가 너한테 개인적으로 잘못했을 때 쓰는 모드임.

평가

ponytail은 새로운 기술이라기보다 YAGNI(You Aren't Gonna Need It) 원칙을 에이전트한테 강제로 체화시키는 잘 만든 프롬프트/스킬 패키지임. AI 에이전트가 시키지도 않은 추상화·라이브러리·레이어를 자꾸 쌓는 과설계 성향을 정조준한 거임.

좋은 점:

토큰·비용·시간 다 줄어드는 게 실측으로 증명됨
보안·검증·접근성은 안 자르는 선을 명확히 그음
14개 에이전트 호환 + MIT 라이선스로 도입 부담 적음
벤치마크 수치를 스스로 보정·공개하는 솔직함

생각할 점:

추론 토큰을 많이 쓰는 모델(예: GPT-5.5)에선 사다리 따지느라 오히려 토큰이 늘 수도 있음
팀이 정말 복잡한 추상화가 필요한 케이스에선 강도 조절이나 off가 필요함

AI 어시스트 개발 워크플로우 굴리는 팀이라면, 사람 리뷰 단계 사이에 끼워넣는 "기본 게으름 가드레일"로 한 번 써볼 만함.

레포: https://github.com/DietrichGebert/ponytail

[Claude Code] 다이내믹 워크플로우(Dynamic Workflows) 써보기

고생쨩 — Fri, 5 Jun 2026 08:55:48 +0900

워크플로우 = Claude가 직접 짠 자바스크립트 오케스트레이션 스크립트임. Claude가 작업을 받아 스크립트를 작성하면, 런타임이 백그라운드에서 그 스크립트를 돌리면서 서브에이전트 수십~수백 개를 병렬로 굴림. 세션은 그동안 계속 반응하고, 끝나면 중간 과정 전부가 아니라 검증된 최종 결과 하나만 돌아옴.

기존 방식이랑 뭐가 다름

핵심은 "누가 계획(plan)을 들고 있느냐"임.

	서브에이전트 / 스킬 / 에이전트 팀	워크플로우
오케스트레이터	Claude 본인 (턴 단위 판단)	스크립트
중간 결과가 사는 곳	Claude 컨텍스트 윈도우	스크립트 변수
재사용되는 단위	워커/지시문 정의	오케스트레이션 자체
규모	턴당 몇 개 위임	런당 수십~수백 개

기존엔 Claude가 매 턴 "다음에 뭘 띄울까"를 정하고, 모든 중간 결과가 컨텍스트에 쌓임.
워크플로우는 루프·분기·중간 변수를 전부 스크립트가 들고 있음. 그래서 Claude 컨텍스트엔 최종 답만 남음.
단순히 에이전트 수만 늘리는 게 아니라, "에이전트들끼리 서로의 결과를 적대적으로 검증(adversarial review)" 같은 반복 가능한 품질 패턴을 코드로 박아둘 수 있음.

어떻게 띄우나

세 가지 방법 있음.

프롬프트에 ultracode 키워드 넣기 — 세션 effort는 그대로 두고 이 작업만 워크플로우로.
```
ultracode: src/routes/ 밑 모든 API 엔드포인트의 인증 누락 검사
```
"워크플로우로 돌려줘" 같은 자연어도 똑같이 먹힘. (참고: v2.1.160 이전엔 트리거 키워드가 workflow였음. 자연어는 두 버전 다 됨.)
/effort ultracode — 켜두면 매 작업마다 Claude가 알아서 워크플로우를 짤지 판단함. 이해→수정→검증으로 한 요청이 워크플로우 여러 개로 쪼개지기도 함. 토큰·시간 많이 씀. 세션 끝나면 풀림.
번들 워크플로우 /deep-research — 바로 체감용. 질문 하나를 여러 각도로 웹 검색·교차검증해서 출처 달린 리포트로 줌.
```
/deep-research Node.js 권한 모델이 v20에서 v22로 가며 뭐가 바뀜?
```

실행 전에 Claude가 계획된 phase들을 보여주며 승인을 물음. 스크립트 원문도 Ctrl+G로 열어볼 수 있음. bypass/claude -p/Agent SDK는 안 묻고 바로 돌아감.

진행 상황 보기 / 저장 / 재사용

/workflows — 실행 중·완료된 워크플로우 목록. 선택해서 들어가면 phase별 에이전트 수·토큰·경과 시간이 보임. 더 파고들면 각 에이전트의 프롬프트·최근 툴 호출·결과까지 확인 가능.
진행 뷰 단축키: p 일시정지/재개, x 중단, r 재시작, s 현재 런 스크립트를 명령으로 저장.
저장 위치 두 곳:
- .claude/workflows/ — 레포 공유용 (clone하는 사람 다 씀)
- ~/.claude/workflows/ — 내 홈, 모든 프로젝트에서 나만 씀
저장하면 /<이름>으로 다음 세션부터 재사용. 매 브랜치마다 돌리는 리뷰 같은 거 굳히기 좋음.
args로 입력도 넘김. Run /triage-issues on issues 1024, 1025, 1030 식으로 구조화된 데이터가 스크립트 전역 args로 들어감.

직접 써보고 느낀 장점

1. 작업에 맞는 모델을 단계별로 골라 쓰니 토큰이 오히려 줄어듦.
워크플로우의 모든 에이전트는 기본적으로 세션 모델을 쓰지만, 작업에 따라 알아서 다른 모델을 사용함. ex) 리서치 등엔 하이쿠 사용.

솔직한 단서: 런 전체로 보면 에이전트가 많아 토큰을 더 쓸 수도 있음. 절약 효과는 "적절한 모델 라우팅 + 컨텍스트 비오염"에서 나오는 거지 무조건 줄어드는 마법은 아님. 그래서 모델 선택을 손봐주는 게 핵심임.

2. 하네스에서 오케스트레이션을 걷어내도 됨.
예전엔 서브에이전트 프롬프트 폴더나 스킬, 별도 하네스로 직접 오케스트레이터를 짜야 했음. 이제 그 조율 로직을 스크립트가 들고 가니까 하네스가 가벼워짐. 이미 만들어둔 오케스트레이터가 있으면 그걸 가리키며 "같은 일 하는 워크플로우로 만들어줘"라고 시킬 수도 있음. 조율은 코드로 굳고, 사람은 결과만 받음.

단점 (그리고 보완 팁)

각 서브에이전트가 정확히 뭘 하는지 한눈에 파악하기 어려움.
중간 결과가 컨텍스트 밖 스크립트 변수에 살고 최종 답만 돌아오는 구조라, 디버깅·신뢰 측면에선 "블랙박스" 느낌이 남.

보완책:

/workflows 진행 뷰에서 phase → agent로 드릴인하면 각 에이전트의 프롬프트·툴 호출·결과를 직접 볼 수 있음. 답답할 땐 여기부터.
모든 런은 스크립트를 ~/.claude/projects/ 밑 파일로 떨궈둠. Claude한테 그 경로 물어서 직접 읽거나, 수정해서 다시 돌리거나, 이전 런과 diff 떠볼 수 있음.
단계 간 사람 검토가 꼭 필요하면, 한 워크플로우로 다 묶지 말고 단계별로 워크플로우를 쪼개서 사이사이 직접 확인.

실전 팁 모음

작게 먼저 재보기 — 레포 전체 말고 디렉터리 하나, 넓은 질문 말고 좁은 질문으로 한 번 돌려 토큰 감 잡기. 캡 덕에 폭주는 막히지만, 비용 가늠은 직접 해야 함.
모델 미리 확인 — 큰 런 전에 /model 체크. 평소 작은 모델로 바꿔뒀다면 그대로 큰 작업에 안 들어가게.
allowlist 미리 채우기 — 서브에이전트는 항상 acceptEdits 모드로 돌고 내 tool allowlist를 상속함. 파일 편집은 자동 승인되지만, allowlist 밖 셸 명령·웹 페치·MCP 툴은 런 중간에 멈춰 물어봄. 긴 런은 필요한 명령을 미리 등록.
중단해도 손해 적음 — 같은 세션 안에서는 재개 가능. 끝난 에이전트는 캐시된 결과를 돌려주고 나머지만 새로 돎. 단, Claude Code를 종료하면 다음 세션에선 처음부터.
구조화 출력은 schema로 — 다음 단계가 결과를 소비해야 하면, "JSON으로 줘"라고 비는 대신 스키마를 줘서 검증된 구조로 강제하는 게 훨씬 안정적임.

제약 / 끄는 법

런 도중 사용자 입력 못 넣음(에이전트 권한 프롬프트만 멈춤). 동시 실행 최대 16개(코어 적으면 더 적게), 런당 총 1,000개 상한. 워크플로우 스크립트 자체는 파일·셸을 직접 못 만짐 — 실제 작업은 에이전트가 함.
끄기: /config에서 Dynamic workflows 토글 / ~/.claude/settings.json에 "disableWorkflows": true / 환경변수 CLAUDE_CODE_DISABLE_WORKFLOWS=1. 조직 전체는 managed settings나 admin 페이지에서.

언제 꺼내 쓰나

한 대화로 조율하기엔 에이전트가 너무 많이 필요할 때, 또는 조율 자체를 읽고 다시 돌릴 수 있는 스크립트로 굳히고 싶을 때. 코드베이스 전역 버그 스윕, 500파일 마이그레이션, 출처 교차검증이 필요한 리서치, 커밋 전 여러 각도로 스트레스 테스트하고 싶은 계획 같은 게 딱임.

리서치 프리뷰 기능이라 동작·옵션이 바뀔 수 있음. 최신 내용은 공식 문서 확인: code.claude.com/docs/en/workflows

Mac에서 Antigravity Cli 권한 자동 주기 (feat. Gemini Cli 서비스 종료)

고생쨩 — Fri, 29 May 2026 10:22:08 +0900

~/.zshrc에 아래 내용추가

agy --dangerously-skip-permissions

[Claude Code] Agents View - 여러 에이전트를 관리하는 기능 추가

고생쨩 — Wed, 13 May 2026 09:27:59 +0900

Claude Code Agent View, 권한까지 한번에 풀고 쓰기

Anthropic이 2026년 5월 11일 공개한 Agent View는 Claude Code에서 여러 백그라운드 세션을 한 화면에서 관리하는 기능. 터미널 탭 여러 개 띄울 필요 없이 디스패치, 모니터링, attach를 한 곳에서 처리 가능. 여기에 권한 모드를 bypassPermissions로 설정해두면 매번 확인 프롬프트 없이 자율 실행까지 가능함.

이 글에서는 Agent View 사용법과, 이를 자율 모드로 굴리기 위한 설정 방법을 정리.

Agent View란?

여러 Claude Code 세션을 동시에 돌리고 한 화면에서 통합 관리하는 기능. 버그 수정, PR 리뷰, 테스트 조사 같은 독립적인 작업을 병렬로 디스패치하고, 입력이 필요한 세션만 골라 응답 가능.

요구사항

Claude Code v2.1.139 이상
Pro, Max, Team, Enterprise, Claude API 플랜 (Research Preview)
버전 확인: claude --version

핵심 개념

백그라운드 세션: 터미널 없이 supervisor 프로세스가 계속 돌림.
Peek 패널: 세션 attach 없이 미리보기 + 답장 가능.
Attach: 세션의 전체 대화로 진입. 빠져나와도 백그라운드 유지.
Worktree 격리: 여러 에이전트가 같은 파일 건드리지 않게 git worktree로 자동 분리.

기본 사용법

1. Agent View 열기

claude agents

하단 입력창 + 세션 목록 테이블이 뜸. Esc로 나가도 세션은 계속 살아있음.

2. 새 세션 디스패치

입력창에 프롬프트 작성 → Enter. 새 백그라운드 세션이 생성되고 행으로 추가됨. 반복하면 병렬로 여러 세션 가능.

특수 문법:

입력	효과
`<agent-name> <prompt>`	커스텀 subagent를 메인 에이전트로 실행
`@<agent-name>`	프롬프트 중간에서 subagent 멘션
`@<repo>`	특정 레포지토리에서 세션 실행
`/<skill>`	스킬 디스패치
`#<번호>` 또는 PR URL	해당 PR 작업 중인 세션 선택
`Shift+Enter`	디스패치 즉시 attach

3. Peek과 Reply

행 선택 후 Space → Peek 패널 오픈. 세션 상태, 최근 출력, 열린 PR 확인 가능. 패널에서 바로 답장 작성 후 Enter. 객관식 질문이면 숫자 키로 선택. Bash 명령 보내려면 ! 접두사.

4. Attach / Detach

Enter 또는 →: 세션에 attach. 전체 대화 진입.
빈 프롬프트에서 ←: detach. Agent View로 복귀.
세션 내부 종료: /stop.
detach 단축키들(←, Ctrl+C, Ctrl+D, Ctrl+Z, /exit): 모두 세션은 살아있음.

5. 셸에서 직접 백그라운드 시작

claude --bg "플레이키 테스트 조사해줘"
claude --agent code-reviewer --bg "PR 1234 리뷰 코멘트 처리"

세션 상태 아이콘

아이콘	상태	의미
애니메이션	Working	도구 실행 / 응답 생성 중
노란색	Needs input	입력 대기 (권한 결정, 답변 등)
흐림	Idle	입력 대기지만 특정 질문 막힘 없음
초록색	Completed	작업 성공 종료
빨간색	Failed	오류 종료
회색	Stopped	`Ctrl+X` 또는 `claude stop`으로 중단

주요 단축키

키	동작
`↑` / `↓`	행 이동
`Space`	Peek 패널 토글
`Enter`	Attach (또는 입력 있으면 dispatch)
`Shift+Enter`	Dispatch + 즉시 attach
`Alt+1`~`Alt+9`	N번째 세션 attach
`Ctrl+S`	그룹핑 전환 (상태별 ↔ 디렉터리별)
`Ctrl+T`	세션 핀 고정
`Ctrl+R`	세션 이름 변경
`Ctrl+X`	세션 중단 (2초 내 한번 더 → 삭제)
`?`	모든 단축키 보기

셸에서 세션 관리

claude agents             # Agent View 열기
claude attach <id>        # 세션 attach
claude logs <id>          # 최근 출력
claude stop <id>          # 세션 중단
claude respawn <id>       # 중단된 세션 재시작
claude respawn --all      # 전체 재시작
claude rm <id>            # 세션 제거

bypassPermissions 설정으로 자율 모드 만들기 (수정)

~/.zshrc에 아래 두줄로 설정하고 claude, claudea 로 용도에 따라 실행하는게 제일 편함.
적용은 터미널 재시작 필요함.

alias claude='claude --dangerously-skip-permissions'
alias claudea='claude agents --dangerously-skip-permissions'

Agent View + bypassPermissions 조합 워크플로

사전 준비: 프로젝트에 .claude/settings.local.json 생성, defaultMode: "bypassPermissions" 설정.
별칭 정리: 위험한 별칭 제거 후 셸 재로드.
Agent View 진입: claude agents.
병렬 디스패치: 독립 작업 여러 개 입력. 모두 권한 프롬프트 없이 자율 실행.
모니터링: 상태 아이콘 보며 완료/실패/입력 필요 세션 확인.
Peek & Reply: 입력 필요한 세션만 Space로 미리보기 후 응답.
결과 수확: 완료 세션의 PR 머지 또는 attach로 전체 대화 확인.

주의사항

사용량 폭주: 백그라운드 세션도 구독 사용량 동일 차감. 10개 병렬 = 10배 빠른 소진.
로컬 한계: 백그라운드 세션은 머신에서 돌고, 절전/종료 시 멈춤. 복구는 claude respawn --all.
자동 종료: 완료 후 1시간 미접속 시 supervisor가 프로세스 회수. attach 시 자동 재시작.
Worktree 정리: 세션 삭제 시 worktree도 같이 사라짐. 머지/푸시 먼저 할 것.
bypassPermissions 자체 위험: 격리된 컨테이너/VM이 아닌 환경에선 rm -rf 같은 실수도 그대로 실행됨. 가능하면 auto 또는 acceptEdits 사용 권장.
조직 정책: 관리자가 disableBypassPermissionsMode: "disable"로 막아둔 환경에선 설정도 플래그도 무효.

마무리

Agent View는 "여러 Claude를 동시에 부리는" 패러다임을 CLI에 가져옴. 여기에 권한 모드를 자율 모드로 박아두면 진짜 "디스패치하고 잊어버리기" 워크플로가 완성됨.

다만 자율성과 안전성은 trade-off. 회사 코드베이스라면 bypassPermissions보다 auto 또는 acceptEdits가 현실적인 선택. 진짜 격리된 실험 환경에서만 bypassPermissions 사용 권장.

공식 문서: https://code.claude.com/docs/en/agent-view

[PSVita] 무라마사 리버스(오보로 무라마사) 한글패치

고생쨩 — Sun, 10 May 2026 10:31:45 +0900

01234

최애겜중에 하나. 기다리면 스위치로 한글 종결판 내주겠지~하다 기다리다 지쳐서 직접 만듬.

따라서 배포도 정발 한글 나오기 전까지만 할 예정.

기쁘게도 26년 6월 9일 스팀 및 스위치로 정식 한글판 발매한다고 뜸. 따라서 정식 발매 후엔 배포 중단할 꺼니 그전에 받을 사람들만 받으셈.

claude랑 codex가 거진 다 했고 난 얘네가 잘 못하는 그래픽 텍스쳐 위주 작업을 했음.

추가로 구글에서 muramasa rebirth uhd 검색하면 텍스쳐팩 나오는데 선적용하고 적용하면 훨씬 더 좋음.

아직 부족한 부분이 많은데 의견은 깃헙으로 부탁드림.

꾸준한 업데이트로 이제 실기 지원도 됨.

문의/의견 - https://github.com/hada0127/muramasa-kor/issues
패치파일 다운로드 - https://github.com/hada0127/muramasa-kor/releases

빠른 시작

이미 Vita3K에서 무라마사 영문판이 정상 실행되는 상태라면 아래 순서만 따라하면 됨.

Python 3.9 이상 설치 (설치 시 "Add Python to PATH" 체크 필수)
Vita3K에 본편 v1.00 + 업데이트 v1.06 PKG 설치 (필수) + DLC 4개 (선택)
Releases에서 최신 패처 zip 다운로드 후 압축 해제
Vita3K 종료
Windows는 apply_windows.bat, macOS는 apply_macos.command 실행
Vita3K 설정에서 Configuration > Settings > GPU > Import Textures 체크
Vita3K 재시작 후 게임 실행

처음이라 전체 과정이 막막하면 아래 상세 설치 가이드부터 차근차근 읽어볼 것.

지원 환경

항목	내용
에뮬레이터	Vita3K (Windows / macOS / Android)
게임 타이틀 ID	`PCSE00240`
대상 게임	Muramasa Rebirth US판 (영문)
본편 버전	v1.00 + 업데이트 v1.06 (필수 조합)
배포 형식	Windows/macOS 공용 로컬 패처 zip + Android 수동 복사

실기(PS Vita 본체)는 지원 안 함. 실기 환경이 없어 검증 불가 + 실기 패치 방식이 까다로움.

릴리즈 zip에는 NinPri.cpk, NinPriPatch.cpk, 원본 PKG, DLC 데이터 미포함. 원본 게임 파일은 정품 소유자가 직접 준비.

원본 게임 준비

영문판 본편(v1.00) + 업데이트(v1.06) + DLC 4개를 모두 PKG로 설치 필요.

⚠️ 본편만 설치하고 업데이트를 적용하지 않으면 한글 패치 동작 안 함. 업데이트 v1.06 PKG 필수.

해시 검증 (선택)

원본 PKG가 정상 파일인지 확인하려면 SHA-256 해시 비교.

본편 (PCSE00240)

파일	버전	크기	SHA-256
`Muramasa Rebirth.pkg`	1.00	450 MB	`339cd06ec0f19bea3c9ce40fe47d4873b365d8ad6f78845f9819edeb0d5d9b71`
`update.pkg`	1.06	33 MB	`1396e08a04a28a41f64f10cc762546139df1eed29cce9ca87363696d13a9388b`
`work.bin`	-	512 B	`49e2550c82fe5a61e873682e84cd22b32229d0482150185abc25087b08b6ba48`

DLC - Genroku Legends (모두 v1.00, 추가 업데이트 없음)

DLC 에피소드	크기	PKG SHA-256	work.bin SHA-256
A Cause to Daikon For	69 MB	`62f46a334f79054a76b4b2644942c2a2ccb4a8271bb553f5208d60f77f922f84`	`9a6ebb5121110ad2f01ca0d0cf05e93b9b742a463746b8eb4c69ec57687b24f0`
A Spirited Seven Nights' Haunting	84 MB	`9c018a639cf631b6babbe2ba48e14a06bca866f752c53a86f9436e39a236a84c`	`9d39ed0c09e446cd852715f87160f0af6882a00504d7ae455089361a879b9d89`
Fishy Tales of the Nekomata	76 MB	`03e660dbf4fbeb848de1650bfe900db346fe711265e42f01a07042a421b657ba`	`9498bd7f4ed205564a46a7f3dbdb8484e156b06ee037030e1b6ab352b57f2439`
Hell's Where the Heart Is	83 MB	`2af2a4de7fd1b1e1233eee86e8a039ae834d015c9ca293e217a047e5292aaf82`	`1ede67a4e510b94682937ca49c1cd7400d0b553a7c5932eac6d3c2a2ef30baa3`

해시 계산 명령어

# Windows PowerShell
Get-FileHash -Algorithm SHA256 ".\Muramasa Rebirth.pkg"
Get-FileHash -Algorithm SHA256 ".\update.pkg"

# macOS / Linux
shasum -a 256 "Muramasa Rebirth.pkg"
shasum -a 256 update.pkg

상세 설치 가이드

0단계 — Python 설치

패처 실행에 Python 3.9 이상 필요.

Windows: python.org에서 설치 시 반드시 "Add Python to PATH" 체크박스 켜고 설치. 이걸 빼먹으면 apply_windows.bat을 더블클릭해도 아무 일도 안 일어남.
macOS: 터미널에서 python3 --version 입력 후 3.9 이상인지 확인. 없으면 python.org 또는 Homebrew로 설치.

설치 후 버전 확인:

# Windows
py -3 --version
# 또는
python --version

# macOS / Linux
python3 --version

1단계 — Vita3K에 원본 게임 설치

Vita3K 실행.
메뉴 File > Install .pkg 로 본편 Muramasa Rebirth.pkg (v1.00) 설치. (work.bin 또는 zRIF 필요)
같은 메뉴로 update.pkg (v1.06) 설치. (필수)
(선택) DLC PKG 4개(각 v1.00)를 같은 방법으로 설치.
Vita3K 앱 목록에 Muramasa Rebirth가 나타나고 정상 부팅되는지 확인.

설치 후 다음 경로에 원본 CPK 생성.

<Vita3K content root>/ux0/app/PCSE00240/NinPri.cpk
<Vita3K content root>/ux0/app/PCSE00240/NinPriPatch.cpk

기본 content root 위치

Windows: C:\Users\<username>\AppData\Roaming\Vita3K\Vita3K\fs
macOS:   ~/Library/Application Support/Vita3K/Vita3K/fs
Android: Android/data/org.vita3k.emulator/files

패처는 .../Vita3K/Vita3K와 .../Vita3K/Vita3K/fs 두 형식 모두 자동 처리. fs 폴더가 없는 경우도 정상이며 패처가 알아서 처리함.

2단계 — 한글 패치 zip 다운로드 및 검증

Releases 페이지에서 최신 zip 다운로드.
같은 릴리즈의 muramasa-kor-v버전-vita3k-patcher-sha256.txt로 zip 무결성 검증. (선택)

# Windows
Get-FileHash -Algorithm SHA256 .\muramasa-kor-v0.5.0-vita3k-patcher.zip

# macOS / Linux
shasum -a 256 muramasa-kor-v0.5.0-vita3k-patcher.zip
shasum -a 256 -c muramasa-kor-v0.5.0-vita3k-patcher-sha256.txt

3단계 — 로컬 패처 실행

⚠️ 패처 실행 전 반드시 Vita3K 종료.

Windows

apply_windows.bat 더블클릭

macOS

apply_macos.command 더블클릭

또는 터미널에서:

python3 apply_patch.py

경로 직접 지정

패처가 Vita3K 경로를 자동으로 찾지 못하면 --vita3k 옵션으로 직접 지정. ux0가 들어 있는 content root 또는 그 상위 Vita3K 루트 둘 다 가능.

# Windows
py -3 apply_patch.py --vita3k "C:\Users\<username>\AppData\Roaming\Vita3K\Vita3K\fs"

# macOS
python3 apply_patch.py --vita3k "$HOME/Library/Application Support/Vita3K/Vita3K/fs"

패처가 수행하는 작업

NinPri.cpk, NinPriPatch.cpk 원본 SHA-256 확인
원본 백업 생성: ux0/app/PCSE00240/.muramasa-kor-backup/
binary patch 적용 후 결과 SHA-256 재검증
textures/import/PCSE00240/ 아래로 Vita3K 텍스처 import 복사

4단계 — Vita3K 텍스처 import 활성화

폰트와 UI 한글 텍스처가 보이려면 텍스처 import 옵션 켜야 함.

Vita3K 실행
앱 목록에서 Muramasa Rebirth 우클릭 → 커스텀 설정 > 편집
Texture Replacement > Import Textures 체크
저장 후 Vita3K 재시작
게임 실행

글로벌 설정(Configuration > Settings > GPU)에서 켜도 되지만, 앱별 커스텀 설정에서 켜는 게 다른 게임에 영향 없어 권장.

Android Vita3K에 적용

Android에서는 패처를 직접 실행하지 않음. PC/macOS에서 패치를 먼저 완료한 뒤 결과 파일을 Android로 복사.

Android에 본편/업데이트/DLC PKG는 별도 설치 필요. 한글화 파일만 PC에서 복사해 옴.

사전 준비

PC/macOS에서 3단계까지 완료
Android Vita3K에 본편 + 업데이트 + DLC PKG 설치 완료
Android Vita3K 종료
Android 쪽 원본 CPK 백업 (만약을 위해)

복사할 파일

PC/macOS에서 가져올 파일

<PC/macOS content root>/ux0/app/PCSE00240/NinPri.cpk
<PC/macOS content root>/ux0/app/PCSE00240/NinPriPatch.cpk
<PC/macOS content root>/textures/import/PCSE00240/

Android에 덮어쓸 위치

<Android content root>/ux0/app/PCSE00240/NinPri.cpk
<Android content root>/ux0/app/PCSE00240/NinPriPatch.cpk
<Android content root>/textures/import/PCSE00240/

기본 Android content root는 보통 다음 위치.

Android/data/org.vita3k.emulator/files

따라서 기본 설치라면 최종 경로는 다음과 같음.

Android/data/org.vita3k.emulator/files/ux0/app/PCSE00240/NinPri.cpk
Android/data/org.vita3k.emulator/files/ux0/app/PCSE00240/NinPriPatch.cpk
Android/data/org.vita3k.emulator/files/textures/import/PCSE00240/*.png

원본 복원

같은 릴리즈 폴더에서 다음 명령을 실행한다.

python3 apply_patch.py --restore

Windows에서는 다음처럼 실행할 수 있다.

py -3 apply_patch.py --restore

복원에 사용하는 원본 백업 위치는 다음과 같다.

<Vita3K content root>/ux0/app/PCSE00240/.muramasa-kor-backup/NinPri.cpk.v<version>.original
<Vita3K content root>/ux0/app/PCSE00240/.muramasa-kor-backup/NinPriPatch.cpk.v<version>.original

패처는 현재 릴리즈 버전명과 다른 v*.original 백업도 원본 해시가 맞으면 복원한다. 복원이 되지 않거나 백업이 없다면, Vita3K에서 원본 PKG와 업데이트 PKG를 다시 설치하면 된다.

릴리즈 파일

릴리즈에는 보통 다음 파일이 포함된다.

muramasa-kor-v1.0.0-vita3k-patcher.zip
muramasa-kor-v1.0.0-vita3k-patcher-manifest.json
muramasa-kor-v1.0.0-vita3k-patcher-sha256.txt
muramasa-kor-v1.0.0-vita3k-patcher-release-notes.txt
muramasa-kor-vX-realhw-patcher-beta.zip — 실기(real PS Vita) 패치 (v1.2.3부터)

✕ 버튼 추가팩 (선택)

선택/확인 버튼을 ○ 대신 ✕로 보고 싶은 분을 위한 선택형 추가팩 muramasa-kor-xbutton-vX.zip이 함께 제공될 수 있다.
기본 패치는 ○를 그대로 쓰고, 이 팩을 추가로 덮어쓰면 버튼 표시가 ✕로 바뀐다.

게임이 버튼 모양을 직접 그리므로 이 팩은 화면 표시만 바꾼다. 실제로 ✕가 "확인"이 되게 하려면
Vita3K 설정에서 Enter Button Assignment = Cross 로도 바꿔야 한다.
설치: 기본 패치 적용 후 apply_xbutton.py(또는 apply_xbutton_windows.bat / apply_xbutton_macos.command) 실행.
되돌리기: python3 apply_xbutton.py --restore.

실기(real PS Vita) 패치 [베타]

에뮬레이터(Vita3K)가 아닌 실제 PS Vita 본체에서도 한글이 표시되도록 하는 패치다. v1.2.3부터
별도 zip muramasa-kor-vX-realhw-patcher-beta.zip 으로 제공한다.

Vita3K판과 무엇이 다른가

Vita3K판은 한글 텍스처/폰트를 hash 이름 PNG로 만들어 Vita3K의 텍스처 import 기능으로 덮어쓴다.
실기에는 그 기능이 없으므로, 한글 텍스처/폰트를 CPK 내부 FTX(게임 텍스처 컨테이너)에 직접
구워 넣는다. 실기는 업스케일(HD)이 불필요해 원본 해상도로 베이크한다. 저작권상 원본 CPK는
배포하지 않으므로, 사용자 본인의 원본 CPK로부터 패치 CPK를 생성한다(무거운 인코딩은 사용자 PC에서 수행).

참고 — 이 CPK는 Vita3K에서도 로드된다. 따라서 HD 텍스처 팩을 쓰지 않는 Vita3K 사용자는 이
실기용 CPK를 ux0/app/PCSE00240/에 넣으면 import 폴더로 PNG를 복사하는 절차 없이 한글이
표시된다. 다만 HD 팩 사용자는 import 방식(현행 Vita3K 패처)을 써야 한다. CPK에 한글을 베이크하면
해당 텍스처의 hash가 바뀌어 HD 팩(원본 hash 기준 import)이 그 텍스처엔 더 이상 적용되지 않아 한글
텍스처가 원본 해상도로 떨어지기 때문이다. 그래서 Vita3K 기본 배포는 HD 화질 지원을 위해 import
방식을 유지한다.

요구 사항

rePatch 플러그인 (실기에 설치·활성화). CPK 파일을 통째로 override 하는 방식이다.
Python 3.8+ 와 패키지: pip install pillow numpy xxhash
본편 + 1.06 업데이트 + (선택)DLC가 설치된 상태의 원본 CPK
(본편 NinPri.cpk/NinPriPatch.cpk, DLC NinPriPack1~4.cpk)

패치 생성·적용

# 1) 본인 원본 CPK로 패치 생성 (DLC 없으면 --pack* 생략)
python3 tools/apply_realhw_patch.py \
  --ninpri  /경로/NinPri.cpk  --ninpripatch /경로/NinPriPatch.cpk \
  --pack1 /경로/NinPriPack1.cpk --pack2 ... --pack3 ... --pack4 ... \
  --out ./out

# 2) 생성된 out/ux0/ 내용을 Vita의 ux0:/ 아래에 그대로 복사
#    ux0:/rePatch/PCSE00240/NinPri.cpk, NinPriPatch.cpk
#    ux0:/reAddcont/PCSE00240/OBOROMURAMASAPK1~4/NinPriPack1~4.cpk
# 3) rePatch 플러그인 활성화 후 게임 실행

○/✕ 버튼: 기본은 ○. ✕로 하려면 --enter-button cross (+ Vita 설정 Enter Button = Cross).
커버리지: 한글 텍스처 82종 전부 + 폰트 완성형 2350자를 CPK FTX에 매핑·베이크(누락 0).

베타 주의

실기 부팅·표시 검증은 아직 Vita3K 기준으로만 이뤄진 베타다. 실기 호환을 위해 CPK의 ETOC를
무력화했다(실기에서 동작하는 기존 rePatch 패치와 동일 방식). 실기에서 문제가 있으면 제보 바란다.

마무리

복사 완료 후 Android Vita3K 실행
Muramasa Rebirth 우클릭 → 커스텀 설정 → Import Textures 체크
게임 실행

⚠️ Android 빌드에서 텍스처 import가 동작하지 않으면 CPK 텍스트 패치는 적용되지만 한글 폰트/UI 텍스처가 정상 표시되지 않을 수 있음.

재패치 방법 (업데이트 적용)

새 버전이 나왔거나 패치를 다시 적용하고 싶을 때 사용. 패치된 CPK 위에 바로 덮어씌우면 원본 해시가 맞지 않아 패처가 중단되므로 아래 순서 준수.

1. Vita3K에 원본 게임이 설치된 상태인지 확인

본편 v1.00 + 업데이트 v1.06이 모두 설치되어 있어야 함.

2. 기존 한글 패치가 적용된 경우 — 원본 CPK 복원

같은 릴리즈 폴더에서 다음 명령으로 원본 CPK 먼저 복원.

# macOS / Linux
python3 apply_patch.py --restore

# Windows
py -3 apply_patch.py --restore

원본 백업은 ux0/app/PCSE00240/.muramasa-kor-backup/ 폴더에 저장됨. 예시 파일명:

NinPri.cpk.v0.7.4.original
NinPriPatch.cpk.v0.7.4.original

패처는 백업 파일명에 들어 있는 버전(v0.7.4)이 현재 패처 버전과 달라도, 원본 해시가 일치하면 복원.

3. 백업이 없을 때만 PKG 재설치

.muramasa-kor-backup/ 폴더가 없거나 비어 있으면 백업으로 복원 불가. 이 경우에만 Vita3K에서 본편 + 업데이트 PKG를 다시 설치한 뒤 다음 단계로 진행.

4. 새 버전 패처 압축 해제

muramasa-kor-v0.7.4-vita3k-patcher.zip (예시)을 원하는 위치에 압축 해제.

5. 패처 실행

Windows: apply_windows.bat 실행
macOS: apply_macos.command 실행
수동: python3 apply_patch.py

6. 패처가 자동으로 처리하는 작업

원본 CPK 해시 확인
원본 백업 생성
CPK 바이너리 패치 적용
Vita3K 텍스처 import 설치
- content root가 fs 폴더일 경우 fs/textures/import/PCSE00240/와 textures/import/PCSE00240/를 함께 갱신

7. Android는 PC에서 패치 완료 후 결과 파일 복사

위 Android Vita3K에 적용 섹션을 따라 다시 복사.

원본으로 되돌리기

한글 패치를 제거하고 원본 영문판으로 돌리려면 패처 폴더에서:

# macOS / Linux
python3 apply_patch.py --restore

# Windows
py -3 apply_patch.py --restore

복원이 안 되거나 백업이 없다면, Vita3K에서 본편 PKG와 업데이트 PKG를 다시 설치하면 됨.

FAQ — 자주 묻는 질문

Q1. `apply_windows.bat`을 더블클릭해도 아무 일도 일어나지 않음.

A. 거의 대부분 Python이 PATH에 등록되지 않아서임. Python 설치 화면에서 "Add Python to PATH" 체크박스를 켜고 다시 설치 필요. 이미 설치했다면 Python을 제거하고 재설치하는 게 가장 빠름.

설치 확인:

py -3 --version

버전이 안 나오면 Python이 제대로 안 깔린 것.

Q2. "Python 3.9 이상이 필요합니다" 오류 발생.

A. 시스템에 깔린 Python이 3.9 미만이거나, 여러 Python이 깔려 있어 구버전이 먼저 인식되는 경우. Python 3.9 이상(예: 3.14 등 최신 버전) 설치 후 PATH 재정리.

Q3. `fs` 폴더가 없음. 어떻게 해야 함?

A. 정상적인 경우임. Vita3K 버전에 따라 fs 폴더가 있을 수도, 없을 수도 있음. 패처는 두 경우 모두 자동 처리. 그래도 안 되면 fs 폴더를 직접 만든 뒤 패처를 다시 실행.

Q4. DLC가 인식되지 않음.

A. Vita3K(특히 안드로이드)에서는 NoNpDrm 롬으로 된 DLC를 인식하지 못하는 경우 있음. DLC는 반드시 PKG 파일로 추가 설치. 본편 설치 완료 후 DLC PKG 4개를 추가로 설치하면 됨. (DLC만 PKG로 설치하는 것은 별도 한글화 작업 불필요.)

Q5. 패치는 됐는데 한글이 깨져 보임 / 폰트가 이상함.

A. Vita3K 텍스처 import 옵션이 꺼져 있거나, textures 폴더 위치가 잘못된 경우.

우선 Muramasa Rebirth 우클릭 → 커스텀 설정 → Import Textures 체크 확인
textures/import/PCSE00240/ 폴더 안에 PNG 파일들이 들어 있는지 확인
Vita3K 실행 파일이 어디 설치되어 있는지 확인 — %appdata%/Vita3K/...가 아닌 다른 위치(Program Files 등)에 깔려 있으면 textures 폴더가 그쪽에 생겼을 수 있음. 해당 위치의 textures 폴더를 content root 위치로 이동.

Q6. Android에서 게임 실행 시 `eboot.bin`이 뜨면서 실행이 안 됨.

A. PC에서 패치가 적용된 파일을 그대로 안드로이드로 옮기지 않고 안드로이드에서 패치를 시도한 경우 발생 가능. 다음 순서 준수.

안드로이드 Vita3K에서 무라마사 게임/업데이트/DLC 삭제
안드로이드 기기에 본편 + 업데이트 + DLC PKG 모두 다시 설치
PC에서 한글 패치 적용 완료
PC의 ux0/app/PCSE00240/ 폴더의 NinPri.cpk, NinPriPatch.cpk와 textures/import/PCSE00240/ 폴더를 안드로이드의 동일 경로에 복사
Android Vita3K에서 텍스처 import 옵션 켜고 실행

Q7. PC에서는 한글로 나오는데 안드로이드에서는 영어/한글이 섞여 나옴.

A. 안드로이드에 본편/업데이트만 설치하고 한글 패치 파일은 복사 안 한 경우, 또는 textures/import/PCSE00240/ 폴더만 빠진 경우. PC에서 가져와야 할 파일은 총 3가지.

ux0/app/PCSE00240/NinPri.cpk
ux0/app/PCSE00240/NinPriPatch.cpk
textures/import/PCSE00240/ 폴더 전체

이 세 가지가 모두 안드로이드의 같은 위치에 복사되어 있어야 함.

Q8. 실기 PS Vita에서도 사용 가능?

A. 안타깝게도 실기 지원은 어려움. 텍스처 한글화 비중이 커서 실기의 패치 방식으로는 적용이 까다롭고, 실기 환경이 없어 검증도 불가능.

Q9. Vita3K 최신 버전(예: 12버전)에서 게임이 안 켜짐.

A. Vita3K 자체 버전 호환성 문제일 수 있음. 한 가지 버전 낮은(예: 11버전) Vita3K로 다운그레이드해서 시도해볼 것. 사용자들이 11버전에서는 잘 동작한다고 보고 중.

Q10. 패치를 다시 적용하려고 하니 "원본 해시 불일치" 오류 발생.

A. 이미 패치된 CPK 위에 다시 패치를 적용하려고 했기 때문. 위 재패치 방법 섹션을 따라 먼저 --restore로 원본을 복원하거나, 본편/업데이트 PKG를 재설치한 뒤 패처 실행.

Q11. 한글 패치 적용 후 게임을 영문으로 되돌리고 싶음.

A. 패처 폴더에서 python3 apply_patch.py --restore (Windows는 py -3 apply_patch.py --restore) 실행하면 백업으로 복원됨. 백업이 없으면 Vita3K에서 본편 PKG와 업데이트 PKG를 다시 설치.

Q12. 추가로 더 좋은 텍스처를 적용하고 싶음.

A. 구글에서 "muramasa rebirth uhd"로 검색하면 텍스처팩 나옴. 이걸 먼저 적용한 뒤 한글 패치를 적용하면 그래픽이 훨씬 더 좋아짐.

Q13. 버그나 오타 발견. 어디에 신고?

A. GitHub Issues에 등록 부탁.

릴리즈 파일

릴리즈에는 보통 다음 파일이 포함됨.

muramasa-kor-v0.5.0-vita3k-patcher.zip
muramasa-kor-v0.5.0-vita3k-patcher-manifest.json
muramasa-kor-v0.5.0-vita3k-patcher-sha256.txt
muramasa-kor-v0.5.0-vita3k-patcher-release-notes.txt

주의사항

이 패치는 Vita3K 전용.
실기용 PKG나 VPK 아님.
원본 pkg, cpk, DLC 데이터는 릴리즈에 미포함. 정품 소유자가 직접 준비.
패처는 US판 PCSE00240 본편 1.00 + 업데이트 1.06의 원본 CPK 해시와 일치할 때만 적용.
텍스처 import는 Vita3K의 해시 기반 교체 기능을 사용.

기여 및 개발

기여자용 빌드/배포/워크플로 문서는 CONTRIBUTING.md 참고.

바이브코딩 오케스트레이션(feat 슬랙 + 아사나MCP + 작은 크론봇)

고생쨩 — Fri, 8 May 2026 15:25:09 +0900

기존엔 텔레그램에 자작 Claude 원격 프로그램(cc-telegram, 봇 채팅으로 Claude 세션을 원격 제어하던 사이드 프로젝트)을 사용하다 체계적인 관리를 위해 Asana 기반으로 방법을 바꾸고 한 달 정도 지남.
텔레그램 방식은 작업 단위 추적, 스레드별 히스토리 검색, 동시 진행 중인 작업 시각화, 리뷰 단계 분리가 어려웠음. 칸반보드로 옮기니 이 네 가지가 한 번에 해결돼서 현재 사용 중인 방법을 공유함.

다른 칸반보드 앱도 MCP나 CLI, API 등으로 관리가 가능하면 비슷한 구성으로 옮길 수 있을 듯.

우리 팀 같은 경우 디자인/FE 쪽은 AI 최적화가 아직 힘들어서 사람 손으로 진행함. 클로드의 디자인 생성 기능, 구글 Stitch, pencil.dev 등 여러 툴을 테스트해봤는데, 시각 일관성·디자인 토큰 매핑·세부 마감 측면에서 자동화 파이프라인에 그대로 끼우긴 부족함. 방법을 아예 바꿔야 자동화가 가능해질 것 같아서, 아직은 시기상조인 듯.

전체 흐름 한눈에 보기

[Human] 기획 todo
   ↓ (담당자=AI 지정)
[AI]    기획 진행중
   ↓
[Human] 기획 리뷰  ←→ [AI] 수정 루프
   ↓
[Human] 디자인 todo → [Human] 디자인 진행중 → [Human] 디자인 리뷰
   ↓
[Human] 개발 todo
   ↓ (담당자=AI 지정)
[AI]    개발 진행중
   ↓
[Human] 개발 리뷰  ←→ [AI] 수정 루프
   ↓
완료 / 보류

핵심은 두 가지임.

AI 전용 Asana 계정을 담당자로 지정하면 크론봇이 그 티켓을 자동으로 픽업함. 담당자가 사람으로 돌아오는 순간 AI는 손을 뗌.
휴먼 리뷰 단계를 워크플로우 안에 명시적으로 박아둠. 자동화는 todo→진행중 구간만, 리뷰 게이트는 항상 사람이 닫음.

슬랙 설정

알림 용도가 전부라서 앱 만들고 필요한 권한 생성해서 토큰 받으면 끝.

섹션 이동, 리뷰어 호출, 배포 완료 같은 이벤트만 슬랙 채널로 푸시
모바일에서 즉시 확인용으로만 사용 (작성/수정은 항상 Asana에서)

Asana 설정

칸반보드를 기본으로 사용
AI 계정과 사람 계정 분리 — 권한 분리, 감사 로그 분리, 책임 추적 모두를 위해 가장 중요한 항목
사용자 지정 필드(Custom Field) 로 우선순위 필드 추가
사용자 지정 필드로 기획 리뷰어 / 디자인 리뷰어 / 개발 리뷰어를 사용자 타입 필드로 지정

참고: Asana의 사용자 지정 필드는 Starter 이상 유료 플랜 기능임. 무료(Personal) 플랜이면 태그(Tab+T)로 우선순위를, 설명란 상단 컨벤션이나 멘션으로 리뷰어를 대체할 수 있음. 또한 Personal 플랜은 협업 인원수 제한이 있어 AI 전용 좌석을 추가하면 한도에 먼저 닿을 수 있음 — 플랜 비용을 미리 확인할 것.

섹션 설정

총 11개 섹션으로 나눴음. 필요에 따라 줄여도 됨. 핵심은 휴먼 리뷰 게이트와 진행 중 작업의 자동 루프.

1) 기획 todo `[인간]`

사람이 설명을 최대한 자세히 작성
모든 내용 기입 후 담당자를 AI로 지정
크론봇이 내용 확인 후 보강 필요/사용자 결정 필요 항목을 댓글로 남기고 기획 리뷰어 멘션

2) 기획 진행중 `[AI]`

크론봇이 기획 todo 중 본인 담당으로 지정된 티켓을 읽어 자동으로 진행중으로 이동
리서치 — Claude·Codex·Gemini를 병렬로 호출해 각자 답을 받고 교차 검증
- 역할은 느슨하게 분담: Claude는 추론·초안, Codex는 구현 가능성·코드 영향도, Gemini는 외부 자료 리서치·대안 검토
- 세 결과 중 충돌이 있으면 댓글로 정리해 사람 판단을 요청
계획 수립 — Claude가 작성하고 Codex·Gemini가 리뷰
크론봇이 확정된 계획을 하위 태스크로 잘게 분해해 작성

3) 기획 리뷰 `[인간]`

AI 기획 완료 시 자동으로 이 섹션으로 이동 + 리뷰어 멘션
사람이 내용을 검토하고 수정 필요 시 댓글에 상세히 적은 뒤 다시 AI 호출
수정 완료 시 하위 태스크 생성자(=AI 계정)를 다시 멘션해 재작업 — 최종 합의까지 반복
최종 통과 시 리뷰어가 디자인 todo 또는 개발 todo로 카드 이동

4) 디자인 todo `[인간]`

사람 진행

5) 디자인 진행중 `[인간]`

사람 진행

6) 디자인 리뷰 `[인간]`

사람 진행
완료 시 개발 todo로 카드 이동

7) 개발 todo `[인간]`

기획 리뷰 또는 디자인 리뷰가 완료된 카드가 흘러옴
크론봇이 내용 확인 후 보강/결정 필요 사항을 댓글로 남기고 개발 리뷰어 멘션

8) 개발 진행중 `[AI]`

크론봇이 본인 담당 티켓을 자동 픽업
구현 — Claude Code가 메인, Codex/Gemini는 코드 리뷰 보조
작업 단위는 가능한 한 작게 — PR 단위로 분리해 하위 티켓 생성
테스트 코드 작성과 통과 확인까지 AI가 수행
진행 상황은 댓글로 자동 업데이트(커밋 해시, PR 링크 등)
테스트/빌드 실패 또는 PR 충돌이 일정 횟수 이상 반복되면 자동으로 보류 또는 사람 호출 (재시도 한도와 호출 조건은 별도 규칙으로 정해둠)

9) 개발 리뷰 `[인간]`

AI 개발 완료 시 자동으로 이 섹션으로 이동 + 리뷰어 멘션
사람이 코드를 검토하고 수정 필요 시 하위 태스크로 상세히 작성해 AI에게 배정
수정 완료 시 하위 태스크 생성자를 다시 멘션 — 최종 합의까지 반복
최종 통과 시 리뷰어가 카드를 완료로 이동

10) 완료 `[인간/Auto]`

모든 리뷰가 끝나고 배포까지 완료된 카드들이 모이는 섹션
주기적으로 아카이브해 보드 정리

11) 보류 `[Any]`

우선순위가 밀리거나 외부 의존성으로 진행이 막힌 카드
어느 단계에서든 이동 가능
보류 사유는 댓글에 명시
재개 시 원래 있던 섹션으로 되돌림

크론봇 설정

크론봇은 자체 개발한 백그라운드 스케줄러 프로그램임. Asana MCP를 직접 호출해 본인 담당 티켓을 폴링하고, 필요할 때 Claude/Codex/Gemini CLI를 spawn 하는 얇은 데몬.

티켓 관리 방식

빠른 응답을 위해 Claude Code를 거치지 않고 크론봇 자체가 Asana MCP에 직접 붙어 티켓을 관리(읽기/쓰기 도구 모두 사용)
Asana MCP 엔드포인트: https://mcp.asana.com/v2/mcp (Streamable HTTP, v2)
- 구버전 SSE 엔드포인트는 별개이며 종료 일정이 공지돼 있으니 v2를 사용할 것
- 게시 시점에 공식 문서로 한 번 더 확인 권장: https://developers.asana.com/docs/using-asanas-mcp-server
권한 분리를 위해 AI 전용 Asana 계정을 따로 발급받아 OAuth 연동
- 토큰은 OS 키체인 또는 암호화된 secret store에 보관
- AI 계정의 프로젝트 접근 범위를 최소한으로(필요한 보드만) 좁힘
크론봇 프롬프트에 "본인 담당으로 지정된 태스크만 읽는다"를 명시
태스크를 읽을 때 함께 가져오는 항목들:
- 제목, 설명, 하위 태스크 전체
- 댓글 스레드(리뷰어 피드백 반영용)
- 첨부 파일(기획서, 레퍼런스 등)
- 사용자 지정 필드(기획/디자인/개발 리뷰어 정보)
- 현재 섹션(어느 단계인지 파악)
한 번에 여러 티켓 처리 시 우선순위 필드 기준으로 정렬
해야 할 일 / 하고 있는 일 큐는 JSON으로 관리(동시 실행 방지)
- 키는 task_gid, 값은 {owner_pid, started_at, heartbeat_at}
- lockfile + 원자적 rename으로 write
- heartbeat이 일정 시간 끊긴 항목은 stale로 보고 재진입

크론 동작 방식

크론봇은 watchdog 모드로 상시 동작
티켓 확인 폴링 주기는 1분
- Asana API/MCP rate limit 이슈가 있으니 변경분 위주 조회 + 429 응답 시 Retry-After/exponential backoff 처리 권장
진행 중 티켓의 세션 활성 여부를 확인 — 죽었거나 미완료 종료라면 동일 티켓에 대해 재진입 루프 진행

프로젝트별 크론봇 설정

프로젝트 디렉터리에서 크론봇을 실행하고 Asana 프로젝트명을 입력
해당 프로젝트의 .cronbot/ 폴더에 설정이 저장됨

처음에는 크론봇 안에 실행 하네스(에이전트, 스킬 등등)까지 묶어 두었다가, 프로젝트별로 분리하는 게 낫다고 판단해 떼어냄. 성격이 다른 여러 프로젝트에 공용 하네스를 강제하면 결국 어딘가에서 깨짐. 유명한 오케스트레이션 툴들도 아직 이 부분을 깔끔하게 해결한 것은 못 봤음.

한 달 써본 장점

사람이 일하던 칸반 흐름을 그대로 유지하면서 전체 프로젝트가 굴러감 — 새 사람이 합류해도 보드만 보면 됨
작업 히스토리가 댓글·하위 태스크·필드 변경 로그로 체계적으로 남아 사후 분석이 쉬움
세션이 중단되거나 미완료 종료돼도 크론봇 watchdog이 다시 집어 듦 — 별도의 루프 보조 플러그인(예: 자체 ralph-loop류 무한 루프 도우미) 없이도 복구가 됨

한 달 써본 단점 / 한계

모바일 Asana 앱은 티켓 관리(특히 사용자 지정 필드 편집, 하위 태스크 정렬)가 다소 아쉬움 — 댓글 확인은 무난
기획 작성 시 그냥 한글로 코딩하는 느낌이 남
디자인/FE 단계는 여전히 사람 의존 — 전체 사이클의 병목이 이쪽으로 이동함
직접 코딩할때보다 확실히 AI 피로감이 더 많이 올라감

위 내용을 참고해 설정하면 좀 더 체계적인 오케스트레이션 관리가 가능함. 크론봇은 좀 더 다듬어서 따로 공유 드릴 예정.

[Claude Code] Codex 플러그인 ~리뷰머신~

고생쨩 — Tue, 21 Apr 2026 09:11:26 +0900

codex plugin 설치(클로드 코드에서 실행)

마켓 설치

/plugin marketplace add openai/codex-plugin-cc

플러그인 설치
```
/plugin install codex@openai-codex
```
플러그인 리로드
```
/reload-plugins
```
codex 설정 확인
```
/codex:setup
```

자동 리뷰 설정

/codex:setup --enable-review-gate

수동 리뷰

기본
```
/codex:review
```
적극적인 문제 찾기
```
/codex:adversarial-review
```

제법 리뷰를 잘해준다. 자동 리뷰 설정하고 쓰는게 좋은듯

[Codex] Mac에서 권한 허가 없이 실행

고생쨩 — Tue, 21 Apr 2026 08:49:39 +0900

.zshrc에 아래줄 추가

alias codex='codex --dangerously-bypass-approvals-and-sandbox'

Claude Cowork Dispatch — 폰으로 집 컴퓨터에 일 시키는 기능

고생쨩 — Tue, 14 Apr 2026 08:35:21 +0900

2026년 3월 17일 Anthropic이 리서치 프리뷰로 출시한 Claude Cowork의 신기능.
Pro/Max 구독자 대상, macOS·Windows 지원.

Dispatch가 뭔지 한 줄 요약

폰에서 지시 → 집 컴퓨터의 Claude가 실행 → 돌아와서 결과 확인

AI한테 할 일 맡겨두고 자리를 비울 수 있는 기능임. 지하철에서 보고서 요청 → 사무실 도착하면 완성돼 있는 구조.

Cowork가 뭔지 먼저

Dispatch는 Cowork의 하위 기능임. Cowork 없이는 Dispatch 사용 불가.

Cowork는 Claude Desktop에 내장된 에이전트 모드임.
기존 Claude가 "질문 → 답변 1회"였다면, Cowork는 멀티스텝 목표를 계획하고 직접 실행하는 구조.

	일반 Claude	Cowork
작업 방식	프롬프트 → 응답 1회	목표 → 계획 → 자율 실행
파일 접근	불가	로컬 파일 + 앱 + 클라우드 커넥터
세션 유지	창 닫으면 끝	앱 열린 동안 지속
원격 접근	불가	Dispatch로 가능

어떻게 작동하는가

핵심 구조

[폰 - Claude 모바일 앱]
        ↓ 작업 지시
[데스크탑 - Claude Cowork]
        ↓ 로컬 파일·커넥터·플러그인 접근
        ↓ 실행
[결과 → 같은 대화 스레드에 표시]

폰은 리모컨, 데스크탑이 실제 실행 주체임.
클라우드에서 돌아가는 게 아니라 내 컴퓨터에서 직접 처리하는 구조.

하나의 지속 스레드

폰과 데스크탑이 단일 대화 스레드를 공유함.
폰에서 보낸 메시지, 데스크탑에서 받은 결과 — 전부 같은 대화창.
현재는 스레드가 1개로 고정. 여러 스레드 관리 기능은 미지원.

설정 방법

설정 자체는 간단함.

Claude Desktop 최신 버전 업데이트 (claude.com/download)
Claude 모바일 앱 최신 버전 업데이트 (iOS/Android)
두 앱 같은 계정으로 로그인
Desktop에서 Cowork 열기 → 사이드바 Dispatch 클릭
파일 접근 권한 허용
QR코드 생성 → 모바일 앱으로 스캔
페어링 완료 — 이후 폰에서 바로 메시지 전송 가능

QR 스캔 한 번으로 끝나는 구조.

할 수 있는 작업들

Cowork에 설정된 커넥터·플러그인·파일 접근 권한을 Dispatch에서 그대로 활용함.

문서·데이터

로컬 스프레드시트 데이터 분석 → 요약 보고서 생성
특정 폴더 파일 분류·정리·이름 변경
Google Drive 파일 기반 프레젠테이션 생성
CSV 정리, 데이터셋 병합, 차트 생성

커넥터 연동

Slack 메시지 검색 → 브리핑 문서 초안 작성
Gmail·Outlook 이메일 요약 → 오늘 할 일 목록 생성
Google Calendar 일정 확인 후 회의 자료 준비

개발 (Dispatch + Claude Code 세션)

프로젝트 뼈대 생성, 버그 수정, 테스트 실행
폰에서 지시 → 데스크탑에서 코드 작업 수행

현재 지원 커넥터 (38개 이상)

카테고리	커넥터
구글	Gmail, Google Drive, Google Calendar
마이크로소프트	Outlook, OneDrive
협업	Slack, Notion, Linear
개발	GitHub
기타	DocuSign 등

현실적인 한계

리서치 프리뷰답게 아직 제약이 있음.

필수 조건

데스크탑이 켜져 있고 Claude 앱이 열려 있어야 함
Mac 덮개 닫거나 절전 모드 → Dispatch 중단됨
Windows에서 설정 오류 보고 다수 → 현재 macOS가 안정적

현재 미지원

작업 완료 푸시 알림 없음 — 직접 대화창 열어서 확인해야 함
단일 스레드 — 여러 독립 스레드 동시 관리 불가
세션 간 메모리 미지원 — Global Instructions에 수동 저장 필요
Claude가 먼저 연락하지 않음 — 지시한 작업만 수행

성공률
MacStories 실전 테스트 기준 약 50% 정도. 단순 조회·요약은 잘 되고, 복잡한 다단계 작업은 아직 불안정.

"자리를 비웠을 때 의존하기엔 충분하지 않다. 하지만 가능성은 있다."
— MacStories 핸즈온 리뷰 요약

구독 요건

플랜	가격	Dispatch
Max	$100~$200/월	즉시 사용 가능
Pro	$20/월	순차 확장 중
Free	무료	미지원

보안 주의사항

폰 명령이 데스크탑 파일·앱에 접근하는 구조 특성상 주의 필요.

광범위한 삭제 지시 금지 — "정리해줘" 같은 명령은 범위 구체화 필수
민감 폴더 제외 — 금융·규제 관련 파일은 접근 범위에서 빼기
외부 문서 분석 주의 — 신뢰할 수 없는 출처의 파일은 프롬프트 인젝션 위험
첫 사용 시 중요하지 않은 파일로 테스트 권장

2026년 1월 한 크리에이터가 Cowork에 "파일 논리적으로 정리해줘" 요청 → 11GB 삭제된 사례 있음.

Dispatch vs OpenClaw

업계에서 자주 비교되는 OpenClaw와의 차이.

	OpenClaw	Dispatch
소스	오픈소스	클로즈드
모델	Claude·GPT·로컬 선택 가능	Anthropic 모델만
설정 난이도	중간 (기술적 설정)	낮음 (QR 스캔 1회)
가격	API 비용 별도	Pro/Max 구독 포함
프라이버시	자가 호스팅 가능	Anthropic 클라우드 경유

OpenClaw → 다양한 메신저, 모델 선택, 오픈소스 원하는 개발자
Dispatch → Claude 구독 중이고 설정 없이 바로 쓰고 싶은 일반 사용자

실전 활용 팁

팁	내용
경로 구체화	"파일 찾아줘" 말고 `/projects/Q1/budget.xlsx` 처럼 지정
결과 중심 지시	단계별 지시 대신 "X를 Y 형식으로 이 폴더에 저장해줘"
Mac 절전 방지	System Settings → Energy → 하드디스크 절전 끄기
커넥터 미리 설정	원격으로 새 커넥터 설정 시도 X → 데스크에서 먼저 완료
복잡한 체이닝 피하기	단일 요약은 잘 됨, "요약 → Notion → 팀 공유" 같은 연속 작업은 아직 불안정
실행 전 확인 강제	"계획 먼저 보여주고 확인 받은 다음 실행해"라고 프롬프트에 포함

한 줄 정리

폰이 리모컨, 데스크탑이 실행 주체.
리서치 프리뷰라 성공률 50% 수준이지만, 단순 조회·요약·파일 처리는 충분히 실용적.
Max 플랜이면 바로, Pro면 며칠 내 사용 가능.
기대치를 리서치 프리뷰에 맞추고 쓰면 꽤 쓸만한 실험임.