DVA-C02를 풀다 보면 Lambda, DynamoDB, SQS가 따로 나오기보다 한 애플리케이션 흐름 안에서 같이 나오는 경우가 많습니다. 예를 들어 “주문 요청을 비동기로 처리한다”, “중복 처리를 막는다”, “처리에 실패한 메시지를 다시 다룬다” 같은 상황입니다.

이때 서비스 이름만 외우면 오히려 헷갈립니다. Lambda는 코드를 실행하는 쪽, DynamoDB는 상태와 조건을 저장하는 쪽, SQS는 요청을 잠시 받아두고 재시도할 수 있게 만드는 쪽입니다. 문제를 읽을 때 이 세 역할을 먼저 나누면 보기 4개 중 절반은 빠르게 지울 수 있습니다.

아래 문제들은 실제 시험 원문이 아니라 DVA-C02 범위에 맞춰 만든 한국어 연습문제입니다. 목표는, 어떤 단서에서 Lambda, DynamoDB, SQS 선택이 갈리는지 보는 것입니다.

먼저 봐야 할 공식 범위

AWS 공식 DVA-C02 exam guide 기준으로 이 시험은 개발자 직무의 사람이 AWS 기반 애플리케이션을 개발, 테스트, 배포, 디버깅할 수 있는지를 봅니다. 도메인은 AWS 서비스 기반 개발, 보안, 배포, 문제 해결과 최적화로 나뉩니다.

Lambda, DynamoDB, SQS는 특히 “애플리케이션을 어떻게 만들고, 실패했을 때 어떻게 복구하고, 중복 처리를 어떻게 줄일 것인가”라는 문제에서 자주 연결됩니다. 그래서 세 서비스를 따로 정리하기보다 작은 문제 상황으로 묶어서 보는 편이 좋습니다.

문제 1. 주문 처리 Lambda가 가끔 같은 주문을 두 번 저장한다

한 쇼핑몰 애플리케이션에서 주문 요청을 SQS 큐에 넣고, Lambda가 메시지를 읽어 DynamoDB Orders 테이블에 저장합니다. 네트워크 오류 때문에 같은 주문 메시지가 다시 처리될 수 있습니다. 같은 orderId가 이미 저장되어 있다면 두 번째 저장은 막아야 합니다.

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

  • A. Lambda reserved concurrency를 1로 설정한다.
  • B. DynamoDB PutItem에 조건식을 사용해 기존 orderId가 없을 때만 저장한다.
  • C. SQS 메시지 보존 기간을 줄인다.
  • D. Lambda timeout을 늘린다.

정답: B

해설: 중복 저장을 막는 핵심은 “이미 같은 주문이 있는지”를 데이터 저장 시점에 확인하는 것입니다. DynamoDB 조건부 쓰기를 사용하면 같은 키가 이미 있을 때 쓰기를 실패시킬 수 있습니다. reserved concurrency를 1로 줄이면 병렬 처리는 줄어들지만 중복 메시지 자체를 해결하지는 못합니다. SQS 보존 기간과 Lambda timeout도 중복 저장 방지 조건과 직접 관련이 없습니다.

실무에서는 이 패턴을 idempotency key로 확장하기도 합니다. 예를 들어 requestId를 별도 DynamoDB 테이블에 기록하거나, 주문 저장과 idempotency 기록을 TransactWriteItems로 묶을 수 있습니다. SQS FIFO deduplication도 짧은 시간의 중복 메시지를 줄이는 데 도움이 되지만, 최종 저장소의 중복 방지 조건을 완전히 대체하지는 않습니다. 그래서 이 문제처럼 “같은 orderId가 이미 저장되어 있으면 두 번째 저장을 막는다”가 핵심이면 조건부 쓰기가 가장 직접적인 답입니다.

시험에서 볼 단서: “이미 존재하면 저장하지 않는다”, “중복 요청”, “idempotent write”가 나오면 DynamoDB 조건부 쓰기를 먼저 의심합니다.

문제 2. Lambda가 SQS 메시지를 처리하다 실패하면 같은 메시지가 반복된다

Lambda가 SQS 큐에서 메시지를 받아 외부 API를 호출합니다. 외부 API가 간헐적으로 실패해 Lambda가 오류를 반환합니다. 같은 메시지를 몇 번 재시도한 뒤에도 계속 실패하면 별도 큐로 보내 운영자가 확인하게 하고 싶습니다.

가장 적절한 구성은 무엇일까요?

  • A. SQS dead-letter queue를 구성하고 max receive count를 설정한다.
  • B. DynamoDB TTL을 설정한다.
  • C. Lambda 환경 변수를 추가한다.
  • D. SQS long polling을 끈다.

정답: A

해설: 반복 실패 메시지를 분리하려면 dead-letter queue가 맞습니다. max receive count를 넘긴 메시지를 DLQ로 보내면 정상 메시지 처리와 실패 메시지 조사를 분리할 수 있습니다. DynamoDB TTL은 오래된 항목 삭제에 가깝고, 환경 변수는 실패 메시지 분리와 직접 관련이 없습니다. long polling은 빈 응답을 줄이는 설정이지 실패 메시지 격리 기능이 아닙니다.

시험에서 볼 단서: “여러 번 실패한 메시지를 별도로 보관”, “운영자가 나중에 분석”, “poison message”가 나오면 DLQ를 생각합니다.

문제 3. 처리량이 갑자기 늘어 Lambda가 DynamoDB 쓰기 제한에 걸린다

이벤트가 갑자기 늘어나면서 Lambda가 DynamoDB에 많은 쓰기를 시도합니다. 일부 요청이 throttling을 만나고 있습니다. 애플리케이션은 짧은 지연을 허용하지만 요청을 잃으면 안 됩니다.

