⌜ 아키텍쳐(Architecture)란? ⌟ 영단어로는 ‘건축학’ 이라는 뜻으로 '하나의 서비스가 어떻게 구성되며 어떻게 동작이 된다'를 표현하는 것이라고 볼 수 있으며 시스템의 구조, 동작 등을 정의하는 개념적인 모형으로 시스템의 목적을 달성하기 위해 시스템의 각 컴포넌트가 무엇이며 어떻게 상호작용 하는지, 정보가 어떻게 교환되는 지를 설명한다.
∙시스템 구성 및 동작 원리를 나타내는 것 ∙구성 요소 간의 관계 및 시스템 외부 환경과의 관계를 묘사하는 것 ∙시스템 구성 요소에 대한 설계 및 구현을 지원하는 수준을 기술하는 것 ∙요구 사양 및 시스템 수명 주기를 고려하는 것 ∙시스템의 전체적인 최적화를 목표로 하는 것
위의 소프트웨어 기능의 고도화 그래프를 통해 확인할 수 있듯이 좋지 않은 디자인을 가진 소프트웨어는 시간이 지날수록 기능을 추가하는 것이 어려워지는 반면, 좋은 디자인을 가진 소프트웨어는 소프트웨어의 컴포넌트화가 잘 되어 있기 때문에 기능을 추가하기 수월하다.
즉, 더 나은 내부 퀄리티를 가진 소프트웨어를 고른다면 추후엔 새로운 기능을 더 빠르게 많이 추가할 수 있게 되고 내부 퀄리티가 낮은 제품은 문제 사항에 대한 빠른 개선이 불가능하게 된다는 것이다.
결국 아키텍처는 '구조화 과정의 시작이자 기준'이라고 할 수 있으며 변화에 저항하기 위해 만드는 것이 아닌, 변화에 능동적으로 대응할 수 있는 미래를 위해 만드는 것이다.
⌜ 언제 필요한가?⌟
아키텍처라는 것은 일반적으로는 서비스의 설계를 의미하지만 개발자들 사이에서는 각 플랫폼에 맞는 설계를 말한다. 따라서 서비스에 맞는 설계 속에서 각 플랫폼에 맞는 설계(아키텍처)를 구현해야 하며 이미 결정한 언어의 한계 때문에 전체 코드를 다른 언어로 바꿔야하는 경우가 생기면 안되기에 아키텍처 설계는 반드시 프로젝트가 시작되기 전에 우선적으로 진행되어야 한다.
아키텍처의 설계 과정은 설계 목표 설정-시스템 타입 결정-아키텍처 패턴 적용-서브시스템 구체화-검토 순으로 진행된다. 1. 설계 목표 설정 : 시스템의 개발 방향을 명확히 하기 위해 설계에 영향을 주는 비즈니스 목표, 우선순위 등의 요구사항을 분석하여 전체 시스템의 설계 목표를 설정 2. 시스템 타입 결정: 시스템과 서브시스템의 타입을 결정하고, 설계 목표와 함께 고려하여 아키텍처 패턴을 선택 3. 아키텍처 패턴 적용 : 아키텍처 패턴을 참조하여 시스템의 표준 아키텍처를 설계 4. 서브시스템 구체화 : 서브시스템의 기능 및 서브시스템 간의 상호작용을 위한 동작과 인터페이스를 정의 5. 검토 : 아키텍처가 설계 목표에 부합하는지, 요구사항이 잘 반영되었는지, 설계의 기본원리를 만족하는지 등을 검토
∙ 조직 내에 진행 중인 업무(Works In-Progress , WIP)가 일정 수준 이상 밀려 있지 않게 하는 데 도움을 준다.
∙강력한 리더십, 조직적 투명성, 팀워크, 사내 열린 소통과 협업을 지원한다.
∙눈에 보이지 않는 작업을 가시화할 수 있기 때문에 우선순위를 놓치는 일을 막고 어떤 일이 처리되고 있는지 모든 사람이 알 수 있다.
⌜ 칸반의단계 ⌟
칸반 게시판용 단계를 만들 때 일반적으로 사용되는 템플릿은 없다. 각 작업 완수에 필요한 단계가 지나치게 복잡하지 않게 하고 전체적으로 간단하게 유지하는 것이 원칙이다. 각 조직은 각 열에 맞는 범주를 자유롭게 선택할 수 있으나 대부분의 칸반 게시판에는 다음과 같은 단계를 포함한다. -대기: 팀이 인지하고 있는 미뤄진 작업을 주로 보관하는 열이다. 대기 중이던 작업은 시작할 여유 시간이 생기면 오늘의 구체적인 작업 열로 이동되거나 ‘진행 중’ 열로 이동할 수 있다. - 진행 중: 현재 작업 중인 모든 작업이 포함된 열이다. ‘하는 중’ 열이라고 부르기도 한다. 작업할 새로운 작업을 선택하면 곧장 이 열로 이동된다. 작업이 진행되는 한 이 열에 머무른다. - 완료: 따로 설명이 필요 없는 열이다. 일단 완료된 작업은 최종적인 ‘마침’ 또는 ‘완료’ 열로 이동된다. - 차단: 무슨 이유에서든지 작업을 완료할 수 없거나 진행이 중단 또는 일시 정지된 경우에는 재개될 수 있을 때까지 ‘차단’ 또는 ‘보류’ 범주로 옮겨 놓는다.
