Outsider's Dev Story

Stay Hungry. Stay Foolish. Don't Be Satisfied.
RetroTech 팟캐스트 44BITS 팟캐스트

기술 뉴스 #181 : 21-09-01

웹개발 관련

  • Rush로 프론트엔드 모노레포 도입기 : 밀당 영어에서 프론트엔드가 큰 모놀리스와 멀티레포로 구성되어 있었는데 멀티레포에서 갈라진 여러 의존성과 다른 레포의 변경사항을 보기 어려운 점, 퍼블리싱 순서의 어려움과 의존성의 업데이트를 위해 모노레포로 변경하기로 했다고 한다. 모노레포를 관리하는 도구를 모두 나열한 뒤 각각의 이유로 후보군을 제거한 뒤 Nx와 Rush의 기능을 자세히 비교한 뒤 장단점이 있지만 Nx에서 플러그인을 만드는 부담도 있고 현재 프로젝트를 점진적으로 바꾸기 위해서는 Rush가 더 낫다고 판단해서 Rush를 선택했다고 한다. 이렇게 선택한 Rush를 이용해서 사용하던 React 버전을 점진적으로 올릴 수 있게 프로젝트 설정하는 방법을 보여준다. 꽤 긴 글이지만 모노레포 도구를 찾고 있다면 많은 도움이 될 글이다.(한국어)
  • 개발자, UI 라이브러리를 만들다. : 직접 다룰 수 있는 UI 라이브러리가 필요해서 Sapa라는 UI 라이브러리를 만드는 easylogic님이 Sapa로 에디터를 만들면서 정리가 되어서 직접 만든 라이브러리르 소개하는 글이다. easylogic는 컴파일 없이 쓸 수 있고 Virtual DOM을 사용하지 않고 DOM 이벤트를 위한 핸들러를 가지고 있는 특성이 있다고 한다. Sapa의 설치부터 사용 방법을 설명하고 있다. 에디터를 포함해서 바닥부터 하나하나 다 만드시는 게 항상 대단하다.(한국어)
  • FE 개발자의 성장 스토리 11 : Electron, 저도 한번 해보겠습니다. : 카카오에서 Electron 앱을 만들면서 배운 과정이 나와 있다. 인증 리다이렉트를 위해 will-navigate 이벤트를 사용하고 여러 화면을 그리기 위해 BrowserWindow안에 BrowserView를 만들어서 사용하면서 상태 공유를 위해서 메인 프로세스를 이용하고 업데이트나 알림 구현 등 프로덕션 수준의 앱을 만들기 위해서 겪은 과정이 나와 있다.(한국어)
  • Ten Years of Bootstrap : 10년 전 트위터에서 일하던 Jacob과 mdo(이 글을 쓴 사람으로 현재 GitHub에 있다)가 오픈소스로 공개했던 Bootstrap의 10년을 돌아본 글이다.

    • 문서 페이지의 25억 페이지뷰(월 68만 5천 PV)
    • 2015년부터 3억 9천만 npm 다운로드(일 18만 다운로드)
    • 전체 웹사이트의 22%가 사용 중
  • Deno on MDN : 웹과 관련해서 가장 좋은 문서 사이트 중 하나인 MDN의 버전 호환표에 Deno가 추가되었다.(영어)

그 밖의 개발 관련

  • How We Design Our APIs at Slack : Slack에서 그동안 API를 디자인하면서 알게 된 디자인 원칙과 새로운 API를 위한 프로세스를 설명하는 글이다.

    • 디자인 원칙

      1. 한 가지 일만 잘한다: 한 번에 많은 문제를 해결하려고 하지 말고 간단한 API를 만들면 이해하기도 쉽고 확장하기도 쉽다.
      2. 빠르고 쉽게 시작할 수 있게 만든다: 처음 하는 사람도 15분 이내에 첫 API 호출을 할 수 있게 한다.
      3. 직관적으로 일관성 있게 노력한다: 문서 없이도 API를 추측할 수 있어야 한다.
      4. 의미 있는 오류를 반환한다: 개발자가 문제를 해결하기 쉽게 한다.
      5. 확장과 성능을 고려해서 설계한다: 큰 컬렉션을 페이징하고 다른 큰 컬렉션 안에 다른 큰 컬렉션을 임베딩하지 않고 API 레이트를 제한한다.
      6. 호환성을 깨뜨리는 변경을 피한다:
    • 디자인 프로세스

      1. API 명세서 작성
      2. 내부 API 리뷰
      3. 초기 파트너 피드백
      4. 베타 테스트
  • git은 폴더경로가 변경된 것을 어떻게 알 수 있을까? : git에서 파일의 경로를 변경하고 수정까지 한 경우에 Git이 어떻게 커밋히스토리를 유지하는지를 추적한 글이다. 추가/삭제된 파일의 hash로 후보를 찾고 이 파일을 규칙에 따라 chunk로 나는 뒤에 50% 이상 동일하면 변경된 것으로 인식한다. 그래서 파일 마지막에 개행 문자가 없는 경우에 rename의 추적 과정이 왜 달라지는지도 보여준다.(한국어)
  • Clean Swift Scaffold : Swift로 iOS 개발을 하면서 화면 구성에 필요한 다양한 객체들을 매번 만드는 게 번거로워서 Usecase를 기반으로 필요한 코드와 Spy 객체를 만들어 주는 iGospy를 만들어서 사용하다가 복사 붙이기를 하지 않고 커맨드라인에서 바로 생성하기 Clean Swift Scaffold를 만들었다고 한다. iOS 개발자이지만 Go 언어 프로젝트가 많아지는 회사 분위기에 따라 golang을 틈틈이 사용하면서 익숙해졌다고 한다.(한국어)
  • macOS 안내서 - 본격 macOS에 개발 환경 구축하기 : subicura님이 블로그에 작성했던 macOS의 개발환경 구축 방법을 설명한 글을 보기쉬운 안내서로 다시 작성했다. macOS를 처음 써보는 사람도 볼 수 있게 macOS의 사용방법 부터 개발에 도움 될 기본 설정부터 기본적인 프로그램과 유용한 앱 추천까지 잘 정리되어 있다.(한국어)
  • 네이버 카페 검색용 알프레드 워크플로우 제작 : macOS의 생산성 도구 중 하나인 Alfred를 이용해서 원하는 네이버 카페에서 바로 검색하는 커스텀 워크플로우를 작성하는 방법을 설명한다. 네이버 카페가 UTF-8이 아니라 CP949이므로 이를 변환하는 Python과 PHP 스크립트를 작성해서 보여주고 있다.(한국어)

