yml properties 차이를 몰랐음. 찾아보니 문법의 차이고 성능 측면에서는 상관없음

  jpa:
    hibernate:
      ddl-auto: validate
    properties:
      hibernate:
        format_sql: true
    show-sql: true

    spring.jpa.hibernate.ddl-auto = validate
    spring.jpa.properties.hibernate.format_sql = true
    spring.jpa.show-sql = true

1. ddl-auto: validate

“엔티티(Entity)와 실제 DB 테이블 구조가 일치하는지만 검사”

옵션별 의미 값 의미 none 아무 것도 안 함 validate 구조만 검사 (지금 추천) update 엔티티 기준으로 테이블 수정 create 실행 시 테이블 전부 삭제 후 생성 create-drop 실행 시 생성, 종료 시 삭제

2. spring.jpa.properties.hibernate

• Hibernate 전용 세부 옵션

spring JPA는 내부적으로 Hibernate를 쓰기 때문에 Hibernate 설정을 이렇게 "넘겨서" 쓰는 구조

3. format_sql: true

• SQL을 보기 좋게 정렬해서 출력

예시 기본

select user0_.id as id1_0_,user0_.email as email2_0_ ...

select
    user0_.id as id1_0_,
    user0_.email as email2_0_
from
    user user0

디버깅에 능함

4. spring.jpa.show-sql: true

• Hibernate가 실행하는 SQL을 콘솔에 출력

실제로 어떤 SQL이 DB에 날아가는지 확인 가능

🎯 목표

• JavaScript가 왜 한 번에 하나만 실행되는지 이해한다
• 비동기 코드의 실행 순서를 예측할 수 있다
• Promise와 setTimeout의 실행 순서 차이를 설명한다

JavaScript는 싱글 스레드다

JavaScript는 한 번에 하나의 작업만 실행한다

• 동시에 여러 줄 실행 ❌
• 대신 순서를 관리해서 비동기처럼 보이게 만든다

이 순서를 관리하는 시스템이 이벤트 루프(Event Loop) 다.

이벤트 루프 핵심 구성요소

Call Stack

현재 실행 중인 동기 코드(함수 호출 기록)

• 함수 호출 시 스택에 쌓임
• 실행이 끝나면 스택에서 제거
• 항상 스택의 맨 위가 실행 중

Heap

객체, 배열, 함수 같은 참조 타입 데이터가 저장되는 공간

• 실제 데이터는 Heap에 저장
• 변수에는 Heap을 가리키는 참조값이 들어 있음
• 가비지 컬렉터(GC)가 관리

Web APIs (Host Environment)

비동기 작업을 대신 처리해주는 영역

• setTimeout
• 네트워크 요청(fetch)
• DOM 이벤트

JS 엔진 밖에서 동작하며, 작업 완료 후 큐로 전달됨.

Microtask Queue

동기 코드가 끝난 직후 가장 먼저 실행되는 대기열

대표 예시:

• Promise.then
• catch
• finally
• await 이후 코드

Task Queue (Macrotask Queue)

일반적인 비동기 콜백이 대기하는 큐

대표 예시:

• setTimeout
• setInterval
• DOM 이벤트 콜백

Event Loop

Call Stack이 비었을 때
Microtask → Task 순서로 실행을 조율하는 관리자

실행 순서 핵심 규칙 (가장 중요)

Call Stack이 비면
1️⃣ Microtask Queue를 전부 비우고
2️⃣ Task Queue에서 하나를 실행한다

이 과정이 반복된다.

setTimeout이 0초여도 늦는 이유

console.log("A");

setTimeout(() => console.log("B"), 0);

console.log("C");

출력

A
C
B

setTimeout은 즉시 실행 ❌

Web API → Task Queue → Event Loop를 거침

Promise가 더 먼저 실행되는 이유

console.log("A");

Promise.resolve().then(() => console.log("B"));

console.log("C");

출력

A
C
B

then 콜백은 Microtask Queue

Task보다 우선 실행됨

Promise vs setTimeout 함께 쓰는 경우

console.log("A");

setTimeout(() => console.log("B"), 0);

Promise.resolve().then(() => console.log("C"));

console.log("D");

출력

A
D
C
B

async / await 실행 흐름

async function test() {
  console.log(1);
  await Promise.resolve();
  console.log(2);
}

console.log(3);
test();
console.log(4);

출력

3
1
4
2

이유 await 뒤 코드는 Promise.then

즉, Microtask로 예약

중요한 포인트 (헷갈림 방지) Promise.then은 즉시 실행 ❌

예약(Microtask) 개념

Microtask 안에서 setTimeout을 등록하면 기존 Task보다 뒤에 실행됨

이벤트 루프 한 줄 요약 JavaScript는 동기 코드를 Call Stack에서 처리하고, 콜스택이 비면 Microtask를 먼저 전부 실행한 뒤, Task를 하나씩 실행한다.

🎯 목표

• this가 언제, 어떻게 결정되는지 이해한다
• 일반 함수 / 메서드 / 화살표 함수의 this 차이를 설명할 수 있다
• call / apply / bind의 역할과 차이를 명확히 구분한다

this란?

this는 함수가 “어디서 선언됐는지”가 아니라
“어떻게 호출됐는지”에 따라 결정된다

⚠️ 주의

• 스코프 → 선언 위치 기준
• this → 호출 방식 기준

this 결정 규칙 (핵심 4가지)

1️⃣ 전역에서의 this

console.log(this);

브라우저: window

2️⃣ 일반 함수 호출

function foo() {
  console.log(this);
}

foo();

브라우저: window

strict mode: undefined

👉 그냥 호출하면 전역 this

3️⃣ 메서드 호출

const user = {
  name: "철수",
  sayName() {
    console.log(this.name);
  }
};

user.sayName(); // 철수

👉 . 앞의 객체가 this

4️⃣ 화살표 함수

const user = {
  name: "철수",
  sayName: () => {
    console.log(this.name);
  }
};

