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

요약 1, 요약 2, 요약 3에 이어서…

완전한 전환 (계속)

낮은 사기의 대가

개발자의 낮은 사기는 소프트웨어 프로젝트 실패의 주된 이유 중 하나다. 이 장에서는 애자일 절차와 애자일 실행 원칙을 기반으로 개발하고 있다고 전제한다.

애자일 행오버: 낮은 사기

애자일 행오버란 애자일로 전환하고 몇 년 후에도 예외 없이 제품 개발 역량이 여전히 뒤떨어져 있는 현상을 말한다. 애자일 행오버에 빠진 회사의 흔한 문제는 사기가 낮다는 것이다. 사기가 낮은 조직의 전형적인 모습은 다음과 같다. 개발자는 동료, 관리자, 아키텍트, 고객에 대해 불평할 때가 많아진다. 관리자는 장기적 계획을 말하지만 실제로 뭘 해야 하는지 정확히 아는 사람은 없다. 많은 사람이 아직 프로젝트에 실질적으로 참여하지 못하고 있고 말만 많다. 다른 부서의 서로 다른 사람들이 상충되는 요구사항을 마구 던진다. 하고 있는 이유를 모르는 일이 많지만 그 일을 요구한 사람은 너무 바뻐서 제대로 설명해주지 않는다. 일하는 방법을 바꿔보려 했지만 그런 것에는 아무도 관심이 없다. 개발자는 자신이 그저 코딩 기계일 뿐 아이디어를 내고 회사에 기여할 수 있는 프로페셔널로서 대우받고 있지 못하다고 느낀다.

사실 애자일을 도입한다는 것은 실무자에 대한 권한 위임, 변화에 대한 내재화, 협업 증대, 정말로 중요한 것에 대한 집중, 각 업무의 가치 이해, 맹목적인 업무의 배제를 시행한다는 것과 같은 의미다. 일을 올바르게 하고 소통을 원활히 하고 피드백 주기를 짧게 하고 팀워크를 최대화한다는 것과 같아야만 한다. 제대로 된 애자일 조직이라면 지식 노동자가 일을 즐겁게 할 수 있게 하는 요건, 즉 자율성과 목적의식을 제공할 수 있어야 한다.

책의 초반부에 얘기했지만 애자일 전환이 피드백 루프를 짧게 하고 프로젝트의 상황을 투명하게 만드는 데는 긍정적이지만 개발자를 성장시키는 데 도움이 되지 않는다. 또한 오래된 개발자는 일하는 방식을 바꾸려 하지 않고 효과적인 협업에도 관심을 가지지 않는다.

애자일 코치가 실행 관례를 도입하려고 하려해도 그리 효과적이지 못하다. 실제로 보여주기 어렵기 때문에 이를 쉽게 무시해버린다. 회사도 애자일 도입을 새로운 절차 정도로 이해하는 회사가 많다. 그럼에도 이를 도입하지만 개발자는 여전히 과거에 하던 방식으로 소프트웨어를 개발한다. 즉 애자일 도입 이전에도 동기 부여가 되어 있지 않았다면 애자일 도입 이후에도 마찬가지다.

그저 ‘출퇴근’만 하는 개발자들로 인한 대가

열정의 부재 자체가 열정적인 개발자가 화나게 하는 것은 아니다. 열정적으로 애플리케이션을 더 나아지게 하고 일하는 방식을 개선하려고 온갖 노력을 하는 동안 뒤에서 팔짱만 끼고 구경하거나 방해하는 것이 화날뿐이다. 열정적인 팀원도 존재하지 않고 좋은 실행관례도 전혀 따르지 않는 개발팀이 있다면 결과적으로 남는 것은 상상 이상으로 늘어진 일정과 늘어난 비용 뿐이다.

낮은 수준의 동기가 만드는 제약

모든 회사가 문제를 안고 있다. 회사가 좀더 나아졌으면 하는 항목은 쉽게 떠올릴 수 있다. 하지만 그렇게 하지 않는다. 왜 그럴까? 이유는 동기 수준이 낮기 때문이다. 구성원의 동기 수준이 낮고 일이 어떻게 되든 상관하지 않으면 조직을 변화시킬 방법이 없다. 그래서 새로운 방식으로 일하기를 설득하기 전에 동기 부여 수준에 대한 질문을 먼저 해야 한다.

개발자에게 열정을 불어넣기

동기 부여 수준이 떨어진 기존 개발자에게 열정을 불어넣는 방법 외부로부터 소프트웨어 장인을 수혈받는 것이다. 소프트웨어 장인이 일반 개발자와 다른 점은 스스로 설정한 임무가 있다는 점이다. 고객에게 가치를 전달하고 자신을 둘러싼 사람들에게 영감을 불어 넣기 위해 모든 노력을 아끼지 않는다. 그리고 방향을 제시하고 변화를 이끄는 데 두려움이 없다. 항상 최선을 추구하는 것은 내재된 본능과도 같다.

뭔가를 하자고 명령하는 대신 다른 사람에게 무엇을 하라고 명령하는 대신 다른 개발자와 함께 앉아 페어 프로그래밍을 하면서 그들의 지식과 경험 열정을 나눈다. 다른 개발자의 멘토로서 행동하는데 주의를 기울인다. 단순히 일을 완료하는 것 외에도 항상 소프트웨어에 대해서 이야기하고 자신의 자기 계발 활동을 다른 사람과 공유하려 한다. 즉 직접 행동함으로써 조직을 변화시켜 나간다. 개발자에게 동기를 부여할 수 있는 최선의 사람은 바로 동료 개발자다. 실력 있는 개발자, 본 받고 싶고 영감을 일으키는 개발자, 바로 소프트웨어 장인이야 말로 최고의 동기 부여가 될 수 있다.

배움의 문화

동기 부여가 되어있지 않다면 어떤 변화도 효과적으로 일어나지 않는다. 관리자가 변화를 일으키려 할 때 일방적인 통보와 별 다를 바 없는 행동으로 아무런 효과도 못하는 경우를 흔하게 본다. 멋진 장표를 가지고 장미빛 미래를 제시하지만 결국 규칙을 더 만들어내는 뿐이다. 더 나아가 개발자가 새로운 규칙을 준수하도록 업무 고과나 보너스를 연계시키는 것은 상황을 얼마든지 더 악화시킬 수 있다. 소프트웨어 개발에서 그러한 접근 방식은 재앙에 가까운 결과를 가져올 뿐이다. 이 장에서는 배움의 문화 를 만들기 위해 개발자가 할 수 있는 여러가지 활동에 대해 살펴본다.

잘못된 방향으로 동기 부여하기

