빌드 걸어놓고 커피 마시고 와도 안 끝나는 그 고통
C++로 개발해 본 분들은 다 아는 고통이 하나 있어요. 바로 컴파일 시간이에요. 코드 몇 줄 고치고 빌드 걸어놓고 커피 한 잔 마시고 와도 아직 돌고 있는 경험, 다들 있으시죠? 이 답답함의 큰 원인 중 하나가 표준 라이브러리(STL)인데요, 메손(Meson) 빌드 시스템을 만든 개발자 유시 파카넨이 'Pystd'라는 실험을 공개했어요. 표준 라이브러리랑 비슷한 기능을 하면서 컴파일 시간은 아주 일부만 잡아먹는 걸 직접 만들어 본 거예요.
왜 C++ 표준 라이브러리는 컴파일이 느릴까
이게 뭐냐면요, C++의 표준 라이브러리는 대부분 '헤더 파일'에 템플릿(template) 형태로 들어 있어요. 템플릿이란 int든 string이든 아무 타입에나 맞춰서 코드를 찍어내는 붕어빵 틀 같은 거예요. 편리하긴 한데, 문제는 이 틀이 컴파일할 때마다 매번 새로 펼쳐진다는 거예요. 게다가 <vector> 하나만 include해도 그게 내부적으로 수십 개의 다른 헤더를 줄줄이 끌고 들어와서, 컴파일러가 실제로 읽어야 하는 코드가 수만 줄로 불어나요. 파일마다 이걸 반복하니까 프로젝트가 커질수록 빌드가 기하급수적으로 느려지는 거죠.
Pystd는 뭘 다르게 했나
Pystd의 접근은 단순해요. '표준 라이브러리의 모든 기능을 완벽하게 지원하는 대신, 실제로 자주 쓰는 핵심 기능만 최소한으로 다시 구현하자'는 거예요. 불필요한 헤더 의존성을 확 걷어내고, 무거운 템플릿 사용을 줄이니까 컴파일러가 씹어야 할 양이 대폭 줄어들어요. 그 결과 비슷한 일을 하는데도 컴파일 시간이 원래의 몇 분의 일밖에 안 걸리는 거예요. 물론 공짜는 아니에요. 표준 라이브러리만큼 검증되지도, 기능이 풍부하지도, 극한까지 최적화되지도 않았죠. 이건 '무엇을 포기하면 컴파일이 얼마나 빨라지는가'를 보여주는 실험에 가까워요.
이런 고민, 나만 하는 게 아니었네
사실 C++ 컴파일 시간과의 전쟁은 업계의 오랜 숙제예요. 게임 회사 EA는 자체 표준 라이브러리인 EASTL을 만들었고, 구글의 Abseil이나 페이스북의 Folly도 비슷한 맥락에서 나온 라이브러리들이에요. 빌드 기법 쪽에서도 여러 cpp 파일을 하나로 합쳐서 컴파일하는 유니티 빌드(unity build), 자주 쓰는 헤더를 미리 컴파일해두는 프리컴파일드 헤더(PCH) 같은 방법들이 오래 쓰여 왔고요. 그리고 근본적인 해결책으로 C++20에 도입된 '모듈(modules)'이 있어요. 헤더를 매번 다시 파싱하는 대신 한 번 컴파일한 결과를 재사용하는 방식이라, 제대로 자리 잡으면 이 문제를 크게 완화해 줄 거라 기대받고 있어요. Pystd는 그 모듈이 완전히 정착하기 전까지, 다른 각도에서 같은 문제를 건드려 본 셈이에요.
한국 개발자에게 주는 시사점
C++를 쓰는 팀이라면 빌드 시간은 곧 개발 생산성이자 돈이에요. 하루에도 수십 번 빌드하는데 매번 몇 분씩 날아가면, 팀 전체로 보면 어마어마한 시간이 증발하거든요. Pystd를 그대로 프로덕션에 가져다 쓰라는 얘기는 아니에요. 다만 '내 프로젝트의 컴파일이 왜 느린지'를 헤더 의존성과 템플릿 관점에서 들여다보는 계기로 삼기엔 아주 좋아요. include 정리, 전방 선언(forward declaration) 활용, PCH 도입, 나아가 C++20 모듈 실험까지, 오늘 당장 빌드 시간을 줄일 방법은 생각보다 많아요.
마무리
정리하면 Pystd는 '편리함을 조금 포기하면 컴파일 속도를 이만큼 되찾을 수 있다'는 걸 실증한 프로젝트예요. 표준 라이브러리는 당연히 좋지만, 그 편리함에 숨은 비용도 한 번쯤 계산해 볼 만하죠. 여러분 프로젝트의 빌드 시간, 마지막으로 진지하게 측정해 본 게 언제인가요?
🔗 출처: Hacker News