라디안을 버려라: 각도를 '턴'으로 다루면 코드가 더 빨라지는 이유

수학 교실에서 배운 대로라면 사인과 코사인의 입력값은 당연히 라디안이어야 한다. 원 한 바퀴는 2π 라디안이고, 90도는 π/2로 환산해서 넣는 것이 상식처럼 굳어져 있다. 그런데 게임 엔진이나 그래픽 라이브러리의 실제 코드를 열어 보면, 이 '상식'이 오히려 불필요한 연산과 정밀도 손실을 만들어 낸다는 지적이 있다. 원문은 한때 유행했던 'π 대신 τ(타우)를 쓰자'는 논쟁을 언급하며, 사실 더 중요한 기회는 π를 τ로 바꾸는 것이 아니라 아예 없애 버리는 것이라고 주장한다.

곱했다가 다시 나누는 낭비

논지의 출발점은 매우 흔한 코드 패턴이다. 프로그래머는 이미 0에서 1 사이를 주기적으로 도는 값 h를 가지고 있는데, sin을 호출하기 위해 여기에 τ를 곱해 라디안으로 바꾼다. 원문 저자는 이것이 자신이 지어낸 예시가 아니라 Godot 엔진 소스에서 'tau'를 검색했을 때 실제로 수십 번 나오는 형태라고 밝힌다. 어떤 게임 엔진 코드를 열어도 사정은 비슷하다.

문제는 그다음이다. 호출된 sin 함수의 구현부를 보면, 널리 참조되는 AVX2 구현을 포함해 대부분의 고속 삼각함수 라이브러리가 진입 지점에서 입력값에 1.27323954473516 같은 상수를 곱하며 사실상 π를 다시 나눠 버린다. 결국 호출하는 쪽은 π를 곱하고, 라이브러리는 그 π를 곧바로 나눠 없앤다. 라디안으로 변환했다가 아무 이유 없이 되돌리는 왕복인 셈이다. 만약 양쪽이 처음부터 라디안을 쓰지 않고 h가 원래 있던 [0, 1] 구간을 그대로 넘겨받기로 합의했다면, 호출 측은 곱셈 한 번을 아끼고 라이브러리는 더 이해하기 쉽고 정확한 상수를 얻는다.

정밀도까지 나아지는 이유

'정확하다'는 표현에는 실질적인 근거가 있다. 0을 제외한 흔한 각도들은 라디안으로는 부동소수점에서 절대 정확하게 표현되지 않는다. 90도를 라디안으로 저장하려면 비트를 아무리 많이 써도 오차가 남는다. 반면 [0, 1] 구간에서 90도는 그냥 0.25이며, 이 값은 가수부 비트를 하나도 필요로 하지 않는다. 0.5(180도)도 마찬가지이고 0.75는 가수부 한 비트면 정확하다. 즉 이 구간은 연산량이 적을 뿐 아니라 실무에서 자주 등장하는 각도들을 더 조밀하고 정밀하게 담아낸다.

이 방식은 누군가 즉흥적으로 만들어 낸 것이 아니라 '턴(turn)'이라는 이름을 가진 정식 수학 개념이다. 0은 0도, 0.5는 180도, 1은 360도, 2는 720도에 대응한다. 사인과 코사인이 반드시 라디안을 입력으로 받아야 한다고 수학이 규정한 적은 없으므로, 각도를 턴으로 매개변수화하는 것은 문법적으로 아무 문제가 없다.

실무 적용은 상수 한 줄 수준

전환 방법은 놀랍도록 단순하다. 직접 만든 수학 라이브러리든 남의 것을 복사해 왔든, sin과 cos가 라디안 대신 턴을 받도록 내부 상수 하나만 손보면 된다. 기존 라디안 기반 코드를 유지해야 한다면, 새 턴 기반 함수에는 다른 이름을 붙이고 옛 라디안 함수는 그 새 함수를 호출하면서 도중에 τ로 나누도록 얇게 감싸 두면 된다. 몇 줄이면 끝나는 작업이다.

턴이 유일한 대안은 아니다. 원 한 바퀴를 [0, 2]로 보는 '반 턴(half turn)' 방식도 있는데, 다소 헷갈리지만 이미 이를 지원하는 라이브러리가 있다는 점이 매력이다. 대표적으로 CUDA의 sincospi 내장 함수는 입력에 π를 곱한 값, 즉 반 턴 단위로 사인과 코사인을 계산한다. 이런 플랫폼을 대상으로 한다면 라이브러리를 건드리지 않고도 지금 당장 π와 τ 상수를 코드에서 걷어낼 수 있다.

다만 이 주장을 받아들일 때 현실적인 한계도 함께 봐야 한다. 이미 라디안을 전제로 짜인 방대한 기존 코드베이스, 팀원들의 익숙함, 외부 API와 주고받는 각도 규약 등이 존재하기 때문에 전환 비용이 늘 '몇 줄'로 끝나지는 않는다. 성능 이득 역시 곱셈 한 번을 줄이는 것이어서, 삼각함수를 극도로 자주 호출하는 저수준 코드가 아니라면 체감이 크지 않을 수 있다. 그럼에도 저자가 여러 코드베이스를 라디안 없이 운영하며 불필요한 π와 τ가 사라져 코드가 더 잘 읽혔다고 말하는 대목은, 성능 이전에 가독성과 정밀도 측면에서 한 번쯤 검토해 볼 가치가 있다는 신호다. 라이브러리 내부는 어차피 라디안을 벗겨 냈다가 다시 씌우는 구조라, 턴이나 반 턴으로 통일하는 일은 대개 코드를 더 쓰는 것이 아니라 지우는 작업에 가깝다.