10분 만에 스펙 정하기 — AI와의 의사결정 프레임워크

 

프로젝트 기획에서 가장 고통스러운 순간은 "선택"이다. 기술 스택을 뭘로 할지, 어떤 기능을 넣을지, 범위를 어디까지 잡을지. 선택지가 동시에 밀려오면 하나도 결정하지 못하는 상태에 빠지기 쉽다. 의사결정 마비다.

이 글은 AI가 던진 세 가지 질문으로 프로젝트의 전체 스펙이 10분 만에 확정된 이야기다. 핵심은 AI가 "대신 결정해준 것"이 아니라, 적절한 질문으로 내 안의 답을 끄집어낸 것이다.

모호함이라는 적

1편에서 Claude에게 "타로카드를 보는 웹페이지를 만드려고 해"라고 던졌고, 2편에서 타로 덱의 기본 구조와 저작권 이슈를 파악했다. 도메인 지식은 어느 정도 갖춰졌다. 이제 남은 것은 "구체적으로 뭘 만들 것인가"를 정하는 일이다.

문제는 이 단계에서 선택지가 갑자기 폭발한다는 것이다. 리딩 모드는 뭘 넣을까? 해석은 어떤 방식으로 제공할까? 기술 스택은? 배포는? 데이터베이스가 필요한가? PWA로 만들까? 이 질문들이 한꺼번에 머릿속에 쏟아지면, 아무것도 결정하지 못하고 "좀 더 생각해보자"는 결론에 도달한다. 사이드 프로젝트가 죽는 두 번째 시점이다.

AI와의 대화에서 인상적이었던 것은, 이 모든 질문을 한꺼번에 던지지 않았다는 것이다. Claude는 세 가지 핵심 축을 순서대로 제시했다.

첫 번째 질문: 어떤 리딩 방식을 지원할 것인가

첫 번째로 돌아온 질문은 리딩 방식이었다. 선택지는 네 가지였다. 원카드(오늘의 운세), 쓰리카드(과거/현재/미래), 켈틱 크로스(10장, 종합 분석), 자유 선택(사용자가 장수 지정).

이 질문이 첫 번째로 온 것은 논리적으로 맞다. 리딩 방식이 정해져야 UI 설계가 가능하고, 필요한 데이터의 형태가 결정되기 때문이다. 하지만 나 혼자 기획했다면 이 순서를 잡지 못했을 가능성이 높다. 아마 기술 스택부터 고민하거나, 전체 기능 목록부터 나열했을 것이다.

내 선택은 원카드, 쓰리카드, 켈틱 크로스 세 가지였다. 자유 선택 모드는 뺐다. 이유는 명확했다. 타로에 익숙하지 않은 사용자에게 "몇 장을 볼까요?"는 오히려 혼란을 준다. "고르세요"보다 "이 중에서 고르세요"가 사용자 경험에서 항상 낫다. 전통적이고 잘 알려진 세 가지 방식이면 충분했다.

여기서 흥미로운 점이 있다. 자유 선택 모드를 빼기로 한 이유는 AI가 선택지를 나열해줬기 때문에 비로소 명확해졌다는 것이다. 머릿속에서 "리딩 모드를 뭘로 하지?" 하고 막연하게 생각할 때는 이 판단이 어렵다. 하지만 네 가지가 눈앞에 나란히 놓이면, "이건 필요하고, 이건 아니야"라는 판단이 즉각적으로 된다. 선택지를 보여주는 것과 선택지를 떠올려야 하는 것의 인지 부하 차이다.

두 번째 질문: 카드 해석은 어떻게 제공할 것인가

두 번째 질문은 해석 엔진에 대한 것이었다. 선택지는 세 가지. 미리 작성된 고정 해석 텍스트, AI API 실시간 연동, 또는 둘 다 지원하는 하이브리드.

이 질문에서 나는 고정 텍스트를 선택했다. 두 가지 현실적 이유가 있었다.

하나는 API 비용이다. 사이드 프로젝트에서 매번 LLM API를 호출하면 사용량에 비례해 비용이 발생한다. 트래픽이 많아지면 부담이 된다. 사이드 프로젝트가 돈을 벌기 전에 돈을 쓰는 구조는 지속 가능하지 않다.

