빛을 담고 세상 넓히기

소프트웨어 개발 방법론은 몇 번의 위기를 극복하면서 지속적으로 발전해 오고 있다. 직관적인 폭포수 모델이 여전히 유효한 상황에서 최근에는 Agile 방법론이 미국을 중심으로 4년 전부터 자리를 잡아가고 있다.

하지만 현재 회사의 프로젝트 관리 방법은 기존 모델의 답습을 넘어서지 못하고 있다. 기획/디자인/개발/QA의 단계별 프로세스를 모두 거쳐야 프로젝트가 완료될 수 있고, 새로운 방법론을 도입하기 보다는 기존 시스템을 지원해줄 수 있는 툴을 개발하고 관리자가 좀 더 편하게 프로젝트 상황을 점검할 수 있게 도와주는데 집중하고 있다는 느낌을 받고 있다.

왜 국내에서는 XP 방법론이 쉽게 전파되지 못하는 것일까? 그 해답을 찾기 위해서 소프트웨어 개발보다 역사가 오래된 제조업을 살펴 보게 됐다. 그 중에서도 계속된 개선을 통해 최고의 상태로 변화해 온 도요타 생산 시스템(Toyota Production System)에 관한 책을 읽기 시작했다.

그런데 TPS의 기본을 설명한 글을 읽다 보면 대부분의 TPS 원칙들이 XP의 그것과 일치함을 알 수 있다. 이 일치하는 원칙들을 몇 개 정리하면 다음과 같다. 아마 XP의 가치나 원칙, 방법론을 잘 알고 있다면 머리 속에 떠오르는 것이 있을 것이다. (삼색볼펜법은 아니지만 형광펜과 볼펜을 옆에 두고 책을 읽으니, 책을 읽으며 생각을 정리하거나 그 생각들을 후에 다시 떠올려볼 때 많은 도움이 되는 것 같다.)

• 실패로부터 발생하는 손해보다는 오히려 도전하지 않아서 발생한 기회손실이 더 크다
• 도전목표 달성에 구성원들을 적극적으로 동참시키려면 “반드시 가능하다”는 리더의 확신과 전폭적인 지원이 가장 중요하다.
• 인간이 발휘하는 에너지를 모두 유효한 업무 즉 부가가치 창출에 쏟을 것을 요구했다.
• 도요타가 갖는 자동화의 의미는 눈으로 감시하는 일을 기계화했다고 보면 이해가 쉽다.
• “많은 노력과 시간을 들여 불량이 나오는 것”은 가장 큰 낭비라고 정의했다.
• 흐름의 속도가 경쟁력을 결정한다는 진리를 깨닫고, 자재를 구입해서 제품을 판매하기까지 현금흐름 주기를 혁신저으로 단축하는 것으로 수익향상을 꾀했다.
• JIT(Just In Time)의 완성을 위해서는 연계업무의 팀플레이 기술이 중요하다.
• 재고가 주는 해악은 자금을 동결할 뿐 아니라 모든 제조 활동의 혼란도 초래한다.
• 보다 더 쉽게 개개인의 업무에 내포된 낭비를 제거하기 위해서 도요타 사원들은 항상 스스로에게 “이 일을 안 하면 회사가 손해를 보는가?”라든가 “이 일이 회사에 어떤 공헌을 하며 얼마만큼의 공헌도를 갖는가?”라고 되묻는다. 이러한 자조적 질문의 습관화는 인간의 본연감각 즉, 유용성이나 효율성은 높게 평가하되 무익하거나 낭비 혹은 무능한 것은 낮게 평가하는 인간의 본성을 십분 발휘하도록 한 것에 지나지 않는다.
• 하나의 원리나 개념을 터득하면 그것을 특정한 일부 분야에 국한시켜 적용하고 그치는 것이 아니라 사용 가능한 모든 분야에 걸쳐 두루 연구해서 통한다는 확신만 생기면 바로 횡적 전개를 시도하는 폭넓은 사고방식을 지니고 있는 것이 특징이다.
• 조직체가 경쟁력을 확보하려면 전 조직원들의 정신이나 마음속에 ‘변화하는 것은 좋은 것’ 혹은 ‘누가 말한 것이라도 좋다고 판단되면 즉시 실천’이라는 의식을 기초로 적극적으로 행동하는 문화가 있어야 한다.
• 근면과 집중이야말로 큰 결과를 내는 데 있어서 유일하게 에너지가 가장 적게 드는 방법임을 깨닫게 된 것이다.
• 도요타 용어에 ‘뒷준비’라는 말이 있다. 이 용어의 의미는 TPS 방식에 의거하여 체계적인 목표를 세워 개선활동을 할 때에는 반드시 개선이 이루어졌을 때의 후속 조치를 미리 설계하는 행동을 뜻한다.

