소프트웨어 개발 프로젝트의 실용주의 선언 - 특집 1부 아키텍트 편

http://gisulsa.tistory.com/7



소프트웨어 개발 프로젝트의 실용주의 선언

전 세계 소프트웨어 개발 프로젝트의 80% 이상이 원래 계획했던 목표를 다 이루지 못한다고 한다. 국내의 경우는 어떠한가? 계획했던 목표를 이루지 못하거나 프로젝트 일정이 늘어지는 것은 비일비재하고, 심지어 프로젝트 전체를 통째로 망치는 경우도 생긴다. 그 곳에 속한 사람들은 또 어떠한가? 지금까지 배워오고 당연하게 생각했던 것들이 실제 프로젝트에서는 꼭 그렇게만 되지 않는다는 사실에 수없이 좌절하지 않았을까. 앤드류 허트와 데이비드 토마스가 ‘실용주의 프로그래머’를 통해 경험에서 우러나오는 통찰과 직관 그리고 지혜를 우리에게 제공했듯이, 국내 소프트웨어 개발 프로젝트에서도 ‘실용주의 선언’이 필요할 때이다. 한 해를 정리하는 송년 특집으로 아키텍트, 디자이너, 개발자, 테스터 그리고 프로젝트 매니저에 이르기까지 소프트웨어 개발 프로젝트에 속한 각 분야별 전문가들의 숙련된 실용주의적 내공을 독자들에게 선사한다.

특집 1부│아키텍트 편
화려하고 새로운 아키텍처의 유혹에서 벗어나라

이해일｜Ubiqo 대표

훌륭한 아키텍처는 주어진 상황에 가장 적합한 아키텍처다. 상황에 가장 적합한 아키텍처는 책에서 구할 수 있는 것도 학교에서 배울 수 있는 것도 아니다. 현장에서 부딪히면서 만들어 낼 수 있는 것이다. 이번 기사를 통해 현장에서 얻은 경험을 바탕으로 아키텍처링 전반을 살펴보고자 한다.

엔터프라이즈 시스템을 구축하는 프로젝트에서 아키텍처의 중요성을 인식하고 아키텍트가 빠질 수 없는 역할로 등장한 것은 그리 오래 되지 않았다. 그렇다고 해서 예전 시스템에 아키텍처가 없는 것은 아니다. 세상에 존재하는 모든 시스템은 아키텍처를 가질 수밖에 없다. 시스템이 존재하고 동작한다는 것 자체가 아키텍처를 가진다는 증거이다. 아무런 원칙 없이 마구잡이로 만들어진 시스템도 가끔 존재하지만 전산화 역사가 오래된 업종의 시스템은 아키텍처를 수립한다는 의식을 하지 않았을는지 몰라도 뚜렷한 원칙과 방향에 따라 구축되었다. 이 원칙과 방향이 바로 아키텍처다.

금과옥조(金科玉條)

좋은 아키텍처란 무엇일까? 어떤 시스템이 화면에서 바로 데이터베이스를 연결하여 모든 업무를 처리하고 있다고 하자. 이 시스템의 아키텍처는 좋은 것일까, 나쁜 것일까? 화면과 업무 로직이 섞여 있기 때문에 나쁜 아키텍처라는 일반론을 들이 댈 수도 있지만 이론일 뿐이다. 아키텍처가 좋은 지 나쁜 지는 오로지 아키텍처가 주어진 상황에 얼마나 적합한지로 판단해야 한다.

만약 대량 데이터를 읽어서 실시간으로 보고서를 제공하는 MIS 업무를 완전 초보 개발 조직이 3개월 동안 개발해야 하는데 고객마저 성질이 급해서 데이터가 아무리 많더라도 요청 후 10초 안에 보고서를 보여주길 바라는 상황이라면, JSF로 화면을 구현하여 Struts 프레임워크에 붙여서 EJB로 구현된 비즈니스 컴포넌트를 통해 OR 맵핑으로 데이터를 가져오는 아키텍처는 무용지물이다. 이런 상황이라면 4GL 도구나 보고서 도구로 구현한 화면에서 바로 데이터를 가져다가 보고서를 만들어 줘야 한다. 아무리 화려한 이론과 최신 기술로 무장한 아키텍처라고 해도 주어진 상황에 맞지 않는다면 말짱 도루묵이다. 아키텍처는 실재로 프로젝트에 적용되어서 시스템으로 체화될 때만 유용성을 인정받을 수 있다. 주어진 상황에 딱 맞는 최적의 아키텍처를 만들어 낸다는 실용주의 자세야 말로 아키텍트가 지켜야 할 금과옥조(金科玉條)인 것이다.
한 가지 주의해야 할 점이 있다면, 아키텍처는 제약일 수밖에 없고 인간은 제약받는 것을 싫어하기 때문에 아키텍트는 다양한 이해관계자들로부터 아키텍처를 어기려는 수많은 도전을 받을 수밖에 없다는 것이다. 반복하지 말라는 DRY(Don’t Repeat Yourself) 원칙, 모듈화의 원칙, 인터페이스 중심의 원칙같이 아키텍처가 주어진 상황과 관계없이 반드시 견지해야 할 원칙들은 존재하고 이 원칙 안에서 도전을 받아들여야 한다.

