본문 바로가기

Homo Architect

(54)
얼마나 많은 이해관계자들을 만족시켜야 하는가? 시스템을 만들때에 사용자(user)의 요구를 충족시키는 것이 제일 목적이라고 말한다. 보통 사용자라고 함은 시스템이 제공하는 서비스를 직접 사용해서 원하는 것(가치)을 얻는 행위를 하는 액터를 일컫는다. 이러한 사용자는 불특정 다수가 될 수도 있겠지만, 업무 시스템과 같이 특정 업무를 위한 시스템의 경우에는 명확한 업무 사용자가 정의된다. 어떠한 사용자이든 이들은 시스템을 직접 다루거나 처리하는 형태가 아닌 그저 수동적으로 시스템이 일방적으로 제공하는 서비스를 사용할 뿐이다. 하지만, 최근의 시스템들은 사용자들에게 어느정도는 능동적인 행위를 부여하는 형태로 서비스를 제공하기 시작한다. 예전에는 HTML을 그저 브라우저를 통해 화면에 보여지는 요소를 만드는 형태로만 쳐다보았다면, 지금의 사용자들은 직접 자..
컴포넌트 식별/구성과 빌드 프로세스, 그리고 의존관계 SW 아키텍처에서 최소한의 빌드 단위를 결정하는 것은 이제 중요한 이슈이다. 현재의 SW 아키텍처에서 빌드 단위는 하나의 애플리케이션 (자바의 경우 war) 단위 안에 물리적으로 모든 소스 코드를 위치하는 형태로는 잦은 비즈니스의 변화와 이에 따르는 응대를 하기란 쉽지 않기 때문에 재사용 가능한 단위의 컴포넌트를 최대한 많이 그리고, 최대한 확장 가능한 형태로 구성해야 한다. 이러한 컴포넌트를 식별하고 구성하는 행위들은 궁극적으로 빌드 단위에 영향을 미치게 되며, 이는 빌드 프로세스에 직접적으로 영향을 미친다. 컴포넌트는 재사용 단위를 높이고 의존관계를 최대한 느슨한 형태로 구성하게 되지만, 이는 그 말 자체가 균형을 이루기 힘든 상태임을 알 수 있다. 재사용 단위를 높이는 것은 궁극적으로 컴포넌트의 의..
너무 많은 이해관계자들을 위한, 너무 많은 시스템을 위한 아키텍처 여기에 아주 근사한 아키텍처를 기반으로 만든 시스템이 있다. 이 아키텍처는 SoC(Separation of Concerns)의 원칙에 따라서 내부 시스템 간에 느슨한 결합(loosely coupled)을 통해 서로 연결되고, 각 계층(layer)은 의존관계(dependency)의 원칙하에 내부 모듈은 호출하게 되어 있다. 다소 어쩔 수 없는 솔루션이나 외부 시스템 때문에 일부 아키텍처가 균형을 이루지 못한 부분도 있지만, 극히 일부분이고, 그리 많이 사용하지 않은 기능이라 이 부분 역시 중요한 모듈과는 최대한 의존관계를 줄이도록 설계를 했다. 기능적으로도 품질적으로도 사용자가 만족할 만한 수준의 아키텍처가 만들어졌으며, 충분히 문서화 작업도 이루어져 있다. 이제 이 시스템이 운영 단계에 접어들면서 운영에..
통합에 대한 불편한 진실 SW에서 통합이라는 이슈가 불거진건 어제 오늘 일이 아니다. 그동안의 다양한 프로젝트들은 SI(System Integration)라는 이름 하에 진행되었으며, 그 내용 역시 서로 다른 다양한 시스템을 대상으로 통합을 위한 활동을 하는 것들이 포함된다. 하지만, 통합이라는 단어가 가지는 어감에 대해서는 시스템을 대하는 태도에 따라서 전혀 다른 아키텍처나 구조를 가지는 결과를 낳는다. 우선 통합과 반대가 되는 단어로는 분산을 들 수 있다. 통합과 유사하거나 같이 사용되는 단어로는 일관성 내지 표준화 정도로 볼 수 있다. 하지만, 이러한 단어들은 모두 통합을 위한 기본적인 토대가 되는 개념으로 서로 어느 정도는 상존될 수 밖에 없다. 아니, 반대와 유사한 개념들이 모두 공존하도록 아키텍처나 설계 구조를 만드는..
아키텍처와 철학 (철학이 있는 아키텍처) 오늘 스티브 잡스가 세상을 떠나면서 그의 추모가 인터넷에서 활발하다. 개인적으로도 그와 같이 동시대에 살았다는 것이 그리고, 그의 작품인 아이폰과 아이패드를 사용할 수 있었다는 것인 행운이었지 않았나 싶다. (사실, 맥도 사용하고 싶지만 경제적인 여력이 없어 그가 가지고 있는 SW에 대한 생각이나 열정을 고스란히 느끼기에는 한계가 있을 것이라고 생각한다.) 스티브 잡스는 IT 업종에 속해 새로운 길을 제시했을 뿐만 아니라, 그는 대중에서 뛰어난 연설을 했던 연설가로도 손색이 없다. 혹자는 스티브가 최고의 프로그래머라고 말하는 사람도 있지만, 실은 그가 프로그래머는 아니었다. 어느 자료나 문서를 보더라도 스티브가 코드를 작성한 프로그래머라는 이야기를 들어본 적은 없다. 하지만, 그에게서 IT를 이끄는 힘을..
원칙(principle)과 제약사항(constraint, environment)의 충돌 SW 아키텍처 설계시에 다양한 원칙들이 있으며, 이는 좋은 설계와 건전성을 위해서 원칙을 선택하게 됩니다. 물론, 아키텍처 원칙 중에는 우선순위가 해당 컨텍스트에 따라서 결정되며, 모든 설계에서 공통으로 적용되는 원칙들도 있습니다. 하지만, 이러한 원칙들은 늘 제약사항이나 환경과 충돌을 경험하게 됩니다. Chaos inside by h.koppdelaney 이러한 충돌이 발생하는 상황에서는 늘 아키텍트나 설계자의 고민을 만들어내게 되며 다양한 의사결정을 하게 됩니다. 대부분의 의사결정에서 어떠한 방식으로 접근하는가에 따라서 추후 변경이나 잘못 결졍된 아키텍처의 수정에 대한 영향을 미치기도 합니다. 또한, 모든 설계 결정을 아키텍트가 하기도 힘들기 때문에 이를 일부러 설계자에게 위임하는 경우도 있으며, 때..
비즈니스 로직의 진화와 아키텍처의 진화 SW 아키텍처는 SW를 지지하는 구조적인 측면에서 개발 초반에 어느 정도 확정이 된다면, 어느 시점까지는 해당 아키텍처 상의 SW를 지탱해줄 수 있는 여력이 만들어집니다. 개발 시점에는 비즈니스 로직의 변화가 제일 심하며, 이에 따라서 아키텍처 역시 같이 진화를 거듭하게 되며, 시스템 오픈 시점에는 SW 아키텍처가 운영을 할 수 있는 상태로 그 균형을 유지하게 만듭니다. 하지만, 운영시점에 있어서는 개발 기간 동안에 예기치 못했던 문제와 다양한 비즈니스 환경의 변화로 인해서 비즈니스 로직의 급격하지는 않지만, 서서한 변화를 겪게 됩니다. 여기에서 비즈니스 로직을 어떻게 변화시키느냐에 따라서 SW 아키텍처는 그 무게를 지탱할 수 있는지 혹은 변칙적인 변화를 수용해서 만들어진 SW 아키텍처의 원칙들이 하나 ..
테스트, 이젠 옵션이 아닌 필수이다. 프로젝트 진행 중에 수많은 산출물들과 수많은 작업들이 있지만, 가장 주요한 그리고 필수적으로 있어야 되는 작업과 산출물은 주로 설계과 소스 코드로 초점을 맞출 수 있습니다. 그 이외에 개발에 지연을 주는 요소들은 모두 선택적인 작업이나 산출물들이 됩니다. 설계 산출물 중에서도 대부분이 클래스 다이어그램을 중심으로 하는 정적 모델을 필수 산출물로 선정하고, 시퀀스 다이어그램과 같은 동적 모델에 대해서도 선택 산출물이라고 얼버무리는 경우도 많습니다. 기본적으로 다이어그램은 선택과 필수라는 식의 접근 방식보다는 해당 산출물이 어떤 이유에서 필요하며 어떤 결과물들을 내기 위해서 사용되어야 하는지에 대한 타당성이 먼저 있어야 하며, 그와 같은 결과물들은 내려면 시퀀스 다이어그램과 같은 동적 모델을 그릴 수 밖에 ..

반응형