스압주의 - 책 자체가 소프트웨어 장인 정신에 대한 요체를 서술하다보니 뺄 내용이 많지 않았다. 그래서 책 내용이 상당히 많다. 이는 책의 저자에게는 상당히 미안한 일이지만 나 자신을 위해서 요약 정리를 해두는 것이 좋다고 생각했다. 만약 이것이 무리가 있는 경우는 개인적으로만 보관하도록 하겠다는 것을 미리 밝힌다. 만약 이 글을 보더라도 개인적으로 책을 사서 읽어보고 개발자의 삶에 있어 지침서로 보관하기를 추천한다. 길더라도 탐독해주시기 바란다

이전 글에 이어서…

이념과 태도 (계속)

영웅, 선의 그리고 프로페셔널리즘

흔히 보는 재앙 상황이 있다. 관리자가 개발자와 협의 없이 모든 일을 일정 내에 하라는 압박으로 밀어붙이는 상황은 개발자라면 누구나 한 번은 겪거나 들어봤을 것이다. 당연히 개발자 입장에서는 협의를 시도했겠으나 관리자가 협박 반, 회유 반으로 개발자로 하여금 포기하게 만드는 경우 말이다. 불가능하다고 말을 해도 벽처럼 느껴지기도 한다. 개발자는 포기하고 밤을 새고 주말도 버려가며 일정을 맞추려고 한다. 어찌저찌 맞출 수 있을 것 같을 때 갑자기 요구사항 변경 혹은 추가라는 후속타가 작렬하게 된다. 그래도 어차피 빡센 김에 더 해보자 하면서 어찌저찌 일정을 맞춘다. 하지만 대부분의 경우 일정을 맞췄으나 릴리즈한 소프트웨어는 불안정하고 수정하기 쉽지 않은 소프트웨어로 남게 된다. 그래서 결국 그 프로젝트는 실패로 기록된다.

아니오라고 말하는 방법 배우기

상식적으로 본다면 누가 봐도 무리한 일정을 푸시한 관리자의 잘못이라고 할 것이다. 하지만 대부분의 경우 결국 소프트웨어 팀에 대한 나쁜 평판만이 남을 뿐 이다. 왜냐하면 최종적으로 소프트웨어 팀이 남긴 결과물이기 때문이다. 억울할 수도 있겠지만 잘 살펴보면 이 또한 소프트웨어 개발자의 책임이다. 하지 말아야 한다고 적극적으로 말하지 않았다. 그리고 마음 속으로는 그 어려운 것을 해내는 것에 대한 영웅 심리가 있었다고 볼 수 있다. 안 되는 것은 아니요라고 말하고 모든 것을 기록으로 남겨 책임 소재를 명확히 하면서 불합리한 상황에 대해 압박을 해야 했어야 했다. 개발자의 미션은 고품질의 상용 소프트웨어를 만드는 것이고 그럴 수 없다면 주어진 조건을 적극적으로 거부했어야 하는 것이다. 즉 고객에게 해가 되는 행위라면 하지 않고 고객을 성공으로 이끄는 프로페셔널리즘을 가지고 행동했어야 한다. 그럼 어떻게 아니요라고 잘 말할 수 있을까?

1. 빡빡한 일정을 다루는 가장 좋은 일은 필요한 모든 것을 분석하여 가능한 위험과 우려사항을 터놓고 관계자와 소통하는 것이다.
2. 불명확하거나 불편한 사실과 우려사항을 최대한 이른 시점에 문제 제기해야 한다.
3. 가장 중요한 것은 일정을 준수할 수 있을지에 대한 자신감의 정도를 꾸준히 표명해야 한다는 것이다. 자신감을 갖는다는 것은 모든 기능이 테스트되고 실제 상용 서비스와 최대한 비슷한 환경에서 충분히 거증된 상태로 소프트웨어를 전달할 수 있음을 의미한다.
4. 진행 중 상황이 안 좋아진다면 관리자에게 해당 이슈를 전달할 것을 요구하고 이에 응하지 않는다면 관리자의 상사가 포함된 미팅을 소집해야 한다. 다툼을 피하지 않고 부딪혀서 어려운 결정을 내릴 수 있어야 한다.

그저 실망시키지 않기 위해 말하는 ‘네’는 거짓말에 지나지 않는다고 했다. 그냥 거짓말이 아니라 중독적이고 파괴적인 습관이다. 아니다라고 하면 실패하거나 실망시키는 느낌을 주는 것 같은가? 프로페셔널리즘이란 나 자신, 팀 동료, 관리자와 고객에게 정직함을 의미한다. 즉 일이 제대로 되게 하는 것을 제 1의 미션으로 삼아야 한다는 것이다.