이제부터 아키텍트가 아키텍처를 만들어가는 아키텍처링 과정을 책에 나온 이론이 아닌 현장에서 얻은 경험을 중심으로 이야기하려고 한다. 경험이 쌓이고 쌓이면 패턴이 된다고 한다. 이 경험이 독자 여러분들의 경험과 더해져 훌륭한 아키텍처링 패턴을 만들어 낼 것을 기대해 본다.

피아식별(彼我識別)

장수가 전장에서 갖춰야 할 제일 기본은 아군을 인식하고 적군과 구별해내는 것이다. 아키텍처링도 마찬가지다. 전 우주에서 우리가 다뤄야 할 ‘우리 시스템’을 식별해 내고, 이렇게 식별한 우리 시스템과 상호 작용하는 다른 시스템들을 찾아내는 작업은 모든 아키텍처링의 시작이다.

그렇다면 어떤 기준으로 우리 시스템을 식별할 수 있을까? 기술 변수도 아주 중요하지만, 프로젝트를 둘러싼 정치 변수들이 더 중요한 경우가 많다. 우리 시스템을 식별해내는 순간 프로젝트 범위가 결정된다. 프로젝트 범위엔 많은 이해관계자들이 얽혀 있다. 이 이해관계자들은 자신의 이해관계에 따라 정치활동을 펼친다. 정치라는 말에 알레르기 반응을 보일지도 모르지만, 아키텍트는 시스템의 기술 측면을 대변하는 이해관계자로서 시스템이 바람직한 기술 구조를 가지도록 다른 이해관계자들을 설득하고 조율하는 정치활동을 펼쳐야 한다. 때로는 이해관계자들의 이해가 상충하여 기술 측면에서 바람직하지 않은 방향으로 시스템의 범위가 결정될 수도 있지만, 이런 결정조차 아키텍트를 포함한 모든 이해관계자들이 찾아낸 합의점이라는 것을 인정하는 지혜가 필요하다.

보통 우리 시스템의 범위는 시스템을 구축하는 프로젝트의 책임 범위에 따라 결정된다. 은행 시스템을 구축한다고 해보자. 프로젝트를 진행하면서 직접 구축해야 하는 부분은 분명히 우리 시스템의 한 부분이다. 또, 은행 공동망 시스템이나 신용카드 시스템은 우리 시스템과 상호 작용해야 하는 다른 시스템인 것도 확실하다. 그런데 구분이 좀 모호한 것도 있다. 예를 들어, 보통 상용 제품을 구매해서 인터페이스만 맞춰서 쓰는 ATM과 새롭게 시스템을 구축하거나 기존 시스템을 재활용하는 인터넷뱅킹은 우리 시스템일 수도 있고 다른 시스템일 수도 있다. 어디에 속할 지는 프로젝트가 책임져야 하는 범위에 따라 달라진다. 우리 시스템의 경계는 프로젝트가 책임 범위까지이고, 우리 시스템과 상호작용하는 다른 시스템은 관심 범위까지라고 생각하면 된다(<그림 1>). 좀 더 단순하게 이야기하면, ATM 구매부터 책임진다면 우리 시스템 범위이고 프로젝트와 무관하게 구매가 이루어진다면 상호작용해야 하는 다른 시스템으로 생각하면 된다.

아키텍트는 우리 시스템은 내부까지 세세하게 다뤄야 하고 관심 범위에 있는 다른 시스템은 상호작용 방식까지만 다루면 된다. 우리 시스템의 범위는 제안요청서(RFP), 비전기술서, 프로젝트 계획서에 잘 드러나기 때문에 아키텍처링 작업 전에 반드시 확보하여 숙지할 필요가 있다.

<그림 1> 아키텍처링 시작하기

고객만족(顧客滿足)

아키텍트의 업종은 무엇일까? 대한민국에서 아키텍트는 서비스업으로 분류된다. 그렇다. 아키텍트는 시스템을 둘러싼 다양한 이해관계자들인 고객을 만족시켜야 하는 서비스 업자다. 그렇다면 어떻게 고객을 만족시킬 것인가? 간단하다. 모든 서비스업이 그렇듯이 고객의 요구를 만족시키면 된다. 아키텍트는 시스템이 필요한 기능과 적절한 품질을 제공해야 한다는 고객의 요구를 만족시킬 수 있게 아키텍처를 만들어야 한다.

