본문으로 건너뛰기
피드

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

Elixir 1.20, 이제 점진적 타입 언어로 한 발 들어감

Elixir 1.20은 타입 애노테이션 없이 모든 Elixir 프로그램에 타입 추론과 점진적 타입 검사를 적용하는 첫 개발 마일스톤을 담았음. 목표는 기존 동적 코드베이스에서 거짓 양성을 낮게 유지하면서, 실제 런타임에서 터질 버그와 죽은 코드를 잡아내는 것임.

backend

인텔, 클라우드·통신사·에이전틱 AI용 제온6+ 정식 출시

인텔이 E코어 기반 서버 프로세서 제온6+를 정식 출시했다. 인텔 18A 공정, 리본펫, 파워비아, 포베로스 3D, EMIB까지 파운드리 기술을 총동원해 소켓당 최대 288코어를 밀어 넣은 제품이다. 인텔은 오래된 제온 서버를 제온6+로 바꾸면 랙과 서버 수를 크게 줄이고, 확보한 전력·공간을 AI 인프라로 돌릴 수 있다고 강조한다.

backend

내구성 있는 워크플로, 꼭 거창한 DB가 필요할까? SQLite로도 충분하다는 주장

Obelisk 글은 내구성 있는 실행에서 정말 중요한 건 비싼 인프라가 아니라 워크플로 상태를 오래 보존하는 것이라고 주장한다. 많은 AI 에이전트나 실험성 워크플로에서는 SQLite 파일과 Litestream 백업만으로도 충분하고, 고가용성 공유 DB가 필요한 시점에 Postgres로 가면 된다는 얘기다.

backend

DBOS 주장: Durable Workflow, 오케스트레이터 말고 Postgres로 충분하다

DBOS는 durable workflow를 구현할 때 Temporal, Airflow, AWS Step Functions 같은 외부 오케스트레이터가 꼭 필요하지 않다고 주장한다. 핵심 아이디어는 워크플로우 상태를 어차피 데이터베이스에 체크포인트로 저장한다면, Postgres 자체를 오케스트레이터처럼 쓰는 편이 더 단순하다는 것이다. 확장성, 가용성, 관측성, 보안까지 Postgres 운영 경험을 그대로 활용할 수 있다는 게 글의 논지다.

backend

Go에서 Rust로 옮길 때 진짜로 바뀌는 것들

이 글은 Go 백엔드 서비스를 Rust로 옮길 때 속도보다 컴파일 타임 보장, 런타임 트레이드오프, 개발자 경험이 더 중요하다고 설명한다. nil 패닉, 데이터 레이스, 에러 처리, 제네릭, 비동기 모델, 마이그레이션 전략까지 실무 관점에서 Go와 Rust를 길게 비교한다.