Eternity's Chit-Chat

aeternum.egloos.com



진화적인 설계-2.소프트웨어 아키텍처와 메타포 4부 Evolutionary Design

소프트웨어 아키텍처와 시스템 메타포(System Metaphor)

소프트웨어 개발이란 도메인에 적합한 개념을 발견하고 이를 적절한 추상화와 표기법을 이용해 코드로 표현하는 작업이다. 소프트웨어의 태동기부터 사람들은 문제 영역에 적합한 추상화를 고안하기 위해 메타포를 활용해 왔다. 메타포는 프로그램 작성과 관련된 거의 대부분의 활동에 영향을 미친다. 객체를 명명하고, 객체 간의 관계를 정의하고, 메소드와 클래스, 패키지를 명명하는 모든 작업이 적절한 메타포를 찾는 일과 관련되어 있다. 이런 관점에서 프로그래밍이란 도메인이라는 문제 영역을 연상할 수 있는 적절한 메타포를 소프트웨어에 새겨 넣는 과정이라고 정의할 수도 있을 것이다.

메타포가 수면 위로 떠오른 것은 XP의 창조자들이 메타포를 아키텍처의 영역으로 확장하면서부터다. 모든 것은 크라이슬러의 급여 지급 시스템을 개발하는 C3(Chrysler Comprehensive Compensation) 프로젝트로부터 시작되었다. C3 프로젝트 팀은 급료를 계산하는 과정을 조립 라인(assembly line)을 따라 흐르는 컨테이너를 조립하는 과정으로 보았으며 급료를 여러 개의 부분으로 구성된 복합체로 간주했다. Kent Beck은 “Extreme Programming Explained” 1판에서 XP의 프랙티스로 “시스템 메타포System Metaphor”를 포함시켰으며 이후 C3의 조립 라인 메타포는 아키텍처 레벨에 시스템 메타포를 적용한 대표적인 사례로 널리 알려지게 되었다.

크라이슬러는 제조 회사로 자동차를 생산한다. 프로젝트를 정의하기 위해 제조 메타포를 사용하는 것은 팀을 (그리고 관리자들을) [모든 지식을 공유하는] 동등한 위치에 올려놓기 위한 중요한 최초의 전진이었다. 라인(line), 부품(part), 상자(bin), 작업(job), 그리고 작업소(station)의 개념은 회사의 모든 사람들이 이해하는 메타포다. 팀은 프로젝트의 첫 번째 반복에서 개발된 매우 풍부한 도메인 모델로부터 이익을 얻을 수 있었다. 이러한 메타포를 통해 프로젝트 구성원들이 극도로 복잡한 도메인을 쉽게 이해할 수 있었다.

- Chet Hendrickson, Everything I need to know I learned from the Chrysler payroll project

시스템 메타포란 모든 사람들–고객, 프로그래머, 그리고 관리자–이 시스템의 작동 방법에 대해 이야기할 수 있는 스토리다. 시스템 메타포에는 두 가지 목표가 있다. 첫 번째 목표는 프로젝트 참여 인력들 간의 의사소통을 향상시키는 것이다. 여러 작업을 펼쳐놓을 수 있는 작업 공간으로서의 데스크탑(desktop) 메타포는 GUI 운영체제에 대한 의사소통과 지식 공유를 촉진시킨다. 두 번째 목표는 적절한 소프트웨어 아키텍처를 구축하기 위한 통찰력을 얻는 것이다. 데스크탑 메타포에서 자료들은 책상에 펼쳐져 있는 서류(file)에 기록하고 관련된 서류들을 서류철(folder)에 보관한다. 데스크탑 메타포를 사용하는 GUI 운영체제의 아키텍처에는 desktop, file, folder로 명명된 컴포넌트들이 포함되며 전체적인 구조 역시 이들 간의 관계를 기반으로 구성된다.


<그림 3> 컴퓨터의 역사를 바꾼 데스크톱 메타포

