AI 클라우드 아키텍트: 멀티 클라우드 설계, 검토 및 FinOps


2026-09-09


AI 클라우드 아키텍트: 멀티 클라우드 설계, 검토 및 FinOps

Cloud Architect라고 표시된 일러스트 등각 투영 클라우드 아키텍처 지도. 멀티 리전 데이터 센터, 서비스 육각형, 네트워크 경로, 청사진 오버레이를 보여 줍니다

클라우드 아키텍트는 기능 목록이 아니라 트레이드오프를 기준으로 사고하여 AWS, Azure, Google Cloud의 프로덕션 클라우드 시스템을 설계하고 검토하며 최적화하도록 도와줍니다. 팀이 서비스 카탈로그, 예상 밖의 청구서, 화이트보드에서는 우아해 보였지만 실제 운영은 어려운 아키텍처에 파묻혀 있을 때, 이 AI는 팀, 규정 준수 수준, 예산에 맞춰 랜딩 존, Well-Architected 검토, 마이그레이션 순서, FinOps 가이드를 제시하는 수석 아키텍트 수준의 판단을 제공합니다.

✅ AWS, Azure, GCP 전반의 멀티 클라우드 설계와 안정성, 보안, 비용, 복잡성 간의 명시적인 트레이드오프 ✅ 블라스트 반경에 따라 결과의 우선순위를 정하고 모든 위험에 해결책을 연결하는 Well-Architected 검토 ✅ 데이터베이스와 공유 서비스가 전환 과정에서 예상 밖의 장애물이 되지 않도록 순서를 정한 7 Rs 기반 마이그레이션 및 현대화 계획 ✅ 슬라이드 자료가 아닌 구체적인 IaC, 네트워킹, IAM, CI/CD 패턴

이러한 판단이 중요한 이유를 이해하려면 클라우드 프로그램이 실제로 어디에서 멈추는지 살펴보는 것이 좋습니다. 아무도 귀속하지 못하는 지출, 출시 이후에 덧붙인 보안, 그리고 이를 운영해야 하는 팀의 역량을 앞질러 버린 아키텍처가 대표적입니다.

빠른 답변: 클라우드 아키텍트란 무엇인가요?

클라우드 아키텍트는 안정성, 보안, 비용, 운영의 균형을 유지하면서 AWS, Azure, GCP 시스템을 설계하고 검토하며 최적화하는 수석 아키텍트 수준의 AI입니다. 대화의 목적에 따라 설계자, 검토자, 마이그레이션 전략가, 구현 자문가의 역할을 오갑니다.

주요 기능:

  • 요구사항에서 시작하는 그린필드 아키텍처: 컴퓨팅, 데이터, 네트워킹, IAM, 장애 도메인
  • 운영 우수성, 보안, 안정성, 성능, 비용, 지속 가능성 전반에 걸친 Well-Architected 검토
  • 클라우드 마이그레이션 및 현대화 계획(리호스트, 리플랫폼, 리팩터링 및 나머지 7 Rs)
  • FinOps 가이드: 적정 규모 조정, 요금 모델, 데이터 전송 함정, 태깅, 단위 경제성
  • Terraform, Kubernetes, 서버리스, CI/CD, 옵저버빌리티를 위한 구현 패턴

클라우드 팀이 계속 비용을 치르는 문제

클라우드는 더 이상 부수적인 프로젝트가 아닙니다. 2025년 전 세계 클라우드 지출은 7,230억 달러에 이를 것으로 전망되었습니다. 하지만 대부분의 조직은 여전히 그 지출을 특정 리소스와 의사결정에 연결하려고 애쓰고 있습니다. Cost Explorer, 청구 내보내기, 수십 개의 계정 콘솔에 데이터는 존재하지만 곳곳에 흩어져 있습니다. 한편, 조직의 84%가 클라우드 지출 관리를 가장 큰 과제로 꼽습니다.

84% — 클라우드 지출 관리를 가장 큰 과제로 꼽는 조직의 비율

비용은 여러 장애 요인 중 하나일 뿐입니다. 리전, SaaS 종속성 또는 잘못 구성된 ID 경로가 중단되면 청구서는 재정적인 문제인 동시에 운영상의 문제가 됩니다.

하루 405,770달러 — 보고된 평균 다운타임 비용. 5일간의 복구 기간에는 약 230만 달러까지 증가

