저 사실 이 기능 반년 동안 몰랐어요: Claude Code 창시자가 쓰는 실전 워크플로우

Claude Code 만든 사람은 자기 도구를 어떻게 쓸까요? Boris Cherny가 공개한 병렬 세션, CLAUDE.md, 검증 루프 등 13가지 실전 패턴을 분석합니다.

---

저도 이거 반년 동안 몰랐어요

Claude Code 쓰면서 “아 AI 코딩 도구구나” 정도로만 생각했어요.

터미널에서 한 세션 켜놓고, 한 번에 하나씩 작업하고.

그게 정상 아닌가요?

근데 말이죠.

Claude Code를 직접 만든 사람은 완전히 다르게 쓰고 있었어요.

Boris Cherny. Anthropic 엔지니어이자 Claude Code 창시자입니다. 이 사람이 2026년 1월 자신의 워크플로우를 공개했는데, 읽고 나서 진짜 놀랐습니다.

혼자 일하는데 5개 세션을 동시에 돌리고, 팀 문서를 코드처럼 관리하고, AI가 스스로 품질을 검증하게 만들고.

“이거 혼자 하는 건데 왜 이렇게 복잡하게…?” 싶었는데, 읽다 보니 이해가 갔어요.

이건 그냥 도구가 아니라 “운영 체계”였습니다.

솔직히 저도 처음엔 이거 몰랐어요. 반년 동안 Claude Code 쓰면서 기본 기능만 쓰고 있었던 거죠.

근데 Boris의 워크플로우를 하나씩 따라해보니까, 진짜로 혼자인데 팀처럼 일하는 느낌이 들더라고요.

오늘은 그 워크플로우를 하나하나 뜯어봅니다. 그리고 여러분이 오늘 당장 따라할 수 있는 것들만 추려서 알려드릴게요.

---

Boris Cherny 워크플로우란?

Boris Cherny의 워크플로우란? Claude Code 창시자 Boris Cherny가 2026년 1월 공개한 실전 개발 워크플로우로, 병렬 세션 운영, CLAUDE.md 팀 지식 관리, 검증 루프 자동화, Plan 모드 활용, 슬래시 커맨드 및 서브에이전트를 통해 혼자서도 팀 수준의 생산성을 만드는 13가지 패턴을 포함합니다. Anthropic 내부 팀도 동일한 원칙을 사용합니다.

Boris Cherny는 Claude Code 워크플로우를 공개하면서 이렇게 말했어요.

“제가 Claude를 쓰는 방식과 팀이 쓰는 방식은 조금 다릅니다. 정답은 없어요. 여러분도 실험해서 맞는 방식을 찾으세요.”

겸손한 말이지만, 핵심은 하나였습니다.

도구 크기가 아니라, 도구를 다루는 체계의 깊이가 차이를 만든다.

---

왜 이 워크플로우가 중요한가요?

여러분, AI 코딩 도구 쓰면서 이런 경험 있죠?

• 프롬프트 한 번 잘못 쓰면 엉뚱한 코드 나옴
• 고치려다 더 꼬임
• 결국 직접 치는 게 빠름

저도요.

그래서 “AI 코딩은 아직 멀었어”라고 생각했어요.

근데 Boris의 접근은 달랐습니다.

일반적인 접근	Boris의 접근
한 세션, 한 작업	5~15개 세션 병렬
프롬프트에 의존	CLAUDE.md로 지식 축적
결과 확인은 사람	AI가 스스로 검증
반복 작업 매번 타이핑	슬래시 커맨드 자동화

차이가 보이시나요?

Boris는 Claude를 단일 도구가 아니라 팀 시스템으로 운영합니다.

혼자인데 혼자가 아닌 것처럼 일하는 거예요.

---

핵심 원칙 3가지

13가지 팁을 다 외울 필요는 없습니다. 핵심은 딱 세 가지로 압축됩니다.

원칙 1. 병렬화 — 혼자인데 혼자가 아닌 것처럼

Boris는 git worktree 5개를 띄워놓고, 각각에서 Claude Code를 동시에 돌립니다. 거기에 웹 버전으로 5~10개 세션을 추가로 실행합니다.

“왜 이렇게 많이?”

AI가 코드를 생성하는 동안 대기 시간이 있잖아요. 그 시간을 다른 작업으로 채우는 겁니다.

원칙 2. 공유 지식 — CLAUDE.md로 팀의 뇌 만들기

