🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

저자는 AI 웹사이트 출시에서 가장 어려웠던 부분이 AI 자체가 아니라 결제, 클라우드, 배포, SEO, 그리고 사용자가 신뢰할 수 있는 프론트엔드 경험을 끝까지 제품으로 다듬는 과정이었다고 말한다.

📌 핵심 요약

• 저자는 이전에 웹 프로젝트를 90%까지 만들고도 Stripe, 웹훅, 운영 환경 변수, 배포 설정, 데이터베이스 상태, 리다이렉트 같은 마지막 작업에서 지쳐 중단하곤 했다고 회고한다.
• 올해는 Bazi 계산·해석 스킬을 Hidden Stems라는 실제 웹 제품으로 만들며, 무료 차트를 먼저 제공하고 유용하다고 느낀 사용자가 더 깊은 리딩을 구매하도록 하는 구조를 시험했다.
• 사용한 도구는 Codex, Stripe CLI, gcloud, Vercel CLI, Supabase처럼 특별하지 않았지만, Codex가 저장소 확인, 명령 실행, 오류 읽기, 파일 수정, 재배포, 검증까지 흐름을 끊지 않게 해준 점이 달랐다.
• Vertex AI와 Stripe는 각각 클라우드 권한·환경 변수·모델 호출, 결제 생성·웹훅·주문 상태·리포트 잠금 해제처럼 여러 상태를 작은 질문으로 나누어 확인하면서 덜 막막해졌다.
• 최종적으로 저자가 가장 어렵다고 느낀 것은 AI 생성이나 결제가 아니라 프론트엔드였다. 특히 Bazi의 문화적 맥락과 신뢰감, 설명력, 유료 리포트의 가치감을 화면 안에서 설득력 있게 만드는 일이 제품 사고의 핵심으로 남았다.

🧩 주요 포인트

1. 저자는 이전에 웹 프로젝트를 90%까지 만들고도 Stripe, 웹훅, 운영 환경 변수, 배포 설정, 데이터베이스 상태, 리다이렉트 같은 마지막 작업에서 지쳐 중단하곤 했다고 회고한다.
2. 올해는 Bazi 계산·해석 스킬을 Hidden Stems라는 실제 웹 제품으로 만들며, 무료 차트를 먼저 제공하고 유용하다고 느낀 사용자가 더 깊은 리딩을 구매하도록 하는 구조를 시험했다.
3. 사용한 도구는 Codex, Stripe CLI, gcloud, Vercel CLI, Supabase처럼 특별하지 않았지만, Codex가 저장소 확인, 명령 실행, 오류 읽기, 파일 수정, 재배포, 검증까지 흐름을 끊지 않게 해준 점이 달랐다.
4. Vertex AI와 Stripe는 각각 클라우드 권한·환경 변수·모델 호출, 결제 생성·웹훅·주문 상태·리포트 잠금 해제처럼 여러 상태를 작은 질문으로 나누어 확인하면서 덜 막막해졌다.
5. 최종적으로 저자가 가장 어렵다고 느낀 것은 AI 생성이나 결제가 아니라 프론트엔드였다. 특히 Bazi의 문화적 맥락과 신뢰감, 설명력, 유료 리포트의 가치감을 화면 안에서 설득력 있게 만드는 일이 제품 사고의 핵심으로 남았다.

🧠 상세 정리

1. 90%에서 멈추던 프로젝트의 반복

저자는 지난해 웹 프로젝트를 90%까지 만들고도 마무리하지 못하는 습관이 있었다고 말한다. 초반 70%는 아이디어가 신선하고 UI가 빠르게 만들어지며 로컬에서 기본 흐름이 동작하기 때문에 재미있었다. 하지만 마지막 단계에서는 Stripe, 웹훅, 운영 환경 변수, Next.js 오류, 배포 설정, 데이터베이스 상태, 클라우드 권한, 콜백 URL, 테스트 모드와 라이브 모드 같은 문제가 한꺼번에 몰려왔다. 각각은 해결 불가능한 문제가 아니었지만, 여러 개가 겹치자 프로젝트의 에너지를 소진시켰고 결국 실제 제품이 되기 직전에서 멈추게 만들었다.

