techblog
by ricale

읽은 글들 (~25.2.28)

2025. 2. 28.

시리즈 "읽은 글들"

▲

React Native

Shopify의 5년간 React Native 사용 경험

(GeekNews 요약)

Shopify 가 모든 앱 개발을 네이티브에서 React Native 로 전환하면서 경험하고 느낀 것을 공유한 글. 상당히 긍정적인 시선이다.

원문은 읽지 않고 GeekNews 요약만 읽었는데, 해당 요약문에서도 개인적으로 주목할만한 부분을 다시 추려보았다.

  • React Native 앱은 빠름
    • 5년이 지난 지금, RN 앱은 빠르게 동작하며, Shopify 앱에서 500ms 이하(P75)의 화면 로드 시간을 달성
    • 네이티브가 항상 빠르다는 보장은 없으며, RN이 항상 느린 것도 아님
    • RN 프레임워크가 성숙해지면서 빠른 앱을 개발하는 것이 점점 더 쉬워질 것으로 기대
  • 네이티브 개발자는 필수적임
    • 플랫폼 레이어에 접근하거나, 바인딩 작성, 빌드 및 배포 마스터링, 그리고 React Native 버전 업데이트를 관리하는 등의 작업은 네이티브 전문 지식이 필요
    • 네이티브 개발자는 다양한 기기 모델에서 앱 성능을 최적화하고, 모든 사용자에게 일관된 경험 제공
    • iOS와 Android의 새로운 기능, API, 툴링 변화에 대응하고 React Native 버전 업데이트를 관리하는 데 필수적
  • 네이티브 코드는 필수적임
    • 100% React Native 사용은 지양해야 함: RN은 기능을 한 번만 개발해도 되는 효율적인 도구지만, 모든 상황에 적합한 기술은 아님
  • React Native 업데이트는 심리스 하지 않음
    • React Native(RN)의 새로운 버전으로 앱을 업데이트하는 데 많은 작업이 필요하며, 종종 코드베이스 재구성이 요구됨
    • Shopify는 이를 해결하기 위해 소규모 순회 개발자 그룹을 구성하여 업데이트 작업을 전담하게 하고, 나머지 팀은 기능 개발에 집중하도록 조정
  • React Native의 미래
    • React Native(RN)의 미래는 밝으며, Meta는 이 프로젝트의 훌륭한 관리자로서 정기적인 개선을 제공하고 있음
    • RN은 지난 5년간 큰 발전을 이루었으며, 도입을 주저하게 만들었던 많은 한계들이 이제는 사라짐
    • RN을 한동안 안 써봤다면 지금은 RN을 다시 시도해 볼 적기임

특히 RN 의 성능에 만족하고 있는 것이 인상적이다.

Frontend

[번역] 모든 프런트엔드 개발자가 알아야 할 접근성 필수 사항

이래서 기자들이 기사의 제목을 자극적으로 짓는 것인가 싶을 정도로 자극적인 제목이라 누르지 않을 수 없었다.

이런 글을 볼 때마다 느끼는 건, 외국(아마도 특히 서양)에서는 장애인 혹은 제한된 환경에 대해 지원하는 것을 중요하게 생각한다는 것. 우리나라는 아직 그런 분위기가 아니라 볼 때마다 신선하다.

  • 시맨틱 HTML: 시멘틱에 맞는 HTML 을 사용하자.
  • 폼: 폼 밖에 input 을 두지 말자. 또한 label 과 placeholder 를 적절히 사용하자.
    • "플레이스홀더는 라벨의 대체물이 아닙니다." 라는 문구가 마음에 든다.
  • 키보드 내비게이션: 탭 키로의 포커스 이동을 잘 지원하자.
    • :focus-visible 속성도 눈여겨볼만 하다. 포커스 될 때마다 포커스링이 표시되는 게 싫은 사람들을 위한 속성.
  • 모달: 이제 <dialog /> 태그가 대부분의 브라우저에서 잘 동작하니 모달을 직접 구현하지 말고 해당 태그를 적극 활용하자.
    • <dialog /> 태그를 좀 자세히 찾아봐야겠다.
  • 이미지 대체 텍스트
    • nextjs lint 가 항상 강조하는 alt 에 대한 내용.
  • 스타일링: 스타일링을 잘하자
  • ARIA 속성: 접근성을 위한 aria-* 속성을 잘 활용하자.
    • aria-label 과 aria-hidden 에 대해 강조한다.

[번역] dialog 요소가 가진 슈퍼 파워 알아보기

바로 위 글에서 <dialog /> 를 사용하라고 했던 게 생각나서 찾아본 글. <dialog /> 사용 방법에 대한 기본을 다루고 있다.

Use the dialog element (reasonably)

