This month I Learned - 2020년 8월2020/08/31

General

• 개발자와 PM이 (매우) 사이좋게 잘 지내는 방법

  • 회사에 전업 PM 포지션이 없고 팀 단위로 실무자들이 뭉쳐 의사결정이 이루어지다보니 이 글을 참고할 일이 별로 없었으나, 점차 규모가 커지면서 PM 역할을 전문적으로 수행하는 분과 함께 일을 하리라고 생각한다. 아니면 미래의 내가 되거나.
  • PM을 향한 조언 키워드로 폭넓은 시야, 수용성, 공감 능력, 데이터를 기반으로 한 의사결정 등이 눈에 띄고
  • 개발자를 향한 조언 키워드로 (마찬가지로) 폭넓은 시야 및 공감 능력 뿐 아니라 릴리즈 플래닝을 지키고 ~“문제를 즉각적으로 알려주어야 한다”~ 는 부분이 눈에 띄었다.
  • 나도 새로 오신 초보 동료분들에게 강조하고, 나 자신도 실수하지 않도록 조심하는 부분인데 문제를 즉각적으로 알리는 것은 아주 중요하다. 문제를 알아야 다 같이 머리를 맞대고 해결을 할 수가 있는데 모르면 도움을 줄 수가 없으니까. 문제가 있다고 나를 쥐잡듯이 잡는 조직에 있다? 그렇다면 그 조직에 내가 있을 가치가 있는지도 고민해볼 필요가 있겠지.

• 음악을 만들어봅시다 | GeekNews

  • 음악을 좋아하고, 취미로 피아노를 연주하다보니 언젠가 살면서 나만 듣고 만족할 수 있는 곡을 직접 지어보고 싶다는 꿈을 가지고 있다.
  • 그런 와중에 이런 글을 보고, 실제로 체험해보니 너무나 재미있었다. 아이패드용으로 음악 연주가 가능한 런치패드 앱들을 가지고 있음에도 불구하고 한번도 손을 대 본적 없다가, 이 글을 계기로 다시금 관심이 생기기 시작했다.
  • 브라우저에서 배울 수 있다는게 중요한 포인트라고 생각한다.

• How Might We

  • 회사에서 일을 하면서 만들고 있는 제품에 대해 심층적인 고민이 필요하다는 팀원의 의견이 있어, 팀원 모두 머리를 맞대고 본격적으로 고민을 하기 시작했다. 사용자에게 어떻게 더 좋은 경험을 전달해주려면 어느 부분이 어떻게 더 나아져야할까?
  • ”~~ 라면 ~~할까?” 라는 방식으로 브레인스토밍을 하는 방법이라고 이해했다.
  • 결과적으로 다양한 방법들을 시도했지만, 디자이너분들은 이 방법론도 시도한다는 이야기가 있어서 한번 적용해보고자 도전하긴 했지만, 익숙하게 이 방법을 활용하진 못했다.

• 인스파이어드

  • 회사에서 시니어 PM 같은 역할(?)을 맡고 계시는 David의 정기 독서 정리. “인스파이어드” 라는 책이다.
  • “제품 로드맵의 문제”, “제품 원칙”, “팀 내외로 설득하는 법” 부분이 인상깊었다.

• What is Product Led Growth? How to Build a Software Company in the End User Era | OpenView

  • SasS로 밥 벌어먹고 사는 회사들이 어떻게 성장을 할 수 있는지 살펴볼 수 있는 좋은 글.

  • 엔드유저에게 제품을 어떻게 공급하는가?

    • 제품을 사용자가 사는 지역에 공급하기
    • 시작하기 쉽게 만들기
    • 돈 걷기 전에 가치를 전달하기
    • 세일즈는 마지막에 고용하기

Developer

• 크롤링과 저작권 침해 고소 진행 일대기 :: Philosophiren

  • 우리나라만에서만 이런 인식이 팽배한 것인지 모르겠으나, 저작권 의식이 부족한 상태에서 무분별하게 크롤링을 할 시 책임을 져야 한다는 사례를 다시 한번 보여주는 글이다.
  • 이전 회사에서도 경쟁업체가 숙소정보 등을 무단으로 크롤링해갔다가 경쟁업체의 대표가 집행유예 판결을 받은 사례도 있었다.
  • 토이 프로젝트에서라도 크롤링을 할 일이 있다면 자신이 크롤링하는 대상의 저작권에 대해 신중하게 파악한 뒤에 작업을 하는 것이 좋을 것이다.

• Banksalad Product Language를 소개합니다 | 뱅크샐러드

  • 글을 읽으면서 탄성을 멈출 수 없었다. 제품 만드는 과정이 아주 멋져 보였기 때문이다.
  • 모든 직군의 제품 개발자들이 하나의 통일된 언어를 만드는 과정 속에서 어려움이 많았을 것 같은데, 그게 성공하고 나서 어떤 이득을 얻었는지 예제를 통해서도 손쉽게 볼 수 있었다.
  • 다만 이런 방법론을 내가 바로 적용하기엔 현실적인 어려움이 뒤따른다는 것이 아쉽지만… 차근차근 이런 도전을 할 기회를 잡아서 시도해보고 싶다.

• Mozilla의 불확실한 미래 | GeekNews

  • 모질라의 미래는 안좋은쪽으로 가는게 많이 예견되고 있지만… 공공을 위한 웹을 위해서라도 브라우저 선택지가 최소한 지금 수준만큼(Chromium, Firefox, Webkit)이라도 남아있기를 희망한다. 이 글을 읽어보면 그러긴 어렵겠지만.

• GPT-3, 인류 역사상 가장 뛰어난 언어 AI – 핑퐁팀 블로그

  • AI 에는 별로 관심이 없는 편이었지만 GPT-3 라는 키워드가 내 주변 타임라인에 많이 잡히기 시작하면서 관심이 생기기 시작했다.
  • 이 글은 GPT-3가 무엇이고 어떻게 활용되고 있는지 잘 정리해주어서 GPT-3 가 어떤 방향으로 발전하고, 다른 제품에 활용될 수 있는지 기대를 안겨주었다.

• ADR을 써야 하는 이유 | GeekNews

  • 한 프로젝트를 오래 붙들고 있다 보면, 자연스럽게 ‘왜 이런 식으로 코드를 짰었더라?’ 하는 순간이 오게 된다. 회사 프로젝트의 README가 잘 관리하기 어려운 것 같아 노션으로 프로젝트의 관련 문서를 작성하고 있었는데, 가능하면 코드에 대한 문서는 코드에서 최대한 가까이 있는게 맞겠다는 생각이 들었다.

  • ADR에 대해서는 이미 링크 안에 본문이 너무 잘 정리되어있는데, 중요하다고 생각하는 부분은 다음과 같다.

    • 시간을 좀 내서, 결정을 내릴때 생각한 과정을 적어두면 팀원들이 당신의 머리속에 들어올 기회를 주게 됨.
    • ADR을 작성하면 “Decision Socialization(의사 결정의 사회화)“가 가능해짐.
    • 이렇게 하면, 개별적으로 결정을 내리는 대신 팀이 유지관리에 대한 책임을 지는 결정을 내리게 함.

  • 나도 더 늦기 전에 업무에 ADR을 어떤 방식으로 적용할 수 있을지 고민하게 되었고, 덩달아 연관 링크를 찾아보게 되었다.

    • Earn future maintainers esteem by writing simple ADRs | Understand Legacy Code

JS / TS