2. Bazi 스킬을 제품으로 바꾸는 실험

이번에 저자가 선택한 프로젝트는 Bazi, 즉 사주·Four Pillars·중국 점성술과 관련된 작은 스킬이었다. 이 스킬은 사용자의 출생 정보를 바탕으로 상징적 차트를 계산하고 해석을 생성할 수 있었다. 로컬 스킬로는 흥미로운 수준이었지만, 실제 제품이 되려면 웹사이트, 사용자 흐름, 무료 차트, 유료 심화 리딩 같은 구조가 필요했다. Hidden Stems라는 이름의 사이트는 먼저 무료 Bazi 차트를 보여주고, 사용자가 그 차트가 유용하다고 느끼면 더 깊은 해석을 잠금 해제하도록 설계되었다. 저자가 검증하고 싶었던 것은 제품 아이디어뿐 아니라 Codex와 CLI 도구가 자신이 보통 인내심을 잃는 마지막 구간을 통과하게 해줄 수 있는지였다.

3. 특별하지 않은 스택, 달라진 작업의 연속성

저자가 사용한 도구들은 특별하거나 마법 같은 것이 아니었다. Codex는 코드베이스를 읽고, 코드를 바꾸고, 테스트를 실행하고, 버그를 추적하는 데 쓰였고, Stripe CLI는 결제 흐름에, gcloud는 Google Cloud와 Vertex AI에, Vercel CLI는 배포와 환경 변수 관리에, Supabase는 데이터베이스에 사용되었다. 차이는 도구 자체보다 작업 흐름에 있었다. 예전에는 Stripe나 Google Cloud에서 막히면 여러 문서를 열고 명령을 복사하고 오류를 검색하다가 어느 환경에 있는지도 헷갈리며 지쳤다. 이번에는 Codex가 저장소를 확인하고, 라우트를 보고, 명령을 실행하고, 오류를 읽고, 환경 변수를 점검하고, 파일을 고치고, 다시 배포한 뒤 결과를 확인하는 흐름 안에 계속 머물 수 있게 했다.

4. Vertex AI와 Stripe를 작은 상태로 쪼개기

저자가 가장 싫어할 것으로 예상했던 부분은 Vertex AI였다. Google Cloud는 결제 계정, 프로젝트, API 활성화, IAM, 리전, 서비스 계정, 인증 정보처럼 각각은 이해 가능한 요소들이 조합되면 미로처럼 느껴졌기 때문이다. 이번에는 모든 것을 완전히 이해한 뒤 움직이기보다, CLI가 드러내는 다음 문제를 따라가며 API 활성화, 프로젝트 확인, 인증 확인, 권한 누락 찾기, 모델 호출 시도, 환경 변수 수정, 재시도를 반복했다. Stripe도 비슷하게 접근했다. 결제 실패를 막연히 ‘결제가 고장났다’고 보지 않고, 설정 여부, 제공자 등록, 체크아웃 생성, 웹훅 도착, 주문 paid 상태, 리포트 잠금 해제, 생성 콘텐츠 저장 여부를 하나씩 확인하면서 블랙박스를 상태들의 연쇄로 바꾸었다.

5. SEO와 출시 잡무를 보이게 만든 체크리스트

SEO와 GEO 작업은 저자에게 또 다른 의외의 지점이었다. 사이트맵, 메타데이터, Google verification, 지역화 페이지, 프로그램 방식의 SEO 페이지, 검색 색인 확인, 외부 링크 메모, 디렉터리용 문구, 커뮤니티 게시글 초안 같은 일들은 지적으로 어려운 문제는 아니지만 쉽게 미뤄지는 작업이었다. 이번에는 이런 항목들을 파일과 체크리스트로 유지했고, Codex가 초안을 만들고, 페이지를 업데이트하고, 확인 작업을 도우며 완료된 일을 추적하는 데 기여했다. 저자는 이것이 SEO를 버튼 하나로 해결해준 것은 아니지만, 일이 충분히 눈에 보이게 되어 계속 움직일 수 있었다고 말한다. 많은 프로젝트가 하나의 거대한 문제 때문에 실패하는 것이 아니라 창업자가 작고 지루한 문제 스무 개를 조용히 피하기 때문에 실패한다는 점도 강조한다.

