2026년 Cloud Resume Challenge에 대한 나의 시도

Source: Dev.to

목차

• 프로젝트 소개
• 시작하기 전에 드리는 제안
• 소요된 시간
• 회고
• 프로젝트 아키텍처
• Lambda 함수
• DynamoDB
• API 게이트웨이
• API 스로틀링
• Git 저장소
• 추가 예정
• 개발 관찰
• Terraform (IaC)
• 보안
• Git 리포지토리
• 다음 단계

프로젝트 소개

Cloud Resume Challenge는 클라우드/DevOps 엔지니어를 목표로 하는 분들이 클라우드 분야를 시작하는 데 도움이 되도록 설계된 프로젝트입니다. 이 챌린지는 실무 경험을 강조하며, 최종 목표는 실제로 사용할 수 있는 것을 만드는 것이며, 장난감 프로젝트가 아닙니다.

이 프로젝트 자체는 페이지 조회수를 카운트하는 이력서 웹사이트입니다.

자세한 내용은 공식 사이트와 여기에서 확인할 수 있으며, 제작자가 챌린지의 동기와 목표에 대해 더 자세히 설명하고 있습니다.

시작하기 전에 제 제안

• HTML/CSS 부분을 건너뛰세요 – 이력서에 올리기 전 사이트가 어떻게 보이는지는 크게 중요하지 않습니다. 진정한 가치는 클라우드 아키텍처와 구현에 있습니다.
• 웹 콘솔부터 시작하세요 AWS(또는 선택한 클라우드 제공업체)에 익숙하지 않다면 인프라스트럭처 코드(IaC)로 바로 뛰어들기보다 웹 콘솔부터 시작하세요. 이렇게 하면 더 빠르게 진행하고 초기 데모를 빨리 만들 수 있습니다. 나중에 IaC로 전환할 때 콘솔이 암묵적으로 처리한 설정을 더 잘 이해하게 됩니다.
• 각 주제에 할애하는 시간을 절제하세요. 이 프로젝트에는 다룰 것이 많고 탐구할 것도 항상 더 있습니다. 저수준 세부 사항에 얽매이기보다 전체 아키텍처를 이해하는 데 집중하세요.

얼마나 시간을 보냈는지

저는 프론트엔드 엔지니어에서 DevOps로 전환 중이었습니다. 이 챌린지에 일주일 미만을 투자하여 웹사이트의 모든 요구 사항을 완료했습니다.

솔직히 말해서, 실제로 소요된 시간 자체는 의미가 없습니다. 이는 개인이 얼마나 깊게 파고들고 싶은지, 그리고 솔루션을 얼마나 포괄적으로 만들고 싶은지에 따라 달라집니다. 대신, 각 파트에 소요된 대략적인 비율은 다음과 같습니다.

반성

스포일러 경고: 아직 도전을 완료하지 않으셨다면 읽기를 중단하십시오. 곧 제 솔루션을 공개하려고 합니다.

프로젝트 아키텍처

도메인 이름(janice-zhong.com)은 CloudFront 배포로 해석되며, 이는 정적 호스팅이 설정된 S3 버킷을 가리킵니다. S3 버킷은 웹사이트 콘텐츠를 제공하고, 이 콘텐츠는 API Gateway를 호출하여 Lambda 함수가 DynamoDB에서 읽고 쓰도록 트리거합니다.

두 개의 TLS 인증서가 프로비저닝됩니다:

• us‑east‑1에 있는 CloudFront용
• ap‑south‑east‑2에 있는 API Gateway용

Lambda 함수

Lambda는 서버를 관리하지 않고도 AWS에서 함수를 실행할 수 있게 해주는 관리형 컴퓨팅 서비스입니다. 중요한 포인트:

• Idempotency – 각 Lambda는 여러 번 호출될 때 동일한 결과를 반환해야 합니다.
• Statelessness – 동시 호출은 새 환경에서 시작되며, 호출 간에 상태가 유지되지 않는다고 가정해야 합니다.

DynamoDB

항목 수준에서의 순차적 쓰기

