[소프트웨어 장인] 14장 기술적 변화의 실행

지금 하는 프로젝트에 새로운 개발 언어나 프레임워크를 어떻게 도입할 수 있을까? 상당수의 개발자들이 켄트 벡이 이야기한 ‘사춘기적 맹신’에 빠져 있다. 그런 개발자들은 훌륭한 소프트웨어를 만들어 내는데 자기만의 비법이 있다고 생각하고 다른 것들은 무시해 버린다.

개발자, 관리자, 아키텍트들이 기술 변화를 이끌려면, 그런 맹신에 빠진 개발자를 어떻게 다루어야 하는지 알아야만 한다. 이 장에서는 기술 변화를 시도할 때 발생하는 회의론과 새로운 아이디어에 좀 더 열린 태도를 갖도록 설득하는 방법을 살펴본다.

회의론의 종류

팀에 새로운 문화를 전파하거나 새로운 실행 관례, 도구, 절차를 도입할 때 어떤 반발에 부딪힐지 미리 파악해야 한다.

• 무지: 특정 도구나 실행 관례를 쓰지 않는 주요한 이유가 단지 잘 몰라서인 경우다. 무지에 대한 본능적인 두려움 때문에 새로운 아이디어가 제안되면 깊이 고민해보지 않고 거부부터 한다.
• 대중: 어떤 결정을 내리기에 자신의 경험이 충분치 않다고 생각한다. 자신감이 부족하여 중요한 결정들을 더 똑똑하고 경험 많은 개발자들에게 맡기려 한다.
• 냉소주의: 논쟁을 좋아하고 지속적으로 자신이 남보다 잘났음을 증명하려 든다. 이러한 종류의 개발자들은 똑똑하게 행동하는 것보다 똑똑하게 보이는것을 더 중요하게 여긴다. 새로운 것을 받아들이지 않는 이유 중 하나가 그들 스스로의 약점을 드러내고 싶지 않아서일 수도 있다.
• 트라우마: 과거 특정 실행 관례나 도구를 사용하려 시도했으나 실패한 경험이 있는 사람들이다. 이런 나쁜 경험들이 있으면 또 다시 그런 경험을 할 수도 있는 상황을 피하려 한다.
• 너무 바쁜: 어떤 일의 장기적인 비용을 보지 못하고 근시안적인 판단을 한다. 무언가 일을 올바르게 할 시간은 없지만 똑같은 일을 계속해서 반복할 시간은 있다. TDD와 같은 실행 관례는 시간이 너무 오래걸리고 전체 시스템을 매번 수동으로 테스트하고 문제를 분석하고 버그를 수정하는 시간은 보지 못한다. 특히 시스템이 망가질까 두려워 큰 규모의 개선은 엄두도 못 낸다는 사실이 얼마나 큰 비용인지 알지 못한다.
• 상사: 상사가 기술 배경이 없다면 당신이 제안하는 것들이 어떤 장점이 있는지 이해하지 못할 가능성이 높다. 상사는 관리상의 문제를 안고 있고, 당신은 개발상의 문제가 있다. “뭔가 자동화하는 도구를 만들자”라고 설명하지 말고 “프로젝트 운영 비용을 줄이자”라고 이야기 해야 한다.
• 몰상식: 가장 최악의 타입이다. 다른 타입은 하나하나 따져서 의미 있는 합의를 도출할 수 있지만, 몰상식한 사람들을 대상으로는 불가능하다. 논리적으로 반대할 내용이 없으면 이 문제에서 저 문제로 끊임없이 옮겨 다닌다. 그들이 하는 말의 내용은 아무런 상관이 업다. 단지 제안 내용을 받아들이기 싫을 뿐이다. 어쩌면 퇴사를 생각하고 있거나, 새로운 일을 만들기 싫은 경우일 수도 있다.
• 무념무상: 이들은 그냥 뭐가 어떻게 되든 아무런 상관을 하지 않는다. 그냥 남들과 같이 흘러갈 뿐이다. 이들의 문제는 좋은 아이디어를 대충 구현해서 결과적으로 나쁜 아이디어로 만든다는 것이다.
• 피해망상: 위험한 개발자들이다. 이런 개발자들은 회사가 자신에게 피해를 주고 있다고 생각한다. 팀을 파괴하고 개발자들끼리 서로 비난하게 한다. 더 최악인 것은 이런 개발자들은 절대 회사를 나가지 않는다.
• 무능력: 이들은 제안의 본질을 파악하지 못한다. ‘무지’에 속한 사람들과 확연히 구분되는 인지능력, 이해능력의 부족을 보인다. 이들은 상황을 명확하게 보지를 못한다. 막연하게 생각하며 이들이 하는 제안은 왜곡된 사실을 기반으로 한 어디선가 주워들은 아이디어들 뿐이다.
• 상아탑 아키텍트: 모든 것을 알고 있다고 생각한다. 수년 동안 상용 시스템의 코드를 단 한줄도 만들어 본 적이 없는 경우가 대부분이다. 코딩을 했다고 해도 현실과는 동떨어진 개념 설명용(Proof of concept) 코드밖에 없다. 코드를 작성하지 않기 때문에 항상 자신의 존재 이유를 증명해야 한다는 압박이 있다. 비즈니스 담당과 개발팀 간에 요구사항이 정리조차 되지 않은 시점임에도 프로젝트를 위한 기술 스택을 정의하는 것이 자신의 업무라고 믿는다.
• 좌불안석: 개발자들의 능력을 제대로 평가할 사람이 없는 조직에서 흔하게 만날 수 있다. 이들은 언젠가 회사에서 자신의 실제 가치를 알게 될까봐 두려워 한다. 그리고 소프트웨어 장인을 그들의 실체를 폭로할 위협으로 바라본다.
• 팬보이: 특정 주제나 관점에 광적으로 완전히 전념하는 사람들이다. 특정 도구나 언어 프레임워크에만 아주 오랫도안 전념해서 해당 기술에는 전문가다. 그래서 그것만이 초괴의 해결책이라고 믿고 다른 모든 대안들을 거부한다. 만약 이러한 사람들의 반대에 부딪힌다면 아주 긴 시간동안 논쟁을 벌일 준비를 해야한다.

