Outsider's Dev Story

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

기술 뉴스 #222 : 23-05-16

웹개발 관련

  • TypeScript is ‘not worth it’ for developing libraries, says Svelte author, as team switches to JavaScript and JSDoc : Svelte에 TypeScript에서 JSDoc으로 전환하는 Pull Request가 올라왔다. TypeScript로 전환하는 추세에 반대로 가는 접근이라 논란이 많았는데 Svelte를 만든 Rich Harris는 타입은 좋지만, TypeScript는 귀찮은 부분이 있고 JSDoc으로 어노테이션을 넣으면 안전성은 확보하면서 TypeScript와 호환되기 때문에 더 좋다고 얘기하고 있다. 쟁점이 되어 Rich Harris가 해커 뉴스에 글도 남겼는데 이는 타입 안전성을 포기하는 것이 아니라 타입 선언을 TS 파일에서 JS 파일로 옮긴 것뿐이라 TypeScript의 장점은 그대로 유지할 수 있으면서 패키지도 작아지고 디버깅도 쉬워질 것이라고 얘기했다.(영어)
  • Introducing INP to Core Web Vitals : 2022년 INP(Interaction to Next Paint)를 실험적으로 도입해서 테스트한 결과 FID(First Input Delay) 대신 INP를 Core Web Vitals 메트릭으로 채택하기로 하고 2024년 3월부터 적용될 예정이다.(영어)
  • Baseline : Chrome 팀에서 특정 웹 기능이 Chrome, Edge, Firefox, Safari 등 주요 버전에서 지원되는 지를 더 명확히 보여주어 웹에서 안정적으로 쓸 수 있는지를 판단할 수 있는 Baseline을 공개했다. 이는 web.dev와 MDN에서 표시될 것이며 Interop 2022/2023에서 Apple, Microsoft, Mizilla와 협력해서 만들고 있다. 앞으로도 1년에 한 번씩 베이스라인을 발표할 예정이라고 한다.(영어)
  • Vercel Ship : Vercel이 Ship 행사를 하면서 많은 제품을 발표했다.

  • Vercel Markup : Vercel의 많은 제품이 다른 서비스 위에서 만들어졌는데 이를 기반으로 가격 차이가 어느 정도인지를 비교한 페이지이다. Vercel의 KV, Postgres, Blob이 비교되어 있다.(영어)
  • React Canaries: Enabling Incremental Feature Rollout Outside Meta : React에서 아직 배포되기 전의 기능이 포함된 카나리 버전을 공식으로 배포하는 카나리 릴리즈 채널을 공개했다. Meta에서는 새 기능의 초기 버전을 개발하고 Meta 내부에서 일부 팀과 협업하며 시험을 한 뒤 디자인이 확정되면 Meta 내 사용 버전에 적용해서 모두가 사용한 뒤 RFC를 공개하고 이후 릴리스에 포함된다. 여기서 카나리 릴리스는 Meta 내부에서 사용하는 버전으로 실험용 릴리스에 비해서 훨씬 안정적이고 이를 공개함으로써 커뮤니티의 피드백도 얻을 수 있기 때문에 각 라이브러리는 Stable과 최신 Canary를 모두 테스트하길 권장하고 Canary에도 변경 사항이 추가될 때 블로그에 변경 사항을 공개할 예정이라고 한다.(영어)
  • Using the Web Vitals extension to debug Core Web Vitals issues : Web Vitals 익스텐션이 업데이트되어 콘솔에서 JSON으로 출력하던 정보를 LCP, CLS, FID, INP로 나누어서 출력해서 문제를 더 쉽게 파악할 수 있도록 개선되었다.(영어)
  • HTMX is the Future : SPA가 대세이지만 학습하는 비용도 많고 클라이언트에서 JavaSciprt도 많이 필요한데 htmx를 사용하면 훨씬 쉽기 때문에 앞으로 웹 개발에 한 축이 될 것이라고 얘기하는 글이다. SPA를 사용할 때 RESTful API를 이용하지만, 데이터만 주고받을 뿐 하이퍼미디어를 사용하지 않으므로 RESTful API를 쓰는 것은 아니며 htmx에서는 서버의 언어를 맘대로 사용할 수 있고 하이퍼미디어를 그대로 이용하기 때문에 프론트엔드에서 JavaScript가 없어도 잘 동작하기 때문에 쉬우면서 접근성 좋은 웹페이지를 만들 수 있고 프론트엔드/백엔드간의 협업도 더 편해진다고 한다.(영어)
  • Introducing Deopt Explorer : Inline caching 최적화를 JavaScript VM에서도 사용하는데 한가지 타입만 관찰하는 Monomorphic IC이 가장 빠르고 여러 타입을 보는 Polymorphic IC, Megamorphic IC로 갈수록 느려진다. TypeScript 팀에서 5.0을 준비하며 V8에서 생성된 트레이스 로그를 분석할 수 있는 VS Code용 확장 Deopt Explorer를 공개했다. 이 Deopt Explorer 확장을 이용해서 트레이스 로그를 이용해 Megamorphic IC가 발생하는 지점을 찾아서 이를 Monomorphic IC로 개선하는 과정을 보여준다.(영어)

