Graph 란?

그래프는 정점(Vertex, 또는 노드(Node)라고도 함)과 이들을 연결하는 간선(Edge)로 구성된 비선형 자료구조

Graph 용어 정리

간략한 그래프 용어 정리

예시

• 정점 : 장소
• 간선 : 길
• 가중치 : 거리/요금

Graph의 특징

• 방향성 : 방향(Directed) / 무방향(Undirected)
• 사이클 유무 : 사이클(Cyclic) / 비사이클(Acyclic)
• 가중치 유무 : 가중치(Weighted) / 무가중치(Unweighted)
• 간선의 밀도 : 밀집(Dense) / 희소(Sparse)

Graph 구현 방법

그래프를 표현하는 대표적인 방식은 아래 두 가지입니다.

1. 인접 행렬 (Adjacency matrix)

관계를 2차원 배열로 표현

• 노드간 연결 여부를 빠르게 확인 가능
• 모든 노드의 관계를 행렬로 저장하므로 메모리 소비 큼

2. 인접 리스트 (Adjacency List)

관계를 링크드 리스트로 표현

• 배열 방에 노드를 나열, 연결되는 노드를 링크드 리스트로 쭉 나열
• 메모리 효율적, 연결된 정점 탐색에 유리

💡 언제 무엇을 사용할까? 간선(Edge)이 많은 밀집 그래프 → 인접 행렬(Adjacency matrix) 간선(Edge)이 적은 희소 그래프 → 인접 리스트(Adjacency List)

Graph 탐색 알고리즘

대표적인 그래프 알고리즘 3가지

• 그래프 탐색 : DFS , BFS
• 최단 경로 : Dijkstra

📌 DFS(Depth-First Search, 깊이 우선 탐색)

가능한 깊게 탐색한 후, 더 이상 갈 곳이 없으면 이전 정점으로 되돌아가는 방식 다른 경로로 넘어가기전 해당 분기를 완벽하게 탐색 ⇒ 세로 탐색

• 주로 스택(Stack) 또는 재귀 함수로 구현

✅ 장점

• 현 경로상의 노드만 기억 ⇒ 메모리 효율 좋음
• 목표 노드가 깊은 위치에 있는 경우, 빠르게 도달 가능

❌ 단점

• 해가 없는 경로를 깊이 탐색할 수 있어 비효율적
• 최단 경로를 보장하지 않음
• 깊이가 깊으면 스택 오버플로우 위험
  • ⚠️ 깊이 제한 두는 방법으로 해결할 수 있음

📌 BFS(Breadth-First Search, 너비 우선 탐색)

한 노드에서 시작해 인접한 노드부터 모두 탐색하고 이후 그 인접한 노드의 인접한 노드 반복… ⇒ 가로 탐색

• 주로 큐(Queue) 사용해 구현

✅ 장점

• 최단 경로 탐색에 유리(특히 무가중치 그래프)
• 경로가 무한히 깊어져도 반드시 해를 찾을 수 있음
• 노드 수가 적고 깊이가 앝은 해가 존재할 때 유리

❌ 단점

• 탐색을 위한 큐 사용 → 메모리 사용량 증가

DFS vs BFS

DFS와 BFS의 시간 복잡도

• 인접 리스트 : O(N + E)
• 인접 행렬 : O(N^2)

N: 노드의 개수, E: 간선의 개수 → 일반적으로 인접 리스트 방식이 더 효율적

두 방식 모두 조건 내의 모든 노드를 검색한다는 점에서 시간 복잡도는 동일 BUT 일반적으로 DFS를 재귀 함수로 구현한다는 점에서 DFS보다 BFS가 조금 더 빠르게 동작함

📌 Dijkstra 알고리즘 (최단 경로 알고리즘)

그래프에서 한 노드에서 다른 모든 노드까지의 최단 경로를 구하는 알고리즘 → 매번 최단 경로의 정점을 선택해 탐색을 반복하는 것

• 우선순위 큐 (Heap) 활용 : (O(E log V))
• BFS + DP 개념으로 이해하면 편함

✅ 장점

• 거리뿐만 아니라 실제 경로 추적도 쉽게 구현 가능
• 가중치가 있는 그래프에서 안정적인 최단 경로 탐색이 가능

❌ 단점

• 간선(Edge)이 많은 대규모 그래프에서 큐 연산이 많아져 속도가 느려질 수 있음
• 그래프와 거리 정보를 저장해야 하므로 메모리 사용량이 많음
• 단일 최단 경로만 제공, 동일 거리의 경로가 여러 개 있어도 전부 찾지는 않음

실제 활용 사례

• SNS 친구 추천 → 그래프 탐색
• 지도앱 길찾기 → 다익스트라(Dijkstra)
• 게임 맵 탐색, AI 이동 경로 계산 → DFS / BFS

Graph 알고리즘 선택 가이드

Reference

• Youtube - [자료구조 알고리즘] 그래프(Graph)에 대해서
• Intro To The Graph Data Structure
• Graph Data Structures and Databases
• Basic Properties of a Graph
• 그래프 알고리즘 종류와 활용 방법
• [그래프] 인접 행렬과 인접 리스트

🗝️ 비밀번호를 맞추는 가장 확실한 방법

비밀번호가 4자리 숫자일 때, 단서가 전혀 없다면 어떻게 풀어야 할까요? 0000부터 9999까지 전부 입력해보는 수밖에 없습니다.

이런 식으로 모든 경우의 수를 전부 시도하는 전략을 → 브루트 포스(Brute Force) 혹은 완전 탐색이라고 합니다.

