매일 기록한 AI 기록

📚 AI 직원 회사 빌드기 — 4부작 시리즈 ① Mac Studio 128GB로 AI 직원 회사 만든 이유 (현재 글) ② 외부 부작용 통제 — Discord 승인 + launchd ③ claude -p 6-step 체이닝 — V3.5 + Phase 2 트랩 ④ 30시간 회고 — 토큰·막힌 5번·다음 6주 KPI Mac Studio를 켜놓고 자도 되는가 Mac Studio 128GB를 켜놓고 자도 되는가. 구입 후 며칠이 지나서야 이 질문이 처음 떠올랐다. 전기요금이 걱정된 게 아니었다. 이 기계가 실제로 뭔가를 만들어내고 있는가 — 라는 질문이었다. 개발자라면 이런 상황을 한 번쯤 겪었을 것이다. 서버를 켜두고 ssh만 가끔 접속하는 걸 "활용 중"이라 부르는 상황 로컬 LLM 148GB를 다운받아 놓고 실제 추론 시간이 전체의 5%도 안 되는 상태 에이전트 파이프라인 세팅을 다 해놓고 "이게 수익이 되는가"라는 질문을 계속 뒤로 미루는 것 이 글은 그 질문에 정면으로 답하는 과정에서 내가 실제로 만든 것, RAM 수치를 어떻게 계산했는지, 그리고 팔 타이밍을 어떤 기준으로 미리 설계했는지를 기록한다. 결론부터 말하면 — 아직 "회사"가 아니고, 처분 시나리오는 이미 설계해뒀다. 로컬 LLM이 이유가 아니다 구입 이유를 물어보면 "로컬 LLM 돌리려고"가 가장 쉬운 답처럼 보인다. 그런데 그게 이유라면 128GB는 정당화하기 어렵다. 로컬 LLM이 실제로 필요한 조건은 대체로 세 가지다. 프라이버시 : 개인 민감 문서를 대량 처리해야 할 때 API 볼륨 : 월 $100+ 이상의 클라우드 API 비용이 발생할 때 오프라인 운용 : 인터넷 없는 환경에서 LLM이 필요할 때 나는 이 세 가지 중 하나도 해당하지 않는다. 그렇다면 로컬 LLM 서버로서의 Mac Studio 128GB는 정당화되지 않는다. ...

cron에서 스킬을 돌렸더니 Phase 2에서 멈췄다 claude -p 를 cron에 넣고 blog-draft 스킬을 자동화했다. 첫 실행 로그를 열었더니 스킬이 프레임 후보 3개를 출력한 뒤 프로세스가 종료돼 있었다. 응답을 기다리는 주체는 아무도 없었다. 이게 Phase 2 승인 트랩 이다. 이 글은 트랩의 원인을 분해하고, 자동화 파이프라인에서 인터랙티브 스킬을 끝까지 실행시키는 우회법 3가지를 다룬다. cron·CI 환경에서 claude -p 로 스킬을 돌리고 있다면 바로 적용 가능한 내용이다. 같은 상황을 겪어봤다면 CI 잡이나 cron에서 claude -p 로 스킬을 호출했는데 절반만 실행되고 종료된 것을 본 적 있다. exit code는 0이라 성공처럼 보이지만 결과물은 없다. stdout 마지막 줄이 "진행 시 Phase 3 시작"이라는 텍스트였는데, 그걸 읽고 Enter를 칠 사람은 없었다. 스크립트는 정상 종료됐고 아무 일도 일어나지 않았다. 이게 반복되면 자동화 자체를 의심하게 된다. 문제는 claude -p가 아니라 스킬 설계의 가정에 있다. 원리와 증상: 단일 턴 vs 멀티턴 가정의 충돌 claude -p 는 비대화형 모드다. 프롬프트 하나를 받아 응답 하나를 돌려주고 종료한다. 대화 루프가 없다. 두 번째 입력을 기다리는 구조가 아니다. 반면 대부분의 인터랙티브 스킬은 멀티턴 가정으로 설계돼 있다. 전형적인 3-Phase 패턴을 보면: Phase 1 — 재료 수집, 분석 결과 출력 Phase 2 — 방향 제안, 사용자 승인 대기 ← 여기가 트랩 Phase 3 — 승인 후 본문 실행 Phase 2는 설계상 응답을 기다리는 체크포인트다. 대화형 환경에서는 "1번으로"라고 답하면 Phase 3가 시작된다. claude -p 환경에서는 Phase 2 출력 직후 Claude가 종료한다. 다음 턴이 오지 않기 때문이다. 스킬이 버그가 있는 게 아니다...