코드 에이전트가 장시간 오랫동안 목적을 지속적으로 수행하도록 하기 위한 작업이다. 적절한 가이드를 제공함으로써 개발 과정의 효율을 높일 수도 있고 돌발 상황에 대한 안전장치가 될 수도 있다.

코드 에이전트 기술

Harness를 다루기 전에 코드 에이전트와 관련된 여러 가지 용어와 기술에 대해서 알아보자.

• AGENTS.md
• Skill
• MCP (Model Context Protocol)
• 멀티 에이전트

AGENTS.md

코드 에이전트에서 우선적으로 사용되는 규칙, 지침 파일이다.

코드 에이전트별로 다르며 Claude code에서는 CLAUDE.md 파일을 사용한다.

작동 방식

• Context Window에 사용자 입력과 AGENTS.md의 내용이 같이 들어간다.

context window: 모델이 한 번에 받아들이는 입력 내용의 영역으로 크기가 제한되어 있다.

AGENTS.md 작성 가이드

• 프로젝트 구성요소에 대한 설명 명시한다.
• 프로젝트의 행동 규칙(Rule) 명시한다.
• 최대한 변하지 않을 내용으로 작성한다.
  • 자주 변경되면 Agent도 혼란을 겪을 수 있다.
• 간략하게 작성한다.
  • 디테일할수록 context를 많이 차지하고, 토큰 소모량 증가하며, 변경될 확률이 증가한다.
• 디테일한 내용은 분리된 md 파일로 작성하여 필요할 때 읽도록 명시한다.

Skill

에이전트에게 특정 작업을 수행하는 방법을 정의하여, 재사용 가능한 지식, 능력 패키지이다. AGENTS.md와 달리, on-demand 방식으로 필요할 때만 동적으로 불러온다.

Skill metadata

각 Skill은 SKILL.md 파일을 가지는데 여기에는 Skill의 metadata (name, description) 정보가 함께 들어있다. 코드 에이전트는 스킬 목록에서 metadata를 불러와서 스킬을 로드할지 판단한다.

use case

• 자주 반복되는 프롬프트를 하나의 명령(skill)으로 생성
• 파일 편집 / 명령어 실행 / 인터넷 검색 같은 Tool을 사용하는 명령(skill)으로 생성

MCP (Model Context Protocol)

코드 에이전트에서 수많은 외부 서비스를 통일된 방식으로 연결하기 위한 표준 프로토콜이다.

멀티 에이전트

단일 에이전트에서 복잡한 업무를 처리할 때 Context Window에 입력된 많은 정보로 성능이 떨어질 수 있다. 멀티 에이전트는 복잡한 업무를 여러 단계로 나누어 각각의 전문가(서브 에이전트)에게 업무를 분배하고 다음과 같은 특성을 이용하여 효율적으로 처리한다.

• 격리(isolation) — 각 에이전트는 자신만의 독립된 Context를 가진다.
• 병렬성(parallelism) — 각 에이전트는 동시에 병렬로 작업할 수 있다.

궁금한 점
모델이 100k의 컨텍스트를 지원한다고 할 때, 멀티 에이전트로 구성할 경우 각 서브 에이전트는 100k의 컨텍스트를 가질까? => Yes

멀티 에이전트의 단점 토큰 소비량이 많아진다. 각 에이전트 별로 독립된 Context를 가지기 때문에, 초기화 비용이 중복으로 발생한다.

Harness 적용하여 개발하기

• Harness 구성
• 요구사항 문서 작성
• Phase 수립 및 개발

Harness 구성

• AGENTS.md 파일 생성 (claude의 경우 CLAUDE.md)
• 프로젝트 내용 작성
• 하네스 구성
  • 주의사항 명시
  • 프레임워크, 도구 명시

Andrej-karpathy skill

https://github.com/multica-ai/andrej-karpathy-skills https://github.com/multica-ai/andrej-karpathy-skills/blob/main/CLAUDE.md

AI 코딩 에이전트의 흔한 실수를 줄이기 위해 사용되는 유명한 지침 (2026-07 기준 Github Stars 수 약 200k)

이런 기본적인 하네스를 구성하는 것도 좋지만, 이는 LLM, 코드 에이전트가 발전할수록 필요성이 떨어질 것이다.
나의 프로젝트에 맞게 최적화된 Harness를 구성하는 것이 더 중요하다.

요구사항 문서 작성

• PRD (Product Requirements Document) 작성
• Specification 문서 작성

PRD (Product Requirements Document) 작성

• 고객 입장에서 어떤 프로그램을 원하는지 작성한다.
• 개발적인 지식이 들어가면 안 된다.

Specification 문서 작성

• 요구사항 문서보다 디테일하게 기준을 정리하는 문서

Superpowers Skill의 /brainstorming을 사용하면 질의응답을 통해, 모도한 요구사항을 더 명확하게 만들 수 있다.

Phase 수립 및 개발 수행

• Phase 작성
• 서브 에이전트 구성
• Workflow 구성
• Feedback loop 구성

Phase 작성

단계별로 어떤 내용을 개발할지 계획 각 Phase 별로 동작되어야 하며 사람이 직접 테스트 가능해야 한다.

• ex) 로그분석 차트 개발
  • Phase 1: UI 구성
  • Phase 2: 파일 URL
  • Phase 3: 데이터 파싱
  • Phase 4: API 별 Latency 측정 통계 계산
  • Phase 5: 차트 출력

서브 에이전트 구성

코드 품질을 높이기 위해 각 Phase 마다, 4단계 작업을 구성하고 각 에이전트가 이를 담당하게 구성한다.

• coding
• test
• review
• verify

ex) claude .claude/ ├── agents/ │ ├── coder.md # 구현 (Coding) │ ├── tester.md # 테스트 작성·실행 (Test) │ ├── reviewer.md # 정확성/보안/품질 리뷰 (Review) │ └── verifier.md # end-to-end 동작 검증 (Verify)

Workflow 구성

• 각 서브 에이전트를 순서대로 실행하도록 Workflow를 구성한다.

Claude Code 전용 기능
서브 에이전트들의 Workflow를 구성하여 실행해 주는 JavaScript 코드를 만들어 준다.

Feedback loop 구성

일부 작업이 실패하더라도 개발 수행이 중단되지 않도록 하는 안전장치(Harness)가 필요하다. 각 에이전트 수행 중 실패 시 코드 수정 후, 다시 test 단계로 되돌아가는 피드백 루프를 추가한다.

More

Harness Engineering 잘하기 위해서 많이 사용되는 AI Harness를 적용해 보면 좋을 것 같다.

• Superpowers
• G-Stack
• Oh My Opencode (Oh My Claudecode)
• Hands off
• ...

Agile 이란?

Agile 교육도 받고 이 단어를 참 많이 들었지만, 아직도 나는 Agile이 무엇인지 모른다. 아마 정확하게 설명할 수 있는 사람도 없을 거라 생각한다. 다만 내 기억 속에서 느낀 대로 설명하자면, Agile에서는 다음 세 가지를 강조하는 듯하다.

• 고객 중심
• 피드백
• 민첩성 (작은 단위)

고객의 입장에서 생각하면서 개발하고, 작은 스프린트로 빠르게 피드백을 받아 더 나은 서비스를 만들자. 정도로 해석해 보았다.

서비스 기획 프로세스

아래는 Agile 교육에서 기억에 남고 유용하면서도 재미있었던 과정들이라 우리 팀에 가져와서 적용해 보았다.

• Persona
• Customer Journey Map
• Feature Identification
• Feature Estimation
• Feature Pyramid

