게임 수학 라이브러리 테스트는 Catch2가 가장 균형 잡혔다

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

벡터 내적 함수 하나는 몇 줄이면 만들 수 있지만, 그 함수가 모든 경계값에서 정확하다는 사실을 증명하는 일은 훨씬 어렵습니다. 특히 게임 프로그래밍에서는 부동소수점 오차, 좌표계 규칙, 정규화되지 않은 입력처럼 플레이 중에만 드러나는 문제가 많아 C++ 테스트 프레임워크 선택이 라이브러리의 신뢰도와 개발 속도를 좌우합니다.

GoogleTest, Catch2, doctest, Boost.Test는 모두 무료로 사용할 수 있지만 지향점은 다릅니다. 이 글에서는 게임 수학 라이브러리를 직접 관리하는 개발자를 기준으로 도입 난이도, 표현력, 빌드 부담, 대규모 프로젝트 적합성을 비교합니다.

네 가지 C++ 테스트 프레임워크는 강점이 분명히 다르다

게임 수학 코드에 필요한 평가 기준

일반적인 비즈니스 로직과 달리 게임 수학 테스트에는 근삿값 비교, 여러 입력을 반복하는 매개변수 테스트, 실패한 벡터 성분을 읽기 쉬운 형태로 보여주는 기능이 중요합니다. 테스트 실행 속도만 보고 고르면 실제 실패 원인을 해석하는 데 더 많은 시간을 쓰게 됩니다.

아래 비교는 소규모 개인 포트폴리오부터 여러 플랫폼을 지원하는 게임 엔진까지 고려한 결과입니다. 네 프레임워크 모두 오픈소스라 라이선스 비용은 사실상 0원이지만, 헤더 파싱 시간과 CI 유지보수 시간도 비용으로 계산해야 합니다.

• 초기 비용: 패키지 설치, CMake 연결, 테스트 실행 파일 구성에 드는 시간입니다.
• 운영 비용: 컴파일 시간, CI 캐시 크기, 버전 업데이트 대응까지 포함합니다.
• 진단 품질: 실패한 수식과 실제 값이 로그에 얼마나 명료하게 표시되는지를 봅니다.

테스트 도구의 가격표가 무료라고 해서 운영 비용도 0원인 것은 아닙니다. 기능 수보다 팀이 매일 치를 컴파일·진단 비용을 먼저 계산하는 편이 안전합니다.

Catch2는 작은 게임 라이브러리에서 가장 빠르게 가치를 낸다

수식에 가까운 테스트를 작성하기 쉽다

Catch2의 장점은 테스트 코드가 자연스럽게 읽힌다는 점입니다. REQUIRE와 CHECK 중심의 단순한 문법, SECTION을 이용한 시나리오 분기, GENERATE 기반 입력 확장은 벡터·행렬·쿼터니언 검증과 궁합이 좋습니다. 별도의 픽스처 계층을 먼저 설계하지 않아도 작은 함수부터 검증할 수 있어 개인 개발자에게 특히 효율적입니다.

예를 들어 회전 행렬의 역행렬이 전치 행렬과 같은지 검사할 때는 각 성분의 완전 일치보다 허용 오차를 적용해야 합니다. Catch2의 근삿값 비교 기능을 쓰면 오차 범위를 테스트 의도로 드러낼 수 있고, 실패 메시지도 직접 만든 assert 매크로보다 읽기 쉽습니다. 다만 테스트 파일이 많아지면 헤더 사용 방식과 컴파일 단위 구성이 빌드 시간에 영향을 줄 수 있으므로 무작정 모든 파일에 무거운 헤더를 포함해서는 안 됩니다.

게임 개발의 결과를 외부에 발표하거나 포트폴리오로 공개할 계획이라면 테스트 리포트도 결과물의 일부가 됩니다. 업계 발표 문화의 맥락은 GDC에 관한 지식백과 설명에서도 확인할 수 있으며, 재현 가능한 벤치마크와 테스트 근거는 기술 프로젝트의 설득력을 높여 줍니다.

1. Vector2와 Vector3처럼 의존성이 적은 형식부터 테스트 대상을 정합니다.
2. 영벡터, 단위벡터, 매우 큰 값과 작은 값을 경계 입력으로 추가합니다.
3. 정확한 정수 결과와 부동소수점 근삿값 검사를 분리합니다.
4. CTest에 실행 파일을 등록해 로컬과 CI가 같은 명령을 사용하게 합니다.

Catch2를 피해야 하는 경우도 있다

수백 명이 참여하는 엔진 조직에서 이미 GoogleTest 기반 도구, 리포터, 사내 매크로가 정착했다면 Catch2로 바꾸는 이익은 작습니다. 반대로 실행 파일 크기와 컴파일 시간이 극도로 제한된 콘솔 도구나 자주 포함되는 헤더 전용 라이브러리라면 doctest가 더 가벼운 선택이 될 수 있습니다.

• 새로운 개인 프로젝트라면 Catch2를 우선 검토합니다.
• 기존 테스트 인프라가 있다면 문법 취향만으로 교체하지 않습니다.
• 빌드 시간이 핵심 지표라면 동일한 샘플로 Catch2와 doctest를 직접 측정합니다.

팀 규모와 빌드 환경에 따라 GoogleTest와 doctest가 앞선다

조직 개발에는 GoogleTest가 안정적이다

GoogleTest는 매개변수화 테스트, 타입 기반 테스트, 픽스처, 모킹 생태계가 잘 갖춰져 있어 규모가 큰 게임 엔진에 적합합니다. 렌더링 백엔드별 행렬 규칙이나 여러 숫자 형식을 동일한 테스트 계약으로 검증해야 한다면 구조화된 기능이 빛을 발합니다. CI 서비스와 IDE에서 결과를 인식하는 사례도 많아 신규 구성원이 익숙한 환경을 만날 가능성이 큽니다.

