괴발개발

React 콜백 Props 패턴이해하기

Definitely Not Dj — Mon, 23 Mar 2026 01:00:50 +0900

React에서 부모-자식 컴포넌트 간 통신의 핵심은 콜백 props 패턴입니다. 이 글에서는 전체 동작 원리를 단계별로 살펴보고, JavaScript의 "함수는 값이다"라는 핵심 개념부터 TypeScript 타입 시스템, 성능 최적화까지 깊이 있게 다룹니다.

전체 흐름 한눈에 보기

이 흐름을 이해한 다음, JavaScript의 "함수는 값이다"라는 핵심 개념을 봐야 합니다.

1. 출발점: "함수는 값이다"

이 패턴을 이해하려면 JavaScript의 핵심 성질 하나를 먼저 받아들여야 합니다. JavaScript에서 함수는 숫자나 문자열처럼 값(value) 으로 취급됩니다. 변수에 담을 수 있고, 다른 변수에 대입할 수 있고, 함수의 인자로 넘길 수 있습니다.

// 함수를 변수에 담는다
const greet = () => console.log("안녕!");

// 다른 변수에 대입 — "복사"가 아니라 "같은 함수를 가리키는 참조"를 복사
const alsoGreet = greet;

alsoGreet(); // "안녕!" 출력 — 완전히 동일한 함수가 실행됨

React의 콜백 props는 이 성질을 그대로 이용합니다. 부모가 함수를 만들고, 그 함수를 가리키는 참조값을 props라는 이름의 객체에 실어서 자식에게 전달합니다.

2. 렌더링 시점: 함수 참조가 아래로 흐른다

컴포넌트가 렌더링될 때 React는 두 단계를 거칩니다.

첫 번째로, 부모 컴포넌트 함수가 실행됩니다. 이 시점에 handleClick이라는 이름의 함수가 생성되어 메모리 어딘가에 저장됩니다.

const Parent = () => {
  // 렌더 실행 시 이 함수가 메모리에 생성됨
  const handleClick = () => {
    console.log("부모가 실행됨!");
  };

  // JSX를 반환할 때, props 객체 안에 함수 참조를 담음
  return <Child onClick={handleClick} />;
};

두 번째로, React가 <Child onClick={handleClick} />를 처리할 때 { onClick: handleClick }이라는 props 객체를 만들어 Child 함수에 넘깁니다. 이 onClick의 값은 새로 만든 함수가 아니라, 방금 생성된 handleClick과 동일한 메모리 주소를 가리키는 참조입니다. 함수 본체가 복제되지 않습니다.

3. 자식 컴포넌트: 받은 참조를 버튼에 연결한다

자식 컴포넌트 입장에서는 누가 이 함수를 만들었는지 전혀 모릅니다. 그냥 props.onClick이라는 이름으로 "호출 가능한 무언가"가 왔을 뿐입니다.

interface ChildProps {
  label: string;
  onClick: () => void; // 호출 가능한 함수라는 계약
}

const Child = ({ label, onClick }: ChildProps) => {
  // 받은 함수 참조를 그대로 버튼의 onClick 이벤트 핸들러로 등록
  return <button onClick={onClick}>{label}</button>;
};
```

여기서 `onClick={onClick}`은 "버튼이 클릭되면 이 함수를 호출하라"고 브라우저에 등록하는 것입니다. 아직 함수가 실행된 게 아닙니다.

---

### 4. 클릭 이벤트: 역방향으로 실행이 올라간다

사용자가 버튼을 클릭하는 순간, 실행 흐름이 역전됩니다.
```
사용자 클릭
  → 브라우저가 SyntheticEvent 생성
    → 등록된 onClick 핸들러(= props.onClick) 호출
      → props.onClick은 사실 부모의 handleClick을 가리킴
        → 부모의 handleClick 실행

자식은 단지 "전달받은 함수를 실행"했을 뿐인데, 그 함수가 사실 부모 스코프에 있는 함수라서 부모의 상태나 로직에 접근할 수 있습니다. 이것이 콜백 패턴의 핵심입니다.

4. 클릭 이벤트: 역방향으로 실행이 올라간다

사용자가 버튼을 클릭하는 순간, 실행 흐름이 역전됩니다.

사용자 클릭
  → 브라우저가 SyntheticEvent 생성
    → 등록된 onClick 핸들러(= props.onClick) 호출
      → props.onClick은 사실 부모의 handleClick을 가리킴
        → 부모의 handleClick 실행

자식은 단지 "전달받은 함수를 실행"했을 뿐인데, 그 함수가 사실 부모 스코프에 있는 함수라서 부모의 상태나 로직에 접근할 수 있습니다. 이것이 콜백 패턴의 핵심입니다.

5. 왜 부모 스코프에 접근되는가 — 클로저

handleClick은 Parent 함수 안에서 정의된 함수입니다. JavaScript의 클로저(closure) 규칙에 의해, handleClick은 자신이 생성된 스코프의 변수들을 기억합니다. 따라서 자식에서 handleClick이 호출되더라도, 그 함수는 여전히 부모의 state나 다른 변수들을 참조할 수 있습니다.

const Parent = () => {
  const [count, setCount] = useState(0);

  const handleClick = () => {
    // 클로저: setCount와 count를 기억하고 있음
    // 자식에서 이 함수가 호출돼도 부모의 상태에 접근 가능
    setCount(count + 1);
  };

  return <Child onClick={handleClick} />;
};

handleClick이 자식에게 넘어가도 setCount에 대한 참조를 잃지 않습니다. 이 덕분에 자식이 버튼을 클릭했을 때 부모의 상태가 업데이트될 수 있습니다.

6. TypeScript와의 시너지 — 인터페이스로 계약을 명시한다

TypeScript를 사용할 때 이 패턴은 더욱 강력해집니다. props 인터페이스에 onClick의 타입을 선언하면, 잘못된 함수를 전달했을 때 컴파일 단계에서 오류를 잡을 수 있습니다.

// 매개변수나 반환값이 있는 경우도 타입으로 명시
interface ButtonProps {
  label: string;
  onClick: () => void;                    // 인자 없음, 반환값 없음
  onSelect?: (id: number) => void;        // 선택적, id를 받음
  onConfirm?: (value: string) => boolean; // boolean 반환
}

const Child = ({ label, onClick, onSelect }: ButtonProps) => {
  // TypeScript가 onClick을 함수로 보장해 주므로 안전하게 호출
  return <button onClick={onClick}>{label}</button>;
};

// 부모에서 타입이 맞지 않으면 컴파일 에러
const Parent = () => {
  const handleClick = () => {}; // () => void ✓
  return <Child label="클릭" onClick={handleClick} />;
};

7. useCallback — 함수 참조 안정화

부모가 리렌더링될 때마다 handleClick은 새로운 함수 객체로 재생성됩니다. 이는 자식 컴포넌트가 React.memo로 감싸져 있어도 props가 바뀐 것으로 인식되어 불필요한 리렌더링을 유발할 수 있습니다.

const Parent = () => {
  const [count, setCount] = useState(0);
  const [other, setOther] = useState("");

  // useCallback 없이: other가 바뀌어도 handleClick이 새로 생성됨
  // → Child가 불필요하게 리렌더링
  const handleClick = () => {
    setCount(c => c + 1);
  };

  // useCallback 사용: 의존성 배열이 바뀌지 않으면 같은 참조 유지
  const stableHandleClick = useCallback(() => {
    setCount(c => c + 1);
  }, []); // count를 직접 읽지 않고 함수형 업데이트를 써서 의존성 없음

  return <MemoizedChild onClick={stableHandleClick} />;
};

const MemoizedChild = React.memo(({ onClick }: { onClick: () => void }) => {
  return <button onClick={onClick}>클릭</button>;
});

useCallback을 무조건 붙이는 건 오히려 코드 복잡도만 높입니다. React.memo와 함께 사용하거나, 해당 함수가 useEffect의 의존성 배열에 들어가야 하는 경우에만 선택적으로 쓰는 것이 좋습니다.

8. 이벤트 객체 전달 — SyntheticEvent

자식이 이벤트 관련 정보(클릭 위치, 키 입력 등)를 부모에 함께 넘겨야 한다면, 함수 시그니처에 이벤트 객체를 포함시킵니다.

interface InputProps {
  onChange: (e: React.ChangeEvent<HTMLInputElement>) => void;
}

const SearchInput = ({ onChange }: InputProps) => (
  <input type="text" onChange={onChange} />
);

const Parent = () => {
  const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => {
    console.log("입력값:", e.target.value); // 자식의 input 값을 부모가 읽음
  };

  return <SearchInput onChange={handleChange} />;
};

또는 이벤트 객체 대신 가공된 값만 부모에게 전달하도록 자식에서 래핑하는 게 더 깔끔할 때도 있습니다.

interface SearchInputProps {
  onSearch: (value: string) => void; // 이벤트 객체 대신 순수한 string
}

const SearchInput = ({ onSearch }: SearchInputProps) => (
  <input
    type="text"
    onChange={(e) => onSearch(e.target.value)} // 자식이 추출해서 전달
  />
);

정리

콜백 props 패턴의 동작 원리를 한 문장으로 요약하면 이렇습니다. 부모가 자신의 스코프에서 함수를 만들고, 그 함수의 참조를 props로 내려보내면, 자식이 이벤트 발생 시 그 참조를 실행한다. 실행 시점에 클로저가 작동하므로 함수는 부모 스코프의 변수(상태, 다른 함수 등)에 자유롭게 접근할 수 있습니다. TypeScript의 타입 시스템이 이 계약을 컴파일 타임에 보장해 주고, useCallback이 성능 최적화를 지원합니다.

