[AWS] AWS 환경에서 모델 학습 API 호출 시 Broken pipe 에러 해결 과정

최근 Spring Boot 기반 API 서버에서 모델 학습 요청을 처리하는 도중, IOException: Broken pipe 예외가 발생하는 상황을 경험했습니다. 문제는 AWS 환경에서 발생했고, 처음에는 에러 메시지만 보고 정확한 원인을 파악하기가 쉽지 않았습니다. 이 글에서는 해당 문제를 어떻게 진단하고 해결했는지 과정을 정리합니다.

문제 상황

모델 학습을 위한 POST API(/api/models/train)를 호출하면 내부에서 학습이 시작되고, 이후 클라이언트에 성공 여부를 응답하도록 구현되어 있었습니다. 그런데 간헐적으로 아래와 같은 에러가 로그에 남는 문제가 있었습니다.

IOException: Broken pipe

Spring Web MVC에서 발생한 에러로, 응답을 전송하는 도중 예외가 발생하며 전체 스택 트레이스가 출력되었고, 클라이언트에서는 정상적인 응답을 받지 못하는 경우도 있었습니다.

원인 분석

처음에는 서버 측의 코드 문제라고 생각했지만, 스택트레이스를 살펴보면서 아래와 같은 단서를 얻었습니다:

• SocketChannelImpl.write(...) → 응답을 쓰는 과정에서 오류
• 클라이언트가 먼저 연결을 종료한 상태에서 서버가 응답을 보내는 중

이것은 흔히 말하는 "Broken pipe", 즉 연결된 파이프의 한 쪽이 이미 닫힌 상태에서 데이터를 쓰려 할 때 발생하는 에러였습니다. 그럼 왜 클라이언트가 먼저 연결을 끊었을까요?

AWS 환경에서 자주 발생하는 원인

제가 구축한 인프라는 AWS 환경에서 ALB(Application Load Balancer)를 사용하고 있었고, API 요청은 Spring Boot 서버 → ALB → 외부 클라이언트 순으로 흐르고 있었습니다. 이때 다음과 같은 가능성이 고려되었습니다.

• ALB의 기본 idle timeout이 60초로 설정되어 있었음
• 모델 학습은 시간이 오래 걸리는 작업이기 때문에, 이 시간을 초과하여 ALB가 연결을 끊었을 가능성 있음
• 클라이언트도 일정 시간 이상 대기하지 못하고 연결을 종료했을 수 있음

결국 서버는 데이터를 클라이언트에 쓰려 했지만, 이미 연결이 종료된 상태여서 Broken pipe 예외가 발생한 것이었습니다.

해결 방법

1. ALB Idle Timeout 설정 조정

ALB의 idle timeout 값을 기본값(60초)에서 300초로 변경했습니다. 이는 대기 시간이 긴 학습 작업에도 연결이 끊기지 않도록 하기 위함입니다.

• AWS Console → Load Balancers → ALB 선택 → Description → Idle timeout 수정

2. 클라이언트 측 타임아웃 설정도 증가

Postman이나 프론트엔드 앱 등에서도 요청 timeout 값을 5분 이상으로 설정했습니다. 클라이언트가 너무 빨리 요청을 포기하지 않도록 하기 위함입니다.

3. 비동기 작업 처리 구조로 개선 검토

모델 학습처럼 오래 걸리는 작업을 동기 방식으로 처리하는 것은 구조적으로도 불안정하다고 느꼈습니다. 추후 다음과 같은 비동기 처리 구조로 리팩토링할 예정입니다.

1. /api/models/train 호출 → 작업 등록
2. 작업 ID(jobId) 응답
3. 클라이언트는 /api/models/status/{jobId}로 상태를 주기적으로 확인
4. 학습 완료되면 결과 제공

4. 로그 개선 및 응답 스트림 검토

서버에서 학습 작업의 시작 시점, 종료 시점, 중간 상태를 로그로 잘 남겨두어 문제가 어디서 발생하는지 더 명확히 알 수 있도록 개선했습니다. 또한 응답이 클 경우에는 chunked transfer나 파일 제공 방식으로 개선할 수 있도록 검토 중입니다.

정리

원인	대응 방법
ALB idle timeout 초과	ALB 설정에서 300초 이상으로 조정
클라이언트 timeout 초과	Postman/앱에서 timeout 시간 증가
장시간 처리 API	비동기 Job Queue 구조 도입 고려
응답 중 연결 종료	로그 개선, 스트리밍 방식 재검토

마무리하며

이 에러를 경험하면서 AWS 환경의 네트워크 구조나 프록시 설정이 애플리케이션 동작에 큰 영향을 미칠 수 있다는 점을 체감했습니다. 특히 장시간 처리되는 API는 동기 방식보다는 비동기 큐를 활용한 설계가 더 안정적이라는 교훈을 얻었습니다.

혹시 비슷한 에러를 겪고 계시다면 위의 내용을 참고하시어 점검해보시길 권해드립니다.