경력·사례·글은 한국어 원문으로 제공됩니다.

← 모든 기록

기술 글 / 제품 개발

공고 알림 메일 0건의 원인: 후보 조건과 예약 경로

메일 8통과 수집·분석·예약 기록을 대조했다. 공고는 저장되고 있었지만 메일 후보 조건이 좁았고, 예약은 이전 코드를 호출하고 있었다.

작업 2026.10

약 5분 소요2,209자

#메일은 매일 도착했다

공고 수집 메일은 오는데 후보가 계속 0건이었다. 정말 볼 만한 공고가 없는 것인지, 중간 처리가 멈춘 것인지 숫자 하나로는 알 수 없었다.

10월 22일부터 25일까지 실제 수신 메일 8통을 읽고, 저장된 발송 결과와 수집 기록, 예약 로그, 실행 코드를 대조했다. 조사하는 동안 새 수집이나 모델 호출, 메일 발송은 하지 않았다.

구성은 Hermes Agent의 예약 작업, Bash 실행 스크립트, Python 수집·분석·메일 코드, PostgreSQL이었다. Hermes는 예약 시각에 스크립트를 시작하고, Python 코드가 DB에서 집계한 결과로 메일을 만들었다. 수집·분석 상태와 발송 snapshot을 DB에 남겼기 때문에 수신 메일의 숫자를 저장된 결과와 대조할 수 있었다. Hermes가 공고의 적합성을 직접 판단한 구조는 아니었다.

먼저 수집 전체가 멈춘 것은 아니라는 점을 확인했다. 최근 수집 실행 8회는 성공으로 기록돼 있었고 새 공고도 저장되고 있었다. 다만 이것이 원천 사이트의 모든 공고를 빠짐없이 모았다는 검증은 아니었다.

#후보가 되려면 먼저 통과할 조건

메일은 저장된 공고를 그대로 보내지 않았다. 사람이 검토 대상으로 선택하고, 현재 입력에 맞는 상세 분석이 완료돼야 후보 판단으로 넘어갔다. 자동 분석이 끝났다는 이유만으로 메일 대상이 늘어나지는 않았다.

새 평가 결과에도 자동 발송을 제외하는 조건이 있었다. 예약이 켜져 있어도 처리할 대상이 비어 있으면 실제 모델 호출은 시작되지 않았다. ‘수집됨’, ‘평가 완료’, ‘메일 후보’가 서로 다른 수였다.

이 조건을 모르고 0건을 읽으면 적합한 공고가 없다는 뜻으로 받아들이기 쉽다. 실제로는 평가를 기다리는 공고와 발송 대상에서 제외된 결과가 섞여 있었다. 자동 추천을 제한하려고 둔 조건이 메일에서는 이유 없이 빈 목록으로 보였다.

#배포한 코드와 예약이 부르는 코드

별도로 실행 경로도 어긋나 있었다. 프로젝트 안의 메일 스크립트는 최신 배포본을 가리켰지만 실제 예약이 호출하는 스크립트는 구형 코드를 직접 실행하고 있었다.

실행 파일 이름만 보면 차이를 알기 어려웠다. 양쪽 모두 send_opportunity_digest.sh였지만, 예약 프로필의 Bash 파일은 구형 collector 안의 send_opportunity_digest.py를 직접 불렀다. 프로젝트에 수정해 둔 Bash 파일은 현재 release의 Python 파일로 연결됐다. 프로젝트 파일을 고친 것과 예약이 실제로 그 파일을 호출하는 것은 별개였다.

공개할 수 없는 배포 경로를 빼고 나면 확인 순서는 간단하다. 예약의 명령과 작업 디렉터리, 그 Bash 파일의 최종 Python 호출 대상, 그 코드가 읽는 DB와 평가 계약을 순서대로 따라갔다. 스케줄러의 성공 상태는 이 연결 끝에서 올바른 집계를 읽었다는 증거가 아니었다.

같은 DB와 날짜 조건으로 읽기 전용 비교를 했다. 최신 코드는 분석 완료 2건을 읽었고 구형 코드는 0건으로 집계했다. 실제 수신 메일은 구형 집계와 일치했다.

그렇다고 경로만 고치면 메일에 공고가 나오지는 않았다. 최신 코드에서도 발송 제외 조건 때문에 최종 후보는 0건이었다. 집계가 틀린 문제와 어떤 공고를 보낼지 정한 조건을 함께 고쳐야 했다.

#다음 메일에서 보고 싶은 것

후속으로 제안한 방향은 기존 수집 자료를 재사용해 오늘 확인할 공고를 보여주는 것이었다. 미평가 공고와 평가가 끝난 공고를 나누고, 참가 자격은 아직 확인하지 않았다는 사실을 함께 적는 방식이다.

후보가 없을 때도 이유를 보여줄 필요가 있었다. 공고를 못 가져온 것인지, 평가 대기인지, 자동 평가가 중지됐는지, 분석 오류인지가 달랐다. 수집 건수와 평가 완료 건수도 한 숫자로 합치지 않기로 제안했다.

이 글에 근거로 삼은 마지막 결과는 진단과 개선안이다. 실제 예약 경로를 수정하고 다음 정기 메일에서 정상 집계를 확인한 증거는 아직 없다. 자동 평가 범위나 예산을 새로 정한 것도 아니다.

공고를 읽은 뒤 다음 작업으로 넘기는 과정을 만들 때는 다음 단계로 넘어가는 조건에 집중했다. 이번에는 그 조건 때문에 넘어가지 못한 상태가 사용자에게 어떻게 보이는지 확인했다. 매일 도착하는 메일이라도, 무엇을 세어 보낸 숫자인지 설명하지 않으면 상태를 잘못 전달할 수 있었다.

작성 2026-11-03

2026년 10월 25일 읽기 전용 진단과 이후 개선 권고를 정리한 기록이다. 운영 수정과 변경 후 정기 메일 성공은 확인하지 않았다. 수신자와 공고 식별정보는 생략했다.