여기서 저자는 테스트 커버리지를 70% 이상으로 만드는 컨설팅 프로젝트에 대해 언급한다. 이는 조직의 인센티브와 맞물린 프로젝트였고 그래서 그 부분을 단순 아웃소싱을 했던 것이다. 테스트의 의미와 작업의 진행은 내부 개발자에게 큰 의미가 없었다. 물론 테스트 자체도 의미가 없었다. 코드의 정확한 동작도 내부 개발자의 도움없이 알 수 없고 심지어 이후 유지보수 조차 보장되지 않았다. 많은 돈을 지불하고 보너스를 내건 프로젝트는 결국 무용하게 돼버렸다.

여기서 얻은 교훈은 사람들에게 새로운 절차나 새로운 실행 관례를 강제한다고 조직을 변화시킬 수 없으며 우리는 배움의 문화를 만들어내야 한다. 사람들 스스로 모든 것을 나아지게 하고 싶어하는 동기를 부여할 수 있어야 한다.

배움의 문화 만들기

배움의 문화를 만들면 회사에 효율적으로 열정을 주입할 수 있다. 배움과 자기계발의 열정이 가득하고 자기가 하는 일에 애정이 있으며 더 나은 방법을 발견하거나 새로운 것을 배웠을 때 흥분하는 그런 선배 개발자들을 보고 배운다면 어떨까? 이런 환경은 소프트웨어 장인이 되기 위한 열망을 불어넣는 것은 물론 소프트웨어 개발이라는 일 자체를 즐길 수 있도록 북돋을 것이다.

이렇게 높은 수준의 동기가 부여된 사람들은 일을 재미있게 할 뿐만 아니라 항상 회사 바깥 세상에 관심을 갖는다. 이 때문에 회사 입장에서는 외부로부터의 혁신과 효율을 지속적으로 수혈받을 수 있는 큰 이득이 생긴다. 개발자들이 훌륭해지는만큼 회사도 혁신적이고 기민해진다. 개발자들이 행복한 회사라면 외부의 훌륭한 개발자들을 유인할 수 있을 것이다.

주의할 점은 관리자가 일일이 시키는 것이 아니라 개발자에게 권한을 위임하고 개발자 스스로 배움의 문화를 만들어갈 수 있도록 북돋워야 한다는 것이다. 그래야 배움의 문화를 내재화할 수 있다. 이 문화를 만들기 위해 개발자가 할 수 있는 것은 아래와 같다.

• 북 클럽에 가입하기
• 테크 런치 진행하기
• 그룹 토론회에 참여하기
• 업무 교환하기
• 얼마동안만 업무 교환하기
• 그룹 코드 리뷰하기
• 코딩 실습하기
• 사용할 기술은 가능한 자유롭게 선택하기
• 내부 학습 모임을 만들기
• 회사에서의 펫 프로젝트 시간을 허용하기
• 외부 기술 커뮤니티와 교류하기

자세한 설명과 운영방법은 책에서 기술하고 있으니 참고하도록 한다. 다만 그룹 코드 리뷰 부분을 읽을 때 주의할 점은 원래 단어는 comment를 보이는 부분을 주석이라고 오역한 부분이 있다. 코드에 대한 의견 정도로 보면서 읽도록 하자.

아무도 참여하지 않는다면

사람들의 행동을 변화시키기는 어려운 일이고 더욱이 조직 전체를 바꿀 생각이라면 그냥 잊는 것이 좋다. 일부만이 개발자로서의 자부심, 즐거움, 열정을 되찾도록 돕는 것은 가능하다. 여기서는 배움의 문화를 조성하도록 복둗우기 위한 몇 가지 조언을 소개한다.

• 모범을 보여라 - 스스로 모범을 보이는 것이 가장 효율적인 방법이다. 새로운 깃을 추구하는 열정적인 사람 자체가 팀 전체에 자극을 주는 열쇠일 수 있다.
• 관심을 보이는 사람들에게 집중하라 - 변화를 수용하는 사람에게 집중하자. 그 몇 사람으로 인해 다른 사람도 관심을 가지고 함께하려는 사람이 늘어날 것이다.
• 강제하지 마라 - 강제하는 경우 최악의 상황이 발생한다. 그저 초대장만 보내자. 강제로 사람을 끌어들이면 그로 인해 열정을 잃는 사람도 생긴다.
• 모두를 변화시키려 들지 말라 - 소수의 사람들로도 큰 진보를 만들어 나갈 수 있다.
• 모임에 대한 약속을 제때하라 - 모두 바쁘기 때문에 일정 조율을 하다보면 모임을 못할 수 있다. 특정한 시간에 모임을 진행하는 것이 좋다.
• 허락을 구하지 마라 - 상사에게 허락을 구하지 않아도 된다. 책임있게 행동하면 될 뿐이다.
• 투덜대지 마라 - 많은 준비나 조직화가 필요한 학습 모임을 목표로 삼지 말자.
• 리듬을 만들라 - 건강하고 지속되는 커뮤니티를 만드는 비결은 리듬을 가지는 것이다. 정기적으로 항상 어디서 모임이 열리는지 모두가 안다면 참여하기가 훨씬 쉽다. 주최자가 없어도 모임이 진행되게 하는 것이 매우 중요하다.

기술적 변화의 실행

팀에 기술적 변화를 전파하는 방법은 무엇일까? 상사나 관리자를 설득하는 것보다 실무 개발자를 설득하기가 훨씬 어려운 편이다. 특정 개발자는 개발에 있어서 자기만의 비법이 있다고 생각하고 다른 것은 무시해버리는, 켄트 벡이 이야기한 사춘기적 맹신(adolescent surety) 에 빠져있다. 이런 실무자의 기술 변화를 이끌어내려면 그런 맹신에 빠진 개발자를 어떻게 다루는지 알아야만 한다.

회의론의 종류

테렌스 라이언(Terrance Ryan)의 저서 기술적 변화 추진하기에서 회의론의 종류를 아래와 같이 구분했다.

• 무지 - 잘 모르기도 하고 모름에 대한 본능적인 두려움으로 인한 거부. 이런 경우 공부를 이어나감에 있어 그다지 시간을 투자하지 않음
• 대중 - 자신의 경험이 충분치 않다고 생각하고 자신감이 부족해 주요한 결정을 더 똑똑하고 경험 많은 개발자에게 맡기려 함
• 냉소주의 - 논쟁을 좋아하고 자신이 남보다 잘났음을 증명하려 함. 과거 잘못된 경험 때문에 새로운 것의 장점을 보지 못할 수도 있거나 똑똑해 보이는 것을 좋아하여 스스로의 약점을 드러내고 싶지 않아서 일 수도 있음
• 트라우마 - 실행 관례나 도구를 도입하는데 실패한 경험이 있는 사람.
• 너무 바쁜 - 너무 바뻐서 뭔가를 할 수 없는 사람. 장기적인 비용을 보지 못하고 근시안적인 판단을 함.
• 상사 - 상사가 기술 배경이 없는 경우 그가 이해할만한 언어로 말해주는 것이 중요함. 개발자 출신인 경우 큰 어려움이 있음. 관리와 개발을 병행할 경우 너무 바쁜 류의 상사일 수도 있음
• 몰상식 - 가장 최악의 유형으로 합리적인 근거 없이 생트집을 잡는 경우. 제안을 받아들이기 싫거나 제안자를 개인적으로 싫어하는 것일 수 있거나 퇴사나 새로운 일을 만들기 싫어할 수도 있음.