📌 브루트 포스(Brute Force)란?

// 0000 ~ 9999까지 모든 경우 탐색
for (let i = 0; i < 10000; i++) {
  if (check(i)) {  // 어떤 조건을 만족하면
    console.log(`정답: ${i}`);
    break;
  }
}

브루트 포스(Brute Force, 완전 탐색)는 가능한 모든 경우의 수를 탐색하여 조건을 만족하는 결과를 찾아내는 문제해결 패러다임입니다.

💡 Brute: 단순히, 순전히 / Force: 힘
→ 즉, 무식한 힘으로 가능한 모든 경우를 탐색하는 방법

브루트 포스를 쓰는 이유

✅ 장점

• 구현이 상대적으로 단순하고 직관적
• 정답이 존재하는 경우 반드시 찾게 됨
• 복잡한 조건이 있어도 적용 가능

❌ 단점

• 시간 복잡도에 매우 민감
• 입력 크기가 커질수록 실행 시간 급격히 증가
• 메모리 사용량이 클 수 있음

⚠️ N = 20인 경우 가능한 경우의 수는 약 100만개(2²⁰)가 되어버림

브루트 포스의 사용 조건

1. 문제의 정답 조건이 명확해야 함 : 어떤 상태가 정답인지 판별할 수 있어야 함
2. 가능한 경우의 수가 제한적이어야 함 : 솔루션의 수가 무한하거나 너무 크면 비효율적

✅ 언제 사용하면 좋을까?

1. 입력 범위가 작은 경우

   • N ≤ 20인 경우: 2^N ≈ 100만개 정도
   • N ≤ 10인 경우: N! ≈ 300만개 정도

2. 다른 알고리즘으로 해결하기 어려운 경우

   • 복잡한 조건이 많아 수학적 공식화가 어려운 경우
   • 문제의 패턴을 찾기 어려운 경우

3. 확실한 정답이 필요한 경우

   • 근사해가 아닌 정확한 답이 필요할 때

완전 탐색의 구현 방식

DFS, BFS, 백트래킹은 추후 자세히 설명

문제 해결 예시

1. 반복문 활용 - Two Sum

🔗 Leetcode - Two Sum

배열 nums와 목표값 target이 주어졌을 때, 두 수의 합이 target과 같아지는 두 원소의 인덱스를 반환

예제 : nums = [2,7,11,15], target = 9 → [0,1] (nums[0] + nums[1] = 2 + 7 = 9)

// 시간 복잡도 : O(N^2)
var twoSum = function(nums, target) {
    const n = nums.length;
    for(let i=0; i<n-1; i++){
        for(let j=i+1; j<n; j++){
            if(nums[i]+nums[j]===target) return [i,j]
        }
    }
   return []
};

모든 두 숫자 조합을 검사 → 시간복잡도 O(N²) 정확하지만 느릴 수 있음

재귀 활용 - 부분수열의 합

🔗 백준 - 부분수열의 합

N개의 정수로 이루어진 수열이 있을 때, 크기가 양수인 부분수열 중에서 그 수열의 원소를 다 더한 값이 S가 되는 경우의 수를 반환

function solution(N,S,arr) {
  let count = 0;

  function dfs(index,sum){
    if(index === N){
      if(sum === S){
        count++;
      }
      return;
    }

    dfs(index + 1, sum + arr[index]); // 포함
    dfs(index + 1, sum);              // 비포함
  }
  dfs(0,0);

  // 크기가 양수인 부분 수열만 인정
  if (S === 0) count--;
  return count;
}

원소마다 포함/비포함(2가지 선택) 시간복잡도: O(2ⁿ)

마무리 요약

브루트 포스는 모든 경우의 수를 하나하나 다 시도해보는 방법입니다. 경우의 수가 적고, 무조건 정답을 찾고 싶을 때 강력한 전략이 됩니다.

브루트 포스만으로 풀 수 있는 문제는 드물지만, 어떤 문제든 '부분적 완전 탐색'이 필요한 경우는 매우 많습니다.

개인적으로 브루트 포스, 완전 탐색이라는 두 단어가 완전히 일치한 용어인가? 라는 질문이 들어서 시간이 걸렸던거 같습니다.

엄밀히 구분하는 일부 자료에서는 다음과 같이 의미상의 미세한 차이를 언급합니다.

하지만 실전에서는 두 용어를 구별해서 쓸 필요는 거의 없고, 동의어로 여겨진다고 합니다.

Reference

• Youtube - 브루트 포스 완전 탐색 알고리즘 3분만에 이해하기
• 전체탐색 : 브루트포스 알고리즘 (Brute Force Algorithm)
• 알고리즘: 선형/비선형 구조와 브루트포스
• [알고리즘 공부] 완전탐색기법 - 비트마스크, 순열 ,재귀

알고리즘 문제 풀이 스터디를 하며 만든 자료입니다. 개인 공부 기록용으로 올립니다.

DP(Dynamic Programming)이란?

Dynamic Programming(동적 계획법)은 하나의 큰 문제를 여러 개의 작은 문제로 나누어서, 그 결과를 저장하여 다시 큰 문제를 해결할 때 사용하는 문제해결 패러다임입니다.

❓ 왜 DP가 필요할까?

완전탐색, DFS, BFS로 해결할 수 있지만 경우의 수가 너무 많아 속도가 느려지는 문제들을 효율적으로 해결하기 위해 등장했습니다.

