<div id="readability-page-1" class="page"><div id="contents">
      <article id="entry">
         <div> 
	
	
<p>지난 AWS re:Invent 2023에서 아마존닷컴 CTO이신 <a href="https://www.youtube.com/watch?v=UTRBVPvzt9w">Werner Vogels 박사님의 기조 연설</a>은 다른 해보다도 더 인상적이었습니다. 그의 기조연설은 항상 특정 주제를 가지고 기술적인 통찰력을 주는 것으로 유명한데요. 올해는 <a href="https://thefrugalarchitect.com/">The Frugal Architecture</a>를 위한 7가지 원칙을 제시해 주셨습니다. 여기서 Frugality라는 단어는 아마존 리더쉽 원칙에도 나오는 말로서 우리말로 옮기자면, “검소함” 혹은 “알뜰함” 즉, 낭비하지 않고 절약하는 마음가짐을 이야기합니다. </p>



<figure><img fetchpriority="high" decoding="async" width="940" height="486" src="https://channy.creation.net/data/channy/2023/12/26065645/2023-the-frugal-architecture-940x486.jpg" alt="" sizes="(max-width: 940px) 100vw, 940px"></figure>



<p>버너 박사님이 “알뜰한 아키텍처”를 이야기하게 된 이유는 아이러니하게도 클라우드 컴퓨팅이 기존 온프레미스 시대의 하드웨어의 제약을 없앴기 때문입니다. 원래 창의성과 혁신은 바로 기술의 제약에서 옵니다. 다시 말해서, 클라우드 시대에는 새로운 제약 조건을 상정해야만 새로운 창의성을 발휘할 수 있게 되며, 여기서 “비용”이라는 제약 조건을 둘 필요가 있다는 것입니다.</p>



<p>비용을 염두해 두고 아키텍처를 개선한 대표적인 케이스로 <a href="https://aws.amazon.com/blogs/containers/pbs-speeds-deployment-and-reduces-costs-with-aws-fargate/">미국 공영방송인 PBS 사례</a>를 들었습니다. 한국의 EBS와 같이 엄격한 예산 제한 속에 있었기 때문에, 그냥 옮기는(Lift &amp; Shift) 방식의 클라우드 마이그레이션은 비용 증가를 의미합니다. 그래서, PBS는 비용 중심의 아키텍처 재설계를 통해 스트리밍 비용을 80%까지 줄였습니다. 그들은 예산이라는 제약 사항이 있었기 때문에 클라우드 네이티브 아키텍처로 전환할 수 있었습니다.</p>



<figure><img decoding="async" width="940" height="529" src="https://channy.creation.net/data/channy/2023/12/26071242/2023-werner-keynote-pbs-case-940x529.jpg" alt="" sizes="(max-width: 940px) 100vw, 940px"></figure>



<p>이 글에서는 버너 박사님의 기조 연설에서 소개한 알뜰한 아키텍처의 원칙과 사례를 요약해보록 하겠습니다.</p>



<h3>1. 비용을 (비기능적) 요구사항으로 설정하라</h3>



<blockquote>
<p>비기능 요구사항은 특정 기능보다는 시스템 작동을 판단하는 기준을 말합니다. 예를 들어, 접근성, 가용성, 확장성, 보안, 이식성, 유지 관리 용이성, 규정 준수 등이며, 비용으로 잘 인식하지 못합니다. 개발 프로젝트는 설계부터 개발, 운영까지 비즈니스의 모든 단계의 (비기능 요구사항의) 비용을 고려하지 않거나 제대로 측정하지 않기 때문에 실패할 수 있습니다. 비용이 이익보다 높으면 비즈니스가 위험에 처하게 됩니다.비용 영향을 조기에 지속적으로 고려함으로써 서비스 기능, 출시 시기 및 효율성의 균형을 맞추도록 시스템을 설계할 수 있습니다. 개발에서는 간결하고 효율적인 코드를 유지하는 데 집중할 수 있습니다. 그리고 운영에서는 리소스 사용과 지출을 미세 조정하여 수익성을 극대화할 수 있습니다.</p>
</blockquote>



<p>예를 들어, AWS는 서비스를 만들 때, 정액제가 아닌 종량제 모델을 택하고, 고객이 서비스를 이용하는 단계에서 서비스에 추가적인 비용이 드는 부분을 고려했습니다. 예를 들어, Amazon S3의 경우, 스토리지 사용량과 데이터 전송량 뿐만 아니라 호출수도 고려해야 한다는 점을 발견하고 추가했습니다. 따라서, 개발 및 운영 과정의 모든 단계에서 비용을 고려해야 합니다.</p>



