[CHAPTER 14] 기술적 변화의 실행

새로운 기술적 실행 관례나 도구를 도입하거나 그러한 것들에 대한 태도를 바꾸려 할 때 상사나 관리자를 설득하는 것보다 실무 개발자들을 설득하기가 훨씬 어려운 편이다.

시작부터 저자가 말하는 내용이다. 변화를 시도하기 위해선 같은 실무 개발자를 설득하는 게 더 어렵다고 한다.

 

기술 변화를 시도할 때 발생하는 회의론과 새로운 아이디어에 좀 더 열린 태도를 갖도록 설득하는 방법을 살펴본다.

변화를 반대하는 다양한 회의론과 그런 실무 개발자들을 설득하는 방법을 알려주는 게 이번 챕터의 내용이다.

 

 

회의론의 종류

새로운 문화, 실행관례, 도구, 절차를 도입할 때 가장 먼저 어떤 반발에 부딪힐지 미리 파악해야 한다.
테렌스 라이언은 그의 저서 [기술적 변화 추진하기]에서 회의론의 종류 를 다음과 같이 정리했다.

- 무지 : 특정 도구나 실행 관례를 쓰지 않는 주요한 이유가 단지 잘 몰라서인 경우다. 자신이 일하고 있는 좁은 책상에만 갇힌 채 밖에서 어떤 일이 일어나고 있는지 이해하려 노력하지 않는다.

- 너무 바쁜 : 너무 바빠서 뭔가를 할 시간이 전혀 없는 사람들이다. 

나도 예전엔 무지, 너무 바쁜이였다. 첫 회사에선 주변엔 같은 신입밖에 없었고, 바쁜 일정 속에서 할 수 있는 건 배웠던 걸로 어떻게든 해야 한다는 압박뿐이었다. 저자는 좁은 책상이라 표현했는데, 나는 두 가지가 결합된 작은 새장이라 말하고 싶다. 잘못된 환경이란 새장에 갇혀 집도 못 가고 일주일 내내 회사에만 있어야 하고 밖이 어떤지도 알 수 없고 안에서 모든 걸 해결해야 하는 상황이었다. 유일한 밖과의 소통은 문제 해결을 위한 구글링뿐. 

 

- 대중 :어떤 결정을 내리기에 자신의 경험이 충분치 않다고 생각한다. 더 똑똑하고 경험 많은 개발자들에게 맡기려 한다.

대부분 주니어라면 결정을 시니어에게 맡길 것이다.

 

- 냉소주의  : 논쟁을 좋아하고 지속적으로 자신이 남보다 잘났음을 증명하려 든다. 꼬투리 잡아 작은 문제를 큰 문제로 이슈화시킨다. 똑똑해 보이는 것을 더 중요하게 여긴다. 

어떻게든 정치로 남을 깎아내리고 본인을 돋보이게 만들려 한다. 

 

- 트라우마 : 과거 변화를 시도했으나 실패한 경험이 있는 사람들이다. 상황을 피하려 한다.

아직까진 이런 사람들을 본 적이 없다.

 

- 상사 : 상사가 기술 배경이 없다면 제안하는 것들이 어떤 장점이 있는지 이해하지 못할 가능성이 높다.

개발자 출신이 아닌 관리직이거나 개발에서 오랫동안 손을 떼는 경우에 해당되지 않을까?

 

- 몰상식 : 가장 최악의 타입이다. 다른 타입들의 경우 합리적이고 논리적인 판단을 한다. 하지만 몰상식한 사람들을 대상으로는 불가능하다. 아무런  합리적 근거도 없이 생트집을 잡는다. 

말로만 들어도 최악의 타입이다. 다행히 겪어 본적이 없다. (롤이란 게임을 하면 많이 볼 수 있을지도?) 

 

그 외에도 저자가 추가한 목록이다

- 무념무상 : 어떻게 되든 아무런 상관을 하지 않는다. 그냥 남들과 같이 흘러갈 뿐이다. 이들의 문제는 좋은 아이디어를 대충 엉망으로 구현해서 나쁜 아이디어로 만든다

이런 분류를 가장 많이 보았다. 나도 첫회사에서 플젝을 파견 나가면 그냥 같이 흘러갈 뿐인 존재였다. 다만 내용과 다르게 좋은 아이디어를 제시하는 사람이 없었다.

 

- 피해망상 : 위험한 개발자다. 스스로 불공정한 대우를 받고 있다고 느끼며, 회사를 싫어하고 불평불만과 회사에 대한 험담이 잦다. 이런 사람의 존재는 팀을 파괴하고 서로 비난하게 만든다. 

