AWS CLI 완벽 가이드 - 설치부터 실전까지

AWS CLI를 처음 접하는 개발자를 위한 완벽 가이드입니다. 설치 방법부터 자격 증명 설정, 실전에서 자주 사용하는 S3와 EC2 명령어까지 실무에 바로 적용할 수 있는 내용을 담았습니다. 베스트셀러 프로그래밍 입문서처럼 술술 읽히는 스타일로 작성되었습니다.

---

목차

1. AWS CLI란?
2. CLI 설치하기
3. 자격 증명 설정
4. 기본 명령어 실습
5. S3 CLI 명령어
6. EC2 CLI 명령어

---

1. AWS CLI란?

신입 개발자 김개발 씨는 오늘도 AWS 콘솔 웹사이트에 접속해서 클릭, 클릭, 또 클릭을 반복하고 있습니다. S3 버킷에 파일 하나 올리는데도 여러 메뉴를 거쳐야 하고, EC2 인스턴스 상태를 확인하려면 페이지를 새로고침해야 합니다.

선배 박시니어 씨가 그런 김개발 씨를 보고 조용히 말합니다. "터미널에서 한 줄로 해결할 수 있는데, AWS CLI 써봤어요?"

AWS CLI는 Amazon Web Services의 모든 기능을 명령줄에서 제어할 수 있게 해주는 통합 도구입니다. 마치 리모컨으로 TV를 조작하듯이, 터미널 창에서 명령어 한 줄로 AWS의 모든 서비스를 제어할 수 있습니다.

웹 콘솔에서 여러 번 클릭하던 작업을 자동화하고, 스크립트로 반복 작업을 처리할 수 있게 됩니다.

다음 코드를 살펴봅시다.

# AWS CLI 버전 확인
aws --version

# S3 버킷 목록 조회 (가장 많이 사용하는 명령어)
aws s3 ls

# EC2 인스턴스 목록 조회
aws ec2 describe-instances --query 'Reservations[*].Instances[*].[InstanceId,State.Name,InstanceType]' --output table

# 특정 리전의 리소스 조회
aws s3 ls --region us-west-2

김개발 씨는 매일 아침 출근하면 가장 먼저 AWS 콘솔에 로그인합니다. 어제 배포한 서비스가 잘 돌아가는지 확인하고, S3에 새로운 파일을 업로드하고, EC2 인스턴스의 상태를 점검합니다.

하지만 이 모든 작업을 웹 브라우저에서 하다 보니 시간이 꽤 걸립니다. 어느 날, 같은 팀 박시니어 씨의 화면을 우연히 보게 됩니다.

신기하게도 박시니어 씨는 터미널 창에서 명령어 몇 줄만 입력하고 있습니다. 그런데 그 짧은 시간에 김개발 씨가 10분 걸려서 하는 작업을 모두 끝냈습니다.

"선배, 어떻게 그렇게 빨리 하세요?" 김개발 씨가 놀라서 묻습니다. 박시니어 씨가 웃으며 대답합니다.

"AWS CLI를 쓰면 돼요. 한번 배워두면 엄청 편해요." AWS CLI란 무엇일까요? 쉽게 비유하자면, AWS CLI는 마치 스마트홈 음성 비서와 같습니다.

"불 켜줘"라고 말하면 불이 켜지듯이, "aws s3 ls"라고 입력하면 S3 버킷 목록이 나타납니다. 웹 콘솔이라는 그래픽 인터페이스를 거치지 않고, 직접 AWS에 명령을 내릴 수 있는 것입니다.

더 정확히 말하면, CLI는 Command Line Interface의 약자입니다. 마우스로 클릭하는 대신 키보드로 명령어를 입력하는 방식이죠.

AWS의 모든 서비스를 이런 방식으로 제어할 수 있게 해주는 도구가 바로 AWS CLI입니다. 왜 AWS CLI가 필요할까요? 웹 콘솔만으로도 충분히 AWS를 사용할 수 있는데, 왜 굳이 명령어를 외워가며 CLI를 배워야 할까요?

첫 번째 이유는 속도입니다. 웹 콘솔에서는 메뉴를 찾아 클릭하고, 페이지가 로딩되기를 기다려야 합니다.

하지만 CLI는 명령어 한 줄이면 끝입니다. 숙련되면 웹 콘솔보다 10배는 빠르게 작업할 수 있습니다.

두 번째는 자동화입니다. 매일 반복되는 작업이 있다면 어떻게 하시겠습니까?

웹 콘솔에서는 매번 같은 클릭을 반복해야 합니다. 하지만 CLI 명령어는 스크립트 파일로 저장해두고 실행하면 됩니다.

한 번 작성해두면 영원히 재사용할 수 있습니다. 세 번째는 정확성입니다.

사람은 실수를 합니다. 클릭해야 할 버튼을 잘못 누르거나, 설정 값을 빠뜨릴 수 있습니다.

하지만 스크립트로 작성된 명령어는 항상 정확하게 동일한 작업을 수행합니다. AWS CLI의 핵심 기능 AWS CLI는 AWS의 거의 모든 서비스를 지원합니다.

S3에 파일을 업로드하고, EC2 인스턴스를 시작하고, RDS 데이터베이스를 생성하고, Lambda 함수를 배포할 수 있습니다. 웹 콘솔에서 할 수 있는 모든 작업을 명령어로 수행할 수 있습니다.

위의 코드를 살펴보겠습니다. 첫 번째 명령어인 aws --version은 설치된 AWS CLI의 버전을 확인합니다.

이것은 마치 프로그램이 제대로 설치되었는지 확인하는 "헬로 월드"와 같습니다. 두 번째 명령어 aws s3 ls는 가장 많이 사용하는 명령어 중 하나입니다.

현재 계정에 있는 모든 S3 버킷의 목록을 보여줍니다. 단 한 줄이면 충분합니다.

세 번째 명령어는 조금 복잡해 보이지만, EC2 인스턴스의 정보를 깔끔한 표 형식으로 보여줍니다. --query 옵션으로 필요한 정보만 추출하고, --output table 옵션으로 보기 좋게 정렬합니다.