대안 제시

프로다운 태도는 아니오와 함께 반드시 하나 이상의 대안을 제시할 수 있어야 한다. 없다면 머리를 모아서 대안을 만드는 과정을 거치는 노력이라도 해야 한다. 물론 답이 나오지 않을 때가 있다. 이럴 때는 최대한 이른 시점에 그 사실을 정직하게 알려야 한다. 그리고 뭔가 약속을 할 수 없더라도 문제 대응이 어떻게 되고 있는지 진척 상항을 계속 공유해야 한다. 이는 모든 새로운 정보가 있을 때마다 팀이 어떻게 대응할지 결정한 기회를 제공하는 중요한 이벤트가 된다. 이런 내부 상황을 꾸준히 공유되어야 하고 그를 통해 대안을 함께 찾아내야 한다. 개발적인 해답만 답이 아니다. 모든 구성원이 비지니스의 성공을 위해 실용적인 대안을 내놓아야 한다.

깨어있는 관리자

훌륭한 관리자는 자신이 개발 팀의 일부며 함께 공동의 목표를 위해 일한다는 것을 이해한다. 현재 프로젝트 상태를 이해하고 주어진 일정 동안 무엇을 할 수 있을지 개발자들과 함께 추산 가능해야 한다. 부정적인 이야기를 공유하는 것과 같은 팀 내 투명성은 관리자와 팀이 험난한 상황을 이겨낼 수 있게 한다. 빠르게 문제 상황을 공유하고 다른 팀원으로 하여금 현실적인 대안을 찾게 해야 한다. 개발자가 “네”라고 한 약속을 잘 지킴으로써 “아니오”라고 할 때의 신뢰도 올라가게 된다. 팀 전체의 역량은 팀 안의 가장 약한 고리에 의해 결정된다. 문제를 숨기지 않고 드러내는 태도는 모두가 하나의 팀으로서 공동의 목표를 위해 일하고 있다는 징표기 때문이다. 관리자에게 더 많은 정보와 추가적인 선택권을 제공한다면 관리자의 업무에 대한 자신감이 크게 높아진다. 관리자도 개발자가 그렇게 하게끔 독려해야 한다. 좋은 관리자는 팀과 동거동락해야 하며 팀의 사기를 진작시켜면서 팀이 한 배에 탔다는 공동체 의식을 강화시켜야 한다. 좋은 관리자는 외부의 압력으로부터 개발자를 보호하고 팀이 가진 장애요소를 제거한다. 팀원이 성과를 낼 수 있는 분위기를 만들고 편안한 마음으로 자신감을 갖고 일할 수 있도록 해준다. 또한 팀 화합의 촉매가 되어야 한다.

동작하는 소프트웨어

이 장에서는 동작하는 소프트웨어만으로는 부족한 이유와 나쁜 소프트웨어가 가진 파급력을 설명한다. 소프트웨어 프로젝트에는 소스코드 그 자체만큼 중요한 것은 없다. 물론 훌륭한 소스 코드를 가지고 있다고 해서 비지니스가 성공하는 것은 아니다. 비지니스 실패의 원인에는 당연히 여러 가지 원인이 있다.

동작하는 소프트웨어만으로는 부족하다

애자일 매니페스토에서는 동작하는 소프트웨어 에 대해 강조한다. 이에 대해 전적으로 동의한다. 하지만 주기가 짧게 배포하고 진척도를 가늠한 소프트웨어를 만드려면 어떻게 해야 할까? 새로운 기능을 추가할 때마다 시간이 점점 오래 걸리거나 약간의 수정에도 수많은 테스트를 하게 되는 상황은 어떠한가? 즉 문제는 시간이 흐르면서 동작하는 소프트웨어에 대한 개념이 고품질의 동작하는 소프트웨어로 옮겨가고 있다는 것이다.

정원 돌보기

프로그래밍은 집을 짓는다기보다는 정원을 돌보는 것에 더 가깝다. 지속적인 유지 보수가 필요하다. 기본적이고 정기적인 유지보수만으로도 정원을 훌륭하게 가꿀 수 있다. 잠깐이라도 게을리한다면 다시 아름답게 하는데 훨씬 많은 노력을 해야 한다. 정기적으로 살피지 않으면 점점 상해서 이 상태를 복구하거나 더 좋아지게 하는데 더욱 힘들어진다. 잘못된 설계, 테스트 부족, 프로그래밍 언어나 도구의 미숙한 활용도 코드를 더 빨리 썩게 만든다.

