라벨이 "웹개발"인 게시물 표시

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

  두 개의 프로젝트가 끝났다. 타로 마스터 20편, 사주명리 20편. 총 40편의 개발기를 쓰는 동안 AI와의 협업 방식은 계속 진화했다. 처음에는 "이게 되네?"라는 놀라움이었고, 끝에서는 "이것 없이 어떻게 했지?"라는 자연스러움이 됐다. 시리즈의 마지막 편에서 그 여정을 되돌아본다. 타로 — 속도의 발견 타로 프로젝트에서 발견한 것은 "속도"였다. AI와 함께하면 코드를 얼마나 빨리 짤 수 있는지. 78장의 카드 데이터를 수작업으로 입력하면 며칠이 걸릴 것을 AI가 몇 시간 만에 생성해줬다. 리딩 로직, UI 컴포넌트, 상태 관리 — 전통적으로 2~3주가 걸릴 기능들이 며칠 만에 동작했다. 타로에서의 AI 협업은 일종의 "터보 부스터"였다. 내가 할 줄 아는 것을 더 빠르게 해주는 도구. 기존 개발 방식의 연장선에서, 속도만 극적으로 빨라진 느낌이었다. 이 단계에서의 핵심 발견은 "AI가 반복적인 작업에서 압도적으로 효율적이다"라는 것이었다. 78장 카드 데이터 같은 대량 생성 작업, 비슷한 패턴의 컴포넌트를 여러 개 만드는 작업, 라이브러리 설정이나 보일러플레이트 코드 작성 같은 것들. 사주 — 깊이의 발견 사주 프로젝트에서 발견한 것은 "깊이"였다. AI와 함께하면 혼자서는 접근하기 어려운 도메인의 깊은 곳까지 도달할 수 있다는 것. 사주명리는 타로와 차원이 다른 도메인이었다. 수천 년의 역사, 다양한 학파, 복잡한 관계 체계. 이 도메인에 혼자 뛰어들었다면 도메인 학습에만 몇 달이 걸렸을 것이다. AI와 함께하니 도메인의 지형도를 10분 만에 그리고, 각 요소의 깊은 규칙을 구현하면서 동시에 학습할 수 있었다. 사주에서의 AI 협업은 "터보 부스터"를 넘어 "탐험 파트너"였다. 낯선 영역을 함께 탐색하는 동반자. 속도뿐 아니라 도달 가능한 깊이 자체가 달라졌다. 같은 도구인데 다른 배움을 얻은 이유는 프로젝...

설계 문서 우선 개발 — AI 시대의 게임 체인저

  코드를 한 줄도 쓰기 전에 문서를 먼저 쓴다. 개발자라면 누구나 아는 원칙이지만 실제로 지키는 사람은 드물다. 그런데 AI와 협업하면서 이 원칙이 단순한 모범 사례가 아니라 생산성의 핵심이라는 것을 깨달았다. 특히 사주명리처럼 복잡한 도메인에서는 설계 문서가 있고 없고의 차이가 하늘과 땅이었다. 타로 때의 방식 — 대화에서 코드로 타로 프로젝트를 돌이켜보자. 그때의 워크플로우는 이랬다. AI와 대화를 나누면서 "78장 카드의 데이터 구조를 어떻게 잡을까?"라고 묻고, AI가 제안하면 바로 코드로 옮긴다. 코드가 동작하면 다음 기능으로 넘어간다. 문제가 생기면 대화를 이어가며 수정한다. 이 방식은 빠르고 직관적이었다. 타로의 복잡도에서는 충분히 작동했다. 78장의 카드, 고정된 해석 텍스트, 비교적 단순한 리딩 로직. 전체 구조를 머릿속에 담을 수 있는 규모였기에 대화 기반으로도 일관성을 유지할 수 있었다. 하지만 사주 프로젝트에 들어가면서 이 방식의 한계가 드러났다. 천간지지 계산, 십신 관계, 합충형파해, 12운성, 지장간, 격국, 용신. 이 모든 요소가 서로 얽혀 있는 도메인에서 대화만으로 맥락을 유지하는 것은 불가능했다. 한계를 깨닫는 순간 사주 프로젝트 초기에도 타로 때와 같은 방식을 시도했다. AI와 대화하며 "십신 계산 로직을 구현해볼까"라고 하면 AI가 코드를 생성한다. 그런데 다음 세션에서 "지장간 분석을 추가하자"고 하면 AI가 이전 세션의 십신 로직과 일관되지 않는 구조를 제안하는 경우가 생겼다. 이유는 단순했다. AI의 대화 컨텍스트에는 한계가 있다. 이전 세션에서 어떤 결정을 내렸는지, 데이터 구조를 어떻게 잡았는지, 왜 그 방식을 선택했는지 — 이런 정보가 새 세션에서는 사라진다. 코드를 읽으면 "무엇"은 알 수 있지만 "왜"는 알 수 없다. 타로에서는 이 문제가 크지 않았다. 구조가 단순하니 코드만 봐도 맥락이 파악됐다. 사주에서는 달랐다. ...

학파 설정이라는 차별화 — "같은 사주, 다른 해석"

  "이 앱에서 본 사주랑 다른 앱에서 본 사주가 달라요." 사주 앱을 만들면 반드시 마주치는 질문이다. 같은 생년월일시를 입력했는데 결과가 다르다니, 사용자 입장에서는 당연히 의아하다. 이 문제를 숨기는 대신 정면으로 드러내기로 했다. 그것이 "학파 설정"이라는 기능의 출발점이었다. 왜 같은 생년월일시에도 다른 결과가 나오는가 사주명리는 수천 년의 역사를 가진 학문이다. 그 긴 시간 동안 다양한 학파와 유파가 생겨났고, 각 학파마다 계산 방식에 미묘한 차이가 있다. 핵심적인 차이점은 크게 네 가지다. 야자시(夜子時) 처리. 밤 11시에서 자정 사이에 태어난 사람의 일주를 어떻게 정할 것인가. 한 학파는 밤 11시가 지나면 다음 날로 본다. 다른 학파는 자정이 지나야 다음 날로 본다. 이 차이 하나로 일주 전체가 바뀌고, 당연히 십신 관계도 전부 달라진다. 진태양시(真太陽時) 적용. 시계로 보는 시간과 실제 태양의 위치에 따른 시간은 다르다. 서울과 부산의 경도가 다르니 같은 시각이라도 태양의 위치가 다르다. 진태양시를 적용하는 학파는 태어난 지역의 경도에 따라 시간을 보정한다. 적용하지 않는 학파는 표준시를 그대로 사용한다. 서머타임(일광절약시간) 보정. 한국은 과거 몇 차례 서머타임을 시행한 적이 있다. 1948~1961년, 그리고 1987~1988년. 이 기간에 태어난 사람의 시간을 1시간 빼야 하는지 말아야 하는지. 서머타임 보정을 적용하는 앱과 그렇지 않은 앱에서 결과가 갈린다. 12운성 음간 순역. 12운성을 계산할 때 양간은 순행, 음간은 역행한다는 것이 전통적인 방식이다. 하지만 일부 학파에서는 음간도 순행으로 계산한다. 이 차이로 12운성 결과가 크게 달라질 수 있다. calculationSchool — 설정으로 풀다 대부분의 사주 앱은 이 중 하나의 방식을 선택해서 고정한다. 어떤 앱은 야자시를 적용하고, 어떤 앱은 적용하지 않는다. 사용자는 어느 쪽이 맞는지 판단할 수 없고, 결과가 다르면 어느 앱을 믿어...