1. DFS란?

정의

DFS는 “갈 수 있을 때까지 끝까지 탐색하는 방식”이다.

다음과 같은 구조를 생각해보자:

내 방 → 거실 → 부엌
        ↓
       화장실

탐색 순서:

1. 내 방 → 거실
2. 거실 → 부엌 (끝까지 이동)
3. 더 갈 곳이 없으면 되돌아감
4. 화장실 탐색

핵심:

끝까지 간다 → 막히면 돌아온다 → 다른 길 탐색

2. DFS 기본 구조

function dfs(node) {
    visited[node] = true;

    for (연결된 노드들) {
        if (아직 방문 안했으면) {
            dfs(다음 노드);
        }
    }
}

3. 재귀란?

정의

재귀는 함수가 자기 자신을 다시 호출하는 방식이다.

4. 재귀 예시

잘못된 경우 (무한 호출)

function f() {
    f();
}

올바른 경우 (종료 조건 존재)

function countDown(n) {
    if (n === 0) return;

    console.log(n);
    countDown(n - 1);
}

실행 흐름:

countDown(3)
→ 3 출력
→ countDown(2)
    → 2 출력
    → countDown(1)
        → 1 출력
        → countDown(0)
            → 종료

5. DFS와 재귀의 관계

DFS는 재귀를 사용해 구현하는 경우가 많다.

function dfs(node) {
    visited[node] = true;

    for (let i = 0; i < n; i++) {
        if (연결 && 방문 안함) {
            dfs(i);
        }
    }
}

의미:

• 현재 노드를 방문
• 연결된 노드 중 방문하지 않은 곳으로 이동
• 그 노드에서도 같은 작업 반복

6. 동작 과정

그래프:

0 — 1 — 2

실행:

dfs(0)
 → dfs(1)
   → dfs(2)
     → 종료
   → 복귀
 → 복귀

7. 단계별 흐름

1. dfs(0) 0 방문, 1로 이동

2. dfs(1) 1 방문, 2로 이동

3. dfs(2) 2 방문, 더 이상 이동 불가 → 종료

복귀:

dfs(2) → dfs(1) → dfs(0)

8. 핵심 요소

1. 방문 처리

visited[node] = true;

2. 탐색 조건

if (연결 && !visited)

3. 재귀 호출

dfs(next);

9. 정리

• DFS는 깊이 우선 탐색 방식이다.
• 재귀는 DFS를 구현하는 대표적인 방법이다.
• 탐색은 “끝까지 진행 → 막히면 복귀” 구조로 동작한다.

한 줄 요약

DFS는 갈 수 있는 곳까지 계속 들어가는 재귀 기반 탐색이다.

WSL Ubuntu에서 잘 되던 프로젝트를 Windows로 옮겼더니 SCSS 빌드 에러가 발생했다. 삽질 끝에 알고 보니 내 코드 잘못이 아닌 Vercel 측 공식 버그였다.

발생 환경

• Next.js: 16.0.7 (Turbopack)
• sass: ^1.93.3
• OS: Windows (WSL Ubuntu에서 이전)

에러 증상

yarn dev 실행 후 localhost:3000에서 다음과 같은 빌드 에러 발생:

./src/app/(main)/page.module.scss
Error evaluating Node.js code
Error: Can't find stylesheet to import.
  ╷
3 │ @forward './utils';
  │ ^^^^^^^^^^^^^^^^^^
  ╵
  src\shared\styles\mixins\index.scss 3:1  @use
  src\app\(main)\page.module.scss 1:1      root stylesheet

SCSS 파일 구조는 다음과 같았다.

src/shared/styles/mixins/
├── index.scss   ← @forward './utils' 등을 통합
├── _utils.scss
├── _flex.scss
├── _size.scss
├── _spacing.scss
└── _font.scss

// mixins/index.scss
@forward './utils';
@forward './flex';
@forward './size';
@forward './spacing';
@forward './font';

삽질 과정

1. alias 경로 오타 발견

next.config.ts를 확인하니 alias 경로가 틀려 있었음

// ❌ 잘못된 경로
turbopack: {
  resolveAlias: {
    '@styles': path.join(__dirname, 'src/styles'), // 존재하지 않는 경로
  },
},

