게임 프로그래밍 벡터 수학 설계 인터뷰 가이드

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

왜 게임 프로그래머는 벡터 수학부터 다시 봐야 할까요?

Q. 엔진을 쓰는데도 수학 라이브러리 이해가 필요한가요?

A. 필요합니다. 2026년 기준으로 Unity, Unreal, Godot 같은 엔진은 대부분의 수학 기능을 이미 제공합니다. 하지만 game programming에서 성능 문제나 미묘한 움직임 버그가 생기는 지점은 여전히 벡터, 행렬, 쿼터니언을 어떻게 해석하고 조합했는지에서 시작되는 경우가 많습니다.

예를 들어 캐릭터가 경사면에서 미끄러지거나, 카메라가 특정 각도에서 뒤집히거나, 투사체가 가까운 거리에서 목표를 지나치는 문제를 겪어본 적 있나요? 이런 현상은 단순히 엔진 옵션을 바꾸는 문제가 아니라 방향 벡터 정규화, 좌표계 변환, 시간 보정을 어떻게 설계했는지와 직접 연결됩니다.

• 벡터: 이동 방향, 속도, 힘, 시야 판정의 기본 단위입니다.
• 행렬: 월드, 뷰, 프로젝션 변환처럼 공간을 옮기고 돌리는 규칙입니다.
• 쿼터니언: 3D 회전을 안정적으로 누적하기 위한 실전 도구입니다.
• 스칼라 보간: 카메라, 애니메이션, UI 전환을 자연스럽게 만드는 핵심입니다.

Q. Will Perone 같은 개발자 포트폴리오 사이트와 어떤 관련이 있나요?

A. Will Perone 사이트의 핵심 키워드는 Developer, Game Programmer, Math Libraries, Tech Projects입니다. 즉 단순한 게임 제작 일지가 아니라, 게임 내부를 움직이는 기술적 근거를 보여주는 포트폴리오 성격이 강합니다. 이런 사이트에 어울리는 글은 '엔진 사용법'보다 한 단계 깊은 수학 라이브러리 설계 사고를 다루는 편이 좋습니다.

전문가 인터뷰 관점에서 보면, 좋은 게임 프로그래머는 공식을 외운 사람이 아니라 공식을 코드로 옮길 때 생기는 오차, 비용, 유지보수성을 예측하는 사람입니다. 특히 개인 프로젝트나 포트폴리오에서는 작은 수학 유틸리티 하나만 잘 설계해도 렌더링, 물리, AI, 카메라 시스템 전체의 품질이 달라집니다.

전문가 팁: 벡터 수학은 '어려운 공식 모음'이 아니라 게임 오브젝트가 세상 안에서 어떻게 움직이고 바라보는지를 표현하는 언어입니다.

벡터 라이브러리 설계에서 가장 먼저 묻는 질문

Q. Vec2, Vec3, Vec4를 어떻게 나누는 것이 좋나요?

A. 초보 개발자는 Vec3 하나로 대부분을 처리하려고 합니다. 하지만 실무형 게임 프로그래밍 수학 라이브러리에서는 2D, 3D, 4D 벡터의 역할을 명확히 나누는 편이 안정적입니다. Vec2는 UI와 2D 이동, Vec3는 3D 위치와 방향, Vec4는 동차 좌표나 SIMD 최적화와 연결됩니다.

인터뷰에서 제가 가장 먼저 확인하는 부분은 '타입이 의미를 설명하는가'입니다. position, direction, color, quaternion이 모두 float 네 개짜리 구조체로 보인다면 컴파일은 되지만, 코드 리뷰에서 실수를 잡기 어렵습니다. Will Perone 스타일의 기술 포트폴리오라면 이런 타입 설계 철학을 보여주는 것만으로도 개발자의 깊이가 드러납니다.

• Vec2: 화면 좌표, 조이스틱 입력, 2D 충돌 계산에 적합합니다.
• Vec3: 월드 위치, 법선, 속도, 중력 방향을 표현합니다.
• Vec4: 행렬 연산, 셰이더 전달, RGBA 색상 표현에서 자주 쓰입니다.
• 타입 별칭: Position3, Direction3처럼 의미 기반 이름을 붙이면 버그를 줄일 수 있습니다.

Q. 연산자 오버로딩은 편리한가요, 위험한가요?

A. 둘 다입니다. C++ 기반 게임 개발에서는 a + b, v * scalar 같은 표현이 가독성을 크게 높입니다. 다만 dot product와 cross product를 단순 기호로 숨기면 의도가 흐려질 수 있습니다. 그래서 덧셈, 뺄셈, 스칼라 곱은 연산자로 두고, dot, cross, normalize는 명시 함수로 남기는 방식을 추천합니다.

