웹훅 이벤트를 업무 요청으로 바꾸는 판단표

웹훅을 업무 요청으로 바꾸는 기준은 이벤트가 도착했는지가 아니라, 이 이벤트가 어떤 고객의 어떤 업무를 시작할 충분한 증거를 갖췄는지입니다. 현재 채널톡 수신 코드는 Message인지, 작성자가 user인지, 이메일과 활성 구독이 있는지를 순서대로 확인하고 조건을 만족할 때만 유지보수 요청을 만듭니다.

입력 열: 이벤트 자격을 판정하는 값

원본 이벤트 저장과 업무 생성은 다른 결정입니다. User나 채널 운영 이벤트도 감사 목적의 원본으로는 보관할 수 있지만, 고객 요청으로 분류하지는 않습니다. 채널톡의 webhook event 모델은 공식 문서에서 이벤트와 엔터티를 구분하므로, 구현 전에 실제 payload의 type·entity를 표에 옮겨야 합니다.공식 Webhook 문서의 예시와 저장소 테스트 fixture를 함께 대조하는 방식이 안전합니다.

결과 열: 수락·보류·원본 보관·거부

1. 인증된 요청인가: 아니면 401로 거부하고 업무 처리하지 않는다.

2. type=Message인가: 아니면 원본만 보관하고 ACK한다.

3. personType이 user인가: 운영자 메시지는 원본만 보관한다.

4. 이메일로 사용자를 찾고 활성 구독이 있는가: 아니면 보류·원본 보관으로 끝낸다.

대조 사례: 세 입력이 만드는 세 결과

샘플 입력 A는 type=Message, personType=user, entity.plainText가 있고 refers.user.profile.email이 활성 구독 사용자와 일치합니다. 결정은 업무 반영이며 중간 산출물은 external_event_id와 title을 가진 유지보수 요청입니다. 샘플 입력 B는 type=User입니다. 결정은 원본만 보관이며 업무 행은 0개입니다. 샘플 입력 C는 Message지만 이메일이 없거나 활성 구독이 없습니다. 결정은 보류이며 나중에 사람의 확인이나 별도 매핑이 필요합니다.

예외 행: 식별 실패와 수동 매칭 복구

이메일 경로를 하나만 읽는 설계는 payload 변형에서 실패합니다. 현재 코드는 refers.user.profile.email, refers.user.email, entity.profile.email, entity.email 순서로 후보를 확인합니다. 그래도 식별되지 않으면 임의의 고객에게 요청을 붙이지 말고 원본을 남긴 채 대안인 수동 매칭으로 보냅니다. 잘못 생성된 업무 요청을 지우는 것보다, 보류 큐에서 근거를 추가해 재처리하는 편이 추적에 유리합니다.

규칙 변경 감사: 결정표와 fixture의 동기화

• 각 행에 입력 필드, 판정, 저장 결과, 담당자를 적는다.

• 조건이 바뀌면 코드보다 먼저 결정표와 테스트 fixture를 함께 갱신한다.

• 원본만 보관된 건을 업무 누락으로 단정하지 말고 보류 사유를 구분한다.

완료 조건은 대표적인 Message·User·운영자 메시지·식별 불가 입력을 재현해 결정표의 결과와 실제 원본·업무 행 수가 일치하는지 확인하고, 각 보류 건의 복구 담당과 재처리 방법을 기록하는 것입니다.