user.sayName(); // undefined

화살표 함수는 자기 this가 없음

자신이 선언된 스코프의 this를 그대로 사용

화살표 함수 this 한 줄 정리

화살표 함수의 this는 “자기가 태어난 곳의 this”다

this가 깨지는 대표적인 상황

const user = {
  name: "철수",
  sayName() {
    setTimeout(function () {
      console.log(this.name);
    }, 0);
  }
};

user.sayName(); // undefined

이유

setTimeout 안의 함수는 일반 함수

호출 주체 없음 → 전역 this

해결 방법 3가지 1️⃣ 화살표 함수 (가장 많이 씀)

setTimeout(() => {
  console.log(this.name);
}, 0);

2️⃣ bind 사용

setTimeout(function () {
  console.log(this.name);
}.bind(this), 0);

3️⃣ 변수에 저장 (구식)

const self = this;

call / apply / bind란?

함수의 this를 강제로 지정하는 방법

call
func.call(thisArg, arg1, arg2);

즉시 실행

인자 나열

greet.call({ name: "철수" }, "안녕"); // 안녕 철수

apply

func.apply(thisArg, [arg1, arg2]);

즉시 실행

인자를 배열로 전달

greet.apply({ name: "영희" }, ["안녕"]);
// 안녕 영희

bind (⭐ 가장 중요)

const boundFn = func.bind(thisArg);

실행하지 않음

this가 고정된 새 함수 반환

이후 call / apply로도 this 변경 불가

const fn = foo.bind(obj);
fn.call(other); // this는 여전히 obj

바인딩(binding)이란?

this를 특정 객체에 연결(고정)하는 것

bind는 함수 자체를 고정하는 게 아님

함수 안에서 사용되는 this만 고정

🎯 목표

• JavaScript가 코드를 실행하기 전에 무엇을 준비하는지 이해한다.
• 호이스팅을 “코드 이동”이 아닌 실행 컨텍스트 생성 과정으로 설명한다.
• var / let / const 차이를 TDZ와 실행 컨텍스트 관점에서 이해한다.

실행 컨텍스트(Execution Context)란?

JavaScript 코드를 실행하기 위해
JS 엔진이 만드는 실행 환경

JS는 코드를 바로 실행하지 않는다.
먼저 준비 → 그 다음 실행한다.

실행 컨텍스트의 2단계

1️⃣ 생성 단계 (Creation Phase)

• 변수 이름 수집
• 함수 선언 등록
• 스코프 체인 구성
• this 결정

2️⃣ 실행 단계 (Execution Phase)

• 코드 한 줄씩 실행
• 값 할당 및 연산 수행

👉 호이스팅은 생성 단계에서 발생하는 현상

호이스팅(Hoisting)이란?

선언이 코드 위로 끌어올려진 것처럼 보이는 현상

실제로 이동하는 게 아니라
👉 실행 전에 선언을 미리 등록하는 것이다.

var의 호이스팅

console.log(a); // undefined
var a = 10;



내부 동작
// 생성 단계
var a = undefined;

// 실행 단계
console.log(a);
a = 10;

선언 + 접근 허용

값만 나중에 할당

👉 에러 ❌, 대신 undefined

let / const의 호이스팅과 TDZ
console.log(b); // ReferenceError
let b = 10;

특징

선언은 수집됨 ⭕

하지만 초기화 전까지 접근 금지

이 구간을 TDZ(Temporal Dead Zone) 라고 한다.

TDZ(Temporal Dead Zone)

선언은 되었지만 값이 할당되기 전까지 접근이 금지된 구간

{
  console.log(x); // ReferenceError
  let x = 10;
}

존재는 알고 있음

접근하면 즉시 ReferenceError

👉 값이 undefined인 상태 ❌ 👉 접근 자체가 불가능한 상태 ⭕

var vs let / const 차이 요약 구분 var let const 선언 수집 ⭕ ⭕ ⭕ 초기화 즉시(undefined) ❌ ❌ TDZ ❌ ⭕ ⭕ 재대입 ⭕ ⭕ ❌ 블록 스코프 ❌ ⭕ ⭕ 함수 호이스팅 함수 선언문

foo();

function foo() {
  console.log("foo");
}

생성 단계에서 함수 전체가 등록

선언 전 호출 가능

함수 표현식

bar(); // TypeError

var bar = function () {
  console.log("bar");
};

변수만 호이스팅

함수는 아직 없음

실행 컨텍스트 스택 (Call Stack)

실행 컨텍스트는 스택 구조로 관리된다

Global Context → 함수 A 실행 → 함수 B 실행 → B 종료 → A 종료

가장 나중에 실행된 함수가 먼저 종료 (LIFO)

재귀, 콜스택 에러의 원인

🎯 목표

• JavaScript에서 변수를 어떻게 찾는지 이해한다.
• 스코프 체인이 왜 “선언 위치 기준”인지 설명할 수 있다.
• 클로저를 메모리 개념이 아닌 접근 규칙 관점에서 이해한다.

스코프(Scope)란?

스코프는 값이 저장된 공간이 아니라
변수를 어디서 접근할 수 있는지에 대한 규칙이다.

• 메모리: 값이 저장되는 장소
• 스코프: 그 값에 접근할 수 있는 범위와 규칙

스코프 체인의 핵심 원칙

JavaScript는 변수를
“어디서 실행됐는지”가 아니라
“어디서 선언됐는지”를 기준으로 찾는다.

변수를 찾을 때의 순서:

1. 현재 스코프
2. 자신을 감싸는 상위 스코프
3. 전역 스코프

👉 가까운 곳부터, 없으면 바깥으로 올라간다.

선언 위치 vs 호출 위치

let x = 10;

function foo() {
  console.log(x);
}

function bar() {
  let x = 20;
  foo();
}

bar(); // 10

foo는 전역에서 선언됨

따라서 foo 안에서 x를 찾을 때

bar의 x는 고려되지 않는다

