AWS 서버리스 CDC 파이프라인 만들기 — DynamoDB 스트림·Lambda·SNS 구조 정리

핵심 메시지

• 결제 처리 코드가 이메일 발송·재고 갱신까지 모두 떠안으면 화면이 멈추고, 기능을 추가할 때마다 가장 건드리기 싫은 결제 코드를 계속 수정해야 한다.
• 해법은 역할을 뒤집는 것이다. 서버는 주문 저장과 즉시 성공 응답만 하고, 데이터베이스가 '변경이 일어났다'고 스스로 알리면 뒤에서 작업들이 각자 실행된다.
• 핵심은 DynamoDB 스트림이다. 테이블의 모든 삽입·수정·삭제가 순서대로 이벤트로 잡히고, 폴링 없이 변경 순간 바로 밀려 나온다.
• 주문을 쓰는 인제스트 Lambda와 스트림을 듣는 프로세서 Lambda를 분리하고, 각각 최소 권한의 IAM 역할을 부여해 보안 경계를 만든다.

쉽게 이해하기

온라인에서 주문 버튼을 누르면 화면은 곧바로 넘어가고 몇 초 뒤 확인 메일이 도착한다. 이 순간 뒤에 있는 장치가 바로 변경 데이터 캡처(CDC, Change Data Capture) 파이프라인이다. 영상은 이를 AWS에서 서버리스로 끝까지 구현하며, 마지막에는 curl 명령 한 번으로 주문을 넣고 코드에 아무런 발송 로직 없이 실제 메일이 도착하는 것을 보여 준다.

문제는 결제 처리 서버가 주문 저장, 배송팀 알림, 확인 메일, 재고 갱신을 한꺼번에 처리하려 할 때 생긴다. 고객은 필요 없는 메일을 기다리며 멈춘 화면을 보게 되고, 나중에 기능을 하나 추가할 때마다 가장 건드리고 싶지 않은 결제 코드를 손봐야 한다. 그래서 발상을 뒤집는다. 서버는 '주문을 저장하고 즉시 성공을 응답한다'는 한 가지 일만 하고, 나머지는 데이터베이스가 변경을 알리면 백그라운드에서 몇 초 안에 각자 실행되게 한다.

모든 것은 하나의 구성 요소에서 시작한다. 주문을 저장하면서 변경 사실을 즉시 알려 줄 수 있는 저장소, 곧 DynamoDB다. 주문 ID를 키로 하는 온디맨드 모드 테이블을 만들면 트래픽에 따라 확장되고 한가할 때는 비용이 들지 않는다. 여기서 DynamoDB 스트림을 켜는 것이 이 설계의 핵심이다. 스트림을 켜면 테이블의 모든 삽입·수정·삭제가 변경 전후 값과 함께 순서대로 이벤트로 기록된다. 테이블에 '새 게 있냐'고 계속 물어보는 폴링 대신, 변경이 일어나는 순간 테이블이 직접 변경을 밀어내며 데이터베이스가 곧 이벤트의 원천이 된다.

테이블을 중심으로 두 개의 반쪽을 만든다. 앞쪽에는 들어온 주문을 테이블에 기록하는 인제스트 Lambda가 있다. 이 함수의 일은 일부러 작게 잡는다. 주문을 읽어 테이블에 넣고 곧바로 '주문이 접수됐다'고 답할 뿐, 메일을 보내거나 기다리지 않는다. 함수를 외부에서 부를 수 있도록 앞에 API 게이트웨이를 두어 POST /order 경로 하나를 연다. 공개 엔드포인트인 만큼 모든 요청에 API 키를 요구하고, 초당 50건·하루 1,000건으로 제한하는 사용 계획을 걸어 한 클라이언트가 요금을 폭증시키거나 파이프라인을 무너뜨리지 못하게 한다.

뒤쪽에는 변경을 듣는 프로세서 Lambda가 스트림에 연결된다. 이 함수는 우리가 직접 호출하지 않는다. 새 주문이 들어오면 DynamoDB 스트림이 자동으로 트리거하고, 함수는 변경 내용에서 주문 정보를 꺼내 Amazon SNS 토픽으로 알림을 발행한다. SNS는 그 메시지를 구독자 모두에게 뿌리는데, 오늘은 이메일이지만 내일은 같은 토픽에 문자나 창고 큐를 구독시키기만 하면 주문 코드는 그대로 둔 채 채널을 늘릴 수 있다. 두 함수는 각각 별도의 IAM 역할을 갖는다. 인제스트는 테이블 쓰기만, 프로세서는 스트림 읽기와 SNS 발행만 할 수 있어, 하나가 뚫려도 다른 하나의 일은 하지 못한다. 그 밑에서는 모든 함수가 CloudWatch에 로그를 남겨 문제가 생겼을 때 한곳에서 확인할 수 있다.

주요 인사이트

• '데이터베이스를 이벤트 원천으로 삼는다'가 이 설계의 핵심이다. 스트림을 켜면 폴링 없이 변경 순간에 후속 작업이 시작된다.
• 결제(체크아웃)는 누가 그 변경을 듣고 있는지 알 필요가 없다. 관심사가 분리되어 새 기능을 붙일 때 결제 코드를 수정하지 않아도 된다.
• SNS의 팬아웃 구조 덕분에 이메일·문자·큐 등 알림 채널을 주문 코드 변경 없이 구독만으로 확장할 수 있다.
• 두 함수에 최소 권한 IAM 역할을 각각 부여하는 것은 선택적 정리가 아니라 보안 경계 그 자체다. 하나가 침해돼도 다른 역할의 작업은 막힌다.
• 온디맨드 DynamoDB와 서버리스 구성 덕분에 트래픽에 맞춰 확장되면서도 유휴 시 비용 부담이 작다.

자주 묻는 질문

관련 AI 소식