소개
작성일 : 2023년 07월 20일 (Thursday)
Table of contents
오늘 날, 우리가 사용하고 있는 프로그램들은 단순히 프로그래머들만 참여해서 만들어진 결과물이 아니다. 비단 현재 뿐만 아니고 사실 과거도 그랬다. 하지만 과거와 현재의 프로그램 복잡도는 확연히 다르다. 예시로, 최초의 검색엔진 Archie와 현재의 Naver 메인화면을 비교해보자.
보면 알겠지만, 한눈에 봐도 프로그램의 복잡도가 다르다는 것이 보인다. 네이버 메인화면을 보면 검색란 외에 뉴스, 광고, 날씨, 그리고 여러가지 서비스로 연결되는 링크들이 포함된 것을 알 수 있다. 위 화면은 만들려면 많은 업체들의 이해관계자들과 네이버 리드 아키텍트 (+시니어 아키텍트) 등 관련 담당자들 간 수 차례의 협의 끝에 정해진 내용을 바탕으로 네이버 개발자들이 힘쓴 결과물이라 할 수 있다. 근데, 방송사 관계자들이나 마케터들이 개발자들과 직접 소통하여 원하는 것을 만들어 낼 수 있을까?
아키텍처의 필요성
다수가 참여하는 프로젝트일 수록 모두가 이해할 수 있는 큰 그림이 중요하다. 모두가 합의할만한 큰 그림이 없이는 모두가 원하는 결론에 도달할 수 없다. 여러 이해당사자들의 니즈를 한 눈에 볼 수 있도록 하는 것이 바로 아키텍처이다. 고객의 니즈를 충족시키는 프로그램 개발시의 어려움 등 역시 다뤄야 한다.
아키텍처 드라이버
이해당사자들의 니즈, 어려움(제한사항) 등 아키텍처 설계에서 주요 인자로 사용되는 항목들을 아키텍처 드라이버 라고 한다.
아키텍처 드라이버의 예시로 기능요구사항, 성능, 신뢰성, 변화용이성, 가용성 등이 존재한다.
좋은 아키텍처는 모든 이해당사자들이 보고 이해할 수 있고, 또 그 모든 당사자들의 니즈, 그리고 한계점을 모두 담아낸 아키텍처이다. 좋은 아키텍처를 설계하는 방법은 이미 널리 사용되고 있는 전략 패턴(스타일)을 최대한 적용하면서 각 이해당사자들/담당자들과 균형적으로 지속적인 소통을 하는 것이다. 좋은 설계를 하기 위해서는 아키텍트는 고객과 개발자의 중간에서 의견을 조율해주는 중재자의 역할을 잘 수행해야 한다. 콘웨이의 법칙에 따르면 개발조직은 아키텍처의 소통 구조를 많이 닮기 때문에 아키텍처를 사전에 잘 설계하는 것이 매우 중요하기 때문에 (이론은 제쳐두고 현실이 그렇다.) 아키텍트는 다른 업무를 병행하지 않고 아키텍트 업무만 집중하는 것이 좋다.
콘웨이의 법칙 (Conway’s law)
시스템 구조는 설계하는 조직의 커뮤니케이션 구조를 닮게 된다는 법칙. (참조 : 제타위키)
대립되는 요소 사이의 균형 (Trade-off) 조절
하지만 아무리 좋은 아키텍처를 만들려고 하더라도 결국에는 이해당사자들의 요구사항들이 서로 충돌하여 어느 정도 의견 조율이 필요하게 되고, 의견 조율이 잘 마무리되었다고 하더라도 실제 기술적인 한계(Constraint)를 고려하여 Trade-off 설계를 진행해야 한다.
▶ 포스트
