로버트 마틴(이후 밥)은 밥 아저씨라는 별명으로 불리며 "Clearn Code"[1]로 유명하다. 또한 마틴 파울러(이후 마틴) 하면 "Refactoring"[2]으로 유명하다. 이 두 사람은 많은 공통점을 가지고 있다. 앞에서 말한데로, 소프트웨어 개발자가 공부를 하다 보면 알게 되는 유명한 책의 저자이다.
둘다 애자일리스트이다. 즉, 애자일 소프트웨어 개발을 지지하는 사람들이다. 이 두 사람은 애자일 소프트웨어 개발 선언(Manifesto for Agile Software Development)[3], 소위 애자일 선언문(Agile Manifesto)에 서명한 17명에 포함되어 있다. 두 사람은 모두 애자일 소프트웨어 개발 중에서 의 가장 엔지니어링 실천법(engineering practices)에 집중하는 익스트림 프로그래밍(Extreme Programming, XP)의 추종자이다.
밥의 블로그인 The Clean Code Blog의 글[4]를 보면 그는 Extreme Programming(XP)을 지지하는 것을 알 수 있다. 그의 글이 2013년도 이고, 글에서도 15년 전 이야기라고 언급 하고 있으니 1998년도 즈음의 이야기를 회고(reflection)하면서 XP를 제외한 Scrum, Kanban 그리고 Lean에서 일어나고 있는 일들을 비판하고 있다. 그는 마틴의 축 늘어진 스크럼(Flaccid Scrum)[5]이라는 비판에 동의 하고 있다. 특히, 밥은 XP의 12개의 실천법 중에서 다른 애자일 신천법은 단 하나, 플래닝 게임(Planning Game, 소위 반복 Iteration)만을 도입하고 있다고 비판한다. 그는, XP를 넘어서 소프트웨어 장인 선언[6]을 지지하고 있다. 특히, 그의 블로그의 첫번 째 글[7]을 보면, "Clean Code"가 바로 이 소프트웨어 장인 정신을 실천하기 위한 것임을 알 수 있고, 그의 유명한 책[1]도 서문에서 부터 그 내용을 다루고 있다.
마틴의 웹페이지(martinfolwer.com)의 글[8]에서 알 수 있듯이, 그도 XP 추종자이다. 그는 XP와 관련된 책의 주요 저자인 켄트 벡(Kent Beck)과 함께 일하였다. 그 때, 켄트 벡에게서 리팩터링을 배우면서, 그의 유명한 책[2]으로 만들어 낸 것이다. 그의 웹페이지에는 주요 관심사로 보이는 항목들이 있다. 첫 번째가 리팩터링이고 두 번째가 애자일[9]이다. 여기서는 바로 그가 애자일에서 중요하다고 생각하는 부분이 드러난다.
"Agile Development is adaptive rather than predictive is people-oriented rather than process-oriented"
애자일이 예측(predictive)보다는 대응(adpative)하고, 프로세스에 기반(process-oriented)을 두기 보다는 사람에 기반(people-oriented)하다는 것이다. 특히, 나의 개인적인 경험으로도 후자가 매우 중요하다는 생각이 든다. 처음 커리어를 시작했을 때, Software Engineering을 전공하던 선배의 말이 아직도 기억이 난다. "설계 (문서)를 아주 꼼꼼하게(detail)하게 (작성)하면 코딩은 그냥 되는 거야". 이 말은 전형적인 프로세스 위주의 말이었다. 즉, 프로세스에서 필요로 하는 설계 문서를 만드는 것이었다. 내가 없어도 다른 사람이 프로세스의 산출물(artifact)인 그 문서가 중요한 것이었다. 거기에 사람은 없었다. 즉, 대체 가능한 것이었다.
차이점
밥과 마틴의 차이점에 대해 [10]에서 이야기를 하는 부분이 매우 인상적이다. 글을 쓴 사람이 Anonymous로 누가 작성한 것인지 모르지만, 매우 공감이 가는 부분이다. 한마디로 밥은 순수주의자(Purist) 그리고 마틴은 실용주의자(Progmatist)라고 한다. 밥이 정리한 OOP의 원칙인 SOLID 혹은 관심사 분리(seperation of concerns)와 같은 실천을 바라 보는 관점이 다르다.
밥은 실천이 원칙와 떨어져서는 안된다고 한다. 이러한 원칙은 법이다. 이를 지켜야만 한다는 것이다. 이것이 한마디로 소프트웨어 장인이다. 밥은 이러한 입장에서 마틴을 비판[11]하기도 한다.
마틴은 실천도 중요하지만, 원칙 혹은 가치가 더 중요하다고 한다. 이러한 실천은 모범 사례(Best Practice)이지 이해 관계자(고객)이 요구하는 실제 문제를 해결이 더 중요하다는 입장이다.
사실 두 사람의 블로그 및 웹페이지를 보면 애자일을 보는 관점에서도 차이가 난다. XP 추종자였던 둘은 이 관점에서도 달라진다. 밥은 애자일 선언문을 넘어서 더 소프트웨어 장인으로 갔고, 마틴은 엔지니어링 기반의 XP에서 애자일 개발에서 스크럼이나 칸반과 같은 다른 분야에도 관심을 보이면서, 애자일 능숙도 모델(Agile Fluency Model)[12]을 제안하기도 했다. 그는 XP도 능숙도 측면에서 4단계 중 2번 째 단계로 이야기 하고 있다. 여기서, 3단계 이 후는 린 스타트업과 같은 비지니스 및 조직 관점에서 차이가 난다고 이야기 하고 있다.
재미있는 부분은 두 사람 모두 소프트웨어 아키텍처에 관해서도 관심을 가지고 있다. 하지만, 둘의 입장에서 보는 아키텍처는 또한 다르다. 밥은 클린 아키텍처[13]에서 도달해야 하는 아키텍처의 모습을 제안한다. 마틴은 리팩터링이 그의 전문 분야인 만큼 기존에 초기에 충분한 시간을 들여 특정 기간(Phase)에서 설계하는 계획 설계(Planned Design)과 대비하여 애자일 개발에서 점진적인 개발에서 나오는 소프트웨어 설계 혹은 아키텍처가 진화적 설계(Evolutionary Design)이라고 했다[14].
결론
초창기 애자일의 경우, 학문적으로 인정 받기는 어려웠다. 하지만, 두 사람의 말대로 애자일은 주류가 되었고, 소프트웨어 엔지니어링 분야의 학계에서도 반복적 접근, 리팩터링, 테스트 기반 개발(TDD)와 같은 XP의 엔지니어링 실천법들이 학계에서도 받아 들여 지고 있다. 그런면에서 두 사람이 기반을 두고 있는 XP는 아주 의미있는 분야가 되었다.
소프트웨어 개발을 하는 사람으로서, 밥을 목표로 할 수 있다. 하지만, 그렇다면 실재로 업무를 수행하면서 죄책감을 느낄 수 있다. 그가 말하는 것은 내가 도달하기 어려운 이상향일 수 있다. 반대로 마틴을 목표로 할 수 있다. 내가 드디어 대가가 이야기 하는 것을 적용할 수 있을 것 같다. 하지만, 여전히 고객과 이해 관계자들에게 휘둘리다 보면 내가 정말 잘하고 있는 것인가 회의가 들기도 한다.
소프트웨어 개발을 하는 사람으로서 여러 분은 이 두사람에 가까울 수도 있거 좀 더 멀 수도 있다. 하지만, 이 두 사람을 좀 더 잘 이해하고 자신이 어떤지 고민하면서 성장한다면 그 또한 충분하지 않을까?
애자일 소프트웨어 개발 중에서 처음 제안이 되기도 했고, 가장 극단적인 방법이 Extreme Programming(XP)이라고 볼 수 있다. 프로세스 적인면에서 특히 그렇다. 또한 짝 프로그래밍(Pair programming), 지속적인 통합(Contiunous Integration), 테스트 주도 개발(Test-drinven development)와 같은 많은 실천법이 다른 개발에서도 채용되기도 했다.
여기서는 마틴 파울러의 2004년도 글[1]을 요약한 것이다. 원문을 읽어 보면 알게되지만, 마틴 파울러는 켄트 벡과 같은 좀 더 극단적인 XP 추종자들 보다는 더 실용적고 다른 접근 방법에 대해서도 열려 있는 것으로 보인다. 이 부분은 아키텍처 설계에 대한 관점에서 부터 크게 차이가 난다.
계획 설계(Planned Design)과 진화적 설계(Evolutionary Design)
마틴은 프로젝트 초반에 충분한 시간을 들여 소프트웨어 설계하고 진행하는 기존의 방식을 계획 설계라고 하고 XP와 같이 설계하는 단계 없이 점진적인 개발에서 나오는 소프트웨어도 아키텍처 혹은 구조가 있다고 하고 이를 진화적 설계로 불렀다.
애자일 개발에서 진화적 설계에 대해서 일반적인 비판은 임시 방편의 모음이라는 것이다. 마틴은 글에서 "우선 코딩하고 문제는 나중에 고친다(code and fix)"라고 설명하고 있다. 그리고, 시간이 지남에 따라 점점 더 코드에 기능을 추가하기 힘들어 지고 버그 수정 비용도 기하급수적으로 증가한다고 지적한다.
그렇다면, 반대로 계획 설계에는 문제가 없는가? 계획 설계에서는 설계자와 구현 담당자가 분리된 경우 종종 있다. 이러한 환경은 구현을 하는 동안에 해결해야 하는 문제를 설계자가 생각할 수 없어 문제를 만들기도 한다. 또한, 많은 개발자가 경험하지만, 요구 사항은 지속적으로 변하게 되어 있다. 이러한 문제들도 계획된 디자인을 유연하게 만들지 못하고 결국에는 "우선 코딩하고 문제는 나중에 고친다"의 접근법을 사용하게 된다고 마틴은 주장한다.
XP에서의 진화적 설계가 가능하게 하는 실천법
마틴은 이러한 문제의 해결법이 바로 XP에서 사용하는 실천법이라고 한다. 즉, 지속적인 테스팅(TDD)과 지속적인 통합(Continous Integration)이다. XP에서는 구현하기 전에 요구 사항을 테스트하는 테스트 코드를 만들고 이를 구현하고, 구현된 테스트 케이스들이 기존 코드의 동작을 보장하는 테스트 주도 개발(Test Driven Development)를 사용한다. 이를 통해서 다른 팀이 개발하는 기능의 통합도 매시간 혹은 매일하게 된다 (Continous Integration).
그 유명한 리팩토링[2]을 쓴 마틴은 리팩토링의 효과도 강조한다. 주먹구구의 느슨한 구조의 재구성과 비교해 XP에서 이야기하는 리팩토링은 아주 강력한 효과를 제공한다고 이야기 하고, 마틴으 켄트 벡으로 부터 이를 배우고 난 후에 자신이 책까지 썼다고 이야기 한다. XP에서 이야기하는 리팩터링은 TDD를 위한 테스트 코드가 존재해야 하고, 기능을 추가하지 않은 상태에서 구조를 변경하는 것이다. 리펙터링의 단순한 예제들을 따라해 봐도 이러한 것이 주는 효과는 분명하다.
디자인 패턴에 대한 마틴의 의견은?
나도 애자일 선언문[3]의 12가지 원칙 중 가장 좋아하는 부분이 "단순성이 -- 안 하는 일의 양을 최대화하는 기술이 -- 필수적이다(Simplicity--the art of maximizing the amount of work not done--is essential)"이다. 마틴도 이 단순성을 매우 강조한다. 즉, 현재 단계에서 필요한 것만 구현하는 것이다.
디자민 패턴에 대해서도 마틴은 다음과 같은 조언을 한다. XP 추종자들에게 하는 조언이기는 하지만, 애자일리스트에게는 누구에게나 적용될 수 있다.
패턴에 대해 학습하는 시간을 미리 해두자.
패턴을 언제 적용할 것인지 시기에 집중한다. 너무 일찍 적용하지 않도록 하자.
먼저 가장 단순한 형태로 패턴을 구현하는 방법에 집중하고 복잡한 것은 나중에 추가하자.
패턴을 넣었지만 충분한 효과가 없다고 생각되면 과감히 제거하라.
아키텍처 키우기
이 글[1]에서 마틴 파울러의 유명한 소프트웨어 아키텍처에 대한 정의가 나오기도 한다. 그는 소프트웨어 아키텍처를 시스템의 변경하기 어려운 부분인 시스템의 핵심 요소(core element)의 개념(notion)이라고 정의 한다.
물론 마틴은 자신을 켄트 벡과 같은 극단적인 XP 추종자가 아니라고 인정하면서 초기 소프트웨어 아키텍처가 필요하다고 이야기 한다. 하지만, 이 설계가 확정되어서 바뀌지 않는다고 생각하지 않는다. 도리어 초기 결정에 문제가 있을 수 있다는 것을 인정하고 과감하게 변경할 수 있어야 한다고 이야기 한다.
예를 들어 Enterprise Java Bean(EJB)와 같은 개발 언어는 초기에 결정해야 하는 중요한 결정일 수 있다. 그렇다면 EJB를 쓸지 않을지 결정은 프로젝트의 초기에 하는 것이 좋을까 가능한 늦게 하는 것이 좋을까? 당연히 가능한 초기에 결정하는 것이 좋을 것이다. 그렇다면, 과제를 시작하면서 바로 결정하는 것이 가장 좋을 것이다. 다시 생각해 보자. 그렇다면, 우리 과제에 EJB가 필요한지 아닌지 어떻게 알 수 있을까? 이를 확인하기 위한 진행이 가장 먼저 선행되어야 할 수 있다. 그 결과 EJB를 프로젝트에서 쓸지 아니면 쓰지 않을지 아키텍처적으로 결정하고 진행할 수 있을 것이다. 이 것이 마틴이 주장하는 소프트웨어 아키텍처를 진화적으로 활용하는 요체라고 할 수 있다.
전통적인 XP 추종자들은 아마도 데이터베이스가 필요할 때까지 데이터베이스를 적용하는 것을 가능한 미룰 것이다. 하지만, 마틴은 많은 사용자가 사용하는 시스템에서 다량의 데이터가 있다면 첫날 부터 데이터 베이스를 고려하고, 복잡한 비지니스 로직이 보이면 도메인 모델을 아키텍처에 넣으라고 조언한다.
문서화(UML 사용하기)
문서는 애자일리스트에게서는 적과 같다. 그렇기 때문에 UML에 사용도 그렇게 치부되어 왔다. 하지만, 많은 애자일을 따르는 개발자들이 단순화 된 UML을 사용하는데 이 또한 마틴에게 영향 받은 것을 보인다.
마틴은 다이어그램을 잘 사용하기 위한 조언도 제공한다.
다이어그램의 일차적 가치는 소통이므로 이를 읽을 독자를 먼저 두어야 한다. 즉, 중요한 것은 넣고 덜 중요한 것은 빼는 것이 중요하다고 강조한다.
어려운 작업일 수록 모여서 빠르게 설계 세션을 가지는 것이 중요하다고 이야기 한다. 하지만, 이 세션은 짧고, 중요한 사항만 다르며, 결과물은 최종 디자인이 아닌 스케치로 간주한다.
이러한 선행 설계는 잘못된 부분이 반드시 있을 수 있다는 것을 인정하고, 구현하면서 발경하면 디자인을 변경해야 한다는 것이다.
디자인을 변경한다고 해서 다이어그램을 변경할 필요가 없다. 디자인을 이해하는데 도움이 되었다면 충분하고 그 다이어그램은 버려도 된다.
다이어그램이 지식 전달(Knowledge Transfer)할 때에도 유용고 중요한 문제를 요약하고 강조하는 역할을 한다. 하지만, 코드가 가장 자세한 정보의 저장소임을 잊지 말자.
경력이 쌓이면 아키텍트가 되길 원하나요?
결론 부터 이야기 하면, 마틴은 테크니컬 리드가 되라고 이야기 한다. 아키텍트라고 하면 개발 업무에서 멀어지고 코딩을 하지 않는 높은 사람처럼 보인다. XP에서 하듯이 경험많은 개발자는 자신의 기술을 강화하고 팀의 여기 저기를 다니며 코칭과 가르침을 주는 것이 더 의미있다고 주장한다.
여기서 고민을 해보자. 이글은 2004년도의 글이다. 2022년 내가 알고 있는 테크니컬 리드의 상반되는 양쪽 극단은 어떤 것일까? 아마도 자신의 도메인에서 경험이 아주 많은 아키텍트가 있을 것이고, 다른 한쪽에는 실무 능력을 아주 무섭게 키운 소프트웨어 장인(Software Craft)가 있을 수 있겠다. 이 두 사람 모두 자신과 연결된 사람들에게 긍정적인 영향을 끼치며 프로젝트가 좋은 방향으로 흘러가게 기여하고 있다고 가정해 보자.
아키텍트는 코딩이나 심지어 코드리뷰도 전혀 하지 않을 것이다. 그가 하는 일은 도메인의 지식을 넓히기 위해 트렌드를 익히고, 매일 다이어그램을 그리고 이를 기반으로 몇몇의 모듈 개발 팀의 일부 인력들(리더 혹은 그 팀의 아키텍트일 수 있고 개발자 일 수도 있다)과 소통하며 방향을 잡을 것이다. 또한, 이 인력들에게 아키텍처 설계에 대해 코칭하고 가르치고 있을 것이다. 소프트웨어 장인은 늘 자신의 개발 역량을 강화하기 위해 반복 연습(카타, 태권도의 품새 같은 연습 루틴)을 하고 새로운 기술을 익힐 것이다. 자신의 담당 모듈의 완성도를 높이며, 자신이 속해 있는 동료들과 협력하며 그들을 코칭할 수 있는 것을 생각해 볼 수 있다.
이 둘은 서로 다르지만, 또한 비슷한다. 자신의 역량을 강화하고, 프로젝트를 위해 기여를 하며, 주변에 있는 동료들을 코칭하며 가르칠 것이다. 우리는 이 두 사람 사이에 어디엔가 있을 것이다. 그렇다면, 올바른 길을 가고 있는 것이라고 이야기 하고 싶다.
가역성(Reversibility)
마틴은 글에서 애자일 방법론에서 가역성의 중요합에 대해서 이야기 한다. 이 부분이 아키텍처에서도 중요하다는 것이다. 즉, 진화적 설계의 측면에서 되돌리기 쉬운 것은 덜 중요한 것이고 되돌릴 수 없는 결정이 중요한 결정이라는 것이다. 이러한 평가를 위해서 미래의 변경이 얼마나 어려울지 실험해 보는 것도 의미가 있다고 이야기 한다.
진화적 설계가 일어나고 있는가?
마틴은 진화적 설계가 일어나는지 파악하는 것이 어려운 일이라고 한다. 최근에는 프로그램 구조에 대해서 정량적/객관적 측정방법도 제안이 되고 있다. 하지만, 마틴은 이 부분은 주관적인 사실 정성적/주관적 측정이 되어야 하는 부분이라고 주장한다. 개발자가 아닌 이해당사자들은 이 부분에 대해서 이해하기 어려울 것이다. 고객의 경우를 생각한다면 자신들이 지불하고 있는 소프트웨어가 이 후에 기능을 추가하려면 더 많은 비용이 들 것인지 아닌지 알 수 없다는 것이다.
마틴은 구체적인 방법 대신 몇가지 제안을 한다.
개발자의 이야기를 들어 보자. 코드베이스가 변경하기 어렵다고 불평한다면, 이를 심각하게 받아들이고 문제를 해결할 시간을 주어야 한다.
얼마나 많은 코드가 버려지고 있는지 살펴 보자. 건강한 리팩토링을 하고 있다면 꾸준히 나쁜 코드는 삭제되고 있다. 버려지는 코드가 없다면 리팩토링이 충분하지 않다는 것이 거의 확실하다.
이러한 제안에도 불구하고 이 지표 또한 남용될 수 있다. 하지만, 우수한 개발자들의 의견은 매우 가치가 있다고 마틴은 주장한다.
여기서도 애자일에서도 [2]에서와 같이 소프트웨어 아키텍처가 필요하다고 이야기 하고 있다. 애자일 측면에서는 창발(emegence)한다고 이야기 하고, [2]에서는 진화적 설계라는 이름이로 이야기 하고 있다. 특히, 요사이는 DevOps등도 채용되고 있기 때문에 계획된 설계 보다는 진화적 설계가 더 널리 받아들여 지고 있다.
[1]에서 아키텍처링이 얼마나 진행되어야 하는가에 대해서는 [2]에서와 마찬가지로 "적정하게(Just Enough)"라고 이야기 한다. 기본적으로 구출할 프로젝트나 제품에 따라 다르다고 하는 부분은 일치한다. 또한, 어느 시점에 하느냐의 경우도, 스프린트 제로 혹은 일부 스프린트(이터레이션, 반복)에서 진행해야 하는 것도 필요하다고 이야기 한다. 하지만, 어떻게 하느냐의 부분은 달라진다.
진화적 설계의 입장에서 위에서 언급한 것 같이 여러 번의 스프린트에서 재설계(소위 리팩터링)으로 아키텍처가 확정된다면, 초기에 충분한 선행 설계(Upfront Design)가 있는 것이 나을 수도 있었다. 저자는 이러한 것 때문에 이런 결정이 섯부르게 처리한 것이고 지연과 막대한 기술 부채를 발생시킨다고 이야기 하고, 이것이 도리어 애자일 철학에 모순된다고 주장한다.
큰 기업에서의 소프트웨어 아키텍처 및 애자일 접근법
이 세셕이 [1]의 가장 중요한 부분이라고 할 수 있다.
처음에는 작은 스타트업으로 시작했던 기업이 크게 성장하는 경우에도 여전히 애자일 개발 방법론이 적용된다. 이는 자기조직화(Self-organized)되어 있고 작은 팀들이 책임지고 있는 기능들은 애자일하게 개발이 된다. 예측하기 힘든 여러 상황에서 팀은 이를 해결하며 적응적으로 개발을 진행한다. 특히, 이 애자일리스트들은 이러한 과정 속에서 자신들의 소프트웨어 아키텍처가 창발(emgerge)한다고 믿는다.
그렇지만, 앞에서 이야기 한데로 이러한 여러 팀이 있는 경우라면 회사의 전체 시스템을 이해하기 어렵고 기업에 가지는 전체의 맥락을 이해하기 어려우며 팀이 여러 중복 솔루션이나 호환성을 떨어 뜨릴 수도 있다. 이를 위해서 이러한 문제를 다룰 수 있는 전담인력들이 필요할 수 있다. 즉, 애자일과는 반대 방향일 수 있으나 중앙 집중적인 방법으로 관리되어 참조 아키텍처(Reference Architecture)으로 관리되어야 한다.
두 가지 측면이 반대이고 호환되지 않는 것 처럼 보일 수 있다. 하지만, [1]에서는 SAFe의 Agile Architecture를 설명하면서 이 두가지가 호환되며 상호보완적이라고 주장한다. 기존과 가장 다른 점은 자기조직화팀의 새로운 디자인을 선행 디자인으로 만들어지는 전체 아키텍처에 통합하면서 진행하는 것이다. 저자는 이를 리트로-피딩(retro-feeding, retrospective, 회고)이라고 한다.
의도적 아키텍처와 창발적 설계의 리트로-피딩(Retro-feeding)[1]
이러한 접근법에서 두 가지 장점을 강조한다.
의도적 아키텍처를 각 팀이 참조하여 필요로 하는 솔루션을 구축할 수 있다.
그러면서도, 팀이 어느 정도의 혁신할 수 있는 여력을 가지고, 이를 의도적 아키텍처에 포함하게 개선하고, 다른 팀이 이를 활용할 수 있게 한다.
이렇게 하기 위한 구조로는 Spotify의 챕터를 [1]에서는 이야기 하지만, 일반적으로 시스템 아키텍트와 어플리케이션 아키텍트 처럼 역할을 나누어 수행할 수도 있을 것으로 보인다.
참고 자료
[1] Miguel Arlandy, "Software Architecture and Agile. Are they both really compatible?" , Feb 19, 2019
아키텍트의 수행 결과인 "아티팩트(artifact 산출물)"이 전달되면, 컴포넌트의 "클래스 다이어그램(상세 설계)"를 그린 뒤
"UI 화면"을 만들고
소스 코드를 개발/테스트 한다.
이 부분에 대해서는 이견이 있을 수 있다. 상세 설계에 해당한다고 보이는 부분도 아키텍처에서 중요하다고 할 수 있는 품질 속성(Quality Attribute, 이 책에서는 아키텍처 특성이라고 하고 있다.)과 관련될 수 있고 이 부분이 아키텍처와 관련된 산출물에 포함되어 설명될 수 있기 때문이다. 이 책에서는 이러한 내용은 명시되어 있지는 않지만, 아키텍트와 개발자의 소통의 중요성을 이야기 하면서 언급되고 있다.
기술 폭(Technical Breadth)
아키텍트이든 개발자 이든 자신이 알고 있는 기술 세부의 범위는 한정적일 수 밖에 없다. 그렇다면, 아키텍트의 이 범위가 어떻게 될까? 책의 저자는 "내가 알고 있는 것", 내가 모른다는 사실을 아는 것" 그리고 "내가 모른다는 사실조차 모르는 것"으로 지식을 설명한다.
지식의 분류[1]
저자는 여기에서 지식의 깊이(Depth)와 폭(Breadth)를 구분하면서 개발자는 이 기술의 폭을 넓혀야 한다고 주장한다. 이 지식의 폭을 넓혀야 하는 이유 중에 하나가 다양한 분야에 전문성을 유지하려고 하면, 어느 하나에도 전문성을 충분히 확보하지 못할 수 있기 때문이다. 두 번째는 김빠진 전문성(stale expertise)이 나타나 자신은 첨단이라고 이야기 하지만, 실상은 낡은 정보만 가지고 있는 경우가 생긴다는 것이다.
정도의 차이는 있을 수 있으나 자신의 전문성을 가지고 다른 분야에도 얕지만 넓은 지식을 가지는 T자형 인재 혹은 제너럴라이징 스페셜리스트(Generalizing Specialist)[2]가 좋은 인재상으로 이야기 된다. 여기서도 깊이와 폭으로 이해될 수 있다. 마치 스펙트럼으로 살펴 보면, 한 분야의 깊이만 아주 깊은 학교의 교수, 전문가를 한쪽 끝으로 생각할 수도 있고 넓이만 아주 넓은 강연자, 이야기꾼을 반대쪽 한쪽 끝으로 생각할 수 있다. 경력이 높은 개발자와 경험이 많은 아키텍트는 모두 이 사이에 있을 것이고 개발자는 스페셜리스트에 이키텍트는 제너럴리스트에 가까울 수 있다. 하지만, 이키텍트들도 획일적으로 한 포인트에 머무르는 것이 아니고, 이 깊이와 폭이 가지각색인 것을 쉽게 예상할 수 있다.
기술 지식의 깊이와 폭[1]
트레이드오프 분석
저자들은 아키텍처 사고(Architectural Thinking)의 요체를 다양한 솔루션과 기술 간의 트레이드오프를 이해하고, 분석하고, 조율하는 것이라고 한다. 책에서는 간단하지만 좋은 비교를 통해서 이 부분이 담고 있는 내용이 어떤 것인지 설명한다. 대표적인 소프트웨어 아키텍처 설계 방법인 속성 주도 설계(ADD, Attribute Driven Design)[3]에서는 품질 속성을 요구사항으로 도출해 내고 여기에 맞는 설계 전략 혹은 아키텍처 패턴/스타일을 적용[4]하는데, 여기에서 다루게 되는 것이 결국은 트레이드오프가 된다고 볼 수 있다.
책[1]에서는 경매 시스템을 구현할 때 컴포넌트 간의 연결을 Queue 혹은 Topic을 사용하였을 때, 트레이드오프에 대해서 논의 한다. 실재 설계할 때에는 접근 방법이 다르지만, 여기서는 우선 두 기술의 장점/단점을 비교하여 트레이드오프가 두드러지게 하였다.
토픽의 장점/큐의 단점
토픽의 단점/큐의 장점
아키텍처 확장성(extensibility, 책에서는 신장성) 서비스 디커플링
보안 서로 다른 계약 혼용 모니터링과 프로그래밍 방식의 규모확장성(Scalability)
Queue/Topic의 장단점 비교
실재로는 어떻게 될까? 여러 요인이 있겠지만 시스템의 품질 속성과 같은 여러 요소들에 따라 더 적절한 기술을 선택해 가는 것이 아키텍처 설계가 된다.
아키텍처와 코딩 실무 간의 균형 맞추기
이 책의 저자 뿐 아니라 다른 책의 저자들도 이야기 하지만, 아키텍트도 개발자로서 코딩 실무를 놓지 말아야 한다는 이야기를 많이 한다. 저자는 특히 이러한 균형을 맞추는 여러가지 방법을 제안하고 있고, 아주 실용적인 예들이기도 하다.
개념 증명(Proof of Concept, PoC)를 주주 해보자
개발팀이 아주 중요한 유저 스토리 작업을 할 수 있도록 기술 부채(Technical Debt) 스토리나 이키텍처 스토리에 전념한다.
개발 이터레이션을 하는 도중에 버그를 잡는다.
개발팀 일상 업무를 간소화 하거나 자동화 하는 간단한 커맨드라인 도구나 분석기를 만든다. 아키텍처 컴플라이언스 보장을 자동화 하는 피트니스 함수 측정기로 쓸 수 있는 아치유닛(ArchUnit)을 이용할 수 있다.
자주 코드 리뷰를 한다.
4번 자주 하고 있는 것 중에 하나이다. 또한, 5번은 코드의 흐름을 놓치지 않을 수 있는 좋은 접근 방법이기도 하다.
참고 문서
[1] 마크 리처즈, 닐 포드, "소프트웨어 아키텍처 101 (Fundamentals of Software Architecture)", 한빛 미디어, 이일웅 옮김, 2021
[2] 위르헌 아펄로, "매니지먼트 3.0" 에이콘, 조승빈 옮김. 2019
[3] 렌 베스, 폴 클레멘츠, 릭 캐즈먼, "소프트웨어 아키텍처 이론과 실제, 개정 3판" 에이콘, 전병선 옮김, 2015
현대 산업 개발에서 시공하고 있는 광주 아이파크가 붕괴된 사고가 발생하고 이러한 메시지를 담고 있는 여러 번의 포스팅을 보았다.
애자일을 지지하는 입장에서 나도 동어반복을 하고 싶다는 생각이 먼저 들었다. 하지만, 변호 혹은 변명이라는 것이 우리가 해야 하는 일일까?
어떤 기사에서는 건설사가 애자일을 인력 효율화를 위해서 사용해서 그렇다고 한다. 또 다른 기사에서는 수십톤의 콘크리트 받침대 구조물을 설치했는데 이를 받치는 임시 지지대를 무단 철거한 것이 원인이라고 추정한다고 한다. 콘크리트 양생 시간을 충분히 해야 하는데, 겨울이고 해서 그렇다는 기사도 보인다.
이 사고 이야기를 듣고 가장 먼저 떠오른 것은 김양민 교수의 "불확실을 이기는 전략: 센스메이킹" 책에서 읽었던 챌린저호의 폭발 사건에 대한 것이었다.
책에서는 다이엔 본의 "챌린저호 발사결정: 나사의 위험한 기술 문화, 그리고 일탈"이라는 글의 내용을 주로 다룬다.
기술적인 결론은 외부 추진용 로켓에는 문제 발생 시 경고를 보내기 위한 센서가 없었으며, 오른쪽 추진용 로켓의 불소고무로 만들어 진 O링이 차가운 온도에 탄력성을 잃어 제 기능을 하지 못해서 폭팔이 발생했다고 한다.
하지만, 다이앤 본은 발사를 결정한 것에 대해서 더 집중한다. 놀라운 것은 발사의 결정은 나사의 지극히 '합리적인 근거'로 리스크를 계산하여 내린 판단이라는 것이다.
NASA의 의사 결정 구조를 잠시 살펴 보자. 의사 결정자는 대부분 기술자들이고, 조직의 피라미드 밑에서 위로 결정이 이루어지는 방식이었고, 공개된 토론을 통해 결론에 도달한다. 그들의 결정은 일상적으로 되풀이 되고 철저하게 기술적인 것들이라는 것이다. 아주 정상적이고 올바르게 동작할 것처럼 보인다.
NASA에서 이러한 의사 결정을 할 때, '수용 가능한 위험'이라고 믿는 기준에 따른다고 한다. 다이엔 본은 여기에 비정상 또는 일탈(deviance)에 너무 익숙해져서 최소한의 안전기준을 충족하지 못하는 상황이 되어도 이상하게 생각하지 않는 일탈의 보편화(Normalization of deviance)과정이 관련되어 있다고 이야기 한다.
발사 결정 전에 NASA에서 50번 이상이나 O링과 직간접적으로 연관된 문제를 다뤘다고 한다. 여기에는 실무와 매니저들이 참여해서 리스크가 수용 가능한지 리뷰를 한다고 한다. 실재로 여러 시험 비행을 통해서 O링과 관련된 문제는 수용 가능하다고 결론이 났다. 하지만, 허용 온도가 있었다.
문제는 발사 당일의 날씨와 이 문제가 만나서 발생했다고 볼 수 있다. 발사 당일은 허용 날씨 기준에서 벗어난 온도였다고 한다. 이 부분도 실무나 매니저 단에서 놓친 것일까?
그렇지 않다. 발사 전날에도 이건은 이슈화가 되었지만, 최종 결정에서는 "우리는 이제 경영상이 결정을 내려야 합니다." 그리고 "이제는 엔지니어의 모자를 벗고 경영자의 모자를 써야할 시간"이라는 말로 발사가 결정되었다고 한다.
경영진도, 매니저도, 실무도 모두 올바르게 한 것 같은데 그럼 무엇이 문제였던가? 유명한 물리학자 리차드 파인만도 이 사고 분석에 관련이 있었다고 한다. 그는 관리자들이 치명적 고장 발생 확률이 1/10만이라고 주장했지만, 실무는 1/200이라고 추정한다는 부분을 발견했다고 한다. 즉, 소통 및 이해의 정도에서 차이가 쌓이면서 발생한 것으로 보인다. 김양민 교수의 "불확실을 이기는 전략: 센스메이킹" 책에서의 결론은 소수 의견에 대한 처리 방식에 문제가 있다고 지적한다. 김교수의 책에서는 악마의 변호인을 소수 의견에 대한 처리 방식으로 제안을 하고 있다.
다시 돌아와 보자. 우리는 아파트 붕괴 사고에서 자세히 살펴 봐야할 것은 무엇일까? 부실 시공과 같은 기술적인 디테일도 중요하다. 지켜야 하는 건설의 절차와 관련된 프로세스도 중요하겠다. 하지만, 챌린저 호 사건에서 지적되었던 것 처럼 소통의 문제 혹은 우리가 모르는 것에 대한 센스메이킹에 대한 것들과 같은 것도 살펴바야 할 것이다.
이 부분은 애자일을 따르던 기존 방식을 따르던 상관없이 중요한 것이다.
나는 애자일에서 회고를 가장 중요하게 본다. 그리고, 특히 빠르게 실패하고 배우자는 모토를 좋아한다. 이미 실종자가 6명인 상태에서 이렇게 이야기 하는 것 차체도 많이 조심스럽다. 하지만, 우리가 여기서 배우지 못한다면 이러한 사고가 반복될 것이고 그것이 더 불행한 상황을 맞으신 분들에게 더 송구한 일이라는 생각이다.
많은 종이책을 정리했지만, 여전히 활자로 보는 것과 전자책은 달라서 옆에 두고 보는 책이 여전히 많다. 낡은 책장을 반 이상 버려, 현재는 쌓아 놓는 책이 많아 정리하게 되었다.
정리하면서 내 나름의 분야로 분류해 봤을 때, 2가지 분야의 책이 가장 많다. 하나는 담당 업무에 대한 책 하나는 애자일 관련이다.
담당 업무 관련은 소프트웨어(Language, Algorithm), 설계(Object Oriented Design, SW Architecture), 네트워크(Computer network, Mobile network) 그리고 멀티미디어(Codec, Signal processing)가 그것이다.
애자일 책에는 방법론(Scrum, Kanban, Lean), 이론(복잡계, 팀, 리더십, 디자인 싱킹)이 그 아래 큰 분류라고 할 수 있다.
위에 모습은 당연한 것 처럼 보인다. 반대로, 의외인 부분은 역사 관련 책이다. 소설으로는 '삼국지', '한제국 건국사', '파운데이션'이 보인다.또한 '스티브 잡스'(영문판도 있다), 'iCon', 'Geeks', 'Just for Fun'과 같은 Nerd들의 이야기도 책장에 꽂혀 있다. '총균쇠', '역사의 역사', 심지어 아일랜드에서 구했던 Primary School에서 사용되는 History Textbook 3권을 보니 줄을 그어가며 보았던 부분이 보인다.
또 다른 흥미로운 것은 글쓰기를 포함한 공부에 관한 책이 좀 있다는 것이다. 아이 공부 관련도 있었겠지만, 그 전에도 자기 개발서 처럼내가 그런 책을 사모우고 있었다는 것이 흥미롭다.
고등학교 때 구해 가지고 있는 초판이 1980년이고 1989년 8판 책으로 가지고 있는 '혼비 영문법', 그 이후에 구해 가지고 있는 여러 영어 공부 방법에 대한 책과 최근 동명이인 고등학교 동창의 저작인 '영어는 개소리'도 이와 연결되어 있다고 생각된다.
"신호와 소음"은 "슈퍼 예측"에서도 언급되었고 또한 미국 선거 예측으로 유명한 네이트 실버의 책이다. 책이 크게 4개의 섹션으로 나뉘어 있다. 첫 번째 섹션인 '예측에 대한 근본적인 의문들'에서는 여러 사례들을 통해서 예측에 관해 이야기를 한다.
1장 '경제: 경제 붕괴, 왜 전문가들은 예상하지 못하는가'에서는 리먼 브라더스를 시작으로 한 경제 붕괴에 대한 이야기이다. 많은 이들이 이 사건을 블랙 스완이라고 한다. 하지만, 이 사건을 배경으로 하는 영화 '빅 쇼트'에서도 나오지만, 여러 조짐이 시장에서 보였다. 책에서도 주택가격 폭락은 블랙 스완이 아니고, 모두 알고 있지만, 이야기 하지 않고 큰 문제를 가리키는 '방 안에 들어와 있는 거대한 코끼리'였다고 이야기 한다.
특히 이 장에서는 위험과 불확실성에 대해서 구분하여 설명한다. 위험은 가격을 설정할 수 있다. 측정할 수 있는 위험의 예에는 포커에서 하나가 틀린 스트레이트가 완성될 확률은 정확히 1/11이라고 한다. 반면에 불확실성은 측정하기 어려운 위험이다. 불확실성에 대한 예측은 100배 빗나갈 수도 있고, 1000배 빗나갈 수도 있다. 저자는 위험은 자유시장 경제의 바퀴에 윤활유를 칠하지만, 불확실성은 바퀴를 갉아 멈춰 서게 한다고 이야기 한다.
특히, 시장 경제에서 탐욕과 공포는 변덕스럽다고 이야기 한다. 이 둘은 시장의 균형을 만들지만, 또 둘 사이의 균형은 언제든 흔들릴 수 있다고 이야기 한다. 탐욕 과잉은 거품 그리고, 공포 과잉은 공황을 만들어낸다고 설명한다.
빅 쇼트 영화에도 나왔지만, 역사적으로 일어나지 않았다고 그것이 일어나지 않을 것이라 믿는 것은 문제가 있다. 부동산은 안전하다고 믿는 것은 문제가 있다는 것이다. 또한, 여유 마진이 없는 경우 조금만 잘못되어도 겉잡을 수 없다는 것이다. 또한 빅 쇼트 영화에서 계속 나오는 것이 자산의 평가가 구조적인 문제로 계속해서 잘못되고 있었다는 것이다. 즉, 표본 외 상황이 발생하고 그에 대한 대비가 되어 있지 않은 상태에서 위기가 왔던 것이라 볼 수 있다.
2장에서는 네이트 실버가 유명해진 선거 결과를 예측 하는 것에 대한 이야기를 한다. 여기서는 "슈퍼 예측"의 테틀록의 그 이전 연구인 '전문가의 정치적 판단(Expert Political Judgement EPJ)'를 언급한다. 특별히 여기서 인용한 부분은 전문가들의 경우 하나같이 동전을 던져 판단을 내릴 때보다 낫지 못했다라는 매우 공격적인 비판이다. 그러면서, 예측을 하는 사람들을 고슴도치와 여우 두 부류로 나눠서 설명한다. 그러면서, 여우는 경험에서 예측을 업데이트 하면서 정확도가 높아진다. 반면, 고슴도치는 자기 편견의 강화 가능성이 더 높아져서 정확도가 더 나빠진다고 설명한다. 즉, 우리는 분석 작업에서 어느 한쪽을 응원하는 마음은 접어두고, 여우의 접근 방법으로 우리가 다루는 사실 그 자체에 접근할 필요가 있다고 주장한다.
예측하는데 도움이 될 수 있는 여우의 원칙은 다음과 같다고 설명한다.
1. '확률적으로 생각하라'라는 것이다. 즉, 결과가 일어날 가능성을 범위로 제시하는 것이다. 이 것은 실제 현실에서의 불확실성을 가장 정직하게 표현하는 것이라 볼 수 있다.
2. 날마다 새로운 예측을 하라는 것이다. 상황은 계속해서 달라질 수 있다. 그리고, 옛날의 예측이 잘못된 것이 분명하다면 어제의 예측이 매달릴 이유는 없기 때문이기도 하다.
3. 집단지성을 활용하라는 것이다. 책에서는 집단 예측이 개인 예측보다 10~25% 정확하다고 언급한다.
저자는 예측 작업을 할때 양적인 접근을 좀더 선호한다. 그러면서, 객관적이라는 것이 계량적(Quantitive)와 동의어로 사용한다고 이야기 한다. 또한, 객관적이라는 것을 개인적 편향과 편견 너머에 있는 진리를 바라본다는 뜻이라고 이야기 하고 있다. 이렇게 하기 위해서 계량적으로 측정하는 것도 편견을 배재하는데 도움이 될 수 있다고 생각한다.
'예측에 대한 근본적인 의문들' 섹션의 마지막 3장에서는 "야구: 야구경기는 왜 모든 '예측'의 모델이 되는가'이다. 제목에서도 알 수 있듯이, 야구에서의 예측에 관한 것이고 이것은 영화 '머니볼'로도 알려진 머니볼에 대해서 이야기 하고, 최근에 한국에서도 유명했던 드라마 '스토브 리그'도 생각하게 하는 챕터였다.
저자는 좋은 야구 예측 시스템은 다음 세가지 기본 사항을 갖추어야 한다고 이야기 하면서, 아래와 같이 설명한다.
1. 각 선수의 통계 자료가 갖는 맥락의 의미 설명하기
2. 실력과 운을 분리하기
3. 노화곡선(선수가 나이와 성적의 관계) 이해하기
우선 야구 선수에 대한 예측을 이야기 한다. 즉, 한 선수가 언제까지 좋은 성적을 내며 뛸 수 있을까가 중요한 질문일 수 있다. 사실 야구 선수의 실력은 고정된 게 아니라 끊임없이 변한다. 바로 여기 예측가의 도전과제가 있다고 저자는 이야기 한다. 이론적인 노화곡선은 '평균적으로 볼때만'매끄러운 곡선 모양이다. 선수는 신인에서 시작하여 스물 일곱살에 절정기를 맞고 떨어지기 시작한다. 그러나 실재로 선수 개개인의 측면에서 보면 노화는 선수마다 다른 속도로 진행된다. 또한, 지독할 정도로 소음이 많다.
머니볼적이 측면에서 이 예측을 활용해야 하는 사람들이 스카우터일 것이다. 하지만, 머니볼이 처음에는 성공했을지 모르지만 통계학자들이 계속적으로 성공을 한 것이 아니다. 스카우터들도 혼합 방식의 접근법을 사용하는 것이다. 즉, 보이지 않는 요소들도 고려하는 것이다.
책에서는 정신적 도구 상자(mental toolbox)라고 소개하는 어떤 선수가 메이저리그에서 성공할 것으로 예측하는데 도움이 된다고 그가 믿는 지적/심리적 능력 다섯 가지를 소개한다.
(1) 준비성과 노동 윤리 : 날마다 프로답게 프로 수준의 기량을 펼쳐야 한다. 일정한 량의 훈련을 반드시 해야한다.
(2) 집중과 초점 : 선수가 경기중에 취하는 태도와 관련이 있다.
(3) 경쟁심과 자신감 : 실패의 두려움을 극복할 정도로 더 높은 성공을 거두고야 말겠다는 바람과 각오가 있는가
(4) 스트레스 관리와 겸손 :
(5) 적응력과 학습 능력 : 새로운 정보를 얼마나 성공적으로 처리하는가? 조언에 귀를 기울이는가? 변화에 어떻게 대응하는가?
책에서는 머니볼이 죽었다고 이야기 한다. 죽었다고 이야기 하기에는 과장된 느낌이 있다. 이미 모든 사람들이 그것을 채용하고 있기 때문이다. 만일 그것을 채용하지 않았다면 다 뒷쳐졌을 것이다. 어찌 보면 머니볼만 보던 사람들은 다른 사람들이 하고 있는 유용한 것을 놓치기 때문에 도리어 뒷쳐질 수도 있다. 그렇다면 진정한 머니볼은 죽었을지 모른다. 좋은 발상을 했다더라도 금방 다른 사람들이 달려 들어 그걸 베끼고 그들 자신을 제쳐 버리기 때문이다.
최근에 보고 있는 미드 Foundation의 대사가 생각이 난다. “You can't save yourselves, but you can save your legacy.”
참고 문헌
[1] 네이트 실버 저/이경식 역, '신호와 소음 미래는 어떻게 당신 손에 잡히는가,' 2014년 07월 11일
조지 페어뱅크스의 "Just Enough Software Architecture: A Risk-Driven Approach"[1]은 성공적으로 소프트웨어를 만드는 것이 "가능한 실패를 예상하고 실패할 수 있는 설계를 피하는 것을 의미"한다고 이야기 한다. 그렇기 때문에 실패 리스크를 찾고 이것에 매핑하는 소프트웨어 설계 테크닉을 적용하는 것이라고 한다.
책에서 말하는 리스크 주도 모델의 경우는 다음과 같은 단계를 거치면서 반복하는 과정이라고 말한다.
리스크 식별/우선 순위 지정
적용할 테크닉 선택/적용
리스크 감소의 평가
소프트웨어 개발은 설계만으로 끝나는 것이 아니고 구현을 해야 한다. 그러므로 다음과 같은 예의 논리를 바탕으로 진행하는 것을 제안한다.
"A, B 그리고 C를 리스크로 식별하고, B는 매우 중요하다. 이를 위한 테크닉 X와 Y를 통해 B의 리스크를 줄일 수 있다고 판단했다. 결과물인 설계를 평가했을 때, B의 리스크가 충분히 완화되어 구현을 계속 했다."
리스크란 무엇인가?
책에서 이야기 하는 리스크의 정의는 "인지된 실패 확률*인지된 영향"이라고 정의 한다. 즉, 인지되지 않은 실패 혹률을 리스크로 판단할 수 없고, 실패로 인한 소프트웨어 프로젝트로의 영향도 파악할 수 없다면 리스크는 확인할 수 없는 것이다.
리스크의 구분은 크게 엔지니어링 및 프로젝트 관리 리스크로 나눈다. 일반적으로 엔지니어링 리스크는 제품의 분석, 설계 및 구현과 관련된 사항이고, 프로젝트 관리 리스크는 일정, 작업 순서, 팀 규모 등과 관련된 것들이다. 여기서 말하는 리스크는 엔지니어링 리스크와 관련되고 이를 해결하기 위한 엔지니러링 테크닉을 적용하는 것이 일반적이다.
리스크의 식별의 경우는 요구 사항에서 하는 것이 일반적이다. [2]에서 설명한 것과 같이 소프트웨어의 요구 사항에서 아키텍처적으로 중요한 요구 사항(Acrhitectural Significant Requirement, ASR)을 추출과 연결 시켜 보면, 추출된 요구 사항(기능적 그리고 비기능적 요구사항/품질 속성)에서 중요한 것을 찾는 것이 기존 방법과 다르게 리스크라는 관점에 중점에 두고 선정하는 것이 차이일 수 있다. 여기서 가장 달성하기 어려운 것을 찾는 것이 방법이라고 할 수있다.
개발하는 소프트웨어의 도메인에 따라 주로 발생하는 원형적 리스크(Prototypical Risk)도 있다. 예로는 아래와 같은 것들이 있다.
프로젝트 도메인
원형적인 리스크
정보 기술(IT)
복잡하고 잘 이해되지 않은 문제 실제 문제를 해결하고 있는지 확실하지 않음 잘못된 상용 기성품(COTS) 소프트웨어를 선택 잘 이해되지 않은 기존 소프트웨어와 통합 사람들에게 흩어져 있는 도메인 지식 수정가능성(modifiability)
시스템
성능, 신뢰성, 크기, 보안 동시성(concurrency) 구성(composition)
웹
보안 애플리케이션 규모확장성(scalability) 개발자 생산성/표현성(expressability)
적용 테크닉
리스크를 인식하고 나면 리스크를 줄일 수 있을 것으로 예상 되는 테크닉(Techique)을 적용할 수 있다. 조지 페어뱅크스는 기존에 방식에서 지혜를 얻고 있다. 소프트웨어 아키텍처 설계에서 사용되는 전술(Tactics)[3] 혹은 패턴(Pattern)을 예로 들고 있다.
이와 같은 테크닉은 수 없이 많을 수 있다. 하지만, 시간과 돈을 낭비하지 않으려면 우선 순위가 지정된 리스크 목록을 가장 잘 줄이는 테크닉을 선택해야 한다. 즉, 최적화 문제로 생각하고 접근해야 한다. 이러하듯, 엔지니어링 리스크를 완전히 제거할 수 없는 이유는 주로 프로젝트 관리 리스크인 비엔지니러링 리스크와 균형르 이루어야 하기 때문이라고 책[1]에서는 이야기한다.
이와 같은 제약 뿐 아니라 적용할 테크닉의 선택을 위해서 문제의 종류(답을 찾는 문제/증명 문제), 모델의 종류(분석 모델 및 유추 모델)에 따라 다르다고 한다. 그리고, 설계를 바라 보는 관점이라고 할 수 있는 뷰타입(Viewtype)의 경우는 리스크와 테크닉의 쌍(Pair)에 효과를 다르게 하기 때문에 어떤 것이 적절한지 매칭(matching)을 고려해야 한다고 이야기 한다.
언제 멈추는가?
소프트웨어 아키텍처를 설계에는 중요한 두가지 질문은 "어떤 테크닉을 사용하는가?" 그리고 "얼마나 설계와 아키텍처를 수행하는가?"라고 할 수 있다. 리스크 주도 설계에서는 아주 단순히 답한다면 "충분히 리스크가 줄어 들 때까지 설계한다"가 답일 수 있다.
이를 위해서는 설계에 들이는 노력은 "리스크에 상응해야 한다"라고 한다. 저자는 아버지의 집앞에 우편함을 만드는 이야기를 하면서 단순하게 땅을 파고 우편함을 묻기만 하면 될 일을 위해서 측량을 한다거나와 같은 높은 건물 건축에서 사용되복잡한 설계나 리스크를 측정하는 테크닉을 적용할 필요가 없다는 것이다.
불완전해 보일 수 있지만, 리스크 모델에서는 리스크가 인식되는 영역만 설계한다는 부분과 리스크 평가가 주관적인 평가라는 부분 또한 언급한다. 이 부분은 단점일 수 있지만, 여전히 장점이기도 하다.
계획된 설계와 진화적 설계
책[1]에서는 소프트웨어 개발에 사용되는 설계 접근 방식을 계획된 설계(Planned design)과 진화적 설계(Evolutionary design)으로 나눈다. 리스크 주도 설계는 이 두가지 설계 방식에 모두 적용 가능하다고 책에서는 주장한다.
진화적 설계의 경우, 주로 애자일 소프트웨어 개발 방식에서 사용하는 방식이다. 시스템이 구현됨에 따라 설계가 확장되기 때문에 지협적이고 파편화된 설계 결정이 여러 문제를 발생 시킨다. 이러한 단점을 해결하는 방법으로 리펙터링(Refactoring), 테스트 주도 설계(Test drivn design), 지속적인 통합(Continous integration)이 제안되어 채영되고 있다. 여전히 아키텍처적 입장에서는 좋은 지침에 제공되고 있지 않다고 지적하고 있다.
계획된 설계는 진화적 설계의 반대쪽 끝에 있다고 설명하며, 실재 구현 이전에 설계를 자세하게 작성하는 것이다. 하지만, 이는 지나친 선행 설계(Big Design Up Front BDUF)라고 비판을 받는다. 앞에서도 이야기 한 저자의 아버지 우편함에 대한 예가 주요 내용이라고 볼 수 있다.
위의 두 가지는 양쪽 극단이다. 마치 스펙트럼 같은 것일 수 있다. 이 중간에는 최소 계획된 설계(Minimal planned design) 또는 작은 선행 설계(Little Design Up Front LDUF)가 있다.
이러한 접근 방법들은 서로 다른 지지자들이 있다. 또한 책에서는 만병통치약이 없듯이 다른 시스템에서는 다른 방법이 적절하다고 이야기 한다. 또한 둘은 다르고, 장점 또한 다르다. 이케텍처 설계를 한다는 것은 장기적인 관점을 가지고 시스템 전체의 속성을 보장하는 장점을 가진다. 진화적 설계는 앞에서 살펴 보았듯이 리펙터링, TDD 그리고 지속적 통합(CI)의 장점을 활용할 수 있다.
프로세스에 적용하기
리스크 주도 소프트웨어 설계를 여러 프로세스에 적용하기 위해서 몇가지 프로세스의 특징을 우선 아래와 같이 정리하고 있다.
프로세스
선행 설계
설계 본질
작업 우선순위
반복 길이
폭포수
분석 및 설계 단계
계획된 설계, 재설계 없음
개방적
개방적
반복적
선택적
계획 또는 진화, 재설계 허용
개방적이고 종종 기능 중심
개방, 보통 1-8 주
나선
없음
계획 또는 진화
가장 위험한 작업부터
개방적
UP/RUP
선택적, 사전 설계 전반부 배치
계획 또는 진화
가장 위험한 작업 후, 가장 높은 가치
보통 2~6 주
XP
없음, 일부 반복 제로(Iteration zero)
진화적 설계
가장 높은 고객 가치 우선
보통 2~6주
우선 애자일 개발 프로세서인 eXtream Programming(XP)에서는 일반적으로 설계 작업이 없지만 반복 제로(Iteration zero)를 두고 설계 작업을 할 수 있다. 이렇게 반복적인 작업에서 리스크 주도 기반 접근법은 각 단계에서 필요한 만큼 설계 작업을 진행할 수 있다.
반복적 프로세스에서 단계별 설계의 양이 다른 예
대표적인 애자일 프로세스인 스크럼은 기능 중심적 접근 방법으로 백로그에 구현할 기능을 관리한다. 여기에도 리스크 주도 접근법을 적용할 수 있다. 일반적인 기능 백로그는 제품 책임자(Product Owner)가 담당한다. 재품 책임자는 엔지니러링 리스크를 파악하기 어렵다. 대신 소프트웨어 팀이 리스크를 파악하고 이를 시스템의 테스트 가능한 기능으로 만들어 백로그에 넣을 수 있다. 이는 각 반복이 끝날 때 회고(Reflection/Retrospective)의 결과로 도출될 수 있다. 제품 책임자는 백로그 중에서 우선 순위에 따라 각 단계에 수행할 내용을 결정할 수 있다.
기능 및 리스크 백로그 활용방안
정리해보면...
리스크 주도 설계 접근 방식의 주요 내용은 설계에 많은 비용이 들기 때문에 리스크를 찾아 내고 이에 적절한 테크닉을 필요한 만큼 반복적으로 적용한다는 것이다. 이는 현재 소프트웨어 개발에서 적용되고 있는 양극단의 소프트웨어 개발 방법에서 모두 적용할 수 있다고 책에서는 주장하고 있다.
특히, 애자일 혹은 반복적 개발에서 알 수 있는 주요한 내용 중 하나가 설계가 항상 개발 프로세스의 앞부분에서만 진행되어야 하는 것은 아니라는 점이다. 후반부에 설계를 하게 되면설계를 변경하기 어려운 부분도 있을 수 있으나 구현하려고 하는 소프트웨어를 초기에는 잘 알지 못하는 문제점도 있다는 것을 책에서는 지적하고 있다. 소프트웨어 개발이 지식을 얻어 가는 과정이라면, 이를 이를 소프트웨어 설계 및 아키텍처링에 적용하는 방법으로서 리스크 주도 접근 방식의 장점과 적용하는 방법에 대해서도 흥미로운 재안을 하고있다.
참고 도서
[1] George Fairbanks, "Just Enough Software Architecture: A Risk-Driven Approach," 2010
