여러가지 이야기

[Spring] Lock 동시성 해결 중 트랜잭션의 관리, Transaction 원리

jimddong — Wed, 11 Feb 2026 01:52:43 +0900

2026.01.23 - [study/Spring] - 객체 중복 생성 방지를 위한 Redis 분산 Lock 도입

객체 중복 생성 방지를 위한 Redis 분산 Lock 도입

최근 진행 중인 프로젝트에서, AI를 활용하여 사용자가 원하는 주제의 요약글과 퀴즈를 생성하는 기능을 개발하는 역할을 맡았다.사용자는 원하는 목표 기간 동안 최대 하루 한 번씩 생성된 요

9oongoguma.tistory.com

문제 발생

이전 글에서 하루에 최대 하나만 생성되어야 할 요약글 객체가, 해당 생성 API가 여러 번 호출되며 중복되는 문제가 있었다. 이에 따라 Lock 로직을 도입하였다.

// DistributedLockFacade.java
public <T> Optional<T> tryExecuteWithLock(String lockKey, long waitTime, long leaseTime, TimeUnit timeUnit, Supplier<T> action) {
    RLock lock = redissonClient.getLock(lockKey);
    try {
        // 락 획득 시도
        if (!lock.tryLock(waitTime, leaseTime, timeUnit)) {
            log.warn("Failed to acquire lock: {}", lockKey);
            return Optional.empty();
        }
        try {
            return Optional.ofNullable(action.get());
        } finally {
            // 락 해제
            if (lock.isLocked() && lock.isHeldByCurrentThread()) {
                lock.unlock();
            }
        }
    } catch (InterruptedException e) {
        // 예외 처리
        Thread.currentThread().interrupt();
        throw new BaseException(CommonResponseCode.INTERNAL_SERVER_ERROR);
    }
}

요약글뿐만 아니라 퀴즈 세트도 사용자에게 하루에 최대 하나 생성되어야하므로, 퀴즈에도 Redis 분산 Lock을 도입하려 했다. 하지만 코드를 수정하여 실제 운영 서버에 반영하고, 서버 로그를 확인해보니 다음과 같은 에러가 발생했다.

2026-01-19T19:57:04.478+09:00  WARN 1 --- [Project1] [nio-8080-exec-9] i.s.t.g.component.DistributedLockFacade  : Failed to acquire lock: lock:category_document:generation:1526:2026-01-19
2026-01-19T19:57:04.482+09:00 ERROR 1 --- [Project1] [nio-8080-exec-9] i.s.t.g.e.GlobalExceptionHandler         : BaseException: 
.
.
.
im.project1.global.exception.BaseException: 서버 처리 중 오류가 발생했습니다. 잠시 후 다시 시도해주세요.
	at im.project1.global.component.DistributedLockFacade.executeWithLock(DistributedLockFacade.java:38) ~[!/:0.0.1-SNAPSHOT]
	at im.project1.domains.categoryDocument.application.usecase.CategoryDocumentUseCase.createNewDailyDocument(CategoryDocumentUseCase.java:153) ~[!/:0.0.1-SNAPSHOT]
.
.
.
2026-01-19T19:58:42.361+09:00 ERROR 1 --- [Project1] [nio-8080-exec-6] i.s.t.g.e.GlobalExceptionHandler         : Exception: 

org.springframework.transaction.UnexpectedRollbackException: Transaction silently rolled back because it has been marked as rollback-only
	at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:804) ~[spring-tx-6.2.14.jar!/:6.2.14]
	at

하나만 생겨야할 요약글이 중복 저장되고, Lock이 제대로 지켜지지 않는 것이다.

왜 이런 문제가 발생했을까?

해결 과정

참고로 현재 프로젝트에서는 GitHub Flow에 따라 개발 브랜치의 작업을 운영 브랜치에 머지하면, 배포 서버에 반영되어 즉각적으로 수정 사항을 볼 수 있다. 즉 QA용 서버가 존재하지 않는데, 이미 해당 프로젝트에서 앱을 배포하여 운영 중이었기에 무턱대고 코드를 수정하여 바로 바로 운영 서버에 반영하기에는 앱 이용자에게도 에러가 즉각적으로 감지될 수 있는 위험이 있었다.

코드를 수정하여도 로컬에서 API를 동시에 여러 번 호출하여 생기는 동시성 문제를 Postman이나 Swagger로 확인하기에는 무리가 있기에, 따라서 로컬에서도 동시성 문제를 테스트해볼 수 있는 스크립트를 작성하여 테스팅을 진행했다.

아래 스크립트는 요약글 요청 후 퀴즈를 요청하는 내용이며, 동시에 여러 번 요청이 들어 왔을 때 Lock이 잘 처리되는지 보기 위해서 요약글→퀴즈 flow를 여러 번(CONCURRENT_REQUESTS만큼) 반복하게 된다.

스크립트: concurrency_test.sh

#!/bin/bash

# 명령행 인자에 JWT access token, categoryId 포함
JWT_TOKEN=$1
CATEGORY_ID=$2

CONCURRENT_REQUESTS=5 # Lock이 걸리는 API를 거의 동시에 똑같이 5번 호출 

if [ -z "$JWT_TOKEN" ] || [ -z "$CATEGORY_ID" ]; then
  echo "Usage: $0 <JWT_TOKEN> <CATEGORY_ID>"
  exit 1
fi

URL_DOC="http://localhost:8080/api/v1/categories/$CATEGORY_ID/documents/daily" # 요약글 생성(이미 존재 시 조회) 요청
URL_QUIZ_BASE="http://localhost:8080/api/v1/user-quizzes"

echo "  Starting $CONCURRENT_REQUESTS concurrent user flows (Doc -> Quizzes)..."
echo "Target: Category ID $CATEGORY_ID"

run_flow() {
  local id=$1
  
  # 1. Request: GET api/v1/categories/{categoryId}/documents/daily
  RESPONSE=$(curl -s -w "\n%{http_code}" -X GET "$URL_DOC" \
    -H "Authorization: Bearer $JWT_TOKEN" \
    -H "Content-Type: application/json")

  HTTP_CODE=$(echo "$RESPONSE" | tail -n1)
  BODY=$(echo "$RESPONSE" | sed '$d')

  echo "User $id Step 1 (Doc): HTTP $HTTP_CODE"

  if [ "$HTTP_CODE" -eq 200 ]; then
      # Document ID로 JSON parsing
      # Structure: { "data": { "documentId": 123, ... } }
      DOC_ID=$(echo "$BODY" | python3 -c "import sys, json; print(json.load(sys.stdin)['data']['documentId'])" 2>/dev/null)
      
      if [ -n "$DOC_ID" ]; then
          # 2. Request: 퀴즈 요청
          QUIZ_URL="$URL_QUIZ_BASE?documentId=$DOC_ID&documentType=CATEGORY"
          QUIZ_RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" -X GET "$QUIZ_URL" \
            -H "Authorization: Bearer $JWT_TOKEN" \
            -H "Content-Type: application/json")
          echo "User $id Step 2 (Quiz): HTTP $QUIZ_RESPONSE (DocId: $DOC_ID)"
      else
          echo "User $id Step 2 (Quiz): SKIPPED (No Doc ID)"
      fi
  else
      echo "User $id Step 2 (Quiz): SKIPPED (Doc Failed)"
  fi
}

# Export (함수 및 변수)
export -f run_flow
export JWT_TOKEN CATEGORY_ID URL_DOC URL_QUIZ_BASE

# Run requests
for i in $(seq 1 $CONCURRENT_REQUESTS); do
  run_flow $i &
done

# 작업 끝
wait
echo "✅ All flows completed."

시도 1) tryLock(waitTime, leaseTime, timeUnit)의 waitTime 늘리기

우선 지식(요약글+퀴즈) 생성 과정에서 lock의 점유가 풀리지 않았을 경우를 고려해보았다. 참고로 지식은, 요약글이 생겨야 해당 내용을 바탕으로 퀴즈 세트 내용이 구성되어 생성되는 로직이다. 즉 다음과 같다.

1️⃣ 요약글(CategoryDocument 또는 DocumentSummary) 생성 위해 Lock 점유 → 생성 완료 시 Unlock
2️⃣ 퀴즈 생성 위해 Lock 점유 → 생성 완료 시 Unlock

여기서 나는 '1️⃣ → 2️⃣ 사이 간극이 너무 짧아서, 아직 앞선 점유 1️⃣이 Unlock 하지도 않았는데 2️⃣가 Lock을 시도해서 그런 것 아닐까?'하는 의문을 가졌다. 이에 따라 tryLock 메서드 내 파라미터에서의 waitTime, 즉 Wait Time을 증가(기존 3초 → 변경 뒤 30초) 시켰다. 즉, 요약글과 퀴즈 생성 로직의 락 대기 시간을 넉넉하게 늘려, 앞선 요청이 끝날 때까지 기다렸다가 결과를 받아갈 수 있게 한 것이다.

그러나 여전히 에러가 발생했다.

로컬에서 실행한 스크립트 에러 결과

  Starting 10 concurrent user flows (Doc -> Quizzes)...
Target: Category ID 104
User 8 Step 1 (Doc): HTTP 200
User 8 Step 2 (Quiz): SKIPPED (No Doc ID)
User 3 Step 1 (Doc): HTTP 500
User 3 Step 2 (Quiz): SKIPPED (Doc Failed)
User 1 Step 1 (Doc): HTTP 500
User 1 Step 2 (Quiz): SKIPPED (Doc Failed)
User 5 Step 1 (Doc): HTTP 500
User 5 Step 2 (Quiz): SKIPPED (Doc Failed)
User 7 Step 1 (Doc): HTTP 500
User 7 Step 2 (Quiz): SKIPPED (Doc Failed)
User 9 Step 1 (Doc): HTTP 500
User 9 Step 2 (Quiz): SKIPPED (Doc Failed)
User 6 Step 1 (Doc): HTTP 500
User 6 Step 2 (Quiz): SKIPPED (Doc Failed)
User 2 Step 1 (Doc): HTTP 500
User 2 Step 2 (Quiz): SKIPPED (Doc Failed)
User 10 Step 1 (Doc): HTTP 500
User 10 Step 2 (Quiz): SKIPPED (Doc Failed)
User 4 Step 1 (Doc): HTTP 200
User 4 Step 2 (Quiz): SKIPPED (No Doc ID)
✅ All flows completed.

참고로 요약글 GET API는 그 날 요약글이 생성되지 않았다면 생성 후 반환, 이미 있다면 바로 반환한다.

위 결과에서 HTTP 200으로 처리된 쪽을 보면 GET 요청은 성공적이었지만, 처음에 요약글 1회 생성에 성공한 뒤 후반에 조회로 된 게 아니라 요약글이 2번 생성된 것이었다. (DB에서 확인 시 중복 생성된 걸 확인함)

시도 2) 트랜잭션 시점 문제를 해결

그렇다면 Lock이 분명 있는데도, 대기 시간을 LLM 소요 시간보다 길게 잡았는데도, 요약글이 중복 생성 되는 이유는 무엇일까?

초반에 보여줬던 운영 서버 에러 로그에서 'Transaction'이라는 단어가 있었다.

참고로 DB 트랜잭션 개념은 다음과 같다.

DB Transaction 트랜잭션
데이터베이스 트랜잭션(Database Transaction)은 데이터베이스의 상태를 변화시키기 위해 수행하는 하나의 논리적인 작업 단위

1️⃣ Active (활성): 트랜잭션이 시작되어 읽기(Read)나 쓰기(Write) 연산을 수행 중인 초기 상태

2️⃣ Partially Committed (부분 완료): 마지막 연산까지 실행을 마쳤지만, 아직 데이터베이스에 최종적으로 반영(Commit)되기 직전의 상태

3️⃣ Committed (완료): 트랜잭션이 성공적으로 완료되어 변경 내용이 데이터베이스에 영구적으로 반영된 상태

4️⃣, 5️⃣ Failed (실패): 연산 수행 중 오류가 발생하거나 명시적으로 중단(Abort)되어 더 이상 정상적인 수행이 불가능한 상태

6️⃣ Terminated (종료): 트랜잭션이 커밋되거나 롤백(Rollback)된 후 완전히 종료된 상태

만약 요약글 생성 메서드가 시작되고 연산을 수행 중인데, 아직 생성된 요약글을 저장하려 했지만 DB에 반영되지 않은 상태에서 다시 한번 요약글 생성 API를 호출하면 어떻게 될까? 프록시 입장에서는 확인되는 오늘의 요약글이 없을 테니, 문제가 없을 거라 판단하고 한 번 더 요약글 생성을 하게 될 것이다. 즉 트랜잭션 커밋 시점 차이로 인해 문제가 생길 수 있는 것이다!

