Claude Code 만든 사람은 이렇게 씁니다

Claude Code 만든 사람이 직접 쓰는 법을 공개했습니다. Boris Cherny. Claude Code 창시자요. 이 사람이 트위터에 10가지 팁을 쭉 올렸는데, 조회수가 830만을 넘겼어요. 근데 그냥 팁 목록이 아니에요. Claude Code 팀 내부에서 실제로 쓰는 방식을 공개한 거예요. 팀원들이 각자 어떻게 쓰는지, 어떤 세팅을 하는지, 어떤 습관이 있는지를 날것 그대로 보여줬어요.

저는 읽으면서 좀 놀랐습니다. 왜냐하면 저도 똑같이 하고 있는 것들이 많았거든요. 근데 동시에 "아, 이건 나도 안 해봤는데?" 싶은 것도 있었어요. 도구를 만든 팀이니까 당연히 저보다 한 발 앞서 있는 부분이 있잖아요.

근데 원문을 그대로 전달하면 의미가 없잖아요. 10개 팁을 1번부터 10번까지 나열하면 "아 그렇구나" 하고 끝이에요. 그래서 오늘은 Boris의 10가지 팁을 제 현업 경험 기준으로 3가지 카테고리로 재분류했습니다. 같은 재료인데 요리법이 다른 거예요.

코딩 환경 세팅

왜 "만든 팀"의 사용법이 중요한가

Claude Code 관련 팁은 인터넷에 넘쳐나요. 유튜브에 "Claude Code tutorial" 치면 수백 개가 나오고, 트위터에서도 매일 누군가 "내가 쓰는 법"을 올려요. 근데 대부분 외부 사용자의 경험이에요. 도구를 받아서 써본 사람들의 이야기죠.

Boris의 글은 다릅니다. 도구를 만든 팀의 이야기예요. 기능을 직접 설계하고, 왜 이렇게 동작하는지를 아는 사람들이 "우리는 이렇게 쓴다"고 말하는 거예요.

비유를 하나 할게요. 자동차를 사면 매뉴얼이 있잖아요. 근데 그 차를 설계한 엔지니어가 "나는 이 차를 이렇게 운전한다"고 말하면 차원이 다르거든요. 서스펜션 세팅을 왜 그렇게 했는지 아니까, 어떤 도로에서 어떻게 달려야 하는지를 설계 의도에 맞게 알려줄 수 있는 거예요.

근데 Boris가 글 첫머리에서 이런 말을 해요:

이게 솔직하고 좋아요. "우리가 정답이다"가 아니라 "우리도 각자 다르다"는 거잖아요. 그래서 오늘 글에서도 Boris 팀의 방식을 그대로 따라 하라는 게 아니라, 여러분 상황에 맞게 골라 쓸 수 있도록 정리했어요.

제가 분류한 3가지 카테고리

원문은 10개 팁인데, 저는 이걸 실무에서 쓰는 순서 기준으로 묶었어요.

하나씩 깊이 들어가볼게요.

시키기 전에 설계하라

Plan Mode를 빼면 Claude Code를 절반만 쓰는 거예요

Boris 팀에서 모든 복잡한 작업은 Plan Mode로 시작한다고 해요. 계획 수립에 에너지를 쏟아서 Claude가 한 번에 구현을 끝내도록 유도하는 거예요.

여기까지는 저도 같아요. 제 강의 Ch3에서 가르치는 핵심이 정확히 이거거든요. "탐색 → 설계 → 구현 → 커밋." 설계를 건너뛰고 바로 "만들어줘"라고 하면 AI가 교과서적인 코드를 뱉어요. 그리고 교과서적인 코드는 현실에서 거의 안 맞아요.

근데 Boris 팀에서 하는 방식 중에 저도 안 해본 게 하나 있어요.

이거 미쳤어요. Plan Mode에서 나온 설계를 다른 세션의 Claude한테 시니어 리뷰어로 검토시키는 거예요. "이 설계에 허점이 있어?" "이 접근법의 리스크는 뭐야?" 이런 걸 물어보는 거죠. 한 세션이 만든 계획을 다른 세션이 까는 겁니다.

제 첫 번째 뉴스레터에서 Writer/Reviewer 패턴을 다뤘는데요. 그때는 구현과 테스트를 분리하는 패턴이었어요. Boris 팀은 그걸 한 단계 앞으로 당긴 거예요. 설계와 설계 리뷰를 분리한 거죠. 구현 전에 설계 자체의 품질을 높이는 거예요.

