AWS 환경 설정 완벽 가이드

AWS 계정 생성부터 Bedrock 서비스 활성화, CLI 설정까지 초급 개발자를 위한 단계별 실전 가이드입니다. 실무에서 바로 사용할 수 있는 AWS 환경 구축 노하우를 담았습니다.

1. AWS 계정 생성하기

김개발 씨는 오늘 처음으로 클라우드 서비스를 사용해보기로 했습니다. 선배 개발자 박시니어 씨가 "요즘은 모든 서비스가 클라우드에서 돌아간다"며 AWS 계정부터 만들어보라고 권했습니다.

AWS 계정 생성은 아마존 웹 서비스를 사용하기 위한 첫 번째 단계입니다. 마치 도서관 회원증을 만드는 것처럼, 계정을 만들어야 AWS의 모든 서비스를 이용할 수 있습니다.

이메일 주소와 신용카드만 있으면 누구나 쉽게 시작할 수 있습니다.

다음 코드를 살펴봅시다.

# AWS 계정 생성 후 확인할 수 있는 기본 정보
import boto3

# AWS 계정 ID 확인
sts_client = boto3.client('sts')
account_id = sts_client.get_caller_identity()['Account']

print(f"현재 AWS 계정 ID: {account_id}")

# 사용 가능한 리전 목록 조회
ec2_client = boto3.client('ec2')
regions = ec2_client.describe_regions()

print("사용 가능한 리전:")
for region in regions['Regions']:
    print(f"  - {region['RegionName']}")

김개발 씨는 회사에서 새로운 프로젝트를 맡게 되었습니다. 프로젝트 매니저가 말했습니다.

"이번 프로젝트는 AWS에서 진행합니다. 계정부터 만들어주세요." AWS가 무엇인지는 들어봤지만, 실제로 사용해본 적은 없었습니다.

막연히 어려울 것 같았지만, 박시니어 씨가 옆에서 한 마디 던졌습니다. "걱정하지 마세요.

네이버 회원가입보다 쉬워요." AWS 계정이란 정확히 무엇일까요? 쉽게 비유하자면, AWS 계정은 마치 대형 쇼핑몰의 회원증과 같습니다.

회원증 하나로 쇼핑몰 안의 모든 매장을 이용할 수 있듯이, AWS 계정 하나로 컴퓨팅, 스토리지, 데이터베이스, AI 서비스 등 200개가 넘는 서비스를 사용할 수 있습니다. 계정이 없던 시절에는 어땠을까요?

과거에는 서버를 직접 구매하고 관리해야 했습니다. 서버실을 만들고, 전기 요금을 내고, 24시간 관리 인력을 두어야 했습니다.

작은 스타트업에게는 엄두도 낼 수 없는 일이었습니다. 더 큰 문제는 트래픽이 갑자기 늘어나면 대응할 방법이 없다는 것이었습니다.

바로 이런 문제를 해결하기 위해 클라우드 서비스가 등장했습니다. AWS 계정을 만들면 필요한 만큼만 서버를 빌려 쓸 수 있습니다.

트래픽이 늘어나면 자동으로 서버를 늘리고, 줄어들면 다시 줄일 수 있습니다. 무엇보다 초기 투자 비용 없이 서비스를 시작할 수 있다는 큰 이점이 있습니다.

계정 생성 과정을 단계별로 살펴보겠습니다. 먼저 AWS 공식 웹사이트(aws.amazon.com)에 접속합니다.

오른쪽 상단의 "무료 계정 만들기" 버튼을 클릭하면 됩니다. 이메일 주소와 비밀번호를 입력하면 첫 단계가 완료됩니다.

다음으로 연락처 정보를 입력합니다. 이름, 주소, 전화번호를 정확히 입력해야 합니다.

AWS는 보안을 매우 중요하게 생각하기 때문에 본인 확인 절차가 꼼꼼합니다. 신용카드 정보를 입력하는 단계에서 많은 분들이 걱정하십니다.

"돈이 빠져나가는 거 아닌가요?" 하지만 걱정하지 않아도 됩니다. AWS는 12개월 동안 프리 티어라는 무료 사용 범위를 제공합니다.

정해진 한도 내에서는 한 푼도 내지 않고 서비스를 사용할 수 있습니다. 전화번호 인증을 거치면 계정 생성이 완료됩니다.

보통 5분에서 10분 정도면 모든 과정이 끝납니다. 실제 현업에서는 어떻게 활용할까요?

대부분의 스타트업은 AWS 프리 티어로 서비스를 시작합니다. 초기에는 사용자가 많지 않아 무료 범위 내에서 충분히 운영할 수 있습니다.

서비스가 성장하면서 자연스럽게 유료 플랜으로 전환하게 됩니다. 넷플릭스, 에어비앤비 같은 글로벌 기업들도 모두 AWS에서 시작했습니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 프리 티어 한도를 확인하지 않고 서비스를 마구 켜두는 것입니다.

이렇게 하면 예상치 못한 요금이 청구될 수 있습니다. 따라서 사용하지 않는 서비스는 반드시 종료하고, 예산 알림을 설정해두어야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 안내에 따라 계정을 만든 김개발 씨는 생각보다 간단해서 놀랐습니다.

"정말 회원가입이랑 똑같네요!" AWS 계정은 클라우드 여정의 시작입니다. 오늘 배운 내용을 토대로 직접 계정을 만들어보세요.

새로운 세상이 열릴 것입니다.

실전 팁

💡 - 루트 계정은 절대 일상 업무에 사용하지 마세요. IAM 사용자를 별도로 만들어야 합니다.

MFA(다중 인증)를 반드시 설정하세요. 계정 보안이 훨씬 강화됩니다.
프리 티어 사용량을 모니터링하는 CloudWatch 알림을 설정하세요.

2. IAM 사용자 및 역할 설정

계정을 만든 김개발 씨는 바로 서비스를 사용하려 했습니다. 그런데 박시니어 씨가 다급하게 손을 저었습니다.

"잠깐! 루트 계정으로 직접 작업하면 안 됩니다.

IAM 사용자부터 만들어야 해요."

IAM(Identity and Access Management)은 AWS 리소스에 대한 접근을 안전하게 제어하는 서비스입니다. 마치 회사에서 부서별로 다른 출입 권한을 주는 것처럼, 각 사용자와 서비스에 필요한 권한만 부여할 수 있습니다.

이를 통해 보안을 크게 강화할 수 있습니다.

다음 코드를 살펴봅시다.

# IAM 사용자 정보 조회
import boto3

# IAM 클라이언트 생성
iam = boto3.client('iam')

# 현재 사용자 정보 확인
user = iam.get_user()
print(f"사용자 이름: {user['User']['UserName']}")
print(f"사용자 ARN: {user['User']['Arn']}")

# 사용자에게 부여된 정책 목록 조회
policies = iam.list_attached_user_policies(
    UserName=user['User']['UserName']
)

print("\n부여된 권한:")
for policy in policies['AttachedPolicies']:
    print(f"  - {policy['PolicyName']}")

김개발 씨는 의아했습니다. "제 계정인데 왜 제가 직접 못 쓰나요?" 박시니어 씨가 차분히 설명을 시작했습니다.

"루트 계정은 마치 회사의 마스터 키와 같아요. 모든 문을 열 수 있죠.

만약 이 키를 잃어버리면 어떻게 될까요? 큰일 나겠죠?" IAM이란 정확히 무엇일까요?

쉽게 비유하자면, IAM은 마치 아파트 관리실에서 발급하는 출입증과 같습니다. 입주민은 자기 집만 들어갈 수 있는 카드를, 경비원은 공용 공간만 접근할 수 있는 카드를, 관리소장은 모든 곳을 갈 수 있는 카드를 받습니다.

이처럼 IAM도 사용자마다 필요한 권한만 정확히 부여하는 시스템입니다. IAM이 없던 시절에는 어땠을까요?

모든 개발자가 루트 계정 정보를 공유해야 했습니다. 누가 무엇을 했는지 추적할 수 없었고, 퇴사한 직원의 접근을 차단하기도 어려웠습니다.

더 큰 문제는 실수로 중요한 데이터를 삭제해도 누가 했는지 알 수 없다는 것이었습니다. 바로 이런 문제를 해결하기 위해 IAM이 등장했습니다.

IAM을 사용하면 각 개발자에게 개별 계정을 만들어줄 수 있습니다. 신입 개발자에게는 읽기 권한만, 시니어 개발자에게는 쓰기 권한도 줄 수 있습니다.

무엇보다 모든 작업이 로그로 남아 누가 언제 무엇을 했는지 정확히 추적할 수 있습니다. IAM의 핵심 개념을 살펴보겠습니다.

먼저 **사용자(User)**는 실제 사람이나 애플리케이션을 의미합니다. 김개발 씨처럼 개별 개발자마다 하나씩 만듭니다.

다음으로 **그룹(Group)**은 비슷한 권한을 가진 사용자들의 모임입니다. 개발팀, 운영팀처럼 팀 단위로 그룹을 만들면 관리가 쉬워집니다.

**정책(Policy)**은 실제 권한을 정의하는 JSON 문서입니다. "EC2 인스턴스를 시작할 수 있다", "S3 버킷을 읽을 수 있다" 같은 구체적인 권한을 명시합니다.

가장 중요한 개념이 **역할(Role)**입니다. 역할은 사람이 아닌 서비스에게 부여하는 임시 권한입니다.

예를 들어 EC2 인스턴스가 S3에 접근해야 할 때, 인스턴스에 역할을 부여하면 됩니다. 비밀번호를 코드에 하드코딩할 필요가 없어집니다.

실제 현업에서는 어떻게 활용할까요? 대부분의 회사는 최소 권한 원칙을 따릅니다.

처음에는 아무 권한도 주지 않고, 필요한 것만 하나씩 추가합니다. 예를 들어 데이터 분석가에게는 RDS 읽기 권한만 주고, 백엔드 개발자에게는 Lambda와 API Gateway 권한을 줍니다.

또한 역할 기반 접근 제어를 적극 활용합니다. 개발 환경, 스테이징 환경, 프로덕션 환경마다 다른 역할을 만들어 분리합니다.

주니어 개발자는 개발 환경만, 시니어는 모든 환경에 접근할 수 있게 합니다. 하지만 주의할 점도 있습니다.