실무에서의 활용 김개발 씨가 속한 팀에서는 매일 아침 모든 EC2 인스턴스의 상태를 확인해야 합니다. 예전에는 웹 콘솔에 접속해서 하나하나 확인했지만, 이제는 스크립트 하나로 모든 인스턴스의 상태를 확인하고, 문제가 있으면 슬랙으로 알림을 보냅니다.

또 다른 예로, 매주 금요일마다 특정 S3 버킷의 오래된 파일을 삭제하는 작업이 있습니다. 이것도 AWS CLI 스크립트로 자동화해두었습니다.

크론탭으로 예약해두면 사람이 신경 쓸 필요가 없습니다. 주의할 점 AWS CLI를 처음 사용할 때 초보자들이 자주 하는 실수가 있습니다.

바로 자격 증명 설정을 제대로 하지 않는 것입니다. AWS CLI는 여러분의 AWS 계정에 접근할 권한이 필요합니다.

이것을 설정하지 않으면 "자격 증명을 찾을 수 없습니다"라는 오류가 발생합니다. 또 하나 주의할 점은 리전 설정입니다.

AWS는 전 세계에 여러 리전을 운영합니다. 서울 리전에 있는 리소스를 조회하려면 리전을 명시해야 합니다.

기본 리전 설정을 해두면 매번 입력하지 않아도 됩니다. 정리 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 눈이 반짝입니다. "이거 정말 편하겠는데요!

저도 배워보고 싶어요!" AWS CLI를 배우면 단순 반복 작업에서 벗어나 더 창의적인 일에 집중할 수 있습니다. 처음에는 명령어를 외우는 게 어렵게 느껴질 수 있지만, 몇 번 사용하다 보면 자연스럽게 손에 익습니다.

여러분도 오늘부터 AWS CLI를 시작해보세요.

실전 팁

💡 - AWS CLI 공식 문서를 북마크해두고 자주 참고하세요

• 자주 사용하는 명령어는 쉘 별칭(alias)으로 등록해두면 편합니다
• 처음에는 --dry-run 옵션으로 안전하게 테스트해보세요

---

2. CLI 설치하기

AWS CLI를 배우기로 결심한 김개발 씨는 가장 먼저 설치부터 해야 한다는 것을 알았습니다. 하지만 인터넷을 검색해보니 설치 방법이 운영체제마다 다르고, 버전도 1과 2가 있다고 합니다.

"어떤 걸 설치해야 하지?" 김개발 씨가 고민하는 모습을 본 박시니어 씨가 다가옵니다. "지금은 무조건 AWS CLI 버전 2를 설치하면 돼요.

방법도 간단해요."

AWS CLI 설치는 운영체제에 따라 다른 방법을 사용합니다. Windows에서는 MSI 설치 파일을 다운로드하고, macOS에서는 PKG 파일이나 Homebrew를 사용하며, Linux에서는 설치 스크립트를 실행합니다.

현재는 AWS CLI 버전 2가 최신이며, 더 빠르고 안정적이므로 반드시 버전 2를 설치해야 합니다.

다음 코드를 살펴봅시다.

# macOS - Homebrew를 사용한 설치 (가장 쉬운 방법)
brew install awscli

# Linux - 공식 설치 스크립트 사용
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

# 설치 확인 - 버전 2.x.x가 나와야 합니다
aws --version

# 설치 경로 확인
which aws

김개발 씨는 맥북을 사용하고 있습니다. 윈도우를 쓰는 동료도 있고, 회사 서버는 리눅스로 돌아갑니다.

각자 사용하는 운영체제가 다르지만, 다행히 AWS CLI는 모든 주요 운영체제를 지원합니다. 박시니어 씨가 김개발 씨에게 설명합니다.

"일단 본인 컴퓨터에 맞는 방법으로 설치하면 돼요. 맥 쓰시니까 Homebrew로 설치하는 게 제일 간단할 거예요." AWS CLI 버전 1 vs 버전 2 AWS CLI에는 두 가지 버전이 있습니다.

예전에 나온 버전 1과 최신 버전 2입니다. 마치 파이썬 2와 파이썬 3처럼 말이죠.

그렇다면 어떤 버전을 설치해야 할까요? 답은 명확합니다.

무조건 버전 2를 설치해야 합니다. 버전 2가 더 빠르고, 새로운 기능도 많으며, AWS에서도 공식적으로 버전 2 사용을 권장합니다.

버전 1은 레거시 시스템을 위해 유지되고 있을 뿐입니다. macOS에서 설치하기 맥 사용자라면 가장 쉬운 방법은 Homebrew를 사용하는 것입니다.

Homebrew는 맥 개발자들이 가장 많이 사용하는 패키지 관리자입니다. 마치 앱스토어처럼 개발 도구를 쉽게 설치하고 업데이트할 수 있게 해줍니다.

터미널을 열고 brew install awscli라고 입력하면 됩니다. Homebrew가 알아서 최신 버전을 다운로드하고 설치합니다.

김개발 씨는 명령어를 입력하고 잠시 기다렸습니다. 1~2분 정도 지나니 설치가 완료되었습니다.

Homebrew가 없다면 어떻게 해야 할까요? 공식 PKG 파일을 다운로드해서 설치할 수도 있습니다.

AWS 공식 문서에서 다운로드 링크를 제공합니다. 더블클릭으로 설치하는 일반 프로그램과 동일합니다.

Linux에서 설치하기 서버 환경에서 자주 사용하는 리눅스에서는 설치 스크립트를 사용합니다. 위의 코드를 보면 세 단계로 이루어져 있습니다.

첫 번째 줄에서 curl 명령으로 설치 파일을 다운로드합니다. 이것은 마치 웹 브라우저로 파일을 다운로드하는 것과 같습니다.

두 번째 줄에서 압축을 풉니다. 세 번째 줄에서 실제로 설치를 진행합니다.

여기서 sudo라는 명령어가 보입니다. 이것은 관리자 권한으로 실행한다는 뜻입니다.

AWS CLI를 시스템 전체에서 사용할 수 있도록 하려면 관리자 권한이 필요합니다. 비밀번호를 입력하라는 메시지가 나오면 여러분의 시스템 비밀번호를 입력하세요.

Windows에서 설치하기 윈도우 사용자라면 MSI 설치 파일을 다운로드하면 됩니다. 일반 프로그램을 설치하듯이 다음, 다음, 설치 버튼을 클릭하면 자동으로 설치됩니다.

