기술 블로그

iOS에서만 느려지는 sticky 탭바 해결하기

jaegwan — Tue, 18 Aug 2026 15:33:09 +0900

반응형 UI를 만들다 보면 데스크톱에서는 멀쩡한데 실기기에서만 어긋나는 문제를 마주하곤 합니다. 최근 메인 페이지의 sticky 탭바가 실기기 아이폰에서만 스크롤을 한 박자 늦게 따라오는 현상을 겪었습니다. 크롬 개발자도구의 모바일 에뮬레이터에서도 재현되지 않아 원인을 좁히기가 쉽지 않았고, 가설을 두 번 세워 두 번 다 기각당한 끝에 전혀 다른 파일의 공통 mixin 한 줄에서 범인을 찾았습니다.

이번 포스트에서는 그 과정을 브라우저 렌더링 엔진의 관점에서 정리합니다.

1. 현상 및 재현 조건

메인 페이지의 '성공 레퍼런스' 섹션에는 모바일에서 상단에 고정되는 탭바가 있습니다. 사이트 헤더(높이 60px) 바로 아래에 붙고, 스크롤로 헤더가 숨으면 그 빈자리로 올라오는 구조입니다.

.tabBarSticky {
  width: 100%;

  @include small {
    position: sticky;
    top: 60px;
    z-index: 10;
    transition: top 300ms ease-in-out;
  }
}

.tabBarStickyUp {
  @include small {
    top: 0; // 헤더 숨김 시 헤더가 비운 자리로
  }
}

문제: 실기기 아이폰에서 탭바가 스크롤에 딱 붙지 않고 한 프레임 이상 끌려다니다가, 스크롤을 멈추면 툭 하고 제자리로 돌아옵니다. 특히 화면에서 손을 뗀 뒤 관성(momentum) 스크롤 구간에서 두드러졌습니다.

재현 조건:

환경	결과
데스크톱 크롬	정상
크롬 DevTools 모바일 에뮬레이터	정상
실기기 iOS Safari (≤480px)	재현

에뮬레이터가 뷰포트 크기만 흉내 낼 뿐 WebKit의 합성·스크롤 처리까지 재현하지는 않기 때문에, 이 문제는 처음부터 실기기에서만 볼 수 있었습니다.

초기 가설: transition: top이 컴포지터 속성이 아니라서 생기는 지연.

2. 가설 1 — `transition: top`은 컴포지터 속성이 아니다

가장 먼저 눈에 띈 것은 트랜지션의 대상이었습니다. 헤더와 탭바가 서로 다른 방식으로 움직이고 있었습니다.

	사이트 헤더	탭바
이동 수단	`transform: translateY(-100%)`	`top: 60px → 0`
처리 주체	GPU / 컴포지터	메인 스레드 (레이아웃)

transform은 메인 스레드가 바빠도 컴포지터가 혼자 300ms를 그려냅니다. 반면 top은 레이아웃 속성이라 매 프레임 재계산이 필요하고, 대상이 position: sticky이므로 sticky 제약(constraint)까지 매 프레임 다시 계산해야 합니다.

게다가 WebKit은 sticky 요소의 컨테이너 사각형과 오프셋(top 포함)을 스크롤링 트리에 한 번 커밋해두고, 이후에는 스크롤 스레드가 알아서 위치를 잡아주는 구조입니다. 그런데 top이 애니메이션 중이면 그 커밋값이 매 프레임 바뀝니다. 즉 트랜지션이 도는 300ms 동안 sticky가 fast path에서 떨어진다는 추론이었습니다.

그럴듯했습니다. 그래서 transition과 .tabBarStickyUp의 top: 0을 통째로 주석 처리하고 다시 테스트했습니다.

결과: 그대로 느림

가설 1 기각. 하지만 이 실패가 중요한 정보를 줬습니다.

top이 아예 바뀌지 않는데도 느리다면, 문제는 "움직일 때"가 아니라 "그냥 스크롤할 때" 입니다. 트랜지션이 sticky를 fast path에서 떨어뜨린 것이 아니라, sticky가 애초에 fast path에 올라간 적이 없었다는 뜻입니다.

참고로 이 시점에 놓친 것이 하나 있습니다. CSS만 껐을 뿐 JS는 그대로였습니다. 스크롤 방향을 감지하는 useHideOnScroll() 훅이 여전히 방향이 바뀔 때마다 setState를 호출해 섹션 전체(차트 + motion 노드 4개)를 리렌더하고 있었습니다. 그 결과로 붙는 클래스가 아무 일도 하지 않을 뿐, 비용은 그대로 내면서 효과만 없앤 상태였습니다. 별도로 정리할 부채입니다.

3. 가설 2 — 합성 레이어 폭증

position: sticky가 fast path에 올라가지 못하는 이유로 다음에 의심한 것은 레이어 예산 초과였습니다.

프로젝트에는 GSAP SplitText 기반 헤딩 컴포넌트가 있습니다. 스크롤 진입 시 글자 단위로 등장하는 효과인데, 내부를 열어보니 다음과 같았습니다.

// 트윈 쪽
willChange: "transform, opacity",
force3D: true,               // → translate3d()

// 그리고 컴포넌트 루트 인라인 스타일
const style: React.CSSProperties = {
  willChange: "transform, opacity",   // 영구. 애니메이션이 끝나도 지워지지 않음
};

force3D: true와 will-change가 함께 걸리면 쪼개진 글자 하나하나가 각각 GPU 합성 레이어로 승격됩니다. 그리고 애니메이션이 끝난 뒤에도 will-change가 요소에 그대로 남습니다.

홈 페이지는 섹션이 12개이고 전부 같은 헤딩 컴포넌트를 쓰며, 하나가 2~~3줄을 렌더합니다. 한국어 제목이 15~~25자이므로 대략 이런 계산이 나옵니다.