가장 적절한 개선 방향은 무엇일까요?

  • A. API Gateway와 Lambda 사이에 SQS를 넣어 요청을 버퍼링한다.
  • B. Lambda 함수 이름을 바꾼다.
  • C. DynamoDB 테이블 이름을 바꾼다.
  • D. CloudWatch Logs를 비활성화한다.

정답: A

해설: 짧은 지연을 허용하고 요청 손실을 줄이고 싶다면 큐로 완충하는 패턴이 잘 맞습니다. SQS는 갑작스러운 요청 증가를 받아두고 Lambda가 처리 가능한 속도로 소비하게 만들 수 있습니다. 함수 이름이나 테이블 이름 변경은 처리량 문제와 관련이 없습니다. 로그를 끄는 것은 원인 분석을 더 어렵게 만들 수 있습니다.

시험에서 볼 단서: “트래픽 급증”, “짧은 지연 허용”, “요청 손실 방지”, “decouple”이 나오면 SQS 버퍼링을 봅니다.

문제 4. FIFO 순서와 중복 제거가 필요하다

결제 이벤트를 처리하는 애플리케이션이 있습니다. 같은 고객의 결제 이벤트는 순서대로 처리되어야 하고, 동일한 이벤트가 짧은 시간 안에 중복으로 들어오면 한 번만 처리하고 싶습니다.

가장 적절한 SQS 큐 유형은 무엇일까요?

  • A. Standard queue
  • B. FIFO queue
  • C. Dead-letter queue만 단독으로 사용
  • D. Delay queue만 단독으로 사용

정답: B

해설: 순서 보장과 중복 제거가 핵심이면 FIFO queue가 맞습니다. Standard queue는 높은 처리량에 유리하지만 strict ordering이나 exactly-once에 가까운 처리 요구에는 맞지 않을 수 있습니다. DLQ는 실패 메시지 격리용이고, delay queue는 메시지 전달 지연용입니다.

시험에서 볼 단서: “순서 보장”, “중복 제거”, “같은 그룹의 이벤트”가 나오면 FIFO queue와 message group id를 떠올립니다.

문제 5. Lambda가 오래 걸리는 작업을 동기 호출로 처리하고 있다

사용자가 API를 호출하면 Lambda가 이미지 분석 작업을 바로 실행합니다. 처리 시간이 길어질 때 사용자는 응답을 오래 기다려야 하고, 가끔 timeout이 발생합니다. 사용자는 즉시 접수 응답을 받고, 작업 결과는 나중에 확인해도 됩니다.

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

  • A. API 요청을 SQS에 넣고 Lambda가 비동기로 처리하게 한다.
  • B. Lambda 메모리를 128MB로 낮춘다.
  • C. DynamoDB 테이블을 삭제한다.
  • D. API Gateway stage 이름을 바꾼다.

정답: A

해설: 사용자가 즉시 응답을 받아도 되고 작업은 나중에 처리해도 된다면 비동기 큐 기반 처리가 적절합니다. API는 접수만 하고, 실제 작업은 SQS와 Lambda 조합으로 처리할 수 있습니다. 메모리를 낮추면 성능은 오히려 나빠질 수 있고, 테이블 삭제나 stage 이름 변경은 timeout 문제를 해결하지 않습니다.

시험에서 볼 단서: “즉시 응답”, “나중에 처리”, “긴 작업”, “timeout 감소”가 나오면 동기 처리에서 비동기 처리로 분리하는 패턴을 봅니다.

문제 6. Lambda가 실패했는데 어떤 메시지가 실패했는지 찾기 어렵다

SQS 메시지를 처리하는 Lambda가 일부 메시지에서 실패합니다. 개발팀은 실패 원인을 빠르게 찾기 위해 각 메시지 처리의 로그와 오류를 추적하고 싶습니다.

먼저 확인할 조합으로 가장 적절한 것은 무엇일까요?

  • A. CloudWatch Logs와 Lambda error metrics를 확인한다.
  • B. Route 53 hosted zone을 삭제한다.
  • C. S3 버킷을 public으로 연다.
  • D. DynamoDB 파티션 키를 무작위로 바꾼다.

정답: A

해설: DVA-C02의 문제 해결 관점에서는 Lambda 실행 로그, 오류 지표, 재시도 상황을 먼저 확인하는 흐름이 자연스럽습니다. CloudWatch Logs에서 어떤 메시지 처리 중 오류가 났는지 확인하고, Lambda metrics로 오류율과 throttling을 봅니다. 나머지 선택지는 문제 해결과 관련이 없거나 위험한 조치입니다.

시험에서 볼 단서: “디버깅”, “실패 원인 확인”, “오류율”, “로그”가 나오면 CloudWatch와 Lambda metrics를 먼저 봅니다.

세 서비스를 구분하는 빠른 기준

문제 단서먼저 의심할 것
코드를 실행한다, 이벤트를 처리한다Lambda
중복 저장을 막는다, 조건이 맞을 때만 쓴다DynamoDB conditional write
트래픽을 완충한다, 비동기로 처리한다SQS
반복 실패 메시지를 분리한다SQS dead-letter queue
순서 보장과 중복 제거가 필요하다SQS FIFO
실행 로그와 오류율을 본다CloudWatch Logs, Lambda metrics

Lambda, DynamoDB, SQS 문제는 “어떤 서비스를 아는가”보다 “어떤 책임을 어디에 둘 것인가”를 묻는 경우가 많습니다. 실행은 Lambda, 상태와 조건은 DynamoDB, 완충과 재시도는 SQS로 먼저 나누면 헷갈리는 선택지를 줄일 수 있습니다.

참고한 공식 자료