• KEEP
  • 커뮤니케이션 & 협업 문화
    • SNS(Slack)을 활용한 팀원 간 소통
    • 정기, 비 정기 회의 진행
    • Git 코멘트 남겨주는 것(질문, 건의, 개선 사항)
    • 화기애애한 팀 분위기
  • 기술적 협업 도구 활용
    • Git 이슈와 같은 편의 기능 사용 시도
    • 팀원의 코드 리뷰

• Problem
  • 프로젝트 진행
    • 스케줄에 맞춰 프로젝트가 진행되지 못한 점
  • 기술적 빌드 업
    • 트러블 슈팅이 빈약했던 점
    • 코드 주석이 미흡했던 점
  • 프로젝트 발표
    • 발표자 랜덤 선출
    • 회고 내용 업로드 안됨

• Try
  • 코드/기술 고도화
    • 팀원 전체가 코드 리뷰 진행
    • 기술의 사용을 넘어 성능 고도화 시도
    • 접목한 기술에 대한 설명/전수 세션
  • 클라우드 인프라 및 배포 자동화 도구 활용
    • 도커(Docker) 활용
    • AWS & CI / CD 활용
  • Git 활용
    • Git 메시지 템플릿 활용
    • Git 이슈를 활용한 프로젝트 진행
    • Git 프로젝트를 활용한 프로젝트 관리

0. 목차

1. 프로젝트 소개

2. 핵심 기술 요약

3. 동시성 제어

4. 대용량 데이터 처리

5. 캐싱

6. 성과 및 회고

1. 프로젝트 소개

🌸 프로젝트 개요

프로젝트 명 : 온라인 꽃 쇼핑몰 "꽃 향기만 남기고 갔단다"

팀 명 :💰1조 벌자

📡 기술 스택

Language: Java 17

Framework: Spring Boot 3.4.4

ORM: Spring Boot JPA

Database: MySQL, H2

Cache: Redis

Security: Spring Security, JWT

API Docs: Swagger

Version Control: Git, GitHub

Test Tool: k6, Postman, Java Test Code

🎨 와이어 프레임

☁️ ERD

📝 API 명세

2. 핵심 기술 요약

동시성 제어

대용량 데이터 처리

캐싱

3. 동시성 제어

🎟️ 쿠폰 발급 시 재고 감소 제어

📌 배경

• 한정 수량 쿠폰이기 때문에 동시에 많은 사용자가 발급을 시도할 경우,

  → 재고가 음수로 떨어지거나,

  → 중복 발급이 발생할 위험 존재!

• 비관적 락 / 낙관적 락만으로는 분산 환경에서의 정확한 동시성 제어에 한계가 있음

💡 해결 전략

• Redis 기반 분산 락 사용

  → 쿠폰 ID 단위로 락을 획득해 재고 감소 과정에서의 충돌 방지

  → 재고 음수화 방지

  → 수평 확장 용이 (트래픽 증가에도 유연한 대응 가능)

🧑‍💻 구현 코드

    @Override
    public UserCouponIssueResponseDto issueUserCoupon(Long storeId, Long couponId, CustomUserPrincipal principal) {

        User user = validateActivateUser(principal.getUsername());
        Long discountCouponId = discountCouponRepository.findById(couponId)
            .orElseThrow(() -> new ApiException(ErrorStatus.COUPON_NOT_FOUND)).getId();
        // 쿠폰ID 기반으로 락 키 생성
        String lockKey = "coupon-lock:id: " + discountCouponId;
        log.info("lockKey = {}", lockKey);
        RLock lock = redissonClient.getLock(lockKey);
        boolean isLocked;

        try {
                  // 락 획득 시도
            isLocked = lock.tryLock(3000, 3000, TimeUnit.MILLISECONDS);

                        // 락 획득 실패 예외처리
            if (!isLocked) {
                log.warn("[Coupon - 쿠폰 발급] 락 획득 실패, couponId: {}", discountCouponId);
                throw new ApiException(ErrorStatus.COUPON_BAD_REQUEST);
            }

                        // 락 획득 후에만 실제 쿠폰 발급 로직 수행 
            return userCouponTransactionalService.issueUserCoupon(storeId, couponId, user);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            log.warn("[Coupon - 쿠폰 발급] 락 인터럽트", e);
            throw new ApiException(ErrorStatus.STORE_BAD_REQUEST);
        } finally { // 락 해제
            if (lock.isHeldByCurrentThread()) {
                try {
                    lock.unlock();
                } catch (Exception e) {
                    log.error("[Coupon - 쿠폰 발급] 락 해제 실패", e);
                }
            }
        }
    }

• 쿠폰 ID 기반으로 락 키 생성
  • "coupon-lock:id:123" 형태로 고유하게 생성
• tryLock()으로 락 획득을 시도함
  • 첫 번째 인자 waitTime: 락을 기다릴 최대 시간 (3초)
  • 두 번째 인자 leaseTime: 락이 자동으로 해제될 시간 (3초)
  • → 락이 일정 시간 후 자동으로 풀려 데드 락 방지
• 락 획득 실패 시 예외 처리 → 재고가 동시에 소진 중일 경우 안정적 대응
• 동시성 환경에서도 정확히 하나의 요청만 쿠폰을 발급

📊 결과

4. 대용량 데이터 처리

🧾 발급 가능한 쿠폰 목록 조회

📌 배경

• 유저가 발급 가능한 쿠폰 목록을 조회하기 위해

  → DiscountCoupon 테이블과 UserCoupon 테이블을 조인하여 필터링 수행

• 유저 수 × 쿠폰 수가 많아질수록 → 조회 성능 급격히 저하

💡 해결 전략

• DB 인덱스 최적화
  • user_id + coupon_id + is_used 복합 인덱스 설정 → 조인 및 서브쿼리 성능 개선
• DTO Projection 적용
  • 조회 대상 컬럼만 선택적으로 가져와 불필요한 데이터 로딩 방지

👩‍💻 구현 코드

1. DB 인덱스 최적화

// DiscountCoupon : 가게별 쿠폰 + 삭제 여부로 필터링
@Table(name = "discount_coupon", indexes = @Index(name = "idx_discount_coupon_store_deleted ", columnList = "store_id, is_deleted"))

// UserCoupon : (user, coupon) 유일성 보장 + 미사용 쿠폰만 필터링
@Table(name = "user_coupon", uniqueConstraints = {
    @UniqueConstraint(columnNames = {"user_id", "coupon_id"})
}, indexes = {
    @Index(name = "idx_user_coupon_user_coupon_used", columnList = "user_id, coupon_id, is_used")
})

 2. DTO Projection

    @Query("""
    SELECT new com.example.springplusteamproject.domain.coupon.dto.response.IssuableUserCouponResponseDto(
        dc.id, dc.couponName, dc.discount, dc.issuedAt, dc.expiresAt, dc.stock
    ) 
    FROM DiscountCoupon dc
    WHERE dc.store.id = :storeId
      AND dc.isDeleted = false
      AND NOT EXISTS (
          SELECT 1
          FROM UserCoupon uc
          WHERE uc.discountCoupon.id = dc.id
            AND uc.user.id = :userId
            AND uc.isUsed = false
      )
    """)
    List<IssuableUserCouponResponseDto> findIssuableCouponDtoList(
        @Param("userId") Long userId,
        @Param("storeId") Long storeId
    );

📊 결과

5. 캐싱

🛒  인기 가게 조회

📌 배경

• 인기 가게 리스트는 조회 빈도가 매우 높음

• 하지만 실시간으로 자주 변경되지는 않음

  → 매번 DB에서 조회 시 성능 저하 및 부하 발생

💡 해결 전략

• Redis 캐싱 활용

  • Redis를 단순 캐시가 아닌 카운터 저장소로 사용
    • 각 가게에 대한 조회 수 증가를 Redis에서 처리
    • 인기 순위는 사용자 액션(조회수)에 따라 실시간으로 변동
    • 추후 DB 저장 방식으로 변환 용이

• 따라서, 정적인 캐싱이 아닌 동적인 캐싱 구조 설계

  → 사용자 행동 기반의 실시간 인기 가게 목록 제공

👩‍💻 구현 코드

    // 인기 가게 조회수 기준 정렬 및 TOP 10 추출
    @Override
    public List<StoreResponseDto> getPopularStoresByView() {
        Set<String> keys = longRedisTemplate.keys("store:viewcount:*");

        return keys.stream()
            .map(k -> {
                Long id = Long.parseLong(k.replace("store:viewcount:", ""));
                Object raw = longRedisTemplate.opsForValue().get(k);
                Long count = (raw instanceof Long) ? (Long) raw
                    : (raw instanceof Integer) ? ((Integer) raw).longValue()
                    : 0L;
                return Map.entry(id, count);
            })
            .sorted((a, b) -> Long.compare(b.getValue(), a.getValue()))
            .limit(10)
            .map(e -> storeRepository.findByIdAndDeletedFalse(e.getKey()).orElse(null))
            .filter(Objects::nonNull)
            .map(StoreResponseDto::fromEntity)
            .toList();
    }

        // 인기 가게 리스트를 10분마다 Redis에 캐싱
    @Scheduled(initialDelay = 0, fixedRate = 600_000)
    public void updatePopularStoresCache() {
        List<StoreResponseDto> topStores = getPopularStoresByView();
        objectRedisTemplate.opsForValue().set("popular:stores:view", topStores, CACHE_TTL);
        log.info("[Store - 캐싱]인기 상점 캐시 갱신 완료 ({}개)", topStores.size());
    }

📊 결과

• 테스트 설계

| 항목 | 내용 |
| --- | --- |
| 목적 | 커서 기반 **DB조회** vs **Redis 캐시** 기반 인기 상점 조회 성능 비교 |
| 실행 환경 | Local |
| 도구 | k6 |
| 테스트 대상 | 1,000 ~ 10,000명의 유저의 동시 요청 시나리오 |
| 부하 단계 | 1단계 : 1~10 초간 1,000명의 유저가 동시 요청, 2단계 : 11~20 초간 5,000명의 유저가 동시 요청, 3단계 : 21~30 초간 10,000명의 유저가 동시 요청 |

1 단계 부하 테스트 결과 요약

| 항목 | DB 커서 조회 | Redis 캐시 조회 |
| --- | --- | --- |
| 평균 응답 | 347ms | **238ms** |
| 최대 응답 | 804ms | **595ms** |
| 95% 응답 | 457ms | **317ms** |
| 요청 처리량
(req/s) | 2,761 | **4,184** |
| 총 요청 수 | 28,506 | **41,657** |
| 실패율 | 1.8% | **1.2%** |

1 ~3 단계 부하 테스트 결과 요약

| 항목 | DB 커서 조회 | Redis 캐시 조회 |
| --- | --- | --- |
| 평균 응답  | 1.6s | **1.06s** |
| 최대 응답 | 13.5s | **13.5s** |
| 95% 응답 | 3.37s | **2.34s** |
| 요청 처리량(req/s) | 1,774 | **2,155** |
| 총 요청 수 | 108,000 | **150,845** |
| 실패율 | 5.6% | 5.6% |

캐시는 빠르지만, 갱신 타이밍이나 Redis saturation 시 실패율이 증가하였음 1. 캐시가 응답 시간, 처리량 면에서 전 구간 우세 2. Redis saturation 시점(갱신 or 트래픽 픽크)에 실패율 급증 3. 캐시가 빠르지만 구조적 보완 필요 → 추후 개선

6. 성과 및 회고

👩‍💻 추후 개선 내용

✅ Redis 캐싱 구조 개선

‼문제점

• Redis는 빠르고 확장성 높지만 TTL 만료, 동시 갱신 충돌, SPOF, 부하 집중 시 불안정

💡 개선 방향

• Double Buffering

  → 캐시 갱신 중 충돌 방지 (기존 캐시 유지 + 신규 캐시 준비 후 전환)

• Lazy TTL / Fallback

  → TTL 만료 시 캐시 miss 최소화 및 DB fallback 후 재캐싱

• Redis 구조 확장

  → Cluster: 샤딩 통한 수평 확장

  → Sentinel: 자동 Failover로 고가용성

  → Pipeline: 명령어 일괄 처리로 속도 향상

• ⚠️ Null 응답 + DB fallback

   → 캐시 miss 시 null 반환 → DB 조회 후 재캐싱 (병목 최소화)

✅ 재고 감소 Redis 리팩토링

‼문제점

• createOrder가 조회 ~ 주문 생성까지 과도한 책임 수행 → SRP 위반

• 내부에서 @Transactional + REQUIRES_NEW 중첩 호출

  → 재고는 차감됐지만 주문은 롤백되는 트랜잭션 충돌

  → 락 해제 누락 시 Deadlock 위험

💡 개선 방향

✔ 락 → 트랜잭션 → 커밋 → 락 해제 흐름 보장

1. Controller에서 lockAndCreateOrder 호출 → 락 먼저 획득
2. Service에서 단일 @Transactional로 재고 차감부터 주문 생성까지 일괄 처리

👩‍💻 구현 코드

• 락을 먼저 획득

