AI한테 내 프롬프트 14,390개를 주고 물어봤다 — 내가 너를 어떻게 쓰고 있냐고

시작

호기심이 생겨서 내가 지난 두 달 동안 Claude Code와 Codex에게 던진 프롬프트를 전부 긁어모아 분석해봤다. ~/.claude/projects/에는 22개 프로젝트, 234개 세션, 6,232개 프롬프트가 쌓여 있었고, ~/.codex/에는 15개 프로젝트, 204개 세션, 8,158개 프롬프트가 있었다.

처음에는 그냥 "내가 토큰을 얼마나 썼나" 정도가 궁금했다. 그런데 데이터를 펼쳐 놓고 보니 토큰 얘기보다 더 흥미로운 게 보였다. 나는 AI 한 대를 잘 쓰는 사람이 아니라, AI 두 대를 역할로 나눠 굴리는 사람이었다.

미리 밝혀두면 — 이 분석과 보고서는 내가 직접 쓴 게 아니라 AI가 써줬다. 내가 한 일은 "내 ~/.claude/와 ~/.codex/ 데이터 전부 읽고 내 사용 스타일을 분석해줘"라고 던진 것뿐이다. 즉 이 글은 내가 AI를 어떻게 쓰는지를 AI에게 분석시킨 결과다. 그래서 더 재미있었다 — AI가 나를 거울처럼 비춰준 셈이니까.

이 글은 그 분석 결과를 정리한 회고다.

---

한 줄 요약

AI를 잘 쓰는 사람이 아니라, AI 팀을 굴리는 매니저.

처음에는 AI 한 대를 어떻게든 잘 써보려고 했다. 그런데 어느 순간부터 두 대를 역할로 나눠 쓰고 있었다. Claude Code는 같이 사고하는 PM/Architect, Codex는 손발 빠른 Senior Engineer. 의도하고 그렇게 한 게 아닌데, 데이터로 보니 그렇게 굳어져 있었다.

---

토큰 효율이 극단적으로 높은 사람

가장 먼저 눈에 띈 건 토큰 사용 패턴이었다. 한 줄로 요약하면 이거다.

직접 타자는 평균의 1/3로 치고, 컨텍스트는 평균의 2배를 읽히고, 출력은 평균의 5배를 받아낸다.

세 개의 숫자가 이 프레임을 그대로 증명한다.

비교 기준에 대해 미리 한 줄: 이 글의 "평균" 표현은 공식 통계가 아니라, 분석을 맡은 AI가 일반적인 사용 패턴을 기준으로 추정한 값이다. 정확한 기준선이 아니라 "내 사용 스타일이 어느 쪽으로 쏠려 있나" 를 보기 위한 참조선 정도로 읽어주시면 좋겠다.

(1) 캐시 적중률 92%

캐시 read 444M / (캐시 write 39M + read 444M) = 92%. AI 추정 기준 일반적인 분포는 70~80%대라고 한다. 같은 프로젝트로 다시 돌아오는 빈도가 높고, 한 세션 안에서 컨텍스트를 적게 갈아엎는다는 뜻이다. 코드를 갈아엎기보다 위에 쌓는 스타일이다.

(2) 출력/직접입력 비율 4.6배

내가 73 토큰 던지면 AI가 335 토큰으로 답한다. 일반적으로는 1.5~2배 정도라는 게 분석 결과였다. 4.6배는 AI에게 결정/판단을 외주하는 비율에 가깝다. 짧게 묻고 길게 답을 받는다.

(3) 응답당 컨텍스트 부피 50K

한 응답에 약 50K 토큰의 컨텍스트가 들어간다. 일반 대비 1.5~2배 정도로 큰 편이라고 한다. 파일 첨부와 히스토리 참조가 많아서 그렇다. 자연어 설명은 짧지만 그 앞뒤에 실제 자료를 듬뿍 붙인다.

한 줄 정리

토큰을 적게 쓰는 게 아니라 토큰 효율이 극단적으로 높은 사람이었다. 본인이 칠 비용은 아끼고, AI한테는 풍부한 자료와 길게 생각할 여유를 주는 — 시간당 의사결정 단가가 가장 낮은 운영 방식.

---

도구별 페르소나가 다르다

같은 사람인데 어휘가 완전히 다르다.

