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

채널톡 FDE 이야기 - 1

Polar • Forward Deployed Engineer

안녕하세요. 채널톡 FDE(Forward Deployed Engineer)팀의 폴라입니다.

채널톡에 FDE팀이 생긴 지 1년이 됐어요. 지난 1년은 우리가 어떤 문제를 맡고, 어떤 방식으로 풀어야 할지 여러 시도를 거치며 방향을 찾아온 시간이었어요.

고객에게 채널톡을 제안하다 보면, 기존 기능만으로는 해결하기 어려운 문제를 만나기도 해요. FDE는 BizDev팀과 고객의 업무를 살피고, 기존 기능으로 풀 수 있는 부분과 추가 개발이 필요한 부분을 나눠요. 가능성이 보이면 아직 제품에 없는 기능도 그 고객을 위해 만들어 제공하겠다고 제안해요. 제품팀과 필요한 기반을 확장하고, 실제 업무에 쓸 수 있는 PoC로 만드는 거예요.

BizDev팀은 이 기능을 다음 고객에게 제안하고, 기존 고객이 채널톡으로 해결하는 업무도 넓혀요. 그 과정에서 가져온 요구를 FDE와 함께 검토해 기능을 보완하고요. 고객에게 먼저 제공하고 다음 고객으로 넓혀가며 확인한 수요와 사용 경험을, 더 많은 고객이 쓸 제품을 만드는 근거로 삼는 거예요.

채널톡 FDE팀이 풀어온 문제들을 시리즈로 소개하려고 해요. 첫 글에서는 제가 맡았던 마케팅 PoC와 콜 캠페인을 다뤄요. 다음 글부터는 다른 팀원들이 각자 풀었던 문제와 그 과정에서의 선택을 이어서 소개할 예정이에요.

1. 고객의 문제에서 시작하기

한 고객사는 웹사이트에 들어왔다가 상담 신청 없이 떠나는 방문자를 실제 상담으로 연결하고 싶어 했어요. BizDev팀과는 방문자에게 먼저 말을 걸어 질문에 답하고, 상담 신청까지 이어지는 흐름을 제안했어요. 새 마케팅 제품이 준비되기 전에도 먼저 풀어볼 수 있는 문제였어요. 채널톡의 AI 에이전트 ALF와 워크플로우를 조합해 대화하고 연락처를 수집하는 형태로 제공했어요.

확인하고 싶었던 건 실제 상담 기회가 늘어나는지였어요. 현장의 요구와 아이디어는 제품팀과 공유했지만, 비교 기준과 충분한 운영 기간을 확보하지 못해 효과를 명확히 확인하는 데에는 아쉬움이 남았어요. 무엇을 만들지와 함께 어떤 변화를 확인할지도 정해야 했던 거죠. 그 과정에서 고객의 요구를 구체화하고, 제품이 준비되기 전에 실제로 써볼 기능으로 만드는 역할이 필요하다는 걸 느꼈어요. FDE가 채널톡에서 맡아야 할 일이 조금씩 보이기 시작했어요.

2. 제품에 없던 기능을 고객에게 제공하기까지

이후 다른 고객에게 채널톡을 제안하는 과정에서 대규모 전화 업무 수요를 발견했어요. 수천~수만 건을 발신하고, 누가 받았는지 통계로 확인한 뒤, 받지 않은 대상에게 다시 연락하고 싶다는 요구였어요. 고객에게 필요한 건 발신부터 결과 분석, 다음 발신까지 이어지는 캠페인 운영이었어요.

당시 채널톡에는 이 과정을 묶은 정식 제품이 없었어요. 대신 전화와 워크플로우, 통화 기록이라는 기반은 있었죠. BizDev팀과 이 기반으로 어디까지 풀 수 있을지 검토하고, 필요한 기능을 직접 만들어 제공하겠다고 제안했어요.

함께 만들고, 먼저 제공하다