보이지 않는 위협

프로젝트를 시작할 때는 유지해야 할 뭔가가 없기 때문에 모든 것이 아름다고 훌륭하다. 하지만 시간이 갈수록 상황이 악화된다. 제대로 원인 파악도 안 된 버그가 생겨나고 기능 구현과 테스트에 걸리는 시간이 보이지 않게 점점 더 길어진다. 같은 작업량의 기능이라도 초기엔 금방 구현할 수 있었지만 나쁜 코드가 많아질수록 더 오랜 시간을 들여야만 구현이 완료된다. 코드의 품질이 낮아질수록 새로운 기능을 추가하거나 버그를 수정하거나 어떤 기능을 테스트하는 일이 점점 어려워진다. 결과적으로 품질이 낮아질수록 애플리케이션의 강건성과 신뢰성이 낮아진다.

하지만 코드 품질이 낮아지는 순간 자신이 만든 소프트웨어에 자신이 인질이 되는 상황이 발생한다. 변경에 너무 많은 시간이 걸린다거나 개발자가 기존 코드에 손을 대는 것을 두려워한다면 지체없이 대응해야 한다. 소프트웨어가 비지니스를 방해하고 지연시키기 때문에 이런 상황은 상당히 위험하다. 당연하게도 나쁜 품질의 코드를 다뤄야 하는 기업은 경쟁력이 떨어지게 된다. 가장 큰 문제는 나쁜 코드가 개발자 외에 다른 사람에게 보이지 않는다는 것이다. 개발자가 아닌 다른 사람이 문제를 인지했을 때는 이미 늦은 상태다. 코드의 품질을 돌봐야 하는 책임은 바로 개발자에게 있다.

그래서 평범한 개발자가 아닌 장인을 고용해야 한다. 장인은 꾸준히 코드 베이스를 돌보고 두려움 없이 빠르게 리팩토링을 한다. 장인은 전체 애플리케이션을 몇 분만에 테스트할 수 있는 자동화 테스트를 구축하고 활용할 줄 안다. 좋은 디자인 원칙과 기법을 전체 애플리케이션의 생애에 걸쳐 적용했을 것이기 때문이다. 코드의 품질이 프로젝트의 성공을 보증하지 못하더라도 실패의 핵심 요인 이 될 수 있다는 것을 배우고 있다.

시간에 대한 잘못된 인식

우리 일상에서 보이는 시간적 여유가 없는 바쁜 팀의 일반적인 모습을 보자.

빨리 끝내야 해서 테스트 코드를 작성할 시간이 없습니다.

단위/기능 테스트를 하는데 시간이 너무 오래 걸려요, 한 4시간?

테스트 시스템을 누군가 먼저 쓰고 있어서 기다려야 해요

QA 부서에 넘겼는데 테스트 결과를 받으려면 통상 몇 일 정도 기다려야 합니다. 처음엔 몇 시간 안 걸렸는데 말이죠.

언젠가 제 담당 시스템에서 에러가 발생해요! 분석해보니 A 시스템 쪽 동작이 이상하네요. 누가 A 시스템 업데이트 했나요?

기술적 부채이란 잘못되거나 쓸데없이 복잡한 설계, 코드에서 사용한 용어와 비지니스에서 사용하는 용어의 상이함과 테스트 코드의 부재 등에서 오는 것으로 부채와 같이 지속적으로 불어나면서 소프트웨어 전반에 부작용을 미치는 것을 말한다. 이런 팀도 처음부터 이러지는 않았을 것이다. 사소한 부채 쌓음이 쌓이고 쌓여서 더이상 감당할 수 없을 만큼이 현 상황까지 온 것이다. 이런 팀에 있는 개발자에게 자동화 테스트는 하고 있는지를 물어보면 대부분은 그럴 시간이 없다거나 이미 더러워진 코드에 붙여서 무얼 기대하냐고 한다. (모두가 그런 것은 아니지만 사람은 생각보다 환경에 영향을 받는다.)

