📜

2021년 10월, 회고 + 보고 배운 것들

태그
회고
최종 편집
Dec 30, 2022 2:32 AM
발행일
October 27, 2021

10월 회고

다행히 9월부터 타올랐던 공부 욕심이 사그라들지 않았다. 여은이를 돌보다 보면 주말에도 별로 시간이 없고 평일 새벽 한두시간밖에 개인 시간이 없는데, 원래 하지 말라면 더 하고 싶은 법이라 시간이 없으니 더 공부가 하고싶었던 것 같기도 하다. 이번 달부터 한달에 한 번 이상 휴가를 쓰면서 정리하고 공부하는 시간을 가져보려 했고 그 결과로 누린 이번 휴가는 (여은이와 시간도 많이 보내기도 했고) 만족스러웠다. 물론 정리하는 데 시간은 턱없이 부족했지만..

  • 거의 한 달 내내 About me를 작성했다. KCD에서의 3년간 배우고 겪은 것들을 제대로 정리해본 적이 없다는 생각이 들어 시작한 것이었다. 기본적으로는 지난 블로그에 써두었던 레주메와 포트폴리오를 대대적으로 수정하는 작업이었는데 이렇게 오래 걸릴 줄 몰랐다. 기록이 충만했던 시기는 간결하게 정리하는 게 힘들고, 기록이 별로 없었던 시기는 기억을 되살리는 게 힘들었다. 전반적으로, KCD에서 보냈던 시기가 가장 뭔가를 제대로 하기 시작한, 밀도가 높았던 시간이었다 보니 쓸 말도 많아서 정리하기도 힘들었다. 이런게 긴 글을 누가 보기나 할까... 라는 생각도 들고. 뭐 어쨌든 고통스러우면서도 재미도 있던 과정이었다.
  • 인생 계획을 다시 세우면서 다음 커리어를 어떻게 준비해볼까 고민이 생겨, 이것저것 조언도 얻어볼 겸 해서 여러 사람을 만났다. 그냥 오랜만에 만나서 같이 식사하면서 수다떤 분들도 있고, 내 커리어 계획과 방향성이 맞아 보이는 회사에 다시는 분을 만날 때는 회사를 이해하기 위한 질문 템플릿을 미리 드린 다음 인터뷰처럼 해보기도 했다. 사람들을 계속 만나니 에너지도 많이 쓰고 피곤하기도 했는데 덕분에 괜찮은 정보와 인사이트를 많이 얻었다. 그러면서 여러가지 새롭게 시도/시작해본 것도 많았다. 엘리스의 AI 교육 수강, Leetcode 문제 풀기, 블록체인 개념을 익히고 암호화폐 투자 입문하기 등.
  • 블로그 글은 About me와 이것을 포함하면 5개, 그리고 공부한 걸 정리한 문서가 엄청 많다. 어느 정도 이상의 퀄리티가 되는 글은 긱뉴스에 올려야지 싶었는데 10월에는 About me 쓰다 보니 그럴 만한 글을 쓸 시간은 부족했다. Sentry 가이드도 썼는데 아직 못 다듬어서... 회사에서 super.so 를 이용한 기술 블로그를 해보겠다고 선언하고, 프론트엔드 팀원 분들께도 글 하나씩 써달라고 말씀드린지 한달도 넘게 지났는데 계속 급한(?) 일이 들어와서 아직 도메인 세팅도 못했다. 11월에는 팀블로그를 꼭 해봐야겠다.
    • 가족 규칙과 회사 문화의 공통점이라는 글은 페이스북에서 따봉을 많이 받아서 즐거웠다. 많들 공감해주신듯.
    • baehwidong.name 도메인을 사서 super.so 에 연결했는데 SSL 설정이 잘 안 돼서 https로 안 들어가진다. 이것 자체보다는 더 많은 블로그 글을 쓰는 게 중요해보여서 더 씨름하는 게 시간이 아깝다. 어쨌든 steady-study.super.site 자체는 https로 됐고 SEO enable도 했으니 일단은 여기까지.
  • LinkedIn에 블로그 업데이트도 할겸 가봤다가 Skill Assessment라는 걸 발견해서 Frontend Development, React, JavaScript, CSS, Git, Agile Methodologies 뱃지를 획득했다. 객관식 문제 15개를 각각 90초 안에 풀어서 제출하는 것이고, LinkedIn이 제공하기에 괜찮은 컨셉으로 보였다. Agile 빼고는 모두 첫 제출에 Top 5%를 받긴 했는데 React는 hook이 아닌 class 기반 문제들이었고 Git도 master 브랜치나 checkout을 쓰는 거 보면 문제가 옛날에 만들어진 것 같았다.
    • Agile은 문제 뭐 나오나 해서 봤는데 내가 모르는 용어가 많았고 Top 30% 로 턱걸이 뱃지를 받았다.
  • 10월에는 내가 읽은 거의 모든 걸 기록해보자는 컨셉으로 해봤는데 너무 양이 많았다. 카테고라이즈하기도 쉽지 않았다.

