① 어떤 상황에서 AI를 활용했나요?

저는 3인 팀 '레이지 타운'에서 Unity 개발을 총괄하며 PICO 4 Ultra용 힐링 콘텐츠 '꽁꽁사르르 XR'을 제작했습니다. 체험자는 현실 공간과 정합된 얼음동굴로 걸어 들어가 실제 의자에 앉고, 이후 가상현실 속 캐릭터의 케어와 우유니 소금사막의 풍경을 경험합니다.

작은 팀이 약 10분 분량의 14개 장면, MR에서 VR로 이어지는 공간 전환, 시선 상호작용, 캐릭터 연출, 사운드, 모바일 성능, 현장용 복구 기능까지 동시에 완성해야 했습니다. 특히 XR은 에디터에서 정상으로 보여도 실제 기기에서는 위치 보정, 시야, 성능, 앱 재실행 과정에서 다른 문제가 생길 수 있습니다. 기능을 빠르게 추가하는 것보다 변경 내용을 놓치지 않고 검토하며, 실제 기기에서 확인할 항목을 끝까지 추적하는 개발 방식이 필요했습니다.

② 어떤 AI를 어떻게 활용했나요?

AI 하나에게 모든 일을 맡기지 않고 역할을 분리했습니다.

- Claude Code는 프로젝트 구조와 작업 기록을 읽은 뒤 기능 구현 계획, Unity C# 코드 작성·수정, 오류 원인 분석, 작업계획과 인계 문서 정리를 보조했습니다.
- OpenAI Codex는 구현자가 아니라 독립 검토자로 사용했습니다. 변경된 코드와 씬 설정, 누락된 예외 경로, 다른 기능에 미칠 영향, 검증 방법을 다시 확인하게 했습니다.
- Higgsfield AI는 개발 과정에서 필요한 일부 이미지와 텍스처 소스의 편집 초안을 만드는 데 활용했습니다. 결과는 그대로 확정하지 않고 화면 분위기와 가독성에 맞는지 사람이 선별·수정했습니다.
- Meshy AI는 내부에 필요한 일부 간단한 3D 오브젝트의 초안을 만드는 데 활용했습니다. 생성 결과는 Blender와 Unity에서 크기, 형태, 재질, 폴리곤 수와 모바일 성능을 확인한 뒤 필요한 부분만 사용했습니다.

실제 작업은 `문제와 완료조건 작성 → Claude Code의 구현·분석 → 사람이 코드와 결과 확인 → Codex의 독립 검토 → 수정 → Unity 컴파일·재생 → PICO 실기 확인 → 결과 기록` 순서로 진행했습니다. AI가 제안한 내용을 바로 정답으로 취급하지 않았으며, 실제 프로젝트 상태와 맞지 않거나 근거가 부족한 제안은 반영하지 않았습니다. 최종 APK 안에서 생성형 AI가 실시간으로 동작하는 것은 아니며, AI는 제작과 품질관리 과정에 사용했습니다.

③ 활용 결과 어떤 변화가 있었나요?

가장 큰 변화는 단순히 작업 속도가 빨라졌다는 것이 아니라, 복잡한 변경을 기록하고 다른 관점에서 다시 검사하는 과정이 생긴 것입니다. 예를 들어 MR 공간 보정 기능을 검토할 때 첫 구현 결과를 바로 완료 처리하지 않고 여러 차례 검토했습니다. 그 과정에서 예외 상황을 시험한 뒤 저장값이 원래 상태로 복구되지 않아 다음 검증 결과까지 왜곡할 수 있는 문제를 발견했습니다. 이후 모든 실패 시험을 `기준값 기록 → 오류 조건 주입 → 결과 관찰 → 원상 복구 → 기준값 재확인` 순서로 수행하도록 기준을 만들었습니다.

또한 다기기 배포 도구가 일부 실패를 성공으로 보고할 수 있는 경로, MR 시작 화면이 다시 나타날 수 있는 조건, 장면 전환 중 음성과 상태가 중복될 수 있는 경우 등을 검토 단계에서 찾아 수정했습니다. 반대로 AI가 위험하다고 판단한 내용도 실제 설정과 기기 측정 결과가 다르면 그대로 반영하지 않았습니다. AI의 의견보다 Unity와 PICO의 실측 결과를 최종 판단 기준으로 삼았습니다.

이 과정을 거쳐 팀은 약 10분 분량의 MR→VR→MR 경험을 Android APK로 완성했고, 같은 APK를 PICO 4 Ultra 6대에 설치해 2026년 8월 19일부터 21일까지 쇼케이스에서 운영했습니다. 3일간 운영진 추산 약 200명이 체험했습니다. 이 수치는 AI만의 성과가 아니라 팀원의 기획·아트·애니메이션·사운드와 개발자의 선택·수정·실기 검증이 결합된 결과입니다.

④ 나만의 방식 또는 개선 포인트는 무엇인가요?

첫째, 구현을 돕는 AI와 검토하는 AI를 분리했습니다. Claude Code가 프로젝트 문맥을 이어받아 구현을 보조하고, Codex는 같은 결과를 반대 관점에서 검사했습니다. 같은 AI에게 작성과 승인을 모두 맡기지 않은 것입니다.

둘째, 작업을 시작하기 전에 완료조건과 확인할 위험을 문서로 남겼습니다. 검토할 때는 마지막 수정분만 보지 않고 관련 변경과 기존 약속을 함께 확인했습니다. 문제가 발견되면 수정 사유, 확인 방법, 아직 실제 기기에서 확인하지 못한 항목을 구분해 기록했습니다.

셋째, 이미지와 3D 생성 AI의 결과도 완성품이 아니라 초안으로 취급했습니다. 시각적으로 좋아 보여도 콘텐츠의 캐릭터성, XR 거리감, 모바일 렌더링 비용에 맞지 않으면 수정하거나 사용하지 않았습니다. AI의 생성 능력과 사람의 품질 판단을 분리한 것이 핵심입니다.

⑤ 다른 사람도 따라 할 수 있나요?

특정 프로젝트나 유료 장비가 없어도 다음 순서로 적용할 수 있습니다.

1. 해결할 문제와 완료조건, 건드리면 안 되는 범위를 짧게 적습니다.
2. 구현용 AI에 현재 파일, 오류, 제약조건을 제공하고 해결안과 검증 방법을 함께 요청합니다.
3. 사람이 제안 내용을 읽고 필요한 부분만 코드나 작업물에 반영합니다.
4. 별도의 AI 또는 새로운 대화에서 누락, 예외 상황, 회귀 위험을 다시 검토합니다.
5. 컴파일·실행·실기 테스트처럼 실제 환경의 결과로 채택 여부를 결정합니다.
6. 수정 이유, 확인 결과, 미확인 항목을 다음 작업자가 볼 수 있게 기록합니다.

중요한 것은 AI 도구의 개수가 아니라 역할을 섞지 않는 것입니다. `AI가 제안하고, 다른 관점이 의심하고, 사람이 실제 결과로 판정한다`는 구조는 앱 개발, 영상 제작, 디자인, 문서 업무 등에도 그대로 적용할 수 있습니다.