그리고 또 하나 중요한 팁:

이건 제가 현업에서 수없이 겪은 거예요. AI가 구현하다 삐끗하면 "고쳐봐" "다시 해봐" 하면서 채팅을 쌓잖아요. 근데 이렇게 하면 갈수록 결과가 나빠져요. 컨텍스트 윈도우가 삽질한 내용으로 오염되니까요.

그냥 Plan Mode로 돌아가세요. "잠깐. 지금 뭐가 잘못됐는지 분석하고, 새로운 계획을 세워."라고 하면 됩니다. 이게 직관에 반하거든요. "지금까지 한 게 아까운데..." 싶잖아요. 근데 오염된 컨텍스트에서 계속 밀어붙이는 게 진짜 시간 낭비예요.

CLAUDE.md는 AI가 직접 쓰게 하세요

이전 뉴스레터에서 CLAUDE.md 이야기를 많이 했는데요. 짧게 유지해야 한다, 핵심 제약조건만 담아야 한다, 이런 얘기를요.

Boris 팀의 팁은 한 단계 더 나가요:

이건 지난 뉴스레터에서 다뤘던 Mitchell Hashimoto의 "하네스 엔지니어링"과 정확히 같은 접근이에요. AI가 실수하면, 그 실수를 시스템으로 막아라. 근데 Boris 팀은 여기서 AI한테 직접 규칙을 쓰게 하는 거예요.

이유가 있어요. 사람이 규칙을 쓰면 추상적으로 쓰게 돼요. "코드 스타일을 일관되게 유지하라." 이러면 AI가 해석의 여지가 너무 많아요. 근데 AI가 직접 자기가 한 실수를 기반으로 규칙을 쓰면 구체적이에요. "import 순서는 외부 라이브러리 → 내부 모듈 → 상대 경로 순으로 작성하라." 이런 식으로요.

솔직히 이건 좀 소름이에요. AI가 자기한테 적용할 규칙을 자기가 쓴다는 거잖아요. Boris 표현을 빌리면 "eerily good" — "섬뜩할 정도로 잘한다"고 해요. 실제로 해보면 진짜 그래요. AI가 자기 실수 패턴을 분석하고, 꽤 정확한 규칙을 만들어내요.

그리고 Boris 팀 엔지니어 중 한 명은 이런 시스템을 운영해요:

이건 CLAUDE.md의 확장판이에요. CLAUDE.md 자체는 짧게 유지하면서, 상세한 맥락은 별도 파일에 두고 참조하게 하는 거예요. 제 강의 Ch2에서 "CLAUDE.md는 짧게 유지하라"고 했는데, 이 방식이면 짧게 유지하면서도 풍부한 컨텍스트를 줄 수 있어요.

프롬프트 수준을 끌어올리는 구체적인 방법

Boris 팀이 실제로 쓰는 프롬프트 패턴 몇 가지가 있는데, 이건 바로 써먹을 수 있어요.

패턴 1: Claude를 리뷰어로 쓰기

"이 변경사항을 엄격히 검토하고, 
내가 테스트를 통과할 때까지 PR 만들지 마."

이러면 Claude가 코드를 만들고 끝이 아니라, 스스로 자기 코드를 까기 시작해요. "이 부분은 엣지 케이스 처리가 빠져있다", "이 로직은 동시성 문제가 있을 수 있다" 같은 피드백을 알아서 해요. 보통은 코드를 만들면 "완료했습니다!"라고 자신감 넘치게 보고하잖아요. 이 프롬프트는 그 자신감을 깨는 거예요.

패턴 2: 증명을 요구하기

"이게 작동한다는 걸 증명해봐. 
main 브랜치와 feature 브랜치 간 동작 차이를 diff해."

이건 좀 고급 패턴인데요. Claude한테 "됐다"고 말하게 두지 않고, 실제로 증명하게 시키는 거예요. main에서는 이렇게 동작하고, feature에서는 이렇게 동작하고, 차이가 이거다. 이걸 보여줘야 합격인 거예요.

패턴 3: 리셋 시키기

"지금까지 알게 된 모든 것을 바탕으로 이걸 버리고 
우아한 솔루션을 구현해."