인프라 관련

  • DevOps팀의 Terraform 모험 : Kurly에서 반복해서 만드는 스테이징/QA 인프라 환경을 관리하기 위해 IaC(Infrastructure as Code) 도구로 Terraform을 도입하는 과정을 정리한 글이다. Terraform을 공부해서 스테이징 환경을 만들어 낼 수 있는 모듈과 Environment 코드를 작성하고 도입을 하려고 했지만 tfstate를 잘못 이해하여 설계부터 잘못된 것임을 깨닫고 목표를 변경했다고 한다. 이후 수동으로 관리할 부분과 Terraform으로 관리할 부분을 구분하고 리소스 간의 의존성을 확실히 이해할 것을 원칙으로 삼았다고 한다. 도입하면서 고생한 과정이 잘 나와 있어서 성공 사례보다 더 값지다.(한국어)
  • WebAssembly serverless functions in AWS Lambda : WasmEdge을 이용해서 AWS Lambda에서 WebAssembly로 서버리스 펑션을 작성하는 방법을 설명한 글이다. WebAssembly는 Python이나 JavaScript보다 훨씬 빠르고 보안에 강하면서 이식성이 좋아서 서버리스 펑션에 사용하기가 좋다. 데모로 Rust로 작성한 WebAssembly 함수를 도커 이미지로 만들어서 Lamba에 배포하는 방법을 보여주고 두 번째 예제는 Tensorflow를 이용해서 추론하는 WebAssembly 함수를 보여주는데 둘 다 WasmEdge로 실행된다.(영어)
  • A Deep Dive Into Kubernetes Schema Validation : Kubernetes manifests를 클러스터에 적용하기 전에 유효성 검사를 할 수 있는 방법을 비교한 글이다. kubectl--dry-run=client/--dry-run=server로 하는 방법과 kubevalkubeconform 도구를 쓴 방법을 비교했는데 잘못된 설정을 모두 잡아내는 방법은 --dry-run=server가 가장 확실했지만, 속도는 가장 느렸으며 속도 면에서는 kubeconform이 가장 빨랐고 kubeval에 비해 Kubernetes 버전 지원도 최신까지 지원하고 있다.(영어)
  • OpenTelemetry becomes a CNCF incubating project : 옵저버빌리티 프레임워크인 OpenTelemetry 프로젝트가 CNCF 인큐베이팅 프로젝트가 되었다.(영어)

볼만한 링크

  • IPv4 vs. IPv6 FAQ : IPv6에 대한 오해나 질문을 정리한 글이다.(영어)

    • IPv6는 1998년 첫 표준안이 발표되고 1999년부터 주소를 할당하며 롤아웃 프로세스가 시작되었지만 20년이 지난 아직 완료되지 않았다.
    • 대부분의 경우 둘 간의 속도 차이가 나지 않는다. 가장 큰 성능 차이는 경로 최적화에 따라 다르지만, IPv4, IPv6 중 어느 쪽을 더 효율적으로 라우팅하는지는 ISP에 따라 다르다.
    • IPsec이 IPv6 표준의 일부로 간주하지만 자동으로 암호화하지는 않고 선택사항이다. 실제로 IPv4처럼 VPN 터널 외에는 거의 IPsec을 사용하지 않는다.
    • IPv6는 설계 목표는 많이 달성했지만, 예상처럼 빠르게 롤아웃되지 않았고 IPv4를 대체하지도 못했다.
    • IPv6의 롤아웃이 느린 이유는 IPv4와 같이 배포할 때 충분한 가치를 제공하지 못했기 때문이다.
    • IPv6의 주목적이 IPv4의 주소 공간을 늘리는 것이었으므로 IPv4 주소 공간이 제한적인 사설망에서 많이 사용된다.
  • GitHub Discussions is out of beta : GitHub에서 게시판 형태로 의견을 주고받을 수 있는 Discussions의 베타가 종료되었다. 저장소 설정에서 Features 아래 Discussions를 활성화하면 사용할 수 있다.(영어)

프로젝트

  • giscus: GitHub의 DIsccussions를 이용한 댓글 시스템.
  • GeekNews Show: GeekNews에서 직접 만든 것을 공유할 수 있는 Show 기능을 공개했다.

버전 업데이트

2021/09/01 09:00 2021/09/01 09:00