5편: 완성 그리고 회고 — 복잡한 도메인에서 AI 협업이 빛나는 순간

 

시리즈: AI 협업 개발기: 사주명리 프로젝트
키워드: AI 협업 방법론, 설계 문서 우선, 프로젝트 회고, 개발 프로세스, 인사이트

---

두 번째 프로젝트가 알려준 것

타로 마스터에 이어 사주명리 앱까지, 같은 AI 협업 방식으로 두 번째 프로젝트를 완성했다. 그런데 두 번째는 첫 번째와 확연히 다른 경험이었다.

타로 프로젝트는 "AI와 함께하면 이렇게 빨리 만들 수 있구나"라는 속도의 발견이었다. 사주 프로젝트는 "AI와 함께하면 이렇게 깊은 도메인도 다룰 수 있구나"라는 깊이의 발견이었다. 같은 도구를 썼지만 배운 것은 완전히 달랐다.

타임라인 회고: 어디에 시간이 걸렸나

각 단계에 투입된 시간의 분포가 인상적이다.

설계 문서 작성에 가장 집중적인 시간을 썼다. 네 개의 문서를 만드는 데 상당한 시간이 들었다. 하지만 이 시간은 구현 단계에서 몇 배로 돌아왔다. 도메인 모델 구축은 예상보다 빨랐다. 설계 문서에서 이미 TypeScript 타입까지 정의해두었기 때문에, 구현은 "문서를 코드로 옮기는 작업"에 가까웠다.

만세력과 계산 엔진은 예상대로 시간이 걸렸다. 절기 데이터 확보와 엣지 케이스(입춘 경계, 야자시, 서머타임) 처리에 투자한 시간은 "정확도"라는 앱의 핵심 가치를 만드는 것이므로 아깝지 않았다.

AI 해석 연동은 예상보다 빨랐다. 프롬프트가 설계 문서 단계에서 상당 부분 완성되어 있었고, 궁통보감 데이터를 참조로 넣는 순간 품질이 크게 올라서 반복 횟수가 줄었다.

가장 예상 밖이었던 것은 검증 단계다. 전문 앱들과 교차 검증하면서, 진태양시나 야자시 같은 설정 차이로 인한 결과 차이를 발견하고 대응하는 데 생각보다 시간이 필요했다. 정답이 여러 개인 도메인에서의 검증은 단순한 단위 테스트와는 성격이 다르다.

타로에서 사주로: AI 협업 방식의 진화

두 프로젝트를 비교하면, AI 협업 방식이 자연스럽게 진화했다.

타로 프로젝트에서는 "대화 → 코드 → 수정 → 반복"의 선형적 흐름이었다. 빠르고 직관적이지만, 프로젝트가 커지면 앞에서 한 대화의 맥락이 뒤에서 유실되는 문제가 있었다.

사주 프로젝트에서는 "설계 문서 → 컨텍스트 로드 → 구현 → 검증"의 구조화된 흐름이 됐다. docs/ 폴더가 AI에 대한 "영구적 컨텍스트"로 기능하면서, 대화의 맥락이 유실되지 않았다. @docs/02-DOMAIN-MODEL.md를 로드하고 "이 모델에 맞춰 십신 분석을 구현해줘"라고 하면, AI가 전체 맥락을 이해한 상태에서 코드를 작성한다.

이 차이는 프로젝트 규모가 커질수록 극적으로 벌어진다. 컴팩트한 프로젝트에서는 대화형으로도 충분하지만, 도메인이 깊고 모듈이 많은 프로젝트에서는 "문서 기반 컨텍스트"가 필수다.

AI가 잘한 것, 사람이 해야 했던 것

두 프로젝트를 거치면서 이 경계가 더 선명해졌다.

AI가 탁월했던 영역이 있다. 도메인 지식의 구조화에서 AI는 사주학의 복잡한 개념을 코드 데이터 구조로 변환하는 "번역가" 역할을 훌륭히 해냈다. 대량 데이터 테이블 생성에서도 60갑자, 지장간, 합충형파해 같은 방대한 테이블을 한 번에 정확하게 만들어줬다. 라이브러리 비교 분석에서는 각 패키지의 장단점을 표로 정리하고 조합 전략을 제안했다. 프롬프트 초안 작성과 반복 개선에서도 시스템 프롬프트의 구조와 제약 조건을 효과적으로 설계했다.

