지금 보고 있는 이 웹사이트. studiobth.dev. 3일 만에 만들었다.
허풍이 아니다. 타임라인을 그대로 공개한다.
타임라인
- 1시간: 비즈니스 설계 (페르소나, 서비스 정의, value chain, 경쟁 분석)
- 1시간: 설계 문서 패키지 (일반적인 표준 구조와는 다르게, 더 구조화되고 세분화된 자체적인 SSOT 설계 패키징을 활용)
- 1일: 랜딩 페이지 전체 구현 (Hero, Intro, Pain, Solution, HowItWorks, BeforeAfter, CaseStudy, Package, Pricing, CTA)
- 1일: AI 챗봇 (Gemini 연동, 스트리밍, 세션 로깅) + 유저 행동 트래킹 인프라
- 1일: 클라이언트 대시보드 + 블로그 시스템 + 도메인 연결 + 배포
총 3일. 설계 포함하면 3일 + 2시간.
왜 이게 가능한가
직접 만든 서비스 설계/개발 설계 AI 엔진을 쓰기 때문이다.
기획자, PM, 풀스택 개발자, UX/UI 디자이너가 팀으로 움직이는 구조가 아니다. 설계 맥락을 AI 엔진에 넣으면, 설계 문서가 2시간 만에 나온다. 그 설계 문서를 기반으로 구현하면, 방향이 틀어질 일이 없다.
크몽 외주 300만원 vs 올인원 300만원에서 "5명이 2달 할 일을 5일에 끝낸다"고 했다. 이 웹사이트가 그 증거다.
뭐가 들어가 있는가
"3일 만에 만들었다"가 "대충 만들었다"를 의미하지 않는다. 들어가 있는 것들을 보면:
AI 챗봇
Gemini API 기반. 업종 + 문제 상황을 입력하면 AI가 역산 추론으로 병목을 진단하고, 해결 방향을 제시한다. 스트리밍으로 실시간 타이핑된다. 대화 세션은 DB에 자동 로깅되고, 상담이 제출되면 알림이 온다. 제출된 상담 내역을 빠르게 캐치 후, 상담 진행을 결정하면 프로젝트 상담 큐로 DB에 자동 적재한다.
유저 행동 트래킹
페이지뷰, 스크롤 깊이(25/50/75/100%), 재방문, 챗봇 사용, 상담 신청. 모든 유저 행동이 추적된다. 어떤 섹션에서 이탈하는지, 어떤 경로로 상담 신청에 도달하는지 데이터로 보인다.
인터랙티브 제품 목업
macOS 데스크탑 프레임 안에서 실제 제품 흐름이 자동으로 순환된다. 업종별 AI 상담 목업도 동적으로 렌더링된다. 스크린샷이 아니라 코드로 된 UI다.
클라이언트 대시보드
로그인하면 프로젝트 진행 현황, 상담 이력, 설계 문서, 계약 정보를 실시간으로 볼 수 있다. 데모 계정으로 직접 체험할 수 있다.
블로그
지금 읽고 있는 이 글. 현재 28편.
SEO는 단순하게 생각하면 로직이 간단하다. 검색 활동의 가치 사슬을 보면 된다.
- 유저가 의도를 갖고 검색한다
- 의도에 부합하는 검색 결과가 출력된다
- 페이지를 방문한다
- 의도에 부합하는 양질의 콘텐츠가 있으면 체류시간이 늘어난다
- 해당 페이지의 다른 연관 콘텐츠를 추가로 소비한다
즉, 의도에 부합하는 양질의 콘텐츠를 제공하는 것이 가장 기본이고 핵심이다.
왜 그럴까. 검색 플랫폼으로서 구글은 검색 트래픽을 모아서 체류시키고, 이를 토대로 광고를 유통한다. 코어 밸류는 검색이라는 유저 행위의 value chain에서 의도에 부합하는 양질의 콘텐츠를 제공하여 만족시키는 것이다.
이것이 근본이다. 나머지 기술적인 세팅들(메타 태그, JSON-LD 구조화 데이터, sitemap, 서버 렌더링)은 부가적인 것이다. 당연히 간과해서는 안 되지만, 본질은 콘텐츠다. 구글의 검색엔진 최적화(SEO) 기본 가이드를 따라가면 된다.
그래서 블로그를 이렇게 만들었다. 서비스 설계 맥락과 내 기존 글쓰기 톤을 AI에 주입시켜서 초안 28편을 2시간 만에 뽑았다. 전부 직접 검수하고 다듬었다. 글 간에 내부 링크가 걸려 있어서 연관 콘텐츠 소비가 자연스럽게 이어진다.
디자인
솔직히 말하면, 디자인적인 특출함은 전혀 없다. 글래스 몰피즘, 3D 틸트, GSAP 애니메이션 같은 건 레퍼런스 웹사이트들의 코드를 분석해서 적용한 것이다.
내가 신경 쓰는 건 UX 마찰 최소화다. 유저가 코어 가치에 도달하기까지 불필요한 단계가 없는지, 인지 부담이 과한 곳은 없는지. 근본적으로 디자인을 기능적인 관점으로 바라본다. 도구보다 사고 프레임이 먼저다에서 이야기한 것과 같은 맥락이다. 중요한 건 어떤 도구를 쓰느냐가 아니라, 무엇을 위해 쓰느냐다.
도그푸딩
이 웹사이트 자체가 studio.bth의 도그푸딩이다. 클라이언트에게 "이렇게 해드립니다"라고 말하는 것과, "이렇게 만들었습니다. 직접 보세요"라고 보여주는 건 완전히 다르다.
블로그 콘텐츠도 마찬가지다. 설계 맥락이 있으니 글 주제가 자동으로 나온다. 내 톤으로 쓰고, 내 경험을 넣고, 내부 링크를 건다. 글 하나 쓰는 데 10분이면 충분하다. 설계 문서가 있으면 주제는 무한하게 생산 가능하다.
사장님, 블로그 글 쓰고 계신가요?에서 이야기한 "고객 유입 콘텐츠" 서비스가 바로 이 구조다.
클라이언트에게도 같은 속도를 제공한다
비즈니스 설계 없이 개발하면 벌어지는 일에서 설계가 왜 먼저인지 이야기했다. 이 웹사이트가 3일 만에 나올 수 있었던 이유도 설계가 먼저 됐기 때문이다.
설계 2시간. 구현 3일. 이 속도를 클라이언트에게도 동일하게 제공한다.