12 섹션 × 2~~3줄 × 15~~25자 ≈ 수백 개의 영구 합성 레이어

데스크톱 크롬은 이 정도를 그냥 삼킵니다. 하지만 iOS WebKit은 타일/레이어 메모리 예산이 훨씬 빡빡해서, 한도를 넘으면 레이어를 퇴출하고 메인 스레드 페인팅으로 되돌립니다. 그 과정에서 sticky의 fast path가 날아갈 수 있다고 봤습니다.

결과: 이것도 아니었습니다

루트의 willChange 한 줄을 주석 처리하고 테스트했지만 변화가 없었습니다.

가설 2도 기각. 다만 엄밀히 말하면 이 테스트는 불완전했습니다. 지운 것은 부모 span의 will-change뿐이고, 글자 하나하나를 승격시키는 트윈 쪽 willChange + force3D는 그대로 남아 있었기 때문입니다. 이후 진범이 잡히면서 이 줄기는 접었지만, 레이어 폭증 자체는 여전히 정리해야 할 성능 부채로 남아 있습니다. 원인은 아니었어도 좋은 상태는 아니니까요.

4. 전환점 — "어디서"가 아니라 "언제만"

두 가설이 연달아 깨지고 나서 질문을 바꿔봤습니다.

지금까지는 "왜 아이폰에서만 느린가"를 물었고, 그래서 계속 iOS/WebKit 쪽만 팠습니다. 그런데 다시 보니 조건이 하나 더 있었습니다.

이 sticky는 @include small(≤480px)에서만 켜집니다. 즉 증상은 "아이폰에서만"이 아니라 정확히는 "small 브레이크포인트에서만" 이었습니다.

그렇다면 @include small 안에만 존재하는 CSS를 전부 다시 읽어야 했습니다. 그리고 sticky의 조상 체인을 따라 올라가자마자 답이 나왔습니다.

// _section.scss — 홈 섹션 공통 mixin
@mixin home-section {
  @include flex(column, center, center);
  width: 100%;

  @include medium {
    max-width: 648px;
  }
  @include small {
    overflow-x: clip;   // ← 여기
  }
}

.tabBarSticky의 부모인 .section이, 정확히 문제가 발생하는 그 브레이크포인트에서만 클리핑 컨테이너가 되고 있었습니다.

한 줄을 지우고 테스트했더니 해결되었습니다.

5. 원인 분석 — 왜 `overflow: clip`이 sticky를 망가뜨렸나

WebKit은 sticky 요소를 스크롤 스레드에서 처리할지 판단할 때, 해당 요소부터 스크롤 컨테이너(여기서는 뷰포트)까지 레이어 체인을 거슬러 올라갑니다. 이때 "클리핑은 하지만 스크롤은 하지 않는 조상" 을 만나면 비동기 처리를 포기합니다. 컴포지터 입장에서 "따로 움직이는 클립"을 표현할 방법이 없기 때문입니다.

fast path에서 떨어지면 이렇게 됩니다.

	정상 (fast path)	떨어졌을 때
스크롤 처리	스크롤 스레드	스크롤 스레드
sticky 위치 갱신	스크롤 스레드가 함께	메인 스레드가 뒤늦게
관성 스크롤 중	딱 붙어 있음	끌려다니다 멈추면 툭

iOS에서 스크롤은 컴포지터가 먼저 그리고 JS/메인 스레드가 뒤따르는 구조이므로, sticky 갱신이 메인 스레드로 내려가면 구조적으로 한 프레임 이상 늦습니다. 데스크톱 크롬에서 보이지 않았던 것은 Blink의 sticky 구현이 다르고 메인 스레드가 한가했기 때문입니다.

6. 그런데 `clip`을 고른 판단 자체는 옳았습니다

해당 줄에는 주석으로 이유가 적혀 있었습니다.

// clip: overflow-x:hidden 이면 브라우저가 overflow-y 를 auto 로 계산해
// 세로 스크롤바가 생김 → clip 으로 회피.

그리고 이건 맞는 얘기입니다.

	`overflow-x: hidden`	`overflow-x: clip`
자르는가	O	O
스크롤 컨테이너 생성	O	X
반대축(`overflow-y: visible`)	`auto`로 강제 계산 → 세로 스크롤바	`visible` 유지

CSS 스펙상 한 축이 visible이고 다른 축이 visible/clip이 아니면, visible인 쪽이 auto로 계산됩니다. hidden은 스크롤 컨테이너가 되므로 이 규칙에 걸리고, clip은 걸리지 않습니다.

즉 "세로 스크롤바를 피하려고 hidden 대신 clip을 썼다"는 결정은 정확했습니다. 다만 clip은 스크롤 컨테이너를 만들지 않을 뿐, 클리핑 레이어는 여전히 만듭니다. WebKit이 걸린 지점은 그쪽이었습니다.

스펙 레벨에서 옳은 선택이 합성(compositing) 레이어에서 대가를 치른 케이스입니다. 두 층위는 별개로 판단해야 합니다.

7. 삭제해도 안전한가 — 검증

"원인이니까 지운다"로 끝내면 안 됩니다. 저 줄이 원래 무엇을 막고 있었는지 확인해야 했습니다.

7-1. 왜 있었나

git 이력을 확인했습니다.

aec4b26  refactor: main 컴포넌트 section스타일 공통화

이 커밋은 mixin으로 승격만 했을 뿐, 그 이전부터 Agency·SuccessReference 각 파일에 있던 줄이었습니다. 커밋 메시지에도 주석에도 "어떤 오버플로를 잡았다"는 기록이 없었습니다. 해당 섹션들에 white-space: nowrap + flex-shrink: 0 조합(칩·배지·라벨)이 많은 것으로 보아, 특정 버그를 잡은 것이 아니라 "모바일에서 뭐라도 삐져나가면 잘라라"는 예방적 안전망으로 깔아둔 것으로 보였습니다.