💡 한 교수는 DP를 "기억하기 알고리즘"이라고 번역하기도 했습니다.

DP의 원리와 조건

📌 핵심 원리

• 메모리를 사용해서 중복 연산을 줄이고, 중복 연산을 줄여서 수행 속도를 개선
  • 메모리 사용 : 배열 or 자료구조를 만든다.
  • 중복 제거 : 연산 결과를 배열에 담는다. 같은 연산을 또 하지 않음
  • 재사용: 겹치는 서브 문제는 한 번만 계산하고 결과를 재사용

DP의 사용 조건

1. 최적 부분 구조 (Optimal Substructure)

   • 큰 문제의 최적해가 작은 문제들의 최적해로 구성됨

2. 중복 부분 문제 (Overlapping Subproblems)

   • 같은 작은 문제들이 반복적으로 계산됨

DP 사용 시점 판별법

✅ DP를 사용해야 하는 경우

1. DFS/BFS로 풀 수 있지만 경우의 수가 너무 많은 문제

   • 일반적으로 DFS/BFS로 처리 가능한 경우의 수: 약 500만개
   • 그 이상이면 DP 고려

2. 중복적인 연산이 많이 발생하는 경우

   • 같은 하위 문제가 여러 번 계산됨
   • 최적값을 구하는 과정에서 불필요한 계산 반복

주요 문제 유형

• 최적화 문제: 최대값, 최소값을 구하는 문제
• 경우의 수: 가능한 방법의 수를 구하는 문제
• 경로 탐색: 최단 경로, 최적 경로 문제

예시: 가장 빨리 도착하는 경로의 소요 시간, 주식 매매 최적 타이밍

💡 DP 문제 해결의 핵심 질문

"어떻게 해야 뒤로 돌아가지 않을 수 있을까?"

구현 방식 : Top-Down vs Bottom-Up

⬇️ Top-Down (Memoization)

큰 문제를 해결하기 위해, 재귀적으로 작은 문제를 호출하며 해결

• dp[n] 같은 목표상태에서 출발
• 필요한 하위 문제를 재귀적으로 호출
• 이미 계산된 값은 메모리에 저장되 있던 내역 꺼내서 활용해 중복 계산 방지

→ 큰 문제에서 작은 문제로(top-down) 내려가며 해결하는 방식

⚠️ 주의사항: 함수 호출이 많아지면 호출 오버헤드, 스택 오버플로우 위험 있음

⬆️ Bottom-Up (Tabulation)

작은 규모의 문제부터 시작해 전체 큰 문제를 해결

• dp[0] 같은 베이스부터 출발
• 반복문을 사용해 테이블을 채워나가는(table-filling) 방식
• 모든*하위 문제를 반복문으로 순차적으로 해결하면서 결과를 테이블에 저장해 중복 계산을 방지

→ 작은 문제를 해결하면서 점점 위로(bottom-up) 올라가는 방식 (주로 사용)

💡 장점: 스택 오버플로우 걱정 없음, 경우에 따라 공간 최적화 가능 ex. 직전 값만 사용하는 경우 리스트가 아닌 변수 사용

근본적인 개념으로 "결과값을 기억하고 재활용" 한다는 측면에서는 Memoization, Tabulation이 크게 다르지 않음

실전 문제 해결 예시

Top-Down 예시: Climbing Stairs

Leetcode - Climbing Stairs

정상까지 오르는데 N번의 스텝이 필요한 계단에서 한번에 한 스텝 혹은 두 스텝을 오를 수 있을때 정상까지 올라가는 방법의 수는?

문제 분석

• 한번에 한스텝 혹은 두 스텝을 오를 수 있음
• n = 6일때,이전 계단은 5층 or 4층 → 해당 값에서 시작해 계속 아래로 내려간다.
• 점화식: climb(n) = climb(n-1) + climb(n-2)

  Step 1: 일반 재귀 (비효율적)

// 시간복잡도: O(2^n) - 매우 비효율적!
function climb(n){
    if(n<=2) return n;
    return climb(n-1) + climb(n-2)
}

문제점 : 동일한 input에 대한 function call이 많은 것을 확인 할 수 있음 → 메모해 뒀다가 이후 재사용하는 방식으로 변경

Step 2: Top-Down DP (Memoization)

// 시간복잡도: O(n)
let memo = [];
function climb(n){
    if(n<=2) return n;

    // 이미 계산된 값이 있으면 바로 반환
    if (memo[n] !== undefined) 
        return memo[n];

    // 없으면 계산 후 저장
    memo[n] = climb(n-1) + climb(n-2);
    return memo[n]
}

Top-Down of DP

• recursive(재귀)
• memoization(메모리에 저장)
  • funcatioin call의 결과를 저장해서 이후에 같은 input에 대한 호출은 저장한 결과를 사용하는 것

Bottom-Up 예시: 연속합

백준 - 연속합

n개 정수 수열에서 연속된 몇 개의 수를 선택해서 구할 수 있는 합 중 가장 큰 값은? 예시: [10, -4, 3, 1, 5, 6, -35, 12, 21, -1] -> 33(12+21)

문제 분석

arr[i] 까지 왔을때, 최대인 연속 합이 나오는 2가지

1. arr[i] 자체만 선택
2. 이전까지의 최대 연속합에 arr[i] 를 더하는 경우

• 점화식: dp[i] = Math.max(arr[i], dp[i-1] + arr[i])

Step 1: 기본 DP 구현