저자가 일하면서 발견한 추가적인 종류다.

• 무념무상 - 아무 생각이 없이 남들과 같이 흘러간다. 더 큰 문제는 좋은 아이디어를 엉망으로 구현해서 나쁜 아이디어로 만든다는 것이다.
• 피해망상 - 회사가 자신에게 피해를 주고 있다고 생각한다. 팀을 파괴하고 개발자끼리 서로를 비난하게 한다. 더 최악인 것은 절대 회사를 나가지 않는다.
• 무능력 - 제안의 본질을 파악하지 못한다. 앞선 무지 와 달리 확연히 구분되는 인지능력, 이해능력의 부족을 보인다. 소프트웨어 개발을 월급을 받기 위한 노동으로만 본다.
• 상아탑 아키텍트 - 몰상식과 함께 최고의 회의론자 중 하나다. 자만에 빠져있으며 가장 높은 지위를 차지하고 있다고 생각한다. 코드를 한 줄도 만들어 본 적이 없는 경우도 있고 만들었어도 실 환경 상에 적용한 적이 없는 경우가 많다. 기술적인 결정에 자신이 책임져야 한다고 하지만 실제로 책임지는 일은 극히 드물다. 실질적인 일보다는 멋들어진 일만을 하려고 한다.
• 좌불안석 - 자신이 다른 사람으로 대체되어 직무를 잃거나 해고될까 걱정한다. 이런 개발자는 사업의 핵심이 기술이 아닌 회사들, 즉 개발자의 능력을 제대로 평가할 사람이 없는 조직에서 흔하게 만날 수 있다. 사내 IT 시스템과 모든 잡다한 문제를 해결하고 약간의 코딩까지 하는 해결사로 취급된다. 언젠가 자신의 실제 가치를 알까바 두려워한다.
• 팬보이 - 특정 주제나 관점에 광적으로 완전히 전념하는 사람이다. 자신이 전념하고 있는 그것만이 모든 것에 대한 최고의 해결책이라 믿고 다른 모든 대안은 거부한다.

준비

나를 둘러싸고 있는 환경을 바꾸고 싶다면 몇 가지 준비해야 하는 것이 있다. 물론 가장 중요한 것은 용기 다. 동료 개발자, 관리자, 기술 리더와 언성이 높아지는 논쟁을 두려워해서는 안 된다. 다음은 정직함과 투명함 이다. 스스로에 대한 자신감 도 필요하다. 그리고 누구나 이해하기 쉬운 단순함 을 추구해야 한다. 누군가를 설득하려면 상대방의 언어로 말해야 한다. 당신의 제안이 가져올 이익을 그들의 관점에서 그들의 언어로 말해야 한다. 말할 내용에 대해 스스로 제대로 이해 하고 있어야 한다. 연구하고 실험하고 연습해야 한다. 반대 의견, 지적에 대해 미리 생각하고 답을 미리 준비해둬야 한다. 제안의 단점이나 문제는 미리 밝혀야 하고 모르는 부분에 있어서 투명하게 고백해야 한다. 그리고 상대방을 존중 해야 한다. 무례하고 공격적인 태도는 방어적인 태도만 낳을 뿐이다. 마지막으로 경청하는 법을 배워야 한다. 자신만이 좋은 아이디어를 갖고 있다고 오판해서는 안 된다. 내가 인지하지 못한 것이 많을 가능성이 있다.

기술적 변화를 시작하는 방법

우선 신뢰 를 쌓아야 한다. 신뢰가 없으면 아무런 변화를 이뤄낼 수가 없다. 가장 좋은 방법은 지속적으로 품질이 좋은 소프트웨어를 딜리버리하는 것이다. 품질이 좋다는 말은 개발자 입장에서는 설계, 변수나 함수의 네이밍, 의미 있고 가독성 높은 테스트 코드, 중복이 없고 장황하지 않은 코드일 것이고 제품 관리자 입장에서 품질 좋은 소프트웨어는 요구사항을 모두 만족하고 버그가 없고 일정 안에 딜리버리되는 것이다. 또한 최종 고객에게 품질 좋은 소프트웨어는 상용 환경 하에서 자신에게 돈을 벌거나 돈을 절약해주고 혹은 매출을 지켜준다는 말이다. 이것만으로는 충분하지 않고 당신을 밖에 알려야 한다. 자신이 진행하는 프로젝트에 대한 애정 그리고 제안하고 싶은 바를 내보여야 한다. 사람은 자신의 열정을 보여주는 사람을 훨씬 더 잘 따른다.

둘째, 전문성 을 확보해야 한다. 신뢰를 쌓으려면 역량이 있어야 한다. 변화를 제안할 때 본인 스스로 충분히 이해해야 한다. 당신이 필요로 하는 것을 그 기술을 이용해 만들어 낼 수 있어야 한다. 무엇보다도 그 기술의 활용법을 다른 사람에게 가르쳐줄 수 있어야 한다. 당신의 학습과 시행착오에 대한 경험은 다른 사람들의 학습 곡선을 단축시키는 데 도움이 될 수 있다. 경험이 쌓일수록 당신의 영향력은 커진다.

다음으로는 모범 을 보여 사람들을 이끌어야 한다. 태도에 대한 변화까지 필요로 하다면 직접 보여주면서 따라하게 하는 것이 가장 좋은 방법이다. 단순히 자료를 찾아서 공부를 해서 할 수 있는 것도 있지만 그렇지 않은 것도 있다. 소프트웨어 설계, 깨끗한 코드, 작업 주기 계획, 개발자 동기부여, 업무 압박에 대한 대응, 고객/관리자/비즈니스/외부 팀과의 신뢰 관계 이러한 것은 웹사이트의 글 하나로 알려준다고 잘하게 될 수 있는 것이 아니다. 몇 개월에서 몇 년까지 연습해야 어느 정도 편하게 활용할 수 있다. 일정과 생산성에 대한 걱정 때문에 우리의 역량 부족을 특정 실행 관레의 도입을 포기하기 위한 핑계로 사용한다. 바로 옆에 앉아 함께 코드를 작성하면서 극복할 수 있다. 제인 먼저 당신 스스로 그것을 할 수 있는지 확인해야 한다. 모범을 보이는 것 자체로 상당수의 회의론을 물리칠 수 있다.

