Hyeseong's Blog

컨텐츠 압축을 위한 배경지식

Sat, 24 Feb 2024 00:00:00 GMT

다양한 시스템에서 데이터를 다룰 때 내용물을 더 작은 용량으로 보관/전송하기 위해 컨텐츠를 압축(Compression)하는 것이 일반적입니다. 일상적으로 접하는 미디어 파일부터, 데이터베이스 시스템, 웹 서비스까지 압축 기술이 적용되지 않는 곳을 찾는게 더 어렵습니다.

웹 서버에서도 응답 압축을 적용하는 것 만으로 트래픽 비용이 70%까지 감소하는 등 적용 시 영향도가 매우 큰 편입니다. 그럼 뭐든지 다 압축하면 좋을까요? gzip을 쓰면 될까요? 그렇게 쉽지는 않습니다.

제가 압축 기술 전문가는 아니지만 한 번 알아본 것들을 어딘가 적어두면 나중에 재탐색이 수월해질 것 같아 글로 남깁니다.

면책조항: 이 글은 어디까지나 판단에 앞서 도움되는 배경지식을 제공하기 위한 목적으로만 작성되었습니다. 이 글의 내용은 직접 수행한 벤치마크를 포함하지 않으며 "가장 좋은 압축 방식"을 소개하지도 않습니다. 적절한 압축 기술은 대상 컨텐츠의 형식, 시스템 아키텍처, 장치 사양 등 상황에 따라 매우 달라질 수 있습니다. 모든 기술이 그러하듯 압축 적용 전에는 반드시 실제 상황에 가까운 벤치마크가 선행되어야하고, 또 어울리지 않는 곳에 일률적으로 적용하는 것을 피해야 합니다.

손실 압축 vs 비손실 압축

컨텐츠를 압축할 때 내용물을 손실을 감수하느냐 여부로 손실(Lossy) 압축과 비손실(Loss-less) 압축으로 구분할 수 있습니다.

컨텐츠 중에서도 시각과 청각에 의존하게 되는 이미지, 오디오, 비디오 같은 미디어 컨텐츠는 잘 알려진 인간의 인지적 한계를 응용하여 불필요한 정보를 버리는 손실 압축 방식을 선택합니다.

반면 부호(code)인 텍스트나 기계들이 주고받는 데이터에서는 작은 손실도 의미를 손상시킬 수 있기 때문에 비손실 압축 방식을 선택합니다. 비손실 압축은 데이터의 일부를 대치하는 등 여러 기법으로 표현을 바꾸고, 사용하는 쪽에서 다시 원래의 표현으로 복원합니다.

당연하게도 비손실 압축이 더 범용적이며, 형식을 가리지 않고 널리 활용되고 있습니다. 손실 압축에 사용되는 기법도 파고들면 굉장히 흥미로운 주제이나, 이 글에서는 비손실 압축을 위주로 다뤄보도록 하겠습니다.

비손실 압축 형식 살펴보기

압축 과정에서 인코딩/디코딩의 속도와 결과물을 압축비율은 트레이드오프 관계이며 상황에 따라 필요한 선택이 달라질 수 있습니다.

또한 압축 형식이 얼마나 오래/널리 사용되었냐에 따라 생기는 이식성의 차이도 주요한 고려사항입니다. 현대적인 알고리듬일 수록 성능이 더 좋지만 이식성이 떨어지는 경향이 있습니다. 더 이식성이 높은 형식을 사용하기 위해 오래된 형식을 지원하는 더 최적화된 구현을 만드는 경우도 있습니다. (예시: pigz - 멀티코어를 활용하여 최적화된 gzip 구현)

반드시 어떤 형식이 더 낫거나 빠르다고 단정할 수는 없지만, 잘 알려진 알고리듬/구현체를 살펴보면 탐색에 도움이 됩니다.

Deflate / Gzip / Zlib

Deflate는 압축 속도와 압축률 사이의 적당한 균형을 추구하는 알고리듬입니다.

LZ77와 허프만 코딩이라는 알고리듬을 응용하여, 자주 반복되는 단어를 부호화하는 "동적 사전" 방식을 사용합니다.

관련하여 3가지 파일 형식(Zlib - RFC 1950, Deflate - RFC 1951, Gzip - RFC 1952)을 찾아볼 수 있지만, 무결성 검사 방식 등 사소한 디테일 차이를 제외하면 모두 Deflate(RFC 1951)에서 정의한 방식으로 구현되기 때문에 흔히 "Deflate 알고리듬"으로 통칭됩니다.

이 3가지 형식을 지원하는 zlib이라는 레퍼런스 구현체가 가장 보편적으로 쓰입니다.

용어가 헷갈릴 수 있는데 정리해보자면,

압축 방식 (알고리듬): Deflate
압축 형식 (포맷): Zlib(거의 안쓰임), Gzip(가장 널리 쓰임), Deflate
레퍼런스 (구현): zlib

레퍼런스 구현체인 zlib은 다양한 언어 런타임/웹 서버 등에 기본적으로 탑재되어 있어, 오늘날 HTTP 기반 대부분의 인프라가 zlib에 의존한다고 봐도 무방할 정도로 보편적입니다. (Node.js 표준 API 중 압축 관련 유틸리티가 node:zlib이라는 이름으로 제공되는 이유도 대부분 zlib의 바인딩이기 때문입니다)

zlib은 속도와 압축률을 조정할 수 있도록 1(가장 적게 압축하지만 빠름)부터 9(가장 많이 압축하지만 느림)까지 압축 수준(Compression Level) 옵션을 제공합니다. 압축 수준이 올라갈 수록 압축률이 완만하게 높아지는 대신 속도가 가파르게 떨어지기 때문에 둘 사이의 비율을 보며 상황에 맞춰 적절한 압축 수준을 선택하는 것이 필요합니다.

널리 쓰이는 아카이빙 포맷인 ZIP, 미디어 포맷인 PNG의 압축에도 Deflate 알고리듬이 쓰입니다. 이처럼 Deflate는 대중적이면서도 오래되었기 때문에 많은 환경에서 기본적으로 탑재되어 이식성이 뛰어나다는 장점이 있습니다.

Brotli

Brotli(RFC 7932)는 구글에서 공개한 웹 에셋 최적화된 압축 형식입니다. 마찬가지로 구글에서 공개한 WOFF2 웹 폰트 형식의 내부 데이터를 위한 압축 기술로 처음 소개되었습니다.

Deflate와 마찬가지로 LZ77과 허프만 코딩을 사용합니다. Brotli는 여기에 컨텍스트 모델링이라는 기법과 개선된 사전 기술을 결합합니다.

Brotli는 기존 LZ77에서 사용되는 창(sliding window) 크기를 대폭 키워(최대 16MB) 효율을 개선합니다. 그리고 자주 사용되는 선별된 단어들을 포함한 "정적 사전"을 추가로 사용하여, 작은 페이로드처럼 컨텍스트가 부족한 상황에서의 압축 효율도 개선했습니다.

이런 특징들로 인해 Brotli는 인코딩/디코딩에 필요한 자원 소모량이 일반적으로 Gzip보다 크지만 평균 압축률이 더 뛰어나다는 장점이 있습니다. 특히 정적 사전 덕분에 HTML, CSS, JavaScript, JSON 등 웹에서 쓰이는 형식을 잘 지원하고 작은 페이로드에서도 어느 정도의 품질을 보장합니다.

zlib과 마찬가지로 압축 수준을 조정할 수 있으며 조금 더 세분화된 1–11 값을 제공합니다.

LZMA

UNIX 계열에서 XZ라는 형식과 7-Zip 프로그램의 7z 형식에서 사용되는 LZMA라는 알고리듬도 있습니다. 전송 계층에선 거의 사용하지 않지만, 비교를 위해 언급해보겠습니다.

LZMA는 인코딩/디코딩에 더 큰 비용이 들지만 Deflate 보다 더 큰 압축률을 보입니다. 이런 특성에 따라 파일 아카이빙이나 일회성 전송을 목적으로 주로 사용됩니다. (e.g. *.tar.xz)

LZO

반대로 빠른 속도에 중점을 둔 압축 방식도 있으며 대표격으로 LZO 알고리듬이 있습니다. 뒤에서도 언급하겠으나 인코딩/디코딩 속도를 높이거나 CPU/메모리 자원을 아끼는 것이 더 주요할 때도 있습니다.

LZO는 Deflate에 비하면 압축 비율이 매우 떨어지는 편이지만(통상 gzip으로 60~70% 압축할 때 20~30% 만 압축됨), 매우 빠른 인코딩/디코딩 속도를 제공합니다.

LZO는 zlib만큼 오래되었고 널리 사용되기 때문에 다양한 플랫폼에 기본적으로 탑재되어 이식성이 뛰어나다는 장점이 있습니다.

Snappy

Snappy는 구글에서 공개한 압축 라이브러리로 LZO와 마찬가지로 빠른 속도를 위해 최적화되어 있습니다. 구글 내부에서 사용하는 Bigtable이나 LevelDB의 내부 데이터 압축을 위해 사용된다고 알려져 있습니다.

LZ4

LZ4는 데이터 압축 전문가인 Yann Collet이 개발한 고속 압축 알고리듬/라이브러리입니다. LZO나 Snappy와 마찬가지로 Deflate 대비 압축률이 많이 떨어지지만 인코딩/디코딩 성능만큼은 알려진 구현체 중 가장 빠른 편에 속합니다. 멀티코어에 최적화된 구현으로 추가 자원을 써서 속도를 더욱 가속할 수도 있습니다.

앞서 소개한 LZO와 Snappy보다 대체로 뛰어난 퍼포먼스를 보여주기에 인코딩/디코딩 성능이 중요한 다양한 데이터 시스템의 압축 형식으로 자주 채택됩니다.

Zstandard

Zstandard(줄여서 zstd, RFC 8788)는 Meta(구 Facebook)에서 공개한 현대적인 비손실 압축 알고리듬입니다. LZ4와 같은 저자(Yann Collet)가 Mercurial의 내부 데이터 압축을 위해 개발했습니다.

허프만 코딩과 FSE(Finite-State Entropy)라는 기법을 결합해서 사용하여 Deflate, Brotli와 마찬가지로 균형잡힌 압축/속도 비율을 추구하면서도, 더 빠른 속도와 더 높은 압축률을 제공합니다.

웹 환경에서 널리 쓰이는 Brotli보다도 나은 압축률을 보여주면서 단일 스레드에서의 인코딩/디코딩 속도가 더 빠릅니다. (창 크기에 따라 달라질 수 있지만 Brotli는 일반적으로 고정된 값을 씁니다)

그 밖에도 다양한 기능들을 제공하고 있습니다.

훨씬 더 세분화된 1–22 사이의 압축 수준을 제공합니다. (기본값: 3)
학습된 사전(Pre-trained Dictionary) 기능을 제공합니다. 실제 프로덕션 데이터를 학습시켜서 환경에 최적화된 정적 사전을 사용할 수 있습니다.
자체적으로 멀티스레드 인터페이스를 제공합니다. 사용자 측에서 코드를 작성하지 않고도 리소스를 투자해 더 나은 성능을 얻을 수 있습니다.

Zstandard는 특별한 목적에서 사용되는 LZ4와 다르게 일반적인 시나리오에서 zlib과 Brotli를 압도하기 때문에 굉장히 주목받고 있습니다.

웹 생태계에서도 이를 지원하기 위한 움직임이 있으며 Chrome 버전 123부터 공식적으로 지원됩니다. 기본적으로 Brotli 보다 선호되기 때문에 앞으로 다양한 웹 서버나 CDN도 발맞추어 지원을 추가하게 될 것으로 보입니다.

HTTP와 압축

데이터 압축은 다양한 시스템에서 보편적으로 다뤄집니다. 가장 널리 쓰이는 전송 프로토콜인 HTTP는 컨텐츠 압축을 기본 기능으로 탑재하고 있습니다.

HTTP 컨텐츠 협상과 압축

HTTP는 웹을 포함한 다양한 에이전트를 지원하기 위해 "컨텐츠 협상(Content Negotiation)"이라는 메커니즘을 제공하며, 본문 압축도 이런 메커니즘을 기반으로 동작합니다.

먼저 클라이언트가 선호하는 압축 형식을 요청 헤더에 Accept-Encoding 필드로 명시하면, 그 중 서버가 지원하는 형식을 결정해서 사용하고 응답 헤더에 Content-Encoding 필드로 명시합니다.

컨텐츠가 이미 오리진에서 압축되어 Content-Encoding 헤더를 명시하고 있는 경우 CDN 같은 중간 노드에서는 추가적인 압축을 진행하지 않습니다 (물론 벤더에 따라 트랜스코딩을 기능으로 지원할 수도 있습니다)

End-to-End vs Hop-by-Hop 압축

오늘날의 웹은 단일 서버에 바로 연결하기 보다 수많은 중간 서버(리버스 프록시, CDN 등)를 경유합니다.

컨텐츠 협상에 사용되는 Accpet-*, Content-* 헤더들은 일반적으로 네트워크의 말단에 해당하는 사용자 에이전트와 오리진 서버에서 결정되기 때문에 End-to-End 헤더라고 부릅니다. Content-Encoding 헤더도 이런 E2E 헤더 중 하나입니다.

간혹 홉 사이에서만 컨텐츠를 압축해서 전송하는 경우가 있는데 이 때 사용하는 전용 헤더가 TE(Accept-Transfer-Encoding)와 Transfer-Encoding와 같은 Hop-by-Hop 헤더입니다. 사용하는 방식은 Accept-Encoding, Content-Encoding 쌍과 동일하지만 다른 맥락과 무관하게 홉 사이에서 필요한 부분만을 추가 명시하는 목적입니다.

오늘날 거의 사용되지 않지만, 혹시나 사용을 검토하더라도 여러 주의가 필요합니다.

컨텐츠가 이미 압축되어 있는 경우(Content-Encoding 헤더 있음) 전송 구간에서 추가적으로 압축을 진행하는 것을 피해야합니다.
HTTP/2와 HTTP/3는 자체적인 데이터 스트리밍 메커니즘을 가지고 있어 Transfer-Encoding 헤더와 호환되지 않습니다. 함께 사용하는 경우 명시적인 프로토콜 에러가 발생하기 때문에 프록시에서 이를 다루는 경우 유의해야 합니다.

중간에 프로그램이 응답을 변경하는 경우도 있습니다. 응답을 읽지 않으면 문제가 없지만 응답을 읽는 경우 반드시 압축을 먼저 해제하고 처리 후 다시 압축해야 합니다. 경로에서 재압축이 반복적으로 수행되는 것은 비효율적이므로 네트워크 비용에 문제가 없다면 압축 적용을 앞쪽으로 미루는 것도 검토해볼 수 있습니다.

불가피하게 재압축을 하더라도 스트리밍 처리가 된다면 응답시간에 큰 영향이 없을 수 있습니다. 하지만 컨텐츠를 버퍼링 해야하는 경우 압축 해제를 대기해야하므로 지연시간이 더 커질 수 있습니다.

`Content-Type` 헤더와 CDN 압축

모든 형식에 압축이 유효한 것이 아니기 때문에 압축을 결정하기 전 형식 정보가 반드시 필요합니다.

하지만 컨텐츠를 제공하는 원본(Origin)이 아닌 측에서는 원본은 형식을 유추(inspect)할 수 있는 방법이 제한됩니다. 그러므로 원본이 아닌 위치에서 압축을 적용하려는 경우, 원본은 컨텐츠의 MIME 정보를 Content-Type 헤더로 제공해야 합니다.

정확한 Content-Type이 없을 때 사용할 수 있는 대안들이 있지만 부정확하거나 비효율적일 수 밖에 없다는 점을 인지하고 있어야 합니다.

경로에 파일명이 포함된 경우 파일 확장자로부터 유추한다.
미리 정의된 경로별 배포 정책을 바탕으로 유추한다.
본문 데이터(헤더, 매직넘버 등)를 읽어 유추한다.

파일 확장자나 Content-Type이 있더라도 그다지 널리 쓰이지 않거나 새로운 형식인 경우 프로그램의 맥락이 부족할 수도 있습니다. 연관 시스템을 운영할 때 MIME 목록을 직접 관리하여 프로그램 맥락에 전달하는 것이 좋습니다.

그 예시로, AWS CLI는 Python의 mimetypes 패키지를 사용해 MIME을 유추하는데, 이 패키지는 몇 가지 하드코딩된 목록을 제외한 정보는 모두 실행환경의 /etc/mime.types 파일에서 불러옵니다.

https://github.com/python/cpython/blob/3.12/Lib/mimetypes.py#L396-L595

시스템에서 AWS S3 호스팅 기능을 사용하고 AWS CLI로 파일을 업로드 하는 경우, 이 /etc/mime.types 파일을 제공하지 않으면 응답의 Content-Type 헤더가 폴백인 application/octet-stream으로 결정되어 다른 클라이언트에서 의도치 않은 동작을 유발할 수 있으므로 주의해야 합니다.

/etc/mime.types 파일 예시:

# 미디어 파일 타입
image/webp    webp
image/avif    avif
vedio/webm    webm

# 웹 폰트 파일 타입
application/x-font-truetype    ttf           # (IANA: March 2013)
application/x-font-opentype    otf           # (IANA: March 2013)
application/font-woff2         woff2         # (W3C W./E.Draft: May 2014/March 2016)
application/font-woff          woff          # (IANA: January 2013)

# 웹 앱 매니페스트 확장
application/manifest+json      webmanifest   # (W3C W./E.Draft: May 2015)

# 웹어셈블리 파일
application/wasm               wasm

원본에 정확한 Content-Type 헤더가 있으면 AWS CloudFront, Cloudflare 같은 CDN 서비스가 이를 바탕으로 본문의 압축 적용 여부를 결정합니다. (이미 Content-Encoding 헤더가 있거나 본문 크기가 매우 작은 경우 생략합니다)

만약 특정 응답에 압축이 적용되지 않는다면, 경로 규칙을 수정하여 강제로 압축을 적용할 수 있습니다.

HTTP 헤더 압축

앞에 설명한 압축은 HTTP 본문(Body)을 통해 주고받는 컨텐츠에 적용됩니다. 그런데 HTTP에서는 본문 말고도 꽤 많은 메타데이터를 HTTP 헤더를 통해 주고 받습니다.

HTTP는 여러 차례 여러차례 프로토콜이 개선되었습니다. HTTP/1.1, HTTP/2(RFC 9113), HTTP/3(RFC 9114) 3가지는 모두 HTTP 의미론과 호환되지만 세부적인 구현에는 큰 차이가 있습니다. HTTP/2와 HTTP/3가 기존 HTTP/1.1 대비 개선된 점 한가지가 바로 전송 시 HTTP 헤더의 압축 여부입니다.

HTTP/2는 HPACK(RFC 7541)이라는 필드 압축 기술을 이용헤서 HTTP 헤더를 압축합니다. HPACK은 Deflate 알고리듬을 그대로 사용하던 SPDY의 잠재적인 보안 위협(뒷부분에서 추가로 설명)을 완화하기 위해 특별히 설계되었으며, HTTP 헤더를 위한 정적 사전을 가지고 있어 헤더 내용을 보다 효율적으로 압축할 수 있습니다.

HTTP/3는 QPACK(RFC 9204)이라는 필드 압축 기술을 사용합니다. HPACK 구현 상 발생할 수 있는 HOL(Head-of-Line blocking) 문제를 완화하기위해 개선된 버전입니다.

와이어 형식과 압축

시스템은 전송 계층에서 데이터를 주고 받기 전에 사용할 수 있는 형식(Wire Format)으로 데이터를 직렬화(Serialization)해야 합니다.

이 때 사용하는 형식들이 데이터를 어떻게 표현하는지, 또는 어떻게 사용되는지에 따라 앞서 소개한 범용 압축 알고리듬들의 적용 가능성과 효율이 달라집니다.

일반적으로 텍스트 기반 형식이 바이너리 기반에 비해 압축이 잘 된다는 인상이 있으나 반드시 그렇지는 않습니다. 실제로는 데이터가 어떤식으로 패킹되어 있는지, 컨텐츠 자체의 엔트로피가 어떤지의 영향을 크게 받습니다.

바이너리 형식이더라도 특별히 패킹되지 않은 raw 바이트열 이라면 같은 내용의 텍스트와 동일한 수준의 압축이 가능하고, 반대로 텍스트 형식이더라도 의미 없는 해시값이나 전체 바이트열을 다시 패킹하는 Base64 문자열 등에 대해서는 대부분의 압축 알고리듬이 잘 동작하지 않습니다.

추가로 컨텐츠 자체와 형식 부분의 압축 적용 비중을 별도로 따져보는 것이 좋습니다. 몇 가지 대표적인 전송 형식을 예로 들어보겠습니다.

XML / JSON

일반적으로 텍스트 기반 직렬화 형식은 압축 효율이 높은 편입니다. 구조를 표현하기 위해 반복적인 텍스트 패턴을 사용하고, 전체에서 이런 부분의 비중이 높은 편이기 때문입니다.

특히 열린 태그와 닫힌 태그가 반복적으로 나타나는 XML은 압축을 적용했을 때 그 효과가 큰 편입니다. XML을 형식을 따르는 HTML, SVG 같은 형식 또한 마찬가지 입니다.

JSON의 구조는 XML보다는 컴팩트하게 표현되기 때문에 다소 효율이 떨어집니다. 하지만 데이터에 포함되는 일반 텍스트들은 여전히 압축의 영향을 크게 받습니다.

간단한 테스트를 위해 JSON Generator를 통해 데이터를 생성하고, Gzip과 Snappy 압축을 적용한 후 크기를 비교해보겠습니다.

Format	Size	Comp Ratio
JSON (원본)	5.27 kB	1.00
JSON + Gzip	2.17 kB	0.40
JSON + Snappy	3.66 kB	0.70

MessagePack / CBOR

MessagePack과 CBOR는 JSON 구조와 (거의) 호환되는 대표적인 바이너리 직렬화 형식입니다. 둘 다 각 데이터 값에 자료형과 길이를 인코딩한 헤더 바이트를 함께 배치하여 추가 스키마 없이 데이터를 표현합니다.

컨텐츠 자체는 거의 변형하지 않으므로 압축률은 큰 차이가 없겠으나, 헤더 정보는 형식 자체에서 이미 압축이 고려하고 있는만큼 추가적인 압축을 적용했을 때 압축률이 떨어집니다. 특히 가변 길이 자료형을 적용하는 경우 더욱 효율이 떨어질 수 있습니다.

앞서 생성한 데이터의 코덱을 CBOR로 변경한 후 비교해보겠습니다.

Format	Size	Comp Ratio
CBOR (원본)	4.71 kB	1.00
CBOR + Gzip	2.16 kB	0.46
CBOR + Snappy	3.06 kB	0.65

Protocol Buffers / Flatbuffers / Cap'n Proto

Protocol Buffers(이하 Protobuf)의 경우 MessagePack과 다르게 자료형이나 길이 정보를 같이 인코딩하지도 않고, 값 자체에도 다양한 패킹 메커니즘(Variable Integers, Zig-Zag Encoding 등)을 사용하기 때문에 추가 압축의 효율이 더욱 떨어지게 됩니다.

마찬가지로 생성했던 데이터를 Protobuf로 재인코딩 후 비교해보겠습니다.

Format	Size	Comp Ratio
Protobuf (원본)	3.89 kB	1.00
Protobuf + Gzip	2.06 kB	0.53
Protobuf + Snappy	2.89 kB	0.74

이런식으로 직렬화 형식 자체가 압축을 수행하는 경우, 추가적인 압축의 효율성이 감소하는 것을 볼 수 있습니다.

이런 형식에서는 큰 비용을 들여도 압축률이 크게 개선되지 않기 때문에 Gzip, Brotli 보다 Snappy, LZ4와 같은 고속 압축 알고리듬의 채택이 더 합리적일 수 있습니다.

압축을 적용하기 전에

시스템 특성 고려하기

네트워크와 디스크 사용량이 시스템의 전체 성능에 병목이 될 수 있는 시스템에서는 다소 처리량을 희생해서라도 압축 비율을 높이는게 나은 선택이 될 수 있습니다. 웹 서버가 LZ4 같은 고속 압축보다 Gzip/Brotli 를 선호하는 것이 대표적인 예시이며, 대부분의 경우 밸런스가 가장 뛰어난 Zstandard가 최선의 선택이 됩니다.

한편 IoT 네트워크 환경처럼 저전력 기기끼리 자체적으로 통신하는 경우를 가정하면 상황이 달라집니다. 네트워크 대역폭은 남아도는데 장치 리소스가 부족합니다. 이럴 때는 기존 형식의 압축 수준을 낮추는 것 보다 오버헤드가 적은 LZ4 같은 것을 선택할 수도 있습니다.

RocksDB 같은 스토리지, Kafka와 같은 메시지 브로커도 시스템의 특성에 따라 적절한 압축 형식을 선택할 수 있도록 Gzip/Brotli/Zstandard 등 다양한 압축 형식을 옵션으로 지원합니다.

마이크로서비스를 구현하는 경우, RPC 통신 구간에서 압축을 적용하는 것은 일반적이지만 다소 주의가 필요합니다. RPC 프레임워크가 직접 압축을 지원하지 않는 경우가 많고 (e.g. Cap'n Proto, gRPC), 와이어 형식이 제공하는 특정 고급 최적화 사례와 호환되지 않을 가능성이 있기 때문입니다 (e.g. FlatBuffers mmap-ing)

바이너리 패킹을 사용하는 대부분의 와이어 형식은 이미 상당히 공간효율적이기 때문에 데이터 내부의 큰 텍스트 필드에만 선택적으로 압축을 적용하는 것이 나을 수도 있습니다. 다만 이 경우 사용자 코드에서 직접 인코딩/디코딩을 추가로 수행해야하기 때문에 코드의 복잡도가 증가하는 것이 단점입니다.

구현 품질 검토하기

같은 형식이라고 해서 그 품질이 모두 동등한 것은 아닙니다. 당연하게도 실제 구현체의 품질에 따라 성능이 좋다고 알려진 형식이 기대보다 못할 수도 있고, 반대로 느리다고 알려진 형식도 더 빠르게 사용할 수 있습니다. 심지어 내부 구현이 동일하더라도 (C 라이브러리를 링크하는 경우) 바인딩 방식 때문에 성능이 감소될 수 있습니다.

플랫폼이 탑재하고 있지 않은 형식을 지원해야 하는 경우, 라이브러리의 크기가 앱의 크기를 과도하게 키우거나 시작 시간을 지연시킬 수 있기 때문에 클라이언트에서 더 고려할 것이 많습니다. 경우에 따라 적절한 형식이더라도 더 나은 구현을 탐색하거나 새로운 구현을 만들어 사용하는 것도 함께 검토해야 합니다.

TypeScript Playground가 코드 공유와 로컬 스토리지 동기화를 위해 사용하는 lz-string 라이브러리가 그러한 예시 중 하나입니다.

저는 긴 텍스트 데이터가 아닌 작은 메타데이터 구조체를 문자열로 압축하기 위해 urlpack이라는 라이브러리를 만들어 사용하기도 했습니다.

압축 사전 제공하기

일반적인 압축 알고리듬은 자주 등장하는 단어가 많을 수록 효율이 올라갑니다. 페이로드가 작을 수록 반복되는 요소가 적어 압축 효율이 떨어지게 됩니다.

현대적인 압축 형식은 정적 사전을 미리 준비하여 개선할 수 있지만, 플랫폼에 탑재된 사전은 보편적인 형식에 대해서만 학습되어 있어 실제 제품의 컨텐츠나 API 데이터의 필드는 충분히 예측하기 쉬움에도 정적 사전의 혜택을 받지 못합니다.

Zstandard는 직접 입력한 데이터를 바탕으로 정적 사전을 생성하는 기능을 제공하고 있어, 실제 프로덕션 데이터를 학습시켜서 압축 효율을 크게 개선할 수 있습니다. LZ4도 Zstandard로 생성한 사전을 그대로 사용하는 기능을 제공합니다. 따라서 Zstandard나 LZ4를 사용하는 서버/클라이언트는 미리 학습한 "공유 사전"을 탑재하는 것을 고려해보면 좋습니다.

웹 플랫폼에 Zstandard 지원이 추가됨에 따라 공유 사전을 HTTP를 통해 교환할 수 있는 Compression Dictionary Transport 표준이 실험 단계에 있습니다.

보안 고려사항

모든 압축 기술은 본질적으로 중복 감소이기 때문에 정보 엔트로피 감소로 인한 정보 유출 위험이 있습니다.

CRIME(Compression Ratio Info-leak Made Easy)과 BREACH(Browser Reconnaissance and Exflitration via Adaptive Compression of Hypertext)로 알려진 부채널 공격이 이런 컨텐츠 압축의 특성을 응용합니다.

사용자 입력 데이터와 비밀키(보호 리소스)가 혼합된 데이터를 하나의 페이로드로 압축하는 것은 취약하다고 알려져 있기 때문에 유의하여 화면과 API를 설계해야합니다.

레퍼런스

아이덴티티 시스템의 7가지 원칙

Tue, 05 Jul 2022 00:00:00 GMT

"사용자"를 다루는 서비스 개발이나 조직 관리에서 Identity Managmenet는 절대 빼놓을 수 없는 핵심적인 주제입니다.

언제나 단순한 인증만 구현하고 넘어가면 편하겠지만 해당 시스템을 확장해야하는 순간이 오면 이 Identity Managment 하나가 이후 나머지의 성패를 좌지우지 한다고 해도 과언이 아닐 것 입니다. 올바른 Identity 플랫폼 없이는 올바른 Access Control 이 구현될 수 없으며, 올바른 Access Control 없이 Use Case를 확장하는데는 뚜렷한 한계가 있기 때문입니다.

저는 Identity를 2016 년에 SI 하면서 잠깐 공부할 기회가 있었는데, 솔직히 그 이후로 서비스 개발하면서 다시 볼 일이 없다고 까먹고 있다가 최근 들어서 똑같은 주제를 바닥부터 다시 공부하고 있습니다. 아무래도 아키텍처 볼 거면 한 번은 제대로 짚고 넘어가야하는 주제 중 하나가 아닐까 합니다.

Identity를 가장 탁월하게 다루는 기업을 하나 꼽자면 역시 Microsoft일 겁니다. AD/ADFS로 수많은 엔터프라이즈 기업의 인증 시스템을 제공하고 있고, 현재는 이를 Azure로 확장해서 클라우드 시대의 인증까지 성공적으로 제공하고 있습니다.

사실 이런 거대한 인증 시스템 이전에도 많은 시행착오가 있었다고 알려져 있습니다. 지금에야 PII(개인식별정보)를 다룰 때 지켜야할 원칙들이 법으로 제한되고 있고, 인증/인가를 위한 다양한 표준 기술이 등장했지만 이것들이 모두 이전의 시행착오를 바탕으로 만들어진 것입니다.

Microsoft Passport ID와 Access 아키텍처를 설계한 Kim Cameron이 이전의 성공과 실패를 바탕으로 정리한 "The Laws of Identity" 백서가 아주 유명하며 이후 만들어진 Shibboleth, CardSpace 같은 시스템들에 직접적인 영향을 미쳤습니다.

서비스 개발자들이나 시스템 설계에 참여하는 사람들도 한 번쯤 읽고 머릿속 어딘가에 새겨둬야 하는 명문입니다. 근데 국내에 공유나 번역이 딱히 없어서 요약된 버전을 올려둡니다. 요약은 레퍼런스에 첨부한 다른 논문에서 발췌하고 해석한 것 입니다. 더 정확한 사례와 설명이 포함되어 있는 원본 글을 정독하는걸 권장드립니다.

The Laws of Identity

사용자 제어 및 동의 (User Control and Consent): 사용자가 데이터 공유 권한을 부여하며 공유 방식에 대해 발언권을 갖습니다;

ID 시스템은 사용자의 동의를 얻은 신원 정보에 대해서만 공유해야 합니다. 여기서 기본 가설은 사용자가 명시적인 동의없이 자신의 신원 정보를 공유하는 시스템을 신뢰하지 않는다는 것 입니다. 사용자가 자신의 ID 속성을 공유하는 시스템이 해당 속성을 보호하고 사용방법에 대해 자신의 희망을 존중한다는 확신을 가질 필요가 있습니다.
제한된 사용을 위한 최소 공개 (Minimal Disclosure for a Constrained Use): 최소한의 식별 정보만 공유하고, 안전하게 저장되고, 신속하게 삭제합니다;

가장 제한된 사용을 위해 가장 최소한의 신원 정보만 공유하는 방식이 가장 안정적이고 장기적인 솔루션입니다. 여기서 기본 가설은 모든 시스템이 보관하는 기밀정보는 탈취와 도용에 취약하다는 것 입니다. 따라서 시스템은 캡처하고 저장하는 PII를 최소화해야하며 이용목적이 만료되자마자 즉시 삭제해야 합니다.
정당한 당사자 (Justifiable Parties): 필요를 증명할 수 있는 사람만이 액세스 권한을 얻을 수 있습니다;

ID 시스템은 신원 정보 공유가 신원 관계에서 필요하고 정당한 당사자에게만 제한되도록 설계해야합니다. 여기서 기본 가설은 사용자가 자신의 PII가 적절한 역할이 없는 제3자에게 제공되는 것에 대해 분개한다는 점 입니다. 예를 들면 사용자가 가족 블로그에 사진을 게시하기 위해 Microsoft 계정을 사용할 필요가 없을 것 입니다. 이는 Microsoft Passport가 "인터넷을 위한 ID 시스템"이라는 비전을 달성하지 못한 가장 직접적인 원인으로 파악됩니다.
유향 신원 (Directed Identity): 사용 목적만을 위한 개인 식별자를 제공해서 신원정보를 보호합니다;

기술적으로 ID는 항상 다른 ID 또는 ID 세트와 연관되는 "방향"을 가진다고 얘기할 수 있습니다. 범용 ID 시스템이 사이트에 신원정보를 제공할 때는 제한된 당사자만 접근 가능하도록 단기적인 "단방향" 식별자를 할당해야 합니다. 여기서 기본 가설은 모든 사용자가 자신의 식별자를 알고 싶어하지 않고 비공개로 유지하는 것을 선호하는 반면, 모든 서비스/웹사이트는 사용자를 식별하고 직접 연락하길 원한다는 것입니다. 이 때 여러 서비스 제공자들이 글로벌 프로필 구축을 위해 공모하는 것을 방지할 수 있습니다.
다원주의 (Pluralism of Operators and Technologies): 경쟁이 더 나은 성과를 낳기 때문에 많은 ID 공급자가 지원되어야 합니다;

범용 ID 시스템은 여러 ID 공급자가 운영하는 여러 ID 기술에 대해 채널화하고 상호운용을 활성화 해야합니다. 여기서 기본 가설은 경쟁은 항상 좋고, 사용자가 익명 ID 사이를 마음대로 전환할 수 있어야 한다는 것 입니다. 이를 위해 지원되는 자격 증명 기술 유형의 무한한 다양성을 지원하면서 신원 정보 전송을 위해 공통 프로토콜을 사용하는 포괄적인 메타-아이덴티티 시스템이 필요합니다. 인증을 위한 단일 중앙 집중식 모놀리식 시스템(메타시스템의 반대)이 결코 존재하지 않는 이유는 한 상황에서 시스템을 이상적으로 만드는 특성이 다른 상황에서 해당 시스템을 부적격하게 만들기 때문입니다.
인간 통합 (Human Integration): 실제 사람이 참여해서 컴퓨터 간 해킹의 위험을 줄입니다;

범용 ID 시스템은 인간 사용자를 보호된 ID 메커니즘으로 통합된 분산 시스템의 일부로 정의해야 합니다. 여기서 기본 가설은 신원 도용 사례의 대다수가 개인 간의 연결보다 PC와 인간 간의 연결 취약성을 공격해서 발생하므로 이 연결이 특별히 보호되어야 한다는 점이며, 두 번째 가설은 그 연결에서 사용자가 이미 친숙한 일관된 의식이 필요하다는 점입니다. 이를 통해 사용자는 인증 과정에서 이상이 발생했을 때 바로 인지할 수 있습니다.
컨텍스트 전반에 걸친 일관성 (Consistent Experience Across Contexts): 사용자는 플랫폼 간에 간단하고 일관된 경험을 갖습니다;

통합 ID 메타시스템은 사용자에게 단순하고 일관된 경험을 제공하는 동시에 여러 운영자와 기술을 통해 컨텍스트를 분리할 수 있어야 합니다. 서비스 제공자가 선택한 신원 증명 기술이나 사용자가 선택한 프로필과 관계 없이 일관된 경험을 가져야 합니다. 사용자는 자신이 선택한 여러 ID 유형 사이에서 자유롭게 전환할 수 있어야 하고 어떤 트랜잭션에서 어떤 ID를 사용하고 있는지 쉽게 식별할 수 있도록 디지털 ID를 이해하기 쉬운 기호로 “사물화(Thingify)”해야 합니다.

위 7가지 법칙들은 만유인력의 법칙처럼 모든 현상에 적용되는 물리법칙 같은 것은 아니지만, ID 관리 시스템이 지원하기 위해 노력해야하며, 지키지 않는 것을 "위험을 무릅쓰고" 선택해야 하는 것들입니다. 사용자가 이 7가지 법칙을 준수하지 않는 모든 ID 시스템을 거부할 가능성이 있습니다.

레퍼런스

오픈소스 프로젝트에서 배운 코드리뷰

Sun, 12 Jun 2022 00:00:00 GMT

최근 이런저런 커뮤니티서 코드리뷰에 대한 얘기가 부쩍 많아지는걸 느낍니다.

이상적인 코드리뷰가 무엇인가에 대해 누구나 저마다의 경험과 의견을 가지고 있을 것입니다. 이에 대해 이런저런 이야기가 나오는 걸 보니 일반적으로 동료와 협업할 때 또는 새로운 회사에 합류했을 때 어떤걸 기대하는지 엿볼 수 있어서 도움이 됩니다만, 아무래도 내용들을 100% 동의하기 어려운게 제가 또 마이너로 빠지고 있나 싶습니다.

저는 코드리뷰 과정을 전부 오픈소스 컨트리뷰션으로 배웠습니다. 일반적으로 회사 업무에 적용할만한 지침은 아닐지 모르지만 나름 경험으로부터 빚은 의견이 있긴 합니다. 일반론으로 내세우긴 좀 그렇지만 오픈소스 프로젝트 코드리뷰에 참여할 때 알아두면 좋을만한 마음가짐으로써 소개해보려고 합니다.

코드리뷰를 마주하는 자세

병합을 전제로 하는 코드리뷰는 프로젝트 메인테이닝 세션 즉, 코드 작성자가 메인테이너로서 참여하는 의식입니다

당신이 원래 커미터인지 아닌지는 상관없습니다. 리뷰 당사자라면 변경사항이 크던 작던, 기능 변경이던, 문서 추가던 아니면 단순 맞춤법 수정이던 간에 적어도 PR이 열려있는 동안은 메인테이너로서 행동해야 합니다.

예를 들어봅시다. 제가 PR을 하나 제출했습니다. 어지간한 git 워크플로우에서는 PR 하나를 기다려주느라 프로젝트 진행이 중단되지 않습니다. 동시에 다른 일이 일어납니다. 사람들과 함께 PR을 리뷰하는 동안, 업스트림에는 48개의 변경사항들이 추가로 커밋되었습니다. 이제 저든 리뷰어든 PR의 변경사항을 그 48개의 커밋으로 리베이스 할 수 있어야 합니다. 즉, 직접 변경한 부분이 아니더라도 동시에 변경된, 변경될 수 있는 의존성 맥락을 모두 쫒아야 함을 의미합니다.

그래서 프로젝트 자체나 변경의 맥락을 얼마나 알고있냐가 상당히 중요해집니다.

저는 사실 이미 구현전략이 결정되어 있고 협업자가 어떤 코드를 작성할지 100% 정확하게 예상할 수 있을 때는 코드리뷰의 필요성을 느끼지 못합니다. 솔직히 말해서 저는 어떤 모양일지 예측만 가능하다면 컨벤션도 별로 따지지 않습니다.

반대로 그렇지 않은 상황에서, 사전에 논의가 없던 요청이라면 대체로 리젝하거나 재작성 수순으로 향합니다. PR은 요청되면 반드시 병합되어야 하는 게 아니거든요. 리뷰 요청을 받는 순간 리뷰어에게도 책임이 넘어오기 때문에 맥락없이 코드만 보고 LGTM를 찍는건 쉽지 않습니다.

메인테이너로서, 그게 좋은 코드인지 아닌지는 별 관계가 없습니다. 모든 코드는 메인테이닝 부채거든요.

좋은 PR, 나쁜 PR

좋은 PR이냐 나쁜 PR이냐에 대해서, 프로젝트마다 나름의 가이드가 있을 수 있지만, 일반론일 뿐 절대적이지 않습니다. 결국 요청의 행방은 코드리뷰에서 합의를 통해 결정되기 때문입니다.

테스트 코드가 있으면 좋은 요청인가요? 코드도 멀쩡해보이고 테스트도 잘 통과하더라도 "올바르게 작성되었는지" 확인하는건 여전히 코드리뷰의 역할입니다. 이 PR은 e2e 테스트 시나리오를 추가하는, 일반적으로는 매우 좋은 내용입니다. 하지만 스펙에 명시된 시나리오와 비교해가며 코드를 검토하니 어설션 하나가 누락된 것을 발견할 수 있었습니다.

변경이 거대하면 나쁜 요청인가요? 어떤 변경은 필연적으로 커집니다. 이런걸 합당한 요청으로 만드는 것 또한 코드리뷰의 역할입니다. 이 PR은 기능 변경이 없는 리팩토링이지만 볼륨이 너무 거대했습니다. 하지만 내용이 맘에 들었습니다. 이걸 병합한다면 엄청 복잡했던 제어 코드가 선언적인 구조로 바뀌어서 앞으로의 메인테이닝 코스트를 크게 줄일 수 있었습니다. 그래서 이 변경이 너무 크다고 리젝하는 대신 PM, 개발자, 테스트 엔지니어를 포함한 13명의 리뷰어가 장장 3개월간 달라붙어 변경을 리뷰하고 피드백과 테스트 결과를 남겼습니다. 저는 피드백을 반영하면서 커밋 100여개를 수십번씩 업스트림에 리베이스 했습니다.

좋은 PR을 만드는 건 결국 좋은 리뷰입니다. 요청한 사람이던 받는 사람이던 리뷰하고 또 리뷰해야합니다.

그리고 충돌을 피하지 말고 리베이스와 테스트에 열과 성을 다하세요.

성장에는 책임이 따른다

코드리뷰를 통해 뭔가 배워서 성장하고, 코드 퀄리티가 올라가고, 팀웍이 좋아지고 할 수 있으나 모두 부가효과입니다.

프로젝트의 거버넌스 모델에 따라 느낌이 다 다르긴 하지만 본질적으로 병합을 전제로 하는 모든 코드리뷰는 메인테이너로서 참여하는 의식입니다.

코드 작성자와 리뷰어의 역할을 나누지 마세요. 코드 작성자는 당연히 1차적으로 리뷰어이며, 리뷰어는 반드시 작성된 코드에 대해 모두 이해해야 합니다. 코드리뷰 당사자는 모두 해당 코드 메인테이너라는 관점에서 역할이 같습니다.

프로젝트 기여과정에서 코드리뷰 참여는 성장에 도움이 됩니다만, 성장을 위한 도구가 아닙니다. 메인테이너 관점에서 생각하세요. 일방적으로 당신의 코드를 떠넘기지 마세요. 코드에 대한 책임을 지세요. (오래 지속되는 프로젝트에 참여한적이 있다면, 코드를 더하는게 능사가 아닌 건 알고 있을 겁니다)

결과적으로 성장하고자 한다면, 기여도를 높여야 할 것입니다. 그리고 큰 기여일수록 큰 책임이 따릅니다.

크던 작던 결과적으로 메인테이너와 관점이 일치하게되는 순간, PR은 쉽게 병합됩니다.

"나랑 계약해서 오픈소스 컨트리뷰터가 되지 않을래?"

"컨트리뷰터들은 결국 모두 메인테이너가 되는거야? 어째서 미리 얘기해주지 않은거야"

"어째서냐니, 물어보지 않았잖아?"
— Hyeseong Kim (@KrComet) March 11, 2022

어쩌면 당신이 다음 메인테이너가 될지도 몰라요 :)

커리어의 첫 장을 넘기며

Wed, 29 Dec 2021 00:00:00 GMT

매년을 돌아보기엔 버거웠는지 2021년을 지나보내면서야 두 번째 회고를 쓰게됐습니다. 2017년 보내고 썼었으니 거의 4년 만... 이네요.

너무 오랫만에 글을 쓰다보니 갈무리가 잘 안되네요. 글을 나눠서 이쪽엔 순수하게 제 "커리어"에 대한 회고만 남겨놓으려 합니다. 제 경력 초반을 통째로 돌아보니 조금 적나라한 업무 얘기나 감상이 있어서 전시하기 좋은 내용은 아닌 것 같지만... 제 사이트니 그냥 맘편하게 올려두렵니다. (문체도 바꿨습니다)

2015년 고등학교 3학년에 산학협력으로 처음 일을 시작해서 당근마켓에서 웹 프론트엔드 개발자로 일하고 있는 지금까지 경력 중 이야기 그리고 앞으로에 대한 이야기입니다. 오픈소스 프로젝트나 여타 이야기들도 저한테 꽤나 중요해서 따로 모아서 올릴 예정입니다.

나의 첫 이력을 돌아보며

주변 사람들과 어쩌다 커리어 얘기를 하다보면 내가 생각보다 개발자로서 경력이 짧다는데서 놀라는 분들이 종종 있다. 내가 처음 일 했던 솔루션 엔지니어(SE)를 쉽게 "세일즈"라고 대충 소개하니 더더욱 그렇다.

실제로 나는 솔루션 엔지니어로 2년 10개월 가까이 근무했고, 그 후에 바로 개발자로 일을 시작한게 2018년 중순이니 이제서야 개발자로서의 경력이 역전한 셈이다. (주변에 개발자가 SE가 되는 경우는 있어도 그 반대는 그리 흔치 않은 것 같기도하다. 내가 볼 땐 이쪽이 생존자 편향이 상당히 강하게 나타나는 분야같다)

솔루션 엔지니어는 무슨 일을 하는지 먼저 설명을 써본다.

내가 다녔던 곳은 자체 솔루션을 다루지 않았고, 회사 규모가 작았기 때문에 주로 수요층이 확실한 솔루션을 가지고 있으나 국내에 지사나 파트너를 두고 있지 않은 해외 솔루션 업체와 독점 영업 계약을 맺어 중간에서 리셀링 수수료를 얻거나 기술지원 서비스를 제공하는 식으로 돈을 벌었다.

그럼 이 솔루션을 영업을 해야하지 않겠는가, B2B 솔루션 영업은 다른 상품판매와 좀 달라서 고객의 요구사항에 맞는 솔루션인지 복잡한 평가과정을 통해 굉장히 보수적으로 계약을 진행한다 (시스템도 시스템이고 가격도 가격인지라...) 이 계약을 위해 기본적인 사용자 교육을 제공하고, 기존 시스템(소위 "기간계")에 통합(System Integration, 즉 "SI"이다)을 위해 제품을 커스터마이징하거나 PoC를 환경을 구성하는 등 엔지니어링 과정이 필요한데 이런 과정을 Pre-sales engineering (또는 Technical sales, 기술영업)이라고 한다.

회사마다 많이 다르기 때문에 다른 분의 글도 함께 링크한다: 제품을 파는 엔지니어가 되어보니

솔직히 말하자면 그 당시는, 고등학교 졸업하기도 전에 시작한 일이라 업무에 대한 이해도가 많이 떨어지는 상태에서 열정만 넘쳤고, 손대는 것마다 일 크게 벌리기 일쑤였다 이 일에 대한 그 당시 감상은 내가 2017년 말에 작성했던 회고에 잘 드러나있다.

그런데 내가 "문제 해결"을 계속할 수록 뭔가 어긋나는 느낌이 들었다.

... (중략) 회사의 비즈니스는 철저하게 "영업"이였고, 내가 고객의 문제를 고민하는 것은 회사 입장에선 아무 득도 안되는 재능기부로 보이는 듯 하다.

이 후 나는 내 커리어를 평가하기 위해 내 이전 업무들을 여러번 돌아보면서 이해도가 높아지게 되었는데, 지금보면 그 당시 나는 회사입장에선 정말 골칫거리였으리라.

뭐 사고를 친 건 아닌데, 내가 문제만 보면 앞뒤 안가리고 달려들어 에스컬레이션도 없이 직접 해결해버리니 자연스럽게 기술지원 티어가 올라가버리거나 나를 중심으로 이전에 없던 큰 리스크의 프로젝트들을 감당해야 했다. 막 2년차 되가는 뭣모르고 나대는 사원의 어떤 부분을 믿어준건지... 덕분에 나는 그 연차에 쉽게 접할 수 없을 커다란 사이트에서 주도적으로 프로젝트를 지원하고 필드도 들락날락하면서 꽤 큰 성장을 할 수 있었으니 결과적으로는 감사한 일이다. (명목상 내 인건비라고 추가로 비용산정이 들어갔을리는 없으니 회사도 참 손해보는 일이였겠다는 생각이 든다)

애초에 내 손에 다 담을 수 없는 문제들을 다루느라 정말 별 일을 다 해야했고, 꽤 많은 교훈을 얻을 수 있었다.

먼저, 내가 아무리 잘나도 세상의 모든 문제를 기술적으로 해결할 수는 없다. 특히 사이트가 크고 복잡할 수록 스스로 해결할 수 있는데 한계가 생겼고, 여러 사람이 얽히는 문제는 대부분 "정치적으로" 해결하거나 덮어두고 미루는 수 밖에 없었다.

두 번째, 애초에 나 하나가 눈 앞의 작은 문제를 고민하는 것을 넘어서 큰 그림에서 톱니바퀴처럼 맞물려야 해결되는 그런 문제가 있다는 것.

세 번째, 솔루션의 수명과 범위(lifecycle)는 그 자체의 복잡성보다 중요하다. 요즘에야 많은 소프트웨어 회사들이 DevOps를 얘기하지만, 애초에 공정의 효율화를 중시하는 대기업들이 SI와 SM 조직을 구분하게 된 데는 그만한 배경이 있다. 바텀업으로 기능 개발에만 집중하면 놓치기 쉽지만 사실 이게 훨씬 본질적인 부분이라는 것.

마지막으로 솔루션은 항상 문제(Problem) 근처에 있다는 것, 솔루션 영업은 그저 내가 이미 가진 방법론의 우월함을 내세워 포교하는 것이 아니라, 고객의 문제에 뛰어들어 그 상황(use case)을 이해하고 수용하는 것이다.

이 때 같은 자리에서 출발해서 똑같이 해매는게 아니라 내가 가져온 도구가 길찾기에 도움이 되더라고 시연하고 설득하기 위해서는 많은 준비가 필요하고, 요구사항과 잘 맞지 않는 것 같을 때는 솔직하게 물러서서 다른 대안을 제시할 수 있어야 한다. 훌륭한 SE는 고객을 마주보는게 아니라 나란히 서서 문제를 바라본다. 내가 파는게 현자의 돌은 아니기 때문에 당연히 모든 일에 대응하진 못한다. 사례가 준비한 시나리오나 계획된 방향성에 크게 벗어났음에도 욕심을 부려 무리한 커스터마이징을 약속하는 것은 후에 큰 문제를 일으키고 신뢰도 하락으로 이어진다. 모든 영업이 그러하듯 당장 한 번의 성과가 아니라 신용과 파트너십을 보고 전략적으로 행동하는 것이 장기적인 성공으로 이어진다.

이러한 생각들은 그 당시엔 구체적이지 않았지만 모든 상황이 지나간 후 회고를 통해 발굴한 소중한 인사이트들이고, 소프트웨어 개발자로 일하는 지금도 내가 문제를 바라보고 접근하는 방식에 큰 영향을 끼치고 있다.

그 당시엔 눈 앞의 문제에 당장 뛰어들어 가장 단순해보이는 방법으로 풀어내지 못하는걸 답답해했지만, 아이러니하게도 지금와선 문제를 큰 그림에서 바라보고 라이프사이클을 고려해서 전략적으로 접근하는 걸 잘하는게 나의 뚜렷한 강점이 되었다.

For every complex problem, there's a solution that is simple, neat, and wrong. 모든 복잡한 문제에는 단순하고 명확하고 잘못된 해답이 있다.

-- H.L. Mencken

개발자가 된 지금도 자주 되새기고 혹시 케이스 스터디가 부족하지 않았는지 문제를 넘겨짚지 않았는지 돌아보게 만들어주는 구절이다.

웹 개발자로 다시 경력 쌓기

개발자로서 커리어를 만드는걸 더 지체할 수 없다는 생각에 정말 급하게 이직해서 작은 헬스케어 스타트업에서 약 1년 서버 개발자로 일했다. 당연히 이전의 경험들은 경력으로 인정받지 못했고, 당장 기능개발에 기여해야하는 나에게 큰 그림이 어쩌고..도 당장 아무런 도움도 되지 않는 일이였다. 내 경력은 사실상 백지부터 다시 시작했고, 뒤쳐진 느낌이 들었다. (음 그 때 급여수준을 생각해보면 느낌만 그런건 아니였다)

그 때는 어차피 다시 시작한다는 마음가짐이라 회사가 인정해주는지 아닌지 별로 여의치 않고 기여할 수 있는 부분을 찾고는 했다. 메인 스택은 Ruby on Rails라서 프레임워크 공부를 잠깐 하기도 했으나 결국은 과제나 하청받는 프로젝트가 여럿 있어서 PHP던 Spring이던 다양한 레거시 코드베이스들을 얕게 봐야 했다. (이건 솔루션 커스터마이징 하느라 이미 도가 튼 일이라 크게 어려울 게 없었다) 1년이 채 안되는 짧은 근무 기간 동안 백엔드에서 기능을 주도적으로 개발할 프로젝트가 딱 한 번 있었는데, 듣도보도 못한 고객사 전용 프레임워크에 찍어내기에 특화된 그들의 방식을 따르느라 경력에는 별로 도움되지 않을게 분명했다.

그 것보단 내부 복제환경을 구축한다거나 CI/CD를 구성하고 거기에 인수테스트 까지 자동화해서 진행상황을 가시화하는식으로 작업환경을 개선하는 종류의 기여가 많았다. (가장 어려웠던 일은 커스텀된 이클립스 기반 IDE에 하드커플링 되어있는 고객사 프레임워크 구성을 디컴파일러로 뜯어내어 Gradle 프로젝트로 포팅하고 그걸 IntelliJ IDEA에서 디버깅 가능하게 만드는 일이였다. 당연히 아무도 시키지 않았다. 그래도 덕분에 환경 복제와 CI/CD가 가능해졌다)

리소스 문제로 일부 복잡하거나 단순한 기능 몇 부분을 웹뷰를 도입해 내가 화면과 서버 API와 배치 기능 개발까지 세트로 온전히 담당하게 되었는데 이 때 쯤부터 웹 프론트엔드에서 문제해결하는 이야기들을 트위터에 종종 올리곤 했다.

타이틀은 서버 개발자였으나 실제로 기억나는 챌린징한 업무는 거의 웹 프론트엔드 개발이였다. 기능 범위를 격리해서 혼자 개발했기 때문에 꽤 실험적인 접근이라도 마음대로 할 수 있었다. 사실 React를 쓴 것 자체도 회사에서 첫 사례였다. 그 와중에 나는 그 당시 React@experimental 채널에서 아직 베타였던 Hooks와 Suspense를 입맛대로 활용하고 있었고 빌드타임에 Pupeeteer를 사용해 Pre-rendering으로 상당한 수준의 최적화까지 시도했다 (결과는 꽤 좋았지만 이 것 때문에 생기는 웹뷰 버그 잡느라 진짜 개삽질했다)

이런 경험들 덕분인지 내 다음 포지션은 서버 개발자가 아니라 웹 프론트엔드 개발자가 되었고, 그게 지금까지 이어지고 있다.

~~트위터~~ 지인의 소개로 데브시스터즈라는 게임회사에 들어가 1년 8개월 가까이 웹 프론트엔드 개발자로 일했다. 고등학교에선 게임개발을 공부했지만, 빠른 취업을 위해 게임회사 취업을 포기하면서 영영 인연이 없을 거라고 생각했었는데 너무 시야가 좁았다는걸 깨달았다.

그렇게 웹개발을 제대로(?) 하기 시작했는데, 게임회사의 웹개발자라는게 나름 독특한 포지션이라는 걸 알게 됐다. 웹이라는게 회사의 주력 제품과 큰 연관이 없으면서도 접근성이 워낙 뛰어난 플랫폼이라서 온갖 웹 기반 사이드프로젝트가 발생했는데 이걸 모두 지원해야했다.

대외적으로는 회사나 게임의 브랜드 홈페이지부터 대내적으로는 온갖 인하우스 시스템들까지 웹 기반이라는 이유로 담당했으니 여기선 굳이 찾지 않아도 할 일이 넘쳐났다.

아까 내가 소프트웨어의 라이프사이클이 그 자체의 복잡성보다 훨씬 중요하다고 했던가, 겉으로는 단순해보이는 회사 홈페이지조차 그렇게 단순한 프로젝트가 아니라는걸 몸으로 부딪히면서 느끼게 되었다.

코딩을 바라보는 여러 관점이 있지만 메인터넌스 관점으로 바라본다면 코드를 더하는 행위는 순수하게 부채를 더하는 행위이다. 회사 홈페이지는 수명이 정말 길다는 것이 자명한 프로젝트 중 하나이기 때문에 최대한 단순하고 빠른 방식으로 접근했다가는 나중에 정말 꾸준하게 부채비용을 치루게 되는데, 문제는 내가 합류한 시점에서 이미 그런 부채들이 쌓여있었다.

다시 생각해보면 이 때가 솔루션 엔지니어로서 경험을 살려 문제를 정리하기 정말 좋은 상황이였지만 안타깝게도 그러지 못했다. 나는 이제서야 개발자로서 제대로 커리어를 시작한다는 고양감에 막 취해있었고, 한창 신작을 쏟고 있는 게임회사의 하드한 스케줄에 발 맞추느라 도저히 체질개선에 많은 리소스를 뺄 수 없었다는 것이 좋은 핑계거리였다.

그나마도 내 기술적인 역량을 앞세워 진행한 몇가지 도전이 굉장히 어정쩡한 결과를 내었고 또 다른 기술부채가 되어버렸다. 내 솔루션 엔지니어로 쌓은 경험과 정체성을 더 빨리 인정하고 강점으로써 활용했으면 좋았을 걸 하는 아쉬움이 남았다.

그래도 이후엔 그렇게 했다. 내가 잘 알고 내 문제를 잘 정의하는 도구가 있다면 적극적으로 팀에 소개하고 적응시켰다.

기능조직으로 많은 의존성과 불확실성에 휘둘려 Estimation이 부정확한게 팀의 고질적인 문제였는데, 마침 Jira 잘쓰려는 조직적인 움직임이 조금 있었다. 나는 Atlassian 솔루션 파트너 하면서 Jira 어드민한테 기능 교육해주는게 업무이던 사람이라 꽤나 적용방식과 효과에 빠삭했고, Estimation 추정치를 얻는 것을 목표로 내 팀에도 Jira 를 적극도입하려고 했다. 근데 이슈트래커 안쓰다가 쓰면 불편하기에 참여도가 떨어지는 것도 있었고, 정확한 추정치를 얻기 까지는 백데이터를 꽤 쌓아야해서 끝내 성과를 보지는 못해 아쉬웠다. (우여곡절 끝에 그럴싸한 번다운이 나오기 시작할 즈음에 내가 퇴사했다)

마케팅 프로젝트 참여하면서 주먹구구식으로 파일 주고 받으면서 진행하던 협업은 그 다음 프로젝트에서 Figma를 밀어서 온라인 협업으로 탈바꿈 시켰다. 이 것도 처음 도입할 때는 그저 일이 늘어나는한 경험적 장벽을 허물기 위해 시간 투자를 많이 했다. 개발하던 시간을 쪼개 프레임이나 프로토타입 정리에 적극적으로 나서고, 아예 이걸 개발자 주도로 하려고 프로토타입 기반 워크플로우를 만들어 프로젝트에 적용했다. 익숙하지 않은 사람들에게 도구의 장점 위주로 노출하는게 분명 도움이 되었다. 새 역할을 떠맡기는게 아니라 일단은 가급적 익숙한 내가 가져가는 것이 힘들지만 분명히 도움이 되었다. 데이터 연동으로 국제화 같이 원래 어려웠던 부분들 날먹하는 장면들을 몇 번 연출한 것이 거부감 줄이는데 도움이 많이 된 것 같다. 페이지 기반 기획과 컴포넌트 기반 개발방식이 잘 맞지 않는데서 오는 어려움이 컸는데 이건... 답이 없어서 해결을 미뤘다.

수 많은 웹사이트 유지보수하는 업무도 이후에 Gatsby 프레임워크의 기능과 현대적인 CMS 솔루션들의 연계로 돌파구가 보였다. 나는 전형적인 분산 컨텐츠 워크플로우에 노출되어있었고, 원래 사용하던 Gatsby는 이 문제영역에서 아주 독보적인 솔루션이였지만 당시에는 이해도가 부족했고, 특정 솔루션에 락인해서 문제를 풀고 싶지 않은 동료의 의견도 있었기에 도입을 피했었다. 이후엔 이 문제영역에 대한 이해도가 굉장히 높아져서 현재 회사에서 같은 문제영역을 다루는데 굉장히 큰 도움이 되고 있다.

아무튼 나는 기술을 큰 그림에서 보고 전략적으로 선택하는데는 능한 사람이였고, 내가 이미 활용하던 기술도 다시보는 계기들을 만들면서 성장하게 된 것 같다. 그게 React던 Gatsby던 GraphQL이던 Figma던 뭐던 원래 다소 얕게 알고 넘어가던 많은 것들이 이면의 전략과 현실의 워크플로우의 이해와 맞물리면서 더 명확해졌다. 이 때부터 트위터에서 내비치는 내 의견들은 다소 강하고 일관성있게 자리 잡았고 덕분에 팔로워가 지속적으로 늘기 시작했다.

대외적인 인지도가 조금 생겨서인지 FEConf 에서 한 세션 잡을 기회도 생겼다.

(최신 슬라이드)

발표에서 나의 문제 접근방식과 생각이 드러났던 것 같다. Statecharts라는 도구를 소개하는 건 명분이고 단순히 문제를 바텀업으로 해결하는 걸 벗어나 문제영역을 정의하고 그 (모델링) 과정에 사람들을 참여시키는 것을 발표의 핵심으로 다뤘는데 썩 잘 전달하진 못한 것 같다.

(발표연습 해야하는데 코로나 이후로 기회가 확 쪼그라들어버렸다)

새로운 도전을 찾다

데브시스터즈는 꽤 (특히 복지 측면에서) 좋은 회사였지만 내 커리어 정체성을 바로잡아주진 못했다. FEConf 발표 슬라이드에서도 나를 FE라고 명확히 소개하지 못했다 ("What's Next?" 라고 대놓고...)

이 시기에 GitHub과 Twitter에서 소셜 활동을 통해 영향력이 쌓이면서 동시에 극심한 가면증후군에 시달렸다. 주변에는 종종 "요즘 거품이 꼈다"라는 표현을 썼다. 내가 잘하는 건 실제로 채용시장이 바라는 것과 거리가 있었는데, 채용시장이 바라는 건 "웹 프론트엔드", "안드로이드", "iOS", "유니티 엔진", "Kubernetes" 등 특정 플랫폼에 능숙한 개발자였고 이 관점에서 나는 남들보다 느렸고, 그나마 내가 강점이라고 인식한 것은 전부 chore한 것들처럼 보였다. (실제로 회사들에게 이전 SE 경험을 경력으로 인정받지 못한 것도 컸다)

나름 규모가 큰 오픈소스 프로젝트(Mattermost)에서 코어 커미터로 인정받았다는 자부심은 있었지만, 기여 자체가 뜸해져서 거의 활동을 안하고 있었고, 그 외에는 남들 흔히하는 뭔가 제품스러운 사이드 프로젝트나 포트폴리오 하나 가지고 있지 않았다. 나름 커리어라고 생각했던게 모래성처럼 연약하게 느껴졌다.

지금부터라도 한 플랫폼 잡아서 스페셜리스트로 컨셉을 잡아야 하지 않나? 근데 웹을 계속하는게 맞나? 아직 안해본거(ex. iOS) 마저 해보는게 좋지 않을까? 그런 생각을 왕창했던거 같다. (이 때 고민상담 들어주신 많은 분들에게 정말 감사드립니다)

잠깐 멈춰서 주변을 돌아보니 나는 여전히 비슷한 관점으로 문제를 풀고 있었고, 잘하는거 하겠다고 주변을 계속 푸시하고 있었고, 그러면서 나 자신은 일적으로 전혀 성장하지 않은 거 같았다. (그나마 하드스킬의 성장은 대체로 새벽에 하고싶은 개발이나 오픈소스 기여를 하면서 이뤄졌다) 갑자기 주변에 미안하기도 하고, 아 큰일이네 너무 앞만보고 살았나 싶던 와중 문득 통장을 확인했다. 회사 복지가 좋아서 그런지 아니면 혼자 살면서 생활수준 낮게 유지해서 그런지 그래도 여유가 있다는 걸 확인하고는, 아무 계획 없이 퇴사하겠다고 말해버렸다.

지금은 다른게 아니라 자아성찰이 필요하구나, 필요하면 한 1년 쉬어버리자 이런 생각이였다. 사실 사회 나오고 병특문제도 있고 이직을 워낙 생각없이 덜컥덜컥 하다보니 제대로 쉬어본 적이 없었고, 그렇게 예정에 없던 내 삶의 첫번째 휴식기간을 가지게 되었다.

퇴사만 하면 일바빠서 못한 프로젝트들도 하고 운동도 하면서 최고로 생산적인 나날이 될 줄 알았다. 근데 거의 두 달 동안 잠자고 넷플릭스만 봤다. 내가 워낙 일 좋아하는 사람이라 조기은퇴니 뭐니 하는 얘기 나올 때 잘 공감을 못했는데 이제는 공감할 수 있다. 정말 좋다. 비생산적인 하루하루는 정말 최고였다.

그러면서 마침 코로나 완화로 지수가 요동치던 시기에 현금이 남아 주식투자를 겉핥기로 공부했다. 이 때 (전)자사주가 1년전에 샀으면 1500% 였다는 가정에 배아파하면서 "내부정보"를 어떻게 다뤄야 하는지... 에 대한 힌트를 조금 얻을 수 있었다. 힌트: 적나라한 내부의 상황과 외부의 정보는 잘 구분해 봐야한다... 지나친 비관론 때문에 기회를 놓치지 말자

가만히 누워서 공상하거나, 이런저런 유튜브 찾아보면서 내 커리어 고민은 계속되었다. 내가 거품이라고 불렀던 것이 의외로 좋은 기회들을 물고 왔고 나는 처음으로 회사를 골라서 가는 경험을 해볼 수 있었다. (기회가 어디까지가 내가 만든 거고 어디까지 데브시스터즈라는 회사가 만든 건지 알 수 없어서 혼란스러웠다)

웹 프론트엔드를 다룬다는 공통점은 있었지만, 3달의 자아성찰 기간동안 이건 나한테 큰 의미가 없다고 결론 내렸다. 그냥 채용시장 최적화일 뿐이다. 이걸 제외하니 다른 점이 보였다. 어떤 회사는 내가 이미 잘하는 걸 기여해주길 원했고, 어떤 회사는 나와 새로운 도전을 펼쳐보길 원했다.

최종적으로 오퍼에서도 보상 수준이 큰 폭으로 올랐고 이건 나한테 여러모로 의미가 컸다. 이전 회사들에서 내 실제 열의와 회사의 기대치가 굉장히 따로 논다고 느꼈고 실제로도 이게 보상에서 그대로 드러났기 때문이다. 다음 회사가 내 커리어에 큰 전환점이 될 것이 분명했고 고민이 깊어졌다. 내가 하고싶은 일이 뭔지 어느때보다 명확해야했고 후회없는 선택을 해야했다.

그 때 유튜브에서 본 TBWA라는 광고회사의 Manifesto가 나한테 가장 큰 영향을 미쳤다.

"Do the brave thing"

가슴뛰는 일, 혁신적인 일을 하라는 메시지가 머릿 속을 멤돌았다. 어느 회사의 제안이 나를 잠못들게 하고 있는지 곰곰히 생각해보니 자연스럽게 가장 높은 보상을 제안한 회사는 잊혀진 후 였다. 결국 그들이 내게 던진 미션만 생각하고 있었다.

결국 나는 어떻게 보면 당시 가장 바보같은(?) 선택을 해버리고 말았다. 안정적인, 잘하는 일, 커리어에 도움될 일들을 다 제치고 가장 알쏭달쏭하고 도전적으로 느껴지는 미션을 제시한 당근마켓에 함류하기로 결정했다.

다음 장의 아웃라인을 잡다

결과적으로 구체적으로 하는 일이 바뀌었나하면 당장은 그렇지 않은 것 같다. 9개월 째 당근마켓에서 일하면서 크게 스킬적인 성장을 했나 하면 솔직히 그것도 아닌 것 같다.

이전에 앞만보고 가다가 뚜렷한 성장을 하지 못한 것을 반성하며 조심스럽게, 하지만 또 기여거리가 보이면 그게 프론트던 백이던 시스템이던 잡일일던 가리지 않고 하고 있다. 그래도 그 와중에 내 팀의 문샷 비전을 벼르는데 시간을 조금씩 들여왔다. 거품이 꺼져버리는게 아닐까 노심초사했으나 다행히 그러지 않았다.

당근마켓의 구성원 신뢰는 다소 놀라운 수준이다. 전 직장들은 큰 그림에서 보고 움직임(Movement)을 보일때마다 주변사람들의 회의적인 시선을 상대해야 했고, 온전히 상대하기엔 내 신뢰 자산이 부족해서 결국 실행하지 못하는 경우가 참 많았는데 (그래도 불안한 예감은 잘 맞추는 편이라 나중에 가선 이걸 "예지력"이라고 했다) 여기는 뭔가 다르다. 신뢰하는데 거리낌이 없다고 해야할까, 그리고 목적조직으로 구성되어 있는 것도 잘 동작하고, 유능한 PM의 지원사격이 있으니 내가 문제에 집중 못하는게 오롯히 과제로 남아버렸다.

반 년을 넘게 들여서 ~~깨작깨작~~ 그림은 다 깔아놨고 실행만 남았으니 내년부터는 잡다한 기여로 에너지 분산하던걸 다시 집중하기 위해 노력해야 할 것 같다. 가짓수 줄이는 것 당장은 무리라서 일단 내 집중력 자체를 강화해보고자 한다.

3개월의 공백동안 한가하게 고민해보니 약점을 보완하는 것 보다는 상대적으로 강점을 살리는게 더 중요하다는 결론을 내리게되었다. 내 강점은 더 부정할 것 없이 솔루션 세일즈 경험과 다양한 시스템과의 통합 경험에서 온다. 사실 남들보다 오픈소스 프로젝트에 쉽게 진입한 것도 이런 배경이 컸던 거 같다. (오픈소스에 필요한 역량은 절반 엔지니어링, 절반 세일즈에 가깝다)

그리고 나는 예전부터 관심영역이 순수한 엔드유저보다는 커스터머의 관점에 가까웠다. 이전부터 서비스 자체보단 서비스를 구성하는 주변 환경을 개선하는데 더 많은 신경을 써왔다. 그렇다고 다시 SE 할 것 아니면 요즘은 DevRel(Developer Relations)같은 포지션이 떠오르는데, 이 것보단 약간 더 Engineering 비중이 높다. 마침 최근에 실리콘밸리 쪽엔 이쪽의 역량을 위주로 하는 새로운 포지션이 등장했는데 바로 DX(Developer Experience) Engineer이다. 팀 또는 고객의 개발 경험을 높이고 유지하는 책임을 가진 엔지니어로써, 외부 고객을 대상으로 할 때는 약간 DevRel 같은 성격도 가진다. 더 나아가 제품 개선을 가속하고 좋은 기준(프레임워크)을 제시하는 역할이 될 수도 있다.

(DX Engineer라는 역할에 대해 자세히 설명하는 아티클)

마침 내 팀의 비전도 이 DX라는 주제와 꽤 깊은 연관을 가지고 있다. 나는 앞으로의 커리어 여정을 이 DX Engineer의 길이라고 정의하고, 가급적 이 쪽 위주로 약점 개선과 강점 강화를 하려고 마음먹었다. 팀 외적인 기여도 연관있다면 손놓지 않고 계속 적극적으로 하게 될 것 같다.

이 여정에 필요하기 때문에 이때까지 쌓은 소셜 인지도를 개인 브랜드 수준으로 강화시키는데도 노력을 해 볼 생각이다. 중심 매체는 당연히 트위터와 깃헙인데 다른 하나를 함께 가져가려고 고민중이다. 최근엔 뉴스레터를 시작해서 한 4개 정도 발행해보았는데 컨셉 고민에 잠깐 중단한 상태이다.

보수적인 플랜도 있어야하기에 웹 프론트엔드 개발자 라는 타이틀도 계속 들고가려고 한다. 그래도 2년 넘게 해보니까, 내가 남들만큼 빠르진 못해도 "잘 하는"건 하는 분야인 듯 하다. 뭐랄까 크로스 플랫폼 인사이트나 시스템 간 통합에 대한 지식은 어딜가나 유용했지만 이쪽은 특히 써먹을 데가 많다. 물론 잘 쓰진 않았지만 UX던 코드 퀄리티던 오버해서 파봤던 경험이 꽤 유효하기도 하다.

시작하며

이렇게 써놓고 나서야 긴 방황을 마치고 출발선으로 돌아왔다는 생각이 듭니다. 방향성이 뚜렷하지 않으니 이 때까지 기술적으로 많이 성장하지 못했다고 느낀 것도 그냥 기분탓은 아니였겠지요. 이걸 인지하고 지난 2021년은 약간 느슨한 자아성찰의 해로 보냈는데 한해가 다 지나가기 전에 의미있는 결론을 내려서 정말 다행이라는 생각도 듭니다. 이걸 계기로 2022년부턴 다시 성장하는 내가 될 수 있지 않을까 기대를 품어봅니다.

혹시나 저와 비슷하게 "아, 커리어 꼬였네" 하는 고민이 있으신 분들에게 조심스럽게나마 이런 생각도 있구나 하고 참고가 되었으면 하는 바람입니다. 결국 서로 다른 그 모든 경험들이 모여 나를 지지해주는 강점이 될 수 있을겁니다.

워드프레스 닷컴 마이그레이션

Sun, 28 Mar 2021 00:00:00 GMT

최근 쉬는동안 지인 소개로 자체호스팅 중이던 Wordpress.org 인스턴스 하나를 Wordpress.com 으로 이전하는 일감을 받아서 진행했습니다.

디테일은 컨피덴셜이지만 기술적인 부분에서 발견한 소소한(?) 삽질거리들은 널리 공유하는 것이 세상에 이롭다는 생각이 들어 정리해서 공개합니다.

워드프레스 닷컴과 구텐베르크 에디터

워드프레스에 대한 인식은 구텐베르크 에디터 도입의 전과 후로 크게 나뉠 수 있을 것 같습니다.

워드프레스가 블럭에디터와 SPA 아키텍쳐를 통해 UX와 확장성을 크게 개선해 현대적인 CMS로 변모한지 상당히 오랜 시간이 흘렀으나 아직도 사람들의 인식에는 느리고 조악하고 마크업 폼 달려있던 그 워드프레스가 떠오르는 사람들이 많은 듯 합니다.

(그리고 여전히 워드프레스를 PHP 프로젝트인줄 아는 사람이 많은데 WordPress & gutenberg 소스코드 합치면 cloc 기준으로 JavaScript 코드가 2배 이상 많습니다)

그래서 워드프레스를 주제로 얘기할 때는 굉장히 주의를 기울여야 합니다. 상대방과 내가 인식하는 워드프레스가 같은 워드프레스인지 두 세 번 확인을 거쳐야 안심하고 얘기할 수 있습니다.

(어느 쪽 화면이 더 익숙하신가요?)

가령 저는 저렴한 가격의 워드프레스 닷컴에서 구텐베르크 에디터로 컨텐츠를 관리하고 WPGraphQL 플러그인과 GitHub Actions 을 통해 Jamstack 프론트엔드에 통합해서 쓰는 Headless CMS 유즈케이스를 얘기하고 있는 동안 상대방은 컨택트 폼 플러그인 깔고 HTML 퍼블리싱하고 PHP 테마 코드 커스터마이징하는 얘기 하고 있을 수도 있거든요.

이미 오랫동안 워드프레스 셀프호스팅을 유지하고 있는 사용자가 어떤 유형의 사용자인지 알려면 설치된 플러그인 목록을 보는게 빠를 것 같습니다.

설치된 플러그인이 그리 많지 않고 Jetpack 과 구텐베르크로 깔끔하게 관리되어 있다면, 좋습니다. 변화에 빠르게 적응하고 유연한 고객에게는 제안할 수 있는 솔루션들이 많아서 협업하는 과정이 즐거워질 수 있겠습니다.

워드프레스 닷컴으로 컨텐츠만 옮겨도 지저분한 관리영역들이 다 없어지니 좋을 것이고, API 기반으로 별도로 프론트엔드를 제공하고 뒤에서 Graceful 하게 움직일 수도 있겠지요.

반대로 이런 저런 폼 플러그인과 백업 플러그인이 잔뜩 깔려있다면, 젯팩이랑 구텐베르크가 뭔지도 모를 가능성이 높습니다. 이 경우는, 역으로 제안할 수 있는 건 별로 없고 반드시 비즈니스 플랜 이상을 쓰도록 설득하는 게 좋습니다.

비즈니스 플랜의 특권: SFTP와 phpMyAdmin

워드프레스닷컴의 Pricing 을 살펴봅니다. Premium ~ Business 플랜 사이에 큰 기능&가격 갭이 형성되어 있습니다.

전문적으로 관리하기 위해 필요한 대부분의 기능이 비즈니스 플랜부터 제공되기 때문에 괜히 돈 아까지 말고 비즈니스 플랜을 선택하는걸 권장드립니다.

특히 기존 사이트에서 마이그레이션 하는 경우 이 옵션이 가장 눈에 들어올 듯 싶습니다.

SFTP (SSH File Transfer Protocol) and Database Access

실제로 사이트에 비즈니스 플랜을 적용하면 "관리 -> 호스팅 옵션" 항목에서 SFTP 접속이 가능한 크레덴셜을 생성할 수 있고, phpMyAdmin 사이트가 제공됩니다.

원클릭 마이그레이션

"도구 -> Import -> Wordpress" 항목을 선택하면 기존에 셀프호스팅 중인 Wordpress.org 사이트의 전체 데이터를 손쉽게 Import 할 수 있습니다.

공식 가이드

"비즈니스 플랜이면 파일시스템이랑 DB까지 접근가능하니 그냥 통으로 밀어넣는게 빠른거 아닌가" 라고 생각할 수도 있는데 매니지드 서비스라 그런지 파일시스템 구조도 DB 구조도 조금씩 다르니까 함부로 날리거나 덮어 씌우다간 큰일납니다.

다행히 제가 Import 도구로 자동 마이그레이션 써보니 기대 이상으로 심리스하게 잘 돌아갔습니다.

라고 하고 싶으나 첫 시도에선 실패했습니다. Backing up -> Restoring (Importing) 두 스테이지로 진행되는데, Backing up 스테이지 진행도가 99%에서 멈춰서 더 이상 진행이 안되더군요. 프로세스 중에는 사이트 전기능이 비활성화 되므로 할 수 있는게 없었습니다.

막혔을 때 도움받으려고 비싼 플랜 쓰는 거니까 당황하지 않고 오른쪽 아래 구석탱이에 있는 Contact form 으로 메일 한통 쐈습니다. 시간대 때문인지 몇 시간 기다리니까 서포트 티켓 나오고 엔지니어가 바로 상태 복원 해주더라고요.

이 후에 한 번 더 진행하니 막히지 않고 성공했습니다.

속도는 그다지 빠르지 않습니다. 컨텐츠 양에 따라 다르겠으나 저는 2~3시간 쯤 걸렸습니다.

사이트 가져오기 중 주의사항

중간에 이상한 삽질이 하나 있긴 했습니다.

마이그레이션 옵션 중에 Everything vs Content-only 가 있는데 Everything이 활성화가 안되더라고요.

우연히 원인을 알게 되었는데 이전 UI에서 Import from... 에 입력한 주소에 www가 빠져서 그랬습니다. 워드프레스 사이트에 설정한 대표(Canonical) URL을 정확히 입력해줘야 활성화 되는 모양입니다.

마이그레이션 시 주의사항

플러그인 호환성

매니지드 서비스라서 호환 안되는 플러그인들이 꽤 있습니다. 자동백업류 플러그인들이 대표적인데 워드프레스닷컴은 자체적으로 백업 기능을 제공하므로 충돌하지 않게 기존 플러그인들을 미리 다 제거해줘야 합니다.

호환되지 않는 플러그인 카테고리와 알려진 목록은 공식 가이드에 잘 정리되어 있으니 확인하고 기존에 설치된 플러그인 목록과 비교해봐야 합니다.

만약 호환되지 않는 플러그인을 사용하고 있다면 마이그레이션 전에 모두 비활성화하고 어차피 옮기고 나면 못쓸 테니 삭제해버립시다.

커스텀 플러그인/테마 마이그레이션

가져오기 도구가 플러그인/테마를 마이그레이션 하는 방식이 단순히 데이터의 이동이 아니라 깔끔하게 "재설치"하는 식으로 동작합니다.

기존 사이트에 플러그인/테마를 부분적으로 커스터마이징 해서 쓰고 있다면 전부 마이그레이션 과정 중에 날아가니까 기존 코드를 따로 백업해두는 것이 좋습니다.

테마 커스터마이징이 필요한 경우 일반적으로 권장되는대로 Child Theme을 만드는 방식으로 관리하는게 좋습니다. Child Theme 코드는 보존되니 안심하고 옮겨도 됩니다.

커스텀 스타일시트 마이그레이션

CSS도 마찬가지로 "CSS 편집" 항목에서 따로 관리하는 커스텀 스타일시트는 잘 보존됩니다.

플러그인/테마를 임의로 수정해서 스타일시트를 사용하는 경우 날라갈 수 있으니 "CSS 편집" 쪽으로 미리 코드를 옮겨놓는게 좋습니다.

미디어 URL 마이그레이션

워드프레스의 가장 이해할 수 없는 부분 중 하나는, 사이트 대표 URL을 모든 임베드 미디어 주소에 포함시킨다는 점입니다.

예를들어 워드프레스 사이트 https://a.com 의 게시글에서 미디어를 업로드 하는 경우, 마크업 데이터에 [img src="https://a.com/wp-content/..."] 같은 식으로 들어갑니다.

문제는 저 대표 URL을 https://www.a.com 처럼 변경할 때 발생합니다. (기존에 인증서 없이 HTTP 프로토콜을 사용하다가 워드프레스닷컴으로 옮기면서 대표 URL이 HTTPS로 전환되는 경우도 마찬가지입니다.)

알아서 바꿔줄 것 같은데 바꿔주질 않아서 이미지가 다 깨집니다. 그럴거면 첨부터 Path 부분만 사용했으면 좋았을텐데 말이죠...

페이지 한 두개 짜리면 손으로 일일히 컨텐츠 내 URL들을 바꿔줄 수도 있지만 컨텐츠가 많으면 DB로 일괄 업데이트 하는 수 밖에 없습니다.

관리 -> 호스팅 설정 -> phpMyAdmin 에 접속해서 UPDATE 쿼리를 하나 때려줍니다.

# 변경 전 URL Origin RegExp
SET @old_origin='https?://a.com/';

UPDATE wp_posts
SET post_content = REGEXP_REPLACE(post_content, @old_origin, '/')
WHERE post_content REGEXP @old_origin;

이러면 모든 포스트에서 내부 링크가 사용된 부분 URL Origin 부분을 날려서 사용할 수 있도록 합니다.

새로 작성된 포스트에선 계속 URL Origin이 포함될테니 대표 URL을 변경할 때 마다 쿼리를 다시 실행해주는게 좋습니다.

SFTP

SFTP는 SSH 기반 프로토콜이니까 같은 호스트에 SSH로 접속할 수 있는거 아닌가 싶습니다만, 막상 SSH 접속이나 rsync 등을 사용하려고 시도하면 전부 막힙니다.

"SFTP 만" 사용할 수 있도록 제한되어 있어서 그렇습니다. 에러가 명확히 안나올 수도 있는데 괜히 시도해보다가 시간 버리지 마세용.

근데... SFTP 진짜 겁나 느립니다 ㅠㅠ 오토매틱 니들도 리눅스 써봤으면 다른거 시도 안해보겠냐고 젠장

부록: CMS와 가격대에 대한 이모저모

사실 CMS 생태계 관련 글도 써보려다가 정리가 잘 안되고 있는데, 워드프레스 얘기 꺼낸김에 조금 적어둡니다. (조금이라도 안적어두면 까먹으니까요)

요즘 현대적인 CMS들을 보면 가격대가 월 $200~500 정도로 상당히 높게 형성되어 있습니다. 근데 워드프레스닷컴 같은 경우 가장 비싼 "eCommerce" 플랜이 월 $45 로 상대적으로 매우 저렴합니다. 왤까요?

CMS 시장의 비싼 가격대의 핵심은 "컨텐츠 모델링" 기능에 있습니다. 유연하고 강력한 컨텐츠 모델링 기능을 갖춘 Headless CMS 제품은 eCommerce 사이트의 전체 서비스 레이어를 담당할 만큼 엄청난 퍼포먼스를 보여줍니다.

물론 워드프레스도 할 수 있지만 컨텐츠 모델링의 영역에서는 예쁜 쓰레기에 불과하다고 봐도 무방할 것입니다.

API Economy 시대가 되면서 웹사이트들도 뒷단에서 다양한 기술적 복잡성을 다루게 됐고 그에 따른 확장성(scalability)를 요구받았습니다. 이 확장성을 지원할 수 있는 강력한 컨텐츠 모델링 기능을 갖춘 Contentful 같은 제품들은 "컨텐츠 허브" 솔루션으로 성장한 반면 워드프레스는 역할이 많이 축소될 수 밖에 없었습니다.

뭐 워드프레스의 구텐베르크 에디터만은 현대 CMS 시장에서 찾아 볼 수 있는 에디팅 경험 중에서 탑티어라고 생각하지만, 상호운용 가능한 컨텐츠 모델링이 뒷받침 되지 않으면 결국 도태될 수 밖에 없습니다. 이 영역에서는 Sanity, Prismic 같은 쟁쟁한 신규 경쟁자와 승부를 가려야 할 것입니다.

TypeScript 튜플 타입 요리하기

Sun, 30 Aug 2020 00:00:00 GMT

지난 4월 말에 TypeScript Korea 그룹에서 타입스크립트에게 내 의도를 이해시키는 방법 이라는 주제로 발표했었습니다.

그 때는 막상 발표를 정해놓고 주제를 잘 정리하지 못해서 두서없이 이런저런 얘기를 했었습니다. 대략 어떤 내용이였냐면

타입스크립트가 타입을 추론하는 방식
타입 추론이 안전한 코드 작성에 어떻게 도움이 되는지
타입 추론을 더 쉽게 사용하기 위한 Type-level 유틸리티를 만드는 방법 (feat. infer)
안전하지 않은 타입을 안전한(컴파일러가 추론 가능한) 타입으로 캐스팅 하는 방법
튜플 타입 다루는 법

이 중에서 튜플 타입을 다루는 방법들에 대해서는 나중에 꼭 글을 써야지라고 생각만 하고 어기적거리고 있다보니 어느새 5개월이 지나고, 어느새 TypeScript 4.0이 출시되었으며, Variadic tuple이라는 새로운 문법의 등장으로 많은 변화가 생겼습니다.

상황이 이렇게 되니 한 편으로는 제 게으름에 대해 자괴감도 들고, 또 한 편으로는 새기능 소개를 한꺼번에 할 수 있으니 잘 됐다는 생각도 들고 그러네요.

이 글은 튜플 형태의 타입 정의 특성을 가볍게 다루기도 하지만 Conditional typing과 infer 키워드를 많이 활용하기 때문에 해당 기능에 대한 이해도가 어느정도 필요합니다. (타입스트립트의 타입 시스템을 타의 추종이 불가능할 정도로 강력하게 만들어주는 고급 기능이자 제가 아직 TypeScript를 사용하는 유일한 이유이기도 합니다)

튜플의 특징

type tuple = readonly [1, 'hello', false];

일반적으로 튜플은 불변 구조이기 때문에 readonly 키워드를 명시적으로 수식했습니다. 사실 어떤 인덱스에 어떤 자료가 들어있는지 기술한 시점부터 readonly 키워드가 명시적으로 있던지 없던지 그 성질은 동일합니다.

// $ExpectType readonly ['sun', 'mon', 'tue', 'wed', 'thu', 'fri', 'sat']
const days = ['sun', 'mon', 'tue', 'wed', 'thu', 'fri', 'sat'] as const;

이렇게 as const를 기술하면 쉽게 값의 정의로부터도 튜플 타입을 가져올 수 있습니다.

이렇게 정의된 튜플 타입의 값은 몇가지 고유한 성질을 가집니다.

Array 인터페이스를 만족하는 객체이기도 합니다.
인덱스 타입도 불변이며, 컴파일러가 그 정확한 값을 기억하고 있습니다.

즉, 위에서 정의한 days 의 타입은 이런 형태로도 기술될 수 있습니다.

{
  0: 'sun',
  1: 'mon',
  2: 'tue',
  3: 'wed',
  4: 'thu',
  5: 'fri',
  6: 'sat',
  readonly length: 7,
}

타입스크립트로 범용적인 유틸리티를 만들기 위해서는 이런 특징을 잘 활용해야 합니다. 제일 일반적인 형태를 뽑아보자면 readonly unknown[] 같이 뭉개지겠지만, 적어도 0번 인덱스와 length 는 참조할 수 있다는 사실은 변하지 않습니다. 따라서, 다음과 같은 유틸리티를 만들 수 있습니다.

type FirstEntry<T extends readonly unknown[]> = T[0];
type Length<T extends readonly unknown[]> = T['length'];

// 각 인덱스들의 가장 일반적인 형태(best common type)은 number 입니다.
// $ExpectType 'sun' | 'mon' | 'tue' | 'wed' | 'thu' | 'fri' | 'sat'
type Day = typeof days[number];

// $ExpectType 'sun'
type FirstDay = FirstEntry<typeof days>;

// $ExpectType 7
type CountOfDays = Length<typeof days>;

실제로 타입스크립트를 사용하면 Iterable한 값과 Enumerable한 타입 정의가 동시에 필요한 경우가 많이 있기 때문에 여기까지만 알아도 벌써 꽤 유용합니다.

하지만 아쉬운 점이 있다면, 인덱스가 항상 0으로부터 시작한다는 사실을 통해 FirstEntry<T> 유은 만들 수 있었지만 이에 대칭되는 LastEntry<T> 는 만들지 못했다는 사실이 대칭성을 사랑하는 저를 굉장히 불편하게 만들었습니다. "마지막 인덱스는 항상 length 값보다 1 작다" 라는 규칙을 알고 있지만 기존 타입시스템에서 표현할 방법을 모릅니다.

기본 타입추론의 기능의 한계를 만났기 때문에 infer가 등장할 차례입니다. LastEntry<T> 를 만드는 방법을 이어서 설명드리겠습니다.

함수 시그니쳐와 튜플

일반적인 함수 시그니쳐의 타입도 튜플과 연관이 있습니다.

interface Callable {
  (...args: any[]) => any
}

바로 위와 같은 가장 일반적인 형태(best common type)의 함수 정의에서 rest parameter 부분이 튜플(여기서는 any[])이거든요.

이런 rest parameters로 부터도 실제로 타입을 추론해낼 수 있는데, 타입스크립트에 내장되어 있는 유틸리티 타입 중 하나인 Parameters<T>의 정의가 이 성질을 활용합니다.

type Parameters<T> = T extends (...args: infer U) => any ? U : never;

Parameters<T> 를 사용하면 함수의 파라미터 배열의 형태를 튜플 형태로 추론해낼 수 있습니다.

이 성질을 조금 응용하면, 우리는 아까 만난 문제를 쉽게 해결 할 수 있습니다.

type DropFirst<Tuple extends readonly unknown[]> =
  ((...tail: Tuple) => any) extends ((head: unknown, ...tail: infer Tail) => any)
  ? Tail : never;

type Last<Tuple extends readonly unknown[]> = Tuple[DropFirst<Tuple>['length']];

// $ExpectType 'sat'
type LastDay = Last<typeof days>;

이해가 되시나요? 함수 시그니쳐에서 튜플을 추론할 수 있다는 성질을 통해 튜플 제약사항을 가진 타입 파라미터 요소(head)를 하나 잘라내었습니다.

Conditional typing에 익숙하지 않으시면 햇갈릴 수 있기 때문에 풀어서 설명해보겠습니다.

먼저, infer는 타입스크립트에게 타입 추론을 위한 특별한 규칙이 있음을 알릴 때 쓰이는 키워드로, 오직 Conditional type의 조건 정의 부분에서만 사용할 수 있습니다. 주어진 제약사항 맥락에서 infer를 만나면 타입스크립트는 "실제 타입"을 추적해서 조건이 참인 경우와 거짓인 경우를 각각 "브랜칭" 해주는 역할을 합니다.

타입 파라미터인 Tuple에서 일부분을 추론하기 위해, "항상 참인 제약사항"을 하나 만들었습니다. 타입 파라미터 Tuple 에 typeof days 를 전달했을 때, 제약사항 식은 ((...tail: typeof days) => any) extends ((head: unknown, ...tail: infer Tail) => any) 이 되는데 여기서 infer 에 의해 추가 파라미터 Tail이 정의됩니다.

타입 파라미터 Tuple은 이미 "튜플"이라는 제약사항을 가지고 있어 제약사항은 어떤 경우라도 참이 되며, head 하나를 제외한 나머지가 타입스크립트가 추론하는 Tail이 됩니다. 익숙해지면 간단한 트릭입니다.

타입레벨 재귀와 순회

타입시스템에서는 새로운 타입 = 기존 타입 * 기존 타입 처럼 기존의 타입들의 조합을 통해 새로운 타입을 정의할 수 있습니다.

당연히 새 타입을 정의할 때, 자신자신의 정의를 재활용 하는 것은 불가능 합니다.

type A = A;
//   ~
//    ^_____ Type alias 'A' circularly references itself.(2456)

정의하는 대상이 모호해지기 때문에 이는 직관적으로 당연한 것으로 느껴집니다.

하지만 추상 자료형을 정의할 때면 자기 자신의 정의를 활용할 일이 생깁니다.
예를 들면, 대표적인 자료형 중 하나인 단방향 연결 리스트를 타입으로 표현하면 이런식입니다.

type List<T> = {
  data: T,
  next?: List<T>,
};

타입스크립트를 포함한 많은 타입시스템들은 이렇게 추상 자료형을 포함하기 위해 제한적으로 자기 자신의 정의를 참조하는 재귀적인 형태의 타입 정의를 허용하고 있습니다.

타입스크립트의 경우에는 바로 위 코드처럼 레코드 형태의 타입의 필드 타입에서 자신의 타입을 참조하는 것이 허용됩니다. list.next?.next?.next?.next?.next 같은 값의 타입이 결정적으로 추론될 수 있는 유일한 구조입니다.

아까 튜플의 부분을 조작하기 위해서 함수 시그니쳐를 사용했 듯이, 튜플 타입을 "순회"하기 위해서 이러한 레코드의 특성을 응용할 수 있습니다. 물론 타입에는 흔히 사용하는 for나 while 같은 반복문이 없기 때문에 재귀를 사용합니다.

이전 섹션에서 배운 내용들을 응용해서 재귀를 통해 타입을 "누적" 하기 위한 유틸리티 타입을 하나 정의합니다.

type Append<Tuple extends readonly unknown[], Item> = (
  ((head: any, ...tail: Tuple) => void) extends ((...extended: infer Extended) => void)
  ? {
    [Index in keyof Extended]: Index extends keyof Tuple
      ? Tuple[Index]
      : Item
    }
  : never
);

type Prepend<Tuple extends readonly unknown[], Item> = (
  ((head: Item, ...args: Tuple) => any) extends ((...args: infer Result) => any)
    ? Result
    : never
);

// Does work well in v3.9.2, but doesn't in v4+
// $ExpectType [1, 2, 3, 4]
type Result0 = Append<[1, 2, 3], 4>;

// $ExpectType [0, 1, 2, 3, 4]
type Result1 = Prepend<Result0, 0>;

앗... 타입스크립트 버전이 4.0이 되면서 동작이 바뀌었는지 Append가 의도한대로 동작하질 않네요 ㅠㅠ 다음 섹션에서 새 기능을 이용해 고치는 방법을 설명드리겠습니다.

일단은 Append 대신 Prepend를 사용해보겠습니다. 이러면 누산한 결과가 뒤집히게 되기 때문에 이를 다시 뒤집어서 원래 의도한 결과대로 만들기 위해 추가적인 유틸리티를 정의하겠습니다.

type Reverse<Tuple extends readonly unknown[], Result extends readonly unknown[] = []> = {
  finish: Result,
  step: Reverse<DropFirst<Tuple>, Prepend<Result, Tuple[0]>>,
}[Tuple['length'] extends 0 ? 'finish' : 'step'];

type ReversedDropLast<Tuple extends readonly unknown[], Result extends readonly unknown[] = []> =
{
  finish: Result,
  step: ReversedDropLast<DropFirst<Tuple>, Prepend<Result, Tuple[0]>>,
}[Tuple['length'] extends 1 ? 'finish' : 'step'];

// 이렇게 재귀를 포함한 타입정의를 중첩하면 타입스크립트의 휴리스틱이 올바르게 동작하지 않는 경우가 많습니다.
// 하지만 실제로는 종료조건만 잘 포함되어 있다면 타입이 성공적으로 추론되므로 해당 라인에 @ts-ignore를 표시해 에러를 무시해버릴 수 있습니다.
// (제가 아는 한 이게 유일하게 올바른 ts-ignore 활용법입니다.)
type DropLast<Tuple extends readonly unknown[], Result extends readonly unknown[] = []> =
  // @ts-ignore
  Reverse<{
    finish: Result,
    step: ReversedDropLast<DropFirst<Tuple>, Prepend<Result, Tuple[0]>>,
    //                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    //                                                             ^_____ Type does not satisfy the constraint 'readonly unknown[]'.(2344)
  }[Tuple['length'] extends 1 ? 'finish' : 'step']>;
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
//                                               ^____ Type instantiation is excessively deep and possibly infinite.(2589)

// 근데 이렇게 중간 변수를 활용하면 또 뭐라고 안합니다;
type _WeekDay_1 = ReversedDropLast<typeof days>;
type _WeekDay_2 = Reverse<_WeekDay_1>;
                            
// $ExpectType ['mon', 'tue', 'wed', 'thu', 'fri']
type WeekDay = DropFirst<DropLast<typeof days>>;

앞 뒤로 붙어있는 요소를 하나씩 잘라내어 주말이 아닌 요일만 포함하는 튜플 타입을 얻었습니다!

예제에서 활용한 Reverse 와 DropLast를 자세히보면, 프로그래밍 처음 배울때 잠깐 지나간 재귀식과 생긴게 똑같다는 사실을 발견할 수 있습니다.

일단 재귀함수의 구성요소들을 다 가지고 있습니다. 값을 누적하기 위한 default parameter(Result)를 하나 정의하고, finish와 step이라는 필드로 구성된 레코드를 사용했습니다.

매 step마다 주어진 Tuple 파라미터를 하나 잘라서 원하는 타입을 만들어 Result 파라미터에, 나머지는 다시 Tuple 파라미터로 사용하여 재귀하고 있으며, Tuple['length']에 대한 제약사항을 종료식으로 사용하고 있습니다. 종료조건에 다다르면 finish 필드를 통해 Result에 누적한 타입을 얻게 됩니다.

와우, 이 정도면 정말 타입 레벨에서 프로그래밍이 가능하군요!

Variadic Tuple (+ v4.0)

가능한건 알겠는데 여러 제약사항을 피해다니느라 정의가 너무 크고 비직관적입니다.

저도 직접 필요한 타입을 몇 번씩 작성해보고 나서야 겨우 읽고 이해되기 시작했습니다. 불현듯 복잡한 정규표현식이나 Perl 코드를 일컫는 Write-only code 라는 표현이 떠오릅니다.

특히나 이런식으로 튜플과 관련된 타입을 다룰 때 쉽게 복잡해지기도 하고, 타입스크립트 휴리스틱에 의한 버그를 피하느라 ts-ignore 를 남발하게 되기도 합니다. ts-ignore의 문제점은 버전 변경 등으로 해당 코드가 동작하지 않게 되었을 때 감지할 수단이 없다는 점입니다. (거짓말입니다. dtslint 같은 도구로 "테스트 코드"를 작성하면 됩니다.)

타입스크립트는 버전 4.0에서 이런 튜플과 관련된 문제를 지원하기 위해 Variadic tuple 이라고 불리는 새로운 문법을 추가했습니다.

Variadic tuple은 튜플 타입에 대한 비구조화(rest/spread)를 지원해서 앞서 함수 시그니쳐를 응용하던 방법보다 훨씬 쉽게 유틸리티 타입들을 구현할 수 있게 해줍니다.

type Append<Tuple extends readonly unknown[], Item> = [...Tuple, Item];
type Prepend<Tuple extends readonly unknown[], Item> = [Item, ...Tuple];

type DropFirst<T extends readonly unknown[]> = T extends readonly [any?, ...infer U] ? U : [...T];
type DropLast<Tuple extends readonly unknown[]> = Tuple extends readonly [...infer U, any?] ? U : [...Tuple];

설명을 얹을 게 없을 정도로 간결하네요... Append와 Prepend 구현은 아주 직관적으로 바뀌었고, 표현이 넓어져서 DropLast를 구현하는데 재귀가 필요하지 않습니다.

이렇게 간결하고 직관적으로 바뀌니 앞서 했던 난해한 삽질들은 뭐였나 하며 허탈하기까지 합니다.

Variadic tuple에 대한 구체적인 설명과 유즈케이스들은 이를 실제로 구현한 PR에서 가장 잘 설명하고 있습니다. 그 밖에도 공식 예제와 릴리즈 노트에 설명이 잘 나와있습니다.

Flow의 $TupleMap 시뮬레이션 하기

Flow 쓰다가 TypeScript로 넘어오고나서 익숙해지는 동안 불편한 것들이 좀 많았는데, 그 중에서도 $TupleMap의 부재가 컸습니다.

드디어 Flow로 하는 것 중 TypeScript에서 안되는 거 찾았다. TupleMap 대안이 없어서 튜플 엔트리마다 제네릭 타입 씌우는 게 안되네
— Hyeseong Kim (@KrComet) August 17, 2018

($TupleMap 기능은 이전 포스트에서도 간단히 소개한 적 있습니다.)

2.8 버전에 대망의 Conditional type & infer 기능이 추가되고 나서부터 바로 재귀를 이용한 추론이 가능했는지는 모르겠지만, 당시에는 이런 아이디어를 배우기 전이였으므로 그냥 타입스크립트가 조금 구린걸로 치고 넘어갔었죠.

하지만 지금은 타입스크립트를 더 잘 사용할 수 있잖아요? [1, null, string, undefined]를 [Promise<1>, Promise<null>, Promise<string>, Promise<undefined>] 로 매핑하는 것 쯤은 껌이잖아요?

type TupleMapPromise<Tuple extends readonly unknown[], Result extends readonly unknown[] = []> = {
  finish: Result,
  step: TupleMapPromise<
    DropFirst<Tuple>,
    Append<Result, Promise<Tuple[0]>>,
  >,
}[Tuple['length'] extends 0 ? 'finish' : 'step'];

type t = [1, null, string, undefined];

// $ExpectType [Promise<1>, Promise<null>, Promise<string>, Promise<undefined>]
type r0 = TupleMapPromise<t>;

가능은 한데, Flow의 $Call과 같이 Type-leve application 구현이 가능한 수준은 아니라서 필요할 때마다 이런 재귀 타입을 작성해줘야 하는 것이 여전히 걸립니다.

몇 가지 제약사항을 임의로 건다면 더 편하게 재사용할 수 있는 유틸리티를 만들 수 있습니다. 가령 타입 파라미터를 하나만 받는 Nominal 타입들에 대해서만 제약한다면 알려진 타입을 모아 미리 구성된 유틸리티를 만들 수 있습니다.

// 잘 알려진 Nominal 한 타입들
type BoxType<T> = (
  | Promise<T>
  | Set<T>
  | Array<T>
);

type Wrap<T, Box extends BoxType<any>> = (
  Box extends Promise<any> ? Promise<T> :
  Box extends Set<any> ? Set<T> :
  Array<T>
);

type Unwrap<T extends BoxType<any>> = (
  T extends Promise<infer U> ? U :
  T extends Set<infer U> ? U :
  T extends Array<infer U> ? U :
  never
);

물론 Flow만큼 범용적이거나 확장 가능하진 않지만, 그래도 비슷한 사례들은 한꺼번에 모아 유틸리티를 만들 수 있게 됐습니다.

type TupleMapWrap<
  Tuple extends readonly unknown[],
  Box extends BoxType<any>,
  Result extends readonly unknown[] = []
> = {
  finish: Result,
  step: TupleMapWrap<
    DropFirst<Tuple>,
    Box,
    Append<Result, Wrap<Tuple[0], Box>>
  >,
}[Tuple['length'] extends 0 ? 'finish' : 'step'];

type TupleMapUnwrap<
  Tuple extends readonly BoxType<any>[],
  Result extends readonly unknown[] = []
> = {
  finish: Result,
  step: TupleMapUnwrap<
    DropFirst<Tuple>,
    Append<Result, Unwrap<Tuple[0]>>
  >,
}[Tuple['length'] extends 0 ? 'finish' : 'step'];

// $ExpectType [Promise<1>, Promise<null>, Promise<string>, Promise<undefined>]
type r1 = TupleMapWrap<t, Promise<any>>;

// $ExpectType [1, null, string, undefined]
type r2 = TupleMapUnwrap<r1>;

뭐 이 정도면 현업에서 쓰긴 충분한 것 같아요 (아마....?)

마무리하며

글에 소개된 예제들은 Playground에서 가지고 놀아볼 수 있습니다.

저는 이런 유틸리티들을 현업에서도 많이 사용하는 편이라 아예 라이브러리를 만들어 모아두고는 합니다.

사실 타입수준 유틸리티들을 구현하고 있는 많은 라이브러리들이 이미 존재하고, 저도 이런 라이브러리들에서 코드를 훔치면서 이런 테크닉들을 배울 수 있었습니다.

범용적인 유틸리티들은 이런 라이브러리에서 가져다가 쓰면 되지만, 그래도 직접 라이브러리 코드를 작성할 때면 종종 복잡한 타입을 작성하게 되는데 이런 테크닉들을 미리 배워두면 많은 도움이 되는 것 같습니다.

정확하게 작성되어 추론이 가능한 타입은 주변 개발자를 행복하게 합니다. 하지만 2시간 동안 타입 시그니쳐와 씨름하느라 실제로 돌아가는 코드를 작성하지 못했다고 하면 관리자는 화를 낼 수도 있습니다.

TypeScript의 타입시스템은 정말 강력한 마법이면서 동시에 헤어나기 힘든 늪과도 같습니다.

애초에 nominal 한 객체와 일관성 있는 인터페이스를 활용한다면 이런짓을 할 일이 없긴 하겠지만, 뭐 이건 JavaScript의 저주라고 해두겠습니다.

그런 의미에서 가장 유용한 유틸리티 타입을 소개드리며 마무리합니다.

type $FixMe = any;
type $FixMeInTomorrow = any;
type $FixMeInNextSprint = any;

Jamstack에서 스타일시트를 최적화하는 법

Sun, 02 Aug 2020 00:00:00 GMT

기여하던 gatsby-plugin-linaria 프로젝트의 소유권을 최근에 이전 받았습니다.

원 저자인 Matija Marohnić 가 더 이상 플러그인을 사용하지 않고 다른 기술 스택을 사용하고 있으며, 제가 중간에 대부분의 코드를 새로 작성하면서 이해도 차이가 생기게 되었는데 Matija 가 이 부분을 언급하면서 제게 소유권을 넘겼습니다.

저는 이 프로젝트에 기여하면서 CSS Extraction을 통한 Critical rendering path 최적화 기법과 이에 따른 trade-off 에 대한 이해도가 높아졌는데 글을 통해 이 부분을 공유해보고자 합니다.

기술적인 맥락

설명에 앞서 연관된 프로젝트들 소개를 잠깐 하겠습니다.

GatsbyJS SSR

GatsbyJS는 이제는 널리 알려진, Jamstack 사이트를 만들기 위한 프레임워크입니다.

Gatsby는 여러가지 놀라운 아이디어를 가지고 있는데 핵심적인 부분 중 하나는 React의 Server-side rendering을 빌드 시간에 딱 한 번 수행하는 것입니다. 이 기법은 Prerendering 이라고도 불립니다.

Gatsby의 플러그인들은 gatsby-ssr.js에서 제공되는 각종 Hooks을 통해 SSR에서 필요한 동작들을 정의합니다.

Zero-runtime CSS in JS

Linaria는 styled-components에서 영감을 받은 아주 유사한 API를 가진 CSS in JS 라이브러리 중 하나 이지만, 특이하게도 Zero-runtime CSS in JS 표방하고 있습니다.

Zero runtime? 말 그대로 styled-components 처럼 사용하는데 실제 런타임은 없는 것을 의미합니다. 이게 어떻게 가능한가요?

문서에서 설명하는대로 Linaria는 별도의 바벨 플러그인과 웹팩 로더를 통해 사용된 코드를 모두 추출해서 완전히 정적인 스타일시트를 생성합니다.

이 전에도 5 세대까지 구분이 나뉠 정도로 빠르게 진화해온 CSS in JS 생태계인데, Astroturf와 Linaria가 실현한 Zero-runtime은 이 후 CSS in JS 라이브러리를 선택할 때 고려하는 주요 기능 중 하나로 평가받게 되었습니다. (그럼 아마 6~7 th generation 쯤 되나요? ㅋㅋㅋ 신경쓰지마세요 아무 의미 없습니다.)

gatsby-plugin-linaria

gatsby-plugin-linaria는 Linaria를 통합하기 위한 GatsbyJS 플러그인 입니다. Gatsby와 CSS in JS 라이브러리, 예를 들면 Styled Components나 Emotion을 쓸 때도 마찬가지로 이런 플러그인들을 만들어 사용해야하는데, 주로 하는 일들은 이렇습니다.

함께 사용해야 하는 Babel/Webpack 플러그인을 설정합니다.
SSR 시에 필요한 처리들을 추가합니다.

Critical rendering path와 CSS Extraction

"SSR 시에 필요한 처리들" 이라는게 구체적으로 뭘 말하는건가요?

gatsby-plugin-linaria에서는 SSR 처리에서 Critical CSS Extraction이라고 하는 최적화 기법을 적용합니다.

CSS in JS 라이브러리들은 React 런타임에 의해 컴포넌트 트리가 렌더링 될 때 정확히 필요한 CSSOM 객체를 생성하기 때문에 동작이 매우 효율적이라고 할 수 있습니다.

하지만 Client-side Rendering(CSR)을 사용하는 앱은 번들 사이즈가 커지면서 지연되는 First Paint(FP)등의 성능 지표를 최적화 하기 위해 SSR을 고려하기 시작합니다. 그리고 SSR을 도입하는 순간 전에 없던 문제들이 생기기기 시작합니다.

그릴 수 있는 마크업이 먼저 등장하면서 "Flash of unstyled content" (FOUC) 문제가 발생합니다.
FOUC를 방지하기 위해 필요한 CSS 스타일시트를 우선적으로 로딩할 필요가 생깁니다.
마크업과 스타일시트가 각각 들어가면서 Critical rendering path가 길어집니다.

구체적으로는 2번을 위해 mini-css-extract-plugin 같이 잘 알려진 Webpack 플러그인을 통해 사용될 CSS 스타일시트를 추출하고 html-webpack-plugin 등으로 HTML 템플릿 상단에 주입하거나, 혹은 각 CSS in JS 라이브러리가 제공하는 서버 사이드 유틸리티를 통해 동적으로 처리할 수 있을 것 입니다.

하지만 3번에서 설명하듯이 또다른 문제가 차례로 나타납니다. Critical rendering path에 대한 설명은 구글의 웹 개발자 가이드인 Web Fundamentals의 Performance 섹션에서 아주 잘 설명하고 있습니다.

(이미지는 Ciritical rendering path 문서에서 가져왔습니다.)

최초 렌더링 시 최대한 빠르게 렌더링하려면 다음 세 가지 변수를 최소화해야 합니다.

주요 리소스의 수.

주요 경로 길이.

주요 바이트의 수.

(주요 렌더링 경로 최적화에서 발췌)

웹 사이트를 최적화하기 위해서는 주요 리소스 바이트의 수를 줄여야 한다고 얘기하지만 실제로는 최적화를 위해서 반대로 주요 렌더링 경로인 index.html 파일의 바이트 수를 늘리는 선택을 했습니다.

(이렇듯 모든 최적화는 Trade-off 를 가지고 있기 때문에 반드시 측정과 분석 후에 선택해야 합니다)

리소스 크기를 조금이라도 최소화하기 위해, 추출한 스타일시트 중에서도 정말 "Critical" 한 룰과 그렇지 않은 룰을 구분해서 처리할 필요가 생깁니다.

Linaria는 Critical CSS 관련 문서에서 이런 것들을 설명하고 있습니다.

import { collect } from 'linaria/server';

const { critical, other }  = collect(html, css);

linaria/server 모듈에서 제공하는 collect API는 HTML과 CSS 문자열을 각각 받아 CSS 중 실제로 HTML 에서 사용된 것을 critical, 나머지를 other로 구분합니다.

추출된 Critical CSS는 주요 렌더링 경로에서 사용하므로 문서 상단에 주입하고, 나머지는 <link> 태그로 비동기로 로딩하는 식으로 처리할 수 있습니다.

Zero-runtime의 Trade-off

위에 언급한 Linaria의 Critical CSS 문서에서 other 문자열을 서버에서 어떤식으로 다루어야 하는지에 대한 안내를 이어서 하고 있지만, 저는 Gatsby를 사용해서 Prerendering을 하고 있으니 같은 방식을 따를 수 없습니다.

Linaria를 통해 CSS 런타임을 제거하고, Gatsby로 SSR 런타임을 제거헤서 초기 런타임은 훨씬 가벼워졌지만, 이는 동적인 것을 효율적으로 처리할 수 있던 기존 레이어를 희생해서 얻은 최적화였습니다.

모든 유즈케이스가 정적으로 최적화 될 수 있는 것은 아닙니다. 사이트에 모달을 하나 추가하고, 이 모달 코드를 Code-spliting을 통해 분할 했다고 가정해봅시다.

스타일링에 Styled components나 Emotion을 사용하고 있었다면, 스타일링 코드가 렌더링 로직과 함께 앱 번들에 포함되어 있기 때문에 other 문자열 따위는 신경쓸 필요가 없었습니다.

반면 Gatsby와 Linaria 조합은 이런 유즈케이스를 대응하기 굉장히 까다롭습니다.

페이지 동작이 완전히 정적이라면, 즉 렌더 트리가 변경되지 않는 앱에서는 이것만으로 충분하지만 Gatsby에서는 기본적으로 페이지 별로 코드가 분할되어 있고 그 외 렌더 트리가 변경되는 코드도 충분히 사용할 수 있기 때문에 other에 대한 처리도 어떤식으로든 해줘야 합니다. 렌더 트리가 변경됐을 때 중복되는 스타일시트 룰 없이 Incremental 하게 나머지만 불러오기 위해서는 무언가 "런타임"이 다시 필요해짐을 깨닫게 됩니다.

"Critical 하지 않은 리소스"라도 여전히 로딩해야 하는 리소스입니다.

gatsby-plugin-linaria의 선택

하아... 그래도 가능한 복잡한 런타임 코드 없이 해보자구요.

저는 실제로 프로젝트에 gatsby-plugin-linaria를 사용하면서 이러한 상황에 직면했기 때문에 그 당시 열러 있던 이슈에 직접 응답하게 됩니다.

그리고 만든 Pull Reqest에서 저는 이 플러그인을 거의 재구현하게 됩니다.

일단 Gatsby는 기본적으로 mini-css-extract라는 웹팩 플러그인 설정을 내장하고 있으며 프로덕션 모드에서는 로딩된 CSS 스타일들을 모두 <head> 태그에 주입해줍니다. 네 말 그대로 "모든 스타일 (chunk: all)" 입니다.

Gatsby는 기본적으로 페이지 단위로 코드 스플리팅을 수행하기 때문에 일반적으로는 크게 문제가 없지만, Linaria의 기본 동작과는 상성이 조금 안좋습니다.

Linaria는 프로젝트의 전체 코드를 먼저 정적분석해서 CSS를 추출하고 .linaria-cache 경로에 저장하고 이를 웹팩 로더로 전달하는 구조를 가지고 있는데, 이 때문에 초기 구현에서는 프로젝트 전체의 스타일시트가 모든 페이지 상단에 주입되는 형태가 되어 있었습니다. 페이지에서 사용하는 스타일이 많던 적던 페이지와 컴포넌트가 많아지면 모든 페이지가 무거워지는 겁니다.

이 문제를 해결하기 위해 플러그인이 CSS Extraction을 적용하는 것은 선택이 아니라 필수적인 상황이였습니다.

일단 앞서 소개한 collect API를 적용했습니다.

let bodyHTML

exports.replaceRenderer = ({ bodyComponent }) => {
  // extract HTML first
  bodyHTML = renderToString(bodyComponent)
}

exports.onPreRenderHTML = ({
  pathname,
  getHeadComponents,
  replaceHeadComponents,
  getPostBodyComponents,
  replacePostBodyComponents,
}) => {
  let styles = []
  const headComponents = getHeadComponents().filter(/* filter only <style> */)

  // collect critical CSS
  const { critical } = collect(
    bodyHTML,
    styles.map(style => style.text).join('')
  )

  // Attach critical CSS into top of head
  replaceHeadComponents([
    <style
      key="linaria-critical-css"
      data-linaria-critical={pathname}
      dangerouslySetInnerHTML={{ __html: critical }}
    />,
    ...headComponents,
  ])

Critical CSS에는 다른 페이지의 스타일시트처럼 사용되지 않는 것들은 제외되어 있을 것이 자명하므로 중복 시트 문제는 해결할 수 있습니다.

이제 other를 어떻게 할지 생각해봅시다.

제일 쉬운 구현은 other 텍스트를 모두 파일로 저장해서 사용하는 것 입니다. 당시 진행하던 프로젝트에서 성능 측정을 해보았는데 여러모로 좋지 않은 구현 같았습니다.

대부분의 페이지에서 other가 critical 보다 큼
other 스타일 시트끼리는 내용이 거의 겹치지만, 매번 다른 파일로 로딩됨
중복되어 분할된 스타일시트를 불러오느라 transfer size가 전체적으로 매우 커짐

주요 렌더링 경로의 바이트 수는 조금 줄였지만, 전체 Transfer size는 큰 폭으로 커졌습니다.

저는 캐시 히트율이 제일 중요하다고 판단하고, 전체 스타일시트를 비동기로 로딩하는 것으로 결정했습니다.

이를 위해 먼저 Linaria 스타일시트 청크를 분할했습니다.

if (config.optimization) {
  // Split chunk for linaria stylesheets
  config.optimization.splitChunks.cacheGroups.linaria = {
    name: 'linaria',
    test: /\.linaria\.css$/,
    chunks: 'all',
    enforce: true,
    // Set priority grater than default group
    priority: 1,
  }
}

Linaria의 스타일시트는 .linaria.css 라는 확장자를 가지고 있기 때문에 어렵지 않게 분할했고, 이를 통해 다른 CSS 라이브러리나 외부 스타일시트를 사용할 때 영향을 주지 않도록 격리할 수 있었습니다.

이렇게 분할한 청크는 mini-css-extract 설정에 의해 별도 파일로 추출되는데 이걸 비동기로 로딩하도록 <link> 태그를 삽입합니다.

// Attach other and critical into bottom of body
// This also includes critical css because of cache hit
replacePostBodyComponents([
  ...getPostBodyComponents(),
  styles
    .map(style => style.href)
    .map(href => (
      <link key={href} rel="stylesheet" type="text/css" href={href} />
    )),
])

이러면 각 페이지마다의 Critical CSS가 "중복된 바이트"나 마찬가지이지만 어쨋든 FOUT 문제를 해결하기 위해 사용되었고, 전체 스타일시트는 한 번 불러와지고 모든 페이지에 대해 공유되니 큰 낭비는 없다고 볼 수 있습니다.

마무리하며

많은 유즈 케이스에 대응하다보면 종종 "은총알은 없다"는 유명한 격언을 되새기게 됩니다.

웹에서 할 수 있는 많은 최적화들이 성능을 위한 은총알처럼 소개되고는 하지만 모든 상황에 통하는 것은 아니며, 당연히 사이즈를 줄이는게 정답이라고 여겨지지만 가끔은 의도적으로 사이즈를 키우는 선택을 해야할 때가 있습니다.

그리고 대부분의 Statically optimized, Zero-runtime 이라고 언급하는 도구들은 큰 제약사항을 기반으로 최적화를 제공하기 때문에 무엇을 잃는지를 제대로 파악하고 실제 사례 분석을 통해 도입을 결정하는 것이 중요합니다.

뭐 이런 것들 말고도 요즘 CSS in JS 커뮤니티는 꾸준히 진화를 거듭해서 요새는 Atomic CSS 라고 하는 기법이 주로 다뤄지고 있고 Zero-runtime의 제약사항을 돌파하기 위해 near zero-runtime을 언급하는 경우가 더 많아졌습니다. 확장성 높은 Theme에 대한 연구도 여전히 활발하게 진행되는 듯 합니다.

이렇게 생태계가 진화하는 것을 배우고 기여하다보면 저도 자연히 성장하게 되는 것 같아 즐겁습니다. 가끔은 너무 자주 바뀐다며 볼맨소리도 하게 되지만 ㅋㅋ; 웹 개발 커뮤니티의 진화에 발 맞추기 위해 다시 한 번 각오를 다져야겠습니다.

그나 저나 1년 2개월 지나 글 쓰는 내가 전설이다 진짜 하...

GraphQL is not just a network protocol

Mon, 19 Aug 2019 00:00:00 GMT

GraphQL을 알게 된지는 꽤 지났습니다. 예전엔 GraphQL을 단순히 요즘 유행하는 새로운 API 개발 방식으로만 이해하고 관심을 가지는 정도였지만, 꾸준히 커뮤니티 동향을 살펴보고, 프로덕션에 사용해보면서 이 기술에 대한 확신이 생겼습니다.

저는 다양한 상태관리 접근법 중에서 Redux를 가장 사랑하지만, 동시에 Apollo Client, Relay Modern 같은 GraphQL 엔진들이 이를 대체할 수 있는 가장 좋은 방법이라고 생각합니다.

그래서 "Client-side GraphQL" 라던가 "State management with GraphQL" 같은 주제를 아직 접해보지 못한 분들에게 영업을 해보는게 이번 포스트의 목표입니다.

잠깐 잠깐, 갑자기 왠 상태관리? GraphQL은 REST를 대체하는 API 개발 방법론 같은거 아니였나요

GraphQL과 상태관리의 연관성을 얘기하려면 먼저 GraphQL이 단순한 "쿼리 언어" 라던지 "API 개발을 위한 서버사이드 런타임" 이라는 인식부터 깨부숴야 합니다.

GraphQL is a query language for your API, and a server-side runtime for executing queries by using a type system you define for your data.

미친 소리처럼 들릴 수도 있겠지만, 네. GraphQL 소개 첫 문장인 바로 그 부분이요. 오늘날의 GraphQL 은 아주 색다르고 흥미로운 방향으로 발전하고 있습니다. 적절한 예시와 함께 큰 그림을 살펴보겠습니다.

예제 프로젝트: HackerNews Client

데모를 위해 Public API를 제공하는 HackerNews 클라이언트를 ~~굳이 하나 더~~ 만들어 보겠습니다.

일부분에 대해서만 포스트에서 소개하고 동작하는 전체 소스코드는 조만간 GitHub에 공개하도록 하겠습니다. (도와주실 분 대환영)

원하는 동작은 다음과 같습니다.

현재 순위대로 HackerNews 트렌드를 볼 수 있어야한다.
불편한 페이지네이션 대신 무한스크롤로 동작하면 좋겠다.
스토리를 "즐겨찾기"에 등록하고 이 목록을 유지했으면 좋겠다.

여기서 한 가지 문제는 저는 GraphQL 예제를 보여주고 싶은데 HackerNews는 GraphQL API를 제공하지 않습니다. 직접 만들어야하나요? 다행히도 일반적인 REST API를 GraphQL 엔드포인트에 통합하는건 아주 쉽게 달성할 수 있습니다.

일단 Apollo Client를 활용해봅시다.

Apollo Link

Apollo Client는 현재 자바스크립트 생태계에서 가장 인기 있는 GraphQL 클라이언트입니다.

GraphQL 클라이언트는 단순히 요청을 보내고 응답을 파싱하는 것보다 많은 일을 처리해야되기 때문에 그 동작이 결코 단순할 수 없습니다. (Relay의 Thinking in GraphQL 포스트를 참고해보세요)

이를 위해 Apollo Client는 Link라는 제어흐름 단위를 엮어 행위를 관측가능한 상태로 만드는 것(Operation → Links → Observable)을 핵심 컨셉으로 소개합니다.

Note that although we have the terminating link requesting GraphQL results from a server in this figure, this doesn't necessarily have to be the case: your GraphQL results can come from anywhere. For example, apollo-link-state allows to use GraphQL operations to query client state.

본문에서 설명하듯, 흔히 사용하는 apollo-link-http(GraphQL 서버를 연결하는)도 그런 링크들 중 하나이고, 그 밖에도 다양한 구현체들이 있습니다.

그 중 하나인 graphql-link-rest를 사용하면 GraphQL 쿼리에 REST API 엔드포인트와 엔티티에 대한 힌트가 되는 디렉티브를 추가해서 REST API 클라이언트처럼 사용할 수 있습니다.

와 쉽다! 아무 서버 로직 작성 없이 GraphQL로 해커뉴스 클라이언트를 만들었군요!

더 나은 스키마

약속한 기능들을 추가하기 전에 짚고 넘어갈 만한 부분들이 있습니다.

해커뉴스의 API는 모델의 단순함을 유지하기 위해 Item이라는 추상모델만 제공하고, 이 때문에 클라이언트는 위험한 가정들을 많이 떠안게됩니다. 결국 코드가 더러워질거라는 얘기죠.

GraphQL은 쿼리 언어인 만큼, 쿼리할 수 있는 데이터 형식을 정의하는 스키마를 가지고 있습니다. 이 스키마를 표현하는 언어를 GraphQL SDL(Schema Definition Language)이라고 부릅니다.

해커뉴스 API를 SDL로 제가 원하는 형태가 되도록 재정의해보겠습니다. 좀 더 구체적이고, 데이터를 구분하는데 도움이 되는 형태로요.

scalar Date
scalar URL

schema {
  query: Query
}

# 커서 기반 페이지네이션의 일부분을 구현합니다.
# 더 불러오기에 필요한 부분만을 선언하고
# 이 외 Edge, Connection에 대한 선언은 생략합니다.
type PageInfo {
  endCursor: String
  hasNextPage: Boolean!
}

type ItemsOutput {
  items: [Item!]!
  pageInfo: PageInfo!
}

type StoriesOutput {
  stories: [Story!]!
  pageInfo: PageInfo!
}

type JobsOutput {
  jobs: [Job!]!
  pageInfo: PageInfo!
}

type Query {
  user(id: ID!): User!
  items(first: Int! = 20, after: ID): ItemsOutput!
  topStories(first: Int! = 20, after: ID): StoriesOutput!
  newStories(first: Int! = 20, after: ID): StoriesOutput!
  bestStories(first: Int! = 20, after: ID): StoriesOutput!
  askStories(first: Int! = 20, after: ID): StoriesOutput!
  showStories(first: Int! = 20, after: ID): StoriesOutput!
  jobStories(first: Int! = 20, after: ID): JobsOutput!
}

type User {
  id: ID!
  createdAt: Date!
  about: String!
  karma: Int!
  submitted: [Item!]!
}

interface Item {
  id: ID!
  createdAt: Date!
  createdBy: User!
}

interface Commentable {
  comments: [Comment!]!
}

# Story and Ask
type Story implements Item & Commentable {
  id: ID!
  createdAt: Date!
  createdBy: User!
  comments: [Comment!]!
  url: URL!
  title: String!
  score: Int!
}

type Comment implements Item & Commentable {
  id: ID!
  createdAt: Date!
  createdBy: User!
  comments: [Comment!]!
  parent: Commentable!
  contentHtml: String!
}

type Job implements Item {
  id: ID!
  createdAt: Date!
  createdBy: User!
  score: Int!
  title: String!
  contentHtml: String!
}

type Poll implements Item & Commentable {
  id: ID!
  createdAt: Date!
  createdBy: User!
  comments: [Comment!]!
  title: String!
  parts: [PollPart!]!
  score: Int!
}

type PollPart implements Item {
  id: ID!
  createdAt: Date!
  createdBy: User!
  poll: Poll!
  text: String!
}

자, 이러면 많은 것들이 명확해지네요! API 모델을 좀 더 구체화하고 커서 기반 페이지네이션을 위한 모델을 부분적으로 추가 정의했습니다.

그리고 이 스키마는 자체적으로 기존 API 정의나 추가 문서들을 다 합친거보다 더 구체적으로 API가 제공하는 데이터들과 데이터 사이의 관계, 사용법까지 서술합니다.

기존의 정의방법으로는 이런 수준의 API 제공이 불가능하다는 얘기가 아닙니다.

GraphQL에서 제공하는 필드 수준의 로직 구현, 직관적인 관계 표현, 인터페이스와 유니온, 타입 수준 검증, 커스텀 스칼라 같은 훌륭한 도구들이 이 것을 더 현실적으로 만들어준다는 것입니다.

적어도 엔드포인트와 밸리데이션 로직을 중복 정의할 필요가 없어지니 생산성이 높다고 확신할 수 있습니다. 아마 OpenAPI (Swagger)를 즐겨 사용하시는 분이라면 그 유용함을 바로 이해하실 수 있을 것입니다.

리졸버 구현하기

아까 썼던 REST Link를 계속 쓸 수도 있겠지만 타입 정의랑 디렉티브를 일일히 붙이는게 다소 번거로워 보입니다. 타입을 재매핑 하는 것을 어디까지 표현할 수 있을지도 확실하지 않습니다.

차라리 커스텀 리졸버를 만들어 쓰는게 더 편하겠네요. 만들어 보겠습니다.

리졸버의 인터페이스는 이렇게 생겼습니다.

function resolver(root, args, context, info);

간단히 설명하자면 각각

root: parent라고 쓰는 경우도 많습니다. 바로 이전 리졸버, 그러니까 쿼리상 한계층 위에 있는 리졸버의 리턴값입니다.
args: 해당 필드에 전달된 arguments 값 입니다.
context: 한 쿼리가 실행될 때 리졸버 간에 공유되는 컨텍스트 객체입니다.
info: 쿼리 실행상태에 대한 대부분의 정보를 담고있는 메타데이터 객체입니다. 복잡한 커스텀 디렉티브 리졸버를 구현하는게 아니라면 쓸 일이 거의 없습니다.

리졸버를 작성해 보신적이 없다면 이 것에 대해 아주 자세히 설명해둔 Prisma Blog의 포스트가 있으니 참고해보시는 게 좋습니다.

리졸버 코드는 스키마로부터 생성할 수도 있고, 프레임워크를 사용할 수도 있지만, 가장 기본적인 형태는 Field→Resolver가 매핑되어 있는 오브젝트를 정의하는 것입니다.

const Resolvers = {
  Query: {
    user(_, { id }, { client }) {
      return client.getUser(id);
    },

    async items(_, { first = 20, after }, { client }) {
      // 해커뉴스는 최근 500개 아이템만 일괄적으로 내려주니 일단 이렇게 합시다.
      const allItems = await client.getItems();
      const cursorIndex = after
        ? allItems.findIndex(item => item.id === after)
        : 0;
      const items = allItems.slice(cursorIndex, first);
      const { length: l, [l-1]: endItem } = items;
      const pageInfo = {
        endCursor: endItem?.id ?? null,
        hasNextPage: allItems.lastIndexOf(endItem) < allItems.length - 1,
      };
      return { items, pageInfo };
    },
    // ... 쭉 이어서 쿼리 리졸버 작성
  },

  Item: {
    __resolveType(obj) {
      return obj.type;
    },
  },

  Commentable: {
    __resolveType(obj) {
      return obj.type;
    },
  },
  // ... 쭉 이어서 타입 리졸버 작성
};

아까 정의한 스키마 정의와 지금 정의한 리졸버 맵이 있으면 바로 GraphQL API를 실행할 수 있습니다. graphql-tools 같은 걸 써서 실행기를 만들고 익숙한 Express 같은 서버에 붙이면 되거든요.

Apollo Server, GraphQL Yoga 같은 프로젝트들은 이 모든 것들을 사전 구성으로 제공하고 있습니다.

어쨋든 결국 서버를 띄워야 한다는 소린가요? 그럴 수도 있고, 여전히 아닐 수도 있습니다.

리졸버 옮기기?!

리졸버의 인터페이스 선언을 보시고 눈치채셨을 수도 있는데, Context 활용만 주의하면, 나머지는 인자 몇 개 받는 JavaScript 함수 집합에 불과합니다.

리졸버 만들 때 서버에서만 활용되는 DB 컨텍스트 같은 걸 쓴게 아니라 그냥 REST client(대충 fetch나 axios 같은걸 썼다고 가정하죠)를 호출한게 다니까, 저 리졸버는 클라이언트에서 실행하는 데 아무 문제가 없습니다.

Apollo에서는 서버 외 환경, 예를 들면 브라우저에서도 GraphQL 리졸버를 실행할 수 있게 끔 graphql-anywhere 라는 유니버셜한 런타임을 제공하고 있습니다.

그리고 Apollo Client가 이 런타임을 사용해서 "클라이언트 스키마", "클라이언트 리졸버" 를 실행합니다.

그게 바로 apollo-link-state 입니다.

State 링크는 이름 그대로 로컬 상태를 GraphQL 리졸버로 관리하는 도구입니다. 아까 작성한 스키마와 리졸버를 등록해두고 쿼리할 때 @client 디렉티브를 추가하면, HTTP 요청이 날라가는 대신 클라이언트 사이드 리졸버가 실행됩니다.

자세한게 궁금하신 분은 Local state management 포스트에서 더 읽어보시는 걸 추천드립니다.

API 확장하기

예제 프로젝트에서는 전체 스키마가 클라이언트 사이드에서 구현되었지만 사실 서버사이드 GraphQL API가 있을 때가 더 중요합니다. 클라이언트 스키마는 서버 스키마를 확장해서 사용하는 것이 더 일반적이기 때문입니다.

예를 들어 Item이라는 타입이 서버에서 제공되고, 하나의 Item에 클라이언트에서만 사용될 bookmarked 라는 boolean 값을 추가하고 싶을 때,

extend type Item {
  bookmarked: Boolean!
}

extend type Query {
  bookmarkItems: [Item!]!
}

클라이언트만 알고 있는 모델 확장이지만 서버의 어떤 데이터로 부터 파생되는지(또는 아예 의존하지 않는지)가 명확합니다.

이렇게 스키마를 정의해두면 마찬가지로 해당 필드에 @client 디렉티브를 붙여 서버에 보낼 쿼리와 한꺼번에 실행할 수 있습니다. 더 나아가서는 @export 같은 추가적인 디렉티브를 활용해서 배치처리를 하는데 활용할 수도 있습니다.

mutation PostBookmarkItems($ids: [ID!]!) {
  # 클라이언트 필드가 먼저 리졸브된다.
  bookmarkItems @client {
    # 이러면 id의 배열로 매핑되는 걸 기대하지만 아직 안될지도 모른다.. 테스트 필요
    id @export(as: "ids")
  }
  # 클라이언트 리졸버에서 채운 캐시 데이터를 활용해서 서버 필드를 리졸브한다.
  # 이보다 더 자연스럽게 클라이언트 상태와 API를 통합하는 방법이 또 있을까
  postItems(ids: $ids) {
    result
  }
}

클라이언트 상태 저장하기

GraphQL 서버가 Data Loader를 활용해서 응답을 캐시하는 것 처럼 같은 용도로 GraphQL 클라이언트 들도 저마다의 인메모리 캐시 구현을 사용합니다.

하지만 이건 휘발성 캐시기기 때문에 새로고침 한 번으로 초기화될 것 입니다. 서버가 없다고 가정하면, 최소한 북마크 정보 같은걸 보존하기 위해서는 브라우저의 LocalStorage 같은데 데이터를 동기화할 필요가 있습니다.

데이터를 보존하기 위함이 아니더라도 cache persistence로부터 store를 rehydration 하는 것은 일반적인 PWA의 사용성(흔히 Offline-first 라고 하는)을 위해 중요한 동작이지만 redux-offline 같은걸 써보셨다면 조금 귀찮게 느끼실 수도 있습니다.

Apollo Client는 상황이 훨씬 좋은게, 애초에 자체적으로 구현한 인메모리 캐시를 기반으로 하는 cache-first 접근이기에 오프라인 지원을 위해 개발자에게 추가적인 무언가를 거의 요구하지 않습니다. 단 몇 줄의 초기화 코드로 오프라인 지원을 활성화 할 수 있습니다.

import { persistCache } from 'apollo-cache-persist';

const cache = new InMemoryCache({...});

await persistCache({
  cache,
  storage: LocalStorage,
});

const client = new ApolloClient({
  cache,
  ...
});

아직 top-level await 문법이 stage 3이라서, persistCache를 기다리게 하기 위해서 프레임워크의 라이프사이클에 의존하는 코드로 변경해야 할겁니다 흑흑...

이러면 Apollo Client 는 캐시를 조작하는 모든 오퍼레이션에서 localStorage 데이터와의 동기화를 알아서 수행할 것입니다. 물론 동작방식이나 화이트리스트/블랙리스트 등을 옵션으로 커스텀 할 수 있습니다.

이것만 했을 뿐인데, Offline Support랑 FMP(First Meaningful Paint) Time 개선이 공짜로 굴러들어왔네요!

REST API, Redux와의 비교

리액트 같은 프론트엔드 프레임워크를 다루다보면 상태를 어디에 둘 것인가로 고민하게 됩니다. 상태를 적절히 배치했더라도 언젠가 상태를 공유하는 새로운 컴포넌트가 등장함에 따라 리팩토링을 요구합니다.

이 케이스를 더 자세히 들여다 보면 상태는 크게 "데이터 의존성"과 "UI 상태"로 나뉩니다. 대부분의 관리 코스트는 외부에서 주입되는 (또는 자체적으로 생산하는) 데이터 의존성에 의해 발생한다는 사실을 깨닫게되고, 프론트엔드 개발자들은 이런 의존성을 효과적으로 관리하기 위해 글로벌 상태관리 전략을 찾게 됩니다.

이런 의존성 데이터가 많은 제품을 개발할 때, 그러니까 비즈니스 로직이 복잡할 수록 모델이 크면 클 수록 백엔드 개발자와 프론트엔드 개발자의 제품에 대한 이해도는 갈라지는데, 대부분의 데이터 모델이 프론트엔드의 "글로벌 상태"와 백엔드의 "데이터베이스"에 정규화되는 형태가 판이하게 다르기 때문입니다.

이는 REST API가 결코 해결해주지 못한 문제입니다. 백엔드와 클라이언트 양쪽 모두 고려하는 이상적인 API는 (적어도 제가 경험한 것 중에는) 없습니다. API 스펙을 작성할 때 어찌됬건 한쪽의 의견이 크게 반영되고 RESTful이냐 BFF냐가 정해짐에 따라 한쪽은 모델 간 바인딩으로 씨름하게 됩니다. 이 문제에서 현대의 프론트엔드 프레임워크가 씨름한 결과가 지금의 Redux 같은 글로벌 상태관리 패턴들이라 볼 수 있습니다.

반면 GraphQL을 Relay나 Apollo Client 같은 라이브러리들은 GraphQL 만을 이용해서 글로벌 상태관리의 핵심 아이디어들을 모두 구현합니다. 그러면서도 서버와 같은 데이터 모델을 공유하고, 같은 로직을 공유하고, 데이터가 어디서 파생되었는지를 다 명시적으로 관리할 수 있고, 좀 더 똑똑하게 캐시를 활용합니다.

이 모든 것을 "알아서 잘" 해결하기 때문에 Redux의 보일러플레이트 지옥도 없습니다.

큰 그림 이해하기

이쯤 왔으면 React와 GraphQL을 창시했으며 실제로 가장 활발하게 사용하고 있는 Facebook의 큰그림이 뭔지 다시 한 번 돌아볼 필요가 있습니다.

먼저 리액트의 아이디어는 단순하게 표현하자면 선언적 UI 관리입니다. UI 표현에 특화되면서 동시에 단순한 "어떤 언어"를 제공하고 (React), 개발자가 이 언어로 "선언"한 것을 바탕으로 DOM 등을 알아서 조작합니다. (React DOM, React Native)

하지만 상태를 다루어야하기에 UI 개발은 여전히 복잡했습니다. 페이스북의 처음 시도는 Flux였죠, Flux는 상태→UI, 상호작용→상태변경 이라는 간결한 워크플로우를 제안했고, 현재까지도 리액트 자신과 몇몇 계승자들은 이 아이디어를 계속 확장해나가고 있습니다.

하지만 그럼에도 상태관리가 점점 복잡해지자 진짜 문제는 "데이터"였음을 깨닫고, "데이터를 위한 리액트"가 필요함을 알아차렸을 것입니다. 페이스북은 이를 "Declarative data fetching"이라고 표현합니다. (저는 "똑똑한 의존성 관리"라는 표현을 더 즐깁니다.) 리액트가 UI 조작에 대한 스트레스를 없애준 것과 똑같은 방식으로 GraphQL과 Relay를 통해 데이터 의존성 관리에 대한 고민을 없애버린 것입니다.

(비유하자면 GraphQL이 React 내지는 JSX에 해당하고, Relay가 React DOM이나 RN에 해당하겠네요.)

이를 위해 진짜 새로운 언어를 만들었다는 점만이 다릅니다.

새로운 언어라는 것은 GraphQL이 단순히 웹 서버나 클라이언트만을 생각해서 만든게 아니라는 데이터를 다루는 모든 영역에서 활용될 수 있음을 의미합니다. GraphQL의 유즈케이스를 살펴보면 실제로 데이터베이스, 마이크로서비스, API 서버, 모바일 클라이언트 등 말 그대로 데이터를 다루는 모든 곳에서 활용되고 있습니다.

그렇게 GraphQL 기반으로 구성된 애플리케이션에서는 뒷단에서 앞단으로 올 수록 데이터가 어떻게 확장되고, 의존성이 어떻게 뻗어 나가는지 일목요연하게 추적할 수 있는 장점이 생깁니다.

모놀리식 구조가 아닌 이상에야 DB Schema, Domain, Redux Action 등 같이 각 개발 영역에서 파편화된 단위 때문에 백엔드/프론트엔드 라는 양 극단으로 갈라졌던 개발팀이 GraphQL Schema라는 하나의 언어를 가지고 데이터 기반으로 소통할 수 있게 되는 것입니다.

GraphQL Anywhere

실제로 데이터를 사용하는 모든 곳에서 활용된다는 GraphQL 유즈케이스가 구체적으로는 어떤게 있는지 대략적으로 살펴봅시다.

Prisma

Prisma는 이전의 Graphcool이라는 BaaS를 제공하려던 조직에서 분리된, GraphQL을 기반 오픈소스 쿼리엔진을 만드는 팀입니다.

MySQL, PostgreSQL 같은 전통적인 RDBMS을 기반으로 GraphQL API를 생성하는 가장 강력한 도구인데 대략 이런식의 워크플로우를 제공합니다.

Prisma SDL로 데이터 모델을 작성한다.
데이터 모델 선언을 바탕으로 DB 테이블과 클라이언트 API가 자동으로 생성된다. 자동으로 생성된 GraphQL API를 통해 DB를 조작할 수 있고, 원하는 언어로 바인딩된 코드로 사용할 수도 있다.
이 DB 클라이언트를 빌딩 블럭으로 사용해서 애플리케이션을 개발한다.

Full-feature GraphQL API로 BFF API를 개발하는데 특화되어 굉장히 생산성 높은 개발경험을 자랑하는 프레임워크입니다.

REST API, GraphQL API, gRPC API, 심지어 일반 CLI 앱까지 다양한 예제를 제공하니 한 번 가볍게 살펴보시는게 좋습니다.

FaunaDB, EdgeDB

Prisma가 ORM에 비교된다면 아예 태생부터 DB에서 직접 Native GraphQL을 지원하려는 시도도 많이 있습니다.

그 중 대표적인 것이 바로 FaunaDB와 EdgeDB입니다.

FaunaDB는 클라우드 DB 서비스로 자주 소개되서 알고는 있었는데, 솔직히 둘 다 직접 사용은 해보지 않아서 자세한 리뷰가 어렵습니다.

다만 저는 DB들이 SQL 보다 GraphQL을 기본 쿼리 언어로 제공하게 되는 것이 앞으로의 트렌드라고 봅니다. SQL에 비교하면 더 적은 파편화, 오픈소스기반 도구 생태계, 더 강력하고 우아한 표현력 등 그러지 않을 이유가 없거든요.

GraphQL Code Generator

최근들어 제가 가장 자주 사용하고 있는 범용 도구가 바로 이 코드 제너레이터 입니다.

GraphQL Code Generator

GraphQL SDL이나 Introspection을 주면 그에 맞는 코드를 생성합니다. 생성할 수 있는 코드는 다양한데 주로 타입 언어에서 타입선언이 매핑된 코드를 뽑는데 활용합니다.

GraphQL과 타입언어를 같이 사용하는 코드베이스에서 더블 타이핑 문제를 겪고 계신다면 필수적으로 사용해야할 도구입니다.

Relay Modern, Apollo Client

아까 클라이언트 사이드에서 서버 스키마를 확장하는 예시를 보여드렸는데 현재까지 이를 지원하는 라이브러리/클라이언트는 Apollo Client와 페이스북의 프레임워크인 Relay Modern 뿐입니다.

릴레이가 좀 더 원조격이라고 볼 수 있죠.

Apollo Federation

스키마를 확장해서 사용하는 것은 당연히 서버사이드에서도 가능합니다. 원래는 Schema Stitching이라고 불리는 조금 투박하게 여러 스키마를 머지하는 방법을 사용했는데, Apollo Federation은 이를 extend type 문법을 사용해 우아하게 해결했습니다.

이걸 사용하면 쉽게 GraphQL 기반의 마이크로 서비스 아키텍처를 달성할 수 있습니다. 각 컴포넌트 서비스에서 GraphQL 스키마를 노출하고 게이트웨이에서 숨기거나, 확장하거나, 통합하거나를 직관적으로 표현이 가능합니다.

GatsbyJS

제가 이 블로그를 만들 때 사용한 GatsbyJS라는 프레임워크도 GraphQL을 아주 창의적으로 사용합니다.

일단 Gatsby가 Relay 컴파일러 아키텍처를 사용해서 빌드타임에 사용할 스키마를 생성합니다.

Gatsby의 플러그인 시스템은 이 빌드 타임에 생성되는 데이터 노드들을 확장하고, 변환하는 역할을 수행하며, 이를 말단 노드에서 작성한 리액트 컴포넌트에서 Gatsby GraphQL로 의존하면, Gastsby가 이 코드를 컴파일타임에 추출하고 분석해서 알맞는 데이터를 주입합니다.

사용법에 대한 문서 말고도 내부 동작에 대한 문서를 보시면 정말 재밌습니다.

조금 특이한 케이스들

apollo-link-rest: 예제에서 사용했던, REST API를 GraphQL 쿼리로 호출하기 위한 링크입니다.
gdom: 이게 특이하다면 특이한게, 데이터랑 별 관계없이 GraphQL 쿼리의 표현력만을 이용해서 웹사이트를 크롤링하는 도구입니다.
graphql-css: 심지어 CSS-in-JS와 비슷한 접근법으로써도 소개된적이 있습니다

마무리하며

이렇게 GraphQL은 API 개발 말고도 정말 다양하게 사용되고 있으며, 여전히 새로운 사용 케이스가 개척되고 있습니다.

이를 가능케 했던 데는, 설계자인 페이스북이 다양한 형태의 데이터를 다루는 것에 대한 높은 이해도와, 개밥먹기 하면서 오픈소스로 공개한 다양한 도구들이 출발이였고, 이후에는 Apollo, Prisma 처럼 GraphQL 활용에 깊게 공감하는 조직의 등장도 있었지만 가장 중요한 건 거대한 오픈소스 커뮤니티의 조성이였습니다.

그러다보니 GraphQL은 하루가 다르게 성장하는 기술이 되었고, 조금 보수적인 입장에서는 아직 안정화되지 않은 기술이라고 보이게도 하는 것 같습니다만, GraphQL이 많은 영역에서 이미 사용되고 있는만큼 GraphQL의 "어떤 부분"을 의심하고 있는지는 돌아볼 필요가 있습니다.

REST API의 대체제로써 GraphQL은 Facebook, GitHub, Shopify, Medium 등등... 더 검증을 언급하는 것이 무의미할 정도로 프로덕션에서 활발하게 사용되고 있습니다.

GraphQL Production Case Studies

저는 서버사이드 API 말고도 프론트엔드 개발자로서 데이터 기반 개발 방법론, 클라이언트 상태관리의 대체, 공유가능한 코드 런타임으로써의 GraphQL에 좀 더 관심을 가지고 다양한 걸 시도해볼 생각입니다.

GraphQL의 미래는 정말 밝습니다. 이 글을 읽어주시는 분들도 서버 개발자라면 꼭 시도해보시는 걸 추천드립니다. 클라이언트 개발자라면, 서버가 아니더라도 활용할 여지가 많으니 역시 시도해보시는 걸 추천드립니다.

혹시 GraphQL 관련 스터디 하실 분 있으면 메일이나 트윗 주세요 :)

(번역) Thinking in GraphQL

Mon, 08 Apr 2019 05:30:00 GMT

역주: 들어가며

이 글은 Facebook의 데이터 기반 리액트 프레임워크인 Relay의 문서 Thinking in GraphQL를 번역한 글입니다.

저는 릴레이라는 프레임워크를 사용하진 않지만 GraphQL을 만든 페이스북의 문제해결 방식을 엿볼 수 있는 좋은 글이라 생각되어 번역해보았습니다.

GraphQL는 (서버와 클라이언트 양측 모두) 인메모리 캐시를 적극적으로 활용하여 기존 REST API에 있던 문제점을 해결하며 데이터를 현대적인 뷰(React) 구조에 맞게 제공합니다.

캐시를 통한 데이터 정규화 과정은 GraphQL을 다루는 서버와 클라이언트 모두 알아야 하는 핵심적인 부분임에도 GraphQL을 소개할 때 잘 언급되지 않으며 REST API에 비해 비교적 쉬운 진입장벽만 강조되어 섣불리 GraphQL을 도입했다가 어려움을 겪는 과정을 몇 번 목격했습니다.

온갖 프레임워크가 쏟아지는 오늘날 어떤 프레임워크가 더 예쁘고 편한 API를 제공하느냐를 아는 것 만큼 그 이면에 숨겨진 철학과 기술적 접근방식을 이해하는 것이 중요합니다. 이 번역을 통해 국내 커뮤니티에서 GraphQL에 대한 (올바른 측면의) 이해도가 개선될 수 있기를 희망합니다.

GraphQL은 클라이언트 애플리케이션에서 개발자가 필요한 데이터에 불러오는데 초점을 맞춰, 뷰에 필요한 데이터를 정확하게 지정해서 한 번의 요청으로 통해 불러올 수 있는 새로운 방법을 제시합니다. GraphQL은 리소스 기반의 REST 같은 기존 접근 방법에 비해 더 효과적으로 데이터를 불러오고, 서버 측에서 중복된 로직이 반복되거나, 이를 피하기 위해 커스텀 엔드포인트를 추가하는 일을 작업을 방지하며, 더 나아가서 제품 코드를 서버의 로직으로부터 분리(Decouple)하는 것을 돕습니다. 예를 들면, 관련 서버 엔드포인트의 변경 없이 더 많거나 적은 정보를 가져오게끔 변경할 수 있습니다.

이 글에서는 GraphQL 클라이언트 프레임워크를 구성하는 요소들을 살펴보고 기존 REST 기반 시스템과 어떤 차이점이 있는지 알아보겠습니다.

데이터 불러오기

스토리 목록을 불러오고, 각 스토리별 추가 디테일을 불러오는 간단한 애플리케이션을 상상해보세요. 리소스 기반 REST API를 사용하는 코드는 다음과 같을 겁니다.

// 스토리 ID 목록을 가져옵니다. 상세정보는 포함되어 있지 않습니다.
rest.get('/stories').then(stories =>
  // This resolves to a list of items with linked resources:
  // 여기서 링크된 리소스로부터 아이템 목록을 가져옵니다.
  // `[ { href: "http://.../story/1" }, ... ]`
  Promise.all(stories.map(story =>
    rest.get(story.href) // 링크 따라가기
  ))
).then(stories => {
  // 스토리 아이템 목록을 가져왔습니다.
  // `[ { id: "...", text: "..." } ]`
  console.log(stories);
});

이 방법은 n+1회 요청을 필요로 합니다. 1은 목록을 불러오고, n은 각 항목의 상세를 불러오는거죠. GraphQL을 사용하면 같은 데이터를 한 번의 네트워크 요청으로 가져올 수 있습니다. (관리해야 할 커스텀 엔드포인트를 추가하지 않고도 말이죠)

graphql.get(`query { stories { id, text } }`).then(
  stories => {
    // 스토리 아이템 목록을 가져왔습니다.
    // `[ { id: "...", text: "..." } ]`
    console.log(stories);
  }
);

이 코드는 GraphQL을 사용한 것만으로 일반적인 REST 접근법 보다 더 효율적인 버전이 됐습니다.

모든 데이터를 단 한 번 네트워크 왕복으로 불러왔습니다.
클라이언트는 필요한 데이터가 있는 서버 엔드포인트들에 의존하는 대신 필요한 데이터를 표현하게 됐습니다.
(서버 클라이언트 디커플링)

간단한 애플리케이션에서도 벌써 많은 개선이 보입니다.

클라이언트 캐싱

서버로부터 반복적으로 정보를 다시 불러오는 것은 앱을 상당히 느리게 만들 수 있습니다. 예를 들면, 스토리 목록에서 특정 항목으로, 그리도 다시 목록으로 돌아오면 전체 목록을 다시 한 번 불러오게 됩니다. 이를 해결하는 표준적인 방법이 바로 캐싱입니다.

리소스 기반의 REST 시스템에선, 응답 캐시를 URI에 기반해서 관리합니다.

var _cache = new Map();
rest.get = uri => {
  if (!_cache.has(uri)) {
    _cache.set(uri, fetch(uri));
  }
  return _cache.get(uri);
};

GraphQL도 마찬가지로 응답 캐시를 사용합니다. 기본적인 접근법은 REST 비슷하지만, 캐시의 키 값으로써 쿼리 자체가 사용된다는 것이 다릅니다.

var _cache = new Map();
graphql.get = queryText => {
  if (!_cache.has(queryText)) {
    _cache.set(queryText, fetchGraphQL(queryText));
  }
  return _cache.get(queryText);
};

이제 이전에 캐싱 된 데이터를 통해 네트워크 요청 없이 바로 응답을 만들 수 있습니다. 캐시는 애플리케이션의 유의미한 성능 향상을 위한 실용적인 방법이지만, 데이터 일관성 문제를 유발할 수 있습니다.

캐시 일관성

GraphQL을 사용하면 여러 쿼리 결과가 겹치는 일이 매우 일반적입니다. 하지만 이전 섹션에서 설명한 캐시 방식은 이러한 중첩을 처리하고 있지 않습니다. — 각각이 고유한 쿼리를 기반으로 캐싱되고 있습니다. 예를 들어 스토리 목록을 가져오는 경우:

query { stories { id, text, likeCount } }

그리고 likeCount가 하나 증가된 후에 개별 항목을 가져오는 경우:

query { story(id: "123") { id, text, likeCount } }

이제 스토리를 어디서 보느냐에 따라 서로 다른 likeCount 값을 보게 됩니다. 첫 번째 쿼리를 사용하는 뷰는 지난 값을 사용하고 있고, 두 번째 쿼리를 사용하는 뷰는 새로운 값을 사용하고 있습니다.

그래프 캐싱하기

GraphQL이 이 문제를 해결하는 방법은 여러 계층의 레코드 응답을 단일 계층의 컬렉션으로 정규화(Nomalize)하는 것입니다.

릴레이는 이를 레코드의 ID를 기반으로 하는 맵으로 구현합니다. 여기서 각 레코드는 필드의 이름과 값을 기반으로 하는 맵입니다. 레코드들은 다른 레코드(순환 그래프를 허용)에 링크될 수 있고, 링크들은 최상위 맵으로 다시 참조되는 특수한 타입으로 저장됩니다.

이 방식을 통해 각 서버 레코드는 어느 화면으로부터 불리던 관계 없이 한 차례만 저장됩니다.

스토리의 텍스트와 작성자의 이름을 가져오는 쿼리 예제입니다.

query {
  story(id: "1") {
    text,
    author {
      name
    }
  }
}

그리고 그 응답입니다.

query: {
  story: {
     text: "Relay is open-source!",
     author: {
       name: "Jan"
     }
  }
}

이런 계층적인 응답이 주어지면 릴레이는 모든 레코드를 다음과 같이 병합합니다.

Map {
  // `story(id: "1")`
  1: Map {
    text: 'Relay is open-source!',
    author: Link(2),
  },
  // `story.author`
  2: Map {
    name: 'Jan',
  },
};

이 건 아주 단순한 예시일 뿐입니다. 실제 캐시는 one-to-many 관계과 페이지네이션을 처리해야하기 때문에 더 복잡합니다.

캐시 사용하기

그래서 이 캐시는 어떻게 사용될까요? 관련된 두 가지 작업에 대해 알아보겠습니다.

응답을 받고 캐시에 저장하는 작업
캐시를 읽고, 쿼리가 로컬에서 전부 처리될 수 있는지를 결정하는 작업
(위에서 구현한 _cache.has(key)와 거의 동일하지만, 그래프 버전)

캐시 채우기

캐시를 쓰는 작업에는 계층적인 응답으로부터 정규화된 레코드를 생성하거나, 정규화된 캐시 레코드를 업데이트하는 일이 포함됩니다.

처음에는 응답 자체만 처리해도 될 수 있지만, 이는 아주 간단한 쿼리들만 해당되는 얘기입니다. user(id: "456") { photo(size: 32) { uri } } 쿼리를 생각해보세요. — 어떻게 photo를 저장해야 할까요? photo라는 이름만 사용하면 다른 인자 값을 사용해서 쿼리하는 경우(예시: photo(size: 64) {...})에는 제대로 동작하지 않습니다. 비슷한 이슈로 페이지네이션을 처리할 때 stories(first: 10, offset: 10) 이라는 쿼리로 11번 째부터 20번 째 스토리 목록을 불러온다면 새로운 결과들은 기존 목록 뒤에 추가되어야 합니다.

따라서 GraphQL에서 응답 캐시 정규화 작업은 페이로드와 쿼리 구문을 함께 처리해줘야 합니다. 예시로 들었던 photo 필드는 이름과 인자 값을 구분하기 위해 photo_size(32) 같은 고유한 필드를 생성해서 캐싱합니다.

캐시에서 데이터 읽기

캐시로부터 각 필드의 값을 불러오려면 쿼리를 읽고 각 필드를 Resolve 하면 됩니다. 그런데 잠깐, 이건 GraphQL 서버가 쿼리를 처리할 때 하는 일과 똑같네요?

그렇습니다! 캐시를 읽는 것은 마치 특수한 경우의 쿼리 처리기 처럼 동작합니다.

모든 결과가 고정된 데이터 구조에서 나오며 커스텀 필드 리졸버가 필요하지 않고
결과가 항상 동기화 되어 있는 경우

— 캐시 된 데이터는 있을 수도 없을 수도 있는데 말이죠.

릴레이는 쿼리문 탐색(캐시나 응답 페이로드의 데이터와 함께 쿼리를 처리하는 작업)의 몇 가지 변형을 구현하고 있습니다. 예를 들면, 쿼리를 수행할 때 릴레이는 "diff" 탐색을 실행해서 어떤 필드들이 누락되어 있는지(리액트가 가상DOM 트리를 diff 하는 과정과 매우 흡사함)를 판단합니다. 이렇게 하면 평균적으로 가져오는 데이터 양을 줄일 수 있고, 쿼리가 완전히 캐시되어 있다고 판단되면 릴레이는 아예 네트워크 요청을 하지 않게 됩니다.

캐시 업데이트

정규화된 구조를 통해 중첩된 결과를 중복 없이 캐시하는 방법을 알아보았습니다. 이제 예제로 돌아가 이 캐싱 기법이 기존 시나리오의 일관성 문제를 어떻게 해결하는지 확인해봅시다.

첫 번째로 스토리 목록을 불러오는 쿼리가 있습니다.

query { stories { id, text, likeCount } }

정규화된 응답 캐시에는 목록의 모든 스토리들에 대한 레코드가 생성됩니다. 그리고 stories 필드에 레코드들에 대한 링크가 저장됩니다.

하나의 스토리 정보를 불러오기 위해 다시 다음 쿼리가 수행되는 경우

query { story(id: "123") { id, text, likeCount } }

이 쿼리의 응답이 정규화 되면, 캐시는 해당 id 필드를 가진 기존 데이터와 겹치는 것을 감지하고 새 레코드를 만드는 대신 기존 123 레코드를 업데이트 합니다. 이제 이 두 쿼리, 뿐만 아니라 스토리를 참조하는 모든 쿼리가 새로운 likeCount 값을 참조하게 되었습니다.

데이터/뷰 일관성

캐시 정규화를 통해 캐시의 일관성을 보장했습니다. 하지만 뷰는 어떨까요? 이상적으로는, 리액트 뷰는 항상 캐시의 현재 정보를 반영해야합니다.

스토리의 텍스트와 작성자 정보와 커멘트를 함께 렌더링하는 경우를 고려해보세요. 쿼리는 다음과 같을겁니다.

query {
  story(id: "1") {
    text,
    author { name, photo },
    comments {
      text,
      author { name, photo }
    }
  }
}

초기에 스토리를 불러오면 다음과 같이 캐시 됩니다. 여기서 스토리와 댓글은 동일한 author 레코드를 참조합니다.

// Note: 이건 `Map` 초기화의 구조를 좀 더 분명하게 설명하기 위한 의사코드입니다.

Map {
  // `story(id: "1")`
  1: Map {
    text: 'got GraphQL?',
    author: Link(2),
    comments: [Link(3)],
  },
  // `story.author`
  2: Map {
    name: 'Yuzhi',
    photo: 'http://.../photo1.jpg',
  },
  // `story.comments[0]`
  3: Map {
    text: 'Here\'s how to get one!',
    author: Link(2),
  },
}

스토리의 저자가 댓글도 등록했습니다 — 꽤 일반적인 상황이죠 :p 이제 다른 뷰에서 작성자에 대한 추가 정보와 그녀의 변경된 프로필 사진 정보를 가져온다고 가정합시다. 이 경우, 캐시 된 데이터 중 오직 한 부분만이 바뀝니다.

Map {
  ...
  2: Map {
    ...
    photo: 'http://.../photo2.jpg',
  },
}

photo 필드의 값이 변경 되었기 때문에 2번 레코드가 변경되었습니다. 이게 전부입니다. 캐시에서 그 이외 부분은 영향을 받지 않습니다. 하지만 뷰는 작성자와 스토리 UI에 새로운 사진을 표시하기 위해 전체적으로 변경될 필요가 있습니다.

가능한 흔한 해결책은 "그냥 불변(Immutable) 객체를 쓰자" 입니다. — 그러면 어떤 일이 일어나는지 확인 해보죠.

ImmutableMap {
  1: ImmutableMap {/* 이전과 같음 */}
  2: ImmutableMap {
    ... // 다른 필드는 변경되지 않았음
    photo: 'http://.../photo2.jpg',
  },
  3: ImmutableMap {/* 이전과 같음 */}
}

2번을 새로운 불변 레코드로 교체하면, 캐시 객체도 새로운 불변 인스턴스를 얻게 됩니다. 하지만 레코드 1과 3은 변경되지 않았습니다. 데이터가 정규화 되어 있기 때문에 스토리 레코드만 보면 스토리의 컨텐츠 변경을 알 수가 없습니다.

뷰 일관성 보장하기

정규화된 캐시에서 뷰의 일관성을 유지하는 다양한 솔루션이 있습니다. 그 중에서 릴레이가 사용하는 방법은 각 UI 뷰의 데이터 매핑을 참조하는 ID들의 세트로써 관리하는 것입니다.

위 예제에서 스토리 뷰는 1 스토리, 2 작성자, 3을 포함한 댓글들의 변경내용을 각각 구독합니다. 캐시에 데이터를 쓸 때, Relay는 영향을 받는 ID들을 추적해서 뷰에 통보합니다. 더 나은 성능을 위해 영향을 받는 뷰만 다시 렌더링되고, 영향을 받지 않는 뷰는 무시할 수 있습니다. (릴레이는 안전하고 효율적인 기본 shouldComponentUpdate 메서드를 제공합니다) 이 전략이 없다면 모든 뷰가 아주 작은 변경사항에도 매번 다시 렌더링 될 것입니다.

이 솔루션은 쓰기 작업들에도 동일하게 적용됩니다.

뮤테이션

데이터를 쿼리해오며 어떻게 최신 상태를 유지하는지 알아보았습니다. 이번엔 쓰기 과정을 알아봅시다. GraphQL에서의 쓰기 과정은 Mutation이라고 불립니다. 이 것은 쿼리와 사이드이펙트가 혼합된 형태로 볼 수 있습니다.

스토리에 좋아요 표시를 하는 뮤테이션을 호출하는 예시입니다.

# 읽기 좋은 이름과 입력 타입을 함께 정의합니다.
# 여기서는 좋아요 표시할 스토리의 아이디
mutation StoryLike($storyID: String) {
   # 뮤테이션 필드를 호출해서 사이드 이펙트를 트리거 합니다.
   storyLike(storyID: $storyID) {
     # 뮤테이션이 완료된 후 다시 가져올 필드들을 정의합니다.
     likeCount
   }
}

뮤테이션 호출로 (아마도) 변경된 데이터를 쿼리했습니다. 여기서 분명 왜 서버가 변경된 것만 알아서 알려줄 수 없는지 궁금할 수 있습니다. 그건 좀 복잡한 문제입니다.

GraphQL은 모든 종류의 데이터 저장 레이어(또는 여러 소스의 집합)를 추상화하며, 어떤 프로그래밍 언어와도 함께 동작합니다. 더 나아가 GraphQL의 목적은 제품 개발자가 뷰를 만드는데 유용한 폼으로 데이터를 제공하는 것입니다.

우리는 GraphQL 스키마가 실제 디스크에 저장되는 데이터의 형태와는 조금 아니 거의 대체로 다르다는 것을 발견했습니다. 간단히 말하자면, 제품 내 데이터 구조(GraphQL)와 데이터 저장소(디스크) 레이어의 데이터는 항상 1:1로 대응하진 않습니다. 그 예시로 개인정보의 경우 age 같은 개인정보 필드를 접근할 수 있는지 판단하기 위해 데이터 저장소 레이어에서 수 많은 레코드에 접근해야 될 수 있습니다. (친구인지, 공유된 정보인지, 블록되지 않았는지 등등)

이런 현실적인 제약사항들을 감안한 GraphQL의 접근법은 뮤테이션 이 후 결과들이 변경될 수 있는 것들만 쿼리하는 것입니다. 그럼 쿼리에는 정확이 어떤 것들이 들어가나요? 릴레이를 개발하면서 우리는 몇 가지 아이디어를 탐색했습니다. — 릴레이의 접근 방식을 이해하기 위해 몇 가지 다른 접근 방식들과 함께 살펴봅시다.

옵션 1: 앱에서 쿼리한 적 있는 것들을 모조리 다시 불러옵니다. 데이터 중 아주 작은 부분만 변경되더라도 서버가 전체 쿼리를 수행하고, 결과를 다운로드하고, 그게 다시 후처리 되는 것을 기다려야 합니다. 이 방식은 매우 비효율적입니다.
옵션 2: 현재 뷰에서 보여지는 것들만 다시 불러옵니다. 이 방식은 옵션 1 보다는 조금 개선되었습니다. 그러나 캐시된 데이터 중 현재 뷰에 보여지지 않는 부분들은 업데이트 되지 않습니다. 이 데이터들이 어떤식으로든 만료된 데이터로 표시되지 않는 한, 이후 쿼리는 오래된 정보를 읽게 될 것입니다.
옵션 3: 뮤테이션 이후 변경될 수 있는 고정 필드 목록을 다시 불러옵니다. 우리는 이걸 팻 쿼리라고 부릅니다. 실제로는 팻 쿼리 중에 일부만 렌더링하기 때문에 이 방법 또한 비효율적이긴 하지만 제대로 데이터를 불러오긴 할 것입니다.
옵션 4: 변경될 수 있는 부분(팻 쿼리)과 캐시 된 데이터의 겹치는 부분만 다시 불러옵니다. 릴레이는 데이터 캐시에 추가로 각 항목을 가져오는 데 사용된 쿼리를 기억하고 있습니다. (역주: 캐시의 키 값으로 저장되어 있음) 이 것을 추적된 쿼리라고 부릅니다. 이 추적된 쿼리와 팻 쿼리를 교차시킴으로써 릴레이는 앱에서 업데이트 할 필요가 있는 정보만을 정확히 쿼리할 수 있습니다.

데이터 패칭 API

지금까지 우리는 데이터 패칭의 저레벨 측면과 다양한 기존 컨셉들이 어떻게 GraphQL에 적용되었는지 살펴보았습니다.

이제 뒤로 한 번 물러나 제품 개발자가 데이터 패칭과 관련해서 자주 접하는 고레벨 관점의 문제들을 살펴봅시다.

뷰 계층구조에 따라 데이터 불러오기
비동기 상태 전이와 요청 동시성 관리하기
에러 관리하기
실패한 요청 재시도하기
쿼리/뮤테이션 응답에 따라 로컬 캐시 업데이트하기
경쟁상태를 피하기 위해 뮤테이션을 큐에 넣기
서버의 뮤테이션 응답을 기다리는 동안 UI를 낙관적(Optimistically) 업데이트하기

우리는 필수 API를 사용하는 데이터 수집에 대한 전형적인 접근방식들이 개발자들에게 불필요한 복잡성을 너무 많이 다루도록 강요한다는 것을 알게됐습니다.

서버 응답을 기다리는 동안 사용자에게 피드백을 주는 방법인 낙관적 UI 업데이트가 그 예시입니다. 무엇을 해야하는지 로직은 꽤 명확합니다. 사용자가 "좋아요"를 클릭하면, 스토리를 좋아하는 것으로 표시하고 서버에 요청을 보내야 합니다. 하지만 구현은 종종 훨씬 복잡해집니다. 명령형 접근방식을 사용하면 UI에서 버튼을 가져와 토글하고, 네트워크 요청을 보내고, 필요하면 재시도하고, 실패하면 에러를 보여주고 (버튼 토글을 취소하고) 기타 등등의 절차들을 모두 구현해야합니다. 데이터 패칭도 마찬가지입니다. 필요한 데이터가 무엇인지 지정하기에 따라 데이터를 가져오는 방법과 시점이 달라지는 경우가 많습니다. 다음 글에서 릴레이가 이런 문제들을 어떻게 해결하는지 알아보겠습니다.

역주: 마무리하며

목차 상 다음 문서는 Thinking in Relay입니다. 이어서 번역할 계획은 없지만 이 글에서 설명한 내용들이 리액트와 어떻게 통합되는지를 설명한 비교적 짧은 글이기에 한 번 읽어볼 것을 추천드립니다.

문맥을 매끄럽게 하기 위한 의역과 내용을 정확히 전달하기 위한 직역이 뒤죽박죽 섞여있습니다. 더 나은 번역에 대한 피드백은 언제든시 환영합니다.

원 글의 저작권은 MIT 라이센스에 따라 Facebook에 있으며 번역에 대한 저작권은 명시하지 않습니다. (아래 CC는 무시)

나는 어떻게 오픈소스 커뮤니티를 통해 성장했나

Sun, 30 Sep 2018 00:00:00 GMT

들어가며

Mattermost에 대해 궁금하신 분은 이전 글을 참고해주세요 :)

제가 Mattermost 커뮤니티에 발들인지 어느새 2년이 되었습니다. 지금은 오픈소스 기여 활동에 대해 그렇게 어렵게 받아들이지 않고 부딪힐 수 있게 되었습니다. 그렇게 잘 하는 편은 아닙니다만... 근자감이 생겼다고나 할까. 어쨋든 뭐든지 첫 단추가 중요하다는 말이 맞는 것 같습니다.

오픈소스 문화에 매료되어 주변사람들에게 막 전파하고 ~~약을 팔고~~ 싶지만 사실 어느날 갑자기 커다란 프로젝트에 뛰어들어 이슈를 파악하고 PR을 보낸다는 것은 쉬운일만은 아닙니다. 저도 막상 돌아보면 시작하게 된 계기가 있었습니다.

이야기를 읽기 좋은 순서로 각색해서 시간순서는 사실과 다를 수도 있습니다. ~~목적은 사실전달이 아니라 약팔이거든요~~

시작하게 된 계기

솔직히 처음 시작했던 계기는 타의가 더 컸습니다. 이러니 저러니 해도 계기가 없으면 시작하기 힘든법이지요.

저와 Mattermost는 좀 복잡한 관계가 있었지만, 사실 이 중 하나만 있더라도 시작하는데 부족함은 없었을거라 생각합니다.

사용자, 시스템 관리자, 비즈니스 파트너

제 첫 직장은 소프트웨어 개발 회사가 아니라 솔루션 영업과 기술 지원을 제공하는 회사였습니다. 공부해왔던 게임 개발이 아니여도 괜찮다라고 생각했지만 막상 들어간 회사에서 하게되는 일이 소프트웨어 개발과 관련 없게 될 줄은 몰랐습니다. 간단한 코딩이나 서드파티 개발은 종종해야 했지만 풀타임 개발과는 거리가 많이 멀었습니다. (주업무는 못된다는 느낌)

그렇게 솔루션 기술지원 업무를 하던 와중 2014년부터 실리콘밸리에서 Slack이 엄청난 인기를 끌었고, 2015~2016년에는 국내에서도 이메일을 대신한 메시징 기반 커뮤니케이션에 대한 관심이 뜨거워졌습니다. 저도 트렌드를 따라가기 위해 리서치를 해야 했습니다.

Slack은 On-premise 계획이 (아마 지금도)없다고 했고, 당시 유력하게 봤던 Atlassian의 (지금은 Slack에 인수된) HipChat은 도저히 쓸만해 보이지 않았습니다.

그 당시 저는 Open source alternative라는 키워드에 꽂혀 있었습니다. 비싼 구독모델이 판을 치는 시기에 쓰고 싶은 소프트웨어를 다 구독하기에는 돈이 너무 모자랐다는게 이유였고, 대안으로 사용할 수 있는 무료 오픈소스 소프트웨어를 곧잘 찾아 쓰고는 했었습니다.

그러다보니 자연스럽게 슬랙의 오픈소스 대안으로 소개된 Mattermost, Rocket.Chat 등을 알게됐고, 그 중에서 특히 Mattermost가 (적어도 그 당시엔) 가장 완벽한 슬랙의 대안으로 보였습니다.

적극적으로 의견을 알리자 곧 회사에서 Mattermost와 파트너쉽을 맺고 영업을 시작했고, 저는 관련 기술지원을 하게 되었습니다. 그리고 회사 자체에서도 이메일 대신 사용하기 괜찮다고 판단이 됐는지 제가 테스트용으로 올렸던 서버에 그대로 눌러앉아 쓰기 시작했습니다.

이렇게 저는 Mattermost의 사용자이자, 어드민이자, 파트너라는 복잡한 관계에 놓이게 됐습니다.

오픈소스와 비즈니스의 갈등

오픈소스 전략을 채택한 많은 회사들은 클라이언트들에게 오픈소스 커뮤니티의 구성원이 되는 것을 요구합니다. 그렇지 않고서야 사용자 지원은 해주지만 로드맵 충돌이 생기는 것은 어쩔 수 없는 일입니다.

오픈소스와 엔터프라이즈 비즈니스의 통합은 이상적인 부분만 본다면 조금만 타협해서 서로 오래 윈윈할 수 있는 전략입니다만, 소위 "갑" 문화가 발달해있는 국내에서는 어려워 보였습니다.

우린 커뮤니티라는 벤더와 돈 줬으니 무조건 해달라는 고객의 이해가 완전히 엇갈리고(하지만 회사는 그 사실을 잘 모르고), 그 중간에 끼게 될 저는 돌파구를 찾아야했습니다. 클라이언트에게 "요구하신 건 이 솔루션 로드맵과는 거리가 멀어서 반영이 어렵겠습니다" 하고, 보스에게 "이건 로드맵을 완전히 무시하는 터무니없는 요구사항입니다"하면서 무시할 수는 없으니까요.

실제로 비즈니스가 시작되고 PoC를 하는 과정에서부터 고객의 요구사항이랑 충돌하는 부분이 많이 나왔습니다.

"이거 오픈소스니까 소스코드 다 볼 수 있는거 아니냐?"

중간에서 Mattermost 클라이언트를 커스터마이징해서 제공하는 것으로 결정되면서 제 악몽이 시작되었습니다. 릴리즈 주기인 2달 마다 맞춰서 커스텀 코드를 리베이스 해줘야 했고, 혼자 죽을 맛이였습니다.

비개발자에게 지속적인 코드 리베이스의 어려움을 어떻게 설명해야 했을까요...ㅎㅎ; 저는 일찍이 소통을 포기하고 빌드타임 핵을 통해 부분적으로 커스텀 컴포넌트를 덮어씌우는 Workaround를 고안하는 둥 어떻게든 "기술적으로 해결하고자" 열심히 부족한 머리를 굴렸지만, 어떤 핵도 제대로 유지보수가 되지 못했습니다.

Mattermost는 끊임없이 발전하고 있었고, 저는 그 발전을 억지로 따라가다가 지칠대로 지쳐버렸습니다. 여기서 저는 처음으로 Burn-out을 경험합니다.

열심히 발버둥 치던 저는 결국 직접적인 컨트리뷰션 밖에 답이없다고 결론을 냈고, 이 주장으로 인해 회사와는 끊임없이 충돌해야 했습니다.

어쨋든 Mattermost의 엔터프라이즈 로드맵에 의견을 내고, 피드백을 모아 전달하는 것은 Community-driven 하게 운영되는 Mattermost에서 아주 자연스럽게 수용되었습니다. 회사에서는 일 제대로 안하는 사람이 되어가는 것 같았지만 커뮤니티의 분위기가 참 맘에들어 꾸역꾸역 했습니다.

고객으로부터 그리고 내부 사용자로부터 주로 보고되던 문제점 중 "한국어 지원이 미흡한 것 같다"가 있었는데 그 중 한 번은 해시태그의 한국어 지원이 되게 해달라는 요구가 있었습니다. 이미 티켓이 수개월 전에 열려있었지만 개발자 중에서 한국어 사용자가 없다보니 쭉쭉 뒤로 밀린 것 같았습니다. 마냥 기다릴 수는 없었고, 이 이슈가 제게 첫 "코드로써의 기여"가 되었습니다.

PLT-2077 Support CJK Hashtags

하고보니 "생각보다 할만한데?" 하는 느낌이 들었습니다.

함께하는 개발에 대한 동경

예전 회고글에서도 썼지만, 저는 솔루션 지원 일을 하면서도 개발자가 되고자 하는 목표를 버리지 않았습니다.

이전부터 만들고자 하는게 있다면 만들어 쓰고, 혼자서 개발 공부도 하고 있었지만 개발자가 되기엔 큰 장벽이 하나 있었습니다.

바로 "협업해본 경험이 없다"는 점 입니다. 실제로 신입 개발자가 가질 수 밖에 없는 가장 큰 약점이고, 많은 회사들이 신입 뽑기를 꺼려하는게 이유 또한 여기서부터 비롯됩니다. 제가 구직할 때도 "팀 프로젝트 해봤냐", "협업경험은 있냐"가 단골 질문 1순위 였네요. 인턴 경험이 있는게 아니면 일개 학생이 어떻게 해보겠습니까, 회사를 가도 개발회사가 아니라면 거의 혼자 개발하게 됩니다.

저에겐 책으로 배운 협업이 전부였고 그 흔한 스터디같은 것도 해본 경험이 없었습니다. 이걸 어디가서 얘기하는 건 "책으로 연애를 배웠습니다" 만큼 부끄럽게 느껴져서 어디가서 자신을 개발자라고 얘기하지 않았습니다. 이 때문에 게임회사 다니는 친구들에게 일 끝나고 프로젝트 해보자고 징징대는 버릇이 생겼습니다. 친구들아 미안해...;

그런 저에게 오픈소스 프로젝트에 PR을 보내고 리뷰받는 경험은 엄청 신선한 것이였고 "나도 할 수 있다"라는 자신감을 주는 일이였습니다.

지쳤을 때 보람찾기

"문제 해결"과 "가치 제공"이 제가 일에서 찾을 수 있는 본질적인 즐거움인데 둘 다 찾지 못하는 순간엔 일이 급격하게 재미없어집니다.

다행히 저는 제가 관심있게 살펴보던 Mattermost가 업무가 되면서 이런 순간들을 어느정도 회피할 수 있었습니다. 문제가 발생하면 스스로 기여해서 해결할 수도 있었고, 고객과 최대한 소통하면서 Mattermost의 가치를 이해시키고 요구와 최대한 통합하고자 노력하다보니 정말 가끔 땅속 깊이 묻혀 보일 기색이 없던 일의 보람이라는 걸 끄집어 낼 수 있었습니다.

그래도 일로 하다보니 지치고 정이 떨어질 것만 같았습니다. 그런데 심적으로 지쳐있던 시기에 Mattermost에서 이런 편지 한통이 날아옵니다.

Mattermost 컨트리뷰션 고맙다고 편지받았다. 너무 감동이잖아 ㅠㅠ pic.twitter.com/bv31QSXRGt
— Hyeseong Kim (@KrComet) April 23, 2018

솔직히 인생에서 손편지 처음 받아봤습니다. 이 편지는 큰 감동과 원동력을 주었고, 저는 덕분에 힘을내서 곧 이직했습니다. 응?

성장환경 보완하기

수많은 신입 개발자들의 공통 고민이 하나 있습니다. 이건 친구들과 얘기할 때나 국내 개발자 커뮤니티에 가면 항상 보이는 내용입니다.

"가르쳐줄 사수가 없어", "혼자 개발하고 있는데 잘하고 있는지 모르겠어", "뭐부터 해야할지 막막해" 등.. 성장의 갈피를 잡지 못할 때 하는 질문입니다.

저 또한 상황은 다를게 없었습니다. 신입개발자나 지망생들은 흔히들 이걸 "잘하는 사수/선배가 없어서"라고 퉁치는 오류를 범합니다. (이게 왜 오류냐면 개발회사가 뽑는 사람은 같이 개발을 할 동료이기 때문입니다) 저는 "나는 이런 핑계 대지 말고 혼자서라도 열심히 해야지" 하면서도 종종 같은 불만을 가졌습니다.

제가 개발자가 되어가는 과정에서 뭘 배웠는지, 뭘 배워야 하는 지 알 수가 없었습니다.

그렇게 모르는게 많던 시절에 Mattermost의 서버 구성을 보고 배우고, 설정 파일을 보일러플레이트처럼 배껴 써가다가 익숙해졌습니다. 곧 React 공부도 Mattermost 기여를 계기로 시작했고, Docker 사용도 좀 능숙해졌습니다. 고가용성, 모니터링, 스트레스 테스트, 개발 조직 구성, 지향해야할 문화 등등 생각해보면 하나같이 Mattermost로부터 배웠습니다.

그 전에 책으로 보고 배웠다고 생각했던 것과 레벨이 다른 직접적인 관찰과 체험을 통한 "진짜 경험"이였고 Mattermost의 엔지니어들과 커뮤니티의 멤버들은 제 든든한 사수이자 동료가 되어주었습니다. ~~심지어 꼰대도 없습니다. 완벽해~~

그리고 나중엔 급조한 제 초라한 이력서에 "오픈소스 활동" 이라는 다소 그럴싸한 이력이 남아있더군요.

저는 이제 "가르쳐줄 사수가 없어" 고민하는 사람들을 만나면 "오픈소스 커뮤니티 활동을 해봐"라고 조언합니다.

오픈소스 커뮤니티의 좋은 점

앞선 내용은 대부분 제 개인적인 환경과 경험을 적은 것이라, 이미 개발자로 경력을 만들어가고 계신 분들에겐 별로 와닿지 않는 내용들일 수도 있습니다.

이번엔 조금 더 보편적인, 오픈소스 개발의 매력을 소개해보겠습니다.

서로 존중하는 문화

제가 경험한 Mattermost의 커뮤니티는 언제나 서로를 존중하고 서로에게 친절했습니다. 이건 아마, 코어 팀 멤버들이 선행해서 그런 문화를 주도하고 있기 때문이 아닐까 싶습니다.

쉬운 이슈를 처리하고 있는 개발자라도 전문가이자 그 이슈의 담당자이고, 사용자의 사소한 불편함도 UX의 버그로 취급합니다.

너나 할 것 없이 적극적으로 의견을 나누고 협력해서 끝에가면 "Awesome work at this!"라고 해줍니다.

(이런 오픈소스 문화의 창시자격인 리누스 토발즈의 언행을 보면, 오픈소스라고 해서 이게 꼭 당연한 것은 아닌 것 같습니다만...)

함께 성장하는 문화

8월 중순에 CTO인 Corey와의 미팅이 있었는데, 서로 고마움을 전달하는 훈훈한 자리였습니다. 그가 제 커리어 발전을 축하해주며 이런 동반 성장이 오픈소스 커뮤니티의 놀라운 점(Awesomeness of open source community)라고 했던 것이 기억에 남아있습니다.

나중에 보니 아예 링크드인 이력에 너의 기여활동을 추가하라며 문서까지 파뒀더군요. (여담으로 일촌으로 추가하라고 얘기도 해줬는데 프로필을 보니 너무 구름위의 사람인것 같아 신청하지 못했습니다 ㅋㅋ 조만간 용기내서 눌러야겠군요)

확실히 커리어에 도움이 되는 것도 오픈소스의 순기능입니다. 조금 세속적인 것 같지만 제가 오픈소스 커뮤니티 활동을 통해 성장한 걸 생각해보면 부정할 수 없습니다. 설령 대단한 "오픈소스 정신"이 없이 진입한다고 해도 잘 운영되는 커뮤니티에는 아무런 해가 되지 않습니다. 그렇게 조직되었으니까요!

기업에서 산업으로의 환원과 채용 증진을 위해 컨퍼런스를 주최하고, 교육이나 인턴쉽을 하는 것과 맥락은 같지만, 오픈소소스 커뮤니티의 그것은 기업의 이익따위(?)에 묶이지 않고 더 넓게 기여를 환원하고 선순환을 만들어내는 것 같습니다.

그래서 저는 기업이 사내 리소스를 오픈소싱 하는 것을 매우 긍정적인 제스쳐라고 봅니다. "가고 싶은 회사"가 되는 지름길이죠.

개발에 집중할 수 있는 시스템

한 번은 PR 중 실수로 Close()를 호출하지 않아 고루틴 릭이 발생했던 적이 있습니다. 저도 놓치고 리뷰어도 놓쳤습니다, 곧 Pre-release 채널에 배포되고는 모니터링에서 걸렸습니다.

대형사고가 날 수도 있었지만 아무도 제 탓을 하지 않았습니다. 오히려 "자주 있는 일이야 ㅋㅋ" 정도로 위로 받고 끝났습니다.

왠만한 국내 개발회사에서 이런식으로 일하면 책임감 없다고 욕먹을지도 모르겠습니다. 저도 이런 문화에 적응하는 과정에서 햇갈려했었지만 곧 이게 이상적인 형태라고 깨닫게 됐습니다.

Mattermost의 개발 문화와 시스템이 처음부터 잘 되 있던건 아니였습니다. 초기엔 CI도 허접했고, 모니터링 수단도 갖춰져 있지 않았습니다. 하지만 이걸 개인의 책임으로 떠넘기지 않고 서로 협력해서 근본적인 원인을 찾고, 해결하고, 발전해가는 과정을 옆에서 지켜보고 가끔은 참여해보면서 많은 걸 느낄 수 있었습니다.

느끼고 배운 것을 정리해보면 아래와 같습니다.

책임은 역할에 따라 분배한다.
공통된 역할이라면 그것을 시스템화 한다.
시스템의 책임을 개인에게 미루지 않는다.
시스템의 유지보수는 모두의 역할이다.

(어찌보면 자주 얘기나오는 "문화로써의 DevOps"라는 것과도 일맥상통하지 않을까요)

하지만 안타깝게도 많은 국내 개발회사들이 도구로 해결할 수 있는 문제나 시스템이 가져가야 할 역할들을 개인에게 떠넘기며 본래 책임보다 더 큰 책임감을 요구하고 있는 것 같습니다. 되려 본래 신경써야할 코드의 퀄리티나 전문가로서의 신념을 포기하게 만들기도 하죠.

뭐 아직 경험이 많다고는 못해 짧은 주관에 불과할지 모릅니다만 어떤 개발 조직이던 이런 걸 궁극적으로 추구해야 하는게 아닌가 합니다. 그렇다면 아직 그럴싸한 커리어가 없는 제가 경험해볼 수 있는 최고의 문화를 경험해보고 있지 않나 하고 감사하게 생각합니다.

다시 시작한다면

요즘은 Mattermost가 아닌 다른 오픈소스 프로젝트에도 참여해볼까 하고 있습니다. 눈독들이고 있는 건 GatsbyJS나 Babel 등 입니다.

컨트리뷰션을 했던 일을 회상하다보니 "만약 Mattermost 기여를 처음부터 시작한다면 이렇게 해야지"하는 것들이 있는데, 혹시 다른 오픈소스 프로젝트에 참여하게 될 때도 지켜야 할 것들 입니다.

더 적극적으로 소통하기

초반엔 영어가 자신이 없다는 핑계로, 질문할 때 제외하고는 거의 소통하지 않았습니다. 그리고 말할 때마다 영어가 서툴다며 미안해했던 때도 있습니다.

나중에 가서 알게된건데, "영어가 서툰 것" 보다는 "소통을 하지 않는 것"이 더 무례한 것 이였습니다. 사실 당당하게 번역기체로 써서 올려놔도 찰떡같이 이해하고 모호한 부분이 있다면 정정 하면서, 이게 맞냐고 물어봐줍니다.

대화 예절을 생각하면 간단한데, 한국에서 얘기하는 권위자와 말할 때의 그런 예절이 아닙니다. 한 번에 이해 못했다고 사과할 필요가 없습니다.

영어가 서툴더라도 적극적으로 의견을 내고, 기능 제안을 주도하고, 이슈의 재현경로를 자세하게 리포트하고, 이슈를 꼼꼼히 챙긴다면 더 환영받을 것 입니다. 하다보니 이런 것들은 영어가 유창하지 않아도 금방 할 수 있는 것이였습니다.

내 활동을 드러내기

Mattermost가 자체적으로 Flow 타입을 도입하기 한참 전부터, 저는 Mattermost 관련 업무를 개선하고자 먼저 Mattermost API 클라이언트와 몇몇 코드들을 Flow로 타이핑 했고, 이걸 정리해서 NPM에 업로드했습니다.

하지만 이 걸 몇몇에게만 알리고 적극적으로 홍보하지는 않았습니다. 도저히 관심있어 할 것 같지 않아서 최소한의 내용들만 README에 적어두고 말았습니다.

"필요성"을 느껴 만든걸 "인기" 요소가 없어 알리지 않은건 치명적인 판단미스였습니다. Mattermost 팀에서 자체적인 판단으로 mattermost-redux 라이브러리에 Flow 타이핑이 도입되기 시작했을 때, Flow 도입을 제안하고 담당한 Jesus에게 뒤늦게 제 라이브러리에 대한 의견을 물었지만 존재를 모르고 있더군요. 제가 이미 대부분 타이핑 해두었던 것들을 다른 누군가가 중복으로 작업한 겁니다.

그리고 저는 제 라이브러리가 공식의 로드맵과 충돌된다고 판단해서 짧은 의논끝에 Deprecate를 결정했습니다. 제 첫 NPM 모듈이기도 해서 조금 씁슬한 경험이였습니다.

이를 통해 저는, 개발자가 자기 활동을 드러내는 것이 단순히 자기자랑이 아니라는 사실을 알게 되었습니다. 하물며 자기자랑 밖에 못되더라도 하는게 낫다는 사실도 함께 말입니다.

프로젝트 전체, 힘들다면 적어도 관심 이슈들은 Watch 하기

프로젝트에 참여하고 싶다면, 전체 이력이 아니더라도 최소한의 컨텍스트는 쫓아가야 합니다.

그러기 위해 GitHub에서 한 번 활발한 프로젝트를 Watch 해보면, 곧 엄청난 알림 메일을 받게 됩니다.

처음에는 별 생각없이 전체를 f-up 해야 한다는 생각에 Mattermost를 Watch 했다가(이 때는 서버와 웹앱이 하나의 저장소에 있었습니다) 쏟아지는 Inbox 압박에 3일을 못견디고 꺼버리고는 하루에 수천통씩 메일을 체크할 메인테이너들에 존경심을 가지게 된 기억이 있습니다.

지금은 저도 메일 처리량이 늘어나 두 개 프로젝트를 Watch 하고 있지만, 이상은 아직 힘들 것 같습니다. 대신 관심 있는 이슈와 관련 이슈를 각각 Subscribe 하는 방법을 사용하고 있습니다.

전문적인 이슈 트래킹 도구나 GitHub 알림 앱, 메일 클라이언트의 자동필터 기능 등을 통해 관리하는 것도 방법이 될 수 있습니다.

특히 하루가 멀다하고 릴리즈되고 신규 컨셉이 쏟아지는 프레임워크들은 이게 중요한데, 예를 들면 React에는 Umbrella 이슈라는 것이 있습니다. 중요하거나 영향도가 클법한 변경사항 관련해서 관련 대화나 레퍼런스를 모아두는 일종의 메타 이슈입니다. 저는 이런 종류의 이슈는 되도록 구독해두는 편입니다.

더 구체적으로 감사하기

요즘 크게 느끼는건데, 저는 PR 리뷰마다 항상 구체적인 감사를 당하고(?) 있었습니다.

"id라고 적혀있는 부분이 햇갈리지 않도록 index라고 고쳐준 부분은 인상 깊었어", "jQuery를 제거한 걸 보게되서 기뻐" 등등... 그리고 항상 "Awesome work at this @cometkim" 하면서 말이죠. 돌아보니 기분이 좋아졌습니다... 그런데 그에 비해 제가 평소에 남들에게 해주는 리뷰나 커멘트에는 별로 감사가 느껴지지 않았습니다.

엄연히 같이 한 것인데도 감사할 줄 모르는 것을 넘어서 성의 없음까지 보이더군요. 뼈저리게 반성하고 있습니다.

최대한 일일히 멘션달아서 리뷰어들에게 "Thank you"라고 이야기하는 것으로 시작하고 있는데, "구체적인 감사"는 생각보다 난이도가 높은 것 같습니다.

이 참에 연습하고, 영어공부도 해야겠습니다. 발전해서 일상에서도 좀 "다채롭게" 감사를 표현할 줄 아는 사람이 되고 싶습니다.

마무리하며

제가 겪은 어려움이나 성장에 대한 회고를 적어봤는데, 비슷한 어려움을 겪는 분들의 선택에 도움이 되리라는 또는 비슷한 분들과 소통하게되는 계기가 되리라는 소망을 가지고 있습니다.

그런 것 치고는 보편적인 얘기는 못적고 너무 구구절절 자기 얘기 뿐인 것은 아직 경험이나 글 실력이 미숙해서 인 것 같습니다. ~~아님 그냥 꼰대라서..?~~

또는 제가 어떤 사람인지 판단하는데도 도움이 되겠군요. 저는 속마음에 크게 거짓되는 글은 쓰지 않거든요.

어쨋든 정리해놓고 보니 뭔가 뚜렷해지는 느낌입니다. 연간 회고 말고도 종종 경험이 생기면 회고하는 글을 남겨둬야겠습니다.

Slack 대안 오픈소스 Mattermost를 소개합니다

Sat, 29 Sep 2018 00:00:00 GMT

들어가며

2018년 Hacktoberfest가 찾아왔습니다. 저는 작년과 마찬가지로 올해도 Mattermost에 기여하게 될 것 같네요.

문득 생각난 것이지만, 국내 개발 커뮤니티에 Mattermost를 소개하고, 스프린트 세션을 만들어 관심있는 분들과 함께하면 좋을 것 같습니다.

하지만 Mattermost가 그만큼 인지도가 있는 프로젝트는 아니지요. 그래서 슬랙의 대안 솔루션으로써의 Mattermost와 오픈소스 프로젝트로써의 Mattermost를 소개해보고자 합니다.

그리고 곁가지로 제가 Mattermost 오픈소스 커뮤니티를 통해 어떻게, 얼마나 성장할 수 있었는지에 대한 이야기도 해보겠습니다. 글 주제가 달라질 것 같아 포스트를 분리했습니다.

Mattermost가 뭔가요?

Mattermost는 Open Source, Private Cloud Slack Alternative로 소개되고 있습니다. 이해하기 쉽게 풀자면 "오픈소스 설치형 슬랙" 정도이고, Mattermost, Inc 회사가 운영하고 있습니다.

많은 오픈소스 솔루션 회사들이 그렇듯, Team Edition / Enterprise Edition으로 나뉘어 있고, 회사의 수익은 대부분 Enterprise Edition에서 옵니다. 주로 Slack 같은 SaaS를 사용하지 못하는 On-premise 환경이 비즈니스 타겟이죠.

그래서인지 당당하게 "Slack Alternative"를 표방하고 있으며, Why we made Mattermost an open source Slack-alternative라는 글에서 그 이유가 되는 커뮤니케이션 도구 선택의 실패를 겪었던 경험과 직접 만들고 오픈소스로 공개한 과정에 대한 얘기를 하고 있습니다.

In 2014, Slack became popular in Silicon Valley, and our company adopted it for messaging. But we had a problem–our archives were in our old messaging app. After our subscription expired, the old app wanted us to pay them to access our own data (and export still didn’t work!). We hated being locked in. We fumed. Our discussions, our research, our analyses, and gigabytes of our carefully tagged in-game artwork was all held for ransom by the service we had trusted. Slack was good, but it was another proprietary SaaS app, and we’d just been burned.

팀이 메시지 기반 커뮤니케이션에 완전히 적응했을 무렵 슬랙이 등장했고, 그에 맞춰 모든 커뮤니케이션 이력을 이전하고 싶었지만 기존 서비스가 그 데이터를 독점하고, 추가 비용을 요구했다는 이야기입니다.

팀 커뮤니케이션에서 도구에서는 (이메일이던 메신저던) 대화이력 뿐만 아니라 팀 내에서 오가는 수많은 문서와 자료들도 포함됩니다. 이런 자료들이 특정 SaaS 서비스에 의존하거나 독점되면 안된다고 생각했고, 슬랙도 상황은 크게 다르지 않아 직접 만들게 되었다고 하네요. (일단 슬랙은 데이터 내보내기에 비용을 요구하진 않습니다)

이런 역사로부터, 팀 커뮤니케이션의 중요성을 강조하기 위해, Slack과 의미가 완전 대조되도록 Mattermost라고 이름을 붙였다고 들었습니다. (뭐, 이유는 알겠는데 솔직히 제품명으로 그리 와닿진 않습니다)

기능 소개, 슬랙과의 차별 요소

위 스크린샷은 현재(글 쓰는 시점에서 v5.3.0) 공개 컨트리뷰터 채널입니다. 테마는 제가 좀 커스터마이징 했습니다.

대놓고 벤치마킹을 해서 시작했기에, 외관이나 기능, 전체적인 UX는 슬랙과 거의 유사합니다. 이게 장점이죠 사실, 슬랙이 너무 잘나가니...

자세한 기능 목록은 홈페이지에서 확인할 수 있습니다. 핵심은 SaaS가 아닌 Self-hosted(직접 구축해서 사용하는) 형태라는 점입니다.

그 이외 몇 가지 대표적인 차별점들을 제 취향대로 꼽아보겠습니다.

마크다운 지원

마크다운의 유사 스펙만을 조금 지원하는 Slack, Discord 같은 메신저들과 다르게, Mattermost는 마크다운(GFM과 CommonMark 스펙 호환)을 풀 스펙으로 지원합니다.

따라서 그냥 메시지로도 쓸 수 있지만, 조금 더 풍부한 Conversation이 가능하다는 것이 장점입니다. 마치 GitHub의 그 것 처럼요. 개발자들이 특히 좋아할만한 기능입니다.

심지어 채널 헤더에도 마크다운을 쓸 수 있어서, 이런 짓도 가능합니다.

태그 검색 지원

본문에 마크다운 이외의 해시태그(#)나 채널태그(~)를 사용할 수 있습니다.

슬랙의 경우 채널을 특정 토픽 단위의 공간으로 정의하고, 해시태그는 그 채널을 가르키는 인디케이터의 역할만 합니다. 제약사항으로 받아들일 수도 있고 개념의 진입장벽도 높습니다.

Mattermost는 SNS에서 흔히 사용되는 형태로, 샵문자로 시작하는 단어가 자동으로 해시태그로 지정되며 검색 단위로 활용할 수 있습니다.

이런 풍부한 컨텍스트가 Integration 만들 때 Markdown 지원과 합해져서 빛을 봅니다. 예를 들면 이슈트래커 도구와의 Integration을 이런식으로 만들 수도 있습니다.

스레드 지원

슬랙도 메시지의 스레드를 지원하기 시작하면서 크게 의미가 없어졌을 수도 있겠습니다만, 사실 Slack의 스레드 기능은 Mattermost를 역으로 벤치마킹해서 도입된 기능입니다.

슬랙에 스레드가 없던 시절, 메시지 스레드는 Mattermost의 핵심적인 차별요소였습니다.

지금 굳이 비교하자면 Slack처럼 스레드를 기본적으로 숨기지 않고, 그대로 노출시켜서 조금 더 자연스럽게 스레드 기반의 대화를 유도하는 UX를 가지고 있습니다.

다국어 지원

슬랙과 다르게 Mattermost는 채널명을 한국어로 하는데 제약이 없습니다. 위에서 말한 해시태그도 역시 한국어를 지원합니다. (제 첫 기여이기도 합니다!!)

또한 인터페이스의 다국어 지원을 시작한지 얼마 안된 슬랙과 다르게, Mattermost는 오랫동안 오픈소스 커뮤니티로부터 번역을 기여받았고, 한국어 번역 역시 지원합니다.

한국어 번역은 일단 제가 Maintainer로 있습니다만, 오랫동안 관리하지 못해 현재 Alpha 단계인 상태라 많은 기여자들의 참여가 필요한 상황입니다.

슬랙과의 호환성

슬랙의 대안을 표방하는 만큼, UX가 비슷할 뿐만 아니라 슬랙의 핵심적인 기능으로 각광받는 Integration도 거의 똑같습니다. 겉만 비슷한게 아니라 실제로 인터페이스(Incoming/Outgoing Webhook의 Payload)가 대부분 호환됩니다.

때문에 슬랙용으로 만든 Webhook 방식의 Integration의 Incomming Webhook 주소를 Mattermost 것으로만 바꾸면 그대로 동작하는 경우가 종종 있습니다. 실제로 예전에 GitLab을 사용할 때 Mattermost 연동이 없어서 슬랙용을 대신 설정해서 쓴 적 있습니다. (지금은 Mattermost 전용 설정이 있습니다)

또한 주 비즈니스 대상이 슬랙을 수용하지 못하는 On-premise 환경뿐 아니라, "슬랙을 비용 문제로 무료버전을 쓰고 있는데, 서버를 직접 운용할 여력은 있는" 사용자들도 포함되기에, 이를 위해 슬랙에서 Export한 모든 데이터를 이전할 수 있는 Slack Migration 기능을 제공합니다. (최근엔 HipChat 데이터 마이그레이션도 준비하더군요) 팀 생성 단계에서 마이그레이션 데이터를 사용하면 슬랙에 있었던 모든 채널들과 사용자, 첨부파일 등이 이전된 상태로 팀을 초기화할 수 있습니다.

클라이언트 지원

일단 공식적으로는 웹, 데스크탑, 모바일 클라이언트를 지원합니다.

mattermost-webapp: React, Redux 기반 웹 클라이언트
mattermost-desktop: Electron 기반 웹 클라이언트의 래퍼
mattermost-mobile: React Native 기반의 Android, iOS 네이티브 앱

API를 공개하고 있기 때문에, 커뮤니티에서 다양한 서드파티 클라이언트를 만들기도 합니다.

서드파티 모바일 클라이언트(저도 하나 만들까 생각중입니다)나 터미널 클라이언트, IRC 브릿지 등등...

비슷한 프로젝트와의 비교 (Rocket.Chat)

비슷한 프로젝트 중에서도 Star 수를 압도하는 Rocket.Chat 이라는 프로젝트도 있습니다.

Mattermost: 13K Stars
Rocket.Chat: 20K Stars
Zulip: 8K Stars

Rocket.Chat과 비교했을 때 선택한 이유는 이렇습니다.

적어도 표면적인 부분에선, 커뮤니티 관리가 더 잘 되고 있습니다. Mattermost의 커뮤니티 관리는 정말 훌륭합니다.
두 프로젝트가 8K 쯤에서 서로 업치락 뒤치락 할 때쯤 솔루션 검토를 했었는데, 그 당시 Rocket.Chat은 정말 느리고 버그 투성이인 못쓸 물건이였어요.
개인적으로 기술 스택이 Mattermost 쪽이 더 관심사와 맞습니다. 프로젝트 구성도 깔끔하고요.
- Mattermost: Golang 베이스의 서버와 React 베이스의 클라이언트
- Rocket.Chat: Meteor.js 베이스의 서버/클라이언트

지금은 Rocket.Chat도 많이 성장했으니 퀄리티를 비교하면 어느쪽이 나을지는 잘 모르겠습니다.

오픈소스 커뮤니티로써의 Mattermost

제가 Mattermost를 좋아하는 이유는 소프트웨어의 퀄리티보단 Community-driven 문화, 잘 조직되고 관리되는 커뮤니티입니다.

Mattermost의 CEO, CTO는 제게 "We are community over company" 라는 표현으로 Mattermost를 소개했습니다.

홈페이지에는 주력 비즈니스인 엔터프라이즈 에디션에 대한 내용이 가득해서 가려질 수 있지만, Mattermost는 제가 봐왔던 다른 거대한 오픈소스 커뮤니티들과 비교해도 손색이 없는 훌륭한 커뮤니티를 가지고 있고, CEO, CTO, Designer, Core-developer.. 멤버 모두가 그 것에 자부심을 가지고 있습니다.

단순히 솔루션 회사가 사용자 그룹을 지원하는 레벨이 아니라 서버의 엔터프라이즈 에디션 기능을 제외한 대부분의 소스코드가 (대부분 Apache 2.0 라이센스 하에)오픈되어 있고 사용하는 공식 커뮤니케이션 채널, 이슈트래커, 로드맵이나 심지어 정기 개발자 미팅까지 공개된 상태로 진행하고 커뮤니티 멤버의 참여를 독려합니다.

커뮤니티 구성요소

Mattermost Organization in GitHub

투명한 것도 좋지만 이것만으로는 좋은 커뮤니티라고고 할 수 없습니다.

Mattermost는 개발자나 사용자 지원을 살펴보면 꽤 잘 갖춰져있다는 걸 알 수 있습니다.

공식 문서
공식 이슈트래커 (GitHub)
공식 이슈트래커 (Jira)
CONTRIBUTING: 워크플로우를 굉장히 자세히 설명해주고 있음
공식 개발자 가이드
공식 채널: Mattermost의 공식 업무 채널이자, 컨트리뷰터 채널이자, 릴리즈 미리보기(master)
공식 사용자 포럼: Discourse를 사용한 사용자 커뮤니티
공식 기능제안 포럼
공식 번역 사이트: Pootle을 사용한 번역 사이트
공식 API 레퍼런스: OpenAPI Spectification (Swagger)
공식 유튜브 채널

공식으로 제공되는 문서, 도구나 채널들만해도 여기 정리한 것보다 많을겁니다. 너무 분산되어 있어 보이기도 하지만, 공식 채널로 운영되는 Mattermost가 이 수많은 채널들을 통합해주는 허브 역할을 충실히 수행하고 있기 때문에 생각보다 햇갈리는 일이 없습니다.

이 점에서 Mattermost에서 핵심 가치로 내세우는 All your team communication in one place, searchable and accessible anywhere.이 드러나는 것 같습니다.

Community-driven 문화

Mattermost Core 팀에는 많은 PM, 디자이너, 개발자, 세일즈 등 여러 역할들이 존재합니다. 멤버들은 서로 다른 역할들을 가지지만 "커뮤니티 지원"이라는 한 가지만은 모두가 공유합니다. (이들의 Handbook 역시 온라인으로 공개되어 있습니다. 개발 조직 운영에 좋은 참고자료이지요)

잘 관리되는 커뮤니티 덕분에, 컨트리뷰션 경험은 아주 만족스러웠습니다. (이후 다른 프로젝트들을 경험해보니 오픈소스라고 해서 꼭 잘 관리되는 게 아니더라고요!)

기본적으로는 PM 리뷰 -> 개발자 리뷰 -> QA 순으로 진행되고 필요하다면 디자이너 리뷰를 추가적으로 요청할 수도 있고, 공식 채널을 통해 온라인인 멤버들과 실시간으로 의견을 나눌 수도 있습니다.

무엇보다, 항상 친절합니다! 2년동안 (전 회사에서의 세일즈를 포함한)기여 활동 중에서 어색한 영어도 문제가 되는 일은 전혀 없었습니다 :)

컨트리뷰션 시작하기

Slack과 거의 유사한 서비스를 만드는 프로젝트에 참여한다는 건 그리 쉽게 접할 수 있는 경험은 아닐겁니다. 오픈소스가 아니라면 말이죠.

Mattermost의 프로젝트들과 기여할 수 있는 영역은 아주 다양하게 세분화되어 있어서 관심사에 따라 골라먹는 재미가 있습니다.

시작하고 나서 가장 먼저할 일은 CLA(Contribution License Agreement)를 제출하는 것입니다. 그 다음 이슈트래커에서 Help Wanted 이슈를 찾아보면 기술별, 난이도별, 상태별로 라벨링이 매우 잘 되있는 걸 볼 수 있습니다.

Up For Graps는 아직 Assign된 사람이 없는 이슈를 의미하고, Difficulty: Introductory는 수정이 단순하고 쉬운(것으로 예상되는) 이슈를 의미합니다. 이 두 라벨로 필터링하면 입문자도 힘들이지 않고 첫기여를 할 수 있습니다.

플랫폼

플랫폼은 프로젝트의 중추이기도 한 mattermost-server 프로젝트를 지칭합니다. (예전엔 저장소 이름이 platform이였습니다)

Go 언어로 100% 작성되어 있고, DB는 MySQL 또는 PostgreSQL을 사용합니다. Go 언어로 웹 서비스를 만드는 것 또는 API 디자인, 메인 비즈니스 로직을 다루는데 관심이 있다면 참여해볼만 합니다.

구성 편의성을 고려해 꽤나 간단한 구성으로 되어있지만, 엔터프라이즈 구성이 고려된 복잡한 부분까지 엿볼 수도 있습니다.

설치/배포

설치형 솔루션이기 때문에 어떻게 배포하고 운영할 것이냐가 상당히 중요한 이슈입니다.

이를 위한 도커 이미지나 k8s 클러스터 설정, 또는 클라우드 VPS의 이미지를 기여하는 것도 커뮤니티에 큰 도움이 될 수 있습니다.

참고:

Deployment Solution Program

웹 클라이언트

Mattermost의 UX 레퍼런스라고도 할 수 있는 웹 클라이언트입니다. React로 큰 규모의 웹 클라이언트를 만드는 데 관심이 있다면 기여해보기 좋습니다.

버전3 초반까지는 Flux 스토어를 사용하다가 Redux 스토어로 마이그레이션이 진행되었습니다. 아직 스토어 마이그레이션이 100% 완료되지 않아 Help Wanted가 다수 열려있는 상태이고 저도 최근엔 이쪽을 열심히 기여하고 있습니다.

컴포넌트 리팩토링 절차는 가이드라인이 매우 상세히 나와 있기 때문에, 너무 단순하지 않으면서도 막막하지 않습니다.

참고:

모바일 클라이언트

React Native로 개발되는 모바일용 네이티브 앱입니다.

참고로 이전엔 그냥 웹앱을 웹뷰로 보여주는 안드로이드 앱과 iOS 앱이 각각 있었는데, Uber에서 RN 모바일앱의 초기 버전을 만들어서 기여했다는 이야기가 전해집니다. (Uber는 자체적으로 Mattermost를 커스터마이징해서 uChat이라는 이름으로 사용하고 있습니다.)

클라이언트 라이브러리

독특하게도 API 클라이언트, Redux 스토어와 리듀서, 셀렉터 등이 mattermost-redux라는 라이브러리 저장소로 분리되어 관리되고 있습니다. 그리고 이 라이브러리를 웹앱과 모바일앱에서 공유해서 사용하고 서드파티에서도 사용할 수 있게 NPM 라이브러리 모듈로 제공되고 있습니다.

여기에 최근 Flow를 사용한 타이핑이 적용되기 시작해서 타이핑 기여도 필요한 상황입니다.

문서

문서 기여도 아주 중요합니다. Mattermost는 공식 문서를 제외하고도 개발자 가이드, API 레퍼런스 등 다양한 문서들을 역시 공개 저장소로 운영하고 있습니다.

오탈자를 찾거나 내용을 고치는 일부터 시작해서 유용한 정보를 채워넣어 커뮤니티 발전에 크게 기여할 수 있습니다.

번역

Mattermost 공식 번역 서버에서 i18n 진행 현황을 보고 참여할 수 있습니다.

한국어 번역의 도움이 절실합니다. 관심이 있으신 분은 공식 i18n - Korean / ko 채널에서 저를 찾아주세욧 ㅠㅠ

Integration

Slack의 그것과 마찬가지로 Mattermost에서도 Webhook이나 WebSocket API를 통해 챗봇을 만들거나 시스템 통합을합니다.

Jira의 업데이트 알림을 받거나, 프로젝트 GitHub 저장소에서 알림을 받거나, Jenkins나 Fastlane의 빌드/배포 이벤트에 대한 알림을 받기도 하고, 투표 봇을 만들어 투표를 진행하기도 합니다.

무궁무진하게 아이디어를 펼칠 수 있는 영역입니다.

참고:

Integration 디렉토리

플러그인

API를 기반으로 한 통합의 가능성은 언제나 열려있지만, 가끔은 아쉬울 때도 있습니다.

Mattermost는 꾸준히 더 많은 사용 시나리오를 만들 수 있는 개발자 SDK와, Mattermost의 API나 UI를 직접 확장할 수 있는 방법을 만들려는 시도를 해왔습니다. Mattermost v5에서 선보인 플러그인 시스템은 그 것의 일환인데, 가상 해커톤에 참여해서 잠깐 만져보니 상당히 쓸만했습니다.

서버 플러그인을 통해, 추가적인 서버 구성 없이 Mattermost 서버에 플러그인을 설치하는 것으로 미리 빌드된 Integration을 사용할 수 있습니다.
Mattermost의 기존 API 이외의 추가적인 API를 구성할 수 있습니다.
제가 해커톤에서 시도했던 것은 Mattermost 서버에 GraphQL API를 추가하는 것 이였습니다.
웹 앱 플러그인을 추가해, 버튼을 추가하거나 스타일을 다듬는 식으로 Mattermost UI를 확장할 수 있습니다.

참고:

Mattermost 확장(플러그인) 가이드

기타 서드파티

웹 앱/모바일 앱이 맘에 안들면 새로운 앱을 만들어 사용할 수도 있습니다. 자신이 쓰는 프로그래밍 언어로 API 클라이언트를 만들 수도 있습니다.

무슨 프로젝트할까 딱히 고민하는 대신 아이디어가 넘쳐 뭐부터 할까 고민하게 되고, 이건 빠져들 수록 즐거운 일인 것 같습니다. ~~고인물 되기~~

기여 보상 받기

첫 PR이 머지되거나 Integration을 만들고 공유하면 Mattermost 팀에서 소소한 선물을 보내줍니다.

열심히 기여하다가 릴리즈 MVP에 선정되면 이렇게 추가적인 선물을 보내주기도 합니다. (의미불명인 디자인입니다 ㅋㅋ)

사실 이런 선물수집을 취미로 들이는 것도 좋은 동기부여가 되지만, 더 중요한건 커뮤니티 활동을 통한 성장입니다. 제가 커뮤니티 기여를 어떻게 보상받았는지에 대해 다른 포스트에서 조금 더 구체적으로 얘기해보겠습니다.

그리고 기여활동은 개발자로서 자신을 드러내는데 도움을 주기도 합니다. Mattermost에서는 그걸 아주 적극적으로 권장합니다. 링크드인에 이력으로 추가하라고 친절하게 문서화까지 해둘 정도로 말입니다.

함께 할 컨트리뷰터를 찾습니다

이렇게 오픈소스 커뮤니티 활동을 할 때 한 가지 아쉬운 점이 있다면 바로 커뮤니티에 같은 한국인 개발자가 없다는 점입니다.

다른 개발자들과는 타임존이 크게 차이나다보니 거의 대부분 비동기로 대화하게 되고, 실시간으로 대화할 기회가 많지는 않았습니다. 언어의 장벽 때문에 의견을 주고 받는데 적극성이 떨어지는 것도 사실입니다.

전 회사의 비즈니스 채널로 모 회사에서 쓴다더라 하는 얘기를 종종 들어 기대하고는 했었는데, 아쉽게도 로컬 멤버의 커뮤니티 진입은 없었습니다.

그래서 항상 생각만 미뤄왔던 Mattermost 소개 포스트를 작성하게 됐습니다. 이렇게 정리해두는게 진입에 조금이나마 도움이 되면 좋겠습니다.

이런 분들께 적극 추천합니다

슬랙 대안을 찾고 계시는 분
회사에서 Mattermost를 사용/운영 하고 계신 분
커다란 오픈소스 프로젝트에 참여해보고 싶으신 분
오픈소스 기여 보상(티셔츠, 머그컵 등) 모으는 게 취미이신 분
회사에 사수가 없거나 분위기가 안좋아 개인 성장이 걱정되시는 분

모두 제가 가지고 있던 계기들입니다. 같은 생각을 가지신 분이라면 한 번쯤 관심가져 볼만한 프로젝트라 추천드립니다.

2018년 Hacktoberfest 함께하실 분

Hacktoberfest는 GitHub와 DisitalOcean에서 매년 주최하는 오픈소스 행사입니다. 10월 한달 간 GitHub 오픈소스 프로젝트에 4 PR이 머지되면 멋진 티셔츠와 스티커를 줍니다.

(요새 입고 출근했는데, 막상 10월에는 추워서 못입고 다닐 것 같네요 ㅋㅋ)

글 시작에서 언급한 것 처럼, 저는 이번 Hacktoberfest도 Mattermost 기여로 도전할 생각입니다.

그리고 이번엔 혼자가 아니라 같이할 사람이 있으면 좋겠다는 생각을 하고 있습니다. 혹시 많이 모이면 스프린트 형식으로 모임을 해도 괜찮겠네요. 혹시 Mattermost에 관심이 있는 분이나, 이번 Hacktoberfest에 도전하고 싶지만 주제가 마땅히 떠오르지 않으시는 분은 부담없이 제게 연락해주시면 감사하겠습니다.

이메일: cometkim.kr@gmail.com
트위터: @KrComet
Mattermost 멘션: @cometkim

그럼 모두 Happy Hacking!

조직에서 GitHub Developer Plan을 사용하는 것은 안티패턴이다.

Wed, 19 Sep 2018 00:00:00 GMT

TR;DL - 돈 아깝다고 GitHub 한 계정 돌려쓰기 하지 마세요.

이 글은 내가 속한 회사/앞으로 속하게 될 회사에 불평불만/제안 하는 것을 목적으로 두고있다.

돈 아끼기?

예전에 GitHub Enterprise 솔루션 지원하던 때, GitHub 사용자 계정을 프로젝트 그룹처럼 활용하는 경우를 종종 본 적이 있었다.

안타깝게도 현재 회사에서 사용하는 방식이기도하다.

GitHub Account @user가 있다.
@user 계정은 Developer Plan을 구독하고 있다.
@user 계정으로 Private Repository를 생성해서 내부 프로젝트를 관리한다.
프로젝트에 Involve 된 직원의 계정을 Collarborator로 등록한다.
프로젝트 관리는 한명의 매니저가 담당하고 있다.

GitHub 가격정책을 보면 Annual로 유저당 9달러(5명까지는 5달러)를 내는 Team Plan에 비해서 Developer Plan이 압도적으로 싸다. Team Plan을 선택하면 회사에 개발자가 20명만 되도 1년이면 1,920달러가 나간다.

그런데 기능표로 보기엔 별 차이가 없어보이니 적절한 선택으로 보인다. 이정도면 훌륭한 원가절감 아닌가?

Organization 기능 들여다보기

하지만 사실 GitHub을 자주 사용할 수록, 기능을 알게 될 수록 의문점이 생긴다.

Developer / Team Plan은 표에 나온 것 만큼 기능 차이가 별로 없을까? 기능 차이가 없다면 가격은 왜 이렇게 차이날까? 표에서는 Team permissions, Organization permissions 딱 두 항목만이 차이날 뿐이다.

한 번이라도 Organization에 속한적이 있다면 알게된다. 혼자 하는 프로젝트를 제외한 GitHub의 모든 Use Case가 Organization에 녹아 있다는 것을. 어떤 서비스던지 제시된 Use Case를 역행하면 불편해지지 않을 수가 없다.

Team, Team, Team!

레파지토리 목록만 본다면, 사용자 계정과 무슨 차이가 있나 싶다.

사실 별 것 없어보이는 Organization의 핵심은 Teams 탭에 있다. Team은 Organization 멤버의 그룹이다.

팀 단위 협업

일단 처음 Team을 생성해보면 이렇게 팀원들끼리 협업할 수 있는 공간이 생긴다.

GitHub 가이드에서 가져온 이 오래된 스크린샷과는 다르게, Projects Board 기능 또한 팀 단위로 사용할 수 있다.

조직의 Jira, Conflence, Trello 등 협업/이슈트래커 도구의 활용도가 낮다면, 완전히 대체, 통합해버릴 수도 있는 훌륭한 기능이다.

팀 별 권한 관리

개인 레파지토리 경우 사용자를 추가하고 싶다면 Collaborators로 추가할 수 있고, Collaborator는 master 브랜치에 Push/Merge 하는 권한만 공유받게 된다.

즉, 여전히 실질적으로 프로젝트를 "관리"할 수 있는 건 @user 계정으로 접속하는 매니져 한 사람 뿐이다.

반면, Organization의 레파지토리는 팀 단위로 사용자에게 "관리" 권한을 포함한 세부적인 권한을 부여할 수 있다.

이건 장단점의 영역이라기보단 필수요소라 볼 수 있겠다.

그룹단위로 관리할 수 있다는 건 매니저에게 없어서 안될 기능이다.
권한의 세부적으로 컨트롤 또한 기업의 소스 컨트롤이라면 필수이다.

특히 신규 멤버가 추가되거나, 퇴사자가 발생하는 경우 더욱 빛을 발한다.

API 접근 제어

GitHub는 다양한 도구들과 통합(Integration)되었을 때 그 전체를 활용할 수 있는 도구라는 점에서 API의 접근 제어가 세분화되는 것도 중요한 요소로 볼 수 있다.

@user 계정을 사용하고자 한다면 매니져가 OAuth Authorize 하는 과정을 전부 직접 수행해야 한다.

특정 프로젝트에 특화된 도구를 연동하는데, 그 프로젝트의 수행자는 레파지토리의 "Settings" 메뉴에 접근조차 할 수 없고, 결국은 매니저가 사용되는 모든 도구를 숙달하고 있어야 한다는 의미이다.

CI/CD(Continuous Integration/Deployment)라면 Access Key의 적절한 관리가 프로젝트 라이프사이클에 직접적인 영향을 주기때문에 더더욱 중요해진다.

이 모든 걸 프로젝트 수행자가 적절한 권한을 부여받지 못해 손가락 빨며 기다려야 하는가? 그리고 매니저는 이걸 다 직접 일일히 관리하고 있을 시간이 있는가?

조직 구성 관리

GitHub로 조직의 Hierarchy를 관리할 수 있다는 건 더 많은 가능성을 파생시킨다.

소규모 조직 중에 LDAP/SAML로 SSO 구축해서 쓰는 곳이 얼마나 있을까? (있다면 벌써 Enterprise Plan을 고려하고 있었겠지..) 그렇기에 작은 조직일 수록 사용자의 계정을 주먹구구식으로 관리하는 경향이 크다.

이런 상황에서 어느 한 군데라도 LDAP 비스무리하게 조직 구성 관리가 수행되고 있다는 것은 개발용 서비스/도구에서의 Access Controll에 활용될 가능성을 내포하고 있다. (인하우스 도구 만들 때 이 구성관리의 유무가 엄청난 차이를 만든다.)

그리고 GitHub API는 OAuth 2.0 Service Provider를 지원하고 있기도 하다. 개발도구로 제한한다면 Google 계정이 통합되는 서비스만큼이나 통합되는 서비스의 범위가 넓고, 이 중에서 실제로 Organization 정보를 활용하는 협업도구도 종종 볼 수 있다.

알림 제어

협업 도구가 가장 중요하게 다루는 기능이 바로 "알림(Notification)"이다. 잘 제어되는 알림은 비동기 협업의 가장 핵심적인 부분이라고 할 수 있다.

이 부분 역시 계정을 돌려쓰다보면 Organization의 부재로 많은 것을 잃어버리게 된다.

그룹 멘션

알림기능에서 대상을 구분하는 용도로 멘션 기능을 활용하게 된다. @user1, @user2 라는 식으로 본문 내용에 포함하면 이 내용은 @user1, @user2 에게 더 높은 중요도를 가지게 된다.

Organization, Team이 있다면 이 단위로 멘션이 가능하다. 멘션을 "역할" 단위로 구분할 수 있는 것이다.

멘션은 서비스 통합 시에도 자주 활용되는데, Organization, Team 단위는 컨텍스트로 다루기도 좋다.

알림 커스텀 라우팅

이 기능 못써서 심각하게 불편해하고 있다.

나는 GitHub에서 회사 프로젝트 뿐 아니라 오픈소스 프로젝트의 이슈들도 다수 Watch하고 있어서 GitHub에서 오는 알림 메일이 개인 Inbox의 대다수를 차지한다.

물론 회사용 메일은 따로 있지만 GitHub 계정의 Primary Email은 개인 메일이라 분리가 안된다.

GitHub는 이러한 상황을 위해 Personal Setttings > Notifications > Custom Routing 메뉴에서 "특정 Organazation에서 오는 알림을 다른 메일 주소로 보내는 기능"을 제공하는데, 이걸 못쓰니 회사 프로젝트의 GitHub 알림은 거의 놓치고 있다. (애초에 회사에서 메일 클라이언트 따로 쓰고 있지도 않아서, 스마트폰으로 확인한다 -_-)

이 것 때문에 "회사용 GitHub 계정"을 따로 파는 분도 있는 것 같다..;

그래서..

혼자 하는 프로젝트가 아닌 이상, Organization 하나로 GitHub의 활용도 차이가 크다. 사실, "협업"을 주제로 하는 모든 서비스가 다 그렇다.

가격 때문에 Developer Plan을 선택하고, 여기서 발생하는 제약사항 때문에

매니저가 무수히 많은 책임/역할에 묶이고,
막상 프로젝트의 수행자는 적절한 권한을 못 받고,
기능제약으로 생긴 불편함에 대한 책임을 개인에게 전가하고,
정돈된 리소스로부터 파생될 다양한 통합가능성을 배제하는,

이러한 행태들이 내가 보기엔 그리 적절하지 못한 것 같다.

얘기 꺼내보기 전에는 다른 팀원들이 어떻게 생각하고 있을지는 모르겠다. 만약, 불편함이 존재하는 것을 인지하지 못하는 상태라면 개인적으로 설득할 자신도 없고, 정말 안타까워할 것 같다.

가격 합리성 따지기

기능 제약이 많다는걸 이해한 후에도 가격이 너무 부담된다면,

직접 구축해서 사용할 수 있는 오픈소스 서비스로 GitLab CE, Gogs, Yona 등 다양한 옵션이 있다. (사실 GitLab이 순기능만 따지면 훨씬 낫..)

하지만 전 회사에서 GitLab CE를 직접 구축해서 써본 경험으로는 이게 좋은 대안이라고 내세우고 싶지 않다. 구축/운영비용이 만만치 않고, 조직 내 의존도가 아주 높은 서비스임에도 불구하고 구축/운영비용이 눈에 잘 보이지 않아 무시되었던 경험이 있기 때문이다.

구매에 실패하지 않는 법으로 "가장 많은 시간을 들이는 것에 많은 돈을 써라" 라는 내용을 트위터에서 본적이 있다. (원문을 아시는 분은 댓글 좀 부탁드리겠습니다.)

GitHub는 현재 내 개인/회사 통틀어서 단언컨데 거의 대부분의 시간을 함께하는 서비스이다. 깃헙에 들이는 시간, 기능 제약으로 인한 생산성 저하, 여기서 나오는 시간을 임금으로 환산할 수 있다면 개발자당 월 9달러가 그렇게 큰 비용일까? (정확한 값은 어떻게 측정될 지 모르겠으나, 예/아니요 논리를 따지는 건 개발자 임금 수준을 생각하면 상당히 예측하기 쉬운 문제로 보인다.)

만약 Youtube 보는게 일이였다면 ~~좋겠다~~ 계산이 쉬워졌겠다. 유튜브 광고보고 있는데 들인 시간(한시간에 5분이라 치자)이랑 하루 노동시간 따졌을 때, (최저임금 8,350원 x 5분/1시간 x 한달 근로시간 209시간) = 145,429원 나오는데 여기에 러프하게 반토막해놓고 따져도 회사에서 Youtube Premium (한달 7,900원) 사주는게 손해겠냐는 얘기다.

그리고 나는 GitHub를 통해 소스 관리하고 협업하는게 YouTube 쳐다보고 있는 것보단 훨씬 고부가가치 작업이라고 믿는다.

결론

~~사주세요~~ 결국 제 값인 데는 다 이유가 있다.

라고 말하고 싶다. 특히 내가 속한/속하게 될 조직은 지속적인 생산성과 직결된 부분엔 되도록 돈을 아끼지 않았으면 좋겠다.

DB 분석서 쓰기 싫어요 - JETT로 분석서 뽑아내기

Mon, 03 Sep 2018 00:00:00 GMT

저번 한 주 동안 진행한 프로젝트의 소개 포스트임.

JETT라는 템플릿 엔진을 이용해서 DB 문서를 생성하는 것이 목표이다. Spring Boot 2, 언어는 Groovy를 메인으로 사용했다.

README 바로보기

동기

현재 회사에서는 MySQL RDBMS를 메인으로 사용한다. 내가 파악한 거의 모든 프로젝트들이 DB 테이블과 관계로 도메인을 표현하고 있다.

이렇게 도메인과 비즈니스가 DB상에서 표현되다 보니 DB 관련 문서도 굉장히 중요하게 다루어지는데, 보통 설계서를 작성하고 그걸 스펙 문서로 활용하지만, 옛날 프로젝트를 건드리거나 SI 프로젝트를 하다보면 역공학 분석서가 나오는 경우도 잦은 것 같다.

일단 전자던 후자던 나는 손으로하는 문서화를 정말 싫어하고, 그 중에서도 분석서는 정말 싫다. 특히 이 경우는 DB 테이블 정보를 특정 양식에 기계적으로 옮겨 적는 일이 되고는 한다.

이런 식의 일은

귀찮기도 더럽게 귀찮고,
꾸준한 업데이트가 필요하다. 하지만 테이블 마이그레이션 마다 문서를 업데이트 하는 건 빼먹기도 쉽다.

얼마전 회사 동료가 비슷한 일로 하루를 보내는 것을 보고, 난 절대 저런 일 절대 성실히 못할거라 생각했다.

혹시 모를 일을 대비해서 미리 자동화해두면 어떨까?

어떻게?

나는 첫 직장에서 다양한 솔루션의 기술 지원을 했다. 그 중에서도 기능이 더럽게 많은 ALM 솔루션은 아무도 모르는 숨겨진 기능을 가이드하기 위해 소프트웨어 자체를 역공학하는 경우가 더러 있었는데, 엑셀 템플릿 커스터마이징 기능이 그랬다.

온라인에서 작업한 스펙을 엑셀 스프레드시트로 내보내기 할 때, 내보내는 양식을 커스터마이징 할 수 있는 기능이였다.

B2B에서는 환영받을 기능이다만, 온갖 내부적인 모델코드를 처음보는 표현식으로 표현해야 하는데 어떤 고객님이 그걸 직접 하고 있을까... 그걸 대신 해주는 일이 많다보니 JEXL 기반의 표현식이 익숙해지고 JETT라는 엔진의 존재와 거기서 쓰이는 태그도 익숙해질 수 밖에 없었다.

쓸모없는 경험은 없다고 했던가, 그 때 그 친구들을 활용하면 자동화할 수 있겠거니 생각이 났다.

JETT? JEXL?

JEXL(Java EXpression Language)은 Apache Commons 소속 프로젝트 중 하나로, Java 애플리케이션에서 동적 스크립팅을 지원하기 위한 표현식을 만드는 라이브러리이다.

JSP에서 JSTL이나 Apache Velocity 같은 템플릿 엔진에 쓰이는 표현식과 비슷한 것을 지원한다.

그리고 JETT(Java Excel Template Translator)는 이러한 표현식을 엑셀 스프레드시트 파일 내에서 사용하게 해주는 특별한 템플릿 엔진이다.

스프링 부트

전부 Apache 라이브러리 기반, Java 기반이고 너무 오래된 고대의 기술들인 것이 맘에 안들어 비슷한 다른 것을 찾아보려고 했다.

스프레드시트를 다루는 것 정도는 Apache POI를 대체할만한 라이브러리들이 많이 있지만 템플릿까지는 지원하는 것이 없어보인다. 있었으면 코딩할 일도 없었을텐데 ~~아쉽다~~

아무튼 자바 기반 프로젝트는 진행한 경험이 없기 때문에 최대한 쉬운 방법을 선택했고 그게 Spring Boot 2 였다.

사실 MVC고 뭐고 다 필요없고 Gradle로 종속성 관리되고 웹 라우트 1~2개 정도 들어가는게 전부라 마이크로 웹 프레임워크 하나만 있으면 충분하겠지만 Java로 작성하는 웹 프레임워크는 Spring 밖에 들어본게 없다.

지금 생각하니 Grails라는게 있었지 참... (이 것도 어차피 스프링 부트란다 ㅋㅋ)

왜 Groovy?

스프링 부트를 시작하려니 선택지가 3개나 주어지더라

Java
Groovy
Kotlin(!!)

당연히 자바로 할거라 생각 중이였는데 막상 다른 선택지가 주어지니 자바는 쓰기 싫었다.

역시 요즘 기세등등한 코틀린을 쓸까 했다만..

일단 써보지 않아서 문법을 전혀 모르고 Java API와의 호환성을 확신할 수 없었다. (몰라서)

반면 그루비는 이전에 업무 때문에 써본적도 있고, 간결하고 (상당히) 모던한 문법을 지원하면서도, 자바 코드를 그대로 옮겨놔도 된다는 것도 알고 있었기 때문에 부담없이 선택할 수 있었다.

시간날 때 잠깐잠깐 코딩

뭐 스프링 프로젝트 세팅할 때만 해도 분석이 아니라 처음부터 만들어보는 건 첨이라 신나서 의욕 충만했지만, 당장 쓸일이 없는 프로젝트다보니 빠르게 식었다.

아래 메서드 하나가 전부라고 볼 수 있는데 프로젝트 세팅한 당일 날 끝났다.

그리고 일주일 간 천천히, 그냥 짬 날때마다 필요한 조금씩 코드를 더했다.

@PostMapping('/render')
ResponseEntity<ByteArrayResource> renderTemplate(
    @RequestParam('host') String host,
    @RequestParam('port') Integer port,
    @RequestParam('database') String dbname,
    @RequestParam('username') String username,
    @RequestParam('password') String password,
    @RequestParam('template') MultipartFile template
) {
    def conn = null
    def fileOut = null
    try {
        conn = DriverManager.getConnection(
            "jdbc:mysql://${host}:${port}/${dbname}",
            username,
            password,
        )
        def jdbc = new JDBCExecutor(conn)
        def metadata = conn.metaData
        def tables = getTableInfoList(metadata)

        def ctx = [
            jdbc  : jdbc,
            tables: tables,
        ]

        fileOut = new ByteArrayOutputStream()

        new ExcelTransformer()
            .transform(template.inputStream, ctx)
            .write(fileOut)

        ResponseEntity
            .ok()
            .contentType(MediaType.APPLICATION_OCTET_STREAM)
            .header(HttpHeaders.CONTENT_DISPOSITION, "attachment; filename=\"${template.originalFilename}\"")
            .body(new ByteArrayResource(fileOut.toByteArray()))

    } catch (Exception e) {
        e.printStackTrace()

        ResponseEntity
            .status(HttpStatus.INTERNAL_SERVER_ERROR)
            .contentType(MediaType.TEXT_PLAIN)
            .body(e.message)

    } finally {
        conn?.close()
        fileOut?.close()
    }
}

거의 자바 코드와 유사하면서도 풍부한 신택틱 슈가 덕에 약간 간결한 표현이 가능한 그루비. 써보니 스트레스 없이 나름 만족스러운 수준

데모

Gradle로 빌드하고 실행하면 위처럼 못생긴 폼이 나온다. (CSS 입혀서 좀 꾸밀걸...)

저기에 DB 커넥션 정보를 입력하고 템플릿 파일을 업로드하면 DB 메타데이터가 렌더링된 파일이 뽑혀 나온다.

Wordpress DB가지고 테스트해보자.

위 처럼 템플릿을 만든다. <jt:forEach ...>, ${column.name} 같은 표현식이 눈에 띈다.

표현식이 알맞게 작성되었다면 이런 식으로 뽑혀져 나온다.

마무리하며

프레임워크도 모르고 JDBC에서 뽑을만한 정보가 뭐가 있는지도 모른체 일단 만들어본거라 제대로 짰는지, 뭐가 더 필요할 지 알 수가 없다.

어쨋든 다른 프로젝트도 많고 이건 당장 필요한 만큼은 동작하니 일단 이 상태에서 동결해야겠다. 피드백없이 상상으로만 프로젝트를 진행하는 건 역시 재미가 떨어지니 이게 필요할 일이 실제로 생기면 그 때가서 다시 개선해서 사용해야겠다.

혹은!! 이게 필요하신 분은 자유롭게 쓰고 피드백 남겨주시면 좋겠습니다.

100% 오픈소스이며 GitHub 레파지토리에서 더 자세한 정보 볼 수 있습니다. 이슈 제시나 PR 등 적극 환영합니다.

도커로 루비 온 레일즈 프로덕션 환경 구성하기

Tue, 05 Jun 2018 00:00:00 GMT

이직한 회사에서 루비 온 레일즈를 처음 쓰게 되어 스터디겸 파일럿 프로젝트를 진행하고 있다.

실제로 사용할 서비스이기 때문에 배포와 운영 단계까지 고려하고 있는데, 프로젝트를 Dockerize하여 docker-compose로 운영하는 방향으로 정했다.

Dockerfile 이미지를 만들고 docker-compose로 서비스를 정의하는 것은 레일즈 뿐 아니라 대부분의 웹 앱이 비슷한 구성을 따라가기 때문에 이번에 하고 있는 레일즈 서비스 구성 과정을 참고 삼아 남겨두려고 한다.

일반적인 웹 애플리케이션 구성

일반적으로(적어도 내가 봐온 것들 기준으로) 작은 규모의 웹 서비스는 위 그림같이 프록시, 앱(+런타임) 서버, 스토리지(File, DB, Cache 등)으로 구성된다.

대표적인 예시로, APM(Apach + PHP + MySQL) 또한 이 구성에서 크게 벗어나지 않는다. 다만, APM처럼 하나의 웹서버가 프록시와 앱 실행 역할을 둘 다 수행하고 있다면 두 개의 웹 서버로 분리해주는 것이 서비스 구성성(Composability) 확보에 도움이 된다.

여기서는 NGINX, Ruby on Rails, MariaDB의 단일 인스턴스로만 스택을 구성한다. 서비스 이름을 줄여서 각각 Web, App, DB 라고 별칭한다.

App 이미지 만들기

Dockerfile 이미지

웹 애플리케이션의 Dockerfile을 작성하는 것은 패턴이 있기 때문에 단계별로 나눠서 서술해본다

기반 이미지 지정

FROM ruby:2.5.1-alpine

프로그래밍 언어에서 제공하는 공식 런타임 이미지가 있다면 사용한다. 프로그래밍 언어는 Stable 버전이 있고 호환성에 상당히 민감하기 때문에 latest를 사용하지 않고 버전을 지정한다.

문제가 없다면 가벼운 alpine 기반의 이미지를 사용하는 편이 이미지를 경량화 하고 빌드시간을 최소화할 수 있다.

필요한 의존성 설치

ENV NODE_VERSION 8.11.2

RUN apk add --no-cache --update \
    ca-certificates \
    linux-headers \
    build-base \
    libxml2-dev \
    libxslt-dev \
    tzdata \
    mariadb-dev \
    nodejs\<$NODE_VERSION \
    yarn

RUN gem install bundler \
    && bundler config --global frozen 1

이 패키지들이 레일즈 애플리케이션을 구동하는 데 필요한 최소한의 패키지들이다.

도커 컨테이너는 언제 몇 번을 빌드하고 실행하던 선언된 동작이 동일하게 수행되도록 불변성과 멱등성을 보장해야한다. 의존성 설치과정에서 버전 지정이 확실하지 않으면 설치되는 의존성 모듈의 버전에 따라 동작이 바뀔 여지가 있다. 버전 지정을 위한 몇 가지 규칙을 정해놓으면 좋다.

호환성이 상관없는(주로 단일 기능만 수행하는 모듈) 경우 마지막 안정(Stable) 버전을 설치한다.
버전에 따른 호환성 변경이 있는 경우, 버전을 지정해서 설치한다.
버전 지정의 경우 ENV 디렉티브를 이용해서 명시하고 참조가 가능하도록 한다.

현대적인 패키지 매니져들은 대부분 버전 잠금(Lock) 기능을 제공하니 활용하자.

추가적으로 번들러의 경우 frozen 옵션을 활성화하면 컨테이너 내부에서 패키지 버전이 임의로 변경되지 않도록 강제할 수 있다.

소스 코드 복사 & 빌드

루비의 경우 별도의 컴파일이 필요하지 않으므로, 소스코드를 복사하는 것만으로 실행 준비가 끝난다.

WORKDIR /app

ENV RAILS_ENV production

# Node 모듈 설치
COPY package.json yarn.lock ./
RUN yarn install --production

# Gem 모듈 설치
COPY Gemfile Gemfile.lock ./
RUN bundle install --without development test

# 레일즈 앱 전체 복사
COPY . .

WORKDIR 디렉티브를 사용하면 작업 디렉토리가 새로 생성되고 커맨드들이 해당 작업 디렉토리를 기준으로 실행된다.

도커 이미지는 디렉티브마다 레이어를 만들고 빌드 할 때 이 레이어 단위로 캐시한다. 캐시 여부에 따라 빌드 시간이 대폭 차이나므로 레이어를 잘 나누어야 한다. 소스코드가 변경될 때 마다 패키지 설치부터 다시하면 매우 비효율적이기 때문에 RUN 디렉티브를 나누어주고 변경이 적은 것부터 잦은 것 순 으로 배치한다.

실행 커맨드 지정

EXPOSE 3000
CMD ["bundle", "exec", "rails", "server", "-b", "0.0.0.0", "-p", "3000"]

도커 컨테이너는 포트를 바인딩해서 사용하므로 컨테이너 내부의 포트는 반드시 고정하고, 외부 서비스에 사용하는 포트는 EXPOSE 디렉티브로 명시한다.

CMD 디렉티브를 통해 컨테이너 커맨드를 지정하는데 데몬 형태가 아니라 반드시 Foreground로 실행되는 커맨드여야 한다.

볼륨 설정

도커 볼륨을 마운트해서 사용하게 될 데이터 경로들을 VOLUME 디렉티브로 명시한다.

VOLUME ["/app/storage", "/app/log"]

애플리케이션 환경 설정

애플리케이션에서 자주 변경되는 환경 설정은 환경 변수를 사용하도록 설정해서 컨테이너로부터 쉽게 분리하고 컨테이너의 불변성을 유지할 수 있다.

레일즈에서는 설정파일에서 ERB 템플릿 지원해서 쉽게 환경변수를 이용할 수 있는데, 설정 템플릿을 지원하지 않는 프레임워크인 경우에는 템플릿 엔진을 이용해서 직접 구현해야 한다.

DB 설정

레일즈의 ActiveRecord에서 사용하는 데이터베이스는 config/database.yml 파일에서 설정한다. 기본적으로는 SQLite3를 사용하도록 되어 있는데 프로덕션 모드에서 MariaDB를 사용하도록 Gemfile과 설정파일을 변경한다.

- gem 'sqlite3'

group :development, :test do
+  gem 'sqlite3'
end

group :production do
+  gem 'mysql2', '~> 0.5.1'
end

default: &default
  encoding: utf8
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>

development:
  <<: *default
  adapter: sqlite3
  database: db/development.sqlite3

test:
  <<: *default
  adapter: sqlite3
  database: db/test.sqlite3

production:
  <<: *default
  adapter: mysql2
  host: <%= ENV.fetch('MYSQL_HOST') { 'db' } %>
  port: <%= ENV.fetch('MYSQL_PORT') { 3306 } %>
  username: <%= ENV['MYSQL_USER'] %>
  password: <%= ENV['MYSQL_PASSWORD'] %>
  database: <%= ENV['MYSQL_DATABASE'] %>

DB는 docker-compose 스택으로 함께 구성할 것이기 때문에 db:3306 으로 고정해도 무관하다. docker-compose 스택 외부의 DB를 사용할 가능성이 있으므로 일단 환경변수로 분리하되 기본 값을 지정한다.

Logging 설정

레일즈는 프로덕션 모드 설정인 config/environments/production.rb를 보면 기본적으로 로깅을 log/production.log 파일에 하며 RAILS_LOG_TO_STDOUT 환경변수를 지정하면 stdout 스트림으로 로깅하도록 변경되게 끔 설정돼있다.

Docker와의 연계를 위해서 stdout으로 로깅하도록 변경하고 반대로 파일 로그(+ 자동 로테이션) 옵션을 만든다.

  stdout_logger = ActiveSupport::Logger.new(STDOUT)
  stdout_logger.formatter = config.log_formatter
  stdout_logger.level = ENV["LOG_LEVEL"] || :info
  stdout_logger = ActiveSupport::TaggedLogging.new(stdout_logger)
  config.logger = stdout_logger

  if ENV["ENABLE_FILE_LOG"] == "true"
    # 파일 로거를 생성한다. 자동으로 로테이션 되도록 설정할 수 있다.
    file_logger = ActiveSupport::Logger.new(config.paths["log"].first, 5, 10.megabytes)
    file_logger.formatter = config.log_formatter
    file_logger.level = ENV["FILE_LOG_LEVEL"] || :info
    file_logger = ActiveSupport::TaggedLogging.new(file_logger)
    # 로거를 교체하는 대신 로그 브로드캐스팅을 사용한다.
    config.logger.extend(ActiveSupport::Logger.broadcast(file_logger))
  end

File Storage 설정

ActiveStorage 설정은 config/storage.yml에서 변경할 수 있는데 로컬 스토리지를 사용하는 경우는 변경할 부분이 특별히 없다. storage/ 경로에 도커 볼륨을 마운트해서 사용할 것이다.

이미지 빌드 & 컨테이너 실행

이미지를 빌드하기에 앞서 프로젝트 루트에 .dockerignore 파일을 추가해서 빌드 시 불필요한 컨텍스트 전송을 방지한다. 필요한 내용은 .gitignore와 동일하므로 복사해서 사용해도 된다.

cp .gitignore .dockerignore

Dockerfile이 있는 경로에서 docker build 커맨드로 이미지를 빌드할 수 있다. rails-docker라는 이름으로 이미지를 빌드한다.

docker build --tag rails-docker .

이미지가 성공적으로 빌드되면 docker run 커맨드로 컨테이너를 실행해본다.

로컬호스트에 MariaDB가 설치되어 있다면, 컨테이너 네트워크를 host로 지정해서 테스트해볼 수 있다. 테스트에 사용할 DB는 미리 생성해두자.

docker run -it -d \
    --net=host \
    -e MYSQL_HOST=localhost \
    -e MYSQL_USER=root \
    -e MYSQL_PASSWORD=password \
    -e MYSQL_DATABASE=rails-data \
    -e ENABLE_FILE_LOG=true \
    -v $(pwd)/data/storage:/app/storage \
    -v $(pwd)/data/log:/app/log \
    rails-docker

매번 환경 변수를 커맨드에 입력하는 대신 .env 파일을 사용할 수 있다. 이 경우 .env 파일이 git 레파지토리에 들어가지 않도록 .gitignore에 반드시 추가해주자.

# .gitignore
+*.env

나는 로컬호스트에 데이터베이스를 설치하는 것을 싫어해서 MariaDB 컨테이너 이미지를 사용해서 테스트 했다. 같은 .env 파일을 컨테이너끼리 공유하도록 하면 쉽게 세팅할 수 있다.

# MYSQL_HOST=db
# MYSQL_PORT=3306

MYSQL_USER=rails-user
MYSQL_PASSWORD=password
MYSQL_DATABASE=rails-data

# LOG_LEVEL=info

ENABLE_FILE_LOG=true
# FILE_LOG_LEVEL=info

docker run -it -d \
    --name rails-db \
    --env-file .env \
    -e MYSQL_RANDOM_ROOT_PASSWORD=yes \
    -v $(pwd)/data/db:/var/lib/mysql \
    mariadb:10.2

docker run -it -d \
    --env-file .env \
    --link rails-db:db \
    -v $(pwd)/data/storage:/app/storage \
    -v $(pwd)/data/log:/app/log \
    rails-docker

ENTRYPOINT 스크립트

위 과정까지 하면 컨테이너 자체는 잘 실행 되지만 레일즈는 제대로 동작하지 않는다. 심지어 잘 안되는 이유가 하나만 있는 것도 아니다.

DB가 구동되기 전에 레일즈가 먼저 실행된다. 접속할 DB가 없어서 레일즈도 덩달아 초기화에 실패한다.
레일즈가 처음 실행됐다면 rails db:setup을 통해 DB를 초기화해주어야 한다.
추가로 스키마의 변경이 있다면 rails db:migrate을 통해 마이그레이션해주어야 한다.
프로덕션 모드에서는 에셋 파이프라인의 라이브 컴파일이 비활성화되기 때문에 rails assets:precompile로 초기화해주어야 한다.
실행했던 컨테이너를 중단하고 재시작하면 안에 남아있는 pid 파일 때문에 실패한다. 컨테이너의 라이프사이클과 적합하지 않은 임시 파일들을 삭제해주어야 한다.

이런 문제들은 레일즈가 도커랑 맞지 않아서 발생하는 것이 아니라, 대부분의 애플리케이션을 Dockerize 할 때 발생하는 공통적인 요구사항들이다.

docker exec -it {CONTAINER_ID} sh로 컨테이너 내부에 attach 해서 직접 실행해주면 문제를 해결할 수 있지만, 이건 아주 나쁜 방법이다. docker exec를 사용하는 것은 대표적인 안티패턴에 해당한다.

도커 컨테이너는 Mortal해서 언제든지 삭제 될 수 있다고 전제해야 한다. docker exec를 통해 임의로 변경한 사항들은 컨테이너가 삭제되면서 같이 사라진다.
(물론 docker commit을 통해 컨테이너 diff의 스냅샷을 보존할 수는 있지만 이렇게 사용하는 워크플로우는 흔하지 않다.)

컨테이너를 새로 생성할 때마다 직접 작업을 수행하는 것은 매우 비효율 적이므로 컨테이너의 진입점(Entrypoint)에서 자동화하는 것이 일반적이다.

Alpine 이미지의 기본 진입점은 /bin/sh이다. 컨테이너는 엔트리 + 커맨드로써 실행되므로 rails-docker 컨테이너는 /bin/sh bundle exec rails server ...의 프로세스와 동일하다.

진입점은 Dockerfile의 ENTRYPOINT 디렉티브를 통해 변경할 수 있다.

COPY docker-entry.sh .
RUN chmod +x ./docker-entry.sh
ENTRYPOINT ["./docker-entry.sh"]

프로젝트 루트에 docker-entry.sh 라는 쉘 스크립트를 추가해준다.

#!/bin/sh

# 임시 파일을 제거한다.
echo "Cleaning temp files..."
rm -rf tmp/*

# Asset이 초기화 됐는지 검사하고, 안되있으면 `rails asssets:precompile`로 초기화한다.
ASSETS_PATH="public/assets"
if [[ ! -n "$(ls -A $ASSETS_PATH 2>/dev/null)" ]]; then
    echo "Assets is not exist, precompiling assets..."
    bundle exec rails assets:precompile
fi

# netcat을 사용해서 DB가 준비될 때 까지 대기시킨다.
until nc -z $MYSQL_HOST $MYSQL_PORT; do
    echo "MySQL is not ready, sleeping..."
    sleep 5
done

# 현재 스키마 버전과 마지막 스키마 버전을 읽는다.

# `rails db:version` 명령어로 현재 DB에 셋업된 스키마 버전을 볼 수 있지만 불필요한 문자열이 포함되어 있으므로
# ActiveRecord::Migrator.current_version 을 대신 사용한다.
SCHEMA_VERSION="$(rails runner "puts ActiveRecord::Migrator.current_version" | tail -n 1)"
LAST_SCHEMA_VERSION="$(find "db/migrate" -name "*.rb" | xargs basename | sort | tail -n 1 | cut -d '_' -f 1)"

echo "Detected the current DB schema version is $SCHEMA_VERSION"
echo "Detected the last DB schema version is $LAST_SCHEMA_VERSION"

# DB가 아직 초기화 되지 않았다면 스키마 버전이 0이다.
# `rails db:setup`으로 초기화 해준다.
if [[ $SCHEMA_VERSION -eq "0" ]]; then
    echo "Initializing the database..."
    rails db:setup

# 현재 DB 스키마 버전과 최종 migration 파일의 버전을 비교하고
# 필요하면 `rails db:migrate`으로 마이그레이션 한다.
elif [[ $SCHEMA_VERSION -lt $LAST_SCHEMA_VERSION ]]; then
    echo "Updating the database..."
    rails db:migrate
fi

# 초기화 과정을 완료하면 컨테이너의 커맨드를 실행한다.
# `exec`를 사용하면 현재 프로세스에서 컨텍스트만 넘겨 사용할 수 있다.
exec "$@"

관례적으로 쉘 스크립트를 쓰지만, 사실 루비 런타임이 포함되어 있는 이미지기 때문에 진입점을 쉘 대신 루비로 작성해도 된다.

다른 대안으로 네트워크 대기, 환경변수 템플릿 등 일반적인 자동화 요구사항들의 구현을 제공하는 Dockerize라는 구현체도 있다.

다시 이미지를 빌드하고 실행해보면 자동적으로 필요한 과정들이 수행되고 성공적으로 레일즈 앱을 컨테이너로 실행할 수 있다.

docker-compose 사용하기

docker-compose는 컨테이너 실행에 필요한 옵션들을 Yaml 형태의 DSL로 제공하고 여러 컨테이너들을 하나의 스택으로 관리할 수 있는 기능을 제공하는 도구이다.

DB, App, Web 서비스를 하나의 스택으로 정의하고 docker-compose가 제공하는 다양한 커맨드를 통해 쉽게 관리할 수 있다.

서비스 스택 정의하기

프로젝트 경로에 docker-compose.yml 파일을 추가한다. (보통 프로젝트 상위 경로에서 하는 것이 일반적이긴 하다)

version: '3.5'
services:
  db:
    image: mariadb:10.2
    env_file: .env
    environment:
      - MYSQL_RANDOM_ROOT_PASSWORD=yes
    volumes:
      - db-data:/var/lib/mysql
      - /etc/localtime:/etc/localtime:ro

  app:
    build: .
    env_file: .env
    environment:
      - MYSQL_HOST=${MYSQL_HOST:-db}
      - MYSQL_PORT=${MYSQL_PORT:-3306}
    volumes:
      - app-assets:/app/public/assets
      - app-data:/app/storage
      - app-logs:/app/log
      - /etc/localtime:/etc/localtime:ro

  # Rails는 프로덕션 모드에서 기본적으로 public/ 경로의 정적파일들을 서브하지 않도록 설정되어 있다.
  # 웹 서버를 사용하지 않는 경우 `config/environments/production.rb` 파일에서 `config.public_file_server.enabled` 옵션을 true로 변경해야 한다.
  web:
    build:
      dockerfile: nginx.Dockerfile
    ports:
      - "80:80"
    volumes:
      - web-logs:/var/log/nginx
      - app-assets:/web/public/assets:ro
      - /etc/localtime:/etc/localtime:ro

volumes:
  db-data:
  app-data:
  app-assets:
  app-logs:
  web-logs:

MariaDB는 DockerHub에서 받은 이미지를 그대로 사용하고, NGINX는 공식이미지에 프로젝트에서 사용하는 정적파일들과 기본설정을 추가해서 사용했다.

nginx.Dockerfile을 프로젝트 경로에 추가해준다.

FROM nginx:alpine
COPY public /web/public
COPY nginx.conf /etc/nginx/conf.d/default.conf
VOLUME ["/var/log/nginx"]

nginx.conf 파일도 프로젝트 경로에 추가한다.

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    server_name _;

    sendfile on;

    gzip on;
    gzip_vary on;

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    error_page 500 502 503 504 /500.html;
    error_page 404 /404.html;
    error_page 422 /422.html;

    location ~ .*\.(ico|txt|eot|ttf|woff|woff2)$ {
        access_log off;
        log_not_found off;
    }

    location ~ ^/assets/ {
        gzip_static on;
        root /web/public;
    }

    location ~ ^/(500|404|422).html$ {
        root /web/public;
    }

    location / {
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass http://app:3000;
    }
}

나는 일반적인 nginx 설정을 이미지에 직접 추가해주었고 프로젝트의 git 레파지토리에서 함께 관리하도록 하였는데, 이보다 더 복잡한 설정 파일 관리가 필요한 경우 설정 파일 경로(/etc/nginx/conf.d) 전체를 볼륨으로 관리해줄 수도 있다.

docker-compose 커맨드로 서비스 관리

이렇게 구성을 전부 정의해놓고 나면 커맨드를 사용해서 전체 서비스를 쉽게 관리할 수 있다.

docker-compose up -d --build 커맨드를 실행하면 docker-compose가 스택에 정의된 내용을 바탕으로 도커 컨테이너, 네트워크, 볼륨을 만들어 생성하여 서비스를 구성해준다.
docker-compose start [service], docker-compose stop [service], docker-compose kill [service] 명령어로 전체 또는 개별 서비스를 관리할 수 있다.
docker-compose logs [-f] [service] 명령어로 서비스에서 출력한 로그를 볼 수 있다.
docker-compose down 명령어로 전체 스택을 중지하고 컨테이너와 네트워크를 삭제하며, docker-compose down -v 명령어를 사용하면 볼륨까지 삭제되어 서비스 전체를 완전히 초기화할 수 있다.

마무리하며

SaaS급 정도되는 서비스 전체를 Dockerize하고 관리하는 데는 한 개 팀 정도는 있어야겠지만, 단일 호스트에서 실행하는 작은 In-house 서비스는 docker-compose 정도로도 충분히 관리할 수 있다.

또한 서비스 스택을 Dockerize하는 과정은 서비스 운영을 가능한 최소한의 구성으로 자동화하는 과정에 가깝기 때문에 애플리케이션이 요구하는 숨은 의존성과 운영에 필요한 공수를 미리 파악하는데 도움이 된다.

일단 지금 당장(레일즈를 처음 사용하며 스터디하는 데)은 별 쓸모 없는 야크쉐이빙이지만, 해놓으면 나중에 삽질할 일 조금이라도 줄겠지

Flow의 Type-level Function 소개

Fri, 20 Apr 2018 00:00:00 GMT

타입 이론에 대해 무지한 상태입니다.. 공부하면서 고치는데 무지하게 시간 쏟을 것 같으니 이상한 내용 있으면 서슴없이 알려주세요

Flow의 고급기능에는 생각보다 잘 알려지지 않은 재밌는 것들이 많다.

미리 빌드되서 제공되는 유틸리티 함수들 중에서도 재밌는 게 많지만, 가장 재밌는 건 Type-level 함수(이하 타입레벨함수)로 직접 유틸리티를 만드는 일 같아 소개하는 글을 써본다.

Type-level Function

Flow는 오직 Flow 서버에서 다른 타입을 추론하는 용도로만 사용될 특별한 타입의 정의를 지원하는데 이걸 타입레벨함수라고 부르는 것 같다.(비공식)

type ExtractReturnType = <T>(() => T) => T

엥? 이거 그냥 제네릭 아닌가?

제네릭 템플릿(이하 템플릿)과 비슷한 표현식(<T>)이 사용되지만, 그 위치가 약간 다르다.

다음은 템플릿 함께 사용되는 예시이다.

// Generic
type Either<L, R> = { type: 'Left', value: L } | { type: 'Right', value: R }

// Type-level Function
type EitherF = <L, R>(x: [L, R]) => Either<L, R>
type ArrayF = <A>(x: [A]) => Array<A>

// Build new types via `$Call`
type ArrOfStrings = $Call<ArrayF, [string]>
type EitherOfStringNumber = $Call<EitherF, [string, number]>

템플릿의 경우 타입 인자가 선언(Declaration)에 들어가고, 타입레벨함수에서는 정의(Definition)에 들어가는 차이점이 보인다.

타입레벨함수 F는 <...>(...) => ... 꼴로 정의할 수 있다.

컨텍스트: <...>
파라미터: (...)
리턴: => ...

템플릿과는 다르게 타입레벨함수에서는 <> 키워드 안에 전달한 타입들이 인자로 사용되지 않고 추론에 필요한 컨텍스트로만 사용된다. 실제 함수에 사용할 인자는 () 안에 정의하고, 이 인자 타입으로부터 추론될 타입을 => 뒤에 정의한다.

그리고 파라미터 타입과 리턴 타입을 정의하는데 앞서 정의한 컨텍스트를 활용할 수 있는 식이다.

이 설명과 예제로는 이해하기 너무 어려우니, 앞서 정의해놓은 ExtractReturnType 통해 어떻게 쓰는지 알아보자.

$Call

$Call<F, T> 유틸리티 함수는 Callable한 타입레벨함수 F와 그 함수에 인자로 전달할 타입 T를 제네릭 인자로 받아 Flow 서버에서 실제로 실행해서 추론된 타입을 반환한다.

type Fn = () => number
type ReturnType = $Call<ExtractReturnType, Fn>

(5: ReturnType)    // OK

// $ExpectError
(true: ReturnType) // Error: ReturnType is a number

$ObjMap, $TupleMap

$ObjMap<T, F>와 $TupleMap<T, F>는 Object/Array와 F를 받고, 엔티티 타입들에 대해 일괄적으로 $Call 해준다. JavaScript에서 .map() 함수가 하는 역할을 생각해보면 이해하기 쉬울 것이다.

그렇게 반환된 타입은 원래의 구조를 유지한 채로 엔티티 타입들이 새롭게 정의된다.

function run<A, O: {[key: string]: () => A}>(o: O): $ObjMap<O, ExtractReturnType> {
  return Object.keys(o).reduce((acc, k) => Object.assign(acc, { [k]: o[k]() }), {})
}

const o = {
  a: () => true,
  b: () => 'foo'
}

(run(o).a: boolean) // Ok
(run(o).b: string)  // Ok

// $ExpectError
(run(o).b: boolean) // Nope, b is a string

// $ExpectError
run(o).c // Nope, c was not in the original object

~~공식 예제 장난하냐 진짜~~

그래서 이 것들을 어디다 써먹을까

사용예1. React Component의 PropType 추론하기

얼마전 트위터 타임라인에서 이런 글을 보게되었다.

type PropsType<T> = T extends React.Component<infer P> ? P : {};
라이브러리에서 PropsType을 export 안하고 있지만 저걸로 뜯어냈다. (ex: PropsType<YouTube>['opts']) 타입스크립트 개쩜ㅋㅋㅋㅋㅋ flow는 이런거 못하지 ㅋㅋ
— ㄹ (@disjukr) 2018년 4월 13일

TypeScript 2.8에서 Conditional Type이라는 ~~사기적인~~ 기능과 함께 infer 키워드가 추가되면서, Flow처럼 리턴 타입을 추론해내거나 하는 일이 가능해졌다.

추가된 기능을 이용해 Component<P, S> 템플릿 파라미터의 실제 타입을 추론해낸건데 이건 Flow로도 되지 않을까?

일단 해보자.

~~작은 삽질 끝에~~ 내가 작성한 타입은 다음과 같다.

import { Component } from 'react'
import MyComponent from './component'

type InferPropsTypeFn = <P, C: Component<P>>(comp: C) => P
type $InferPropsType<C: Component<any>> = $Call<InferPropsTypeFn, C>

export type MyComponentProps = $InferPropsType<MyComponent>

P, C 두개를 정의하고 C는 React.Component와 템플릿 인자 P로 구성되어 있음을 알린다. 그리고 C를 인자로 받으면 P를 리턴하도록 정의했다.

솔직히, TypeScript에선 되지만 Flow에서 안되는 것들도 몇 번 봐왔기 때문에 (Conditional Type 이라니 다시 생각해도 너무 사기적인 기능 아닌가?) 안될 수도 있겠다 싶어 불안했지만...

Flow를 제대로 활용하고 싶다면, VSCode보단 Atom + Nuclide 가 더 나은 선택이다.

성공했다! 저렇게 뜯어 낸 Object 타입에서 프로퍼티 타입을 가져오고 싶을 땐 $PropertyType<T, k> 유틸리티를 쓰면 된다.

사용예2. Reducer 목록으로 부터 State 추론하기

이게 가장 잘 알려진 사용 예시인 것 같다.

참고: Type-checking React and Redux (+Thunk) with Flow — Part 2

Redux에서 사용되는 Reducer는 부분적인 State와 Action을 받아 새로운 State를 반환하는 순수 함수이다. 다시 말해 모든 Reducer들이 반환하는 리턴타입을 조합하면 전체 State를 추론해낼 수 있다.

import type { Reducers } from 'reducers'

type ExtractReturnType = <V>(v: (...args: any) => V) => V

export type State = $ObjMap<Reducers, ExtractReturnType>

전체 상태를 힘겹게 다시 정의하지 않아도 되는 유용한 패턴이다.

사용예3. Nested 타입 추론하기

좀 더 복잡한 타입의 경우는 어떨까? 엄청나게 중첩된 Nested Object가 있더라도 Flow는 거뜬히 추론해준다.

// Extracting deeply nested types:
type NestedObj = {|
  +status: ?number,
  +data: ?$ReadOnlyArray<{|
    +foo: ?{|
       +bar: number,
    |},
  |}>,
|};

// If you wanted to extract the type for `bar`, you could use $Call:
type BarType = $Call<
  <T>({
    +data: ?$ReadOnlyArray<{
      +foo: ?{
        +bar: ?T // 여기 이 부분
      },
    }>,
  }) => T,
  NestedObj,
>;

(5: BarType);

// $ExpectError
(true: BarType);  // Error: `bar` is not a boolean

된다는 거지 이렇게 쓰는 경우는 없다. (있다면 타입 정의 다시해야한다)

마무리 하며

여느 Facebook 라이브러리들이 그렇듯, 문서에는 Concept과 Philosophy 위주로 설명되어 있고 MS처럼 진입장벽을 허물고 사용자를 포섭하려는 노력이 부족한 것 같다.

나날히 발전하는 TypeScript 진영을 보면서, 그리고 이미 종말에 치달은 Flow의 이슈트래커와, 그래도 아직 Flow가 나은점이 있다고 위로하면서도 정작 자신의 프로젝트에는 TypeScript를 셋업하고 있는 나를 보면서, Flow 사용자로서의 자부심이 바닥을 치고 있는 요즘이다.

기능 자체는 Flow에서 먼저 나오고 TypeScript가 따라오는 형태라도, Flow의 코드베이스가 OCaml인 만큼(대체 왜...) 신규 기여자 유입이 많이 힘들어서 다다음 릴리즈 쯤이면 전부 따라잡힐 것 같다.

그래도 타입 이론을 공부하거나 타입 라이브러리를 유지보수할 땐 (아직까진) Flow가 더 많은 확장성을 제공한다고 생각해서 계속 쓰지만, 솔직히 미래는 어둡다. 너무 아쉬운 도구인 것 같아.

오픈소스기여로 알게 된 Content-Type 표준과 깨달은 점

Sat, 14 Apr 2018 00:00:00 GMT

오늘도 Mattermost 컨트리뷰션 중, 개인적으로 인상깊은 경험을하여 급하게 글로 남긴다.

요약: 라이브러리 개발/기여의 영향력이나 파급효과를 항상 고려하고, 관련 표준을 꼭 꼼꼼히 찾아보도록 하자!

캐릭터셋 이슈

Mattermost는 글에 HTML페이지 링크를 넣으면 서버에서 HTML을 파싱해서 OpenGraph 메타데이터를 저장하고 이걸 미리보기용 데이터로 제공한다.

OpenGraph는 사이트 미리보기를 지원하기 위한 메타태그 확장 중 하나이다.

하지만 종종 문자셋이 이렇게 깨지는 이슈가 있다.

GitHub 이슈 링크

나도 종종 이 문제로 불편해하고 있었으므로 직접 해결해보기로 했다.

문제는 많은 사이트들이, 특히 국내 뉴스 사이트 아직도 UTF-8이 아닌 다른 문자셋을 사용해서 페이지를 제공하기 때문에 발생한다. 서버에서 각자 다른 방식으로 인코딩 된 메타데이터를 주고, 클라이언트는 무조건 UTF-8로 표현하려고 하니 Non-ASCII 글자가 다 깨지는 것이다.

이슈는 클라이언트 사이드로 라벨링 되었지만, 나는 이 이슈가 서버사이드에서 해결하는 것이 더 적절하다고 판단했고, 더 나아가 한 번 파싱한 페이지를 재 파싱하는 것은 매우 비효율적이므로, HTML에서 OpenGraph 정보를 파싱하는 외부 모듈에 기여해서 해결하는 것이 이상적이라고 판단했다.

자신있게 PR하기!

문제의 그 모듈이다.

https://github.com/dyatlov/go-opengraph

최근 커밋이 2~3년 전이라 유지보수가 중단된 것은 아닐지 걱정했지만, 이삭줍기 PR을 보냈더니 엄청나게 빠른 답변을 주었다.

모듈 자체는 매우 간단해서, 메타 태그를 순회하는 구간에 몇 가지 케이스만 추가해주면 될 것 같았다.

먼저 HTML5의 경우

<meta charset="euc-kr">

키는 charset이고 값을 가져오면 되는 아주 간단한 케이스이다.

type OpenGraph struct {
 	isArticle        bool
 	isBook           bool
 	isProfile        bool
+	Charset          string   `json:"charset"`
 	Type             string   `json:"type"`
 	URL              string   `json:"url"`
 	Title            string   `json:"title"`
...

...
    if keyStr == "charset" {
        og.Charset = valStr
    }
}
og.ProcessMeta(m)

하지만 HTML4 방식의 경우 조금 더 복잡했는데,

<meta http-equiv="content-type" content="text/html; charset=windows-1250">

이런 식으로 http-equiv의 값이 content-type이고, MIME 정의를 컨텐트로 가지는 태그에 대응해야 했다.

당황하지 않고 기존 코드의 컨벤션을 살핀 후, 비슷한 스타일로 전용 함수를 작성했다.

func (og *OpenGraph) processCharsetMetaForHTML4(metaAttrs map[string]string) {
	contentType := metaAttrs["content"]
	const key = "charset="
	if i := strings.Index(contentType, key); i > 0 {
		charset := contentType[i+len(key):]
		og.Charset = strings.TrimRight(charset, " ")
	}
}

var hasMIME bool
...
    if keyStr == "http-equiv" && strings.EqualFold(valStr, "content-type") {
        hasMIME = true
    }
}
if hasMIME {
    og.processCharsetMetaForHTML4(m)
}

좋다. 잘 작동하는지 확인시켜주는 테스트코드도 변경한 후 PR을 보냈다.

https://github.com/dyatlov/go-opengraph/pull/3

이 정도면 꽤나 훌륭하게 처리됐다고 생각했다. 빠른 답변을 주는 메인테이너이기 때문에 보상겸 휴식을 취하면서 기다렸다.

의외의 답변, 그리고 표준

Charset is not part of OpenGraph standard, so I would rather not add it here, it can be parsed separately. Also, I don't think that you're parsing content-type meta correctly: https://www.w3.org/Protocols/rfc1341/4_Content-Type.html Encoding definition can be a quoted string.

두 가지 문제를 지적받았다.

첫 번째는, Charset 자체가 OpenGraph 표준에 포함되지 않는다는 것. 이건 어느정도 예상한 답변이였지만 확장 필드 하나만 추가하는 정도였고 나름 합리적인 이유가 있다고 생각했다. 그래도 받을 이유는 충분치 않으니 실제 이슈 링크를 전달하면서 나은 제안이 있으면 알려달라고 했다.

내가 예상치 못한 부분 두 번째, 바로 잘못 파싱했다는 부분이였다.

분명 위의 두 메타태그에 대한 테스트도 해보았지만 문제가 없었다. 그런데 틀렸다고? 메인테이너인 Vitaly(@dyatlov)님이 친절하게 MIME에 대한 RFC 링크까지 주어서 드물게 RFC를 자세히 읽어보았다.

MIME(Multipurpose Internet Mail Extensions)의 Content-Type 헤더

Content-Type은 웹을 한다면 자주 봤을 보게 되는(주로 HTML4 equiv 태그나 HTTP Response Header에서 확인할 수 있는), 전송 컨텐츠의 타입정보를 담는 헤더이다.

MIME 표준에 대해 기술하고 있는 RFC 1341의 4번째 챕터에서 Content-Type에 대한 정확한 정의를 확인할 수 있다.

Content-Type := type "/" subtype *[";" parameter]

지적받은 잘못 파싱된 부분은 parameter였는데, parameter는 attribute "=" value로 정의되어 있고 여기서 value가 다시 token / quoted-string으로 정의되어 있다.

token의 정의는 일반적으로 쓰는 utf-8, euc-kr, windows-1250 형식이 맞다.

근데 quoted-string 이라고? 'UTF 8' 'EUC KR', 'Windows 1250' 이런식으로도 가능하다는 얘기같은데 이해한게 맞는지 정확히 모르겠다.

(더 자세히 내용을 아시는 분은 부디 알려주시면 감사하겠습니다 )

왜냐면 저런 형식을 사용하는 것은 HTML이나 웹 서버를 다루면서도 실제로 본적이 없기 때문이다. MDN 문서에서도 언급이 없다.

표준의 중요성과 오픈소스

표준의 중요성은 아무리 강조해도 지나치지 않다고 생각한다. 하지만 나름 큰 플랫폼에서 놀다보니 그 플랫폼에서 사용되는 방식이 표준이라고 착각하고 있었다.

MIME은 웹 뿐만 아니라 인터넷 전반을 아우르는 표준이다. 비록 일반적인 환경에서 token 형식만 봐왔더라도, 다른 어딘가에서 quoted-string 쓰이고 있어 언젠가 문제가 됬을지도 모른다.

플랫폼의 틀에 갖혀 호환성을 놓칠뻔했지만 go-opengraph 모듈의 메인테이너이자, 노련한 웹 개발자로 보이는 Vitaly는 이 부분을 놓치지 않았고, 나에게 잘못된 점과 더 나은 방안을 친절하게 가르쳐 주었다.

감탄과 함께, 또 다시 오픈소스에서 좋은 경험을 얻었다.

후에 라이브러리 개발자가 되고 싶은 사람으로서, 표준에 대한 경각심을 더 가지고 살아야 할 것 같다.

끝. 이제 자야지

추가

나중에 생각해보니 굳이 Charset 알아내려고 HTML 태그 파싱할 필요가 없는게, 정상적인 서버면 응답헤더에도 Content-Type이 있겠지.

결론: 의미있는(?) 삽질이였다 ㅋㅋ

추가 2

캐릭터셋 인코딩 변환을 위해 iconv 부터 찾다니... 내가 Go를 너무 만만히 본 것 같다.

결론: 재차 강조하지만 삽질하기 싫으면 표준을 살피자..

Babel 7 + Node.js로 모던 자바스크립트 사용하기

Thu, 12 Apr 2018 00:00:00 GMT

주의사항: 이 글은 현재 베타버전인 Babel 7에서의 사용법을 기준으로 설명한다.

바벨이란?

바벨은 자바스크립트 표준인 ECMAScript(이하 ES)의 최신 문법으로 작성된 코드를 실행할 수 있는 이전 버전 문법으로 변환해주는 트랜스파일러이다. (core-js 등의 주요 폴리필도 포함하고 있다.)

자바스크립트는 ECMAScript 표준과, TC39 위원회, 자바스크립트 커뮤니티를 통해 빠르게 발전해오고 있지만 브라우저들과 노드가 지원하는 자바스크립트는 이 표준을 제대로 호환하지 못하거나 따라잡지 못하고 있다. 특히 구버전의 IE를 지원하거나 해야되는 상황도 많기 때문에 순수히 ES를 사용해 개발하는 것은 그림의 떡같은 상황이다.

ES 호환성 테이블에서 지원현황을 확인할 수 있다.

최신(Current)버전의 노드는 비교적 문법지원이 빠른 편이지만, 서버리스 플랫폼을 사용하는 등 이유로 트랜스폼이나 폴리필이 필요할 수도 있다.

바벨을 사용하면 이런 호환성 걱정 없이 자바스크립트의 최신 문법을 어디서나 자유롭게 사용할 수 있고, 이 후에 포함될 문법도 미리 사용해볼 수 있다.

바벨 설정하기

이미 ES 문법을 사용하거나 리액트를 사용하는 프로젝트라면 이미 설정되어 있겠지만, 간단하게 설치하는 법과 설정하는 법을 살펴본 후 어떻게 최적의 설정 하는지 살펴보자.

먼저 Yarn을 이용해 AwesomeProject라는 이름으로 프로젝트를 생성하고, 바벨을 사용하기 위한 필수 패키지를 설치한다.

# Yarn으로 Node.js 프로젝트 생성
mkdir AwesomeProject
cd AwesomeProject
yarn init -y

# 바벨 패키지 설치
yarn add --dev @babel/core @babel/cli @babel/preset-env @babel/polyfill

프로젝트 루트에 간단하게 package.json이 생성되고 @babel/core, @babel/cli, @babel/preset-env 패키지가 devDependencies에 추가된다. 폴리필 사용도 설명하기 위해 @babel/polyfill도 추가했다.

동작을 확인하기 위해 일단 간단한 코드를 index.js라는 이름으로 생성한다.

import '@babel/polyfill'

const name = 'World'

const main = async () => {
  console.log(`Hello ${name}`)
}

main().catch(console.error)

ES모듈 임포트, 화살표 함수, 템플릿 리터럴, Async 함수 등의 문법을 사용했다.

이 파일을 설치한 바벨 CLI를 이용해서 트랜스파일 해보자

npx babel --presets @babel/env index.js

트랜스파일 된 코드가 stdout으로 다음과 같이 출력된다.

"use strict";

require("@babel/polyfill");

function _asyncToGenerator(fn) { return function () { var self = this, args = arguments; return new Promise(function (resolve, reject) { var gen = fn.apply(self, args); function step(key, arg) { try { var info = gen[key](arg); var value = info.value; } catch (error) { reject(error); return; } if (info.done) { resolve(value); } else { Promise.resolve(value).then(_next, _throw); } } function _next(value) { step("next", value); } function _throw(err) { step("throw", err); } _next(); }); }; }

var name = 'World';

var main =
/*#__PURE__*/
function () {
  var _ref = _asyncToGenerator(
  /*#__PURE__*/
  regeneratorRuntime.mark(function _callee() {
    return regeneratorRuntime.wrap(function _callee$(_context) {
      while (1) {
        switch (_context.prev = _context.next) {
          case 0:
            console.log("Hello ".concat(name));

          case 1:
          case "end":
            return _context.stop();
        }
      }
    }, _callee, this);
  }));

  return function main() {
    return _ref.apply(this, arguments);
  };
}();

main().catch(console.error);

import 구문이 commonjs의 require로 바뀌고 async에 대한 폴리필이 들어가는 등, 언급한 문법들이 조금 더 하위 문법(ES5)의 코드로 변환된 것을 확인할 수 있다.

이렇게 생성된 코드는 노드 버전 4에서 실행하더라도 의도한대로 잘 동작한다. (정확히는 유지보수되고 있는 노드 버전에 대한 동작을 보장한다. 버전 5는 LTS버전이 아니라서 이미 EoL이 지났기 때문에 공식적으로 지원하진 않는다.)

플러그인과 프리셋

잠깐, 위 예제에 치명적인 결함이 있는 것 같다.

내 노드 버전은 무려 9.11이라 import만 require로 바꿔주면 그냥 돌아갈텐데.. 모듈 문법 하나때문에 이렇게 큰 코드를 생성해서 실행해야만 하는가?

바벨은 각 문법별 트랜스폼을 각각 독립적인 플러그인(Plugin)으로 제공하며, 이 플러그인들을 한꺼번에 적용할 수 있도록 모아놓은 것을 프리셋(Preset)이라 한다.

이전에 자주 쓰이던 프리셋으로는 babel-preset-es2015(년도별 표준 프리셋), babel-preset-stage-0(스테이지 넘버별 프리셋) 등이 있다. 이 프리셋들은 이름대로 어떤 기준에 따라 플러그인을 모아놓고 한번에 적용하기 위한 용도로 많이 사용됐지만, 실제 실행환경을 고려하지 못해 종종 불필요하게 너무 많은 트랜스폼이 포함되는 문제가 있었다. 그렇다고 사용할 플러그인만 일일히 추가하기엔 설정이 매우 귀찮다.

이런 문제를 해결하기 위해 등장한 것이 Env 프리셋이다. Env 프리셋의 등장 이 후 이전에 자주 사용되던 년도별, 스테이지별 프리셋들은 사용이 권장되지 않는다.

Env 프리셋 사용하기 - 플러그인

Env 프리셋은 기본적으로 stage 3 이상 쯤 되는 문법의 플러그인들을 포함하고 있다. 자세한 목록을 확인해보자.

$ yarn list --pattern @babel/plugin --depth 1
yarn list v1.5.1
├─ @babel/plugin-proposal-async-generator-functions@7.0.0-beta.44
├─ @babel/plugin-proposal-object-rest-spread@7.0.0-beta.44
├─ @babel/plugin-proposal-optional-catch-binding@7.0.0-beta.44
├─ @babel/plugin-proposal-pipeline-operator@7.0.0-beta.44
├─ @babel/plugin-proposal-unicode-property-regex@7.0.0-beta.44
├─ @babel/plugin-syntax-async-generators@7.0.0-beta.44
├─ @babel/plugin-syntax-object-rest-spread@7.0.0-beta.44
├─ @babel/plugin-syntax-optional-catch-binding@7.0.0-beta.44
├─ @babel/plugin-syntax-pipeline-operator@7.0.0-beta.44
├─ @babel/plugin-transform-arrow-functions@7.0.0-beta.44
├─ @babel/plugin-transform-async-to-generator@7.0.0-beta.44
├─ @babel/plugin-transform-block-scoped-functions@7.0.0-beta.44
├─ @babel/plugin-transform-block-scoping@7.0.0-beta.44
├─ @babel/plugin-transform-classes@7.0.0-beta.44
├─ @babel/plugin-transform-computed-properties@7.0.0-beta.44
├─ @babel/plugin-transform-destructuring@7.0.0-beta.44
├─ @babel/plugin-transform-dotall-regex@7.0.0-beta.44
├─ @babel/plugin-transform-duplicate-keys@7.0.0-beta.44
├─ @babel/plugin-transform-exponentiation-operator@7.0.0-beta.44
├─ @babel/plugin-transform-for-of@7.0.0-beta.44
├─ @babel/plugin-transform-function-name@7.0.0-beta.44
├─ @babel/plugin-transform-literals@7.0.0-beta.44
├─ @babel/plugin-transform-modules-amd@7.0.0-beta.44
├─ @babel/plugin-transform-modules-commonjs@7.0.0-beta.44
├─ @babel/plugin-transform-modules-systemjs@7.0.0-beta.44
├─ @babel/plugin-transform-modules-umd@7.0.0-beta.44
├─ @babel/plugin-transform-new-target@7.0.0-beta.44
├─ @babel/plugin-transform-object-super@7.0.0-beta.44
├─ @babel/plugin-transform-parameters@7.0.0-beta.44
├─ @babel/plugin-transform-regenerator@7.0.0-beta.44
├─ @babel/plugin-transform-shorthand-properties@7.0.0-beta.44
├─ @babel/plugin-transform-spread@7.0.0-beta.44
├─ @babel/plugin-transform-sticky-regex@7.0.0-beta.44
├─ @babel/plugin-transform-template-literals@7.0.0-beta.44
├─ @babel/plugin-transform-typeof-symbol@7.0.0-beta.44
└─ @babel/plugin-transform-unicode-regex@7.0.0-beta.44
Done in 0.30s.

앞에서 본 것 처럼 별다른 설정없이 Env 프리셋을 사용하면, 기본적으로 이 플러그인들이 적용된다. 하지만 Env 프리셋은 그 이름에 걸맞는 특별한 기능들을 가지고 있다.

Env 프리셋은 타겟이 될 "환경"을 browserslist를 사용해 지정하고, ES호환성 테이블의 정보를 활용해서 필요한 플러그인만 선택해주는 스마트한 프리셋이다.

바벨의 엔트리 설정파일 .babelrc.js을 만든다.

module.exports = {
  presets: [
    ['@babel/env', {
      targets: {
        node: 'current',
      },
    }],
  ],
}

기본적으로 플러그인이나 프리셋은 presets: ["@babel/env"] 식으로 이름(resolve)만 주고 사용하지만, 세세하게 옵션을 지정할 땐 [resolve: string, option: Option] 형태로 들어간다.

targets({ [string]: number | string }): 여기서 프로젝트 타겟 환경을 지정할 수 있다. chrome, opera, edge, firefox, safari, ie, ios, android, electron 식별자로 특정 브라우저 버전을 콕 짚어서 지정할 수 있다. 예를 들면 이런식으로:
```
{
  /* ... */
  targets: {
    ie: 11,
    chrome: 43, // 물론 여기서 'last 2 versions' 같은 브라우저리스트 셀렉터를 쓸 수도 있다.
    firefox: 52,
    edge: 40,
    ios: 9,
    android: 5
  }
  /* ... */
}
```
- node(number | string | 'current' | true): 노드의 프로젝트의 경우 'current'나 true로 지정하면 실제 바벨을 실행하는 노드 환경의 버전(process.versions.node)이 선택된다.
- browsers(Array<string> | string): 일일히 지정하는게 아니라 이 옵션에서 브라우저리스트 셀렉터를 하나 이상 지정해주면 알아서 골라준다. 물론 명시적으로 특정 브라우저를 지정해서 설정했다면, 이 옵션은 오버라이딩 될 것이다.

이참에 index.js는 src/index.js로 옮기고 package.json에 빌드 스크립트도 추가해줘서 프로젝트 스러운 구조를 만들어보자.

mkdir src
mv index.js src/

{
  name: AwesomeProject,
  version: 1.0.0,
-  main: index.js,
  license: MIT,
  devDependencies: {
    @babel/cli: ^7.0.0-beta.44,
    @babel/core: ^7.0.0-beta.44,
    @babel/polyfill: ^7.0.0-beta.44,
    @babel/preset-env: ^7.0.0-beta.44
-  }
+  },
+  scripts: {
+    build: babel -d dist src,
+    start: yarn build && node dist/index.js
+  }
}

yarn start로 간단히 실행할 수 있게 되었다. 출력된 dist/index.js를 출력해보면 불필요한 트랜스폼이 싹 없이진게 보인다.

"use strict";

require("@babel/polyfill");

const name = 'World';

const main = async () => {
  console.log(`Hello ${name}`);
};

main().catch(console.error);

실제 노드 버전을 따라가게 설정했기 때문에, 다른 사람이 더 낮은 노드 버전에서 이 프로젝트를 실행하더라도 그에 맞게 호환되는 코드가 생성되서 문제없이 동작할 것이다.

Env 프리셋 사용하기 - 폴리필

하지만, 위 코드에도 여전히 문제가 남아있다. 바로 require("@babel/polyfill");이다.

무려 86KB 이다... 물론 전부 실행될 코드는 아니겠지만 적어도 동기적으로 파일을 읽고 구문 분석은 하게 될 것이다. 이거 정말 전부 require할까?

@babel/polyfill은 core-js와 regenerator-runtime을 포함하는 폴리필의 프리셋이다. 바벨 플러그인이 그렇듯 폴리필에 대해서도 역시 Env 플러그인이 스마트한 트랜스폼을 제공하고 있다.

.babelrc.js를 다음과 같이 수정해보자.

module.exports = {
  presets: [
    ['@babel/env', {
      targets: {
        node: 'current',
      },
+      useBuiltIns: 'entry',
    }],
  ],
}

useBuiltIns('usage' | 'entry' | false, 기본값은 false.)
- 'usage': 실제 소스코드에서 사용하여 필요한 폴리필만 포함하도록 트랜스폼한다.
- 'entry': 지정된 환경에서 필요한 폴리필은 일단 포함하도록 트랜스폼한다.

dist/index.js가 어떻게 바뀌는지 확인해보자.

- require("@babel/polyfill");
+ require("core-js/modules/es6.array.sort");

그렇다. 내 노드 9.11 환경에서 필요한 폴리필은 고작 Array.prototype.sort가 전부였다. 사실 실제 코드에서 sort()를 사용하지 않았기 때문에 폴리필 자체가 필요없다. usage 옵션을 사용하면 해당 구문자체가 없어진다.

종종 CRA, CRNA 같은 프로젝트를 보면 usage 옵션과 비슷한 역할을 하는 바벨 프리셋을 직접 만들어 제공하는 걸 볼 수 있는데 바벨 7으로 업그레이드 후엔 모두 순정으로 대체될 것으로 보인다.

Env 프리셋 사용하기 - 그 외 옵션들

targets와 useBuiltIns 설정으로 어느정도 최적의 설정을 가져갈 수 있지만, 가끔 다른 플러그인/프리셋 넣다가 제대로 안들어가는 경우도 있었다. (버그일 것 같은데 지금은 어떨지 모르겠다)

include와 exclude 옵션으로 예외적으로 포함/제외 할 플러그인들을 지정할 수 있다.

beta-40만 해도 있었던 몇 옵션이 안보인다. 얼마나 더 바뀔지 모르겠으니 나머지 옵션들은 정식 릴리즈 후 다시 보는게 좋을 것 같다.

모던 자바스크립트 사용하기

이제 표준은 따라 왔다. 더 나아가 아직 없는 힙한 문법도 사용해보고 싶다. 아니 데코레이터만 하더라도 이미 MobX에서 널리 쓰이고 있다.

이런 문법들은 실험적인 기능이라 프리셋단위로 제공되기엔 어렵지만 바벨에 구현된 플러그인이 있는지 여부정도는 babel/proposals에서 확인할 수 있다.

실제로 플러그인이 있는데 이 목록에 없는 문법도 몇 있다. 이름 규칙은 @babel/plugin-proposal-* 이니 NPM에서 검색해서 둘러보는 것도 좋겠다.

RxJS나 Lodash에서 활용하기 위해 파이프라인 연산자를 추가해야한다면 플러그인 단위로 추가해준다.

module.exports = {
  presets: [
    ['@babel/env', {
      targets: {
        node: 'current',
      },
      useBuiltIns: 'entry',
    }],
  ],
  plugins: [
+    '@babel/proposal-pipeline-operator',
  ]
}

Env 프리셋에 없는 것 중에도 눈에 띄는 제안들이 아주 많다.

Optional Chaining
Nullish Coalescing
Throw Expressions
Numeric Separator
Function Bind
Decorators
RegExp Unicode Property Escapes
RegExp Named Capture Groups
RegExp DotAll Flag
do Expressions
Logical Assignment Operators
Optional Catch Binding
Export Extensions

유력한 문법들이니 바벨을 통해 하나씩 미리 써보면 좋을 것 같다. 문법을 직접 쓰지 않더라도 트랜스파일된 코드를 보면 자바스크립트 코딩 패턴을 익히는데 도움이 좀 된다.

마무리하며

TypeScript나 Flow 사용하는 등 좀 더 많은 케이스 별 바벨 설정을 다루고 싶다.

그러나 자바스크립트 프로젝트는 웹 프로젝트 비중이 크다보니 바벨만가지고는 내용을 다룰 수가 없다. (React라던가...) 내용 마무리를 못할 것 같아 일단 노드와 자바스크립트로 주제를 좁히게 되었다.

Webpack 4가 내가 알던거랑 많이 바뀌었다고 하니 그 주제를 다룰 때 다시 바벨을 보게 될 것 같다. 다음엔 Webpack 4로 웹프로젝트 설정하는 부분과, Rollup을 이용해 다른 형태의 라이브러리 모듈을 만드는 것을 탐구해봐야겠다.

확실한 건 어떤 자바스크립트 프로젝트던 바벨이 포함되 있을 것이다.

임시글: React 16.3 릴리즈와 React Next 레퍼런스 모음

Wed, 04 Apr 2018 00:00:00 GMT

React 16.3 릴리즈

라이프 사이클 메서드 변경

추가

UNSAFE_componentWillMount
UNSAFE_componentWillReceiveProps
UNSAFE_componentWillUpdate
static getDerivedStateFromProps
getSnapshotBeforeUpdate

제거 예정 (16.4부터 Deprecated, 17에서 삭제)

componentWillMount
componentWillReceiveProps
componentWillUpdate

변경이유는 Async Rendering 관련 블로그에 설명됨

New Context API

내 요약은 이렇다.

Context API 는 원래 있었다.
16.3부터 정식 API 릴리즈
Context Provider를 제공하는 라이브러리들은 원래 대부분 변경 대비가 되어있다. (HOC 사용)
예를 들면 Redux의 Provider, connect()나 react-intl의 IntlProvider, styled-components의 ThemeProvider 등. 갖다 쓰는 사용자는 바꿀 것이 없다.

이제 Redux 안 쓰고 Context로 상태 전달 하면 되지 않아? 라는 흐름은 좀 이상하다. 이 아이디어를 차용해서 단일 스토어를 통한 상태관리 모델을 제공해주는게 Redux이고, 상태 전달만이 목적이라면 애초부터 Redux를 쓸 필요가 없다.

이번 16.3 릴리즈로 크게 변경된 라이브러리가 있다면 버리자. 관리가 제대로 안되고 있거나 앞으로도 그럴 가능성이 크다.

New Ref API

공식 블로그

Async Rendering

데모를 통해 리액트 Fiber에 또 다시 엄청난 성능/반응성 개선이 있는 것을 확인할 수 있다.

이번에 크게 변경된 라이프사이클 메서드 등 모두 비동기 렌더링을 언급하고 있다. immer, Redux, MobX도 영향을 받을 것이라는 언급도 있는 듯하다(제대로 확인해볼 것) 지금 시점에서 가장 주목해야 할 변경사항이라는 확신이 든다.

“Importantly, this is still the React you know. This is still the declarative component paradigm that you probably like about React.”

그리고 너무 반가워서 첨부한 인용, 내가 리액트를 쓰는 이유. 그러하다.

업그레이드 관련

<StrictMode>
자동 스크립트: 각종 레거시 패턴들을 자동으로 리팩토링해주는 스크립트가 있다. 이건 또 언제 만들어 놨지... 고맙게 ㅎㅎ

Note that if you’re a React application developer, you don’t have to do anything about the legacy methods yet. The primary purpose of the upcoming version 16.3 release is to enable open source project maintainers to update their libraries in advance of any deprecation warnings. Those warnings will not be enabled until a future 16.x release.

말그대로 16.3은 폭풍전야와 같은 릴리즈, 당장 사용자에게 다가올 변경은 미미하고 라이브러리 개발자를 위해 준비된 기간이라 할 수 있다. 여기서 관리 안되는 라이브러리 미리 걸러내지 못하면 다음 릴리즈부터 갈려나갈 것이다.

호환성 관련

하위 버전 지원을 버리지 않고 라이브러리를 업그레이드 하는 법

기타

리액트 팀이 직접 만든 외부 데이터 주입할 수 있는 라이브러리

create-subscription

주간 GitHub Stars (~ 2018/03/31)

Sat, 31 Mar 2018 00:00:00 GMT

포스팅 시간을 놓쳐서, 어디까지가 저번 주 였는지 정확히 기억나지 않는다 ㅠㅠ

Education

ossu/computer-science: Open Source Society University의 CS 코스, 대학을 안가봐서 모르겠지만 커리큘럼 기간만 봤을 때 대등해 보일 정도로 알차다. 수강자체는 무료이고 Cert취득만 유료인 것 같다.

Go

build-web-application-with-golang: mingrammer님의 번역 프로젝트. 영문 버전을 봤는데 Go 튜토리얼로도 훌륭하고, 웹 개발 전반적으로 알아야 할 것들이 많아서 번역하면서 공부해봐야지 했는데 이미 하고계셨다. 해놓으신 부분 정리되면 적극적으로 참여해보려고 한다.
gophers: 대신 귀여운 Gopher를 드리겠습니다.
soup: HTML DOM 파서, 크롤러 만들기 딱 좋아보인다.
vim-go: Vim에 Go 개발환경 세팅하기
statik: go build로 패키지할 때 에셋도 다 들어갈 줄 알았는데 아니다. 정적 에셋에 대해 파일시스템 같은 API를 제공하고 빌드 시 패키징 될 수 있도록 소스코드로 생성해주는 도구

GraphQL

graphql-react: ~~이야 로고 멋지다. 로고보고 찍었습니다.~~ Relay, Apollo 대신 쓸 수 있는 경량 GraphQL 클라이언트 라이브러리

Information

주니어 개발자를 위한 취업 정보: 국내 주니어 개발자를 위한 양질의 채용정보 모음!!
Back-End 개발자 인터뷰 질문: NESOY님의 번역 프로젝트. 백엔드 개발자 인터뷰 뽀개기
dev-meetup.github.io: PR을 통해 관리되는 국내 개발자 밋업 일정 캘린더

JavaScript

ECMAScript Pattern Matching: ES표준의 패턴매칭 제안! 리듀서 패턴에 적용한 예제가 정말 인상적이다.
tc39/proposals: ECMAScript 표준을 논의하는 TC39의 제안 저장소. 자바스크립트의 미래를 들여다 볼 수 있다!
babel/proposals: TC39의 제안 중 Babel에 제안 및 논의가 올라온 제안의 목록. 몇 개 빠진게 있는 것 같다.
tickedoff: JavaScript 콜스택에서 함수 호출을 지연하는 여러가지 방법을 소개해준다.
polyfill-service: 브라우저 폴리필 as a 서비스!! 사용자 UA 기반으로 폴리필 넣어주고 통계도 낼 수 있다니 대단하다.
puppeteer-examples: 구글이 직접 제공하는 양질의 Puppeteer 활용 E2E 테스팅 예제 모음
wait-for-expect: Expect를 지연호출하는 라이브러리. 실패를 던지기 전에 지정된 timeout과 duration동안 성공 할 때까지 반복할 수 있다.

React / React Native

react-testing-tutorial-kr: Rinae님의 번역 프로젝트. 리액트 테스팅은 관심이 많은 주제라
reducer-tester: 리듀서 테스팅 유틸리티. 리듀서 호출 전후의 상태값을 스냅샷 테스팅하는 방식.
react-native-really-awesome-button: RN 3D 버튼 컴포넌트. 버튼과 버튼 액션의 프로그레스가 합쳐진 UI를 첨보는데 흥미롭고 직관적이다.
ink: 리액트로 CLI까지 만들거라 생각조차 못했다. 이젠 정말 리액트를 웹 프레임워크 하나가 아닌 "뷰의 선언적 추상화를 위한 오픈소스 커뮤니티 기반의 API 표준" 정도로 받아들여야 한다.
ink-link: 뭔가 싶어서 봤더니 CLI 컴포넌트. ink의 존재를 알게되었다.
Under-the-hood-ReactJS: 리액트를 심해까지 살펴볼 수 있는 리소스. 모든 API와 구현을 다 뜯는다 ㄷㄷ; Jae-kwang님께서 한국어 번역을 해놓으셨다.
React Native Motion: RN 트랜지션 애니메이션 라이브러리. 데모를 보자
react-lifecycles-compat: React 16.3~ 릴리즈에서 추가되는 정적 라이프사이클 메서드를 폴리필로 추가해주는 라이브러리. 근데 이미 16.3이 릴리즈되었다.
fresh-async-react: 다가올 리액트 비동기 렌더링에 대한 신선한(?) 링크 모음
react-with-styles: AirBnB에서 선보이는 CSS-in-JS 라이브러리
ant-design-mobile: Ant 디자인 시스템의 모바일(RN) 버전

Rust

awesome-rust: 러스트 관련 리소스 모음

Tool

parrot.live: 터미널에서 cURL로 요청하면 춤추는 패럿을 볼 수 있다 :parrot: HTTP 스트림을 이해하는데도 도움이 되지 않을까?
wait-for-it: TCP 서비스 연결을 대기하는 순수 Bash 스크립트. 도커 컨테이너로 서비스 올릴 때 항상 쓰는데 nc 같은 패키지 설치가 없어도 된다.
github/licensed: GitHub에서 공개한 종속성 라이센스 검사 도구. GitHub의 Insights > Dependencies 메뉴에서 쓰는 그것으로 보인다.
go-task: Go로 작성된 태스크 매니져. Yarn으로 설정을 작성하며 Go Template으로 템플릿도 적용 가능하다. Go 프로젝트에서 쓸만한 태스크 매니져가 없어서 다 Makefile 쓰던데 이거 쓰면 될듯
youtube-dl: 유튜브 영상을 다운로드하는 CLI 도구

TypeScript

TsUML: 타입스크립트 코드베이스 읽어서 UML 클래스 다이어그램 뽑아준다. 요즘 AST에서 많은 툴링 가능성을 보고 있다. 이런 것도 좋은 예제

Web

awesome-chrome-devtools: 크롬 개발자 도구 리소스 모음

주간 GitHub Stars (~ 2018/03/24)

Sat, 24 Mar 2018 00:00:00 GMT

Awesome

Awesome Developer Streams: 스트리밍 하는 해외 개발자 모음

GatsbyJS

Gatsby RFCs: Gatsby에서 React RFCs 처럼 RFC 프로젝트를 따로 만들었다. 2.0 버전 준비의 일환으로 보이는데 잘 지켜봐야겠다.

Go

cfmt: fmt에 컨텍스트별 색깔을 입힌 라이브러리
gocraft/work: Job(Worker) 단위로 백그라운드 작업 처리를 도와주는 라이브러리
fsnotify: 파일시스템 watching 라이브러리. 근데 Go 채널 개념은 아직 잘 모르겠다.
go-humanize: Humanized Unit 라이브러리
goth: 인증 라이브러리. 인증 방식 상관없이 엄청 많은 프로바이더를 제공하고 있다. 저번 달에 프로젝트 메인테이너를 급하게 구한다고 알렸다.
golang/proposal: Go 언어의 각종 Proposal들이 등록되는 저장소

JavaScript / Node

MoveTo: 아주 쓰기 쉽고 작은, 스크롤 위치 움직이는 라이브러리
driver.js: 웹페이지의 특정 부분을 하이라이팅 하는 라이브러리, 최초접속자를 위한 튜토리얼 쉽게 만들 수 있을 것 같다.
functional.es: ES6+, 함수형, 비동기, 동시성에 대한 좋은 한글 자료
oclif: Heroku가 공개한 CLI 프레임워크. Commander, Sade는 선언적으로 CLI를 만들 수 있어 아주 편하지만 문자열 규칙을 기반으로한 "매직"이 많은 편인데, ES(or TS) Class 기반으로 한 선언적이고 구조적인 CLI 정의를 할 수 있어 쓰기 쉽고 확장성도 좋다.
chromeless: Headless browser 테스팅 프레임워크. 이제 Puppeteer 때문에 안쓰이지 않을까 싶은데...
semantic-release: 실수로 Unstar 했다가 다시 눌렀다. Semantic Versioning(aka semver) 기준으로 하여 자동화된 패키지 버전관리를 제공해준다.
NProgress: 로딩 중에 상단에 작고 이쁜 프로그래스바를 표시해주는 라이브러리.
Noderize: CLI, Express, TypeScript, Flow 등 자주 쓰이는 세팅으로 Node 프로젝트 생성해줌. 나도 나만의 프로젝트 생성기를 만들고 싶다.
gun: 실시간, 분산형 데이터베이스. 아주 쉬운 API에 자체적으로 데이터를 동기화를 해주니 redux 없이 간단한 앱이나 게임 만들 때 좋을 것 같다.
Caporal.js: commander, sade 같은 스타일의 CLI 프레임워크. 기능이 조금 더 많아 보이지만 나는 왠만하면 oclif를 쓰게될 것 같다.

React / React Native

react-dom-testing: react-dom에 포함된 test-utils의 래퍼, 작은 기본 라이브러리를 써서 테스트를 구성할 때 보일러플레이트를 줄이는게 목적인 것 같다.
react-testing-library: React 테스팅의 베스트 프랙티스를 정리하는 프로젝트. 나도 Enzyme 같은 단일 프레임웍으로 많은걸 수행하는 것보단 필요한 작은 부분들을 조합해 구성성을 높이는 것을 선호하는 편이다.
react-quill: React WYSIWYG 에디터 컴포넌트 1
pell: React WYSIWYG 에디터 컴포넌트 2 (사이즈 경쟁은 끝나지 않는다)
Timeline: 애니메이션 라이브러리. 리셋, 역재생 등 시계열로 동작하는 게 포인트인듯하다.
graphql-css: GraphQL... CSS...? Blazing Fast??? ~~이건 어디로 분류해야하나~~ 이거나 저번 gdom이나 보면 내가 GraphQL에 대한 가능성에 대해 너무 닫힌 시각을 가지고 있는게 아닌가 싶을 정도로, 생각지도 못한 아이디어가 쏟아져 나오고 있다. 어쨋든 결국 CSS-in-JS 라이브러리
jsxstyle: 또 다른 CSS-in-JS(X) 라이브러리
freestyler: 또, 또 다른 CSS-in-JS(X) 라이브러리. 무려 자신과 styleit, jsxstyle을 5th generation 이라고 소개한다.
react-router-navigation: 미치겠다 네비게이션 라이브러리가 또 있다. 원래 JSX 스타일로 사용 가능한 React Router가 끌려서 그런지 엄청 좋아보인다.
react-icons-kit: 엄청난 양의 SVG 아이콘이 리액트 컴포넌트로 제공된다.

Reason

bs-react-native: bs 플랫폼의 React Native 바인딩, RN과 Reason 둘 다 해보려는데 같이해봐도 될 것 같다.
BuckleScript: bs가 이거였다. OCaml의 js interop을 지원하기 위한 플랫폼으로, Reason의 전신이라 볼 수 있을듯 함.

Rust

yew: Rust SPA 프레임워크. JSX와 유사한 형태의 템플릿을 사용하고, WASM으로 컴파일된다고 한다.

Tool

fossa-cli: Node 프로젝트의 오픈소스 라이센스를 스캔해주는 Fossa 서비스의 CLI 도구
marktext: 내가 본 것 중 가장 글쓰기에 최적화되어있는 마크다운 에디터
awesome-finder: CLI로 원하는 Awesome 리스트를 검색하자

TypeScript

pattern-matching-with-typescript: 패턴매칭이 없는 자바스크립트/타입스크립트에서 패턴매칭을 "구현"하는 방법에 대한 설명, 그리고 엄청난 보일러플레이트... 하지만 패턴으로써 참고할 가치가 보인다.

Vim

vim-f-hangul: vim에서 f로 한글 초성 검색하기

Web

package-name-maps: 브라우저에서 Node의 모듈을 지원하려고 할 때 생기는 각종 문제에 대한 고찰. 결국은 package.json내지 번들러의 module resolver 역할을 할 새로운 스펙이 필요한 것으로 보인다.
WebAssembly Studio: 다양한 언어로 웹 어셈블리 프로젝트를 체험할 수 있는 웹 IDE이다.

Zsh

zsh-yarn-autocompletions: zsh에서 yarn 커맨드 auto-completion 지원

ETC

language-server-protocol: MS에서 VSCode를 만드는데 사용된 설계의 일부분을 따로 정리해놓은 것으로 보인다. 여러 언어를 지원해야하거나 이미 언어 서비스가 구현되어 있는 상태로 개발환경을 만들 때 구조를 참고할 수 있을 것 같다.
lighthouse-badge: Lighthouse 뱃지! README에 점수 넣고싶긴 한데 README 수정까진 CI에서 자동화하기 좀 어려울 것 같다.
10th-amendment: @devunt님 께서 대한민국 헌법 개정안을 한 눈에 보기 쉽게 웹페이지로 만드셨다.

주간 GitHub Stars (~ 2018/03/17)

Sat, 17 Mar 2018 00:00:00 GMT

Go

learn-go-with-tests: 테스트와 함께 배우는 Go 언어 튜토리얼

JavaScript / Node

money-clip: 특이한 이름의 클라이언트 사이드 캐시 라이브러리이다. idb-keyval 이라는 IndexedDB 래퍼에 캐시 버저닝과 TTL 기능을 추가했다고 한다.
devalue: JSON.stringify의 대안 라이브러리. JSON.stringify에서 지원하지 않는 출력형식을 지원한다.
ecoji: Base1024 인코딩 엌ㅋㅋㅋㅋㅋ
axios-extensions: 일반적으로 원격 요청할 때 클라이언트 단에서 쓰로틀 방지 지연 요청이나, 응답 캐시 등 일반적인 구현 요구사항이 있는데, Axios adapter API를 이용한 확장. 그대로 쓸 수 있을 거 같진 않지만 참고해서 만들기 좋을 것 같다.
axios-mock-adaptor: 마찬가지로 adaptor 이용해서 응답 모킹하는 라이브러리. 이외에도 moxios라는 공식(?!) 라이브러리도 있더라. 음? axios는 nock으로 모킹이 안되나? 싶어 찾아봤더니 이런 이슈가 있다.
Awaity.js: Bluebird의 대안 라이브러리. Node에 내장 Promise가 있지만 추가 오퍼레이터 지원이 있는 Bluebird가 약간 끌리긴 했는데 좋은 대안인 것 같다. 좀 더 가볍고, Promise 프로토타입에 비표준 메서드를 추가하지도 않고, 동시성 제어를 지원하면서, 펑-셔널 스타일도 지원한다.
TsMonad: TypeScript를 이용한 모나드 컨테이너 라이브러리, 사실 모나드가 뭔지 몰라서 일단 찍었다.
Rough.js: 도형이나 패쓰를 손그림 스타일로 그려주는 캔버스 라이브러리
NPM Install Webpack Plugin: 진정한 HMR의 완성이 아닌가..
javascript-debugging-example: Subicura님의 자바스크립트 디버깅에 대한 예제 프로젝트.
Emma: Yarn Add 어시스턴트 CLI

Knowledge

Writing-IT-Books: 한빛미디어의 프로그래밍 책 집필 가이드북
Programmer's Proverbs: 프로그래머 격언 저장소

React / React Native

react-fiber-architecture: 리액트 16에서 싹바뀐 코어 아키텍쳐, 일명 Fiber에 대한 설명이 있다. 나중에 꼭 읽어봐야지하곤 일단 킵
React Native Fundamentals Slides: 리액트 네이티브 관련 슬라이드, 빌어먹을 키노트 파일로 올라와 있어서 변환이 필요하다. 내 경우엔 감사하게도 커뮤니티 분이 해주셨지만 만약 변환해야한다면 온라인 변환기를 쓰자. ppt로 변환하면 깨지고, pdf나 html로 뽑으면 잘 나오더라.
react-patterns: React와 함께 자주쓰이는 패턴들 정리
react-af: React 차기버전 호환성 라이브러리, 각종 Deprecation이나 예정된 신규 API들을 미리 사용할 수 있다. 라이브러리 개발자들에게 도움된다고 함.
react-data-fetching: Render props 패턴을 간단한 Data fetching에도 적용해보기 :thinking_face:

Reason

parcel-reason-react: Parcel + Reason + React 프로젝트 보일러플레이트

Rust

neon: Rust의 Node.js Native 바인딩. 네이티브 모듈 Rust로 만드는거 상당히 끌린다.

Server

frp: 리버스 프록시 전용 서버, 다양한 로레벨 프로토콜을 지원하고 설정도 쉬워보인다. ~~정부의 검열에 시달리는 중국의 개발자가 프록시를 만들었다니 묘한 신뢰가~~

Tool

html-minifier: HTML 압축, 이미 minimize 되있는거 돌려봤는데 확실히 더 줄어든다. 옵션도 많다.
fkill-cli: Goodbye lsof

TypeScript

typewiz: 타입 어노테이션 생성기. 지원안해주는 지연타입추론을 이런식으로 해결할 정도로 TS 커뮤니티 파워는 크다. ~~Flow 사용자는 또 웁니다~~
typescript-starter: 타입스크립트 보일러플레이트 생성 CLI

Web

WebFundamentals: 구글의 PWA 베이스 지식과 베스트 프랙티스 모음

주간 GitHub Stars (~ 2018/03/10)

Sat, 10 Mar 2018 00:00:00 GMT

Application

sourcerer: GitHub 활동을 분석해서 개인 프로필 만들어주는 서비스
mattermost-mobile: Slack 대체 오픈소스 Mattermost의 모바일 앱.

Front-end

FEDevelopers/tech.description: 한국어 프론트엔드 위키 저장소
frontend-case-studies: 엔터프라이즈 벤더 별 프론트엔드 기술 아티클 모음
Front-End-Wizard: 프론트엔드 리소스 모음, 분류가 이쁘게 잘되있다.

Go

go-perfbook: Go 언어 성능최적화 꿀팁 모음
go-internals: Go 내부에 대해 설명하는 시리즈
gopher-reading-list: Go 읽을거리 모음
project-layout: Go를 하면 찾아해맬일이 없다. 왜냐? 뭘 찾던 스탠다드가 있을테니까!

GraphQL

How To GraphQL: GraphQL 풀스택 튜토리얼

Site

strml.net: 정말 신박한 홈페이지, 사이트가 자기자신을 직접 라이브코딩, 데모를 한다.

Editor

atom/xray: 성능에 좋다는건 다 끌어다 쓰는 차세대 에디터 프로젝트. 성능을 추구하는 면에선 구글의 xi-editor 프로젝트(차세대 vi)와 유사하지만 프론트엔드는 Atom을 대체할 사용성을 추구한다는 점이 다름 (두 개를 합치면..?)

JavaScript / Node

Awesome

awesome-nodejs: NodeJS Awesome 리스트

Framework

stencil: 웹 컴포넌트 프레임워크

Library

TSTL: TypeScript 라이브러리, C++ STL의 향수
caminte: 노드 Cross-db ORM, 굉장히 많은 종류의 설치형DB들을 하나의 인터페이스로 지원한다.

Testing

jest-puppeteer: Jest로 Headless Chrome 테스팅하기, DOM 테스팅에도 쓸 수 있는 건 아닌듯..
jest-puppe-shots: 아닌 줄 알았는데 누가 만들어 놨다. 생성한 페이지에 리액트 컴포넌트 마운트 후 스크린샷 까지!

Tool

pkg: Node 바이너리 패키징 도구, 알고만 있다가 첨 써봤는데 엄청 편하다. 거의 go build급
dts-gen: TypeScript .d.ts 생성기. 이런거 있는 줄 몰랐따, flow-typed 보다 한 술 더 떠서 모듈 내부 구조까지 전부 읽어 생성하는 듯

Language

PureScript: 함수형, 강타입, 자바스크립트로 컴파일되는 언어. 커피랑 엘름이랑 섞어놓은 것 같은데 쉽고 직관적인 것 같다만, 생태계가 아직 작다.
reason-react: JavaScript와 OCaml이 호환되는 ML언어, 생태계가 크고, React를 쓸 수 있다는게 굉장히 매력적이다.
awesome-reasonml: ReasonML의 Awesome 목록

React / React Native

victory: D3기반 리액트 svg 차트 라이브러리
victory-native: victory의 리액트 네이티브 버전
urql: GraphQL 클라이언트 컴포넌트 라이브러리
react-motions: React 애니메이션 라이브러리, 추상화된 인터페이스보단 자주 사용되는 애니메이션을 제공하는 방식
react-native-filesystem-v1: React Native 파일시스템 라이브러리
dooboo-native: React Native Seoul 밋업의 dooboolab님이 만드신 RN 프로젝트 보일러플레이트 생성 도구, CLI까지 만드셔서 Zero-configuration을 실천하시는 것 보고 감탄..
react-native-easy-grid: RN 그리드 레이아웃 컴포넌트
react-native-calendars: 캘린더 컴포넌트
aurora-imui: IM UI 프리셋 라이브러리, gifted chat이 메시징 컴포넌트라면 여긴 이미 컴포넌트 조합이 된 상태. 간단한 채팅앱을 이걸로 만들어보면.... 의미가 없지않나?
rn-styled-components-performance: 궁금증 해결, RN에서의 styled-components는 내장 StyleSheet보다 느리다고 알려져 있는데, 그것에 대한 벤치마크
awesome-react-native-native-modules: RN 네이티브 모듈 Awesome 리스트. Android, iOS 뿐 아니라 Windows 까지도 같이 지원되는 모듈이 있는게 놀랍다.
markdown-to-jsx: React 마크다운 렌더링 컴포넌트, 안에 리액트 컴포넌트 오버라이딩까지 지원한다니 내가 찾던 그거(mdx)다.
react-native-markdown: RN 마크다운 렌더링 컴포넌트, 이 때까지 찾아본거론 아직 그닥 쓸만한 게 없다.

Tool

git-sizer: Git 레파지토리(Workspace가 아니다) 분석 도구
onlang: 언어간 트랜스파일러, 하나의 언어로 코드를 작성하면 다른 언어들로 트랜스파일해준다.
fac: CLI 컨플릭트 머지 툴, 항상 CLI써도 머지할 땐 GUI 툴을 쓰곤 했는데, 쓰기 편한 CLI 머지툴이라니 머지할일 생기면 한 번 써봐야지

WebAssembly

webassembly-examples: MDN에서 제공하는 웹어셈블리 예제들
iswasmfast: 무조건 더 빠른건 아니다, 웹어셈블리 성능 벤치마크

뒤늦게 돌아보는 2017년, 그리고 2018년 계획

Sat, 03 Mar 2018 00:00:00 GMT

2017년을 돌아보며

나는 한 해에 무슨 일들이 있었는지 일일히 기억할 만큼 기억력이 좋지 않다.

회고는 적어 볼 엄두도 못내고 있었는데, 문득 제작년부터 트위터에 의식의 흐름을 풀어놓던게 떠올랐다. 트위터 타임라인을 찬찬히 살펴보니 드문드문 기억이 되살아나는 느낌이들어, 늦었지만 지난 해를 회고해보고자 한다. ~~트위터가 이렇게 이롭습니다~~

의식 흘러가는데로 쓰고보니 회고라기 보단 밀려쓰는 일기 같아졌다. 뭐 어쩌겠는가 이렇다 할 데이터 안남긴 내 잘못이지.

2017년의 가장큰 변화는 자바스크립트, 리액트와 친해진 것이다.

그 전 까진 자바스크립트라면 JQuery 밖에 모르던 나는 업무의 일환으로 리액트 코드베이스를 리버싱하는 것을 계기로 리액트에 푹 빠지게 됐다. 그러면서 본격적으로 자바스크립트와 웹도 공부하게 됐으나... 만만한 길은 없다고 했던가, 2016년에 자바스크립트를 배우는 기분을 2017년 버전으로 느껴야 했다.

그래도 새로운 모던 자바스크립트(ES6+)를 배우는 것은 매우 즐거웠다. 나는 학교에서 친구들이 C++ 98 스펙으로 프로젝트를 할 때 혼자 모던 C++(11/14) 문법을 파고, 약을 팔러 다녔던 전적이 있는데 왜 항상 이런 쪽으로 빠지는 건지 모르겠다. 깊게 생각해본 적은 없지만 아마 모던 언어가 제시하는 새로운 패러다임이 시선을 넓혀주는 느낌을 좋아하는 것 같다.

다만, 관심사가 분산되면서 그 전에 파던 DevOps/인프라에 대해 소홀해졌다. 정리해서 남겨둔게 없기 때문에 언제 다시 파보나 하는 불안감이 있다.

어쨋든 계기가 되준 오픈소스 프로젝트에는 간간히 기여를 했다.

이슈 리포팅, 번역, 문서화, PR등 조금씩 해보다가 내 힘으로 "첫 삽"을 떠보고 싶다는 욕심에 NPM 모듈도 올려보았는데 생각보다 주목받지 못한데다가 이 후엔 누가 중복작업을 하고있었다. 여럿이면 뭘하던 커뮤니케이션이 가장 중요한 것 같다.

어쨋든 별거 아닌 것 같던 내 자그마한 기여로 멋진 티셔츠까지 얻었다.

이쁘다 ㅎㅎ Mattermost는 아니고 Hacktoberfest에 신청해서 받은거긴 하지만 PR은 전부 Mattermost 관련이였으니까, 그리고 Mattermost 머그컵이랑 티셔츠는 이미 제작년에 다 받아버렸으니까. (그런데 겨울이라 반팔티는 못입고 그렇다고 여름에 10월이 테마인 티셔츠 입는 것도 뭔가 이상하다)

이것저것 해보는 와중에 11월이 되었고, 길게 묶었던 머리를 자르고 훈련소에 4주간 다녀왔다. 4주내내 수면부족과 허리통증에 시달렸다. 사격훈련은 나름 재밌었다. 동기 분대원들은 모두 좋은 사람들이였지만, 공통관심사가 거의 없어 사회에서 계속 연락하진 않는다. 사실 이해관계나 관심사 제쳐두고 친구를 만들 수 있으면 좋겠지만 쉽게 그러지 못하는 성격이라 아쉬울 따름이다.

일 얘기는...

아껴두는게 좋겠지만 까먹을지도 모르니까 조금은 적어놔야겠다.

한 가지 확고해진건, 개발자가 되고싶다라는 생각.

솔루션 회사에 다니면서 내가 이해하고 있던 업무는 어떠냐하면, 그래도 "문제가 생기면 해결하면 된다"는 것이다. 접근 방식은 아무래도 리버스 엔지니어링에 가깝기 때문에 개발자의 그것과는 거리가 있지만, 어쨋든 문제해결 자체에 성취감을 느끼니까, 개발은 취미로 계속하면 되니까 상관없다고 생각했다.

그런데 내가 "문제 해결"을 계속할 수록 뭔가 어긋나는 느낌이 들었다. 아무도 문제가 터지기 전까진 내 생각(직접 Best Practice를 만들어 제공하는 것)에 동의해주지 않았다. 회사의 비즈니스는 철저하게 "영업"이였고, 내가 고객의 문제를 고민하는 것은 회사 입장에선 아무 득도 안되는 재능기부로 보이는 듯 하다.

어쨋든 문제 해결의 일환으로 코드를 자주 만지다 보니까 이제 팀에선 개발자로 불리지만, 사실 내 업무는 해킹이지 개발은 결코 아니다. 남는시간에 개발 공부한다고 해서 내가 어디가서 개발자라고 자처할 수 있을까?

2018년엔 뭘할까

이 글을 쓰고 있는 시점에서 벌써 3월이 되었다. 해보고 싶은 건 많은 듯 하면서도 아직 이렇다할 성과가 없는데, 한 번 확실하게 목록을 정리할 필요가 있는 것 같다.

지금 주어진 업무를 계속해도 만족스러운 이력은 안남는다. 그렇담 훌륭한 신입 개발자가 되기 위해선, 뭘 해야할까?

블로깅

요새 한창 GatsbyJS로 블로그를 만들고 있다. 직접 만드는 것도 좋지만 사용하지 않으면 의미가 없다.

대략 2주에 한 번은 포스팅하는 걸로 목표를 잡아보자.

오픈소스

내게 영향을 준건 8할이 오픈소스이다. 나도 오픈소스에 뭔가 공헌해야 바람직하다. 훌륭한 기회를 주었던 Mattermost에 기여가 많이 뜸해졌는데 이참에 바로잡아야겠다.

한국어 번역 100%
Help Wanted 이슈 10개 이상 닫기
3rd-party 기여 1개 이상
한국에 Mattermost 홍보하기

그리고 이왕이면 다른 오픈소스 프로젝트에도 한 번 참여해보고 싶다.

더 깊게, React / React Native

역시 현업 프로그래머분들이라 그런가 리액트로 앱하나 뚝딱 만드시는 것들을 볼 때마다 놀라곤 한다. 리액트에 대해 어느정도 안다고 생각하다가도, 나는 한 번도 저런 생산성을 가져본 적 없다는 사실에 좌절한다.

문서와 업데이트를 열심히 보는 것도 좋지만, 진짜 서비스를 만들어봐야 겠다.

리액트 기반으로 서비스 하나 이상
리액트 네이티브 앱 하나 이상

사이드 프로젝트

리액트 관련 외에도 몇 가지 사이드 프로젝트 생각하던게 있는데 다 할 수 있을진 모르겠지만 일단 올해 목표로 적어둬야 겠다.

Windows 내장 Sticky Notes 부가기능: 예전에 이거 쓰다가 너무 불편한데 다른 앱 깔기 싫어서 하던 프로젝트가 있다. 하다 말았는데 아무래도 완성해보고 싶은 주제 중 하나이다.
WebGL 2D Game Framework: 학교에서 게임 개발 공부할 때 2D만 팠다. GDI+로 한 번, DX9으로 한 번, cocos2d-x로 한 번. WebGL 공부하는 겸 2D게임 프레임웍 한 번 만들어보면 어떨까. 놀랍게도 아직 최신문법을 사용하는 프레임웍은 찾아보기 어렵다. TypeScript로 만들어보면 좋을 것 같다.

새로운 프로그래밍 언어

Go: 지금도 살짝살짝 보고 있긴한데 엄청 만족스럽다. 생산성이 나오는 수준까지 파보려고 한다.
함수형 언어 1개: 아예 Haskell을 파보거나 아니면 Elm, ReasonML 같은 JavaScript Interop이 지원되는 언어 중에서 하나 파볼 생각이다.

네트워킹

이 때까진 너무 히키코모리로 지냈지만 기회는 집밖에 있으니까, 좀 밖에도 돌아다니고 해야겠다.

개발자가 있는 모임에 참석해서 지식도 전수받고, 혹시 내가 공유할 수 있는게 있다면 공유하면서.

주간 GitHub Stars (~ 2018/03/03)

Sat, 03 Mar 2018 00:00:00 GMT

Application

shiori: Go로 작성된 Pocket의 Open Source Alternative

Awesome

Font

블로그용 폰트 찾기

Framework

flutter: 구글의 모바일 앱 개발 프레임웍 Beta 1.0 릴리즈, Dart 안버렸구나...

Game

samccone/tiny-games: 다른 건 아니고, 트랜스파일 된 코드가 트윗 280글자 안에 들어간다... (261자 나옴 ㄷㄷ)

Go

gorp: Go언어 ORM 라이브러리

GraphQL

gdom: GraphQL로 DOM 쿼리하기, 발상이 대단하다
graphql-js/graphene: GraphQL Schema 쉽게 정의하기

Javascript / Node

funkia/list
immer: ImmutableJS의 대안, 더 나은 API, 평균적으로 더 나은 성능
AlgorithmVisualizer: 자바스크립트로 만든 각종 알고리즘 비주얼라이제이션
shelljs: Javascript 포터블 유닉스 쉘 구현체. Node API를 이용해 각종 쉘 명령어들을 API로 제공하는데 엄청 사용하기 쉽고, OS 상관없이 잘 동작한다고 한다. ~~희망사항 아님?~~
xstate: Functional, stateless JavaScript finite state machines and statecharts. ~~근데 FSM이면 Stateless가 아니잖아~~
turbo-http: Node low-level http 라이브러리, 노드 코어의 http 모듈보다 10배가량 빠르다고 주장한다.
dom-to-image: Canvas를 이용해서 DOM 엘리먼트의 이미지 스냅샷을 만든다. 근데 Chrome Dev Tools API에 이미 기능이 있었던 것 같기도 하다.

ECMAScript Propasal

proposal-slice-notation: 파이썬의 그 slice notation

React / React Native

react-native-elements: RN Traning UI 컴포넌트 라이브러리
react-native-navigation: 사실상 표준인듯 하다.
react-easy-param: 복잡한 라우팅 필요없는 매우 작은 앱을 만들 때 쓸만할 것 같다.
react-morph: UI 트랜지션 라이브러리, 대박인 듯
lottie-react-native: Airbnb의 애니메이션 라이브러리

React Native 코드 웹에서 실행하기. 데스크탑은 일렉트론으로 올리면 되니까 이정도면 현실적인 멀티플랫폼인가?

Tool

babel-upgrade: Babel 7을 준비하자!
web-tooling-benchmark
gitleaks: git에 민감한 정보 넣지 말자
acme.sh: ACME 클라이언트 UNIX Shell 구현체 (즉, zero dependencies)
slackin: slack 초대 자동화, 깔쌈한 UI와 뱃지 제공
node-gh/gh: GitHub Client CLI! 역시 CLI가 최고다!!

UI

responsive-components: CSS 참고거리로 딱좋음
primer: GitHub의 CSS 컴포넌트 라이브러리. 깃헙을 만들 수 있다.
filepond: JavaScript 파일 업로드 컴포넌트, 애니메이션이 화려하다.

Web

Web Share API 제안과 그 구현체

Web Clipboard API 제안

w3c/clipboard-apis

나만의 블로그 개발하기 - 0. 플랫폼 선정

Sun, 25 Feb 2018 00:00:00 GMT

블로그 플랫폼은 Gatsby + Netlify입니다.

Gatsby는 무려 React와 GraphQL을 사용해 엄청나게 빠른 퍼포먼스의 사이트를 빌드해주는 정적사이트생성기이고 Netlify는 정적사이트의 호스팅과 사이트 관리 기능을 제공하는 서비스입니다.

개발 중인 블로그의 소스코드와 포스트는 100% 오픈소스로 라이센스 동의 하에 자유롭게 사용 및 의견 제시가 가능합니다.

들어가며

2018년이 되어 블로깅에 도전, 부끄럽지만 원래는 2017년 신년계획이였다.

이전에도 수 차례 워드프레스로 블로그를 구성하거나 운영해보긴 했으나 테마나 플러그인을 탐색하는데 시간을 들이면서 기술적인 향상을 기대하기도 어려웠고 워낙 게으른 탓에 포스팅도 안하는데 호스팅 비용이 아까워 금방 내리곤 했다.

자칭 웹 개발 공부한다면서 블로그 하나 없으면 안되지, 배운게 안남는 것도 문제고, 돈 안들이고 다시 시작할 방법이 없을까. 가만보니 개발자들은 다들 정적 사이트 생성기로 기술 블로그 만드는게 유행하는 것 같아서 나도 따라해보기로 했다.

Static Site Generator

잘나가는 개발자들은 다들 GitHub Page로 정적 사이트 하나쯤은 올려두는 것 같다. 이유는 다양하겠지만 일단 평소에 마크다운과 Git을 자주 사용하는 개발자라면 평소에 쓰던 마크다운 에디터 하나로 CMS를 대체하기 충분하기 때문일 것이다.

가장 인기있는 생성기는 Jekyll지만, Ruby 언어로 되어있기 때문에 남들이 만들어놓은 테마나 플러그인만 끄적이면서 시간 보내지 않으려면 Ruby를 본격적으로 공부하거나 다른 생성기를 찾아야 할 것 같았다.

어차피 사이트에 자바스크립트는 들어갈테니 요새 파고있는 리액트로 직접 만들면 어떨까 싶었지만 싶었지만 이 경우 서버사이드렌더링이 꼭 필요했다.

두번 렌더링한다구요? 네.

사실 서버사이드렌더링은 SPA의 장점을 포기하고 리액트를 템플릿 엔진처럼 사용하는 방법이라고 착각하고 있었지만, Subicura님의 블로그 글을 읽고 제대로 이해하게 됐다.

하지만 리액트 한 번 써보겠다고 블로그에 백엔드까지 추가하기엔 배보다 배꼽이 더 커지는 것 같다.

GatsbyJS

Blazing-fast static site generator for React

기막히게 빠른 정적 사이트 생성기

한 트친님이 Gatsby로 블로그를 새단장 하셨다는 소식을 보게 되면서 Gatsby의 존재를 알게 되었다.

Gatsby는 무려 React + GraphQL 조합으로 정적사이트를 만든다. 동작방식은 대략 이렇다.

그래프 형태의 데이터 인터페이스를 제공한다.
데이터 노드를 구성한다. 프리셋인 플러그인을 통해 확장할 수도 있다.
구성한 데이터를 GraphQL로 쿼리해서 페이지 코드에서 사용한다.
사이트의 모든 페이지를 사전에 렌더링하여 경로에 index.html을 생성한다.

이렇게 해서 서버사이드렌더링을 적용한 리액트 앱과 완전히 동일한 수준의 정적사이트가 만들어진다. 렌더링을 위한 추가 백엔드 없이 웹서버와 CDN에 업로드하는 것 만으로 사용할 수 있으며 SPA를 지원하지 않는다고 알려진 GitHub Pages를 사용하는 데에도 문제가 없다.

이미 많은 사이트/블로그들이 사용하고 있어서 커뮤니티도 제법 크고 활발하다. 대표적으로는 React 홈페이지도 Gatsby를 사용한다.

yarn global add gatsby-cli
gatsby new [PROJECT_NAME] [URL_OF_STARTER_GIT_REPO]

제공되는 CLI와 Starter 목록을 사용하면 아주 쉽게 시작할 수 있다.

나는 최대한 가볍게 시작하기 위해 기본 + Typescript 구성이 조금 추가된 스타터를 사용했다. (이 스타터는 더 이상 관리가 안되는 것 같으니 참고)

Netlify

Deploy modern static websites with our automated platform. Add best practices like SSL, CDN distribution, caching and continuous deployment with a single click.

자동화된 정적 웹사이트 배포 플랫폼. SSL, CDN, CI/CD를 클릭 한 번에!

Netlify는 정적 사이트를 호스팅해주는 것은 물론, 자동 빌드/배포, DNS, SSL, CDN 설정 등 온갖 자동화된 사이트 관리 기능들을 무료로 제공한다.

Node, Ruby, Python 빌드를 지원하기 때문에 GitHub Pages처럼 직접 빌드하고 업로드 할 필요가 없다.

스크린샷처럼 GitHub / GitLab / BitBucket 계정으로 연결한 후, 소스가 있는 레파지토리를 선택한다. 배포할 브랜치, 빌드 스크립트, 사이트 Output 디렉토리를 선택하면 기본적인 설정이 끝난다.

이 후 사이트 관리에서 DNS, SSL 등을 설정할 수 있는데 이 부분도 대부분 자동화 되어있기 때문에 어렵지 않게 사용할 수 있다.

1분이면 리액트로 멋진 사이트를 만들 수 있으니 위 버튼을 눌러 시작해보자.

Hyeseong's Blog

컨텐츠 압축을 위한 배경지식

손실 압축 vs 비손실 압축

비손실 압축 형식 살펴보기

Deflate / Gzip / Zlib

Brotli

LZMA

LZO

Snappy

LZ4

Zstandard

HTTP와 압축

HTTP 컨텐츠 협상과 압축

End-to-End vs Hop-by-Hop 압축

Content-Type 헤더와 CDN 압축

HTTP 헤더 압축

와이어 형식과 압축

XML / JSON

MessagePack / CBOR

Protocol Buffers / Flatbuffers / Cap'n Proto

압축을 적용하기 전에

시스템 특성 고려하기

구현 품질 검토하기

압축 사전 제공하기

보안 고려사항

레퍼런스

아이덴티티 시스템의 7가지 원칙

The Laws of Identity

레퍼런스

오픈소스 프로젝트에서 배운 코드리뷰

코드리뷰를 마주하는 자세

좋은 PR, 나쁜 PR

성장에는 책임이 따른다

커리어의 첫 장을 넘기며

나의 첫 이력을 돌아보며

웹 개발자로 다시 경력 쌓기

새로운 도전을 찾다

다음 장의 아웃라인을 잡다

시작하며

워드프레스 닷컴 마이그레이션

워드프레스 닷컴과 구텐베르크 에디터

비즈니스 플랜의 특권: SFTP와 phpMyAdmin

원클릭 마이그레이션

사이트 가져오기 중 주의사항

마이그레이션 시 주의사항

플러그인 호환성

커스텀 플러그인/테마 마이그레이션

커스텀 스타일시트 마이그레이션

미디어 URL 마이그레이션

SFTP

부록: CMS와 가격대에 대한 이모저모

TypeScript 튜플 타입 요리하기

튜플의 특징

함수 시그니쳐와 튜플

타입레벨 재귀와 순회

Variadic Tuple (+ v4.0)

Flow의 $TupleMap 시뮬레이션 하기

마무리하며

Jamstack에서 스타일시트를 최적화하는 법

기술적인 맥락

GatsbyJS SSR

Zero-runtime CSS in JS

gatsby-plugin-linaria

Critical rendering path와 CSS Extraction

Zero-runtime의 Trade-off

gatsby-plugin-linaria의 선택

마무리하며

GraphQL is not just a network protocol

예제 프로젝트: HackerNews Client

Apollo Link

더 나은 스키마

리졸버 구현하기

리졸버 옮기기?!

API 확장하기

클라이언트 상태 저장하기

REST API, Redux와의 비교

큰 그림 이해하기

GraphQL Anywhere

Prisma

FaunaDB, EdgeDB

`Content-Type` 헤더와 CDN 압축