보안과 규정 준수도 이 문제와 분리되어 있지 않습니다. 클라우드 제공업체는 공동 책임 모델과 규정 준수 증명을 공개합니다. 예를 들어 AWS는 NHS Data Security and Protection Toolkit과 같은 평가를 완료합니다. 그러나 ID, 네트워크 세분화, 암호화, 로깅은 여전히 고객이 해결해야 할 아키텍처 문제입니다. 나중에 덧붙인 통제는 우회됩니다. 구조적인 통제는 그렇지 않습니다.

하지만 작동하는 데모에서 운영 가능한 프로덕션 시스템으로 나아가는 일은 여전히 답답할 만큼 어렵습니다.

  • 우연히 조직 구조를 그대로 닮은 아키텍처. Conway의 법칙은 선택 사항이 아닙니다. 불명확한 팀 경계는 불명확한 서비스 경계가 되고, 결국 불명확한 블라스트 반경으로 이어집니다.
  • 무시된 데이터 중력. 컴퓨팅은 쉽게 이동할 수 있지만 데이터는 그렇지 않습니다. AZ 간 및 리전 간 트래픽, 이중 쓰기, 그리고 "임시" 복제 작업이 조용히 비용 항목이 됩니다.
  • 1일 차 비용을 초과하는 2일 차 비용. 우아한 다이어그램은 출시됩니다. 하지만 온콜, 드리프트, 스노플레이크 환경, 유휴 개발 스택은 계속 비용을 발생시킵니다.
  • 몇 주씩 걸리는 검토. 계정별로 증거를 수집해야 하는 철저한 AWS Well-Architected Framework 검토는 여전히 많은 노동이 필요합니다. 일부 컨설팅 업체는 자동화 이전에 50시간이 걸리는 작업을 보고하기도 합니다.

2025년의 엔터프라이즈 마이그레이션 프로그램에서는 같은 패턴이 반복됩니다. 모든 것을 리프트 앤 시프트하고, 랜딩 존 설계를 건너뛰며, 데이터베이스, ID, 네트워킹이 실제 핵심 경로였다는 사실을 나중에 발견하는 것입니다. 하이브리드 및 멀티 클라우드 도입은 유연성과 두 번째 컨트롤 플레인을 추가하지만 운영 가능성을 자동으로 높여 주지는 않습니다.

클라우드 아키텍트는 바로 이러한 문제를 해결하기 위해 만들어졌습니다.

클라우드 아키텍트를 선택해야 하는 이유

클라우드 아키텍트는 아키텍처를 명시적인 선택의 집합으로 다룹니다. 어떤 축(안정성, 비용, 보안, 속도, 단순성)을 우선하는지, 무엇을 포기하는지, 그리고 팀이 결과물을 실제로 운영할 수 있는지를 따집니다. 서비스 카탈로그를 그대로 나열하지 않습니다. 목표, 규모, 팀의 성숙도, 규정 준수, 예산, 현재의 문제를 확인한 다음 하나의 방향을 추천하고 대안이 적용되는 시점을 설명합니다.

이는 클라우드 제공업체가 동일한 6가지 핵심 원칙에 따라 Well-Architected 가이드를 제공하기 때문입니다. 핵심 원칙은 운영 우수성, 보안, 안정성, 성능 효율성, 비용 최적화, 지속 가능성입니다. 그러나 이 원칙을 여러분의 워크로드에 적용하려면 프레임워크만으로는 제공할 수 없는 맥락이 여전히 필요합니다. 세 명으로 구성된 스타트업과 50개 계정을 운영하는 플랫폼 팀에 동일한 Kubernetes 권장 사항을 제시해서는 안 됩니다.

기존 접근 방식클라우드 아키텍트
첫 번째 장애가 발생하면 낡아 버리는 화이트보드 세션과 슬라이드 자료제약 조건, 결정 사항, 미해결 질문을 기억하는 지속적인 설계 대화
팀 규모와 온콜 역량을 무시하는 일반적인 "모범 사례"화요일 새벽 2시에 누가 시스템을 운영할지를 고려한 권장 사항
Well-Architected 검토를 위해 몇 주 동안 콘솔을 오가는 작업범위 설정, 평가, 블라스트 반경 × 가능성에 따른 우선순위 지정, 해결로 이어지는 구조화된 검토
청구서에서 시작하는 비용 검토아키텍처 수준의 FinOps: 과도한 프로비저닝, 유휴 환경, 데이터 전송, 스토리지 수명 주기, 요금 모델
모든 워크로드를 리호스트로 처리하는 마이그레이션 계획워크로드별 7 Rs 순서 설정, 데이터베이스에 추가 시간을 배정하고 모든 전환에 롤백 계획 수립

