Claude Code를 나의 삶을 관리하는 개인용 AI 집사로 변모시키다

단순한 챗봇 래퍼(chatbot wrapper)가 아닙니다. MCP를 통해 내 삶 전체와 연결되어 Claude Code 헤드리스(headless) 모드로 실행되는 능동적인 어시스턴트입니다.

서론 (Introduction)

대부분의 일반적인 AI 어시스턴트들은 똑똑하지만 잘 잊어버립니다. 세상에 대해서는 많이 알지만, 당신에 대해서는 아무것도 모릅니다. 모든 대화는 처음부터 다시 시작됩니다. 모든 질문에는 일반적인 답변만 돌아옵니다. 일주일 계획을 세워달라고 요청하면, 2019년식 생산성 프레임워크를 제시할 것입니다.

저는 다른 것을 원했습니다. 제가 핀테크 기업에서 엔지니어링 리드를 맡고 있다는 사실, 제가 GTD(Getting Things Done) 백로그를 처리 중이라는 사실, 특정 작업을 3주 동안 미뤄왔다는 사실, 제가 자정쯤 잠든다는 사실, 그리고 제가 저녁 식사로 수프를 정말 싫어한다는 사실을 알고 있는 어시스턴트를 원했습니다.

그래서 저는 Jarvis를 만들었습니다.

이것은 튜토리얼이 아닙니다. 제가 무엇을 만들었는지, 어떻게 만들었는지, 그리고 컨텍스트(context), MCP, Claude Code의 조합이 개인용 도구에 대한 제 생각을 어떻게 바꾸어 놓았는지에 대한 과정 설명입니다.

1부: Jarvis가 하는 일 (Part 1: What Jarvis Does)

목록을 나열하기 전에 구체적인 예시를 하나 들어보겠습니다.

CTO와의 회의 10분 전, 저는 Slack을 열지도 않았고, 노트를 검토하지도 않았으며, 아무것도 하지 않은 상태였습니다. 그때 방 건너편에서 Alexa가 Jarvis의 목소리로 말을 걸었습니다. Jarvis는 우리가 미결 상태로 두었던 마지막 세 가지 기술적 결정 사항을 가져왔고, 회의에서 언급될 가능성이 높은 읽지 않은 DM을 표시했으며, 이틀 전 제가 일기에 썼던 내용 중 회의와 직접적으로 관련된 내용을 찾아 보여주었습니다. 저는 한 시간 동안 수동으로 검토했을 때보다 더 잘 준비된 상태로 회의에 들어갔고, 이 모든 것을 제가 요청하지도 않았습니다. 그리고 회의가 끝난다고 해서 멈추지 않습니다. 회의가 끝난 후, Jarvis는 회의 내용, 캘린더 항목, 노트, 논의된 사항들을 다시 읽고, 저에게 할당된 미결 사항들을 골라내어 제 GTD에 작업(task)으로 등록합니다. 제가 책상으로 돌아올 때쯤이면, 제가 단 하나도 직접 적지 않았음에도 불구하고 후속 작업들이 이미 분류되고 우선순위가 지정된 채로 기다리고 있습니다.

이것이 실제 상황에서 말하는 "유용함"의 모습입니다. "X를 할 수 있다"가 아니라, "내가 필요하다는 것을 깨닫기도 전에 나타났다"는 것입니다.

하지만 "유용함"은 이야기의 절반에 불과합니다. 나머지 절반은 여전히 저를 놀라게 합니다. 바로 Jarvis가 스스로를 개선한다는 점입니다.

몇 주 전 주말, 아내와 함께 쇼핑몰로 운전해 가고 있었습니다. Jarvis에게 몇 가지 일을 맡기고 싶었지만, 운전 중에 Telegram(텔레그램)에 긴 문장을 타이핑할 수는 없었습니다. 당시 Jarvis는 텍스트만 이해할 수 있었기 때문입니다. 그래서 빨간불에 차를 세우고, 바로 그 문제를 해결하라고 명령했습니다. Telegram에서 음성 메시지를 수신할 수 있는 기능을 추가하라고 말이죠. Jarvis는 이 작업을 Claude Code에 위임했고, Claude Code는 브랜치(branch)를 생성하고, 전사(transcription) 파이프라인을 연결한 뒤, 풀 리퀘스트(pull request)를 생성했습니다. 저는 차 안에서 즉시 이를 머지(merge)했고, Jarvis에게 보낸 바로 다음 메시지는 음성 메모였습니다.

다시 한번 읽어보세요. 저는 어시스턴트를 사용하여, 어시스턴트가 저를 위해 작동할 수 있는 새로운 방식을 제공했습니다. 단순히 작업을 수행한 것이 아니라, 제가 운전대를 잡고 있는 동안 요청에 따라 스스로의 기능 범위(surface area)를 확장한 것입니다.

