1️⃣ 파일 스토리지 

서버가 1대일 때는 로컬 디스크에 파일 저장해도 문제 없습니다.

하지만 2대가 되면:

• WAS1에 업로드
• 다음 요청은 WAS2로 라우팅
• 파일 없음 → 오류

해결 방법

• S3 같은 오브젝트 스토리지
• EFS 같은 공유 스토리지
• 최소한 공통 마운트 경로

👉 실무에서 세션보다 파일 문제로 장애나는 경우가 많습니다.

2️⃣ DB 커넥션 수

서버가 2대가 되면:

• DB 커넥션 풀도 2배
• Auto Scaling이면 순간적으로 3~4배

DB max_connections 초과로 장애 발생 가능.

체크 포인트

• HikariCP maxPoolSize
• RDS max_connections
• 커넥션 사용 패턴

3️⃣ 캐시 일관성

서버 메모리 캐시 사용 시:

• WAS1 캐시
• WAS2 캐시

데이터 불일치 발생.

해결

• Redis 등 외부 캐시 사용
• 로컬 캐시는 TTL 짧게

4️⃣ 스케줄러/배치 중복 실행

Spring @Scheduled 같은 작업이 있다면:

서버 2대에서 동일 작업이 동시에 실행됩니다.

예:

• 만료 세션 정리
• 예약 상태 갱신
• 정산 배치

해결

• 분산 락 (Redis, DB lock)
• Leader election
• 별도 배치 서버 분리

👉 이거 고려 안 하면 이중화 후 바로 사고 납니다.

5️⃣ 로그/모니터링

서버가 1대일 때는 로그 파일 하나만 보면 됩니다.

2대 이상이면:

• 로그 중앙 수집 필요
• 장애 시 어느 서버 문제인지 파악 필요

최소 구성

• 중앙 로그 수집
• 헬스체크 모니터링
• 5xx 알람

6️⃣ 환경 변수 / 암호화 키

서버 간 다음 값이 동일해야 합니다:

• JWT secret
• 세션 암호화 키
• 쿠키 서명 키
• SSO 관련 키

다르면 서버 간 인증 불일치 발생.

7️⃣ 트랜잭션 / 동시성

특히 예약/정산 시스템이라면:

• 중복 요청
• 동시 처리
• 재시도 정책

이중화되면 동시성 이슈가 더 자주 드러납니다.

8️⃣ 배포 전략

서버 2대 이상이면:

• 무중단 배포?
• 롤링?
• 블루그린?

DB 마이그레이션 전략도 포함됩니다.

📌 정리

이중화 시 고려해야 할 핵심은:

1. 세션
2. 파일
3. 캐시
4. 배치/스케줄러
5. DB 커넥션
6. 환경 키 일관성
7. 모니터링
8. 배포 전략

한 줄 요약

클라우드에서 서버 이중화는 인프라 설정이 아니라
애플리케이션 상태와 운영 전략의 문제다

클라우드에서 서버 이중화는 어렵지 않다.

• VPC 구성
• 서로 다른 AZ에 WAS 2대 이상 배치
• Load Balancer 연결
• Auto Scaling 설정

이 정도는 이제 기본이다.

하지만 실제 운영에서 문제를 일으키는 지점은 따로 있다.

서버 이중화의 핵심은 인프라가 아니라 세션 설계다.

1. 왜 세션이 문제인가

서버가 1대일 때는 문제가 없다.

하지만 2대 이상이 되면 상황이 달라진다.

로그인 후 다음 요청이 다른 서버로 전달되면
세션이 존재하지 않아 로그인이 풀릴 수 있다.

특히 공공기관 시스템이나 SSO 연동 구조에서는
로그인 이후 애플리케이션이 자체 세션을 유지하는 경우가 많다.

이때 세션이 서버 메모리에 있다면 이중화는 불완전하다.

2. 클라우드 이중화 시 세션 설계 방식

① Sticky Session (임시방편)

Load Balancer가 특정 사용자를 항상 동일 서버로 보낸다.

장점:

• 설정 간단
• 코드 수정 거의 없음

단점:

• 서버 장애 시 세션 소멸
• Auto Scaling 의미 감소
• 근본 해결 아님

② Spring Session + RDB

세션을 데이터베이스에 저장한다.

장점:

• 구현 쉬움
• 공공/SI 환경에 적합
• 기존 MVC 구조 유지 가능

단점:

• 요청마다 세션 갱신으로 DB write 증가
• 고트래픽 환경에서는 병목 가능성