👉 함수는 자신이 선언된 스코프만 본다

var / let 차이 (핵심만) var는 반복문 전체에서 하나의 변수를 공유하고 let은 반복문 한 바퀴마다 새로운 변수를 만든다

// var
for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 0);
}
// 3, 3, 3

// let
for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 0);
}
// 0, 1, 2

클로저(Closure)란? ❌ 외운 정의

외부 함수의 변수를 참조하는 내부 함수

⭕ 이해용 정의

함수가 자신이 선언된 스코프를 기억하고 그 스코프에 계속 접근할 수 있는 현상

클로저가 생기는 이유

function outer() {
  let a = 1;
  return function inner() {
    console.log(a);
  };
}

const fn = outer();
fn(); // 1

outer 실행은 끝났지만

inner 함수가 a에 접근하고 있음

JS 엔진은 해당 변수를 제거하지 않음

👉 값이 메모리에 남아서가 아니라 접근 경로가 살아 있기 때문

클로저와 메모리의 관계 개념 의미 메모리 값이 저장되는 장소 스코프 변수를 찾는 규칙 클로저 함수가 스코프 접근을 유지하는 현상

클로저는 변수를 저장하는 것이 아니라 변수를 참조할 수 있는 상태를 유지한다.

클로저 예제 한 줄 설명

function makeCounter() {
  let count = 0;
  return function () {
    count++;
    return count;
  };
}

내부 함수는 자신이 선언된 스코프의 count를 기억하기 때문에 호출할 때마다 이전 상태를 유지할 수 있다.

🎯 목표

• JavaScript에서 얕은 복사와 깊은 복사의 차이를 이해한다.
• 객체 복사 시 왜 예상치 못한 버그가 발생하는지 설명할 수 있다.
• React에서 state를 직접 수정하면 안 되는 이유를 연결해서 이해한다.

복사가 왜 문제일까?

const a = { n: 1 };
const b = a;

b.n = 2;

console.log(a.n); // 2

객체를 복사했다고 생각했지만, 실제로는 같은 객체를 공유하고 있어서 한쪽을 수정하면 다른 쪽도 함께 변경된다.

👉 이 경우는 복사가 아니다 (참조 공유)

얕은 복사 (Shallow Copy) 정의

겉 객체만 새로 만들고, 내부 객체는 그대로 공유하는 복사

얕은 복사 예시 const a = { n: 1 }; const b = { ...a };

b.n = 2;

console.log(a.n); // 1

겉 객체는 새로 생성

n은 원시 타입이라 안전

⚠️ 얕은 복사의 함정 (중첩 객체)
const a = { n: { x: 1 } };
const b = { ...a };

b.n.x = 2;

console.log(a.n.x); // 2

n은 객체

내부 객체를 공유

속성을 수정하면 같이 바뀜

👉 겉만 복사했기 때문

얕은 복사지만 안전한 경우
const a = { n: { x: 1 } };
const b = { ...a };

b.n = { x: 2 };

console.log(a.n.x); // 1

공유 중인 객체의 속성 수정 ❌

객체 자체를 새로 교체 ⭕

📌 차이 포인트

속성을 바꾸면 공유 유지, 객체를 교체하면 분리

깊은 복사 (Deep Copy) 정의

겉 객체와 내부 객체까지 모두 새로 만드는 복사

structuredClone 사용
const a = { n: { x: 1 } };
const b = structuredClone(a);

b.n.x = 2;

console.log(a.n.x); // 1

내부 객체까지 완전히 분리

서로 영향 없음

복사 방식 한눈에 정리 방식 결과

b = a    ❌ 복사 아님 (공유)
{ ...a }    ⭕ 얕은 복사
structuredClone(a)    ⭕ 깊은 복사
React와 연결 (중요)
❌ 잘못된 상태 변경
state.user.name = "영희";
setState(state);

참조 유지

React는 변경을 감지하지 못함

리렌더링 ❌

⭕ 올바른 패턴

setState({
  ...state,
  user: {
    ...state.user,
    name: "영희"
  }
});

필요한 깊이까지만 새 객체 생성

불변성 유지

핵심 정리

복사 아님: 같은 객체를 공유

얕은 복사: 겉만 새로, 속은 공유될 수 있음

깊은 복사: 겉도 속도 전부 새로

중첩 객체에서는 얕은 복사에 주의해야 한다

🎯 목표

• JavaScript에서 원시 타입(Primitive) 과 참조 타입(Reference) 의 차이를 이해한다.
• const 인데도 객체 값이 바뀌는 이유를 설명할 수 있다.
• 함수에 객체를 넘겼을 때 원본이 바뀌는 경우 / 안 바뀌는 경우를 구분한다.

JS 자료형 큰 분류

JavaScript의 자료형은 크게 두 가지로 나뉜다.

Primitive Type (원시 타입) Reference Type (참조 타입)

Primitive Type (원시 타입)

정의

값 그 자체가 데이터인 타입

종류

• number
• string
• boolean
• null
• undefined
• symbol
• bigint

특징

• 값 자체가 복사됨
• 서로 영향을 주지 않음

let a = 10;
let b = a;

b = 20;

console.log(a, b); // 10, 20

Reference Type (참조 타입) 정의 객체를 가리키는 참조값을 데이터로 가지는 타입

종류 object

array

function

특징 참조값이 복사됨

여러 변수가 같은 객체를 가리킬 수 있음

const a = { value: 1 };
const b = a;

b.value = 2;

console.log(a.value); // 2

Primitive vs Reference 차이 구분 Primitive Reference 저장 값 자체 객체에 대한 참조값 복사 값 복사 참조값 복사 영향 없음 있음

const인데 왜 값이 바뀔까? 오해 const는 값이 바뀌면 안 된다 ❌

실제 의미 const는 재할당만 금지한다

const user = { name: "철수" };

user.name = "영희"; // ⭕ 가능 (객체 내부 수정)
user = { name: "민수" }; // ❌ 에러 (재할당)

