소프트웨어 아키텍처 101 내용 중 자율 평가 문제에 대한 제가 생각하는 답을 정리했습니다. 책에서 가르쳐준 내용을 토대로 최대한 정답이라고 생각하는 내용을 적었으나 잘못 정리 했거나 틀린 답을 적었을 수 있습니다. 정리한 내용 중 책의 저작권을 위배하는 사항이 있다면 내용이 수정될 수 있습니다.

1 어떤 속성이 아키텍처 특성이 되려면 충족해야 할 세 기준은 무엇인가요?

• 비도메인 설계 고려 사항을 명시한다.
• 설계의 구조적 측면에 영향을 미친다.
• 애플리케이션 성공에 (절대적으로) 중요하다.

2 암묵적 특성과 명시적 특성의 차이점은 무엇인가요? 각각의 예를 들어보세요.

암묵적 아키텍처 특성은 요구사항 정의서에는 거의 안 나오지만 프로젝트 성공을 위해 꼭 필요한 특성들이다.
예를들어, 가용성, 신뢰성, 보안은 거의 모든 애플리케이션에 필요한 특성이지만 설계 문서에는 잘 등장하지 않는다.

명시적 아키텍처 특성은 요구사항 정의서나 다른 지침서에 기재된다.

3 운영 특성(operational characteristic)의 예를 들어보세요.

특성	설명
가용성	시스템이 얼마나 오랫동안 사용 가능해야 하나?
연속성	재해 복구 능력
성능	스트레스 테스트, 피크 분석, 기능의 사용 빈도 분석, 필요 용량, 응답 시간 등
복구성	장애 발생 시 얼마나 신속하게 시스템을 재가동 시켜야 하나?
신뢰성/안전	시스템에 fail-safe 가 필요한가?
견고성	프로그램 실행 중 인터넷 접속 끊김, 정전, 하드웨어 실패 등 에러 및 경계 조건을 감당하는 능력
확장성	유저 수, 요청 수가 늘어나도 시스템이 그에 맞는 성능을 발휘하는 능력

4 구조 특성(structural characteristic)의 예를 들어보세요.

특성	설명
설정성	최종 유저가 소프트웨어 설정을 쉽게 바꿀 수 있는가?
신장성	새로운 기능을 삽입하는 일의 중요성
설치성	필요한 모든 플랫폼에 시스템을 얼마나 손쉽게 설치할 수 있나?
활용성/재사용	공통 컴포넌트를 여러 제품에서 활용할 수 있나?
지역성	데이터를 입력/조회하는 화면에서 다국어가 지원되는가?
유지보수성	시스템을 얼마나 쉽게 변경/개선할 수 있나?
이식성	하나 이상의 플랫폼에서 시스템을 실행할 수 있나?
지원성	애플리케이션은 어느 정도의 기술 지원을 필요로 하나?
업그레이드성	이 애플리케이션/솔루션의 구 버전을 새 버전으로 쉽고 빠르게 업그레이드 할 수 있는가?

5 공통 특성(cross-cutting characteristic)의 예를 들어보세요.

특성	설명
접근성	색맹, 청각 장애인 등 모든 유저가 접근하는 데 불편함이 없나?
보관성	데이터를 따로 아카이빙 해야하나, 아니면 일정 시간 경과 후 삭제해야 하나?
인증	유저가 본인이 맞다는 것을 증명하기 위해 필요한 보안 요구사항
인가	유저가 애플리케이션에서 정해진 기능만 사용할 수 있도록 강제하는 보안 요구사항
합법성	시스템 운영상 법적 제약조건이 있는가?
프라이버시	회사 내부 임직원의 트랜잭션을 외부에 드러내지 않는 기능
보안	데이터를 암호화 한 후 데이터베이스에 보관해야하나?
사용성/성취성	유저가 애플리케이션/솔루션을 이용하여 원하는 목적을 달성하기 위해 필요한 교육/훈련 수준

참고

• 소프트웨어 아키텍처 101

소프트웨어 아키텍처 101 내용 중 자율 평가 문제에 대한 제가 생각하는 답을 정리했습니다. 책에서 가르쳐준 내용을 토대로 최대한 정답이라고 생각하는 내용을 적었으나 잘못 정리 했거나 틀린 답을 적었을 수 있습니다. 정리한 내용 중 책의 저작권을 위배하는 사항이 있다면 내용이 수정될 수 있습니다.

1. 커네이선스라는 용어는 무엇을 의미하나요?