<figure><img decoding="async" width="940" height="520" src="https://channy.creation.net/data/channy/2023/12/26071250/2023-werner-keynote-s3-case-940x520.jpg" alt="" sizes="(max-width: 940px) 100vw, 940px"></figure>



<h3>2. 시스템을 비지니스 운영 비용에 맞추어라</h3>



<blockquote>
<p>개발한 시스템의 내구성은 운영 비용이 비즈니스 모델에 얼마나 잘 부합하는지에 따라 달라집니다. 시스템을 설계하고 구축할 때는 수익을 고려해야 합니다. 돈을 버는 방법을 찾고, 아키텍처가 수익을 내는지 확인해야 합니다. 예를 들어 전자 상거래에서 돈 버는 방법을 주문 횟수라고 합시다. 만약, 주문이 증가하면 인프라 및 운영 비용도 함께 증가합니다. 그러나, 시스템이 잘 구성되어 있으면 규모의 경제를 활용할 수 있으므로 괜찮습니다. 인프라 비용으로 비즈니스를 측정할 수 있다는 것이 중요합니다. 개발자들은 수익을 늘 생각하고, 지식을 총동원해야 합니다. 비용이 더 많은 성장은 결국 파멸의 길로 이어지니까요.</p>
</blockquote>



<p>예를 들어, AWS Lambda를 초기에 T2 인스턴스로 구성을 했다가, 운영 비용이 매우 늘어났습니다. 비용 최적화를 위해 Firecracker라는 microVM으로 리팩토링하고 나서, 비용도 줄이고 속도도 향상되었습니다. 파이어크래커 덕분에 Fargate라는 서버리스 컨테이너 서비스를 만들 수 있었구요. 기술 부채가 복리로 더 이상 쌓이기 (비용이 수익을 초월하기) 전에 부채를 계속 갚아 나가야 합니다.</p>



<figure><img loading="lazy" decoding="async" width="940" height="489" src="https://channy.creation.net/data/channy/2023/12/26071302/2023-werner-keynote-firecracker-940x489.jpg" alt="" sizes="(max-width: 940px) 100vw, 940px"></figure>



<h3>3. 아키텍처는 타협(Trade-off)의 연속이다</h3>



<blockquote>
<p>모든 기술적 결정은 절충점을 찾아야 합니다. 비용, 탄력성, 보안 및 성능은 서로 긴장 관계에 있습니다. 예를 들어, 장애를 방지하기 위해 회복력에 투자하면, 성능에 대해서는 포기해야 할 수도 있습니다. 따라서, 기술과 비즈니스 요구 사항 사이의 적절한 균형을 찾는 것이 중요합니다. 즉, 위험 허용 범위와 비용의 최적점을 찾는 것입니다. 알뜰함은 지출을 최소화하는 것이 아니라 가치를 극대화하는 것입니다. 이를 위해 어느 정도 투자할 의향이 있는지 결정해야 합니다.</p>
</blockquote>



<p>예를 들어, AWS 고객인 <a href="https://aws.amazon.com/solutions/case-studies/nubank/">Nubank 사례</a>에서는 비용, 안정성 및 성능 간의 균형을 이루기 위해 마이크로서비스 가비지 수집 및 데이터베이스 캐싱 전략과 같은 영역에 초점을 맞춰 아키텍처를 개선했습니다. 이를 통해, 9천만 명의 은행 고객이 2022년에 80억 달러의 수수료를 절약했다고 합니다. 버너 박사님은 회사에서 중요하게 생각하는 우선 순위를 조정하라고 조언했습니다.</p>



<figure><img loading="lazy" decoding="async" width="940" height="503" src="https://channy.creation.net/data/channy/2023/12/26071449/2023-werner-keynote-nubank-case-940x503.jpg" alt="" sizes="(max-width: 940px) 100vw, 940px"></figure>



<h3>4. 측정되지 않은 시스템은 알 수 없는 비용을 만든다</h3>