준비

무언가 바꾸고 싶다면 가장 중요한 것은 용기다. 동료 개발자, 관리자, 기술 리더와 언성이 높아지는 논쟁을 두려워해서는 안 된다. 의견 충돌이 없는 마음 편한 대화만을 기대할 수는 없다 싸울 준비가 되어 있어야 한다. 스스로에 대한 자신감도 필요하다 자기가 하는 말이 무엇인지 스스로도 제대로 모르면서 다른 사람을 설득할 수는 없다.

• 단순함을 추구해야 한다. 명료하고 단순해야 한다. 누구든지 이해하기 쉽게 만들어야 한다. 제안이 받아 들여지느냐의 여부는, 그 내용도 중요하지만 커뮤니케이션을 얼마나 잘 하느냐가 큰 영향을 미친다.
• 상대방의 언어로 말해야 한다. 제안 내용에 따라서 상대방이 개발자, 관리자, 아키텍트, 투자자, 제품 오너, 비즈니스 분석가 등 성격이 다른 직무의 사람일 수 있다. 상대방이 사용하는 언어를 배우고 활용해야 한다. 당신의 제안이 가져올 이익을 그들의 관점에서 그들의 언어로 말해야 한다.
• 말할 내용에 대해 스스로 제대로 이해하고 있어야 한다. 연구하고, 실험하고, 연습해야 한다.
• 상대방을 존중해야 한다. 제안을 듣는 상대방을 바보처럼 느끼게 해서는 안된다. 무례하고 공격적인 태도는 사람들을 방어적으로 만들어 설득 자체가 불가능해진다.
• 경청하는 법을 배운다. 당신만이 좋은 아이디어를 갖고 있다고 오판해서는 안 된다.

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

신뢰를 쌓으라

사람들이 당신을 믿어 주지 않는다면 아무런 변화도 이루어낼 수 없다. 개발자로서, 동료 개발자들이나 관리자 고객들과 신뢰를 쌓는 가장 좋은 방법은 지속적으로 품질 좋은 소프트웨어를 딜리버리하는 것이다. 사람들은 단순히 그냥 무언가를 하자고 하는 사람보다 자신의 열정을 보여주는 사람을 훨씬 더 잘 따른다. 무엇보다도 신뢰를 쌓으려면 역량이 있어야 한다. 사람들이, 당신이라면 그 일을 해낼 수 있을 것만 같은 느낌이 들어야 한다.