William C. Wake는 “Extreme Programming Explored”에서 공통 비전(Common Vision), 공유 용어집(Shared Vocabulary), 창조성(Generativity), 아키텍처(Architecture)의 4가지를 시스템 메타포를 탐구하는 이유로 들었다.

  • 공통 비전(Common Vision): 모든 사람들이 시스템의 작동 방식에 동의할 수 있도록 한다. 메타포는 문제와 해결방법을 인식하는 핵심 구조를 제안한다. 이것은 시스템이 무엇인가 뿐만 아니라 무엇일 수 있는가를 쉽게 이해할 수 있도록 한다.
  • 공유 용어집(Shared Vocabulary): 메타포는 객체와 이들의 관계에 대한 공통 이름 체계를 고안할 수 있도록 한다. 용어집은 최선의 경우 도메인에서 사용되는 특수한 용어로 구성될 것이다: [도메인] 전문가를 위한 강력하고, 특화된, 간결한 용어집. 어떤 것에 명칭을 부여하는 것은 그것을 제어할 수 있는 힘을 제공한다.
  • 창조성(Generativity): 메타포에 의한 비유는 (문제와 솔루션 영역 모두에 있어) 시스템에 대한 새로운 아이디어를 제시한다. “고객 서비스는 조립 라인이다”라는 메타포를 살펴보자. 이 메타포는 업무 담당 그룹 간에 문제가 전달될 것이라는 점을 제시하지만, 그와 동시에 의문점을 제시한다. “문제가 라인의 최종 지점에 도달한다면 어떻게 할 것인가? 그냥 바닥으로 떨어지고 말 것인가?” 메타포는 숨겨진 채 부패할지도 모르는 중요한 이슈를 드러낸다.
  • 아키텍처(Architecture): 메타포는 핵심적인 객체를 식별하고 핵심 객체의 인터페이스 측면을 제시함으로써 시스템을 구체화한다. 메타포는 시스템의 정적인 측면과 동적인 측면 모두를 지원한다.

- William C. Wake, Extreme Programming Explored

도메인의 개념들을 연상시키고 시스템의 구조를 가이드할 수 있는 적절한 시스템 메타포를 탐구함으로써 시스템에 대한 통찰력을 향상시킬수 있으며 이해하고 확장하기 쉬운 시스템을 구축하기 위한 발판을 마련할 수 있다. 도메인에 대한 적절한 시스템 메타포가 있다면 이를 의사소통과 아키텍처 구축 시에 적극적으로 활용하라. 그러나 시스템 메타포를 적용해야 한다는 강박관념에 사로잡히지 마라. 지속적인 학습 과정을 통해 얻어진 풍성한 도메인 모델이 있다면 시스템 메타포 없이도 원하는 결과를 얻을 수 있다.

Domain-Driven Design의 관점에서 시스템 메타포는 프로젝트의 공통 언어인 UBIQUITOUS LANGUAGE의 일부이며 도메인 모델링을 위한 영감을 제공하는 역할을 수행한다. 시스템 메타포는 도구이지 목적이 아니다.

그러나 모든 메타포는 부정확하므로 지속적으로 메타포가 지나치거나 적절치 못한가를 재점검하고, 방해가 된다면 언제든 버릴 준비를 하라. … SYSTEM METAPHOT가 모든 프로젝트에서 유용한 것은 아니다. 일반적으로 대규모 구조는 필수적인 요소가 아니다. … XP의 12가지 실천사항 중에서 SYSTEM METAPHOR의 역할은 UBIQUITOUS LANGUAGE에 의해 실현될 수 있다. 프로젝트는 적절하다고 판단될 경우 SYSTEM METAPHOR나 대규모 구조를 사용해서 UBIQUITOUS LANGUAGE를 확장해야 한다.

- Eric Evans, Domain-Driven Design

아무 것도 없는 상태에서 시스템 메타포를 창조할 필요는 없다. 유사한 도메인에 효과적으로 적용된 시스템 메타포가 이미 존재하고 있다면 이 역시 재사용할 수 있다. 시스템 메타포를 재사용할 수 있는 효과적인 방법 중 하나는 패턴 언어(Pattern Language)의 형식으로 이를 표현하는 것이다.


EVENT와 ACCOUNT 메타포

