엔지니어로서 우리는 종종 도구를 ‘당연한 것’으로 받아들입니다. float 타입이 IEEE 754 표준을 어떻게 따르는지 매번 고민하지 않는 것처럼, 복소수(Complex Numbers) 역시 FFT나 임피던스 계산을 위한 도구 정도로 치부하곤 하죠.

하지만 최근 Hacker News와 수학 블로그계를 달구고 있는 논쟁 하나가 제 눈길을 끌었습니다. 바로 “복소수의 본질적인 구조는 무엇인가?” 라는 질문입니다. 이 논쟁은 단순한 수학적 정의 싸움이 아닙니다. 이것은 우리가 소프트웨어 아키텍처에서 매일 마주하는 ‘인터페이스 vs 구현체’ 의 문제와 소름 돋을 정도로 닮아 있습니다.

오늘은 이 수학적 논쟁을 엔지니어링 관점에서 뜯어보고, 우리가 설계하는 시스템의 ‘본질’에 대해 이야기해 보려 합니다.

1. 복소수를 바라보는 4가지 시선

원문 저자 Joel David Hamkins 교수는 수학자들이 복소수($\mathbb{C}$)를 바라보는 관점이 크게 네 가지로 나뉜다고 설명합니다. 이를 개발자 용어로 번역해 보겠습니다.

• Analytic (해석적 관점): $\mathbb{C}$는 실수($\mathbb{R}$)의 확장팩입니다. class Complex extends Real 같은 느낌이죠. 여기서 $i$와 $-i$는 대수적으로 구분이 불가능합니다.
• Smooth (위상적 관점): 위상(Topology)이 핵심입니다. 극한과 연속성이 정의된 공간이죠. 사실상 해석적 관점과 구조적으로 동일합니다.
• Rigid (경직된 관점): 우리가 흔히 아는 ‘복소평면’입니다. struct { x: float, y: float } 처럼 좌표가 핵심입니다. 여기서는 실수부와 허수부가 명확히 구분되므로 $i$는 $(0, 1)$이라는 고유한 값을 가집니다.
• Algebraic (대수적 관점): 가장 추상적인 레벨입니다. 그저 “대수적으로 닫혀있는 특성 0의 체(Field)“일 뿐입니다. 여기서는 위상도, 좌표도 없습니다. 심지어 $\pi$와 $e$조차 구분할 수 없는 카오스 상태입니다.

재미있는 점은 대다수의 엔지니어와 물리학자들은 Rigid(복소평면) 관점을 선호한다는 것입니다. Hacker News 댓글에서도 “복소수는 결국 2D 벡터에 회전 연산을 얹은 것 아니냐”는 의견이 지배적입니다. 우리에게 중요한 건 ‘계산 가능한 좌표’니까요.

2. $i$와 $-i$의 식별 불가능성: 인터페이스의 함정

이 글의 핵심 쟁점은 “$i$와 $-i$를 구분할 수 있는가?” 입니다.

순수 대수적 관점(Analytic/Algebraic)에서 $i$와 $-i$는 완벽하게 대칭적입니다. $x^2 + 1 = 0$의 두 근일 뿐, 어느 것이 ‘진짜’ $i$인지 꼬리표가 붙어있지 않습니다. 켤레복소수(Complex Conjugation)라는 오토모피즘(Automorphism)을 통해 서로 뒤바꿔도 수학적 구조는 전혀 깨지지 않습니다.

이것은 마치 Load Balancer 뒤에 있는 두 개의 무상태(Stateless) 서버 와 같습니다. 클라이언트(수학적 연산) 입장에서는 서버 A($i$)로 요청을 보내든 서버 B($-i$)로 보내든 결과가 똑같습니다. 외부에서 볼 때 둘은 식별 불가능(Indiscernible)합니다.

하지만 Hamkins 교수는 여기서 날카로운 지적을 합니다.

“우리가 복소수를 구성(Construct) 할 때는 반드시 대칭을 깨야 한다.”

우리가 코드로 복소수를 구현한다고 상상해 봅시다. struct Complex { double real; double imag; }를 정의하는 순간, 우리는 이미 $(0, 1)$을 $i$로, $(0, -1)$을 $-i$로 고정(Rigidify)해버린 것입니다. 즉, 대칭적인 인터페이스를 제공하기 위해, 내부 구현에서는 비대칭적인 선택을 강제해야 한다는 모순이 발생합니다.