두 컴포넌트 중 한쪽이 변경될 경우 다른 쪽도 변경해야 전체 시스템의 정합성이 맞는다면 이들은 커네이선스를 갖고 있다고 말할 수 있다.

2. 정적 커네이선스와 동적 커네이선스의 차이점은 무엇인가요?

정적 커네이선스: 소스 코드 레벨의 커플링
동적 커네이선스: 런타임 상황에서 확인할 수 있는 커네이선스

3. 타입 커네이선스는 무엇인가요? 이것은 정적 커네이선스인가요, 아니면 동적 커네이선스인가요?

타입 커네이선스는 정적 커네이선스 중 하나로 여러 컴포넌트의 엔티티 타입이 일치해야 하는것을 뜻한다.

4. 가장 강력한 형태의 커네이선스는 무엇인가요?

동적 커네이선스 중 식별 커네이선스
여러 컴포넌트가 동일한 엔티티를 참조하는 경우에 발생

5. 가장 약한 형태의 커네이선스는 무엇인가요?

정적 커네이선스 중 명칭 커네이선스
여러 컴포넌트의 엔티티명이 일치해야 하는 경우에 발생

6. 정적 커네이선스, 동적 커네이선스 중 코드베이스에서는 어느 쪽이 더 바람직한가요?

정적 커네이선스는 동적 커네이선스에 비해 쉽게 개선할 수 있고 동적 커네이선스는 효과적인 분석 도구가 많지 않아 파악하기 어려우므로 정적 커네이선스가 코드베이스에 더 바람직하다. 그리고 동일한 커네이선스가 널리 흩어져 있는 것 보다는 가까이 붙어 있는것이 더 바람직하다(커네이선스의 지역성). 또한 커네이선스가 미치는 영향의 규모 값(degree)이 작을수록 코드베이스에 바람직하다.

참고

• 소프트웨어 아키텍처 101
• https://connascence.io

소프트웨어 아키텍처 101 내용 중 자율 평가 문제에 대한 제가 생각하는 답을 정리했습니다. 책에서 가르쳐준 내용을 토대로 최대한 정답이라고 생각하는 내용을 적었으나 잘못 정리 했거나 틀린 답을 적었을 수 있습니다. 정리한 내용 중 책의 저작권을 위배하는 사항이 있다면 내용이 수정될 수 있습니다.

아키텍처 대 개발의 기존 접근 방식을 설명하고, 이제는 더 이상 기존 접근 방식이 통하지 않는 이유를 설명하세요.

전통적인 아키텍트의 책임과 개발자의 책임은 다음과 같다. 아키텍트는 비즈니스 요구사항을 분석해서 아키텍처 특성을 도출/정의하고 각종 컴포넌트를 포함한 아티팩트를 만들어 개발팀에 전달 -> 개발팀은 각 컴포넌트의 설계를 하고 코드를 개발/테스트

전통적인 아키텍처 대 개발의 접근 방식은 아키텍트가 내린 결정이 개발팀에서 전혀 쓸모가 없는 경우가 있음에도 불구하고, 개발팀이 아키텍처를 변경하기로 결정한 내용이 다시 아키텍트에게 전달되는 일이 거의 없다.

변화에 둔감하고 융통성 없는 구식 폭포수 모델과 달리, 요즘 시스템 아키텍처는 매 프로젝트 단계마다, 또는 매 이터레이션마다 끊임없이 변화하고 발전하기 때문에 프로젝트를 성공으로 이끌려면 아키텍트와 개발팀이 모두 활발히 소통하고 프로젝트 생명 주기의 일부로서 항상 서로 동기화 되어야 한다.

지식 피라미드의 세 레벨의 지식을 열거하고 각각의 예를 들어보세요.

지식 피라미드의 세 레벨 (나의 예)

1. 내가 알고 있는 것 (스프링 웹 백엔드 개발, 클라우드 서비스 활용 웹 개발 등)
2. 내가 모른다는 사실을 아는 것 (NoSQL, 최신 프론트 웹 개발 등)
3. 내가 모른다는 사실조차 모르는 것 (열거할 수 없음)

아키텍트에게는 왜 기술의 깊이보다 폭에 집중하는 것이 더 중요한가요?

아키텍트는 기술적인 제약 하에 어떤 기능이 가장 알맞는지 결정해야 하므로 아주 폭넓은 솔루션을 두루 꿰고 있어야 한다.

아키텍트로서 기술 깊이를 유지하고 실무 능력을 잃지 않으려면 어떻게 해야 하나요?