7-2. 이 clip은 뷰포트 가장자리에서만 자르고 있었습니다

레이아웃 체인에 좌우 padding도, max-width도 없습니다.

body            max-width:100vw · overflow-x:clip
└ .shell        stretch
  └ .content    flex:1, 블록 → 100%
    └ .page     100%, 좌우 padding 없음
      └ .section width:100%          ← 여기

그리고 결정적으로, 같은 mixin 안에서 두 선언의 적용 구간이 겹치지 않습니다.

max-width: 648px → @include medium
overflow-x: clip → @include small

즉 이 clip은 "섹션이 뷰포트보다 좁을 때 자르는" 역할을 한 번도 한 적이 없고, 항상 뷰포트 가장자리에서 자르고 있었습니다.

7-3. 그 가장자리는 이미 body가 자르고 있습니다

html { overflow-x: hidden; }  // 루트의 overflow는 뷰포트로 전파
body { overflow-x: clip; }

자르는 x좌표가 .section의 것과 동일합니다. 결론적으로 중복이었습니다. 지워도 가로 스크롤은 생기지 않고, 잘리는 위치도 그대로입니다.

React 대량 데이터 편집 모달에서 입력 지연 원인 추적기

jaegwan — Fri, 20 Mar 2026 16:49:41 +0900

[React] 대규모 데이터 편집 시 발생하는 입력 지연 분석: Fiber 트리 순회와 브라우저 Reflow

React 환경에서 수천 건의 데이터를 동시에 다루는 편집 UI를 구현하다 보면, 단순한 최적화만으로는 해결되지 않는 성능 병목을 마주하곤 합니다. 최근 약 3,800건의 매출 데이터를 수정하는 모달에서 입력 시 약 5초간의 지연(Input Lag)이 발생했던 사례를 통해, React 내부 동작과 브라우저 렌더링 엔진의 관점에서 그 원인을 분석하고 해결 과정을 기록합니다.

1. 현상 및 초기 진단

규모: 약 3,822행 (행당 Input 및 SelectBox 등 10여 개의 컴포넌트 포함)
문제: 특정 입력 필드에 타이핑 시 화면이 수 초간 프리징됨.
초기 가설: 검색 필터링 로직의 부하 혹은 부모 컴포넌트의 불필요한 리렌더링을 의심함.

그러나 성능 측정 결과, 필터링 로직은 1ms 미만으로 수행되었으며, onBlur 처리를 통해 부모의 리렌더링을 억제했음에도 지연 현상은 개선되지 않았습니다.

2. React.memo와 Fiber 트리 순회 비용

Chrome DevTools의 Performance 프로파일링을 통해 확인한 결과, JavaScript 실행 시간(Yellow Block)이 병목의 큰 비중을 차지하고 있었습니다. 특히 React 내부의 recursivelyTraverseMutationEffects 함수가 수만 번 호출되는 것을 확인했습니다.

분석 결과 비교

최적화 단계	JS 실행 시간 (Performance)	특이 사항
기존 (No Memo)	4,366ms	모든 Fiber 노드를 전수 조사
React.memo 적용 후	2,983ms	변경되지 않은 서브트리 스킵

React는 상태 변경 시 Fiber 트리를 순회하며 업데이트가 필요한 노드를 탐색합니다. 행당 컴포넌트가 복잡할수록(Hook 사용량이 많을수록) Fiber 노드의 수는 기하급수적으로 증가하며, React.memo가 없을 경우 단 하나의 입력 변경에도 수만 개의 노드를 재귀적으로 방문하게 됩니다.

React.memo 적용 시, 변경되지 않은 행의 subtreeFlags를 확인하여 해당 서브트리 전체를 건너뛰기 때문에 JS 실행 비용을 유의미하게 절감할 수 있었습니다.

3. 두 번째 병목: 브라우저 렌더링 엔진의 한계 (Reflow)

JavaScript 실행 시간을 단축했음에도 불구하고, 프로파일러상에는 여전히 보라색 블록(Layout/Reflow)이 선명하게 남아 있었습니다. 이는 React의 영역을 넘어 브라우저 렌더링 엔진이 처리해야 할 물리적인 한계치에 도달했음을 의미합니다.

DOM 노드 규모: 3,822행 × 11개 셀 = 약 10만 개의 DOM 노드
원인: input의 value가 변경될 때마다 브라우저는 DOM에 존재하는 10만 개의 노드를 대상으로 레이아웃을 재계산합니다.
한계: React.memo는 JavaScript 엔진의 부하를 줄여줄 뿐, 이미 DOM에 그려진 수많은 노드로 인한 브라우저의 Reflow 비용은 해결할 수 없습니다.

4. 종합 및 최종 해결책

이번 디버깅을 통해 파악한 성능 병목의 구조는 다음과 같습니다.

병목 레이어	원인	대응 방안	비고
JavaScript (React)	Fiber 트리 재귀 순회 부하	React.memo	서브트리 스킵 가능
Browser (Rendering)	10만 개 DOM 노드의 Reflow	Virtualization	DOM 노드 수 자체를 제한

결론적으로 가상화(Virtualization)는 단순히 리렌더링 성능만을 위한 도구가 아닙니다.

Fiber 트리의 규모를 물리적으로 축소하여 React의 순회 비용을 최소화하고,
DOM 노드 수를 수백 개 수준으로 유지하여 브라우저의 레이아웃 계산 부하를 근본적으로 제거하는 가장 확실한 전략입니다.

5. 마치며

대규모 데이터를 다루는 UI에서는 "느림"의 원인이 복합적으로 작용할 때가 많습니다. 이번 사례처럼 JS 실행 비용과 브라우저 렌더링 비용이 혼재된 경우, 단계별 측정을 통해 병목의 실체를 명확히 구분하는 과정이 필수적입니다.

5,000건 대량 테이블의 '전체 선택' 지연 해결하기 (Virtualization)

