굴삭기 판매 영업 운영 플랫폼 Backend Engineer Django · Redis · AWS 기반 통합 운영 플랫폼 구축

중고·신형 굴삭기 판매 영업을 위한 서비스 운영 플랫폼과 영업 자동화 플랫폼을 하나의 Backend Platform으로 통합한 프로젝트.

서비스 운영 플랫폼 홈페이지 시운전 예약 A/S 접수 영상 처리 사용자 행동 분석

영업 자동화 플랫폼 AI 수요 분석 Meta 광고 연동 CRM Android 상담 연동 영업 파이프라인

Backend Platform Django Redis MySQL Docker AWS

01서비스 운영 플랫폼Operation

02영업 자동화 플랫폼Sales

03Django BackendCore

04Redis / MySQLData

05Docker / AWSInfra

06Queue / WebhookReliability

프로젝트 방향

서비스 운영과 영업 자동화의 백엔드 플랫폼 통합

서비스 운영 플랫폼 홈페이지시운전 예약A/S 접수영상 업로드행동 분석

영업 자동화 플랫폼 AI 시장 분석Meta 광고CRMAndroid영업 파이프라인

운영에 필요한 데이터는 웹사이트, 광고 플랫폼, Android 애플리케이션, 외부 커뮤니티 등 다양한 채널에서 발생. 채널별 생성 방식과 처리 방식이 달라, 영업 담당자가 바로 사용할 수 있는 형태로 표준화하는 것이 핵심 과제.

서비스 운영

고객 접점 요청의 안정적 처리

실시간 방문 행동 데이터

조회, 클릭, 스크롤 이벤트 증가로 인한 DB 직접 쓰기 부하

시운전 예약

웹사이트 예약 신청의 영업 보드 즉시 전달 필요

A/S 접수

접수 내용 저장과 담당자 Slack 알림 동시 처리 필요

고장 영상 업로드

동시 업로드와 영상 변환 과정의 메모리 사용량 급증

영업 자동화

광고·상담·시장 수요 데이터의 영업 판단 연결

Meta 광고 리드

광고 문의, CRM 단계, 구매 전환 데이터의 연결

전화 / 문자 상담

업무용 번호 상담 이력의 고객 Timeline 자동 기록

중고 굴삭기 구매 수요 글

커뮤니티 질문글과 정보글 사이에서 실제 구매 의도 선별

광고 최적화

구매 완료 데이터를 Meta로 재전송해 실제 구매 고객 기반 타겟 조정

Website방문 행동

조회 · 클릭 · 스크롤

Reservation시운전 예약

고객 정보 · 관심 장비

A/S접수 / 영상

고장 내용 · 파일 업로드

Django Backend 굴삭기 판매 영업 운영 플랫폼

CRM · Dashboard · Queue · Redis · MySQL

Meta광고 리드

Lead Webhook · CAPI

Android전화 / 문자

상담 Timeline

NLP구매 수요

Intent · Entity JSON

전체 아키텍처

전체 파이프라인 아키텍처

서버 구조 최적화

요청 처리, 영업 운영, 실시간 버퍼를 3개 컨테이너로 분리한 운영 서버 구조

웹 요청과 영업 보드, Redis 이벤트 처리를 한 프로세스에 몰아넣지 않고 역할별 컨테이너로 나누어 장애 범위와 처리 책임을 분리한 구조.

AWS EC2 Server

Docker Network

container 1 hyunjin-web

고객 접점과 서비스 요청을 처리하는 웹 컨테이너

홈페이지 / 제품 상세
시운전 예약 POST
A/S 접수 및 파일 업로드
Redis 방문 행동 이벤트 수집

container 2 board

영업 데이터와 외부 연동을 처리하는 보드 컨테이너

CRM / 상담 Timeline
Meta Lead Webhook
Android 전화/문자 연동
Crawler / NLP 수요 분석

container 3 redis

짧고 빈번한 이벤트와 비동기 작업을 받는 버퍼 컨테이너

웹 방문 행동 임시 저장
영상 변환 작업 Queue
주간 단위 MySQL 적재
실시간 Dashboard 데이터 공급

Core Features

핵심 기능별 데이터 흐름과 설계 근거

문제 → 데이터 흐름 → 구현 → 실제 예시 → 설계 이유 구조.

서비스 운영 플랫폼

웹사이트 요청의 운영 데이터 전환

해결하려는 문제예약, A/S, 행동 로그의 분산 발생

