Claude Code를 11일 동안 쓴 결과 — 데이터로 본 나의 사용 패턴

시리즈 1탄. 후속편: Claude Code를 5주 더 쓴 결과 — 스킬·CLAUDE.md를 키워가는 방식

Claude Code 사용 이력을 분석하는 기능이 생겼길래 돌려봤다. 11일치 세션 데이터를 보니 생각보다 솔직한 결과가 나왔다. 잘 됐던 것, 안 됐던 것이 숫자로 찍혀 있으니 부정하기가 어렵다.

수치부터 보면: 549 메시지, 42 세션, 108 커밋, 11일. 하루 평균 50메시지 가까이 쳤다. 생각보다 많이 쓰고 있었다.

뭘 하는 데 썼나

세션을 분류해보니 크게 다섯 영역이 나왔다.

• 기술 블로그 & 포트폴리오 작성 (~12세션): 슬롯 게임, Redis Lua 스크립트, StampedLock 같은 주제로 마크다운 문서 작성
• PR 워크플로우 자동화 (~12세션): PR 생성, 리뷰 반영, CI 수정, GHE 파이프라인 구성
• 기능 구현 & 버그 수정 (~8세션): RSC 캐시 최적화, 예산 페이지, API 마이그레이션 등
• 인프라 & 검색 설정 (~5세션): Prometheus 배포, OpenSearch 인덱스, Nori 분석기 설정
• 이력서 & 취업 자료 (~5세션): 채용 공고 분석, CV 작성, job-analyzer 스킬 제작

TypeScript(305파일), Markdown(293파일), Java(178파일) 순으로 많이 건드렸다. 코드만 쓰는 게 아니라 문서 생산도 상당한 비중을 차지한다.

잘 됐던 것

1. PR 전 주기 자동화

"PR 리뷰 반영하고, 머지 컨플릭트 해결하고, CI 고쳐줘"를 한 번에 시키는 패턴이 생각보다 잘 작동했다. 리뷰 코멘트 읽고 → 수정하고 → 커밋하고 → CI 실패 원인 분석하고 → 재수정까지 한 세션에서 굴러가는 경우가 많았다.

이전엔 리뷰 반영이 귀찮아서 질질 끌었는데, Claude한테 맡기면 심리적 저항이 낮아진다. 같은 작업을 내가 직접 하면 30분이지만 Claude가 하면 대기 시간만 된다.

2. 기술 블로그 콘텐츠 생산

과거 업무 경험을 문서화하는 작업에 꽤 효율적이었다. 내가 구현했던 내용을 설명하면 글 뼈대를 잡아주고, 내가 수정하는 방식으로 진행했다. 블로그 포스팅 하나를 처음부터 끝까지 쓰는 게 하루 이상 걸렸는데, 지금은 한 세션에 초안까지 나온다.

심지어 blog-post-writer 스킬에 자동 평가까지 넣었더니 품질 일관성이 생겼다. 반복 작업에 기준을 만들어두면 매번 같은 설명을 안 해도 된다.

3. 멀티스텝 복합 작업

"A 하고, B 하고, C 해줘" 식의 연속 작업에 강하다. 단순 코드 생성보다 여러 파일을 읽고 맥락을 유지하면서 작업하는 능력이 실질적으로 유용하다. 멀티파일 변경이 가장 도움됐다고 분석된 것도 이런 이유다(24건).

안 됐던 것

1. Wrong Approach — 21건

가장 많이 터진 패턴이다. 내가 이미 방향을 알려줬는데 Claude가 알아서 다른 길을 탐색하다가 시간을 날리는 경우다.

OpenSearch 쿼리 짜달라고 했더니 코드베이스를 뒤지기 시작했다. 인덱스 매핑을 먼저 보라고 했는데 무시하고 파일 읽기를 한참 했다. 결국 세션을 그냥 나왔다.

이건 내 문제이기도 하다. 맥락을 충분히 안 줬거나, "이거 먼저 봐"를 명확하게 안 했거나. Claude가 방향을 모르면 탐색부터 하는 게 합리적인 선택이니까. 근데 내가 이미 방향을 알 때는 그 탐색이 낭비다.

