에이전트 브리프 파서 빌드로그: unknown 레인을 먼저 판 이유

마케팅 자동화 쪽에서 보조 에이전트가 매일 마크다운 브리프를 하나씩 남겨요. 사람이 읽기엔 좋은데, 이걸 DB에 넣어 다음 단계로 넘기려면 구조가 필요했어요. 그래서 9월 7일에 브리프를 distill하는 파서를 만들었고, 그날 이 파서 관련 커밋만 6건이 쌓였어요. 첫 커밋에서 건드린 파일은 5개였어요.

왜 unknown 레인부터 팠나

처음엔 정규식 몇 줄로 끝날 줄 알았어요. 직접 만들어 보니 브리프 형식이 날마다 조금씩 달랐어요. 제목 줄이 빠지기도 하고, 항목 구분이 바뀌기도 하고요. 매칭 안 되는 줄을 조용히 버리면 파서는 항상 성공한 것처럼 보여요. 이게 제일 무서운 상태예요.

그래서 분류를 2계층으로 나눴어요. 1계층은 JSON 부록이에요. 에이전트가 브리프 끝에 기계용 JSON을 붙여 주면 그걸 우선 읽고, 부록이 깨져 있으면 본문 파싱으로 폴백해요. 2계층은 본문 파싱인데, 여기서도 못 알아본 덩어리는 버리지 않고 unknown 레인에 원문 그대로 격리해요. 나중에 레인만 열어 보면 뭐가 새어 나갔는지 바로 보여요.

JSON 부록 읽기→실패 시 본문 파싱→못 알아본 덩어리는 unknown 레인 격리

인젝션 줄은 파싱 전에 지운다

브리프는 외부 콘텐츠를 요약한 결과라서 "이 지시를 따르라" 같은 문장이 섞여 들어올 수 있어요. 테스트 픽스처에 그런 줄을 넣어 돌려 보면 일반 항목처럼 잡히기도 했어요. 그래서 파싱 전에 prescan 단계를 앞에 두고, 의심 줄은 redact한 뒤 격리 레인으로 보내요. 전체 원문은 따로 보존해서 뭘 지웠는지 나중에 대조할 수 있게 했고요.

적재와 dry-run

DB 적재는 ledger를 남기면서 하고, 잡이 정상 종료하면 deadman 마커를 갱신해요. 돌려 보니 dry-run에서도 마커가 갱신되는 문제가 있었어요. 마커가 갱신되면 감시 쪽은 "잘 돌았다"고 믿거든요. 그래서 dry-run은 마커를 건드리지 않고 ledger에 dry_run 플래그만 남기게 고쳤어요. 같은 본문이 다른 날짜 파일로 두 번 들어오는 경우도 락으로 막았고요.

실제 백필을 적용해 봤더니 42개 파일에서 초안 127건, 계정 64건이 들어갔고 격리된 항목은 0건이었어요. 0건이 좋은 소식인지는 아직 몰라요. 격리가 안 잡힌 건지 격리할 게 없던 건지 며칠 더 봐야 해요.

• ✓unknown 레인 격리
• ✓prescan redact
• ✓dry-run 마커 미갱신
• ✓원문 보존

다음

이제 스케줄러로 매일 10시 50분에 도는데, 격리 레인이 실제로 채워지는지가 다음 확인 포인트예요. 플랜비에서 동호회 회비 기록을 정리할 때도 사람이 쓴 메모를 구조로 바꾸는 일이 생겨서, 이 파서를 기준 삼아 같은 방식으로 풀어 볼 생각이에요.