POC 기반으로 MOA 서비스에 적용해보기 IOS_MOA 설치 [안드로이드 MOA 설치] (https://play.google.com/store/apps/details?id=com.moa.salary.app&hl=ko)

1. 배포 전략: 왜 한번에 안 했는가

3편에서 Phase 1(스케줄러 안전장치)과 Phase 2(Blue-Green 인프라)를 분리 배포하기로 결정했었다.

Phase 1 배포 → 2~3일 관찰 → Phase 2 배포

한 PR로 합치면 빠르겠지만, 실제로 문제가 생겼을 때 원인 특정이 어려워진다. ShedLock 설정 문제인지, Nginx 전환 문제인지, deploy.sh 문제인지. 특히 ShedLock은 매일 00:00, 03:00에 돌아가는 배치에 적용되니까, 최소 하루는 운영에서 돌려봐야 확인 가능하다.

2. Phase 1 적용 — ShedLock + Graceful Shutdown

2-1. 변경 사항

2-2. ShedLock 설정 핵심

@Configuration
@EnableScheduling
@EnableSchedulerLock(defaultLockAtMostFor = "PT5M")
class SchedulingConfig {

    @Bean
    fun lockProvider(dataSource: DataSource): LockProvider =
        JdbcTemplateLockProvider(
            JdbcTemplateLockProvider.Configuration.builder()
                .withJdbcTemplate(JdbcTemplate(dataSource))
                .usingDbTime()
                .build()
        )

    @Bean
    fun taskScheduler(): TaskScheduler =
        ThreadPoolTaskScheduler().apply {
            poolSize = 2
            setThreadNamePrefix("scheduler-")
            setWaitForTasksToCompleteOnShutdown(true)
            setAwaitTerminationSeconds(60)
        }
}

여기서 .usingDbTime()은 DB 서버의 NOW() 함수를 기준으로 락 시간을 계산한다는 뜻이다. Java의 System.currentTimeMillis() 대신 DB 시간을 쓰면, Blue/Green 두 컨테이너의 시스템 시계가 미세하게 어긋나더라도 같은 DB의 같은 시간 기준으로 경쟁하니까 안전하다.

setWaitForTasksToCompleteOnShutdown(true)는 3편에서 다뤘던 "Graceful Shutdown이 @Scheduled를 보호하지 않는 문제"의 해결책이다. SIGTERM이 들어오면 실행 중인 스케줄러 작업이 끝날 때까지 최대 60초를 기다려준다.

2-3. 스케줄러별 락 파라미터

// 매 1분 실행 — 55초 이내에 락 만료, 최소 30초 유지
@SchedulerLock(name = "dispatchNotifications", lockAtMostFor = "55s", lockAtLeastFor = "30s")

// 매일 1회 실행 — 최대 2분 유지, 최소 1분 유지
@SchedulerLock(name = "createDailyNotifications", lockAtMostFor = "2m", lockAtLeastFor = "1m")

lockAtMostFor를 cron 주기보다 짧게 잡는 게 포인트다. 1분 cron에 lockAtMostFor: 60s면 경계에서 다음 실행과 겹칠 수 있다. 55초로 잡으면 5초의 여유가 생긴다.

2-4. PR 리뷰에서 받은 피드백

PR을 올렸더니 GitHub Copilot 리뷰에서 2가지를 지적받았다.

지적 1: ShedLock 테이블 생성 스크립트가 없다

"JdbcTemplateLockProvider는 shedlock 테이블이 DB에 존재해야 합니다. 이 PR에 마이그레이션이나 init 스크립트가 없어서 런타임에 실패할 수 있습니다."

운영 DB에는 이미 수동으로 DDL을 실행해둔 상태였다. 하지만 로컬(H2)에서는 테이블이 없어서 개발 환경에서 스케줄러가 에러를 뱉는다.

application-local.yml에 H2 전용 schema 초기화를 추가해서 해결했다.

# application-local.yml
spring:
  sql:
    init:
      mode: always
      schema-locations: classpath:db/local/schema.sql

-- src/main/resources/db/local/schema.sql
CREATE TABLE IF NOT EXISTS shedlock (
    name VARCHAR(64) NOT NULL PRIMARY KEY,
    lock_until TIMESTAMP(3) NOT NULL,
    locked_at TIMESTAMP(3) NOT NULL,
    locked_by VARCHAR(255) NOT NULL
);

application-local.yml에서만 경로를 지정하니까 운영(prod)에서는 절대 실행되지 않는다.

지적 2: cron 표현식이 바뀌었다

"cron이 0 20 0 * * *에서 0 0 0 * * *로 변경됐습니다. 분산락 추가 PR인데 스케줄 변경이 섞여있으니 의도적인지 확인해주세요."

의도한 변경이었지만, PR의 범위가 섞인 건 맞는 지적이었다. 한 PR에 "분산락 추가"와 "스케줄 시간 변경"이 동시에 들어가면, 나중에 문제 생겼을 때 어떤 변경 때문인지 추적이 어려워진다. 앞으로는 이런 부분을 분리해서 커밋해야겠다.

3. 트러블슈팅: ShedLock 타임존 9시간 밀림

Phase 1 배포 후 shedlock 테이블을 확인했는데, 이상한 게 보였다.

3-1. 증상

SELECT NOW() AS db_now, name, locked_at, lock_until FROM shedlock;

db_now                  name                       locked_at                  lock_until
2026-04-17 07:36:06     dispatchNotifications      2026-04-16 22:36:00.001    2026-04-16 22:36:30.001
2026-04-17 07:36:06     createPaydayNotifications  2026-04-16 18:00:00.001    2026-04-16 18:01:00.001
2026-04-17 07:36:06     createDailyNotifications   2026-04-16 15:00:00.001    2026-04-16 15:01:00.001

NOW()는 한국 시간 07:36인데, locked_at은 전날 22:36이다. 정확히 9시간 차이. UTC로 저장된 거다.

KST로 변환해보면 3개 다 맞다:

스케줄러는 정확한 시간에 실행되고 있었다. 저장되는 시간만 UTC인 것.

3-2. 원인: 타임존이 레이어마다 다르다

처음에는 "Dockerfile에서 -Duser.timezone=Asia/Seoul 설정했으니까 다 KST 아닌가?" 싶었다. 근데 아니었다.

┌─ Docker 컨테이너 ──────────────────────────────┐
│                                              │
│  OS (Alpine Linux): 타임존 = UTC               │
│                                              │
│  JVM: -Duser.timezone=Asia/Seoul             │
│    → LocalDateTime.now() = KST ✅            │
│    → @Scheduled cron 해석 = KST ✅            │
│    → 로그 시간 = KST ✅                        │
│                                              │
│  JDBC Driver: serverTimezone=Asia/Seoul      │
│    → Java↔MySQL 값 변환 기준만 설정              │
│    → MySQL 세션 타임존은 건드리지 않음 ❌           │
│                                              │
│  MySQL 세션:                                  │
│    → time_zone = SYSTEM = UTC                │
│    → NOW() = UTC ← ★ 여기가 9시간 차이의 원인     │
│                                              │
└──────────────────────────────────────────────┘

핵심은 3개의 타임존 설정이 각각 다른 레이어에서 독립적으로 동작한다는 것이다.

-Duser.timezone은 JVM 프로세스 메모리 안에서만 유효하다. JVM이 MySQL에 TCP 연결을 맺을 때, 이 설정은 MySQL 서버로 전달되지 않는다.

serverTimezone=Asia/Seoul은 MySQL 세션 타임존을 바꾸지 않는다. JDBC 드라이버가 MySQL에서 TIMESTAMP 값을 읽고 쓸 때 "이 값은 Asia/Seoul 기준이야"라고 해석하는 힌트일 뿐이다. MySQL에 SET time_zone 같은 명령을 보내지 않는다.

결국 ShedLock이 .usingDbTime()으로 NOW(3)을 호출하면, Java 앱의 MySQL 세션 타임존(UTC)이 적용되어 UTC 값이 저장된다.

3-3. 기능 문제는 없다

ShedLock의 락 로직은 이렇게 동작한다:

-- 락 획득 시도 (Java 앱 세션 = UTC)
SELECT * FROM shedlock WHERE name = 'dispatch...' AND lock_until <= NOW(3)

-- 락 갱신 (Java 앱 세션 = UTC)
UPDATE shedlock SET lock_until = NOW(3) + INTERVAL 55 SECOND WHERE ...

READ와 WRITE가 같은 UTC 세션에서 실행되니까 비교가 정확하다. Blue/Green 두 컨테이너도 같은 MySQL에 같은 UTC 세션으로 붙으니까 락 경쟁에도 문제없다.

3-4. 판단: 고치지 않는다

해결 방법은 3가지가 있었다:

1. 조회할 때 CONVERT_TZ로 변환 — 가장 안전, 코드 변경 없음
2. JDBC URL에 forceConnectionTimeZoneToSession=true 추가 — 근본 해결이지만 JPA의 다른 TIMESTAMP 컬럼에도 영향
3. MySQL 서버 타임존 변경 — 가장 파급 범위가 넓어서 위험

"보기 불편하다"와 "동작이 잘못됐다"는 다른 문제다. ShedLock 동작에 문제가 없는데 타임존을 건드리면 다른 엔티티의 createdAt, updatedAt 등 모든 TIMESTAMP 컬럼에 영향을 줄 수 있다. Blue-Green 배포라는 원래 목표에 집중하기로 하고, 타임존 정리는 별도 작업으로 분리했다.

4. Phase 1 운영 관찰

배포 후 2일간 모니터링했다.

SELECT * FROM shedlock;

3개 스케줄러 모두 정상 동작. Phase 2 진행 가능으로 판단했다.

5. Phase 2 적용 — Blue-Green 인프라

5-1. 서버 세팅

EC2 서버에서 직접 실행한 명령어들:

# 상태 파일 생성 — 현재 blue가 돌고 있으므로 blue로 시작
echo "blue" | sudo tee /home/ubuntu/app/active-color
sudo touch /home/ubuntu/app/deploy-history

# Nginx upstream 파일 추가 (deploy.sh가 이 파일을 배포마다 덮어씀)
sudo tee /etc/nginx/conf.d/moa-upstream.conf > /dev/null <<'EOF'
upstream moa_backend {
    server 127.0.0.1:8080;
}
EOF

기존 Nginx SSL server 블록에서 proxy_pass를 변경했다:

# 변경 전
location / {
    proxy_pass http://localhost:8080;
}

# 변경 후
location / {
    proxy_pass http://moa_backend;
}

localhost:8080 하드코딩에서 moa_backend upstream으로 바꾸는 게 핵심이다. 이 시점에서는 upstream이 8080 고정이라 기존 배포와 완전히 동일하게 동작한다. Blue-Green은 workflow를 바꾸는 순간부터 시작된다.

5-2. deploy-main.yml 변경

기존의 "stop → pull → run" 방식에서 deploy.sh 호출로 교체했다.

# 변경 전
- name: Stop existing container and pull latest image
  run: |
    sudo docker stop moa-server || true
    sudo docker rm -f moa-server || true
    sudo docker pull godqhr721/moa_server:${{ needs.setup.outputs.docker_tag }}

- name: Run container
  run: |
    sudo docker run ... --name moa-server -p 8080:8080 ...

# 변경 후
- name: Checkout deploy scripts
  uses: actions/checkout@v4
  with:
    sparse-checkout: |
      scripts

- name: Run Blue-Green Deploy
  env:
    DOCKER_IMAGE: godqhr721/moa_server
  run: |
    chmod +x scripts/deploy.sh
    sudo -E bash scripts/deploy.sh "${{ needs.setup.outputs.docker_tag }}"

workflow 최상단에 동시 배포 방지도 추가했다:

concurrency:
  group: deploy-production
  cancel-in-progress: false  # 진행 중인 배포는 절대 취소하지 않고 큐잉

5-3. Smoke Test의 HTTPS 대응

deploy.sh 작성 중 놓칠 뻔한 부분이 있었다. MOA 서버의 Nginx 설정이 이렇게 되어있었다:

server {
    listen 80;
    return 301 https://$host$request_uri;  # HTTP → HTTPS 리다이렉트
}

server {
    listen 443 ssl;
    location / {
        proxy_pass http://moa_backend;
    }
}

deploy.sh의 smoke test가 http://localhost/api/v1/deploy-info로 요청하면 301 리다이렉트 응답이 와서 body가 비어있다. 정상 배포인데 smoke test가 실패하면서 자동 롤백이 터지는 상황이 생긴다.

--resolve 옵션으로 HTTPS를 localhost에서 직접 테스트하도록 수정했다:

SMOKE_RESULT=$(curl -sf \
    --resolve "${SMOKE_TEST_HOST}:443:127.0.0.1" \
    "https://${SMOKE_TEST_HOST}/api/v1/deploy-info" 2>/dev/null || true)

--resolve moa-official.kr:443:127.0.0.1은 DNS를 타지 않고 127.0.0.1:443에 직접 붙으면서 SNI(Server Name Indication)는 moa-official.kr로 보낸다. 실제 사용자와 동일한 HTTPS 경로를 서버 로컬에서 테스트하는 것이다.

5-4. 첫 배포 시 좀비 컨테이너 문제

첫 Blue-Green 배포에서 주의할 점이 있었다. 기존에는 moa-server라는 이름으로 컨테이너가 돌고 있는데, deploy.sh는 moa-blue, moa-green이라는 이름을 사용한다.

active-color = blue → NEXT = green
  → moa-green(:8081) 생성
  → Nginx upstream → 8081 전환
  → "이전 컨테이너 moa-blue를 정리하자" → docker inspect moa-blue → 없음 → 스킵
  → 기존 moa-server(:8080)는 그대로 방치됨 💥

두 번째 배포 때 moa-blue를 8080에 띄우려다가 기존 moa-server와 포트 충돌이 난다.

해결: 첫 배포 성공 확인 후 수동으로 moa-server를 제거했다.

# 첫 배포 후 moa-green 정상 서빙 확인
curl https://moa-official.kr/api/v1/deploy-info
# → "color":"green" 확인

# 좀비 컨테이너 제거
sudo docker stop moa-server && sudo docker rm moa-server

위 내용을 실제 무중단 배포 환경을 제공할 때 주의사항이고 필수로 해야하는 과정이지만 나는 이 과정을 좀 늦게 알아차렸다. ㅋㅋㅋ... 일주일간 블루-그린 환경의 톰캣 컨테이너와 기조 컨테이너가 함께 실행되고 있었고 다행히 ShedLock이 아주 잘 동작중이여서 문제가 발생하진 않았다!!! 로그를 보니 nignx가 8081 포트의 서버로만 요청을 보냈지만 실제로 배치 프로그램은 Lock을 소유한 컨테이너에서 실행되는 걸 의도치 않게 확인할 수 있는 좋은 경험이었다~

6. 무중단 검증

6-1. 방법

터미널 2개로 진행했다.

터미널 1 — 모니터링 (0.5초마다 요청)

while true; do
  RESULT=$(curl -s -o /tmp/resp.txt -w "%{http_code}" https://moa-official.kr/api/v1/deploy-info 2>/dev/null)
  BODY=$(cat /tmp/resp.txt)
  VERSION=$(echo "$BODY" | grep -o '"version":"[^"]*"' | head -1)
  COLOR=$(echo "$BODY" | grep -o '"color":"[^"]*"' | head -1)
  echo "$(date '+%H:%M:%S') | HTTP ${RESULT} | ${VERSION} | ${COLOR}"
  sleep 0.5
done

터미널 2 — 두 번째 배포 트리거

git commit --allow-empty -m "test: zero-downtime verify"
git push origin main

6-2. 결과

14:30:01 | HTTP 200 | "version":"a1b2c3d" | "color":"green"
14:30:02 | HTTP 200 | "version":"a1b2c3d" | "color":"green"
14:30:02 | HTTP 200 | "version":"a1b2c3d" | "color":"green"
... (배포 진행 중 — 계속 200) ...
14:31:45 | HTTP 200 | "version":"a1b2c3d" | "color":"green"
14:31:46 | HTTP 200 | "version":"d4e5f6g" | "color":"blue"    ← 전환!
14:31:46 | HTTP 200 | "version":"d4e5f6g" | "color":"blue"
14:31:47 | HTTP 200 | "version":"d4e5f6g" | "color":"blue"

502가 단 하나도 없다. 모든 요청이 HTTP 200이고, version/color가 한 순간에 green→blue로 전환됐다.

7. 시리즈 전체 회고

1편부터 4편까지, "배포할 때마다 서버가 죽는다"에서 "배포해도 아무도 모른다"까지 왔다.

최종 아키텍처

Client → Nginx(:443) → upstream(전환 가능)
                        ├─ moa-blue  (:8080)
                        └─ moa-green (:8081)

ShedLock → 스케줄러 중복 실행 방지
Graceful Shutdown → 배치 실행 중 안전 종료
deploy.sh → 9단계 자동 배포 (health check + smoke test + 자동 롤백)
rollback.yml → GitHub Actions UI에서 원클릭 롤백

내가 놓칠 뻔한 것들

1. @Scheduled는 Graceful Shutdown 밖이다 — HTTP 요청만 보호한다는 걸 모르면 배치가 중간에 끊긴다
2. Smoke Test ≠ Health Check — 컨테이너가 살아있어도 Nginx 설정이 잘못되면 사용자는 502를 본다
3. HTTPS 환경에서의 Smoke Test — http://localhost로 테스트하면 301만 오는데, 이걸 놓치면 정상 배포가 매번 롤백된다
4. 첫 배포의 좀비 컨테이너 — moa-server와 moa-blue는 이름이 다르다
5. JVM 타임존 ≠ MySQL 세션 타임존 — -Duser.timezone이 DB 쿼리의 NOW()에는 영향을 주지 않는다

전체 시리즈 아키텍처 결정 흐름

다음 단계

현재 구조의 한계점도 명확히 알고 있다.

• SPOF: EC2 서버 1대가 죽으면 끝이다. 트래픽이 늘면 ALB + Auto Scaling Group으로 가야 한다
• 인프라 레벨 헬스체크만: /actuator/health는 비즈니스 로직 버그를 잡지 못한다. CI 테스트 강화가 선행되어야 한다
• 수동 롤백: 메트릭 기반 자동 롤백은 아직 없다. CloudWatch 알람 + 자동 롤백까지 가면 더 안전해진다

지금 규모(DAU 80명)에서는 이 정도면 충분하다. 현재 규모에 맞는 적정 기술을 선택하고, 필요할 때 다음 단계로 전환할 수 있는 구조를 이해하는 것. 이 시리즈를 통해 그 과정을 경험할 수 있었다.

해당 인라인 블럭으로 작성한 내용을 직접 고민하고 생각한 내용을 작성하는 부분입니다. 클로드 코드가 작성해준 내용과 구분하기 위함.

5. 테스트 파일 구조 해부 ( ClaudeCode의 답변)

NotificationBatchServiceHolidayTest.kt를 블록 단위로 뜯어봅니다.

5-1. Fake를 위한 자료구조

private val holidayCalendar = mutableSetOf<LocalDate>()
private val workPolicies = mutableListOf<WorkPolicyVersion>()
private val notificationLogs = mutableListOf<NotificationLog>()
private val terms = mutableListOf<Term>()
private val agreements = mutableListOf<TermAgreement>()
private val settings = mutableListOf<NotificationSetting>()
private val fcmTokens = mutableListOf<FcmToken>()
private val dailySchedules = mutableListOf<DailyWorkSchedule>()

이게 인메모리 DB입니다. 프로덕션의 MySQL 테이블과 1:1 대응:

네이밍 선택: publicHolidayRepo, notificationLogRepo 같은 infrastructure 용어 대신 holidayCalendar, notificationLogs 같은 도메인 용어로 지었습니다. 테스트를 읽을 때 "공휴일 달력에 신정을 추가하고 나면…"처럼 자연어로 읽히게 하려는 의도.

여기서 나는 너무 자료구조들이 존재하고 이는 즉 너무 많은 책임을 가지고 있는 것은 아닐까? 하는 의문이 생겼고 바로 클로드 코드에게 코드리뷰를 부탁했다.

1차 분해 — Fake 8개는 동급이 아니다

SUT(System Under Test)는 NotificationBatchService인데, 그 자체가 의존하는 협력자는 8개가 아니다.

NotificationBatchService (SUT)  
├─ WorkPolicyVersionRepository      ← SUT 직접 의존  
├─ NotificationLogRepository        ← SUT 직접 의존  
├─ NotificationEligibilityService   ← 실물(in-process)로 함께 검증  
│   ├─ TermRepository  
│   ├─ TermAgreementRepository  
│   ├─ NotificationSettingRepository  
│   ├─ FcmTokenRepository  
│   └─ DailyWorkScheduleRepository  
└─ PublicHolidayService             ← 실물  
    └─ PublicHolidayRepository

• SUT가 직접 들고 있는 의존: 4개 (WorkPolicyVersionRepository, NotificationLogRepository, NotificationEligibilityService, PublicHolidayService).
• SUT 자체로는 4개, 그 중 2개가 in-process 도메인 서비스라 같이 검증 범위에 끌어들였고, 그 결과 간접 의존 6개의 데이터 경계까지 합쳐 fake가 8개가 됐다.

NotificationBatchService.kt 한 파일만 보면 의존성이 비대하지 않다. 8개라는 숫자는 세 서비스가 함께 참여하는 통합된 도메인의 데이터 경계 합산이다.

PublicHolidayService, NotificationEligibilityService는 실물을 사용한다.

"Fake = 결합도" 명제의 조건부 진실

이 명제는 mockist 스타일에서는 거의 진실이다. mock이 많다 = SUT가 협력자에게 많은 명령을 내린다 = 결합도가 높다.

Classicist 스타일에선 다르게 읽어야 한다. classicist의 fake는 "협력자의 동작 흉내"가 아니라 "외부 시스템(DB)의 얇은 어댑터"이다. 그래서 fake 수는 결합도가 아니라 외부로 노출된 데이터 경계의 수에 비례한다.

이 프로젝트의 도메인 데이터 경계를 세보면:

• 회원 자격 — 약관(2: term, agreement) + 알림 설정(1) = 3
• 근무 정책 — work_policy_version + daily_schedule = 2
• 공휴일 — 1
• 알림 로그 — 1
• FCM 토큰 — 1

= 8개. 정확히 일치한다. 즉 fake 8개는 "SUT의 결합도가 폭발했다"의 지표가 아니라 도메인이 잘 정규화돼서 테이블이 8개로 쪼개져 있다는 사실의 그림자일 뿐이다.

이 차이를 명확히 의식하지 못하면, mockist 시절의 "fake = 결합도" 직관을 classicist 코드에 그대로 적용해서 잘못된 리팩터링 압력을 만든다.

그래도 SRP 의심점은 있다 — 어디 있는가

테스트 fake의 수보다 production 쪽에서 더 본격적인 의심점이 보인다.

NotificationEligibilityService가 5개 repository를 한 번에 들이고 있다. 자문해본다.

Q: NotificationEligibilityService는 무엇을 하는가?
A: "이 회원이 이 시점에 이 종류의 알림을 받을 자격이 있는가" 한 가지 질문에 답한다.

답이 한 줄로 압축되면 SRP 통과 — 5개 repo는 하나의 자격 판정에 필요한 다섯 가지 입력일 뿐이다. 입력의 수와 책임의 수는 다른 차원이다.

만약 답이 "회원 정보를 합성하고, 약관을 검증하고, 토큰을 조회하고, 휴가를 판정하고…" 처럼 and로 연결되는 여러 동사라면 SRP 위반 — 분리 후보.

Eligibility라는 이름이 한 단어로 응집되어 있다는 사실 자체가 전자의 형태일 가능성이 높다는 신호다. 다섯 입력은 한 답을 위한 다섯 검증 조건이지, 다섯 일이 아니다.

다만 이건 production 코드를 직접 펼쳐서 한 번 더 확인할 가치는 있다. 눈으로 보고 책임이 한 문장에 압축되는지를 본인이 답할 수 있어야 한다.

SRP 의심점 리뷰를 받고 NotificationEligibilityService 다시 한번 직접 리뷰하면서 고민하는 시간을 가졌고 아래와 같은 코드를 볼 수 있었다.

    if (!context.hasAgreedToAll(memberId, requiredCodes)) return null  
    if (!context.isSettingEnabled(memberId, NotificationSettingType.WORK)) return null  
    if (context.shouldSkipNotification(memberId)) return null  
    if (!context.hasFcmToken(memberId)) return null

createNotificationsIfEligible() 메서드가 존재하는데 이는 알림을 생성해도 되는지 판단하는 헬퍼 메서드로 사용되고 있다.

이번 리뷰를 통해 and로 연결되는 여러 동사라면 SRP 위반이라는 피드백을 보고 context 객체를 생성해주는 NotificationEligibilityContext 를 다시 보게 되었고 해당 객체는 회원별 적격성을 판단하기위한 정보를 로드하는 책임뿐 아니라 shouldSkipNotification() 과 같이 알림을 전송해도되는지 판단까지 하는 책임을 가지고 있다고 생각했고 이를 리팩토링 하기로 했다.

• 추가적으로 호출자에서 직접 메서드를 호출해보고 판단하는게 이후 유지보수에서 일관성일 떨어지는 지점으로 만들 것 같아 해당 책임을 처리하는 클래스 분리를 고려하려고한다.

결론 단순히 많은 자료구조, 많은 클래스를 생성한다고 해서 SRP를 위반했다고 접근하는건 위험한 생각이다. 실제로 NotificationBatchService 가 직접 의존하는 객체는 4개였고 나머지 4개의 경우 단위테스트 작 성을 위해 연관된 실물 클래스들이 사용하는 간접 의존 객체였다.

고전파 방식의 테스트를 진행하기 위해서는 어쩌면 당연한 수순이었고 조금 더 본질을 생각할 수 있는 계기가 되었다.

5-2. Repository 어댑터 (ClaudeCode 작성)

private val publicHolidayRepo = mockk<PublicHolidayRepository>().apply {
    every { existsByDate(any()) } answers { firstArg<LocalDate>() in holidayCalendar }
}

existsByDate가 호출되면 holidayCalendar Set에서 in 연산(Kotlin의 contains)으로 포함 여부 확인. O(1).

더 복잡한 예시:

private val workPolicyRepo = mockk<WorkPolicyVersionRepository>().apply {
    every { findLatestEffectivePoliciesPerMember(any()) } answers {
        val date = firstArg<LocalDate>()
        workPolicies
            .filter { !it.effectiveFrom.isAfter(date) }   // effectiveFrom <= date
            .groupBy { it.memberId }
            .map { (_, versions) -> versions.maxBy { v -> v.effectiveFrom } }
    }
}

이게 재현하는 실제 JPQL:

select distinct w from WorkPolicyVersion w
join fetch w.workdays
where w.effectiveFrom = (
    select max(w2.effectiveFrom)
    from WorkPolicyVersion w2
    where w2.memberId = w.memberId and w2.effectiveFrom <= :date
)

Kotlin 번역:

• filter { !it.effectiveFrom.isAfter(date) } → effectiveFrom <= date
• groupBy { it.memberId } → 회원별 그룹
• map { ... maxBy { v.effectiveFrom } } → 각 그룹에서 최신 버전 선택

⚠️ 중요한 한계: 이 Fake 재현 로직이 실제 JPQL과 의미가 같다는 보장이 없습니다. 재현 로직 자체가 버그일 수 있어요. 그래서 계층 2(@DataJpaTest)가 필요합니다 — 실제 JPQL이 Fake와 같은 의미를 갖는다는 계약을 증명하는 테스트.

5-3. 실물 도메인 서비스

private val publicHolidayService = PublicHolidayService(publicHolidayRepo)
private val eligibilityService = NotificationEligibilityService(
    termRepo, agreementRepo, settingRepo, fcmTokenRepo, dailyScheduleRepo,
)
private val sut = NotificationBatchService(
    workPolicyRepo, notificationLogRepo, eligibilityService, publicHolidayService,
)

mock이 아니라 실물입니다. 이게 고전파의 핵심.

• PublicHolidayService.isHoliday의 실제 로직이 돌아감
• NotificationEligibilityService.loadContext가 진짜 실행됨
• NotificationBatchService.generateHolidayNotifications도 진짜 호출됨

→ 세 서비스의 협력이 올바른지를 한 테스트가 검증.

sut는 System Under Test 약자. 테스트 대상을 명확히 구분하는 관습.

5-4. DSL 헬퍼

private fun 공휴일로_지정(date: LocalDate) {
    holidayCalendar += date
}

private fun 회원_등록(
    id: Long,
    알림_켜짐: Boolean = true,
    정책기준일: LocalDate = 신정,
    근무요일: Set<Workday> = Workday.WEEKDAYS,
) {
    workPolicies += WorkPolicyVersion(...)
    agreements += TermAgreement(memberId = id, termCode = TOS_CODE, agreed = true)
    settings += NotificationSetting(memberId = id, workNotificationEnabled = 알림_켜짐)
    fcmTokens += FcmToken(memberId = id, token = "token-$id")
}

테스트 전용 도메인 언어(DSL). 한글 함수명을 쓴 이유:

1. 이 프로젝트 컨벤션 (다른 테스트도 한글 백틱 네이밍)
2. 기획자/PM도 테스트 시나리오를 읽을 수 있게
3. 비즈니스 의도를 기계적 세팅 코드와 분리

기본값 적극 활용:

• 알림_켜짐 = true: 대부분 "켜짐"이므로 기본값
• 정책기준일 = 신정: 대부분 공휴일 테스트
• 기본값과 다를 때만 인자 지정 → 각 테스트가 "이 테스트에서 특별한 것"만 명시적으로 드러냄

DSL이란? Domain-Specificic Language (도메인 특화 언어)라는 뜻을 가지고 있다.

단순 Kotlin 함수 호출인데, 이를 잘 작성해두면 읽을 때 도메인 시나리오처럼 읽혀 유비보수성을 높이는데 기여할 수 있다.

주로 모든 셋업이 테스트마다 반복되는 과정을 DSL을 사용하면 도움이된다. 공휴일_지정과 같은 용어로 함수를 지정하면 해당 과정이 뭘 위한 것인지 직관적으로 이해하는데 도움이 된다. 또한, 도메인 마다 다르게 해석될 수 있는 부분을 도메인 용어로 작성하여 도움을 줄 수 있다.

예를 들어 단순히 캘린더 자료구조에 데이터를 추가하는 행위가 약속을 추가하는 건지, 근무일을 추가하는 것인지 구분을 쉽게 할수 있다.

다만 동일한 개념이 자바에도 존재하지만 코틀린만큼 매끄럽지 않기 때문에 자바에서는 잘 사용되지 않는다고한다.

자바 시대부터 있던 Test Data Builder / Object Mother 패턴이 Kotlin의 표현력 좋은 문법(named/default args, 백틱 식별자)과 만나서 "거의 자연어처럼 읽히는 형태"로 진화한 것

7. 주니어가 자주 빠지는 함정 (ClaudeCode 작성)

함정 1: 커버리지 100%를 위해 분기당 테스트 1개 쓰기

❌ 안티패턴: if 하나당 테스트 하나.

✅ 옳은 접근: 사용자 관점의 시나리오당 테스트 하나. 내부 분기가 2개든 10개든 외부에서 관찰 가능한 행동 단위로 묶음.

예) "공휴일이어도 알림 꺼둔 회원 제외"는 내부적으로 isHoliday 분기 + eligibility 필터 분기를 거치지만 테스트는 1개. 사용자 관점에선 "OFF → 알림 없음" 한 시나리오이기 때문.

함정 2: verify로 모든 호출을 검증하기

❌ 안티패턴:

verify(exactly = 1) { workPolicyRepo.findLatestEffectivePoliciesPerMember(any()) }
verify(exactly = 1) { notificationLogRepo.findMemberIdsBy...(...) }
verify(exactly = 1) { eligibilityService.loadContext(any(), any()) }
verify(exactly = 1) { notificationLogRepo.saveAll(any()) }

이건 "구현을 박제"하는 것. 내부가 조금만 바뀌어도 테스트가 깨져 거짓 양성이 쏟아짐.

✅ 옳은 접근: 최종 상태만 검증. "어떻게 도달했는가"는 구현 세부사항.

verify가 정당한 순간은 "호출 자체가 명세일 때"뿐입니다. 예: FCM API에 올바른 토큰·제목·본문을 전달했는가 — 이건 호출이 곧 명세.

함정 3: @SpringBootTest 남발

❌ 안티패턴: 서비스 테스트마다 @SpringBootTest.

✅ 옳은 접근:

@SpringBootTest는 컨텍스트 로딩에 초 단위 걸립니다. 100개면 5분. 속도는 테스트 문화의 복리입니다. 처음엔 체감 못해도 6개월 뒤에 팀 전체가 테스트 안 돌리는 조직이 됨.

함정 4: Given-When-Then 주석 남발

❌ 안티패턴:

@Test
fun `test name`() {
    // Given
    val x = ...
    // When
    val result = sut.doSomething(x)
    // Then
    assertThat(result).isEqualTo(...)
}

✅ 옳은 접근: 빈 줄로 섹션 구분. 주석 불필요.

@Test
fun `test name`() {
    공휴일로_지정(신정)
    회원_등록(id = 1L)

    sut.generateNotificationsForDate(신정)

    assertThat(notificationLogs).hasSize(1)
}

빈 줄 하나가 Given/When/Then을 자연스럽게 분리합니다. DSL 헬퍼 이름이 명확하면 주석은 소음.

함정 5: 테스트에 if/for/when 사용

❌ 안티패턴:

@Test
fun `다양한 케이스 한번에 검증`() {
    for (case in listOf(case1, case2, case3)) {
        if (case.isHoliday) {
            assertThat(...).isEqualTo(...)
        } else {
            assertThat(...).isEqualTo(...)
        }
    }
}

✅ 옳은 접근: 한 테스트 = 한 시나리오. 조건부 로직이 테스트에 있다는 건 여러 테스트가 섞였다는 신호.

다중 케이스를 테이블로 처리하고 싶다면 JUnit 5 @ParameterizedTest. if/for 금지.

함정 6: Fake 재현 로직이 틀렸는지 확인 안 하기

우리 테스트의 findLatestEffectivePoliciesPerMember Fake:

workPolicies
    .filter { !it.effectiveFrom.isAfter(date) }
    .groupBy { it.memberId }
    .map { (_, versions) -> versions.maxBy { v -> v.effectiveFrom } }

이게 진짜 JPQL과 같은 결과를 낼지 단위 테스트 레벨에선 증명 못 합니다. 그래서 @DataJpaTest 계약 테스트가 반드시 있어야 해요.

없으면? 단위 테스트는 전부 녹색인데 프로덕션은 터지는 사고가 납니다.

함정 7: 한 테스트에서 여러 assertion 남발

❌ 안티패턴: 한 테스트에서 assertThat(...)가 10줄.

✅ 옳은 접근: 한 테스트는 하나의 주장(assertion). 여러 측면을 검증하고 싶으면 테스트를 분리. 단, 같은 객체의 여러 속성을 검증하는 건 허용 (한 개념).

우리 테스트 ①에서 memberId, notificationType, scheduledDate, scheduledTime, status를 모두 검증한 건 "생성된 NotificationLog 객체의 완전성"이라는 하나의 개념에 대한 검증이므로 OK.

운영환경에서 테스트코드 작성 중요성을 체감하고 있고 이것이 가성비가 좋은 테스트인가? 라는 고민을 블라디미르 코리코프의 단위테스트 책을 읽고 시작하게 되었다.

일단 나의 경우 예시에 대입해서 내 생각을 정리하는 것을 좋아하는데, 최근 AI와 함께 좋은 예시를 만들어서 함께 토론하며 생각 정리하는데 정말 좋은 것 같다.

다시 본론으로 돌아와서 MOA 프로젝트에는 사용자들에게 FCM 을 이용해서 알림을 전송하는 기능이 존재하고, 여기에 공휴일엔 공휴일 전용 알림을 전송해 보고자 기능을 추가였고 이에 대한 테스트 코드를 작성하는 것이다.

MOA_GIT_REPO

1. 무엇을 왜 테스트하는가

대상 코드

매일 자정 KST에 NotificationBatchScheduler.createDailyNotifications()가 실행됩니다:

@Scheduled(cron = "0 0 0 * * *", zone = "Asia/Seoul")
@SchedulerLock(name = "createDailyNotifications", lockAtMostFor = "2m", lockAtLeastFor = "1m")
fun createDailyNotifications() {
    val today = LocalDate.now(ZoneId.of("Asia/Seoul"))
    notificationBatchService.generateNotificationsForDate(today)
}

그리고 NotificationBatchService.generateNotificationsForDate:

fun generateNotificationsForDate(date: LocalDate) {
    if (publicHolidayService.isHoliday(date)) {
        generateHolidayNotifications(date)  // ← 우리 테스트 대상
    } else {
        generateWorkNotifications(date)
    }
}

공휴일이면 PUBLIC_HOLIDAY 타입 NotificationLog를 적격 회원에게 09:00 예약으로 생성한다. 그다음 NotificationDispatchScheduler가 이 로그를 읽어 FCM으로 실제 발송합니다.

실제로 내가 부분을 테스트 할 것인지 클로드 코드에게 알려준다면 더 좋은 퀄리티의 테스트 코드를 작성할 수 있다고 생각합니다.

하지만 아직 테스트 코드를 많이 작성한 경험이 부족하고, 또한 잘못된 가성비가 좋지 않은 테스트 코드를 작성하게 시켜 오히려 좋지 않은 안정망이 만들어 질 수 있다는 핑계? 아닌 생각과 함께 모든 엣지 케이스를 고려하여 테스트 코드를 작성하게 시켰보았습니다.

해당 기능에서 발생할 수 있는 모든 엣지케이스를 고려해서 그 이유와 함께 제시하라는 프롬프트를 입력하였고 아래와 같은 결과를 받을 수 있었습니다.

이 기능이 깨지면 벌어지는 일 (ClaudeCode 답변)

"알림이 두 번 가는 경우"가 실제로 일어날 확률은? 있습니다. 이유:

• 배치는 재시도됩니다 (k8s pod 리스타트, ShedLock TTL 만료, 수동 재실행)
• 멱등성은 findMemberIdsByScheduledDateAndNotificationTypeAndMemberIdIn 한 줄에 걸려 있고, 이 쿼리 이름이 오타나 리팩터로 깨지기 쉽습니다
• 분기(공휴일/평일) × 필터(약관/설정/토큰)의 조합이 많아 리팩터링 중 실수 여지가 큽니다

다음으로 해당 문제들을 해결할 수 있도록 런던파와 고전파 의 관점에서 더 안정적이고 리팩토링 내성이 좋은 테스트 코드 작성을 요구했고, 다음과 같은 답변을 받을 수 있었습니다.

3. 런던파 vs 고전파 — 스타일 결정 (ClaudeCode 답변)

두 학파의 배경

2000년대 초 TDD 커뮤니티에서 단위 테스트를 어떻게 짤 것인가에 대해 두 진영이 갈렸습니다.

런던파 (London School / Mockist)

• 주창자: Steve Freeman, Nat Pryce — Growing Object-Oriented Software, Guided by Tests (2009)
• 철학: "단위"는 클래스 하나. 주변 협력자는 전부 mock.
• 검증: 상호작용(interaction) — "A가 B에게 올바른 메시지를 보냈는가?"

고전파 (Classicist / Detroit School / Chicago School)

• 주창자: Kent Beck, Martin Fowler, Vladimir Khorikov — Unit Testing: Principles, Practices, and Patterns (2020)
• 철학: "단위"는 하나의 동작(behavior). 여러 클래스가 협력해서 만드는 결과.
• 검증: 최종 상태(state) — "실행 후 세계가 어떻게 바뀌었는가?"

같은 로직을 두 스타일로 비교

대상: "공휴일에 적격 회원이면 알림 로그를 저장한다"

런던파 버전

@Test
fun `공휴일에 적격 회원이면 로그를 저장한다`() {
    every { publicHolidayService.isHoliday(날짜) } returns true
    every { workPolicyRepo.findLatestEffectivePoliciesPerMember(날짜) } returns listOf(정책)
    every { notificationLogRepo.findMemberIdsBy...(...) } returns emptyList()
    every { eligibilityService.loadContext(...) } returns 적격_컨텍스트
    every { eligibilityService.findRequiredTermCodes() } returns emptySet()

    sut.generateNotificationsForDate(날짜)

    verify(exactly = 1) {
        notificationLogRepo.saveAll(match<List<NotificationLog>> {
            it.size == 1 && it[0].memberId == 1L
        })
    }
}

고전파 버전 (우리 선택)

@Test
fun `공휴일에 적격 회원이면 로그를 저장한다`() {
    공휴일로_지정(신정)
    회원_등록(id = 1L)

    sut.generateNotificationsForDate(신정)

    assertThat(notificationLogs).hasSize(1)
}

왜 이 코드에 고전파를 선택했나

이유 1: "단위"는 클래스가 아니라 파이프라인이다

NotificationBatchService는 혼자 결정하지 않습니다. PublicHolidayService, NotificationEligibilityService와 협력해서 "공휴일 알림 생성"이라는 하나의 비즈니스 동작을 만듭니다.

런던파로 짜면:

• NotificationBatchService 단위 테스트: 협력자 모두 mock
• PublicHolidayService 단위 테스트: 따로 존재
• NotificationEligibilityService 단위 테스트: 따로 존재
• → 세 개가 연결됐을 때 올바른지는 아무도 보증 안 함 (이걸 통합 테스트가 대신 해야 하는데, 그러면 단위 테스트의 존재 이유가 약해짐)

고전파로 짜면:

• 한 테스트가 세 서비스를 실제로 돌려 최종 상태를 검증
• → 연결 자체가 피처라는 사실이 테스트에 녹아있음

이유 2: 리팩터링 내성

런던파는 "어떻게(how)"를 박제합니다. saveAll이 몇 번 호출됐는지, 어떤 인자로 호출됐는지를 다 검증해요.

예시: 최적화로 saveAll 한 번 대신 save 여러 번 호출하도록 바꾸면?

• 런던파: 전부 빨개짐 (하지만 동작은 같음) → 거짓 양성
• 고전파: 통과 (최종 저장 상태가 같으니까)

피처를 안 바꾸고 구현만 바꿀 때 테스트가 깨지면, 팀은 테스트를 신뢰하지 않게 됩니다.

이유 3: 기존 프로젝트 컨벤션

이미 src/test/kotlin/com/moa/service/calculator/CompensationCalculatorTest.kt는 고전파 스타일입니다 (mock 없이 실물 계산기 사용). 컨벤션 일관성을 위해 같은 스타일을 유지합니다.

그럼 런던파는 언제 쓰나

외부 경계 어댑터에는 런던파가 더 자연스럽습니다:

• FCM 클라이언트: "올바른 토큰·제목·본문으로 FCM API를 호출했는가?" → 호출 자체가 명세
• 결제 PG 호출: 호출 인자가 계약
• 이메일/Slack 발송: 상호작용 검증이 자연스러움

규칙: 내부 도메인 로직 = 고전파, 외부 경계 = 런던파. 실무에서 자주 쓰이는 분업입니다.

나의 생각 테스트를 처음 공부할 때, 고전파 개념은 알 수 없었지만 테스트 더블 방식의 Fake 클래스를 정의하고 객체를 만들어 수행하는 것이 빌드 속도가 빠르면서 실제로 테스트하고자 하는 것을 정확하게 판단할 수 있다는 점과 외부 의존 라이브러리는 변경될 수 있어도 이에 따른 결과는 변경돼서는 안된다. (테스트 코드를 포함해서) 고전 파는 최종 상태를 테스트 하는 리팩토링 내성에서 긍정적으로 생각한다.

하지만 Fake 객체를 만들기 위해서 클래스를 만들고 이를 사용하고 등등 더 많은 코드가 작성되고 정말 중요한 기능이 아니라면 복잡도와 초기 생산성이 너무 낮아질 것 같았다. 하지만 최근엔 ClaudeCode, Codex를 활용하면 정말 빠르고 쉽게 개발할 수 있다는 점에서 고전파의 단점을 극복할 수 있어진건 아닐까? 싶다.

나의 생각을 또 Claude에게 물어봤다.

내가 생각한 코드 양이 늘어나는 것과는 다른 고전파 단점을 알려줬다.

• 객체 그래프 셋업 복잡도 — 한 테스트가 진짜 협력자들을 다 거치니까, 의미 있는 시나리오 하나 만들려면 많은 사전 상태가 필요해. (그래서 Object Mother, Test Data Builder 같은 패턴이 나옴)
• 에지 케이스 강제 어려움 — "정확히 이 시점에 DB가 터지면?" 같은 시나리오는 mock이 훨씬 편해.
• 테스트 실행 속도 — Fake로 어느 정도 해결되지만, 실물 의존성이 많아질수록 느려짐.
• Fake와 실물의 행동 불일치 — in-memory repo가 실제 JPA repo와 미묘하게 다르게 동작하면 거짓 안심을 주게 됨. (Khorikov는 그래서 가능하면 Testcontainers 같은 실제 인프라 권장)

그렇다면 AI가 극복해주는 부분은 정확히 뭘까?(ClaudeCode 답변)

"AI로 빠르게 짜니까 고전파 단점이 해소된다"는 통찰은 맞는데, 어떤 단점이 해소되는지는 좀 더 정교하게 볼 필요가 있어:

• ✅ 해소됨: Fake 클래스 초기 작성, Test Builder 보일러플레이트, 비슷한 패턴의 테스트 케이스 양산
• ⚠️ 여전히 사람 영역: 어떤 시나리오를 테스트할지 결정, Fake와 실물의 행동 일치 검증, 테스트가 실패했을 때 디버깅, 리팩터링 시 테스트 의도 보존

오히려 AI 시대에 고전파가 더 유리해지는 다른 이유도 있어: AI가 짠 테스트는 종종 mock 설정이 과한 경향이 있고, 이런 테스트는 리팩터링할 때 우수수 깨져서 AI가 다시 고치고 또 깨지는 악순환을 만들어. 상태 검증 위주의 고전파 테스트는 AI가 나중에 코드를 수정해도 잘 안 깨지는 견고함이 있어서, 사람-AI 협업에 더 잘 어울려.

4. Spring Data JPA에서 고전파 구현하기 (ClaudeCode 답변)

문제: Repository는 애매한 의존성

고전파는 "in-process 협력자는 실물을 쓰라"고 합니다. 그런데 Repository는:

• 인터페이스는 in-process
• 실제 구현은 DB(out-of-process)

Khorikov가 이걸 명쾌히 정리했어요: "Repository는 DB 어댑터다. DB는 out-of-process니까 Repository도 out-of-process로 취급하고 대역으로 교체하라."

즉, 단위 테스트에서 Repository는 대역으로 대체. 단, 상호작용 감시용 mock이 아니라 인메모리 Fake로.

테스트 대역(Test Double) 5종

고전파 = Fake 위주, 런던파 = Mock 위주입니다.

"MockK-as-Fake" 패턴

Spring Data JPA Repository는 JpaRepository<T, ID>를 확장해 수십 개 메서드를 상속합니다. 손으로 Fake 클래스를 만들면 다 구현해야 해서 현실적이지 않아요.

실무 해법: MockK를 Fake처럼 쓴다.

private val notificationLogs = mutableListOf<NotificationLog>()  // 인메모리 저장소

private val notificationLogRepo = mockk<NotificationLogRepository>().apply {
    // 쓰기: 리스트에 추가
    every { saveAll(any<Iterable<NotificationLog>>()) } answers {
        val added = firstArg<Iterable<NotificationLog>>().toList()
        notificationLogs += added
        added
    }
    // 읽기: 리스트에서 필터
    every {
        findMemberIdsByScheduledDateAndNotificationTypeAndMemberIdIn(any(), any(), any())
    } answers {
        val date = firstArg<LocalDate>()
        val type = secondArg<NotificationType>()
        val ids = thirdArg<Collection<Long>>()
        notificationLogs
            .filter { it.scheduledDate == date && it.notificationType == type && it.memberId in ids }
            .map { it.memberId }.distinct()
    }
}

이건 mock이 아니라 fake입니다. 왜냐하면:

• verify { saveAll(...) }로 호출 횟수를 감시하지 않음
• 대신 notificationLogs 리스트의 최종 상태를 단언
• 라이브러리(MockK)는 같지만, 사용 의도가 Fake

📖 Khorikov Unit Testing 6장: "out-of-process 의존성을 in-memory로 대체하는 건 fake다." — 딱 이 패턴.

진짜 Fake 클래스 대신 MockK를 쓰는 이유

Q: "진짜 FakeNotificationLogRepository 클래스를 만드는 게 더 깔끔하지 않나요?"

A: 깔끔하지만 유지비가 큽니다.

• JpaRepository에 메서드가 추가되면 Fake 클래스도 같이 수정해야 함
• MockK-as-Fake는 실제로 호출되는 메서드만 stub하면 됨
• 나머지 메서드를 호출하면 런타임에 "stubbing 안 됨" 에러 → 쓰지 않는 메서드는 구현 안 해도 되는 미니멀 전략

일단 현재까지 내가 이해한 부분으로는 Mockk은 원래 런던파 방식으로 Mock 객체를 만들어서 

특정 메서드가 실행되었다고 치고 호출 횟수를 검증하는 방식으로 내부 구현이 리팩토링되면 테스트가 깨지는 단점을 가지고 있고, Fake 객체는 실제 테스트하고자 하는 레포지토리에 메서드가 추가되면 이를 인터페이스로 만들어두고 페이크 클래스는 구현하는 형태로 만들어지기에 신규 기능 추가 시 컴파일이 깨지는 단점이 있다.

오히려 테스트 커버리지를 엄격하게 요구하는 조직이라면 신규 기능 추가 시 테스트가 깨지는 것은 장점일 수도? 라는 생각과 함께 이런식으로 하네스를 만들어보는 것도? 좋지 않을까?

일단 MockK가 어떻게 위 단점들을 우회할 수 있는지 궁금해서 추가 질문을 했다.

MockK이 이걸 어떻게 우회하나 (Claude 답변)

핵심은 MockK이 만드는 객체가 "타입은 만족하지만 행동은 비어있는 프록시" 라는 것.

kotlin

val repo = mockk<NotificationLogRepository>()

이 시점에서 repo는:

• 타입 시스템 입장에선 NotificationLogRepository를 완벽히 구현한 객체
• 실제로는 모든 메서드가 비어있음 (호출하면 MockKException 던짐)
• 컴파일러는 "어 30개 메서드 다 있네" 하고 통과시킴

이게 트릭이야. 상속받은 메서드를 우리가 직접 구현할 필요가 없어졌어. 바이트코드 수준에서 프록시가 자동 생성돼서 모든 메서드 시그니처를 만족시키거든.

Mock 객체 생성원리와 동작 방식을 공부하고 이해하고 있어야 좋을 것 같다.

그 다음에 필요한 메서드만 "살려준다"

kotlin

every { repo.saveAll(any<Iterable<NotificationLog>>()) } answers {
    val added = firstArg<Iterable<NotificationLog>>().toList()
    notificationLogs += added  // ← 외부 상태에 기록
    added
}

여기서 핵심 문법 두 가지를 구분해야 해:

returns (정적 Stub)

kotlin

every { repo.count() } returns 5L

호출되면 항상 5 반환. 인자 무관, 상태 무관. 전형적인 Stub.

answers (동적 Fake)

kotlin

every { repo.findByMemberId(any()) } answers {
    val id = firstArg<Long>()
    notificationLogs.filter { it.memberId == id }
}

호출 시점에 람다가 실행됨. 인자를 받고, 외부 상태를 읽고, 결과를 계산해서 반환. 이게 Fake처럼 동작하는 핵심이야.

firstArg(), secondArg(), thirdArg()는 호출 시 실제 들어온 인자를 꺼내오는 헬퍼야. 타입 추론을 위해 firstArg<Long>()처럼 제네릭을 명시해.

"왜 Fake냐" — 사용 의도가 정한다

문서에서 강조한 부분:

kotlin

// London 스타일 (Mock으로 쓰는 법)
verify(exactly = 1) { repo.saveAll(match { it.size == 1 }) }
//     ^^^^^^^ ─ "saveAll이 1번 호출됐는지" 검증 = 상호작용 검증

// Classicist 스타일 (Fake로 쓰는 법)
assertThat(notificationLogs).hasSize(1)
//                          ^^^^^^^^ ─ "최종 상태가 어떤지" 검증 = 상태 검증

똑같은 MockK 객체인데, 무엇을 단언하느냐에 따라 정체성이 갈려.

• verify { ... } 쓰면 → Mock 역할 → 런던파
• 외부 컬렉션의 최종 상태만 보면 → Fake 역할 → 고전파

라이브러리는 도구일 뿐이고, 학파를 결정하는 건 단언의 대상이야. 이게 문서에서 "MockK-as-Fake"라고 부르는 이유고.

정리: 두 문제를 어떻게 동시에 해결하나

MockK이 제공하는 건 "타입 시스템 만족"이고, Fake 의미론은 우리가 answers + 외부 상태 + 상태 단언으로 만들어내는 것이야. 두 도구의 좋은 점만 결합한 셈.

한 가지 함정

every { repo.findByX(...) } answers { ... }로 정의 안 한 메서드를 SUT가 호출하면 런타임에 MockKException: no answer found이 터져.

이게 단점처럼 보이지만 사실 장점이야. "내가 미처 생각 못한 호출 경로가 있다"는 신호거든. 진짜 Fake였으면 빈 구현이 조용히 빈 결과를 반환해서 거짓 통과하는 일이 생길 수 있어. MockK은 시끄럽게 실패해서 알려줘.

(이 동작이 부담스러우면 mockk<T>(relaxed = true)로 완화할 수 있는데, 고전파 의도라면 strict가 정답이야. 모르는 호출이 있으면 알아야 하니까.)

나의 생각 이전에는 Mock 객체를 사용하면 무조건 런던파 방식이라는 틀린 생각을 가지고 있었고, 이번 테스트 코드는 이를 깨는 계기가 되었다.

내용이 너무 길어지는 것 같아 실제 테스트 파일 구조 해부의 경우 다음 포스팅으로 진행하겠습니다~

POC 기반으로 MOA 서비스에 적용해보기 IOS_MOA 설치 [안드로이드 MOA 설치] (https://play.google.com/store/apps/details?id=com.moa.salary.app&hl=ko)

POC와는 다른 운영 환경

무중단 배포 Blue-Green 1편에서 설계하고 무중단 배포 Blue-Green 2편에서 실제로 검증까지 성공했다. while loop 돌려도 502 하나 없이 블루→그린 전환되는 걸 확인했으니 이제 MOA에 적용만 하면 되는 줄 알았다.

근데 MOA 프로젝트에 적용하려고 생각하다 보니 MOA 프로젝트는 cron job 기반의 스케줄러가 실행되고 있다는게 생각났다.

// 매 1분마다 FCM 알림 발송
@Scheduled(cron = "0 * * * * *", zone = "Asia/Seoul")
fun dispatchPendingNotifications() { ... }

// 매일 00:00 출퇴근 알림 배치 생성
@Scheduled(cron = "0 0 0 * * *", zone = "Asia/Seoul")
fun createDailyNotifications() { ... }

// 매일 03:00 월급 알림 배치 생성
@Scheduled(cron = "0 0 3 * * *", zone = "Asia/Seoul")
fun createPaydayNotifications() { ... }

스케줄러가 3개 있다. Blue-Green 배포에서 뭐가 문제냐면, 전환 시점에 Blue와 Green 두 컨테이너가 동시에 잠깐 떠있다. 이 10~30초 구간에 스케줄러가 터지면 두 컨테이너에서 같은 작업이 2번 실행된다.

특히 dispatchPendingNotifications는 매 분 돌아가니까 배포 중 거의 확실하게 중복 실행된다. 같은 FCM을 두 번 쏘면? 사용자가 알림을 두 번 받는다. 모아의 소중한 사용자들에게 나쁜 경험을 줄 수 없기에 고민을 시작했다. (클로드와 함께)

스케줄러 중복 실행, 어떻게 막을까?

방어할 방법은 여러 가지 있었다. 하나씩 비교해봤다.

처음엔 무시하고 스케줄링 시간을 피해서 배포하면 되지 않을까? 라는 생각을 잠시...ㅋㅋ

선택지 1 — 환경변수로 특정 컬러에서만 스케줄러 실행

가장 단순한 방법. DEPLOY_COLOR=blue인 컨테이너에서만 @Scheduled를 돌리게 만드는 거다.

@Component
@ConditionalOnProperty(name = "scheduler.active", havingValue = "true")
class NotificationDispatchScheduler { ... }

근데 이 방법은 전환 시점 제어가 불가능하다. Blue가 스케줄러를 돌리고 있다가 Green으로 전환되는 순간, Green의 스케줄러가 켜지기 전까지 공백이 생긴다. 반대로 두 개 모두 켜지는 순간도 생길 수 있다.

게다가 배포마다 환경변수를 조절해야 하는데, 그럼 deploy.sh에 추가 로직이 들어가야 하고, 실수 한 번으로 모든 스케줄링이 중단될 수 있다. 너무 위험하다.

선택지 2 — Redis 분산락

가장 많이 쓰는 방법. Redis + Redisson 조합. 성능도 좋고 안정적이다.

근데 MOA 서버에 Redis가 없다. 분산락 하나 쓰려고 Redis 인프라 구축하는 건 솔직히 배보다 배꼽이 크다. 사용자 80명 규모에서 Redis는 과하다는 게 1편에서 내린 결론이었는데, 여기서도 똑같다.

선택지 3 — DB 분산락 (ShedLock)

이미 MySQL이 돌고 있으니까 테이블 하나 추가해서 락으로 쓰자는 방법으로, ShedLock이라는 라이브러리가 이걸 쉽게 해준다.

@Scheduled(cron = "0 * * * * *")
@SchedulerLock(name = "dispatchNotifications", lockAtMostFor = "55s")
fun dispatch() { ... }

어노테이션 하나 붙이면 끝이다. 락 획득에 실패한 컨테이너는 자동으로 스킵한다. 추가 인프라도 없고, 라이브러리도 검증돼있다(GitHub star 2.5k+).

결론: ShedLock

• EC2 단일 서버 → Redis는 과함
• 환경변수 제어는 배포 시점 공백 문제 있음
• ShedLock은 기존 MySQL + 어노테이션 하나로 끝

1편에서 "현재 규모에 맞는 적정 기술"을 고민했던 것과 같은 맥락이다. 쿠버네티스를 안 쓰고 Nginx+Docker로 간 것처럼, 여기서도 Redis 안 쓰고 MySQL로 간다.

스케줄러 락만으로 정말 충분한가

ShedLock 붙이면 두 컨테이너 중 하나만 스케줄러를 실행한다. 동시 실행 자체는 이걸로 막힌다.

다만 ShedLock을 설정하면서 발송 로직을 들여다보다가, 동시 실행 방어와는 별개의 외부 I/O 일관성 문제가 보였다. 이 부분은 직접 해결하면서 별도 글로 정리할 예정이다.

매 1분 cron에서 lockAtMostFor: 55s, lockAtLeastFor: 30s로 설정했다.

• lockAtMostFor: 최대 55초 락 유지 (TTL). 프로세스가 죽어서 해제 못 해도 자동 만료된다
• lockAtLeastFor: 최소 30초는 유지. 빠르게 재실행되는 걸 막는다

55초로 잡은 이유는 1분 cron 주기 내에 락이 만료되어야 다음 분에 다시 돌 수 있어서다. 60초로 잡으면 경계에서 문제가 생긴다.

Graceful Shutdown이 @Scheduled까지 보호해줄까?

1편에서 이 주제를 짧게 다뤘는데, MOA에 적용하려니 다시 파봐야 했다.

server:
  shutdown: graceful
spring:
  lifecycle:
    timeout-per-shutdown-phase: 30s

이 설정이 보호하는 건 HTTP 요청 처리 스레드다. SIGTERM 받으면:

• Tomcat/Netty가 새 HTTP 요청 거부
• 진행 중인 HTTP 요청은 완료까지 대기
• 30초 후 강제 종료

근데 @Scheduled는 HTTP가 아니다. Spring의 TaskScheduler가 별도 스레드풀에서 돌린다. Graceful shutdown 대상에 안 들어간다.

시나리오:

12:00:00 dispatchNotifications 실행 시작 (FCM 100건 발송 중)
12:00:05 배포 전환 → Blue에 SIGTERM
12:00:05 Graceful shutdown 시작
         → HTTP 요청 보호 (하지만 FCM 스케줄러는 보호 안 됨)
12:00:35 30초 후 강제 종료
         → FCM 50건만 보내고 죽음 💥

해결: TaskScheduler 커스터마이즈

Spring 기본 TaskScheduler는 shutdown 시 진행 중 작업을 보호하지 않는데, 직접 빈을 등록하면 설정 가능하다.

@Bean
fun taskScheduler(): TaskScheduler =
    ThreadPoolTaskScheduler().apply {
        poolSize = 2
        setThreadNamePrefix("scheduler-")
        setWaitForTasksToCompleteOnShutdown(true)  // ← 실행 중인 작업 완료 대기
        setAwaitTerminationSeconds(60)              // ← 최대 60초 대기
    }

같이 application-prod.yml에서 shutdown 타임아웃도 늘려줬다:

spring:
  lifecycle:
    timeout-per-shutdown-phase: 60s  # 30초 → 60초

그리고 docker stop의 타임아웃도 Spring보다 길게 잡아야 한다. Spring이 60초 기다리는데 Docker가 30초에 SIGKILL 보내면 의미가 없다.

# deploy.sh에서
sudo docker stop --time 70 "${CURRENT_CONTAINER}"  # Spring 60초 + 여유 10초

이렇게 해서 "배치 실행 중 배포가 들어와도 배치를 끝까지 기다려주는" 구조를 만들었다.

배포 전략 — 왜 한번에 안 하나

Phase 1 (스케줄러 안전장치)과 Phase 2 (Blue-Green 인프라)를 한 번에 배포할까 고민했다. 한 PR로 묶으면 작업도 끝나고 깔끔하잖아.

근데 생각해보니까 위험 분산 관점에서 안 좋은 선택이었다.

한번에 배포 시:
  버그 발생 → ShedLock 문제? Graceful Shutdown 문제?
             Nginx 전환 문제? deploy.sh 문제?
             → 원인 파악에 시간 소요 → MTTR 증가

분리 배포 시:
  Phase 1 배포 → 2~3일 관찰 → 정상 → Phase 2 진행
  Phase 2에서 문제 → 원인은 Phase 2에 국한 → 즉시 롤백 가능

특히 ShedLock은 매일 한 번만 돌아가는 배치(00:00, 03:00)에 적용되니까, 로컬에서 확인했다고 끝이 아니다. 실제 운영 DB에서 매일 돌아갈 때 문제없는지 확인하려면 최소 하루는 기다려야 한다.

배포 순서는 이렇게 잡았다:

1일차: Phase 1 배포 (ShedLock + Graceful Shutdown)
       ├─ build.gradle.kts + SchedulingConfig
       ├─ 3개 스케줄러에 @SchedulerLock
       ├─ application-prod.yml에 graceful shutdown
       └─ shedlock 테이블 DDL 수동 실행

2~3일 관찰
       ├─ SELECT * FROM shedlock — 락 기록 확인
       ├─ 00:00 배치 정상 실행 확인
       ├─ 03:00 배치 정상 실행 확인
       └─ /actuator/health 응답 OK

4일차: Phase 2 배포 (Blue-Green 인프라)
       ├─ 서버 디렉토리 + Nginx upstream
       ├─ deploy.sh + rollback.sh
       ├─ deploy-main.yml 수정
       └─ while loop로 무중단 검증

DB 스키마 변경 — 조심해야 할 것

Blue-Green의 본질적 특징 중 하나는 전환 시점에 두 버전이 같은 DB를 본다는 것이다. 지금은 스키마 변경 없지만 앞으로 배포할 때 조심해야 한다.

위험한 변경은 2단계 배포로 처리:

1차 배포: 새 컬럼 추가 + 코드에서 새/기존 양쪽 지원
2차 배포: 기존 컬럼 제거

이건 Blue-Green의 단점이라기보다, 어떤 무중단 배포 방식이든 공통으로 신경 써야 할 부분이다.

정리

POC에서는 안 보였던 것들이 운영 서비스에서는 튀어나왔다.

1. 스케줄러 3개 → ShedLock으로 중복 실행 방어
2. FCM 멱등성 우려 → 현재 코드가 이미 배치 처리라서 스케줄러 락만으로 충분
3. @Scheduled는 graceful shutdown 밖 → TaskScheduler 커스터마이즈
4. 한 번에 배포 시 위험 → Phase 1 + 관찰 + Phase 2 분리 배포
5. DB 스키마 변경 → 하위 호환성 유지 필수

특히 재밌었던 건 "N+1 우려"였다. 분산락 패턴을 보고 반사적으로 "쿼리 많이 나가겠네" 싶었는데, 현재 코드를 뜯어보니 이미 saveAll()로 배치 처리가 되어있었다. 코드를 안 보고 패턴만 보고 판단하면 틀린다는 교훈.

"기존 코드가 이미 잘 해결하고 있는 문제를 추가 패턴으로 해결하려 하지 마라."

다음 편에서는 실제로 배포하면서 겪은 일들을 정리해볼 예정이다. Phase 1 적용 → 운영 관찰 → Phase 2 적용 → 무중단 검증까지의 실전 기록을 작성해보자.

1편: 설계 | 2편: POC 실전 | 3편: MOA 계획 | 4편: MOA 적용 실전 (작성 예정)

MOA 운영 서비스에 적용하기 전, POC 프로젝트로 먼저 검증해본 기록 IOS_MOA 설치 [안드로이드 MOA 설치] (https://play.google.com/store/apps/details?id=com.moa.salary.app&hl=ko)

서버 상황

POC를 위해 이전에 다른 토이 프로젝트를 위해 만들어둔 홈서버를 사용해보고자 한다. 이미 Docker랑 Nginx는 이미 깔려 있었기에 빠르게 시작해볼 수 있었다.

하지만 이전에 설정한 도메인이 만료됐고 서비스도 안 돌아가는 상태라서, 기존 설정을 다 걷어내고 Blue-Green용으로 새로 세팅하기로 했다.

기존 Nginx 설정을 뜯어보니

server {
    listen 80 default_server;
    return 301 https://$host$request_uri;
    location / {
        try_files $uri $uri/ =404;   # ← return 301 때문에 여기 도달 불가 (dead code)
    }
}

server {
    listen 443 ssl;
    server_name www.shinhan-sosol.store;
    ssl_certificate /etc/letsencrypt/live/www.shinhan-sosol.store/fullchain.pem;

    location /api/ {
        proxy_pass http://localhost:8080/api/;   # ← 이전 프로젝트 백엔드
    }
}

문제점이 몇 개 보였다.

1. SSL 인증서가 만료된 도메인 — 도메인이 만료됐으니 의미 없는 설정
2. proxy_pass가 localhost:8080으로 하드코딩 — Blue-Green은 upstream을 써야 하니까 교체 필요
3. dead code — return 301 아래의 location / { try_files... }는 절대 실행 안 된다

전부 걷어내고 새로 구성하기로 했다.

서버 세팅 — 단계별

1단계: 기존 상태 확인

docker --version          # Docker 설치 확인
nginx -v                  # Nginx 설치 확인
sudo docker ps            # 돌아가는 컨테이너 확인
sudo ss -tlnp | grep -E ':(80|8080|8081) '  # 포트 사용 현황

Docker, Nginx 모두 이미 깔려있었고, 돌아가는 컨테이너는 없었다.

2단계: 앱 디렉토리 + 상태 파일 생성

mkdir -p /home/hp-server/Desktop/project/zero-v1/logs
echo "blue" > /home/hp-server/Desktop/project/zero-v1/active-color
touch /home/hp-server/Desktop/project/zero-v1/deploy-history

active-color 파일에 blue를 넣어두면, 첫 배포 시 deploy.sh가 이걸 읽고 "현재 blue니까 다음은 green"으로 판단한다.

3단계: 기존 Nginx 설정 제거

sudo rm /etc/nginx/sites-enabled/default

이전 프로젝트 설정이 통째로 들어있던 파일을 제거해줬다.

4단계: Blue-Green Nginx 설정 생성

# upstream 설정 — deploy.sh가 이 파일을 배포마다 덮어씀
sudo tee /etc/nginx/conf.d/moa-upstream.conf > /dev/null <<'EOF'
upstream moa_backend {
    server 127.0.0.1:8080;
}
EOF

# server 블록 — 모든 요청을 upstream으로 프록시
sudo tee /etc/nginx/conf.d/zero-downtime.conf > /dev/null <<'EOF'
server {
    listen 80;
    server_name _;

    location / {
        proxy_pass http://moa_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_connect_timeout 5s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
    }
}
EOF

핵심은 moa-upstream.conf다. 이 파일의 server 127.0.0.1:8080;을 server 127.0.0.1:8081;로 바꾸고 nginx -s reload 하면 트래픽이 전환된다. deploy.sh가 이 작업을 자동으로 해준다.

5단계: Nginx 검증 + 적용

sudo nginx -t        # 설정 문법 검증
sudo nginx -s reload # 적용
curl -I http://localhost

curl 결과로 502 Bad Gateway가 나왔는데, 이게 정상이다. Nginx는 떠있지만 upstream인 8080에 아무 컨테이너도 없으니까 502가 맞다. 이제 첫 배포 후에 200이 나오면 된다.

6단계: GitHub Actions Self-Hosted Runner 설치

리포지토리 Settings → Actions → Runners → New self-hosted runner에서 안내하는 명령어를 따라 했다.

# runner 디렉토리에서
bash config.sh --url https://github.com/subsub97/blue-green --token <토큰>

실행하면 이런 화면이 뜬다:

"Connected to GitHub"가 뜨면 성공이다. 이후 Runner group, name, labels 등을 물어보는데 전부 Enter(기본값)로 넘기면 된다.

Configure 끝나고 서비스 등록:

sudo bash svc.sh install
sudo bash svc.sh start

7단계: GitHub Secrets 설정

리포지토리 Settings → Secrets and variables → Actions에서:

여기까지 하면 서버 세팅은 끝이다. main에 push하면 자동으로 빌드→배포가 시작된다.

첫 배포가 돌아가면 GitHub Actions에서 이런 로그를 볼 수 있다:

Current: blue(:8080), Next: green(:8081)으로 첫 배포가 green 컨테이너에 올라간다. 배포 완료 후 API를 찍어보면:

version에 git commit SHA, color에 green이 찍힌다. 이게 나오면 첫 배포는 성공이다.

트러블슈팅

서버 세팅하면서 생각보다 잔에러가 많이 났다. 하나하나 정리해보자.

1. chown: invalid user 'ubuntu:ubuntu'

$ sudo chown -R ubuntu:ubuntu /home/hp-server/Desktop/project/zero-v1/
chown: invalid user: 'ubuntu:ubuntu'

원인: 이 서버의 유저명이 ubuntu가 아니라 hp-server였다. 스크립트나 가이드에서 ubuntu를 기본으로 쓰는 경우가 많은데, 실제 서버의 유저명에 맞춰야 한다.

해결:

sudo chown -R hp-server:hp-server /home/hp-server/Desktop/project/zero-v1/

서버 세팅 가이드를 그대로 복붙하면 이런 데서 막힌다. 자기 서버의 유저명은 whoami로 확인하자.

2. must not run with sudo

$ sudo ./config.sh --url ...
Must not run with sudo

원인: GitHub Actions Runner의 config.sh는 root로 실행하면 안 된다. 보안 정책상 일반 유저로 실행해야 한다.

해결: root로 접속해있었으면 일반 유저로 전환 후 실행한다.

su - hp-server
cd ~/Desktop/project/zero-v1/actions-runner
bash config.sh --url https://github.com/... --token ...

3. sudo ./svc.sh: command not found

$ sudo ./svc.sh install
sudo: ./svc.sh: command not found

원인: sudo로 실행할 때 상대 경로가 제대로 해석이 안 되는 경우가 있다.

해결: bash로 직접 절대 경로를 지정해서 실행한다.

sudo bash /home/hp-server/Desktop/project/zero-v1/actions-runner/svc.sh install

4. svc.sh: No such file or directory

$ ls
actions-runner-linux-x64-2.333.1.tar.gz  bin  config.sh  env.sh  externals  run.sh ...

svc.sh가 파일 목록에 없었다.

원인: svc.sh는 config.sh를 실행한 후에 생성된다. config 과정에서 Runner 설정이 완료되면 서비스 등록에 필요한 파일들이 생긴다.

해결: config.sh를 먼저 실행하고 나면 svc.sh가 생성되어 있다.

5. config.sh: No such file or directory

~/Desktop/project/zero-v1 $ bash config.sh --url ...
bash: config.sh: No such file or directory

원인: config.sh는 actions-runner 디렉토리 안에 있는데, 한 단계 상위에서 실행하고 있었다.

해결:

cd ~/Desktop/project/zero-v1/actions-runner
bash config.sh --url ...

에러 메시지가 "No such file or directory"이면 일단 pwd로 현재 위치부터 확인하자.

6. Permission denied on config.sh

$ bash config.sh --url ...
touch: cannot touch '.env': Permission denied
System.UnauthorizedAccessException: Access to the path '..._diag' is denied.

원인: actions-runner 디렉토리를 root로 압축 해제해서, 파일 소유자가 root였다. 일반 유저(hp-server)로 실행하니까 권한이 없었던 거다.

해결:

sudo chown -R hp-server:hp-server ~/Desktop/project/zero-v1/actions-runner

소유권 변경 후 다시 config.sh 실행하니까 정상적으로 진행됐다.

7. curl에서 404 응답

$ curl http://58.227.208.141//api/deploy-info
# 404 Not Found

원인: URL에 슬래시가 두 개 들어갔다. //api/deploy-info가 아니라 /api/deploy-info여야 한다.

해결:

curl http://58.227.208.141/api/deploy-info

사소한 오타지만 404가 나오면 "API가 안 되나?" 하고 다른 데서 원인을 찾게 된다. URL부터 다시 확인하는 습관이 필요하다.

이해하고 넘어가야 할 것들

서버 세팅하면서 몇 가지 "이거 어떻게 되는 거지?" 싶었던 부분이 있었다. 정리해본다.

Q. deploy.sh는 어떻게 실행될까?

GitHub Actions의 deploy job이 self-hosted runner에서 실행한다.

main에 push
  → GitHub Actions 트리거
    → build job (GitHub 서버): 테스트 + Docker 이미지 빌드
    → deploy job (내 서버의 runner): deploy.sh 실행

방금 설치한 runner가 GitHub의 에이전트 역할을 해서, GitHub 리포에 있는 코드를 서버에 내려받고 실행해주는 거다.

Q. DEPLOY_COLOR는 어떻게 주입될까?

Spring Boot의 ${DEPLOY_COLOR:local}은 환경변수에서 값을 읽는다. 이 환경변수는 deploy.sh가 docker run할 때 넣어준다.

# deploy.sh의 Step 1에서 상태 파일을 읽고 다음 컬러를 결정
NEXT="green"  # (현재가 blue이므로)

# Step 3에서 컨테이너 시작할 때 환경변수로 주입
sudo docker run -e DEPLOY_COLOR="${NEXT}" -e APP_VERSION="${DOCKER_TAG}" ...

컨테이너 자체는 자기가 blue인지 green인지 모른다. deploy.sh가 상태 파일을 보고 결정해서 환경변수로 알려주는 거다.

무중단 검증

여기가 제일 중요한 부분이다. "진짜 무중단인가?"를 어떻게 확인했는지.

방법: 0.5초마다 요청을 계속 보내면서 배포

터미널 2개를 열고:

터미널 1 — 모니터링 (0.5초마다 요청)

while true; do
  RESULT=$(curl -s -o /tmp/resp.txt -w "%{http_code}" http://<서버IP>/api/deploy-info 2>/dev/null)
  BODY=$(cat /tmp/resp.txt)
  VERSION=$(echo "$BODY" | grep -o '"version":"[^"]*"' | head -1)
  COLOR=$(echo "$BODY" | grep -o '"color":"[^"]*"' | head -1)
  echo "$(date '+%H:%M:%S') | HTTP ${RESULT} | ${VERSION} | ${COLOR}"
  sleep 0.5
done

터미널 2 — 코드 수정 후 push해서 배포 트리거

git add . && git commit -m "test deploy v2" && git push

결과

22:30:01 | HTTP 200 | "version":"abc1234" | "color":"green"
22:30:01 | HTTP 200 | "version":"abc1234" | "color":"green"
22:30:02 | HTTP 200 | "version":"abc1234" | "color":"green"
... (배포 진행 중 — 계속 200) ...
22:31:15 | HTTP 200 | "version":"abc1234" | "color":"green"
22:31:15 | HTTP 200 | "version":"def5678" | "color":"blue"    ← 여기서 전환!
22:31:16 | HTTP 200 | "version":"def5678" | "color":"blue"
22:31:16 | HTTP 200 | "version":"def5678" | "color":"blue"

실제로 돌려본 결과:

502가 단 하나도 없다. 모든 요청이 HTTP 200이고, version과 color가 한 순간에 green→blue로 바뀌는 걸 볼 수 있다. 전환 사이에 요청 실패가 없었다.

이걸로 Blue-Green 무중단 배포가 정상 동작한다는 걸 확인했다.

판단 기준

정리

EC2 단일 서버에서 Nginx + Docker + GitHub Actions로 Blue-Green 무중단 배포를 구현하고 검증까지 완료했다.

핵심 포인트를 정리하면:

1. Nginx upstream 전환이 Blue-Green의 핵심이다. 새 컨테이너가 완전히 준비된 후에 트래픽을 전환하니까 다운타임이 0이다.

2. Health Check만으로는 부족하다. Nginx를 경유하는 Smoke Test까지 해야 "실제 사용자 관점에서 정상"인지 확인할 수 있다.

3. 서버 세팅에서 삽질이 제일 많았다. 코드 구현보다 Runner 권한 문제, 경로 문제, 소유권 문제를 잡는 데 시간이 더 걸렸다.

4. 자동 롤백 구조가 있으니까 배포가 편하다. Health check 실패하면 기존 컨테이너가 계속 돌아가니까 사용자 영향 없이 롤백된다.

이제 이 구조를 MOA 운영 서비스에 적용하면 되는데, POC에서는 안 다뤘지만 실제 MOA에 붙이면서 고민해야 할 것들이 있다.

다음 — MOA에 실제 적용하면서 다뤄볼 것들

POC는 순수한 API 서버였다. 근데 MOA는 그렇게 단순하지 않다. 실제로 적용하면서 추가로 풀어야 할 문제들이 있는데, 미리 정리해둔다.

배치 작업과 배포의 충돌

MOA에는 매일 12시에 돌아가는 알림 배치가 있다. 만약 이 배치가 FCM을 100건 보내는 도중에 배포가 들어오면?

12:00:00  Blue에서 알림 배치 시작 (FCM 100건 발송 중...)
12:00:30  배포 → Nginx 전환 → Blue에 SIGTERM
12:00:32  graceful shutdown 시작
          → HTTP 요청은 보호됨
          → ★ 근데 @Scheduled 배치는 HTTP 요청이 아님
12:01:02  30초 후 강제 종료 → 배치가 50건만 보내고 죽음 💥

server.shutdown: graceful이 보호하는 건 HTTP 요청뿐이다. @Scheduled 배치는 graceful shutdown 대상이 아니라서, Spring이 컨텍스트를 닫으면 그냥 중간에 끊긴다.

이 문제를 어떻게 풀 건지 — 배치를 graceful shutdown 대상에 포함시키는 방법, 배치 자체를 멱등하게 만드는 방법, 배포 전 배치 실행 여부를 체크하는 방법 등을 MOA 적용편에서 다뤄보려 한다.

그 외 MOA 적용 시 고려사항

• DB 스키마 변경이 있는 배포: Blue와 Green이 동시에 같은 DB를 보는데, 컬럼 삭제 같은 breaking change가 있으면 Blue가 터진다. 하위 호환성을 유지하면서 2단계로 나눠 배포해야 한다.
• 기존 CI/CD 파이프라인 전환: 현재 MOA의 docker stop → docker run 방식을 deploy.sh 기반으로 교체하면서 기존 workflow를 어디까지 건드릴지.
• SSL 환경에서의 Nginx 설정: POC는 HTTP로 테스트했는데, MOA는 HTTPS(Let's Encrypt)가 걸려있다. upstream 설정을 SSL server 블록 안에 넣는 구조로 바꿔야 한다.

이런 부분들을 실제로 적용하면서 다음 글에 정리해보겠다.

claude + gemini이와 함께 공부하며 작성했습니다.

MOA 운영 서비스에 적용하기 전, POC 프로젝트로 먼저 검증해본 기록 IOS_MOA 설치 [안드로이드 MOA 설치] (https://play.google.com/store/apps/details?id=com.moa.salary.app&hl=ko)

배포할 때마다 서버가 죽는다

현재 MOA 서비스의 배포 방식은 이렇다.

docker stop moa-server     # ← 여기서부터 서비스 중단
docker rm moa-server
docker pull new-image
docker run moa-server      # ← Spring Boot 기동까지 10~20초

docker stop을 하는 순간부터 새 컨테이너의 Spring Boot가 완전히 뜰 때까지 약 10~30초 동안 서비스가 죽어있다. 이 시간 동안 사용자가 앱을 열면 502 Bad Gateway가 뜬다.

주 1회 배포면 월간 다운타임이 약 2분인데, 솔직히 수치만 보면 대단한 건 아니다. 근데 문제는 "배포 = 서비스 중단"이라는 구조 자체다. 배포할 때마다 긴장하게 되고, 사용자가 적은 새벽에만 배포하게 되고, 그러다 보면 배포 주기가 점점 길어진다.

무중단 배포는 이 구조적 문제를 없애는 거다. 배포해도 사용자한테 영향이 없으니까 언제든 편하게 배포할 수 있다.

왜 Blue-Green인가

무중단 배포 전략은 여러 가지가 있는데, 비교해보면 이렇다.

MOA에서 Blue-Green을 선택한 이유는 명확했다.

1. EC2 서버가 1대 → Rolling Update는 서버가 여러 대 있어야 가능하니까 불가
2. Nginx가 이미 깔려있음 → 추가 인프라 없이 upstream 설정만 바꾸면 됨
3. DAU 80명 → Canary의 "일부 트래픽 검증"이 통계적으로 무의미
4. 즉시 롤백 → Nginx reload 한 번이면 1초 안에 이전 버전으로 복원

쿠버네티스 쓰면 더 깔끔하겠지만, 120명 규모 서비스에 K8s는 과하다. 컨트롤 플레인만 해도 메모리 2GB 이상 잡아먹는데, 그 리소스와 학습 비용을 감당할 이유가 없었다. (이후 학습후 롤링 배포를 도전해보자!!)

전체 아키텍처

Before — 단일 컨테이너

Client → Nginx(:80) → moa-server(:8080)
                       배포 시 stop → start = 다운타임

After — Blue-Green

Client → Nginx(:80) → upstream(전환 가능)
                       ├─ Blue  (:8080)  ← 현재 활성
                       └─ Green (:8081)  ← 대기/신규 배포

핵심은 Nginx의 upstream 설정을 바꾸고 reload하는 것이다. 새 컨테이너가 완전히 준비된 후에 트래픽을 전환하니까, 클라이언트 입장에서는 끊김이 없다.

nginx -s reload가 무중단인 이유도 재밌는데, Nginx는 Master-Worker 모델이라 reload 시 기존 Worker는 현재 처리 중인 커넥션만 마무리하고, 새 Worker가 새 설정으로 요청을 받는다. 그래서 어떤 커넥션도 끊기지 않는다.

배포 플로우 전체 그림

GitHub에 push
  → GitHub Actions (build job)
    → 테스트 실행
    → Docker 이미지 빌드 + Docker Hub push
  → GitHub Actions (deploy job) — 서버의 self-hosted runner가 실행
    → deploy.sh 실행
      → Step 1: 현재 활성 컬러 확인 (blue/green)
      → Step 2: 새 이미지 pull
      → Step 3: 새 컨테이너 시작 (대기 포트에)
      → Step 4: Health check (최대 60초)
      → Step 5: Nginx upstream 전환 + reload
      → Step 6: Smoke test (nginx 경유 확인)
      → Step 7: 이전 컨테이너 graceful shutdown
      → Step 8: 상태 파일 + 배포 이력 업데이트
      → Step 9: Docker 이미지 정리

전체 과정에서 클라이언트 요청이 실패하는 구간은 없다. Step 4까지는 기존 컨테이너가 트래픽을 처리하고, Step 5에서 전환한 후에는 새 컨테이너가 처리한다.

구현 코드 상세

버전 확인 API — DeployInfoController

배포 후 "진짜 새 버전이 뜬 건가?"를 확인할 수 있는 API가 필요했다. /api/deploy-info를 호출하면 현재 버전, 컬러, 기동 시간을 반환한다.

@RestController
@RequestMapping("/api")
public class DeployInfoController {

    private final String version;
    private final String color;
    private final Instant startedAt;

    public DeployInfoController(
            @Value("${app.version:dev}") String version,
            @Value("${app.deploy-color:local}") String color) {
        this.version = version;
        this.color = color;
        this.startedAt = Instant.now();
    }

    @GetMapping("/deploy-info")
    public DeployInfoResponse deployInfo() {
        return DeployInfoResponse.of(version, color, startedAt);
    }
}

APP_VERSION과 DEPLOY_COLOR는 Docker 컨테이너 실행 시 환경변수로 주입된다. 로컬에서 ./gradlew bootRun으로 실행하면 환경변수가 없으니까 기본값인 "dev", "local"이 들어간다.

실제 배포 후 이 API를 호출하면 이런 응답이 온다:

처음에 이 부분이 좀 헷갈렸는데, 결국 이런 흐름이다:

deploy.sh에서 현재 상태 파일 읽음 → "blue"
→ 다음 컬러는 "green"
→ docker run -e DEPLOY_COLOR=green -e APP_VERSION=abc123 ...
→ Spring Boot가 환경변수 읽음 → ${DEPLOY_COLOR:local} → "green"

Graceful Shutdown 설정 — application-prod.yaml

server:
  shutdown: graceful

spring:
  lifecycle:
    timeout-per-shutdown-phase: 30s

management:
  endpoints:
    web:
      exposure:
        include: health
  endpoint:
    health:
      show-details: never

server.shutdown: graceful 이 없으면 SIGTERM 받았을 때 진행 중인 요청을 바로 끊어버린다. 이 설정을 넣으면 새 요청은 거부하되, 처리 중인 요청은 완료할 때까지 기다려준다. 최대 30초.

show-details: never로 한 이유는 보안 때문이다. health endpoint는 인증 없이 접근 가능한데, 상세 정보에 DB 호스트나 디스크 경로 같은 인프라 정보가 포함될 수 있다.

Dockerfile — Multi-stage 빌드

# Stage 1: Build
FROM eclipse-temurin:21-jdk AS builder
WORKDIR /build
COPY gradle/ gradle/
COPY gradlew settings.gradle build.gradle ./
RUN chmod +x gradlew && ./gradlew dependencies --no-daemon || true
COPY src/ src/
RUN ./gradlew bootJar --no-daemon -x test

# Stage 2: Runtime
FROM eclipse-temurin:21-jre
WORKDIR /app
COPY --from=builder /build/build/libs/*.jar app.jar
RUN mkdir -p /app/logs
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

2단계로 나눈 이유는 이미지 크기 때문이다. JDK(450MB) 대신 JRE(200MB)를 런타임에 쓰면 이미지가 절반 이하로 줄어든다. 배포마다 이미지가 쌓이니까 이 차이가 디스크 관리에서 꽤 중요하다.

Gradle 의존성을 먼저 다운받는 레이어를 분리한 것도 포인트인데, 소스 코드만 바뀌면 의존성 레이어는 Docker 캐시에서 가져오니까 빌드 시간이 확 줄어든다.

배포 스크립트 — deploy.sh

이게 Blue-Green 배포의 핵심이다. 전체 코드는 길어서 주요 부분만 짚어보면:

동시 배포 방지 (flock)

exec 200>"${LOCK_FILE}"
if ! flock -n 200; then
    echo "[ERROR] Another deployment is already running. Exiting."
    exit 1
fi

누군가 SSH로 직접 deploy.sh를 실행하는 경우를 대비한 OS 수준의 파일 락이다. GitHub Actions의 concurrency 설정과 이중으로 방어한다.

해당 부분에 대해서 claudeCode에게 리뷰를 받았고 지적 받았다. 혼자서는 생각해볼 수 없는 부분인데 참고할 수 있어서 너무 좋은듯

Health Check

for i in $(seq 1 ${HEALTH_CHECK_MAX_RETRY}); do
    HEALTH=$(curl -sf "http://localhost:${NEXT_PORT}/actuator/health" 2>/dev/null || true)
    if echo "${HEALTH}" | grep -q '"status":"UP"'; then
        echo "[Step 4] Health check PASSED"
        break
    fi
    if [ "${i}" -eq "${HEALTH_CHECK_MAX_RETRY}" ]; then
        # 실패 → 새 컨테이너 정지, 기존 유지
        sudo docker stop "${NEXT_CONTAINER}" || true
        sudo docker rm "${NEXT_CONTAINER}" || true
        exit 1
    fi
    sleep ${HEALTH_CHECK_INTERVAL}
done

최대 30번 × 2초 = 60초 동안 health check를 시도한다. 실패하면 새 컨테이너를 정리하고 스크립트를 종료한다. 기존 컨테이너는 건드리지 않으니까 사용자 영향 없이 자동 롤백되는 셈이다.

Smoke Test

SMOKE_RESULT=$(curl -sf "http://localhost/api/deploy-info" 2>/dev/null || true)
if echo "${SMOKE_RESULT}" | grep -q "\"version\":\"${DOCKER_TAG}\""; then
    echo "[Step 6] Smoke test PASSED"
else
    # Nginx를 이전 컬러로 되돌림
    ...
fi

Health check와 Smoke test의 차이가 중요한데:

• Health check: 컨테이너에 직접 요청 (port 8081)
• Smoke test: Nginx를 경유해서 요청 (port 80)

Nginx upstream 설정이 잘못되면 health check는 통과해도 사용자는 502를 볼 수 있다. Smoke test는 실제 사용자 경로를 그대로 테스트하는 거다.

GitHub Actions — deploy.yml

name: Blue-Green Deploy

on:
  push:
    branches: [ main ]

concurrency:
  group: deploy-production
  cancel-in-progress: false  # 진행 중인 배포는 절대 취소하지 않음

cancel-in-progress: false가 핵심이다. true로 하면 빠른 연속 push 시 진행 중인 배포가 취소되는데, deploy.sh가 nginx 전환 중간에 죽으면 nginx가 존재하지 않는 컨테이너를 가리키게 될 수 있다. false로 하면 첫 번째 배포가 끝날 때까지 두 번째가 큐에서 대기한다.

deploy job은 self-hosted runner에서 실행되는데, 리포에서 scripts/ 폴더만 sparse-checkout으로 가져와서 deploy.sh를 실행한다. 실제로 GitHub Actions에서 deploy가 돌아가면 이런 로그가 나온다:

Current가 blue(:8080)이고 Next가 green(:8081)인 걸 볼 수 있다. 다음 배포 때는 반대로 green→blue가 된다.

deploy:
  needs: build
  runs-on:
    - self-hosted

  steps:
    - name: Checkout deploy scripts
      uses: actions/checkout@v4
      with:
        sparse-checkout: |
          scripts

    - name: Run Blue-Green Deploy
      env:
        DOCKER_IMAGE: ${{ secrets.DOCKER_USERNAME }}/zero-downtime
      run: |
        chmod +x scripts/deploy.sh
        sudo -E bash scripts/deploy.sh "${{ needs.build.outputs.docker_tag }}"

롤백 전략

자동 롤백: Health check 실패하면 새 컨테이너 정리하고 끝. 기존 컨테이너가 계속 돌고 있으니까 다운타임 없음.

수동 롤백: GitHub Actions UI에서 rollback.yml을 트리거하면 된다. 이전 태그를 입력하거나, 비워두면 deploy-history 파일에서 직전 성공 태그를 자동으로 찾아서 재배포한다.

# .github/workflows/rollback.yml
on:
  workflow_dispatch:
    inputs:
      docker_tag:
        description: 'Rollback할 Docker 태그. 비우면 직전 버전으로 롤백'
        required: false

롤백도 결국 deploy.sh를 재실행하는 거라서, health check, smoke test 등 동일한 안전장치가 적용된다.

놓치기 쉬운 것들

구현하면서 처음에 생각 못 했다가 나중에 추가한 부분들이 있다.

1. Docker 이미지가 쌓인다

배포마다 ~200MB 이미지가 pull된다. EC2 t2.micro 기본 디스크가 8GB인데, 25번 정도 배포하면 꽉 찬다. 디스크 풀 나면 docker pull이 실패하면서 배포가 막힌다. deploy.sh 마지막에 docker image prune -f를 넣어서 해결했다.

2. 로그에서 blue/green 구분이 안 된다

두 컨테이너가 같은 볼륨에 로그를 쓰는데, 태깅이 없으면 에러 로그가 이전 버전에서 난 건지 새 버전에서 난 건지 알 수가 없다. 로그 패턴에 [${DEPLOY_COLOR}]을 넣어서 해결했다.

3. 배포 이력이 없으면 롤백이 느리다

장애 나서 롤백하려는데 "이전 버전 태그가 뭐였지?" → GitHub Actions 로그 뒤져야 한다. deploy-history 파일에 매 배포마다 timestamp|color|tag|status를 기록해두니까 rollback.sh가 직전 태그를 바로 찾을 수 있다.

4. 첫 배포에서 스크립트가 죽을 수 있다

최초 배포 시 "이전 컨테이너"가 없는데, docker stop을 하면 에러가 난다. set -e 때문에 스크립트가 바로 죽는다. 모든 docker stop/rm 앞에 docker inspect로 존재 확인 + || true로 방어했다.

다음 글에서는 실제 서버에 세팅하면서 겪은 트러블슈팅과 무중단 검증 결과를 정리해보겠다.

2편: 실전 — 서버 세팅, 트러블슈팅, 무중단 검증

문제 상황

팀원 휴가를 조회하는 API를 만들고 있었다. 응답에는 작성자 이름(=유저 이름)이 포함돼야 한다. 하지만 휴가 테이블에는 이름을 직접 저장하지 않고, USER 테이블의 PK를 FK로 들고 있는 전형적인 설계다. 그래서 자바 세상(JPA)에서는 휴가 엔티티에서 참조를 통해 유저 이름에 접근했다.

// VacationHistory.java (요약)
@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "user_id")
private User user; // author, writer … 어떤 네이밍이 더 나을까요?

네이밍은 author, writer 중 하나면 충분히 직관적이라고 생각하지만, 더 좋은 의견이 있다면 댓글 부탁드립니다!

로그로 본 N + 1

다음 스크린샷은 User 테이블을 추가 조회하는 쿼리가 연달아 날아가는 모습이다.

휴가 3건이면 쿼리가 3번, 앞으로 유저 수가 100명, 1000명 늘어나면 1000번…. 이건 누가 봐도 비효율이다. “차라리 한 방에 가져오면 안 될까?”

JOIN VS FETCH JOIN

👉 결론부터: JOIN FETCH를 쓰면 N + 1을 없앨 수 있지만, ⁠⁠꼭 필요한 경우에만, 그리고 페이징 제약을 기억하면서 사용하자.

JOIN (일반 조인)

@Query("""
SELECT vh
FROM VacationHistory vh
JOIN   vh.user u
WHERE  vh.startDate >= :lastMonthLastWeek
  AND  vh.endDate   <= :nextMonthFirstWeek
  AND  vh.department.id = :departmentId
ORDER BY vh.startDate
""")
List<VacationHistory> findAllByDepartment(...);

• SQL 차원에서는 JOIN 으로 묶여 한 번에 가져오는 것처럼 보인다.
• 하지만 영속성 컨텍스트에는 VacationHistory 만 저장되고, User 는 프록시 상태로 남는다.
• vh.getUser().getName() 이 호출되는 순간 추가 SELECT 가 날아가 N + 1 발생.
• 연관 필드를 EAGER 로 바꿔도 별도 SELECT 나 조인 으로 한 번 더 불러오는 건 마찬가지일 수 있다.

JOIN을 사용해서 문제를 해결하기 위해서는 DTO 프로젝션 방법을 선택해야한다. (다음글에서 정리)

JOIN FETCH

@Query("""
SELECT vh
FROM VacationHistory vh
JOIN FETCH vh.user u
WHERE  vh.startDate >= :lastMonthLastWeek
  AND  vh.endDate   <= :nextMonthFirstWeek
  AND  vh.department.id = :departmentId
ORDER BY vh.startDate
""")

• 단일 쿼리에 VacationHistory와 User 를 모두 끌어와서 즉시 영속성 컨텍스트에 적재.
• 이후 vh.getUser() 를 호출해도 추가 쿼리가 없다 → N + 1 종결
• 내부적으로는 SQL JOIN 으로 구현되지만, JPA가 중복 행을 병합해 엔티티는 하나씩만 유지한다.

항상 FETCH JOIN을 사용하면 안될까?

👍 장점 N + 1 해결 & 직렬화에도 유리

복잡한 매핑이라도 쿼리 1회로 데이터 확보

⚠️ 주의할 점 불필요한 데이터까지 한 번에 끌어와서 메모리 낭비할 수 있다.

컬렉션(fetch join) + 페이징을 동시에 쓰면,

(Hibernate 기준) DB단 LIMIT/OFFSET이 무력화되고

모든 데이터를 긁어온 뒤 메모리 페이징 → OOM 위험하다.

마무리

N + 1 문제가 발생한 것과 어떻게 문제를 해결할 수 있는지 간단하게 작성해보았다. 하지만 아직 구체적인 상황에 따라서 최적의 선택을 하는 방법까지 학습하지 못했다. 무조건 FETCH JOIN을 사용하는 것도 올바른 방법도 아니라고 생각한다. 관련된 내용을 정리해서 추가 글을 작성해야겠다.

대답할 수 없어서 글을 쓰면서 다음엔 대답할 수 있는 개발자가 되어보자

먼저 결론부터 말하면

1. 비대칭 키는 느리다.
2. 클라이언트의 공개키를 서버가 기억해야 하므로 무상태성이 깨진다.

대칭키와 비대칭키 이해하기

먼저 대칭키랑 암호화, 복호화에 사용하는 키가 동일하다.

비대칭키/ 공개키 : 암호화, 복호화에 사용하는 키가 서로 다르다.

• 대칭키

  세션키, 시크릿 키, 공유 키, 대칭키 ,단용키 라고도 부른다.

  • 장점
    • 구현이 용이하다.
    • 데이터를 암호화하기 위한 연상이 빨라 대용량 데이터 암호화에 적합하다.
    • 기밀성을 제공한다.
  • 단점
    • 강한 보안을 위해 키를 주기적으로 교환해주는 것이 좋다.
    • 키 탈취 및 관리가 어렵다.
    • 무결성 지원이 부분적으로만 가능하다.
    • 부인 방지 기능을 제공하지 못한다.

• 비대칭키

  • 장점

    • 키 분배 및 키 관리가 용이하다.
    • 기밀성, 무결성을 지원한다.
    • 부인 방지 기능을 제공한다.
    • 암호학적 문제를 해결할 수 있다.

  • 단점

    • 상대적으로 키의 길이가 길다.
    • 연산속도가 느리다.

  • 수신자의 공개키로 암호화하면 이를 수신자의 개인키로 복호화해서 볼 수 있다. (수신자만 해독가능)*

    계속 헷갈리는 부분

    서버는 개인키를 소유하고 있다 절대 노출되면 안되는 키다.

    공개키는 누구나 사용할 수 있다.

    그래서 클라이언트는 공개키로 암호화하고 서버에 보내면 이를 해독할 수 있는건 오직 개인키 뿐이니까 안전하게 요청을 보낼 수 있다.

    자 그럼 서버에서 개인키로 암호화해서 클라이언트로 보내면 중간에 누가 탈취하면 누구나 공개키를 알 수 있으니까 응답 내용을 다른 사람이 볼 수 있는거 아닐까?

  • 먼저 결론부터 말하면 서버는 민감 정보를 보내지 않는다.*

    진짜 서버가 보낸 응답인지 검증할 뿐이다. 개인키로 암호화한 것만 공개키로 열리니까

    이게 진짜 서버에서 왔다 변조가 안됐다는걸 보장할 수 있는거다.

  • 그럼? 내용은 어떻게 암호화할건데요? (기밀성 보장은 어떻게?)*

    내가 자주 헷갈렸던 부분은 서버에서 대칭키를 만들어서 개인키로 암호화하고 클라이언트랑 공유한다고 생각했다. 하지만 반대였다. 클라이언트가 공개키로 암호화해서 서버에 대칭키를 공유하는 것이다.

    그럼 서버만 해독할 수 있는 공개키로 암호화 했기 때문에 안전하게 대칭키를 공유할 수 있다.

  • 여기서 궁금한 건 그럼 비대칭 키만 이용해서는 계속 통신할 수 없을까?*

    서버도 개인키/공개키를 가지고 있고 클라이언트도 개인키/공개키를 가지고 있다면 각자의 공개키로 암호화해서 보내는 방식으로 통신은 가능할 것이다.

    근데 이게 대칭키를 공유해서 사용하는 방식보다 느리다고 한다.

  1. 느리다. 비대칭 키 왜 느릴까?

     구조적인 차이 때문이라고 한다.

     항목	비대칭키 (RSA, ECC)	대칭키 (AES 등)
     암호화/ 복호화 속도	느림(1000~ 1000배 이상 느림)	매우 빠름
     키 길이	길다( 2048 ~ 4096 bit)	짧다(128~256bit)
     CPU 사용량	높음 (수학적으로 무거운 연산)	낮음
     데이터 양	적은 데이터에 적합	큰 데이터에 적합

  WHY? 비대칭키랑 대칭키의 암호화 방식이 다를까?

  둘 다 암호화한다는 목적이 같은데 왜 서로 다른 것을 사용하고 그래서 암호화, 복호화 속도까지 느리게할까?

  좋은게 좋은거라고 안전하고 빠른 방법을 둘 다 선택해서 사용하면 되는거 아닐까? 라는 의문이 든다.

  먼저 RSA / ECC 는 키 공유 + 인증 을 위한 알고리즘 이라고 한다.

  AES는 “데이터 보안”을 위한 알고리즘이다.

  이렇게 작성해두면 잘 와닿지 않는다.

  좀 풀어서 얘기하면 비대칭 키 방식은 우체통과 같다. 누구나 편지를 넣을 수 우체통 키를 가지고 있는 우체부만 편지를 꺼낼 수 있다. RSA/ ECC 는 우체통과 같은 구조를 만들어주는 알고리즘이다. 근데 이 알고리즘은 CPU 사용량이 높기에 많이 사용한다면 통신 비용이 증가할 것이다.

  이에 비해 단순한 구조르 가진 대칭키가 있다. 대칭키는 예를 들자면 현관문 전자 비밀번호 같은 것 이다. 비밀번호를 아는 누구나 출입 가능한다. 근데 한가지 문제점은 이 비밀번호르 어떻게 안전하게 공유할 것 이냐는 것이다.

  자 이 문제를 해결하기 위해서 HTTPS는 비대칭키랑 대칭키를 적절히 함께 사용하는 것이다.

  1. 서버는 클라이언트의 공개키를 알기 힘들다

     기본적으로 HTTPS 에서는 클라이언트는 익명이다.

     • 브라우저가 서버에 접속할 때 → 클라이언트의 공개키는 전달되지 않음

       그렇기 때문에 암호화해서 줄 수가 없을 것이다.

    **그럼 클라이언트가 공개키를 서버에 보내면 되잖아?**

    키 관리가 복잡할 것 같다.

    서버는 클라이언트마다 키를 관리하고 그에 맞는 공개키로 암호화해서 보내야 하니까 
    무상태를 유지 할 수 없을 것이다.

    그리고 클라이언트가 보낸 공개키가 진짜냐?를 검증할 수 있는 방법이 없다. (근데 검증을 해야할까?)

public interface Filter {

    public default void init(FilterConfig filterConfig) throws ServletException {}

    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException;

    public default void destroy() {}

}

LogFilter implements Filter()

    <script>
      const app = new Vue({
        el: '#root',
        data: {},
        methods: {},
      });
    </script>

<script>
      const app = new Vue({
        el: '#root',
        data: {
          first: '',
          second: '',
          value: '',
          result: '',
        },
        methods: {},
      });
    </script>