1. 개념 증명(Proof of Concept)을 자주 해본다.
2. 중요한 유저 스토리 작업은 개발팀에 맡기고 기술 부채 스토리나 아키텍처 스토리에 전념한다.
3. 이터레이션 동안 버그를 잡는다.
4. 간단한 커맨드라인 도구나 분석기를 만들어 개발팀의 일상 업무를 간소화, 자동화 한다.
5. 아키텍처의 컴플라이언스 보장을 자동화하기 위한 피트니스 함수를 만든다.
6. 자주 코드리뷰를 한다.

참고

• 소프트웨어 아키텍처 101, 한빛미디어

소프트웨어 아키텍처 101 내용 중 자율 평가 문제에 대한 제가 생각하는 답을 정리했습니다. 책에서 가르쳐준 내용을 토대로 최대한 정답이라고 생각하는 내용을 적었으나 잘못 정리 했거나 틀린 답을 적었을 수 있습니다. 정리한 내용 중 책의 저작권을 위배하는 사항이 있다면 내용이 수정될 수 있습니다.

소프트웨어 아키텍처를 정의하는 네 차원은 무엇인가요?

1. 아키텍처 특성(architecture characteristic)
   시스템의 기능과 직교하는 시스템의 성공 기준
   시스템이 지원해야 하는 ‘~성’ 들 (ex: 가용성, 신뢰성, 시험성, 확장성, 보안, 민첩성 등)
2. 아키텍처 결정(architecture decision)
   시스템 구축에 필요한 규칙들
   시스템의 제약조건을 형성, 개발자가 해도 되는 것과 하지 말아야 할 것을 알려줌
3. 설계 원칙(design principle)
   소프트웨어의 조건과 구현 방안에 대한 가이드라인
   (ex: 마이크로서비스 아키텍처의 성능 향상을 위한 서비스 간 통신은 비동기 메시징을 활용해야함)
4. 구조(structure)
   시스템이 구현된 아키텍처 스타일(들)의 종류
   (ex: 마이크로서비스, 레이어드, 마이크로커널 등)

아키텍처 결정과 설계 원칙은 어떤 차이점이 있나요?

아키텍처 결정이 반드시 지켜야 할 규칙이라면 설계 원칙은 가이드라인
소프트웨어의 모든 조건과 구현 방안을 아키텍처 결정(규칙)으로 다룰 수는 없기에 권장하는 방법에 관한 가이드를 설계 원칙으로 제공

소프트웨어 아키텍트의 8대 핵심 기대치를 나열하세요

1. 아키텍처 결정을 내린다.
   아키텍트는 기술 선택을 가이드 하는 사람이지 정해주는 사람이 아니다.
2. 아키텍처를 지속적으로 분석한다.
   ex: 3년 이전에 정의한 아키텍처가 지금도 얼마나 현실성 있는지 평가
3. 최신 트렌드를 계속 유지한다.
   항상 최신 기술과 업계 트렌드를 따라가야 함
4. 아키텍처 결정의 컴플라이언스를 보장한다.
   아키텍트가 정의하고 문서화하여 전달한 아키텍처 결정과 설계 원칙들을 개발팀이 제대로 준수하고 있는지 지속적으로 확인
5. 다양한 기술과 경험에 노출된다.
   유능한 아키텍트는 여러가지 언어, 플랫폼, 기술을 경험할 기회를 적극적으로 모색하면서 기술의 깊이보다는 폭에 초점을 둔다.
6. 비즈니스 도메인 지식을 보유한다.
   비즈니스 도메인 지식이 없으면 비즈니스의 문제점, 목표, 요구사항을 이해하기 어렵고, 따라서 비즈니스 요구사항을 수용할 만한 효율적인 아키텍처를 설계하기도 어려움.
7. 대인 관계 기술이 뛰어나다.
   아키텍트는 개발팀을 기술적으로 이끌기만 하는 사람이 아니라, 개발팀을 리드해서 아키텍처를 구현하는 사람이므로 직책 또는 역할과 상관 없이, 리더십 스킬은 아키텍트로서 성공하기 위해 필수 요구사항의 절반 이상은 차지함.
8. 정치를 이해하고 처세를 잘한다.
   아키텍트가 내린 거의 모든 결정은 사람들의 반발에 부딪히게 마련이다. 따라서 대부분의 결정을 사람들이 수용하도록 기본적인 협상 기술을 발휘해야 함.

소프트웨어 아키텍처 제1법칙은 무엇인가요?

소프트웨어 아키텍처의 모든 것은 다 트레이드오프다.

참고

소프트웨어 아키텍처 101