로버트 C 마틴 보기

로버트 C 마틴의 책들에 대해 이야기해보려 합니다.
로버트 C 마틴은 1970년대 부터 소프트웨어 개발자로 살아온 소프트웨어 업계의 전설적인 멘토입니다. 우리나라에 소개된 그의 책은 클린 시리즈 5권과 UML에 대한 책 이렇게 6권인데요. "클린 코드"를 읽고 감명받았던 저는 나머지 5권을 모두 구해서 읽었습니다.

• 클린 코드
• 클린 코더
• 클린 아키텍처
• 클린 소프트웨어
• 클린 애자일
• UML 실전에서는 이것만 쓴다

책을 읽으면서 메모해 두었던 주요 키워드를 중심으로 그 내용에 대해서 이야기해보도록 하겠습니다.

로버트 C 마틴의 법칙

로버트 C 마틴 하면 가장 유명한 법칙 두 가지가 있습니다. "보이스카웃 법칙", 그리고 SOLID 법칙입니다.

보이스카웃 법칙은 다음과 같습니다.

캠프장은 처음 왔을 때보다 더 깨끗하게 해 놓고 떠나라
- 클린 코드 -

소스코드를 가져오면(pull), 조금이라도 깨끗하게 만들어서 push 해야 한다는 이야기입니다. 만약 팀 인원 모두가 이런 방식으로 코드를 관리한다면 그 회사의 코드는 아주 깨끗하게 되겠죠.

그다음 SOLID 법칙입니다.

이 원칙들은 다음과 같다.
SRP: 단일 책임 원칙(SingleResponsibility Principle)
OCP: 개방 폐쇄 원칙(Open-Closed Principle)
LSP: 리스코프 치환 원칙(LiskovSubstitution Principle)
DIP: 의존 관계 역전 원칙(DependencyInversion Principle)
ISP: 인터페이스 분리 원칙(InterfaceSegregation Principle)
- 클린 소프트웨어 -

로버트 C 마틴은 <클린 소프트웨어>뿐만 아니라 <UML 실전에서는 이것만 쓴다>에서도 SOLID를 설명하고 있습니다. <클린 아키텍처>에서는 SOLID를 어떻게 생각해 냈는지 설명하고 있는데요. 1980년대부터 유즈넷에서 사람들의 의견을 취합했다고 합니다. 그리고 결정적으로 2004년 무렵 마이클 페더스가 이메일을 보내서 글자의 배열을 SOILD로 해보지 않겠냐고 제안했다고 하네요.  ( 마이클 페더스는 <레거시 코드 활용전략>이라는 책의 저자입니다. )

SOLID는 객체지향 설계 원칙으로 알려지기 시작했는데요. <UML 실전에서 이것만 쓴다>에서 SOLID를 언급한 것을 보면, UML이 지향하는 바가 결국 객체 임을 이해할 수 있습니다. 특히 <UML 실전에서 이것만 쓴다>에서는 RUP(Rational Unified Process)에 까지 연결하고 있는데요. RUP은 UML으로 소프트웨어 개발 프로세스를 진행하는 소프트웨어 개발방식입니다. 

애자일

특히, 로버트 C 마틴은 애자일 선언문을 만들었던 사람들 중에 한 명입니다. <클린 애자일>에서는 애자일 선언 당시 "스노버드 산장"의 분위기에 대해서도 언급하고 있습니다.

나는 그렇게 많은 사람이 참여하겠다고 한 것에 꽤 놀랐다. 대체 누가 '경량 프로세스 회담'이라는 회의에 진짜로 가고 싶겠는가? 하지만 이렇게 스노버드의 산장 Lodge 내 아스펜 회의실에 사람들이 모였다.

17명의 참가자는 서로 다른 몇 가지 관점을 대표했다. 먼저 다섯 가지 경량 프로세스가 있었다. 가장 많은 사람이 참석한 것은 XP 팀으로 켄트 벡, 나, 제임스 그레닝, 워드 커닝햄, 론 제프리즈가 있었다. 다음은 스크럼팀으로 켄 슈와버, 마이크 비들, 제프 서덜랜드가 참가했다. 존 컨이 기능 주도 개발을 대표했고, 아리 반 벤네쿰이 동적 시스템 개발방법 DSDM을 대표했다. 마지막으로 앨리스터 코오번이 자신의 크리스털 계열 프로세스를 대표하여 참석했다.

