AA 예시

각 단계별로 "인프라쪽 AA"를 Application Architect와 Access Analyzer 두 가지 해석을 기준으로 실제 예시를 들어 설명해드리겠습니다.

1. Application Architect (응용 프로그램 아키텍트) 예시

상황: 중견 기업 A사는 새로운 고객 관리 시스템(CRM)을 개발하려고 합니다. 이를 위해 Application Architect가 역할을 맡습니다.

a. 애플리케이션 아키텍처 설계

• 예시: Application Architect는 비즈니스 요구사항을 분석한 후, 고객 데이터 관리, 고객 연락처 저장, 일정 관리 등 여러 모듈로 구성된 CRM 시스템 아키텍처를 설계합니다. 이 설계는 시스템이 데이터베이스와 어떻게 상호작용할지, 각 모듈이 어떤 방식으로 통신할지 등을 정의합니다.

b. 기술 스택 결정

• 예시: Architect는 Python과 Django 프레임워크를 사용하는 것을 결정합니다. 이유는 Django가 빠르게 프로토타입을 만들고 관리할 수 있는 기능을 제공하기 때문입니다. 또한, PostgreSQL 데이터베이스를 선택합니다. 이는 확장성과 보안이 요구되는 CRM 시스템에 적합하기 때문입니다.

c. 성능 및 확장성 고려

• 예시: CRM 시스템은 시간이 지남에 따라 수백만 개의 고객 데이터를 처리해야 할 수도 있습니다. Architect는 이를 고려해, Amazon AWS의 EC2 인스턴스와 RDS(PostgreSQL)를 기반으로 하는 클라우드 인프라를 제안합니다. 또한, 로드 밸런서를 통해 트래픽이 증가할 때 시스템이 자동으로 확장되도록 설계합니다.

d. 보안 및 규정 준수

• 예시: CRM 시스템은 GDPR과 같은 데이터 보호 법규를 준수해야 합니다. Architect는 데이터가 암호화되어 전송되도록 SSL 인증서를 사용하고, 고객 데이터 접근 권한을 엄격히 제어하기 위한 역할 기반 접근 제어(RBAC)를 설계합니다.

e. 개발 팀 리드

• 예시: Architect는 개발 팀을 이끌며, 각 모듈이 설계된 대로 구현되도록 합니다. 각 기능이 완료될 때마다 코드 리뷰를 하고, 애플리케이션의 테스트를 감독하며, 개발자와 DevOps 엔지니어 간의 협력을 조율합니다.

2. Access Analyzer (접근 분석기) 예시

상황: 클라우드 기반 금융 서비스 제공업체 B사는 AWS를 사용하여 여러 서비스를 운영 중입니다. 보안 강화의 일환으로 AWS IAM Access Analyzer를 도입합니다.

a. 접근 권한 분석

• 예시: Access Analyzer는 AWS 계정 내에서 특정 S3 버킷이 공용으로 노출되어 있는지, 혹은 외부 엔터티가 접근할 수 있는지를 분석합니다. 이 과정에서, 외부에서 접근 가능한 버킷이 몇 개 발견되어 이를 팀에 보고합니다.

b. 보안 정책 검토

• 예시: 발견된 문제를 해결하기 위해, Access Analyzer는 S3 버킷의 정책을 검토하고 수정 제안을 합니다. 예를 들어, 모든 사용자에게 읽기 권한이 열려 있는 버킷의 정책을, 특정 IAM 역할이나 특정 IP 주소만 접근할 수 있도록 수정합니다.

c. 클라우드 리소스 모니터링

• 예시: B사는 Access Analyzer를 사용하여 실시간으로 접근 로그를 모니터링합니다. 이를 통해 특정 사용자가 예상치 못한 시간에 특정 리소스에 접근하려는 시도를 탐지하고, 해당 접근 시도를 차단하거나 경고를 발송합니다.

d. 감사 및 보고

• 예시: Access Analyzer는 매월 정기적으로 감사 보고서를 생성하여 관리팀에 제출합니다. 보고서에는 지난달 동안의 접근 시도, 차단된 비정상적인 접근, 그리고 권한 수정 내역 등이 포함됩니다. 이 보고서는 회사의 규정 준수 담당자가 검토하여 외부 감사에 대비할 수 있도록 합니다.

이처럼 Application Architect와 Access Analyzer는 각각 다른 방식으로 인프라 및 시스템 관리에 중요한 역할을 합니다. 첫 번째는 주로 시스템의 설계와 개발에 초점을 맞추고, 두 번째는 보안과 접근 제어에 중점을 둡니다.