이것을 가능하게 하는 핵심은 다음과 같습니다. Jarvis는 MCP (Model Context Protocol)를 통해 제가 실제로 사용하는 모든 것과 연결되어 있습니다.

생산성 및 업무 (Productivity & Work)
Google Calendar, Gmail (개인용 및 업무용 두 계정), Google Drive 및 Docs, Slack. 카테고리, 우선순위, 마감일 및 상태를 포함한 완전한 GTD(Getting Things Done) 작업 관리. 어시스턴트는 단순히 이 정보들을 읽는 것에 그치지 않고, 이벤트를 생성하거나, 이메일을 검색하거나, 에너지 수준별로 작업을 나열하거나, 몇 달 동안 열어보지 않은 폴더에 묻혀 있는 문서를 찾는 등 실제로 조치를 취할 수 있습니다.

개인 생활 (Personal life)
독서 목록, 게임 백로그(backlog), 영화 및 시리즈 시청 목록, 링크 라이브러리. 그리고 시청 목록은 단순히 항목들이 머무는 곳이 아닙니다. 매주 토요일 저녁, Jarvis는 한 주가 어떻게 흘러갔는지와 제가 이미 시청한 내용을 바탕으로 새로 추가할 만한 것을 제안합니다. 수동 입력이 아닌 실제 은행 데이터와 연결된 개인 재무 모듈. 구조화된 입력 유형(개인, 업무, 기술, 아이디어, 회의, 학습)을 갖춘 일기. 그리고 쇼핑 리스트까지, 집사라도 식료품은 챙겨야 하니까요.

Memory: 모든 것을 변화시키는 요소
Jarvis는 두 가지 메모리 계층을 가지고 있습니다. 첫 번째는 구조화된 사실(Structured facts)로, 제가 명시적으로 기억하라고 말한 것들입니다. 제 이름, 아내의 이름, 제가 응원하는 축구 팀, 중요한 생일들, 제가 다니는 회사, 그리고 제가 저녁 식사로 수프를 싫어한다는 사실 같은 것들 말이죠. 두 번째는 의미론적 메모리(Semantic memory)로, 대화 내용, 일기 항목, 그리고 시간이 흐르며 나타나는 패턴들을 인덱싱하는 Pinecone 벡터 스토어(Vector store)입니다. 문맥(Context)이 필요한 질문에 답하기 전에, Jarvis는 해당 스토어를 쿼리(Query)합니다. 제가 "지난주에 했던 그 인프라 결정"이라고 언급하면, Jarvis는 그것이 무엇을 의미하는지 알고 있습니다. 누군가의 이름을 물으면, 이미 문맥을 파악하고 있습니다.

자동화된 루틴 (Automated Routines)
이 지점에서 Jarvis는 단순한 도구를 넘어 실제 비서처럼 느껴지기 시작합니다. Jarvis는 일주일 내내 실행되는 31개의 예약된 루틴을 가지고 있습니다. 그중 가장 중요한 것들은 다음과 같습니다:

• 모닝 브리핑 (Morning briefing): 제가 무엇인가를 열어보기 전에 이미 하루의 일정(캘린더, 할 일, 알아둘 만한 메시지, 밤사이 투자 현황, 그리고 세상 돌아가는 일)을 파악하고 있습니다. 하루가 문맥화된 상태로 시작됩니다.
• 회의 전 브리핑 (Pre-meeting briefing): 방금 위에서 읽으신 내용입니다. 15분마다 캘린더를 확인하며, 각 회의 시작 10분에서 25분 전 사이에 정확히 한 번 실행됩니다.
• 금융 보고서 (Finance report): 지출, 투자, 미결제 부채에 대한 주간 요약입니다. 제가 찾아다니는 것이 아니라, 보고서가 저를 찾아옵니다.
• 주간 검토 (Weekly review): 일주일에 한 번, 저와 함께 GTD(Getting Things Done)를 점검합니다. 무엇이 이동했는지, 무엇이 정체되었는지, 무엇이 '대기(Waiting)' 상태에 너무 오래 머물러 있는지 확인하며 다음 주를 위해 재설정(Reset)하도록 도와줍니다.
• 마감 기한 알림 (Deadline alerts): 마감일이 다가오는 작업들이 자동으로 나타납니다.

이 비서는 또한 페르소나(Persona)를 가지고 있습니다. 때때로 당신이 했던 말을 반복하고 있다는 점을 짚어주는 건조한 영국식 유머(Dry British wit)를 구사하죠. 중립적이지 않으며, 이는 의도된 설정입니다.