// 시간복잡도: O(n), 공간복잡도: O(n)
function solution(N, arr) {
  const dp = Array(N).fill(0);
  dp[0] = arr[0];
  let maxSum = dp[0];

  for (let i = 1; i < N; i++) {
    dp[i] = Math.max(arr[i], dp[i - 1] + arr[i]);
    maxSum = Math.max(maxSum, dp[i]);
  }

  return maxSum;
}

잘 보면 결국 바로 직전의 값만 사용하는 것을 확인할 수 있음 → 꼭 배열 형태로 사용할 필요가 없다!

Step 2: 메모리 ㅊ최적화

dp 배열 없이 현재 상태만 저장해서 메모리 사용을 줄임

// 시간복잡도: O(n), 공간복잡도: O(1)
function solution2(N, arr) {
  let current = arr[0];
  let maxSum = arr[0];

  for (let i = 1; i < N; i++) {
    current = Math.max(arr[i], current + arr[i]);
    maxSum = Math.max(maxSum, current);
  }

  return maxSum;
}

실제 활용 사례

1. Google Maps의 경로 탐색 : 다양한 경로 중에서 최단 경로를 순차적으로 찾는 데 활용
2. 네트워크 데이터 전송 : 송신자에서 여러 수신자에게 데이터를 순차적으로 전송할 때 최적화된 경로를 찾는 데 사용
3. 문서 유사도 분석 : Google, Wikipedia, Quora 등의 검색 엔진에서 두 텍스트 문서 간의 유사성 정도를 측정하는 알고리즘에 활용
4. 맞춤법 검사 : 편집 거리(Edit Distance) 알고리즘을 사용하여 오타를 찾고 올바른 단어를 제안하는 맞춤법 검사기에서 활용
5. 데이터베이스 캐싱 시스템
6. Git 병합 (Git Merge) : 문서 비교에서 최장 공통 부분수열(LCS) 알고리즘을 사용하는 대표적인 사례
7. 유전 알고리즘 : 최적화 문제를 해결하는 유전 알고리즘의 핵심 연산에 활용

Reference

• YouTube - DP 동적계획 다이나믹 프로그래밍 알고리즘 설명 10분만에 이해하기
• YouYube - 코딩테스트에서 많이 사용되는 dynamic programming(동적 계획법)의 개념
• 알고리즘 - Dynamic Programming(동적 계획법)
• Application of dynamic programming in real world programming

1. Docker를 이용해 MySQL 컨테이너 설치하기
2. DBeaver를 통해 MySQL에 접속할 수 있도록 설정하기

개인적인 기록용으로 작성합니다.

1. Docker 컨테이너 관리 명령어

# MySQL Docker 컨테이너 중지
$ docker stop mysql-container

# MySQL Docker 컨테이너 시작
$ docker start mysql-container

# MySQL Docker 컨테이너 재시작
$ docker restart mysql-container

2. Docker 및 MySQL 설치

2-1. Docker 설치

1. Docker 공식 홈페이지에서 운영체제에 맞는 버전 설치
2. 설치 완료 후, 아래 명령어로 정상적으로 설치되었는지 확인

docker -v

2-2. MySQL Docker 이미지 다운로드

# 최신 버전 다운로드
$ docker pull mysql

# 특정 버전 다운로드 (예: 8.0 버전)
$ docker pull mysql:8.0

2-3. 다운로드한 Docker 이미지 확인

$ docker images

3. MySQL Docker 컨테이너 생성 및 실행

$ docker run --name mysql-container \
  -e MYSQL_ROOT_PASSWORD=<your-password> \
  -d -p 3306:3306 mysql:8.0

🔹 <your-password> 부분에 원하는 비밀번호를 입력하세요.

4. Docker 컨테이너 상태 확인

# 실행 중인 컨테이너 확인
$ docker ps -a

5. MySQL Docker 컨테이너 접속

# 컨테이너 내부로 접속
$ docker exec -it mysql-container bash

# MySQL 접속
$ mysql -u root -p

🔹 'Enter password:' 프롬프트가 나타나면, 앞서 설정한 비밀번호를 입력하세요.

6. MySQL 사용자 및 데이터베이스 설정

-- 새로운 사용자 생성
CREATE USER 'username'@'%' IDENTIFIED BY 'your-password';

-- 사용자에게 모든 권한 부여
GRANT ALL PRIVILEGES ON *.* TO 'username'@'%';

-- 변경 사항 적용
FLUSH PRIVILEGES;

🔹 @'%'는 외부 접속을 허용하는 설정입니다.

7. DBeaver 연결 설정

7-1. DBeaver 설치 및 MySQL 연결

1. DBeaver 공식 사이트에서 프로그램 다운로드 및 설치
2. 새로운 MySQL 연결 생성 후, 아래 정보 입력
   • Host: localhost
   • Port: 3306
   • Database: 원하는 데이터베이스 이름 (없으면 비워둠)
   • Username: 앞서 생성한 username
   • Password: 설정한 비밀번호 입력

7-2. Public Key Retrieval is not allowed 오류 해결

1. Driver Properties 탭 이동
2. allowPublicKeyRetrieval 옵션을 true로 설정

🔗 참고 자료

• PoiemaWeb - Docker MySQL
• Docker로 MySQL 설치하기 (MySQL 5.7) - Mac M1
• MySQL 도커 컨테이너 설치 후 DBeaver 연결하기

1. 문제 상황

저희 애플리케이션은 다음과 같이 각 기능마다 다른 권한을 요구합니다.

