클로드 코드 창시자는 어떻게 클로드 코드를 쓸까

안녕하세요, AI 커피챗입니다.

요즘 개발자들 사이에서 Claude Code가 뜨겁죠. 그런데 막상 써보려니 "이걸 어떻게 쓰는 게 제대로 쓰는 건지 모르겠어"라는 생각이 드실 겁니다. 당연합니다. 새로운 도구를 손에 쥐었는데 설명서가 없으니까요.

그래서 오늘은 특별한 이야기를 가져왔습니다. 다름 아닌 Claude Code를 직접 만든 보리스가 본인은 어떻게 쓰고 있는지 공개한 내용입니다. "만든 사람이 어떻게 쓰는데?"라는 궁금증, 누구나 한 번쯤 가져보셨을 거예요.

보리스는 글 첫머리에서 의외의 이야기를 합니다. "제 설정은 놀랍도록 평범합니다"라고요. Claude Code는 기본 설정만으로도 충분히 훌륭하게 작동하기 때문에 본인은 별로 커스터마이징을 하지 않는다고 합니다. 오히려 팀원들마다 완전히 다른 방식으로 사용하고 있다고 하네요.

그렇다면 보리스는 구체적으로 어떻게 Claude Code를 활용하고 있을까요? 하나씩 살펴보겠습니다.

동시에 여러 개의 Claude를 돌린다는 것

보리스는 터미널에서 5개의 Claude를 동시에 실행합니다. 탭에 1번부터 5번까지 번호를 매겨놓고, 시스템 알림을 통해 어떤 Claude가 입력을 기다리고 있는지 확인한다고 하네요.

여기서 끝이 아닙니다. 로컬 터미널의 5개 Claude 외에도 claude.ai/code에서 5~10개의 Claude를 추가로 병렬 실행합니다. 터미널에서 코딩하다가 로컬 세션을 웹으로 넘기기도 하고, 크롬에서 수동으로 세션을 시작하기도 하고, --teleport로 왔다갔다하기도 합니다. 심지어 아침에 일어나서나 하루 중간중간 iPhone의 Claude 앱에서 몇 개 세션을 시작해두고 나중에 확인한다고 하네요.

"동시에 10개 넘게 Claude를 돌린다고?" 처음 들으면 좀 과하다 싶으실 수도 있습니다. 하지만 생각해보면 우리도 브라우저 탭을 여러 개 띄워놓고 작업하잖아요. 검색하면서, 문서 보면서, 코드 참고하면서. 보리스는 그걸 Claude로 하고 있는 겁니다.

무조건 Opus 4.5 with thinking

보리스는 모든 작업에 Opus 4.5 with thinking 모드를 사용합니다. 지금까지 써본 코딩 모델 중 최고라고 평가하네요.

흥미로운 건 그 다음 설명입니다. Opus가 Sonnet보다 크고 느린 건 사실이지만, 조종을 덜 해도 되고 도구 사용을 더 잘하기 때문에 결국은 더 빠르다고 합니다. 작은 모델을 쓰면 이것저것 수정하고 다시 돌리고 하느라 시간이 더 걸린다는 얘기죠.

"큰 모델이 느린데 어떻게 더 빠를 수가 있어?" 싶으셨다면, 이건 실제로 써본 사람만이 할 수 있는 통찰입니다. 빠르다는 건 단순히 응답 속도만을 말하는 게 아니거든요. 한 번에 제대로 된 결과를 내는 것, 그게 진짜 빠른 겁니다.

Claude[.]md 라는 팀의 공유 두뇌

보리스의 팀은 Claude Code 레포지토리를 위한 하나의 Claude[.]md 파일을 공유합니다. 이 파일을 git에 체크인해두고, 팀 전체가 일주일에 여러 번 업데이트합니다.