이 모든 것이 단위 테스트를 작성할 시간이 없기 때문에 발생한다. 물론 모든 것이 테스트를 작성하지 않아서라고 하면 어폐가 있을 수 있다. 하지만 여러 문제의 근원이 테스트와 같은 기본적인 소프트웨어 장인 정신을 지키지 않아서 발생하는 것이라고 봐도 무방하다. 단위 테스트 작성은 별개의 업무인가? 단위 테스트는 우리가 코드를 작성하는 방식에 이미 녹아있는 것이지 별도의 작업이 아니다. 기능 구현이 완료됐다고 하려면 반드시 테스트까지 되어야 한다. 어떤 코드든 쉽게 테스트하고 통합할 수 있도록 주변을 잘 정리해야만 한다. 좋은 개발 환경을 만드는 데 필요한 것도 함께 고려해 둬야 한다. 단위 테스트나 리팩토링 같은 것을 빼먹어도 되는 선택사항이라고 잘못된 인상을 주게 되면 고객에게 좋은 결과물을 제공하기는 어려워진다. 결국 소프트웨어의 품질에 책임을 지는 것은 개발자의 몫이다. 책임을 다하려면 단위 테스트뿐만 아니라 뭐든 해야 한다.

하지만 장인 정신을 가진 사람이라면 올바른 것을 하길 원한다. 하지만 소프트웨어 개발자의 삶에 있어 압박은 피할 수 없다. 우리는 압박을 받는다고 느낄 때 중심을 잃고 고만고만해진다. 비지니스에서 필요로 하는 기능을 최대한 빨리 끝내는 것이 개발자로서 미덕이라고 느끼고 있다. 하지만 상황을 솔직하고 투명하게 밝히고 며칠 더 늦게 안정적인 솔루션을 전달하기 보다는 버그가 좀 있더라도 일정 안에 전달하는 편이 낫다. 우리의 결정이 어떤 의미이고 어떤 결과를 가져오는지 잘 이해해야 한다.

또한 소프트웨어 프로젝트는 팀워크다. 특정 개발자 한 사람을 위한 것이 아니다. 프로젝트가 커질수록 작은 이기적인 행동에 모든 사람이 피해를 입게 된다. 프로젝트에 다른 사람들도 있다는 사실을 인식하고 전체 프로젝트에 미치는 영향을 감안하여 책임 있게 행동해야 한다.

그리고 우리 업무에서 반복적인 작업을 자동화하여 제거하는 것은 우리가 해야 할 일이다. 단순 반복 작업에 얼마나 시간을 소모하고 있는지는 쉽게 측정하고 정량화할 수 있다. 이를 개선해야 한다. 그래야 요구사항의 변화 속도만큼이나 소프트웨어의 변화 속도도 빠르게 할 수 있다. 비지니스 담당은 시스템을 전체적으로 본다. 개발자도 시스템을 전체적으로 볼 수 있어야 한다.

이렇게 함으로써 만약 합리적인 사람들과 애자일 스타일로 일하고 있다 전제 하에 진행 사항을 투명하게 공유하고 그 예측 불가한 항목에 대한 불확실성을 제어할 수 있기 때문에 비니지스 담당자는 거꾸로 우리의 계획과 예측에 의존하게 된다. 이럼으로써 개발 팀에 대한 신뢰가 쌓이는 것이다.

레거시 코드

태도는 큰 차이를 가져올 수 있는 작은 요소다 - 윈스턴 처칠

누구나 그린 필드 프로젝트(백지 상태에서 시작하는 프로젝트)를 선호한다. 레거시라면 학을 띄는 사람이 많다. 아무런 테스트도 없고 문서도 없다면 공황에 빠진다. 이직 욕구가 폭발한다. 하지만 어디에나 레거시 코드가 있기 마련이다. 한탄하고 불평하고 저주해봤자 삶이 쉬워지거나 나아지지 않는다는 점이다. 무언가 나아지길 원한다면 그에 맞는 행동을 취해야 한다. 레거시 코드를 다룰 때는 보이스카웃 규칙 ‘처음 발견했을 때보다 더 깨끗하게’를 지속적으로 적용해야 한다. 작은 부분씩 집중해서 한번에 하나씩 이해해나간다면 조금씩 개선 가능하다. 퍼즐을 푸는 것과 유사하다. 리팩토링과 테스트를 붙이다보면 코드 상태가 서서히 개선되는 것이 보이면서 큰 성취감을 얻는다. 그렇게 바꿔나가다보면 라이브러리의 버전을 바꾸기도 쉽고 프레임워크를 도입해 상당 부분의 코드를 폐기하거나 시스템의 한 부분을 완전히 대체할 수도 있다. 코드 정리가 되면서 한 부분의 수정이 나머지 부분에 영향을 미치지 않게 되기 때문이다. 이를 재미있고 도전적인 문제로 바라보면 좋다.