jaegwan — Thu, 19 Mar 2026 10:05:48 +0900

정산 시스템의 데이터 수정 모달에서 최대 5,000건의 행을 테이블로 보여줘야 하는 기능을 구현했습니다. 개별 체크박스 토글은 문제가 없었으나, 헤더의 '전체 선택'을 클릭할 때마다 화면이 수 초간 멈추는 성능 저하가 발생했습니다.

지난 포스트에서 다룬 Set 기반 최적화와 React.memo만으로는 해결되지 않았던 이 문제를 가상화(Virtualization)를 통해 해결한 과정을 정리합니다.

1. 병목 지점 분석: React.memo가 무력화되는 순간

개별 체크박스 토글은 React.memo로 최적화가 가능합니다. 5,000개 행 중 상태가 변하는 행은 단 1개뿐이기 때문입니다. 하지만 '전체 선택'은 이야기가 다릅니다.

전체 선택 시 발생하는 일

selectedSeqs 상태가 0개에서 5,000개로 변경됩니다.
각 행의 isSelected 프로퍼티가 전부 false → true로 바뀝니다.
React.memo의 비교 함수가 작동하지만, 모든 행의 상태가 바뀌었으므로 5,000개 행 전체를 리렌더링합니다.
React는 5,000개 <tr>에 대한 Virtual DOM diff를 수행하고 실제 DOM을 업데이트합니다.

결과적으로 데이터가 수천 건이 넘어가면 Virtual DOM을 비교하고 실제 DOM에 반영하는 과정 자체가 브라우저 메인 스레드에 큰 부담을 주게 됩니다.

2. 해결책: 가상화 (Virtualization)

가상화의 핵심 아이디어는 "눈에 보이는 영역(Viewport)만 렌더링하자"는 것입니다. 5,000개의 데이터가 있더라도 사용자의 화면에 보이는 행은 고작 10~15개 내외입니다. 가상화를 적용하면 전체 선택을 눌러도 React는 현재 보이는 15개의 행만 비교하면 되므로 즉각적인 반응 속도를 얻을 수 있습니다.

구현: @tanstack/react-virtual

TanStack Table과 궁합이 좋은 @tanstack/react-virtual을 활용하여 가상 테이블을 구현했습니다.

import { useVirtualizer } from '@tanstack/react-virtual';

const VirtualSimpleTable = ({ data, columns, estimateRowHeight = 53 }) => {
  const parentRef = useRef<HTMLDivElement>(null);

  const table = useReactTable({ data, columns, getCoreRowModel: getCoreRowModel() });
  const { rows } = table.getRowModel();

  // 가상화 설정
  const virtualizer = useVirtualizer({
    count: rows.length,
    getScrollElement: () => parentRef.current,
    estimateSize: () => estimateRowHeight,
    overscan: 5,
    measureElement: el => el.getBoundingClientRect().height, // 동적 높이 대응
  });

  const gridTemplateColumns = table
    .getAllColumns()
    .map(col => `${col.getSize()}fr`)
    .join(' ');

  return (
    <div ref={parentRef} style={{ maxHeight: 400, overflowY: 'auto' }}>
      {/* 가상화 적용 시 내부 컨테이너 높이를 전체 데이터 높이만큼 확보 */}
      <div style={{ height: virtualizer.getTotalSize(), position: 'relative' }}>
        {virtualizer.getVirtualItems().map(virtualRow => {
          const row = rows[virtualRow.index];
          return (
            <div
              key={row.id}
              ref={virtualizer.measureElement}
              style={{
                position: 'absolute',
                top: 0,
                transform: `translateY(${virtualRow.start}px)`,
                display: 'grid',
                gridTemplateColumns,
              }}
            >
              {row.getVisibleCells().map(cell => (
                <div key={cell.id}>
                  {flexRender(cell.column.columnDef.cell, cell.getContext())}
                </div>
              ))}
            </div>
          );
        })}
      </div>
    </div>
  );
};

3. 주요 구현 포인트

1) Table 대신 Div + CSS Grid 사용

가상화 라이브러리는 각 행을 absolute 포지션으로 배치합니다. 하지만 표준 <table> 태그 내에서 <tr>에 absolute를 적용하면 테이블 레이아웃 구조가 깨지게 됩니다. 따라서 레이아웃 유연성이 높은 <div>와 CSS Grid 조합으로 전환하여 컬럼 정렬과 가상화 배치를 동시에 잡았습니다.

2) 동적 행 높이 대응 (measureElement)

데이터 내용에 따라 행 높이가 달라질 수 있는 경우, estimateSize만으로는 위치 계산이 부정확할 수 있습니다. measureElement를 통해 실제 렌더링된 요소의 높이를 측정함으로써 스크롤 위치를 정확하게 유지할 수 있습니다.

4. React.memo vs 가상화 비교

구분	React.memo (행 단위)	가상화 (Virtualization)
작동 원리	변경 없는 행 렌더링 스킵	보이는 행만 DOM에 렌더링
전체 선택 시	5,000개 전수 리렌더링 (느림)	약 15개만 리렌더링 (매우 빠름)
초기 렌더링	5,000개 DOM 생성	약 15개 DOM 생성
구현 난이도	낮음	중간 (CSS 레이아웃 수정 필요)

결론

React.memo는 '변경된 행만 다시 그리는' 훌륭한 전략이지만, 전체 선택처럼 모든 행의 상태가 동시에 변하는 케이스에서는 힘을 쓰지 못합니다.

데이터가 수천 건 이상이고 사용자와의 인터랙션이 잦은 테이블이라면, 처음부터 가상화를 고려하는 것이 성능과 사용자 경험(UX) 측면에서 훨씬 유리합니다. 특히 @tanstack/react-virtual을 활용하면 기존 TanStack Table의 로직을 그대로 유지하면서 성능만 끌어올릴 수 있습니다.