그 밖의 개발 관련

  • Using OpenAI with JavaScript : OpenAI의 chat/completions과 embeddings 2개의 엔드포인트와 Pinecone을 이용해서 자신만의 콘텐츠로 챗봇을 구성할 수 있는 가이드를 설명하는 글로 이 과정의 결과물로 7-docs라는 프로젝트를 공개했다.(영어)
  • Node.js url.parse() 취약점 컨트리뷰션 : 토스 보안기술팀에서 Node.js의 url.parse()의 보안 취약점을 발견하고 이를 수정한 과정을 정리한 글이다. WHATWG URL API가 있지만 node.js의 url.parse()는 자체 구현되어 있는데 스펙에 나와 있는 대로 허용되지 않는 문자열을 검사하는 로직으로 인해서 hostname spoofing 취약점이 발생하게 되었기 때문에 이를 Node.js에 보고하고 해결 방법을 논의하면서 이 취약점을 수정했다.(한국어)
  • How I used GitHub Copilot to build a browser extension : 크롬 확장 프로그램을 GitHub Copilot을 사용해서 만드는 과정을 정리한 글이다. GitHub Copilot의 채팅 기능을 이용해서 질문하면서 파일에 자세한 설명을 제공하면서 코드를 자동완성 하면서 익스텐션을 만들었다. GitHub Copilot의 도움으로 익스텐션을 만들어 보지 않았음에 만들 수 있었지만 쉽게 배울 수 있을 학습 작업 자체를 대체하진 않으므로 프롬프트도 실행해 보고 다양한 질문이나 검색도 했다고 한다.(영어)
  • StarCoder: A State-of-the-Art LLM for Code : HuggingFace에서 GitHub 데이터로 학습한 LLM인 StarCoder를 공개했고 Copilot같은 다른 모델보다 성능이 좋다고 한다.(영어)
  • Push protection is generally available, and free for all public repositories : 커밋에 시크릿이 포함된 경우 푸시 자체를 거절하는 Push protection 기능이 공개 저장소에서 무료로 이용할 수 있게 되었다.(영어)

인프라 관련

  • GitHub Actions – Actions Runner Controller Public Beta : GitHub Actions의 셀프 호스티드 러너를 Kubernetes에서 운영할 수 있도록 도와주는 Kubernetes 오퍼레이터인 Actions Runner Controller(ARC)가 퍼블릭 베타로 공개되었다.(영어)
  • Amazon EKS에서 Topology Aware Hint 기능을 활용하여 Cross-AZ 통신 비용 절감하기 : EKS에서 가용성을 위해 여러 존에서 노드를 운영하는 경우 Cross-AZ 비용이 증가할 수 있다. 이때 Topology Aware Hint를 이용하면 같은 존끼리만 통신할 수 있고 Deployment에는 Topology Spread Constraints를 설정해서 Pod이 각 존에 고르게 배포되게 할 수 있다. 상황별 설정 방법과 동작 방식을 설명하고 있다.(한국어)
  • Introducing Adaptive Metrics: A new cost management feature in Grafana Cloud : Grafana Cloud에 Adaptive Metrics 기능이 추가되어 Grafana Cloud의 모든 티어 사용자가 사용할 수 있다. 사용하지 않는 메트릭이 많으면 비용도 많아지고 속도도 느려지는데 사용하지 않는 메트릭 정리는 꽤 귀찮은 작업인데 Adaptive Metrics는 사용하지 않거나 부분적으로 사용하는 지표를 분석해서 권장 집계를 알려준다. 150개 환경에서 초기 테스트한 결과 평균적으로 20~50%의 시계열 데이터를 줄일 수 있었다고 한다.(영어)

