새로운 아키텍처 검증


컨텐츠

  • Lucidscale을 활용해 새로운 클라우드 아키텍처를 검증하는 방법
  • 예시 
  • 결론

새로운 클라우드 아키텍처를 계획할 때는 상당한 작업이 필요합니다. 그리고 가끔은 아키텍처를 빌드하는 사람과 설계하는 사람이 다를 때도 있습니다. 새로운 아키텍처를 개발하는 작업자가 제공된 그림을 잘못 해석할 수도 있고, 창의력을 발휘해 장기적으로 도움이 될 거라고 생각하는 방향으로 아키텍처를 수정할 수도 있습니다. 이렇듯 설계와 빌드 사이엔 간격이 존재할 수 있기 때문에 아키텍처가 원래의 계획에 따라 빌드되었는지 검증하는 과정이 매우 중요합니다.

2 분 읽기

사용자 고유의 클라우드 시각화를 작성하시겠습니까? 루시스케일을 시도해 보세요. 빠르고, 쉽고, 완전히 자유롭습니다.

무료로 가입하기

Lucidscale을 활용해 새로운 클라우드 아키텍처를 검증하는 방법

클라우드 아키텍처를 수동으로 검증하는 과정은 굉장히 시간 소모적이고 지루합니다. 하지만 Lucidscale을 활용하면 너무나 간단합니다. 다음의 3단계를 따르세요. 

  1. 데이터 허브로 아키텍처 가져오기 

Lucidscale의 왼쪽 패널로 이동하여 '데이터 가져오기'를 선택해서 클라우드 공급업체 메타데이터를 가져와 현 상태를 정확하게 확인합니다. Lucidscale은 AWS, Azure 및 GCP와 함께 작동합니다. 

  1. Lucidscale에서 새 모델 만들기 

가져온 데이터에서 다이어그램을 자동 생성합니다. 필터를 적용하고, 보기를 맞춤 설정하고, 연결된 리소스를 표시하는 등 다양한 기능을 사용할 수 있습니다.  

클라우드 아키텍처

 

  1. 오리지널 다이어그램과 새로운 모델 비교 

Lucidscale에서 새로운 모델과 사용 중인 다이어그래밍 소프트웨어 내 아키텍처 계획을 비교하세요. Lucidchart는 지능형 다이어그래밍을 위한 탁월한 선택으로, Lucidscale와 Lucidchart는 모두 Lucid 제품군에 속하기 때문에 Lucidscale에서 Lucidchart로 내보내는 과정이 매우 매끄럽습니다. 여러 보기를 사용하여 특정 리소스를 필터링하거나 리소스 그룹에 초점을 맞출 수도 있습니다. 또한 라인을 끄거나 켜서 특정 리소스가 올바르게 연결되었는지 확인할 수도 있습니다. 일치하지 않는 부분이 있다면, 추후에 참조할 수 있도록 하이라이트를 적용하세요.

클라우��드 아키텍처

클라우드 시각화는 Lucidscale로 빠르고 쉽다. 시각화를 시작하려면 오늘 무료 평가판을 시작하십시오.

무료로 가입하기

예시 

Lucid 고객의 사례를 보면 새로운 아키텍처 검증의 중요성을 확인할 수 있습니다. Lucid는 대형 항공사의 클라우드 아키텍처 시각화를 위해 협력하고 있습니다. 해당 항공사는 50개의 아키텍처와 수많은 클라우드 환경을 관리해야 하는 상황이었죠. 

Lucidscale을 사용하기 전, 해당 항공사는 새로운 빌드를 위해 기존에 승인된 템플릿을 가져온 다음, 새로운 아키텍처에 필요한 사항에 따라 템플릿을 변경했습니다. 그런 다음 아키텍처팀이 빌드팀에 설계를 전달했죠. 

이 시점부터 아키텍처팀은 이후의 진행 상황을 알 수 없게 되고, 원래 설계에서 변경된 부분이 있는지 없는지 알 수 없었습니다. 아키텍처팀은 계획이 잘못되었는지 전혀 알 수가 없었습니다. 

이상적인 상황에서는 원래 설계자와 피드백 채널이 존재했을 것입니다. 대부분의 아키텍처에는 설계와 실행 단계 사이에서 변경 사항이 발생하니까요. 피드백 채널이 있는 경우, 설계자는 향후 설계 및 결정을 내릴 때 그동안의 작업 과정을 고려할 수 있게 됩니다. 

이러한 상황은 그리 드물지 않게 발생합니다. 종종 사용자의 팀은 새로운 제품, 기능 또는 고객 베이스 지원을 위해 인프라를 추가하거나 변경해야 하고, 새로운 아키텍처를 생성하기 위한 계획도 이에 따라 변경되게 됩니다. 변경 후 계획은 작업 초기의 계획과 많이 다를 수 있습니다. 최종 실행 단계에서 새로운 아키텍처에 변경 사항이 적용될 경우, 보통 아키텍처팀에서 빌드팀으로 계획이 넘어가는 단계 사이에 다음 두 가지 중 한 가지 상황이 발생합니다. 

  1. 변경되지 말아야 할 것이 변경됩니다. 이 경우, 아키텍처팀에서 변경 사항을 파악할 수 있어야 빌드팀에게 원래 의도대로 계획을 다시 변경해 줄 것을 요청할 수 있습니다. 
  2. 원래 설계에 문제가 있었거나, 더 흔하게는 프로젝트에 변경 및 수정 사항이 발생해, 최종 제품이 원래의 아키텍처 계획과 다르게 빌드되어야 합니다. 이 경우에도 아키텍처팀에게 변경 사항을 알리는 게 중요합니다. 그래야 향후 결정을 내릴 때 이를 고려할 수 있습니다. 향후 프로젝트에서 시간을 절약할 수 있도록 아키텍처팀에서 템플릿을 업데이트하고자 할 수도 있습니다. 

결론

클라우드 인프라는 너무나 쉽게 원래의 아키텍처에서 확장되거나 변경될 수 있으며, 이 때문에 더욱 추적이 어렵습니다. 장기적으로는 이로 인해 계획된 예산보다 더 많은 비용이 소요될 수 있으며, 효율성에 문제가 발생할 수 있습니다.  

클라우드 인프라의 상태를 추적하는 최고의 방법은 시작부터 새로운 클라우드 아키텍처를 검증하는 데 있습니다. Lucidscale과 같은 소프트웨어를 활용하면 현재 상태를 반영해 최신 다이어그램을 생성하고, 아키텍처팀과 빌드팀 사이에 지속적인 피드백 채널을 활성화하는 등 다양한 기능을 통해 검증 과정을 더욱 쉽게 진행할 수 있습니다.


시작하기

  • 가격
  • 개인
  • 영업팀에 문의하기
개인정보 보호정책법률적인쿠키
  • linkedin
  • twitter
  • instagram
  • facebook
  • youtube
  • glassdoor

© 2022 Lucid Software Inc.