작동 방식은 이렇습니다. Claude가 뭔가 잘못하는 걸 발견하면Claude[.]md에 추가합니다. 그러면 다음번에 Claude는 그걸 하지 않게 되죠. 다른 팀들도 각자의 Claude[.]md를 유지하고 있고, 각 팀이 자기 파일을 최신 상태로 유지할 책임을 진다고 하네요.

더 재미있는 건 코드 리뷰 과정에서 @.claude를 태그해서 Claude[.]md에 뭔가를 추가하기도 한다는 겁니다. Claude Code Github action을 사용해서요. 보리스는 이걸 "Compounding Engineering의 우리 버전"이라고 부릅니다.

생각해보면 이건 정말 똑똑한 방법입니다. Claude는 대화 기록을 기억하지 못하지만, Claude[.]md는 팀의 집단 기억이 되는 거죠. 실수를 반복하지 않도록 학습시키는 시스템입니다.

Plan 모드로 시작한다는 원칙

보리스의 대부분 세션은 Plan 모드(shift+tab 두 번)로 시작합니다. Pull Request를 작성하는 게 목표라면, Plan 모드에서 Claude와 계획에 대해 왔다갔다하면서 만족스러운 계획을 만들어냅니다. 거기서부터 auto-accept edits 모드로 전환하면 Claude가 보통 한 번에 해낸다고 하네요.

좋은 계획은 정말 중요합니다! 이 한 문장에 느낌표까지 붙여놓은 걸 보니 보리스가 얼마나 강조하고 싶어하는지 알 수 있죠.

우리가 프로젝트를 시작할 때도 마찬가지입니다. 설계 없이 바로 코딩 들어가면 나중에 갈아엎게 되잖아요. Claude도 똑같습니다. 먼저 계획을 세우고, 그 계획이 마음에 들면 실행으로 넘어가는 거죠.

Slash Commands로 반복 작업 자동화

보리스는 하루에 여러 번 하는 모든 "내부 루프" 워크플로우에 slash commands를 사용합니다. 반복적인 프롬프팅을 줄이고, Claude도 이 워크플로우를 사용할 수 있게 만들기 위해서죠. 커맨드들은 git에 체크인되어 .claude/commands/에 저장됩니다.

예를 들어, 보리스와 Claude는 /commit-push-pr이라는 slash command를 하루에 수십 번 사용합니다. 이 커맨드는 인라인 bash를 사용해서 git status와 몇 가지 정보를 미리 계산해둡니다. 그래서 모델과 왔다갔다할 필요 없이 빠르게 실행되죠.

"매번 똑같은 걸 입력하는 게 귀찮다"고 느낀 적 있으시죠? 그걸 slash command로 만들어두면 됩니다. 타이핑 한 번으로 복잡한 워크플로우 전체가 실행되는 겁니다.

Subagents와 Hooks로 검증 자동화

보리스는 몇 가지 subagent를 정기적으로 사용합니다. code-simplifier는 Claude가 작업을 마친 후 코드를 단순화하고, verify-app은 Claude Code를 end-to-end로 테스트하는 상세한 지침을 갖고 있습니다. Slash command처럼, subagent도 대부분의 PR에서 하는 가장 흔한 워크플로우를 자동화하는 것으로 생각한다고 하네요.

또한 PostToolUse hook을 사용해서 Claude의 코드를 포맷합니다. Claude가 보통은 잘 포맷된 코드를 생성하지만, 이 hook이 마지막 10%를 처리해서 나중에 CI에서 포맷 에러가 나는 걸 방지하죠.

생각해보면 우리도 작업 후에 "마지막 체크"를 하잖아요. 맞춤법 검사, 린터 돌리기, 테스트 실행. 보리스는 그걸 자동화해둔 겁니다.

권한 관리는 스마트하게

보리스는 --dangerously-skip-permissions를 사용하지 않습니다. 대신 /permissions를 사용해서 자신의 환경에서 안전하다고 아는 일반적인 bash 명령어들을 미리 허용해둡니다. 불필요한 권한 프롬프트를 피하기 위해서죠. 이런 설정들 대부분은 .claude/settings.json에 체크인되어 팀과 공유됩니다.