신중하게 싸울 곳 을 정하라. 우린 때때로 권한만 있다면 모든 것을 바꿀 수 있다고 말하곤 한다. 하지만 그런 일은 절대 일어나지 않는다. 혼자서 모든 이슈와 조직 전체를 상대로 두고 싸울 수 없다. 한 번에 한 가지씩 신중하게 싸울 곳을 골라야 한다. 가장 주요한 목표 중 하나는 조직의 문화를 바꾸는 것이었다. 이를 위해 채용 절차를 바꿔서 새로 합류하는 팀원이 사전에 우리가 갖고 싶어하는 문화와 합치되도록 했다. 두 번째 목표는 팀에 TDD와 페어 프로그래밍을 도입하는 것이었다. 관리자를 설득하고 눈에 띄는 개선을 만들어내기까지 1년 남짓의 시간이 필요했다. 변화를 추진하기 전에 변화의 영향 - 변화의 단기적/장기적인 이익, 이겨내야 할 장애요소의 속성과 크기, 주요한 지지자 등 - 을 고려해야 한다. 정말 의미 있는 곳에 노력을 집중하고 더 빨리 가치를 얻을 수 있는 싸움에 우선순위를 두자.

마지막으로는 점진적으로 반복, 관찰, 수용 하라. 큰 충돌을 피할 수 있는 가장 쉬운 방법은 점진적인 변화를 제안하는 것이다. 의사 결정 과정에 사람들이 참여할 수 있게 하는 것이 중요하다. 모두가 자신의 생각을 동등하게 피드백할 수 있는 과정이 있어야 한다. 작업 주기의 경계를 이용해서 논의를 진행하면 직접 참여하고 있다고 느끼고 이 때 서로 싸우기보다는 훨씬 협조적인 분위기가 된다. 잘 정의된 피드백 루프를 갖추고 각 작업 주기마다 조금씩 변화를 이뤄낸다.

두려움과 자신감 부족

두려움이 있는데다 자신감이 부족하면 회사는 관료적이고 정치적으로 변한다. 두려움 은 프로페셔널로서 행동하고 자신의 의견을 표현하는 것을 막고 무능함 은 우리를 둘러싼 일을 올바른 방향으로 변화시키기 위한 싸움을 할 수 없게 한다. 이런 두려움과 무능함은 이기적이고 프로페셔널하지 않은 행동을 만들어낼 뿐만 아니라 부도덕함까지 만들어낸다. 주변을 바꾸고 싶다면 두려움을 버려야 한다. 무능함을 극복하고 최고의 개발자로 거듭나야 하고 두려움을 극복하고 항상 진실을 말해야 한다. 유일한 충고는 인격적으로 못되먹은 사람이 되지 말라는 것 하나뿐이다.

상사를 설득하는 방법

상사는 설득할 수 없다. 용서를 구하는 것이 허락을 구하기보다 쉽다. 가서 하고 싶은 것을 하면 된다. 관리자는 일정에 맞춰서 제픔이 딜리버리되고 예산을 지키고 버그가 없는 것에 관심을 가질 뿐이다. 관리자가 원하는 것은 고객과 이해관계자의 만족이다. 고객은 개발자에게 높은 품질의 소프트웨어, 훌륭한 솔루션을 기대한다. 기술적 실행 관례는 모두 이를 달성하게 돕기 위해 만들어졌다. 무슨 일을 하든 고객에게 가치를 전달해야 한다. 일의 진척 사항에 대해 정직하고 투명하게 말해야 한다. 관리자에게 리팩토링이나 단위 테스트 업무를 위해 시간을 달라고 요청하는 자체가 의미가 없음을 말하고 싶다. 작업을 구현과 테스트를 나눠서는 안 되고 테스트와 리팩토링은 어떤 종류의 개발 업무이든 당연히 내재되어있는 사항이다. 상세사항을 많이 노출하면 할 수록 관리자가 당신에게 더 세세하게 업무 지시를 하고 싶게 만든다.

팀이 TDD를 수용하도록 설득하는 방법

새로운 프레임워크나 도구, 디자인 방법론을 도입하는 것은 어려운 일이다. 큰 충돌 없이 TDD를 도입할 수 있는 방법은 도움을 달라고 요청하는 것이다. 팀에서 가장 열정적인 동료에게 당신의 코드 구현을 도와달라고 하자. 작업 내용을 설명하고 한 두 시간 동안 TDD로 구현해보자고 제안해보자. 그냥 재미로 해보자고 하자. 실행 관례를 전파하는 가장 효율적인 방법은 모범을 보이는 것이다.

회의론을 상대하는 방법

우선 역량을 키우면 변화를 이끌어 나가는 데 큰 힘이 된다. 그리고 커뮤니케이션을 상대방의 수준에 맞게 잘 하는 것도 중요하다. 상사를 내 편으로 만드려면 상사의 언어로 이야기를 해야 한다. 개발 수준의 문제를 끄집어 내서는 안 된다. 상사의 수준에 맞제 대화의 수준을 올려야 한다. 생산성 향상, 비용 절감, 매출 증대, 일정 준수, 버그 감소, 예측 가능하고 꾸준한 개발 속도, 비지니스 요구사항의 충족 등 이런 것이 상사의 사항이다. 상사가 관심을 가지는 요소에 어떤 영향을 미치는지 생각해야 한다.

몰상식한 사람들은 무시하자. 논리적인 논쟁을 하려 하고 내가 주장하는 바로부터 뭔가 더 알아내려는 사람에게 집중하자. 의사 결정 과정에 모두가 참여하도록 만드는데 주의를 기울이자. 작업 주기가 전환되는 시점에 새로운 것을 시도해 볼 것을 제안하자. 누군가의 자리를 위협하는 것처럼 보이거나 스스로 상사가 되거나 모든 개선 사항에 자신의 업적을 주장하려는 목적을 둬서는 안 된다. 팀의 여느 개발자와 같은 위치에서 제안해야 한다. 좌불안석 타입의 회의론자로 만드는 것을 방지할 수 있다.

열정을 공유하고 모범을 보임으로써 사람들을 이끌고 정직하고 투명해야 한다. 자신감을 축적하고 당신이 아는 것을 다른 사람들에게 가르쳐 주는 행위는 주변 사람에게 신뢰를 쌓는 최선의 방법이다. 종국적으로는 롤모델이 되어야 한다.

상아탑 아키텍트는 앞서도 언급했지만 다루기 힘든 회의론자다. 무엇이 어떻게 되어야 하는지 본질적인 가치와 아이디어와의 충돌이 발생한다. 스트프웨어 장인은 소프트웨어를 개발할 때 보다 애자일스러운 접근을 고려하지만 상아탑 아키텍트는 초기부터 큰 설계를 밀어붙인다. 아직 비지니스 문제들이 제대로 이해되지도 않은 시점에 기술 스택과 전반적인 아키텍처를 완성하려 든다. 특정 기술이나 설계를 따르려고 요구하지만 그 결정이 어떤 영향을 미쳤는지 이해하려 들지 않는다. 그는 자신이 모든 결정을 책임지는 사람이고 개발자는 단지 자신의 비전을 실행할 단순 코더로 취급한다. 또 비지니스 담당과 가깝게 지내면서 뭔가 잘못될 때마다 개발자들을 희생양으로 삼는다. 그리고 개발자의 노력으로 뭔가 잘 될 때는 그 공을 자신의 것으로 포장한다. 우리가 기술적 솔루션에 대해서 아무런 의사 표현도 하지 않았다면 우리 역시 아무런 책임을 지지 않는 것이 공정하다. 상아탑 아키텍트가 자신의 결정에 책임을 질 수 밖에 없도록 만드는 것이다.