• Announcing TypeScript 4.0 | TypeScript

  • 오랜만에 타입스크립트 메이저 버전업이 나왔다. 2018년 7월 30일 3.0이 런칭되고 난 이후 2년도 더 되었다.

  • Variadic Tuple Types

    • 튜플 타입 선언 시 전개 연산자(Spread Operator)를 사용하는 것이 제네릭이 된다. 덕분에 불필요한 오버로딩을 하지 않고도 적절한 타입 추론이 가능해졌다.
    • 정확한 길이가 있는 튜플을 펼칠 경우 다른 타입이나 제네릭과 결합되었을 때 그 길이가 정확히 보장되기 때문에 사용하기 편리해졌다.
    • 단순히 concat, tail 정도의 함수에 활용하는 예제를 넘어 부분 적용 함수를 만들 때, 인자를 전달할 때도 유용하게 적용될 수 있다. 인자가 정확히 몇개가 들어오는지 구분하고, 그 인자들의 타입도 효과적으로 추론하는게 가능해졌다.
    • 덕분에 함수 조합과 관련하여 다영한 활용 방법이 생기리라 기대한다.

  • Labeled Tuple Elements

    • 튜플 요소에 이름을 붙일 수 있는 기능이다. 예를 들어 [number, number] 라고 표현되던 튜플에 [start: number, end: number] 라고 각 요소에 이름을 붙일 수 있게 된 것이다.
    • 튜플 인자 리스트 등을 활용하여 오버로딩을 구현하면서 타입 안정성을 확보할 때 유용하게 사용할 수 있다.

  • Class Property Inference from Constructors

    • 클래스의 생성자에서 선언하여 할당한 속성도 class property의 타입으로 자동 추론이 된다.

  • Short-Circuiting Assignment Operators

    • &&=, ||=, ??= 로 해당 연산자의 조건에 맞을 경우 새로운 값을 할당하는 것이 가능하다. 이전에 루비를 다룰 때 있던 연산자라 이런 식의 할당이 가능해진게 반갑다.

  • catch 블록에서 에러 객체를 unknown 으로 지정

    • 이전에 catch (error) {} 로 잡힌 error 객체는 기본적으로 any 타입이다. 하지만 이렇게 되었을 경우 타입 안정성도 보장하기 어렵다보니 에러 객체를 다루다 실수할 수 있는 여지가 있다.
    • 4.0 버전부터는 unknown 으로 타입을 지정할 수 있으므로, 에러를 처리하는 쪽에서는 명시적으로 타입 가드를 해야 한다는 것을 인지시키고 결과적으로 좀 더 안전하게 에러를 처리할 수 있게 된다.

  • 커스텀 JSX 팩토리

    • JSX를 사용할 때 여러 자손 엘리먼트를 리턴할 수 있도록 Fragment 문법을 지원한다. 타입스크립트 초기에는 다른 JSX 사용 라이브러리들이 이 아이디어를 차용하리라고 생각하지 못했으나, 자연스레 다른 라이브러리들도 비슷한 형태의 API를 제공하기 시작했다.
    • 그래서 이 fragment 선언을 더 적절하게 활용하기 위해 어떤 함수가 fragment 생성에 사용되는지 직접 tsconfig.json 에서 지정해줄 수 있게 되었다.

  • 각종 에디터 지원 기능

    • 옵셔널 체이닝 문법으로 자동 전환 지원.
    • @deprecated 지원
    • 큰 프로젝트를 불러올 때 에디터 시작 시 일부만 우선적으로 시맨틱을 적용하는 모드 지원.
    • 더 똑똑해진 Auto import: 기존에 @types 패키지만을 우선적으로 자동 불러오기의 대상으로 삼았던 것에서 발전하여 package.json 파일에 있는 패키지도 자동으로 불러올 수 있도록 별도의 처리를 하는 옵션이 생겼다.

  • 새로운 웹사이트

    • 훨씬 세련된 새 웹사이트가 등장했다. 참고로 이 웹사이트는 Gatsby로 만들었다고 한다.

  • Breaking Changes

    • lib.d.ts 선언이 변경되었고, 주로 DOM에 대한 타입이 변경되었다.
    • 클래스 속성이 접근자(getter, setter)를 오버라이드 할 때 에러를 표시
    • strictNullChecks 옵션을 켰을 때 delete 연산자의 호출 대상은 옵셔널로 처리되어야 한다.

• Hyeseong’s Blog - TypeScript 튜플 타입 요리하기

  • 너무 담아두고 계신게 많아서 글은 천천히 쓰시는 혜성님의 TS 고급(적어도 나에겐 고급이다) 글. Variadic Tuple 부분 설명하기 이전에 재귀적인 타입 선언 방법이 너무 재미있었다.
  • 예제 코드 하나하나 직접 타입스크립트 플레이그라운드에서 따라 쳐보고 이해하는 것만 해도 타입스크립트에 대한 이해를 어느정도 올릴 수 있으니 꼭 글을 읽고 예제를 따라해보라고 권해보고 싶다.
  • 추가로 예제에 나온 재귀적 타입 선언 방식은, 이제 다음 TS 버전업에서 공식적인 방법으로 지원될 예정으로 보인다.

Frontend

• Hyeseong’s Blog - Jamstack에서 스타일시트를 최적화하는 법

  • 본문에 나온 Linaria 프로젝트는 ‘나중에 써봐야지’ 정도로만 인식하고 지나간 채로 있었는데, 이렇게 다시 접하게 되었다.
  • 더불어 덕분에 CRP(Critical Rendering Path)라는 개념을 다시 상기시킬 수 있었다.
  • Gatsby, Linaria 프로젝트를 잘 모르는 분들이라도 기술적인 맥락 보고 CRP에 대해 평소에 어떻게 생각해오고 있었고, 이 글에서 무엇을 배울 수 있었는지 한번 곱씹어보는 것 만으로도 너무 유용한 글이다.
  • Google 문서를 찾다보니 이런 강좌도 무료로 제공을 하고 있더라. 꼭 수강해봐야지.