아키텍처는 시스템에 필요한 쓸모, 아름다움, 짜임새를 모두 다뤄야 하지만, 보통 쓸모가 짜임새와 아름다움을 주도한다. 아키텍처가 고객이 원하는 쓸모를 충족시키지 못한다면 아무리 짜임새 있고 아름다워도 아무 소용없다. 아키텍처는 고객이 원하는 쓸모를 충족시킬 수 있도록 아름다움과 짜임새를 결정하는 것이다(<그림 2>). 고객이 원하는 쓸모가 바로 고객의 요구로 유스케이스로 대표되는 기능 요구와 품질로 대표되는 비기능 요구로 나눌 수 있다.

<그림 2> 아키텍트가 다뤄야 할 것들

<표 1> 품질 요구 질의서 예

구분	ID	요구 사항	순위	상충	아키텍처 결정
장애 영향 최소화	AR 005	특정 지점의 장애가 다른 지점에 영향을 미치지 않아야 한다.	1	AR 015	웹서버, WAS, DB를 지점 별로 구성
	AR 006	외부 시스템의 장애가 발생하더라도 업무 진행에 지장이 최소화되어야 한다.	5		대외 시스템에 장애가 발생하면 데이터를 보관해 놓았다가 장애 복구 후 일괄 처리
24×365 서비스	AR 008	ATM/인터넷 뱅킹은 중단없이 24×365 서비스를 제공한다.	4		D일자 마감 후 업무 원장 Snapshot을 기반으로 D일자 지점 MIS 업무를 수행하며, 마감 후 거래는 D+1일자로 업무 원장에 반영
	AR 009	서비스 중단 없이 하드웨어를 교체할 수 있어야 한다.	3		하드웨어 이중화
	AR 010	O/S 커널 파라미터 변경. WAS/DBMS 재 기동을 제외하고, 서비스의 중단 없이 애플리케이션이나 컴포넌트를 교체할 수 있어야 한다.	4	AR 011	하드웨어 이중화 대체 가능성이 높은 컴포넌트 단위로 배포 Hot Deploy 제공
빠른 처리 속도	AR 011	온라인 거래와 온라인 배치는 다음과 같은 시간 내에 처리 완료되어야 한다. - 내부 거래: 최대 7초, 평균 3~4초 - 원격 거래: 최대 10초, 평균 5~6초	1	AR 010	같은 기계 내부에서 EJB 호출을 최고화할 수 있는 아키텍처 제시
	AR 012	온라인 보고서 조회는 최대 60초 이내 처리 완료되어야 한다.	3		SQL 최적화 (구현으로 해결)
	AR 013	점포별 일일 마감을 포함한 일 배치 작업은 점포별 30분 이내에 처리 완료되어야 한다.	2		마감 배치 작업에 시스템 자원 최대 배정
	AR 014	영업시간 중 온라인 거래 (ATM, IB 포함)와 온라인 배치는 1초에 최대 25건의 거래를 처리해야 한다.	2		트랜잭션 처리 단위 최적화
쉬운 유지보수	AR 015	변경 사항을 시스템에 반영하는 과정을 자동화해야 한다. 지점별로 시스템 설정에 걸리는 시간은 0.5M/H를 넘어선 안된다.	1	AR 005	자동 빌드, 배포 스크립트 제공

조금만 생각해보면 기능과 품질이 서로 밀접한 연관관계를 가지는 것은 아니라는 것을 알 수 있다. 만약 기능과 품질이 밀접한 연관이 있다면 시스템이 제공하는 기능에 따라 성능, 가용성, 사용성, 보안 수준 같은 품질이 결정되겠지만 그렇지 않다는 것을 우리는 잘 알고 있다. 그렇다고 해서 시스템이 무슨 기능을 제공하든지 원하는 수준의 품질을 제공할 수 있다는 뜻은 아니다. 아주 많은 데이터를 근거로 아주 복잡한 계산을 하는 기능을 제공하면서 아주 빠른 성능을 내는 것은 거의 불가능하다. 아키텍트는 모든 유스케이스가 적절한 수준의 품질을 만족시킬 수 있도록 해주어야 한다.

흔히 아키텍처를 설명하면서 품질과 많이 연관시킨다. 맞다. 하지만 아키텍처가 품질만을 다루는 것은 아니다. 다만 유스케이스로 대표되는 기능 요구는 아키텍처를 기반으로 하는 개발을 통해 만족시킬 수 있지만 품질로 대표되는 비기능 요구는 주로 아키텍처가 만족시킬 수밖에 없기 때문에 품질이 강조되는 것뿐이다.

기능 요구는 명백하지만 비기능 요구는 모호할 수 있다. 예를 들어, 시스템은 높은 성능을 내야 한다는 말은 매우 모호하다. 어떤 상황에서 얼마나 성능을 내야 한단 말인가? 또, 시스템은 유연하게 수정할 수 있어야 한다는 말도 의미가 없다. 어떤 종류의 변화에 대해서는 수정할 수 있지만 어떤 종류의 변화에 대해서는 수정할 수 없을지도 모른다. 또 비기능 요구사항들은 서로 상충할 수도 있기 때문에 모든 품질 요구를 100% 만족시킬 수는 없다. 전체 품질은 각 품질의 목표를 적절한 수준에서 조율한 수준에서 결정된다. 품질 요구를 정확하게 판단하기 어렵기 때문에 <표 1>과 같은 품질 요구 질의서를 통해 품질 요구를 정확하게 파악하는 것이 필요하다.