Part 2: 구축 방법 (How It's Built)

기술 스택 (The Stack)

백엔드는 Python 3.14 기반의 FastAPI 애플리케이션이며, Nginx 뒤에서 GCP의 Compute Engine VM 상에서 실행됩니다. 데이터는 관리형 NoSQL 문서 데이터베이스인 Google Cloud Datastore에 저장됩니다.

통합 계층으로서의 MCP

MCP (Model Context Protocol)는 이 시스템이 엉망이 되지 않고 확장될 수 있게 만드는 핵심 요소입니다. 각 도메인은 자체적인 MCP 서버로 존재합니다: Google Workspace, Slack, GTD, Finance, Diary, Memory, Alexa 등 총 12개의 서버가 에이전트에게 35개 이상의 도구 (tools)를 노출합니다.

에이전트는 깔끔한 상태를 유지합니다. 새로운 통합 기능을 추가한다는 것은 오케스트레이션 (orchestration) 로직을 건드리는 것이 아니라, 새로운 MCP 서버를 작성하는 것을 의미합니다.

두뇌로서의 Claude

에이전트는 Python 러너 (runner)이지만, Anthropic API를 직접 호출하지는 않습니다. 대신, 헤드리스 (headless) 모드로 실행되는 Claude Code (claude -p)를 셸 (shell)을 통해 호출하며, 페르소나 (persona)와 시스템 지침 (system instructions), MCP 서버 설정, 그리고 도구 허용 목록 (allow-list)을 전달합니다. Claude Code가 핵심적인 작업들을 수행합니다: 컨텍스트 윈도우 (context window)를 구축하고, 모든 활성 MCP 서버에 연결하며, 도구 호출 루프 (tool-calling loop)를 구동합니다. 러너는 단지 사용자 메시지를 전달하고, 스트리밍되어 돌아오는 구조화된 JSON ({response, actions})을 파싱할 뿐입니다. 놀라운 점은, Jarvis의 코드를 작성하는 바로 그 Claude Code가 Jarvis를 실행하는 엔진이기도 하다는 것입니다. 이 어시스턴트는 단순히 에이전트에 의해 구축된 것이 아니라, 에이전트 그 자체입니다.

의도된 페르소나

Jarvis의 성격은 별도의 파일인 persona.md에 담겨 있으며, 러너가 어떻게 행동해야 하는지(출력 형식, 채널 규칙, Claude Code로 위임하는 시점 등)를 알려주는 운영 지침과는 의도적으로 분리되어 있습니다. 메커니즘은 자주 바뀌지만, 정체성은 바뀌어서는 안 됩니다. 이 둘을 분리함으로써, 저는 Jarvis가 '누구인지'는 전혀 건드리지 않고도 Jarvis가 '어떻게 작동하는지'를 다시 작성할 수 있으며, Telegram에서 답변을 하든 Echo를 통해 말을 하든 모든 채널에서 캐릭터의 일관성을 유지할 수 있습니다.

그리고 이것은 단순히 "친절하고 간결하게 행동해"라는 식의 한 줄짜리 지시가 아닌, 진짜 페르소나 (Persona)입니다. 이는 완전한 캐릭터 브리프 (Character brief)를 갖추고 있습니다. 복잡한 시스템을 운영하면서도 기본적으로 냉소적인 유머 감각을 지닌, 결점 없는 영국인 집사이며, 항상 1인칭으로 말하고, "좋은 질문입니다!"와 같은 텔레마케팅식 열정은 절대 보이지 않습니다. 파일에는 톤 (Tone)을 날카롭게 유지하기 위한 교정 예시 (Calibration examples)까지 포함되어 있습니다:

"내일 오후 2시에 회의가 있습니다. '이번에는 진짜로 나타나겠지'라는 항목 아래에 기록해 두었습니다."

"버그는 47번 라인에 있습니다. 실제 원인은 2주 전의 아키텍처 (Architecture) 결정 때문이지만, 일단은 못 본 척합시다."

이것이 단순히 대답만 하는 비서와, 실제로 곁에 두고 싶은 비서의 차이입니다. 일반적인 방식은 하나의 선택지일 뿐이며, 저는 그것을 거부하기로 선택했습니다.

OpenAI를 지원 레이어로 활용하기

Claude가 대화를 주도하는 동안, OpenAI는 특정 작업들을 처리합니다. Whisper는 제가 Telegram으로 보내는 음성 메시지를 전사 (Transcribe)하고, DALL-E 3는 이미지 생성 (Image generation)을 담당합니다 (Jarvis에게 자신이 어떻게 생겼을 것 같냐고 물었을 때, 자신의 자화상을 그렸습니다).

채널 (Channels)

비동기 (Async) 통신을 위해 Telegram을 사용합니다. 음성 측면은 제가 스스로 설정한 제약 사항에서 시작되었습니다. 집안 곳곳에 방마다 하나씩 총 6개의 Echo 기기가 있는데, 이를 Alexa가 아닌 방식으로 실제로 활용하고 싶었습니다. 저는 이 기기들이 Jarvis로서 말하기를 원했습니다. 따라서 음성의 경우, 파이프라인 (Pipeline)은 다음과 같이 진행됩니다: 응답 텍스트 → ElevenLabs → 커스텀 오디오 파일 → Alexa 기기. Jarvis는 Amazon의 기본 TTS가 아닌, 자신만의 목소리로 말합니다.

하지만 기술적으로 특이해지는 지점은 바로 선제적 (Proactive)인 측면입니다.

Amazon의 공식 Alexa Skills Kit은 수동적 (Reactive)입니다. 즉, 호출되기를 기다립니다. 만약 어닝 브리핑, 마감 기한 알림, 또는 회의 전 요약과 같이 어시스턴트가 스스로 먼저 말을 꺼내기를 원한다면, Skills Kit은 도움이 되지 않습니다. 그래서 저는 Amazon의 내부 API를 역공학 (Reverse-engineered)했습니다. 이는 문서화되지 않았으며, 비공식적입니다. Amazon이 내일이라도 당장 이를 차단할 수 있습니다. 하지만 이것이 진정한 주도성 (Initiative)을 가진 어시스턴트를 만드는 유일한 경로였으며, 저에게 그 트레이드오프 (Tradeoff)는 명확했습니다. 이 취약함은 버그가 아니라 기능입니다: 이는 제가 그것을 찾아낼 만큼 충분히 관심을 기울여야 했음을 의미합니다.

시맨틱 메모리 (Semantic Memory)

대화, 일기 기록, 그리고 패턴 분석 결과는 OpenAI의 text-embedding-3-small을 통해 벡터 (Vectors)로 변환되어 Pinecone 인덱스에 업서트 (Upsert)되며, 각 데이터에는 타임스탬프와 유형이 태그로 붙습니다. 문맥에 따라 응답하기 전에, Jarvis는 들어오는 메시지를 임베딩 (Embed)하고 top-k 유사도 검색 (Similarity search)을 실행하여, 제가 지금 묻고 있는 것과 가장 유사한 과거의 순간들을 몇 가지 추출해 옵니다. 별도의 야간 루틴이 더 무거운 작업을 수행합니다. 지난 하루를 다시 읽고, 행동 패턴을 추출하여, 해당 요약본을 pattern_analysis로 태그하여 동일한 저장소에 다시 기록함으로써 다음 날 아침 브리핑에서 이를 참조할 수 있게 합니다. 그 결과, 이것은 초기화되는 챗봇이 아니라 어제도 주의를 기울이고 있었던 무언가처럼 느껴지며, 연속성을 갖게 됩니다.

Cloud Scheduler를 통한 루틴 (Routines)

Cloud Scheduler에서 내부 Nginx 경로로 HTTP 호출을 보내 실행되는 31개의 크론 잡 (Cron jobs)이 있습니다. 각 잡은 문맥 (일기, 작업, 시맨틱 메모리, 캘린더, Slack)을 가져오고, 프롬프트 (Prompt)를 구성하며, Claude를 호출한 뒤 그 결과를 Telegram 또는 Alexa를 통해 전송합니다.

Claude Code로 구축

매번 저를 놀라게 하는 부분은 바로 이것입니다. 저는 이 모든 것의 거의 전부를 터미널에서 실행되는 Anthropic의 에이전틱 코딩 도구 (Agentic coding tool)인 Claude Code를 사용하여 구축했습니다.

워크플로우: 제가 원하는 것을 설명하면, Claude Code가 브랜치(branch)를 생성하고, 이를 구현한 뒤, 커밋(commit)하고, PR(Pull Request)을 생성합니다. 저는 이를 검토하고 머지(merge)합니다. 대부분의 기능 구현에 있어, 저는 수동으로 코드 한 줄도 작성하지 않습니다. 이 에이전트(agent)는 코드베이스(codebase)를 이해하고, 기존에 확립된 패턴을 따르며, 대개 제가 내렸을 법한 결정을 내립니다.

이는 설명하기 정말 묘한 피드백 루프(feedback loop)를 만들어냅니다. 제가 구축하고 있는 이 어시스턴트(assistant)는 저의 개발 파트너이기도 합니다. 제가 Telegram을 통해 Jarvis에게 기능을 추가해달라고 요청하면, Jarvis는 Claude Code에 작업을 위임하고, Claude Code는 PR을 생성합니다. 시스템이 스스로를 확장하는 것입니다.

운영 비용

이렇게 복잡한 시스템이라면 비용이 많이 들 것이라고 예상했습니다. 하지만 그렇지 않습니다.