체크박스 아이템 최적화

jaegwan — Fri, 13 Mar 2026 12:17:44 +0900

[react] 대량의 체크박스(5,000건) 렌더링 최적화하기

프로젝트를 진행하다 보면 대량의 데이터를 다뤄야 하는 상황을 마주하곤 합니다. 최근 정산 데이터 수정 모달에서 약 5,000건의 데이터를 테이블로 렌더링하고, 각 행을 체크박스로 선택하는 기능을 구현했습니다.

하지만 구현 후 테스트 과정에서 체크박스를 클릭할 때마다 1~2초 수준의 심각한 지연이 발생했습니다. 이번 포스트에서는 배열 기반 상태 관리의 함정과 이를 Set 및 React.memo로 해결한 과정을 정리합니다.

1. 문제 상황과 원인 분석

처음에는 일반적인 방식인 배열(Array)을 사용하여 선택된 아이템의 상태를 관리했습니다.

const [selectedItems, setSelectedItems] = useState<DataListEditItem[]>([]);

// 개별 선택 핸들러
const handleSelectRow = (item: DataListEditItem) => {
  setSelectedItems(prev =>
    prev.some(selected => selected.seq === item.seq)
      ? prev.filter(selected => selected.seq !== item.seq)
      : [...prev, item],
  );
};

// 컬럼 정의 내 체크 여부 판단
cell: ({ row }) => (
  <input
    type="checkbox"
    checked={selectedItems.some(item => item.seq === row.original.seq)}
  />
),

언뜻 보면 큰 문제가 없어 보이지만, 데이터가 5,000건 이상으로 늘어나면 시간 복잡도 측면에서 병목이 발생합니다.

시간복잡도로 보는 병목

체크박스 하나를 클릭할 때마다 다음과 같은 연산이 일어납니다.

selectedItems 상태가 변경되어 전체 컴포넌트가 리렌더링됩니다.
5,000개 행이 모두 다시 그려집니다.
각 행은 selectedItems.some()을 실행하여 체크 여부를 판단합니다.

Array.some()은 최악의 경우 배열 전체를 순회하는 O(s) 연산입니다(s = 선택된 아이템 수). 이를 5,000개 행마다 반복하므로 전체 비용은 O(n × s)가 됩니다. 만약 전체 선택 후 1개를 해제한다면 약 2,500만 번(5,000 × 5,000)의 비교 연산이 수행되는 셈입니다.

2. 해결 단계 1: Set 기반으로 전환

첫 번째 개선은 조회 성능이 뛰어난 Set 자료구조를 사용하는 것입니다. Set.has()는 O(1)의 시간 복잡도를 가지므로, 5,000행 전체를 확인해도 O(n)으로 연산량이 급감합니다.

const [selectedSeqs, setSelectedSeqs] = useState<Set<number>>(new Set());

const handleSelectRow = (item: DataListEditItem) => {
  setSelectedSeqs(prev => {
    const next = new Set(prev);
    if (next.has(item.seq)) next.delete(item.seq);
    else next.add(item.seq);
    return next;
  });
};

// 조회 시 O(1)
cell: ({ row }) => (
  <input
    type="checkbox"
    checked={selectedSeqs.has(row.original.seq)}
  />
),

연산	배열 (Before)	Set (After)
개별 선택/해제	O(n × s) ≈ O(n²)	O(n)
체크 여부 비교 (1행)	O(s)	O(1)

3. 해결 단계 2: 행 단위 React.memo 적용

Set을 통해 연산 비용은 줄였지만, 여전히 상태가 변경될 때마다 5,000개의 행이 모두 리렌더링되는 근본적인 문제가 남아 있습니다. 이를 해결하기 위해 각 행을 memo로 감싸고 커스텀 비교 함수를 적용했습니다.

// SimpleTable 내부 Row 컴포넌트화
const MemoizedRow = memo(
  <T,>({ row, isSelected }: MemoizedRowProps<T>) => (
    <tr>
      {row.getVisibleCells().map(cell => (
        <td key={cell.id}>
          {flexRender(cell.column.columnDef.cell, cell.getContext())}
        </td>
      ))}
    </tr>
  ),
  (prev, next) =>
    prev.row.original === next.row.original && 
    prev.isSelected === next.isSelected // 데이터와 선택 상태가 같으면 리렌더링 방지
);

이 방식을 통해 체크박스 하나를 클릭했을 때, 실제 변경이 일어난 단 1개의 행만 다시 그려지도록 최적화했습니다.

4. 최종 비교 및 정리

각 단계별 최적화 결과는 다음과 같습니다.

구분	배열 기반	Set 전환	Set + Memo
checked 비교	O(s)	O(1)	O(1)
개별 클릭 시 리렌더링	5,000개 행	5,000개 행	1개 행
5,000건 체감 속도	1~2초 지연	다소 개선	즉시 반응

데이터셋이 작을 때는 배열 기반으로도 충분하지만, 수천 건 이상의 인터랙티브한 테이블을 구현해야 한다면 Set을 통한 조회 최적화와 memo를 통한 렌더링 최적화 조합을 필수적으로 고려해야 합니다.

특히 Set으로의 전환은 코드 수정량이 적으면서도 O(n²)에서 O(n)으로 성능을 끌어올릴 수 있는 가장 효율적인 방법입니다.

초성 검색을 지원하는 Local Async SelectBox 구현하기

jaegwan — Mon, 9 Feb 2026 10:33:57 +0900

프로젝트 규모가 커짐에 따라 서버 부하를 줄이기 위해 전체 데이터를 클라이언트에서 관리하며 필터링해야 하는 경우가 많아집니다. 특히 한국어 서비스에서는 사용자의 검색 경험을 결정짓는 '초성 검색'과 UI의 안정성을 보장하는 '포탈(Portal) 렌더링'이 필수적입니다.