“그렇다면 실제로 요금이 계산되는 건 매일 새벽이겠군요. 가입자가 통화나 문자 서비스를 전송할 때마다 사용 정보가 시스템으로 전송되고, 다음날 새벽에 하루 동안 전송된 사용 정보를 이용해서 매일 매일의 통화료를 계산한다는 말씀이시죠?”

업무 담당자가 고개를 끄덕였다. 환기가 잘 안 되는지 이야기를 할 때마다 숨이 턱턱 막혀 왔다. 속으로 혀를 찼다. 참석자 수에 비해 너무 좁은 회의실을 잡은 것 같군. 주위를 둘러보니 대부분의 사람들이 눈가에 초점을 잃은 채 멍한 상태로 업무 담당자를 바라보고 있었다.

“많이 힘드신 것 같은데 조금만 쉴까요?”

여기 저기서 의자 특유의 삐걱 소리가 들려왔다. 참석자들 대부분이 이제 좀 살겠다는 듯이 한숨을 쉬며 회의실을 빠져 나갔다. 의자에서 일어나며 길게 기지개를 켰다. 회의실 밖으로 나오자 상쾌한 공기가 폐를 지나 옴 몸으로 퍼지면서 머리 속이 한결 가벼워지는 느낌이 들었다.

커피를 한 잔 마시려고 휴게실로 발걸음을 옮기려는 찰나 과금 업무 담당자가 다가오고 있는 것이 시야에 들어왔다. 얼굴 한번 찌푸리지 않고 몇 시간째 온갖 질문에 답변을 해주는 모습이 인상적이었다.

“많이 힘드시죠?”

업무 담당자가 웃으면서 말을 건네왔다.

“제가 힘들 게 뭐 있나요? 너무 기초적인 질문만 해서 답답하셨죠?”

“아니요. 당연히 나올 거라고 예상했던 질문이 대부분이었습니다. 참석하신 분들의 업무 이해도도 꽤나 높아 보이더군요.”


목도 축일 겸 궁금했던 부분에 대해 질문도 할 겸 업무 담당자와 함께 휴게실로 향했다. 휴게실에는 팀원들 몇 명이 모여 회의에서 오갔던 내용들에 대해 의견을 나누고 있었다. 자판기에서 음료수를 뽑은 후 업무 담당자와 함께 테이블에 자리를 잡고 앉았다. 창 밖으로 보이는 녹음이 시야 가득 들어오면서 마음이 편안해졌다.

“아까 매일 새벽에 배치 작업을 통해 가입자의 일간 요금 정보를 계산한다고 말씀하셨는데 만약 요금 결과가 잘못 된 경우에는 어떻게 보정하시나요?”

팀원들이 못 말리겠다는 표정으로 바라보고 있는 것이 느껴졌다. 어쩔 수 없지. 아무리 쉬는 시간이라도 궁금한 것은 해결해야 직성이 풀리는 성격인걸 어쩌란 말인가?

“아주 중요한 질문을 하셨군요. 현재 가입자의 요금은 일단위로 처리하고 있습니다. 하루 동안의 사용 정보를 취합해서 그날 그날의 가입자 별 요금 정보를 계산하고 있죠. 작업의 단위가 일간이기 때문에 요금 계산이 잘 못 될 경우 해당 일자의 처리 결과만 삭제하면 요금 계산 작업을 다시 수행할 수 있습니다. 즉, 요금 결과가 잘 못 될 경우 처리 결과를 삭제하고 시스템에 저장된 사용 정보를 이용해서 다시 요금을 계산할 수 있다는 것이죠. 근본적으로 요금의 보정 작업은 수정이 아닌 삭제 후 재저장 작업이라고 할 수 있습니다.”

“만약 전체 사용 정보를 시스템 내에 계속 유지할 경우에는 전체 사용 정보를 이용해 가입자의 모든 통화 요금 정보를 재계산하는 것도 가능하겠군요? 예를 들면 1월부터 12월까지의 1년간 요금을 완전히 새로 계산하는 등의 작업 말이죠.”

“예, 이론상으로는 가능 합니다만 워낙 데이터가 방대하기 때문에 대부분의 보정 작업은 한 달 단위로 이루어 진다고 보셔도 무방합니다.”

