안녕하세요. 고기를 좋아하는 올리브영 SRE 태극기입니다!
올리브영은 기존에 사용하던 외부 솔루션 기반 온콜 시스템의 한계를 해결하기 위해, 2025년 7월 Amazon SES + Amazon Connect 기반의 서버리스 온콜 시스템으로 전환했습니다.
이 글에서는 그 과정에서의 설계 의도, 시행착오, 그리고 최종적으로 얻어진 안정성과 결과를 공유합니다.

1. 온콜(On-call)은 무엇이며 왜 중요한가

온콜은 장애가 발생했을 때 담당자에게 즉시 연락해 문제가 더 커지기 전에 빠르게 조치할 수 있도록 하는 비상 호출 체계입니다.
특히 대규모 트래픽을 처리하는 플랫폼이나 이벤트 발생 시에는 1분의 지연이 수만 명의 고객 경험에 영향을 주기 때문에, 이 비상 호출의 무게감이 남다릅니다. 이에 장애 발생 시 온콜이 정상적으로 작동해야만 비로소 다음과 같은 가치들을 지켜낼 수 있습니다.

• 장애 조기 감지: 시스템 모니터링이 포착한 신호를 엔지니어의 인지로 즉각 연결합니다.
• SLA 준수 및 고객 영향 최소화: 대응 골든타임을 확보하여 서비스 가용성을 유지합니다.
• 장애 확산 억제: 초기 대응을 통해 국지적 결함이 전체 시스템 마비로 번지는 것을 막습니다.

온콜이 울리지 않는 순간, SRE의 어떤 대응 프로세스도 시작할 수 없습니다. 따라서, 온콜의 신뢰성 자체가 서비스 안정성의 가장 중요한 요소입니다.

2. 기존 온콜 솔루션의 구조적 한계

올리브영은 그동안 외부 온콜 솔루션을 이용해 장애 알림을 운영했습니다. 하지만 다음과 같은 한계가 존재했습니다.

• 해외 번호 발신

  온콜 발신 번호가 해외번호로 표시되면서, 국내 통신사 스팸정책에 의해 전화가 차단되는 사례가 반복되었습니다.
  개발자가 직접 통신사 고객센터에 연락해 국제전화 수신을 요청해야 하는 불편함도 있었습니다.

  

• 발신 실패 발생

  외부 솔루션 이슈로 간헐적으로 발신 실패하는 사례가 발생했습니다.

• 높은 고정 비용

  발신 실패 여부와 관계없이 월 약 200만 원 이상의 솔루션 사용료가 고정적으로 청구되었습니다. 사용량 대비 비용 효율이 떨어지는 구조였습니다.

기존 외부 온콜 솔루션이 가진 제약을 해결하기 위해, '어떻게 하면 더 단순하면서도 확실하게 전화가 울리게 만들 수 있을까?'라는 관점에서 전체 구조를 다시 검토했습니다.
Amazon Connect는 주로 AICC(AI Contact Center, 인공지능 컨택센터) 구축에 활용되는 서비스입니다. 아메리칸 항공에서 고객센터를 Amazon Connect로 전환한 사례처럼, API 기반의 발신 제어와 안정적인 통화 품질을 강점으로 하는 서비스이기도 합니다. 올리브영에서는 이 서비스를 ‘장애 대응 온콜 시스템’이라는 특수한 목적에 맞게 재해석해 적용했습니다. 콜센터 서비스 특유의 안정적인 발신 품질, 고가용성, TTS 연동 능력이 온콜 발신 시스템으로 활용하기에 매우 적합했기 때문입니다.
이제 필요한 것은 '이 발신 엔진을 어떤 방식으로 트리거할 것인가'였습니다. 다양한 장애 알림을 하나의 입력으로 통합하려면 표준화된 단일 채널이 필요했습니다. 이 기준에서 검토한 결과, 가장 신뢰성이 높고 구현이 단순한 방식이 바로 '이메일을 온콜 트리거로 사용하는 구조'였습니다.

3. 온콜 트리거를 이메일로 통합

새로운 온콜 시스템 설계의 핵심 원칙은 가능한 빠르고 확실하게 전화를 울리게 하는 것이었습니다.
이를 위해 이메일(Amazon SES)을 온콜 트리거로 선택했습니다.

