벡터 연산에 막힌 게임 수학 라이브러리 개발자라면

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

작은 수학 라이브러리를 직접 써보니 먼저 보인 문제

벡터 하나가 게임 코드의 표정을 바꿉니다

캐릭터 이동, 카메라 회전, 투사체 방향 계산을 만들다 보면 어느 순간 게임 수학 라이브러리의 품질이 코드 전체의 리듬을 좌우한다는 걸 느끼게 됩니다. 저도 처음에는 엔진 기본 Vector3와 Matrix4만 쓰면 충분하다고 생각했습니다. 그런데 툴 코드, 서버 검증 로직, 간단한 시뮬레이션 프로젝트를 오가다 보니 같은 연산을 매번 다른 방식으로 쓰고 있었습니다.

특히 Will Perone 사이트의 성격처럼 game programming과 math library에 관심이 있는 개발자라면, 직접 작은 라이브러리를 굴려보는 경험이 꽤 유용합니다. 완벽한 대체 엔진을 만들자는 이야기가 아닙니다. 내 게임의 좌표계, 각도 단위, 보간 방식, 부동소수점 허용 오차를 한곳에 묶어두는 것만으로도 디버깅 시간이 줄어듭니다.

• 좋았던 점: 벡터 정규화, 내적, 외적, 거리 계산이 프로젝트마다 같은 이름과 같은 규칙으로 정리됩니다.
• 불편했던 점: 초반에는 엔진 내장 타입과 변환 코드를 계속 작성해야 해서 생산성이 잠깐 떨어집니다.
• 실제 체감: 카메라 흔들림, 조준 보정, 충돌 전 보정값처럼 애매한 버그를 추적할 때 수식 위치가 명확해집니다.

팁: 처음부터 거대한 수학 패키지를 만들기보다 Vector2, Vector3, Quaternion, Matrix4의 사용 빈도 높은 연산만 먼저 묶어보는 편이 부담이 적습니다.

사용 후기 기준으로 본 핵심 설계 포인트

이름보다 중요한 것은 좌표계와 단위입니다

제가 가장 먼저 고친 것은 함수명이 아니라 단위 규칙이었습니다. 도 단위와 라디안 단위가 섞이면 회전 보간에서 이상한 값이 튀고, 왼손 좌표계와 오른손 좌표계가 섞이면 카메라가 반대로 돕니다. 그래서 모든 회전 입력은 라디안으로 받고, 에디터에서만 도 단위를 표시하도록 나눴습니다.

게임 개발 행사나 기술 발표를 보면 이런 기본기를 반복해서 강조하는 이유가 있습니다. GDC의 의미와 맥락을 살펴보면, 게임 개발 지식이 실전 사례와 함께 공유되는 흐름을 이해하기 좋습니다. 수학 라이브러리도 결국 멋진 수식보다 팀이 재사용할 수 있는 약속이 먼저였습니다.

1. 좌표계 문서화: 월드, 로컬, 뷰, 스크린 좌표가 어디서 변환되는지 주석과 테스트로 남겼습니다.
2. 오차 허용값 통일: 거의 같은 값인지 판단하는 epsilon을 파일마다 다르게 쓰지 않도록 했습니다.
3. 불변 연산과 변경 연산 분리: add와 addInPlace처럼 의도가 드러나는 이름을 붙이면 성능 최적화 지점도 찾기 쉽습니다.

테스트는 수식 검증보다 사용 시나리오에 가까워야 합니다

처음에는 내적 공식, 행렬 곱셈 결과처럼 교과서식 테스트만 넣었습니다. 하지만 실제로 도움이 된 테스트는 “플레이어가 바라보는 방향으로 10m 이동한다”, “카메라가 목표 지점을 0.2초 동안 따라간다” 같은 사용 시나리오였습니다. 이 방식은 게임 프로그래머가 수학 코드를 읽을 때 머릿속에서 장면을 떠올리게 해 줍니다.

• 벡터 테스트: 정규화 후 길이가 1에 가까운지 확인하되, 영벡터 입력 처리도 함께 봅니다.
• 쿼터니언 테스트: 180도 근처 회전에서 보간이 급격히 뒤집히지 않는지 확인합니다.
• 행렬 테스트: 이동, 회전, 스케일 순서가 프로젝트 규칙과 맞는지 장면 단위로 검증합니다.

엔진 내장 기능과 직접 만든 코드 사이의 현실적인 균형

모든 것을 새로 만들 필요는 없었습니다

직접 써보며 가장 크게 배운 점은 “직접 구현”과 “직접 소유”가 다르다는 것입니다. 고성능 SIMD 연산이나 플랫폼별 최적화는 엔진 또는 검증된 라이브러리에 맡기는 편이 낫습니다. 대신 프로젝트에서 자주 쓰는 수학 개념을 감싸는 얇은 계층을 두면, 코드 의도를 읽기 쉬워집니다.

예를 들어 Unity, Unreal, Godot 같은 엔진을 사용해도 게임 규칙에 특화된 타입은 따로 둘 수 있습니다. AimDirection, GroundNormal, SpawnTransform처럼 의미 있는 이름으로 감싸면 단순 Vector3보다 실수가 줄어듭니다. 기획자와 협업할 때도 “전방 30도 cone 안에 들어오면 감지”처럼 말이 코드와 가까워집니다. 직무 관점이 궁금하다면 기획자의 역할 설명도 함께 보면 협업 언어를 맞추는 데 도움이 됩니다.