실제 파일은 src/shared/styles에 있었으므로 수정

// ✅ 수정된 경로
turbopack: {
  resolveAlias: {
    '@styles': path.join(__dirname, 'src/shared/styles'),
  },
},

그래도 에러는 계속됐다. 그리고 그러면 왜 wsl에서는 문제가 없었던거니??

2. sassOptions.includePaths 추가 시도

sassOptions: {
  includePaths: [path.join(__dirname, 'src/shared/styles')],
},

효과 없음...

3. sass importer 추가 시도 (findFileUrl)

sassOptions: {
  importers: [{
    findFileUrl(url: string) {
      if (!url.startsWith('@shared')) return null;
      return new URL('file:///' + path.join(__dirname, 'src', url.replace('@', '')));
    },
  }],
},

새로운 에러 발생;;

Error: An importer must have either canonicalize and load methods, or a findFileUrl method.

Turbopack은 findFileUrl 방식의 importer를 지원하지 않는다.

4. canonicalize + load 방식으로 변경 시도

sassOptions: {
  importers: [{
    canonicalize(url: string) { ... },
    load(canonicalUrl: URL) { ... },
  }],
},

역시 동작하지 않았다.

이외에도 스타일시트를 import하는 경로 전부를 상대경로 및 절대경로 방식으로 바꿨다가... 이것도 제대로 안 먹혀서 싹 되돌렸다.

찾아낸 원인

핵심 원인은 Next.js 16 Turbopack의 Windows SCSS 경로 처리 버그였다.

이는 Vercel 공식 GitHub 이슈로 등록된 버그다. 내 코드 잘못이 아니다! ㅜㅜ

그리고 sassOptions가 동작하지 않은 이유도 따로 있었다.

Turbopack은 Rust 기반 아키텍처라 sassOptions로 전달되는 JavaScript 함수를 직접 실행할 수 없다고 한다. findFileUrl, canonicalize, load 등 모든 JavaScript importer 방식이 Turbopack에서는 동작하지 않는다.

해결 방법

로컬 개발 (Windows): --webpack 플래그 사용

// package.json
{
  "scripts": {
    "dev": "next dev --webpack",
    "build": "next build"
  }
}

• dev는 Webpack으로 실행 → SCSS alias 정상 동작
• build는 Turbopack 유지 → 배포 시 그대로 사용

배포 (Vercel): 그대로 사용

Vercel 배포 서버는 Linux이므로 Turbopack + SCSS alias가 정상 동작한다. next build에 별도 설정이 필요 없다.

정리

Vercel이 Windows 경로 버그를 픽스하면 package.json에서 --webpack 플래그만 제거하면 된다.

참고

• Next.js GitHub Issue #87243

• DFS (Depth First Search)
• BFS (Breadth First Search)

처음 보면 두 알고리즘은

• directions 배열 사용
• 방문 체크
• 격자 이동

등의 같은 구조를 사용해서 거의 동일해 보여도 탐색 방식과 사용 목적은 완전히 다르다. 자꾸 헷갈리는 부분이 있어서 잊어버리지 않도록 정리하기로 했다!!

1. DFS와 BFS의 차이
2. 미로 문제에서 BFS를 사용하는 이유
3. BFS 미로 최단거리 코드
4. DFS로 최단거리를 구하지 않는 이유

1. DFS vs BFS 차이

DFS (Depth First Search)

DFS는 한 방향으로 끝까지 탐색한다.

예시

S → A → B → C → D

막히면 다시 돌아와서 다른 길을 탐색한다. 이를 백트래킹(backtracking)이라 한다!!

특징

• 깊이 우선 탐색
• 일반적으로 재귀 사용
• 모든 경로 탐색에 적합
• 백트래킹 문제에 많이 사용

대표 문제

• 모든 경로 찾기
• 순열 / 조합
• 백트래킹
• 섬의 개수

BFS (Breadth First Search)

BFS는 가까운 것부터 탐색한다.

탐색 방식

거리 0
S

거리 1
A B

거리 2
C D E

중심에서 바깥으로 퍼져나가는 구조!!

특징

