Cloud & IT Cert Prep · 강의

전역 보조 인덱스 및 로컬 보조 인덱스

테이블을 복제하지 않고도 대체 쿼리 패턴을 지원하도록 GSI와 LSI를 추가합니다.

전역 보조 인덱스 및 로컬 보조 인덱스은(는) CoddyKit의 무료 Cloud & IT Cert Prep 강의입니다. 이것은 4개 중 3번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Cloud & IT Cert Prep 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Cloud & IT Cert Prep 강의에는 총 4개의 강의가 포함되어 있습니다.

보조 인덱스가 필요한 이유

DynamoDB의 기본 키는 테이블에서 효율적으로 쿼리할 수 있는 유일한 경로를 정의합니다. 다른 속성을 기준으로 항목을 조회해야 하는 경우, 예를 들어 테이블의 파티션 키가 CustomerId일 때 제품 ID별 모든 주문을 찾으려면 보조 인덱스 없이 비용이 많이 드는 Scan을 수행해야 합니다.

보조 인덱스는 다른 키를 중심으로 구성된 별도의 데이터 사본을 유지하고 자동으로 업데이트하여 이 문제를 해결합니다. DynamoDB는 Global Secondary Index(GSI)와 Local Secondary Index(LSI)라는 두 가지 유형을 제공하며, 각각 서로 다른 장단점이 있습니다.

Global Secondary Index(GSI) 기본

Global Secondary Index를 사용하면 기본 테이블과 완전히 다른 파티션 키와 선택적인 정렬 키를 정의할 수 있습니다. GSI는 기본 테이블의 모든 파티션에 걸쳐 있는 진정한 전역 인덱스입니다. GSI의 파티션 키로 정의한 모든 속성을 기준으로 항목을 찾도록 GSI를 쿼리할 수 있습니다.

GSI는 기본 테이블과 독립적인 자체 프로비저닝 처리량을 가지며(또는 온디맨드 모드를 상속하며), 테이블당 최대 GSI 20개를 생성할 수 있습니다. 기존 테이블에서도 언제든지 GSI를 추가하거나 삭제할 수 있습니다.

# Create a table with a GSI on ProductId
aws dynamodb create-table \
  --table-name Orders \
  --attribute-definitions \
    AttributeName=OrderId,AttributeType=S \
    AttributeName=ProductId,AttributeType=S \
    AttributeName=OrderDate,AttributeType=S \
  --key-schema AttributeName=OrderId,KeyType=HASH \
  --global-secondary-indexes '[
    {
      "IndexName": "ProductId-OrderDate-index",
      "KeySchema": [
        {"AttributeName": "ProductId", "KeyType": "HASH"},
        {"AttributeName": "OrderDate", "KeyType": "RANGE"}
      ],
      "Projection": {"ProjectionType": "ALL"},
      "ProvisionedThroughput": {"ReadCapacityUnits": 10, "WriteCapacityUnits": 5}
    }
  ]' \
  --provisioned-throughput ReadCapacityUnits=10,WriteCapacityUnits=5

Local Secondary Index(LSI) 기본

Local Secondary Index는 기본 테이블과 동일한 파티션 키를 공유하지만 다른 정렬 키를 사용합니다. LSI가 '로컬'인 이유는 하나의 파티션, 즉 동일한 파티션 키를 가진 항목 내에서만 쿼리하기 때문입니다. 따라서 LSI는 특정 고객의 주문을 다른 속성으로 정렬하여 조회하는 데 적합합니다.

LSI는 테이블 생성 시점에 정의해야 하며 나중에 추가하거나 삭제할 수 없습니다. 각 테이블에는 최대 LSI 5개를 생성할 수 있습니다. LSI는 기본 테이블의 프로비저닝 용량을 공유하므로 별도의 처리량이 필요하지 않으며, 기본 테이블과 LSI 데이터의 합계에 대해 파티션 키당 10GB의 저장 용량 제한이 적용됩니다.

# Create a table with an LSI (at creation time only)
aws dynamodb create-table \
  --table-name Orders \
  --attribute-definitions \
    AttributeName=CustomerId,AttributeType=S \
    AttributeName=OrderDate,AttributeType=S \
    AttributeName=TotalAmount,AttributeType=N \
  --key-schema \
    AttributeName=CustomerId,KeyType=HASH \
    AttributeName=OrderDate,KeyType=RANGE \
  --local-secondary-indexes '[{
    "IndexName": "TotalAmount-index",
    "KeySchema": [
      {"AttributeName": "CustomerId", "KeyType": "HASH"},
      {"AttributeName": "TotalAmount", "KeyType": "RANGE"}
    ],
    "Projection": {"ProjectionType": "ALL"}
  }]' \
  --billing-mode PAY_PER_REQUEST

