최근에는 Claude Code나 GitHub Copilot 등 AI 코딩 에이전트를 사용하여 애플리케이션을 쉽게 만들 수 있게 되었습니다.

한편으로는, "AWS 인프라 구축에서도 정말 쓸 수 있을까?"라는 의문이 있었습니다.

그래서 이번에 AWS IoT Core for LoRaWAN을 중심으로 한 IoT 시스템을 Claude Code를 주체로 구축해 보았습니다.

구축한 시스템은 다음과 같습니다.

AWS IoT + Amazon Bedrock을 이용한 스마트 채원 PoC

최종적으로는

• AWS IoT Core
• Lambda
• DynamoDB
• S3
• Amazon Bedrock
• API Gateway
• React Native 앱

까지 한 차례 동작하는 환경을 구축할 수 있었습니다.

이 기사에서는 Claude Code로 AWS 구축을 수행한 실체험을 써보겠습니다.

PoC이므로 복잡한 구성은 아니지만, 실제로 AWS 서비스를 횡단하여 서버리스(Serverless)로 구축하고 있습니다.

이번에 AI로 어디까지 구축할 수 있는지 검증하기 위해, Claude Code로 CDK를 구현하기로 했습니다.

참고로 AWS 공식에서 에이전트용 Toolkit이 공개되어 있지만, 이번에는 사용하지 않았습니다. Claude만으로 어디까지 실현할 수 있는지 시험해보고 싶었기 때문입니다.

Claude Code에 실현하고 싶은 요구사항이나 제약을 전달하고, 대화하며 아키텍처(Architecture)를 검토해 나갑니다.

단, AI가 제안한 설계를 그대로 채택하지는 않았습니다.

예를 들어,

・보안 요구사항을 충족하는가

・장래의 기능 추가를 견딜 수 있는 구성인가

・운영 및 보수가 용이한가

・비용이 타당한가

와 같은 관점에서 인간이 리뷰를 수행하고, 필요에 따라 설계를 수정해 나갑니다.

AI는 설계안을 빠르게 만드는 데는 능숙하지만, 그 설계가 프로젝트의 목적이나 제약에 적합한지를 판단하는 것은 인간의 역할이 됩니다.

• AWS CLI 설치
• AWS Configure로 인증 정보를 로컬에 설정
• 프로젝트 폴더 준비
• .CLAUDE.md에 규칙 및 금지 사항, 디렉터리 구성 기재
• 요구사항.md에 시스템에서 실현하고 싶은 내용을 불렛 포인트로 기재
• 요구사항.md를 INPUT으로 하여 Claude에게 시스템 구성안을 도출하게 함
• 자신의 예상과 대체로 일치할 때까지 대화를 반복하여 구성을 정리
• 구성안이 완성되면 Claude에게 설계를 시킴
• 각 서비스의 설계서 md를 리뷰 → 지적 및 수정 반복
• 각 서비스의 설계서.md를 INPUT으로 하여 Claude에게 CDK 구현을 지시
• cdk 빌드가 통과할 때까지 수정을 반복하고 배포를 실행
• 배포에 실패하면 에러를 조사하게 하여 설계서와 CDK를 수정하게 함 (9번으로 돌아감)
• 배포가 성공하면 앱과 세트로 동작 확인을 수행

과 같은 흐름으로 Claude와의 개발을 바이브 코딩(Vibe Coding) 형식으로 진행했습니다.

이렇게 보고 있으면 사람과 함께 일하는 것과 다를 바 없네요.

참고로, 대규모 시스템의 애플리케이션 개발 현장에서는 팀 단위로 개발을 수행하기 때문에, 멀티 에이전트 설계나 컨텍스트 엔지니어링(Context Engineering), 하네스 엔지니어링(Harness Engineering)과 같은 기법을 구사하여 누구나 동일하게 안정적인 출력을 얻을 수 있는 메커니즘 구축이 요구됩니다.

이번에는 취미 범위이며 혼자서 개발을 진행하고 있기 때문에, 간편한 바이브 코딩 형식을 채택하고 있습니다. 최적의 기법으로 권장하는 것은 아니라는 점, 미리 양해 부탁드립니다.

