시작의 충동 — "타로 웹앱을 만들어볼까?"

사이드 프로젝트는 대부분 기획서 작성 단계에서 죽는다. 당신도 경험이 있을 것이다. 번뜩이는 아이디어가 떠올라 노션을 열었다가, 기획을 정리하다 에너지를 다 써버리고, 결국 "나중에 해야지" 폴더에 묻히는 그 패턴 말이다.

이 글은 그 패턴을 깬 이야기다. AI에게 한 문장을 던지고, 10분 만에 프로젝트가 구체화된 경험에 대한 이야기다.

한 문장에서 시작된 프로젝트

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

프로젝트의 시작은 이 한 문장이었다. 거창한 기획서도, PRD도, 경쟁사 분석도 없었다. 평소 타로에 관심이 있었고, 웹으로 만들면 재밌겠다는 생각이 전부였다. 구체적인 기능 목록도 없었고, 어떤 기술 스택을 쓸지도 정하지 않았다.

보통이라면 여기서 두 가지 중 하나가 벌어진다. 구글링을 시작해서 "타로 웹앱 만들기"를 검색하거나, 노션에 기획 문서를 만들고 목차부터 쓰기 시작하는 것이다. 두 방법 모두 나쁘지 않지만, 공통적인 위험이 있다. 실행에 들어가기 전에 에너지가 소진된다는 것이다.

이번에는 다르게 접근했다. Claude에게 바로 물었다. 이 선택 하나가 프로젝트 전체의 성격을 결정지었다.

왜 기획 단계에서 프로젝트가 죽는가

잠깐 이야기를 돌려서, 사이드 프로젝트가 왜 기획 단계에서 사라지는지 생각해보자. 내 경험상 이유는 세 가지다.

첫째, 완벽주의의 함정이다. "제대로 시작하려면 제대로 기획해야지"라는 생각이 들면, 기획서의 목차를 쓰고, 벤치마킹할 서비스를 찾고, 기능 목록을 정리하기 시작한다. 그러다 보면 만들어야 할 것이 점점 커지고, "이건 주말에 할 수 있는 규모가 아닌데"라는 결론에 도달한다.

둘째, 도메인 지식의 벽이다. 타로 웹앱을 만들려면 타로에 대해 알아야 한다. 카드가 몇 장인지, 어떤 종류가 있는지, 리딩은 어떻게 하는지. 이걸 알아보려고 검색을 시작하면 탭이 열 개, 스무 개 쌓인다. 정보는 많은데 "내 프로젝트에 필요한 수준"의 정리가 안 된다.

셋째, 의사결정의 마비다. 기술 스택을 뭘로 할지, 데이터베이스가 필요한지, 배포는 어디로 할지. 선택해야 할 것들이 동시에 밀려오면, 어떤 것부터 정해야 할지 모르겠어서 멈춘다.

AI가 이 세 가지를 모두 낮춰줄 수 있다는 걸, 나는 이 프로젝트를 통해 알게 됐다.

AI에게 아이디어를 던지면 벌어지는 일

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

이 한 문장을 Claude에게 던졌을 때, 나는 "그래서 뭘 만들고 싶은데?"라는 되물음을 예상했다. 실제로 돌아온 반응은 더 구조적이었다. Claude는 이 모호한 아이디어를 즉시 몇 가지 축으로 분해하기 시작했다.

어떤 타로 덱을 기반으로 할 것인가. 어떤 리딩 방식을 지원할 것인가. 카드 해석은 어떻게 제공할 것인가. 카드 이미지는 어디서 가져올 것인가.

이게 AI와의 대화가 가진 첫 번째 장점이다. 모호한 아이디어를 의사결정 축으로 분해해준다. 혼자 기획할 때는 "뭘 만들지"에 대한 답이 머릿속에서 뭉뚱그려진 채 존재하기 쉽다. AI가 명시적으로 질문을 던지면, 그 모호함이 구체적인 선택지로 바뀐다.

중요한 건 이게 "AI가 대신 결정해주는 것"이 아니라는 점이다. AI는 질문을 던질 뿐이고, 결정은 내가 한다. 하지만 "무엇을 결정해야 하는가"를 정리해주는 것만으로도 의사결정의 속도가 완전히 달라진다.

"완벽한 기획" 없이 시작하는 용기

정직하게 말하면, AI에게 한 문장을 던진 것은 전략적 판단이 아니라 그냥 편하니까였다. 기획서를 쓰기 귀찮았고, 그냥 대화하면서 정리하고 싶었다.

그런데 결과적으로 이 접근이 사이드 프로젝트에 완벽하게 맞는 방법론이었다. 사이드 프로젝트는 회사 프로젝트가 아니다. 이해관계자에게 보여줄 기획서가 필요 없고, 일정 산정도 필요 없다. 필요한 건 "무엇을 만들 것인가"에 대한 최소한의 합의뿐인데, 그 합의의 상대가 나 자신이니까 대화 한 번이면 충분한 것이다.

