Claude Code 제작자 Boris Cherny의 13가지 사용 팁

작성 2026년 1월 4일

Claude Code를 잘 쓰는 방법을 찾다 보면 모델, 명령어, 서브에이전트 목록이 먼저 눈에 들어옵니다. 하지만 Boris Cherny의 사용 팁에서 가져올 핵심은 작업을 나누고, 필요한 문맥을 주고, 결과를 확인할 수 있게 만드는 흐름이라고 봅니다.

이 글은 2026년 1월 초 공유된 13가지 팁의 주제를 정리하고 제 적용 기준을 덧붙였습니다. 당시 모델명과 세션 수는 개인의 운영 사례입니다. 명령과 설정 설명은 2026년 9월 12일 확인한 공식 문서로 보완했으며, 예전 스크린샷과 현재 UI는 다를 수 있습니다.

먼저 무엇이 불편한지 고르기

13가지를 모두 적용할 필요는 없습니다. 자주 발생하는 비용부터 줄이는 편이 좋겠습니다.

지금 겪는 문제	먼저 시도할 변화	좋아졌는지 볼 기준
구현 후 요구사항이 달랐음을 발견	짧은 계획과 완료 조건	재작업량
그럴듯하지만 동작하지 않는 결과	실행 가능한 검증 방법	같은 오류의 재발과 수정 횟수
같은 프로젝트 설명을 반복	짧은 CLAUDE.md	반복 설명의 감소
매번 같은 절차를 지시	재사용 명령 또는 skill	지시 누락과 관리 비용
긴 독립 작업 때문에 기다림	별도 작업 공간의 병렬 세션	통합까지 포함한 완료 시간

이 표의 순서는 고정된 성숙도 단계가 아닙니다. 작고 명확한 변경이라면 계획·에이전트·새 규칙을 모두 추가하지 않아도 됩니다.

1. 터미널 병렬 세션: 개수보다 경계

Boris가 소개한 운영 방식에는 번호를 붙인 여러 터미널 세션과 알림이 있습니다. 대기 중인 작업을 병렬로 진행하고, 사람이 필요한 시점에 돌아오는 방식입니다.

제 적용 기준은 세션마다 목표, 수정 범위, 완료 조건을 나누는 것입니다. 같은 파일을 동시에 편집하면 빠른 생성 뒤에 충돌 정리 비용이 붙습니다. 독립적인 구현은 별도 브랜치·worktree에서 진행하고, 같은 변경의 리뷰는 읽기만 맡기는 식으로 경계를 정할 수 있습니다.

세션을 더 늘릴지는 “몇 개까지 실행 가능한가”보다 결과를 검토하고 통합할 여유가 있는지로 판단하겠습니다. 공식 문서의 병렬 작업 안내

2. 웹과 터미널 연결: 문맥뿐 아니라 브랜치도 확인

웹에서 작업을 시작하고 터미널에서 이어가는 흐름도 소개됐습니다. 현재 문서에서는 claude --teleport로 웹 세션을 가져오는 방법을 설명합니다.

당시 웹 세션 운영 예시

이 동작은 대화만 복사하는 것으로 생각하면 안 됩니다. 문서는 해당 저장소의 브랜치를 가져와 체크아웃하며, 같은 저장소·계정과 정리된 작업 상태 등이 필요하다고 설명합니다. 이동 전에는 현재 변경 사항과 가져올 브랜치를 확인해야 합니다. 웹에서 터미널로 이어가기

첫 메시지에는 나중에 돌아와도 이해할 수 있도록 산출물과 완료 조건을 남기는 편이 좋겠습니다. 예를 들어 “로그인 오류 조사”보다 “실패 요청의 공통 조건을 찾고, 재현 방법과 수정 후보를 정리”가 회수하기 쉽습니다.

3. 모델 선택: 응답 한 번보다 완료까지의 비용

당시 팁에서 언급된 기본 조합은 Opus 4.5와 thinking입니다. 이 모델명을 현재의 보편적인 추천값으로 받아들일 필요는 없습니다.

실무에서 비교할 것은 첫 응답 속도뿐 아니라 수정 왕복, 검토 시간, 사용 비용입니다. 큰 모델이 한 번에 끝내는 작업도 있고, 간단한 작업에서는 작은 모델로 충분할 수 있습니다. 팀의 대표 작업 몇 개를 같은 완료 조건으로 비교하는 편이 모델 순위를 그대로 따르는 것보다 낫습니다.

이 글에는 모델 간 직접 측정값이 없습니다. 특정 모델이 항상 더 빠르거나 경제적이라는 결론은 내리지 않겠습니다.

4. CLAUDE.md: 계속 추가하기보다 필요한 문맥만 유지

공용 CLAUDE.md를 Git에 넣어 팀이 함께 유지하는 것은 반복 설명을 줄이는 방법입니다.

팀이 공유한 프로젝트 지침의 예시