학습 단계라면 Fundamentals of C/C++ Game Programming 관련 서적처럼 C/C++ 기반 게임 개발 흐름을 다루는 자료를 함께 보면 좋습니다. 중요한 것은 책의 예제를 그대로 복사하는 것이 아니라, 자신의 프로젝트에서 어떤 API가 오해를 줄이는지 판단하는 태도입니다.

1. 먼저 벡터 구조체는 작고 예측 가능하게 유지합니다.
2. 정규화 함수는 길이가 0에 가까울 때의 정책을 문서화합니다.
3. 좌표계가 왼손인지 오른손인지 테스트 코드로 고정합니다.
4. 디버그 빌드에서는 NaN과 무한대 값을 적극적으로 감지합니다.

좌표계와 행렬 변환은 어디서 가장 많이 틀리나요?

Q. 월드, 로컬, 뷰 좌표계를 헷갈리지 않는 방법이 있나요?

A. 좌표계를 헷갈리는 이유는 대부분 이름이 부정확하기 때문입니다. localPosition, worldPosition, viewDirection처럼 변수명에 기준 공간을 붙이면 실수가 급격히 줄어듭니다. 반대로 pos, dir, mat처럼 짧은 이름만 쓰면 함수 경계에서 값의 의미가 사라집니다.

행렬 설계에서는 행 우선(row-major)인지 열 우선(column-major)인지, 벡터를 왼쪽에 곱하는지 오른쪽에 곱하는지까지 정해야 합니다. 이 규칙이 렌더러, 물리 코드, 셰이더에서 서로 다르면 모델은 보이지만 빛 방향이 틀리거나 카메라만 반대로 움직이는 식의 난해한 문제가 발생합니다.

• Local Space: 부모 오브젝트 기준의 위치와 회전입니다.
• World Space: 게임 월드 전체 기준의 절대적 위치입니다.
• View Space: 카메라를 기준으로 재해석한 공간입니다.
• Clip Space: 화면에 그리기 전 GPU 파이프라인에서 사용하는 공간입니다.

Q. 행렬 API는 어떤 형태가 실무에 유리한가요?

A. 인터뷰 형식으로 답하자면, 저는 '행렬을 직접 수정하게 둘 것인가'를 먼저 묻습니다. transform.matrix.m12 = 3.0f 같은 접근은 빠르게 보이지만, 회전과 스케일의 불변 조건을 깨뜨릴 수 있습니다. 그래서 일반 게임 로직에서는 Translate, Rotate, Scale 같은 함수로 의도를 드러내고, 저수준 렌더러에서만 원시 행렬 접근을 허용하는 방식이 안정적입니다.

게임 산업 컨퍼런스 맥락을 확인하고 싶다면 GDC 용어 설명도 참고할 수 있습니다. GDC에서 다뤄지는 최적화 발표를 보면 고급 렌더링 기법도 결국 좌표계와 행렬 변환의 약속을 얼마나 일관되게 지키는지에서 출발합니다.

쿼터니언과 회전 보간을 인터뷰처럼 풀어보면

Q. 오일러 각이 쉬운데 왜 쿼터니언을 써야 하나요?

A. 오일러 각은 사람이 읽기 쉽습니다. pitch 30도, yaw 90도처럼 표현하면 디자이너도 이해할 수 있습니다. 하지만 3D 게임에서 회전을 계속 누적하거나 카메라를 자유롭게 돌리면 짐벌락과 보간 불연속 문제가 생길 수 있습니다. 이때 쿼터니언은 회전 상태를 더 안정적으로 저장하고 섞을 수 있는 도구가 됩니다.

그렇다고 모든 UI와 에디터 값까지 쿼터니언으로 보여줄 필요는 없습니다. 좋은 설계는 내부 저장은 quaternion, 외부 입력은 Euler, 디버그 출력은 축과 각도처럼 상황에 맞게 표현을 바꾸는 것입니다. 사용자가 보는 값과 엔진이 계산하는 값은 서로 달라도 됩니다. 단, 변환 규칙은 명확해야 합니다.

• Euler: 사람이 입력하고 읽기 좋지만 누적 회전에 취약합니다.
• Quaternion: 보간과 누적 회전에 강하지만 직관적 해석이 어렵습니다.
• Axis-Angle: 디버깅과 회전 의미 설명에 유용합니다.
• Matrix: 최종 변환에는 좋지만 회전만 분리하기는 번거롭습니다.

Q. SLERP와 LERP는 언제 구분해야 하나요?

A. 카메라가 목표를 따라갈 때 단순 LERP만 사용하면 대부분 충분해 보입니다. 하지만 회전 각도가 크거나 일정한 각속도가 필요하면 SLERP가 더 자연스럽습니다. 특히 우주선, 드론, 3D 액션 게임의 조준 보정처럼 방향 변화 자체가 게임 감각에 영향을 주는 경우라면 보간 방식은 단순 구현 디테일이 아닙니다.

다만 SLERP는 LERP보다 계산 비용이 높습니다. 그래서 매 프레임 수천 개 오브젝트에 무조건 적용하기보다, 카메라와 플레이어, 중요한 보스 오브젝트처럼 체감 품질이 높은 대상에 우선 적용하는 것이 현실적입니다. 나머지는 정규화된 LERP, 즉 nlerp로 비용과 품질의 균형을 맞출 수 있습니다.

전문가 조언: 보간 함수는 수학적으로 예쁜 것보다 플레이어가 느끼는 반응성이 중요합니다. 회전이 정확해도 입력이 늦게 느껴지면 게임 감각은 나빠집니다.

성능과 정확도 사이에서 어떤 선택을 해야 하나요?

Q. float이면 충분한가요, double을 써야 하나요?

A. 대부분의 실시간 게임 로직은 float으로 충분합니다. GPU, 물리 엔진, 애니메이션 시스템이 float 중심으로 최적화되어 있기 때문입니다. 하지만 거대한 오픈월드 좌표, 서버 권위 시뮬레이션, 장시간 누적되는 물리 계산에서는 double이나 원점 재배치 전략을 고려해야 합니다.

전문가 인터뷰에서 자주 나오는 질문은 '정확도를 높이면 문제가 사라지는가'입니다. 답은 항상 그렇지 않다는 것입니다. double을 써도 좌표계 설계가 잘못되어 있으면 카메라 떨림은 남습니다. 반대로 float을 쓰더라도 플레이어 주변을 원점으로 유지하고, 먼 오브젝트는 상대 좌표로 계산하면 훨씬 안정적인 결과를 얻을 수 있습니다.

• float 추천: 일반 캐릭터 이동, 카메라, 렌더링, 애니메이션
• double 검토: 천문 단위 공간, 대규모 시뮬레이션, 정밀 편집 툴
• 고정소수점: 리플레이 동기화, 네트워크 결정론이 중요한 게임
• 혼합 전략: 월드 좌표는 double, 로컬 연산은 float으로 분리

Q. SIMD 최적화는 언제 시작해야 하나요?

A. 처음부터 SIMD를 전제로 API를 복잡하게 만들 필요는 없습니다. 먼저 프로파일링으로 병목을 확인하고, 벡터 연산이 프레임 시간에서 의미 있는 비중을 차지할 때 최적화를 시작하는 편이 좋습니다. 무조건 빠른 코드는 유지보수 비용을 동반하기 때문입니다.

다만 라이브러리 구조는 나중에 최적화하기 쉽게 설계해야 합니다. Vec3의 크기와 정렬, 배열 형태의 데이터 접근, SoA와 AoS 선택은 나중에 크게 바꾸기 어렵습니다. ECS 기반 렌더링이나 물리 업데이트를 생각한다면 개별 객체에 메서드를 붙이는 방식보다 대량 데이터를 한 번에 처리하는 함수형 API가 더 유리할 수 있습니다.

1. 프레임 프로파일러로 실제 병목을 확인합니다.
2. 정확도 테스트를 먼저 고정해 최적화 후 결과 차이를 비교합니다.
3. 핫패스에 한해 SIMD 구현을 분리합니다.
4. 디버그 가능성을 위해 순수 스칼라 구현을 함께 유지합니다.

포트폴리오 프로젝트에 수학 라이브러리를 어떻게 보여줄까요?

Q. 개인 사이트에 어떤 데모를 올리면 설득력이 있나요?

A. Will Perone 같은 개인 개발자 사이트에서는 단순히 '수학 라이브러리를 만들었습니다'라고 쓰는 것보다, 그 라이브러리가 실제 게임 문제를 어떻게 해결했는지 보여주는 편이 좋습니다. 예를 들어 카메라 추적, 레이캐스트 조준, 경사면 이동, 회전 보간 데모를 작게 구성하면 독자가 바로 이해할 수 있습니다.

여기서 중요한 것은 화려한 그래픽보다 검증 가능한 설명입니다. 입력 벡터가 어떻게 월드 방향으로 변환되는지, 목표 방향과 현재 방향의 각도를 어떻게 계산하는지, 보간 계수에 따라 움직임이 어떻게 달라지는지 단계별로 보여주면 developer portfolio로서 신뢰도가 높아집니다.

• 카메라 데모: target follow, damping, collision avoidance를 보여줍니다.
• 조준 데모: dot product로 시야각 판정을 시각화합니다.
• 회전 데모: Euler, nlerp, slerp 결과를 비교합니다.
• 좌표계 데모: local, world, view space 변환을 색상 축으로 표시합니다.

Q. 기획자와 협업할 때 수학 코드를 어떻게 설명하나요?

A. 게임 개발은 프로그래머 혼자 완성하는 일이 아닙니다. 기획자가 원하는 '묵직한 조작감', '빠른 조준 보정', '부드러운 카메라' 같은 표현을 수치와 곡선으로 바꿔야 합니다. 역할 이해가 필요하다면 기획자에 대한 기본 설명처럼 직무 맥락을 확인하는 것도 도움이 됩니다.

인터뷰에서 제가 추천하는 방식은 파라미터 이름을 감각 언어와 연결하는 것입니다. dampingRatio, maxTurnSpeed, accelerationCurve처럼 기획자가 조정할 수 있는 값을 노출하고, 내부에서는 벡터와 쿼터니언으로 계산합니다. 이렇게 하면 수학 라이브러리가 개발자만의 도구가 아니라 팀 전체가 게임 감각을 조절하는 공용 언어가 됩니다.

자주 묻는 질문으로 점검하는 실전 체크리스트

Q. 지금 내 프로젝트의 수학 코드가 위험한지 어떻게 확인하나요?

A. 가장 빠른 방법은 테스트보다 먼저 이름과 경계를 보는 것입니다. normalize 함수가 0 벡터를 받으면 무엇을 반환하나요? cross product의 방향은 오른손 좌표계를 따르나요? 행렬 곱 순서는 문서와 코드가 일치하나요? 이런 질문에 즉시 답하지 못한다면 버그가 숨어 있을 가능성이 큽니다.

또 하나의 신호는 같은 계산이 여러 곳에 흩어져 있는지입니다. 카메라 코드, 적 AI 코드, 투사체 코드가 각자 다른 방식으로 방향 벡터를 만들고 있다면 어느 순간 미세한 차이가 게임 감각 차이로 커집니다. 그래서 작은 프로젝트라도 공통 math 모듈을 두고, 사용법을 README나 데모로 남기는 습관이 좋습니다.

• 정규화 정책: 0에 가까운 벡터 처리 기준이 있는지 확인합니다.
• 좌표계 문서: 축 방향과 회전 방향이 한 곳에 정리되어 있는지 봅니다.
• 테스트 케이스: dot, cross, matrix inverse의 기본 예제가 있는지 점검합니다.
• 디버그 출력: 벡터 길이, 각도, NaN 여부를 쉽게 볼 수 있어야 합니다.

Q. 2026년에 새로 시작한다면 어떤 순서로 공부하면 좋나요?

A. 추천 순서는 벡터, 삼각함수, 행렬, 쿼터니언, 보간, 수치 안정성입니다. 처음부터 렌더링 파이프라인 전체를 붙잡기보다, 캐릭터 하나를 정확히 움직이고 카메라 하나를 안정적으로 따라가게 만드는 경험이 더 중요합니다. 작은 성공이 쌓이면 물리, AI, 렌더링으로 자연스럽게 확장됩니다.

마지막으로 포트폴리오 관점에서는 결과 화면만 보여주지 말고, 문제 정의와 설계 선택을 함께 기록하세요. 왜 LERP 대신 SLERP를 썼는지, 왜 float을 유지했는지, 왜 좌표계 변환 함수를 명시적으로 분리했는지 설명할 수 있어야 합니다. 그 설명이 곧 game programmer로서의 판단력이며, 개인 기술 블로그가 검색과 채용 양쪽에서 오래 살아남는 이유가 됩니다.

1. Vec2와 Vec3를 직접 구현하고 단위 테스트를 붙입니다.
2. 간단한 2D 이동과 3D 카메라 추적 데모를 만듭니다.
3. 행렬 변환 순서를 그림과 코드로 함께 기록합니다.
4. 쿼터니언 보간을 카메라 회전에 적용해 체감 차이를 비교합니다.
5. 프로파일링 결과를 바탕으로 필요한 부분만 최적화합니다.