③ Spring Session + Redis

세션을 인메모리 캐시에 저장한다.

장점:

• 성능 우수
• 확장성 높음
• 실무에서 가장 일반적인 방식

단점:

• Redis 장애 시 로그인 전체 영향
• 별도 인프라 운영 필요

④ JWT 기반 Stateless 설계

애플리케이션이 세션을 저장하지 않는다.

장점:

• 서버 수와 무관
• Auto Scaling 최적화
• 멀티 리전에도 유리

단점:

• 로그아웃/토큰 만료 설계 필요
• 보안 설계 중요

3. SSO 연동 시스템에서의 주의점

많은 시스템이 SSO를 사용한다고 해서
자동으로 이중화가 된다고 생각한다.

하지만 SSO는 인증 과정을 처리할 뿐이다.

SSO 로그인 이후 애플리케이션이 JSESSIONID를 발급하고
서버 메모리에 세션을 저장한다면,
이중화 시 동일한 세션 문제가 발생한다.

따라서 반드시 확인해야 한다.

• 로그인 유지가 서버 세션인가?
• LB 뒤에 세션 외부화가 되어 있는가?
• 세션 암호화 키가 서버 간 동일한가?

4. 결론

클라우드는 서버를 쉽게 늘릴 수 있다.
그러나 세션을 자동으로 해결해주지는 않는다.

이중화의 핵심은
“서버 메모리에 상태를 두지 않는 것”이다.

Sticky는 편의,
RDB/Redis는 외부화,
JWT는 무상태.

시스템 특성에 맞는 선택이 필요하다.

한 줄 요약

서버를 두 배로 늘리는 것보다 중요한 것은
세션을 어디에 둘 것인지 결정하는 것이다.

많은 사람들이 이렇게 말한다.

“클라우드는 VPC 만들고 LB 붙이고 Auto Scaling 하면 끝 아닌가요?”

기술적으로는 맞다.
하지만 ‘서버 이중화’와 ‘서비스 이중화’는 완전히 다른 이야기다.

1. 서버 이중화는 생각보다 쉽다

클라우드에서는 다음 구성이 기본 패턴이다.

기본 구성

• VPC
• 서로 다른 AZ에 EC2 2대 이상
• Application Load Balancer
• Auto Scaling Group
• Health Check 기반 자동 교체

이 단계까지는 인프라 레벨에서 어렵지 않다.
온프레미스처럼 장비 구매, 이중화 장비 구성, 네트워크 장비 세팅을 직접 하지 않아도 된다.

컴퓨트 레벨의 이중화는 클라우드의 기본 기능이다.

2. 진짜 난이도는 ‘상태(State)’에서 시작된다

문제는 여기서부터다.

1) 세션 문제

• 서버가 2대면 세션이 분산된다.
• Sticky Session은 장애 상황에서 깨진다.
• 스케일아웃 시 세션 유실 가능.

해결 방법:

• JWT 기반 무상태 인증
• Redis + Spring Session
• 세션 공유 구조

2) 파일 저장 문제

• 로컬 디스크에 업로드하면 서버 장애 시 파일 손실
• 서버 2대면 파일 불일치 발생

해결 방법:

• Object Storage(S3 등)
• 공유 스토리지(EFS 등)

3) DB가 진짜 본체다

웹/was 이중화는 쉽다.
DB 이중화가 비용과 난이도를 폭증시킨다.

옵션:

• Managed DB Multi-AZ
• Read Replica
• 직접 HA 구성 (Patroni 등)

여기서부터는 RPO/RTO 정의가 필요하다.
즉, “얼마까지 데이터 손실을 허용할 것인가?”라는 경영적 판단이 개입된다.

3. 배포 전략이 달라진다

서버가 1대일 때는 단순 재시작 배포가 가능하다.
2대 이상이면 이야기가 달라진다.

필수 고민 사항:

• Rolling Deployment
• Blue-Green Deployment
• DB 마이그레이션 호환성
• Feature Toggle 전략

이 시점부터 DevOps 역량이 요구된다.

4. 관측(Observability)이 없으면 오히려 위험하다

서버가 늘어나면 장애 분석 난이도가 올라간다.

최소 필요 요소:

• 중앙 로그 수집
• 메트릭 수집
• 에러율 알람
• 5xx 모니터링
• DB 커넥션 모니터링

이걸 안 깔고 서버만 늘리면
장애는 줄지 않고 복잡도만 증가한다.

5. 비용은 단순히 2배가 아니다