프로젝트 루트에 CLAUDE.md 파일을 하나 만들어서, Claude가 잘못할 때마다 규칙을 추가합니다.

“테스트에서 any 타입 쓰지 말 것” “import는 항상 절대 경로로”

시간이 지나면 프로젝트에 특화된, 살아있는 코딩 가이드가 만들어집니다.

Boris는 이걸 **”복리식 엔지니어링”**이라고 부릅니다.

원칙 3. 검증 루프 — AI가 스스로 품질을 보증하게

Boris가 가장 중요하다고 강조한 팁입니다.

“Claude에게 자신의 작업을 검증할 방법을 제공하세요. 피드백 루프가 있으면 2-3배 품질 향상됩니다.”

Claude가 코드를 작성한 다음, 스스로 그 코드가 맞는지 확인할 수 있어야 한다는 겁니다.

---

1. 병렬 세션 운영: 혼자인데 5명이 일하는 느낌

여러분 Claude Code 하나 켜놓고 한 번에 하나씩 작업하고 계신가요?

Boris는 안 그렇습니다.

VentureBeat 보도에 따르면, Boris는 로컬 터미널에서 5개 세션, 웹에서 5~10개 세션을 병렬로 돌립니다.

git worktree… 뭔 소린지 모르겠죠?

쉽게 말할게요.

하나의 레포지토리에서 여러 브랜치를 동시에 체크아웃할 수 있게 해주는 기능입니다.

보통은 브랜치 전환할 때 stash하고, checkout하고, 다시 돌아오고… 번거롭잖아요. worktree를 쓰면 각 브랜치가 별도 디렉토리에 존재해서, 동시에 여러 작업을 진행할 수 있습니다.

# worktree 만들기
git worktree add ../my-project-feature-auth feature/auth
git worktree add ../my-project-fix-bug fix/critical-bug
git worktree add ../my-project-refactor refactor/database

# 각 디렉토리에서 Claude Code 실행
cd ../my-project-feature-auth && claude &
cd ../my-project-fix-bug && claude &
cd ../my-project-refactor && claude &

이렇게 하면 뭐가 좋으냐.

하나의 세션에서 Claude가 코드를 생성하는 동안, 다른 세션에서는 버그를 고치고, 또 다른 세션에서는 리팩토링을 진행할 수 있습니다.

Boris는 시스템 알림을 설정해서 Claude가 입력을 기다리는 순간을 감지합니다. “아, 3번 세션이 내 입력을 기다리네” 하고 바로 전환하는 거예요.

💬 개인적으로 이 패턴이 가장 충격이었어요. 저는 한 세션만 쓰면서 “AI가 느리네” 하고 기다렸는데, Boris는 그 시간에 다른 작업을 진행하고 있었던 거죠.

---

2. Opus 4.5 + thinking: “느린 게 결국 빠르다”

빠른 모델 쓰면 빠르게 끝나겠지? 라고 생각하기 쉽습니다.

Boris의 생각은 다릅니다.

그는 Opus 4.5 + thinking 모드를 기본으로 고정합니다. 가장 크고, 가장 느린 모델이에요.

왜일까요?

Boris의 설명은 이렇습니다. “더 크고 느리지만, 조향(steering) 부담이 적어서 결과적으로 더 빠르다.”

이게 무슨 뜻이냐면요.

작은 모델을 쓰면 결과물이 살짝 빗나갈 때가 있습니다. 그러면 “아니 이거 말고”, “이 부분은 이렇게 바꿔”, “아까 말한 거 다시 해봐” 같은 추가 프롬프트가 필요하죠.

이 교정 작업에 드는 시간이 생각보다 큽니다.

반면 큰 모델은 한 번에 의도를 더 잘 파악합니다. 교정 횟수가 줄어듭니다. 결국 총 소요 시간은 비슷하거나 오히려 더 짧아지는 거예요.

이걸 운전에 비유하면 이해가 쉽습니다.

핸들을 계속 이리저리 꺾어야 하는 차 vs 한 번 방향 잡으면 쭉 가는 차.

어느 쪽이 덜 피곤하고, 결국 더 빨리 도착할까요?

---

3. CLAUDE.md: 팀의 뇌를 파일 하나에 담기

여러분 팀에 신입이 들어오면 어떻게 하시나요?

