서론

"나는 어떤 기술에 능숙한가", "어떤 작업 스타일인가" —— 엔지니어로서의 자기 평가는 언제나 주관에 의존하기 쉽다. 이력서에는 대표적인 경험밖에 쓸 수 없고, 강점을 물어봐도 "음, TypeScript 같은 거..."라며 애매하게 대답하게 된다.

하지만, Claude Code (Anthropic의 AI 코딩 어시스턴트)를 일상적으로 사용하고 있다면, 당신의 행동 로그가 ~/.claude/projects/에 가득 남아 있다. 실제로 어떤 명령어를 입력했는지, 무엇에 시간을 썼는지, Claude에게 어떻게 지시했는지 —— 라는

정량적인 행동 기록이다.

본고에서는 Claude Code의 대화 로그를 해석하여 기술 스택, 작업 경향, 강점과 약점을 자동으로 추출한 실험을 소개한다. "내가 생각했던 자기 모습"과 "로그가 보여주는 실태" 사이의 격차가 흥미로울 정도로 보이기 시작했다.

5줄 요약 (클릭하여 확장)

TL;DR (5줄 요약)

• Claude Code의 대화 로그(~/.claude/projects/에 JSONL 형식으로 저장)에는 도구 사용 횟수, 파일 조작, 명령어 실행 이력 등의 정량적 행동 데이터가 남는다.
• 스크립트로 로그를 해석하면 "실제로 자주 다루는 기술 스택", "Claude Code 활용의 성숙도" 등을 객관적으로 시각화할 수 있다.
• API 키 등의 민감 정보는 로그 해석 시 마스킹(Masking) 처리하고, 집계값만을 중간 파일로 남기는 설계로 하면 여러 PC 간에 안전하게 수집할 수 있다.
• "자신의 프로젝트 구성"뿐만 아니라 "어떻게 지시를 작성하고 있는가"의 패턴으로부터 아키텍처 지향성, 프로세스 규율, 위임 스타일까지 읽어낼 수 있다.
• 결론: Claude Code를 깊이 있게 사용하고 있다면, 로그는 정량적 포트폴리오 소재가 될 수 있다. 엔지니어의 자기 평가를 "주관적인 이야기"에서 "로그에 근거를 둔 분석"으로 바꾸는 접근법으로서 유효하다.

1. 로그는 어디에 있는가

Claude Code의 대화 로그는 기본적으로 다음 경로에 저장된다.

~/.claude/projects/
├── C--work-myapp/ ← 프로젝트 경로가 디렉토리명으로
│ ├── abc123.jsonl ← 1대화 = 1파일 (JSONL 형식)
...

각 .jsonl 파일의 한 줄이 하나의 이벤트(사용자의 프롬프트 전송, Claude의 응답, 도구 실행 등)에 대응한다.

{"type": "user", "timestamp": "2026-05-10T10:23:45.123Z", "message": {...}}
{"type": "assistant", "timestamp": "2026-05-10T10:23:47.456Z", "message": {...}}

이 로그는 해당 머신에만 남는다. 클라우드 동기화는 되지 않으므로, 여러 대의 PC에서 Claude Code를 사용하고 있다면 각 머신에서 데이터를 추출하여 집계해야 한다.

2. 안전하게 데이터를 추출하는 아키텍처

대화 로그에는 API 키, 이메일 주소, 코드 조각 등 민감한 정보가 혼입될 수 있다. 그대로 집계하는 것은 위험하다. 그래서 다음과 같은 설계를 채택했다.

【각 PC】
~/.claude/projects/**/*.jsonl
↓ extract.mjs (마스킹 + 집계만 수행)
...

마스킹 규칙은 다음과 같은 정규 표현식(Regular Expression)으로 구현했다.

