goldtag

20편의 여정을 돌아보며 "타로카드를 보는 웹페이지를 만드려고 해." 이 한 문장에서 시작된 프로젝트가 여기까지 왔다. 78장의 카드 데이터를 설계하고, 남색 배경에 금빛 텍스트로 분위기를 잡고, 카드가 숨 쉬듯 떠다니는 애니메이션을 만들고, 모바일에서의 수십 가지 문제를 해결하고. 20편에 걸쳐 그 과정을 기록했다. 이 마지막 편에서는 프로젝트 전체를 거시적으로 돌아보려 한다. AI가 정말로 도움이 됐던 순간과 그렇지 않았던 순간. 이 프로젝트를 통해 정립한 AI 협업 방법론. 그리고 사이드 프로젝트에서 AI 협업이 가지는 본질적 가치에 대해. 전체 프로젝트 타임라인 타로 마스터의 개발 과정을 시간순으로 정리하면 이렇다. 아이디어 구체화와 기술 스택 결정에 하루. 78장 카드 데이터와 해석 텍스트 작성에 이틀. 기본 리딩 기능과 UI 구현에 사흘. 애니메이션과 마이크로 인터랙션에 이틀. AI 실시간 해석과 서버리스 API 구축에 이틀. PWA 전환과 사용자 기능 추가에 사흘. 모바일 최적화와 UI 개편에 나흘. 전부 합치면 약 2주 반이다. 풀타임으로 집중한 게 아니라 퇴근 후와 주말을 활용한 시간이니, 실제 투입 시간은 이보다 적다. AI 없이 같은 결과물을 만들었다면 최소 두 달은 걸렸을 것이다. 이 시간 차이가 사이드 프로젝트의 생사를 결정한다. 두 달짜리 사이드 프로젝트는 완주 확률이 극히 낮지만, 2주 반이면 에너지가 식기 전에 끝낼 수 있다. AI가 잘한 것 다섯 가지 첫째, 도메인 지식 전달이다. 타로에 대해 거의 몰랐던 내가 78장 카드의 의미, 다양한 스프레드 방식, 정방향과 역방향 해석의 차이를 빠르게 파악할 수 있었던 건 AI 덕분이다. 새로운 분야에 진입하는 초기 학습 곡선을 극적으로 낮춰줬다. 둘째, 대량 콘텐츠 생성이다. 78장 카드 각각에 대한 정방향/역방향 해석 텍스트, 총 156개의 해석을 작성하는 건 사람이 하면 일주일은 걸린다. AI와 함께 이틀 만에 완성했다. 물론 AI가 생성한 텍스트를 그대로 쓴 게 아...