적을 만한 내용은 코드만 읽어서는 알기 어려운 프로젝트 제약, 실제 검증 명령, 자주 틀리는 중요한 경계입니다. 기본 언어 문법이나 파일별 설명을 길게 복제할 필요는 없습니다. 공식 문서도 짧게 유지하고, 가끔 필요한 절차는 skill 등으로 분리할 것을 권합니다. 효과적인 CLAUDE.md

예를 들어 “좋은 코드를 작성하라”보다 “이 API의 날짜는 UTC로 보내며, 화면에서만 사용자 시간대로 변환한다”가 더 구체적입니다. 단, 실제 프로젝트에 그런 계약이 있을 때만 적어야 합니다.

5. 리뷰에서 규칙 갱신: 사건 하나를 영구 규칙으로 만들지 않기

리뷰 중 발견한 중요한 제약을 공용 지침에 반영하면 같은 설명을 줄일 수 있습니다. 당시에는 GitHub Action에서 @claude로 규칙 갱신을 요청하는 흐름도 소개됐습니다.

코드리뷰에서 공용 문서 갱신을 요청하는 흐름

다만 실수할 때마다 문장을 추가하면 지침이 사고 기록장으로 변합니다. 제 기준은 “여러 작업에 다시 적용되는가, 코드나 자동 검사로 표현하기 어려운가”입니다. 포맷은 포맷터로, 타입 제약은 타입으로 표현하고, 문서에는 그 밖의 판단에 필요한 맥락을 남기겠습니다.

6. Plan mode: 길이가 아니라 잘못된 구현을 줄이는가

계획이 유용한 경우는 요구사항이 불명확하거나, 여러 파일·도메인에 걸치거나, 구현 선택의 영향이 큰 작업입니다.

실행 전에 목표와 접근을 정리하는 단계

다음 네 항목이 보이면 충분한 출발점이 됩니다.

바꾸려는 사용자 동작과 완료 조건.
현재 코드에서 확인한 원인 또는 아직 확인할 가설.
변경할 범위와 의존 관계.
동작을 확인할 방법과 실패 시 복구 경로.

계획의 가설이 틀렸다면 구현 중에 수정해야 합니다. 한 번 승인한 계획을 끝까지 고수하는 것이 목적은 아닙니다. 단순 오탈자처럼 범위가 명확한 작업에서는 별도 계획이 오히려 비용일 수 있습니다. 탐색·계획·구현의 구분

7. 반복 명령: 익숙한 절차가 생긴 뒤 자동화

당시에는 .claude/commands/에 slash command를 두는 방법이 소개됐습니다. 현재 공식 문서에서는 custom command가 skill 체계로 통합됐다고 설명합니다. 기존 command 파일도 동작하며, 새 skill은 .claude/skills/<이름>/SKILL.md 형태로 둘 수 있습니다. Skills 공식 문서

자동화할 내용은 반복해서 성공한 작은 절차부터 고르는 편이 좋겠습니다. 예를 들어 “변경 내용 요약 → 관련 검증 → PR 본문 작성”은 입력과 결과가 비교적 명확합니다. 커밋·푸시·배포까지 포함한다면 어느 저장소와 브랜치에서 어떤 권한으로 실행할지까지 절차에 포함해야 합니다.

자동화가 매번 예외 설명을 더 요구한다면, 아직 절차가 충분히 안정되지 않았다는 신호일 수 있습니다.

8. 서브에이전트: 독립적으로 끝낼 수 있는 일을 맡기기

code-simplifier, verify-app 같은 이름보다 중요한 것은 별도 문맥에서 어떤 결과를 돌려줄지입니다. skill은 재사용 지식·절차를 담을 수 있고, subagent는 별도 문맥과 도구 설정을 가진 실행 단위입니다. 서로 대체해야 하는 개념은 아닙니다. Subagents 공식 문서

읽을 파일이 많은 오류 조사, 특정 범위의 읽기 전용 리뷰, 독립적인 UI 검증은 분리하기 좋습니다. 반면 두 에이전트가 같은 요구사항을 서로 다르게 구현하거나, 같은 파일을 계속 고쳐야 한다면 통합 비용이 커집니다.

위임할 때는 “검토해”보다 “권한 검사 누락을 찾고, 파일 위치·발생 조건·사용자 영향을 보고하라”처럼 결과의 형태를 지정할 수 있습니다. 제안 개수가 많다는 이유로 모두 적용할 필요는 없습니다.

9. PostToolUse hook: 포맷 실패를 숨기지 않기

수정 도구 실행 후 포맷터를 돌리는 hook은 반복적인 서식 정리를 자동화할 수 있습니다.

도구 실행 후 후처리를 연결한 예시

다만 모든 도구 호출마다 저장소 전체를 포맷하면 지연과 불필요한 변경이 늘 수 있습니다. 관련 수정 도구에만 연결하고 변경 파일을 대상으로 실행하는 편이 낫습니다. 파일 경로를 쉘 명령에 넘길 때도 공백과 특수문자를 안전하게 처리해야 합니다.