코드 리팩토링은 중독될 정도로 정말 재미있을 때가 많다. 하지만 잊지 말아야 하는 것은 우리가 대가를 지불받고 있는 프로페셔널이라는 사실이다. 고객이 비지니스 목적을 달성토록 주의를 기울여야 한다. 소프트웨어를 깨끗하게 할수록 고객은 그 소프트웨어를 통해 더 오랫동안 이익을 얻을 수 있다. 애플리케이션의 수명을 늘린다는 것은 고객의 투자 이익을 극대화한다는 의미다.

기술적 실행 관례

올바른 일 vs 올바른 실행

앞서 얘기했지만 애자일 방법론의 경우 변화 자체를 내재한다. 빠르고 짧은 피드백 루프를 제공하여 우리가 올바른 일(Right Things) 을 실행하는 지를 점검한다. 하지만 이런 활동이 애플리케이션의 품질 상태가 어떠한지는 알려주지는 않기 때문에 이 부분에서 문제가 된다. 나쁜 코드는 암과 성질이 유사하다. 처음에는 발견하기 어렵지만 빠르게 중식되며 문제로 드러난 이후에는 대응하기가 어렵다. 그렇다면 일을 올바르게 실행하고 있다는 것은 어떻게 알 수 있을까? 코드의 품질과 설계에서는 빠르고 짧은 피드백 루프를 어떻게 만들 수 있을까? 소프트웨어 장인정신은 기술적 실행 관례에 집중함으로써 코드의 품질에 대한 빠르고 짧은 피드백 루프를 제공해 애자일을 보완하는 효과가 있다. 기술적 실행 관례들은 우리가 일을 올바르게 하고 있는지 알 수 있게 해준다.

상황 논리

소프트웨어 장인정신에서 제안하는 여러가지 실행 관례가 있지만 이를 실제로는 잘 이용하지 않는다. 다들 회사과 팀의 사정상, 상사의 허락이 없어서 등의 이유를 댄다. 하지만 공통으로 안고 있는 문제가 많다. 소프트웨어 개발 역량 부족, 느린 대응 속도, 관료주의 등과 같은 비슷한 문제로 불안한 상태인 것은 예상 가능하다. 이런 문제를 풀기 위해 기계적으로 따르기만 하면 문제가 해결되는 단순한 처방전 같은 해결책을 찾은 회사가 많다. 하지만 개발하는 소프트웨어 자체에 더 관심을 기울여야만 한다는 사실 을 깨닫기 전까지는 그렇다.

우리가 어떤 상황에 놓여 있는지 파악하는 것이 대단히 중요하다. 업무 절차가 바뀌면 역할과 책임 그리고 정보의 흐름에 영향을 줄 수 있기 때문에 현재 처한 상황에 대한 이해가 바탕이 되어야 한다. 그리고 개별적인 상황 논리도 있지만 그와 독립적인 것도 많다.

흔히 XP(익스트림 프로그래밍)는 애자일 방법론의 하나라 보고 있지만 애자일 전환을 수용한 회사들 중에서 XP의 실행 관례를 활용하는 경우는 매우 드물다. 대부분 애자일의 절차적인 관례보다 XP 실행 관례보다 더 중요하다고 판단했다. 애자일 전환 과정 중 자연스럽게 XP의 실행 관례를 저절로 얻게 될 것이므로 하지만 대부분의 경우 무시가 된다. 이유는 무엇일까하는 의견은 많지만 이는 전혀 중요하지 않다. 중요한 것은 소프트웨어 장인정신을 심는 것이다.

실행 관례와 가치

실행 관례를 도입(강제적으로 적용)하는 것이 프로젝트의 성공을 보증하지 않는다. 실혱 관례는 우리가 습관처럼 해야 하는 것이다. 흔히 특정한 경우에는 우리 TDD를 한다는 것과 같은 부분적인 것은 도움이 되지 않는다. XP 실행 관례로부터 성과를 얻으려면 진심으로 이것을 받아들이고 내재화 해야 한다. 습관과 같다고 했기 때문에 작심삼일 다이어트처럼 필요할 때하거나 하다가 그만 둔다면 효과를 얻기 어렵다. 실행 관례가 정말 효과가 있는지 없는지 알기 위해서는 그에 대한 명환한 전략을 정의해야 한다. 우선 모든 팀 구성원들에 의해서 아래 나열한 가치가 납득되어야 한다.

• 원활한 정보소통
• 빠른 피드백
• 빠른 결과물 생성
• 실수 예방
• 고객 만족
• 최선을 다하지 못하거나 배우지 못하는 것에 대한 부끄러움을 느낄 줄 아는 것

