이 글은 2016년 11월 16일 서울 엘릭서 밋업에서 한 발표의 내용을 정리한 것입니다.

초심자에게 가르칠 언어를 선택할 때 바로 엘릭서를 떠올리실 분은 없을 것입니다. 파이썬, 루비, 자바스크립트, C/C++, 자바 등이 더 일반적이죠. 하지만 저는 엘릭서 특유의 장점 덕분에 엘릭서도 첫 언어로 진지하게 고려해볼 만하다고 생각합니다.

엘릭서는 초보 개발자에게 코드를 작은 부분으로 분리시키는 습관을 가르친다

루비 온 레일즈와 나

레일즈 앱이 흔히 그러하듯이, 제 레일즈 앱도 어느 순간부터 거대한 엉망진창 코드 덩어리가 되어버렸습니다. 지난번 직장을 그만 둔 이후로 제 목적은 대체 왜 그리고 어쩌다 그런 일이 발생했는지를 알아내는 것이었습니다.

어느 정도 알아본 결과 그래도 납득이 가는 답을 찾아낼 수 있었습니다. 레일즈에는 흔히 “레일즈 웨이”라고 부르는 기본적인 컨벤션이 있는데, 이는 개발자가 기본적인 CRUD 웹 어플리케이션을 빠르게 만들 수 있도록 해줍니다. 데이터베이스, 라우팅, 애셋 관리 등 웹 어플리케이션에 필수적인 요소에 대해 매우 합리적인 기본 구조를 제공합니다.

하지만 앱이 더 복잡해질 수록 “레일즈 웨이”는 점점 효과가 떨어집니다. 게다가 단기적 생산성에 집중했기 때문에 레일즈의 코드 구조는 간단한 단기적 프로젝트에는 적합하지만 복잡한 장기적 프로젝트에는 맞지 않는다는 부작용이 있습니다.

하지만 저를 비롯한 수많은 개발자들은 어플리케이션의 현재 단계에서는 “레일즈 웨이”가 더 이상 적합하지 않은데도 이를 계속 따랐고, 그러면서 엄청나게 많이 고생했습니다. 게다가 저는 독학을 했기 때문에 “레일즈 웨이” 말고 다른 방식은 알지도 못했기 때문에 어차피 대안도 없었죠.

그래서 코드를 관리하는 다른 방법을 찾기 위해 계속 리서치를 진행했습니다. 그래도 수많은 개발자가 이런저런 시도를 해 본 덕분에 레일즈 앱을 확장하기 위한 베스트 프랙티스가 이제 어느 정도 정립이 된 것 같았습니다.

  • 컨트롤러는 HTTP 호출에 대한 응답만을 다룬다
  • 뷰와 헬퍼는 뷰에 관련된 부분만 다룬다
  • 나머지는 모두 모델 레이어에서 담당한다
  • 모델 레이어에서 퍼시스턴스 로직과 도메인 로직을 분리한다
  • 루비 객체를 필요한 만큼 만들어서 제대로 된 OOP를 한다

달리 말해 코드를 분리하고 단순하게 유지할 것. 책을 몇 권 읽어보니 여러 사람이 이런 조언을 최소한 90년대부터 계속 해왔다는 것도 알게되었습니다. 비극적인 것은 제가 그런 사실을 쉽게 알 방법이 없었다는 것이죠. 이런 것도 혼자서 배울 수 있는 좋은 방법이 없을까 생각을 하게 되었는데, 그러다가 엘릭서에 대해서 알게 되었습니다. 그리고 엘릭서를 조금 다뤄본 결과, 코드를 작은 부분으로 나누어 구성하고 관리하는 방법을 엘릭서를 통해서 배울 수 있겠다는 생각을 가지게 되었습니다.

엘릭서는 코드를 분리하도록 “가르친다”

엘릭서는 코드를 분리하는 방법을 언어 차원에서 지원할 뿐 아니라, 그렇게 하도록 반쯤 강제합니다.

모듈 수준에서는 패턴 매칭을 사용하도록 해서 거대한 케이스 구문이나 조건문이 만들어지는 것을 방지합니다. 프로그램 수준에서는 OTP 컨벤션을 사용하도록 해서 비대한 모노리스 어플리케이션이 되어버리는 것을 막습니다.

다른 언어에서도 코드를 분리하고 관리하는 방법을 제공하긴 하지만, 엘릭서는 그보다 더 나아갑니다. 코드 분리는 엘릭서에서 가장 신경쓰는 요소 중 하나라는 느낌을 받았고, 그만큼 하기도 쉽고 권장됩니다.

저는 언어와 프레임워크가 매우 중요하다고 보는데, 개발자가 코드를 어떻게 바라보고 어떻게 작성하는지에 큰 영향을 주기 때문입니다. 언어나 프레임워크가 어떤 작업을 하기 쉽고 편하게 만드는지는 일반적으로 생각하는 것 이상으로 우리에게 큰 영향을 끼칩니다. 사람의 뇌는 어떤 것을 제대로 분석하기보다는 휴리스틱을 사용해서 손쉽게 판단하는 것을 선호합니다. 그렇기 때문에 언어나 프레임워크가 어떤 기능을 사용하는 것을 다른 것보다 쉽게 만든다면, 우리는 거의 반드시 그 기능을 사용하게 됩니다.