유튜브 채널

  • 개발바닥: 기존 영상은 거의 다 봤고 10월에 새 영상이 많이 올라오진 않았다.
  • FE재남: 모던 자바스크립트 딥 다이브 책에 대한 스터디 영상이 많이 올라와서 감사하며 봤다. 초반에는 거의 다 아는 내용이었지만, 프로토타입에 대해서 내가 자세히 모르던 내용도 배우고, '딥 다이브'라는 이름에 걸맞게 내 지식에 깊이를 꽤 더해주었다.
  • Google Chrome Developers: 역시 좋은 영상 많이 올라왔고, HTTP 203 시리즈 영상도 몇 개 봤다.
  • The Roadmap: 개발자 기술 로드맵을 매년 소개하는 https://roadmap.sh/ 에서 운영하는 유튜브 채널을 새로 구독했다. 단순히 로드맵 관련 영상만 있을줄 알았는데 상당히 좋은 내용이 많았다.
  • LeadDev는 유튜브 영상은 하나도 안 보고 글만 봤다. 좋은 글이 많은데, 매주 너무 많이 올라와서 문제다. 다 못보겠다.

React, JavaScript, TypeScript

  • Effective TypeScript: 읽으면 읽을수록 좋은 책이다. 출퇴근할 때 조금씩 읽으면서 새로 알게 된 내용을 정리하고 있다. 이제 40% 쯤 읽은듯.
  • Rate Limiting in JavaScript: Bytes 뉴스레터. limiter라는 npm package를 이용해 rate limiting을 아주 간단하게 구현하는 방법을 보여준다. 써드파티 API 호출시 사용하기에 유용해 보인다.
  • My Top React Interview Questions: JS Weekly. 질문들 자체는 나쁘지 않았는데, 나는 워낙 프로덕 엔지니어 마인드라서 그런지 인터뷰에서 이런 질문을 하거나, 이런 질문에 대해 답변을 하는 내 모습을 상상하면 불만족스럽다.
    • 이걸 제대로 답변 못한다고 이 사람을 떨어뜨릴 수 있나? 거꾸로, 이걸 잘 답변한다고 이 사람이 좋은 엔지니어라는 보장이 있나? 또는, 이것들을 잘 알면 프로덕의 성공에 도움이 정말 되는가?
    • 결국 나는 프로덕을 운영하면서 겪었던 여러가지 기술적/비기술적 문제 해결 경험을 듣고 그 안에서 이런 기술적 깊이가 좀 더 드러나게 탐색적 질문을 하면 될거라는 생각이 든다.
  • JavaScript is very fast: Bytes 뉴스레터. JS는 다년간 "느리다"는 악명이 높았는데, 초기(e.g., IE의 시대)에는 사실이었으나 요즘에는 아니다. V8 엔진 이후로는 정말 빨라졌다.
    • ‣
    요약
  • How I built a modern website in 2021: Kent C. Dodds 가 본인의 홈페이지를 리뉴얼하면서 어떤 기술 스택을 사용했는지 자세히 설명한 글이다.
    • 글이 엄청나게 긴데, 내가 다음 프로젝트를 할 때는 다시 한번 읽어보면서 참고할 만 하다.
    • React Router의 메인테이너들이 만든 Remix를 본격적으로 사용했는데 그 경험이 무척 좋았다고 한다. 이게 유료고 너무 비싸서 관심을 덜 가지고 있었는데 오픈소스로 풀린다고 해서 기대된다. 켄트가 이 글 이후로도 리믹스에 대한 여러 글을 올리고 있는데 괜찮은 부분이 정말 많다.
    • 기술 스택 중 내가 안 써봤지만 관심 가는 것들은 XState와 MSW다.
    • 써드파티 중에서는 아래 두 개.
      • Fly.io: Super hosting platform
      • Fathom: Privacy-focused ethical analytics service.

