1. ES6 도입 배경

기존 자바스크립트는 복잡한 웹 애플리케이션을 개발하기에 구조적인 한계가 있었음. 이를 해결하고 현대적인 개발 환경을 구축하기 위해 대규모 업데이트가 진행됨. 특히 신입 개발자 기술 면접이나 리액트(React) 같은 모던 프론트엔드 프레임워크를 다룰 때 반드시 알아야 하는 핵심 기반임.

• 변수 관리 문제: 엉성한 유효 범위(Scope)로 인해 예측 불가능한 버그 발생.
• 콜백 지옥 (Callback Hell): 비동기 작업 처리 시 코드가 심하게 중첩됨.
• 모듈 시스템 부재: 코드를 여러 파일로 쪼개고 관리하는 표준 방법이 없었음.

2. 핵심 변화 8가지 (코드 예시 포함)

① let, const 도입 (블록 스코프)

기존 var는 함수 단위 스코프를 가져서 제어가 어렵고 재선언이 가능해 버그의 주범이었음. ES6부터는 블록 단위 {} 스코프를 가지는 let과 const가 도입됨.

• let: 재선언 불가, 값 변경 가능. (값이 바뀔 변수에 사용)
• const: 재선언 불가, 값 변경 불가. (상수 선언에 사용, 기본적으로 가장 많이 권장됨)

// Before (var)
var a = 1;
var a = 2; // 에러 안 남 (의도치 않은 덮어쓰기 위험)

// After (let, const)
let b = 1;
b = 2; // 값 변경 가능

const c = 1;
// c = 2; // TypeError 발생 (상수는 변경 불가)

② 화살표 함수 (Arrow Function)

함수 선언 문법을 간결하게 만들고, 기존 함수의 복잡한 this 바인딩 문제를 해결함. 자신만의 this를 생성하지 않고 상위 스코프의 this를 그대로 유지하기 때문에 콜백 함수로 넘길 때 매우 유용함.

// Before
const addES5 = function(a, b) {
  return a + b;
};

// After
const addES6 = (a, b) => a + b; // 실행문이 한 줄이면 중괄호와 return 생략 가능

③ 템플릿 리터럴 (Template Literal)

