나는 Claude Code를 어떻게 쓰고 있을까?

이전 글에서 설계만 하고 코드는 전부 Claude Code가 작성한다고 짧게 언급했습니다. 이번엔 구체적으로 어떻게 쓰고 있는지 실제 데이터와 함께 풀어보겠습니다.

90%는 Claude Code로만

현업에서 제 작업의 90%는 Claude Code를 통해 이루어집니다. Terraform, Kubernetes YAML, Helm 차트, Go 서비스, Python 스크립트, 심지어 Notion 문서 작성과 PR 생성까지 전부요. IDE를 안 켠지 한 달이 넘었습니다.

제가 하는 건 설계입니다. 어떤 아키텍처로 갈지, 어떤 순서로 배포할지, 어디서 장애가 날 수 있는지. 방향성과 놓치기 쉬운 것들, 예상되는 실수만 머릿속에 넣어두고 작업을 시작합니다. 중간중간 톡톡 잘 쳐주면 결국 목표점을 향해 잘 갑니다.

개인용과 업무용을 엄격히 분리합니다

Claude Code의 핵심은 .claude/ 디렉토리 구조입니다. 저는 이걸 개인용과 업무용으로 완전히 분리해서 씁니다.

~/.claude/                          # 글로벌 설정 (개인 기본값)
├── CLAUDE.md                       # 482줄, 기본 페르소나 + 언어 표준
├── agents/                         # 커스텀 에이전트 30개
├── modes/                          # 커스텀 모드 7개
├── skills/                         # 커스텀 스킬
├── rules/                          # 글로벌 규칙 (722줄)
│   ├── coding-style.md
│   ├── git-workflow.md
│   ├── security.md
│   └── ...
└── projects/                       # 프로젝트별 메모리 14개

~/Development/company/.claude/      # 회사 전용 설정 (글로벌 덮어쓰기)
├── CLAUDE.md                       # 106줄, 회사 특화 규칙
└── rules/                          # 회사 규칙 (683줄)
    ├── security.md                 # 176줄, 암호화 보안/컴플라이언스
    ├── gitops.md                   # ArgoCD 앱오브앱스 패턴
    ├── go-conventions.md           # Go 코드 컨벤션
    ├── ci-cd.md                    # GitHub Actions 워크플로우
    ├── incident-response.md        # 장애 대응 프로토콜
    └── solidity.md                 # 스마트 컨트랙트 규칙

회사 디렉토리 안의 .claude/가 글로벌 설정을 덮어씁니다. 회사에서 Claude Max 구독을 제공해주고, 개인용은 따로 결제합니다. MCP 서버를 연결하고 싶으면 보안 규정 확인 후 Head한테 허락을 맡고 씁니다.

총 규칙만 약 2,000줄입니다. 이게 왜 필요한지는 뒤에서 설명합니다.

MCP 서버 16개

현재 연결된 MCP 서버 목록입니다.

서버	용도
GitHub	PR 생성, 이슈 관리, 코드 검색
Notion	문서 작성, 페이지 관리
Grafana	대시보드 조회, 메트릭 쿼리, 알럿 관리
Shortcut	티켓 조회, 상태 업데이트
Playwright	E2E 테스트, 브라우저 자동화
Serena	시맨틱 코드 분석, 프로젝트 메모리
Context7	라이브러리 문서 조회
Sequential Thinking	다단계 추론
Tavily	웹 검색
그 외 7개	이미지 생성, 문서 처리 등

이걸 다 쓰는 건 아닙니다. 상황에 따라 필요한 것만 활성화합니다. 중요한 건 Claude Code가 단순 코드 생성기가 아니라 외부 시스템과 직접 소통하는 인터페이스가 된다는 점입니다.

Grafana MCP로 메트릭을 조회하고, 그 결과를 바탕으로 Helm 차트 values를 수정하고, GitHub MCP로 PR을 열고, Notion MCP로 변경 사항을 문서화하는 게 하나의 세션 안에서 가능합니다. 이건 수동으로 하면 브라우저 탭 5개를 왔다갔다하며 할 일입니다.

에이전트 30개, 모드 7개

커스텀 에이전트를 30개 만들어뒀습니다. 몇 가지 예를 들면,

devops-architect: 인프라 설계, CI/CD 파이프라인
security-engineer: 보안 분석, 위협 모델링
root-cause-analyst: 장애 원인 분석
code-reviewer: 코드 리뷰 (코드 작성 직후 자동으로 돌림)
tdd-guide: 테스트 주도 개발 가이드
planner: 복잡한 기능의 구현 계획 수립

모드는 Brainstorming, Deep Research, Orchestration, Token Efficiency 등 7개. 작업 성격에 따라 Claude의 행동 방식을 바꿉니다.