객체 비교의 함정

const a = { value: 1 };
const b = { value: 1 };

console.log(a === b); // false

객체 비교는 내용 비교가 아니다

서로 다른 객체이므로 참조값이 다르다

함수와 참조 타입 (중요) 객체를 수정하는 경우

function change(user) {
  user.name = "영희";
}

const person = { name: "철수" };
change(person);

console.log(person.name); // "영희"

함수는 객체를 가리키는 참조값을 받는다

객체 내부를 수정하면 원본도 변경된다

참조를 재할당하는 경우

function update(user) {
  user = { name: "영희" };
}

const person = { name: "철수" };
update(person);

console.log(person.name); // "철수"

함수 내부에서 참조를 바꿔도

원본 객체에는 영향이 없다

핵심 정리 모든 변수는 값을 가진다

Primitive는 값 자체

Reference는 객체를 가리키는 참조값

객체를 수정하면 공유된 모든 참조에 영향

참조를 재할당해도 원본 변수는 변하지 않는다

한 줄 정리 JavaScript에서 버그의 대부분은 참조 타입을 값처럼 다룰 때 발생한다.

🎯 목표

• 브라우저에서 JS가 왜, 언제 실행되는지 설명할 수 있도록 한다.
• HTML / CSS / JS를 브라우저가 어떻게 처리해서 화면을 그리는지 정리한다.

브라우저 렌더링 흐름

HTML 파싱 → DOM 생성 → CSS 파싱 → CSSOM 생성 → Render Tree → Layout → Paint

파싱(parsing)이란?

문자열로 된 문서를
브라우저가 이해할 수 있는 의미 있는 객체 구조로 바꾸는 과정

HTML 파싱 예시

<button>클릭</button>
이 상태에서 브라우저 입장에서는

버튼 ❌

구조 ❌

의미 ❌

👉 단순한 문자 덩어리

브라우저는 HTML을 위에서부터 읽으면서 다음과 같이 해석한다.

"<button>"  → Button 노드 생성
"클릭"      → Text 노드 생성
"</button>" → 닫힘 처리
그 결과 만들어지는 구조는 다음과 같다.

Document
 └─ body
    └─ button
        └─ "클릭"
이렇게 생성된 트리가 DOM 트리이다.

DOM / CSSOM / Render Tree
HTML → DOM

CSS → CSSOM

DOM + CSSOM → Render Tree

Render Tree란? Render Tree는 DOM과 CSSOM을 결합해서 실제로 화면에 그릴 요소만 선별한 트리 구조이다.

백엔드로 따졌을 때 DTO 포지션과 비슷하다. 받아올 때 선언한 변수들을 전부 사용하지 않고, 필요한 것들만 뽑아서 사용하는 느낌이다.

파싱의 핵심

파싱은 이것이 무엇인지 이해하는 단계이다. 화면을 그리는 단계는 아니다.

Layout 과 Reflow

Layout
Render Tree를 기준으로
각 요소의 위치와 크기를 계산하는 단계

Reflow
Layout을 다시 계산하는 작업
DOM 구조 변경이나 요소의 크기 / 위치가 변경되면 발생한다.

Paint와의 차이
색 변경 → Paint

크기 / 위치 변경 → Reflow

box.style.color = "red";    // Paint
box.style.width = "200px"; // Reflow
색상 변경은 Layout에 영향을 주지 않기 때문에
Reflow가 아니라 Paint만 발생한다.

JS가 DOM을 바꾸면 성능이 나빠지는 이유
JS로 DOM을 변경하면
기존 Render Tree와 Layout 정보가 무효화된다.

그 결과,

DOM 변경
→ Render Tree 무효화
→ Layout(Reflow)
→ Paint
이 과정이 여러 번 반복되면
브라우저가 레이아웃을 계속 다시 계산하게 되어
성능이 저하된다.

📝 문제 상황

서비스에 공유하기 기능이 있었는데,
공유 링크를 복사해 브라우저에 붙여넣으면 404(Not Found) 오류가 발생했다.

기능을 확인하는 과정에서 한 가지 의문이 들었다.

“공유하기는 보통 현재 페이지 주소(URL)만 복사하면 되는 기능인데,
왜 백엔드에 공유 링크를 생성하는 로직이 존재하지?”

해당 기능을 구현한 팀원은 발표용 PPT 준비로 여유가 없는 상황이었고,
내가 대신 원인을 정리하고 수정 방향을 제안하게 되었다.

🔍 원인 분석

이번 이슈의 핵심은 공유 링크 생성 책임이 애매하게 분산되어 있었다는 점이었다.

• 기존 구조에서는
  • 방 등록 시점에 백엔드가 shareLink를 생성
  • 프론트는 해당 값을 그대로 사용
• 하지만
  • 프론트 라우팅 규칙과 실제 생성된 링크가 맞지 않으면서
  • 복사한 링크로 접근 시 404가 발생했다.

또한 공유 링크는:

• 서버 상태나 DB와 강하게 연결될 필요가 없고
• 프론트 라우팅 규칙만 알면 충분히 생성 가능한 값이었다.

🛠 해결 방법

팀원과 상의 후, 다음과 같은 방향으로 구조를 단순화했다.

✅ 1) 백엔드 공유 링크 자동 생성 로직 제거

• 방 등록 시 shareLink를 생성하던 백엔드 로직은 주석 처리
• 발표 일정상 리스크를 줄이기 위해
  • 백엔드 변경은 최소화
  • 프론트에서 책임을 가져가는 방향 선택

✅ 2) 공유 링크 생성 책임을 프론트로 이동

• 프론트에서 방 ID를 기준으로 공유 URL을 직접 생성
• 서버 응답에 의존하지 않도록 변경

// room.ts
const shareLinkUrl =
  roomId ? `${window.location.origin}/rooms/${roomId}` : undefined;



3) 공유 버튼 클릭 시 클립보드 복사만 수행

공유 버튼은 링크를 생성하지 않고

