01. 지금 운영하는 White label의 구조는 어떠한가?

White label이란?

 White Label(이하 W/L)이란 타사의 제품 또는 서비스를 구매하여 자사 브랜드로 리브랜딩해 판매하는 비즈니스 모델을 뜻한다. 이는 공급업체가 기술, 콘텐츠, 서비스 등을 제공하고, 구매한 기업이 이를 자신의 브랜드로 최종 소비자에게 제공할 수 있도록 허용하는 방식이다.
 일반적으로 고객들은 SaaS 솔루션을 계약하고 사용하지만, Resell, MSP, 또는 사내 조직별 클라우드 관리를 위해 W/L 계약을 맺는 경우도 있다.
 대표적인 사례로 Atlassian을 들 수 있다. Atlassian은 도메인을 등록하고 인증한 뒤, Jira, Confluence 등의 서비스를 선택하도록 구성 페이지를 제공한다. 이 과정 이후 고객 도메인 기반으로 서비스를 사용할 수 있다. 여기서 중요한 것은 도메인 인증으로, Atlassian은 고객에게 필요한 DNS 레코드를 등록하도록 요구한다. 이는 서비스 사용을 위한 레코드, SSL 인증, 발신자 이메일 설정을 포함하며, 이를 통해 W/L 구축의 기반이 마련된다.

초기 구조는 어땠을까?

내가 입사하기 전, W/L은 이미 구축되어 있었으나 다소 기괴한 구조였다. 우리 서비스는 AWS를 기반으로 운영되었고, W/L 구축 할 때마다 새로운 ALB(Application Load Balancer)를 생성해서 해당 주소를 고객 DNS의 CNAME 레코드로 등록하도록 했다.
이 방식은 다음과 같은 문제를 발생시켰다.

1. 비용 증가: ALB가 고객 수만큼 늘어나며 AWS 비용이 크게 증가했다.
2. 관리 복잡성: 모든 ALB에 동일한 Listener를 설정해야 했고, 관리가 어려웠다.
3. 보안 우려: ALB DNS가 일반적인 도메인 형식이 아니어서 고객들이 “보안에 문제가 있지 않냐”는 질문을 자주 했다. 나 또한 고객의 이러한 불만에 공감했다.

개선된 구조

현재는 이러한 비효율을 개선했다.
ALB를 하나로 통합하고, 고객 DNS 레코드의 엔드포인트를 우리 서비스 주소로 변경했다.
예를 들어, 우리의 서비스 도메인이 service.provider.com이고 고객이 customer.com을 소유하고 있다면, 고객은 자신의 DNS에서 service.customer.com의 CNAME 값을 기존 ALB 주소 대신 service.provider.com으로 설정하면 된다.
이 방식은 고객 DNS가 우리의 DNS를 거치도록 만들었지만, ALB를 하나로 줄임으로써 유지보수와 비용 측면에서 큰 개선 효과를 얻을 수 있었다.

해결되지 않은 문제

서브도메인 커스터마이징

W/L 유지보수 과정에서 가장 힘들었던 점은 고객과의 지속적인 커뮤니케이션이었다. 특히 신규 서비스가 출시되면 고객이 이를 사용하기 위해 DNS 등록을 요청받아야 했으며, 서비스마다 서브도메인이 고정값으로 설정되어 있어 커스터마이징 요청이 빈번했다. 예를 들어, 우리는 service.customer.com 형식을 선호했지만, 고객이 app.customer.com을 요구할 경우 ALB Listener 규칙 및 URL 설정을 모두 변경해야 했다. 이는 추가 배포 작업으로 이어졌다. 
 이를 해결하기 위해 Listener를 서브도메인 기반이 아닌 경로 기반 라우팅으로 전환했으나, 기존 레거시 서비스들이 여전히 서브도메인을 사용하고 있어 완전한 전환은 어려운 상황이다.

인프라 자동화 - ACM, ALB

고객이 등록해야 하는 DNS 레코드 중 SSL 인증용 레코드가 있다. 우리 서비스는 AWS 기반이므로 ACM(AWS Certificate Manager)을 활용해 SSL 인증을 처리한다. 이를 통해 고객 도메인에서 HTTPS 요청을 처리할 수 있었다. 하지만 문제가 있었다.
 ACM 인증이 완료되더라도 ALB에 수작업으로 인증서를 등록해야 했다. 이는 비효율적이었으며, SES(Amazon Simple Email Service)와 같은 다른 인프라 자원 생성 후에도 비슷한 후처리 작업이 필요했다.
 현재는 이러한 작업을 자동화하기 위한 프로세스를 개발 중이다.

마치며

W/L 구축 업무를 맡아 매년 약 4건 정도를 처리하다 보니 수작업으로도 충분히 감당 가능했다. 그러나 서비스 규모가 커지면서 이러한 작업량이 크게 늘었다. 이 블로그를 작성하며 지금까지의 변화를 정리해 보았고, 자동화가 필요한 더 많은 영역이 있다는 것을 깨달았다. 현재 초안 개발 중인 자동화 프로세스가 완성되면 이에 대한 내용을 따로 공유할 예정이다.