죽은 딜이 다시 나타나는 버그: '마지막 수정일'이 곧 마지막 활동을 의미하지 않을 때

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

일일 리드 브리프가 이번 주에 19개의 죽은 딜을 '새로운' 것으로 표시하여, 이용 가능한 25개 슬롯 중 19개를 채웠습니다. 이들은 7월부터 9월까지 명시적으로 폐쇄되고 비활성화된 딜들이었습니다. 진정으로 새롭거나 활성인 리드를 보여주도록 설계된 제 시스템이 노이즈를 보여주고 있었습니다. 즉각적인 질문은 다음과 같았습니다. 어떤 프로세스가 이 딜들을 건드려 '마지막 수정일(last modified)' 타임스탬프를 재설정하여 브리프를 트리거했을까요? 밝혀진 답은 제가 작성한 것이 아무것도 아니라는 것이었습니다.

아침 브리프의 오탐지 (False Positives)

제 일일 리드 브리프는 cto-aipa라는 프로세스에 의해 생성되는데, 이 프로세스는 지난 하루 동안 198번 재시작되어 일부 불안정성을 나타내지만 반드시 데이터 손상 문제는 아닙니다. 이 브리프는 HubSpot의 last-modified 속성에 의존하여 최근 활동을 식별합니다. AI Ops Wiki에 '아침 브리프가 19개의 죽은 딜을 새로운 것으로 호출했는데, 아무도 건드리지 않았다'고 기록된 이 사건은 중요한 불일치를 강조했습니다. 즉, 딜의 last-modified 타임스탬프가 제 에이전트로부터 직접적인 쓰기 작업(write operations) 없이 업데이트되고 있었습니다.

위키에 기록된 사건은 구체적으로 다음과 같이 언급했습니다: '19개 모두 하나의 연락처, 운영자의 자체 받은 편지함에서 비롯되었고, 해당 연락처로 들어오는 모든 이메일이 ea에 숨겨진 롤업(rollup)을 재계산하게 만들었습니다.' 이것이 핵심이었습니다. HubSpot과 같은 많은 CRM은 내부 롤업 필드를 유지합니다. 죽은 딜과 관련된 연락처로 오는 이메일이라 할지라도, 해당 연락처의 last-modified 타임스탬프 업데이트를 유발할 수 있습니다. 이는 다시 연쇄적으로 영향을 미쳐, 딜 자체가 건드려지지 않고 '죽은' 상태에 머물러 있더라도, 관련 딜들의 last-modified 타임스탬프를 업데이트할 수 있습니다.

직접적으로 '죽은 딜 재출현 버그(dead deals resurfacing bug)'를 유발하지는 않지만, HubSpot의 API 호출 제한(rate limits)이 디버깅과 데이터 동기화를 복잡하게 만듭니다. 제 hs-watch-manual-emails.log에는 429 오류가 표시됩니다: "You have reached your ten_secondly_rolling limit." 이는 제가 수동 이메일 활동을 감시하는 시스템, 즉 프로세스가 HubSpot의 TEN_SECONDLY_ROLLING 정책에 도달했음을 나타냅니다. 이 제한은 publicapi:private_app-api-calls-ten-secondly:39045903:51409153과 연결되어 있어, 이러한 last-modified 업데이트의 정확한 트리거 지점을 파악하기 위해 더 세밀한 활동 로그를 공격적으로 폴링(poll)하고 싶어도 제약이 생깁니다.

hs-watch-manual-emails 프로세스는 외부 상호작용(예: 이메일)이 딜 상태에 어떻게 영향을 미치는지 이해하는 데 매우 중요합니다. 이것이 호출 제한을 받으면, 저는 이러한 외부 업데이트의 정확한 타이밍과 성격에 대한 가시성을 잃게 됩니다. 이는 딜의 last-modified 날짜를 업데이트해야 하는 합법적인 활동과 '죽은 딜 재출현 버그'를 유발하는 '숨겨진 집계(hidden rollup)' 업데이트를 구별하기 어렵게 만듭니다.

에이전트 안정성 및 모니터링

제 프로덕션 환경에서는 모든 것이 온라인인 9개의 PM2 프로세스를 실행하고 있습니다. cto-aipa는 지난 하루 동안 198번 재시작을 보여주지만, algom-stream은 55일 동안 무려 55193번의 재시작이라는 놀라운 수치를 보입니다. algom-stream에서 이러한 수준의 불안정성은 '죽은 딜 재출현 버그'와 직접적으로 연관되어 있지는 않더라도, 해결해야 할 더 깊고 근본적인 문제를 시사합니다. 반면, dragontrade-dashboard와 dragontrade-main 프로세스는 각각 55일과 2일 동안 1회 및 4회의 재시작으로 비교적 안정적입니다.

