채용 에이전트가 '오늘 행동하라'고 26번 말한 후 두 개의 일자리를 전달하다

원래 aideazz.xyz에 게시되었으며, 여기에는 정식 링크와 함께 교차 게시되었습니다.

AIdeazz AI Lab의 필드 노트 — 라이브 프로덕션 시스템에서 발생한 실제 사건을 로그를 바탕으로 작성함. 2026년 10월 6일.

한 채용 발견 에이전트가 일주일 동안 매 12시간마다 운영자 앞에 강력하게 일치하는(strong matches) 항목들을 기록했다. 그녀의 액션 큐(action queue)는 사흘 동안 새로운 것이 없었다. 성공 라인은 CRM이 응답하기 전에 인쇄되었고, 최고의 지역 소스는 '일자리 없음 (0 jobs found)'이라는 메시지와 녹색 체크 표시를 보고하면서 모든 요청을 거부했으며, 승인된 일자리는 그녀가 이미 마감한 거래에 의해 폐기되거나 통합되고 있었다.

외부에서 보기에 어떤 모습이었나

운영자는 에이전트가 며칠 동안 지원할 새로운 직무를 단 하나도 전달하지 않았다는 것을 알아차렸다. 모든 구성 요소는 건강해 보였다. 프로세스들은 깨끗하게 실행되고 재시작되었으며, 검색 도어(search door)는 하루에 두 번 실행되어 '완료 — 새 일자리: 30'이라고 기록했고, 그 로그에는 'IRON-CLAD FIT + judge OK -> 오늘 행동하라 (I Act TODAY)'라는 문구가 지속적으로 흘러나왔다. 시간당 엔진은 각 소스마다 녹색 체크 표시를 보고했다. 하지만 CRM은 다른 이야기를 전하고 있었다. 그녀의 액션 큐에 들어온 마지막 새 일자리는 사흘 전에 도착한 것이었다.

실제로는 무슨 일이 일어나고 있었는가

실제로는 무슨 일이 일어나고 있었는가