이번 포스트에서는 hangul-js를 활용하여 검색 효율을 높이고, 외부 환경에 영향을 받지 않는 독립적인 LocalAsyncSelectBox를 구축한 과정을 정리합니다.

1. 커스텀 컴포넌트 구현의 필요성

기존 오픈소스 라이브러리들은 범용성을 위해 설계되었으나, 다음과 같은 기술적 제약이 있었습니다.

한글 검색 최적화 미흡: 단순 텍스트 매칭만 지원하여 초성 검색 등 한국어 특화 기능을 별도로 구현해야 함.
레이아웃 간섭: 드롭다운 UI가 부모 컨테이너의 overflow: hidden이나 z-index 설정에 영향을 받아 가려지는 현상 발생.
낮은 예측 가능성: 라이브러리 내부 로직에 의존할 경우 특이 케이스(Edge Case) 대응 시 디버깅 리소스가 증가함.

이러한 문제를 해결하기 위해 제어권을 완전히 확보한 커스텀 컴포넌트를 제작하여 장기적인 유지보수 효율을 높이고자 했습니다.

2. 핵심 구현 사항

한글 초성 검색 로직 (`hangul-js`)

사용자가 'ㅅㄱ'만 입력해도 '사과'를 찾을 수 있도록 정규표현식과 hangul-js를 조합했습니다. 입력값이 초성인지 여부를 판단하여 필터링 로직을 분기 처리했습니다.

const filterData = useCallback((keyword: string) => {
  if (!keyword.trim() || keyword.length < minLength) {
    setOptions([]);
    setIsOpen(false);
    return;
  }

  const searchKeyword = keyword.toLowerCase();
  const isChosung = /^[ㄱ-ㅎ]+$/.test(searchKeyword); // 초성 여부 검사

  const filtered = data
    .filter(item => {
      if (!item?.label) return false;
      const searchTarget = item.label.toLowerCase();

      if (isChosung) {
        // 초성 검색: 각 글자의 첫 자음을 분해하여 비교
        const targetChosung = Hangul.disassemble(searchTarget, true)
          .map(char => char[0])
          .join('');
        return targetChosung.includes(searchKeyword);
      }

      // 일반 검색 및 한글 형태소 검색 지원
      return searchTarget.includes(searchKeyword) || Hangul.search(searchTarget, searchKeyword) !== -1;
    })
    .slice(0, 5); // 성능 최적화를 위한 노출 개수 제한

  setOptions(filtered);
  // ...이후 렌더링 제어
}, [data, minLength]);

ModalPortal과 뷰포트 좌표 계산

드롭다운이 레이아웃 구조에 구애받지 않도록 ModalPortal을 통해 DOM 계층의 최상단에서 렌더링되도록 했습니다. 이때 부모 요소와의 정렬을 위해 getBoundingClientRect()를 활용해 동적으로 좌표를 계산합니다.

const updateDropdownPosition = useCallback(() => {
  if (containerRef.current) {
    const rect = containerRef.current.getBoundingClientRect();
    setDropdownRect({
      top: rect.bottom + window.scrollY,
      left: rect.left + window.scrollX,
      width: rect.width,
    });
  }
}, []);

3. 실무 적용 예시: 정산 파일 업로드 폼

구현된 컴포넌트는 CalculateFileUploadForm 내에서 매체 및 상품 선택 섹션에 적용되었습니다.

Debounce 처리: 300ms의 타이머를 설정해 연속적인 입력 시 불필요한 연산을 방지했습니다.
데이터 무결성: 입력 중에는 onChange(null)를 호출하여 선택되지 않은 상태를 명확히 전달함으로써 잘못된 데이터가 제출되는 것을 방지했습니다.

4. 마치며

컴포넌트 설계 시 가장 중점을 둔 것은 "확장성과 안정성"입니다. 라이브러리의 불투명한 내부 로직에 의존하기보다 직접 제어 가능한 구조를 구축함으로써, 예기치 못한 UI 버그를 사전에 차단하고 일관된 사용자 경험을 제공할 수 있게 되었습니다.

react의 실수하기 쉬운 안티패턴과 파훼법

jaegwan — Mon, 25 Aug 2025 14:34:18 +0900

1. 상태가 다른 상태를 바꾸는 패턴 (useEffect 안에서 setState)

const [a, setA] = useState(0);
const [b, setB] = useState(0);

useEffect(() => {
  setB(a * 2);
}, [a]);

문제: 다른 값으로부터 계산 가능한 값을 굳이 상태로 두면 무한 루프 위험 + 중복 관리 필요
해결: 계산은 상태로 두지 않고 직접 계산

const [a, setA] = useState(0);
const b = a * 2; // 혹은 useMemo

2. 상태를 지나치게 잘게 나눈 경우

const [email, setEmail] = useState('');
const [isValid, setIsValid] = useState(false);

문제: 서로 연결된 값이 따로 관리되면 동기화 문제 발생
해결: 하나의 객체로 묶어서 관리

const [form, setForm] = useState({ email: '', isValid: false });

const handleChange = (email: string) => {
  setForm({ email, isValid: validateEmail(email) });
};

3. useEffect로 데이터 가공하기

useEffect(() => {
  const filtered = list.filter(item => item.active);
  setFilteredList(filtered);
}, [list]);

문제: 단순히 계산 가능한 값을 effect와 state로 억지로 분리
해결: 렌더링 과정에서 계산

const filteredList = useMemo(
  () => list.filter(item => item.active),
  [list]
);

4. 렌더링 중에 비동기 호출

const data = fetch('/api/data'); // ❌ 렌더마다 실행

문제: 무한 호출 발생
해결: useEffect 안에서 처리

useEffect(() => {
  fetch('/api/data').then(res => setData(res));
}, []);

5. 조건부로 훅 호출

if (isOpen) {
  const [value, setValue] = useState(0); // ❌
}