뭔가 시스템에 대한 윤곽이 잡히는 것만 같았다. 그렇다면 가입자의 한달 요금은 일간 요금을 더한 값이 될 것이다.

“아까 설명을 통해 들으셨겠지만 일간 요금 계산 결과는 1건이 아닙니다. 요금은 시스템으로 전달된 각 사용 정보 별로 계산된 후 저장됩니다. 즉, 가입자가 하루 동안 10번의 통화와 5건의 문자 메시지를 사용했다면 요금 결과는 15건이 생성되는 거죠. 시스템은 2010년 5월 1일의 사용 요금 총액을 저장하지 않고 각 사용 정보인 15건에 대한 개별 요금 계산 결과를 저장하게 됩니다.”


“요금 계산 배치는 하루에 한번 돌지만 요금 계산 결과는 가입자가 그 날 사용한 통화 및 문자 메시지 전송 건 수에 비례해서 생성된다는 말씀이시죠? 요금 계산 결과는 하루에 한 건이 아니라는 말씀이시군요.”

업무 담당자가 음료수를 입으로 가져갔다. 어느새 회의실에 모여있던 팀원들의 눈과 귀가 두 사람의 대화로 집중되고 있었다. 가벼운 침묵 속에 묻혀 있는 휴게실은 어느새 회의실로 바뀌어져 있었다.

“이렇게 하는 이유는 추적성을 확보하고 요금에 대한 보정을 용이하게 하기 위해서입니다. 과금 단위 별로 요금 결과를 관리하면 요금 계산 시에 오류가 발생한 원인을 쉽게 추적할 수 있죠. 일간 요금 정보의 보정은 오류가 발생한 요금 계산 결과를 새로운 계산 결과로 대체하기만 하면 됩니다. 전체 요금을 완전히 새로 계산할 필요는 없는 것이죠.”

뒤에서 이야기를 듣던 팀원이 불쑥 한 마디를 던졌다.

“마치 장부에 기록하는 것 같군요. 각각의 항목 별로 요금을 계산한 후 회계장부(account)에 계산 결과를 항목(entry)으로 기장(post)하는 것과 유사하네요. 장부에 기록된 항목을 더해서 총계를 내기도 하고 각 항목 별로 수정하기도 하고...”


그 순간 휴게실에 있던 모든 사람들의 머릿속에서 과금 시스템이 구체적인 형상을 띠며 체계를 갖추기 시작했다. 요금 결과를 장부에 기록하고 나중에 각 항목을 합산해서 총계를 구한다는 메타포처럼 핸드폰 과금 시스템의 본질을 정확하게 설명해주는 것이 또 어디에 있겠는가?

“그러고 보니 비슷한 내용을 본 것 같아요. EVENT SOURCING 패턴 언어(Pattern Language)라는 건데 시스템에 도착하는 이벤트를 처리해서 결과 항목을 생성한 후 이를 사용해서 시스템의 상태를 변경하는 패턴들의 집합입니다. 이 패턴의 특수한 예가 ACCOUNT 패턴 언어로 방금 전에 말씀하셨던 회계장부와 비슷한 개념을 소프트웨어로 구현하기 위한 패턴의 집합이죠.”

되돌아 보면 그 순간에 프로젝트의 방향이 결정되었던 것 같다. 회의실에서 이야기를 나누던 그 순간에 핸드폰 과금 시스템의 개념과 구조를 공유할 수 있는 적절한 메타포를 발견했던 것이다. 회계장부 메타포는 개발자뿐만 아니라 도메인 전문가도 이해할 수 있는 직관적인 메타포다. 또한 아키텍처를 구축하기 위해 무에서 출발할 필요가 없다는 사실에 어느 정도의 안도감을 느낄 수 있었다. 우리 보다 앞서 험한 길을 개척해 나간 선각자들이 이미 패턴 언어 형식으로 이를 정리해 놓았기 때문이다.


덧글

  • 2011/09/21 01:51 # 삭제 비공개

    비공개 덧글입니다.
※ 로그인 사용자만 덧글을 남길 수 있습니다.