핵심은 이겁니다. 에이전트와 모드를 잘 조합하면 혼자서도 시니어 엔지니어 여러 명이 리뷰하는 것과 비슷한 효과를 냅니다. 보안 리뷰어가 코드를 보고, 아키텍트가 설계를 검토하고, TDD 가이드가 테스트를 강제하는 식으로요.

이 블로그도 Claude Code로 만들었습니다

이 블로그 자체가 좋은 예시입니다. 이틀간의 작업 로그를 보면,

PageSpeed 최적화 → Lighthouse 100/100/100/100 달성
Lighthouse CI 워크플로우 작성
블로그 글 7편 발행
한국어 OG 이미지 폰트 깨짐 수정 (Noto Sans KR 폴백 추가)
댓글 시스템 교체 (Giscus → Waline → Giscus 복원)
파비콘 교체
Pre-commit 훅 설정

모든 커밋이 Claude Code를 통해 이루어졌습니다. 저는 방향만 잡고 중간중간 확인하고 교정했을 뿐입니다. 지금 읽고 계신 이 글도요.

그래서 한계는?

솔직하게 말합니다. 세 가지가 있습니다.

1. 보안 가드레일 없으면 위험합니다.

규칙 없이 쓰면 회사 코드를 개인 계정의 public 리포지토리에 푸시하려는 짓도 합니다. 실제로 겪었습니다. 그래서 회사 디렉토리에 별도 규칙을 만들어서 조직과 visibility를 강제로 고정시켰습니다. 2,000줄의 규칙이 괜히 있는 게 아닙니다.

시크릿을 하드코딩하거나, IRSA 대신 Access Key를 쓰려 하거나, privileged: true로 컨테이너를 띄우려는 시도는 규칙으로 차단합니다. 규칙이 없으면 편한 길로 갑니다. 편한 길이 보안에선 가장 위험한 길이고요.

2. 세션이 길어지면 맥락을 잃습니다.

긴 세션에서 컨텍스트 유실이 생깁니다. 10개 파일을 수정하라고 하면 8개만 수정하고 끝난 것처럼 말합니다. 자동 컴팩션이 일어나면 이전 결정 사항을 잊기도 합니다. Serena MCP의 프로젝트 메모리가 이걸 어느 정도 보완해주지만, 완벽하진 않습니다.

모델이 진화하면 나아질 수도, 오히려 다른 방식으로 후퇴할 수도 있습니다. 그래서 우리의 역할은 변하지 않습니다. 탄탄한 계획과 아키텍처를 제시하는 것.

3. 지나치게 긍정적입니다.

이게 제일 짜증납니다. “모호하면 반드시 물어봐라”고 아무리 규칙에 적어놔도, 스스로 확신에 차서 진행해버립니다. 물어보는 게 나을 상황에서 추측으로 밀어붙이고, 결과물을 보면 방향이 틀어져 있습니다. 도구를 쓰는 사람이 끊임없이 확인하고 교정해야 하는 이유입니다.

어떻게 쓰면 좋을까

규칙부터 만드세요. CLAUDE.md와 .claude/rules/에 팀의 컨벤션, 보안 정책, 금지 패턴을 전부 적어두세요. 규칙 없는 AI 코딩은 주니어에게 코드 리뷰 없이 프로덕션 배포 권한을 주는 것과 같습니다.
개인과 업무를 분리하세요. 디렉토리 단위로 규칙을 분리하면 회사 코드에 개인 설정이 섞이는 사고를 방지할 수 있습니다.
설계는 직접 하세요. AI에게 “뭘 만들어줘”가 아니라 “이 설계대로 만들어줘”가 되어야 합니다. 설계 능력이 곧 AI 활용 능력이 됩니다.
결과물을 반드시 검증하세요. “다 했습니다”를 믿지 마세요. 빠진 파일이 있는지, 방향이 틀어지진 않았는지, 보안 규칙을 지켰는지 직접 확인해야 합니다.

마치며

Claude Code는 제 업무 방식을 근본적으로 바꿨습니다. IDE를 열지 않고도 인프라를 설계하고, 코드를 작성하고, 테스트하고, 배포하고, 문서화까지 합니다. 하지만 도구일 뿐입니다.

잘 쓰려면 잘 알아야 합니다. 인프라를, 보안을, 아키텍처를. AI가 편한 길로 빠지지 않도록 가드레일을 치는 것도, 결과물의 품질을 판단하는 것도 결국 엔지니어의 몫입니다.

2,000줄의 규칙은 제가 그동안 겪은 실수들의 총합입니다. 여러분도 자신만의 규칙을 만들어가시길 바랍니다.