AWS 공식 웹사이트에서 64비트용 MSI 파일을 다운로드하세요. 설치가 끝나면 명령 프롬프트나 파워셸을 다시 시작해야 합니다.

이미 열려 있던 창에서는 aws 명령어를 인식하지 못할 수 있기 때문입니다. 설치 확인하기 설치가 제대로 되었는지 확인하는 방법은 간단합니다.

터미널을 열고 aws --version이라고 입력해보세요. 제대로 설치되었다면 다음과 같은 메시지가 나타납니다.

"aws-cli/2.13.25 Python/3.11.5 Darwin/22.6.0 source/arm64" 여기서 중요한 것은 첫 부분의 버전 번호입니다. 2.x.x로 시작한다면 성공입니다.

만약 1.x.x가 나온다면 버전 1이 설치된 것이므로 다시 설치해야 합니다. 실무에서의 활용 회사에서는 보통 여러 대의 서버에 AWS CLI를 설치해야 하는 경우가 많습니다.

한 대씩 접속해서 설치하는 것은 비효율적입니다. 이럴 때는 설치 스크립트를 작성해서 Ansible이나 Chef 같은 자동화 도구로 일괄 설치합니다.

김개발 씨의 팀에서는 도커 이미지를 만들 때 AWS CLI를 포함시킵니다. 이렇게 하면 컨테이너 안에서도 AWS 서비스를 제어할 수 있습니다.

CI/CD 파이프라인에서 자동 배포할 때 특히 유용합니다. 주의할 점 초보자들이 자주 하는 실수 중 하나는 PATH 설정을 확인하지 않는 것입니다.

AWS CLI가 설치되어도 시스템이 그 위치를 모르면 명령어를 인식하지 못합니다. which aws 명령으로 설치 경로를 확인할 수 있습니다.

또 다른 실수는 버전 1과 버전 2를 동시에 설치하는 것입니다. 이렇게 되면 어떤 버전이 실행될지 예측하기 어렵습니다.

버전 1이 이미 설치되어 있다면 제거하고 버전 2만 사용하세요. 정리 김개발 씨는 무사히 AWS CLI 설치를 마쳤습니다.

aws --version 명령으로 확인해보니 버전 2.13.25가 설치되어 있습니다. "생각보다 간단하네요!" 김개발 씨가 환하게 웃습니다.

설치는 AWS CLI를 사용하기 위한 첫 걸음입니다. 한 번만 제대로 설치해두면 계속 사용할 수 있습니다.

이제 다음 단계인 자격 증명 설정으로 넘어가 봅시다.

실전 팁

💡 - Homebrew 사용자는 brew upgrade awscli로 쉽게 업데이트할 수 있습니다

• 도커를 사용한다면 공식 AWS CLI 이미지를 활용하세요
• 회사 프록시 환경에서는 프록시 설정이 필요할 수 있습니다

---

3. 자격 증명 설정

AWS CLI 설치를 마친 김개발 씨는 신이 나서 aws s3 ls 명령을 입력해봅니다. 하지만 예상과 달리 에러 메시지가 나타납니다.

"Unable to locate credentials." 자격 증명을 찾을 수 없다는 뜻입니다. 당황한 김개발 씨에게 박시니어 씨가 설명합니다.

"AWS CLI가 여러분의 계정에 접근하려면 먼저 인증이 필요해요. 마치 은행 앱에서 로그인하는 것처럼요."

자격 증명 설정은 AWS CLI가 여러분의 AWS 계정에 안전하게 접근할 수 있도록 하는 과정입니다. IAM에서 발급받은 액세스 키와 시크릿 키를 등록해야 하며, aws configure 명령으로 간단하게 설정할 수 있습니다.

이것은 마치 집 현관문의 비밀번호를 입력하는 것과 같습니다.

다음 코드를 살펴봅시다.

# 자격 증명 설정 - 대화형으로 입력받습니다
aws configure

# 입력 예시:
# AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
# AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
# Default region name [None]: ap-northeast-2
# Default output format [None]: json

# 설정 확인
aws configure list

# 특정 프로필로 설정 (여러 계정 사용 시)
aws configure --profile work
aws configure --profile personal

# 프로필 사용하기
aws s3 ls --profile work

김개발 씨는 혼란스럽습니다. 분명히 AWS CLI를 설치했는데 왜 사용할 수 없는 걸까요?

박시니어 씨가 비유를 들어 설명합니다. "생각해보세요.

은행 ATM기에 카드를 넣으면 비밀번호를 입력하라고 하잖아요. AWS CLI도 마찬가지예요.

설치만 했다고 끝이 아니라, 여러분이 누구인지 증명해야 합니다. 그게 바로 자격 증명이에요." 자격 증명이란 무엇인가요? 자격 증명은 여러분이 정당한 사용자임을 증명하는 정보입니다.

AWS에서는 두 가지 키를 사용합니다. 액세스 키 ID와 시크릿 액세스 키입니다.

이것은 마치 아이디와 비밀번호 같은 것입니다. 액세스 키 ID는 공개되어도 괜찮지만, 시크릿 액세스 키는 절대로 외부에 노출되면 안 됩니다.

누군가 여러분의 시크릿 키를 알게 되면 여러분의 AWS 계정에 무단으로 접근할 수 있기 때문입니다. IAM에서 키 발급받기 그렇다면 이 키는 어디서 얻을 수 있을까요?

AWS의 IAM(Identity and Access Management) 서비스에서 발급받을 수 있습니다. AWS 콘솔에 로그인한 다음, IAM 서비스로 이동합니다.

왼쪽 메뉴에서 "사용자"를 클릭하고, 본인 계정을 선택합니다. "보안 자격 증명" 탭에서 "액세스 키 만들기" 버튼을 클릭하면 새로운 키가 생성됩니다.

중요한 점이 있습니다. 시크릿 액세스 키는 생성할 때 딱 한 번만 볼 수 있습니다.

창을 닫으면 다시는 확인할 수 없으므로 반드시 안전한 곳에 저장해두어야 합니다. 만약 잊어버렸다면 기존 키를 삭제하고 새로 만들어야 합니다.

aws configure 명령으로 설정하기 키를 발급받았다면 이제 설정할 차례입니다. 터미널을 열고 aws configure라고 입력하세요.

