기조연설: Simplexity 원칙
아래는 AWS Summit Seoul 2025에서 아마존 CTO Dr. Werner Vogels의 기조연설 “Simplexity”에서 발표된 여섯 가지 핵심 원칙입니다. 이 개념은 “단순함(Simplicity)”과 “복잡성(Complexity)”의 조화를 통해, 복잡한 시스템과 조직을 효과적으로 관리하자는 메시지를 담고 있습니다.
1. Evolvability를 요구사항으로 두기
- 시스템은 시간이 지남에 따라 성장하고 변화합니다.
- S3를 설계할 때 “1년 후 아키텍처가 달라질 것”을 염두에 두고 구축했으며,
- 유지보수 중심의 단기 관점이 아니라 장기적 관점에서 변화에 대응 가능한 설계가 중요합니다.
2. 복잡성을 조각내기 (Break complexity into pieces)
- 예를 들어 CloudWatch는 반복적으로 내부 구조를 분해·재구성하며 확장성을 유지했듯,
- 낮은 결합도와 높은 응집력, 그리고 잘 정의된 API를 가진 모듈형 구조가 핵심입니다.
3. 조직 구조는 아키텍처를 따라 정렬하라
- 소프트웨어 아키텍처의 복잡성이 곧 조직 구조의 복잡성으로 이어집니다.
- 팀 단위의 소유권(ownership)과 구조적 도전 정신이 필요하며,
- 조직 운영 역시 시스템처럼 수시로 점검하고 개선해야 합니다.
4. Cell 기반 구조로 나누기
- 서비스나 조직을 작업 단위(cell)로 분리하면,
- 인접한 영역의 문제 확산을 방지할 수 있으며,
- 각 cell이 독립적으로 확장 및 테스트될 수 있어 신뢰성과 보안을 동시에 보장합니다.
5. 예측 가능한 시스템 설계
- 이벤트 중심(event-driven) 아키텍처처럼, 반응 흐름을 명확히 정의하면
- 시스템 동작이 예측 가능해지고, 불확실성에 대한 민감도를 낮출 수 있습니다 (예: Route 53)
6. 복잡성은 자동화하라
- “무엇을 자동화할 것인가?”가 아니라,
- “무엇을 자동화하지 않을 것인가?”를 묻는 것이 핵심.
- 판단이 덜 필요한 반복적 작업은 가급적 자동화하여,
- 사람은 판단이 필요한 영역에 집중할 수 있게 합니다 (예: Bedrock Serverless Agentic Workflows)
💭 이번이 첫 AWS 컨퍼런스 참석이었기 때문에, 전 세계적으로 기술적 영향력을 갖춘 아마존 CTO의 철학을 직접 들을 수 있다는 점만으로도 큰 감명을 받았습니다. 특히 우리가 일상적으로 사용하고 있는 AWS 서비스를 예시로 들며 설명해주셔서 내용이 더욱 와닿았고, 신선하게 느껴졌습니다.
여섯 가지 원칙 모두 중요했지만, 특히 2번 ‘복잡성 분해’와 4번 ‘셀 기반 구조’는 동료 네오께서도 평소 피드백을 주셨던 부분이라 더욱 깊이 새길 수 있었고, 6번 ‘자동화’ 원칙은 개인적으로 작년부터 관심을 가져온 주제라 특히 인상 깊었습니다. 지금까지는 “무엇을 자동화할 것인가”에만 집중했다면, “무엇을 자동화하지 않을 것인가”라는 관점은 저에게 매우 신선한 인사이트로 다가왔습니다.
나의 완벽한 개발 비서: Amazon Q와 함께 SDLC 이븐하게 가속하기
이번 AWS Summit Seoul 2025에서 특히 관심 있었던 세션 중 하나는 “나의 완벽한 개발 비서: Amazon Q와 함께 SDLC 이븐하게 가속하기”였습니다.
개발자의 입장에서 하루에도 수없이 반복되는 작업들—문서 탐색, 테스트 코드 작성, 디버깅 등—이 Amazon Q를 통해 어떻게 자동화되고 최적화되는지를 직접 확인할 수 있던 유익한 시간이었습니다.
Amazon Q는 단순한 코드 생성 도구가 아니라, SDLC(소프트웨어 개발 생명주기)의 전 구간을 지원하는 지능형 파트너라는 점이 특히 인상 깊었습니다. 예를 들어, 기획 단계에서는 방대한 문서나 운영 가이드를 빠르게 탐색할 수 있었고, 실제 개발 환경(IDE) 안에서는 코드 보완, 테스트 자동 생성, 심지어는 보안 스캔까지 지원했습니다.
세션 중 가장 흥미로웠던 부분은 기존 Java 애플리케이션을 현대화하는 데모였습니다. 대화형으로 코드를 분석하고, 테스트 코드를 생성하며, 마이그레이션 방향까지 제시하는 모습에서 “정말 이게 현실이구나” 하는 감탄이 나왔습니다.
특히 “Amazon Q Agent”를 활용한 대화 기반 리팩토링 과정은 마치 경험 많은 동료 개발자와 페어 프로그래밍하는 느낌이 들 정도였습니다.
무엇보다도, 사내 데이터를 학습한 전용 비서처럼 동작하면서도 코드 유출 없이 보안까지 신경 쓴 설계는 기업 입장에서 매우 매력적인 요소였습니다. 단순한 AI 도우미를 넘어, 현실적인 업무 흐름에 녹아드는 도구라는 점에서 실무 적용 가능성도 높아 보였습니다.
이번 세션을 통해 ‘자동화’에 대한 관점을 다시 한번 생각해보게 되었고, 반복적인 작업에서 벗어나 더 창의적이고 전략적인 업무에 집중할 수 있는 가능성을 체감할 수 있었습니다. 개발자로서의 일상이 어떻게 변화할 수 있을지를 미리 엿본 느낌이었습니다.
💭 우리 팀은 이미 PRD/UXDR 같은 요구사항 정의나 ADR 기반의 설계를 체계적으로 하고 있기 때문에, Amazon Q가 이러한 초기 기획 및 설계 단계에서 어떻게 도움을 줄 수 있을지가 가장 궁금했던 부분이었습니다. 아쉽게도 이번에는 체험 부스를 직접 방문해 보지는 못해 그 부분은 확인하지 못했지만,
한편으로는 데브옵스 팀에서 Amazon Q를 활용한 코드 리뷰 환경을 마련해주신 덕분에, 현재는 두 개의 레포에서 실험적으로 적용해보고 있는 중입니다.
✨ 숨고 1,000만 가입자를 이끈 플랫폼의 클라우드 활용 전략 및 혁신 스토리
💭 이번 세션을 통해 숨고의 시작부터 현재까지의 성장 과정과 기술적 진화를 되짚어볼 수 있어 의미 있는 시간이었습니다. 제가 입사하기 전부터 이어져 온 숨고의 변화와 확장 과정을 한눈에 정리해볼 수 있었고, 기술이 비즈니스 성장에 어떻게 기여했는지를 전체 맥락에서 이해할 수 있었습니다.
특히 데브옵스 영역은 평소 직접 접할 기회가 적었던 만큼, 많은 동료들의 노력과 기술적 도약이 어떤 식으로 플랫폼에 녹아들었는지를 새삼 실감할 수 있었습니다. 반면, 제가 입사한 이후의 여정에서는 직접 알고 있거나 일부 기여한 부분들도 있어, 개인적으로 더욱 몰입해서 들을 수 있었습니다.
또한 MAS 이전에는 배포(빌드)에 20분 이상 소요되던 시기가 있었다는 점이 인상 깊었고, 실제로 당시 상황이 꽤나 고되었을 거라는 생각도 들었습니다. 현재는 자주 있는 상황은 아니지만, MAS 서버에 포함된 알림 관련 작업이 배포될 경우 서버 수 증가로 인해 여전히 20분 이상 소요되는 경우도 발생하고 있어, 이 부분은 여전히 고민이 필요한 과제라는 생각도 들었습니다.
이번 세션은 단순한 회고를 넘어, 기술적 의사결정의 맥락을 공유하고, 앞으로의 방향을 고민할 수 있는 기회였다는 점에서 매우 유익했습니다.
변화하는 RDB 데이터를 놓치지 않는 실시간 스트리밍 아키텍처 이야기
이번 세션에서는 RDB의 데이터 변경 사항을 실시간으로 감지하고, 이를 안정적으로 스트리밍하는 아키텍처를 어떻게 구현했는지에 대한 구체적인 사례를 들을 수 있었습니다.
핵심은 CDC(Change Data Capture) 기술을 기반으로, 변경된 데이터를 Kafka로 전달하고, 이후 이를 다양한 다운스트림 시스템(예: 데이터 레이크, 모니터링, 실시간 알림 등)으로 유실 없이 안정적으로 전달하는 구조였습니다.
Debezium, MSK, Kafka Connect 등 오픈소스와 AWS 서비스를 조합하여 신뢰성과 확장성을 모두 고려한 점이 인상 깊었습니다.
특히 다음과 같은 포인트들이 유익했습니다:
- CDC를 통해 RDB 기반 시스템에서도 실시간 이벤트 처리 구조로 전환 가능
- 중복 처리, 순서 보장, 재처리 가능성 등 스트리밍 환경의 현실적 고려사항을 어떻게 풀었는지에 대한 설명
- 실시간성과 정확성 사이의 트레이드오프를 실용적인 기준으로 접근한 사례
개인적으로는 “어떤 데이터를 어떤 시점에 어떤 방식으로 처리할 것인가”에 대한 사고 전환의 계기가 되었고, 앞으로 데이터 흐름을 더 유연하고 실시간 중심으로 설계하는 데에 참고할 수 있는 좋은 인사이트를 얻었습니다.
💭 무신사의 세션을 통해 Kafka Streams라는 기술을 새롭게 알게 되어 매우 유익했고, 공통 데이터(예: 사용자 정보 등)를 각 도메인별로 중복 테이블로 관리한다는 접근도 인상적이었습니다. 또한, 데이터옵스 챕터의 윌크께서 Kafka Streams를 이미 알고 계시고 실험적으로 적용하고 계신다는 점도 큰 참고가 되었습니다.
우리는 주로 주소나 프로필 정보 변경을 감지해 실시간 동기화하는 데 활용하고 있지만, 리콘랩스에서는 변경 데이터를 기반으로 트래커 생성이나 알림 트리거 등 다양한 방식으로 확장하고 있다는 점도 흥미롭고, 앞으로의 활용 방향에 대한 좋은 인사이트가 되었습니다.