• 엔진 타입을 그대로 쓸 때: 렌더링, 물리, 애니메이션처럼 엔진 API와 밀접한 구간은 변환 비용을 줄이는 편이 좋습니다.
• 래퍼 타입을 둘 때: 게임 규칙, 서버 판정, 리플레이 검증처럼 의미가 중요한 구간에서는 별도 타입이 유리합니다.
• 직접 구현을 피할 때: 고급 선형대수, 플랫폼 최적화, 난수 품질처럼 검증 비용이 큰 영역은 기존 라이브러리를 존중하는 편이 안전합니다.

실전 팁: 수학 라이브러리를 만들 때 성능을 먼저 외치기보다, 잘못된 좌표 변환을 컴파일 단계나 테스트 단계에서 빨리 드러내는 구조를 먼저 잡는 것이 낫습니다.

작은 표로 보면 선택이 쉬워집니다

아래 기준은 제가 사이드 프로젝트에서 실제로 적용한 구분입니다. 팀 규모가 작을수록 “이론적으로 좋은 구조”보다 “다음 주에도 이해되는 구조”가 중요했습니다. 유지보수할 사람이 미래의 나 한 명뿐이라면 더더욱 그렇습니다.

비용도 무시하기 어렵습니다. 시간을 어디에 쓸지 정하는 건 개발 예산의 일부이며, 큰 조직에서 말하는 계획예산 제도의 관점처럼 우선순위를 정하는 문제와 닮아 있습니다. 직접 구현에 3일을 쓸지, 에디터 툴 개선에 3일을 쓸지 판단해야 합니다.

• 빠른 프로토타입: 엔진 내장 타입 중심으로 시작하고, 반복되는 계산만 함수로 분리합니다.
• 멀티플랫폼 게임: 부동소수점 차이와 직렬화 규칙을 먼저 확인한 뒤 공통 수학 계층을 둡니다.
• 포트폴리오 프로젝트: 핵심 알고리즘을 직접 작성하되, 테스트와 문서까지 보여주는 편이 인상적입니다.

벡터 코드에서 자주 넘어지는 지점들

정규화, 보간, 좌표 변환에서 실수가 반복됩니다

제가 가장 자주 만난 실수는 영벡터 정규화였습니다. 입력이 0에 가까운 방향 벡터인데 normalize를 그대로 호출하면 NaN이 퍼지고, 그 값이 카메라나 캐릭터 위치에 들어가면서 화면 전체가 흔들립니다. 그래서 safeNormalize처럼 기본 방향을 함께 받는 함수를 따로 두니 재현 어려운 버그가 줄었습니다.

두 번째는 보간 함수 선택입니다. 위치에는 lerp가 자연스러울 때가 많지만 회전에는 slerp가 필요한 경우가 있습니다. 그런데 모든 회전에 slerp를 쓰면 비용이 커질 수 있고, 아주 작은 각도에서는 lerp 후 정규화가 충분한 경우도 있었습니다. 중요한 건 “수학적으로 멋진 함수”가 아니라 게임 느낌과 프레임 예산에 맞는 선택입니다.

• 실수 1: 거리 비교에 sqrt를 매번 호출합니다. 반지름 판정은 squared length로 비교하면 훨씬 가볍습니다.
• 실수 2: 행렬 곱셈 순서를 문서화하지 않습니다. Transform A * B의 의미가 팀마다 다르면 버그가 조용히 쌓입니다.
• 실수 3: 디버그 출력 없이 숫자만 봅니다. 방향 벡터는 선으로, 법선은 색으로 그려야 문제를 빨리 찾습니다.

포트폴리오로 보여줄 때는 사용 장면이 설득력입니다

Will Perone 같은 개발자 포트폴리오 성격의 사이트라면, 수학 라이브러리 자체보다 그것이 어떤 게임 장면을 안정시켰는지 보여주는 편이 좋습니다. “Vector3 구현”이라고만 쓰면 흔한 과제처럼 보이지만, “카메라 추적 흔들림을 safeNormalize와 damped spring으로 줄였다”라고 쓰면 실제 개발 경험으로 읽힙니다.

저는 README에 API 목록보다 작은 사용 예시를 먼저 배치했을 때 반응이 더 좋았습니다. 함수 이름, 입력 단위, 실패 처리, 테스트 명령어를 짧게 붙이면 코드를 처음 보는 사람도 금방 맥락을 잡습니다. 게임 프로그래밍에서 수학은 어려운 장식이 아니라, 플레이어가 조작을 편하게 느끼도록 만드는 조용한 기반이라는 점이 잘 드러납니다.

• 추천 예시: 조준 보정, 카메라 추적, 탄도 예측, 경사면 이동처럼 화면에서 바로 확인되는 기능을 붙입니다.
• 문서 방식: 함수 설명보다 “언제 쓰는지”를 먼저 쓰면 검색 유입 독자도 오래 머뭅니다.
• 주의할 점: 라이브러리 이름만 거창하고 실제 게임 장면이 없으면 포트폴리오 설득력이 약해집니다.