이미 프론트에서 계산된 URL을 복사하는 역할만 담당

const handleShareLink = async (room: RoomSummary) => {
  const link = room.shareLinkUrl;

  if (!link) {
    alert("공유 링크가 준비되지 않았습니다. 관리자에게 문의해 주세요.");
    return;
  }

  try {
    if (navigator.clipboard?.writeText) {
      await navigator.clipboard.writeText(link);
      alert("공유 링크가 클립보드에 복사되었습니다.");
    } else {
      // 구형 브라우저 대비
      window.prompt("이 링크를 복사해 주세요.", link);
    }
  } catch {
    window.prompt("이 링크를 복사해 주세요.", link);
  }
};

✅ 결과

공유 링크 복사 → 붙여넣기 시 발생하던 404 문제가 해결되었고

공유 기능의 책임이 명확해졌다:

URL 생성 → 프론트

복사 동작 → 공유 버튼

발표(PPT) 준비 일정에도 영향을 주지 않고 안정적으로 기능을 마무리할 수 있었다.

📌 배운 점

단순한 기능일수록 책임을 한 곳에 모으는 것이 유지보수에 유리하다.

공유 링크처럼

라우팅 규칙에만 의존하는 값은

굳이 백엔드에서 관리하지 않아도 된다.

협업 상황에서는

“누가 만들었는가”보다

현재 상황에 맞는 가장 단순하고 안전한 해결책을 선택하는 것이 중요하다.

• 팀원이 main 브랜치에 push
• 로컬에서 git pull을 했는데 오류 발생
• 다음과 같은 메시지를 보게 됨

fatal: Not possible to fast-forward, aborting.

또는

pull은 했는데 코드가 꼬이거나

브랜치 상태가 예상과 다르게 변함

즉,

“팀원이 올린 코드를 받아오려 했는데, Git이 거부한 상황”

🔍 원인 정리 이 문제는 대부분 로컬 브랜치와 원격 브랜치의 커밋 히스토리가 갈라졌을 때(diverge) 발생한다.

1️⃣ 로컬 커밋과 원격 커밋이 서로 다른 방향으로 진행됨 로컬 main 브랜치에서 커밋을 한 상태

동시에 원격 origin/main에도 다른 커밋이 추가됨

이 경우 Git은:

“어느 쪽이 기준인지 모르겠다” → fast-forward 불가

2️⃣ fast-forward 이란?

히스토리가 갈라지지 않았을 때, 병합 커밋 없이 브랜치가 직선으로 이어지는 상태를 말한다.

팀 프로젝트에서는 각자 브랜치에서 작업한 결과를 main에 병합하기 때문에 fast-forward가 되지 않는 구조가 오히려 자연스럽다.

반대로 개인 프로젝트에서는 히스토리가 갈라질 일이 거의 없으므로 fast-forward가 더 단순하고 안전하다.

A -- B -- C  (origin/main)
          \
           D  (local main)

이 구조에서는:

단순히 앞으로 당길 수 없음

반드시 merge 또는 rebase가 필요

3️⃣ pull.rebase 옵션의 영향 환경에 따라 Git 설정이 다음과 같을 수 있다.

git config --global pull.rebase true

이 경우:

git pull = fetch + rebase

rebase란 내 커밋들을 다른 브랜치의 최신 커밋 뒤로 “다시 얹는” 작업이다.

충돌 발생 시 더 복잡해 보일 수 있음

원인을 모르면 “왜 갑자기 안 되지?”라는 느낌을 받게 됨

🛠 해결 방법 ✅ 1) 무조건 git fetch부터

git fetch origin

원격 변경사항을 작업 트리에 반영하지 않고

상태만 먼저 확인

git log --oneline --graph --all

→ 브랜치가 어떻게 갈라졌는지 시각적으로 확인 가능

✅ 2) merge로 충돌을 직접 해결

git merge origin/main

충돌 발생 시

파일 열어서 직접 수정

git add

git commit

👉 팀 프로젝트에서는 가장 안전한 방식

✅ 3) 로컬 작업이 필요 없을 경우

git reset --hard origin/main

로컬 변경사항 전부 폐기

원격 상태와 완전히 동일하게 맞춤

⚠️ 주의: 협업 중에는 신중히 사용

✅ 4) 브랜치 전략 재정의 문제의 근본 원인은 브랜치 운영 규칙 부재인 경우가 많다.

main 직접 작업 ❌

기능 단위로 feature 브랜치 사용

PR 기반으로 merge

예:

feature/login
feature/oauth
feature/ban

📝 문제 상황

HTTPS 적용 후 프론트/백엔드 연결이 갑자기 안 됨

또는 redirect 루프 발생

EC2 + Nginx + Spring Boot 조합에서 흔한 상황

🔍 원인

80 → 443 redirect 설정 오류

프록시 경로(/api) mismatch

Nginx에서 CORS or host header 제대로 안 넘김

Certbot SSL 설정 파일 충돌

🛠 해결 방법

/etc/nginx/sites-enabled/default 구조 정리

proxy_pass 정확하게 / or /api 구분

React dev server와 Nginx path 충돌 해결

certbot이 만든 파일 중복 제거

📌 배운 점

HTTPS는 “SSL 설정 + proxy 설정 + redirect 설정” 세 가지가 모두 맞아야 돌아간다.

📝 문제 상황

클릭하면 UI에서는 반응하는 것처럼 보이는데

실제 DB 저장도 안 되고, 프로필 화면에서도 반영 안 됨.

isFavorite 상태가 꼬여서 UI만 업데이트됨.

🔍 원인

배열 내부에 isFavorite 값을 넣는 방식 자체가 불안정

Optimistic UI 적용이 중간에 실패

favorites Set 기반 구조와 충돌

🛠 해결 방법

rooms 배열에서 isFavorite 프로퍼티 제거

좋아요 여부는 favorites Set 기반으로만 렌더링

toggleFavorite에서 UI 선반영 제거