첫 번째 실수는 동시에 실행되는 Lambda 함수들이 같은 레코드를 업데이트할 때 경쟁 상태가 발생할 것이라고 가정한 것이었습니다. 저는 처음에 페이지 방문마다 새 레코드를 삽입하고 전체 레코드 수를 세었습니다. 하지만 Scan 연산은 O(n) 이므로 단순 페이지 뷰 카운터로서는 비효율적이라는 문제가 빠르게 드러났습니다.

배운 점: DynamoDB는 기본적으로 항목 수준에서 순차적 쓰기(serial writes)를 제공하므로, 단일 항목에 대한 카운터를 안전하게 증가시킬 수 있습니다.

클라이언트 재시도로 제한된 동시 쓰기 방지

DynamoDB는 **RCU(읽기 용량 단위)**와 **WCU(쓰기 용량 단위)**를 기반으로 동작합니다. 온디맨드 모드에서는 초당 최대 4,000개의 쓰기가 가능합니다. 이 한도를 초과하면 DynamoDB는 ProvisionedThroughputExceededException을 반환합니다. 클라이언트 측에서 지수 백오프 재시도를 구현해 이 예외를 처리하면 쓰기 제한(throttling)을 완화할 수 있습니다.

API 게이트웨이

이 게시물을 간결하게 유지하기 위해 많은 세부 사항을 생략하겠지만, 강조할 만한 핵심 주제 중 하나는 API 게이트웨이에서의 throttling입니다.

API 제한

(스루틀링 제한, 버스트 용량 및 사용 계획을 구성하는 방법에 대한 자세한 내용은 여기에서 확인할 수 있습니다.)

Git 저장소

저장소 링크 (실제 URL로 #을 교체하세요)

더 많은 내용이 곧 제공됩니다

Stay tuned for deeper dives into:

• CI/CD 파이프라인
• 모니터링 및 알림
• 비용 최적화

모든 제목, 목록, 링크는 원본 내용을 보존하면서 표준화되었습니다.

Development Observations

During development I noticed a large amount of bot traffic hitting my CloudFront distribution. This prompted me to set up throttling in API Gateway.

API Gateway Throttling

API Gateway throttling can be applied at three levels:

I applied throttling at the stage level and configured:

• Burst: 50
• Limit: 200

For more advanced per‑IP throttling, AWS WAF can be used.

Terraform (IaC)

Remote State + Locking

• 상태 파일은 절대로 버전 관리에 커밋해서는 안 됩니다. 이는 자격 증명 유출 및 상태 손상을 방지하기 위함입니다.
• 처음에는 상태를 S3 버킷에 저장했지만, 이후 HCP Terraform으로 마이그레이션하여 더 나은 관리를 구현했습니다.

Always Pin Versions

프로바이더와 모듈 버전을 고정하여 상위 업데이트로 인한 예기치 않은 파괴적 변경을 방지합니다.

Use HCP Terraform for Automated Terraforming (CI/CD)

• HCP Terraform은 GitHub Actions와 비교했을 때 별도 설정 없이도 감사 로그와 수동 승인 워크플로를 기본 제공합니다.
• 이를 통해 Terraform 기반 CI/CD 파이프라인의 운영 부담을 크게 줄일 수 있습니다.

보안

OIDC

OpenID Connect (OIDC)는 GitHub Actions 워크플로가 AWS 계정에서 IAM 역할을 가정하고 단기간 유효한 자격 증명을 얻을 수 있게 합니다.

• GitHub 비밀에 저장된 장기 액세스 키를 제거합니다.
• 자격 증명 회전의 운영 부담을 줄입니다.

TLS

TLS는 클라이언트와 서버 간 트래픽을 암호화합니다.

• 두 개의 TLS 인증서가 프로비저닝됩니다:
  • us‑east‑1 – CloudFront용
  • ap‑south‑east‑2 – API Gateway용

인간 검증 프로세스 추가

봇 트래픽이 많아 정당한 사용자가 제한에 의해 차단될 수 있다는 우려가 제기되었습니다. 두 가지 옵션을 사용할 수 있습니다:

AWS WAF 접근 방식에 대한 튜토리얼은 here에서 확인할 수 있습니다.

Git 저장소

• 프론트엔드:
• IaC:

다음 단계

기본 워크플로우를 실행 중이며 곧 Cloud Resume Challenge 책을 다루어 선택적인 추가 과제를 구현할 예정입니다.

계속 기대해 주세요!