헬프데스크를 클라우드플레어 위에 통째로 올렸어요
고객 문의를 받고, 티켓으로 만들고, 담당자를 배정하고, 답변하고, 상태를 관리하는 소프트웨어를 '헬프데스크'라고 해요. 젠데스크(Zendesk)나 프레시데스크(Freshdesk)가 대표적이죠. 그런데 이런 헬프데스크를 전통적인 서버 없이, 오로지 클라우드플레어의 서버리스 스택만으로 만든 오픈소스 프로젝트가 나왔어요. 이름은 ResolveHQ이고, GitHub에 공개돼 있어요.
이게 왜 흥미롭냐면, '서버리스로 실제 업무용 애플리케이션을 끝까지 만들 수 있느냐'는 질문에 대한 하나의 답이기 때문이에요. 서버리스 함수로 간단한 API 하나 만드는 건 누구나 해봤을 거예요. 하지만 데이터베이스, 파일 저장, 백그라운드 작업까지 다 붙여서 사람들이 매일 쓰는 도구를 완성하는 건 전혀 다른 이야기거든요.
어떤 부품으로 만들었나
ResolveHQ가 쓴 클라우드플레어 서비스를 하나씩 풀어볼게요.
Workers는 클라우드플레어의 서버리스 실행 환경이에요. 전 세계 수백 개 데이터센터에 코드를 배포해서, 사용자와 가장 가까운 곳에서 자바스크립트나 타입스크립트 코드가 실행돼요. AWS Lambda와 비슷하지만, 컨테이너 대신 V8 격리 환경(브라우저 탭 하나 같은 가벼운 샌드박스)을 써서 콜드 스타트가 거의 없다는 게 특징이에요. ResolveHQ의 API와 웹 UI 서빙이 모두 여기서 돌아가요.
D1은 클라우드플레어의 서버리스 관계형 데이터베이스예요. 내부적으로 SQLite를 쓰고, SQL로 쿼리해요. 티켓, 고객, 담당자, 댓글 같은 구조화된 데이터가 여기 저장돼요. 이게 뭐냐면, 서버 한 대 띄우고 MySQL 설치할 필요 없이 '데이터베이스 하나 주세요' 하면 바로 생기는 SQLite라고 보면 돼요. 단, 일반 RDB처럼 무한히 큰 데이터베이스는 아니고 크기 제한이 있어서, 규모가 커지면 설계를 고민해야 해요.
R2는 S3 호환 오브젝트 스토리지예요. 고객이 티켓에 첨부한 스크린샷이나 로그 파일 같은 것들이 여기 저장돼요. R2의 가장 큰 장점은 이그레스(데이터 전송) 비용이 없다는 거예요. AWS S3는 데이터를 꺼내 갈 때마다 돈을 받는데, R2는 그게 공짜예요. 첨부파일을 자주 내려받는 헬프데스크 특성상 이건 꽤 큰 차이예요.
Queues는 메시지 큐예요. '지금 당장 안 해도 되는 일'을 나중에 처리하도록 대기열에 넣는 장치죠. 헬프데스크에서는 알림 이메일 발송, 자동 배정 규칙 실행, SLA(응답 시간 약속) 타이머 체크 같은 작업이 여기에 해당해요. 사용자가 티켓을 만들었을 때 응답은 바로 돌려주고, 알림 발송은 큐에 넣어 뒤에서 처리하는 식이에요. 이렇게 하면 요청 처리 시간이 짧아지고, 이메일 서버가 잠깐 느려져도 사용자 경험에는 영향이 없어요.
여기에 클라우드플레어의 Email Workers(수신 이메일을 코드로 처리하는 기능)를 붙이면, support@회사.com으로 온 메일이 자동으로 티켓이 되는 흐름도 만들 수 있어요. 헬프데스크의 가장 핵심적인 진입점이죠.
정리하면 흐름은 이래요. 고객이 문의를 보내면 Worker가 받아서 D1에 티켓을 만들고, 첨부파일은 R2에 올리고, 후속 작업은 Queues에 던져요. 담당자는 Worker가 서빙하는 웹 UI에서 티켓을 보고 답변하고요. 이 모든 게 '서버'라는 걸 한 대도 띄우지 않고 돌아가요.
업계 맥락: 헬프데스크와 서버리스 풀스택
헬프데스크 시장은 젠데스크, 프레시데스크, 인터콤, 헬프스카우트 같은 SaaS가 장악하고 있어요. 좋은 제품들이지만 사용자당 월 요금이 쌓이면 소규모 팀에는 부담이 되죠. 오픈소스 쪽에는 Zammad, osTicket, FreeScout, Chatwoot 같은 대안이 있어요. 하지만 이들은 전부 '서버에 설치하는' 방식이라, 결국 누군가 VM을 관리하고 백업하고 업데이트해야 해요.
ResolveHQ는 그 사이 빈 곳을 노려요. 오픈소스라서 코드를 통제할 수 있고, 서버리스라서 관리할 서버가 없고, 클라우드플레어 무료 티어가 넉넉해서 소규모라면 비용이 거의 안 들어요. 이런 '클라우드플레어 풀스택' 접근은 최근 몇 년간 빠르게 늘고 있어요. Hono 같은 경량 웹 프레임워크가 Workers 환경에서 표준처럼 자리 잡았고, Durable Objects(상태를 가진 서버리스 객체)와 Workers AI까지 더해지면서 '클라우드플레어만으로 다 만든다'는 게 현실적인 선택지가 됐거든요.
물론 트레이드오프도 분명해요. 클라우드플레어에 강하게 종속된다는 점(벤더 락인), D1의 크기와 성능 한계, Workers의 CPU 시간 제한, 그리고 복잡한 트랜잭션이나 장시간 작업을 다루기 어렵다는 점이에요. 대형 조직의 헬프데스크보다는 스타트업이나 사이드 프로젝트, 소규모 팀에 맞는 선택이에요.
한국 개발자에게 주는 시사점
첫째, 참고 아키텍처로서의 가치예요. 클라우드플레어 스택으로 뭔가 만들고 싶은데 D1, R2, Queues를 어떻게 조합하는지 감이 안 온다면, 이 프로젝트의 코드를 읽는 게 문서 열 페이지보다 나아요. 특히 Queues로 비동기 작업을 분리하는 패턴과 첨부파일을 R2에 저장하고 서빙하는 패턴은 다른 프로젝트에도 그대로 가져다 쓸 수 있어요.
둘째, 소규모 팀의 실제 도구로요. 국내 스타트업이나 인디 개발자 중에 젠데스크 비용이 아까워서 노션이나 슬랙으로 고객 문의를 관리하는 경우가 많잖아요. 이런 팀이라면 클라우드플레어 계정 하나에 배포해서 거의 무료로 쓸 수 있는 헬프데스크는 충분히 매력적이에요. 다만 한국어 UI나 카카오톡 채널 연동 같은 건 직접 붙여야겠죠.
셋째, 서버리스 설계 감각을 기르는 교재로요. '이 작업은 요청 안에서 처리할까, 큐로 보낼까', '이 데이터는 D1에 넣을까, R2에 넣을까' 같은 판단은 서버리스 설계의 핵심인데, 헬프데스크는 이런 판단이 골고루 등장하는 좋은 예제예요.
새로 공개된 프로젝트라 성숙도는 아직 검증이 필요해요. 프로덕션에 바로 쓰기보다는 코드를 읽고, 필요하면 포크해서 우리 팀에 맞게 고쳐 쓰는 걸 추천해요.
정리
한 줄로 정리하면, 클라우드플레어의 서버리스 부품들만으로 실제 업무용 헬프데스크를 완성할 수 있다는 걸 보여준 오픈소스 프로젝트예요.
여러분 팀은 고객 문의를 어떻게 관리하고 계세요? 그리고 서버리스 풀스택으로 '진짜 제품'을 만드는 것에 대해 어떻게 생각하시나요? 벤더 락인을 감수할 만한 가치가 있을까요?
🔗 출처: Hacker News