사람이 반드시 해야 했던 영역도 명확하다. 학파별 차이에서의 기본값 선정이 가장 대표적이다. AI는 "A 학파는 이렇고, B 학파는 이렇습니다"라고 정리할 수 있지만, "우리 앱은 이걸로 간다"는 결정은 내리지 못한다. 데이터 정확성의 최종 검증도 사람의 몫이었다. AI가 생성한 지장간 테이블이 실제로 맞는지, 만세력 사이트와 대조하는 것은 자동화할 수 없었다. UX의 미세 조정 — 여백, 색상 대비, 글꼴 크기의 위계 — 도 마찬가지다. 그리고 면책 조항의 내용, 운명론적 표현의 경계 같은 윤리적 결정은 AI에게 위임할 수 없는 영역이다.

특히 "학파별 차이에서의 선택"은 이 프로젝트에서 반복적으로 만난 패턴이었다. 음간 12운성의 순행/역행, 야자시 처리, 지장간 구성, 용신 판단법... 매번 AI는 선택지와 근거를 정리해줬지만, 어느 쪽을 채택할지는 "우리 앱의 사용자가 누구인가", "어느 기준이 더 보편적인가"라는 제품적 사고가 필요했다.

설계 문서 우선 개발: AI 시대의 핵심 역량

두 프로젝트를 통해 확신하게 된 것이 있다. AI 시대에 개발자의 핵심 역량은 "코드를 빨리 치는 것"이 아니라 "무엇을 만들 것인지를 명확하게 정의하는 것"이라는 점이다.

docs/를 먼저 만드는 접근법에는 세 가지 실질적 이점이 있다.

첫째는 사고의 구조화다. 복잡한 개념을 문서로 정리하는 과정 자체가 "내가 무엇을 이해하고 무엇을 모르는지"를 드러낸다. 코드를 치면서는 이 구분이 모호해지기 쉽다.

둘째는 AI 컨텍스트의 영속화다. 대화형 AI의 한계인 컨텍스트 윈도우 문제를 설계 문서가 해결한다. 새로운 대화를 시작할 때마다 @docs/를 로드하면 전체 맥락이 복원된다. 이것이 "AI와의 장기 프로젝트"를 가능하게 하는 핵심 기법이다.

셋째는 팀 확장의 기반이다. 혼자 하는 사이드 프로젝트라도, 설계 문서가 있으면 나중에 다른 사람이나 다른 AI가 합류할 때 온보딩이 극적으로 빨라진다.

AI 협업 방법론 6가지: 두 프로젝트의 종합

타로와 사주 두 프로젝트를 거치면서 정리된 실전 방법론이 있다.

첫째, 도메인 탐색은 AI와의 대화로 빠르게 시작하라. "무엇을 만들지"에 대한 아이디어가 있을 때, 구글링이나 기획서 대신 AI에게 바로 물어보는 것이 가장 빠른 시작점이다. AI가 던지는 질문이 기획의 프레임이 된다.

둘째, 복잡한 도메인에서는 설계 문서를 코드보다 먼저 만들라. 도메인이 단순하면 바로 코드를 쳐도 된다. 하지만 전문 지식이 필요한 영역에서는 "무엇을 코드로 옮길 것인가"를 먼저 정리하는 것이 필수다.

셋째, AI에게 맥락을 주는 데 투자하라. "천간 데이터를 만들어줘"보다 설계 문서를 로드하고 "이 모델에 맞춰 구현해줘"가 훨씬 좋은 결과를 낸다. 프롬프트에서도 "잘 해석해줘"보다 궁통보감 데이터를 참조로 제공하는 것이 극적으로 효과적이다. AI의 출력 품질은 입력의 맥락 품질에 비례한다.

넷째, "계산 가능한 것"과 "판단이 필요한 것"을 구분하라. 사주에서 십신 판정은 계산이고, 용신의 의미 해석은 판단이다. 계산은 코드로, 판단은 AI로. 이 분리가 정확도와 자연스러움을 동시에 확보하는 열쇠다.

