인턴 시작일에 안내받은 개발론

나는 언제나 미시적인 최적화를 LLM을 쓰든, 직접 하든 시도했다. 예를 들면 최근 LibTTAK같은 도구를 만들 때도 락프리, 성능 최적화 등을 고려하며 개발을 진행했었다. 그러나 내가 절대적이라고 생각한 것을 곧바로 반박하는 사례는 이번 인턴을 하는 회사의 프로덕션이었다.

무어의 법칙: 지금의 최적화는 내일의 부채이다

인프라코어팀의 팀장님은 과도한 최적화에 대해 무어의 법칙을 근거로 들어 반박하셨다. 시대가 지날 수록 칩의 집적도는 올라가고, 과거에 공을 들인 최적화가 나중에는 이해하기만 어렵고 딱히 필요없는 코드가 될 수 있단 언급이었다. 그리고 시대의 로직은 후에는 관리하기 힘든 코드이고, 나아가선 이식성을 저해하는 잘못된 유혹이라고 말씀도 하셨다. 물론 나와 같이 최적화를 성배처럼 생각하던 사람에게는 충격이었지만, 이를 컴퓨터 소프트웨어의 역사 관점에서 보면 이해가 된다. 동적 할당은 초기 컴퓨터에서 가급적 배제해야 하는 비싼 연산이었다. 프로그래머들은 스택 영역을 아레나로 사용하며 어떻게든 정적으로 모든 메모리 공간을 사용하려 하였다. 또한 그 때의 메모리 크기 한계로 힙 영역 할당을 자꾸 하면 단편화는 필연이었다. 하지만 현대에는 Java, Python 3, Go…수많은 똑똑한 언어들은 동적 할당을 마구마구 사용한다. 더구나, 과거라면 군더더기라고 여겨졌을 안전 로직이 잔뜩 붙은 Zig, Rust같은 언어들은 산업계를 선도하는 슈퍼 루키이다.

그러한 현대에서 레거시라고 불리는 C 코드들은 대부분 연산량을 수학적으로 줄이기 위한 ‘어려운 코드’들이다. 이러한 종류의 코드들에 대해서 비판사항이 되는 것은 현재 흔하지만,80년대에 작성될 당시에는 그렇게 하지 않으면 처리량이 폭락했다는 뜻이다.

그렇다면 내가 LibTTAK에서 진행한 라틴직교방진을 이용한 락프리 설계나, 고전 수학의 증승개방법이나 다원술 인용, 오일러의 연구 인용과 같은 나조차 이해하기 힘들어지는 것들은 미래에는 그냥 RWLock과 Mutex를 마구 바르고, 복잡한 연산을 그냥 필산하듯 냅다 써도 그 공간복잡도와 시간복잡도나, 우리가 짠 것이나 어차피 눈 깜짝할 새 지나가는 연산일지도 모르는 셈이다.

나의 관점: 소신이라면 이건 완전히 틀린 것은 아니다

서비스 로직에 집중해야 하는 실무적인 상황에선 학구적인 자세나 스스로 AI 코딩을 위한 붕어빵 도구를 만드는 것이 아니다. 이런 상황에선 이식성이 최우선이며, 하다 못해 고객사가 칭다오에 있고 Loongson 64를 쓴다고 해도 잘 빌드되고 예측 가능하게 동작해야 한다. 상대의 희소한 버그에 대해 인력을 투입해 빌드 옵션을 덕지덕지 바르는 것은 딱히 똑똑하지 않다.

그렇지만 학구적인 목적으로 시험해 본다면, 원래 200ms 짜리가 100ms로 줄던 것이 20ms에서 15ms로 줄지라도 어느 정도 하드웨어 아키텍처의 변경에 영향이 적은 최적화들이 분명히 제자리에 있다. 대체로 큰 수의 산술 연산, 제곱근 등의 부분이다. 이러한 부분에서는 아주 예전에 개발된 빠른 역제곱근 등도 여전히 유효하다. 만약 당신이 돈이 없는 개인이라면 이런 차이는 더 유효하다. 회사의 서버는 정말로 무어의 법칙을 충실하게 따라가며, 회사 측에서도 회사 서버의 RAM은 테라바이트, 스토리지는 페타바이트 단위라고 말했다. 그러나 내 서버의 RAM은 8GB이며, 스토리지는 1TB이다. 남는 서버는 RAM 16GB, 512GB 스토리지를 쓴다. 사실상 개인이라는 제약 때문에 00년대 서버 수준의 스펙에서 개발하고 있는 셈이다. 이런 환경에서는 첨단 기술들을 쓰고 싶어도 쓰지 못하며, 여기서 포기하면 내 GitHub는 비고 오픈소스 활동은 접게 된다. 그러나 이런 부분들을 탐구하고 선제적으로 적용한다면 실무와는 다른 결의 코드도 탐미하며 오픈 소스 활동 역시 할 수가 있어진다.

그럼 어떻게 하지?

모든 것을 자본의 논리로만 보면 개발이 재미없어진다. 그러나, 자본의 논리를 무시하고 자기 개발을 회사에서 짜는 돈 버는 코드보다 우선할 수도 없는 노릇이다. 다른 20대 중반의 인턴들은 어떤 생각을 하며 취업 준비나 인턴십을 하는지는 모르겠지만, 코드가 미학이라고 믿는 신념을 굳이 코드는 ROI, 자본 등에서만 가치가 있다고 묶어 버려야 할까? 그냥 둘이 다르다고 생각하고 적당히 잘 처리하면 된다고 생각한다.