Day 2 - 애플리케이션 통합: 시스템을 느슨하게 연결하기

왜 직접 연결하면 안 되는가: 결합도 이야기

시스템과 시스템이 "어떻게 서로 이야기를 주고받느냐"의 문제다. 작은 앱은 함수가 함수를 직접 호출하면 되지만, 주문·결제·알림 시스템이 따로 있는 큰 서비스에서는 이야기가 달라진다.

• 주문 서비스가 결제 서비스를 직접 호출(동기 호출)하면, 결제가 잠깐 느려지거나 죽을 때 주문도 응답을 기다리다 같이 멈춘다. 강하게 묶여 있는(tightly coupled) 상태다.
• 대신 주문 서비스가 "주문 들어왔어"라는 메시지를 중간 큐에 던져두고, 결제 서비스가 준비되면 꺼내 처리한다면?
  • 결제가 잠깐 죽어도 메시지는 큐에 안전하게 쌓여 있다.
  • 주문은 영향을 받지 않는다.
• 이것이 느슨한 결합(loose coupling)이며, 오늘 볼 세 서비스(SQS, SNS, EventBridge)가 모두 이를 위한 도구다.

느슨한 결합은 Well-Architected Framework의 Reliability(안정성) 기둥의 핵심 원칙이다. 컴포넌트 하나의 장애가 전체로 번지지 않게 하려면, 직접 호출 대신 메시지/이벤트로 중간을 끊어줘야 한다.

[강한 결합]  주문 ──직접 호출──▶ 결제   (결제 죽으면 주문도 멈춤)

[느슨한 결합] 주문 ──메시지──▶ [큐] ──▶ 결제  (결제 죽어도 큐에 보관)

온라인 티켓 판매 사이트에서 인기 공연 예매가 열린 순간을 상상해 본다. 1분에 수만 명이 몰린다. 이 사이트는 주문을 받으면 곧바로 결제 시스템을 호출하고, 결제가 끝나야 "예매 완료" 화면을 띄우도록 만들어져 있다. 그런데 결제사 서버가 트래픽을 못 견디고 응답이 느려지기 시작한다. 그러면 무슨 일이 벌어질까? 주문 서버는 결제사의 답을 기다리며 붙잡혀 있고, 기다리는 요청이 쌓이면서 주문 서버까지 멈춘다. 결제 하나가 느려졌을 뿐인데 사이트 전체가 죽는다. 화면에는 "잠시 후 다시 시도해 주세요"만 뜨고, 그 사이 들어온 주문은 흔적도 없이 사라진다.

같은 사이트를 큐로 바꿔 본다. 주문 서버는 "이 사람이 이 좌석을 샀다"는 메시지를 큐에 던지고 즉시 "접수되었습니다" 화면을 보여 준다. 결제 시스템은 자기 속도로 큐에서 하나씩 꺼내 처리한다. 결제사가 느려져도 주문은 계속 받을 수 있고, 메시지는 큐에 안전하게 남아 있다가 결제사가 회복되면 처리된다. 바뀐 것은 코드 몇 줄이 아니라 시스템이 무너지는 방식 그 자체다.

동기와 비동기: 전화와 문자메시지

느슨한 결합을 이해하려면 동기(synchronous)와 비동기(asynchronous)를 먼저 구분해야 한다. 어려운 말 같지만 우리가 매일 쓰는 두 가지 연락 방식과 똑같다.

동기는 전화다. 상대가 받아야 이야기가 시작된다. 상대가 자리에 없으면 통화 자체가 성립하지 않고, 내가 전화기를 붙들고 있는 동안에는 다른 일을 못 한다. 대신 답을 즉시 얻는다.

비동기는 문자메시지다. 나는 보내고 내 일을 계속한다. 상대는 여유가 될 때 확인하고 답한다. 상대가 회의 중이어도 메시지는 사라지지 않는다. 대신 즉답은 못 받는다.

오늘 보는 세 서비스(SQS, SNS, EventBridge)는 전부 비동기 쪽 도구다. 시스템 사이의 대화를 전화에서 문자로 바꿔 주는 장치라고 생각하면 정확하다.

