소프트웨어 아키텍처란?

소프트웨어 아키텍처 프로세스에서는 고객 요구 사항을 수집 및 분석하고 이러한 요구 사항을 충족하는 소프트웨어의 설계를 만듭니다. 성공적인 소프트웨어 설계는 상충하는 요구 사항으로 인해 발생하는 필연적인 타협점 간의 균형을 맞추고, 오랜 시간에 걸쳐 발전한 설계 원칙과 실행 기법을 준수하고, 최신 하드웨어, 네트워킹 및 관리 시스템을 보완해야 합니다. 강력한 소프트웨어 아키텍처에는 이론 및 실무 주제에 대한 풍부한 경험과 막연한 비즈니스 시나리오 및 요구 사항을 구체적이고 실용적인 설계로 변환하는 데 필요한 비전이 필요합니다.

소프트웨어 아키텍처에는 모든 기술 및 운영 요구 사항을 충족하는 구조화된 솔루션을 정의하고 성능, 보안, 관리 효율성과 같은 일반적인 품질 특성을 최적화하는 작업이 포함됩니다. 여기에는 광범위한 요소를 기반으로 한 일련의 의사 결정이 필요하며, 이러한 각 의사 결정은 소프트웨어의 품질, 성능, 관리 효율성 및 전체적인 성공에 큰 영향을 미칠 수 있습니다.

근래의 소프트웨어는 독립적으로 실행되는 경우는 거의 없습니다. 대부분의 경우 최소한 소프트웨어 사용자가 작업하는 데 필요한 정보를 제공하는 회사 데이터베이스와 같은 데이터 원본과 상호 작용합니다. 또한 일반적으로 현대 소프트웨어는 다른 서비스 및 네트워크 기능과 상호 작용하여 인증을 수행하고 정보를 획득 및 게시하고 통합 사용자 환경을 제공합니다. 적절한 아키텍처가 없는 경우 소프트웨어를 배포, 운영, 유지 관리하고 다른 시스템과 성공적으로 통합하기가 어렵거나 불가능할 수 있으며 사용자 요구 사항을 충족할 수 없게 됩니다.

소프트웨어 아키텍처는 소프트웨어가 달성해야 하는 목표와 코드로서의 구현 세부 사항을 연결하는 것이라고 생각할 수 있습니다. 올바른 아키텍처를 확보하면 요구 사항과 결과물 간의 연결을 최적화할 수 있습니다. 잘 설계된 소프트웨어는 원래 요구 사항의 매개 변수 내에서 지정된 작업을 수행하며 이 과정에서 성능, 보안, 안정성 등을 최대화합니다.

최상위 수준의 아키텍처 설계는 시스템 구조를 노출하되 구현 세부 사항은 숨기고, 모든 사용 사례와 시나리오를 실현하고, 모든 관계자의 요구 사항을 처리하도록 노력하고, 모든 기능 및 품질 요구 사항을 최대한 충족해야 합니다.

소프트웨어 아키텍처가 왜 중요한가?

응용 프로그램에 대한 사용자의 기대가 커지면서 현재 소프트웨어에 대한 요구 사항도 더 복잡해지고 있습니다. 이제 대부분의 비즈니스 및 상업 시나리오에서 간단한 독립 실행형 데스크톱 응용 프로그램은 부족하게 되었습니다. 현재의 연결된 환경에서 응용 프로그램은 다른 응용 프로그램 및 서비스와 상호 작용하고 클라우드 및 휴대용 장치와 같은 다양한 환경에서 실행되어야 합니다. 과거에 일반적으로 사용된 모놀리식 설계는 프레임워크, 운영 체제, 런타임 호스트 및 네트워크를 사용하여 불과 몇 년 전까지만 해도 없었던 새로운 기능을 구현하는 구성 요소화된 서비스 지향 소프트웨어로 대체되었습니다.

이 복잡성은 설계뿐만 아니라 소프트웨어 배포, 유지 및 관리에도 영향을 미칩니다. 소프트웨어의 TCO(총 소유 비용)는 이제 대부분 배포 후 비용으로 구성됩니다. 잘 설계된 응용 프로그램은 응용 프로그램을 배포하고 실행 상태를 유지하고 변화하는 요구 사항을 총족하도록 업데이트하고 문제를 해결하는 데 필요한 비용과 시간을 줄임으로써 TCO를 최소화합니다. 또한 사용자 지원 및 관리도 간소화합니다.

성공적인 소프트웨어가 되려면 여러 가지 필수적인 기준도 충족해야 합니다. 악의적인 공격과 우연한 잘못으로부터 응용 프로그램과 데이터를 보호할 수 있는 보안 기능을 제공해야 합니다. 오류 및 이와 관련된 비용이 최소화되도록 견고하고 안정적이어야 합니다. 최대 응답 시간 또는 특정 작업 부하 용량과 같은 고객의 요구 사항을 충족하기 위해 필요한 매개 변수 내에서 기능을 수행해야 합니다. 관리 및 지원 비용을 최소화하기 위해 유지 관리가 용이해야 하며, 시간이 경과함에 따라 필요한 변경 및 업그레이드가 가능하도록 충분한 확장성을 갖추어야 합니다.