GSI와 LSI: 주요 차이점

시험 대비를 위해 다음과 같이 나란히 비교해 보겠습니다.

파티션 키: GSI는 기본 테이블과 다를 수 있지만, LSI는 기본 테이블과 같아야 합니다
정렬 키: 둘 다 기본 테이블과 다른 정렬 키를 지원합니다
생성 시점: GSI는 언제든 생성할 수 있지만, LSI는 테이블 생성 시에만 만들 수 있습니다
처리량: GSI는 자체 처리량을 가지지만, LSI는 기본 테이블의 처리량을 공유합니다
일관성: GSI 읽기는 최종적 일관성만 지원하지만, LSI 읽기는 강력한 일관성을 지원할 수 있습니다
제한: GSI는 최대 20개, LSI는 테이블당 최대 5개입니다

프로젝션 유형

인덱스를 생성할 때 인덱스에 프로젝션(복사)할 속성을 선택합니다.

키만: 기본 테이블의 기본 키와 인덱스 키만 포함합니다. 인덱스 크기가 가장 작지만, 키가 아닌 속성을 가져오려면 추가로 GetItem을 호출해야 합니다
INCLUDE: 키 속성과 지정한 추가 속성 목록을 포함합니다. 인덱스 크기와 액세스 패턴 사이의 균형을 맞출 수 있습니다
ALL: 모든 속성을 인덱스에 프로젝션합니다. 가장 유연하지만 스토리지 비용과 쓰기 비용이 더 높습니다

쿼리에서 실제로 필요한 속성을 기준으로 프로젝션 유형을 선택하십시오. 필요 이상으로 프로젝션하면 모든 쓰기 작업에서 WCU가 낭비되고, 필요한 속성을 충분히 프로젝션하지 않으면 인덱스에 없는 속성을 가져오기 위해 추가 GetItem 호출이 필요합니다.

GSI 쿼리

GSI 쿼리는 동일한 Query API를 사용하지만 --index-name 매개변수를 지정합니다. 쿼리는 기본 테이블이 아니라 GSI의 키 스키마를 대상으로 실행됩니다. GSI 쿼리는 항상 최종적 일관성을 사용합니다. 기본 테이블에 쓰기가 수행된 후 GSI가 비동기적으로 업데이트되므로 잠시 지연이 발생합니다.

기본 테이블의 항목에 GSI의 파티션 키 속성이 없으면 해당 항목은 GSI에 전혀 포함되지 않습니다(희소 인덱스 패턴). 이는 항목의 일부만 인덱싱하는 강력한 기법입니다. 예를 들어 GSI 파티션 키가 Status라면 상태가 PENDING인 모든 주문만 인덱싱할 수 있습니다.

# Query the GSI for all orders for a product in 2026
aws dynamodb query \
  --table-name Orders \
  --index-name ProductId-OrderDate-index \
  --key-condition-expression 'ProductId = :pid AND OrderDate BETWEEN :start AND :end' \
  --expression-attribute-values \
    '{":pid":{"S":"prod-abc"},":start":{"S":"2026-01-01"},":end":{"S":"2026-12-31"}}'

희소 인덱스 패턴

희소 인덱스는 DynamoDB가 GSI의 파티션 키 값을 가진 항목만 GSI에 프로젝션한다는 특성을 활용합니다. 일부 항목에만 존재하는 속성을 GSI 파티션 키로 정의하면 해당 부분 집합만 포함하는 인덱스를 만들 수 있습니다.

예를 들어 Orders 테이블에서 배송되지 않은 주문에만 PendingShipmentDate 속성이 있다고 하겠습니다. PendingShipmentDate를 기준으로 GSI를 만들면 배송되지 않은 주문만 자연스럽게 포함됩니다. 따라서 전체 테이블을 스캔하지 않고도 보류 중인 모든 주문을 매우 효율적으로 조회할 수 있습니다.

GSI 오버로딩을 사용한 쓰기 샤딩

GSI 오버로딩은 한 테이블에 서로 다른 엔터티 유형을 저장하고, 일반적인 GSI 키 속성(예: GSI1PK 및 GSI1SK)에 항목 유형에 따라 서로 다른 패턴의 값을 채우는 고급 단일 테이블 설계 기법입니다. 이를 통해 각 엔터티 유형이 하나의 GSI를 통해 효율적인 자체 쿼리 경로를 갖게 됩니다.