다섯째, 기존 서비스 벤치마킹을 과소평가하지 말라. 전문 앱들의 결과 차이를 분석하면서 데이터 소스, 보정 로직, 학파 차이라는 핵심 설계 포인트를 발견했다. "만들기 전에 쓰기"가 주는 인사이트는 기획서로는 얻을 수 없다.

여섯째, 정답이 여러 개인 도메인에서는 "기본값 + 유연한 구조"가 핵심이다. 야자시 처리, 음간 12운성, 학파별 지장간 — 하나만 맞다고 하드코딩하면 사용자의 절반을 잃는다. 합리적 기본값을 설정하되, 다른 해석을 허용하는 구조를 만들어야 한다.

숫자로 보는 프로젝트

설계 문서 5개, 총 100페이지 이상. 도메인 데이터 테이블 20종 이상(천간, 지지, 60갑자, 오행, 십신, 지장간, 12운성, 합충형파해 등). 절기 데이터 130년분(1920~2050). 서머타임 보정 12개 기간. 주요 도시 경도 테이블. AI 해석 카테고리 7종. 궁통보감 120조합 참조 데이터.

타로 프로젝트가 78장 카드 × 2방향 = 156개 해석 텍스트였던 것과 비교하면, 데이터의 깊이와 복잡도 차이가 확연하다. 하지만 AI 협업 덕분에 이 복잡도가 "불가능"에서 "도전적이지만 가능"으로 바뀌었다.

앞으로 남은 것들

프로젝트가 "완성"되었지만 확장할 수 있는 방향은 많다. 대운(大運)과 세운(歲運) 분석은 10년 단위, 매년 단위의 운세를 보는 것으로, 사주 상담에서 가장 많이 묻는 주제다. 궁합 분석은 두 사주 간의 상성을 보는 것으로, 자연스러운 다음 기능이다. 신살 분석의 확장(현재 기본 22종 → 50종 이상), PDF 리포트 생성, 다국어 지원도 고려하고 있다.

더 흥미로운 방향은 "학파 선택" 기능이다. 앱 설정에서 용신 판단법(억부법/조후법), 12운성 음간 순역, 야자시 처리 방식을 선택할 수 있게 하면, 같은 사주라도 다른 관점에서 해석을 비교해볼 수 있다. 이것은 단순한 사주 앱이 아니라 "명리학 학습 도구"로의 확장 가능성을 열어준다.

마치며: AI는 도구가 아니라 협업자다

두 프로젝트를 마치고 나서 가장 크게 바뀐 인식이 있다. AI를 "코딩 도구"로 보는 시각에서 "프로젝트 협업자"로 보는 시각으로의 전환이다.

도구라면 "이걸 코드로 짜줘"라고 시키면 끝이다. 협업자라면 "이 도메인을 함께 탐색하자", "이 설계에 빈 곳이 있나?", "이 해석이 자연스러운가?"라고 대화한다. 타로에서는 도구에 가까웠고, 사주에서는 협업자에 가까웠다.

프로젝트의 복잡도가 올라갈수록, AI를 협업자로 대하는 접근이 더 효과적이다. 그리고 그 협업의 질은, 개발자가 "무엇을 만들 것인가"를 얼마나 명확하게 정의할 수 있느냐에 달려 있다. 설계 문서를 쓰는 능력, 도메인을 구조화하는 능력, 적절한 기본값을 선택하는 능력. 이것이 AI 시대 개발자의 진짜 역량이다.

28년간 코드를 작성해왔다. 그중 최근 몇 년은 AI와 함께 코드를 작성했다. 돌이켜보면, AI가 가장 크게 바꾼 것은 코딩 속도가 아니라 "혼자서는 도전하지 못했을 프로젝트에 도전할 수 있게 된 것"이다. 사주명리학이라는, 평소라면 엄두도 내지 못했을 깊은 도메인을 웹 앱으로 구현한 이 경험이 그 증거다.

---

이 글은 "AI 협업 개발기: 사주명리 프로젝트" 시리즈의 5편이자 마지막 편입니다.

타로 마스터 시리즈도 함께 읽어보시면, AI 협업 방법론이 프로젝트 간에 어떻게 진화하는지를 더 넓은 시각에서 파악할 수 있습니다.