온보딩 문서 주고, 코드 컨벤션 알려주고, “우리는 이렇게 해” 라고 설명하잖아요.

Claude Code도 똑같습니다. 다만 그 온보딩 문서가 CLAUDE.md입니다.

Boris는 이 파일을 코드베이스에 체크인해서 관리합니다. 그리고 주 여러 번 업데이트합니다.

핵심 전략은 이겁니다.

Claude가 잘못할 때마다 규칙을 추가한다.

예를 들어 Claude가 테스트 코드에서 any 타입을 남발했다? CLAUDE.md에 “테스트에서도 구체적 타입을 사용할 것”을 추가합니다.

이게 시간이 지나면 어떻게 되느냐.

프로젝트에 특화된, 살아있는 코딩 가이드가 만들어집니다. Claude는 매번 이 파일을 읽고 시작하니까, 같은 실수를 반복하지 않게 됩니다.

진짜 감탄했던 부분은 이겁니다.

팀원이 PR 리뷰에서 @.claude를 태그하면, GitHub Action이 자동으로 그 리뷰 내용을 CLAUDE.md에 추가하고 커밋합니다.

사람이 직접 파일을 편집할 필요도 없는 거예요.

실제 CLAUDE.md는 이런 식입니다.

# CLAUDE.md

## 프로젝트 개요
이 프로젝트는 Next.js 14 + TypeScript + Prisma ORM 기반의 SaaS 대시보드입니다.

## 코드 컨벤션
- import는 항상 절대 경로 사용 (@/components/...)
- 컴포넌트 파일명은 PascalCase
- API 라우트에서는 반드시 zod로 입력 검증
- 테스트에서 any 타입 사용 금지

## 자주 하는 실수 (Claude용)
- ❌ console.log 남기지 말 것
- ❌ prisma.user.findMany()에 take 없이 호출하지 말 것
- ❌ try-catch에서 에러를 삼키지 말 것 (반드시 로깅)

이 파일 하나가 팀의 코딩 문화를 담고 있는 겁니다.

---

4. Plan 모드: 무작정 코딩하지 않기

여러분은 Claude에게 바로 “이거 만들어줘”라고 하시나요?

간단한 작업이라면 그래도 됩니다. 하지만 복잡한 작업에서 그러면 십중팔구 원하는 결과가 안 나옵니다.

Boris의 접근법은 다릅니다.

Shift+Tab을 두 번 누릅니다. 그러면 Plan 모드로 진입합니다.

Plan 모드에서 Claude는 코드를 쓰지 않습니다. 대신 어떻게 구현할 것인지 계획을 세웁니다.

Boris의 워크플로우는 이렇습니다.

1. Plan 모드로 진입 (Shift+Tab × 2)
2. 계획을 검토하고 필요하면 수정 요청
3. 계획이 괜찮으면 자동 수락 모드로 전환
4. Claude가 계획대로 쭉 실행
5. 중간에 방향이 틀어지면? 즉시 Plan 모드로 복귀

이 “재계획 전략”이 중요합니다.

코딩하다가 “이거 아닌데?” 싶으면, 계속 밀어붙이지 말고 바로 멈추세요. Plan 모드로 돌아가서 계획을 다시 세우는 겁니다.

잘못된 방향으로 100줄 쓰는 것보다, 멈추고 10분 재계획하는 게 훨씬 빠릅니다.

---

5. 슬래시 커맨드와 훅: 반복 작업을 자동화하기

매번 같은 프롬프트를 치고 계신가요?

“커밋하고 푸시하고 PR 만들어줘”를 매번 타이핑하는 건 시간 낭비입니다.

Boris는 자주 쓰는 워크플로우를 슬래시 커맨드로 저장합니다.

.claude/commands/ 디렉토리에 마크다운 파일로 넣어두면, Claude Code에서 /커맨드이름으로 바로 실행할 수 있습니다.

# .claude/commands/commit-push-pr.md

현재 변경사항을 검토하고 다음을 수행하세요:

1. 변경 내용을 분석해서 커밋 메시지를 작성합니다
2. git add && git commit
3. 현재 브랜치를 push
4. gh pr create로 PR 생성
   - PR 제목은 커밋 메시지 기반
   - PR 본문에 변경 요약 포함

그리고 PostToolUse 훅도 씁니다.

// .claude/settings.json 내 hooks 설정 예시
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "command": "npx prettier --write $CLAUDE_FILE_PATH"
      }
    ]
  }
}