• 너비 우선 탐색
• Queue 사용
• 최단거리 문제에 적합

대표 문제

• 미로 최단거리
• 바이러스 퍼짐
• 최소 이동 횟수
• 토마토 문제 (BOJ 7576)

2. 왜 미로 최단거리는 BFS인가

미로 문제의 목표는 보통 출발점 → 도착점 최단거리 구하기이다.

DFS는 먼 길을 먼저 발견할 수도 있다.

S → A → B → C → D → E 라는 경로를 탐색했을 때, 거리는 5

하지만 실제 최단 경로 S → X → E가 존재하고, 그 거리는 2

DFS는 모든 경로를 탐색해야만 최단거리를 알 수 있다.

반면 BFS는 거리가 가장 가까운 순서대로 탐색하는 방식이다.

그래서 처음 도착한 경로 = 항상 최단거리가 보장된다!!

3. BFS 미로 최단거리 코드

미로 예시

1 = 길
0 = 벽

BFS 코드

function solution(maps){

    // 미로의 세로 길이 (행 개수)
    const n = maps.length;

    // 미로의 가로 길이 (열 개수)
    const m = maps[0].length;

    // 상하좌우 이동을 위한 방향 배열
    // [dx, dy] 형태로 이동 방향을 표현
    const directions = [[0,1],[0,-1],[1,0],[-1,0]];

    // BFS 탐색에 사용할 큐
    // [x, y, dist] : 현재 위치와 시작점에서부터의 이동 거리
    const queue = [[0,0,1]];

    // 방문 여부를 기록하는 2차원 배열 생성
    // 처음에는 모든 칸이 false (방문 안함)
    const visited = Array.from({length:n},()=>Array(m).fill(false));

    // 시작 위치 (0,0)은 이미 방문했으므로 true로 표시
    visited[0][0] = true;

    // queue에서 꺼낼 위치를 가리키는 포인터
    // shift() 대신 사용하여 시간복잡도 증가를 방지
    let head = 0;

    // 큐에 탐색할 위치가 남아있는 동안 계속 BFS 탐색
    while(head < queue.length){

        // 현재 탐색할 위치를 큐에서 꺼냄
        // queue[head]를 읽은 뒤 head를 증가시키는 후위 증가 연산
        const [x,y,dist] = queue[head++];

        // 현재 위치가 목표 위치라면
        // 지금까지 이동한 거리 dist를 반환
        if(x === n-1 && y === m-1) return dist;

        // 현재 위치에서 상하좌우 4방향 탐색
        for(const [dx,dy] of directions){

            // 다음에 이동할 위치 계산
            const nx = x + dx;
            const ny = y + dy;

            // 다음 위치가
            // 1️⃣ 미로 범위 안에 있고
            // 2️⃣ 길(1)이며
            // 3️⃣ 아직 방문하지 않았다면
            if(
                nx >= 0 &&
                ny >= 0 &&
                nx < n &&
                ny < m &&
                maps[nx][ny] === 1 &&
                !visited[nx][ny]
            ){
                // 해당 위치를 방문 처리
                visited[nx][ny] = true;

                // 다음 탐색 위치로 큐에 추가
                // 거리는 한 칸 이동했으므로 +1
                queue.push([nx,ny,dist+1]);
            }
        }
    }

    // BFS 탐색이 끝날 때까지 목표 지점에 도달하지 못했다면
    // 갈 수 없는 경우이므로 -1 반환
    return -1;
}

코드 흐름을 정리해보면...

1. 시작점을 queue에 넣기
2. 시작점을 visited 처리
3. queue에서 하나 꺼냄
4. 꺼낸 위치가 목표 지점이라면 거리 반환
5. 상하좌우 탐색
6. 갈 수 있고 방문하지 않았다면 → 꺼낸 위치 visited 처리 → 갈 수 있는 위치 queue에 추가
7. queue가 빌 때까지 반복
8. 끝까지 못 찾으면 -1 반환

4. DFS로 최단거리를 구하지 않는 이유

