나는 Cursor와 Cloudflare로 2개월 만에 Daily Tarot 앱을 코딩했다 — 아직 AI가 할 수 없는 것

Source: Dev.to

위의 링크에 포함된 본문을 제공해 주시면, 해당 내용을 한국어로 번역해 드리겠습니다.

Introduction

몇 달 전, 나는 명확한 프로젝트 아이디어를 가졌습니다: 사람들이 카드를 뽑고 의미 있는 해석을 받을 수 있는 깔끔하고 무료인 일일 타로 리딩 사이트—유료 장벽도, 다크 패턴도, “당신의 미래가 차단되었습니다, 업그레이드해서 해제하세요” 같은 문구도 없습니다. 그 결과가 **dailytarot.io**이며, 한 장, 세 장, 켈트 십자가, 예/아니오 스프레드를 포함하고 78장의 카드 의미 라이브러리를 제공하는 완전한 타로‑리딩 웹 앱입니다. 이를 만들기까지 대략 두 달 정도의 즉흥 코딩을 했으며, 그 과정에서 AI가 빛을 발하는 영역과 인간의 눈을 절대 대체할 수 없는 영역에 대해 많이 배웠습니다.

스택: 왜 나는 Cloudflare에 전념했는가

프로젝트를 시작했을 때, 사이트가 혹시 인기를 끌게 되더라도 확장할 수 있는 가장 간단한 호스팅 설정을 원했습니다. 그래서 Cloudflare 풀‑스택 콤보를 선택했습니다:

• Cloudflare Pages – 프론트엔드 호스팅
• Cloudflare D1 (엣지에서 동작하는 SQLite) – 카드 데이터, 스프레드, 해석 저장
• Cloudflare R2 – 카드 이미지와 정적 자산 저장

이 세 가지 조합의 장점은 완벽하게 통합된다는 점입니다. D1 바인딩은 Pages 함수에 바로 끼워 넣을 수 있고, R2는 환경 변수 하나만 설정하면 바로 사용할 수 있으며, 전체 배포는 GitHub 푸시만으로 이루어집니다. 콜드 스타트에 대한 걱정이 없고, 관대한 무료 티어와 AWS 청구서 스트레스도 없습니다. 콘텐츠가 많은 사이드 프로젝트를 구축하고 있고 아직 Cloudflare 풀‑스택을 사용해 보지 않았다면, dailytarot.io 가 실제로 어떤 것을 구현할 수 있는지 보여주는 살아있는 데모입니다.

툴링: Cursor + 두 가지 다른 AI 뇌

내 주요 코딩 환경은 Cursor와 내장된 Composer 1.5였습니다. 이것이 작업의 주축이었으며—라우트 핸들러 생성, 카드‑스프레드 UI 구축, D1 쿼리 로직 작성, 컴포넌트 스캐폴딩, 레이아웃 반복 등에 사용했습니다. Composer는 사실상 AI와 페어 프로그래밍을 하면서 전체 레포 전체에 걸쳐 컨텍스트를 유지하는, 지속적인 다파일 “이 기능 만들기” 세션에 탁월합니다.

디버깅을 위해서는 Claude Opus 4.6을 별도로 활용했습니다. 미묘하거나 혼란스러운 방식으로 무언가가 깨졌을 때—예를 들어 D1 마이그레이션이 제대로 적용되지 않거나, 카드‑스프레드 상태 관리 버그가 발생하거나, 로컬에서는 동작하지만 프로덕션에서는 동작하지 않는 R2 프리사인드 URL—관련 컨텍스트를 Opus에 붙여넣고 문제를 논리적으로 분석하도록 요청했습니다. 두 모델 간의 논리 깊이 차이는 디버깅 작업에서 확연히 드러났습니다. Opus는 표면적인 패치 제안에 그치지 않고 실제 근본 원인을 자주 찾아냈습니다.

워크플로우

1. Composer 1.5 – 빠르게 스캐폴드하고 반복
2. Claude Opus 4.6 – 이해가 안 되고 진정한 추론이 필요할 때
3. 반복하고, Cloudflare Pages에 배포

AI가 정말 어려워했던 부분: 타로 카드 의미

여기서 아무도 알려주지 않는 사실이 있습니다. 타로 앱을 만들 때 가장 어려운 부분은 코드가 아니라 콘텐츠입니다.

