AWS Summit 2025 2일차
aws summit 2025 seoul 2일차 이야기
1일차 내용에 이어 2일차 내용도 정리해봅니다.
2일자 기조연설에서는 도움이 될만한 많은 정보가 나왔습니다. 그 내용을 정리해보겠습니다.
기조 연설
AWS에서는 말합니다.
모든 인프라나 기술은 단순해야 한다고.. 바로 Simplexity
그리고 이러한 복잡성을 관리하는 원칙을 다음과 같이 소개합니다.
이를 정리해보겠습니다.
Lesson 1: 시스템 진화 가능성을 염두하세요
이 의미는 만들고자 하는 서비스/인프라에 대해서는 처음부터 진화 가능성을 염두에 두고 설계하여 시간이 지남에 따라 시스템이 적응하고 성장할 수 있도록 하는 것이 중요하다는 것을 말합니다. 시간이 지날수록 새로운 기술, 아키텍처, AI 모델, 프레임워크.. SW 기술을 지속적으로 발전합니다. 그렇기 때문에 이러한 변화에 진화할 수 있는 시스템을 만드는것이 중요하다는 것이죠. 아키텍처를 계속 바꿀 수 있는 것은 복잡성을 줄이고, 향후 변경 사항을 쉽게 수용할 수 있습니다.
Lesson 2: 복잡성을 작은 조각으로 나누세요
시스템의 규모가 커지면 커질수록 사람이 감당하기 어려울 정도로 복잡해집니다. 그렇기 때문에 가급적이면 작은 단위로 시스템을 분해를 하여 낮은 결합도/높은 응집도 작은 구성 요소를 구성하는 것이 중요합니다. 바로 API로 유기적으로 연결된 MSA 아키텍처를 적용하라는것이죠. 이렇게 하면 문제 분석 및 해결이 쉬워집니다.
Lesson 3: 아키텍처에 맞게 재구성 하세요
만드는 시스템이 복잡해지고, 거대해질수록.. 이를 운영하는 조직도 그에 맞춰 거대해지고 복잡해집니다. 이렇게 되면 그 조직은 변화를 두려워하게 되고, 안정적인 조직 운영에 초점을 두게 되며 더이상 새로운 도전을 하기 어렵게 됩니다. 그래서 AWS CTO는 가급적이면 소규모 팀을 구성하게 하고 그 팀이 자신들의 문제와 결과를 자신있게 관리할 수 있게 조직을 구성해야 한다고 합니다. 그 팀이 진정으로 제품을 소유하고 있다고 느낄 때, 그들은 결과를 관리할 수 있다는 것을 알고 고객에게 투자했기 때문에 더 나은 결정을 내립니다. 그래야 팀은 빠르고 자유롭게 좋은 의사결정을 하여 지속적인 시스템 발전을 이룰 수 있다고 합니다.
Lesson 4: 셀 단위로 영향 범위를 최소화하세요
셀 기반 아키텍처는 서비스를 격리된 관리 단위로 분리함으로써, 전체 시스템의 복잡성을 효과적으로 줄이는 접근 방식입니다. 이를 통해 확장, 테스트, 배포 과정을 보다 통제 가능하고 예측 가능한 방식으로 운영할 수 있게 됩니다.
이 아키텍처의 핵심은 셀 간의 독립성입니다. 하나의 셀에서 문제가 발생하더라도, 다른 셀에 영향을 주지 않도록 설계되어 있기 때문에 장애의 전파를 최소화할 수 있습니다.
또한 각 셀은 가장 큰 작업 부하를 처리할 수 있을 만큼 충분히 크면서도, 동시에 전체 규모 수준에서 테스트가 가능할 정도로 작아야 합니다. 이 점에서 셀 아키텍처는 단순한 MSA(Microservices Architecture)와는 다릅니다. MSA가 기능 단위로 서비스를 나누는 것이라면, 셀 기반 아키텍처는 시스템 전체를 격리 가능한 블록 단위로 쪼개어 운영의 안정성과 확장성을 극대화하는 전략입니다.
Lesson 5: 예측 가능한 시스템으로 설계하세요
우리는 아키텍처의 불확실성을 줄이기 위해, 시스템을 매우 예측 가능하게 설계해야 합니다. 예측 가능성은 단지 시스템이 잘 동작하는 것뿐 아니라, 항상 같은 방식으로 안정적으로 동작해야 함을 의미합니다. 이를 가능하게 하려면 시스템을 단순하게 유지하는 것이 무엇보다 중요합니다.
하지만 ‘단순함(Simple)’은 그냥 되는 것이 아니라, **엄격한 설계 규율(Discipline)**을 기반으로 합니다. 단순하게 보이는 시스템도 실제로는 잘 정의된 원칙과 패턴 위에 설계되어야만 예측 가능성을 유지할 수 있습니다.
Lesson 6: 가능한 모든 것을 자동화하세요
AWS CTO는 "가능한 모든 것을 자동화하라"고 강조합니다. 시스템이 커지고 복잡해질수록, 사람의 개입을 최소화하는 것이 안정성과 효율성 측면에서 매우 중요해지기 때문입니다. 수동 작업은 실수를 유발할 가능성이 높고, 반복적인 작업은 개발자와 운영자의 집중력을 분산시킵니다. 그런데 여기서 중요한 원칙이 있습니다. "무엇을 자동화하면 안될지 유념하자" 입니다. 모든 업무를 자동화 할 수 없습니다. 이 생각을 안하고 무작정 자동화를 다 시도하면 오히려 더 높은 복잡도, 불필요한 결과를 초래하게 됩니다. 사람의 높은 판단력이 필요한 작업에는 사람이 개입하고, 보안 및 운영 같은 분야를 자동화하면 좋겠죠
그리고 이 발표와 함께 잠시 발표자가 전환이 됩니다.
바로 삼성전자의 발표인데요.
삼성전자 기조연설
삼성전자 MX 사업부는 어제 발표에 이어 오늘도 발표를 하는데, 자신들의 규모를 좀 더 소개를 해줬습니다. 매달 5억명 이상의 사용자가 있으며, 10억개가 넘는 디바이스가 활성화되어 있고, 매일 400억건의 API가 호출된다고 합니다. 엄청난 규모이죠.
이러한 거대함은 많은 비용 문제, 거버넌스 문제를 야기하게 됩니다. 너무나 거대한 시스템은 막대한 비용이 초래되어 이를 줄이는걸 고민할 수 밖에 없게 되었고, 또한 이러한 거대한 시스템을 어떻게 효율적으로 적은 비용으로 자동화할지도 고민 포인트가 되었습니다. 처음엔 이러한 일들이 체계화되어 있지 않아 많은 시행착오가 있었고 그로 인해 큰 비용 문제와 장애 위험도가 항상 뒤따랐습니다.
그래서 삼성전자는 이러한 문제를 해결하기 위해 다음과 같이 목표를 세웁니다.
기술 측면에서 운영의 고도화를 위해 기존의 전통적인 임계 기반의 이상 탐지 기법이 아닌 Dynamic Upper 방식을 도입하였습니다. 선형적인 이상 현상이 아니라 동적으로 임계값을 판단하여 최대/최소 범위내의 이상 현상이 발생되었는지를 판단하는것이죠.
이외에도 다양한 보안 대응 및 취약점 조치 자동화 및 DevOps 파이프라인을 정비하여 기술 측면에서 클라우드 운영 당면 과제 해결을 시도하였습니다.
두번째로는 FinOps 체계의 구축입니다. AWS로부터 컨설팅과 교육을 지속적으로 바로 내부 역량을 강화하였고, 개발팀/운영팀/재무팀/경영진이 하나가 되는 TF가 구성이 되어 어떻게 비용을 가시화할지 전략을 세웠습니다. 그리고 이 전략을 시험한 2개의 파일럿 과제를 선정하여 KPI를 정하고 목표를 수립하였으며 이러한 활동이 어떻게 흘러가는 파악할 수 있는 모니터링 시스템을 만들어 비용 효율화를 달성할 수 있었습니다.
MX 사업부는 이러한 성공을 원동력 삼아 지속적으로 클라우드 운영을 고도화하는 중장기 로드맵을 수립하였으며, 이러한 과정에 AWS와의 지속적인 협업을 계속해나갈것입니다. 또한 Hybrid Cloud를 도입하여 Public 및 Private Cloud를 적절하게 비용 효율적으로 운영을 할 수 있는 플랫폼을 구축할 예정입니다.
결국 이러한 모든 활동은 궁극적으로 사용자들이 안심하고 서비스를 이용할 수 있도록 하는 것이 궁극적인 목표입니다. 더 나은 사용자 경험을 위한 것이죠
이렇게 발표를 마치고 다시 AWS의 광고(?)시간이자 자기 자랑(?) 시간이 진행됩니다. 고객 요구에 충실한 자신들의 강력한 컴퓨팅 환경을 제공할 수 있다고 자랑했으며
자신들이 자체적으로 개발하고 도입한 HW를 통해 고성능/저비용 workload를 달성할 수 있었다고 하며
전세계를 아우르는 다양하고 막강한 데이터베이스 환경을 구축했다고 합니다.
그리고 이러한 막강한 데이터베이스는 단순히 저장소 제공이 아니라 막강한 분석 도구들이 함께 함을 소개합니다.
탐나는 S3 Table...
그리고 이러한 훌륭한 데이터 저장소 및 도구를 기반으로.. 데이터를 AI로 분석할 수 있는 이번 AWS의 핵심 주제중 하나인 SageMaker에 대한 소개를 합니다. SageMaker 도구 하나로 데이터 분석 및 AI 모델 개발, 앱 서비스 개발, 데이터 스트리밍, BI 분석 및 검색등 다양한 활동이 가능하죠
SQL 기반으로 데이터를 쿼리하고.. 분석할 수 있으며
노트북 기반으로 이를 기반으로 한 데이터 엔지니어링이 가능합니다.
그리고 이러한 데이터 분석을 정말 잘하고 활용하는 기업에 대해 소개합니다.
티맵 모빌리티
자신들의 서비스 소개와 아키텍처 소개를 하고
왜 이런 클라우드 도입이 필요했는지를 알려줍니다. 서비스는 성장해야 하는데 마침 IDC 계약이 종료되었고, HW를 또 재투자하고 SW 라이선스 비용을 지불하는게 부담이 있었으며.. 급격하게 변하는 인프라 시장에 유연하게 대응하고자 도입했다고 합니다.
그런데 TMAP은 우리가 알다시피.. 항상 언제나 많은 사람들이 쓰는 서비스이기 때문에 마이그레이션 추진을 신규 서비스 우선 진행하고.. 최대한 무중단 운영을 할 수 있게 차근차근 기존 시스템들을 마이그레이션 합니다. 그러면서 마이그레이션 역량을 점진적으로 강화했죠
그중 티맵이 공을 들인 것은 데이터 마이그레이션입니다. 그들이 다양하게 쓰는 데이터베이스를 안정적으로 AWS 서비스로 대체하는 작업을 해야 했던거죠
또한 이러한 작업을 위해서는 개발 문화도 대대적으로 변해야 했습니다. 개발조직, DevOps 조직, 사업 조직이 한몸 처럼 비용 최적화를 위한 미션을 향해 움직였으며.. 이러한 흐름은 실제적인 인프라 효율로 인해 제어할 인프라를 줄일 수 있었고, 매출 규모와 사용자는 확대할 수 있게 됩니다.
그리고 이러한 성공적인 마이그레이션은 그 다음 단계를 생각할 수 있게 됩니다. 자신들의 막강한 데이터를 기반으로 한 AI 기업인것이죠. 그래서 지금 한창 AI 플랫폼을 진화시키고 있다고 하며 발표를 마칩니다.
이후 다시 AWS의 발표로 전환됩니다. 광고이자 자기 자랑 시간..
AWS Bedrock
어제에 이어 또 소개를 하네요
생성형 AI 어플리케이션의 요구사항이 이런데
AWS의 Bedrock은 이러한 요구사항을 달성할 수 있는 최고의 솔루션이라고 합니다.
사용자의 요구사항에 맞게 다양한 모델을 선택할 수 있는 옵션을 제공하며
사용자들이 원하는 커스터마이징 기능도 제공합니다.
그리고 AI가 만든 결과에 대한 책임 있는 결과를 도와주는 가이드라인을 적용해줄 수 있으며
AI 할루시네이션을 해결하기 위해 내부적으로 자동화된 추론을 적용합니다
또한 계속 화두가 되고 있는 비용 문제를 해결하기 위해 모델의 증류를 지원하며 이런 다양한 증류 모델만 소형/중형/대형 모델등을 적절하게 라우팅하는 체계도 갖추고 있다고 합니다.
그리고 이러한 Bedrock은 이제 Agent를 위한 서비스가 되고자 하는데
이러한 Agent를 위한 자신들의 도구 Amazon Q Developer를 소개하게 됩니다.
Amazon Q Developer는 단순히 AI 코드 생성 도구가 아닌 Agent를기반으로 앱의 현대화를 지원하고, DevOps 전반에 걸쳐 직접적인 관여 및 분석을 가능하게 도와주며, SageMaker와 연계하여 데이터 분석 및 AI 적용에도 도움을 줍니다. 또한 자신들의 AWS 서비스들과 MCP를 기반으로 한 통신을 하여 SDLC 전반에 걸쳐 관여를 할 수 있게 됩니다.
그리고 마지막으로 생성형 AI를 위한 다양한 모델들에 대한 소개가 이뤄지는데
AI 광고 제작 서비스
Pozalabs가 만든 AI 음원 제작 서비스
Supertone에서 만든 실시간 음성 더빙 서비스
Sketch Lab의 이미지 생성 서비스
Sketch Lab의 만화제작 서비스
를 소개하며.. 기조 연설을 마칩니다.
나의 완벽한 개발 비서: Amazon Q와 함께 SDLC 이븐하게 가속하기
이번 Summit에서 제가 가장 마음에 드는 발표중 하나였던 Amazon Q Developer 세션입니다.
AWS 서비스를 많이 접하지 않으면 이게 뭐야? 할 수 있는데.. 아래 프로필을 한번 보세요
Amazon Q Developer는 Cursor랑 다를게 뭐야? 할 수 있지만.. AWS는 그 이상을 보여주기 위해 만든 서비스입니다. 바로 SDLC 전반에 걸친 개입을 위한 도구이죠
이 서비스는 어떤 환경이든 다 접근이 가능합니다. 웹 코솔부터 터미널, IDE 심지어 모바일이나 Slack이나 써드파티인 GitLab에서도 가능하죠
Claude 3.7을 기반으로 추론 능력을 포함하여 강력한 AI 경험을 제공해줍니다. 당연히 Agent 능력을 포함했죠죠
자 그럼 이게 어떤 일을 할 수 있는지 자세히 하나씩 들여다보죠. 여기서는 실제 데모 기반으로 설명을 진행하게 됩니다.
요구사항 정의
사용자가 간단한 요구사항을 전달하면 추론을 통해 요구사항 문서를 AI 직접 자세하게 정의하게 됩니다.
다음 단계를 계속해서 나아가기 위해 이 요구사항을 파일로 기록시킵니다.
단순한 요구사항이 엄청 상세한 요구사항으로 기록되었네요. 여기서 마음에 안드는게 있으면 개발자는 이 문서를 좀 더 수정하고 있으면 되겠죠
설계
요구사항을 만들었으니 이제 설계를 해야겠죠?
텍스트로 설계 문서가 정리됩니다.
근데 다이어그램 없는 설계는 아쉽죠? 이것도 만들어봅시다
plantUML로 다이어그램이 완성되었습니다.
개발
요구사항도 정의했고, 설계도 했으니 이 문서를 기반으로 개발을 해야겠죠
엔티티를 다음과 같이 만들어졌네요
추론 모델 답게 결론도 적당히..
이제 코드 구현 들어갑니다. 정의한 엔티티 대로 파일들을 순식간에 작성했네요
테스트 & 디버깅
코드가 만들어졌으니 이에 대한 테스트 코드도 당연히 작성해야겠죠?
이제 해줘를 남발합니다. 꼼꼼하게 커버리지를 최대한 올릴 수 있게 계속 요청하네요
하지만 이렇게 짠 TC가 한번에 성공할리 없겠죠?
에러 메시지를 전달해서 계속해서 코드 수정 및 TC 수정을 진행합니다. 이걸 반복적으로 하여 완성도를 올리는거죠
빌드 & 배포
코드를 만들었으니 배포를 해야겠죠? 여기서부터는 Cursor도 못하는 행동을 하기 시작합니다. 인프라를 가진 Agent가 얼마나 많은 일을 할 수 있는지 이제 그 활약을 볼 수 있는것이죠
요즘 시대의 기본인 k8s 기반으로 배포를 위해 Dockerfile을 작성시킵니다.
CI 빌드를 하기 위해 GitHub Actions 도 작성 시킵니다.
Terraform으로 CD를 하기 위해 역시 작성 시키죠
우리에게 익숙하지 않은 TerraForm 코드가 척척척
당연히 AWS에 최적화된 코드가 작성된거랍니다.
사실상 GitOps가 벌써 준비된거죠.
문서화
자동화된 빌드&배포를 위한 준비가 모두 끝났으니... 이제 문서화를 해야겠죠?
해줘! (API 문서, 주석, README 생성) LLM이 제일 자신 있는 분야 답게 상세하게 작성을 해줍니다.
운영 & 모니터링
이제 배포도 했고, 문서화도 했으니 운영을 하겠죠?
근데 운영으로 뭘 봐야할지 모르겠다? 물어봅시다
그럼 알려줍니다
오 이제 알겠으니.. 자동화된 운영을 위해 알람좀 해달라고 부탁해봅시다
또 TerraForm 코드를 작성해주네요
근데 운영중에 장애가 발생했다? 질문해서 해결하면 됩니다
운영 조직을 위해 문서가 필요하다? 작성 시킵시시다
아 이제 타이핑하는것도 귀찮다? 말로 시킵시다
사실 이 발표는 실제 데모를 기반으로 하다보니 영상으로 접해야 하는데.. 아쉽게도 사진만 찍었고 모든 순간 촬영은 못했습니다만 이정도만 보시면 무슨 일을 할 수 있는지 감이 잡히실 겁니다
비싸지만 않으면 당장 쓰고 싶네요 ㅠㅠ
원래 글을 시간 흐름대로 쓰긴 했지만.. Amazon Q Developer 설명을 이어서 하기 위해 잠시 건너띄워서 세션을 이어볼까 합니다.
클라우드 전문가가 되는 지름길: Amazon Q Developer와 함께하는 스마트 운영
소개를 다시하는데..
2024년 기점으로 크게 바뀌는 AWS의 AI 코딩 어시스턴트
이전 설명 자료에서처럼 SDLC 전반에 관여하는 도구가 되었으며
이 도구는 이제 단순히 ide에 붙어서 일을 하는 코딩 어시스턴트가 아닙니다 aws에 결합되어 빌드, 운영, 최적화를 모두 도와주는 강력한 도구이죠
aws가 스스로 쌓은 경험 + 수많은 고객들로부터 얻은 경험을 기반으로 학습된 모델이라 사실상 전문가입니다. 이러한 능력은 기존의 LLAMA 같은 오픈소스 모델은 못하는것이죠.
이러한 IaC 누가 해주겠습니까? AWS의 Amazon Q Developer가 잘해주죠. 인프라 운영 경험은 세계 최고 회사이고.. 그러한 문서들을 학습한 모델이니깐요
인프라 뭘 어떻게 구성할지 모른다? 자원 뭘 신청해야 할지 모른다? 물어보면 다 대답해주고 구성도 해줍니다.
간단한 서버리스 서비스를 만들겠다? Web IDE에서 바로 코드 작성시키고 테스트하면 됩니다
AWS 서비스 쓰면서 인프라에서 오류 발생했다? 물어보면 되죠
운영 측면에서도 막강합니다. 내가 관리하는 자원이 너무 많다? 매번 데일리로 모니터링 하기 힘들다? 다 도움 받으면 됩니다.
AWS의 트러블슈팅 에이전트는 본인들의 경험과 고객들의 경험을 기반으로 문제에 대한 솔루션을 Chat 형태로 풀어나갈 수 있습니다.
문제 파악 및 해결 가이드.. 이런거 다 문서화되어 있고, Chat을 통해 가이드 받을 수 있습니다.
또한 내가 생각 못했던 부분도.. 제안을 해줍니다
우리가 이런식으로 일하던 노가다가..
그냥 물어보면 됩니다.
어진간한 운영 이슈는 Runbook을 참고하여 내 인프라를 검사하고, 장애를 진단하면 됩니다
이렇게 Amazon Q Developer는 개발에서뿐만 운영에서도 Agent로 동작을 하여 모든 운영 문제에서 큰 도움을 줍니다. 인프라 장인들이 이루어진 회사 답게.. 자신들의 전문성을 확실히 발휘하네요
그리고 당연히 FinOps도 챙깁니다.
정말 비즈니스를 할줄 아는 회사.. 세계 최고의 클라우드 기업 답게 고객을 가려운 부분을 잘 긁어주네요
오픈소스로 점검하는 AWS 인프라 보안과 멀티 클러스터 접근 제어 사례
AWS 와 같은 인프라를 다룰떄는 보안은 매우 중요합니다. 이걸 신경 안쓰고 살면 우리는 보안 설정 실수로 큰 사고를 발생시키죠. (얼마전 SKT 사태만 보더라도....)
이러한 보안은 개발 시작할때부터 챙겨야.. 나중가서 큰 비용(고통)을 안치루게 됩니다. 처음부터 DevOps 구성시 DevSecOps가 될 수 있게 워크플로 설정 및 인프라 구성이 되야 한다는 것이죠
그러기 위해서는 워크플로에 함께하는 자동화된 진단 도구가 중요합니다. 물론 비싼게 좋은거지만.. 꼭 비싼거 안써도 됩니다. 우리에겐 오픈소스가 있으니깐요
여기서는 이 도구를 소개합니다. Prowler
왠만한 수준의 보안은 다 챙겨주는 멋진 도구랍니다.
AWS 인프라에 대한 점검도 가능할뿐만 아니라 온프레미스 환경도 가능하죠 그리고 CIS, NIST 같은 유명 보안 프레임워크 준수 여부도 점검해줍니다.
사용법도 아주 간단해요!
문서화도 잘되어 있고
강력한 UI도 제공합니다
요즘 대세인 Chat UI도 지원합니다. 보안을 대화식으로 챙겨볼 수 있죠
이 도구는 CI/CD에 결합하기 좋게 만들어져서.. GitHub Actions Workflow에 통합하면 DevSecOps 실천에 매우 큰 도움이 될거랍니다.
그리고 또다른 도구 하나를 더 소개해줍니다. 근데 이건 AWS에서 만든 오픈소스 도구라.. 온프레미스 환경에서는 쓸 수 있을지 모르겠습니다만 일단 소개를 해봅니다
죄송합니다. 제 손꾸락.. 그래도 글자는 안가렸네요 다행히 이 도구는 AWS에 대해 진지하게 검사를 해주며 대시보드 형태로 보고서도 만들어줍니다.
당연히 설치도 쉽습니다
사용법도 간단하죠. (CLI 기반)
수행하면 이렇게 HTML 리포트가 나옵니다
AWS에 특화된 도구 답게 잘 활용하면 아주 강력하겠죠? 리포트도 이렇게 자동생성해주니..
이러한 보안 챙기는 활동은 사실 경영진 입장에서는 "돈을 벌어주는 것"이 아니기 때문에 사고가 발생하기 전까지 대우를 못받는게 현실입니다. 그렇다고 일부러 사고를 낼수도 없으니.. 사고가 안나게 열심히 평소에 챙기기도 하고, 경영진이 중요성을 알 수 있게 보고도 자주 하는게 중요하다고 합니다. (그렇다고 이걸 사람이 매번 하면 경영진이 불필요한 인력 비용이라 생각 할 수 있으니 자동화 적용이 필수)
그리고 발표자는 다음의 원칙을 지키길 권고합니다
- 처리 우선순위를 설정하고, 중요한 문제부터 집중하세요. (사소한 문제는 미뤄도 됨)
- 꼭 처리해야 하는 것과 아닌 것을 구분하세요. (예외처리해도 되는 것들은 잠시 보지 않아도 됨)
- 파이프라인에 꼭 태워야 한다면 별도 파이프라인 분리나 병렬 실행을 고민해보세요. (성능 개선 중요)
- 점검 도구 업데이트를 소홀히 하지 마세요 (최신의 도구는 최신의 점검 항목을 체크합니다)
- 경영진과 주요 의사 결정자들이, 보안에 관심을 가질 수 있도록 결과를 공유하세요. (SKT 사태!!)
그리고 이제 다른 발표자가 보안에 대해 이어서 진행을 합니다
유명한 프랑스 철학가 볼테르의 멘트로 시작하는 발표로
이런 과거의 보안 방식을 소개하며.. (이렇게 하지 말라는겁니다)
요즘의 보안 트렌드인 ZTNA를 소개합니다
이러한 요소를 어떻게 개발자가 다 챙겨? 하겠지만.. AWS에선 당연히 이를 위한 도구가 제공되죠
우린 AWS 안쓰는데? 할 수 있는데.. 그런 사람을 위해 이 번 발표가 준비된거죠. 대안 도구를 소개합니다 바로 Teleport
오픈소스 도구인 이 도구는 Container 환경에 붙어서 클러스터의 리소스 접근 제어를 감시하고, 관리할 수 있습니다.
Teleport의 프록시 서버를 통해 모든 클러스터 통신이 이루어지며 이때 Teleport의 인증으로 접근도 ㅌ오제가 되죠. 또한 모든 자원에는 Teleport Agent가 붙어 활동에 대해 감사 및 모니터링이 가능합니다.
이 도구는 AWS에 붙여서 이렇게도 쓸 수 있죠
실제로 LG U Plus는 보안이 매우 중요한 특정 자원에 대해서는 VPN와 Teleport로 강력한 보안을 적용하였습니다.
이러한 Teleport는 Terraform으로 IaC를 지원합니다
감이 잘 안오시는분들을 위해 데모 소개 들어갑니다
아주아주 보안이 중요한 자원에 접근하기 위해 일단 프록시 서버에 로그인을 합니다
이 사용자가 kube ls 명령어를 쳐봅니다. 이러한 모든 활동이 메신저로 실시간 전달되고 기록되는게 보이죠?
심지어.. 사용자가 무슨 활동을 했는지 화면도 녹화됩니다. 그래서 보안 담당자는 그 상황을 나중에 재생 시킬 수 있습니다.
그러면서 발표자는 Zero Trust 기반 보안 적용이 매우 중요하다고 하며, 여기에 AI 보안을 도입하는것을 서둘러야 한다고 합니다. 이번에 SKT 사태를 보면.. 정말 잘 챙겨야겠죠?
숨고 1,000만 가입자를 이끈 플랫폼의 클라우드 활용 전략 및 혁신 스토리
이번엔 스폰서 세션으로 숨고 자랑을 들으러 가봤습니다.
저도 집 전등 교체할때 불러본적이 있던 숨고..
초반 스타트업시절에 AWS로부터 10만달러의 지원을 받고 인프라를 꾸려서 시작했다고 하네요
성공하는 스타트업 답게 가파르게 성장을 하지만.. 그만큼 AWS 비용도 증가하게 됩니다
그럼 뭘 해야한다? 인프라 개선 및 DevOps 적용 & MSA 적용이죠!
EKS (Kubernetes) 기반으로 ArgoCD 기반의 GitOps를 2020년에 도입하였다고 합니다.
MSA를 왜 도입해야 할까요? 성장하는 SW는 나중에 규모가 커질수록 민첩성이 사라지게 됩니다. 그렇다고 엉덩이 무겁게 발전하지 않으면.. 그냥 정체되고 도태되는겁니다.
특히 서비스를 만드는 경우 이러한 정체와 도태는.. 수많은 경쟁자들한테 밀려 사라지게 되는거죠
그렇다고 무작정 수정하면 오류로 난리날테고.. 그러기 때문에 변화는 빠르게 할 수 있으면서도 문제 파급력이 적은 MSA 아키텍처가 선호되게 됩니다.
또한 이러한 MSA 아키텍처는 자원을 효율적으로 사용할때도 매우 유리하죠
숨고는 2020년에 MSA 전환을 성공적으로 하여 다음과 같은 효과를 얻었다고 합니다
역시 대세는 DevOps, MSA 입니다!!
인터넷 안되는 하이브리드 환경에서 살아남기
두산 에너빌리티와 무신사의 발표가 있었습니다
이번 AWS 보면 IT 기업 말고 다양한 기업이 등장하는데.. "두산 에너빌리티"??
할 수 있지만 ... 요즘 AI 시대에서 어떤 기업이든 IT 를 필요로 합니다.
근데 이 업종 특성상.. 보안이 너무너무너무너무 중요합니다. 발전소가 악성 코드 감염되면 어떠겠습니까.. 끔찍하잖아요?
여긴 그야말로 완전한 여지 없는 망분리 세계입니다.
그러다보니 여기도 클러스터는 딴 세상 이야기 였지만.. 시대가 변했습니다. AI 시대, 데이터 시대가 오니깐.. IT 개발 및 인프라 관리가 너무 힘들어집니다. 언제까지 클래식하게 개발 및 배포를 할 수 없게 된거죠
클래식한 수작업 중심의 개발 문화는.. 사람이 갈려나가고, 기술부채는 심해지며.. 이러한 곳은 사람 채용도쉽지 않습니다..
그래서 이 완벽한 무인도 같은 에어갭 세계도 변화를 시도합니다
그렇다고 AWS 도입하고 클러스터 구축!! 이런 목표는 아니고 좀 더 현실적이고 확실한 목표를 세웁니다
IDP 구축 및 컨테이너로 일하는 문화 도입이죠 (k8s 아닙니다)
클래식 개발 환경에서 갑자기 k8s 도입하면 난리가 나겠죠? 그리고 러닝커브도 심하고.. 그래서 비교적 쉬운 docker 기반을 선택합니다
개발은 그래도 클라우드가 접근 가능한 환경 내에서 Jenkins와 Ansible로 할 수 있게 합니다 (여긴 개발망이라.. 완전히 에어갭이 아니더군요. Gen AI는 여기도 써야 하니..)
그래도 개발은 행복한 환경에서 일을 하네요 IDP 플랫폼을 구성하고..
온라인으로 배포할 수 있는 환경도 구성합니다. (에어갭 환경에서만 일을 하느건 아니니깐)
인프라 CI/CD도 Ansible로 가능하게 구축했고요
Jenkins로 CI/CD를 이렇게 ..
그런데 에어갭 환경은 어떻게 배포할까요?
USB에 담아 딜리버리 서비스... (어쩔 수 없..)
어쨋건 이러한 IDP 구축 및 Docker / Jenkins / Ansible 기반으로 한 개발 환경은 개발자의 인지부하를 줄이고, 좋은 개발 문화를 만드는게 큰 도움이 되었다고 합니다.
무엇보다도 자동화로.. 운영 리소스를 줄일 수 있었다는게 크다고 하네요
그리고 행복한 개발 문화를 위해 Amazon Q Developer를 써서..
Figma로 UI를 그리고 Agent에게 이걸 던져서 프론트엔드 개발을 해서 행복하다고 합니다.
확실히 AI Agent 개발은 생산성 향상에 큰 역할을 하죠
그리고 인프라 자동화를 위한 스크립트도 척척!
여긴 무려 적용 시간이 -90%인 생산성 효과를!!
배포 시간도 획기적으로 줄였습니다
다음은 무신사 발표입니다. 무신사의 경우.. AWS를 잘 쓰고 있습니다만
AI 시대가 오면서 AI 기술을 내재화 하려 했습니다. 근데 AWS의 GPU 비용은.. 도저히 감당하기 어렵다고 판단하여 하이브리드 환경을 꿈 꿉니다.
그와중에 만난 따끈따끈한 EKS의 새로운 서비스가 "EKS Auto Mode & Hybrid Mode"
EKS Outposts와 Anywhere의 중간에 위치 하는 절묘한 모드로 하드웨어는 내꺼 쓰지만 컨트롤 플레인은 EKS를 사용할 수 있는 그런 모드로 GPU 같은 경우 쓰기에 매우 적절한 서비스이죠!! (AWS의 서비스는 이용하되 비용은 최소화!)
쉽게 말해 AWS 네트워크와 VPN으로 연결시켜 AWS의 컨트롤플레인이 On Prem 환경의 노드를 제어하는겁니다.
AWS의 CIDR 만 겹치지 않게 잘 구성하면 된다는것이죠
이 업무를 했던 발표자에 따르면.. 자기가 국내 최초로 시도했던거 같다고 하네요. 그래서 수많은 우여곡절이 있었다고 하는데.. (그부분은 생략하겠습니다 ㅎㅎ 트러블슈팅 가이드 내용들이라.. 사진은 많은데 TMI 같아서..)
어쨋건 이렇게 함으로써 용산에서 구매했던 GPU가 달린 워크스테이션 서버를 Worker Node 로 구성하여.. AWS와 kubernetes 환경을 만들었고..
AI 연구를 적은 비용으로 하면서 AWS의 각종 서비스들을 같이 쓸 수 있어 행복했다고 합니다
그저 Chill한 데브옵스 구축 : 생성형 AI를 통한 차세대 데브옵스 구성하기
드디어 마지막 세션입니다. 사실 저도 이때부터는 힘 빠져서 열심히 못들었.. (사실 내용도 너무 이제 익숙한거라 집중력도 꺠졌네요)
이제는 너무 뻔한 DevOps 이야기..
도입하면 이렇게나 좋습니다.
근데 이거 내가 잘하는지 어떻게 진단하지? 한다면
DORA DORA DORA를 봅시다
여러분은 소프트웨어 배포를 하루에 한번은 하나요? 아니면 한달에 한번 하나요? 그리고 배포했을때 장애 안만날 확률은? 그리고 장애 발생했을때 디버깅하는데 복구하는데 걸리는 시간은?
네? 무서워서 배포를 분기에 한번 한다고요?.. 그럼 DevOps 안하는겁니다.
에이.. 어떻게 하루에 한헌 배포하고 복구를 1시간만에 해?
라고 하신다면.. 자동화가 부족하신겁니다.
심지어 요즘은 AI 시대입니다. DevOps 에 AI Ops가 적용되죠
우린 SW 서비스나 웹서비스가 아니라 어쩔 수 없어.. 라고 하신다면
TSMC의 DevOps 이야기를 한번 찾아보심을 추천드립니다..
(이거 내용 방대해서 나중에 따로 다뤄볼게요)
어쨋건 AI 자동화는 이미 우리에게 친숙합니다
코드리뷰봇이나..
Amazon Q Developer로 운영을 위한 모니터링 제안이나..
장애 리포트를 AI로 생성해서 본다던가..
이전에 발생했던 유사 사고들을 탐색한다던가..(그떄의 조치 히스토리 탐색하기)
그 조치에 대한 내용이 서버리스 함수로 되어 있으면 버튼 클릭으로 장애 해결도 가능해요
해결 가이드도 ai에게 생성 시키고
이 모든 과정은 aws에서 이미 쉽게 할 수 있게 서비스가 제공됩니다
우와 이렇게 많은 서비스들..
이 aws가 제공하는 모든 서비스를 기업 내 직접 내재화 하려면 .. 그거 만드는 조직은 죽어나가겠네요
잘 만들어도.. "어차피 aws만도 못하네? 왜 사서 안써?" 라는 소리를 듣... ㅠㅠ
참 안타까운 현실입니다
이상으로 이번 aws summit 2일차 내용도 정리를 마칩니다...
이정도 되면 내년엔 도대체 무슨 발표가 나올지 기대가 되며............. 또하나의 cloud 장인인 google의 IO도 이러한 Amazon Q Developer 같은 Agent들이 발표된다는데..
참 시대 변화가 무섭습니다..