<blockquote>
<p>주의 깊은 관찰과 측정 없이는 시스템 운영에 드는 실제 비용을 알 수 없습니다. 모든 부분에서 관찰하고 적절한 모니터링을 구현해야 합니다. “측정할 수 없으면 관리할 수 없다”는 격언이 있습니다. 시스템 사용량, 오류 등을 추적하는 것은 비용 관리에 매우 중요합니다. 기획자와 엔지니어들이 핵심적인 비용 지표를 제일 중요하게 다루기 시작하면, 지속적인 실행들이 유기적으로 일어날 것입니다. 지속적인 검사를 통해 초과 지출을 찾아내고 운영 방식을 조정하면 비용을 절감할 수 있습니다. 관찰 가능성(observability)에 대한 투자 수익은 일반적으로 비용보다 훨씬 큽니다. 비용을 최우선에 두면, 지속 가능한 실행이 가능해집니다.</p>
</blockquote>



<p>예를 들어, 1970년대 암스테르담에서는 석유 파동으로 인한 에너지 절약을 위해 전기 계량기를 달았는데요. 똑같은 건물의 전기 사용량에 차이가 있는 것을 발견했습니다. 계량기가 지하실에 설치된 건물이 건물 입구에 달아둔 곳 보다 전기 사용량이 높은 것이었습니다. 즉, 잘 살펴보지 않으면 낭비적인 습관이 생길 수 있습니다. 계량기를 눈에 띄는 위치에 두는 것만으로도 행동이 크게 바뀔 수 있다는 사실입니다. </p>



<figure><img loading="lazy" decoding="async" width="940" height="540" src="https://channy.creation.net/data/channy/2023/12/26071624/2023-werner-keynote-amsterdam-case-940x540.jpg" alt="" sizes="(max-width: 940px) 100vw, 940px"></figure>



<p>아마존의 경우, 각 마이크로서비스를 운영하는 팀이 시스템 내의 모든 비용을 측정해서, 낮은 소매 마진을 충분히 메꿀 수 있어야 합니다. 예를 들어 요청당 비용의 경우, 이를 규모의 경제에 이르도록 시간에 따라 감소하도록 계속 측정하고 재설계하고 있습니다. 비지니스를 위한 측정 지표를 정의하고 이를 관리해야 합니다.</p>



<figure><img loading="lazy" decoding="async" width="876" height="472" src="https://channy.creation.net/data/channy/2023/12/26071921/2023-werner-keynote-amazon-cost-per-requests.jpg" alt="" sizes="(max-width: 876px) 100vw, 876px"></figure>



<h3>5. 비용 인식 아키텍처는 비용을 통제할 수 있다</h3>



<blockquote>
<p>알뜰한 아키텍처의 핵심은 비용 최적화 기능과 결합된 강력한 모니터링입니다. 잘 설계된 아키텍처를 통해 쉽게 개선 조치를 취할 수 있습니다. 이를 위해 애플리케이션을 쉽게 바꿀 수 있는 작은 빌딩 블록으로 나누세요. 일반적인 접근 방식은 중요도에 따라 구성 요소를 계층화하는 것입니다. Tier 1은 필수적인 것으로 비용에 관계없이 최적화합니다. Tier 2는 중요하지만 큰 영향 없이 일시적으로 축소할 수 있습니다. Tier 3 구성요소는 “있으면 좋고”입니다. 낮은 비용으로 쉽게 제어할 수 있도록 하세요. 이렇게 계층을 정의하면 비용과 기타 요구 사항 간의 절충이 가능해집니다. 더 세밀하게 제어하면 비용과 경험이 모두 최적화됩니다. 인프라, 프로그래밍 언어, 데이터베이스 역시 모두 조정 가능해야 합니다. 항상 매출과 이익을 염두에 두고 시스템을 설계하고 구축하세요. 비용 최적화는 측정 가능해야 하며 비즈니스와 늘 연계되어야 합니다.</p>
</blockquote>



<p>아마존에서는 T1은 상품 검색, 장바구니, 주문, 결제 기능이죠. T2는 개인화 및 추천 같은게 되겠죠. T2에서 T1으로 이동한 것 대표적인 것이 바로 상품 리뷰입니다. T3는 베스트셀러 목록 같은 것입니다. 어떻게 계층을 설정할 수 있을까요? 실제로 이들 기능을 고객 관점에서 실제로 끄고 켜보면 어떤게 진짜 중요한지 알 수 있게 됩니다.</p>



