[AWS Community day] DAY1 - Basic 참여

 

요즘 AWS에 대해 열심히 공부하고 있던 중, 친구가 AWS Community Day가 열린다며 같이 가자고 제안해줘서 참여하게 되었다.

아직 AWS를 본격적으로 공부한 지 얼마 되지 않아, Basic 코스를 선택해서 듣게 되었다.

AWS Community Day 2025 - AI로 혁신하는 최신 클라우드 기술 배우기 - 이벤터스

 

 

 

 

입장하자마자 다양한 굿즈를 받았는데, 일상에서도 유용하게 쓸 수 있는 것들이 많아서 기분이 좋았다.

 

이후 여러 강연을 들으며 클라우드와 AI 시대의 개발자 역할에 대해 많은 생각을 하게 되었다.

 

 

 

에이전트 AI 시대: 클라우드 네이티브 개발자의 대응

첫 세션은 “Agentic AI” 라는 다소 생소한 개념으로 시작됐다.
요즘 ChatGPT나 Claude처럼 LLM을 활용하는 개발이 늘고 있지만,
단순히 질문하고 답변받는 수준을 넘어서 “스스로 행동하는 AI”, 즉 Agentic AI가 주목받고 있다는 내용이었다.

 

Agentic AI 개발 도구 

Strands Agents와 오픈 소스 AI 에이전트 SDK 살펴보기 | Amazon Web Services

 

기존의 LLM 기반 코딩에는 여러 한계가 있었다:

• 프로젝트 확장성 부족
• 일관된 AI 협업 제어의 어려움
• 코드 품질 저하

 

이런 문제를 해결하기 위한 접근이 바로 Agentic AI였다.

 

Strands Agents란?

AWS가 공개한 오픈소스 SDK로, 단 몇 줄의 코드로 AI 에이전트를 만들 수 있다.

Python 기반으로 동작하며, 단순히 답만 주는 것이 아니라 API 호출, 파일 조작 등 행동을 수행할 수 있는 것이 특징이다.

 

예를 들어,

LLM에게 " 지금 몇 시야?" 라고 물으면 “모르겠다”고 하지만,

Strands Agents는 실제로 시스템 시계를 조회하는 API를 호출해 “오전 10시 32분입니다.”라고 대답한다.

 

즉, 단순한 언어 모델이 아니라, “생각하고 → 행동하고 → 검증하는 구조”를 가지는 것이다.

 

개발자의 역할 변화

강연자는 앞으로의 개발자를 이렇게 정의했다.

 

• 제품 엔지니어 – 사용자의 요구를 AI에게 직접 설계하는 사람
• 시스템 아키텍처 – 복잡한 시스템 구조를 안정적으로 설계하고 유지하는 사람
• 학습과 실험 정신 – 새로운 AI 도구와 프롬프트를 끊임없이 테스트하며 개선하는 사람

“AI가 코드를 대신 짜주는 시대에도, 결국 시스템 전체를 설계하고 책임지는 건 인간 개발자입니다.”

 

이 말이 가장 인상 깊었다.

 

클라우드도 결국  어딘가에 있는 온프레미스가 아닌가요 ?

두 번째 세션은 제목부터 흥미로웠다.

 

사실 클라우드도 결국 누군가의 데이터센터 위에서 돌아간다.

즉, 우리가 직접 서버실을 꾸리지 않을 뿐, AWS가 대신 인프라를 운영해주는 형태라고 볼 수 있다.

 

온프레미스 시대의 특징

네트워크 구성, 스토리지 연결, 서버 증설 등 모든 작업을 직접 물리적으로 처리해야 했다.

서버 한 대에 여러 가상머신(VM)을 띄워야 하는 경우, 하이퍼바이저(VMware 등) 같은 별도 기술이 필요했다.

스토리지는 네트워크를 통해 직접 연결(NAS, SAN 등)해야 했다.

 

클라우드 인프라의 진화

이 모든 복잡한 작업을 AWS의 서비스 단위로 대체할 수 있다.

• VPC와 Subnet으로 가상 네트워크 환경 구성
• EC2로 가상 서버 생성
• S3, RDS, ElasticCache로 스토리지와 DB를 관리

URL (Unique Resource Locator)

이 부분이 재밌었다.

 

URL은 Unique Resource Locator의 약자로,

말 그대로 인터넷 상의 리소스(자원) 위치를 가리키는 주소예요.

 

