히치키치

AWS Community Day 2025 - Amazon Q CLI 워크숍 참여 후기 본문

카테고리 없음

AWS Community Day 2025 - Amazon Q CLI 워크숍 참여 후기

히치키치 2025. 11. 10. 23:52

 

AWS Community Day 2025는 AWS 클라우드를 사용하는 개발자와 엔지니어들이 분야별 아키텍처 경험을 공유하는 기술 컨퍼런스입니다. 여러 세션 중에서도 특히 Amazon Q 기반 생성형 AI 활용 사례가 흥미로웠고, 마침 AWS CLI를 확장한 Amazon Q CLI 핸즈온 세션이 있어 참여하게 되었습니다.

워크숍에서는 Amazon Q CLI를 직접 실습하며, 생성형 AI가 개발 워크플로우에 어떻게 자연스럽게 녹아들 수 있는지, 또 기존 CLI 환경에서 개발자의 효율을 얼마나 높일 수 있는지를 몸소 체험할 수 있었습니다.

 

코딩할 때는 넓은 창가 뷰와 달달구리가 필수임!!!

 

💡 Amazon Q CLI란?

Amazon Q CLI는 Amazon Q의 지능형 기능을 명령줄 환경에서도 활용할 수 있도록 확장한 AI 기반 명령줄 도구(Command Line Interface) 입니다. 개발자는 Amazon Q CLI를 통해 AWS 서비스에 대한 도움과 권장 사항을 즉시 얻고, 리소스 문제를 진단 및 해결하며, AWS CLI 명령어를 자동으로 생성하거나 해석할 수 있습니다. 또한, 단순한 명령 실행을 넘어 AWS 모범 사례(Best Practice) 기반 실시간 가이드와 대화형 AI 어시스턴트 기능을 제공하여, 기존 CLI 작업 흐름을 보다 효율적이고 직관적으로 개선할 수 있습니다. 요약하자면, Amazon Q CLI는 개발자와 엔지니어가 AWS 환경을 더 스마트하게 탐색하고 운영하도록 돕는 AI 도우미입니다.

 

 

aws workshop studio에서 손쉽게 구축된 VS Code Server 환경을 활용해 총 7가지 주제로 실습을 진행했습니다.


주어진 시간 동안 단계별로 따라가느라 다소 바쁘게 느껴질 수도 있지만, Workshop Studio의 매뉴얼이 매우 체계적이고 친절하게 구성되어 있어 큰 어려움 없이 진행할 수 있었습니다. 또, 권한이 48시간으로 넉넉하게 제공되어 집에 가서도 다시 둘러볼 수 있습니다.

특히 AWS 환경에 어느 정도 익숙한 분이라면, 실습 흐름을 따라가면서 다른 개발자 분들과 중간중간 Amazon Q CLI의 동작 원리나 명령 구조를 직접 탐색해보고 서로 다른 생성형 ai agent의 답변과 문제 해결 과정을 공유할 수 있을 정도로 잘 설계된 워크숍이었습니다.
특히 저는 실습 주제들이 실제 시나리오 기반으로 구성되어 있어, Amazon Q CLI가 어떻게 개발자의 의도를 이해하고 AWS 리소스 관리에 도움을 주는지를 자연스럽게 체험할 수 있었습니다.

 

부힛 잘 따라가는 중

AWS EC2 인스턴스에 SSH로 접속하지 못하는 문제를 Amazon Q CLI가 단계적으로 진단하고 해결해 나가는 과정이 정말 흥미로웠습니다. 왜냐하면, ChatGPT도 없던 제 대학생 시절 — 바로 그 ‘잼인’ 시절에 — 동일한 문제를 겪으며 밤새 구글링과 Stack Overflow를 뒤져가며 해결했던 기억이 떠올랐기 때문입니다.

$ ssh ec2-user@54.89.151.1
ssh: connect to host 54.89.151.1 port 22: Connection timed out

 

그때의 저는 EC2 인스턴스가 정상적으로 실행 중인지조차 확신이 없었고, 보안 그룹(Security Group), 네트워크 ACL, SSH 키 인증 등 AWS의 3계층 보안 메커니즘을 일일이 점검하며 원인을 찾아야 했습니다.

하지만 이번 워크숍에서의 Amazon Q CLI는 이런 과정을 놀라울 정도로 매끄럽게 자동화했습니다. 단 몇 줄의 명령으로 현재 인스턴스 상태를 점검하고, 보안 그룹 설정을 분석하며, 잠재적 연결 문제를 짚어주는 모습은 “AI가 코드 뿐만 아니라 개발자의 디버깅 과정을 학습해 진화하고 있구나”라는 생각이 절로 들게 했습니다.

 

Amazon Q는 다음과 같은 검사 항목을 제시했습니다.

  1. EC2 인스턴스 상태 - 실행 중인가?
  2. Security Group - 포트 22가 열려있는가?
  3. Network ACL - 트래픽이 허용되는가?
  4. Route Table - 인터넷 게이트웨이가 제대로 연결되었는가?

문제 1: Security Group에서 포트 22 차단

$ aws ec2 describe-security-groups --group-ids "sg-0cd42ce3e51d8d146"
```

결과는 충격적이었다. Security Group은 **HTTP(포트 80)만 허용**하고 있었다. SSH(포트 22)는 완전히 차단되어 있었다.
```
SecurityGroupIngress:
  - IpProtocol: tcp
    FromPort: 80
    ToPort: 80
    CidrIp: 0.0.0.0/0    ← HTTP만 허용
  
  # SSH(포트 22)는 규칙 자체가 없음!

 