dailytarot.io 은 78장의 모든 타로 카드—메이저 아르카나와 마이너 아르카나의 두 슈트—를 다루며, 각 카드마다 정방향과 역방향 의미를 사랑, 직업, 건강, 일반적인 조언 등 다양한 리딩 상황에 맞춰 제공합니다. 이는 많은 해석적 콘텐츠를 의미합니다.

처음에 저는 이렇게 생각했습니다: “AI에게 모든 카드 의미를 생성하도록 프롬프트만 주고, 빠르게 검토해서 주말 안에 끝내면 되겠지.” 저는 크게 틀렸습니다.

AI‑생성 타로 해석의 문제점

AI 모델에게 타로 카드 의미를 생성하도록 요청했을 때, 문장은 유창하고 형식도 깔끔했지만 실제로 타로를 사용하는 사람들에게 중요한 방식으로 미묘하게 틀린 경우가 많았습니다. 문제점은 몇 가지 범주로 나뉩니다:

• 톤 불일치 – 전통적인 타로 해석은 특정한 어조를 가지고 있습니다: 반성적이며, 처방적이지 않습니다. AI‑생성 텍스트는 종종 일반적인 자기계발 언어(“내면의 힘을 받아들여라!”)로 흐르거나, 뒤집힌 타워 카드를 뽑은 사람이 힘든 날에 정말로 불안해할 만한 과도하게 불길한 경고로 치우치는 경향이 있었습니다.
• 맥락 일관성 부족 – 카드의 의미는 전개 위치에 따라 의미 있게 변합니다. “과거” 위치에 있는 삼검은 “미래” 위치에 있는 같은 카드와 매우 다르게 해석됩니다. AI는 종종 위치적 뉘앙스를 무시하거나 전개 유형 간에 서로 모순되는 의미를 제시했습니다.
• 심오한 세부 사항에 대한 정확도 흐림 – 일부 카드는 전통적인 상징성을 가지고 있습니다 — 라이더‑웨이트 이미지, 토트 체계 변형, 수비학적 연관성 등 — AI는 이를 대충 틀리게 하거나 섞어 버리는 경우가 있었습니다. 타로에 익숙한 사용자에게는 신뢰가 즉시 무너집니다.
• 역방향 카드에 대한 잘못된 긍정/부정 – AI 모델은 역방향 카드 의미를 부드럽게 만드는 경향이 있습니다. 역방향 카드는 단순히 “정방향 의미에 약간의 부정이 더해진 것”이 아니라, 완전히 다른 원형적 무게를 지닙니다. AI는 이 구분을 평탄하게 만들었습니다.

대신에 내가 해야 했던 일

나는 모든 카드 의미에 대해 수동 검토를 진행했습니다. 단순히 훑어보는 것이 아니라 전통적인 자료와 교차 검증하고, 위치 논리를 확인하며, 어조를 조정하고, 미묘하게 오해를 일으킬 수 있는 부분을 다시 작성했습니다. 이것이 “2주 프로젝트”를 2개월 프로젝트로 만든 이유입니다.

AI도 여전히 유용했습니다 — 첫 번째 초안을 빠르게 만들 수 있는 엔진이자, 의미가 왜 잘못됐는지 설명하려 할 때 좋은 스파링 파트너였죠. 하지만 실제로 **dailytarot.io**에 표시될 모든 해석에 대해 최종 결정을 내리는 것은 인간이었습니다. 사람들이 인생의 취약한 순간에 카드를 뽑는 제품인 만큼, “충분히 좋은” AI 출력은 받아들일 수 없었습니다.

Vibe 코딩이 실제로 어떻게 보이는지 (좋은 부분)

AI 코딩 경험에 대해 지나치게 부정적으로 들리게 하고 싶지는 않아요 — 코드 자체에 관해서는 Composer가 정말 변혁적이었거든요. 실제로 저를 구해준 부분은 다음과 같습니다:

• Feature scaffolding at speed – “이 10개의 포지션을 가진 Celtic Cross 스프레드를 추가하고, 추첨을 D1에 저장하고, 카드‑플립 애니메이션으로 결과를 표시해줘” 라고 말하면 Composer가 전체 라우트, DB 스키마, 그리고 React 컴포넌트를 몇 분 안에 생성하는 모습을 볼 수 있었습니다.
• Consistent naming and typing – AI가 프론트‑엔드와 D1 쿼리 전반에 걸쳐 TypeScript 타입을 일관되게 맞춰 주어, 보통 발생하는 수동 리팩터링의 왕복 작업을 크게 줄여줬습니다.
• Rapid prototyping of UI states – “카드‑드로우 뷰용 로딩 스켈레톤”을 요청하면 즉시 기존 디자인 시스템과 맞는 재사용 가능한 컴포넌트를 받아볼 수 있었습니다.
• Zero‑setup CI/CD – Composer가 필요한 wrangler.toml과 GitHub Actions 워크플로 파일을 추가해 주어, 각 푸시마다 별도 설정 없이 자동으로 빌드되고 Cloudflare Pages에 배포되었습니다.