초보자들이 가장 많이 하는 실수는 AdministratorAccess 정책을 모든 사용자에게 부여하는 것입니다. 이렇게 하면 IAM을 쓰는 의미가 없습니다.

따라서 반드시 업무에 필요한 최소한의 권한만 부여해야 합니다. 또 다른 실수는 액세스 키를 코드에 직접 쓰는 것입니다.

GitHub에 올린 코드에서 액세스 키가 노출되면, 전 세계 해커들이 여러분의 AWS 계정으로 비트코인을 채굴할 수 있습니다. 실제로 이런 사고가 매일 발생합니다.

김개발 씨는 박시니어 씨의 설명을 듣고 고개를 끄덕였습니다. "보안이 이렇게 중요한 줄 몰랐어요." 바로 자신의 IAM 사용자를 만들고, 개발팀 그룹에 추가했습니다.

IAM을 제대로 설정하면 보안 사고를 미연에 방지할 수 있습니다. 처음에는 복잡해 보이지만, 한 번 익혀두면 평생 써먹을 수 있는 지식입니다.

실전 팁

💡 - MFA를 모든 IAM 사용자에게 강제로 설정하세요. 비밀번호만으로는 부족합니다.

액세스 키는 90일마다 교체하는 정책을 만드세요. 오래된 키는 보안 위험입니다.
AWS Organizations를 사용하면 여러 AWS 계정을 중앙에서 관리할 수 있습니다.

3. Bedrock 서비스 활성화

IAM 설정을 마친 김개발 씨는 이제 본격적으로 AI 서비스를 사용해보고 싶었습니다. 회사에서 챗봇을 만들어보라는 과제를 받았기 때문입니다.

박시니어 씨가 추천했습니다. "AWS Bedrock을 써보세요.

요즘 가장 핫한 서비스예요."

AWS Bedrock은 파운데이션 모델(FM)을 API로 쉽게 사용할 수 있게 해주는 완전 관리형 서비스입니다. 마치 렌터카를 빌리듯이, AI 모델을 직접 훈련하지 않고도 Claude, Llama 같은 최신 모델을 바로 사용할 수 있습니다.

복잡한 인프라 관리 없이 AI 기능을 애플리케이션에 추가할 수 있습니다.

다음 코드를 살펴봅시다.

# Bedrock 서비스 활성화 확인 및 사용 가능한 모델 조회
import boto3
import json

# Bedrock 클라이언트 생성
bedrock = boto3.client('bedrock', region_name='us-east-1')

# 사용 가능한 파운데이션 모델 목록 조회
models = bedrock.list_foundation_models()

print("사용 가능한 Bedrock 모델:")
for model in models['modelSummaries']:
    print(f"  - {model['modelName']}")
    print(f"    모델 ID: {model['modelId']}")
    print(f"    제공사: {model['providerName']}")
    print()

김개발 씨는 AI에 대해 들어는 봤지만, 직접 사용해본 적은 없었습니다. "AI 모델을 훈련시키려면 엄청난 컴퓨터와 데이터가 필요하지 않나요?" 걱정스러운 목소리로 물었습니다.

박시니어 씨가 웃으며 대답했습니다. "옛날 이야기예요.

이제는 이미 훈련된 모델을 빌려 쓰면 됩니다." AWS Bedrock이란 정확히 무엇일까요? 쉽게 비유하자면, Bedrock은 마치 음악 스트리밍 서비스와 같습니다.

직접 CD를 사거나 음원을 다운로드하지 않아도, 멜론이나 스포티파이에서 바로 음악을 들을 수 있습니다. 이처럼 Bedrock도 AI 모델을 직접 만들지 않아도, API 호출 한 번으로 최신 AI의 능력을 쓸 수 있게 해줍니다.

Bedrock이 없던 시절에는 어땠을까요? AI 모델을 사용하려면 직접 서버에 설치하고 관리해야 했습니다.

GPU 서버를 구매하고, 모델 파일을 다운로드하고, 버전 관리를 하고, 트래픽에 맞춰 스케일링도 직접 처리해야 했습니다. 작은 스타트업에게는 불가능한 일이었습니다.

더 큰 문제는 모델이 너무 빨리 발전한다는 것이었습니다. 겨우 GPT-3를 설치했는데 GPT-4가 나오면, 다시 처음부터 설치 작업을 해야 했습니다.

시간과 비용이 엄청나게 낭비되었습니다. 바로 이런 문제를 해결하기 위해 AWS Bedrock이 등장했습니다.

Bedrock을 사용하면 Anthropic의 Claude, Meta의 Llama, Stability AI의 Stable Diffusion 같은 최신 모델을 API로 바로 쓸 수 있습니다. 서버 관리, 모델 업데이트, 스케일링이 모두 자동으로 처리됩니다.

무엇보다 사용한 만큼만 비용을 내는 종량제 방식이라 초기 투자가 필요 없습니다. Bedrock 활성화 과정을 단계별로 살펴보겠습니다.

먼저 AWS 콘솔에 로그인한 후 Bedrock 서비스를 검색합니다. 아직 한국 리전에서는 제공되지 않으므로, 오른쪽 상단에서 리전을 us-east-1(버지니아 북부)이나 us-west-2(오레곤)로 변경해야 합니다.

Bedrock 대시보드에 들어가면 "Get started" 버튼이 보입니다. 클릭하면 서비스가 자동으로 활성화됩니다.

별도의 설정이 필요 없어 매우 간단합니다. 왼쪽 메뉴에서 "Model access"를 선택하면 사용 가능한 모델 목록이 나타납니다.

Claude 3 Sonnet, Claude 3 Haiku, Llama 2, Titan 등 다양한 모델을 볼 수 있습니다. 각 모델은 용도와 가격이 다르므로, 프로젝트에 맞는 것을 선택하면 됩니다.

실제 현업에서는 어떻게 활용할까요? 많은 기업들이 Bedrock으로 고객 지원 챗봇을 만듭니다.

이메일이나 채팅으로 들어온 고객 문의를 AI가 자동으로 답변합니다. 간단한 문의는 AI가 처리하고, 복잡한 것만 사람에게 전달하여 운영 비용을 크게 줄일 수 있습니다.

또한 문서 요약 서비스도 인기가 많습니다. 긴 계약서나 보고서를 몇 줄로 요약해주면 임원들이 빠르게 의사결정을 할 수 있습니다.

법률 회사, 컨설팅 회사에서 특히 많이 사용합니다. 코드 생성 도구도 활발히 개발되고 있습니다.

자연어로 "사용자 로그인 API를 만들어줘"라고 요청하면, Bedrock이 실제 작동하는 코드를 생성해줍니다. 개발 속도가 2배 이상 빨라집니다.

하지만 주의할 점도 있습니다. 초보자들이 흔히 하는 실수는 리전을 확인하지 않는 것입니다.

Bedrock은 모든 리전에서 제공되지 않습니다. 서울 리전(ap-northeast-2)에서는 아직 사용할 수 없으므로, 미국 리전을 사용해야 합니다.

리전이 다르면 데이터 전송 비용이 추가로 발생할 수 있습니다. 또 다른 함정은 요금 폭탄입니다.

AI 모델은 사용량에 따라 비용이 급증할 수 있습니다. 특히 이미지 생성 모델은 텍스트 모델보다 훨씬 비쌉니다.

따라서 반드시 예산 알림을 설정하고, 초기에는 작은 규모로 테스트해봐야 합니다. 김개발 씨는 Bedrock 콘솔을 열어보며 감탄했습니다.

"정말 간단하네요. 클릭 몇 번이면 끝이잖아요?" 박시니어 씨가 고개를 끄덕였습니다.

"활성화는 쉽지만, 잘 쓰려면 다음 단계가 중요해요." Bedrock 서비스를 활성화하면 AI의 세계로 첫발을 내딛는 것입니다. 하지만 진짜 중요한 건 어떤 모델을 선택하느냐입니다.

다음 단계에서 자세히 알아보겠습니다.

실전 팁

💡 - 처음에는 가장 저렴한 모델(Claude Haiku, Llama 2)로 프로토타입을 만드세요.

Bedrock Playground에서 모델을 직접 테스트해볼 수 있습니다. 코드 작성 전에 충분히 실험하세요.
VPC 엔드포인트를 설정하면 데이터가 인터넷을 거치지 않아 보안이 강화됩니다.

4. 모델 액세스 요청하기

Bedrock 서비스를 활성화한 김개발 씨는 바로 모델을 사용하려 했습니다. 그런데 "Access denied" 에러가 떴습니다.

당황한 김개발 씨가 박시니어 씨에게 물었습니다. "분명 활성화했는데 왜 안 되죠?" 박시니어 씨가 설명했습니다.

"모델 액세스는 별도로 요청해야 해요."

모델 액세스 요청은 Bedrock에서 특정 AI 모델을 사용할 수 있는 권한을 받는 과정입니다. 마치 도서관에서 특별 열람실 사용 신청을 하는 것처럼, 각 모델마다 별도로 액세스를 요청해야 합니다.

대부분의 모델은 즉시 승인되지만, 일부는 검토 과정을 거칩니다.

다음 코드를 살펴봅시다.

# 모델 액세스 상태 확인
import boto3

# Bedrock 클라이언트 생성
bedrock = boto3.client('bedrock', region_name='us-east-1')

# 모델 액세스 목록 조회
try:
    response = bedrock.list_foundation_models()

    print("모델별 액세스 상태:")
    for model in response['modelSummaries']:
        model_id = model['modelId']
        model_name = model['modelName']

        # 각 모델의 상세 정보 조회
        detail = bedrock.get_foundation_model(modelIdentifier=model_id)
        status = detail.get('modelLifecycle', {}).get('status', 'UNKNOWN')

        print(f"  {model_name}: {status}")

except Exception as e:
    print(f"오류 발생: {str(e)}")

김개발 씨는 이해가 되지 않았습니다. "서비스를 활성화했으면 다 쓸 수 있는 거 아닌가요?" 합리적인 의문이었습니다.

박시니어 씨가 커피를 한 모금 마시고 설명을 시작했습니다. "AWS는 보안과 규정 준수를 매우 중요하게 생각해요.