<figure><img loading="lazy" decoding="async" width="940" height="490" src="https://channy.creation.net/data/channy/2023/12/26072304/2023-werner-keynote-amazon-tiers-940x490.jpg" alt="" sizes="(max-width: 940px) 100vw, 940px"></figure>



<h3>6. 비용 최적화는 누적되어야 한다</h3>



<blockquote>
<p>비용 효율성을 추구하는 것은 지속적인 여정이어야 합니다. 서비스 배포 후에도 시스템을 다시 최적화하여, 점진적인 개선을 해야 합니다. 이를 위해 끊임없이 질문하고 더 깊이 파고들어야 합니다. 프로그래밍 언어 단에서 코드 성능을 분석하는 프로파일링 도구를 사용하여, 실행 시간을 밀리초 단축하기 위한 세부적인 분석이 가능합니다. 아주 작은 최적화처럼 보일 수 있지만 규모에 따라 큰 절감 효과가 축적됩니다. 운영 중에는 기존 시스템을 실행하는 데 대부분 시간이 소요됩니다. 자원 사용량을 프로파일링하고 낭비를 줄여야 합니다. Amazon에서는 프로덕션 서비스를 지속적으로 모니터링헤서 비효율성의 패턴을 찾아 줄여 나갑니다. 절약을 위해서는 끈기가 필요합니다. 지연 시간과 인프라 비용을 점진적으로 줄여 서비스 비용을 최적화할 수 있습니다. 계속 찾아보면 개선의 여지는 항상 있습니다. 오늘 우리가 얻은 비용 절감으로 내일을 위한 혁신에 투자할 수 있습니다.</p>
</blockquote>



<p>예를 들어, 비용 절감 기회를 계속 모색해야 합니다. 개발 장비는 업무 외에는 끈다던가, x86 대비 전력량이나 비용 대비 성능이 높은 Arm 기반으로 바꾼다거나, 서비스에 불필요한 낭비 요소는 없는지 찾아보는 것입니다. Amazon CodeGuru 프로파일러의 경우, 기계 학습 알고리즘을 사용하여 가장 비용이 많이 드는 코드 라인을 찾는 데 도움을 주고 효율성을 개선하고 CPU 병목 현상을 제거할 수 있는 방법을 찾아낼 수 있습니다. <a href="https://aws.amazon.com/ko/blogs/korea/how-to-improve-software-development-productivity-ml-based-aws-cloud-services/">클라우드 기반 AI 코드 서비스</a>를 활용해서 지속적으로 프로그램 코드와 성능을 개선하시기 바랍니다.</p>



<figure><img loading="lazy" decoding="async" width="940" height="469" src="https://channy.creation.net/data/channy/2023/12/26072741/2022-aws-ai-code-services-940x469.jpg" alt="" sizes="(max-width: 940px) 100vw, 940px"></figure>



<h3>7. 성공은 안주하는 경향이 있다</h3>



<blockquote>
<p>대개 큰 실패나 장애물없이 성공을 거두면 현실에 안주하게 됩니다. 예전에 성공한 방법, 도구 및 방식에 대해 과신하는 위험한 경향이 있습니다. 개발팀은 예전의 아키텍처나 기술적 선택이 최선이라고 가정하는 함정에 빠질 수 있습니다. 이는 현 상태에 대한 의문을 제기하거나 보다 비용 효율적이거나 확장 가능한 새로운 옵션을 탐색하는 것을 방해할 수 있습니다. 특히, 프로그래밍 언어와 관련하여 이러한 현상을 자주 볼 수 있습니다. “우리는 Java만 써요”라는 말은 너무 자주 들어본 말인데, 이는 혁신을 저해할 수 있습니다. 도전받지 않은 성공은 가정을 통해 안일함을 낳습니다. 우리는 항상 질문하고, 최적화하고, 개선할 수 있는 방법을 찾아야 합니다. Grace Hopper의 “영어에서 가장 위험한 표현은 ‘우리는 늘 이런식으로 해왔다'” 인용문처럼 과거의 방식을 고집해서는 안됩니다.</p>
</blockquote>