마지막으로 아키텍처만 잘 만든다고 모든 요구가 만족되는 것은 아니라는 것을 기억해야 한다. 프로젝트의 모든 공정이 기능과 품질에 영향을 미친다. 품질 요구 가운데 일부는 아키텍처 자체가 만족시키기도 하지만 대부분 기능과 품질은 설계, 구현, 배치와 같은 세부 활동의 결과물이기 때문에 끊임없는 활동결과 검토로 아키텍처를 유지해 가는 것이 중요하다.

분할정복(分割征服)

엔터프라이즈 시스템은 복잡하다. 수십 명에서 수백 명에 이르는 각 분야의 전문가들이 일 년 넘게 혼신을 쏟아야 완성될 정도로 복잡하다. 아키텍트는 수많은 변수를 요모조모 따져서 이렇게 복잡한 엔터프라이즈 시스템 구축에 필요한 최적화된 아키텍처를 만들어내야 한다. 게다가 인간이 한 번에 다룰 수 있는 정보량은 지극히 한정되어 있기 때문에 아무리 뛰어난 아키텍트라도 엔터프라이즈 시스템을 통째로 다루는 것은 거의 불가능하다. 다행히도 인류는 복잡한 문제는 이해하고 다룰 수 있는 크기로 나눈 다음 하나씩 정복하면 해결할 수 있다는 것을 오랜 경험으로 체득하고 있다.

아키텍처링도 마찬가지다. 우선 우리가 이해할 수 있는 수준에서 시작해야 한다. 앞서 이야기했듯이 무한히 복잡한 전 우주에서 우리 시스템을 분할해내야 한다. 아무리 복잡한 시스템이라도 아키텍처링의 시작은 이렇게 단순하다. 일단 우리 시스템과 전 우주를 분할한 다음 우리 시스템을 다시 이해할 수 있는 수준의 부분들로 분할해가면서 부분들 사이의 인터페이스 방식을 정의하면 아키텍처는 완성된다. 결국, 아키텍처링이란 시스템을 몇 개 상자와 선으로 표현하는 것에서 시작해서 이 상자 내부와 선을 구체화시켜 가는 과정이다. 카네기-멜론 소프트웨어 엔지니어링 인스트튜트에서 주창한 ADD (Attribute-Driven Design, 속성 주도 설계) 방법이 되었든, 직접 고안한 방법이 되었든 모든 아키텍처 수립 방법론은 결국 우리가 ‘그냥’ 알고 있는 분할정복 전략을 체계화한 것이다(<그림 3>).

그렇다면 과연 어떤 기준으로 시스템을 분할해 갈 것인가? 다행히도 이 기준은 선배 아키텍트들이 수십 년 동안 경험을 통해 마련해 놨다. 우리는 이 경험을 고스란히 익혀서 새롭게 적용하면 된다. 이런 경험들을 고상한 말로 아키텍처 패턴이라고 한다.

<그림 3> 분할정복 전략

[AOD 방법의 공정]

ADD(Attribute-Driven Design, 속성 주도 설계) 방법의 공정은 <그림 1>과 같다. 아키텍처 드라이브(Architecture Drive, 요구사항이라고 생각하면 된다)를 달성할 수 있도록 아키텍처 패턴에 따라 시스템을 좀 더 작은 단위로 분할해 가면서 아키텍처를 설계하는 것이다(<그림 2>).

자세한 내용은 www.sei.cmu.edu/architecture/add_method.html에서 살펴보기 바란다. 현장에서 체득한 지식을 이론으로 무장해야 완벽에 가까워지는 법이다.

<그림 1> ADD 방법 공정


<그림 2> ADD 방법으로 시스템을 분할 정복하는 과정

온고지신(溫故知新)

게을러지고 싶은 아키텍트는 영악해지면 된다. 전문가들의 경험을 활용하면 된다. 처음부터 다시 시작하지 마라. 하늘 아래 전혀 새로운 것은 진짜 드물다. 전대미문의 시스템을 구축하는 일이 얼마나 있겠는가? 오히려 그동안 운영되어 오던 엔터프라이즈 시스템을 개비(改備)하는 일이 많기 때문에 비록 구닥다리가 되어 버린 것 같은 기존 시스템에서 수십 년 동안 쌓여 온 전문가들의 경험을 뽑아내야 한다. 컴포넌트라고 이름을 붙이든 모듈이라고 이름을 붙이든 응집도를 높이고 결합도를 낮춰야 한다는 소프트웨어 공학의 기본 원리가 변하지 않듯이 코볼로 만들었든 자바로 만들었든 시스템을 만드는 철학은 크게 다르지 않다. 어떤 시스템이 수십 년 동안 특정한 모습으로 유지되어 왔다면 다 나름대로 근거가 있고 이유가 있는 법이다. 아키텍트는 이 근거와 이유를 검토하여 새롭게 구축하는 우리 시스템에 적용해야 한다.

