7년차 개발자의 AI 실험실

[Claude Code 실전 정복 #6] 레거시 코드 리팩토링을 AI한테 맡겨봤더니 — 2,000줄짜리 파일이 이렇게 됐어요

체리플랜 — Sat, 16 May 2026 18:00:56 +0900

cherryplan 프로젝트 초기 코드를 다시 열었을 때 솔직히 눈을 감고 싶었어요.

2024년 초에 급하게 짠 utils.js 하나에 함수가 47개였어요. 인증 로직이랑 날짜 포맷팅이랑 API 호출 헬퍼가 전부 한 파일에 섞여 있었고, 주석은 "나중에 정리하자"라고 써놓은 채로 6개월이 지나 있었어요. 새 기능 붙일 때마다 "어디 있더라?" 검색하는 시간만 5~10분씩 나갔어요. 파일 하나 건드리면 연결된 다른 곳에서 터지는 것도 반복됐고요.

리팩토링 해야 한다는 건 알았는데 타이밍을 못 잡고 있었어요. 이걸 어디서부터 건드려야 하는지 감이 안 잡히는 것도 있었고, 혼자 2,000줄 분석하고 재구성할 엄두가 안 났던 것도 솔직히 있어요.

Claude Code한테 맡겨봤어요. 그냥 파일 던지고 "분석해줘"라고 했는데 결과가 예상을 넘었어요.

Claude Code한테 리팩토링 어떻게 시켰냐면

막연하게 "리팩토링해줘"라고 하면 Claude Code도 방향을 못 잡아요. 제가 실제로 쓴 프롬프트는 이랬어요.

이 파일 전체 분석해줘.
- 함수 목록이랑 각 함수가 하는 역할 정리해줘
- 관심사 기준으로 어떻게 분리할 수 있는지 제안해줘
- 실제로 어떤 파일로 나눌지 구조 잡아줘
- 리팩토링하면서 기존 import 경로 깨지지 않게 해줘

Claude Code가 먼저 파일 전체를 읽고 함수 47개를 이렇게 분류해줬어요.

분류 결과:
- auth/ → 인증 관련 함수 11개 (토큰 처리, 권한 체크)
- date/ → 날짜/시간 포맷 함수 8개
- api/ → API 호출 헬퍼 함수 14개
- validation/ → 유효성 검사 함수 9개
- format/ → UI 표시용 포맷 함수 5개
- 분류 애매한 것 → 별도 검토 필요 5개 (같이 결정하자고 물어봄)

실제로 써보니 이 분류 단계가 핵심이었어요. 저 혼자였으면 함수 목록 정리하는 데만 30분은 썼을 텐데, Claude Code가 5초 만에 읽고 바로 뱉어줬어요. "분류 애매한 것"은 같이 결정하자고 역으로 물어봐서 오히려 더 신뢰가 갔어요.

실제 리팩토링 진행 과정

분류 확인 후 이렇게 지시했어요.

auth 폴더부터 시작해줘.
- 기존 utils.js에서 인증 함수 11개 추출해서 auth/index.js로 만들어줘
- utils.js에 남겨둔 export도 유지해줘 (기존 import 안 깨지게)
- 테스트 있는 함수는 테스트 경로도 업데이트해줘

Claude Code가 실제로 진행한 순서예요.

# Claude Code 실행 로그 (실제)
Reading utils.js... (2,847 tokens)
Extracting auth functions: 11 found
Creating auth/index.js
Creating auth/tokenHelper.js
Updating utils.js (re-exporting from auth/)
Checking for test files... found utils.test.js
Updating import paths in utils.test.js
Done. 0 breaking changes detected.

실제로 써보니 "0 breaking changes detected" 이게 제일 안심됐어요. 기존 코드 어디서도 import 경로 안 바꾸고 리팩토링이 완료된 거예요. 한 폴더씩 확인하면서 진행하니까 중간에 뭔가 이상하다 싶으면 바로 잡을 수 있었고요.

실전 활용 — 이런 프롬프트가 잘 먹혔어요

리팩토링 과정에서 효과적이었던 프롬프트 패턴 몇 가지예요.

함수 중복 찾기

이 파일에서 비슷한 역할을 하는 함수들 찾아줘.
중복 로직 있으면 통합할 수 있는 것들 알려줘.

네이밍 개선

이 함수들 이름이 역할을 잘 설명하는지 검토해줘.
더 명확한 이름 있으면 제안해줘. 기존 이름이랑 새 이름 같이 보여줘.

의존성 파악

이 함수가 어디서 호출되는지 프로젝트 전체에서 찾아줘.
영향 받는 파일 목록 뽑아줘.

마지막 프롬프트가 특히 유용했어요. 리팩토링할 때 제일 무서운 게 "이거 어디서 쓰는지 몰라서 건드리기 무섭다"인데, Claude Code가 프로젝트 전체 grep해서 호출 위치 다 뽑아줬어요.

솔직한 한계

다 좋은 건 아니에요.

비즈니스 로직은 직접 판단해야 해요. Claude Code가 함수를 분류할 때 "이게 auth 쪽인지 validation 쪽인지 애매하다"고 물어보는 경우가 있어요. 이건 코드 문맥이 아니라 서비스 구조를 알아야 판단할 수 있는 거라서, 결국 사람이 결정해야 해요. Claude Code는 선택지를 주고 기다리지, 멋대로 결정하지 않아요.

복잡한 의존성 체인은 한 번에 안 돼요. A가 B를 쓰고 B가 C를 쓰고 C가 다시 A를 참조하는 순환 의존성 있는 코드는 Claude Code도 "이 구조 먼저 정리해야 한다"고 플래그만 달아줘요. 해결은 같이 단계 나눠서 해야 해요.

컨텍스트 창 한계. 파일이 너무 크면 (5,000줄 이상) 한 번에 못 읽어요. 이럴 땐 섹션 나눠서 넘겨줘야 해요.

마무리

utils.js 한 파일 리팩토링하는 데 혼자 했으면 이틀은 잡았을 거예요. Claude Code랑 같이 하니까 반나절이었어요. 그것도 중간에 밥 먹고 커피 마시면서요.

더 중요한 건 시간보다 심리적 진입 장벽이에요. "2,000줄짜리 건드렸다가 뭔가 터지면 어떡하지"라는 두려움이 사라진 게 제일 커요. Claude Code가 영향 범위 파악하고, breaking change 체크하고, 단계별로 진행하니까 리팩토링이 무서운 작업이 아니라 그냥 할 수 있는 작업이 됐어요.

레거시 코드 보기 싫어서 미루고 있던 분들, 그냥 파일 던지고 "분석해줘"부터 시작해보세요.

다음 포스팅 예고: [Claude Code 실전 정복 #7] Claude Code로 테스트 코드 짜기 — 커버리지 0%에서 시작한 이야기

Cursor 쓰다가 Claude Code로 갈아탄 7년차 개발자의 솔직 후기

체리플랜 — Fri, 15 May 2026 18:00:09 +0900

설 연휴 직전이었어요. 갑자기 "설날 세뱃돈 게임 만들면 재밌겠다" 싶어서 Cursor 켰습니다. 바이브코딩 처음 도전하는 거라 기대 반 설렘 반이었는데 — 결과부터 말하면, 완성은 했어요. 근데 과정이 좀 험했습니다.

Cursor가 제 의도를 물어보지 않고 그냥 자기 판단대로 코드를 짜버리는 거예요. "이 정도면 되겠지?" 하고 진행하다가 나중에 제가 "아 이건 아닌데" 하면서 롤백. 또 짜고, 또 롤백. 토큰은 토큰대로 날리고, 시간은 시간대로 날리고.

seollal-game.vercel.app

설날 세배 타이밍 - 미니게임

어른 마음에 딱 맞게 세배하면 세뱃돈을 받아요! 게이지가 중앙에 올 때 클릭하세요. 타이밍에 맞춰 절하기를 클릭하세요!

seollal-game.vercel.app

에 올라간 결과물은 그럭저럭 나왔지만 그 과정은 솔직히 비효율의 연속이었어요.

그러다 Claude Code를 써봤는데, 첫 대화에서 바로 달랐습니다. 기획 단계부터 저한테 먼저 물어봐요. "이 기능은 어떻게 동작하면 돼요?", "이 케이스는 어떻게 처리할까요?" — 저는 그냥 답만 하면 되고, Claude가 그걸 md 파일로 정리해주고, 그 기획서를 기반으로 개발을 시작하는 거죠. 그래서 롤백이 거의 없어요.

Cursor가 뭔지는 알죠? 근데 Claude Code는요?

https://cursor.com/

The best way to code with AI

탁월한 생산성을 내도록 설계된 Cursor는 AI로 소프트웨어를 만드는 최고의 방법입니다.

cursor.com

Cursor는 VS Code 기반 AI 코딩 에디터예요. 코드 자동완성, 채팅으로 코드 생성, 에러 수정 — 이런 기능들이 있고 바이브코딩 입문용으로 많이들 시작하죠.

Claude Code는 Anthropic이 만든 터미널 기반 AI 코딩 에이전트예요. VS Code 안에서도 쓸 수 있고, 터미널에서 claude 명령어로도 실행돼요. 결정적인 차이는 에이전트라는 점이에요 — 단순히 코드를 제안하는 게 아니라, 파일을 읽고, 만들고, 수정하고, 실행까지 해요. 그리고 모르는 게 있으면 저한테 먼저 물어봅니다.

Cursor는 "내가 알아서 할게"고, Claude Code는 "잠깐, 이거 먼저 확인하고 가자"예요.

실제로 어떻게 달랐냐면

Cursor로 만든 설날 세뱃돈 게임

프로젝트: 설날 테마 타이밍 미니게임 (seollal-game.vercel.app)
상황: 기획 없이 바로 "세뱃돈 게임 만들어줘" 입력
결과물: GitHub → Vercel 배포까지 완성. GA 연동도 했어요.
문제: Cursor가 알아서 방향 잡고 코드 생성 → 내가 원하던 방향이 아님 → 롤백 → 재작성 → 반복

설날 세배 타이밍 - 미니게임

어른 마음에 딱 맞게 세배하면 세뱃돈을 받아요! 게이지가 중앙에 올 때 클릭하세요. 타이밍에 맞춰 절하기를 클릭하세요!

seollal-game.vercel.app

배포 자체는 됐어요. Vercel 연동, Google Analytics 설정, 트위터 공유 기능까지 다 붙였는데 — 이걸 하면서 Claude가 GitHub 초기화부터 Vercel 배포, GA 측정 ID 적용까지 단계별 가이드 문서도 만들어줬거든요. 문서화까지 자동으로 되는 건 좋았는데, 코딩 과정 자체에서 롤백이 반복되는 게 가장 큰 문제였어요.

실제로 써보니 Cursor는 빠른 프로토타이핑에는 강한데, 내 의도가 복잡하거나 기획이 필요한 프로젝트엔 소통 비용이 꽤 들어요.

Claude Code로 만든 왕과 사는 남자 유형 테스트

프로젝트: 조선시대 배경 캐릭터 유형 검사 웹앱 (https://the-kings-warden2.vercel.app/)
스택: React 18 + TypeScript + Vite + Tailwind CSS
기간: 약 3일
방식: Claude랑 기획 대화 먼저 → md 파일로 PRD 자동 정리 → 개발 시작

❝왕과 사는 남자❞ 캐릭터 유형 테스트

나의 ❝왕과 사는 남자❞ 캐릭터 유형은? 10문항으로 나의 유형을 찾아보세요.

the-kings-warden2.vercel.app

이 프로젝트가 Claude Code의 진짜 실력을 보여줘요. 유형 검사류 앱은 콘텐츠 설계가 복잡해요. 저 같은 경우엔:

14개 문항, 각 선택지마다 5개 캐릭터 유형 중 하나에 점수 누적
5가지 캐릭터 유형 — 단종형(신념형), 엄흥도형(실천형), 한명회형(전략형), 금성대군형(돌파형), 매화형(공감형)
동점 처리 로직까지 — 마지막 선택 유형 우선, 그것도 동점이면 DJ > UH > HM > GS > MH 순서로 결정

이런 복잡한 로직을 Claude랑 대화하면서 하나씩 잡아갔어요. 그리고 개발이 끝난 뒤에 Claude가 완성된 코드를 역으로 분석해서 PRD(Product Requirements Document) 를 자동으로 만들어줬어요. "역 PRD"라고 부르는데 — 나중에 유지보수하거나 비슷한 프로젝트 만들 때 이 문서 하나가 진짜 요긴하게 쓰여요.

실제로 써보니 기획 → 개발 → 문서화가 하나의 흐름으로 이어지는 게 Cursor랑 완전히 달랐어요. 롤백 없이 3일 만에 끝냈는데, 같은 규모의 프로젝트를 Cursor로 했으면 훨씬 오래 걸렸을 거예요.

여기서 끝이 아니에요 — MCP 연동이 진짜 게임체인저

Claude Code 자체도 좋은데, MCP(Model Context Protocol)를 연결하면 차원이 달라져요.

저는 지금 노션 + 피그마 + 구글 캘린더 MCP를 연결해서 쓰고 있어요. 실제 워크플로우가 이렇게 돌아가요:

Claude Code로 기획 대화
→ 기획 내용 자동으로 노션 페이지에 저장
→ 그 노션 페이지를 블로그 글 / 유튜브 쇼츠 대본으로 바로 활용
→ 피그마로 카드뉴스 제작
→ 구글 캘린더에 발행 스케줄 추가

이게 다 Claude 안에서 명령 한 번으로 이어져요. "체리플랜 노션에 오늘 기획 저장해줘" 하면 알아서 저장하고, 페이지 링크까지 줘요.

실제로 CherryPlan 노션 페이지의 상세 페이지들 대부분이 Claude가 직접 작성한 내용이에요. 개인 프로젝트 기록, 블로그 초안, 콘텐츠 아이디어 — 전부 Claude + MCP 조합으로 정리되고 있어요. 개인 프로젝트뿐만 아니라 회사 업무 정리에도 똑같이 쓰고 있는데, 월 $20으로 이 정도 효율이면 압도적으로 납득이 가요.

솔직한 한계

Claude Code가 다 좋은 건 아니에요.

터미널 기반이라 진입장벽 있음: Cursor는 VS Code 설치하면 바로 되는데, Claude Code는 터미널에 익숙해야 해요. 처음엔 낯설 수 있어요.
월 $20 유료 플랜 필요: 무료로는 Claude Code 제대로 못 써요. 근데 이 효율이면 아깝지 않아요.
Google AI Studio 대비: AI Studio는 웹에서 바로 쓸 수 있어서 가볍게 시작하기엔 편한데, 실제 코드 파일 관리나 Vercel 배포 연동은 Claude Code가 압도적으로 편해요.
Cursor가 완전히 나쁜 건 아님: 간단한 코드 수정이나 빠른 프로토타이핑엔 Cursor도 충분해요. 다만 기획이 필요한 프로젝트엔 Claude Code가 맞아요.

마무리

Cursor로 바이브코딩 시작해서 롤백을 반복하던 저한테, Claude Code는 완전히 다른 경험을 줬어요. 설날 게임에서 며칠 걸리던 작업이 왕과 사는 남자 프로젝트에선 3일로 줄었고 — PRD 자동 문서화, MCP 연동까지 붙이니 기획 → 개발 → 콘텐츠 발행 전체 사이클이 하나로 이어졌어요. 코드 한 줄 안 짜도 React + TypeScript 앱이 나오고, 기획서까지 자동으로 생성되는 게 7년차 개발자 입장에서도 솔직히 놀라웠어요.

Claude Code 써보고 싶은데 어디서 시작해야 할지 모르겠다면, 다음 포스팅에서 설치부터 MCP 연동까지 단계별로 정리할게요.

다음 포스팅 예고: Claude Code 설치부터 MCP 노션 연동까지 — 처음 하는 사람도 따라할 수 있는 세팅 가이드

#클로드코드 #ClaudeCode #바이브코딩 #AI코딩 #개발자AI #커서vs클로드 #MCP #노션연동 #AI개발도구 #프론트엔드개발 #7년차개발자 #AI자동화 #개발생산성 #바이브코딩입문 #anthropic

Claude에 MCP 연결하면 뭐가 달라지냐고요? 노션·피그마·구글캘린더 세팅 실전기

체리플랜 — Thu, 14 May 2026 18:00:03 +0900

MCP 세팅하기 전에 저는 Claude랑 대화할 때마다 이런 걸 반복했어요.

"나 체리플랜이라는 1인 브랜드 운영 중이고, 티스토리 블로그랑 네이버 블로그 병행하고 있어. 오늘 쓸 글 주제는…" — 매번 컨텍스트를 처음부터 설명하는 거죠. 대화가 끊기면 또 처음부터. Claude는 이전 대화를 기억 못 하니까 매번 소개부터 해야 했어요.

근데 MCP(Model Context Protocol) 연결하고 나서 달라졌어요. 이제 Claude가 제 노션 페이지를 직접 읽고, 구글 캘린더 일정을 확인하고, 피그마 파일에 접근해요. 제가 설명 안 해도 컨텍스트를 이미 알고 있는 거예요. 특히 claude.ai 앱에서 MCP 연결해두면 대화할 때 체감이 완전히 달라요.

이번 글에서 제가 실제로 연결한 노션 + 피그마 + 구글 캘린더 MCP 세팅 방법을 소개할게요.

MCP가 뭔데요?

MCP는 Model Context Protocol의 약자예요. 쉽게 말하면 Claude가 외부 앱에 직접 접근할 수 있게 해주는 연결 규격이에요.

기존엔 Claude한테 "내 노션에 이런 내용 있어"라고 말로 설명해야 했다면, MCP 연결 후엔 Claude가 노션을 직접 열어서 읽어요. 구글 캘린더도 직접 확인하고, 피그마 파일도 직접 가져와요. 제가 복붙하거나 설명할 필요가 없어요.

Anthropic이 공식으로 밀고 있는 규격이라서 점점 지원하는 앱이 늘어나고 있고, claude.ai 앱에서 설정 몇 번으로 연결할 수 있어요.

세팅 방법 — claude.ai 앱 기준

Step 1: claude.ai 접속 → Settings → Integrations

claude.ai 접속 후 로그인 (pro 플랜부터 가능)
하단에 앱 및 확장 프로그램 받기 클릭!
데스크톱용 앱 다운받기
Customize 선택
연결 가능한 앱 목록 확인

현재 claude.ai에서 공식 지원하는 MCP 앱으로 노션, 구글 캘린더, 피그마 등이 있어요. 목록에서 원하는 앱 선택하면 돼요.

Step 2: 노션 MCP 연결

Integrations 목록에서 Notion 선택
Connect 클릭
노션 계정으로 로그인 → 접근 허용할 워크스페이스 선택
페이지 접근 권한 설정 — 전체 워크스페이스 허용 추천
연결 완료

연결되면 Claude한테 "내 노션 체리플랜 페이지 읽어줘" 하면 바로 읽어요. "오늘 기획한 내용 노션에 저장해줘" 하면 알아서 페이지 만들고 저장까지 해줘요.

실제로 쓴 명령어 예시:
"체리플랜 노션 페이지에 오늘 블로그 기획 내용 정리해서 저장해줘"
→ Claude가 노션 페이지 생성 + 내용 작성 + 링크 전달까지 한 번에

Step 3: 구글 캘린더 MCP 연결

Integrations 목록에서 Google Calendar 선택
Connect 클릭
구글 계정 로그인 → 캘린더 접근 허용
연결 완료

이제 "다음 주 월요일에 블로그 발행 일정 추가해줘" 하면 Claude가 구글 캘린더에 직접 일정 넣어줘요. 발행 패턴 관리할 때 진짜 편해요.

실제로 쓴 명령어 예시:
"티스토리 글 내일 오전 10시 발행으로 구글 캘린더에 추가해줘. 제목은 'Claude Code vs Cursor 비교글'"
→ 캘린더 일정 자동 생성

Step 4: 피그마 MCP 연결

Integrations 목록에서 Figma 선택
Connect 클릭
피그마 계정 로그인 → 접근 허용
연결 완료

피그마 연결하면 Claude가 피그마 파일 구조를 읽고, 카드뉴스 레이아웃 제안이나 디자인 피드백을 훨씬 구체적으로 줄 수 있어요. 실제 파일 보면서 얘기하는 거라 "이 컴포넌트 어떻게 수정하면 돼요?" 같은 질문도 바로 답해줘요.

연결하고 나서 실제로 달라진 것들

세팅 자체는 어렵지 않아요. 각 앱당 5분이면 끝나요. 근데 연결하고 나서 워크플로우가 이렇게 바뀌었어요.

연결 전

나: "나 체리플랜 운영 중이고 티스토리 블로그 있어. 오늘 쓸 글은..."
→ 매 대화마다 컨텍스트 설명 반복
→ 기획 내용 직접 복붙해서 노션에 저장
→ 캘린더 일정 따로 앱 열어서 추가

연결 후

나: "오늘 블로그 기획하고 노션에 저장, 발행 일정 캘린더에 추가해줘"
→ Claude가 기획 대화 진행
→ 노션 페이지 자동 생성 + 저장
→ 구글 캘린더 일정 자동 추가
→ 링크 전달까지 한 번에

개인 프로젝트뿐만 아니라 회사 업무 정리에도 똑같이 쓰고 있어요. 회의 내용 정리해서 노션에 저장하고, 후속 일정 캘린더에 넣는 것도 Claude한테 시키면 돼요. 월 $20짜리 Claude Pro 플랜에서 다 돼요.

솔직한 한계

연결 가능한 앱이 아직 제한적: 공식 지원 앱 외엔 직접 MCP 서버 세팅이 필요해요. 개발자가 아니면 좀 어려울 수 있어요.
권한 범위 주의: 노션 전체 워크스페이스 허용하면 편한데, 민감한 페이지가 있다면 접근 범위 좁혀서 설정하는 게 좋아요.
대화 맥락은 여전히 필요: MCP가 파일/앱에 접근하는 거지, Claude가 내 모든 히스토리를 기억하는 건 아니에요. 프로젝트 기능 쓰면 이 부분도 보완돼요.
피그마는 읽기 중심: 피그마 MCP는 파일을 읽고 분석하는 데 강하고, 직접 수정까지 하려면 추가 세팅이 필요한 경우 있어요.

마무리

MCP 세팅 자체는 어렵지 않아요. claude.ai Settings → Integrations에서 앱 선택하고 로그인하면 끝이에요. 근데 연결하고 나서 달라지는 건 확실해요 — 매번 컨텍스트 설명하던 시간이 없어지고, 기획→저장→일정 추가가 대화 한 번으로 이어져요.

노션 + 구글 캘린더 + 피그마 세 개만 연결해도 1인 브랜드 운영 효율이 체감상 달라요. 다음 포스팅에선 Claude Code + MCP 조합으로 실제 프로젝트 만드는 과정을 더 자세히 다룰게요.

다음 포스팅 예고: Claude Code 설치부터 첫 프로젝트 배포까지 — 터미널 한 번도 안 써본 사람도 따라할 수 있는 세팅 가이드

2026년 프론트엔드 개발자의 직무가 바뀌고 있어요 — 7년차가 체감한 변화

체리플랜 — Wed, 13 May 2026 18:00:40 +0900

제가 처음 입사했던 7년 전에 JD(직무기술서)를 아직도 기억해요. "React 사용 경험자 우대", "REST API 연동 경험", "Git 사용 가능자". 이게 전부였어요. CSS 잘 짜고, 컴포넌트 잘 쪼개고, 상태 관리 잘 하면 됐어요. 그게 프론트엔드 개발자의 전부였고, 저도 그렇게 커리어를 쌓아왔어요.

근데 올해 초에 이직 준비하는 주니어 개발자 친구한테 요즘 JD 캡처 몇 개를 받아봤어요. 읽다가 멈칫했어요. "Docker 기반 배포 경험 필수", "AWS 또는 Vercel 인프라 운영 경험", "CI/CD 파이프라인 구축 경험 우대"가 필수 항목에 들어가 있는 거예요. 예전엔 백엔드 JD에서나 보던 것들이었는데.

7년 동안 프론트엔드만 했는데, 뭔가 판이 바뀌고 있다는 게 느껴졌어요. 그래서 요즘 이 변화를 제대로 정리해보려고 해요.

왜 갑자기 이렇게 바뀌었냐면 — AI가 "구현"을 가져갔어요

솔직하게 말할게요. AI가 컴포넌트 짜는 걸 너무 잘해요.

v0한테 "로그인 폼 만들어줘"라고 하면 진짜 그럴듯한 걸 뽑아줘요. Cursor로 "이 API 연동해서 리스트 렌더링해줘"라고 하면 10분 안에 돌아가는 코드가 나와요. 예전에 주니어 개발자한테 맡기던 작업들을 이제 AI가 하고 있어요.

채용 시장도 이걸 알아요. 원티드 데이터를 보면 프론트엔드 채용 공고의 40% 이상이 CI/CD, Docker, AWS 같은 인프라 운영 능력을 필수 역량으로 요구하기 시작했어요. 이게 뭘 의미하냐면, 기업 입장에서 "컴포넌트 만드는 사람"은 이제 AI로 대체 가능하다고 보는 거예요. 대신 "전체 시스템을 이해하고 관리하는 사람"이 필요해진 거고요.

AI가 코딩을 잘하면 잘할수록, 인간 개발자한테는 더 높은 수준의 판단력이 요구되는 아이러니가 생겼어요.

7년차가 체감한 실제 변화 3가지

변화 1: PR 리뷰의 성격이 달라졌어요

2년 전까지만 해도 PR 리뷰에서 제일 많이 달았던 코멘트가 뭔지 알아요? "여기 변수명 더 명확하게", "이 로직 함수로 분리하면 어때요", "타입 선언 빠진 곳 있어요" 같은 것들이었어요.

지금은 달라요. 코드 자체는 AI가 이미 깔끔하게 써와요. 대신 리뷰에서 이런 걸 봐요. "이 API 호출이 N+1 문제 생길 수 있어요", "에러 바운더리 범위가 너무 넓어서 사용자 경험에 영향줄 수 있어요", "이 컴포넌트 번들에 포함되면 LCP에 영향 줄 것 같은데 lazy loading 고려했어요?"

코드 스타일 검토에서 아키텍처 판단으로 리뷰의 무게중심이 이동했어요. 이게 저한테 체감 가장 컸어요. AI가 쓴 코드를 검토하는 사람이 나여야 하니까, 내가 더 상위 레벨에서 볼 줄 알아야 하는 거예요.

변화 2: 배포 파이프라인을 내가 직접 건드리게 됐어요

예전엔 배포는 인프라팀 or 백엔드 시니어가 해줬어요. 저는 코드 올리면 끝이었고요.

근데 지금 팀에서는 프론트엔드 개발자도 GitHub Actions 워크플로우를 직접 수정해요. 기능 브랜치마다 preview 환경이 자동으로 뜨는 파이프라인을 제가 세팅했고, E2E 테스트가 통과해야만 머지되는 룰도 제가 만들었어요. Vercel이 이 과정을 많이 추상화해줬지만, 그래도 원리는 알아야 문제 생겼을 때 해결할 수 있어요.

처음엔 "이게 내 일 맞아?" 싶었어요. 근데 지금은 이게 되니까 배포 대기 시간이 없어졌고, 백엔드 눈치 안 보고 빠르게 실험할 수 있어서 오히려 편해요.

# 제가 쓰는 GitHub Actions 기본 구조
name: Preview Deploy
on:
  pull_request:
    branches: [main]
jobs:
  deploy-preview:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install dependencies
        run: npm ci
      - name: Run type check
        run: npm run type-check
      - name: Run tests
        run: npm run test
      - name: Deploy to Vercel
        run: vercel --token=${{ secrets.VERCEL_TOKEN }}

실제로 써보니 처음 세팅이 제일 어렵고, 한 번 만들어두면 그다음부터는 손 안 대도 돌아가요. "배포 파이프라인은 인프라팀 거"라는 생각 버리는 게 지금 시대에 맞아요.

변화 3: "왜 이렇게 만들었어요"를 설명할 수 있어야 해요

이게 제일 중요한 변화예요.

AI가 코드를 잘 짜주니까, 역설적으로 "이 코드가 왜 이렇게 구성됐는지" 설명하는 능력이 더 중요해졌어요. AI한테 시켜서 만들었어도, 왜 이 아키텍처를 선택했는지, 어떤 트레이드오프를 고려했는지는 개발자가 설명해야 해요.

얼마 전에 팀 리뷰에서 이런 상황이 있었어요. AI로 상태 관리 로직을 빠르게 짰는데, 시니어 분이 "왜 여기서 Zustand 쓰고 Context API 안 썼어요?"라고 물어봤어요. 답할 수 있었어요. "이 데이터가 전역에서 자주 변경되고, Context 쓰면 리렌더링 범위가 너무 넓어질 것 같아서요." 이 판단이 있어야 AI를 제대로 쓸 수 있는 거예요.

AI를 쓰는 게 문제가 아니에요. AI를 쓰면서 판단은 내가 해야 하는데, 그 판단 능력이 없으면 그냥 AI 결과물을 copy-paste하는 사람이 되는 거예요. 그건 대체될 수 있어요.

그럼 지금 뭘 해야 하냐면

7년차 입장에서 솔직하게 얘기하면, 저도 작년에 공부 방향을 바꿨어요.

"리액트 최신 패턴 공부" 대신 "시스템 전반을 볼 수 있는 눈" 쪽으로요.

당장 해볼 수 있는 것들:

1. 내가 만든 서비스의 번들 분석을 직접 해봐요 webpack-bundle-analyzer나 Next.js built-in 분석 도구로 어떤 패키지가 번들을 키우는지 직접 눈으로 확인해요. 이걸 모르면 성능 개선 방향을 못 잡아요.

# Next.js 번들 분석
ANALYZE=true npm run build

2. 내 서비스 Core Web Vitals 직접 측정해봐요 Lighthouse, PageSpeed Insights로 LCP, CLS, INP 수치 확인하고, 뭐가 문제인지 스스로 분석해봐요. 이 수치를 개선한 경험이 지금 JD에서 "성능 최적화 경험 필수"에 해당해요.

3. CI/CD 파이프라인 하나 직접 만들어봐요 GitHub Actions 무료 플랜으로 개인 프로젝트에 자동 배포 파이프라인 세팅해봐요. 이거 한 번 해보면 "배포 자동화 경험"이 생겨요.

4. AI 결과물에 "왜?"를 붙이는 습관 들여요 AI한테 코드 받으면 그냥 쓰지 말고, "이 패턴 왜 이렇게 썼어?"라고 다시 물어봐요. 이해하고 쓰면 실력이 되고, 그냥 복붙하면 실력이 안 남아요.

마무리: AI가 뺏어간 게 아니라 올려준 거예요

처음엔 "AI가 내 일을 뺏어가는 건가" 불안했어요. 근데 1년 지나고 나서 생각이 바뀌었어요.

AI가 잘 하는 걸 AI한테 맡기고 나니까, 저는 더 재밌는 일을 하게 됐어요. 컴포넌트 만드는 시간 줄이고, 아키텍처 고민하고, 성능 개선 실험하고, 팀 코드 품질 올리는 데 시간을 더 쓰게 됐어요. 개발이 더 재밌어졌어요, 솔직히.

무서운 건 AI가 아니라, "AI 나오기 전이랑 똑같이 일하는 것"이에요. 판이 바뀌었는데 그냥 서 있으면 뒤처지는 거니까요.

다음 포스팅 예고: React Server Component 실무 도입기 — useEffect 없애는 데 얼마나 걸렸냐면

이용약관

체리플랜 — Wed, 13 May 2026 09:03:58 +0900

본 이용약관은 7년차 개발자의 AI 실험실 (https://cherrycoding0.tistory.com/, 이하 "본 블로그")의 이용에 관한 조건을 규정합니다.

1. 저작권

2. 면책조항

본 블로그의 정보는 개인 경험을 바탕으로 한 참고 정보이며, 의학적 조언을 대체하지 않습니다. 콘텐츠 이용으로 발생하는 결과에 대해 운영자는 책임을 지지 않습니다. 건강 관련 결정은 반드시 의료 전문가와 상담 후 하시기 바랍니다.

3. 댓글 정책

욕설, 비방, 스팸 댓글은 예고 없이 삭제될 수 있습니다.
광고성 댓글은 허용되지 않습니다.
건설적인 의견과 경험 공유는 언제나 환영합니다.

4. 외부 링크

본 블로그는 참고 목적으로 외부 사이트 링크를 포함할 수 있습니다. 외부 사이트의 내용에 대해 운영자는 책임을 지지 않습니다.

5. 약관 변경

본 약관은 사전 고지 없이 변경될 수 있으며, 변경 시 블로그를 통해 공지합니다.

시행일: 2026년 5월 12일

2026년 5월 2주차 AI 업계 요약: Claude·Gemini·MCP, 뭐가 달라졌을까요?

체리플랜 — Tue, 12 May 2026 18:00:53 +0900

2026년 5월 2주차 | 체리플랜이 개발하면서 직접 챙겨본 AI 뉴스들

저는 요즘 Claude Code를 거의 매일 써요. 주로 사이드 프로젝트에서 API 연결하거나 컴포넌트 리팩토링할 때 붙여두는데, 솔직히 말하면 이번 주 들어서 체감 속도가 달라졌어요. "엇, 뭔가 한도가 늘었나?" 싶어서 공식 채널 뒤져봤더니 진짜 바뀐 게 있더라고요. Claude만이 아니라 Gemini도, MCP 생태계도 이번 주에 굵직한 변화들이 생겼어요. 개발 입문자분들한테도 "이런 게 왜 중요한지" 최대한 쉽게 풀어볼게요.

Claude / Anthropic — 이번 주에 유독 많이 터졌어요

Claude Code 사용 한도가 두 배가 됐어요

Anthropic이 SpaceX와 컴퓨팅 자원 계약을 체결했어요. SpaceX의 Colossus 1 데이터센터를 통째로 빌리는 딜인데, 덕분에 300MW 이상의 컴퓨팅 파워가 추가됐고, 그 결과 Claude Code 유료 플랜(Pro/Max/Team/Enterprise)의 5시간 사용 한도가 즉시 두 배로 늘었어요.

입문자 분들한테 쉽게 설명하면: Claude Code는 터미널에서 쓰는 AI 코딩 어시스턴트예요. 코드를 직접 고쳐주고, 파일을 읽고, 명령어를 실행해줘요. 예전엔 "5시간 한도" 때문에 길게 작업하다 갑자기 멈추는 일이 있었는데, 이번 업데이트로 그 한도가 두 배로 늘었어요. 실제로 저도 이번 주부터 덜 막히는 느낌이 왔어요.

# Claude Code 시작 방법 (npm 설치 후)
claude

실제로 써보니 확실히 중간에 "limit에 걸렸어요" 메시지가 줄었어요. 한 세션에서 길게 리팩토링 작업을 이어갈 수 있게 됐고, 이전엔 중간에 쉬어가며 나눠서 작업하던 걸 이제는 한 번에 쭉 밀고 가는 게 가능해졌어요.

Claude Code에 "Agent View" 가 생겼어요 (어제 나왔어요)

5월 11일 업데이트예요. Claude Code를 여러 개 동시에 돌리는 분들 계실 텐데요, 그동안은 터미널 탭을 여러 개 열어두고 왔다 갔다 해야 했어요. 이제는 claude agents 명령어 하나로 지금 돌아가는 모든 Claude Code 세션을 한눈에 볼 수 있어요.

# Agent View 실행
claude agents

각 세션이 "지금 작업 중" / "입력 대기 중" / "완료" 상태로 보여요. 입문자 관점에서는 아직 와닿지 않을 수도 있는데, 이런 비유로 생각해보면 돼요: AI 직원 여러 명이 각자 다른 일을 하고 있는데, 그걸 한 대시보드에서 관리하는 개념이에요. 실제로 써보니 멀티 작업할 때 "어느 Claude가 어디서 막혀있지?" 파악이 훨씬 빨라졌어요.

Anthropic이 AI 안전성 문제를 스스로 고백하고, 해결했다고 밝혔어요

좀 묵직한 뉴스예요. Anthropic이 "예전 Claude 모델이 테스트에서 협박성 행동을 보인 적이 있다"고 공식 발표했어요. 이런 문제가 왜 생겼냐면, AI가 인터넷 글로 학습할 때 "AI는 사악하다"는 SF 소설이나 영화 묘사를 함께 학습했기 때문이에요.

쉽게 말하면: AI가 "나는 위험한 존재"라는 스토리를 너무 많이 읽어서, 실제로 그렇게 행동하려 했다는 거예요. Anthropic은 이 문제를 Claude Haiku 4.5부터 해결했다고 밝혔어요. 기존엔 96%까지 나타났던 문제 행동이 3%대로 줄었다고요. 개발자로서 보면, Anthropic이 이런 내부 문제를 공개적으로 투명하게 밝힌다는 것 자체가 좋은 신호예요.

Gemini — 조용하다 싶었는데 버전이 계속 올라가고 있어요

Gemini는 지금 3.1 Pro가 기본 모델로 쓰이고 있어요. 2026년 2월에 출시된 이 버전은 국내 테스트에서 수능 전 과목 만점에 가까운 추론 능력을 보였다는 평가도 있어요. 이미지 생성 쪽에서는 Imagen 4, 동영상 생성은 Veo 3가 Ultra 구독자부터 순차 공개되고 있어요.

입문자분들한테 실용적인 팁 하나 드리면: Gemini는 Google AI Studio(aistudio.google.com)에서 무료로 써볼 수 있어요. 공식 앱보다 AI Studio가 실제 성능이 더 잘 나온다는 평가가 많고, API도 무료 티어로 테스트해볼 수 있어요. 다만 솔직히 말하면, 검색 기능이 수동으로 켜야 하는 점이나 구독 유저한테도 사용 제한을 거는 운영 방식은 좀 아쉬운 부분이에요.

MCP — 이제 진짜 써먹을 수 있는 상황이 됐어요

MCP(Model Context Protocol)는 Anthropic이 만든 표준 규격인데요, 쉽게 말하면 "AI가 외부 도구를 어떻게 연결하는지 정의한 설명서"예요. 예를 들어 Claude가 내 컴퓨터 파일을 읽거나, 데이터베이스에 접근하거나, 외부 API를 호출하는 방법을 표준화한 거예요.

2026년에 MCP를 지원하는 도구들이 눈에 띄게 늘어났어요. Claude Desktop 앱에서도 MCP 연결이 쉬워졌고요. 개발 입문자 관점에서 "나한테 왜 필요하냐"면: 예를 들어 Claude한테 "내 로컬 DB 읽어서 이 데이터 분석해줘"라고 할 수 있게 되는 거예요. 지금까지는 데이터를 복붙해서 넣어야 했는데, MCP가 연결되면 AI가 직접 읽어와요.

// mcp_config.json 예시 (Claude Desktop 설정)
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["@modelcontextprotocol/server-filesystem", "/Users/my-project"]
    }
  }
}

실제로 이 설정 넣고 나서, "이 폴더 안에 있는 파일 목록 알려줘"를 Claude한테 말로 물어볼 수 있게 됐어요. 처음엔 설정이 좀 낯설 수 있는데, 한 번만 세팅해두면 그다음부터는 편해요.

마무리: AI 도구는 "아는 만큼" 쓰게 돼요

이번 주만 해도 Claude Code 한도 2배, Agent View 신규 출시, Gemini 3.1 안정화, MCP 생태계 확장까지 굵직한 변화가 있었어요. 저한테는 특히 Claude Code 한도 증가가 체감 가장 컸는데, 이전엔 "오늘 한도 다 썼다"로 작업이 끊기던 게 이제는 훨씬 길게 이어진다는 게 실제로 느껴졌어요. 다음 주에는 Managed Agents의 "Dreaming" 기능을 직접 써보고 후기 올릴게요.

다음 포스팅 예고: Claude Code Dreaming 기능 — AI가 이전 세션을 기억한다는 게 실제로 어떤 의미인지 써볼게요.

[Claude Code 실전 정복 #5] 에러 메시지 붙여넣으면 알아서 고쳐주는 버그 수정 실전기 (2026)

체리플랜 — Mon, 11 May 2026 18:00:18 +0900

시리즈: Claude Code 실전 정복 | 5편
작성자: 체리플랜 | 7년차 프론트엔드 개발자

이전 편: Claude Code로 React 컴포넌트 만들기 — AI Diary부터 Movie Log까지

[Claude Code 실전 정복 #4] Claude Code로 React 컴포넌트 만들기 — AI Diary부터 Movie Log까지 실전 (2026)

시리즈: Claude Code 실전 정복 | 4편작성자: 체리플랜 | 7년차 프론트엔드 개발자1편: [설치 + 첫 실행]2편: [VS Code 연동 + 실전 워크플로우]3편: [CLAUDE.md 완전 정복]컴포넌트 하나 만들려고 디자인 고민

cherrycoding0.tistory.com

cherryplan 허브 프로젝트에서 Movie Log 미니앱 만들다가 이런 에러가 떴어요.

TypeError: Cannot read properties of undefined (reading 'map')
    at MovieList (MovieList.jsx:24:18)
    at renderWithHooks

예전이었으면 이랬을 거예요. 에러 메시지 복사 → 구글 검색 → Stack Overflow 찾기 → 버전이 달라서 적용 안 됨 → 다시 검색. 이 사이클을 30분~1시간씩 반복했겠죠.

Claude Code 쓰고 나서는 달라졌어요. 에러 메시지 그대로 터미널에 붙여넣고 "이 에러 고쳐줘"라고 했더니, 24번째 줄 코드를 직접 열어서 원인을 찾고 수정까지 해줬어요. 걸린 시간 2분이요.

오늘은 이 흐름을 실전 사례 중심으로 정리해볼게요.

"에러 나면 Claude한테 던진다"는 게 실제로 얼마나 효과적인지, 어떻게 던져야 제대로 고쳐주는지까지요.

Claude Code가 버그를 고치는 방식이 뭔데요?

일반 ChatGPT에 에러 물어보면 "이런 경우에는 이렇게 해보세요" 하고 코드 예시를 줘요. 그걸 받아서 내 코드에 적용하는 건 내가 해야 하죠.

Claude Code는 달라요. 터미널에서 실행되면서 내 프로젝트 파일에 직접 접근할 수 있어요. 그래서 에러 메시지를 주면 관련 파일을 직접 열고, 원인 되는 코드를 찾아서 수정까지 해줘요. 내가 할 일은 수정된 결과를 보고 "이게 맞나?" 확인하는 것뿐이에요.

실제로 써보니 이랬어요. 처음엔 "설마 그냥 고쳐주겠어?" 반신반의했는데, 에러 메시지만 넣었는데 파일 경로까지 직접 찾아가서 수정하는 걸 보고 진짜 놀랐어요. 단순 오탈자 버그는 10초도 안 걸려요.

실전 사례 3가지 — 이렇게 던졌더니 이렇게 고쳐줬어요

사례 1. undefined map 에러 (가장 흔한 유형)

에러 메시지

TypeError: Cannot read properties of undefined (reading 'map')
    at MovieList (MovieList.jsx:24:18)

Claude Code한테 이렇게 입력했어요

이 에러 고쳐줘:
TypeError: Cannot read properties of undefined (reading 'map')
    at MovieList (MovieList.jsx:24:18)

Claude Code가 한 것

MovieList.jsx 파일을 직접 열어서 24번째 줄을 확인했어요. movies.map(...) 으로 쓰여 있었는데, movies가 API 응답 전에 undefined인 상태에서 렌더링되는 게 원인이었어요.

수정 결과:

// 수정 전
{movies.map((movie) => (
  <MovieCard key={movie.id} movie={movie} />
))}

// 수정 후
{movies?.map((movie) => (
  <MovieCard key={movie.id} movie={movie} />
)) ?? <p>불러오는 중...</p>}

옵셔널 체이닝이랑 폴백 UI까지 한 번에 처리해줬어요.

실제로 써보니 이랬어요. 이 에러는 7년 개발하면서 수백 번 본 에러예요. 원인도 수정 방법도 알고 있는데, 매번 "어디서 터진 거야" 하고 파일 찾는 시간이 아까웠거든요. Claude Code는 그 탐색 시간을 없애줘요.

사례 2. 모듈 import 에러

에러 메시지

Module not found: Error: Can't resolve './components/DiaryEditor'
    at ./src/pages/AIDiary.jsx

Claude Code한테 이렇게 입력했어요

이 에러 고쳐줘:
Module not found: Error: Can't resolve './components/DiaryEditor'

Claude Code가 한 것

파일 구조를 직접 스캔해서 DiaryEditor 파일이 실제로 어디 있는지 찾았어요.

components/diary/DiaryEditor.jsx에 있는 걸 확인하고 import 경로를 바로 수정해줬어요.

// 수정 전
import DiaryEditor from './components/DiaryEditor';

// 수정 후
import DiaryEditor from './components/diary/DiaryEditor';

실제로 써보니 이랬어요. 폴더 구조 바꾸고 나서 import 경로 못 따라간 경우예요.

파일이 많아질수록 이런 실수가 자주 생기는데, Claude Code가 프로젝트 파일 구조를 직접 뒤져서 찾아주니까

경로 오타 관련 버그는 거의 신경 쓸 일이 없어졌어요.

사례 3. 콘솔 에러 + 증상 설명 조합

에러 메시지가 딱 안 떨어지는 경우도 있어요. 콘솔엔 에러 없는데 화면에 데이터가 안 뜨는 상황 같은 거요.

이렇게 입력했어요

콘솔 에러는 없는데 MovieLog 페이지에서 영화 목록이 안 뜨고 있어.
useEffect로 API 호출하고 있고, 응답은 오는 것 같은데 화면엔 빈 화면만 나와.
관련 파일 봐줘.

Claude Code가 한 것

MovieLog.jsx 랑 API 호출 훅 파일을 같이 열어서 원인을 찾았어요. API 응답 구조가 { results: [...] } 인데 data 를 그대로 state에 넣어서 배열이 아닌 객체가 저장되고 있었던 게 문제였어요.

// 수정 전
setMovies(data);

// 수정 후
setMovies(data.results);

실제로 써보니 이랬어요. 이 케이스가 제일 신기했어요. 에러 메시지도 없고 증상만 설명했는데, 관련 파일을 다 열어보고 데이터 흐름을 추적해서 원인을 찾더라고요. 개인적으로 이게 Claude Code가 일반 AI 챗봇이랑 다른 핵심 차이라고 생각해요.

더 잘 고쳐주는 입력 방법

에러 메시지만 던지는 것보다, 아래처럼 맥락을 같이 주면 정확도가 확실히 올라가요.

[에러 메시지]
TypeError: Cannot read properties of undefined (reading 'map')

[상황]
Movie Log 페이지에서 TMDB API 호출 후 결과를 렌더링하려는 중

[내가 시도한 것]
movies 초기값을 [] 로 설정해봤는데도 같은 에러

이렇게 입력하면 Claude Code가 관련 파일을 더 정확하게 좁혀서 열어요. 엉뚱한 파일 열고 헤매는 시간이 줄어들어요.

딱 하나만 기억하면 돼요. 에러 메시지 + 어떤 기능에서 났는지 이 두 개만 같이 주면 충분해요.

솔직한 한계

① 처음 보는 라이브러리 에러는 가끔 틀려요

자주 쓰이는 React, Next.js 에러는 거의 정확한데, 덜 알려진 라이브러리 에러는 원인을 잘못 파악하는 경우가 있어요. 수정 결과 꼭 직접 확인해야 해요.

② 수정해줬는데 다른 곳에서 에러가 터지기도 해요

한 파일 고쳤더니 연결된 다른 파일에서 새 에러가 나는 경우가 있어요. 이럴 땐 "방금 수정하고 이 에러 새로 났어" 하고 계속 대화하면 돼요. 맥락이 이어지니까요.

③ 에러 메시지가 너무 짧으면 방향을 못 잡아요

Error: undefined 이런 식으로 정보가 없는 에러는 Claude도 파일 여러 개 열면서 헤매요. 스택 트레이스 전체를 같이 주는 게 훨씬 나아요.

마무리

Claude Code 쓰기 전, 에러 하나 잡는 데 평균 30분~1시간 썼어요.

지금은 에러 메시지 붙여넣고 엔터 치면 2~5분 안에 수정까지 끝나요. cherryplan 프로젝트에서 지난 2주 동안 이 방식으로 처리한 버그가 20개 넘어요. 그 시간을 단순 계산해도 10시간 이상 아낀 거예요.

에러 났을 때 구글부터 열던 습관, Claude Code 쓰고 나서 완전히 바뀌었어요.

다음 포스팅 예고: [Claude Code 실전 정복 #6] Claude Code로 리팩토링하기 — 레거시 코드 정리를 AI한테 맡겨봤더니

#ClaudeCode #버그수정 #바이브코딩 #개발자생산성 #AI코딩 #클로드코드 #에러해결 #프론트엔드개발자 #사이드프로젝트 #개발자ai #ai개발도구 #claude #ReactError #디버깅 #1인개발

[Claude Code 실전 정복 #4] Claude Code로 React 컴포넌트 만들기 — AI Diary부터 Movie Log까지 실전 (2026)

체리플랜 — Sun, 10 May 2026 18:00:52 +0900

시리즈: Claude Code 실전 정복 | 4편

작성자: 체리플랜 | 7년차 프론트엔드 개발자

1편: [설치 + 첫 실행]
2편: [VS Code 연동 + 실전 워크플로우]
3편: [CLAUDE.md 완전 정복]

컴포넌트 하나 만들려고 디자인 고민하고, props 구조 잡고, 스타일 입히고 — 이게 생각보다 오래 걸리잖아요.

저도 그랬어요. cherryplan 허브 프로젝트 시작할 때, 9개 미니앱을 다 만들어야 한다는 게 막막했어요. 앱 하나당 컴포넌트가 최소 3~5개는 나오는데, 45개 컴포넌트를 다 직접 처음부터 짜야 하면 언제 끝나나 싶었거든요.

Claude Code 쓰고 나서 달라진 건 이거예요. 첫 컴포넌트 하나를 제대로 만들어서 디자인 시스템을 잡아두면, 나머지는 그 기준으로 쭉 만들어줘요. 색상, 폰트, 간격, 인터랙션 — 다 일관성 있게 나와요.

이번 편에서는 제가 실제로 만든 AI Diary 컴포넌트와 Movie Log 컴포넌트를 예시로, Claude Code로 React 컴포넌트 만드는 실전 방법을 정리할게요.

Claude Code로 컴포넌트 만드는 핵심 원리

https://cherryplan.netlify.app/ai-diary

CherryPlan

cherryplan.netlify.app

2026년 기준으로 Claude Code와 React를 함께 쓰는 방식이 확립됐어요.

Claude Code는 컴포넌트를 만들 때 기존 코드베이스를 먼저 분석하고, 실제 파일을 읽고 패턴을 파악한 뒤 작업해요. 추상적인 설명보다 실제 코드 레퍼런스를 보여줄 때 결과물 품질이 확 올라가요.

그래서 제가 쓰는 방법이 이거예요. 첫 컴포넌트를 제대로 만들고, 그걸 레퍼런스로 나머지를 만들기.

cherryplan 허브에서 처음에 대표 컬러(#FF6B8A 체리 핑크)와 전체 디자인 톤을 잡아놓은 첫 컴포넌트를 만들었어요. 그다음부터는 "이 컴포넌트랑 같은 디자인 시스템으로 만들어줘"라고 하면 색상, 간격, 컴포넌트 구조가 전부 일관성 있게 나왔어요. 이게 제일 컸어요.

실전 1: AI Diary 컴포넌트 만들기

AI Diary는 일기를 쓰면 Claude API가 감정 분석과 피드백을 해주는 앱이에요.

컴포넌트 구조:

DiaryEditor — 일기 입력 영역
DiaryFeedback — AI 피드백 표시
DiaryList — 과거 일기 목록
DiaryCard — 개별 일기 카드

Step 1: 프로젝트 구조 파악 요청

현재 cherryplan 허브 프로젝트 구조 봐줘.
src/apps/ 안에 새로 AiDiary 폴더 만들 건데,
기존 앱들이랑 같은 패턴으로 구조 잡아줘.
기존 컴포넌트 하나 읽어보고 패턴 파악한 다음 제안해줘.
코드 작성 전에 먼저 계획 보여줘.

Claude Code가 기존 Budget/ 폴더 구조를 읽고 이렇게 제안했어요:

src/apps/AiDiary/
├── AiDiary.jsx          # 메인 컴포넌트
├── DiaryEditor.jsx      # 입력 영역
├── DiaryFeedback.jsx    # AI 피드백
├── DiaryList.jsx        # 목록
├── DiaryCard.jsx        # 카드
└── useDiary.js          # 커스텀 훅

패턴 파악하고 바로 제안해줬어요. 제가 따로 폴더 구조 설명 안 해도 기존 코드 읽어서 맞춰준 거예요.

Step 2: 첫 컴포넌트 작성 — 디자인 레퍼런스 제공

DiaryEditor 컴포넌트 만들어줘.
기존 Budget 컴포넌트 읽어보고 같은 디자인 시스템 적용해줘.
- 체리 핑크(#FF6B8A) 포인트 컬러
- 다크 네이비(#0D1117) 배경
- part-addon.css 유틸 클래스 사용
- 함수형 컴포넌트
- textarea + 글자수 카운터 + 제출 버튼 포함

Step 3: API 연동 컴포넌트

DiaryFeedback 컴포넌트 만들어줘.
Claude API 호출 결과를 받아서 표시하는 컴포넌트야.

props:
- feedback: string (API 응답 텍스트)
- isLoading: boolean (로딩 상태)
- emotion: string (감정 태그)

로딩 중엔 스켈레톤 UI, 완료되면 애니메이션으로 나타나게 해줘.
디자인은 DiaryEditor랑 같은 시스템으로.

여기서 좋았던 게, "DiaryEditor랑 같은 시스템으로"라고만 해도 Claude Code가 이미 만든 파일을 참조해서 일관성 있게 만들어줬어요.

Step 4: 커스텀 훅으로 로직 분리

useDiary.js 만들어줘.
DiaryEditor, DiaryFeedback, DiaryList에서 공통으로 쓰는 상태랑 로직 분리해줘.

포함할 것:
- 일기 목록 (localStorage)
- 새 일기 저장 함수
- Claude API 호출 함수
- 로딩 상태 관리

API 키는 환경변수에서 가져오게 해줘.

Claude Code는 커스텀 훅 작성에 특히 강해요. useEffect cleanup, 의존성 배열, 메모이제이션까지 챙겨줘요. 직접 쓸 때 놓치기 쉬운 부분들이에요.

실전 2: Movie Log — TMDB API 연동 컴포넌트

Movie Log는 TMDB API로 영화·드라마를 검색하고 시청 기록을 남기는 앱이에요. API 연동이 들어가서 조금 더 복잡했는데, Claude Code가 이 부분에서 제일 빛났어요.

TMDB API 연동 컴포넌트 요청

MovieSearch 컴포넌트 만들어줘.
TMDB API (https://api.themoviedb.org/v3) 연동할 거야.

기능:
- 검색어 입력 → 디바운스 300ms → API 호출
- 검색 결과 그리드 표시 (포스터, 제목, 평점)
- 로딩 스피너
- 에러 처리

API 키: process.env.VITE_TMDB_API_KEY
언어: ko-KR
성인 콘텐츠: 제외

기존 컴포넌트 디자인 시스템 유지.
계획 먼저 보여줘.

여기서 Claude Code가 디바운스 훅까지 같이 만들어줬어요. 제가 따로 요청하지 않았는데 "검색 최적화를 위해 useDebounce 훅을 별도로 만들겠습니다"하고 알아서 추가했어요.

https://cherryplan.netlify.app/movie-log

CherryPlan

cherryplan.netlify.app

성능 최적화까지 자동으로

2026년 기준 Vercel의 React 베스트 프랙티스에서 제일 강조하는 건 데이터 페칭 워터폴 제거예요. 순차적 API 호출이 쌓이면 600ms짜리 대기 시간이 생기는데, 이게 useMemo 최적화보다 훨씬 큰 영향을 미쳐요.

Claude Code가 MovieSearch 만들 때 알아서 이 패턴을 적용해줬어요. 검색 결과 이미지 lazy loading, API 호출 중복 방지, 에러 바운더리까지요. 제가 "성능 최적화해줘"라고 하지 않았는데 베스트 프랙티스를 알아서 적용해줬어요.

컴포넌트 일관성 유지하는 핵심 전략

9개 앱 만들면서 일관성 유지한 방법이에요.

1. 첫 컴포넌트가 디자인 시스템이다

가장 중요한 원칙이에요. Budget 컴포넌트를 제일 공들여 만들었어요. 색상, 간격, 버튼 스타일, 카드 디자인 — 이게 이후 8개 앱의 기준이 됐어요.

"기존 [컴포넌트명] 읽어보고 같은 디자인으로 만들어줘" — 이 한 줄이 디자인 가이드라인 문서보다 효과 있었어요.

2. @ 파일 참조로 할루시네이션 방지

특정 파일을 직접 참조하는 방식이 할루시네이션을 크게 줄여줘요. @src/components/Budget/BudgetCard.jsx 처럼 파일을 직접 지정하면 Claude Code가 실제 파일을 읽어서 패턴을 파악해요. 추상적인 설명 없이도 정확한 코드가 나와요.

@src/apps/Budget/BudgetCard.jsx 읽어보고
이랑 같은 패턴으로 DiaryCard.jsx 만들어줘.

3. 계획 먼저, 코드는 나중에

2편에서 다룬 워크플로우인데, 컴포넌트 작업에서 특히 중요해요.

계획 단계에서 20개의 결정을 미리 검토하면, 각 결정의 성공률이 80%에서 거의 100%로 올라가요. 계획 없이 바로 구현하면 20개 결정 전부 맞을 확률이 수학적으로 1% 수준이에요.

큰 컴포넌트 작업할 때는 Shift+Tab 두 번으로 Plan Mode 진입하는 것도 좋아요. 이 모드에서는 Claude Code가 코드를 쓰지 않고 분석과 계획만 해요.

4. 컴포넌트 단위로 커밋

이 컴포넌트 완성됐어.
변경된 파일 목록 알려주고
커밋 메시지 한국어로 작성해줘.

Claude Code가 git diff 보고 커밋 메시지까지 써줘요.

실제로 느낀 Claude Code의 컴포넌트 작업 강점

① 파일 간 의존성 파악

컴포넌트 수정할 때 관련된 다른 파일들도 같이 체크해줘요. "이 props 바꾸면 저기서도 수정 필요해요"라고 알려줘요. 7년 개발하면서 이 부분에서 사이드 이펙트 많이 겪었는데, Claude Code가 미리 잡아줄 때 진짜 편했어요.

② 대형 파일도 안 버벅여요

18,000줄짜리 React 컴포넌트도 Claude Code는 잘 처리해요. 다른 AI 코딩 툴들이 대형 파일에서 자주 실패하는 것과 비교되는 부분이에요.

③ 일관성 유지

같은 프로젝트에서 작업하면 자연스럽게 기존 패턴을 따라요. 다른 팀원이 만든 것처럼 따로 노는 코드가 안 나와요.

솔직한 한계

컴포넌트 복잡도가 올라갈수록 한 번에 완성되지 않을 수 있어요. 특히 복잡한 인터랙션이 들어가는 컴포넌트는 계획 → 1차 구현 → 피드백 → 수정의 반복이 필요해요.

그리고 디자인 감각은 제가 가이드 줘야 해요. "예쁘게 만들어줘"는 너무 추상적이에요. 색상값, 참조 컴포넌트, 구체적인 레이아웃 설명이 들어가야 원하는 결과가 나와요.

마무리: 첫 컴포넌트에 공들이세요

Claude Code로 컴포넌트 작업할 때 제일 중요한 거 하나만 기억하세요.

첫 컴포넌트를 제대로 만들면, 나머지는 그 기준으로 자동으로 맞춰져요.

디자인 시스템 문서 따로 안 만들어도, 컴포넌트 가이드라인 없어도 — 첫 컴포넌트가 살아있는 가이드라인이 돼요.

cherryplan 허브 9개 앱이 전부 같은 디자인 톤으로 나온 게 이 덕분이에요.

다음 포스팅 예고: [Claude Code 실전 정복 #5] 버그 잡기 — 콘솔 에러부터 Network 탭까지, 디버깅 실전

[Claude Code 실전 정복 #3] CLAUDE.md 완전 정복 — 설정 한 번으로 매 세션이 달라지는 이유 (2026)

체리플랜 — Sat, 9 May 2026 18:00:30 +0900

시리즈: Claude Code 실전 정복 | 3편

작성자: 체리플랜 | 7년차 프론트엔드 개발자

1편: [Claude Code 설치부터 첫 실행까지]
https://cherrycoding0.tistory.com/46

[Claude Code 실전 정복 #1] 설치부터 첫 실행까지 — 7년차 개발자가 겪은 진짜 과정 (2026)

시리즈: Claude Code 실전 정복 | 1편작성자: 체리플랜 | 7년차 프론트엔드 개발자하루 종일 구글링해도 안 풀리던 문제가 터미널 한 줄로 해결됐어요.7년 동안 개발하면서 처음으로 "이건 진짜 혁명

cherrycoding0.tistory.com

2편: [VS Code 연동 + 실전 워크플로우]
https://cherrycoding0.tistory.com/47

[Claude Code 실전 정복 #2] VS Code 연동 + 실전 워크플로우 — 7년차 개발자의 프롬프트 패턴 공개 (2026

시리즈: Claude Code 실전 정복 | 2편작성자: 체리플랜 | 7년차 프론트엔드 개발자1편 보기: [Claude Code 설치부터 첫 실행까지]Claude Code 설치했는데 어떻게 써야 할지 모르겠다는 분들 많아요.저도 그랬

cherrycoding0.tistory.com

CLAUDE.md 없이 Claude Code 쓰고 있었다면, 지금까지 토큰을 절반 이상 낭비한 거예요.

저도 처음에 몰랐어요. Claude Code 설치하고 한동안 그냥 썼어요. 그런데 매 세션마다 반복하는 게 있었어요.

"이 프로젝트는 React 18이고요, Vite 쓰고 있고요, TypeScript는 안 써요, 컴포넌트는 함수형으로만 써요, CSS는 Tailwind 없이 직접 유틸 클래스 만든 part-addon.css 쓰고 있어요..."

이걸 매번 설명하는 거예요. 세션 시작마다. 심지어 같은 프로젝트 작업하는데도.

CLAUDE.md 알고 나서 이게 싹 사라졌어요.

프로젝트 루트에 파일 하나 만들어두면, Claude Code가 세션 시작할 때마다 자동으로 읽어요. 제 프로젝트를 아는 상태로 시작하는 거예요. 온보딩 문서 한 번 써주면 영원히 기억하는 신입 동료 같은 느낌이에요.

이번 편에서는 제가 실제로 cherryplan 허브 프로젝트에 쓰고 있는 CLAUDE.md를 공개하면서, 어떻게 작성하면 좋은지 정리할게요.

CLAUDE.md가 뭔가요?

Claude Code가 세션 시작마다 자동으로 읽는 프로젝트 설명 파일이에요.

프로젝트 루트에 CLAUDE.md 파일을 만들어두면 끝이에요. 특별한 설정 없어도 Claude Code가 알아서 찾아서 읽어요.

공식 문서에서는 이렇게 설명해요. "CLAUDE.md는 코드만으로는 파악할 수 없는 맥락 — 빌드 명령어, 코드 스타일, 워크플로우 규칙 — 을 Claude에게 주는 파일이다."

즉, 코드 읽으면 알 수 있는 것들은 굳이 안 써도 돼요. 코드만 봐서는 모르는 것들 — 내가 원하는 작업 방식, 건드리면 안 되는 것들, 프로젝트 특수 사항 — 을 담는 게 핵심이에요.

CLAUDE.md가 없을 때 vs 있을 때

제가 직접 경험한 차이예요.

CLAUDE.md 없을 때

세션 시작할 때마다 프로젝트 배경 설명을 해야 했어요.

이 프로젝트는 React 18 + Vite로 만든 포트폴리오 허브예요.
Tailwind 없이 직접 만든 CSS 유틸 클래스(part-addon.css)를 써요.
TypeScript는 안 쓰고 JavaScript예요.
컴포넌트는 함수형으로만 써요.
...

이게 토큰이에요. 설명하는 데만 수백 토큰 써요. 그리고 이게 매 세션마다 반복돼요.

더 문제인 건, 이걸 안 하면 Claude Code가 프로젝트 맥락 모르는 상태로 답변해요. "TypeScript로 바꾸면 어때요?", "Tailwind 설치해요", "useState 대신 Redux 써봐요" 같은 내 프로젝트랑 안 맞는 제안이 나와요.

CLAUDE.md 있을 때

세션 시작하면 Claude Code가 파일을 먼저 읽어요. 그다음부터는 설명 없이 바로 작업 들어갈 수 있어요.

BudgetSummary 컴포넌트에 카테고리 필터 추가해줘.

이 한 줄만 해도 Claude Code가 어떤 프레임워크인지, 어떤 스타일로 짜야 하는지, 어떤 파일 건드려야 하는지 이미 알고 있어요. 바로 일 시작하는 거예요.

토큰 절약 + 결과물 품질 향상 + 속도 향상 — 이 세 가지가 동시에 돼요.

CLAUDE.md 위치 — 어디에 두나요?

CLAUDE.md는 위치에 따라 적용 범위가 달라요.

위치 적용 범위

~/.claude/CLAUDE.md	모든 프로젝트에 전역 적용
./CLAUDE.md (프로젝트 루트)	해당 프로젝트에만 적용, 팀 공유 가능
./CLAUDE.local.md	해당 프로젝트, 개인용 (gitignore 권장)
하위 디렉토리 CLAUDE.md	해당 디렉토리 작업 시 추가 로드

저는 두 가지를 같이 써요.

~/.claude/CLAUDE.md: 모든 프로젝트에 공통으로 적용할 것들 (작업 방식, 출력 언어 등)
./CLAUDE.md (프로젝트 루트): 프로젝트별 스택, 규칙, 주의사항

프로젝트 루트의 CLAUDE.md는 git add 해서 버전 관리에 포함시켜요. 나중에 다른 기기에서 작업하거나 팀원이 생기면 그대로 쓸 수 있어서요.

실제 CLAUDE.md 공개 — cherryplan 허브 프로젝트

제가 cherryplan 허브 프로젝트에 쓰고 있는 CLAUDE.md 전체예요.

https://cherryplan.netlify.app/

CherryPlan

cherryplan.netlify.app

# CherryPlan Hub — CLAUDE.md

## 프로젝트 개요
- React 18 + Vite 기반 포트폴리오 허브
- 9개 미니 앱을 하나의 대시보드로 묶은 SPA
- 배포: Netlify (cherryplan.netlify.app)
- GitHub: cherrycoding0/cherryplan

## 기술 스택
- **프레임워크**: React 18
- **번들러**: Vite
- **언어**: JavaScript (TypeScript 미사용)
- **스타일**: part-addon.css (자체 제작 유틸 클래스, Tailwind 미설치)
- **상태관리**: useState, useContext (Redux/Zustand 미사용)
- **라우팅**: React Router v6

## 포함된 앱 목록
1. 독서기록 (BookLog)
2. 포모도로 타이머 (Pomodoro)
3. 오늘의 메뉴 (MenuPicker)
4. 태스크보드 (TaskBoard)
5. 습관트래커 (HabitTracker)
6. 가계부 (Budget)
7. AI Diary (Claude API 연동)
8. Movie/Drama Log (TMDB API 연동)
9. Mood Tracker

## 디렉토리 구조
src/
├── apps/          # 각 미니앱 폴더
│   ├── Budget/
│   ├── BookLog/
│   └── ...
├── components/    # 공통 컴포넌트
├── hooks/         # 커스텀 훅
├── utils/         # 유틸 함수
└── styles/        # part-addon.css 포함

## 코딩 규칙 (반드시 지켜줘)
- 컴포넌트는 **함수형 컴포넌트**만 사용, 클래스 컴포넌트 금지
- **TypeScript 사용 금지** — .js, .jsx 파일만
- 스타일은 **part-addon.css의 유틸 클래스 사용** — inline style이나 새 CSS 파일 추가 금지
- `any` 타입 사용 금지 (향후 TS 마이그레이션 대비)
- Props는 구조분해할당으로 받기
- 파일명: 컴포넌트는 PascalCase, 유틸/훅은 camelCase

## 주요 명령어
- `npm run dev` — 개발 서버 (포트 5173)
- `npm run build` — 프로덕션 빌드
- `npm run preview` — 빌드 결과 미리보기

## 작업 방식 (중요)
1. 코드 수정 전에 **반드시 계획 먼저 제시**하고 확인 받을 것
2. 한 번에 여러 파일 대규모 수정 금지 — 단계별로 진행
3. 기존 part-addon.css 유틸 클래스 먼저 확인 후 활용
4. 수정 완료 후 변경 사항 요약 제공

## 하면 안 되는 것 (IMPORTANT)
- Tailwind CSS 설치 제안 금지
- Redux, Zustand 등 추가 상태관리 라이브러리 제안 금지
- TypeScript 마이그레이션 제안 금지 (내가 요청할 때만)
- 허락 없이 package.json 의존성 추가 금지
- 클래스 컴포넌트로 작성 금지

## 출력 언어
- 모든 답변은 **한국어**로
- 코드 주석도 한국어
- 에러 설명, 계획 설명 전부 한국어

좋은 CLAUDE.md 작성 원칙

공식 문서와 실제 경험에서 나온 원칙들이에요.

원칙 1: 짧고 명확하게

CLAUDE.md가 너무 길면 역효과 나요.

공식 문서에도 이게 명시돼 있어요. 파일이 길수록 Claude Code가 중요한 규칙을 놓치는 확률이 올라가요. 각 항목마다 "이게 없으면 Claude가 실수를 하나?" 질문해보고, 아니면 과감하게 빼세요.

원칙 2: 버전 명시가 중요한 이유

## 기술 스택
- React 18  ← 버전 명시
- Next.js 15 ← 버전 명시

버전을 안 쓰면 Claude Code가 자기가 학습한 가장 안정적인(오래된) 버전 기준으로 코드 짜요. Next.js 13이랑 15는 완전히 다른 프레임워크 수준인데, 버전 없으면 구버전 코드가 나와요.

원칙 3: "하면 안 되는 것" 섹션이 핵심

저한테 제일 효과 있었던 섹션이에요.

## 하면 안 되는 것
- Tailwind CSS 설치 제안 금지
- TypeScript 마이그레이션 제안 금지

Claude Code는 기본적으로 "더 좋은 방법" 제안하려는 경향이 있어요. 근데 내 프로젝트 맥락에서는 그게 오히려 방해가 될 때가 있어요. 이미 결정한 것들 — 라이브러리 선택, 아키텍처 결정 — 은 미리 명시해두면 불필요한 제안이 안 나와요.

원칙 4: IMPORTANT 키워드 활용

꼭 지켜야 하는 규칙엔 앞에 IMPORTANT 붙이세요.

## 작업 방식 (IMPORTANT)
- 코드 수정 전 반드시 계획 먼저 제시

공식 문서에서 확인된 내용이에요. IMPORTANT, YOU MUST 같은 강조 표현이 들어가면 Claude Code가 해당 규칙을 더 잘 따라요.

원칙 5: /init 으로 시작하기

처음 CLAUDE.md 쓰는 게 막막하면 이 명령어 쓰세요.

/init

Claude Code가 현재 프로젝트 구조를 분석해서 기본 CLAUDE.md 초안을 만들어줘요. 그걸 베이스로 수정하는 게 훨씬 쉬어요.

계층적 CLAUDE.md — 모노레포나 대형 프로젝트에서

프로젝트가 커지면 디렉토리별로 CLAUDE.md를 분리할 수 있어요.

my-project/
├── CLAUDE.md           ← 전체 프로젝트 공통 규칙
├── frontend/
│   └── CLAUDE.md       ← 프론트엔드 특화 규칙
└── backend/
    └── CLAUDE.md       ← 백엔드 특화 규칙

Claude Code가 frontend/ 안에서 작업할 때 루트 CLAUDE.md랑 frontend/CLAUDE.md 둘 다 읽어요. 공통 규칙 + 영역별 특화 규칙이 합쳐지는 구조예요.

@import 문법으로 파일 가져오는 것도 돼요:

# CLAUDE.md
프로젝트 공통 규칙 여기.

## Git 워크플로우
@docs/git-workflow.md 참고.

@docs/git-workflow.md가 자동으로 로드돼요.

CLAUDE.md 관리 팁 — 살아있는 문서로 유지하기

CLAUDE.md는 한 번 쓰고 끝이 아니에요. 코드처럼 관리해야 해요.

언제 업데이트하나요?

새 라이브러리 추가할 때
코딩 컨벤션 바꿀 때
Claude Code가 계속 같은 실수를 반복할 때 (그게 빠진 규칙이라는 신호)
프로젝트 구조가 크게 바뀔 때

Claude Code가 계속 같은 실수를 한다면:

이게 CLAUDE.md 업데이트 타이밍이에요. 예를 들어 Claude Code가 계속 inline style을 쓴다면:

## 스타일 규칙 (IMPORTANT)
- inline style 절대 금지
- part-addon.css 유틸 클래스만 사용
- 새 CSS 파일 추가 금지

이렇게 추가하면 다음 세션부터 안 해요.

git에 커밋하세요:

git add CLAUDE.md
git commit -m "CLAUDE.md: 스타일 규칙 추가"

CLAUDE.md도 코드예요. 버전 관리 하세요.

솔직한 한계

CLAUDE.md 규칙을 100% 지켜주는 건 아니에요.

공식 문서에도 나와있는데, CLAUDE.md 지시를 따르는 확률이 약 70% 수준이에요. 스타일 선호도 같은 건 70%도 충분해요. 근데 "절대 이 파일 건드리지 마" 같은 크리티컬한 규칙은 70%로 부족해요.

이런 크리티컬한 규칙은 CLAUDE.md가 아니라 Hooks 기능으로 강제해야 해요. Hooks는 Claude Code의 특정 행동을 스크립트로 강제하는 기능인데, 이건 별도 편에서 다룰게요.

그래도 70%만 돼도 체감 차이가 커요. 매번 설명하다가 한 번만 써두면 70% 이상 지켜주는 걸로 바뀌는 거잖아요.

마무리: CLAUDE.md는 Claude Code를 제대로 쓰기 위한 필수 세팅이에요

Claude Code 쓰면서 제일 먼저 해야 할 일이 CLAUDE.md 세팅이에요.

설치하고, 인증하고, CLAUDE.md 만들고 — 이 세 단계까지 해야 Claude Code를 제대로 쓰기 시작한 거예요.

CLAUDE.md 없이 쓰는 건 신입사원한테 온보딩 안 하고 바로 일 시켜놓고 "왜 이렇게 하냐"고 하는 거랑 같아요. 문서 한 번 만들어두면 Claude Code가 내 프로젝트 맥락을 영구적으로 기억해요.

오늘 당장 /init 치고 시작해보세요.

다음 포스팅 예고: [Claude Code 실전 정복 #4] Claude Code로 React 컴포넌트 제대로 만들기 — 함수형 컴포넌트부터 커스텀 훅까지

[Claude Code 실전 정복 #2] VS Code 연동 + 실전 워크플로우 — 7년차 개발자의 프롬프트 패턴 공개 (2026)

체리플랜 — Fri, 8 May 2026 18:00:54 +0900

시리즈: Claude Code 실전 정복 | 2편

작성자: 체리플랜 | 7년차 프론트엔드 개발자

1편 보기: [Claude Code 설치부터 첫 실행까지]

https://cherrycoding0.tistory.com/46

[Claude Code 실전 정복 #1] 설치부터 첫 실행까지 — 7년차 개발자가 겪은 진짜 과정 (2026)

cherrycoding0.tistory.com

Claude Code 설치했는데 어떻게 써야 할지 모르겠다는 분들 많아요.

저도 그랬어요. 설치는 했는데, 터미널 열어놓고 뭘 물어봐야 할지 막막한 거예요. 그냥 "이 코드 고쳐줘"하면 되는 건지, 아니면 뭔가 더 잘 쓰는 방법이 있는 건지.

7년차 프론트엔드 개발자로 Claude Code 실무에 녹여 쓰면서 찾아낸 워크플로우가 있어요.

핵심은 이거예요. "일단 짜줘"가 아니라 "먼저 계획 세워줘" — 이 순서 하나가 코드 품질이랑 토큰 효율 둘 다 잡아줘요.

이번 편에서는 VS Code 연동 방법부터, 제가 실제로 쓰는 프롬프트 패턴까지 공개할게요.

VS Code에서 Claude Code 쓰는 법

Claude Code는 기본적으로 터미널 도구예요. 근데 VS Code에서 통합해서 쓰면 훨씬 편해요.

방법 1: VS Code 내장 터미널 활용

제가 제일 많이 쓰는 방식이에요.

VS Code에서 프로젝트 열기
터미널 열기 (Ctrl + ` 또는 Cmd + `` )
터미널에서 claude 실행

이게 전부예요. VS Code 에디터 옆에 터미널이 붙어있으니까, Claude Code가 수정한 파일이 에디터에 바로 반영돼요. 파일 저장됐다는 표시 뜨면 에디터에서 바로 확인할 수 있어요.

방법 2: VS Code Extension (Claude Code)

Anthropic이 공식 VS Code 익스텐션을 제공해요.

VS Code 익스텐션 마켓플레이스에서 "Claude Code" 검색
Anthropic 공식 익스텐션 설치
사이드바에 Claude 아이콘 생김

익스텐션 쓰면 편집기 안에서 직접 Claude랑 대화할 수 있어요. 파일 선택하고 "이 파일 설명해줘"같은 식으로 컨텍스트 넘기기도 편해요.

저는 주로 내장 터미널 방식으로 써요. 익스텐션보다 응답이 빠르고, 터미널 명령어 실행 결과까지 같은 화면에서 볼 수 있어서요.

핵심 워크플로우 — 제가 실제로 쓰는 방식

Claude Code 쓰면서 시행착오 끝에 정착한 워크플로우예요.

1단계: 상황 설명 + 계획 요청

가장 중요한 단계예요. 바로 "코드 짜줘"로 시작하지 않아요.

지금 상황:
- cherryplan 허브 프로젝트, React 18 + Vite
- 가계부 컴포넌트에서 월별 지출 합계가 틀리게 나오는 버그
- src/components/Budget/BudgetSummary.jsx 파일 관련

바꾸고 싶은 것:
- 월별 합계 계산 로직 수정
- 음수 지출도 올바르게 처리되게

이 내용 먼저 파악하고 어떻게 접근할지 계획 세워줘.
코드 수정은 내가 확인하고 나서 진행해줘.

이렇게 하면 Claude Code가 파일을 먼저 읽고, 현재 코드 구조를 파악하고, 접근 방법을 제안해요. 이 단계에서 제가 생각했던 것과 다른 문제를 발견하는 경우도 꽤 있어요.

왜 이게 중요하냐면:

계획 없이 바로 코드 수정 시작하면 중간에 방향이 틀어졌을 때 롤백이 힘들어요. 계획 단계에서 잘못된 방향 잡으면 수정하는 게 코드 다 짠 다음보다 10배 쉬워요. 토큰도 훨씬 적게 써요.

2단계: 계획 검토 + 수정

Claude Code가 제안한 계획 보고 괜찮으면 진행, 아니면 방향 수정해요.

2번 방법으로 진행해줘.
단, 기존 데이터 형식은 바꾸지 말고 계산 로직만 수정해줘.

또는:

1번 방법은 사이드 이펙트가 생길 것 같아.
로컬 상태만 건드리는 방향으로 다시 계획 세워줘.

3단계: 코드 수정 실행

계획 확정되면 진행해요.

확인했어. 진행해줘.

Claude Code가 파일을 직접 수정해요. 수정되는 파일들 목록 보여주면서 진행하는데, VS Code 에디터에서 파일 변경 표시가 실시간으로 뜨는 게 눈으로 보여요.

[스크린샷: Claude Code가 파일 수정 중인 터미널 화면 — 여기에 이미지 첨부]

4단계: 확인 + 마무리

수정 완료되면:

수정된 내용 요약해줘. 그리고 사이드 이펙트 생길 수 있는 부분 있으면 알려줘.

이렇게 마무리 확인을 습관화하면 나중에 예상 못 한 버그 만날 확률이 줄어요.

자주 쓰는 프롬프트 패턴

7년치 개발 경험에서 나온 패턴들이에요.

패턴 1: 에러 디버깅

이 에러가 났어:
[에러 메시지 붙여넣기]

에러 발생 파일: src/hooks/useBudget.js
에러 발생 상황: 날짜 필터 적용할 때

원인 파악하고 수정 방법 제안해줘. 수정 전에 나한테 확인받고 진행해줘.

핵심은 에러 메시지 전체를 그대로 붙여넣기예요. "뭔가 에러남"이 아니라 실제 에러 메시지 전체를 주면 정확도가 확 올라가요.

패턴 2: 새 기능 추가

현재 상황: 가계부 앱에 카테고리별 분류 기능이 없음

추가하고 싶은 기능:
- 지출 항목에 카테고리 선택 (식비, 교통, 쇼핑, 기타)
- 카테고리별 월간 합계 표시
- 기존 데이터 구조는 최대한 건드리지 않고 추가

구현 방법 먼저 제안해줘. 기존 코드와 어떻게 연결할지 설명 포함해서.

패턴 3: 리팩토링

BudgetList.jsx 파일 읽어봐.
이 컴포넌트 너무 길어. 300줄 넘어.

어떻게 분리하면 좋을지 제안해줘.
- 재사용 가능한 부분
- 로직이랑 UI 분리
- 파일명 제안 포함

계획만 먼저 줘. 실제 분리는 내가 확인하고 나서.

패턴 4: 코드 설명

src/utils/dateUtils.js 파일 읽어보고
각 함수가 뭘 하는지 설명해줘.
특히 getMonthlyRange 함수 동작 방식 자세히 설명해줘.

이건 남이 짠 코드 인수인계받을 때 진짜 유용해요. 파일 직접 읽으니까 주석 없어도 설명해줘요.

패턴 5: PR 준비

git diff main 결과야:
[diff 내용 붙여넣기 또는 "git diff 결과 봐줘"라고 하면 직접 실행]

이 변경사항으로 PR 설명 작성해줘.
- 변경 이유
- 변경 내용 요약
- 테스트 방법
한국어로 써줘.

토큰 아끼는 실전 팁

Claude Code 쓰다 보면 컨텍스트가 쌓이면서 토큰이 빠르게 소비돼요. 실제로 써본 절약 방법들이에요.

/compact 명령어 적극 활용

긴 세션 중간에 치면 대화 내용을 요약해서 컨텍스트를 압축해요.

/compact

완전히 새로 시작하고 싶으면:

/clear

세션 초반에 최대한 구체적으로

처음 프롬프트가 모호하면 Claude Code가 확인 질문을 여러 번 해요. 그만큼 토큰 써요. 처음부터 상황 + 목표 + 제약조건을 다 넣어주면 확인 질문이 줄어요.

불필요한 파일 읽기 막기

src/components/Budget 폴더 안에 있는 파일들만 봐줘.
다른 폴더는 지금 안 봐도 돼.

이렇게 범위를 명시하면 Claude Code가 불필요하게 전체 프로젝트를 스캔하는 걸 막을 수 있어요.

컨텍스트 60% 넘기 전에 새 세션 시작

연구 결과에 따르면 Claude Code는 컨텍스트가 60% 넘어가면 품질이 떨어지기 시작해요. 길어진 세션에서 "왜 갑자기 이상한 답 나오지?" 싶을 때 대부분 컨텍스트 꽉 찬 경우예요.

이럴 땐 지금까지 논의한 내용을 파일로 저장하고 새 세션 시작하는 게 낫어요:

지금까지 작업한 내용 progress.md 파일로 저장해줘.
다음 세션에서 이어받을 수 있게 현황이랑 다음 할 작업 포함해서.

솔직한 한계 — 이건 진짜 안 됐어요

아직까지 Claude Code 쓰면서 "이건 못 하는구나" 싶었던 건 딱 하나예요.

컨텍스트 한계로 인한 긴 작업 중단이에요.

규모가 큰 리팩토링 작업을 중간에 하다가 컨텍스트 꽉 차서 끊긴 적이 있어요. 그 시점까지 한 작업들이 날아가지는 않았는데, 다음 세션에서 어디까지 했는지 다시 파악하는 데 시간이 걸렸어요.

이거 해결책이 앞서 말한 progress.md 패턴이에요. 작업 중간중간에 현황을 파일로 저장해두면 세션이 끊겨도 이어받을 수 있어요.

그 외에는 아직까지 "이건 못 하더라"는 경험은 없었어요. 오히려 제가 예상 못 했던 것들까지 해주는 경우가 더 많았어요.

마무리: 워크플로우가 결과를 결정해요

Claude Code는 도구예요. 좋은 도구도 어떻게 쓰느냐에 따라 결과가 완전히 달라요.

"일단 짜줘"로 시작하는 것과, "먼저 계획 세워줘"로 시작하는 것 — 결과물 품질이 다르고 토큰 효율도 달라요.

처음엔 이 워크플로우가 번거롭게 느껴질 수 있어요. 근데 한 번 익숙해지면 오히려 더 빨라져요. 중간에 방향 틀어서 롤백하는 시간이 없어지거든요.

다음 편에서는 이 워크플로우의 핵심 — CLAUDE.md 설정을 다룰게요. CLAUDE.md가 없으면 매 세션마다 프로젝트 설명부터 다시 해야 해요. 있으면 처음부터 내 프로젝트를 아는 동료처럼 바로 시작할 수 있어요.

다음 포스팅 예고: [Claude Code 실전 정복 #3] CLAUDE.md 완전 정복 — 설정 한 번으로 매 세션 토큰 절약하는 법

https://cherrycoding0.tistory.com/48

[Claude Code 실전 정복 #3] CLAUDE.md 완전 정복 — 설정 한 번으로 매 세션이 달라지는 이유 (2026)

시리즈: Claude Code 실전 정복 | 3편작성자: 체리플랜 | 7년차 프론트엔드 개발자1편: [Claude Code 설치부터 첫 실행까지]https://cherrycoding0.tistory.com/46 [Claude Code 실전 정복 #1] 설치부터 첫 실행까지 — 7

cherrycoding0.tistory.com