Outsider's Dev Story

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

기술 뉴스 #247 : 24-06-01

웹개발 관련

  • Rethinking Text Resizing on Web : Airbnb가 접근성을 높이기 위해 WCAG의 권고에 따라 텍스트 크기를 2배로 키웠을 때도 웹 콘텐츠와 기능이 유지되도록 개선한 과정이다. 텍스트의 단위에 px, em, rem이 있지만 일관되고 예측할 수 있는 rem을 선택했고 후처리 도구를 만들어서 CSS에서 작성한 px를 자동으로, rem으로 변환하도록 했고 Figma 플러그인을 만들어서 디자인 단계에서 텍스트가 커졌을 때의 문제를 미리 확인할 수 있게 했다. 데스크톱은 확대에 대한 영향이 크지 않았지만, 모바일에서는 영향이 심했고 브라우저가 차이도 있었지만, rem 자동 변환을 통해서 쉽게 적용할 수 있었다.(영어)
  • Why, after 6 years, I’m over GraphQL : 오랫동안 GraphQL을 사용해왔고 옹호했지만, 최근에 그 입장이 변경되어 더는 추천하지 않는 이유를 정리한 글이다. 클라이언트에 쿼리 언어를 노출했기에 권한 부여나 Rate limit 같은 공격 표면이 늘어났고 N+1 성능 문제도 겪게 된다. 그리고 GraphQL에서는 비즈니스 로직이 전송 계층으로 이동되기 때문에 커플링이 심해지고 복잡해지는 문제가 있다.(영어)
  • WCAG 2.2 한국어 번역본 공개 : 작년 10월에 표준을 나온 웹 콘텐츠 접근성 가이드라인(WCAG) 2.2을 조현진 님이 한국어로 번역해서 공개했다.(영어)
  • State of HTML 2023 : HTML 생태계의 상황을 2만여 명에서 설문 조사해서 정리한 결과이다. From, 상호작용, 접근성 등 각 기능의 사용 여부와 알려진 정도를 살펴볼 수 있고 정적 사이트 생성기나 API의 사용 정도를 알 수 있다.(영어)
  • 패키지 매니저의 과거, 토스의 선택, 그리고 미래 : JavaScript 패키지 매니저는 의존성을 처리하기 위해 어떤 의존성인지 고정하는 Resolution 단계, 해당 의존성을 다운로드 받는 Fetch 단계, 소스코드에서 해당 의존성은 사용할 수 있게 하는 Link 단계로 이뤄진다. 이 Link 단계가 npm, pnpm, yarn이 다른 접근을 하고 있는데 npm은 package.json의 의존성은 node_modules 폴더 아래 모두 작성하고 nnpm은 이 모두 파일에 쓰는 성능 문제를 해결하기 위해 모두 쓰지 않고 alias를 만들어서 연결하고 yarn은 Plug'n'Play 방식을 사용해서 .pnp.cjs 파일에 JavaScript Map으로 의존성을 찾는 방법을 명시해서 훨씬 빠르고 정확하게 동작할 수 있다. Toss는 Yarn의 좋은 아키텍처, 정확성과 성능 때문에 Yarn을 선택했다고 한다.(한국어)
  • Manifest V2 phase-out begins : 작년 11월 Chrome에서 공지한 대로 크롬 익스텐션의 Manifest V3의 도입으로 6월 3일부터 Manifest v2를 사용하는 익스텐션에서는 지원되지 않는다는 경고가 뜰 것이고 점진적으로 비활성화될 예정이다.(영어)

그 밖의 개발 관련

  • Introducing GitHub Copilot Extensions: Unlocking unlimited possibilities with our ecosystem of partners : GitHub Copilot의 Extensions가 발표되었다. 아직 Limited Beta라 직접 볼 수는 없지만 서드파티 서비스가 Copilot Extension을 만들면 VS Code를 벗어나지 않고 Copilot Chat에서 해당 서비스에 연결된 정보를 물어볼 수 있어서 바로 등록된 리소스의 정보나 배포 상태 등을 확인할 수 있다. 회사 내에서 비공개 Extension도 만들 수 있어서 내부 API나 데이터와 연동하면 회사 내의 정보도 Copilot에서 사용할 수 있다.(영어)
  • Keeping it 100(x) with real-time data at scale : Figma가 실시간으로 데이터를 가져오기 위해 내부에서 LiveGraph를 사용하는데 서비스의 성장에 따라 LiveGraph의 아키텍처도 다시 설계할 수밖에 없었다. 2년 전에 LiveGraph는 단일 Postgres의 replication stream에 의존한 구조였는데 부하가 커지면서 수직 샤드로 분할되자 전역으로는 순서가 보장되지 않았고 결국 큰 한계를 맞이하게 된다. LiveGraph는 실시간 업데이트를 위해 만든 서비스지만 트래픽을 분석하자 대부분은 초기 데이터 조회라는 것을 알게 되었고 쿼리를 분석한 결과 어떤 쿼리를 다시 조회해야 하는지 파악이 쉬워서 이에 따른 캐시 무효화도 쉽다는 것을 발견한다. 그래서 새로운 LiveGraph 100x는 Go로 만들었고 클라이언트의 뷰 요청을 처리하는 엣지, 쿼리 결과를 저장하는 읽기 캐시, 변경이 있으면 캐시 무효화하는 invalidator로 구성했다.(영어)
  • Visualizing algorithms for rate limiting : 특정 사용자가 서비스의 리소스를 모두 차지하지 않도록 하는 Rate Limit의 구형 방법을 설명한다. Fixed window는 가장 간단하고 사용자가 예측하기 쉽지만, 창 시작 시에 요청이 몰리거나 창의 시간이 긴 경우 타임존의 영향이 있을 수 있고 Sliding window는 동시에 받을 수 있는 개수를 제한해서 요청을 원활하게 분산할 수 있지만 리소스가 많이 필요하다. Token bucket은 버킷에 토큰이 있어야만 요청을 보낼 수 있고 일정 시간 간격으로 버킷이 채워지는 형태라 유연하지만, 사용자의 예측성이 떨어진다. 각 방식을 애니메이션으로 보여주어 이해하기 좋다.(영어)
  • Milo: A new HTTP parser for Node.js : Node.js는 HTT 파서로 초기에 사용하던 http_parser를 12.0부터 C로 변환해서 실행하는 llhttp 계속 사용해 왔다. llhttp의 한계를 해결하기 위해 Rust로 작성된 Milo가 만들어졌고 뛰어난 성능과 기능을 갖추었기에 WebAssembly 최적화만 완료되면 Node.js에 도입될 예정이다.(영어)
  • Introducing TypeSpec: A New Language for API-Centric Development : Microsoft에서 API 정의 언어인 TypeSpec을 공개했다. TypeSpec을 사용하면 API를 정의한 후 다양한 프로토콜, 클라이언트, 서버, 문서를 동시에 출력할 수 있고 이미 Microsoft 내에서 Azure의 많은 서비스에 TypeSpec을 사용하고 있다.(영어)
  • Introducing the ESLint Configuration Migrator : ESLint가 v9.x부터 새로운 Flat config가 도입되어서 사용자가 겪는 어려움을 해결하기 위해 .eslintrc.* 파일을 eslint.config.js로 변환하는 ESLint Configuration Migrator를 공개했다.(영어)
  • Meet Studio: Your New Favorite Way to Develop WordPress Locally : Wordpress의 로컬 개발 환경을 쉽게 구축할 수 있도록 Studio를 공개했다. Studio를 사용하면 로컬에서 Wordpress를 실행하고 작업 중인 사이트를 공유할 수 있다.(영어)

인프라 관련

  • State of DevSecOps : Datadog에서 24년 2~4월까지 수집한 애플리케이션, 컨테이너 이미지, 클라우드 환경을 분석해서 DevSecOps의 현황을 분석한 자료다. 발견한 특징을 다음과 같이 정리했다.(영어)
  1. Java 서비스는 서드파티 취약점의 영향을 가장 많이 받는다.
  2. 자동화된 보안 스캐너의 공격 시도는 대부분 조치할 수 없는 노이즈다.
  3. 식별된 취약점 중 일부만 우선순위를 정할 가치가 있다.
  4. 경량 컨테이너 이미지를 사용하면 취약점이 감소한다.
  5. Infrastructure as Code의 도입률은 높지만, 클라우드 업체별로 꽤 차이가 있다.
  6. 수동 클라우드 배포는 여전히 널리 퍼져있다.
  7. CI/CD 파이프라인에서 수명이 짧은 크리덴셜의 사용률이 여전히 너무 낮다.
  • How to use Grafana Beyla in Grafana Alloy for eBPF-based auto-instrumentation : 최근 공개한 OpenTelemetry Collector인 Grafana Alloy에서 eBPF 기반 자동 계측 도구인 Grafana Beyla를 사용할 수 있게 되었다. 이 글에서는 Beyla를 사용해서 서비스의 RED 메트릭과 Kubernetes 애플리케이션을 자동 계측해서 Alloy로 수집하는 방법을 보여준다.(영어)

볼만한 링크

  • QUESTIONABLE ADVICE: “MY BOSS SAYS WE DON’T NEED ANY ENGINEERING MANAGERS. IS HE RIGHT?” : 어떤 사람이 40명 엔지니어 조직에 VP로 합류해서 엔지니어링 관리자를 뽑는 일에 대해 CEO와 갈등을 겪는다는 질문에 Honeycomb의 CTO인 Charity Majors가 답변을 정리한 글이다. 이런 류의 질문에 정답은 없지만 Charity의 답변은 꽤 생각할 부분이 있다고 생각한다.(영어)
    • 계층 구조는 실제로는 권위적인 구조라기 보다는 적응성, 탄력성, 확장성에 중요한 역할을 하며 하위 시스템의 이익을 위해 생겨난 것이다.
    • 시스템은 공통의 목표를 달성하기 위해 상호 의존적인 구성 요소의 네트워크이다.
    • 하위 시스템은 큰 시스템 내에서 더 작은 목표를 가진 요소들의 집합이다.
    • 계층 구조의 주요 이점은 정보 과부하를 줄이는 것이다. 팀 내 커뮤니케이션은 대역폭이 높고 빨라야 하고 팀 간 커뮤니케이션은 더 적게 이루어져야 한다.
    • 해야 할 일이 제대로 이뤄지도록 하는 것이 관리자의 역할이다. 모든 엔지니어에게 흥미롭고 도전적이지만 부담스럽지 않은 업무를 부여하고 불쾌한 노동이 공평하게 배분되도록 하는 것도 관리자의 역할이다.
    • 엔지니어는 개발, 배포, 유지 보수하는 소프트웨어에 책임이 있고 관리자는 팀과 조직 전체에 책임이 있다.
    • 자연스러운 계층 구조에서 목적을 위해 위를 보고 기능을 위해 아래를 본다.
    • 대부분의 엔지니어링 조직에는 엔지니어링 관리자가 있다.
    • 알고 있는 매니저 없는 실험은 모두 포기되거나 성장하지 못했다. 경험상 리더들이 권력에 빠져서라기보다는 혼란, 집중력 부족, 실행력 부족으로 인한 것이었다.
    • 명시적인 구조나 위계가 없을 때, 자유와 평등이 아니라 "비공식적이고 인정받지 못하며 책임지지 않는 리더쉽"이 될 수 있다.
    • 그룹 수는 적지만 그룹 규모가 크면 전반적인 관리 오버헤드가 줄어들고 조율 작업도 훨씬 줄어든다.
    • 엔지니어링 매니저가 모든 작업을 수행하고 결정하는 것은 아니지만 경험상 작업이 제대로 이루어지고 잘 수행되도록 하는 데는 절대적으로 중요한 역할을 한다.
    • 사실 관리는 오버헤드이다. 작업은 중요하지만, 그 자체가 비즈니스를 발전시키는 것은 아니고 꼭 필요한 만큼만 하고 그 이상은 하지 않아야 한다.
  • Instead of "auth", we should say "permissions" and "login" : 보통 auth라고 할 때 인증(authentication)과 인가(authorization)라는 2가지 문제가 있어서 혼란스럽게 만든다. authn과 authz로 나누어서 부르기도 하지만 해결책이 되지 않기 때문에 이를 로그인과 권한으로 부르는 것이 더 좋다고 얘기한다.(영어)

IT 업계 뉴스

프로젝트

  • 100 Exercises To Learn Rust : 실습을 따라 하면서 Rust 언어를 배울 수 있는 튜토리얼.
  • Slidev : Markdown 기반 문법으로 슬라이드를 만들 수 있는 도구.
  • amber : Bash로 컴파일되는 프로그래밍 언어

버전 업데이트

Comments

RetroTech 팟캐스트 44BITS 팟캐스트
Valid HTML5 Valid CSS WCAG 2.1 AA tested