1. 서버(Thread A): 요약글 생성 API 호출 & 락 점유 (아직 Transaction commit이 되지 않아 DB에 완전히 저장 x)
2. 프론트엔드: 버튼을 모르고 연타하는 등, 요약글 생성 API 중복 호출됨
3. 서버(Thread A): (조금 뒤) 락 해제
4. 서버(Thread B): 요약글 생성 API 호출 & 락 점유 , DB 조회 했지만 아직 Thread A에서의 Transaction이 끝나지 않아 저장된 요약글이 없기에 또 요약글을 중복 생성
5. 서버(Thread A): 뒤늦게 트랜잭션 커밋 완료. 이제 DB에 요약글이 진짜 save
6. 서버(Thread B): (조금 뒤) 락 해제 , 이후 트랜잭션 커밋 완료, 또 다시 요약글이 save
.
.
.
=> 결과적으로 요약글이 중복 되어 여러 개가 생김

또한 이는 요약글 생성 이후의 퀴즈 생성에서도 발생할 수 있는 문제이다.
만약 요약글 데이터 저장 호출은 했는데 아직 DB에 반영(Commit)이 안 된 순간에 프론트엔드가 퀴즈 생성 API를 요청한다면 다음과 같을 것이다.

서버(Thread A): 요약글 만들고 퀴즈 생성함. (아직 트랜잭션 안 끝남, DB에 완전히 저장 x)

프론트엔드: 요약글 생겼다고 판단 후 GET /quizzes

서버(Thread B): DB 조회 했지만 아직 커밋 안 돼서 퀴즈가 없음 -> 빈 화면 반환 (Empty List)

서버(Thread A): (조금 뒤) 트랜잭션 커밋 완료. 이제 DB에 퀴즈가 진짜로 보임.

유저: (앱 나갔다 들어옴) 다시 퀴즈 요청 -> 서버가 이제는 퀴즈 반환 가능

이런 문제를 트랜잭션 커밋 시점 차이(Race Condition / Visibility Issue)라고 한다.

이 문제를 해결하려면 "트랜잭션이 완전히 커밋된 후에 락이 해제되도록" 코드를 수정해야한다. 트랜잭션 관련 코드를 수정하기 앞서, 스프링에서의 트랜잭션 전략에 대해서 잠시 알아보자.

Spring에서 트랜잭션 활용하기

✔️ @Transactional 어노테이션: 메서드나 클래스에 붙여, 메서드 시작 시 트랜잭션을 열고 메서드가 성공적으로 종료될 시 commit, 런타임 예외 발생 시 rollback을 자동 수행한다.

✔️ 동작 원리 (AOP Proxy)
Spring에서 @Transactional이 동작하는 방식은 내부적으로 AOP(Aspect Oriented Programming)를 활용한다.
1. Spring이 해당 객체를 상속받거나 인터페이스를 구현한 프록시(Proxy, 가짜 스프링 Bean) 객체를 생성
2. 사용자가 메서드를 호출하면 프록시가 먼저 호출을 가로챔.
3. 프록시 내부에서 TransactionManager를 통해 트랜잭션을 시작
4. 실제 비즈니스 로직을 수행한 후, 결과에 따라 Commit 또는 Rollback이 호출

이에 따라 기존 요약글 관련 UseCase 메서드의 @Transactional에서 Propagation.NOT_SUPPORTED 조건을 넣어 트랜잭션의 범위를 수정하기로 결정했다. 즉, 큰 트랜잭션의 범위를 무시하는 것이다.

// CategoryDocumentUseCase.java
// 1. 외부 트랜잭션 없이 진입 (락보다 넓은 범위의 트랜잭션 방지)
@Transactional(propagation = Propagation.NOT_SUPPORTED)
public CategoryDocumentResponse generateDocument(Long categoryId, Long userId) {
    // ... 검증 로직 ...
    // 2. 락 획득 시도 및 로직 수행
    CategoryDocument targetDocument = distributedLockFacade.tryExecuteWithLock(
        lockKey, 
        30, 
        60, 
        TimeUnit.SECONDS, 
        () -> {
            // 3. 락 내부에서 이중 체크 (Double Check)
            if (categoryDocumentService.existsByGoalIdAndDate(goal.getId(), LocalDate.now())) {
                return categoryDocumentService.getDocumentsByGoalId(...);
            }
            // 4. 실제 생성 및 저장 (여기서 내부적으로 새로운 트랜잭션이 시작되고 커밋됨)
            return createDocumentInternal(goal);
        }
    ).orElseGet(() -> {
        // 락 획득 실패 시 재조회 등 처리
    });
}

즉 정리해보자면 다음과 같다.

기존 트랜잭션
@Transactional

✅ 트랜잭션
@Transactional(propagation = Propagation.NOT_SUPPORTED))

: 메서드가 시작될 때 트랜잭션을 열고 메서드가 완전히 끝나서 리턴될 때 닫는(커밋) 구조

기존 로직

UseCase 메서드 시작 (트랜잭션 시작 )
락 점유
요약글/퀴즈 생성 & DB save 호출 -> 하지만 아직 커밋 x, 메모리에만 있음
락 해제 (메서드 로직 상 finally 블록에서 해제됨)
메서드 종료 및 프록시가 트랜잭션 커밋 (DB 반영)

: 큰 트랜잭션 없이 작은 트랜잭션을 관리하는 구조

변경된 흐름

UseCase 메서드 시작 (트랜잭션 없음)
락 점유
요약글/퀴즈 생성
DB save resultRepository.save(...) 호출 -> 이 순간 트랜잭션이 열리고, 바로 저장하고, 바로 커밋됨 (작은 트랜잭션 종료)
- DB 저장 메서드 등은 자체 트랜잭션을 가짐
락 해제

변경 전(왼쪽의 기존 트랜잭션): 전체 로직이 하나의 트랜잭션으로 묶여 락이 먼저 풀림, DB 반영은 나중에 됨.
➡️ 변경 후(오른쪽의 트랜잭션 전략): 락 점유 중 내부에서 개별적인 작은 트랜잭션(Repository의 save 등)이 실행되고 즉시 커밋됨. 락이 풀리는 시점에는 이미 DB에 데이터가 저장된 상태이도록 함.

오른쪽 방법처럼 주요 메서드에서 트랜잭션 옵션을 바꾸어, 락 점유 중에 생성된 요약글을 바로 DB에 저장하여 락이 풀리자마자 다른 요청들이 요약글이 생성된 사실을 인지하게끔 하였다.

스크립트 실행 결과(성공)

  Starting 5 concurrent user flows (Doc -> Quizzes)...
Target: Category ID 107
User 3 Step 1 (Doc): HTTP 200
User 2 Step 1 (Doc): HTTP 200
User 5 Step 1 (Doc): HTTP 200
User 4 Step 1 (Doc): HTTP 200
User 1 Step 1 (Doc): HTTP 200
User 3 Step 2 (Quiz): HTTP 200 (DocId: 79)
User 2 Step 2 (Quiz): HTTP 200 (DocId: 79)
User 5 Step 2 (Quiz): HTTP 200 (DocId: 79)
User 4 Step 2 (Quiz): HTTP 200 (DocId: 79)
User 1 Step 2 (Quiz): HTTP 200 (DocId: 79)
✅ All flows completed.

다만, 트랜잭션 없이 접근하는 부분에서 엮여있는 기존의 지연 로딩 접근 메서드에서는 LazyInitializationException이 발생하기도 했다.

이런 부분(findWithCurrentGoalById, findWithGoalById 등...)에는 해결책으로 Fetch Join을 사용하는 전용 조회 메서드를 추가하여, 필요한 데이터를 한 번에 안전하게 가져오도록 수정하였다.

// UserRepository.java
@Query("select u from UserEntity u left join fetch u.currentGoal g left join fetch g.category where u.id = :id")
Optional<UserEntity> findWithCurrentGoalById(Long id);

이번 트러블 슈팅을 통해 단순히 Redis Lock을 건다고 해서 모든 동시성 문제가 해결되는 것은 아닌 걸 깨달았다. 처음에는 Lock 관점에서만 생각했는데, 에러 로그의 Transaction이라는 키워드를 통해 DB 저장 시점 즉 DB 커밋 시점과 락 해제 시점의 불일치에서 문제가 있었다는 걸 파악할 수 있었다.

즉, Lock의 범위와 트랜잭션의 범위(생명주기) 관계를 정확히 이해하고 설계해야 데이터 정합성을 보장할 수 있다는 게 핵심이었다.

또한 Spring에서 다루는 DB의 트랜잭션 범위나, @Transactional에 걸 수 있는 조건은 readOnly 외에는 잘 몰랐었는데 프록시와 엮어 AOP 기반으로 어떻게 관리되는지까지 확장해서 공부할 수 있었다!

@Transactional과 AOP 기반의 락이 만났을 때, 트랜잭션 커밋 시점이 락 해제보다 늦어질 수 있다는 점은 잊지 않아야겠다고 다짐했다.

앱 서비스를 출시하였지만, 계속 고도화하면서 아마 광고를 본 사용자에게는 요약글과 퀴즈를 더 제공하는 기능 등이 생길 예정인데 해당 Lock을 어떻게 리팩토링할지 고민해보아야겠다.

[Prometheus, Grafana] 모니터링 시스템 구축 방법과 대시보드 개선

jimddong — Sat, 24 Jan 2026 01:30:55 +0900

모니터링 대시보드 개선 및 지표 추가 기록

서비스 안정성과 장애 대응력을 높이기 위해 주요 지표들을 추가하였습니다.

1. 실시간 API별 트래픽 분석표 패널 생성

도입 이유

기존의 Mean(평균) 지표는 소수의 사용자가 겪는 극심한 지연(Long Tail)을 반영하지 못하는 평균의 함정 발생 가능

ex. 대다수 사용자가 0.1초의 응답을 받아도, 특정 요청이 10초가 걸릴 경우 평균값은 실제 사용자 경험보다 훨씬 낮게 측정되어 장애 감지가 늦어질 수 있음.

요청 처리 시간 지표 고도화
- P95 (95th Percentile): 하위 5%를 제외한 대다수 사용자가 체감하는 최악의 속도를 모니터링
기대 효과: 일시적인 네트워크 지연이나 특정 API의 성능 저하를 통계적으로 유의미하게 파악할 수 있음.

2. 에러율(Error Rate) 및 상태 코드 가시화

도입 이유

단순 요청 수(RPM) 그래프는 요청의 성공 여부를 구분하기 어려움.

ex. 서버에 치명적인 오류가 발생해 모든 요청이 500 에러를 반환하고 있음에도, 요청 수가 급증하면 이를 서비스 활성화로 오해할 수도 있음.

HTTP Status Code 분류: 4xx(클라이언트 오류), 5xx(서버 오류)를 시각적으로 구분
에러 발생 알림 기준: 최근 1분간 에러 발생 빈도를 계산하는 PromQL 적용
기대 효과: 서비스 가용성(Availability)을 실시간으로 확인하고, 배포 직후나 트래픽 폭증 시 즉각적인 장애 인지가 가능함.

sum by (status) (increase(http_server_requests_seconds_count{status=~"4..|5.."}[1m])) > 0

3. DB 커넥션 풀(HikariCP) 상태 모니터링

도입 이유

DB 커넥션 풀 고갈: Spring Boot 기반 애플리케이션에서 성능 저하의 가장 흔한 원인

⇒ 대시보드에서 하드웨어 자원(CPU/RAM)만 볼 경우, DB 연결을 기다리느라 응답이 멈춘 상황을 분석하기 어려울 수 있기에 이를 도입함.

주요 모니터링 지표:
- hikaricp_connections_active: 현재 활성 상태인 커넥션
- hikaricp_connections_pending: 커넥션 할당을 기다리며 대기 중인 스레드 수
기대 효과: 응답 지연의 원인이 애플리케이션 로직인지, DB 연결 병목인지 명확히 구분하여 인프라 증설이나 쿼리 최적화 등의 의사결정 근거로 활용 가능

추가 고려 사항

대시보드 구축 후 모니터링 과정에서 UNKNOWN으로 기록된 401, 400 에러들이 다수 관측됨.
- 해당 요청들은 Spring Security의 Filter Chain 단계에서 즉시 차단된 악성/비인가 요청 ⇒ 비정상적인 요청이 비즈니스 로직(Controller)까지 진입하여 자원을 소모하기 전에 앞단(Filter)에서 효율적으로 거부되고 있다는 뜻..
지표들 기반으로 코드 수정점 발견 시 코드 개선 필요

이에 따른 코드 개선점에 대해 다음 글에서 설명하도록 하겠다.

[Spring] 객체 중복 생성 방지를 위한 Redis 분산 Lock 도입

jimddong — Fri, 23 Jan 2026 02:38:07 +0900

최근 진행 중인 프로젝트에서, AI를 활용하여 사용자가 원하는 주제의 요약글과 퀴즈를 생성하는 기능을 개발하는 역할을 맡았다.
사용자는 원하는 목표 기간 동안 최대 하루 한 번씩 생성된 요약글과 퀴즈 세트를 확인 후 풀이할 수 있다.