진정한 소프트웨어 프로페셔널은 권한에는 항상 책임이 따른다는 것을 이해하고 있다. 권한을 갖고 싶다면 책임질 수 있는 준비를 해야 한다. 이미 책임이 주어져있다면 관련된 의사결저에 권한도 가질 수 있도록 해야 한다. 상아탑 아키텍트는 자신의 커리어에 해를 입을까봐 자신의 의견에 책임을 지기 두려워하고 관료주의와 정치 뒤에 숨는다. 그가 당신 앞을 가로막는 것을 피하고 싶다면 그의 결정에 책임지도록 만들어야 한다.

피해망상 또한 매우 다루기 어려운 부류 중 하나다. 나를 아닌 회사를 상대로 대항을 한다. 제대로 된 대우를 받지 못한다고 생각한다. 최선의 방법은 이들을 잘 대해주고 팀의 구성원으로서 잘 융합하도록 돕는 것이다.

이 모든 것을 다 챙겨야만 하는가?

프로페셔널은 고객이 필요로 하는 완벽한 솔루션을 전달해야 한다. 이를 위해서는 단지 코드를 잘 작성하는 것만으로는 충분하지 않다. 진심을 말하며 자신의 행동에 책임을 지고 프로젝트를 위해 최선이라면 싸우기를 주저하지 않는다. 일을 잘 해내려면 소통을 명확히 해야 한다. 무엇보다도 개발자들과 신뢰를 쌓는 방법을 알고 있어야 한다. 신뢰야말로 변화를 이끌기 위한 핵심적인 요소다. 대화하는 상대방을 이해하고 그 사람 생각의 바탕에 어떤 이유가 있는지 공감할 수 있어야 한다. 자신을 준비시키고 용감해지고 주도하자.

실용주의 장인정신

만연한 편견은 좋은 품질에 잘 짜여진 코드는 매우 비싸고 작업이 오래 걸리지만 저급에 버그가 있는 코드는 싸고 빨리 만들 수 있다고 생각한다. 정말로 고품질은 고비용일까?

품질은 선택사항이 아니다

일부러 낮은 품질을 원하는 사람은 없다. 가장 근본적인 문제는 싸고 그저 그런 코드로도 충분하다는 매우 잘못된 가정을 할 때가 많다는 것이다. 단기적으로는 그럴 수도 있지만 중장기적으로는 절대 그렇지 않다. 보통 품질의 코드를 목표로 하는 회사는 형편없는 코드를 결과물로 내놓는 경우가 대부분이다. 낮은 품질의 소프트웨어는 버그의 숫자가 늘어나고 새로운 기능을 추가하는데 시간이 늘어나며 전체 애풀리케이션을 다시 만들자는 이야기가 수면 위로 떠오른다. 관리자와 프로젝트 투자자는 개발자가 아니기에 그런 사항을 보지 못한다. 그들에게 소프트웨어 개발은 다른 분야의 서비스와 마찬가지로 그냥 돈을 내고 받는 서비스일 뿐이다. 보통의 경우라면 최대한 품질을 확보하면서도 낮은 비용으로 빨리 작업이 끝내길 바란다.

좋은 품질은 비싸고 시간이 오래 걸릴까?

소프트웨어 장인은 익스트림 프로그래밍(XP)의 실행 관례와 애자일 원칙을 습관화하고 있다. 기능 구현을 완료했다는 의미는 그 기능이 상용 시스템이나 상용 시스템과 비슷한 내부 검증 환경에 (아직 소프트웨어를 공개 배포할 수 없는 경우) 배포했다는 의미다. 경험 많은 장인으로 이뤄진 팀은 하루에도 몇 번씩 수정된 소프트웨어를 배포할 수 있다. 소프트웨어 장인은 지속적인 통합과 프로젝트 초기부터의 제품 딜리버리를 목표로 하기 때문에 소프트웨어 품질로 인해 상용 릴리즈가 지연되는 일은 가정에 없는 사항이다. 어떤 소프트웨어 프로젝트이건 코드 타이핑 자체가 병목인 경우는 존재하지 않는다. 어떤 코드든 몇 줄이 넘어가는 복잡도를 가졌다면 소프트웨어 장인은 테스트 코드를 함께 작성하고 이는 테스트 코드 없이 작업하는 것보다 더 느리지 않다. 더욱이 애플리케이션의 크기가 크면 XP 실행 관례를 몸에 익힌 소프트웨어 장인이 XP 실행 관례를 전혀 수용하지 않은 보통의 개발자보다 훨씬 더 빨리 작업을 완료한다.

특정 실행 관례를 배우고 마스터하는 데는 시간이 필요하다. 배우는데 시간이 든다고 해서 그 실행 관례가 나쁘다고 할 수는 없다. 실행 관례를 무시하는 대신 경험 많은 소프트웨어 장인을 더 많이 확보해 팀 구성원의 학습 곡선을 당기고 멘토링하는데 관심을 기울여야 한다. 테스트 주도 개발을 도입하다보면 TDD가 항상 필요할까하는 논쟁이 있다. 실용적인 대답은 ‘아니다’다. 도구나 실행 관례를 선택할 때는 실제로 처한 맥락을 반드시 고려해야 한다. 안타까운 것 중 하나는 TDD에 능숙한 사람 중에는 이런 의문을 가지는 사람이 없다는 점이다. 실행 관례에 의문을 표하는 사람은 뒤에 남길 골칫덩이에 대해서는 인지하지 못하고 당장 뭔가를 만들어 내는 것에만 집중한다. 유능한 개발자라면 TDD 때문에 일정을 지연시키지 않는다. 익숙하지 않음 때문에 일정이 늦어진다고 생각하는 것이고 단기적보다는 장기적으로 봤을 때 일을 더 빨리 끝낼 수 있는 방법이다.

리펙토링