블라스트 반경과 데이터에서 시작하는 설계

AI는 먼저 장애 도메인을 기준으로 사고합니다. 프로덕션 환경에서는 멀티 AZ가 기본이며, 멀티 리전은 대부분의 팀이 과소평가하는 비용 및 복잡성에 관한 결정입니다. 타당한 이유가 없다면 관리형 서비스가 직접 호스팅하는 차별화되지 않은 작업보다 우선합니다. 지연 시간, 일관성, 전송 비용이 숨어 있는 곳이 바로 데이터이므로 데이터 아키텍처가 컴퓨팅보다 먼저입니다.

결과를 보여 주는 것이 아니라 해결책을 만드는 검토

검토는 워크로드와 중요한 핵심 원칙을 기준으로 범위를 정한 뒤 우선순위를 지정합니다. 중요(지금 수정) 항목을 주요(계획 수립) 항목 및 있으면 좋은 항목과 분리합니다. 모든 결과에는 무엇이 잘못되었는지, 왜 중요한지, 무엇을 해야 하는지, 대략 어느 정도의 노력이 필요한지를 명시합니다. 이는 진지한 Well-Architected 검토에 필요한 것과 동일한 원칙이지만 컨설팅 일정을 기다릴 필요가 없습니다.

동화 같은 이야기가 아닌 마이그레이션

리호스트는 전략이 아니라 전술입니다. 가치가 높은 워크로드는 리플랫폼하거나 리팩터링하고, 가치가 낮은 워크로드는 폐기하거나 유지합니다. 공유 서비스가 종속 서비스보다 먼저 이동합니다. 롤백할 수 없다면 전환할 준비가 된 것이 아닙니다.

의견이 아닌 구현

구축할 준비가 되면 Terraform, Bicep, Pulumi 또는 CloudFormation 스케치, IAM 구조, 네트워크 레이아웃, CI/CD 프로모션 패턴을 얻을 수 있습니다. 핵심은 운영 가능성입니다. 원격 상태, 작은 상태 파일, 환경 간 동등성, 롤백 요구사항에 맞는 파이프라인이 포함됩니다.

"피크 시 약 200 req/sec를 처리하는 PCI 범위 결제 API를 AWS에서 설계해 주세요. 6명으로 구성된 팀이며 AWS 경험은 보통 수준이고 월 목표 비용은 12,000달러입니다. 아직 프로덕션에서 Kubernetes를 운영하고 싶지는 않습니다."

작동 방식

완벽한 브리핑은 필요하지 않습니다. 실제 제약 조건이 필요합니다. AI 아키텍트는 탐색을 우선하는 순환 과정을 실행하고, 사용자가 확인한 경우에만 결정을 확정합니다.

1단계: 도구가 아니라 업무를 설명하세요 새로운 설계, 검토, 마이그레이션 계획 또는 특정 장애에 대한 도움이 필요한지 말해 주세요. 업종, 규모(사용자, 요청, 데이터 용량), 팀 규모와 클라우드 성숙도, 제공업체 약정, 가용성 목표, 규정 준수, 예산이 있다면 함께 포함하세요.

"Azure에서 B2B SaaS를 운영하고 있습니다. 엔지니어 8명, 한 리전의 App Service + SQL Database, SOC 2 진행 중입니다. 지연 시간은 괜찮지만 두 분기 동안 청구서가 40% 증가했고 아무도 이유를 설명하지 못합니다."

2단계: 트레이드오프가 명시된 권장 사항을 받으세요 계정/프로젝트 전략, 네트워크 토폴로지, 컴퓨팅 및 데이터 저장소, ID 경계, DR 패턴, 비용 동인을 포함한 제안된 구조와 함께 무엇을 하지 않는지, 그 이유가 무엇인지 전달받습니다. 두 가지 접근 방식이 모두 유효하다면 하나를 추천하고 대안이 적용되는 상황을 구체적으로 설명합니다.

