DVA-C02에서 DynamoDB 조건부 쓰기는 단순한 문법 문제가 아닙니다. 백엔드에서 같은 주문 요청이 두 번 들어오거나, Lambda가 같은 이벤트를 재처리하거나, SQS 메시지가 다시 전달되는 상황과 연결됩니다.

핵심은 저장 시점에 “이미 처리한 요청인가”를 확인하는 것입니다. 아래 문제들은 실제 시험 원문이 아니라 DVA-C02 범위에 맞춘 자체 제작 연습문제입니다.

먼저 결론: 중복 방지는 저장 시점 조건이 필요하다

중복 요청을 막을 때 자주 보이는 선택지는 다음처럼 갈립니다.

선택지역할
DynamoDB conditional write같은 key가 이미 있으면 쓰기를 실패시키거나 조건에 맞을 때만 update
Idempotency key같은 요청을 식별하는 안정적인 key
TransactWriteItems여러 item의 조건 확인과 쓰기를 하나의 transaction으로 처리
SQS FIFO deduplication일정 범위에서 동일 메시지 중복 전달을 줄임
Lambda reserved concurrency동시 처리 수를 제한하지만 중복 이벤트 자체를 제거하지는 않음

시험에서는 “중복 저장을 막는다”는 요구사항이 나오면 concurrency 제한보다 데이터 조건을 먼저 봐야 합니다.

문제 1. 같은 주문 ID로 두 번 저장되면 안 된다

주문 API가 DynamoDB Orders 테이블에 주문을 저장합니다. 클라이언트 재시도 때문에 같은 orderId로 요청이 두 번 들어올 수 있습니다. 같은 orderId가 이미 있으면 두 번째 쓰기는 실패해야 합니다.

가장 적절한 방법은 무엇일까요?

  • A. PutItem에 attribute_not_exists(orderId) 조건을 사용한다.
  • B. Lambda reserved concurrency를 1로 설정한다.
  • C. SQS retention period를 늘린다.
  • D. DynamoDB table scan을 먼저 실행한 뒤 결과가 없으면 저장한다.

정답: A

해설: DynamoDB 조건부 쓰기는 지정한 조건이 참일 때만 쓰기를 수행합니다. partition key가 orderId라면 attribute_not_exists(orderId) 조건으로 이미 같은 주문이 있을 때 저장을 실패시킬 수 있습니다. reserved concurrency는 동시 실행을 줄일 뿐, 재시도나 중복 요청이 순차적으로 들어오는 상황까지 해결하지 못합니다.

시험에서 볼 단서: duplicate request, same orderId, only if item does not exist, conditional write

문제 2. 같은 requestId는 한 번만 처리해야 한다

결제 처리 Lambda가 API Gateway 뒤에서 호출됩니다. 클라이언트는 requestId를 함께 보냅니다. 같은 requestId가 다시 들어오면 결제를 다시 실행하지 않고 이전 처리 결과를 반환해야 합니다.

가장 적절한 설계는 무엇일까요?

  • A. requestId를 idempotency key로 저장하고 조건부 쓰기로 최초 요청만 처리한다.
  • B. Lambda timeout을 길게 늘린다.
  • C. CloudWatch alarm을 만든다.
  • D. DynamoDB table 이름을 매 요청마다 바꾼다.

정답: A

해설: idempotent API에서는 같은 요청을 식별할 key가 필요합니다. DynamoDB에 requestId를 key로 저장하고 조건부 쓰기를 사용하면 최초 요청만 성공시키고, 이후 같은 요청은 저장된 결과를 조회해 응답할 수 있습니다. timeout 증가는 느린 처리를 완화할 수는 있지만 중복 결제를 막는 조건이 아닙니다.

시험에서 볼 단서: idempotent, requestId, retry, do not process twice

문제 3. 주문과 포인트 차감을 함께 처리해야 한다

주문 생성 시 Orders item을 만들고, 같은 요청에서 UserBalance item의 포인트도 차감해야 합니다. 주문이 이미 있으면 포인트 차감도 일어나면 안 됩니다. 두 작업은 함께 성공하거나 함께 실패해야 합니다.

가장 적절한 DynamoDB 기능은 무엇일까요?

  • A. TransactWriteItems와 조건식을 사용한다.
  • B. 두 번의 독립적인 PutItem을 순서대로 실행한다.
  • C. CloudFront cache invalidation을 실행한다.
  • D. S3 lifecycle policy를 만든다.

정답: A

해설: 여러 item에 대한 조건 확인과 쓰기가 하나의 단위로 처리되어야 하면 DynamoDB transaction을 봐야 합니다. TransactWriteItems에서 주문 item에는 attribute_not_exists 조건을 걸고, 포인트 차감 update에도 필요한 조건을 함께 둘 수 있습니다. 독립적인 두 번의 쓰기는 중간 실패 시 불일치가 생길 수 있습니다.