Vite 이해하기 — 번들링부터 ES Module, 그리고 왜 Vite가 등장했는가

Definitely Not Dj — Wed, 4 Mar 2026 19:53:55 +0900

프론트엔드 개발을 하다 보면 한 번쯤 이런 질문을 하게 됩니다.

"왜 Webpack 대신 Vite를 사용하는 걸까?"
"Vite는 왜 그렇게 빠른 걸까?"

이 질문에 제대로 답하려면 번들링(Bundling), JavaScript 모듈 시스템, 그리고 브라우저의 ES Module 지원까지 이해해야 합니다. 단순히 "Vite가 빠르다"는 사실을 넘어, 왜 빠른지 그 구조적인 이유를 이해하면 도구를 훨씬 더 잘 활용할 수 있습니다. 이 글에서는 JavaScript 모듈의 역사부터 Vite의 내부 동작 원리까지 차근차근 살펴보겠습니다.

1. JavaScript에는 원래 모듈 개념이 없었다

초기의 JavaScript는 모듈 시스템이 존재하지 않았습니다. 당시에는 HTML에 <script> 태그를 나열하는 방식으로 여러 파일을 불러왔습니다.

<script src="math.js"></script>
<script src="app.js"></script>

예를 들어 다음과 같은 코드가 있다고 가정해보겠습니다.

// math.js
function add(a, b) {
  return a + b
}

// app.js
console.log(add(1, 2))

코드만 보면 간단해 보이지만, 이 방식에는 치명적인 문제들이 숨어 있습니다.

첫째, 모든 변수가 전역(Global) 스코프에 존재합니다. 어떤 파일에서 선언한 변수든 전부 전역으로 노출되기 때문에, 다른 파일의 변수와 이름이 겹치는 순간 충돌이 발생합니다.

둘째, 파일 로딩 순서가 매우 중요합니다. 만약 아래처럼 순서가 바뀌면 바로 에러가 납니다.

<script src="app.js"></script>   <!-- add() 함수가 아직 없음 -->
<script src="math.js"></script>

셋째, 프로젝트 규모가 커질수록 관리가 사실상 불가능해집니다. 변수 충돌, 의존성 관리의 어려움, 복잡한 코드 구조가 뒤엉키면서 유지보수는 점점 악몽이 됩니다. 이런 한계 때문에 JavaScript 모듈 시스템의 필요성이 대두됩니다.

2. JavaScript 모듈 시스템의 등장

브라우저가 모듈을 공식적으로 지원하기 전, 개발자들은 스스로 라이브러리 기반 모듈 시스템을 만들어냈습니다. 대표적인 방식은 다음과 같습니다.

모듈 시스템특징

CommonJS	Node.js 환경에서 사용하는 동기 방식 모듈
AMD	브라우저를 위한 비동기 모듈 방식
UMD	CommonJS와 AMD 모두 호환하는 범용 모듈

대표적인 도구로는 RequireJS와 Browserify가 있었습니다. AMD 방식의 코드는 다음과 같이 작성했습니다.

// main.js
define(["math"], function(math) {
  console.log(math.add(1, 2))
})

// math.js
define(function() {
  function add(a, b) {
    return a + b
  }
  return { add }
})

모듈화라는 개념 자체는 진보적이었지만, 코드가 장황하고 복잡해서 유지보수가 쉽지 않았습니다. 더 근본적인 해결책이 필요했습니다.

3. 번들링(Bundling)이 등장한 이유

브라우저가 모듈 시스템을 직접 지원하지 않는 상황에서, 번들러(Bundler)라는 도구가 새로운 해법으로 등장합니다. 번들링이란 간단히 말해, 여러 개의 JavaScript 파일을 하나의 파일로 합치는 과정입니다.

예를 들어 다음과 같은 프로젝트 구조가 있다고 해봅시다.

src
├── main.js
├── math.js
├── api.js
└── util.js

번들링 없이 브라우저가 이 코드를 실행하려면, 파일 하나하나를 네트워크를 통해 모두 다운로드해야 합니다. 반면 번들링을 하면 이 모든 파일이 bundle.js 하나로 합쳐지고, 브라우저는 이것만 다운로드하면 됩니다.

<script src="bundle.js"></script>

네트워크 요청 횟수가 줄어들고, 로딩 순서 문제도 해결됩니다. 번들러가 순서를 알아서 정리해주기 때문입니다.

4. 번들러가 하는 일

번들러는 단순히 파일을 합치는 것 그 이상을 합니다. 대표적인 번들러로는 Webpack, Rollup, Parcel이 있으며, 이들이 처리하는 주요 작업은 다음과 같습니다.

Dependency Graph 생성: 어떤 파일이 어떤 파일에 의존하는지 분석합니다.
코드 변환 (Transpile): TypeScript, JSX, 최신 문법 등을 브라우저가 이해할 수 있는 코드로 변환합니다.
하나의 파일로 합치기: 분석된 의존성을 기반으로 파일들을 하나로 묶습니다.
최적화: 불필요한 코드를 제거하고, 파일 크기를 줄입니다.

예를 들어 다음 코드를 번들러가 처리하면,

// math.js
export function add(a, b) {
  return a + b
}

// main.js
import { add } from "./math"
console.log(add(1, 2))

번들러는 이를 아래와 같이 하나의 즉시실행함수(IIFE) 형태로 변환합니다. import와 export가 사라지고 모든 코드가 하나로 합쳐집니다.

(function() {
  function add(a, b) {
    return a + b
  }
  console.log(add(1, 2))
})();

5. Webpack이 해결한 문제, 그리고 그 한계

Webpack은 의존성 그래프(Dependency Graph)를 분석해 올바른 순서로 번들링해주는 강력한 도구로 자리를 잡았습니다.

main
├── math
│   └── util
└── api

하지만 Webpack 개발 서버를 실행할 때의 과정을 살펴보면 명확한 한계가 보입니다.

source code
  ↓
dependency 분석
  ↓
transpile
  ↓
bundle 생성
  ↓
dev server 실행

코드를 한 줄도 수정하기 전에 이 모든 과정을 거쳐야 합니다. 프로젝트 규모가 작을 때는 괜찮지만, 파일이 수백 개, 수천 개로 늘어난 대형 프로젝트에서는 개발 서버 시작까지 10~40초가 걸리는 경우도 생깁니다. 개발자 경험(DX) 측면에서 이는 분명한 병목입니다.

6. ES Module의 등장

JavaScript 표준 명세에 드디어 공식적인 모듈 시스템이 포함되었습니다. 바로 ES Module(ESM)입니다.

// math.js
export function add(a, b) {
  return a + b
}

// main.js
import { add } from "./math.js"

그리고 브라우저에서는 type="module" 속성만 붙이면 됩니다.

<script type="module" src="main.js"></script>

이제 브라우저가 직접 모듈을 처리할 수 있게 되었습니다. 브라우저는 main.js를 요청하고, 그 안의 import를 보고 math.js를 추가 요청하는 방식으로 의존성 그래프를 스스로 탐색하고 실행합니다. 이 변화가 Vite 탄생의 핵심 배경입니다.

7. Vite의 등장

ES Module을 브라우저가 직접 지원하게 되면서, 새로운 접근 방식이 가능해졌습니다. 바로 "개발할 때는 번들링을 하지 않는다"는 아이디어입니다. 이것이 Vite의 핵심입니다.

Webpack 방식이 "먼저 다 합쳐서 서버 올리기"라면, Vite는 "일단 서버 올리고, 브라우저가 필요한 파일을 그때그때 요청하게 두기"입니다. 이 발상의 전환 하나가 개발 경험을 완전히 바꿔놓습니다.

8. Vite의 내부 구조

Vite dev server의 동작 방식은 다음과 같습니다.

source code
  ↓
Vite dev server
  ↓
browser (ES Module로 직접 로드)

프로젝트 내에 다음과 같은 파일들이 있다고 해봅시다.

/src/main.ts
/src/App.tsx
/src/components/Button.tsx

Vite는 서버 시작 시 이 파일들을 미리 번들링하지 않습니다. 브라우저가 특정 페이지를 열어서 main.ts를 요청할 때, 그 파일만 변환해서 응답합니다. 나머지 파일은 실제로 브라우저가 요청할 때 처리됩니다. 이것이 바로 On-demand Transform 방식입니다.

9. node_modules 문제와 Dependency Pre-bundling

이 방식에는 한 가지 큰 문제가 있습니다. node_modules는 구조가 매우 복잡합니다. 예를 들어 React 하나만 해도 내부적으로 수십 개의 파일로 나뉘어 있고, 이것을 브라우저가 ES Module 방식으로 그대로 요청하면 수백 개의 HTTP 요청이 발생합니다. 네트워크 병목이 생기면서 오히려 느려집니다.

그래서 Vite는 node_modules에 한해서만 번들링을 수행합니다. 이 과정을 Dependency Pre-bundling이라고 합니다. Vite는 이 작업에 esbuild를 사용합니다. esbuild는 Go 언어로 작성된 초고속 번들러로, Webpack보다 수십 배 빠르게 동작합니다.

node_modules
  ↓
esbuild (초고속 번들링)
  ↓
node_modules/.vite/deps/react.js  (캐시)