⚠️ 함정: 비동기가 무조건 좋은 것은 아니다. "카드 승인이 됐는지 지금 화면에 보여 줘야 한다"처럼 즉시 답이 필요한 곳까지 큐로 바꾸면 오히려 사용자 경험이 나빠진다. 느슨한 결합은 "지금 당장 답을 받지 않아도 되는 일"을 골라내는 판단이 먼저다.

Amazon SQS: 메시지를 안전하게 쌓아두는 큐

• Amazon SQS(Simple Queue Service)는 완전 관리형 메시지 큐다.
• 한쪽(생산자, producer)이 메시지를 큐에 넣으면, 다른 쪽(소비자, consumer)이 준비될 때 꺼내서 처리한다.
• 핵심은 1:1 전달과 버퍼링이다.
  • 생산자와 소비자가 같은 시각에 살아 있을 필요가 없다(비동기).
  • 트래픽이 몰리면 큐에 쌓아두고 소비자가 자기 속도로 처리한다(완충/버퍼).
  • 메시지는 소비자가 처리 완료를 알릴 때까지 보관되어 유실되지 않는다.
• 대표 비유는 카페의 주문 대기열 — 손님이 몰려도 주문서는 줄을 서고, 바리스타는 하나씩 차근차근 처리한다.

큐가 트래픽 급증을 견디는 방식: 댐과 수문

SQS의 진짜 가치는 "메시지를 보관한다"보다 "들어오는 속도와 처리하는 속도를 분리한다"는 데 있다. 큰비가 오면 강물이 순식간에 불어나지만, 중간에 댐이 있으면 하류로는 일정한 양만 흘려보낼 수 있다. 큐가 바로 그 댐이다.

[큐가 없을 때]   요청 1만 건 ───▶ 처리 서버 (동시에 1만 건? → 터진다)

[큐가 있을 때]   요청 1만 건 ──▶ [큐: 1만 건 대기] ──▶ 처리 서버
                                                   (초당 200건씩 차근차근)

이 구조 덕분에 뒤쪽 시스템은 평소 규모 그대로 두어도 된다. 트래픽이 몇 배로 뛰는 몇 분을 위해 서버를 열 배로 늘려 놓을 필요가 없다는 뜻이고, 이는 곧 비용 절감이기도 하다.

표준 큐와 FIFO 큐

SQS에는 성격이 다른 두 종류의 큐가 있다. 이름만 알아 두면 충분하지만, 구분 자체는 시험에 나온다.

FIFO는 "First In, First Out" — 먼저 들어온 것이 먼저 나간다는 뜻이고, 은행 창구의 번호표와 같다. 은행 업무 처리나 재고 차감처럼 순서가 뒤바뀌면 결과가 달라지는 일에는 FIFO를, 이미지 변환이나 알림 발송처럼 순서가 상관없고 양이 많은 일에는 표준 큐를 쓴다.

"메시지를 잃어버리면 안 된다", "트래픽 급증을 완충하라", "작업을 큐에 쌓아 순차 처리"라는 키워드가 보이면 SQS다. 한 메시지는 보통 하나의 소비자가 가져가 처리한다는 점이 SNS와의 결정적 차이다.

⚠️ 함정: SQS는 소비자에게 메시지를 밀어주지 않는다. 소비자가 "새 거 있나요?"라고 물어봐야(폴링) 가져간다. 그래서 "이벤트가 생기는 즉시 여러 시스템에 알려야 한다"는 시나리오에 SQS를 고르면 오답이 되기 쉽다. 그건 SNS의 일이다.

Amazon SNS: 한 메시지를 여러 곳에 동시에 알리기

• Amazon SNS(Simple Notification Service)는 발행/구독(pub/sub) 방식의 알림 서비스다.
• 발행자가 하나의 주제(topic)에 메시지를 한 번 보내면, 그 주제를 구독한 여러 대상에게 동시에 전달된다(1:다, 팬아웃).
• 구독자가 될 수 있는 대상: 이메일, SMS, HTTP 엔드포인트, Lambda 함수, SQS 큐.
• 예: "주문 완료" 메시지 하나로 고객 이메일 발송 + 분석 시스템 기록 + 배송 시스템 기동을 동시에 처리.

