푸른영혼의별

캐시는 성능이 아니라 복잡성이다

캐시는 “빠르게 해준다”가 아니라
상태를 하나 더 만든다는 결정이거든요.

1) 캐시를 넣는 순간 늘어나는 것들

A. 상태가 하나 더 생김

• DB 상태
• 캐시 상태 (부분 복제, 지연 반영)

→ 이제 정답이 두 개입니다.

B. 일관성 문제

• Write-through / Write-behind
• TTL 만료 타이밍
• 부분 무효화 / 전체 무효화

→ “언제 틀려도 괜찮은가?”를 정의해야 함

C. 장애 전파

• 캐시 장애 = DB 폭주
• 캐시 스탬피드
• 핫키 하나로 전체 시스템 흔들림

D. 디버깅 난이도 상승

• “로컬에서는 안 됨”
• “새로고침하면 됨”
• “조금 기다리면 됨”

→ 이 시점부터 재현 불가 버그가 됩니다.

2) 그래서 캐시는 언제 넣는 게 맞나

성능이 아니라 ‘비용’을 줄이기 위해 넣을 때만 의미 있습니다.

캐시가 합리적인 경우

• 동일 결과가 반복적으로 요청됨
• 약간의 지연/오차 허용 가능
• DB/외부 연계 호출 비용이 큼
• 무효화 규칙을 말로 설명할 수 있음

👉 설명 못 하면 넣지 말 것

3) 실무에서 가장 안전한 캐시 원칙

1. 읽기 캐시부터
2. TTL 짧게 시작
3. 무효화 로직 최소화
4. 캐시 미스가 기본 시나리오
5. 캐시 장애 시 DB가 살아야 함

한 줄로:

캐시는 최적화가 아니라 부채다. 필요할 때만 진다.

4) Spring 기준으로 특히 위험한 패턴

• @Cacheable 남발
• 엔터티 통째로 캐싱
• 유스케이스 경계 무시
• 트랜잭션 안에서 캐시 갱신

이거 다 운영 지뢰입니다.

5) 르무엘님 문장, 더 날카롭게 쓰면

캐시는 시스템을 빠르게 만드는 기술이 아니라,
시스템을 이해하기 어렵게 만드는 선택이다.

또는 회고용으로는 이게 더 세죠.

캐시를 넣은 순간, 우리는 성능이 아니라 복잡성을 샀다.

맞습니다. 운영에서 스프링은 기능보다 관측 가능성(Observability) 이 먼저입니다.
로그/메트릭 없으면 장애는 “추측”으로만 대응하고, 그 순간부터 운영은 지옥입니다.

1) 운영 생존 우선순위

1. 로그: “무슨 일이 일어났는지” 사건 기록
2. 메트릭: “지금 상태가 어떤지” 수치 추세
3. 트레이싱: “어디서 느려지는지” 경로(있으면 좋음)

2) 스프링 운영에서 반드시 깔아야 하는 로그(최소 세트)

A. 요청 단위 상관관계 (Correlation)

• requestId / traceId를 모든 로그에 찍기 (MDC)
• API 한 번 호출이 WAS → DB → 외부연계를 타도 한 묶음으로 보이게

B. 구조화 로그

• 문자열 덕지덕지 말고 JSON 로그로 쌓기
• 운영/분석은 grep가 아니라 필터/집계로 합니다.

C. 예외 로그 규격

• errorCode, cause, httpStatus, userId(있으면) 같이 필수 필드 고정
• “NullPointerException”만 남기면 아무 의미 없습니다.

3) 메트릭은 “장애를 미리 알게 해주는 계기판”

스프링 부트라면 실무에서 이거부터 봅니다.

A. RED(요청 중심)

• Rate: TPS
• Errors: 4xx/5xx 비율
• Duration: p95/p99 응답시간

B. USE(자원 중심)

• CPU / 메모리 / GC
• Thread 풀
• DB 커넥션 풀(active/idle/wait)
• 외부 API 타임아웃/리트라이 횟수

운영 장애의 절반은 DB 커넥션 풀 + 타임아웃에서 시작합니다.

4) Spring Boot 기준 “바로 적용 가능한” 구성 방향

• Actuator + Micrometer로 메트릭 노출
• 로그는
  • MDC(traceId/requestId)
  • 요청/응답 요약 로깅(민감정보 마스킹)
  • 에러는 표준 에러 포맷 + errorCode

이 조합이 SI 운영에서 가장 ROI 높습니다.

5) 실무 한 줄 요약 (르무엘님 문장 강화 버전)

운영에서 살아남는 스프링 앱은 기능보다 관측 가능성이 먼저다.
로그가 없으면 원인 분석이 아니라 책임공방이 시작된다.

이 문장은 Spring 실무에서 거의 경고문에 가깝습니다.

빈 라이프사이클을 모르면 버그는 ‘느낌’으로만 잡는다

왜냐하면 Spring에서 버그의 상당수는
로직이 아니라 “언제 생성되고, 언제 연결되고, 언제 호출되느냐” 문제라서요.

1️⃣ 빈 라이프사이클을 모르면 생기는 전형적인 착각