하루 1회 요약글과 퀴즈 세트가 모두 OpenAI 모델을 활용해 생성되게끔 구현하였는데, 사용자가 그날 최초로 홈 화면에 접속 했을 때 해당 객체들이 순차적으로 생기게끔 구현하기로 했다.

하지만 실제 서버 로그와 DB를 확인했을 때는 그렇지 않았다. 그날 최초 홈화면 접속 시 하루 1회만 생성 되어야 할 요약글과 퀴즈 세트가 여러 개 생성되는 것이다.

사용자 입장에서 요약글이나 퀴즈 세트를 조회하면 그날분의 것만 볼 수 있어서 문제가 되지 않았지만, DB 비용을 낭비한다는 점에서 문제가 있어 수정이 필요했다.

사실 요약글과 퀴즈 세트가 생기기까지 즉, LLM이 생성한 응답을 조회하기까지 OpenAI 특성 상 시간이 꽤 걸린다. 그동안 유저는 홈 화면에서 기다리기만 하지 않고 다른 탭을 눌러보는 등 홈 화면을 여러 번 들락거릴 수 있다. 아까 언급 했듯이 '홈 화면에 들어오면 요약글과 퀴즈 세트가 하루 최대 한 번 생김'에서 나는 하루 한 번 생성되어야하는 요약글, 퀴즈 세트 로직에만 집중했었다. 실제로 그 날 한 번 이 객체들이 생성 되면, 그 날에 더이상 요약글, 퀴즈 세트를 생성할 수 없게 코드는 작성되어있다.

내가 놓친 것은 LLM이 응답을 만들고 있을 때였다. 현재 프론트 쪽에서는 요약글과 퀴즈가 생기기 전에 홈화면에 들어 오면 요약글 생성 API와 퀴즈 생성 API를 호출한다. 객체가 생성되기 직전인, LLM이 응답(요약글과 퀴즈 세트)을 만들고 있을 동안에 사용자 홈화면 버튼을 여러 번 연타하거나 들락거리는 경우는 고려하지 못 했던 것이다..!

문제 상황을 시퀀스 다이어그램으로 나타낸 모습

(역시 실제 화면 플로우와 그 속에서 일어날 수 있는 다양한 케이스를 고려해야하는 걸 여기서 뼈저리게 느꼈다.)

이처럼 요약글 및 퀴즈가 생기기 전까지 홈 화면에 여러번 접속해서 생성 요청이 여러 번 보내진다면, 그 횟수만큼 요약글 및 퀴즈가 중복되어 생성되며 안 그래도 LLM 응답이 느린데 응답이 더 느려지는 문제도 있었다.

이내 '그날 최초로 홈 화면에 접속 했을 때만 해당 객체들이 생기게 하기'에 집중했다. 처음에는 2가지 방법을 함께 도입했다.

객체 중복 생성 방지

시도 1. DB Unique 제약 조건 -> 실패

요약글 생성은 단일 엔티티를 생성하는 것이라 이런 식으로 요약글 엔티티 코드 앞에 해당 날에는 딱 하나의 요약글이 생기게 제약을 두었다.

@Table(name = "category_document", uniqueConstraints = {
        @UniqueConstraint(name = "uk_category_document_goal_date", columnNames = { "goal_id", "created_date" })
})

하지만, 배포 서버에 반영 후 DB를 확인해보니 여전히 요약글이 생기기 전까지 LLM이 작동하는 동안 홈 화면을 여러 번 들어올 때마다 그 횟수만큼 요약글이 여러 개 생기는 문제가 있었다. 하루 생성 중복이 막아지지 않은 것이다.

이유는 다음과 같았다.

요약글 엔티티는 공통 필드를 사용하기 위해 BaseEntity를 상속하는데, 이 중 LocalDateTime createdDate은 초 단위까지 기록하게 되어있다. 이러한 경우에, 현재처럼 createdDate를 비교하여 엔티티가 독립적인지 판별하려면 당연히 초 단위까지 고려할 것이다.

하지만 LLM 응답이 오기 전까지 홈 화면을 여러 번 들어오거나 생성 요청이 연타되었다면 요청 시간대는 다음과 같을 수 있다.

// 요청 예시
첫 번째 요청: 2026-01-19 16:49:02.471919
두 번째 요청: 2026-01-19 16:49:11.590923

즉, DB Unique Constraint 설정에서 (goal_id, created_date)가 중복되지 않게 막았지만 초 단위(밀리초 차이로 다른 시간에 들어온 요청은 모두 다른 데이터로 인식)로 판단하여, 요약글 생성이 1일 1회로 지켜지지 않는 문제가 발생한 것이다. 따라서 요약글에도 다음 2번 방법을 적용하기로 결정했다.

(해결 방법) 2. Redis 분산 Lock

사실 퀴즈에 우선 이 방법을 적용했었다. 하루에 퀴즈 세트 하나를 생성하는 것이지, 퀴즈 엔티티를 딱 하나 만드는 것이 아니었기에 퀴즈에는 DB Unique 제약을 걸 수 없었기 때문이다.

Redis 분산 Lock 개념

tryLock(waitTime, leaseTime, timeUnit): 앞선 lock을 최대 waitTime만큼 기다리고, 최대 leaseTime만큼 점유(Lock 획득)할 수 있다.
- 앞선 첫 요청이 Lock을 점유하고 있을 때(작업 중) → 두 번째 요청은 첫 번째 요청이 끝날 때까지 최대 waitTime까지 기다려준다.
- 앞선 요청이 Lock을 점유하고 있지 않다면 두 번째 요청은 락을 즉시 획득한다. (대기 0초)

퀴즈에서의 Redis 분산 Lock의 흐름은 다음과 같다.

<로직>
1. 퀴즈 생성 전에 lock:quiz:generation:{문서ID}:{유저ID} 라는 이름으로 lock 걸기
2. 1번째 요청: lock(최대 60초)-> 퀴즈 생성(LLM 호출) -> unlock(생성 시 바로 잠금 해제)
=> 예를 들어 사용자가 버튼을 10번 연타해도, 2~10번째 요청은 대기하다가 1번 요청 확인 후 퀴즈 생성 안 하고 리턴하게 됨.

// Redisson Distributed Lock 도입
            String lockKey = "lock:quiz:generation:" + documentId + ":" + userId;
            RLock lock = redissonClient.getLock(lockKey);

            try {
                // 3초 대기, 60초 락 점유 (LLM 응답이 늦어질 수 있으므로 넉넉하게 잡음)
                if (lock.tryLock(3, 60, TimeUnit.SECONDS)) {
                    try {
                        // Double-Check: 락 획득 후 다시 한 번 개수 확인 (다른 스레드가 이미 생성했을 수도 있음)
                        priorityQuizzes = quizService.getUnsolvedQuizzesByAttributes(documentId, userId,
                                targetDifficulty, targetTopic, quizCount);

                        if (priorityQuizzes.size() < quizCount) {
                            int remainingCount = quizCount - priorityQuizzes.size();
                            quizUseCase.createQuizzesForDocument(documentId, userId, remainingCount);

                            // 재생성 후 최종 조회
                            priorityQuizzes = quizService.getUnsolvedQuizzesByAttributes(documentId, userId,
                                    targetDifficulty, targetTopic, quizCount);
                        }
                    } finally {
                        if (lock.isLocked() && lock.isHeldByCurrentThread()) {
                            lock.unlock();
                        }
                    }
                } else {
                    // 락 획득 실패 시 (Timeout) -> 기존 조회된 것만 반환하거나 예외처리
                    // 여기서는 최대한 생성된 만큼만 반환
                }
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
                throw new BaseException(CommonResponseCode.INTERNAL_SERVER_ERROR);
            }
        }

퀴즈에 Redis 분산 Lock을 도입했을 때는 퀴즈 세트가 딱 하나가 생성 되어 문제 없이 작동하는 것을 확인했다.

따라서 요약글 생성에도 위 로직을 도입하기 위해 공통 메서드를 만들었다.

 public <T> T executeWithLock(String lockKey, long waitTime, long leaseTime, TimeUnit timeUnit, Supplier<T> action) {
        RLock lock = redissonClient.getLock(lockKey);

        try {
            if (!lock.tryLock(waitTime, leaseTime, timeUnit)) {
                log.warn("Failed to acquire lock: {}", lockKey);
                throw new BaseException(CommonResponseCode.INTERNAL_SERVER_ERROR);
            }

            try {
                return action.get();
            } finally {
                if (lock.isLocked() && lock.isHeldByCurrentThread()) {
                    lock.unlock();
                }
            }
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            log.error("Lock acquisition interrupted: {}", lockKey, e);
            throw new BaseException(CommonResponseCode.INTERNAL_SERVER_ERROR);
        }
    }

하지만 Lock 로직이 여러 개 생겼을 때는 또 다른 문제가 생겼다.

요약글이 먼저 생성되고, 그 글의 내용을 기반으로 퀴즈를 생성해야하기에 Lock 로직을 두 개로 분리하였는데 요약글이 여러 개 생기는 것이다.

이 문제는 트랜잭션과 관련이 있었고, 바로 다음 글에서 자세히 해결 과정을 기술하겠다.

[BOJ] 1012번: 유기농 배추 (Java)

jimddong — Mon, 3 Nov 2025 16:33:25 +0900

https://www.acmicpc.net/problem/1012

문제 설명

이 문제는 배추밭에 필요한 배추흰지렁이의 총 마리수를 구해야한다. 배추가 서로 인접해있는 구역 하나 당 한 마리의 배추흰지렁이가 필요하기에, 배추가 있는 구역의 수를 세어 출력하면 된다.

사진과 같은 배추밭은 배추 구역이 5개, 따라서 답도 5이다.

즉 배추가 심어진 칸(1)이 상하좌우로 붙어있는 면적은 구역이 된다.

시도 1 - Comparator로 2차원 배열을 탐색하기

이 코드는 Comparator로 2차원 배열을 탐색하는데, 배추가 있는 구역의 바로 오른쪽/아래가 인접하면 같은 덩어리로 간주하게끔 했다.

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.Arrays;
import java.util.StringTokenizer;

public class Main {
    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        int T = Integer.parseInt(br.readLine());

        StringTokenizer field = new StringTokenizer(br.readLine());
        int M = Integer.parseInt(field.nextToken());
        int N = Integer.parseInt(field.nextToken());
        int K = Integer.parseInt(field.nextToken());

        StringBuilder result = new StringBuilder();

        for (int i = 0; i < T; i++) {
            result.append(getCabbagePosition(K)).append("\n");
        }

        System.out.print(result);
    }

    static int getCabbagePosition(int K) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        int[][] cabbages = new int[K][2];

        for (int i = 0; i < K; i++) {
            StringTokenizer xOrY = new StringTokenizer(br.readLine());
            int x = Integer.parseInt(xOrY.nextToken());
            int y = Integer.parseInt(xOrY.nextToken());
            int[] arr = {x,y};
            cabbages[i] = arr;
        }

        Arrays.sort(cabbages, (o1, o2) -> {
            if (o1[0] - o2[0] == 0)
                return o1[1] - o2[1];

            else return o1[0] - o2[0];
        });

        return countEarthWorm(cabbages, K);
    }

    static int countEarthWorm(int[][] arr, int K) {
        int count = 0;

        for (int i = 0; i < K; i++) {
            if ((arr[i][0] + 1 == arr[i+1][0] && arr[i][1] == arr[i+1][1])
                || (arr[i][0] == arr[i+1][0] && arr[i][1] + 1 == arr[i+1][1])) {
                continue;
            }

            else {
                count++;
                break;
            }
        }
        return count;
    }
}

배추가 있는 (x,y) 좌표를 정렬하였을 때 만약 바로 다음 좌표가 오른쪽/아래로 인접하면 같은 덩어리로 간주하려했는데, 그래프 연결은 바로 다음 원소만 인접한다고 생기는 것이 아닐뿐더러 count++의 기준도 이상했다. 따라서 이런 방식으로 구현하기에 복잡도가 올라가 다른 방식을 찾아보려 했다.

시도 2 - 배열 내 요소를 오른쪽, 아래 방향으로 탐색하기

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.StringTokenizer;

public class Main2 {
    static int M, N, K, count;
    static int[][] field;

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        int T = Integer.parseInt(br.readLine());
        int[][] cabbages;
        StringBuilder result = new StringBuilder();

        // 밭에 배추 심기
        for (int i = 0; i < T; i++) {
            // 밭 크기, 배추 개수
            StringTokenizer st = new StringTokenizer(br.readLine());
            M = Integer.parseInt(st.nextToken());
            N = Integer.parseInt(st.nextToken());
            K = Integer.parseInt(st.nextToken());

            field = new int[N][M];
            cabbages = new int[K][2];

            // 배추 심은 좌표값 = 1
            for (int j = 0; j < K; j++) {
                StringTokenizer st2 = new StringTokenizer(br.readLine());
                int x = Integer.parseInt(st2.nextToken());
                int y = Integer.parseInt(st2.nextToken());
                field[x][y] = 1;

                // 배추 위치 배열에 저장
                cabbages[j][0] = x;
                cabbages[j][1] = y;
            }

            count = 0;
            for (int j = 0; j < K; j++) {
                int x = cabbages[j][0];
                int y = cabbages[j][1];

                if(field[x][y] == 0)
                    continue;

                countEarthWorm(x, y);
            }
            result.append(count).append("\n");
        }