• 매니저만 공지사항 등록 가능
• 커뮤니티 유저만 커뮤니티 게시글 등록 가능
• 일반 유저가 볼 수 있는 라이브 방송 기능 제공

이처럼 기능별로 권한이 다르기 때문에, 요청마다 권한을 검증하는 과정이 필요했습니다.

기존 문제점

1. 권한 검사 로직 중복
   • 서비스 레이어에서 개별적으로 검사하여 코드 중복 발생
2. 보안 취약점
   • 서비스 레이어까지 불필요한 요청이 도달하여 민감한 데이터 접근 가능
3. 불필요한 리소스 소비
   • 권한이 없는 요청도 내부 로직 실행 → 성능 저하 유발
4. 권한 관리의 일관성 부족
   • 일부는 Guard, 일부는 서비스에서 검사하여 유지보수 어려움
5. 확장성과 유지보수성 저하
   • 권한 정책 변경 시 여러 서비스 코드 수정 필요

처음에는 일반 유저만 가드를 적용하고, 커뮤니티 유저와 관련된 권한은 서비스 레이어에서 검사했습니다. 그러나 이 방식은 코드 중복을 유발했고, 권한이 없는 사용자가 서비스 로직까지 도달하여 보안 이슈가 발생할 가능성이 있었습니다.

2. 해결 방법: Guard 적용

이러한 문제를 해결하기 위해 NestJS의 Guard 기능을 활용했습니다. Guard는 NestJS에서 제공하는 공식적인 인증 및 권한 관리 기능이고, AuthGuard와 함께 사용하면 사용자 인증을 쉽게 처리할 수 있다고 생각했습니다.

✅ Guard 적용 예상 결과 & 결론

1. 중복된 권한 검사 로직 제거
   • Guard에서 권한 검사를 수행 → 서비스 레이어는 비즈니스 로직에만 집중 가능
2. 보안 강화 및 불필요한 요청 차단
   • 서비스 진입 전에 차단하여 민감한 데이터 보호 및 성능 최적화
3. 일관된 권한 관리
   • 모든 API에 동일한 방식으로 Guard 적용 → 접근 제어 정책 유지
4. 유저 권한 정보 제공
   • Guard에서 매니저, 아티스트 등의 권한 정보를 서비스로 전달하여 중복 코드 감소
5. 확장성과 유지보수성 개선
   • 새로운 권한 정책 추가 시 Guard만 수정하면 적용 가능 → 서비스 코드 수정 최소화

➡ 결론: Guard를 활용하여 서비스 로직을 간결하게 유지하면서 보안과 성능을 개선하고, 유지보수성을 향상시킬 수 있었습니다.

3. 해결 방법 적용 후 발생한 문제

Guard를 적용하는 과정에서 또 다른 문제가 발생했습니다.

❌ 문제점: multipart/form-data 요청 처리 이슈

게시글을 등록하는 API에서는 JSON 형식의 게시글 정보와 함께 이미지 파일을 업로드할 수 있도록 multipart/form-data를 사용하고 있습니다.

하지만, Guard에서 multipart/form-data 형식의 request.body 값을 읽을 수 없는 문제가 발생했습니다.

원인 분석

multipart/form-data 요청은 파일 인터셉터를 사용해 파일 업로드가 완료된 후 request.files와 request.body로 분리됩니다. 이 분리 시점이 Guard보다 늦게 실행되어 request.body를 찾을 수 없었던 것 입니다.

4. 해결 방법: 미들웨어 적용

이 문제를 해결하기 위해 Guard 이전 단계에서 실행되는 미들웨어를 활용했습니다.

✅ 적용 방법

1. Multer 미들웨어를 게시글 모듈에 적용하여 파일을 먼저 처리
2. 파일 업로드 완료 후 files와 body가 분리됨
3. Guard에서 분리된 body 값을 받아와 유저 권한 확인

이 방법을 통해 Guard에서도 request.body 값을 정상적으로 확인할 수 있었습니다.

5. 결론 및 개인적인 생각

이번 해결 방법은 완벽하지 않지만, NestJS의 라이프사이클을 고려하여 Guard와 multipart/form-data 요청을 함께 사용하는 방법을 고민해본 사례로 기록하고자 합니다.

혹시 같은 문제를 겪고 계신 분들에게 도움이 되었으면 좋겠습니다. 😊

📌 참고 자료

• NestJS 공식문서: Request Lifecycle

현 서비스에는 권한이 계층형입니다. ① 전역: 비회원 ↔ 회원(JWT) ② 커뮤니티: 여러 커뮤니티 중 “요청된 커뮤니티에 가입된 멤버인지” ③ 역할: 그 커뮤니티에서의 일반 유저 / 아티스트 / 매니저 컨트롤러에서 매번 if–else로 검사하면 중복·누락이 생기고, 정책이 코드 곳곳으로 흩어집니다. 그래서 권한은 선언, 검증은 가드에서 처리하도록 변경했습니다.

현재 문제 → 개선 방안

문제

• Service 내부에서 ② 커뮤니티 권한 검사 → 코드 중복
• 권한 이슈를 Service에서 예외로 처리하기보다 API 입구에서 차단하는 게 적절

개선 방안

• 컨트롤러에 @UseGuards(JwtAuthGuard, CommunityUserGuard) 표준화
• 가드에서 ② 커뮤니티 회원 + ③ 역할(ARTIST/MANAGER) 검사
• Custom Decorator @CommunityUserRoles(...) 로 허용 role 선언

전체 흐름 요약

Controller (선언)
  └─ @CommunityUserRoles(…optional)  +  @UserInfo()  // 권한 역할 선언 + 유저 주입
      ↓