HTML

  • WAI-ARIA란?: 웹 접근성을 높일 수 있는 HTML 요소와 속성들에 대한 글이다. 대부분 아는 얘기이긴 했지만 정작 실천은 많이 안 하고 있어서.. 사실 테스트코드를 많이 작성하기 시작하면 접근성을 높였을 때 테스트할 엘리먼트 선택도 쉽고 가독성도 좋아지기 때문에, 1타 2피라고 생각하고 있다. 이 방향으로 더 나아가볼 생각.
  • DOM, Shadow DOM, Virtual DOM: 로드맵 유튜브.
    • DOM(Document Object Model): HTML 파일을 브라우저가 파싱해서 만들어낸 in-memory representation. Abstract Syntax Tree라고 볼 수도 있다.
      • DOM API로 DOM을 조작할 수 있다. DOM 자체는 프로그래밍 언어가 아니므로 DOM API를 자바스크립트를 통해 호출하긴 하나, DOM은 JS Spec에 포함되어있지는 않다. DOM Spec은 따로 있다.
    • Shadow DOM: Custom Web Component를 만들 때 주로 사용하며, video 태그가 전통적으로 shadow DOM을 썼던 녀석이다. 기본적으로는 DOM과 같으나 캡슐화되어있어서 shadow root 외부에 영향을 미칠 수 없다. IE11 빼고 거의 모든 브라우저에서 지원한다.
    • Virtual DOM: Shadow DOM과 달리 브라우저에서 지원하는 게 아니라 JavaScript로 만들어내는 추상화다. 대표적으로 React가 사용하는 개념으로, 실제 DOM 을 추상화한 가짜 DOM을 메모리에 두고, UI에 일어난 변화는 virtual DOM에만 적용했다가, 일정 주기로 실제 DOM과 싱크하는(= reconciliation) 것이다. 실제 DOM의 조작보다 렌더링을 더 빠르게 할 수 있다는 장점이 있다.
  • Incremental DOM과 Virtual DOM 비교: 위 글 보다가 궁금해져서 검색하다가 발견.
    • Angular는 2019년부터 Virtual DOM 대신 Incremental DOM을 사용하고 있다. Incremental DOM은 Virtual DOM과 달리 메모리에 DOM을 저장해두지 않으며, 대신 "DOM을 이렇게 바꿔라" 라는 명령의 모음을 저장해두고, 이걸 실행한 결과를 실제 DOM과 비교한다.
    • 가상 DOM을 메모리상에 유지하지 않기 때문에 Incremental DOM은 Virtual DOM에 비해 메모리 사용량이 훨씬 덜하다. 그러나 DOM 비교 과정은 Virtual DOM이 더 빠르다. 다른 장단점도 있으나, 주된 차이는 속도와 메모리의 트레이드오프라고 할 수 있다.

CSS, UX

  • 2021년에 살펴볼 법한 브라우저 개발자 도구의 유용한 스타일 관련 기능: 페이스북. 자주 사용되지 않는 개발자 도구에 있는 스타일 관련 기능들을 소개한다. Firefox의 폰트 디버깅 도구, Chrome의 CSS Overview 및 스타일 정의 커버리지 보기, Edge/Safari의 z-index 계층 보기 등은 내가 몰랐으면서도 유용해 보였다.
  • CSS aspect-ratio, object-fit 속성: 둘 다 이미지를 적당한 비율로 표시할 수 있게 도와주는 속성이다. 회사에서 이미지 크기 조절하다가 알아보게 됐다. aspect-ratio는 2021년부터, object-fit는 대략 2014년부터 쓸 수 있었던 것으로 보인다. 둘다 IE 지원은 안 되는데, 예전에는 IE 지원 안 되면 신 포도 취급하며 자세히 알아보지 않았었는데 이제는 그러면 안 되겠다.
  • Why Tailwind CSS: 바이츠 뉴스레터. KCD에서 테일윈드를 쓰고 있기 때문에 소개된 장점 대부분은 알던 내용이었지만, 스타일 인라이닝의 장점 관련해서는 살짝 의견이 다르다.
    • ‣
    소개된 장점
    ‣
    나의 의견
  • Ct.css - <head>의 성능 분석용 CSS Snippet: 긱뉴스. 웹사이트에 CSS 파일 하나를 주입하여 이 웹사이트의 <head /> 에 명시된 CSS와 script 등이 얼마나 괜찮은 상태인지 알려준다. 크롬 개발자 도구의 스니펫으로 사용할 수 있다.
  • Avoiding layout shift by putting the CSS in charge: 크롬 유튜브의 HTTP 203 시리즈. 레이아웃에서 CSS를 어떻게 사용하느냐에 따라 레이아웃 시프트가 일어날 수 있음을 보여주고, 어떻게 피할 수 있는지, 그러한 의사결정에서 트레이드오프는 무엇인지 보여준다.
    • ‣
    요약
  • 효율적인 다크 모드 구현을 위한 배경/전경 컨텍스트 기반의 컬러 팔레트 만들기 (feat. CSS variable): 아직 다크 모드를 한번도 개발해보지 않아서, 이런 키워드만 나오면 읽어보고는 있는데 잘 실감이 안 난다. 개발자보다는 디자이너를 위한 글에 가까워 보였는데.. 아무튼 다크모드를 개발하게 될 때 다시 읽어볼 수 있도록 무의식에게 맡긴다.
  • Thinking on ways to solve MULTI-SELECT: 크롬 개발자 유튜브 채널의 GUI 챌린지. 필터링 UI를 만드는 방법을 보여준다. written article도 있다.
    • ‣
    요약