이 가치가 중요하다고 말하는 것만으로는 부족하다. 우리는 그 사람이 말하는 가치와 행동이 일치하는지 봐야 하는 것처럼 XP 실행 관례가 실천되고 있는지는 가치를 실현하고 있는지 알아볼 수 있는 척도다.

여기까지는 동의한다면 어떻게 하면 팀(또는 관리자, 회사)에 TDD나 페어 프로그래밍 등을 도입하도록 설득할 수 있는가는 의문을 떠오르게 될 것이다. 조직을 변화시키는 것은 어렵고, 관리자와 상사는 그것을 하는 것이 당장 기능을 하나 개발하는 것보다 비지니스 가치가 무엇이 있냐고 질문하고 이에 대한 대답을 제대로 하지 못해 그냥 포기하기 마련이었다. 가장 쉬운 방법은 현재 일하는 방식과 비교해서 그것이 가져올 이익에 집중해야 하는 것이다.

실행 관례 중 몇 가지에 대해 비지니스적으로 어떤 가치를 가져다 주는지 이해해보자. 자세한 내용은 켄트 백의 저서, 익스트림 프로그래밍 소개를 찾아보면 좋다.

• 자동화된 테스트
  • 빠른 피드백 루프 - 클릭 한 번으로 전체 시스템을 단 몇 분 만에 검증할 수 있게 해준다. QA 검증을 피할 수 있다면 비지니스에서 최소 며칠에서 몇 주의 시간을 벌 수 있다. 피드백 루프가 몇 주에서 몇 분으로 줄면 실수를 거의 즉시 고칠 수 있다.
  • 시스템 개발의 민첩성 유지 - 테스트 코드를 먼저 작성하면 새로운 기능을 추가할 때 다른 부분이 망가질 두려움을 덜 수 있기 때문에 시스템이 커지더라도 민첩성을 유지할 수 있다.
  • QA 인력의 최소화 - QA는 테스트 담당자를 필요로 하고 테스트를 수동으로 한다면 시스템이 커질수록 그 수도 더 많이 필요하다.
• 테스트 먼저
  • 구체적인 설계 - 모듈, 클래스, 함수를 구체적으로 정의하도록 강제하여 일을 점진적으로 진행할 수 있다.
  • 신뢰서 있는 코드 - 코드 작성 완료 후 실제 환경에서 기대한 대로 동작할 것으로 강하게 확실 할 수 있다.
  • 빠른 피드백 루프를 하기 위한 기본 요소
  • 요구사항과 비용에 대한 더 나은 이해 - 테스트 자체는 잘 정리된 요구사항 역할을 하고 이로 인해 오버 엔지어링을 방지할 수 잇다.
• 테스트 주도 개발
  • 테스트 먼저 의 진화된 버전이자 설계에 대한 실행 관례
  • 복잡한 코드 작성 방지
    • BDUF(Big Design Up Front) 방지 - 정확히 요구사항만큼만 만족시키는, 테스트에 규정된 부분만 작성하게 된다.
    • 복잡한 설계의 리트머스 역할 - 테스트가 어렵다면 설계가 복잡한 것이고 이를 검토해야 할 시간이 된 것이다.
  • 빠른 설계 피드백 - 기존 코드의 유지보수 용이성에 대해 거의 즉시 피드백을 받게 된다. 설계 리뷰도 중요하지만 참여자의 욕구로 인해 객관성을 잃고 오버 엔지니어링이 되기 쉽다. 설계 리뷰도 큰 변화가 시작되기 전에 있어야 하고 큰 모듈이라면 그 중간 몇 번 정도는 괜찮다. 서로 배타적이기보다 상보적이라고 보면 된다.
  • 코드에 대한 살아 움직이는 문서 역할
  • 회귀 테스트 역할
• 지속가능한 통합
  • 빠른 피드백 루프 - 코드 변경 시 다른 부분에 대한 영향에 대한 피드백 루프를 몇 분 만에 알 수 있게 된다.
  • 항상 배포 가능 상태의 코드 - 일단 멈추고 버그부터 수정한다는 마음으로 버그 수정에 집중해야 함으로써 버그가 누적되지 않는다는 점에서 효율이 높다.
  • QA 팀의 부담 감소
• 페어 프로그래밍
  • 빠른 코드 리뷰 - 코드를 작성하자마자 그 품질에 대해 피드백을 받을 수 있다. 코드 리뷰보다 더 빠른 주기로 피드백이 가능하다.
  • 빠른 지식의 공유 - 잦은 페어 교체를 하면 전체 개발자의 스킬이 팀 차원에서 누적되어 올라간다.
  • 코딩 표준의 정의와 유지