이러한 모든 요소에는 절충이 수반됩니다. 예를 들어 복잡한 암호화를 통해 가장 안전한 메커니즘을 구현하면 성능은 떨어지게 됩니다. 광범위한 구성 및 업그레이드 옵션을 구현하면 배포 및 관리 작업이 더 복잡해질 수 있습니다. 또한 설계가 복잡할수록 구현 비용도 많이 듭니다. 좋은 아키텍처는 이러한 요소들 간에 균형을 맞추어 특정 시나리오에 대한 최적의 결과를 얻는 것을 목표로 해야 합니다.

소프트웨어 아키텍처는 어떤 역할을 하는가?

소프트웨어 아키텍처의 시작은 요구 사항 집합입니다. 이러한 요구 사항은 다이어그램, 프로세스 순서도, 모델 또는 소프트웨어가 수행해야 하는 운영 작업의 문서화된 목록 형태로 표현됩니다. 일반적으로 고객 또는 파트너는 모양과 느낌 또는 일반적인 작업에 대한 특정 사용자 인터페이스의 작동 방식과 같이 명확하지 않은 요구 사항도 제시합니다. 요구 사항에는 새 소프트웨어가 상호 작용할 기존 소프트웨어, 시스템, 하드웨어 및 네트워크에 대한 정보와, 배포 및 유지 관리 계획, 그리고 물론 프로젝트에서 사용할 수 있는 예산과 같은 다른 요소도 포함되어야 합니다.

소프트웨어 설계자는 고객의 요구를 고려해야 합니다. 그러나 “고객”이라는 일반적인 용어는 일반적으로 비즈니스 요구 사항, 사용자 요구 사항, 시스템 요구 사항이라는 세 가지 상충하는 책임 영역으로 구성됩니다. 비즈니스 요구 사항은 일반적으로 비즈니스 프로세스, 성능 요소(예: 보안, 안정성 및 처리량), 그리고 예산 및 비용 제약과 같은 요소를 정의합니다. 사용자 요구 사항에는 소프트웨어 인터페이스 디자인, 운영 기능 및 사용 편의성이 포함됩니다. 시스템 요구 사항에는 하드웨어, 네트워킹 및 런타임 환경 기능과 제약이 포함됩니다. 그림 1은

그림 1 - 일반적인 고객의 상충하는 요구 사항

소프트웨어 설계자에게는 요구 사항을 수집 및 분석하고 아키텍처를 정의하기 위한 자기만의 방법이 있습니다. 설계자는 흔히 “사용자는 어떤 방법으로 응용 프로그램을 사용하게 되는가?”, “응용 프로그램이 프로덕션과 관리 환경에 어떻게 배포되는가?”, “보안, 성능, 동시성, 국제화 및 구성과 같은 응용 프로그램의 품질 특성 요구 사항은 무엇인가?”, “시간이 지나도 유연하고 유지 관리가 가능하도록 응용 프로그램을 설계하려면 어떻게 해야 하는가?” 그리고 “지금 또는 배포된 후 응용 프로그램에 영향을 미칠 수 있는 아키텍처 추세는 무엇인가?”와 같은 질문의 답을 구해야 합니다.

마지막 질문은 흥미로우면서도 중요합니다. 좋은 소프트웨어 설계는 고객의 현재 요구 사항뿐만 아니라 가까운 미래의 요구 사항도 지속적으로 충족합니다. 이는 하드웨어, 구성 요소, 프레임워크, 런타임 플랫폼, 관리 소프트웨어 시스템 및 소프트웨어에 내장되거나 소프트웨어가 통합해야 하는 기타 다양한 기능에 대해 설계자가 내려야 하는 의사 결정에 영향을 미칩니다.

소프트웨어 설계 및 개발 영역의 작업이 대부분 그렇듯이, 아키텍처를 설계하는 일은 선행적이고 반복적인 프로세스입니다. 요구 사항 분석, 기술 연구, 목표 식별과 같은 많은 초기 작업은 일반적으로 프로세스의 시작 부분에서 수행됩니다. 다음 단계는 설계에 대한 주요 시나리오를 확인하는 것입니다. 이는 소프트웨어가 충족해야 하는 기본 요구 사항이자 소프트웨어 운영의 제약 조건이기도 합니다. 설계자는 이 정보를 통해 응용 프로그램의 개요를 도출할 수 있습니다. 이 개요에는 응용 프로그램 유형(웹, 폰, 데스크톱 또는 클라우드), 배포 아키텍처(일반적으로 구성 요소들이 하드웨어와 네트워크 경계를 넘어 통신하는 계층화된 설계), 추종할 적절한 아키텍처 스타일(예: n계층, 클라이언트/서버, 또는 서비스 지향), 그리고 시나리오에 가장 잘 맞는 구현 기술과 같은 전체적인 세부 사항이 포함됩니다.