그러면 대화형으로 네 가지 정보를 입력받습니다. 첫 번째는 AWS Access Key ID입니다.

IAM에서 발급받은 액세스 키를 복사해서 붙여넣으세요. 두 번째는 AWS Secret Access Key입니다.

마찬가지로 시크릿 키를 입력합니다. 세 번째는 Default region name입니다.

여기에는 주로 사용할 AWS 리전을 입력합니다. 한국에서 서비스한다면 ap-northeast-2를 입력하면 됩니다.

이것은 서울 리전을 의미합니다. 네 번째는 Default output format입니다.

명령 결과를 어떤 형식으로 보여줄지 정하는 것입니다. json, yaml, text, table 중에서 선택할 수 있습니다.

대부분 json을 사용합니다. 설정 파일은 어디에 저장되나요? 입력한 정보는 어디에 저장될까요?

홈 디렉터리의 .aws 폴더 안에 저장됩니다. 맥이나 리눅스에서는 ~/.aws/credentials와 ~/.aws/config 파일입니다.

윈도우에서는 C:\Users\사용자명\.aws\ 폴더입니다. 직접 이 파일을 열어보면 입력한 내용이 텍스트로 저장되어 있습니다.

필요하다면 텍스트 에디터로 직접 수정할 수도 있지만, 가급적 aws configure 명령을 사용하는 것이 안전합니다. 여러 계정 사용하기 - 프로필 회사 계정과 개인 계정을 따로 사용하는 경우가 있습니다.

이럴 때는 프로필 기능을 사용합니다. aws configure --profile work라고 입력하면 "work"라는 이름의 프로필을 만들 수 있습니다.

마찬가지로 aws configure --profile personal로 개인 계정 프로필도 만듭니다. 이렇게 설정한 후에는 명령어 실행 시 --profile 옵션으로 어떤 계정을 사용할지 지정할 수 있습니다.

예를 들어 aws s3 ls --profile work라고 하면 회사 계정의 S3 버킷이 조회됩니다. 실무에서의 활용 김개발 씨의 팀에서는 개발 환경, 스테이징 환경, 프로덕션 환경을 각각 다른 AWS 계정으로 관리합니다.

각 환경마다 프로필을 만들어두고 사용합니다. 이렇게 하면 실수로 프로덕션 환경의 데이터를 건드리는 사고를 방지할 수 있습니다.

CI/CD 파이프라인에서는 보통 환경 변수로 자격 증명을 설정합니다. AWS_ACCESS_KEY_ID와 AWS_SECRET_ACCESS_KEY 환경 변수를 설정하면 aws configure 없이도 작동합니다.

깃허브 액션이나 젠킨스에서 이런 방식을 많이 사용합니다. 보안 주의사항 자격 증명을 다룰 때 가장 중요한 것은 보안입니다.

절대로 깃허브 같은 공개 저장소에 키를 업로드하면 안 됩니다. 실수로 올렸다가 몇 분 만에 해킹당한 사례도 있습니다.

또한 루트 계정의 액세스 키는 절대 사용하지 마세요. 반드시 IAM 사용자를 만들어서 필요한 권한만 부여하세요.

이것을 최소 권한 원칙이라고 합니다. 정리 김개발 씨는 IAM에서 키를 발급받고, aws configure 명령으로 설정을 마쳤습니다.

이제 다시 aws s3 ls를 입력해봅니다. 이번에는 정상적으로 S3 버킷 목록이 나타납니다.

"드디어 되네요!" 김개발 씨가 기쁨에 찬 목소리로 외칩니다. 자격 증명 설정은 AWS CLI를 사용하기 위한 필수 단계입니다.

한 번만 제대로 설정해두면 계속 사용할 수 있습니다. 이제 본격적으로 AWS CLI 명령어를 배워봅시다.

실전 팁

💡 - 시크릿 키는 절대로 깃에 커밋하지 마세요 - .gitignore에 .aws 폴더를 추가하세요

• 정기적으로 액세스 키를 교체하는 것이 보안상 좋습니다
• MFA(다중 인증)를 활성화하면 더욱 안전합니다

---

4. 기본 명령어 실습

자격 증명 설정까지 마친 김개발 씨는 이제 실전 명령어를 배울 준비가 되었습니다. 하지만 AWS 서비스가 워낙 많다 보니 어디서부터 시작해야 할지 막막합니다.

박시니어 씨가 조언합니다. "처음에는 모든 명령어의 공통 패턴부터 익히세요.

그러면 어떤 서비스든 쉽게 사용할 수 있어요."

AWS CLI의 모든 명령어는 일관된 구조를 가지고 있습니다. aws [서비스] [명령] [옵션] 형식으로 이루어지며, 헬프 기능과 필터링, 출력 형식 지정 등 공통 옵션을 제공합니다.

이 기본 패턴만 익히면 수백 개의 명령어를 쉽게 이해할 수 있습니다.

다음 코드를 살펴봅시다.

# 헬프 보기 - 모든 서비스 목록
aws help

# 특정 서비스의 헬프 보기
aws s3 help
aws ec2 help

# 특정 명령어의 상세 헬프
aws s3 cp help

# JSON 출력 결과를 보기 좋게 포맷팅
aws ec2 describe-instances --output json | jq '.'

# 테이블 형식으로 출력
aws ec2 describe-instances --output table

# 특정 필드만 추출 (--query 사용)
aws ec2 describe-instances --query 'Reservations[*].Instances[*].[InstanceId,State.Name]' --output text

# 여러 리전의 리소스 조회
aws ec2 describe-instances --region us-east-1
aws ec2 describe-instances --region ap-northeast-2

김개발 씨는 AWS CLI를 사용할 준비가 되었지만, 막상 어떤 명령어를 사용해야 할지 모르겠습니다. AWS 서비스만 해도 수백 개인데, 각각의 명령어를 다 외워야 할까요?

박시니어 씨가 웃으며 말합니다. "걱정 마세요.

AWS CLI는 모든 명령어가 같은 규칙을 따라요. 이 규칙만 이해하면 나머지는 저절로 따라옵니다." 명령어의 기본 구조 AWS CLI 명령어는 항상 동일한 패턴을 따릅니다.