Slack, Datadog 등 올리브영이 사용하는 대부분의 모니터링 도구는 '이메일 발신'을 기본 인터페이스로 지원합니다. 따라서 별도의 복잡한 API 연동 없이도 이메일이라는 표준화된 통로를 통해 모든 장애 신호를 하나로 통합할 수 있었습니다.

실제 운영을 통해 확인한 이메일 기반 구조의 강점은 다음과 같습니다.

• 단일 파이프라인: 모든 장애 트리거가 이메일이라는 하나의 채널로 수렴되어 관리가 용이함
• 구조적 단순함: 아키텍처가 직관적이라 유지보수가 쉽고 장애 포인트가 적음
• 검증된 신뢰성: 운영 이후 트리거 누락 없이 안정적으로 동작 중

4. 이메일 기반 아키텍처 설계

이메일을 트리거로 삼기로 결정한 후, 이 신호를 단 한 번의 유실도 없이 Amazon Connect까지 전달할 파이프라인을 설계했습니다. 이 설계의 핵심은 '유연성'과 '안정성'입니다.

핵심 설계 포인트

• 표준화된 통합: Slack 인시던트나 Datadog Alert 등 파편화된 장애 신호를 이메일이라는 공통 표준 인터페이스로 수렴하여 연동 복잡도를 제거
• 관리의 유연성: Google Groups를 브릿지로 활용해, 인프라 코드(IaC) 수정 없이도 팀·스쿼드 단위의 온콜 그룹을 유연하게 운영
• 안정적인 메시지 릴레이: SES(수신) → SNS(팬아웃) → SQS(버퍼링) 구조를 채택하여, 대량 메일이 쏟아지는 상황에서도 메시지 유실을 방지하고 발신 속도를 제어할 수 있는 기반을 마련

이메일에서 온콜 발신까지의 데이터 여정

1. 트리거 발송: 모니터링 도구가 미리 정의된 온콜 전용 이메일 주소로 장애 알림을 발송  
2. 신호 수집(SES): Amazon SES가 이메일을 수신하면, Receipt Rule을 통해 메일 원문을 SNS를 거쳐 SQS에 적재  
3. 데이터 파싱(Lambda): 온콜 발신 Lambda가 SQS에서 메시지를 꺼내 수신 대상자(전화번호)와 안내 음성(TTS) 내용을 정교하게 파싱  
4. 최종 발신(Amazon Connect): 파싱된 정보를 바탕으로 Amazon Connect API를 호출. 이때 Lambda는 SQS 메시지를 초당 4건의 속도로 소비하여 발신량(Rate Limit)을 제어  

즉, 온콜 프로세스는 이메일(Amazon SES) 수신을 출발점으로 삼아, 이후 모든 단계가 서버리스 기반으로 자동 처리됩니다.

이렇게 아키텍처가 정리되면 다음 과제는 '누구에게 전화를 발신해야 하는가'를 정확하게 식별하는 일입니다.
온콜 수신 대상자는 조직 개편, 담당자 변경 등 다양한 이유로 변경이 잦을 수 있기 때문에, 구조적으로 단순하면서도 변경이 쉬운 방식이 필요했습니다. 이에 전화번호를 DB에 저장하고 관리하는 일반적인 방식 대신, '기존 조직 관리 체계(Google Groups)를 그대로 활용하면서도, 별도 DB 없이 동적으로 발신 대상을 식별할 수 없을까?'를 고민했습니다.
그 해답은 Google Groups와 RFC 5233 표준인 '플러스 어드레싱'의 조합에 있었습니다.

5. Google Groups 기반 온콜 대상자 관리

Google Groups를 활용하면 온콜 그룹을 이메일 주소 하나로 관리할 수 있고, 담당자 변경 시 온콜 시스템을 수정하지 않아도 됩니다.

예시는 다음과 같습니다.

sre-oncall@oliveyoung.co.kr
security-oncall@oliveyoung.co.kr
payment-oncall@oliveyoung.co.kr

시스템의 작동 원리는 간단합니다. 장애 트리거 메일이 Google Groups로 발송되면, 해당 메일은 등록된 멤버들의 온콜 전용 주소로 즉시 전달됩니다.

