업무 관점에서 원인을 까보면 대부분 여기로 수렴합니다.
- 상태(State)를 가진다
- 세션, 트랜잭션, 락, 캐시
- 상태가 있다는 건 → 꼬일 수 있다는 뜻
- 프론트는 새로고침하면 끝이지만, 백엔드는 데이터가 남습니다.
- 외부 의존성이 몰려 있다
- DB, 외부 API, 인증(SSO), 배치, 메시지 큐
- 장애 보고서 열어보면 항상
DB connection pool 고갈, 외부 연계 타임아웃 이런 말이 나옵니다.
- 조용히 죽는다
- 프론트 오류 → 바로 티 남
- 백엔드 오류 →
- 응답 지연
- 간헐적 실패
- 특정 조건에서만 재현
→ 제일 찾기 어렵고 제일 욕먹음
- 비즈니스 룰이 있다
- 장애의 진짜 원인은 기술보다 업무 로직인 경우가 많습니다.
- “이 경우는 예외였음”, “운영에선 이렇게 씀”
→ 이건 백엔드가 다 떠안습니다.
그래서 백엔드 개발자는
- 눈에 안 띄는 사고 예방자
- 장애 없으면 “한 게 없음”
- 장애 나면 “왜 대비 안 했냐”
완전 방패 포지션이죠.
그래서 이 문장은 단순한 멋있는 말이 아니라:
백엔드는 시스템의 책임이 쌓이는 곳이다
라는 선언에 가깝습니다.
LIST
'Spring & Backend' 카테고리의 다른 글
| 스프링은 확장에 강하다. 대신 초기 설계를 대충하면 고통도 같이 확장된다 (0) | 2026.02.02 |
|---|---|
| 스케일은 트래픽이 아니라 상태 관리에서 갈린다 (0) | 2026.02.02 |
| 설정이 적은 코드가 아니라 의도가 분명한 코드가 좋은 스프링 코드다 (0) | 2026.02.02 |
| AOP는 문제 해결이 아니라 문제 은닉 도구가 될 수 있다 (0) | 2026.02.02 |
| 좋은 자바 코드는 JVM을 신뢰하되, 감시한다 (0) | 2026.02.02 |