볼만한 링크

  • Google "We Have No Moat, And Neither Does OpenAI" : 여기서 Moat는 해자를 말하고 해자는 외부 침입을 막기 위해 성 주변에 파놓은 구덩이를 말하는데 Google뿐 아니라 OpenAI도 AI에 관해서 이러한 보호장치가 없다고 얘기하고 있다. 이는 Google 내부의 한 연구원이 작성한 문서가 유출된 것으로 회사 전체의 의견은 아니지만 오픈소스 AI가 구글과 OpenAI를 모두 능가할 것이라고 얘기한다. 오픈 소스 모델이 더 빠르고 커스터마이징할 수 있으며 성능도 뛰어나면서 비용도 적게 들고 있어서 스케일링 문제를 해결했다. LoRA를 통해 몇 시간 만에 언어 모델을 개인화할 수 있게 되어 더 저렴하게 최신 모델을 유지할 수 있게 되어 오히려 가장 큰 모델을 유지 관리하는 게 더 불리한 입장이 되었다. 역설적으로 LLaMA가 유출된 Meta가 가장 승자로 오픈소스의 무료 노동력을 얻었으면 구글도 오픈소스와 협력해야 한다고 얘기하고 있다.(영어)
  • SBOM(소프트웨어 자재명세서) 구현을 위한 개방형 표준 : SBOM(Software Bill Of Materials; 소프트웨어 자재명세서)은 소프트웨어를 구성하는 모든 컴포넌트 명세서를 말하고 특히 사이버 보안분야에서 주목을 받고 있다. 표준 SBOM 포맷으로는 리눅스 재단이 오랫동안 지원하며 발전시켜 온 SPDX(Software Package Data Exchange)가 있고 SPDX의 포괄성과 유연함이 걸림돌이 되어 보안과 컴플라이언스에 집중한 CycloneDX가 있는데 이는 OWASP에서 만들었고 CNCF, GitHub, GitLab, 레드햇의 지지를 받고 있다. SWID(Software Identification)는 OASIS의 ISO/IEC 표준으로 정의한 식별정보다. 각 SBOM 표준 선택 기준도 설명하고 있다.(한국어)
  • The 37signals Guide to Making Decisions : 37signals(지금은 Basecamp)가 의사결정을 할 때 고려하는 원칙이 정리되어 있다. 한 번에 다 다 고려하는 체크리스트는 아니고 결정할 때 참고하는 부분이다. 아래는 Deelp의 번역이다.(영어)

    1. 왜 우리가 무언가를 결정해야 할까요? 실제로 여기서 결정을 내려야 하는가?
    2. 적절한 사람이 이 결정을 내리고 있나요? 적절한 역할이 아니라 적절한 정보, 컨텍스트 및 통찰력을 가진 적절한 사람이 결정하고 있나요? 누가 그저 참견만 하는 건가요?
    3. 당장의 영향을 제거하면 1년 후 이 결정에 대해 어떤 기분이 들까요?
    4. 왜 아직 이 결정을 내리지 않았을까요? 왜 진작에 결정하지 않았을까요?
    5. 이 결정을 내리는 데 왜 이렇게 오래 걸리는가? 왜 망설이는 걸까요? 이를 통해 무엇을 알 수 있나요?
    6. 왜 다른 사람이 다른 결정을 내릴까요? 다른 쪽, 또는 두세 가지 다른 결정은 어떤 모습일까요?
    7. 이 결정을 더 작게 할 수는 없을까요? 하나의 큰 결정을 세 개의 작은 결정으로 바꿀 수 있을까요?
    8. 결정을 얼마나 쉽게 되돌릴 수 있을까요?
    9. 이 결정에 대한 우리의 첫 번째 본능은 무엇이었나요? 우리는 지금 데이터로 직감을 정당화하기 위해 빙빙 돌고 있을 뿐인가요?
    10. 결정을 내리지 않으면 어떻게 될까요?
    11. 지난번에 이런 결정을 내렸을 때 어떤 일이 일어났나요?
    12. 결정이 내려진 후 우리는 무엇을 기대하는가? 우리는 무엇을 두려워하는가?
    13. 어떻게 하면 이 결정을 더 쉽게 내릴 수 있을까요? 고려 대상에서 제외할 수 있는 부분은 무엇인가요?
    14. 잘못된 결정은 없는가?
    15. 내일 아침까지 기다렸다가 결정을 내리면 다른 결정을 내릴 수 있을 것으로 예상되는가?
    16. 어떤 결정이 결정을 내리지 않는 것보다 나은가, 아니면 어떤 결정도 내리지 않는 것이 어떤 결정보다 나은가?
    17. 이 결정으로 인해 다른 어떤 결정이 영향을 받게 되는가?
    18. 이 결정으로 인해 다른 결정을 내릴 필요가 없어질까요, 아니면 더 많은 결정을 내려야 할 필요성이 생길까요?
    19. 누락된 정보로 인해 다른 결정을 내릴 수 있는가?
    20. 이 결정으로 인해 해당 업무에 여분의 시간이 없는 사람들이 더 많은 일을 하게 되나요? 아니면 업무가 없어질까요?
    21. 이 결정이 다른 사람에게 연습용으로 좋은 결정이 될 수 있을까요?
    22. 언제 결정해야 하나요?
    23. 한 번으로 끝나는 결정인가, 아니면 반복되는 결정인가?
    24. 회사 외부의 누군가가 이 결정에 의존하는가, 아니면 우리가 스스로 내린 결정인가?
    25. 이 결정이 고객에게 어떤 영향을 미치는가, 아니면 우리에게 어떤 영향을 미치는가?
    26. 주로 데이터에 기반한 결정인가, 아니면 직관이나 직감에 기반한 결정인가?
    27. 다른 의견이 도움이 될까요, 방해될까요?
    28. 지금 당장 결정을 내려야 한다면 어떤 결정을 내릴 것인가?
    29. 90일 전에 이 결정을 내렸다면 우리는 지금 어떤 상황에 부닥쳐 있을까요?
    30. 이 결정에서 X, Y 또는 Z를 고려하지 않았다면 후회할 만한 점이 있나요?
    31. 어떤 방향으로 진행될지 신경 쓰이나요? 그렇지 않다면 왜 관여하는 건가요?
    32. 그 결정이 옳은 결정이었는지, 심지어 중요한 결정이었는지 언제 어떻게 알 수 있을까요?
    33. 결정의 결과가 나타나면 맨눈으로 볼 수 있을까요, 아니면 현미경으로 확인해야 할까요? 후자라면 그게 중요할까요?
    34. 이 결정을 내릴 때 우리는 어떤 원칙을 굽히고 있나요?
    35. 한 사람이 내려야 할 결정을 여러 사람에게 부탁하고 있는 것은 아닌가요?
    36. 노력에 대한 수익이 그만한 가치가 있는가?
    37. 이 결정을 내리면 무엇이 더 쉬워지는가? 무엇이 더 어려워지는가? 쉬워지는 것이 장기적으로도 쉬워지는 것일까요, 아니면 단기적으로는 쉬워지지만 장기적으로는 어려워지는 것일까요? 그 반대의 경우도 마찬가지입니다.
    38. 결국 돈 때문인가요?