<그림 4> 대부분 엔터프라이즈 시스템에 적용할 수 있는 아키텍처 패턴

[브라이언 푸트의 패턴 이야기]

브라이언 푸트(Brian Foote)만큼 훌륭하게 패턴을 설명한 사름은 없는 것 같다. 게으르고 영약한 건축가가 있었다. 어느날 이 건축가가 대학 건물과 그 주변 통행로를 설계하게 되었는데 대학 건물만 설계하고 통행로는 방치한 채 게으름을 피웠다. 결국 통행로 없이 대학 건물만 지었지만 이 건축가는 여유만만이었다. 사람들은 통행로가 없었기 때문에 자기 좋을 대로 건물 주위를 돌아 다녔다. 겨울이 되었고 큰 눈이 내렸다. 이 건축가는 드디어 일을 시작했다. 사람들이 눈 위로 돌아다닌 발자국들을 사진으로 찍었다가 봄이 되자 찍어 두었던 사진들을 보고 통행로를 설계했다. 이렇게 완성된 통행로는 다니기에도 편했고 주변 건물과도 잘 어울렸다. 패턴이란 바로 이런 것이다. 패턴은 어떤 분야에서 계속 반복해서 나타나는 문제들을 해결해 온 전문가들의 경험을 모아서 정리한 것이다. 누가 뭐래도 대학 건물 주변의 동선(動線)을 제일 잘 알고 있는 전문가는 바로 매일 건물 주위를 돌아다니던 사람인 것이다. 게으르고 영약한 건축가는 누가 전문가인지 잘 알고 있었고 전문가들의 경험을 활용한 것이다.

그렇다면 대부분 엔터프라이즈 시스템에 적용할 수 있는 아키텍처 패턴은 무엇일까? 이 질문에 답하려면 아키텍처를 결정하는 가장 중요한 아키텍처 드라이브가 무엇인지 생각해봐야 한다. 중요한 아키텍처 드라이브인 기능과 품질 가운데 더 중요한 것은 기능이다. 아키텍처는 우선 시스템에 필요한 모든 기능을 지원하는 기반을 제공해야 한다. 시스템에 필요한 기능을 모두 제공하지 못한다면 아무리 뛰어난 품질을 제공한다고 한들 무슨 소용이 있겠는가?(그렇다고 품질을 무시하고 무조건 기능만 만족시키라는 의미는 아니다. 품질과 기능이 서로 밀접한 연관 관계를 가지는 것은 아니지만, 이 둘이 직교하는(orthogonal) 관계는 아니다. 필요한 모든 기능을 만족할 만한 품질로 제공해야 한다).

최초로 시스템을 분할할 때 기능성(functionality)이라는 아키텍처 드라이브를 기준으로 삼아야 한다. 지난 수십 년 동안 만들어진 대부분 엔터프라이즈 시스템은 제공하는 주요 기능에 따라 채널계, 계정계, 정보계라는 세 가지 구성요소로 나눠지는 아키텍처 패턴을 따르고 있다.

은행 시스템을 예로 들어보자. 계정계는 주로 실시간 업무를 처리하는 부분으로 업무 원장이라는 데이터를 중심으로 움직인다. 채널계는 계정계에 접근하는 다양한 통로로 ATM이나 인터넷뱅킹 같은 별도 시스템일 수도 있고 사용자가 조작하는 단말기일 수도 있다. 정보계는 계정계에서 만들어진 데이터를 가공하여 보고서와 같은 정보를 생산한다. 시스템을 채널계, 계정계, 정보계로 분할하는 아키텍처 패턴은 코볼로 시스템을 만들던 시대나 자바 EE(Java Enterprise Edition)로 시스템을 만드는 시대나 항상 유효하다. 또, 각 계 사이의 상호작용 방식은 기술과 시대의 변화에 따라 바뀔 수 있지만, 상호작용하는 관계는 크게 변하지 않는다. <그림 4>를 굳이 레이어, 블랙보드, 파이프와 필터 같은 잘 알려진 아키텍처 패턴에 끼워 맞출 수도 있지만 이 단계에서 큰 의미는 없는 작업이다.

채널계, 계정계, 정보계로 시스템을 나누는 것은 훌륭한 출발점이 될지는 모르지만 아직 실무자들이 받아들이기엔 너무 추상화 수준이 높다. 다시 적절한 아키텍처 패턴을 적용하여 각 계를 좀 더 작은 단위로 분할해야 한다. 예를 들어 계정계를 다시 온라인 시스템, 일괄처리 시스템, 대외 인터페이스 시스템으로 나누는 아키텍처 패턴을 적용할 수 있다. 이 아키텍처 패턴 역시 기능성이라는 아키텍처 드라이브를 가장 중요하게 고려한 것이다.