평균적인 결과물이 나왔을 때 쓰는 패턴이에요. Claude가 첫 시도에서 "그저 그런" 코드를 만들었으면, 그걸 기반으로 리팩터링하는 것보다 아예 처음부터 다시 하는 게 나은 경우가 많아요. 왜냐하면 첫 시도에서 문제 영역을 이미 학습했으니까, 두 번째 시도에서는 훨씬 나은 결과가 나오거든요.

이건 제 세 번째 뉴스레터에서 Mitchell Hashimoto가 "같은 작업을 두 번 한다"고 했던 것과 맥이 같아요. 첫 번째 시도가 학습이고, 두 번째 시도가 진짜예요.

그리고 Boris가 이 모든 팁을 관통하는 원칙 하나를 말해요:

결국 AI에게 모호하게 시키면 모호한 결과가 나오고, 구체적으로 시키면 구체적인 결과가 나와요. 이건 AI만의 문제가 아니에요. 사람한테 일을 시킬 때도 마찬가지잖아요. 근데 AI한테는 이게 10배 더 중요해요. 사람은 모호하면 다시 물어보지만, AI는 모호하면 자기가 알아서 결정해버리거든요. 그리고 그 결정은 대부분 교과서적이에요.

병렬 작업 환경

혼자인데 팀처럼 일하라

이 카테고리가 Boris 팀이 가장 강조하는 부분이에요. 트위터 스레드 첫 번째 팁이 바로 이거였거든요.

Git Worktree — 한 사람이 3~5명분의 일을 하는 법

이건 제 강의 Ch5의 핵심이에요. "혼자인데 팀처럼 일할 수 있다. 터미널 3개면 3명이다."

근데 Boris 팀이 공유한 세부 사항 중에 진짜 실용적인 게 있어요.

셸 alias로 워크트리 전환하기:

Boris 팀원 중 한 명은 워크트리에 이름을 붙이고, 셸 alias를 이렇게 만들었대요:

# .zshrc 또는 .bashrc에 추가
alias za="cd ~/projects/myapp-worktree-a"
alias zb="cd ~/projects/myapp-worktree-b"  
alias zc="cd ~/projects/myapp-worktree-c"

za 한 번 치면 워크트리 A로, zb 치면 B로. 한 글자로 작업 공간을 전환하는 거예요. 이거 사소해 보이지만, 하루에 수십 번 전환할 때 체감이 커요.

분석 전용 워크트리:

또 다른 팀원은 "analysis" 워크트리를 별도로 운영해요. 여기서는 코드를 안 건드리고, 로그 확인이나 데이터 분석만 해요. 개발 워크트리와 분석 워크트리를 분리하면 "이 터미널에서 뭘 하고 있었지?" 하는 혼란이 줄어들어요.

저도 현업에서 이렇게 했거든요. 터미널 탭 하나는 구현, 하나는 테스트, 하나는 로그 확인. 각 탭에 역할을 정해두면 컨텍스트 스위칭 비용이 확 줄어요. Boris 팀원들은 여기에 터미널 탭에 색상 코드와 이름을 붙이고 tmux를 쓴다고 해요. 작업/워크트리당 하나의 탭.

서브에이전트 — 메인 세션을 깨끗하게 유지하는 법

Boris가 공유한 팁 중에 "use subagents"라는 게 있어요:

서브에이전트가 뭐냐면요. Claude Code가 개별 작업을 별도의 하위 에이전트에 위임하는 거예요. 메인 에이전트는 전체 작업을 관리하고, 세부 작업은 서브에이전트한테 맡기는 거죠.

이게 왜 중요하냐면, 메인 에이전트의 컨텍스트 윈도우를 깨끗하게 유지할 수 있기 때문이에요. 제 강의에서 "컨텍스트 윈도우 = AI의 RAM"이라고 했잖아요. 메인 에이전트가 모든 작업을 다 하면 RAM이 금방 차요. 서브에이전트를 쓰면 메인의 RAM을 아끼는 거예요.

실전에서 예를 들면요. "이 파일의 모든 함수에 JSDoc 주석을 추가하고, 동시에 테스트도 작성해줘"라고 하면, 메인 에이전트가 JSDoc 작업은 서브에이전트 A한테, 테스트 작업은 서브에이전트 B한테 각각 위임하는 거예요. 메인 에이전트의 컨텍스트에는 "JSDoc 추가 완료, 테스트 작성 완료"라는 결과만 남아요.

