Server Engineer 데이터 흐름으로 운영을 설계하는 서버 엔지니어

대표 프로젝트 굴삭기 판매 영업 운영 플랫폼 Django · Redis · AWS 기반 통합 운영 플랫폼 구축

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

End-to-End Ownership 요구사항 정리 아키텍처 설계 서버 구현 배포 / 운영 장애 개선

전체 아키텍처 보기 핵심 기능 보기

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

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

Backend Platform Django Redis MySQL Docker AWS

프로젝트 방향

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

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

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

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

서비스 운영

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

실시간 방문 행동 데이터

고객이 어떤 장비를 보고 어디에서 이탈하는지 파악할 필요. 조회, 클릭, 스크롤 이벤트가 계속 발생해 DB 직접 저장 시 불필요한 쓰기 부하 발생.

시운전 예약

웹사이트 예약 신청을 사람이 다시 전달할 경우 초기 연락 지연 발생. 고객 정보와 관심 장비가 영업 보드로 즉시 전달되는 구조 필요.

A/S 접수

고장 접수는 데이터 저장과 담당자 알림이 동시에 필요한 업무. 접수 내용 저장, 첨부 자료 관리, Slack 알림을 함께 처리하는 구조 필요.

고장 영상 업로드

고객이 첨부한 고장 영상은 서버 측 포맷 변환 필요. 동시 업로드 시 메모리 사용량이 급증하므로 요청 처리와 영상 변환의 분리 필요.

영업 자동화

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

Meta 광고 리드

광고 문의가 이후 상담, 미팅, 구매 단계와 분리될 경우 리드 품질 판단이 어려움. 광고 리드를 CRM 단계와 연결하는 구조 필요.

전화 / 문자 상담

광고나 웹사이트 이후 업무용 번호로 직접 들어오는 전화·문자 상담 다수 발생. 상담 내용을 수기 입력 없이 고객 Timeline에 자동 기록하는 구조 필요.

중고 굴삭기 구매 수요 글

카페와 밴드에는 구매글, 질문글, 정보글이 혼재. 실제 구매 의도가 있는 굴삭기 수요 글만 선별해 영업 대상으로 등록하는 과정 필요.

광고 최적화

Meta가 단순 문의자가 아니라 실제 구매 가능성이 높은 고객을 학습하도록 구성할 필요. 구매 완료 데이터를 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 접수 상세와 첨부 자료 관리 화면

설계 이유

고객 접점인 hyunjin-web과 운영 처리 공간인 board를 분리하고, 예약/A/S 요청은 POST로 전달. 실시간 행동 이벤트는 DB 직접 저장 대신 Redis에 먼저 적재해 쓰기 부하를 줄이는 구조.

결과

고객 접점에서 발생한 운영 데이터가 영업 담당자의 후속 연락과 처리 판단으로 바로 연결.

영업 자동화 플랫폼

영업 고객 관계 단계 관리 대시보드

해결하려는 문제여러 채널에서 발생하는 영업 데이터의 통합 관리

Meta 리드, 웹사이트 행동 분석, 전화·문자 상담, 고객 관계 단계를 한 화면에서 확인하고 관리할 수 있는 대시보드 필요.

구현Django AdminCRM 모델상태 관리DashboardMySQL

구현 상세

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

설계 이유

Meta Webhook, Android REST API, 웹 행동 로그처럼 입력 방식이 다른 데이터를 board 컨테이너의 공통 CRM 모델로 정규화. 상태값을 DB 모델로 관리해 고객 관계 단계를 일관되게 추적하는 구조.

결과

고객별 상태를 관심, 상담, 미팅, 구매 단계로 확인하고 다음 영업 액션을 빠르게 결정할 수 있는 구조.

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 Classification을 먼저 수행. confidence_score 기준으로 필터링한 뒤 Entity Extraction을 적용해 톤수, 예산, 지역, 용도를 구조화하는 파이프라인.

결과

confidence_score 0.7 이상 글만 영업 보드에 등록하여 담당자가 가능성 높은 수요부터 확인하는 구조.

Meta Closed-loop CRM

전환 잠재고객 최적화를 위한 Meta 데이터 연동

해결하려는 문제Meta가 더 유효한 고객에게 광고를 노출하도록 만드는 구조

단순 문의 고객이 아니라 실제 구매 가능성이 높은 고객 정보를 Meta에 전달해 타겟을 재조정할 필요.

