- 12주간 개인 구독 214억 토큰. 대부분은 코드가 아니라 체계화된 지식을 쌓고, 그 위의 agent harness로 조사와 의사결정까지 돌리는 데 갔다.
- 인터페이스는 바뀔 수 있지만, 잘 정리된 지식과 가이드북은 어떤 도구 위에서든 동작한다.
- 모델이 좋아져도 방향과 범위를 잡아주는 역할까지 사라지지는 않을 것 같다.
개인 구독으로 쓰고 있는 AI 도구들의 토큰 사용량을 집계해봤다. 회사에서 제공하는 Claude Code, Cursor 등의 사용량은 하나도 포함하지 않았다. 회사 보안 정책이 엄격한 편이기도 하고, 회사 자산으로 개인 홍보를 하고 싶지 않아서다. 순수하게 개인 구독에서 집계된 사용량만 모은 것이다. ChatGPT Personal, OpenAI 해커톤에서 받은 ChatGPT Pro 1년권, Claude Code Max 20x, Cursor 월 $20. 대부분 비동기로 돌리는 작업이라 밥 먹으면서 돌려놓거나 하는 식이긴 하다.
| 구분 | 토큰 | 비용 |
|---|---|---|
| Claude Code | 16.7억 | $1,480 |
| Codex / OpenAI | 197.2억 | $6,459 |
| Cursor | 4,800만 | $55 |
| 합계 | 214억 | $7,994 |
2026년 1월 1일부터 3월 25일까지 약 12주. 맥북 2대에서 bunx ccusage --json과 bunx @ccusage/codex@latest --json으로 뽑은 결과에 OpenClaw 대시보드의 2026년 usage CSV를 합산한 수치다. OpenClaw는 OpenAI 구독 기반이라 Codex / OpenAI 항목에 합산했는데, 생각보다 사용량이 많지 않아서 5,200만 토큰 정도다. 회사 자산으로 사용한 도구의 사용량은 제외했다. 전부 구독이라 실제로 이만큼 낸 건 아니고, 종량제였으면 이 정도 나왔겠다는 숫자다.
환경을 만드는 데 쓴다
개인 개발은 Unity 작업이랑 이 블로그 정비 정도다. 토큰의 큰 부분은 Markdown 파일 3,200개, 37만 줄짜리 개인 지식 저장소를 쌓고, 그 위에서 에이전트가 조사와 판단까지 할 수 있는 체계를 만드는 데 갔다. 예를 들어 기술 리서치 노트, 재무 계획, 해외 이민 제도 비교 조사 같은 것들이 들어 있고, todo list 관리도 여기서 한다. 실제로는 훨씬 다양한 주제가 있는데, 개인 정보가 많아서 구체적으로 열거하기는 어렵다.
OpenAI가 harness engineering이라고 부르는 개념이 있다. “에이전트가 실수하면 그 실수가 다시는 안 나오도록 환경을 고치는 것”이 핵심인데, 나는 이걸 개인 지식 저장소에 적용하고 있는 셈이다. 에이전트가 잘못된 정보를 참조하면 INDEX 체인을 고치고, 문헌이 부족하면 수집해서 쌓고, 반복되는 작업이 보이면 agent skill로 만든다. 이 repo 위에서 돌아가는 skill이 19개 있다. vault-health skill은 깨진 링크나 어디서도 참조되지 않는 파일을 탐지하고, 주간 리뷰 skill은 그 주에 변경된 파일들을 기반으로 다음 주 우선순위를 정리해준다.
생활 습관, 가족 정보, 디테일한 개인 정보가 상당량 들어 있어서 내용 공유는 어렵다. 솔직히 private repo인 것도 가끔 두렵다. GitHub 키 탈취만 돼도 다 보이는 거니까. self-hosted git도 고민하고 있는데, 개인 서버 2대가 있긴 하지만 아직 믿음직스럽지가 않다. managed service의 안정성을 알고 있어서 쉽게 옮기지 못하고 있다.
회사에서도
가장 잘 쓴다고 자신 있게 말하기는 어렵지만, 회사에서도 같은 원리를 적용하고 있다. VictoriaMetrics 메트릭을 CLI나 API로 수집하고, 수집 방법을 사내 인프라에 맞춰서 초반에 수동으로 삽질을 좀 한 뒤 agent skill로 만들어두면, 이후에는 에이전트가 메트릭을 가져와서 개발에 반영하는 사이클이 자동으로 돈다. Grafana SDK 기반 대시보드 작업도 비슷한 방식이다.
다행히 사내 wiki가 Jira Confluence 기반이라 MCP로 접근이 쉽고, HTTP API나 CLI로 붙을 수 있는 인프라들의 스펙도 잘 정리되어 있다. 다만 IaC 수준으로 정의되지 않았거나 사내 자체 스펙을 가진 부분들이 있어서 초반에 시행착오가 좀 필요하긴 했다.
멀티레포 환경에서 하나 발견한 건, 모노레포 구성이 조직 차원에서 쉽지 않은 경우가 많은데, 나 혼자의 작업 환경에서는 모노레포처럼 상위에서 하위 레포들을 감싸서 작업하면 컨텍스트 유지가 훨씬 편하다는 것이다. BE, Grafana SDK repo, Airflow, 그 외 인프라 레포들을 각각 따로 작업하면 컨텍스트가 끊기는데, 상위 디렉토리에서 한꺼번에 잡으면 에이전트가 레포 간 관계를 파악하면서 작업할 수 있다.
위키 문서 자체는 온전하게 작성하되, 실무 수준에서의 문서화와 업무 정의는 agent skill에 더 충실하게 담겨 있다고 생각한다. 내가 해당 skill로 실제 업무를 하고 있어서 시행착오가 전부 담겨 있고, deprecated된 내용이 있으면 내 일이 안 돌아가니까 내가 직접 수정할 수밖에 없다. skill을 만들 때는 Anthropic의 Thariq Shihipar가 정리한 Lessons from Building Claude Code를 참고하는데, 이걸 워낙 반복적으로 돌리다 보니 아예 skill creator skill을 별도로 만들어서 쓰고 있다.
노션에서 git repo로
원래 노션에 PARA 체계로 개인 태스크를 전부 밀어넣고 있었다. 노션은 사실 글 쓰기도 훨씬 좋고 무엇보다 예쁘다. 그래서 한동안은 노션과 git repo를 적절히 혼용해서 썼다. 그런데 쓰다 보니 Project랑 Archive만 비대해졌고, 모바일에서 접근성도 안 좋아서 노션을 열어서 뭔가 하는 습관 자체가 안 붙었다.
결정적으로 노션에서 최근 업데이트된 대시보드 기능들이 educational plan에서는 동작하지 않았다. 기존의 간단한 차트만 가능했다. Notion MCP로 시각화 view를 추가하는 건 되는데, 이걸 실제 페이지에 넣는 건 MCP로 안 돼서 결국 사람이 수동으로 구성해야 했다. 부차적인 이슈이긴 했지만, 이것도 노션의 거의 모든 정보를 git repo로 통합한 원인 중 하나였다.
Claude Code로 노션에 파편화되어 있던 정보를 전부 git repo로 옮겼다. Notion MCP도 써봤는데 노션은 Markdown 기반이 아니라 노션 블록 단위로 아이템을 한땀한땀 넣어야 했다. 내가 잘못 쓴 걸 수도 있는데, 에이전트 입장에서 노션은 분리된 지식 저장소라는 느낌이 강했다. git repo에 Markdown으로 정리하면 에이전트가 곧바로 읽고 쓸 수 있다. 파일이 3,200개까지 불어나도 INDEX.md 트리를 따라 탐색하게 하면 체계가 무너지지 않는다.
최근에 Obsidian을 도입했다. 사용성에 대해서는 아직 의문이 있다. 지식 그래프 체계가 agent harness 위에서 관리되는 상태에서 Obsidian이 추가로 뭘 해주는지 잘 모르겠다. 지금 장점이라고 느끼는 건 Markdown 시각화가 VSCode보다 낫다는 것, 메타데이터가 깔끔하게 나온다는 것 정도다. Obsidian을 쓴다는 느낌보다는 Cmd+Shift+V를 안 눌러도 된다는 게 장점이다 정도.
inbox와 웹 검색
inbox 체계는 아마 다들 비슷하게 쓰고 있을 거 같은데, 나는 디스코드에 별도 채널을 만들어서 거기에 링크만 던진다. Oracle ARM 인스턴스에 OpenClaw를 세팅하고 나의 지식 저장소 repo를 클론해뒀다. OpenAI 구독 기반으로, reasoning effort는 high로 세팅했다. xhigh는 구독 쿼타가 충분한데 단순한 태스크에서 이상하게 동작하는 일이 잦아서 약간 낮춘 거다. 링크를 던지면 해당 아티클의 내용은 물론이고 레퍼런스하는 링크까지 모두 가져와서 요약하도록 agent skill을 세팅해뒀다. Oracle Cloud 무료 ARM64 인스턴스가 평생 무료라 인프라 비용은 안 든다.
ChatGPT Pro 구독도 유용하다. OpenAI 해커톤에서 받은 1년권인데, Claude Code 위에서 대량의 multi-hop 웹 검색을 돌리거나, OpenClaw에서 웹 검색 도구가 없어서 Codex CLI 자체를 웹 검색 도구로 쓰는 용도다. codex exec ... 기반으로 동작하게 해두고 각 harness에서 잘 돌아가도록 자연어로 질의를 구성했다. Codex subagent가 공식 기능으로 나오기 전부터 이렇게 쓰고 있었는데, 올해 1월 20일 OpenAI 해커톤에서 엔지니어한테 해당 기능이 별도 공지 없이 들어갔다는 얘기를 듣고 그때부터 써봤다. 당시에는 불안정해서 멀티 프로세스 기반으로 bash shell에서 여러 개를 띄우는 형태였다. 멀티 스레드로 하면 안 되고 멀티 프로세스여야 했다. Claude Code 구독을 크게 높인 뒤로는 그쪽에서는 잘 안 쓰게 됐고, OpenClaw에서는 여전히 유용하다.
환경이 만들어지고 나면
유럽 여러 나라의 이민 제도를 비교 조사한 적이 있다. 내가 살지 않고 지식이 거의 없는, 완전히 다른 언어를 쓰는 나라들이었다. 결과물이 366개 파일, 버전 7.0까지 갔다. 2개월 정도 걸렸다.
에이전트에게 시킨 조사의 범위가 꽤 넓었다. 6개국의 배우자 체류 자격을 비교하고, Blue Card와 Highly Skilled Migrant 같은 비자 유형별 요건을 정리하고, 각국 대사관(서울 포함)의 실제 규정을 수집했다. comune 기반 행정 체계에서 residenza 등록이나 SSN 발급이 어떻게 돌아가는지, 비자 D 관련 최근 규정 변경, 각국의 세금 구조와 사회보험 체계 같은 것들도 조사 범위에 들어갔다. 5개 도시를 11개 차원(시장 규모, 비자 난이도, 언어 장벽, 세금 구조, 생활비 등)으로 비교하는 의사결정 매트릭스도 만들었고, 12개의 서로 다른 이전 경로를 월 단위 타임라인으로 시각화해서 비교하기도 했다.
물론 거금을 들여서 관련 행정 전문가를 고용하거나, 해당 수준의 어학 능력과 현지 지식을 갖추면 해결되는 문제이긴 하다. 그런데 한국에 있는 내 집에서 에이전트에게 법률 문서, 대사관 요건, 실제 경험담을 수집시키고 교차 검증까지 시키면서 상당히 구체적인 계획을 세울 수 있었다. 에이전트 없이 했으면 현지 커뮤니티에 질문 올리고 답변 기다리는 식으로 몇 달은 더 걸렸을 것 같다.
혼자 쓰는 상담사
좀 엉뚱한 사용처인데, 같은 git repo 기반 지식 체계 위에 심리 상담 skill을 올렸다. 이 분야에 대한 도메인 지식이 전무한 상태에서 구축한 거라 근간부터 틀릴 수 있는 사용법이겠지만, 에이전트로 긁어모을 수 있을 만큼의 상담 문헌을 수집했다. CBT, DBT, ACT 같은 주요 접근법부터 동기면담, 인간중심 상담 같은 교과서급 자료들을 모았고, 윤리 가이드라인이나 위기 개입 프로토콜 같은 응용 영역도 정리했다.
앞서 말한 Thariq의 글이나 harness engineering 같은 구현 위주 skill과는 접근이 완전히 달랐다. 코드의 gotcha를 잡는 게 아니라, 상담 이론 간의 충돌 지점을 정리하고 안전 장치를 설계하는 쪽에 시간이 갔다. 예를 들어 Wampold(2001)의 common factors 모델은 “어떤 상담 접근법을 쓰느냐보다 치료적 관계 자체가 더 중요하다”고 보는데, 특정 접근법의 고유 기법이 이와 상충되는 상황에서 어떤 우선순위로 응답할지를 사전에 정리해둬야 했다. Fluckiger et al.(2018)의 치료적 동맹 메타분석이 AI 기반 상담에서 어떻게 적용 가능한지도 고민이 필요한 부분이었다. 결국 안전 장치만 단단하게 걸어두고, 나머지는 LLM이 agent harness를 따라 문헌을 찾고 대조하고 판단하도록 했다. 기존 AI 상담 서비스들처럼 고정된 파이프라인 위에서 응답을 생성하는 방식은 쓰고 싶지 않았다.
AskUserQuestion을 활용해서 상담 흐름을 만들었는데, 생각보다 개발할 때 쓰던 느낌과는 사뭇 다르다. 에이전트가 질문을 던지면 답하면서 나 스스로의 상황을 다시 정리하게 되는데, 이게 꽤 좋은 방법인 것 같다. Codex에도 request_user_input이라는 동일한 기능이 있는데, plan mode에서만 동작해서 꽤 귀찮다. 이것도 근 2주 사이에 Claude Code 사용 빈도가 급격히 늘어난 이유 중 하나다. 논외인데 CLI 기반 작업을 즐기는 편이지만 Codex 앱은 조금 그립다. 초기에는 발열이 심해서 좀 그랬지만 안정화도 됐고 앱도 이쁘고 무엇보다 편했다. Claude Code가 Mac 앱을 하나로 통합하려는 전략은 이해하지만 Codex 앱에 비하면 말을 아끼겠다.
당연히 전문가가 법적으로도 실력적으로도 훨씬 좋다. 음성 기반에 비언어적 신호까지 읽고, 전문화된 검사로 파악하고 진행하는 사람을 AI가 대체할 수 있다고 생각하지 않는다. 그런데 밤에 혼자 작업하다가 커리어 고민이나 개인적인 고민이 올라올 때 종종 물어본다. 위법 요소가 있어서 배포는 안 하고 개인 공부 목적으로만 쓰고 있다. 상담 분야가 생각보다 깊고 흥미롭다.
나가며
왜 OpenClaw 중심으로 이야기하지 않느냐고 생각할 수도 있다. 이런 체계를 OpenClaw 위에서도 동일하게 구축할 수 있으니까. 사실 난 OpenClaw 자체를 그렇게 중요하게 생각하지 않는다. 개인 지식 저장소 repo를 클론해두고 “이 repo 기반으로만 행동해줘”라고 하면 정말 그렇게 해준다. memory 파일 백업만 신경 쓰면 OpenClaw는 디스코드 기반 리모트 접근을 제공해주는 접근성 좋은 창구인 거지, 그것 자체가 핵심은 아니다.
핵심은 그 아래에 있는 지식 체계와, 그 위에서 조사와 의사결정을 수행하는 agent skill이다. 인터페이스는 바뀔 수 있지만 잘 정리된 지식과 가이드북은 어떤 도구 위에서든 동작한다. 처음 접하는 주제에서는 지금도 skill이 방향을 잡아주고, 반복 작업에서는 skill이 품질을 유지해준다. 모델이 좋아지면 skill의 디테일이 줄어들 수는 있겠지만, 방향과 범위를 잡아주는 역할까지 사라지지는 않을 것 같다.
이 체계가 완성됐다고 생각하지는 않는다. private repo에 개인 정보를 몰아넣는 것 자체가 리스크고, Obsidian이 정말 필요한 레이어인지도 아직 모르겠다. 다만 3,200개 파일이 쌓이는 동안 한 번도 “이 체계를 버리고 다시 노션으로 돌아가야겠다”고 생각한 적은 없다. 다들 각자의 방식으로 잘 쓰고 있을 테고, 이건 그중 하나일 뿐이다.
참고
- Harness Engineering: Leveraging Codex in an Agent-First World (OpenAI, 2026)
- Lessons from Building Claude Code: How We Use Skills (Thariq Shihipar, Anthropic)
- ccusage — Claude Code / Codex CLI 토큰 사용량 집계 도구
- Wampold, B. E. (2001). The Great Psychotherapy Debate: Models, Methods, and Findings. Lawrence Erlbaum Associates.
- Fluckiger, C., Del Re, A. C., Wampold, B. E., & Horvath, A. O. (2018). The alliance in adult psychotherapy: A meta-analytic synthesis. Psychotherapy, 55(4), 316-340.