JwtAuthGuard (① 전역: 로그인/회원)
      ↓
CommunityUserGuard
  ├─ ② 커뮤니티 멤버인지 검사
  └─ ③ (필요시) 커뮤니티 역할(ARTIST/MANAGER) 검사

구현

아래 코드는 흐름을 설명하기 위해 실제 구현한 코드를 간소화한 버전입니다.

1) 역할(Role) Enum

// community-user-role.type.ts
export enum CommunityUserRole {
  ARTIST  = 'ARTIST',
  MANAGER = 'MANAGER',
  // 필요시 다른 역할 확장
}

2) Custom Decorator — 허용할 역할 선언

// community-user-roles.decorator.ts

import { SetMetadata } from '@nestjs/common';
import { CommunityUserRole } from './community-user-role.type';

export const COMMUNITY_ROLES_KEY = 'communityRoles';
export const CommunityUserRoles = (...roles: CommunityUserRole[]) =>
  SetMetadata(COMMUNITY_ROLES_KEY, roles);

위 Enum만 CommunityUser의 허용 role로 선언합니다. @CommunityUserRoles() 내부에 들어간 값을 읽어 가드에서 실제 검증에 사용합니다.

3) Custom Decorator — UserInfo()로 유저 정보 받기

// user-info.decorator.ts
import { ExecutionContext, createParamDecorator } from '@nestjs/common';

export const UserInfo = createParamDecorator(
  (data: unknown, ctx: ExecutionContext) => {
    const request = ctx.switchToHttp().getRequest();
    return request.user;
  },
);

매번 req.user 를 사용해 직접 꺼내오지 않고 @UserInfo 데코레이터를 만들어 유저 정보를 가져올 수 있도록 했습니다.

• 읽기 쉽고, 구조 변경 시 데코레이터 내부만 수정하면 된다.
• user만 필요해도 매번 req 전체를 받아야 했음 -> 필요한 정보만 가져오도록 변경

Before/After

// Before
@Post()
create(@Req() req: Request, @Body() dto: CreateDto) {
  const user = req.user; // 매번 이렇게 꺼냄
  ...
}

// After
@Post()
create(@UserInfo() user: PartialUser, @Body() dto: CreateDto) {
  ...
}

4) Guard - 역할 검사

// community-user.guard.ts
@Injectable()
export class CommunityUserGuard implements CanActivate {
  constructor(
    private readonly reflector: Reflector,
      // ...
  ) {}

  async canActivate(ctx: ExecutionContext): Promise<boolean> {
    const req = ctx.switchToHttp().getRequest();

    // 1) ① 로그인 여부 확인
    const userId = req.user?.id;
    if (!userId) throw new UnauthorizedException();

    // ...

    // 2) ② 해당 커뮤니티 유저인지 검사
     const existedCommunityUser =
      await this.communityUserService.findByCommunityIdAndUserId(
        communityId,
        userId,
      );

    // ...

    // 3) @CommunityUserRoles 데코레이터 안 roles를 가져오는 역할
    // ex) @CommunityUserRoles(ARTIST,MANAGER) → roles [ARTIST,MANAGER]
    const roles: CommunityUserRole[] = this.reflector.get(
      context.getHandler(),
    );

    // 4) roles 데코레이터 없으면 : 멤버면 통과
    if (roles.length === 0) return true;

    // 5) ③ 역할 검사(지정된 roles 중 맞으면 통과)
    const communityUserid = existedCommunityUser.communityUserId;

    // ③ 커뮤니티 유저이면서 ARTIST roles를 가진 경우
    if (roles.includes(CommunityUserRole.ARTIST)) {
      // ...
    }

    // ③ 커뮤니티 유저이면서 MANAGER roles를 가진 경우
    if (roles.includes(CommunityUserRole.MANAGER)) {
      // ...
    }

    // ...

    throw new ForbiddenException('존재하지 않는 역할입니다.');
  }
}

컨트롤러 적용 예시

// 1) 해당 커뮤니티 “멤버면” 접근
@UseGuards(JwtAuthGuard, CommunityUserGuard)
@Post(':communityId/assets')
createAsset(
  @UserInfo() user: PartialUser, 
  @Body() dto: CreateAssetDto,
) { /* ... */ }

// 2) “아티스트 또는 매니저”만 접근
@CommunityUserRoles(CommunityUserRole.ARTIST, CommunityUserRole.MANAGER) 
@UseGuards(JwtAuthGuard, CommunityUserGuard)
@Post(':communityId/publish')
publish(
 @UserInfo() user: PartialUser, 
  @Body() dto: PublishDto,
) { /* ... */ }

// 3) “매니저만” 접근
@CommunityUserRoles(CommunityUserRole.MANAGER)
@UseGuards(JwtAuthGuard, CommunityUserGuard)
@Delete(':communityId/posts/:postId')
removePost(
  @Param('postId') postId: string,
  @UserInfo() user: PartialUser,
) { /* ... */ }

마무리

기존 서비스 로직에 있던 코드들을 Guard를 사용하는 식으로 변경하고 나니 개발한 사람 외에는 팀원들이 사용할 수도 없을거란 생각을 했고, 쉽게 이해/사용할 수 있도록 가이드문서가 필요하다는 생각을 했습니다. 위 내용과 많이 중복되기는 하지만, 혹시 가이드 문서가 필요하다고 생각하신 분들이 참고할 수 있도록 짧게 사진 넣습니다 🥹