3단계: 설계를 압박 테스트하세요 설계에 도전해 보세요. 기본 데이터베이스가 장애를 일으키면 어떻게 되는지, 배포가 잘못되면 어떻게 되는지, 계약자가 권한이 부여된 자격 증명을 가지고 떠나면 어떻게 되는지 물어보세요. 종속성과 관리형 서비스의 가치, 모놀리스와 서비스의 선택, 멀티 리전이 실제로 정당화되는지를 깊이 검토하세요.

"기본 AZ가 4시간 동안 사라진다고 가정하세요. 체크아웃의 장애 모드를 단계별로 설명하고, 이 DR 구성이 파일럿 라이트 리전과 비교해 비용이 얼마나 드는지 알려 주세요."

4단계: 결정을 배포 가능한 산출물로 전환하세요 ADR, 컴포넌트 목록, IaC 모듈, 태깅 표준, SLO 제안 또는 단계별 마이그레이션 순서를 요청하세요. 요구사항이 변경되면 계속 반복해서 개선할 수 있습니다. 지속적인 메모리 덕분에 매 세션마다 랜딩 존을 다시 설명할 필요가 없습니다.

설계에서 프로덕션 서비스가 필요할 때는 실제로 배포하는 언어로 구현을 이어 갈 수 있습니다. 모놀리스에서 Go 서비스를 추출한다면 Go 코딩 어시스턴트가 합의된 경계를 바탕으로 관용적이고 동시성에 안전한 코드를 생성하여 아키텍처가 다이어그램으로만 남지 않도록 도와줍니다.

클라우드 아키텍트를 무료로 사용해 보세요 — 신용카드가 필요하지 않습니다.

결과 및 활용 사례

🏗️ 방어 가능한 예산으로 구축하는 그린필드 SaaS

상황: 10명으로 구성된 제품 팀에 멀티 테넌트 API, 백그라운드 워커, 관계형 데이터, 객체 스토리지, 인증이 필요합니다. 투자자는 클라우드 전략을 원하지만 엔지니어링 팀은 12명으로 구성된 플랫폼 팀을 만들고 싶어 하지 않습니다.

기존 접근 방식: 2주 동안 비교 조사를 진행하고, "확장성"을 이유로 Kubernetes 클러스터를 도입한 뒤, 유휴 노드, 아무도 모델링하지 않은 NAT 게이트웨이, 아직 도달하지 않은 미래를 위해 크기를 정한 데이터베이스가 포함된 청구서를 받습니다.

클라우드 아키텍트: 단일 리전 멀티 AZ 데이터 플레인, 명확한 블라스트 반경, 1,000배가 아닌 10배까지 확장할 수 있는 경로를 포함하는 관리형 컨테이너 또는 서버리스 우선 설계를 제시합니다. 계정 전략, 태깅, 예산 알림을 첫날부터 포함합니다. 이는 FinOps 프로그램이 아키텍처가 아닌 청구서에서 시작할 때 흔히 실패하는 지점입니다.

  • 워크로드 유형에 맞춰 컴퓨팅을 선택합니다(상태 비저장 API vs. 배치 vs. 상태 저장)
  • 온콜 부담이 되기 전에 시기상조인 마이크로서비스를 지적합니다
  • 비용을 분기별 깜짝 결과가 아니라 설계 입력값으로 만듭니다

🔍 복잡하게 확장된 AWS 환경의 Well-Architected 검토

상황: 15개의 계정, Terraform과 콘솔 작업이 혼재된 환경, "스테이징에만 필요하다"며 공개된 RDS 스냅샷, 한 AZ에 배치된 프로덕션 Redis를 인수했습니다. 경영진은 다음 SOC 2 기간 전에 검토를 원합니다.

기존 접근 방식: 컨설턴트는 분석을 시작하기 전에 50시간짜리 Well-Architected 작업의 대부분을 증거 수집에 사용합니다. 내부 팀은 CIS 통제를 수작업으로 확인하지만 계정 간 신뢰 관계는 여전히 놓칩니다.

이 AI 아키텍트: 워크로드의 범위를 정하고 6가지 핵심 원칙을 검토한 뒤 ID, 암호화, 백업/복구, 연결 풀링, 데이터 전송 경로에 대한 결과를 우선순위별로 반환하며 해결책과 노력을 함께 제시합니다. 성숙한 FinOps 역량에 도달한 조직은 14.2%에 불과합니다. 리소스 수준의 비용을 볼 수 없는 검토로는 이러한 격차를 해소할 수 없습니다.

  • 중요한 잘못된 구성과 아키텍처 부채를 구분합니다
  • 일반적인 체크리스트가 아니라 블라스트 반경에 보안 격차를 연결합니다
  • 로드맵에 추가할 수 있는 순서를 만듭니다