마치 영어 문장이 주어-동사-목적어 순서를 따르는 것처럼 말이죠. aws [서비스] [명령] [옵션] 첫 번째는 항상 aws로 시작합니다.

이것은 "지금부터 AWS CLI 명령을 실행할 거야"라고 선언하는 것입니다. 두 번째는 서비스 이름입니다.

s3, ec2, lambda 같은 것들이죠. 세 번째는 명령어입니다.

ls, cp, describe-instances 등이 있습니다. 예를 들어 aws s3 ls라는 명령어를 분석해봅시다.

aws는 AWS CLI를 뜻하고, s3는 S3 서비스를, ls는 목록을 보여달라는 명령입니다. 영어로 읽으면 "AWS야, S3 서비스의 목록을 보여줘"가 됩니다.

헬프는 여러분의 친구 모든 명령어를 외울 필요는 없습니다. AWS CLI에는 강력한 헬프 기능이 내장되어 있습니다.

aws help라고 입력하면 사용 가능한 모든 서비스 목록이 나타납니다. aws s3 help라고 하면 S3 서비스에서 사용할 수 있는 모든 명령어가 나옵니다.

aws s3 cp help라고 하면 cp 명령어의 상세한 설명과 예제를 볼 수 있습니다. 헬프 화면은 맨 페이저로 표시됩니다.

스페이스바로 다음 페이지로 넘어가고, q 키를 누르면 종료됩니다. 처음에는 조금 불편할 수 있지만, 익숙해지면 구글 검색보다 빠르게 원하는 정보를 찾을 수 있습니다.

출력 형식 지정하기 AWS CLI는 기본적으로 JSON 형식으로 결과를 보여줍니다. JSON은 구조화된 데이터를 표현하기 좋지만, 사람이 읽기에는 불편할 수 있습니다.

--output 옵션으로 출력 형식을 바꿀 수 있습니다. --output table을 사용하면 깔끔한 표 형식으로 보여줍니다.

--output text를 사용하면 탭으로 구분된 텍스트로 출력되어 쉘 스크립트에서 파싱하기 좋습니다. JSON 출력을 더 보기 좋게 만들려면 jq라는 도구를 함께 사용할 수 있습니다.

jq는 JSON 데이터를 처리하는 커맨드라인 도구입니다. 파이프로 연결해서 | jq '.'라고 하면 색상이 들어간 보기 좋은 형식으로 출력됩니다.

쿼리로 필요한 데이터만 추출하기 EC2 인스턴스 정보를 조회하면 엄청나게 많은 데이터가 나옵니다. 하지만 우리가 필요한 것은 인스턴스 ID와 상태 정도일 수 있습니다.

이럴 때 --query 옵션을 사용합니다. --query는 JMESPath라는 쿼리 언어를 사용합니다.

SQL처럼 원하는 필드만 선택할 수 있습니다. 예를 들어 --query 'Reservations[*].Instances[*].[InstanceId,State.Name]'라고 하면 인스턴스 ID와 상태만 추출됩니다.

처음에는 쿼리 문법이 어렵게 느껴질 수 있습니다. 하지만 몇 번 사용하다 보면 패턴이 보입니다.

대괄호 []는 배열을 의미하고, 점 .은 객체의 속성을 의미합니다. [*]는 모든 요소를 뜻합니다.

리전 지정하기 AWS는 전 세계에 여러 리전을 운영합니다. 서울, 도쿄, 버지니아, 오하이오 등등.

리소스는 특정 리전에 속해 있습니다. aws configure로 기본 리전을 설정했지만, 다른 리전의 리소스를 조회하고 싶을 때가 있습니다.

이럴 때는 --region 옵션을 사용합니다. 예를 들어 aws ec2 describe-instances --region us-east-1이라고 하면 미국 동부 리전의 EC2 인스턴스를 조회합니다.

글로벌 서비스를 운영한다면 여러 리전의 리소스를 확인해야 하므로 자주 사용하는 옵션입니다. 실무에서의 활용 김개발 씨의 팀에서는 매일 아침 모든 리전의 EC2 인스턴스를 확인하는 스크립트를 실행합니다.

각 리전마다 --region 옵션을 바꿔가며 조회하고, --query로 필요한 정보만 추출하고, --output table로 보기 좋게 표시합니다. 또한 에러가 발생했을 때는 --debug 옵션을 사용합니다.

이 옵션을 켜면 내부적으로 어떤 API 호출이 일어나는지 상세하게 볼 수 있습니다. 문제를 해결하는 데 큰 도움이 됩니다.

자주 사용하는 공통 옵션 모든 명령어에서 사용할 수 있는 옵션들이 있습니다. --dry-run은 실제로 실행하지 않고 검증만 합니다.

실수로 중요한 리소스를 삭제하는 것을 방지할 수 있습니다. --no-cli-pager는 출력을 페이저 없이 바로 표시합니다.

스크립트에서 사용할 때 유용합니다. --profile은 앞서 배운 것처럼 특정 프로필을 사용합니다.

--color on/off는 출력에 색상을 넣거나 뺍니다. 정리 박시니어 씨가 정리합니다.

"보셨죠? 명령어가 많아 보여도 패턴은 동일해요.

서비스 이름만 바꾸면 되는 거예요." 김개발 씨는 이제 자신감이 생겼습니다. "아, 이렇게 보니까 간단하네요.

헬프 기능도 있고, 쿼리로 필요한 것만 뽑아낼 수도 있고!" AWS CLI의 기본 패턴을 익혔다면 이제 구체적인 서비스별 명령어를 배울 차례입니다. 가장 많이 사용하는 S3부터 시작해봅시다.

실전 팁

💡 - jq 도구를 설치해두면 JSON 처리가 훨씬 편해집니다

• 자주 사용하는 쿼리는 쉘 별칭으로 저장해두세요
• --dry-run으로 항상 먼저 테스트하는 습관을 들이세요

---

5. S3 CLI 명령어

김개발 씨가 가장 먼저 배우고 싶은 것은 S3입니다. 회사에서 매일 S3에 파일을 올리고 다운로드하는데, 웹 콘솔에서 하려니 너무 번거롭기 때문입니다.

특히 파일이 수백 개일 때는 하나하나 클릭하는 것이 고역입니다. 박시니어 씨가 말합니다.