한편 그 밖의 참가자는 특별한 소속이 없었다. 앤디 헌트와 데이브 토머스는 실용주의 프로그래머였다. 브라이언 매릭은 테스트 컨설턴트였고, 짐 하이스미스는 소프트웨어 관리 컨설턴트였다. 스티브 멜러는 우리 중 다수가 미심적어하는 모델 주도 철학을 대표했었기 때문에 우리의 틀린 부분을 지적해 줄 수 있었다. 마지막으로 마틴 파울러가 있었다. 마틴은 XP팀과 개인적으로 친분이 있긴 했지만, 멋지게 이름을 붙이고 홍보하는 프로세스에 회의적이었다. 그래도 모두와 공감하는 편이었다.
-클린 애자일-

재미있는 건, 애자일 개발은 처음부터 그런 이름을 쓰지 않았다는 겁니다. "경량 프로세스 회담"이라고 했다는 거죠. 게다가 개발 프로세스에 대한 관점도 5가지나 되었습니다. 17명이 5가지 관점을 가지고 이야기하고 있었다면, 그 결과는 소프트웨어 프로세스라기보다 동일하게 추구하는 철학이었을 겁니다. 애자일 선언문은 개발 프로세스보다 그 철학이 담긴 결과물이 되었고요. 

그럼 애자일이 왜 필요한 걸까요?

 

로버트 C 마틴은 <클린 아키텍처>에서 프로그램을 제대로 만든다는 것이 어떤 의미를 지니는지 설명합니다. 

하지만 프로그램을 제대로 만드는 일은 전혀 다르다. 소프트웨어를 올바르게 만드는 일은 어렵다.
소프트웨어를 제대로 만들려면 적정 수준의 지식과 기술을 겸비해야 하지만 대다수의 젊은 프로그래머는 이 수준에 도달하지 못했다. 또한 사고력과 통찰력을 갖춰야 하지만 대다수의 프로그래머는 시간을 들여 이러한 능력을 개발하지 않는다. 그리고 어느 정도의 훈련과 헌신이 필요하지만, 대다수의 프로그래머는 훈련과 헌신이 필요하리라는 생각 조차 하지 않는다.
소프트웨어를 올바르게 만들려면 무엇보다도 기술을 향한 열정과 전문가가 되려는 열망이 필수다.

반면 소프트웨어를 제대로 만들게 되면 마법과도 같은 일이 벌어진다. 소수의 프로그래머만으로 프로그램이 지속적으로 동작하도록 만들 수 있다. 거대한 요구사항 문서와 이슈가 수없이 등록된 이슈 추적 시스템도 필요가 없다.
전 세계의 칸막이로 나뉜 작은 사무실에서 휴일도 없이 일해야 하는 프로그래머가 없어도 된다.

제대로 된 소프트웨어를 만들면 아주 적은 인력만으로도 새로운 기능을 추가하거나 유지 보수할 수 있다. 변경은 단순해지고 빠르게 반영할 수 있다. 결함은 적어지고 잦아든다. 최소한의 노력으로 기능과 유연성을 최대화할 수 있다.

나를 포함해서 우리 대다수는 대체로 이러한 경험을 했다. 훌륭한 소프트웨어 설계를 바탕으로 작업하면서 즐거움을 느끼기보다는, 형편없는 소프트웨어 설계와 맞서 싸우는 일을 훨씬 더 자주 맞닥뜨린다.
- 클린 아키텍처 -

로버트 C 마틴이 주장하는 핵심은, 소프트웨어를 제대로 만들면, 유지보수 인력을 최소화할 수 있다는 겁니다. <클린 아키텍처>에서는 이를 실제 자료로 설명하는데요. 다음은 <클린 아키텍처>에서 캡처한 도표입니다.

- 클린 아키텍처 발췌 -

시장을 선도하기 위해서 다양한 기능을 추가해 나가는 회사는 그림과 같이 점점 더 많은 개발자를 필요로 했습니다. 하지만 다음 그림과 같이 많은 사람이 들어오더라도 코드 라인당 비용으로 볼 때 유지보수 비용도 함께 늘어나는 것을 볼 수 있습니다.

- 클린 아키텍처 발췌 -

결국, 소프트웨어를 출시할 때마다 인건비는 증가하게 됩니다.

- 클린 아키텍처 발췌 -

인건비가 증가하는 이유는 코드 구조가 그만큼 복잡하기 때문이죠. 그럼 왜 복잡한 코드가 생겨났을까요?