즉, “URL에 접근한다”

 “인터넷 상에서 그 리소스를 달라고 요청하는 것”

 

이라고 볼 수 있다.

 

 

클라우드 환경에서도 결국 이 원리는 동일하다.

우리가 CloudFront나 EC2의 퍼블릭 IP로 접속한다는 건, 그 리소스를 달라고 요청한다는 뜻이다.

 

배포 공식

프론트엔드 배포 공식

1. 정적 파일(HTML, CSS, JS 등)을 업로드
2. Nginx 같은 웹 서버 실행
   → 예: S3 + CloudFront 조합으로 정적 사이트 배포

백엔드 배포 공식

1. 서버 코드 업로드
2. WAS(Web Application Server) 실행
   → 예: Node.js 서버를 EC2나 ECS에서 실행

클라우드 시대의 배포 방식

EC2를 중심으로 다양한 역할이 서비스 단위로 분화되었다.

전 세계에 분산된 Nginx 기반 엣지 서버가 CloudFront 전용 네트워크 내에서 동작한다고 보면 된다.

 

이번 세션을 들으면서 느낀 건, 클라우드는 단순히 서버를 대신 빌려주는 곳이 아니라는 것이다.
그보다는 온프레미스 인프라의 복잡한 과정을 서비스 단위로 추상화한 진화형 구조라는 표현이 더 어울렸다.

이 구조를 잘 이해하면, 우리가 AWS를 사용할 때 훨씬 유연하게 시스템을 설계할 수 있을 것 같다.

 

 

 

Amazon Q 와 CDK로 빠르게 검증하며 개편한 스타트업 인프라 설계

이 세션에서는 AI + 인프라 자동화의 실전 활용 사례를 다뤘다.

 

Amazon Q Developer

Amazon Q는 AWS 전용 AI 어시스턴트다.

복잡한 설정이나 리소스 구조를 물어보면 문서 대신 대화로 설명해 준다.

CLI 명령어, IAM 설정, 보안 그룹 구성 등을 자연어로 질문할 수 있다.

 

“이제 AWS 콘솔을 뒤지지 않아도 된다”는 말이 과장이 아니었다.

 

AWS CDK

AWS CDK란 무엇입니까? - AWS 클라우드 개발 키트(AWS CDK) v2

 

AWS가 만든 IaC 오픈소스 프로젝트로, TypeScript나 Python으로 인프라를 코드처럼 관리할 수 있다.

CDK를 쓰면 “콘솔에서 수동 클릭으로 세팅하던” 환경을 `cdk deploy` 한 줄로 통합 관리할 수 있다.

 

실제 스타트업의 사례를 보면서 “인프라 관리가 개발자의 손으로 돌아오고 있다”는 걸 느꼈다.

 

 

 

 

아직도 서버 관리를 수작업으로 하세요 ? AWS Systems Manager 로 자동화

이 세션은 매우 유용했다. 서버 접근, 에이전트 설치, 보안 패치 등 그동안 사람이 직접 하던 일들을 AWS Systems Manager(SSM) 로 자동화할 수 있다는 내용이었다.

 

01 수동 관리의 Pain Point

서버를 여러 대 운영하다 보면 반복되는 상황이 생긴다.

 

• 시나리오 1) 신규 Agent 설치
  : 신규 EC2 인스턴스마다 하나씩 접속해서 설치해야 함
• 시나리오 2) 추적 가능한 서버 접근
  : 누가 언제 어떤 명령을 실행했는지 로그 관리가 어렵고
• 시나리오 3) 긴급 보안 패치
  : 매번 서버마다 패치를 수동으로 적용해야 함

 

이 모든 문제를 AWS Systems Manager 한 번으로 해결할 수 있다.

 

02 AWS Systems Manager란?

System Manager

: SSH/RDP 없는 대규모 서버 운영 자동화

• SSM AGENT를 사용함으로써 서버의 SSH (22) 포트나 RDP (3389) 포트를 외부에 열어둘 필요가 없다.
• 단 하나의 콘솔과 API를 통해 일관된 방식으로 관리한다.
• 하나의 document 에 정의하여 선언적으로 구성된다.

Paramater Store

: 설정값, DB 암호, API 키 등 저장하는 중앙 관리 저장소

• Config를 코드 및 인스턴스에서 분리한다.
• ECS Task Definition, EC2 UserData 등에서 안전하게 참조 가능하다.
• IAM 통해 접근 제어 가능, SecureString으로 암호화 가능, 변경 이력 추적 가능하다.