구현WebhookCRM APIConversion APIPurchase EventMeta

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

구현 상세

영업 보드구매 확정

CRM 단계 변경

Django전환 이벤트 JSON 생성

{
  "data": [
    {
      "action_source": "system_generated",
      "custom_data": {
        "event_source": "crm",
        "lead_event_source": "통합CRM",
        "currency": "KRW",
        "value": 22000000
      },
      "event_name": "Purchase",
      "event_time": 1719999999,
      "user_data": {
        "lead_id": "1321735499882524",
        "ph": ["sha256_hash_of_821012341234"]
      }
    }
  ]
}

Meta CAPI전환 이벤트 전송

전환 잠재고객 최적화

왜 Webhook인가

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

왜 CAPI인가

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

Android CRM

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

해결하려는 문제전화·문자 인바운드 영업 정보의 자동 공유

다이렉트로 들어오는 전화와 문자 상담 내용을 수기 입력 없이 자동으로 보드에 등록하고, 영업 담당자가 즉시 확인할 수 있는 구조 필요.

구현Android AppREST APIPhone MatchingCRM TimelineDjango

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

구현 상세

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

설계 이유

전화·문자 이벤트는 Android 단말에서 먼저 발생하므로, 앱에서 이벤트를 감지한 뒤 REST API로 Django 서버에 전송. 서버에서는 전화번호 기반 고객 매칭 후 Timeline 모델에 상담 이력을 누적하는 구조.

결과

전화, 문자, 미팅 이력이 고객 Timeline에 자동 누적되어 담당자가 상담 맥락을 바로 확인하는 구조.

Backend Platform

모든 운영 데이터를 하나의 비즈니스 로직으로 처리하는 Backend

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

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

구현DjangoORMREST APIServer-side ValidationDashboard

데이터 흐름

① Python 생태계 활용

AI 기반 NLP, 크롤링, 데이터 전처리까지 모두 Python으로 구현. 웹 서버 역시 Django를 사용하여 별도 API 서버나 언어 전환 없이 하나의 런타임에서 데이터 처리.

② Business Logic 통합

웹사이트, Meta Webhook, Android 앱, 크롤러에서 들어오는 데이터를 하나의 Business Logic으로 통합. Validation, 고객 매칭, CRM 생성, 영업 파이프라인 처리를 동일 규칙으로 처리.

③ ORM 기반 데이터 관리

예약, A/S, 고객, 상담 이력, Meta 리드 등 서로 다른 데이터를 관계형 모델로 관리. ORM을 활용한 일관성 있는 데이터 처리.

④ 기본 보안 기능

CSRF 보호, ORM 기반 SQL Injection 방지, 입력값 검증 등을 활용하여 외부 API와 사용자 입력을 안전하게 처리.

Infrastructure

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

해결하려는 문제성격이 다른 서버 역할이 하나의 실행 환경에 섞이는 문제

고객용 웹사이트, 영업 대시보드, 이벤트 큐는 처리하는 요청과 변경 주기가 달라 컨테이너 단위의 역할 분리 필요.

구현AWS EC2DockerNginxHTTPSRedis

데이터 흐름

사용자 요청이 HTTPS Nginx Reverse Proxy를 거쳐 Internal Docker Network의 Service Platform, Sales Platform, Redis 컨테이너로 전달되는 인프라 구조 — Nginx Reverse Proxy를 외부 진입점으로 두고, Service Platform, Sales Platform, Redis를 Internal Docker Network 안에서 분리한 구조

설계 이유

운영용 웹사이트, 영업 대시보드, 이벤트 저장소는 역할과 변경 주기가 달랐기 때문에 각각 3개의 컨테이너로 분리. 웹사이트는 고객 요청과 예약/A/S 접수를 처리하고, board는 CRM·영업 데이터·외부 API 연동을 담당하며, Redis는 실시간 이벤트와 작업 큐를 처리하도록 구성. 세 컨테이너는 같은 Docker Network를 공유하여 외부에 불필요한 포트를 노출하지 않고 내부 서비스명으로 통신할 수 있도록 설계.

Troubleshooting

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

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

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

구현QueueWorkerEncodingSlack APIDB 저장

데이터 흐름

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

구현 상세

Before

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

After

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

왜 Queue인가

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

결과

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