"S3는 AWS CLI로 제어하기 가장 쉬운 서비스 중 하나예요. 거의 일반 파일 시스템처럼 사용할 수 있거든요."

S3 CLI 명령어는 파일 시스템과 유사한 방식으로 작동합니다. ls로 목록을 보고, cp로 복사하고, mv로 이동하고, rm으로 삭제합니다.

로컬 파일을 S3로 업로드하거나, S3 파일을 로컬로 다운로드하는 작업을 명령어 한 줄로 처리할 수 있습니다.

다음 코드를 살펴봅시다.

# S3 버킷 목록 조회
aws s3 ls

# 특정 버킷 내부 파일 목록
aws s3 ls s3://my-bucket/

# 폴더 내부까지 재귀적으로 조회
aws s3 ls s3://my-bucket/logs/ --recursive

# 로컬 파일을 S3로 업로드
aws s3 cp myfile.txt s3://my-bucket/

# S3 파일을 로컬로 다운로드
aws s3 cp s3://my-bucket/myfile.txt ./

# 폴더 전체를 동기화 (변경된 파일만 업로드)
aws s3 sync ./my-folder s3://my-bucket/backup/

# 파일 삭제
aws s3 rm s3://my-bucket/old-file.txt

# 버킷 생성
aws s3 mb s3://my-new-bucket

# 버킷 삭제 (비어있어야 함)
aws s3 rb s3://my-old-bucket

김개발 씨는 매주 월요일마다 로그 파일을 S3에 백업합니다. 파일이 수백 개인데, 웹 콘솔에서 하나씩 드래그 앤 드롭하려니 시간이 너무 오래 걸립니다.

게다가 중간에 실수로 창을 닫으면 처음부터 다시 해야 합니다. 박시니어 씨가 김개발 씨의 화면을 보더니 말합니다.

"그렇게 하지 마세요. AWS CLI로 하면 명령어 한 줄이면 끝나는데요." S3는 왜 특별한가? S3는 AWS에서 가장 많이 사용되는 서비스 중 하나입니다.

파일을 저장하는 객체 스토리지 서비스죠. 사진, 동영상, 백업 파일, 로그, 정적 웹사이트 등 거의 모든 종류의 파일을 저장할 수 있습니다.

AWS CLI에서 S3는 특별한 대우를 받습니다. 일반적인 파일 시스템처럼 사용할 수 있도록 간편한 명령어를 제공하기 때문입니다.

리눅스나 맥에서 사용하는 ls, cp, mv, rm 같은 명령어를 그대로 사용할 수 있습니다. 버킷과 객체 이해하기 S3에서는 버킷과 객체라는 개념을 사용합니다.

버킷은 파일을 담는 최상위 컨테이너입니다. 컴퓨터의 드라이브나 폴더와 비슷하다고 생각하면 됩니다.

객체는 실제 파일을 의미합니다. 버킷 이름은 전 세계에서 유일해야 합니다.

다른 누군가가 "my-bucket"이라는 이름을 이미 사용하고 있다면 여러분은 사용할 수 없습니다. 따라서 보통 회사 이름이나 프로젝트 이름을 접두사로 붙입니다.

파일 목록 보기 - ls 가장 기본적인 명령어는 aws s3 ls입니다. 이것은 현재 계정에 있는 모든 버킷의 목록을 보여줍니다.

특정 버킷 안의 파일을 보려면 aws s3 ls s3://버킷이름/이라고 입력합니다. 여기서 주의할 점은 s3://라는 프로토콜을 붙여야 한다는 것입니다.

이것은 "S3에 있는 리소스야"라고 알려주는 표시입니다. 폴더 구조가 깊다면 --recursive 옵션을 사용하세요.

그러면 하위 폴더까지 모두 탐색해서 모든 파일을 보여줍니다. 리눅스의 ls -R 명령어와 같습니다.

파일 복사하기 - cp 파일을 업로드하거나 다운로드할 때는 cp 명령어를 사용합니다. 마치 로컬 파일 시스템에서 파일을 복사하는 것과 동일합니다.

로컬에서 S3로 업로드하려면 aws s3 cp 로컬파일경로 s3://버킷/경로라고 입력합니다. 반대로 S3에서 로컬로 다운로드하려면 순서만 바꾸면 됩니다.

폴더 전체를 복사하려면 --recursive 옵션을 추가합니다. 그러면 폴더 안의 모든 파일과 하위 폴더가 통째로 복사됩니다.

동기화하기 - sync sync 명령어는 매우 유용합니다. 로컬 폴더와 S3 버킷을 동기화해줍니다.

마치 드롭박스나 구글 드라이브처럼 변경된 파일만 자동으로 업로드합니다. 예를 들어 aws s3 sync ./backup s3://my-bucket/backup/이라고 하면, backup 폴더의 내용을 S3와 동기화합니다.

이미 업로드된 파일은 건너뛰고, 새로 추가되거나 수정된 파일만 업로드합니다. 이것은 백업 자동화에 특히 유용합니다.

크론 작업으로 매일 밤 sync 명령을 실행하면, 자동으로 증분 백업이 이루어집니다. 파일 삭제하기 - rm 필요 없는 파일을 삭제하려면 rm 명령어를 사용합니다.

aws s3 rm s3://버킷/파일경로라고 입력하면 됩니다. 폴더 전체를 삭제하려면 역시 --recursive 옵션을 붙입니다.

하지만 주의하세요. 삭제된 파일은 복구할 수 없습니다.

버저닝을 활성화하지 않았다면 영원히 사라집니다. 버킷 만들고 삭제하기 새로운 버킷을 만들려면 mb 명령어를 사용합니다.

"make bucket"의 약자입니다. aws s3 mb s3://새버킷이름이라고 입력하면 버킷이 생성됩니다.

버킷을 삭제하려면 rb 명령어를 사용합니다. "remove bucket"의 약자죠.

하지만 버킷이 비어있어야만 삭제할 수 있습니다. 파일이 있다면 먼저 모두 삭제해야 합니다.

실무에서의 활용 김개발 씨의 팀에서는 빌드 결과물을 S3에 자동으로 업로드하는 CI/CD 파이프라인을 운영합니다. 젠킨스나 깃허브 액션에서 빌드가 끝나면 aws s3 sync 명령으로 결과물을 S3에 올립니다.