Claude가 파일을 쓰거나 수정할 때마다, 자동으로 Prettier가 돌아갑니다.

CI에서 “포맷팅 안 맞음” 하면서 실패하는 그 짜증나는 상황을 원천 차단하는 거예요.

---

6. 서브에이전트: AI 팀원을 여러 명 두기

Claude Code 하나가 만능일 수 있을까요?

솔직히 힘듭니다. 코드 작성, 리뷰, 테스트, 리팩토링… 각각 다른 관점이 필요한 작업들이잖아요.

Boris는 서브에이전트를 만들어 씁니다.

.claude/agents/ 디렉토리에 역할별 에이전트를 정의해두는 거예요.

# .claude/agents/code-simplifier.md

당신은 코드 단순화 전문가입니다.

## 역할
복잡한 코드를 더 읽기 쉽고 유지보수하기 좋은 형태로 리팩토링합니다.

## 원칙
- 동작은 유지하면서 복잡도를 줄일 것
- 중첩 if문 → early return 패턴
- 긴 함수 → 작은 함수로 분리

Boris는 Claude에게 이렇게 말합니다. “5개 서브에이전트로 코드베이스를 탐색해줘.”

그러면 Claude가 각 에이전트를 병렬로 실행해서 코드베이스의 서로 다른 측면을 동시에 분석합니다.

혼자 일하는 건데, 코드 리뷰를 5명이 동시에 해주는 느낌입니다.

---

7. 검증 루프: Boris가 뽑은 #1 팁

13가지 워크플로우 중에서 Boris가 가장 중요하다고 강조한 게 뭐였을까요?

병렬 세션? 아닙니다. CLAUDE.md? 아닙니다.

검증 루프입니다.

Boris의 원문을 직역하면 이렇습니다.

“가장 중요한 것은 Claude에게 자신의 작업을 검증할 방법을 제공하는 것입니다. 피드백 루프가 있으면 2-3배 품질 향상이 됩니다.”

이게 뭔 소리냐고요?

Claude가 코드를 작성한 다음, 스스로 그 코드가 맞는지 확인할 수 있어야 한다는 겁니다.

예를 들어볼게요.

검증 루프 없는 경우:

1. Claude가 함수 작성
2. 개발자가 눈으로 확인
3. “이거 틀렸어” 피드백
4. Claude가 수정
5. 또 확인… 반복

검증 루프 있는 경우:

1. Claude가 함수 작성
2. Claude가 직접 테스트 실행
3. 실패하면 스스로 수정
4. 통과할 때까지 반복
5. 개발자에게 “다 됐습니다” 보고

차이가 보이시나요?

검증 루프가 있으면 사람이 중간에 개입할 필요가 줄어듭니다. Claude가 알아서 품질을 보장하니까요.

구체적으로 어떻게 구현하느냐.

# 프롬프트에 검증 루프를 명시하는 방법

"이 API 엔드포인트를 구현해줘.
구현 후 반드시 다음을 확인해:
1. tsc --noEmit으로 타입 에러 없는지
2. vitest run으로 관련 테스트 통과하는지
3. curl로 실제 요청 보내서 응답 확인
문제가 있으면 스스로 수정하고, 모두 통과할 때까지 반복해."

이게 왜 중요하냐면요.

AI 코딩 도구의 가장 큰 문제가 뭔지 아시나요? **”그럴듯하지만 틀린 코드”**를 만든다는 겁니다.

검증 루프는 이 문제를 구조적으로 해결합니다.

---

8. 권한 관리: 안전하게, 그리고 똑똑하게

Claude Code에서 매번 “이 명령 실행해도 되나요?” 물어보는 거 귀찮지 않으세요?

그렇다고 --dangerously-skip-permissions를 쓰면… 이름부터 위험하잖아요.

Boris는 /permissions 명령으로 안전한 명령어를 사전에 허용 목록에 등록합니다.

// .claude/settings.json
{
  "permissions": {
    "allow": [
      "Bash(bun run build:*)",
      "Bash(bun run test:*)",
      "Bash(git add *)",
      "Bash(git commit *)",
      "Bash(git push *)"
    ]
  }
}

빌드, 테스트, git 작업은 물어보지 않고 바로 실행합니다. 하지만 rm -rf 같은 위험한 명령은 여전히 확인을 거칩니다.

---