• 리팩토링
  • 유지보수가 쉬운 깨끗한 코드 - 깨진 유리창 법칙으로 인해 엉망인 코드가 많을수록 엉망인 코드가 늘어나는 속도도 빨라진다. 개발속도를 높이고 버그가 만들어질 가능성을 낮춘다.
  • 보이스카웃 원칙 - 모든 것을 수정하는 것이 아니라 수정된 부분에 한정해서 리팩토링에 집중해야 한다. 모든 것은 트레이드 오프가 있기 때문에 실용주의적 관점에서 접근해야 한다.

책임감

우리의 의사 결정에 책임감을 가져야 한다. 실행 관례를 도입하지 않는 결정도 포함된다. 관리자 역시 팀이 특정 실행 관례를 따르지 못하도록 할 때 그에 대한 책임감이 있어야 한다. 우리는 이러한 결정을 기록하고 문제가 있을 때 에스컬레이션해야 한다.

실용주의

기술, 방법론, 실행 관례는 지속적으로 개발되고 진화 중이다. 한 때 맞았던 것이 지금은 정답이 아닐 수 있다. 실용주의 는 소프트웨어 장인이 가져야 하는 최선의 역량 중 하나다. 우리는 지속적으로 일하는 더 나은 방법을 찾고 고객을 만족시켜야 한다. 실행 관례의 가치를 가장 좋은 방법은 피드백 루프가 얼마나 긴지 비교해보는 것이다. 영원히 옳은 관례는 없다. 끊임없이 점검하고 적응해야 한다. 소프트웨어 장인으로서 우리의 일에 항상 최선의 기술, 도구, 절차, 방법론 그리고 실행 관례를 선택할 수 있도록 개방적인 사고 방식을 가져야 한다.

길고 긴 여정

사람들은 뭔가를 잘 하고 싶어한다. 그 동기는 사람마다 다르겠지만 뭔가를 통달한다는 일은 대단히 즐겁다는 것만은 같다. 숙달할 수 있을 정도로 어떤 것에 집중하고 결단하기는 꽤 어려운 일이다. 우리 중 극히 일부만이 마스터가 되기 위한 어렵고 힘든 긴 여정을 감내해낸다. 이 장에서는 커리어와 동기에 대해 말한다.

보통의 경우 자신의 커리어는 정말 중요하다. 내가 살고 싶은 모습이 어떤 것인지 정하고 그 기준과 포부에 따라 성공적인 커리어를 준비해야 한다. 편안하고 익숙한 상태에서 벗어나 나를 발전시키고 배울 수 있는 기회를 지속적으로 찾아야만 한다는 것을 깨달았다. 나의 인생이고 나의 커리어고 내가 주인이어야 했다.

결단과 집중

요기 베라의 “어디로 가고 있는지 모르고 있다면 결국 가고 싶지 않은 곳으로 간다”는 말이 있다. 소프트웨어 장인으로서 스스로의 커리어를 가치있게 여기고 아끼고 보살펴야 한다. 어디로 가기를 원하는지 커리어의 방향을 정하는 것이 중요하다. 커리어를 몇 년 짜리 프로젝트라 여기고 어떻게 관리할지 생각해보자. 그것을 작은 단위로 나누도 점진적인 반복 작업으로 만든다. 작은 작업 단계마다 프로젝트의 목표를 재평가하고 필요한 경우에는 수정해야 한다.

어디로 가야 할지 모를 수도 있다. 커리어 방향을 정의한다는 것은 대단히 어려운 일이다. 딱 한번 결정하고 나면 그 이후로는 아무 생각 없이 내달리기만 하면 되는 그런 것이 아니다. 우리는 지속적으로 그 결정을 재평가하고 다시 목표를 세워야 한다. 모를 경우 고립된 상황에서 벗어나서 모든 기회를 탐색하면서 다녀야 한다. 그래야 기회를 잡을 수 있다. 아래는 기회를 잡기 위한 활동의 목록이다.

• 익숙하고 편한 것에서 벗어나 새로운 것을 공부하고 기술적 지식을 확장한다. 예를 들어 새로운 프로그래밍 언어나 기술을 배운다.
• 지역 커뮤니티에 정기적으로 출석하거나 행사에 참여한다.
• 다른 개발자, 비지니스 맨과 교류한다.
• 새롭게 배운 것, 지금 하고 있는 것들에 대해 블로깅한다.
• 오픈 소스 프로젝트에 참여한다.
• 프로젝트를 만들고 공개한다.
• 컨퍼런스에 참석한다.
• 컨퍼런스에 연사로 나선다.

