메신저로 주문을 받는 사업의 공통 고민은 주문 양식이 지켜지지 않는다는 것입니다. 안내문을 고정해 놔도 거래처는 자기 방식대로 보냅니다. 순서가 바뀌고 수량은 한글로 오고 축약과 오타가 섞입니다. 사람이 읽을 때는 문제가 없지만 이걸 자동 처리하려는 순간 파싱이 시스템의 관문이 됩니다. 24시간 무인으로 주문을 처리하는 시스템에서 주문 파싱을 설계하고 실운영으로 다듬은 이야기입니다.
주문 파싱의 목표: 이해가 아니라 추출
먼저 목표를 좁혀야 합니다. 주문 파싱은 자연어 이해가 아닙니다. 필요한 것은 메시지에서 정해진 슬롯(계정, 서버, 수량, 요청 사항)을 채우는 일입니다. 목표를 슬롯 추출로 좁히면 설계가 달라집니다. 문장 전체를 해석하는 대신, 각 슬롯의 표기 변형을 수집하고 흡수하는 문제가 됩니다.
우리는 위치와 패턴을 함께 쓰는 슬롯 파서로 접근했습니다. 거래처별 메시지 구조(어떤 정보가 어떤 순서로 오는지)를 프로필로 두고 각 슬롯은 패턴 매칭으로 뽑습니다. 구조가 흔들려도 패턴이 잡고 패턴이 애매해도 위치가 후보를 좁힙니다.
진짜 일은 표기 정규화에 있다
파서의 뼈대보다 오래 걸린 것은 표기 변형의 수집과 정규화였습니다. 실제 메시지에서 만난 수량 표기만 해도 다음과 같습니다.
| 표기 유형 | 예시 | 정규화 |
|---|---|---|
| 아라비아 숫자 | 20000 | 20000 |
| 콤마 표기 | 20,000 | 20000 |
| 한글 수사 | 이만개 | 20000 |
| 만 단위 축약 | 2만 | 20000 |
| 금액 표기 | 금액으로 적고 수량을 의도 | 단가 환산 |
특히 마지막 유형이 도메인 지식의 영역입니다. 거래처가 금액을 적으면 시스템이 단가 기준으로 수량을 환산해야 하는데, 이 규칙은 어떤 범용 파서에도 없습니다. 파싱 설계의 절반은 이런 도메인 규칙을 코드로 옮기는 일입니다. 그래서 실제 메시지 샘플의 수집이 파서 개발의 첫 단계여야 합니다.
실패는 조용히 넘기지 않는다
파서 설계에서 가장 중요한 결정은 추출 실패의 처리입니다. 슬롯을 못 채웠을 때 기본값으로 메꾸거나 비슷한 값으로 추정하면, 파싱 실패가 잘못된 처리로 둔갑합니다. 주문 시스템에서 이는 곧 금전 사고입니다.
우리 파서의 원칙은 "확신이 없으면 뽑지 않는다"입니다. 추출에 실패하거나 값이 검증 규칙(수량 범위, 계정 형식)에 어긋나면 그 주문은 자동 처리에서 빠지고 사람 확인 대상으로 표시됩니다. 파싱 성공률을 높이는 것과 별개로, 실패가 실패로 드러나는 구조가 먼저입니다.
거래처 식별도 같은 원칙입니다. 등록된 방과 발신자 목록에 매칭되는 메시지만 주문 후보로 삼고 그 밖의 메시지는 아예 파싱 대상에서 제외합니다. 파서가 만능이 되려 할수록 오탐이 늘어나므로, 입구에서 대상을 좁히는 화이트리스트가 파서의 정확도를 함께 지킵니다.
규칙 파서와 LLM 사이에서
요즘이라면 LLM에 메시지를 넣고 JSON을 받는 선택지도 있습니다. 실제로 다른 프로젝트(카페 댓글 주문 정리)에서는 규칙 파서에 LLM 폴백을 얹는 하이브리드를 썼습니다. 이번 시스템에서 순수 규칙 파서를 유지한 이유는 세 가지입니다.
- 결정론: 같은 메시지는 언제나 같은 결과여야 합니다. 금전 처리에서 판정이 흔들리는 것은 받아들일 수 없습니다.
- 지연과 비용: 24시간 상주 시스템에서 메시지마다 외부 API를 태우면 지연·비용·장애 지점이 함께 늘어납니다.
- 변형의 유한성: 거래처가 한정된 B2B 채널은 표기 변형도 수렴합니다. 수집된 변형을 규칙으로 흡수하는 편이 유지보수가 쉽습니다.
반대로 불특정 다수의 자유 문장(일반 소비자 댓글 등)을 다룬다면 LLM 폴백의 가치가 커집니다. 파서 선택은 기술 취향이 아니라 입력의 성격이 정합니다.
이 파서가 들어간 전체 시스템은 카카오톡 주문 자동화 사례에서 볼 수 있습니다. 파싱 이후의 처리 검증은 OCR 인식 검증 설계, 실패 건의 사람 확인 흐름은 RPA 사람 승인 게이트로 이어집니다.
자주 묻는 질문
주문 양식을 강제하면 파싱이 쉬워지지 않나요?
이론상 그렇지만 현실에서는 지켜지지 않습니다. 거래처는 자기 습관대로 보내고 양식 위반을 반려하면 거래 마찰이 됩니다. 양식은 권장으로 두되 파서가 변형을 흡수하는 방향이 지속 가능합니다. 실제 메시지 샘플을 모아 변형의 목록을 만드는 것이 첫걸음입니다.
파싱 실패율은 어느 정도까지 허용되나요?
실패율 자체보다 실패의 처리 방식이 중요합니다. 실패가 사람 확인 큐로 드러나는 구조라면 실패는 개입 비용의 문제일 뿐이지만 실패가 기본값이나 추정으로 가려지는 구조라면 단 몇 건이라도 사고가 됩니다. "확신 없으면 뽑지 않는다"가 지켜지는지 먼저 확인하세요.
규칙 기반 파서와 LLM 파싱 중 뭘 써야 하나요?
입력의 성격으로 정합니다. 발신자가 한정되고 표기 변형이 수렴하는 채널(B2B 거래처 방)은 규칙 파서가 결정론·지연·비용에서 유리하고 불특정 다수의 자유 문장은 규칙만으로 커버가 어려워 LLM 폴백이 실용적입니다. 금전 처리라면 어느 쪽이든 검증 규칙과 사람 확인 경로는 필수입니다.
새로운 표기 변형이 나타나면 어떻게 대응하나요?
파싱 실패 로그가 곧 백로그입니다. 사람 확인으로 넘어간 건을 주기적으로 훑어 반복되는 변형을 규칙에 추가하면, 파서는 운영할수록 정확해집니다. 이 순환을 위해서라도 실패 건에 원문 메시지를 함께 남겨야 합니다.