goldtag

  취미로 게임을 만들기 시작했다. 이전에 타로 프로젝트를 AI와 함께 완성한 적이 있다. 사주명리 프로젝트도 했다. 둘 다 20편짜리 개발기를 쓸 만큼 배운 게 많은 프로젝트였고, AI 협업 개발이라는 방식에 대한 확신도 생겼다. 다음 프로젝트로 뭘 할까 고민하다가, 게임이라는 영역이 눈에 들어왔다. 만들어본 적은 없지만 해본 적은 많은 분야. 개발자로서의 궁금증이 생겼다. 그래서 아이에게 물어봤다. "아빠가 요즘 취미로 게임을 만들고 있는데, 혹시 너도 만들고 싶은 게임 있어? 같이 만들어볼까?" 아이의 눈이 커졌다. "진짜? 나도 할 수 있어?" "응. 어떤 장르 게임이 좋아?" 잠깐 생각하더니 아이가 대답했다. "미연시." 순간 당황했다. 슈팅이나 퍼즐, 아니면 마인크래프트 같은 걸 말할 줄 알았다. 미연시라니. 어디서 접한 건지, 친구들 사이에서 유행하는 건지 모르겠지만, 아이는 꽤 진지한 표정이었다. 그런데 이상하게 그 대답이 머릿속에서 떠나지 않았다. 중2 여자아이의 취향에 놀란 것도 있지만, 그보다는 내 안에서 뭔가 반응한 느낌이었다. 개발자의 직업병 나는 개발자다. 뭔가를 만드는 일을 직업으로 하고 있다. 그래서 "만들 수 있어?"라는 질문에는 늘 조건반사적으로 반응한다. 만들 수 있냐고? 기술적으로야 대부분 만들 수 있다. 문제는 항상 다른 데 있다. 시간, 기획, 완성도, 그리고 끝까지 갈 수 있느냐는 의지. 아이가 미연시를 말한 순간, 개발자의 뇌가 즉시 가능성을 따지기 시작했다. 미연시. 비주얼 노벨. 텍스트와 선택지로 이루어진 게임. 화려한 액션도 없고, 복잡한 물리 엔진도 필요 없다. 대신 이야기가 있고, 선택이 있고, 그 선택에 따라 관계가 달라진다. 사실 게임 개발과 인연이 아예 없는 건 아니다. DOS에서 Windows로 막 넘어가던 2000년대 초반, 게임 라이브러리를 직접 만들던 시절이 있었다. 비트맵, PCX 같은 이미지 포맷을 직접 ...

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

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