이렇게 사전 번들링된 결과물은 캐시되기 때문에, 이후 서버를 다시 시작해도 해당 패키지들은 다시 처리하지 않습니다.

10. HMR(Hot Module Replacement)이 매우 빠른 이유

코드를 수정했을 때의 동작 방식도 Webpack과 Vite는 완전히 다릅니다.

Webpack: 변경된 파일을 감지하면 전체 번들을 다시 빌드합니다.
Vite: 변경된 파일 하나만 무효화하고, 브라우저에 해당 파일만 교체하도록 알립니다.

프로젝트 규모와 관계없이, Vite의 HMR은 항상 빠릅니다. 파일 수가 1000개든 10000개든, 수정한 파일 하나만 처리하기 때문입니다. 반면 Webpack은 프로젝트가 커질수록 HMR도 느려지는 경향이 있습니다.

11. Production Build는 Rollup을 사용한다

개발 환경에서는 번들링을 하지 않지만, 실제 배포(production) 환경에서는 여전히 번들링이 필요합니다. 최적화되지 않은 수백 개의 파일 요청은 실제 사용자 환경에서 성능 문제를 일으킬 수 있기 때문입니다.

그래서 Vite는 vite build 명령 시 Rollup을 사용해 최적화된 번들을 생성합니다.

dist
├── assets/
├── chunks/
└── index.js

이 과정에서 다음과 같은 최적화가 이루어집니다.

Tree Shaking: 실제로 사용되지 않는 코드를 제거합니다.
Code Splitting: 페이지별로 필요한 코드만 분리해 로딩 성능을 높입니다.
Minify: 파일 크기를 최소화합니다.

Webpack vs Vite 한눈에 비교

항목ViteWebpack

Dev Server 시작	매우 빠름 (번들링 없음)	느림 (전체 번들링 필요)
개발 시 번들링	없음 (ES Module 직접 사용)	항상 수행
HMR 속도	매우 빠름 (파일 단위)	보통 (규모에 따라 느려짐)
설정 복잡도	간단	복잡
Production Build	Rollup 사용	Webpack 사용
node_modules 처리	esbuild pre-bundling	번들링에 포함

핵심 정리

Vite의 동작 원리를 한 문장씩 정리하면 다음과 같습니다.

ES Module 기반 Dev Server: 브라우저가 직접 모듈을 요청하고 실행합니다.
node_modules Pre-bundling (esbuild): 외부 패키지만 사전에 고속 번들링하고 캐시합니다.
src 파일 On-demand Transform: 실제 요청된 파일만 그때그때 변환합니다.
Production Build는 Rollup: 최적화된 번들을 생성해 배포 성능을 확보합니다.

결론적으로 Vite는 개발(dev) 환경에서는 빠르게, 배포(build) 환경에서는 최적화 이 두 가지를 동시에 달성한 도구입니다.

마무리

프론트엔드 개발 도구의 역사를 되짚어보면, 각 도구가 당시의 문제를 해결하기 위해 등장했다는 것을 알 수 있습니다.

script 태그 시대
  ↓
RequireJS (AMD, 모듈화)
  ↓
Webpack (번들링, 의존성 관리)
  ↓
Vite (ES Module, 번들링 없는 개발)

Vite는 단순히 "Webpack의 개선판"이 아닙니다. ES Module이라는 브라우저 표준이 성숙해진 시대에 맞춰, 개발 방식 자체를 다시 설계한 도구입니다. Vite가 왜 빠른지 이제 느낌이 오시나요? 단순히 "좋다더라"가 아니라, 구조적인 이유를 이해하고 사용하면 훨씬 더 효과적으로 활용할 수 있습니다.

다음 글에서는 Vite의 플러그인 시스템과 실제 프로젝트 설정 방법을 다뤄보겠습니다.

DOM(Document Object Model)과 Virtual DOM

Definitely Not Dj — Mon, 25 Aug 2025 22:27:58 +0900

0. 목차

서론
DOM(Document Object Model)이란?
Virtual DOM이란?
렌더링과 페인팅의 차이
Virtual DOM의 Diffing 알고리즘
실제 DOM의 수정은 어떻게 일어나는가?
결론

1. 서론

프론트엔드 개발을 공부하면서 처음에는 “어차피 부모가 리렌더링되면 자식도 다 같이 리렌더링 되는 거 아닌가? 그렇다면 Virtual DOM을 쓸 이유가 뭐지?”라는 의문이 있었습니다.
지금 생각해보면 그건 제가 React의 “렌더링(rendering)”과 브라우저의 “페인팅(painting)”을 명확히 구분하지 못했기 때문이었습니다.

이번 글에서는 그 과정을 정리하면서, DOM과 Virtual DOM, 그리고 실제 DOM이 어떻게 수정되는지에 대해 이해한 내용을 공유해 보겠습니다.

2. DOM(Document Object Model)이란?

DOM은 HTML 문서를 브라우저가 해석해서 메모리 속 객체 트리로 표현한 구조입니다.
즉, 우리가 작성한 HTML 파일 그 자체가 아니라, 브라우저 엔진이 만든 실시간 조작 가능한 데이터 구조입니다.

노드(Node): 태그, 속성, 텍스트 모두 노드로 표현
객체화: JavaScript에서는 document 객체를 통해 접근 가능
위치: 하드디스크가 아니라 브라우저 엔진 메모리 속에 존재

<html>
  <body>
    <h1>Hello</h1>
    <p>World</p>
  </body>
</html>

위 HTML은 다음과 같이 트리 형태의 DOM으로 변환됩니다:

Document
 └─ html
     └─ body
         ├─ h1 → "Hello"
         └─ p  → "World"

3. Virtual DOM이란?

Virtual DOM은 브라우저의 DOM 트리를 메모리 속 JavaScript 객체로 가볍게 복제한 것입니다.
React 같은 라이브러리에서 사용하는 개념으로, DOM 조작의 비용을 줄이기 위해 도입되었습니다.

동작 과정

상태/props 변경 → 새로운 Virtual DOM 생성
이전 Virtual DOM과 비교(diffing)
달라진 부분만 찾아내기
그 변경 사항만 실제 DOM에 반영(commit)

이 방식 덕분에 전체 DOM을 무겁게 다시 그리는 대신, 바뀐 부분만 최소한으로 고칩니다.

4. 렌더링과 페인팅의 차이

제가 처음 오해했던 지점은 바로 여기였습니다.
저는 한동안 “컴포넌트가 리렌더링된다 = 브라우저가 화면을 다시 그린다” 라고 생각했는데, 사실은 전혀 다른 단계였습니다.

React에서의 Rendering
→ 컴포넌트 함수가 다시 실행되고, 그 결과로 JSX를 반환
→ 이건 JavaScript 연산일 뿐, 브라우저 화면에는 아직 아무 일도 일어나지 않음
브라우저의 Painting
→ Virtual DOM diff 결과로 실제 DOM이 변경되면, 브라우저 엔진이 이를 받아
→ 레이아웃 계산(Layout) → 페인트(Paint) → 합성(Composite) 단계를 거쳐 화면 픽셀에 반영

구분	Rendering (React)	Painting (Browser)
실행 위치	JS 엔진	브라우저 렌더링 엔진
하는 일	컴포넌트 함수 실행 → JSX 반환	실제 DOM 변경 후 픽셀 다시 그림
비용	가볍다	무겁다
발생 조건	state/props 변경	Virtual DOM diff 결과로 실제 DOM 수정 발생

즉, 컴포넌트 함수가 다시 실행(rendering)되었다고 해서 브라우저가 반드시 다시 그린다(painting)는 뜻은 아니다 라는 점이 핵심입니다.

5. Virtual DOM의 Diffing 알고리즘

Virtual DOM의 핵심은 “변경 사항을 최소 단위로 찾아내는 것”입니다.

React는 성능을 위해 다음과 같은 단순화된 규칙을 둡니다:

1. 타입이 같은 요소는 속성만 비교 후 업데이트→ div 유지, className만 수정

<div className="red" /> → <div className="blue" />

2. 타입이 다른 요소는 새로 생성→ div 삭제, span 생성

<div /> → <span />

3. 리스트(children)는 key로 비교→ key 값이 같으면 같은 요소로 간주, 위치만 바꿈

<li key="a" /> <li key="b" /> → <li key="b" /> <li key="a" />

4. 이렇게 diff 결과가 나오면 React는 그에 맞춰 DOM API를 호출합니다.

6. 실제 DOM 수정은 어떻게 일어나는가?

DOM을 직접 관리하는 건 브라우저 엔진이지만, JavaScript는 DOM API를 통해 간접적으로 조작할 수 있습니다.

예시:

const el = document.createElement("div");   // 새로운 div 생성
el.textContent = "Hello";                   // 텍스트 삽입
document.body.appendChild(el);              // body에 붙이기

React도 결국 이와 같은 API를 사용합니다:

createElement, appendChild, removeChild
setAttribute, textContent

즉, React는 Virtual DOM diff 결과를 바탕으로 “어떤 DOM API를 호출할지” 결정하고, 브라우저 엔진에게 “이 부분만 고쳐줘”라고 요청하는 셈입니다.

7. 결론

DOM: 브라우저 엔진 메모리 속의 문서 객체 트리
Virtual DOM: DOM을 JS 객체로 가볍게 복제 → diff 계산 후 최소 변경만 반영
React Rendering: 컴포넌트 함수 호출, Virtual DOM 생성 (JS 연산)
Browser Painting: 실제 DOM 변경 반영, 픽셀 다시 그림 (브라우저 엔진 작업)

