소개
노닥 AI 워케이션 2기에서 회사 리뉴얼된 홈페이지를 만들었어요.
처음 계획은 기존 html 하드코딩 되어있는 현재 홈페이지를 개선하고자 webflow(홈페이지 빌더)를 활용하려고 했어요. 기존에 1/3정도 작업하던 내용을 마무리하는게 목표였는데, 둘째날 오전 아루나 님 강의를 듣고 전면 개편, 완전 새롭게 다시 시작하게 되었어요. 강의 후 황금호랑이님 조언도 전체 일의 구조를 구상하는데 큰 도움 받았습니다.
이런 분들께 도움돼요
홈페이지 리뉴얼을 준비하면서 무엇부터 정리해야 할지 막막한 비개발자, 특히 마케터
개발팀에 무엇을 어떻게 요청해야 할지 고민하는 기획자
AI로 시안은 만들었는데, 그다음 DB 구축 방법, 이후 운영(유지, 보수) 책임과 역할을 어디에 둘지 정해야 하는 분
제가 느낀 기존 홈페이지의 문제는 꽤 구체적이었어요. 어떤 경로로 잠재 고객이 들어오는지, 어떤 콘텐츠를 보고 문의하는지 파악하기 어려웠습니다. 검색엔진과 AI 검색에 맞는 콘텐츠 관리도 보완하고 싶었고, 새로운 소식에 맞춰 페이지를 만들거나 문구를 바꾸는 일도 더 자유로워야 했어요.
문의가 들어온 다음의 흐름도 중요했습니다. 관련 부서에 메일이 전달되더라도 누가 답했는지, 후속 조치가 어디까지 진행됐는지 연결해서 보기 어려웠어요. 그래서 리뉴얼 목표를 ‘방문자가 필요한 정보를 찾고, 문의로 이어지고, 그 뒤의 응대까지 관리할 수 있는 분석 가능하고 개선점 도출이 가능한 홈페이지’로 구체화했습니다.
이미 진행하던 작업이 있었기 때문에, 워케이션에서 완성하리라 마음먹고 참여했지만 새로운 방법론과 깨달음을 얻으며, 바이브 코딩이지만 계획서와 기획안을 좀 더 촘촘하게 설계(MRD, PRD 제작)하고 시작하기로 마음먹고 처음부터 다시 시작했지만 후회 없었어요. 또 개선된 홈페이지를 제작하는 목적 이외, 회사 홈페이지였기에 향후 부서별 R&R, 운영, 유지/관리에대해서도 미처 생각지 못한 부분에 고민이 되었는데, 이 부분도 spec kit 제작하고 handoff 문서 작성해 관련된 모든 사람들에게 share하고 협업할 수 있는 아이디어를 얻어 감사했습니다.
기존 홈페이지 코드와 webflow 구축 중이던 페이지를 대조하고, 리뉴얼 요구사항 문서와 3개 디자인 클릭형 시안을 만들고, 개발팀과 나눌 일(R&R)까지 문서로 정리했습니다.
방향이 이미 있다면 새 아이디어로 바꾸지 말고,
지금까지 된 것과 남은 일을 구분해 범위만 좁혀줘.진행 방법
사용한 도구
Claude Code — 기존 자료 대조, 요구사항 문서화, 클릭형 시안 생성
Codex — 기능 구현 사양과 초기 코드 작성
MRD, PRD, Spec Kit — 사용자 시나리오와 완료 확인 기준 구체화
Firebase(Firestore · 이메일 로그인) — 문의 저장과 관리자 접근의 초기 코드
기존 자료를 대조하니 새로 만들 범위가 보였어요
기존 홈페이지와 Webflow 작업물, 콘텐츠와 이미지부터 대조했습니다. 확보한 자료에서 CMS 콘텐츠 161건과 이미지 610개의 파일 존재·매핑을 확인했어요. 이 숫자는 새 사이트로 이관을 끝냈다는 뜻이 아니라, 무엇을 옮겨야 하는지 확인할 기초 목록을 만든 것입니다. 기존에 as-is 현황을 파악하고 sitemap을 만들고 webflows에서 리뉴얼 홈페이지를 제작하기 시작했는데 누락된 db들도 있었어요.
이 과정에서 제 문제 정의도 더 정확해졌어요. 백업에 분석 태그가 있다는 사실과, 실제로 유입부터 문의까지 이어지는 분석이 가능하다는 것은 별개였습니다. ‘아무것도 없다’고 단정하기보다 이미 있는 것과 확인해야 할 것을 구분해서 요구사항을 정리했어요.
시안을 비교할 기준을 만드니 선택이 구체적이 됐어요
홈페이지의 목적과 방문자, 필요한 메뉴를 요구사항 문서로 정리하고 세 가지 디자인 방향을 만들었습니다. 제품과 서비스를 빠르게 이해하는 A안, 기술과 근거를 보여주는 B안, 회사의 철학과 사람을 보여주는 C안이었어요. 단순히 디자인 적인 취향의 안을 검토하는것이 아니라, 방향에따른 다른 시안을 만들도록 가이드했어요.
시안을 보고 다시 물었습니다.
MRD에 근거, A/B/C 세 가지 안이 MRD에서 정한 목표 각 영역에
어떻게 부합하는지 설명해.기준이 생기니 A안의 구조를 기본으로 C안의 기업 스토리와 B안의 기술 설명을 결합하기로 정할 수 있었어요. 그 방향을 제품·회사·인사이트 등으로 확장하면서 결합 시안은 34개의 클릭형 화면으로 발전했습니다. 메뉴를 한 줄로 정리하고, 공식 제품 로고를 적용하고, 모바일에서 글자가 넘치지 않는지 확인하는 작은 수정도 많았어요. ‘AI that Works.’(slogan)를 한 줄로 표시하는 것처럼 브랜드 표현도 직접 짚어가며 고쳤습니다. 화면이 생기니 설명만 할 때보다 구체적인 피드백을 줄 수 있었어요.
<A/B/C안 중, C안 화면 스크린>
가장 오래 고민한 질문은 개발팀과의 R&R이 었어요
AI로 화면을 만들 수 있게 되면서, 이후의 운영 책임을 어디에 둘지 더 분명히 해야 했어요. 콘텐츠를 바꾸는 일, 관리자 권한을 설정하는 일, 문의 정보를 저장하는 일, 장애가 생겼을 때 복구하는 일은 각각 담당과 완료 기준이 필요했습니다. 제가 정리한 방향은 이랬어요.
마케팅 팀 — 사업 목표, 콘텐츠와 브랜드 기준, 편집·발행 정책, 사용자 관점의 검수
내부 개발팀 — 웹 구현, CMS·DB·권한, 서비스 연동, 배포·백업·장애 대응 등 기술 책임
외주(만약, 고려한다면) — 내부 수행이 어려운 범위를 프로젝트 단위로 검토
특히 ‘콘텐츠를 직접 운영하고 싶다’는 요구를 구체화했어요. 마케팅팀이 글과 페이지를 수정할 수 있으면서도 사이트 구조와 권한은 안정적으로 관리되는 환경이 필요했습니다. 특히 SEO/AEO/GEO 설계까지 고려한 시의성 있고 당사 브랜드/제품 전략 방향과 얼라인 된 글감을 찾고 콘텐츠 draft를 자동 작성, blog 글을 제작하는 기능은 아직 완성하지는 못했습니다.
화면 검토를 넘어 기능 구현으로 넘어갔어요
요구사항은 PRD와 Spec Kit을 활용해 사용자 시나리오와 완료 확인 기준으로 더 구체화했습니다. 문의는 접수뿐 아니라 담당 배정, 응대 기한, 이메일 이력까지 연결하는 방향으로 설계했고, 콘텐츠 발행은 초안·검토·승인 흐름을 별도로 정리했어요. 이후 Firebase를 연결하는 단계로 넘어가 문의를 Firestore에 저장하는 흐름, 이메일 로그인, 관리자 문의 조회 화면, 접근 제한 규칙의 코드를 추가했습니다.
사용한 프롬프트 전문 — 이번 경험을 바탕으로 재구성 한, 비슷한 상황에서 그대로 쓸 수 있는 프롬프트예요.
현재 프로젝트의 파일과 이미 결정한 내용을 먼저 확인해줘.
구현된 것, 문서로만 설계한 것, 실제 환경에서 검증한 것을 구분해줘.
이번에 확보한 시간은 [기간·시간]이고, 해결하려는 문제는 [문제]야.
이 기간에 검토 가능한 결과물을 만들 수 있도록 범위를 좁히고,
마케팅·개발팀·외주가 맡을 일과 완료 확인 방법을 함께 정리해줘.
모르는 사실은 추정으로 확정하지 마.결과와 배운 점
확인된 결과
리뉴얼 요구사항과 운영·R&R 문서 — 목적·방문자·메뉴, 팀별 역할 분담 방향을 문서로 정리했습니다. 개발팀 공유&협의 예정이에요.
클릭형 시안 4개 화면 — A/B/C 세 안을 비교한 뒤 결합안(v2)으로 확장했습니다. 제품 소개, 회사 정보, AI 인사이트, R&D Tech Blog를 구성했고, AI 인사이트와 R&D Tech Blog는 목적이 다른 채널로 나눴어요. 여러 화면폭에서 가로 넘침과 이미지 누락을 검사한 기록도 남겼습니다.
이관 기초 목록 — 확보한 자료에서 CMS 콘텐츠 161건, 이미지 610개의 파일 존재·매핑을 확인했습니다. 옮길 대상 목록을 정리했고, 이관은 어사이드로 실행할거에요.
기능 구현 사양과 초기 코드 — Firestore 문의 저장, 이메일 로그인, 관리자 문의 조회 화면, 접근 제한 규칙. 실제 배포·관리자 계정까지 로그인, DB 확인했어요. cms도 추가해볼 예정이에요.
시행착오 — AI가 제 의도를 다르게 이해한 순간
Webflow를 포함해 다른 CMS를 개발팀과 비교하려고 했는데, 대화 중에는 Webflow를 후보에서 제외하는 뜻으로 정리되기도 했어요. 그래서 다시 설명했습니다.
의도는 Webflow도 포함해 다른 CMS와 개발팀이 함께 비교하자는 뜻 맞아.
하지만 특정 툴에 바인딩되고싶지는 않아.그 뒤로는 제품 이름에 앞서 실제 운영 과업을 비교 기준으로 삼았어요. 글에 표와 이미지를 넣기 편한지, 작성과 승인 권한을 나눌 수 있는지, 공개된 글의 수정 초안이 바로 노출되지 않는지, 나중에 콘텐츠를 다른 시스템으로 옮길 수 있는지 같은 질문입니다.
또 하나는 문서 조사와 실제 검증의 차이였어요. 서비스 소개에 기능이 있다는 것과 우리 계정에서 원하는 대로 작동한다는 것은 달랐습니다. 이 차이를 기록해두는 것이 이후 개발팀과의 협업에도 필요하겠다고 생각했어요.
꿀팁
이미 진행 중인 일이 있다면, 새 아이디어를 받기 전에 “지금까지 된 것과 남은 일을 구분해 범위만 좁혀줘”부터 요청하세요. 바이브 코딩으로 대화를 이어가며 웹사이트를 구축할 때 자꾸 산으로 가는걸 막으려면 처음 목적을 확인하고 옵션을 줄여나가는 것, 선택을 하고 가이드를 명확히 주는게 중요해요.
구현된 것 / 문서로만 설계한 것 / 실제 환경에서 검증한 것을 나눠서 말하게 하면, 결과를 과장 없이 정리할 수 있어요.
시안을 여러 개 만드는 것보다, 비교할 기준 문서를 먼저 두는 편이 선택을 빠르게 합니다.
도구를 비교할 때는 제품 이름이 아니라 실제 운영 과업(권한 분리, 승인 흐름, 이관 가능성)으로 기준을 세우세요.
AI가 의도를 좁혀 이해했다 싶으면, 부정문으로 고치기보다 “이것도 포함해서 비교하자”처럼 의도를 다시 문장으로 못 박는 편이 빨랐어요.
도움이 필요한 부분
마케팅팀이 직접 글을 발행하면서도 사이트 구조와 권한은 안정적으로 유지하는 운영 구조, 실제로 어떻게 나누고 계신가요?
AI로 만든 시안과 초기 코드를 개발팀에 넘길 때, Handoff 문서 이외 도움되는 산출물 형태가 있다면 궁금합니다.
앞으로의 계획
다음에는 콘텐츠를 작성·검토·발행하는 흐름을 구현하려고 해요. 개발팀과는 이번에 정리한 화면과 R&R 문서를 놓고 기술 구성과 공수를 협의할 계획입니다. CMS 편집·승인 기능과 CRM·메일 연동도 후속 작업으로 남아 있어요.
확인이 필요한 부분
실제 배포와 관리자 계정 권한 부여, 운영 환경에서의 저장·조회 검증
개발팀과의 담당자 배정 및 공수 합의
CMS 후보 검토 - 서비스별 기능이 우리 계정 환경에서 기대대로 작동하는지
도움 받은 글 (옵션)
글 구성은 닿님 의 write-post 방식을 참고하고, 지아코모님 강의, 소개해주신 aside로 draft 원고를 작성, 편집, 완성했어요.
실제 작업 기록에서 출발해 문제·과정·결과·재사용 프롬프트를 연결하는 구성입니다. https://github.com/daht-mad/write-post
노닥 AI 워케이션 2기(용평)에서 진행한 작업을 정리한 것입니다.
쭌님, 황금호랑이님, 멘토 존님 그리고 4조 여러분들. 그대들에게 Special Thanks를 전합니다.파란 하늘과 초록을 충분히 누리지 못해 아쉽기도 했지만, 맑은 공기와 창밖 풍경만으로도 환기되는 찐한 주말이었습니다.
모두, 감사합니다!