public Flower lockAndDecreaseStock(OrderRequestDTO dto, CustomUserPrincipal principal) {
        String lockKey = "order-lock:user:" + principal.getId();
    RLock lock = redissonClient.getFairLock(lockKey);

    try {
        if (!lock.tryLock(500, -1, TimeUnit.MILLISECONDS)) {
            throw new RuntimeException(락 획득 실패: " + lockKey);
        }

        return orderService.createOrder(dto, principal);

    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
        throw new ApiException(ErrorStatus.ORDER_BAD_REQUEST);
    } finally {
        if (lock.isHeldByCurrentThread()) {
            lock.unlock();
        }
    }
}

• Create 호출

@Transactional
public OrderResponseDTO createOrder(
OrderRequestDTO requestDTO, CustomUserPrincipal principal
) {
    //유저 조회
    User user = userRepository.findById(principal.getId())
        .orElseThrow(() -> new ApiException(ErrorStatus.ORDER_USER_NOT_FOUND));

    List<OrderItem> orderItems = new ArrayList<>();
    //전체 금액
    int priceTotal = 0;
    Long discount = 0L;
    for(OrderItemRequestDTO item : requestDTO.getItems()) {
        // 꽃 Id(상품Id)
        Long flowerId = item.getFlowerId();
        //수량
        int quantity = item.getQuantity();

        Flower flower = flowerRepository.findById(flowerId)
            .orElseThrow(() -> new ApiException(ErrorStatus.ORDER_FLOWER_NOTFOUND));
            log.info("재고 감소전 >>> {}", flower.getStock());
            flower.decreaseStock(quantity);
            log.info("재고 감소후 >>> {}", flower.getStock());

        //단가
        int unitPrice = foundFlower.getPrice();
        int subTotal = unitPrice * quantity;
        priceTotal += subTotal;

        Price price = Price.of(subTotal, discount);
        OrderItem orderItem = OrderItem.of(null, foundFlower, quantity, price);
        orderItems.add(orderItem);
    }
    UserCoupon foundUserCoupon = null;

    //쿠폰이있으면
    if(requestDTO.getUserCouponId() != null) {
            foundUserCoupon = userCouponRepository
                .findById(requestDTO.getUserCouponId())
                .orElseThrow(() -> 
                    new ApiException(ErrorStatus.ORDER_COUPON_NOTFOUND));

        //본인확인
        if(!foundUserCoupon.getUser().getId().equals(user.getId())){
            throw new ApiException(ErrorStatus.ORDER_COUPON_OWNER_MISMATCH);
        }

        //중복 방지
        if(foundUserCoupon.isUsed()){
            throw new ApiException(ErrorStatus.ORDER_COUPON_ALREADY_USED);
        }

        //할인
        discount = foundUserCoupon.getDiscountCoupon().getDiscount();
        //dirty
        foundUserCoupon.useCoupon();

    }
    //가격 저장
    Price price = Price.of(priceTotal,discount);

    //주문 저장
    Order order = Order.of(user, price, orderItems);

    if(foundUserCoupon != null){
        order.setUserCoupon(foundUserCoupon);
    }
    Order savedOrder = orderRepository.save(order);

    //결제 API

    //dirty PAID
    order.updateStatus();
    return OrderResponseDTO.from(savedOrder);
}

🧾최종 정리

이번 프로젝트 “꽃향기만 남기고 갔단다”는 실제 쇼핑몰 서비스 구조를 기반으로,

동시성 제어, 대용량 데이터 처리, 캐싱 구조 고도화 등

실무 중심의 백엔드 핵심 기술을 직접 다뤄볼 수 있었던 경험이었습니다.

• Redis 기반 분산 락과 비관적 락을 통해 재고, 쿠폰 발급 등의 동시성 문제 해결

• 복합 인덱스 + DTO Projection으로 대용량 데이터 조회 성능 최적화

• Redis 캐시를 단순 저장소가 아닌 실시간 인기 카운터로 활용

  → k6 기반 부하 테스트를 통해 성능 수치화 및 병목 파악, 개선 포인트 도출

또한, 기술적인 고도화 외에도

팀원 간 자유로운 소통, 정기적인 회의, 문서 기반 협업을 통해

실제 개발 협업에서의 유연한 커뮤니케이션과 협업 역량의 중요성을 체감할 수 있었습니다.

다만,

• 일정 관리 미흡
• 트러블 슈팅 및 기술 회고의 부족
• 코드 주석 작성의 일관성 부족

등은 다음 프로젝트에서 개선해야 할 과제로 남았습니다.

이번 프로젝트는 단순한 기능 구현을 넘어,

서비스의 확장성과 안정성을 고려한 기술 설계와 협업 경험을 모두 담아낸 소중한 기회였습니다.

1. CI/CD란?

1. 정의

• CI: Continuous Integration (지속적인 통합)
• CD: Continuous Delivery / Deployment (지속적인 제공/배포)

2. 특징

• 자동화된 빌드, 테스트, 배포
• 안정적이고 빠른 코드 제공 가능
• 스크럼 기반의 애자일 개발과 잘 어울림

3. 전통적인 배포 vs 현대적 배포

2. Docker 기초

1. 왜 Docker인가?

• 환경 차이 없이 동일한 컨테이너 환경에서 실행 가능
• 독립적이고 확장성 있는 배포 가능
• CI/CD와의 궁합 좋음
• 호스트 OS에 영향 없음

3. Docker 설치

Windows

• WSL2 설치: wsl --install
• Ubuntu 22.04 설치
• Docker GPG 키 및 리포지토리 설정 후 설치
• Docker Desktop 설정에서 WSL 연동

4. Container 실행 테스트

docker image pull nginx:1.25.3-alpine
docker run -d -p 8001:80 --name webserver01 nginx:1.25.3-alpine
curl localhost:8001

5. Docker Image 관리

1. 개념

• Stateless: 상태 비저장
• Immutable: 변경 불가 이미지

2. 주요 명령어

docker pull nginx:latest
docker image inspect nginx:latest
docker image history nginx:latest
docker login
docker logout

6. Docker Container 관리

1. Image vs Container

• Image: 레시피(붕어빵 틀)
• Container: 실행된 인스턴스(붕어빵)

2. 주요 명령어

docker run -ti --name test ubuntu:22.04
docker start test
docker attach test
docker ps -a
docker stop test
docker rm test
docker logs test
docker inspect test

3. 포트, 로그, 리소스 확인

docker port test
docker stats test
docker logs -f test

7. Docker 파일 생성 및 실행 실습

mkdir nodejsapp && cd nodejsapp
# app.js 및 Dockerfile 생성
docker buildx build -t node-test:1.0 .
docker run -itd -p 6060:6060 --name=node-test node-test:1.0
curl http://localhost:6060

8. 정리 및 정리 명령어

1. 리소스 정리

docker container prune         # 중지된 컨테이너 삭제
docker image prune             # Dangling 이미지 삭제
docker system prune            # 전체 정리

2. Github & CI/CD

1. Github Actions란?

정의

• Github에 내장된 CI/CD 도구
• .github/workflows 디렉토리에 YAML 파일 작성
• 무료 제공: 500MB 저장공간 + 월 2000분

2. Github Actions로 CI 구성

예시 워크플로우

name: CI
on:
  push:
    branches: [develop, feature/*]
  pull_request:
    branches: [develop]

jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - name: checkout
        uses: actions/checkout@v4
      - name: java setup
        uses: actions/setup-java@v2
        with:
          distribution: 'adopt'
          java-version: '17'
      - name: run unittest
        run: ./gradlew clean test

3. Github Actions로 CD 구성

예시 워크플로우

name: CD
on:
  push:
    branches: [main]

jobs:
  cd:
    runs-on: ubuntu-latest
    steps:
      - name: checkout
        uses: actions/checkout@v4
      - name: java setup
        uses: actions/setup-java@v3
        with:
          distribution: 'adopt'
          java-version: '17'
      - name: run unittest
        run: ./gradlew clean test
      - name: deploy to heroku
        uses: akhileshns/heroku-deploy@v3.12.12
        with:
          heroku_api_key: ${{ secrets.HEROKU_API_KEY }}
          heroku_app_name: "sampleapp-github-actions"
          heroku_email: "nbcdocker@proton.me"

4. Github Actions 주요 구성 요소

5. 예제 실행

간단한 데모 워크플로우

name: GitHub Actions Demo
on: [push]

jobs:
  Explore-GitHub-Actions:
    runs-on: ubuntu-latest
    steps:
      - run: echo "🎉 자동 트리거됨!"
      - run: echo "🐧 OS: ${{ runner.os }}"
      - name: Check out repository
        uses: actions/checkout@v4

6. Spring Boot + Github Actions (CI)

• develop, feature 브랜치에 push 또는 PR 발생 시 gradle test 실행

✔ 예시: .github/workflows/run-test.yaml

name: Run Test
on:
  push:
    branches: [develop, feature/*]
  pull_request:
    branches: [develop]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: checkout
        uses: actions/checkout@v4
      - name: java setup
        uses: actions/setup-java@v2
        with:
          distribution: 'adopt'
          java-version: '17'
      - name: make executable gradlew
        run: chmod +x ./gradlew
      - name: run unittest
        run: ./gradlew clean test

7. Cloudtype 배포 자동화

1. 개념 흐름

1. feature/** → PR 생성 → 자동 테스트
2. PR 성공 시 → main 브랜치 merge
3. main → 자동 배포 to cloudtype

2. PR 테스트용: test-pr.yml

name: test every pr
on:
  workflow_dispatch:
  pull_request:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - name: setup jdk
        uses: actions/setup-java@v3
        with:
          java-version: '17'
          distribution: 'temurin'
          cache: gradle
      - name: Grant execute permission
        run: chmod +x ./gradlew
      - name: gradlew test
        run: ./gradlew test

3. Cloudtype 배포용: deploy-main.yml

name: Deploy to cloudtype
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - name: Connect deploy key
        uses: cloudtype-github-actions/connect@v1
        with:
          token: ${{ secrets.CLOUDTYPE_TOKEN }}
          ghtoken: ${{ secrets.GHP_TOKEN }}
      - name: Deploy
        uses: cloudtype-github-actions/deploy@v1
        with:
          token: ${{ secrets.CLOUDTYPE_TOKEN }}
          project: nbc.docker/cicd
          stage: main
          yaml: |
            name: cicd
            app: java@17
            options:
              ports: 8080
            context:
              git:
                url: git@github.com:${{ github.repository }}
                ref: ${{ github.ref }}
              preset: java-springboot

8. 환경 설정 가이드

1. Cloudtype

• 가입: cloudtype.io
• 카드 등록 후 무료 요금제 활성화 필요
• API 키 발급 후 Github Secrets에 등록

2. Github Secrets 등록

3. Docker

1. Dockerfile로 나만의 Docker Image 만들기

1. 개념

• Dockerfile은 앱 실행을 위한 모든 환경 설정 레시피
• 동일한 환경, 자동화된 이미지 생성, 재사용 가능

2. 예제

FROM ubuntu:latest
RUN apt-get update && apt-get install -y nginx
COPY index.html /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

3. 명령어 정리

2. Docker Compose를 사용한 멀티 컨테이너 관리

1. Docker Compose란?

• 여러 컨테이너를 하나의 YAML 파일로 정의
• 의존성 관리, 포트 설정, 환경변수 관리 가능

2. 예제: docker-compose.yaml

version: '3'
services:
  web:
    image: nginx:latest
    ports:
      - 80:80
    depends_on:
      - api
  api:
    image: java:latest
    ports:
      - 8080:8080
    environment:
      - MYSQL_HOST=mysql
  mysql:
    image: mysql:latest
    ports:
      - 3306:3306
    environment:
      - MYSQL_ROOT_PASSWORD=password

3. Docker Compose 명령어

4. 모니터링과 로깅

1. docker stats

docker stats

• CPU, 메모리 사용량, I/O 실시간 확인

2. htop 도구 설치 및 실행

docker exec -ti test-tools /bin/bash
apt update && apt install htop -y
htop

3. 디스크 확인

docker exec -ti test-tools /bin/bash
df -h
du -sh

5. 컨테이너 로깅

1. 로그 확인

docker logs [컨테이너명]
docker logs -f --tail 10 [컨테이너명]

2. 로그 파일 경로 확인

docker inspect [컨테이너명] --format "{{.LogPath}}"

3. 로그 로테이션 예제

docker run -d \
  --log-driver json-file \
  --log-opt max-size=10m \
  --log-opt max-file=5 \
  --name nginxtest \
  nginx:latest

4. docker-compose 로 설정

services:
  app:
    logging:
      driver: 'json-file'
      options:
        max-size: '10m'
        max-file: '10'

프로젝트 전환 및 기본 설정

1. Kotlin 기반 프로젝트

• 기존 Java 기반 코드에서 Kotlin으로 전환.

2. 디렉토리 구조 정리

• /src/main/kotlin에 코어 비즈니스 로직 이전.
• /java/org.example.expert → /kotlin/com.example.domain로 이전하며 패키지 통일.

3. 공통 설정 파일

• application.yml 구성 완료.
• .env 파일을 통해 외부 환경변수 분리.
• SECRET_KEY, MYSQL_USERNAME 등 중요한 값들은 .env로 관리.

보안 / 인증 시스템 구축

1. JWT 유틸 클래스 구현 (JwtUtil.kt)

• HS256 알고리즘 기반 JWT 생성 및 파싱 구현.
• Claims 필드: userId, email, userRole, nickname
• 만료 시간: 60분 설정.

@PostConstruct
fun init() {
    val bytes = Base64.getDecoder().decode(secretKey)
    key = Keys.hmacShaKeyFor(bytes)
}

2. JWT 필터 구현 (JwtAuthenticationFilter.kt)

• OncePerRequestFilter 상속.
• 토큰 유효 시 사용자 인증 정보를 SecurityContextHolder에 등록.

3. Spring Security 설정 (SecurityConfig.kt)

• /auth/**는 허용
• /admin/**은 ADMIN Role만 허용
• 나머지는 모두 인증 필요
• Stateless 정책, Form Login / HTTP Basic 비활성화

http.csrf().disable()
    .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)

사용자 기능

1. User 엔티티 변경

• User.kt 클래스에 profileImage 필드 추가
• fromAuthUser() 정적 팩토리 메서드 도입
• changePassword, updateRole, setProfileImage 메서드 구현

2. UserController.kt / UserService.kt

• 비밀번호 변경 API (/users, PUT)
• 사용자 정보 조회 (/users/{userId})
• 닉네임 기반 조회 캐싱 적용 (@Cacheable)

3. 예외 처리

• InvalidRequestException, AuthException, ServerException 공통 처리
• @RestControllerAdvice 기반 글로벌 예외 핸들러 작성

Todo 기능

1. Todo 엔티티 및 Repository

• title, contents, weather, user 필드 포함
• findAllByOrderByModifiedAtDesc() / searchTodos() 구현

2. TodoService.kt

• saveTodo: 날씨 조회 후 저장
• getTodos: 페이징 조회
• searchTodos: 조건부 검색
• getTodo: 단일 조회 + User join
• searchTodosWithFilters: QueryDSL 기반 키워드, 닉네임, 날짜 필터링

3. TodoQueryRepositoryImpl

• Projections.constructor를 사용한 커스텀 DTO 매핑
• groupBy, leftJoin, where절 조합
• count 쿼리 분리하여 페이징 대응

Manager 기능

1. Manager 엔티티

• @ManyToOne 연관관계로 User, Todo를 소유
• @Id, @GeneratedValue 전략

2. ManagerService

• saveManager: 일정 작성자와의 매칭 여부 검증
• deleteManager: 생성자만 삭제 가능
• getManagers: 일정별 매니저 목록 조회

3. 로깅 기능 추가

• Log 엔티티: action, details, createdAt
• LogService: @Transactional(REQUIRES_NEW)로 로그 분리 저장
• 예외가 발생해도 로그는 저장되도록 finally 블록 활용

Comment 기능

1. Comment 엔티티

• contents, user, todo, Timestamped 상속

2. CommentService

• saveComment: Todo 존재 여부 확인 후 저장
• getComments: TodoId로 Comment 전체 조회 (User Join 포함)

AWS / Redis 설정

1. S3 연동 (S3Service.kt)

• updateFile() 메서드 구현
• 파일은 UUID 기반 이름으로 업로드

2. Redis 설정 (RedisConfig.kt)

• RedisTemplate 및 RedisCacheManager 설정
• TTL: 10분

테스트 및 부가사항

• @GetMapping("/health"): Health Check API 제공
• AdminAccessLoggingAspect: AOP로 UserController.getUser() 접근 로그 출력
• 전체적으로 !!, ?, lateinit 등의 코틀린 nullable 처리 점검
• @Valid, @RequestParam, @PageableDefault 등 다양한 Spring 어노테이션 적용

해결한 문제 목록

PasswordEncoder Bean 오류

• 의존성 누락 문제였으나, Spring Boot Starter Security로 해결됨

JwtUtil 빈 주입 실패

• SECRET_KEY 환경변수가 .env로만 존재할 때 인식 안됨
• 해결 방법: .env -> OS 환경변수로 등록 or .yml에 직접 선언

LocalDateTime? → LocalDateTime 타입 불일치

• Repository 쿼리에서 nullable 타입이어서 타입 mismatch 오류 발생
• todoRepository.searchTodos(pageable, weather, start ?: now(), end ?: now()) 식으로 대응

@Generated Q 클래스 import 오류

• Kotlin, Java 혼합 프로젝트에서 QueryDSL의 Q클래스 import 경로 꼬임 문제 발생
• 해결: QueryDSL 생성 경로를 kotlin에 통일 / querydslDir 명시

1. Kotlin vs Java 기본 비교

2. Nullable (?)과 Non-nullable

val name: String = "hello"       // null 불가
val nickname: String? = null     // null 가능

• Kotlin은 null safety 기본 제공
• ?를 붙여야 null 할당 가능

3. !! (Non-null 단언 연산자)

val length = name!!.length

• !!는 null이 절대 아님을 강제
• null이면 런타임에서 NPE 발생 → 사용 지양

4. ?. (safe call), ?: (엘비스)

val length = name?.length               // null이면 null 반환
val finalName = name ?: "기본값"        // null이면 우측 값 반환

5. 자바 → 코틀린 자동 변환 후 필수 점검 항목

1. !! 남용
2. DTO → data class 변환
3. @NotBlank → @field:NotBlank
4. 클래스 상속 필요 시 open 키워드 사용
5. companion object에 @JvmStatic 필요한 경우

6. Kotlin의 대표 문법들

data class

data class User(val id: Long, val name: String)

• equals, hashCode, toString, copy() 자동 생성

when

when (role) {
    "ADMIN" -> ...
    "USER" -> ...
    else -> ...
}

문자열 템플릿

val name = "Kotlin"
println("Hello $name!")  // Hello Kotlin!

7. 코틀린 스타일

• val → 불변 (기본적으로 사용)
• var → 변경 가능한 경우만 사용
• 명확한 null 구분 (?, !!, ?:)
• 한 줄 함수는 = 로 작성 가능

fun square(x: Int) = x * x

8. 팁

• 자동 변환 → !! 제거 → 의존성 주입 수정 → DTO 정리
• QueryDSL은 @QueryProjection 사용 + data class 유지
• Entity는 가급적 var, DTO는 val
• lateinit은 @PrePersist, Bean 주입 외에는 지양

2. Kotlin 리팩토링

1. Build.gradle 설정

plugins {
    id 'org.jetbrains.kotlin.jvm' version '2.0.0'  
    id 'org.jetbrains.kotlin.plugin.lombok' version '2.0.0'  
    id 'org.jetbrains.kotlin.plugin.spring' version '2.0.0'  
    id 'org.jetbrains.kotlin.plugin.jpa' version '2.0.0' 
    id 'org.jetbrains.kotlin.kapt' version '2.0.0'
}

sourceSets {
    main {
        java {
            srcDirs += "src/main/kotlin"
        }
    }
}

dependencies {

//   annotationProcessor 'com.querydsl:querydsl-apt:5.0.0:jakarta' 주석처리

    //Kotlin
    implementation "org.jetbrains.kotlin:kotlin-stdlib"
    implementation "org.jetbrains.kotlin:kotlin-reflect" 
    kapt "com.querydsl:querydsl-apt:5.0.0:jakarta"  
    kapt "jakarta.annotation:jakarta.annotation-api"  
    kapt "jakarta.persistence:jakarta.persistence-api"
}

kapt {  
    keepJavacAnnotationProcessors = true  
}

allOpen {
    annotation("jakarta.persistence.Entity")
    annotation("jakarta.persistence.Embeddable")
    annotation("jakarta.persistence.MappedSuperclass")
}

2. 주요 작업

• 기존 Java 코드를 Kotlin으로 자동 변환(ctrl + shift + a -> Convert Java File to Kotlin File ) 후 수작업 리팩토링
• !! 제거, 명확한 null-safe 설계
• DTO는 data class, Entity는 class
• @field:NotBlank 등 validation 어노테이션 위치 수정
• Service/Controller의 의존성 주입은 생성자 기반으로 재작성

3. User / Todo 도메인 리팩토링

User 엔티티

@Entity
@Table(name = "users")
class User(
    @Column(unique = true)
    var email: String,

    var password: String? = null,

    @Enumerated(EnumType.STRING)
    var userRole: UserRole,

    var nickname: String,

    var profileImage: String? = null
) {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    var id: Long? = null
        protected set

    companion object {
        @JvmStatic
        fun fromAuthUser(authUser: AuthUser): User {
            return User(authUser.email, null, authUser.userRole, authUser.nickname).apply {
                this.id = authUser.id
            }
        }
    }
}

Todo 엔티티

@Entity
@Table(name = "todos")
class Todo(
    var title: String,
    var contents: String,
    var weather: String,

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "user_id", nullable = false)
    var user: User
) {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    var id: Long? = null

    @OneToMany(mappedBy = "todo", cascade = [CascadeType.REMOVE])
    val comments: MutableList<Comment> = mutableListOf()

    @OneToMany(mappedBy = "todo", cascade = [CascadeType.ALL], orphanRemoval = true)
    val managers: MutableList<Manager> = mutableListOf()

    init {
        managers.add(Manager(user, this))
    }
}

TodoService 일부

@Transactional
fun saveTodo(authUser: AuthUser, request: TodoSaveRequest): TodoSaveResponse {
    val user = User.fromAuthUser(authUser)
    val weather = weatherClient.todayWeather
    val saved = todoRepository.save(Todo(request.title, request.contents, weather, user))
    return TodoSaveResponse(saved.id!!, saved.title, saved.contents, weather, UserResponse(user.id!!, user.email))
}

4. 이슈 및 해결

5. 리팩토링 항목

• TodoRepository, TodoQueryRepository Kotlin 스타일로 정리
• TodoController에서 !! 제거, request/response 명확화
• Log Entity에서 @PrePersist와 lateinit var 안전하게 구성
• DTO는 모두 data class로 통일

정리

• User, Todo 도메인의 CRUD Kotlin 전환 완료
• QueryDSL, validation, JPA 호환 확인

• 대용량 데이터 처리 실습을 위해, 테스트 코드로 유저 데이터를 100만 건 생성해주세요.
  • 데이터 생성 시 닉네임은 랜덤으로 지정해주세요.
  • 가급적 동일한 닉네임이 들어가지 않도록 방법을 생각해보세요.

• 닉네임을 조건으로 유저 목록을 검색하는 API를 만들어주세요.
  • 닉네임은 정확히 일치해야 검색이 가능해요.
• 여러가지 아이디어로 유저 검색 속도를 줄여주세요.
  • 조회 속도를 개선할 수 있는 여러 방법을 고민하고, 각각의 방법들을 실행해보세요.
  • README.md 에 각 방법별 실행 결과를 비교할 수 있도록 최초 조회 속도와 개선 과정 별 조회 속도를 확인할 수 있는 표 혹은 이미지를 첨부해주세요.

1. 최초 설계

코드

Controller

    @GetMapping("/user/nickname")
    public ResponseEntity<User> getUserByNickname(@RequestParam String nickname) {
        User user = userService.getUserByNickname(nickname);
        return ResponseEntity.ok(user);
    }

Repository

Optional<User> findByNickname(String nickname);

Service

public User getUserByNickname(String nickname) {
        return userRepository.findByNickname(nickname)
            .orElseThrow(() -> new IllegalArgumentException("사용자가 없습니다."));
    }

K6

• 요약 actively refused 발생: 서버가 감당 못하고 연결 자체를 끊어버림 평균 응답 시간 12.8초(12860ms), p95 = 36.7초(39800ms) 부하가 1초에 수백건이 들어 오면 일부만 응답 성공

2. 코드 개선 - DB 인덱싱

조회를 진행할때 인덱싱이 되어 있지 않으면 풀 스캔 -> nickname 인덱싱

UserEntity

@Table(name = "users", indexes = {
    @Index(name = "idx_nickname", columnList = "nickname")
})

• 위 코드를 추가함으로 nickname 컬럼에 인덱스 지정
  

주의

• 이미 생성된 테이블의 경우 적용 안됨

• 직접 DDL 실행

직접 SQL로 인덱스 추가 - 이미 생성된 테이블의 경우

CREATE INDEX idx_nickname ON users(nickname);

K6

• 요약 nickname 필드에 인덱스 추가 후, 성능이 비약적으로 향상됨 실패율이 2% 이하로 감소했고, 응답 시간도 평균 1초 이내로 안정화 서버가 동시 1000명 × 10초간 요청을 처리 가능함 평균 응답 시간 0.331초(331.98ms), p95 = 0.405초(405.08ms)
• 이전 테스트 대비 성공률 +34%, 평균 응답 시간 -11초 이상 개선됨*

3. DB 커넥션 풀 튜닝(HikariCP)

병목 가능성: 다수의 요청이 들어 올 경우 커넥션 부족으로 대기 시간 존재 -> .yml파일 maximumPoolSize, connectionTimeout 조정

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/${MYSQL_NAME}?useSSL=${SSL}&allowPublicKeyRetrieval=${ALLOWPUBLICKEYRETRIEVAL}
    username: ${MYSQL_USERNAME}
    password: ${MYSQL_PASSWORD}
    driver-class-name: com.mysql.cj.jdbc.Driver
    hikari:
      maximum-pool-size: 32 //동시에 사용할 수 있는 최대 커넥션 (서버 CPU의 스레드 * 2)
      minimum-idle: 10 // 최소 대기 커넥션
      idle-timeout: 30000 // 최대 대기 시간
      max-lifetime: 1800000 // 커넥션 하나의 최대 생존시간
      connection-timeout: 30000 // 커넥션 획득까지 기다릴 최대 시간

K6

• 요약 응답 시간은 평균 0.323초(323.39ms), p95 = 0.396초(396.79ms) 실패율 36.08%(최초) -> 2.06%(1차 개선) -> 1.24%(현재)

4. Redis 도입

한번 호출한 유저 정보를 Redis에 10분 간 저장하고, 10분내에 재 호출 할 경우 Redis에서 바로 응답

.yml

spring:
  data:
    redis:
      host: localhost
      port: 6379

RedisConfig

@Configuration
@EnableCaching
public class RedisConfig {

    @Bean
    public RedisConnectionFactory redisConnectionFactory() {
        return new LettuceConnectionFactory();
    }

    @Bean
    public RedisTemplate<String, Object> redisTemplate() {
        RedisTemplate<String, Object> template = new RedisTemplate<>();
        template.setConnectionFactory(redisConnectionFactory());
        template.setKeySerializer(new StringRedisSerializer());
        template.setValueSerializer(new GenericJackson2JsonRedisSerializer());
        return template;
    }

    @Bean
    public RedisCacheManager cacheManager(RedisConnectionFactory connectionFactory) {
        RedisCacheConfiguration config = RedisCacheConfiguration.defaultCacheConfig()
            .entryTtl(Duration.ofMinutes(10)) // 10분 TTL
            .serializeKeysWith(RedisSerializationContext.SerializationPair.fromSerializer(new StringRedisSerializer()))
            .serializeValuesWith(RedisSerializationContext.SerializationPair.fromSerializer(new GenericJackson2JsonRedisSerializer()));

        return RedisCacheManager.builder(connectionFactory).cacheDefaults(config).build();
    }
}

UserService

@Cacheable(value = "userByNickname", key = "#nickname", unless = "#result == null")
    public User getUserByNickname(String nickname) {
        return userRepository.findByNickname(nickname)
            .orElseThrow(() -> new IllegalArgumentException("사용자가 없습니다."));
    }

K6

• 요약 응답 시간은 평균 0.250초(250.80ms), p95 = 0.292초(292.66ms) 실패율 36.08%(최초) -> 2.06%(1차 개선) -> 1.24%(2차 개선) -> 0%(Only Redis)

최종 요약

• 응답 시간

• 실패률

• 요청 수

AWS 핵심 정리

IAM이란?

• AWS 리소스 접근 제어를 위한 서비스
• 사용자(User), 그룹(Group), 역할(Role), 정책(Policy)을 통해 접근 권한을 관리함

IAM 주요 기능

1. 인증(Authentication): 사용자 로그인 확인 (아이디/비밀번호, MFA 등)
2. 권한 부여(Authorization): 정책(Policy)을 통해 리소스 접근 권한 부여
3. 권한 검증: 요청이 해당 사용자에게 허용된 것인지 검사

정책(Policy) 구성 요소

• Version: 정책 언어 버전
• Statement: 하나 이상의 접근 제어 규칙
  • Effect: Allow / Deny
  • Action: 수행할 수 있는 작업 (예: s3:ListBucket)
  • Resource: 리소스 ARN

Best Practices

• 최소 권한 원칙(Least Privilege) 적용
• 루트 사용자 사용 금지, MFA 활성화
• 역할 기반 접근 제어(RBAC), 태그 기반 제어도 가능

EC2 (Elastic Compute Cloud)

• 가상 서버를 제공하는 서비스
• 인스턴스 타입, AMI, 보안 그룹, 키 페어 설정 필요
• 상태: Stopped, Running 등
• 탄력적 IP(Elastic IP)로 고정 주소 사용 가능

S3 (Simple Storage Service)

• 객체(파일) 저장을 위한 스토리지 서비스
• 버킷 단위로 파일 관리
• 퍼블릭 접근 제어, 버전 관리, 정적 웹 호스팅 가능
• 각 객체는 고유한 URL로 접근 가능

Controller

@PostMapping(value = "/upload", consumes = MediaType.MULTIPART_FORM_DATA_VALUE)
    public ResponseEntity<String> uploadFile(
        @AuthenticationPrincipal AuthUser authUser,
        @RequestParam("file") MultipartFile file
    ) {
        Long userId = authUser.getId();
        String imageUrl = s3Service.updateFile(file, "profile/" + userId, userId); // S3에 업로드 후 URL 반환
        return ResponseEntity.ok(imageUrl);
    }

Service

private final AmazonS3 amazonS3;
    private final UserRepository userRepository;

    @Value("${cloud.aws.s3.bucket}")
    private String bucket; // S3 버킷 이름 (application.yml에서 설정)


    public String updateFile(MultipartFile multipartFile, String dirName, Long userId) {
        // 고유한 파일명을 생성 (디렉토리/UUID_원본파일명)
        String fileName = dirName + "/" + UUID.randomUUID() + "_" + multipartFile.getOriginalFilename();

        // S3 객체 메타데이터 설정
        ObjectMetadata metadata = new ObjectMetadata();
        metadata.setContentLength(multipartFile.getSize());
        metadata.setContentType(multipartFile.getContentType());
        metadata.setContentDisposition("inline");


        try (InputStream inputStream = multipartFile.getInputStream()) {
            // 파일을 S3에 업로드
            amazonS3.putObject(new PutObjectRequest(bucket, fileName, inputStream, metadata));
        } catch (IOException e) {
            throw new RuntimeException("S3 업로드에 실패하였습니다.", e);
        }

        // 기존 유저 이미지가 있다면 삭제
        userRepository.findById(userId).ifPresent(user -> {
            String oldUrl = user.getProfileImage();
            if (oldUrl != null && oldUrl.contains(bucket)) {
                // 이전 이미지 key 추출 후 삭제
                String oldKey = oldUrl.substring(oldUrl.indexOf(bucket) + bucket.length() + 1);
                amazonS3.deleteObject(bucket, oldKey);
            }

            // 새 이미지 URL 설정 및 저장
            String newUrl = amazonS3.getUrl(bucket, fileName).toString();
            user.setProfileImage(newUrl);
            userRepository.save(user);
        });

        // 새 이미지의 S3 URL 반환
        return amazonS3.getUrl(bucket, fileName).toString();
    }

config

@Value("${cloud.aws.credentials.access-key}")
    private String accessKey;

    @Value("${cloud.aws.credentials.secret-key}")
    private String secretKey;

    @Value("${cloud.aws.region.static}")
    private String region;

    // AmazonS3 클라이언트 Bean 등록
    @Bean
    public AmazonS3 amazonS3() {
        // 자격 증명 객체 생성
        BasicAWSCredentials awsCredentials = new BasicAWSCredentials(accessKey, secretKey);

        // S3 클라이언트 빌더를 통해 리전 및 인증 정보 설정
        return AmazonS3ClientBuilder.standard()
            .withRegion(region)
            .withCredentials(new AWSStaticCredentialsProvider(awsCredentials))
            .build();
    }

RDS (Relational Database Service)

• MySQL, PostgreSQL, MariaDB, Oracle, SQL Server 등 관계형 데이터베이스 관리형 서비스
• Multi-AZ 배포 가능 (고가용성)
• 자동 백업, 모니터링, 보안 그룹 적용 가능
• DB 인스턴스와 엔드포인트 개념 존재

문제 요약

주어진 조건을 만족하는 네 양의 정수 (a, b, c, d) 쌍의 개수가 정확히 59개가 되는 가장 작은 자연수 m과 가장 큰 자연수 M을 찾고, 그 합 M + m을 구하는 문제.

조건:

(a^(1/b)) * (c^(1/d)) = 24^(1/5)

수학적 접근

해당 문제는 수치 비교에서 실수 오차가 발생할 수 있기 때문에, 정확한 수 비교를 위해 로그를 이용한 비교로 전환했다.

변형 수식:

log(a^(1/b)) + log(c^(1/d)) = log(24^(1/5))
⇒ (1/b) * log(a) + (1/d) * log(c) = log(24)/5

이 식을 기반으로 실수 비교를 수행함.

구현 전략

1. k의 범위를 2부터 200까지 순차적으로 증가시키며 검사
2. a, b, c, d를 각각 [2, k], [1, k] 범위로 완전 탐색
3. 위 수식의 좌변이 log(24)/5와의 차가 epsilon보다 작을 경우 조건 만족으로 판단
4. 조건을 만족하는 쌍을 Set<String>에 저장해 중복 제거
5. count == 59일 때의 최소 k와 최대 k를 저장
6. 최종적으로 M + m 출력

핵심 코드

for (int k = 2; k <= 200; k++) {
    Set<String> seen = new HashSet<>();
    int count = 0;

    for (int a = 2; a <= k; a++) {
        for (int b = 1; b <= k; b++) {
            for (int c = 2; c <= k; c++) {
                for (int d = 1; d <= k; d++) {
                    double lhs = Math.log(a) / b + Math.log(c) / d;
                    if (Math.abs(lhs - target) < epsilon) {
                        seen.add(a + "," + b + "," + c + "," + d);
                        count++;
                    }
                }
            }
        }
    }

    if (count == 59) {
        if (minK == 0) minK = k;
        maxK = k;
    }
}

주요 고려 사항

• 부동소수점 오차 방지: Math.abs(lhs - target) < epsilon 조건 활용
• 중복 제거: (a,b,c,d) 쌍을 문자열로 구성하여 Set에 저장
• 정수 범위 제한: a, c는 2 이상부터 시작 (1이면 의미 없는 조합이 되므로)

결과

정확히 k = 72와 k = 80에서 59개의 조합이 존재함을 확인했고, 최종 결과는:

M + m = 152

배운 점

• 로그를 통한 수식 비교는 실수 오차 처리에 매우 유용하다
• 완전 탐색 알고리즘은 조건을 명확히 이해하고 효율적으로 구성하면 계산 가능한 수준에서 문제를 해결할 수 있다
• 수학적 사고력과 구현력이 결합되면 교과서 수준 문제도 코드로 정복 가능하다

AWS 클라우드

AWS는 Amazon Web Services의 약어로, 아마존닷컴이 제공하는 클라우드 컴퓨팅 플랫폼입니다. AWS는 전 세계에 분산되어 있는 데이터 센터에서 고객에게 IT 인프라를 제공하며, 이를 사용하여 고객은 필요한 인프라를 빠르고 쉽게 설정하고 관리할 수 있습니다.

Amazon: 책방에서 IT업계의 공룡기업!

1. 회원가입

https://aws.amazon.com/ko/

으로 접속 후 계정 생성 진행

비자, 마스터 카드등 필요

2. IAM 핵심

01. IAM 개요

• IAM (Identity and Access Management): AWS 리소스에 대한 인증(Authentication) 과 권한 부여(Authorization) 를 담당하는 서비스.

주요 기능:

1. 인증 (Authentication): 사용자 이름/비밀번호를 통해 로그인.
2. 권한 부여 (Authorization): 정책을 기반으로 각 사용자/역할/그룹에 필요한 권한만 부여.
3. 권한 검증: 요청 시 정책을 기반으로 허용/거부 판단.

   보안 강화 + 최소 권한 원칙 적용 + 규정 준수 지원

02. IAM 구성 요소

03. IAM 정책 구조

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow", // 또는 "Deny"
      "Action": ["s3:ListBucket"], // 수행 가능한 작업
      "Resource": ["arn:aws:s3:::my-bucket/*"], // 대상 리소스
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "192.168.0.1/32"
        }
      }
    }
  ]
}

• Effect: 허용(Allow) 또는 거부(Deny)
• Action: 수행할 수 있는 작업 (예: s3:GetObject)
• Resource: 적용 대상 리소스 ARN
• Condition: 특정 조건에서만 정책 적용 (선택)

04. MFA (다중 인증)

• MFA (Multi-Factor Authentication): 비밀번호 외에 추가 인증 수단(앱, 하드웨어 토큰 등)을 요구하여 보안을 강화.

• MFA 적용 대상:

  • 루트 사용자: 무조건 설정 필수
  • IAM 사용자: 가능하면 모두 설정

계정 정보가 유출되어도 MFA가 없다면 로그인 불가 → 보안 강화 필수!

• 서버가 사용자에게 인증 완료 증명서를 발급해주는 디지털 쪽지

어떻게 생겨먹었나?

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJ1c2VySWQiOiIxMjMiLCJyb2xlIjoiUk9MRV9VU0VSIn0.
1234567890abcdef

디코딩 한다면

{"alg":"HS256","typ":"JWT"}{"userId":"123","role":"ROLE_USER"}5~9=Ѧu

1. Header: 어떤 암호화 알고리즘을 썼는가? ex. HS256
2. Payload: 사용자 정보
3. signature: 위 정보를 변조 못하게 서명한 것

JWT 흐름

1. 로그인 요청
2. 서버가 이메일/비밀번호 확인
3. 성공하면 JWT 발급
4. 클라이언트는 발급 받은 토큰을 Authorization: Bearer {token}으로 사용
5. 서버는 매 요청마다 JWT를 해석해서 사용자 인증 처리

Step. 1 - 로그인 컨트롤러와 레파지토리

@RestController
@RequiredArgsConstructor
@RequestMapping("/auth")
public class AuthController {

    private final AuthService authService;

    @PostMapping("/login")
    public ResponseEntity<TokenResponse> login(@RequestBody LoginRequest request) {
        return ResponseEntity.ok(authService.login(request));
    }
}

• 로그인 API가 있어야 토큰을 발급받겠죠?
• 이미 많이 만들어 보셨을 테니 자세한 설명은 패스

public record LoginRequest(String email, String password) {

}

public record TokenResponse(String accessToken, String refreshToken) {

}

• 레파지토리는 아무 내용도 없어도 됩니다!

Step. 2 - JWT 생성 클래스( JwtTokenProvider )

@Component // Spring Bean으로 등록해 다른 컴포넌트에서 주입 받을 수 있게 해줌
public class JwtTokenProvider {

    // jwt.secret 값을 주입받음 -> 사용자가 아무 값이나 지정해주면 됨(한 20자리 정도?)
    // ex. jwtsecretjwtsecretjwtsecretjwtsecretjwtsecretjwtsecretjwtsecretjwtsecret
    @Value("${jwt.secret}") 
    private String secret;

    // 엑세스 토큰 유효기간 설정 ms단위임!
    private final long accessTokenValidity = 1000L * 60 * 60; // 1시간

    // 리프레쉬 토큰 유효기간 설정 역시 ms단위임!
    private final long refreshTokenValidity = 1000L * 60 * 60 * 24 * 7; // 7일

    // 사용자 ID와 역할을 바탕으로 액세스 토큰을 생성 -> 최대한 적은 정보가 들어가는게 좋음
    public String createAccessToken(Long userId, String role) {
        return createToken(userId, role, accessTokenValidity);
    }

    // ID와 역할을 바탕으로 뭐? 리프레쉬 토큰을 만들어 준다~
    public String createRefreshToken(Long userId, String role) {
        return createToken(userId, role, refreshTokenValidity);
    }

    // 공통 로직 -> 토큰 생성 claims(정보) 설정, 발급 시간/ 만료 시간 지정, 서명
    private String createToken(Long userId, String role, long validity) {
        Claims claims = Jwts.claims().setSubject(String.valueOf(userId)); // subject에 userId 설정
        claims.put("role", role); //claims에 룰 추가

        Date now = new Date(); // 지금 시간
        Date expiry = new Date(now.getTime() + validity); // 만료 시간 계산

        // JWT 빌더를 이용해서 토큰 생성해줌
        return Jwts.builder()
                .setClaims(claims) // 위에 열심히 적은 정보들
                .setIssuedAt(now) // 발급 시간
                .setExpiration(expiry) // 만료 시간
                .signWith(SignatureAlgorithm.HS256, secret.getBytes()) // 서명 알고리즘 + secretkey 지정
                .compact(); // 최종적으로 토큰 생성
    }

    // 토큰에서 사용자 ID(subject) 추출
    public Long getUserId(String token) {
        return Long.valueOf(parseClaims(token).getSubject());
    }

    // 토큰에서 룰 추출
    public String getRole(String token) {
        return parseClaims(token).get("role", String.class);
    }

    // 토큰이 유효한지 검사 -> 성공하면 혁며..아니고 ture, 실패하면 false
    public boolean validateToken(String token) {
        try {
            parseClaims(token); // 내부적으로 예외 던짐
            return true;
        } catch (Exception e) {
            return false;
        }
    }

    // 토큰을 파싱해서 Claims 객체 반환 (위에 적은 jwt.secret 이용해서 검증)
    private Claims parseClaims(String token) {
        return Jwts.parserBuilder()
                .setSigningKey(secret.getBytes()) // 서명 키
                .build()
                .parseClaimsJws(token) //JWT 파싱
                .getBody(); // Claims 반환
    }
}

• 자세한 설명은 주석으로 대신했습니다.

Step. 3 JWT 발급 - 만든거 줘야겠지?

@Service
@RequiredArgsConstructor
public class AuthService {

    private final UserRepository userRepository;
    private final JwtTokenProvider jwtTokenProvider;

    public TokenResponse login(LoginRequest request) {
        User user = userRepository.findByEmail(request.email())
            .orElseThrow(() -> new RuntimeException("유저 없음"));

        if (!user.getPassword().equals(request.password())) {
            throw new RuntimeException("비밀번호 틀림");
        }

        // 엑세스 토큰 생성
        String accessToken = jwtTokenProvider.createAccessToken(user.getId(), user.getRole().name());

        // 리프레쉬 토큰 생성
        String refreshToken = jwtTokenProvider.createRefreshToken(user.getId(), user.getRole().name());

        // 토큰 두개 담아서 반환
        return new TokenResponse(accessToken, refreshToken);
    }
}

• Service에서 가장 중요한건 열심히 만든 토큰을 똑바로 주는것!

Step. 4 인증 필터 (Spring Security)

@Configuration // 이 클래스가 Spring의 설정 클래스임을 알려줌
@EnableWebSecurity // Spring Security 기능을 활성화
@RequiredArgsConstructor 
public class SecurityConfig {

    private final JwtTokenProvider jwtTokenProvider; // JWT 관련 로직을 처리할 Provider 주입

    @Bean // SecurityFilterChain을 Bean으로 등록
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .csrf(csrf -> csrf.disable()) // CSRF 보호 비활성화 (JWT 기반 인증 할꺼니까?)
            .sessionManagement(session -> session.sessionCreationPolicy(SessionCreationPolicy.STATELESS)) // 세션을 사용하지 않도록 설정 (역시 JWT 인증 이니까)
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/auth/**").permitAll() // /auth/** 경로는 인증 없이 접근 허용
                .anyRequest().authenticated() // 그 외의 모든 요청은 인증 필요
            )
            .addFilterBefore(new JwtAuthFilter(jwtTokenProvider), UsernamePasswordAuthenticationFilter.class); // JWT 인증 필터를 Spring Security 필터 체인 앞단에 추가

        return http.build(); // 최종 SecurityFilterChain 객체 생성 및 반환
    }
}

Step. 5 Filter

// 매 요청마다 실행됨
public class JwtAuthFilter extends OncePerRequestFilter {

    private final JwtTokenProvider jwtTokenProvider;

    public JwtAuthFilter(JwtTokenProvider jwtTokenProvider) {
        this.jwtTokenProvider = jwtTokenProvider;
    }

    // 실제 필터 동작을 정의함
    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain)
            throws ServletException, IOException {

        String token = resolveToken(request); // Authorization 헤더에서 토큰 추출

        // 토큰이 존재하고 유효하면 인증 처리
        if (token != null && jwtTokenProvider.validateToken(token)) {
            Long userId = jwtTokenProvider.getUserId(token); // 토큰에서 userId 추출
            String role = jwtTokenProvider.getRole(token); // 토큰에서 role 추출

            // 인증 객체 생성: principal에 커스텀 AuthUser, credentials는 null, 권한 목록 설정
            UsernamePasswordAuthenticationToken authentication = new UsernamePasswordAuthenticationToken(
                new AuthUser(userId, role),
                null,
                List.of(new SimpleGrantedAuthority(role))
            );

            // 인증 객체를 현재 SecurityContext에 설정 → 컨트롤러에서 @AuthenticationPrincipal 등으로 접근 가능
            SecurityContextHolder.getContext().setAuthentication(authentication);
        }

        // 다음 필터로 요청 전달 -체인 계속 진행
        chain.doFilter(request, response);
    }

    // Authorization 헤더에서 Bearer 토큰 파싱
    private String resolveToken(HttpServletRequest request) {
        String bearer = request.getHeader("Authorization");
        return (bearer != null && bearer.startsWith("Bearer ")) ? bearer.substring(7) : null;
    }
}

• 여기까지가 발급에 필요한 기본 포맷입니다~

그 다음은 어떤게 있냐고요?

1. 리프레쉬 토큰을 저장 -> 로그아웃, 재발급 대비
2. 로그아웃 시 블랙리스트 처리
3. PasswordEncoder 적용 등이 있죠!

조건

• 매니저 등록 요청을 기록하는 로그 테이블을 만들어주세요.
  • DB 테이블명: log
• 매니저 등록과는 별개로 로그 테이블에는 항상 요청 로그가 남아야 해요.
  • 매니저 등록은 실패할 수 있지만, 로그는 반드시 저장되어야 합니다.
  • 로그 생성 시간은 반드시 필요합니다.
  • 그 외 로그에 들어가는 내용은 원하는 정보를 자유롭게 넣어주세요.

구현 전략

1. Log 엔티티 & Repository 생성
2. 로그 저장용 서비스 생성
3. @Transactional(propagation = Propagation.REQUIRES_NEW) 사용
4. 매니저 등록을 수행 하는 서비스에서 로그 저장 호출

1. Log 엔티티 설계

@Entity
@Setter
@Table(name = "log")
public class Log {

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

    private String action;

    private String details;

    private LocalDateTime createdAt;

    @PrePersist
    public void prePersist() {
        this.createdAt = LocalDateTime.now();
    }
}

2. Repository 설계

public interface LogRepository extends JpaRepository<Log, Long> {
}

3. Service 설계

@Service
public class LogService {

    private final LogRepository logRepository;

    public LogService(LogRepository logRepository) {
        this.logRepository = logRepository;
    }

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void saveLog(String action, String details) {
        Log log = new Log();
        log.setAction(action);
        log.setDetails(details);
        logRepository.save(log);
    }
}

4. 매니저 등록 서비스에 try-finally문 추가

        try{
            // 일정을 만든 유저
            User user = User.fromAuthUser(authUser);
            Todo todo = todoRepository.findById(todoId)
                .orElseThrow(() -> new InvalidRequestException("Todo not found"));

            if (todo.getUser() == null || !ObjectUtils.nullSafeEquals(user.getId(), todo.getUser().getId())) {
                throw new InvalidRequestException("담당자를 등록하려고 하는 유저가 유효하지 않거나, 일정을 만든 유저가 아닙니다.");
            }

            User managerUser = userRepository.findById(managerSaveRequest.getManagerUserId())
                .orElseThrow(() -> new InvalidRequestException("등록하려고 하는 담당자 유저가 존재하지 않습니다."));

            if (ObjectUtils.nullSafeEquals(user.getId(), managerUser.getId())) {
                throw new InvalidRequestException("일정 작성자는 본인을 담당자로 등록할 수 없습니다.");
            }

            Manager newManagerUser = new Manager(managerUser, todo);
            Manager savedManagerUser = managerRepository.save(newManagerUser);

            return new ManagerSaveResponse(
                savedManagerUser.getId(),
                new UserResponse(managerUser.getId(), managerUser.getEmail())
            );
        } catch (Exception e) {
            throw e;
        } finally {
            logService.saveLog(
                "매니저 요청", "userId: " + authUser.getId() + ", todoId: " + todoId + ", managerUserId: " + managerSaveRequest.getManagerUserId()
            );
        }

조건

• 검색 조건은 다음과 같아요.
  • 검색 키워드로 일정의 제목을 검색할 수 있어요.
    • 제목은 부분적으로 일치해도 검색이 가능해요.
  • 일정의 생성일 범위로 검색할 수 있어요.
    • 일정을 생성일 최신순으로 정렬해주세요.
  • 담당자의 닉네임으로도 검색이 가능해요.
    • 닉네임은 부분적으로 일치해도 검색이 가능해요.
• 다음의 내용을 포함해서 검색 결과를 반환해주세요.
  • 일정에 대한 모든 정보가 아닌, 제목만 넣어주세요.
  • 해당 일정의 담당자 수를 넣어주세요.
  • 해당 일정의 총 댓글 개수를 넣어주세요.
• 검색 결과는 페이징 처리되어 반환되도록 합니다.

1. 컨트롤러 작성

    // 키워드, 날짜, 닉네임으로 필터링된 할일 목록을 페이징 처리하여 조회
    @GetMapping("/todos/searchFilters")
    public ResponseEntity<Page<TodoSummaryResponse>> searchTodosWithFilters(
        @RequestParam(required = false) String keyword, // 제목 검색 키워드
        @RequestParam(required = false) @DateTimeFormat(iso = DateTimeFormat.ISO.DATE)LocalDate startDate, // 시작 날짜
        @RequestParam(required = false) @DateTimeFormat(iso = DateTimeFormat.ISO.DATE)LocalDate endDate, // 종료 날짜
        @RequestParam(required = false) String nickname, // 닉네임
        @PageableDefault(size = 10, sort = "createdAt", direction = Sort.Direction.DESC) Pageable pageable //페이징 정보
    ) {
        Page<TodoSummaryResponse> result = todoService.searchTodosWithFilters(keyword, nickname, startDate, endDate, pageable);
        return ResponseEntity.ok(result);
    }

• required = false 사용하여 빈값도 받음

2. 응답 DTO 작성

public record TodoSummaryResponse (

    String title,
    Long managerCount,
    Long commentCount
) {
    // QueryDSL의 Projection 기반 생성자
    @QueryProjection
    public TodoSummaryResponse(String title, Long managerCount, Long commentCount) {
        this.title = title;
        this.managerCount = managerCount;
        this.commentCount = commentCount;
    }
}

3. Repository 작성

// 인터페이스
Page<TodoSummaryResponse> searchTodosWithFilters(String keyword, String nickname, LocalDate startDate, LocalDate endDate, Pageable pageable);

// 구현체
    @Override
    public Page<TodoSummaryResponse> searchTodosWithFilters(String keyword, String nickname, LocalDate startDate,
        LocalDate endDate, Pageable pageable) {
        // Q 클래스 선언
        QTodo todo = QTodo.todo;
        QUser user = QUser.user;
        QManager manager = QManager.manager;
        QComment comment = QComment.comment;

        // 실제 데이터 리스트 조회
        List<TodoSummaryResponse> content = queryFactory
            .select(Projections.constructor(
                TodoSummaryResponse.class, //DTO를 생성자 기반으로 맵핑
                todo.title,
                manager.countDistinct(), // 관리자 수
                comment.count() // 댓글 수
            ))
            .from(todo)
            .leftJoin(todo.managers, manager)
            .leftJoin(manager.user, user)
            .leftJoin(todo.comments, comment)
            .where(
                titleContains(keyword), // 제목 필터
                nicknameContains(nickname), // 닉네임 필터
                createdBetween(startDate, endDate) // 날짜 필터
            )
            .groupBy(todo.id) // count를 쓰기위해 작성
            .orderBy(todo.createdAt.desc()) // 정렬 조건
            .offset(pageable.getOffset()) // 페이징 시작위치
            .limit(pageable.getPageSize()) // 페이징 한페이지 크기
            .fetch();

        // 전체갯수 조회 카운트용
        Long count = queryFactory
            .select(todo.countDistinct())
            .from(todo)
            .leftJoin(todo.managers, manager)
            .leftJoin(manager.user, user)
            .where(
                titleContains(keyword),
                nicknameContains(nickname),
                createdBetween(startDate, endDate)
            )
            .fetchOne();

        return new PageImpl<>(content, pageable, count);
    }

    private BooleanExpression titleContains(String keyword) {
        return StringUtils.hasText(keyword) ? QTodo.todo.title.contains(keyword) : null;
    }

    private BooleanExpression nicknameContains(String nickname) {
        return StringUtils.hasText(nickname) ? QManager.manager.user.nickname.contains(nickname) : null;
    }

    private BooleanExpression createdBetween(LocalDate start, LocalDate end) {
        if (start != null && end != null) {
            return QTodo.todo.createdAt.between(start.atStartOfDay(), end.plusDays(1).atStartOfDay());
        }
        return null;
    }

4. 서비스 작성

public Page<TodoSummaryResponse> searchTodosWithFilters(String keyword, String nickname, LocalDate startDate, LocalDate endDate, Pageable pageable) {
        return todoQueryRepository.searchTodosWithFilters(keyword, nickname, startDate, endDate, pageable);
    }

1. QueryDSL 장점

1. 타입 안전성

   • 컴파일 타임에 오류 잡아줌. 문자열로 쿼리 짜는 JPQL보다 안전함.

   • 오타, 컬럼 이름 틀림 -> 컴파일 에러로 바로 확인 가능.

2. IDE 자동완성

   • Q클래스를 기반으로 작성하니까 IDE가 필드 자동완성해줌.

   • 실수 줄고 개발 속도 상승

3. 가독성과 유지보수성

   • 복잡한 동적 쿼리도 자바 코드처럼 명확하게 표현 가능.

   • 조건문 분기 같은 것도 자연스럽게 if문으로 처리 가능.

4. 동적 쿼리 작성 쉬움

   • BooleanBuilder나 where 조건에 null 무시 기능으로 조건 선택적으로 붙이기 간단.

5. 쿼리 재활용 쉬움

   • 공통 조건들을 메서드로 빼서 재사용 가능.

2. QueryDSL 단점

1. 기본 세팅이 귀찮음

2. 러닝 커브 존재

3. 코드가 길어짐

3. 언제 QueryDSL를 쓰는게 좋을까?

1. 복잡한 검색/필터 조건이 많은 경우

   • 회원을 이름, 나이, 주소, 등록일 등으로 조합해서 검색해야 할 경우

   • if != null 조건이 여러 개 붙는 경우 -> JPQL 이나 Criteria으로 하려면 머리 터짐

2. 동적 쿼리가 자주 필요한 경우

   • 검색 조건이 optional인 경우 (검색창 입력 여부에 따라 필터 적용)

   • BooleanBuilder 또는 where(x, y, z) 구조로 처리 가능

3. 리포지토리 쿼리 재사용하고 싶은 경우

   • 쿼리 조건들을 메서드로 분리해서 공통화 가능 -> 유지보수, 테스트 쉬워짐

4. 프론트에서 정렬, 페이징 요청 자주 들어올 때

   • orderBy, offset, limit 등 DSL로 처리 가능

   • Pageable과 연동도 쉬움

5. 엔티티 간 join이 많은 경우

   • fetch join, left join 등 복잡한 join이 필요할 때 더 안전하게 처리 가능

4. 간단한 비교 예시

// JPQL
String jpql = "SELECT m FROM Member m WHERE m.age > :age";

// QueryDSL
QMember m = QMember.member;
List<Member> result = queryFactory
    .selectFrom(m)
    .where(m.age.gt(20))
    .fetch();

5. 결론!

• 복잡한 검색 조건이 많고, 동적 쿼리 많이 짜야 하면 무조건 쓰는 게 좋다.

개별 프로젝트

Lv. 2

1. Spring Security

Spring 기반 애플리케이션의 인증(Authentication)과 인가(Authorization)를 처리해주는 보안 프레임워크

핵심 기능

1. 인증(Authentication) 사용자가 누구인지 확인 (로그인 처리) ex) 아이디/비번으로 로그인, 소셜 로그인, JWT 토큰 검증 등
2. 인가(Authorization) 인증된 사용자가 어떤 리소스에 접근 가능한지 검사 ex) 관리자만 /admin, 점주만 /store/** 접근 가능
3. 보안 관련 필터 자동 적용 CSRF 방어, 세션 고정 방지, 비밀번호 암호화 등

기존 Filter와 Argument Resolver를 사용하던 코드들을 Spring Security로 변경

0. build.gradle에 의존성 추가

implementation 'org.springframework.boot:spring-boot-starter-security'

1. JwtUtil 클래스에 resolveToken() 및 validateToken() 메서드 추가

    public String resolveToken(HttpServletRequest request) {
        String bearer = request.getHeader("Authorization"); // 토큰값 헤더에서 가져오기
        if (StringUtils.hasText(bearer) && bearer.startsWith("bearer ")) { // 값이 있고, bearer 로 시작한다면
            return bearer.substring(7); // 앞의 "bearer "(7자리)를 때고 토큰값만 리턴 할것
        }
        return null;
    }

    public boolean validateToken(String token) {
        try {
            extractClaims(token); //토큰에서 클레임을 추출하여 유효성 검사
            return true; // 예외 없으면 유효한 토큰으로 판단
        } catch (Exception e) { 
            return false; // 예외 발생 시 유효하지 않은 토큰으로 판단
        }
    }

2. JwtAuthenticationFilter 클래스 설계 -> 기존의 Filter 대체

@Component
@RequiredArgsConstructor
public class JwtAuthenticationFilter extends OncePerRequestFilter {

    private final JwtUtil jwtUtil;

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

        String token = jwtUtil.resolveToken(request); // 요청 헤더에서 토큰값 추출

        if (token != null & jwtUtil.validateToken(token)) { // 토큰이 존재하고, 유효성 검증메서드를 통과 할 경우
            Claims claims = jwtUtil.extractClaims(token); //토큰에서 클레임(정보) 추출

            Long userId = Long.parseLong(claims.getSubject()); // 사용자 ID를 클레임에서 꺼냄
            String email = claims.get("email", String.class); // 사용자 email를 클레임에서 꺼냄
            String role = claims.get("userRole", String.class); // 사용자 role을 클레임에서 꺼냄
            String nickname = claims.get("nickname", String.class); //사용자 nickname을 클레임에서 꺼냄

            AuthUser authUser = new AuthUser(userId, email, UserRole.of(role), nickname);
            List<GrantedAuthority> authorities = List.of(new SimpleGrantedAuthority("ROLE_" + role)); // Spring Security에서 사용할 권한 정보 생성

            UsernamePasswordAuthenticationToken authenticationToken = new UsernamePasswordAuthenticationToken(authUser, null, authorities); // 인증 객체 생성 / 비밀번호는 null

            SecurityContextHolder.getContext().setAuthentication(authenticationToken); // SecurityContext에 인증 객체 저장
            System.out.println(role);
            System.out.println(authorities);
            System.out.println(authenticationToken);
        }
        filterChain.doFilter(request, response); // 다음 필터로 요청 전달
    }
}

3. SecurityConfig 설계

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .csrf(AbstractHttpConfigurer::disable) // CSRF(사이트 간 위조 요청) 보안 비활성화 - JWT 기반에서는 필요 없음
            .sessionManagement(session -> session // 세션을 사용하지 않음 - JWT 사용
                .sessionCreationPolicy(SessionCreationPolicy.STATELESS))
            .authorizeHttpRequests(auth -> auth // 요청별 인가 규칙
                .requestMatchers("/auth/**").permitAll() // /auth/** 경로는 누구나 접근 가능
                .requestMatchers("/admin/**").hasRole("ADMIN") // /admin/** 경로는 어드민 만 접근 가능
                .anyRequest().authenticated() // 그 외 모든 요청은 인증 필요
            )
            .addFilterBefore(jwtAuthenticationFilter, UsernamePasswordAuthenticationFilter.class) // JWT 인증 필터 등록 (기본 인증 필터 앞에 위치)
            .formLogin(AbstractHttpConfigurer::disable) // 기본 로그인 폼 사용 안함 - JWT 사용
            .httpBasic(AbstractHttpConfigurer::disable); // HTTP Basic 인증 사용 안 함 (ID/PW를 매 요청마다 보내는 방식)

        //최종 보안 설정을 적용한 SecurityFilterChain 반환
        return http.build();
    }

4. PasswordEncoderConfig 설개

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder;
import org.springframework.security.crypto.password.PasswordEncoder;

@Configuration
public class PasswordEncoderConfig {

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

여기서 문제 기존의 PasswordEncoder 커스텀 클래스의 처리

• 이름이 PasswordEncoder라서 Spring Security의 인터페이스랑 이름이 겹쳐서 충돌 남
• Spring Security 기반으로 전환 중 임으로, 커스텀 로직은 불필요
• BCryptPasswordEncoder는 Spring Security에서 안정적이고 표준적으로 제공

• 결론 지워 버리자

수정 했으니 해당 클레스를 사용하는 서비스의 import 수정 필요

1. auth.AuthService
2. user.UserService

   //삭제
   import org.example.expert.config.PasswordEncoder;

   //추가
   import org.springframework.security.crypto.password.PasswordEncoder;

5. 필요 없어진 java파일 정리

1. JwtFilter.java
   • 기존에 Filter 인터페이스 상속해서 토큰 처리하던 클래스

   • Spring Security의 JwtAuthenticationFilter로 대체됐으므로 삭제

2. FilterConfig.java
   • JwtFilter를 등록하던 FilterRegistrationBean 설정 클래스

   • SecurityFilterChain에서 관리하므로 필요 없음

3. AuthUserArgumentResolver.java
   • @Auth 어노테이션 + 커스텀 객체 AuthUser 주입 기능 제공

   • @AuthenticationPrincipal로 대체 가능

4. WebConfig.java
   • AuthUserArgumentResolver를 등록하던 설정 클래스 -> 위 클래스 제거하면 이 설정도 쓸모 없음
5. PasswordEncoder.java
   • BCrypt 직접 썼던 커스텀 인코더

   • PasswordEncoderConfig로 대체됨, 이름 충돌 및 중복 문제 있음

도전과제 최종 테스트와 문제

1. Not-null property references a transient value - transient instance must be saved before current operation -> Todo.user -> User

원인 : 컨트롤러 단에서 @Auth 사용함 -> JWT토큰으로 변경하며 AuthUserArgumentResolver 삭제 null 발생

해결: @Auth 에서 @AuthenticationPrincipal으로 변경

yml 기본 세팅

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/yourDb
    username: username
    password: password
    driver-class-name: com.mysql.cj.jdbc.Driver

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

server:
  port: 8080

jwt:
  secret:
    key: secretKey

properties 기본 세팅

spring.datasource.url=jdbc:mysql://localhost:3306/yourDb
spring.datasource.username=username
spring.datasource.password=password
spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver

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

server.port=8080

jwt.secret.key=secretKey

properties 코드블럭 문법 하이라이딩 하실 수 있는 분...?

개별 프로젝트

Lv. 0

0. 프로젝트 기본 설정

1. application.yml

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/${MYSQL_NAME}?useSSL=${SSL}&allowPublicKeyRetrieval=${ALLOWPUBLICKEYRETRIEVAL}
    username: ${MYSQL_USERNAME}
    password: ${MYSQL_PASSWORD}
    driver-class-name: com.mysql.cj.jdbc.Driver

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

server:
  port: 8080

jwt:
  secret:
    key: ${SECRET_KEY}

2. 환경변수파일(.env)

#MYSQL 설정
MYSQL_NAME=
SSL=false
ALLOWPUBLICKEYRETRIEVAL=true

MYSQL_USERNAME=root
MYSQL_PASSWORD=

#JWT
SECRET_KEY=

Lv. 1

1. 코드 개선 퀴즈 - @Transactional의 이해

    @PostMapping("/todos")
    public ResponseEntity<TodoSaveResponse> saveTodo(
            @Auth AuthUser authUser,
            @Valid @RequestBody TodoSaveRequest todoSaveRequest
    ) {
        return ResponseEntity.ok(todoService.saveTodo(authUser, todoSaveRequest));
    }

해당 API 호출 시 에러 발생

jakarta.servlet.ServletException: Request processing failed: org.springframework.orm.jpa.JpaSystemException: could not execute statement [Connection is read-only. Queries leading to data modification are not allowed] [insert into todos (contents,created_at,modified_at,title,user_id,weather) values (?,?,?,?,?,?)]

1. 에러 내용 DB 커넥션이 읽기 전용(read-only) 상태인데, 쓰기 작업 시도

2. 에러 예상 Service 클래스 전체가 @Transactional(readOnly = true)로 되어 있거나, saveTodo 메서드가 @Transactional(readOnly = true) 일 것으로 예상

3. 확인 결과 TodoService 클래스 전체에 @Transactional(readOnly = true) 걸려있음을 확인

4. 개선 방법 1 : 클래스에 걸려있는 readOnly = true 삭제 방법 2 : 클래스 설정보다 메서드 설정을 우선한다는 점에서 메서드 위에 @Transactional 명시 (기본값 : false)

2. 코드 추가 퀴즈 - JWT의 이해

토큰안에 nickname값 넣기

1. User Entity에 컬럼 추가 private String nickname;

2. Entity 내부 메서드 수정

   public User(String email, String password, UserRole userRole, String nickname) {
        this.email = email;
        this.password = password;
        this.userRole = userRole;
        this.nickname = nickname; // <- 추가
    }
   
    private User(Long id, String email, UserRole userRole, String nickname) {
        this.id = id;
        this.email = email;
        this.userRole = userRole;
        this.nickname = nickname; // <- 추가
    }
   
    public static User fromAuthUser(AuthUser authUser) {
        return new User(authUser.getId(), authUser.getEmail(), authUser.getUserRole(), authUser.getNickname()); // <- 추가
    }

3. 회원가입 Request에 nickname 추가

   @NotBlank 
   private String nickname; // <- 추가

4. domain.auth.service.AuthService 수정

   public SignupResponse signup(SignupRequest signupRequest) {
   
        if (userRepository.existsByEmail(signupRequest.getEmail())) {
            throw new InvalidRequestException("이미 존재하는 이메일입니다.");
        }
   
        String encodedPassword = passwordEncoder.encode(signupRequest.getPassword());
   
        UserRole userRole = UserRole.of(signupRequest.getUserRole());
   
        User newUser = new User(
                signupRequest.getEmail(),
                encodedPassword,
                userRole,
                signupRequest.getNickname() // <- 추가
        );
        User savedUser = userRepository.save(newUser);
   
        String bearerToken = jwtUtil.createToken(savedUser.getId(), savedUser.getEmail(), userRole, savedUser.getNickname()); // <- 추가
   
        return new SignupResponse(bearerToken);
    }
   
    public SigninResponse signin(SigninRequest signinRequest) {
        User user = userRepository.findByEmail(signinRequest.getEmail()).orElseThrow(
                () -> new InvalidRequestException("가입되지 않은 유저입니다."));
   
        // 로그인 시 이메일과 비밀번호가 일치하지 않을 경우 401을 반환합니다.
        if (!passwordEncoder.matches(signinRequest.getPassword(), user.getPassword())) {
            throw new AuthException("잘못된 비밀번호입니다.");
        }
   
        String bearerToken = jwtUtil.createToken(user.getId(), user.getEmail(), user.getUserRole(), user.getNickname()); // <- 추가
   
        return new SigninResponse(bearerToken);
    }

5. config.AuthUserArgumentResolver 수정

   // JwtFilter 에서 set 한 userId, email, userRole, nickname 값을 가져옴
        Long userId = (Long) request.getAttribute("userId");
        String email = (String) request.getAttribute("email");
        UserRole userRole = UserRole.of((String) request.getAttribute("userRole"));
        String nickname = (String) request.getAttribute("nickname"); // <- 추가
   
        return new AuthUser(userId, email, userRole, nickname); // <- 추가

6. JwtUtill 수정

   public String createToken(Long userId, String email, UserRole userRole, String nickname) {
        Date date = new Date();
   
        return BEARER_PREFIX +
                Jwts.builder()
                        .setSubject(String.valueOf(userId))
                        .claim("email", email)
                        .claim("userRole", userRole)
                        .claim("nickname", nickname) // <- 추가
                        .setExpiration(new Date(date.getTime() + TOKEN_TIME))
                        .setIssuedAt(date) // 발급일
                        .signWith(key, signatureAlgorithm) // 암호화 알고리즘
                        .compact();
    }

3. 코드 개선 퀴즈 - JPA의 이해

1. JPQL을 사용하여 목표 달성

    @Query("""
        SELECT t
        FROM Todo t LEFT JOIN FETCH t.user u
        WHERE (:weather IS NULL OR t.weather = :weather)
            AND (:start IS NULL OR t.modifiedAt >= :start)
            AND (:end IS NULL OR t.modifiedAt <= :end)
        ORDER BY t.modifiedAt DESC
    """)
    Page<Todo> searchTodos(
        Pageable pageable,
        @Param("weather") String weather,
        @Param("start") String start,
        @Param("end") String end
        );

   SELECT t
   FROM Todo t LEFT JOIN FETCH t.user u
   WHERE (:weather IS NULL OR t.weather = :weather)
   AND (:start IS NULL OR t.modifiedAt >= :start)
   AND (:end IS NULL OR t.modifiedAt <= :end)
   ORDER BY t.modifiedAt DESC

   1. 문제점

   fetch join과 page<Todo> 같이 쓸 수 있는가?

   • 참고자료: https://lsj31404.tistory.com/94

2. 이유

• fetch join은 JPA가 내부적으로 중복 row를 만듬
• @OneToMany, @ManyToOne 관계에서 fetch join을 쓰면 SQL 쿼리 상에서 중복된 row가 만들어짐
• 이럴 경우 JPA는 하나의 Todo를 복수 row로 인식해서 메모리에서 중복 제거를 시도

그 결과 Todo 여러 개가 리턴될 수 있음

2. 근본적 이유

• JPA가 페이징을 위해 count query를 자동 생성하는데, fetch join은 count 쿼리에 적합하지 않음
• fetch join은 row 수를 늘려버리기 때문에 정확한 페이징 깨짐

3. 요약 -> fetch join을 왜 쓰는가? : N+1문제를 해결하기 위해 N+1은 왜 생기는가? : 한개의 엔티티를 검색할때 여기에 연결된 엔티티가 여러개 라서!

4. 그래서 그게 왜 문제 인가? 위 그림과 같은 상황에서 각각 page처리를 하여 한 페이지에 3개 묶음 씩 해서 2페이지 보여주세요 라고 한다면? 일반 경우 게시글 4, 5, 6 을 출력 fetch join의 경우 게시글 1의 댓글 4, 5 와 게시글 2의 댓글 1 출력

2. 해결법

1. fetch join + List<T> -> 전체 조회에 적합, 페이징 X
2. fetch join + Page<T> + countQuery 직접 명시 -> 복잡하지만 안정적
3. Page<T> + 지연 로딩(LAZY) -> 일반적으로 사용

3. 코드작성

1. TodoRepository 작성

   @Query(value = """
        SELECT t
        FROM Todo t LEFT JOIN FETCH t.user u
        WHERE (:weather IS NULL OR t.weather = :weather)
            AND (:start IS NULL OR t.modifiedAt >= :start)
            AND (:end IS NULL OR t.modifiedAt <= :end)
        ORDER BY t.modifiedAt DESC
    """,
    countQuery = """
        SELECT COUNT(t)
        FROM Todo t
        WHERE (:weather IS NULL OR t.weather = :weather)
            AND (:start IS NULL OR t.modifiedAt >= :start)
            AND (:end IS NULL OR t.modifiedAt <= :end)
    """
    )
    Page<Todo> searchTodos(
        Pageable pageable,
        @Param("weather") String weather,
        @Param("start") LocalDateTime start,
        @Param("end") LocalDateTime end
        );

2. TodoService 작성

   public Page<TodoResponse> searchTodos(int page, int size, String weather, LocalDateTime start, LocalDateTime end) {
        Pageable pageable = PageRequest.of(page - 1, size);
   
        Page<Todo> todos = todoRepository.searchTodos(pageable, weather, start, end);
   
        return todos.map(todo -> new TodoResponse(
            todo.getId(),
            todo.getTitle(),
            todo.getContents(),
            todo.getWeather(),
            new UserResponse(todo.getUser().getId(), todo.getUser().getEmail()),
            todo.getCreatedAt(),
            todo.getModifiedAt()
        ));
    }

3. TodoController 작성

   @GetMapping("/todos/search")
    public ResponseEntity<Page<TodoResponse>> searchTodos(
        @RequestParam(defaultValue = "1") int page,
        @RequestParam(defaultValue = "10") int size,
        @RequestParam(required = false) String weather,
        @RequestParam(required = false) String start,
        @RequestParam(required = false) String end
    ) {
        LocalDateTime startDateTime = (start != null) ? LocalDateTime.parse(start) : null;
        LocalDateTime endDateTime = (end != null) ? LocalDateTime.parse(end) : null;
        return ResponseEntity.ok(todoService.searchTodos(page, size, weather, startDateTime, endDateTime));
    }

4. 테스트 코드 퀴즈 - 컨트롤러 테스트의 이해

todo_단건_조회_시_todo가_존재하지_않아_예외가_발생한다() 테스트가 성공적으로 작동할 수 있게 코드 수정

mockMvc.perform(get("/todos/{todoId}", todoId))
                .andExpect(status().isOk())
                .andExpect(jsonPath("$.status").value(HttpStatus.OK.name()))
                .andExpect(jsonPath("$.code").value(HttpStatus.OK.value()))
                .andExpect(jsonPath("$.message").value("Todo not found"));

• 예외 처리임에도 기대값을 OK로 설정

  mockMvc.perform(get("/todos/{todoId}", todoId))
                .andExpect(status().isBadRequest())
                .andExpect(jsonPath("$.status").value(HttpStatus.BAD_REQUEST.name()))
                .andExpect(jsonPath("$.code").value(HttpStatus.BAD_REQUEST.value()))
                .andExpect(jsonPath("$.message").value("Todo not found"));

• 기대값을 BAD_REQUEST로 수정

5. 코드 개선 퀴즈 - AOP의 이해

특정 클래스의 메소드가 실행 전 동작하게 수정 필요

1. 기존 코드

   @After("execution(* org.example.expert.domain.user.controller.UserController.getUser(..))")
    public void logAfterChangeUserRole(JoinPoint joinPoint) {
        String userId = String.valueOf(request.getAttribute("userId"));
        String requestUrl = request.getRequestURI();
        LocalDateTime requestTime = LocalDateTime.now();
   
        log.info("Admin Access Log - User ID: {}, Request Time: {}, Request URL: {}, Method: {}",
                userId, requestTime, requestUrl, joinPoint.getSignature().getName());
    }

2. 수정 코드

   @Before("execution(* org.example.expert.domain.user.controller.UserController.getUser(..))")
    public void logAfterChangeUserRole(JoinPoint joinPoint) {
        String userId = String.valueOf(request.getAttribute("userId"));
        String requestUrl = request.getRequestURI();
        LocalDateTime requestTime = LocalDateTime.now();
   
        log.info("Admin Access Log - User ID: {}, Request Time: {}, Request URL: {}, Method: {}",
                userId, requestTime, requestUrl, joinPoint.getSignature().getName());
    }

• 어노테이션 교체 @After -> @Before

Lv. 2

1. JPA - Cascade

• 할 일을 새로 저장할 시, 할 일을 생성한 유저는 담당자로 자동 등록

  기존 코드

  @OneToMany(mappedBy = "todo")
    private List<Manager> managers = new ArrayList<>();

  수정 코드

  @OneToMany(mappedBy = "todo", cascade = CascadeType.ALL, orphanRemoval = true)
    private List<Manager> managers = new ArrayList<>();

1. OneToMany: Todo 1개가 Manager 여러 개를 가질 수 있음.(1:N 관계)
2. mappedBy = "todo": 양방향 매핑 기준. Manager 쪽의 todo 필드가 주인
3. cascade = CascadeType.ALL: Todo 저장/삭제 시, 관련된 Manager도 자동으로 저장/삭제
4. orphanRemoval = true: Todo.managers 리스트에서 제거된 Manager는 DB에서도 삭제
   • todo.getManagers().remove(manager); 선언시 DB에서 삭제

2. N + 1

• 댓글 조회 시 N+1문제 발생

  Hibernate: 
    select
        c1_0.id,
        c1_0.contents,
        c1_0.created_at,
        c1_0.modified_at,
        c1_0.todo_id,
        c1_0.user_id 
    from
        comments c1_0 
    where
        c1_0.todo_id=?
  Hibernate: 
    select
        u1_0.id,
        u1_0.created_at,
        u1_0.email,
        u1_0.modified_at,
        u1_0.nickname,
        u1_0.password,
        u1_0.user_role 
    from
        users u1_0 
    where
        u1_0.id=?
  Hibernate: 
    select
        u1_0.id,
        u1_0.created_at,
        u1_0.email,
        u1_0.modified_at,
        u1_0.nickname,
        u1_0.password,
        u1_0.user_role 
    from
        users u1_0 
    where
        u1_0.id=?
  Hibernate: 
    select
        u1_0.id,
        u1_0.created_at,
        u1_0.email,
        u1_0.modified_at,
        u1_0.nickname,
        u1_0.password,
        u1_0.user_role 
    from
        users u1_0 
    where
        u1_0.id=?

• 게시글에 댓글을 단 ID를 한번씩 조회함.

1. CommentRepository 코드 수정 필요

@Query("SELECT c FROM Comment c JOIN c.user WHERE c.todo.id = :todoId")
    List<Comment> findByTodoIdWithUser(@Param("todoId") Long todoId);

• JOIN만 사용함을 확인 할 수 있음

• USER가 여전히 지연(LAZY) 로딩 대상

• JOIN FETCH으로 변경 하여 N + 1 문제 해결

  @Query("SELECT c FROM Comment c JOIN FETCH c.user WHERE c.todo.id = :todoId")
    List<Comment> findByTodoIdWithUser(@Param("todoId") Long todoId);

3. QueryDSL

QueryDSL 란?

QueryDSL은 Java 기반 ORM(Query DSL: Domain Specific Language) 중 하나로, 타입 안정성 있는 SQL-like 쿼리를 자바 코드로 작성할 수 있도록 도와주는 프레임워크

왜 쓰는가?

기존 JPQL이나 native query는 문자열 기반이라 컴파일 타임에 에러를 잡을 수 없지만, QueryDSL은 자바 코드로 쿼리를 작성함으로 오타나 잘못된 필드를 컴파일 타임에 체크 가능

사용 전 설정

1. build.gradle에 의존성 추가

   plugins {
    id 'java'
    id 'org.springframework.boot' version '3.3.3'
    id 'io.spring.dependency-management' version '1.1.6'
    id 'idea'
   }
   

group = 'org.example' version = '0.0.1-SNAPSHOT'

java { toolchain { languageVersion = JavaLanguageVersion.of(17) } }

def querydslDir = "$buildDir/generated/querydsl"

sourceSets { main { java { srcDirs += querydslDir } } }

idea { module { generatedSourceDirs += file(querydslDir) } }

configurations { compileOnly { extendsFrom annotationProcessor } }

repositories { mavenCentral() }

dependencies { // Spring Boot implementation 'org.springframework.boot:spring-boot-starter-web' implementation 'org.springframework.boot:spring-boot-starter-validation' implementation 'org.springframework.boot:spring-boot-starter-data-jpa' implementation 'org.springframework.boot:spring-boot-starter-security'

// QueryDSL
implementation 'com.querydsl:querydsl-jpa:5.0.0:jakarta'
annotationProcessor 'com.querydsl:querydsl-apt:5.0.0:jakarta'
annotationProcessor 'jakarta.persistence:jakarta.persistence-api:3.1.0'
annotationProcessor 'jakarta.annotation:jakarta.annotation-api:2.1.1'
implementation 'jakarta.persistence:jakarta.persistence-api:3.1.0'

// Lombok
compileOnly 'org.projectlombok:lombok'
annotationProcessor 'org.projectlombok:lombok'

// Database
runtimeOnly 'com.h2database:h2'
runtimeOnly 'com.mysql:mysql-connector-j'

// JWT
compileOnly 'io.jsonwebtoken:jjwt-api:0.11.5'
runtimeOnly 'io.jsonwebtoken:jjwt-impl:0.11.5'
runtimeOnly 'io.jsonwebtoken:jjwt-jackson:0.11.5'

// Test
testImplementation 'org.springframework.boot:spring-boot-starter-test'
testRuntimeOnly 'org.junit.platform:junit-platform-launcher'

}

tasks.named('test') { useJUnitPlatform() }

tasks.withType(JavaCompile) { options.annotationProcessorGeneratedSourcesDirectory = file(querydslDir) options.compilerArgs += "-XprintRounds" options.compilerArgs += "-XprintProcessorInfo" }

>- Gradle 이 설치 되어 있어야 한다. 만약 없다면
터미널에 아래 문구를 순차적으로 입력하여 설치 진행
1. Set-ExecutionPolicy RemoteSigned -Scope CurrentUser
2. irm get.scoop.sh | iex
3. scoop install gradle
4. gradle -v // 버전 체크
5. gradle wrapper // 실행

> - 설치를 완료 했다면 터미널에
./gradlew clean build // H2 등 DB 설정 필요 없으면 실패
./gradlew clean build -x test // 테스트 스킵 빌딩만 함

![](https://velog.velcdn.com/images/giwon_wg/post/bc51048b-be1b-42e5-96bf-bf6dce5f7582/image.png)
Qentity 가 생겼다면 성공!

#### QueryDslConfig 설계
```java
@Configuration
public class QueryDslConfig {

    @Bean
    public JPAQueryFactory jpaQueryFactory(EntityManager entityManager) {
        return new JPAQueryFactory(entityManager);
    }
}

변경 대상 - TodoRepository.findByIdWithUser

@Query("SELECT t FROM Todo t " +
            "LEFT JOIN t.user " +
            "WHERE t.id = :todoId")
    Optional<Todo> findByIdWithUser(@Param("todoId") Long todoId);

QueryDSL 변경 후

위 코드 -> 주석 처리

public interface TodoRepository extends JpaRepository<Todo, Long>, TodoQueryRepository {

• TodoQueryRepository -> 추가

public interface TodoQueryRepository {
    Optional<Todo> findByIdWithUser(Long todoId);
}

• 클래스 추가

@RequiredArgsConstructor
public class TodoQueryRepositoryImpl implements TodoQueryRepository {

    private final JPAQueryFactory queryFactory;

    @Override
    public Optional<Todo> findByIdWithUser(Long todoId) {
        QTodo todo = QTodo.todo;
        QUser user = QUser.user;

        return Optional.ofNullable(
            queryFactory
                .selectFrom(todo)
                .leftJoin(todo.user, user).fetchJoin()
                .where(todo.id.eq(todoId))
                .fetchOne()
        );
    }
}

• TodoQueryRepositoryImpl 클래스 추가

1. User Entity 작성

가장 먼저 회원 정보를 저장할 Usuer 엔티티를 만들어야 겠죠? 우리는 엔티티를 수 없이 만들어 보았으니, 금방 작성 하실거에요!

@Getter
@Setter
@NoArgsConstructor
@AllArgsConstructor
@Builder
@Entity
@Table(name = "users")
public class User {

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

    @Column(nullable = false, unique = true)
    private String email; // 구글로부터 받은 이메일

    @Column(nullable = false)
    private String password; // 소셜 로그인은 고정 패스워드 사용

    @Column(nullable = false)
    private String nickname; // 닉네임 (랜덤 생성)
}

2. Repository 작성

스탭 2! 이메일로 회원을 조회하거나 저장할 인터페이스 설계!

public interface UserRepository extends JpaRepository<User, Long> {
    Optional<User> findByEmail(String email); // 이메일로 회원 조회
}

3. Service 작성

이메일로 기존 회원을 찾고, 없으면? 자동가입을 시켜준다~

@Service
@RequiredArgsConstructor
public class UserServiceImpl {

    private final UserRepository userRepository;

    // 이메일로 회원을 찾고, 없으면 새로 가입시킴
    public User registerIfNeed(String email) {
        return userRepository.findByEmail(email)
                .orElseGet(() -> {
                    User newUser = User.builder()
                            .email(email)
                            .password("SOCIAL_LOGIN") // 고정 패스워드
                            .nickname("구글유저_" + UUID.randomUUID().toString().substring(0, 8))
                            .build();
                    return userRepository.save(newUser);
                });
    }
}

4. Controller 작성

로그인 성공 시 이탈할 Controller도 작성합니다.

@Controller
@RequiredArgsConstructor
public class LoginSuccessController {

    private final UserServiceImpl userService;

    @GetMapping("/login/success")
    public String oauthSuccess(@AuthenticationPrincipal OAuth2User oAuth2User) {
        // 1. 구글 로그인 완료 후 사용자 정보 가져오기
        String email = oAuth2User.getAttribute("email");

        // 2. 이메일로 회원가입 or 로그인 처리
        User user = userService.registerIfNeed(email);

        // 3. 로그인 성공 후 리다이렉트 (프론트 화면 경로)
        return "redirect:/welcome.html"; // 원하는 경로로 변경 가능
    }
}

5. SecurityConfig 작성

Config 설정은 어려울 수 있어요! 차근차근 진행 해 보자구요?

@Configuration
public class SecurityConfig {

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http
            .csrf().disable()
            .authorizeHttpRequests(authorize -> authorize
                .requestMatchers("/", "/login/**").permitAll()
                .anyRequest().authenticated()
            )
            .oauth2Login(oauth2 -> oauth2
                .defaultSuccessUrl("/login/success") // 로그인 성공 시 이동할 URL
            );

        return http.build();
    }
}

6. application.properties 작성

이제 코드 작성은 끝! properties에 아래 내용을 붙여 넣어주세요!

spring.security.oauth2.client.registration.google.client-id=YOUR_GOOGLE_CLIENT_ID
spring.security.oauth2.client.registration.google.client-secret=YOUR_GOOGLE_CLIENT_SECRET
spring.security.oauth2.client.registration.google.scope=email,profile

spring.security.oauth2.client.provider.google.authorization-uri=https://accounts.google.com/o/oauth2/v2/auth
spring.security.oauth2.client.provider.google.token-uri=https://oauth2.googleapis.com/token
spring.security.oauth2.client.provider.google.user-info-uri=https://www.googleapis.com/oauth2/v2/userinfo

YOUR_GOOGLE_CLIENT_ID와 YOUR_GOOGLE_CLIENT_SECRET이 뭐냐구요?
그렇군요. 여기 까지 온 당신! 이제 인터넷을 켜세요!

7. Google Oauth 설정

이제 구글 서버에 우리 서비스를 등록해서, 인증기능을 사용하기 위한 설정을 진행합니다!

1. 구글 클라우드 접속 → https://console.cloud.google.com/

2. 좌 상단의

프로젝트 선택 클릭

3. 우측의 새 프로젝트 클릭

4. 프로젝트 이름 입력 후 만들기

5. 2번 프로젝트 선텍 클릭 후 만든 프로젝트로 진입

6. 좌 상단의 햄버거 버튼 클릭 → API 및 서비스 -> OAuth 클릭

7. 시작 하기

8. 앱 이름, 이메일 작성 후 다음

9. 대상 외부

10. 나머지 정보 작성 후 만들기

11. 클라이언트 → 클라이언트 만들기

12. 내용 작성합니다!

    
    

13. 만든 클라이언트 클릭!

14. 클라이언트 ID와 보안 비밀번호 복사

15. application.properties에 ID와 비밀번호 작성

• 클라이언트 ID

  spring.security.oauth2.client.registration.google.client-id=YOUR_GOOGLE_CLIENT_ID

• 보안 비밀번호

  spring.security.oauth2.client.registration.google.client-secret=YOUR_GOOGLE_CLIENT_SECRET

2. 위치기반 API - Kakao MAP 무작정 따라하기!

위치 정보를 가져오기 위해 외부 API(카카오맵 API)를 사용합니다.

1. RestTemplate 설정

외부 API 서버(카카오)에 요청을 보내기 위한 기본 설정!

@Configuration
public class RestTemplateConfig {

    @Bean
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}

2. KakaoAddressClient 작성

카카오맵 서버에 좌표(x, y)를 보내고, 주소를 받아오는 역할이에요

@Component
@RequiredArgsConstructor
public class KakaoAddressClient {

    private final RestTemplate restTemplate;

    @Value("${kakao.rest-api-key}")
    private String kakaoApiKey;

    // 좌표(x, y)를 받아 주소를 요청하는 메서드
    public String getAddress(double longitude, double latitude) {
        String url = "https://dapi.kakao.com/v2/local/geo/coord2address.json?x=" + longitude + "&y=" + latitude;

        HttpHeaders headers = new HttpHeaders();
        headers.set("Authorization", "KakaoAK " + kakaoApiKey);

        HttpEntity<Void> request = new HttpEntity<>(headers);

        ResponseEntity<String> response = restTemplate.exchange(
                url,
                HttpMethod.GET,
                request,
                String.class
        );

        return response.getBody(); // 그대로 JSON String 리턴
    }
}

3. RegionService 작성

KakaoAddressClient를 이용해 비즈니스 로직을 처리합니다.

@Service
@RequiredArgsConstructor
public class RegionService {

    private final KakaoAddressClient kakaoAddressClient;

    // 위도, 경도를 받아서 주소 문자열을 반환하는 메서드
    public String getAddress(double longitude, double latitude) {
        return kakaoAddressClient.getAddress(longitude, latitude);
    }
}

4. RegionController 작성

API 엔드포인트를 만들어, 프론트 요청을 받습니다.

@RestController
@RequiredArgsConstructor
@RequestMapping("/api/region")
public class RegionController {

    private final RegionService regionService;

    @GetMapping("/address")
    public ResponseEntity<String> getAddress(@RequestParam double longitude, @RequestParam double latitude) {
        // ex) /api/region/address?longitude=126.9780&latitude=37.5665
        String address = regionService.getAddress(longitude, latitude);
        return ResponseEntity.ok(address);
    }
}

5. application.properties 작성

카카오 REST API 키를 등록합니다.

# 카카오 REST API 키 입력
kakao.rest-api-key=YOUR_KAKAO_REST_API_KEY

6. 카카오 REST API 키 발급 방법

카카오맵 API를 사용하려면 키를 발급받아야 합니다.

[진행 순서]

1. 카카오 개발자 사이트 접속 → https://developers.kakao.com/

2. 로그인 후, 상단 시작하기 클릭!

3. "애플리케이션 추가하기" 클릭

4. 내용을 작성하고, 저장!

5. 좌측 메뉴 → 플랫폼 → 웹(Web) 등록 (http://localhost:8080)

   주의: 플랫폼(Web) 등록을 안 하면 CORS 오류나 인증 오류가 발생할 수 있습니다.

6. 좌측 메뉴 → 카카오맵 → 활성화 ON

7. "앱 키" 탭에서 "REST API 키" 복사

8. application.properties에 복사한 키 붙여넣기

여기까지 왔다면...

축하합니다!

여러분은 혼자서도 소셜로그인와 위치기반 API를 사용 할 수 있게 되었습니다!!

오늘 배운 것 개요

• RefreshToken Redis 저장 실패 이슈 원인 분석 및 해결
• @RequestBody 바인딩 실패 원인 분석
• Redis 키 문자열 공백 문제 해결
• 정확한 Redis 직렬화 설정 방법 학습

1. RefreshToken Redis 저장 실패 트러블슈팅

1. 문제 상황

• 로그인 시 RefreshToken을 Redis에 저장하고, 이후 이를 통해 AccessToken을 재발급받는 구조를 설계함.
• /reissue API 호출 시 다음과 같은 예외 발생:

java.lang.IllegalArgumentException: RefreshToken이 비여 있거나, null입니다.

2. 원인 분석

1) Redis 저장 여부 확인

127.0.0.1:6379> keys *
1) "RefreshToken"
2) "BlackList"
3) "testKey"
127.0.0.1:6379> get RT:1
(nil)

• 예상했던 RT:1 키가 존재하지 않거나 null로 조회됨.
• LoginService 내부 확인 결과, Redis 저장 로직이 빠져 있었음.

2) 저장 로직 추가 후에도 이상한 직렬화 결과 발생

1) "\xac\xed\x00\x05t\x00\x04RT:1"

• 이는 Java 기본 직렬화 방식으로 저장된 결과. 사람이 읽을 수 없음.

3. 해결 방법

Redis 직렬화 설정 추가

StringRedisSerializer stringSerializer = new StringRedisSerializer();
template.setKeySerializer(stringSerializer);
template.setValueSerializer(stringSerializer);
template.setHashKeySerializer(stringSerializer);
template.setHashValueSerializer(stringSerializer);
template.afterPropertiesSet();

정상 저장 확인

127.0.0.1:6379> keys *
1) "RT:1"
2) "BlackList"
3) "RefreshToken"
127.0.0.1:6379> get RT:1
"eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxI..."

2. RefreshToken 재발급 과정에서 바인딩 실패

1. 문제 상황

• Redis에는 잘 저장되었지만, /reissue 요청 시 다음 예외 발생:

java.lang.IllegalArgumentException: RefreshToken이 비여 있거나, null입니다.

2. 원인 분석

• TokenRefreshRequest DTO가 다음과 같이 구성되어 있었음:

  @Getter
  @NoArgsConstructor
  public class TokenRefreshRequest {
    private String refreshToken;
  }

• 하지만 바인딩이 실패하여 값이 null로 전달됨.

3. 해결 방법

@Getter
@NoArgsConstructor
public class TokenRefreshRequest {

    @JsonProperty("refreshToken")
    private String refreshToken;
}

• @JsonProperty를 명시하여 JSON 필드와 정확하게 매핑되도록 수정함.

3. Redis 키 비교 오류

1. 문제 상황

• 다음과 같은 예외 발생:

java.lang.IllegalArgumentException: 서버에 저장된 RefreshToken 과 다릅니다.

2. 원인 분석

String storedToken = redisTemplate.opsForValue().get("RT: " + userId);

• Redis에는 "RT:1"로 저장되어 있었고, 코드에는 "RT: 1"처럼 공백이 포함된 상태로 조회하고 있었음.

3. 해결 방법

redisTemplate.opsForValue().get("RT:" + userId);

• 공백 제거하여 일치하도록 수정

오늘의 결론

1. Redis 직렬화 설정은 기본이지만 놓치기 쉬운 핵심 포인트다.
2. @JsonProperty는 DTO 매핑에서 중요한 역할을 하며, 필드명이 일치해도 명시해주는 게 안전하다.
3. Redis 키 문자열 비교는 공백 여부까지도 정확하게 신경 써야 한다.

Java를 Spring처럼 - [번외편]DTO 하나로 처리하는 CLI 기반 CRUD 실습

이번 편에서는 우리가 CLI 환경에서 구현한 CRUD 흐름을 스프링스럽게 리팩토링해보면서, URI 기반 요청 처리와 DTO 통합 설계를 직접 해보았습니다.
특히 PostRequest라는 하나의 DTO로 Create와 Update 요청을 동시에 처리하는 전략을 적용해봤어요. 저는 귀찮아서 하나로 작성했지만 Create 와 Update를 나누는게 더 재미 있겠죠?

직관적인 CRUD 설계 Step. 1 - Entity

Entity 부터 설계 해 볼까요??

package Entity;

/**
 *  Entity 구현 부 Class명은 Post!
 */
public class Post {
    private Long id;
    private String title;
    private String content;
    private String author;

    public Post() {
    }

    public Post(String title, String content, String author) {
        this.title = title;
        this.content = content;
        this.author = author;
    }

    // Getter 와 Setter
    public Long getId() {
        return id;
    }
    public void setId(Long id) {
        this.id = id;
    }

    public String getTitle() {
        return title;
    }
    public void setTitle(String title) {
        this.title = title;
    }

    public String getContent() {
        return content;
    }
    public void setContent(String content) {
        this.content = content;
    }

    public String getAuthor() {
        return author;
    }
    public void setAuthor(String author) {
        this.author = author;
    }
}

뭐가 이렇게 기냐고요?? 왜냐면 저희는 뉴비이기 때문에 Lombok을 안쓰고 한땀한땀 Getter / Setter를 작성했어요!

직관적인 CRUD 설계 Step. 2 - Repository

Repository 인터페이스

package Repository;

import java.util.List;
import java.util.Optional;

import Entity.Post;

public interface PostRepository {
    //C
    Post save(Post post);

    //R
    Optional<Post> findById(Long id);
    List<Post> findAll();

    //U - id 기반 검색
    void update(Long id, Post post);

    //D - id 기반 검색
    void delete(Long id);
}

Repository 구현체

package Repository;

import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.Optional;

import Entity.Post;

public class PostRepositoryImpl implements PostRepository {

    private final Map<Long, Post> store = new HashMap<>();
    private Long sequence = 0L;

    @Override
    public Post save(Post post) {
        // 글이 작성될때 id에 +1
        post.setId(++sequence);
        store.put(post.getId(), post);
        return post;
    }

    @Override
    public Optional<Post> findById(Long id) {
        return Optional.ofNullable(store.get(id));
    }

    @Override
    public List<Post> findAll() {
        return new ArrayList<>(store.values());
    }

    @Override
    public void update(Long id, Post updatePost) {
        Post post = store.get(id);
        if(post != null) {
            post.setTitle(updatePost.getTitle());
            post.setContent(updatePost.getContent());
        }
    }

    @Override
    public void delete(Long id) {
        store.remove(id);
    }
}

Repository는 인터페이스와 구현체로 나뉩니다! 선언은 인터페이스, 구현은 구현체

직관적인 CRUD 설계 Step. 3 - Service

Service(비즈니스 로직)

public class PostService {
    private final PostRepository repository = new PostRepository();

    public Post createPost(String title, String content, String author) {
        Post post = new Post();
        post.setTitle(title);
        post.setContent(content);
        post.setAuthor(author);
        return repository.save(post);
    }

    public List<Post> getAllPosts() {
        return repository.findAll();
    }

    public Optional<Post> getPostById(Long id) {
        return repository.findById(id);
    }

    public void updatePost(Long id, String newTitle, String newContent) {
        Post update = new Post();
        update.setTitle(newTitle);
        update.setContent(newContent);
        repository.update(id, update);
    }

    public void deletePost(Long id) {
        repository.delete(id);
    }
}

직관적인 CRUD 설계 Step. 4 - Controller

package controller;

import java.util.List;
import java.util.Optional;

import Entity.Post;
import Service.PostService;
import dto.PostRequestDto;

public class PostController {
    private final PostService postService;

    public PostController(PostService postService) {
        this.postService = postService;
    }

    public Post creat(PostRequestDto requestDto) {
        return postService.createPost(requestDto.getTitle(), requestDto.getContent(), requestDto.getAuthor());
    }

    public List<Post> getAll() {
        return postService.getAllPosts();
    }

    public Optional<Post> getPostById(Long id) {
        return postService.getPostById(id);
    }

    public void update(Long id, PostRequestDto requestDto) {
        postService.updatePost(id, requestDto.getTitle(), requestDto.getContent());
    }

    public void delete(Long id) {
        postService.deletePost(id);
    }
}

직관적인 CRUD 설계 Step. 5 - main

import java.util.Scanner;

import Entity.Post;
import Repository.PostRepository;
import Repository.PostRepositoryImpl;
import Service.PostService;
import controller.PostController;
import dto.PostRequestDto;

public class PostClient {
    /**
     * 제목 내용 저자 스캐너 활용
     * URI와 유사한 기능 적용
     * @param args
     */
    public static void main(String[] args) {

        //의존성 주입
        PostRepository postRepository = new PostRepositoryImpl();
        PostService postService = new PostService(postRepository);
        PostController postController = new PostController(postService);
        Scanner scanner = new Scanner(System.in);

        while (true) {
            System.out.println("\nURI > :");
            String URI = scanner.nextLine().trim();

            switch (URI) {
                case "/posts/create":
                    String title = scanner.nextLine();
                    String content = scanner.nextLine();
                    String author = scanner.nextLine();

                    PostRequestDto requestDto = new PostRequestDto(title, content, author);
                    Post post = postController.creat(requestDto);
                    break;

                case "/posts":
                    postController.getAll().forEach(p -> System.out.println("Id: " + p.getId() + ", Title: " + p.getTitle() + ", content: " + p.getContent() + ", author: " + p.getAuthor()));
                    break;

                case "exit":
                    return;

                default:
                    //동적 매칭 구현
                    if (URI.matches("/posts/\\d+")) {
                        Long id = Long.parseLong(URI.split("/")[2]);
                        postController.getPostById(id).ifPresent(p -> System.out.println("Id: " + p.getId() + ", Title: " + p.getTitle() + ", content: " + p.getContent() + ", author: " + p.getAuthor()));
                    } else if (URI.matches("/posts/\\d+/update")) {
                        Long id = Long.parseLong(URI.split("/")[2]);
                        String newTitle = scanner.nextLine();
                        String newContent = scanner.nextLine();
                        PostRequestDto updateRequestDto = new PostRequestDto(newTitle, newContent, null);
                        postController.update(id, updateRequestDto);
                    } else if (URI.matches("/posts/\\d+/delete")) {
                        Long id = Long.parseLong(URI.split("/")[2]);
                        postController.delete(id);
                    } else {
                        System.out.println("URI 확인 필요");
                    }
            }
        }
    }
}

💡 우리의 목표는?

Admin API 접근 시 인터셉터에서 인증, AOP에서 로깅 처리

목표 시나리오

• /admin/** 경로에 접근 할때:
  1. 인터셉터가 JWT 토큰을 검사하고, ADMIN 관한이 아니면 거부
  2. AOP가 요청 및 응답 내용을 로깅

Step 1. Interceptor - 인증 처리

1. AdminInterceptor.java

@Component
public class AdminInterceptor implements HandlerInterceptor {


    private final JwtProvider jwtProvider;

    // 생성자 주입 방식으로 JwtProvider 의존성 주입!
    public AdminInterceptor(JwtProvider jwtProvider) {
        this.jwtProvider = jwtProvider; 
    }

    // 컨트롤러 실행 전 요청을 가로채는 메서드(인터셉트!)
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)
        throws Exception {

        // 요청에서 토큰 추출
        String token = jwtProvider.resolveToken(request);

        // 토큰이 없거나 유효하지 않으면 401 Unauthorized 응답
        if (token == null || !jwtProvider.validateToken(token)) {
            response.setStatus(HttpStatus.UNAUTHORIZED.value()); // 인증 실패
            return false; // 컨트롤러로 진입하지 않음
        }

        // 토큰에서 역할 정보 추출
        String role = jwtProvider.getRole(token);

        // 역할이 ADMIN이 아니면 403 Forbidden
        if (!"ADMIN".equals(role)) {
            response.setStatus(HttpStatus.FORBIDDEN.value()); // 인가 실패
            return false;
        }

        // 모든 조건을 통과하면 true 반환 → 컨트롤러 실행 허용
        return true;
    }
}

2. WebConfig.java

@Configuration
public class WebConfig implements WebMvcConfigurer {

    private final AdminInterceptor adminInterceptor;

    public WebConfig(AdminInterceptor adminInterceptor) {
        this.adminInterceptor = adminInterceptor;
    }

    @Override
    public void addInterceptors(InterceptorRegistry registry) {

        // "/admin/**" 경로에 대해서만 adminInterceptor를 적용
        registry.addInterceptor(adminInterceptor)
                .addPathPatterns("/admin/**");
    }
}

Step 2. AOP - 요청/응답 로깅

1. AdminLoggingAspect.java

@Aspect // AOP 클래스임을 나타냄
@Component
@Slf4j // 로그 출력용 롬복 어노테이션 (log.info 사용 가능)
public class AdminLoggingAspect {

    // Pointcut 설정: admin 하위 패키지의 모든 메서드에 적용
    @Pointcut("execution(* com.example.controller.admin..*(..))")
    public void adminMethods() {}

    // 어드민 메서드 실행 전후로 로그를 남김
    @Around("adminMethods()")
    public Object logAdminRequest(ProceedingJoinPoint joinPoint) throws Throwable {

        // 현재 요청 객체 가져오기 (RequestContextHolder는 AOP 내에서 HttpServletRequest 접근 가능하게 함)
        HttpServletRequest request = ((ServletRequestAttributes) RequestContextHolder.getRequestAttributes()).getRequest();

        // URI 정보 및 요청자 ID 추출
        String uri = request.getRequestURI();
        String userId = request.getHeader("userId"); // 예: 헤더에서 userId 가져오기

        // 요청 로그 출력 (args는 메서드 파라미터 배열)
        log.info("어드민 요청 - userId: {}, URI: {}, request: {}", userId, uri, Arrays.toString(joinPoint.getArgs()));

        // 원래의 컨트롤러 메서드 실행
        Object result = joinPoint.proceed();

        // 응답 로그 출력
        log.info("어드민 응답 - userId: {}, URI: {}, response: {}", userId, uri, result);

        return result;
    }
}

Step 3. 테스트용 Admin Controller

1. UserAdminController.java

@RestController
@RequestMapping("/admin/users")
public class UserAdminController {

    // 어드민 권한이 있어야만 접근 가능한 API
    @PatchMapping("/{userId}")
    public ResponseEntity<String> changeUserRole(@PathVariable Long userId, @RequestBody RoleUpdateRequest request) {

        return ResponseEntity.ok("변경 완료");
    }
}

마무리

[요청] → Interceptor (인증 확인)
               ↓
     통과하면 AOP 진입 (로깅)
               ↓
     컨트롤러 실행 (ex. changeUserRole)
               ↓
     AOP 종료 로그
               ↓
[응답 반환]

1. 도입 - "객체는 누가 만들어야 할까?"

2편에서는 인터페이스를 통해 다양한 구현체를 갈아끼우며 유연한 구조를 만들었죠. 그런데 이런 질문이 생깁니다.

UserService userService = new UserService(new EmailService());
→ 이걸 누가 만들고 주입할까?

하드코딩 대신, 객체 생성을 한 곳에서 관리할 수는 없을까요?

2. 의존성 주입(Dependency Injection)의 개념

의존성 주입은 말 그대로 필요한 객체를 외부에서 주입해주는 방식입니다.

생성자 주입

public class UserService {
    private final NotificationService notificationService;

    // 생성자 주입
    public UserService(NotificationService notificationService) {
        this.notificationService = notificationService;
    }
}

필드 주입

public class UserService {
    @Autowired
    private NotificationService notificationService;
}

세터 주입

public class UserService {
    private NotificationService notificationService;

    @Autowired
    public void setNotificationService(NotificationService notificationService) {
        this.notificationService = notificationService;
    }
}

생성자 주입은 불변성과 테스트 편의성 측면에서 가장 권장됩니다.

3. IoC란 무엇인가?

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

• 기존: 객체를 직접 생성하고 사용하는 구조
• IoC: 객체 생성/관리 주체를 개발자가 아닌 외부로 전환

코드 비교

IoC 적용 전

UserService userService = new UserService(new EmailNotificationService());

IoC 적용 후

AppConfig config = new AppConfig();
UserService userService = config.userService();

객체 생성을 외부에 맡기면서, 구현체를 바꾸고 테스트하기 쉬워집니다.

4. 자바로 IoC 컨테이너 흉내내기

직접 객체를 조립하는 설정 클래스 만들기

public class AppConfig {

    public UserService userService() {
        return new UserService(notificationService());
    }

    public NotificationService notificationService() {
        return new EmailNotificationService();
    }
}

사용 예

public class Main {
    public static void main(String[] args) {
        AppConfig config = new AppConfig();
        UserService userService = config.userService();
        userService.process();
    }
}

이 구조 자체가 스프링의 IoC 컨테이너를 흉내낸 것입니다! AppConfig가 모든 객체를 만들고 연결해주죠.

📌 예를 들어 테스트 환경에서 FakeNotificationService를 만들어 AppConfig에서 주입하면 쉽게 테스트가 가능합니다.
또는 Slack 연동 구현체를 교체하더라도 AppConfig의 return 값만 바꾸면 UserService 코드는 수정할 필요가 없습니다.

5. DI 방식 비교

스프링은 생성자 주입을 가장 권장합니다.

6. 왜 이렇게까지 해야 하나요?

다음과 같은 실무 경험이 있습니다:

실무 프로젝트에서 처음에는 이메일만 지원하던 알림 서비스에 카카오 알림톡과 슬랙 연동이 추가되었습니다.
기존 코드가 new로 직접 구현체를 생성하고 있어 확장 시 많은 수정이 필요했고, 테스트 코드도 함께 깨졌습니다.
이후 DI 구조로 바꾼 뒤에는 NotificationService 인터페이스 기반으로 주입만 바꿔서 Slack, Kakao 구현체를 적용할 수 있었고,
테스트도 FakeNotificationService를 주입하는 방식으로 간단하게 처리할 수 있었습니다.

DI는 단순한 설계 원칙이 아니라, 협업과 유지보수에 큰 차이를 만들어냅니다.

7. 스프링에서는 어떻게 처리할까?

@Configuration
public class AppConfig {

    @Bean
    public NotificationService notificationService() {
        return new EmailNotificationService();
    }

    @Bean
    public UserService userService() {
        return new UserService(notificationService());
    }
}

그리고 실행 시 아래처럼 ApplicationContext로부터 객체를 받아옵니다:

ApplicationContext context = new AnnotationConfigApplicationContext(AppConfig.class);
UserService userService = context.getBean(UserService.class);

스프링이 객체를 생성하고 의존성을 주입해줍니다. 우리는 그저 "필요한 걸 꺼내 쓰면" 됩니다.

8. 실무에서는 어떻게 사용되나?

@Service
public class EmailNotificationService implements NotificationService { ... }

@RequiredArgsConstructor
@RestController
public class UserController {

    private final NotificationService notificationService;

    @PostMapping("/notify")
    public void send() {
        notificationService.send("API 호출됨");
    }
}

• @Component, @Service, @Repository 등으로 등록된 빈은
• @Autowired 또는 @RequiredArgsConstructor를 통해 주입됩니다.

또한 실무에서는 다음과 같은 기술도 자주 사용됩니다:

• @Qualifier("emailService") → 여러 구현체 중 특정 이름을 지정
• @Primary → 기본 구현체 지정
• @Profile("test") → 환경에 따라 다른 빈 등록

이러한 방법들은 인터페이스 기반 설계를 더욱 유연하게 만들어줍니다.

9. 오늘의 정리

오늘 배운 것 개요

• 내용: AOP 기반 어드민 API 접근 로깅 구현 방법 학습
• 내용: @Around 어노테이션을 활용한 요청/응답 시점 로그 처리
• 내용: joinPoint.getArgs()를 활용한 RequestBody 추출과 로깅 방법 확인

1. AOP 기반 어드민 접근 로깅

1. @AdminLogging 어노테이션

• 어드민 API 접근 시 AOP 적용 대상을 명시하기 위해 사용
• @Retention(RetentionPolicy.RUNTIME), @Target(ElementType.METHOD)으로 설정

2. AdminLogginAspect 클래스 구조

• @Aspect, @Component로 정의
• @Around("@annotation(...AdminLogging)")을 통해 AOP 진입
• HttpServletRequest에서 사용자 정보(userId)와 요청 URI 추출
• joinPoint.getArgs()를 통해 요청 파라미터(JSON 직렬화) 추출
• joinPoint.proceed() 이후 응답 또는 예외를 처리

코드 개선

@Around("@annotation(org.example.expert.logging.AdminLogging)")
public Object logAdminAccess(ProceedingJoinPoint joinPoint) throws Throwable {
    Long userId = (Long) request.getAttribute("userId");
    String uri = request.getRequestURI();
    LocalDateTime time = LocalDateTime.now();
    String requestBody = objectMapper.writeValueAsString(joinPoint.getArgs());

    log.info("어드민 요청 - userId: {}, URI: {}, time: {}, request: {}", userId, uri, time, requestBody);

    Object result = null;
    try {
        result = joinPoint.proceed();
        return result;
    } catch (Throwable e) {
        log.warn("어드민 응답 실패 - userId: {}, URI: {}, error: {}", userId, uri, e.getMessage());
        throw e;
    } finally {
        if (result != null) {
            String responseJson = objectMapper.writeValueAsString(result);
            log.info("어드민 응답 - userId: {}, URI: {}, response: {}", userId, uri, responseJson);
        } else {
            log.info("어드민 응답 - userId: {}, URI: {}, response: 예외 발생 또는 반환값 없음");
        }
    }
}

개선된 점

• 요청 파라미터를 통째로 JSON 직렬화하여 request에 기록
• 응답 또는 예외 발생 여부에 따라 finally에서 로깅 분기 처리
• 테스트에서도 요청과 응답 로그를 CapturedOutput으로 검증 가능

오늘의 결론

1. @Around는 메서드 실행 전후를 포괄적으로 제어할 수 있는 강력한 도구
2. joinPoint.getArgs()는 RequestBody와 PathVariable 모두 확인 가능
3. 예외가 발생해도 finally 블록을 활용해 응답 로그를 일관되게 남길 수 있다