프로 하스켈러 6주차 — Scotty Web Framework
6월 초 진행한 “제주 웹 컨퍼런스”에 발표자로 참석하느라, 마음의 여유 시간이 부족했다는 핑계로, 오랜만에 “프로 하스켈러” 글을 올립니다. 어차피 매일 이야기를 적겠다는 생각은 아니었고, 매주 한 편 정도는 어쩌면 올릴 수 있을지 않을까 기대합니다. 그러다 또 늘어지면, 한 달에 한 편씩은 가능하겠죠. 어쨌건, 적당한 페이스로 부담 없이 적어볼 생각입니다.
온보딩 교육 2주 종료
어느새 팔자 좋은 2주간의 온보딩 기간이 다 끝났습니다. 하스켈 기초부터, 현재 개발된 배포 및 운영 환경 활용까지 배워본 즐거운 여정이었습니다. 사실 경력 개발자에게 온보딩 기간을 2주나 주는 것은 과한 친절인 것 같습니다. 아마도 하스켈 특수가 아닐까 해요. 하스켈을 프로덕션 레벨로 활용하는 개발자는 (거의 확정적으로) 없을 테니, 다른 언어를 활용하던 백엔드 개발자를 영입해서 하스켈부터 익히게 해주는 전략 측면에서는, 좋은 접근법 같습니다. 그 말은 즉, 하스켈 실무 경험 없어도 입사 가능하다는 말씀입니다. 와서 열심히 하면 됩니다. 선지원 후고민입니다. 고민은 배송을… 아니 입사를 늦출 뿐입니다.
프로 개발자
그리고, 그 사이 월급이 들어왔습니다. 하스켈 코딩을 하며 월급을 받았으니, 본격 프로 하스켈러 맞다고 주장해 봅니다. 언젠가 실력도 프로가 될 겁니다. 프로의 기준으로 가장 쉬운 것은, 전업으로 생활하느냐 아니냐인 것 같습니다. 프로가 되려면 특정한 자격을 갖추고 라이선스를 받아야 하는 분야도 있는 것 같습니다만, 개발자는 심지어 자격증도 필요가 없습니다. 제가 만약 노래, 연기, 스포츠, 게임 등을 전업으로 하려면 엄청난 실력과 대단한 운이 받쳐줘야 하는 거잖아요? 그런 분야에 비하면야, 개발은 매우 쉽죠. 그러니 제가 “프로” 하스켈러일 수 있는 것 같습니다. 월급 받으며 생활하시는 개발자분들 모두 자존감을 더 높입시다.
우린 모두 프로 개발자입니다.
GitHub Actions
현재 백엔드 시스템 배포 환경은 GitHub Actions로 구축되어 있어서, 이번 기회에 연습해 볼 수 있었습니다. 이미 잘 세팅해 둔 것을 그대로 따라한 것이라 더 그렇게 느껴졌겠지만, 아주 매끄럽게 잘 배포되고, 설정도 직관적으로 이해하기 좋았습니다. 다만, 깃헙이 자체적으로 이런 서비스를 제공하는 것은, 소비자로서는 매우 환영할 만한 좋은 일입니다만, 이걸 서비스 사업으로 하던 TravisCI 같은 업체들은 이제 어쩌라는 말인가 싶은, 남 걱정이 들기도 합니다.
플랫폼 사업자가 써드파티 업체들에게 사업할 기회를 열어 놓고는, 그중 잘 되는 열매가 열리면, 쏙 따다가 자기 밭에 심어 버리다니, 마음 한 구석 씁쓸하기도 합니다. 이것이 써드파티 서비스의 숙명인가 싶기도 하고요. 그렇다고, 제가 소비자 입장에서 기존 써드파티 서비스를 응원하는 마음이라며 그걸 쓸 것도 아니니, 괜한 고민 같습니다. 결국 그냥 GitHub Actions 쓰겠죠. 이미 TravisCI 같은 써드파티 서비스를 잘 쓰던 팀들은, 굳이 이전할 이유까지는 없을 테니, 기존 고객들이 크게 이탈하지는 않으리라 기대합니다. 더 이상 큰 성장을 하지 않을 뿐, 안정적으로 수익을 내는 건 문제없을 겁니다. 제가 할 걱정이 아닙니다.
Servant — A Type-Level Web DSL
혼자 하스켈 연습할 때는 웹 프레임워크로 Servant를 사용해 보았습니다. 타입 레벨로 Route를 선언하는 흥미로운 접근이 인상적이었습니다. 뭔가 탄탄하게 선언해서 개발하는 것은 믿음직스럽습니다만, 아직 “깐깐한” 타입 선언에 익숙치 않은 입장에서는 그 타입을 맞춰서 코딩하는 게 다소 부담스러운 면도 있었습니다. 하스켈 코딩의 일반적인 느낌이기도 합니다.
컴파일되는 타입을 맞추기가 힘든데, 일단 컴파일되고 나면, 런타임에는 어지간하면 잘 돈다.
조삼모사, 어차피 힘들게 개발해야 하는 건 같은 느낌도 듭니다. 하지만 보통은, 소프트웨어의 어떤 문제든 개발 과정의 앞 단계에서 발견될수록 해결 비용이 저렴하니까요, 컴파일 타임을 힘들게 거치는 것이 전체적인 비용 측면에서는 유리할 거라고 생각해 봅니다.
Scotty — Haskell Web Framework
타입 레벨 라우트를 선언하는 Servant와는 다른 접근으로, Ruby의 Sinatra나 Node의 Express 같은 방식으로 처리하는 Scotty라는 프레임워크도 있습니다. 마치, Sinatra 코드를 보는 것처럼 유사합니다. 모나드를 활용한 명령형 프로그래밍 스타일로 흐름대로 읽고 쓰기도 좋습니다. 저도 Ruby 쓰던 시절에 Sinatra를 즐겨 썼었기 때문에 더 반갑습니다.
조금씩이지만, 둘 다 써본 입장에서 보자면, Scotty가 코드를 작성하기에는 더 편하고, 문서는 Servant가 더 잘 되어있는 것 같습니다. 더 하스켈스러운 방식은 아마도 Servant 쪽이 우세한 것 같습니다. 어차피 저희는 GraphQL서버를 만드는 입장이라 HTTP 엔드포인트나 라우트들은 크게 복잡하거나 많지 않기에, 간단한 Scotty를 쓰면 되는 것 같습니다. 심지어 그냥 WAI 기본 서버로 WARP를 직접 써도 될 것 같습니다.
저보고 다시 고르라면, GraphQL 서버를 만든다면, Scotty나 WARP를 직접 쓰고, REST API 서버를 만든다면 Servant를 사용하겠습니다.
첫 이슈 처리
온보딩 교육 종료 후, 첫 번째 이슈를 처리해 보았습니다. GraphQL 응답에 에러를 다루는 부분을 살짝 바꾸는 내용이었는데, 간단한 내용이지만,
- 그래도 이제서나마 밥값을 시작하는 것 같아 기뻤고,
- 컴파일되고 나니, 런타임 확인을 안 해도 될 정도로 잘 돌더라.
는 점이 인상적이었습니다.
그럼, 오늘은 여기까지.