        System.out.println(result);
    }

    public static int countEarthWorm(int x, int y) {
        field[x][y] = 0; // 체크 완료했기에 중복 count 방지를 위해 0으로 변경

        if (x<M || y<N) {
            if (x==M-1 && y==N-1){
                count++;
                return 0;
            }

            if (x==M-1) {
                if ((field[x][y+1] == 0)) {
                    countEarthWorm(x, y+1);
                }
            }

            if (y==N-1) {
                if ((field[x+1][y] == 0)) {
                    countEarthWorm(x+1, y);
                }
            }

            if ((field[x+1][y] == 0) && (field[x][y+1] == 0)) {
                count++;
                return 0;
            }

            else {
                if (field[x+1][y] == 1) {
                    countEarthWorm(x+1, y);
                }

                if (field[x][y+1] == 1) {
                    countEarthWorm(x, y+1);
                }
            }
        }
        return 0;
    }
}

이번에는 Comparator를 버리고, 그냥 좌표를 처음부터 끝까지 탐색하려했다. 하지만 문제는 이 코드에서도 나는 오른쪽, 아래쪽에 바로 인접한 정점만 확인하려 했던 것이다. 배추밭에서의 그래프는 무방향이므로 상하좌우 4방향을 모두 검사해야한다.

또한 인덱스도 field[y][x]로 확인해야했는데 뒤집어서 설정했다는 것도 큰 오류였다.

(* 배추밭의 가로길이 M(1 ≤ M ≤ 50)과 세로길이 N(1 ≤ N ≤ 50), 배추의 위치 X(0 ≤ X ≤ M-1), Y(0 ≤ Y ≤ N-1))

(⭐️최종) 시도 3 - BFS, DFS를 활용하여 탐색하기

위 시도 끝에 내가 고려해야할 점은 2가지였다.

1. 현재 정점에서 인접한 상하좌우 4방향을 모두 탐색하기

검사해야할 좌표: 현재 좌표의 상하좌우 1칸 근방에 있는 노드 4개
- 방향: (-1,0), (1,0), (0,-1), (0,1)
⇒ int[] dx = {1,-1, 0, 0} : x좌표 direction
& int[] dy = {0, 0, 1, -1} : y좌표 direction
// 상하좌우 4가지 확인 (0, 1) (0,-1) (1,0) (-1,0)
            for (int dir = 0; dir < 4; dir++) {
                int nextJ = j + dy[dir];
                int nextI = i + dx[dir];
                .
                .
                .
둘을 조합한 값을 현재 좌표에 더해 이동시키면, 현재 좌표의 상하좌우 1칸 근방에 있는 좌표를 모두 표현 가능하다.

따라서 만약 좌표 값이 1이면(배추가 있으면) 그 노드의 상하좌우를 검사한다.

이를 상하좌우 모든 좌표 값이 모두 0이 나올 때까지 반복하면 된다.

2. 탐색 기준 정하기

이때까지는 배추가 있는 노드의 오른쪽이나 아래에도 배추가 있다면(값이 1이라면) 순차적으로 탐색을 진행했다. 하지만 이 방식은 배열 요소 값이 1임에도 미처 탐색하지 못하고 지나치게 될 수 있기에 적합하지 않았다.

따라서 적절한 우선 순위나 기준에 따라 2차원 배열을 탐색해야하기에, 그래프 탐색 방식인 DFS 혹은 BFS를 활용할 수 있다.

DFS(깊이 우선 탐색)
- 재귀
- field 2차원 배열
- boolean visited[] 혹은 field 배열에서 방문한 정점의 값은 0으로 대체

BFS(너비 우선 탐색)
- 큐(FIFO): 큐에 해당 정점 넣고, 검사 시 제거
- field 배열
- boolean visited[] 혹은 field 배열에서 방문한 정점의 값은 0으로 대체

사실 이 문제와 같이 2차원 배열을 탐색해야하는 유형의 문제는 대체로 BFS/DFS를 활용하여 푼다. 즉 큐에 검사한 요소들을 넣고 빼서 탐색하거나, 재귀(스택)으로 탐색을 반복하면 된다. 처음 해결했을 때는 이 배추밭은 탐색 순서가 정해져있지 않기에 BFS/DFS 즉 너비 우선/깊이 우선 탐색이 무슨 관련이 있는지, 단순히 '큐나 재귀로 푸는 문제' 같기만 했다. '너비나 깊이를 우선으로 탐색 순서를 정하는 게 배추밭에 배추가 있는(값이 1인) 모든 정점을 탐색해내야하는 것은 거리가 느껴져.'가 내 생각이었다.

하지만 이 의문은 그래프의 정의와 연결관계를 생각해보며 해결할 수 있었다.

⚠️ 주의할 점

이 문제는 단순히 DFS/BFS 문제가 아니다. 2차원 배열 내 그래프를 어떻게 탐색할 것인지, 즉 큐나 재귀(스택)을 활용해 어떤 방식으로 탐색하느냐에 달려있다.

그래프는 정점(Vertex)와 간선(Edge)의 집합으로, 방향이 있든 없든 상관 없다.

그리고 문제의 배추밭은 루트도 방향도 없는 무방향 비연결 그래프이다.

따라서 이 문제에서는 마치 DFS/BFS의 본래 의미인 “탐색 순서”, 즉 깊이나 너비를 우선으로 탐색한다는 의의는 퇴색되어 보이고 실제로도 상대적으로 중요하지 않다. 핵심은 배열 내 값이 1인 정점 기준으로, 상하좌우 인접한 1들이 있는지 덩어리로 묶어 탐색(connected component 탐색)한다. 서로 연결된 것만 다 훑는 것이 문제의 목표로, 어느 방향부터 우선적으로 탐색할 것인지 구체적인 순서는 중요하지 않은 특수 케이스다.

DFS/BFS는 개념, 탐색 전략이고 큐/재귀(스택)은 구현 도구이다. 여기서는 정점간 연결 관계를 완전히 탐색하기 위한 도구로 DFS/BFS의 구현 도구인 큐/재귀(스택)을 이용할 수 있다. 즉, 단순 DFS/BFS 문제라기 보다는 그래프 연결 관계 탐색이라는 문제 목표를 위해 DFS/BFS를 활용하여 풀 수 있는 것 핵심이다.

특히 내가 처음에 DFS, BFS를 납득하기 어려웠던 이유는 DFS, BFS를 구현할 때 이때까지는 번호가 매겨진 정점이 어떤 정점과 이어져있는지를 확인하여 각 정점별 배열에 넣었기 때문이다. 배열에 들어간 요소들이 너비 우선이나 깊이 우선이라는 기준에 따라 어떤 정점과 이어져있는지 하나씩 검사하는 과정이었다. 그래서 DFS, BFS를 탐색 순서를 찾기 위한 용도로만 이제껏 생각해왔다.

그래프 정의에 따르면, 이 배추밭은 루트도 방향도 없기에 '무방향 비연결 그래프'이다. 그래프 탐색 순서라는 개념이 들어간 DFS/BFS는 결국 정점간 연결관계를 모두 완전히 탐색한다는 점에서 탐색 전략이기도 하다.

결국 모든 정점을 탐색하기 위해, 탐색 방식에 있어서 너비나 깊이를 우선으로 탐색할지만 결정한 것에 그치지 않는다. 즉, 이번 문제에서는 DFS/BFS를 구현하는 큐/재귀(스택)으로 모든 연결된 정점을 탐색하겠다는 목표로 DFS/BFS 개념을 활용하면 되는 것이다!

BFS - 큐

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.ArrayDeque;
import java.util.StringTokenizer;

public class Bfs {
    static int[][] field;
    static int M, N, K;
    static int[] dx = {1,-1, 0, 0};
    static int[] dy = {0, 0, 1, -1};

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        int T = Integer.parseInt(br.readLine());

        StringBuilder result = new StringBuilder();

        for (int i = 0; i < T; i++) {
            StringTokenizer st = new StringTokenizer(br.readLine());
            M = Integer.parseInt(st.nextToken());
            N = Integer.parseInt(st.nextToken());
            K = Integer.parseInt(st.nextToken());

            field = new int[N][M];

            for (int j = 0; j < K; j++) {
                StringTokenizer st_xy = new StringTokenizer(br.readLine());
                int x = Integer.parseInt(st_xy.nextToken());
                int y = Integer.parseInt(st_xy.nextToken());
                field[y][x] = 1;
            }

            int count = 0;
            for (int y = 0; y < N; y++) {
                for (int x = 0; x < M; x++) {
                    if(field[y][x] == 1) {
                        count++; // 지렁이 필요한 구역 하나씩 count
                        bfs(y,x);
                    }
                }
            }
            result.append(count).append("\n");
        }

        System.out.print(result);
    }

    static void bfs(int y, int x) {
        ArrayDeque<int[]> queue = new ArrayDeque<>();
        field[y][x] = 0; // 방문
        queue.add(new int[]{y,x});

        while(!queue.isEmpty()) {
            int[] cur = queue.poll();
            int j = cur[0];
            int i = cur[1];

            // 상하좌우 4가지 확인 (0, 1) (0,-1) (1,0) (-1,0)
            for (int dir = 0; dir < 4; dir++) {
                int nextJ = j + dy[dir];
                int nextI = i + dx[dir];
                if (nextI>=0 && nextI<M && nextJ>=0 && nextJ<N && field[nextJ][nextI] == 1) {
                    field[nextJ][nextI] = 0; // 방문 확인
                    queue.add(new int[]{nextJ, nextI});
                }
            }
        }
    }
}

DFS - 재귀

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.StringTokenizer;

public class Dfs {
    static int[][] field;
    static int M, N, K;
    static int[] dirX = {1,-1, 0, 0};
    static int[] dirY = {0, 0, 1, -1};

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        int T = Integer.parseInt(br.readLine());

        StringBuilder result = new StringBuilder();

        for (int i = 0; i < T; i++) {
            StringTokenizer st = new StringTokenizer(br.readLine());
            M = Integer.parseInt(st.nextToken());
            N = Integer.parseInt(st.nextToken());
            K = Integer.parseInt(st.nextToken());

            field = new int[N][M];

            for (int j = 0; j < K; j++) {
                StringTokenizer st_xy = new StringTokenizer(br.readLine());
                int x = Integer.parseInt(st_xy.nextToken());
                int y = Integer.parseInt(st_xy.nextToken());
                field[y][x] = 1;
            }

            int count = 0;
            for (int y = 0; y < N; y++) {
                for (int x = 0; x < M; x++) {
                    if(field[y][x] == 1) {
                        count++; // 지렁이 필요한 구역 하나씩 count
                        dfs(y,x);
                    }
                }
            }
            result.append(count).append("\n");
        }

        System.out.print(result);
    }

    // 재귀
    static void dfs(int y, int x) {
        field[y][x] = 0; // 방문 확인

        for (int i = 0; i < 4; i++) {
            int nextY = y + dirY[i];
            int nextX = x + dirX[i];

            if (nextY>=0 && nextY<N && nextX>=0 && nextX<M && field[nextY][nextX] == 1) {
                dfs(nextY, nextX);
            }
        }
    }
}

배추밭 탐색 시 모든 정점을 확인하되, 값이 1이라면 탐색 시작 시 count++(구역의 개수)을 해준다. 중요한 포인트는, 이때 이 정점은 BFS(큐)나 DFS(재귀)로 상하좌우까지 확인되고 이 정점의 값 1을 0으로 값을 바꿔주어 다음 배추밭 탐색에서 다시 확인(재방문)되어 count가 증가되지 않게 해주어야한다.

배운 점

이번 문제에서 시도 1, 2가 틀렸던 것은 이 문제의 본질이 그래프 문제임을 몰랐기 때문이라 생각한다. 만약 배추가 있단 좌표를 정렬 하고 그 다음 원소(오른쪽, 아래)만 비교하면 무방향 그래프의 연쇄/분기 연결을 놓칠 것이다. 또한 인덱스가 뒤바뀌거나(field[y][x]), 구역 개수를 세는 count++의 타이밍도 중요 했었다...

그래프라는 주제를 깨닫고 나서는 문제 풀이를 완전히 이해할 수 있었다. 결국 2차원 배열은 암묵적 그래프로, 앞으로도 2차원 배열을 탐색할 일이 있으면 그래프 탐색 BFS/DFS 개념을 활용할 수 있다. 이 문제에서는 배추밭을 그래프로 이해하면 격자의 각 칸을 정점, 상하좌우 인접을 간선으로 생각해볼 수 있다.