우리는 꿈 일기 공유 플랫폼이라는 주제를 가지고 시작했기 때문에, 주제를 선정하기 위한 단계는 생략하고 페르소나부터 진행하였다.

Persona

Persona(페르소나)는 가상의 고객을 가정한다. 고객의 입장이 되어, 우리 서비스를 찾는 과정, 서비스를 이용하면서 얻으려는 것이 무엇인지 예상해 보는 것이다. Confluence에서 괜찮은 Persona Template을 제공하여 이를 변형하여 사용하였다.

꿈 일기 공유 플랫폼을 사용할 법한 10대 ~ 30대로 범위를 정해두고 여러 페르소나를 만들어 보았다. 다양한 가상의 인물을 만들어 보니 다양한 니즈를 예상해 볼 수 있었다.

Customer Journey Map

Customer Journey Map에서는 앞서 만들어둔 페르소나(고객)가 우리 서비스를 이용하는 여정을 여러 단계의 시나리오로 만들어 본다. 단계별로 고객의 감정 변화를 시각화하고 문제점을 예상해 보면서 더 나은 솔루션을 만들어보는 과정이다. 이번에도 Confluence에서 Customer journey mapping Template 을 제공하여 이를 사용했다.

Customer Journey Map을 진행할 때는 각 단계에서의 감정이 어떨지 예상하고, 문제점을 만들어 보는 것이 쉽지 않았다. 그래도 이런 시나리오를 만들고 이입하여 실행해 보니 재밌는 아이디어들을 많이 찾아낼 수 있어서 굉장히 만족스러운 단계였다.

Feature Identification

Feature Identification은 Customer Journey Map에서 도출한 문제점, 솔루션들을 토대로 Feature(기능)를 정리해 보는 과정이다.

Customer Journey Map에서 나온 솔루션들이 명확해서 기능을 도출하는 데 큰 어려움은 없었다. 미리 생각하고 있던 기본적인 기능들부터 Persona, Customer Journey Map을 통해 얻은 새로운 아이디어까지 세분화하니 정말 많은 기능들이 나왔다.

점수를 부여하여 기능의 사이즈를 정하는 Feature Estimation 단계도 있지만, 너무 많은 공수가 들면 팀이 지칠 것 같아 생략하였다.

Feature Pyramid

짧은 시간 내에 모든 기능들을 다 구현할 수는 없다. 따라서 Feature Pyramid에서는 기능의 가치, 선행 관계 등을 고려하여 우선순위를 정해서 피라미드 형태로 표현하고 하위에 배치된 일부 기능들은 보류하거나 걷어낸다.

우리는 먼저 Slack에서 Polly라는 기능을 사용하여 팀에서 각 Feature의 중요도를 조사하였다. 팀원들이 각 기능마다 1점~5점으로 중요도(가치)를 투표하고, 평균을 내어 점수를 내었다. (아쉽게도 Polly 무료 플랜에서는 45일이 지난 투표 결과를 보여주지 않는다...)

투표 결과 점수로 선 정렬한 후 토론을 통해서 순서를 재조정하였다. 애플리케이션 형태를 위해 기본적인 기능들이 선순위 작업으로 올라왔다. 중요도가 높지만 유사한 가치를 제공하는 기능이나 사이즈가 너무 큰 기능은 아래로 밀려났다. (겪어 보니 Feature Estimation을 통해 사이즈를 예상해 보면 좋았겠다는 생각도 들었다.)

Next

지금까지 4가지 단계를 거쳐서 기능을 도출하고, 개발 순서도 정해보았다. 처음에는 이 과정들을 우리가 잘 적용할 수 있을까 하는 걱정이 있었는데, 결과도 아주 만족스러웠고 팀원들의 반응도 긍정적이었다. 다음으로는 우리 팀이 협업을 위해 사용하는 도구들과, 협업/개발 과정을 하나씩 소개해 보겠다.

테스트 더블을 사용하면 테스트를 단순화하고 외부 환경과 독립된 코드를 테스트할 수 있다는 장점이 있다. 테스트 더블에는 다양한 종류가 있지만 여기서는 Stub과 Mock을 통칭하여 Mock이라고 부르겠다.

Mocking - 의존성 주입

• client.py

class Client:
    def list_items(self):
        raise Exception("Network Exception!")

Mocking 여부를 쉽게 파악할 수 있도록, list_items가 에러를 발생시키도록 구현하였다.

• service.py

import client


class Service:
    def __init__(self, _client: client.Client):
        self.client = _client

    def do_list(self):
        return self.client.list_items()

• test_service.py

from unittest import TestCase
from unittest.mock import Mock

from service import Service


class TestService(TestCase):
    def test_do_list(self):
        # given
        mock_client = Mock()
        mock_client.list_items.return_value = ['item1', 'item2', 'item3']
        target_service = Service(mock_client)
        # when
        result = target_service.do_list()
        # then
        self.assertEqual(result, ['item1', 'item2', 'item3'])

일반적인 언어에서는 의존성 주입 형태로 구현해 두어야, 대상 서비스를 생성할 때 Mock 객체를 주입하여 Mock 테스트를 구현할 수 있다.

Python에서의 Mocking

Python에서는 위처럼 의존성 주입 형태로 구현하지 않아도 unittest.mock.patch를 이용하여 Mocking을 수행할 수 있다.

• client.py

def list_items():
    raise Exception("Network Exception!")

• service.py

import client


def do_list():
    return client.list_items()

• test_service.py

from unittest import TestCase
from unittest.mock import patch

import service


class TestService(TestCase):
    @patch('client.list_items', return_value=['items1', 'items2', 'items3'])
    def test_do_list(self, mock_list_items):
        result = service.do_list()
        self.assertEqual(result, ['items1', 'items2', 'items3'])

patch는 Namespace에 등록된 이름이 생성한 Mock 객체를 가리키도록 한다.

Python mock 주의사항

Python unittest에서는 의존성 주입 형태로 구현하지 않더라도 Mock을 주입할 수 있는 강력한 기능을 제공한다. 하지만 위 코드에서 import client 부분을 from client import list_items로 변경한다면 Mocking이 제대로 이루어지지 않고 테스트는 실패한다. 원인을 제대로 이해하기 위해 Python의 Namespace에 대해서 자세히 알아보자.

https://docs.python.org/ko/3/library/unittest.mock.html#id6

Python namespace

Python에서 Namespace는 Object 정보를 가리키는 이름을 매핑해 둔 공간으로 Dictionary(Key:Value) 형태로 저장된다.

• Key: Name
• Value: Object address

종류

Namespace에는 다음과 같이 4가지 종류가 있다.

• Function namespace (Local namespace)
• Enclosing namespace
• Module namespace (Global namespace)
• Built-in namespace

위 순서와 같이 좁은 범위에서 넓은 범위로 탐색한다.

Python에서 패키지는 디렉터리 단위, 모듈은 파일 단위로 볼 수 있다.

Python import

Python에서는 일반적으로 2가지 방식의 import 구문을 가지고 있다.

• 모듈을 Import from <package> import <module>
• 모듈 내 함수를 Import from <module> import <function>

이렇게 다른 import 문이 Namespace에서 어떤 차이가 있는지 예제를 통해서 살펴보자.

모듈을 Import 하는 경우

• client.py

def list_items():
    raise Exception("Network Exception!")

• service.py

import client


def do_list():
    return client.list_items()

service.py 모듈의 Namespace에 client라는 이름이 등록되고, 이는 client.py 모듈의 경로를 가리킨다.

테스트

from unittest import TestCase
from unittest.mock import patch

