1. 프로젝트 구조

src/main/java
  ├── com.nhnacademy.todo
      ├── controller       // REST API 엔드포인트 정의
      ├── domain           // JPA 엔티티 클래스
      ├── dto              // 데이터 전송 객체 (DTO)
      ├── repository       // JPA 리포지토리 인터페이스
      ├── service          // 비즈니스 로직 구현
      ├── exception        // 사용자 정의 예외 처리
      └── config           // 설정 파일 (예: CORS, 데이터베이스 등)
src/main/resources
  ├── application.properties // 환경 설정 파일

2. 엔티티

package inho.domain;

import com.fasterxml.jackson.annotation.JsonCreator;
import com.fasterxml.jackson.annotation.JsonProperty;
import jakarta.persistence.*;
import lombok.Data;
import lombok.NoArgsConstructor;
import lombok.extern.slf4j.Slf4j;

import java.time.LocalDateTime;

@Entity
@NoArgsConstructor
@Data
@Table(name = "todos")
@Slf4j
public class Todo {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(name = "subject", nullable = false)
    private String subject;

    @Column(name = "event_at", nullable = false)
    private String eventAt;

    @Column(name = "created_at", nullable = false, updatable = false)
    private LocalDateTime createdAt;

    @JsonCreator
    public Todo(
            @JsonProperty("subject") String subject,
            @JsonProperty("eventAt") String eventAt) {
        this.subject = subject;
        this.eventAt = eventAt;
        log.debug("eventAt 테스트 {}", eventAt);
        this.createdAt = LocalDateTime.now(); // createdAt을 항상 설정
    }

    @PrePersist
    protected void onCreate() {
        if (this.eventAt == null || this.eventAt.isEmpty()) {
            throw new IllegalArgumentException("eventAt 필드는 필수입니다");
        }
        if (this.createdAt == null) {
            this.createdAt = LocalDateTime.now();
        }
    }
}

subject: 할 일 제목

eventAt: 할 일 날짜

createdAt: 생성 날짜 (자동 설정)

@PrePersist: 데이터 저장 전 필수 값 검증

3. 레포지토리

package inho.repository;

import inho.domain.Todo;
import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.data.jpa.repository.Query;

import java.util.List;

public interface TodoRepository extends JpaRepository<Todo, Long> {

    List<Todo> findByEventAt(String eventAt);

    long countByEventAt(String eventAt);

    boolean existsById(Long id);

    @Query("SELECT t from Todo t where t.eventAt LIKE :eventMonth%")
    List<Todo> findEventAtStartingWith(String eventMonth);
}

• 특정 날짜 또는 월별 조회 기능 제공
• @Query를 활용하여 월별 데이터 조회

4. 서비스

서비스 구현 (Service Implementation)

package inho.service.impl;

import inho.domain.Todo;
import inho.exception.MaxTodoLimitExceededException;
import inho.exception.TodoNotFoundException;
import inho.repository.TodoRepository;
import inho.service.TodoService;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

import java.util.List;

@Service
@RequiredArgsConstructor
@Transactional
public class TodoServiceImpl implements TodoService {
    private final TodoRepository todoRepository;
    private static final int DAILY_MAX_TODO_COUNT = 8;

    /**
     * 새로운 TODO를 저장
     */
    public Todo saveTodo(String subject, String eventAt) {
        long count = todoRepository.countByEventAt(eventAt);
        if (count >= DAILY_MAX_TODO_COUNT) {
            throw new MaxTodoLimitExceededException("하루 최대 8개의 TODO만 등록 가능합니다.");
        }
        Todo todo = new Todo(subject, eventAt);
        return todoRepository.save(todo);
    }

    /**
     * 특정 날짜의 모든 TODO 삭제
     */
    public void deleteTodosByDate(String eventAt) {
        List<Todo> todos = todoRepository.findByEventAt(eventAt);
        if (todos.isEmpty()) {
            throw new TodoNotFoundException("해당 날짜(" + eventAt + ")에 등록된 TODO가 없습니다.");
        }
        todoRepository.deleteAll(todos);
    }

    /**
     * 특정 ID의 TODO 삭제
     */
    public void deleteTodoById(Long id) {
        if (!todoRepository.existsById(id)) {
            throw new TodoNotFoundException("ID " + id + "에 해당하는 TODO가 존재하지 않습니다.");
        }
        todoRepository.deleteById(id);
    }

    /**
     * 특정 날짜의 TODO 리스트 조회
     */
    public List<Todo> getTodosByDate(String eventAt) {
       return findTodos(eventAt, false);
    }

    /**
     * 특정 월의 TODO 리스트 조회
     */
    @Transactional(readOnly = true)
    public List<Todo> getTodosByMonth(String eventMonth) {
        return findTodos(eventMonth, true);
    }

    /**
     * 특정 날짜의 TODO 개수 반환
     */
    public long countTodosByDate(String date) {
        return todoRepository.countByEventAt(date);
    }

    /**
     * 특정 ID의 TODO 조회
     */
    public Todo getTodoById(Long id) {
        return todoRepository.findById(id)
                .orElseThrow(() -> new TodoNotFoundException("ID " + id + "에 해당하는 TODO가 존재하지 않습니다."));
    }

    /**
     * 특정 날짜 또는 월의 TODO 리스트 조회 (공통 로직)
     */
    private List<Todo> findTodos(String queryParam, boolean isMonthly){
        return isMonthly ? todoRepository.findEventAtStartingWith(queryParam) : todoRepository.findByEventAt(queryParam);
    }
}

서비스 인터페이스

package inho.service;

import inho.domain.Todo;
import java.util.List;

public interface TodoService {
    Todo saveTodo(String subject, String eventAt);
    void deleteTodosByDate(String eventAt);
    void deleteTodoById(Long id);
    List<Todo> getTodosByDate(String eventAt);
    List<Todo> getTodosByMonth(String eventMonth);
    long countTodosByDate(String date);
    Todo getTodoById(Long id);
}

🔹 핵심 정리

• 비즈니스 로직은 TodoServiceImpl에서 관리
• 인터페이스를 통해 서비스의 계약을 정의
• 트랜잭션을 관리하여 데이터 일관성 유지

5. 컨트롤러

컨트롤러 계층은 클라이언트로부터 HTTP 요청을 받아 서비스 계층을 호출하고, 그 결과를 적절한 HTTP 응답으로 변환하는 역할을 한다.

주요 기능

• TODO 생성: @PostMapping("/events")를 통해 새로운 할 일을 생성한다.
• TODO 삭제: 특정 ID 또는 날짜의 TODO를 삭제한다.
• TODO 조회: 특정 날짜 또는 월의 TODO 리스트를 조회할 수 있다.
• TODO 개수 확인: 특정 날짜의 TODO 개수를 반환한다.

package inho.controller;

import inho.domain.Todo;
import inho.service.TodoService;
import lombok.RequiredArgsConstructor;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.*;

import java.util.List;

@RestController
@RequiredArgsConstructor
@RequestMapping("/api/calendar")
public class TodoController {

    private final TodoService todoService;

    /**
     * 새로운 TODO 생성
     */
    @PostMapping("/events")
    public ResponseEntity<Todo> createTodo(@RequestBody Todo todo) {
        Todo savedTodo = todoService.saveTodo(todo.getSubject(), todo.getEventAt());
        return ResponseEntity.status(201).body(savedTodo);
    }

    /**
     * 특정 ID의 TODO 삭제
     */
    @DeleteMapping("/events/{id}")
    public ResponseEntity<Void> deleteTodoById(@PathVariable Long id) {
        todoService.deleteTodoById(id);
        return ResponseEntity.noContent().build();
    }

    /**
     * 특정 날짜의 모든 TODO 삭제
     */
    @DeleteMapping("/events/daily/{eventAt}")
    public ResponseEntity<Void> deleteTodosByDate(@PathVariable String eventAt) {
        todoService.deleteTodosByDate(eventAt);
        return ResponseEntity.noContent().build();
    }

    /**
     * 특정 날짜의 TODO 리스트 조회
     */
    @GetMapping(value = "/events/", params = {"year", "month", "day"})
    public ResponseEntity<List<Todo>> getTodosByDate(
            @RequestParam int year,
            @RequestParam int month,
            @RequestParam int day
    ){
        String eventAt = String.format("%04d-%02d-%02d", year, month, day);
        List<Todo> todos = todoService.getTodosByDate(eventAt);
        return ResponseEntity.ok(todos);
    }

    /**
     * 특정 월의 TODO 리스트 조회
     */
    @GetMapping(value = "/events/", params = {"year","month"})
    public ResponseEntity<List<Todo>> getTodosByMonth(
            @RequestParam int year,
            @RequestParam int month
    ){
        String eventMonth = String.format("%04d-%02d", year, month);
        List<Todo> todos = todoService.getTodosByMonth(eventMonth);
        return ResponseEntity.ok(todos);
    }
}

🔹 핵심 정리

• 컨트롤러 계층은 클라이언트 요청을 처리하고 응답 반환
• @RequestParam을 활용하여 날짜 및 월별 조회 지원

전반적인 흐름

1. 백엔드 계층 구조

🔹 주요 계층

• 컨트롤러 (Controller): 클라이언트 요청을 받아 처리하고 응답을 반환
• 서비스 (Service): 비즈니스 로직을 수행
• 리포지토리 (Repository): 데이터베이스와 직접적으로 상호작용
• 도메인 (Domain/Entity): 데이터 모델 정의
• 예외 처리 (Exception Handling): 발생하는 예외를 관리하고 적절한 에러 응답을 반환

2. 주요 기능 흐름

🔹 TODO 생성

클라이언트가 POST /api/calendar/events 요청을 보냄

TodoController에서 @RequestBody로 요청 데이터를 받음

TodoService에서 비즈니스 로직 수행 (최대 8개 제한 체크 등)

TodoRepository를 통해 데이터베이스에 저장

저장된 데이터를 클라이언트에 반환 (201 Created 응답)

🔹 TODO 조회

특정 날짜 조회

클라이언트가 GET /api/calendar/events/?year=2024&month=04&day=01 요청

TodoController에서 @RequestParam을 활용해 파라미터를 받음

TodoService에서 findTodos(eventAt, false) 호출

TodoRepository에서 해당 날짜의 데이터를 조회 후 반환

클라이언트에 200 OK 응답과 함께 리스트 반환

특정 월 조회

클라이언트가 GET /api/calendar/events/?year=2024&month=04 요청

TodoService에서 findTodos(eventMonth, true) 호출

TodoRepository에서 해당 월의 데이터를 조회 후 반환

클라이언트에 200 OK 응답과 함께 리스트 반환

🔹 TODO 삭제

특정 ID 삭제

클라이언트가 DELETE /api/calendar/events/{id} 요청

TodoController에서 @PathVariable Long id로 ID 받음

TodoService에서 deleteTodoById(id) 실행

데이터베이스에서 해당 ID 삭제 후 204 No Content 반환

특정 날짜의 모든 TODO 삭제

클라이언트가 DELETE /api/calendar/events/daily/{eventAt} 요청

TodoService에서 deleteTodosByDate(eventAt) 실행

데이터베이스에서 해당 날짜의 TODO 삭제 후 204 No Content 반환

3. 예외 처리 흐름

🔹 예외 발생 시 처리 과정

MaxTodoLimitExceededException: 하루 최대 8개 제한 초과 시 발생

TodoNotFoundException: 삭제 또는 조회 시 해당 데이터가 없을 경우 발생

예외 발생 시 @ControllerAdvice를 통해 글로벌 예외 처리

적절한 HTTP 상태 코드와 메시지를 포함한 JSON 응답 반환

4. 데이터베이스 연동

🔹 TodoRepository

findByEventAt(String eventAt): 특정 날짜의 TODO 조회

findEventAtStartingWith(String eventMonth): 특정 월의 TODO 조회

countByEventAt(String eventAt): 특정 날짜의 TODO 개수 확인

existsById(Long id): 특정 ID 존재 여부 확인

deleteById(Long id): 특정 ID의 TODO 삭제

5. 전체적인 요청 & 응답 흐름

클라이언트 → 컨트롤러 → 서비스 → 리포지토리 → 데이터베이스
           ← 응답 반환 ←

Spring Boot의 핵심 계층을 활용하여 모듈화된 구조로 개발되었으며, 클린 아키텍처를 유지하면서 유지보수성이 높은 구조를 가진다!

데이터 넣기

Front

DB

데이터 삭제

Front

DB

날짜별 삭제

모든 요청에는 반드시 아래 헤더를 포함해야 합니다:

X-USER-ID: 사용자 식별자 (예: "dusen0528")
Content-Type: application/json

🌍 엔드포인트 (Endpoints)

📌 엔드포인트 상세

✅ 1. 새로운 TODO 생성

• 설명: 새로운 TODO를 생성합니다.
• HTTP Method: POST
• URL: /api/calendar/events

헤더:

Content-Type: application/json
X-USER-ID: 사용자 ID

요청 본문 (Request Body):

{
  "subject": "todo 제목",
  "eventAt": "2025-04-02"
}

응답 코드:

• 201 Created: 성공적으로 생성됨 ✅
• 400 Bad Request: 요청 데이터가 잘못됨 ⚠️
• 403 Forbidden: 하루 최대 TODO 개수 초과 ❌

응답 예시:

{
  "id": 123,
  "subject": "todo 제목",
  "eventAt": "2025-04-02",
  "createdAt": "2025-04-02T12:00:00Z"
}

❌ 2. 특정 ID의 TODO 삭제

• 설명: 특정 ID에 해당하는 TODO를 삭제합니다.
• HTTP Method: DELETE
• URL: /api/calendar/events/{id}

헤더:

X-USER-ID: 사용자 ID

응답 코드:

• 204 No Content: 성공적으로 삭제됨 ✅
• 404 Not Found: 해당 ID가 존재하지 않음 ⚠️

응답 예시:

{
  "message": "삭제 완료"
}

🗑 3. 특정 날짜의 모든 TODO 삭제

• 설명: 지정된 날짜의 모든 TODO를 삭제합니다.
• HTTP Method: DELETE
• URL: /api/calendar/events/daily/{todoDate}

헤더:

X-USER-ID: 사용자 ID

응답 코드:

• 204 No Content: 성공적으로 삭제됨 ✅
• 404 Not Found: 해당 날짜에 등록된 TODO가 없음 ⚠️

📅 4. 특정 날짜의 TODO 조회

• 설명: 지정된 날짜에 등록된 모든 TODO를 조회합니다.
• HTTP Method: GET
• URL: /api/calendar/events/?year={year}&month={month}&day={day}

헤더:

X-USER-ID: 사용자 ID

응답 코드:

• 200 OK: 요청 성공 ✅
• 404 Not Found: 해당 날짜에 등록된 TODO가 없음 ⚠️

응답 예시:

[
  {
    "id": 123,
    "subject": "HTML 공부하기",
    "eventAt": "2025-04-02",
    "createdAt": "2025-04-01T12:00:00Z"
  },
  {
    "id": 124,
    "subject": "JavaScript 복습하기",
    "eventAt": "2025-04-02",
    "createdAt": "2025-04-01T13:00:00Z"
  }
]

🔢 5. 특정 날짜의 TODO 개수 조회

• 설명: 지정된 날짜에 등록된 TODO 개수를 반환합니다.
• HTTP Method: GET
• URL: /api/calendar/daily-register-count?date={todoDate}

헤더:

X-USER-ID: 사용자 ID

응답 코드:

• 200 OK: 요청 성공 ✅
• 404 Not Found: 해당 날짜에 등록된 TODO가 없음 ⚠️

응답 예시:

{
  "count": 5
}

🔍 6. 특정 ID의 TODO 조회

• 설명: 특정 ID에 해당하는 단일 TODO를 조회합니다.
• HTTP Method: GET
• URL: /api/calendar/events/{id}

헤더:

X-USER-ID: 사용자 ID

응답 코드:

• 200 OK: 요청 성공 ✅
• 404 Not Found: 해당 ID가 존재하지 않음 ⚠️

응답 예시:

{
  "id": 123,
  "subject": "HTML 공부하기",
  "eventAt": "2025-04-02",
  "createdAt": "2025-04-01T12:00:00Z"
}

📆 7. 월 단위로 TODO 리스트 조회

• 설명: 지정된 연도와 월에 등록된 모든 TODO를 반환합니다.
• HTTP Method: GET
• URL: /api/calendar/events/?year={year}&month={month}

헤더:

X-USER-ID: 사용자 ID

응답 코드:

• 200 OK: 요청 성공 ✅
• 404 Not Found: 해당 월에 등록된 TODO가 없음 ⚠️

응답 예시:

[
  {
    "id": 123,
    "subject": "HTML 공부하기",
    "eventAt": "2025-04-02",
    "createdAt": "2025-04-01T12:00:00Z"
  },
  {
    "id": 124,
    "subject": "JavaScript 복습하기",
    "eventAt": "2025-04-03",
    "createdAt": "2025-04-01T13:00:00Z"
  }
]

🚨 에러 처리 (Error Handling)

