로렌츠 통합 운영 플랫폼

문제

목표

• 여러 채널의 주문을 한 화면에서 처리하고 재고, 배송, 발주, 정산, 상담을 잇는다.
• AI 에이전트는 DB를 읽기만 한다. 데이터를 바꾸는 일은 기존 업무 API로, 직원이 슬랙에서 승인한 뒤에만 실행한다.
• 에이전트는 직원이 관리자 화면에서 할 수 없는 일을 대신하지 않는다. 메뉴 권한을 똑같이 검사한다.
• 일반 배포에서는 DB를 바꾸지 않고, 스키마가 맞지 않는 롤백은 막는다.

풀어 간 과정

처음 시도한 방법, 막힌 지점, 방향을 바꾼 이유를 시간 순서로 적었어요.

1. 2025년 12월

   배송 추적부터 시작했어요

   첫 기능은 송장을 엑셀로 한 번에 올리고 택배사 API로 배송 상태를 조회하는 것이었어요. API가 없는 판매 채널의 주문은 Playwright 시나리오 엔진으로 가져왔어요.

2. 2026년 1월

   채널 주문을 한 화면으로

   네이버 커머스 API 주문을 하나의 주문 화면으로 합치고, 수동 주문과 카페24 주문 동기화를 붙였어요. 송장을 등록하면 주문이 자동으로 배송 처리돼서, 직원이 상태를 따로 바꾸지 않아도 돼요.

3. 2026년 6~7월

   배포 사고 두 번, 배포를 트랜잭션으로

   1월부터 블루그린으로 배포했지만 6월에 두 번 문제가 났어요. 배포가 이지어드민 워커를 다시 띄우지 않아 2주 전 코드가 돌았고, 새로 생긴 필수 컬럼 때문에 이지어드민 주문 동기화가 통째로 실패했어요. 같은 달에는 오래된 환경이 활성화돼 옛 코드가 나갔는데, Nginx 전환이 실패한 것도 드러나지 않았어요. 7월에 배포 기록, 워커 세대 검사, 카나리를 넣었어요.

4. 2026년 9월

   배송 조회를 송장마다 따로

   6시간마다 송장 약 2,900개를 한꺼번에 조회하던 방식은 328개를 두 번 조회하고, 이지어드민 추가 송장 157개는 아예 조회하지 않았어요. 이상이 생긴 송장도 최대 6시간을 기다려야 했고요. 송장마다 다음 조회 시각을 정하고, 5분마다 때가 된 송장만 한 번에 250건까지 조회하게 바꿨어요.

5. 2026년 3~10월

   명령어 봇에서 승인받는 에이전트로

   3월에 사내 API를 읽기만 하는 MCP 서버를 먼저 열었어요. 7월의 첫 슬랙 봇은 AI 모델 없이 정해진 명령 10개만 받았고, 쓰기는 막았어요. 9월에는 대표만 쓰는 읽기 전용 파일럿으로 읽기 도구를 4개에서 14개로 늘리고, 에이전트 도구 6개를 비교해 엔진을 골랐어요. 10월에 직원 7명 모두에게 열었고, 3주 동안 처리하지 못한 요청 30건 중 13건이 쓰기 요청이라 승인 후 실행하는 쓰기 작업을 붙였어요.

지금의 구조

흩어진 채널과 사람의 손을 한 흐름으로 묶었어요.

1. 1

   판매 채널 13곳과 수동 발주, 이지어드민 경로로 주문을 모아요. API가 없는 채널은 Playwright 시나리오 엔진이 처리해요.

2. 2

   Django와 Celery가 주문 동기화, 정산, 알림을 처리해요.

3. 3

   직원은 Next.js 관리자 화면의 주문 허브와 클레임, B2B 화면에서 일해요.

4. 4

   MCP 서버가 사내 API를 읽기 도구와 승인 도구로 열어요.

5. 5

   슬랙 에이전트 '로니'가 질문에 답하고, 데이터를 바꾸는 요청은 제안 카드로 올려 요청한 직원이 승인해야 실행해요.

6. 6

   상담 통화 녹음은 음성 인식과 요약을 거쳐 상담 기록이 되고 슬랙 채널에 올라가요. 슬랙 버튼을 누르면 크롬 확장이 해당 톡톡 채팅방과 고객 정보를 열어요.

