BLOG POST
nangman_craft 첫 배포 로그
Related Product #
Why this post #
Product 상세에는 핵심 정보만 남기고, 긴 작업 로그와 의사결정은 블로그에서 관리하려고 한다.
이 글은 2026-02-28 첫 배포 당일의 실제 작업 흐름을 그대로 기록한 로그다.
이 배포가 중요했던 이유는 단순히 홈페이지 하나를 띄웠기 때문이 아니다.
77BuildsIn7Months를 진짜로 운영하려면, 제품과 글과 판단이 한곳에 쌓일 중심 공간이 먼저 필요했다. nangman_craft의 첫 배포는 그 아카이브 구조를 실제로 여는 순간에 가까웠다.
What launched first #
첫 배포 시점에 우선 고정하고 싶었던 것은 세 가지였다.
- Products와 Blog가 분리된 구조
- build 결과와 운영 판단이 같이 남는 기본 정보 아키텍처
- 이후 반복 수정이 가능한 배포/기록 루프
즉 이 launch의 목적은 예쁜 소개 페이지를 만드는 것이 아니라, 이후의 build들이 기록으로 축적될 수 있는 기반을 먼저 여는 데 있었다.
첫 홈 화면. 처음부터 제품 하나를 파는 사이트보다, 무엇을 만들고 어떻게 기록할 것인가가 보이는 구조를 우선하려고 했다.
Timeline #
| DateTime | Log |
|---|---|
| 2026-02-28 08:00 | 기존 서비스와 동일하게 TS + React + Vite로 시작 |
| 2026-02-28 08:30 | SEO 관점에서 Next.js가 유리하다고 판단해 프레임워크 전환 |
| 2026-02-28 09:00 | 3시간 브런치(에그베네딕트) 후 복귀 |
| 2026-02-28 13:00 | 홈페이지 전체 구조와 디자인 작업 |
| 2026-02-28 15:00 | 블로그 글 관리 방식(Obsidian 기반) 확정 후 첫 배포 |
| 2026-02-28 16:00 | Google Analytics 적용 및 배포 후 후속 수정 시작 |
| 2026-02-28 이후 | 디자인 개선, 소개 문구 반복 개선, 다이어그램 구성, 실제 블로그 글 작성 |
Launch 후 추가 작업 (2026-03-01 기준) #
| DateTime | Log |
|---|---|
| 2026-03-01 오전 | Product 카드/상세 UX 정비: 서비스 방문 CTA 가시성 개선, 카드 정보 밀도 조정 |
| 2026-03-01 오전 | About 구조 재설계: Production Flow + Build Capability 재구성, 문구/레이아웃 반복 개선 |
| 2026-03-01 오전 | Blog 운영 구조 고정: author/updatedAt 정리, 빌드 로그 분리 전략, 글 템플릿 정비 |
| 2026-03-01 오후 | 분석 체계 확장: GA4 핵심 이벤트/퍼널 정의 및 문서화, 주요 전환 액션 계측 반영 |
| 2026-03-01 오후 | SEO/GEO 강화: 메타/구조화 데이터/크롤링 신호 보강 및 검색 노출 품질 개선 작업 |
| 2026-03-01 오후 | AdSense 준비: ads.txt 인증, Privacy 정책 정비, CMP(European regulations) 설정 완료 |
| 2026-03-01 저녁 | Blog UX 마감: 리스트 레이아웃 개선, 페이지네이션 추가, pinned 표현 최소화 |
| 2026-03-01 저녁 | 안정화: 신규 글 라우팅 이슈(dynamic params) 수정 및 배포 반영 |
Key decisions behind the launch #
1. Vite에서 Next.js로 바꾼 이유 #
처음에는 기존 서비스와 같은 TS + React + Vite 흐름으로 시작했다.
하지만 이 사이트는 제품 기록과 글이 계속 쌓이는 구조라서, 첫날부터 SEO와 정적 생성 기준을 무시하기 어렵다고 판단했다.
그래서 프레임워크를 빨리 바꿨다.
이 판단이 중요했던 이유는, nangman_craft는 단순한 개인 홈페이지가 아니라 검색과 공유를 통해 계속 읽히는 아카이브가 되어야 했기 때문이다.
2. Product와 Blog를 처음부터 분리한 이유 #
처음부터 기록을 한 문서 안에 다 넣으면 편할 수는 있다.
하지만 제품 설명과 긴 작업 로그는 읽는 이유가 다르다.
- Product는 구조화된 설명서
- Blog는 판단, 시행착오, 작업 흐름
이 분리를 첫날부터 정해 두지 않으면 이후 build가 늘어날수록 정보가 금방 섞인다고 봤다.
Product 상세 화면. 제품 결과와 상태, AI build system, 판단 기준이 한 문서 안에서 같이 읽히도록 구조를 잡았다.
3. launch 직후 바로 분석과 정책을 붙인 이유 #
GA4, SEO, 구조화 데이터, 정책 페이지, AdSense 준비를 launch 직후 바로 붙인 것도 의도적인 순서였다.
대부분의 build는 “일단 띄우고 나중에 보자”로 흘러가기 쉽다.
하지만 이 사이트는 앞으로 다른 build들의 허브가 되어야 하기 때문에, 첫 제품부터 운영 기준을 같이 고정하는 편이 낫다고 봤다.
What changed #
- Product/Blog/About 구조를 중심으로 정보 아키텍처를 고정했다.
- 정적 배포 기준으로 운영 루프를 만들었다.
- 런칭 이후 반복 업데이트를 위해 기록 포맷과 콘텐츠 관리 흐름을 정리했다.
- 퍼널 계측(조회 → 상세 진입 → 외부 방문) 기준을 세우고 GA4 이벤트로 반영했다.
- SEO/GEO/AdSense 심사 대응을 위한 기술적/운영적 최소 기준을 갖췄다.
Why this matters #
이 사이트는 단순한 포트폴리오 페이지가 아니라, 제품 하나하나의 시도와 운영 판단을 축적하는 중심 공간이다. 그래서 첫 배포의 의미는 예쁜 랜딩 완성이 아니라, 제품과 기록이 함께 쌓이는 구조를 고정했다는 데 있다. 이 구조가 있어야 이후의 제품 실험도 "무엇을 만들었는지"를 넘어서 "왜 그렇게 판단했는지"까지 남길 수 있다.
Blog 상세 화면. 제품 페이지에 담기 어려운 긴 판단과 작업 로그는 블로그에서 따로 읽히게 하면서, 두 영역이 서로를 보완하도록 설계했다.
What I learned from the first launch #
- 첫 배포는 디자인 완성보다 정보 구조 확정이 더 중요했다
- AI를 써서 빨리 만드는 것과, 이후 계속 읽히는 구조를 만드는 것은 다른 문제였다
- Product와 Blog의 역할을 초기에 분리해 둔 것이 이후 전체 품질 개선의 출발점이 됐다
- launch 자체보다 launch 이후 어떤 기준으로 계속 다듬을지 정하는 것이 더 중요했다
Next #
다음 로그에서는 실제 사용자 데이터(방문/체류/재방문/외부 이동률)를 기준으로 무엇을 유지하고 무엇을 버릴지 정리한다.