버그 수정 — "fix"라고만 치세요

Boris 팀이 버그를 고치는 방법이 심플해요:

여기서 MCP가 뭐냐면, Model Context Protocol의 약자예요. 외부 도구(Slack, GitHub 등)를 Claude Code에 직접 연결하는 프로토콜이에요. Slack MCP를 연결하면 Claude가 Slack 메시지를 직접 읽을 수 있어요.

버그 리포트가 Slack에 올라오잖아요. 예전에는 그걸 읽고, 코드를 열고, 원인을 파악하고, 수정하고, 테스트하고... 이 과정을 다 거쳐야 했어요. Boris 팀은 Slack 스레드를 Claude에 던지고 "fix"라고만 치는 거예요. Claude가 알아서 맥락을 파악하고, 원인을 찾고, 수정해요.

또 하나:

CI가 실패했을 때 "어디서 왜 실패했는지 분석하고 고쳐줘"라고 구구절절 설명할 필요 없이, 그냥 "CI 고쳐"라고 하면 된다는 거예요. 마이크로매니지하지 마라. 이건 사람한테 일 시킬 때도 마찬가지잖아요. 시니어한테 "if문 3번째 줄에 else 추가해서..."라고 하진 않잖아요.

그리고 Docker 로그를 Claude에 전달해서 분산 시스템 트러블슈팅에 활용한다고 해요. "이 Docker 로그를 보고 뭐가 문제인지 알려줘"라고 하면 "놀라울 정도로 유능하다"고 Boris가 직접 말해요.

이건 제가 현업에서도 많이 쓰는 패턴이에요. 에러 로그를 통째로 Claude에 던지면 원인을 짚어주는 경우가 많거든요. 특히 스택트레이스가 길고 복잡한 경우에 진짜 유용해요. 사람이 읽으면 5분 걸릴 걸 Claude는 몇 초 만에 핵심을 짚어줘요.

반복되면 도구를 만들어라

이 부분이 사실 가장 "내부자"다운 팁이에요. 외부 사용자는 잘 안 하거든요.

Skill과 Slash Command — 하루에 한 번 이상이면 자동화하라

Skill이 뭐냐면요. Claude Code에서 특정 작업을 수행하는 방법을 문서화해놓은 마크다운 파일이에요. .claude/skills/ 디렉토리에 넣어두면 Claude가 관련 작업을 할 때 자동으로 참조해요.

Slash Command는 더 직관적이에요. /techdebt 같은 커맨드를 만들어두면, 세션 끝에 /techdebt 치면 Claude가 코드베이스에서 중복 코드를 찾아서 정리해줘요.

Boris 팀이 실제로 만든 것들:

세 번째 거 보세요. 이건 Skill의 끝판왕이에요. 역할 자체를 Skill로 정의한 거예요. "너는 analytics engineer야. dbt 모델을 이렇게 작성해야 하고, 이런 기준으로 리뷰해야 한다."를 미리 정의해놓은 거죠.

제 강의에서는 CLAUDE.md에 프로젝트 맥락을 담는 걸 가르치는데, Skill은 거기서 한 걸음 더 나간 거예요. CLAUDE.md가 "이 프로젝트는 이렇다"라면, Skill은 "이 작업은 이렇게 해라"예요. 프로젝트 맥락 + 작업별 맥락을 같이 주는 거죠.

실전에서 바로 써볼 수 있는 예시를 하나 드릴게요. 매일 아침 코드를 시작할 때 git status 확인하고, 어제 커밋 리뷰하고, TODO 주석 찾는 작업을 하잖아요. 이걸 Skill로 만들면:

<!-- .claude/skills/morning-review.md -->
# 아침 코드 리뷰

## 수행할 작업
1. `git log --oneline -10`으로 최근 커밋 확인
2. `git diff HEAD~3`으로 최근 변경 사항 확인
3. 프로젝트 전체에서 TODO, FIXME, HACK 주석 검색
4. 발견한 이슈를 우선순위별로 정리해서 보고

## 주의사항
- 코드를 수정하지 마라, 보고만 하라
- 보안 관련 이슈가 있으면 맨 위에 표시하라