이들 개발자는 "코드는 나중에 정리하면 돼, 당장은 시장에 출시하는 게 먼저야!"라는 흔해 빠진 거짓말에 속는다.
이렇게 속아 넘어간 개발자라면 나중에 코드를 정리하는 경우는 한 번도 없는데,
시장의 압박은 절대로 수그러들지 않기 때문이다.
'시장 출시가 먼저'라는 생각을 하는 이유는 바로 뒤에 여러 무리의 경쟁자가 뒤쫓고 있고,
경쟁자보다 앞서 가려면 가능한 한 빠르게 달려야 하기 때문이다.
- 클린 아키텍처 -

원인은 "빨리빨리!!!"였습니다. 이른바 Time to market 정책입니다. 시장에 먼저 출시해서 빨리 시장을 쫓아가야만 회사가 살아남는다는 경영진의 논리에 개발자들이 넘어갔기 때문이죠. 문제는 시장이 시간을 주지 않는다는 겁니다. 코드를 대충 만들어 놓고 결과를 만들어 내면 그다음에 더 많은 것을 추가해야 합니다. 지속적으로요. 그러면 어느 시점에는 유지보수가 불가능한 순간이 다가옵니다. 

결국 회사의 이익률은 떨어지고 경쟁력도 뒤쳐지게 되겠죠.

 

하지만 그러면 안됩니다. 

 

어떻게 하면 코드를 잘 정리하면서 유지 보수하기 쉬운 코드로 만들어 나갈 수 있는지 고민하던 사람들은 "경량화 프로세스"라는 철학에 동의하기 시작했습니다. 프로세스를 최대한 가볍게 가져가면서, 좋은 코드를 만드는 원칙을 찾아낸 겁니다. 

그런데 "경량화 프로세스"라는 이름이 좀... 너무 가볍군요.

다들 경량이 중요하지 않은 느낌을 준다고 생각했다. 적응Adaptive이라는 단어를 좋아하는 사람도 있었다. 애자일이 언급되긴 했는데, 누군가 그건 지금 군대에서 뜨는 유행어라고 지적했다. 결국 누구도 애자일이라는 단어를 정말 좋아하지는 않았다. 하지만 여러 가지 안 좋은 후보 중에서 그나마 제일 나은 것이었다.
- 클린 애자일 -

결국, 애자일 선언문은 채택되었습니다. 17명의 선각자들의 주장은 폭포수 개발 프로세스로 개발하던 사람들에게 충격으로 다가왔습니다. 

 

좋은 아키텍트는 결정되지 않은 사항의 수를 최대화한다.

​- 클린 아키텍처 -

폭포수 입장에서 정의되지도 않은 아키텍트를 코딩한다는 게 말이 안 되죠. 

프로그래머에게 완벽한 형식의 문서가 있다면, 코드 형태일 것이다. 테스트가 바로 그렇다.
- 클린 애자일 -

마틴 파울러가 리팩터링에서 설파했던 건, "중복은 나쁜 냄새"라는 것이었습니다. 즉, 코드 레벨에서 문서 레벨까지, 동일한 무언가를 설명하는 문서는 단 하나이어야만 합니다. 따라서 코드로 설명 가능한 건, 코드로 남겨두는 것이 가장 합리적이죠. 코드로 표현할 수 있는데 다른 표현방법을 동원하고 있다면, 그건 코딩을 잘못한 겁니다. 

만약 소프트웨어 설계가 요구사항 변경 때문에 퇴화한다면 우리는 애자일 방식대로 하고 있지 않은 것이다.
- 클린 소프트웨어 -

그리고, 

회사가 망한 원인은 바로 나쁜 코드 탓이었다. 
-클린 코드-

만약 회사가 미션을 가지고 있다면, 미션을 위해서 사업을 지속해야 한다면, 애자일을 고민할 필요가 있는 겁니다. 그래야 회사가 망하지 않을 테니까요. 

TDD를 하는 진정한 이유는 이런 것이 아니다. 진짜 이유는 바로 용기다.
-클린 애자일-

우리에게 필요한 건, "용기"뿐입니다. 

 

단일 책임 원칙

단일 책임원칙은 클래스나 모듈을 변경할 이유가 하나, 단 하나뿐이어야 한다는 원칙이다.
- 클린 코드 -

 어떤 클래스를 변경해야 할 이유는 오직 하나뿐이어야 한다. 
- UML 실전에서는 이것만 쓴다 -

하나의 모듈은 하나의 오직 하나의 액터에 대해서만 책임져야 한다.
- 클린 아키텍처 -

한 클래스는 단 한가지의 변경 이유만을 가져야 한다.
- 클린 소프트웨어 -