• 네이버 FE 뉴스 - 8월

  • Svelte가 타입스크립트를 공식 지원한다는 소식을 이 글을 통해 접했다.
  • 크롬 Devtool 고급 사용법, return null vs undefined, Mocky 등이 눈에 띈다.

• Flat vs Hierarchical URL Structure | Joey Hoer’s Blog

  • 앱에 새로운 페이지를 추가하다가, URL 구조에 대해 잠깐 고민하는 시기가 있었다. 직접적으로 연관된 리소스같지 않은데 어떤 페이지의 하위 구성이라는 이유만으로 / 를 하나 더 추가해도 되는건가? 비교적 평탄하게 URL 구조를 만들 수 있지 않을까? 하고 말이다.
  • 결론부터 살펴봤을 때는 SEO 측면에서 계층 구조의 URL이 더 유리해 보인다.

React

• Generic Components | React TypeScript Cheatsheets

  • “react-typescript-cheatsheet”이 오랜만에 눈에 띄길래 몇개 슥슥 읽다가 컴포넌트 선언 시 제네릭을 넘길 수 있다는 것을 지금 알았다. Props 선언할 때 제네릭을 받아서 처리할 방법 없나 하고 끙끙댄적이 있었는데 인생 손해본 기분이다.
  • 막상 지금은 제네릭까지 써야 할 정도로 범용적인 컴포넌트를 구현할 일이 없어서 그런지 필요가 없다만… 다시 한번 저 Cheatsheet을 복습할만한 계기는 되었다.

• GitHub - theKashey/use-callback-ref: 🤙The same useRef, but it will callback

  • ref의 변경을 감지하여 콜백이 실행되도록 만들어진 훅이다. 기능적으로 꽤 유용해보일 수 있지만 추후 Concurrent mode를 지원하기 어렵다는 아쉬움은 있다. 그래도 구현도 깔끔하게 되어있기 때문에 가볍게 코드를 읽어보면 좋다.
  • 덤으로 디자인 패턴 중 하나인 ‘퍼사드 패턴’ 에 대해 관심이 생길 수 있다.

• GitHub - theKashey/react-imported-component: ✂️📦Bundler-independent solution for SSR-friendly code-splitting

  • 위의 use-callback-ref 를 만든 라이브러리 제작자의 코드 스플리팅 라이브러리. 소개하는 기능 표만 봐서는 템플릿 스트링을 사용한 import가 안되는 것 빼고는 @loadable/component 보다 좋아보인다.
  • 지금도 실무에서 아주 기본적인 수준으로 @loadable/component 를 쓰고 있기 때문에, 이 라이브러리가 훨씬 유용하다면 나중에 교체를 고려해봐도 좋겠다는 느낌이 들었다.

Tools

• GitHub - lwouis/alt-tab-macos: Windows alt-tab on macOS

  • 맥에서 하나의 애플리케이션에 여러 윈도우를 쓰는 것을 꺼리게 되는데, 아무래도 같은 애플리케이션의 다른 윈도우 사이에 전환하는 것이 번거롭기 때문이다. 몇 가지 솔루션을 알아봤는데, 알프레드 워크플로우도 있었고, 이런 오픈소스 앱도 있다.
  • 이미 같은 애플리케이션의 윈도우끼리 이동하는 단축키로 Cmd+backtick 이 있음에도 불구하고 이런 도구를 찾아다니게 되는 이유는 저 단축키만으로는 여러모로 불편한 점이 있기 때문이다.
  • A라는 애플리케이션에 창이 두세개 있고, 그 중에 하나로 이동해야하는데 제가 만약 B 애플리케이션을 활성화해둔 상태라면 키스트로크를 두번 이상 입력해야 한다. 그게 아니라면 미션 컨트롤을 이용하여 창을 찾아다녀야 한다. 이전에는 미션컨트롤로 창을 찾아다녔는데 이것도 점점 귀찮아지기 시작해서 조금 더 쉽고 빠른 방법을 찾게 되었다.

• 노션으로 일잘러 되기 프로젝트 매거진

  • 노션을 다양한 업무에 활용하는 방법 포스팅 모음. 다른 도구로 대입하여 활용할 수 있는 부분도 있어서 참고용으로 줍줍.