많은 팀이 간과하는 부분이다.

서버 2대 = 비용 2배
가 아니다.

추가되는 비용 요소:

• Load Balancer
• NAT Gateway
• Multi-AZ DB
• 로그 저장 비용
• 모니터링 비용
• 트래픽 비용

실제 체감은 3~10배까지 튈 수 있다.

6. 정리: 서버 이중화 vs 서비스 이중화

결론은 명확하다.

클라우드는 서버 이중화를 쉽게 만든다.
하지만 서비스 이중화를 자동으로 해결해주지는 않는다.

7. 현실적인 최소 기준선

실무에서 “이중화했다”고 말하려면 최소한 다음은 충족해야 한다.

• 2 AZ 이상 분산
• LB + Health Check
• 세션 무상태화(JWT) 또는 Redis
• 파일은 Object Storage
• Managed DB Multi-AZ
• 로그/모니터링 체계

이 정도가 기본선이다.

마무리

클라우드는 인프라를 단순화한다.
그러나 설계를 단순화하지는 않는다.

이중화는 장비의 문제가 아니라
상태 관리와 운영 전략의 문제다.

서버를 두 배로 늘리는 것보다 중요한 건
“장애가 났을 때 서비스가 어떻게 동작해야 하는지”를 정의하는 것이다.

보안 설계를 하다 보면 결국 기본 개념을 얼마나 정확히 이해하고 있는가로 귀결됩니다.
공격 유형, 인증 요소, 암호 알고리즘은 모든 보안 논의의 출발점입니다.
아래는 실무와 시험 모두에서 자주 등장하는 핵심 개념 정리입니다.

1. 공격 유형: 소극적 공격 vs 적극적 공격

보안 공격은 시스템에 변화를 주는지 여부에 따라 구분됩니다.

• 소극적 공격 (Passive Attack)
  • 목적: 정보 수집
  • 특징: 시스템 자원이나 데이터에 직접적인 변경 없음
  • 예시: 도청(Eavesdropping)
    → 네트워크 트래픽을 몰래 감청하여 정보를 획득
• 적극적 공격 (Active Attack)
  • 목적: 시스템 교란 또는 정보 조작
  • 특징: 데이터나 시스템 상태를 의도적으로 변경
  • 예시: 위·변조(Tampering)
    → 전송 중인 데이터 내용을 수정하거나 삽입

👉 핵심 차이:
“읽기만 하느냐(소극)” vs “건드리느냐(적극)”

2. 인증 요소의 3가지 분류

인증(Authentication)은 사용자가 누구인지 증명하는 과정이며, 다음 세 가지 요소로 나뉩니다.

• 지식 기반 인증 (Something You Know)
  • 사용자가 알고 있는 정보
  • 예시: 비밀번호(Password)
• 소유 기반 인증 (Something You Have)
  • 사용자가 소유한 물리적/논리적 수단
  • 예시: OTP 토큰
• 행동 기반 인증 (Something You Do / Are)
  • 사용자의 행동 특성 또는 생체 특징
  • 예시: 서명(Signature)

👉 실무에서는 보안을 강화하기 위해
**2가지 이상을 조합한 다중 인증(MFA)**을 사용합니다.

3. KISA에서 개발한 대칭키 블록 암호 알고리즘

국내 표준 암호 알고리즘 중 하나로,
한국인터넷진흥원(KISA)에서 개발한 대칭키 블록 암호는 다음과 같습니다.

• SEED
  • 블록 크기: 128비트
  • 키 길이: 128비트
  • 특징: 국내 공공기관 및 금융권에서 널리 사용

SEED는 AES 이전에 국내 표준으로 채택되었으며,
현재도 레거시 시스템과 공공 프로젝트에서 자주 등장합니다.

마무리

보안은 고급 기술보다 기본 개념의 정확성이 먼저입니다.

• 공격은 소극/적극으로 구분하고
• 인증은 지식·소유·행동으로 나누며
• 국내 블록 암호 알고리즘으로는 SEED를 기억하면 됩니다.

이 세 가지만 정확히 알고 있어도
보안 설계, 면접, 시험에서 최소한의 신뢰선은 확보됩니다.

1️⃣ 사고는 “미설정”이 아니라 “방치”에서 난다

실제 사고 패턴은 거의 이렇습니다.

• 초기에는 설정돼 있었음
• 담당자 변경
• 프로젝트 종료
• 예외 처리 추가
• 긴급 대응 후 원복 안 됨

👉 보안은 꺼진 게 아니라 ‘잊힌 상태’에서 터집니다.

