글로벌 애플리케이션의 세 가지 책임 (Part 2)

Source: Dev.to

파트 1에서는 전 세계 규모에서 신뢰가 감정이 아니라 시스템이 강제하고 증명해야 하는 아키텍처의 일부임을 설명했습니다. 이 글에서는 글로벌 시스템이 유기적으로 성장하도록 하는 세 가지 뚜렷한 책임에 대해 설명합니다.

---

책임 1 – 실행 (비즈니스 로직)

무엇을 하는가

• 비즈니스 로직 실행
• 요청 처리
• 이벤트 처리
• 워크플로우 진행

일반적인 AWS 서비스

• AWS Lambda
• Step Functions
• EventBridge
• DynamoDB
• SQS
• SNS

주요 질문

시스템이 비즈니스를 위해 무엇을 하는가?

최적화 목표

• 정확성
• 확장성
• 탄력성
• 격리

문제가 되는 경우

• 컴플라이언스 로직을 비즈니스 코드에 직접 삽입
• 구조 없이 모든 곳에 “만일을 대비한” 로깅을 추가
• 운영상의 고민이 도메인 로직에 섞이는 경우

실행 코드는 작업 수행에 집중해야 하며, 이를 설명하거나 방어하는 데에 집중해서는 안 됩니다.

---

책임 2 – 감사 / 증명

존재 이유

팀 외부의 누군가가 다음과 같은 질문을 할 것입니다:

• 누가 접근했는가?
• 누가 프로덕션을 변경했는가?
• 어떤 데이터가 어디로 이동했는가?
• 그때 로깅이 활성화되어 있었는가?

이 질문들은 디버깅이 아니라 증명에 관한 것입니다.

이 책임을 구현하는 AWS 서비스

• AWS CloudTrail
• IAM 구성 및 접근 기록
• 구성 이력 및 보존 정책
• AWS Audit Manager

일반적인 함정

• 실행 또는 관측 데이터를 증거로 재사용 (로그 형식이 바뀌고, 메트릭이 집계되며, 대시보드가 삭제되고, 개발자들이 기억을 다르게 함).

증거는 다음과 같아야 함

• 완전함
• 일관성
• 변조 방지

이러한 요구사항 때문에 감사는 실행과 별도로 유지되어야 합니다.

---

책임 3 – 운영 / 건강 모니터링

주요 질문

시스템이 현재 정상적인가?

(“테넌트 X에 무슨 일이 있었는가?” 혹은 “누가 이것을 변경했는가?”가 아니라)

일반적인 관심사

• 오류가 증가하고 있는가?
• 지연 시간이 악화되고 있는가?
• 문제가 지역적인가, 전 세계적인가?

답은 다음에서 나옴

• 메트릭
• 알림
• SLO
• 대시보드

사용되는 AWS 서비스

• Amazon CloudWatch 메트릭 & 대시보드
• Amazon Managed Prometheus
• 서비스 텔레메트리 & 알림

이 서비스들은 건강 신호가 임계값을 초과하면 조사와 조치를 트리거합니다.

---

책임을 분리함으로써 얻는 이점

• 명확한 대화

  • “로그를 중앙화해야 할까요?” 대신 “우리가 어떤 책임을 충족하려는가?” 라고 물어보세요.
  • “왜 메트릭에 tenantId만 추가할 수 없나요?” 대신 “이것이 운영 신호인가, 회계 질문인가?” 라고 물어보세요.
  • “왜 거버넌스가 우리를 늦추나요?” 대신 “우리가 만족시키려는 책임은 무엇인가?” 라고 물어보세요.

• 명시적인 트레이드‑오프 – 결정은 해당 책임을 염두에 두고 이루어져 숨겨진 복잡성을 줄입니다.

• 규모가 커질수록 혼란 감소 – 테넌트 ID가 포함된 메트릭, 감사 대시보드, CloudTrail을 통한 디버깅은 각각 독립적으로는 의미가 있지만, 이를 혼합하면 모호한 신호가 됩니다.

거버넌스 관점에서 글로벌 시스템이 실패하는 이유는 분산돼 있기 때문이 아니라, 단일 시스템에 모든 일을 한 번에 수행하도록 요구하기 때문입니다. 실행, 감사, 운영 건강을 분리함으로써 복잡성을 적절한 위치에 배치할 수 있습니다.