import service


class TestService(TestCase):
    @patch('client.list_items', return_value=['items1', 'items2', 'items3'])
    def test_do_list(self, mock_list_items):
        result = service.do_list()
        self.assertEqual(result, ['items1', 'items2', 'items3'])

service.py 모듈의 client는 실제 client.py를 가리키기 때문에 client.list_items를 패치하면 do_list가 Mock list_items를 호출하게 된다.

모듈 내 함수를 Import 하는 경우

• client.py

def list_items():
    raise Exception("Network Exception!")

• service.py

from client import list_items


def do_list():
    return list_items()

앞 예제에서 service.py 모듈에서 기능은 변경하지 않고 import 구문만 (함수를 직접 import 하도록) 수정하였다.

위처럼 함수를 직접 import 할 경우, service.py 모듈의 Namespace에 list_items라는 이름이 등록되고, 이는 실제 list_items 함수를 가리킨다.

테스트 (기존과 동일)

from unittest import TestCase
from unittest.mock import patch

import service


class TestService(TestCase):
    @patch('client.list_items', return_value=['items1', 'items2', 'items3'])
    def test_do_list(self, mock_list_items):
        result = service.do_list()
        self.assertEqual(result, ['items1', 'items2', 'items3'])

테스트 코드를 변경하지 않았다면, client.py 모듈의 list_items는 패치되어 Mock 객체를 가리키지만, do_list가 호출하는 service.py 모듈의 list_items는 여전히 실제 list_items 함수를 가리키고 있다.

테스트 (patch 구문 수정)

from unittest import TestCase
from unittest.mock import patch

import service


class TestService(TestCase):
    @patch('service.list_items', return_value=['items1', 'items2', 'items3'])
    def test_do_list(self, mock_list_items):
        result = service.do_list()
        self.assertEqual(result, ['items1', 'items2', 'items3'])

client.py 모듈의 list_items가 아닌 service.py 모듈의 list_items를 패치하면, 테스트 대상인 do_list 함수에서 호출하는 list_items가 정상적으로 Mocking되어 테스트가 성공한다.

결론

import 구문을 다양한 방식으로 사용할 경우 단위 테스트의 Mock 처리에서 혼란을 일으킬 수 있다. 따라서 import 하는 방법을 하나로 통일하여 컨벤션으로 정해두는 것을 추천한다. 개인적으로는 모듈을 import 하는 방법을 선호한다.

또 다른 방법으로는 Mocking 대상을 다른 언어와 같이 (Dependency Injection으로 구현하지 않더라도) 클래스로 구현하는 방법이 있다. 원리는 다음 글에서 설명하겠다.

참고 자료

https://docs.python.org/ko/3/library/unittest.mock.html https://realpython.com/python-namespaces-scope/

Logging 코드 (Python)

import logging

logger = logging.getLogger()
logger.setLevel(logging.INFO)

stream_handler = logging.StreamHandler()
logger.addHandler(stream_handler)

def main():
    logger.debug("Debug[Level: 10]")
    logger.info("Info[Level: 20]")
    logger.warning("Warning[Level: 30]")
    logger.error("Error[Level: 40]")
    logger.critical("Critical[Level: 50]")

if __name__ == '__main__':
    main()

Info[Level: 20]
Warning[Level: 30]
Error[Level: 40]
Critical[Level: 50]

Python에서 로그를 출력하는 간단한 예제를 가져왔다. 로그는 설정한 Level 이상의 로그만 출력된다. 위 코드에서는 INFO level 이상의 로그만 출력된다.

Logging level

https://docs.python.org/3/library/logging.html

AWS Lambda log

AWS Lambda에서 출력한 내용은 CloudWatch에서 확인할 수 있다.

권한

AWS Lambda 함수를 생성할 때 역할을 생성하도록 하면, CloudWatch 로그 그룹을 생성하고 해당 로그 그룹에 로그를 작성할 수 있는 권한이 생성된다.

Example

import json
import logging

logger = logging.getLogger()
logger.setLevel(logging.INFO)

def lambda_handler(event, context):
    logger.debug("Debug: %s" %event)
    logger.info("Info: %s" %event)
    logger.warning("Warning: %s" %event)
    logger.error("Error: %s" %event)
    logger.critical("Critical: %s" %event)
    return {
        'statusCode': 200,
        'body': json.dumps('Hello from Lambda!')
    }

예제를 Test로 실행하고 CloudWatch에서 확인해 보자.

Amazon CloudWatch

AWS Lambda 로그

로그 스트림에서 함수 실행 전후로 START, END, REPORT 정보를 Request ID와 함께 출력해 주는 것을 확인할 수 있다. Logging 함수로 출력한 로그에도 Request ID가 Prefix로 들어가 있다.

Live Tail

Live tail은 CloudWatch의 로그를 실시간으로 확인할 수 있는 기능이다. 로그 그룹을 선택해 시작한 후, Lambda에서 테스트를 실행하면, 로그를 실시간으로 확인할 수 있을 것이다.

Log Insights

Log Insights에서는 쿼리를 통해서 원하는 로그를 검색할 수 있다. 위처럼 like 키워드를 이용해서 특정 단어가 포함된 로그를 검색할 수 있다.

특정 로그를 처음부터 끝까지 보고 싶다면 @requestId 필드를 조건으로 검색해 보자.

CloudWatch 로그 인사이트 쿼리 구문 에서 자세한 쿼리 문법을 확인할 수 있다.

AWS Lambda

언제 AWS Lambda를 사용해야 할까? 라는 질문에는 여러 가지 고려 사항이 있겠지만, AWS Lambda의 요금 정책이 어느 정도 답안을 줄 수 있다. Lambda의 요금은 CPU, 메모리 사양과 요청 수, 실행한 시간에 따라 결정된다. 따라서 많이 호출될수록, 오래 실행될수록 많은 요금이 많이 발생한다. 대신 드물게 요청되면서 짧은 시간 안에 처리되는 로직이라면 직접 서버를 프로비저닝하여 애플리케이션을 운영하는 것보다 노력과 비용을 절감할 수 있다.

AWS Lambda 요금

예제

AWS Lambda의 기능, 사용 방법을 더 잘 이해하기 위해 네트워크 비용 절감을 위해 업로드된 프로필 사진의 썸네일 제작이라는 예제를 통해 살펴보자.

주의 사항 트리거로 사용한 버킷과 Lambda에서 생성하는 버킷을 다르게 설정하자. 동일하게 설정한다면, 트리거가 무한으로 작동하여 Lambda 요금이 정말 많이 나올 수 있다.

Lambda 트리거

Lambda에서는 API Gateway, S3 Event, SQS 등 다양한 트리거를 설정할 수 있다.

트리거 추가

gook-app-image 버킷의 모든 파일 생성 이벤트를 트리거로 등록하였다. (아래에는 트리거를 발생시킬 S3 버킷과 코드에서 대상으로 하는 S3 버킷을 동일하게 설정하면 재귀적인 호출로 Lambda 사용량이 높아질 수 있다는 경고를 보여주고 있다.)

코드

import boto3
import json
import os
from PIL import Image
from io import BytesIO


def lambda_handler(event, context):
    print(json.dumps(event))
    for record in event['Records']:
        source_bucket = record['s3']['bucket']['name']
        target_bucket = os.environ.get('THUMBNAIL_BUCKET')
        key = record['s3']['object']['key']
        file_extension = key.split('.')[-1].lower()
        if file_extension in ['jpg', 'jpeg', 'png', 'gif']:
            generate_thumbnail(source_bucket, target_bucket, key)
        else:
            print("Not supported image file")