사고 경로, IAM 악용 사례 또는 탐지 격차에 대한 위협 기반 분석도 필요하다면 사이버 보안 분석가가 동일한 검토를 위협 모델링, 탐지 엔지니어링, 규정 준수 증거로 확장하여 아키텍처를 다시 설명할 필요가 없도록 도와줍니다.

🚚 빅뱅 주말 작업 없이 데이터 센터에서 마이그레이션하기

상황: 중견 기업이 오래된 VMware 환경에서 벗어나고 싶어 합니다. 핵심 자산은 문서화가 부족한 저장 프로시저가 포함된 2TB SQL Server 환경입니다. 경영진은 컨퍼런스에서 "리프트 앤 시프트"라는 말을 들었습니다.

기존 접근 방식: 모든 것을 리호스트하고, 전환 중 데이터베이스가 핵심 경로라는 사실을 발견하며, DNS TTL과 이중 쓰기 지연이 런북에 포함되지 않았다는 것을 알게 됩니다.

클라우드 아키텍트: 워크로드별로 7 Rs를 적용합니다. 종속성이 낮은 앱을 먼저 이동하여 도구에 대한 신뢰를 쌓습니다. 공유 ID와 네트워킹을 종속 서비스보다 먼저 배치합니다. 데이터베이스에는 추가 시간, 동기화 전략, 명시적인 롤백 계획을 적용합니다. 클라우드 비용 최적화 작업은 대상 설계에서 시작됩니다. 적정 규모 조정, 스토리지 클래스, 예약형과 온디맨드 비교를 적용하여 온프레미스의 낭비를 더 비싼 환경에서 반복하지 않도록 합니다.

스키마, 인덱싱, 쿼리 계획이 마이그레이션의 병목이 되면 SQL 코딩 어시스턴트가 합의된 데이터 아키텍처를 바탕으로 이식 가능하고 엔진을 고려한 SQL로 전환하여 데이터베이스를 앱 계층 뒤의 블랙박스로 취급하지 않도록 도와줍니다.

  • "데이터 센터로서의 클라우드" 안티패턴을 피합니다
  • 영웅적인 주말 작업이 아니라 위험에 따라 순서를 정합니다
  • 팀의 역량과 비용에 비추어 RTO/RPO를 현실적으로 유지합니다

📱 휴대폰으로 확인하는 온콜 아키텍처

상황: 기차 안에서 프로덕션 지연 시간이 증가하고 있으며, 가지고 있는 유일한 자료는 흐릿한 화이트보드 사진과 "Redis 문제"에 관한 Slack 스레드뿐입니다.

기존 접근 방식: VPN으로 세 개의 콘솔에 접속하고, 어떤 서비스가 경로에 있는지 추측하며, 런북이 최신 상태이기를 기대합니다.

클라우드 아키텍트: 다이어그램을 업로드하고 증상과 SLO를 설명하면 잠재적인 병목, 먼저 확인할 항목, 아키텍처 자체(단일 AZ 캐시, 백프레셔 없음, 잦은 AZ 간 호출)가 장애인지 여부를 보여 주는 장애 모드 안내를 받을 수 있습니다. 웹, iOS, Android에서 모든 기능을 동일하게 사용할 수 있으므로 데스크톱과 모바일에서 동일한 지속적 맥락을 이용할 수 있습니다.

  • 사진, 대략적인 다이어그램, 일부 구성 파일로도 작업합니다
  • 원시 CPU 사용량보다 사용자에게 보이는 증상을 우선합니다
  • 장애가 설계 변경으로 이어지도록 후속 ADR을 남깁니다

FAQ

클라우드 아키텍트는 어떤 용도로 사용하나요?

클라우드 아키텍트는 새로운 클라우드 시스템을 설계하고, Well-Architected 원칙에 따라 기존 시스템을 검토하며, 마이그레이션을 계획하고, IaC, 네트워킹, IAM, CI/CD에 대해 조언하는 데 사용됩니다. 일반적인 작업에는 랜딩 존 전략, 컴퓨팅 및 데이터 저장소 선택, DR 패턴, FinOps, AWS, Azure, GCP 전반의 보안 아키텍처가 포함됩니다. 이는 실제 제약 조건을 위한 아키텍처 가이드이며, 규제 기관에서 여전히 요구할 수 있는 인증 감사를 대체하지 않습니다.

클라우드 아키텍트는 무료인가요?

예. 무료 플랜에는 제한된 월간 사용량과 함께 핵심 기능이 포함되어 있어 설계 세션이나 집중적인 검토를 진행하기에 충분합니다. 유료 요금제에서는 사용량이 늘어나고 사용자 지정 모델 선택과 같은 옵션이 추가됩니다. 사용량은 청구일에 초기화되며 일일 한도는 없습니다. 동일한 에이전트를 웹, iOS, Android에서 사용할 수 있습니다.

AI 클라우드 아키텍트는 일반 챗봇과 어떻게 다른가요?

일반 챗봇은 서비스를 나열합니다. 이 제품은 그런 습관을 거부하도록 설계되었습니다. 팀의 역량을 확인하고, 트레이드오프를 명시하며, 일정과 역량이 뒷받침하지 못한다면 프로덕션에서 Kubernetes를 운영하지 말라고 말합니다. 여러 제공업체에 걸쳐 통합된 Well-Architected 사고를 적용하고, 세션 간 결정 사항과 미해결 질문을 추적하며, 일반적인 참조 아키텍처가 아니라 여러분의 워크로드를 바탕으로 ADR, IaC 스케치, 마이그레이션 순서를 생성할 수 있습니다.

클라우드 아키텍트는 AWS, Azure, Google Cloud 전반에서 작동하나요?

예. 설계와 검토는 AWS, Azure, GCP를 아우르며, 데이터 주권, M&A, 워크로드 수준에서의 진정한 최적 조합과 같이 실제 동인이 있을 때만 하이브리드 및 멀티 클라우드를 포함합니다. 주요 목표로서의 "종속성 회피"는 비용으로 간주합니다. 이식성 계층이 클라우드로 이전한 이유였던 관리형 서비스를 차단하는 경우가 많기 때문입니다.

클라우드 아키텍트는 모바일에서 작동하나요?

예. iOS 또는 Android에서 웹 앱과 동일한 대화 메모리를 사용하여 아키텍처 검토를 실행하고, 구성 파일을 붙여 넣고, 화이트보드 사진을 업로드할 수 있습니다. 이것이 장애 중에도 사용할 수 있는 아키텍처 파트너와 책상에서만 작동하는 도구의 차이입니다.

클라우드 아키텍트는 프로덕션 의사결정에 사용할 만큼 정확한가요?

패턴, 안티패턴, 트레이드오프 추론에 강하며, 구체적인 사항이 중요할 때는 이를 지어내지 않고 현재 서비스 제한, 가격, 리전별 가용성을 조사합니다. 결과물은 팀과 함께 검토해야 하는 수석 아키텍트 수준의 가이드로 활용하세요. PCI-DSS, HIPAA, FedRAMP, GDPR과 같은 규정 준수 체계에는 여전히 자체 증거가 필요하며, 법적으로 자격을 갖춘 평가가 필요한 경우 이를 대체하지 않습니다.

결론

클라우드 아키텍처는 예측 가능한 방식으로 실패합니다. 아무도 책임지지 않는 지출, 다이어그램 이후에 추가되는 보안, 데이터베이스를 사후 고려 사항으로 취급하는 마이그레이션, 온콜 팀이 운영할 수 없는 설계가 대표적입니다. 클라우드 아키텍트는 AWS, Azure, GCP 전반에서 수석 아키텍트 수준의 설계, Well-Architected 검토, FinOps, 마이그레이션 전략을 제공하고 트레이드오프를 공개적으로 명시하여 이러한 격차를 해소합니다.

랜딩 존, 감사 전 검토 또는 비용 회의에서 방어할 수 있는 마이그레이션 순서가 필요하다면 실제로 가지고 있는 제약 조건을 제시하고 설계 세션을 시작하세요. Jenova에서 더 자세히 알아보세요.

개발자를 위한 안내: 클라우드 아키텍트는 Jenova API를 통해 프로그래밍 방식으로 사용할 수 있습니다 — 단일 API 호출로 수석 아키텍트 수준의 클라우드 아키텍처 설계, 검토, 마이그레이션 계획을 애플리케이션에 통합하세요. 전체 문서 →