글램 컴파일러, Erlang 소스 대신 추상 형식 사용으로 개선
Gleam doesn't compile to Erlang source anymore
Gleam v1.19.0이 출시되었으며, 컴파일 방식이 기존 Erlang 소스 코드 생성에서 중간 표현인 'Erlang 추상 형식'을 사용하는 방식으로 근본적으로 변경되었습니다.
컴파일 방식을 근본적으로 개선하여 빌드 시간을 크게 단축시키고, 디버깅 시 위치 메타데이터의 정확도를 높여 개발 생산성과 안정성을 동시에 향상시켜요.
- 이번 변화로 Gleam 프로젝트의 빌드 시간이 크게 단축되고, BEAM 크래시 보고서 등에서 라인 번호와 같은 디버깅 메타데이터 정확도가 획기적으로 향상되었습니다.
- JavaScript 패턴 매칭 및 리스트 처리 최적화가 이루어졌고, TypeScript에서도 타입 정보 손실을 막는 API 오버로드가 추가되어 전반적인 안정성이 높아졌습니다.
- 개발팀은 BEAM 바이트코드 직접 생성을 포기했는데, 이는 가상 머신의 지속적인 진화와 복잡한 내부 최적화를 유지하는 것이 더 큰 부담이라 판단했기 때문입니다.
Gleam은 컴파일 방식을 근본적으로 변경하여 기존의 Erlang 소스 코드 생성 방식에서 벗어나 'Erlang 추상 형식(abstract forms)'을 사용합니다. 이 중간 표현은 Erlang 컴파일러가 사용하는 메타데이터 주석이 달린 트리 구조이며, 이를 통해 생성된 코드는 Erlang의 외부 항 형식 바이너리 인코딩으로 직접 로드할 수 있어 컴파일 과정의 효율성을 높입니다.
이 새로운 코드 생성기는 컴파일러 성능을 개선하여 Gleam 프로젝트의 빌드 시간을 크게 단축시켰습니다. 또한, BEAM 크래시 보고서나 스택 추적에서 라인 번호와 같은 위치 메타데이터가 원래의 Gleam 소스 코드를 기준으로 정확하게 제공됩니다. JavaScript 측면에서는 패턴 매칭(`case` 표현식)을 더 평평한(flatter) 코드로 최적화하고, 짧은 리스트 리터럴에 대해서는 배열 변환 과정을 생략하는 등 여러 개선이 이루어졌습니다.
TypeScript와의 통합을 강화하기 위해, 사용자 정의 데이터 구조를 다룰 때 타입 정보 손실을 방지하는 오버로드가 추가되었습니다. 또한, 빌드 도구 측면에서도 개선이 있었습니다. 이전에는 Gleam 지원 빌드 도구가 `.app` 리소스 파일을 제공해야 했으나, 이제 `gleam` 실행 파일 자체가 BEAM 컴파일 시 해당 파일을 생성하도록 기능을 확장했습니다.
용어 풀이
- API
- 프로그램끼리 기능을 주고받는 약속된 창구. AI 모델은 보통 API로 불러 써요.
Gleam이 사용하는 'Erlang 추상 형식'은 무엇인가요?
이 추상 형식은 Erlang 컴파일러가 사용하는 메타데이터 주석이 달린 트리 구조예요. 이를 사용함으로써 생성된 코드는 Erlang의 외부 항 형식 바이너리 인코딩으로 직접 로드할 수 있게 되어 컴파일 과정의 효율성이 높아져요.
자바스크립트 측면에서 어떤 최적화가 이루어졌나요?
패턴 매칭(`case` 표현식)을 더 평평한 코드로 최적화했고, 짧은 리스트 리터럴에 대해서는 배열 변환 과정을 생략하는 등의 개선이 이루어졌어요. 이 외에도 빌드 시간 단축과 디버깅 메타데이터 정확도 향상 같은 전반적인 성능 개선이 있어요.
타입 정보 손실을 막기 위해 어떤 기능이 추가되었나요?
사용자 정의 데이터 구조를 다룰 때 발생하는 타입 정보 손실을 방지하기 위해 API 오버로드가 추가되었어요. 또한, 빌드 도구 측면에서도 `gleam` 실행 파일 자체가 BEAM 컴파일 시 `.app` 리소스 파일을 생성하도록 기능이 확장되어 통합성이 높아졌답니다.