대량의 Markdown 설계서를 리뷰하는 것은 고된 일이지만, 그림이나 표로 기재해 주기 때문에 이해하기 쉬워 리뷰가 원활하게 진행되었습니다.

스택을 어떻게 분할할지는 항상 고민되지만, Claude가 제안하는 스택은 이상적이라고 느꼈습니다.

AWS 서비스 간의 접속 설계가 거의 완벽하다는 점입니다.

예를 들어, 권한인 IAM과 서비스 간의 파라미터 정의입니다.

AWS 구축 경험이 풍부한 사람이라 할지라도, 최적의 IAM 권한 정의와 서비스 간의 정합성 고려는 꽤 고생스러운 작업입니다.

이것을 해주는 것은 정말 큰 도움이 되었습니다.

한편으로, 여러 가지 실현 방법이 있는 경우 "어느 것을 선택해야 하는가"라는 설계 판단은 프로젝트에 따라 달라집니다.

AI는 후보를 제시하는 데는 능숙하지만, 최종적인 선택에는 경험과 운용을 바탕으로 한 판단이 필요했습니다.

당연한 이야기지만, 한 번에 100% 성공하는 일은 없습니다.

예를 들어, 막상 실행해 보니 IAM 정책 부족으로 에러가 발생하는 등의 일은 적지 않게 있었습니다.

다만, 에러 발생 이후의 시행착오 (Try & Error) 과정 또한 인간보다 훨씬 빠르게 실행할 수 있기 때문에, 해결에 도달하는 속도도 빠릅니다.

개인적으로는 에러 분석 (Error Analysis) 기능이 최고였습니다.

AWS의 에러는 단서가 적어 다양한 로그를 헤매야 하며, 원인 분석에는 항상 어려움이 있었습니다.

하지만 AI의 상황 분석 및 추론 능력은 매우 뛰어나서, 원인 특정은 저보다 훨씬 빠릅니다.

결과나 해설을 보고 "과연 그렇구나"라며 공부하게 되는 장면도 많습니다.

AI가 정답을 내놓는다기보다, "원인 조사를 대폭 가속화해 준다"는 감각입니다.

최종적인 판단은 인간이 내리지만, 조사 시간은 체감상 몇 분의 일로 줄어들었다고 생각합니다.

AI는 매우 우수한 구현자 (Implementer)입니다.

하지만 시스템 개발에서 정말 어려운 것은 "무엇을 만들 것인가", "어떻게 구현할 것인가"를 결정하는 것입니다.

예를 들어,

・ 업무 요구사항 (Business Requirements), 비기능 요구사항 (Non-functional Requirements) 정리

・ 보안 및 거버넌스 (Governance)

・ 운영 설계 (Operational Design)

・ 장애 시 복구 방법

・ 비용과 성능의 균형

・ 향후 확장성

이러한 것들은 프로젝트 전체를 이해한 상태에서 의사결정을 내려야 합니다.

AI는 선택지를 제시할 수는 있지만, 최종적인 의사결정과 책임을 질 수는 없습니다.

그렇기에 AI 시대의 SIer에게는 『구현하는 회사』가 아니라, 『AI를 활용하여 최적의 시스템을 설계하고 실현하는 회사』로서의 역할이 요구된다고 느꼈습니다.

이번 PoC(Proof of Concept)에서는 Claude Code를 활용함으로써 AWS 인프라 구축 속도가 대폭 향상되었습니다.

한편, AI가 잘하는 것은 "구현을 가속화하는 것"이지, "시스템으로서 성공할지 여부"를 판단하는 것이 아닙니다.

요구사항을 정리하고, 적절한 아키텍처 (Architecture)를 선택하며, 품질·보안·운영까지 포함하여 설계하는 것은 여전히 인간의 중요한 역할입니다.

앞으로는 『AI냐 인간이냐』가 아니라, 『AI를 전제로 하여, 더욱 고품질의 시스템을 단기간에 제공할 수 있는가』가 SIer의 경쟁력이 될 것이라고 느꼈습니다.

AI는 SIer의 일자리를 빼앗는 존재가 아니라, 엔지니어가 더욱 본질적인 설계나 고객 가치 창출에 집중할 수 있도록 돕는 강력한 파트너라고 생각합니다.

※ 본 기사의 내용은 개인적인 견해이며, 소속 조직의 공식 견해가 아닙니다.