2️⃣ 보안 설정의 수명은 사람보다 짧다

• 계정 만료 ❌
• 방화벽 규칙 누적
• 임시 포트 상시화
• 테스트용 계정 운영 반영
• 로그 적재 중단

이 중 의도적으로 취약하게 만든 건 거의 없음
대부분은 “나중에 정리하자”입니다.

3️⃣ 그래서 보안은 설정 문제가 아니라 운영 문제

보안이 무너지는 순간은 이때입니다.

• 누가 책임자인지 모를 때
• 왜 이 설정이 있는지 모를 때
• 언제 제거해야 하는지 모를 때

즉,

보안 설정은 기술이 아니라
책임과 시간의 문제다

4️⃣ 살아있는 보안의 최소 조건

✔ 보안은 상태가 아니라 프로세스여야 한다

• 정기 점검 주기
• 변경 이력
• 예외 만료일

✔ “왜 열려 있는지” 설명 가능해야 한다

• 설명 못 하면 취약점

✔ 자동화보다 중요한 건 가시성

• 다 열려 있으면 아무도 안 본다
• “이상”이 보이게 만드는 게 핵심

5️⃣ 현업용 한 줄 번역

• “보안 다 돼 있습니다” ❌
• “이 설정을 누가, 언제, 왜 유지하고 있는지 설명 가능합니다” ⭕

한 줄 결론

보안은 켜는 기술이 아니라
잊지 않게 만드는 구조다.

“쿼리가 느린 게 아니라 모델이 거짓말을 하고 있다.”

1. 느린 쿼리는 결과, 원인은 모델 불일치

쿼리가 느릴 때 현장에서 제일 먼저 나오는 대응은 이겁니다.

• 인덱스 추가
• 힌트
• 서브쿼리 제거
• 조인 줄이기

근데 이걸로 안 끝나는 케이스는 거의 다 이겁니다.

모델이 현실을 제대로 표현하지 못하고 있다

그래서 DB가 “말을 돌려서” 답을 내느라 느려지는 겁니다.

2. 모델이 거짓말할 때 나타나는 전형적인 징후

아래 중 두 개 이상이면 99% 모델 문제입니다.

1️⃣ 의미가 모호한 컬럼

• status, type, flag, etc1
• 값이 1,2,3인데 의미는 문서에만 있음

→ 쿼리가 조건 분기 지옥으로 감

2️⃣ 시간 개념이 섞여 있음

• 생성일 / 수정일 / 적용일 / 종료일이 한 테이블에 뒤섞임
• “현재 유효한 것”을 구하기 위해 조건이 5개 이상

→ DB는 현재가 뭔지 계산해야 하는 상태

3️⃣ N:M을 숨긴 1:N

• 사실 이력 테이블인데 최신 row만 쓰는 구조
• group by + max + join

→ “최신”이라는 개념을 쿼리로 발명 중

4️⃣ 집계 책임이 DB에 떠넘겨짐

• 실시간 통계
• 조건별 합계
• 상태별 카운트

→ DB가 비즈니스 판단까지 대신함

3. 그래서 쿼리가 ‘느려 보이는’ 이유

DB는 거짓말을 그대로 믿고 실행합니다.

• “이 row는 하나야” → 실제로는 수백 개
• “상태 하나면 끝나” → 사실상 상태 머신
• “이 값은 불변” → 이력 덕지덕지

결과적으로 옵티마이저는

• 잘못된 카디널리티
• 틀린 실행 계획
• 불필요한 풀스캔

을 선택하게 됩니다.

쿼리가 느린 게 아니라, DB가 혼란스러운 상태인 거죠.

4. 해결은 튜닝이 아니라 “진실한 모델링”

이럴 때 정공법은 명확합니다.

✔ 상태를 쪼갠다

• 현재 상태 / 이력 상태 분리
• 의미 단위로 컬럼 분해

✔ 시간을 명시한다

• effective_from, effective_to
• “현재”를 컬럼으로 만들지 말고 테이블로 만든다

✔ 책임을 옮긴다

• 집계는 배치/캐시/전용 테이블
• 조회용 모델 따로 둠 (CQRS 개념)

✔ 쿼리가 아니라 질문을 바꾼다

• “이걸 한 번에 구할 수 있나?”
• “이걸 실시간일 필요가 있나?”

5. 한 줄 요약 (리뷰용)

DB가 느리게 답하는 건,
모델이 현실을 정직하게 설명하지 못하고 있기 때문이다.