아키텍처, 백엔드, 인프라

  • AWS S3와 Github Actions를 통한 정적 웹사이트 배포: 페이스북. 내가 비교적 소홀히 했던 AWS 리소스 다루는 법에 대해서 글 하나에 처음부터 끝까지 잘 나와 있어서 개인 웹사이트 만들 때 참고하기 좋아 보인다.
  • The BFF Pattern (Backend for Frontend): An Introduction: BFF라는 말을 종종 봤는데 뭔지 몰라서 찾아봤다. 알고보니 내가 모르던 개념은 아니고 여러 마이크로서비스(또는 그냥 여러 서버)들과 통신하는 단 하나의 중개 역할을 하는 서버를 두고, 프론트엔드는 딱 그 서버랑만 정해진 방식으로 통신하는 개념이다.
    • Hasura처럼 여러 소스로부터 단일 GraphQL 스키마를 만들어주는 것도 BFF라고 볼 수 있다.
  • 평생 무료인 모니터링 도구 10분만에 만들기: 생활코딩 페이스북. 깃헙 액션과 깃헙 이슈, 깃헙 페이지를 이용해 웹사이트 업타임을 체크해주는 툴을 만드는 방법을 소개한다.
  • 배민쇼핑라이브를 만드는 기술: 채팅 편: 우아한형제들 테크 블로그. 원래는 채팅을 Sendbird 같은 외부 서비스를 사용해서 만드려고 했는데, 이 서비스는 순간 트래픽이 엄청나기 때문에 외부 솔루션을 쓰기 어렵다는 결론을 내리고 직접 구현한 스토리다. 채팅을 "가볍게" 만들기 위해 겪은 여러 시행착오와 그 해결방법이 자세히 적혀 있어서 좋았다.
    • 웹소켓은 웹소켓이 꼭 필요한 부분에만 최소한으로 사용해서 복잡도를 줄이고, 나머지는 그냥 API 쓴다.
    • RDB 에 직접 접근하는 일을 줄이고 Redis 같은 캐시 레이어를 중간에 둔다.
    • 메시지가 너무 길어질 수 있으므로 리스트 가상화 + 렌더링 횟수(업데이트 횟수)를 줄인다.

WebAssembly

  • WebAssembly는 어떻게 JavaScript를 빠르게 실행할 수 있는가: 2021년 2분기 Dev Day때 읽고 요약했다. 긱뉴스에도 올렸는데, 댓글 덕분에 왜 JIT이 보안에 더 취약한지 알게 됐다.
    • "기본적으로 JIT 엔진은 복잡하기 때문에 공격 표면이 늘어날 뿐더러, JIT에서 성능 향상을 위해 적용하는 투기적 최적화(Speculative Optimization)와 같은 방법이 특정 패턴의 보안 문제를 반복적으로 발생시키는 경향이 있는 모양입니다. 이 때문에 웹 브라우저의 보안 결함 중 JIT 관련 보안 결함의 비율이 상당히 높다고 합니다."
  • 초보 개발자를 위한 웹 신기술 WebAssembly 설명: 위 글만으로는 웹어셈블리 개념이 덜 잡혔었는데, 유튜브가 어찌 알았는지 추천해주었다. 간단한 개념은 여기서 잘 이해가 되었다.
    • node --print-bytecode app.js 와 같이 하면 바이트코드를 실제로 볼 수 있음
    • JS는 파싱된 후 Chrome 엔진인 V8을 기준으로, 바이트코드를 그냥 실행하는 건 Ignition이 하고 최적화된 코드는 Turbofan이 한다.
      • 브라우저는 JS를 바이트코드로 만들어둔 다음 반복되는 코드를 최적화(더 기계어에 가깝게 번역)해둔다.
      • 그런데 변수의 타입이 변하거나 하면 최적화를 취소해야 할 수 있다.
    • wasm은 파싱/컴파일 없이 바로 바이트코드처럼 실행할 수 있다.
      • 이 실행은 V8에서는 Liftoff가 하는데, 이것 또한 최적화해서 Turbofan을 사용할 수 있다.
      • 그런데 wasm은 거의 모든 코드를 최적화할 수 있으며, 또한 명시적 타입핑이라서 최적화를 취소해야 할 일이 거의 없다.
      • 그래서 wasm은 JS보다 실행 시작 속도도 빠르고 최적화 속도도 빠르다.
  • 2020년과 이후 JavaScript의 동향 - WebAssembly: 더 자세히 알아보고 싶어서 예전에는 스쳐지나갔던 글도 다시 꺼내봤다.
    • 2019년 12월부터 W3C가 wasm을 웹의 HTML, CSS, JS 에 이은 4번째 언어로 권고했다.
    • wasm은 LLVM(컴파일러 기반 구조) 지원 언어가 모두 웹에서 사용될 수 있게 컴파일되는 Polyglot이라 할 수 있으며, wasm으로 컴파일할 수 있는 언어 목록은 공식 개발자 가이드에서 확인할 수 있다.
      • 여러가지 이유로 JS로 못 쓰던 다른 런타임들을 wasm으로 바꾸면 이제 웹에서 다 실행할 수 있는 것.
      • 고급 언어를 컴파일해서 wasm을 만들 수도 있고 직접 텍스트로 만들 수도 있다.
    • wasm은 사실은 '언어'라기보다는 파일 포맷, 또는 네이티브 코드를 웹에서 실행하게 해주는 도구에 가깝다. wasm 모듈은 JS 엔진 내에서 실행된다. 전적으로 브라우저 영역(클라이언트)에서 수행되며, memory-safe한 계산 작업과 보안에 강하다.
      • ‣
      wasm은 왜 빠른가? (첫번째 글에도 있지만 이 글의 내용을 다시 써보면)

