Elixir 1.20, 타입 어노테이션 없이 버그를 잡는 쪽으로 움직여요

Elixir 1.20, 타입 어노테이션 없이 버그를 잡는 쪽으로 움직여요

AI 뉴스 썸네일

Elixir 1.20은 기존 동적 언어의 흐름을 유지하면서도 타입 검사 쪽으로 한 걸음 더 갔어요. 개발자가 타입 어노테이션을 붙이지 않아도 컴파일러가 죽은 코드와 실행 시 실패가 확실한 타입 오류를 더 많이 찾아내요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
언어 업데이트	Elixir 1.20이 모든 프로그램에 타입 추론과 점진적 타입 검사를 적용해요	오래된 동적 언어가 타입 안정성을 어떻게 받아들이는지 보여줘요
타입 시스템	`dynamic()`이 값의 가능한 범위를 좁히며 확실한 위반만 보고해요	TypeScript나 Dialyzer와 다른 설계 방향을 비교해 볼 수 있어요
개발 경험	타입 어노테이션 없이도 일부 버그와 중복 절을 찾고, 컴파일 시간도 개선됐어요	기존 Elixir 프로젝트가 큰 마이그레이션 없이 이득을 볼 수 있어요

1. Elixir가 타입을 붙이는 방식이 조금 다르게 바뀌었어요

Elixir 1.20의 첫 번째 변화는 “모든 코드에 타입을 쓰세요”가 아니에요. 기존 코드 위에서 컴파일러가 타입을 추론하고, 실행하면 반드시 실패할 조합을 찾아내는 쪽에 가까워요. 공식 발표에서는 이를 `verified bugs`라고 불러요. 예를 들어 정수나 문자열일 수 있는 값을 map 전용 함수에 넘기면, 가능한 타입 범위와 함수가 받는 타입이 겹치지 않기 때문에 위반으로 잡을 수 있어요. 1

이 접근은 오래된 코드베이스를 가진 팀에 더 현실적이에요. 타입 어노테이션을 한꺼번에 넣지 않아도 컴파일러가 일부 오류를 찾아주고, 기존 코드의 작성 습관을 크게 바꾸지 않아도 돼요. Elixir를 Phoenix나 OTP 기반 백엔드에서 쓰는 팀이라면, 새 버전을 올렸을 때 어떤 죽은 절과 타입 위반이 드러나는지 확인해 볼 만해요.

2. `dynamic()`은 “아무거나 가능”과 달라요

많은 점진적 타입 시스템에서 동적 타입은 타입 정보를 거의 포기하는 장치처럼 보일 때가 있어요. Elixir 1.20의 `dynamic()`은 조금 달라요. 값이 런타임에 어떤 범위 안에 있을 수 있는지 추적하고, 코드가 그 값을 어떻게 쓰는지에 따라 범위를 좁혀요. 1

예를 들어 어떤 값이 정수 또는 문자열일 수 있다면, 숫자 연산이나 문자열 함수 호출에서 곧바로 위반을 내지 않아요. 가능한 타입 중 일부가 함수가 받는 타입과 겹치기 때문이에요. 반대로 map만 받는 함수에 같은 값을 넘기면 겹치는 범위가 없어요. 이때는 실제 실행에서도 실패할 가능성이 아니라 실패가 확실한 조합으로 보고 경고를 낼 수 있어요.

3. guard와 조건문도 타입 정보로 쓰여요

Elixir 코드에서 guard는 이미 런타임 조건을 표현하는 중요한 도구예요. 1.20에서는 `is_list`, `is_integer`, `is_map_key`, `tuple_size` 같은 조건이 타입 정보를 좁히는 데 쓰여요. `case`나 조건문도 앞 절에서 확인한 정보를 다음 절에 반영해요. `nil`을 먼저 처리했다면, 남은 분기에서는 값의 타입을 더 좁게 볼 수 있어요. 1

이런 변화는 Elixir다운 문법을 그대로 쓰면서 타입 검사 품질을 올리는 방향이에요. 새 문법을 크게 배우기보다, 기존 코드가 이미 가진 패턴 매칭과 guard 정보를 컴파일러가 더 잘 읽는다고 보면 쉬워요.

4. 성능과 컴파일 시간도 같이 손봤어요

이번 릴리스는 타입 시스템만 담고 있지 않아요. 공식 발표에 따르면 다중 코어 환경에서 애플리케이션 컴파일 시간이 다시 개선됐고, 합성 벤치마크에서 Elixir 빌드 도구가 BEAM 언어 중 가장 빠른 결과를 냈어요. 1

새 컴파일러 옵션 `:module_definition`도 들어갔어요. `mix.exs`에서 `elixirc_options: [module_definition: :interpreted]`처럼 설정하면 `defmodule` 내부 실행 방식을 바꿀 수 있어요. 디스크에 저장되는 `.beam` 파일에는 영향을 주지 않고, 큰 프로젝트의 컴파일 시간 개선에 도움이 될 수 있는 옵션이에요.

왜 중요한가요

Elixir 1.20은 동적 언어가 타입 시스템을 받아들이는 방식에 관한 좋은 사례예요. “타입을 전부 쓰거나 전부 포기하거나”가 아니라, 기존 코드 위에서 확실한 오류부터 찾는 쪽을 택했어요. 이 방향은 Python, JavaScript, Ruby처럼 동적 언어를 오래 써온 개발자에게도 익숙한 고민이에요.

아직 typed struct나 새 타입 시그니처까지 모두 열린 건 아니에요. 공식 발표도 집합론적 타입 기반의 더 넓은 타입 정의는 성능, 재귀 타입, 매개변수화 타입, map key-value 순회 같은 연구가 더 충족된 뒤 논의될 예정이라고 설명해요. 그래도 1.20은 Elixir 타입 시스템이 연구 단계에서 실제 개발 도구로 넘어왔다는 점에서 의미가 커요. 1

참고 자료

1. Elixir v1.20 released: now a gradually typed language — The Elixir programming language
2. Elixir v1.20: 이제 점진적 타입 언어 — GeekNews
3. If T: Benchmark for Type Narrowing — GitHub
4. Strong arrows: a new approach to gradual typing — The Elixir programming language