불평불만을 하는 사람은 많았지만 피해망상이라고 생각될 정도의 사람은 없었다. 모두 불공정한 대우는 사실이었기 때문... 대부분 같은 생각으로 회사를 욕하는 경우를 봤다.

 

- 무능력 : 제안의 본질을 파악하지 못한다. 위의 '무지'와는 다르게 인지능력, 이해능력의 부족을 보인다. 

- 상아탑 아키텍트 : '몰상식'과 함께 최악의 회의론자들 중 하나다. 모든 것을 알고 있다고 생각한다. 자신이 제일 높은 위치에 있다고 생각하나 수년 동안 실무 코드를 한 줄도 만든 적이 없는 게 대부분이다. 실무와 동 떨어지는 개념 설명용 코드밖에 없다. 이들은 모든 기술적 결정에 자신이 책임져야 한다고 말하지만 실제로 책임을 지는 일은 드물다. 잘못되면 지시를 '제대로' 따르지 않은 개발자 탓이다.

'무능력', '상아탑 아키텍트'를 같이 묶은 이유는 이런 유형의 관리자를 경험해봤기 때문이다. 투입된 프로젝트에서 관리자가 회사 대표라는 말에 잘 이끌겠지 생각했었지만 위의 케이스가 해당되는 사람이었다. 가장 끔찍한 경험이었고 평생 기억에 남을 프로젝트다. 현재 들리는 소식으론 그 회사는 망했다고 한다.

 

- 좌불안석 : 자신이 다른 사람으로 대체되어 직무를 잃거나 해고될까 봐 걱정한다. 이러한 개발자들은 사업의 핵심이 기술이 아닌 조직에서 흔하게 만날 수 있다. 

가장 흔하게 볼 수 있는 분류 중 하나다. 사용자의 모든 업무를 자동화하면 개발자는 먹고살 수 없다고 말하던 사람도 몇 있었다.

 

- 팬보이 : 특정 주제나 관점에 광적으로 전념하는 사람들이다. 특정 도구나 언어, 프레임워크에는 전문가다. 잘 아는 분야가 그것밖에 없기 때문에 다른 대안들을 거부한다.

몇몇의 개발회사나 솔루션 회사가 이런 경우가 있다. 내가 겪었던 솔루션회사는 고인물이 많고 주니어는 거의 없었다. 그들이 사용하는 언어나 프레임워크를 광적으로 좋아하고 다른 언어나 프레임워크를 하찮게 본다. 그들의 기술이 진리이며 최고라 생각한다 말이 안 통하는 수가 있다.

 

 

준비

진정으로 바꾸고 싶다면 가장 중요한 것은 용기다.
언성이 높아지는 논쟁을 두려워해서는 안된다.
싸울 준비가 되어있어야 한다.
장인이라면 반드시 가져야 할 핵심 가치다.

위에서 언급된 희의론을 설득하려면 논쟁은 피할 수 없다. 감정소모도 대비해야 한다.

 

다음은 저자가 말하는 준비 요소들이다.

- 단순함을 추구 : 아이디어나 제안은 아주 명료하고 단순해야 한다. 누구든지 이해하기 쉽게 만들어야 한다.

누군가 좋은 아이디어나 제안을 제시했다. 하지만 너무 복잡해서 다른 구성원들이 이해하지 못하면 기피하게 될 거다.

 

- 상대방의 언어로 말하기 : 설득해야 하는 상대방이 다른 직무의 사람일 수 있다. 그들의 관점에서 그들의 언어로 말해야 한다.

개인적으로 가장 힘든 요소라 생각한다. 상대방의 언어로 말하는 것은 상대방이 하는 업무, 비즈니스를 이해하고, 내가 말하는 제안이나 아이디어가 상대방의 관점에서 어떤 영향을 끼쳐야 하는지 알야야한다는 것을 의미한다.

 

- 말할 내용에 대해 스스로 제대로 이해하기 : 연구, 실험 연습해야 한다. 어떤 반대 의견이나 문제 지적을 예상하고 답을 미리 준비해둬야 한다. 제안이 단점이나 문제 상황은 미리 밝혀야 한다. 미리 밝히는 것은 제안 자체에 신뢰성을 높인다. 

정직하게 단점을 공개하라는 얘기다.

 

- 상대방을 존중하기 :  무례하고 공격적인 태도는 설득 자체가 불가능해진다.

어떤 사람이 와서 아무 설명없이 지금하고 있는거 다 뜯어 버리고 이 방법으로 다시 하라고 하면 누가 수긍을 할까.

 

