스케줄러 프로세스 Hang 현상

 

첫 회사, 첫 개발 커리어, 그리고 첫 장애 대응

첫 회사에서 첫 개발 커리어를 시작하면서 예상치 못한 일이 벌어졌습니다.
사실 저는 신입으로 입사한 지 얼마 되지 않았고, 기존 담당자가 급하게 퇴사하면서 제가 그 역할을 맡게 되었습니다. 그래서 솔루션 담당자가 된 것도 사실은 상당히 황당한 상황이었죠... 인수인계도 일주일밖에 없었고, 저는 어쩔 수 없이 그 솔루션을 책임지게 됐습니다..

 

기억이 나네요, 본부장님이 저에게 해주신 말이...
"신입인데 이렇게 혼자 맡게 되어 미안하지만, 솔루션에 큰 문제가 없으면 고객사에서 연락이 오지 않으니 크게 신경 쓸 필요는 없을거다 걱정하지 말라"며 위로를 해주시더라고요.

 

저는 몰랐습니다. 본부장님의 말이 이번 사건의 플래그였단걸요..

 

그렇게 저는 다른 프로젝트에도 투입되었고, 6개월이 지나고 그날이 왔습니다.

---

그날, 고객사로부터 전화가 오다

[03/18] 그 날이었습니다.
고객사에서 갑작스러운 전화가 왔습니다.

 

고객사: "안녕하세요. ooo 대표입니다. 다름이 아니라 저희 솔루션에 문제가 발생했어요. 스케줄러에서 신규 잡을 등록하고 실행을 했는데, 워크플로우에서 잡들 간의 엔드시그널을 받지 못해 다른 잡이 시작되는데 시작이 안되고 있어요. 지금 문제가 심각해서 밤 늦게라도 해결을 위해 오실 수 있으세요?

 

순간 멘붕이었습니다.

저는 그동안 투입된 프로젝트와 버전 관리 업무 ( 3개의 업무를 맡고 있습니다. 신입이 맞는지...) 에 신경 쓰느라 고객사 솔루션에 대해서 상세히 알지 못한 상황이었고, 이게 첫 장애 대응이라니, 머리가 새하얘지기 시작했습니다.

물론 그 전에도 고객사에서 문의가 오면 나름 공부하면서 대응을 했습니다.

어쨋든 본부장님에게 상황을 바로 설명했고, 그나마 위로의 말을 들으면서도 급하게 고객사 사무실로 향했습니다...

---

장애 대응, 그리고 발견한 문제

고객사 사무실에 도착해 문제를 분석해보니 기존 3개 병원에서의 스케줄링에는 문제가 없었고, 신규 병원이 하나가 추가되면서 문제가 발생했다는 것을 알게 되었습니다. 신규 병원에서 폴링 스케줄러가 정상적으로 작동하지 않으면서, 리소스가 쌓이는 현상이 발생했죠.

 

문제의 핵심은 잡을 처리하는 데는 이상이 없었지만, 잡을 넘기는 데 시간이 너무 많이 걸린 것이었습니다.
처음엔 작업 간 엔드시그널을 받는 시간이 길어지고, 점차 다른 작업들까지 영향을 미쳤습니다. 결국 한 작업이 끝나고 다른 작업으로 넘어가는 데 40분 이상 걸리는 상황을 확인했습니다.

이때부터 머리가 복잡해지기 시작했습니다. 

 

삽질의 시작 – "이거 큐 문제 아니야?"

최근 한 개 병원이 추가되면서 이슈가 발생했기 때문에,

"큐에 데이터가 너무 많이 쌓여서 처리 못 한 거 아냐?"라는 합리적(?) 의심이 들었습니다.

 

JMS 설정을 뒤지기 시작

해당 솔루션은 자바 기반.
그래서 자연스럽게 JMS 설정부터 확인해봤습니다.

<memoryLimit>1mb</memoryLimit>

 

...음?

설정 파일에서 발견한 기본 값.
여기서 살짝 의구심이 들기 시작했습니다..

"잠깐만... 이미 기존에도 병원 3곳 데이터를 잘 처리했는데, memoryLimit이 기본 그대로라고?"

그리고 스쳐 지나간 생각.

“혹시... 이거 JMS 큐를 안 쓰고 있는 거 아냐?”

---

 

그래도 혹시 모르니까 

의심은 했지만, 확인 없이 지나갈 순 없어.
설정 파일을 백업해두고, memoryLimit 값을 수정했습니다.

스케줄러 재기동.
Worker 재기동.

기대한 결과는...

당연히 안 됐습니다 ㅎㅎ…

---

글은 이렇게 짧게 쓰지만,
여기까지 오는 데 시간은 정말 오래 걸렸습니다
밤도 깊어지고, 머리도 지끈거려서 결국 다음 날로 넘기기로 했습니다.

 

아침부터 폭격... 고객사의 부르짖음

아침부터... 고객사님의 문자 폭격 ON.