리팩토링을 위한 리팩토링은 시간 낭비다. 특별한 이유도 없이 코드를 열어서 재정리하는 일은 아무런 의미가 없다. 보이스카웃 원칙에서는 ‘처음 발견했던 것보다 더 깨끗하게’ 캠프를 남겨 둘 것을 이야기하고 있지 ‘캠프 전체를 혀로 햝아도 될 정도로 반짝반짝하게 만들라’ 는 뜻은 아니다. 그렇게 하는 것이 나쁘다는 것은 아니지만 실용적인 관점에서는 그저 시간 낭비일 뿐이다. 최소한 수정한 부분만큼은 원래 보다 깨끗하게 만들어놓아야 한다. 새로운 기능을 추가할 때마다 코드를 분석하고 필요한 경우 리팩토링을 하여 레거시 코드가 새로운 기능을 자연스럽게 받아들일 수 있도록 해야 한다. 새로 추가할 기능이 레거시 코드에 큰 영향을 준다면 사전에 영향이 가해지는 부분을 리팩토링하는 것이 바람직하다. 레거시 코드는 새로운 기능을 받아들일 준비가 되어 있는가? 수정해야 할 코드량은 어느 정도 되는가? 이 두 질문에 대한 답이 ‘아니오’와 ‘아주 많이’라면 먼저 레거시 코드를 리팩토링하여 새로운 기능을 받아들이기 쉬운 상태로 만들어야 한다. 확장에는 열려있고 변경에는 닫힌 OCP 원칙을 준수할 수 있도록 코드를 리팩토링한 후에 신규 기능을 추가한다. 그 후 레드/그린/리팩터 라이프 사이클에 맞춰 작은 리팩토링을 연속해서 적용한다. 먼저 동작하게 만든 후 점진적으로 개선해 나간다. 분명한 필요에 의해 시스템을 변경하고 그 와중에 작은 리팩토링을 꾸준히 하는 것이 실용적인 관점에서 바람직한 애플리케이션 개선 방법이다.

소프트웨어 개발 방법의 한 가지 예

소프트웨어 장인정신 운동의 가장 큰 목적은 소프트웨어 개발이라는 업의 수준을 기술적, 사회적으로 높이는 것이다. 소프트웨어 개발 직무의 위상을 높이고자 한다. 더불어서 현재 가장 바람직한 것으로 평가되고 있는 여러 기술적 실행 관례의 사용을 장려하고 있다. 커리어 사다리를 올라가며 경험이 쌓이면 스스로 더 나은 다른 방법을 찾고 실제 프로젝트에서 시도해보아야 한다. 즉 계속 진화해야 하고 거기서 얻은 경험을 커뮤니티와 나눠야 한다. 장인이라면 TDD와 같은 XP 실행 관례를 절대 불변의 진리라고 믿어서는 안 된다. 특정 기술이나 실행 관례, 도구에 대해 개별 상황에 대한 이해 없이 절대적, 교조적으로 판단하는 것은 소프트웨어 장인 정시이라 할 수 없다. 소프트웨어 장인은 여러 가지 훌륭한 도구를 포용하면서 맡은 일의 맥락에 가장 적합한 것을 꺼내어 적용할 수 있어야 한다. 특정 실행 관례를 사용하지 않는 다는 이유로 누군가를 프로페셔널하지 않다고 성급하게 폄하해서는 안 된다. 그들이 사용 중인 실행 관례가 무엇인지 물어보고 당신이 사용하고자 하는 실행 관례와 비교해서 그들의 것이 어떤 점에서 더 나은지 찾아봐야 한다.

비지니스 돕기

진정으로 원하는 바가 무엇인지 비지니스 담당자 스스로도 잘 모르는 프로젝트를 흔하게 볼 수 있다. 어떤 것이 프로젝트에 합당한지 내외부 고객과 얘기하면서 이런 저런 솔루션을 탐색해야 하는 상황을 자주 본다. 애자일 코치는 개발자가 비지니스 담당자와 직접 대화하면서 질문하고 솔루션을 제안할 것을 권장한다. 같은 팀이 되어 도와야 한다. 당연하지만 어떤 상황에서든 필요한 일이다. 그런데 그 이상으로 할 수 있는 것이 있다.

문제는 큰 그림에서는 목표가 무엇인지 모두 알고 있었지만 구체적인 수준에서는 모든 것이 모호하고 복잡하다는 것이었다. 요구사항과 시스템이 기술적으로 복잡한 것만이 문제가 아니었고 회사 전체 조직이 구성된 방식과도 연관이 있었다. 즉 비지니스 자체의 운영방식을 바꿔야 하는 경우도 있었다. 조직의 특정 부분에 대한 깊은 이해와 함께 정치적, 관료적인 문제도 핵심적인 논의 대상이었다. 이런 부분에 대해서도 소프트웨어 개발자가 아이디어를 짜내야만 하는 상황이었다. 때로 비지니스 부서는 아직도 자기가 무엇을 원하는지 잘 모를 수 있고 제시할 수 있는 것이라고는 계속 바뀌는 설익은 것뿐인 경우가 있다. 이럴 때 가장 좋은 방법은 뭐든 최대한 빨리 만들어서 이들 앞에 내놓는 것이다. 비지니스 담당이 마음을 바꾸는 것과 거의 같은 속도로 코드를 바꿀 수 있어야 한다. 이렇게 비지니스 담당이 그의 아이디어를 가시화하고 애플리케이션을 사용할 사람으로부터 피드백을 받을 수 있다.

소프트웨어 프로젝트는 우리를 위한 것이 아니다

프로페셔널로서 소프트웨어 프로젝트가 개발자를 위한 것이 아니라는 사실을 이해할 필요가 있다. 프로젝트를 수행한 사람들이 떠나간 후 그것을 유지보수할 사람들을 고려해야만 한다. 원 저작자들 없이 소프트웨어를 진화시켜야 하는 회사의 어려움을 이해해야 한다. 한 개발자가 프로젝트에 추가하는 가치가 그 개발자의 참여를 조건부로 한다면 그것은 가치가 아니다. 그것은 실패 요인이다.

비범함과 평범함

비범한 개발자와 평범한 개발자를 가르는 기준은 어떤 방식으로 그것을 동작하게 만드느냐다. 비범한 개발자는 요구사항을 충족하는 가장 단순한 코드를 만들어 경험이 적은 개발자가 이해하는데 아무런 문제가 없도록 한다. 문제를 단순하고 우아한 방법으로 해결하는 것은 복잡하고 과잉된 방법으로 해결하기보다 훨씬 더 어렵다. 비범한 개발자는 심지어 단순하고 짧은 솔루션 이상의 것을 추구한다. 그들은 코드 한 줄도 짜지 않고 문제를 해결할 방법을 찾는다. 가장 훌륭한 코드는 작성할 필요가 없는 코드다. 잘 작성한 코드는 작고 테스트 가능하며 이해하기 쉽다. 그리고 가장 중요한 부분으로 코드가 해야 할 일을 해낸다. 코드는 버그와 고통의 근원이다. 더 적게 작성할수록 더 좋다.

단순한 설계를 위한 4 가지 원칙

켄트 벡이 말한 단순한 설계를 위한 네 가지 원칙을 먼저 생각해야 한다.

1. 모든 테스트를 통과해야 한다.
2. 명료하고 충분히 표현되고 일관되어야 한다.
3. 동작이나 설정이 중복이 있어서는 안 된다.
4. 메서드, 클래스, 모듈의 수는 가능한 적어야 한다.