2. 툴 오해 — 반복적인 cmux vs tmux 혼동

내 환경은 tmux 대신 cmux를 쓰는데, Claude가 계속 tmux 명령어를 쓰거나 cmux 플래그를 잘못 썼다. 한 세션에서만 여러 번 수정했다.

이건 명확히 내가 CLAUDE.md에 적어두지 않은 탓이다. Claude는 새 세션마다 맥락이 없다. 내가 당연하게 아는 환경 정보를 Claude는 모른다.

3. CI를 깨는 코드 변경 — 11건

null guard를 지웠더니 DB 없는 환경에서 CI가 터졌다. 캐시 최적화가 NextAuth mock 체인을 건드려서 테스트가 깨졌다. 사후에 고치는 사이클이 반복됐다.

Claude가 변경의 파급 범위를 항상 예측하지 못한다. 특히 테스트 환경과 프로덕션 환경의 차이, 외부 의존성이 있는 코드에서 실수가 많았다.

인사이트 — 어떻게 쓰면 나을까

"교정" 말고 "예방"으로

내 스타일은 일단 시키고 틀리면 고치는 방식이었다. 이게 빠르게 움직이는 느낌을 주지만, 실제로는 정정 사이클이 많아서 느리다.

반대로 세션 시작할 때 맥락을 2~3줄 던져주는 게 훨씬 효율적이다:

환경: cmux 사용 (tmux 아님), GHE에 gh CLI 설치됨, Spring Boot는 local 프로필로 실행
이번 작업: OpenSearch 인덱스 매핑을 먼저 확인하고 쿼리 작성

이것만 있어도 탐색 낭비가 많이 줄어든다.

CLAUDE.md는 진지하게 쓸 것

프로젝트 루트에 CLAUDE.md를 두면 Claude가 매 세션마다 읽는다. PR 제목 형식, 디렉터리 구조, 환경 특이사항을 여기 적어두면 반복 수정을 없앨 수 있다.

나는 이걸 처음엔 대충 썼다가 cmux 혼동, 잘못된 디렉터리 저장, Dooray 댓글/본문 혼동 같은 문제가 반복된 뒤에야 제대로 정리했다. 처음부터 잘 써뒀으면 수십 번의 수정이 필요 없었을 거다.

복잡한 멀티스텝 작업에 맞게 태스크를 구성할 것

Claude는 명확하게 구조화된 작업에 강하다. "이거 고쳐줘"보다:

1. PR #XXX의 리뷰 코멘트 전부 읽기
2. 각각 수정하고 개별 커밋
3. 수정 후 테스트 실행
4. 테스트 통과하면 push

이렇게 주면 중간에 뭔가 빠지거나 순서가 꼬이는 경우가 확연히 줄었다.

방향을 알 때는 명확하게 말할 것

"subject_id가 어디서 오는지 찾아봐"보다 "OpenSearch 인덱스 매핑에서 subject_id 필드 확인해줘"가 훨씬 낫다. 내가 이미 어디를 봐야 하는지 알면, 그걸 그대로 알려주는 게 낫다. 탐색은 내가 모를 때만 시키는 게 효율적이다.

반복 작업은 스킬로 만들 것

PR 생성, 블로그 포스팅, 리뷰 반영처럼 자주 하는 작업은 스킬로 만들어두면 매번 설명하지 않아도 된다. 컨벤션, 형식, 체크리스트를 스킬 파일에 담아두면 Claude가 매 세션마다 처음부터 배우지 않아도 된다.

전체적인 느낌

83% 달성률이라는 숫자는 나쁘지 않다. 근데 나머지 17%를 분석해보면 대부분 내가 맥락을 덜 줬거나 방향을 불명확하게 했을 때 터졌다.

Claude는 알아서 잘 하는 AI가 아니라, 잘 설명하면 잘 하는 AI에 가깝다. 함께 일하는 신입이 있다고 생각하면 비슷하다. 잘 가르쳐두면 믿고 맡길 수 있고, 당연히 알겠지 하고 맡기면 엉뚱한 방향으로 간다.

결국 Claude를 잘 쓰는 건 프롬프트 스킬이 아니라 내 작업 방식을 얼마나 구조화하느냐의 문제다.