흔해빠진 말이지만 저도 제 일을 하는 게 꿈입니다. 이미 한 번 꽤 무모하게 시도해봤고 실패했죠. 배운 건 많았지만 매우 고통스러운 경험이었습니다. 그래서 이제는 조금 더 계획적으로 접근하고 있습니다. 프로덕트 매니저로 일하기로 결정한 것도 그 일환이구요. 이번 롤에서 바란 것은 성공하는 제품을 그려내고, 계획하고, 실제로 만들어내는 방법을 배우는 것이었습니다. 이제 1년 반 가까이 PM으로 일해왔는데, 무엇을 얻었고 이어서 무엇을 할지 회고해보기 좋은 시점이라고 생각해서 이 글을 씁니다.

마지막으로 글을 쓴 지 2년이 지났는데, 감사하게도 그 동안 다음 글은 언제 나오냐고 생각보다 많은 분들이 물어봐주셨습니다. 이제야 드디어 다음 글을 쓰네요. 네, 제목에 적힌 대로 이직을 하면서 프로덕트 매니저로 직종을 옮겼습니다.

이 모든 것은 블로그 글에 삽입한 엘름 코드에 코드 하이라이트가 안 된다는 것을 알아차렸을 때 시작되었습니다. 문제의 근원은 간단히 확인할 수 있었습니다. 기존 블로그는 지킬 및 보조 라이브러리를 모아둔 Github Pages 젬을 사용해서 만들었는데, 이 중 코드 하이라이트를 담당하는 rouge 라이브러리가 엘름 문법을 지원하기 이전인 2.2.1 버전으로 고정되어 있었습니다. rouge 버전을 강제로 올려서 간단히 해결할 수도 있었겠지만, 이 참에 아예 Github Pages 젬을 빼버리고 모든 의존성을 최신 버전으로 올려버릴까? 라는 생각이 들었습니다. 그렇게 야크 털 깎기가 시작되었습니다.

Elm Architecture에서 update 함수는 Model 상태를 변경하는데 사용됩니다. Model, Msg, update의 구조에 따라서 update 함수를 호출한 뒤에 다른 Msg를 인자로 삼아 update 함수를 다시 호출해야할 수도 있습니다. update를 재귀적으로 호출하는 것은 간단히 할 수 있습니다.

엘름에서 포트 함수 관련 코드를 어떻게 하면 깔끔하게 관리할 수 있을지 고민하다가 두 가지 방식을 정리해보았습니다. 독자가 엘름 아키텍처와 포트 함수의 동작 방식 등은 이미 알고 있다고 가정하겠습니다. 깃헙 리포에 예시 앱을 올려두었으니 아래와 같이 받아서 실행해보실 수 있습니다.

엘름 디버거는 제가 써본 중 가장 우수한 디버거입니다. 엘름 언어 자체 특성 때문에 개발 과정에서 버그가 생길 일이 거의 없어서 사실 디버깅할 일이 없는게 함정이지만요. 엘름 디버거는 표시 가능한 문자열 길이에 제한을 두고, 지정된 길이를 넘어가는 문자열이나 자료 구조는 ...으로 생략해버립니다. 합리적인 기본값이긴 한데 가끔 내가 정확히 어떤 메시지를 받았는지 알고 싶을 때는 짜증을 유발합니다. 리처드 펠드먼의 RealWorld 샘플 앱에서 디버거가 긴 문자열을 생략하는 예시를 봅시다.

Vim에서 하스켈 개발 환경을 설정하다가 짜증이 나서 대안을 찾다가 Spacemacs를 설치해서 사용해보고 있는데, 별도의 설정 없이 설치하자마자 바로 쓸 수 있을 정도로 기본 설정이 훌륭해서 현재까지는 만족스럽게 쓰고 있습니다. 다만 한국어를 설정하는 방법이 옛날 글만 있거나 이맥스 초보가 이해하기 어렵게 작성되어 있어서 좀 헤멨습니다. 문서를 찾아보면서 어느 정도 원하는 대로 설정하는데 성공해서 설정을 공유합니다. 한국어 글꼴은 D2Coding을 사용하고 있는데 원하시는 글꼴을 설치해서 사용하시면 되겠습니다.

환경은 Ubuntu 16.04.4, Emacs 26.1입니다.

예전에 CSS보다는 하스켈이 차라리 더 쉽다는 농담을 들은 적이 있는데, 당시에는 그냥 웃어 넘겼었습니다. 하지만 지난 몇 달 동안 CSS를 작성해보았더니 왜 그 사람이 그런 말을 했는지 이제는 이해할 수 있습니다. CSS는 복잡합니다. 문법과 구조는 간단하지만 결과물이 런타임에 따라 천변만화하기 때문에 어떤 결과물이 나올지 예측하기 정말 어렵습니다.

세 가지 문제

제가 보기엔 문제의 원인은 크게 세 가지로 나눌 수 있습니다.

1. 어떤 CSS 규칙이 최종적으로 적용될지 예측하기 어렵다
2. CSS 규칙의 상호작용을 모두 알기 어렵다
3. 런타임 환경을 예상하기 어렵다

서문

작년에 이드리스 언어에 관한 책을 한 권 읽고 블로그 글을 한 편 작성한 적이 있습니다. 그리고 그 글을 쓴 지 얼마 되지 않아 우연히 블록체인 기술을 다루는 회사에 입사해서 일을 하기 시작했습니다. 그러니 제가 최근 흥미를 가진 이 두 가지 주제를 함께 다룬 “Safer smart contracts through type-driven development: Using dependent and polymorphic types for safer development of smart contracts”라는 논문이 있다고 들었을 때 꼭 읽어봐야겠다는 생각을 하게 되었습니다.

이 글은 해당 논문을 읽으면서 가지게 된 생각을 정리한 글이며, 논문 내용에서 한 발짝 더 나아가거나 한 내용은 없습니다. 또한 글을 쓸 때 함수형 프로그래밍 패러다임, 특히 순수 함수와 사이드 이펙트 사이의 차이점에 대한 기본적인 이해를 가정하고 작성했으니 감안하고 읽어주시기 바랍니다.

요약

엘름 언어에 대해서 기본적인 것을 배우고 나서 엘름 코드를 읽다보면 >>, <<, |>, <| 같은 기묘한 연산자를 보게 되는데, 이는 함수를 조합하거나 적용할 때 사용되는 함수입니다. 이 글에서는 제가 해당 연산자를 언제 어떻게 쓰는지에 대해서 간단히 이야기해보겠습니다. 하지만 먼저 간단히 요점만 정리하면 다음과 같습니다.

1. |>와 <|는 데이터의 흐름을 시각적으로 명확히 표현하고 싶을 때 사용합니다. 괄호를 중첩해서 사용해도 똑같은 의미를 나타낼 수 있지만 |>나 <| 연산자를 쓰면 더 명확합니다.

2. >>와 <<는 데이터 흐름과는 무관하게 함수의 조합만을 표현하고 싶을 때 사용합니다. 실제 코드에서는 함수 조합을 통해서 새 함수를 정의하고, 그 함수를 |>나 <|와 함께 사용합니다.

3. |>와 >>의 쌍이나 <|와 <<의 쌍만 사용하고, 둘을 섞어서 사용하지 않습니다. 연산자의 모양이 방향에 대한 의미를 내포하고 있기 때문에 서로 다른 방향을 나타내는 연산자를 섞어 쓸 경우 뇌에서 인지적 자원을 더 소모하게 됩니다.