아키텍처가 이 정도 수준에 이르면 한 가지 모습으로 아키텍처를 파악하기 어려워지기 때문에 적절한 아키텍처 프레임워크(Architectural Framework)를 참조해서 프로젝트 특성에 맞는 다양한 관점(View)으로 시스템을 바라보면서 아키텍처를 만들어 가야 한다. <그림 5>는 그 동안 경험으로 얻은 아키텍처에 필요한 관점들을 모아 놓은 것이다.

전체 아키텍처 관점은 우리 시스템 전체 윤곽을 <그림 4>의 수준에서 설명한다. 다음으로 각 계의 구성요소를 대상으로 시스템 아키텍처 관점과 소프트웨어 아키텍처 관점을 기술한다.

시스템 아키텍처 관점은 하드웨어와 네트워크 구성요소 사양과 구성 방식(topology)을 주로 기술한다. 하드웨어나 네트워크 사양은 프로젝트가 시작될 시점에 정해진 예산에 따라 어느 정도 결정되어 있기 때문에 아키텍트가 프로젝트 기획 단계부터 참여하지 않는다면 시스템 아키텍처를 설계할 때 많은 제약을 받을 수밖에 없다. 엔터프라이즈 시스템 구축 프로젝트 생리상 하드웨어나 네트워크 사양이 딸려서 문제가 되는 경우는 거의 없다. 문제는 하드웨어와 미들웨어 사이의 궁합이나 개발한 소프트웨어에서 일어나는 경우가 대부분이다. 이런 제약이 아키텍처링 전체에 위협을 가할 정도는 아니다.

하지만 시스템이 제공해야 하는 품질 가운데 많은 부분을 소프트웨어로만 감당하기 힘들기 때문에 아키텍트는 하드웨어나 네트워크 관련 지식도 많이 갖춰야 한다(박스 기사 참조). 가용성을 높일 수 있는 페일오버(Fail-over) 같은 기능은 하드웨어 수준에서 제공해주지 않으면 거의 실현하기 어렵다. 또, 일일 마감 전에 대량 데이터를 복제해야 한다면 저장장치 업체가 제공하는 제품을 쓰면 성능이나 데이터 일관성을 보장받기 쉽다. 아키텍트는 자신의 지식체계에 반드시 하드웨어, 네트워크, 제품이라는 분류도 추가해야 한다.

소프트웨어 아키텍처 관점은 직접 개발할 소프트웨어나 기존 소프트웨어의 다양한 모습을 기술한다. 이때 적용할 기술 구조가 어느 정도 결정되어 있다면 각 기술 구조마다 검증된 아키텍처 패턴이 이미 존재하고 있기 때문에 아키텍트는 좀 더 게을러질 수 있다. 물론 MDA 같이 기술 중립 아키텍처를 설계하는 방법도 있지만, 결국 시스템을 완성하려면 특정 기술 구조를 적용해야 하고 아키텍처가 제공해야 하는 특정 품질 요구를 만족시키려면 특정 기술에 종속된 기능을 반드시 써야 하는 경우가 많다.

온라인 시스템의 소프트웨어 아키텍처 관점을 좀 더 살펴보자. 실시간 거래를 담당하는 온라인 시스템의 아키텍처는 레이어드(Layered) 아키텍처 패턴을 따르는 것이 좋다. 단, 실무에 적용해보면 책에서 본 것 같은 단순한 평면 레이어 구조로는 엔터프라이즈 시스템을 설명하는 것은 어렵다. 적어도 업무 관점으로 바라본 레이어와 구현 관점에서 바라본 레이어를 고려해야 한다(<그림 6>).

업무 관점에서 보통 <표 2>와 레이어를 같이 나눌 수 있다(레이어 이름은 정해진 표준이 있는 것이 아니라 흔히 쓰이는 이름을 붙인 것이다). 또, 구현 관점에서 <표 3>과 같이 레이어를 나눌 수 있다. 레이어 이름은 기존에 여러 대가들이 붙였던 이름들을 종합해서 결정한 것이기 때문에 독자들이 알고 있는 이름과 다룰 수도 있다. 비록 이름은 다르더라도 레이어가 해야 하는 역할은 변함없다.

<그림 5> 아키텍처를 기술하는 다양한 관점

<그림 6> 레이어드 아키텍처 예제

<표 2> 업무 관점에서의 레이어

구성	내용
애플리케이션 프레임워크 레이어	기술 기반 기능을 제공한다.
애플리케이션 프레임워크 레이어	업무 기반 기능을 제공한다.
업부 파티션 레이어	실제 업무 기능을 제공한다. 공통 업무 기능을 제공하는 코어 업무 파티션과 나머지 일반 업무 기능을 제공하는 단위 업무 파티션으로 나눌 수 있다.

<표 3> 구현 관점에서의 레이어

