Test-Driven Development

Test-Driven Development(이하 TDD)에 대한 이야기는 몇차례로 나누어서 진행하도록 하겠습니다. 오늘은 Java 환경에서 TDD를 하는데 꼭 필요한 JUnit Framework에 대한 이야기입니다.
 
 
본론으로 들어가기 전에 몇 가지 말씀드리겠습니다. 첫째는 다시 강조해 말씀드리지만 소개하는 책들이나 글들의 대부분은 저도 읽지 못했습니다. 여기 저기서 좋은 책이더라 혹은 좋은 글이더라는 입소문을 정리해놓고 언젠가는 한번 읽어야지 하고 생각하고 있을 뿐입니다. 설사 읽었더라도 10%도 이해하지 못한 수준으로 읽었을 뿐입니다. 그런데 보내는 글마다 "이 글은 저는 못읽었지만, 누가 그러는데 좋더라"라는 식으로 쓰는 게 어색해 보여서 당연히(?) 제가 읽었다는 투로 할뿐입니다.
 
둘째는 그래서 제가 이야기하는 주제에 대해서 저도 잘 모릅니다. 어쩌면 "주제 넘게" 설치고(?) 있는 것인지도 모르겠습니다. 알기 때문에 주장하거나 글을 쓰는 것이 아니라, 주장하고 싶기 때문에 주장하는 것이고 글을 쓰고 싶기 때문에 글을 쓰는 것입니다. 앎의 크기와는 별개로... 무식하면 용감해진다고 하는 것처럼. 제가 쓰는 글들이 학술 세미나에 발표될 논문도 아닌 거의 낙서(?) 수준인데 학문적 엄밀성 같은 건 없습니다. 그리고 알게 모르게 구라(?)도 좀 있습니다.
 
셋째는 제가 쓰는 글들이 "Agile" 적인 것에 집착(?)하면서 다른 것들을 의도적으로 폄하(?)하거나 무시(?)하는 경향이 있다는 것을 알고 있습니다. 금년 KBL 챔피언 결정전처럼 허재를 위해서 김승현과 김병철, 그리고 힉스가 저같은 허재의 팬들에게는 세상의 나쁜 놈이 되었던 것 처럼... 내년이면 저도 서른이군요. 제가 아무리 설쳐야 CMM이나 RUP가 가지는 위상에 변함이 없을거란, 그리고 Agile에 아무런 도움도 되지 않을 거란 정도는, 그리고 더 이상 세상이 "나"를 중심으로 돌아가지 않는 다는 정도는, 그리고 스스로의 능력의 크기 정도는 알 정도의 철은 들었습니다. 그러나 이것도 맞고 저것도 맞고 혹은 이것도 틀리고 저것도 틀리다는 식의 양비론 혹은 양시론적인 글쓰기는 쓰는 사람이나 읽는 사람이나 지루(?)하지 않을까요. 그건 조선일보만으로도 충분하다고 생각합니다. 앞으로도 쭉 Agile은 좋은 놈(?) RUP와 CMM은 나쁜 놈(?)입니다.
 
넷째, 제가 이런 글들을 쓰는 목적의 하나는 잘난 척(?)하려는 거고, 둘은 Agile을 주장하고 싶은 거고, 셋은 가지고 있는 생각들을 정리하려는 거고, 넷은 공유하려는 것입니다. 중요도 순(?)입니다.
 
 
JUnit Framework
 
"JUnit is a regression testing framework written by Erich Gamma and Kent Beck. It is used by the developer who implements unit tests in Java. JUnit is Open Source Software, released under the IBM's Common Public License Version 1.0 and hosted on SourceForge."
 
Kent Beck과 Erich Gamma가 어느 컨퍼런스 참석을 위해서 타고 가던 비행기에서 함께 만들었다고 알려진 자바 환경에서의 단위 테스트 실행(?) 프로그램입니다. 당연히 비즈니스 클래스였겠지요... 정확하게는 xUnit architecture for unit testing frameworks(이하 xUnit Architecture)로 불리는 자동 단위 테스트 실행을 위한 개념적 디자인을 자바 환경에서 구현한 것으로 파악할 수 있습니다. 이는 MDA(Model Driven Architecture)의 전형적인 예라고 할 수 있습니다. 실제로 xUnit Architecture를 프로그램밍 언어에 맞게 구현한 것이 30여개에 이르고 있습니다. 동일한 디자인(xUnit Architecture)을 공유하면서 다양한 플랫품(언어)에서 구현했다는 점에서 MDA와 같습니다. 그러나 MDA는 하나의 디자인이 상이한 플랫폼들로 구현되는 과정의 자동화를 추구한다는 점에서 특정 프로그램밍 언어 개발자들에 의해서 직접 구현되는 xUnit Architecture와는 다릅니다. 아래의 사이트에서 JUnit Framework에 대한 많은(?) 정보를 얻을 수 있습니다.
 
www.junit.org

 
최소한 자바 개발자들에게는 Martin Fowler의 격찬(?)이 맞다고 생각합니다.
 

Never in the field of software development was so much owed by so many to so few lines of code.