대신 간단한 수학 함수 하나를 검증할 때도 프로젝트 설정과 문법이 Catch2보다 장황하게 느껴질 수 있습니다. GoogleMock까지 끌어오면 의존성 구조가 커지므로 순수 함수가 대부분인 math 모듈에는 필요한 기능만 연결하는 편이 좋습니다. 게임 수학은 상태 객체보다 값 변환이 중심이어서 모든 테스트에 모킹이 필요한 것도 아닙니다.

• 추천: 여러 팀이 공통 엔진을 사용하고 테스트 규칙을 표준화해야 할 때
• 장점: 풍부한 기능, 익숙한 CI 출력, 대규모 테스트 분류
• 주의: 작은 라이브러리에 과도한 픽스처와 모킹 계층을 만들지 않기

컴파일 속도가 최우선이면 doctest가 유리하다

doctest는 가벼운 통합과 빠른 컴파일을 내세우며, 제품 코드 안에 테스트를 가까이 배치하는 방식도 지원합니다. 반복적으로 전체 빌드를 수행하는 게임 툴이나 헤더 중심의 템플릿 수학 라이브러리에서는 짧아진 피드백 시간이 기능 하나보다 더 큰 생산성 향상을 만들 수 있습니다.

다만 테스트를 제품 코드에 함께 넣을 때는 배포 빌드에서 비활성화되는 조건과 빌드 플래그를 명확히 관리해야 합니다. 또한 팀이 복잡한 매개변수 테스트와 표준화된 확장 도구를 요구한다면 GoogleTest 생태계가 더 편할 수 있습니다. 어떤 쪽이든 선택 전에 디버그·릴리스·콘솔 타깃을 각각 빌드해 증가 시간을 측정해야 합니다.

1. 대표적인 테스트 30~50개를 두 프레임워크로 작성합니다.
2. 클린 빌드와 한 파일 수정 후 증분 빌드를 따로 측정합니다.
3. 실패 로그를 주니어 개발자가 읽고 원인을 찾는 데 걸린 시간도 기록합니다.

프레임워크 벤치마크는 빈 프로젝트가 아니라 실제 Vector, Matrix, Quaternion 헤더를 포함한 상태에서 해야 합니다. 그래야 템플릿 인스턴스화 비용까지 선택에 반영됩니다.

Boost.Test를 습관처럼 고르면 테스트보다 환경 관리가 커진다

상황별 선택은 의존성 지도에서 시작한다

이미 Boost를 광범위하게 사용하는 레거시 엔진이라면 Boost.Test가 합리적입니다. 기존 패키지 공급 경로와 빌드 캐시를 그대로 활용할 수 있고, 데이터 기반 테스트와 다양한 로그 형식도 제공합니다. 그러나 새 포트폴리오 프로젝트에서 테스트 하나를 위해 Boost 의존성을 추가한다면 다운로드 용량, 버전 정합성, 플랫폼별 빌드 설정이 불필요한 부담이 될 가능성이 큽니다.

상황별 추천은 단순합니다. 혼자 만드는 범용 math 라이브러리는 Catch2, 대규모 스튜디오의 공용 엔진은 GoogleTest, 컴파일 피드백이 중요한 툴과 헤더 라이브러리는 doctest, Boost가 이미 기반인 오래된 프로젝트는 Boost.Test가 어울립니다. 예산을 기능 개발에만 배분하지 말고 테스트 작성과 CI 실행 시간까지 계획해야 하며, 자원 배분 관점은 계획예산 제도의 개념처럼 목표와 비용을 연결해서 생각하면 이해하기 쉽습니다.

• 개인 개발자: Catch2로 읽기 쉬운 테스트와 문서 역할을 함께 확보합니다.
• 엔진 팀: GoogleTest로 타입·플랫폼별 테스트 규약을 통일합니다.
• 빌드 민감 프로젝트: doctest를 실제 헤더 구성에서 측정한 뒤 채택합니다.
• Boost 기반 코드: 새 의존성을 늘리지 않는다는 전제에서 Boost.Test를 유지합니다.

수학 테스트에서 반복되는 세 가지 실수

첫 번째 실수는 모든 부동소수점 결과에 같은 epsilon을 쓰는 것입니다. 좌표의 크기와 연산 횟수가 달라지면 절대 오차와 상대 오차의 의미도 달라집니다. 월드 좌표처럼 값이 큰 경우에는 상대 오차를 검토하고, 정규화 결과에는 길이와 방향을 나눠 검사해야 합니다.

두 번째는 구현을 그대로 복사해 기대값을 계산하는 방식입니다. 테스트와 제품 코드가 같은 공식을 사용하면 같은 오류를 공유할 수 있습니다. 잘 알려진 항등식, 손으로 검산 가능한 축 회전, 독립적인 참조 구현을 이용하세요. 세 번째는 랜덤 테스트의 시드를 기록하지 않는 것입니다. 실패 입력과 시드를 로그에 남기지 않으면 CI에서 발견한 희귀 오류를 개발 PC에서 재현할 수 없습니다.

1. 고정 epsilon 하나로 모든 Vector와 Matrix 연산을 판정하지 않습니다.
2. 테스트 코드에서 제품 구현과 동일한 알고리즘을 반복하지 않습니다.
3. 난수 기반 속성 테스트는 시드와 최소 실패 입력을 반드시 출력합니다.
4. 프레임워크 기능 수만 비교하고 실제 프로젝트의 증분 빌드를 생략하지 않습니다.