결론적으로, 제가 처음에 가졌던 의문, “부모가 리렌더링되면 자식도 전부 리렌더링 되는데 Virtual DOM은 왜 쓰는 거야?”

그 답은, 렌더링과 페인팅은 다르기 때문이었습니다.

React Hook의 등장 배경

Definitely Not Dj — Fri, 22 Aug 2025 19:36:19 +0900

0. 목차

초창기 React: 함수형 vs 클래스형
컴포넌트의 한계
Hook의 등장

1. 초창기 React: 함수형 vs 클래스형

React가 처음 나왔을 때, 컴포넌트에는 두 가지 방식이 있었습니다.

함수형(Function) 컴포넌트

function Hello(props) {
  return <h1>Hello, {props.name}</h1>;
}

자바스크립트에서 함수가 호출되면, 그 실행 과정은 실행 컨텍스트(Execution Context) 라는 단위로 **스택(Stack)**에 쌓입니다. 실행이 끝나면 해당 컨텍스트는 스택에서 제거되고, 내부의 지역 변수와 매개변수도 함께 사라집니다.

즉, 함수형 컴포넌트가 렌더링될 때마다:

새로운 실행 컨텍스트가 스택에 생성되고,
함수 내부에서 선언된 변수들은 그 안에 저장되지만,
렌더링이 끝나면 실행 컨텍스트가 스택에서 제거되며 변수도 함께 소멸됩니다.

이 때문에 함수형 컴포넌트는 렌더링 사이에 상태값을 붙잡아 둘 수 없었고, 특정 시점(마운트, 업데이트, 언마운트)에 개입할 수 있는 방법도 존재하지 않았습니다.

클래스형(Class) 컴포넌트

import React from "react";

class Counter extends React.Component {
  constructor(props) {
    super(props);
    // 힙에 존재하는 인스턴스의 상태
    this.state = { count: 0 };
  }

  componentDidMount() {
    // 마운트 직후 (DOM 준비 후) 1회 실행: 예) 데이터 fetch, 구독 시작
    console.log("mounted");
  }

  componentDidUpdate(prevProps, prevState) {
    // 업데이트 직후 실행: 예) props 변화 대응
    if (prevState.count !== this.state.count) {
      console.log("count changed:", this.state.count);
    }
  }

  componentWillUnmount() {
    // 언마운트 직전 정리(clean-up)
    console.log("unmounted");
  }

  handleInc = () => this.setState(s => ({ count: s.count + 1 }));

  render() {
    return (
      <button onClick={this.handleInc}>
        Count: {this.state.count}
      </button>
    );
  }
}

반대로 클래스형 컴포넌트(Class Component)는 React가 new 키워드로 인스턴스를 생성하여 힙(Heap) 메모리에 보관합니다.

이 인스턴스는 컴포넌트가 언마운트될 때까지 메모리에 남아 있으며,
this.state와 라이프사이클 메서드(componentDidMount, componentDidUpdate, componentWillUnmount)는 그 인스턴스 내부에 저장되어 렌더링 사이에도 계속 유지됩니다.

즉, 클래스형 컴포넌트는 한 번 생성된 객체가 메모리에 살아남아 있기 때문에 상태 관리와 생명주기 제어가 가능했던 것입니다.

2. Class 컴포넌트의 한계

하지만 클래스 방식은 점점 문제가 드러났습니다.

복잡한 라이프사이클 로직
- 데이터 fetch → 구독(subscribe) → 정리(clean-up) 같은 로직이 componentDidMount, componentDidUpdate, componentWillUnmount로 흩어져 관리됐습니다.
- 한 기능에 관련된 코드가 여러 메서드에 나뉘다 보니 유지보수가 어려웠습니다.
로직 재사용의 불편함
- 여러 컴포넌트에서 동일한 상태 로직을 쓰려면 HOC(Higher-Order Component)나 Render Props 같은 패턴을 사용해야 했습니다.
- 이 방식은 코드가 중첩되고 가독성이 떨어졌습니다.
this 바인딩 문제
- 클래스 내부 메서드에서 this를 올바르게 쓰기 위해 constructor에서 바인딩하거나, 화살표 함수를 쓰는 등의 번거로움이 있었습니다.
러닝 커브
- 함수형은 단순한데, 클래스 문법은 초심자에게 어렵게 느껴졌습니다.
- 특히 자바스크립트의 this 동작 원리를 알아야 했습니다.

3. Hook의 등장

React 팀은 “클래스 없이도 상태와 라이프사이클을 다룰 수 있게 만들자”라는 목표로 Hook을 도입했습니다. (React v16.8, 2019년)

useState: 함수형 컴포넌트에서도 상태를 가질 수 있게 함
useEffect: 라이프사이클을 하나의 API로 단순화 (mount/update/unmount 모두 처리)
useContext, useReducer, useMemo, useCallback: 다양한 상태/성능 최적화 도구 제공

Hook의 핵심 원리는 React가 함수 호출 외부(Heap)에 상태 저장소를 두고, 호출 순서를 기반으로 상태를 이어주는 것입니다.
덕분에 함수형 컴포넌트도 “상태를 가진 UI 단위”로 진화할 수 있었습니다.

4. 마무리

이번 글에서는 React Hook의 등장배경과 전반적인 개요를 다뤘습니다.
각 Hook의 자세한 내용 및 사용법은 앞으로 개별 포스팅에서 더 깊이 살펴보겠습니다.

NPM(Node Pacakge Manager)

Definitely Not Dj — Fri, 15 Aug 2025 12:19:53 +0900

0. 목차

개요
npm이 뭐에요?
package.json, node-modules, package-lock.json
npm / pnpm / npx 의 차이
package.json 구성
monorepo ( workspaces )

1. 개요

최근 폐쇄망 개발 프로젝트에 투입되면서, 독특한 개발 환경 설정 과정을 직접 경험했고 그 과정에서 npm에 대한 다양한 정보를 얻게 되었습니다. 이번 글에서는 그 경험을 기록해두려 합니다.

특히, Nexus에 자체 npm registry를 띄워 프로젝트의 기본 저장소로 설정하고, 모듈 파일을 직접 Nexus에 업로드하는 등 평소라면 접하기 어려운 절차를 거쳤습니다. 이러한 비일상적인 과정 속에서 뜻밖의 인사이트도 많이 얻을 수 있었습니다.

2. npm이 뭐에요?

npm(Node Package Manager)은 Node.js 환경에서 가장 널리 사용되는 패키지 관리자입니다. 프로젝트를 개발하다 보면 외부에서 만든 기능 모듈(라이브러리)을 가져다 쓰는 경우가 많은데, 이때 필요한 패키지를 쉽게 설치·관리·배포할 수 있도록 도와주는 도구가 바로 npm입니다.

npm은 크게 다음과 같은 역할을 합니다.

패키지 설치 (Install)
- npm install 패키지명 명령으로 수많은 오픈소스 라이브러리를 손쉽게 프로젝트에 추가할 수 있습니다.
- 예: npm install express → 웹 서버 프레임워크 Express 설치
의존성 관리 (Dependency Management)
- package.json 파일을 통해 프로젝트에서 사용하는 패키지와 버전을 기록합니다.
- 다른 개발자가 프로젝트를 받아도 npm install만 실행하면 동일한 환경이 세팅됩니다.
패키지 배포 (Publish)
- 자신이 만든 모듈을 npm registry에 업로드하여 전 세계 개발자들과 공유할 수 있습니다.
스크립트 실행 (Scripts)
- package.json에 정의한 빌드, 테스트, 배포 스크립트를 npm 명령어로 실행할 수 있습니다.

정리하면, npm은 Node.js 생태계의 필수 인프라로, 개발자가 재사용 가능한 코드를 쉽게 공유·활용할 수 있도록 하는 중심 허브 역할을 합니다.

3. package.json, node-modules, package-lock.json

프로젝트를 비행기로 비유하여 package.json, node-modules와 package-lock.json 파일이 각각 어떤 역할을 담당하는지 표현해보겠습니다.

비행기	프로젝트
부품 설계도	package.json
부품 창고	node_modules
부품 마켓	npm registry
부품 구매 영수증	package-lock.json

1. package.json — 부품 설계도

비행기를 만들려면 먼저 어떤 부품이 필요한지와 어느 정도 규격(버전)의 부품이면 되는지를 적은 설계도가 필요합니다.

2. node_modules — 부품 창고

설계도가 있다면, 이제 부품 마켓(npm registry)에 가서 부품을 사와야 합니다.

사온 부품들은 비행기 조립 공장 옆 창고( node_modules )에 차곡차곡 쌓입니다. 이 창고에는 설계도에 적힌 부품뿐 아니라, 그 부품이 또 필요로 하는 하위 부품까지 모두 들어옵니다.

3. package-lock.json — 부품 구매 영수증

package.json에는 보통 이렇게 버전의 범위가 적혀 있습니다.

"axios": "^1.6.0"

여기서 ^1.6.0은 “1.6.0 이상, 2.0 미만이면 다 OK”라는 뜻입니다. 즉, 오늘 설치하면 1.6.0이 깔릴 수 있지만,

한 달 뒤에 설치하면 1.7.2가 깔릴 수도 있습니다.