많은 사람들이 이 네 가지 원칙을 다른 방식으로 표현하고 있다. 저자는 J.B. 레인스버거의 버전을 선호한다.

1. 모든 테스트의 통과
2. 중복의 최소화
3. 명료성의 최대화
4. 구성요소의 최소화

원칙의 우선 순위에 대해 매우 많은 논쟁이 있다. TDD를 일상적으로 실천한다고 가정한다면 첫 번째 원칙은 너무 자명해지고 중복을 최소화하다보면 구성요소는 자연스레 최소화된다. 그러면 네 가지 원칙은 두 가지로 줄어든다.

1. 중복의 최소화
2. 명료성의 최대화

저자는 중복 제거보다는 명료함을 항상 우선시한다. 단순한 설계를 위한 가이드라인으로 좋은 네이밍과 비지니스 컨셉을 잘 투영한 추상화에 집중한다. 그 다음 중복을 제거하면서 코드의 응집성과 독립성을 높인다. 중복을 제거하다보면 새로운 구조가 떠오르고 다시 명료성을 높인다. 다시 중복을 없앤다. 이러한 사이클을 매우 짧은 반복 주기로 작업이 완료될 때까지 계속한다. 이 접근 방법이 도메인 기반 설계, SOLID 원칙과 결합되면 꽤 괜찮은 코드를 만들어낼 수 있다. 이 접근 방법은 불필요한 여러가지 설계적, 아키텍처적 패턴으로 코드가 오염되는 것을 막아준다.

디자인 패턴

1990년대에는 디자인 패턴(GoF: Gang of Four) 책을 참고하지 않고 단 한 줄이라도 코드를 작성할 생각은 할 수 없었다. 모든 것이 범용적으로 설계했기 때문에 과잉 엔지니어링에다가 상당히 복잡한 솔루션을 유도했다. 미래를 위해 모든 것이 일반화, 범용화해야 했다. 범용코드는 물론 좋지만 공짜는 아니다. 코드를 범용화할수록 더 복잡해진다. TDD를 기본으로 하여 애자일과 XP 실행 관례를 몸에 익히면, 미래에 대비한 범용 코드를 작성하는 일에서 당장의 필요를 충족시키는 구체적인 코드를 작성하는 것으로 옮겨가게 된다. 상당히 큰 관점의 변화이면서 상아탑 아키텍트의 불만을 야기하는 일이기도 하다.

패턴을 위한 리팩토링

TDD에 능숙한 개발자는 개발 초기부터 디자인 패턴을 적용하는 일은 극히 드물다. 테스트 코드는 비지니스 요구사항에 맞추는 것이지 디자인 패턴에 맞추는 것은 아니다. 코드는 테스트 통과에 꼭 필요한만큼만 작성된다. 리팩토링 단계는 TDD 라이프 사이클을 따라서 중복되는 모든 부분이 제기되고 문제 도메인에 적합하게 코드를 작성했는지를 확인한다. 리팩토링이 필요한 시점은 새로운 요구사항이 나와서 기능을 추가하기 전 기능을 잘 넣기 위해 수행한다. 이러한 방식으로 적시(Just-in-Time) 설계를 할 수 있다. 코드가 추상화되면 간접 단계가 추가되고 이로 인해 비용이 발생하지만 이는 요구사항을 잘 처리하기 위해 감수해야 하는 당위성이 있다고 볼 수 있다. 실용적인 접근 방법은 실제로 필요한 상황이 생겼을 때만 추상화를 도입하는 것이다. 그렇게 하면 전체적인 복잡도를 낮추는데 도움이 된다. 당연하지만 복잡도가 낮은 시스템이 높은 시스템보다 유지보수 비용이 낮다. 디자인 패턴 자체가 나쁜 것은 아니다. 분명 우리가 활용해야 할 도구 중 하나지만 무조건 사용해야 할 도구는 아니다. 레이어를 추가하거나 추상화를 위해 코드를 리팩토링할 때 한걸음 더 나아가서 해당 문제에 흔하게 적용하는 패턴을 찾아서 적용할 수도 있다. 내가 좋아하는 패턴에 문제를 끼워 맞추기 전에 문제에 적합한 리팩토링을 단순한 설계와 SOLID 원칙을 따라서 먼저 시도해야 한다. 대신 주어진 문제에만 특정된 코드로 먼저 솔루션을 찾은 후 나중에 필요한 상황이 생겼을 때 범용화하는 것이 좋다.

장인 정신과 실용주의

실용주의가 없는 장인정신은 장인정신이 아니다. 장인이 가장 중요하게 초점을 맞추는 것은 고객의 만족이다. 품질은 물론이고 시간과 비용도 고객 만족을 위한 구성요소다. 고객에게 가치를 전달할 수 없다면 잘 작성된 코드라고 할 수 없다. 고객이 소프트웨어 프로젝트를 통해 무엇을 성취하려 하는지 반드시 이해해야 한다. 깨끗하고 잘 작성된 코드는 항상 중요하다. 깨끗하고 잘 작성된 코드는 비지니스의 요구에 맞춰 빠르고 안전하게 변경할 수 있는 기반이 된다. 요구사항의 변화에 맞춰 코드를 빠르게 바꿀 수 있는 것이 비지니스를 돕는 최선의 방법이다. 품질은 비싼 것이 아니다. 장인으로서 우리 역할은 특별히 이슈가 되지 않을 정도까지 품질 비용을 낮추는 것이다. 이 때 새로운 스킬, 새로운 실행 관례, 새로운 기술을 배우고 마스터하는 것은 병목점이 된다. 이를 위해 좋은 실행 관례를 마스터하고 실용주의적인 입장을 취할 필요가 있다.

소프트웨어 장인으로서의 커리어

마지막 장인 이 부분에서는 장인이 된다는 것이 어떤 의미인지, 성공적이고 만족스런 커리어를 어떻게 꾸릴 수 있을지에 대해 서술한다.

장인의 길

장인의 길은 열정으로 요약할 수 있다. 문제를 단순한 방법으로 푸는 데 열정적이다. 배우고 가르치고 공유하는 데에도 소프트웨어 산업이 진화하도록 돕는 데도 열정적이다. 또한 겸손해야 한다. 항상 더 나은 개발자에게 뭔가를 배울 자세가 되어 있고 경험이 적은 개발자를 돕기를 주저하지 않는다. 또한 다음 세대의 장인을 키우는데 사회적 윤리적 의무감을 느껴야 한다. 그렇게 함으로써 소프트웨어 산업을 더욱 성숙하고 프로페셔널해지도록 만들어야 한다.

좋은 코드를 작성하고 비니지스 가치를 전달하는 것만으로는 좋은 개발자가 될 수 있지만 장인이 될 수 없다. 장인의 일종의 삶의 철학이다. 항상 최고의 코드를 만들도록 다른 것을 희생해서라도 계속 배우고 남을 도우리라는 각오를 하는 것이다. 장인으로서의 삶은 아름다운 코드를 작성하기 위한 일생에 걸친 헌신과도 같다. 소프트웨어를 통해 가치를 창출할 수 있는 더 나은, 더 효과적인 방법을 찾는 끊임없는 노력의 길이다.

