게임 프로그래밍 절차적 생성에 거대한 AI 모델은 필요 없다

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

맵을 만들 때마다 아티스트의 손이 부족하고, 반복 플레이를 늘리자니 콘텐츠 제작비가 걱정되시나요? 이런 상황에서 곧바로 생성형 AI부터 떠올리기 쉽지만, 게임 안에서 예측 가능하고 빠르게 작동해야 하는 콘텐츠 생성에는 오히려 오래 검증된 알고리즘이 더 잘 맞습니다. 절차 생성 시스템을 설계해 온 개발자 유담에게 게임 프로그래밍과 절차적 생성의 현실적인 적용법을 물었습니다.

절차적 생성은 왜 대형 AI 없이도 충분한가

Q. 규칙 기반 생성은 이미 낡은 기술 아닌가요?

A. 전혀 그렇지 않습니다. 게임에서 중요한 것은 무엇이든 새롭게 만드는 능력이 아니라, 플레이 가능한 결과를 정해진 시간과 메모리 안에서 반복해서 만드는 능력입니다. 셀룰러 오토마타, 웨이브 함수 붕괴, 확률 문법, 보로노이 다이어그램, 노이즈 함수처럼 비교적 작은 알고리즘도 규칙과 제약을 잘 설계하면 동굴, 도시, 아이템 배치, 퀘스트 조합까지 처리할 수 있습니다. 같은 시드를 입력했을 때 같은 결과가 나오는 결정론도 확보하기 쉬워 저장 데이터, 네트워크 동기화, 버그 재현에 유리합니다.

반대로 거대한 모델이 생성한 결과는 그럴듯해 보여도 게임 규칙을 자동으로 만족하지는 않습니다. 출구가 막힌 던전, 이동 불가능한 발판, 경제 밸런스를 깨는 보상처럼 시각적으로는 자연스럽지만 플레이할 수 없는 결과가 섞일 수 있습니다. 결국 별도의 검증기와 수정 단계가 필요하므로, 런타임 콘텐츠라면 작은 생성기와 강한 검증기의 조합이 비용과 품질을 함께 관리하기 쉽습니다. 개발 발표와 기술 교류가 게임 제작 방식에 어떤 영향을 주는지 궁금하다면 GDC의 의미와 배경도 참고할 만합니다.

• 결정론적 재생: 월드 전체를 저장하지 않고 시드와 변경점만 보관할 수 있습니다.
• 빠른 실행: 추론 서버나 대용량 모델 로딩 없이 프레임 또는 로딩 단계에서 생성할 수 있습니다.
• 명확한 제약: 방 크기, 경사도, 적 밀도, 희귀 아이템 간격을 숫자로 통제할 수 있습니다.
• 쉬운 회귀 테스트: 실패한 시드를 기록해 같은 맵을 개발 환경에서 즉시 재현할 수 있습니다.
• 플랫폼 독립성: 저사양 PC와 모바일, 콘솔에서도 동일한 규칙을 공유하기 쉽습니다.

Q. 그렇다면 AI는 절차 생성에서 쓸모가 없다는 뜻인가요?

A. AI를 없애자는 이야기가 아니라 역할을 분리하자는 뜻입니다. 런타임에서는 규칙 기반 생성기가 안전한 구조를 만들고, 제작 단계에서는 AI가 콘셉트 초안, 장식 후보, 대사 변형처럼 실패해도 제품 전체를 망가뜨리지 않는 작업을 도울 수 있습니다. 예를 들어 방 연결 그래프와 충돌 가능한 지형은 코드가 결정하고, 벽 장식의 분위기나 지역별 명칭 후보만 생성 도구에서 받아 사람이 승인하는 방식입니다. 이 구조라면 모델이 바뀌거나 서비스가 중단되어도 게임의 핵심 루프는 흔들리지 않습니다.

전문가 조언: “생성기의 목표를 ‘무한한 다양성’으로 잡지 마세요. 플레이어가 차이를 느끼는 몇 가지 축을 정의하고, 그 축이 서로 충돌하지 않게 만드는 편이 훨씬 중요합니다.”

