1편: 아이디어에서 스펙까지 — AI에게 "뭘 만들지"를 함께 정하다

반응형

 

시리즈: AI 협업 개발기: 타로 마스터 프로젝트
키워드: AI 협업, 프로젝트 기획, 사이드 프로젝트, Claude, 요구사항 정의


시작은 단순한 호기심이었다

"타로카드를 보는 웹페이지를 만드려고 해."

프로젝트의 시작은 이 한 문장이었다. 거창한 기획서도, PRD도 없었다. 평소 타로에 관심이 있었고, 웹으로 만들면 재밌겠다는 생각이 전부였다. 보통이라면 여기서 구글링을 시작하거나, 노션에 기획을 정리하기 시작할 것이다. 하지만 이번엔 다르게 접근했다. Claude에게 바로 물었다.

이 선택이 프로젝트 전체의 성격을 결정지었다. AI와의 대화를 통해 아이디어를 구체화하는 과정 자체가 하나의 방법론이 되었기 때문이다.

첫 번째 질문: "카드 이미지는 몇 개야?"

프로젝트를 시작할 때 가장 먼저 한 일은 도메인 지식을 확인하는 것이었다. 타로카드가 총 몇 장인지, 어떤 구조인지 정확히 알아야 했다. Claude는 곧바로 핵심 구조를 정리해줬다.

타로 덱은 총 78장으로 구성된다. 메이저 아르카나 22장은 0번 The Fool부터 21번 The World까지이고, 마이너 아르카나 56장은 Wands, Cups, Swords, Pentacles 네 가지 슈트에 각각 14장(Ace부터 King까지)이 들어간다.

여기서 중요한 점은 이 정보를 단순히 "검색해서 알아낸" 것이 아니라는 것이다. AI와 대화하면서 자연스럽게 "그럼 이미지는 어디서 구하지?"로 흘러갔고, 저작권이라는 핵심 이슈까지 한 흐름 안에서 파악할 수 있었다. 구글링으로 이 흐름을 만들려면 탭을 열 개는 열어야 했을 것이다.

이름을 정하다: "타로 마스터"

프로젝트 이름은 의외로 빨리 정해졌다. "무난하게 타로 마스터로 할까?"라고 물었고, 깔끔하고 직관적이라는 피드백을 받았다.

사소한 것 같지만, 사이드 프로젝트에서 이름을 정하는 건 생각보다 중요하다. 이름이 정해지는 순간 프로젝트에 실체감이 생긴다. "그 프로젝트"에서 "타로 마스터"가 되는 것이다. 여기서 몇 시간을 고민하는 대신 AI와 빠르게 결정하고 넘어간 것은 좋은 선택이었다.

AI가 던진 세 가지 질문

이름이 정해지자마자 Claude가 구현 방향을 잡기 위한 질문 세 가지를 던져왔다.

첫째, 어떤 타로 리딩 방식을 지원할 것인가. 선택지는 원카드(오늘의 운세), 쓰리카드(과거/현재/미래), 켈틱 크로스(10장), 자유 선택(사용자가 장수 지정)이었다.

둘째, 카드 해석은 어떻게 제공할 것인가. 미리 작성된 고정 해석 텍스트, AI API 연동, 또는 둘 다 지원하는 방식 중 선택해야 했다.

셋째, 기술 스택 선호는 무엇인가. React + Vite, 순수 HTML/CSS/JS, Next.js 중 하나를 고르는 것이었다.

이 세 질문이 정말 핵심적이었던 이유가 있다. 개발자가 혼자 기획할 때는 "뭘 만들지"에 대한 답이 머릿속에서 뭉뚱그려진 채로 존재하기 쉽다. AI가 명시적으로 선택지를 제시하면, 그 모호함이 구체적인 의사결정으로 바뀐다. 이건 단순히 "AI가 대신 결정해주는 것"이 아니다. 개발자 자신이 원하는 것을 명확히 인식하게 만드는 과정이다.

나의 선택, 그리고 그 이유

원카드, 쓰리카드, 켈틱 크로스 세 가지를 선택했다. 자유 선택 모드는 뺐다. 타로에 익숙하지 않은 사용자에게 "몇 장을 볼까요?"는 오히려 혼란을 주기 때문이다. 전통적인 세 가지 방식이면 충분했다.

해석은 미리 작성된 고정 텍스트를 선택했다. AI API를 연동하면 더 풍부한 해석이 가능하지만, 두 가지 현실적 이유가 있었다. 하나는 API 비용이고, 다른 하나는 응답 지연 시간이다. 카드를 뒤집고 결과를 보는 순간의 즉각적인 경험이 타로의 핵심인데, API 호출로 2~3초 대기가 생기면 그 몰입감이 깨진다.

기술 스택은 React + Vite를 골랐다. 28년 경력 중 최근 몇 년간 React 기반 프로젝트를 주로 해왔고, Vite의 빠른 HMR은 프론트엔드 사이드 프로젝트에 최적이다. Next.js는 이 규모에 오버스펙이었고, 순수 HTML/JS는 상태 관리가 번거로웠을 것이다.

스펙이 확정되기까지 걸린 시간: 약 10분

아이디어 → 도메인 파악 → 이름 결정 → 기능 범위 → 기술 스택. 이 모든 과정이 Claude와의 대화 한 세션 안에서 끝났다. 체감상 10분 정도였다.

전통적인 방식이었다면 어땠을까. 타로카드 구조 리서치, 유사 서비스 벤치마킹, 기획서 초안, 기술 스택 검토... 최소 반나절은 걸렸을 것이다. 물론 그 과정에서 더 깊은 고민을 할 수도 있지만, 사이드 프로젝트에서 가장 위험한 것은 "시작하기 전에 지치는 것"이다.

AI와의 대화는 그 장벽을 낮춰줬다. 아이디어가 떠오른 그 순간의 에너지를 잃지 않고, 바로 구체적인 스펙으로 연결할 수 있었다.

이 과정에서 배운 것

첫째, AI에게 열린 질문을 던지면 생각보다 좋은 구조화가 돌아온다. "타로 웹페이지를 만들고 싶어"라는 모호한 입력이 리딩 방식, 해석 엔진, 기술 스택이라는 세 축의 의사결정으로 분해된 것이 대표적이다.

둘째, 선택지가 주어지면 자신의 판단 기준이 명확해진다. AI API 대신 고정 텍스트를 선택한 이유, 자유 선택 모드를 뺀 이유는 AI가 질문하지 않았다면 무의식적으로 넘어갔을 판단들이다.

셋째, 사이드 프로젝트는 속도가 생명이다. 완벽한 기획보다 빠른 시작이 중요하고, AI는 그 속도를 만들어주는 도구다.

다음 편 예고

스펙이 정해졌으니 이제 만들 차례다. 그런데 78장의 카드 각각에 정방향/역방향 해석 텍스트를 넣어야 한다. 156개의 해석 텍스트를 어떻게 설계하고 구조화했는지, 2편에서 이어진다.


이 글은 "AI 협업 개발기: 타로 마스터 프로젝트" 시리즈의 1편입니다.

반응형