이때 Amazon SES는 유입되는 메일을 Receipt Rule에 의해 SNS를 거쳐 SQS로 전달합니다. 이후 파이프라인의 핵심인 온콜 발신 Lambda가 동작하며, SQS 메시지에서 다음 두 가지 핵심 데이터를 추출합니다.

• 수신 주소: 누가 전화를 받을 것인가? (플러스 어드레싱 기반 식별)
• 이메일 제목: 어떤 내용으로 전화를 걸 것인가? (TTS 음성 변환)

즉, 이메일에 '누구에게, 무엇을' 전달할지에 대한 정보가 모두 담겨 있어, 별도의 DB 조회 없이도 즉각적인 온콜 발신이 가능해집니다.

플러스 어드레싱 기반 대상자 식별 — RFC 5233 Subaddressing 활용

온콜 대상자 식별을 위해 이메일 주소에 플러스 어드레싱(+ Addressing) 방식을 적용했습니다.
이는 RFC 5233에서 정의된 공식 표준(Subaddressing)으로, 이메일 로컬 파트(local-part)에 + 식별자를 추가하는 방식입니다.

실제로 Gmail 등 대부분의 메일 시스템은 'ID+식별자@domain.com' 형태에서 '+' 뒤의 문자열을 무시하고 원래의 'ID 주소'로 메일을 전달합니다. 하지만 이메일 원문에는 이 플러스 어드레스가 그대로 남아있다는 점에 주목했습니다. Amazon SES가 수신한 메일 원문을 SQS로 넘겨주면, Lambda는 복잡한 DB 조회 대신 아주 단순한 정규식만으로 '누구에게 전화를 걸지' 판단합니다.

[데이터 파싱 예시]

- 수신 주소: call+821012345678@oliveyoung.co.kr → 추출 번호: 821012345678
- 메일 제목: [장애] ALB 응답시간 지연 발생 → TTS 내용: ALB 응답시간 지연 발생

이 방식의 장점은 다음과 같습니다.

• 무상태성(Stateless) 유지: 시스템이 전화번호 데이터를 들고 있을 필요가 없어 DB 관리 공수가 0에 수렴
• 즉각적인 확장: 새로운 담당자가 추가되어도 Google Groups에 플러스 어드레싱이 적용된 메일 주소만 등록하면 즉시 온콜 대상에 포함

6. 실제 운영 중 겪은 문제 — 야간 스팸메일로 인한 오발신

완벽하다고 믿었던 시스템도 실제 프로덕션의 변수 앞에서는 예외가 발생했습니다.
내부 테스트 기간 중, 모두가 깊이 잠든 자정 즈음에 느닷없이 온콜 전화가 울렸습니다.

원인은 황당하게도 '광고성 스팸 메일'이었습니다. 수신된 이메일을 모두 온콜로 처리하는 트리거의 치명적인 허점이었습니다. 온콜 전용 주소가 외부로 노출되지 않았더라도, 무작위로 발송되는 스팸 메일은 온콜 트리거를 작동시켰고, Lambda는 스팸메일 제목을 정성스럽게 TTS로 읽어주면서 담당자를 깨웠던 것입니다.

이 사건 이후, 지정한 도메인에서 발신한 이메일만 온콜 트리거로 허용하는 필터링 규칙을 Lambda에 적용하여 문제를 해결했습니다.

최종 해결책: 이메일 화이트리스트(Allow-List) 도입

• 보완 전: 수신된 모든 메일을 온콜 처리
• 보완 후: 이메일의 발신도메인을 체크하여, 허가된 시스템(Datadog, Slack, 올리브영 사내메일)에서 보낸 메일만 온콜 처리

전사 적용 후에 이런 일이 발생했다면, 새벽에 모든 개발자를 온콜로 깨우는 상황이 될 뻔 했습니다. 전사 확산 전, 내부 테스트 기간에 이렇게 매운맛 경험을 한 것이 오히려 천운이었습니다. 덕분에 현재는 단 한 건의 오발신 없는 철벽 방어 시스템을 유지하고 있습니다. (어? 사내메일로 예약메일을 보내면 모닝콜 대신 쓸 수 있는 건 비밀입니다.)

이메일 기반 온콜 흐름에서 발생할 수 있는 문제들을 해결한 이후, 실제 대규모 발신 테스트를 통해 Amazon Connect의 제약 사항도 확인할 수 있었습니다.