SNS를 그림으로 보면 이렇다. 발행자는 구독자가 몇 명인지, 누구인지 전혀 몰라도 된다. 그냥 주제에 한 번 던질 뿐이다.

                        ┌──▶ 이메일 발송
                        │
발행자 ──▶ [SNS 주제] ──┼──▶ Lambda(분석 기록)
 (주문 서비스)           │
                        └──▶ SQS 큐(배송 처리)

이것이 회사 게시판이나 단체 공지 채널과 같은 구조다. 공지를 올리는 사람은 누가 읽는지 신경 쓰지 않고, 나중에 읽는 사람이 늘어도 올리는 방식은 바뀌지 않는다. 새 시스템을 하나 더 붙이고 싶을 때 발행자 코드를 고칠 필요가 없다는 것이 팬아웃의 진짜 이점이다.

실무 패턴: SNS + SQS 팬아웃

SNS만 쓰면 한 가지 아쉬운 점이 있다. 구독자 중 하나가 잠깐 죽어 있으면 그 알림을 놓칠 수 있다는 것이다. 그래서 실무에서는 SNS 주제에 SQS 큐들을 구독시키는 조합을 자주 쓴다.

                        ┌──▶ [SQS 큐 A] ──▶ 배송 시스템
발행자 ──▶ [SNS 주제] ──┤
                        └──▶ [SQS 큐 B] ──▶ 정산 시스템

이렇게 하면 한 번 발행으로 여러 곳에 퍼뜨리면서(SNS), 각 시스템은 자기 큐에 안전하게 쌓아 두고 자기 속도로 처리(SQS)할 수 있다. 배송 시스템이 잠시 멈춰도 큐 A에 메시지가 남아 있고, 정산 시스템은 아무 영향 없이 계속 돈다. 두 서비스의 장점만 취한 구성이라 CLF에서도 이름 정도는 등장한다.

"하나의 이벤트를 여러 시스템에 동시에 알려라", "이메일/SMS 알림", "팬아웃(fan-out)"이 보이면 SNS다. 실무에서는 SNS + SQS 조합(SNS 주제에 여러 SQS 큐를 구독시켜 팬아웃하면서도 각 큐는 안전하게 버퍼링)을 자주 쓴다.

음식 배달 앱에서 "주문 접수" 하나가 일어나면 뒤에서 벌어져야 할 일은 한둘이 아니다. 고객에게 알림을 보내고, 가게 태블릿에 주문서를 띄우고, 라이더 배차를 시작하고, 매출 데이터에 기록해야 한다. 이걸 주문 서비스가 네 곳을 차례로 직접 호출하도록 만들면, 넷 중 하나만 느려져도 주문 전체가 지연되고, 나중에 "쿠폰 정산"이라는 다섯 번째 일이 추가될 때마다 주문 코드를 고쳐야 한다. SNS 주제 하나에 발행하고 각 시스템이 구독하게 바꾸면, 주문 서비스는 "주문 접수됨"만 외치면 되고 나머지는 각자 알아서 반응한다.

Amazon EventBridge: 이벤트 기반으로 흐름을 잇기

• Amazon EventBridge는 이벤트 버스(event bus) 서비스다.
• AWS 서비스들, 우리 앱, 외부 SaaS(예: Zendesk, Datadog)에서 발생한 이벤트를 받아 규칙(rule)에 따라 적절한 대상으로 라우팅한다.
• SNS와 비슷해 보이지만, EventBridge는 이벤트의 내용을 보고 필터링·라우팅하는 데 강하다.
  • "S3에 특정 폴더로 파일이 올라오면 → 이 Lambda를 실행"
  • "EC2 상태가 변하면 → 이 알림을 보내라"
  • 이런 조건부 흐름을 코드 없이 규칙으로 구성한다.
• 정해진 시간마다 작업을 실행하는 스케줄(cron) 기능도 제공한다.