문제: 훅은 항상 같은 순서로 실행돼야 함
해결: 훅은 최상단에 두고 조건은 렌더링 단계에서 처리

const [value, setValue] = useState(0);
if (!isOpen) return null;

6. props를 그대로 상태로 복사

function Child({ initialValue }) {
  const [value, setValue] = useState(initialValue); // ❌ 부모 값 변경시 동기화 안 됨
}

문제: 부모 값이 바뀌어도 동기화 안 됨
해결:
- props를 직접 사용
- 정말 독립적인 값이어야 한다면 이름을 defaultValue처럼 명확히
- 필요하다면 의도적으로 useEffect로 갱신

7. 불필요한 리렌더

원인:
- Context에 큰 객체를 넣어서 전달
- 매번 새로운 함수나 객체를 만들어서 props로 전달
해결:
- React.memo, useCallback, useMemo로 최적화
- Context는 작은 단위로 쪼개서 관리

[rn] prebuild + fastlane 같이 사용하기

jaegwan — Tue, 5 Aug 2025 20:17:06 +0900

expo의 장점과 eas 지출회피를 같이하기 위해 prebuild를 사용하고 있었으나

prebuild 시 ios 폴더가 초기화되는 현상 떄문에 fastlane을 적용하기 어려웠다.

방법 1. expo config plugin
방법 2. app.json 설정

위 방법들은 prebuild시 유지해야할 항목을 보존하는데 도움을 줄 순 있으나 fastlane 관련 파일을 보존하긴 어려워

prebuild와 복구 명령어를 통합하기로 했다.

fastlane 폴더를 루트에서 백업
bash

/project-root
┣ /fastlane-template/
┃ ┣ Appfile
┃ ┗ Fastfile
2. expo prebuild 이후에 복사
bash

npx expo prebuild --clean
cp -R ../fastlane-template ios/fastlane
prebuild 후 스크립트로 자동 복구 가능

//prebuild.sh

npx expo prebuild --clean
echo "  Before fastlane copy: $(pwd)"
cp -R ./fastlane-template/fastlane ./ios/fastlane
echo "✅ fastlane 디렉토리 복원 완료"
cd ios
fastlane beta
echo "✅ iOS 빌드 완료"

default_platform(:ios)

platform :ios do
  desc "TestFlight 업로드"
  lane :beta do
    # 코드사이닝 설정
    automatic_code_signing(
      use_automatic_signing: true,
      team_id: "H4DJJ5V239",
      path: "nocotine.xcodeproj"
    )
    
    increment_build_number(
      # xcodeproj: "nocotine.xcodeproj"
      build_number: "6"  # 원하는 번호로 설정
    )

    build_app(
      workspace: "nocotine.xcworkspace",  # workspace 다시 사용
      scheme: "nocotine",
      export_method: "app-store",
      configuration: "Release",
      clean: true,
      include_bitcode: false
    )

   upload_to_testflight(
      api_key_path: "./fastlane/keyCode.json", // 본인 키 Json
      skip_waiting_for_build_processing: true
    )3
  end
  
  desc "수동 Archive 테스트"
  lane :archive_only do
    # 코드사이닝 설정
    automatic_code_signing(
      use_automatic_signing: true,
      team_id: "team id ",// 본인 팀아이디
      path: "nocotine.xcodeproj"
    )
    
    increment_build_number(
      xcodeproj: "nocotine.xcodeproj"
    )
    
    gym(
      workspace: "nocotine.xcworkspace",  # workspace 다시 사용
      scheme: "nocotine",
      configuration: "Release",
      clean: true,
      skip_archive: false,
      skip_package_ipa: true,  # IPA 생성 안 함, Archive만
      include_bitcode: false
    )
  end
end

//key.json

{
    "key_id": "",
    "issuer_id": "~~",// apple connect - 보안 - 통합에서 이슈어id 확인
    "key": "-----BEGIN PRIVATE KEY-----\n~~~~\n-----END PRIVATE KEY-----", //각 줄바꿈에 \n 삽입 // 관리자로 키 생성해야함
    "duration": 1200,
    "in_house": false
}

expo prebuild로 프로덕션 빌드하기

jaegwan — Fri, 25 Jul 2025 12:25:36 +0900

npx expo prebuild --clean
cd ios
pod install
open ios/nocotine.xcworkspace

왼쪽 상단에서 "nocotine" → "nocotine" (프로젝트, 파란색 아이콘) 클릭

TARGETS > nocotine 선택
Signing & Capabilities 탭에서
- Team: Apple Developer 계정 선택
- Bundle Identifier: com.jaegwan.nocotine 맞는지 확인
- Provisioning Profile: 자동으로 맞춰주거나, 직접 선택(Ad Hoc 등)
Build Settings > Versioning에서
- Current Project Version: 빌드 넘버(예: 3)
- Version: 마케팅 버전(예: 1.0.2)

상단 Scheme에서 "Any iOS Device (arm64)" 선택
(시뮬레이터 아님! "Generic iOS Device" 또는 실제 기기)
상단 메뉴에서
- Product > Archive 선택

빌드가 끝나면 Organizer 창이 자동으로 뜸

Organizer 창에서 방금 빌드한 아카이브 선택
Distribute App 버튼 클릭
배포 방식 선택:
- App Store Connect: 앱스토어 업로드(Transporter 없이 직접 가능)
- Ad Hoc: 테스트 기기에 직접 설치용 ipa 생성
- Development: 개발자 디바이스용
- Enterprise: 기업 배포용
배포 타입 선택 후, Xcode 안내에 따라 진행
마지막 단계에서 Export하면
→ .ipa 파일이 원하는 경로에 생성됨

expo - ios 빌드 및 출시

jaegwan — Fri, 25 Jul 2025 00:09:28 +0900

0. eas build는 github repo를 기반으로 빌드

app.json 파일 점검하여

ios:{buildNumber} 등 체크
1. ipa 생성

npm install -g eas-cli