fetchFavoriteRooms로 초기 상태 보장

📌 배운 점

“좋아요 기능”은 global state가 불안정하면 쉽게 꼬인다 → Set 기반 관리가 가장 안정적.

📝 문제 상황

MUI 컴포넌트(Box 등)를 사용하는 과정에서 다음과 같은 TypeScript 오류가 발생했다.

{} 형식은 ReactNode에 할당할 수 없습니다.

yaml 코드 복사

렌더링 과정에서 JSX의 children 위치에
TypeScript가 허용하지 않는 타입이 전달되며 오류가 발생했다.

🔍 원인

React에서 children으로 전달될 수 있는 값은 ReactNode로 제한된다.

• 문자열, 숫자
• JSX 요소
• null, undefined, false
• 위 타입들의 배열

반면 객체(Object)는 렌더링 대상이 아니기 때문에
JSX에서 그대로 출력하려 할 경우 타입 오류가 발생한다.

이 오류는 MUI Box처럼 children: ReactNode를 그대로 사용하는 컴포넌트에서 특히 자주 드러난다.

🛠 해결 방법

JSX에서 객체를 직접 렌더링하지 않고,
실제로 화면에 표시할 수 있는 값만 추출해 컴포넌트로 감싸도록 수정했다.

{value && <Badge>{value}</Badge>}
또한 조건부 렌더링을 통해
렌더링 가능한 경우에만 컴포넌트를 출력하도록 방어 로직을 추가했다.

📌 배운 점
JSX의 children에는 반드시 ReactNode만 전달되어야 한다.

TypeScript는 이러한 문제를 런타임 이전에 잡아준다.

MUI + TypeScript 조합에서는
“이 값이 실제로 화면에 그려질 수 있는가?” 를 항상 의식해야 한다.

yaml
코드 복사

• Google OAuth2 로그인은 성공함
• 하지만 로그인 이후 항상 /(루트)로만 이동
• 실제로는 /home 또는 특정 페이지로 이동시키고 싶었음
• redirect_uri를 넘기거나 설정을 바꿔도 무시되는 것처럼 보였음

즉,

“OAuth2 로그인은 됐는데, 리다이렉트 제어가 전혀 안 되는 상황”

🔍 원인 정리

이 문제의 핵심은 Spring Security OAuth2의 기본 redirect 동작이 매우 강력하다는 점이다.
의도적으로 override 하지 않으면, 개발자가 설정한 값이 적용되지 않을 수 있다.

1️⃣ CustomOAuth2SuccessHandler가 실제로 적용되지 않음

Spring Security는 SuccessHandler를 명시하지 않으면 기본 핸들러를 사용한다.

• SavedRequestAwareAuthenticationSuccessHandler
• 또는 defaultSuccessUrl("/")

즉,

• CustomOAuth2SuccessHandler를 구현했더라도
• SecurityConfig에 명확히 등록하지 않으면
• 기본 SuccessHandler가 그대로 실행됨

➡ 그 결과, 항상 / 또는 기본 URL로 이동

2️⃣ Frontend redirect_uri와 Backend 처리 방식 불일치

• 프론트에서는 redirect_uri를 전달했지만
• 백엔드에서는 이를:
  • 읽지 않거나
  • 다른 파라미터 이름으로 기대하거나
  • 아예 사용하지 않았을 가능성

OAuth2에서는
“프론트가 보내는 redirect 정보”와
“백엔드가 실제로 사용하는 redirect 기준”이 정확히 일치해야 한다.

3️⃣ defaultSuccessUrl() 또는 OAuth2 기본 설정이 우선 적용됨

다음과 같은 설정이 존재하면:

.formLogin()
  .defaultSuccessUrl("/")

이 설정이 CustomSuccessHandler보다 우선 적용되어 직접 구현한 redirect 로직이 무력화될 수 있다.

문제 해결 방법

2) SecurityConfig에서 SuccessHandler를 명확히 지정

.oauth2Login(oauth -> oauth
    .userInfoEndpoint(userInfo -> userInfo.userService(customUserService))
    .successHandler(customSuccessHandler)
)

➡ “OAuth2 로그인 성공 시 이 핸들러를 사용하라”고 Security 설정에서 명시적으로 선언

✅ 3) defaultSuccessUrl() 제거 또는 OAuth2 영역에서 사용하지 않기

OAuth2를 커스터마이징하는 경우

defaultSuccessUrl()은 혼선을 유발할 수 있음

redirect 로직은 SuccessHandler 하나로 통일

✅ 4) 프론트 ↔ 백엔드 redirect 책임 분리

프론트가 redirect를 제어할지

백엔드가 redirect를 전담할지

👉 둘 중 하나만 책임지도록 명확히 정해야 한다. (혼합하면 현재와 같은 문제가 반복됨)

OAuth2 로그인 성공 시 커스텀 redirect 로직이 확실히 적용되도록 CustomOAuth2SuccessHandler를 SecurityConfig에 명시적으로 등록했다.

쿠키 기반 인증을 도입하는 과정에서 React와 Spring Security(OAuth2, JWT) 사이에 인증 방식 불일치로 총 4가지 대표적인 오류가 발생했다.

🟥 오류 유형 1 — 쿠키 기반 인증으로 바꿨는데 로그인 유지가 안 되는 문제

📌 문제 상황

OAuth2 로그인 성공 후 백엔드에서 HttpOnly 쿠키로 토큰을 전달했음.

하지만 프론트는 로그인 상태를 sessionStorage 기반으로 판단하고 있었음.

그 결과:

쿠키에는 토큰이 존재함

sessionStorage에는 없음 → 프론트는 계속 “로그인 안 됨”으로 판단 → 홈 화면 또는 로그인 화면으로만 리다이렉트됨

📌 원인

백엔드는 “쿠키 기반 인증”, 프론트는 “sessionStorage 기반 인증” → 인증 판단 기준이 완전히 달라졌기 때문.

📌 발생 조건