초기에는 고객의 발신을 직접 지원했고, 이후에는 반복해서 운영할 수 있는 앱으로 옮겼어요. 고객과 약속한 발신 일정에 맞춰 빠르게 제공하는 게 중요했어요. 하지만 처음 사용할 고객이 소수라고 해서 다뤄야 할 규모까지 작은 건 아니었어요. 한 번 실행하면 수천~수만 건의 전화가 나갔고, 제한된 회선 안에서 처리해야 했어요. 빠진 대상도 확인할 수 있어야 했고, 무엇보다 같은 고객에게 중복으로 전화가 가는 건 피해야 했어요.

그래서 먼저 지켜야 할 조건과, 제공한 뒤에 개선할 부분을 나눴어요. 기존 전화와 워크플로우를 활용해 개발 범위를 캠페인 운영에 집중했어요. 음성 안내 발신과 안내 후 통화 종료는 제품팀이 확장한 기능을 활용하고, FDE는 그 위에 발신 대상을 관리하고 예약한 시점에 실행하는 앱을 붙였어요.

가장 고민한 건 응답이 오지 않은 발신 요청을 어떻게 처리할지였어요. 다시 요청하면 빠진 발신을 처리할 수 있지만, 응답만 유실됐다면 이미 걸린 전화를 한 번 더 걸 수도 있었어요. 이번 PoC에서는 중복 발신을 피하는 쪽을 우선했어요. 결과가 불확실한 요청은 자동으로 재시도하지 않고, 한 번 실행을 시작한 작업 묶음도 다시 실행하지 않도록 했어요. 일부 대상에게 전화가 가지 않을 가능성은 남지만, 원래 발신 대상과 실제 통화 기록을 대조해 결과가 확인되지 않은 대상을 따로 살펴볼 수 있게 했어요.

발신 속도에도 선택이 필요했어요. 정해진 시간 안에 많은 전화를 걸려면 속도를 높이고 싶지만, 초당 발신 한도인 CPS만 지킨다고 충분한 건 아니었어요. 통화가 길어지면 회선을 계속 점유하기 때문에, 같은 속도로 발신해도 필요한 회선 수는 달라져요. 제품팀과 가용 용량을 확인하고, 최대 통화 시간을 기준으로 회선 점유를 보수적으로 계산했어요. 회선을 덜 활용하는 순간이 생기더라도, 확보한 용량 안에서 처리할 수 있도록 예약 물량과 발신 속도를 정했어요.

예약과 실행에는 SQS 같은 별도 큐를 붙이는 방안도 검토했어요. 다만 큐를 추가하면 DB에는 작업이 저장됐지만 큐에는 전달되지 않은 상황까지 다뤄야 했어요. 당시 처리량에서는 PostgreSQL에 작업과 진행 상태를 저장하고, 실행기가 주기적으로 읽어 처리하는 것으로 충분했어요. 지금 필요한 규모를 처리하면서, 함께 관리해야 할 상태를 줄이는 쪽을 선택했어요.

실행기도 하나로 시작했어요. 여러 실행기로 나누면 각 실행기가 제한을 지키더라도, 합산한 발신량은 전체 CPS를 넘을 수 있었어요. 이를 함께 제어하는 구조와 무중단 배포까지 갖추는 일은 초기 범위에서 제외했어요. 배포나 장애 때 잠시 멈추는 것은 허용하고, 작업 상태를 남겨 아직 시작하지 않은 작업부터 이어갈 수 있게 했어요. 약속한 일정 안에 고객이 써볼 수 있도록, 발신 제어와 결과 확인에 개발 시간을 먼저 집중한 거예요.

발신 결과를 확인하는 흐름도 함께 만들었어요. 기존 통화 기록을 캠페인별로 모아 수신·미수신 현황을 확인하고, 받지 않은 대상을 추려 다음 발신에 사용할 수 있게 했어요. 이후에는 채널톡의 데이터 분석 도구 CoS에서도 분석할 수 있도록 연결하고, 운영하면서 분석 화면과 편의 기능을 보완해 나갔어요.

한 고객의 해법이 다음 딜의 무기로

