카카오톡으로 오는 발주, 사람 손 없이 정리하기 — 대화 내보내기 파일을 발주 시트로

발주 시스템을 이미 쓰고 있는데도, 거래처의 3분의 1은 여전히 카카오톡으로 주문을 보냅니다. 시스템을 도입해서 풀리는 문제가 아니었습니다. 거래처 입장에서는 카톡이 이미 열려 있고, 시스템은 로그인을 해야 하니까요.

그래서 접근을 바꿨습니다. 거래처에게 시스템을 쓰라고 설득하는 대신, 카톡으로 온 주문을 그대로 받아서 정리하는 쪽을 자동화했습니다. 주문 방식은 그대로 두고, 옮겨 적는 일만 없앴습니다.

먼저 — 이 케이스가 할 수 없는 것

정직하게 시작하겠습니다. 카카오톡으로 들어오는 메시지를 외부 시스템이 실시간으로 받아가는 공식 경로를 저희는 확인하지 못했습니다. 카카오의 비즈니스 메시지 공식 문서는 발송만 다루고, 그마저도 *"카카오와 파트너 계약이 되어있는 공식 딜러사를 통해 진행 가능"*하다고 명시합니다.

• 실시간 자동 수신은 이 케이스의 범위가 아닙니다. 안드로이드 기기에 상주 앱을 띄워 알림을 가로채는 방식이 민간에서 쓰이지만, 재현 가능하고 유지보수 가능한 업무 구조로 권하기 어렵습니다. 기기가 꺼지면 주문이 사라지고, 그 사실을 아무도 모릅니다.
• 그래서 입력을 '대화 내보내기 `.txt`'로 잡았습니다. 담당자가 하루 한 번(또는 마감 전) 대화방을 내보내 업로드하면, 그 뒤로는 전부 자동입니다.
• 이게 타협처럼 보이지만 실제 효과는 큽니다. 없애려는 것은 '카톡을 확인하는 일'이 아니라 '카톡을 보면서 발주 시트에 옮겨 적는 일'이기 때문입니다. 후자가 시간의 대부분을 차지합니다.

내보내기 파일 형식이 하나가 아닙니다

두 번째 함정입니다. 카카오톡 대화 내보내기 .txt는 플랫폼과 앱 버전에 따라 형식이 다릅니다. 파서를 한 가지 형식에만 맞추면 다른 기기에서 내보낸 파일이 통째로 안 읽힙니다.

형식 A (안드로이드 계열)
2026년 8월 15일 오후 2:30, 김사장 : 배추 5박스 부탁드립니다

형식 B (대괄호 계열 — 날짜는 구분선에서 가져옴)
--------------- 2026년 8월 15일 금요일 ---------------
[김사장] [오후 2:30] 양파 3망 주문이요

형식 C (ISO 날짜시각)
2026-08-15 14:30:00, 김사장 : 오이 2박스

• 워크플로우의 Parse Chat Export 노드에 세 형식이 모두 들어 있고, 줄마다 순서대로 시도해 먼저 맞는 것을 씁니다.
• 오전/오후는 24시간제로 변환됩니다. 오후 2:30 → 14:30. 이걸 안 하면 오전 주문과 오후 주문의 순서가 뒤집힙니다.
• 여러 줄에 걸친 주문은 이어 붙입니다. 감자도 다음 줄에 20kg 한 포대 같이요가 오면 한 메시지로 묶입니다. 실제 발주는 이렇게 옵니다.
• 어느 형식에도 안 맞은 줄은 버리지 않고 `unparsed_count`로 셉니다. 이 숫자가 크면 형식이 다른 것이니 패턴을 추가해야 합니다. 조용히 0건 처리되는 것이 최악이라, 숫자로 드러나게 만들었습니다.

시스템 메시지를 먼저 걸러야 합니다

내보내기 파일에는 대화 말고도 홍길동님이 들어왔습니다, 저장한 날짜 : ..., 삭제된 메시지입니다 같은 줄이 섞여 있습니다. 이걸 그냥 두면 바로 앞 주문 메시지에 이어 붙어서 AI에게 넘어갑니다. 주문 내용이 오염되는데 파싱 실패로도 안 잡힙니다.

그래서 파서는 줄을 만나면 시스템 메시지인지부터 검사하고, 맞으면 이어 붙이기 전에 버립니다. 순서가 중요합니다 — 이어 붙인 다음에 걸러내면 이미 늦습니다.

AI에게 무엇을 시키고, 무엇을 시키지 않나

AI는 구조화만 합니다. 판단은 규칙이 합니다. 프롬프트에 명시한 규칙은 다섯 가지입니다.

1. 주문이 아닌 메시지(인사, 잡담, 배송 문의)는 무시한다.
2. 품목과 수량이 모두 분명할 때만 confidence를 high로 한다.
3. 수량이 없거나 품목이 모호하면 low로 하고 이유를 함께 적는다.
4. 절대 수량을 추측하지 않는다. 모르면 quantity를 null로 둔다.
5. 정정 메시지("아까 3박스 말고 5박스로")가 있으면 최종 수량만 남긴다.

신뢰도 게이트

AI 응답을 그대로 믿지 않고, 등록 직전에 한 번 더 거릅니다. `confidence`가 `high`이고, 수량이 실제 양수이고, 품목명이 비어 있지 않은 것만 자동 등록됩니다. 나머지는 전부 검토 큐로 갑니다 — AI가 적은 이유를 그대로 달아서요.

