본문으로 건너뛰기
피드

Gleam 1.17.0, 단일 파일 BEAM 실행 파일과 IDE 편의 기능을 잔뜩 추가했다

backend 약 8분
vote
0
댓글
북마크

Gleam 1.17.0이 공개되면서 Erlang VM용 단일 파일 실행 배포 방식인 escript export를 공식 지원한다. 여기에 변수 참조 하이라이트, todo 상수 표현식, import 제안, 패턴 매칭 최적화, 여러 언어 서버 코드 액션, 보안 수정까지 포함됐다.

  • 1

    gleam export escript 명령으로 BEAM 바이트코드를 단일 실행 파일로 묶을 수 있다

  • 2

    언어 서버는 변수 참조 하이라이트, 레코드 업데이트 hover, 누락 모듈 생성 같은 IDE 기능을 추가했다

  • 3

    자바스크립트 타깃의 패턴 매칭 코드 생성이 더 compact해지고 불필요한 체크가 줄었다

  • 4

    빌드 도구의 설정 검증 관련 취약점 3건이 수정됐다

  • Gleam v1.17.0이 나왔고, 이번 릴리스의 메인 기능은 BEAM용 단일 파일 실행 배포임

    • Gleam은 Erlang VM(BEAM)과 JavaScript 런타임을 타깃으로 하는 타입 안전 언어임
    • BEAM에서는 Gleam 코드가 모듈별 .beam 바이트코드 파일로 컴파일되는데, 작은 CLI 프로그램을 공유할 때는 파일이 여러 개라 좀 번거로웠음
  • 새로 추가된 gleam export escript가 그 문제를 해결함

    • 프로젝트를 컴파일하고, 유효한 main 함수가 있는지 확인하고, 컴파일된 바이트코드를 escript 단일 파일로 묶어줌
    • 예시에서는 gleam export escript 실행 후 0.48초 만에 빌드되고, 생성된 실행 파일을 바로 ./my_project로 실행함
    • 자바스크립트 번들러가 여러 모듈을 하나로 묶는 것과 비슷한 포지션인데, 대상이 Erlang VM이라는 차이가 있음

💡

> Gleam으로 작은 내부 CLI나 운영 도구를 만들고 있다면 escript 지원은 꽤 실용적임. Erlang만 깔린 머신이면 여러 .beam 파일 배포 없이 단일 파일로 넘길 수 있음.

  • 언어 서버(Language Server) 개선도 많음

    • textDocument/documentHighlight를 지원해서 선택한 변수의 모든 참조를 에디터에서 하이라이트할 수 있음
    • 레코드 업데이트 구문에 hover하면 새 값으로 지정하지 않은 나머지 필드도 보여줌
    • 없는 모듈을 import하면 해당 모듈 파일을 만들어주는 code action도 추가됨
  • todo 표현식이 상수에서도 동작하게 됨

    • Gleam의 todo는 아직 못 만든 코드를 타입체크하거나 실행 흐름에 남겨두기 위한 placeholder임
    • 상수 표현식은 컴파일 타임에 평가되기 때문에, 상수 안의 todo가 있으면 프로그램 실행은 막히지만 타입체크와 분석은 가능함
    • 이 덕분에 레코드 생성자에서 빠진 label을 todo로 채워주는 “Fill labels” code action도 상수에서 동작함
  • 컴파일러 에러 메시지가 Gleam 스타일에 맞게 더 친절해짐

    • 다른 모듈 함수를 io.println처럼 qualified 형태로 써야 하는데 println만 썼다면, import된 모듈을 검색해서 io.println을 제안함
    • warning에 타입 이름을 표시할 때도 canonical name만 내보내지 않고, 코드에서 alias로 쓴 이름을 반영함
    • 예시처럼 user as visitor로 import했다면 힌트에서도 visitor.User처럼 보여줌
  • JavaScript 타깃의 패턴 매칭 코드 생성도 최적화됨

    • Gleam의 case 표현식은 겉보기엔 위에서 아래로 검사하는 선형 검색처럼 보이지만, 실제 컴파일 결과는 decision tree 방식임
    • 이번 릴리스에서는 비트 배열 길이 관련 중복 체크를 제거하고, assignment 코드를 더 compact하게 만드는 최적화가 들어감
  • 개발 모드와 의존성 확인도 소소하지만 덜 헷갈리게 바뀜

    • gleam dev --no-print-progress로 개발 모드 실행 시 컴파일 진행 메시지를 숨길 수 있음
    • gleam deps outdated는 이제 “1 of 12 packages”처럼 업데이트 가능한 패키지 수를 요약해줌
    • 업데이트할 게 없을 때도 “0 of 12 packages”를 출력해서, 아무 출력이 없어 혼란스러운 상황을 줄임
  • monorepo에서 패키지 publish 감지도 개선됨

    • Gleam 패키지가 Git 저장소 루트가 아닌 하위 디렉터리에 있어도 gleam publish가 Git repo 안에 있다는 사실을 더 잘 인식함
    • monorepo 안에 여러 Gleam 패키지를 두는 팀에는 꽤 현실적인 개선임
  • fault tolerant compilation도 더 단단해짐

    • 코드가 잘못된 상태여도 컴파일러가 분석을 최대한 계속해서 언어 서버가 도움을 줄 수 있게 하는 설계임
    • list-prepend 구문과 record update 구문의 오류 상황에서 내성이 좋아짐
    • 불필요한 record update를 제거하는 code action도 추가돼서 warning에서 바로 수정 가능함
  • 새 코드 액션들은 초보자와 빠른 편집 둘 다 노림

    • 문자열 연결에 +를 쓰는 실수를 하면 Gleam의 문자열 연결 연산자 <>를 제안하고 자동 수정할 수 있음
    • 이 자동 수정이 guard expression 안에서도 동작하게 됨
    • case expression에서 _로 버린 값을 실제 패턴으로 확장하는 액션도 추가돼, 리스트라면 [][first, ..rest] 케이스로 펼쳐줌