Web

인공지능

  • 헬로 딥러닝 - 쉽고 명확하게 딥러닝을 이해하기: 마침 인공지능에 관심을 더 가지게 된 와중에 페이스북에서 보이저엑스의 대표인 남세동님이 딥러닝의 기초 개념을 유튜브 라이브로 설명해준다는 글을 보고 냉큼 봤다. 딥러닝 개념을 정말 쉽게 설명해주더라. 들은 내용을 간단히 정리해두었다.
  • 2021 NIPA AI 온라인 교육: 위 라이브를 보고 더 관심이 생겨서, 이전 직장인 엘리스에서 무료 강의로 홍보하길래 들어보기 시작했다. 아직은 파이썬 기초만 보고 있는데 시간이 나면 더 들을 생각이다.
  • State of AI 2021 보고서: 긱뉴스. 2021년 주요 테마는 다음과 같다. AI가 세상을 어떻게 바꾸는지 관심을 가지다 보니 이런 뉴스도 재밌게 보인다.
    • ‣
    6가지 주요 테마

컴포넌트 설계, 네이밍

  • 변경에 유연한 컴포넌트: 페이스북에서 본 토스 프론트엔드 엔지니어 한재엽님의 글. 프론트엔드에서 UI 컴포넌트를 예시로 들어, 지속가능한 소프트웨어를 위해서는 "예상할 수 없는 변경에 그나마 유연하게 대응"하는 컴포넌트를 설계하기 위한 원칙을 제시한다.
    • 데이터의 층위와 형태, 그 데이터를 어떤 역할로 컴포넌트가 사용하는지, 이 컴포넌트는 재사용 가능한 인터페이스를 가지고 있는지 등을 기준으로 설계를 한다는 것.
    • 전체적으로 좋은 글이긴 하나 너무 여러가지 깨달음이 녹아있어서 그런지 요약하기는 어렵다. 기본적으로는 React의 원칙 중 Prefer composition over inheritance에서 뻗어나온 것으로 느껴진다.
  • 프로그래머를 위한 이름 짓는 원리: 긱뉴스. 위의 "변경에 유연한 컴포넌트" 글의 부록으로도 소개되었다. 이름이 왜 중요하고, 좋은 이름의 기준은 무엇인지 설명한다. 철학적이고 생소한 용어가 많아서 술술 읽히지는 않았지만 공감이 가는 글이었다. 글의 '요약' 파트에서 일부만 발췌한다.
    • 코드에서의 의미이론: 이름은 지시체(구현)가 아니라 의미(목적)를 기준으로 지어야 합니다. 그래야 적절한 간접화 계층이 형성됩니다. 의미를 드러내는 이름을 지을 수 없다면, 이름을 붙여야하는 대상이 아닐 수도 있습니다.
    • 협의성: 이름이 너무 일반적이면 의미가 모호하며 과도한 변경을 허용하게 됩니다. 이름이 너무 구체적이면 구현이 인터페이스에 노출되며 변경이 어려워집니다. 그 사이에서 강조하고자 하는 대상의 특성에 맞춰 의미를 좁힌 이름이 좋습니다.
    • 일관성: 이름의 협의성은 문맥에 의해서도 형성됩니다. 하지만 어떤 이름의 의미가 문맥에 따라 달라진다면 이름의 의미를 이해하거나 커뮤니케이션 하는 데 더 많은 비용이 듭니다. 어떤 문맥에서든 동일한 의미를 갖는 이름이 더 좋습니다.

