Elixir 3분 소요

동적 언어 Elixir가 타입을 품었다 — 점진적 타이핑이 던진 새로운 질문

타입이냐 자유냐. 프로그래밍 언어를 둘러싼 이 오래된 논쟁에 흥미로운 사건이 하나 끼어들었습니다. 동적 언어의 대표주자 중 하나인 Elixir가 타입 시스템을 품기 시작한 건데요. 그것도 우리가 흔히 아는 방식이 아니라 집합론 기반 타입이라는 독특한 길을 택했습니다. 동적 언어를 좋아하던 사람들에게도, 정적 타입을 신봉하던 사람들에게도 곱씹어볼 거리가 생겼습니다.

먼저 솔직하게 말씀드리겠습니다. 이번 주제는 최근 30일 사이 커뮤니티에서 활발히 논의된 따끈한 이슈라기보다는, 지난 몇 년간 꾸준히 진행돼 온 큰 흐름에 가깝습니다. 실제로 최근 한 달 내 새로운 토론은 거의 잡히지 않았습니다. 그래서 이 글은 속보가 아니라, Elixir 창시자 José Valim이 직접 풀어낸 설명들을 바탕으로 한 흐름 정리에 가깝다는 점을 미리 밝혀둡니다.

동적 언어가 왜 타입을 고민하게 됐나

Elixir는 그동안 타입 선언 없이 코드를 쭉쭉 써 내려가는 자유로움이 큰 매력이었습니다. 함수에 무엇이 들어오든 일단 받고, 실행하면서 판단합니다. 빠른 프로토타이핑과 유연함을 얻는 대신, 엉뚱한 값이 들어왔을 때 문제가 실행 중에야 터지는 위험을 안고 가는 방식입니다.

문제는 코드베이스가 커질 때 드러납니다. 협업하는 사람이 늘고 함수가 수천 개가 되면, “이 함수에 도대체 뭘 넣어야 하지"라는 정보 비대칭이 점점 무거워집니다. 정적 타입 언어들이 누리던, 컴파일 단계에서 실수를 잡아주는 안전망이 아쉬워지는 순간입니다.

그렇다고 기존 코드를 전부 갈아엎고 타입을 강제할 수는 없습니다. 수많은 라이브러리와 서비스가 이미 동적인 방식으로 돌아가고 있으니까요. 여기서 등장한 해법이 바로 점진적 타이핑입니다.

점진적 타이핑이란 무엇인가

점진적 타이핑(gradual typing)은 말 그대로 타입을 조금씩, 원하는 만큼만 도입하는 방식입니다. 타입을 적은 부분은 컴파일러가 엄격하게 검사해주고, 타입을 적지 않은 부분은 기존처럼 동적으로 자유롭게 동작합니다.

비유하자면 이렇습니다. 모든 직원에게 사원증 검사를 강제하는 대신, 보안이 중요한 구역에만 출입 통제를 두는 셈입니다. 핵심 로직에는 타입을 명시해 안전망을 깔고, 가볍게 쓰는 부분은 그대로 두는 거죠. 개발자가 안전과 유연함 사이에서 직접 균형을 고를 수 있다는 게 핵심입니다.

이 접근의 장점은 마이그레이션 부담이 적다는 점입니다. 기존 코드를 한 번에 바꿀 필요 없이, 새로 짜는 모듈부터 타입을 붙여나가면 됩니다. 동적 언어의 생태계를 깨지 않으면서 정적 타입의 이점을 흡수하려는 영리한 전략입니다.

집합론 기반 타입이라는 독특한 선택

Elixir가 특히 주목받는 이유는 타입 시스템의 토대로 집합론 기반 타입(set-theoretic types)을 골랐다는 점입니다. 이름이 어렵게 들리지만 발상은 직관적입니다. 타입을 “값들의 집합"으로 보고, 집합 연산처럼 다루는 방식입니다.

예를 들어 “정수이거나 문자열"이라는 타입은 두 집합의 합집합으로 표현됩니다. 여러 타입의 교집합, 여집합 같은 개념도 자연스럽게 다룰 수 있습니다. 이게 왜 중요할까요. Elixir 같은 언어에는 함수가 입력에 따라 다른 형태의 값을 돌려주는 경우가 흔하기 때문입니다. 전통적인 타입 시스템은 이런 유연한 패턴을 표현하기가 까다로운데, 집합론적 접근은 이를 한결 자연스럽게 담아냅니다.

José Valim은 한 팟캐스트 인터뷰에서 이 설계 철학을 직접 풀어내기도 했습니다. 동적 언어의 표현력을 죽이지 않으면서 타입의 안전성을 더하려면, 기존 정적 타입의 틀을 그대로 가져오는 대신 새로운 수학적 토대가 필요하다는 판단이었습니다. 단순히 “타입을 붙였다"가 아니라 “동적 언어에 맞는 타입을 새로 설계했다"는 점이 이 작업의 야심입니다.

이 변화가 던지는 진짜 질문

Elixir의 행보는 한 언어의 기능 추가를 넘어 더 큰 흐름을 보여줍니다. 동적 언어 진영에서 타입을 받아들이는 움직임은 사실 Elixir만의 일이 아닙니다. 파이썬의 타입 힌트, 자바스크립트 위의 타입스크립트가 이미 비슷한 길을 걸었습니다. 동적 언어의 생산성과 정적 타입의 안정성, 둘 다 갖고 싶다는 욕심이 업계 전반의 방향이 된 셈입니다.

흥미로운 건 Elixir의 접근이 기존 사례들보다 한 발 더 들어갔다는 점입니다. 타입스크립트가 자바스크립트 위에 별도 층을 얹는 방식이라면, Elixir는 컴파일러 안에 타입 추론을 직접 녹여 넣으려 합니다. 외부 도구가 아니라 언어 자체의 일부로 만들겠다는 겁니다.

물론 숙제도 남습니다. 점진적 타이핑은 자유를 주는 만큼 일관성이 흔들릴 수 있습니다. 어디까지 타입을 붙일지는 결국 팀의 규율에 달려 있으니까요. 그리고 집합론 기반 타입이 이론적으로 우아하더라도, 실제 대규모 코드에서 빠르고 정확하게 동작하는지는 시간을 두고 검증돼야 할 부분입니다.

타입은 족쇄일까요, 아니면 안전벨트일까요. Elixir는 “둘 다 당신이 고르세요"라는 답을 내놓고 있습니다. 동적 언어의 자유를 사랑하던 분들이라면, 이 새로운 타협안을 어떻게 받아들이실지 궁금해지는 대목입니다. 당신의 코드에 타입이라는 안전벨트, 어디까지 매고 싶으신가요.

Elixir 타입시스템 프로그래밍언어 점진적타이핑 José Valim

댓글

    댓글을 불러오는 중...