9. 프롬프팅의 기술: Boris가 실제로 치는 말들

같은 도구를 써도 결과물이 다른 이유가 뭘까요?

프롬프트 때문입니다.

Boris가 실제로 사용하는 프롬프트 패턴 세 가지를 소개합니다.

패턴 1: 까다로운 리뷰어 모드

"이 변경사항을 검토하면서 합격하기 전까지 나를 괴롭혀줄래?"

이렇게 하면 Claude가 “네, 좋습니다~” 하고 넘어가지 않습니다. 진짜로 문제점을 찾아내고, 엣지 케이스를 지적하고, 개선안을 제시합니다.

패턴 2: 클린 슬레이트

"처음부터 새로 구현해."

기존 코드를 수정하다가 꼬일 때 쓰는 패턴입니다. Claude가 기존 구현에 끌려가지 않고, 요구사항만 보고 처음부터 깔끔하게 작성합니다.

패턴 3: 상세 명세

모호성을 제거하는 겁니다.

“인증 미들웨어 만들어줘”라고 하면 Claude가 알아서 판단해야 할 게 많아지잖아요. 그 판단이 여러분의 기대와 다를 수 있습니다.

상세하게 명세를 주면, 결과물이 기대에 훨씬 가까워집니다.

---

오늘 당장 따라하기: 초보자용 3단계

여기까지 읽으셨으면 이런 생각이 드실 수 있습니다.

“다 좋은데, 나는 어디서부터 시작하지?”

13가지를 한꺼번에 다 적용하려고 하지 마세요. 오늘 당장 할 수 있는 최소 세트 3가지만 알려드리겠습니다.

Step 1: CLAUDE.md 만들기 (5분)

프로젝트 루트에 CLAUDE.md 파일을 하나 만드세요. 처음엔 간단하게 시작합니다.

# CLAUDE.md

## 프로젝트
- [프로젝트 이름]: [한 줄 설명]
- 기술 스택: [예: Next.js, TypeScript, Prisma]

## 규칙
- [프로젝트에서 중요한 규칙 1]
- [프로젝트에서 중요한 규칙 2]

## Claude가 자주 하는 실수
- (아직 없음 - Claude와 작업하면서 채워나갈 것)

“Claude가 자주 하는 실수” 섹션이 핵심입니다. 작업하다가 Claude가 실수할 때마다 여기에 추가하세요.

Step 2: 첫 슬래시 커맨드 만들기 (3분)

가장 자주 반복하는 작업 하나를 골라서 슬래시 커맨드로 만드세요.

mkdir -p .claude/commands

# .claude/commands/review.md

현재 staged된 변경사항을 검토해줘.

확인 사항:
1. 타입 안전성
2. 에러 처리 누락
3. 엣지 케이스

문제가 있으면 구체적으로 지적하고 수정안을 제시해.

이제 Claude Code에서 /review만 치면 됩니다.

Step 3: 검증 루프 습관 들이기 (0분, 습관만 바꾸면 됨)

앞으로 Claude에게 코드를 시킬 때, 프롬프트 끝에 이 한 문장을 추가하세요.

"구현 후 테스트를 실행해서 통과하는지 확인하고,
실패하면 스스로 수정해."

이것만 추가해도 결과물 품질이 확 달라집니다.

---

Boris 워크플로우 한눈에 보기

워크플로우	핵심	난이도
병렬 세션	git worktree + 동시 실행	중
Opus + thinking	조향 부담 감소	하
CLAUDE.md	복리식 규칙 축적	하
Plan 모드	계획 → 실행 → 재계획	하
슬래시 커맨드	반복 작업 자동화	하
서브에이전트	역할별 AI 팀원	중
PostToolUse 훅	자동 포맷팅/검증	중
권한 관리	안전한 자동 실행	하
검증 루프	자가 품질 보장	하
프롬프팅 기법	까다로운 리뷰어, 클린 슬레이트	하

---

내가 느낀 점

Boris의 워크플로우를 보면서 한 가지 깨달은 게 있습니다.

이건 Claude Code 기능 소개가 아니었습니다. 개발 철학이었어요.

모델이 아무리 똑똑해져도, 그걸 어떤 체계 안에서 쓰느냐가 결과를 결정합니다.

검증 루프 없이 최신 모델을 쓰는 것보다, 검증 루프를 갖추고 약간 느린 모델을 쓰는 게 더 나은 결과를 만듭니다.