백틱(`)을 사용하여 문자열과 변수 결합을 직관적으로 개선함. 줄바꿈 기호(\n) 없이도 줄바꿈이 그대로 인식됨.

const name = "김개발";
const job = "프론트엔드 개발자";

// Before
var introES5 = "안녕하세요. 저는 " + name + "이고,\n" + job + "입니다.";

// After
const introES6 = `안녕하세요. 저는 ${name}이고,
${job}입니다.`;

④ 구조 분해 할당 (Destructuring)

객체나 배열에서 필요한 데이터만 변수로 쉽게 추출함. 리액트에서 컴포넌트의 props를 넘겨받거나 useState를 다룰 때 아주 자주 쓰이는 패턴임.

const user = { name: "지민", age: 25, city: "서울" };

// Before
var nameES5 = user.name;
var ageES5 = user.age;

// After (객체 구조 분해)
const { name, age } = user;
console.log(name); // "지민"

// 배열 구조 분해
const colors = ["red", "green", "blue"];
const [firstColor, secondColor] = colors;
console.log(firstColor); // "red"

⑤ 전개 연산자 (Spread Operator)

점 세 개(...)를 사용해 배열이나 객체의 요소를 쉽게 복사하거나 합칠 수 있음. 원본 데이터를 직접 훼손하지 않고 새로운 데이터 복사본(상태)을 만들어야 할 때 필수적으로 사용됨.

// 배열 합치기
const arr1 = [1, 2, 3];
const arr2 = [4, 5, 6];
const combined = [...arr1, ...arr2]; // [1, 2, 3, 4, 5, 6]

// 객체 복사 및 속성 수정
const user1 = { name: "철수", age: 20 };
const updatedUser = { ...user1, age: 21 }; // { name: "철수", age: 21 }

⑥ 기본 매개변수 (Default Parameters)

함수를 호출할 때 값을 전달하지 않았을 경우 사용할 기본값을 미리 설정할 수 있음. 코드의 방어력을 높여줌.

// Before
function greetES5(name) {
  var userName = name || "손님";
  console.log("환영합니다, " + userName);
}

// After
const greetES6 = (name = "손님") => {
  console.log(`환영합니다, ${name}`);
};

greetES6(); // 환영합니다, 손님
greetES6("영희"); // 환영합니다, 영희

⑦ 프로미스 (Promise)

서버에서 데이터를 받아오는 등의 비동기 처리 방식을 개선하여 콜백 지옥을 해결함. .then(), .catch() 메서드로 성공/실패 결과를 깔끔하게 체이닝하여 처리함. (이후 등장한 async/await 문법의 기반이 됨)

// Promise 예시
const fetchData = () => {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      resolve("데이터 수신 완료");
      // 에러 발생 상황: reject("에러 발생");
    }, 1000);
  });
};

fetchData()
  .then((data) => console.log(data)) // 성공 시 실행
  .catch((error) => console.error(error)); // 실패 시 실행

⑧ 모듈 (Module - Import / Export)

파일 단위로 코드를 분리하고 필요한 것만 가져다 쓸 수 있는 표준 방식. 전역 변수 이름이 겹쳐서 충돌하는 것을 막고, 코드 재사용성을 극대화함.

// math.js 파일 (내보내기)
export const add = (a, b) => a + b;
export const sub = (a, b) => a - b;

// app.js 파일 (가져오기)
import { add, sub } from './math.js';

console.log(add(10, 5)); // 15

EC2에서 S3 같은 AWS 서비스에 접근할 때, 굳이 외부 인터넷(IGW)을 거칠 필요가 없다. 보안과 효율을 위해 사용하는 VPC 엔드포인트의 개념을 정리하고, 헷갈리기 쉬운 NAT Gateway와의 차이점 및 보안 설정까지 다뤄본다.

1. VPC 엔드포인트란? (개념 잡기)

VPC 내부의 인스턴스가 인터넷 게이트웨이(IGW)를 거치지 않고, AWS의 다른 서비스(S3, DynamoDB 등)와 직접 통신할 수 있게 해주는 기술이다.

💡 왜 쓸까? (3가지 이점)

1. 보안 (Security): 트래픽이 공용 인터넷(Public Internet)을 타지 않고 AWS 글로벌 네트워크 안에서만 움직인다. 해킹 위험이 줄어든다.
2. 비용 (Cost): NAT Gateway를 통해 데이터를 많이 보내면 데이터 처리 비용이 꽤 나온다. S3 같은 대용량 전송은 엔드포인트가 훨씬 경제적일 수 있다.
3. 성능 (Performance): 네트워크 경로가 단순해져서 지연 시간(Latency)이 줄어든다.

비유: 창고로 가는 전용 통로

• 기존: 집(VPC)에서 창고(S3)에 가려고 현관문(IGW)을 열고 동네 한 바퀴(인터넷)를 돌아서 창고로 들어감.
• 엔드포인트: 집 벽을 뚫어서 창고로 바로 이어지는 비밀 통로를 만듦.

2. 엔드포인트의 두 가지 유형

지원하는 서비스와 동작 방식에 따라 크게 두 가지로 나뉜다.

① Gateway Endpoint (게이트웨이 엔드포인트)

• 대상: S3, DynamoDB (딱 2개만 기억하자)
• 방식: 라우팅 테이블(Route Table)에 *"S3로 가는 트래픽은 이쪽 문으로 가라"* 고 표지판을 세우는 방식.
• 특징:
  • VPC 내부에 별도의 IP주소(ENI)를 만들지 않는다.
  • 무료다. (가장 큰 장점)
  • OS단에서 별도 설정이 필요 없다.

② Interface Endpoint (인터페이스 엔드포인트)

• 대상: 그 외 대부분의 서비스 (SQS, SNS, Kinesis, CloudWatch 등)
• 방식: PrivateLink 기술을 사용한다. 서브넷 안에 ENI(랜카드)를 하나 생성하고, 그 IP로 트래픽을 보낸다.
• 특징:
  • Private IP가 할당된다.
  • 유료다. (시간당 요금 + 데이터 처리 요금)
  • 보안 그룹(Security Group)을 적용할 수 있다.

3. 헷갈리기 쉬운 개념 비교: NAT Gateway vs VPC Endpoint

AWS를 처음 배우면 이 둘의 차이가 헷갈린다. 둘 다 "Private Subnet에서 밖으로 나갈 때" 쓴다는 점이 비슷하기 때문이다.

요약: 내 서버가 '구글'에 접속해야 하면 NAT Gateway가 필요하고, 'S3'에만 접속하면 되는데 굳이 비싼 NAT를 쓸 필요 없이 엔드포인트를 쓰면 된다.

4. 심화: 조금 더 디테일한 설정들

① VPC Endpoint Policy (문지기 설정)

엔드포인트를 뚫어놨다고 해서 아무나 다 지나가게 하면 위험하다. Endpoint Policy(JSON 정책)를 통해 제어할 수 있다.

• 예: *"이 엔드포인트로는 내 회사 S3 버킷(My-Bucket)에만 접근 가능하고, 다른 사람의 S3 버킷에는 접근 금지!"*
• IAM 권한과는 별개로, 네트워크 관문 자체에서의 제어가 가능하다.

② Private DNS (인터페이스 엔드포인트용)

Interface Endpoint를 생성하면 복잡한 전용 도메인 주소가 나온다. 하지만 개발할 때 코드를 바꾸기 귀찮다.

• Private DNS 기능을 켜면, AWS 기본 도메인(예: sqs.ap-northeast-2.amazonaws.com)을 그대로 써도, 알아서 내부 엔드포인트 IP로 연결해준다.
• 즉, 애플리케이션 코드를 수정할 필요가 없다.

5. 정리

1. AWS 서비스끼리 통신할 때는 VPC 엔드포인트를 쓰는 게 국룰이다.
2. S3, DynamoDB는 무료인 Gateway 타입을 쓴다. (라우팅 테이블 건드림)
3. 나머지는 유료인 Interface 타입을 쓴다. (ENI 생성, PrivateLink 기술)
4. 인터넷 접속이 목적이라면 NAT Gateway, AWS 서비스 접속이 목적이라면 VPC Endpoint.

구조 개요

• VPC1 (10.0.0.0/16) : MyWeb1
• VPC2 (172.16.0.0/16) : MyWeb2, MyWeb3
• VPC2 앞단에 Network Load Balancer(NLB) 배치

1. Region과 Availability Zone

Region은 AWS의 물리적 위치 단위이며, Availability Zone(AZ)은 리전 내부의 독립된 데이터센터 묶음이다.
각 서브넷은 하나의 AZ에 소속되어 물리적 장애 격리를 제공한다.

2. VPC (Virtual Private Cloud)

VPC는 AWS에서 사용하는 논리적으로 분리된 네트워크 공간이다.
서로 다른 VPC는 기본적으로 통신할 수 없으며 CIDR도 겹칠 수 없다.

3. CIDR과 IP 범위

CIDR은 네트워크에서 사용할 수 있는 IP 범위를 정의한다.

예시:

• 10.0.0.0/16 → 10.0.0.0 ~ 10.0.255.255
• 10.0.1.0/24 → 10.0.1.0 ~ 10.0.1.255

EC2 인스턴스의 Private IP는 반드시 서브넷 CIDR 범위 안에 포함되어야 한다.

4. Subnet

Subnet은 VPC를 더 작은 네트워크 단위로 나눈 것이다.
EC2 인스턴스는 반드시 하나의 서브넷에 속한다.

이번 구조:

• MyPublic1Subnet (10.0.1.0/24)
• MyPublic2Subnet (172.16.1.0/24)

5. Internet Gateway (IGW)

IGW는 VPC와 인터넷을 연결하는 게이트웨이다.
IGW만 연결되어 있다고 해서 바로 인터넷 통신이 가능한 것은 아니며, Route Table 설정이 필요하다.

6. Route Table

Route Table은 패킷이 이동할 경로를 정의한다.

Public Subnet이 되기 위한 조건:

0.0.0.0/0 → Internet Gateway

이 경로가 있어야 서브넷의 리소스가 인터넷과 통신할 수 있다.

7. Private IP와 Public IP

EC2는 항상 Private IP를 가진다.
Public IP는 외부에서 접근하기 위한 NAT 개념으로 매핑된다.

로드밸런서와 EC2 간 통신은 모두 Private IP를 사용한다.

8. Network Load Balancer (NLB)

NLB는 L4(TCP) 레벨에서 동작하는 로드밸런서이다.
패킷의 IP와 포트만 보고 트래픽을 전달한다.

이번 구조에서는 NLB가 MyVPC07에 위치하며, MyWeb2와 MyWeb3으로 트래픽을 분산한다.

9. Target Group

Target Group은 로드밸런서가 트래픽을 전달할 대상 집합이다.

target_type = "instance" 설정 시, EC2 인스턴스가 대상이 된다.

10. VPC 분리 의미

외부에 노출되는 서비스 영역(MyVPC07)과 내부 서버 영역(MyVPC06)을 네트워크 레벨에서 분리하여 구성할 수 있다.

예약 날짜가 하루 전으로 조회되는 문제 (트러블 슈팅)

리사이쿨 프로젝트에서 예약 정보를 조회할 때,
사용자가 선택한 날짜보다 하루 전 날짜가 조회되는 문제가 발생했다.
특히 결제 페이지와 예약 상세 화면에서 날짜가 어긋나 보이면서 이슈를 인지하게 되었다.

문제 상황

예약 생성 시 사용자가 날짜를 선택하면
조회 시 해당 날짜가 항상 하루 전 날짜로 표시되었다.

예시

• 선택한 날짜: 2026-01-02
• 조회된 날짜: 2026-01-01

원인 분석

프론트엔드에서 날짜를 서버로 전달할 때 다음과 같은 방식으로 처리하고 있었다.

selectedDate.toISOString().slice(0, 10)

toISOString()은 날짜를 UTC 기준 문자열로 변환한다.
이 과정에서 한국 시간(KST)을 기준으로 날짜를 선택하더라도
UTC 기준으로 변환되면서 날짜가 하루 전으로 계산되어 서버에 전달되고 있었다.

문제의 원인은 서버가 아닌,
프론트엔드에서 날짜를 변환하는 방식에 있었다.

해결 방법

UTC 변환을 제거하고,
프론트엔드에서 로컬 기준 날짜를 문자열로 직접 생성해 서버에 전달하도록 수정했다.

const formatDate = (date) => {
  const y = date.getFullYear();
  const m = String(date.getMonth() + 1).padStart(2, "0");
  const d = String(date.getDate()).padStart(2, "0");
  return `${y}-${m}-${d}`;
};

서버에서는 날짜를 LocalDate로 처리해
타임존 영향을 받지 않도록 유지했다.

결과

• 예약 생성 시 선택한 날짜와
• 예약 조회 및 결제 페이지에 표시되는 날짜가 정확히 일치
• 날짜가 하루씩 밀리는 현상 해결

이번 이슈를 통해 날짜와 타임존 처리는
프론트엔드와 백엔드가 함께 기준을 맞춰야 한다는 점을 다시 한번 정리할 수 있었다.

클라우드 서비스는 누가 어디까지 관리하느냐에 따라 구분된다.
대표적으로 On-Premise, IaaS, PaaS, SaaS 네 가지 형태가 있다.

1-1. On-Premise

On-Premise는 모든 것을 직접 관리하는 방식이다.
서버, 네트워크, 운영체제, 미들웨어, 애플리케이션까지 전부 직접 구성한다.
초기 비용과 관리 부담이 크지만, 제어 범위가 가장 넓은 구조다.

1-2. IaaS (Infrastructure as a Service)

IaaS는 인프라만 클라우드에서 제공받는 형태다.
서버, 스토리지, 네트워크, 가상화 계층까지 AWS가 관리한다.
운영체제부터 애플리케이션은 사용자가 직접 관리한다.

• 대표 예시: EC2
• 서버 환경을 직접 다뤄야 하는 경우에 적합한 구조

1-3. PaaS (Platform as a Service)

PaaS는 애플리케이션 실행 환경까지 제공되는 형태다.
운영체제, 런타임, 미들웨어를 신경 쓰지 않아도 된다.
개발자는 코드와 데이터에만 집중할 수 있다.

• 서버 설정 부담 감소
• 빠른 개발과 배포에 유리한 구조

1-4. SaaS (Software as a Service)

SaaS는 완성된 소프트웨어를 서비스 형태로 제공받는 방식이다.
사용자는 설정이나 개발 없이 바로 사용한다.
이메일, 협업 도구 등이 대표적인 예시다.

3. AWS 네트워크 기본 개념

AWS 네트워크는
물리적인 위치 개념에서 시작해서
논리적으로 분리된 네트워크를 구성하는 구조다.
큰 단위부터 순서대로 이해하는 것이 편하다.

Region (리전)

Region은 AWS 데이터 센터가 위치한 물리적 지역을 구분하는 단위다.
서울, 도쿄처럼 지역별로 나누어 운영하는 방식이다.
리전 간 리소스는 기본적으로 분리해서 사용하는 구조다.

Availability Zone (가용 영역)

Availability Zone은 하나의 리전 안에 존재하는 독립된 데이터 센터 묶음이다.
각 AZ는 서로 영향을 주지 않도록 분리되어 있다.
장애가 발생해도 서비스를 유지하도록 구성하는 방식이다.

VPC (Virtual Private Cloud)

VPC는 AWS 안에서 사용하는 논리적으로 분리된 가상 네트워크다.
IP 주소 대역을 직접 정해서 네트워크를 구성하는 방식이다.
AWS 네트워크 설정의 시작점에 해당하는 개념이다.

Subnet

Subnet은 VPC를 더 작은 네트워크 단위로 나누는 구조다.
서브넷 단위로 접근 범위와 역할을 구분한다.

Public Subnet

• 외부 인터넷과 직접 통신하도록 구성하는 방식
• 웹 서버, 로드 밸런서 등을 배치하는 용도

Private Subnet

• 외부에서 직접 접근하지 못하도록 구성하는 방식
• DB 서버, 내부 서비스 등을 배치하는 용도

Internet Gateway

Internet Gateway는 VPC와 인터넷을 연결하는 역할을 한다.
퍼블릭 서브넷이 외부와 통신할 수 있도록 설정하는 방식이다.
라우팅 테이블과 함께 사용한다.

Routing Table

Routing Table은 네트워크 요청의 이동 경로를 정의하는 설정이다.
어디로 트래픽을 보낼지 규칙을 지정하는 방식이다.
서브넷마다 하나의 라우팅 테이블을 연결해서 사용한다.

Security Group

Security Group은 인스턴스 단위로 적용하는 보안 설정이다.
허용할 트래픽만 명시하는 방식이다.
인바운드와 아웃바운드 규칙을 통해 접근을 제어한다.

• 상태를 기억하는 방식(Stateful)
• 허용되지 않은 요청은 자동 차단

정리

AWS 네트워크는
Region 안에 Availability Zone이 있고,
그 안에 VPC를 만들고,
VPC 안에 Subnet을 나누고,
Security Group으로 접근을 제어하는 구조다.

이 흐름을 이해하는 것이 AWS 네트워크 학습의 핵심이다.

Recychool 프로젝트에서 예약 결제를 구현하면서
PortOne에서 제공하는 Browser SDK v2를 사용해
프론트와 서버의 역할을 분리한 결제 구조로 구성

프론트에서는 결제 UI와 결제 요청만 담당하고,
결제 성공 여부 판단과 상태 변경은 서버 기준으로 처리하는 방식

결제 전체 흐름

예약 생성 (PENDING)
→ 결제 페이지 진입 (/payment/:reserveId) → PortOne 결제창 호출
→ 결제 성공 응답 (impUid, merchantUid) → 서버 결제 검증
→ 결제 완료 / 상태 변경

PortOne 결제창 호출 (Frontend)

결제 페이지에서 PortOne Browser SDK v2를 사용해 결제창을 호출

• 결제 수단별로 channelKey 분리
• 프론트에서 paymentId 생성 → merchantUid 역할
• PortOne 결제 성공 시 반환되는 고유 ID를 서버 검증용으로 사용

결제 요청 시에는 최소한의 필수 정보만 전달

• storeId
• channelKey
• paymentId (merchantUid)
• amount
• customer 정보 (name, email, phone)

결제 성공 후에는 PortOne SDK 응답으로 받은 결제 식별자를 서버에 전달해
실제 결제 완료 처리 요청

결제 완료 처리 (Backend)

POST /private/payment/complete

프론트에서 전달받은 결제 정보에 대해
서버에서 결제 검증 → 저장 → 상태 변경 순서로 처리

처리 순서

1. impUid 중복 검사
2. reserveId 기준 결제 가능 여부 확인
3. PortOne 서버 결제 정보 조회 및 검증
4. 결제 금액 위·변조 여부 검증
5. Payment 저장
6. Reserve 상태 변경

이미 처리된 결제 요청에 대해서는
→ HTTP 409 (Conflict) 로 응답해 중복 결제를 차단

개요

• 관점: 개발에 있어 관심사(Concern)를 의미
• 효과:
  • 코드 중복 감소
  • 핵심 로직과 주변 로직을 분리하여 관리 가능

핵심 로직 vs 주변 로직

• 주변 로직 체크리스트
  • 파라미터가 잘 전달 되었는가?
  • 로직에서 발생할 수 있는 예외가 무엇인가?
• 정의: 핵심 로직은 아니지만 반복적으로 개발에 필요한 관심사
• AOP의 역할:
  • 주변 로직 ➡ 횡단 관심사로 분리
  • 핵심 비즈니스 로직 ➡ 종단 관심사만 작성하도록 유도

예시) 나눗셈 프로그램 개발

• 핵심: 두 개의 숫자를 나누는 연산
• 주변: 0으로 나누는지 검사 (유효성 체크)

특징

• 반복적으로 나타나는 횡단 관심사를 모듈로 분리 후 적절한 시점에 주입
• 스프링의 중요 특징 중 하나 (별도의 복잡한 설정 없이 간편하게 기능 구현 가능)

AOP 적용 시점 (Advice)

• ⭐ Around (전 구역): 가장 많이 사용됨 (재정의)
• Before: 대상 메서드 실행 전
• After: 대상 메서드 실행 후 (정상 종료/예외 발생 무관하게 무조건 실행, final과 동일)
• AfterReturning: 메소드 정상 리턴 후
• AfterThrowing: 메소드 예외 발생 후

AOP 설계 순서

1. 구현할 횡단 관심사를 의미하는 어노테이션 생성
2. 어노테이션을 AOP로 등록 (@Aspect 어노테이션 사용)
3. 종단 관심사에 등록된 어노테이션 사용 (프록시 생성 및 동작)

전역 상태를 간단하고 효율적으로 관리할 수 있게 도와주는 상태 관리 라이브러리

메모리 기반 상태 관리를 제공하며 상태가 브라우저 메모리(RAM)에 저장되어 앱이 살아 있는 동안만 유지된다. 상태 유지를 위해 주로 로컬스토리지와 함께 사용된다.

Store

컴포넌트간의 데이터를 공유하기 위해선 상위 컴포넌트를 거쳐야 하는 Props Drilling을 없애고 컴포넌트간의 Store를 사이에 두어 여러 컴포넌트가 같은 데이터를 쉽게 보고 수정할 수 있는 중앙 저장소를 의미한다.

Zustand 주요함수

1. Create

State와 Action을 통합 정의할 수 있고, 반환되는 훅으로 상태 접근과 액션 호출을 동시에 처리할 수 있다. 또한 필요한 상태만 선택적으로 구독(subscribe)해 불필요한 리렌더링을 방지할 수 있습니다

2. Set

상태를 업데이트하는 함수로, create 함수 내부에서 사용됩니다. 기존 상태를 불변성을 유지하면서 부분적으로 변경할 수 있으며, 함수 형태로도 값을 갱신할 수 있어 복잡한 상태 계산도 가능합니다.

3. Persist

Zustand 상태를 브라우저의 로컬 스토리지(localStorage)나 세션 스토리지(sessionStorage)에 자동으로 저장하고 불러올 수 있게 해주는 미들웨어입니다. 페이지를 새로고침해도 상태가 유지되므로, 로그인 정보나 테마 설정 등 지속적인 상태 관리에 유용합니다.

결제 완료 처리 이후 예약 상태 불일치 문제

문제상황

• 결제 완료 요청이 처리된 이후에도 예약 상태가 변경되지 않아
결제 정보와 예약 상태 간 데이터 불일치 발생

해결 방법

• Service 계층에서 결제 저장과 예약 상태 변경을

  하나의 트랜잭션으로 통합

• @Transactional을 적용하여 결제 저장(Payment)과
예약 상태 변경(ReserveStatus.COMPLETED)을

   동일한 작업 단위로 처리

• 결제 완료 서비스 로직에서 서버 기준으로 상태를 검증한 뒤

  예약 상태를 변경하도록 개선

결과

• 결제와 예약 상태 변경이 항상 동시에 반영되어 데이터

  일관성 확보

• 중간 실패 시 전체 롤백이 보장되어 결제/예약 데이터

  불일치 문제 해결

결제 취소 시 결제가 완료되는 문제 트러블슈팅

1. 문제 상황

주차/장소 예약 후 결제 페이지에서
결제창(NICEPAY / PortOne)에서 X 버튼 또는 종료 버튼을 눌러 결제를 취소했음에도 불구하고,
프론트 화면에서는 '결제가 완료되었습니다.' 라는 메시지가 출력되며
서버에는 결제 완료로 저장되는 문제가 발생했다.

예약 테이블을 초기화한 상태에서도 동일한 현상이 재현되었다.

2. 원인 분석

프론트엔드 관점

• PortOne.requestPayment 호출 후
• 결제창을 닫아도 response 객체가 반환되는 경우가 있음
• response 존재 여부만으로 결제 성공으로 판단
• 그대로 결제 완료 API 호출

백엔드 관점

• 결제 완료 API는 요청이 오면 무조건 결제 완료 처리
• 실제 결제 성공 여부에 대한 검증 로직 부재

3. 핵심 원인 요약

서버는 결제창에서 사용자가 어떤 버튼(X, 종료, 완료)을 눌렀는지 알 수 없는데
프론트에서 결제 완료 API를 무조건 호출하고 있었다.

4. 해결 전략

구조는 유지하되, 프론트와 백엔드에서 최소한의 검증 로직을 추가했다.

5. 프론트엔드 해결

결제 결과 상태가 PAID인 경우에만 서버 API를 호출하도록 수정했다.

• 결제창 종료 또는 취소 시 서버 호출 차단
• 결제 완료 상태만 서버에 전달

6. 백엔드 해결

서버 기준 상태 검증

결제 완료 API에서 예약 상태가 결제 가능한 상태인지 검증했다.

• 예약 상태가 PENDING이 아닐 경우 결제 거부
• impUid 기준 중복 결제 차단

이를 통해 프론트 조작이나 중복 호출에도 안전하게 방어할 수 있도록 했다.

7. 최종 결론

• 결제 완료 여부는 프론트 이벤트가 아닌 서버 기준으로 판단해야 한다
• 프론트에서는 결제 성공 상태만 전달
• 서버에서는 예약 상태와 중복 여부로 최종 검증

이 구조를 통해 결제 취소 시 결제가 완료되는 문제를 안정적으로 해결했다.

8. 교훈

• 결제 시스템에서 프론트는 신뢰 대상이 아니다
• 결제 완료의 진실은 서버 한 곳에서만 판단해야 한다
• 요청이 왔다와 결제가 완료됐다는 완전히 다른 개념이다

Redux 클라이언트 상태 관리 전역 UI 상태, 로그인 정보 캐싱 및 비동기 직접 구현 React Query 서버 상태 관리 API 데이터 자동 캐싱 로딩/에러 상태 자동 제공 프론트에서 Fetch를 보내는 경우 fetch만 사용하는 경우 const [data, setData] = useState(null); const [loading, setLoading] = useState(true); const [error, setError] = useState(null);

useEffect(() => { fetch("/api/posts") .then(res => res.json()) .then(data => setData(data)) .catch(err => setError(err)) .finally(() => setLoading(false)); }, []); fetch + React Query const fetchPosts = async () => { const res = await fetch("/api/posts"); return res.json(); };

const { data, isLoading, isError } = useQuery({ queryKey: ["posts"], queryFn: fetchPosts, }); 리액트 쿼리의 장점

1. 서버 상태 관리에 특화 Redux와 달리 클라이언트 상태가 아닌 서버 상태 관리에 집중 API 응답 데이터의 생명주기(요청, 캐싱, 갱신)를 자동으로 관리
2. 캐싱을 자동으로 제공 동일한 요청에 대해 중복 API 호출을 방지 이전에 받아온 데이터를 캐시로 즉시 제공하여 UX 향상
3. 로딩 / 에러 상태를 자동 관리 isLoading, isError, error 상태를 기본 제공 Redux나 fetch처럼 상태 변수를 직접 만들 필요 없음
4. 보일러플레이트 코드 감소 Redux의 action, reducer, dispatch 불필요 순수 fetch 대비 코드량 대폭 감소
5. 중복 요청 및 경쟁 상태 방지 동일한 queryKey 요청은 하나만 실행 컴포넌트 여러 개에서 사용해도 안전 마무리 React Query는 단순한 데이터 요청 도구가 아니라, 서버 상태를 효율적으로 관리하기 위한 데이터 관리 라이브러리이다.

Redux나 순수 fetch로 직접 구현해야 했던 캐싱, 로딩·에러 처리, 중복 요청 방지 등의 기능을 자동화하여

프론트엔드 코드의 복잡도를 크게 줄여준다. 서버 데이터 중심의 애플리케이션에서는 React Query를 활용하는 것이 더 효율적인 선택이 될 수 있다.

📌 결제 페이지 트러블 슈팅 정리 (Recychool)

문제

/payment/1로 접근 시 결제 페이지가 빈 화면으로 렌더링됨

Swagger에서 /private/payment/page?reserveId=1 API는 정상 응답

원인

라우팅 방식 불일치

라우터: payment/:reserveId (path parameter)

프론트: useSearchParams()로 쿼리스트링(?reserveId=)을 읽고 있었음 → reserveId가 null로 전달됨

예약 ID 상태 누락

예약 조회 후 reserve state에 id를 저장하지 않아

결제 완료 요청 시 reserve.id가 undefined

해결

useSearchParams → useParams로 변경하여 path param에서 reserveId 추출

예약 조회 응답(PaymentPageResponseDTO)에서 reserveId를 reserve.id로 state에 저장

데이터 로딩 전 빈 화면 방지를 위해 간단한 로딩 가드 추가

결과

결제 페이지 정상 렌더링

예약 조회 → 결제 요청 → 결제 완료 흐름 정상 동작

🔧 결제 기능 트러블 슈팅 (PortOne Browser SDK v2)

1. 문제 상황

React 결제 페이지에서 PortOne Browser SDK(v2)를 사용하여
일반 결제 / 카카오페이 / 토스페이 결제를 구현하던 중,
토스페이 결제 시 아래와 같은 에러가 발생하였다.

POST https://checkout-service.prod.iamport.co/api/prepare/v2 400 (Bad Request)

결제 실패: 결제 창 호출에 실패하였습니다.
토스페이먼츠의 경우 간편 결제 수단은 필수 입력입니다.

에러는 PortOne.requestPayment() 호출 직후 발생했으며,
브라우저 SDK 내부의 preparePayment 단계에서 실패하였다.

2. 원인 분석

초기 구현에서는 결제 수단에 따라 다음과 같이 처리하고 있었다.

• 일반 결제
  • payMethod: "CARD"
• 카카오페이 / 토스페이
  • payMethod: "EASY_PAY"

그러나 PortOne Browser SDK v2에서는
payMethod: "EASY_PAY"를 사용할 경우,

반드시 어떤 간편결제 수단인지(easyPayProvider)를 함께 전달해야 한다.

특히 토스페이먼츠 채널에서는
easyPayProvider가 누락될 경우 400 Bad Request 에러가 발생한다.

즉, 문제의 원인은 다음과 같았다.

• payMethod: "EASY_PAY"만 전달됨
• easyPayProvider 옵션 누락 ❌

3. 해결 방법

3-1. 결제 수단별 옵션을 명확히 분리

결제 수단에 따라 아래 항목을 명확히 분리하였다.

• channelKey
• payMethod
• easyPayProvider

const getPortOnePayType = () => {
  if (payType === "GENERAL") {
    return {
      channelKey: process.env.REACT_APP_PORTONE_CHANNEL_CARD,
      payMethod: "CARD",
      easyPayProvider: null,
    };
  }

  if (payType === "KAKAOPAY") {
    return {
      channelKey: process.env.REACT_APP_PORTONE_CHANNEL_KAKAOPAY,
      payMethod: "EASY_PAY",
      easyPayProvider: "KAKAOPAY",
    };
  }

  return {
    channelKey: process.env.REACT_APP_PORTONE_CHANNEL_TOSSPAY,
    payMethod: "EASY_PAY",
    easyPayProvider: "TOSSPAY",
  };
};

3-2. requestPayment 호출 시 조건부 옵션 추가

payMethod가 EASY_PAY일 때만
easyPay 옵션을 조건부로 추가하도록 수정하였다.

const paymentRequest = {
  storeId: process.env.REACT_APP_PORTONE_STORE_ID,
  channelKey,
  paymentId,
  orderName,
  totalAmount,
  currency: "CURRENCY_KRW",
  payMethod,
  customer: {
    fullName: user.name,
    email: user.email,
    phoneNumber: user.phone,
  },
};

if (payMethod === "EASY_PAY") {
  paymentRequest.easyPay = { easyPayProvider };
}

const response = await PortOne.requestPayment(paymentRequest);

4. 결과

• 결제 채널별 요구사항을 정확히 반영하여 결제창 정상 호출
• 일반 결제 / 카카오페이 / 토스페이 모두 정상 동작 확인
• 결제 실패 원인을 명확히 분리하여 트러블 슈팅 문서로 정리 가능

5. 정리

• PortOne Browser SDK v2에서는
  EASY_PAY 사용 시 easyPayProvider가 필수
• 에러 메시지는 추상적이므로
  네트워크 탭과 SDK 요구사항을 함께 확인해야 함
• 결제 수단별 설정을 명확히 분리하는 것이 중요

PortOne 결제 ID 미저장

우리 시스템 결제 UID 미저장

도커란?

• 컨테이너를 생성·구동·배포할 수 있는 기능을 제공하는 리눅스 기반 오픈 소스 가상화 플랫폼
• 도커 클라이언트, 도커 서버, 이미지, 컨테이너, 레지스트리, 볼륨, 네트워크로 구성

구성 요소

도커 클라이언트

• 리눅스 Shell과 유사한 역할
• 사용자의 명령을 도커 서버로 전달

도커 서버

• 도커 클라이언트로부터 명령을 받아 이미지·컨테이너·볼륨·네트워크 등을 관리하는 데몬 수행

이미지 ⭐

• 도커 허브에서 가져오거나 직접 제작 가능
• 운영체제 커널은 포함되지 않으며, 호스트 OS를 공유
• 읽기 전용 구조(불변성)
• 컨테이너 실행 기반으로 사용

컨테이너

• 이미지를 실제로 실행한 독립 프로세스 단위
• 고유한 IP를 가지며 개별 시스템처럼 동작

레지스트리

• 이미지 저장소
• 기본 설정은 도커 허브 사용

볼륨

• 컨테이너 데이터를 호스트에 저장하는 마운트 기능
• 컨테이너 삭제 후에도 볼륨 데이터 유지

네트워크

• 컨테이너 간 통신 및 네트워크 분리 기능 제공

도커를 사용하는 이유 ⭐

• 서버 장비 수만큼 물리적인 자원과 인력, 비용이 증가하는 문제를 줄일 수 있음
• 컨테이너 기반으로 환경을 이식성 있게 관리 가능

주요 명령어

기존 RDB 설계 방식의 문제

관계형 DB에서는 상속 개념이 없기 때문에, 공통된 속성이 있어도 테이블마다 반복해서 작성해야 한다.

기존 테이블 예시

책

옷

운동기구

→ 공통 필드(상품번호, 이름, 가격)가 반복됨

슈퍼·서브 타입 모델링(ER 모델)

공통 속성을 부모(슈퍼) 테이블로 올리고 자식(서브)이 상속받는 구조

상품(슈퍼테이블)

서브 테이블

• 서브 테이블의 PK는 부모 테이블의 PK를 그대로 사용 → PK이자 FK

책

옷

운동기구

※ 이 구조는 논리적 모델이며, 실제 물리 구현은 전략에 따라 달라짐

JPA 상속 매핑 전략 3가지

1) 조인 전략(Joined)

• 부모·자식 각각 테이블 생성
• 자식 테이블은 부모 테이블의 PK를 받아 FK + PK로 사용
• 조회 시 조인 연산이 자주 발생
• 테이블 구조가 명확하여 정규화 관점에서 유리

2) 단일 테이블 전략(Single Table)

• 하나의 테이블에 모든 엔티티 데이터를 저장
• 공통 속성 외의 필드는 NULL 허용

상품(단일 테이블)

• 쿼리가 단순하지만, 불필요한 NULL 필드가 증가하여 공간 낭비

3) 구현 클래스마다 테이블 전략(Table Per Class)

• 엔티티마다 테이블 생성
• 일반적인 RDB 설계와 유사하지만
  중복 데이터가 많고 쿼리 비용이 높아 비추천

JPA 기본 Fetch 전략

→ 특별히 항상 함께 조회되는 관계가 아니면 지연 로딩 권장

JPA 데이터 타입 종류

1. 엔터티 타입

   • 식별자(PK)를 가지며 독립적으로 존재

2. 임베디드 타입(복합 값 타입)

   • 개발자가 직접 정의한 타입
   • 예) 주소 정보

class Address {
    private String address;
    private String addressDetail;
    private String zipcode;
}

→ 엔터티에서 아래처럼 통합 표현 가능

private Address address;

3. 컬렉션 값 타입
   • 값 타입을 컬렉션 형태로 보관하는 구조

핵심 정리

• 기존 RDB는 상속 개념이 없어 중복된 설계를 피하기 어려움
• JPA는 상속 매핑 전략을 통해 객체 모델과 DB 간 패러다임 차이를 해소
• 사용 목적에 따라 상속 전략을 선택하면 설계 품질과 유지보수성이 향상됨

JPA 상속 매핑 = 객체지향 설계 + DB 물리 모델링 간 격차 해소

Hibernate ddlAuto 옵션

영속성 컨텍스트(PersistenceContext)

JPA는 트랜잭션 기반으로 동작하며, 영속성 컨텍스트를 통해 엔티티를 관리한다.
EntityManager가 이 영역을 관리하며, .persist()를 통해 엔티티를 등록할 수 있음

동작 흐름

1. 엔티티를 영속성 컨텍스트로 로딩
2. 1차 캐시에 저장 → 영속 상태
3. 변경 쿼리를 쓰기 지연 저장소에 보관
4. 트랜잭션 종료 시 flush() 실행 → DB에 실제 SQL 반영
5. commit 완료 시 DB에 최종 반영

엔티티의 4가지 상태

Repository

• 애플리케이션과 DB 사이에서 데이터를 읽고 쓰는 역할을 담당하는 계층
• Spring Data JPA에서는 Repository 인터페이스 기반으로 구현

연관관계 매핑(Relation Mapping)

테이블 구조

USER

BOARD

객체 구조

public class User {
    private Long id;
    private String userEmail;
    private String userPassword;
    private String userName;
    private Integer userAge;
}

public class Board {
    private Long id;
    private String boardTitle;
    private String boardContent;
    private User user; // 작성자
}

연관관계와 방향성

방향(Direction)

• 객체는 참조를 통해 관계를 표현하기 때문에, DB와 달리 방향 개념이 존재함

다중성(Multiplicity)

항상 다(N) 쪽에 외래키 존재

연관관계의 주인

양방향 관계일 경우
둘 중 한 엔티티가 연관관계의 주인이 되며, 주인이 FK를 관리한다

JPA에서는 주인 아닌 쪽은 읽기 전용 역할을 하게 된다

핵심 정리

• ddlAuto는 개발 단계에서 유용하지만 운영 환경에서는 주의 필요
• 영속성 컨텍스트는 JPA의 기반 메커니즘으로 엔티티 상태를 관리
• 연관관계 매핑은 테이블 구조를 객체 중심으로 해석해 반영하는 과정
• JPA는 객체지향 코드와 관계형 DB 간의 간극을 줄여 유지보수성을 높여줌

JPA = 객체 중심 + 연관관계 기반 설계 + 영속성 관리 + SQL 절감

ORM이란?

• 객체지향 언어에서 사용하는 객체와 관계형 DB의 테이블을 서로 연결해주는 기술
• 자바의 객체 구조와 관계형 DB는 구조가 다르기 때문에 그대로 사용하면 객체지향적인 코드의 장점을 살리기 어렵다
• ORM은 이 문제를 해결하기 위해 객체 중심 설계가 가능하도록 매핑 기능을 제공하는 기술

MyBatis는 SQL과 인터페이스를 매핑하지만,
ORM은 객체(클래스) 와 DB 테이블을 매핑한다는 점이 가장 큰 차이

Hibernate

• ORM 기술을 직접 구현해놓은 대표적인 오픈소스 프레임워크
• JPA를 기반으로 동작하는 실질적인 구현체 역할

JPA(Java Persistence API)

• 자바 진영에서 ORM을 사용하기 위한 표준 명세
• JPA는 직접 기능을 제공하는 것이 아니라 인터페이스(규약) 만 제공하며
  실제 동작은 Hibernate 같은 ORM 프레임워크가 수행

프론트에서 jQuery 의존성이 제거되면서 React 기반으로 전환된 사례와 유사
특정 구현체에 의존하지 않도록 추상화된 표준을 두는 방식

Spring Data JPA

• JPA 기반의 모듈
• Repository 인터페이스만 구현하면 기본적인 CRUD 기능이 자동 제공
• DB 접근 코드가 간단해지는 장점이 있지만 내부 동작이 추상화되어 있어
  문제가 발생하면 원리를 모르면 해결하기 어려움
  → ORM 개념 먼저 학습하는 것이 안전

JPA를 사용하는 이유

1. 객체와 관계형 DB 패러다임 불일치 문제

자바는 객체지향 언어지만, 데이터베이스는 절차적으로 데이터를 저장
구조가 다르다 보니 객체지향의 장점인 상속, 다형성, 캡슐화를 제대로 활용하기 어려움

예를 들어 사람 데이터를 확장해보면

공통 속성(슈퍼 테이블)

학생 테이블

| 번호(FK, PK) | 학년 | 등급 |

직장인 테이블

| 번호(FK, PK) | 경력 | 직급 |

• DB에서는 슈퍼 엔터티와 서브 엔터티로 나누어 관리해야 함
• insert 시 두 테이블에 값을 저장해야 하는 경우도 생김
• 하지만 자바에서는 Student extends Person 방식으로 상속 후 업캐스팅만 하면 해결
  → JPA는 이 패러다임 차이를 줄여주는 역할

2. 연관관계 처리 방식 차이

RDB의 연관관계

• FK(외래키)를 통해 관계를 맺음
• JOIN으로 다른 테이블의 데이터를 연결해 조회

객체의 연관관계

• 객체는 참조를 통해 접근

class Board {
    User user; // 작성자
}

자바에서는 new Board().getUser()는 가능하지만
반대로 User에서 Board로 바로 접근할 수 있는 구조는 자동 제공되지 않음

→ JPA는 이러한 관계를 객체스럽게 표현할 수 있도록 매핑 기능을 제공

3. 객체 그래프 탐색

• 객체 지향의 핵심은 참조를 따라가며 객체를 탐색하는 것

예시 구조

File → Board → User → UserProfile
           |
         Reply

new Board().getUser().getUserProfile();

• SQL 중심 개발에서는 쿼리를 어디까지 작성했는지(XML mapper 확인) 알지 못하면
  어느 객체까지 탐색 가능한지 알 수 없다
• 결과적으로 예상치 못한 NullPointerException이 발생하기 쉬움
• JPA는 이 객체 그래프 탐색을 자연스럽게 지원

정리

• ORM은 객체와 DB 테이블 간의 괴리를 줄여주는 기술
• Hibernate는 ORM의 대표 구현체
• JPA는 ORM 사용을 위한 표준
• Spring Data JPA는 이를 더 쉽게 사용할 수 있도록 한 모듈
• JPA를 사용하면 상속, 연관관계, 객체 그래프 탐색 등 객체지향적인 설계를 유지하면서 DB와 연동 가능

ORM = 객체 중심 설계 + SQL 의존성 감소 + 유지보수성 증가