“지금도 되질 않아요 저희도 급합니다..”    “언제까지 이 상태로 놔둘 겁니까?”    “빨리 확인 좀 해주세요!”

 

현재 진행 중인 프로젝트도 바쁜데 솔루션 문제까지 겹쳐서 정말 머리가 터질 뻔했습니다...

 

아침부터 머리를 감싸면서 물어볼 사람은...?
다들 바쁘셔서 어디 물어보기도 민망한 분위기.
하소연조차 못함.

“...나 진짜 신입 맞아? 왜 벌써 혼자 다 하고 있음?”

혼잣말을 하며 현실 자각.
현타 제대로 옴.
하지만 달라질 게 없으니 정신 차리고 업무 마무리 후, 고객사 사무실로 가게 됐습니.

 

삽질 방식 변경 – 관점을 바꾸자

어제 저는 큐 문제에만 집착해서, 정작 중요한 에러 로그를 제대로 보지 못했습니다.

 

이번엔 스케줄러를 돌리면서 로그를 실시간 확인 봤습니다.

 

문제 발견 – 그리고 희망

• DB 최대 세션 수: 150개 (기본값)
• Worker 하나당 세션 약 40개 생성.
• 병원 4개 → 160개 세션 필요.

“아, 이거다. 세션 부족으로 블로킹 된 거구나!”

바로 DB 설정 변경하여 세션 수 500으로 늘렸습니다.

 

스케줄러 재기동.
Worker 재기동.

---

...그리고 반전결과: 여전히 안 됨. 😇

 

기대가 크면 상심도 역시 크더군요.. 

 

 

 

다시 로그 분석 – 그리고 새로운 단서 발견

큐도 아니고,
DB 세션 수 늘려도 안 되고...
머릿속은 점점 복잡해졌지만 다시 로그를 보기로 했습니다.

---

이상한 반복... 그리고 에러의 정체

Worker 로그를 유심히 보던 중,
30초 간격으로 DB에 SCP명을 전달하는 로직이 반복 실행되고 있었는데...

“어...? 이게 실패하다가 간혹 성공할 때 작업이 수행되네?”

자세히 로그를 들여다보니, 문제의 원인으로 보이는 에러 발견.

 

DB 접속 실패 – Connection failed (timeout)

“DB 접속을 못해서 fail...? 그럼... DB랑 통신 자체를 못하고 있는 건가?”

---

문제의 핵심 – DB 연결 시간 초과

바로 이 지점에서 감이 왔습니다.

병원이 하나 추가되면서 리소스 사용량 증가 → DB 응답 지연
그런데 DB 연결 시간 제한이 30초로 설정돼 있어서,
응답이 늦으면 바로 timeout → 실패 → 재시도 무한 반복
이로 인해 엔드시그널도 못 보내고 작업이 멈추는 현상 발생.

---

해결 방안 탐색 – 구글링과 커뮤니티 분석

구글 검색과 커뮤니티를 통해 JDBC 연결 설정에 대한 자료를 찾아봤다.
그리고 눈에 들어온 설정 값.

 

---

설정 수정 – 그리고 기적

Timeout 값을 30초 -> 60초로 변경.

 

그리고 스케줄러 및 worker 재기동.

---

결과 – 정상 동작 확인!

“어...? 어어어?? 정상 작동한다???”

지금까지의 삽질이 무색하게
모든 작업이 정상적으로 처리되고, 엔드시그널도 문제 없이 전달.

---

결론 – 진짜 원인은 리소스 증가에 따른 응답 지연

아마도 병원 하나가 추가되면서 전체 시스템의 부하가 증가했고,
기존 30초 타임아웃 설정이 그 부하를 감당하지 못한 것.

• 응답 지연으로 연결 실패
• 실패가 누적되면서 전체 작업 지연
• 엔드시그널도 누락 → Hang 현상 발생

타임아웃을 늘려주니 DB 응답을 기다릴 수 있게 되어
모든 프로세스가 정상화된 것.

 

 

🧠 교훈 – 삽질 끝에 얻은 깨달음

1. 문제의 원인은 늘 예상 밖에 있다.
   큐를 의심했지만 큐는 억울했고, 세션을 의심했지만 그것도 아니었음.
   진짜 원인은 30초짜리 설정 하나였다.\
2. 로그는 거짓말을 하지 않는다.
   감으로 추측하지 말고, 로그를 믿어라.
   로그는 개발자의 나침반이다.
3. 설정 값 하나가 시스템을 좌우한다.
   숫자 하나, 단위 하나로 시스템이 날아갈 수도, 살 수도 있다.
   30초 → 60초, 단순해 보여도 그 안엔 생존이 달려있다.
4. 구글링과 커뮤니티는 진짜 스승이다.
   혼자 삽질도 중요하지만, 세상엔 이미 삽질 끝낸 선배들이 많다.
   그들의 흔적을 따라가면 생존 확률이 올라간다.
5. 삽질은 해도, 헛삽질은 하지 말자.
   삽질은 피할 수 없지만, 방향은 제대로 잡자.
   아니면 진짜 ‘땅’만 판다.