고객 접점 요청을 영업 보드와 운영 관리 화면으로 즉시 연결할 필요.

구현DjangoREST APIRedis EventSlack APIMySQL

서비스 운영 플랫폼에서 예약과 A/S 정보가 영업 자동화 플랫폼으로 전송되는 흐름 — 홈페이지의 예약/A/S 정보가 영업 자동화 플랫폼으로 전달되는 흐름

해결 과정

POST
{
  "name": "홍길동",
  "phone": "010-0000-0000",
  "machine": "he-017",
  "region": "서울/경기",
  "desired_date": "2026-03-31"
}

POST
{
  "receipt_no": "AS-20260703143022-A1B2C3",
  "customer_name": "홍길동",
  "phone": "010-1234-5678",
  "machine": "he-017",
  "region": "서울/경기",
  "description": "작업 중 유압이 약하고 붐 상승 속도가 느립니다.",
  "status": "received"
}

시운전 예약 데이터가 보드에 표시된 화면 — 시운전 예약 데이터가 board에 등록된 화면

A/S 접수 상세와 첨부 자료가 보드에 표시된 화면 — A/S 접수 상세와 첨부 자료 관리 화면

왜 분리했는가

웹사이트는 고객 요청 접점, board는 운영 처리 공간. 역할 분리 필요.

결과

예약과 A/S의 운영 보드 즉시 확인 흐름 구축.

영업 자동화 플랫폼

문의·상담·미팅·구매 전환의 CRM 흐름 통합

해결하려는 문제담당자별로 흩어진 영업 상태

Lead부터 구매까지 이어지는 단계의 보드 기반 관리 필요.

구현Django AdminCRM 모델상태 관리DashboardMySQL

해결 과정

Meta 리드가 영업 보드에 유입된 화면 — Meta 리드가 들어왔을 때의 영업 보드 화면

왜 단계 관리인가

광고 리드의 매출 전환 여부 확인을 위한 상태 변화 데이터화.

결과

담당자별 상담 진행과 구매 전환을 한 화면에서 확인하는 구조.

AI 기반 수요 분석

커뮤니티 글의 구매 수요 데이터 구조화

해결하려는 문제판매글, 질문글, 구매글이 섞인 커뮤니티 데이터

구매 의도 선판별 후 가능성이 높은 글만 영업 대상으로 추출.

구현Python CrawlerNLPIntent ClassificationEntity ExtractionMySQL

영업 자동화 플랫폼이 필요한 데이터를 요청하고 AI 기반 수요 분석이 수요 데이터를 응답하는 흐름 — 영업 자동화 플랫폼이 키워드/지역 조건으로 데이터를 요청하고, NLP 분석 결과를 수요 데이터로 응답하는 흐름

해결 과정

CASE A · PASS

농사용 1.7톤 굴삭기 찾습니다.
예산은 1800 정도 생각하고 있습니다.
전남에서 구합니다.

confidence_score0.980.7 이상 → 영업 대상

{
  "equipment_type": "굴삭기",
  "tonnage": "1.7톤",
  "budget_min": 1800,
  "region": "전라남도",
  "purpose": "농업",
  "intent": "구매",
  "confidence_score": 0.98,
  "board_status": "registered"
}

영업 보드 등록

지역, 예산, 톤수 기준으로 수요 Dashboard에 표시

CASE B · DROP

농사용 1.7톤 굴삭기 사용 중 질문 있습니다.
작업 중 관리 방법이 궁금합니다.

confidence_score0.240.7 미만 → 제외

{
  "equipment_type": "굴삭기",
  "purpose": "질문",
  "intent": "정보 문의",
  "confidence_score": 0.24,
  "board_status": "discarded"
}

보드 미등록

구매 의도가 낮아 영업 대상에서 제외

왜 Intent 먼저인가

Entity 추출 전 구매 의도가 낮은 글을 제외해 불필요한 영업 대상 감소.

왜 0.7 기준인가

정보성 게시글을 걸러내고 실제 구매 가능성이 높은 글만 보드에 등록.

Meta Closed-loop CRM

광고 리드와 실제 구매 데이터의 Closed-loop 연결

해결하려는 문제문의 수에서 멈추는 광고 성과 측정

실제 구매 고객 데이터를 Meta에 다시 전달해 광고 학습 기준으로 활용.

구현WebhookCRM APIConversion APIPurchase EventMeta