리더십, 협업, 생산성

  • 개발자가 모자라요: 박영록님 블로그 글. 오랜만에 봤는데 여전히 좋았다. '사실은 개발자가 모자라지 않고, 프로세스와 문화의 문제다'라는 것. 회사에서 기능조직에서 목적조직 형태로 다시 구조를 변경하면서 목적조직에 기대하는 바를 작성했었는데, 이 글에서 느낀 게 알게모르게 그 안에 들어갔던 것 같다.
    • "개발자가 모자란 것은 원인이 아니라 결과다. 원인은 개발자들이 제대로 일할 수 있는 문화가 갖춰지지 않았기 때문이다. 문화가 갖춰지면 개발자들의 생산성은 몰라보게 올라갈 것이고, 뛰어난 개발자도 저절로 모여든다. 개발자가 모자란다고 불평하기 전에, 우리 회사는 왜 개발자가 생산성을 낼 수 없는지 고민하는 것이 우선이다. 그런 고민 없이 아무리 개발자 늘려봐야 소용 없다."
  • 지금, 툴이 아닌 틀을 바꿔야 할 때: 페이스북에서 본 토스 블로그. 글도 참 잘 쓰고 제목도 잘 짓는다. 개발 생산성과 디자인 생산성을 극도로 올리기 위한 여정이 잘 보인다.
    • 디자인 툴을 Framer로 변경 → 디자인 시스템을 잘 확인할 수 있는 자체 Hand-off 툴을 만듦 → 디자인 시안을 Design Syntax Tree로 해석해서 이를 코드로 변환하게 함 → 디자인 시스템 커버리지 계산 → ...
    • KCD는 Figma를 쓰고 있는데, 만약 Framer로 바꾼다면 어떨까 해서 잠시 찾아보았는데, 피그마가 프레이머의 장점을 따라하는 게 프레이머가 피그마의 장점을 따라하는 것보다 더 쉬워 보인다. 토스는 '실제 모바일 환경에서 버튼을 누르면 어떤 화면으로 넘어가는지, 어떤 토스트가 나타나는지, 어떤 사운드나 햅틱이 나오는지를 알 수 없었던' 문제를 언급했지만 우리는 그정도로 고품질 인터랙션 디자인을 하고 있지 않기 때문에 아직은 괜찮아 보인다. 코드로 디자인을 만든다는 측면은 피그마나 프레이머나 비슷하고.
  • 토스가 보이스톤 메이커를 만들게 된 배경: 토스 디자이너가 쓰신 글이다. 위와 살짝 이어지는 느낌. 프로덕이 비슷한 분위기로 유저에게 말을 걸게 하는 것을 가이드라인으로 만드는 것에서 그치지 않고 자동화까지 했다. 토스가 각 구성원의 반복작업을 줄이고, 생산성을 높이고, 프로덕 내 일관성을 높이기 위해 노력을 정말 많이 한다는 게 느껴져 무척 인상적이었다.
  • Technical Leadership and Glue Work: 팀 동료 will에게 추천받았다. 다 보고 나서 알았는데 LeadDev에도 영상이 있더라. 내가 KCD에서 (시니어 롤이 아님에도) glue work를 많이 해왔는데, 다행히 이 조직은 그것들을 잘 인정해줬고, 나 스스로도 기술적 챌린지를 통해 기술역량을 많이 올랐기 때문에 내가 살아남은 것 같다. (11월에 본 기버/매처/테이커 영상과도 관련이 있어 보인다)
    • ‣
    요약

스타트업, 그로스

