Introduction to software architecture - 소프트웨어 아키텍쳐 기초

hyperskill - Introduction to software architecture 영어 원문

여러 컴포넌트를 결합하는 복잡한 어플리케이션을 위한 개발 사이클의 시작 부분에서,

당신은 내부에서 일어나는 모든 상호작용들을 표현하는 적절한 구조를 가져야 한다는 것을 알아챘을 겁니다.

Software architecture(소프트웨어 아키텍처) 는 이러한 구조를 정의하는 용어입니다.

이는 각각의 주요한 시스템 컴포넌트 사이의 관계를 이해하는 데 도움을 주고,

동시에 개발자와 클라이언트를 위해 중요한 문서를 제공합니다.

여러개의 서로 다른 컴포넌트들을 결합하는 각각의 프로젝트는

시스템을 위해 필요한 기술적 구조적 필요사항들을 정의하기 위해 명확한 소프트웨어 아키텍처를 가집니다.

이러한 소프트웨어 아키텍쳐는 프로젝트를 생성할 때 일어날 수 있는 리스크들을 줄일 수 있게 해 줍니다.

만약 당신이 프로젝트를 완수해야 하거나, 짧은 시간에 팀 내에서 커뮤니케이션을 세워야 한다면,

소프트웨어 아키텍처를 마스터해야 합니다.

What is software architecture? - 소프트웨어 아키텍처란?

---

예를 들어, 당신은 새로운 어플리케이션을 개발하고 싶은데,

이 어플리케이션은 당신이 원하는 무엇이던 잠재적으로 수행 할 수 있습니다.

당신이 할 첫 번째 행동은 무엇일까요?

당신의 대답은,

"나의 어플리케이션을 여러 컴포넌트들로 분할하고, 문서를 작성하며, 내부의 모든 커넥션들의 스키마를 그려야 한다"

가 되어야 합니다.

기본적으로, software architecture (SA) 는 패턴이며,

시스템의 모든 내부 컴포넌트들을 묘사하며, 이들 간의 상호작용들을 묘사합니다.

이는 당신이 직접과 간접으로서 분류할 수 있는 영향력의 구체들을 가지고 있습니다.

직접 영향을 미침으로서, 당신은 프로젝트에서 어떠한 변화던 만들 수 있습니다.

보안 혹은 품질 속성들의 향성점이나, 프로젝트 구조의 최적화던가,

기술을 사용함에 있어 영향을 미치는 어떠한 점 과 비슷합니다.

Indirect influence (간접 영향) 이 의미하는 것은,

프로젝트의 환경이 변화한다는 것을 의미합니다.

밑에 있는 그래프로 당신이 볼 수 있는 것은, 분류가 어떻게 될 수 있는가입니다.

SA 즉, 소프트웨어 아키텍처는 프로젝트의 구조, IT 환경, 품질 속성 에 직접적인 영향을 끼칩니다.

반면에, 간접 영향은 인간 역학 과 비즈니스 전략 을 포함합니다.

flowchart TB

Software("Software Architecture\n 소프트웨어 아키텍쳐")

Software --> Direct("Direct Influence\n 직접적 영향")

Software --> Indirect("Indirect Influence\n 간접적 영향")

Project("Project Structure\n 프로젝트 구조")
IT("IT Environment\n IT 환경")
Quality("Quality Attributes\n 품질 속성")

Direct --> Project
Direct --> IT
Direct --> Quality

Human("Human Dynamics\n 인간 역학")
Business("Business Strategy\n 비즈니스 전략")

Indirect --> Human
Indirect --> Business

Why would you need software architecture? - 소프트웨어 아키텍처는 왜 필요할까?

---

복잡한 프로젝트를 작업하고 있을 때,

개발자들은 그들이 무엇을 수행하고 있는지, 그 다음은 무엇을 수행하는지, 마지막에는 무엇을 얻는지 추정하게 되는지,

이해하기 위해 필요합니다.

시스템 내의 모든 연결을 묘사하는 아키텍처적인 패턴은,

개발자들이 그들의 프로젝트를 이해하고 워크플로우를 조정하는 데 도와줄 수 있습니다.

여기 소프트웨어 아키텍쳐에 대한 장점을 나열했습니다 :

