Read Original
#Backend

채널톡의 FDE는 어떤 일을 할까?

채널톡의 FDE는 어떤 일을 할까?
01

Summary

제품에 없는 기능도 직접 만든다! 채널톡 FDE가 고객 문제를 무기로 바꾼 기술 잔혹사

BizDev와 제품팀 사이에서 PoC 개발부터 정식 베타 제품화까지 이끌어낸 현장 중심 엔지니어링 실전기

채널톡 FDE(Forward Deployed Engineer)팀이 대규모 전화 캠페인 요구사항을 현장에서 신속하게 검증하고 제품화로 이끌어낸 1년간의 여정을 담은 글입니다. 정식 제품이 부족한 상황에서 과감한 트레이드오프와 현용 인프라 활용으로 비즈니스 기회를 창출한 실전 엔지니어링 인사이트를 제공합니다.

  • 01제품 미지원 기능을 풀어내기 위해 기존 전화·워크플로우 인프라 위에 발신 관리 앱을 빠르게 구축
  • 02SQS 및 다중 실행기 도입 대신 PostgreSQL 상태 저장과 단일 실행기를 선택하여 신속 개발 및 상태 복잡도 최소화
  • 03CPS 제한 및 최대 통화 시간 기준 회선 점유를 보수적으로 계산하여 대규모 전화 발신 안정성 확보
  • 04중복 발신 부작용을 막기 위해 자동 재시도를 지양하고 대조 작업으로 한계점을 보완한 현실적 기술 선택
  • 05단일 고객을 위한 해법이 신규 딜 체결 및 정식 베타 제품화로 연결되는 선순환 구조 정립

RECOMMENDATION

고객 현장의 요구사항을 빠르게 검증해야 하는 B2B SaaS 엔지니어나, 비즈니스와 제품 개발 간 인터페이스에 관심이 있는 리더에게 강력히 추천합니다.

The Problem

고객사의 수천~수만 건 대규모 전화 발신 및 통계 분석 요구사항이 존재했으나, 당시 채널톡 제품에는 이를 일괄 제어하고 캠페인 형태로 운영할 정식 기능이 없었습니다.

The Solution

FDE팀은 기존 전화, 워크플로우 인프라를 기반으로 PostgreSQL 작업 관리 및 단일 실행기 구조를 갖춘 발신 제어 앱을 신속히 개발하여 PoC 형태로 제공했습니다.

The Result

입금 안내, 방문 리마인드 등 실제 전화 업무 문제를 연이어 해결하며 수요를 검증했고, 해당 PoC는 현재 베타 테스트 제품 및 공식 제품화 단계로 확장되었습니다.

Trade-off

빠른 일정 맞춤 및 시스템 상태 최소화를 위해 SQS 큐 도입과 다중 실행기, 자동 재시도 로직을 제외하고 중복 발신 방지를 우선 선택함에 따라 일부 미수신 대상에 대한 자동 재발신이 제한되었습니다.

03

Key Concepts

Concept · 01

Forward Deployed Engineer (FDE)

고객 밀착 접점에서 비즈니스 문제를 정의하고, 정식 제품 출시 전 기술 솔루션이나 PoC를 빠르게 구현하여 실제 고객 가치와 시장 수요를 검증하는 역할입니다.

  • BizDev팀과 협력하여 고객 요구를 분석하고 기존 채널톡 기반 위에서 작동하는 PoC 앱을 제작했습니다.
  • 고객 현장 검증 결과를 제품팀과 공유하여 채널톡 정식 제품 스펙 논의의 근거로 제공했습니다.
Concept · 02

CPS (Calls Per Second) & 회선 점유 관리

초당 발신 건수 제한(CPS)을 준수하는 동시에 통화 지속 시간에 따른 회선 점유율을 계산하여 통신 인프라 과부하를 방지하는 제어 기법입니다.

  • 최대 통화 시간을 기준으로 필요 회선 수를 보수적으로 산출하여 안전한 발신 속도와 예약 물량을 산정했습니다.
  • 확보된 가용 용량 범위 내에서 작업을 처리하여 인프라 장애와 중복 발신 위험을 예방했습니다.
Concept · 03

PostgreSQL 기반 태스크 스케줄링

메시지 큐(예: SQS) 도입에 따른 트랜잭션 불일치와 운용 복잡성을 피하기 위해 RDB 내 작업 상태 필드와 주기적 폴링 방식을 활용하는 경량화된 스케줄링 기법입니다.

  • DB와 큐 사이의 상태 전달 오류 유실 가능성을 차단하기 위해 PostgreSQL에 진행 상태를 직접 기록했습니다.
  • 단일 실행기가 주기적으로 작업을 읽어 처리하는 구조로 초기 분산 제어의 복잡성을 제거했습니다.