7. Amazon Connect 도입 직후 발견된 Rate Limit 제약

숨겨진 제약: Amazon Connect의 동시 발신 제한

위와 같이 이메일 기반 온콜 흐름에서 발생할 수 있는 문제들을 해결한 이후, 실제 대규모 발신 테스트를 통해 Amazon Connect의 제약 사항도 확인할 수 있었습니다. 온콜 테스트를 위해 약 50여 명에게 동시에 발신을 시도하자, 예상치 못한 상황이 발생한 것인데요, 일부 인원에게 전화가 가지 않는 '발신 누락'이 확인되었습니다. 원인은 Amazon Connect의 초당 호출 제한(Rate Limit)이었습니다. 확인해보니 StartOutboundVoiceContact API를 짧은 시간에 집중적으로 호출할 경우, Quota 초과로 호출이 거절된 것이었습니다. 수십 명에게 즉시 전화를 걸어야 하는 온콜 시스템에는 턱없이 부족한 수치였습니다.

해결 과정: Quota 증설과 안정성 확보

올리브영 담당 AWS TAM(Technical Account Manager)에 서비스 할당량 증설을 요청했고, 약 2주간의 검토를 거쳐 초당 5회까지 발신 가능하도록 증설을 마쳤습니다. 하지만 여기서 그치지 않았습니다. 인프라의 한계치까지 사용하는 것은 위험하다고 판단하여, 실제 운영 시에는 안전 마진을 둔 초당 4회로 발신 속도를 제어하기로 결정했습니다.

8. SQS 기반 발신 속도 제어 구조로 문제 해결

발신 속도를 안정적으로 제어하기 위해 SQS를 도입하여 아키텍처를 재설계했습니다.

개선된 아키텍처

• SQS 지연 처리: 대량의 메일이 쏟아지더라도 SQS가 이를 안전하게 보관하며 버퍼 역할을 수행합니다.
• Lambda 동시성 제어: Lambda의 Reserved concurrency 값을 4로 설정하여, Amazon Connect API 호출이 초당 4건을 넘지 않도록 정교하게 제어했습니다.
• 관측성 확보: 모든 발신 성공/실패 로그를 Datadog으로 전송하여, 실제 전화가 몇 초 만에 도달했는지 대시보드에서 실시간으로 확인할 수 있게 구성했습니다.
  
  

테스트 결과: 46명에게 17초 만에 도달

재설계된 구조로 대규모 발신 테스트를 진행한 결과, 단 한 건의 누락도 발생하지 않았습니다.

• 성능: 46명 전원 발신 완료까지 약 17초 소요 (초당 4건 목표치 준수)
• 안정성: API Throttling 에러 발생률 0%

9. 전화 + SMS 이중화

온콜이 안정적으로 작동하자, 실제 온콜을 받는 개발팀으로부터 실무적인 피드백이 도착했습니다.

이에 Amazon SNS를 활용한 SMS 발신 기능을 추가하여 알림 이중화를 구현했습니다.

알림 레이어의 확장

기존 Lambda에 Amazon SNS 연동을 추가하여, 단일 트리거로 두 가지 경로의 알림이 동시에 발생하도록 개선했습니다.

• 1단계 Voice: Amazon Connect를 통해 긴급 상황임을 알리는 전화 발신 (즉각적 대응 유도)
• 2단계 Text: 동일한 TTS 안내 내용을 SMS로 즉시 전송 (기록성 및 가독성 확보)

이제 담당자가 전화를 받지 못하더라도, 뒤이어 도착한 SMS를 통해 장애의 맥락을 즉시 파악하고 조치에 들어갈 수 있게 되었습니다.
'전화'가 대응의 시작을 알린다면, 'SMS'는 대응의 정확도를 높이는 역할을 수행하게 된 것입니다.

10. 고정 비용 최적화

기존 외부 솔루션은 발신 건수와 관계없이 고정비용으로 월 200만 원 이상을 지출하고 있었습니다.
하지만 Amazon SES + Amazon Connect 기반 서버리스 구조로, 전환하며 운영 비용을 월 10만원 이하(약 95% 이상 절감)로 조정할 수 있었습니다.

구분	기존 외부 온콜 솔루션	Olive Connect (신규 서비스)	비고
과금 방식	구독형 고정 비용	사용량 기반 과금	-
월 예상 비용	약 2,000,000원 + α	약 100,000원 미만	약 95% 절감
주요 과금 항목	유저당 라이선스, 플랫폼 사용료	Amazon Connect 발신 비용, Lambda 호출 비용 등	-
발신 안정성	해외 번호 발신 (스팸 차단 위험)	국내 번호 발신 및 서버리스로 안정성 높음	안정성 향상

11. 최종 온콜 아키텍처

아래는 현재 운영 중인 온콜 시스템 구성도입니다.

12. 사내 전파와 안착 — 개발자 포털(IDP)을 통한 운영 가이드 제공

온콜 시스템이 안정적으로 운영되기 시작하면서, 다음 과제는 '이 시스템을 어떻게 조직 전체에 안전하게 확산시키고, 오래 유지할 것인가'였습니다. 아무리 잘 만든 시스템이라도 사용 방법이 명확하지 않거나, 담당자 변경 시 지식이 단절되는 구조라면 문제가 됩니다. 시간이 지나면 결국 또 다른 운영 리스크로 되돌아오기 마련입니다.

이를 방지하기 위해, 온콜 시스템의 설계 배경, 사용 방법을 정리한 가이드 문서를 작성했고, 이를 사내 IDP(Internal Developer Portal)에 배포했습니다.

가이드에는 다음과 같은 내용을 포함했습니다.

• 온콜 시스템 전체 아키텍처 개요
• 신규 서비스 온콜 연동 방법 (이메일 트리거 설정 가이드)
• Google Groups 기반 온콜 그룹 관리 방법

이제 새로운 서비스에 온콜을 도입할 때, 별도의 설명이나 인프라 지원 없이도 가이드 문서만으로 셀프 적용이 가능한 구조가 되었습니다. 기술적인 완성도뿐 아니라, 운영과 전파까지 고려한 문서화는 이 온콜 시스템을 '특정 팀의 도구'가 아닌 조직의 공통 인프라 자산으로 만드는 데 중요한 역할을 했습니다.

마무리

현재 Amazon Connect는 Amazon Polly TTS 서비스로 장애 정보를 온콜로 전달하고 있습니다. 하지만 긴박한 장애 상황에서 기계적인 한국어 발음은 때때로 정보 전달력을 떨어뜨리기도 합니다.
이에 다음 단계로 음성 사용자 경험(VUX)을 고도화할 계획입니다. 네이버 클로바 더빙이나 Typecast 같은 외부 AI TTS 솔루션을 연동하여, 마치 동료가 직접 전화를 걸어 상황을 설명해 주는 듯한 자연스러운 음성 안내를 구현하고자 합니다. 단순히 '듣기 좋은 목소리'를 넘어, 장애 대응 중인 엔지니어의 인지 부하를 줄이고, 상황 파악 속도를 높이는 데 기여할 것입니다.

그리고, 이메일 기반 온콜이라는 단순한 접근 방식은 예상보다 훨씬 강력했습니다.

• 신뢰성: 복잡한 연동 없이 이메일 표준을 활용해 발신 실패율 0% 달성
• 완결성: 전화와 SMS 이중화를 통한 장애 전파 누락 방지
• 유연성: 별도 DB 없이 Google Groups만으로 온콜 그룹 관리 자동화
• 효율성: 운영 리소스와 비용(95% 절감)의 획기적 최적화

무엇보다, 가장 단순한 구조가 가장 안정적인 구조가 될 수 있다는 경험을 얻었습니다.

온콜은 단순한 전화 발신 기능을 넘어, 장애 상황과 엔지니어의 대응 사이의 간극을 메우는 '서비스 신뢰성의 마지막 1cm'입니다. 이 짧은 간극을 어떻게 채우느냐에 따라 고객이 경험하는 서비스의 안정성이 결정됩니다.
올리브영 SRE팀은 앞으로도 복잡하게 얽힌 문제들을 가장 명쾌하고 단순한 기술로 풀어내며, 고객이 믿고 머무를 수 있는 탄탄한 플랫폼을 만들어 나갈 것입니다. '단순함으로 구현한 견고한 신뢰'에 대한 저희의 또 다른 도전과 해결 사례들도 계속해서 기대해 주세요.