5편: 완성 그리고 회고 — AI 협업 개발에서 배운 것들

 

시리즈: AI 협업 개발기: 타로 마스터 프로젝트
키워드: AI 개발 방법론, 회고, 바이브 코딩, 개발자의 역할, 사이드 프로젝트

---

완성된 타로 마스터

프로젝트가 완성됐다. 최종 결과물을 정리하면 이렇다.

78장의 RWS 타로카드 전체를 지원하며, 원카드, 쓰리카드, 켈틱 크로스 세 가지 리딩 모드를 제공한다. 각 카드에 정방향과 역방향 한국어 해석이 포함되어 있고, 별이 흐르는 다크 테마 배경 위에서 3D 카드 뒤집기 애니메이션이 동작한다. React + Vite SPA로 구축했고, 퍼블릭 도메인 이미지를 사용해 저작권 문제가 없다.

기능 목록으로 보면 평범해 보일 수 있다. 하지만 이 프로젝트의 진짜 가치는 결과물 자체보다 만드는 과정에 있었다.

전체 타임라인

프로젝트의 전체 진행을 돌아보면 재미있는 패턴이 보인다.

기획과 스펙 정의에 약 10분이 걸렸다. Claude와의 대화 한 세션으로 아이디어부터 기술 스택까지 확정했다. 데이터 설계와 해석 텍스트 생성은 가장 오래 걸린 부분이었다. 78장의 구조 설계, 텍스트 생성, 품질 검증까지 상당한 시간이 소요됐다. UI 구현은 데이터가 확정된 후 비교적 빠르게 진행됐다. 이미지 소싱과 디버깅은 예상보다 오래 걸린 작업이었다.

전통적인 개발 프로세스였다면 기획서 작성에 반나절, 디자인 시안에 이틀, 구현에 일주일은 걸렸을 것이다. AI 협업으로 전체 사이클이 크게 압축됐다.

AI가 잘한 것

이 프로젝트에서 AI가 특히 잘한 영역들이 있었다.

첫째, 도메인 지식의 빠른 전달이다. 타로카드의 구조(78장, 메이저/마이너 아르카나), 저작권 상태(1909년 원본 vs 1971년 재색칠), 전통적인 리딩 방식(원카드, 쓰리카드, 켈틱 크로스)에 대한 정보를 대화 흐름 안에서 자연스럽게 얻을 수 있었다. 별도의 리서치 시간이 거의 필요 없었다.

둘째, 대량 콘텐츠의 구조화된 생성이다. 156개의 해석 텍스트를 프레임워크(슈트별 주제, 번호별 서사, 톤 가이드라인)에 맞춰 일관성 있게 생성한 것은 AI의 가장 큰 기여였다. 사람이 이걸 직접 쓰려면 타로 전문가의 도움이 필요했거나, 기존 해석서를 참고하는 방대한 작업이 됐을 것이다.

셋째, UI 구현의 가속이다. "별이 흐르는 배경"이라는 추상적 요구를 CSS 라디얼 그라데이션 코드로 변환하거나, 켈틱 크로스의 전통적 배치를 CSS Grid로 구현하는 것은 AI가 빠르게 처리한 영역이다. 특히 세밀한 CSS 값(색상 코드, 투명도, 애니메이션 커브 등)의 미세 조정은 AI와의 반복적 대화로 효율적으로 진행됐다.

넷째, 문제 해결의 다각적 접근이다. 이미지 URL이 깨졌을 때 Wikimedia → Internet Archive → GitHub 호스팅 → Azure Blob Storage까지 여러 대안을 순차적으로 탐색한 과정은 AI의 폭넓은 지식 기반이 빛난 순간이었다.

AI가 못한 것, 그리고 사람이 해야 했던 것

동시에 AI의 한계도 명확했다.

첫째, 최종 판단은 항상 사람의 몫이었다. AI API 대신 고정 텍스트를 선택한 것, 자유 선택 모드를 제외한 것, 역방향 해석의 철학을 정한 것은 모두 개발자의 판단이었다. AI는 선택지를 제시할 수 있지만 "이 프로젝트에서 뭐가 더 적합한가"는 프로젝트의 맥락과 사용자에 대한 이해가 있는 사람만 결정할 수 있다.

둘째, 감각적 품질 검증은 사람이 해야 한다. 해석 텍스트가 "자연스러운 한국어인가", 카드 뒤집기 속도가 "기분 좋은가", 색상 조합이 "분위기에 맞는가" 같은 감각적 판단은 AI가 제안할 수는 있지만 최종 확인은 눈과 직감으로 해야 했다.

셋째, 실제 환경에서의 테스트는 AI의 영역 밖이다. 이미지 URL이 실제로 작동하는지, 모바일에서 레이아웃이 깨지는지, 브라우저 호환성에 문제가 없는지는 결국 사람이 직접 확인해야 한다. Claude가 네트워크 제한으로 URL을 검증하지 못했던 것이 대표적 사례다.

넷째, 프로젝트의 "왜"는 사람에게서 나온다. "타로 웹앱을 만들자"는 동기, "신비로운 분위기가 중요하다"는 방향성, "사이드 프로젝트니까 과도한 인프라는 피하자"는 판단 기준은 모두 사람이 가져온 것이다. AI는 "어떻게"를 잘 풀어주지만 "왜"를 만들어주진 않는다.

"바이브 코딩"의 함정과 올바른 접근

이 프로젝트를 진행하면서 요즘 유행하는 "바이브 코딩(Vibe Coding)"에 대해서도 생각해봤다.

바이브 코딩은 간단히 말해 "AI에게 코드를 쓰게 하고, 분위기(vibe)만 확인하면서 개발하는 것"이다. 빠르고 편하지만 위험하다. AI가 생성한 코드가 왜 그렇게 작성됐는지 이해하지 못하면, 문제가 생겼을 때 디버깅할 수 없다.

