Gani의 개발 기록

request,response 정리

Gani053 — Tue, 31 Mar 2026 14:23:00 +0900

솔직히 이게 제일 헷갈렸다. req가 뭔지 res가 뭔지는 알겠는데 실제로 코드에서 어디서 어떻게 쓰이는지가 계속 안 잡혔다.

req, res

req (request) : 클라이언트가 서버한테 보내는 요청. 뭘 해달라는 거. URL, HTTP 메서드, 헤더, 바디 다 여기 담겨 있다.

res (response) : 서버가 클라이언트한테 돌려주는 응답. 처리 결과를 돌려주는 거. 상태코드, 헤더, 바디가 여기 담긴다.

클라이언트 --[req]--> 서버
클라이언트 <--[res]-- 서버

프론트(Vue + axios)에서 req 보내기

axios로 요청을 보내는 게 req를 만드는 거다.

// GET 요청
const res = await axios.get('/api/vehicles')

// POST 요청
const res = await axios.post('/api/vehicles', {
  carNumber: '12가3456',
  ownerName: '홍길동'
})

// 헤더에 JWT 토큰 담아서 보내기
const res = await axios.get('/api/vehicles', {
  headers: {
    Authorization: `Bearer ${token}`
  }
})

axios.get(), axios.post() 이게 req를 만들어서 서버에 보내는 거다. 반환값으로 받는 res가 서버에서 돌아온 응답이다.

응답 데이터는 res.data로 꺼내 쓴다.

const res = await axios.get('/api/vehicles')
console.log(res.data) // 서버가 보내준 데이터

백(Spring)에서 req 받고 res 돌려주기

프론트에서 보낸 req를 Spring 컨트롤러가 받는다.

@RestController
@RequestMapping("/api/vehicles")
public class VehicleController {

    // GET 요청 받기
    @GetMapping
    public ResponseEntity<List<Vehicle>> getVehicles() {
        List<Vehicle> list = vehicleService.getAll();
        return ResponseEntity.ok(list); // 200 OK + 데이터 반환
    }

    // POST 요청 받기 (바디에서 데이터 꺼내기)
    @PostMapping
    public ResponseEntity<Void> addVehicle(@RequestBody VehicleRequest request) {
        vehicleService.add(request);
        return ResponseEntity.status(201).build(); // 201 Created
    }
}
```

`@RequestBody` : req 바디에 담긴 JSON을 Java 객체로 변환해준다.
`ResponseEntity` : 상태코드랑 응답 바디를 직접 설정해서 돌려줄 수 있다.

---

## 전체 흐름 한눈에
```
[Vue]
axios.post('/api/vehicles', { carNumber: '12가3456' })
        ↓ req (HTTP POST, body에 JSON 담아서 전송)

[Spring - JwtAuthenticationFilter]
Authorization 헤더에서 토큰 꺼내서 검증
        ↓ 통과하면

[Spring - VehicleController]
@RequestBody로 바디 꺼냄
서비스 로직 실행
ResponseEntity로 결과 반환
        ↓ res (HTTP 201, 결과 JSON)

[Vue]
res.data로 응답 데이터 꺼내서 사용

처음엔 req가 axios에서 끝나는 줄 알았는데, Spring 필터 거치고 컨트롤러까지 들어오는 흐름이 연결돼 있는 거였다.

헷갈렸던 포인트

@RequestBody vs @RequestParam

// URL에 붙어오는 데이터 (?page=1&size=10)
@GetMapping
public ResponseEntity<?> getList(@RequestParam int page, @RequestParam int size) { }

// 바디에 JSON으로 담겨오는 데이터
@PostMapping
public ResponseEntity<?> add(@RequestBody VehicleRequest request) { }

GET 요청은 보통 URL 파라미터, POST 요청은 보통 바디에 담아 보낸다. 처음엔 이걸 몰라서 계속 null 받았다.

axios res vs Spring ResponseEntity

프론트에서 쓰는 res는 axios가 받아온 응답 객체고, Spring에서 쓰는 ResponseEntity는 백엔드가 응답을 만들어서 보내는 객체다. 이름이 비슷해서 헷갈렸는데 역할이 반대라고 보면 된다.

느낀 점

req, res 개념 자체는 어렵지 않은데 프론트랑 백이 나눠져 있으니까 각각 어느 쪽에서 뭘 하는 건지 흐름이 안 잡혔던 것 같다.

프로젝트에서 axios 요청 보내놓고 컨트롤러에서 왜 안 받히지 하면서 한참 헤맸는데, 결국 @RequestBody 빠뜨린 거였다.

전체 흐름을 한 줄로 놓고 보니까 훨씬 이해가 됐다.

프론트에서 만든 req가 필터 거쳐서 컨트롤러까지 들어오고, 컨트롤러에서 만든 res가 다시 프론트로 돌아가는 구조. 이 한번 머릿속에 그려지니까 이해가 조금 더 됐다.

IoC · DI · 빈 등록 정리

Gani053 — Tue, 31 Mar 2026 10:54:47 +0900

오늘 IoC랑 DI 개념 정리했다.

사실 그동안 그냥 @Service 붙이면 되는 거 아닌가 하고 넘겼는데 제대로 짚고 가야 할 것 같아서 정리한다.