자동 등록 조건 (셋 다 만족해야 함)
  confidence === 'high'
  quantity 가 유한한 양수
  item 이 빈 문자열이 아님

하나라도 어긋나면 → 검토 큐 + 이유 표시
AI 응답이 JSON 이 아니면 → 전량 검토 큐 (조용히 버리지 않음)

필요한 것

• n8n — 파일 업로드를 외부에서 받으므로 인터넷에서 접근 가능한 주소가 필요합니다.
• Postgres 데이터베이스 하나 — 주문 테이블 하나.
• LLM API 키 — 주문 추출용. 대화량이 많지 않으면 비용은 크지 않지만, 얼마나 나올지 미리 알고 싶다면 저희 `ai-cost-guard` 케이스를 함께 보세요.
• Slack Bot User OAuth Token — 검토 큐 알림용.
• 실제 거래처 대화 내보내기 파일 몇 개 — 형식 확인과 정확도 측정에 필요합니다. 이게 없으면 파서가 맞는지 알 수 없습니다.

주문 테이블

CREATE TABLE IF NOT EXISTS kakao_orders (
  id          bigserial PRIMARY KEY,
  sender      text,                -- 카톡 발신자 이름 (거래처 매핑의 출발점)
  item        text NOT NULL,
  quantity    numeric,
  unit        text,
  status      text NOT NULL DEFAULT 'needs_review',  -- confirmed|needs_review
  source_file text,                -- 어느 내보내기 파일에서 왔는지
  created_at  timestamptz NOT NULL DEFAULT now()
);

CREATE INDEX IF NOT EXISTS kakao_orders_status_idx
  ON kakao_orders (status, created_at DESC);

sender를 남기는 것이 중요합니다. 카톡 표시 이름은 거래처 코드가 아니므로, 표시 이름 → 거래처 코드 매핑 테이블을 따로 두는 것이 다음 단계입니다. 처음에는 이름 그대로 쌓아두고, 매핑이 필요해진 시점에 붙이면 됩니다.

설정 순서 (35분 + 형식 확인)

1. 실제 내보내기 파일부터 확보 — 거래처 대화방을 하나 내보내 텍스트 편집기로 엽니다. 위 세 형식 중 어디에 해당하는지 확인하세요. 이게 1단계입니다.
2. 테이블 생성 — 위 SQL을 실행합니다.
3. Postgres·Slack 자격증명 등록 — 각각 Test로 확인하고, Slack 채널에 /invite @봇이름.
4. 워크플로우 import — n8n → Workflows → ... → Import from File.
5. 모델·API 키 입력 — Build Extraction Prompt 노드의 REPLACE_WITH_YOUR_MODEL과 AI Extract Orders 노드의 REPLACE_WITH_YOUR_API_KEY를 채웁니다.
6. 파서 먼저 테스트 — Parse Chat Export 노드만 실행해 message_count와 unparsed_count를 봅니다. `unparsed_count`가 크면 형식이 다른 것이니 `PATTERNS`에 패턴을 추가하세요. 여기서 넘어가면 뒤가 전부 무의미합니다.
7. 채널명·자격증명 연결 후 Activate.
8. 손으로 대조 — 내보낸 대화의 주문 10건을 직접 세어보고, kakao_orders에 들어간 것과 검토 큐로 간 것의 합이 맞는지 확인합니다. 빠진 주문이 있는지가 핵심 점검 항목입니다.
9. 검토 큐 운영 방식 정하기 — 하루 몇 건이 검토 큐로 가는지 일주일 관찰하세요. 너무 많으면 프롬프트의 품목 예시를 보강하고, 거의 없으면 게이트가 너무 헐거운 건 아닌지 표본으로 확인합니다.

예외 상황이 있으면 어떻게 되나

• 사진으로 온 주문 — 이 워크플로우는 텍스트만 읽습니다. 내보내기 파일에서 사진은 사진 같은 표시로만 남으므로 시스템 메시지로 걸러집니다. 사진 발주가 많은 거래처라면 별도 처리가 필요합니다 — contract-intake 케이스의 OCR 접근이 출발점이 됩니다.
• 한 대화방에 여러 거래처 — sender로 구분됩니다. 다만 카톡 표시 이름이 바뀌면 매핑이 깨지므로, 거래처 매핑 테이블을 두면 이름 변경에 강해집니다.
• 정정 메시지 — 프롬프트에서 최종 수량만 남기도록 지시했습니다. 다만 정정이 며칠에 걸쳐 오면 놓칠 수 있으므로, 같은 거래처의 같은 품목이 짧은 시간에 두 번 들어오면 검토 큐로 보내는 규칙을 추가하는 것을 권합니다.
• 같은 파일을 두 번 업로드 — 이 워크플로우에는 중복 방지가 없습니다. 같은 주문이 두 번 등록됩니다. 실전에서는 `source_file`과 메시지 시각으로 멱등키를 만들어 `ON CONFLICT`를 거세요 — 저희 payment-taxinvoice·lead-capture 케이스가 그 패턴을 보여줍니다.
• AI 응답이 JSON이 아닌 경우 — 전량을 검토 큐로 보내고 파싱 실패를 표시합니다. 조용히 버리지 않습니다.
• 주문이 하나도 없는 대화 — 추출 결과가 비면 등록도 알림도 없습니다. 잡담만 오간 날에 알림이 오지 않는 것이 정상입니다.

카카오톡 대화 내용을 엑셀 파일로 자동 변환하는 기능이 필요합니다.— 국내 개발 외주 플랫폼의 실제 발주 요청