3. 구조주의와 ‘추상화 누수’

철학적 구조주의(Structuralism)에서는 “대상이 무엇(what)인가”보다 “어떤 역할(role)을 하는가”가 중요하다고 말합니다. 이 관점에서 $i$와 $-i$는 역할이 같으므로 같은 대상이어야 합니다. 하지만 그들은 분명히 서로 다른 두 숫자입니다.

저는 이 부분이 소프트웨어의 추상화 누수(Leaky Abstraction) 와 연결된다고 봅니다.

• 우리는 완벽한 추상화(순수 대수적 관점)를 꿈꿉니다. “구현 디테일은 몰라도 돼, 인터페이스만 맞춰.”
• 하지만 실제로 그 객체를 생성(Instantiate)하려면, 구체적인 메모리 주소와 비트 패턴(Rigid 관점)이 필요합니다.
• Hamkins 교수의 주장처럼, “모든 구조는 더 풍부하고 경직된(Rigid) 맥락에서 파생된 후, 일부 정보를 망각(Forget)함으로써 얻어진다” 는 것입니다.

즉, 우리가 우아하다고 느끼는 추상화된 라이브러리들도, 까보면 결국 지저분한 하드웨어 의존성과 ‘매직 넘버’들 위에서 돌아가고 있다는 사실을 상기시킵니다.

4. Hacker News의 반응: 실용주의 vs 순수주의

Hacker News의 댓글 타래는 이 주제에 대한 엔지니어들의 시각을 적나라하게 보여줍니다.

• 물리학의 관점: 한 유저는 “슈뢰딩거 방정식을 봐라. 복소수는 단순한 도구가 아니라 자연의 본질이다”라고 주장합니다. 반면 다른 유저는 “그저 2개의 연립 방정식으로 풀 수 있는 걸 편하게 묶은 것뿐”이라고 반박합니다. 이는 마치 “OOP가 본질인가, 아니면 절차적 프로그래밍의 문법적 설탕인가?”라는 논쟁과 비슷합니다.
• 좌표 주의자들: “나는 $a+bi$라는 표기가 싫다. 그냥 $(a,b)$라고 써라.” 많은 엔지니어들이 복소수를 2D 벡터 공간의 특수한 형태로 이해하길 원합니다. 추상적인 성질보다는 데이터 구조 로서의 명확함을 선호하는 것이죠.
• Hamkins의 답변: 저자는 이런 논쟁에 대해 “어느 하나가 정답이 아니다”라고 말합니다. Rigid한 구현이 있어야 추상적인 개념을 빌드업할 수 있고, 추상적인 개념이 있어야 일반화된 이론을 펼칠 수 있기 때문입니다.

5. 결론: 엔지니어에게 주는 시사점

이 긴 수학적/철학적 탐구 끝에 제가 내린 결론은 다음과 같습니다.

1. 구현 없는 추상화는 없다: 아무리 우아한 인터페이스(API)라도, 그 아래에는 구체적이고 못생긴 구현(Implementation)이 존재해야 합니다. $i$와 $-i$를 구분할 수 없는 순수한 세계를 만들기 위해, 우리는 역설적으로 그 둘을 구분하는 좌표계를 먼저 만들어야 합니다.
2. 맥락에 맞는 모델을 선택하라: FFT를 짤 때는 Rigid한 관점(좌표)이 필요하고, 대수학적 증명을 할 때는 Algebraic 관점이 필요합니다. “복소수는 원래 이런 거야”라고 고집하는 것은, “모든 코드는 함수형이어야 해”라고 고집하는 것만큼이나 위험합니다.

결국 복소수의 본질에 대한 논쟁은, 우리가 시스템을 설계할 때 “어디까지 추상화하고, 어디까지 구체화할 것인가” 를 결정하는 과정과 맞닿아 있습니다. 수학자들은 아직도 싸우고 있지만, 우리 엔지니어들은 상황에 맞춰 유연하게 도구를 선택하는 지혜가 필요합니다.

여러분의 코드 베이스에서 ‘복소수’ 같은 존재는 무엇인가요? 너무 추상화되어 본질을 잃어버린 모듈은 없나요? 한 번쯤 고민해 볼 만한 밤입니다.