- 경청하는 법 배우기 :같은 문제라도 사람들은 관점이 서로 다르다. 당신만의 결론을 내리기전에 모두의 말을 경청하고 정리해야 한다. 

 이야기를 경청해주기만 해도 존중받는다고 느낄 수도 있고, 새로운 해답을 얻을 기회도 생길 수도 있다.

 

 

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

제안했을 때 날아올 질문들을 생각하면 실현하기가 얼마나 어려운지 짐작할 수 있다.
어디서부터 시작해야 할까?

신뢰를 쌓으라
가장 좋은 방법은 지속적을 품질 좋은 소프트웨어를 딜리버리하는 것이다...
그것만으로는 충분하지 않다. 당신을 밖에 알려야 한다. 사람들에게 당신이 눈에 띄어야만 한다...
사람들은 자신의 열정을 보여주는 사람을 훨씬 더 잘 따른다...
보여주는 것으로 부족하다. 역량이 있어야 한다.

꾸준히 열정적으로 블로그나 깃허브로 관리를 해왔다면 많은 사람들에게 노출이 되었을 거다.

아무것도 없이 제안만 하는 사람과 퀄리티가 있는 글이나 코드를 남기고 꾸준히 관리하는 사람의 제안은 다를 것이다.

 

전문성을 확보하라
새로운 기술을 제안하기 전에, 본인 스스로 충분히 이해해야 한다...
다른 사람에게 가르쳐줄 수 있어야 한다...
경험이 쌓일수록 당신의 영향력은 커진다. '무지'에 빠진 사람들을 눈을 뜨게 할 수 있다...
'냉소주의'들은 당신의 자신감과 깊은 지식들 앞에 힘을 못 쓸 것이다...
전문성이 강화되면 '상아탑 아키텍트'나 '팬보이'와의 논쟁을 이겨낼 무기가 되어 줄 것이다.

전문성을 확보하는 것은 쉬운 일이 아니다. 단순히 사용만 하는 게 아닌 이해하고 다른 방법론이나 도구에 비해 어떤 점이 장점이 있고 단점이 있는지를 이해해야 한다. 여기서 장단점을 비교한다는 것은 제안 외의 다른 것도 이해한다는 것이다. 하나를 알고 둘을 알고 셋을 알고.. 꾸준히 배우려고 노력해야 한다.

 

모범을 보여 사람들을 이끌라
변화를 추진할 때, 직접 보여 주면서 따라하게 하는 것이 가장 좋은 방법이다... 
단순히 메뉴얼만 보고 시작할 수 없는 것들이 있다. TDD가 바로 그런 것들 중 하나다...
어떤 규범이나 실행 관례들은 마스터하는데 몇 년이 걸리기도 한다...
너무 어려워 포기하는 개발자들이 많다...
두려움은 함께 코드를 작성하면서 극복할 수 있다. 누군가에게 의지할 수 있다면 새로운 실행 관례를 더 편안하게 받아들일 수 있다...

전혀 새로운 것을 해야 한다면 알아보고 한번 경험해보는데 시간이 걸린다. 옆에서 누군가가 이끌어준다면 받아들이는 속도는 혼자 두려움 속에서 하는 것보다 빠를 것이다. 

 

신중하게 싸울 곳을 정하라
혼자서 모든 이슈와 조직 전체를 상대로 두고 싸울 수는 없다...
한 번에 한 가지씩 신중하게 싸울 곳을 골라야 한다...
모든 변화들을 추진하기 전에 변화들의 영향에 대해서 고려해야 한다...
싸움을 잘 선택하기 전에 어떤 변화들이 더 중요한지 따져야 한다...
당신이 준비되어 있지 않다면... 모든 부분에서 싸움을 시작하지 말자.

변화가 필요한 곳이 여러 곳이라면 각 변화를 이해해야 한다. 이해하지도 않고 싸우려들면 실패할 것이다. 

 

점진적으로 반복, 관찰, 수용하라
큰 충돌을 피할 수 있는 가장 쉬운 방법은 점진적인 변화를 제안하는 것이다...
의사결정 과정에 사람들이 참여할 수 있게 하는 것이 중요하다...
점진적인 변화를 제안하면 저항의 강도를 줄이고 위험을 최소화할 수 있다...
이 방법의 장점은 대다수의 회의론을 잠재울 수 있다.('몰상식'은 예외다)...
"... 한번 시도해보는 것뿐 결정되는 것은 없습니다."

변화가 많다면 한 번에 시도하는 것은 잘못된 방법이다. 너무나 큰 변화를 시도하는 건 기존 구성원들의 반발이 그만큼 커진다는 의미다.

