AWS Full Serverless로 공부 사이트 만들어보기 (with Codex 5.3)

작년에 이어 올해도 AWSKRUG 자격증 소모임 운영진을 이어가고 있는데, 작년까진 자격증 소모임 공부를 위한 서포트를 디스코드를 이용하여 운영중이었습니다.

 

하지만, 아무래도 디스코드의 인지도가 한국에선 부족한 부분도 있고, 채찍질(?)이 잘 되지 않는다는 이야기도 있어서 기왕 만드는 김에 사이트를 만들고 운영하게 되었습니다.

 

사실 공부를 위한 사이트는 이것 말고 하나 더 있긴 합니다.

자격증 시험을 대비하기 위한 사이트가 있는데 (aws-exam.drumgoon.net) 이것과 연동하려는 목적으로 공부 사이트를 만들었습니다.

 

아키텍쳐

 

보시면 아시겠지만, AWS의 일반 컴퓨팅 방식이 쓰이지 않은 100% 서버리스 구성입니다.

DB의 경우도 DynamoDB가 아닌 Postgresql을 사용하기 위해 DSQL을 적용하였습니다.

 

 

DSQL 주의점

• Serverless지만 RDS와 유사한 Aurora Serverless와는 다릅니다.
• DSQL은 ID는 고정이지만 AWS IAM 기반으로 정해진 시간 단위로 세션을 적용하는 방식으로 고정된 PW를 쓸수가 없습니다.
• 백엔드에서 Database 연동시 반드시 재시도 로직을 적용하지 않으면 어플리케이션이 멈추는 광경을 볼 수 있습니다.
• 람다가 재시작하면서 인증을 계속 시도하기 때문에 인증 시간 동안은 새로 생성된 비밀번호를 사용하게 되며, 다량의 인증시에도 인증 권한 / TTL을 고려하여 비밀번호가 동작하기에 TTL만 잘 설정한다면 훨씬 안전하게 비밀번호를 지키며 사용이 가능합니다.
• 문서를 보니 아래와 같은 제약 사항이 있었습니다.
  • 람다 동시성에 의한 1000 token은 생성해도 문제 없음
  • 람다에서 1 token으로 1000개의 커넥션이 넘어가는 경우엔 문제 있음
  • 일반적으로 최적의 커넥션 개수 : DB connection <= 100~200
  • 인증 TTL : 15min ~ 7Day까지 가능

개발 스택

• Frontend : React 19
• Backend : Go lang 1.22
• Infra : AWS (Api Gateway + Lambda + DSQL)
• Code Repo : Github

백엔드의 경우 100% Lambda Function으로 나눈것이 아닌 Docker Image를 통째로 올려놓고 쓰는 형태로 작업했습니다.

일반 백엔드 개발자는 Key-Value 기반의 DynamoDB보다 SQL이 적응되어 있고 그 부분을 한번 DSQL로 해보면 어떨까? 라고 생각했습니다. (시험 사이트는 DynamoDB + ECR + ECS + Fargate로 구성되어 있습니다)

 

백엔드, 프론트엔드는 Codex를 이용해서 작업했습니다.

일 8시간 정도 프로토 타입과 빌드에 3일 가량 소모되었습니다.

 

일단 이 아키텍쳐의 장점과 단점은 명확했습니다.

 

장점

1. 완전 서버리스

•  기존의 EC2, ECS, EKS같은 컴퓨팅 노드를 모니터링하고 운영해야 하는 물리적인 관리 코스트가 줄어듭니다.

2. Github Action 배포

• 언제 어디서든지 Code Push만 하면 배포가 가능하다.

3. 쓴 만큼만 과금

• 사용한 만큼만 비용이 나오기 때문에 일반 컴퓨팅의 비용 계산 방식에서 벗어나서 쓴 만큼만 과금되는 명확한 비용을 확인할 수 있습니다.

 

단점

1. Lambda Cold Start

• Lambda Cold Start를 최대한 줄이기 위해 Go lang backend가 적용되어 있습니다만, 사용자가 사용을 시작할때 내부 인스턴스가 떠 있지 않다면 부팅같은 느낌의 Cold Start가 발생하는데 늘 3~6초가 발생합니다.
• 이 문제를 해결하기 위해 layer를 도입해보려 하였으나, Node.js와 달리 layer가 제대로 활용할 수 없는 것으로 예상되어 일단 제외 했습니다.
• Lambda 실행 환경은 일정 시간 동안 재사용될 수 있습니다. 실행 후 몇 분 정도 warm 상태가 유지되는 경우가 있지만 AWS에서 보장되는 동작은 아닙니다. 따라서 실행 환경이 이미 존재한다고 하더라도 Cold Start가 발생하지 않는다고 보장할 수는 없습니다.
  트래픽이 예상되는 경우 사전에 API를 호출하여 Lambda 실행 환경을 warm 상태로 만들어 Cold Start 발생 가능성을 줄일 수 있습니다.

 

2. 컴퓨팅 대비 비싼 비용

