ClaudeCode

매일 아침 유투브로 전일 미국 시장 정보를 습득하는 편인데 영상을 처음부터 보려면 너무 많은 시간이 소비된다. 그리고 이러한 영상들은 대부분 스크립트를 제공하지 않는다. 그래서 스크립트를 제공하지 않는 영상의 스크립트를 추출해서 AI를 활용해 요약본을 만들 수 있게 만드는 개인용 파이프라인을 설계했다. 아직 구상 단계지만, 각 단계를 어떤 도구로 어떻게 연결할지는 구체적으로 정리해뒀다. 1단계: 오디오 추출 — AI 없이 로컬에서 가능 가장 먼저 필요한 건 영상에서 오디오만 뽑아내는 작업이다. 이건 AI가 필요 없는 단순 작업이라 로컬에서 처리한다.

Claude Code로 작업하다 보면 세션 하나가 몇 주씩 이어지는 경우가 생긴다. 아이맥 로컬 LLM 실험, 루팅폰 서버 관리, 사이드 프로젝트 기획까지 — 한 대화창 안에 여러 프로젝트가 뒤섞여 쌓이다 보니, 어느 순간 “이 대화가 너무 무거워졌다"는 느낌이 들었다. 특히 이 세션은 특정 컴퓨터(아이맥)에 대한 파일 접근 권한까지 물고 있어서, 더더욱 새 세션으로 넘어가고 싶어졌다. 문제는 그동안 나눈 대화에 흩어져 있는 결정사항, 삽질 기록, 설정값들을 그냥 버리기는 아깝다는 점이었다. 세션을 닫기 전에 정리부터 그래서 새 세션으로 넘어가기 전에, 지금까지의 대화 내용을 주제별로 정리한 문서를 먼저 만들어두는 방법을 썼다. Claude Docs(Claude가 만드는 살아있는 문서) 기능을 이용해서, 세션 안에서 다룬 프로젝트 하나당 탭 하나씩으로 나눠 정리했다.

지금까지 나는 유휴 휴대폰 두 대를 각각 다른 용도의 서버로 굴리고 있었다. 갤럭시 퀀텀2는 Cloudflare Tunnel로 노출된 FastAPI 기반 업비트 시세 서버, 갤럭시 S9는 루팅해서 만든 IRIS 카카오톡 봇 서버. 이번에 이 두 서버의 기능을 S9 하나로 합쳤다. 왜 합쳤나 두 폰을 따로 유지보수하는 비용이 생각보다 컸다. 각 폰마다 Termux 환경, proot-Ubuntu, Claude Code 원격 세션을 따로 관리해야 했고, 장애가 나면 어느 폰의 어느 서비스인지부터 확인해야 했다. 서버 자체의 부하는 두 서비스를 합쳐도 충분히 감당할 수준이라 판단해서, 한 대로 통합하는 쪽을 택했다.

로컬 LLM으로 코딩을 시켜보겠다고 마음먹었을 때, 실은 두 가지 서로 다른 활용 방식을 놓고 고민했다. 방식 A: Aider 자율 코딩 터미널에서 Aider를 실행하고, 프롬프트 하나로 파일 생성·수정·테스트·커밋까지 로컬 모델이 알아서 처리하게 하는 방식이다. yes-always 옵션으로 확인 프롬프트까지 다 꺼두면, 사람은 결과만 나중에 확인하면 된다. 지금까지 이 블로그 시리즈에서 다룬 벤치마크 테스트가 전부 이 방식이었다. 방식 B: MCP를 통한 위임 Claude Code 세션 안에서 작업을 하다가, 특정 하위 작업만 로컬 모델에 “던지고” 결과를 받아오는 방식이다. Claude Code가 메인 오케스트레이터 역할을 하고, 로컬 LLM은 도구(tool) 중 하나로 취급된다. 이걸 위해 mcp-local-llm MCP 서버를 소스에서 직접 빌드해 붙였다(이 과정은 앞선 글에서 다뤘다).