모든 경로를 탐색하고 각 경로의 길이를 기록한 뒤 가장 짧은 경로 선택하는 방식으로 이론적으로는 가능하다. 하지만 DFS는 가능한 경로의 수가 많아질수록 탐색량이 기하급수적으로 증가한다는 단점이 있다. 반면 BFS는 시작점에서 가까운 위치부터 탐색을 진행하기 때문에 도착점을 처음 발견하는 순간 그 경로가 최단거리가 된다. 또한 각 칸을 한 번씩만 방문하므로 시간복잡도는 O(n × m) 수준이다. 따라서 100 * 100 = 10,000번의 탐색만으로 최단거리를 구할 수 있어 BFS가 훨씬 효율적이다.

코딩테스트 알고리즘 선택 기준

정수 l과 r이 주어졌을 때, l 이상 r이하의 정수 중에서 숫자 "0"과 "5"로만 이루어진 모든 정수를 오름차순으로 저장한 배열을 return 하는 solution 함수를 완성해 주세요.

만약 그러한 정수가 없다면, -1이 담긴 배열을 return 합니다.

제한사항

1 ≤ l ≤ r ≤ 1,000,000

예시

l = 5 r = 55 → 5, 50, 55

조건을 만족하는 수가 없다면 -1을 반환합니다.

나의 시도 : 완전 탐색

처음엔 범위 내 모든 숫자를 문자열로 변환 후 정규식을 통해 검사하여 걸러냄

function solution(l, r) {
  const result = [];
  for (let i = l; i <= r; i++) {
    const str = i.toString();
    if (/^[05]+$/.test(str)) result.push(i);
  }
  return result.length ? result : [-1];
}

통과!! 그러나 비효율적... r이 커질수록 반복 횟수가 폭증

다른 풀이 참고 : 이진수 패턴으로 생각하기

조건에 맞는 수를 하나씩 검사하는 것 대신, 조건에 맞는 수를 직접 생성하는 방식?

아예 처음부터 가능한 경우의 수만 만들기. 즉, 0과 5의 조합으로 만들어지는 숫자만 고려 → 불필요한 탐색이 없음

문제의 핵심은 모든 자릿수가 0 또는 5로만 구성되어야 한다는 것 0과 5만 사용하는 수 = 이진수의 0과 1을 0과 5로 치환한 형태

십진수| 이진수 | 변환 후 | | :-: | :--: | :-: | | 1 | 1 | 5 | | 2 | 10 | 50 | | 3 | 11 | 55 | | 4 | 100 | 500 | | 5 | 101 | 505 |

즉, 이진수의 1 → 5로 바꾸면 우리가 찾는 0과 5로만 이루어진 수가 됨!!

최종 풀이 코드

function solution(l, r) {
  const result = [];

  // i를 1부터 시작해 가능한 모든 '0과 5로만 이루어진 수'를 생성
  for (let i = 1; ; i++) {
    // 1. i를 이진수로 변환
    // 2. 1 → 5로 치환
    const num = parseInt(i.toString(2).replace(/1/g, '5'), 10);

    // r 초과 시 탐색 종료
    if (num > r) break;

    // l 이상이면 결과에 추가
    if (num >= l) result.push(num);
  }

  return result.length ? result : [-1];
}

동작 예시

결과: [5, 50, 55]

시간 복잡도

이진수 길이에 따라 반복되므로 O(log r) 정도로 매우 효율적 r이 커져도 빠르게 종료됩니다

알게 된 점

조건을 검사하는 것보다 패턴을 생성하는 것이 더 효율적일 때가 있음.

0과 5 제약은 곧 이진수 패턴과 1:1로 대응.

toString(2)을 통한 이진수 변환은 코테에서 매우 유용한 도구가 될지도...

클래스 컴포넌트를 사용하지 않고도 상태와 라이프사이클 메서드 활용 가능 Hooks 자체는 디자인 패턴이라고 할 수 없으나 많은 전통적 디자인 패턴 대체 가능

1. 클래스 컴포넌트의 한계

• 클래스 컴포넌트의 특징

  • 생성자 함수에서 상태 관리
  • componentDidMount, componentWillUnmount 등 라이프사이클 메서드 사용
  • 커스텀 메서드로 로직 추가

• 하지만 함수형 컴포넌트를 클래스 컴포넌트로 리팩토링할 경우?

  • 클래스 문법에 대한 이해가 필요함
  • 데이터 흐름을 깨지 않고 변환하기 어렵고 복잡함