❌ “코드는 맞는데 왜 안 되지?”

• @Autowired 했는데 null
• 값이 초기화 안 된 것처럼 보임
• 어떤 환경에서는 되고, 어떤 환경에서는 안 됨

→ 타이밍 문제입니다.

❌ “어제는 됐는데 오늘은 안 됨”

• 로컬 OK / 운영 FAIL
• 단건 호출 OK / 트래픽 시 FAIL
• 테스트 OK / 배치에서 FAIL

→ 빈 스코프 / 프록시 / 초기화 순서 문제일 확률 높음.

2️⃣ Spring 빈 라이프사이클 핵심 흐름 (실무용)

정석 다 외울 필요 없습니다.
아래만 머리에 들어있으면 80% 잡습니다.

👉 프록시는 “초기화 이후”에 붙는다
이거 모르면 트랜잭션/보안 버그 절대 못 잡습니다.

3️⃣ ‘느낌 디버깅’이 되는 대표 사례들

1. @PostConstruct에서 트랜잭션 안 걸림

• “왜 @Transactional 안 먹지?”
• 이유: 자기 자신 호출 + 프록시 미적용 시점

2. @Autowired 필드가 null

• 생성자에서 사용
• 이유: 주입은 생성자 이후

3. @Async / @Transactional 메서드 안 먹음

• 같은 클래스 내부 호출
• 이유: 프록시는 외부 호출만 가로챔

4. prototype 빈이 싱글톤처럼 동작

• 기대: 매번 새 객체
• 현실: 싱글톤 빈이 한 번만 주입

4️⃣ 빈 라이프사이클을 아는 사람의 디버깅 방식

❌ 느낌 디버깅

• 로그 찍어봄
• 재시작해봄
• 어제 코드랑 비교
• “환경 문제 같은데요…”

✅ 구조 디버깅

• 이 빈은 언제 생성되나?
• 프록시는 언제 붙나?
• 호출 주체는 컨테이너 밖인가 안인가?
• 스코프가 뭐지?

👉 원인 후보가 바로 좁혀짐

5️⃣ 실무에서 최소로 알아야 할 포인트 5개

이건 암기 가치 있습니다.

1. 생성자 주입이 기본
2. @PostConstruct는 프록시 이전
3. AOP는 외부 호출만
4. 빈 스코프는 주입 시점에 결정
5. 컨테이너 밖 객체에는 Spring이 없다

6️⃣ 한 줄 요약 (설계/회고용)

• “Spring 버그의 절반은 생명주기 문제다.”
• “라이프사이클을 알면, 증상이 아니라 원인을 본다.”
• “모르면 코드를 고치고, 알면 구조를 고친다.”

Spring에서 ‘언제’는 ‘무엇’보다 중요하다

스프링은 확장에 강하다. 대신 초기 설계를 대충하면 고통도 같이 확장된다

업무 용어로 풀면 이겁니다.

왜 Spring은 확장에 강한가

• IoC / DI
  → 결합도 낮추기 쉬움
• 레이어드 구조
  → 기능 추가가 물리적으로 가능
• 풍부한 생태계
  → 보안, 트랜잭션, 배치, 메시징 다 있음

즉, “붙이는 것” 은 정말 쉽습니다.

그런데 고통도 같이 커지는 이유

1. 경계 없는 서비스

• Service가 비대해짐
• 유스케이스 단위가 아니라 테이블 단위 서비스
• 변경 영향도 예측 불가

👉 기능 하나 추가 = 전체 리그레션 공포

2. 엔티티 남용

• JPA 엔티티 = DTO = API 모델
• 양방향 연관관계 + 지연로딩 지옥
• 작은 요구사항에 쿼리 폭발

👉 성능 이슈가 설계 부채로 전환됨

3. 설정과 추상화의 과잉

• 인터페이스를 위한 인터페이스
• 전략 패턴 남발
• 실제로 교체 안 함

👉 확장을 대비했지만,
확장보다 유지보수가 더 어려워짐

4. “일단 돌아가게”

• 트랜잭션 범위 대충
• 예외 정책 없음
• 상태 관리 산만

👉 트래픽 늘면 바로 임계점 도달

그래서 Spring 잘 쓰는 팀의 기준

한 줄로 정리됩니다.

확장 포인트만 설계하고, 나머지는 단순하게 둔다

실무 체크리스트로 보면:

• 서비스는 유스케이스 기준
• 엔티티는 도메인 내부 전용
• API 모델 분리
• 트랜잭션 경계 명확
• “나중에 확장”이라는 말 금지

유스케이스는 정책의 흐름이고,
엔터티는 상태의 진실이고,
DB는 현실의 비용이다.
설계는 이 셋의 타협을 문서화하는 일이다.

이 문장도 현업 기준으로 정확합니다.
그리고 앞 문장보다 한 단계 더 깊습니다.

스케일은 트래픽이 아니라 상태 관리에서 갈린다

이걸 실무 언어로 풀면 이겁니다.

왜 트래픽은 문제가 아닌가

트래픽 자체는 요즘 거의 문제 아닙니다.