단일 책임 원칙의 기원은 <클린 소프트웨어>에서 나옵니다. 로버트 C 마틴은 톰 드마르코와 메이릴 페이지 존스의 연구에서 "응집도"라는 개념을 가져왔고 이를 모듈이나 클래스에 맞게 확장했다고 설명하고 있습니다. 

 

단일 책임 원칙은 SOLID에서 처음 나오는 원칙인데요. 단일 책임 원칙을 만족하는 코드는 그다음에 오는 4가지 원칙에도 만족할 수 있는 기틀이 됩니다. 게다가 테스트 가능한 코드가 되려면, 단일 책임 원칙을 만족해야 하고, 테스트가 가능해야만 리팩터링이 가능하고 유지보수가 쉬운 코드로 만들어갈 수 있기 때문에 결과적으로는 가장 근본적인 원칙이라고 볼 수 있습니다. 그래서 그런지, 로버트 C 마틴은 모든 저서에서 단일 책임 원칙을 직간접적으로 다루고 있습니다. 

 

응집도라는 용어로 코드를 바라보면, 상당히 추상적인 느낌을 줍니다. 하지만 "단일 책임 원칙"이라고 말하면, 상당히 구체적인 모양이 상상되죠. 게다가 로버트 C 마틴의 설명을 들으면 더 구체적이 됩니다. 로버트 C 마틴은 "한 클래스는 단 한가지만의 변경 이유만을 가져야 한다"라고 이야기 하고 있거든요. 모듈의 책임이 단일하려면, 이를 수정할 이유도 단 한가지 일 수 밖에 없습니다. 

 

만약 다용도 칼을 사용한다면, 다용도 칼을 수리할 이유는 다용도 칼의 기능 만큼이 됩니다. 하지만 과일깍는 칼을 수리한다면 단 한가지 이유밖에 없습니다. 날이 무뎌진거죠. 

 

<클린 소프트웨어>나 <UML 실천에서는 이것만 쓴다>는 비교적 예전에 출간한 책들이기 때문에 단일책임원칙의 대상이 객체나 모듈에 초점이 맞춰져 있습니다. 그러나 <클린 아키텍처>를 보면, 좀더 포괄적인 영역에서 단일책임원칙을 사용할 수 있겠다고 보여집니다. 

결론

로버트 C 마틴은 상당히 오랜기간 개발을 해온 개발자 입니다. 다양한 프로그래밍 언어를 사용했고, C++이나 Java 쪽에서는 리더로서 역할을 했습니다.  다시 말해 우리가 그의 조언을 받아들이지 말아야할 만한 이유가 없다는 겁니다. 즉, 로버트 C 마틴의 책은 필독서 입니다. 

 

로버트 C 마틴의 책을 읽다보면 두가지 큰 줄기가 눈에 띕니다. 하나는 애자일 다른 하나는 SOLID입니다. 먼저 SOLID는 객체지향설계 원칙이라는 이름으로 설명하기 시작했지만, <클린 아키텍처>에서는 아키텍트 규모로 확장함을 볼 수 있습니다. 

 

그리고 애자일,

애자일 선언을 따르는 대표적인 개발방식인 익스트림프로그래밍은 "변화를 수용하라"는 모토를 가지고 있습니다. 그 이유는 변화가 당연한 것이기 때문입니다. 

우리와 모든 것이 변합니다. 우리 몸을 이루는 원자 98퍼센트가 매년 교체되고, 뼈는 3개월, 피부는 4,5주마다 교체된답니다. IT기술은 2년마다 두배씩 성장합니다. ( 무어의 법칙은 물리적인 원인 때문에 멈추어섰지만 그 기조는 지속되고 있습니다. ) 

 

변화가 자연스러운 것입니다. 

 

하지만, 1970년대, 변화가 자연스럽지 않다는 가정하에 만들어진 개발 프로세스가 소프트웨어 개발 업계를 점령했습니다. 바로 "폭포수 개발 방식"이죠. 로버트 C 마틴도 <클린 애자일>에서 "나는 정말로 믿고 싶었다. 이게 진짜라면 정말 꿈이 이루어지는 것이었으니까."라고 언급하고 있고요. 

하지만 그것은 꿈일 뿐이었습니다. 신기루 같은 존재였죠. 쫓아가면 만날 수 있을 것 같은 오아시스는 없었습니다. 소프트웨어 프로젝트의 실패율이 이를 증명합니다. 

오랜시간 소프트웨어 개발을 하며 폭포수개발이 신기루임을 이해했던 사람들 중 로버트 C 마틴도 있었습니다.  그래서 로버트 C 마틴의 저서에서 애자일이 등장하고, 애자일을 강조하는 것 아닐까 싶습니다. 

 

 

​