실내와 실외를 연결하는 기능을 정리했다. 위 스크린샷의 하단부는 실외이고, 초가집 내부 모습이 상단에 나타나있다. 문을 통해서 두 공간을 오갈 수 있다. 독(dock) 모드에서는 위와 같고, 전체 화면으로 했을 때는 아래와 같은 모습이다.
이번에 코드를 완전히 다시 작성하게 된 계기가 이 실내/실외 이동 관련한 구현이 버그가 워낙 많았기 때문인 것도 있다.
- 독 모드에서는 실내 팝업이 독자적인 윈도우로 나와야 한다.
- 전체화면 모드에서는 실내 팝업이 게임 내 팝업으로 나와야 한다.
말로 하면 참 쉽고 간결했고, 바이브 코딩으로 구현을 시킬 때도 잘 되는 것처럼 보였다. 그러나 몇 번 전체화면 모드와 독 모드를 토글링하면 런타임 퍼포먼스(즉, fps)가 극단적으로 내려갔고 이를 수정하지 못했다.
이번에는 모든 클래스 목록을 내가 직접 정했고, 각 클래스의 책임과 한계에 대해서 하나씩 구현해나가며 최대한 알려주는 방향으로 훨씬 더 좁은 보폭으로 AI에게 일을 시켰다. 예를 들어, 예전 바이브 코딩에서는 “실내로도 들어갈 수 있게 하는데, 문으로 가서 페이드아웃되고 실내 문에서 페이드인되면 된다.” 수준이었다면 이번에는 “각 공간은 ZPlace란 클래스로 표현된다. ZPlace는 ZPortal이라는 자식을 가질 수도 있다. 서로 다른 ZPortal은 서로 연결되며, 이에 따라 서로 다른 두 ZPlace가 ZPortal에 의해 연결되는 구조이다. 폰(pawn)은 ZPortal 근처로 가서 거기에 연결된 다른 ZPortal로 순간이동할 수 있는데, 순간이동은 연출 절차는 페이드인/페이드아웃이다.” 정도로 자세히 안내했다. 이동 좌표에 대해서도 예전엔 아무 이야기 안해서 도대체 어떻게 구현했는지 실외 이동 범위를 자꾸 벗어나서 어디론가 가는지도 몰랐는데 이번에는 “이동 보간은 ZPlace의 로컬 좌표로서만 처리한다” 등 좀 더 자세한 지침을 바로바로 알아듣는 상태가 되었다.
실내-실외의 연결을 그래프로 이해하는 것은 간단히 키워드만 던져주니 알아서 잘 하는 것으로 보였다. 예를 들어 실내에 있을 때는 ‘벌목’을 하고 싶어도 할 수가 없다. 실내라는 ZPlace안에 나무가 없기 때문이다. 그러나 존재하는 ZPortal을 탐색해서 이동 가능한 다른 ZPlace까지도 검색 범위를 넓히라고 했더니, 실외의 나무까지 탐색이 됐고, 이동을 위해 만든 ZMoveJob의 복잡화된 버전인 ZComplexMoveJob을 만들라고 해서 임의의 ZPlace의 임의 로컬 좌표를 목적지로 하는 작업도 한번에 잘 만들었다.
여전히 모든 코드는 내가 코드 리딩하고 리뷰하면서 작업하고 있어서 개발 속도는 4-5배는 느려진 것 같으나, 결과적으로 어떤 일이 일어나고 있는지를 다 알고 진행하고 있기 때문에 괴상하고 도저히 알아볼 수 없는 이상한 코드로 발산하는 것은 선제적으로 막을 수 있게 됐다.
코드 리뷰 과정에서 내가 AI에게 자주 묻는 질문과 답은 다음과 같은 카테고리 중 하나다.
- “이 멤버 변수가 꼭 필요한가요?” => “꼭 필요하진 않습니다”
- “이 프로퍼티에 true를 설정한 이유가 있습니까?” => “반드시 그래야만 하는 것은 아닙니다”
- “이 값은 다른 값에 이미 참조가 걸려 멤버 변수로 따로 들고 있을 필요가 없어 보입니다.” =>”그 참조가 불변이라는 가정이 있다면 필요 없는 것이 맞습니다”
특히나 세 번째가 좀 재밌었는데, 의외로 내가 암묵적인 가정을 많이 하고 있다는 점이었다. 예를 들어 아까 이야기한 “ZPortal을 통해 ZPlace가 연결된다”는 부분에서 ZPortal과 연결된 ZPlace가 불변이라는 가정을 나는 당연히 했는데, AI는 그런 가정을 하지 않아서 발생한 문제였다. 결과적으로는 과한 구현이었지만, 명시적이지 않은 부분에 대해 매우 방어적으로 구현하고, 그에 따라 나중에 걷잡을 수 없는 이상한 버그를 만들 가능성도 있는 그런 부분이긴 하지만… 암묵적 가정을 나도 모르게 정해둔 부분을 잘 잡아내는 것이 AI의 장점이 극대화된 부분인 것 같기도 하다.