AI 모델은 강력한 도구이기 때문에, 누가 어떻게 쓰는지 추적해야 합니다." 모델 액세스 요청이란 정확히 무엇일까요? 쉽게 비유하자면, 모델 액세스는 마치 운전면허와 같습니다.

자동차가 있어도 면허가 없으면 운전할 수 없습니다. 경차는 쉽게 면허를 받지만, 대형 트럭은 추가 교육과 시험이 필요합니다.

이처럼 AI 모델도 종류에 따라 승인 절차가 다릅니다. 액세스 제어가 없던 시절에는 어땠을까요?

누구나 모든 AI 모델을 마음대로 사용할 수 있었습니다. 그 결과 유해한 콘텐츠를 생성하거나, 개인정보를 유출하거나, 저작권을 침해하는 사례가 빈번했습니다.

더 큰 문제는 기업들이 AI 사용 내역을 추적할 방법이 없었다는 것입니다. 규정 위반이 발견돼도 책임 소재를 파악하기 어려웠습니다.

바로 이런 문제를 해결하기 위해 모델별 액세스 관리가 도입되었습니다. 모델 액세스를 요청하면 AWS가 계정을 검토합니다.

신용카드가 정상적으로 등록되어 있는지, 과거에 규정 위반 사례가 없는지 확인합니다. 대부분의 경우 몇 분 안에 자동 승인되지만, 강력한 모델은 수동 검토를 거칠 수 있습니다.

모델 액세스 요청 과정을 단계별로 살펴보겠습니다. 먼저 Bedrock 콘솔 왼쪽 메뉴에서 **"Model access"**를 클릭합니다.

현재 사용 가능한 모든 모델 목록이 표시됩니다. 각 모델 옆에 "Available", "Access granted", "Access requested" 같은 상태가 표시됩니다.

오른쪽 상단의 "Manage model access" 버튼을 클릭하면 모델 선택 화면이 나타납니다. 사용하고 싶은 모델 옆의 체크박스를 선택합니다.

Claude 3 Sonnet, Claude 3 Haiku처럼 여러 모델을 한 번에 선택할 수 있습니다. 화면 하단의 "Request model access" 버튼을 누르면 요청이 제출됩니다.

일반적인 모델은 즉시 "Access granted" 상태로 변경됩니다. 만약 "Pending" 상태가 나타나면, 검토 중이라는 의미이므로 조금 기다려야 합니다.

실제 현업에서는 어떻게 활용할까요? 대부분의 기업은 프로젝트 초기에 필요한 모든 모델 액세스를 한 번에 요청합니다.

예를 들어 챗봇 프로젝트라면 Claude 3 Sonnet(대화용), Titan Embeddings(검색용), Stable Diffusion(이미지용)을 모두 신청합니다. 나중에 하나씩 추가하는 것보다 효율적입니다.

또한 개발 계정과 프로덕션 계정을 분리합니다. 개발 계정에서는 모든 모델을 자유롭게 테스트하고, 프로덕션 계정에서는 실제로 사용할 모델만 활성화합니다.

이렇게 하면 보안과 비용 관리가 쉬워집니다. 하지만 주의할 점도 있습니다.

초보자들이 자주 하는 실수는 모든 모델에 액세스를 요청하는 것입니다. "혹시 몰라서" 모든 체크박스를 선택하는데, 이렇게 하면 나중에 관리가 복잡해집니다.

실제로 사용할 모델만 선택하는 것이 좋습니다. 또 다른 함정은 리전별로 액세스가 다르다는 점을 모르는 것입니다.

us-east-1에서 Claude 액세스를 받았다고 해서 us-west-2에서도 자동으로 되는 건 아닙니다. 각 리전마다 별도로 요청해야 합니다.

가장 치명적인 실수는 조직 정책을 확인하지 않는 것입니다. AWS Organizations를 사용하는 기업이라면, 중앙 IT 팀이 특정 모델 사용을 제한할 수 있습니다.

아무리 액세스를 요청해도 조직 정책에서 막혀 있으면 승인되지 않습니다. 김개발 씨는 신중하게 모델을 선택했습니다.

챗봇 프로젝트에 필요한 Claude 3 Haiku와 Titan Embeddings만 체크했습니다. 몇 초 후 "Access granted" 메시지가 떴습니다.

"이제 진짜 시작이네요!" 모델 액세스를 받았다면 이제 본격적으로 AI 개발을 시작할 준비가 된 것입니다. 하지만 콘솔에서만 작업할 수는 없습니다.

실제 코드에서 사용하려면 CLI 설정이 필요합니다.

실전 팁

💡 - 처음에는 무료 티어가 있는 모델(Titan, Llama)로 시작하세요. 비용 부담 없이 학습할 수 있습니다.

모델마다 제공되는 기능이 다릅니다. 문서를 읽고 프로젝트에 맞는 모델을 선택하세요.
일부 모델은 특정 국가에서 사용이 제한될 수 있습니다. 이용 약관을 확인하세요.

5. AWS CLI 설치 및 설정

모델 액세스까지 받은 김개발 씨는 이제 코드를 작성하고 싶었습니다. "콘솔에서 버튼만 누르는 건 답답해요.

진짜 개발자처럼 터미널에서 작업하고 싶어요." 박시니어 씨가 노트북을 열며 말했습니다. "그럼 AWS CLI부터 설치해야죠."

AWS CLI(Command Line Interface)는 터미널에서 AWS 서비스를 제어할 수 있는 명령줄 도구입니다. 마치 마우스 없이 키보드만으로 컴퓨터를 조작하는 것처럼, CLI를 사용하면 웹 콘솔 없이도 모든 AWS 작업을 수행할 수 있습니다.

자동화와 스크립트 작성에 필수적입니다.

다음 코드를 살펴봅시다.

# AWS CLI 설치 확인 및 기본 사용법
# 터미널에서 실행하는 명령어들

# AWS CLI 버전 확인 (설치 여부 확인)
aws --version

# 현재 설정된 자격 증명 확인
aws sts get-caller-identity

# Bedrock 모델 목록 조회 (CLI 사용 예제)
aws bedrock list-foundation-models --region us-east-1

# 특정 S3 버킷 목록 조회
aws s3 ls

# EC2 인스턴스 목록 조회
aws ec2 describe-instances --region ap-northeast-2

김개발 씨는 터미널 화면을 보며 두근거렸습니다. "진짜 해커 같은데요?" 박시니어 씨가 웃었습니다.

"해커까지는 아니고, 그냥 효율적인 개발자죠." AWS CLI란 정확히 무엇일까요? 쉽게 비유하자면, CLI는 마치 자동차의 수동 변속기와 같습니다.

자동 변속기(웹 콘솔)는 편하지만 세밀한 제어가 어렵습니다. 수동 변속기(CLI)는 처음엔 어렵지만, 익숙해지면 훨씬 빠르고 정확하게 제어할 수 있습니다.

게다가 같은 작업을 반복할 때는 스크립트로 자동화할 수 있습니다. CLI가 없던 시절에는 어땠을까요?

모든 작업을 웹 콘솔에서 클릭으로 해야 했습니다. EC2 인스턴스 10개를 만들려면 같은 버튼을 10번 눌러야 했습니다.

실수로 잘못 클릭하면 처음부터 다시 시작해야 했습니다. 더 큰 문제는 작업 내역을 기록하기 어렵다는 것이었습니다.

어떤 설정을 어떻게 바꿨는지 나중에 재현할 방법이 없었습니다. 바로 이런 문제를 해결하기 위해 AWS CLI가 등장했습니다.

CLI를 사용하면 한 줄의 명령어로 복잡한 작업을 수행할 수 있습니다. 같은 명령어를 스크립트 파일에 저장해두면 언제든 똑같이 재현할 수 있습니다.

무엇보다 Git으로 버전 관리를 하면, 인프라 변경 사항을 코드처럼 추적할 수 있습니다. AWS CLI 설치 과정을 운영체제별로 살펴보겠습니다.

Windows 사용자라면 AWS 공식 사이트에서 MSI 인스톨러를 다운로드합니다. 더블클릭으로 설치하면 끝입니다.

PowerShell이나 CMD에서 aws --version을 입력해 정상 설치되었는지 확인합니다. macOS 사용자는 터미널을 열고 간단한 명령어를 입력합니다.

curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"로 패키지를 다운로드하고, sudo installer -pkg AWSCLIV2.pkg -target /로 설치합니다. 또는 Homebrew를 사용한다면 brew install awscli만 입력하면 됩니다.

Linux 사용자는 배포판에 따라 방법이 조금 다릅니다. 우분투라면 sudo apt install awscli로 간단히 설치할 수 있습니다.

하지만 최신 버전을 원한다면 공식 설치 스크립트를 사용하는 것이 좋습니다. 설치가 완료되면 aws --version을 실행해봅니다.

aws-cli/2.15.0 Python/3.11.6 같은 출력이 나오면 성공입니다. 실제 현업에서는 어떻게 활용할까요?

DevOps 엔지니어들은 CLI로 인프라를 코드로 관리합니다. 예를 들어 개발 서버 100대를 만들어야 한다면, for 루프를 돌며 aws ec2 run-instances 명령을 반복합니다.

몇 초 만에 모든 서버가 생성됩니다. CI/CD 파이프라인에서도 CLI는 필수입니다.

GitHub Actions나 Jenkins에서 코드를 빌드한 후, aws s3 cp로 S3에 업로드하고, aws cloudfront create-invalidation으로 캐시를 무효화합니다. 모든 과정이 자동으로 진행됩니다.

비용 모니터링 스크립트를 만들 수도 있습니다. 매일 아침 aws ce get-cost-and-usage 명령으로 어제 사용한 비용을 조회하고, 슬랙으로 알림을 보냅니다.

예산 초과를 미리 방지할 수 있습니다. 하지만 주의할 점도 있습니다.

초보자들이 가장 많이 하는 실수는 구버전 CLI를 사용하는 것입니다. 패키지 매니저로 설치하면 오래된 버전이 설치될 수 있습니다.

Bedrock 같은 최신 서비스는 CLI v2에서만 지원되므로, 반드시 최신 버전을 설치해야 합니다. 또 다른 실수는 명령어 옵션을 정확히 모르고 쓰는 것입니다.

--dry-run 옵션을 붙이면 실제로 실행하지 않고 미리 결과를 확인할 수 있습니다. 특히 delete나 terminate 같은 위험한 명령은 반드시 dry-run으로 먼저 테스트해야 합니다.