Run Command

: 여러 EC2 인스턴스나 온프레미스 서버에 명령을 동시에 실행할 수 있게 해주는 서비스

• EC2나 온프레미스 서버에 명령을 한 번에 실행한다.
• SSH 없이도 yum update 나 systemctl restart 같은 명령이 가능하다. 
• 명령 실행 결과를 중앙에서 바로 확인 가능하다.

 

State Manager

: 인스턴스가 항상 의도한 상태를 유지하도록 보장

• 정해진 스케줄에 맞춰 구성 상태를 점검한다.
• 상태가 벗어나면 자동으로 재구성한다.
• 서버의 일관성과 표준화를 유지한다.

 

03 자동화를 위한 구성 기능

AWS SSM은 단일 기능이 아니라, 여러 모듈이 합쳐져 운영 자동화를 완성한다. 

구성요소	역할	설명
Document	정의	JSON/YAML로 수행할 작업 정의
Distributor	배포	소프트웨어 패키지 버전 관리 및 중앙 배포
Automation	자동화	여러 단계를 오케스트레이션하는 워크플로우 서비스
State Manager	상태 유지	정의한 상태를 인스턴스에 지속 반영
Compliance	규정 준수	인스턴스가 규정된 정책을 잘 지키고 있는지 점검

 

즉, “정의 → 배포 → 자동화 → 상태 유지 → 검증” 의 모든 단계를 하나로 연결하는 셈이다.

 

 

 

AWS WAF로 서비스 다방면으로 보호하기

이제 서버를 자동화했다면, 다음 단계는 보안이다.

AWS에는 WAF (Web Application Firewall) 이라는 강력한 서비스가 있다.

 

Protection Packs (Web ACLs)

WAF의 기본 단위는 Web ACL (Access Control List) 이다.

보호할 리소스와 그 리소스에 적용될 규칙(Rules) 을 한 번에 정의한다.

 

Rule 구성 요소

• Statement : 어떤 조건에서 룰이 동작할지를 정의한다. 
• Action : Allow, Block Count 중 하나를 선택한다.
• Allow : 요청을 허용한다.
• Block : 요청을 거절한다.
• Count : 요청을 계산하고, 다음 우선순위의 rule 또하는 rule group으로 넘긴다. 
• Priority : 여러 Rule이 있을 때 적용 순서를 결정한다.

예를 들어, 특정 IP는 차단, 특정 국가에서 오는 요청만 허용, 나멎니느 카운트하여 로그로만 기록 과 같은 구성이 가능하다. 

 

WAF 동작 과정

1. CloudFront 와 연결해 엣지 단에서 공격 차단
2. Application Load Balancer (ALB) 와 결합해 백엔드 보호
3. 필요 시 API Gateway 나 AppSync 와도 통합 가능

WAF는 단순히 “공격을 막는 방화벽” 정도로만 알고 있었는데, 이번 세션을 통해 그 이상의 역할을 한다는 걸 확실히 느꼈다.

특히 인상 깊었던 부분은 ‘보안도 코드처럼 관리할 수 있다’ 는 개념이었다. 과거에는 보안 설정을 콘솔에서 일일이 클릭하며 설정해야 했다면, 이제는 Web ACL과 Rule Group을 선언적으로 정의하고 재사용할 수 있기 때문에 보안 정책 자체를 인프라의 일부로 버전 관리할 수 있다는 점이 굉장히 매력적으로 다가왔다.

결국 보안도 자동화의 연장선에 있다. 서버 운영을 자동화했다면, 보안 역시 자동화할 차례라는 메시지가 명확히 다가왔다.

 

 

 

---

 

AWS Community Day 2025는 단순히 ‘AWS를 배우는 행사’가 아니라,

클라우드와 AI 시대에 개발자가 어떤 방향으로 성장해야 하는지를 보여주는 자리였다.

 

아직 AWS를 막 배우기 시작한 단계지만,

이번 커뮤니티 데이를 통해 “왜 클라우드를 배워야 하는지”, “어디로 나아가야 하는지”를 조금 더 명확히 잡을 수 있었다.

단순히 기술을 익히는 게 아니라, 그 기술을 서비스와 사용자의 경험으로 연결하는 개발자가 되고 싶다는 목표도 새롭게 생겼다.

 

다음에 또 좋은 기회가 생긴다면, 또 참여하고 싶다는 생각이 들었다.