Reference

코드의 대부분은 NestJS 공식 문서에 관련 내용이 적혀있습니다! Guards | NestJS - A progressive Node.js framework Custom decorators | NestJS - A progressive Node.js framework

그럼 테이블명은 단수형으로 쓰는 게 좋을까요, 복수형으로 쓰는 게 좋을까요? 제 생각은 정답은 없지만 일관되게 사용하는 것이 중요하다입니다.

이번 포스트에서는 단수형과 복수형에 대한 의견을 살펴보고, 개인적인 생각도 살짝 담아보았습니다.

단수형 파

1. 각 행(레코드)를 나타낸다

• 테이블의 각 행이 하나의 엔티티를 나타내기 때문에 단수형이 더 직관적이다.
• 예를 들어, User 테이블은 개별 유저를 나타냄

2. 편리하고 에러 발생 가능성이 줄어든다

• 영어가 모국어가 아닌 프로그래머에게는 단수형이 더 쉽다.
• 복수형은 형태가 불규칙적일 수 있어 오타가 발생할 가능성이 있으며, 몇몇 복수형은 존재하지 않는다.
• 작성 시간이 줄고, 디스크 공간을 절약할 수 있다.
• (유머) 키보드를 많이 치지 않아 키보드를 오래 사용할 수 있습니다.

복수형 파

1. 집합값을 나타낸다

• 테이블이 여러 행을 포함하는 집합임을 나타내기 때문에 복수형이 더 자연스럽다.
• 예를 들어, Users 테이블은 모든 유저를 포함

2. 직관적이며 변수명과 일관성을 유지할 수 있다

• 리스트나 배열을 나타낼 때 복수형을 사용하듯, 여러 레코드를 포함하는 테이블명도 복수형으로 작성하는 것이 변수명과 일관성을 유지하는 방법입니다.

개인적인 선호: 단수형

정답은 없지만, 저는 단수형을 더 선호합니다.

1. 의미의 중복

각 엔티티는 데이터베이스의 테이블을 나타내기 때문에, 복수형을 사용하면 의미가 중복된다는 느낌을 받을 수 있습니다.

예를 들어, User 엔티티는 User 테이블로 해석되어 이미 User에 여러 개의 데이터를 포함할 것임을 알고 있습니다. 그렇다면 굳이 테이블 이름에 복수형을 붙여서 다시 여러 개임을 나타낼 필요가 있을까요?

저에겐 다소 아래 처럼 느껴집니다.

• 유저 + 여러개 + 여러개

양말을 넣은 서랍에 네임택을 붙인다고 생각했을때 보통 '양말'이라고 적지 '양말들'이라고 적지 않습니다. 저희는 이미 서랍에 '양말들'이 있을걸 알고 있기 때문인데요. 테이블 네이밍도 이와 비슷하다고 생각합니다.

2. 명확한 의미 전달

User와 Users 테이블이 있다고 가정해봅시다.

• User table: 유저의 집합
• Users table: 유저들의 집합

복수형을 사용했을때를 보면 해당 테이블이 각 유저 데이터에 대한 테이블인지, 여러 유저를 묶어 놓은 유저 덩어리 데이터의 테이블인지 명확하게 전달되지 않습니다.

복수형을 사용했을 때, 의미가 명확하게 전달되지 않는다고 느껴지는 부분이 제가 복수형을 선호하지 않는 가장 큰 이유인 것 같습니다.

다시 한번 결론

• 뭐가 옳다고 할 수는 없으나, 컨벤션을 정해 일관되게 사용하는 것이 중요하다.
• 단수형 / 복수형 섞어서 사용하지 말 것!

참고 자료

table-naming-dilemma-singular-vs-plural-names

오늘은 관계형 데이터베이스에 관련된 용어를 알아보겠습니다.

속성(attribute)

• 테이블에서 열(column) 을 의미합니다.
• 각각의 열은 이름과 타입을 가지고 있습니다.
• 필드(Field) , 속성(attribute, 애트리뷰트) , 열(column , 컬럼) 등으로 불립니다.
• 위의 학생 릴레이션의 속성은 4개입니다.

튜플(tuple)

• 릴레이션에서 행(row) 를 의미합니다.
• 행은 관계된 데이터의 묶음 입니다.
• 행(row) , 튜플(tuple, 투플) , 레코드(record) 등으로 불립니다.
• 위의 학생 릴레이션의 튜플은 총 5개 입니다.

카디널리티(Cardianlity)

• 한 릴레이션 안에 있는 튜플(tuple)의 개수이다.
• 유효한 릴레이션은 카디널리티 0을 가질 수 있습니다. 릴레이션을 만들었지만, 아직 데이터를 넣지 않은 것과 같은 경우 입니다.
• 릴레이션의 카디널리티는 시간이 지남에 따라 계속해서 변화합니다. 데이터를 추가하고 삭제함에 따라 튜플의 수가 변하기 때문입니다.
• 위 릴레이션의 튜플은 5개 이므로 카디널리티는 5 입니다.

차수(degree)

• 한 릴레이션 안에 있는 애트리뷰트(attribute)의 수 입니다.
• 유효한 릴레이션의 최소 차수는 1 입니다. 즉 모든 릴레이션들은 한 개 이상의 속성(attribute, 애트리뷰트)를 가져야 합니다.
• 릴레이션의 차수는 자주 바뀌지 않습니다. 차수가 바뀌기 위해서는 릴레이션의 구조를 자체를 바꿔야 하므로 잘 변경 되지 않습니다.
• 위 릴레이션의 속성의 수는 4개 이므로 차수는 4 입니다.

