게임 좌표계 오류를 원인별로 추적해 바로잡는 흐름

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

좌표가 틀어진 순간부터 증상을 분리합니다

화면이 틀린 것인지 데이터가 틀린 것인지 먼저 봅니다

캐릭터가 벽 안으로 파고들거나, 총알이 조준점과 다른 방향으로 날아가거나, 카메라가 특정 각도에서 뒤집히는 문제는 대부분 게임 좌표계 오류처럼 보입니다. 하지만 실제 원인은 렌더링 좌표, 물리 좌표, 입력 좌표, 에디터 표시 좌표 중 한 군데에만 있을 수 있습니다. 처음부터 행렬 전체를 뜯기보다 증상을 쪼개면 디버깅 시간이 훨씬 줄어듭니다.

Will Perone 같은 game programming 중심 포트폴리오에서 인상적인 프로젝트는 복잡한 기능보다 기본 좌표 흐름이 안정적인 코드에서 나옵니다. 게임 수학은 화려한 공식보다 값이 어디서 태어나 어디로 전달되는지 설명할 수 있을 때 힘을 발휘합니다. 그래서 첫 단계는 고장난 장면을 작게 만들고, 월드 좌표와 로컬 좌표를 같은 프레임에서 출력하는 일입니다.

• 화면만 이상한 경우: 렌더 행렬, 뷰 행렬, 프로젝션 설정을 우선 확인합니다.
• 충돌만 이상한 경우: 물리 엔진의 단위, 콜라이더 중심점, 스케일 적용 순서를 봅니다.
• 입력 방향만 반대인 경우: 카메라 기준 이동 벡터와 월드 기준 이동 벡터가 섞였는지 확인합니다.
• 에디터에서는 맞고 런타임에서 틀린 경우: 임포트 축 변환과 런타임 초기화 코드의 중복 보정을 의심합니다.

팁: 좌표 버그는 눈으로만 보면 착시가 많습니다. 문제 프레임의 위치, 회전, 스케일 값을 로그로 남기고 화면의 기즈모와 나란히 비교해 보세요.

단위와 축 방향을 잠그고 기준표를 만듭니다

왼손 좌표계와 오른손 좌표계가 섞이는 지점을 찾습니다

게임 프로그래밍에서 좌표계 문제가 길어지는 가장 흔한 이유는 팀 안에 기준표가 없기 때문입니다. 아티스트 툴은 Z-up, 엔진은 Y-up, 물리 라이브러리는 미터 단위, 게임플레이 코드는 센티미터 단위를 쓸 수 있습니다. 각각은 틀리지 않았지만, 변환 지점이 문서화되지 않으면 같은 위치 값이 매번 다른 뜻으로 해석됩니다.

특히 math library를 직접 만들거나 외부 라이브러리를 감싸서 쓸 때는 행렬 저장 방식까지 확인해야 합니다. 행 우선인지 열 우선인지, 벡터를 왼쪽에 곱하는지 오른쪽에 곱하는지, 전진 방향이 +Z인지 -Z인지가 모두 결과를 바꿉니다. 이 차이를 ‘나중에 맞추면 되겠지’라고 넘기면 애니메이션, 카메라, 충돌 코드가 서로 다른 세계에서 움직이게 됩니다.

1. 프로젝트의 기본 월드 축을 한 줄로 적습니다. 예: X는 오른쪽, Y는 위, Z는 앞.
2. 거리 단위를 하나로 고정합니다. 물리와 렌더가 다르면 변환 함수 이름에 단위를 드러냅니다.
3. 모델 임포트 시 축 변환을 한 번만 수행하도록 위치를 정합니다.
4. 좌표 변환 함수에는 from과 to를 이름에 넣습니다. 예: LocalToWorld, WorldToView.

팀에 기획자가 있다면 이동 방향, 카메라 기준, 조작감 요구사항도 함께 확인해야 합니다. 게임 개발에서 역할 정의가 궁금하다면 기획자에 대한 지식백과 설명처럼 직무의 관점을 참고해도 좋습니다. 좌표 기준은 개발자만의 내부 규칙이 아니라 플레이 경험을 결정하는 약속이기 때문입니다.

