PM이 Claude Code로 2주 만에 블로그 만든 이유와 방법
PM이 Claude Code로 2주 만에 블로그 만든 이유와 방법
"PM은 코드 못 짜잖아요."
지난주 회사에서 들은 말이다. 틀린 말은 아니다. 나는 디자이너 출신이고, 개발은 HTML/CSS 정도만 건드려봤다. 그런데 지금 이 블로그는 내가 만들었다. Next.js로, TypeScript로, Tailwind로. Claude Code라는 도구 하나로 2주 만에.
이 글은 코딩을 잘하는 PM이 된 후기가 아니다. 여전히 나는 코드를 '잘' 짜지 못한다. 하지만 '만들 수' 있게 됐다. 그 차이가 생각보다 크다는 걸 깨달았다.
왜 굳이 직접 만들었나
Notion, Tistory, Medium 다 써봤다. 괜찮았다. 근데 뭔가 2% 부족했다. 디자이너 출신으로서 "이 마진은 좀 줄이고 싶은데", "이 색상은 좀 바꾸고 싶은데"가 계속 쌓였다. PM으로서는 "이 데이터를 이렇게 보여주면 좋을텐데"가 계속 머릿속을 맴돌았다.
개발자한테 부탁? 팀 리소스를 내 개인 블로그에 쓸 순 없었다. 외주? 유지보수 때마다 돈 나간다. 결국 답은 하나였다. 내가 만드는 거.
그런데 타이밍이 좋았다. Claude가 3.7 Sonnet을 출시하면서 '코딩 에이전트' 기능을 내놨다. Claude Code. 코드를 대신 짜주는 게 아니라, 옆에서 같이 짜주는 느낌이라고 해야 할까.
Claude Code는 어떻게 다른가
기존 AI 코딩 도구들은 대부분 "코드 자동완성" 수준이었다. GitHub Copilot, Cursor, 다 써봤다. 좋긴 한데 결국 내가 코드를 이해해야 했다.
Claude Code는 좀 다르다. 세 가지가 특히 달랐다.
1. 파일 구조를 이해한다
"블로그 포스트에 태그 기능 추가해줘"라고 하면, 어떤 파일을 수정해야 하는지 알아서 판단한다. components/Post.tsx, lib/posts.ts, app/blog/[slug]/page.tsx 이 세 개 파일을 동시에 수정해야 한다는 걸 안다.
2. 에러를 같이 디버깅한다
빌드 에러가 나면 터미널 로그를 복사해서 붙여넣기만 하면 된다. "아, 여기서 타입이 안 맞네요. 이렇게 고치면 됩니다"하고 수정된 코드를 준다. 실제로 79번의 빌드 에러를 이렇게 해결했다. (진짜 세어봤다)
3. PM 언어로 대화한다
"유저가 카테고리별로 포스트를 필터링할 수 있으면 좋겠어"라고 말하면 이해한다. filter() 함수를 어떻게 쓰는지 몰라도 된다. 요구사항만 명확하면 된다.
이게 PM한테는 엄청난 차이다. 우리는 '뭘 만들지'는 잘 안다. '어떻게 만들지'를 몰랐을 뿐이다.
2주간의 실제 작업 과정
Day 1-3: 기본 구조 세팅
처음엔 Next.js 템플릿부터 시작했다. Claude한테 "블로그 시작하고 싶은데 뭐가 필요해?"라고 물었다. Next.js, TypeScript, Tailwind 조합을 추천받았다. 왜 이 조합인지 설명도 듣고, 동의해서 진행했다.
npx create-next-app 명령어도 Claude가 알려줬다. 하나하나 따라하니까 됐다.
Day 4-8: 핵심 기능 개발
마크다운 파싱, 포스트 목록, 개별 포스트 페이지, 태그 시스템. 이 네 개를 만들었다. 각각 반나절에서 하루씩 걸렸다.
솔직히 말하면 여기서 좌절할 뻔 했다. Day 6에 빌드가 안 됐다. 에러 메시지를 봐도 뭔 소린지 모르겠고, Claude한테 물어봐도 계속 다른 해결책을 줬다. 30번 정도 시도하고 포기할까 싶었다.
그런데 문제를 더 작게 쪼개서 물어보니 해결됐다. "전체 에러"를 물어보지 말고, "이 파일의 이 부분만" 물어보니 답이 나왔다. PM으로서의 습관이 여기서 도움이 됐다. 큰 문제를 작은 문제로.
Day 9-12: 디자인 다듬기
여기가 제일 재밌었다. 디자이너 출신으로서 진가를 발휘할 때. Tailwind CSS를 Claude한테 배우면서, 내가 원하는 대로 스타일을 조정했다.
"이 카드 컴포넌트에 미묘한 그림자를 추가하고, 호버 시 살짝 올라오는 느낌을 줘" → 정확히 원하는 대로 나왔다. 16px을 14px로 바꾸고 싶으면 바로 바꿨다. 플랫폼 제약이 없으니 자유로웠다.
Day 13-14: 배포와 마무리
Vercel에 배포했다. 이것도 Claude가 단계별로 알려줬다. Git 커밋, GitHub 연동, Vercel 설정. 각 단계마다 왜 이렇게 하는지도 설명해줬다.
첫 배포 후 발견한 버그만 23개. 모바일에서 레이아웃 깨지고, SEO 메타태그 빠지고, 다크모드 일부 안 먹고. 하나씩 고쳤다. Claude한테 "모바일에서 이 부분이 깨져"라고 스크린샷 보내면 고쳐줬다.
PM이 코드를 쓸 줄 알면 달라지는 것들
프로토타입 속도가 10배 빨라진다
이제 제품 아이디어가 생기면 직접 만들어본다. Figma 목업 → Claude Code로 실제 작동하는 프로토타입. 이게 2-3일이면 된다. 팀한테 "이렇게 만들면 어떨까요?" 하면서 링크를 보낸다. 말로 설명하는 것과 차원이 다르다.
개발팀과 대화가 구체화된다
"이 기능 구현 가능할까요?"가 아니라 "이 기능은 이렇게 구현하면 될 것 같은데, 퍼포먼스 이슈 있을까요?"로 바뀐다. 개발자들 반응이 달라진다. 더 구체적인 피드백을 준다.
기술 부채를 체감한다
직접 코드를 보니까 '왜 개발자들이 리팩토링을 원하는지' 이해된다. 내 블로그도 2주 만에 기술 부채가 생겼다. 중복 코드, 일관성 없는 네이밍, 하드코딩된 값들. 이제 스프린트 플래닝에서 리팩토링 이슈가 나오면 공감한다.
실전 가이드: PM이 Claude Code로 뭐든 만드는 법
1단계: 작은 프로젝트로 시작하라
처음부터 복잡한 걸 만들지 마라. 나는 블로그를 선택했다. 이유는 간단하다.
- 기능이 명확하다 (포스트 쓰고, 보여주기)
- 에러가 나도 서비스 장애가 안 난다
- 천천히 개선할 수 있다
추천 첫 프로젝트: 개인 블로그, 간단한 랜딩페이지, TODO 앱.
2단계: Claude한테 구조부터 물어봐라
"블로그 만들고 싶어"가 아니라 "블로그를 만들려고 하는데, 어떤 기술 스택으로 시작하면 좋을까? 나는 코딩 초보고, 유지보수를 쉽게 하고 싶어"라고 물어라.
왜 이 기술을 쓰는지 이해하고 시작하면, 나중에 문제 생겼을 때 대처가 쉽다.
3단계: 한 번에 하나씩 만들어라
"블로그 전체 만들어줘"는 안 된다. 너무 크다.
대신:
- "Next.js 프로젝트 세팅해줘"
- "마크다운 파일을 읽어서 HTML로 변환하는 기능 만들어줘"
- "포스트 목록을 보여주는 페이지 만들어줘"
이렇게 쪼개라. PM은 이거 잘한다.
4단계: 에러는 친구다
처음 100번 정도는 에러가 뭔지 몰라서 당황한다. 괜찮다. 에러 메시지 전체를 복사해서 Claude한테 붙여넣고 "이거 어떻게 고쳐?"라고 물어라. 90%는 해결된다.
나머지 10%는 구글에 에러 메시지를 검색하라. 같은 에러를 겪은 사람이 반드시 있다.
5단계: Git은 무조건 쓰라
이건 진짜 중요하다. 뭔가 건드렸다가 전체가 망가졌을 때, Git이 없으면 처음부터 다시다. Git이 있으면 git reset --hard로 돌아간다.
Claude한테 "Git 초보자용 명령어 알려줘"라고 물어보고, 그거 세 개만 외워라. git add ., git commit -m "메시지", git push. 이것만 알아도 된다.
실제로 쓴 프롬프트 예시:
나는 Next.js 블로그를 만들고 있어. 지금 포스트 목록 페이지가 있는데, 여기에 카테고리 필터 기능을 추가하고 싶어. 상단에 "All", "Tech", "Product", "Life" 버튼을 만들고, 버튼 클릭하면 해당 카테고리 포스트만 보이게 해줘.
현재 코드: [여기에 현재 파일 내용 붙여넣기]
어떤 파일을 수정해야 하고, 코드는 어떻게 바꾸면 될까?
이런 식으로 구체적으로 물어라. 맥락을 주고, 현재 상태를 보여주고, 원하는 결과를 명확히 하라. PM이 요구사항 정리하는 것과 똑같다.
솔직히 힘들었던 것들
터미널 공포증
검은 화면에 흰 글씨. 여전히 좀 무섭다. rm -rf를 잘못 치면 전체가 날아간다는 걸 알고 나서 더 조심스러워졌다. 지금도 명령어 치기 전에 한 번 더 확인한다.
에러의 늪
어떤 날은 하루종일 에러 하나 못 잡았다. 특히 TypeScript 타입 에러는 아직도 헷갈린다. Property 'title' does not exist on type 'never' 이런 거 보면 머리가 아프다.
완벽주의와의 싸움
디자이너 출신으로서 1px까지 맞추고 싶은데, 코드로는 그게 쉽지 않다. 어느 순간 "일단 작동하게 만들고, 나중에 예쁘게 하자"로 마인드를 바꿔야 했다.
2주 후 달라진 것
숫자로 정리하면:
- 작성한 코드 라인: 약 3,200줄
- Claude와 나눈 대화: 847개 메시지
- 마주한 에러: 79개
- 배포 시도: 12번
- 구글링 횟수: 200번 이상
하지만 진짜 달라진 건 숫자로 안 나온다. 제품을 보는 눈이 바뀌었다. 이제 어떤 서비스를 쓰면 "이건 어떻게 만들었을까?"를 생각한다. 개발자 탭을 열어서 코드를 본다. 이해는 못 해도, 구조는 보인다.
팀 미팅도 바뀌었다. "이거 만들 수 있어요?"가 아니라 "이거 이렇게 만들면 되는 거 맞죠?"라고 물어본다. 개발자들이 "오, PM이 이제 코드를 아네요?"라고 한다. 아는 건 아니지만, 대화는 된다.
PM이여, 코드를 두려워 말라
이 글을 쓰는 지금도 나는 '개발 잘하는 PM'이 아니다. 알고리즘 문제 못 풀고, 시간복잡도 모르고, 디자인 패턴도 잘 모른다.
하지만 뭔가를 '만들 수' 있다. 내 머릿속 아이디어를 2주 안에 실제로 작동하는 프로덕트로 바꿀 수 있다. 그게 면접관 앞에서 화이트보드 코딩하는 것보다 PM한테는 더 중요하다고 생각한다.
Claude Code는 마법 도구가 아니다. 코드를 모르는 사람을 개발자로 만들어주지 않는다. 대신 '만들고 싶은 의지가 있는 사람'에게 도구를 쥐어준다. PM이 제품을 기획만 하는 게 아니라 직접 만들어볼 수 있게 해준다.
이 블로그를 만들면서 제일 많이 한 생각은 "아, 이래서 개발자들이 이렇게 말했구나"였다. 기술 부채도, 리팩토링도, 테스트 코드도, 이제 체감한다. 그게 더 나은 PM을 만든다고 믿는다.
다음 프로젝트는 사내 툴이다. 팀이 쓸 간단한 대시보드를 만들어볼 생각이다. Claude Code와 함께. 이번엔 일주일 안에 만들 수 있을 것 같다.
PM이 코드를 쓸 줄 알아야 하냐고? 필수는 아니다. 하지만 할 수 있으면, 세상이 달라 보인다. 그리고 지금은 Claude Code 덕분에, 생각보다 어렵지 않다.
시작해보라. 작은 프로젝트 하나로. 2주면 된다.