타로 마스터 프로젝트에서 나는 바이브 코딩이 아니라 "의도 기반 협업"을 했다. 차이는 이렇다. 바이브 코딩은 "타로 앱 만들어줘"이고, 의도 기반 협업은 "78장 카드의 데이터 스키마를 이렇게 정의하고, 정방향/역방향에 각각 키워드와 해석을 넣어줘"이다.

전자는 AI에게 전체를 위임하는 것이고, 후자는 내가 구조를 설계하고 AI에게 실행을 맡기는 것이다. 결과물만 보면 비슷해 보일 수 있지만, 두 가지 결정적 차이가 있다. 첫째, 문제가 생겼을 때 어디를 봐야 하는지 안다. 둘째, 프로젝트를 확장하거나 수정할 때 스스로 방향을 잡을 수 있다.

AI 협업 개발의 방법론 정리

이 프로젝트를 통해 정립한 AI 협업 방법론을 정리하면 다섯 가지로 요약된다.

첫째, "무엇을 만들 것인가"는 AI와 대화로 빠르게 정한다. 열린 질문으로 시작하면 AI가 의사결정 축을 구조화해준다. 선택지가 주어지면 자신의 기준이 명확해진다. 기획에 시간을 과하게 쓰는 것보다 빠르게 정하고 시작하는 것이 사이드 프로젝트의 핵심이다.

둘째, 데이터와 구조는 코드보다 먼저 확정한다. AI에게 코드를 바로 요청하기보다 데이터 스키마, 정보 구조, 사용자 흐름을 먼저 정의한다. 이게 확정되면 코드는 자연스럽게 따라온다.

셋째, AI에게 맥락을 충분히 준다. "해석 텍스트를 만들어줘"보다 "슈트별 주제가 이렇고, 번호별 서사 흐름이 이렇고, 톤은 이런 식으로"라고 프레임워크를 먼저 설명하면 결과물의 일관성과 품질이 크게 올라간다.

넷째, AI의 출력은 반드시 검증한다. 해석 텍스트의 정확성, 이미지 URL의 유효성, 생성된 코드의 동작 여부는 사람이 확인해야 한다. AI는 "그럴듯한 것"을 잘 만들지만 "정확한 것"은 보장하지 않는다.

다섯째, AI가 못하는 영역을 인지하고 사람이 채운다. 감각적 판단, 환경 테스트, 프로젝트의 방향성은 개발자의 고유 역할이다.

사이드 프로젝트의 관점에서

타로 마스터는 사이드 프로젝트다. 완벽할 필요는 없고, 누군가의 기대를 충족시켜야 할 의무도 없다. 그래서 더 자유롭게 AI 협업을 실험할 수 있었다.

사이드 프로젝트에서 AI 협업의 가장 큰 장점은 "시작의 마찰을 줄여준다"는 것이다. 아이디어가 떠올랐을 때 10분 만에 스펙이 정해지고, 바로 구현에 들어갈 수 있다. 많은 사이드 프로젝트가 기획 단계에서 에너지를 소진하고 사라지는 걸 생각하면 이 속도감은 결정적이다.

동시에 한 가지 주의점이 있다. AI가 빠르게 만들어주니까 "일단 만들고 나중에 고치자"는 접근이 되기 쉽다. 데이터 구조를 대충 잡고 코드를 먼저 쓰거나, 검증 없이 AI 출력을 그대로 사용하는 식이다. 속도와 품질의 균형을 의식적으로 유지하는 것이 중요하다.

타로 마스터, 그 이후

프로젝트는 완성됐지만 끝이 아니다. 몇 가지 확장 가능성이 있다.

첫째, AI API 연동. 현재의 고정 텍스트 해석에 더해, 사용자의 질문에 맞춤형 해석을 제공하는 AI 모드를 추가할 수 있다. 1편에서 API 비용과 응답 지연 문제로 보류했지만, 고급 모드로 제공하면 흥미로울 것이다.

둘째, 리딩 히스토리. 과거 리딩 결과를 저장하고 패턴을 분석하는 기능이다. localStorage로 간단히 구현할 수 있지만, 사용자 경험적으로 "내 타로 일지" 같은 가치를 만들 수 있다.

셋째, 더 많은 리딩 방식. 자유 선택 모드, 연애 운세 전용 스프레드, 예/아니오 리딩 같은 변형을 추가할 수 있다.

이 확장들은 현재 프로젝트의 구조(데이터 스키마, 컴포넌트 분리, 모드 시스템)가 잘 설계되어 있기 때문에 비교적 쉽게 추가할 수 있다. 처음에 데이터 구조를 신중하게 설계한 것이 여기서 보상받는 셈이다.

마치며

"AI와 함께 개발한다"는 말이 갈수록 흔해지고 있다. 하지만 그 구체적인 모습은 사람마다, 프로젝트마다 다르다. 타로 마스터 프로젝트를 통해 경험한 AI 협업은 "AI가 대신 만들어주는 것"이 아니라 "AI와 대화하며 함께 만들어가는 것"이었다.

아이디어를 구조화할 때, 대량의 콘텐츠를 생성할 때, 디자인을 코드로 변환할 때, 문제를 디버깅할 때 — 각 단계에서 AI의 역할과 사람의 역할은 달랐다. 그 경계를 인식하고 활용하는 것이 AI 시대 개발자의 핵심 역량이 아닐까 생각한다.

---

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

전체 시리즈: [1편: 아이디어에서 스펙까지] → [2편: 78장의 데이터를 설계하다] → [3편: 신비로운 UI를 코드로] → [4편: 이미지 소싱의 현실] → [5편: 완성 그리고 회고]