시험에서 볼 단서: all-or-nothing, multiple items, atomic, transaction, conditional check

문제 4. SQS 메시지가 재전달되어도 중복 저장되면 안 된다

SQS standard queue가 Lambda를 트리거합니다. Lambda는 메시지를 처리해 DynamoDB에 결과를 저장합니다. 네트워크 오류나 Lambda 실패로 같은 메시지가 다시 처리될 수 있습니다.

가장 중요한 애플리케이션 설계는 무엇일까요?

  • A. 메시지의 안정적인 ID를 idempotency key로 사용하고 DynamoDB 조건부 쓰기를 적용한다.
  • B. SQS message retention period를 1일로 줄인다.
  • C. Lambda memory를 늘리면 중복 처리가 사라진다.
  • D. CloudTrail을 끈다.

정답: A

해설: SQS standard queue는 중복 전달 가능성을 고려해야 합니다. 따라서 consumer는 idempotent하게 작성해야 합니다. DynamoDB 조건부 쓰기는 “이미 처리한 메시지인지”를 저장 시점에 확인하는 방법입니다. retention period나 memory 설정은 성능/보관과 관련이 있지만 중복 저장 방지 조건은 아닙니다.

시험에서 볼 단서: SQS standard, at-least-once, retry, duplicate processing, idempotent consumer

문제 5. SQS FIFO deduplication만 있으면 충분할까?

팀은 SQS FIFO queue의 deduplication 기능을 사용하고 있습니다. 하지만 애플리케이션은 동일한 비즈니스 요청이 다른 경로로 다시 들어오는 경우에도 중복 저장을 막아야 합니다.

가장 안전한 판단은 무엇일까요?

  • A. FIFO deduplication을 쓰더라도 데이터 저장 시점의 idempotency 조건을 둔다.
  • B. FIFO queue를 쓰면 애플리케이션 idempotency는 항상 필요 없다.
  • C. reserved concurrency를 0으로 설정한다.
  • D. DynamoDB 조건부 쓰기는 읽기 전용 기능이다.

정답: A

해설: SQS FIFO deduplication은 메시징 계층에서 중복 전달을 줄이는 기능입니다. 그러나 비즈니스 요청이 다른 경로로 들어오거나 deduplication 범위 밖에서 재시도될 수 있습니다. 결제, 주문, 포인트처럼 중복 처리 비용이 큰 작업은 애플리케이션과 데이터 저장 계층에서도 idempotency를 갖추는 편이 안전합니다.

시험에서 볼 단서: FIFO, deduplication, business request, idempotency, data layer

문제 6. 이미 처리된 요청이면 상태를 바꾸면 안 된다

DynamoDB item에는 status가 있습니다. PENDING 상태일 때만 COMPLETED로 바꿔야 하며, 이미 COMPLETED인 요청을 다시 update하면 안 됩니다.

가장 적절한 방법은 무엇일까요?

  • A. UpdateItem에 status = :pending 조건을 둔다.
  • B. 매번 PutItem으로 item 전체를 덮어쓴다.
  • C. DynamoDB table을 삭제하고 다시 만든다.
  • D. CloudWatch dashboard를 만든다.

정답: A

해설: 조건부 쓰기는 새 item 생성뿐 아니라 update에도 사용할 수 있습니다. 현재 상태가 기대한 값일 때만 상태 전이를 허용하면 중복 처리나 잘못된 재시도로 인한 상태 덮어쓰기를 줄일 수 있습니다.

시험에서 볼 단서: only if current status, state transition, conditional update, prevent overwrite

결론

DVA-C02에서 DynamoDB 조건부 쓰기는 “데이터를 안전하게 저장하는 방법”으로 나옵니다. 특히 재시도, 중복 메시지, 같은 주문 ID, 같은 request ID가 보이면 idempotency와 함께 생각해야 합니다.

정리하면 다음 기준입니다.

  • 같은 key가 이미 있으면 저장하면 안 된다: attribute_not_exists
  • 현재 상태가 특정 값일 때만 바꾼다: conditional update
  • 여러 item을 함께 성공/실패시킨다: TransactWriteItems
  • SQS/Lambda 재시도가 있다: consumer idempotency와 조건부 쓰기
  • FIFO deduplication이 있어도 비즈니스 중복 방지는 별도로 검토

시험에서 “중복을 막는다”는 말이 나오면 먼저 저장 시점 조건을 보세요. concurrency, timeout, retention period는 보조 단서일 수 있지만 중복 저장 방지의 핵심은 idempotent한 데이터 쓰기입니다.

참고한 공식 자료