[다양한 이벤트 소스]            [EventBridge 규칙]         [대상]
 AWS 서비스 ──┐                  내용 필터 + 라우팅          Lambda
 내 앱       ──┼──▶ [이벤트 버스] ──────────────▶          SQS/SNS
 SaaS 앱     ──┘                                            Step Functions ...

SNS와 EventBridge는 뭐가 다른가

둘 다 "한 곳에서 발행하면 여러 곳이 받는다"는 점이 비슷해서 가장 많이 헷갈린다. 차이는 누가 걸러 내느냐에 있다.

SNS는 확성기다. 주제에 대고 외치면 그 주제를 구독한 모두가 같은 내용을 받는다. 무엇을 받을지는 구독하는 쪽이 정한다.

EventBridge는 우편물 분류실이다. 온갖 곳에서 들어온 이벤트를 열어 보고, "발신자가 S3이고 폴더가 /invoices인 것만 이 Lambda로" 같은 규칙에 따라 골라서 보낸다. 게다가 AWS 서비스들이 스스로 만들어 내는 이벤트(인스턴스 상태 변경, 빌드 완료 등)와 외부 SaaS의 이벤트까지 받아 준다.

"AWS 서비스 상태 변화에 반응", "SaaS 이벤트 연동", "이벤트 내용으로 조건부 라우팅", "정해진 시간에 자동 실행"이 보이면 EventBridge다. 이벤트 기반 아키텍처(event-driven architecture)를 코드 없이 구성하게 해주는 접착제 역할이다.

한 줄만 더: AWS Step Functions

통합 서비스 이야기가 나오면 AWS Step Functions도 한 번쯤 언급된다. 여러 단계를 순서대로, 조건에 따라, 실패하면 다시 시도하도록 작업의 흐름(워크플로)을 그림처럼 정의해 실행하는 서비스다. "1단계 이미지 검사 → 2단계 승인 → 3단계 게시, 중간에 실패하면 되돌리기" 같은 절차를 코드가 아니라 흐름도로 관리한다고 생각하면 된다. CLF 수준에서는 "여러 단계를 조율(오케스트레이션)하는 서비스" 한 줄이면 충분하다.

셋을 한 장으로 구분하기

• CLF에서는 깊은 설정이 아니라 이 세 줄짜리 정체성으로 시나리오를 가르는 능력을 묻는다.
  • "여러 명에게 알린다" → SNS
  • "작업을 안전하게 쌓아 처리한다" → SQS
  • "이벤트에 반응해 흐름을 잇는다" → EventBridge
• 셋의 공통 목표는 하나다 — 컴포넌트끼리 직접 묶이지 않게 해서, 하나가 흔들려도 전체가 버티게 만드는 것.

헷갈리는 짝 정리

통합 서비스 키워드 매핑표

잘 만든 시스템은 부품이 고장 나지 않는 시스템이 아니라, 부품이 고장 나도 전체가 버티는 시스템이다. 부품은 언젠가 고장 나고, 그때 옆 부품까지 끌고 넘어지지 않게 하는 장치가 메시지와 이벤트다. SQS는 급증한 트래픽을 완충하고 처리하는 쪽이 자기 속도로 꺼내 가게 한다. SNS는 새 청중이 늘어도 외치는 쪽은 그대로다. EventBridge는 AWS 서비스와 SaaS의 이벤트, 스케줄까지 다룬다. 시나리오에서는 한 명이 처리하면 되는 일이면 SQS, 여러 명이 알아야 하는 일이면 SNS, 조건을 보고 갈라야 하는 일이면 EventBridge로 가른다.

다음 글에서는 이렇게 구성한 시스템이 잘 돌아가는지 지켜보고 관리하는 도구 — CloudWatch, CloudTrail, Config, Systems Manager — 를 본다.

📖 용어