로컬 LLM 파이프라인 작업을 마무리하면서 뜻밖의 부산물을 하나 발견했다. 작업 중이던 대화창 상단에 계속 “Simon’s iMac · 연결됨"이라는 표시가 떠 있었던 것이다. 처음엔 대수롭지 않게 넘겼는데, 자세히 보니 이 대화에만 뜨고 다른 대화에는 안 뜨는 걸 알아챘다. 왜 이 대화에만 떴을까 원인은 명확했다. 이 세션 초반, 아이맥에 Ollama/Aider를 설치하려고 ~/Projects 폴더에 접근 권한을 요청했고, 그 요청을 승인했던 것이다. 그 승인 자체가 “이 대화(작업)와 이 컴퓨터를 연결” 시키는 액션이었다. 즉 이건 계정 전체에 걸리는 설정이 아니라, 대화(세션) 단위로 부여되는 권한이다. 다른 대화에서는 이런 폴더 접근 요청을 한 적이 없으니 연결 표시도 뜨지 않는 것이다.

앞선 글들에서 인텔 아이맥에 로컬 코딩 LLM 파이프라인을 설치하고, 4개 모델을 실측 비교했다. 결론부터 말하면 이 프로젝트는 여기서 접기로 했다. 그 판단에 이르기까지의 근거를 정리한다. 결정타는 “재현성 부족"이었다 가장 빠르고 안정적이었던 DeepSeek-Coder-V2-16B를, 완전히 동일한 프롬프트로 한 번 더 돌려봤다. 결과는 이랬다. 1차 2차 소요 시간 9분 30초 22분 55초 (2.4배) 커밋 feat + lint fix 시도 feat 1개뿐 함수 개수 요청한 4개 요청에 없던 4개(거듭제곱·나머지·제곱근·팩토리얼) 임의 추가 flake8 잔여 오류 일부 16건 같은 입력, 같은 모델인데 소요 시간이 2.4배 차이 나고, 심지어 요청하지 않은 기능을 마음대로 추가했다. 이건 “느리다"가 아니라 “결과물을 매번 처음부터 검토해야 한다"는 뜻이다. 무인 파이프라인의 핵심 전제 — 사람이 개입하지 않아도 일정 수준의 결과가 보장된다는 것 — 이 자체가 깨진 셈이다.

로컬 LLM 파이프라인에는 두 가지 활용 방식이 있다고 생각했다. 하나는 Aider가 터미널에서 로컬 모델로 자율 작업을 하는 방식, 다른 하나는 Claude Code 세션 안에서 필요할 때만 로컬 모델에 작업을 위임하는 MCP(Model Context Protocol) 서버 방식이다. 이 둘은 서로 배타적이지 않고 병행할 수 있어서, 일단 MCP 쪽도 붙여보기로 했다. CONNECTION_CLOSED claude mcp add local-llm -- npx -y mcp-local-llm 등록은 됐는데, claude mcp list로 확인하면 상태가 이렇다. local-llm: npx -y mcp-local-llm - ✘ Failed to connect — CONNECTION_CLOSED 에러 메시지만으로는 원인을 알 수 없었다. npx가 내부적으로 어떤 명령을 실행하는지 직접 눈으로 확인해야 했다.

지금까지 다룬 코인 추천, 시황 브리핑 같은 루틴들은 전부 휴대폰 안에서 직접 크론(cron)으로 도는 게 아니라, Claude Code의 예약 루틴(Cloud Trigger) 기능을 통해 클라우드에서 독립적으로 실행됩니다. 이번 글은 그 구조가 로컬 크론과 어떻게 다른지, 어떤 장단점이 있었는지 정리합니다. 로컬 크론이 아니라 완전히 격리된 클라우드 세션 이 방식의 가장 큰 특징은 실행 주체가 이 휴대폰이 아니라는 점입니다. 정해진 cron 표현식(예: 매일 06:55 UTC 기준 변환)에 맞춰 클라우드에서 새로운 세션이 열리고, 그 세션이 지정된 저장소(GitHub repo)의 지침 문서를 읽어 작업을 수행합니다. 휴대폰이 꺼져 있거나 네트워크가 끊겨 있어도 예약된 실행 자체는 영향을 받지 않습니다.