행렬 곱 순서를 작은 장면에서 다시 재현합니다

스케일, 회전, 이동의 순서가 바뀌면 전혀 다른 장면이 됩니다

좌표계가 맞는데도 오브젝트가 엉뚱한 궤도로 도는 경우에는 행렬 곱 순서를 의심해야 합니다. 이동 후 회전과 회전 후 이동은 같은 값으로 보이지만 결과는 다릅니다. 캐릭터 손에 붙은 무기가 몸 중심을 기준으로 빙글 돌거나, UI 마커가 타깃 옆으로 밀리는 현상이 여기에 속합니다.

큰 장면에서 바로 고치려 하면 부모 노드, 애니메이션, 카메라 보정, 스크립트 업데이트 순서가 한꺼번에 섞입니다. 가장 좋은 방법은 큐브 하나, 부모 노드 하나, 자식 노드 하나만 있는 테스트 장면을 만드는 것입니다. 여기에서 스케일, 회전, 이동을 하나씩 켜고 끄면 어느 단계에서 값이 튀는지 빠르게 드러납니다.

• SRT와 TRS를 혼동한 경우: 스케일이 회전축까지 늘려서 자식 오브젝트 위치가 예상보다 멀어집니다.
• 부모 월드 행렬을 두 번 곱한 경우: 자식이 부모 이동량의 두 배만큼 밀립니다.
• 역행렬을 잘못 쓴 경우: 월드 좌표를 로컬로 바꿔야 할 때 오히려 더 먼 위치로 튑니다.
• 프레임마다 누적 곱을 한 경우: 작은 오차가 쌓여 카메라가 서서히 기울거나 크기가 변합니다.

전문가 조언: 변환 버그를 잡을 때는 임시 보정값을 넣지 마세요. 숫자를 맞추는 패치는 다음 기능에서 다시 깨지고, 원인 위치를 더 깊이 숨깁니다.

게임 개발 발표와 사례를 꾸준히 보는 것도 도움이 됩니다. 예를 들어 GDC의 개념을 살펴보면 실무 지식이 어떻게 공유되는지 이해할 수 있습니다. 좌표와 행렬 문제는 엔진, 툴, 그래픽스, 게임플레이가 만나는 지점이라 다른 개발자의 디버깅 사례에서 힌트를 얻는 일이 많습니다.

쿼터니언과 오일러 각이 섞인 코드를 표시합니다

회전값을 사람이 읽는 방식과 엔진이 계산하는 방식은 다릅니다

카메라가 위를 볼 때 갑자기 뒤집히거나, 캐릭터가 특정 방향에서만 떨린다면 회전 표현을 살펴봐야 합니다. 오일러 각은 사람이 이해하기 좋지만 축 순서와 짐벌락 문제에 취약합니다. 쿼터니언은 보간과 누적 회전에 강하지만 값을 눈으로 읽기 어렵기 때문에 로그만 보고 판단하기 쉽지 않습니다.

많은 버그는 둘 중 하나가 나빠서가 아니라, 둘을 오가는 변환이 코드 곳곳에 흩어져 생깁니다. 예를 들어 입력 시스템은 yaw와 pitch를 오일러 각으로 저장하고, 애니메이션은 쿼터니언을 쓰며, 카메라 후처리에서 다시 오일러 각으로 변환하면 축 순서가 한 번만 어긋나도 결과가 흔들립니다. developer 입장에서는 회전 데이터의 소유자를 정하고 변환 경계를 줄이는 것이 핵심입니다.

1. 런타임 내부 회전 표현을 하나로 정합니다. 일반적으로 누적 회전과 보간에는 쿼터니언이 안전합니다.
2. 에디터 입력이나 디버그 UI에서만 오일러 각을 노출합니다.
3. 오일러 변환 함수에는 축 순서를 이름이나 주석으로 남깁니다.
4. 카메라 pitch에는 상하 제한을 두고, roll은 의도한 기능이 아니면 0에 가깝게 유지합니다.
5. 두 회전 사이 보간은 선형 보간보다 slerp를 우선 검토합니다.