많은 사람들이 단위 테스트를 위한 툴이라는 본래의 목적 외에도 JUnit Framework는 패턴 스터디 대상물로 적격이라고 말합니다. Design Pattern이 실제 프로그램에서 어떻게 구현되는지를 알 수 있게 해주며 동시에 소스코드의 양도 작기 때문입니다. 또한 Kent Beck이나 Erich Gamma가 아직도 개발에 참여하고 있기 때문에 대가의 코드를 직접 접할 수도 있습니다. [JUnit A Cook's Tour]라는 글을 참조하면 좋을 것 같습니다.
 
JUnit Framework에 대한 좋은 읽은 거리는 다음과 같습니다.
 
Test Infected: Programmers Love Writing Tests (Erich Gamma)
http://junit.sourceforge.net/doc/testinfected/testing.htm

JUnit Cookbook (Kent Beck, Erich Gamma)
http://junit.sourceforge.net/doc/cookbook/cookbook.htm

JUnit A Cook's Tour (Erich Gamma, Kent Beck)
http://junit.sourceforge.net/doc/cookstour/cookstour.htm

JUnit FAQ (Mike Clark)
http://junit.sourceforge.net/doc/faq/faq.htm

 
이상은 JUnit(3.8.1)을 다운받으면 그 안(doc 디렉토리)에 모두 들어 있습니다. JUnit FAQ는 계속 수정이 되기 때문에 웹에서 확인하는 것이 좋습니다.
 
Martin Fowler의 [Refactoring: Improving the Design of Existing Code]에도 JUnit과 관련된 장이 있습니다. [Java Tools for Extreme Programming: Mastering Open Source Tools Including Ant, JUnit, and Cactus]에도 내용이 있습니다.

 
JUnit Framework를 설치하고 사용할 줄 아는데 걸리는 시간은 아는 사람들의 도움을 받으면 1시간이면 충분합니다. 사용해보고 싶은 분들은 언제든지 말씀하세요. 다음은 eXtreme Programming(XP)에서의 TDD와 Test-First Programming(TFP)에 대해서 이야기하도록 하겠습니다.
 

 
잡설 하나.
 
xUnit Architecture는 .NET에서는 NUnit Framework로 구현되었습니다.
 
잡설 둘.
 
Grich Gamma의 [Test Infected: Programmers Love Writing Tests]는 꼭 한번 읽어보세요. 이 글은 The Problem, Example, Testing Practices, Conclusions으로 구성되어 있는데 Example을 빼면 1 페이지 정도의 분량입니다. JUnit Framework에 익숙하지 않은 상태라면 Example을 제외하고 읽으시면 됩니다.

The Unified Software Development Process

1999년 중반부터 2001년 초반까지는 Addison Wesley의 "Object Technology Series"(흰 바탕 겉표지 하단 오른쪾에 Booch, Jacobson, Rumbaugh의 이름을 담은 사각형 박스 낙인(?)이 찍힌 그 책들)가 90년대를 뜨겁게 달구었던 백가쟁명의 시대를 마감하고 천하를 통일한(Unified) 시대로 역사(?)에 오랫동안 기억될 것입니다. 진시황의 진나라처럼 너무나 짧은 기간이었지만...
 

법가(Capability Maturity Model, CMM)에 기반한 그 짧았던 왕조는 자신만의 것이 옳다고 주장하며 분서갱유를 마다하지 않았으며, 불로장생(Model-Driven Architecture, MDA) 꿈을 버리지도 못했습니다. 그러나 그런 왕조의 폭정에 항거하여 단호하게 일어난 이들이 있었으니 그들이 바로 그 자랑스런 에자일 연합(Agile Alliance)이었으며, 그들에 의해 왕조는 그 막을 내렸습니다. 그러나 진시황이 동시에 도량형, 화폐, 거궤, 문자를(Unified Modeling Language, UML) 통일하는 등의 업적이 있었음은 부정할 순 없을 겁입니다.

아마도 탁월한 합리주의자이자 기능주의자인 시황제가 아니었더라면 이런 대업적을 단기간에 이룩하는 것은 불가능했을 것이다. 진시황은 극단적인 합리성과 동시에 극단적인 비합리성이 기묘한 형태로 어우러져서, 아주 꼼꼼하게 정무에 힘쓰는 반면에, 거대건축을 세우거나 선약찾기에 막대한 재정을 쏟아부어 부질없이 낭비를 거듭하는 양극단을 오고가는 극과 극의 이중성을 지닌 인물이었던 것으로 생각된다.

                                                                                                       - 어느 인터넷 사이트에서 펌
 
 
그 시대를 빛냈던 그러나 상대적으로 큰 주목을 끌지 못했던 책이 바로 Ivar Jacobson, Grady Booch, James Rumbaugh가 쓴 [The Unified Software Development Process (이하 UP)] 입니다. 동시에 나온 책 중 [The Unified Modeling Language User Guide]는 Booch 주도로, [The Unified Modeling Language Reference Manual]은 Rumbaugh 주도로 쓰여졌고, UP는 Jacobson 박사(일반적인 그에 대한 존칭임) 주도로 작성되었다고 할 수 있습니다. 사실 UML Reference Manual은 저자가 세명이기 때문에 나온 저주받은 책이라는 느낌이 들고 Rumbaugh 역시 상대적으로 과소평가를 받고 있습니다.


RUP(Rational Unified Process, 이걸 '러프'라고 읽는다면서요?)는 UP(Unified Process)를 상품화한 방법론입니다. 사실 RUP와 관련된 책들이 20권 정도가 있는데, 대표적인 책들이 위의 UP를 비롯해 Philippe Kruchten의 [The Rational Unified Process: An Introduction, 2nd]와 Craig Larman의 [Applying UML and Patterns, 2nd]라고 할 수 있습니다. UP는 깊은(?) 철학에 대해서 설명하는 책이고, Kruchten의 책은 제목 그대로 기대할 것 없는 소개서이며 동시에 Rational 사 툴의 광고 팜플렛 같고, Craig Larman의 책은 Agile에 입각한 실천적인 분석·설계 지침서라고 할 수 있습니다.

 
그리고 RUP에 대한 좋은 자료는 Rational의 [Object-Oriented Analysis and Design Using UML] 교육자료입니다. 현재 야간에 교육하고 있는 수업에서 사용하고 있는 그 자료입니다. 전 2001년 여름에 이 수업을 들었는데, 강사말고 교재만 좋습니다.(강사 멀리서 보면 이쁘고(?) 사람은 무척 좋았습니다. 당시 전 안경을 쓰지 않았슴.) 당시 강사가 RUP를 쓰는 프로젝트에서도 실제로는 Iterative하게 개발하지 않는다고 너무 솔직하게 말하더군요. UP 책의 1/3을 Iterative and Incremental Process 설명에 쏟아부은 Jacobson 박사가 알면 눈물 흘리며 슬퍼했을 겁니다.

글고 한 수강생이 CBD에 대해 질문하자 다른 강사는 이런 말은 했습니다. "CBD의 대가인 Jacobson 박사도 아직 CBD는 시기 상조고 어렵다고 했다. CBD는 현실에 적용하기 힘들거다.(뭐 대충 이런투로)". 솔직히 이 답변은 문제가 될 것이 없습니다. 저 스스로도 그 답변에 동의하고, 당시 RUP는 CBD를 주장하던 사람들로부터 RUP는 CBD 방법론이 아니다라는 공격을 받던 시기였으니까요. 근데 요즘은 RUP = CBD 더군요. 2년만에 RUP가 엄청난 발전을 한건지 아니면... "뻥"이 는건지...
 

개인적인 생각으로는 이정도 자료를 접한 다음은 더 볼 책도, 필요도 없다고 생각합니다. 필요한 건 단지 RUP로 진행되는 프로젝트 경험일 겁니다.
 
하여간 이 책들 중 UP를 읽지 않고 RUP는 논한다면 그는 사기꾼입니다. (UP가 담고 있는 내용을 다른 형태로 접했거나 프로젝트 경험이 많은 사람은 예외입니다.) 그 정도로 중요한 책이라고 할 수 있습니다.
 
 
UP는 크게 3 부분으로 구성되어 있습니다.
 
첫번째는 "The Unified Software Development Process"로 책 제목과 같으며, UP의 핵심 사상을 담고 있습니다. 그 핵심 사상은 "A Use-Case-Driven Process", "An Architecture-Centric Process", "An Iterative and Incremental Process"입니다. 그리고 "People are Crucial"이라는 내용도 있습니다. 이 내용을 보면 Agile로부터 공격받는 RUP를 바라보는 Jacobson 박사의 심정이 궁금합니다. Alistair Cockburn은 Use Case는 Drawing하는 것이 아니라 Writing하는 것이다로 더 많은 지지자(?)를 확보했고(Craig Larman의 책도 Cockburn의 Use Case를 따릅니다), 최소한 J2EE와 .NET 환경의 개발에서 4+1 View에 기반한 아키텍쳐는 아키텍쳐를 위한 아키텍처라는 느낌이 들기도 하며, 마지막 Iterative Process는 현실 프로젝트에서 세부적이고 복잡한 RUP의 개발 단계로 인해 사실상 Waterfall을 벗어나지 못했습니다.
그럼에도 불구하고 그 기본철학은 구구절절히 맞는 이야기들입니다


두번째는 "Core Workflows"로 요구사항 분석부터 테스트까지의 단계별 기법들에 대해서 설명하고 있습니다. 이 부분을 이해하기 위해서는 큰 그림을 그릴 수 있어야 합니다. 그 큰 그림을 그리지 못하면 망(?)합니다. UP를 이해하는데 있어서 가장 어렵고 무시되는 부분이 Iterative Process인데 그 이유가 책에서는 Core Workflows를 Waterfall 형태로 설명하고 있기 때문입니다. 이렇게 평면적으로 판단하면 안되고 입체적인(Iterative)를 것을 고려해서 큰 그림을 그릴 수 있어야만 Core Workflows를 바로 이해할 수 있습니다. 그럼에도 불구하고 Core Workflows는 너무 많은 내용과 형태의 중간 산출물과, 활동(Activity), 역할(Role)들로 필요 이상으로 복잡하며, 이 부분이 Agile 진영이 RUP(UP보다 더 복잡한)를 비판하는 가장 큰 논거입니다.

 
세번째는 "Iterative and Incremental Development"로, Core Workflows가 기술적 기법 중심이었다면, 이부분은 프로젝트 관리 측면에서 다루고 있습니다. 그 관리의 중심에 바로 "Iterative and Incremental" 철학이 녹아들어가 있습니다. 이 부분은 UP에서 가장 중요하지만 가장 재미없는 부분입니다. 2000년 여름인가 Jacobson 박사가 한국에 왔을 때 멀리서나마 볼 수 있는 기회가 있었습니다. 참석자 중 한명이 Jacobson 박사에게 Iterative Process가 "Divide and Conquer"와 뭐가 다르냐고 했을 때, 그리고 실제 Waterfall가 뭐가 다르냐고 했을 때, Jacobson 박사의 대답이 기억에 없습니다. 그 역시 "Iterative and Incremental"이라는 개념이 프로젝트 성공을 위해서 얼마나 중요한 것인가에 대해서는 명확하게 알고 있음에도, 복잡한 UP의 Workflow(Unified라는 말처럼 4가지 방법론이 합쳐져서 발생하며, 동시에 모델링 툴을 비롯한 도구에 대한 의존도 때문에) 때문에 실제 프로젝트에서 Iterative하게 간다는 것이 불가능(?)하다는 것을 인정하지 않을까하는 주제넘는 생각을 합니다.
 
 
잡설 하나.
 
5월에 있는 "XP 2003", 6월에 있는 "Agile Development Conference"와 함께 3대 Agile Conference인 "XP Agile Universe 2003(8월)"에 Ivar Jacobson 박사가 강연자로 나온다고 합니다. 그가 어떤 이야기를 할지가 벌써부터 궁금합니다. UP를 통해 그를 보면 Agile과 그 사이에는 종이보다도 작은 차이만이 있음을 믿게합니다.
 

잡설 둘.
 
위의 3개 Agile 관련 Conference의 공통점은 뭘까요? MS .NET이 모두 후원을 하고 있다는 점입니다. 삥을 뜯겨도 단단히 뜯기는군요.
 

잡설 셋.
 
Agile Alliance는 Agile 진영의 느슨한(?) 연합이라고 생각하시면 됩니다. Agile Alliance 현 이사회(Grady Booch)에 놀랍게도 Grady Booch가 있습니다.

Scrum Software Development Process

제 머리 속을 맴도는 생각들을 친절하게도 정리한 것 같은 글입니다. Linda Rising과 Norman S. Janoff가 작성한 [The Scrum Software Development Processes for Small Teams (July/August 2000, IEEE Software)]입니다. IEEE Software는 Harvard Business Review에 견줄만한 저널인 것 같습니다.


Scrum Development Process는 "Agile Alliance"의 대표 주자 중 하나입니다. XP(eXtreme Programming)만이 Agile은 아닙니다. XP가 프로그래밍에 초점을 맞춘다면, Scrum은 Management Process에 초점을 맞추고 있습니다. Scrum에 대한 자세한 내용은 [Pattern Languages of Program Design 4]에 실린 [SCRUM: An extension pattern language for hyperproductive software development]를 참조하시면 됩니다.
 
http://ootips.org/yonat/Scrum.pdf
 
그 외 Scrum을 이끌고 있는 Ken Schwaber와 Jeff Sutherland의 홈페이지도 참조하시기 바랍니다.
 
http://www.controlchaos.com/
http://www.jeffsutherland.com/scrum/index.html
 
 
내용 하나

Most development teams respond with, 'Make the chaos go away! Give us better requirements!' Unfortunately or not, chaos is the reality in this new business environment - as software developers we must learn how to meet customer needs and turn this chaos to our advantage.(26 page)

Chaos(멍 청하고 변덕스러운 고객과 기술 및 시장의 급격한 변화 등)는 위협(Threat)이 아닌 사업기회(Business Opportunity)입니다. 멍한 고객이 요구사항을 바꾸자고 하면 화내지 말고 쓰다듬어 주어야 합니다. 이 이쁜 것... Just embrace change!
 
 
내용 둘

Scrum advocates the use of small teams - no more than 10 team members..... (In the big project,) We thought initially that we could simply divide larger teams into collections of smaller subteams, each no larger than 10. We found that when the subteams are independent and the interfaces well defined, this works. When the overlap is considerable and the interfaces poorly understood, the benefits are not as great. Clearly, this(Scrum) is not an approach for large, complex team structures, but we found that even small, isolated teams on a large project could make use of some elements of Scrum. This is true process diversity.(29 page)

아직까지는 Agile Software Development와 프로젝트 규모와의 관계에 대한 적절한 답은 위의 발췌 내용이라고 생각합니다. 결국 규모가 큰 프로젝트는 Agile 대신 다른 것(RUP? ... 옌 될까?)을 선택하거나 위의 조건(when the subteams are independent and the interfaces well defined)을 충족시키도록해야 할 것입니다. 이를 위해서 중요한 것은 Common Team, Core Team에 대한 고민입니다. 다른 Module Team은 주로 Common Team, Core Team과 Interface를 이룰 뿐 자신들끼리의 Interface는 적기 때문입니다.
 
 
내용 셋.

As in all projects, there must be an initial planning phase. During this phase, the project team must develop an architecture and identify a chief architect. During development, the team should be prepared to make changes to this architecture, but they need a plan, an architecture, and a chief architect at the start. The chief architect defines the development project's vision based on this architecture and ensures that visions consistency throughout all the development phases.... 'The Architect role should advise and control the Developer roles and communicate closely with the developers.'(30 page)

개인적으로 Architect라는 역할을 좋아하진 않지만 위의 발췌 내용이 바로 Common Team이 해야 하는 것을 정확하게 서술하고 있습니다. Iterative 개발이 가능하려면 바로 Initial planning phase(혹은 warming up time)을 획기적으로 줄여야합니다. 바로 이게 표준 프레임워크의 목표입니다. 워크 플로우, 동적 메뉴 관리, 인증 및 권한 관리, 개발 기법 및 표준의 제공 등... Enterprise Common Team이 Project Common Team(EPM Common 팀)을 리드하고 도와줌으로써, 프로젝트 구성원은 Core Team을 중심으로 움직이도록 해야합니다. Core Team은 해당 애플리케이션에서 가장 중요한 모듈을 개발하는 팀입니다. 인사애플리케이션 개발의 경우 Core는 임직원 및 부서를 포함한 조직 체계를 관리하는 모듈을 개발하는 것이 될테고, 프로젝트 관리 애플리케이션 개발의 경우 프로젝트 정보를 관리하는 것이 Core가 될 것입니다.
 
 
내용 넷.

A sprint produces a visible, usable, deliverable product that implements one or more user interactions with the system. The key idea behind each sprint is to deliver valuable functionality..... A sprint is time-boxed development, meaning that the end date for a sprint does not change, The team can reduce delivered functionality during the sprint, but the delivery date cannot change.(30 page)

Sprint 는 Iteration 주기와 Release 주기의 중간개념으로 생각하면 됩니다. Sprint의 기간은 무조건(?) 4주보다 짧아야 합니다. SCMS에 비해서 NRMS의 결과나 생산성이 떨어졌던 이유에 대한 답이라고 생각합니다. 도메인의 복잡도에 차이가 있기 했지만 SCMS의 경우에는 time-box를 지켰던데 비해서 NRMS에서는 계속 날짜를 미루면서 Waterfall도 Iterative도 아닌 애매한 방식으로 개발을 진행했던 것이 가장 큰 실수 였다는 개인적인 생각이 듭니다.
 
클라이언트 애플리케이션과 웹 애플리케이션 개발 사이에 나타나는 차이 중에 하나가 바로 Beta 버전의 존재라고 생각합니다. 클라이언트 애플리케이션에는 여러차례의 Beta 버전의 출시 후에 최종 제품이 릴리즈 되는 반면, 웹 애플리케이션에는 Beta 버전 개념이 없는 것 같습니다. Iterative 개발을 하기 위해서는 Beta 버전이라는 개념에 기반한 Dynamic Release 방식을 채택할 필요가 있다고 봅니다.
 
 
내용 다섯.

The organization can make one very important decision at the end of a sprint: whether to continue product development. Given what was delivered during the last sprit and the current state of the market, the stakeholder meeting should address the question, "Should this project contiune?" This is a business decision and must be made after considering all the technical and marketing issues.'(32 page)

어렵지만 회피해서는 안되는 고민인 것 같습니다. 안그러면 NRMS 처럼 됩니다.
 
 
 

저번 주는 5년 전에 배웠던 생산 관리 교제[Operations Management - Strategy and Analysis, 4th (Krajewski / Ritzman)]를 꺼내 읽어야 했습니다. CMM과 RUP에서는 Frederick Tayler의 과학적 관리법이나 포드적 생산방식의 냄새가 난다면 과장일까요. 5년전 생산관리 시간에도 그런 구다닥리 기법은 가르치지도 배우지도 않았습니다. Lean Manufacturing이나 JIT(Just-In-Time) 등에서 Agile의 냄새가 난다면 과장일까요.
 

At XP2002 in Sardinia, noted economist Enrico Zaninotto observed, "... it appeared to me that software industry was trying to mimic method of industrial organization already exhausted ... industrial organization theory changed its view during the 1970's." What the software industry had been trying to mimic over the last twenty years - a more defined and granular approach to the process of software development was discredited and abandoned by a manufacturing industry that embraced lean manufacturing. Enrico observed that lean manufacturing is much like Extreme Programming and the agile processess.

 
XP2002에서 Kent Beck이 이런 말을 했군요.
 

At XP2002, Kent Beck called for focus during the next year on "the year of the manager," as we move agile practices into IT management and even into the business and IT management relationship. Indeed! Agile causes profound changes to this relationship and practicing, educating, and assisting IT and business management in the change will be a major factor in the success of the agile processes over the next years.

이미 NEXT YEAR은 올해입니다. 그리고 벌써 4월말입니다. 중학교 때 보았던 찰리 채플린의 [Modern Times]가 보고 싶은 하루입니다. 그 우울한 웃음도...

소프트웨어 개발과 생산 관리

OB(Organizational Behavior, 조직행동)와 OR(Operation Research, 경영과학)이 경영학의 양대 축입니다. 전략, 인사, 마케팅은 OB에 뿌리를 두고 있고, 생산관리, MIS, 재무·회계는 OR에 뿌리는 두고 있습니다. 경영학 전공자는 결국 OB를 추구하거나, OR를 추구하거나 경영학과 담을 쌓죠...
 
개인적으로는 OR을 OB보다는 선호했고, 그 중 생산관리 과목(비슷하게는 관리회계, 기업재무 등을 포함해서)에 관심을 가졌습니다. ERP(Enterprise Resource Planning), SCM(Supply Chain Management), CRM(Customer Relationship Manageemnt) 등은 모두 MRP(Material Requirements Planning)에서 발전된 개념입니다.
 

강의 교재는 [Operations Management - Strategy and Analysis, 4th (Krajewski / Ritzman)]를 사용했습니다. 이 때가 제대 후 복학해서 첫학기 였으니깐 98년 1학기 였습니다.(처음 조 모임에 나갔는데 조원들이 OHP로 발표를 한다고 하더군요. OHP가 뭔지 한참 고민했습니다.) 오랜만에 책을 다시 꺼냈는데 놀라운 사실을 발견했습니다. 책은 책장 속에서도 늙어가는 군요.
 
비즈니스 애플리케이션 개발도 생산관리에 기반하고 있거나 혹은 기반해야 합니다. 여기서 잠깐! 혹시 "테일러의 과학적 관리법"이나 "포드의 컨테이너 벨트"를 아신다면 잊어도 됩니다. 그런 구닥다리는 구팔년에도 가르치지 않았습니다. "쨈"없는 CMM 보다는 "쨈"있는 Operation Management를 PM 교육 교재로 삼는다면 PM들이 싫어하겠죠...


9 장 Layout에서는 작업장 또는 사무공간에 대해서 다루고 있네요. 현재 우리는 소프트웨어 개발 공간에 대한 고려가 미흡하다고 생각합니다. 개발자의 행동양식과 의사가 반영되지 않은 개발공간이란 슬픈일입니다. 이런 부분에 대한 고민이 아직은 사치로 보일 수도 있지만 작은 차이가 큰 차이를 만들지 않을까요. Alistair Cockburn이 [Agile Software Development]에서 개발 공간에 대해서 다루고 있습니다.

 
6 장 Work-force Management에서는 Job Specialization과 Job Generalization (Job Enlargement, Job Rotation, Job Rnrichment)에 대한 내용이 있습니다. 세부적인 Role 방식을 따르는 RUP는 Job Specialization을, Agile 방법론들은 Job Generalization을 따릅니다. 인도 사람들에게는 모르겠지만 한국은 Job Generalization이 맞다고 봅니다. 안그러면 기분상하고 쌈납니다.  Ed Romand이 [Mastering Enterprise JavaBeans 2nd]에서 이 부분에 대한 이야기를 하고 있습니다.

Design by UML VS. Design by Code

소프트웨어 개발에서 소프트웨어 디자인이 중요한 것은 엄연한 사실입니다. 디자인은 소프트웨어 개발의 중심입니다. 문제는 어떻게 디자인을 할 것인가입니다. 대표적인 방법이 Design By UML과 Design By Code (또는 Design By Programming)라고 할 수 있습니다.
 
일반적인 소프트웨어 개발이 [요구사항분석 -> 디자인 -> 구현 -> 배치 -> 테스트] 형태로 이루어진다고 할 때 두 방식은 전혀 다른 모습으로 나타납니다. Design By UML은 각 단계를 더 세분화하는 방식으로 갑니다. RUP 방법론에서 디자인 단계만 10 단계 이상입니다. 반면 Design By Code는 디자인과 구현 단계의 구분을 희석시키면서 각 단계를 단순하게 합니다. 결과적으로 Design By UML은 Waterfall Process를, Design By Code는 Iterative Process를 따르게 됩니다. 역설적인 것은 RUP가 주창하는 개발 모델은 "Iterative and Incremental process"라는 겁니다. RUP를 비판하는 많은 사람들의 주장 중 하나가 바로 "RUP는 Iterative Process를 주장하긴 하지만 RUP를 적용한 프로젝트는 Waterfall로 가기 쉽다"라는 겁니다. RUP의 근간이 되는 UP(Unified Process)는 정말로 훌륭한 방법론입니다. 하지만 Rose를 비롯한 Rational사의 각종 툴의 마케팅 수단으로 악용된(?) RUP는 쓰레기가 된 겁니다.

RUP 가 Design By UML의 한 극단을 차지하고 있다면, Kent Beck은 Design By Code의 다른 극단을 차지하고 있습니다.(eXtreme Programming을 사용하는 모든 사람들이 UML을 사용하지 않는 것은 아닙니다. Kent Beck이 유독 심할뿐입니다.) 그렇다면 어떤 방식을 따를 것인가?

 
논의 진전을 위해 대상 프로젝트를 객체지향언어를 이용한 비즈니스 애플리케이션 개발에 한정하도록 하겠습니다.(UML 자체가 객체지향 방식으로 소프트웨어를 디자인할 때 사용하는 것이고, 우리 회사가 개발하는 시스템이 주로 비즈니스 애플리케이션이기 때문에 이런 범위 제한은 당연하다 하겠습니다.)

 
소스 코드를 담고 싶은 UML

UML의 등장과 성공은 C++가 Java로 대표되는 객체지향언어의 등장입니다. "코드를 UML로 UML을 코드로(Reverse or Forward Engineering)"가 가능해지면서, UML이 부각되었습니다.(Model-Driven Architecture는 여기서 한 걸음더 나간겁니다.) UML은 꾸준히 코드를 담고 싶어합니다. 그러나 언제나 "싶어함"에 그칩니다. 이런 와중에서 사람들은 "소스 코드로 디자인할 수 있다."라는 사고까지 다다릅니다. 디자인은 UML로만 할 수 있는게 아니라 코드로도 할 수 있는 거였다. 사실상 객체지향언어의 등장이 새로운 패러다임 전환을 가져온 것이 바로 "소스코드로 디자인할 수 있다"는 겁니다. Jack Reeves의 [The Source Code is the Design]이 이를 잘 설명해주고 있습니다.

객체지향에 대해서 잘모르면 UML Notation을 알아도 UML을 쓸 수 없습니다. 객체지향에 대해서 잘알면 UML 보다는 코드로 디자인하는 것이 더욱 풍부하고 생산적입니다. 슬픈 UML...
 
 
동작하고 싶은 UML

비즈니스 애플리케이션은 요구사항이 애매모호한데다가 사춘기 소녀처럼 시도때도 없이 변하고 삐지는 특성이 있습니다. 이 문제에 대처하는 방법은 동작하는 시스템을 멍청한(?) 사용자나 고객에게 보여주는 겁니다. "이거 니가 원하는 건 맞아? 아냐? 그럼 어떻게 해줄까?" 만고 불변의 진리는 UML은 동작하지 않는다는 것입니다. 또한 디자인하는 과정에서도 현재의 디자인이 맞는지 확인할 수 있는 것이 중요합니다. UML은 동작하지 않습니다. Design By Code만이 이를 보장해줍니다. 자동화된 단위 테스트를 계속 수정하면서 개발자(혹은 디자이너)는 자신의 디자인에 대한 Feedback을 받으면서 디자인을 수정할 수 있습니다.
 
 
커뮤니케이션이 쉬운 것 같은 UML

UML을 중시하는 많은 사람들은 UML을 통해 고객 또는 비즈니스 도메인 전문가와 쉽게 커뮤니케이션할 수 있다고 생각합니다. 맞습니다. 맞구요... 하지만 뭐하러 그걸 고객이나 비즈니스 도메인 전문가에게 보여줍니까?  커뮤니케이션 대상은 개발자간에 이루어질 뿐입니다. 커뮤니케이션도 UML보다는 코드가...
 
 
결론적으로 소프트웨어 개발은 Design By Code를 중심으로 이루어저야 합니다. UML은 보조적인 수단일 뿐입니다. 보조적인 수단이란 의미는 개발 중에 UML로 작성된 것을 산출물로 관리하지 않는다는 것입니다. 프로젝트의 규모는 "Design By UML이냐? Design By Code나?"는 논쟁과 직접적인 상관관계가 있다고 보지는 않습니다. 그보다는 "Waterfall이냐? Iterative?"라와 관계될 것 같습니다. 이 이야기는 다음 기회에... 어찌되었든 RUP도 "Iterative and Incremental Process"에 기반하고 있다고 주장합니다.
 
 
잡설 하나. 예전에 처음 Rose를 사용했을 때 가장 큰 불만은 작은 모니터와 A4 종이만 지원하는 프린터였습니다. 만약 [마지막 황제] 시절의 대한극장 스크린만한 모니터와 그만한 종이를 지원하는 프린터가 있다면... 그리고 그걸 볼 수 있는 성능 좋은 돋보기가 있다면 Design By UML도 괜찮을 수 있습니다.

잡설 둘. UML이 시스템을 문서화할 때는 좋은 것 같습니다. 지들(고객)이 읽을 것도 아니면서 UML로 작성한 문서를 받으면 "헤헤헤"하니.. 뽀대가 나기는 합니다. 그런데 Reverse Engineering을 아십니까?
 
잡 설 셋. 비용을 고려하면 98년도에 네덜란드가 우리는 5:0으로 이기듯, Design By Code의 Design By UML에 대한 압승입니다. 천이백만원 짜리 툴이라는 게 뽀대는 나지만... 내실을 기할 때입니다. Open Source 진영의 개발자들이 UML을 싫어하는지 아직은 쓸만한 UML 모델링 툴이 없습니다.
 
잡설 넷. 작년 이맘 때까진 저도 RUP와 UML 추종자였습니다. 저처럼 지조가 깊은 사람이 변심한 건 Kent Beck의 "In software development, Duplication is evil. And  UML is duplication of source code. Therefore, UML is evil."이라는 논박하기 어려운 명제 때문이었습니다.

Refactoring 이야기

Martin Fowler의 [Refactoring - Improving the design of existing code]는 재미없는 책입니다. 하지만 꼭 소장해야하는 책입니다. 이책의 추천사(Forward)도 Erich Gamma가 썼습니다.
 
Refactoring에 대한 Martin Fowler의 정의는 다음과 같습니다.
 
Refactoring (noun) : a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior
 
Refactoring (verb) : to restructure software by applying a series of refactorings without changing it obsevable behavior.
 
 
Refactoring의 전제조건(Precondition)은 동작하는 코드입니다. 이런 이유로 Refactoring은 Design By UML보다는 Test-Driven Development과 궁합이 맞습니다. 동작하는 코드를 이해하기 쉽고 수정 비용이 최소화 되도록 "깨끗하게" 변경하는 것이 Refactoring입니다. 그리고 Refactoring의 완료조건(Postcondition)도 동작하는 코드입니다. 깨끗하지만 동작하지 않는 코드는 아무짝에도 쓸모가 없으니...
 
즉 이런 전제조건(동작하는 코드)과 완료조건(동작하는 코드)이 담보되기 위해서 필요한 것이 바로 자동화된 테스트 케이스입니다. Refactoring의 진행되는 과정과 완료 후에 현재 코드가 동작한다는 것을 간단한 마우스 클릭으로 알 수 있어야 하기 때문입니다. 예를 들면, JUnit Framework가 이런 자동화된 단위 테스트를 제공하는 툴입니다.
 
Refactoring 과정에서 필요한 두번째는 Refactoring 자체를 자동화해주는 Refactoring Browser의 필요성입니다. Intellij IDEA가 현재의 브랜드 파워를 갖추게된 가장 큰 동인이 Refactoring Browser의 개념을 Java 환경에서 현실화해했기 때문입니다. 자동화된 Refactoring은 수동으로 하는 Refactoring 시 발생할 수 있는 에러를 최소화하고, 지루한 단순반복 작업을 없애줍니다. 결과적으로 개발자가 용기를 가지고 과감하게 자주 Refactoring을 할 수 있게 합니다.
 
[Rename Method]는 클래스의 메소드 이름을 변경하는 간단한 Refactoring 입니다. 이를 수동적으로 처리할 때 개발자가 해야 하는 일은 다음과 같습니다.
 
1. Check to see whether the method signature is implemented by a superclass or subclass. If it is, perform these steps for each implementation.
2. Declare a new method with the new name. Copy the old body of code over to the new name and make any alterations to fit.
3. Compile
4. Chagne the body of the old method so that it calls the new one.
5. Compile and test.
6. Find all references to the old method name, and change them to refer to the new one. Comile and test after each change.
7. Remove the old method.
8. Compile and test.
 
Refactoring Broswer를 사용하면 위의 단계를 간단한 마우스 클릭으로 수행할 수 있습니다. 메소드의 이름을 변경하는 것을 막말로 이젠 껌입니다.
 
P.S. 현재 시중에 나와 있는 IDE들이 모든 Refactoring Catalog를 지원하지는 못하고 있습니다. 하지만 자주 사용되는 것들에 대한 지원은 충분하다고 생각합니다.

데이터베이스 리팩토링

축구를 졌습니다. 간만에 Martin Fowler(www.martinfowler.com)의 홈페이지에 방문했는데, 깔끔하게(?) 변경된 사이트에서도 그는 여전히 빛나는군요.
 
새 로 추가된 [Pramod's Database Refactoring Sildes]가 눈에 뜁니다. 작년 연말에 읽었던 [Evolutionary Database Design]의 후속작인 모양입니다. 이 작업(Database Refactoring)은 Martin Fowler가 아닌 Pramod Sadalage(이름이 인도틱하군요..)의 주도로 이루어지나 봅니다. 이 작업에서 Martin Fowler의 역할은 [Refactoring - Improving the design of existing code]의 저자로서의 명성을 Pramod Sadalage에게 빌려주는 것이 아닌가 하는 생각이 듭니다.(Martin Fowler 처럼 그도 [ThoughtWorks]에서 일하고 있으니까!)
 
SK(주) 의 eHR 프로젝트나 지금 왼쪽 발만 담구있는 EPM 모두 관계형 데이터베이스가 전체 시스템에서 차지하고 있는 비중이 크다는 것은 주지의 사실입니다. 대부분의 비즈니스 애플리케이션은 데이터베이스를 분리하고는 생각할 수 었습니다.
 
일반적으로 프로젝트는 E-R 다이어그램을 작성한 후 그 위에 애플리케이션을 입히는 방식으로 진행됩니다. 이런 환경에서 [Evolutionary Database Design]이라는 말은 낯설고 생소한게 사실이지만, 역설적으로 모든 프로젝트는 [Evolutionary Database Design] 방식을 취하고 있습니다. 정적인 데이터의 관계를 보여주는 E-R 다이어그램으로 복잡한 비즈니스 요구사항을 완전히 표현할 수 없기 때문에, 그런 요구사항이 구현되는 과정에서 테이블이 잔인한(?) 난도질을 당하는 것은 슬프지만 엄연한 사실입니다.
 
인도에서 넘 놀다와서 그런지 요즘 EPM 프로젝트를 진행하면서 애를 먹고 있습니다. EPM 전체 시스템에 대한 이해가 부족해서든, 요구사항의 추가나 변경이든 데이터베이스 테이블을 수정해야 하는 경우가 많은데 쉽지가 않습니다. 간단한 경우는 테이블의 컬럼 이름 또는 타입을 변경하거나 칼럼 자체의 삭제나 추가부터 테이블 자체의 삭제 또는 변경까지... 나름대로는 테스트 케이스를 작성했고 테이블을 접근하는 애플리케이션을 단일화하기도 했는데... 오늘 오전도 특정 칼럼의 Default 값을 변경한 결과 반나절을 디버깅하면서 보냈습니다.
 
[Pramod's Database Refactoring Sildes]는 이런 문제에 대한 해답 또는 시작을 제시하려는 시도입니다. Agile 방법론과 규율(Discipline)이 한 짝을 이루듯 Refactoring 작업은 애플리케이션을 개발하면서 늘상 하는 작업들에 규율을 제공합니다.
 
[Pramod's Database Refactoring Sildes]에서 제공하는 Refactoring은 다음과 같습니다.
 
- Add Nullable Column
- Add Default Value
- Remove Default Value
- Update Data
- Insert Data
- Make Column Non-Nullable
- Make Column Nullable
- Move Data
- Add Unique Index
- Drop Column
- Drop Table
- Add Foreign Key
- Remove Foreign Key
- Bulk Changes
- Rename Table
- Rename Column
- Split Table
- Split Column
- Merge Table
- Merge Column
- Add Database Code
- Remove/Change Database
- Add Index
 
 
이제까지는 Refactoring에 대한 관심이 애플리케이션 중심으로 이루어졌다면 앞으로의 Refactoring에 대한 관심은 Database를 중심으로 이루어지지 않을까하는 생각이 듭니다.(정확하게는 데이터베이스 스키마를 변경하려고 할 때, 애플리케이션 단에서 어떤 작업을 전후로 해야 하는가가 Database Refactoring입니다. 그리고 Database Refactoring의 별미는 운영중인 시스템의 시키마를 변경하는 순간일 것 같습니다.)
 
앞으로 Database Refactoring에 CBD에 대한 관심의 1/10 만 투자했으면 하는 작은 소망이 있습니다.
 
P.S. [Pramod's Database Refactoring Sildes]는 Martin Fowler의 [Refactoring]책과 같은 포맷을 가지고 있으며, 조만간 출판되지 않을까합니다.
 
P.S. 슬라이드에 나오는 코드를 보면 Martin Fowler가 [Patterns of Enterprise Application Architecture]에서 제시하고 있는 모든 내용들이 ThoughtWorks에서는 일상적으로 사용되는 것 같습니다. 부럽습니다.