윗 글과 맞물려서 찾아본 글. 아직 <dialog /> 태그가 완벽하지는 않지만, 이제는 모달을 직접 구현하는 것보다는 더 나은 선택지가 되었다는 내용의 글이다. 작성 시기는 23년 1월인 걸 보면, 이미 2년이 지난 지금은 더 쓸만한 선택지이지 않을까 싶다.

TypeScript

The bottom type never in TypeScript

타입스크립트의 never 타입에 대해 설명한다.

CSS

(번역) 잘 가 SASS, 다시 만나 반가워 네이티브 CSS

이제 대부분의 SASS 기능을 CSS 에서 지원해주기 때문에 SASS 를 굳이 사용할 필요가 없다는 내용의 글.

글에서 언급한, SASS 가 필요 없어지게 만든 CSS 의 기능들은 아래와 같다.

  • 변수
  • CSS 중첩
  • :is()
  • :has()
  • @container 쿼리
  • Cascade Layers

여전히 SASS 에서만 지원하는 기능이 있다곤 하지만

Etc

Why does Windows use backslashes for paths and Unix forward slashes?

문득 궁금해져서 찾아본, "왜 윈도우즈는 슬래시가 아닌 역슬래시를 사용할까?" 에 대한 글.

간단히 요약하면 "MS-DOS 에 디렉토리 개념을 도입할 당시 slash 는 이미 다른 용도로 사용하고 있었기 때문에 충돌을 피하기 위해 backslash 사용".

원래는 저작권 문제 같은 걸로 알고 있었는데 완전 잘못된 내용이었다.

[GeekNews] 나이 들어가는 프로그래머 - [발표영상] 요약

(원본 영상)

평생 프로그래밍 하면서 살아가려면 무엇을 준비해야 할까? 애 대한 내용. 시력, 뇌 등등 건강에 관련된 내용이 많다. 평생 프로그래머로 사는 게 목표이기도 한 지라 더 눈에 들어온다.

, 그 기능이 꼭 필요한 게 아닌 이상 굳이 사용할 필요가 없어보인다.

Do not use secrets in environment variables and here's how to do it better

.env 파일에 secret 을 관리할 경우 생길 수 있는 보안 취약점에 대해 이야기한다.

저자가 친절히 정리해둔 목차에 의하면 아래와 같은 이유로 취약점이 생길 수 있다.

  • 이유 1: 환경 변수에 저장된 시크릿은 제대로 관리되지 않을 가능성이 높다
  • 이유 2: 프론트엔드와 백엔드(SSR) 경계가 모호해져 시크릿이 유출될 위험이 있다
  • 이유 3: .env 파일에 저장된 시크릿은 유출되기 쉽다
  • 이유 4: 로그를 통해 시크릿 데이터가 유출될 수 있다
    • 실제 사례: Seneca CVE-2019-5483
  • 이유 5: 생성된 프로세스는 기본적으로 동일한 환경 변수를 공유한다
    • FAQ: “내 애플리케이션은 자식 프로세스를 생성하지 않는데도 문제가 되나?”
  • 이유 6: 환경 변수는 프로세스 목록에서 볼 수 있다
    • FAQ: “다른 사용자의 프로세스를 볼 수 없는 것 아닌가?”
    • FAQ: “시스템에 접근하는 것이 어렵지 않나?”
    • 경로 탐색 취약점(Path Traversal)이 환경 변수의 시크릿을 노출할 수 있다
  • 이유 7: Docker 빌드 인수(Build Arguments)와 .env 파일이 Docker 이미지에 유출될 위험이 있다

간단히 줄이자면 아래와 같은 이유로 취약점이 생긴다고 말할 수 있다.

  • 개발자의 실수로 인한 유출
  • 서드 파티 라이브러리에서의 의도치 않은 유출
  • 프로세스/OS 레벨에서의 의도치 않은 유출

이는 개발자가 조심해서 막을 수 있는 수준이 아니고, 따라서 저자는 애플리케이션의 환경 설정과 시크릿은 명백히 분리되어 관리되어야 할 사항이라고 말하며 해결책을 제시하고 있다.

    1. “Secret Zero” 문제 해결
    • 비밀정보를 분리해도 해당 비밀정보에 접근하기 위한 비밀이 또 필요하다는 딜레마가 있다. 이 경우 "비밀정보에 접근하기 위한 비밀"을 단기(short-lived) 이며 제한된 사용 횟수(limited usage count) 로 관리해야 한다.
    1. 가장 쉽고 편리한 방법: 시크릿 스토어(Secrets Stores)
    • 예) 1Password
    1. 더 안전하지만 더 복잡한 방법: 시크릿 관리 서비스(Secrets Management Services)
    • 예) Infisical, HashiCorip Vault, 혹은 Google Cloud Secret Manager 같은 클라우드의 시크릿 관리 서비스

글이 길긴 하지만 예시와 자세한 설명이 있으므로 읽어보기를 권한다.

목차