이 단계에서 중요한 질문은 ‘어느 값이 진짜 상태인가?’입니다. 진짜 상태가 여러 곳에 있으면 동기화 버그가 생깁니다. 회전 원본은 하나만 두고 나머지는 표시용, 입력용, 네트워크 전송용 파생값으로 취급하면 게임 수학 코드가 훨씬 단단해집니다.

툴과 포트폴리오 코드까지 같은 규칙으로 묶습니다

디버그 기즈모, 로그, 테스트가 같은 언어를 쓰게 만듭니다

좌표계 오류를 고쳤는데 며칠 뒤 다시 생긴다면 코드만의 문제가 아닐 수 있습니다. 디버그 기즈모는 월드 좌표를 보여주고, 로그는 로컬 좌표를 찍고, 테스트는 렌더 좌표를 기대한다면 개발자는 매번 머릿속에서 변환을 해야 합니다. 작은 개인 프로젝트라도 이 규칙을 맞춰두면 portfolio로 공개했을 때 코드의 신뢰도가 달라집니다.

Will Perone 스타일의 기술 프로젝트를 참고하는 독자라면, 기능을 많이 넣는 것만큼이나 디버깅 가능한 구조를 보여주는 것이 중요합니다. 수학 라이브러리나 게임 엔진 샘플은 API 이름, 테스트 이름, 예제 장면이 같은 개념을 공유할 때 읽기 좋아집니다. 예제 코드가 짧아도 좌표 기준이 선명하면 다른 개발자가 빠르게 이해하고 재사용할 수 있습니다.

• 기즈모 색상: X, Y, Z 축 색을 프로젝트 전체에서 고정합니다.
• 로그 접두어: [Local], [World], [View]처럼 좌표 공간을 앞에 붙입니다.
• 테스트 이름: Transform_LocalToWorld_PreservesChildOffset처럼 변환 의도를 드러냅니다.
• 샘플 장면: 큐브, 카메라, 부모-자식 노드가 있는 최소 장면을 유지합니다.

여기서 비용을 크게 들일 필요는 없습니다. 무료 테스트 프레임워크와 엔진 기본 디버그 드로잉만으로도 충분합니다. 다만 임시 로그를 남발하기보다 좌표 공간을 함께 출력하는 작은 헬퍼를 만들면 이후 카메라, 충돌, 애니메이션 작업에서도 같은 도구를 재사용할 수 있습니다.

오늘 한 장면을 회귀 테스트로 남깁니다

방금 잡은 버그가 다시 살아나지 않게 고정합니다

좌표계 버그는 고친 순간보다 다시 생기지 않게 만드는 순간이 더 중요합니다. 특히 엔진 코드와 게임플레이 코드가 함께 바뀌는 프로젝트에서는 정상으로 보이는 장면 하나를 기준점으로 남겨야 합니다. 테스트가 없다면 나중에 모델 임포트 옵션을 바꾸거나 카메라 코드를 손봤을 때 같은 문제가 조용히 돌아옵니다.

가장 실용적인 방법은 방금 문제가 발생한 장면을 더 작게 줄여 자동 테스트나 샘플 씬으로 보존하는 것입니다. 예를 들어 부모 오브젝트를 X축으로 10 이동하고, 자식을 로컬 Z축으로 2 배치한 뒤, 월드 좌표가 기대값과 일치하는지 확인합니다. 수치 오차가 있는 연산은 완전 일치 대신 허용 오차를 둡니다.

1. 문제가 보였던 오브젝트 하나를 선택합니다.
2. 부모 변환, 자식 변환, 기대 월드 좌표를 숫자로 적습니다.
3. 로컬에서 월드로 가는 함수 하나만 호출하는 테스트를 만듭니다.
4. 렌더 확인이 필요하면 같은 장면에 축 기즈모를 켜고 스크린샷을 보관합니다.
5. 테스트 이름에 버그 원인을 넣어 다음 개발자가 의도를 읽게 합니다.

지금 바로 할 수 있는 행동은 간단합니다. 현재 프로젝트에서 좌표가 한 번이라도 이상했던 장면을 열고, 그 오브젝트의 Local position, World position, Rotation order, Scale 네 값을 한 파일에 기록해 보세요. 그다음 LocalToWorld 테스트 하나를 추가하면, 오늘의 디버깅이 내일의 안전장치가 됩니다.