물론 단점은 콘텐츠 측면이었죠(위를 참고). 하지만 인프라 측면에서는 AI‑보강 워크플로가 혼자 두 달 동안 진행하던 작업을 작은 팀의 스프린트처럼 느껴지게 만들었습니다.

Bottom Line

AI는 코드를 가속화할 수 있습니다. 특히 원하는 아키텍처에 대한 명확한 머릿속 모델이 있을 때 더욱 그렇습니다.

하지만 도메인‑특화, 미묘한 콘텐츠—예를 들어 타로 해석과 같은 경우—에서는 여전히 지식이 풍부한 사람이 결과를 검증하고, 수정하고, 다듬는 과정이 필요합니다.

스택이나 워크플로가 궁금하다면 dailytarot.io 를 자유롭게 탐색해 보세요. 두 달간의 실험 결과를 확인할 수 있습니다. 즐거운 코딩 (그리고 카드 뽑기) 되세요!

Composer‑Powered “Vibe Coding”

내가 만든 것

Composer를 사용해 단 2개월 만에 풀‑스택 AI 기반 타로 리딩 웹앱을 만들었습니다. 결과물은 dailytarot.io 로, 무료이며 프로덕션 수준의 사이트이며 다음과 같은 특징을 가지고 있습니다:

• 전체 78장의 타로 카드를 제공합니다
• 다양한 스프레드 유형을 제공합니다 (예: 켈틱 크로스, 세 장 스프레드)
• 각 카드에 대한 인간 검토 의미를 제공합니다
• 완전히 Cloudflare 엣지에서 실행됩니다 (관리할 서버가 없습니다)

Composer가 혁신이 된 이유

콘텐츠 + AI 사이트 구축 시 배운 교훈

AI 생성 콘텐츠가 핵심인 제품(단순 개발 보조가 아님)을 계획하고 있다면, 다음 사항을 기억하세요:

1. 콘텐츠 QA에 실시간 예산을 배정하세요
   AI는 초안 생성 기계일 뿐, 출판자는 아닙니다. 정확성이나 어조가 중요한 경우, 인간 검토 시간을 할당하세요.

2. 도메인 지식은 대체할 수 없습니다
   저는 사전에 타로를 공부했기 때문에 AI가 만든 타로 의미 오류를 잡아낼 수 있었습니다. 익숙하지 않은 도메인에서 구축하면 AI 콘텐츠 QA가 거의 불가능해집니다.

3. “빠르게 구축” 모델과 “깊게 생각” 모델을 분리하세요

   • 빠른 반복을 위해 경량 모델(예: Composer)을 사용하세요.
   • 디버깅 및 추론이 많이 필요한 작업에는 무거운 모델(예: Opus)으로 전환하세요.
     필요할 때 깊이를 유지하면서 예산을 절감할 수 있습니다.

4. Cloudflare의 무료 티어는 사이드 프로젝트에 놀라울 정도로 좋습니다
   D1, R2, 그리고 Pages를 함께 사용하면 비용을 한 푼도 쓰지 않기 전에 상당한 트래픽을 처리할 수 있습니다. dailytarot.io 같은 프로젝트에선 사실상 무료 프로덕션 인프라가 됩니다.

결과

dailytarot.io 은(는) 라이브이며 무료이고, 여러 스프레드 유형을 포함한 전체 타로 덱을 다룹니다. 모든 의미는 인간이 검토했으며, 앱은 Cloudflare 엣지에서 서버 없이 실행됩니다.

다시 할까요? 물론이죠.
두 달은 그때는 길게 느껴졌지만, AI 도움 없이 같은 프로젝트를 진행했다면 최소 6개월이 걸렸을 것이고—아니면 아예 만들지 못했을 겁니다. “바이브 코딩”은 “판단이 필요 없다”는 뜻이 아니라 당신이 판단을 가져오고, AI가 속도를 가져온다는 의미입니다.

오늘 카드를 뽑는다면, 좋은 카드가 나오길 바랍니다. 🃏