• 자세한 것을 구현하지 않고, 간단한 방식으로 시스템을 설명합니다.
• 모든 작업 시나리오들을 표시합니다.
• 기능적, 품질적 필요사항들을 구별합니다.
• 작업 환경, 비즈니스 환경을 향상시킵니다.

만약 당신이 SA 의 요소들 사이에서 기능들을 적절히 분배한다면,

당신은 새로운 기능들을 구현하고 있는 개발자들을 위해 잠재적으로 시간을 아낄 수 있습니다.

또한, 이는 새로운 팀 멤버들을 위해 워크플로우를 조정하는 데 더 쉬울 겁니다.

그럼 다시 돌아와서, 소프트웨어 아키텍처를 생성하는 것은 실제적인 차이점을 만들어 낼 수 있음에도 불구하고,

항상 적절한 것 만은 아닙니다.

따라서 우리는 SA 를 표현하는 메서드의 부족을 경험하며,

SA의 우선순위에 차질을 경험합니다.

Types of software architecture

---

항상 전적으로 고유한 소프트웨어 아키텍쳐를 생성 할 필요는 없습니다.

왜냐하면 최적화 된 솔루셔ㄴ들로서 흔하게 문제들을 일으키는 서로 다른 패턴 유형들이 많기 때문입니다.

Layered, Primary-Secondary, Peer-to-Peer 과 같은 적은 유형의 패턴들도 있습니다.

당신은 이런 패턴들을 미래의 주제에서 더 배울 겁니다.

어떠한 패턴이던지 표현하기 위해서,

당신은 스키마, 모델, 다이어그램, 심지어는 모든 아키텍처 결정들을 모은 문서를 사용할 수 있어야 합니다.

Architecture Desision Record : ADR

또한, 당신은 SA를 모델링 언어, 혹은 UML을 통해 시각화할 수 있습니다.

UML은 시각 언어로 독립적인 목적을 위한 서로 다른 유형의 다이어그램들을 통합하는 시각 언어입니다.

더 나은 이해를 위해서, 여기 몇 가지 기본적인 유형의 소프트웨어 아키텍처의 목록이 있습니다 :

Application architecture - 어플리케이션 아키텍처

어플리케이션을 만들기 위해 필요한 패턴들의 설명입니다.

이 유형의 아키텍처는 잘 구조화된 앱을 만들기 위한 로드맵을 팀에게 제공합니다.

Information architecture - 정보 아키텍처

컨텐츠 조직, 구조, 라벨링에 대한 설명입니다.

이는 유저들이 그들이 필요한 정보에 편하게 접속할 수 있게 해 주는 방식을 설명합니다.

Database architecture - 데이터베이스 아키텍처

데이터베이스 관리 시스템 (DBMS) 의 디자인, 개발, 구현, 유지보수의 개념에 집중되어 있습니다.

간단히 말해, 이는 데이터베이스를 인지하고 지원하는 데 필요한 모든 단계들을 설명하는 아키텍처이며,

유저들과 관리자들에게 기능에 접근하기 위한 적절한 권한을 줍니다.

Network architecture - 네트워크 아키텍처

네트워크 시스템의 물리적, 논리적 디자인의 설명입니다.

기본적으로, 네트워크 컴포넌트들 간의 관계를 묘사하거나,

그들의 논리적 기능들을 설명합니다.

Conclusion - 결론

---

소프트웨어 아키텍처 (SA) 는 IT 와 IT를 표현하는 방식의 지식이 결합된 복잡한 개념입니다.

프로젝트에 대해 소프트웨어 아키텍처를 가지는 것은 몇 가지 혜택을 제공하는데,

문서를 작성하거나, 계획하는 것은 개발자들이 공통적인 목표를 향해 작업하는 것을 돕습니다.

소프트웨어 아키텍처를 생성함으로서, 미래의 시간을 잠재적으로 줄을 수 있으며,

당신의 프로젝트가 핵심 부분에 견고한 구조를 가진다는 것을 확실히 합니다.

words to remember

---

potentially : 잠재적으로

Direct : 직접 <==> Indirect : 간접

encompass : 에어 싸다, 둘러싸다, 포함하다

depict 묘사하다, 서술하다