Amazon Q는 즉시 규칙을 추가했습니다.

$ aws ec2 authorize-security-group-ingress \
  --group-id "sg-0cd42ce3e51d8d146" \
  --protocol tcp \
  --port 22 \
  --cidr 0.0.0.0/0

 

이제 첫 번째 관문을 통과해. 다시 SSH를 시도해습니다. 그러나 ....

$ ssh ec2-user@54.89.151.1
ssh: connect to host 54.89.151.1 port 22: Connection timed out

 

여전히 같은 에러가 발생했습니다.

 

문제 2: Network ACL에서도 포트 22 차단

Amazon Q는 다음 계층으로 Network ACL 계층을 점검했습니다.

$ aws ec2 describe-network-acls --filters \
  Name="association.subnet-id",Values="subnet-0c5fbd12b9b4992a0"
```

Network ACL 규칙을 확인해보니:
```
Inbound Rules:
  - Rule Number: 100, Port: 80 (HTTP) → Allow
  - Rule Number: 200, Port: 1024-65535 (Ephemeral) → Allow
  - Port 22 (SSH) → 규칙 없음! ✗

Outbound Rules:
  - Rule Number: 100, Port: 80 → Allow
  - Rule Number: 110, Port: 443 → Allow
  - Rule Number: 200, Port: 1024-65535 → Allow

Security Group을 수정한 후에도 Network ACL이 트래픽을 차단하고 있었다!

Amazon Q는 Network ACL 규칙을 추가했다.

$ aws ec2 create-network-acl-entry \
  --network-acl-id "acl-0f9870d0dbb11b0b6" \
  --rule-number 150 \
  --protocol tcp \
  --port-range From=22,To=22 \
  --cidr-block 0.0.0.0/0 \
  --ingress \
  --rule-action allow

다시 SSH를 시도했다. 이번에는 다른 에러문이 나왔습니다.

$ ssh -o ConnectTimeout=10 ec2-user@54.89.151.1
Warning: Permanently added '54.89.151.1' (ED25519) to the list of known hosts.
ec2-user@54.89.151.1: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

 

드디어 다른 에러가 났다! 이제 네트워크 연결은 성공했지만, 인증에 실패했다.

문제 3: SSH 키 쌍이 없음

$ aws ec2 describe-instances \
  --instance-ids "i-009cc5ab6325e627d" \
  --query "Reservations[0].Instances[0].KeyName"

출력 결과는 공백이었다. EC2 인스턴스에 할당된 키 쌍이 없었던 것이다.

일반적으로 EC2 인스턴스를 생성할 때 키 쌍을 지정해야 하는데, 이 인스턴스는 그렇지 않았다.

 

Amazon Q는 두 가지 옵션을 제시했다.

Option 1: EC2 Instance Connect 사용과 Option 2: Systems Manager Session Manager 사용이다.

 

Option 2를 시도한 결과, 

$ aws ssm start-session --target i-009cc5ab6325e627d
An error occurred (TargetNotConnected) when calling the StartSession operation: 
i-009cc5ab6325e627d is not connected.

SSM 에이전트가 설치되지 않았다. 따라서 Option 1(EC2 Instance Connect)을 사용해야 했다.

 

해결: EC2 Instance Connect로 임시 키 생성

Amazon Q는 다음 과정을 수행했습니다.

 

1단계: 로컬에서 임시 SSH 키 쌍 생성

$ ssh-keygen -t rsa -f /tmp/temp_key -N "" -q

# 공개키 확인
$ cat /tmp/temp_key.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCfYhidmYYEJ9nLGYSYUHrkgi5m...

RSA 암호화 방식으로 공개키와 비밀키가 생성되었다.

 

2단계: 공개키를 EC2에 전송

$ aws ec2-instance-connect send-ssh-public-key \
  --instance-id i-009cc5ab6325e627d \
  --instance-os-user ec2-user \
  --ssh-public-key file:///tmp/temp_key.pub \
  --availability-zone us-east-1a

EC2 Instance Connect 서비스가 공개키를 EC2 인스턴스의 ~/.ssh/authorized_keys 파일에 추가했다. 이 공개키와 대응하는 비밀키를 가진 클라이언트만 접속할 수 있게 되었다.

 

3단계: 비밀키로 접속

 

성공~~

 

Amazon Q CLI가 어떤 내부 도구를 사용해 문제를 분석하고, 단계별로 어떤 전개(Reasoning)와 액션(Action)을 수행해 솔루션을 제시하는지 파악하는 과정 또한 매우 인상적이었습니다. 단순히 AI에게 모든 문제 해결을 전적으로 위임하는 것이 아니라, 그 과정을 이해하고 함께 판단하는 개발자의 역할이 여전히 중요하다는 점을 느꼈습니다.

Amazon Q CLI는 확실히 강력한 AI 어시스턴트이지만, 결국 도구의 가치를 극대화하는 것은 그것을 어떻게 활용하느냐에 달려 있습니다.
이번 워크숍을 통해 단순히 새로운 기능을 배운 것을 넘어, AI가 개발자의 문제 해결 과정에 자연스럽게 녹아드는 미래의 개발 환경을 엿볼 수 있었던 뜻깊은 경험이었습니다.

Comments