회고 — 타로에서 사주로, AI 협업의 진화

 

두 개의 프로젝트가 끝났다. 타로 마스터 20편, 사주명리 20편. 총 40편의 개발기를 쓰는 동안 AI와의 협업 방식은 계속 진화했다. 처음에는 "이게 되네?"라는 놀라움이었고, 끝에서는 "이것 없이 어떻게 했지?"라는 자연스러움이 됐다. 시리즈의 마지막 편에서 그 여정을 되돌아본다.

타로 — 속도의 발견

타로 프로젝트에서 발견한 것은 "속도"였다. AI와 함께하면 코드를 얼마나 빨리 짤 수 있는지. 78장의 카드 데이터를 수작업으로 입력하면 며칠이 걸릴 것을 AI가 몇 시간 만에 생성해줬다. 리딩 로직, UI 컴포넌트, 상태 관리 — 전통적으로 2~3주가 걸릴 기능들이 며칠 만에 동작했다.

타로에서의 AI 협업은 일종의 "터보 부스터"였다. 내가 할 줄 아는 것을 더 빠르게 해주는 도구. 기존 개발 방식의 연장선에서, 속도만 극적으로 빨라진 느낌이었다.

이 단계에서의 핵심 발견은 "AI가 반복적인 작업에서 압도적으로 효율적이다"라는 것이었다. 78장 카드 데이터 같은 대량 생성 작업, 비슷한 패턴의 컴포넌트를 여러 개 만드는 작업, 라이브러리 설정이나 보일러플레이트 코드 작성 같은 것들.

사주 — 깊이의 발견

사주 프로젝트에서 발견한 것은 "깊이"였다. AI와 함께하면 혼자서는 접근하기 어려운 도메인의 깊은 곳까지 도달할 수 있다는 것.

사주명리는 타로와 차원이 다른 도메인이었다. 수천 년의 역사, 다양한 학파, 복잡한 관계 체계. 이 도메인에 혼자 뛰어들었다면 도메인 학습에만 몇 달이 걸렸을 것이다. AI와 함께하니 도메인의 지형도를 10분 만에 그리고, 각 요소의 깊은 규칙을 구현하면서 동시에 학습할 수 있었다.

사주에서의 AI 협업은 "터보 부스터"를 넘어 "탐험 파트너"였다. 낯선 영역을 함께 탐색하는 동반자. 속도뿐 아니라 도달 가능한 깊이 자체가 달라졌다.

같은 도구인데 다른 배움을 얻은 이유는 프로젝트의 성격 차이 때문이다. 타로는 내가 이미 아는 영역(웹 개발)에서 AI가 속도를 높여준 것이고, 사주는 내가 모르는 영역(명리학)에서 AI가 가이드 역할을 한 것이다. AI 협업의 진짜 가치는 후자에서 더 크게 드러난다.

AI가 잘한 것 5가지

두 프로젝트를 거치면서 AI가 특히 잘한 영역을 다섯 가지로 정리한다.

첫째, 도메인 구조화. 사주명리라는 방대한 도메인의 전체 지형도를 빠르게 그려주고, 각 요소 간의 관계를 구조적으로 정리해줬다. "천간지지는 이렇고, 오행은 이렇게 연결되고, 십신은 이 관계에서 나온다." 이런 도메인 맵핑 작업에서 AI의 효율은 압도적이었다.

둘째, 대량 테이블 생성. 60갑자 테이블, 십신 관계표, 납음오행표, 12운성표, 토정비결 144괘 해석 — 이런 대량의 구조화된 데이터 생성에서 AI의 속도는 사람이 따라갈 수 없는 수준이었다. 물론 생성 후 검증은 반드시 필요하지만, 초안 생성 자체의 속도가 프로젝트 전체 일정을 크게 앞당겼다.

셋째, 라이브러리 비교와 기술 선택. korean-lunar-calendar를 선택할 때, 여러 음력 변환 라이브러리의 장단점을 빠르게 비교해줬다. PWA 설정, PDF 생성(jspdf+html2canvas), 상태 관리(Zustand) 등 기술 스택 결정에서도 각 선택지의 트레이드오프를 정리해주는 역할이 유용했다.

