현대 컴파일러가 전통적인 파이프라인 대신 질의 기반 모델로 이동한 이유와, 이에 대한 교육 자료가 더 필요하다는 주장.
2026년 2월 19일 · 3분 읽기 · 584단어
노트
Paged Out 매거진에 글을 써 달라는 초대를 받았습니다. 이 글을 멋진 HD 컬러로, 재미있는 다이어그램과 함께 보고 싶다면 8호를 확인해 보세요. 꽤 괜찮습니다.
지난 세기의 컴파일러 교과서(대작)를 아무거나 펼쳐 보면 거의 비슷한 아키텍처의 변형을 발견할 수 있습니다. 컴파일러의 각 패스가 전체 코드를 대상으로 실행된 뒤, 그 출력이 다음 패스로 전달되는 파이프라인 말이죠. 그리고 파이프라인은 첫 번째 오류에서 멈추며, 그때까지 완료된 작업은 모두 버려집니다.
반면, 이 천년대(2000년대 이후)에 작성된 컴파일러를 아무거나 뜯어보면 그런 구조는 거의 찾아보기 어렵습니다. 컴파일러 아키텍처에는 조용한 변화가 일어났습니다. 현대 컴파일러는 거의 예외 없이 질의(query) 기반 모델을 사용합니다.
각 패스를 끝까지 실행하는 대신, 컴파일은 서로 의존하는 일련의 질의들로 구조화됩니다. 이제 렉싱을 호출하고 그다음 파싱을 호출하는 식이 아닙니다. 대신 컴파일러에게 이렇게 묻습니다. “이 파일의 파싱된 구문 트리(parsed syntax tree)는 어떻게 생겼지?” 그러면 컴파일러는 그 질문에 답하는 과정의 일부로 파일을 렉싱합니다. 컴파일은 더 이상 첫 번째 오류에서 멈추지 않습니다. 한 질의에서 오류가 나더라도 다른 질의를 막지 않기 때문에, 여러 오류를 모으거나 심지어 코드의 관련 없는 부분에 있는 오류는 무시할 수도 있습니다.
질의 기반 컴파일은 두 가지 요인에서 동기를 얻습니다. **증분 재사용(incremental reuse)**과 **통합 개발 환경(IDE)**입니다. 언어가 더 많은 기능을 갖추게 될수록, 이를 따라잡기 위해 컴파일러가 해야 할 일도 늘어났습니다. 이제는 컴파일러가 증분적으로 동작하는 것이 점점 더 중요해지고 있습니다. 즉, 지난 컴파일 이후 바뀐 코드를 찾아내어 바뀐 부분만 다시 컴파일해야 합니다. 질의 모델은 각 질의가 어떤 질의들에 의존하는지 추적하기 때문에 이를 돕습니다. 어떤 질의가 의존하는 대상들이 모두 변하지 않았다면, 그 질의의 출력도 변하지 않았다고 볼 수 있고, 캐시된 값을 재사용할 수 있습니다.
IDE의 인기는 계속 커지고 있습니다. 특히 언어 서버 프로토콜(LSP)이 등장하면서(좋아하는 편집기가 nano만 아니라면요; nano를 좋아한다면 정말 미안합니다) 좋아하는 편집기에서도 IDE 기능을 쓸 수 있게 되었습니다. 이렇게 널리 사용되면서, 우리가 컴파일러를 사용하는 방식도 바뀌었습니다. 예전보다 훨씬 더 세밀한 단위로 사용합니다. 프로그램 전체의 타입을 알고 싶은 게 아니라, 지금 내가 보고 있는 함수의 타입만 알고 싶습니다. 프로그램의 모든 변수 정의가 필요하지도 않습니다. 커서 아래에 있는 변수의 정의만 있으면 됩니다.
질의는 여기서도 도움이 됩니다. 단일 함수, 심지어 단일 변수만 대상으로 동작하는 질의를 구성할 수 있고, 그러한 질의는 그 함수에 해당하는 질의들에만 의존하게 만들 수 있습니다. 우리 함수에 대해 최소한의 질의 집합만 실행하면 더 빠르게 답을 얻을 수 있습니다. IDE에서는 사용자가 컴파일러의 응답을 기다리고 있기 때문에, 빠를수록 좋습니다. 질의는 답을 얻는 데 필요한 최소한의 작업만 수행하게 해 줍니다.
질의 기반 컴파일러는 지금 대세입니다. Rust, Swift, Kotlin, Haskell, Clang 모두 컴파일러를 질의 중심으로 구조화합니다. 하지만 이런 새롭고 최적화된 증분 컴파일러가 어떻게 동작하는지 배우고 싶어도, 자료를 찾기란 쉽지 않습니다. 이 글을 행동 촉구로 받아들여 주세요. 교수님을 설득하고, 주변의 PL(프로그래밍 언어) 열정가들을 들볶고, 대표자에게 연락하세요. 질의 기반 컴파일러에 대한 교육 자료가 더 필요합니다.
팁
질의 기반 컴파일러를 만드는 방법을 배우고 싶다면 제 Making a Language 시리즈를 확인해 보세요. 이 시리즈는 질의 기반 컴파일러를 구축하고, 이를 사용해 언어 서버를 구현하는 것으로 마무리됩니다.
연락하기 · thunderseethe · Email: