<div id="readability-page-1" class="page"><div id="contents">
      <article id="entry">
         <div> 
	
	
<p>제가 연말에 늘 기대하는 것은 Amazon의 CTO인 Werner Vogels 박사님이 AWS re:Invent 2024에서 하는 마지막 기조 연설입니다. 여기서는 그의 가장 통찰력 있는 멋진 스토리를 들을 수 있는데요. 올해도 예외는 아니었고, “아키텍처 단순함”, 즉 Simplexity를 위한 6가지 배운점을 AWS 서비스를 예로 들어 공유해주셨습니다.</p>



<figure><img fetchpriority="high" decoding="async" width="940" height="528" src="https://channy.creation.net/data/channy/2025/01/02020628/1733448914359-940x528.png" alt="" sizes="(max-width: 940px) 100vw, 940px"></figure>



<h3>1. 요구 사항으로서 진화 가능성</h3>



<p>아마 오늘 설계하는 아키텍처는 내년에도 똑같지 않을 것입니다. 아키텍처의 진화 및 유지 관리 가능성은 서로 혼동해서는 안 됩니다. 하나는 시간이 지남에 따라 복잡성을 처리하기 위한 장기 전략이고 다른 하나는 단기적으로 시스템이 제대로 작동하도록 하는 것입니다. 예를 들어, Amazon S3는 네트워크(Nitro)와 스토리지가 서로 고정되지 않고 시간이 지남에 따라 진화할 수 있을 만큼 모듈식으로 만들어진 훌륭한 사례입니다.</p>



<p>아키텍처를 계속 바꿀 수 있는 것은 복잡성을 줄이고, 향후 변경 사항을 쉽게 수용할 수 있습니다.</p>



<figure><img decoding="async" width="940" height="426" src="https://channy.creation.net/data/channy/2025/01/02013333/1733507883919-940x426.png" alt="" sizes="(max-width: 940px) 100vw, 940px"></figure>



<h3>2. 복잡성을 조각으로 나누기</h3>



<p>아키텍처가 가진 복잡성을 해소하기 위해 시스템 분리/작은 구성 요소를 만듦으로서 서ㅅ비스간 낮은 결합도/높은 응집도 작은 구성 요소를 구성할 수 있습니다. 이를 위해 각 모듈이 쉽고 빠르게 서로 통신할 수 있도록 잘 정의된 API를 제공해야 합니다. Amazon CloudWatch가 바로 좋은 예입니다. 고객에게 중단 없이 새로운 기능을 제공하기 위해 시간이 지남에 따라 다시 작성되고 다시 작성된 매우 간단한 프론트엔드 서비스를 제공하고 있습니다.</p>



<p>높은 응집성과 잘 정의된 API를 통해 복잡한 기능을 빌딩 블록으로 분해하여 구성해야 합니다.</p>



<figure><img decoding="async" width="940" height="414" src="https://channy.creation.net/data/channy/2025/01/02013714/1733507593988-940x414.png" alt="" sizes="(max-width: 940px) 100vw, 940px"></figure>



<h3>3. 사내 조직을 아키텍처에 맞추기</h3>



<p>복잡한 시스템을 구축하면 조직은 일반적으로 구축하는 소프트웨어만큼 복잡해집니다. 즉, 소규모 팀을 구성하고, 현재 상태에 대해 항상 도전하며, 서비스 제공해주는 것이 좋습니다. 팀이 성공하려면, 팀이 진정으로 제품을 소유하고 있다고 느낄 때, 그들은 결과를 관리할 수 있다는 것을 알고 고객에게 투자했기 때문에 더 나은 결정을 내립니다.</p>



<figure><img loading="lazy" decoding="async" width="940" height="491" src="https://channy.creation.net/data/channy/2025/01/02013910/1733508010143-940x491.png" alt="" sizes="(max-width: 940px) 100vw, 940px"></figure>



<h3>4. 작은 단위로 구성하기</h3>



<p>서비스를 작은 셀 기반 아키텍처로 분해하여 각각 독립적으로 작동하도록 하여, (고객에게) 영향 범위를 줄이고 중단을 최소화 해야합니다. 작은 셀은 상상할 수 있는 가장 큰 작업 부하를 처리할 수 있을 만큼 커야 하지만, 전체 규모로 테스트할 수 있을 만큼 작아야 합니다. 더 큰 셀은 규모의 경제성을 제공하지만 문제의 잠재적 영향이 커집니다.</p>



<p>셀 기반 아키텍처는 서비스를 격리되고 관리 가능한 단위로 구성하여 복잡성을 줄입니다. 이 접근 방식은 확장, 테스트 및 배포를 보다 통제 가능하고 예측 가능하게 만듭니다. 이 아키텍처를 자체 시스템에 적용하는 방법에 대한 자세한 지침은 <a href="https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/what-is-a-cell-based-architecture.html">AWS Well-Architected Framework</a>를 확인하세요.</p>



<figure><img loading="lazy" decoding="async" width="940" height="501" src="https://channy.creation.net/data/channy/2025/01/02014046/1733566518164-940x501.png" alt="" sizes="(max-width: 940px) 100vw, 940px"></figure>



<h3>5. 예측 가능한 시스템 설계</h3>



<p>우리는 아키텍처의 불확실성을 줄이기 위해 매우 예측 가능한 시스템 구축해야 하는데, 이를 위해서는 단순하게 유지해야 합니다. 단순함에는 규율이 필요합니다. 이 규율은 작은 시스템으로 큰 시스템을 호출하고, 지속적인 작업 패턴을 구현합니다.</p>



<p>예를 들어, Amazon Route 53 상태 점검 기능의 목표는 매우 예측 가능한 처리입니다. 각 상태 점검기는 고정 크기 테이블을 보내고, 집계기는 모든 항목을 처리합니다. Route 53은 결과를 메모리에 저장하고 DNS 쿼리만 참조합니다. 이는 낭비처럼 보일 수 있지만 복잡한 처리를 줄이는 이점은 엄청납니다.</p>



<figure><img loading="lazy" decoding="async" width="940" height="500" src="https://channy.creation.net/data/channy/2025/01/02015835/1733566518168-940x500.jpg" alt="" sizes="(max-width: 940px) 100vw, 940px"></figure>



<h3>6. 복잡성 자동화</h3>



<p>자동화는 복잡하고 대규모 인프라를 관리하는 데 필수적입니다. AWS는 내구성, 확장성, 리전 구축, 소프트웨어 배포 및 물리적 네트워킹(문제의 자동 감지 및 해결)에 자동화를 사용합니다. 높은 판단력이 필요하지 않은 모든 작업은 자동화해야 합니다. “무엇을 자동화해야 할까?”에서 “무엇을 자동화하지 말아야 할까?”로 질문을 바꾸세요. </p>



<p>보안은 자동화를 어떻게 사용할 수 있는지에 대한 대표적인 예입니다. AWS에서 보안은 모든 사람의 일이며, 이는 복잡성을 관리하는 방법 중 하나입니다. 처음부터 보안을 고려하여 설계함으로써, 서비스를 생성할 때 보안을 서비스에 내장합니다. 이를 통해 대규모로 서비스를 실행하는 데 관련된 변수가 줄어들고 운영이 간소화되며 복잡성이 최소화됩니다.</p>



<figure><img loading="lazy" decoding="async" width="940" height="465" src="https://channy.creation.net/data/channy/2025/01/02020525/1733566518169-940x465.jpg" alt="" sizes="(max-width: 940px) 100vw, 940px"></figure>



<p>더 자세한 것은 <a href="https://www.youtube.com/watch?v=aim5x73crbM">Werner Vogels 박사님 기조 연설 영상</a>을 참고해주세요!</p>



<figure><p>
<iframe loading="lazy" title="​​AWS re:Invent 2024 - Dr. Werner Vogels Keynote" width="500" height="281" src="https://www.youtube.com/embed/aim5x73crbM?feature=oembed" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen=""></iframe>
</p></figure>
<div><h3>더 읽어 볼 글</h3></div>	

<p><small>- ;</small></p>

	<p>※ <a href="http://channy.creation.net/about/#disclaimer" target="new">Disclaimer</a>- 본 글은 개인적인 의견일 뿐 제가 재직했거나 하고 있는 기업의 공식 입장을 대변하거나 그 의견을 반영하는 것이 아닙니다. 사실 확인 및 개인 투자의 판단에 대해서는 독자 개인의 책임에 있으며, 상업적 활용 및 뉴스 매체의 인용 역시 금지함을 양해해 주시기 바랍니다. 본 채널은 광고를 비롯 어떠한 수익도 창출하지 않습니다. (The opinions expressed here are my own and do not necessarily represent those of current or past employers. Please note that you are solely responsible for your judgment on checking facts for your investments and prohibit your citations as commercial content or news sources. This channel does not monetize via any advertising.)</p>



	<p><small>* 이 글의 댓글 일부는 <a href="https://indieweb.org/Webmention">Webmention</a> 도구를 이용하여, 소셜 미디어 공유 반응(Comments, Like, Tweet)을 수집한 것입니다.</small></p>

<div id="respond"><h3>답글 남기기</h3>





</div>
   </div></article>
</div></div>

Channy's Blog

제가 연말에 늘 기대하는 것은 Amazon의 CTO인 Werner Vogels 박사님이 AWS re:Invent 2024에서 하는 마지막 기조 연설입니다. 여기서는 그의 가장 통찰력 있는 멋진 스토리를 들을 수 있는데요. 올해도 예외는 아니었고, “아키텍처 단순함”, 즉 Simplexity를 위한 6가지 배운점을 AWS 서비스를 예로 들어 공유해주셨습니다.
1. 요구 사항으로서 진화 가능성
아마 오늘 설계하는 아키텍처는 내년에도 똑같지 않을 것입니다. 아키텍처의 진화 및 유지 관리 가능성은 서로 혼동해서는 안 됩니다. 하나는 시간이 지남에 따라 복잡성을 처리하기 위한 장기 전략이고 다른 하나는 단기적으로 시스템이 제대로 작동하도록 하는 것입니다. 예를 들어, Amazon S3는 네트워크(Nitro)와 스토리지가 서로 고정되지 않고 시간이 지남에 따라 진화할 수 있을 만큼 모듈식으로 만들어진 훌륭한 사례입니다.
아키텍처를 계속 바꿀 수 있는 것은 복잡성을 줄이고, 향후 변경 사항을 쉽게 수용할 수 있습니다.
2. 복잡성을 조각으로 나누기
아키텍처가 가진 복잡성을 해소하기 위해 시스템 분리/작은 구성 요소를 만듦으로서 서ㅅ비스간 낮은 결합도/높은 응집도 작은 구성 요소를 구성할 수 있습니다. 이를 위해 각 모듈이 쉽고 빠르게 서로 통신할 수 있도록 잘 정의된 API를 제공해야 합니다. Amazon CloudWatch가 바로 좋은 예입니다. 고객에게 중단 없이 새로운 기능을 제공하기 위해 시간이 지남에 따라 다시 작성되고 다시 작성된 매우 간단한 프론트엔드 서비스를 제공하고 있습니다.
높은 응집성과 잘 정의된 API를 통해 복잡한 기능을 빌딩 블록으로 분해하여 구성해야 합니다.
3. 사내 조직을 아키텍처에 맞추기
복잡한 시스템을 구축하면 조직은 일반적으로 구축하는 소프트웨어만큼 복잡해집니다. 즉, 소규모 팀을 구성하고, 현재 상태에 대해 항상 도전하며, 서비스 제공해주는 것이 좋습니다. 팀이 성공하려면, 팀이 진정으로 제품을 소유하고 있다고 느낄 때, 그들은 결과를 관리할 수 있다는 것을 알고 고객에게 투자했기 때문에 더 나은 결정을 내립니다.
4. 작은 단위로 구성하기
서비스를 작은 셀 기반 아키텍처로 분해하여 각각 독립적으로 작동하도록 하여, (고객에게) 영향 범위를 줄이고 중단을 최소화 해야합니다. 작은 셀은 상상할 수 있는 가장 큰 작업 부하를 처리할 수 있을 만큼 커야 하지만, 전체 규모로 테스트할 수 있을 만큼 작아야 합니다. 더 큰 셀은 규모의 경제성을 제공하지만 문제의 잠재적 영향이 커집니다.
셀 기반 아키텍처는 서비스를 격리되고 관리 가능한 단위로 구성하여 복잡성을 줄입니다. 이 접근 방식은 확장, 테스트 및 배포를 보다 통제 가능하고 예측 가능하게 만듭니다. 이 아키텍처를 자체 시스템에 적용하는 방법에 대한 자세한 지침은 AWS Well-Architected Framework를 확인하세요.
5. 예측 가능한 시스템 설계
우리는 아키텍처의 불확실성을 줄이기 위해 매우 예측 가능한 시스템 구축해야 하는데, 이를 위해서는 단순하게 유지해야 합니다. 단순함에는 규율이 필요합니다. 이 규율은 작은 시스템으로 큰 시스템을 호출하고, 지속적인 작업 패턴을 구현합니다.
예를 들어, Amazon Route 53 상태 점검 기능의 목표는 매우 예측 가능한 처리입니다. 각 상태 점검기는 고정 크기 테이블을 보내고, 집계기는 모든 항목을 처리합니다. Route 53은 결과를 메모리에 저장하고 DNS 쿼리만 참조합니다. 이는 낭비처럼 보일 수 있지만 복잡한 처리를 줄이는 이점은 엄청납니다.
6. 복잡성 자동화
자동화는 복잡하고 대규모 인프라를 관리하는 데 필수적입니다. AWS는 내구성, 확장성, 리전 구축, 소프트웨어 배포 및 물리적 네트워킹(문제의 자동 감지 및 해결)에 자동화를 사용합니다. 높은 판단력이 필요하지 않은 모든 작업은 자동화해야 합니다. “무엇을 자동화해야 할까?”에서 “무엇을 자동화하지 말아야 할까?”로 질문을 바꾸세요. 
보안은 자동화를 어떻게 사용할 수 있는지에 대한 대표적인 예입니다. AWS에서 보안은 모든 사람의 일이며, 이는 복잡성을 관리하는 방법 중 하나입니다. 처음부터 보안을 고려하여 설계함으로써, 서비스를 생성할 때 보안을 서비스에 내장합니다. 이를 통해 대규모로 서비스를 실행하는 데 관련된 변수가 줄어들고 운영이 간소화되며 복잡성이 최소화됩니다.
더 자세한 것은 Werner Vogels 박사님 기조 연설 영상을 참고해주세요!

Simplexity: 복잡성을 단순하게 하는 6가지 원칙 – Werner Vogels

댓글