코드를 짜면서 앞서 언급했듯이 그저 큐나 재귀로 푼 문제 같다고만 느꼈다 했는데, 명심할 점은 DFS/BFS는 “어떤 순서로 방문할지”를 정하는 전략이고, 재귀(스택)/큐는 그 전략을 실현하는 구현 수단이다. 여기서는 무방향 그래프이기에 어떤 순서로 방문할지가 주 쟁점이 되기 보다는 모든 정점을 탐색하고자 하는 의도에서 BFS/DFS를 탐색에 활용한다.

그리고 상하좌우 모두를 검사하기 위해 x,y 방향을 지정해주는 dirX={1,-1,0,0}, dirY={0,0,1,-1} 같은 배열을 좌표에 조합하여 더해 쓸 수 있다는 새로운 아이디어도 얻었다!

[Git] Git branch 전략(Git-Flow), feature와 develop 브랜치 사이 작업 시 pull 전략

jimddong — Fri, 11 Jul 2025 17:37:06 +0900

그동안 팀 협업 시 Git을 쓰긴 했지만, 보통은 각자 작업한 내용을 feature 브랜치를 만들어 push하고 develop으로 merge하는 방식이었다. 그런데 이번에 새로운 프로젝트를 진행하게 되면서, Git branch 전략 중 Git-Flow를 접하게 되었다.

사실 나는 그간 여러 브랜치를 파는 게 개발적으로 단순 작업 분리 및 통합의 기능을 한다고 생각해왔었는데, 그 이상의 것을 한다는 걸 알게 되었다!
그 내용을 정리해보려 한다.

본론부터 말하자면 브랜치 전략은 팀 프로젝트 코드를 작업을 나누어 개발하는 것에서 더 나아가, 검증 및 배포 후 운영하는 데 있어서 필요하다. 왜냐면 Git-Flow에서는 단순 feature, develop이 끝이 아니라 release, main 브랜치까지 존재하기 때문이다.

Git Flow 구조를 직접 그림으로 그려보았다.

feature 브랜치

feature 브랜치는 개인이 할당 받은 작업을 처리하는 개인 개발용 브랜치라고 보면 된다. 그림에서 볼 수 있듯이 feature 브랜치는 develop에서 뻗어나와, 작업이 끝나면 다시 develop으로 합쳐진다. 즉, develop에서 시작하여 만든 브랜치에서 작업을 하고 develop으로 push한다는 것이다.

git checkout -b feature-project-init

// 해당 브랜치에서 코드 작업 후
git add .
git commit -m "feat: Initial project setting"
git push origin feature-project-init

// Develop 브랜치에서 merge
git pull origin feature-project-init

develop 브랜치 (Dev)

develop 브랜치는 말 그대로 개발 브랜치이다. 여러 feature 브랜치 내용들이 병합된 작업물이다.

release 브랜치 (QA)

develop 브랜치의 내용을 release 브랜치에서 검증한다. 검증 브랜치로, 최종 배포인 main 브랜치에 가기 전 통합 테스트를 진행한다.

그런데 만약 검증 단계인 release(QA) 브랜치에서 버그나 문제가 생겼다면 어떻게 해야할까? 이 때는 main(Prod)으로 바로 직행하지 않고 develop으로 돌아가야한다. (롤백)

이처럼 롤백에서는, develop에서 수정된 내용을 다시 release에 병합 하는 검증 과정을 문제가 모두 해결될 때까지 반복한다.

이런 과정이 첫 번째였다면 알파 테스트, 두 번째였다면 베타 테스트 등으로 부른다.

main 브랜치 (Prod)

이제 마지막 브랜치 main이다. 실제 운영 환경 브랜치로 최종 배포만 이뤄지는 곳이다.

실제로 나의 경우, 터미널에서 bastion 서버를 거쳐 실제 배포 서버(ssh)로 들어가 develop (release는 생략) 브랜치의 내용을 main 브랜치로의 병합하는 과정을 경험할 수 있었다.

main에 반영하는 방법은 크게 두 가지이다.

1. 운영 서버에서 수동 배포하기

main 브랜치에서 git pull origin develop을 통해 병합(merge)하면 되는데, 코드 충돌이 발생하면 터미널에서 수동으로 해결해야한다는 번거로움이 있다.

2. Git Action 활용하기

정확히는 프로젝트 GitHub에 들어가 develop에서 main으로 pull하게끔 PR(pull request)을 날려 수동 배포하는 것이다.

이때 develop 기능을 main 반영에 반영할 때 Git Actions의 CI/CD 및 CodeDeploy가 쓰일 수 있다.

CI/CD 자동 배포로, Git Action이 CI/CD 파이프라인을 자동으로 실행시키기에 PR만 날려주면 직접 1번과 같은 명령어 입력 없이 배포(main 브랜치에 최종 반영)가 가능하다.

Git Action을 활용한 CI/CD 방법은 추후 다시 정리해보겠다!

추가로 배포 서버 내에서 변경된 rds DB 스키마를 수정하는 등의 작업도 하기도 했다.

추가로, 이렇게 각 브랜치 업데이트별로 버전을 붙이는 작업을 Tagging이라 하는데, Tag는 각 개발 시점의 버전을 맞춰 기록하기 위해 쓰인다.

그런데 다시 위 사진을 보면 develop, release 브랜치와 main 브랜치의 버전이 조금씩 차이가 나는 걸 확인할 수 있다.

만약 계속 반복적으로 이뤄지는 펜딩(release ↔ main, 검증 후 수정과 merge 반복)이 있었다면, release와 develop 사이에서는 계속해서 새로운 각 커밋의 release note 버전이 존재할 것이다.

main 브랜치에는 검증하여 최종적으로 통과된 버전만 올라가게 해야하므로, 버전이 사진과 같이 순차적이지 않을 수 있다!

(ex. v1.0.0 → v1.3.2)

* 숫자 차이가 클수록 QA 후 배포하려는 과정에서 엄청난 핑퐁이 있었다고 생각하면 된다고 한다..

다시 정리해보자면 아래와 같다

작업 순서 (feature → dev → release → main) & Tagging

feature(개인 개발용, 사진 상 dev 브랜치 왼쪽 가생이들) 브랜치에서 작업 후 dev 브랜치로 병합
여러 feature들이 모인 dev를 release(검증용)으로 병합(merge)
- release note - 비개발자들이 볼 수 있는 documentation, 깃헙 형식이 아닌 파일 형식
(ex. release note (v1.0.0))
검증 통과 시 최종적으로 main에도 push
(ex. main branch (v1.1.0))

develop, release, main 3개 브랜치가 모두 동일한 버전, 같은 커밋( = 한 release note 기준으로 굴러가기)으로 관리하는 과정은 중요하기에 relelase note도 필수다.

+ Git 유의사항 (pull & merge)

추가로 내 작업이 있는 feature 브랜치에서 develop 브랜치로 push하기 전에 develop에서 다른 사람들의 작업이 추가되었다면, feature 브랜치에서 develop의 내용을 가져와 합친 후 (혹시 충돌 내용이 있다면 고쳐야함) develop으로 push할 수 있다.
하지만 아래처럼 에러가 발생하기도 했다.

 * branch            develop    -> FETCH_HEAD