OAuth2SuccessHandler에서 쿠키 적용 시작

/api/me 기반 인증 로직이 없음

프론트가 sessionStorage만 읽고 상태 판단

📌 해결 방법

인증 판단을 sessionStorage에서 쿠키 기반 + /api/me 조회 방식으로 전환

axios 요청에 withCredentials: true 설정

로그인 여부는 sessionStorage가 아니라 백엔드 검증 기반으로 판단

🟥 오류 유형 2 — HttpOnly 쿠키가 JS에서 읽히지 않는 문제

📌 문제 상황

React에서 쿠키 값을 확인하려 했지만 결과값이 계속 undefined.

📌 원인

HttpOnly 쿠키는 원래 JS에서 읽을 수 없음. 이 속성은 보안(XSS 차단)을 위해 존재하는 것.

즉, JS에서 읽히지 않는 것이 “정상 동작”임.

📌 발생 조건

React에서 document.cookie 또는 cookie-parser로 접근하려고 함

HttpOnly 옵션이 적용된 쿠키였음

📌 해결 방법

쿠키를 직접 읽지 말고 /api/me 같은 사용자 정보 API에서 받은 응답으로 인증 여부 판단

모든 요청에 withCredentials: true 추가

핵심: “쿠키를 읽는다”가 아니라 “쿠키를 서버에 전송해서 인증한다”

🟥 오류 유형 3 — React에서 인증 여부 판단 불일치 → 무한 리다이렉트 / 로그인 안 됨

📌 문제 상황

다음과 같은 코드가 존재했음:

if (!sessionStorage.getItem("username")) { navigate("/"); }

하지만 백엔드는 쿠키 기반 인증이라 sessionStorage에는 아무것도 없었음.

→ 프론트가 계속 “로그인 안 됨”이라고 오판 → 홈 화면으로 강제 이동 또는 무한 redirect 발생

📌 원인

React 인증 상태 판단이 sessionStorage에 의존하고 있었음.

백엔드 인증 방식이 변경되었음에도 이를 반영하지 않은 구조적 문제.

📌 발생 조건

쿠키 기반 인증 도입

sessionStorage 사용 코드 삭제되지 않음

/api/me 호출 구조 미비

📌 해결 방법

로그인 여부를 sessionStorage → /api/me 방식으로 전환

sessionStorage 기반 인증 로직 제거

AuthContext에서 쿠키 기반 인증으로 변경

🟥 오류 유형 4 — useEffect에서 인증 체크가 잘못되어 무한 호출 / redirect 반복

📌 문제 상황

다음과 같은 useEffect 로직이 존재했음:

useEffect(() => { if (!sessionStorage.getItem("username")) { navigate("/"); } }, []);

Cookie → sessionStorage 불일치 때문에 해당 로직이 계속 발동해

로그인 성공 후에도 계속 "/"로 이동

useEffect 내부에서 navigate 반복 → 무한 루프처럼 보임

📌 원인

인증 판단 로직이 쿠키 구조를 반영하지 않고 sessionStorage만 검사했기 때문. 즉, useEffect는 “정상적으로 잘못된 조건”을 반복적으로 만족하게 된 것.

📌 발생 조건

쿠키 기반 인증으로 전환

sessionStorage 값 없음

useEffect가 최초 렌더링 때 항상 조건 만족 → redirect 실행

📌 해결 방법

useEffect의 인증 판단 로직을 /api/me 기반으로 변경

쿠키 기반 인증 여부를 비동기 로드 후 루트 경로 이동 여부 결정

sessionStorage 활용 코드 제거

📌 총정리

이 네 가지 문제는 모두 같은 뿌리에서 시작됨:

“백엔드는 쿠키 기반 인증으로 전환했는데 프론트는 여전히 sessionStorage 기반 인증을 유지하고 있었다.”

그 결과:

로그인 유지 안 됨

리다이렉트 반복

쿠키 읽기 불가

OAuth2 정상동작 안 함

등 여러 문제가 다른 증상처럼 보였지만 하나의 근본 원인에서 발생했다.

공통 해결 전략 — 인증 판단 기준을 /api/me로 통일

위 4가지 오류의 공통점은 모두 동일했다.

백엔드는 쿠키 기반 인증을 사용하고 있는데, 프론트는 여전히 sessionStorage 기준으로 로그인 여부를 판단하고 있었다.

그래서 설계적으로는 다음 전략이 가장 깔끔했다.

/api/me 호출로 서버에서 로그인 상태 검증

axios 요청에 withCredentials: true 적용

React 인증 상태(AuthContext)를 /api/me 응답으로 초기화

sessionStorage 기반 인증 로직 제거

🔁 현실적인 선택 — /api/me 대신 Redirect Token 방식으로 Rollback 📌 배경

설계적으로는 /api/me 기반 인증 구조가 가장 이상적이었다. 하지만 팀 프로젝트 환경에서는 현실적인 제약이 존재했다.

⚠️ 현실적인 문제

로그인 프론트엔드를 다른 팀원이 전담

해당 코드 구조를 즉시 파악하거나 수정하기 어려운 상황

/api/me 전환 시:

AuthContext 구조 변경

초기 렌더링 로직 수정

로그인/로그아웃 흐름 전반 수정 필요

👉 일정과 리스크를 고려했을 때 즉각적인 구조 변경이 어려웠다.

🔄 선택한 대응

최종적으로는 다음과 같은 rollback 전략을 선택했다.

OAuth2 로그인 성공 시 → 기존 방식대로 redirect URL에 accessToken / refreshToken 포함

프론트는 → 이미 구현된 sessionStorage 기반 로그인 로직 유지

Ban 사용자만 예외적으로 → ?error=banned_user 쿼리 파라미터로 redirect 처리

즉,

설계적으로는 /api/me가 정답이지만, 팀 협업 상황과 프로젝트 안정성을 고려해 기존 방식으로 rollback했다.

원래는 sessionStorage 에 저장된 값(토큰/username 등)을 기반으로 로그인 여부를 판단하고 있었음.