1. 먼저 플레이 규칙을 위반하면 안 되는 불변 조건을 적습니다.
2. 그다음 방 형태, 적 조합, 보상처럼 체감 차이가 큰 변수를 고릅니다.
3. 안전한 범위 안에서만 난수를 사용하고 모든 난수에 시드 경로를 부여합니다.
4. 생성 직후 연결성, 난이도, 자원량을 검사하는 검증 단계를 둡니다.
5. 검증에 실패하면 전체를 버리지 말고 문제가 생긴 구역만 다시 생성합니다.

재미있는 랜덤을 만드는 게임 수학의 설계법

Q. 무작위로 배치했는데 왜 플레이가 금방 지루해질까요?

A. 균등 난수는 공정해 보이지만 사람이 기대하는 재미있는 분포와는 다릅니다. 적 열 마리가 우연히 한 구역에 몰리거나, 회복 아이템이 오랫동안 나오지 않는 상황도 수학적으로는 정상입니다. 그러나 플레이어는 이를 불공정하다고 느낍니다. 그래서 게임 프로그래밍에서는 단순 난수 대신 가중치, 쿨다운, 셔플 백, 포아송 디스크 샘플링, 누적 실패 보정 같은 장치를 사용합니다. 질문은 “랜덤한가?”가 아니라 “플레이어가 납득할 수 있는 변동인가?”가 되어야 합니다.

가령 희귀 상자의 기본 확률이 낮더라도 일정 횟수 동안 등장하지 않으면 가중치를 조금씩 높일 수 있습니다. 적 배치는 최소 거리를 두는 포아송 디스크 방식으로 겹침을 줄이고, 전투 강도는 방별 예산을 먼저 배분한 뒤 그 안에서 적 종류를 선택하면 됩니다. 예산이라는 말이 딱딱하게 느껴진다면 계획과 예산을 연결하는 개념처럼 목표와 자원을 함께 관리하는 방식으로 이해하면 쉽습니다. 게임에서는 돈이 아니라 체력 피해량, 적 수, 이동 거리, 인지 부하를 예산으로 다룬다는 차이가 있습니다.

Q. 다양성과 밸런스는 어떻게 동시에 측정합니까?

A. 스크린샷 몇 장을 보고 판단하면 특이한 사례만 기억하게 됩니다. 최소 수천 개의 시드를 자동 생성한 뒤 경로 길이, 분기 수, 빈 공간 비율, 적 위협도, 보상 가치, 되돌아가는 거리 같은 지표를 수집해야 합니다. 평균뿐 아니라 하위 1%와 상위 1%를 함께 보세요. 평균 난이도가 적당해도 극단적인 시드에서 진행 불가능한 맵이 나오면 출시 후 반드시 문제로 이어집니다. 특히 개발자용 시드 검색 도구를 만들어 “보상이 가장 적은 맵”, “출구까지 가장 긴 맵”을 한 번에 열 수 있게 하면 수동 테스트 시간이 크게 줄어듭니다.

• 연결성: 시작점에서 필수 목표와 출구까지 모두 도달할 수 있는지 검사합니다.
• 완주 거리: 최단 경로뿐 아니라 필수 우회 구간과 되돌아가는 거리도 기록합니다.
• 공간 리듬: 좁은 구간과 넓은 전투 공간이 얼마나 자주 교대하는지 측정합니다.
• 전투 편차: 같은 진행 단계에서 위협도 최댓값이 평균보다 지나치게 높지 않은지 봅니다.
• 보상 분산: 총량이 같더라도 초반에 몰리거나 후반에 고갈되지 않는지 확인합니다.
• 시각 반복: 동일한 방 템플릿과 장식 조합이 연속해서 등장하는 횟수를 제한합니다.

테스트 팁: 좋은 시드만 즐겨찾기하지 말고 실패 시드에 이름을 붙이세요. “문 뒤 낭떠러지”, “회복약 없는 보스 길”처럼 증상을 분류하면 생성 규칙의 약점이 데이터로 드러납니다.

프로토타입을 망치는 자동 생성의 세 가지 착각

Q. 처음 구현할 때 어느 정도 규모로 시작해야 하나요?

