AWS Certified Developer - Associate (DVA-C02) #6 Domain 1-5 AWS 서비스로 개발: SDK 개발 패턴

#2부터 #5까지 개별 서비스를 봤다면, 이번 글은 그 서비스들을 코드로 호출할 때 공통으로 반복되는 패턴입니다. 시험은 특정 서비스가 아니라 “API를 호출하는 올바른 방식"을 묻는 문항을 꾸준히 냅니다. 페이지네이션, 재시도, 멱등성, S3 업로드, 자격 증명 공급이 그 핵심입니다.

페이지네이션 #

AWS API는 한 번에 반환하는 결과 수에 한도가 있습니다. ListObjectsV2, Query, Scan, DescribeInstances 등은 결과가 많으면 잘라서 돌려주고, 다음 페이지를 가리키는 토큰을 함께 줍니다.

• 응답에 NextToken(또는 LastEvaluatedKey, IsTruncated + ContinuationToken)이 있으면 결과가 더 있다는 뜻입니다.
• 그 토큰을 다음 요청에 넣어 반복 호출합니다.
• 대부분의 SDK는 **페이지네이터(paginator)**를 제공해 이 반복을 자동화합니다.

시험 함정: “결과 일부만 돌아온다"는 버그의 원인은 보통 페이지네이션을 처리하지 않은 것입니다. 첫 페이지만 읽고 멈춘 코드입니다.

지수 백오프와 지터 #

스로틀링(ThrottlingException, ProvisionedThroughputExceededException, 429, 503)이나 일시적 오류는 즉시 재시도하면 안 됩니다. 같은 순간에 모두가 재시도하면 부하가 더 커집니다(thundering herd).

• 지수 백오프(Exponential Backoff). 재시도 간격을 1초, 2초, 4초처럼 지수적으로 늘립니다.
• 지터(Jitter). 간격에 무작위성을 더해 재시도 시점을 분산합니다.

좋은 소식은 AWS SDK가 지수 백오프 + 지터 재시도를 기본 내장한다는 점입니다. 재시도 횟수와 모드(legacy/standard/adaptive)를 설정으로 조정할 수 있습니다. “스로틀링에 어떻게 대응하나"의 답은 거의 항상 지수 백오프 재시도이며, 직접 구현이 아니라 SDK 설정으로 처리하는 것이 권장입니다.

멱등성 #

#2,#5에서 본 대로, 비동기,큐 기반 전달은 같은 요청을 여러 번 전달할 수 있습니다(at-least-once). 부수 효과가 있는 작업은 멱등하게 만들어야 합니다.

• 멱등성 키. 클라이언트가 요청마다 고유 키(예: 주문 ID, UUID)를 부여하고, 서버는 그 키로 중복을 식별합니다.
• 조건부 쓰기로 구현. DynamoDB의 attribute_not_exists 조건으로 “처음 본 키일 때만 처리"를 강제합니다.
• 일부 AWS API는 ClientRequestToken 같은 멱등성 토큰 파라미터를 직접 지원합니다.

S3 개발 패턴 #

멀티파트 업로드 #

큰 객체(권장: 100MB 이상, 필수: 5GB 초과)는 멀티파트 업로드로 나눠 올립니다.

• 파트를 병렬 업로드해 속도를 높이고, 실패한 파트만 재전송합니다.
• 불완전한 멀티파트 업로드는 스토리지 비용을 발생시키므로, 수명 주기 규칙으로 미완료 업로드를 정리하는 것이 권장입니다.

presigned URL #

서버가 임시 서명된 URL을 발급해, 클라이언트가 AWS 자격 증명 없이 정해진 시간 동안 S3에 직접 업로드/다운로드하게 합니다.

• 모바일,웹 클라이언트에 IAM 키를 배포하지 않고 S3 접근을 주는 표준 방법입니다.
• URL은 발급한 주체의 권한과 만료 시간을 가집니다.

“브라우저에서 S3로 직접 큰 파일을 올려야 한다. 서버를 거치지 않고.“의 답은 presigned URL입니다.

S3 일관성 #

S3는 현재 신규 객체 PUT과 덮어쓰기,삭제 모두에 강력한 읽기-쓰기 일관성을 제공합니다(이전의 최종 일관성 모델은 더 이상 해당하지 않습니다). 다만 같은 키를 동시에 쓰는 경우 마지막 쓰기가 이깁니다.

SDK 자격 증명 공급 체인 #

SDK는 자격 증명을 정해진 우선순위로 찾습니다. 시험은 “코드에 키를 하드코딩하지 않고 어떻게 자격 증명을 공급하나"를 묻습니다.

1. 코드에 명시적으로 전달한 자격 증명
2. 환경변수(AWS_ACCESS_KEY_ID 등)
3. 공유 자격 증명 파일(~/.aws/credentials)
4. IAM Role(EC2 인스턴스 프로파일, ECS 태스크 역할, Lambda 실행 역할)

프로덕션 권장은 IAM Role입니다. EC2,ECS,Lambda에서는 Role을 붙이면 SDK가 임시 자격 증명을 자동으로 가져오므로 키를 저장할 필요가 없습니다. “EC2의 코드가 S3에 접근"의 답이 항상 Role인 이유입니다.

그 외 시험 포인트 #

• 리전,엔드포인트. SDK 클라이언트는 리전을 지정해야 합니다. 잘못된 리전은 흔한 버그입니다.
• CLI --dry-run. 권한만 확인하고 실제 실행은 하지 않습니다.
• 에러 응답의 요청 ID. 지원 문의,디버깅 시 x-amz-request-id를 첨부합니다.

시험 출제 패턴 #

• “리스트 API 결과가 일부만 온다.” → 페이지네이션 미처리.
• “스로틀링에 어떻게 대응하나.” → 지수 백오프 + 지터(SDK 기본 재시도).
• “큐 메시지가 중복 전달돼 중복 처리된다.” → 멱등성 키 + 조건부 쓰기.
• “브라우저에서 S3로 직접 업로드, 키 배포 없이.” → presigned URL.
• “5GB 넘는 파일을 안정적으로 업로드.” → 멀티파트 업로드.
• “EC2 코드에 액세스 키를 어떻게 줄까.” → IAM Role(저장 안 함).
• “400 InvalidRequest가 반복된다.” → 재시도 말고 요청,권한 수정(4xx는 재시도 무의미).

정리 #

이번 글에서 잡은 것:

• 페이지네이션. 토큰을 따라 반복. 첫 페이지만 읽는 코드는 버그
• 지수 백오프 + 지터. 스로틀링/5xx 대응. SDK가 기본 내장, 4xx는 재시도 무의미
• 멱등성 키 + 조건부 쓰기로 at-least-once 중복 방어
• S3. 큰 파일은 멀티파트, 클라이언트 직접 접근은 presigned URL
• 자격 증명 공급 체인. 프로덕션은 키 저장 없이 IAM Role

다음: Domain 2-1 인증과 인가 #

개발 도메인을 마쳤습니다. 다음은 26%를 차지하는 보안입니다. #7 인증과 인가에서는 IAM Role을 코드 관점에서 다시 보고, Cognito User Pool과 Identity Pool의 역할 분담, STS의 임시 자격 증명과 페더레이션을 정리하겠습니다.