그러나 백엔드에서 OAuth2 성공 후 ➡ 쿠키(HttpOnly) 로 토큰을 전달하는 방식으로 바꾸면서 프론트는 sessionStorage만 보고 있었기 때문에:

쿠키에는 토큰이 있음

sessionStorage에는 없음 → 프론트는 “로그인 안 됨”으로 판단함 → 홈 화면으로 계속 리다이렉트되는 현상 발생

📌 원인 정리

“백엔드는 쿠키 기반 인증으로 변경했는데, 프론트는 여전히 sessionStorage 기준으로 인증 상태를 판단한 것”

즉, 백과 프론트의 인증 저장 방식 불일치가 원인.

📌 발생 조건

OAuth2 로그인 성공 후 토큰을 쿠키에 저장하는 구조로 전환

프론트는 sessionStorage만 검사

/api/me 호출 또는 쿠키 기반 인증 검증 로직이 없었음

📌 해결 방법

프론트는 쿠키 기반 인증 방식으로 업데이트

로그인 여부를 판단할 때 sessionStorage 대신 → /api/me 호출 혹은 → 쿠키를 포함한 axios 요청(withCredentials: true) 사용

로컬 로그인도 동일하게

쿠키 세팅 유지

인증 검증은 동일하게 /api/me에서 처리

백엔드: OAuth2SuccessHandler → redirect 유지

프론트: sessionStorage 기반 인증 제거

📌 정리 문장(벨로그용)

“쿠키 기반 인증을 도입했지만 프론트가 계속 sessionStorage를 기준으로 로그인 여부를 판단하고 있었기 때문에 인증이 정상적으로 완료되어도 로그인 처리되지 않고 홈 화면으로만 리다이렉트되는 문제가 발생했다. 이는 인증 저장 방식 불일치에서 기인한 문제였다.”

🚨 2. 오류 원인 #2 — Ban 처리 시 특정 경우 로그인되는 문제 (Local/OAuth2 처리 불일치) 📌 문제 상황

Ban된 사용자라면:

로컬 로그인 → 403 Forbidden

OAuth2 로그인 → redirect + error=banned_user

이렇게 모두 막혀야 정상이다.

하지만 실제로는 다음 현상이 발생함:

로컬 로그인에서는 정상적으로 ban 처리됨

OAuth2(구글) 로그인에서는 ban 사용자가 로그인 성공처럼 동작

또는 그 반대로 OAuth2에서는 막히지만 로컬에서는 토큰 발급됨

즉, 둘 중 하나의 ban 처리 로직이 씹혀서 적용되지 않는 문제

📌 원인 정리

Ban 검사가 다음 3곳에 분산되어 있었기 때문:

UserDetailsService (로컬 로그인)

OAuth2SuccessHandler

JwtAuthenticationFilter

이 세 곳에서 ban 체크 기준이 다르고 처리 방식도 달랐음.

그 결과:

OAuth2에서는 redirect만 이루어지고 ban 체크 누락

JwtAuthenticationFilter에서는 ban 여부 확인하지 않음

UserDetailsService는 로컬 로그인에서만 동작

➡ 결국 ban 사용자라도 로그인 성공 처리되는 시나리오가 발생했다.

📌 발생 조건

OAuth2SuccessHandler에서 ban 체크가 빠진 상태

JWT 인증 필터가 ban 토큰을 검증하지 않음

UserDetailsService는 로컬 로그인만 커버 → 세 로직이 “각자 따로 놀면서” 누락 발생

📌 해결 방법

해결 핵심 포인트는 “ban 처리를 모든 인증 경로에서 일관되게 적용하는 것”

Local 로그인 (UserDetailsService)

ban → 403 banned_user JSON 응답

OAuth2 로그인 (CustomSuccessHandler)

ban → sendRedirect(...?error=banned_user)

JWT 인증 (JwtAuthenticationFilter)

ban 사용자의 토큰 → 403 banned_user

프론트는 local/OAuth2 모두 같은 방식으로 경고

axios catch에서 403 처리

OAuth2 redirect param 확인

📌 정리 문장(벨로그용)

“Ban 처리가 UserDetailsService, OAuth2SuccessHandler, JwtAuthenticationFilter로 분산되어 있었고, 각각의 로직이 일관되지 않아 특정 경우에는 ban된 사용자도 로그인되는 문제가 발생했다. 이를 모든 인증 경로(Local/OAuth2/JWT)에 대해 동일한 기준으로 ban 검증 로직을 통일함으로써 해결하였다.”

✨ 최종 — 벨로그에 두 오류를 나누어 설명할 때의 추천 구조

🔥 OAuth2 + JWT + Cookie 기반 인증 통합 중 발생한 문제 원인 정리

1. 오류 원인 #1 — 쿠키 기반 인증 도입 후 로그인 실패 & 홈 화면 리다이렉트 문제

(설명 + 원인 + 해결 + 정리문장)

2. 오류 원인 #2 — Ban 처리 불일치로 특정 사용자가 로그인되는 문제

(설명 + 원인 + 해결 + 정리문장)

마무리

두 문제는 모두 "백/프론트 인증 흐름의 불일치"와
"ban 처리 책임이 분산된 구조"에서 비롯되었으며
리팩토링 후 인증 경로를 일원화함으로써 해결되었다.

🟦 포함 내용

폴더 구조 설계

컴포넌트/페이지 분리 기준

API layer 설계

공통 컴포넌트 구조

재사용 가능한 UI 설계

🟦 포함 내용

불필요 렌더링이 왜 발생하는가

각 훅의 사용 목적

실전 기준 언제 써야 하는가

🟦 필수 개념

전역 상태의 필요성

Context API 한계

Zustand 실전 예

Redux Toolkit 소개

🟦 핵심 내용

axios 설치 및 기본 셋팅

GET / POST 실전

에러 핸들링

API 요청 구조 설계

React Query 도입 여부