제 모니터링 로그(apply-queue.log (✓ Telegram으로 전송됨 (1개 신규)))와 concierge-selftest.log (✅ PASS — 5개 검사, 첫 번째 카드까지 4093ms 소요)를 통해 핵심 통신 및 자체 테스트 메커니즘이 정상적으로 작동함을 확인했습니다. followup-radar.log는 imap.zoho.com에서 291개의 받은 편지함 이메일과 imap.gmail.com에서 656개의 받은 편지함을 모니터링하고 있으며, 이는 활발한 이메일 처리를 나타냅니다. 이러한 이메일 활동은 직접적으로 진행 중인 딜(deal)과 관련이 없더라도, 수신되는 이메일들이 연관된 연락처와 그에 따른 딜의 숨겨진 last-modified 업데이트를 유발하여 '죽은 딜 재등장 버그(dead deals resurfacing bug)'의 근본 원인일 가능성이 높습니다.

근본 원인 해결: '새로움'의 재정의

핵심 문제는 제가 오직 last-modified 날짜만을 기반으로 '새롭거나' '활성 상태'라고 정의하는 방식이 복잡한 내부 업데이트 메커니즘을 가진 CRM 시스템에서는 결함이 있다는 것입니다. '죽은 딜 재등장 버그'를 수정하려면, 일일 브리프가 어떤 딜이 관련성이 있는지 식별하는 방식을 개선해야 합니다.

단순히 last-modified에 의존하기보다는 다음과 같은 추가 기준을 통합해야 합니다:

1. 딜 단계 필터링 (Deal Stage Filtering): last-modified 날짜와 관계없이

최근 커밋 20d2271 (2026-10-09) ai-ops-wiki: the morning brief called nineteen dead deals new (last-modified-is-not-last-activity)에서 이 문제를 직접적으로 인정했습니다. 다음 단계는 이러한 딜(deal)들을 브리핑에서 필터링하는 로직을 구현하는 것입니다. 이를 위해서는 cto-aipa 에이전트를 수정하여 추가적인 딜 속성을 조회하고, "새로운" 딜로 제시하기 전에 더 강력한 필터링 규칙을 적용해야 합니다.

자주 묻는 질문 (Frequently Asked Questions)

Q: HubSpot의 숨겨진 롤업(hidden rollups)이 "신규 딜(new deal)" 로직에 영향을 미치는 것을 어떻게 방지할 수 있나요?
A: 딜 단계(예: "closed lost" 제외)를 기반으로 명시적인 필터링을 구현하고, 가능하다면 last_modified_date보다 last_activity_date를 우선순위로 지정할 것입니다. 왜냐하면 일반적으로 last_activity_date가 해당 딜 자체와의 직접적인 상호작용을 반영하기 때문입니다.

Q: HubSpot의 TEN_SECONDLY_ROLLING 속도 제한(rate limit)이 이 문제를 디버깅하는 데 어떤 영향을 미치나요?
A: hs-watch-manual-emails.log에 대한 429 속도 제한은 제가 HubSpot에서 세부 활동 로그를 공격적으로 폴링(poll)할 수 있는 능력을 제한하여, last-modified 변경을 유발하는 외부 업데이트의 정확한 시점과 성격을 파악하기 어렵게 만듭니다.

Q: cto-aipa의 높은 재시작 횟수가 "데드 딜이 다시 나타나는 버그(dead deals resurfacing bug)"와 관련이 있나요?
A: cto-aipa가 198번 재시작된 것은 불안정성을 나타내지만, "데드 딜이 다시 나타나는 버그"는 주로 데이터 해석 문제(last-modified를 잘못 해석하는 것)입니다. 비록 cto-aipa가 브리핑을 생성하지만, 그 재시작 자체가 HubSpot에서 부정확한 last-modified 날짜를 직접적으로 유발하지는 않습니다.

Q: 몇 개의 "데드 딜"이 잘못하여 신규로 플래그 지정되었나요?
A: 일일 리드 브리핑에서는 정리 작업 후, 사용 가능한 25개 슬롯 중 19개의 데드 딜을 신규로 표시했습니다. 이들은 7월부터 9월까지의 딜이었습니다.

— Elena Revicheva · AIdeazz · Portfolio