혼자서 하나의 세션만 쓰는 것보다, CLAUDE.md로 지식을 축적하면서 여러 세션을 돌리는 게 훨씬 높은 생산성을 만들고요.

도구의 크기가 아니라, 도구를 다루는 체계의 깊이가 차이를 만든다.

---

솔직한 마음

솔직히 처음엔 좀 무서웠습니다.

“AI가 이렇게까지 할 수 있구나” 하는 생각과 동시에, “그럼 내 가치는 뭐지?” 하는 불안도 들었어요.

근데 Boris의 워크플로우를 따라해보면서 깨달았습니다.

AI 도구가 똑똑해질수록, 그걸 운영하는 체계가 더 중요해진다는 걸요.

병렬 세션을 어떻게 배치할지, CLAUDE.md에 무엇을 기록할지, 검증 루프를 어떻게 설계할지.

이 모든 건 사람의 판단입니다.

불안하지만 방향은 찾았습니다.

AI를 잘 쓰는 사람이 되려면, 도구 자체보다 운영 체계를 설계하는 능력을 키워야 한다는 거요.

---

앞으로 내가 할 것들

1. CLAUDE.md 작성 시작: 오늘 당장 현재 프로젝트에 추가
2. 첫 슬래시 커맨드 만들기: /review 커맨드부터
3. 검증 루프 습관화: 모든 프롬프트에 “테스트 돌려보고 확인해” 추가
4. git worktree 실험: 2개부터 시작 (메인 작업 + 테스트)
5. 한 달 후 되돌아보기: 생산성 변화 측정

여러분도 한번 시도해보세요.

처음에는 번거로워 보여도, 일주일만 해보면 확실히 차이가 느껴집니다.

---

FAQ (자주 묻는 질문)

Q: CLAUDE.md는 어디에 저장하나요?

A: 프로젝트 루트 디렉토리에 CLAUDE.md 파일을 생성하세요. git에 체크인해서 팀원들과 공유합니다. 2026년 2월 기준 Claude Code는 프로젝트 시작 시 이 파일을 자동으로 읽습니다.

Q: git worktree vs 일반 브랜치 전환, 뭐가 다른가요?

A: 일반 브랜치 전환은 한 디렉토리에서 브랜치만 바뀌지만, git worktree는 각 브랜치가 별도 디렉토리에 존재합니다. 따라서 여러 브랜치에서 동시에 작업할 수 있고, 각 디렉토리에서 Claude Code 세션을 병렬로 실행할 수 있습니다.

Q: Opus 4.5가 비싼데 정말 써야 하나요?

A: Boris는 “조향 부담이 적어 결과적으로 더 빠르다”고 말했지만, 비용이 부담된다면 핵심 설계에는 Opus, 단순 작업에는 Sonnet으로 나누세요. 검증 루프만 제대로 갖춰도 작은 모델로도 충분히 좋은 결과를 얻을 수 있습니다.

Q: 슬래시 커맨드를 너무 많이 만들면 안 좋나요?

A: Shipyard 가이드에 따르면, 복잡한 커스텀 커맨드를 많이 만드는 것은 anti-pattern입니다. Claude의 장점은 자유로운 대화인데, 커맨드가 너무 많으면 오히려 복잡해집니다. 진짜 자주 쓰는 3-5개만 만드세요.

---

결론

좋은 소식은, 이 체계를 만드는 데 거창한 준비가 필요 없다는 겁니다.

오늘 CLAUDE.md 하나 만드세요. 프롬프트 끝에 “테스트 돌려보고 확인해” 한 문장 추가하세요. 자주 쓰는 작업 하나를 슬래시 커맨드로 만드세요.

이 세 가지만으로도, 내일의 여러분은 오늘보다 확실히 더 효율적으로 코딩하게 될 겁니다.

혼자서 팀처럼 코딩하는 게 진짜 가능하냐고요?

Boris가 매일 증명하고 있습니다.

---

참고 자료

• Inside the Development Workflow of Claude Code’s Creator – InfoQ
• The creator of Claude Code just revealed his workflow – VentureBeat
• The Claude Code team just revealed their setup – Dev Genius
• Claude Code CLI Cheatsheet – Shipyard
• Best Practices for Claude Code – Claude Code Docs

🏷️ 태그: #ClaudeCode #AI코딩 #워크플로우 #생산성 #개발도구