A 개발자: 어제 npm install 해서 axios 1.6.0 설치
B 개발자: 오늘 npm install 했더니 axios 1.7.2 설치

겉으로 보기엔 같은 패키지를 쓴 것 같지만, 내부 동작이 조금 달라서 A는 정상 동작하지만 B는 에러가 발생하는 일이 생길 수 있습니다. 이러한 상황 때문에 필요한 것이 영수증( package-lock.json ) 입니다.

package-lock.json은 “설치할 때 정확히 어떤 버전을 썼는지”를 스냅샷처럼 기록합니다.

axios@1.6.0 resolved: https://registry.npmjs.org/axios/-/axios-1.6.0.tgz integrity: sha512-...

이 기록을 기반으로 npm install 하면, 모든 개발자·서버가 무조건 같은 버전의 axios를 설치하게 됩니다.

4. npm / pnpm / npx 의 차이

1. npm (Node Package Manager)

역할: Node.js의 기본 패키지 관리자
주요 기능:
- 패키지 설치: npm install react
- 의존성 관리: package.json, package-lock.json 생성·갱신
- 스크립트 실행: npm run build
특징:
- Node.js 설치 시 기본 포함
- 패키지를 로컬(node_modules) 또는 전역(-g)에 설치 가능
- 의존성 설치 시 중복 패키지가 많아질 수 있음 (폴더 구조 깊어짐)

2. pnpm (Performant npm)

역할: npm을 대체하는 고속·저용량 패키지 관리자
주요 기능: npm과 동일 (명령어도 유사)
- 예: pnpm install react
특징:
- *하드 링크 + *심볼릭 링크 구조를 사용해 패키지를 전역 저장소에 한 번만 설치하고, 각 프로젝트에서 참조
- 중복 설치를 줄여 속도↑, 디스크 사용량↓
- 의존성 충돌 방지: 프로젝트마다 독립적인 환경 유지
- 모노레포(Monorepo) 환경 지원 강화
단점:
- npm 대비 상대적으로 역사가 짧아 일부 생태계 호환성 이슈가 있을 수 있음

*하드링크 : 같은 파일 데이터를 가리키는 또 다른 이름으로, 원본이 삭제돼도 데이터는 유지됨.
*심볼릭링크 : 원본 경로를 가리키는 포인터로, 원본이 삭제되면 링크가 깨짐.

3. npx (npm package executor)

역할: 패키지를 설치하지 않고 바로 실행할 수 있는 도구
주요 기능:
- 로컬에 설치된 패키지의 실행 파일 호출
  - 예: npx jest → node_modules 안의 jest 실행
- 설치 없이 일회성으로 실행
  - 예: npx create-react-app my-app → create-react-app 패키지를 다운로드 후 즉시 실행, 사용 후 폐기
특징:
- CLI 도구나 생성기(generator) 실행에 자주 사용
- 설치를 최소화해 전역 환경 오염 방지

5. package.json 구성

1. package.json 예시

{
  "name": "my-project",               // 패키지 이름 (npm 배포 시 식별자)
  "version": "1.0.0",                  // 패키지 버전 (SemVer 규칙)
  "description": "React 기반 웹 앱",   // 프로젝트 설명
  "author": "홍길동 <hong@example.com>", // 작성자 정보
  "license": "MIT",                    // 라이선스 종류

  "main": "index.js",                  // CommonJS 환경 진입점
  "module": "index.mjs",               // ES Module 환경 진입점
  "type": "module",                    // 모듈 유형 ('commonjs' or 'module')

  "scripts": {                         // npm run <스크립트명> 으로 실행
    "start": "node index.js",          // 예: npm run start
    "build": "webpack",                // 예: npm run build
    "test": "jest"                     // 예: npm run test
  },

  "dependencies": {                    // 런타임(서비스 실행 시) 필요한 패키지
    "express": "^4.19.2",
    "react": "^18.2.0"
  },

  "devDependencies": {                 // 개발·빌드 시에만 필요한 패키지
    "webpack": "^5.89.0",
    "jest": "^29.7.0"
  },

  "peerDependencies": {                // 호스트 앱이 설치해야 하는 호환 패키지
    "react": ">=18"
  },

  "optionalDependencies": {            // 설치 실패해도 무시되는 선택적 의존성
    "fsevents": "^2.3.3"
  },

  "engines": {                          // 지원 Node.js / npm 버전
    "node": ">=18",
    "npm": ">=9"
  },

  "repository": {                       // 소스 코드 저장소 정보
    "type": "git",
    "url": "https://github.com/user/my-project.git"
  },

  "keywords": ["react", "frontend", "web"], // npm 검색 키워드
  "files": ["dist", "src/index.js"],    // npm 배포 시 포함할 파일
  "private": true                       // true면 npm 배포 방지
}

2. 버전 표기법

예: 1.0.0 → 주버전 1, 부버전 0, 패치 0

주버전 : 하위 호환이 깨지는 변경
부버전 : 하위 호환을 유지한 기능 추가
패치 : 버그 수정/미세 변경

3. 범위 지정자 (dependencies 등)

비교 연산자	지정한 조건에 맞는 버전 설치	>=1.6.0 / < 2.0.0 / >=1.6.0 <2.0.0	1.6.0 이상 / 2.0.0 미만 / 1.6.0 이상 2.0.0 미만
^ (캐럿)	주버전 유지 내에서 자동 업데이트, 단 0대 버전은 틸드와 동일	^5.89.0 / ^0.0.5	>=5.89.0 < 6.0.0 / >=0.0.5 < 0.0.6
~ (틸드)	부버전 유지 내에서 자동 업데이트	~1.2.3 / ~1.2	>=1.2.3 < 1.3.0 / >=1.2.0 < 1.3.0
하이픈 범위	시작~끝 버전 범위 지정	1.2.3 - 1.4.0	>=1.2.3 <=1.4.0
X-Range / 와일드카드	일부 자리만 고정, 나머지는 자유	1.2.x / 1.x / *	>=1.2.0 <1.3.0 / >=1.0.0 <2.0.0 / 모든 버전 허용(권장 X)
프리릴리스	사전배포 버전 지정	1.2.0-beta.2	일반 범위(^1.2.0)에는 자동 포함 안 됨, 정확히 지정 필요

6. monorepo ( workspace )

모노레포(Monolithic Repository)는 여러 개의 프로젝트(패키지)를 하나의 저장소(repository)에서 관리하는 방식입니다.

예를 들어, 프론트엔드 웹 앱, 백엔드 API 서버, UI 컴포넌트 라이브러리, 공용 유틸리티 모듈 등을 각각 별도의 저장소로 운영하는 대신, 하나의 Git 저장소 안에 디렉터리 구조로 함께 배치하는 것입니다.

아래 코드 예시로 monorepo 구조와 사용법을 확인하며 포스팅을 마치겠습니다.

1. 디렉터리 구조

.
├─ apps/
│  ├─ web/
│  │  └─ package.json
│  └─ admin/
│     └─ package.json
├─ packages/
│  ├─ ui/
│  │  └─ package.json
│  └─ utils/
│     └─ package.json
├─ pnpm-workspace.yaml
├─ package.json
└─ pnpm-lock.yaml

2. 워크스페이스 선언 ( pnpm )

//pnpm-workspace.yaml

packages:
  - "apps/*"
  - "packages/*"

3. 로컬 패키지 의존성 연결 (workspace: 프로토콜)

packages/ui/package.json

{
  "name": "@acme/ui",
  "version": "1.0.0",
  "main": "dist/index.js",
  "types": "dist/index.d.ts",
  "scripts": {
    "build": "tsc -p tsconfig.json",
    "lint": "eslint ."
  }
}

packages/utils/package.json

{
  "name": "@acme/utils",
  "version": "1.0.0",
  "main": "dist/index.js",
  "types": "dist/index.d.ts",
  "scripts": {
    "build": "tsc -p tsconfig.json",
    "lint": "eslint ."
  }
}

apps/web/package.json — 로컬 패키지를 workspace로 참조

{
  "name": "@acme/web",
  "version": "1.0.0",
  "private": true,
  "scripts": {
    "dev": "vite",
    "build": "tsc -p tsconfig.json && vite build",
    "test": "vitest",
    "lint": "eslint ."
  },
  "dependencies": {
    "@acme/ui": "workspace:^",        // 로컬 패키지 연결(호환범위 ^)
    "@acme/utils": "workspace:*",     // 동일 버전 강제하지 않고 최신 workspace 사용
    "react": "^18.2.0"
  }
}

workspace:*, workspace:^, workspace:~ 중 선택

* : 워크스페이스 최신
^ : 주버전 호환
~ : 부버전 호환

취업 후 1년 회고, 앞으로

Definitely Not Dj — Tue, 22 Jul 2025 21:24:01 +0900

입사 후 1년

2024년 7월 22일, 첫 회사에 입사해 C# 엔지니어로 일한 지 어느덧 1년이 지났다. 1년 동안 시뮬레이션 모델을 개발하며 여러 프로젝트에 참여했고, 그 과정에서 기술 외에도 많은 것을 배웠다.

커뮤니케이션 능력

반년 넘게 ‘엔진 고도화’ 프로젝트를 진행하면서 고객과 거의 매일 대화를 나눴다. 그 과정에서 커뮤니케이션 능력이라는 것이 단순히 말을 잘하는 것을 뜻하지 않는다는 걸 절실히 느꼈다.