이런 식으로요. 한 번 만들어두면 매일 아침 "morning review 해줘"라고만 하면 돼요.

터미널 세팅은 생각보다 중요합니다

Boris 팀이 터미널 세팅에 대해 꽤 많이 이야기하는데요. 요약하면:

Ghostty 터미널을 추천해요. 동기화 렌더링, 24비트 컬러, 유니코드 지원이 좋다고요. Ghostty는 세 번째 뉴스레터에서 다뤘던 Mitchell Hashimoto가 만든 터미널이에요. Claude Code 팀이 Ghostty를 쓴다는 건 의미가 있죠.

그리고 흥미로운 팁이 하나 있어요:

macOS에서 fn 키를 두 번 누르면 음성 받아쓰기가 활성화돼요. 이걸로 Claude에 프롬프트를 입력하면 타이핑할 때보다 3배 빠르고, 더 자세하게 설명할 수 있다는 거예요.

생각해보면 맞는 말이에요. 타이핑하면 "짧게 써야지" 하는 심리가 있잖아요. 근데 말로 하면 자연스럽게 더 자세히 설명해요. "이 함수가 있는데, 이게 지금 에러를 반환하지 않고 null을 반환하는 문제가 있어서, 이걸 Result 타입으로 바꿔야 하는데, 기존에 이 함수를 호출하는 곳이 3군데 있으니까 거기도 같이 수정해야 해." 이런 식으로 맥락을 풍부하게 전달할 수 있어요. 타이핑으로는 이렇게 길게 안 쳐요.

그리고 /statusline으로 상태바를 커스터마이징해서 컨텍스트 사용량과 현재 git 브랜치를 항상 표시한다고 해요. 이건 실용적이에요. 컨텍스트 윈도우가 얼마나 남았는지를 항상 확인할 수 있으니까, "아, 곧 차니까 /compact 해야겠다" 같은 판단을 할 수 있거든요.

도구와 자동화

데이터 분석 — 6개월째 SQL을 직접 안 쓴다고요

Boris가 한 말 중에 이건 좀 충격이었어요:

BigQuery skill을 코드베이스에 넣어두고, 팀 전체가 Claude Code에서 직접 분석 쿼리를 실행한다고 해요. "이번 주 DAU 추이를 보여줘"라고 하면 Claude가 알아서 SQL을 작성하고 BigQuery에서 실행해서 결과를 보여주는 거예요.

이건 개발자뿐만 아니라 PM, 데이터 분석가한테도 해당되는 이야기예요. CLI, MCP, API가 있는 모든 데이터베이스에 동일하게 적용 가능하다고 Boris가 명시했거든요. PostgreSQL이든 MySQL이든 ClickHouse든, 접근 방법만 있으면 Claude가 쿼리를 대신 써줘요.

근데 주의할 점이 있어요. 이전 뉴스레터에서 얘기한 것처럼 AI가 생성한 쿼리를 그대로 믿으면 안 돼요. 특히 분석 쿼리는 결과가 "그럴듯해 보이지만 실제로는 틀린" 경우가 있어요. JOIN 조건이 빠졌다거나, GROUP BY가 잘못됐다거나. 결과를 한 번은 검증하세요.

Claude를 학습 도구로 쓰는 방법

마지막으로 이건 개발자 성장과 관련된 건데요. Boris 팀이 Claude를 학습에도 적극적으로 활용해요.

보통 Claude가 코드를 수정하면 "수정했습니다"로 끝나잖아요. Learning 모드를 켜면 "왜 이렇게 수정했는지"를 같이 설명해줘요. 코드 리뷰를 시니어한테 받는 느낌이에요. 주니어 개발자한테 특히 유용해요.

더 놀라운 건 이거예요:

마지막 거 보세요. Claude를 튜터로 쓰는 거예요. "내가 이해한 걸 설명할 테니, 틀린 부분을 짚어줘." 이러면 Claude가 "이 부분은 맞는데, 이 부분은 오해가 있어요. 실제로는..."이라고 피드백을 줘요.

제 강의의 Ch0에서 "AI 시대 개발자의 두려움"을 다루는데요. "AI가 다 해주면 내 실력은 어떻게 되나?"가 가장 큰 걱정이잖아요. Boris 팀의 접근은 그 답을 줘요. AI를 코드 생성 도구로만 쓰지 말고, 학습 도구로도 쓰라는 거예요. AI가 코드를 생성하는 과정에서 "왜"를 설명하게 하면, 여러분의 실력도 같이 올라가요.

