프로그래밍 언어를 공부하다 보면 꼭 한 번쯤 듣게 되는 이름이 있다.
바로 Elixir(엘릭서).
이름만 보면 무슨 판타지 게임에서 마나 채워주는 물약 같지만, 사실 엘릭서는 동시성 처리에 강하고, 장애에 잘 버티고, 서버 개발에 아주 잘 맞는 함수형 프로그래밍 언어다.
그런데 이 설명만 들으면 또 이런 생각이 든다.
“그래서 얘가 정확히 뭐 하는 놈인데?”
오늘은 엘릭서를 처음 듣는 사람도 감이 오게, 엘릭서가 왜 만들어졌고, 어디에 강하고, 왜 사람들이 좋아하는지를 가볍게 정리해보려고 한다.
1. 엘릭서는 한마디로 뭐냐면
엘릭서는 많은 일을 동시에 처리해야 하는 서버를 안정적으로 돌리기 좋은 언어다.
예를 들어 이런 상황을 떠올려보자.
- 수많은 사용자가 동시에 접속하는 채팅 서비스
- 실시간 알림이 계속 오가는 앱
- 장애가 나도 쉽게 죽으면 안 되는 백엔드 서버
- 연결이 엄청 많이 붙는 게임 서버나 메시징 시스템
이런 곳에서는 단순히 “빠른 언어”보다 여러 요청을 동시에 잘 처리하고, 중간에 하나가 터져도 전체가 무너지지 않고, 오래 안정적으로 돌아가는 것이 더 중요하다.
엘릭서는 바로 이런 문제를 풀기 위해 존재감이 커진 언어다.
2. 엘릭서의 진짜 몸통은 BEAM이다
엘릭서를 이해하려면 사실 엘릭서 자체보다, 그 밑에서 돌아가는 BEAM을 알아야 한다.
BEAM은 원래 Erlang VM(에를랑 가상 머신)이다.
쉽게 말하면 엘릭서는 에를랑(Erlang) 이라는 오래된 강자의 엔진 위에서 돌아가는 현대적인 언어라고 보면 된다. 에를랑은 원래 통신 장비 쪽에서 쓰이던 언어라서, 처음부터 목표가 아주 분명했다.
“수많은 연결을 안정적으로 처리하고, 장애가 나도 시스템이 계속 돌아가게 하자.”
그래서 BEAM은 다음 같은 특징을 아주 잘 처리한다.
- 엄청 많은 경량 프로세스
- 프로세스끼리 독립적인 실행
- 메시지 기반 통신
- 장애 격리와 자동 복구
- 장시간 안정적인 서비스 운영
즉, 엘릭서는 예쁜 문법만 가진 언어가 아니라 검증된 런타임 위에 올라탄 실전형 언어다.
3. 왜 “동시성” 이야기만 그렇게 많이 할까
엘릭서를 소개할 때 빠지지 않는 단어가 바로 동시성(Concurrency)이다.
처음 들으면 좀 거창한데, 생각보다 개념은 단순하다. 한 가지 일만 순서대로 하는 게 아니라, 여러 작업을 동시에 자연스럽게 처리하는 능력이라고 보면 된다.
예를 들어 웹 서버를 만든다고 해보자. 사용자 A가 요청을 보내고, 동시에 사용자 B도 요청을 보내고, 그 와중에 데이터베이스 조회도 하고, 알림도 보내고, 로그도 저장해야 한다. 이걸 한 줄로 줄 세워서 처리하면 느려지고, 중간에 하나 꼬이면 전체가 답답해진다.
엘릭서는 이런 작업들을 작고 독립적인 프로세스로 나눠서 처리하는 데 강하다.
중요한 건 여기서 말하는 프로세스가 우리가 OS에서 생각하는 무거운 프로세스랑 느낌이 좀 다르다는 점이다. 엘릭서의 프로세스는 매우 가볍고 수백만 개씩 띄울 수 있다.
그래서 “동시에 많은 요청을 받아야 하는 서버”에서 특히 빛난다.
4. 장애가 나도 “전체는 살아있게” 만드는 철학
엘릭서가 재미있는 건, 에러를 무조건 숨기거나 억지로 막으려 하기보다 “문제가 생기면 그 부분만 죽이고 다시 살리자(Let it crash)” 쪽에 가깝다는 점이다.
처음 들으면 위험해 보일 수 있다.
“아니, 죽이면 어떡해?”
그런데 현실적인 서버 개발에서는 모든 에러를 완벽하게 막는 게 거의 불가능하다. 그래서 엘릭서 진영에서는 차라리 문제가 생긴 작은 프로세스를 빠르게 종료하고, 감독(Supervision) 구조로 다시 시작하는 방식을 쓴다.
이 철학 덕분에 시스템 전체가 훨씬 단단해진다. 마치 큰 공장에서 작은 부품 하나 고장 났다고 공장 전체를 멈추는 게 아니라, 그 부품만 교체하고 계속 돌리는 느낌이다. 이게 엘릭서가 “안정성” 얘기에서 자주 언급되는 이유다.
5. 문법은 에를랑보다 훨씬 친절하다
에를랑은 강력하지만, 처음 보면 문법이 꽤 낯설다. 엘릭서는 그 에를랑의 장점을 가져오면서, 조금 더 현대적이고 읽기 쉬운 문법으로 다듬은 언어다.
“엘릭서는 에를랑의 강력한 엔진을 좀 더 사람 친화적으로 쓸 수 있게 만든 언어다.”
예를 들어 함수형 언어답게 데이터를 직접 마구 바꾸기보다는 새로운 값을 만들어가며 흐름을 구성하는 스타일이 강하다. 처음엔 낯설 수 있지만, 익숙해지면 오히려 코드 흐름이 예측 가능해지고 버그를 줄이는 데 도움이 된다.
특히 파이프 연산자(|>)는 엘릭서를 상징하는 문법 중 하나다.
"hello"
|> String.upcase()
|> String.reverse()이런 식으로 데이터를 왼쪽에서 오른쪽으로 흘려보내면서 처리할 수 있어서, 읽을 때 꽤 직관적이다.
6. 그래서 어디에 쓰면 잘 맞을까?
엘릭서는 특히 백엔드 서버에서 강점을 보인다. 대표적으로 잘 맞는 경우는 이렇다.
- 실시간 서비스: 채팅, 알림, 대시보드, 협업 도구처럼 여러 사용자의 상태가 계속 바뀌고 연결이 유지되는 서비스에 잘 맞는다.
- 높은 안정성이 필요한 시스템: 중간에 일부 기능이 실패해도 전체 서비스는 계속 살아있어야 하는 경우에 유리하다.
- 동시 접속이 많은 웹 서비스: 많은 요청을 동시에 받아야 하는 환경에서 엘릭서의 강점이 드러난다.
- 이벤트 중심 시스템: 메시지 전달, 작업 분배, 큐 처리처럼 여러 이벤트가 동시에 흘러다니는 구조와 잘 어울린다.
7. Phoenix는 엘릭서의 대표 무기다
엘릭서를 이야기할 때 Phoenix(피닉스)를 빼놓을 수 없다.
Phoenix는 엘릭서 기반 웹 프레임워크인데, 쉽게 말하면 엘릭서로 웹 서비스를 만들 때 가장 대표적으로 쓰는 도구다. 그리고 Phoenix의 킬러 기능 중 하나가 바로 LiveView다.
보통 웹에서 화면이 실시간으로 바뀌려면 프론트엔드에서 자바스크립트를 많이 쓰고, 서버와 API를 계속 주고받고, 상태 관리도 복잡해진다. 그런데 LiveView는 이 중 많은 부분을 서버 중심으로 풀어낸다. 즉, 실시간 UI를 비교적 단순한 구조로 만들 수 있게 도와준다.
그래서 엘릭서 진영에서는 “복잡한 실시간 웹 서비스를 생각보다 적은 복잡도로 만들 수 있다”는 이야기가 자주 나온다.
8. 엘릭서가 무조건 정답은 아니다
물론 장점만 있는 건 아니다. 엘릭서는 아주 매력적인 언어지만, 모든 프로젝트에 정답처럼 들이밀 수 있는 만능 열쇠는 아니다. 가령 이런 점들은 진입장벽이 될 수 있다.
- 함수형 사고방식이 낯설다: 변수 바꾸고, 상태 바꾸고, 반복문 돌리는 데 익숙한 사람에게는 처음엔 머리가 좀 꼬일 수 있다.
- 생태계가 대형 언어보다 작다: Python, JavaScript, Java처럼 압도적인 규모는 아니다. 그래서 자료나 라이브러리 선택지가 덜할 때도 있다.
- 팀 적응이 필요하다: 혼자 공부할 때는 재밌어도, 팀 전체가 언어와 철학에 익숙해져야 진짜 장점이 나온다.
즉, 엘릭서는 “아무 데나 갖다 붙이는 언어”라기보다는 문제가 잘 맞아떨어질 때 엄청 강한 언어에 가깝다.
9. 엘릭서는 이런 사람에게 특히 재밌다
엘릭서는 이런 사람에게 꽤 매력적으로 다가온다.
- 서버가 왜 자꾸 복잡해지는지 고민하는 사람
- 장애 대응과 안정성에 관심 있는 사람
- 실시간 기능이 많은 서비스를 만들어보고 싶은 사람
- 함수형 프로그래밍을 제대로 맛보고 싶은 사람
- “코드는 적은데 시스템은 강하다”는 감각을 좋아하는 사람
처음에는 낯설지만, 한 번 감을 잡으면 “아, 이 언어는 애초에 싸움터가 다르구나” 싶은 느낌이 든다.
마무리
엘릭서는 한마디로 정리하면 이렇다.
많은 일을 동시에 처리하고, 장애에도 잘 버티고, 서버를 오래 안정적으로 굴리는 데 강한 언어.
겉보기에는 비교적 조용한 언어처럼 보이지만, 실제로는 동시성, 안정성, 실시간 처리라는 꽤 묵직한 문제를 정면으로 다루는 언어다. 그래서 “요즘 많이 쓰는 언어냐?”보다 더 중요한 질문은 이거다.
“내가 풀고 싶은 문제가 엘릭서와 잘 맞는가?”
그 질문에 “그렇다”라고 답할 수 있다면, 엘릭서는 꽤 믿음직한 선택지가 될 수 있다.
이름은 물약 같지만, 하는 일은 생각보다 아주 하드코어하다.
그런데 지금 딱히 배울 가치는 없다. AI가 잘쓰지는 못하는것같다.
차라리 쓸꺼면 Go 쓰게 하는게 나을것같음.
요즘 오픈소스에 엘릭서 많이 보이길래 궁금해서 써봄