신기하게도 같은 한국말을 쓰고 있지만, 고객과 개발자의 언어는 달랐다. 고객은 현업의 용어로 이야기했고, 개발자인 나는 변수명과 컬럼명으로 설명했다. 서로 같은 이야기를 하면서도 엇갈리는 순간이 많았다. 그럴 때마다 대화의 목적과 문맥을 먼저 이해하려고 노력해야 했고, 내 언어를 그들의 언어로 ‘번역’하는 것이 중요하다는 걸 깨달았다.

고객뿐만 아니라 직장 동료, 상사, 인계자 등 누군가와 소통할 때 항상 내가 이해한 상대방의 말을 나의 언어로 다시 상대방에게 되묻는 버릇이 생겼다.

독서에 대한 태도의 변화

예전엔 책을 읽으면 내용이 머릿속에서 흘러나갈까 봐 걱정부터 했다. 30페이지쯤 읽고 나면 꼭 메모장을 열어 느낀 점과 핵심 내용을 상세히 정리했다. 언제든지 꺼내볼 수 있게 해두고 싶었다. 나중에 필요할 때, 머릿속에서 바로 꺼낼 수 있도록 말이다.

하지만 요즘은 생각이 달라졌다. 꼭 모든 내용을 외우지 않아도 된다고 느꼈다. 오히려 더 많은 지식에 노출되는 게 중요하다는 걸 알게 됐다. 비슷한 상황이 닥쳤을 때 "아, 그때 그런 내용이 있었지" 정도만 기억하고 있어도 충분했다. 정확한 방법은 구글링을 하거나 ChatGPT에 물어보면 찾을 수 있으니까. 이제는 ‘바이브 코딩’까지 유행하는 시대 아닌가.

그래서 요즘은 책을 읽을 때 힘줘서 외우거나 정리하려고 하지 않고 교양서를 읽듯이 편하게 읽는다.

2025. 07. 22 ~

남은 하반기에 하고자 하는 일이 있다면, 첫째는 입사 후 바빠서 손 놓았던 코딩테스트 문제를 조금씩 다시 풀어보는 것이고, 둘째는 시스템 디자인과 관련된 책을 3권 정도 읽어보는 것, 마지막은 링크드인에 내가 여태껏 사용했던 기술 스택들을 사소한 것이라도 모두 남겨놓는 것이다.

SPA(Single Page Application) , Client-Side Routing

Definitely Not Dj — Wed, 12 Jun 2024 15:56:06 +0900

서론

SPA의 정의 및 기본 개념

SPA(Single Page Application)는 단일 HTML 페이지로 구성된 웹 애플리케이션을 의미합니다. 사용자가 웹 페이지를 탐색할 때, 전체 페이지를 다시 로드하지 않고 현재 페이지 내에서 필요한 콘텐츠만 동적으로 로드하여 빠르고 원활한 사용자 경험을 제공합니다. 이는 주로 JavaScript 프레임워크와 라이브러리를 활용하여 구현됩니다.

SPA의 동작 원리

기존의 다중 페이지 애플리케이션(MPA)에서는 사용자가 다른 페이지로 이동할 때마다 서버로부터 새로운 HTML 페이지를 받아오고 전체 페이지를 새로 고칩니다. 반면에 SPA에서는 처음에 한 번만 전체 페이지를 로드하고, 이후의 페이지 전환은 서버와 비동기적 통신(AJAX)을 통해 필요한 데이터만 받아와 화면을 동적으로 갱신합니다. 이를 통해 페이지 이동 시 발생하는 로딩 시간을 최소화하고, 부드러운 UX를 사용자에게 제공합니다.

이미지 출처 - https://www.scalablepath.com/front-end/single-page-applications

본론

사실 실제로 서비스화 될 규모의 웹 사이트에 페이지가 하나만 존재한다는 것은 불가능합니다. 이러한 이유로 SPA에서는 여러 페이지를 사용자에게 제공하기위해 Client-Side Routing(CSR)을 사용합니다. ~~라우팅이란 사용자가 특정 URL을 방문할 때 해당 URL에 맞는 페이지나 콘텐츠를 제공하는 방식입니다.~~

Server-Side Routing VS Client-Side Routing

기존의 MPA에서는 각 페이지가 별도의 HTML 파일로 구성되어 있으며, 사용자가 URL을 변경할때 서버에게 해당 URL의 HTML 을 요청하고 받은 HTML로 페이지를 그립니다. 즉, 서버에게 "페이지" 자체를 받는다고 봐도 무방하죠. 이게 Server-Side Routing 입니다.

이미지 출처 - https://www.telerik.com/blogs/what-is-react-router-what-is-react-location

반면, SPA에서 사용하는 Client-Side Routing은 URL에 맞는 콘텐츠를 서버에 요청하지 않고, 클라이언트 측에서 동적으로 제어하여 URL에 맞는 페이지를 로딩합니다. 이를 가능하도록 하는 대표적인 라이브러리로는 React Router와 Vue Router가 있습니다.

이미지 출처 - https://www.telerik.com/blogs/what-is-react-router-what-is-react-location

React Router를 프로젝트에서 사용해보신 분이라면, 최상위 컴포넌트에서 보여줄 페이지들을 Route 요소로 정의하고, 이를 BrowserRouter 태그로 감싸야 한다는 사실을 알고 계실 겁니다.

const App = () => {
	return (
		<div className='App'>
			<BrowserRouter>
				<Routes>
					<Route path="/" element={<Main />}></Route>
					<Route path="/product1/" element={<Product1 />}></Route>
					<Route path="/product2/" element={<Product2 />}></Route>
					<Route path="/product3/" element={<Product3 />}></Route>
				</Routes>
			</BrowserRouter>
		</div>
	);
};

즉, 최상위 App 컴포넌트 하나만 존재하고, 이 App 컴포넌트 안에 여러 하위 페이지를 포함하며, React Router(또는 다른 브라우저 라우터 라이브러리)를 사용하여 각 하위 페이지에 URL이라는 이름을 부여합니다.

사용자가 특정 URL을 요청하면, React Router는 해당 URL과 일치하는 하위 페이지 컴포넌트를 화면에 보여주고, 일치하지 않는 컴포넌트는 감춥니다. 이로 인해 페이지 전체를 다시 로드하지 않고도 URL에 따라 다른 콘텐츠를 표시하며 사용자들은 SPA가 여러 페이지처럼 보일 수 있게 됩니다.

결론

SPA는 이러한 클라이언트 사이드 라우팅을 통해 페이지 전환 시 발생하는 불필요한 로딩을 없애고, 더 직관적이고 효율적인 웹 애플리케이션을 구현할 수 있습니다.

React Router와 같은 라이브러리를 통해 URL 관리와 페이지 전환을 간편하게 처리할 수 있습니다. 결국, SPA는 MPA처럼 보이지만, 실제로는 더 나은 성능과 사용자 경험을 제공하는 현대적인 웹 애플리케이션 개발 방식입니다.

여기까지 제가 SPA에 대해 처음 공부했을 때 오해했던 부분에서 비롯된 인사이트를 위주로 설명해봤습니다. 다음 포스팅에서는 React DOM과 같은 SPA의 최적화 부분에 초점을 맞춰 SPA 관련 포스트를 한번 더 업로드 하도록 하겠습니다.

[백준 / BOJ] 10986번 나머지 합 (Javascript / Node js)

Definitely Not Dj — Tue, 4 Jun 2024 15:21:16 +0900

https://www.acmicpc.net/problem/10986

누적합(prefix sum)

먼저 누적합이란 나열된 수의 누적된 합을 말한다. 만약 [1, 2, 3, 4, 5] 라는 배열이 있고, 이 배열을 누적합으로 나타낸다면 [1, 3, 6, 10, 15] 가 된다.

보통 반복문을 통해 `0번 index부터 4번 index까지의 누적합`을 구한다면 5번의 수행동작이 필요하다. 즉 O(N)의 시간 복잡도를 갖는 것이다. 하지만 누적합을 사용하여 `0번 index부터 4번 index까지의 누적합`을 구한다면 누적합 배열의 4번 index 값을 꺼내오기만 하면 되기 때문에 O(1)의 시간 복잡도를 갖는다.

그렇다면 `2번 index부터 4번 index까지의 누적합`을 구하기 위해서는 어떻게 해야할까? (1 + 2 + 3 + 4 + 5)[0 ~ 4] 에서 (1 + 2)[0 ~ 1]을 빼주면 (3 + 4 + 5)[2 ~ 4]가되기 때문에 누적합 배열 4번 인덱스 값 15에서 1번 인덱스 값 3 을 빼주면 된다.

문제 풀이

처음에는 이중 for문의 i와 j를 완전 탐색하여 누적합의 i번째 index의 값에서 j번째 index값을 빼주는 방식으로, j ~ i의 구간합이 m으로 나누어 떨어지는지 검사하였다. 하지만 수의 개수가 최대 10억개이기 때문에 당연히 시간초과가 발생했다.

//나머지 합
const fs = require('fs');

const [[N, M], arr] = fs
  .readFileSync(0)
  .toString()
  .trim()
  .split('\n')
  .map((item) => item.split(' ').map((v) => +v));

let prefix_sums = Array(N);
prefix_sums = [...arr];

//누적합 배열 생성
for (let i = 1; i < N; i++) {
  prefix_sums[i] = prefix_sums[i] + prefix_sums[i - 1];
}

let cnt = 0;

