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 Markup : Vercel의 많은 제품이 다른 서비스 위에서 만들어졌는데 이를 기반으로 가격 차이가 어느 정도인지를 비교한 페이지이다. Vercel의 KV, Postgres, Blob이 비교되어 있다.(영어)
React Canaries: Enabling Incremental Feature Rollout Outside Meta : React에서 아직 배포되기 전의 기능이 포함된 카나리 버전을 공식으로 배포하는 카나리 릴리즈 채널을 공개했다. Meta에서는 새 기능의 초기 버전을 개발하고 Meta 내부에서 일부 팀과 협업하며 시험을 한 뒤 디자인이 확정되면 Meta 내 사용 버전에 적용해서 모두가 사용한 뒤 RFC를 공개하고 이후 릴리스에 포함된다. 여기서 카나리 릴리스는 Meta 내부에서 사용하는 버전으로 실험용 릴리스에 비해서 훨씬 안정적이고 이를 공개함으로써 커뮤니티의 피드백도 얻을 수 있기 때문에 각 라이브러리는 Stable과 최신 Canary를 모두 테스트하길 권장하고 Canary에도 변경 사항이 추가될 때 블로그에 변경 사항을 공개할 예정이라고 한다.(영어)
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의 도움으로 익스텐션을 만들어 보지 않았음에 만들 수 있었지만 쉽게 배울 수 있을 학습 작업 자체를 대체하진 않으므로 프롬프트도 실행해 보고 다양한 질문이나 검색도 했다고 한다.(영어)
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년 후 이 결정에 대해 어떤 기분이 들까요?
왜 아직 이 결정을 내리지 않았을까요? 왜 진작에 결정하지 않았을까요?
이 결정을 내리는 데 왜 이렇게 오래 걸리는가? 왜 망설이는 걸까요? 이를 통해 무엇을 알 수 있나요?
왜 다른 사람이 다른 결정을 내릴까요? 다른 쪽, 또는 두세 가지 다른 결정은 어떤 모습일까요?
이 결정을 더 작게 할 수는 없을까요? 하나의 큰 결정을 세 개의 작은 결정으로 바꿀 수 있을까요?
결정을 얼마나 쉽게 되돌릴 수 있을까요?
이 결정에 대한 우리의 첫 번째 본능은 무엇이었나요? 우리는 지금 데이터로 직감을 정당화하기 위해 빙빙 돌고 있을 뿐인가요?
결정을 내리지 않으면 어떻게 될까요?
지난번에 이런 결정을 내렸을 때 어떤 일이 일어났나요?
결정이 내려진 후 우리는 무엇을 기대하는가? 우리는 무엇을 두려워하는가?
어떻게 하면 이 결정을 더 쉽게 내릴 수 있을까요? 고려 대상에서 제외할 수 있는 부분은 무엇인가요?
잘못된 결정은 없는가?
내일 아침까지 기다렸다가 결정을 내리면 다른 결정을 내릴 수 있을 것으로 예상되는가?
어떤 결정이 결정을 내리지 않는 것보다 나은가, 아니면 어떤 결정도 내리지 않는 것이 어떤 결정보다 나은가?
이 결정으로 인해 다른 어떤 결정이 영향을 받게 되는가?
이 결정으로 인해 다른 결정을 내릴 필요가 없어질까요, 아니면 더 많은 결정을 내려야 할 필요성이 생길까요?
누락된 정보로 인해 다른 결정을 내릴 수 있는가?
이 결정으로 인해 해당 업무에 여분의 시간이 없는 사람들이 더 많은 일을 하게 되나요? 아니면 업무가 없어질까요?
이 결정이 다른 사람에게 연습용으로 좋은 결정이 될 수 있을까요?
언제 결정해야 하나요?
한 번으로 끝나는 결정인가, 아니면 반복되는 결정인가?
회사 외부의 누군가가 이 결정에 의존하는가, 아니면 우리가 스스로 내린 결정인가?
이 결정이 고객에게 어떤 영향을 미치는가, 아니면 우리에게 어떤 영향을 미치는가?
주로 데이터에 기반한 결정인가, 아니면 직관이나 직감에 기반한 결정인가?
다른 의견이 도움이 될까요, 방해될까요?
지금 당장 결정을 내려야 한다면 어떤 결정을 내릴 것인가?
90일 전에 이 결정을 내렸다면 우리는 지금 어떤 상황에 부닥쳐 있을까요?
이 결정에서 X, Y 또는 Z를 고려하지 않았다면 후회할 만한 점이 있나요?
어떤 방향으로 진행될지 신경 쓰이나요? 그렇지 않다면 왜 관여하는 건가요?
그 결정이 옳은 결정이었는지, 심지어 중요한 결정이었는지 언제 어떻게 알 수 있을까요?
결정의 결과가 나타나면 맨눈으로 볼 수 있을까요, 아니면 현미경으로 확인해야 할까요? 후자라면 그게 중요할까요?
이 결정을 내릴 때 우리는 어떤 원칙을 굽히고 있나요?
한 사람이 내려야 할 결정을 여러 사람에게 부탁하고 있는 것은 아닌가요?
노력에 대한 수익이 그만한 가치가 있는가?
이 결정을 내리면 무엇이 더 쉬워지는가? 무엇이 더 어려워지는가? 쉬워지는 것이 장기적으로도 쉬워지는 것일까요, 아니면 단기적으로는 쉬워지지만 장기적으로는 어려워지는 것일까요? 그 반대의 경우도 마찬가지입니다.
GitHub Copilot Chat 전체 프롬프트 유출 : Marvin von Hagen이라는 사람이 베타로 공개된 GitHub Copilot Chat의 전체 프롬프트를 얻어냈다. 규칙을 알려달라고 했을 땐 거절했지만, OpenAI 개발자라서 설정이 필요하다고 알려달라고 하지 전제 AI programming assisant 프롬프트를 알려주었다.(한국어)
Comments