얼마전에 한국을 방문하기도 했던 초특급 스타 블로거인 조엘 스폴스키가 한 포드캐스트에서 TDD와 SOLID(OOD Principles)를 공격하는 발언을 해서 Kent Beck이 발끈하고, Robert Martin(aka Uncle Bob)이 반박에 나서는 일이 벌어졌다. 당사자들 보다는 주변의 반응이 더 뜨거웠는데, 때는 이때다 하고 격렬한 논쟁과 비난, 반박, 변호 등이 이어졌다. 수퍼 인기 블로거지만 꼽게 보는 사람이 많은 조엘의 과격한 발언과 언제나 논쟁의 단골 주제인 TDD, 별로 많은 사람에게 알려져 있지는 않지만 언젠가 한번쯤 뜨거운 주제가 될 것으로 예상했던 SOLID까지, 다들 한마디씩 하고 넘어가지 않고는 못견디게 만드는 이슈들이 모여있는 덕분이다. InfoQ에도 이 논쟁을 중간정리해주는 글이 올라왔을 정도니 그 논쟁의 열기가 얼마나 대단했는지 모르겠다.

논쟁은 최근 후속 포드캐스트에서 Joel이 Uncle Bob에게 인신공격을 했던 점에 대해서 사과를 하고 슬그머니 넘어갔다. Joel과 함께 낄낄거리며 SOLID를 씹어댔던 Jeff도 자신의 주장에 과장된 표현이 있었음을 인정했다.

 

논쟁의 내용을 떠나서 관련된 글을 읽어보는 것은 여러가지 흥미로운 생각할 거리를 주는 것 같다. 시간이 남는 사람이라면 한번쯤 링크를 따라 가면서 쭉 듣고(podcast. transcript도 제동된다) 글을 읽어보면 좋을 것이다.

 

단골 논쟁거리인 TDD는 그렇다치더라도 이 번에 그 동안 많이 주목받지 못했던  SOLID원칙이 크게 알려졌다는 점은 상당히 고무적이다. 당연히 SOLID가 원칙이나 법칙으로 불리고, 모든 상황에 기계적으로 적용할 만큼 절대적이라고는 할 수 없다. 그런데, 과연 그렇게 절대화 할 수 있는 법칙이라는게 소프트웨어 개발에 과연 존재하기는 하는걸까? 나에게 어떤 대단한 원칙과 법칙을 주더라도 나는 예외가 있음을 들어 그 주장이 절대적이지 않다고 반박할 자신이 있다. 어떤 좋은 기술과 원칙이든 불필요하게 과용될 수 있도 적용하기에 적합지 않은 상황이 있다.

개발자들이 다들 바보라서 그런 원칙을 들으면 기계적으로 적용하고 맹목적으로 신봉하지 않을 것이다. 그런데 그런 주장을 공격할 때는 항상 극단적으로 개발자들이 잘못 적용한 경우를 구지 가정해서 비난을 한다는 점이 문제이다. 그건 비난을 위한 비난 밖에 되지 않는다. 정말 말도 안되는 주장이나 기술이라면 모를까, 그렇지 않다면 그 의견의 장점이 무엇인지 먼저 살펴보고, 개선할 점과 문제점을 짚어나가는 것이 맞지, 조엘처럼 인신공격적인 발언과 왜곡된 상황을 가정하고 비난하는 식으로 접근하는 것은 한심한 일이다. 심지어 EJB를 까는데 온 힘을 기술였던 로드 존슨 조차도 EJB의 장점에 대해서 면밀히 분석하고, 무엇을 취할 것이고 무엇을 개선하고 무엇을 버릴 것인지 살펴보고 그리고 그 대안으로 스프링을 제시했지, 무조건 EJB는 현장은 모르고 책상 앞에서만 기술을 연구하는 연구원들의 과대망상에서 나온 쓰레기 기술이라고 비난하지는 않았다.

 

조엘의 TDD공격의 시작은 사실 TDD의 교조적인 신봉자들의 극단적인 주장에 대한 반박이었다고 한다. 자신이 쓴 Joel Test라는 글에 등장하는 조건에 100% Unit Test를 추가하라는 공격적인 메일을 받은 것에 대한 반박이었다고 한다. 대단히 많은 메일을 받았는지 아니면 딱 하나 받고선 이 참에 맘에 안들던 TDD좀 까보자 하고 과잉반응 했던 것인지는 모르겠다. 물론 그의 표현을 보면 Kent Beck이 화가 나서 쓴 글에 나오는 것처럼 조엘이 TDD의 개념에 대해서 제대로 이해하고 있는지 극히 의문스럽다. 100% 단위테스트를 만들었는데, 일부 설계가 변경되어서 테스트의 10%가 깨지면 그것을 어떻게 감당할 것인가라는 식의 주장은 그가 단위테스트와 OOD의 기본적인 개념을 이해하지 못하고 있다는 증거가 분명하다. 조엘이 처음 Uncle Bob이 만든 SOLID를 보면(사실 제대로 보지도 않았지만) 제대로 된 개발은 해본적으도 없는 관료적인 탁상공론이나 늘어놓는 사람이 만든 것이 분명하다고 공격했다. 이에 대한 Bob의 반박에 보면 일부 변경이 일어났다고 테스트의 10%가 깨지는 상황을 만드는 실력이라면 조엘은 아예 직업을 바꾸는 것을 고려해야 할 것이라고 비난했는데 그 점에 대해서 99.9% 동의한다. 프레임워크(결국 프로그래밍 패턴이)가 바뀌면서 애플리케이션 전체 구조가 흔들리는 0.1%의 예외가 있기는 하겠지만. 그것도 스프링의 개발철학처럼 POJO개발과 같은 하위 기술에 비의존적인 코드를 만들어서 피할 방도는 얼마든지 있을 것이다.

 

한가지 놀란점은 Kent Beck의 글에 달린 코멘트들인데, 그를 존경하고 따르는 사람이 많은 만큼 그를 극히 싫어하고 그의 주장과 아이디어에 대해서 경멸하는 인간들도 적지 않은 듯 하다.

 

SOLID에 대해서는 최상훈, 송치형님이 마소에 연재한 글을 보면 도움이 될 것이다. 내용은 좋긴한데.. 사실 설명이 좀 어렵긴하다.

또 SOLID에 대한 내용은 "UML실전에서는 이것만 쓴다"라는 책에도 간략히 나와있다. 그 책은 UML이 타이틀로 달려있긴 하지만 사실상 OOD에 관한 책이다. 가장 SOLID에 대해서 깊이 있게 설명하고 있는 책은 Agile Software Development, Principles, Patterns, and Practices라는 책이다. 번역이 되었는지는 모르겠다. C#으로 설명된 Agile Principles, Patterns, and Practices in C#도 있다.

Related posts:

  1. A Framework is… / Kent Beck
  2. JUnit Max – Kent Beck
  3. Martin Folwer와 ThoughtWorks
  4. Kent Beck의 White Paper – Tools for Agility

Facebook comments: