운영 환경에서 처음으로 전제가 깨지기 시작했다
이 문서는 INSK를 운영 환경에 올리면서 실제로 겪은 문제들을 정리한 기록이다.
해결 방법을 정리하기보다는, 왜 이런 문제가 발생했는지,
그리고 이 문제가 어떤 설계 전제 위에서 발생했는지를 남기는 것이 목적이다.
1. 배포는 성공했지만 서비스는 열리지 않았다 (502 Bad Gateway)
- 상황
- CI/CD 파이프라인은 정상 종료
- 브라우저 접근 시 `Nginx 502 Bad Gateway` 응답
- 서버는 살아 있었지만 API는 응답하지 않았다
- 최초 판단
- 애플리케이션 포트 매핑 오류
- Spring Boot 프로세스 비정상 종료 가능성
- 확인 과정
- Nginx access / error 로그 확인
- EC2 내 애플리케이션 프로세스 상태 확인
- Spring Boot 기동 로그 확인
- 실제 원인
- Spring Boot가 기동 단계에서 DB 연결 실패
- RDS 보안 그룹 인바운드에 EC2 보안 그룹이 허용되지 않음
- 해결
- RDS 보안 그룹에 EC2 보안 그룹 ID 추가
- DB 연결 정상화 후 애플리케이션 기동 확인
- 설계상 문제
- 애플리케이션 오류로 단정하고 네트워크 계층을 후순위로 판단
- “코드가 문제일 가능성이 가장 크다”는 개발자 편향이 작동2. 배치 작업이 조용히 멈춰 있었다 (@Scheduled)
- 상황
- 서비스는 정상 동작
- 하지만 특정 날짜 이후 뉴스 데이터가 수집되지 않음
- 모니터링이나 알림은 없었음
- 최초 판단
- 외부 뉴스 API 응답 지연
- 데이터 수집 대상 부족
- 확인 과정
- 배치 로그 직접 확인
- 특정 스케줄 작업 이후 로그가 더 이상 남지 않음
- 실제 원인
- 배치 로직 중 예외 발생
- 예외가 스케줄 스레드를 종료시켰고 이후 재실행되지 않음
- 해결
- 예외 처리 보완
- 실패 로그 추가
- 설계상 문제
- 배치 작업이 항상 정상 동작한다는 전제
- 실패를 정상 시나리오로 다루지 않음
- 재시도, 상태 관리, 알림이 없는 구조3. 캐시 적용 이후 데이터 정합성 문제 (Redis)
- 상황
- 기사 점수 수정 이후에도 화면에는 이전 점수가 노출됨
- 새로고침을 반복해야 값이 갱신됨
- 최초 판단
- 프론트엔드 캐시 문제
- API 응답 캐싱 문제
- 확인 과정
- Redis 키 확인
- 캐시 TTL 확인
- API 호출 시 캐시 히트 여부 확인
- 실제 원인
- 캐시 무효화 기준이 API 요청 단위로만 설계됨
- 배치 작업에서 변경된 데이터에 대한 캐시 무효화가 누락됨
- 해결
- TTL 단축
- 일부 키 수동 삭제
- 설계상 문제
- TTL을 해결책으로 착각
- 캐시를 성능 도구로만 인식하고 일관성 리스크를 고려하지 않음4. LLM 호출 실패로 전체 파이프라인 중단
- 상황
- 일부 뉴스가 저장되지 않음
- 특정 날짜 데이터가 통째로 누락
- 최초 판단
- 뉴스 API 수집 문제
- 데이터 파싱 오류
- 확인 과정
- LLM 호출 로그 확인
- OpenAI API 실패 응답 확인
- 실제 원인
- 요약 / 분류 / 점수 계산을 하나의 흐름으로 처리
- LLM 호출 실패 시 이후 로직 전체 중단
- 해결
- 실패 로그 추가
- 부분 결과 저장
- 설계상 문제
- 외부 API를 내부 트랜잭션처럼 다룸
- 실패를 예외 케이스로만 취급
- 외부 의존성은 항상 실패할 수 있다는 전제 부재5. CI/CD 배포 이후 코드가 갱신되지 않은 문제
- 상황
- GitHub Actions 성공
- 하지만 실제 서비스는 이전 코드 상태
- 최초 판단
- 배포 지연
- 서버 캐시 문제
- 확인 과정
- Docker 이미지 태그 확인
- 배포 시점과 이미지 빌드 시점 비교
- 실제 원인
- Docker 이미지에 latest 태그 사용
- 이미지 Push / Pull 타이밍 간 레이스 컨디션 발생
- 해결
- Git Commit Hash 기반 이미지 태그 사용
- 배포 대상 이미지 명시
- 설계상 문제
- CI/CD에서 불변성(Immutability) 개념 미적용
- 배포 결과를 “신뢰”하고 검증하지 않음6. 개발 관점 트러블슈팅에서 느낀 한계
이 문제들의 공통점은 분명했다.
-
대부분의 문제는 코드 품질 문제가 아니었다
-
설계 시 암묵적으로 깔아둔 전제가 깨진 결과였다
-
실패를 고려하지 않은 구조는, 운영 환경에서 반드시 흔들렸다
이 시점에서 INSK는
“기능이 완성된 서비스”가 아니라
운영을 통해 설계 한계를 드러낸 상태에 가까웠다.
이 트러블슈팅편의 의미
이 문서는 문제 해결 자랑을 위한 기록이 아니다.
오히려 반대로, 내가 어떤 판단을 너무 쉽게 했는지를 드러내는 문서다.
그리고 이 기록들이 쌓이면서
다음 질문으로 자연스럽게 이어졌다.
“이 문제들을 계속 땜질로 해결하는 게 맞는가,
아니면 구조 자체를 다시 봐야 하는가?”
이 질문에 대한 답이
다음 INSK 개발편 3의 출발점이 된다.