Meta 리드와 구매 전환 데이터가 영업 자동화 플랫폼과 양방향으로 연결되는 흐름 — Meta 리드가 CRM으로 들어오고 구매 전환 데이터가 다시 Meta CAPI로 전달되는 흐름

해결 과정

{
  "event_name": "Purchase",
  "action_source": "system_generated",
  "customer_phone": "hashed_phone",
  "value": 18000000
}

왜 Webhook인가

광고 리드를 폴링하지 않고 발생 즉시 CRM으로 수집.

왜 CAPI인가

문의가 아닌 구매 고객 기준의 광고 타겟 최적화.

Android CRM

전화·문자 상담 이력의 CRM Timeline 연결

해결하려는 문제CRM 밖에 남는 오프라인 상담 이력

업무용 번호의 전화와 문자를 고객 데이터와 자동 매칭할 필요.

구현Android AppREST APIPhone MatchingCRM TimelineDjango

Android CRM의 전화 문자 데이터가 REST API를 통해 영업 자동화 플랫폼으로 전송되는 흐름 — 전화·문자 상담 데이터가 Android App과 REST API를 거쳐 영업 자동화 플랫폼으로 전송되는 흐름

해결 과정

전화 문자 상담 데이터가 영업 보드에 연결되어 표시된 화면 — 전화·문자 상담 데이터의 고객 Timeline 연결 화면

왜 REST API인가

Android 이벤트를 Django 서버로 단순하고 안정적으로 전달.

결과

전화, 문자, 미팅 이력의 고객 단위 누적.

Backend Platform

운영 요청과 영업 데이터를 처리하는 Django Backend 중심 구조

해결하려는 문제웹, CRM, 외부 API, Dashboard의 고객 데이터 기준 통합

흩어진 스크립트가 아닌 공통 백엔드 중심 처리 필요.

구현DjangoORMREST APIServer-side ValidationDashboard

해결 과정

Lead
- customer_phone
- source
- status
- assigned_to
- timeline_events
- purchase_event_sent

왜 Django인가

관리자 페이지, ORM, 서버 검증, 대시보드 구성이 운영 플랫폼에 적합.

왜 서버 검증인가

광고, 웹, Android에서 들어오는 서로 다른 데이터 형식의 백엔드 정규화.

Infrastructure

AWS EC2와 Docker Network 기반 역할별 컨테이너 분리

해결하려는 문제웹 요청, 보드 처리, 이벤트 버퍼가 한 흐름에 몰릴 때 커지는 장애 범위

운영 책임을 컨테이너 단위로 나누는 구조 필요.

구현AWS EC2DockerNginxHTTPSRedis

해결 과정

Container Roleshyunjin-web: 고객 접점board: 영업 보드redis: 이벤트 버퍼MySQL: 운영 데이터

왜 Docker인가

실행 환경 고정과 웹, 보드, Redis 역할 분리.

왜 Redis인가

짧고 빈번한 이벤트를 MySQL에 직접 쓰지 않는 버퍼 구조.

Troubleshooting

동영상 업로드 메모리 문제의 Queue 기반 비동기 처리

해결하려는 문제동시 고장 영상 업로드 시 포맷 변환 중 메모리 사용량 급증

사용자 응답과 무거운 영상 처리의 분리 필요.

구현QueueWorkerEncodingSlack APIDB 저장

데이터 흐름

동영상 업로드를 즉시 응답, 원본 저장, 큐 등록, 워커 변환, DB 업데이트로 처리하는 상세 시퀀스 — 동영상 업로드 요청을 즉시 응답과 백그라운드 변환 작업으로 분리한 상세 처리 시퀀스

해결 과정

Before

요청 중 영상 변환 → 메모리 급증 → 응답 지연

After

접수 완료 응답 → Queue 적재 → Worker 처리

왜 Queue인가

무거운 영상 변환을 요청/응답 흐름에서 분리해 서비스 안정성 확보.

결과

사용자는 빠르게 접수 완료 응답, 서버는 작업을 순차 처리.

Lessons Learned

비즈니스 흐름과 서버 구조를 함께 고려한 운영 인프라 설계

이 프로젝트에서 중요한 것은 기능을 많이 붙이는 것이 아니라, 어떤 데이터가 서비스 운영에 속하고 어떤 데이터가 영업 자동화에 속하는지 구분한 뒤, 두 흐름을 안정적인 백엔드 플랫폼에서 만나게 하는 구조.