가장 위험한 실수는 와일드카드를 잘못 사용하는 것입니다. aws s3 rm s3://my-bucket/* --recursive를 실수로 입력하면 버킷의 모든 파일이 삭제됩니다.

복구가 불가능할 수 있으므로, 항상 명령어를 두 번 확인해야 합니다. 김개발 씨는 터미널에서 aws --version을 입력했습니다.

버전 정보가 화면에 출력되자 뿌듯한 미소를 지었습니다. "이제 진짜 개발자 같네요!" 하지만 박시니어 씨가 손을 저었습니다.

"아직 끝이 아니에요. CLI를 설치했다고 바로 쓸 수 있는 건 아닙니다.

자격 증명을 설정해야 해요." AWS CLI를 설치하는 것은 시작에 불과합니다. 진짜 중요한 건 어떻게 안전하게 인증하느냐입니다.

다음 단계에서 자격 증명 설정 방법을 배워보겠습니다.

실전 팁

💡 - CLI 명령어가 기억나지 않으면 aws <service> help로 도움말을 볼 수 있습니다.

--output json 옵션을 쓰면 결과를 JSON으로 받아 jq 같은 도구로 파싱할 수 있습니다.
AWS CloudShell을 사용하면 설치 없이 브라우저에서 CLI를 쓸 수 있습니다.

6. 자격 증명 구성하기

CLI를 설치한 김개발 씨는 바로 명령어를 입력해봤습니다. aws s3 ls를 실행했지만 에러만 떴습니다.

"Unable to locate credentials." 박시니어 씨가 설명했습니다. "AWS가 당신이 누군지 모르니까 명령을 거부하는 거예요.

신분증을 보여줘야 합니다."

자격 증명 구성은 AWS CLI가 여러분의 계정으로 작업할 수 있도록 인증 정보를 설정하는 과정입니다. 마치 ATM에 카드를 넣고 비밀번호를 입력하는 것처럼, Access Key ID와 Secret Access Key를 등록해야 합니다.

이 정보 없이는 어떤 AWS 작업도 수행할 수 없습니다.

다음 코드를 살펴봅시다.

# 자격 증명 구성 및 확인 스크립트
import boto3
import os

# 방법 1: 환경 변수로 자격 증명 설정 (임시 테스트용)
# os.environ['AWS_ACCESS_KEY_ID'] = 'YOUR_ACCESS_KEY'
# os.environ['AWS_SECRET_ACCESS_KEY'] = 'YOUR_SECRET_KEY'
# os.environ['AWS_DEFAULT_REGION'] = 'us-east-1'

# 방법 2: AWS CLI 구성 파일 사용 (권장)
# ~/.aws/credentials 파일에서 자동으로 읽어옴

# 현재 자격 증명으로 신원 확인
sts = boto3.client('sts')
identity = sts.get_caller_identity()

print("현재 인증 정보:")
print(f"  계정 ID: {identity['Account']}")
print(f"  사용자 ARN: {identity['Arn']}")
print(f"  사용자 ID: {identity['UserId']}")

# 설정된 리전 확인
session = boto3.session.Session()
print(f"\n현재 리전: {session.region_name}")

김개발 씨는 당황했습니다. "분명 로그인했는데 왜 인증이 안 되죠?" 합리적인 의문이었습니다.

웹 콘솔에서는 로그인만 하면 모든 게 됐으니까요. 박시니어 씨가 차분히 설명했습니다.

"웹 브라우저는 쿠키와 세션으로 로그인 상태를 유지합니다. 하지만 터미널은 브라우저가 아니에요.

별도의 인증 방법이 필요합니다." 자격 증명이란 정확히 무엇일까요? 쉽게 비유하자면, 자격 증명은 마치 호텔 객실 카드키와 같습니다.

프론트에서 체크인할 때(웹 로그인) 받는 카드키(Access Key)로 방문(AWS 리소스)을 열 수 있습니다. 카드키를 잃어버리면 아무것도 할 수 없습니다.

하지만 프론트에 다시 가면 새 카드키를 받을 수 있습니다. 자격 증명이 없던 시절에는 어땠을까요?

매번 명령어를 실행할 때마다 ID와 비밀번호를 입력해야 했습니다. 자동화 스크립트에 비밀번호를 하드코딩해야 했고, 이는 엄청난 보안 위험이었습니다.

더 큰 문제는 여러 계정을 사용할 때 매번 로그아웃하고 다시 로그인해야 한다는 것이었습니다. 바로 이런 문제를 해결하기 위해 액세스 키 기반 인증이 도입되었습니다.

액세스 키를 한 번 설정해두면 이후로는 자동으로 인증됩니다. 여러 계정의 자격 증명을 프로필로 저장해두고, 필요할 때마다 --profile 옵션으로 전환할 수 있습니다.

무엇보다 키를 분실하거나 유출되면 즉시 폐기하고 새로 발급받을 수 있습니다. 자격 증명 구성 과정을 단계별로 살펴보겠습니다.

먼저 IAM 콘솔에서 액세스 키를 생성해야 합니다. 자신의 IAM 사용자 페이지로 가서 "Security credentials" 탭을 클릭합니다.

"Create access key" 버튼을 누르면 용도를 선택하는 화면이 나타납니다. "Command Line Interface (CLI)"를 선택하고 다음으로 넘어갑니다.

경고 메시지가 나타나지만 "I understand" 체크박스를 선택하고 진행합니다. 마지막 화면에서 Access Key ID와 Secret Access Key가 표시됩니다.

이 화면은 단 한 번만 보이므로, 반드시 안전한 곳에 저장해야 합니다. CSV 파일로 다운로드하는 것이 좋습니다.

이제 터미널을 열고 aws configure를 입력합니다. 네 가지 질문이 나옵니다.

첫 번째는 AWS Access Key ID입니다. 방금 생성한 키를 붙여넣습니다.

두 번째는 AWS Secret Access Key입니다. 역시 복사해서 붙여넣습니다.

세 번째는 Default region name입니다. 주로 사용할 리전을 입력합니다.

서울은 ap-northeast-2, 도쿄는 ap-northeast-1, 버지니아는 us-east-1입니다. Bedrock을 쓸 거라면 us-east-1을 입력합니다.

네 번째는 Default output format입니다. json, yaml, text 중 선택할 수 있습니다.

대부분 json을 사용합니다. 모든 입력을 마치면 자격 증명이 ~/.aws/credentials 파일에 저장됩니다.

aws sts get-caller-identity를 실행하면 현재 인증된 사용자 정보가 출력됩니다. 실제 현업에서는 어떻게 활용할까요?

대부분의 개발자는 여러 프로필을 관리합니다. 개인 계정, 회사 개발 계정, 회사 운영 계정을 모두 다른 프로필로 저장합니다.

aws configure --profile personal, aws configure --profile work-dev 같은 식으로 각각 설정합니다. 사용할 때는 aws s3 ls --profile work-dev처럼 프로필을 지정합니다.

환경 변수를 활용하는 경우도 많습니다. CI/CD 파이프라인에서는 AWS_ACCESS_KEY_ID와 AWS_SECRET_ACCESS_KEY 환경 변수를 설정합니다.

이렇게 하면 configure 명령 없이도 자격 증명이 작동합니다. IAM 역할을 사용하는 것이 가장 안전합니다.

EC2 인스턴스나 Lambda 함수에서 작업할 때는 액세스 키를 전혀 사용하지 않습니다. 인스턴스에 역할을 부여하면 자동으로 임시 자격 증명이 생성됩니다.

하지만 주의할 점도 있습니다. 초보자들이 가장 많이 하는 실수는 액세스 키를 GitHub에 올리는 것입니다.

코드에 하드코딩하거나 .env 파일을 실수로 커밋하면, 봇들이 즉시 발견하고 악용합니다. 몇 분 만에 수백만 원의 요금이 청구될 수 있습니다.

또 다른 실수는 루트 계정의 액세스 키를 만드는 것입니다. 루트 계정은 모든 권한을 가지고 있어 매우 위험합니다.

반드시 IAM 사용자의 키만 사용해야 합니다. 가장 흔한 함정은 액세스 키를 정기적으로 교체하지 않는 것입니다.

한 번 만든 키를 몇 년씩 쓰는 경우가 많습니다. 하지만 키가 유출되었는지 모를 수 있으므로, 90일마다 새 키로 교체하는 것이 좋습니다.

김개발 씨는 신중하게 자격 증명을 설정했습니다. aws sts get-caller-identity를 실행하자 자신의 계정 정보가 출력되었습니다.

"드디어 됐어요!" 환호성을 질렀습니다. 박시니어 씨가 만족스럽게 고개를 끄덕였습니다.

"이제 진짜 개발자가 됐네요. AWS의 모든 문이 열렸어요." 자격 증명을 올바르게 설정하면 로컬 개발 환경에서 AWS의 모든 서비스를 자유롭게 사용할 수 있습니다.

이제 여러분도 Bedrock으로 AI 애플리케이션을 만들 준비가 완료되었습니다.

실전 팁

💡 - AWS Vault나 aws-mfa 같은 도구를 사용하면 MFA와 임시 자격 증명을 쉽게 관리할 수 있습니다.

액세스 키를 절대 슬랙이나 이메일로 공유하지 마세요. IAM 역할이나 AssumeRole을 사용하세요.
AWS Secrets Manager에 자격 증명을 저장하면 코드에서 안전하게 불러올 수 있습니다.

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

#AWS#IAM#Bedrock#CLI#Credentials

AWS 환경 설정 완벽 가이드