def generate_thumbnail(source_bucket, target_bucket, path):
    s3_client = boto3.client('s3')
    response = s3_client.get_object(Bucket=source_bucket, Key=path)
    image_stream = BytesIO(response['Body'].read())
    thumbnail_stream = extract_thumbnail(image_stream)
    s3_client.put_object(Body=thumbnail_stream, Bucket=target_bucket, Key=path)
    print(f"Thumbnail generated and saved to {target_bucket}/{path}")


def extract_thumbnail(image_stream):
    image = Image.open(image_stream)
    image.thumbnail((100, 100))
    thumbnail_bytes = BytesIO()
    image.save(thumbnail_bytes, format='jpeg')
    thumbnail_bytes.seek(0)
    return thumbnail_bytes

환경 변수

예제 코드에서 대상 버킷에 대한 이름은 환경 변수를 통해 입력받는다. 환경 변수는 Lambda 함수 구성 > 환경 변수에서 설정할 수 있다.

라이브러리 설치

우리는 개발 환경이나 서버에서 Python 코드를 실행할 때 PIP를 이용해 필요한 라이브러리를 설치한다. Lambda에서 외부 라이브러리를 설치하는 방법을 알아보자.

boto3 라이브러리는 AWS Lambda에서 내장하고 있어 별도로 설치하지 않아도 된다.

라이브러리 zip 생성

pip install pillow -t ./python

예제 코드에서는 boto3를 제외하고 pillow라는 외부 라이브러리가 필요하다. Lambda에 추가하기 위해, 동일한 리눅스 환경에서 위 명령어를 통해 python 폴더 아래에 필요한 라이브러리를 설치하자.

그리고 필요한 라이브러리들이 설치된 이 python 폴더를 압축한다.

AWS Cloudshell 바로 접속할 수 있는 리눅스 서버가 없다면, AWS의 Cloudshell을 활용할 수 있다. Cloudshell은 무료로 사용할 수 있지만, AWS 네트워크 비용은 발생할 수 있다. https://docs.aws.amazon.com/ko_kr/cloudshell/latest/userguide/shell-pricing.html

계층(Layer) 생성

앞에서 압축한 zip 파일을 등록하여 Lambda 계층을 생성한다. 런타임을 라이브러리를 설치한 Python 버전과 맞춰주자.

계층 등록

Lambda 함수에서 Layers를 선택하고 [Add a layer]를 통해 앞에서 생성한 계층을 등록할 수 있다. 사용자 지정 계층에서 선택하거나 ARN을 직접 지정하면 된다.

권한 구성

gook-app-image 버킷에 이미지를 업로드하여, 예제 코드를 실행하면, S3 버킷에서 파일을 읽는 권한이 없어 Access Denied 에러가 발생한 것을 확인할 수 있다. S3 버킷에 있는 파일을 읽고, 쓰기 위한 권한이 필요하다.

Lambda에 연결된 역할 확인

Lambda 함수의 구성 > 권한으로 들어가면 할당된 역할을 확인할 수 있다.

Lambda 함수를 생성할 때 기본 Lambda 권한을 가진 새 역할 생성 옵션을 사용하였다면, ${함수명}-xxx라는 이름으로 역할이 생성되며, 기본적으로 함수의 로깅을 위한 권한 정책이 할당된다.

역할에 권한 정책 추가