PS) 위의 인용은 지금 읽고 있는 ‘도요타 초일류 경영‘에서 발췌했다.

PS) 애자일 이야기의 글을 보면 XP가 TPS에서 많은 영향을 받지 않았을까 생각하게 된다. 단순한 우연이나 ‘기본은 하나로 통한다’는 그런 의미는 아니라는 얘기.

얼마전에 XP의 원칙과 가치에 대한 글을 올렸는데, 이번에 ‘거침없이 XP’라는 사내 XP 토론회에 참가하게 되어 다시 한번 ‘Extreme Programming Explained’ 책을 읽고 내가 쓴 지난 글을 읽어 봤다. 간단하게 정리한다고 썼던 지난 글도 다시 읽어 보니 수 많은 원칙과 가치가 길게 나열되어 있을 뿐 실질적인 느낌이 잘 전달되지 않았다.

다른 개발 방법론과 달리 XP는 팀 구성원 모두가 공통의 가정을 기반으로 해야 한다. 켄트 벡이 생각하는 공통의 가정은 다음과 같다.

• XP는 여러분이 자신을 팀의 일부로 생각한다고 가정한다.
• XP는 여러분이 다른 사람들과 함께 일하고 싶어 한다고 가정한다.
• XP는 여러분이 성장하고, 능력을 계발하고, 관계를 발전시키기 원한다고 가정한다.
• XP는 이런 목표들을 이루기 위해 여러분이 기꺼이 변화를 감수하리라고 가정한다.

당연해 보이지만 실제로 모두가 이 가정에 맞게 행동하고 있다고는 생각하지 않는다. 즉, 원칙과 가치를 공유하기에 앞서 이 가정 자체가 틀리다면 XP는 팀이나 조직에 성공적으로 정착할될 수 없다는 것이다. (사실 능력 계발만 하더라도 본인이 지속적인 노력을 하고 있어야 그 가정이 맞다고 할 수 있다.)

개인적으로 XP의 가장 중요한 특징은 개발이라는 업무를 좀 더 풍요롭고 즐거운 경험으로 바꿔줄 수 있는 능력이라고 생각한다. 예를 들어 XP에서 중요하게 여기는 ‘개선’, ‘반성’ 등의 가치는 ‘지속적 통합’, ‘Pair Programming’, ‘근본 원인 분석’ 등의 실천 방법을 통해 개발자의 실패에 대한 스트레스를 줄여준다. 동시에 새로운 업무에 대한 부담을 감소시켜주고, 실패를 새로운 것을 배울 수 있는 기회로 만들어준다.

또한 ‘다양성’의 가치는 재미있는 팀을 구성할 수 있게 해준다. 현재 내가 담당하고 있는 파트의 파트원을 선택해야 하는 경우 항상 이 ‘다양성’을 첫번째 기준으로 삼고 있다. 성비가 균형을 이루고 다양한 백그라운드를 가지고 있는 사람들이 모였을 때 하나의 문제에 대해 다양한 해결책이 나올 수 있고 서로가 서로를 보완해줄 수 있다.

결국 모든 것은 ‘사람 문제’이지만 XP는 구체적인 실천방법을 통해 그 가치를 추구할 수 있는 방법을 알려주고 있기 때문에 개발 업무의 유용한 방법론으로 자리 잡게 된 것 같다. 이런 의미에서 XP에서 설명된 첫번째 가치가 ‘의사소통’이고 첫번째 원칙이 ‘인간성’인 것은 시사하는 바가 크다고 생각한다.

PS) 소식이 궁금한 분들을 위해서….
사실 G사가 원하는 영역과 제가 잘 하고자 노력한 영역은 불일치하는 부분이 많습니다. 결국 일치하는 영역을 좀 더 늘린 후 다시 면접을 진행하기로 했습니다. Final Interview을 진행할 Mountain View의 engineers가 비전공에 C도 모르는 개발자를 선택하진 않을 테니까요.
결국 2달 정도 C를 공부하게 됐네요. 이 공부할 팔자라니….