# AWS 환경 설정 완벽 가이드 AWS 계정 생성부터 Bedrock 서비스 활성화, CLI 설정까지 초급 개발자를 위한 단계별 실전 가이드입니다. 실무에서 바로 사용할 수 있는 AWS 환경 구축 노하우를 담았습니다. --- ## 목차 1. [AWS_계정_생성하기](#aws-계정-생성하기) 2. [IAM_사용자_및_역할_설정](#iam-사용자-및-역할-설정) 3. [Bedrock_서비스_활성화](#bedrock-서비스-활성화) 4. [모델_액세스_요청하기](#모델-액세스-요청하기) 5. [AWS_CLI_설치_및_설정](#aws-cli-설치-및-설정) 6. [자격_증명_구성하기](#자격-증명-구성하기) --- ## 1. AWS_계정_생성하기 김개발 씨는 오늘 처음으로 클라우드 서비스를 사용해보기로 했습니다. 선배 개발자 박시니어 씨가 "요즘은 모든 서비스가 클라우드에서 돌아간다"며 AWS 계정부터 만들어보라고 권했습니다. **AWS 계정 생성**은 아마존 웹 서비스를 사용하기 위한 첫 번째 단계입니다. 마치 도서관 회원증을 만드는 것처럼, 계정을 만들어야 AWS의 모든 서비스를 이용할 수 있습니다. 이메일 주소와 신용카드만 있으면 누구나 쉽게 시작할 수 있습니다. 다음 코드를 살펴봅시다. ```python # AWS 계정 생성 후 확인할 수 있는 기본 정보 import boto3 # AWS 계정 ID 확인 sts_client = boto3.client('sts') account_id = sts_client.get_caller_identity()['Account'] print(f"현재 AWS 계정 ID: {account_id}") # 사용 가능한 리전 목록 조회 ec2_client = boto3.client('ec2') regions = ec2_client.describe_regions() print("사용 가능한 리전:") for region in regions['Regions']: print(f" - {region['RegionName']}") ``` 김개발 씨는 회사에서 새로운 프로젝트를 맡게 되었습니다. 프로젝트 매니저가 말했습니다. "이번 프로젝트는 AWS에서 진행합니다. 계정부터 만들어주세요." AWS가 무엇인지는 들어봤지만, 실제로 사용해본 적은 없었습니다. 막연히 어려울 것 같았지만, 박시니어 씨가 옆에서 한 마디 던졌습니다. "걱정하지 마세요. 네이버 회원가입보다 쉬워요." AWS 계정이란 정확히 무엇일까요? 쉽게 비유하자면, AWS 계정은 마치 대형 쇼핑몰의 회원증과 같습니다. 회원증 하나로 쇼핑몰 안의 모든 매장을 이용할 수 있듯이, AWS 계정 하나로 컴퓨팅, 스토리지, 데이터베이스, AI 서비스 등 200개가 넘는 서비스를 사용할 수 있습니다. 계정이 없던 시절에는 어땠을까요? 과거에는 서버를 직접 구매하고 관리해야 했습니다. 서버실을 만들고, 전기 요금을 내고, 24시간 관리 인력을 두어야 했습니다. 작은 스타트업에게는 엄두도 낼 수 없는 일이었습니다. 더 큰 문제는 트래픽이 갑자기 늘어나면 대응할 방법이 없다는 것이었습니다. 바로 이런 문제를 해결하기 위해 **클라우드 서비스**가 등장했습니다. AWS 계정을 만들면 필요한 만큼만 서버를 빌려 쓸 수 있습니다. 트래픽이 늘어나면 자동으로 서버를 늘리고, 줄어들면 다시 줄일 수 있습니다. 무엇보다 초기 투자 비용 없이 서비스를 시작할 수 있다는 큰 이점이 있습니다. 계정 생성 과정을 단계별로 살펴보겠습니다. 먼저 AWS 공식 웹사이트(aws.amazon.com)에 접속합니다. 오른쪽 상단의 "무료 계정 만들기" 버튼을 클릭하면 됩니다. 이메일 주소와 비밀번호를 입력하면 첫 단계가 완료됩니다. 다음으로 연락처 정보를 입력합니다. 이름, 주소, 전화번호를 정확히 입력해야 합니다. AWS는 보안을 매우 중요하게 생각하기 때문에 본인 확인 절차가 꼼꼼합니다. 신용카드 정보를 입력하는 단계에서 많은 분들이 걱정하십니다. "돈이 빠져나가는 거 아닌가요?" 하지만 걱정하지 않아도 됩니다. AWS는 12개월 동안 **프리 티어**라는 무료 사용 범위를 제공합니다. 정해진 한도 내에서는 한 푼도 내지 않고 서비스를 사용할 수 있습니다. 전화번호 인증을 거치면 계정 생성이 완료됩니다. 보통 5분에서 10분 정도면 모든 과정이 끝납니다. 실제 현업에서는 어떻게 활용할까요? 대부분의 스타트업은 AWS 프리 티어로 서비스를 시작합니다. 초기에는 사용자가 많지 않아 무료 범위 내에서 충분히 운영할 수 있습니다. 서비스가 성장하면서 자연스럽게 유료 플랜으로 전환하게 됩니다. 넷플릭스, 에어비앤비 같은 글로벌 기업들도 모두 AWS에서 시작했습니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 프리 티어 한도를 확인하지 않고 서비스를 마구 켜두는 것입니다. 이렇게 하면 예상치 못한 요금이 청구될 수 있습니다. 따라서 **사용하지 않는 서비스는 반드시 종료**하고, **예산 알림**을 설정해두어야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 안내에 따라 계정을 만든 김개발 씨는 생각보다 간단해서 놀랐습니다. "정말 회원가입이랑 똑같네요!" AWS 계정은 클라우드 여정의 시작입니다. 오늘 배운 내용을 토대로 직접 계정을 만들어보세요. 새로운 세상이 열릴 것입니다. **실전 팁** 💡 - 루트 계정은 절대 일상 업무에 사용하지 마세요. IAM 사용자를 별도로 만들어야 합니다. - MFA(다중 인증)를 반드시 설정하세요. 계정 보안이 훨씬 강화됩니다. - 프리 티어 사용량을 모니터링하는 CloudWatch 알림을 설정하세요. --- ## 2. IAM_사용자_및_역할_설정 계정을 만든 김개발 씨는 바로 서비스를 사용하려 했습니다. 그런데 박시니어 씨가 다급하게 손을 저었습니다. "잠깐! 루트 계정으로 직접 작업하면 안 됩니다. IAM 사용자부터 만들어야 해요." **IAM**(Identity and Access Management)은 AWS 리소스에 대한 접근을 안전하게 제어하는 서비스입니다. 마치 회사에서 부서별로 다른 출입 권한을 주는 것처럼, 각 사용자와 서비스에 필요한 권한만 부여할 수 있습니다. 이를 통해 보안을 크게 강화할 수 있습니다. 다음 코드를 살펴봅시다. ```python # IAM 사용자 정보 조회 import boto3 # IAM 클라이언트 생성 iam = boto3.client('iam') # 현재 사용자 정보 확인 user = iam.get_user() print(f"사용자 이름: {user['User']['UserName']}") print(f"사용자 ARN: {user['User']['Arn']}") # 사용자에게 부여된 정책 목록 조회 policies = iam.list_attached_user_policies( UserName=user['User']['UserName'] ) print("\n부여된 권한:") for policy in policies['AttachedPolicies']: print(f" - {policy['PolicyName']}") ``` 김개발 씨는 의아했습니다. "제 계정인데 왜 제가 직접 못 쓰나요?" 박시니어 씨가 차분히 설명을 시작했습니다. "루트 계정은 마치 회사의 마스터 키와 같아요. 모든 문을 열 수 있죠. 만약 이 키를 잃어버리면 어떻게 될까요? 큰일 나겠죠?" IAM이란 정확히 무엇일까요? 쉽게 비유하자면, IAM은 마치 아파트 관리실에서 발급하는 출입증과 같습니다. 입주민은 자기 집만 들어갈 수 있는 카드를, 경비원은 공용 공간만 접근할 수 있는 카드를, 관리소장은 모든 곳을 갈 수 있는 카드를 받습니다. 이처럼 IAM도 사용자마다 필요한 권한만 정확히 부여하는 시스템입니다. IAM이 없던 시절에는 어땠을까요? 모든 개발자가 루트 계정 정보를 공유해야 했습니다. 누가 무엇을 했는지 추적할 수 없었고, 퇴사한 직원의 접근을 차단하기도 어려웠습니다. 더 큰 문제는 실수로 중요한 데이터를 삭제해도 누가 했는지 알 수 없다는 것이었습니다. 바로 이런 문제를 해결하기 위해 **IAM**이 등장했습니다. IAM을 사용하면 각 개발자에게 개별 계정을 만들어줄 수 있습니다. 신입 개발자에게는 읽기 권한만, 시니어 개발자에게는 쓰기 권한도 줄 수 있습니다. 무엇보다 모든 작업이 로그로 남아 누가 언제 무엇을 했는지 정확히 추적할 수 있습니다. IAM의 핵심 개념을 살펴보겠습니다. 먼저 **사용자(User)**는 실제 사람이나 애플리케이션을 의미합니다. 김개발 씨처럼 개별 개발자마다 하나씩 만듭니다. 다음으로 **그룹(Group)**은 비슷한 권한을 가진 사용자들의 모임입니다. 개발팀, 운영팀처럼 팀 단위로 그룹을 만들면 관리가 쉬워집니다. **정책(Policy)**은 실제 권한을 정의하는 JSON 문서입니다. "EC2 인스턴스를 시작할 수 있다", "S3 버킷을 읽을 수 있다" 같은 구체적인 권한을 명시합니다. 가장 중요한 개념이 **역할(Role)**입니다. 역할은 사람이 아닌 서비스에게 부여하는 임시 권한입니다. 예를 들어 EC2 인스턴스가 S3에 접근해야 할 때, 인스턴스에 역할을 부여하면 됩니다. 비밀번호를 코드에 하드코딩할 필요가 없어집니다. 실제 현업에서는 어떻게 활용할까요? 대부분의 회사는 **최소 권한 원칙**을 따릅니다. 처음에는 아무 권한도 주지 않고, 필요한 것만 하나씩 추가합니다. 예를 들어 데이터 분석가에게는 RDS 읽기 권한만 주고, 백엔드 개발자에게는 Lambda와 API Gateway 권한을 줍니다. 또한 **역할 기반 접근 제어**를 적극 활용합니다. 개발 환경, 스테이징 환경, 프로덕션 환경마다 다른 역할을 만들어 분리합니다. 주니어 개발자는 개발 환경만, 시니어는 모든 환경에 접근할 수 있게 합니다. 하지만 주의할 점도 있습니다. 초보자들이 가장 많이 하는 실수는 **AdministratorAccess** 정책을 모든 사용자에게 부여하는 것입니다. 이렇게 하면 IAM을 쓰는 의미가 없습니다. 따라서 반드시 업무에 필요한 최소한의 권한만 부여해야 합니다. 또 다른 실수는 **액세스 키를 코드에 직접 쓰는 것**입니다. GitHub에 올린 코드에서 액세스 키가 노출되면, 전 세계 해커들이 여러분의 AWS 계정으로 비트코인을 채굴할 수 있습니다. 실제로 이런 사고가 매일 발생합니다. 김개발 씨는 박시니어 씨의 설명을 듣고 고개를 끄덕였습니다. "보안이 이렇게 중요한 줄 몰랐어요." 바로 자신의 IAM 사용자를 만들고, 개발팀 그룹에 추가했습니다. IAM을 제대로 설정하면 보안 사고를 미연에 방지할 수 있습니다. 처음에는 복잡해 보이지만, 한 번 익혀두면 평생 써먹을 수 있는 지식입니다. **실전 팁** 💡 - MFA를 모든 IAM 사용자에게 강제로 설정하세요. 비밀번호만으로는 부족합니다. - 액세스 키는 90일마다 교체하는 정책을 만드세요. 오래된 키는 보안 위험입니다. - AWS Organizations를 사용하면 여러 AWS 계정을 중앙에서 관리할 수 있습니다. --- ## 3. Bedrock_서비스_활성화 IAM 설정을 마친 김개발 씨는 이제 본격적으로 AI 서비스를 사용해보고 싶었습니다. 회사에서 챗봇을 만들어보라는 과제를 받았기 때문입니다. 박시니어 씨가 추천했습니다. "AWS Bedrock을 써보세요. 요즘 가장 핫한 서비스예요." **AWS Bedrock**은 파운데이션 모델(FM)을 API로 쉽게 사용할 수 있게 해주는 완전 관리형 서비스입니다. 마치 렌터카를 빌리듯이, AI 모델을 직접 훈련하지 않고도 Claude, Llama 같은 최신 모델을 바로 사용할 수 있습니다. 복잡한 인프라 관리 없이 AI 기능을 애플리케이션에 추가할 수 있습니다. 다음 코드를 살펴봅시다. ```python # Bedrock 서비스 활성화 확인 및 사용 가능한 모델 조회 import boto3 import json # Bedrock 클라이언트 생성 bedrock = boto3.client('bedrock', region_name='us-east-1') # 사용 가능한 파운데이션 모델 목록 조회 models = bedrock.list_foundation_models() print("사용 가능한 Bedrock 모델:") for model in models['modelSummaries']: print(f" - {model['modelName']}") print(f" 모델 ID: {model['modelId']}") print(f" 제공사: {model['providerName']}") print() ``` 김개발 씨는 AI에 대해 들어는 봤지만, 직접 사용해본 적은 없었습니다. "AI 모델을 훈련시키려면 엄청난 컴퓨터와 데이터가 필요하지 않나요?" 걱정스러운 목소리로 물었습니다. 박시니어 씨가 웃으며 대답했습니다. "옛날 이야기예요. 이제는 이미 훈련된 모델을 빌려 쓰면 됩니다." AWS Bedrock이란 정확히 무엇일까요? 쉽게 비유하자면, Bedrock은 마치 음악 스트리밍 서비스와 같습니다. 직접 CD를 사거나 음원을 다운로드하지 않아도, 멜론이나 스포티파이에서 바로 음악을 들을 수 있습니다. 이처럼 Bedrock도 AI 모델을 직접 만들지 않아도, API 호출 한 번으로 최신 AI의 능력을 쓸 수 있게 해줍니다. Bedrock이 없던 시절에는 어땠을까요? AI 모델을 사용하려면 직접 서버에 설치하고 관리해야 했습니다. GPU 서버를 구매하고, 모델 파일을 다운로드하고, 버전 관리를 하고, 트래픽에 맞춰 스케일링도 직접 처리해야 했습니다. 작은 스타트업에게는 불가능한 일이었습니다. 더 큰 문제는 모델이 너무 빨리 발전한다는 것이었습니다. 겨우 GPT-3를 설치했는데 GPT-4가 나오면, 다시 처음부터 설치 작업을 해야 했습니다. 시간과 비용이 엄청나게 낭비되었습니다. 바로 이런 문제를 해결하기 위해 **AWS Bedrock**이 등장했습니다. Bedrock을 사용하면 Anthropic의 Claude, Meta의 Llama, Stability AI의 Stable Diffusion 같은 최신 모델을 API로 바로 쓸 수 있습니다. 서버 관리, 모델 업데이트, 스케일링이 모두 자동으로 처리됩니다. 무엇보다 사용한 만큼만 비용을 내는 **종량제 방식**이라 초기 투자가 필요 없습니다. Bedrock 활성화 과정을 단계별로 살펴보겠습니다. 먼저 AWS 콘솔에 로그인한 후 Bedrock 서비스를 검색합니다. 아직 한국 리전에서는 제공되지 않으므로, 오른쪽 상단에서 리전을 **us-east-1**(버지니아 북부)이나 **us-west-2**(오레곤)로 변경해야 합니다. Bedrock 대시보드에 들어가면 "Get started" 버튼이 보입니다. 클릭하면 서비스가 자동으로 활성화됩니다. 별도의 설정이 필요 없어 매우 간단합니다. 왼쪽 메뉴에서 "Model access"를 선택하면 사용 가능한 모델 목록이 나타납니다. Claude 3 Sonnet, Claude 3 Haiku, Llama 2, Titan 등 다양한 모델을 볼 수 있습니다. 각 모델은 용도와 가격이 다르므로, 프로젝트에 맞는 것을 선택하면 됩니다. 실제 현업에서는 어떻게 활용할까요? 많은 기업들이 Bedrock으로 **고객 지원 챗봇**을 만듭니다. 이메일이나 채팅으로 들어온 고객 문의를 AI가 자동으로 답변합니다. 간단한 문의는 AI가 처리하고, 복잡한 것만 사람에게 전달하여 운영 비용을 크게 줄일 수 있습니다. 또한 **문서 요약 서비스**도 인기가 많습니다. 긴 계약서나 보고서를 몇 줄로 요약해주면 임원들이 빠르게 의사결정을 할 수 있습니다. 법률 회사, 컨설팅 회사에서 특히 많이 사용합니다. **코드 생성 도구**도 활발히 개발되고 있습니다. 자연어로 "사용자 로그인 API를 만들어줘"라고 요청하면, Bedrock이 실제 작동하는 코드를 생성해줍니다. 개발 속도가 2배 이상 빨라집니다. 하지만 주의할 점도 있습니다. 초보자들이 흔히 하는 실수는 **리전을 확인하지 않는 것**입니다. Bedrock은 모든 리전에서 제공되지 않습니다. 서울 리전(ap-northeast-2)에서는 아직 사용할 수 없으므로, 미국 리전을 사용해야 합니다. 리전이 다르면 데이터 전송 비용이 추가로 발생할 수 있습니다. 또 다른 함정은 **요금 폭탄**입니다. AI 모델은 사용량에 따라 비용이 급증할 수 있습니다. 특히 이미지 생성 모델은 텍스트 모델보다 훨씬 비쌉니다. 따라서 반드시 **예산 알림**을 설정하고, 초기에는 작은 규모로 테스트해봐야 합니다. 김개발 씨는 Bedrock 콘솔을 열어보며 감탄했습니다. "정말 간단하네요. 클릭 몇 번이면 끝이잖아요?" 박시니어 씨가 고개를 끄덕였습니다. "활성화는 쉽지만, 잘 쓰려면 다음 단계가 중요해요." Bedrock 서비스를 활성화하면 AI의 세계로 첫발을 내딛는 것입니다. 하지만 진짜 중요한 건 어떤 모델을 선택하느냐입니다. 다음 단계에서 자세히 알아보겠습니다. **실전 팁** 💡 - 처음에는 가장 저렴한 모델(Claude Haiku, Llama 2)로 프로토타입을 만드세요. - Bedrock Playground에서 모델을 직접 테스트해볼 수 있습니다. 코드 작성 전에 충분히 실험하세요. - VPC 엔드포인트를 설정하면 데이터가 인터넷을 거치지 않아 보안이 강화됩니다. --- ## 4. 모델_액세스_요청하기 Bedrock 서비스를 활성화한 김개발 씨는 바로 모델을 사용하려 했습니다. 그런데 "Access denied" 에러가 떴습니다. 당황한 김개발 씨가 박시니어 씨에게 물었습니다. "분명 활성화했는데 왜 안 되죠?" 박시니어 씨가 설명했습니다. "모델 액세스는 별도로 요청해야 해요." **모델 액세스 요청**은 Bedrock에서 특정 AI 모델을 사용할 수 있는 권한을 받는 과정입니다. 마치 도서관에서 특별 열람실 사용 신청을 하는 것처럼, 각 모델마다 별도로 액세스를 요청해야 합니다. 대부분의 모델은 즉시 승인되지만, 일부는 검토 과정을 거칩니다. 다음 코드를 살펴봅시다. ```python # 모델 액세스 상태 확인 import boto3 # Bedrock 클라이언트 생성 bedrock = boto3.client('bedrock', region_name='us-east-1') # 모델 액세스 목록 조회 try: response = bedrock.list_foundation_models() print("모델별 액세스 상태:") for model in response['modelSummaries']: model_id = model['modelId'] model_name = model['modelName'] # 각 모델의 상세 정보 조회 detail = bedrock.get_foundation_model(modelIdentifier=model_id) status = detail.get('modelLifecycle', {}).get('status', 'UNKNOWN') print(f" {model_name}: {status}") except Exception as e: print(f"오류 발생: {str(e)}") ``` 김개발 씨는 이해가 되지 않았습니다. "서비스를 활성화했으면 다 쓸 수 있는 거 아닌가요?" 합리적인 의문이었습니다. 박시니어 씨가 커피를 한 모금 마시고 설명을 시작했습니다. "AWS는 보안과 규정 준수를 매우 중요하게 생각해요. AI 모델은 강력한 도구이기 때문에, 누가 어떻게 쓰는지 추적해야 합니다." 모델 액세스 요청이란 정확히 무엇일까요? 쉽게 비유하자면, 모델 액세스는 마치 운전면허와 같습니다. 자동차가 있어도 면허가 없으면 운전할 수 없습니다. 경차는 쉽게 면허를 받지만, 대형 트럭은 추가 교육과 시험이 필요합니다. 이처럼 AI 모델도 종류에 따라 승인 절차가 다릅니다. 액세스 제어가 없던 시절에는 어땠을까요? 누구나 모든 AI 모델을 마음대로 사용할 수 있었습니다. 그 결과 유해한 콘텐츠를 생성하거나, 개인정보를 유출하거나, 저작권을 침해하는 사례가 빈번했습니다. 더 큰 문제는 기업들이 AI 사용 내역을 추적할 방법이 없었다는 것입니다. 규정 위반이 발견돼도 책임 소재를 파악하기 어려웠습니다. 바로 이런 문제를 해결하기 위해 **모델별 액세스 관리**가 도입되었습니다. 모델 액세스를 요청하면 AWS가 계정을 검토합니다. 신용카드가 정상적으로 등록되어 있는지, 과거에 규정 위반 사례가 없는지 확인합니다. 대부분의 경우 몇 분 안에 자동 승인되지만, 강력한 모델은 수동 검토를 거칠 수 있습니다. 모델 액세스 요청 과정을 단계별로 살펴보겠습니다. 먼저 Bedrock 콘솔 왼쪽 메뉴에서 **"Model access"**를 클릭합니다. 현재 사용 가능한 모든 모델 목록이 표시됩니다. 각 모델 옆에 "Available", "Access granted", "Access requested" 같은 상태가 표시됩니다. 오른쪽 상단의 **"Manage model access"** 버튼을 클릭하면 모델 선택 화면이 나타납니다. 사용하고 싶은 모델 옆의 체크박스를 선택합니다. Claude 3 Sonnet, Claude 3 Haiku처럼 여러 모델을 한 번에 선택할 수 있습니다. 화면 하단의 **"Request model access"** 버튼을 누르면 요청이 제출됩니다. 일반적인 모델은 즉시 "Access granted" 상태로 변경됩니다. 만약 "Pending" 상태가 나타나면, 검토 중이라는 의미이므로 조금 기다려야 합니다. 실제 현업에서는 어떻게 활용할까요? 대부분의 기업은 **프로젝트 초기에 필요한 모든 모델 액세스를 한 번에 요청**합니다. 예를 들어 챗봇 프로젝트라면 Claude 3 Sonnet(대화용), Titan Embeddings(검색용), Stable Diffusion(이미지용)을 모두 신청합니다. 나중에 하나씩 추가하는 것보다 효율적입니다. 또한 **개발 계정과 프로덕션 계정을 분리**합니다. 개발 계정에서는 모든 모델을 자유롭게 테스트하고, 프로덕션 계정에서는 실제로 사용할 모델만 활성화합니다. 이렇게 하면 보안과 비용 관리가 쉬워집니다. 하지만 주의할 점도 있습니다. 초보자들이 자주 하는 실수는 **모든 모델에 액세스를 요청하는 것**입니다. "혹시 몰라서" 모든 체크박스를 선택하는데, 이렇게 하면 나중에 관리가 복잡해집니다. 실제로 사용할 모델만 선택하는 것이 좋습니다. 또 다른 함정은 **리전별로 액세스가 다르다는 점**을 모르는 것입니다. us-east-1에서 Claude 액세스를 받았다고 해서 us-west-2에서도 자동으로 되는 건 아닙니다. 각 리전마다 별도로 요청해야 합니다. 가장 치명적인 실수는 **조직 정책을 확인하지 않는 것**입니다. AWS Organizations를 사용하는 기업이라면, 중앙 IT 팀이 특정 모델 사용을 제한할 수 있습니다. 아무리 액세스를 요청해도 조직 정책에서 막혀 있으면 승인되지 않습니다. 김개발 씨는 신중하게 모델을 선택했습니다. 챗봇 프로젝트에 필요한 Claude 3 Haiku와 Titan Embeddings만 체크했습니다. 몇 초 후 "Access granted" 메시지가 떴습니다. "이제 진짜 시작이네요!" 모델 액세스를 받았다면 이제 본격적으로 AI 개발을 시작할 준비가 된 것입니다. 하지만 콘솔에서만 작업할 수는 없습니다. 실제 코드에서 사용하려면 CLI 설정이 필요합니다. **실전 팁** 💡 - 처음에는 무료 티어가 있는 모델(Titan, Llama)로 시작하세요. 비용 부담 없이 학습할 수 있습니다. - 모델마다 제공되는 기능이 다릅니다. 문서를 읽고 프로젝트에 맞는 모델을 선택하세요. - 일부 모델은 특정 국가에서 사용이 제한될 수 있습니다. 이용 약관을 확인하세요. --- ## 5. AWS_CLI_설치_및_설정 모델 액세스까지 받은 김개발 씨는 이제 코드를 작성하고 싶었습니다. "콘솔에서 버튼만 누르는 건 답답해요. 진짜 개발자처럼 터미널에서 작업하고 싶어요." 박시니어 씨가 노트북을 열며 말했습니다. "그럼 AWS CLI부터 설치해야죠." **AWS CLI**(Command Line Interface)는 터미널에서 AWS 서비스를 제어할 수 있는 명령줄 도구입니다. 마치 마우스 없이 키보드만으로 컴퓨터를 조작하는 것처럼, CLI를 사용하면 웹 콘솔 없이도 모든 AWS 작업을 수행할 수 있습니다. 자동화와 스크립트 작성에 필수적입니다. 다음 코드를 살펴봅시다. ```python # AWS CLI 설치 확인 및 기본 사용법 # 터미널에서 실행하는 명령어들 # AWS CLI 버전 확인 (설치 여부 확인) aws --version # 현재 설정된 자격 증명 확인 aws sts get-caller-identity # Bedrock 모델 목록 조회 (CLI 사용 예제) aws bedrock list-foundation-models --region us-east-1 # 특정 S3 버킷 목록 조회 aws s3 ls # EC2 인스턴스 목록 조회 aws ec2 describe-instances --region ap-northeast-2 ``` 김개발 씨는 터미널 화면을 보며 두근거렸습니다. "진짜 해커 같은데요?" 박시니어 씨가 웃었습니다. "해커까지는 아니고, 그냥 효율적인 개발자죠." AWS CLI란 정확히 무엇일까요? 쉽게 비유하자면, CLI는 마치 자동차의 수동 변속기와 같습니다. 자동 변속기(웹 콘솔)는 편하지만 세밀한 제어가 어렵습니다. 수동 변속기(CLI)는 처음엔 어렵지만, 익숙해지면 훨씬 빠르고 정확하게 제어할 수 있습니다. 게다가 같은 작업을 반복할 때는 스크립트로 자동화할 수 있습니다. CLI가 없던 시절에는 어땠을까요? 모든 작업을 웹 콘솔에서 클릭으로 해야 했습니다. EC2 인스턴스 10개를 만들려면 같은 버튼을 10번 눌러야 했습니다. 실수로 잘못 클릭하면 처음부터 다시 시작해야 했습니다. 더 큰 문제는 작업 내역을 기록하기 어렵다는 것이었습니다. 어떤 설정을 어떻게 바꿨는지 나중에 재현할 방법이 없었습니다. 바로 이런 문제를 해결하기 위해 **AWS CLI**가 등장했습니다. CLI를 사용하면 한 줄의 명령어로 복잡한 작업을 수행할 수 있습니다. 같은 명령어를 스크립트 파일에 저장해두면 언제든 똑같이 재현할 수 있습니다. 무엇보다 Git으로 버전 관리를 하면, 인프라 변경 사항을 코드처럼 추적할 수 있습니다. AWS CLI 설치 과정을 운영체제별로 살펴보겠습니다. **Windows 사용자**라면 AWS 공식 사이트에서 MSI 인스톨러를 다운로드합니다. 더블클릭으로 설치하면 끝입니다. PowerShell이나 CMD에서 `aws --version`을 입력해 정상 설치되었는지 확인합니다. **macOS 사용자**는 터미널을 열고 간단한 명령어를 입력합니다. `curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"`로 패키지를 다운로드하고, `sudo installer -pkg AWSCLIV2.pkg -target /`로 설치합니다. 또는 Homebrew를 사용한다면 `brew install awscli`만 입력하면 됩니다. **Linux 사용자**는 배포판에 따라 방법이 조금 다릅니다. 우분투라면 `sudo apt install awscli`로 간단히 설치할 수 있습니다. 하지만 최신 버전을 원한다면 공식 설치 스크립트를 사용하는 것이 좋습니다. 설치가 완료되면 `aws --version`을 실행해봅니다. `aws-cli/2.15.0 Python/3.11.6` 같은 출력이 나오면 성공입니다. 실제 현업에서는 어떻게 활용할까요? DevOps 엔지니어들은 CLI로 **인프라를 코드로 관리**합니다. 예를 들어 개발 서버 100대를 만들어야 한다면, for 루프를 돌며 `aws ec2 run-instances` 명령을 반복합니다. 몇 초 만에 모든 서버가 생성됩니다. **CI/CD 파이프라인**에서도 CLI는 필수입니다. GitHub Actions나 Jenkins에서 코드를 빌드한 후, `aws s3 cp`로 S3에 업로드하고, `aws cloudfront create-invalidation`으로 캐시를 무효화합니다. 모든 과정이 자동으로 진행됩니다. **비용 모니터링 스크립트**를 만들 수도 있습니다. 매일 아침 `aws ce get-cost-and-usage` 명령으로 어제 사용한 비용을 조회하고, 슬랙으로 알림을 보냅니다. 예산 초과를 미리 방지할 수 있습니다. 하지만 주의할 점도 있습니다. 초보자들이 가장 많이 하는 실수는 **구버전 CLI를 사용하는 것**입니다. 패키지 매니저로 설치하면 오래된 버전이 설치될 수 있습니다. Bedrock 같은 최신 서비스는 CLI v2에서만 지원되므로, 반드시 최신 버전을 설치해야 합니다. 또 다른 실수는 **명령어 옵션을 정확히 모르고 쓰는 것**입니다. `--dry-run` 옵션을 붙이면 실제로 실행하지 않고 미리 결과를 확인할 수 있습니다. 특히 `delete`나 `terminate` 같은 위험한 명령은 반드시 dry-run으로 먼저 테스트해야 합니다. 가장 위험한 실수는 **와일드카드를 잘못 사용하는 것**입니다. `aws s3 rm s3://my-bucket/* --recursive`를 실수로 입력하면 버킷의 모든 파일이 삭제됩니다. 복구가 불가능할 수 있으므로, 항상 명령어를 두 번 확인해야 합니다. 김개발 씨는 터미널에서 `aws --version`을 입력했습니다. 버전 정보가 화면에 출력되자 뿌듯한 미소를 지었습니다. "이제 진짜 개발자 같네요!" 하지만 박시니어 씨가 손을 저었습니다. "아직 끝이 아니에요. CLI를 설치했다고 바로 쓸 수 있는 건 아닙니다. 자격 증명을 설정해야 해요." AWS CLI를 설치하는 것은 시작에 불과합니다. 진짜 중요한 건 어떻게 안전하게 인증하느냐입니다. 다음 단계에서 자격 증명 설정 방법을 배워보겠습니다. **실전 팁** 💡 - CLI 명령어가 기억나지 않으면 `aws help`로 도움말을 볼 수 있습니다. - `--output json` 옵션을 쓰면 결과를 JSON으로 받아 jq 같은 도구로 파싱할 수 있습니다. - AWS CloudShell을 사용하면 설치 없이 브라우저에서 CLI를 쓸 수 있습니다. --- ## 6. 자격_증명_구성하기 CLI를 설치한 김개발 씨는 바로 명령어를 입력해봤습니다. `aws s3 ls`를 실행했지만 에러만 떴습니다. "Unable to locate credentials." 박시니어 씨가 설명했습니다. "AWS가 당신이 누군지 모르니까 명령을 거부하는 거예요. 신분증을 보여줘야 합니다." **자격 증명 구성**은 AWS CLI가 여러분의 계정으로 작업할 수 있도록 인증 정보를 설정하는 과정입니다. 마치 ATM에 카드를 넣고 비밀번호를 입력하는 것처럼, Access Key ID와 Secret Access Key를 등록해야 합니다. 이 정보 없이는 어떤 AWS 작업도 수행할 수 없습니다. 다음 코드를 살펴봅시다. ```python # 자격 증명 구성 및 확인 스크립트 import boto3 import os # 방법 1: 환경 변수로 자격 증명 설정 (임시 테스트용) # os.environ['AWS_ACCESS_KEY_ID'] = 'YOUR_ACCESS_KEY' # os.environ['AWS_SECRET_ACCESS_KEY'] = 'YOUR_SECRET_KEY' # os.environ['AWS_DEFAULT_REGION'] = 'us-east-1' # 방법 2: AWS CLI 구성 파일 사용 (권장) # ~/.aws/credentials 파일에서 자동으로 읽어옴 # 현재 자격 증명으로 신원 확인 sts = boto3.client('sts') identity = sts.get_caller_identity() print("현재 인증 정보:") print(f" 계정 ID: {identity['Account']}") print(f" 사용자 ARN: {identity['Arn']}") print(f" 사용자 ID: {identity['UserId']}") # 설정된 리전 확인 session = boto3.session.Session() print(f"\n현재 리전: {session.region_name}") ``` 김개발 씨는 당황했습니다. "분명 로그인했는데 왜 인증이 안 되죠?" 합리적인 의문이었습니다. 웹 콘솔에서는 로그인만 하면 모든 게 됐으니까요. 박시니어 씨가 차분히 설명했습니다. "웹 브라우저는 쿠키와 세션으로 로그인 상태를 유지합니다. 하지만 터미널은 브라우저가 아니에요. 별도의 인증 방법이 필요합니다." 자격 증명이란 정확히 무엇일까요? 쉽게 비유하자면, 자격 증명은 마치 호텔 객실 카드키와 같습니다. 프론트에서 체크인할 때(웹 로그인) 받는 카드키(Access Key)로 방문(AWS 리소스)을 열 수 있습니다. 카드키를 잃어버리면 아무것도 할 수 없습니다. 하지만 프론트에 다시 가면 새 카드키를 받을 수 있습니다. 자격 증명이 없던 시절에는 어땠을까요? 매번 명령어를 실행할 때마다 ID와 비밀번호를 입력해야 했습니다. 자동화 스크립트에 비밀번호를 하드코딩해야 했고, 이는 엄청난 보안 위험이었습니다. 더 큰 문제는 여러 계정을 사용할 때 매번 로그아웃하고 다시 로그인해야 한다는 것이었습니다. 바로 이런 문제를 해결하기 위해 **액세스 키 기반 인증**이 도입되었습니다. 액세스 키를 한 번 설정해두면 이후로는 자동으로 인증됩니다. 여러 계정의 자격 증명을 프로필로 저장해두고, 필요할 때마다 `--profile` 옵션으로 전환할 수 있습니다. 무엇보다 키를 분실하거나 유출되면 즉시 폐기하고 새로 발급받을 수 있습니다. 자격 증명 구성 과정을 단계별로 살펴보겠습니다. 먼저 **IAM 콘솔에서 액세스 키를 생성**해야 합니다. 자신의 IAM 사용자 페이지로 가서 "Security credentials" 탭을 클릭합니다. "Create access key" 버튼을 누르면 용도를 선택하는 화면이 나타납니다. "Command Line Interface (CLI)"를 선택하고 다음으로 넘어갑니다. 경고 메시지가 나타나지만 "I understand" 체크박스를 선택하고 진행합니다. 마지막 화면에서 **Access Key ID**와 **Secret Access Key**가 표시됩니다. 이 화면은 단 한 번만 보이므로, 반드시 안전한 곳에 저장해야 합니다. CSV 파일로 다운로드하는 것이 좋습니다. 이제 터미널을 열고 `aws configure`를 입력합니다. 네 가지 질문이 나옵니다. 첫 번째는 **AWS Access Key ID**입니다. 방금 생성한 키를 붙여넣습니다. 두 번째는 **AWS Secret Access Key**입니다. 역시 복사해서 붙여넣습니다. 세 번째는 **Default region name**입니다. 주로 사용할 리전을 입력합니다. 서울은 `ap-northeast-2`, 도쿄는 `ap-northeast-1`, 버지니아는 `us-east-1`입니다. Bedrock을 쓸 거라면 `us-east-1`을 입력합니다. 네 번째는 **Default output format**입니다. `json`, `yaml`, `text` 중 선택할 수 있습니다. 대부분 `json`을 사용합니다. 모든 입력을 마치면 자격 증명이 `~/.aws/credentials` 파일에 저장됩니다. `aws sts get-caller-identity`를 실행하면 현재 인증된 사용자 정보가 출력됩니다. 실제 현업에서는 어떻게 활용할까요? 대부분의 개발자는 **여러 프로필을 관리**합니다. 개인 계정, 회사 개발 계정, 회사 운영 계정을 모두 다른 프로필로 저장합니다. `aws configure --profile personal`, `aws configure --profile work-dev` 같은 식으로 각각 설정합니다. 사용할 때는 `aws s3 ls --profile work-dev`처럼 프로필을 지정합니다. **환경 변수**를 활용하는 경우도 많습니다. CI/CD 파이프라인에서는 `AWS_ACCESS_KEY_ID`와 `AWS_SECRET_ACCESS_KEY` 환경 변수를 설정합니다. 이렇게 하면 configure 명령 없이도 자격 증명이 작동합니다. **IAM 역할**을 사용하는 것이 가장 안전합니다. EC2 인스턴스나 Lambda 함수에서 작업할 때는 액세스 키를 전혀 사용하지 않습니다. 인스턴스에 역할을 부여하면 자동으로 임시 자격 증명이 생성됩니다. 하지만 주의할 점도 있습니다. 초보자들이 가장 많이 하는 실수는 **액세스 키를 GitHub에 올리는 것**입니다. 코드에 하드코딩하거나 `.env` 파일을 실수로 커밋하면, 봇들이 즉시 발견하고 악용합니다. 몇 분 만에 수백만 원의 요금이 청구될 수 있습니다. 또 다른 실수는 **루트 계정의 액세스 키를 만드는 것**입니다. 루트 계정은 모든 권한을 가지고 있어 매우 위험합니다. 반드시 IAM 사용자의 키만 사용해야 합니다. 가장 흔한 함정은 **액세스 키를 정기적으로 교체하지 않는 것**입니다. 한 번 만든 키를 몇 년씩 쓰는 경우가 많습니다. 하지만 키가 유출되었는지 모를 수 있으므로, 90일마다 새 키로 교체하는 것이 좋습니다. 김개발 씨는 신중하게 자격 증명을 설정했습니다. `aws sts get-caller-identity`를 실행하자 자신의 계정 정보가 출력되었습니다. "드디어 됐어요!" 환호성을 질렀습니다. 박시니어 씨가 만족스럽게 고개를 끄덕였습니다. "이제 진짜 개발자가 됐네요. AWS의 모든 문이 열렸어요." 자격 증명을 올바르게 설정하면 로컬 개발 환경에서 AWS의 모든 서비스를 자유롭게 사용할 수 있습니다. 이제 여러분도 Bedrock으로 AI 애플리케이션을 만들 준비가 완료되었습니다. **실전 팁** 💡 - AWS Vault나 aws-mfa 같은 도구를 사용하면 MFA와 임시 자격 증명을 쉽게 관리할 수 있습니다. - 액세스 키를 절대 슬랙이나 이메일로 공유하지 마세요. IAM 역할이나 AssumeRole을 사용하세요. - AWS Secrets Manager에 자격 증명을 저장하면 코드에서 안전하게 불러올 수 있습니다. --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: AWS

언어: Python

태그: AWS, IAM, Bedrock, CLI, Credentials

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

AWS 환경 설정 완벽 가이드

목차

1. AWS 계정 생성하기

2. IAM 사용자 및 역할 설정

3. Bedrock 서비스 활성화

4. 모델 액세스 요청하기

5. AWS CLI 설치 및 설정

6. 자격 증명 구성하기

댓글 (0)

함께 보면 좋은 카드 뉴스

Helm 마이크로서비스 패키징 완벽 가이드

보안 아키텍처 구성 완벽 가이드

AWS Organizations 완벽 가이드

AWS KMS 암호화 완벽 가이드

AWS Secrets Manager 완벽 가이드