문제해결 경험

  • iOS 단축어를 이용한 업무 자동화: 예전에 Hammerspoon을 이용한 반복업무 자동화 글을 썼던 거랑 아주 비슷한 맥락이다. 팀 동료인 chris와 lucy가 VPN 연결시 필요한, RSA SecureID 앱에 뜨는 OTP를 붙여넣는 반복작업을 자동화하기 위한 시도를 하셨다.
    • 애플의 단축어 기능과 Universal Clipboard를 이용한 것인데, 대략 이런 과정이다.
    • 아이폰 위젯으로 단축어를 실행 → 앱을 스크린샷 찍고, OCR로 숫자 인식해서 복사 → (맥북과 아이폰이 같은 계정으로 iCloud에 로그인되어있다면) Universal Cipboard에 들어감 → 맥북에서 CMD+V
    • 쓰다 보니 나는 뭔가 인식이 잘 안돼서 안쓰게 되긴 했지만, 이런 식으로도 반복업무를 줄일 수 있다는 영감을 얻어서 재밌었다.
  • 애물단지가 되어 자리만 차지하는, 부팅 안되는 10년 된 iMac 처리하는 방법
    • 부품을 쪼개서 파는 방법을 소개하는 영상도 있었고 막 납땜하고 해서 모니터로 재활용하는 영상도 있었는데 시간과 노력이 많이 들어서 내게는 안 맞아 보였다. 중고거래도 거의 안해봤고.
    • 애플 트레이드인으로 새 애플 기기를 살 때 보상판매를 할 수 있다는 것 같았는데, 부팅이 안돼서 시리얼넘버도 못찾겠더라. 애플 공식 홈페이지에서 산 게 아닌 것인지 구입 기록도 없다. 11번가에서 샀던 것 같기도 해서 가보니 5년 전까지밖에 검색이 안 되고.
    • 내 증상으로 검색해보니 부팅시키기 위해 해볼 만한 것들이 잘 나와있어서, 주말에 시간 내서 시도해보려고 한다. 잘 안 되면 리통 리싸이클이라는 곳에 공짜로 폐기할 수도 있다.
    • 되든 안되든 이 과정은 블로그 글 하나로는 써봐야겠다.
  • 윈도우즈 PC에서 한컴오피스 2018이 열리지 않는 문제 해결
    • 2년 전쯤 모니터 대용으로도 쓰고 은행이나 공공기관 업무도 할 겸 일체형 윈도우즈 PC를 하나 사뒀다. 살 때 한컴오피스 2018을 함께 줬는데 어느 순간부터 프로그램이 열리지 않더라.
    • 검색을 해보니 윈도우즈 업데이트되면서 나처럼 C++ 런타임이 충돌이 났다거나 하는 이유로 실행 안 되는 사람이 많았다. C++ 런타임을 Repair하니까 해결됐다.
  • 회사에서 개츠비로 빌드한 사이트의 렌더링이 깨지는 현상 해결 (by 팀 동료 chris)
    • 내 컴퓨터에서는 재현이 되질 않아서, 깨지는 분이 어떤 HTML을 가지고 있는지 전달받아서, 정상적인 HTML과 비교하니 확실히 이상했다.
    • 알고보니 page-data.json 을 캐싱하면 안 되는데 캐싱을 해두었기 때문이었다. 과거에는 page-data.json 이 해싱되어 있어서 캐싱을 하는 게 원칙이었는데 2019년 6월부터 달라졌다.
      • "The new page-data.json resources are not content-hashed. This means that if a user is on the site and a rebuild occurs resulting in changed page-data.json, the user will then see that new information when they navigate to that page."
      • page-data.json 은 빌드할 때 모든 페이지에 대한 정보를 담고 있도록 만들어지고, HTML을 생성하는 데 쓰인다.
    • 이미 page-data.json 이 immutable 로 로컬 캐싱되어 있는 유저들에게는 갱신해줄 방법이 없어서, 파일 경로를 변경해서 새 URL로 요청하도록 만들었다.
  • 회사 웹사이트의 배포 환경 변화 이후로 쿠키에 인증 토큰이 저장되지 않는 문제 해결
    • 원래 AWS Amplify로 캐시노트 웹을 배포하고 있었다. 이 때는 CORS 이슈를 피하기 위해 app.cashnote.kr/api/.. 같은 프록시로 요청을 보내면 Cloudfront가 api.cashnote.kr/.. 로 보내주는 식으로 구현했다.
    • 이게 여러모로 귀찮아서, 서버는 CORS를 허용하고, 웹사이트도 Amplify 같은 스택을 통하지 않고 직접 S3 + Cloudfront에 올리는 식으로 작업했다. 즉 클라이언트에서 cross-origin으로 API 요청을 직접 하는 것이다. 여기에 더해, 인증 토큰도 클라이언트의 localStorage에 저장하는 대신 httpOnly 쿠키에 *.cashnote.kr 로 서버가 저장해주는 방식으로 변경했다.
    • 그런데 배포 방식을 바꾼 뒤로 쿠키에 인증 토큰이 저장되지 않기 시작했다. 알고 보니 proxy를 쓰던 시절에는 origin이 같기 때문에 쿠키가 잘 세팅되었는데, API 호출이 cross-origin으로 바뀌면서 request에 credentials: include 를 넣어야만 쿠키가 세팅될 수 있다는 걸 몰랐던 것이다.
    • axios, Apollo Client, GraphQL Client 등 API 요청을 담당하는 라이브러리들에서 이 옵션을 추가함으로써 해결됐다.
  • <button /> 에 display: block; 을 줘도 버튼 크기가 전체 width를 채우지 못하는 문제 해결
    • <button /> 은 HTML 스펙에 따르면 inline-size 속성이 auto 이면 내부적으로 fit-content 로 사용된다.
    • inline-size는 physical이 아닌 logical property이기 때문에 writing-mode 를 어떻게 두느냐와 조합하여 width, height를 직접 지정하지 않고 재사용할 수 있다.
    • 일반적인 횡쓰기에서 inline-size 는 기본적으로 width와 같은 값을 가진다. 즉 width가 지정되지 않으면 디폴트값인 auto 가 되고, 이게 button 에게는 fit-content 로 작용하여 전체 컨텐츠보다 더 긴 영역을 차지하지 않게 되는 것이다.
    • 아직 inline-size 의 브라우저 지원이 넓지 않기 때문에, 그냥 width를 100%로 지정해서 해결했다.

