Claude Code와 한 달간 페어 프로그래밍을 하며 느낀 점 — 실제로 효과적이었던 것들

6주 전, 저는 Claude Code를 일상적인 페어 프로그래머 (pair programmer)로 사용하기 시작했습니다. 데모용이나 "AI가 이런 것도 할 수 있어요"라고 보여주기 위한 용도가 아니라, 실제로 프로덕션에 배포되는 (ship-to-production) 작업을 위해서였습니다.

인터넷에는 수많은 의견이 넘쳐납니다. AI가 모든 개발자를 대체할 것이라는 의견과, 혹은 깨진 코드를 작성하는 장난감에 불과하다는 의견이 대립하죠. 한 달간 실제로 사용해 본 결과, 둘 다 사실이 아닙니다. 실제로 무엇이 효과적이었는지 공유하겠습니다.

설정 (The Setup)

저는 웹 검색, 파일 작업, 데이터베이스 쿼리를 위한 몇 가지 커스텀 MCP 서버와 함께 터미널에서 Claude Code를 실행합니다. IDE 플러그인도, 채팅 인터페이스도 사용하지 않습니다. 그저 /usr/bin/claude와 터미널 분할 화면뿐입니다.

주요 설정 결정 사항:

• 세션을 시작하기 전 항상 명확한 목표 파일 (goal.md)로 시작할 것
• 컨텍스트 (context)를 위해 MCP 도구를 사용할 것 (문서 검색, 로그 확인, 스키마 읽기 등) — 도구가 없는 순수 Claude Code는 환각 (hallucination) 현상이 너무 심합니다.
• 모든 작업을 최대 15분 단위의 청크 (chunks)로 나눌 것

강점을 보이는 부분 (Where It Shines)

1. 자신감 있는 리팩터링 (Refactoring). 2년 동안 자연스럽게 비대해진 600줄짜리 Express.js 라우트 핸들러 (route handler)가 있었습니다. "이것을 controller/service/repository 레이어로 분리하고, 기존 동작을 모두 유지하며, 세션 미들웨어 (session middleware)를 깨뜨리지 마세요." Claude Code는 단 한 번의 시도로 이를 수행했습니다. 저는 10분 만에 디프 (diff)를 검토했습니다. 회귀 (regression)는 전혀 없었습니다.

비결은 무엇을 변경하지 '말아야' 하는지 구체적으로 명시하는 것입니다. "120-180번 라인의 에러 핸들링 패턴은 건드리지 마세요"라고 말하는 것이 "이것을 제대로 리팩터링하세요"라고 말하는 것보다 훨씬 낫습니다.

2. 평소 미루곤 했던 보일러플레이트 (boilerplate) 작성. 데이터베이스 마이그레이션 (database migrations), 새로운 모델을 위한 CRUD 라우트, 기존 엔드포인트 (endpoint)에 대한 API 테스트 등은 제가 "2시간" 정도로 예상하지만 집중력이 흐트러져 4시간이 걸리곤 하는 작업들입니다. Claude Code는 90%의 정확도로 한 번에 이를 끝냅니다. 나머지 10%는 사소한 수정 작업일 뿐입니다.

3. 난해한 에러 디버깅 (Debugging). 어떤 WASM WebGL 프로젝트가 콘솔 에러가 전혀 없는 상태에서 검은 화면만 렌더링하고 있었습니다. 저는 셰이더 (shader) 코드와 빌드 설정을 Claude에 붙여넣었습니다. Claude는 제가 한 시간 동안 뚫어지게 쳐다봤던 WGSL 버텍스 셰이더 (vertex shader)에서 누락된 @interpolate(flat) 한정자 (qualifier)를 찾아냈습니다. 저의 저녁 시간을 아껴주었습니다.

부족한 부분 (Where It Falls Short)

복잡한 다단계 로직 (Complex multi-step logic). "OAuth, 세션 관리, 속도 제한 (rate limiting), 그리고 감사 로깅 (audit logging)을 포함한 새로운 인증 흐름을 구현하라"라고 명령하면, Claude Code는 작동하는 코드를 생성하지만 예외 케이스 (edge cases)를 놓칩니다. 예를 들어 비밀번호 변경 시의 CSRF 토큰 순환 (rotation)이나, 에러 응답에서의 속도 제한 헤더 (rate limit headers) 같은 것들 말입니다. 이는 시니어 개발자가 경험을 통해 알고 있는 부분들입니다.

설계 결정 (Design decisions). Claude Code는 "어떻게 (how)"에는 뛰어나지만 "할 것인가 (whether)"에는 취약합니다. 이 기능을 위해 WebSocket을 사용할까요, 아니면 SSE를 사용할까요? 이것을 새로운 마이크로서비스 (microservice)로 만들어야 할까요, 아니면 기존 API의 엔드포인트 (endpoint)로 만들어야 할까요? Claude Code는 설령 그것이 틀린 방식일지라도 사용자가 제안하는 방식이라면 기꺼이 구현해 버립니다.

테스트 없는 대규모 리팩터링 (Large refactors with no tests). 검증할 테스트 스위트 (test suite)가 없다면, Claude Code는 겉보기에는 그럴싸해 보이지만 조용히 시스템을 망가뜨리는 변경 사항을 만들어냅니다. Claude Code를 자유롭게 풀어놓기 전에, 반드시 핵심 경로 (critical path)를 실행하는 최소 하나 이상의 통합 테스트 (integration test)를 갖춰두어야 합니다.

효과적인 워크플로우 (The Workflow That Works)

저의 현재 루틴은 다음과 같습니다:

1. Goal.md 우선 작성 — 명시적인 제약 사항을 포함하여 무엇이 일어나야 하는지에 대해 3~5문장으로 작성합니다.
2. Claude Code의 1차 작업 — 저는 대화 내용이 아니라 차이점 (diff)을 검토합니다.
3. 미묘한 부분 수정 — 에러 처리 (error handling), 예외 케이스 (edge cases), 명명 규칙 (naming conventions) 등을 직접 수정합니다.
4. 좋은 메시지와 함께 커밋 — Claude Code가 커밋 메시지의 상용구 (boilerplate)를 작성하면, 저는 "이유 (why)"를 추가합니다.

가장 큰 생산성 향상은 속도가 아닙니다. 바로 **몰입 상태 (flow state)**입니다. Claude Code가 기계적인 부분들을 처리해 줄 때, 저는 아키텍처 결정, 예외 케이스 사고, 코드 리뷰와 같이 중요한 부분에 집중하며 몰입 상태를 유지할 수 있습니다.

솔직한 결론 (The Honest Bottom Line)

Claude Code는 저의 하루 중 약 2~3시간을 아껴주는데, 주로 어차피 미루고 싶었을 작업들에서 시간을 절약해 줍니다. 이 도구가 시니어 엔지니어의 필요성을 없애는 것은 아닙니다. 오히려 단순 반복 작업 (grunt work)을 제거함으로써 그들을 더 효과적으로 만들어 줍니다.

가장 큰 가치를 얻는 개발자는 모든 것에 이 도구를 사용하는 사람이 아닙니다. 언제 이 도구를 사용해야 하고, 언제 직접 코드를 타이핑해야 하는지를 정확히 아는 사람입니다.

저는 실제로 가장 효과적이었던 구체적인 프롬프트(prompts)와 워크플로(workflows)를 수집해 왔습니다. 혹시 궁금하시다면, 제가 작성한 재사용 가능한 Claude Code 설정(configurations)과 MCP 서버 설정(setups) 전체 목록을 공유해 드렸습니다.