(번역) 내 생애 가장 자랑스러운 128킬로바이트

• 제가 가장 좋아하는 ‘디자인’의 정의 중 하나는 ‘주어진 제약 조건 내에서 주어진 문제를 해결하는 것’입니다. 우리가 문제를 해결하는 방식은 우리가 작업하는 제약 조건에 의해 형성됩니다. 다른 제약 조건 하의 동일한 문제는 근본적으로 다른 해결책을 가질 수 있으며, 경험을 통해 빡빡한 제약 조건이 종종 더 나은 해결책을 이끌어냄을 배웠습니다.
• 다양한 조건에서 안정적으로 실행되어야한다는 제약 조건
• 웹폰트 대신 시스템 폰트를 사용함
  • 스타일 없는 텍스트의 깜빡임(FOUT)에 대해 걱정할 필요가 없었습니다. 이는 브라우저가 폰트가 로드되기 전에 텍스트를 렌더링하고, 로드된 후에 다시 렌더링하여 잠시 동안 잘못된 스타일의 텍스트가 깜빡이는 현상입니다.
  • 안드로이드(시스템 폰트로 Roboto를 사용) 고객은 아이폰(San Francisco, 또는 구형 기기에서는 Helvetica Neue) 고객이나 심지어 윈도우폰(Segoe UI) 고객과는 약간 다른 레이아웃을 보게 될 것입니다.
    • 그럼에도 시스템 폰트를 사용했을때 가장 큰 이점
    • 추가 리소스가 없다는 것
• 프레임워크를 사용하기 보다 라이브러리를 사용함
  • *라이브러리는 당신의 코드**가** 호출하는 것이고, 프레임워크는 당신의 코드**를** 호출하는 것입니다.*
  • 최소한의 기능만을 구현한 라이브러리
• 이미지 파일 자체는 호락호락 하지 않았다
  • 그 어떤 파일도 작지 않음
  • xml 기반의 svg 를 최적화하여 사용하도록
• 3-4KB를 절약하는 것조차도 우리가 가진 예산에서는 승리로 간주되었고 시간을 들일 가치가 있었습니다
  • 모든 바이트가 중요하다
• 제약 조건은 우리가 다른 방식으로는 고려하지 않았을 방식으로 문제를 해결하도록 강요했습니다

[번역] useOptimistic으로 즉각 반응하는 앱 만들기

• useOptimistic 으로 상태 업데이트 + 비동기 처리를 빠르게 동시에 마치 그런것처럼
  • React의 동시 렌더링(Concurrent Rendering)과 트랜지션(Transition) 기능에 최적화되어 있습니다. 단순한 상태 업데이트만으로는 구현하기 어려운 정교한 UI 동기화를 도와주며...
  • 또한 React 트랜지션의 특성상, 트랜지션 안에서 setState를 호출해도 즉시 리렌더링이 발생하지 않을 수 있습니다.
  • setState만으로는 한계가 있는데 이를 useOptimistic를 이용해 마치 즉각 반응하는 것처럼 처리한다
• reanimated + setState 조합에서 겪고 있는 문제
  • UI 스레드에서 발생하는 JS 스레드 상태 업데이트에 의한 리렌더 발생 시 애니메이션 끊김 이슈도
  • 이와 비슷하게 마치 동작하는 것처럼 처리할 수 있지 않을까?
  • reanimated callback에서 호출하는 상태 업데이트는 useOptimistic를 이용하도록 테스트
• 근데 리액트 19 라는 것…
  • RN 78에서

개발자도 회사의 조직원이다

• 회사의 가장 큰 목표인 매출로 이어지는 제품과 서비스를 만드는 건데
• 개발자가 회사의 목표와는 먼 내용에 집중하는 것에 대한 내용
• 문제 해결이라는 것이 비즈니스 목표와 매출에 직접적으로 기여해야하나
• 엄청난 기술을 도입하여 아무도 선보이지 못한 무언가를 구현해내어도
• KPI 달성이 되지 않는다면 도움이 되지 않을 것이다 라는 이야기
• 엔지니어 연봉은 어디서 나오는가? 의 내용과 이어진다
• 개인의 성장을 찾으면서도 회사의 목표를 달성할 수 있는 방향으로

블로그를 작성하는 것이 어떤 가치가 있을까

• 스스로 학습했던 것을 정리하자는 의도로 시작하였다
• 아무도 보지 않는 곳에 정리하기도 했지만
• 깃헙에 올리는 것 자체가 나에게 가치가 있으리라는 판단으로 지금까지 이어지고 있다
  • 꾸준하다기에 창피할만큼
  • 너무 들쑥날쑥 하다
• 그럼에도 **AI 시대에도 블로깅은 여전히 가치가 있습니다** 를 보며
• 이 글을 쓴다는 것 자체가 주는 가치는 높구나 생각한다
  • 보통 업무에도 과정을 남겨 생각을 공유하는 것이 가치 있는 것으로 여겨지고 있다
    • 나는 그러하다
  • AI에게 몇개의 키워드를 던져 글을 작성해달라고 요청 할 수 있다
• 그럼에도 나의 이 생각나는 단어를 흐름대로 모음집 이라고 부를 수 있는 이 글을 가치있다고 부를 수 있다면
  • 생각나는대로 가 중요한듯