구성	내용
프리젠테이션 레이어	뷰(View). 액터-시스템 인터페이스를 제공한다. 채널계 쪽으로 빠질 수도 있다.
애플리케이션 레이어	프리젠테이션 레이어와 비즈니스 레이어를 연결한다. 외부 시스템으로부터 요청을 받아들인다.
비즈니스 레이어	컨트롤(Control). 제공해야 하는 서비스를 실행한다.
커넥터레이어	다른 레이어를 리소스 레이어나 외부 시스템과 연결한다.
업부 파티션 레이어	모델(Model). 시스템이 다루는 정보를 관리한다.

[시스템 아키텍처에 관련된 정보]

소프트웨어 아키텍처에 비해 시스템 아키텍처와 관련된 정보는 흔하지 않지만 다음 사이트에서 찾아 볼 수 있다.

• www.gaudisite.nl
• www.enterpriseintegrationpatterns.com
• www-128.ibm.com/developerworks/patterns

<그림 7> 업무 패턴 예제

<그림 8> 비지니스 레이어 구현 패턴 예

각 레이어 내부 역시 적절한 패턴을 적용해서 분할해가면서 정복해야 한다. 이 수준부터 적용되는 아키텍처 패턴은 좀 더 특정 분야에 특화된다. 업무 관점은 샌프란시스코 비즈니스 패턴(SanFrancisco Business Patterns) 같은 범용 비즈니스 패턴이나 업무 전문가들이 경험으로 체득한 패턴들을 적용해서 작성한다. 예를 들어, 은행애서 회계처리가 일어나는 연동 거래 업무 패턴은 <그림 7>과 같다.
또, 기술 관점은 Pattern of Enterprise Architecture, EJB Design Pattern, Core Java EE Pattern, Enterprise Solution Patterns Using Microsoft .NET과 같은 패턴들을 응용하여 작성한다. <그림 8>은 비즈니스 레이어 구현 패턴 예제이다.

좀 더 깊숙이 들어가면 트랜잭션 처리, 동시성 제어, 가변성 제어, 세션 제어 같은 상세한 사항을 해결할 수 있는 메커니즘을 제시해야 한다. 이 메커니즘을 제시하려면 아키텍트는 프로젝트에 적용한 표준 기술(예를 들어 자바 EE, 닷넷, CORBA)을 잘 알아야 할 뿐 아니라 웹 서버, 웹 애플리케이션 서버, 데이터베이스, 운영체제 같은 플랫폼의 특성도 상당히 깊이 이해하고 있어야 한다.

지금까지 시스템을 점차 작은 부분으로 나눠가면서 적절한 수준의 패턴을 적용해서 아키텍처를 만드는 방법을 살펴보았다. 이런 환원주의(還元主義)는 주의해야 할 점이 있다. 전체는 부분의 합보다 크다는 것을 잊지 말아야 한다는 것이다. 부분 부분은 완벽할 수 있어도 한 데 모아놓으면 서로 상충하는 부분이 생길 수 있고 직교한다고 생각했던 부분들이 서로 영향을 미칠 수도 있다. 따라서 부분을 바라보고 일을 할 때도 항상 전체를 생각할 수 있어야 한다.

또 하나 강조하고 싶은 것은 기술 순혈주의(純血主義)에 빠지지 말라는 것이다. 방대한 엔터프라이즈 시스템을 단일한 기술로 균질하게(Homogeneous) 만들 수 없을지도 모른다. 다양한 기술과 다양한 품질 요구를 만족시키려면 가장 적절한 기술 구조를 적용해야 한다. 물론 유지보수도 쉽고 인력수급도 쉽고 개발 난이도도 낮아지기 때문에 단일한 기술로 균질하게 시스템을 만드는 것이 제일 좋다. ‘적절한’이란 말은 유지보수, 인력수급, 개발 난이도, 기능, 성능 등 이 모든 것을 고려해서 결정을 내리라는 뜻이다. 온라인 시스템은 자바 EE로, 터미널은 VB.Net으로, 커넥터는 유닉스 C로 구현할 수 있다. 심지어 온라인 시스템 안에서도 화면 조회 같은 특정 업무는 보고서 도구로 구현할 수도 있다. 세상은 어차피 비균질(Heterogeneous)하다. 교조주의에 빠지지 않도록 주의하라.

이런 과정을 거쳐 완성된 아키텍처를 고객이 가장 쉽게 이해하고 적용할 수 있는 방법을 찾아야 한다. 아키텍처 기술서 전달과 아키텍처 교육은 필수이고 대부분 작업 지침서와 예제까지 제공한다. 아키텍처는 프로젝트 참여자들의 자유를 규제하고 규제라는 것은 작업 속도만 놓고 보면 분명 걸림돌이다. 따라서 고객의 생산성을 높일 수 있는 도구들을 제공해 줄 필요가 있다. <그림 8>과 같은 구현 패턴이 결정되면 구현 패턴에 맞춰 골격 코드를 만들어 낼 수 있는 코드 생성기를 제공하는 것이 좋다. 코드 생성기는 시스템 자체의 품질뿐만 아니라 아키텍처 자체의 품질도 높을 수 있는 도구이다. 예를 들어, 데이터 중심 시스템이라면 <그림 9>와 같이 데이터베이스로부터 자동으로 데이터 접근 객체(DAO, Data Access Object)와 데이터 전달 객체(Data Transfer Object)를 만들어 주는 코드 생성기를 제공하여 생산성을 크게 향상시킬 수 있다.