넷째, 프롬프트 설계. AI 해석 레이어에서 사주 분석 결과를 자연어로 풀어내는 프롬프트를 함께 설계했다. "이 사주 데이터를 받아서 어떤 구조의 해석 텍스트를 생성할 것인가"라는 메타 수준의 프롬프트 설계에서 AI가 제안한 구조가 여러 차례 채택됐다.

다섯째, 코드 번역. React 컴포넌트 구조 변환, TypeScript 타입 정의, 기존 코드의 리팩토링 등 "이미 있는 것을 다른 형태로 바꾸는" 작업에서 AI가 정확하고 빨랐다. 특히 설계 문서에서 코드로의 번역, 코드에서 테스트로의 번역 같은 "번역" 성격의 작업에서 강점을 보였다.

사람이 해야 했던 것 4가지

반대로, AI에게 맡길 수 없어서 사람이 직접 판단하고 결정해야 했던 영역도 있다.

첫째, 학파 선택. 야자시를 적용할 것인가, 진태양시를 적용할 것인가. 이것은 기술적 결정이 아니라 도메인 전문가의 판단이다. AI에게 물으면 양쪽의 근거를 다 설명해주지만, 최종적으로 기본값을 어디에 놓을 것인가는 사람이 결정해야 했다. 우리 프로젝트에서는 "사용자가 선택하게 하자"는 제3의 길을 택했는데, 이 결정 자체도 사람의 판단이었다.

둘째, 데이터의 최종 검증. AI가 생성한 60갑자 테이블, 십신 관계표 등은 대부분 정확했지만 100%는 아니었다. 미묘한 오류가 섞여 있는 경우가 있었고, 이를 발견하려면 도메인 지식을 가진 사람이 꼼꼼히 검수해야 했다. 특히 학파별로 다른 규칙이 있는 부분에서 AI가 학파를 혼합해 잘못된 데이터를 생성하는 경우가 몇 차례 있었다.

셋째, UX의 미세 조정. 학파 설정 배지를 어디에 배치할 것인가, 오행 테스트의 문항 순서를 어떻게 할 것인가, 결과 화면에서 어떤 정보를 먼저 보여줄 것인가. 이런 UX 판단은 사용자의 감정과 행동을 이해하는 감각이 필요하고, 이 감각은 AI보다 사람이 낫다.

넷째, 윤리적 결정. MBTI-일간 매칭에 "과학적 근거 없음" 경고를 넣을 것인가, 일일 운세에 "오늘 조심하세요" 같은 부정적 메시지를 어느 수준까지 허용할 것인가, 유명인 사주 분석에서 살아있는 인물의 부정적 해석을 어떻게 처리할 것인가. 이런 윤리적 판단은 AI가 제안할 수는 있지만 최종 결정은 사람의 몫이다.

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

40편의 개발기를 통해 축적된 AI 협업 방법론을 6가지로 종합한다.

1번, 도메인 지형도를 먼저 그려라. 프로젝트 시작 시 AI에게 도메인의 전체 구조를 요청한다. 요소 목록, 관계 맵, 복잡도 평가. 이것이 이후 모든 결정의 나침반이 된다.

2번, 설계 문서를 먼저 쓰고 코드를 나중에 짜라. 특히 복잡한 도메인에서는 설계 문서가 AI 컨텍스트의 영속적 저장소 역할을 한다. 문서가 명확할수록 AI의 구현 품질이 올라간다.

3번, AI에게 "왜"를 물어라. "이 코드를 짜줘"보다 "이 문제를 해결하는 방법이 뭐가 있어? 각각의 장단점은?"이 더 좋은 질문이다. AI의 가치는 코드 생성보다 선택지 제시와 트레이드오프 분석에서 더 크다.

4번, AI의 출력을 반드시 검증하라. 특히 도메인 데이터에서. AI가 생성한 테이블, 규칙, 텍스트는 "훌륭한 초안"이지 "최종본"이 아니다. 검증 없이 배포하면 미묘한 오류가 사용자 신뢰를 깎는다.

5번, 모듈화에 투자하라. AI와 협업할 때 모듈화된 코드베이스는 "이 모듈의 맥락만 알면 돼"라는 효율을 만든다. 전체 코드베이스를 AI에게 이해시킬 필요 없이, 관련 모듈의 설계 문서만 로드하면 된다.