우리는 gook-app-image 버킷에서 파일을 가져오는 권한과 gook-app-thumbnail 버킷에 파일을 업로드하는 권한이 필요하므로 역할에 다음과 같은 정책을 추가해 주자.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::gook-app-image/**"
        },
        {
            "Effect": "Allow",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::gook-app-thumbnail/**"
        }
    ]
}

각 Statement는 제한된 리소스(Resource) 범위에 대해서 특정 작업(Action)을 허용/거부(Effect) 할지 나타낸다.

결과 확인

로그

이제 권한을 추가했으니 gook-app-image 버킷에 이미지를 업로드하여 Lambda를 실행해 보자.

Lambda 함수가 에러 없이 잘 실행되었다.

썸네일

gook-app-thumbnail 버킷에 이미지가 잘 생성된 것을 확인할 수 있다.

200 x 200 크기의 이미지에서 100 x 100 크기의 썸네일이 잘 생성되었다.

Next

AWS Lambda가 무엇이고, 언제 어떻게 사용하는지 간단하게 알아보았다. 다음에는 트리거 유형의 차이와 Lambda 로그 확인 방법에 대해서 알아보자.

• 자격 증명 기반 정책
  • 사용자
  • 그룹
  • 역할
• 리소스 기반 정책
  • 버킷 정책(Bucket policy)
  • ACL (Access Control List)

AWS IAM (Identity and Access Management)

자격 증명(사용자, 그룹, 역할) 기반 정책은 이미 위 포스트에서 다루었다. 이번에는 주로 S3에서 많이 사용하는 리소스 기반 정책(특히 버킷 정책)에 대해서 알아보자.

Bucket policy

권한 없는 사용자

어떤 권한도 주지 않은 tester라는 사용자로, 콘솔에서 (URL을 통해) gook-policy-test 버킷에 접속해 보았다.

tester는 S3에 대한 권한이 없기 때문에, gook-policy-test라는 버킷 내의 어떤 파일도 확인할 수 없다.

S3에 버킷 정책 적용

tester라는 사용자에게 권한을 부여하는 대신 S3에 버킷 정책을 부여하여 tester에게 권한을 줄 수 있다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::{계정명}:user/{사용자명}"
            },
            "Action": [
                "s3:ListBucket",
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::{bucket 명}",
                "arn:aws:s3:::{bucket 명}/*"
            ]
        }
    ]
}

리소스 기반 정책에서는 Principal을 통해 권한을 적용할 주체(사용자, 그룹, 역할 등)을 지정할 수 있다. 내 계정의 tester를 지정해 주었다. Action을 통해 어떤 권한을 줄 것인지 지정하고, Resource에는 버킷과 버킷 내부의 모든 파일로 지정해 주었다.

공식 문서 IAM JSON 정책 요소 참조에서 자세히 확인할 수 있다.

권한 확인

버킷 정책을 통해 tester라는 사용자에게 gook-policy-test라는 버킷에 대해 s3:GetObject 권한을 부여하였다. 이제 tester는 gook-policy-test 버킷의 파일들을 확인할 수 있다.

다른 계정 간 권한 부여

앞에서 살펴 본 리소스 기반 정책 (버킷 정책)의 핵심은 자격 증명 주체(사용자, 그룹, 역할)가 아니라 리소스에게 정책을 할당하여 권한을 부여한다는 것이다.

자격 증명 기반 정책으로는 다른 계정에 있는 리소스에 대한 권한을 줄 수 없다. 하지만 리소스 기반 정책을 사용하면 위와 같이 다른 계정에 있는 사용자에게도 리소스에 대한 권한을 부여할 수 있다.

B 마음대로 A 계정에 있는 버킷에 접근 권한을 설정할 수는 없겠지만, A 계정이 본인의 S3 버킷에 대해 B 계정의 주체(사용자, 그룹, 역할)에게 권한을 줄 수 있는 것이다.

ACL (Access Control List)

ACL은 버킷 내의 파일 별로 접근 제어를 수행할 수 있지만 일반적으로 사용하는 방식은 아니다. AWS에서도 "Amazon S3의 최신 사용 사례 대부분은 더 이상 ACL을 사용할 필요가 없습니다. 각 객체에 대해 액세스를 개별적으로 제어할 필요가 있는 드문 상황을 제외하고는 ACL을 비활성화한 채로 두는 것이 좋습니다."라고 한다.

그래도 궁금하다면 ACL(액세스 제어 목록) 개요를 참고하자.

S3(Simple Storage Service)는 객체 스토리지 서비스로 버킷(Bucket)으로 구분된 단위에 파일(Object)를 저장할 수 있는 서비스이다.

S3 버킷 (Bucket)

S3는 파일(Object)을 버킷(Bucket)이라는 곳에 모아서 저장한다.

• 버킷은 리전 별로 생성된다.
• 버킷 이름은 AWS 전체에서 고유하게 설정해야 한다.
• 버킷 이름은 소문자, 숫자, '-'로 3-63 글자로 설정할 수 있다.

S3 오브젝트 (Object)

S3에 저장되는 파일을 의미한다. Object는 정확한 파일을 가리킬 수 있도록 Key를 가진다. 이 Key는 경로(Prefix)와 파일 이름(Object name)으로 구성된다.

ex) s3://buekct-name/path1/path2/object.txt

제한

• Object의 최대 크기는 5TB이다.
• 5GB가 넘는 파일을 업로드할 때는 Multi-part로 나누어서 업로드한다.

S3 storage class

S3는 목적에 맞게 사용할 수 있도록, 다음과 같이 성능, 검색 비용, 저장 비용 등이 구분된 Storage class를 가지고 있으며, 파일(Object) 별로 적용된다.

• Amazon S3 standard
  • General Purpose
  • Infrequent Access (IA)
• Amazon S3 Glacier
  • Instant Retrieval
  • Flexible Retrieval
  • Deep Archive
• Amazon S3 one zone
  • Infrequent Access

Amazon S3 Standard

S3 Standard(General Purpose)는 검색(조회) 비용이 저렴하여 자주 접근되는 파일을 저장할 때 용이하다. S3 standard-IA는 General Purpose와 성능은 동일하다. 대신 저장 비용이 더 저렴하고, 검색 비용은 더 비싸기 때문에 자주 접근되지 않는 데이터를 저장하는데 적합하다.

Amazon S3 Glacier

S3 Glacier는 저장 비용이 저렴하고, 검색 비용이 비싸기 때문에 거의 액세스 되지 않는 파일에 적합하다. 이 중에 S3 Glacier Instant Retrieval은 S3 Standard와 동일한 성능을 제공하지만, S3 Glacier Flexible Retrieval, S3 Glacier Deep Archive는 바로 접근할 수 없다. 접근하려면 복원 작업(클래스 변경)이 필요하다.

Amazon S3 One Zone

S3 One Zone은 3개의 가용 영역을 사용하는 다른 클래스와 달리 하나의 가용 영역만 사용하기 때문에 내구성/가용성이 떨어진다. 대신 저장 비용이 더 저렴하다.

자세한 성능 및 가격은 Amazon S3 스토리지 클래스을 참고하자

S3 Lifecycle Configuration

S3 Lifecycle Configuration을 활용하면 시간의 흐름에 따라 파일(Object)의 Storage class를 변경할 수 있다. 서버의 로그를 S3에 저장한다고 하자. 로그가 처음 한 달 동안만 자주 접근되고, 6개월 정도 지나면 거의 접근되지 않는다고 한다면 다음과 같이 설정할 수 있다.

RDS 기능

RDS는 다음과 같은 기능들을 제공하고 있다.

• Postgres, MySQL, MairaDB, Oracle, Mirosoft SQL Server, Aurora 지원
• 완전 관리형 서비스
  • 서버 및 데이터베이스 프로비저닝 자동화
  • OS 패치 자동화
• 지속적인 백업 생성
  • 자동으로 백업하여 특정 시점으로 복원할 수 있다.
  • 최대 35일 전까지
• 대시보드 모니터링
• Auto scaling
• 읽기 복제본 (Read replicas) 생성 가능
• Multi-AZ

RDS 구조

Amazon RDS는 EC2 + EBS (Storage)로 구성되어 데이터베이스를 형태로 제공되는 PaaS 서비스이다. EC2의 컴퓨팅으로 운영체제와 데이터베이스를 실행하고, 데이터 저장을 위한 스토리지로 EBS를 사용한다. 때문에 우리는 연결된 스토리지의 용량을 원하는 대로 늘릴 수 있고, Auto scaling을 활성화하여 자동으로 확장하도록 구성할 수 있다.

Read Replicas

일반적으로 데이터베이스는 쓰기 작업보다 읽기 작업이 훨씬 많다. 거기다 애플리케이션 동작 외에도 데이터 분석 등을 위해 DB 읽기 작업이 추가될 수 있다. 많은 읽기 작업으로 부하가 커질 수 있는데, RDS는 읽기 복제본(Read replicas)을 제공하여 작업 부하를 줄일 수 있다.

• 데이터가 비동기식으로 복제

• 다른 가용 영역(AZ), 다른 리전(Region)에도 생성 가능

• Read replicas를 DB로 전환 가능

• 최대 5개 생성 가능

Read replica가 다른 AZ에 있어도 데이터 전송에 따른 네트워크 비용이 발생하지 않는다. 하지만 다른 리전에 있다면 데이터 전송 비용이 발생한다.

Multi-AZ

Multi-AZ는 데이터가 동기식으로 복제되며, 주로 재해복구를 위한 대비책으로 사용한다. 단일 DB 인스턴스도 언제든 무중단으로 Multi-AZ 전환이 가능하다.

RDS 생성하기

배포 옵션

단일 DB 인스턴스로 구성하고 Read replica를 직접 추가해 보자.

자격증명 설정

사양 설정

• 인스턴스 (EC2)

• 스토리지 (EBS)

원하는 사양과 스토리지 Auto scaling을 사용 여부를 선택하면 된다.

네트워크 구성

RDS를 생성하려면 VPC와 DB 서브넷 그룹을 선택해야 한다.

VPC, 서브넷에 대해 잘 모르겠다면 AWS 네트워크 (VPC, Subnet, ...)를 참고하자

RDS를 생성하려면 DB 서브넷 그룹은 최소 2개 이상의 AZ를 포함해야 한다. (언제든지 Multi-AZ로 전환할 수 있도록 구성하기 위한 조건으로 보인다.)

DB 인스턴스가 생성될 AZ도 선택해준다.

보안 그룹

보안 그룹을 새로 생성하고 이후에 필요한 허용 규칙을 추가해 주자.

데이터베이스 인증

RDS는 암호만을 사용한 인증뿐만 아니라 IAM 인증을 함께 사용할 수 있다.

백업 & 암호화

확인

DB 생성이 완료되면 엔드 포인트가 나타난다. 이 주소를 통해 RDS DB에 접속할 수 있다.

보안 그룹 (Security group)

보안 그룹은 AWS 리소스 (EC2 인스턴스) 단위로 적용할 수 있는 방화벽이다. 인바운드/아웃바운드로 구분하여 방화벽 규칙을 지정할 수 있다. 보안 그룹에는 허용(Allow) 규칙만 존재한다. 기본적으로 모든 트래픽을 차단하고 있고, 허용된 트래픽만 이동할 수 있다.

https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/security-groups.html

인바운드 규칙 (Inbound rule)

인바운드 규칙은 기본적으로 아무것도 등록되어 있지 않다. 따라서 EC2 인스턴스에 SSH로 접속하려면 TCP 22번 포트를 열어 줘야 한다. 소스는 0.0.0.0/0과 같이 모든 주소 (또는 특정 CIDR IP 범위)로 허용할 수도 있고 다른 보안 그룹을 지정할 수도 있다.

아웃바운드 규칙 (Outbound rule)

아웃바운드 규칙 역시 같은 방식으로 규칙을 추가하여 나가는 트래픽을 허용할 수 있다. 아웃바운드 규칙에는 기본적으로 모든 트래픽을 모든 대상으로 허용하는 규칙이 추가되어 있다.

Stateful

보안 그룹은 Stateful이라는 특성을 가진다. 트래픽이 오고 가는 상태를 기억하고 처리해 준다는 것이다. 예를 들어 인바운드 규칙으로 아무것도 등록되어 있지 않다면 어떤 트래픽도 리소스로 접근할 수 없다. 하지만 만약 아웃바운드 규칙으로 허용되어 나간 트래픽(Request)에 대한 응답(Response)은 들어올 수 있도록 허용된다.

NACL (Network ...)

NACL은 서브넷 단위로 적용할 수 있는 방화벽이다. NACL에는 허용 규칙과 거부 규칙이 모두 존재한다. 그리고 보안 그룹과 달리 Stateless하다. 즉 NACL 인바운드에서 허용되어 들어왔다 하더라도, 아웃바운드 규칙에서 거부되어 통신이 안될 수 있다.

NACL 규칙

• NACL 규칙에는 Allow/Deny가 모두 존재한다.
• 각 규칙의 번호(1 ~ 32766)가 낮을수록 우선순위가 높다.
• 모든 NACL은 *번으로 모든 트래픽을 거부하는 규칙이 있다.
• Default NACL에는 Inbound/Outbound의 100번 규칙으로 모든 트래픽을 허용하는 규칙이 있다.

*번은 마지막 규칙으로 우선순위가 가장 낮다.

NACL 주의사항: Stateless

• 임시 포트 (Ephemeral port)

일반적으로 서버의 포트는 고정되어 있지만 클라이언트는 임시 포트 범위 중에서 랜덤으로 사용한다. 따라서 Stateless한 NACL에서는 임시 포트를 신경 써서 관리해야 한다. 예를 들어 서버 서브넷에는 아웃바운드로 클라이언트의 임시 포트 범위를 열어 주어야 한다.

보안 그룹 vs NACL

보안 그룹과 NACL 모두 논리적인 개념으로 하나를 가지고 여러 리소스에 연결하여 적용할 수 있다.

VPC

먼저 가장 큰 단위인 Amazon VPC(Virtual Private Cloud)에 대해서 알아보자. VPC는 특정 리전 내에서 AWS 자원을 배치할 수 있는 가상의 네트워크이다. 내부 통신을 위해 사설 IP (Private IP) 대역을 사용하며, Subnet mask를 활용하는 CIDR 형태의 주소를 사용한다.

CIDR (Classless Inter-Domain Routing) CIDR은 IP를 사용할 때 클래스로 네트워크 주소를 구분하지 않고 Subnet mask를 사용한다. 클래스 기반 방식보다 더 유연하게 네트워크 크기를 조절할 수 있다. https://aws.amazon.com/ko/what-is/cidr/

Private IP 외부 통신과 별개로, 특정 네트워크 내에서만 통신하기 위한 IP 주소. 따라서 분리된 네트워크에서는 Private IP가 중복되어도 문제없다. 아래 대역을 Private IP로 사용할 수 있다. https://en.wikipedia.org/wiki/Private_network

• 10.0.0.0/8 10.0.0.0 – 10.255.255.255
• 172.16.0.0/12 172.16.0.0 – 172.31.255.255
• 192.168.0.0/16 192.168.0.0 – 192.168.255.255

한 리전에 여러 개의 VPC를 만들 수 있다. (최대 5개지만 추가 신청할 수 있음) VPC의 CIDR은 내부에서 통신하기 위한 가상 주소이기 때문에 중복되어도 상관없다. 하지만 VPC 간에 연결할 계획이 있다면 다르게 설정해야 한다.

서브넷 (Subnet)

AWS는 VPC 내에서 IP 주소 범위로 분리하여 관리할 수 있도록 서브넷(Subnet)을 제공한다. 하나의 서브넷은 특정 가용 영역 내에서 관리된다.

AWS 리전(Region)과 가용 영역 (Availability Zone) 에서 다룬 것처럼 고가용성을 위해 동일 목적의 서브넷을 하나 이상의 AZ에 생성해 두는 것이 좋다.

예약된 IP

각 서브넷에서 5개 (처음 4개, 마지막 1개)의 IP는 자동으로 예약된다. ex) 10.0.0.0 / 24

• 네트워크 주소 (10.0.0.0)
• VPC 라우터 (10.0.0.1)
• Amazon-provided DNS (10.0.0.2)
• 미래를 위해 예약된 주소 (10.0.0.3)
• Broadcast (10.0.0.255)

네트워크 리소스

VPC 내부에 우리가 사용하는 EC2, RDS(DB) 등의 리소스를 생성했다고 하자. 그러면 VPC 내부의 리소스들은 서로 통신할 수 있지만 외부와는 통신할 수 없을 것이다. VPC 내의 리소스들이 외부와 통신하기 위해 필요한 자원들을 알아보자.

• 인터넷 게이트웨이 (Internet gateway)
• NAT 게이트웨이 (NAT gateway)
• 라우팅 테이블 (Routing table)

인터넷 게이트웨이 (Internet Gateway)

VPC 내부의 리소스와 외부 인터넷 간에 통신할 수 있게 해준다. Public 서브넷에서 외부로 접근할 수도 있고, 리소스에 Public IP가 있다면 외부에서 해당 리소스에 접근할 수도 있다.

https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/VPC_Internet_Gateway.html

NAT 게이트웨이 (NAT Gateway)

Private 서브넷의 리소스는 외부에서 접근할 수 없도록 막아야 하지만, 내부에서 외부 인터넷으로의 접근은 필요할 수 있다. 이때 NAT 게이트웨이를 사용할 수 있다.

https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/vpc-nat-gateway.html

라우팅 테이블 (Route Table)

인터넷 게이트웨이, NAT 게이트웨이를 생성했다고 해서 내부 리소스에서 외부 인터넷과 통신할 수 있는 것은 아니다. 라우팅 테이블 설정에서 게이트웨이를 사용하도록 설정해 주어야 한다.

위 라우팅 테이블을 보면 10.1.0.0/16 에 포함되는 주소는 패킷을 local로 보내고 나머지(0.0.0.0/0)는 인터넷 게이트웨이로 보내도록 설정되었다.

라우팅 테이블의 우선순위 (Logest Match Rule) 대상 주소를 포함하는 규칙 중 네트워크 주소가 가장 긴 규칙에 해당하는 대상으로 보낸다. ex) 10.1.0.100 이라는 주소는 10.1.0.0/16, 0.0.0.0/0 모두 포함되지만 네트워크 주소가 더 긴 10.1.0.0/16의 우선순위가 더 높다.

실습: VPC 구성하기

VPC > VPC 생성으로 진입해서 VPC 등 옵션을 위에서 다룬 리소스들까지 한 번에 생성할 수 있다. VPC CIDR만 지정해 주면 서브넷의 IP는 자동으로 할당해 주고, AZ(가용 영역)의 수도 선택할 수 있다.

그림처럼 리소스 맵도 확인할 수 있다. 그림을 보면 각 서브넷에 라우팅 테이블이 연결되고 해당 라우팅 테이블에서 연결된 자원도 확인할 수 있다.

Next

지금까지 AWS의 네트워크 대해서 공부하고 직접 구성해 보았다. 하지만 아직 아주 중요한 부분 보안이 남아있다. 다음에는 방화벽 역할을 하는 보안 그룹 (Security group)과 NACL(Network access control list)에 대해서 알아보자.

IAM 서비스에 접속하면 리전이 Global인 것을 확인할 수 있다. IAM은 리전 별로 구분하지 않고 글로벌로 통합하여 관리하는 서비스이다.

IAM Resources

• 사용자 (User)
• 그룹 (Group)
• 정책 (Policy)
• 역할 (Role)

IAM을 이용해 적절한 접근 제어를 적용하려면 위 개념들을 잘 이해하고 넘어가야 한다.

사용자(User)

AWS에서는 일반적으로 하나의 계정(Account)를 여러 사람이 공유하여 사용하게 된다. 같이 작업할 사람이 추가되었다면 이 사용자(User)를 새로 생성하여 신규 작업자에게 제공할 수 있다.

사용자 권한

사용자(User)에게 권한을 주는 방법은 다음과 같다.

• 권한 정책(Policy) 연결
• 그룹(Group)에 포함
• 역할(Role) 부여

사용자 생성

별로 실감 나지 않으니 직접 생성하고 사용해 보자.
사용자 > 사용자 추가

Step 1) 사용자 세부 정보 지정

Step 2) 권한 설정

권한을 줄 수 있는 여러 가지 방법을 확인할 수 있다. 직접 정책 연결을 선택하면 AWS에서 미리 만들어놓은 여러 권한 정책을 확인할 수 있다. 지금은 특별히 권한을 주지 않고 생성해 보자.

Step 3) 검토 및 생성

앞에서 설정한 내용들을 확인해 볼 수 있다. 생성된 User 계정에 자동으로 암호를 부여해 주고, 로그인 시 재설정하도록 설정된 것을 볼 수 있다. 특별히 권한을 추가하지 않았지만 사용자가 비밀번호를 변경하여 사용할 수 있도록 IAMUserChangePassword 권한이 있는 것도 확인할 수 있다.

Step 4) 암호 검색

사용자(User) 생성을 완료하면 생성된 사용자의 로그인 정보를 확인할 수 있다. 위 정보를 csv 파일로 다운로드 받아서 사용자 계정을 전달해 주면 된다.

사용자 로그인

앞에서 본 콘솔 로그인 URL로 접속하면 "IAM 사용자로 로그인" 페이지로 이동하고, 자동으로 계정 ID가 입력된다. 계정 ID (또는 계정 Alias)를 외우고 있다면 AWS 로그인 페이지로 와서 직접 입력해도 된다. 그리고 전달받은 사용자 이름과 암호를 입력하면 사용자(User)로 로그인할 수 있다.

매번 링크로 접속하기는 귀찮고, 계정 ID (12자리)를 외우기도 힘들다면, 루트 사용자가 계정 ID 대신 외우기 쉬운 계정 별칭(Alias)를 만들어 줄 수 있다.

사용자를 생성해야 하는 이유

• 사용자에 따라서 권한을 다르게 부여할 수 있다.
• AWS 계정에서 어떤 사용자가 어떤 작업을 했는지 확인할 수 있다. (CloudTrail)

그룹(Group)

그룹(Group)을 이용하면 여러 사용자를 포함시키고 권한 정책(Policy)를 연결하여, 여러 사용자에게 동일한 권한을 제공할 수 있다.

한 사용자는 여러 그룹에도 들어갈 수 있다.

정책(Policy)

실제 서비스나 리소스에 대한 권한이 명시되어 있는 리소스이다. 사용자, 그룹, 역할 등에 연결하여 권한을 부여한다.

정책 유형

• 자격 증명 기반 정책 (Identity-based policies)
• 리소스 기반 정책 (Resource-based policies)
• IAM 권한 경계 (Permissions boundaries)
• 서비스 제어 정책 (Organizations SCPs)
• 액세스 제어 목록 (Access control lists (ACLs))
• 세션 정책 (Session policies)

위와 같이 다양한 유형의 정책이 있지만, 여기서는 자격 증명 기반 정책에 대해서만 다룰 것이다. 자격 증명 기반 정책은 자격 증명(사용자, 그룹, 역할 등)이 무슨 작업(Action)을 어느 리소스(Resource)에서 어떤 조건(Condition)에서 수행할 수 있는지를 정의하여 제어할 수 있다.

https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/access_policies.html#policies_id-based

사용자에 정책 연결

앞에서 만들었던 John이라는 사용자로 로그인하여 EC2 서비스에 접속해 보자.

현재는 아무 권한도 없기 때문에 EC2와 관련된 어떤 것도 조회할 수 없다.

그럼 다시 관리자로 로그인하여 John에게 권한을 추가해 주자. IAM > 사용자 > John > 권한 추가

AmazonEC2FullAccess 권한을 추가하자.

사용자 John의 권한에 AmazonEC2FullAccess가 추가된 것을 볼 수 있다. [+]를 누르면 세부적으로 어떻게 권한이 적용되었는지 Json으로 확인할 수 있다. 이제 다시 John으로 로그인하면 EC2 서비스를 정상적으로 이용할 수 있다.

정책 Json 구조

ex) IAMReadOnlyAccess

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "iam:GenerateCredentialReport",
                "iam:GenerateServiceLastAccessedDetails",
                "iam:Get*",
                "iam:List*",
                "iam:SimulateCustomPolicy",
                "iam:SimulatePrincipalPolicy"
            ],
            "Resource": "*"
        }
    ]
}

Statement 내에 값을 중점적으로 알아보자.

• Effect Allow / Deny 지정
• Action 어떤 작업인지 지정
• Resource 특정 리소스를 지정
• Condition 정책이 적용될 조건을 지정 ex) "NotIpAddress": { "aws:SourceIp": ["192.168.1.0", "192.168.1.1"] }

https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/reference_policies_elements.html

EC2 Keyword

• AMI
• Instance type
• Key pair
• Network
  • VPC
  • Subnet
  • Security group
• Storage
  • EBS
• More
  • 구매 옵션
  • User data

위 키워드에 대해서 미리 알아 둔다면 EC2를 생성하고 사용하는 데 어려움이 없을 것이다. 나중에 하나씩 알아보면 되니 당장 모두 이해할 필요는 없다.

EC2 생성하기

이전 포스팅 AWS 리전(Region)과 가용 영역 (Availability Zone)에서 Region에 대해서 배웠다.

EC2를 생성할 리전을 선택하고 EC2 > Instances에 접속하면 Launch instance를 통해 EC를 생성할 수 있다. 직접 EC2를 생성해 보면서 키워드를 하나씩 알아보자.

AMI (Amazon Machine Image)

AMI는 Vmware에서 iso를 불러오는 것처럼 OS의 이미지라고 볼 수 있다. Amazon Linux에서 프리티어 사용 가능한 것으로 선택하자.

AWS 프리티어는 1년 동안 일부 AWS 서비스를 매월 특정 사용량까지 무료로 사용해 볼 수 있는 기능으로, 신규 AWS 계정에서 자동으로 활성화된다. https://repost.aws/ko/knowledge-center/what-is-free-tier

Instance type

Instance type은 CPU, Memory 성능을 결정한다. 타입을 선택하면 CPU 개수, Memory 용량, 비용을 확인할 수 있다. 마찬가지로 프리티어 사용 가능한 t2.micro를 선택하자

Key pair

Key pair는 보안을 위해 생성한 EC2에 SSH로 접속할 때 제공할 Key 파일을 설정하는 것이다. 처음 접속하면 Key pair가 없을 테니 생성하자.

Key pair를 생성하면 EC2에 접속할 때 필요한 Private key 파일이 선택한 타입(.pem)으로 다운로드 된다. 이 파일은 키 페어 생성 시 한 번만 다운로드할 수 있으므로 잃어버리지 말고 잘 보관하고 있자.

Network

다음으로는 EC2가 생성될 VPC (Virtual Private Network), Subnet 등의 네트워크를 구성하고, EC2의 방화벽 역할을 하는 보안 그룹(Security group)을 설정해야 한다. 자세한 내용은 이후에 Network를 정리하면서 다룰 것이다. Public IP를 할당하는지 확인하고 넘어가자.

Storage

EC2를 생성하면 기본적으로 EBS Root 볼륨이 생성된다. EBS (Elastic Block Store)는 EC2에 연결하여 사용할 수 있는 Network Drive이다. Root 볼륨 외에도 EBS 볼륨을 추가할 수 있다. EBS에 대해서는 나중에 Storage를 공부할 때 자세히 알아보자.

EC2 확인

EC2를 생성하면 실행하고, 상태를 확인하는 데 몇 분 정도의 시간이 좀 걸릴 수 있다. EC2를 선택하면 그림과 같이 Public/Private IP, VPC, Status 등 EC2 인스턴스에 대한 여러 가지 정보를 확인할 수 있다.

EC2 접속하기

EC2를 선택하고 연결(Connect) 하면 EC2에 접속하는 방법들을 확인할 수 있다. 4가지 옵션이 있지만 가장 기본적인 SSH client를 사용해 보자.

Example 명령어를 복사해서 아까 다운로드 받은 .pem key가 있는 곳에서 실행하면 EC2 인스턴스에 접속할 수 있다.

EC2 삭제

실습을 해봤다면 이제 추가적인 요금이 발생하지 않도록 EC2 인스턴스를 삭제하자. 한국어로는 중지(Stop), 종료(Terminate)로 표기되어 있는데 종료(Terminate)가 EC2 인스턴스 삭제를 의미한다. 헷갈려서 실수로 삭제하는 일이 없도록 하자.

AWS는 전 세계적으로 클라우드 서비스를 제공하기 위해 리전(지역)으로 구분하여 서비스를 제공한다.
https://aws.amazon.com/about-aws/global-infrastructure/에 접속하면 전 세계에서 AWS가 어떤 리전에서 지원하고 있는지 한눈에 볼 수 있다.

리전 (Region)

AWS에서 리전은 물리적인 데이터 센터 그룹을 클러스터링 하는 지역을 말한다. 리전을 선택하는 데 다양한 원인이 있을 수 있지만, 대표적으로 지연 시간과 법률 준수(Compliance) 등이 있다.

리전 선택하기 - 지연 시간

우리가 EC2(가상의 컴퓨터) 서비스를 사용해 우리나라를 대상으로 한 웹 서비스를 배포한다고 하자. 그러면 일반적으로 사용자와 물리적으로 가까운 서울 리전에서 배포하는 것이 좋을 것이다. 우리나라 사람들이 사용하는데 서버가 미국에 있다고 하면 물리적인 거리로 인해 큰 지연 시간을 겪을 수 있다.

리전 선택하기 - Compliance

우리가 정부 관련 또는 다른 나라에 서비스를 제공하려고 할 때, 데이터 센터를 반드시 국내에 두어야 한다 등의 법이 있을 수 있기 때문에 서비스를 위한 리전을 선택할 때 법적인 부분도 파악해야 한다.

리전 별 서비스

각 리전 별로 지원되는 서비스가 다를 수 있다. 각 리전 별로 사용 가능한 서비스는 리전 별 AWS 서비스에서 확인할 수 있다.

리전 확인 (AWS Console)

AWS Console 상단 바에서 리전을 선택할 수 있다.

가용 영역(Availability Zone / AZ)

가용 영역(Availability zone)은 한 리전 내의 데이터 센터 그룹을 의미한다. AZ(줄여서 AZ라는 표현을 많이 사용한다)는 서비스의 가용성을 높이기 위해 설계되었다.

Multi-AZ

내가 운영하는 서비스를 하나의 AZ에만 배포했다면, 해당 AZ에 재해가 생겼을 때 서비스는 멈추게 된다.

하지만 서비스를 그림과 같이 Multi-AZ로 배포한다면 재해로 인해 특정 AZ에 배포한 서비스가 마비되었다 하더라도 다른 AZ의 서비스를 계속 이용할 수 있다.

공부 방법

• Udemy 강의 - 【한글자막】 AWS Certified Solutions Architect Associate 시험합격!
• Exam Topics Dump 문제 풀이
• 오답 노트

강의

공부는 주로 Udemy에 【한글자막】 AWS Certified Solutions Architect Associate 시험합격! 이라는 강의를 들었고, 유료이긴 하지만 강의가 정말 잘 구성되어 있다. 시험 범위가 넓은 만큼 총 강의 시간은 27시간이다.. 그래도 강의 하나에 평균 5분 정도로 짧게 끊어놔서 편하게 들을 수 있었다. 처음에는 시간 날 때마다 내가 궁금했던 내용을 위주로 들었는데 강의 수가 너무 많다 보니 진도율이 너무 느리게 올랐다.

평소에는 정말 조금씩 실습 하나하나 해가면서 한 달 정도 공부했고, 일주일쯤 남았을 때는 강의를 내용을 위주로 빠르게 들었다. 강의는 총 400개 중 평소에 천천히 100개, 일주일 정도 동안 빠르게 100개 정도 해서 반 정도 들었다. 이미 알고 있는 내용이나 특정 서비스에 너무 심화적인 내용의 강의를 제외하고 들었다. (제외했다기보다는 미루다가 못 들었다.) 하나하나 들을 때마다 확실히 도움 되는 내용인 것 같아서 시간이 충분하다면 다 들었을 것 같다. 들을 거다. 아마도.

Dump 문제 풀이

강의를 듣다가 오! 나 이제 문제 잘 풀 수 있을 것 같아! 하는 순간 Exam Topics 문제를 봤는데, 범위가 넓다 보니 방금 공부한 내용이 좀처럼 안 나와서 재미는 못 봤다. 그래도 강의 들을 때 문제에서 봤던 내용이 나오면 집중력이 좋아지는 것 같다. 문제를 먼저 보고 나서 관련된 부분의 강의를 찾아보는 것도 괜찮다.

평소에 시간 날 때 한두 문제씩 100번 정도까지 풀었다. 시험 3일 전에는 Exam topics 한 번에 1번 ~ 100번을 다시 풀고, 이틀 전에 시험 치듯이 101 ~ 150까지 풀어봤다. 방금 찾아보니 Exam topics에서 270번까지는 무료로 볼 수 있는 것 같다.

오답 노트

시간 날 때 틈틈이 푸는 것도 문제 유형을 파악하는 데는 괜찮았는데, 시험 치듯이 문제를 쭉 풀고 오답 노트를 만드는 게 훨씬 좋았다. Google sheet로 작성했고 틀린 문제에서 풀이를 이해하고 나면 옆에 Keyword와 Solution을 매칭 시켰다.

결과

시험은 아침에 봤는데 의외로 다음 날에 바로 결과가 나왔다. 메일로 합격 축하를 보내주고 Badge도 준다. 이런 건 참 잘 만들었다. 기분 좋다.

시험 사이트에 들어가면 [취득한 자격증]에서 인증서를 받을 수 있고 [시험 내역]에서 PDF로 점수도 확인할 수 있다.