기능을 제공한 뒤, BizDev팀은 이를 다른 고객에게도 적극적으로 제안했어요. 신규 고객에게는 채널톡과 함께 소개하고, 기존 고객에게는 전화 업무까지 해결할 수 있다고 제안했어요.

다른 고객에게서도 비슷한 문제가 보였어요. 납부일에 맞춰 많은 고객에게 입금을 안내하고 싶다는 요구, 상담을 예약하고도 방문하지 않는 고객을 줄이고 싶다는 요구가 있었어요. 미납 고객에게 연락한 뒤, 미납 항목과 사유에 대한 상담까지 연결하려는 요구도 있었고요.

새로운 요구가 들어올 때마다 FDE와 BizDev팀은 바로 제공할 것과 다음 단계로 미룰 것을 함께 정했어요. 방문 리마인드는 예약이 확정된 고객에게 안내하는 기능부터 제공하고, 대화형 전화와 CRM 연동은 다음 단계로 미뤘어요. 안내 콜만으로도 고객의 업무에 도움이 되는지 먼저 확인하려고 했어요. 미납 안내는 이후 전화 뒤 메시지로 ALF 상담과 고객사 데이터 조회를 연결하는 흐름으로 확장했어요.

입금 안내를 위해 콜 캠페인을 제공한 고객은 다음 달에도 다시 사용하고 싶다고 했어요. 한 고객에게 제공한 기능이 다음 고객을 만날 기회를 만들고, 그곳에서 가져온 요구가 다시 기능을 발전시켰어요. 새로운 수요와 반복해서 쓰려는 업무를 함께 확인하면서, 이 기능을 더 넓게 제공할 이유가 쌓였어요.

여러 고객의 요구를 하나의 제품으로

고객이 늘면서 공통으로 필요한 부분과 달라지는 부분이 보였어요. 대량 발신·결과 분석·재발신은 공통이었지만, 입금 안내는 월 단위로 많은 대상에게 보내고 방문 리마인드는 매일 바뀌는 대상에게 보내야 했어요. 고객마다 안내 내용과 전화 이후에 연결할 업무도 달랐고요.

이 경험을 바탕으로 전화·마케팅 제품팀과 제품화 방향을 논의했어요. 반복되는 운영은 공통 기능으로 묶고, 실행 주기와 안내 내용처럼 달라지는 부분은 고객이 어디까지 직접 설정하게 할지 정해야 해요. FDE가 고객별로 맞춰주던 기능을 여러 고객이 스스로 쓸 수 있게 만드는 과정이에요.

현재 콜 캠페인은 베타 테스트 제품으로 고객에게 제공하고 있어요. 기존 고객을 정식 기능으로 옮기는 방법과 늘어나는 사용량을 감당할 구조도 제품팀과 함께 준비해야 해요.

실제 업무 효과를 확인하는 일도 남아 있어요. 통화 기록으로 수신 여부를 알 수는 있지만, 납부나 방문이 늘었는지는 고객사의 데이터와 함께 봐야 해요. 고객이 반복해서 사용하는 이유와 실제로 개선된 결과까지 확인해야, 다음 제품에 무엇을 담을지도 더 분명해질 테니까요.

3. 고객의 문제에서 사업과 제품까지

FDE팀을 만들고 지난 1년 동안, ‘채널톡에서 우리는 어떤 일을 해야 할까’를 계속 고민했어요. 여러 방향을 시도하면서, 고객 가까이에서 아직 제품이 풀지 못한 문제를 해결하고 그 경험을 새로운 사업과 제품으로 이어가는 일에 저희의 역할이 있다는 걸 알게 됐어요.

새 팀의 방향을 찾는 일은 회사에 어떤 기여를 할 수 있는지 하나씩 확인하는 일이기도 했어요. 고객의 문제를 풀며 만들어낸 변화들이 쌓이면서, 우리가 계속해 나갈 일도 선명해지고 있어요.

앞으로도 FDE팀은 고객의 문제에 먼저 뛰어들고, 그 안에서 찾은 가능성을 채널톡의 다음 제품으로 만들어갈 거예요.

We Make a Future Classic Product