심신단련(心身鍛鍊)

마지막으로 인간으로서, 직업인으로서 아키텍트를 이야기하고 싶다. 아키텍트는 완벽을 추구해야 한다. 아키텍트가 기침하면 프로젝트 전체가 독감에 걸릴 수도 있기 때문이다. 혹시라도 작은 실수를 했다면 발견한 즉시 실수를 인정하고 바로 잡아야 한다. 아무리 작은 실수라도 묻어둔다면 전체 프로젝트 참여자가 작업을 진행하면 할수록 문제가 쌓이고 쌓여 나중엔 바로 잡을 수 없는 지경에 이를 수도 있다.

아키텍트는 항상 겸허하고 유연해야 한다. 아무리 오래된 기존 시스템에서도 장점을 찾아서 받아들일 수 있어야 하고, 업무 전문가들이 수년간 일해온 방식에서 패턴들을 찾아낼 수 있어야 한다. 아키텍트는 다양한 가능성 가운데 최적의 답을 찾아낼 수 있도록 어떠한 정치 요소에도 흔들리지 않고 결단을 내릴 수 있어야 한다. 아키텍트는 프로젝트의 기술 분야를 책임지는 CTO라 할 수 있다. 기술 분야에서는 최고 권위를 가지고 결단내려야 한다.

아키텍트는 IT 기술뿐만 아니라 직업인의 기본기를 충분히 갖춰야 한다. 조직이 개인의 자질을 체계적으로 키워주지 않는 환경에서 일하는 안타까운 현실에서 우리는 직업인으로서 기본기를 스스로 갖출 수밖에 없다. 아키텍트가 상대해야 하는 고객은 프리젠테이션 기술, 외국어, 커뮤니케이션, 보고서 작성과 같은 직업 기본기가 충실한 사람들이기 때문이다. 결국 아키텍처링도 시스템 구축도 사람들이 모여서 하는 일이기 때문에 사람과 사람 사이의 관계를 유지하는 기술이 전문기술보다 훨씬 더 중요할 수 있다는 것을 잊지 말자.

일천 아키텍처 양병설을 주장하며

시스템이 새로운 사업 영역을 만들어 내는 비즈니스 인에이블러(business enabler)를 넘어 사업을 이끌어 가는 비즈니스 드라이버(business driver)가 되어버린 지 오래고 아키텍처는 시스템의 성공을 좌우하는 가장 중요한 요소 가운데 하나다. 이런 현실에서 뛰어난 아키텍트를 양성하는 것은 국가의 대사가 아닐 수 없기에 감히 일천(一千) 아키텍처 양병(養兵)을 주장하고 싶다. 훌륭한 아키텍트가 많은 나라를 꿈꿔본다.

<그림 9> 아키텍처의 품질을 높이는 코드 생성기 예

[아키텍트 지침 15]

1. 전 우주에서 우리 시스템을 식별해내고 우리 시스템과 상호작용하는 다른 시스템을 찾아내는 것에서 아키텍처링을 시작하라.
2. 때로는 기술보다 정치가 훨씬 더 중요하다는 것을 명심하라.
3. 아키텍트는 서비스 업자다. 고객의 요구를 정확히 판단하여 고객을 만족시켜라.
4. 복잡하다면 다룰 수 있는 수준으로 나눠라. 아키텍처링은 상자 몇 개, 선 몇 줄을 구체화해 가는 과정이다.
5. 아키텍처는 모든 유스케이스가 적절한 수준의 품질을 만족시키며 실현될 수 있게 만들어져야 한다.
6. 가장 중요한 아키텍처 드라이브는 기능성이다.
7. 현장에서 체득한 지식을 이론으로 무장해야 완벽해진다.
8. 원리는 변하지 않는다. 방식이 변할 뿐이다. 옛 것을 익혀 새롭게 만들어라. 기존 시스템에 녹아있는 선배들의 귀중한 경험을 새로운 시스템에 적용하라.
9. 다양한 관점으로 시스템을 바라보라.
10. 지식체계에 하드웨어, 네트워크, 제품을 집어넣어라.
11. 환원주위의 맹점을 주의하라.
12. 기술 순혈주의를 경계하라.
13. 아키텍처 자체의 품질을 높여라.
14. 인성과 업무 기본기를 익혀라.
15. 아키텍처링도 결국 사람들이 모여서 하는 일이하는 것을 잊지 마라.

제공 : DB포탈사이트 DBguide.net