<p>사실 우리 나라 많은 IT 기업들에서 자주 보이는 모습입니다. 모든 프로젝트가 개발 비용 보다 운영 비용이 훨씬 높습니다. 개발 이후에도 안주하지 않고 지속적인 평가와 개선이 필요합니다. 새로운 프로젝트를 할 때도 새로운 검토와 도전을 해야 합니다. 예를 들어, Ruby와 Python은 C++과 Rust에 비해 50배 이상의 에너지를 쓴다는 연구 결과가 있습니다. AWS는 Rust를 기반으로 Firecracker를 구현했고, S3의 많은 기능을 구현하고 있습니다. 버너 박사님은 우리가 항상 계속해서 배우고, 자신의 기술적 신념을 재확인하면서, 때로는 기존의 믿음을 부정해야 한다고 하셨습니다.</p>



<figure><img loading="lazy" decoding="async" width="940" height="499" src="https://channy.creation.net/data/channy/2023/12/26072524/2023-werner-keynote-program-language-rankings-by-energy-940x499.jpg" alt="" sizes="(max-width: 940px) 100vw, 940px"></figure>



<p>결론적으로 개발 및 운영 비용을 제약 사항으로 두는 것은 매우 중요한 혁신의 동기가 될 수 있습니다. 예를 들어, 에너지 문제에 대한 지속 가능성은 앞으로 매우 중요하게 다뤄질 분야입니다. 앞으로 전력량이나 탄소 배출을 신경쓸 수 밖에 없으며, 이는 인공 지능 시대에서 새로운 제약이 될 것이기 때문입니다. 저는 버너 박사님이 암호화폐, 메타버스, 생성형 AI와 같은 고 비용 기술 구조의 진화에서 우리가 여전히 신경써야 할 것이 무엇인지 일깨워주셨다고 생각합니다.</p>



<p>The Frugal Architecture 외에도 AI 시대의 개발자들이 어떻게 생산성을 높히고 미래를 바꿔 나갈 수 있는지 다양한 사례와 통찰력도 전해 주셨습니다. 메트릭스를 패러디한 깨알같은 드라마와 연기도 있으니 꼭 한번 시청해 보시길 바랍니다.</p>



<figure><p>
<iframe loading="lazy" title="AWS re:Invent 2023 - Keynote with Dr. Werner Vogels" width="500" height="281" src="https://www.youtube.com/embed/UTRBVPvzt9w?feature=oembed" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" 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.)</p>


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

Channy's Blog