AI와의 대화는 그 "나 자신과의 합의"를 빠르게 만들어주는 도구였다. 머릿속에서 모호하게 떠도는 아이디어를 밖으로 꺼내고, 질문에 답하면서 구체화하는 과정이다. 마치 동료 개발자와 커피를 마시며 "이런 거 만들면 재밌지 않을까?" 하고 이야기하는 것과 비슷했다. 다만, 이 동료는 타로에 대해서도, 웹 개발에 대해서도, 디자인에 대해서도 두루 알고 있다는 차이가 있을 뿐이다.

아이디어의 에너지를 놓치지 않는 것

사이드 프로젝트에서 가장 중요한 자원은 시간이 아니다. 동기 부여, 즉 에너지다. "이거 만들면 재밌겠다"는 순간의 흥분. 이 에너지는 시간이 지나면 빠르게 식는다.

기획서를 쓰고, 벤치마킹을 하고, 기술 스택을 검토하는 전통적인 과정은 이 에너지를 조금씩 갉아먹는다. 이틀 후에 "아, 그 타로 프로젝트"를 다시 열면 처음의 흥분은 절반으로 줄어 있다. 일주일 후에는 "그거 좀 과한 프로젝트 아니었나" 하는 의심이 든다.

AI와의 대화가 이 문제를 해결한 방식은 단순하다. 아이디어가 떠오른 그 순간의 에너지를 잃지 않고, 바로 구체적인 형태로 연결해준 것이다. 한 문장을 던진 지 10분 후, 나는 이미 "78장의 타로카드, 원카드/쓰리카드/켈틱크로스 리딩 모드, 고정 해석 텍스트, React + Vite"라는 명확한 스펙을 가지고 있었다. 이 시점에서 프로젝트는 이미 "살아있는 것"이 됐다.

이 과정에서 나는 한 가지를 깨달았다. 사이드 프로젝트에서 진짜 중요한 건 "얼마나 잘 기획하느냐"가 아니라 "얼마나 빨리 손을 대느냐"다. 완벽한 기획은 필요 없다. 방향만 잡히면 된다. 나머지는 만들면서 조정하면 된다.

프로젝트에 이름을 붙이다

대화 흐름 속에서 자연스럽게 프로젝트 이름도 정해졌다. "무난하게 타로 마스터로 할까?"라고 물었고, 깔끔하고 직관적이라는 피드백을 받았다.

사소한 것 같지만, 사이드 프로젝트에서 이름을 정하는 건 생각보다 중요하다. 이름이 정해지는 순간 프로젝트에 실체감이 생긴다. "그 프로젝트"에서 "타로 마스터"가 되는 것이다. 폴더 이름이 정해지고, 대화에서 고유명사로 불리기 시작하면 프로젝트가 "진짜"가 된다.

여기서도 AI 협업의 장점이 드러났다. 이름 짓기에 몇 시간을 고민하는 대신, 빠르게 결정하고 넘어간 것이다. 이름이 마음에 안 들면 나중에 바꾸면 된다. 사이드 프로젝트에서 이름은 시작의 신호탄이지, 최종 결정이 아니다.

지금 이 순간을 시작으로

돌이켜보면, 이 프로젝트의 가장 중요한 순간은 코드를 처음 쓴 순간도, 배포를 완료한 순간도 아니었다. Claude에게 "타로카드를 보는 웹페이지를 만드려고 해"라고 한 문장을 던진 그 순간이었다. 그 순간 프로젝트가 시작됐고, 한 번 굴러간 바퀴는 멈추지 않았다.

당신에게도 머릿속에서 떠도는 아이디어가 있을 것이다. "이런 거 만들면 재밌을 텐데." 그 아이디어를 기획서에 옮기지 마라. AI에게 한 문장으로 던져보라. 10분 후에 어떤 일이 벌어지는지 직접 경험하게 될 것이다.

이 과정에서 배운 것

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

둘째, 사이드 프로젝트에서 가장 위험한 것은 "시작하기 전에 지치는 것"이다. 완벽한 기획보다 빠른 시작이 중요하고, AI는 그 속도를 만들어주는 도구다.

셋째, 아이디어의 에너지는 유통기한이 있다. 떠오른 순간에 잡지 않으면 사라진다. AI와의 대화는 그 에너지를 구체적인 형태로 즉시 변환해주는 가장 빠른 도구다.

다음 편 예고

프로젝트를 시작하기로 했다. 그런데 타로에 대해 아는 게 거의 없다. 카드가 몇 장인지도 정확히 몰랐고, 메이저 아르카나니 마이너 아르카나니 하는 용어도 낯설었다. 모르는 분야에 뛰어들 때 AI를 어떻게 활용했는지, 구글링과 AI 대화의 학습 효율이 얼마나 다른지, 2편에서 이어진다.