Claude로 아키텍처를 설계해 봤습니다.
안녕하세요 클래스메소드 김재욱(Kim Jaewook) 입니다. 이번 블로그에서는 Claude로 아키텍처를 설계해 봤습니다.
이전 글에서는 요구사항을 기반으로 CloudFormation 코드를 생성하고 실제 배포까지 진행해보았습니다. 하지만 실제 서비스 개발에서는 코드 작성 이전에 어떤 구조로 시스템을 구성할지 설계하는 과정이 더 중요합니다.
이번에는 이 설계 과정을 Claude에게 맡겨보겠습니다.
Claude로 CloudFormation 코드를 생성하고 실제 배포하는 과정은 아래 블로그를 참고해 주세요.
요구사항 정의
먼저 간단한 서비스 요구사항을 정의합니다.
간단한 웹 서비스를 만들고 싶어.
- 사용자는 웹 페이지에 접속할 수 있어야 함
- 트래픽은 많지 않지만, 기본적인 확장성은 고려
- 비용은 최대한 낮게 유지
- 데이터 저장 필요 (간단한 DB)
- AWS 환경 사용
이어서 프롬프트를 구체화해서 질문합니다.
너는 AWS 솔루션 아키텍트야.
위 요구사항을 기반으로:
- 전체 아키텍처를 설계하고
- 사용해야 할 AWS 서비스 목록을 제시하고
- 각 서비스의 역할을 설명해줘
또한:
- 왜 이 구조를 선택했는지
- 비용과 확장성 관점에서의 장점
까지 포함해서 설명해줘.
Claude 결과
상기 요구사항과 프롬프트를 Claude에게 전달한 결과입니다.
아키텍처를 두 개의 다이어그램으로 나눠서 설명하겠습니다. 먼저 전체 구조부터 보여드립니다.
다음은 트래픽이 실제로 흐르는 요청 흐름 다이어그램입니다.
AWS 서비스 구성 및 역할
선택한 서비스 5가지
- Route 53 — DNS 라우팅
도메인 이름을 IP 주소로 변환하는 진입점입니다. 헬스 체크와 장애 조치(failover) 라우팅도 내장되어 있어, 나중에 멀티 리전으로 확장할 때도 그대로 활용할 수 있습니다. - CloudFront — CDN + HTTPS 처리
정적 파일(HTML, CSS, JS, 이미지)을 전 세계 엣지 로케이션에 캐싱합니다. 사용자는 물리적으로 가까운 서버에서 응답을 받으므로 체감 속도가 빠릅니다. HTTPS 인증서(ACM)도 무료로 붙일 수 있습니다. 캐시 히트 시 Lambda·DB 호출이 전혀 없으므로 비용이 거의 0에 수렴합니다. - S3 — 정적 파일 호스팅
React, Vue 같은 SPA 빌드 결과물, 이미지, 폰트 등을 저장합니다. 서버가 필요 없고 스토리지 비용만 부과됩니다. GB당 $0.023 수준으로 사실상 무시할 만한 수준입니다. - API Gateway + Lambda — 서버리스 백엔드
REST API 엔드포인트를 API Gateway가 받고, 실제 비즈니스 로직은 Lambda 함수가 처리합니다. 요청이 없으면 비용이 발생하지 않습니다. Lambda는 월 100만 건 무료 티어가 있어 트래픽이 적은 초기 서비스는 사실상 무료로 운영됩니다. 트래픽 급증 시 자동으로 수평 확장합니다. - Aurora Serverless v2 — 데이터베이스
RDS처럼 항상 켜진 인스턴스가 아니라, 실제 요청 부하에 따라 용량이 자동으로 0.5 ACU까지 축소됩니다. 트래픽이 없는 시간에는 거의 비용이 들지 않고, 피크 트래픽 시에는 수십 ACU까지 자동 확장됩니다. MySQL 호환이므로 기존 ORM, 드라이버를 그대로 사용할 수 있습니다.
왜 이 구조인가
서버리스를 선택한 핵심 이유는 "트래픽이 많지 않다"는 조건 때문입니다. EC2를 상시 운영하면 사용량에 무관하게 고정 비용이 발생합니다. 반면 Lambda + Aurora Serverless 조합은 요청이 있을 때만 과금되므로 초기 트래픽이 적을수록 유리합니다.
확장성 관점에서는 Lambda가 동시 실행 수를 자동으로 늘리고 CloudFront가 전 세계 캐싱을 담당하기 때문에, 트래픽이 10배 늘어도 아키텍처를 바꿀 필요가 없습니다. 서버 증설, 로드밸런서 튜닝 같은 작업이 필요 없습니다.
예상 월 비용 (소규모 서비스 기준)
예상 월 비용 (소규모 서비스 기준)
| 서비스 | 예상 비용 |
|---|---|
| Route 53 | ~$0.50 (호스팅 존 1개) |
| CloudFront | ~$1–3 (트래픽 10GB 이하) |
| S3 | ~$0.10 이하 |
| API Gateway | ~$1 (월 100만 건 이하) |
| Lambda | 무료 티어 범위 내 |
| Aurora Serverless v2 | ~$10–20 (유휴 시간 많을 경우) |
| 합계 | 약 $15–25/월 |
트래픽이 늘어나면 비용도 비례해서 증가하지만, 동시에 수익도 발생하는 구조이므로 스타트업 초기에 가장 합리적인 선택입니다.
한계와 고려사항
Aurora Serverless v2는 완전한 cold start가 없어지긴 했지만, 장시간 트래픽이 없다가 갑자기 요청이 몰리면 수 초의 스케일업 지연이 생길 수 있습니다. 이 점이 민감하다면 최소 ACU를 1로 고정하는 옵션도 있습니다(비용 약간 증가). Lambda 역시 cold start가 있으므로 응답 시간에 민감한 엔드포인트는 Provisioned Concurrency를 고려할 수 있습니다. 추가로 궁금한 부분이 있으면 말씀해 주세요.
활용 관점에서의 핵심 포인트
이번 실습을 통해 얻을 수 있는 핵심은 다음과 같습니다.
코드 작성 이전에 설계를 먼저 진행한다요구사항을 구체적으로 정의할수록 결과 품질이 높아진다AI를 활용해 여러 아키텍처를 빠르게 비교할 수 있다초기 설계 단계에서 시행착오를 줄일 수 있다
결국 생성형 AI는 단순한 코드 생성 도구가 아니라, 설계 단계에서 의사결정을 보조하는 도구로 활용하는 것이 중요합니다.
정리
이번 글에서는 단순히 인프라 코드를 생성하는 것을 넘어, 서비스 아키텍처 설계 단계부터 Claude를 활용해보았습니다.
특히 인상적인 부분은, 몇 줄의 요구사항만으로도 실제 서비스에 적용 가능한 수준의 아키텍처 초안을 빠르게 도출할 수 있다는 점입니다. 단순한 서비스 나열이 아니라, 각 구성 요소의 역할과 선택 이유, 그리고 비용과 확장성까지 함께 고려된 결과를 얻을 수 있었습니다.
이러한 방식은 특히 초기 서비스 설계 단계에서 큰 장점을 가집니다.
직접 모든 구조를 고민하는 데 들어가는 시간을 줄이고, 여러 아키텍처 옵션을 빠르게 비교할 수 있기 때문입니다.
또한 이번 예시에서 확인할 수 있듯이, Claude는 단순히 정적인 설계를 제시하는 것이 아니라 서버리스 기반 아키텍처, 비용 최적화, 확장성 확보와 같은 실제 운영 환경에서 중요한 요소들까지 함께 고려한 결과를 제공합니다.
마무리
이번 글에서는 생성형 AI를 활용하여 단순한 코드 생성을 넘어, 서비스 아키텍처 설계 단계부터 실제로 어떻게 활용할 수 있는지를 살펴보았습니다.
기존에는 인프라를 구성하기 위해 먼저 레퍼런스를 찾고, 여러 아키텍처 패턴을 비교하고, 각 서비스의 특징을 하나씩 검토하는 과정을 거쳐야 했습니다. 하지만 이번 사례처럼 Claude를 활용하면, 몇 줄의 요구사항만으로도 기본적인 구조가 갖춰진 아키텍처 초안을 매우 빠르게 도출할 수 있습니다.
특히 인상적인 점은 단순히 서비스 목록을 나열하는 것이 아니라, 각 구성 요소의 역할, 선택 이유, 비용 구조, 확장성 전략까지 함께 고려된 결과를 제공한다는 점입니다. 이는 단순한 정보 제공을 넘어, 실제 설계 과정에서 고민해야 할 핵심 요소들을 자연스럽게 포함하고 있다는 의미이기도 합니다.
또한 이러한 접근 방식은 초기 설계 단계에서 매우 큰 장점을 가집니다.
완벽한 설계를 처음부터 만들려고 하기보다는, AI를 통해 빠르게 초안을 만들고 → 검토하고 → 개선하는 반복 구조로 접근할 수 있기 때문입니다. 이 과정에서 설계 속도는 물론, 다양한 아키텍처 옵션을 비교할 수 있는 여유까지 확보할 수 있습니다.
이번 예시에서 사용한 서버리스 기반 구조 역시 이러한 장점을 잘 보여줍니다.
Lambda, API Gateway, Aurora Serverless, CloudFront와 같은 서비스 조합은 트래픽이 많지 않은 초기 단계에서 비용을 최소화하면서도, 필요 시 자연스럽게 확장할 수 있는 구조를 제공합니다. 이러한 설계 방향을 처음부터 고려할 수 있다는 점만으로도 AI 활용의 가치는 충분하다고 볼 수 있습니다.
물론, 생성형 AI가 제안하는 아키텍처를 그대로 사용하는 것은 주의가 필요합니다.
AI는 다양한 베스트 프랙티스를 기반으로 결과를 생성하지만, 모든 환경에 최적화된 정답을 제공하는 것은 아니기 때문입니다. 따라서 생성된 설계는 반드시 검토하고, 실제 요구사항과 제약 조건에 맞게 조정하는 과정이 필요합니다.
그럼에도 불구하고, 이번 과정을 통해 확인할 수 있는 가장 중요한 변화는 명확합니다.
이제는 인프라 설계 역시 사람이 처음부터 모든 것을 만드는 것이 아니라, AI와 함께 설계를 만들어가는 방식으로 변화하고 있다는 점입니다.
앞으로의 작업 방식은 단순히 “무엇을 만들어달라”는 요청을 넘어서, 어떤 구조가 필요한지 정의하고, 그 구조를 기반으로 AI와 함께 결과를 만들어가는 방향으로 점점 발전하게 될 것입니다.
결국 핵심은 하나입니다.
생성형 AI를 단순한 코드 생성 도구로 사용하는 것이 아니라, 설계 단계에서 의사결정을 보조하고 방향을 제시해주는 파트너로 활용하는 것입니다.
이번 글에서 살펴본 내용이, 생성형 AI를 보다 실무적으로 활용하는 데 있어 하나의 출발점이 되기를 바랍니다.
