세상을 놀라게 하자!

XPER instant conference : Joseph Yoder 본문

Software construction/Agile development

XPER instant conference : Joseph Yoder

유진호 2011. 7. 22. 00:35

Joseph Yoder 소개



우리나라에서는 정말 만나기 힘든 ‘Architect’이신 Joseph Yoder가 한국에 다른 일정으로 오셨습니다. 이분의 주무기는 Refactoring과 Adaptive Object Model, Design Pattern입니다.
http://www.joeyoder.com/ 에 자세한 이야기가 나와 있습니다만  다양한 형태의 PLoP  Conference를 주관하시고 있고 소프트웨어 아키텍쳐, 설계, 구현과 같은 다양한 소프트웨어 개발에 대한 훈련, 멘토링과 컨설팅을 하고 계십니다.


The Big ball of mud

특별히 이번에 진행된  Conference에서는 TDD와 Refactoring에 대한 이야기를 했습니다. 왜 소프트웨어는 가면 갈수록 점점 엉터리 코드로 엉망이 되어 가는걸까요? The big ball of mud pattern이란 이런 현상을 설명하는 좋은 예입니다. 동의어로 스파게티 코드가 있지요. 그런데 Joseph은 이러한 것이 반드시 나쁜 것이냐 라는 질문을 합니다. 이것은  “Worse is better” 라는 Gabriel이 1991년에 낸 생각과 유사합니다.  이 뜻은  “일찍 출시해서 시장이 최종 제품을 설계하는데 도움을 주게 하라"는 뜻인데 실제 오픈소스가 이런 방식으로 발전해왔지요.  

즉 완벽한 소프트웨어를 만들기 위해 우리 모두 노력을 하지만 소프트웨어의 변화는 결국 진흙덩어리를 만들게 됩니다. 이것이 완벽히 없어야만 좋은 소프트웨어가 되는 것은 아니지만 이것을 계속 두게 되면 ‘기술의 빚'을 지게 되는 것이지요. 이것을 해결하는 방법으로 꾸준한 Refactoring, TDD등의 방법을 제안하고 있습니다.

그리고 이러한 소프트웨어의 변화는 계층에 따라 변하는 속도가 다르게 됩니다.  아래 순서대로 위쪽에 있는 것일 수록 늦게 변하고 아래로 갈수록 빠르게 변할 수 있다고 Footer와 Joseph은 주장을 합니다.
  • The platform
  • Infrastructure
  • Data schema
  • Standard frameworks and components
  • Abstract classes and interfaces
  • Classes
  • Code Faster
  • Data


Mud로 대표되는 소프트웨어의 문제점들에 대해 Joseph은 다음과 같은 주장을 합니다.
  • 우리는 코드를 개량하고 복구하거나 개조해서 진흙덩어리들을 치워버릴 수 있다. (We can gentrify, rehabilitate, or make-over code helping clean up the mud.)

  • 어떠한 패턴이나 프레임워크, 부분모듈, 그리고 객체가 오히려 진흙덩어리를 만들어 냈 다.  애자일 개발방식은 이를 해결하는데 도움을 주었다.  (Even some patterns, framework,  components, and objects works, helped with mud. Agile has helped some.)


Refactoring & TDD

이날  Joseph 굉장히 Refactoring에 대해 많은 시간을 가지고  소개했습니다. Refactoring의 정의, 종류, 위험도에 따른 분류까지 했습니다. 무엇보다 매일 그리고 점진적으로 Refactoring을 해나가야 한다라는 주장을 했습니다. 그리고 본인은 따로 Refactoring시간을 두지 않고 자연스럽게 하다보면 Refactoring을 하고 있더라라는 이야기를 했습니다.


그리고 이러한 Refactoring을 위해 Test를 꼭 하라면서 Testing이 Agile이 있기 전부터 Refactoring의 핵심원리라 할 만큼 강조했습니다. 저 역시 이 부분에 대해서는 정말 공감합니다. 그리고 TDD와 Refactoring이 서로 겹치는 부분이 있다 했습니다. 무엇보다 Test case를 먼저 안 썼다고 비난하지 말라 하시며 오히려 실제 구현 작성 하고나서  Test code를 작성하고 이것이 실패하면 구현을 수정하는 방식으로 일해도 된다했습니다. 저는 이 부분이 TDD관련되서 과거에 많이 논쟁이 되었던 것을 기억해보면 진짜 전문가는 ‘가지는 쳐내고 맥을 제대로 집는다'는 느낌을 가지게 되었습니다.



Refactoring & Design pattern

그럼 이러한 Refactoring을 할 때 구조를 바꿔야 하는 일도 있을 것입니다. Joseph 이때 Design pattern을 살펴보라고 했습니다.  Design pattern이란 것이 실제 소프트웨어를 설계하면서 나온 일종의 공식이고 다른 사람들의 경험이 녹아 있기 때문이지요. 즉 Refactoring이 다소 복잡한 구조라면 이를 풀어나가는 방법을 생각하기 위해 Pattern catalogue같은 목록을 보면서 어찌 풀지 고민해 보라는 주장이었습니다. 물론 지나친 Pattern광신은 경계했고요. 그 후 PLoP에서 어떻게 패턴이 만들어지는지에 대해 소개해주었습니다. (Writer’s workshop같은 것들 )



Adaptive Object Model