Codex 단골 멘트는 Implement the plan. (36회), 진행해줘. 계열이다. Claude한테는 "같이 보자" 모드, Codex한테는 "실행해라" 모드.

재미있는 건 "토론"이라는 단어 비율은 도구가 바뀌어도 거의 똑같다는 점이다 (0.22% vs 0.21%). 이건 도구의 문제가 아니라 내 체질이다. 어떤 AI를 쓰든 같은 비율로 토론을 건다. 다만 토론 후 실행을 어디서 하느냐가 다를 뿐.

---

프로젝트도 자연스럽게 분리되어 있었다

Claude는 글쓰기/문서/메타작업, Codex는 실제 코드 실행. 이걸 의식적으로 정한 적이 한 번도 없는데도 분기가 깔끔하게 갈려 있었다.

---

운영 방식 — 3단 루프

데이터에서 반복적으로 보이는 흐름은 결국 이 3단계로 압축된다.

1. 판단(Diagnose)  — "수정하지 말고 분석만 해줘 / 너의 생각은?"
2. 실행(Execute)   — "오케이 진행해줘 / 그렇게 해줘"
3. 검증(Verify)    — "다시 체크해줘 / 원본이랑 비교해줘"

이 루프가 내 시그니처에 가까웠다. 1번(판단) 없이 바로 실행으로 가거나 3번(검증) 없이 결과를 그냥 수용하는 패턴도 흔한데, 내 데이터에는 둘 다 꽤 일관되게 찍혀 있었다. 그리고 이 루프 안에 권한을 단계적으로 푸는 게이트가 하나 더 깔려 있었다.

1. "한번 분석해줘" / "체크만해줘"          ← 읽기 권한
2. "너의 생각은 어때? / 동의할까?"         ← 의견 권한
3. "오케이 진행해줘 / 그렇게 해줘"          ← 실행 권한
4. "커밋하고 푸쉬해줘"                      ← 커밋 권한

이 4단 게이트가 거의 모든 중요한 의사결정에서 반복된다. 평소엔 의식하지 못했는데, 데이터로 보니 이게 hallucination 방어선이자 잘못된 방향으로 빠르게 달리는 걸 막는 안전장치였다.

---

7가지 핵심 강점

(1) 모드 분리 능력

토론과 구현을 명시적으로 분리해서 통보한다. "아직 수정하지 말고 나랑 토론을 하자" 같은 문장이 데이터에 꽤 자주 박혀 있었다. AI를 굴려본 시간이 만든 운영 감각인 것 같다.

(2) 결정 외주, 책임 보유

AI에게 "딱 정해줘", "판단해서 알려줘"라고 자주 시킨다. 결정 과정은 외주하지만, 결정 책임은 내가 진다. 그래서 잘못된 방향이 나오면 "다 날리고 git 초기화". 매몰비용 0.

(3) 컨텍스트 밀도 운영

자연어 설명보다 실물 자료(파일, 로그, 이미지, 통화 스크립트, 다른 AI 답변)를 던진다. 입력 토큰은 평균의 1/3인데 컨텍스트는 평균의 2배. AI가 거짓말하기 어려운 환경을 체질적으로 만든다.

(4) 회복력 — 매몰비용 0

방향이 틀렸다고 판단되면 즉시 리셋. "모두 버려", "git 상태로 초기화". 도구를 잘 쓰는 마인드라기보단, 시스템을 굴려본 시간이 만든 습관에 가까운 듯하다.

(5) 의인화된 관계 형성

"너였으면 어떻게 할래?", "나 혼자 하기에는 더 힘든 상황이자나" — AI에게 내 처지를 공유한다. 비합리적인 의인화가 아니라, 내 제약을 알려주면 답이 내 상황에 맞게 좁혀진다. 의인화가 효율을 만든다.

(6) 자연 발생적 이중 검증

Claude가 만든 plan을 Codex가 실제 실행. Claude의 거짓말이 Codex 실행 단계에서 잡히는 구조가 의도하지 않게 작동 중이었다. "AI 거짓말을 잘 못 느낀다"는 감각의 절반은 사실 이 구조 덕분이다.

(7) 토큰 경제 운영

Max 구독 $200으로 환산하면 약 $810 상당의 가치를 쓰고 있었다(약 4×). Codex까지 합치면 1인 운영자가 굴리기엔 꽤 효율적인 편이었다.

---

다음 단계 — 더 잘할 수 있는 부분들

약점이 아니라 다음 레벨로 넘어갈 때 챙길 만한 것들로 정리했다.

(1) AI의 "자기 보고"까지 검증 루프에 넣기

결과물 검증은 강하다. 다만 AI가 "138 pass / 0 fail", "6개 컬렉션 다 확인했어" 같이 자기 행동을 보고할 때, 그 보고 자체를 한 번 더 들여다보면 검증 루프가 더 단단해진다.

보완 문장은 한 줄이면 충분하다.

실제로 실행한 명령과 핵심 출력도 같이 보여줘.

(2) 프로젝트 메모리로 인지 부담 옮기기

22개 프로젝트(Claude) + 15개(Codex). 토큰은 잘 절약되고 있는데, 프로젝트 간 컨텍스트 전환 비용을 내 머리가 부담하고 있다. 메모리 시스템에 프로젝트별 상태(현재 목표, 마지막 결정, 다음 액션)를 저장해두면 가장 큰 ROI가 나올 영역. 토큰 효율을 인지 효율까지 확장하는 단계다.

(3) Second Opinion을 의식적으로 설계

Gemini 같은 다른 AI 답변을 가져와 교차검증하는 패턴은 1인 운영자에게 강력한 보완 장치다. 다만 모든 판단에 다 쓰면 시간 비용이 누적되니, 어떤 결정에 second opinion을 붙일지만 미리 정해두면 강점이 그대로 유지되면서 비용은 줄어든다 (예: 아키텍처/보안/투자 결정에만).

(4) 도구 간 핸드오프 명문화

Claude에서 정리한 plan을 Codex로 옮길 때 요약이 살짝 손실된다. 두 AI 사이에 내 머리가 끼어 있어서 — 나만 안다. plan을 옮길 때 작은 템플릿 한 줄(목표 / 제약 / 검증 기준)만 정해두면, 매니저로서의 운영 비용이 더 줄어든다.

---

어떻게 분석했나 — 직접 해볼 수 있는 방법

이 글의 모든 숫자는 내 로컬 파일에서 나왔다. 외부 서비스가 아니라 누구나 자기 컴퓨터에서 똑같이 돌려볼 수 있는 데이터다.

데이터가 있는 곳

~/.claude/projects/<프로젝트별 폴더>/<세션ID>.jsonl
~/.codex/sessions/<연도>/...
~/.codex/history.jsonl

Claude Code는 프로젝트 폴더마다 세션이 .jsonl로 한 줄에 한 이벤트씩 쌓인다. 사용자 프롬프트, 어시스턴트 응답, 토큰 사용량(usage), 캐시 read/write, 모델 이름까지 다 들어 있다. Codex는 ~/.codex/sessions/에 비슷한 구조로 쌓이고 history.jsonl에 사용자 입력 히스토리가 누적된다.

추출할 핵심 필드

세션 JSONL을 한 줄씩 파싱해서 아래 항목만 뽑으면 충분하다.

• 사용자 프롬프트 텍스트: type == "user" 메시지의 본문
• 토큰 사용량: 어시스턴트 응답의 usage (input / output / cache_creation / cache_read)
• 타임스탬프 / 세션 ID / 프로젝트 경로: 시계열·프로젝트 분포용
• 모델 이름: 단가 환산용

핵심 지표 계산식

캐시 적중률      = cache_read / (cache_read + cache_write)
출력/입력 비율   = output / input(직접 타이핑분만, 캐시 제외)
세션당 컨텍스트  = (input + cache_read) / 응답 수
프롬프트 평균길이 = sum(len(prompt)) / 프롬프트 수
어휘 빈도        = "진행해", "해줘", "토론" 등 키워드 카운트 / 전체 프롬프트 수
비용 환산        = 모델별 단가 × (input/output/cache 각각)

캐시 적중률과 출력/입력 비율 두 개만 봐도 본인의 사용 스타일이 뚜렷하게 드러난다.

참고: 본문에 나온 "평균" 비교치(70~80%, 1.5~2배 등)는 별도의 공식 데이터셋에서 뽑은 게 아니라, 분석을 맡긴 AI가 일반적인 사용 패턴을 기준으로 추정해준 값이다. 절대 기준이 아니라 "내가 어느 쪽으로 쏠려 있나" 를 보는 참조선으로 봐주시면 좋겠다. 본인 숫자 자체는 위 계산식으로 정확히 재현 가능하다.