여기서 설계자는 앞서 파악한 최상위의 가장 중요한 요구 사항을 충족하는 후보 설계들을 생성할 수 있습니다. 이 설계를 많은 경우 고객 및 평가판 또는 테스트 버전의 피드백과 함께 주요 시나리오에 따라 검토 및 테스트해서 최적의 솔루션을 제공하는지 확인합니다. 첫 번째 반복에서 되지 않더라도 주기가 반복됨에 따라 설계는 요구 사항 및 주요 시나리오를 기반으로 수렴하게 됩니다. 그림 2는 이 반복 접근 방식을 보여 줍니다.

그림 2 – 반복적인 아키텍처 설계 프로세스

설계가 세밀해지고 개별 작업 및 구성 요소가 식별됨에 따라 설계자는 각 단계에서 설계를 더 정제하고 세부 사항을 추가할 수 있습니다. 예를 들어 아키텍처 스타일과 배포 접근 방식이 식별되면 설계자는 계층과 구성 요소 간의 통신에 대한 의사 결정을 내릴 수 있습니다. 여기에는 현재 및 미래 요구 사항을 기반으로 프로토콜을 선택하고, 앞으로 나올 표준에 정의된 새로운 기술과 기능을 사전에 검토하는 작업이 포함될 수 있습니다.

설계자 작업의 최종 결과물은 일반적으로 여러 관점에서 응용 프로그램을 정의하는 설계도, 모델 및 문서 집합입니다. 이러한 요소들이 결합되면 개발자, 테스트 팀, 관리자 및 경영진에게 설계를 구현하는 데 필요한 모든 정보가 제공됩니다. 이 정보에는 구성 요소와 응용 프로그램 계층의 구조 및 레이아웃에 대한 설명, 로깅 및 유효성 검사와 같은 크로스 커팅(Cross-Cutting) 사안이 처리되는 방법, 테스트 및 배포 계획, 개발자, 관리자 및 지원 담당자를 지원하기 위한 문서가 포함됩니다.

최종 설계는 응용 프로그램이 충족해야 하는 품질 특성도 지정해야 합니다. 이는 설계자가 고객과 상담하면서 내린 신중한 의사 결정과 타협의 결과입니다. 여기에는 보안 요구 사항과 보안 구현 계획, 대상 플랫폼에 배포될 경우 필요한 확장성과 성능, 유지 관리 용이성과 확장성이 구현되는 방식, 다른 시스템과의 상호 운용성을 가능하게 하는 기능에 대한 정의가 포함됩니다.

소프트웨어 설계자에게 필요한 기술은 무엇인가?

소프트웨어 설계자에게 다양한 소프트 스킬과 하드 스킬이 모두 필요하다는 것은 분명합니다. 요구 사항 분석 및 검토 단계에서 설계자는 고객과 협력하고 파트너 및 다른 팀 구성원과 상담하고 관리자, 사용자 및 시스템 관리자 사이의 중개자 역할을 해야 합니다. 이러한 소프트 스킬이 뛰어나면 더 나은 초기 계획과 더 정확한 요구 사항 집합을 만들 수 있으므로 이후 시간과 노력을 덜 수 있습니다.

소프트웨어 설계자는 최신 소프트웨어 시스템, 프레임워크 및 하드웨어가 요구 사항에 대응하는 방식, 네트워킹 및 운영 체제 요소가 설계 의사 결정에 미치는 영향, 이러한 영역의 추세와 변화가 설계에 미칠 영향을 이해하기 위해 필요한 하드 스킬도 갖추어야 합니다. 초기 요구 사항 분석 후 소프트웨어 설계자는 설계 패턴, 통신 및 메시징 표준, 코드 기능, 보안 관련 사항과 성능 제약에 대한 하드 스킬도 적용해야 합니다. 이러한 모든 요소에는 최종 소프트웨어를 구현하는 데 사용될 기술에 대한 풍부한 지식이 필요합니다.

물론 소프트웨어 아키텍처에는 비전도 필요합니다. 설계자는 여러 시스템이 연계되어 상호 운용되는 방법, 이러한 시스템이 분할 및 배포되는 방법, 그리고 사용자와 시스템이 상호 작용하는 방법을 파악하려면 먼저 전체적인 솔루션을 마음 속에 그릴 수 있어야 합니다. 그렇게 하기 위해서는 모든 요구 사항과 제약을 대조 및 파악하고, 유연하고 포괄적인 기술 설계에서 이러한 요소들을 점진적으로 변형시켜 나가기 위한 체계적인 접근 방법과 세부 사항에 대한 세심한 주의가 필요합니다. 또한 최종 결과를 시각화한 다음 이상적인 솔루션을 향해 조직적으로 작업해 나갈 수 있는 직감과 상상력도 필요합니다.