Hacker News 2026.04.23 29

tanh를 직접 근사해본다고? 딥러닝 엔지니어가 알아두면 좋은 수치계산 이야기

왜 갑자기 tanh 근사를 이야기하는가

딥러닝을 조금이라도 해본 분이라면 tanh라는 함수를 한 번쯤 본 적 있을 거예요. 하이퍼볼릭 탄젠트라고 부르는데요, 입력값을 -1과 1 사이로 압축해주는 활성화 함수예요. LSTM, RNN 게이트, 그리고 최근에는 GELU 근사나 정규화 레이어 내부에서도 계속 등장해요. 그런데 이 함수, 실제로 CPU나 GPU에서 계산하려면 생각보다 비싸요. 정의식 자체가 (e^x - e^-x) / (e^x + e^-x)라서, 지수함수 두 번과 나눗셈이 들어가거든요.

이 블로그 글은 "그러면 tanh를 어떻게 하면 더 빠르고 충분히 정확하게 계산할 수 있을까?"를 실제로 파고든 글이에요. 단순히 라이브러리의 std::tanh를 쓰는 걸 넘어서, 직접 근사 함수를 설계하고 정확도와 속도를 재어보는 과정을 보여줘요. 딥러닝 프레임워크를 만드는 입장이거나, 임베디드에서 추론을 돌려야 하는 엔지니어에게는 아주 실용적인 주제예요.

근사의 기본 아이디어

tanh는 대칭적이고(홀함수), 0 근처에서는 x에 가깝고, |x|가 커지면 ±1로 수렴하는 S자 곡선이에요. 이런 특성을 이용하면 여러 방법으로 근사할 수 있어요.

첫 번째는 테일러 급수예요. tanh(x) ≈ x - x³/3 + 2x⁵/15 - ...처럼 다항식으로 펼치는 방법인데, 0 근처에선 정확하지만 x가 조금만 커져도 오차가 폭발해요. 그래서 실전에서는 쓰기 어려워요.

두 번째는 파데 근사(Padé approximant). 분자와 분모를 모두 다항식으로 쓰는 유리함수 형태예요. 예를 들어 tanh(x) ≈ x(27 + x²)/(27 + 9x²) 같은 식인데, 테일러보다 훨씬 넓은 범위에서 정확해요. 나눗셈이 한 번 들어가긴 하지만 지수함수보다 싸요.

세 번째는 구간 분할(piecewise) 근사. x가 아주 크면 그냥 1로 잘라내고(saturation), 중간 구간만 다항식이나 룩업 테이블로 처리하는 방식이에요. 하드웨어 구현에서 자주 쓰는 방법이에요.

네 번째는 지수함수 쪽 근사 재활용. tanh(x) = 1 - 2/(e^(2x) + 1) 같은 항등식을 쓰고, 여기서 e^(2x)를 빠른 exp 근사로 처리하는 거예요. exp는 이미 최적화된 구현이 많기 때문에 이 방식도 경쟁력이 있어요.

정확도와 속도의 트레이드오프

이 글의 진짜 가치는 이 방법들을 한 표에서 비교한다는 점이에요. 최대 절대 오차, 평균 오차, 사이클당 처리 시간을 재보면, "가장 정확한 근사"와 "가장 빠른 근사"는 절대 같은 방법이 아니에요. 예를 들어 0.001 수준의 오차를 허용하면 2~3차 유리함수로 충분하고, 이 경우 표준 라이브러리 대비 2~3배 빠른 결과가 나와요. 반대로 1e-7 수준의 정확도를 요구하면 고차 다항식이나 룩업 테이블이 필요하고, 속도 이점은 많이 줄어들어요.

여기서 중요한 포인트는, 딥러닝 추론에서는 대부분 고정밀도가 필요 없다는 점이에요. FP16이나 BF16으로도 모델 정확도가 거의 유지되는 마당에, 활성화 함수를 1e-3 수준으로 근사해도 최종 예측에는 거의 영향이 없어요. 그래서 프레임워크들은 기본적으로 근사 버전 tanh를 쓰고 있어요. 파이토치의 tanh, XLA의 구현, GELU의 'approximate=tanh' 모드가 모두 이런 트릭을 내부에 숨겨두고 있죠.

업계에서 비슷한 사례

이런 수치 근사 엔지니어링은 눈에 잘 안 띄지만 AI 인프라의 기반이에요. 인텔의 SVML, AMD의 LibM, 엔비디아의 CUDA math 라이브러리, 그리고 최근엔 sleef 같은 오픈소스 SIMD 수학 라이브러리가 이 영역의 경쟁자들이에요. ARM용 모바일 추론 엔진인 XNNPACK이나 TFLite 델리게이트도 자체 tanh/sigmoid/GELU 근사를 넣어두고 있고요.

한국 개발자에게 시사하는 것

대부분의 애플리케이션 개발자에게는 "그런 게 있구나" 수준이면 충분해요. 하지만 온디바이스 AI, 엣지 추론, 모델 최적화를 다룬다면 이야기가 달라져요. 스마트폰이나 IoT 디바이스에서 모델을 돌릴 때, 활성화 함수 근사 품질이 배터리 수명과 직결되거든요. 또 요즘 자체 NPU를 설계하는 국내 팹리스(리벨리온, 퓨리오사AI, 사피온)들도 이런 비선형 연산을 하드웨어로 구현할지, 룩업 테이블로 구현할지 매번 결정해야 해요.

그리고 이 글이 주는 더 큰 교훈은, "라이브러리는 블랙박스"라는 전제를 벗어던져야 진짜 최적화가 시작된다는 점이에요. 표준 함수 하나를 뜯어보는 것만으로도 시스템 성능이 크게 달라질 수 있다는 걸 보여주는 좋은 예제예요.