본문 바로가기

나의 이야기/보통의 존재

루비 개발자가 파이썬 개발자가 된다면?

나는 2015년도에 스타트업에서 백엔드 엔지니어로서 처음 프로그래밍 일을 시작했다.
2010년대 초에는 가독성이 높고, 생산성이 높은 웹 프레임워크가 인기를 끌었다. 루비온레일즈도 그 중 하나였고, 당시에 시작된 많은 스타트업에서 루비온레일즈를 주력 언어로 채택하고는 했다. 첫 직장도 이러한 배경으로 루비온레일즈를 주 언어로 사용했다. 그래서 메인 서비스가 루비온레일즈로 구현되었고, 이 곳에서 3년간 루비를 사용했었다.

드라마 실리콘밸리 리처드

나는 루비의 긱한 이미지와 희소성을 좋아한다. 드라마 실리콘밸리의 주인공인 리처드도, 처음에는 루비로 프로그래밍을 시작했다. 그래서 루비가 더 특별하고 재미있게 여겨졌다.
그리고 루비의 동글동글한 문법과, 한 편의 글을 쓰듯이 프로그램을 작성할 수 있단 점을 좋아한다. 그 중, 테스트 프레임워크인 Rspec을 사용할 수 있다는 점이 가장 좋았다. Rspec을 사용하면 BDD 기반으로 생각을 정리하며 유닛 테스트를 작성할 수 있었다.
그러나 몇가지 아쉬움도 있었다. 가장 큰 이유는 프로그래밍 언어 시장에서 루비가 점점 비주류가 되어간다는 점이었다.
이 때문에 최신 기술을 사용하는 데에 제약이 생기고는 했다. 루비를 지원하지 않는 라이브러리가 많았고, 레퍼런스 자료와 전문 서적이 부족해서 어려움을 겪었다. 그래서 루비로 만들어진 오픈소스를 발견할 때마다 내 편을 만난 듯한 반가움이 들고는 했었다. Gitlab과 AWS Code Deploy Agent가 그러했다. 이러한 루비의 특별함과 비주류의 사이에서 나는 갈팡질팡했다.
그러던 중 머신러닝, 딥러닝이 뜨면서 파이썬이 인기를 끌기 시작했다. 파이썬/장고 커뮤니티가 활성화되는 모습을 보며 부러운 마음이 들기도 했다. 이후 나는 파이썬과 장고를 사용하는 커머스 회사로 이직하게 되었다.
루비와 파이썬은 모두 인터프리터언어이고, 간단하고 쉬운 문법을 지향한다. 그래서 두 언어의 차이를 크게 느끼진 않았다. 코드를 보고 “이건 루비스럽지않아”라고 말하던 환경이, “이건 파이써닉 하지않아”로 바뀌었다. 그 만큼 두 언어가 지향하는 바가 유사하다는 생각이 들었다.
대신 “루비온레일즈”와 “장고”의 차이점이 인상깊었다.
나에게 장고의 첫인상은 조금 오묘했다. 괴상해보이지만, 어느 한편으로는 친근했다. 루비온레일즈와 장고는 마치 형제처럼 보였다. 루비온레일즈가 첫째, 장고가 둘째..?
장고는 루비온레일즈의 장점을 대부분 갖고 있었다. 그래서 루비온레일즈에서 사용하던 몇가지 패턴들을 장고에 그대로 적용할 수 있었다. 그러다보니 장고에 빠르게 익숙해질 수 있었다.
그리고 장고는 상대적으로 루비온레일즈보다 여러 도메인을 관리하기 편했다. 하나의 프로젝트에서 여러개의 앱을 구성할 수 있다는 점, 비즈니스 로직 구현에 집중할 수 있도록 반복되는 코드들이 패턴화 되었다는 점 덕분이다.
장고의 DRF 프레임워크를 사용하면 권한, 필터 등을 쉽게 추가할 수 있다. 그리고 장고의 Form을 사용하면, 데이터 검증, 비즈니스 로직 통합 등이 편했다. 그리고 멀티앱 구조 덕분에 여러 도메인을 쉽게 관리할 수 있고, 나중에 별도의 앱으로 분리해내기도 상대적으로 용이했다.
반면 루비온레일즈는 하나의 프로젝트에 하나의 앱으로 구성되어있다. 그리고 장고보다 좀더 자율성이 높은 편이었다. 그러다보니 여러 도메인이 섞이게 되고, 쉽게 중복코드가 발생하게 되고, 코드가 파편화되는 현상이 발생하고는 했었다.
지금은 루비온레일즈의 장점은 대부분 갖고 있고, 단점은 극복한 장고가 편하고 유용하다. 그러나 여전히 몇가지 어려움은 있다.
장고의 반복 작업 패턴화는 편하고 유용하지만, 처음에는 이 패턴들이 괴상하게 느껴졌었다. 지정된 위치에 클래스를 상속받고, 변수를 선언하면, 기능이 알아서 완성되는 매커니즘이 이해되지 않았기 때문이다. 처음에는 이 매커니즘을 이해하고 싶었지만, 자료를 찾기 어려웠다. 그래서 일단 장고의 패턴을 외우고, 쓰면서 원리를 이해하는 방향으로 공부를 했었다.
그리고 장고의 패턴이 편의성과 표준화의 장점이 있지만, 자율성을 떨어트린다는 단점 또한 있었다. 정해진 방식과 다르게 함수를 커스텀하기 어려웠다. 그리고 추상화된 함수의 동작원리를 모르는 채로 사용하면, 성능이 현저하게 떨어지거나 예상하지 못한 방식으로 데이터가 처리되는 경우도 있었다. 그래서 꼼꼼히 호출 스택을 디버깅하면서, 의도한바대로 코드가 동작하고 있는지 점검하는 습관이 생겼다.

마치며

  • 루비 3년, 파이썬은 2년째 사용하고 있다. 
  • 아직 "루비스럽다"와 "파이써닉하다"의 차이점은 모르겠다. 
  • 개인적으로 파이썬 보다는 루비가 좋고, 루비온레일즈보다는 장고를 좋아한다.
  • 그러나 파이썬의 커뮤니티는 넘사벽이다.
    • 특히 데이터 프로그래밍에 대한 접근성이 높아졌다.
      • Google Colab, 머신러닝, 딥러닝, NLP 등을 활용할 때 최고다.
      • 코드도 술술 읽히고, 오픈소스도 쉽게 사용할 수 있다.
  • TMI: Rspec에 팩토리봇 (팩토리걸)이 있다면, Pystest에는 팩토리보이가 있다.
    • 팩토리봇은 팩토리보이의 원조급 라이브러리이다.
    • 2017년에 "팩토리걸"이 "팩토리봇"으로 이름이 바뀌었는데, 이름의 유래는  여기 에서 읽어볼 수 있다. 
    • "팩토리걸"<>"팩토리보이"으로 이름 라임을 맞췄던 것 같은데, 이제 라임이 깨졌다. 


<끝>