게임 사운드 외주 수주부터 Wwise 인게임 연동까지: 연출 프로세스 실무 가이드
게임 사운드 외주를 수주한 뒤 요구사항을 설계하고 에셋을 제작·검수해 Wwise와 Unity에 연동하는 전 과정을 정리합니다. 견적·납품 기준부터 이벤트, RTPC, 사운드뱅크, QA까지 실무에서 재작업을 줄이는 방법을 다룹니다.
게임 사운드 외주의 핵심은 좋은 효과음을 납품하는 데서 끝나지 않는다. 기획 의도를 구현 가능한 오디오 명세로 바꾸고 Wwise Event·Switch·State·RTPC 구조를 엔진 코드와 일치시키며 실제 플레이 중에도 자연스럽게 들리도록 검수해야 한다. 이를 위해 수주 단계에서부터 에셋 수량, 변형 규칙, 호출 파라미터, 통합 책임 범위를 문서화하는 것이 가장 효과적이다.
사운드 외주 연출 프로세스는 어떻게 시작할까?
사운드 외주는 보통 문의 → 범위 정의 → 견적 및 계약 → 프리프로덕션 → 제작 → 미들웨어 구현 → 엔진 연동 → QA 및 납품 순서로 진행된다. 단계가 뒤로 갈수록 수정 비용이 커지므로 초기 문서에서 연출 목적과 기술 조건을 함께 확정해야 한다.
flowchart LR
A[프로젝트 문의] --> B[요구사항·레퍼런스 분석]
B --> C[에셋 목록·견적·일정 확정]
C --> D[사운드 스타일 가이드·시제품]
D --> E[에셋 제작·클라이언트 피드백]
E --> F[Wwise 이벤트·파라미터 구현]
F --> G[Unity 또는 Unreal 연동]
G --> H[플레이 QA·밸런싱·최종 납품]수주 전 반드시 확인할 항목
| 구분 | 확인할 내용 | 재작업을 막는 이유 |
|---|---|---|
| 게임 정보 | 장르, 플랫폼, 타깃 연령, 플레이 영상, 빌드 | 사운드의 밀도와 현실성 기준이 달라진다. |
| 연출 의도 | 타격감, 공포감, 속도감, 정보 전달 우선순위 | 같은 총소리라도 기능과 톤이 달라진다. |
| 에셋 범위 | UI, 환경음, 캐릭터, 무기, 보이스, BGM 포함 여부 | 견적의 기준이 되는 실제 작업 단위다. |
| 기술 환경 | Unity/Unreal 버전, Wwise/FMOD 사용 여부, 기존 오디오 구조 | 납품물이 WAV인지 프로젝트 파일인지 결정한다. |
| 통합 범위 | 외주사가 미들웨어 세팅·엔진 연동까지 담당하는지 | 제작비와 기술 지원 범위를 분리할 수 있다. |
| 납품 기준 | 파일 포맷, 샘플레이트, 루프 규칙, 수정 횟수, 소스 파일 권리 | 최종 검수의 판단 기준이 된다. |
견적과 작업 명세서는 무엇까지 써야 할까?
에셋 개수만으로 견적을 내면 부족하다. 하나의 공격 사운드도 단발 WAV 1개인지 약·중·강 타격 3단계와 피치 변형, 재생 우선순위, RTPC 제어를 포함하는지에 따라 작업량이 달라진다.
작업 명세서에는 최소한 다음 필드를 넣는다.
- 에셋 ID와 용도:
SFX_Player_Sword_Hit_Light처럼 검색 가능한 이름과 사용 장면을 작성한다. - 변형 규칙: 랜덤 컨테이너 개수, 피치 범위, 볼륨 범위, 쿨다운을 정한다.
- 재생 조건: 어떤 게임 이벤트에서 재생되는지 2D인지 3D인지 부착할 게임 오브젝트가 무엇인지 기록한다.
- 기술 파라미터: 샘플레이트, 루프 구간, 거리 감쇠, 동시 재생 제한, 믹서 버스와 덕킹 규칙을 정한다.
- 검수 기준: 어떤 빌드와 어느 장면에서 확인할지, 수정 횟수와 승인 절차를 명시한다.
예를 들어 ‘검 휘두르기’는 다음처럼 에셋이 아니라 기능 단위로 적는 편이 안전하다.
| 항목 | 예시 명세 |
|---|---|
| Event | Play_Player_Sword_Swing |
| 소스 | 4개 변형을 Random Container에 배치 |
| 피치 | -30 ~ +30 cents 랜덤 |
| 재생 제한 | 동일 액터 기준 최대 2개 |
| 공간화 | 3D, 플레이어 손 소켓 위치 |
| RTPC | PlayerSpeed에 따라 고역 비중과 볼륨 변화 |
| 검수 장면 | 대시 중 연속 공격, 카메라 거리 1 m·8 m 비교 |
사운드 디자인 시제품은 왜 먼저 만들어야 할까?
레퍼런스는 방향을 알려 주지만 게임에 바로 적용 가능한 답은 아니다. 특히 타격음과 UI 사운드는 영상만 듣는 평가와 직접 조작하는 평가가 다르다. 따라서 전체 에셋을 만들기 전에 대표 기능 3~5개를 시제품으로 제작해 톤, 길이, 정보성, 반복 피로도를 확인한다.
권장 시제품은 다음과 같다.
- 플레이어의 기본 공격 또는 이동
- 가장 자주 쓰는 UI 입력과 오류 알림
- 적 피격·처치처럼 전투 결과를 알려 주는 소리
- 배경 루프와 전투 진입 전환
- 게임의 정체성을 보여 주는 특수 행동 1개
승인할 때는 ‘멋있다’보다 행동 기준으로 피드백을 받는다. 예를 들어 “피격음을 더 세게” 대신 “피격 성공 여부가 카메라 흔들림 없이도 들리는가”, “0.3초 간격 연타에서도 귀가 피로하지 않은가”처럼 질문해야 수정 방향이 명확해진다.
Wwise에서 게임 사운드 연출을 어떻게 구현할까?
Unity 2022.3 LTS와 Wwise 통합 프로젝트를 예로 들면 게임 코드는 가능한 한 Wwise Event만 호출하고 랜덤 재생·볼륨·피치·상태 전환 같은 연출 규칙은 Wwise Authoring Tool에서 관리하는 구조가 유지보수에 유리하다. 코드에 믹싱 규칙을 분산하면 사운드 수정마다 빌드가 필요해진다.
1. 오디오 오브젝트와 버스 구조를 설계한다
효과음은 기능별 Work Unit과 버스로 나눈다. 예를 들어 SFX_Player, SFX_Enemy, SFX_UI, AMB, Music, VO를 최상위 범주로 두고 최종 믹싱은 Master Audio Bus 아래에서 관리한다.
대화가 재생될 때 BGM을 낮추는 덕킹은 VO 버스가 Music 버스에 적용하는 방식이 일반적이다. 단순히 BGM 볼륨을 코드로 내리는 방식보다 중첩 재생과 복구를 일관되게 처리하기 쉽다.
2. Event, Switch, State, RTPC의 책임을 분리한다
| Wwise 요소 | 적합한 용도 | 예시 |
|---|---|---|
| Event | 재생·정지 같은 단발 명령 | Play_Weapon_Fire |
| Switch | 같은 행동의 종류를 즉시 선택 | 표면 재질: 흙, 금속, 나무 |
| State | 씬 또는 게임 전체의 지속 상태 | 탐험, 전투, 보스전 |
| RTPC | 연속적으로 변하는 수치 | 속도, 체력, 엔진 RPM, 위험도 |
발소리는 Switch_SurfaceType으로 재질을 고르고 RTPC_PlayerSpeed로 달리기 강도를 조절하며 State_GamePhase로 전투 중 믹싱을 바꾸는 식으로 분리할 수 있다. Switch에 연속 수치를 억지로 넣거나 State를 매 프레임 변경하면 디버깅이 어려워진다.
RTPC 값 를 0~100 범위로 정규화해 게인을 제어한다면 예를 들어 다음과 같이 선형 매핑을 설계할 수 있다.
실제 값은 콘텐츠에 따라 달라지지만 최소값·최대값·갱신 주체를 문서에 남겨야 클라이언트 코드와 Wwise 곡선이 어긋나지 않는다.
3. 사운드뱅크와 엔진 호출을 연결한다
사운드뱅크는 씬 또는 기능 단위로 나누고 해당 씬에 필요한 Event와 미디어만 포함한다. 모든 사운드를 한 뱅크에 넣으면 초기 로딩과 메모리 관리가 어려워진다.
Unity C#에서는 Wwise Unity Integration이 생성한 Event 참조를 사용해 다음처럼 호출할 수 있다.
using UnityEngine;
public sealed class FootstepAudio : MonoBehaviour
{
[SerializeField] private AK.Wwise.Event footstepEvent;
[SerializeField] private AK.Wwise.Switch surfaceSwitch;
public void PlayFootstep(GameObject surfaceObject)
{
surfaceSwitch.SetValue(gameObject);
footstepEvent.Post(gameObject);
}
}위 예제에서 중요한 점은 Event가 재생될 3D 위치를 가질 게임 오브젝트에 게시된다는 것이다. surfaceObject가 필요하다면 레이캐스트 결과에서 재질 Switch를 판정하는 역할을 별도 코드로 두고 이 메서드에는 확정된 Switch 값만 전달하는 편이 명확하다.
인게임 사운드 QA는 어떤 순서로 진행할까?
에디터에서 정상 재생되는 것만으로 통합이 끝난 것은 아니다. 프레임 드롭, 빠른 상태 전환, 다수 적 등장, 씬 재진입 같은 실제 조건에서 사운드는 끊기거나 겹치고 뱅크가 빠졌거나 게임 오브젝트 위치가 잘못될 수 있다.
- 기능 QA: 모든 Event가 올바른 시점에 호출되는지 필요한 SoundBank가 로드되는지 확인한다.
- 공간 QA: 3D 감쇠 거리, 리스너 위치, 좌우 패닝, 폐쇄 공간에서의 청감 변화를 점검한다.
- 부하 QA: 동시 재생 수가 많은 전투에서 Voice Limit와 우선순위에 따라 중요한 소리가 남는지 확인한다.
- 연출 QA: 플레이 영상과 함께 검수해 타격 판정, 애니메이션, VFX, 카메라 흔들림과 사운드의 시작점이 맞는지 확인한다.
- 믹싱 QA: 대사, UI, 전투, 환경음이 동시에 재생될 때 핵심 정보가 가려지지 않는지 확인한다.
Wwise Profiler에서는 Voice Graph, Voices, RTPC, SoundBanks 등을 확인해 실제 게임에서 어떤 Event와 미디어가 재생되는지 추적할 수 있다. 문제가 생겼을 때 ‘소리가 안 난다’가 아니라 Event 미호출, Switch 미설정, 뱅크 미로드, Voice Limit 탈락, 감쇠 범위 밖 중 어느 단계인지 분류하는 것이 빠르다.
자주 묻는 질문 (FAQ)
사운드 외주 납품물에 Wwise 프로젝트까지 포함해야 할까?
통합 업무가 계약 범위라면 포함하는 것이 좋다. 다만 Wwise 프로젝트, 원본 소스, 렌더링된 WAV, SoundBank 중 무엇을 인도하는지와 사용 권한을 계약서에 분리해 적어야 한다.
Event 이름은 누가 정해야 할까?
사운드 담당자와 클라이언트 프로그래머가 함께 정하는 것이 가장 안전하다. 기능 중심의 영문 규칙을 만들고 중간에 이름을 바꾸지 않도록 에셋 명세서와 엔진 호출 목록을 같은 기준으로 관리한다.
랜덤 사운드는 몇 개가 적당할까?
반복 빈도가 높은 발소리·타격음은 보통 3~6개 변형부터 검토한다. 개수보다도 피치·볼륨 랜덤 범위, 동시 재생 제한, 반복 방지 규칙을 함께 조절해야 기계적인 반복을 줄일 수 있다.
정리
사운드 외주의 품질은 개별 WAV의 완성도와 기술 연동의 완성도가 함께 결정한다. 수주 단계에서 기능 단위의 명세를 만들고 시제품으로 연출 방향을 승인한 뒤 Wwise의 Event·Switch·State·RTPC를 역할별로 분리하자. 마지막으로 실제 플레이 조건에서 프로파일링과 믹싱 QA를 수행하면 납품 후의 통합 수정과 커뮤니케이션 비용을 크게 줄일 수 있다.