"매번 권한 물어보는 거 성가시다"고 느끼셨나요? 하지만 그렇다고 모든 권한을 다 열어주는 건 위험하죠. 보리스의 방법은 중간 지점입니다. 안전한 명령어들만 미리 화이트리스트에 넣어두는 거죠.

Claude가 모든 도구를 대신 사용한다

Claude Code는 보리스의 모든 도구를 대신 사용합니다. Slack에서 검색하고 게시하고(MCP 서버 통해), BigQuery 쿼리를 실행해서 분석 질문에 답하고(bq CLI 사용), Sentry에서 에러 로그를 가져오는 등등. Slack MCP 설정은 .mcp.json에 체크인되어 팀과 공유됩니다.

이 부분을 읽으면서 "아, 이게 진짜 AI 시대구나" 싶었습니다. Claude가 단순히 코드만 짜는 게 아니라, 슬랙도 보고, 데이터베이스도 쿼리하고, 에러 로그도 확인하는 거죠. 마치 실제 팀원처럼요.

장시간 작업은 검증 시스템과 함께

매우 오래 걸리는 작업의 경우, 보리스는 세 가지 방법 중 하나를 사용합니다.

(a) Claude에게 작업이 끝나면 백그라운드 에이전트로 자신의 작업을 검증하라고 프롬프트하거나 (b) agent Stop hook을 사용해서 더 결정론적으로 하거나
(c) ralph-wiggum 플러그인을 사용합니다

샌드박스에서는 --permission-mode=dontAsk나 --dangerously-skip-permissions를 사용해서 권한 프롬프트를 피하고, Claude가 보리스의 응답 없이도 작업을 계속할 수 있게 합니다.

오래 걸리는 작업을 맡기고 자리를 비울 때가 있잖아요. 보리스는 그럴 때 Claude가 혼자서도 잘 돌아가게 만들어둔 겁니다.

가장 중요한 팁: 검증 루프

보리스는 마지막으로 가장 중요한 팁을 공유합니다. "Claude Code에서 훌륭한 결과를 얻는 가장 중요한 것은 Claude에게 자신의 작업을 검증할 방법을 주는 것입니다. Claude가 그 피드백 루프를 갖고 있으면, 최종 결과의 품질이 2-3배 향상됩니다."

보리스는 claude.ai/code에 랜딩하는 모든 변경사항을 Claude가 Chrome 확장 프로그램을 사용해서 테스트하게 합니다. 브라우저를 열고, UI를 테스트하고, 코드가 작동하고 UX가 좋다고 느낄 때까지 반복하죠.

검증은 도메인마다 다르게 보입니다. bash 명령어 하나를 실행하는 것만큼 간단할 수도 있고, 테스트 스위트를 실행하거나, 브라우저나 폰 시뮬레이터에서 앱을 테스트하는 것일 수도 있습니다. 이걸 견고하게 만드는 데 투자하는 게 중요합니다.

생각해보면 당연한 이야기입니다. 우리도 코드를 짜고 나면 테스트하잖아요. Claude도 마찬가지입니다. 자기가 만든 걸 직접 확인하고 고칠 수 있게 해주면, 품질이 확 올라가는 거죠.

정리하며

보리스의 활용법을 보면서 느낀 점이 있습니다. 복잡한 설정이나 고급 기법이 아니라, 기본을 제대로 활용하는 게 중요하다는 거죠.

동시에 여러 Claude 돌리기, 좋은 계획 먼저 세우기, 반복 작업 자동화하기, 검증 시스템 만들기. 하나하나 뜯어보면 다 상식적인 이야기입니다. 하지만 이걸 시스템으로 만들어서 팀과 공유하고, 매일 사용하는 것. 그게 차이를 만드는 것 같습니다.

출처: [링크]