사용자가 로그인할 때 발급되는 토큰 이 토큰은 사용자의 정보를 담고 있어서, 사용자가 API 호출할 때 매번 "나는 이 사람이 맞습니다!"라고 증명하는데 사용됨 이 JWT에는 짧은 시간 동안만 유효하고, 만료시 다시 로그인하거나 Refresh Token을 이용해 새로운 AccessToken이 필요

🚨 JWT의 문제점?

로그아웃한 사용자의 JWT를 어떻게 무효화할까?

-> 기본적으로 JWT는 자체적으로 만료되기 전까지 유효함 근데 사용자가 로그아웃했거나, 보안상의 이유로 강제 로그아웃을 해야한다면 어떻게 처리할까?

그냥 토큰 지워버리면 되는거 아닌가요?

JWT는 클라이언트 측에 저장되기 때문에 서버가 JWT를 직접 삭제하거나 만료시킬 방법은 존재하지 않음

💡 세션기반 인증방식과 비교해본다면?

• 세션은 서버에서 관리되므로 사용자가 로그아웃하면 서버에서 세션을 삭제할 수 있음. 하지만 서버 메모리 혹은 DB에 작업해야하므로 서버마다 세션을 저장해야해서 확장성이 떨어짐

토큰을 분산 시스템에서 공유해야 할 때 어떻게 동기화 하지?

-> 여러 서비스에서 인증을 공유할 때, 한 서비스에서 로그아웃 시 다른 서비스에서도 즉시 반영되어야 함

1. Redis란?

1.1 Redis의 역할

토큰 블랙리스트와 Refresh Token 저장

• Redis는 데이터를 메모리에 저장해서 엄청 빠르게 읽고 쓸 수 있다.
• 로그아웃된 JWT를 기억하고 RefreshToken을 안전하게 저장하기 위해서 사용

블랙리스트 관리(로그아웃된 JWT저장)

• 사용자가 로그아웃하면 JWT를 Redis에 넣고 "이 토큰은 더 이상 사용 불가!"로 저장
• API 호출시마다 Redis를 확인해서, 블랙리스트에 있는 토큰이면 거부

Refresh Token 저장

• Access Token은 짧은 시간이 지나면 만료되는데
• 우리가 사용하는 SNS 인스타를 예시로 보면 1시간마다 로그아웃되면 사용자 경험이 현저히 낮아질 것
• 이때 활용되는게 Refresh Token인데, 사용자가 다시 로그인 하지 않도록 이 토큰을 발급해서 새로운 Access Token을 발급해준다.
• 단, 금융 서비스와 같이 보안에 민감한 부분에는 짧은 토큰 만료기간을 설정한 후 만료시, 다시 로그인 하도록 하며 SNS와 같이 사용자 경험이 중요한 서비스의 경우 리프레쉬 토큰 만료 기간을 길게 잡아서 편리한 서비스로 만듬

확장성

• 서버가 여러개여도 Redis가 중앙에서 JWT 블랙리스트를 관리하면 문제 없음

휘발성

• 다만 휘발성이 있기에, 서버가 꺼지면 데이터가 사라질 수 있음
• 따라서 캐시로 많이 사용됨

1.2 Redis 대표적인 기능

• Key-Value 저장소 : "user:123" → {"name": "Alice", "age": 25} 처럼 저장 가능
• 캐싱 : 자주 쓰는 데이터를 저장해서 DB 부하를 줄임
• 토큰 저장 : RefreshToken 저장, JWT 블랙리스트 관리

2. RabbitMQ란?

2-1. RabbitMQ의 역할

각각의 서비스가 독립적으로 동작하면서도, 서로 데이터를 주고 받을 수 있도록 도와주는 메시지 중계소

💡 쉽게 말하면?

• auth 서비스가 blog 서비스로 회원가입 할거야! 라고 메세지를 보내고 싶을 때 RabbitMQ를 거쳐 전달
• 두 서비스가 동시에 연결될 필요 없이 비동기적으로 통신 가능

MSA 구조에서 서비스들끼리 데이터 교환시 사용

🚀 결론적으로

• JWT 인증시 Redis를 통해 빠른 데이터 조회(JWT 블랙리스트, Refresh Token 저장)
• 분산 시스템에서도 중앙화된 Redis 메모리를 통해 인증 정보 공유 가능
• 로그아웃 같은 이벤트를 여러 서비스에 동기화 하기 위해 Rabbit MQ
• 서비스간 독립적인 메세지 전달을 지원하는 장점들을 활용해서

JWT 인증을 구현한다!

Step 1 : 기술 스택 선정

• JWT: 인증 토큰 발급/검증

• Redis: 토큰 블랙리스트 관리, Refresh Token 저장

• RabbitMQ: 분산 시스템 간 이벤트 통신 (로그아웃 알림 등)

• Spring Cloud Gateway: API Gateway 역할

• Spring Security: 인증/인가 처리

• Eureka: 서비스 디스커버리

Step 2 : 아키텍처

[Client]
  │
  ▼ HTTPS
[API Gateway] ───▶ [Auth Service] ↔ Redis (Token Storage)
  │                   │
  │                   ▼
  └──▶ [Blog Service] ←─ RabbitMQ (Logout Events)

Step 3 : Redis 통합 토큰 관리

• Gateway에서 모든 클라이언트 요청을 필터링하며 JWT 검증을 수행
• 블랙리스트에 등록된 토큰은 요청을 차단!
• TokenRepository 사용해서 블랙리스트와 Refresh Token 관리

brew install redis
redis-server --version

위와 같이 설치하기

Redis 명령어

1. Foreground로 실행

redis-server

2. Background로 실행

brew services start redis
brew services stop redis

• redis 테스트

  redis-cli ping

  Redis는 기본적으로 포트 6379에서 작동

Step 3-1 : Redis 설정

pom.xml

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

• redis 의존성 추가

  application.properties

  spring.data.redis.host=localhost
  spring.data.redis.port=6379
  spring.data.redis.password=1234 

• 레디스 정보 설정

Step 3-2 : RedisConfig.class

@Configuration
public class RedisConfig {

    @Bean
    public RedisConnectionFactory redisConnectionFactory() {
        return new LettuceConnectionFactory(); // Lettuce는 비동기 방식으로 높은 성능 제공
    }

    @Bean
    public RedisTemplate<String, String> redisTemplate(RedisConnectionFactory connectionFactory) {
        RedisTemplate<String, String> redisTemplate = new RedisTemplate<>();
        redisTemplate.setConnectionFactory(connectionFactory);
        redisTemplate.setKeySerializer(new StringRedisSerializer()); // Key를 문자열로 직렬화
        redisTemplate.setValueSerializer(new StringRedisSerializer()); // Value를 문자열로 직렬화
        return redisTemplate;
    }
}

• RedisConnectionFactory는 레디스 서버와 연결을 관리하는 객체
• Lettuce는 레디스와 통신할 때 비동기 방식으로 동작해 높은 성능을 제공

• RedisTemplate는 레디스에 데이터를 넣고 가져오는 데 사용하는 주요 도구
  1. connectionFactory: 레디스 서버와 연결을 관리하는 객체를 연결
  2. KeySerializer: 키를 문자열로 변환(직렬화)
  3. ValueSerializer: 값을 문자열로 변환(직렬화)

💡 왜 직렬화가 필요할까?

레디스는 데이터를 네트워크를 통해 주고 받는데, 네트워크에서 데이터를 보내려면 객체를 문자열 혹은 바이트 형태로 바꿔야한다. 이 과정을 직렬화라고 한다.

• RdisConfig는 실행 시 레디스 서버와 연결을 설정
• RedisTemplate를 통해 레디스에 데이터를 저장하거나 가져올 수 있음
  • "user:1"라는 키에 "Inho"라는 값 저장하거나 가져오기

사용 예시

@Autowired
private RedisTemplate<String, String> redisTemplate;

public void useRedis() {
    // 데이터 저장
    redisTemplate.opsForValue().set("user:1", "John");

    // 데이터 가져오기
    String value = redisTemplate.opsForValue().get("user:1");
    System.out.println("user:1의 값은 " + value); // 출력: user:1의 값은 Inho
}

• 데이터를 넣고 가져오는 간단한 예시

Step 3-3 : 토큰 블랙리스트 & 리프레쉬 토큰 관리 클래스

@Component
@RequiredArgsConstructor
public class TokenRepository {

    private final RedisTemplate<String, String> redisTemplate;

    // 블랙리스트에 토큰 추가 (만료 시간 설정)
    public void addToBlacklist(String token, long expiration) {
        redisTemplate.opsForValue().set(token, "blacklisted", expiration, TimeUnit.MILLISECONDS);
    }

    // 블랙리스트 여부 확인
    public boolean isBlacklisted(String token) {
        return Boolean.TRUE.equals(redisTemplate.hasKey(token));
    }

    // Refresh Token 저장 (유저 ID 기준)
    public void storeRefreshToken(String userId, String refreshToken) {
        redisTemplate.opsForValue().set(userId, refreshToken, 7, TimeUnit.DAYS);
    }

    // Refresh Token 조회 (유저 ID 기준)
    public String getRefreshToken(String userId) {
        return redisTemplate.opsForValue().get(userId);
    }
}

메소드 1 : 블랙리스트에 토큰 추가

 // 블랙리스트에 토큰 추가 (만료 시간 설정)
    public void addToBlacklist(String token, long expiration) {
        redisTemplate.opsForValue().set(token, "blacklisted", expiration, TimeUnit.MILLISECONDS);
    }

• 특정 JWT 토큰을 블랙리스트에 추가
• Redis에 토큰을 키로 저장 후 값은 blacklisted로 설정
• 만료시간을 설정해서 밀리초 단위로 설정해서 자동으로 삭제

opsForValue() 메소드

1. 값 저장

redisTemplate.opsForValue().set("key", "value");

Redis에 "key"라는 이름으로 "value"를 저장 기본적으로 만료 시간이 설정되지 않으며, 값은 영구적으로 저장 2. 값 조회

String value = redisTemplate.opsForValue().get("key");

Redis에서 "key"에 해당하는 값을 가져옴 값이 없으면 null을 반환 3. 값 삭제

redisTemplate.delete("key");

특정 키에 저장된 데이터를 삭제 4. 값 저장 (만료 시간 설정)

redisTemplate.opsForValue().set("key", "value", 60, TimeUnit.SECONDS);

"key"에 "value"를 저장하고, 만료 시간을 60초로 설정 만료 시간이 지나면 Redis는 해당 데이터를 자동으로 삭제 5. 키 존재 여부 확인

boolean exists = redisTemplate.hasKey("key");

특정 키가 Redis에 존재하는지 확인 존재하면 true, 없으면 false를 반환

메소드 2 : 블랙리스트 여부 확인

 // 블랙리스트 여부 확인 
    public boolean isBlacklisted(String token){
        return Boolean.TRUE.equals(redisTemplate.hasKey(token));
    }

• 특정 토큰이 블랙리스트에 등록되어 있는지 확인
• 해당 토큰이 Redis에서 키로 존재하는지 검사

메소드 3 : 리프레쉬 토큰 저장

    // 리프레쉬 토큰 저장 
    public void storeRefreshToken(String userId, String refreshToken){
        redisTemplate.opsForValue().set(userId, refreshToken, 7, TimeUnit.DAYS);
    }

• 특정 사용자ID를 기준으로 RefreshToken을 저장
• 리프레쉬 토큰은 7일동안 유지되며, Redis TTL 기능으로 자동 삭제 됨

메소드 4 : 리프레쉬 토큰 조회

// 리프레쉬 토큰 조회 
    public String getRefreshToken(String userId){
        return redisTemplate.opsForValue().get(userId);
    }

• 특정 사용자 ID를 기준으로 리프레쉬 토큰 조회

전체 동작 흐름

1. 로그아웃 처리(블랙리스트)

• 서버가 로그아웃 요청을 받으면 해당 JWT를 addToBlacklist 메소드로 블랙리스트에 추가
• 이후 인증 요청 시 isBlackliste 메소드로 JWT가 블랙리스트에 있는지 확인하고 요청 차단

2. 리프레쉬 토큰 관리

• 사용자가 로그인시 storeRefreshToekn 메소드로 리프레쉬 토큰 저장
• 클라이언트가 새로운 액세스 토큰 요청 시 리프레쉬 토큰 조회 후 검증

JWT 검증 필터 구현은 다음 게시글로 !

"모든 서비스가 자신의 위치(IP, Port)를 등록하고 다른 서비스가 찾을 수 있게 해주는 중앙 등록소"

• 넷플릭스가 개발하고 Spring Cloud에 기여한 오픈소스 서비스 디스커버리 도구
• 마이크로서비스 환경에서 서비스 인스턴스의 위치 정보를 중앙 집중식으로 관리하며, 동적 서비스 탐색과 상태 모니터링 기능을 제공

1.1 아키텍처 구성

[Eureka Server Cluster]
      ⇅      ⇅
[Service A Instance]  
      ⇅      ⇅
[Service B Instance]

1.2 설정 파일

application.properties

server.shutdown=graceful
spring.lifecycle.timeout-per-shutdown-phase=10s

spring.application.name=eureka-server

# 스프링 시큐리티 기본 인증 설정
spring.security.user.name=admin
spring.security.user.password=1234


# 활성화할 프로필 설정
spring.profiles.active=peer1

# 유레카 클라이언트 설정
# 자신을 유레카 서버에 등록하지 않음 (서버 모드)
eureka.client.register-with-eureka=false

# 레지스트리 정보를 로컬에 캐싱하지 않음 (서버 모드)
eureka.client.fetch-registry=false


# 유레카 서버 설정
# 서비스 등록 정보 캐시 갱신 주기 (밀리초)
eureka.server.response-cache-update-interval-ms=5000
# 등록된 서비스 중 비정상 서비스 제거 주기 (밀리초)
eureka.server.eviction-interval-timer-in-ms=5000

• graceful : 서버 종료 시 진행 중인 요청을 처리한 후 종료하는 그레이스풀 셧다운 방식을 사용
• 그레이스풀 셧다운시 최대 10초까지 대기
• 서버 실행될 포트

application-peer1.properties & peer2

peer 1

# 서버 포트 설정
server.port=8761
# 유레카 인스턴스 호스트명
eureka.instance.hostname=peer1
# 유레카 서버 URL 설정 (클러스터링)
eureka.client.service-url.defaultZone=http://admin:1234@peer2:8762/eureka/
# 자신을 유레카 서버에 등록 (클러스터링 모드)
eureka.client.register-with-eureka=true
# 레지스트리 정보를 로컬에 캐싱 (클러스터링 모드)
eureka.client.fetch-registry=true

peer2

# 서버 포트 설정
server.port=8762
# 유레카 인스턴스 호스트명
eureka.instance.hostname=peer2
# 유레카 서버 URL 설정 (클러스터링)
eureka.client.service-url.defaultZone=http://admin:1234@peer1:8761/eureka/
# 자신을 유레카 서버에 등록 (클러스터링 모드)
eureka.client.register-with-eureka=true
# 레지스트리 정보를 로컬에 캐싱 (클러스터링 모드)
eureka.client.fetch-registry=true

• peer1 & peer2 2개의 유레카 서버가 서로 연결되어 서비스 레지스트리 정보를 동기화
• 이를 통해 peer1이 다운되더라도 peer2가 서비스 디스커버리 기능을 계속해서 제공
• 30초 간격으로 서로 레지스트리 정보를 복제
• 모든 유레카 서버는 동일한 서비스 인스턴스 정보를 유지

클라이언트 측 로드 밸런싱

• 클라이언는 두개의 유레카 서버를 설정 파일에서 지정

  eureka.client.service-url.defaultZone=http://admin:1234@localhost:8761/eureka,http://admin:1234@localhost:8762/eureka

  클라이언트는 이 목록에서 하나의 서버를 선택해서 요청을 보냄
• 기본적으로 라운드 로빈 방식으로 유레카 서버를 선택