전문성을 확보하라

새로운 기술을 제안하기 전에, 본인 스스로 충분히 이해해야 한다. 무엇보다도 그 기술의 활용법을 다른 사람에게 가르쳐 줄 수 있어야 한다. 당신의 학습과 시행착오에 대한 경험은 다른 사람들의 학습 곡선을 단축시키는 데 도움이 될 수 있다. 경험이 쌓일수록 영향력은 커진다. 논쟁에서 지더라도 이전보다 더 많은 지식이 쌓일 것이기 때문에 더 나은 프로페셔널이 된ㄴ다. 그런 상황은 상호 이득이다.

모범을 보여 사람들을 이끌어라

기술적 변화를 추진할 때, 특히 TDD 처럼 대토에 대한 변화까지 필요로 한다면, 직접 보여 주면서 따라하게 하는 것이 가장 좋은 방법이다. 어떤 규범이나 실행 관례들을 편하게 쓸 수 있는 정도까지 도달하기가 어려워 포기하는 개발자들이 많다. 관리자들은 일정과 생산성에 대한 걱정 때문에 도입을 포기하는 핑계로 사용한다. 처음 해보는 것에 두려움은 바로 옆에 앉아 함께 코드를 작성하면서 극복할 수 있다. 누군가에게 의지할 수 있는 상황이라면 새로운 실행 관례를 더 편안하게 받아 들일 수 있다.

팀의 행동방식을 바꾸거나 새로운 기술과 실행 관례를 수용하게 하고 싶다면, 제일 먼저 당신 스스로 그것을 할 수 있는지 확인해야 한다.

신중하게 싸울 곳을 정하라

혼자서 모든 이슈와 조직 전체를 상대로 두고 싸울 수는 없다. 한 번에 한 가지씩 신중하게 싸울 곳을 골라야 한다. 모든 부분에서 싸움을 시작하지 말자. 모든 이슈들이 똑같이 중요하지는 않다. 정말 의미 있는 곳에 노력을 집중하고 더 빨리 가치를 얻을 수 있는 싸움에 우선순위를 두자

점진적으로 반복, 관찰, 수용하라

큰 충돌을 피할 수 있는 가장 쉬운 방법은 점진적인 변화를 제안하는 것이다. 의사결정 과정에 사람들이 참여할 수 있게 하는것이 중요하다. 모두가 자신의 생각을 동등하게 피드백할 수 있는 과정이 있어야 한다. 과정에 직접 참여하고 있다고 느끼게 되면 서로 싸우기 보다는 훨씬 협조적인 분위기가 된다. 점진적인 변화를 제안하면 저항의 강도를 줄이고 위험을 최소화할 수 있다. 잘 정의된 피드백 루프를 갖추고 각 작업 주기마다 조금씩 변화를 이루어 낸다.

두려움과 자신감 부족

두려움이 있는 데다가 자신감이 부족하면 회사는 관료적이고 정치적으로 변한다. 잘못되고 비효율적인 솔루션이라는 것을 모두가 알고 있지만 아무도 상사에게 문제 제기하려 들지 않는 상황도 겪어 보았을 것이다.
두려움은 프로페셔널로서 행동하고 자신의 의견을 표현하는 것을 막고, 무능함은 우리를 둘러싼 일들을 올바른 방향으로 변화시키기 위한 싸움을 할 수 없게 한다.

무능하고 비겁한 사람들은 일을 제대로 해내는 것보다 다른 사람의 뒤에 숨어서 실수를 떠 넘기고, 승진을 위한 정치 게임에 몰두하기를 좋아한다.

이런 태도는 매우 이기적이고, 프로페셔널하지 않을 뿐만 아니라 부도덕하다. 프로페셔널 개발자라면 그에 맞는 윤리 의식과 행동원칙이 있다.

당신의 주변을 바꾸고 싶다면, 두려움을 버려야 한다. 준비하고, 연습하고, 독서하고, 공부해서 스스로 도달할 수 있는 최고의 개발자로 거듭나야 한다. 무슨일이 일어나든 항상 진실을 말해야 한다.