저자가 주장하는 제안은 너무나도 좋은 거 같다. 완전히 바꾸자는 뜻도 아니고 한번 시도 후 정하자는 뜻이니, 장인은 노력으로 구성원들은 새로운 변화를 제대로 경험하지 않을까 생각한다. 

 

 

두려움과 자신감 부족

CEO, CTO, 관리자, 아키텍트 또는 팀 리더의 자리에 자질이 전혀 없는 사람이 있는 것을 본 적이 있을 것이다...
바보 같은 절차를 따라야 했던 경험도, 개발팀과 전혀 관계 없는 사람이 만든 잘못된 아키텍처 때문에 갖은 문제를 떠안아야 했던 적도...
언제까지 그냥 침묵하고만 있을 것인가?

참다못해 몰상식하고 무능한 리더한테 대항하는 사람들은 몇번 봤다. 항상 나쁜 결말만 봤다. 대다수가 인사적으로 불이익을 당했다.

나도 불합리한 것을 알지만 옆에서 침묵했다.

 

설득할 자신이 없는 사람은 이런 식으로 말한다...
"... 그는 내 상사이고 인사권자다."

동감한다. 상사는 자기 뜻대로 움직이지 않는 개발자를 손쉽게 갈아치워 버린다. 또한 그런 환경속에서 일하는 것이 당연하다는 분위기가 많았다.

 

두려움은 의견을 표현하는 것을 막고, 무능함은 올바른 방향으로 변화시키기 위한 싸움을 할 수 없게 한다.

맞다. 두려움은 나를, 모두를 침묵하게 만들었고 그런 말도 안되는 불합리한 속에서 모두 스스로를 공장 노동자처럼 취급하게 만들었다. 오히려 그런 상황이 익숙해 무덤덤해진지도 모른다.  

 

무능한 사람들만이 일자리를 불안해 한다. 실수를 떠 넘기고, 정치게임에 몰두하기를 좋아한다...
진정한 소프트웨어 장인이라면, 그에 맞는 윤리 의식과 행동원칙이 있다...
주변을 바꾸고 싶다면, 두려움을 버려야 한다. 준비하고, 연습하고, 독서하고, 공부해서 스스로 도달할 수 있는 최고의 개발자로 거듭나야한다. 무슨 일이 일어나든 항상 진실을 말해야 한다.

옆그레이드란 말장난이 있다. 이직을 해도 비슷한 환경의 일자리만 간다는 뜻으로, 위로 가지못하고 항상 제자리만 돈다는 표현이다. 일하는 환경을 바꾸고 싶으면 두려움을 버리고 스스로의 현재를 인정하고 발전을 위해 노력해야 한다. 부족한 점을 인정하지 않고 대우만 받기를 원하고 일자리를 불안해하면 나 자신도 언젠간 저런 무능력하고 몰상식한 존재가 될 수도 있는 법이다.

 

 

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

장인이라면, 기술적인 역량뿐만 아니라 주니어 개발자들을 위한 롤 모델 역할도 할 수 있어야 한다. 정직하고 투명해지기를 두려워하지 않는다...
사람들이 듣고 싶은 말이 아니라 진심을 말하며 행동에 책임을 지고 최선이라면 싸우기를 주저하지 않는다...

싸우기를 좋아하는 사람을 본 적이 없다.

대다수 문제가 생기면 회피하거나 떠넘기는게 많았고, 해결하려고 노력하는 사람은 극소수였다.

고객에게 진심으로 프로젝트 상황에 대해 말하는 관리자를 본적이 없다. 상황에 상관없이 꿀발린 소리만 하던 관리자가 있었다. 

행동에 책임을 지던 책임자를 본적이 없고 엉뚱한 개발자가 뒤짚어쓰는 경우를 많이 봤다. 

이런 것을 모두 챙겨야하는 소프트웨어 장인은 멀고도 험난 길이다.  

---

후기 

이전 챕터 배움의 문화처럼 기술적 변화를 시도하는 것은 매우 힘드는 일이라는 걸 알려준다.

변화에 대항하는 다양한 회의론자를 얘기해줬으며, 어떻게 변화를 이끌어야 하는지 알려주는 좋은 챕터였다.

 

중간에 빼먹은 소주제 회의론을 상대하는 방법이 있다. 대화 내용이 많아 생략하고 넘어갔지만 간단히 설명하자면 상아탑 아키텍트와 어떻게 싸우고 이겼는지(대화 내용이 길다), 그리고 다른 회의론에 대응하는 방법이 나와있다. 

 

이 리뷰는 내 주관적인 입장에서 작성한거라 실제로 책을 읽어보면 다르게 와닿을 수 있다.