IoC (Inversion of Control) - 제어의 역전

직역하면 제어의 역전인데 처음엔 이게 무슨 말인지 몰랐다.

원래는 이렇게 쓴다.

public class UserService {
    private UserRepository userRepository = new UserRepository();
}

내가 직접 new로 객체를 만드는 거다. 근데 Spring 쓰면 이걸 내가 안 해도 된다.

@Service
public class UserService {
    private final UserRepository userRepository;

    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }
}

Spring이 알아서 객체 만들고 넣어준다. 이게 IoC다. 객체를 내가 제어하는 게 아니라 Spring이 제어하니까 "제어가 역전됐다"는 거였다. 이름이 어렵게 느껴지는데 개념 자체는 별거 없었다.

Bean (빈)

Spring이 관리하는 객체를 빈이라고 부른다. 그리고 그 빈들을 담아두는 공간이 IoC 컨테이너 (ApplicationContext).

빈 등록하는 방법

1. 어노테이션으로 등록

@Component
@Service
@Repository
@Controller

이거 붙이면 Spring이 알아서 빈으로 등록해준다.

@Service, @Repository, @Controller 다 내부적으로 @Component 포함하고 있음. 역할 구분하려고 나눠놓은 거라고 한다.

@Service
public class ParkingService {
    // 그냥 이렇게만 해도 빈으로 등록됨
}

2. @Configuration + @Bean으로 직접 등록

외부 라이브러리처럼 내가 소스코드를 못 건드리는 경우에 쓴다.

@Configuration
public class SecurityConfig {

    @Bean
    public PasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }
}

BCryptPasswordEncoder는 외부 클래스라서 @Component 못 붙이니까 이렇게 수동으로 등록하는 거다.

프로젝트에서 시큐리티 설정할 때 이 방식 썼는데 그때는 왜 이렇게 하는지 몰랐는데 이제 이해된다.

DI (Dependency Injection) - 의존성 주입

IoC를 구현하는 방법이다. Spring이 빈끼리 연결해주는 방식.

주입 방법이 3가지가 있다.

1. 생성자 주입 (권장)

@Service
public class VehicleService {

    private final VehicleRepository vehicleRepository;

    public VehicleService(VehicleRepository vehicleRepository) {
        this.vehicleRepository = vehicleRepository;
    }
}

final 쓸 수 있어서 불변성 보장되고, 순환 참조도 컴파일 시점에 잡힌다. Spring 공식 권장 방식.

2. 필드 주입 (비권장)

@Service
public class VehicleService {

    @Autowired
    private VehicleRepository vehicleRepository;
}

코드가 짧아서 처음엔 이게 편해 보였는데 final 못 쓰고 테스트할 때 문제가 생긴다.

3. setter 주입

@Service
public class VehicleService {

    private VehicleRepository vehicleRepository;

    @Autowired
    public void setVehicleRepository(VehicleRepository vehicleRepository) {
        this.vehicleRepository = vehicleRepository;
    }
}

처음엔 IoC, DI, 빈이 다 따로따로인 줄 알았는데 정리하고 보니까 결국 하나로 이어지는 개념이었다.

선택적 의존성 있을 때 쓰는 거라는데 솔직히 아직 이걸 쓸 상황이 잘 안 떠오른다.

셋의 관계 정리
IoC
└── IoC 컨테이너가 Bean 생성·관리
└── DI로 Bean 간 의존 관계 연결

느낀 점

솔직히 처음에 @Autowired 붙이면 되는 거 아닌가 하고 이해도 없이 쓰고 있었다.

근데 프로젝트하다가 순환 참조 오류 터지고 나서야 왜 생성자 주입 써야 하는지 몸으로 깨달았다.

필드 주입이 코드 짧아서 편해 보이는데 테스트 짤 때 의존성 못 넣어줘서 결국 다 생성자 주입으로 바꿨다.

그때부터 그냥 동작하니까 쓰는 거랑 이유 알고 쓰는 거 차이를 느꼈다.

Spring 처음 배울 때 제일 헷갈렸던 부분인데 이번에 제대로 정리하고 나니까 코드 읽는 게 좀 더 편해진 것 같다.

JWT(JSON Web Token)

Gani053 — Sat, 7 Feb 2026 22:13:04 +0900

JWT 인증 방식이란?

기존 세션 방식은 서버에 로그인 정보를 저장하는 반면, JWT는 토큰에 사용자 정보를 담아서 클라이언트가 들고 다니는 방식이다.

서버는 stateless하게 유지되고, 매 요청마다 토큰만 검증하면 되니까 확장성이 좋다.

전체 흐름

1. 로그인 요청 (username, password)
   ↓
2. 인증 성공 시 JWT 토큰 발급
   ↓
3. 클라이언트는 이후 요청마다 토큰을 헤더에 담아 전송
   Authorization: Bearer {token}
   ↓
4. 서버는 필터에서 토큰 검증 후 인증 처리
   ↓
5. 컨트롤러 접근

주요 구성 요소

1. JwtTokenProvider

JWT 토큰 생성, 검증, 정보 추출 담당
비밀키로 서명해서 위변조 방지
주요 메서드:
- createToken(): 사용자 정보 → JWT 토큰 변환
- validateToken(): 토큰 유효성 검증
- getUsername(): 토큰에서 사용자명 추출

2. JwtAuthenticationFilter

매 HTTP 요청마다 실행되는 필터
Authorization 헤더에서 JWT 토큰 추출
토큰 검증 후 SecurityContext에 인증 정보 설정
이후 요청에서 인증된 사용자로 처리됨

3. SecurityConfig

Spring Security 전체 설정
CSRF 비활성화 (JWT 방식에서는 불필요)
세션 사용 안 함 (STATELESS)
URL별 접근 권한 설정
- /api/auth/**: 누구나 접근 가능 (로그인, 회원가입)
- 나머지: 인증 필요
JWT 필터를 Spring Security 필터 체인에 추가

4. AuthController

로그인 엔드포인트 제공
AuthenticationManager로 실제 인증 처리
인증 성공 시 JWT 토큰 발급해서 반환

동작 과정

로그인 시

사용자가 username, password 전송
AuthenticationManager가 DB에서 사용자 조회 및 비밀번호 검증
성공하면 JWT 토큰 생성해서 반환
클라이언트는 토큰 저장 (localStorage 등)

이후 API 요청 시

클라이언트가 Authorization: Bearer {token} 헤더 포함해서 요청
JwtAuthenticationFilter가 토큰 추출 및 검증
유효하면 SecurityContext에 인증 정보 설정
컨트롤러에서 인증된 사용자로 처리

핵심 포인트

세션 사용 안 함: 서버는 상태를 저장하지 않음 (stateless)
토큰 기반 인증: 매 요청마다 토큰으로 인증
비밀키로 서명: 토큰 위변조 방지
만료 시간 설정: 보안을 위해 토큰 유효기간 제한

보안 고려사항

JWT secret은 반드시 환경변수로 관리
HTTPS 사용 필수 (토큰 탈취 방지)
토큰 만료시간 적절히 설정 (보통 1시간~1일)
Refresh Token 추가 구현 고려 (Access Token 재발급용)

느낀 점

처음 JWT를 공부할 때는 필터, SecurityContext, Authentication 같은 개념들이 너무 많아서 헷갈렸다.

특히 Spring Security 자체가 워낙 방대해서 어디서부터 손대야 할지 막막했는데,

결국 핵심은 "토큰을 어떻게 만들고, 어떻게 검증하느냐" 였다.

REST API와 HTTP

Gani053 — Mon, 2 Feb 2026 10:08:51 +0900

프론트엔드를 공부하다 보면 GET, POST, PUT, DELETE 같은 단어를 계속 보게 된다.

처음에는 그냥 요청 방식 이름 정도로만 알았는데, 정리해보니 REST API는 프론트와 백엔드가 서로 대화하는 방식에 대한 규칙이라는 느낌에 더 가까웠다.

REST API란?

REST API는 프론트엔드와 백엔드가 데이터를 주고받기 위한 통신 규칙이다.

프론트는 화면을 만들고 버튼을 누르면 요청을 보내고, 백엔드는 데이터를 가져오거나 수정해서 응답을 준다. 이 둘이 직접 데이터베이스와 연결되는 게 아니라 항상 서버를 거쳐서 통신하게 된다.

구조를 단순하게 보면 이렇게 된다.

프론트 → 백엔드 서버 → 데이터베이스

프론트는 DB에 직접 접근하지 않고 백엔드에게 "이 데이터 줘", "이거 저장해" 같은 요청만 보낸다.

프론트에서 DB에 직접 접근하지 않는 이유

처음에는 "그냥 프론트에서 DB 연결하면 빠르지 않나?" 이 생각이 들었는데 실제로는 거의 사용하지 않는 구조였다.

이유는 크게 세 가지였다.

보안 문제: DB 주소나 비밀번호가 브라우저에 그대로 노출된다.
권한 관리 어려움: 누가 어떤 데이터를 수정하는지 통제가 힘들다.
로직 처리 한계: 데이터 검증이나 조건 처리를 프론트에서 하기가 어렵다.

그래서 프론트는 DB가 아니라 항상 서버하고만 통신하게 된다.

HTTP 메서드 종류

REST API에서 가장 많이 쓰는 방식은 네 가지이다.

GET (조회)

데이터를 가져올 때 사용한다.

GET /board
GET /board/3

/board → 전체 목록 조회
/board/3 → id가 3번인 글 하나 조회

POST (생성)

새로운 데이터를 만들 때 사용한다.

POST /board

body에 제목, 내용 같은 데이터가 들어간다.
데이터베이스 INSERT 느낌이다.

PUT (수정)

기존 데이터를 수정할 때 사용한다.

PUT /board

수정할 id와 변경 내용을 같이 보낸다.
UPDATE 개념에 가깝다.

DELETE (삭제)

DELETE /board?id=3

특정 id 데이터를 삭제한다.
DELETE SQL과 거의 같은 느낌이다.

프론트에서의 흐름 (axios 기준)

Vue나 React에서는 보통 axios나 fetch를 사용한다.

axios.get('/board')

이 한 줄이 내부적으로는

http://localhost:8080/board

이 주소로 요청을 보내는 것이다.

프론트에서는 단순히 함수 호출처럼 보이지만 실제로는 서버와 통신이 일어나는 구조다.

느낀 점

REST API는 단순히 요청 방식 이름을 외우는 게 아니라 프론트와 백엔드의 역할을 나누는 구조를 이해하는 게 더 중요했다.

중요한 기준은

프론트는 화면과 요청
백엔드는 데이터와 로직
DB는 서버를 통해서만 접근

이라는 흐름이었다.

이 구조를 이해하고 나니 axios 코드가 단순한 함수가 아니라 "서버와 대화하는 문장"처럼 보이기 시작했다.

GET은 "이거 보여줘", POST는 "이거 저장해줘", DELETE는 "이거 지워줘" 같은 명령문인 셈이다.

결국 프론트와 백엔드는 각자 맡은 역할만 하고, REST API라는 약속된 규칙으로 대화하는 구조였다.

객체지향 프로그래밍(OOP)

Gani053 — Fri, 30 Jan 2026 17:42:01 +0900

객체지향을 처음 배울 때는
그냥 클래스 만들고 new 쓰는 문법 정도로만 생각했다.
그런데 정리하다 보니 객체지향은 단순 문법이 아니라 코드를 어떻게 나눌 것인가에 대한 설계 방식이라는 게 더 중요하다는 걸 알게 됐다.

객체지향이란?

객체지향(Object Oriented Programming, OOP)은 프로그램을 기능 단위가 아니라 객체(Object) 단위로 나누어 설계하는 방식이다.

객체는 단순한 데이터가 아니라 상태(데이터)와 행동(기능)을 함께 가지고 있는 하나의 단위라고 이해했다.

예를 들어 자동차를 생각해 보면

색상, 속도 → 데이터(필드)
달린다, 멈춘다 → 기능(메서드)

이렇게 현실 세계의 개념을 코드로 표현하는 방식이 객체지향의 기본 구조이다.

클래스(Class)와 객체(Object)

처음에 가장 헷갈렸던 개념이었다.
정리해보니 클래스는 설계도, 객체는 그 설계도로 만들어진 실제 결과물이었다.

class Car {
    String color;
    int speed;

    void drive() {
        System.out.println("달린다");
    }
}

Car car1 = new Car();
Car car2 = new Car();

같은 설계도로 만들어졌지만 각각 다른 상태를 가질 수 있는 독립적인 존재가 객체라는 점이 중요했다.

필드(Field)와 메서드(Method)

객체는 데이터와 기능을 함께 가진다.

필드 → 상태 정보
메서드 → 행동

class Person {
    String name;
    int age;

    void introduce() {
        System.out.println("자기소개");
    }
}

데이터와 기능을 하나의 단위로 묶는 것이 객체지향의 가장 기본적인 특징이라고 느꼈다.

생성자(Constructor)와 this

객체를 생성할 때 초기값을 설정하는 역할을 한다.

class User {
    String name;

    User(String name) {
        this.name = name;
    }
}

this는 현재 객체 자신을 의미하고 필드와 매개변수를 구분할 때 사용된다는 점을 이해하고 나니 코드를 읽는 게 훨씬 편해졌다.

캡슐화(Encapsulation)

처음에는 그냥 private 붙이는 문법이라고 생각했는데 정리하면서 보니 데이터 보호가 핵심 목적이었다.

class Account {
    private int money;

    public void setMoney(int money) {
        this.money = money;
    }

    public int getMoney() {
        return money;
    }
}

외부에서 직접 값을 변경하지 못하게 하고 메서드를 통해서만 접근하도록 만드는 구조이다.

상속(Inheritance)

기존 클래스의 기능을 물려받아 새로운 클래스를 만드는 개념이다.

class Animal {
    void sound() {
        System.out.println("소리");
    }
}

class Dog extends Animal {
}

코드를 복사하지 않고 재사용할 수 있다는 점이 가장 큰 장점이었다.

오버라이딩(Overriding)

부모 클래스의 메서드를 자식 클래스에서 다시 정의하는 것이다.

class Dog extends Animal {
    @Override
    void sound() {
        System.out.println("멍멍");
    }
}

같은 이름의 메서드지만 객체에 따라 다른 동작을 하게 만들 수 있다는 점이 인상적이었다.

다형성(Polymorphism)

하나의 타입으로 여러 객체를 다룰 수 있는 개념이다.

Animal a = new Dog();
a.sound();

타입은 Animal이지만 실제 동작은 Dog의 메서드가 실행된다.
이 구조 덕분에 코드가 훨씬 유연해진다.

인터페이스와 추상 클래스

둘 다 “완성되지 않은 설계도”라는 공통점이 있다.

인터페이스 → 기능의 규칙만 정의
추상 클래스 → 일부 구현 + 일부 미구현

처음에는 차이를 외우려고 했는데, 인터페이스는 규칙, 추상 클래스는 반쯤 구현된 설계도라고 이해하니 정리가 됐다.

정리하면서 느낀 점

객체지향은 단순히 문법을 배우는 개념이 아니라 코드를 역할과 책임 기준으로 나누는 사고 방식이라는 점이 가장 중요했다.

클래스 몇 개 만드는 것보다

데이터와 기능을 어떻게 묶을지
상속이 필요한지
외부 접근을 막아야 하는지
공통 규칙을 인터페이스로 만들지

이런 고민을 하는 과정이 객체지향의 핵심이라는 걸 이해하게 됐다.

정규화와 정규형(Normalization & Normal Form)

Gani053 — Fri, 9 Jan 2026 23:31:44 +0900

데이터베이스를 공부하다 보면 정규화, 정규형이라는 개념이 계속 나온다.
처음에는 그냥 테이블을 나누는 거라고 생각했는데, 정리해보니 데이터 중복을 줄이고 이상현상을 막기 위한 설계 과정이라는 게 핵심이었다.

정규화와 정규형이란?

정규화(Normalization)는 데이터베이스를 설계할 때
중복 데이터를 줄이고, 삽입·수정·삭제 시 발생하는 이상현상(아노말리)을 막기 위해 테이블을 분해하는 과정이다.

단순히 테이블을 쪼개는 게 목적이 아니라, 데이터 사이의 관계를 명확하게 정리하는 것이 더 중요하다.

예를 들어 고객 정보와 주문 정보를 한 테이블에 같이 넣으면, 고객 이름이나 전화번호가 주문할 때마다 계속 반복 저장된다.

CREATE TABLE order_info (
    order_id INT,
    customer_id INT,
    customer_name VARCHAR(20),
    customer_phone VARCHAR(20),
    product_name VARCHAR(20),
    product_price INT
);

이런 구조에서는

고객 전화번호가 바뀌면 여러 행을 수정해야 하고
아직 주문하지 않은 고객은 저장할 수 없고
주문 기록을 지우면 고객 정보까지 같이 사라질 수 있다

이런 문제들을 해결하기 위해 정규화를 한다.

정규형(Normal Form)은 정규화를 거쳐 만들어진 테이블의 상태를 의미한다.
즉, 정규화는 과정이고 정규형은 결과라고 이해했다.

제1정규형 (1NF)

제1정규형은 모든 컬럼이 하나의 값만 가지는 상태이다.
하나의 컬럼에 여러 값이 들어가면 안 된다.

CREATE TABLE student (
    student_id INT,
    name VARCHAR(20),
    phone VARCHAR(100)
);

phone 컬럼에
010-1111-2222, 010-3333-4444
처럼 여러 값이 들어가 있으면 제1정규형이 아니다.

그래서 값을 나눠서 저장한다.

CREATE TABLE student_phone (
    student_id INT,
    phone VARCHAR(20)
);

제1정규형은 관계형 데이터베이스의 기본 조건이라서 모든 정규화는 여기서부터 시작한다.

제2정규형 (2NF)

제2정규형은 제1정규형을 만족하면서 부분 함수 종속이 제거된 상태이다.
이 개념은 기본키가 두 개 이상인 복합키일 때 중요해진다.

CREATE TABLE order_detail (
    order_id INT,
    product_id INT,
    product_name VARCHAR(20),
    order_quantity INT,
    PRIMARY KEY (order_id, product_id)
);

여기서 기본키는 (order_id, product_id)인데
product_name은 order_id와는 상관없이 product_id에만 의존한다.

이게 바로 부분 함수 종속이다.

그래서 상품 정보를 따로 분리한다.

CREATE TABLE product (
    product_id INT PRIMARY KEY,
    product_name VARCHAR(20)
);

CREATE TABLE order_detail (
    order_id INT,
    product_id INT,
    order_quantity INT,
    PRIMARY KEY (order_id, product_id)
);

제2정규형의 핵심은
일반 컬럼이 기본키 전체에 의존하도록 만드는 것이라고 이해했다.

제3정규형 (3NF)

제3정규형은 제2정규형을 만족하면서 이행 함수 종속을 제거한 상태이다.

CREATE TABLE employee (
    emp_id INT PRIMARY KEY,
    dept_id INT,
    dept_name VARCHAR(20)
);

이 테이블에서는

emp_id → dept_id
dept_id → dept_name

이런 관계가 생긴다.
즉, dept_name은 emp_id에 직접 의존하는 게 아니라 dept_id를 통해 의존한다.

이런 구조는 중복을 만들기 때문에 테이블을 분리한다.

CREATE TABLE department (
    dept_id INT PRIMARY KEY,
    dept_name VARCHAR(20)
);

CREATE TABLE employee (
    emp_id INT PRIMARY KEY,
    dept_id INT
);

제3정규형은 일반 컬럼이 다른 일반 컬럼에 의존하지 않게 만드는 단계라고 정리했다.

BC 정규형 (BCNF)

BC 정규형은 제3정규형보다 더 엄격한 형태이다.
모든 결정자는 반드시 후보키여야 한다.

이론적으로는 가장 깔끔한 구조지만, 실제 프로젝트에서는 성능이나 쿼리 복잡도 때문에
제3정규형까지만 적용하는 경우도 많다고 한다.

제4정규형 (4NF)

제4정규형은 다가 종속을 제거한 상태이다.

CREATE TABLE student_info (
    student_id INT,
    hobby VARCHAR(20),
    certificate VARCHAR(20)
);

한 학생이 여러 취미와 여러 자격증을 가질 수 있는데,
이걸 한 테이블에 넣으면 불필요한 조합이 계속 생긴다.

그래서 각각 분리한다.

CREATE TABLE student_hobby (
    student_id INT,
    hobby VARCHAR(20)
);

CREATE TABLE student_certificate (
    student_id INT,
    certificate VARCHAR(20)
);

제5정규형 (5NF)

제5정규형은 조인 종속과 관련된 정규형이다.
테이블을 나눴다가 다시 조인했을 때 원래 데이터와 완전히 같아야 한다.

실무에서는 거의 쓰이지 않고, 개념적으로만 이해하면 되는 단계라고 느꼈다.

정리하면서 느낀 점

정규화를 공부하면서 느낀 건
몇 정규형이냐보다 왜 나눠야 하는지 설명할 수 있는지가 더 중요하다는 점이었다.

중요한 기준은 다음이라고 정리했다.

데이터 중복이 발생하는지
수정·삭제·삽입 시 문제가 생길 수 있는지
컬럼 간의 의존 관계가 논리적인지

정규화는 정답 맞추기용 이론이 아니라, 데이터를 어떻게 설계해야 덜 꼬일지를 고민하는 과정이라는 걸 조금은 이해한 것 같다.

관계형 데이터베이스(RDB)

Gani053 — Tue, 6 Jan 2026 17:38:24 +0900

최근에 데이터베이스를 배우면서 알게 된 개념들을 정리해 두고 싶다는 생각이 들었다.
단순히 용어 외우기 수준이 아니라, 이게 왜 필요한지, 실제로 어떤 역할을 하는지 이해하고 넘어가는 게 중요할 것 같았기 때문이다.

데이터베이스란 결국 데이터를 제대로 관리하기 위한 시스템

데이터베이스를 한 줄로 표현하면,
많은 데이터를 안전하게 저장하고, 필요할 때 빠르게 꺼내 쓰고, 믿을 수 있게 관리하기 위한 시스템이라고 생각하면 이해가 쉬웠다.

단순히 파일에 저장하는 것이 아니라, 제대로 정리하고 구조화해서 관리하는 방식이기 때문에 현실 세계의 거의 모든 서비스가 데이터베이스 위에서 돌아간다고 해도 과장이 아닌 것 같다.
회원 정보, 주문 기록, 결제 내역, 게시글 데이터 등 이런 모든 것들이 결국 데이터베이스에 저장된다.

관계형 데이터베이스(RDB), 표로 관리하는 가장 정돈된 방식

그중에서도 가장 많이 사용되는 방식이 관계형 데이터베이스(RDB)다.
이건 데이터를 표(테이블) 형태로 관리하는 시스템인데, 엑셀 시트를 떠올리면 생각보다 훨씬 친숙하게 다가온다.

하나의 표가 하나의 데이터 덩어리
행(Row)은 실제 데이터 한 건
열(Column)은 각각의 속성

여기까지만 이해해도 전체 구조가 크게 어렵게 느껴지지 않는다.

왜 관계형일까?

배우면서 제일 인상 깊었던 부분이 바로 이 관계라는 개념이다.

데이터를 하나의 큰 테이블에 몰아넣지 않고, 성격이 다른 데이터끼리 나눠서 저장한 뒤 서로 필요한 부분만 연결한다.

예를 들어,

회원은 회원 테이블
상품은 상품 테이블
주문은 주문 테이블

이렇게 나눠 놓고, 공통되는 값(키)을 통해 서로 연결한다.

이 구조 덕분에 데이터가 깔끔해지고, 중복이 줄어들고, 관리가 훨씬 쉬워진다.

잘못 설계하면 생기는 문제, 이상 현상(Anomaly)

친절하게 알려주는 부분만 있는 건 아니었다.
설계를 잘 못하면 오히려 문제가 터질 수 있다는 것도 배우게 됐다.

데이터를 추가하려는데 이상한 값까지 같이 넣어야 하는 상황
같은 데이터를 여러 곳에서 수정해야 하는 상황
데이터를 지우다가 없어지면 안 되는 정보까지 같이 삭제되는 상황

이런 문제들을 이상 현상(Anomaly)라고 한다.

그래서 등장한 개념이 정규화(Normalization)인데, 데이터를 적절히 나누고, 규칙적으로 정리해서 문제를 최소화하는 과정이라고 이해했다.
말 그대로 데이터를 건강하게 정리하는 작업이라는 느낌이었다.

무결성과 제약 조건, 믿을 수 있는 데이터를 만드는 장치들

또 하나 중요한 개념이 무결성(Integrity)이다.
데이터가 “올바른 상태”를 유지하도록 강제하는 개념이다.

Primary Key는 비어 있으면 안 되고, 중복될 수 없다.
Foreign Key는 존재하는 값만 참조해야 한다.
컬럼마다 허용되는 값의 규칙을 정할 수 있다.

여기에 더해, 데이터베이스에는 제약 조건(Constraint)을 걸어서 실제로 규칙을 어기면 아예 저장 자체가 되지 않도록 만들 수 있다.

PRIMARY KEY
FOREIGN KEY
NOT NULL
UNIQUE
CHECK
DEFAULT

이런 것들이 전부 데이터 안전장치 역할을 한다는 걸 알게 되면서, 데이터베이스가 단순 저장소가 아니라, 신뢰성을 보장해 주는 시스템이라는 걸 더 확실히 느끼게 됐다.

정리하면서 느낀 점

처음 데이터베이스를 접했을 때는 그냥 데이터 저장하는 곳 정도로 생각했다.
하지만 배우고 정리하면서 느낀 건, 데이터베이스는 단순 저장을 넘어서 데이터를 얼마나 안전하고 정확하게 관리할 수 있느냐를 책임지는 핵심 시스템이라는 점이었다.

관계형 데이터베이스가 표 기반 구조를 사용하는 이유, 정규화와 무결성이 왜 중요한지,
제약 조건이 왜 필수인지까지 연결되면서 전체 흐름이 점점 명확해졌다.

앞으로 실제 프로젝트에서 사용자 정보, 주문 기록, 서비스 데이터 등을 다루게 될 텐데, 오늘 정리한 이 개념들이 큰 기반이 될 것 같다는 생각이 들었다.

한 문장으로 정리하면, 이렇게 남기고 싶다.

관계형 데이터베이스는 데이터를 단순히 저장하는 도구가 아니라, 정확하고 안전하게 ‘관리’하기 위한 구조적인 시스템이다.

Vue.js Props

Gani053 — Tue, 30 Dec 2025 18:18:57 +0900

Vue.js에서 컴포넌트를 사용하다 보면, 같은 컴포넌트를 상황에 따라 다르게 보여줘야 하는 경우가 많다. 예를 들어 글자 색만 다르게 보여주고 싶다거나, 같은 디자인의 카드인데 내용만 다르게 쓰고 싶을 때가 있다. 이럴 때 사용하는 것이 바로 Props이다.

Props란 무엇인가?

Props는 부모 컴포넌트가 자식 컴포넌트로 값을 전달하는 방법이다.
한 문장으로 정리하면 이렇게 생각하면 된다.

“Props = 부모가 주고, 자식이 받는 값”

데이터 흐름은 항상 부모에서 자식 방향으로만 흐르는 단방향 구조이며, 자식 컴포넌트는 받은 값을 읽어서 사용만 할 수 있다.
그래서 Props는 “읽기 전용”이라고 표현한다.

Props가 필요한 이유

컴포넌트를 사용하는 이유는 재사용성 때문이다.
하지만 완전히 같은 UI만 계속 반복해서 쓰기에는 한계가 있다.
같은 컴포넌트지만, 상황마다 다른 데이터를 보여주고 싶을 때 Props가 필요하다.

같은 컴포넌트 + 다른 데이터
→ 재사용은 유지하면서 내용만 바꿀 수 있음

Props가 동작하는 흐름

Props의 흐름을 간단하게 정리하면 다음과 같다.

자식 컴포넌트는 “이런 값을 받을 수 있다”라고 선언한다
부모 컴포넌트가 실제 값을 넘겨준다
자식 컴포넌트는 그 값을 화면에서 사용한다

이 흐름이 이해되면, Props 구조는 크게 어렵지 않다.

Props가 undefined가 되는 상황

처음 Props를 쓰면 가장 많이 만나는 문제가 바로 이거다.

“분명 Props를 썼는데 값이 undefined로 나온다”

대부분 이런 경우에 발생한다.

부모가 값을 보내지 않았을 때
부모와 자식의 Props 이름이 서로 다를 때
부모에서 전달하려는 값 자체가 비어 있을 때

즉, 구조 자체가 잘못된 게 아니라 “값이 실제로 들어오냐”가 중요하다.

Props 기본값 개념

Props는 언제든 안 들어올 수도 있기 때문에 “기본값” 개념이 필요하다.
Vue에서는 기본값을 설정해 두면, 값이 전달되지 않아도 안정적으로 동작하도록 만들 수 있다.

이렇게 기본값을 설정해두는 습관을 들이면 예상치 못한 undefined 문제를 줄일 수 있다.

Props 요약

Props는 이렇게 기억하면 된다.

“Props는 부모가 자식에게 값을 전달하는 통로이고, 자식은 그 값을 읽어서 사용하는 역할을 한다.”

컴포넌트를 제대로 활용하려면 꼭 이해해야 하는 개념이고, 실제 프로젝트를 하게 되면 거의 필수처럼 계속 사용하게 될 개념이다.

정리하면서 느낀 점

Props를 정리하면서 가장 크게 느낀 건, 단순히 “부모가 자식에게 값을 넘겨준다”라는 문장 하나로 끝나는 개념이 아니라는 점이었다.
처음에는 그냥 기능 중 하나라고만 생각했는데, 공부하다 보니 컴포넌트를 “진짜 재사용 가능한 단위”로 만들어 주는 핵심이라는 걸 확실히 알게 됐다.

특히 undefined가 뜨는 상황이나 기본값 개념을 같이 보면서, 단순히 문법만 아는 것과 구조를 이해하는 건 확실히 다르다는 것도 느꼈다. 앞으로 Vue로 작업할 때, 그냥 props를 “넘긴다” 수준이 아니라, 언제 값이 없을 수 있는지, 어떤 흐름으로 데이터가 내려가는지까지 같이 생각해야 한다는 걸 기억해 두면 좋을 것 같다.

비동기(Asynchronous)

Gani053 — Fri, 26 Dec 2025 20:46:54 +0900

오늘은 자바스크립트에서 정말 많이 쓰이고, 또 헷갈리기 쉬운 개념인 비동기 처리에 대해 정리해보려고 한다. 수업 들으면서도 그렇고, 직접 정리하면서 느낀 거지만, 이 개념이 정확히 잡히지 않으면 이후에 나오는 API 호출이나 서버 통신 같은 부분에서 계속 막히게 될 것 같아서 한 번 정리해 두면 좋을 것 같았다.

비동기란 무엇일까?

비동기 처리는 한 줄로 정리하면 기다리지 않고 다른 일을 먼저 하면서, 끝나면 다시 처리하는 방식이다.
작업 중에 시간이 오래 걸리는 일이 있으면 그 자리에서 멈춰서 계속 기다리는 것이 아니라, 그동안 다른 코드부터 실행하고 있다가, 나중에 결과가 준비되면 그때 다시 처리한다.

웹에서는 서버 요청, 데이터 불러오기, API 통신 같은 작업들이 시간이 걸리기 때문에 비동기 처리가 정말 중요하다. 만약 이런 것들이 전부 동기로 동작한다면, 화면이 멈춘 것처럼 보이고 사용자 경험이 크게 나빠질 것이다.

동기와 비동기의 차이

비동기를 이해할 때 가장 도움이 된 건 동기 방식과 비교하는 것이었다.

동기 방식은 모든 작업이 순서대로 진행된다.
앞에 있는 작업이 끝나야 다음 작업이 실행된다.
그래서 앞의 작업이 오래 걸리면 뒤에 있는 작업들도 전부 기다려야 한다.

반면 비동기 방식은 오래 걸리는 작업을 따로 맡겨두고, 그 사이에 실행 가능한 다른 작업을 먼저 처리한다. 그리고 기다리던 작업이 끝나면, 그 결과를 나중에 처리한다.
그래서 실행 순서와 결과 순서가 다를 수 있다는 점이 특징이다. 처음엔 이 부분이 헷갈리지만, 구조를 이해하면 충분히 납득되는 부분이다.

자바스크립트가 비동기를 처리하는 방식

자바스크립트는 기본적으로 한 번에 하나의 작업만 처리하는 언어인데, 그럼에도 불구하고 비동기가 가능한 이유는 내부 구조 때문이다.

현재 실행 중인 코드를 처리하는 영역이 따로 있고, 시간이 오래 걸리는 작업은 별도로 맡겨 두었다가, 작업이 끝나면 다시 실행 가능한 상태로 옮겨 처리한다.
이 덕분에 코드가 위에서 아래로 실행되는데도, 실제 결과는 다른 순서로 나오는 상황이 만들어진다.
이 구조를 이해하고 나니 “왜 분명 위에 쓴 코드가 나중에 실행되지?”라는 의문이 조금씩 풀렸다.

콜백과 콜백 지옥

처음 비동기를 처리할 때 많이 사용하는 방식이 콜백 함수이다.
작업이 끝난 뒤에 실행할 코드를 미리 함수로 넘겨주고, 완료되었을 때 그 함수를 실행하는 방식이다.

문제는 비동기 작업이 많아질 때 생긴다.
콜백 안에 콜백, 그 안에 또 콜백… 이런 구조가 반복되면서 코드가 점점 안쪽으로 파고들고, 이 상황을 콜백 지옥이라고 부른다.
이렇게 되면 가독성도 떨어지고, 유지보수도 어려워진다.

Promise와 async / await

콜백 지옥 문제를 해결하기 위해 등장한 것이 Promise이다.
Promise는 “작업이 성공하면 이렇게, 실패하면 이렇게 처리하겠다” 라는 흐름을 깔끔하게 표현해 주는 방식이다.
이 덕분에 비동기 코드 구조가 훨씬 정리되고 이해하기 쉬워졌다.

여기서 한 단계 더 발전한 방식이 async / await이다.
이 문법을 사용하면 비동기 코드를 마치 일반 코드처럼 자연스럽게 읽히도록 작성할 수 있다.
실제로도 많이 쓰이고, 가독성도 좋아서 앞으로 비동기 처리를 할 때 가장 많이 사용할 것 같다는 생각이 들었다.

정리하면서 느낀 점

비동기는 처음엔 단순히 “순서가 이상한 코드” 정도로만 느껴졌는데,
오늘 정리하면서 왜 이런 방식이 필요한지, 그리고 웹에서 비동기가 얼마나 중요한 개념인지 제대로 이해하게 된 것 같다.

지금은 개념적으로 이해한 단계지만, 나중에 실제 프로젝트에서 API 연결, 데이터 통신, 서버 연동 같은 걸 하게 되면
오늘 정리한 내용이 많이 도움이 될 것 같다.

특히 기억하고 싶은 문장은 이거 하나다.
“비동기는 멈추지 않고, 기다리지 않으며, 나중에 다시 처리한다.”