소프트웨어 아키텍처 101 내용 중 자율 평가 문제에 대한 제가 생각하는 답을 정리했습니다. 책에서 가르쳐준 내용을 토대로 최대한 정답이라고 생각하는 내용을 적었으나 잘못 정리 했거나 틀린 답을 적었을 수 있습니다. 정리한 내용 중 책의 저작권을 위배하는 사항이 있다면 내용이 수정될 수 있습니다.
아키텍처 대 개발의 기존 접근 방식을 설명하고, 이제는 더 이상 기존 접근 방식이 통하지 않는 이유를 설명하세요.
전통적인 아키텍트의 책임과 개발자의 책임은 다음과 같다. 아키텍트는 비즈니스 요구사항을 분석해서 아키텍처 특성을 도출/정의하고 각종 컴포넌트를 포함한 아티팩트를 만들어 개발팀에 전달 -> 개발팀은 각 컴포넌트의 설계를 하고 코드를 개발/테스트
전통적인 아키텍처 대 개발의 접근 방식은 아키텍트가 내린 결정이 개발팀에서 전혀 쓸모가 없는 경우가 있음에도 불구하고, 개발팀이 아키텍처를 변경하기로 결정한 내용이 다시 아키텍트에게 전달되는 일이 거의 없다.
변화에 둔감하고 융통성 없는 구식 폭포수 모델과 달리, 요즘 시스템 아키텍처는 매 프로젝트 단계마다, 또는 매 이터레이션마다 끊임없이 변화하고 발전하기 때문에 프로젝트를 성공으로 이끌려면 아키텍트와 개발팀이 모두 활발히 소통하고 프로젝트 생명 주기의 일부로서 항상 서로 동기화 되어야 한다.
지식 피라미드의 세 레벨의 지식을 열거하고 각각의 예를 들어보세요.
지식 피라미드의 세 레벨 (나의 예)
- 내가 알고 있는 것 (스프링 웹 백엔드 개발, 클라우드 서비스 활용 웹 개발 등)
- 내가 모른다는 사실을 아는 것 (NoSQL, 최신 프론트 웹 개발 등)
- 내가 모른다는 사실조차 모르는 것 (열거할 수 없음)
아키텍트에게는 왜 기술의 깊이보다 폭에 집중하는 것이 더 중요한가요?
아키텍트는 기술적인 제약 하에 어떤 기능이 가장 알맞는지 결정해야 하므로 아주 폭넓은 솔루션을 두루 꿰고 있어야 한다.
아키텍트로서 기술 깊이를 유지하고 실무 능력을 잃지 않으려면 어떻게 해야 하나요?
- 개념 증명(Proof of Concept)을 자주 해본다.
- 중요한 유저 스토리 작업은 개발팀에 맡기고 기술 부채 스토리나 아키텍처 스토리에 전념한다.
- 이터레이션 동안 버그를 잡는다.
- 간단한 커맨드라인 도구나 분석기를 만들어 개발팀의 일상 업무를 간소화, 자동화 한다.
- 아키텍처의 컴플라이언스 보장을 자동화하기 위한 피트니스 함수를 만든다.
- 자주 코드리뷰를 한다.