eas login

eas build:configure # (최초 1회)

eas build -p ios --profile production # 필요시 --clear-cache

위 과정을 따른 후

빌드가 완료되면 EAS 에 접속 해 ipa 를 내려받는다.

2. apple connect에 전송

3. 심사 제출

Type Guard와 every 메서드의 한계

jaegwan — Mon, 14 Oct 2024 11:45:18 +0900

문제 상황: Type Guard와 `every` 메서드의 한계

TypeScript는 코드의 타입 안전성을 보장하기 위해 컴파일 시점에 타입을 검사한다. 이 과정에서 타입 가드와 타입 단언을 활용해 컴파일러가 타입을 정확하게 추론하도록 돕는다. 하지만 때로는 타입 가드를 사용했음에도 TypeScript가 배열의 타입을 확신하지 못하는 경우가 생긴다.

예시 코드

다음 예제에서 result 배열이 FileSystemFileEntry 또는 FileSystemDirectoryEntry로만 구성되어 있는지를 every 메서드를 통해 확인하고자 한다.

if (
    result.length > 0 &&
    result.every(entry => isFileSystemFileEntry(entry) || isFileSystemDirectoryEntry(entry))
) {
    resolve(result); // 오류 발생: TypeScript는 여전히 result의 타입을 알 수 없음
}

여기서 TypeScript는 result가 (FileSystemFileEntry | FileSystemDirectoryEntry)[] 타입임을 보장하지 않는다. 비록 every로 각 요소의 타입을 확인했지만, 컴파일러는 여전히 result 배열 전체가 안전한 타입인지 확신하지 못한다.

왜 발생하는가?

every 메서드는 배열의 모든 요소가 조건을 만족하는지 여부만을 반환한다. 즉, true 또는 false 값을 반환할 뿐이며, 이 정보만으로는 컴파일러가 result 전체 배열의 타입을 자동으로 강제할 수 없다.

타입 추론의 한계

타입 가드가 특정 요소의 타입을 좁히는 데는 효과적이지만, every와 같은 메서드는 배열 자체의 타입을 좁히지 않는다. TypeScript는 every의 결과가 true일 때, 개별 요소들이 특정 타입임을 알 수 있을지라도 배열 전체의 타입은 추론하지 않는다. 예를 들어, result가 FileSystemEntry[] 타입으로 선언되어 있다면 every 이후에도 여전히 FileSystemEntry[] 타입으로 인식하게 된다.

TypeScript 컴파일러가 불완전하다고 느낄 수도 있지만, 사실 TypeScript는 의도적으로 배열의 전체 타입을 자동으로 추론하지 않도록 설계된 것이다. 그 이유는 TypeScript의 타입 시스템이 정적 타입 검사를 수행하기 때문이다. 즉, 컴파일 시점에만 타입을 검사하며, 런타임에서의 변화는 감지하지 않는다.

왜 TypeScript는 every의 결과로 타입을 강제하지 않는가?
every 메서드는 배열의 모든 요소가 특정 조건을 만족하는지를 검사하지만, 이때 반환되는 값은 오직 true나 false이다. 이렇듯 every는 단순히 배열이 조건을 만족하는지 아닌지를 알려주는 용도로 사용된다. TypeScript는 런타임에서의 조건을 기반으로 배열의 전체 타입을 좁히는 작업을 하지 않는다.

예를 들어, TypeScript가 result.every(...)의 결과가 true라고 해서, result의 타입을 자동으로 (FileSystemFileEntry | FileSystemDirectoryEntry)[]로 확신한다고 가정해보자. 만약 배열이 변경되거나, 이후 코드에서 다른 타입의 요소가 추가된다면, TypeScript는 컴파일 시점에서 이 변경을 미리 감지할 수 없게 된다. 따라서 컴파일 시점의 타입 검사에서는 every의 검사 결과로 배열 전체 타입을 확신하지 않도록 하고, 대신 개발자가 타입을 직접 좁히거나 명시적으로 지정하도록 하는 것이다.

해결 방법

every를 사용할 때 TypeScript가 배열의 타입을 확신하게 하려면, 타입 가드를 통해 배열을 다시 선언해줄 필요가 있다. 이를 해결하는 방법은 크게 두 가지로 나뉜다.

1. 타입 단언 사용

타입 단언을 사용하여 TypeScript에게 result가 안전한 타입임을 명시할 수 있다:

resolve(result as (FileSystemFileEntry | FileSystemDirectoryEntry)[]);

2. `filter`와 타입 가드 조합 사용

filter와 타입 가드를 조합하여 컴파일러가 배열의 타입을 안전하게 추론하도록 만들 수 있다. 이를 통해 타입 단언을 피하면서도 원하는 타입으로 제한할 수 있다.

const validEntries = result.filter(
    (entry): entry is FileSystemFileEntry | FileSystemDirectoryEntry =>
        isFileSystemFileEntry(entry) || isFileSystemDirectoryEntry(entry)
);

resolve(validEntries); // TypeScript는 validEntries가 (FileSystemFileEntry | FileSystemDirectoryEntry)[] 타입임을 확신한다.

여기서 filter 메서드는 새로운 배열을 반환하며, 이 배열이 FileSystemFileEntry와 FileSystemDirectoryEntry만 포함하고 있다고 TypeScript가 확신할 수 있도록 돕는다. 따라서 타입 단언 없이도 배열의 타입을 안전하게 추론할 수 있다.

결론

TypeScript는 개별 요소에 대한 타입 가드가 사용되더라도 배열 전체 타입을 자동으로 강제하지는 않는다. 이런 경우 filter와 타입 가드를 조합하여 컴파일러가 타입을 추론하도록 돕거나, 타입 단언을 통해 안전성을 명시해줄 수 있다. 이러한 이해를 통해 TypeScript의 타입 시스템을 더욱 효과적으로 활용할 수 있을 것이다.