6번, AI를 도구가 아니라 협업자로 대하라. "이거 짜줘"가 아니라 "이 문제를 어떻게 풀면 좋겠어?" AI에게 맥락을 충분히 제공하고, 의견을 물어보고, 제안을 비판적으로 검토하는 과정. 이것이 AI 협업의 핵심이다.

"AI는 코딩 도구가 아니라 프로젝트 협업자"

이 시리즈에서 반복해서 전달하고 싶었던 메시지가 하나 있다. AI를 "코딩 도구"로 보는 시각에서 "프로젝트 협업자"로 보는 시각으로의 전환.

도구로 보면 AI의 가치는 "코드를 빨리 짜주는 것"에 한정된다. 협업자로 보면 도메인 리서치, 설계 논의, 코드 작성, 코드 리뷰, 테스트 설계, 문서 작성 — 프로젝트의 거의 모든 단계에서 AI와 대화하고 함께 결정할 수 있다.

그리고 이 시각의 전환은 프로젝트의 복잡도가 올라갈수록 더 중요해진다. 타로처럼 단순한 프로젝트에서는 도구로 써도 충분했다. 사주처럼 복잡한 프로젝트에서는 협업자로 대하지 않으면 AI의 잠재력을 절반도 활용하지 못한다.

협업자로 대한다는 것은 구체적으로 이런 것이다. 충분한 컨텍스트를 제공한다 — 설계 문서를 로드시키고, 프로젝트의 배경을 설명한다. 의견을 묻는다 — "이 방법 말고 다른 방법은 없어?" 비판적으로 검토한다 — AI의 제안을 무조건 수용하지 않고 "이게 정말 최선이야?"라고 되묻는다. 그리고 AI가 잘 모르는 영역을 인식한다 — 윤리적 판단, UX 감각, 최종 의사결정은 사람이 한다.

28년 개발 경력에서 AI가 바꾼 가장 큰 것

1998년부터 개발을 시작했다. 28년. 그 긴 시간 동안 수많은 기술 변화를 겪었다. 웹의 등장, 모바일의 폭발, 클라우드의 부상, 마이크로서비스 아키텍처. 하지만 AI 협업이 바꾼 것은 이전의 어떤 기술 변화와도 질적으로 다르다.

이전의 기술 변화는 "어떻게 만드는가"를 바꿨다. 서버 사이드 렌더링에서 클라이언트 사이드로, 모놀리스에서 마이크로서비스로. 만드는 방법이 바뀐 것이다.

AI 협업은 "무엇을 만들 수 있는가"를 바꿨다. 사주명리? 28년차 개발자라도 혼자서는 쉽게 도전하지 못했을 프로젝트다. 도메인이 너무 방대하고 복잡하기 때문이다. AI와 함께하니 도전할 수 있었다. 그리고 실제로 만들어냈다.

이것이 AI가 바꾼 가장 큰 것이다. 개인 개발자의 도달 범위(reach)의 확장. 혼자서는 엄두를 내지 못했을 프로젝트에 도전하고, 완성하고, 배울 수 있게 된 것. 기술의 변화가 아니라 가능성의 변화다.

마치며 — 시리즈를 마무리하며

타로 마스터 20편과 사주명리 20편. 총 40편의 개발기를 쓰면서 가장 많이 한 생각은 "이걸 읽는 분들에게 실질적인 도움이 되고 있을까"였다.

개발기를 쓰는 이유는 기록이기도 하지만, 공유이기도 하다. AI 협업 개발이라는 새로운 방식을 시도하면서 겪은 시행착오, 발견한 패턴, 얻은 교훈. 이것들이 비슷한 도전을 하려는 분들에게 조금이라도 참고가 되었으면 한다.

두 프로젝트를 통해 확신하게 된 것이 하나 있다. AI와의 협업은 일시적인 유행이 아니라 개발의 새로운 패러다임이라는 것이다. 지금은 아직 초기 단계이고, 도구도 방법론도 계속 발전하고 있다. 하지만 방향은 분명하다. AI는 개발자의 역할을 대체하는 것이 아니라, 개발자가 도달할 수 있는 범위를 넓혀준다.

다음에 어떤 프로젝트를 하게 될지는 아직 모른다. 하지만 한 가지는 확실하다. AI와 함께할 것이고, 그 과정에서 또 새로운 것을 배울 것이라는 점이다.

40편의 시리즈를 끝까지 읽어주신 분들께 진심으로 감사드린다.