2. 구조 변경의 어려움

• 여러 컴포넌트 간 코드 공유는 보통 다음 두 패턴 사용

  • 고차 컴포넌트(컴포넌트를 인자로 받아 새로운 컴포넌트를 반환하는 함수)
  • 렌더 Props 패턴

• 하지만 이런 패턴을 적용하거나 변경하려면?

  • 전체 애플리케이션 구조를 변경해야 할 수 있음
  • 컴포넌트가 클수록 구조 변경이 어려움
  • 컴포넌트 중첩이 심화되어 “Wrapper Hell” 발생 가능 → 데이터 흐름이 복잡해지고 디버깅이 어려워짐

3. 복잡성 증가

• 클래스 컴포넌트에 로직이 많아질수록?

  • 파일 크기와 복잡도가 빠르게 증가함
  • 로직이 얽혀 구조화되지 않음
  • 특정 로직이 어디서 쓰이는지 파악이 어려움
  • 디버깅과 성능 최적화 어려움
  • 라이프사이클 메서드 간 코드 중복 발생

4. Hooks의 등장

• 위 문제를 해결하기 위해 React 16.8부터 Hooks 도입

• 리액트 훅을 사용하면?

  • 함수형 컴포넌트에서도 상태 관리 가능 (useState)
  • 라이프사이클 관리 가능 (useEffect)
  • 여러 컴포넌트 간 상태 관련 로직의 재사용 용이

상태 Hook

1. 상태 Hook: useState

• 함수형 컴포넌트에서 상태(state)를 관리할 수 있게 해주는 Hook
• 사용 전 import { useState } from 'react'로 리액트에서 불러와야 함
• useState는 초기 상태값(initial state) 을 인자로 받음
• 반환값은 배열 형태로 두 가지를 제공
  • const [state, setState] = useState(initialValue);
  • state: 현재 상태 값 → 클래스 컴포넌트의 this.state.value와 유사
  • setState: 상태를 업데이트하는 함수 → this.setState()와 유사

2. 이펙트 Hook: useEffect

• useEffect는 컴포넌트의 라이프사이클 메서드를 대체할 수 있는 Hook
• componentDidMount, componentDidUpdate, componentWillUnmount를 하나로 통합하여 처리할 수 있음

3. 커스텀 Hook

• use로 시작하는 이름으로 함수 작성 (리액트가 규칙 준수 여부 판단)
• 공통 로직을 추출해 재사용 가능
• 직접 작성 가능하며, 외부에서 공유된 Hook도 설치해 사용 가능

주요 기본 Hook

useState

• 함수형 컴포넌트에서도 상태 관리 가능
• const [state, setState] = useState(initialValue) 형태

useEffect

• 렌더링 이후 실행되는 부수 효과 처리
• 타이머, API 호출, 이벤트 등록 등
• 클래스의 componentDidMount, componentDidUpdate, componentWillUnmount 대체

useContext

• Context API 상태를 쉽게 사용
• props drilling 없이 전역 상태 접근 가능
• context 객체를 인자로 받음

useReducer

• 복잡한 상태 로직, 상태 간 의존 관계 처리에 적합
• const [state, dispatch] = useReducer(reducer, initialState)
• 트리 깊은 구조에서의 성능 최적화에 효과적

Hook의 장단점

관심사 기반 코드 구성

• 라이프사이클이 아닌 기능 단위로 코드 정리 → 가독성 향상

클래스 불필요

• JS 클래스 관리 어려움 해결
• 핫 리로딩 호환, 함수형 프로그래밍 용이

복잡한 로직 추출 가능

• 고차 컴포넌트, render props 없이도 상태 로직 공유 가능
• 테스트 및 재사용 쉬운 순수 함수로 구성 가능

규칙 엄수 필요

• 컴포넌트의 최상위에서만 호출 (조건문/반복문 내 사용 금지)
• use로 시작할 것 : Linter(ESLint + React Hooks plugin)로 규칙 위반 감지 가능

학습 곡선 존재

• useEffect, useCallback, useMemo는 잘못 사용 시 성능 문제 유발