A. 월드 전체가 아니라 플레이 5분 분량의 한 구역부터 시작하는 것이 좋습니다. 입력 시드, 생성 규칙, 검증 결과, 최종 배치를 서로 분리하고, 개발 화면에서 각 단계를 켜고 끌 수 있게 만드세요. 처음부터 생태계, 날씨, 퀘스트, 경제를 연결하면 어떤 규칙이 재미를 만들었고 무엇이 실패를 일으켰는지 추적하기 어렵습니다. 기획 의도를 코드와 연결하려면 생성 변수마다 “이 값이 바뀌면 플레이 경험이 어떻게 달라지는가”라는 설명도 붙여야 합니다. 역할과 협업 범위를 이해하는 데에는 게임 기획자의 업무 설명도 참고할 수 있습니다.

권장 프로토타입은 단순합니다. 20~30개의 방 후보를 만들고, 시작점과 출구 사이의 최소 거리를 정한 뒤, 위협도 예산에 따라 적을 배치합니다. 그 후 자동 플레이어나 탐색 알고리즘으로 길이 존재하는지 확인하고, 실패한 시드는 로그에 남깁니다. 여기서 재미가 확인된 다음에만 테마 변형과 장식을 추가하세요. 혹시 장식이 빠진 회색 상자 맵은 재미없어 보인다고 느끼시나요? 바로 그 상태에서도 이동 선택과 전투 리듬이 흥미로워야 시각 요소가 더해졌을 때 견고한 시스템이 됩니다.

1. 1단계: 생성기 입력과 출력 구조를 고정하고 시드를 화면에 항상 표시합니다.
2. 2단계: 필수 경로와 선택 경로를 구분해 그래프만 생성합니다.
3. 3단계: 그래프 노드를 실제 방과 복도로 변환하고 충돌 영역을 계산합니다.
4. 4단계: 위협도와 보상 예산을 진행도 곡선에 맞춰 분배합니다.
5. 5단계: 자동 검증을 통과한 결과만 플레이 가능한 후보로 넘깁니다.
6. 6단계: 플레이 로그를 규칙 변경 전후로 비교해 체감과 수치를 함께 확인합니다.

Q. 현장에서 가장 흔히 저지르는 실수는 무엇인가요?

A. 첫 번째 실수는 랜덤 값을 많이 쓰면 콘텐츠가 다양해진다고 믿는 것입니다. 서로 의미 없는 수십 개의 변수가 흔들리면 차이는 많아져도 플레이 경험은 흐려집니다. 두 번째는 생성 성공 여부만 확인하고 품질의 하한선을 두지 않는 것입니다. 길이 연결되어 있다는 사실만으로 좋은 맵이 되지는 않으므로, 최대 우회 거리와 최소 회복 자원처럼 플레이 가능한 범위를 수치로 선언해야 합니다. 세 번째는 시드 하나만 저장하고 난수 호출 순서를 관리하지 않는 것입니다. 장식 코드를 한 줄 추가했더니 적 배치까지 달라진다면 독립 난수 스트림이 없다는 신호입니다.

• 실수 1, 무제한 변수: 플레이어가 실제로 느끼는 공간 크기, 위험도, 보상 밀도부터 세 축 정도만 조절합니다.
• 실수 2, 재시도 남발: 성공할 때까지 전체 맵을 다시 만드는 대신 실패 원인을 반환하고 해당 단계만 복구합니다.
• 실수 3, 난수 스트림 공유: 지형, 적, 보상, 장식에 서로 다른 하위 시드를 사용해 변경 영향을 격리합니다.
• 실수 4, 디버그 화면 부재: 연결 그래프, 이동 불가 영역, 위협도 히트맵을 한 키로 표시할 수 있게 합니다.
• 실수 5, 평균값 의존: 최악의 시드와 경계값을 별도 테스트 목록으로 유지합니다.

특히 재시도를 안전장치처럼 사용하는 습관을 조심해야 합니다. 조건이 까다로워질수록 특정 기기에서 로딩 시간이 갑자기 늘고, 드물게 생성이 끝나지 않을 수도 있습니다. 각 단계에 최대 시도 횟수와 실패 사유를 두고, 작은 대체 방이나 보수적인 기본 배치로 복구하는 경로를 마련하세요. 절차적 생성의 완성도는 가장 화려한 결과가 아니라 가장 나쁜 결과를 얼마나 통제했는지에서 드러납니다.