지난 AWS re:Invent 2023에서 아마존닷컴 CTO이신 Werner Vogels 박사님의 기조 연설은 다른 해보다도 더 인상적이었습니다. 그의 기조연설은 항상 특정 주제를 가지고 기술적인 통찰력을 주는 것으로 유명한데요. 올해는 The Frugal Architecture를 위한 7가지 원칙을 제시해 주셨습니다. 여기서 Frugality라는 단어는 아마존 리더쉽 원칙에도 나오는 말로서 우리말로 옮기자면, “검소함” 혹은 “알뜰함” 즉, 낭비하지 않고 절약하는 마음가짐을 이야기합니다. 
버너 박사님이 “알뜰한 아키텍처”를 이야기하게 된 이유는 아이러니하게도 클라우드 컴퓨팅이 기존 온프레미스 시대의 하드웨어의 제약을 없앴기 때문입니다. 원래 창의성과 혁신은 바로 기술의 제약에서 옵니다. 다시 말해서, 클라우드 시대에는 새로운 제약 조건을 상정해야만 새로운 창의성을 발휘할 수 있게 되며, 여기서 “비용”이라는 제약 조건을 둘 필요가 있다는 것입니다.
비용을 염두해 두고 아키텍처를 개선한 대표적인 케이스로 미국 공영방송인 PBS 사례를 들었습니다. 한국의 EBS와 같이 엄격한 예산 제한 속에 있었기 때문에, 그냥 옮기는(Lift & Shift) 방식의 클라우드 마이그레이션은 비용 증가를 의미합니다. 그래서, PBS는 비용 중심의 아키텍처 재설계를 통해 스트리밍 비용을 80%까지 줄였습니다. 그들은 예산이라는 제약 사항이 있었기 때문에 클라우드 네이티브 아키텍처로 전환할 수 있었습니다.
이 글에서는 버너 박사님의 기조 연설에서 소개한 알뜰한 아키텍처의 원칙과 사례를 요약해보록 하겠습니다.
1. 비용을 (비기능적) 요구사항으로 설정하라
비기능 요구사항은 특정 기능보다는 시스템 작동을 판단하는 기준을 말합니다. 예를 들어, 접근성, 가용성, 확장성, 보안, 이식성, 유지 관리 용이성, 규정 준수 등이며, 비용으로 잘 인식하지 못합니다. 개발 프로젝트는 설계부터 개발, 운영까지 비즈니스의 모든 단계의 (비기능 요구사항의) 비용을 고려하지 않거나 제대로 측정하지 않기 때문에 실패할 수 있습니다. 비용이 이익보다 높으면 비즈니스가 위험에 처하게 됩니다.비용 영향을 조기에 지속적으로 고려함으로써 서비스 기능, 출시 시기 및 효율성의 균형을 맞추도록 시스템을 설계할 수 있습니다. 개발에서는 간결하고 효율적인 코드를 유지하는 데 집중할 수 있습니다. 그리고 운영에서는 리소스 사용과 지출을 미세 조정하여 수익성을 극대화할 수 있습니다.
예를 들어, AWS는 서비스를 만들 때, 정액제가 아닌 종량제 모델을 택하고, 고객이 서비스를 이용하는 단계에서 서비스에 추가적인 비용이 드는 부분을 고려했습니다. 예를 들어, Amazon S3의 경우, 스토리지 사용량과 데이터 전송량 뿐만 아니라 호출수도 고려해야 한다는 점을 발견하고 추가했습니다. 따라서, 개발 및 운영 과정의 모든 단계에서 비용을 고려해야 합니다.
2. 시스템을 비지니스 운영 비용에 맞추어라
개발한 시스템의 내구성은 운영 비용이 비즈니스 모델에 얼마나 잘 부합하는지에 따라 달라집니다. 시스템을 설계하고 구축할 때는 수익을 고려해야 합니다. 돈을 버는 방법을 찾고, 아키텍처가 수익을 내는지 확인해야 합니다. 예를 들어 전자 상거래에서 돈 버는 방법을 주문 횟수라고 합시다. 만약, 주문이 증가하면 인프라 및 운영 비용도 함께 증가합니다. 그러나, 시스템이 잘 구성되어 있으면 규모의 경제를 활용할 수 있으므로 괜찮습니다. 인프라 비용으로 비즈니스를 측정할 수 있다는 것이 중요합니다. 개발자들은 수익을 늘 생각하고, 지식을 총동원해야 합니다. 비용이 더 많은 성장은 결국 파멸의 길로 이어지니까요.
예를 들어, AWS Lambda를 초기에 T2 인스턴스로 구성을 했다가, 운영 비용이 매우 늘어났습니다. 비용 최적화를 위해 Firecracker라는 microVM으로 리팩토링하고 나서, 비용도 줄이고 속도도 향상되었습니다. 파이어크래커 덕분에 Fargate라는 서버리스 컨테이너 서비스를 만들 수 있었구요. 기술 부채가 복리로 더 이상 쌓이기 (비용이 수익을 초월하기) 전에 부채를 계속 갚아 나가야 합니다.
3. 아키텍처는 타협(Trade-off)의 연속이다
모든 기술적 결정은 절충점을 찾아야 합니다. 비용, 탄력성, 보안 및 성능은 서로 긴장 관계에 있습니다. 예를 들어, 장애를 방지하기 위해 회복력에 투자하면, 성능에 대해서는 포기해야 할 수도 있습니다. 따라서, 기술과 비즈니스 요구 사항 사이의 적절한 균형을 찾는 것이 중요합니다. 즉, 위험 허용 범위와 비용의 최적점을 찾는 것입니다. 알뜰함은 지출을 최소화하는 것이 아니라 가치를 극대화하는 것입니다. 이를 위해 어느 정도 투자할 의향이 있는지 결정해야 합니다.
예를 들어, AWS 고객인 Nubank 사례에서는 비용, 안정성 및 성능 간의 균형을 이루기 위해 마이크로서비스 가비지 수집 및 데이터베이스 캐싱 전략과 같은 영역에 초점을 맞춰 아키텍처를 개선했습니다. 이를 통해, 9천만 명의 은행 고객이 2022년에 80억 달러의 수수료를 절약했다고 합니다. 버너 박사님은 회사에서 중요하게 생각하는 우선 순위를 조정하라고 조언했습니다.
4. 측정되지 않은 시스템은 알 수 없는 비용을 만든다
주의 깊은 관찰과 측정 없이는 시스템 운영에 드는 실제 비용을 알 수 없습니다. 모든 부분에서 관찰하고 적절한 모니터링을 구현해야 합니다. “측정할 수 없으면 관리할 수 없다”는 격언이 있습니다. 시스템 사용량, 오류 등을 추적하는 것은 비용 관리에 매우 중요합니다. 기획자와 엔지니어들이 핵심적인 비용 지표를 제일 중요하게 다루기 시작하면, 지속적인 실행들이 유기적으로 일어날 것입니다. 지속적인 검사를 통해 초과 지출을 찾아내고 운영 방식을 조정하면 비용을 절감할 수 있습니다. 관찰 가능성(observability)에 대한 투자 수익은 일반적으로 비용보다 훨씬 큽니다. 비용을 최우선에 두면, 지속 가능한 실행이 가능해집니다.
예를 들어, 1970년대 암스테르담에서는 석유 파동으로 인한 에너지 절약을 위해 전기 계량기를 달았는데요. 똑같은 건물의 전기 사용량에 차이가 있는 것을 발견했습니다. 계량기가 지하실에 설치된 건물이 건물 입구에 달아둔 곳 보다 전기 사용량이 높은 것이었습니다. 즉, 잘 살펴보지 않으면 낭비적인 습관이 생길 수 있습니다. 계량기를 눈에 띄는 위치에 두는 것만으로도 행동이 크게 바뀔 수 있다는 사실입니다. 
아마존의 경우, 각 마이크로서비스를 운영하는 팀이 시스템 내의 모든 비용을 측정해서, 낮은 소매 마진을 충분히 메꿀 수 있어야 합니다. 예를 들어 요청당 비용의 경우, 이를 규모의 경제에 이르도록 시간에 따라 감소하도록 계속 측정하고 재설계하고 있습니다. 비지니스를 위한 측정 지표를 정의하고 이를 관리해야 합니다.
5. 비용 인식 아키텍처는 비용을 통제할 수 있다
알뜰한 아키텍처의 핵심은 비용 최적화 기능과 결합된 강력한 모니터링입니다. 잘 설계된 아키텍처를 통해 쉽게 개선 조치를 취할 수 있습니다. 이를 위해 애플리케이션을 쉽게 바꿀 수 있는 작은 빌딩 블록으로 나누세요. 일반적인 접근 방식은 중요도에 따라 구성 요소를 계층화하는 것입니다. Tier 1은 필수적인 것으로 비용에 관계없이 최적화합니다. Tier 2는 중요하지만 큰 영향 없이 일시적으로 축소할 수 있습니다. Tier 3 구성요소는 “있으면 좋고”입니다. 낮은 비용으로 쉽게 제어할 수 있도록 하세요. 이렇게 계층을 정의하면 비용과 기타 요구 사항 간의 절충이 가능해집니다. 더 세밀하게 제어하면 비용과 경험이 모두 최적화됩니다. 인프라, 프로그래밍 언어, 데이터베이스 역시 모두 조정 가능해야 합니다. 항상 매출과 이익을 염두에 두고 시스템을 설계하고 구축하세요. 비용 최적화는 측정 가능해야 하며 비즈니스와 늘 연계되어야 합니다.
아마존에서는 T1은 상품 검색, 장바구니, 주문, 결제 기능이죠. T2는 개인화 및 추천 같은게 되겠죠. T2에서 T1으로 이동한 것 대표적인 것이 바로 상품 리뷰입니다. T3는 베스트셀러 목록 같은 것입니다. 어떻게 계층을 설정할 수 있을까요? 실제로 이들 기능을 고객 관점에서 실제로 끄고 켜보면 어떤게 진짜 중요한지 알 수 있게 됩니다.
6. 비용 최적화는 누적되어야 한다
비용 효율성을 추구하는 것은 지속적인 여정이어야 합니다. 서비스 배포 후에도 시스템을 다시 최적화하여, 점진적인 개선을 해야 합니다. 이를 위해 끊임없이 질문하고 더 깊이 파고들어야 합니다. 프로그래밍 언어 단에서 코드 성능을 분석하는 프로파일링 도구를 사용하여, 실행 시간을 밀리초 단축하기 위한 세부적인 분석이 가능합니다. 아주 작은 최적화처럼 보일 수 있지만 규모에 따라 큰 절감 효과가 축적됩니다. 운영 중에는 기존 시스템을 실행하는 데 대부분 시간이 소요됩니다. 자원 사용량을 프로파일링하고 낭비를 줄여야 합니다. Amazon에서는 프로덕션 서비스를 지속적으로 모니터링헤서 비효율성의 패턴을 찾아 줄여 나갑니다. 절약을 위해서는 끈기가 필요합니다. 지연 시간과 인프라 비용을 점진적으로 줄여 서비스 비용을 최적화할 수 있습니다. 계속 찾아보면 개선의 여지는 항상 있습니다. 오늘 우리가 얻은 비용 절감으로 내일을 위한 혁신에 투자할 수 있습니다.
예를 들어, 비용 절감 기회를 계속 모색해야 합니다. 개발 장비는 업무 외에는 끈다던가, x86 대비 전력량이나 비용 대비 성능이 높은 Arm 기반으로 바꾼다거나, 서비스에 불필요한 낭비 요소는 없는지 찾아보는 것입니다. Amazon CodeGuru 프로파일러의 경우, 기계 학습 알고리즘을 사용하여 가장 비용이 많이 드는 코드 라인을 찾는 데 도움을 주고 효율성을 개선하고 CPU 병목 현상을 제거할 수 있는 방법을 찾아낼 수 있습니다. 클라우드 기반 AI 코드 서비스를 활용해서 지속적으로 프로그램 코드와 성능을 개선하시기 바랍니다.
7. 성공은 안주하는 경향이 있다
대개 큰 실패나 장애물없이 성공을 거두면 현실에 안주하게 됩니다. 예전에 성공한 방법, 도구 및 방식에 대해 과신하는 위험한 경향이 있습니다. 개발팀은 예전의 아키텍처나 기술적 선택이 최선이라고 가정하는 함정에 빠질 수 있습니다. 이는 현 상태에 대한 의문을 제기하거나 보다 비용 효율적이거나 확장 가능한 새로운 옵션을 탐색하는 것을 방해할 수 있습니다. 특히, 프로그래밍 언어와 관련하여 이러한 현상을 자주 볼 수 있습니다. “우리는 Java만 써요”라는 말은 너무 자주 들어본 말인데, 이는 혁신을 저해할 수 있습니다. 도전받지 않은 성공은 가정을 통해 안일함을 낳습니다. 우리는 항상 질문하고, 최적화하고, 개선할 수 있는 방법을 찾아야 합니다. Grace Hopper의 “영어에서 가장 위험한 표현은 ‘우리는 늘 이런식으로 해왔다'” 인용문처럼 과거의 방식을 고집해서는 안됩니다.
사실 우리 나라 많은 IT 기업들에서 자주 보이는 모습입니다. 모든 프로젝트가 개발 비용 보다 운영 비용이 훨씬 높습니다. 개발 이후에도 안주하지 않고 지속적인 평가와 개선이 필요합니다. 새로운 프로젝트를 할 때도 새로운 검토와 도전을 해야 합니다. 예를 들어, Ruby와 Python은 C++과 Rust에 비해 50배 이상의 에너지를 쓴다는 연구 결과가 있습니다. AWS는 Rust를 기반으로 Firecracker를 구현했고, S3의 많은 기능을 구현하고 있습니다. 버너 박사님은 우리가 항상 계속해서 배우고, 자신의 기술적 신념을 재확인하면서, 때로는 기존의 믿음을 부정해야 한다고 하셨습니다.
결론적으로 개발 및 운영 비용을 제약 사항으로 두는 것은 매우 중요한 혁신의 동기가 될 수 있습니다. 예를 들어, 에너지 문제에 대한 지속 가능성은 앞으로 매우 중요하게 다뤄질 분야입니다. 앞으로 전력량이나 탄소 배출을 신경쓸 수 밖에 없으며, 이는 인공 지능 시대에서 새로운 제약이 될 것이기 때문입니다. 저는 버너 박사님이 암호화폐, 메타버스, 생성형 AI와 같은 고 비용 기술 구조의 진화에서 우리가 여전히 신경써야 할 것이 무엇인지 일깨워주셨다고 생각합니다.
The Frugal Architecture 외에도 AI 시대의 개발자들이 어떻게 생산성을 높히고 미래를 바꿔 나갈 수 있는지 다양한 사례와 통찰력도 전해 주셨습니다. 메트릭스를 패러디한 깨알같은 드라마와 연기도 있으니 꼭 한번 시청해 보시길 바랍니다.

The Frugal Architecture – 알뜰한 아키텍처를 위한 7가지 원칙

댓글