도메인(domain)

• 애트리뷰트가 가질 수 있는 값들의 집합을 도메인이라고 합니다.
• 하나의 도메인을 여러 속성에서 공유할 수도 있습니다.

• 위 student_tbl 릴레이션의 도메인은 VARCHAR(4), VARCHAR(20), VARCHAR(100), DATE 등이 있습니다.

참고

http://www.tcpschool.com/mysql/mysql_intro_relationalDB

제목(Heading)

h1부터 h6까지 #를 붙여 사용 가능합니다.

# Heading1

## Heading2     

### Heading3

#### Heading4

##### Heading5

###### Heading6

결과)

Heading1

Heading2

Heading3

Heading4

Heading5

Heading6

일반 본문

강조(Text attributes)

아래와 같이 텍스트에 강조 효과를 줄 수 있습니다.

It is *wonderful* ==> 이탤릭

It is **wonderful**  ==> 굵게

It is ***wonderful*** ==> 굵게 + 이탤릭

It is ~~wonderful~~ ==> 취소선

It is <u>wonderful</u> ==> 밑줄

It is wonderful It is wonderful It is wonderful It is wonderful It is wonderful

인용문(Quote)

> 를 이용하며, 중첩해 사용하거나 안에서 다른 마크다운 요소를 쓸 수 있습니다.

> I'm queen!!!!

> I'm queen!!!!
>> I'm queen!!!!
>>> I'm queen!!!!

> #### Heading4
* List1
> > * List 2
>>> ##### CodeBlock
>>>```
CodeBlock
>>>```

이런 식으로 복잡하게 중첩해서 쓸 수도 있습니다.

I'm queen!!!!

I'm queen1

I'm queen2

I'm queen3

Heading4

• List1

  • List 2

    CodeBlock

    CodeBlock

목록(List)

• 순서 없는 목록(Bullet List)

  * , + , - 를 이용하며, 혼합해서 사용하는 것도 가능합니다.

Fruits:
* apple
* pear
* grapes
* mango

vegetables:
+ lettuce
+ green onion
+ cabbage
+ mushroom

other fruits:
* watermelon
    + orange
        - plum

결과)
결과물이 velog에서는 제대로 나오지 않아서 마크다운 파일을 하나 생성해서 나온 결과 사진을 첨부했습니다.

• 순서 있는 목록(Numbered List)

  순서 있는 목록은 숫자와 점을 이용해 나타낼 수 있습니다.

1. first
2. second
3. third

1. first
2. second
3. third

번호의 순서가 틀리더라도 처음 시작한 숫자부터 내림차순으로 정의됩니다.

2. first
6. second
1. third

2. first
3. second
4. third
   

맨 처음 시작 숫자가 2이기 때문에 2 , 3 , 4로 나타나는 걸 볼 수 있습니다.

링크(Link)

Click [원하는 텍스트](링크)
This is [google](https://www.google.com/)

Click 원하는 텍스트 This is google

This is [google](https://www.google.com/ "구글로 이동")

위처럼 뒤에 설명을 붙이게 되면, 마우스를 가져다 댔을 때 아래처럼 뜨게 됩니다.

This is google

이미지(Image)

이미지도 링크와 같은 방법으로 삽입할 수 있습니다.

![이미지 설명](이미지 링크)

별도의 사이즈 조절 기능이 없기 때문에 이런 부분을 조정하고 싶다면 <img> 태그를 써야 합니다.

• 사이즈 조절 <img src="이미지주소" width="" height=""></img>

예시)
<img src="이미지주소" width="800px" height="500px"></img>

테이블(Table)

| 문자와 - 문자로 표를 만들 수 있습니다.

|Header|Description|
|--|--|
|cell1|cell2|
|cell1|cell2|
|cell1|cell2|
|cell1|cell2|

: 문자를 사용하면 정렬을 할 수 있습니다. 아래의 예제는 cell1은 중앙정렬, cell2는 우측정렬을 해봤습니다.

|Header|Description|
|:--:|--:|
|cell1|cell2|
|cell1|cell2|
|cell1|cell2|
|cell1|cell2|

코드(Code)

마크다운으로 코드를 삽입하는 방법에는 인라인(Inline) 과 코드블럭(CodeBlock) 으로 삽입하는 2가지 방법이 있습니다. 두 방법 다 백틱(`) 을 이용하여 사용할 수 있습니다.

• 인라인(Inline) 코드 삽입

`console.log('inline')`
<code>console.log('inline')</code>

console.log('inline') console.log('inline')

• 코드블럭(Code block) 삽입

  백틱(`) 3개를 위아래로 붙여 사용합니다.
  

*``` * console.log('block1') console.log('block2') console.log('block3') *``` *

console.log('block1')
console.log('block2')
console.log('block3')

``` 뒤에 사용하는 언어를 넣으면 문법 강조(Syntax highlighting) 가 가능합니다.

``` js console.log('block1') console.log('block2') console.log('block3') *``` *

console.log('block1')
console.log('block2')
console.log('block3')

줄바꿈

줄 바꿈은 문장 마지막에서 3칸 이상을 띄어쓰기()해야 합니다.

이 문장은 ___ 줄 바꿈 예시입니다.

이 문장은 줄 바꿈 예시입니다.

수평선

아래 있는 줄은 모두 수평선을 만듭니다.

***
---
----------- ----

참고

https://gist.github.com/ihoneymon/652be052a0727ad59601