힌트: You have divergent branches and need to specify how to reconcile them.
힌트: You can do so by running one of the following commands sometime before
힌트: your next pull:
힌트: 
힌트:   **git config pull.rebase false  # merge**
힌트:   git config pull.rebase true   # rebase
힌트:   git config pull.ff only       # fast-forward only
힌트: 
힌트: You can replace "git config" with "git config --global" to set a default
힌트: preference for all repositories. You can also pass --rebase, --no-rebase,
힌트: or --ff-only on the command line to override the configured default per
힌트: invocation.
fatal: Need to specify how to reconcile divergent branches.
```

이 메시지는 git pull 전략을 설정하지 않아서 나오는 것인데, 위에서 나오는 pull 전략 3가지에 대해 정리해보겠다.

Git pull 전략 3가지

1. ⭐️ (merge) git config pull.rebase false (= git merge develop)
: 기본적인 merge

협업, 팀 프로젝트에서 많이 쓰이는 기본 전략
아래와 같이 커밋 히스토리에도 Merge branch 'develop' into feature/... 같은 merge commit이 남는다.

*   f7a3d45  ← merge commit (feature와 develop 병합)
|\
| * d43c123  ← feature 브랜치 작업 ⬆️
|/
* 53d8210  ← develop 최신 ⬆️

히스토리 추적이 쉽고, 변경 흐름이 명확히 드러난다.
여러 명이 같은 브랜치 작업할 때 나는 충돌 관리(한 번에 처리)도 쉽다.

2. (rebase) git config pull.rebase true (= git rebase develop)
: 커밋 히스토리를 깔끔하게 정리

개인 작업용 브랜치 정리할 때 좋음, 팀에서는 신중하게 써야 함 (충돌 추적이 어려워질 수도 있어서) 난이도 ⬆️
커밋 히스토리가 일직선으로 깔끔해진다.
병합 커밋(merge commit)이 생기지 않는다.

* d43c123  ← feature 커밋 (rebase 후 새로 생성됨)
* 53d8210  ← develop 최신 ⬆️

충돌이 났을 때도 해결해야 하지만(커밋마다 처리), Git이 "이 커밋은 어디서 왔는지" 파악하기 어려울 수 있음
(충돌 발생 시 rebase 명령어로 새 커밋을 만들어 해결)

git rebase develop

# 충돌 발생
# 수정 후
git add .

# 다음 커밋으로 계속 진행
git rebase --continue

# 또 충돌? 똑같이 반복
git add .
git rebase --continue

# 만약 중단하고 싶으면
git rebase --abort

3. (fast-forward only) git config pull.ff only: 커밋 충돌이 없는 경우에만 진행

위에서 말했듯이 feature 브랜치에서 업데이트 된 develop의 내용을 가져와 합친 후 충돌 내용이 있다면 고쳤어야했기에,

즉 내가 한 git pull은

merge 후 conflict 해결

= git config pull.rebase false

= git fetch develop + git merge develop 이었다.

결론적으로 작업 시 다음과 같은 전략을 쓰는 것이 좋다.

// feature에서 작업하고
git add .
git commit -m "feat: XXX 기능 추가"
git push origin feature/XXX

// 만약 feature 브랜치에서 develop merge
git checkout feature/XXX
git config pull.rebase false    # merge 전략으로 설정
git pull origin develop 
git push origin feature/XXX     # 충돌 해결 사항도 포함해서 push

// develop <- feature PR 보내기

[Spring Security] 401 에러, PasswordEncoder를 써야하는 진짜 이유 / SecurityContext 내 UsernamePasswordAuthenticationToken의 원리

jimddong — Tue, 25 Mar 2025 19:46:37 +0900

Spring Security를 토대로 로그인을 구현하기 앞서, 우선 로그인용 필터를 사용한 로직을 구현하려 했다.

SecurityContext 내의 Authentication 객체를 만드는 과정을 구현한 필터를 만드는 것인데, 나는 form 로그인 대신 추후 json으로 로그인하여 JWT를 활용하는 것이 목표였기에 기본적인 로그인 로직만 UsernamePasswordAuthenticationFilter에서 가져와 변형하여 코드를 짰다.

username과 password를 입력받을 LoginRequestDTO, Authentication 객체를 생성하는 LoginFilter, Authentication-UsernamePasswordAuthenticationToken 내의 Principal 객체에서 쓰일 유저의 정보(username, password)를 담을 UserDetails와 UserDetailsService의 구현체 등을 구현했다.

참고로 Authentication 인터페이스에 속하는 UsernamePasswordAuthenticationToken 객체를 만드는 과정을 구현했다.
위 사진처럼 Authentication 객체는 SpringContextHolder 안의 SpringContext에 보관된다.

SpringContextHolder: 인증된 사용자들의 세부사항을 저장하는 곳, 현재 실행 중인 스레드(Thread)에서 SecurityContext를 관리하는 역할
SpringContext: Spring Security에서 로그인 후 인증이 완료되면 Authentication 객체가 저장 되는 보관소
Authentication (인터페이스) 구성 요소 3가지
- Principal: 유저 정보를 담은 객체 = UserDetails 인스턴스 (username, password)
- Credentials: 증명 (비밀번호, 토큰)
  - Principal이 올바른지 입증하는 객체, 보통 비밀번호를 저장한다.
  - 증명 후에는 유출 방지를 위해 비워짐
- Authorities: 유저의 권한(ROLE) 목록을 저장한다.
  - authorities 요소들 = GrantedAuthority(혹은 구현체의) 객체들
    (Authentication.getAuthorities()로 구할 수 있음.)

하지만 이후 코드를 실행시켜 Postman으로 로그인을 시도하니 처음에는 다음과 같은 에러가 떴다.

401 Unauthorized 에러가 뜬 것이다.

401 에러란 즉슨... 인증이 되지 않았다는 것인데, 코드를 디버깅해보니 Authentication 객체가 아예 생기지도 않았었다.

이유가 뭘까?

PasswordEncoder

PasswordEncoder는 비밀번호를 암호화하는 기능을 하는 인터페이스로, 해시함수를 사용해 encode()를 할 수 있다. 또한 encoded 된 비밀번호와 요청으로부터 전달받은 비밀번호가 일치하는지 확인하는 matches()나 추가적인 암호화 메서드도 사용할 수 있다.

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

이와 같은 내용으로 SecurityConfig 클래스 안에 빈 등록하여 PasswordEncoder로 쓸 수 있다. (bcrypt 사용)

하지만 앞선 코드에서 나는 회원 가입 로직에서 다음과 같이 PasswordEncoder를 일절 사용하지 않았었다.

@Service
@RequiredArgsConstructor
public class MemberServiceImpl implements MemberService {

    private final MemberRepository memberRepository;

    @Override
    public Member createMember(MemberRequestDTO.JoinDTO joinDTO) {
        Member member = MemberConverter.toMember(joinDTO);
        return memberRepository.save(member);
    }
}

일단 회원가입 된 유저가 로그인을 시도하면 username과 password를 받아 Authentication 객체를 생성시켜 로그인이 되는 과정을 만들어보고 싶은 마음이 앞섰다. 하지만 이내 이 과정에서 반드시 PasswordEncoder가 필요함을 깨달았다. 왜지? 단순히 보안을 위해서?

사실 핵심은 바로 내가 Authentication 객체로 사용한 UsernamePasswordAuthenticationToken을 발급하기 위한 과정에 있었다.

LoginFilter 코드

@Getter
public class LoginRequestDTO {

    private String email;

    private String password;
}

@RequiredArgsConstructor
public class LoginFilter extends UsernamePasswordAuthenticationFilter {

    private final AuthenticationManager authenticationManager;

    @Override
    public Authentication attemptAuthentication(HttpServletRequest request, HttpServletResponse response)
            throws AuthenticationException {
        LoginRequestDTO loginRequestDTO = readBody(request);
        UsernamePasswordAuthenticationToken usernamePasswordAuthenticationToken = UsernamePasswordAuthenticationToken.unauthenticated(loginRequestDTO.getEmail(),
                loginRequestDTO.getPassword());

        return authenticationManager.authenticate(usernamePasswordAuthenticationToken);
    }

    public LoginRequestDTO readBody (HttpServletRequest request) {
        ObjectMapper om = new ObjectMapper();

        try {
            return om.readValue(request.getInputStream(), LoginRequestDTO.class);
        } catch (IOException e) {
            throw new AuthHandler(ErrorStatus._BAD_REQUEST);
        }
    }
}

내가 짠 코드는 위와 같았다. (username과 password를 json으로 받아 이를 토대로 인증 객체를 만드는 과정, JWT 구현 제외)

내가 로그인 필터를 구현할 때 참고한 메서드는 UsernamePasswrdAuthenticationFilter의 attemptAuthentication()이다.

LoginFilter를 보면 클라이언트 요청 request를 토대로 username(email), password를 필드로 하는 LoginRequestDTO 클래스의 객체로 변환했다. 이 내용을 토대로 UsernamePasswordAuthentiationToken을 만든다.

UsernamePasswordAuthenticationFilter의 로직

이때 코드와 그림에서도 볼 수 있듯이, AuthenticationManager가 관여한다. 이 안의 DaoAuthenticationProvider라는 인터페이스는 인증 객체인 UsernamePasswordAuthenticationToken을 처리하는데, 여기서 PasswordEncoder가 필요했던 이유를 파악할 수 있다.

자세히 알아보자!

AuthenticationManager의 원리

AuthenticationManager

SecurityContextHolder에 있는 Authentication이 나오게끔 혹은 만들어지게끔 인증을 도와주는 인터페이스다.

❗️ 반드시 SecurityConfig에 AuthenticationManager 등록해 주기!

→ 그렇지 않으면 Spring Security가 SecurityContext 내에 있는 Authentication 객체를 인증 처리해 줄 AuthenticationManager가 선언되지도 않았기에, 작동할 수도 없고 Authentication(- 안의 Principal - 안의 UserDetails까지 모두)이 생기지 않는다.

* 만약 AuthenticationManager를 등록해주지 않으면, 직접 구현한 UserDetailsService(PrinicipalDetailsService)를 호출할 수 없기에 결국 인증 과정을 처리할 수도 없음 → SecurityContext에 Authentication 객체가 만들어지지 않아 에러

AuthenticationManager의 가장 흔한 구현체는 ProviderManager이다.

ProviderManager는 여러 AuthenticationProviders를 List로 선언한다.

AuthenticationManager가 모든 AuthenticationProvider를 반복문으로 돌려 인증을 확인한다.

DaoAuthenticationProvider

위 AuthenticationProvider의 구현체 중 하나가 DaoAuthenticationProvider다. DaoAuthenticationProvider는 UsernamePasswordAuthenticationToken을 처리한다.

사진에서 볼 수 있듯이 username과 password를 인증화하기 위해 DaoAuthenticationProvider는 UserDetailsService와 PasswordEncoder(필수!!)를 사용한다.

그런데 만약 회원 가입 코드에서 PasswordEncoder를 사용하지 않았다면, 회원 가입 시 입력된 비밀번호가 그대로 데이터 베이스에 저장될 것이다. DaoAuthenticationProvider는 PasswordEncoder.matches()를 사용해 비밀번호 검증을 수행하는데, 데이터베이스에 저장된 값이 암호화되지 않은 상태라면 비교에 실패하게 된다. 따라서 비밀번호 검증이 실패하여 인증 객체(Authentication)가 생성되지 않고 로그인도 실패한다.

DaoAuthenticationProvider 입장에서는 인증 객체(토큰)를 발급하려는데, 요청으로 받은 password를 PasswordEncoder로 암호화하여 matches()로 비교해보려 해도, 애초에 회원 가입 코드에서 (MemberServiceImpl의 createMember() 참고) 멤버의 비밀번호가 PasswordEncoder.encode()를 통해 암호화가 되지도 않았으니 요청으로 입력 받은 비밀번호와 이가 일치하는 비밀번호인지 비교할 수가 없을 것이다.

결론은 인증 객체(Authentication, UsernamePasswordAuthenticationToken)를 만들어 SecurityContext 내에 저장하고 싶다면 반드시 유저 생성 시 PasswordEncoder로 비밀번호를 반드시 암호화시켜줘야 한다!

회원 가입 로직에 PasswordEncoder로 비밀번호 암호화 과정 추가 (MemberServiceImpl, MemberConverter)

@Service
@RequiredArgsConstructor
public class MemberServiceImpl implements MemberService {

    private final MemberRepository memberRepository;
    private final PasswordEncoder passwordEncoder;

    @Override
    public Member createMember(MemberRequestDTO.JoinDTO joinDTO) {
        Member member = MemberConverter.toMember(joinDTO, passwordEncoder);
        return memberRepository.save(member);
    }
}

public class MemberConverter {

    public static Member toMember (MemberRequestDTO.JoinDTO joinDTO, PasswordEncoder passwordEncoder) {
        return Member.builder()
                .email(joinDTO.getEmail())
                .password(passwordEncoder.encode(joinDTO.getPassword()))
                .signUpType(joinDTO.getSignUpType())
                .role(joinDTO.getRole())
                .build();
    }
}

UserDetails, UserDetailsService

참고로 DaoAuthenticationProvider에 의해 사용되는 UserDetailsServices가 username과 password 등을 가진다. UserDetailsService가 반환하는 것이 UserDetails이며, UserDetailsService와 UserDetails 인터페이스를 구현해 주는 PrincipalDetailsService와 PrincipalDetails를 다음과 같이 작성했다.

@RequiredArgsConstructor
public class PrincipalDetails implements UserDetails {

    private final Member member;

    // 역할들
    @Override
    public Collection<? extends GrantedAuthority> getAuthorities() {
        List<String> roleList = new ArrayList<>();
        roleList.add("ROLE_" + member.getRole().name());
        Collection<? extends GrantedAuthority> authorities = roleList.stream()
                .map(SimpleGrantedAuthority::new)
                .collect(Collectors.toList());

        return authorities;
    }

    @Override
    public String getPassword() {
        return member.getPassword();
    }

    @Override
    public String getUsername() {
        return member.getEmail();
    }
}

@Service
@RequiredArgsConstructor
public class PrincipalDetailsService implements UserDetailsService {

    private final MemberRepository memberRepository;

    @Override
    public UserDetails loadUserByUsername(String email) throws UsernameNotFoundException {
        Member member = memberRepository.findByEmail(email).orElseThrow(() -> {
            throw new MemberHandler(ErrorStatus._NOT_FOUND_MEMBER);
        });

        return new PrincipalDetails(member);
    }
}

정리

다시금 정리해 보자면 UsernamePasswordAuthenticationToken이 SecurityContext 내에 보관되는 구체적인 과정은 다음과 같다.

UsernamePasswordAuthenticaitonFilter 같은 필터(나는 LoginFilter로 상속 받아 구현했다.)는 AuthenticationManager에게 토큰을 건네준다.
AuthenticationManager의 구현체, ProviderManager, 이것에 의해 선언 된 AuthenticationProvider들의 구현체 DaoAuthenticationProvider
DaoAuthenticationProvider에서는 UserDetailsService에서 UserDetails(username, password)들을 파악
PasswordEncoder가 이 UserDetails의 비밀번호를 검증 ( ⇒ UserDetailsService로 사용자 조회, PasswordEncoder로 비밀번호 검증 - 기존의 비밀번호와 비교 시 PasswordEncoder.matches()로)
최종적으로 토큰이 필터에 의해 SecurityContextHolder에 설정됨

코드를 짤 때 역시 중요한 건 작동 원리를 알아야 한다는 것을 재차 깨달았다. 그냥 '아 PasswordEncoder 없으면 인증 안 되는구나' 하고 넘어갈 수도 있었겠지만, 왜?라는 질문을 던지면서 Spring Security의 전반적인 구조와 필터의 원리까지 세세하게 살펴볼 수 있었다.

특히 도움 됐던 점은 스프링 공식 문서를 살펴보며 개념을 정리해 가며 공부했다는 것! 교환 학생 다녀오길 잘했다(?)

앞으로도 의문이 생기면 끊임없이 질문하고 탐구하는 자세를 잃지 말자!

참고 자료

https://docs.spring.io/spring-security/reference/servlet/authentication/passwords/dao-authentication-provider.html#servlet-authentication-daoauthenticationprovider

[BOJ] 1966번 - 프린터 스택 (Java)

jimddong — Fri, 7 Mar 2025 17:08:49 +0900

https://www.acmicpc.net/problem/1966

이 문제는 사용자에게 문서들의 중요도와 출력 순서를 알고 싶은 특정 문서를 입력 받아, 그 문서가 출력물들 중에서 몇번째로 나올지 알려주는 코드를 짜야했다.

중요한 점은 문서열 큐에서 가장 앞에 있는 것을 빼낼 때, 가장 앞의 것의 중요도보다 더 큰 것이 열에 존재한다면 앞의 것을 제일 뒤로 add해야한다는 것이다.

코드 1) 출력 순서를 알고 싶은 특정 문서의 위치를 기억하기 위해 큐에 0 삽입

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.LinkedList;
import java.util.Queue;
import java.util.StringTokenizer;

public class Main {

    // 어떻게 원래 위치를 저장하는가? <- 문제

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        int testCase = Integer.parseInt(br.readLine());
        StringBuilder result = new StringBuilder();

        for (int i = 0; i < testCase; i++) {
            StringTokenizer documents = new StringTokenizer(br.readLine());
            StringTokenizer importance = new StringTokenizer(br.readLine());

            int num = Integer.parseInt(documents.nextToken());
            int test = Integer.parseInt(documents.nextToken());

            Queue<Integer> queue = new LinkedList<>();

            // 큐에 중요도 넣기
            for (int j = 0; j < num; j++) {
                queue.add(Integer.parseInt(importance.nextToken()));

                // test 위치 확인용 0 삽입
                if (j == test)
                    queue.add(0);
            }

            // 출력 순서 확인
            result.append(checkPrintSeq(queue)).append("\n");
        }

        System.out.print(result);
    }

    static String checkPrintSeq (Queue<Integer> q) {
        int max = 1;
        int count = 0;
        int qSize = q.size();

        // 초기 max 중요도 확인
        for (int i = 0; i < qSize; i++) {
            if (q.peek() > max)
                max = q.peek();

            q.add(q.poll());
        }

        while (true) {
            if (q.peek() < max)
                q.add(q.poll());

            // 중요도 max인 요소 만났을 때 빼기
            else {
                q.poll();
                count++; // 빠진 순서

                // 바로 다음이 0이라면 종료
                if (q.peek() == 0)
                    break;

                // 요소가 빠졌다면 중요도 다시 확인
                max = 1;
                qSize = q.size();

                for (int j = 0; j < qSize; j++) {
                    int top = q.poll();

                    if (top > max)
                        max = top;

                    q.add(top);
                }
            }
        }

        return Integer.toString(count);
    }
}

일단 코드 짜기에 앞서 가장 고민 했던 것은 '어떻게 사용자가 알고자 하는 문서의 위치를 기억하느냐?'였다. 큐에서 poll, add가 반복되면서 특정 문서의 위치도 변화하기 때문이다.

그래서 사용한 것이 구별되는 숫자를 그 문서 바로 다음에 넣어 위치를 파악하는 방법이다. 문서의 중요도는 1 이상 9 이하의 정수이므로 이와 구별되는 0을 이용했다.

하지만 이보다 더 간단하고 좋은 방법이 있었다!

코드 2) Priority Queue 활용하기

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.*;

public class Main {
    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        int testCase = Integer.parseInt(br.readLine());
        StringBuilder result = new StringBuilder();

        for (int i = 0; i < testCase; i++) {
            StringTokenizer documents = new StringTokenizer(br.readLine());
            int N = Integer.parseInt(documents.nextToken());
            int M = Integer.parseInt(documents.nextToken());

            StringTokenizer importance = new StringTokenizer(br.readLine());
            Queue<int[]> queue = new LinkedList<>(); // 1차원 배열에 (중요도, 위치) 이렇게 삽입
            // 우선 순위 큐 내림차순으로 (오름차순이 기본 설정)
            PriorityQueue<Integer> priorityQueue = new PriorityQueue<>(Collections.reverseOrder()); // 중요도 순으로 요소 꺼낼 때 활용

            for (int j = 0; j < N; j++) {
                int priority = Integer.parseInt(importance.nextToken());
                queue.add(new int[]{priority, j});
                priorityQueue.add(priority);
            }

            int count = 0;
            while (!queue.isEmpty()) {
                int[] current = queue.poll();
                if(current[0] == priorityQueue.peek()){
                    count++;
                    priorityQueue.poll();

                    if (current[1] == M) {
                        result.append(count).append("\n");
                        break;
                    }
                }

                else {
                    queue.add(current);
                }
            }
        }

        System.out.print(result);
    }
}

일반적으로 큐에서 요소를 꺼내거나 확인할 때 (poll, peek) 가장 앞의 요소가 반환된다. 하지만 Priority Queue, 우선 순위 큐는 큐의 요소를 꺼낼 때 가장 우선 순위가 높은(가장 작거나 큰, 기본은 오름차) 요소를 꺼낸다.

그럼 이 우선순위 큐를 어떻게 이용한다는 걸까?

일단 기본 큐 요소를 1차원 배열로 하여, 입력 받은 문서의 중요도와 큐에서의 처음 위치를 함께 넣는다. 그리고 Priority Queue에는 중요도만 넣는다.

앞서 문제 설명에서 큐에서 요소를 하나씩 출력하려 할 때 뒷 요소들 중 중요도가 더 큰 것이 있다면 그 요소(제일 앞 요소)를 가장 뒤로 보낸다고 했다. 이 말은 즉슨 결국에 문서를 중요도가 큰 순으로 출력하겠다는 것이므로, 큐에서 꺼낸 문서의 중요도와 PriorityQueue에서 peek를 한 값(중요도)이 같다면 출력하면 되는 것이다.

특정 문서가 몇 번째로 출력되는지 계산하기 위해서는 count 값을 문서가 빠져나갈 때마다 증가시켜주고, 문서의 기존 순서 값이 원래 찾으려던 문서의 순서 값과 같다면 반복문을 멈춘다.

Priority Queue

삽입되는 순서와 상관 없이 큐 요소를 우선 순위가 높은 순으로 삭제시켜 주는 자료구조이다.
Priority Queue는 기본적으로 삭제 시 오름차순으로 요소를 꺼낸다.

만약, 내림차순으로 이용 시 Collections.reverseOrder()를 사용한다. (이는 Comparator의 일종)

PriorityQueue<Integer> priorityQueue = new PriorityQueue<>(Collections.reverseOrder());

항상 큐에서 특정 요소의 위치를 어떻게 기억하나 싶었는데, 오늘 문제와 같이 기존 순서를 따로 또 저장해주는 방법을 활용할 수 있겠다 생각했다. 또한 Priority Queue를 처음 접했는데, 우선순위에 따라 가장 먼저 요소를 꺼내야한다는 조건 등이 있을 때 사용하도록 잘 익혀놔야겠다.

[Spring] 예상치 못한 JSON 필드 추가? - Lombok과 Jackson 직렬화 문제 해결

jimddong — Sun, 16 Feb 2025 12:39:48 +0900

응답 통일을 위해 DTO, BaseCode, 성공 시 응답 처리 등을 코드로 작성했었다.

* 응답 통일을 해야하는 이유

내 생각: 데이터가 전달될 때 일정한 형식으로 오고 가야 CRUD 기능 내 메소드가 처리될 수 있고, 프론트단에서도 일정한 형식으로 (json 등) 제대로 정보를 받고 다시 보낼 데이터의 형식도 맞추는 등 쉽게 처리할 수 있다. 꼭 응답 통일 코드 작성을 잊지 말자!

응답의 형식을 담을 BaseResponse 코드를 대략 아래와 같이 짰었다.

@Getter
@AllArgsConstructor
@JsonPropertyOrder({"isSuccess", "code", "message", "result"})
public class BaseResponse<T> {

    @JsonProperty("isSuccess")
    private final boolean isSuccess;
    private final String code;
    private final String message;
    @JsonInclude(JsonInclude.Include.NON_NULL)
    private T result;

    public static <T> BaseResponse<T> onSuccess(T result) {
        return new BaseResponse<>(true, SuccessStatus._OK.getCode(), SuccessStatus._OK.getMessage(), result);
    }
	.
    .
    .
}

보다시피 내가 json으로 변환 시키고 싶은 자바 필드는 isSuccess, code, message, result 이다.

근데 TestController를 실행 시켜 onSuccess의 결과를 localhost:8080에서 확인 했을 때 다음과 같은 결과가 나왔다.

{ "isSuccess": true, "code": "COMMON200", "message": "성공입니다.", "result": "성공 응답 테스트 - 성공!",
"success": true }

내가 추가시키지도 않은 success라는 값이 추가된 것!

이렇게 Java 객체를 JSON으로 변환할 때 예상과 달리 나올 때를 JSON 직렬화 문제라고 한다.

(참고로 반대로 JSON에서 Java 객체로 변환시키는 것은 역직렬화라고 한다.)

왜 이런 문제가 발생했을까?

Lombok의 @Getter와 Jackson의 원리

문제를 해결하려면 내가 어노테이션으로 붙인 @Getter와 Jackson에 대해서 생각해봐야한다.

Lombok의 @Getter는 자동으로 각 필드에 대한 getter 메서드를 자동 생성해준다.
(ex. 내 코드에는 code, message라는 필드가 있기에 getCode, getMessage 등이 되겠다.)

그런데 @Getter가 boolean 타입의 필드를 가지고 getter 메서드를 만들 때는 getXXX()가 아니라 isXXX()를 이름으로 한 메서드를 생성시킨다. 내 코드의 경우, isSuccess가 boolean 타입이었기에 다음과 같이 자동으로 getter가 만들어졌을 것이다.

public boolean isSuccess() { return isSuccess; }

이제 자바에서 json 변환할 때 getter 메서드를 탐색하여 json 필드를 결정해주는 도구, Jackson이 사용된다.

Jackson은 getter 메서드 이름을 json키로 사용하기에 is 제외 success를 필드로 간주해 json으로 자동 변환한다.

따라서 json 형식 응답을 확인 했을 때, 우리가 원하는 isSuccess뿐만 아니라 success도 추가로 생기는 위와 같은 문제가 생긴 것이다.

* 참고로 Jackson은 자바 객체 -> json 변환 시 이용되는 도구일뿐, 단순 데이터 타입 json과는 다르다!

해결

@JsonIgnore는 Jackson이 해당 필드를 자동 변환하지 않도록(직렬화에서 제외) 막을 수 있는 어노테이션이다.

Lombok이 @Getter로 자동 생성 시켜주는 isSuccess() 대신, 직접 명시적으로 getter 메서드를 적어주고 그 위에 @JsonIgnore 어노테이션을 붙여주자.

@JsonIgnore
public boolean isSuccess() { return isSuccess; }

public static <T> BaseResponse<T> onSuccess(T result) {
        return new BaseResponse<>(true, SuccessStatus._OK.getCode(), SuccessStatus._OK.getMessage(), result);
    }
    
// 필드 값을 초기화하는 것

이렇게 하면 isSuccess 값은 우리가 직접 정의한 getter를 통해 가져오고, 나머지(code, message, result)는 Lombok이 자동 생성한 getter를 통해 JSON으로 변환된다.

처음에는 '뭐지? 갑자기 난데 없는 success가 어디서 생긴거지? success라는 걸 내가 어딘가 넣었었나' 해서 당황스러웠다. 하지만 문제 해결을 위해 찾아보다 내가 무심코 쓰고 있던 어노테이션이 이런 원리를 하고, 거기서 json 변환에 Jackson이라는 도구가 이용된다는 사실을 알게 되었다.

역시 각 도구들이 어떤 기능을 하는지 원리를 알아야함을 뼈저리게 깨달았다. 앞으로도 궁금하거나 잘 모르는 어노테이션, 도구가 등장하면 꼭 원리를 익히고 사용해야겠다고 다짐했다!

[BOJ] 4949번: 균형잡힌 세상 (Java)

jimddong — Thu, 13 Feb 2025 21:24:53 +0900

https://www.acmicpc.net/problem/4949

이 문제는 소괄호와 대괄호가 짝이 맞게, 올바른 순서로 이루어져 있는지 확인하는 문제다.

처음 문제를 접했을 때, 주어진 문장을 한 글자씩 검사하여 괄호가 등장하면 큐나 덱에 push하고 그 후 괄호가 잘 구성되어 있는지 검사하려 했다.

시도 1) 큐에 괄호들 push 후 큐 검사

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.ArrayDeque;
import java.util.ArrayList;
import java.util.Deque;

public class BOJ_4949_1 {
    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));

        String st = "";
        ArrayList<String> result = new ArrayList<>();

        // . 입력 전까지 문자열 입력
        do {
            st = br.readLine();
            Deque<Character> sentence = new ArrayDeque<>();

            if(st.equals("."))
                break;

            else {
                for (char c : st.toCharArray()) {
                    if (c == '(' || c == ')' || c == '[' || c == ']' || c == '.')
                        sentence.add(c);
                }
            }
            result.add(checkBalance(sentence));

        } while(true);

        while (!result.isEmpty())
            System.out.println(result.remove(0));
    }

    static String checkBalance(Deque<Character> dq) {
        char first, second = ' ';
        int count = 0;

        do {
            first = dq.poll();

            if(first!='.') second = dq.peek();

            if(((first=='(' && second==')') || (first=='[' && second==']'))){
                second = dq.poll();
            }

            else {
                dq.add(first);
            }

            if (dq.size() == 3)
                count++;

            if (count == 4) break;

            if (dq.size() == 1 && dq.peek() == '.') break;

        } while(true);

        if (dq.size() == 1) return "yes";

        else return "no";
    }
}

~~코드가 딱 봐도 길다...~~

처음에 내가 코드를 짠 기준은 다음과 같았다.

우선 문장에는 .도 함께 포함된다.

가장 첫 요소를 pop()하고 두 번째 것을 peek()하여 비교했을 때 ( 와 ) 혹은 [ 와 ] 로 짝이 맞는다면 두 번째 것도 역시 pop을 해준다. 하지만 pop한 첫 번째 요소가 다음 요소와 짝이 맞지 않는다면, 첫 번째 것을 제일 뒤로 add 해준다.

이러한 과정을 큐에 . 만 남고 괄호가 모두 pop 되어 없어질 때까지 반복한다.

백준 사이트에서 제공된 예제 입력을 콘솔창에 입력했을 때 예제 출력대로 결과가 잘 나와 사실 정답인 줄 알았다...

하지만

틀렸다!

왜일까? 곰곰이 생각해보았다.

<개선점> 괄호의 순서, 구성이 잘못된 경우를 제대로 처리하지 않는다.

불필요한 count 변수를 사용하고 있는 게 문제이다. 일단, 괄호를 pop하고 add하는 걸 계속 반복만 하고 더 이상 괄호가 빠지지 않는다면 불균형적인 괄호 문장으로 판단하여 반복문을 break하고 결과를 "no"로 저장되게끔 하였다. 이 일정 이상의 반복의 기준을 count로 설정했다. 예를 들어 )(. 와 같은 문장이 있을 때, 큐의 길이는 .을 포함해 3이고 이때 pop&add가 4번이나 반복 되어 count++이 총 4번 반복 되면, 이 이상 반복해도 큐에서 빠지는 괄호가 없기에 같은 과정이 반복되기만 하는 불균형 문장으로 판단할 수 있다. 얼핏 보면 괜찮다고 생각했는데, 이 당시에 저 예시에 홀린 것인지... '큐 길이가 3인 상태가 4번이나 반복되면 불균형 문장!' <- 이렇게 생각하며 논리의 오류를 남발했다... 허허

하지만 우리는 ( [ ) ] 와 같은 불균형적인 괄호 문장도 판단해내야한다.

지금 생각해보면 큐의 균형 여부는 당연히 큐의 길이(처음에는 괄호는 짝이 맞아야하니까 짝수, 홀수 이런 것도 떠올려보기도 했지만...)와는 관련이 없고, 가장 중요하게도 괄호 순서에 초점을 두어야한다.

예외가 있으면 안 되니까 다양한 입력 예시를 모두 생각하고 고려해보며 코드를 짜야함을 또 명심했다.

시도 2) (최종 코드) 스택을 이용하기

괄호 순서에 유의하며 스택을 이용한 코드로 바꿨다.

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.Stack;

public class BOJ_4949_2 {

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        String st = "";
        StringBuilder sb = new StringBuilder();

        while (true) {
            st = br.readLine();

            if (st.equals(".")) break;

            if (isBalanced(st))
                sb.append("yes\n");

            else sb.append("no\n");
        }
        System.out.println(sb);
    }

    public static boolean isBalanced(String st) {
        Stack<Character> stack = new Stack<>();

        for (char c : st.toCharArray()) {
            if (c == '(' || c == '[')
                stack.push(c);

            else if ((c == ')' || c == ']')) {
                if (stack.isEmpty())
                    return false;

                else {
                    char top = stack.pop();

                    if ((top == '(' && c != ')') || (top == '[' && c != ']'))
                        return false;
                }
            }
        }
        return stack.isEmpty();
    }
}

생각보다 더욱 간단한 로직으로 풀 수 있는 문제였다.

추가적으로 달라진 점이 있다면, 앞선 코드에서는 문장의 모든 괄호 (,[,),], .을 덱(deque)에 다 넣고 나서 균형한지 판단했지만, 이번에는 순차적으로 스택에 ( 과 [ 만 넣으면서 동시에 균형한지 판단(짝이 맞으면 pop)한다는 것이다.

그리고 )이나 ] 이 나오면 스택 안의 top 요소- ( 또는 [ - 를 꺼내 비교하고, 짝이 맞지 않는다면 false를 반환해 no가 출력되게 하는 것이다. 괄호 검사 반복문을 마쳤을 때는 stack.isEmpty()의 결과를 반환해 스택이 모두 비었다면 true, 즉 균형 있는 스택, 스택에 아직 요소가 있다면 false, 불균형 스택이 된다.

문제를 봤을 때 pop, push가 있는 스택, 큐나 덱을 써야겠다고 생각은 했고, 모든 요소를 넣어야 판별이 될거라 처음에는 생각했다. 그래서 코드가 복잡해지고 count 변수도 생기고 했었다... 하지만 이 문제에서는 모든 괄호를 넣는 게 아니라 시작 괄호들만을 넣고 끝 괄호와 비교해서 스택에서 요소들을 pop 한다는 발상이 나에게는 새로웠다.

그리고 다양한 예시, 예외 상황을 눈흐릿..하며 무시하지 말고 귀기울이자고 다짐했다. "여기선 이 논리가 당연하겠지~"라며 어물쩡 넘어 갔던 사소한 부분들로부터 예외 상황을 고려하지 못한 코드를 낳는다는 점을 명심하며...

나의 부족한 점을 깨달을 수 있는 문제였다!

[Spring/클론 코딩] todo mate를 따라 만들어보자(1) - IA와 데이터베이스 ERD 설계

jimddong — Fri, 24 Jan 2025 23:12:54 +0900

반년간 교환학생을 다녀온 뒤, 개발에 대한 감각이 많이 무뎌진 것 같다고 스스로 느끼곤 했다.

앞으로 무얼해야할까 고민하다 혼자서 웹/앱 서비스를 구현해보는 건 어떨지 고민하게 되었다. 처음에는 아예 새로운 서비스를 구현해보고자 하는 마음에 우선 내 아이디어에서 시작해보았다.

내가 좋아하고, 만들고 싶었던 걸 떠올리다 나온 것은 '내가 좋아하는 다이어리 꾸미기(다꾸)를 웹이나 앱으로 만들어보자!'었다. 매일 쓴 일기에 그 주변을 꾸미고, 월간 캘린더, 거기다 내가 구현해보고팠던 채팅 기능까지(웹소켓을 공부해보고 싶었기 때문...) 넣으면 어떨지 생각해보았다. 그런데 자꾸만 어쩐지 겹쳐지는 투두 메이트의 잔상...

사실 난 투두 메이트를 굉장히 애용하는 사람이다. 그만큼 내가 투두를 이용하면서 느낀 아쉬운 점도 많았다. 내가 개발자라면.. 이 기능도 괜찮을 것 같은데? 하며 말이다 (ㅋㅋ) 기존의 투두 메이트는 이름 그대로 'mate'에 집중하여 사람들과 소통할 수 있는, 그리고 다른 친구들이 하루 하루 그리고 한 달 동안 성취해내는 체크 리스트를 보면서 나도 자극 받고 열의를 다질 수 있는 어플이라 느꼈다. 하지만 나는 다꾸러(아직 파릇파릇한 다꾸 어린이 수준이지만...)로서 다이어리 꾸미기나 기록에도 집중한 나만의 투두 메이트를 만들어 보고 싶었다 ㅎㅎ

생각했던 추가 기능은 일기나 그 날의 할 일에 자신이 원하는 위치를 넣게끔 하는 기능을 추가하면 어떨지(약속 등은 시간뿐만 아니라 장소도 기록해두면 기억하기 편하니까), 단체 채팅방도 추가하면 어떨지 등등... 또한 가능하다면 다꾸할 수 있게끔 스티커들도 추가해본다든지..였다!

아이디어가 여기 저기 떠돌아다니지만 우선 투두 메이트를 클론 코딩하며 무뎌진 나의 개발 감각을 일깨워보려한다! 그리고 원했던 기능들도 추가할 것이다. 또한 사실 서버 구현말고도 리액트로 웹앱 등까지 욕심 내보고 싶다. 서버 개발자가 되기를 원하지만 프론트 쪽을 너무 몰라도 문제인 것 같다고 부쩍 느끼고 있기 때문... 서버에는 내가 서툰, 안 써본 기술들을 적용해보기도 하고 좀 더 코드를 고민하며 짜보려 한다. 여튼 그만큼 꽤 힘들 것 같기도 하지만, 힘든 만큼 성장할 수 있다 생각하고 최선을 다해 임해보려 한다!

잔말 말고 시작!

IA

개발하기에 앞서 내가 생각한 나만의 투두메이트 IA(Information Architecture)를 그려봤다.

(검색 기능에 친구 그룹을 찾는다든지 하는 다양한 기능들도 있었지만, 나는 친구 아이디로 조회하는 기능만 우선 넣을 것이다.)

구현할 기능 목록

로그인/회원가입 (jwt token)
- 메일, 비번
- 소셜 로그인 (구글, 카카오톡) (OAuth)
피드
- 달력 → 날짜별 할 일 목록
  - 할 일 목록은 카테고리별로 묶어 보여준다.
    - 할 일에는 할 일 내용, 시간, 장소
- 달력 → 날짜별 일기
  - 일기에는 사진, 글, 장소
- 친구 목록
  - 친구를 클릭하면 그 친구의 달력에서 할 일 목록, 일기를 확인 가능
대화 (ws)
- 채팅방: 1:1, 단체
  - 사람, 채팅 내용, 시간
마이페이지
- 할 일 보관함 - 카테고리별로
설정
- 계정
- 로그아웃
- 회원탈퇴

기존에 없던 추가 기능
- 단체 채팅방
- 할 일과 일기에 장소 추가하기 (프론트 지도 api)
추후 구현할 기능
- 일기, 투두 리스트 보여주기 범위 (나만 보기, 특정 팔로워 등)

그리고 위 목록들은 내가 구현할 수 있는 기능들로 정리해보았다. 사실 기존 투두에서는 내가 적은 할 일 리스트나 일기를 나만 보게 하거나 특정 팔로워에게만 보이게 설정할 수 있다. 하지만 우선적으로는 모두에게 보이게끔 권한을 설정하려한다. (나에겐 일단 꽤나 어려울 것 같음...)

데이터베이스 ERD

StarUML 사용

그리고 나서는 IA와 투두 메이트 화면을 와이어프레임 삼아 고민해보며 데이터베이스 erd를 설계했다.

특히 어려웠던 부분은 '팔로잉과 팔로워를 어떻게 erd에서 나타내지?' 였다.

생각한 방법은 크게 두 가지였다.

팔로잉과 팔로워 관리하는 법

아이디어 1) 멤버 엔티티 내의 attribute으로 팔로우, 팔로잉 리스트 만들기

한 유저는 여러 명을 팔로우할 수 있다.
다른 유저도 여러 명을 팔로우할 수 있다.

⇒ 멤버 엔티티 내의 attribute으로 팔로우, 팔로잉 리스트 만들기

⇒ 이렇게 되면 누군가 멤버를 팔로우 했을 때 그 멤버의 팔로우를 건드려야함.

즉, 업데이트 시 매번 리스트 전체를 수정해야하므로 효율적 x

(데이터 조회, 관리도 어렵)

기각!

아이디어 2) Follow 엔티티 만들기

한 유저는 여러 명을 팔로우할 수 있다.
- 동시에, 한 유저는 여러 명에게 팔로잉 될 수 있다.

⇒ 팔로워/팔로잉 관계를 표시하는 Follow 엔티티를 만들자.

즉, 한 팔로워/팔로잉 관계 당 한 Follow 객체가 생김.

ex. 멤버 1이 멤버 2를 팔로우한다. ⇒ follower_id는 멤버 1의 id, followed_id는 멤버 2의 id
예를 들어, 멤버 10명이 한 명당 5명을 팔로우 했을 때에는 50개의 Follow 객체가 생기는 것이다. (여기서 서로 맞팔로우를 한다면 100개)

멤버 및 팔로우 엔티티

기타 또 고민한 문제들, 그리고 하나하나 생각해보며 어떤 방법이 나을지 정리했다.

멤버 조회 시 팔로워 수와 팔로잉 수를 프로필에서 나타내기

투두에는 마이페이지에서 자신의 팔로워 수와 팔로잉 수를 확인할 수 있다. 이 수를 어떻게 조회하고 보여줘야할지 고민했다.

실시간으로 계산해서 보여주기 => 데이터 많아지면 느려질 수도 있음.
- 특정 멤버의 팔로워 수는 followed_id가 해당 멤버의 id인 Follow 객체의 수를 count 하면 됨.
- 반대로 팔로잉 수는 follower_id가 해당 멤버의 id인 Follow 객체 수를 센다.
미리 저장 (Member 속성으로 follower_count, following_count 두기)
- 관계 변경 시 마다 member 업데이트하기

이 방법 중에서 고민해봤는데, 우선 데이터를 많이 넣지는 않을 것이니 1번으로 구현할 예정이다.

채팅방 구현

단체 채팅방까지 구현하고 싶어 이것 저것 생각해보았다.

우선,

한 멤버는 여러 채팅방에 들어갈 수 있다.
또한 한 채팅방에는 여러 멤버가 참여할 수 있다.

⇒ 이는 다대다 관계이므로, 이를 일대다 테이블로 풀어주기 위해 중간 테이블을 추가했다.

추가적으로 했던 고민...
채팅 기능 구현에 웹소켓을 쓸 것인데 메시지 엔티티를 추가해야할까?
A. Yes!
- 웹소켓은 실시간 메시지 소통에 효과적, 하지만 메시지를 영구 저장하지는 않는다.
- 메시지를 저장해서 나중에 또 조회하려면 Message 테이블 필요함.

Message 엔티티

메시지를 누가 보냈는지 확인하기 위해, 메시지 엔티티에서 채팅방 아이디와 멤버 아이디를 같이 외래키로 두어야하는지 처음에 고민했었다. 하지만 생각해보니 이건 아니었음..! 이유는 아래와 같다.

누가, 어느 채팅방에서 보냈는지 조회하는 방법
1. member_id와 chatroom_id 가져오기(FK)
  - 다대다 관계를 다시 정의(중복 정의)하는 것과 비슷
  - member_id와 chatroom_id 조합이 있는지 message 테이블에서 찾아봐아하는 추가 로직 필요
  ⇒ 매번 확인 시 비효율적, 무결성 유지⬇️
2. member_chatroom_id를 가져오기(FK)
  - 간결, 무결성 유지 ‍♀️

채팅방 구현 관련 erd

+. 메시지를 보낸 날짜, 시각은 created_at 속성 활용할 것이다.

실제 우리가 이용하고 있는 서비스에서 제공하는 기능들은 가만 보면 다 개발자들이 고심하고 고심해서 설정한 것이란 것..!

몸소 깨달을 수 있었다. 위 erd는 점차 코드를 짜다보면 달라지기도 할 것이다. 얼른 엔티티 코드를 작성해봐야겠다!