또한 매일 밤 데이터베이스 덤프 파일을 S3에 백업합니다. 쉘 스크립트에 aws s3 cp 명령을 넣어두고, 크론으로 자동 실행합니다.

덤프 파일 이름에 날짜를 붙여서 매일의 백업을 따로 보관합니다. 로그 분석 작업을 할 때는 S3에서 로그 파일을 다운로드하고, 로컬에서 분석한 다음, 결과를 다시 S3에 업로드합니다.

이 모든 과정이 스크립트 한 줄로 처리됩니다. 고급 옵션 S3 CLI는 다양한 고급 옵션을 제공합니다.

--acl 옵션으로 접근 권한을 설정할 수 있고, --storage-class 옵션으로 스토리지 클래스를 지정할 수 있습니다. 자주 접근하지 않는 파일은 Glacier로 보내서 비용을 절감할 수 있습니다.

--exclude와 --include 옵션으로 특정 패턴의 파일만 선택할 수도 있습니다. 예를 들어 로그 파일만 업로드하고 싶다면 --include "*.log"라고 하면 됩니다.

주의사항 S3는 사용한 만큼 비용이 발생합니다. 저장 용량과 데이터 전송량에 따라 과금됩니다.

불필요한 파일은 정기적으로 삭제하고, 생명주기 정책을 설정해서 오래된 파일을 자동으로 삭제하거나 아카이브하세요. 또한 퍼블릭 액세스를 조심하세요.

실수로 버킷을 퍼블릭으로 설정하면 누구나 파일을 다운로드할 수 있습니다. 개인정보나 중요한 데이터가 유출될 수 있으므로 ACL 설정을 항상 확인하세요.

정리 김개발 씨는 이제 S3 CLI를 능숙하게 사용합니다. 수백 개의 로그 파일을 업로드하는 작업이 명령어 한 줄로 끝납니다.

"진작 배울걸 그랬어요!" 김개발 씨가 후회 섞인 목소리로 말합니다. S3 CLI는 AWS CLI 중에서도 가장 자주 사용하는 명령어입니다.

익숙해지면 파일 관리 작업의 생산성이 크게 향상됩니다. 다음은 EC2 CLI 명령어를 배워봅시다.

실전 팁

💡 - S3 버킷 이름에는 회사나 프로젝트 접두사를 붙이세요

• sync 명령어에 --delete 옵션을 추가하면 원본에 없는 파일을 삭제합니다
• 대용량 파일은 멀티파트 업로드로 자동 처리됩니다

---

6. EC2 CLI 명령어

S3 마스터가 된 김개발 씨는 이제 EC2 CLI를 배우고 싶어졌습니다. 회사에서 운영 중인 EC2 인스턴스가 수십 개인데, 상태를 확인하고 시작하고 중지하는 작업이 반복됩니다.

특히 개발 환경의 인스턴스는 퇴근할 때 중지하고 출근하면 다시 시작해야 비용을 절약할 수 있습니다. 박시니어 씨가 말합니다.

"EC2 CLI를 쓰면 인스턴스를 코드로 관리할 수 있어요. 자동화의 핵심이죠."

EC2 CLI 명령어는 가상 서버 인스턴스를 관리하는 도구입니다. 인스턴스 목록 조회, 시작, 중지, 재부팅, 상태 확인 등의 작업을 수행할 수 있습니다.

S3보다 복잡하지만, 쿼리와 필터를 활용하면 원하는 정보를 정확하게 추출할 수 있습니다.

다음 코드를 살펴봅시다.

# 모든 EC2 인스턴스 조회
aws ec2 describe-instances

# 실행 중인 인스턴스만 조회
aws ec2 describe-instances --filters "Name=instance-state-name,Values=running"

# 특정 태그를 가진 인스턴스 조회
aws ec2 describe-instances --filters "Name=tag:Environment,Values=production"

# 인스턴스 ID와 상태만 간단히 출력
aws ec2 describe-instances --query 'Reservations[*].Instances[*].[InstanceId,State.Name,PublicIpAddress,Tags[?Key==`Name`].Value|[0]]' --output table

# 인스턴스 시작
aws ec2 start-instances --instance-ids i-1234567890abcdef0

# 인스턴스 중지
aws ec2 stop-instances --instance-ids i-1234567890abcdef0

# 인스턴스 재부팅
aws ec2 reboot-instances --instance-ids i-1234567890abcdef0

# 인스턴스 종료 (삭제)
aws ec2 terminate-instances --instance-ids i-1234567890abcdef0

# 보안 그룹 목록 조회
aws ec2 describe-security-groups

김개발 씨의 팀은 개발, 스테이징, 프로덕션 환경을 각각 별도의 EC2 인스턴스에서 운영합니다. 총 15대의 인스턴스가 있는데, 개발 환경 인스턴스 5대는 평일 오전 9시에 시작하고 오후 6시에 중지해야 합니다.

주말에는 아예 꺼두어야 합니다. 김개발 씨는 매일 아침 출근하면 AWS 콘솔에 접속해서 인스턴스를 하나하나 체크하고 시작 버튼을 클릭합니다.

퇴근할 때도 마찬가지로 중지합니다. 한두 번은 괜찮지만, 매일 반복하다 보니 지겹습니다.

게다가 잊어버리는 날도 있습니다. EC2란 무엇인가? EC2는 Elastic Compute Cloud의 약자입니다.

클라우드에서 실행되는 가상 서버입니다. 여러분이 원하는 사양의 컴퓨터를 몇 분 만에 만들어서 사용할 수 있습니다.

마치 컴퓨터를 렌트하는 것과 같습니다. 필요할 때 빌려 쓰고, 필요 없으면 반납합니다.

사용한 시간만큼만 비용을 지불하므로 효율적입니다. 인스턴스 목록 조회하기 가장 기본적인 명령어는 aws ec2 describe-instances입니다.

현재 계정의 모든 EC2 인스턴스 정보를 보여줍니다. 하지만 그냥 실행하면 정보가 너무 많이 나옵니다.

JSON 형식으로 수백 줄이 출력됩니다. 인스턴스 ID, 타입, 상태, IP 주소, 보안 그룹, 태그 등 모든 정보가 포함되기 때문입니다.