투자로서의 일터

직장은 단순히 돈을 버는 곳이 아니라 큰 목표를 향해 다가가는 단계 중 하나다. 소프트웨어 장인은 거치는 자리마다 끊임없이 지식, 열정, 몰입과 프로페셔널로서의 태도를 키워나간다. 따라서 다른 형태의 투자로서 우리가 기대하는 보상이 어떤 것인지 명확히 할 필요가 있다. 투자가 계속되는 동안 정기적으로 투자의 성과를 평가해야 한다.

투자라고 해서 본인의 이익만 챙긴다는 것으로 오해해서는 안 된다. 비지니스의 성공이 본인 커리어에 가장 큰 도움이 된다. 프로페셔널로서 고객을 생각해야 한다. 지식은 일에서 얻을 수 있는 가장 흔한 투자 이익이다. 개인적인 삶도 커리어 결정에 중요한 역할을 한다. 금전적인 것, 생활적인 여유, 안정적인 직장이 필요할 시기가 있다. 커리어에 옳고 그른 것은 없다. 지식은 영원하고 돈과 안정은 영원할 수 없다는 것만은 마음에 새기고 있어야 한다. 어떤 이유에서든 직장을 떠날 때 남는 것은 오로지 지식과 경험 뿐이다.

자율성, 통달, 목적의식

다니엘 핑크의 저서, 원동력: 동기부여에 대한 놀라운 진실에서 돈은 충족되어야 할 기본 조건이고 지식 노동자를 움직이는 것은 자율성, 통달, 목적 의식이라고 하고 있다.

• 자율성: 우리가 무엇을, 어떻게, 언제할지 통제할 수 있는 상태를 뜻한다. 제대로 된 애자일 개발 환경이라면 이런 것들을 보장해야 한다.
• 통달: 더 나은 프로페셔널, 더 나은 인간이 되기 위해 계속 배우고 진화하는 것을 뜻한다.
• 목적의식: 지금 하고 있는 일이 중요하고 뭔가를 더 나아지게 하고 있다고 느끼는 것을 뜻한다. 아무런 이해없이 시키는 대로 일하는 것의 반대 개념이다.

금전적인 보상이 부족하다면 일에 집중하기 어렵다. 그러기에 기본인 것이다. 위 3가지 중 자신이 포기할 수 없는 곳에 있다면 다른 직장으로 가는 것이 좋다.

회사 안에서의 커리어

회사 밖에서 보는 모습과 안에서의 모습은 다를 수 있다. 그래서 실망할 수도 있다. 물론 입사 당시에는 훌륭할 수도 있지만 내가 성장했을 때는 아닐 수도 있다. 커리어는 특정 직업이나 회사보다 훨씬 중요하지만 회사 안에서의 커리어가 개인으로서 추구하는 커리와 동일할 수는 없다. 우리의 커리어는 매우 긴 계단이고 특정 직업이나 직장은 한 계단에 지나지 않는다.

일반적으로 대규모 조직에서 커리어를 유지하려 할 때 잘못된 방향으로 가는 것을 많이 보곤 한다. 그 회사를 위해 최선의 것이 무엇인지를 집중하는 대신에, 승진과 보너스에 필요한 것들에만 집중한다. 프로페셔널이 되기 보단 주어진 규칙과 질서를 지키는데 에너지를 쏟는다. 사내 정치 등 회사 안에서 잘못된 일에 집중하고 있는 동안 업계는 계속 진화하고 다른 회사에는 갈 수 없는 퇴물이 되어버린다. 결국 커리어가 망가지는 것이다. 이런 현상을 피터의 원리 - 자신의 무능력이 드러날 때까지 승진하려는 경향 - 라 한다. 다르게 말하면 어떤 사람들은 정치 게임, 권한 남용, 책임 전가와 비난, 부정직하고 프로페셔널하지 않은 태도를 통해 감당할 능력이 전혀 없는 자리까지 승진한다. 하지만 이렇게 기술이 퇴보한 사람은 다른 직장을 찾을 수 없어 근심하게 된다.

소프트웨어 장인은 직업을 잃는 것에 대해 걱정하지 않는다. 자신의 커리어 방향과 일치하는 경우에만 회사 안의 커리어를 수용한다. 역량이 높아질수록 스스로에게 기쁨을 주는 일을 찾기가 쉬워진다. 일을 신중히 선택하고 고객들을 만족시켜 나가면 소프트웨어 장인으로서 매우 성공적이고 즐거운 커리어를 만들 수 있다.

- 요약 2부 끝 -