✅ 특징

• 크기 고정
• 인덱스로 접근 (O(1))
• 중복 허용
• 순서 유지

int[] arr = new int[5];
String[] words = new String[3];

언제 쓰나?

• 데이터 개수가 처음부터 명확할 때
• 성능이 중요한 경우

단점

• 크기 변경 불가
• 중복 제거, 정렬 로직을 직접 구현해야 함

👉 코테에서는 입력 개수가 유동적이면 잘 안 씀

2️⃣ List – 순서가 있는 자료들의 집합

대표 구현체

• ArrayList
• LinkedList

List<String> list = new ArrayList<>();

✅ 특징

• 입력 순서 유지
• 중복 허용
• 크기 자동 조절
• 정렬 가능

Collections.sort(list);

언제 쓰나?

• 입력 순서가 중요할 때
• 정렬이 필요한 문제

👉 코테에서 가장 많이 쓰는 자료형

3️⃣ Set – 중복을 허용하지 않는 집합

대표 구현체

Set<String> set = new HashSet<>();

✅ 특징

• 중복 자동 제거
• 인덱스 없음

언제 쓰나?

• 중복 제거가 목적일 때
• "같은 값이 있나?"만 중요할 때

4️⃣ Map – Key와 Value의 관계 표현

Map<String, Integer> map = new HashMap<>();

✅ 특징

• Key는 중복 ❌
• Value는 중복 ⭕
• 순서 보장 X (기본)

대표 구현체

언제 쓰나?

• 빈도수 계산
• 이름 → 점수 같은 매핑

👉 "카운팅 문제"의 거의 정답 자료형

5️⃣ 정렬 관점에서 한 번에 정리

6️⃣ for-each 문과 자료형의 관계

for (String s : list) {
    System.out.println(s);
}

• List, Set 모두 가능
• 내부적으로 Iterator 사용
• 값을 읽는 용도에 적합

❌ 반복 중 컬렉션 구조 변경 불가

7️⃣ 코테에서 빠르게 선택하는 기준

• 중복 제거 → Set
• 정렬 필요 → List
• 순서 유지 출력 → List
• Key-Value 관계 → Map
• 성능 최우선 + 고정 크기 → Array

1. 현재 redis 세팅(단일객체)

정보를 담아 둘 Redis 객체가 하나뿐인 현재는 Redis 서버가 다운되면 refreshToken을 통한 인증(연장) 마비, 예약된 테이블을 조회할 수 있게 해주는 실시간 서비스 마비 등 프로그램에 치명적인 영향을 끼치는 상태이다.

2. 대처방안

• Redis Sentinel을 사용하여 고가용성 구조로 전환

  고가용성(High Availability, HA) 구조는 시스템이 장애 상황에서도 서비스를 지속적으로 제공할 수 있도록 설계된 아키텍처를 의미한다.

※ windows에서는 redis sentinel 구성설정을 지원하지 않으므로 Docker-redis를 이용한 sentinel 빌드를 하기로 함

3. 진행순서

1️⃣ Root(프로젝트 외부)에 Redis Sentinel을 설정파일을 담을 디렉토리, docker-compose.yml생성

• docker-compose.yml

  version: '3'
  

services:

redis-master: image: redis:7 container_name: redis-master hostname: redis-master ports: - "6379:6379" volumes: - ./master/redis.conf:/usr/local/etc/redis/redis.conf - master-data:/data command: ["redis-server", "/usr/local/etc/redis/redis.conf"] networks: - redis-network healthcheck: test: ["CMD", "redis-cli", "ping"] interval: 5s timeout: 3s retries: 5

redis-replica: image: redis:7 container_name: redis-replica hostname: redis-replica ports: - "6380:6379" depends_on: redis-master: condition: service_healthy volumes: - ./replica/redis.conf:/usr/local/etc/redis/redis.conf - replica-data:/data command: ["redis-server", "/usr/local/etc/redis/redis.conf"] networks: - redis-network

sentinel1: image: redis:7 container_name: redis-sentinel1 hostname: redis-sentinel1 ports: - "6381:26379" depends_on: redis-master: condition: service_healthy volumes: - ./sentinel1:/usr/local/etc/redis command: ["redis-sentinel", "/usr/local/etc/redis/sentinel.conf"] networks: - redis-network restart: on-failure

sentinel2: image: redis:7 container_name: redis-sentinel2 hostname: redis-sentinel2 ports: - "6382:26379" depends_on: redis-master: condition: service_healthy volumes: - ./sentinel2:/usr/local/etc/redis command: ["redis-sentinel", "/usr/local/etc/redis/sentinel.conf"] networks: - redis-network restart: on-failure

sentinel3: image: redis:7 container_name: redis-sentinel3 hostname: redis-sentinel3 ports: - "6383:26379" depends_on: redis-master: condition: service_healthy volumes: - ./sentinel3:/usr/local/etc/redis command: ["redis-sentinel", "/usr/local/etc/redis/sentinel.conf"] networks: - redis-network restart: on-failure

volumes: master-data: replica-data:

networks: redis-network: driver: bridge

### 2️⃣ 각각의 디렉토리에 설정을 담은 .conf파일 생성
>- /master/redis.conf

port 6379 bind 0.0.0.0 protected-mode no replica-announce-ip 127.0.0.1 replica-announce-port 6379 appendonly yes appendfilename "appendonly.aof"

>- /replica/redis.conf

port 6379 bind 0.0.0.0 protected-mode no

Replica announce 설정 추가

replica-announce-ip 127.0.0.1 replica-announce-port 6380 appendonly yes appendfilename "appendonly.aof"

Master는 Docker 내부 IP 유지

replicaof 172.19.0.2 6379 slave-priority 100 replica-read-only yes

>- /sentinel1/sentinel.conf
```conf
port 26379
bind 0.0.0.0
protected-mode no
sentinel resolve-hostnames no
sentinel announce-hostnames no
# IP 주소로 모니터링 (Master IP를 확인 후 입력)
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel announce-ip "127.0.0.1"
sentinel announce-port 6381
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 10000
sentinel deny-scripts-reconfig yes

sentinel2,3은 포트번호 이외에 모두 동일(6381,6382,6383순)

redis의 root로 이동후 실행

docker desktop을 먼저 실행 후 root디렉토리에서

# docker-compose.yml에 정의된 컨테이너들을 백그라운드(-d)에서 실행
1. docker-compose up -d

# 현재 실행 중인 도커 컨테이너 목록과 상태를 출력
2. docker ps

# 'sentinel1' 서비스의 로그를 실시간(-f)으로 확인
3. docker-compose logs -f sentinel1

# 'redis-replica' 컨테이너에 접속(-it)하여 
# redis-cli를 실행하고, 복제(replication) 상태 정보를 출력
4. docker exec -it redis-replica redis-cli info replication
4-1. docker stop redis-master
4-2. docker exec -it redis-replica redis-cli info replication

1. 실행된 docker 컨테이너들

2. 실행 중인 컨테이너 목록과 상태

3. 실시간 확인이 가능한 로그

4. master를 종료하자 역할이 뒤바뀐 replica와 master

이후 docker stop redis-replica명령어로 replica를 종료해 본 결과 master가 다시 master 역할로 돌아오는 것을 확인 하였다.

회고

현재 상태에서는 Docker가 실행 중일 때만 Redis HA가 작동하므로 추후 cloud등의 서비스에 Redis Sentinel환경을 구축하여 항시 작동하는 로직이 추가되어야 할 것 같다.

또한 하지만 두 개의 컨테이너가 모두 종료되는 경우 또 다시 서비스에 차질이 생기므로 분산환경에의 redis객체 구축이 필요할 것으로 보인다

💻 ResponseEntity

HTTP 응답 전체를 직접 구성할 수 있는 Spring의 클래스

ResponseEntity가 제어할 수 있는 3요소

• HTTP Status Code
• HTTP Headers
• Response Body (JSON, String, Object)

왜 ResponseEntity를 사용하는가

1️⃣ HTTP status코드를 정확히 내려줄 수 있음

리소스 생성 시 201 상태로 명확하게 응답예시

return ResponseEntity.status(HttpStatus.CREATED).body(data);

2️⃣ 응답 Header 세팅이 필요할 때

JWT, Cookie기반 인증시 필수적

return ResponseEntity.ok()
        .header("Set-Cookie", cookie)
        .body(userInfo);

3️⃣ body에 객체를 자유롭게 담을 수 있음

담긴 객체는 자동으로 JSON문자열로 변환 됨

return ResponseEntity.ok(new UserResponse(...));

4️⃣ 에러 핸들링을 명확하게 할 수 있음

에러 상황에서 적절한 상태 코드와 함께 커스텀 에러 메시지 전달이 가능

// 404 에러 응답 예시
return ResponseEntity.status(HttpStatus.NOT_FOUND)
        .body(new ErrorResponse("USER_NOT_FOUND", "해당 사용자를 찾을 수 없습니다."));

// 400 에러 응답 예시
return ResponseEntity.badRequest()
        .body(new ErrorResponse("INVALID_INPUT", "이메일 형식이 올바르지 않습니다."));

정리

다음과 같은 상황에서는 ResponseEntity는 선택이 아닌 필수이다.

• 인증/인가 구현 시: JWT 토큰이나 세션 쿠키를 헤더에 담아 전달
• RESTful API 설계 시: 리소스 생성(201), 수정(200), 삭제(204) 등 정확한 상태 코드 반환
• 에러 핸들링 시: 4xx, 5xx 에러와 함께 커스텀 에러 메시지 전달

단순히 데이터만 반환하는 @ResponseBody와 달리, ResponseEntity는 HTTP 통신의 모든 측면을 제어할 수 있게 해주기 때문이다.

프로젝트를 진행하며 다루었던 JWT에 대한 복습 겸 정리를 해보려고 한다.

🧩 JWT란?

Json Web Token의 약자로, 사용자 인증/인가 정보를 JSON 형식으로 담아 클라이언트와 서버가 주고받는 서명된 토큰

주요 특징

• Stateless: 서버가 세션을 저장하지 않아도 됨
• 클라이언트가 매 요청마다 토큰을 보내서 인증
• 토큰 변조를 서명(Signature)으로 방지

📦 JWT 구조 (3가지 파트)

JWT는 .으로 구분된 3개의 Base64Url 문자열로 구성

xxxxx.yyyyy.zzzzz
Header.Payload.Signature

1️⃣ Header (헤더)

{
  "alg": "HMAC SHA256",
  "typ": "JWT"
}

• alg: 서명 알고리즘 (HMAC SHA256, RS256 등)
• typ: 토큰 타입 (JWT)

→ 이 JSON을 Base64Url로 인코딩한 것이 헤더 부분이다.

2️⃣ Payload (페이로드)

토큰에 담긴 실제 데이터(클레임, Claims)

대표적인 클레임

• sub: 사용자 식별자 (주체, Subject)
• iat: 발급 시간 (Issued At)
• exp: 만료 시간 (Expiration)

{
  "sub": "user123",
  "role": "USER",
  "exp": 1700000000
}

→ Header와 마찬가지로 Base64Url 인코딩

※ Payload는 암호화가 아니라 인코딩이므로 민감 정보(비밀번호 등)를 절대 넣지 않도록 한다.

3️⃣ Signature (서명)

토큰 위변조 방지를 위한 서명 부분입니다.

예시: HS256 알고리즘

HMACSHA256(
    Base64UrlEncode(header) + "." + Base64UrlEncode(payload),
    secret
)

서버는 이 Signature를 검증해 토큰이 조작되지 않았는지 확인함

💡 Secret Key 관리

서명에 사용되는 secret은 보안상 매우 중요하므로, 코드에 직접 작성하지 않고 application.properties 또는 application.yml 파일에서 관리

✅ JWT의 장점

• 무상태(Stateless): 서버 확장 용이, 스케일 아웃 쉬움
• HTTP Header에 실어서 보내기 편함
• 서버 저장소 불필요 → 로드 밸런싱에 유리
• MSA(마이크로서비스) 환경에 적합

❗ 단점 및 주의사항

운이 좋게도 내 이름으로 된 도메인이 남아있어 연 2만원 정도의 금액을 주고 도메인을 구매했다.

1️⃣ repository pages탭에 구매한 도메인 입력

도메인 구매 후 다음과 같이 Custom Domain을 설정하는 것 만으로는 바로 프로젝트 출력이 되지 않는 것을 확인했다.

2️⃣ 도메인에 DNS레코드 할당

깃허브 공식문서(https://docs.github.com/en/pages)에서 지원하는 DNS레코드 값을 도메인을 구매한 서비스에 할당해 주어야 한다.

할당된 DNS레코드 모달

DNS Check가 완료된 후 Page Tab

3️⃣ package.json수정

원래 쓰던 도메인을 새로 구매한 도메인으로 변경

4️⃣ 프로젝트 재빌드

5️⃣ 경로수정(트러블 슈팅)

도메인 할당을 완료했으나 경로때문에 React 프로젝트를 읽어오지 못하는 상황 발생

경로 문제인 줄 알았던 페이지가 이전 Cache의 영향을 받은게 원인이었음을 확인, 아래의 방법으로 캐시 초기화 후 재빌드 해서 해결

원하는 도메인에 포트폴리오가 나오는 것을 확인 할 수 있었다.

🛠️ BugFix

yml에 custom된 도메인을 추가하여 빌드 할 떄마다 초기화되는 버그를 픽스

접근 제어자(Access Modifier)란 👉 클래스, 필드(변수), 메서드, 생성자에 대해 “어디까지 접근을 허용할지 범위를 정하는 키워드”이다.

접근제어자 사용 범위

• 접근 제어자는 클래스, 필드(변수), 메서드, 생성자에 적용할 수 있으며,
• 각 요소의 외부 접근 가능 범위를 제어해 객체의 구조와 데이터를 보호한다.

🗒️ Java 접근 제어자 정리 (Access Modifier)

1️⃣ public — 완전 개방형

어디서든 접근 가능

• 패키지 밖이든
• 클래스 밖이든
• 다른 프로젝트 모듈이든 → 전부 접근 가능

public int age;

✅ 특징

• 접근 제한 없음
• 공개 API 만들 때 주로 사용
• 너무 남발하면 캡슐화 깨져서 유지보수 힘들어짐

👉 가장 넓은 접근 범위

2️⃣ protected — 조금 좁혀진 공개 범위

protected int score;

✅ 특징

• 같은 패키지 → 바로 접근 가능
• 다른 패키지 → 상속받은 자식 클래스만 접근 가능
• 👉 상속 관계에서 자주 사용

3️⃣ default — 아무것도 안 쓰는 경우

패키지 전용 접근

키워드가 없어서 “default 접근제어자”라고 부름

int level;   // default

✅ 특징

• 같은 패키지 안에서는 접근 가능
• 다른 패키지에서는 절대 접근 불가

4️⃣ private — 가장 폐쇄적

오직 같은 클래스 내부에서만 접근 가능

private String password;

✅ 특징

• 객체 내부에서만 사용
• 외부에서 절대 접근 불가
• 캡슐화할 때 가장 많이 씀 → getter / setter로 접근 조절

👉 가장 좁은 접근 범위

🔥 접근 범위 정리표

💡 어디에 어떻게 쓰면 좋냐?

• ✅ private → 거의 모든 필드(속성) → 외부에서 막 써버리면 객체 무너짐

• ✅ public → 진짜 외부에 공개해야 할 메서드

• ✅ protected → 자식 클래스에 기능 열어주고 싶을 때

• ✅ default → 패키지 단위로 묶어서 관리할 때

자바에서 생성자(Constructor)는 객체가 "태어날 때" 처음 세팅을 담당.

1️⃣ 생성자

생성자는 클래스로부터 인스턴스(객체)를 만들 때 무조건 호출되는 '객체 초기화 메서드' 객체를 쓰기 전에 필요한 초기 상태를 맞춰주는 역할

2️⃣ 생성자의 주요 특징들

특징 내용 이름 클래스 이름이랑 대소문자까지 똑같아야 함 반환 타입 return값이 없음(void도 안씀) 호출 시점 new 키워드로 객체 생성시 한 번만 호출 목적 인스턴스 변수(필드)의 초기값을 할당해주기 위함

3️⃣ 디폴트 생성자 (Default Constructor)

생성자를 만들지 않을 경우 자바 컴파일러가 알아서 매개변수 없는 '디폴트 생성자'를 생성해 줌 이 디폴트 생성자가 호출되면, 변수들은 타입별 기본값으로 초기화됨. 변수 타입 기본값 (초기값) 참조 타입 (String, Class 등) null (아무것도 없음) 정수형 (int, short, long 등) 0 실수형 (double, float) 0.0 논리형 (boolean) false 문자형 (char) '\u0000' (빈 문자)

4️⃣ 생성자 사용 예시 (코드)

직접 생성자를 만들면, 객체를 만들 때 꼭 필요한 값을 넣어주도록 강제할 수 있음

public class Car {
    String model;
    int year;

    // 우리가 만든 생성자 (파라미터 있음)
    public Car(String modelName, int manufacturedYear) {
        this.model = modelName;      // 초기값 세팅
        this.year = manufacturedYear; // 초기값 세팅
        System.out.println("🚗 " + model + " 객체 생성 완료!");
    }

    // 참고: 이 생성자를 만들면 기본 생성자는 자동으로 안 생김
}

객체 만들기:

// 객체 만들자마자 생성자 호출되고 초기화됨
Car myCar = new Car("테슬라 모델 Y", 2024);
// 출력 결과: 테슬라 모델 Y 객체 생성

결론: 생성자는 자바에서 객체가 제대로 된 초기 상태를 갖도록 보장하는 필수적인 "초기화 담당"

Java를 처음 배우면서 가장 이해하기 힘들었던 개념이 객체(지향)이었다. 오늘은 그 객체와 더불어 java의 class에 대한 정리도 같이 하기로 했다.

🤔 객체(Object)란?

객체(Object)는 쉽게 말해 현실 세계의 사물이나 개념을 코드로 표현한 것이다.

예를 들어, 여러분 앞에 스마트폰이 있다고 생각해보자. 이 스마트폰은:

• 속성(특징)을 가지고 있다: 색상, 크기, 배터리 용량, 모델명 등
• 동작(행동)을 할 수 있다: 전화 걸기, 문자 보내기, 사진 찍기 등

프로그래밍에서 객체도 마찬가지다. 객체는 데이터(속성)와 그 데이터를 처리하는 메서드(동작)를 하나로 묶어놓은 것이다.

중요한 점은, 한 번 생성된 객체는 메모리 상에 실체로서 존재하게 되고, 프로그램 어디서든 그 객체를 불러내서 재사용할 수 있다는 것이다. 이게 바로 객체의 핵심이다.

🤔 클래스(Class)는?

클래스는 객체를 만들기 위한 설계도 또는 틀이라고 생각하면 된다.

붕어빵을 만든다고 생각해보자:

• 붕어빵 틀 = 클래스
• 실제로 만들어진 붕어빵 = 🐟객체

하나의 틀(클래스)로 여러 개의 붕어빵(객체)을 찍어낼 수 있는 것처럼, 하나의 클래스로 여러 개의 객체를 만들 수 있다.

실제 코드로 정리 💻

1. 클래스 정의

public class Smartphone {
    // 속성 (필드, 멤버 변수)
    String brand;      // 브랜드
    String model;      // 모델명
    String color;      // 색상

    // 동작 (메서드)
    void call(String number) {
        System.out.println(number + "로 전화를 겁니다.");
    }

    void sendMessage(String message) {
        System.out.println("메시지 전송: " + message);
    }
}

2. 객체 생성, 사용

public class Main {
    public static void main(String[] args) {
        // 객체 생성 (인스턴스화) - 이 순간 메모리에 실체가 만들어진다!
        Smartphone myPhone = new Smartphone();

        // 속성에 값 할당
        myPhone.brand = "Samsung";
        myPhone.model = "Galaxy S24";
        myPhone.color = "Black";

        // 이제 이 객체(myPhone)를 언제든지 불러서 사용할 수 있다
        myPhone.call("010-1234-5678");
        myPhone.sendMessage("안녕하세요!");

        // 다른 메서드에서도 사용 가능
        usePhone(myPhone);

        // 또 다른 객체 생성 - 완전히 별개의 실체
        Smartphone friendPhone = new Smartphone();
        friendPhone.brand = "Apple";
        friendPhone.model = "iPhone 15";
        friendPhone.color = "White";

        // 같은 클래스로 만들었지만 서로 다른 객체!
        // myPhone과 friendPhone은 각각 독립적으로 존재한다
        System.out.println("내 폰: " + myPhone.model);
        System.out.println("친구 폰: " + friendPhone.model);
    }

    // 다른 메서드에서도 객체를 전달받아 사용 가능!
    static void usePhone(Smartphone phone) {
        phone.sendMessage("다른 메서드에서도 사용 가능!");
    }
}

3. 생성자(Constructor) 활용하기

매번 속성을 하나씩 설정하기 번거로우니, 생성자를 사용하면 객체를 만들 때 바로 값을 넣을 수 있다.

public class Smartphone {
    String brand;
    String model;
    int battery;
    String color;

    // 생성자
    public Smartphone(String brand, String model, String color) {
        this.brand = brand;
        this.model = model;
        this.color = color;
        this.battery = 100;  // 초기 배터리는 100%
    }

    void call(String number) {
        System.out.println(number + "로 전화를 겁니다.");
    }
}

// 사용 예시
Smartphone myPhone = new Smartphone("Samsung", "Galaxy S24", "Black");

📚 용어 정리

• 클래스(Class): 객체를 만들기 위한 설계도
• 객체(Object): 클래스를 바탕으로 만들어진 실체
• 인스턴스(Instance): 객체와 같은 의미 (클래스로부터 만들어진 것)
• 필드(Field): 객체의 속성, 데이터 (brand, model 등)
• 메서드(Method): 객체의 동작, 기능 (call, sendMessage 등)
• 생성자(Constructor): 객체 생성 시 호출되는 특별한 메서드

왜 객체지향을 사용할까?

1️⃣ 코드 재사용성

한 번 만든 클래스를 여러 곳에서 재사용할 수 있다.

2️⃣ 유지보수 용이

관련된 데이터와 기능이 하나로 묶여있어 수정이 쉽다.

3️⃣ 현실 세계 반영

실제 세계의 사물을 코드로 표현하니까 이해하기 쉽다.

4️⃣ 협업에 유리

팀원들과 역할을 나눠서 각자 다른 클래스를 개발할 수 있다.

마무리

처음에는 “왜 굳이 이렇게 복잡하게?”라는 생각이 들 수 있다. 나도 그랬다. 하지만 프로그램의 규모가 커질수록, 그리고 실제 프로젝트를 해보면 객체지향의 필요성과 편리함을 자연스럽게 느끼게 된다.

핵심은 "관련된 것들을 하나로 묶는다"는 것이다. 스마트폰 관련 정보와 기능을 Smartphone 클래스 하나에 모아두면, 나중에 찾기도 쉽고 관리하기도 편하다.

개발하다 보면 Google Maps API, Toss Payments API, Open API… 이런 식으로 API라는 말을 정말 많이 듣는다. 하지만 그 단어가 정확히 어떤 의미에서 쓰이고, 왜 필요한 건지 한 번쯤은 제대로 짚고 넘어갈 필요가 있었다.

API라는 개념에 접근하기전에 인터페이스라는 것에 대해 먼저 알고 넘어가기로 했다. API는 Application Programming Interface, 결국 Interface이기 때문이다.

1️⃣ Interface?

보통 인터페이스에 대한 설명에는 스마트폰과 전원버튼을 예시로 사용한다.

전원이 꺼진 스마트폰이 있다고 가정해보자. 전원버튼을 누르면 전원이 켜진다.

이때 중요한 점은 내가 스마트폰 내부에서 무슨일이 일어나는지 모른다는 점이다. 스마트폰 내부의 복잡한 구조등을 몰라도 사용자는 그저 버튼을 누르기만 하면되는 것이다. 이처럼 간단하게 정해진 방식으로만 사용할 수 있게끔 A(사용자)와 B(스마트폰)를 연결해주는 통로가 바로 인터페이스이다.

2️⃣ 이를 토대로 API를 살펴보자

API는 '애플리케이션 프로그래밍 인터페이스(Application Programming Interface)'의 약자로, 두 소프트웨어 애플리케이션이 서로 통신하고 데이터를 주고받을 수 있도록 하는 규칙과 프로토콜의 집합입니다.

구글에 검색하면 나오는 API의 정의이다. 쉽게 풀어보면 API는 프로그램끼리 소통하는 인터페이스다. 스마트폰 예시에서는 '사람'과 '기기'를 연결했다면, API는 '프로그램'과 '프로그램'을 연결한다.

내가 사용했던 Toss Payments API문서를 살펴보면 (https://docs-pay.toss.im/reference/normal/create)

해당 형식의 요청에 필요한 파라미터를 문서로 만들어서 정리해 주고 있다. 나는 내부에서 무슨일이 일어나는지 모르지만 Toss측에서 원하는 파라미터만 보내서 요청하면 내가 원하는 Toss의 결제 기능을 사용 할 수 있는 것이다. ※반대로 생각하면 이런 정형화된 문서가 필수적이라는 단점도 가지고 있다

정리하며

• 인터페이스는 복잡함을 숨기고 간단한 사용법만 제공한다
• API는 프로그램 간 소통을 위한 인터페이스다
• 내부 구조를 몰라도 정해진 규칙만 따르면 기능을 사용할 수 있다

결국 API는 '약속된 방식으로 소통하는 통로'라고 볼 수 있겠다.

웹 개발을 하다 보면 CSR(Client-Side Rendering)과 SSR(Server-Side Rendering)이라는 용어를 자주 마주하게 됩니다. 둘은 브라우저에 웹 페이지를 보여주는 방식이 달라, 성능과 SEO, 개발 구조에 큰 영향을 미칩니다.

1️⃣ CSR(Client-Side Rendering) – 클라이언트 중심

개념: 서버는 최소한의 HTML과 JavaScript만 내려주고, 브라우저가 JS를 실행하여 화면을 렌더링하는 방식입니다.

특징:

• React, Vue, Angular 같은 SPA(단일 페이지 애플리케이션)에서 주로 사용.
• 서버는 주로 API 데이터를 제공.
• 클라이언트에서 페이지를 렌더링하므로 초기 로딩은 느릴 수 있지만, 이후 페이지 전환은 빠름.
• SEO 최적화가 어렵지만, 사용자 경험(UX)은 좋음.

예시:

사용자 요청 → 서버(API) → JSON 데이터 전달
→ 브라우저에서 React가 HTML 생성 → 화면 렌더링

⚡ React 프로젝트를 별도 포트에서 띄우고 Spring Controller가 단순 API만 제공하는 경우는 CSR에 해당합니다.

2️⃣ SSR(Server-Side Rendering) – 서버 중심

개념: 서버에서 완전히 렌더링된 HTML을 브라우저에 전달하는 방식입니다.

특징:

• JSP, Thymeleaf, Spring 기반 SSR에서 사용.
• 초기 페이지 로딩 속도가 빠르고 SEO 친화적.
• 서버가 HTML을 만들어 브라우저에 보내므로 클라이언트는 바로 화면 확인 가능.

예시:

사용자 요청 → 서버(Spring + Thymeleaf) → 서버에서 HTML 렌더링
→ 브라우저에 전달 → 화면 표시

⚡ JSP나 Thymeleaf를 이용하면 서버에서 HTML을 렌더링한 후 브라우저에 전달하므로 SSR입니다.

3️⃣ CSR vs SSR 비교

4️⃣ 혼동되는 상황

• React 프로젝트를 Next.js 등 SSR 지원 프레임워크로 서버에서 렌더링하면 SSR 가능.
• React 프로젝트를 별도 서버에서 실행하고 Spring이 API만 제공하면 CSR.
• Tailwind CSS는 HTML 내부에서 작동하므로 CSR에서도 문제없이 동작.

5️⃣ 핵심 정리

• 서버에서 HTML을 렌더링 → SSR
• 클라이언트에서 JS로 HTML을 렌더링 → CSR
• 렌더링 위치와 초기 로딩 주체가 SSR과 CSR의 차이를 결정합니다.

🗒️ 추가 용어 정리

🔍 SEO (Search Engine Optimization) – 검색 엔진 최적화

SEO는 검색 엔진 최적화를 의미하며, 구글, 네이버, 빙 같은 검색 엔진에서 내 웹사이트가 더 잘 검색되도록 개선하는 작업입니다. 쉽게 말해 “검색했을 때 내 페이지가 상단에 나오도록 하는 기술”이에요.

1. Front에서 결제 컨트롤러로 요청 보냄(Payment 객체에 Toss에서 필요한 요청을 전송하는 값들을 담아서
2. Back에서 매핑주소를 이용해서 Responsebody에 원하는 JSON형식을 담아 프론트에 리턴해줌( return ResponseEntity.ok(response.getBody());)

3. 결제결과 callBack에서 400이 나오면 orderId를 재생성 후 다시요청, 그래도 안되면 실패로 반환하도록 검증로직 구현하기

3. 200을 받아오면 그때서야 토스 결제페이지로 리디렉션(response의 body에 checkoutPage 형태로 받아옴
4. 결제 페이지를 받아와서 리디렉션 하는 코드
5. 4의 메서드로는 토스에서 보내는 요청(응답)이 토큰을 가지고 있지 않기 떄문에 해당 200코드를 해결하는 프로트엔드 로직이 필요

로그 찍는 방법이 잘못되어 원래대로 불러오는게 맞았는데 console.log("",response);로 찍어보도록 하자 올바른 요청주소는 response.data.checkoutPage 였다.

6. retUrl로 프론트 주소를 설정하고, 이후 프론트엔드에서 onLoad 시점에 controller로 결제정보를 반환받도록 비동기 처리를 하자

7. SearchParams 모듈을 써서 들어오고 있는 status등 결제 정보를 받아옴..!

8. 보낸정보를 토대로 백엔드 컨트롤러에서 받아서 로직검증 아래가 컨트롤러(리턴해줍니다)

9. 결제 완료 프론트엔드에서 들어온 요청을 검증 후 결제완료 창을 표시하면 결제 완료

*추가로 결제정보를 DB에 담는것과 위조정보 검증로직, 트랜잭션 처리 *필요

JavaScript (이하 JS) 수업 때와 마찬가지로 ‘자료형’에 대해 먼저 배우게 되었다.

🟦 JS

JS를 공부할 때도 물론 자료형이라는 개념은 알고 있었다. 하지만 JS에서는 let, const로 모든 선언을 끝내버리고, 변수에 어떤 값이 들어오든 타입이 자동으로 바뀌는 구조다. 즉, JS는 동적 타입 언어라서

let x = 10;   // number
x = "hello";  // string
x = true;     // boolean

이렇게 값이 바뀌면 변수의 타입도 즉석에서 바뀐다. 당시엔 “그냥 편하네~” 정도로만 생각했었다.

💡 Java 자료형은 느낌이 완전 다르다

Java는 JS와 달리 정적 타입 언어다. 즉, 변수의 타입을 선언할 때 명확히 지정해야 하고, 타입에 맞지 않는 값을 넣으면 컴파일 단계에서 바로 오류가 난다.

📘 Java 자료형 정리

🐶 클래스 예제에서 느낀 점

Java 수업에서 가장 먼저 만드는 클래스 중 하나가 이런 구조였다:

public class Dog {
    String name = "뽀삐";
    int age = 2;

    public static void main(String[] args) {

    }
}

여기서 바로 실수하기 쉬운 부분이 있다.

• 문자열은 " "(큰따옴표)
• 문자는 ' '(작은따옴표)
• age처럼 숫자를 넣는 필드는 String이 아니라 int 등 숫자 타입을 써야 함

JS에서는 숫자를 "2"로 넣든 2로 넣든 대체로 넘어가지만, Java는 타입을 확실히 구분해야 한다.

이런 작은 차이부터 JS와 Java의 철학 차이가 확 드러난다.

✍️ 회고

자료형이라는 개념은 처음엔 다소 번거롭게 느껴질 수 있지만, Java처럼 타입이 확실한 언어를 배워보면 “코드가 안정적이게 만들어지는 느낌”을 확실히 경험할 수 있다.

• GROUP BY절에는 SUM, COUNT 함수를 사용할 수 없다.
• RATIO_TO_REPORT
• INLINE VIEW는 일반적으로 메인쿼리보다 먼저 수행되므로 SQL 문장 내에서 절차성을 주는 효과를 얻을 수 있다.
• PL/SQL의 사용 순서는 Cursor 선언, Cursor open, FETCH, Cursor Close이다.

🧩 개념정리

1️⃣ OR 조건 작동 방식

쿼리 :

SELECT COUNT(*)
FROM limbest.emp
WHERE JOB = 'CLERK'
   OR (ENAME LIKE 'T%' AND SAL >= 3000);

CLERK이면서 동시에 ENAME LIKE 'T%' AND SAL >= 3000 조건도 만족하면 그 행이 두 번 카운트되나?

👉두 번 조회되지 않음, WHY?**

행이 아래 두 조건을 모두 만족한다고 할때

1. JOB = 'CLERK'
2. ENAME LIKE 'T%' AND SAL >= 3000

그러면 그 행의 where 결과는:

TRUE OR TRUE → TRUE

그러면 그 행은 그냥 한 번만 결과집합에 들어감. 설령 CLERK이면서 T%이면서 SAL >= 3000이라도 그 사원은 1명으로만 카운트됨.

결과 요약

• UNIQUE제약조건은 NULL을 가질 수 있다.
• ORACLE에서는 ORDER BY 정렬 시 NULL을 가장 큰 값으로 취급한다.
• ORDER BY 절은 “컬럼마다” 정렬 순서를 따로 준다
• 테이블 명은 숫자로 시작할 수 없으며, -(하이픈)을 사용할 수 없다.
• NTILE함수 사용시 나머지는 앞 그룹부터 1씩 추가된다.
• '=' 연산은 NULL과 비교하면 항상 거짓을 반환한다.
• LAG 함수는 현재 행을 기준으로 이전 행의 값을 가져온다.
• 반대로 LEAD 함수는 현재 행을 기준으로 다음 행의 값을 가져온다.
• CUME_DIST는 누적백분율을 구하는 함수이다.

🧩 용어정리

1️⃣ DECODE

DECODE(A, &nbsp&nbsp&nbspB, C, -- A가 B면 → C &nbsp&nbsp&nbspD, E, -- A가 D면 → E &nbsp&nbsp&nbspF, G, -- A가 F면 → G H) -- 그 외 → H

2️⃣ EXISTS 문법

• EXISTS: 서브쿼리 결과가 존재하면 TRUE
• NOT EXISTS: 서브쿼리 결과가 없으면 TRUE

  EXISTS는 레코드 존재 여부만 확인하기 때문에
  SELECT * 대신에  1, 'X', '아무문자열' 처럼 상수를 써도 상관없음

3️⃣ 서브쿼리(subQuery)

결과요약

프로그래밍 첫 강의는 HTML, JavaScript, 그리고 Database였다. JavaScript는 이미 독학해본 경험이 있었기에 비교적 수월하게 따라갈 수 있었다.

하지만 데이터베이스(Database) — 이 단어를 처음 들었을 때의 충격은 아직도 기억난다.

“내가 보는 프로그램의 데이터는 도대체 어디에 저장되어 있을까?” “버튼을 누르면 화면이 바뀌는데, 그 안에서는 어떤 일이 일어나는 걸까?”

그동안 단순히 “누르면 움직이는 화면” 정도로만 생각했던 웹이, 사실은 보이지 않는 곳에서 데이터를 저장하고 관리하는 구조라는 사실이 놀라웠다.

강의에서는 Schema, Entity, DBMS 같은 데이터의 기본 개념부터 다뤘다. 그리고 CMD 창에서 직접 쿼리문을 작성해 EMP 테이블을 조회했을 때, HTML로 만든 웹페이지와는 전혀 다른 세계가 펼쳐졌다. 그때의 신선함은 지금도 잊을 수 없다.

이후 다양한 쿼리와 문법 예제를 풀다 보니 시간 가는 줄 모를 정도로 흥미로웠다.

물론 JOIN, 서브쿼리(Subquery) 등을 배울 때는 많이 헤매기도 했지만, 프로젝트에선 SQL 문을 단독으로 관리하고 무결성 검증까지 맡을 만큼 성장했다.

이 경험을 바탕으로, 현재(2025년 11월 14일)는 SQLD 자격증 취득을 목표로 공부 중이다.

• 'ORDER BY (숫자)'는 테이블의 숫자번째 컬럼을 기준으로 정렬한다.

• 비교연산자 '<>'는 같지 않음을 의미한다.
• 'GROUP BY COL1, COL2'는 COL1, COL2의 조합이 같은 행들 끼리 묶는다.
• 한 개의 엔터티는 두 개 이상의 속성과 두 개 이상의 인스턴스를 가진다.
• 관계형 데이터베이스는 부하를 분석하는데 어려움이 있다.
• 주식별자의 특징은 유일성, 최소성, 불변성, 존재성 이다

🧩 용어정리

1️⃣ SUBSTR vs REGEXP_SUBSTR

2️⃣ 인조식별자 vs 본질식별자

3️⃣ CASE문 문법요약

• CASE

   &nbsp&nbsp&nbspWHEN 조건1 THEN 결과1

  &nbsp&nbsp&nbspWHEN 조건2 THEN 결과2 &nbsp&nbsp&nbspELSE 기본값 END

결과 요약

• grant는 권한을 부여, revoke는 권한을 삭제하는 SQL문이다.
• INTERSECT 연산자는 중복된 행을 하나의 행으로 표시한다.
• 데이터모델링 순서는 개(념적) - 논(리적) - 물(리적)
• SELECT * FROM SQLD5 WHERE COL1 IN (1,2,NULL)에서 NULL은 항상 'UNKNOWN'이 된다. -> 1,2만 select 됨
• WHERE 1=1 = "모든 행을 선택하되, 조건을 나중에 쉽게 추가하기 위한 문법적 장치"
• 고유키로 지정된 모든 칼럼은 중복된 값을 허용하진 않지만, NULL 값은 가질 수도 있다.

🧩 용어정리

1️⃣ 속성사전(Attribute Dictionary)

정의: 데이터베이스 내 속성(컬럼)들의 이름, 타입, 제약 조건, 의미 등을 정리해 둔 사전.

용도: 데이터 설계와 관리 시 참조, 문서화, 일관성 유지.

2️⃣ 시스템카탈로그(System Catalog)

정의: 데이터베이스 자체가 관리하는 메타데이터 저장소.

내용: 테이블, 컬럼, 인덱스, 제약 조건, 사용자 권한 등.

특징: 데이터베이스 구조 정보를 제공 → DBMS 내부에서 사용.

3️⃣ 릴레이션(Relation)

정의: 관계형 데이터베이스에서 테이블 자체를 의미.

특징: 행(Row) = 튜플(Tuple), 열(Column) = 속성(Attribute) 구조.

핵심: 모든 데이터는 릴레이션 형태로 저장.

4️⃣ 도메인(Domain)

정의: 속성이 가질 수 있는 값의 범위와 형식을 정의.

예시: 나이 속성 → 정수, 0~150

용도: 데이터 무결성 유지, 입력 오류 방지.

결과 요약

• BETWEEN은 '=' 를 포함한다.
• DECODE (EMPNO.1000. 'TRUE', 'FALSE')'로 IF문을 구현가능하다.
• 집합 연산자는 두 개 이상의 테이블에서 조인을 하지 않고 관련된 데이터를 조회한다.

LIKE문

• '%'는 모든 문자열(개수상관X)을 의미
• '_' 는 한 글자만을 의미

• 데이터 모델링
• 프로세스 모델링 업무흐름 중심
• 상관관점 모델링 업무에 따른 데이터 처리 흐름 중심

🧩 ERD 표기법(IE 표기법 vs Barker 표기법)

SELECT SUM(SAL) OVER ( PARTITION BY MGR ORDER BY HIREDATE -- DEFAULT ASC ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING ) AS MGR_SUM FROM Mytest;

• PARTITION BY MGR MGR(관리자) 별로 데이터를 그룹(파티션) 으로 나눕니다. 즉, 같은 MGR을 가진 직원들끼리만 윈도우 함수가 작동합니다.

- ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING 현재 행을 기준으로 이전 1행 + 현재 행 + 다음 1행을 윈도우(창)으로 설정합니다. 이 범위 내의 값을 이용해서 합계나 평균 등을 계산합니다.

🧩 JOIN(INNER, OUTER, CROSS, SELF)

• JOIN관련 문제에 취약점을 보이므로 오늘 확실히 짚고 넘어가기
• 자세한 내용은 NOTION, 책보며 학습*

📘 SQL JOIN 종류 요약표