기술의 본질을 꿰뚫는 2만 줄의 코드

안녕하세요. 풀링포레스트 CTO 송찬영입니다.

최근 개발자 커뮤니티에서 조지 핫츠(George Hotz)가 쓴 'tinygrad 5년'이라는 글이 꽤 화제가 되었습니다. 혹시 보셨나요? 단순히 새로운 라이브러리 소개나 기술 자랑이 아니더군요. 거기엔 우리 엔지니어들이 뼛속 깊이 고민해봐야 할 '소프트웨어의 본질'에 대한 통찰이 담겨 있었습니다. 오늘은 이 글을 빌려, 제가 CTO로서 늘 고민하는 엔지니어링 철학에 대해 이야기해볼까 합니다.

왜 하드웨어가 아니라 소프트웨어인가

조지 핫츠는 tinygrad라는 딥러닝 프레임워크를 5년 동안 개발했습니다. 그런데 놀랍게도 이 프로젝트의 코드베이스는 테스트 코드를 제외하면 고작 18,935줄입니다. 6명의 팀원이 5년이라는 시간을 쏟아부은 결과물치고는 너무 적어 보일 수도 있습니다. 하지만 그는 이렇게 단언합니다. "이것이 NVIDIA와 경쟁하기 위한 올바른 과정이다."라고요.

많은 기업들이 자체 AI 칩을 만들겠다고 뛰어듭니다. 칩을 설계하고, 비싼 비용을 들여 테이프 아웃(Tape-out)을 하죠. 하지만 핫츠는 이를 "바보 같은 짓"이라고 일갈합니다. 구글과 NVIDIA가 시장을 지배하는 이유는 칩의 성능 그 자체가 아니라, 그 칩을 완벽하게 구동시키는 '소프트웨어 스택'을 가지고 있기 때문이라는 겁니다. AMD나 테슬라, 아마존도 훌륭한 칩을 만들었지만, 실제 훈련 현장에서 NVIDIA를 압도하지 못하는 이유가 바로 여기에 있습니다.

저 역시 풀링포레스트에서 비슷한 경험을 자주 합니다. 우리는 종종 문제 해결의 핵심을 도구(Tool)나 인프라 스펙에서 찾으려 합니다. "서버 사양이 낮아서 그래", "새로운 라이브러리를 도입하면 해결될 거야"라고 말이죠. 하지만 진짜 병목은 하드웨어가 아니라, 그 하드웨어를 제어하는 소프트웨어의 효율성, 그리고 그 소프트웨어를 만드는 우리의 사고방식에 있을 때가 훨씬 많습니다.

복잡성이라는 괴물

핫츠의 글에서 가장 인상 깊었던 부분은 소프트웨어의 '비만'에 대한 지적이었습니다.

"모든 코드베이스는 다른 부분의 문제들을 우회(workaround)하는 코드를 가지고 있다... 나는 소프트웨어 코드의 98%가 기본적으로 이런 것이라고 생각한다."

솔직히 이 문장을 읽고 등골이 서늘했습니다. 우리네 레거시 코드를 떠올려보세요. 비즈니스 로직은 몇 줄 안 되는데, 온갖 라이브러리의 호환성을 맞추기 위해, 혹은 예전 버전의 버그를 피하기 위해 덕지덕지 붙은 '접착제 코드(Glue code)'들이 얼마나 많은가요?

LLM 서버 하나를 띄우기 위해 우리는 수백만 줄의 코드를 의존성으로 가져옵니다. 하지만 tinygrad는 불필요한 추상화와 호환성 유지 코드를 걷어내고, 오직 'GPU에서 모델을 실행한다'는 본질에만 집중하여 코드를 1000분의 1로 줄였습니다. 심지어 AMD GPU를 구동하기 위해 LLVM 의존성마저 제거하고 드라이버부터 런타임까지 직접, 아주 작게 만들고 있죠.

이것은 단순히 코드를 짧게 짜는 'Code Golf' 놀이가 아닙니다. "가장 좋은 부품은 부품이 없는 것이다(The best part is no part)"라는 일론 머스크 식의 극단적 효율화를 소프트웨어에 적용한 것이죠.

조직도 코드와 같다

재미있는 점은 이러한 철학이 조직 운영에도 그대로 적용된다는 것입니다. 핫츠는 자신의 회사를 '고급 요리사가 분해(deconstruct)한 요리'처럼 운영한다고 말합니다. 불필요한 관리 조직이나 복잡한 보고 체계 없이, 깃허브와 디스코드만으로 소통하며, 주 1회 회의를 제외하면 모두가 자율적으로 코드에 기여합니다.

저 또한 CTO로서 늘 경계하는 것이 조직의 '관료화'입니다. 팀이 커지면 필연적으로 소통 비용이 늘어나고, 코드보다는 문서를 만드는 시간이 길어집니다. "왜 이 기능을 개발하죠?"라는 질문에 "상위 기획서에 있으니까요"라거나 "다른 팀과 스펙을 맞추기 위해서요"라는 대답이 나오기 시작하면 위험 신호입니다.

코드의 군더더기를 걷어내듯, 조직의 프로세스에서도 군더더기를 걷어내야 합니다. 개발자가 코드 작성보다 회의 준비에 더 많은 시간을 쓰고 있다면, 그건 리더인 제 책임이겠죠. 우리의 목표는 '관리를 위한 관리'가 아니라, 고객에게 가치를 전달하는 '제품'을 만드는 것이니까요.

기술 주권을 가진다는 것

결국 tinygrad가 5년 동안 2만 줄의 코드로 증명하려는 것은 '기술 주권(Sovereign Software)'입니다. 남들이 만들어놓은 거대한 블랙박스(NVIDIA CUDA 등)에 의존하지 않고, 바닥부터 끝까지 완전히 이해하고 통제할 수 있는 기술을 갖는 것. 그것이 진정한 경쟁력이라는 메시지입니다.

물론 모든 회사가 핫츠처럼 바닥부터 다시 짤 수는 없습니다. 우리는 비즈니스를 해야 하니까요. 하지만 적어도 우리가 사용하는 기술 스택이 '왜' 필요한지, 혹시 불필요한 복잡성 속에 매몰되어 있는 건 아닌지 의심해볼 필요는 있습니다.

개발자 여러분, 막막할 때가 있을 겁니다. 남들은 벌써 저만큼 앞서가는 것 같고, 내 코드는 초라해 보일 때가 있죠. 하지만 화려한 겉모습이나 유행하는 프레임워크 이름에 현혹되지 마세요. 1만 줄이든 100줄이든, 문제의 본질을 정확히 타격하는 코드가 가장 아름답고 강력한 코드입니다.

때로는 무거운 갑옷을 벗어 던지고, 아주 작고 날카로운 칼 하나를 가는 시간이 필요합니다. 그 5년의 시간이 결국 '특이점'을 앞당길 테니까요.

오늘도 복잡함과 싸우며 본질을 찾고 계신 여러분을 응원합니다.

감사합니다.