예를 들어 User 항목에는 GSI1PK = 'COUNTRY#US' 및 GSI1SK = username을 설정하고, Order 항목에는 GSI1PK = 'STATUS#PENDING' 및 GSI1SK = orderDate를 설정합니다. 적절한 접두사를 사용해 GSI를 쿼리하면 대상 엔터티 유형을 효율적으로 가져올 수 있습니다.

인덱스 제한과 용량

GSI 제한은 기본 테이블과 독립적으로 발생합니다. GSI에 프로비저닝된 WCU가 너무 적으면 GSI에 프로젝션되는 항목에 대한 쓰기가 제한됩니다. 기본 테이블에 충분한 용량이 있더라도 마찬가지입니다. 각 GSI의 ConsumedWriteCapacityUnits 및 ThrottledRequests를 별도로 모니터링하십시오.

흔한 문제는 GSI의 용량을 기본 테이블보다 낮게 설정한 뒤, 쓰기 패턴이 갑자기 증가하면서 GSI 쓰기 속도가 높아져 제한이 발생하는 것입니다. 이를 방지하려면 GSI에 Auto Scaling을 사용하거나 온디맨드 모드를 선택하십시오.

GSI, LSI 또는 재설계를 선택하는 기준

SAA-C03 시험을 위한 선택 지침은 다음과 같습니다.

완전히 다른 속성으로 쿼리해야 함 → GSI
같은 파티션 안에서 다른 순서로 정렬해 쿼리해야 하고, 생성 시점에 이를 알고 있음 → LSI
대체 정렬 키에 대해 강력한 일관성의 읽기가 필요함 → LSI(GSI는 최종적 일관성만 지원하므로 유일한 선택지입니다)
서로 다른 쿼리 패턴이 10개 이상임 → 별도의 테이블을 많이 만드는 대신 GSI 오버로딩을 사용한 단일 테이블 설계를 고려하십시오
분석을 위해 모든 항목을 가져오기만 하면 됨 → DynamoDB가 적합한 데이터베이스인지 다시 검토하십시오

GSI 삭제와 백필

기본 테이블에 영향을 주지 않고 언제든 GSI를 삭제할 수 있습니다. 기존 테이블에 새 GSI를 추가하면 DynamoDB가 기본 테이블을 스캔하여 인덱스를 비동기적으로 백필합니다. 대규모 테이블에서는 이 작업에 수분에서 수 시간이 걸릴 수 있습니다. 백필 중에도 기본 테이블은 읽기와 쓰기 모두 완전히 사용할 수 있습니다.

콘솔에서 또는 DescribeTable API를 통해 인덱스의 IndexStatus 필드를 확인하여 백필 진행 상황을 모니터링할 수 있습니다. 백필 중에는 CREATING, 완료되면 ACTIVE가 됩니다. ACTIVE 상태가 될 때까지 GSI를 쿼리하지 마십시오.

# Check GSI status during backfill
aws dynamodb describe-table \
  --table-name Orders \
  --query 'Table.GlobalSecondaryIndexes[*].{Name:IndexName,Status:IndexStatus}'

빠른 확인

이 단원에서 다룬 AWS Solutions Architect(SAA-C03) 개념을 얼마나 이해했는지 확인해 보십시오.

단원 요약

이 단원에서는 GSI가 대체 파티션 키를 제공하며 언제든 추가할 수 있다는 점, LSI는 기본 파티션 키를 공유하며 생성 시 정의해야 한다는 점, 그리고 프로젝션 유형이 인덱스에 복사되는 속성을 제어한다는 점을 배웠습니다. 또한 고급 쿼리 유연성을 제공하는 희소 인덱스 및 오버로딩 패턴도 살펴보았습니다. 다음 단원에서는 DynamoDB 스트림과 글로벌 테이블을 알아보겠습니다.

자주 묻는 질문

“전역 보조 인덱스 및 로컬 보조 인덱스” 강의는 무료인가요?

네 — “전역 보조 인덱스 및 로컬 보조 인덱스” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Cloud & IT Cert Prep 강의 전체를 잠금 해제할 수 있습니다. Cloud & IT Cert Prep 강의에는 총 4개의 강의가 포함되어 있습니다.

“전역 보조 인덱스 및 로컬 보조 인덱스”에서 뭘 배우나요?

테이블을 복제하지 않고도 대체 쿼리 패턴을 지원하도록 GSI와 LSI를 추가합니다. 브라우저에서 직접 실행하는 실습 코드로 Cloud & IT Cert Prep을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Cloud & IT Cert Prep을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Cloud & IT Cert Prep은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 3번째 강의입니다.

“전역 보조 인덱스 및 로컬 보조 인덱스” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 Cloud & IT Cert Prep 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 Cloud & IT Cert Prep 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

← Cloud & IT Cert Prep(으)로 돌아가기