XP를 접한지 2~3년의 시간이 지났다. 처음에는 혼자서 적용해 볼 수 있는 것들을 시도해 보았고, 최근에는 조직 안에서 XP를 적용하기 위한 시도들을 해오고 있다. PP(Pair Programming), TDD(Test Driven Development), US(User Story) 등 새롭고 신선한 실천방법들에 매력을 느꼈고 그 효용성을 체험해 보고 싶었다.

이번 주말에 ‘Extreme Programming Explained’ 2판을 다시 읽어 보았다. 그리고 내가 놓치고 있는 것이 무엇인지 알게되었다.

가치, 원칙, 실천방법…. XP는 실천방법만으로 이루어진 개발 방법론이 아니다. XP가 추구하는 가치와, 그 가치를 위한 원칙들을 기반으로 많은 실천방법들이 합쳐져서 최고의 효과를 발휘하는 것이다. 즉, XP를 도입하기 위해서는 그 가치와 원칙에 대해서 서로 공유하고 합의를 이루는 과정이 선결되어야만 한다.

그래서 다시 한번 XP의 가치와 원칙을 정리해 보기로 했다. 그리고 팀내에서 이에 대한 의견을 모아서 모두가 동의하는 원칙을 세울 필요가 있다고 생각한다.

[XP가 중요시 하는 가치]

• 의사소통 : 문제를 해결하고 효과적으로 협동하기 위해 의사소통이 중요하다.
• 단순성 : 제대로 작동할만한 가장 단순한 것은 무엇일까?
• 피드백 : 변화는 피드백을 필요로 한다. 점진적 개선으로 완벽을 추구한다.
• 용기 : 용기는 다른 가치들과 조화를 이룰 때 강력해진다.
• 존중 : 모든 사람은 인간으로서 동등한 가치를 지닌다. 팀에 속한 모든 개인의 기여를 존중해야 한다.

[XP 적용 원칙]

• 인간성 : 인간의 기본적 욕구를 충족시켜줘야 하며, 인간의 장점을 살리기 위해 노력해야 한다.
• 경제성 : 돈의 시간적 가치, 시스템과 팀의 선택의 가치를 중요시 한다.
• 상호 이익 : 모든 활동은 관련된 모든 사람에게 이익이 되어야 한다.
• 자기유사성 : 어떤 해결책의 구조를 다른 맥락에서도 그대로 적용할 수 있다.
• 개선 : 프로세스나 설계, 스토리를 완벽하게 만들려고 노력한다.
• 다양성 : 어떤 설계에 대한 생각이 두 가지 나왔다면, 이것은 문제가 아니라 기회다.
• 반성 : 실수를 숨기지 않고 오히려 실수를 드러내어 거기에서 배운다.
• 흐름 : 개발의 모든 단계를 동시에 작업함으로써 가치 있는 소프트웨어를 흐르듯이 끊임없이 제공하는 것이다.
• 기회 : 문제를 기회로 전환할 수 있다.
• 잉여 : 잉여를 만들기 위해 드는 비용보다 재앙을 면할 수 있어 얻는 이익이 더 크다.
• 실패 : 실패가 지식을 늘려주는 한, 그것은 허비가 아니다. 실패를 감수하는 것이 성공으로 가는 가장 짧고 확실한 길이다.
• 품질 : 품질 기준을 높일 경우 제품 전달이 빨라지는 경우가 많다.
• 아기 발걸음 : 올바른 방향이라고 알아챌 수 있는 일 중 당신이 할 수 있는 최소한은 무엇입니까?
• 받아들인 책임 : 책임감은 오직 책임질 마음이 있는 사람이 받아들일 수 있을 뿐이다. 책임이 있는 곳에는 권위도 따라온다.

팀과 개인이 중요하게 생각하는 가치는 우선순위는 다를 수 있겠지만 대부분 동감을 할 것이다. 하지만 가치만으로는 실천방법을 정확히 정할 수 없다. 의사소통을 위해 ‘기립 회의’를 할 수도 있고 자세히 기술된 문서를 요구할 수도 있다. 이렇듯 이 가치를 얻기 위해서는 좀 더 명확한 원칙을 세울 필요가 있다. 위에 나열된 XP의 원칙들 외에도 팀에서 다양한 원칙을 정립할 수 있을 것이다. 이 원칙들을 바탕으로 의사결정을 한다면
모두가 공감하고 모두에게 이익이 되는 실천방법을 찾을 수 있게 될 것이다.