상사를 설득하는 방법

고객은 개발자에게 높은 품질의 소프트웨어, 훌륭한 솔루션을 기대한다. TDD, 페어 프로그래밍, 연속된 통합 등의 실행 관례들은 모두 그러한 것들을 달성하도록 돕기 위함이다. 누군가에게 물어볼 것 없이 그냥 실행하면 된다.

무슨 일을 하든 고객에게 가치를 전달해야 한다. 일의 진척 상황에 대해서 정직하고 투명하게 말해야 한다. 단, 직접적인 질문이 없다면 상세한 내용에 대해서 일일이 짚어서 설명할 필요는 없다. 그런 것들은 고객 입장에서 전혀 중요하지 않다. 관리자에게 리펙토링이나 단위 테스트 업무를 위해 시간을 달라고 요청하는 것 자체가 의미가 없음을 말하고 싶다.

상세사항을 많이 노출하면 할수록 관리자가 당신에게 더 세세하게 업무 지시를 하고 싶게 만든다.

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

개발자는 습관대로 하려는 편이고 자기 주관이 뚜렷한 경우가 대부분이다. 그냥 가서 해보자고 말한다고 순순히 따라오지는 않는다. 실행 관례를 전파하는 가장 효율적인 방법은 모범을 보이는 것이다. 당신과의 페어 프로그래밍에 초대해서 어떻게 하는 것인지 보여주자.

회의론을 상대하는 방법

의사 결정 과정에 모두가 참여하도록 만드는 데 주의를 기울이자. 나의 의견을 일방적으로 요구해서는 안 된다. 작업 주기가 전환되는 시점에 새로운 것을 시도해 볼 것을 제안하자. 이때 누군가의 자리를 위협하는 것처럼 보여서는 안 된다. 무언가를 더 나아지게 만드는 데 목적을 두어야 한다. 스스로 상사가 되거나 모든 개선 사항에 자신의 업적을 주장하려는 데 목적을 두어서는 안 된다. 팀의 여느 개발자와 같은 위치에서 제안해야 한다.

자신감을 축적하고 당신이 아는 것을 다른 사람들에게 가르쳐 주는 행위는 주변 사람들에게 신뢰를 쌓는 최선의 방법이다. 종국적으로는 롤모델이 되어야 한다. 누군가가 따르고 싶어하고, 조언을 듣고 싶어하는 사람이 되어야 한다.

상아탑 아키텍트

소프트웨어 장인들은 개발할 때 보다 애자일스러운 접근을 고려하지만 상아탑 아키텍트는 초기부터 큰 설계를 밀어 붙인다. 잘못된 아키텍처 설계로 인해 많은 개발자들이 고통받을 때 그는 아무런 고통도 느끼지 못한다.

권한과 책임

상아탑 아키텍트는 자신이 모든 결정을 책임지는 사람이고, 개발자들은 단지 자신의 비전을 실행할 단순 코더들로 취급한다. 하지만 그가 결정에 책임 있게 행동하는 경우는 극히 드물다. 우리가 취할 수 있는 행동 중 하나는 상아탑 아키텍트가 자신의 결정에 책임을 질 수 밖에 없도록 만드는 것이다.

권한을 갖고 싶다면, 책임질 수 있는 준비를 해야 한다. 이미 책임이 주어져 있다면, 관련된 의사결정에 권한도 가질 수 있도록 해야 한다. 그들이 당신 앞을 가로 막는 것을 피하고 싶다면, 그들의 결정에 책임지도록 만들어야 한다.

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

잘못된 조직과 업무 환경에서는 소프트웨어 장인이 고객에게 가치를 전달하기가 어렵다. 고객에게 가치를 전달하는 것은 단순히 코딩을 의미하지 않는다. 완벽한 솔루션을 전달하려면 단지 코드를 잘 작성하는 것만으로는 충분하지 않다.

요약

일을 잘 해내려면 소통을 명확히 해야 한다. 대화하는 상대방을 이해하고, 그 사람의 생각의 바탕에 어떤 이유들이 있는지 공감할 수 있어야 한다.

참조

• 소프트웨어 장인