다른 하나는 응답 지연 시간이다. 카드를 뒤집고 결과를 보는 순간의 즉각적인 경험이 타로의 핵심이다. API 호출로 2~3초 대기가 생기면 그 몰입감이 깨진다. 타로 리딩에서 카드를 뒤집는 순간은 일종의 "의식(ritual)"인데, 로딩 스피너가 돌아가면 그 마법이 사라진다.

이 판단도 선택지가 제시되지 않았다면 달라졌을 것이다. "타로 앱 만들어야지"라고만 생각했다면, "당연히 AI가 해석해야 멋있지"라며 API 연동부터 시작했을 가능성이 높다. 그리고 비용과 지연 문제를 나중에 발견하고 설계를 뒤엎었을 것이다.

선택지가 나란히 놓이고, 각각의 트레이드오프를 의식적으로 비교하는 순간, 자신의 우선순위가 선명해진다. 이것이 AI와의 의사결정에서 가장 가치 있는 부분이었다.

세 번째 질문: 기술 스택 선호는 무엇인가

세 번째 질문은 기술 스택이었다. React + Vite, 순수 HTML/CSS/JS, Next.js 세 가지가 제시됐다.

이건 상대적으로 빨리 결정됐다. React + Vite를 골랐다. 경력의 대부분을 프론트엔드에 투자했고, 최근 몇 년간 React 기반 프로젝트를 주로 해왔기 때문이다.

각 선택지를 빠르게 검토한 과정은 이랬다. 순수 HTML/JS는 빠르게 시작할 수 있지만, 여러 리딩 모드의 상태 관리가 번거로워진다. 카드를 선택하고, 뒤집고, 결과를 보여주는 일련의 상태 전이를 순수 JS로 관리하면 코드가 복잡해진다. Next.js는 이 규모에 오버스펙이다. 서버 사이드 렌더링이 필요한 프로젝트가 아니고, 파일 기반 라우팅도 단일 페이지 앱에서는 장점이 아니다.

React + Vite의 조합은 사이드 프로젝트에 딱 맞았다. React의 컴포넌트 기반 구조로 UI를 깔끔하게 나눌 수 있고, Vite의 빠른 HMR(Hot Module Replacement)로 개발 중 피드백 루프가 짧다. 번들 크기도 Next.js보다 가볍다.

선택지가 판단 기준을 만든다

세 가지 질문에 답하는 과정에서 깨달은 것이 있다. AI가 선택지를 제시하는 것의 가치는 "고르기 쉬워서"가 아니라 "자신의 판단 기준이 드러나서"다.

고정 텍스트를 선택했을 때, 나는 "사용자 경험의 즉각성"과 "운영 비용의 최소화"를 내 프로젝트의 우선순위로 인식했다. 자유 선택 모드를 뺐을 때, "사용자 친화성"이 "기능의 풍부함"보다 중요하다는 판단을 내렸다. React + Vite를 골랐을 때, "익숙한 기술로 빠르게"가 "새로운 기술 학습"보다 우선이라는 것을 확인했다.

이런 판단 기준들은 AI가 질문하지 않았다면 무의식적으로 넘어갔을 것들이다. "왜 이걸 골랐어?"라고 스스로에게 물어볼 기회 자체가 없었을 것이다. 선택지를 보는 것, 그리고 그중에서 하나를 고르는 것, 그 과정 자체가 자신의 우선순위를 선명하게 만드는 도구다.

프로젝트 이름 결정: "타로 마스터"

세 가지 핵심 의사결정이 끝난 후, 자연스럽게 프로젝트 이름도 확정됐다. "무난하게 타로 마스터로 할까?"라고 물었고, 깔끔하고 직관적이라는 피드백을 받았다.

이름 결정에 5초도 안 걸렸다. 사이드 프로젝트에서 이름에 고민하는 시간은 거의 낭비라고 생각한다. 완벽한 이름을 고민하다 에너지를 쓰느니, 적당한 이름으로 빠르게 시작하는 것이 낫다. 이름은 언제든 바꿀 수 있지만, 시작의 에너지는 한 번 잃으면 돌아오지 않는다.

"타로 마스터"는 기능을 직관적으로 설명하고, 기억하기 쉽고, 한국어와 영어 모두에서 자연스럽다. 도메인을 잡든, 저장소 이름을 정하든 문제가 없다. 이 정도면 충분하다.

스펙 확정: 체감 10분

정리하면, 이 한 세션의 대화에서 확정된 것들은 다음과 같다.