6. 가장 어려웠던 것은 프론트엔드와 제품 감각

여러 기술적 고비를 지나고 나서 저자가 가장 답답하게 느낀 부분은 AI 생성도 Stripe도 아니라 프론트엔드였다. 페이지는 기능적으로 동작할 수 있지만, 그것만으로 사용자가 왜 버튼을 눌러야 하는지 이해하거나 제품처럼 느끼는 것은 아니다. Hidden Stems는 Bazi, 한자, 오행, 천간, 지지, 운의 주기 등 서구 사용자에게 낯설 수 있는 문화적 개념을 다루기 때문에 단순히 출생 정보를 입력받는 화면 이상이 필요했다. UI는 필요한 만큼 설명해야 했고, 원래의 중국어 상징을 보존하면서도 읽기 어렵지 않아야 했으며, 동양 형이상학의 분위기를 유지하되 싸구려 장식처럼 보이면 안 됐다. 저자는 여러 버전을 거치며 현재 버전이 더 어둡고 의식적인 분위기와 실제 차트 중심 구조를 갖추게 되었지만, 여전히 완전히 만족하지는 못한다고 말한다.

7. 기술 루프 이후에 남는 인간의 판단

저자는 예전에는 출시를 하나의 거대한 문처럼 생각했다고 설명한다. 결제, 배포, 데이터베이스, AI, SEO가 모두 해결되지 않으면 프로젝트가 진짜가 아니라고 느꼈고, 그래서 마지막 10%가 무겁게 다가왔다. 이제는 그것이 여전히 귀찮고 함정이 많은 일이지만, 작은 문제들의 더미처럼 보이며 덜 외롭고 덜 미스터리하게 느껴진다. Codex는 취향, 판단, 제품 감각의 필요를 없애지 않았고 오히려 그것들을 더 선명하게 드러냈다. 엔지니어링 루프가 쉬워지면 남는 질문은 이것이 실제로 좋은 제품 경험인지이며, 저자는 바로 그 제품 루프에 여전히 인간의 눈이 필요하다고 결론짓는다.

🧾 핵심 주장 / 시사점

• AI 도구의 강점은 모든 판단을 대신하는 데보다, 오류 확인과 수정, 재배포, 검증으로 이어지는 엔지니어링 흐름을 끊기지 않게 만드는 데 있다.
• 복잡한 결제나 클라우드 문제는 하나의 거대한 장애로 보면 막막하지만, 확인 가능한 상태 질문들로 나누면 디버깅 가능한 작업이 된다.
• 기술적으로 동작하는 제품과 사용자가 신뢰하고 이해하며 행동하게 만드는 제품은 다르며, 그 차이는 프론트엔드 polish, 포지셔닝, 문화적 톤, 제품 감각에서 결정된다.

✅ 액션 아이템

• 결제, 웹훅, 운영 환경 변수, 배포 설정, DB 상태, 리다이렉트로 마무리되는 마지막 10% 작업을 항목별로 분리해 추적한다.
• Hidden Stems에서 무료 차트 후 유료 리포트 구매로 이어질 때 문화적 맥락·신뢰감·설명력 요소가 화면에서 설득되도록 프론트엔드를 다듬는다.
• Codex가 보여준 방식처럼 저장소 확인·오류 읽기·재배포·검증의 연속 루프를 유지하되 Vertex AI 호출과 Stripe 결제 상태를 작은 질문 단위로 계속 분해해 처리한다.

❓ 열린 질문

• 실제 출시에서는 AI보다 결제·클라우드·배포·SEO 중 어떤 항목이 먼저 병목으로 발생할 가능성이 가장 큰가?
• 무료 차트로 흥미를 유도한 뒤 유료 리포트 구매로 연결될 때 문화적 맥락 설명은 어느 지점에서 가장 강하게 작동하는가?
• Vertex AI 권한·환경 변수·모델 호출 오류와 Stripe 주문 생성·웹훅·리포트 잠금 해제 상태 이상을 구분할 기준은 어떤 방식으로 정의할 것인가?