자금 여력이 넉넉하지 않은 소규모 웹 벤처や 프리랜서가 실무에서 Haskell을 썼을 때의 현실과 시행착오, 그리고 버티며 얻은 교훈을 공유합니다.
제 본업은 낙농이고, 염소 사쿠라짱을 돌보는 게 일입니다만, 그것만으로는 먹고살기 어려운 게 세상살이의 슬픈 이치라서, 부업으로 프리랜스 IT 컨설턴트(겸 프로그래머)를 하고 주식회사 UZUZ라는 회사의 히키코모리계 최고기술책임자로서 Haskell과 Elm을 업무에 쓰고 있습니다.
또, 개인적인 취미로 주식회사 ARoW라는 직원 2명의 아주 작은 웹계 회사를 실험적으로 운영하고 있고, 거기서도 메인으로 Haskell을 쓰고 있습니다.
Haskell을 실제로 소규모 회사나 프리랜서로 쓰는 사람은, 사실 세상에 거의 없는 듯합니다.
그래서 실제로 “Haskell이 자금력이 없는 회사나 개인이 업무에서 쓸 수 있는 거냐?”라는 의문에 대해 솔직하게 답해보려 합니다.
먼저, Haskell 커뮤니티의 일본 내 현황에 대해 이야기합니다.
아시는 분도 많겠지만, 일본에서 Haskell을 빡세게 실무 활용하는 회사를 아래에 적어봅니다.
아사히넷
IIJ
Tsuru Capital
워크스애플리케이션즈
실제로 어떤 기업에서 어떻게 유효하게 활용되는지는 @syocy 님이 정리해 준 글을 참고하세요.
다만 보시다시피 어디나 회사로서 자금 원천이 든든한 곳들뿐입니다.
반대로 웹계 벤처가 Haskell을 대대적으로 쓰고 있다는 이야기는 국내에서는 거의 들리지 않습니다.
GREE가 한때 Haskell을 썼던 것 같지만, 그 이후로는 소식이 없네요...
또, 스포츠 경력이 있는 엔지니어를 환영한다는 어떤 회사가 Haskell과 Elm으로 낚는 구인 공고를 냈지만, 지원하면 엔지니어가 아닌 사장이 혼자 짜놓은 위태로워 보이는 PHP의 유지보수를 시킨다는 소문도 있습니다.
역시 Haskell을 채택해서 비즈니스적으로도 수지가 맞는 것은 돈이 넉넉한 기업뿐인 걸까요.
설이 분분하긴 하겠지만, 현재로서는 Haskell에 관심을 보이고 깊게 관여하는 사람들의 대부분이
라는 부류로 구성되어 있다는 인상입니다.
마치 PHP나 Rails 쪽이 “아무튼 빨리 돈이 되지 않으면 의미 없다”는 분들이 주류라서, 실무 이용을 열심히 고민해주는 한편, 어쩔 수 없이 기초 기술이 소홀해지는 경향이 있는 것과는 반대로, Haskell 쪽은 그 반대의 상황이랄까요.
(개인적인 감상입니다)
물론 기초 기술이 허술해지면 어떻게 되는지는 말할 필요도 없지만, 이런 상황 탓에 웹계 벤처가 Haskell을 실무 도입하려 하면 엄청 고됩니다.
이 부분에 대해서는 @melpon 님이 Wandbox 관련 글의 댓글로 보태주신 내용이 많은 것을 말해줍니다.
실제로, Haskell계에서 고참이고, 다들 습관처럼 써버리는, Rails가 되고 싶었던 타입의 웹 프레임워크인 Yesod는 실무에서 쓰려 하면 똥입니다.
물론 “프런트엔드는 절대 하기 싫어맨”이 취미로 프로덕트를 만드는 용도라면 이만큼 든든한 것도 없습니다만, 한편으로는 Webpack 같은 것과의 병용은 전혀 염두에 두지 않은 듯한 Shakespeare라는 나만의 템플릿 엔진을 권장한다든지(자세한 내용), JSON을 돌려주는 방법이 공식 튜토리얼에서 홀대받아 진짜 암흑이었다든지(지금은 어떤지 모름), “너희 프런트엔드에 관심 너무 없지 않냐” 감이 넘칩니다.
이건 Haskell계에 “프런트엔드는 절대 하기 싫어맨”이 많은 것이 모든 악의 근원이라고 봅니다.
물론 전설의 @notogawa 님처럼 공학부 수학과(속칭) 출신으로 이론에도 강하고 프런트엔드도 소홀히 하지 않는 분들도 물론 있습니다.
저는 예전부터 Haskell에 가능성을 느껴 꼭 쓰고 싶었는데, 처음 들어간 “예전엔 연구 부서에 Haskeller가 잔뜩 있었지만 대부분 다 도망친” 회사에서 연수 중에 좌천당하는 일도 있었고, 그 뒤로 부동산 영업을 하다가 결국 회사원으로 사는 걸 그만뒀습니다.
별수 없이 영업 경험과 문제 해결력을 살려, 무엇을 만들지(혹은 만들지 말지)부터 상담할 수 있는 프리랜스 프로그래머로서의 삶을 시작했습니다.
프리랜서라 결과를 못 내면 일이 끊기지만, 그 속에서 Haskell을 써가며 어떻게든 살아왔습니다.
그리고 겸사겸사 취미로 하는 회사도 최근 흑자 전환이 보이기 시작했습니다.
살아올 수 있었던 비결을 몇 가지로 정리해봅니다.
* 정말 필요한 부분에만 Haskell을 쓰면 된다
* 결과적으로 많은 신규 프로젝트는 백엔드가 Haskell이긴 하지만!
* 그래도 GHCJS 같은 건 손대지 않고 Elm을 쓰고, CSS나 바닐라 JS도 꽤 쓴다
* 기존의 의미 모를 고대 언어 프로젝트도, 갈아엎는 것보다 그대로 덧대는 편이 종합적으로 좋을 때는 그대로 덧대며 때를 본다
2. 기술 선택을 게을리하지 않기
* 다들 Yesod를 쓴다고 해서 그게 적합하다는 뜻은 아니다
3. 최악의 경우 직접 만들 각오를 갖기
* 앞서 말한 상황 때문에, 제대로 된 라이브러리가 없는 분야도 존재한다
4. 근성으로 장기적인 투자를 계속하기
취미로 하는 회사는 약 2년간 임원 보수를 0원으로, 직원에게 지급하는 돈은 제가 프리랜서로 벌어들인 사재를 투입해 운영해 왔습니다. 죽을 뻔했습니다.
그 결과, 가까스로 최근에서야 흑자화가 보이고 있습니다.
또 사실 사재를 투입해 엄청난 실력의 직원 데니스 씨에게 이것저것 조사해 달라고 한 덕분에, 프리랜스나 CTO 일 쪽의 성과가 엄청 올라 그쪽에서 먼저 회수되기도 했습니다.
투자 기간은 어쩔 수 없이 길어지므로, 그걸 견딜 수 없다면 Haskell 같은 데에 어중간하게 손을 대서는 안 된다고 생각합니다.
반대로 그걸 근성으로 버틸 수 있다면, 분명 엄청 해피한 무언가가 될 겁니다.
어떤 해피가 될지는 “보통 녀석들을 앞서 가라”에 쓰여 있는 것과 가까울 것 같습니다.
그런데요, 여기만의 이야기지만, 스스로 근성으로 어떻게든 하기보다 이미 사재로 어떻게든 굴려서 노하우를 가진 사람에게 돈을 맡기는 쪽이 가성비가 좋다고 생각합니다. 제 입장상 반은 영업이긴 한데, 반은 진심으로 그렇게 생각해요
왜냐면, 이 이상 Haskell로 힘든 경험을 하는 사람이 늘어나는 걸 보고 있자니 저도 힘들거든요.
이상, 염소를 기르면 장기적인 투자가 필요한 Haskell의 실무 활용에서도, 정신의 안정을 지킬 수 있고 사쿠라짱 귀여워! 우헤헤헤!!
오해가 있을 수 있어 덧붙이자면, 염소는 거친 먹이에도 견디는 동물이라 전후 물자가 부족하던 시절에는 그 성질을 이용해 우유를 목적으로 염소를 기르는 가정이 많았습니다.
그래서, Haskell에 투자하느라 살림이 빠듯해져도 염소는 가계에 큰 부담을 주지 않습니다.
이 글을 공개하고 대략 1년이 지났기에 그 후 어떻게 되었는지의 추기입니다.
스스로 뚜껑을 열고 물을 마셔요#사쿠라짱일기pic.twitter.com/YtJMVeIz41
— 🐐야기 마법소녀 퓨어 펑셔널(사쿠라짱) (@arowM_) 2018년 5월 12일
체중은 당시 16kg에서 25kg이 되어 대략 라브라도 리트리버 정도의 무게가 되었습니다.