• 로드밸런서 → 수평 확장
• CDN → 정적 리소스 분산
• 오토스케일링 → 인스턴스 늘리면 끝

요청 수(QPS)는 돈 문제지, 구조 문제는 아닙니다.

진짜 갈리는 지점: 상태(State)

1. 세션

• 서버 세션?
  • 스케일 아웃 순간 깨짐
• Sticky Session?
  • 확장성 포기
• Redis 세션?
  • 이제부터 락·TTL·장애 전파가 시작됨

👉 “로그인 유지” 하나로 아키텍처 레벨 결정됨

2. 트랜잭션

• 단일 DB일 땐 멀쩡
• 샤딩 / 분산 들어가는 순간:
  • 2PC? 성능 박살
  • 보상 트랜잭션? 로직 지옥

👉 비즈니스 일관성 vs 확장성의 전쟁

3. 캐시 일관성

• 캐시 없으면 성능 안 나옴
• 캐시 넣으면:
  • 최신성 보장?
  • 장애 시 fallback?
  • 캐시 스탬피드?

👉 캐시는 성능 장치가 아니라 상태 복제 장치

4. 비동기 처리

• 큐 넣는 순간:
  • exactly-once는 환상
  • 중복 처리 설계 필수
  • idempotency 없으면 재앙

👉 상태를 “나중에 반영”하기 시작한 순간 난이도 급상승

그래서 스케일 잘 되는 시스템의 공통점

업무적으로 정리하면 딱 3줄입니다.

1. 상태를 최대한 없앤다
2. 있다면 한 곳에 모은다
3. 언젠간 틀려도 괜찮게 만든다

기술 스택보다 이 철학이 먼저입니다.

업무 관점에서 원인을 까보면 대부분 여기로 수렴합니다.

1. 상태(State)를 가진다
   • 세션, 트랜잭션, 락, 캐시
   • 상태가 있다는 건 → 꼬일 수 있다는 뜻
   • 프론트는 새로고침하면 끝이지만, 백엔드는 데이터가 남습니다.
2. 외부 의존성이 몰려 있다
   • DB, 외부 API, 인증(SSO), 배치, 메시지 큐
   • 장애 보고서 열어보면 항상
     DB connection pool 고갈, 외부 연계 타임아웃 이런 말이 나옵니다.
3. 조용히 죽는다
   • 프론트 오류 → 바로 티 남
   • 백엔드 오류 →
     • 응답 지연
     • 간헐적 실패
     • 특정 조건에서만 재현
       → 제일 찾기 어렵고 제일 욕먹음
4. 비즈니스 룰이 있다
   • 장애의 진짜 원인은 기술보다 업무 로직인 경우가 많습니다.
   • “이 경우는 예외였음”, “운영에선 이렇게 씀”
     → 이건 백엔드가 다 떠안습니다.

그래서 백엔드 개발자는

• 눈에 안 띄는 사고 예방자
• 장애 없으면 “한 게 없음”
• 장애 나면 “왜 대비 안 했냐”

완전 방패 포지션이죠.

그래서 이 문장은 단순한 멋있는 말이 아니라:

백엔드는 시스템의 책임이 쌓이는 곳이다

라는 선언에 가깝습니다.

❌ “설정이 적은 코드”가 좋은 코드라는 착각

스프링에서 설정이 적다는 건 대부분 이런 상태입니다.

• 애노테이션이 의미를 숨김
• 자동 설정이 어디서 들어오는지 모름
• 조건부 빈(@Conditional)이 암묵적으로 동작
• AOP·프록시·트랜잭션이 보이지 않게 개입

→ 코드량은 줄었지만, 인지 부하는 폭증합니다.

✅ 좋은 스프링 코드의 기준: “의도가 보이느냐”

1. 이 클래스가 왜 존재하는지 한 눈에 보인다

• 잡다한 공통 처리 없음
• “무엇을 하는지”가 클래스명/메서드명으로 드러남

2. 어디서 무엇이 적용되는지 추적 가능하다

• 트랜잭션 경계가 코드에 드러남
• AOP 뒤에 숨기지 않음
• 장애 나면 여기부터 본다가 명확

3. 자동화보다 명시성을 우선한다

• @Autowired 남발 ❌ → 생성자 주입 명시
• 컴포넌트 스캔 범위 최소화
• @Configuration 클래스에서 의존성 구조가 드러남

→ 설정이 늘었지만 시스템 구조는 선명해짐

4. 프레임워크 코드는 가장자리로 밀어낸다

• 컨트롤러 / 인프라 계층만 스프링 의존
• 도메인/서비스는 POJO 유지
• 테스트에서 스프링 띄우지 않아도 돌아감

이게 진짜 유지보수 가능한 스프링입니다.

SI / 공공 프로젝트에서의 현실적인 결론

• 설정 적음 = 초기 개발 속도
• 의도 명확 = 운영·감사·인수인계 생존

공공 SI에서 “마법 같은 코드”는
100% 나중에 설명 요구서로 돌아옵니다.

한 줄 정리 (업무용 문장)

좋은 스프링 코드는 설정이 적은 코드가 아니라,
‘이 코드가 왜 존재하는지’가 드러나는 코드다.