IT 업계 뉴스

프로젝트

  • tea/gui : macOS의 패키지 매니저인 Homebrew를 만든 Max Howell이 새로 만든 패키지 매니저인 tea에 GUI가 추가되었다.
  • Shap-E : OpenAI의 3D 생성 모델

버전 업데이트

  • Angular v16.0.0 : JavaScript 프레임워크, 릴리스 공지

    • 성능과 개발자 경험을 크게 개선하는 완전히 새로운 reactivity 모델의 개발자 프리뷰
    • Angular signals 라이브러리로 reactive 값을 정의하고 의존성을 표현할 수 있음
    • 서버사이드 렌더링과 하이드레이션의 개선
    • esbuild 기반 빌드시스템이 개발자 프리뷰로 들어와 72% 이상 개선됨
    • 실험적인 Jest 지원이 추가되고 차후에는 Web Test Runner가 도입될 예정
  • Dart v3.0.0 : 프로그래밍 언어, 릴리스 공지

    • 100% 안전한 null 안정성을 갖추게 되어 타입이 null을 가지지 않는다고 하면 절대 null이 될 수 없다.
    • records로 구조화된 데이터를 쉽게 만들 수 있고 pattern 매칭과 class modifier가 추가됨.
  • Next.js 13.4 : 서버렌더링 React 애플리케이션 프레임워크, 릴리스 공지

    • 6개월 전 Next.js 13부터 도입된 App Router가 안전상태가 됨
    • Turbopack이 베타가 됨
    • 중간 API를 만들 필요 없이 직접 함수를 호출해서 서버에서 데이터를 조작할 수 있는 Server Actions가 알파로 도입됨
  • Nx v15.4.0 : 모노레포 빌드 시스템, 릴리스 공지

    • Vite 공식 지원
    • 공식 Deno 플러그인 지원
    • JetBrains IDE를 위한 Nx Console 도입
  • astro v2.4 : 정적 사이트 빌더, 릴리스 공지

    • scopedStyleStrategy 플래그를 통해 컴포넌트 범위의 스타일을 구성할 수 있음
    • 사이트맵에서 SSR 지원
    • 실험적인 미들웨어와 <style> 태그를 통한 인라인 스타일 지원
  • Grafana Tempo v2.1.0 : 분산 트레이싱 백엔드, 릴리스 공지
  • Docker Desktop v4.19 : 데스크톱용 Docker 애플리케이션, 릴리스 공지

    • macOS에서 vpnkit을 gVisor의 TCP/IP 스택으로 교체하여 컨테이너와 호스트 간 네트워크가 5배 빨라짐
    • 4.18에 도입된 docker init이 Node.js와 Python을 지원
    • Docker Scout의 데이터를 Dcoker Desktop에서 바로 볼 수 있음
  • pgAdmin 4 v7.1 : PostgreSQL 클라이언트 도구, 릴리스 공지
  • PgBouncer v1.17.0 : PostgreSQL 커넥션 풀, 릴리스 공지
  • Vitest v0.31.0 : Vite 유닛 테스트 프레임워크, 릴리스 공지
  • Meteor v2.12 : 웹앱 플랫폼, 릴리스 공지
  • Qwik v1.0.0 : 웹 프레임워크, 릴리스 공지
  • MRSK v0.12.0 : 컨테이너 배포 도구, 릴리스 도구
  • Node.js v20.1.0 (Current) : 자바스크립트 런타임, 릴리스 공지
  • Spring Data 2023.0.0 GA : Spring 기반 데이터 접근 라이브러리, 릴리스 공지
  • RedwoodJS v5.1.0 : 풀스택 웹프레임워크, 릴리스 공지
  • Remix v1.16.0 : 풀스택 웹 프레임워크, 릴리스 공지
  • Apache Airflow v2.6.0 : 워크플로우 플랫폼, 릴리스 공지
  • alpine Linux 3.18.0 : Linux 배포판, 릴리스 공지
  • qwik v1.1.0 : 웹 프레임워크, 릴리스 공지
  • Prisma v4.14.0 : TypeScript/Node.js 데이터베이스 툴킷, 릴리스 공지
  • jQuery v3.7.0 : JavaScript 라이브러리, 릴리스 공지
  • OpenKruise v1.4.0 : Kubernetes용 어플리케이션 관리, 릴리스 공지
2023/05/16 03:11 2023/05/16 03:11