//M으로 나누어 떨어지는 구간합 탐색
for (let i = 0; i < N; i++) {
  if (prefix_sums[i] % M === 0) cnt++;
  for (let j = 0; j < i; j++) {
    if ((prefix_sums[i] - prefix_sums[j]) % M === 0) {
      cnt++;
    }
  }
}

console.log(cnt);

그렇기 때문에 모든 구간합에 대해 검사하지 않기 위해서 한가지 아이디어가 더 필요했다. 그 아이디어는 다음과 같다.

세개의 수 N, K, M에 대하여 N % M === K % M 일 경우 (N - K)는 M으로 나누어 떨어진다.
예시) N이 23이고, K가 28, M이 5라고 가정했을 때, N % M 과 K % M의 값은 3으로 동일

N은 (20 + 3), K는 (25 + 3)으로 나타 낼 수 있는데, N(20 + 3) - K(25 + 3)을 하게 될 경우 나머지인 3이 소거되기 때문이다.

이러한 이유로 j부터 i까지의 구간합 prefix_sum[i] - prefix_sum[j] 에 대해서

prefix_sum[i] % m === prefix_sum[j] % m 이라면 prefix_sum[i] - prefix_sum[j]은 m으로 나누어 떨어진다. 즉, j부터 i까지의 구간합이 m으로 나누어 떨어진다.

이제 위 식을 사용하기 위해서 누적합의 각 index 별 M으로 나누었을 때의 나머지 값들을 모두 저장해두고 같은 나머지 값을 갖는 누적합끼리 같은 집합으로 묶는다. 그리고 각 집합 별 전체 원소 n개 중 2개의 원소를 뽑아내는 경우의 수 nC2를 구하고, 집합 별 nC2들을 모두 더해주면 0으로 나누어 떨어지는 모든 경우의 수를 구할 수 있다.

실제 값을 대입하여 살펴보자.

Ex) prefix_sum = [1, 3, 6, 10, 15] 에 대하여 2로 나누었을 때

나머지가 0이 나오는 수의 개수 2개 {6, 10} // (10 - 6)은 2로 나누어 떨어짐, 10 - 6은 index 3부터 4까지의 구간합
나머지가 1이 나오는 수의 개수 3개 {1, 3, 15} // (3 - 1), (15 - 3), (15 - 1) 모두 2로 나누어 떨어짐

{6, 10} 에서 두개의 원소를 뽑아내는 경우의 수 === 2C2

{1, 3, 15} 에서 두개의 원소를 뽑아내는 경우의 수 === 3C2

2C2 + 3C2 = 1 + 3 = 4

그리고, nC2의 경우 위와 같이 식을 정리할 수 있기 때문에 팩토리얼이 필요없이 n * (n - 1)이란 식만으로 값을 구할 수있다.

전체코드

//나머지 합
const fs = require('fs');

const [[N, M], arr] = fs
  .readFileSync('../input.txt')
  .toString()
  .trim()
  .split('\n')
  .map((item) => item.split(' ').map((v) => +v));

let prefix_sums = Array(N);
prefix_sums = [...arr];

let map = new Map();

let cnt = 0;

if (prefix_sums[0] % M === 0) {
  cnt++;
}
map.set(prefix_sums[0] % M, 1);

// M으로 나누었을 때 나머지 값 r의 집합
// expected : {나머지 : 개수, 1 : 3, ...}
for (let i = 1; i < N; i++) {
  prefix_sums[i] = prefix_sums[i] + prefix_sums[i - 1];
  let mod = prefix_sums[i] % M;
  if (!mod) {
    cnt++;
  }

  if (map.has(mod)) {
    map.set(mod, map.get(mod) + 1);
  } else {
    map.set(mod, 1);
  }
}

// nC2
map.forEach((value) => {
  cnt += (value * (value - 1)) / 2;
});

console.log(cnt);

[백준 / BOJ] 11444번 피보나치 수 6 (Javascript / Node js)

Definitely Not Dj — Tue, 4 Jun 2024 13:15:10 +0900

https://www.acmicpc.net/problem/11444

인사이트

이번 문제는 우리들이 사랑하는 피보나치 수열이다. 피보나치 수열이 골드2까지 난이도가 책정된 이유에는 입력값의 크기 제한에 있다.

일반적으로 1초에 대략 1억번 정도의 연산이 처리된다는 것을 감안하면, 입력값의 최대값이 1000억이기 때문에 dp를 사용해서 O(N)의 시간 복잡도로 처리해도 시간 초과가 날 것임을 예상할 수 있다.

그렇기 때문에 피보나치 수열의 일반항으로는 어떤 짓을 해도 시간초과를 해결할 수 없을 것이다. 해서, 이 피보나치 수열의 일반항에서 시간 처리를 극적으로 줄일 점화식을 고안해내야 한다. 여기서 한가지 더 생각해보면 1000억이란 숫자를 1억 내로 안정적으로 줄이려면 제곱근으로 접근하는 것 외에는 거의 방법이 없을 것임을 생각해볼 수 있다.

사실은 이러한 인사이트는 추후에 든 생각이고, 처음에는 막연히 식을 풀어봤었다.

문제 풀이

피보나치 수열의 일반항은 `F(n) = F(n-1) + F(n-2)` 다. 그리고 같은 식으로 `F(n-1) = F(n-2) + F(n-3)` 이다. 때문에, 일반항 `F(n) = F(n-1) + F(n-2)`의 F(n-1)이 F(n-2) + F(n-3)으로 치환이 가능함으로 `F(n) = 2F(n-2) + F(n-3)`이 성립한다.

다시 마찬가지로 F(n-2) = F(n-3) + F(n-4)로 치환이 가능하고 이 과정을 반복하다 보면, F(n) 을 다음과 같은 식들로 표현이 가능하다.

그런데 각 F(n-k) 와 F(n-k-1) 앞의 상수를 살펴보면 마찬가지로 피보나치 수열을 이루고 있는 것을 알 수 있다. (여기서 k는 `F(n) = F(n-1) + F(n-2)` 에서 1과 2를 뜻함)

그리고 이 피보나치 수열이 F(n-k) 앞의 상수는 피보나치 수열 F(k + 1)이고 F(n-k-1) 앞의 상수는 F(k)라는 것까지 알아낼 수 있다. 이제 식 `F(n) = F(k+1) * F(n-k) + F(k) * F(n-k-1)` 이 된다.

그럼 이제 F(n)의 n에 k를 대입하면 일반항을 k로 재정립할 수 있게 된다. 하지만 F(n-k)와 F(n-k-1)을 고려하여 2k를 넣도록 하자. 그럼 최종적으로 아래와 같이 식이 정리된다. ~~+ (n 에 k-1을 넣으면 원래의 피보나치 수열의 일반항으로 돌아간다. 수학은 정말 신비롭다.)~~

F(2k)

하지만 위 식은 2k에 대한 식이므로 짝수의 경우만 구할 수 있기 때문에 홀수에 대한 식을 추가로 세워야 한다. 홀수의 경우는 n에 2k+1을 넣는 것으로 하자.

F(2k + 1)

처음 목표로 했던 좌변의 대입값을 제곱으로 표현하는 것에 성공했다. 이제 위 두 식을 이용해 짝수와 홀수의 경우를 분할하여 각각 재귀적으로 구하면 되겠다. 당연히 입력값이 1000억이나 되니 구한 값은 메모이제이션하여 dp의 TopDown 방식으로 구해내면 되겠다.

아래는 구현한 코드이다.

const fs = require('fs');
const mod = 1000000007n;
const N = BigInt(fs.readFileSync('../input.txt').toString().trim());
let memo = new Map();

const fibo = (N) => {
  if (N === 0n) return 0n;
  if (N === 1n) return 1n;
  if (N === 2n) return 1n;
  if (memo[N] > 0n) return memo[N];

  if (N % 2n === 0n) {
    memo[N] = (fibo(N / 2n) * (fibo(N / 2n + 1n) + fibo(N / 2n - 1n))) % mod;
  }

  if (N % 2n === 1n) {
    memo[N] = (fibo((N + 1n) / 2n) ** 2n + fibo((N - 1n) / 2n) ** 2n) % mod;
  }

  return memo[N];
};

console.log(fibo(N).toString().replace('n', ''));

[백준 / BOJ] 17114번 하이퍼 토마토 (Javascript / Node js)

Definitely Not Dj — Sun, 26 May 2024 23:38:35 +0900

https://www.acmicpc.net/problem/17114

문제 해설

이번 하이퍼 토마토 문제는 지난 토마토 문제에서 배열의 깊이가 2차원에서 11차원으로 변형된 심화 문제입니다.

[백준 / BOJ] 7576번 토마토 ( Node js / Javascript )

https://www.acmicpc.net/problem/7576 문제 풀이토마토는 BFS의 대표 문제들 중 하나입니다. 만약 BFS 혹은 그래프 탐색 자체에 대한 지식이 부족하다면 아래 링크를 참고하시길 바랍니다. 너비 우선 탐

dnd0707.tistory.com

언뜻 보기에는 11차원이라는 말도 안되는 조건 때문에 괴랄해 보이겠지만 사실은 보이는 것 만큼의 난이도를 가진 문제는 아닙니다. 만약 만약 x축이 이동할 때 동시에 y축도 이동이 가능하다면 문제가 생기겠지만, 해당 문제의 조건에서는 한번의 이동에서 이동 가능한 축은 하나로 제한되어 있기 때문에 사실상 이동 방향의 선택지가 4(2 x 2)개에서 22(11 x 2)개로 늘어났을 뿐이기 때문입니다.