"AI에게 다 시키면 되지"의 달콤한 유혹 "GPT한테 시키면 5분이면 만들어주던데?" 이 말을 들을 때마다 복잡한 감정이 든다. 틀린 말은 아니다. AI에게 "타로 앱 만들어줘"라고 하면 정말로 동작하는 코드가 나온다. 화면에 카드가 보이고, 클릭하면 뒤집어지고, 해석 텍스트가 나타난다. 5분은 과장이지만, 30분이면 충분하다. 문제는 그 다음이다. "카드 애니메이션을 바꾸고 싶어." "리딩 히스토리를 추가하고 싶어." "모바일에서 레이아웃이 깨지는데." 이런 요구가 오는 순간, AI가 5분 만에 만들어준 코드 위에서 개발자가 할 수 있는 일이 거의 없다. 코드를 이해하지 못하니까. 이것이 바이브 코딩의 함정이다. 그리고 이 글은 타로 마스터 프로젝트 전체를 관통하는 핵심 주제, "바이브 코딩과 의도 기반 협업의 차이"에 대한 이야기다. 바이브 코딩이란 무엇인가 바이브 코딩은 간단히 말해 "AI에게 코드를 쓰게 하고, 분위기(vibe)만 확인하면서 개발하는 것"이다. 코드의 내부 구조를 이해하지 않고, 결과물이 원하는 대로 동작하면 넘어가는 방식이다. 빠르고, 편하고, 즉각적인 만족감을 준다. 이 방식이 유효한 경우도 분명 있다. 일회성 스크립트, 빠른 프로토타입, 학습 목적의 코드. 한 번 쓰고 버릴 코드라면 내부 구조를 깊이 이해할 필요가 없다. 문제는 이 방식을 "지속되는 프로젝트"에 적용할 때 발생한다. 타로 마스터는 한 달이 넘는 기간 동안 점진적으로 기능이 추가되고, 디자인이 바뀌고, 버그가 수정되는 프로젝트였다. 초기에 만들어진 코드 위에 계속 새로운 코드가 쌓인다. 기초가 이해되지 않은 상태에서 쌓아올린 코드는 모래 위의 성이다. 결정적 차이: "만들어줘" vs "이렇게 설계하고" 바이브 코딩과 의도 기반 협업의 차이를 가장 잘 보여주는 건 AI에게 ...

  데스크톱에서 완벽했던 앱이 모바일에서 무너지다 "데스크톱에서 잘 되는데?" 이 말은 프론트엔드 개발에서 가장 위험한 문장 중 하나다. 타로 마스터를 처음으로 내 스마트폰에서 열었을 때, 화면 하단이 잘려 있었다. 카드 뒤집기 애니메이션이 버벅거렸다. 텍스트가 너무 작아서 읽을 수 없었다. 데스크톱에서의 그 우아한 경험은 어디로 간 걸까. 웹 트래픽의 절반 이상이 모바일에서 발생한다. 타로 마스터 같은 가벼운 엔터테인먼트 앱은 그 비율이 더 높을 수밖에 없다. 출퇴근길에, 침대에서, 친구와 커피를 마시다가 "타로 한번 볼까?"라고 꺼내는 게 일상적 사용 시나리오다. 모바일 경험이 나쁘면 사용자의 대부분을 잃는다는 뜻이다. 하단 탭 바: 네이티브 앱의 감각 빌리기 모바일 앱에서 가장 자연스러운 네비게이션은 하단 탭 바다. 인스타그램, 카카오톡, 거의 모든 네이티브 앱이 하단 탭을 사용한다. 엄지손가락이 자연스럽게 닿는 위치에 주요 메뉴를 배치하는 것이 모바일 UX의 기본 중의 기본이다. 타로 마스터에도 하단 탭 바를 도입했다. 홈, 리딩, 히스토리, 설정. 네 개의 탭으로 구성했다. 웹앱에서 하단 탭 바를 구현하는 건 기술적으로 어렵지 않다. CSS의 position: fixed와 bottom: 0을 쓰면 된다. 하지만 여기서부터 진짜 문제가 시작된다. 모바일 브라우저에는 자체 UI가 있다. 주소창, 하단 도구 모음. 이것들이 화면 공간을 차지하면서 우리가 만든 하단 탭 바와 충돌한다. 특히 스크롤할 때 브라우저 UI가 나타났다 사라졌다 하면서 레이아웃이 춤을 추는 현상이 발생한다. CSS의 환경 변수 env(safe-area-inset-bottom)을 사용해서 이 문제를 완화했다. 이 값은 노치나 홈 인디케이터 같은 시스템 UI 영역의 크기를 알려준다. 하단 탭 바의 패딩에 이 값을 더하면 시스템 UI와 겹치지 않는 안전한 영역에 탭이 위치한다. 하지만 이건 시작에 불과했다. Chrome 모바일의 악명 높은 하단 탭 버그 ...

  "이거 하루면 되겠는데"가 진짜 하루에 되는 경험 기능 하나를 추가하는 데 보통 얼마나 걸릴까. 기획하고, 설계하고, 구현하고, 테스트하고. 회사 프로젝트라면 일주일은 잡아야 하는 일이다. 그런데 AI와 함께하면 "이거 하루면 되겠는데"라는 직감이 진짜로 하루 안에 현실이 된다. 이번 편은 타로 마스터에 추가한 여섯 가지 기능의 이야기다. 리딩 히스토리, 스트릭, SNS 공유, PDF 리포트, Instagram 스토리 카드, 자유 선택 모드. 하나하나가 독립적인 기능이지만, 모두 "사용자가 더 오래, 더 자주 돌아오게 만드는" 공통 목적을 가지고 있다. 리딩 히스토리: localStorage로 만드는 "내 타로 일지" 타로 리딩을 하고 나서 결과를 다시 보고 싶을 때가 있다. "지난주에 받은 리딩이 뭐였더라?" 하는 순간. 이 니즈를 충족시키는 가장 간단한 방법이 리딩 히스토리 기능이다. 데이터베이스 없이 localStorage만으로 구현했다. 사이드 프로젝트에서 데이터베이스는 유지 비용과 복잡성을 급격히 높이는 선택이다. 서버를 운영해야 하고, 사용자 인증이 필요해지고, 개인정보 보호 문제까지 따라온다. localStorage는 브라우저에 데이터를 저장하는 가장 단순한 방법이다. 서버 없이, 인증 없이, 사용자의 기기에만 데이터가 남는다. 리딩 결과를 JSON으로 직렬화해서 저장하고, 히스토리 페이지에서 날짜순으로 보여주는 구조다. Claude에게 "localStorage를 활용한 리딩 히스토리 기능을 만들고 싶다. 날짜, 리딩 타입, 뽑은 카드, 해석 텍스트를 저장해야 한다"고 설명하자, 데이터 구조 설계부터 저장/조회 로직까지 빠르게 나왔다. 한계는 분명하다. 브라우저 캐시를 지우면 데이터가 사라진다. 기기 간 동기화도 안 된다. 하지만 사이드 프로젝트에서 이 정도면 충분하다. "내 타로 일지"라는 가치를 제공하면서도 기술적 복...