소프트웨어 개발자도 예외가 아닙니다. 레일즈에서 코드를 관리하는 방법에 대해서 리서치할 때, 가장 놀라웠던 것은 레일즈 프레임워크의 목표와 자신이 개발하는 어플리케이션의 목표가 상충해서 코드에 많은 문제가 발생하고 있음에도 불구하고, 이미 개발 경험도 많은 수많은 개발자들이 레일즈의 방식을 계속 따랐다는 것입니다. 정말 더 이상은 방법이 없다는 생각이 들 때까지 따르더군요. 왜 그럴까요? 새로운 방식을 만드는 것보다 기존 컨벤션을 따르는 것이 차라리 더 쉬웠기 때문입니다.

이런 현상이 부정적으로 느껴질 수도 있지만, 반대로 생각하면 제대로 디자인한다면 엄청나게 큰 도움이 될 수도 있다는 가능성도 의미합니다. 이 글에서는 코드 관리에 대한 레일즈 컨벤션을 계속 비판했지만, 웹 어플리케이션의 기본 구조에 대해서는 레일즈 컨벤션은 정말 엄청난 도움이 되었습니다. 웹 개발 방식을 뿌리째 흔들어서 훨씬 긍정적으로 변화시켰죠.

결국 이 모든 것이 의미하는 것은 엘릭서 개발자는 기회가 있을 때마다 매우 높은 확률로 코드를 분리할 것이라는 것입니다. 단순히 엘릭서에서 코드를 분리하는 것이 쉽다는 이유만으로 말입니다. 이는 경험 많은 개발자와 신입 개발자 모두에게 도움이 될 것입니다. 하지만 배움이라는 측면에서 보면 경험 많은 개발자는 어차피 그런 방식에 대해 이미 알고 있기 때문에 크게 새로 배울 내용은 없을 것입니다. 반면 신입 개발자 입장에서는 코드 분리라는 가치있는 기술을 배우고 연습할 수 있게 됩니다. 저도 그럴 수 있었으면 참 좋았을 것 같은데 아쉽습니다.

게다가 엘리서 커뮤니티나 관련 글에서도 모두들 코드를 분리해서 병렬 분산형 프로그래밍을 하도록 권장합니다. 신입 개발자 입장에서는 사용하는 텍스트 에디터, 옆 자리의 동료, 엘릭서 개발 문서, 그리고 인터넷에 있는 알지도 못하는 사람이 모두 한 목소리로 모두 코드를 분리하라고 외치고 있는 상황인거죠. 무엇인가를 빠르게 배우고 체화하기엔 참 좋은 환경입니다.

그리고 시니어 개발자나 회사에서도 이를 통해 누릴 수 있는 이득이 있다고 봅니다. 신입 개발자가 만든 거대한 엉망진창 코드 덩어리를 고쳐야 할 일도 줄어들 것이고, 그들에게 베스트 프랙티스를 가르치기 위해 들이는 시간과 비용도 절약할 수 있을 것입니다.

단점

여태까지 엘릭서의 장점만 실컷 이야기했지만 엘릭서를 첫 언어로 배우는 것에는 당연히 심각한 단점도 있습니다.

가장 치명적인 것은 아직은 엘릭서 관련 일자리가 별로 없다는 것입니다. 어떤 사람이 프로그래밍이라는 새로운 분야에 뛰어들 때 재미로 그러는 사람은 별로 없습니다. 엄청난 시간과 노력을 투자하는 만큼 투자된 비용에 부합하는 효과를 원합니다. 그리고 엘릭서에서는 단기적으로는 이에 대한 확답을 줄 수 없습니다. 하지만 장기적으로는 충분히 가치가 있다고 봅니다.

엘릭서를 배울 수 있는 자료도 적습니다. 현재로서는 튜토리얼 세네 개, 책 대여섯 권, 온라인 코스 두세 개, 스크린캐스트 두세 개 정도밖에 없습니다. 그리고 모두 영어로 되어있는 만큼 비영어권 국가 사람이 배우기엔 쉽지 않을 수도 있습니다.

또한 엘릭서에는 IDE도 없습니다. 프로그래밍을 처음 배우는 사람은 IDE에서 익숙한 GUI를 보는 것만으로도 크게 안심이 됩니다. 엘릭서 REPL을 지원하는 웹사이트도 몇 개 있지만, 결국은 황량한 텍스트 에디터를 사용하는 것 외에는 대안이 없습니다.

2부 요약

  1. 어떤 언어나 프레임워크가 개발자, 특히 초보들에게 얼마나 큰 영향을 미칠 수 있는지는 레일즈가 잘 보여준다.
  2. 엘릭서는 컨벤션과 도구를 내장해서 제공함으로써 코드를 분리하는 것을 “권장”한다.
  3. 엘릭서는 신입 개발자에게 코드를 작은 부분으로 분리하는 습관을 가르치며, 이는 시니어 개발자나 회사에도 이득이 될 수 있다.
  4. 단기적으로는 엘릭서 관련 일자리나 학습자료가 적으나, 곧 훨씬 증가할 것이라고 생각한다.