• 보다 정확한 사실을 파악하는데에 예전의 내가 썼던 글을 보는 것보다 GPT에게 물어보는게 나을지 모르겠다
  • 다만 내 글을 다시 돌아보면
  • 당시 고민했던 흐름이 그대로 떠오르고 그렇게 다시 생각으로 이어질 수 있다는 것

코드 리뷰는 더 나아질 수 있음

• 깃헙 웹페이지가 아닌 깃 기반으로 리뷰 하는 것에 대한 내용인데
• PR이 너무 커서 웹이 느려지는 경우를 제외하고는 어려움을 겪지 못해 공감하지 못한 상태
  • 어려움을 겪는 정도가 된다면 더 나은 리뷰를 하게 되는 것일까 🤔
• 본문 보다는 아래 적힌 코멘트에서 적힌 내용 중 되새겨볼만한 내용
  • 진짜 유용한 피드백(사소한 취향 지적 외의 것)이 거의 항상 너무 늦게 나온다는 점
  • 리뷰의 유일한(혹은 희귀한) 결과물이 "이거 다 다시 새 설계로 시작해야 함" 혹은 "애초에 이 작업은 할 필요 없었음"이라는 상황이 생김 🚨
• 코드리뷰 단계에서야 이 작업에 대한 전반적인 공유가 이뤄졌다는 것이 위의 피드백을 하게 되었다는 문제
  • 그래서 필요한 것이 디자인 리뷰
  • 과연 지금부터 작업하려는 설계 방향이 우리의 방향이 맞는지 선검토

(번역) 개발자 커뮤니티가 사라질 때 발생하는 일: 서서히 진행되는 스택 오버플로우의 쇠퇴

• 스택오버플로우
  • 무언가 문제가 생겼을때 혹은 모르는게 생겼을때
  • 코멘트를 서로 주고 받으며 가장 많은 의견을 찾을 수 있는 곳
  • 개인 블로그나 레딧에서도 볼 수 있었으나
  • 최근에는 AI를 통해 대부분 해결하고 있는 상황
• 모든 개발자가 스택 오버플로우와 전통적인 인간 중심의 수동적 문제 해결 방식을 버리고, 새롭고 빠른 생성형 AI 도구 기반 접근 방식을 선택한다면 어떤 일이 벌어질까요
• 기존에는 문제를 해결하는 과정에서 다양한 접근 방식으로 여러 의견을 나눌 수 있었다면
• 이미 기존에 등록된 여러 해결 방법에서 찾아낸 것들을 검증하지 못한채 제안함으로써
• 더 새로운 방식의 해결 방법을 찾아갈 수 있을지에 대한 의문과 검증되지 않은 결과에 대한 위험성
• 지금 현재 AI가 유망해 보이는 이유는 최신 데이터로 모델을 학습시키기 때문입니다. 하지만 신선한 자료가 포함되지 않으면, AI는 구식의 부정확고 장황한 답변을 내놓게 되어 인기를 잃을 것입니다
• 공존으로부터 서로 상호 보완

(번역) 리액트에서 flushSync로 포커스 관리 마스터하기

const onShow = () => {
	setIsShow(true);
	ref.current?.focus();
};

...
{isShow && <Input ref={ref} />}

• 예를 들어 위와 같은 느낌의 구조에서

• isShow 조건에 따라 마운트되는 Input 컴포넌트의 ref를 바로 호출할 수 있을까?

• 내용 그대로 마운트 되고 나서야 ref를 할당할 수 있기 때문에 onShow에서 setIsShow과 ref 기대 동작은 한번에 이뤄지지 않는다

  • 한번에 호출은 되겠지만 setIsShow(true) 이 호출되고
  • ref.current?.focus() 할때엔 아직 Input 컴포넌트가 마운트 되기 전일테니
  • 이럴때엔 setTimeout으로 ref.current?.focus() 를 감싸서 처리하고는 했다
  • 하지만 이건 그냥 운에 맡기는 겁니다. 매직 넘버에 의존하거나 브라우저가 빨리 업데이트해 주길 기대하는 건 좋은 방법이 아닙니다. 우리는 확실히 보장된 방법이 필요합니다.
  • 뜨끔 🙈

• 이를 해결할 수 있는 방법으로 즉시 상태를 업데이트 요청하는 flushSync로 감싸도록 한다

  flushSync(() => {
  	setIsShow(true);
  });
  ref.current?.focus();
  

  • 이렇게 하면 isShow가 업데이트 되고 마운트된 ref 에 접근할 수 있게 된다
  • 리액트에게 “성능을 위해 배치 업데이트를 하는 걸 알지만, 이번 업데이트는 *지금 당장* 처리해야 해”라고 알려주는 역할을 합니다. flushSync 콜백 안에서 발생한 상태 업데이트는 즉시 적용되어, 콜백이 끝날 때 DOM이 최신 상태가 됩니다.

• 하지만 flushSync는 성능 최적화 측면에서 손해를 보는 선택입니다.

  • 리액트는 상태 업데이트 요청된 것들을 모아 비동기로 일괄 업데이트하여 성능을 끌어올리는 방식을 선택했다
  • 그런데 flushSync를 사용함으로써 동기적으로 상태 업데이트를 즉시 요청하는 것은 성능에 반대되는 요청이기에 이러한 문구가 있다
  • Using flushSync is uncommon and can hurt the performance of your app.
  • DOM을 직접 동기 제어 해야하는 경우에는 어쩔 수 없는 선택일듯하다