Day 5: 런칭, 그리고 5일간의 여정에서 배운 것들
김솔
런칭 버튼 위에 손가락이 멈췄다
2025년 11월 19일, 오전 11시.
Cloudflare Pages 대시보드.
"Deploy" 버튼 위에 마우스가 멈춰 있었다.
지난 5일간의 커밋들이 스쳐 지나갔다.
첫 번째 커밋. Initial commit from Create Next App.
마지막 커밋. fix: add explicit types to SITE_CONFIG to resolve build error.
그 사이에 206개의 커밋.
66개의 Pull Request.
새벽 3시에 Lightbox 버그로 머리를 쥐어뜯던 순간.
5시간 동안 "터미널에선 되는데 왜 안 돼"를 외치던 순간.
"진짜 이게 끝이야?"
클릭.
✓ Build successful
✓ Deploying to production...
✓ Your site is live!
내가 만든 블로그가 세상에 공개됐다.
Day 5의 시작: 마지막 관문, 뉴스레터
런칭 전 마지막 과제는 뉴스레터였다.
독자와 직접 소통하고 싶었다.
플랫폼을 거치지 않고.
네이버 블로그처럼 알고리즘에 휘둘리지 않고.
삽질 #1: 6개월 전 가이드의 함정
처음에는 Mailgun을 썼다.
설정이 복잡했다.
"Claude, 더 간단한 방법 없어?"
"Resend 써보세요. 개발자 친화적이고 무료에요."
좋아. Resend로 갈아탔다.
구글링해서 찾은 가이드를 따라했다.
"Audience를 먼저 만들고, Audience ID를 환경 변수에 넣어라."
const response = await fetch('https://api.resend.com/audiences/{audienceId}/contacts', {
method: 'POST',
headers: {
'Authorization': `Bearer ${RESEND_API_KEY}`,
},
body: JSON.stringify({
email,
firstName: name,
audienceId: process.env.RESEND_AUDIENCE_ID, // 가이드대로 추가
}),
})
실행.
Error: Invalid audience ID
"뭐야?"
Audience ID를 다시 확인했다.
맞는데.
대시보드에서 복사해서 붙여넣었는데.
30분을 삽질했다.
"Claude, 이거 왜 안 돼? Audience ID 맞는데."
"잠깐만요, Resend 문서 확인해볼게요... 아, 2024년에 API가 업데이트됐네요. 이제 Audience ID 없이 바로 Contact를 생성할 수 있어요."
"뭐?"
// 2024년 이후 버전 - Audience ID 불필요
const response = await fetch('https://api.resend.com/contacts', {
method: 'POST',
headers: {
'Authorization': `Bearer ${RESEND_API_KEY}`,
'Content-Type': 'application/json',
},
body: JSON.stringify({
email,
firstName: name,
}),
})
이메일 주소와 이름만 보내면 끝.
작동했다.
기술은 계속 발전한다. 6개월 전 가이드가 오늘은 맞지 않을 수 있다.
공식 문서를 먼저 확인하는 습관.
이번 삽질로 뼈저리게 배웠다.
삽질 #2: 환영 이메일 5번의 수정
구독하면 자동으로 환영 이메일이 간다.
간단할 줄 알았다.
첫 번째 버전: 논문
<h1>Sol의 블로그 뉴스레터를 구독해주셔서 감사합니다!</h1>
<p>안녕하세요! 저는 8년간 의료 현장에서 일하다가
AI 개발자로 커리어를 전환하고 있는 Sol입니다.</p>
<p>이 뉴스레터에서는 다음과 같은 내용을 다룰 예정입니다:</p>
<h2>1. 의료 AI 프로젝트</h2>
<p>의료 데이터를 활용한 AI 프로젝트 개발 과정을 공유합니다.
LangChain, RAG, 벡터 데이터베이스 등 최신 기술을 활용한...</p>
<h2>2. 커리어 전환 이야기</h2>
<p>전문의에서 개발자로 전환하는 과정에서 겪은 시행착오와...</p>
<!-- 800단어 계속... -->
Claude에게 피드백을 요청했다.
"이게 무슨 논문이야? 환영 이메일인데 왜 이렇게 길어요?"
두 번째 버전: 여전히 길다
중복을 제거하고 400단어로 줄였다.
"아직 길어요. 그리고 자기소개가 너무 많아요. 구독자는 이미 블로그를 봤으니까 당신이 누군지 알아요."
세 번째 버전: 핵심만
<p>안녕하세요!</p>
<p>Sol의 블로그 뉴스레터를 구독해주셔서 감사합니다.</p>
<p>매주 화요일, 이런 이야기들을 전해드립니다:</p>
<ul>
<li>의료에서 AI로의 커리어 전환 여정</li>
<li>실전 프로젝트와 기술 학습</li>
<li>일과 육아의 균형 찾기</li>
</ul>
"훨씬 낫네요. 근데 디자인이 너무 밋밋해요."
네 번째 버전: 템플릿 적용
<div style="max-width: 600px; margin: 0 auto; font-family: sans-serif;">
<div style="text-align: center; padding: 40px 0; border-bottom: 2px solid #eee;">
<h1>Sol's Blog</h1>
</div>
<div style="padding: 40px 0;">
<!-- 내용 -->
</div>
<div style="text-align: center; padding: 20px 0; border-top: 2px solid #eee; color: #666;">
<p>더 이상 받고 싶지 않으시다면 <a href="...">여기</a>를 클릭하세요.</p>
</div>
</div>
다섯 번째 버전: 최종
구독 취소 링크의 문구를 다듬고, 줄 간격을 조정했다.
5번의 수정.
간결함은 어렵다.
쓰는 건 쉽다.
줄이는 게 어렵다.
삽질 #2: 마지막 순간의 타입 에러
뉴스레터 시스템이 완성됐다.
이제 진짜 런칭만 남았다.
마지막 빌드를 돌렸다.
✓ Build successful
로컬에서 완벽하게 작동한다. Cloudflare에 푸시했다.
✗ Build failed
"뭐?"
에러 로그를 확인했다.
Type error: Type 'string' is not assignable to type 'string | undefined'.
SITE_CONFIG의 소셜 링크 타입 문제였다.
// 내가 작성한 코드
export const SITE_CONFIG = {
social: {
twitter: '@solkim', // string으로 추론
github: 'kimsol1134',
},
}
// 다른 파일에서 사용
const twitter: string | undefined = SITE_CONFIG.social.twitter
// 에러: string은 string | undefined에 할당 불가
로컬의 TypeScript는 관대하게 넘어갔는데, Cloudflare의 빌드 환경은 엄격했다.
해결:
export const SITE_CONFIG = {
social: {
twitter: '@solkim' as string | undefined,
github: 'kimsol1134' as string | undefined,
},
}
다시 푸시.
✓ Build successful
✓ Deploying to production...
마지막 순간에 터지는 버그가 가장 무섭다.
런칭
오전 11시.
모든 체크리스트를 확인했다.
기능 테스트:
- ✅ 모든 페이지 정상 작동
- ✅ 검색 기능 (Cmd+K)
- ✅ 댓글 작성/수정/삭제
- ✅ 뉴스레터 구독/취소
- ✅ RSS 피드
성능:
- ✅ Lighthouse 성능 90+
- ✅ 페이지 로딩 2초 이내
콘텐츠:
- ✅ About 페이지
- ✅ 블로그 글 4개
- ✅ 프로젝트 2개
마지막 항목에 체크를 넣었을 때, 묘한 감정이 밀려왔다.
Deploy 버튼을 클릭했다.
"Your site is live!"
첫 구독자
런칭하고 아내에게 보여줬다.
"와, 진짜 만들었네?"
"응, 구독해봐."
아내가 이메일을 입력하고 구독 버튼을 눌렀다.
환영 이메일이 갔다. 5번이나 수정한 그 이메일이.
첫 구독자. 1명.
아내였다.
며칠 후, Valley AI라는 커뮤니티에 블로그 개발기를 공유했다.
"5일 만에 개인 블로그를 만들었습니다."
반응이 왔다.
"와, 대단하시네요." "저도 해보고 싶어요."
그리고 뉴스레터 구독자가 1명 늘었다.
2명.
숫자는 작았다. 하지만 시작이다.
206개의 커밋이 말해주는 것
5일간의 통계를 정리했다.
| 항목 | 수치 |
|---|---|
| 총 커밋 수 | 206개 |
| Pull Request | 66개 |
| 작업 시간 | 약 60시간 |
| 밤샘 | 2회 |
| 구현된 Task | 37개 (100%) |
하루 평균 41개의 커밋.
12시간 작업.
미친 짓이었다.
하지만 이 숫자들이 말해주는 건 하나다.
짧은 시간에 집중하면, 생각보다 많은 것을 만들 수 있다.
5일간 배운 것들
1. "작동하는 최소 버전"의 힘
Day 1에 옵시디언 연동, 댓글 시스템, 첫 배포까지 했다.
완벽하지 않았다.
버그도 있었다.
디자인도 허술했다.
하지만 '작동'했다.
그 기반 위에서 Day 2, 3, 4가 가능했다.
처음부터 완벽하게 만들려고 했다면? 아마 아직도 시작 못 했을 것이다.
2. 공식 문서를 먼저 확인하라
Resend Audience ID 삽질로 배웠다.
블로그 포스트, 유튜브 튜토리얼은 작성 시점의 정보다.
API는 계속 바뀐다. 공식 문서가 진실이다.
3. 모듈화는 미래의 나를 위한 선물
댓글 시스템을 만들 때 Claude가 모듈화를 제안했다.
처음엔 귀찮았다. "그냥 한 파일에 다 쓰면 안 돼?"
하지만 Day 4에 보안 취약점을 수정할 때 깨달았다.
어디를 고쳐야 하는지 바로 알 수 있었다.
features/comments/api.ts만 수정하면 됐다.
4. 보안은 처음부터
"나중에 추가하지 뭐"는 위험한 생각이다.
Day 4에 보안 감사를 돌렸을 때, CRITICAL 취약점이 2개 나왔다.
다행히 수정할 수 있었지만, 구조가 더 복잡했다면 전체를 다시 짜야 했을 것이다.
5. 간결함은 어렵다
환영 이메일 5번 수정.
800단어를 100단어로 줄이는 게 800단어 쓰는 것보다 어려웠다.
쓰는 건 쉽다. 줄이는 게 어렵다.
6. AI와의 협업
Claude Code 없이는 불가능했다.
내가 한 건 "무엇을 만들고 싶은지" 명확히 설명하는 것이었다.
코드는 Claude가 짰다.
내가 한 건 방향을 잡고, 피드백을 주고, 결정하는 것.
프로그래밍 언어를 몰라도 프로그램을 만들 수 있는 시대.
바이브 코딩의 힘이다.
블로그를 만든다는 것
5일간의 삽질을 마무리하며 문득 깨달은 게 있다.
처음에는 "글을 쓰는 플랫폼"을 만들려고 했다.
네이버 블로그 셋방살이를 청산하고, 내 집을 갖는 것.
그런데 만들고 나니 달랐다.
블로그를 만드는 것 자체가 퍼스널 브랜딩이었다.
206개의 커밋. 66개의 PR. 새벽 3시의 삽질들.
이 모든 과정이 "나는 이런 사람입니다"를 보여주는 증거가 됐다.
- 모르는 걸 두려워하지 않고 부딪히는 사람
- 삽질을 기록하고 공유하는 사람
- 60시간을 투자해서라도 완성하는 사람
이력서에 "Next.js로 블로그 만들었습니다"라고 한 줄 쓰는 것과,
206개의 커밋 히스토리와 5편의 개발기를 보여주는 것.
무게가 다르다.
결과물만이 아니라, 과정 자체가 나를 증명한다.
당신에게
이 글을 읽고 있는 당신.
혹시 마음속에 미뤄둔 프로젝트가 있나요?
"시간이 없어서." "실력이 부족해서." "뭘 만들어야 할지 몰라서."
나도 그랬습니다.
5년 넘게 "언젠가 개인 블로그 만들어야지" 하면서 미뤘습니다.
그러다 어느 날, 그냥 시작했습니다.
5일.
206개의 커밋.
66개의 PR.
그리고 지금, 내가 만든 블로그에서 이 글을 씁니다.
완벽한 순간은 오지 않습니다. 시작이 완벽을 만듭니다.
당신의 "언젠가"가 "오늘"이 되길 바랍니다.
에필로그
어제 밤, 딸아이를 재우고 책상에 앉았다.
옵시디언을 열었다.
새 파일을 만들었다.
제목을 적었다.
"5일간의 블로그 개발기 - 1편"
그리고 글을 쓰기 시작했다.
예전 같았으면 네이버 블로그 에디터를 열고, 양식을 맞추고, 이미지를 다시 올렸을 것이다.
지금은 다르다.
옵시디언에서 글을 쓰면 끝이다.
나머지는 시스템이 알아서 한다.
내가 만든 시스템이.
5일간의 삽질이, 이 작은 편리함을 만들었다.
그리고 이 편리함이, 앞으로 수백 개의 글을 가능하게 해줄 것이다.
시작하길 잘했다.
시리즈 전체 목록
- 코딩 모르는 의사가 5일 만에 블로그를 만든 이유 - 동기와 전체 개요
- Day 1-2: 첫 삽질의 기록 - 옵시디언 연동, 댓글 시스템, 첫 배포
- Day 3-4: 디테일이 만든 차이 - UI 개선, 보안 감사
- Day 5: 런칭, 그리고 배운 것들 (현재 글)
관련 링크
- 완성된 블로그: https://solkim.blog
- 뉴스레터 구독: https://solkim.blog (페이지 하단)
P.S. 이 글이 도움이 되셨다면, 뉴스레터를 구독해주세요.
당신의 "오늘"을 응원합니다.
이 글이 도움이 되었나요?
관련 글

코딩 모르는 의사가 5일 만에 블로그를 만든 이유
206개의 커밋, 66개의 PR, 5일간의 몰입. 네이버 블로그 셋방살이를 청산하고 나만의 집을 지은 이야기

Day 1-2: 첫 삽질의 기록 - 옵시디언에서 웹사이트까지
프로젝트 초기화부터 첫 배포까지, 48시간 동안 일어난 일들. 위키링크 변환 삽질, 댓글 시스템 설계, 그리고 예상치 못한 Date 객체의 배신

새벽 3시, 당황한 의사 아빠가 만든 해열제 계산기
10분이 걸리던 해열제 용량 계산을 10초로. 간단한 사용자 경험 뒤에 숨겨진 여정