성공 메시지에 가려진 네 가지 결함이 있었다. 첫째, 검색 창은 CRM에 일자리를 전달하기 전에 '오늘 행동하라(I Act TODAY)'라는 문구를 출력하고 답을 읽지 않았다. 9월 29일부터 이 문구가 10개의 개별 일자리마다 총 26번 출력되었고, 그중 정확히 2개만이 새로운 거래로 이어졌다. 이 승인 중 12개는 회사 이름이 비어 있었는데, 이는 코드가 경로(path)가 아닌 Lever 링크의 서브도메인(

모든 성공 라인은 이제 그것에 따라 행동해야 하는 시스템을 기다립니다. 검색 도구는 CRM의 답변을 읽고 새로운 거래가 있을 때만 '오늘 행동함(I Act TODAY)'이라고 기록하며, 중복은 '이미 CRM에 있음 (단계 …) — 새 것이 아님'으로, 거절은 'CRM에서 거부됨 (HTTP 코드: 메시지)'로, 그리고 거래 ID가 없는 2xx는 알 수 없음으로 기록합니다. 이제 CRM 측에서는 해당 직무가 중복이었는지 여부와 운영자가 이미 결정했었는지 여부를 답변하며, 재방문한 직무에 대해서는 아무런 변경 없이 그대로 둡니다: 메모도 없고, 대기열 항목도 없고, 유료 커버레터 요청도 없습니다. 동일 거래에 대한 회신이나 인터뷰 초대는 여전히 도착합니다. 회사명은 링크 경로에서 읽어오며, 보수적인 제목 대체값은 890개의 실제 빈 회사 제목과 비교됩니다. 조회 목록(seen-list)은 가장 오래된 항목을 삭제합니다. 비어 있는 검색 본문은 한 번 재시도됩니다. 거부하는 구인 게시판은 우회되지 않았습니다: 이제 자체 고객에게만 서비스를 제공하며, 약관상 스크래핑이 금지되어 있어 실패는 실패로 기록되고 그에 대한 결정은 운영자에게 넘어갔습니다. 대신 명시된 급여와 자격 요건을 갖춘 지역 배치 에이전트가 소스로 추가되었습니다. 동일한 변경 사항은 에이전트의 타겟팅을 운영자가 공개한 전문 프로필의 직무 목록과 일치시켜, 에이전트가 이전에 검색한 적 없는 11개의 제목을 추가했습니다.

작동했다는 것을 아는 방법

로그가 아닌 CRM으로 확인합니다. 변경 전에는 '오늘 행동함(I Act TODAY)' 라인 26개가 2개의 새로운 거래를 만들었고, 마지막 새 거래는 3일 전에 발생했습니다. 배포 후 처음 5분 동안, 8개의 새로운 직무가 그녀의 액션 대기열에 들어왔습니다. 마감했던 직무를 재실행하자 '중복, 결정됨, 손실로 마감'이라는 답변이 돌아왔고, CRM 로그는 '이미 존재함 — 행동 메모 새로 고침'에서 '이미 결정됨 — 그대로 둠'으로 변경되었습니다. 거부하는 소스는 이제 녹색 체크 표시 대신 '❌ 직무 0개 — 요청 3/3 실패 (HTTP 400)'을 기록합니다. 전체 평가 스위트(full evaluation suite)는 프로덕션 서버에서 통과했습니다(862개의 테스트). AI 심사관의 변경 전/후 재실행은 적절한 직무를 3개 중 3개 승인하고 부적절한 구직을 3개 중 3개 거부했습니다.

얻게 된 규칙

얻게 된 규칙

결과를 볼 수 있는 사람이 요청한 사람을 통해서가 아니라 직접 출력해야 합니다. 만약 어떤 컴포넌트가 다운스트림 시스템의 응답을 받기 전에 '완료'라고 기록한다면, 그 로그는 성과(outcome)가 아닌 노력(effort)을 측정합니다. 결과가 도달하는 곳에서 카운트하세요: 여기서는 매일 CRM에 들어오는 새로운 거래 건수와 '승인된' 라인 수입니다. 이 두 숫자가 다를 때, 그 차이가 버그입니다. 0을 반환하는 소스는 아무것도 찾지 못했는지 아니면 요청하는 데 실패했는지를 말해야 합니다. '✅ 0'과 '❌ 0'은 다른 사실이며, 이를 구분할 수 없는 대시보드는 장애가 발생해도 계속 녹색 상태를 유지합니다.

그 뒤에 숨겨진 명명된 개념들

실패 모드(failure mode)에 이름을 붙이는 것이 그것이 또 다른 곳에서 같은 모양으로 인식되게 만들고, 추가적인 주말을 낭비하기 전에 미리 대비할 수 있게 합니다.

인정은 완성이 아니다

영수증은 전달만 증명합니다. 처리까지는 절대 증명하지 못합니다.

작업을 비동기적(asynchronous) 시스템—큐(queue), 웹훅(webhook), 워크플로우 도구, 백그라운드 작업(background job)—에 넘길 때 받는 응답은 _'내가 이것을 받았다'_라는 의미입니다. 그것은 _'내가 이것을 했다'_라는 의미가 아니며, 매우 자주 _'내가 이것을 할 의도가 있다'는 의미조차 아닙니다.

이것이 '데이터가 그냥 사라졌다(the data just vanished)'와 관련된 많은 사고의 함정입니다. 전송 측면은 성공으로 기록하고, 수신 측면은 아무것도 처리하지 않으며, 양쪽 모두 개별적으로 볼 때는 건강해 보입니다. 메시지를 받아들이고 절대 읽지 않는 큐는 작동하는 큐와 똑같이 보입니다.

방어책을 강도 순서로 나열하면 다음과 같습니다:

1. 인정(acknowledgement)에 의존하지 마십시오. 만약 폴백 로직이 _'전달에 실패했다면, 내가 직접 하겠다'_라고 읽는다면, 전달 자체가 성공했다고 보고하기 때문에 절대 실행되지 않을 것입니다. 로컬 경로는 무조건적(unconditional)으로 만들고, 아이덴티티(idempotency)가 중복을 흡수하도록 하십시오.
2. 반대편에서 확인하십시오. 영수증을 신뢰하는 대신, 작업이 실제로 완료되었는지—상태 엔드포인트(status endpoint), 결과 기록(result record), 콜백(callback)—를 확인하세요.
3. 마감 기한을 설정하십시오. 예상되는 결과가 N분 이내에 나타나지 않으면, 영원히 기다리기보다는 실패로 간주하고 조치하십시오.

무음 실패 (Silent failure)

시스템이 합리적인 행동을 했지만 아무에게도 알리지 않았습니다.

가장 비용이 많이 드는 버그 유형 중 하나인데, 모두가 문제가 없다고 가정하는 동안 시계는 계속 돌아가기 때문입니다.

무음 실패(silent failure)는 충돌(crash)이 아닙니다. 충돌은 크고 수정하기 쉽습니다. 무음 실패는 어떤 구성 요소가 아무도 알지 못하게 _방어 가능한 로컬 결정_을 내리는 것입니다. 즉, 이 메시지를 버리거나, 이 레코드를 건너뛰거나, 빈 문자열을 반환하는 식입니다. 외부에서 볼 때, 완벽하게 작동하는 시스템과 완전히 죽은 시스템이 만들어내는 관찰 결과는 동일합니다: 아무 일도 일어나지 않았습니다.

방어책은

• 의존성을 조사하고(Probe the dependency), 그 자격 증명(credential)을 읽지 마십시오. 존재하는 키는 그 뒤에 있는 잔액에 대해 아무것도 증명하지 못합니다.
• 설정 라인(setup line)이 아닌, 동작 라인(action line)에서 검색하십시오(Grep). 시작 배너(startup banner)는 프로세스가 시작했다는 것만 증명할 뿐, 실제로 작업을 수행했는지 여부는 증명하지 못합니다.
• 배포 후 타임스탬프를 비교하십시오. 실행 중인 프로세스가 디스크의 파일보다 오래되었다면, 메모리에서 이전 버전을 계속 실행하고 있는 것입니다.

이것이 얻게 되는 규칙은 이렇습니다: 시스템의 동작을 그 설정(configuration)으로부터 절대 보고하지 마십시오. 동작이 발생했음을 증명하는 라인을 검색하여 인용하십시오.

이 노트는 운영 엔지니어링 교훈에 대한 지속적인 위키 기록 중 하나의 항목입니다. 모든 개념은 그것을 가르친 사고와 연결되어 있습니다 — aideazz.xyz/ai-ops-wiki.html.

이 작성 문서에는 고객 데이터, 자격 증명, 호스트 이름 또는 내부 기록 식별자가 나타나지 않습니다.