특히 실패를 일괄적으로 || true로 덮으면 포맷터가 고장 나도 성공처럼 보일 수 있습니다. 실패 원인을 남기고 모델이 확인할 수 있게 하되, 최종 검증에서도 포맷 상태를 확인해야 합니다. PostToolUse는 도구 실행 후이므로 이미 일어난 변경을 막는 장치도 아닙니다. Hooks의 동작과 반환 규칙

10. Permissions: 명령의 이름보다 실제 효과

반복적인 확인을 줄이려면 검토한 작업을 사전 허용할 수 있습니다. /permissions와 팀 설정은 그 범위를 관리하는 수단입니다.

당시 사전 허용 설정 화면

git status 같은 조회와 배포·데이터 삭제·외부 게시의 효과는 다릅니다. 테스트나 린트도 결국 저장소의 코드를 실행하므로, 이름만 보고 어디서나 무해하다고 판단해서는 안 됩니다. 신뢰하는 프로젝트의 실제 명령과 필요한 권한 범위를 확인해야 합니다.

dontAsk도 구분해야 합니다. 현재 문서에 따르면 이 모드는 원래 물어봐야 할 요청을 자동 거부합니다. 사전 허용되거나 승인이 필요 없는 동작은 실행되지만, 모든 동작을 무조건 허용하는 옵션은 아닙니다. Permissions 공식 문서

11. MCP: 연결 수보다 필요한 정보까지의 거리

로그, 이슈, 분석 데이터 등 작업의 근거가 외부 도구에 있다면 MCP 연동이 도움이 될 수 있습니다. 당시에는 Slack, Sentry, BigQuery 같은 도구와의 연결이 소개됐습니다.

제 적용 순서는 작업에 필요한 읽기 경로를 먼저 열고, 이후 실제로 반복하는 쓰기 작업을 검토하는 것입니다. 로그 조회를 위해 메시지 발송 권한까지 넓힐 이유는 없습니다. .mcp.json 등 공유 설정에는 연결 구조를 남기고 인증정보는 해당 시스템의 인증 방식으로 관리해야 합니다.

연동 도구가 많아도 필요한 근거를 찾기 어렵다면 목적을 달성한 것이 아닙니다. “오류를 발견했을 때 관련 요청과 배포를 확인할 수 있는가”처럼 구체적인 업무 흐름으로 평가하겠습니다. 공식 문서의 MCP 안내

12. 장기 작업: 계속 실행하는 조건만큼 멈출 조건

백그라운드 검증이나 Stop hook은 한 번의 응답 뒤에도 작업이 이어지도록 만들 수 있습니다. 하지만 계속 시도하는 것과 진전이 있는 것은 다릅니다.

장기 작업에는 성공 조건, 검증 명령, 시간·비용 상한, 같은 실패가 반복될 때 보고할 내용을 정하는 편이 좋겠습니다. 외부 권한 부족이나 실패하는 환경 설정을 코드 수정으로 해결하려 하면 반복할수록 결과가 나빠질 수 있습니다.

Stop hook을 직접 만든다면 재진입 상태를 확인해야 합니다. 공식 문서는 stop_hook_active를 확인해 끝나지 않는 조건으로 계속 막지 않도록 설명합니다. Stop hook

13. 검증 루프: 모델의 확신을 동작 증거로 바꾸기

이 13개 중 가장 먼저 적용하고 싶은 항목입니다. “잘 작동하게 해”보다 실제 실행 방법과 성공 기준을 주는 편이 결과를 확인하기 쉽습니다.

예를 들어 프론트엔드의 저장 기능을 수정한다면 다음과 같은 기준을 줄 수 있습니다. 이는 특정 프로젝트의 실행 결과가 아니라 요청 작성 예시입니다.

목표: 저장 실패 후 사용자가 입력을 잃지 않고 다시 시도할 수 있게 한다.
현재 재현: 저장 API가 실패하면 입력창이 초기화된다.
검증: 실패 응답에서는 입력 유지와 오류 안내,
      성공 응답에서는 저장 결과 표시를 확인한다.
완료 보고: 변경한 동작, 실제 실행한 검증, 확인하지 못한 조건을 남긴다.

빌드·타입 검사 통과와 사용자 동작 검증은 다른 근거입니다. UI 변경이면 브라우저에서 해당 상태를 확인하고, 회귀 위험이 있는 로직이면 그 위험을 겨냥한 검증을 붙이는 편이 좋습니다. 사소한 문구 변경에 광범위한 테스트를 새로 만드는 것이 목적은 아닙니다. 검증 방법 제공하기

제일 작은 변화 하나부터

당장 적용한다면 다음 작업에 완료 조건과 실행 가능한 검증 방법을 먼저 적겠습니다. 이후 같은 문맥을 계속 설명해야 할 때 지침을, 같은 절차를 계속 지시해야 할 때 자동화를, 독립적인 대기 시간이 커질 때 병렬 작업을 추가하겠습니다.

효과는 세션 수나 자동 생성한 코드량보다 검토·통합까지 끝난 시간, 재작업, 놓친 결함으로 확인하는 편이 낫습니다. 잘 맞는 설정은 화려한 도구 목록이 아니라, 우리 작업에서 반복되는 비용을 줄여주는 설정일 테니까요.