리딩 모드: 원카드, 쓰리카드, 켈틱 크로스 세 가지. 해석 방식: 미리 작성된 고정 텍스트 (향후 AI API 확장 가능). 기술 스택: React + Vite + TypeScript. 프로젝트 이름: 타로 마스터. 데이터 범위: RWS 78장 전체, 정방향/역방향 해석 포함.

아이디어부터 이 스펙까지 도달하는 데 걸린 시간. 체감상 10분 정도였다.

전통적인 방식이었다면 어땠을까. 타로카드 구조 리서치에 반나절, 유사 서비스 벤치마킹에 반나절, 기획서 초안에 반나절, 기술 스택 검토에 또 반나절. 최소 이틀은 걸렸을 것이다. 물론 그 과정에서 더 깊은 고민을 할 수도 있다. 하지만 사이드 프로젝트에서 이틀은 치명적인 시간이다. 이틀 후에 당신의 열정이 지금과 같을 거라는 보장이 없기 때문이다.

빠른 결정의 위험과 안전장치

"10분 만에 정했다"고 하면, "너무 성급한 거 아닌가?"라는 의문이 들 수 있다. 합당한 우려다. 빠른 결정은 잘못된 결정을 내릴 위험이 있다.

하지만 사이드 프로젝트에서 잘못된 결정의 비용은 회사 프로젝트와 다르다. 기술 스택을 잘못 골라도, 이해관계자에게 보고할 필요 없이 그냥 바꾸면 된다. 기능 범위가 너무 넓어도, 줄이면 된다. 사이드 프로젝트의 특권은 "실패의 비용이 낮다"는 것이다.

오히려 "정하지 않는 것"의 비용이 더 크다. 스펙이 확정되지 않으면 아무것도 시작할 수 없고, 시작하지 않으면 프로젝트는 죽는다.

그래도 안전장치는 필요하다. 나의 안전장치는 두 가지였다. 첫째, 초기에 확정하는 것은 "핵심 축"만이고, 세부 사항은 만들면서 조정한다. 리딩 모드 세 가지는 확정하되, 각 모드의 세부 UX는 구현하면서 정한다. 둘째, "확장 가능한" 방향으로 결정한다. 고정 텍스트를 선택하되, 나중에 AI API를 추가할 수 있는 구조로 간다.

이 방식은 완벽하지 않지만, 사이드 프로젝트에서는 충분하다.

AI와의 의사결정에서 주의할 점

한 가지 분명히 해두고 싶은 것이 있다. AI가 선택지를 제시해준다고 해서, AI에게 결정을 맡겨서는 안 된다.

"React랑 Next.js 중에 뭐가 나아?" 같은 질문을 AI에게 던지면, 양쪽의 장단점을 균형 잡히게 설명해줄 것이다. 하지만 "내 프로젝트에 뭐가 맞아?"에 대한 답은 AI가 해줄 수 없다. 내 경험, 내 시간 제약, 내 우선순위를 종합한 판단은 내가 해야 한다.

AI의 가치는 "정답을 알려주는 것"이 아니라 "질문을 구조화해서 내가 판단하기 쉽게 만들어주는 것"이다. 이 차이를 인식하는 것이 AI 협업의 첫 번째 원칙이라고 생각한다.

이 과정에서 배운 것

첫째, 의사결정에서 가장 어려운 것은 "무엇을 결정해야 하는가"를 아는 것이다. AI는 이 부분을 탁월하게 도와준다. 모호한 아이디어를 의사결정 축으로 분해하고, 각 축에 대한 선택지를 제시해준다.

둘째, 선택지가 주어지면 자신의 판단 기준이 명확해진다. 머릿속에서 뭉뚱그려진 생각은 선택지 앞에서 구체적인 우선순위로 변한다. "왜 이걸 골랐는가"를 의식적으로 인식하게 된다.

셋째, 사이드 프로젝트에서 "빠른 결정 + 유연한 수정"은 "느린 결정 + 완벽한 계획"을 이긴다. 10분 만에 정한 스펙이 두 달 고민한 기획서보다 실행력에서 압도적으로 유리하다.

다음 편 예고

스펙이 정해졌다. 리딩 모드, 해석 방식, 기술 스택 모두 확정. 이제 코딩을 시작하고 싶은 유혹이 들지만, 한 가지 먼저 해야 할 일이 있다. 78장의 카드 데이터를 어떤 구조로 관리할 것인가. 코드보다 데이터가 먼저인 이유, 그리고 콘텐츠 중심 프로젝트의 설계 원칙을 4편에서 다룬다.