그리고, m * n * o * p * q * r * s * t * u * v * w의 값이 10^6으로 제한되어 있는 것을 볼 수 있습니다. 하지만 그럼에도 지난 2차원 배열에서의 로직만으로 시간 제한안에 통과하는 건 당연히 무리가 있었기 때문에, 지난 토마토 문제에서의 코드를 극한으로 최적화해보는 좋은 경험이 되었습니다.

BFS에 대한 설명은 2차원 토마토에서 충분히 다뤘기 때문에 이번 문제에서는 2차원 토마토 코드와의 차이점을 중점으로 설명하도록 하겠습니다.

생각해낸 개선점은 다음과 같습니다.

1. 지난 코드는 안익은 토마토가 남아있는지 검사하기 위해서 bfs가 끝난 뒤 배열을 한번 더 순회했습니다. 처음 시작점 (1)을 찾는 반복문 내에서 0의 개수를 카운트하여 초기 익지 않은 토마토의 개수를 세고, bfs 동작 과정에서 0을 1로 바꿀때마다 카운트하여 익힌 토마토의 개수를 세어 이 둘이 일치하지 않을 경우 익지 않은 토마토가 존재한다고 판단하도록 개선했습니다.

2. 위 코드에서는 선형 시간 복잡도 O(N)의 shift()연산을 피하기 위해 매 반복마다 nextQueue에 다음에 탐색할 노드들을 담고, queue를 nextQueue 로 교체했었는데, 이번에는 linked list 자료구조를 사용해 Queue를 직접 구현하여 사용했습니다.

여기까지는 순조로우나 해결해야 될 부분이 하나 더 남았습니다.

입력값

입력 처리 부분에서 2차원 배열의 경우에는 받은 입력을 그대로 사용해도 문제가 없었지만, 이번 문제의 경우는 11차원이기 때문에 2차원으로 받은 배열을 11차원으로 가공해주어야 합니다.

예를 들어 입력이 다음과 같을 경우, 5 x 3 짜리 2차원 배열이 2개 있는 것이기 때문에 3줄이 들어왔을 때, 끊어주고 다음 배열에 넣어주는 작업이 필요합니다. 그리고 입력이 5 3 2 2 ... 라면 5 x 3 짜리 2차원 배열이 2개 들어있는 배열이 2개 존재한다는 뜻입니다.

이미 3차원 토마토에서 한번 겪어본 맥락이기 때문에 어떻게 해야 될지는 금방 감이 잡혔지만, 11차원을 구현하기 위해 비윤리적으로 늘어난 indent 때문에 생각보다 구현에서 애를 먹었습니다.

그렇게 처음 shift() 연산을 사용해서 2차원 배열을 11차원으로 구현했고 시간초과가 발생했습니다. m * n * o * p * q * r * s * t * u * v * w 의 값이 10^6이란건 최악의 경우 m,n,o,p,q,r,s,t,u,v 가 1이고, w가 10^6일 수도 있다는 점을 간과한 것이 문제였습니다.

이렇게 w가 10^6일 경우 시간 복잡도 O(N)의 shift()연산을 10^6 수행하게 되니 당연히 시간초과가 발생하게 됩니다.

이는 shift()연산을 포인터로 대체하여 해결했습니다.

+ shift() 연산이 O(N)의 시간복잡도를 갖는 이유는, [1, 2, 3, 4]라는 배열에서 shift()연산을 수행하게 되면 1만 제거하는 것이 아닌, 1을 제거한 뒤 2, 3, 4를 전부 한칸씩 앞으로 가져와야하기 때문입니다.

그렇기 때문에 이를 포인터로 대체하여 배열은 그대로 두고, 포인터가 가르키는 index를 1씩 증가하도록 대체하면 시간복잡도는 O(1)로 개선됩니다.

전체 코드

//하이퍼 토마토
class Node {
  constructor(value, next) {
    this.value = value;
    this.next = next;
  }
}

class Queue {
  constructor() {
    this.lastNode = null;
    this.length = 0;
    this.firstNode = null;
  }

  push(v) {
    if (this.length === 0) {
      this.firstNode = new Node(v, null);
      this.lastNode = this.firstNode;
    } else {
      let newNode = new Node(v, null);
      this.lastNode.next = newNode;
      this.lastNode = newNode;
    }
    this.length++;
  }

  pop() {
    if (this.length === 0) return undefined;
    let secondNode = this.firstNode.next;
    let value = this.firstNode.value;
    this.firstNode = secondNode;
    if (this.length === 1) this.lastNode = null;
    this.length--;
    return value;
  }
}

const fs = require('fs');

let [[m, n, o, p, q, r, s, t, u, v, w], ...arr] = fs
  .readFileSync('../../input.txt')
  .toString()
  .trim()
  .split('\n')
  .map((item) => item.split(' ').map((v) => +v));

let map = Array(w)
  .fill(0)
  .map((w_v) =>
    Array(v)
      .fill(0)
      .map((v_v) =>
        Array(u)
          .fill(0)
          .map((u_v) =>
            Array(t)
              .fill(0)
              .map((t_v) =>
                Array(s)
                  .fill(0)
                  .map((s_v) =>
                    Array(r)
                      .fill(0)
                      .map((r_v) =>
                        Array(q)
                          .fill(0)
                          .map((q_v) =>
                            Array(p)
                              .fill(0)
                              .map((p_v) =>
                                Array(o)
                                  .fill(0)
                                  .map((o_v) =>
                                    Array(n)
                                      .fill(0)
                                      .map((n_v) => 0)
                                  )
                              )
                          )
                      )
                  )
              )
          )
      )
  );

let cnt_0 = 0;
let indexes = [];

let arr_index = 0;
for (let i1 = 0; i1 < w; i1++) {
  for (let i2 = 0; i2 < v; i2++) {
    for (let i3 = 0; i3 < u; i3++) {
      for (let i4 = 0; i4 < t; i4++) {
        for (let i5 = 0; i5 < s; i5++) {
          for (let i6 = 0; i6 < r; i6++) {
            for (let i7 = 0; i7 < q; i7++) {
              for (let i8 = 0; i8 < p; i8++) {
                for (let i9 = 0; i9 < o; i9++) {
                  for (let i10 = 0; i10 < n; i10++) {
                    map[i1][i2][i3][i4][i5][i6][i7][i8][i9][i10] =
                      arr[arr_index++];
                    map[i1][i2][i3][i4][i5][i6][i7][i8][i9][i10].forEach(
                      (v, i) => {
                        if (v === 1) {
                          indexes.push([
                            i1,
                            i2,
                            i3,
                            i4,
                            i5,
                            i6,
                            i7,
                            i8,
                            i9,
                            i10,
                            i,
                          ]);
                        }
                        if (v === 0) {
                          cnt_0++;
                        }
                      }
                    );
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

const directions = [
  [1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [-1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, -1, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, -1, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, -1, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, -1, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, -1, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, -1, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, -1, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, -1, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -1],
];

let max_day = 0;
const bfs = (start_indexes) => {
  const queue = new Queue();
  start_indexes.forEach((index) => queue.push([...index]));
  while (queue.length > 0) {
    let [i1, i2, i3, i4, i5, i6, i7, i8, i9, i10, i11] = queue.pop();
    directions.forEach(
      ([di1, di2, di3, di4, di5, di6, di7, di8, di9, di10, di11]) => {
        let ni1 = i1 + di1;
        let ni2 = i2 + di2;
        let ni3 = i3 + di3;
        let ni4 = i4 + di4;
        let ni5 = i5 + di5;
        let ni6 = i6 + di6;
        let ni7 = i7 + di7;
        let ni8 = i8 + di8;
        let ni9 = i9 + di9;
        let ni10 = i10 + di10;
        let ni11 = i11 + di11;

        if (
          ni1 >= 0 &&
          ni2 >= 0 &&
          ni3 >= 0 &&
          ni4 >= 0 &&
          ni5 >= 0 &&
          ni6 >= 0 &&
          ni7 >= 0 &&
          ni8 >= 0 &&
          ni9 >= 0 &&
          ni10 >= 0 &&
          ni11 >= 0 &&
          ni1 < w &&
          ni2 < v &&
          ni3 < u &&
          ni4 < t &&
          ni5 < s &&
          ni6 < r &&
          ni7 < q &&
          ni8 < p &&
          ni9 < o &&
          ni10 < n &&
          ni11 < m &&
          map[ni1][ni2][ni3][ni4][ni5][ni6][ni7][ni8][ni9][ni10][ni11] === 0
        ) {
          map[ni1][ni2][ni3][ni4][ni5][ni6][ni7][ni8][ni9][ni10][ni11] =
            map[i1][i2][i3][i4][i5][i6][i7][i8][i9][i10][i11] + 1;
          if (
            map[ni1][ni2][ni3][ni4][ni5][ni6][ni7][ni8][ni9][ni10][ni11] > 0
          ) {
            max_day =
              map[ni1][ni2][ni3][ni4][ni5][ni6][ni7][ni8][ni9][ni10][ni11];
          }
          queue.push([ni1, ni2, ni3, ni4, ni5, ni6, ni7, ni8, ni9, ni10, ni11]);
          cnt_0--;
        }
      }
    );
  }
};

bfs(indexes);

if (max_day === 0) {
  max_day = 1;
}

console.log(cnt_0 > 0 ? -1 : max_day - 1);