Gleam은 왜 한 가지 문법을 고집할까요

Gleam은 왜 한 가지 문법을 고집할까요

AI 뉴스 썸네일

프로그래밍 언어는 기능이 많을수록 편리해 보이지만, 같은 일을 여러 방식으로 표현하면 코드를 읽는 비용도 커져요. Gleam은 선택지를 줄이는 쪽을 택했어요. 폐기 예정 API 안내부터 패턴 매칭과 오류 처리까지, 언어가 정한 몇 가지 방식 안에서 풀도록 설계했어요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
언어 설계	같은 문제를 한 가지 명시적인 문법으로 풀어요	팀원이 낯선 코드를 읽을 때 추측할 부분이 줄어요
유지보수	`@deprecated`와 `todo`가 언어에 들어 있어요	API 교체 경로와 미완성 작업을 컴파일러가 드러내요
타입 시스템	값의 부재와 실패를 `Option`과 `Result`로 표현해요	`null`이나 예외가 숨어서 흐름을 바꾸는 일을 줄여요
절충점	제약된 제네릭 같은 복잡한 기능은 제공하지 않아요	표현력보다 문법의 단순성과 읽기 쉬운 코드를 우선해요

1. 기능을 더하기보다 선택지를 줄인 Gleam

Gleam은 Erlang 가상머신인 BEAM에서 동작하는 정적 타입 언어예요. 원문 작성자는 약 일주일 동안 언어를 익히며 인상적이었던 기능을 기록했어요. 오래 사용한 뒤의 성능 평가나 대규모 운영 사례가 아니라, 문법과 개발 경험을 살핀 학습 기록이라는 점은 구분해서 읽어야 해요. 2

폐기할 API에는 다음 길을 함께 적어요

함수에 `@deprecated("Use new_way")`를 붙이면 사용 중단 예정이라는 사실과 대체 함수를 함께 알릴 수 있어요. 라이브러리 이용자는 경고만 받는 데서 끝나지 않아요. 어느 API로 옮겨야 하는지 컴파일러 메시지에서 바로 확인할 수 있어요.

728x90

`todo`도 주석 관례나 별도 린터에만 기대지 않아요. `todo as "설명"`처럼 언어 구문으로 남길 수 있어요. 구현하지 않은 위치와 해야 할 일을 코드 안에서 같은 형식으로 표시하니, 팀마다 다른 주석 규칙을 정할 부담이 적어져요.

제네릭은 함수 타입처럼 읽혀요

Gleam은 입력과 반환에 같은 소문자 타입 변수를 쓰는 방식으로 제네릭을 표현해요. 별도의 긴 선언을 앞세우지 않아도 함수 시그니처만 보고 값의 관계를 읽을 수 있어요. 대신 특정 연산을 지원하는 타입만 받는 제약된 제네릭처럼 복잡한 표현은 포기했어요.

이 선택은 모든 프로젝트에 유리하지 않아요. 정교한 타입 제약이 필요한 라이브러리라면 표현력이 부족할 수 있어요. 반대로 일반적인 데이터 변환 함수가 많은 서비스 코드에서는 타입 선언이 짧아져 읽기 편할 수 있어요.

패턴 매칭은 `case`로 모아요

Elixir와 Erlang은 함수 헤드, 가드, 매크로 등 여러 장치를 조합해 분기를 표현할 수 있어요. Gleam은 값 비교와 목록 분해, 패턴 별칭을 `case` 표현식에 모아요. 목록의 첫 항목을 분해하면서 이름을 붙이는 작업도 같은 문법 안에서 처리해요.

덕분에 코드를 읽는 사람은 분기가 나오면 먼저 `case`를 찾을 수 있어요. 하지만 함수 헤드 패턴 매칭에 익숙한 개발자에게는 반복이 늘어난 것처럼 느껴질 수 있어요. GeekNews 토론에서도 이 지점은 단순함의 장점과 표현 방식 축소의 아쉬움이 갈리는 부분으로 언급됐어요. 1

실패를 반환 타입에 남겨요

Gleam은 값이 없을 때 `null`을 넣는 대신 `Option`을 써요. 성공과 실패는 `Result`로 나눠요. 호출하는 쪽은 `Some`과 `None`, `Ok`와 `Error`를 타입에 맞춰 처리해야 해요.

예외가 호출 경로 바깥에서 갑자기 실행 흐름을 바꾸지 않으니, 함수 시그니처가 실패 가능성을 더 많이 보여 줘요. 기본값이 필요하면 `option.unwrap`처럼 호출자가 직접 정해요. 오류를 무시하기가 불가능한 것은 아니지만, 어떤 선택을 했는지가 코드에 남아요.

왜 중요한가요

새 언어를 고를 때는 기능 목록보다 팀이 매일 읽고 고칠 코드가 어떻게 보이는지를 따져야 해요. Gleam의 설계는 문법 선택지를 줄이고, API 변경과 미완성 작업, 실패 가능성을 코드 표면에 드러내는 데 집중해요. 여러 사람이 오래 유지할 서비스에서는 이런 일관성이 학습 시간과 리뷰 비용을 줄일 수 있어요. 2

반면 단순함에는 비용이 따라요. 제약된 제네릭이나 여러 함수 헤드처럼 더 강한 표현을 원하는 팀이라면 우회 코드가 늘 수 있어요. 도입 전에는 작은 기능을 직접 만들어 보고, 오류 처리와 패턴 매칭이 기존 코드베이스보다 실제로 읽기 쉬운지 비교하는 편이 좋아요.

참고 자료

1. Gleam의 멋진 점들 — GeekNews
2. The cool things of Gleam — A Bit, Alejandro Baez