실무에서는 보통 --query 옵션으로 필요한 정보만 추출합니다. 예를 들어 인스턴스 ID, 상태, IP 주소, 이름 정도만 보고 싶다면 위 코드의 쿼리를 사용합니다.

필터로 원하는 인스턴스만 조회하기 인스턴스가 많을 때는 필터 기능이 유용합니다. --filters 옵션으로 조건에 맞는 인스턴스만 선택할 수 있습니다.

예를 들어 실행 중인 인스턴스만 보려면 --filters "Name=instance-state-name,Values=running"이라고 합니다. 중지된 인스턴스를 보려면 Values=stopped로 바꾸면 됩니다.

태그로 필터링하는 것도 가능합니다. 회사에서는 보통 Environment, Team, Service 같은 태그를 붙여서 인스턴스를 분류합니다.

--filters "Name=tag:Environment,Values=production"이라고 하면 프로덕션 환경의 인스턴스만 조회됩니다. 인스턴스 시작하고 중지하기 인스턴스를 시작하려면 start-instances 명령어를 사용합니다.

--instance-ids 옵션에 인스턴스 ID를 지정합니다. 여러 개를 동시에 시작하려면 ID를 공백으로 구분해서 나열하면 됩니다.

중지할 때는 stop-instances를 사용합니다. 형식은 동일합니다.

중지된 인스턴스는 디스크 용량에 대해서만 비용이 발생하고, 컴퓨팅 비용은 발생하지 않습니다. 재부팅이 필요할 때는 reboot-instances를 사용합니다.

이것은 운영체제를 재시작하는 것으로, 인스턴스를 중지했다가 다시 시작하는 것과는 다릅니다. IP 주소도 유지됩니다.

인스턴스 종료하기 - 주의! terminate-instances 명령어는 매우 조심해야 합니다. 이것은 인스턴스를 완전히 삭제하는 것입니다.

중지와는 다릅니다. 종료된 인스턴스는 복구할 수 없습니다.

모든 데이터가 사라집니다. EBS 볼륨도 함께 삭제되도록 설정되어 있다면 백업도 없습니다.

따라서 프로덕션 환경에서는 절대로 함부로 사용하면 안 됩니다. 실수를 방지하기 위해 종료 방지 설정을 켜두는 것이 좋습니다.

이 설정이 활성화되면 CLI로도 종료할 수 없습니다. 먼저 웹 콘솔에서 종료 방지를 해제해야 합니다.

태그와 이름 지정 EC2 인스턴스에는 태그를 붙일 수 있습니다. 태그는 키-값 쌍으로 이루어진 메타데이터입니다.

예를 들어 Name=WebServer, Environment=Production, Team=Backend 같은 식입니다. 특히 Name 태그는 중요합니다.

웹 콘솔에서 인스턴스 목록에 표시되는 이름이 바로 이 Name 태그의 값입니다. CLI로 조회할 때도 Name 태그를 함께 보면 어떤 인스턴스인지 알아보기 쉽습니다.

위의 쿼리 예제를 보면 Tags[?Key==\Name`].Value|[0]`라는 부분이 있습니다. 이것은 태그 중에서 Key가 Name인 것의 Value를 추출하라는 뜻입니다.

JMESPath 문법이 조금 복잡하지만, 한번 익혀두면 계속 재사용할 수 있습니다. 보안 그룹 관리 EC2 인스턴스는 보안 그룹으로 네트워크 접근을 제어합니다.

방화벽과 같은 역할을 합니다. 어떤 포트를 열고, 어떤 IP에서 접속을 허용할지 정의합니다.

aws ec2 describe-security-groups로 보안 그룹 목록을 조회할 수 있습니다. 특정 보안 그룹의 규칙을 수정하려면 authorize-security-group-ingress나 revoke-security-group-ingress 명령을 사용합니다.

예를 들어 SSH 접속을 허용하려면 22번 포트를 여는 규칙을 추가해야 합니다. 웹 서버라면 80번과 443번 포트를 열어야 합니다.

실무에서의 활용 김개발 씨의 팀은 EC2 CLI를 스케줄러와 결합해서 사용합니다. AWS Lambda 함수에 EC2 시작/중지 스크립트를 넣어두고, CloudWatch Events로 스케줄링합니다.

평일 오전 9시에 Lambda가 실행되어 개발 환경 인스턴스를 모두 시작하고, 오후 6시에 다시 Lambda가 실행되어 중지합니다. 모니터링에도 활용합니다.

매 시간마다 모든 인스턴스의 상태를 확인하는 스크립트를 실행하고, 예상치 못하게 중지된 인스턴스가 있으면 슬랙으로 알림을 보냅니다. 오토 스케일링 그룹을 사용할 때도 CLI로 원하는 용량을 조정합니다.

트래픽이 증가할 것으로 예상되면 미리 인스턴스 수를 늘려두고, 트래픽이 줄어들면 다시 줄입니다. 비용 절감 팁 EC2는 사용하지 않을 때 중지하면 비용을 크게 절약할 수 있습니다.

개발 환경이나 테스트 환경은 업무 시간에만 켜두고 나머지 시간에는 끄세요. 또한 예약 인스턴스나 스팟 인스턴스를 활용하면 온디맨드보다 훨씬 저렴합니다.

스팟 인스턴스는 CLI로도 요청할 수 있습니다. 정리 김개발 씨는 이제 EC2 인스턴스를 자유자재로 제어할 수 있습니다.

쉘 스크립트에 몇 줄만 추가하면 매일 반복하던 수작업이 자동화됩니다. "이제 아침마다 인스턴스 켜는 일은 없겠네요!" 김개발 씨가 기뻐합니다.

EC2 CLI를 마스터하면 인프라를 코드로 관리하는 Infrastructure as Code의 세계에 한 걸음 다가갈 수 있습니다. AWS CLI는 이제 여러분의 손에 익었습니다.

이것을 발판 삼아 더 복잡한 자동화와 인프라 관리에 도전해보세요.

실전 팁

💡 - 인스턴스 ID 대신 태그로 필터링하면 스크립트가 더 유연해집니다

• 프로덕션 인스턴스는 종료 방지를 반드시 켜두세요
• CloudWatch Events와 Lambda를 결합하면 완전 자동화가 가능합니다

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!