const SECRET_PATTERNS = [
/sk-[A-Za-z0-9_-]{16,}/g, // OpenAI/Anthropic 스타일 키
/ghp_[A-Za-z0-9]{20,}/g, // GitHub PAT
...

중간 파일에는 집계값과 짧게 마스킹된 프롬프트 발췌본만을 저장한다. 코드 조각이나 가공되지 않은 대화 내용은 커밋하지 않는다.

3. 로그에서 무엇을 볼 수 있는가

3-1. 기술 스택 ("어떤 기술을 실제로 다루고 있는가")

파일 조작 (Read/Edit/Write)의 확장자와 명령어 실행 종류를 집계하면, 자신이 정말로 자주 다루고 있는 기술 스택이 보인다.

필자의 경우 (단일 PC · 약 1개월분):

.ts (로직·타입 정의)와 .tsx (UI 컴포넌트)를 나누어 집계한 이유는 프론트엔드와 백엔드의 비중을 파악하기 위해서다.

Markdown의 조작량이 언어들과 나란히 나타난 것은 흥미로운 발견이었다. "코드만큼이나 문서를 많이 쓰고 있다"라는 사실은 이력서에는 나타나지 않는다.

프레임워크·도구별로는:

3-2. Claude Code 활용의 성숙도

어떤 도구를 어떻게 사용하는지도 성숙도를 나타내는 좋은 지표다.

【도구 사용 횟수 (2대 · 약 1개월 통합)】
Bash 13,131 명령 실행
Read 9,317 파일 읽기
...

Read가 Write의 3.6배라는 비율이 인상적이다. "코드를 쓰기 전에 대량으로 읽고 이해한다"라는 스타일이 숫자로 드러나고 있다.

Claude Code의 활용 성숙도는 대략 다음과 같은 레벨로 정리할 수 있다 (필자의 주관적인 정리):

TaskCreate/Update 합계 2,444회 · Agent 722회라는 숫자로부터, L4에 도달해 있다는 평가를 내렸다.

3-3. 강점의 언어화 ("어떻게 지시하는가에서 성격이 드러난다")

로그 속에서 반복적으로 나타나는 프롬프트 패턴은 해당 엔지니어의 개발 철학을 보여준다.

예를 들어, 다음과 같은 지시가 다수 등장하는 경우:

"다음 내용을 조사하고 필요하다면 티켓을 생성한 뒤, 티켓별로 수정과 커밋을 진행할 것. 또한,

npm run build / test / lint / type-check

대응할 것."

이는 단순한 지시가 아니라, "조사 → 과제의 티켓화 → 작게 커밋 → 정적 검사로 담보"라는 품질 게이트를 자신의 표준 작업 절차(SOP)로 내면화하고 있음을 나타낸다.

마찬가지로 로그를 통해 읽어낼 수 있는 경향:

• 리팩터링 지향: "기능 추가"보다 "중복 제거·추상화"에 관한 지시가 많음
• 수평 전개 설계: 한 번 확립한 패턴(이미지 저장 구성 등)을 여러 프로젝트에 전개함
• 사양 정합성에 대한 집착: 리뷰의 수렴 결과를 사양서에 반영하는 운용을 하고 있음

이러한 강점은 이력서에 쓸 수 없고, 스스로는 "당연하다"고 생각하여 깨닫지 못하는 경우가 많다. 로그가 "객관적인 거울"이 되어준다.

4. 실제 발견과 자기상(Self-image)의 괴리

분석을 통해, "내가 생각했던 모습"과 "로그가 보여주는 실태" 사이의 격차가 몇 가지 드러났다.

발견 ①: "인프라는 약하다"고 생각했지만 실적이 있다

Docker(144회) · Cloudflare Workers(119회) · wrangler · Vercel——라는 숫자는 "인프라가 약한 사람"의 실적이 아니다. "설정은 하지만 잘한다고는 할 수 없다"라는 셀프 이미지는 과소평가였다.

발견 ②: Markdown 조작량이 코딩 언어에 필적함

Markdown의 조작 횟수(4,653회)는 SQL(31회)의 150배 이상이다. "코드를 쓰는 엔지니어"라기보다 "코드와 문서를 동등하게 다루는 엔지니어"라는 실태에 가깝다. 사양서·설계서·ADR의 유지를 중시하는 스타일이 숫자로 나타났다.

발견 ③: "질문이 많다"는 약점이 아니라 협업 스타일

AskUserQuestion(Claude가 불명확한 점을 확인하도록 설정)이 134회 있었다. 처음에는 "판단 위임이 부족하다"고 보았으나, 다시 생각해보면 "독단적으로 진행하지 않고 합의를 형성하는 자세"라고도 읽을 수 있다. 숫자의 해석에는 컨텍스트가 필요하다.

발견 ④: "RAG는 구현해 본 적이 있다"고 생각했지만 미구현

기억으로는 "조금 다뤄봤다"고 생각했지만, 로그를 보면 프레임워크 계열인 pgvector, LlamaIndex, LangChain의 검출 횟수는 거의 제로에 가깝다. 직접 구현했거나 다른 라이브러리를 사용했을 가능성을 부정할 수는 없지만, 로그상으로는 확인할 수 없었다 —— 스킬의 공백(skill gap)으로서 재확인하는 계기가 되었다.

5. 이 방법론의 한계

로그 분석이 모든 것을 말해주지는 않는다. 몇 가지 중요한 한계가 있다.

로그에 나타나지 않는 중요한 스킬

• 코드 리뷰나 페어 프로그래밍(Pair Programming) 등의 협업 스킬
• 아키텍처 설계의 "사고 프로세스" (대화 내용을 보면 알 수 있지만 집계 데이터로는 나타나지 않음)
• 운영 장애 대응 및 인시던트 대응(Incident Response) 실력
• 비즈니스 요구사항 정리, 고객 협상 등의 비기술적 스킬

단일 PC · 단기간 관측에 따른 편향(Bias)

이번 분석은 주로 1대의 PC, 약 1개월 분량의 데이터에 기반한다. 프로젝트의 편중(하나의 프로젝트가 전체 턴의 86% 차지)도 심하다. 여러 대의 PC와 장기간의 데이터가 있을수록 신뢰도가 높아진다.

"횟수가 많다 = 잘한다"는 아니다

Bash 실행이 13,000회라 하더라도, 그것이 쉘 스크립트(Shell Script) 전문가임을 의미하지는 않는다. 에러가 많아서 여러 번 시도했을 가능성도 있다. 양은 근거가 될 수 있지만, 질에 대한 증명은 별도로 필요하다.

6. 실천을 위한 단계

동일한 시도를 해보고 싶은 사람들을 위해 최소한의 단계를 제시한다.

단계 ①: 로그 위치 확인하기

ls ~/.claude/projects/

프로젝트 경로가 디렉토리 이름으로 되어 있는지 확인한다.

단계 ②: 간단한 카운트부터 시작하기

우선 하나의 JSONL 파일을 살펴보며 구조를 파악한다.

# 최근 세션 확인 (bash/zsh 공통)
find ~/.claude/projects -name "*.jsonl" | xargs ls -lt | head -5
# 도구 사용 횟수 개략적 산출
...

단계 ③: 마스킹(Redaction) 스크립트 작성하기

민감 정보의 제거는 필수다. 앞서 언급한 정규 표현식 패턴을 참고하여 extract.mjs를 정비한다.

// 마스킹의 최소한의 구현 예시
function redact(s) {
if (typeof s !== "string") return "";
...

단계 ④: 집계 결과를 AI에게 해석시키기

중간 파일이 만들어졌다면, Claude에게 다음과 같이 질문하는 것이 빠르다:

이 로그 집계 데이터로부터 나의 강점, 작업 경향, 스킬의 공백을 분석해 주세요.
특히 "내가 인지하지 못하고 있을 가능성이 있는 특징"을 우선적으로 지적해 주세요.
{intermediate.json의 내용을 붙여넣기}

AI가 "데이터를 읽는 방법에 대한 가설"을 제시해주므로, 이를 본인이 검증하고 보정하는 루프가 효율적이다.

요약

Claude Code를 일상적으로 사용하는 엔지니어에게 ~/.claude/projects/의 로그는 정량적인 행동 기록이다.

"자신이 어떤 기술에 능숙한가"는 주관적으로 말하기 쉽지만, 로그는 "실제로 무엇을 몇 번 조작했는가"를 정직하게 기록하고 있다. 작업 시간대, 요일 패턴, Claude Code 활용 성숙도, 지시 패턴에서 읽어낼 수 있는 개발 철학까지 —— 이력서로는 전달할 수 없는 부분이 보인다.

한편, 로그에 나타나지 않는 중요한 스킬도 많다. "로그로 뒷받침하는 것"과 "로그에 없는 것을 보완하는 것"을 모두 결합함으로써, 더욱 해상도 높은 자기 분석이 가능해진다.

Claude Code를 깊이 있게 사용하고 있다면, 그 로그는 이미 존재한다. 남은 것은 스크립트 하나로 "과거의 자신"을 시각화하는 것뿐이다.

이직 활동, 포트폴리오 작성, 커리어 정리 타이밍에 한 번 로그를 파헤쳐 보는 것을 추천한다.

참고

• Claude Code Documentation — Claude Code 공식 문서
• Claude Code: Best practices for agentic coding — Anthropic 엔지니어링 블로그 (Claude Code 활용 베스트 프랙티스)
• Model Context Protocol (MCP) — Claude가 외부 도구와 연동하기 위한 프로토콜 사양

Discussion