⚠️주의

> 빌드 도구의 설정 검증 관련 취약점도 3건 수정됨. 문서에는 CVE-2026-43965, CVE-2026-32685, CVE-2026-42795가 언급됐고, 영향이 “너무 무섭진 않다”고 표현했지만 업데이트를 미룰 이유는 별로 없음.

  • Gleam 프로젝트는 여전히 커뮤니티 기반으로 운영됨
    • 빅테크나 VC 자금 없이 후원에 의존한다고 밝힘
    • 핵심 팀원 보상을 위한 후원을 요청했고, 이번 릴리스에도 여러 기여자의 IDE, 컴파일러, 빌드 도구 개선이 들어감

기술 맥락

  • 이번 escript 지원이 중요한 이유는 Gleam이 BEAM 위에서 돌아가기 때문이에요. BEAM은 원래 여러 모듈의 바이트코드 파일을 자연스럽게 다루지만, 작은 CLI를 배포할 때는 그 구조가 오히려 불편해질 수 있거든요.

  • gleam export escript는 이 배포 문제를 빌드 도구 안으로 끌어온 선택이에요. 사용자가 Erlang 쪽 escript 생성 과정을 따로 맞추지 않아도, Gleam 프로젝트를 컴파일하고 main 함수 검증까지 한 뒤 실행 파일을 만들어줘요.

  • 언어 서버 개선이 많은 것도 Gleam다운 방향이에요. 타입 시스템이 강한 언어일수록 컴파일러가 가진 정보를 에디터에 잘 넘기면 자동완성, 수정 제안, 패턴 확장 같은 기능이 훨씬 정확해지거든요.

  • fault tolerant compilation은 개발 중 코드가 깨져 있어도 도구가 멈추지 않게 하려는 선택이에요. 실제 편집 중에는 완성된 코드보다 중간 상태의 코드가 더 많으니까, 이 부분이 좋아질수록 에디터 경험이 부드러워져요.

Gleam은 언어 문법보다 ‘도구가 개발자를 얼마나 덜 헷갈리게 하는가’에 꾸준히 투자하는 느낌이 강하다. 이번 릴리스도 대형 문법 기능보다 배포, 에러 메시지, 자동 수정, 언어 서버 같은 실전 피로도를 줄이는 개선이 중심이다.

댓글

댓글

댓글을 불러오는 중...

backend

클릭하우스가 PgBouncer 처리량을 4배로 끌어올린 방법

ClickHouse Managed Postgres 팀은 단일 스레드인 PgBouncer를 여러 프로세스로 띄우고 `so_reuseport`와 피어링(peering)을 조합해 16 vCPU 머신을 제대로 쓰게 만들었다. 동일한 AWS 환경에서 단일 프로세스는 약 8.7만 TPS 근처에서 막혔지만, 16개 프로세스 구성은 약 33.6만 TPS까지 올라갔다.

backend

SQLite 쓸 거면 STRICT 테이블을 기본값으로 보자는 주장

SQLite의 STRICT 테이블은 INTEGER 컬럼에 문자열이 들어가는 식의 타입 실수를 막아주는 기능이다. 글쓴이는 SQLite 특유의 유연한 타입 시스템보다, 실수는 빨리 터뜨리는 쪽이 실무에서 낫다고 주장한다. 다만 기존 테이블을 바로 STRICT로 바꾸기 어렵고, SQLite 3.37.0 이상에서만 쓸 수 있다는 제약도 있다.

backend

왜 아직도 Lisp를 배워볼 만한가

Lisp는 괄호가 많은 이상한 언어처럼 보이지만, 핵심은 문법이 아니라 언어 자체를 확장할 수 있다는 점에 있음. 매크로, 코드-데이터 동일성, REPL 중심 개발이 합쳐지면 프로그램을 '작성'한다기보다 살아 있는 시스템을 계속 진화시키는 방식으로 개발하게 됨.

backend

EDB 포스트그레스 AI, 포레스터 멀티모델 데이터 플랫폼 리더 선정

EDB의 AI 데이터 플랫폼 EDB 포스트그레스 AI가 2026년 2분기 포레스터 웨이브 멀티모델 데이터 플랫폼 보고서에서 리더로 선정됐음. 트랜잭션, 분석, AI 워크로드를 하나의 플랫폼에서 다루는 흐름이 강해지는 가운데, EDB는 전략과 현재 제공 기능 모두에서 높은 평가를 받았다고 밝힘.

backend

Bun, Zig에서 Rust로 갈아탔다: 11일짜리 초대형 런타임 포팅 실험

Bun 팀이 53만 줄이 넘는 Zig 코드베이스를 Rust로 기계적으로 포팅했고, Bun v1.4.0부터 Rust 기반으로 전환될 예정임. 핵심 이유는 성능보다 안정성이었고, use-after-free, double-free, 메모리 누수 같은 문제를 컴파일러와 타입 시스템으로 더 빨리 잡기 위해서였음. Claude Code 워크플로 64개를 병렬로 돌려 11일 만에 전 플랫폼 테스트 통과까지 밀어붙인 사례라, LLM 기반 대규모 코드 마이그레이션의 꽤 강한 신호탄임.