첫 번째 요청 → Peer1 (http://localhost:8761)

두 번째 요청 → Peer2 (http://localhost:8762)

세 번째 요청 → 다시 Peer1

---
Peer1이 다운된 경우 → Peer2로 요청 전환

Peer2도 다운된 경우 → 서비스 디스커버리 실패

이 방식은 클라이언트와 유레카 서버 간 트래픽을 분산시켜 부하를 줄이는 데 도움을 줌

1.3 Eureka - SecurityConfig

@EnableWebSecurity(debug = false)
@Configuration
public class SecurityConfig {
    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http.csrf(AbstractHttpConfigurer::disable);
        http.authorizeHttpRequests(authorizeRequests ->
            authorizeRequests.anyRequest().authenticated()
        );

        http.httpBasic(Customizer.withDefaults());
        return http.build();
    }
}

• 유레카 서버는 서버-서버간 통신에 사용되기 때문에 불필요한 보안 계층인 CSRF 보호를 비활성화
• Basic Auth로 최소한의 보안 유지

2. Gateway란?

모든 요청의 단일 입구. 적절한 서비스로 안내하고, 보안 검사도 담당

2-1. 아키텍처 구성

[Client] 
  ↓ HTTPS
[API Gateway] : 모든 요청의 단일 진입점
  ⇅ 
[Eureka Server]
  ⇅ 
[Microservices]

2-2. 설정 파일

# 서버 포트 설정
server.port=8080

# 애플리케이션 이름 설정 (유레카에 등록될 서비스 이름)
spring.application.name=api-gateway

# 서비스 디스커버리 활성화 (유레카를 통한 서비스 자동 발견)
spring.cloud.gateway.discovery.locator.enabled=true
# 서비스 ID를 소문자로 변환 (URL 경로에서 대소문자 구분 없이 사용)
spring.cloud.gateway.discovery.locator.lower-case-service-id=true

# 유레카 서버 주소 설정 (클러스터링된 두 서버 모두 등록)
eureka.client.service-url.defaultZone=http://admin:1234@localhost:8761/eureka,http://admin:1234@localhost:8762/eureka
# IP 주소 사용 (호스트명 대신)
eureka.instance.prefer-ip-address=true

# 로깅 레벨 설정 (게이트웨이 디버깅용)
logging.level.org.springframework.cloud.gateway=DEBUG
logging.level.reactor.netty=DEBUG

• 서비스 이름 소문자로 통일
• 커넥션 풀 유휴 시간 기본값 45초

2-3. RouteLocatorConfig

@Configuration
public class RouteLocatorConfig {

    @Bean
    public RouteLocator myRoute(RouteLocatorBuilder builder) {
        return builder.routes()
                .route("auth-service", r -> r
                        .path("/auth/**")
                        .uri("lb://AUTH-SERVICE"))
                .route("blog-service", r -> r
                        .path("/blog/**")
                        .uri("lb://BLOG-SERVICE"))
                .build();

    }
}

• /auth로 시작하는 모든 경로에 대한 요청은 AUTH-SERVICE를 유레카 서비스 목록에서 찾아 로드밸런싱을 통해 하나의 인스턴스로 요청 전달

예시

GET /auth/login → AUTH-SERVICE/auth/login POST /blog/posts → BLOG-SERVICE/blog/posts

2-4. 동작흐름

1. 클라이언트 요청 : GET http://localhost:8080/auth/login
2. 게이트웨이 라우팅 : /auth/** 경로 매칭 -> AUTH-SERVICE로 라우팅 결정
3. Eureka 조회 : 유레카 서버에서 AUTH-SERVICE의 등록된 인스턴스 목록을 가져옴
4. 로드 밸런싱 : 인스턴스중 하나를 선택 (예: http://auth-service-instance:8081)
5. ** 요청 전달** : 선택된 인스턴스의 /auth/login 엔드포인트로 요청 전달

2-5. 대시보드

유레카 서버 http://localhost:8761 에 접속하면 등록된 서비스들이 확인할 수 있다.

전체 동작 아키텍처

[Client] 
  │
  ▼ 
[API Gateway] 
  ├──▶ [Auth Service] /auth/** (JWT 검증 X)
  └──▶ [Blog Service] /blog/** (JWT 검증 O)
        ▲
        │
[Service-to-Service Communication]
        │
        ▼
    [Eureka Server]

1️⃣ 서비스 간 통신 방식

(1) 클라이언트<->서버 통신

모든 클라이언트 요청은 반드시 API Gateway를 통과

(2) 서버<->서버 통신

Eureka를 통한 직접 통신 (Gateway 경유하지 않음)

컴포넌트간 역할 분리

1. 인터페이스 정의

java
@FeignClient(name = "authAdaptor", url = "${api.blog.url}", path = "/api/auth")
public interface AuthAdaptor {
    @PostMapping("/login")
    ResponseEntity<String> login(@RequestBody Map<String, String> loginRequest);
}

• 백엔드 API에게 부탁할 일의 목록과 같음
  • "나는 /api/auth/login으로 POST 요청을 보낼 거야"
  • "이메일과 비밀번호를 JSON으로 보낼 거야"
  • "그리고 문자열(JWT 토큰) 응답을 받을 거야"

2. Spring (자동 구현)

• 스프링은 위 인터페이스를 보고 실제 HTTP 요청을 보내는 코드를 자동으로 만듬

3. 컨트롤러에서 사용하기

@Controller
public class AuthController {
    // Spring이 자동으로 만든 구현체를 여기에 넣어줌
    private final AuthAdaptor authAdaptor;

    @PostMapping("/api/auth/login")
    public String login(...) {
        // 사용자가 입력한 이메일과 비밀번호를 Map에 담기
        Map<String, String> requestBody = new HashMap<>();
        requestBody.put("email", email);
        requestBody.put("password", password);

        // 백엔드 API 호출하기 !!🌟
        ResponseEntity<String> responseEntity = authAdaptor.login(requestBody);

        // 응답 처리하기
        // ...
    }
}

4. 실제 HTTP 요청

POST /api/auth/login HTTP/1.1
Host: api.blog.url
Content-Type: application/json

{
  "email": "user@example.com",
  "password": "userPassword123"
}

5. 백엔드 API 응답

HTTP/1.1 200 OK
Content-Type: text/plain

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

1.인증 관련 Adaptor 생성

import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;

import java.util.Map;

@FeignClient(name = "authAdaptor", url = "${api.blog.url", path = "/api/auth")
public interface AuthAdaptor {
    // "/api/auth/login" 경로로 POST 요청을 보내는 메서드 선언
    @PostMapping("/login")
    ResponseEntity<String> login(@RequestBody Map<String, String> loginRequest);
}

• Feign Client 선언: 백엔드 API와 통신하기 위한 인터페이스

• name은 스프링에서 빈으로 등록할 때 사용

• url : 요청을 보낼 서버의 기본 url(application.properties)

• path : API 기본 경로

• 요청 본문에서 Map형태로 이메일 비밀번호를 담아서 전송

• 응답으로 JWT 토큰을 받음

2. 인증 컨트롤러 생성

@Controller
@RequiredArgsConstructor
public class AuthController {
    private final AuthAdaptor authAdaptor;

     @PostMapping("/api/auth/login")
    public String login(@RequestParam String email, @RequestParam String password,
                        HttpServletResponse response, RedirectAttributes redirectAttributes){
    }
}

• 웹 요청을 처리하는 컨트롤러임을 어노테이션으로 명시
• 백엔드 API와 통신하기 위해 AuthAdaptor 주입 받음
• 폼에서 전송된 email, password 파라미터를 받음
• 또한 파라미터로 리다이렉트 시 데이터 전달을 위한 객체를 받아줌

// 응답 본문에서 JWT 토큰을 추출
String token = responseEntity.getBody();

• 만약 백엔드에서 응답이

HTTP/1.1 200 OK
Content-Type: text/plain

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyQGV4YW1wbGUuY29tIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

이렇게 온다면 getBody는

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyQGV4YW1wbGUuY29tIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

반환 하는데 이것이 JWT 토큰

2-1. Login 메소드 구현

메소드가 해야하는 역할

1. /api/auth/login 경로로 POST 요청이 도착
2. @RequestParam으로 이메일과 비밀번호를 받음
3. 이메일과 비밀번호를 Map에 담아 JSON 형태로 변환

   // 백엔드 API에 보낼 JSON 데이터를 준비 (이메일과 비밀번호)
            Map<String, String> requestBody = new HashMap<>();
            requestBody.put("email", email);
            requestBody.put("password", password);
   

4. AuthAdaptor를 통해 백엔드 API 호출
```java
        ResponseEntity<String> responseEntity = authAdaptor.login(requestBody);

5. 백엔드 API에서 인증 처리 (이메일, 비밀번호 검증 후 성공시 JWT 토큰 생성 후 응답)

6. 응답 코드가 200인지, 응답 본문에서 JWT 토큰 추출

   if(responseEntity.getStatusCode().is2xxSuccessful(){
    // 응답 본문에서 토큰 추출
    String token = responseEntity.getBody();
   
    // jwtToken 이라는 이름의 쿠키 생성
    Cookie cookie = new Cookie("jwtToken", token);
   
    // 쿠키 경로 "/"로 설정(모든 페이지에서 사용이 가능하게)
    cookie.setPath("/");
   
    // 자바스크립트에서 쿠키 접근 할 수 없게 설정(XSS 공격방지)
    cookie.setHttpOnly(true);
   
    // 7. 쿠키를 HTTP 응답에 추가
    response.addCookie(cookie);
   }

7. 성공시 홈페이지로 리다이렉트, 실패시 오류메세지와 함께 로그인 페이지로 이동

                // 홈페이지로 리다이렉트
                return "redirect:/";
            }else{
                 // 로그인 실패시 로그인 페이지로 리다이렉트
                redirectAttributes.addAttribute("error", "true");
                return "redirect:/login";
            }
        }catch(Exception e){
            redirectAttributes.addAttribute("error", "true");
            return "redirect:/login";
        }

2-2. Logout 메소드

    @GetMapping("/logout")
    public String logout(HttpServletResponse response){
        //JWT 토큰 쿠키 삭제
        Cookie cookie = new Cookie("jwtToken", null);
        cookie.setPath("/");
        cookie.setMaxAge(0);
        response.addCookie(cookie);

        return "redirect:/login?logout=true";
    }

• 쿠키값 null 설정
• 모든 경로에서 삭제되도록 설정 후
• 쿠키 즉시 만료 : setMaxAge(0)
• 응답에 쿠키 추가 후
• 로그아웃 메세지와 함께 로그인 페이지로 이동

현재까지 구현된 사항

게이트웨이에서 JWT 인증 필터 구현

• JwtProvider 클래스: 토큰 검증 및 사용자 정보 추출
• JwtAuthenticationFilter 클래스: 요청 필터링 및 인증 처리

  프론트엔드에서 인증 관련 기능 구현

• AuthAdaptor 인터페이스: 백엔드 API와의 통신
• AuthController 클래스: 로그인 및 로그아웃 처리
• 쿠키 기반 JWT 토큰 저장 및 관리

이전게시물

MSA 아키텍처에서는 각 마이크로서비스마다 인증 로직을 반복 구현해줘야 하는데, 이러한 단점을 보완하며 모든 서비스에 동일한 인증 및 권한 부여 정책을 적용하기위해 게이트웨이 패턴을 적용하기로 했다.

• 이점으로는 각 서비스는 인증 로직 없이 비즈니스 로직에만 집중 가능
• 서비스 확장시에 용이

1. SecurityConfig

pom.xml 의존성 추가하기

  <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-security</artifactId>
        </dependency>
        <dependency>
            <groupId>io.jsonwebtoken</groupId>
            <artifactId>jjwt-api</artifactId>
            <version>0.11.5</version>
        </dependency>
        <dependency>
            <groupId>io.jsonwebtoken</groupId>
            <artifactId>jjwt-impl</artifactId>
            <version>0.11.5</version>
            <scope>runtime</scope>
        </dependency>
        <dependency>
            <groupId>io.jsonwebtoken</groupId>
            <artifactId>jjwt-jackson</artifactId>
            <version>0.11.5</version>
            <scope>runtime</scope>
        </dependency>

SecurityConfig

package com.nhnacademy.gateway.config;


import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.reactive.EnableWebFluxSecurity;
import org.springframework.security.config.web.server.ServerHttpSecurity;
import org.springframework.security.web.server.SecurityWebFilterChain;

@Configuration
@EnableWebFluxSecurity
public class SecurityConfig {

    @Bean
    public SecurityWebFilterChain securityWebFilterChain(ServerHttpSecurity http){
        return http
                .csrf(ServerHttpSecurity.CsrfSpec::disable)
                .authorizeExchange(exchanges -> exchanges
                        .pathMatchers("/api/auth/**", "/login", "/register", "/css/**", "/js/**")
                        .permitAll()
                        .anyExchange().authenticated()
                )
                .build();
    }
}

• @EnableWebFluxSecurity: Spring WebFlux 환경에서 Spring Security를 활성화하는 어노테이션
• 리액티브 환경에 맞게 설계됨

💡 리액티브 환경

비동기&논블로킹 방식으로 동작하는 환경 요청이 들어와도 쓰레드를 계속 점유하지 않고, 다른 요청을 처리할 수 있음

🛠 블로킹 vs 논블로킹 비교

1️⃣ 블로킹 I/O (Spring MVC 환경)

@GetMapping("/user")
public String getUser() {
    return userService.getUser(); // DB에서 데이터를 가져올 때까지 스레드 대기 (Blocking)
}

요청이 들어오면 getUser() 실행 후 완료될 때까지 스레드가 블로킹됨. 동시 요청이 많아지면 스레드가 부족해지고 성능 저하 발생. 2️⃣ 논블로킹 I/O (Spring WebFlux 환경)

@GetMapping("/user")
public Mono<String> getUser() {
    return userService.getUser(); // DB에서 데이터 가져오는 동안 스레드는 다른 작업 수행 (Non-blocking)
}

요청을 받으면 바로 Mono을 반환하고 스레드는 다른 요청을 처리. DB 응답이 오면 그때 결과를 전달.

2. JwtAuthenticationFilter

@Component
public class JwtAuthenticationFilter implements GlobalFilter, Ordered {

    private final JwtProvider jwtProvider;
    private final List<String> allowedPaths;

    public JwtAuthenticationFilter(JwtProvider jwtProvider) {
        this.jwtProvider = jwtProvider;
        this.allowedPaths = List.of("/api/auth/login", "/api/auth/register", "/login", "/register");
    }

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        return null;
    }

    @Override
    public int getOrder() {
        return 0;
    }
}

• import org.springframework.beans.factory.annotation.Value;
• Lombok의 Value ❌
• key: JWT 토큰 서명을 검증하는 데 사용되는 키
• allowedPaths: 인증 없이 접근 가능한 경로 목록

생성자

• @Value("${jwt.secret}"): application.properties 또는 application.yml 파일에서 jwt.secret 값을 주입받음
• Keys.hmacShaKeyFor(): 바이트 배열로부터 HMAC-SHA 키를 생성, JWT 토큰 검증에 사용됨
• allowedPaths: 인증이 필요 없는 경로 목록을 초기화

2-1. filter 메소드 구현

• import org.springframework.http.server.reactive.ServerHttpRequest;

• Spring-Cloud-Gateway는 리액티브 기반이기에 패키지 클래스 임포트

  2-2 JwtProvider

  • 게이트웨이에서는 토큰 생성할 필요 없이 검증만 하고
  • 백엔드에서는 validateTokenOrThrow(String token) 메서드가 있어 토큰이 유효하지 않을 경우 예외를 발생 시키는데, 게이트웨이는 필터 내에서 직접 토큰 유효성을 확인하고 401 응답을 반환
  • 위의 사항을 고려 최소한의 기능으로 만든 JwtProvider도 Gateway에 만들어줘야함

    package com.nhnacademy.gateway.security;
    

  import io.jsonwebtoken.Claims; import io.jsonwebtoken.Jwts; import io.jsonwebtoken.security.Keys; import org.springframework.beans.factory.annotation.Value; import org.springframework.stereotype.Component;

  import java.security.Key;

  @Component public class JwtProvider {

  private final Key key;
  
  public JwtProvider(@Value("${jwt.secret}") String secretKey) {
      byte[] keyBytes = secretKey.getBytes();
      this.key = Keys.hmacShaKeyFor(keyBytes);
  }
  
  // 토큰 검증
  public boolean validateToken(String token) {
      try {
          Jwts.parserBuilder()
                  .setSigningKey(key)
                  .build()
                  .parseClaimsJws(token);
          return true;
      } catch (Exception e) {
          return false;
      }
  }
  
  // 토큰에서 이메일 추출
  public String getEmailFromToken(String token) {
      Claims claims = Jwts.parserBuilder()
              .setSigningKey(key)
              .build()
              .parseClaimsJws(token)
              .getBody();
      return claims.getSubject();
  }

  }

  ```

• filter 메서드는 Spring Cloud Gateway에서 모든 요청이 통과하는 필터 로직을 구현

• public Mono filter(ServerWebExchange exchange, GatewayFilterChain chain)

• 파라미터로 웹 요청과 응답에 대한 컨테이너인 SeverWebExchange, 필터 체인을 위한 파라미터

  @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        // 1. 요청 정보 추출
        ServerHttpRequest request = exchange.getRequest(); // Spring WebFlux에서 HTTP 요청 정보를 담고 있는 객체
        String path = request.getURI().getPath(); // 요청 URL에서 경로 부분만 추출 ("/api/auth/login")
  
        // 2. 인증 예외 경로 확인
        if(isAllowedPath(path)){
            return chain.filter(exchange); // 인증 필요없는 경로면 다음 필터로 요청 전달
        }
  
        // 3. 정적 리소스 확인
        if (path.startsWith("/css/") || path.startsWith("/js/")) {
            return chain.filter(exchange);
        }
  
        // 4. JWT 토큰 추출
        String token = extractToken(request); // Authorization" 헤더에서 "Bearer " 다음에 오는 문자열을 토큰으로 추출
  
        // 5. 토큰 검증 및 오류 처리
        if (token == null || !jwtProvider.validateToken(token)) {
            ServerHttpResponse response = exchange.getResponse();
            response.setStatusCode(HttpStatus.UNAUTHORIZED);
            return response.setComplete();
        }
  
        // 6. 사용자 정보 추가
        String email = jwtProvider.getEmailFromToken(token);
  
        ServerHttpRequest modifiedRequest = request.mutate()
                .header("X-User-Email", email)
                .build();
  
      // 7. 수정된 요청 전달
        return chain.filter(exchange.mutate().request(modifiedRequest).build());
    }  

1. 요청 경로를 확인하여 인증이 필요한지 판단
2. 인증이 필요없는 경로인지 판단 후 필요없을 시 다음 필터로 요청 그대로 전달
3. 경로가 정적 리소스인지 확인, 정적 리소스는 인증 없이 접근 가능 해야하기 때문
4. Authorization 헤더에서 Bearer 토큰 추출
5. 토큰이 없거나, 유효성 검증 실패시 ,401 상태코드 설정 후 응답 완료 후 클라이언트에게 반환

-> 즉 유효하지 않은 토큰 접근 시 인증 오류 반환 6. 토큰에서 사용자 이메일 추출 후, mutate() 메소드를 통해 기존 요청 객체를 수정하기 위한 빌더 생성 -> header로 사용자 이메일 정보 추가 -> .build() 수정된 요청 객체 생성 7. 수정된 요청을 전달하는데, 기존 교환 객체를 수정하기 위해 빌더 생성 후 수정된 요청 객체를 교환 객체에 설정 후 생성! -> 수정된 교환 객체를 다음 필터로 전달

2-2. getOrder 메소드

  @Override
    public int getOrder() {
        return -1;
    }

• JWT 인증 필터는 일반적으로 다른 필터보다 먼저 실행되어야 하므로 getOrder 값을 음수로 설정

이제 JWT 인증필터가 게이트웨이에 구현되었기에

• 인증되지 않은 요청은 게이트웨이에서 차단
• 각 마이크로서비스마다 JWT 인증 로직을 구현할 필요 없음
• 모든 서비스에 동일한 인증 정책 적용됨

게이트웨이는 다음과 같은 역할을 수행

• JWT 토큰 검증
• 인증되지 않은 요청 차단 (401 응답 반환)
• 인증된 요청에 사용자 정보 추가 (X-User-Email 헤더)
• 인증된 요청을 적절한 백엔드 서비스로 라우팅

백엔드 서비스는 게이트웨이가 추가한 X-User-Email 헤더를 통해 사용자를 식별할 수 있으며, 추가적인 권한 검사나 비즈니스 로직에 집중할 수 있게 됨

JWT(JSON Web Token)는 사용자가 로그인에 성공한 후, 서버가 발급해주는 인증 토큰 이 토큰은 클라이언트가 서버에 요청할 때마다 자신이 인증된 사용자라는 것을 증명하는 데 사용됨

JWT의 구성요소

• Header : 토큰의 타입(JWT)와 서명 알고리즘 포함
• Payload : 사용자 정보 포함
• Signature : 토큰이 변조되지 않았음을 보장하기 위해 생성된 서명

JWT 특징

• REST API와 같은 상태 없는 통신에서 사용자 인증을 처리하는데 적합하다
• 서버가 클라이언트의 상태(Session)를 저장할 필요가 없다.
• 대부분의 인증 정보는 JWT(민감한 정보는 제외)에 포함되어 클라이언트와 함께 전송됨
• 이러한 사이트에서 바로 복호화가 가능함

사용자가 로그인 시 서버는 JWT 발급 -> 이후 요청시마다 이 토큰을 통해 인증처리

• JWT는 사용자 정보를 페이로드에 포함가능하기에 추가적인 데이터 전달이 가능 (Role, userID, 만료 시간 등..)

• 서버가 상태를 저장하지 않기에 서버 부하 감소

• 서명을 통해 토큰이 변조되지 않았음을 보장

• 클라이언트가 서버로부터 받은 JWT만 있다면 서버는 추가적인 DB조회없이 사용자 인증 가능

• 토큰에 만료시간 설정 가능함, 하지만 한번 발급되면 만료시간까지 유효하기 때문에 서버에서 강제로 만료시키기 어려움

• *사용자가 로그아웃해도 기존 토큰 유효 *

• JWT는 모든 데이터를 자체적으로 포함하기에 크기가 커질 수 있음

• 비밀키 유출시 모든 JWT가 위조될 수 있음

즉 REST API에서 인증 정보를 안전하게 받고 변조 방지를 위해 JWT

우선 로그인 요청 DTO를 만들어준다. 로그인 시에는 이메일, 패스워드만 있으면 되기 때문에

package com.nhnacademy.blog.member.dto;

import lombok.Getter;
import lombok.NoArgsConstructor;

@Getter
@NoArgsConstructor
public class MemberLoginRequest {
    private String mbEmail;
    private String mbPassword;
}

위와 같이 만들었음

1. JWT 토큰 생성 컴포넌트

이제 JWT 토큰을 생성하고 검증하는 컴포넌트가 필요하다. JwtTokenProvider.java

package com.nhnacademy.blog.common.security;

import org.springframework.beans.factory.annotation.Value;
import org.springframework.stereotype.Component;

@Component
public class JwtProvider {
    private final Key key;

    // @Value 어노테이션을 사용해 설정 파일에서 값을 주입받음
    public JwtProvider(@Value("${jwt.secret}") String secretKey) {
        // Base64로 인코딩된 비밀키를 디코딩하여 Key 객체 생성
        byte[] keyBytes = secretKey.getBytes();
        this.key = Keys.hmacShaKeyFor(keyBytes);
    }


}

• 스프링 빈으로 등록해서 다른 클래스에서 주입 받아 사용할 수 있도록 @Component
• application.properties에 설정된 값 가져오기
  • secretKey : JWT 암호화시 사용하는 비밀키
  • validityInMilliseconds : JWT 토큰 만료될 때까지 유효시간 설정

2. JWT 토큰 생성 메소드

   public String generateToken(String email) {
        Date now = new Date();
        Date validity = new Date(now.getTime() + 3600000); // 1시간 유효

        return Jwts.builder()
                .setSubject(email) // 사용자 이메일을 subject로 설정
                .setIssuedAt(now) // 발급 시간 설정
                .setExpiration(validity) // 만료 시간 설정
                .signWith(key, SignatureAlgorithm.HS256) // Key 객체와 알고리즘을 사용해 서명
                .compact(); // 최종적으로 문자열 형태의 JWT 반환
    }
    }

• subject는 JWT의 페이로드에 포함될 주요 데이터(사용자 식별 정보)

• 로그인 성공시 사용자 이메일을 JWT subject 필드에 저장해서 이후 요청에서 사용자 식별 가능

• 토큰이 일정 시간 후 만료되게 설정

• HS256 알고리즘 사용

3. 토큰 검증 및 사용

 public boolean validateToken(String token){
        try{
            Jwts.parserBuilder()
                    .setSigningKey(key) // 서명을 검증하기 위해 키를 설정
                    .build()   // 파서를 빌드하여 실제 검증 작업을 수행할 준비를 완료
                    .parseClaimsJws(token); // 전달받은 토큰을 파싱하여 서명 및 구조가 올바른지 확인

            return true;
        }catch(Exception e){
            return false;
        }
    }

 // 유효하지 않은 토큰 예외

public void validateTokenOrThrow(String token) {
        //validateToken 메소드를 호출하여 토큰의 유효성을 확인
        if (!validateToken(token)) {
            throw new TokenIsNotValidException("유효하지 않은 토큰입니다");
        }
    }

• Jwts.parserBuilder() : 서명을 검증하기 위해 키를 설정하는데 이때 이 키는 토큰 생성시 사용된 비밀키와 동일해야함
• 이를 통해 클라이언트가 제공한 토큰이 변조되지 않았고, 서버에서 발급된 것인지 확인 가능
• setSigningKey(key)는 토큰의 서명이 비밀키로 생성되었는지 확인하는 중요한 단계

3-1. JWT 이메일 추출

  public String getEmailFromToken(String token) {
        return Jwts.parserBuilder()
                .setSigningKey(key) // 서명을 검증하기 위해 키를 설정
                .build() // 파서를 빌드하여 실제 검증 작업을 수행할 준비 완료
                .parseClaimsJws(token) // 전달받은 토큰을 파싱하여 Claims 객체 반환
                .getBody() // Claims 객체에서 페이로드(body)를 가져옴
                .getSubject(); // 페이로드에서 subject 필드(사용자 이메일)를 가져옴
    }

• 사용자가 로그인하면 이 메서드를 호출하여 JWT를 생성하고 클라이언트에게 반환

4. JWT를 활용하여 인증 및 권한 부여를 시스템에 통합하기

4-1. Spring Security와 JWT 통합

SecurityConfig 설정

@Configuration
@RequiredArgsConstructor
public class SecurityConfig {

    private final JwtProvider jwtProvider;

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity httpSecurity) throws Exception {
        httpSecurity.csrf(csrf -> csrf.disable())
                .authorizeHttpRequests(auth ->
                        auth.requestMatchers("/api/auth/**").permitAll()
                                .anyRequest().authenticated());

        return httpSecurity.build();
    }
}

• REST API는 클라이언트가 매번 인증 정보를 포함하여 요청하므로 CSRF 보호가 필요❌
• 요청별로 보안 정책 설정
• /api/auth/** 경로로 들어오는 요청은 인증 없이 접근가능하게 허용
• 위에 명시된 경로를 제외한 모든 요청은 인증 필요

4-2. JwtAuthenticationFilter

• 클라이언트가 요청시 전달한 JWT를 검증, 인증 정보를 SecurityContextHolder에 저장하는 역할
• Spring Security Filter Chain에 등록되어 모든 요청 처리전 실행됨

@RequiredArgsConstructor
public class JwtAuthenticationFilter extends OncePerRequestFilter {

    private final JwtProvider jwtProvider;

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {

    }
}

• OncePerRequestFilter : Spring Security의 기본 필터를 확장하여 요청마다 한 번만 실행되는 필터

JWT는 Authorization 헤더에 포함된다.

• 클라이언트는 서버에 요청시 JWT를 HTTP 헤더에 포함

  Authorization: Bearer <JWT>

• Bearer는 단순히 토큰임을 나타내는 접두사

실제 JWT는 Bearer뒤에 있는 값이므로 잘라내는 메소드

  // Authorization 헤더에서 Bearer 토큰 추출
    private String extractToken(HttpServletRequest request) {
        String header = request.getHeader("Authorization");
        if (header != null && header.startsWith("Bearer ")) {
            return header.substring(7); // "Bearer " 이후의 토큰만 추출
        }
        return null; // 헤더가 없거나 Bearer로 시작하지 않으면 null 반환
    }

doFilterInternal 요청이 들어올 때마다 실행되는 메소드

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
        // 요청 헤더에서 JWT 추출
        String token = extractToken(request);

        if(token!=null && jwtProvider.validateToken(token)){
            String email = jwtProvider.getEmailFromToken(token);
            UsernamePasswordAuthenticationToken authentication =
                    new UsernamePasswordAuthenticationToken(email, null, null);

            SecurityContextHolder.getContext().setAuthentication(authentication);
        }
        filterChain.doFilter(request, response);
    }

• extractToken으로 실제 토큰 값 추출
• 클라이언트가 JWT를 보내는지 확인 후 보냈다면 JWT가 유효한지 확인 + 서명이 올바른가, 만료되지 않았는가 등
• getEmailFromToken을 통해 토큰에서 이메일 꺼낸 후 SpringSecurity에서 사용하는 인증 객체 UsernamePasswordAuthenticationToken에다가 이메일만 인증정보로 설정
• 이후 SpringSecurtiy 컨텍스트에 인증 정보 저장
• 이를 이용해 추후 컨트롤러에서 인증된 사용자 정보 사용 가능
• 필터 작업이 끝나면 요청을 다음 필터로 전달

4-3.만든 필터를 SecurityConfig에 추가하기

  @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity httpSecurity) throws Exception {
        httpSecurity.csrf(csrf -> csrf.disable())
                .authorizeHttpRequests(auth ->
                        auth.requestMatchers("/api/auth/**").permitAll()
                                .anyRequest().authenticated())  
                .addFilterBefore(new JwtAuthenticationFilter(jwtProvider), UsernamePasswordAuthenticationFilter.class);

        return httpSecurity.build();
    }

• Spring Security의 기본 인증 필터(UsernamePasswordAuthenticationFilter) 앞에 JwtAuthenticationFilter를 추가

4-4. RefreshToken 고민

Access Token은 보안상의 이유로 짧은 유효기간(예: 15분1시간)을 설정함 만료된 Access Token은 더 이상 사용할 수 없으므로 클라이언트는 새로운 Access Token을 발급받아야 함 Refresh Token은 Access Token이 만료되었을 때 새로운 Access Token을 발급받기 위해 사용됨 Refresh Token은 상대적으로 긴 유효기간(예: 7일30일)을 가지며, 서버에서 안전하게 관리됨

추후에 필요시 구현하기 지금 당장은 꼭 필요한지 모르겠다

5. AuthController에 추가하기

5-1. AuthService 인터페이스에 로그인 메소드 추가

    @Override
    public String login(MemberLoginRequest memberLoginRequest) {
        Member member = memberRepository.findByMbEmail(memberLoginRequest.getMbEmail())
                .orElseThrow(()->new NotFoundException("이메일 또는 비밀번호가 일치하지 않습니다"));

        if (!passwordEncoder.matches(memberLoginRequest.getMbPassword(), member.getMbPassword())) {
            throw new UnauthorizedException("이메일 또는 비밀번호가 일치하지 않습니다.");
        }

        return jwtProvider.generateToken(member.getMbEmail()); // JWT 생성 후 반환 
    }

• 이메일로 멤버 조회후 존재하지 않을시 예외 발생
• 만약 입력된 비밀번호와 DB에 저장된 암호화된 비밀번호 비교 후 일치하지 않을 시 예외 발생
• 인증 성공시 JWT 토큰 생성 후 반환

5-2. AuthController에 로그인 엔드 포인트 추가

   @PostMapping("/login")
    public ResponseEntity<String> login(@RequestBody MemberLoginRequest memberLoginRequest){
        String token = authService.login(memberLoginRequest);
        return ResponseEntity.ok(token);
    }

• /api/auth/login 주소로 POST 요청시

  POST /api/auth/login
  Content-Type: application/json
  

{ "mbEmail": "test@example.com", "mbPassword": "password123" }

이와 같은 요청이 오는데

public ResponseEntity login(@RequestBody MemberLoginRequest memberLoginRequest){

- 클라이언트가 보낸 JSON 형식의 요청 데이터를 자바 객체(MemberLoginRequest)로 변환하여 받음
- authService.login 메소드로 생성된 JWT를 클라이언트에게 반환
- 클라이언트는 이 JWT를 사용해서 인증이 필요한 API 호출

🌟 **전체 흐름**
![](https://velog.velcdn.com/images/_inho/post/cc8556a0-2e77-4c48-b4c8-1bfb2951f7c1/image.png)

## 6. 추가된 기능 테스트하기 by Mockito

### 6-1. 로그인 성공 테스트
```java
 @Test
    @DisplayName("로그인 성공 테스트")
    void loginSuccess() {
        // Given: 로그인 요청 데이터 준비
        MemberLoginRequest loginRequest = new MemberLoginRequest("test@nhnacademy.com", "password123123!");

        // Mock 설정: 데이터베이스에서 사용자 조회
        Member member = Member.ofNewMember(
                "test@nhnacademy.com",
                "TestUser",
                passwordEncoder.encode("password123123!"),
                "01012345678"
        );

        Mockito.when(memberRepository.findByMbEmail(Mockito.anyString())).thenReturn(Optional.of(member));
        // Mock 설정: JWT 생성 동작 정의 (Mock)
        Mockito.when(jwtProvider.generateToken(Mockito.anyString())).thenReturn("mock-jwt-token");

        // When: 로그인 로직 실행
        String token = authService.login(loginRequest);

        // Then: 결과 검증
        assertNotNull(token);
        assertEquals("mock-jwt-token", token);
    }

• 
• @Spy 어노테이션은 내가 모킹해주는 메소드에 한해서만 모킹하고 나머지는 실제 메소드가 동작
• 이와 같이 설정해준 후 테스트 진행

6-2. 로그인 실패 테스트 - 비밀번호 불일치

    @Test
    @DisplayName("로그인 실패 테스트 - 비밀번호 불일치")
    void loginFail() {
        // Given: 로그인 요청 데이터 준비
        MemberLoginRequest loginRequest = new MemberLoginRequest("test@nhnacademy.com", "temp");

        // Mock 설정: 데이터베이스에서 사용자 조회
        Member member = Member.ofNewMember(
                "test@nhnacademy.com",
                "TestUser",
                passwordEncoder.encode("password123123!"),
                "01012345678"
        );

        Mockito.when(memberRepository.findByMbEmail(Mockito.anyString())).thenReturn(Optional.of(member));

        // When & Then: 로그인 로직 실행 시 UnauthorizedException 발생 확인
        assertThrows(UnauthorizedException.class, () -> authService.login(loginRequest));

    }

• 로그인 실패 테스트
• 요청 비밀번호, 저장된 비밀번호 일부러 실패하게 만든후 예외 확인

6-3. 로그인 실패 테스트 - 존재하지 않는 이메일

  @Test
    @DisplayName("로그인 실패 테스트 - 존재하지 않는 이메일")
    void notFoundEmail(){
        Mockito.when(memberRepository.findByMbEmail(Mockito.anyString())).thenReturn(Optional.empty());

        assertThrows(NotFoundException.class, ()->{
            authService.login(new MemberLoginRequest("testmail", "testpass"));
        });
    }

• 메일로 멤버 조회시 일부러 Optional.empty 리턴
• 이후 로그인 시 NotFound 예외 발생하는지 검증

7. JwtProvider 검증

7-1. 환경 설정

   private JwtProvider jwtProvider;
    private final String secretKey = "7c83e8ed501e28981f123d88ca87fa8a61277945c39b18a14ec8816986f96399"; // 테스트용 시크릿 키
    private final String testEmail = "test@example.com";

    @BeforeEach
    void setUp() {
        jwtProvider = Mockito.spy(new JwtProvider(secretKey));
    }

• 테스트용 시크릿키 및 테스트 데이터
• Mockito.spy로 JwtProvider 초기화

7-2. 토큰 생성 테스트

  @Test
    @DisplayName("토큰 생성 테스트")
    void generateToken() {

        // jwt 토큰이 mock-jwt-token 반환하도록 설정
        doReturn("mock-jwt-token").when(jwtProvider).generateToken(testEmail);

        // 테스트 이메일로 토큰 생성
        String token = jwtProvider.generateToken(testEmail);

        // 생성된 토큰이 NULL이 아닌지
        assertNotNull(token);

        // 생성된 토큰이 비어있지 않은지
        assertFalse(token.isEmpty());

        // mock-jwt-token인지
        assertEquals("mock-jwt-token", token);
    }

• generateToken() 메소드가 정상적으로 실행되며, mock-jwt-token이 반환되는지 확인

7-3. 유효한 토큰 검증

 @Test
    @DisplayName("유효한 토큰 검증 성공")
    void validateToken_validToken_returnsTrue() {
        String token = "valid-token";
        // validateToken시 true 반환
        doReturn(true).when(jwtProvider).validateToken(token);

        // 생성된 토큰 검증 (성공 예상)
        boolean isValid = jwtProvider.validateToken(token);

        //  검증 결과가 true인지 확인
        assertTrue(isValid);
    }

• validateToken()이 true를 반환하는지 테스트

7-4. 유효하지 않은 토큰 검증 (실패)

    @Test
    @DisplayName("유효하지 않은 토큰 검증 실패")
    void validateToken_invalidToken_returnsFalse() {
        // 유효하지 않은 토큰 생성
        String invalidToken = "wrong-token";
        doReturn(false).when(jwtProvider).validateToken(invalidToken);

        // 유효하지 않은 토큰 검증 (실패 예상)
        boolean isValid = jwtProvider.validateToken(invalidToken);

        // 검증 결과가 false인지 확인
        assertFalse(isValid);
    }

• validateToken()이 false를 반환하는지 테스트

7-5. 유효한 토큰 검증 시 예외 발생 X

    @Test
    @DisplayName("유효한 토큰 검증 시 예외 발생하지 않음")
    void validateTokenOrThrow_validToken_noException() {
        //  테스트 이메일로 토큰 생성
        String token = "valid-token";
        doNothing().when(jwtProvider).validateTokenOrThrow(token);

        //  예외가 발생하지 않는지 확인
        assertDoesNotThrow(() -> jwtProvider.validateTokenOrThrow(token));
    }

• validateTokenOrThrow()가 정상적으로 실행되는지 확인.

7-6. 유효하지 않은 토큰 검증 시 예외 발생

    @Test
    @DisplayName("유효하지 않은 토큰 검증 시 예외 발생")
    void validateTokenOrThrow_invalidToken_throwsException() {
        // 유효하지 않은 토큰 생성
        String invalidToken = "inValid-token";
        doThrow(new TokenIsNotValidException("유효하지 않은 토큰입니다.")).when(jwtProvider).validateTokenOrThrow(invalidToken);

        //  TokenIsNotValidException 예외가 발생하는지 확인
        assertThrows(TokenIsNotValidException.class, () -> jwtProvider.validateTokenOrThrow(invalidToken));
    }

• TokenIsNotValidException이 발생하는지 검증.

7-7. 토큰에서 이메일 추출 테스트

  @Test
    @DisplayName("토큰에서 이메일 추출 테스트")
    void getEmailFromToken() {
        // 테스트 이메일로 토큰 생성
        String token = "valid-token";
        doReturn(testEmail).when(jwtProvider).getEmailFromToken(token);

        // 토큰에서 이메일 추출
        String email = jwtProvider.getEmailFromToken(token);

        // 추출한 이메일, 테스트 이메일 비교
        assertEquals(email, testEmail);
    }

• getEmailFromToken()이 예상한 이메일 값을 반환하는지 확인.

추후에 공부할 내용

• Refresh Token 관리 방식

  • DB저장? Redis?
  • Refresh Token 탈취방지 보안 이슈

• JWT Payload

  • Payload 암호화 되지 않으므로 민감한 정보 포함 X
  • 추가 정보 필요시 DB 조회

• JWT 발급 후 클라이언트에서 저장 방식

  • LocalStorage는 보안상 위험 -> HTTP ONLY 쿠키 사용 권장
  • 쿠키 사용지 CORS, Secure 설정 고려

• 로그아웃 처리

  • Access Token은 클라이언트가 갖고 있기 때문에 서버에서 강제 만료 어렵
  • 보통 Refresh Token을 서버에서 삭제하는 방식으로 처리

내용 정리

1. JWT 인증 시스템 구현 JwtProvider: JWT 토큰 생성, 검증, 이메일 추출 기능 구현

generateToken(String email): 사용자 이메일로 JWT 토큰 생성

validateToken(String token): 토큰 유효성 검증

getEmailFromToken(String token): 토큰에서 이메일 추출

JwtAuthenticationFilter: 요청 헤더에서 JWT 토큰을 추출하고 검증하는 필터

모든 요청에 대해 Authorization 헤더에서 Bearer 토큰을 추출

토큰 검증 후 인증 정보를 SecurityContext에 설정

PasswordEncoder: 비밀번호 암호화 및 검증

BCrypt 알고리즘을 사용한 비밀번호 암호화

로그인 시 비밀번호 일치 여부 검증

2. 인증 관련 API 구현 회원가입 API: /api/auth/register

사용자 정보(이메일, 이름, 비밀번호, 연락처 등) 저장

블로그 생성 및 카테고리 설정

로그인 API: /api/auth/login

이메일과 비밀번호로 사용자 인증

인증 성공 시 JWT 토큰 발급

3. 보안 설정 SecurityConfig: Spring Security 설정

CSRF 보호 비활성화 (REST API이므로)

세션 관리 정책을 STATELESS로 설정

인증이 필요한 경로와 필요하지 않은 경로 설정

JwtAuthenticationFilter 등록

4. 예외 처리 NotFoundException: 리소스를 찾을 수 없을 때 발생

UnauthorizedException: 인증 실패 시 발생

TokenIsNotValidException: 유효하지 않은 토큰일 때 발생

5. 테스트 코드 AuthServiceImplTest: 회원가입 및 로그인 기능 테스트

JwtProviderTest: JWT 토큰 생성, 검증, 이메일 추출 기능 테스트

@Entity
@Table(name = "blog_member_mappings",
    indexes = {
        @Index(name = "uk_blog_member_mapping",columnList = "mb_no, blog_id, role_id", unique = true)
    }
)
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@ToString
@Getter
public class BlogMemberMapping {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "blog_member_id")
    private Long blogMemberId;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "mb_no", referencedColumnName = "mb_no", nullable = false)
    private Member member;

    @Setter
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name="blog_id", referencedColumnName = "blog_id", nullable = false)
    private Blog blog;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name="role_id", referencedColumnName = "role_id", nullable = false)
    private Role role;

    private BlogMemberMapping(Member member, Blog blog, Role role) {
        this.member = member;
        this.blog = blog;
        this.role = role;
    }

    public static BlogMemberMapping ofNewBlogMemberMapping(Member member, Blog blog, Role role) {
        return new BlogMemberMapping(member,blog,role);
    }

}

블로그 멤버 매핑은 Role, Blog, Member 세 가지 엔티티를 연결하는 중요한 관계 엔티티이다. 이러한 복잡한 관계를 테스트할 때 단위 테스트와 통합 테스트 각각의 적합성에 대해서 고민한 내용에 대해 얘기해보려한다.

이전에 Blog, Member 등에 대해서는 테스트 코드를 작성할 때 당연히 단위 테스트로 진행했다.

BlogRepositoryTest

@SpringBootTest
@ActiveProfiles("test")

class BlogRepositoryTest {

    @Autowired
    BlogRepository blogRepository;


    Blog blog = null;


    @BeforeEach
    void setUp(){
        blog = Blog.ofNewBlog(
                "testFid",
                true,
                "testBlogName",
                "testNickName",
                "testDescription"
        );

        blogRepository.save(blog);
    }

    @AfterEach
    void tearDown(){
        blogRepository.delete(blog);
    }

    @Test
    @DisplayName("블로그 아이디 - 블로그 찾기 ")
    void findBlogsByBlogId() {

        Optional<Blog> testBlog = blogRepository.findBlogsByBlogId(blog.getBlogId());

        assertNotNull(testBlog);

        assertAll(
                ()-> assertEquals(true, testBlog.get().isBlogMain()),
                ()-> assertEquals("testFid", testBlog.get().getBlogFid()),
                ()-> assertEquals("testBlogName",testBlog.get().getBlogName()),
                ()-> assertEquals("testNickName", testBlog.get().getBlogMbNickname()),
                ()-> assertEquals("testDescription", testBlog.get().getBlogDescription())
        );
    }
   ...
  }

BlogServiceTest

@ActiveProfiles("test")
@SpringBootTest
@Transactional
class BlogServiceImplTest {

    @Mock // 블로그레포지토리는 테스트가 끝났으므로 (검증 완료) 실제 객체가 아닌 Mock 객체
    BlogRepository blogRepository;

    @InjectMocks // Mock 객체 자동 주입 후 AutoWired
    BlogServiceImpl blogService;



    @Test
    @DisplayName("블로그 저장")
    void saveBlog() {
        BlogRequest blogRequest = new BlogRequest(
                "testFid",
                true,
                "testName",
                "testNickName",
                "testDescription"
        );

        Mockito.doAnswer(invocationOnMock -> {
                  Blog blog = invocationOnMock.getArgument(0);
                  Field blogId = Blog.class.getDeclaredField("blogId");
                  Field createdAt = Blog.class.getDeclaredField("createdAt");
                  blogId.setAccessible(true);
                  blogId.set(blog, 1L);

                  createdAt.setAccessible(true);
                  createdAt.set(blog, LocalDateTime.now());
                  return null;
                })
                .when(blogRepository)
                .save(Mockito.any(Blog.class));

        BlogResponse blogResponse =  blogService.saveBlog(blogRequest);

        assertNotNull(blogResponse);

        assertAll(
                ()-> assertNotNull(blogResponse.getBlogId()),
                ()-> assertTrue(blogResponse.getCategories().isEmpty()),
                ()-> assertTrue(blogResponse.getBlogMemberMappings().isEmpty()),
                ()-> assertEquals("testFid",blogResponse.getBlogFid()),
                ()-> assertTrue(blogResponse.isBlogMain()),
                ()-> assertEquals("testName", blogResponse.getBlogName()),
                ()-> assertEquals("testNickName", blogResponse.getBlogMbNickName()),
                ()-> assertEquals("testDescription", blogResponse.getBlogDescription()),
                ()-> assertNotNull(blogResponse.getCreatedAt()),
                ()-> assertNull(blogResponse.getUpdatedAt()),
                ()-> assertTrue(blogResponse.getBlogIsPublic())
        );

    }
    ...
}

단위 테스트는 개별 컴포넌트나 메서드를 격리된 환경에서 테스트하는 방식으로 위의 예시로 서비스 테스트의 경우 Repository는 이미 검증이 끝났기 때문에 Mockito를 사용해 가짜 객체를 만들어 Service 비즈니스로직에만 집중해서 테스트를 할 수 있다.

따라서 블로그 멤버 매핑도 단위 테스트로 진행하려 했다.

통합테스트 여러 컴포넌트간의 상호작용을 테스트

하지만 블로그 멤버 매핑에서는 Blog, Member, Role 등 여러 모듈이 합쳐지기 때문에 이를 통합테스트로 진행해야 하는 것이 아닌가?

@SpringBootTest
@ActiveProfiles("test")
@Transactional
class BlogMemberMappingServiceTest {
    @Autowired
    private BlogMemberMappingService blogMemberMappingService;

    @Autowired
    private BlogMemberMappingRepository blogMemberMappingRepository;
    ...
 }

즉 실제 ID가 생성되고 관계가 맺어지는 것을 테스트해야 하므로 통합 테스트로 변경해서 진행했다.

테스트 목표인 블로그 멤버 매핑 서비스 코드를 다시 한번 보자

public class BlogMemberMappingServiceImpl implements BlogMemberMappingService {

    private final BlogMemberMappingRepository blogMemberMappingRepository;

    @Override
    @Transactional
    public void createBlogMemberMapping(Member member, Blog blog, Role role) {
        Optional<BlogMemberMapping> existingMapping =
            blogMemberMappingRepository.findBlogMemberMappingByMember_MbNoAndBlog_BlogId(
            member.getMbNo(), blog.getBlogId()
        );

        if(existingMapping.isPresent()){
            return;
        }

        BlogMemberMapping memberMapping = 
            BlogMemberMapping.ofNewBlogMemberMapping(
            member, blog, role
        );
        blogMemberMappingRepository.save(memberMapping);
    }
}

이거 근데 보이드면 검증이 불가능하기 때문에 dto만들어서 BlogMemberMappingResponse를 반환형을 바꿔준다면?

확인해보니 void로 지정할 경우

1. 단순성 : 구현이 간단하고 명확하고 메서드는 작업을 수행하고 끝난다
2. 또한 오직 작업 수행에만 집중하고 결과 정보 생성에 대한 책임이 없다
3. CQS(명령 쿼리 분리 원칙) 디자인 원칙 이와 같은 장점이 있지만

• 메소드 실행 결과를 직접 검증할 수 없어 DB 조회 등 간접적인 방법으로 검증해야한다(Repository)
• 확장성이 제한되고 추가 조회 작업이 필요

따라서 단순한 작업일 경우엔 void, 복잡한 비즈니스 로직이나 API에서는 DTO 반환 방식이 좀 더 유연하다고 할 수 있다.

하지만 이 테스트만을 위해서 dto를 만들어주고, 메소드 반환형을 수정하는게 과연 올바른가?

테스트가 설계를 주도하는 것과 같은 상황에 다음과 같이 생각해보자

• API 사용성: 호출자에게 작업 결과에 대한 정보 제공이 필요한가?
• 비즈니스 요구사항: 실제 비즈니스 로직에서 반환값이 필요한 상황이 있는가?
• 확장성: 향후 추가 정보가 필요할 가능성이 있는가?
• 일관성: 다른 유사한 API들은 어떤 패턴을 따르고 있는가?

등을 생각하다...가 블로그 멤버 매핑 서비스의 필요성에 대해서 생각하게 됐다.

당연히 모든 엔티티는 레포지토리, 서비스가 있을 것이다 라고 깊은 고민을 해보지 않은채 단정을 지었기 때문에 미쳐 놓쳐버린 것이다.

단순 CRUD vs 비즈니스 로직: 서비스 = 비즈니스 로직, 레포지토리 = 데이터 액세스 만약 블로그 멤버 매핑이 단순한 데이터 저장/조회를 넘어 권한 검증, 비즈니스 규칙 적용 등이 필요하다면 서비스 계층이 적합하지만 지금 블로그 멤버 매핑은 간단한 데이터 저장.조회 뿐이기 때문에 레포지토리 계층에 끝내는게 맞는 것 같다.

결론

• 모든 엔티티에 동일한 계층 구조가 필요한 것은 아니며, 각 엔티티의 역할과 복잡성에 따라 적절한 구조를 선택해야함
• 블로그 멤버 매핑과 같은 단순 관계 매핑 엔티티의 경우, 복잡한 비즈니스 로직이 필요하기 전까지는 레포지토리 계층만으로도 충분
• 테스트 코드를 작성하며 기능 검증뿐만이 아닌 설계 자체에 대해 고민하는 시간이 되었다.

<head> 요소의 내용은 브라우저에 표시되지 않음
페이지에 대한 metadata를 포함

제목을 표시하는 <title>

<title>Datamotion Movie Database</title>
파일 링크와 스크립트

CSS : <style> 태그로 사입

<style>
    p {
        font-family: helvetica, sans-serif;
        letter-spacing: 1px;
        text-transform: uppercase;
        border: 2px solid rgba(0,0,200,0.6);
        display: inline-block;
        cursor:pointer;
    }
</style>
<link> 태그로 파일 참조

<link rel="stylesheet" href="sample.css">
JavaScript : <script> 태그로 삽입

<script>
    const para = document.querySelector('p');
    para.addEventListener('click', updateName);
    function updateName() {
        let name = prompt('Enter a new name');
        para.textContent = 'Player 1: ' + name;
    }
</script>
script src = 로 파일 참조

<script src="sample.js"></script>
페이지에 대한 메타 데이터를 포함
인코딩 설정

<meta charset="UTF-8">
IE 호환성

<meta http-equiv="X-UA-Compatible" content="IE=edge">
페이지 설명

<meta name="keywords" content="movie">
<meta name="description" content="Simple Movie Database">
<meta name="author" content="Randy">

Open Graph Protocol 페이지에 대한 요약 정보

웹사이트가 OGP 를 지원한다면, 웹사이트를 들어가기도 전에 뭐하는 사이트인지 미리 알 수 있습니다. payco.com의 url을 카카오톡 or dooray 메신저에 붙여 넣으면 다음과 같이 확인 할 수 있습니다.

<meta name="og:image" content=“http://image.toast.com/aaaaac/paycoNoti/payco_com.jpg">
<meta name="og:title" content="PAYCO.COM 사는게 니나노PAYCO">
<meta name="og:description" content="NHN 페이코의 간편결제 서비스, 착한소비 제로페이, 송금수수료 없는 제휴계좌, 매달 PAYCO포인트 리워드 혜택, 실적 조건 없이 적립되는 제휴카드, 실속있는금융 생활의 중심, PAYCO">

Character Sets and Encodings

• 글자나 기호들의 집합을 숫자로 정의한 것

ASCII

• 영문 알파벳을 사용하는 대표적인 문자 인코딩
• 7bit
• 한글 표현 불가능
  ### EUC-KR
• 한글 완성형 인코딩
• 8bit 문자 인코딩
• 한글은 2byte 사용하는 문자 집합

UTF-8 (유니코드)

• 전세계 모든 문자열을 하나의 코드표로 통합
• 한문자를 저장하기 위해 최소 1byte ~ 최대 4byte까지 동적으로 사용
• 조합형, 완성형 등이 있다

charset이 잘못되면 생기는 일

charset = euc-kr, 파일은 UTF-8 인코딩이면..

또는 charset=utf-8 파일은 euc-kr 이면 ..

<!DOCTYPE html>
<html lang="ko">
    <head>
        <meta charset="euc-kr" />
        <title>실습-02</title>
    </head>
    <body>
        <h1>euc-kr 한글 인코딩 테스트</h1>
    </body>

</html>

HTML 문서를 표현하는 모든 TAG는 두 분류중 하나에 속합니다.

Inline Tag

자신의 내용과 앞뒤 태그의 내용을 같은 라인에 출력하는 태그

대표적인 tag는 <span></span>

반드시 알아야할 테그

<span>, <a>, <br>
,<button>,<img>,<input>,<select>,<textarea>,<label>,<strong>
<abbr>, <acronym>, <b>, <bdo>, <big>, <cite>, <code>, <dfn>, <em>, <i>, <kbd>,<map>, <object>, <q>, <samp>, <small>, <script>,<sub>, <sup>,<tt>, <var>

Block Tag

자신의 내용과 앞뒤 태그의 내용을 다른 라인에 출력하는 태그(즉 좌우 너비가 100%)

주로 구조를 만들 때 사용

대표적인 tag는 <div></div>

다만 <p> 태그는 내부에는 인라인 요소만 표현할 수 있습니다.

반드시 알아야할 테그

<form>, <ul>, <p>, <table>, <div>,<address>
<h1>,<h2>, <h3>, <h4>, <h5>, <h6>
<article>, <aside>, <audio>, <blockquote>, <canvas>, <dd>, <dl>, <fieldset>, <figcaption>, <figure>, <footer>,
<header>, <hgroup>, <hr>, <noscript>, <ol>, <output>, <pre>, <section>, <video>

HTML Text

<p> : 문단
<br> : new line
List
계층구조(목록)을 표현

순서 없는 목록 : <ul>, <li>

<ul>
    <li>우유</li>
    <li>계란</li>
    <li>빵</li>
    <li>후무스(중동의 김치)</li>
    <li>베이컨</li>
</ul>

순서 있는 목록(Ordered) : <ol>, <li>

<ol>
    <li>Avatar</li>
    <li>Avengers: Endgame</li>
    <li>Titanic</li>
    <li>Starwars: Force Awaken</li>
    <li>Avengers: Infinity War</li>
</ol>

중요(Emphasis)와 강조(Strong importance) 중요한 글자를 강조하기 위해 글자를 두껍게 표현하거나 기울여서 표현

<p><em>스래시 메탈</em> 밴드로는 <strong>메탈리카</strong>가 있습니다</p> <p>그리고 <strong>메가데스</strong>또한 말하지 않을 수 없죠.</p>

a tag

문법
<a href="링크할 주소">텍스트 또는 이미지</a>

예제1
<p>영화 데이터베이스</p>
<p><a href="http://www.imdb.com">IMDB</a>로 연결</p>
<p>영화 데이터베이스 <a href="http://www.imdb.com" title="세계에서 가장 큰 영화 데이터베이스">IMDB</a>로 연결
</p>

URL 과 Path

• URL(Unified Resource Locator) : 웹 상의 어디에 위치하는지 결정하는 텍스트 문자열
• Path은 내부 파일을 찾기 위해 Path 사용

table ( 테이블 )

웹 문서에서 자료를 정리할 때 가장 많이 사용하는 태그

<table> 태그로 테이블을 시작

<tr> 태그로 테이블을 시작

<td> 태그로 행을 만듦

<th> 태그는 셀의 문자를 가운데 굵게 표시(제목에 사용)

<table border="1">
    <tr>
        <td>아바타</td> <td>2009</td> <td>제임스 카메론</td>
    </tr>
    <tr>
        <td>어벤저스: 엔드게임</td> <td>2019</td>
        <td>루소 형제</td>
    </tr>
</table>

행 합치기 : colspan, 열 합치기 : rowspan

<style>
    *{
        font-size:20pt;
    }
    table,th,td {
        border: 1px double black;
        width: 800px;
    }

    .border-red{
        border: 1px double red;
        color:red;
    }
    .border-blue{
        border:1px double blue;
        color:blue;
    }
</style>

<table>
    <catpion>전 세계 박스 오피스</catpion>
    <thead>
        <tr>
            <th>제목</th>
            <th>연도</th>
            <th>감독</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>아바타</td>
            <td>2009</td>
            <td rowspan="2" class="border-blue">제임스 카메론</td>
        </tr>
        <tr>
            <td>타이타닉</td>
            <td>2002</td>
        </tr>
        <tr>
            <td>어벤저스: 엔드게임</td>
            <td>2019</td>
            <td>루소 형제</td>
        </tr>
    </tbody>
    <tfoot>
        <tr>
            <td colspan="3" class="border-red">www.boxoffice.com</td>
        </tr>
    </tfoot>
</table>

Element

Opening tag , Closing tag

영역을 나누는 태그

• div

  • Division의 약자, 웹 사이트의 레이아웃을 만들 때 사용하는 태그 웹 페이지에서 논리적 구분을 정의 각각의 블록(공간)을 알맞게 배치하고 CSS 스타일을 적용 Block level element

• span

  • 자체만으로는 어떠한 의미도 가지지 않음 class, id의 전역 속성으로 스타일링을 위해 요소들을 그룹화 Inline level element

• form

내용을 표현하는 태그

Semantic tags

• 의미 없는 div 태그의 사용보다 문서의 내용을 쉽게 이해할 수 있도록 의미를 가지는 새로운 태그요소

HTTP Method

GET 방식의 특징

데이터가 URL에 노출됩니다

예시: https://httpbin.org/get?no=1&id=marco&age=30 URL에 파라미터가 ?key=value 형태로 전달됨

데이터는 args 객체 안에 저장됩니다 URL에 데이터가 포함되어 있어 북마크가 가능합니다 데이터 크기에 제한이 있습니다 (브라우저마다 다르지만 보통 2048자)

POST 방식의 특징

데이터가 URL에 노출되지 않습니다

예시: https://httpbin.org/post 데이터는 HTTP 요청 본문(body)에 포함됨

데이터는 form 객체 안에 저장됩니다 보안성이 상대적으로 높습니다 (URL에 데이터가 노출되지 않음) 대용량 데이터 전송이 가능합니다

사용 용도

GET: 데이터 조회(검색, 읽기)와 같은 단순 요청 POST: 데이터 생성/수정/삭제와 같이 서버의 상태나 데이터를 변경하는 요청

HTTP Status Code

• 소프트웨어 개발에 있어 소스 코드를 실행할 수 있는 애플리케이션으로 만들어주는 도구
• 자동화, 일관성, CI/CD 통합, 코드 컴파일, 테스팅, 호환성, 배포, 패키징 등.. 많은 기능들을 제공
• Maven은 Java의 대표적인 빌드 툴 중 하나이며 XML을 사용해 빌드 파일을 기술하며, 중앙 저장소를 이용해 편리한 의존 관계 라이브러리를 관리한다.
• 또한 일관된 디렉토리 구조를 제공하지만 기본적으로 maven에서 제공하지 않는 빌드 과정 추가가 복잡하다
• 플러그인 설정이 상이하거나 장황해질 경우 재사용성 및 확장성이 떨어지는 문제가 있다
  

설치

brew install mvn

Mac 환경을 사용하고 있기에 Homebrew를 통해 간단히 설치 했다.

또한 Java 11 / Java 21 버전을 기반으로 학습할 예정이다.

프로젝트 생성

이전 vscode에서 생성할 때와 달리 IntelliJ 툴을 이용하니 직관적으로 바로 Maven 프로젝트를 생성할 수 있었다.

Maven 프로젝트 구조

기본적으로 위와 같은 구조를 하는데 각 디렉토리는 다음과 같은 목적을 가지고 있다.

src 디렉토리

src/main

• 이 디렉토리는 프로젝트의 주요 소스 코드와 리소스를 포함합니다.

  src/main/java

  • 프로젝트의 주요 Java 소스 코드가 위치합니다. • 여기에는 com/nhnacademy 패키지 구조가 있어, 해당 패키지 내에 Java 클래스 파일들이 위치하게 됩니다.

  src/main/resources

  • 애플리케이션에서 사용되는 리소스 파일들이 위치합니다. • 설정 파일, 프로퍼티 파일, XML 파일 등이 이 디렉토리에 저장됩니다.

  src/test

  • 이 디렉토리는 테스트 관련 코드와 리소스를 포함합니다.

  src/test/java

  • 단위 테스트를 위한 Java 소스 코드가 위치합니다. • JUnit 테스트 클래스 등이 이 디렉토리에 저장됩니다.

  target 디렉토리

  • 빌드 결과물이 저장되는 디렉토리입니다.

  target/classes

  • 컴파일된 클래스 파일들이 저장됩니다. • com/nhnacademy 구조는 소스 코드의 패키지 구조를 반영합니다.

  target/generated-sources

  • 빌드 프로세스 중에 생성된 소스 코드가 저장됩니다.

  target/maven-archiver

  • Maven 아카이브 관련 정보가 저장됩니다.

  target/maven-status

  • Maven 컴파일 상태 정보가 저장됩니다.

Pom.xml

Maven의 기본 작업 단위.

Maven이 프로젝트를 빌드하는 데 사용하는 프로젝트 및 구성에 대한 세부 정보가 포함된 XML 파일

Java 11 환경을 구성하기에

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.nhnacademy</groupId>
    <artifactId>Web</artifactId>
    <version>1.0-SNAPSHOT</version>

    <properties>
        <maven.compiler.source>11</maven.compiler.source>
        <maven.compiler.target>11</maven.compiler.target>
        <mavn.compiler.release>11</mavn.compiler.release>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>
    <build>
        <plugins>
            <plugin>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.8.0</version>
            </plugin>
        </plugins>
    </build>
</project>

이와 같은 의존성을 추가해줬다.

POM(Project Object Model) 주요 Tag

• project

  Maven의 XML Namespace를 지정합니다.

• modelVersion

  Maven의 model Version

• groupId

    group id

• artifactId

    artifact id

• name

    project 이름

• url

프로젝트 정보를 다른 사람들이 프로젝트에 대한 자세한 정보를 찾을 수 있도록 안내

프로젝트 관련된 문서, 소스코드(git)등 관련된 정보를 제공

• properties

  프로젝트에서 사용할 공통 속성

• dependencies

  프로젝트가 참조하고 있는 라이브러리

주요 Maven 명령어

mvn clean install : 이전 빌드 결과를 정리하고, 프로젝트를 새로 컴파일, 테스트, 패키징한 후 로컬 저장소에 설치합니다. mvn clean package : 이전 빌드 결과를 정리하고, 프로젝트를 새로 컴파일, 테스트한 후 패키징합니다. mvn clean test : 이전 빌드 결과를 정리하고, 프로젝트를 컴파일한 후 테스트를 실행합니다.

mvn validate : 프로젝트 상태 점검 및 필요한 정보와 존재 여부 확인

mvn compile : 프로젝트 소스 코드 컴파일

mvn test : 컴파일된 소스코드에 대한 단위 테스트 실행

mvn package : 컴파일된 코드를 JAR(Java ARchive), WAR(Web Archive) 파일로 패키징

mvn verify : 패키지가 품질 기준에 적합한지 검사

mvn install : 패키징된 JAR/WAR 파일을 로컬 Maven 저장소에 설치

mvn site : 프로젝트에 대한 문서 사이트 생성

mvn deploy : 패키징된 JAR/WAR 파일을 원격 저장소에 배포

내가 벌써 4학년이야 !! 했던 1월 1일의 기억이 선명한데 정신차리니 12월 31일이네요 아마 이번년도에 가장 많은 경험을 하지 않았을까 생각이 듭니다 좋은 사람들도 많이 만나고 꽤나 의미있게 보낸거 같아요 !

2024 - 상반기

당시에는 꽤나 알차게 보냈던 기억이 남는 학기인데.. 특히 캡스톤을 2과목이나 수강하는 바람에 프로젝트 폭탄이였습니다.

가장 힘들었던게 USG 캡스톤 종합설계 과목이 참 ...

시각 장애인을 위한 점자 해석 어플리케이션 이라는 주제인데 당시에는 막막한 이미지 처리 기술부터.. 매번 2명이서 팀플하다가 5명이라는 인원으로 진행하려니 꽤 막막했었습니다.

특히 이미지 회전 !!!! 이건 챗GPT, google, github 다 뒤져보면서 오픈소스도 찾아보고 이것저것 했지만.. 영문으로 했을 땐 쉽게 끝났을텐데 한글로 하려고 하니 점자 변환 부분에서도 꽤 애를 먹었네요 피눈물의 흔적

*발표날 *

비록 수상은 못했지만 공익성 있는 주제 선정부터 중간에 학교 캠퍼스 관련 문제로 ..usg 자격 상실 등 여러 이슈를 겪은 것 치고는 우리팀들 모두 고생 많았습니다 ^^

2024 - 하반기

이후 2학기를 혼자 공부할지.. 아니면 다른 부캠을 갈지 고민 하던 중 2학년 때부터 고민하던 NHN Academy IoT/Backend 과정이 보여 바로 지원했습니다.

코테하고 제주도 가서 놀던 중 결과가 나오자마자 너무 기뻤고 가서 많은 경험을 할 수 있단 생각에 양산에 집도 정리하고 바로 김해로 이사 왔네요 !!

우선 여기 오자마자 느낀건 생각보다 제가 제대로 된 공부를 하고 있었던게 아니구나..와 깃허브 사용법을 제대로 숙지 하지 않아 기록을 안하고 있었는데.. 막상 딱 앉아서 끝까지 파보니까 어려운게 아니더라구요

이런식으로 코드 리뷰도 받고 내가 짠 코드의 목적성과 구조 등을 팀원들이랑 같이 검토하는 과정에서 되게 재미를 느꼈습니다.

지금까지 Java Basic / Thread / Network / DB / Python / IoT / ML 등을 배우는데

조금씩 기록하면서 12월 달에는 2주동안 8인 팀플도 했네요 !!

Node-Red라는 플랫폼을 카피한 Node-Blue 라는 자바 라이브러리를 만들어보자! 를 목표로 열심히 달렸습니다.

그래도 대학생 때 기록하는 습관들이 있어 Notion, Miro, Git 등을 활용할 때 도움이 됐네요 간단히 팀 페이지 만들어두고 ..

매일 오전엔 스크럼을 진행하면서 어제 했던 것과 오늘 해야할 목표등을 설정해서 최대한 기간내에 각자 맡은 부분을 개발하는 것을 제일 중요하게 생각했네요 !!

그리고.. 설계 부분을 진행하면서 굉장히 어려움이 많았는데 처음엔 완벽할거 같아서 이젠 코드로 구현을 해보자 !! 였지만.. 바로 논리적인 문제가 생겨서 수정에 수정, 수정, 수정 ..... 찐찐찐찐막 설계도를 토대로 우선 구현부터 해나가자 !! (시간이 매우 부족했음) 한 결과로 위에 시스템 아키텍처와

메인 프로젝트에서 Node-Blue를 사용한 흐름도를 구성했습니다.

그 중 상세히 제가 담당했던 부분이네요 !! 이 과목에서 저에겐 멀게만 느껴졌던 라즈베리 파이 모듈과.. 낯선 Flow-Based Programming 등 .. 자세히 공부해볼 수 있었네요 !! 가장 재밌었고 열정적이였던 과목 같습니다.

팀원간 전반적인 회고록인데 다음 팀플을 하게 되면 이 아쉬운 점을 개선한 팀이 되도록 좀 더 노력해봐야겠네요..

결론

그동안 대학울타리 안에 갇혀 학점만 챙기며 진짜 노력이란 것을 해보지 않았던 저에겐 부트캠프에 와서 한계도 깨닫고 열정도 태우는 좋은 경험이 된거 같습니다 ! 내년 초부턴 Spring 본과정에 들어가는데 그땐 Velog, Git에 더 성실히 복습해서 기록하는 습관을 들이고 싶네요!

그리고 틈틈히 알고리즘 공부까지 !!

이렇게 마무리 하자니 대학생활 때 뭐가 남았나 할거 같은데 그래도 알차게 보냈습니다 ^^

2019.03 ~ 2020.02 컴퓨터 공학과 1학년 대표 2020.02 ~ 2021.10 대한민국 해군 작전사령부 독도함 전산병 만기 전역 2022.03 ~ 2023.02 컴퓨터 공학과 2학년 대표 2023.03 ~ 2023.12 22대 자치회장

2023.03 ~ 2024.08 AI 컴퓨터공학과 학회장 2024.08 ~ ing NHN Academy A/IOT 2기

20대의 초반을 좋은 사람들, 좋은 경험으로 가득 쌓은거 같네요 다들 2024년 고생 많으셨고 2025년에는 성실한 Velog로 돌아오겠습니다 !

**Query**
⬇︎⬇︎
**Query Optimizer and Execution** : 쿼리 최적화기를 실행함으로써 데이터 구조&통계를 이용해 효율적인 수행 계획을 수립 후 실행
⬇︎⬇︎
**Relation Operators** : 관계 연산자를 통한 데이터에 대한 질의 생성
⬇︎⬇︎
**Buffer Manager** : 버퍼관리자를 통해서 메모리의 버퍼에 적재된 주기억 장치 공간(HDD, SDD)의 데이터를 프레임 단위로 구분해서 관리
⬇︎⬇︎
**File and Access Manager** : 파일 관리자를 통해 여러 형태의 파일 내의 페이지를 추적 감시하여 한 패이지내에 정보들을 조직하는 방법을 수행
⬇︎⬇︎
**Disk Manager** : 데이터가 저장될 디스크 공간을 관리
⬇︎⬇︎
**DataBase**

의 과정을 거친다.

레코드를 삽입 또는 삭제함에 따라 데이터베이스 역시 확장되고 축소되는데, 디스크 관리자는 어떤 디스크 블록들이 사용중이고, 어떤 페이지가 어느 디스크 블록에 있는지를 추적 감시하는데 DB를 사용하는 과정에 처음에는 빈 공간에 디스크에 블록들이 할당되지만 할당, 반환 등의 과정이 반복되며 순차적인 구조는 무너지고, 중간에 빈 공간이 생기게 된다

이러한 빈 공간을 효율적으로 관리해야만 새로운 데이터를 잘 저장 할 수 있는데, 두가지 방법이 있다.

1. 블록 반환시마다 비어있는 공간의 포인터를 리스트에 저장해 나중에 사용할 수 있도록 한다.

   • 빈공간을 쉽게 찾을 수 있으며, 관리가 간단
   • 연속된 큰 공간을 찾기 어려울 수 있다.

2. 각 디스크 블록마다 1bit 블록 사용 여부를 나타내는 비트맵을 유지

   • 연속된 빈 공간을 빨리 찾을 수 있으며, 전체 공간 상태를 한눈에 파악할 수 있다.
   • 단, 데이터 구조에 따라 관리가 복잡할 수 있다.

   ---

버퍼 관리

대부분의 데이터베이스는 주기억장치보다 큰 용량을 가지는데, CPU는 메모리에 적재된 데이터만 처리할 수 있다. 따라서 DBMS는 필요시 데이터를 주 기억장치에 적재하여, 언제 페이지를 교체해야하는지 결정해야 한다. 이 때 버퍼 관리자는 하드디스크에서 필요한 데이터를 가져와 메모리에 임시 저장해두는 역할을 한다. 예시로, 책장(하드디스크)에서 자주 보는 책을 책상(메모리)에 올려두는 과정과 유사하다.

버퍼 풀

메모리에서 데이터를 임시로 보관하는 공간이며, 여러개의 프레임으로 나누어져있다. 책상 위에 책을 올려놓을 수 있는 여러개의 공간을 나눈 것과 같은데, 각 칸은 두가지 정보를 가지고 있다.

프레임이 가지고 있는 정보

• pin_count : 특정 페이지가 사용중인 상태를 나타내며, 여러 트랜잭션이 동시 접근 가능함 (pin_count가 0이 아닌 경우 해당 페이지는 교체 대상에서 제외)
• dirty : 데이터가 수정되었는지 표시하는 flag (수정시 1, 메모리의 페이지를 디스크에 기록 하기 전 dirty 상태의 페이지는 디스크에 반영해야 함)

간단한 버퍼 관리의 동작 과정

1. 우선 서버로 데이터 요청이 들어오면 해당 데이터가 있는지 버퍼 풀에서 먼저 탐색한다. 2-1. 만약 빈공간이 있다면 바로 사용 2-2. 버퍼 풀에 없다면 새로운 공간을 할당해줘야 하는데 이때 pin_count가 0인 곳을 찾아 수정된 데이터(dirty == true)인 경우 하드디스크에 저장하고 새로운 데이터를 가져온다.

자세히 정리하자면 버퍼 풀의 역할은 디스크 I/O를 줄이기 위해 메모리에 데이터를 캐싱해두는 핵심 공간이며, DBMS는 버퍼 풀에 데이터를 적재함으로써 디스크 접근을 최소화하여 성능을 최적화 시킨다. 즉, 자주 사용하는 데이터에 대해 디스크 대신 메모리에서 읽고 쓰는 작업을 수행

또한 버퍼 풀의 크기는 DB 성능에 중요한 영향을 미치기에 버퍼 풀이 너무 작을 경우 페이지 교체가 빈번해지며(속도 저하?), 너무 크면 메모리 낭비가 발생하므로 최적의 크기를 찾는 것이 DB 성능 최적화를 위한 중요한 요소 중 하나이다.

페이지

페이지는 버퍼 풀에 저장되는 레코드의 집합이며, 디스크 -> 메모리로 데이터가 전송되는 최소 단위이다.

페이지 역시 각 레코드가 저장되는 슬롯을 가지며, 각 슬롯에 레코드가 저장된다.

레코드는 <페이지 번호>, <슬롯 번호>의 쌍으로 식별되며 이 쌍을 RID(Record ID)라고 하며 레코드의 포인터 역할을 수행한다.

데이터 저장 및 관리

대부분 자료구조에서는 저장된 데이터의 rid를 직접 알 수 없는데, 정렬되지 않은 자료 구조에서 동등 검색을 수행할 경우, 전체 자료 구조를 스캔 해야한다.

이때 index는 선택(Selection) 조건에 맞는 rid를 구할 수 있도록 만든 보조 자료구조인데 이를 활용한다.

스토리지 엔진

MyISAM(ISAM 기반)

• 색인 순차 접근 방식 파일
• 인덱스를 순차적으로 구성하여 큰 인덱스의 성능 문제를 해결

  파일 구조
  .frm : 테이블 구조
  .MYD : 실제 데이터
  .MYI : 파일에 인덱스

  기본적인 연산인 삽입, 삭제, 검색은 매우 간단한데, 이중 동등 셀렉션 탐색의 경우 루트 노드부터 시작하여 크 기밧에 해당하는 레코드가 어떤 서브트리에 있을지 판단한다.

ISAM에서 삽입, 삭제는 단말 페이지의 내용에만 영향을 주는데, 이 경우 하나의 단말 노드에 수많은 삽입이 수행될 때 오버 플로우 체인을 만들 수 있으며, 탐색시 그만큼 탐색해야 하므로 레코드를 찾아내는 시간에 상당한 영향을 미치게 된다.

이를 위해 페이지에 약 20%의 여유 공간이 있도록 트리를 만드는데, 이때도 트리가 가득 찼을 때 데이터 삽입 시 오버 플로우 체인이 만들어지게 될 것이다. 한편으론 단말 페이지만 수정될 수 있어 동시성 제어에서는 이점을 갖게 되는데, 일반적으로 어떤 페이지를 접근하는 요청자는 자신이 이 페이지를 사용하는 동안 다른 사용자들이 그 내용을 동시 수정 할 수 없도록 Lock을 건다. 페이지 수정시에도 그 페이지를 잠근 사용자가 없을 경우에만 허용되는 전용(exclusive) 잠금을 강제함으로써 그 페이지에 대한 접근을 시도하는 트랜잭션을 기다리도록 할 수 있다.

인덱스 계층 페이지를 잠글 필요가 없는 것은 , B+ 트리와 같은 동적 구조에 비해 커다란 이점이 되며, 데이터의 분포와 크기가 상대적으로 정적일 경우(오버 플로우 체인이 거의 없다면) ISAM은 B+ 트리보다 좋은 구조가 된다.

또한 외래키를 미지원 하며 테이블 레벨 잠금, 읽기 작업에 최적화 되어 있다고 볼 수 있다.

• 시스템 장애시 수동 복구가 필요하며, 데이터 손상 위험이 있다.

InnoDB(B+Tree기반 ) ISAM과 같은 정적인 구조는 파일 커짐에 따라 오버 플로우 체인으로 인해 성능 저하의 단점이 있다. 따라서 삽입, 삭제시에도 깔끔히 조정되는 융통성 있는 동적 구조를 개발하게 되는데 이것이 B+Tree이다.

동적 균형 트리 구조를 가지고 있으며, 모든 단말 노드가 같은 레벨이다.

• 균형 유지로 인해 일관된 성능을 보장하며
• 동적이기에 오버 플로우 체인이 없어 효율적인 데이터 관리가 가능하다 하지만 구조가 복잡하고 추가 공간이 필요하며, 읽기 성능은 상대적으로 낮다.

내부 구조
내부 노드 : 키 값, 포인터만 저장
리프 노드 : 실제 데이터 저장
- 리프 노드들은 Linked Llist로 연결되어 순차 접근이 용이

자체 버퍼 풀을 사용해 데이터와 인덱스를 모두 캐시하며, ACID 특성을 완벽히 지원한다

ACID 특성

• 원자성 : 트랜잭션은 완전히 실행 되거나, 완전히 취소 되어야 한다.
• 일관성 : 데이터의 무결성을 보장해야한다.
• 격리성 : 동시 실행 트랜잭션은 간섭을 방지해야한다.
• 지속성 : 완료된 트랜잭션은 영구히 보존되어야 한다.

레코드를 탐색할 땐 루트부터 알맞은 단말 노드까지만 가면 되는데 이걸 높이라고 한다. 균형 트리이기에 어떤 단말 노드든 이 값은 같고 이러한 B+Tree는 레코드 파일이 자주 갱신되며, 정렬된 접근이 중요하면 데이터 엔트리로 레코드를 저장한 B+Tree를 쓰는것이 정렬 파일 이용시보다 성능이 우수하다.

인덱스 엔트리 저장을 위한 공간 오버헤드 대신 정렬 파일의 장점과 효과적인 삽입, 삭제 알고리즘의 장점을 모두 얻게 된다.

• 자동 복구 기능과 크래시 복구를 지원해 데이터 안전성이 높다.

** 비교하기 ** MyISAM은 테이블 레벨에서 잠금을 하며, InnoDB는 행레벨에서 잠금을 한다 MyISAM은 정적인 구조, InnoDB는 동적인 구조로 데이터를 관리하며 InnoDB의 경우 외래키, 트랜잭션을 지원한다.

즉 선택 기준을 정리하자면 단순히 읽기 위주의 작업이고 데이터의 분포, 크기가 상대적으로 정적일 경우엔 MyISAM이 B+ Tree보다 좋은 구조를 가지지만 보통 InnoDB는 쓰기, 수정 작업에 특화되어 있으며 트랜잭션이 필요하거나, 높은 동시성을 요구하며 빈번한 데이터 수정이 필요할 때 선택한다. 파일은 일반적으로 축소보단 확장되며, 이러한 활용도로 인해 ISAM 방식보다 B+Tree가 전반적으로 우수하다고 평가된다.

관리 방법

1. 생성 후 종료될 때 자동 삭제 되도록 하기

• Thread는 Runnable interface의 run() 수행이 끝나면 종료되는데, 일정한 작업을 외부 간섭 없이 수행후 종료되면 운영상에 크게 문제가 없다
• 단 이경우 thread를 원하는 시점에 종료시키거나 관련 정보 확인이 어려움

2. 구현 되는 클래스 내에서 Thread object를 포함시켜 관리

• Rubbale interface를 구현하는 class가 필요로 하는 Thread instance를 클래스 내에 포함시켜 관리하는데,
• 이 경우 생성된 object에서 자신과 관련된 Thread instance를 관리하기에, thread 제어와 관련된 처리가 가능

3. Thread pool 이용 = 1번 방법과 유사하지만, Thread 생성과 삭제를 반복하는 것이 아닌 생성된 Thread instance를 활용하기에 자원 활용면에서 좋다

• Thread Pool은 스레드 관리를 대신해주지만, 필요에 따라 특정 작업의 취소나 상태 확인 등은 가능하지만, Thread 관리에 대한 권한을 직접적으로 가지고 있지 못하므로 Thread 제어가 필요한 경우 사용이 제한될 수 있다

Thread class와 Runnable 인터페이스 이용 차이

class 확장

• 다중 상속을 지원하지 않기에, 다른 class로 부터 추가적인 확장이 불가능
• instance 생성 후 바로 실행할 수 있다
• 간단한 class여도 별도의 class 정의가 필요

Interface 구현

• interface의 경우 여러개를 사용할 수 있기에 구현된 후에도, 해당 class의 확장이 가능
• 추가적인 Thread object가 있어야 한다(Instance 생성 후 바로 사용이 불가능)
• Runnable interface는 functional interface로 Lambda로 구현 가능

Thread 멈추기

Java Thread는 start()에 의해 시작 되지만 종료에 대한 명령은 없다. 초기엔 stop()메소드를 지원 했지만, thread가 실행중에 강제 종료시 thread 내부에서 리소스 정리를 제대로 할 수 없게 되며, lock을 해제 하지 않은 채 thread를 종료시켜 다른 thread에서 lock 획득을 위해 무한히 기다리는 deadlock 상태에 빠질 수 있다.

따라서 Thread를 안전하게 종료하기 위해서 thread내에서 확인만 가능하게 상태를 전달해 스스로 종료할 수 있도록 만들어야 한다.

Interrupt

상태 제어를 통해 thread를 중지 시키려할 때 위와 같은 문제가 발생하는데, 이를 해결하기 위해서는 Java Thread 클래스에서 지원하는 sleep, wait 상태일 때 외부로부터 이벤트를 전달 받을 수 있는 Interrup가 있다.

Thread Class 상태 정보로도 사용되지만, sleep || wait 같은 대기 상태에서 exception을 발생시킨다.

Thread 동시성 제어

Thread 동기화 문제

1. Race Condition(경쟁 조건)

• 둘 이상의 thread가 동시에 공유 자원 접근시 발생
• 동시 접근함으로써 문제가 발생할 수 있는 구역을 **Critical Section(임계 구역)
• • 이라 함
• 1번 Thread가 변수를 읽고, 2번 Thread도 변수에서 동일한 값을 읽는다.
• 이후 1,2번 Thread는 각 작업을 수행 후 변수에 마지막으로 값을 쓰기 위해 서로 경쟁하게 되고, 결국 마지막에 덮어쓴 thread 값이 저장 되어 원하는 결과를 얻지 못한다.

2. Critical Section(임계 구역)

• 두 스레드가 동시 접근하여 허용되지 않는 공유 자원에 접근하는 코드의 블록
• Critical Section은 Thread에서 작업에 필요한 최소한의 시간만 유지되어야 하며, 작업이 완료된 후에는 반드시 해제 되어야함
• 따라서 한 thread가 critical section에 들어가 작업이 진행중이라며, 나머지 thread들은 해당 작업 완료까지 대기해야 한다.
• Mutual Exclusion(상호배제)를 보장받기 위해서, critical section에 들어가거나, 나올 때를 위한 다양한 동시성 제어 메커니즘 제공

3. Mutual Exclusion(상호 배제)

• 두개 이상의 process or thread가 동시에 하나의 공유 자원으로 발생할 수 있는 race condition 문제를 해결하기 위해 어느 시점에서의 공유 자원 접근을 하나의 process 혹은 thread로 제한하는 것

4. Deadlock(교착 상태)

mutual exclusion 과정에서 자원 접근 권한 획득과 자원 접근 권한 반환 관계의 꼬임으로 발생

** Hold and wait (점유 대기)**

1. process 2가 resource 1의 접근 권한을 획득한 상태로 resource2의 접근 권한을 기다리는 상태
2. process2의 수행 과정이 resource 2의 접근 권한을 획득하여 처리 한 후 resource 1의 접근권한을 해제하면 process 3이 접근 권한을 해제하기 전까지 무한 대기 상태에 놓이게 됨
3. 따라서 resource 1의 접근 권한을 요청하는 process 1도 무한대기 상태에 빠짐

** Circular Wait(순환 대기) **

순환 대기의 경우

Process1 &nbsp&nbsp&nbsp ⬅️&nbsp&nbsp&nbsp Resource2 &nbsp&nbsp&nbsp&nbsp&nbsp&nbsp⬇️ &nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp ⬆️ Resource1 &nbsp&nbsp&nbsp➡️ &nbsp&nbsp&nbspProcess2

• process 1은 Resource2에 대한 접근 권한을 가진 상태에서 Resource1에 대한 접근 권한을 기다림
• process 2는 Resource1에 대한 접근권한을 가진 상태에서 Resource2에 대한 접근 권한을 기다림

두개의 프로세스는 서로가 다른 process가 가지고 있는 접근 권한을 얻기 위해 대기하고 있어, 하나의 프로세스가 먼저 해제하지 않는 이상 대기 상태는 계속 유지됨

** Starvation(기아 상태) ** 다른 process || thread가 공유 자원의 접근 권한을 지속적으로 가짐으로써, 우선 순위가 낮은 process || thread는 접근 권한을 획득할만큼의 수행 시간을 갖지 못해 무한 대기 상태에 놓일 수 있다.

5. Livelock

• deadlock 문제 해결을 위해 공유 자원 접근 요청 후 일정 시간 안에 권한 획득에 실패시 수행 과정을 종료하며 발생한다.

• 두개의 process나 thread에서 교착 상태를 유지하다가 일정 시간 후 자원 접근 요청을 철회시, 두개의 process || thread가 동시에 수행하여 자신이 확보하고 있던 공유 자원 접근 권한을 반환해 교착 상태를 해결

• 이경우 교착 상태처럼 아무런 작업도 하지 못하는 것은 아니지만, 해당 자원에 대한 접근 권한을 획득하지 못하므로 관련된 작업을 수행할 수 없다.

• 즉 교착 상태는 관련 process || thread가 대기 상태를 계속 유지함으로써 타 작업 수행이 불가능하지만, livelock의 경우 해당 자원에 대한 처리만 못하고 나머지 작업은 처리되는 차이가 있다.

프로젝트 전체 로직

1. YOLO 모델을 통해 점자 객체를 탐지
2. 이미지 전처리 후
3. 정면 이미지를 점자 해석 알고리즘에 INPUT

이 중 실시간 YOLO 카메라를 통해서 들어오는 이미지를 3번 과정을 위해 정면으로 돌리는 역할을 맡게 되었다.

이미지

점자 이미지는 점의 배열 3*2(예외 케이스가 존재)로 구성되어 있고, 각 점은 돌출 형식으로 되어 있다.

이 예시 이미지를 기준으로 구현해보자.

이미지 정렬 변환 및 변환 과정

1.윤곽선 검출 및 경계 상자 설정 detect_object

• 이미지를 GrayScale
• 이진화(threshold)를 통한 객체 추출
• cv2의 findContours() 메소드를 통해 외곽선을 찾음
• 외곽선 길이 1%로 근사화 정확도 설정
• 외곽선을 다각형으로 근사화

 [  0  49]
 [  0 256]
 [359 228]]

2. 경계 상자 기반 이미지 전처리 set_output_shape

• 경계 박스의 크기를 계산
• 계산된 가로 세로 길이를 사용해 출력 이미지의 4개의 꼭짓점 좌표 설정

• 변환 매트릭스 계산시 사용

Output Shape: [[359   0]
 [  0   0]
 [  0 242]
 [359 242]]

3. 이미지 정렬 warp_img

• cv2.getPerspectiveTransform 메소드를 사용해 객체 경계 박스 점과 출력 형태 점들을 기반으로 변환 매트릭스 계산
• wrapPerspective 메소드를 사용해 이미지 변환

이미지 워핑과 객체 감지 한계

이 방법의 단점은 목표로 정한 예제 사진과 같이 밝은 배경에서는 잘 작동하지만 어두운 배경에서는 문제가 발생

1. 이진화

• 밝은 배경에서는 객체, 배경간 명암 차이가 커서 이진화 작업이 효과적
• 어두운 배경에서는 객체와 배경의 명암 차이가 작아 이진화 작업이 잘 되지 않음 -> 객체 감지 정확도 Down

2. 외곽선 감지

• 객체와 배경의 경계가 명확할 때 잘 작동하지만 어두운 이미지에서는 경계가 불분명해져서 외곽선 감지가 어려움

3. 타겟 경계 박스 설정

• 워핑 작업 수행시 타겟 경계 박스가 필요한데 어두운 배경에서는 1,2와 같은 이유로 타겟 박스 설정이 어려움

결론

예제 사진과 같은 밝은 배경은 정면으로 정렬시키는 작업은 성공했다. 하지만 어두운 배경에서 객체를 감지하여 정면 이미지 변환 작업은 해결하지 못했다. 밝은 배경에서는 비교적 쉽게 가능했지만 이를 위해서 이미지 명암비 조정이나 다른 정보들을 더 찾아보고 공부한 후에 완성해보고 싶다.

MacOS에서 깃 허브 쉽게 설치하기

우선 터미널을 열어줍니다.

❯ git --version

터미널에 다음과 같이 입력했을 때 버전이 뜨지 않았다면 설치를 진행합시다.

$ brew install git

Homebrew를 이용하면 편하게 설치가 가능합니다.

이후 깃 허브 홈페이지(https://github.com/)에 방문해서 새로운 레포를 생성하면 끝

VsCode와 연동하기

처음에 깃을 사용하다보면 복잡한 명령어와 개념들이 와닿지 않습니다. 직접 이것저것 깨져보고 사용하다보면 익숙해져 가는데, 제가 상황에 맞게 쉽게 정리해보았습니다.

ssh 키 발급

1. 기존 발급 받은 ssh키가 있는지 확인하기
cat ~/.ssh/id_rsa.pub 

2. ssh key 생성하기
ssh-keygen

3. ssh 키 클립보드에 복사하기
pbcopy < ~/.ssh/id_rsa.pub

이후 gitHub 홈페이지 로그인 후 설정에 들어가서

사진 속 SSH and GPG keys에 붙여넣기 하면 끝입니다.

내 파일&폴더 깃허브에 올리기

git init : git 초기화 
git remote -v : 로컬 ~ 원격을 잇는 정보확인
git remote add origin(변수) "깃 레포지토리 주소"

레포지토리 주소는 깃 허브 레포 페이지로 이동 후 이 버튼을 통해 쉽게 복사할 수 있습니다.

우선 여기까지 진행하면 이제 해당 주소의 레포지토리에 파일을 업로드할 수 있게 연결된 상태입니다.

git branch : 현재 로컬 브랜치 확인
을 하면 보통 main이나 master 등으로 되어있는데 이 이름을 기억해둡시다.

이제 VsCode에서 업로드를 원하는 파일 디렉토리로 이동합니다. 저의 경우 Python -> 백준 폴더만 이동하고 싶었기 때문에 다음과 같이 이동하였습니다

1-1. git add . : 디렉토리 파일 전체 업로드 1-2. git add 파일명 : 해당 파일만 업로드

이 둘중 원하는 방식을 선택하여 터미널에 입력한 후

2. git status 를 입력하면 현재 상태를 보여줍니다. 저 같은 경우 변경사항이 없기 때문에 위의 사진과 같은 결과가 나왔습니다.

3. git commit -m "Update:: 추가한 내용" 이 단계는 커밋이라고 하는데, 진짜 진짜 마지막 저장 이라고 생각하면 됩니다. 이 커밋 메세지는 사진속 "디렉토리 정리"와 같은 형태로 보여집니다.

4. git push origin master ` 로컬 브랜치에 추가한 파일을 원격 브랜치(깃허브 홈페이지)에 저장 을 하면 끝입니다.

그 외에 경우

1. 깃을 강제로 덮어 씌우기 예를 들면 깃 허브에는 Baekjoon이라는 폴더가 있고 로컬에는 그 폴더는 수정하여 Python, Data 등 새로운 내용으로 구성했을 경우 깃 허브에 레포지토리를 로컬 폴더 구조로 그대로 덮어 씌우는 방법입니다.

git push origin master --force

2. 깃 허브의 백준 폴더가 아닌 다른 폴더에 저장하고 싶다면?

• 기존 origin 원격 저장소 변경 git remote set-url origin 레포지토리링크

• 기존 origin 원격 저장소 제거 후 새로 추가 git remote remove origin git remote add origin 레포지토리링크

• 다른 이름으로 원격 저장소 추가 -> 즉 origin 이라는 이름을 유지하며 추가적인 원격 저장소를 프로젝트에 등록할 때 git remote add 아무이름 레포지토리링크

3. branch 관련 명령어 git branch : 현재 로컬 브랜치 확인 git checkout -b main : main이라는 브랜치를 만듬과 동시에 이동 git branch : 현재 로컬 브랜치 재확인하고 git branch -D <로컬 브랜치 이름> : 브랜치 삭제

바보짓

백엔드 공부 + 프로젝트를 병행 하다보니 어느새 C, Java, Python 등.. 열심히 공부했던 내용들을 어느새 까먹고 있음을 인지해서 오늘부터 깃허브에 잔디를 심어보자 하고 백준 문자열부터 다시 풀이를 하고 있었다.

그래도 어느정도 도전과 실패를 반복하다보니 옛날 처음 백준을 접했을 때는 기초 문제마저 여러번 틀리고 그랬는데 오늘 해보니 1번만에 전부 통과를 했다 !! 단 이 문제 빼고..

백준 1152번 문제 단어의 개수를 보자마자 문제를 너무 대충 읽어서인가?

이런식의 코드를 작성했다

words = input('')
words = words.split(' ')
print(len(words))

테스트 케이스 1번만 보고 내가 아무렇게나 입력해봐도 올바른 단어 수가 나오길래 당당히 제출했는데 그렇다.. 당연히 오답이 나왔다

깜짝 놀랐지만 바로 2번 테스트 케이스를 입력했는데 내 환경에서는 7이 나오더라 자세히 보니까 맨 앞에 공백이 있었고, 저 상태로 split을 하게 되면 공백이기 때문에 이렇게 리스트의 요소로 공백이 추가 되어 내가 예상한 길이 +1만큼의 결과가 나온 것이다.

그럼 나는 이 공백을 없앨 방법을 생각해봤다. 내가 떠오른건 첫번째로

1. filter 함수 이용

filter 함수의 1번째 매개 변수로 None을 주게 된다면, 공백이 사라진다.

words = input('')
words = words.split(' ')
words = list(filter(None, words))
print(len(words))

이 외에도 다른 방법은 없을까? 고민하다가 리스트임을 고려해서 작년쯤 봤던 파이썬 알고리즘 책에서 공부했던 List Comprehension 개념이 떠올랐다.

2. List Comprehension

우선 파이썬에서는 빈 문자열 ''이 False로 취급된다는 점을 알고 가야한다.

파이썬에서 False로 취급되는 것들

빈 문자열 : ''
숫자 0
숫자 0.0
빈 리스트 : []
빈 튜플 : ()
빈 딕셔너리 : {}
'None'

즉 위의 값들은 False로 취급하기 때문에 조건문이 실행되지 않는다.

List Comprehension 구조는 다음과 같다

[ 표현식 for 항목  in 반복 가능 객체 if 조건문 ]

• 표현식 : 리스트 새로운 요소를 정의 (변수, 함수 호출, 실제 값 등) 예시로 num*2는 항목의 값을 두배로 하는 표현식
• 항목 : 반복 가능 객체로부터 하나씩 가져온 개별 요소
• 반복 가능 객체 : 리스트, 튜플, 문자열, 딕셔너리 등 반복을 통해 그 요소들을 하나씩 순회할 수 있는 모든 객체

words = input('')
words = words.split(' ')
words = [w for w in words if w]
print(len(words))

따라서 위의 코드와 같이 words의 요소들을 하나씩 반복하며 요소 w가 참일 경우만 리스트에 포함 시킴으로써 False를 반환하는 '' 공백은 걸러내는 것이다.

1번과 2번 방식 모두 속도는 비슷한 것 같다..?? 아무튼 이 개념을 공부할 당시 내가 딱히 쓸 일이 있을까? 했는데 이런식으로 다시 만나게 될 줄은 몰랐다.

다시 알고리즘 공부를 시작하게 된 지금 앞으로 종종 책에 공부한 내용을 여기에 쉽게 정리하고 공유해야겠다.

Nodejs는 JavaScript를 서버측에서 실행할 수 있게 해주는 것이라고 알고 천천히 살펴보자

배경

이전에 JavaScript 엔진을 만들어 웹 브라우저가 JavaScript를 이해하고 실행할 수 있도록 개선되기 시작했다. 이 때 크롬 V8엔진을 중심으로 빠르게 발전하기 시작했는데, 2009년 Ryan Dahl에 의해 처음으로 발표됐다.

즉, Node js는 자바스크립트 런타임 환경이다.

기존 자바스크립트는 HTML에 종속된 언어이기 때문에 웹 브라우저에서 다음과 같이 사용해야 했다.

하지만 Node.js를 사용한다면 브라우저 없이도 쉽게 사용할 수 있다!

Node js 기본 구조와 특징

Node js 애플리케이션은 메모리 힙과 콜 스택을 포함한다.

• 메모리 힙 : 데이터를 저장하는 공간
• 콜 스택 : 실행중인 코드의 위치를 추적

Node js는 비동기 언어인데, 그 차이점을 한번 비교해보자.

동기 vs 비동기

동기 : 요청을 보낸 후 해당 요청의 응답을 받아야만 다음 동작을 실행하는데, 이는 요청 처리가 완료될 때까지 기다려야 하므로 순차적이고 직렬적인 작업 처리에 적합

비동기 : 요청을 보낸 후 응답과 관계없이 다음 동작을 실행하는 방식으로 응답이 오는 대로 처리할 수 있기 때문에 병렬적인 작업 처리가 가능하며 시스템 자원을 효율적으로 활용 가능

Node.js는 자바스크립트 기반이므로 싱글 스레드이지만 그럼에도 불구하고 굉장히 빠르고 효율적인 서버를 만들 수 있다. 세계적으로 유명한 기업들부터 우리나라의 대기업들도 많이 사용하는 것이 근거이다.

그런데 Node.js는 싱글 스레드이지만 어떻게 좋은 성능을 낼 수 있을까?

바로 Non-Blocking I/O와 Event-Driven 방식으로 되어있기 때문에 멀티스레딩 방식보다 더 효율적으로 I/O 처리를 담당할 수 있다.

Non-Blocking I/O

입출력 작업을 할 때, 한 작업이 완료될 때까지 기다리지 않고 다음 작업을 바로 진행하는 방식이다. 쉽게 말하면 나는 음식점 요리사라고 생각해보자.

동기적 처리의 경우 내가 스테이크를 구울 때 10분이 걸린다면, 이 스테이크가 다 구워질 때까지 아무것도 하지 못하고 기다려야 한다. 비동기적 처리의 경우 스테이크를 굽기 시작하고 그동안 주문을 받는다거나 설거지를 한다. 이후 알람이 울려서 스테이크를 꺼내고 다시 다른 작업을 진행하는 방식이다.

이와 같이 비동기적 처리를 한다면 시스템 자원을 효율적으로 사용할 수 있고, 처리 속도도 빨라진다는 장점이 있다.

Event-Driven

이벤트가 발생시 미리 정의된 콜백 함수를 실행하는 구조이다. 내가 음식점 알바생이라고 생각해보자. 손님 A가 물을 달라고 해서 물을 가져다주는 동안, 손님 B는 주문을 기다리고 있다. 그러면 나는 손님 B의 주문을 받고 주방에 가서 주문을 전달한다. 그리고 다른 손님 C가 계산을 요청하면, 나는 계산을 처리하는데 이 때 이 모든 일들은 순차적으로 이루어지지 않아도 된다. 즉 결론적으로 어떤 이벤트(손님 요청)이 발생하면, 그에 맞는 적절한 행동(콜백 함수)을 하는거다.

결론

Node js는 싱글 스레드이지만 위의 방식들을 이용해 멀티스레딩 방식보다 더 효율적으로 I/O처리를 할 수 있다. 이러한 구조 덕분에 높은 동시성을 요구하는 웹 애플리케이션 개발에 적합하다. 하지만 싱글 스레드 모델은 CPU 집약적인 작업에는 한계를 가지고 있다. 이미지&비디오 처리, 대규모 데이터 처리와 같은 작업은 CPU를 많이 사용하기 때문에 Node.js는 적합하지 않다.