7. 7

   배포는 digest를 고정한 이미지로 대기 중인 쪽(블루나 그린)을 먼저 띄우고, 워커 검증과 카나리를 통과하면 Nginx 트래픽을 넘겨요.

핵심 결정

어려웠던 문제

겪었거나 배포 전에 막은 문제를 어떻게 알아챘고, 무엇을 의심해 원인을 찾았는지, 다시 일어나지 않게 무엇을 바꿨는지 기록했어요.

    self._scrape_preparing_orders_into_db(driver, result)
if file_path is None:
    return result
orders = self.parse_excel_file(file_path)
saved, new, upd = self.save_orders_to_db(orders)

    if file_path is not None:
        orders = self.parse_excel_file(file_path)
        if orders:
            saved, new, upd = self.save_orders_to_db(orders)
        else:
            excel_parse_failed = True
    self._scrape_preparing_orders_into_db(driver, result)  # 엑셀 다음
result["success"] = (not excel_parse_failed) or result["scraped_new"] > 0

# 정리 명령: 세 값이 모두 같을 때만 지워요
return (loser.total_price == survivor.total_price
        and loser.quantity == survivor.quantity
        and loser.product_name.strip() == survivor.product_name.strip())

# 대기 중인 마이그레이션에 스키마 전환이 있으면 일반 배포를 멈춰요
while IFS= read -r migration; do
  case "$migration" in
    <data-copy>|<column-drop>|<create-copy-drop>)
      error "Schema transition requires a quiesced cutover and verified database recovery"
      return 1 ;;
  esac
done < <(pending_migration_names)

# 워커 시작, Nginx 전환, 역방향 복구 앞마다 하한을 확인해요
start_workers() {
  schema_release_allowed "${GIT_COMMIT:-}" || return 1
reverse_deployment_transaction() {
  schema_entry_allowed || return 1
  schema_release_allowed "$JOURNAL_PREDECESSOR_COMMIT" || return 1

WORKER_START_TIMEOUT="${WORKER_START_TIMEOUT:-60}"
validate_minimum_capacity <BEAT_LIMIT> "${..:-512m}" 512
validate_minimum_capacity <UPLOAD_SCAN_LIMIT> "${..:-768m}" 768

WORKER_START_TIMEOUT="${WORKER_START_TIMEOUT:-240}"
validate_minimum_capacity <BEAT_LIMIT> "${..:-1g}" 1024
validate_minimum_capacity <UPLOAD_SCAN_LIMIT> "${..:-1536m}" 1536

결과

주문 허브

판매 채널 13곳과 수동 발주를 한 화면에서

외부 연동

택배사, 은행 계좌 조회 포함 25곳 넘게

배송 조회

6시간마다 일괄 조회에서, 송장마다 30분~12시간 간격으로

운영 에이전트

MCP 도구 30여 개, 승인으로 실행하는 작업 8종

에이전트 점검

직무별 질문 28개 중 27개 통과

승인 카드

요청 후 약 10초 안에 슬랙에 올라와요

테스트 파일

백엔드 1,264개, 프론트엔드 517개

• 직원이 쇼핑몰 주문을 복사해 등록하거나, 택배사 사이트에서 배송을 하나씩 조회하지 않아요.
• 상품 입수량이나 최소 주문 수량을 다른 직원에게 묻지 않고 슬랙에서 로니에게 물어요.
• 상담 통화가 요약된 상담 기록으로 남아 슬랙 채널에서 바로 보여요.

같이 일한 방식

• 직원들이 실제로 한 업무 질문 40개로 검증 세트를 만들었고, 직무별 질문 28개를 DM으로 보내 에이전트를 점검했어요. 27개가 통과했고, 실패한 1개는 백엔드 권한 버그여서 고쳤어요.
• 에이전트가 처리하지 못한 요청을 모아 다음에 만들 기능의 순서를 정했어요.
• 직원이 고친 답변이 사내 위키보다 우선하도록 규칙을 정했어요.
• 비개발 직원을 위한 해요체 설치 가이드와 사용자 가이드 문서를 쓰고, 관리자 화면 안에 공지와 기능 요청, 버그 게시판을 두었어요.