내가 실제로 던진 프롬프트

미리 잡아둔 4단계 플로우 같은 건 없었다. 홈 디렉토리에서(cd ~) Claude Code를 그냥 띄워놓고, 떠오르는 대로 짧게 던졌다. 세션 히스토리에 남은 실제 프롬프트는 14개 정도였고, 분석을 시작한 첫 마디는 이거였다.

클로드 코드를 보면 히스토리를 가지고 있자나 각 폴더별로...
그 히스토리를 보면 나랑 대화를 나누는 것들이 있고..
그것들을 전체다 분석해서 나의 프롬프팅 성향과 방법 등을 분석 해볼수 있어?

답이 나오면 다음을 던졌다.

좀더 자세히 분석해줘.
AI를 대하는 자세라든가..
나는 AI의 거짓말을 많이 못느낌점..
다른 사람들보다 토큰을 많이 안쓰는점 기타 등등

나는 다른 사람에 비해 토큰 사용량이 어떻게되?

통합적으로 내가 AI를 다루는 총평을 만들어줘.

Codex 데이터도 같이 보고 싶어졌을 때는 이렇게 물었다.

여기에서 실제 코덱스의 히스토리도 같이 볼수 있나??

마지막에는 결과물을 파일로 떨어뜨렸다.

이제 클로코드에서 총평을 한것과 클로드코드와 코덱스를 합쳐서
총평을 한것을 문서로 만들어줘 .md 파일로 해서..
@Documents/ 안에 만들면되.

그리고 — 이게 마음에 드는 부분인데 — 결과를 한 번 더 의심하는 프롬프트도 끼어 있었다.

실제 전체 다 히스토리를 다 보고 애기한거 맞지?
실제 전체를 보고 결론을 내려줘!

본문에서 "AI 자기 보고를 한 번 더 들여다보면 검증 루프가 더 단단해진다" 고 적었는데, 분석 과정에서도 무의식적으로 이걸 하고 있었다는 게 데이터에서 다시 드러났다. 회고하면서 내가 가장 놀란 부분이다.

한 줄 요약

특별한 플로우를 세팅한 게 아니다. 홈에서 Claude Code 띄우고, 짧은 자연어 14줄을 던진 게 전부다. 그 결과물을 읽고, 마음에 드는 프레임은 받아들이고, 의심스러운 부분은 "전체 다 보고 한 거 맞지?" 로 다시 물었다.

분석조차 자기가 평소에 쓰는 운영 방식 그대로 굴리는 것 — 그게 데이터에서 자기를 발견하는 가장 정직한 방법이었다. 그리고 그 운영 방식 자체가 이 글의 본문이다.

---

멀리서 본 그림

여기까지 정리하고 보니 내 작업 방식이 한 장의 그림으로 보였다.

1. 머릿속에서 가설 발생
        ↓
2. Claude한테 짧게 토론 — "이 방향 어때?"
        ↓
3. 합의 → plan 정리
        ↓
4. Codex한테 plan 던짐 — "Implement the plan."
        ↓
5. Codex 실행 결과 확인
        ↓
6. 이상하면 → 리셋 / 다시 Claude로 돌아가 토론

CTO + 시니어 엔지니어 + PM 세 자리짜리 미니 팀이 돌아가는 모양에 가까웠다. 나 혼자서, 두 AI를 빌려서.

---

마지막 한 줄

프롬프트를 잘 쓰는 것과, AI를 굴려서 일이 굴러가게 만드는 건 다른 일인 것 같다.

데이터를 까보기 전에는 "AI를 잘 활용하는 편" 정도로 막연하게 생각했다. 까보고 나니 표현이 살짝 바뀌었다 — AI 팀을 굴리는 매니저에 가깝게 일하고 있었구나.

특별한 의도로 그렇게 만든 게 아니라, 64일 동안 6,232번을 두드리면서 자연스럽게 자리 잡은 운영 방식이라는 게 가장 흥미로운 부분이었다. 자기 데이터를 한 번씩 까보는 건 누구한테나 권할 만한 일인 것 같다.