추가적으로 AOP(
http://adaptiveobjectmodel.com/ )에 대한 설명도 해주셨습니다. 이것도 Joseph 작품이거든요. 간단히 설명하자면 속성과 관계(Attribute and Relationship)에 대한 것들 / 그리고 행동(Behavior)을 객체로 분리해서 구현 하자는것입니다. 이렇게 해서 최대한 유연한 유로운 객체구조를 만들자라는것이 목적입니다.

이러한 설계가 나온 이유는 실제 현장에서 자주 구조를 재 설계해야 하는 일이 벌어지는 거죠. 예컨데 보험회사의 시스템의 경우 상품에 대한 구조가 바뀌는 것에 따라 이를 처리해주는 소프트웨어도 변해야 하는데 이를 단순히 상속기반의 설계로는 감당할 수 없습니다.  실제 Joseph이 이러한 설계를 생각해 낸 것도 금융 쪽 소프트웨어에 대한 설계를 하다 나온 것이라 했던것으로 기억합니다. (그렇게 들은 것 같은데 녹취록을 다시 들어보니 그런 말이 없어요.. T_T...) 자세한 구현은 http://www.codeproject.com/KB/architecture/AOMTypeObject.aspx 같은 것을 보시면 좋을 것입니다.

특히 이 분이 이 패턴을 설명하면서 ‘Over engineering’을 이야기 했는데, 이 패턴을 반드시 적용해야 하는 곳인지 잘 생각해서 하라는 의미였습니다. 유연한만큼 품이 많이 드는 패턴이기 때문입니다. ‘균형'을 잡으라는 뜻이죠.
 


재미있던 Q&A 시간


앞선 강의도 1시간을 좀 넘겼는데 이후 질문/답변은 무려 3시간을 지속했습니다. 배고프고 힘들어서 매실에이드와 녹차만 들이켰습니다... 많은 질문 답변 중에 몇개 골라서 적당히 요약해서 적어봅니다.

저는 개발할 때 Refactoring할 시간이 없었는데...
: 지금 빚(Technical depth)을 갚을 것인지 나중에 갚을 것인지 문제입니다. 이것은 매일매일 되어야 하는 것입니다. 작은 것부터 해보시길 권합니다.

어떤 분들은 자신의 코드에 자신의 자아를 투영해서 심지어는 쓰레기임에도 남이 치우는 것을 싫어합니다. 이런 분들을 어떻게 다루거나 피해야 합니까?
: 다른 분의 코드라도 코드를 정리해줘서 깨끗하게 유지하는 것은 좋은 일입니다. XP에서는 남의 코드, 내 코드의 구분하지 말라고 가르치지요. 혼자 할 때야 혼자의 코드이지만 팀을 이뤄서 일한다는 것은 내가 작성했어도 팀의 코드라는 뜻입니다. 함께 극복해야죠. 페어프로그래밍 방식을 도입해 보십시오. 각 부분(핵심, GUI등)팀들이 서로 돌아가면서 코드를 보게 하세요.

이런 상황에서 팀 리더가 아니라면 어떻게 해야 할까요?
: 나쁜 방법은 코드리뷰를 할 때 , ‘이게 문제네요, 이게 뭐에요~’라면서 서로 놀리는 것입니다. 의외로 많이 이렇게 합니다. 이 문제에 대해 상대방을 배려하면서 ‘내가 이 부분이 이해가 안되는데 도와 줄 수 있어요?’라고 질문할 수 있어야 합니다. ( 저는 비폭력대화나 코칭을 배워보시길 추천합니다. )

타인의 코드를 Refactoring할 때 어떻게 진행하시나요?
: 타인의 코드를 한번에 이해하기는 힘듭니다. 이럴 때 기존에 있는 큰 코드를 몇 개의 Procedure로 분해하고 이 Procedure의 의미를 물어보고 이름을 짓는 과정에서 자연스럽게 이해하게 됩니다. 마법은 없지요. 심지어는 디버거로 중단점 찍어가면서 확인도 합니다.

얼마나 Refactoring할 때 Comment를 남기나요? 어떤 사람들은 Comment없이 코드만으로 이해할 수 있게 짜라는 조언을 하는데요.
: Kent Beck은 Comment가 길면 무언가 추상화 할 수 있는 잠재성이 있다고 했습니다.  어떤 사람은 Refactoring을 할 때 코드의 전체 구조를 먼저 Comment로 적고 실제 함수 이름은 그 Comment에서 띄어쓰기를 뺀 이름을 쓰기도 합니다. 어떻게 이름 짓는가가 어떻게 구현하느냐보다 중요하다고 Kent Beck은 이야기 했지요. Comment로 적어 놓는 다는 것은 어찌보면 이후에 제거해야 할 것들에 대해 표시를 하는 것과 같은 의미일 것입니다.
( 그러나 저는 Comment는 코드의 ‘의도'를 적어야 한다는 Code Complete의 저자인 Steve McConnell의 의견에 더 동의합니다.)


얼마나 하면 당신 같은 전문가가 될 수 있을 까요?
: 매일 매일 노력해야 합니다. 작은 것이라도 개발환경을 개선하고 소프트웨어를 더 낫게 만들어야지요. 마법의 연차수는 없습니다. ^^ 스크럼 마스터 인증서가 실제 그 사람이 좋은 스크럼 마스터라는 것을 보증하지 않은데 검증없이 고용하는 회사들이 있죠. 실제 그 사람이 했던 결과물들, 코드를 봐야 합니다. Google이 이런 부분에 대해서는 잘 하고 있지요.


당신에게 지난 몇 년 동안 가장 도전적이었던 일은 어떤 것이었습니까?
:  저에게 제일 힘든 문제는 소프트웨어 자체보다 사람들과 관계를 맺는 일이었습니다.  좋은 팀을 만드세요.  


Slide : [Link]

Voice record: [Keynote], [Q&A]

 
Comments