• 강한 결합(tight coupling) : 시스템끼리 직접 붙어 있어 한쪽이 멈추면 다른 쪽도 같이 멈추는 상태.
• 느슨한 결합(loose coupling) : 중간에 메시지·이벤트를 두어, 한쪽이 죽어도 다른 쪽은 계속 도는 구조.
• 비동기(asynchronous) : 보낸 쪽이 답을 기다리지 않고 바로 자기 일을 계속하는 방식.
• 메시지 큐 : 처리할 일을 순서대로 쌓아두는 대기줄. 처리하는 쪽이 준비될 때 하나씩 꺼내 간다.
• 생산자 / 소비자 : 메시지를 큐에 넣는 쪽(생산자)과 꺼내서 처리하는 쪽(소비자).
• 폴링(polling) : 소비자가 "새 메시지 있나요?"라고 큐에 주기적으로 물어보며 가져가는 방식.
• 발행/구독(pub-sub) : 한 곳에 한 번 발행하면, 그걸 구독한 모두가 같은 내용을 받는 방식.
• 팬아웃(fan-out) : 메시지 하나가 여러 대상으로 동시에 퍼져 나가는 것.
• 이벤트 버스 : 여러 곳에서 오는 이벤트를 한데 모아, 규칙에 따라 알맞은 곳으로 보내주는 중계소.
• 동기(synchronous) : 보낸 쪽이 답을 받을 때까지 기다리는 방식. 전화 통화에 가깝다.
• 주제(topic) : SNS에서 메시지를 발행하는 창구 이름. 구독자는 이 창구를 구독한다.
• 버퍼링 : 한꺼번에 몰린 요청을 중간에 잠시 쌓아 두어, 뒤쪽이 감당할 수 있는 속도로 흘려보내는 것.
• FIFO : "First In, First Out" — 먼저 들어온 것이 먼저 나간다는 뜻. 은행 번호표와 같은 순서 보장.
• 이벤트(event) : "무슨 일이 일어났다"는 사실 한 건. 예: 파일이 업로드됨, 인스턴스 상태가 바뀜.
• 규칙(rule) : EventBridge에서 "어떤 이벤트를 어디로 보낼지" 정해 두는 조건.
• 오케스트레이션 : 여러 단계·여러 서비스의 작업을 순서와 조건에 맞게 지휘하는 것. Step Functions가 이 역할을 한다.

📝 연습 문제

선택지를 클릭하면 정답·해설이 펼쳐집니다.

문제 1

주문 시스템이 트래픽 급증 시에도 메시지를 잃지 않고, 결제 시스템이 자기 속도로 하나씩 처리하도록 두 시스템을 분리하려 한다. 가장 적합한 서비스는?

• AAmazon SNS
• BAmazon SQS
• CAmazon EventBridge
• DAmazon ElastiCache

문제 2

하나의 "주문 완료" 이벤트로 고객에게 이메일을 보내고, 분석 시스템에 기록하고, 배송 시스템을 동시에 깨우려 한다. 가장 적합한 서비스는?

• AAmazon SQS
• BAmazon RDS
• CAmazon SNS
• DAmazon Redshift

문제 3

시스템 컴포넌트를 직접 호출 대신 메시지로 연결할 때 얻는 주된 이점은?

• A컴포넌트 간 강한 결합으로 속도 향상
• B느슨한 결합으로 한 컴포넌트 장애가 전체로 번지는 것을 방지
• C데이터베이스 비용 절감
• DIAM 권한 자동 구성

문제 4

S3에 특정 파일이 업로드되면 자동으로 Lambda를 실행하는 등, AWS 서비스나 SaaS의 이벤트 내용에 따라 조건부로 작업을 라우팅하려 한다. 가장 적합한 서비스는?

• AAmazon SQS
• BAmazon EventBridge
• CAmazon ElastiCache
• DAmazon Aurora

문제 5

SQS와 SNS의 차이로 가장 정확한 설명은?

• ASQS는 다중 수신자에게 푸시하고, SNS는 단일 소비자가 폴링한다
• BSQS는 메시지 큐(보통 1:1, 소비자가 끌어감), SNS는 발행/구독(1:다, 구독자에게 푸시)이다
• C둘 다 데이터베이스 서비스다
• DSQS는 알림 발송 전용, SNS는 작업 버퍼링 전용이다