기술 블로그

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의 타입 시스템을 더욱 효과적으로 활용할 수 있을 것이다.

타입스크립트에서 배열 요소 타입 가드: 왜 작동하지 않는가?

jaegwan — Mon, 30 Sep 2024 19:33:55 +0900

타입스크립트에서 배열 요소 타입 가드: 왜 작동하지 않는가?

타입스크립트는 정적 타입 기반의 언어로, 타입을 명확히 정의하고 코드의 안정성을 높이는 데 중요한 역할을 한다. 그중에서도 타입 가드(Type Guard)는 변수가 특정 조건을 만족할 때 해당 변수의 타입을 좁히는 기능을 담당한다. 하지만 배열 요소에 타입 가드를 적용할 때는 예상치 못한 오류가 발생할 수 있다. 이번 글에서는 배열 요소에 타입 가드가 제대로 작동하지 않는 이유와 이를 해결하는 방법을 살펴보겠다.

타입 가드란?

타입 가드는 변수의 타입을 안전하게 좁히기 위해 사용하는 조건문이다. 대표적인 예로 typeof, instanceof, in 연산자가 있다. 이들은 특정 조건을 만족할 때 타입스크립트가 변수를 더욱 구체적인 타입으로 추론하도록 돕는다.

타입 가드 예시

function isString(value: any): value is string {
    return typeof value === "string";
}

function printLength(value: any) {
    if (isString(value)) {
        // 타입스크립트는 여기서 value가 string임을 알 수 있다.
        console.log(value.length);
    }
}

위 예시에서 isString 함수는 value가 문자열(string)인지 확인하는 타입 가드다. 이 타입 가드를 통해 조건문 안에서는 value가 string 타입으로 안전하게 좁혀져 사용될 수 있다.

배열 요소에 타입 가드를 적용할 때의 문제

배열 요소를 다룰 때는 배열의 동적 특성 때문에 타입 가드가 예상대로 작동하지 않는 경우가 발생한다. 예를 들어 배열에서 특정 요소를 인덱스로 접근할 때 타입스크립트는 해당 요소의 타입을 완전히 좁히지 못하는 경우가 있다.

문제 상황 예시

const fileEntries: FileSystemEntry[] = getFileEntries(); // 여러 FileSystemEntry 객체가 들어있는 배열
if (isFileSystemFileEntry(fileEntries[i])) {
    fileList.dcmFiles.push(fileEntries[i]);  // 오류 발생
}

여기서 isFileSystemFileEntry 타입 가드는 배열 요소가 FileSystemFileEntry인지 확인해준다. 그러나 타입스크립트는 fileEntries[i]의 타입을 FileSystemFileEntry로 확실하게 좁히지 못하고, 여전히 FileSystemEntry 타입으로 취급할 수 있다. 이로 인해 "fileEntries[i]"를 FileSystemFileEntry에 할당할 수 없다는 오류가 발생하게 된다.

타입스크립트가 배열 요소를 좁히지 못하는 이유

이 문제가 발생하는 주된 이유는 배열이 동적 데이터 구조이기 때문이다. 배열 요소는 인덱스로 접근할 수 있으며, 이때 배열의 길이가 동적으로 변할 수 있다고 타입스크립트는 가정한다. 즉, 배열에서 특정 인덱스를 통해 접근하는 요소가 언제든 바뀔 수 있기 때문에, 타입스크립트는 타입을 안전하게 좁히는 데 주저하게 된다.

해결 방법: 배열 요소를 변수에 할당하기

이 문제를 해결하기 위한 가장 간단한 방법은 배열 요소를 변수에 할당한 후 타입 가드를 적용하는 것이다. 이를 통해 타입스크립트는 해당 변수를 정적으로 처리할 수 있게 되며, 타입을 안전하게 좁히게 된다.

해결된 코드 예시

const fileEntry = fileEntries[i]; // 배열 요소를 먼저 변수에 할당
if (isFileSystemFileEntry(fileEntry)) {
    fileList.dcmFiles.push(fileEntry);  // 문제 해결
}

이렇게 배열 요소를 변수에 할당하면, 타입스크립트는 fileEntry를 FileSystemFileEntry로 좁히는 것을 확실하게 할 수 있다. 이로 인해 더 이상 타입 관련 오류가 발생하지 않으며, 타입스크립트는 안전하게 해당 요소를 fileList.dcmFiles에 추가할 수 있다.

결론

타입스크립트에서 배열 요소를 다룰 때 타입 가드가 예상대로 작동하지 않는 이유는 배열의 동적 특성 때문이다. 배열의 요소는 언제든 바뀔 수 있는 가능성이 있기 때문에, 타입스크립트는 타입을 안전하게 좁히는 것을 주저할 수 있다. 이러한 문제를 해결하려면 배열 요소를 변수에 먼저 할당한 후 타입 가드를 적용하는 방법이 효과적이다.

이 방식을 적용하면 배열 요소에 타입 가드를 성공적으로 사용할 수 있으며, 코드의 안정성과 가독성을 동시에 높일 수 있다.

기술 블로그

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

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

1. 현상 및 초기 진단

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

분석 결과 비교

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

4. 종합 및 최종 해결책

5. 마치며

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

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

전체 선택 시 발생하는 일

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

구현: @tanstack/react-virtual

3. 주요 구현 포인트

1) Table 대신 Div + CSS Grid 사용

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

4. React.memo vs 가상화 비교

결론

체크박스 아이템 최적화

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

1. 문제 상황과 원인 분석

시간복잡도로 보는 병목

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

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

4. 최종 비교 및 정리

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

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

2. 핵심 구현 사항

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

ModalPortal과 뷰포트 좌표 계산

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

4. 마치며

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

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

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

3. useEffect로 데이터 가공하기

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

5. 조건부로 훅 호출

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

7. 불필요한 리렌더

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

expo prebuild로 프로덕션 빌드하기

expo - ios 빌드 및 출시

Type Guard와 every 메서드의 한계

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

예시 코드

왜 발생하는가?

타입 추론의 한계

해결 방법

1. 타입 단언 사용

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

결론

타입스크립트에서 배열 요소 타입 가드: 왜 작동하지 않는가?

타입스크립트에서 배열 요소 타입 가드: 왜 작동하지 않는가?

타입 가드란?

타입 가드 예시

배열 요소에 타입 가드를 적용할 때의 문제

문제 상황 예시

타입스크립트가 배열 요소를 좁히지 못하는 이유

해결 방법: 배열 요소를 변수에 할당하기

해결된 코드 예시

결론

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

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

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