디자인보다 구조 먼저였습니다. 저는 콘텐츠 맵으로 방부터 정하고 골조를 세운 뒤("집부터 짓고 인테리어는 나중에"), 페이지마다 제각각이던 짜깁기를 디자인 메뉴얼 북 하나로 30장 넘게 정합했습니다. 이 세 가지는 제가 혼자 한 게 아닙니다 — 뼈대는 개발팀에게, 옷은 디자인 담당(Nova)에게 터미널에서 불러 지시했고, 첫 배포 113개 파일이 모두 "Canceled"로 튕겼을 때 그 범인인 설정 파일 한 줄은 제가 직접 찾아 지웠습니다.
외주를 주지 않기로 했으니, 이제 직접 지어야 했습니다. 첫 삽을 어디에 떴을까요. 디자인이 아니었습니다.
디자인보다 구조 먼저
제가 세운 원칙은 건축적이었습니다. "집부터 짓고 인테리어는 나중에."
화려한 색과 폰트를 고르기 전에, 전체 구조부터 정했습니다. 어떤 방이 있어야 하는가. 진단·보고서, 지식 테스트, 교육·도서, 블로그, 회사소개, 회원 — 방의 목록을 정하고, 무엇이 어느 방에 들어갈지 콘텐츠 맵(청사진)을 그렸습니다.
1년간 ANC가 안에서 쌓아온 것들이 많았습니다. 블로그 글 수십 편, 보고서, 강의, 진단 도구들. 이것들을 어느 방에 넣을지를 먼저 정하고, 빈 방의 골조부터 세웠습니다. 디자인은 그 위에 얹기로 했습니다.
터미널을 열고, 개발팀을 불렀다
청사진이 나오자, 저는 터미널을 열고 개발팀을 불렀습니다. 지시는 이랬습니다 — 집짓기를 계속하자. 방 목록대로 골조를 세우되, 이미 작동하는 도구(계산기·시뮬레이터)의 계산 로직·문항·수치·폼은 한 글자도 건드리지 말고 그대로 두라. 옷은 나중에 갈아입힌다.
개발팀이 그 지시대로 빈 방들의 골조를 세웠습니다. 저는 그 위에서 스스로 이 집의 현장 감독(PM)이 되어, 어느 방을 먼저 올릴지 순서를 정하고 막힌 자리를 풀었습니다. 방향을 정하고 지시를 쓰는 건 저였고, 실제로 벽돌을 쌓은 건 개발팀이었습니다.
짜깁기를 한 채로 묶은 밤 — 디자인 담당 Nova를 불렀다
방을 하나씩 짓다 보니 문제가 생겼습니다. 어느 날 보고서 페이지를 열어 보니, 페이지마다 폰트가 다르고 색이 다르고 여백이 달랐습니다. 한 채의 집이 아니라 여러 집을 인위적으로 이어 붙인 짜깁기처럼 산만했습니다.
그래서 이번에는 디자인 담당 Nova를 불렀습니다. 제가 준 지시는 이랬습니다.
"페이지마다 형식·폰트·색 기준이 없어 너무 산만하다. 디자인 메뉴얼 북으로 기준점을 하나 잡고, 각 페이지가 그 기준에 맞는지 검수하듯 한 장씩 완료해 가라. 벤치마킹 사이트를 준 건 그 기준을 네가 정하라는 뜻이다."— 디자인 담당에게 준 지시
Nova가 표준을 정했습니다. 이미 다듬어 둔 메인 페이지를 정본으로 삼아, 서체는 두 종, 색은 따뜻한 브라운 한 가지 포인트, 각진 모서리, 라이트 톤 내비게이션, 네 칸짜리 사이트맵 푸터. 보수적인 자산가 이용자에게는 오히려 상투적일 만큼 안정적인 톤이 신뢰감을 준다는 판단이었습니다.
제가 "하나로 가도 된다"며 전수 일괄 작업을 승인했고, Nova가 그 기준에 진단·보고서·지식·블로그·회사소개·서비스·약관 전 30장을 한 장씩 맞췄습니다. 이 과정에서 'AI가 만든 티'(균일한 박스·과한 장식)도 함께 걷어냈습니다. 최종 검수는 31장 중 31장 전부 통과 — 다크 내비게이션·그라데이션·서체 이탈은 모두 0이 됐습니다.
중요한 건, 계산기·시뮬레이터 같은 작동하는 도구의 동작은 한 글자도 건드리지 않았다는 것입니다. 겉옷만 한 벌로 갈아입히고, 속은 그대로 살렸습니다. 페이지를 가로질러 눈으로 보니 비로소 "한 사이트로 보인다"는 확인이 섰습니다.
"Canceled"의 밤 — 한 줄이 범인이었다
이제 세상에 내보낼 차례. 첫 배포로 113개 파일을 올렸습니다. 그런데 모든 빌드가 이유 없이 "Canceled"로 스킵됐습니다. 코드는 멀쩡한데 배포가 아예 시작되지 않았습니다.
이건 제가 직접 붙들었습니다. 로그를 보고, 설정을 뒤지고, 한참을 추적했습니다. 그리고 범인을 찾았습니다 — 배포 설정 파일 vercel.json에 들어 있던 딱 한 줄이었습니다.
"ignoreCommand": "exit 0"— 모든 빌드를 무조건 건너뛰게 만든 한 줄 (커밋 d559a51로 제거)
이 한 줄이 "빌드를 항상 스킵하라"는 명령이라, 대시보드 설정까지 이기고 모든 배포를 죽이고 있었습니다. 그 줄을 지우니, 바로 Ready — 라이브로 떴습니다.
바이브 코딩의 전형적인 순간입니다. 거창한 버그가 아니라, 한 줄이 범인이었습니다. 이런 자리는 담당에게 넘기지 않고 제가 직접 파고듭니다.
구조 설계(콘텐츠 맵), 디자인 일관성(메뉴얼 북), 배포 오류 추적(한 줄 디버그), 도메인 연결 — 이 네 가지는 어느 회사 홈페이지를 짓든 똑같이 부딪힙니다. 제가 우리 집에서 한 번 손으로 겪었기에, 고객사 홈페이지에서는 같은 밤을 새우지 않게 해드릴 수 있습니다.
다음 편부터는, 이렇게 지은 집의 방을 하나씩 열겠습니다. 제가 그 방에서 어떤 담당을 불러 무엇을 지시했는지와 함께. 첫 방은 — 회사 정보를 넣으면 세금을 숫자로 돌려주는 진단·보고서 탭입니다. 그 방을 만든 두 담당, Theo와 Jordan을 소개하면서.
자주 묻는 질문
홈페이지를 만들 때 무엇부터 시작했나요?
디자인이 아니라 구조부터입니다. 저는 전체 콘텐츠 맵을 그려 어떤 방(페이지)이 있고 무엇이 어디에 들어갈지를 먼저 정하고, 빈 방의 골조부터 세웠습니다. 디자인은 그 위에 얹었습니다. '집부터 짓고 인테리어는 나중에'가 원칙이었습니다.
페이지마다 디자인이 달라지는 문제는 어떻게 해결했나요?
디자인 담당(Nova)을 불러 디자인 메뉴얼 북 하나를 기준으로 삼게 하고, 30장이 넘는 페이지의 폰트·색·여백을 단일 표준에 맞췄습니다. 최종 검수는 31장 전부 통과 — 짜깁기처럼 보이던 사이트가 한 채의 집으로 묶였습니다.
배포가 안 됐다던데 무슨 일이었나요?
첫 배포에 113개 파일을 올렸는데 모든 빌드가 이유 없이 Canceled로 스킵됐습니다. 제가 직접 추적한 끝에, 배포 설정 파일 vercel.json의 한 줄(ignoreCommand: exit 0)이 모든 빌드를 무조건 건너뛰게 만든 범인이었습니다. 그 한 줄을 지우니(커밋 d559a51) 바로 배포가 됐습니다.
이런 트러블슈팅도 고객사에 도움이 되나요?
그렇습니다. 구조 설계, 디자인 일관성, 배포 오류 추적, 도메인 연결은 어느 회사 홈페이지에서나 똑같이 부딪히는 문제입니다. 제가 한 번 손으로 겪어본 것은 고객사 홈페이지를 만들 때 그대로 노하우가 됩니다.
- 콘텐츠 맵
- 홈페이지에 어떤 페이지(방)가 있어야 하고, 무엇이 어느 페이지에 들어갈지를 정리한 전체 구조도. 디자인보다 먼저 그리는 설계 도면이다.
- 디자인 메뉴얼 북
- 서체·색·여백·모서리 같은 디자인 규칙을 하나의 기준으로 정리한 문서. 이 기준에 모든 페이지를 맞춰 사이트 전체의 통일감을 만든다.
- PM(현장 감독)
- Project Manager의 줄임말. 이 글에서는 대표가 홈페이지 제작 전체 진행을 직접 지휘하는 역할을 집짓기에 빗대 "현장 감독"으로 표현했다.
- vercel.json
- 홈페이지를 배포하는 서비스(Vercel)에 "빌드를 어떻게 처리할지" 지시하는 설정 파일. 이 파일의 한 줄이 배포 전체를 막았다.
- 커밋(commit)
- 코드의 변경 내용을 하나의 단위로 저장하는 기록. 코드 저장소(Git)에서 "언제 무엇을 고쳤는지"를 추적하는 데 쓰인다.
- 디AI화
- AI가 만든 것 특유의 티(균일한 박스·과한 장식 등)를 걷어내고 사람이 만든 것처럼 자연스럽게 다듬는 작업. 사내 디자인 기준으로 통과 여부를 판정한다.