기타

  • 회사 금융 담당자분들께 들은 이야기. 대출은 크게 3가지 분류로 사용자에게 어필할 수 있다. 낮은 금리, 많은 한도, 빠른 대출(간단한 심사).
  • Leetcode 문제풀이: 구글 다니시는 분께 추천받았는데 알고리즘 문제풀이를 한 번도 안 해봐서, 조금 풀어보니 재밌었다. 면접을 준비한다기보다, 평소에 안 쓰던 뇌를 쓰는 느낌? 겨우 3문제 풀고 다른 거 정리하느라 못하고 있다. 10월 회고 하다보니 너무 욕심이 많았던 것 같다.
    • 지금까지 푼 3문제는 정말 "문제"를 푸는데 집중했는데 그보다는 내가 문제를 해석하고 접근하는 기록을 남겨두는 게 더 좋겠다는 생각이 든다.
  • 2021년에 FaaS 선택하기: 긱뉴스. 여러 클라우드 벤더의 Function as a Service를 비교한다. 내가 몰랐던 것도 있는데 개인 프로젝트든 어디서든 쓸법 해서 킵해둔다. 원문에서 말하는 FaaS의 장단점은 다음과 같다.
    • Pro: Maintenance, Cost, Upgradable
    • Cons: Higher Latency, Portability
  • 십년지기 언어, 러스트와 고: 페이스북. 요즘 워낙 러스트의 성능이 좋다는 얘기를 많이 들어서 재밌게 봤다.
    • 대형 프로젝트에서는 Go가 우세. 커뮤니티가 더 큼. 러스트는 아직 사례가 적으나 늘어나고 있음.
    • 동시성과 병렬성에서는 둘 다 좋음.
    • 메모리 안정성에서도 둘 다 좋으나, 러스트가 더 좋다는 평을 듣고 있음. 특히 수동 메모리를 이용할 경우.
    • 빠른 속도에서는 러스트가 우세. 러스트 추상화에 대한 학습이 잘 되어있다면. Go는 메모리 관리를 Go 런타임이 담당하면서 오버헤드가 생겨 더 느림.
  • 페이스북 내부고발자 프랜시스 하우건의 의회 청문회 모두 발언: 아웃사이더 블로그. 페이스북의 폐쇄성과, "페이스북은 회사의 이윤과 시민 모두의 안전이 충돌하는 상황을 끝없이 맞닥뜨렸고, 그때마다 어김없이 회사의 이윤을 좇았습니다."라는 문구가 인상적이었다.
  • 새로운 학습 방법: 학습은 기술이다: 긱뉴스. 어떤 것이든 배우기 위한 전략 6단계. AI나 블록체인 등 요즘 내가 관심있어 하는 분야에 대해 이렇게 접근할 수도 있을 것 같다.
    1. Identify & Establish: 주제와 그에 대해 아는 것을 모두 적기
    2. Research: 수평(넓이)으로 시작해서 수직(깊이)으로 가기. 현대적 도구들 이용 (레딧,트위터,뉴스레터,팟캐스트,전문가 네트웍,책)해서 깊이 들어가기
    3. Skin in the Game: 스킨을 넣어서 학습 곡선 가속화 (돈을 쓰거나, 공개적 약속을 하거나)
    4. Engage Community: 권위자와 대화하고, 러닝서클과 토론하기
    5. Teach: 학습하고 싶다면 가르칠 것. 파인만 기법 사용
    6. Reflect & Review: 줌아웃 해서 갭을 확인하고 채우기를 반복
  • 질문에 대한 유용한 답변을 얻는 방법: 긱뉴스. 제목은 "질문"에 초점이 맞춰져있지만 내용은 AC2에서 했던 효과적인 코칭 방법과도 유사하다. 내용이 무척 괜찮았다. 요약된 내용이 워낙 좋기 때문에 그걸 다시 요약하는 건 무의미하지만.. 그래도 핵심 두 개로만 요약해보자. 기억이 안나면 나중에 긱뉴스 글을 다시 보기로 하고.
    • 나는 이것이 궁금한데, 내가 현재 알고 있는 건 이거다. 이게 맞냐?
    • (대화 도중) 내가 이해한 게 맞는지 당신이 설명한 걸 다시 요약해보겠다.
  • Engineering Ladder의 System 축에 있는 SLA(Service Level Agreement)라는, 내게는 생소했던 개념이 궁금했다. 그래서 찾다 보니 Software Reliability Engineering 개념에 관심이 생겨, 이 글부터 시작해서 구글의 여러 블로그 글을 탐독했다. 내가 소화한 내용을 별도의 글 하나로 엮어볼 생각이다.

아직 킵만 해둔 링크들과 도구들

시간 나면 시도해볼 순서대로 써보자.