• AWS의 서버리스 비용은 대용량 사용자용과 소규모 사용자용으로 확실히 나뉘는 것 같습니다. 서버리스를 작은 규모로 사용할 경우 Free Tier 적용으로 인해 무료에 가깝게 운영할 수 있다는 장점이 있습니다.
  다만 Lambda는 기본적으로 계정/리전당 동시 실행 1,000개의 제한이 있으며 필요 시 AWS에 요청하여 늘릴 수 있습니다. 또한 트래픽이 증가하여 비용이 EC2 기반 컴퓨팅 아키텍처보다 높아지는 경우에는 일반 컴퓨팅 체제로 전환하는 것도 고려할 필요가 있습니다.
• 컴퓨팅에 경우, Reserved Instance (예약 인스턴스), Savings Plan 등 여러가지 방법을 이용하여 비용을 절감할 수 있는 방법이 있으며 특히 RI의 경우 3년 All upfront (전체 선결제) 적용시 최대 72%까지 할인 되는 경우도 있으며, Spot Instance의 경우 평균 60% 이상의 할인율을 가진 인스턴스도 선택이 가능하지만, 서버리스의 경우 Lambda에 한해서만 SP 적용이 가능합니다. (20% 할인)
• 특히 지속적으로 높은 트래픽이 발생하는 서비스의 경우 호출 기반 과금 구조로 인해 서버리스 비용이 빠르게 증가할 수 있습니다.

 

3. Lambda의 제한

• Lambda의 기본 Timeout은 3초이며 최대 15분까지 설정할 수 있습니다.
• 다만 API Gateway를 통해 호출되는 구조에서는 API Gateway의 Integration Timeout이 약 29초이기 때문에 실제 API 응답 시간은 이 제한의 영향을 받습니다.
• 따라서 일반적인 API 응답은 보통 몇 초 이내로 처리하는 것이 권장되며, 수 분 이상 수행되는 작업은 Step Functions, SQS, Event 기반 처리 등 비동기 아키텍처로 설계하는 것이 일반적입니다.

 

바이브 코딩

어떻게 만들어야 하는지 기능 목록도 명확했고, Coding Agent를 사용하고 있기 때문에 sub agent까지 도입해서 하려고 아래 문서를 참조하여 여러 AGENTS.md를 만들도록 했습니다.

 

만들고 난 뒤 sub agent를 이용해서 제가 필요한 기능, agent들을 만들었습니다.

• 기획자 Agent
• 웹 디자이너 Agent
• Frontend 개발자 Agent
• Backend 개발자 Agent
• QA Agent

이렇게 해놓고 Codex 5.3을 WSL 모드 (전 윈도우 유저입니다)로 구동하여 열심히 작업했습니다.

물론 Codex는 윈도우에서도 사용이 잘 됩니다만, Command Level에서의 명령어는 linux가 더 명확하게 동작하며, Windows Script는 비정상 동작하여 실수가 잦고 Token을 더 많이 소모되고 작업 시간이 더 많이 소요되기 때문이었습니다.

단, 기존에는 제가 디자인을 잘 못해서 Coding Agent를 써도 정말 디자인이 맘에 안 들었었는데 이번엔 TailAdmin Template을 사용하여 깔끔하게 작업했습니다.

아예 TailAdmin을 다운로드 받아서 기억해두고 모든 Components를 100% Native로 사용하게 지침을 주고 코딩했습니다.

 

배포

배포는 Github Action을 이용하여 빠르게 처리했습니다.

브랜치를 활용하여 특정 브랜치에서만 작동하도록 하였고

• Frontend : 자동으로 S3 업데이트 + CloudFront invalidation
• Backend : ECR Image Upload + Lambda Alias 변경

이렇게 해놓고 보니 제가 맥에서 작업하던 윈도우에서 작업하던 Github 인증하고 push만 한다면 자연스럽게 배포할 수 있는 구조로 적용이 되었습니다.

 

결과물

https://study.drumgoon.net

My Study Memory

 

 

 

AWS 자격증에 관심이 있으시다면 AWSKRUG Slack #cert 채널에 오시면 참가하실 수 있습니다.

 

AWSKRUG Slack: https://slack.awskr.org/

AWSKRUG Slack 채널 - AWS 한국사용자모임

 

자격증 소모임 카카오톡방 : https://open.kakao.com/o/garbWa3g

AWSKRUG 자격증 소모임 서티라운지

 

참고자료

https://aws.amazon.com/ko/rds/aurora/dsql/

https://docs.aws.amazon.com/aurora-dsql/latest/userguide/SECTION_authentication-token.html

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html

https://aws.amazon.com/ko/blogs/compute/understanding-and-remediating-cold-starts-an-aws-lambda-perspective/

https://docs.aws.amazon.com/ko_kr/savingsplans/latest/userguide/sp-ris.html

https://docs.aws.amazon.com/ko_kr/lambda/latest/dg/configuration-timeout.html

https://developers.openai.com/codex/guides/agents-md/