장인이 된다는 것은 새로운 것에 대해 호기심을 가지고 실험한다는 것과 같은 의미다. 장인은 특정 도구, 개발 언어, 프로임워크에 독단적인 고집을 부리지 않고 주어진 문제에 가장 적합한 도구를 찾고 단순한 해결책을 추구한다. 최선이라도 알려진 몇몇 조합에 대해 완전하게 마스터하고 있어야 한다. 마스터한 도구가 없다면 장인이라고 할 수 없다. 또한 코드 작성이 아니라 문제 해결에 집중한다. 코드를 작성할 때는 높은 품질의 코드를 작성하는데 집중한다. 테스트 가능하며 쉽게 이해할 수 있으며 수월하게 유지보수할 수 있는 코드를 작성하는데 집중한다.

정직과 용기는 소프트웨어 장인이 갖춰야하 할 핵심적인 자질이다. 정직과 용기란 필요한 상황에서 고객에게 ‘아니오’라고 말할 수 있는 것을 의미한다. 고객이 비현실적인 요구를 할 때 고객과의 껄끄러운 상황이 발생할 것을 알면서도 그 요구를 제대로 반영하기 힘들다고 전달하는 것이다. 고객이 나쁜 의사결정을 할 때도 마찬가지다. 그저 아니오라고 대답하는 것만이 장인으로서의 태도는 아니다. 모든 아니오에는 항상 대안을 제시해야 한다. 장인의 커리어는 정직과 용기 위에 세워진다. 장인은 고객에게 뭔가를 숨기지 않는다. 장인과 고객의 동반자 관계는 정직과 용기, 완전한 투명성으로 이뤄진다.

커리어의 진전

모든 전문직에는 커리어 사다리가 있다. 소프트웨어 개발 직능의 사다리를 오른다는 것이 관리자나 아키텍트가 된다는 의미는 아니다. 그것은 커리어의 진전이라고 볼 수 없다. 훌륭한 관리자나 아키텍트가 되는 데 필요한 스킬과 훌륭한 개발자가 되기 위한 스킬이 서로 같을 수 없기에 사디리를 오른게 아니라 사다리 자체를 바꾼 것이다.

여정과 이정표

회사 안에서의 커리어와 소프트웨어 장인으로서의 커리어에는 매우 큰 차이가 있다. 성공한 소프트웨어 장인은 스스로의 커리어를 매우 신중하게 계획한다. 뭔가를 배우고 더 나은 프로페셔널이 되기 위한 기회를 찾는다. 다음 단계를 위해 앞서 보고 계획하는 것은 성공적인 커리어를 위해 핵심적이다. 오래 지속되고 성공적인 커리어에 관심을 기울이는 프로페셔널이라면 직장은 급여 이상의 의미가 있다. 직장은 커리어를 위한 지속적인 투자다. 급여를 대가로 해서 일을 하는 것 말고도 우리의 열정과 헌신 그리고 업무 외 개인 시간을 들여 확보한 지식을 투자하여 일터를 더 나은 곳으로 만든다. 단순히 일을 하는 곳이 아니라 배우고 성장하는 장이 되게 한다. 항상 더 많은 것을 제공하고 더 많은 일을 수행해서 내 주변의 모두가 더 나아지도록 한다.

커리어 만들어 나가기

커리어를 만들어나갈 때 아래와 같은 질문을 스스로에게 던졌다.

• 나의 커리어로부터 나는 무엇을 원하는가?
• 그것을 성취하기 위한 다음 단계는 무엇인가?
• 이 일은 나의 커리어 방향과 일치하는가?
• 내가 이 회사에 줄 수 있는 가치의 양은 얼마나 되는가?
• 그러한 투자에 대한 이익은 무엇인가?
• 그러한 투자는 대략적으로 얼마동안 지속되어야 하는가?
• 내가 되고자 하는 프로페셔널에 이르는 데 이 일은 어떻게 도움이 되는가?
• 이 일에서 나는 자율성, 통달, 목적의식을 가질 수 있나?
• 나의 고용주와 생산적인 동반자 관계를 맺을 수 있나? 양측 모두 가치 얻고 행복할 수 있나?

수행한 프로젝트, 일 하나하나가 여정에서 우리가 더 멀리 나아갈 수 있게 해준다. 일을 선택하는 것은 매우 신중해야 한다. 개인의 커리어 열망과 방향이 합치하는 한 그 회사에 가능한 오랫동안 머무르길 권한다. 앞으로 나아가지 못하고 정체되어 있다고 느낀다면, 무언가를 배우거나 스스로 일을 즐기지 못한다면 그 때는 움직여야만 한다. 회사와 동료를 사랑한다는 것만으로는 그 일을 계속해야 하는 충분한 이유가 되지 못한다.

원하는 바를 모른다면 어떻게 해야 할까

내가 무엇을 원하는지, 어디로 가기를 원하는지, 다음에 무엇을 했으면 하는지 항상 알고 있을 수는 없다. 어떤 때는 길을 잃고 그저 혼란스럽기만 할 수 있다. 그 사실을 인정하는 데는 상당한 용기가 필요하지만 한 번 인정하고 나면 모든 것이 나아진다. 그러고 나서 할 일은 마음을 열고 사람들을 만나는 것이다. 껍질을 벗고 뛰쳐 나와 할 수 있는 한 최대한 많은 문을 열어봐야 한다. 커뮤니티 행사에 참석하고 오픈 소스에 기여하고 토론 메일링 리스트에 참여한다. 영감을 줄 수 있는 사람도 찾아 나서는 게 좋다. 이렇게 하면 모르던 큰 세상이 있음을 알게 되고 그 곳에 기회가 있음을 알게 된다.

다양성

소프트웨어 개발은 다양성이 상당히 높은 전문 분야다. 성공적인 장인이라면 넓은 방면으로 다양한 경험이 있다. 다양한 환경을 경험하는 것은 전문화된 장인에 이르는 길에도 도움이 된다. 인적 네트워크는 소프트웨어 장인으로서 커리어를 개발해 나가는데 큰 도움이 된다. 여러 프로젝트, 환경, 회사, 산업, 기술, 소프트웨어적인 문제 접근 방법론을 경험해 나가면서 어떤 분야에 집중할지 방향을 잡을 수 있으니 이 또한 장인이 되기 위한 여정이다.

소프트웨어 장인의 사명

소프트웨어 장인은 자신만의 사명이 있다. 더 나아지는 데 집중하고 계속해서 자신의 커리어에 투자하며 배우고 가르치고 공유헌다. 그가 맡은 고객에게 항상 가치를 전달할 수 있도록 해야 한다. 프로페셔널리즘, 열정, 관심으로 소프트웨어 산업의 수준을 높이는 것이다.