장애에 대해 대처하는 방법

들어가며

서비스를 운영하면서 크고 작은 장애들을 경험했다. 처음엔 당황스러웠지만, 이제는 어느 정도 패턴이 보이기 시작했다.

특히 “코드를 어느 계층에서 수정해야 할까?”라는 고민이 가장 어려웠는데, 나름의 판단 기준을 정리해보고자 한다.

주요 장애 유형

지금까지 경험한 장애 유형들이다.

1. 비즈니스 로직 오류 (70%) - VOC, QA를 통해 발견되는 가장 흔한 케이스
2. 트래픽 급증 (15%) - 서버 과부하 및 DB 장애로 연쇄 반응
3. 메모리 부족 (10%) - 힙 메모리 사용량 증가로 인한 OOM
4. 락 관련 오류 (3%) - table에 S락이 걸려, 다른 트랜잭션에 영향을 준 케이스
5. 마이그레이션 실패 (2%) - 배포 과정에서 발생

이 중 가장 빈번하고 판단이 어려운 비즈니스 로직 오류에 대한 대응 프로세스를 정리했다.

장애 대응 프로세스

1단계: 감지 및 초기 대응

해야 할 일

• 슬랙/모니터링 도구로 장애 인지
• 영향 범위 파악 (사용자 수, 기능 범위)
• 팀에 상황 공유
• 스택 트레이스 확인

판단 포인트

• 즉시 롤백이 필요한 수준인가?
• 임시 조치로 우회 가능한가?
• 사용자 영향도는 어느 정도인가?

2단계: 원인 분석 및 해결 방향 결정

스택 트레이스 분석

@Transactional(readOnly = true)
public List<User> getReviewTargetUsers(Review review, User requester) {
    ...
    throw I18nException.of("예외발생");  // 여기서 터짐
}

핵심 질문들

• 이 예외가 정상적으로 발생해야 하는가?
• 추가 검증 로직이 빠진 건가?
• 비즈니스 요구사항이 바뀐 건가?

3단계: 계층별 수정 전략

이 부분이 가장 중요하다. 단순히 예외 발생 지점에서 수정하면 안 되고, 계층별 영향도를 반드시 고려해야 한다.

Case 1: Controller → Service (첫 번째 계층)

API → UserService.getReviewTargetUsers() → 예외 발생

대응 방법

1. 클라이언트에서 API 사용처 확인
   • 앱 어느 화면에서 호출하나?
   • 웹 어느 페이지에서 사용하나?
2. 로직 추가 시 기존 사용처에 미치는 영향 검토(해당 API가 다른 곳에서도 쓰이고 있는 지 클라 확인이 필요)
3. 문제없다고 판단되면 검증 로직 추가

Case 2: Controller → Service → CommonService (두 번째 계층)

API → UserService → CommonUserService.validateUser() → 예외 발생

이때가 진짜 복잡하다!

대응 방법

1. CommonService를 사용하는 모든 첫 번째 계층 서비스 확인

    CommonUserService.validateUser() 사용처
    - UserService.getReviewTargetUsers()
    - UserService.updateUserProfile()  
    - AdminService.banUser()
   

2. 해당 서비스들을 사용하는 모든 API 확인

    UserService.updateUserProfile() 사용 API
    - PUT /api/users/profile
    - PATCH /api/users/settings
   

3. 새 로직이 기존 API들에 미치는 영향 분석

판단 기준

• 첫 번째 계층에서 해결 가능한가? → 그쪽에서 처리
• 공통 로직 수정이 불가피한가? → 영향도 분석 후 신중히 수정
• 복잡도가 너무 높은가? → 새로운 메서드 생성 또는 API 분리 검토

4단계: 해결 실행

핫픽스 프로세스로 갈지, 정규 릴리즈 때 같이 태울 지 상의해서 결정한다. (장애 심각도에 따라 다름)

1. 코드 수정
2. 테스트 코드 보강 (재발 방지)
3. 코드 리뷰 (간소화하되 필수)
4. QA 확인 (영향 범위 중심)
5. 배포 및 모니터링

5단계: 사후 처리

회고 준비

• 장애 발생 원인과 해결 과정 정리
• 재발 방지 방안 검토
• 프로세스 개선점 도출하고 발표

기억해야 할 핵심

1. 계층별 영향도 분석은 필수

   • 예외 발생 지점에서 바로 수정하지 마라
   • 항상 “이 수정이 다른 곳에 미치는 영향”을 먼저 생각해라 (하위호환성 고려)

2. 안전한 선택을 하라

   • 복잡하면 첫 번째 계층에서 해결

3. 도메인 지식이 핵심

   • 비즈니스 로직의 적절성 판단은 경험이 쌓여야 한다
   • 확실하지 않으면 팀원들과 상의하라

특히 장애 대응에서 가장 중요한 건 당황하지 않기와 체계적으로 접근하기 인 것 같다.