Boris 팀 vs 에피의 워크플로우 비교

읽으면서 "이 사람들이랑 나랑 뭐가 같고 뭐가 다르지?"를 정리해봤어요.

솔직히 말하면, Boris 팀이 저보다 한 단계 더 나가 있는 부분이 있어요. 특히 Skill 시스템과 MCP 활용 쪽이요. 이건 제가 아직 덜 활용하고 있는 영역이에요.

근데 반대로, 제가 더 강조하는 부분도 있어요. 검증 워크플로우요. Boris 팀의 10개 팁에서 테스트나 검증에 대한 이야기는 상대적으로 적어요. "Claude한테 시키고 리뷰어로 쓰라"는 있지만, Writer/Reviewer 패턴이나 속성 기반 테스트 같은 체계적인 검증 방법론은 없어요. 이건 제 강의 Ch6에서 깊이 다루는 부분인데, Boris 팀도 당연히 내부적으로 하고 있겠지만 트위터에서는 언급하지 않은 거예요.

그래서 Boris 팀의 "생산성" 팁 + 에피의 "검증" 워크플로우를 합치면 꽤 탄탄한 AI 코딩 시스템이 되는 거예요. 빠르게 만들면서도 품질을 유지하는 거죠.

오늘 바로 해보세요

10개 팁을 다 적용하려면 부담스럽잖아요. 단계별로 가세요.

오늘 당장 (5분)

CLAUDE.md 자동 업데이트 습관 만들기

다음 작업에서 Claude가 실수할 때, 고쳐주고 나서 이 한 마디를 덧붙이세요:

"지금 한 실수가 반복되지 않도록 CLAUDE.md를 업데이트해."

이거 한 줄이면 됩니다. 내일부터 Claude가 같은 실수를 안 해요. 시간이 지나면 CLAUDE.md가 프로젝트에 최적화된 규칙서가 되어 있을 거예요.

이번 주 안에 (30분)

셸 alias + 워크트리 세팅

# 워크트리 만들기
git worktree add ../myapp-feature-a feature-a
git worktree add ../myapp-feature-b feature-b

# 셸 alias 추가
echo 'alias za="cd ~/projects/myapp-feature-a"' >> ~/.zshrc
echo 'alias zb="cd ~/projects/myapp-feature-b"' >> ~/.zshrc
source ~/.zshrc

이 세팅을 한 번 해두면, za 치고 claude 치면 워크트리 A에서 Claude가 돌아가고, 다른 탭에서 zb 치고 claude 치면 워크트리 B에서 Claude가 돌아가요. 혼자인데 두 명이 된 거예요.

시간이 있을 때 (1시간)

첫 번째 Skill 만들어보기

.claude/skills/ 디렉토리를 만들고, 매일 반복하는 작업 하나를 Skill로 만들어보세요. 뭐든 상관없어요. 코드 리뷰든, PR 작성이든, 로그 분석이든. 한 번 만들어보면 "아, 이런 것도 자동화할 수 있구나"가 열려요. 그때부터 두 번째, 세 번째 Skill을 만들게 돼요.

마무리

Boris의 10개 팁을 한 문장으로 요약하면 이거예요:

프롬프트를 잘 쓰는 건 10%예요. 나머지 90%는 환경이에요. CLAUDE.md, Skill, 워크트리, 터미널 세팅, MCP 연결. 이런 것들이 쌓이면 "프롬프트를 잘 쓰는 사람"이 아니라 "AI와 일하는 시스템을 가진 사람"이 돼요.

도구를 만든 팀도 정답이 없다고 했어요. 팀원마다 다 다르대요. 여러분도 실험하세요. 오늘 소개한 것 중에 하나만 골라서 해보세요. 맞으면 쓰고, 안 맞으면 버리면 돼요.

근데 하나는 확실해요. 아무것도 안 해보는 게 가장 나쁜 선택이에요. Boris 팀이 이렇게까지 공개한 건 이유가 있거든요. 써보라는 거예요. 도구가 좋아지는 건 사람들이 써야 가능하니까요.

다음 뉴스레터에서도 바이브 코딩과 Claude Code 관련 실전 인사이트를 가져오겠습니다.

레퍼런스