[CHAPTER 13] 배움의 문화

구성원들이 동기가 부여되어 있지 않거나 자신의 일 자체에 별 관심이 없으면 그 어떤 변화도 효과적으로 일으킬 수 없다.
...
관리자들은 상황을 얼마든지 더 악화시킬 수 있다. 개발자들이 새로운 규칙을 준수하도록 업무 고과나 보너스를 연계시키는 것이다.

이전 챕터와 이어지는 내용이다. 관리자가 잘못된 방법으로 변화를 이끄려 한다면 더 안 좋은 상황이 될 거라 말한다.

 

이 장에서는 배움의 문화를 만들기 위해 개발자들이 할 수 있는 여러 활동들에 대해 살펴본다.

 

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

어느 유명한 투자 은행에서 회사에 일을 맡겼다. 고객사의 요구사항은 매우 특정적이었다.
"우리의 레거시 코드 베이스에 단위 테스트를 역을 끼워 맞춰줄..."
작업을 고객사가 아닌 우리 회사의 사무실에서 하기를 바랐다. 뭔가 꽤 잘못되었다고 느꼈다...

레거시 프로젝트에 테스트코드를 추가해달라는 고객이라니, 일이 바빠서 외부인력이 필요한가? 생각되는 내용이다.

하지만 고객사에 상주하는 것도 아니고 비상주로 만들어달라니. 무언가 이상하다. 레거시 프로젝트를 이해하려면 담당자와 소통이 필요한데 담당자를 회사에 보내주겠다는 건지 알 수가 없다.

 

몇 달 동안 레거시 코드를 작성한 사람들과 말 한마디 나눠보지도 못한 상태에서 그 코드들에 대한 테스트를 작성했다.

담당자 없이 코드를 보면서 이해하고 테스트를 작성해야 한다니 얼마나 난해한 작업인지 상상도 안 간다.

 

테스트를 작성하면서 코드 베이스의 미묘한 동작들이 버그인지 원래 의도한 것인지 아리송한 상황이 꽤 많았다...
전체적인 설계 관점에서 올바른 지도 전혀 알 수 없었다...
고객사의 개발자들과 이야기를 해보려 했지만 그 부분은 계약 조건에서 배제되어 있었다...

 담당자 이야기를 하고 싶어도 계약에서 배제되어 할 수가 없다니, 잘못되어도 한참 잘못되었다.

 

더 최악인 것은, 고객사의 개발자들은 코드 베이스를 변경할 때, 테스트 코드를 수정하지도, 추가하지도 않았다...
고객사의 최신 코드를 가져올 때마다 어김없이 테스트가 망가졌다.

테스트를 만들어 달라는 고객이 오히려 테스트를 매번 망가뜨리다니 얼마나 모순된 모습인가?

테스트를 작성하는 개발자의 입장에서 어떻게 생각할지 상상도 안된다.

 

그 프로젝트가 끝나고 한참 후 정체가 무엇인지 물었다...
그 해에 고객사의 고위 기술 담당이 테스트 커버리지를 70%로 올리는 것을 목표 중 하나로 설정했고 팀의 보너스가 영향을 받았다. 그 목표 달성 부분을 그냥 아웃 소싱했던 것이었다.

우리가 그 고객사에 그 일이 잘못되었을 뿐만 아니라 위험하다는 점을 이야기했다면 제대로 된 도움을 줄 수 있었을지도 모른다...

결국에는 그 고객사에서 보너스만 노린 엉뚱한 투자였음을 알게 되었다.

단순하게 보너스가 달려있다는 이유로 중요한 테스트를 외부인력에 맡겼다는 게 놀라울 따름이다.

개인적으로 더 놀라운 건 저자가 일했던 회사의 자세다. 잘못된 것을 깨닫고 도움을 줄 수 있었을 거란 반성하는 말에 정직하고 올바르다고 느껴진다.

 

우리는 교훈 하나를 얻었다. 새로운 절차나 실행 관례를 강제한다고 조직을 변화시킬 수 없으며 우리는 배움의 문화를 만들어 내야 한다.

배움의 문화를 만들어하면 어떻게 해야 할까? 스스로 시간을 투자해서 배우게 하기 위해선 무엇을 해야할까?

 

 

배움의 문화 만들기

배움의 문화를 만들면 회사에 효율적으로 열정을 주입할 수 있다.

배우기 위해 노력할 수 있도록 문화가 형성되면 얼마나 좋을까? 내가 겪어본 SI 프로젝트나 여러 고객사 그리고 고객사로 이직하여 직접 만든 플랫폼을 운영했던 경험까지... 저자가 말하는 배움의 문화가 형성된 곳을 체험해 본 적이 없다.

다만 몇몇 회사에서 배움에 대해 금액을 지원하는 경우가 있었지만 제약사항이 심해서 사용하는 직원은 아무도 못봤다. 있으나마나 보여주기식이 많았다.

 

일에 불평불만과 한탄을 쏟아내는 아무런 동기 부여도 없는 개발자들을 옆에서 지켜보는 경우가 더 흔하다. 롤 모델이 부족하기 때문에 주니어 개발자들은 소프트웨어 개발이라는 것이 신나는 커리어가 아니라고 믿게 된다.

예전에 개발자는 40대가 되면 관리자가 되거나 은퇴하고 치킨집을 차려야 된다는 말이 많았고, 실제로 그렇게 된 개발자들이 많았다. 

흔히들 30대 후반부터 40대 개발자의 한 명의 인건비로 신입 개발자 여러 명을 고용하는 게 더 이익이라고 말했던 개발자를 공장 노동자로 취급한 시절이였고, 지금도 변함없이 그렇게 이어저 오는 곳이 많다.

이런 환경 속에서 주니어는 개발이 그저 그런 커리어라고 인식하게 만들기 쉽다.

 

완전히 다른 성향의 선배 개발자들 속에서 일한다면 어떨까? 배움과 자기계발의 열정이 가득하고 자기가 하는 일에 애정이 있으며...
그러한 환경은 장인이 되기 위한 열망을 불어넣는 것은 물론 개발이라는 일 자체를 즐길 수 있도록 북돋울 것이다.

솔직히 우리나라에 이러한 배움의 문화가 되어있는 곳이 너무나도 적다. IT 인력시장을 많이 차지하는 것은 SI 업계이고 이런 곳은 대부분 공장 노동자로 취급한다.

 

동기가 부여된 사람들은 일을 재미있게 할 뿐만 아니라 항상 바깥세상에 관심을 갖는다.
회사 입장에서는 외부로부터의 혁신과 효율을 지속적으로 수혈받을 수 있는 큰 이득이 생긴다.

우리나라에서 배움의 문화가 있는 곳을 쉽게 찾으려면 인력시장이 좁은 서비스업을 찾아봐야한다.

 

저자는 배움의 문화를 조성하기 위해 개발자들이 할 수 있는 것을 다음과 같이 나열했다.

 

- 북 클럽에 가입하기
책을 하나 선택해서 동료들에게 읽기 시작할 거라고 공표하자. 관심이 있거나 관련 내용에 토론을 하고 싶다면 한주에 한번 함께 모이자고 하자. 동료 중 한명이라고 관심을 보인다면 시작할 수 있다.
아무도 관심이 없다면 동료들이 관심이 있을만한 주제를 탐색해본다.
그래도 아무도 없으면 그냥 본인이 원하는 책을 읽기 시작한다.

- 테크 런치 진행하기
일주일에 한번 정도 점심시간에 기술과 관련된 난상 토론회를 가지는 것을 제안해보자. 어떤 형식을 갖출 필요가 없다. 아무거나 이야기하면 된다.
다만 업무의 연장선으로 만들지 않는 것이 좋다. 이 토론회는 배움에 대한 것으로 만들어야 한다.

- 그룹 토론회에 참여하기
사무실 벽이나 화이트보드를 둘로 나눈다. 한쪽엔 각 참여자들에 의해 짧은 주제 발표가 될 항목들을 모으고, 다른 쪽은 토론 대상 주제들을 모아 놓는다. 약 5분 동안 주제를 발표하고 2분간 질의응답을 한다. 시간을 잘 지키도록 관리한다. 주제 발표가 끝나면 토론 주제로 넘어간다.

- 업무 교환하기
회사내의 개발팀들 각각 서로 다른 애플리케이션이나 시스템의 상이한 부분을 담당할 때가 많다. 특정 시기가 지나면 반복 업무가 된다. 너무 익숙해져 다른 방법들을 탐색해보지 않게 된다. 매너리즘에 빠지고 지루함이 찾아온다. 개발자 교환을 통해 이러한 매너리즘을 해결할 수 있다.
다음은 몇가지 긍정적인 효과다
 기존 결정들에 대한 재검증 : 새로운 사람은 기존 결정 맥락을 이해하고 올바른 것이었는지 확인해 줄 수 있다.
 지식의 공유 : 새로운 개발자는 특정 문제들이 어떻게 해결되었는지 배울 수 있다.
 개선 : 문제들을 해결할 더 나은 방법을 제안할 수도 있다.
 공동 학습 : 서로 현재의 해결책을 토론하고 지식들을 공유하면 더 나은 해결책이 떠오를 수 있다.

- 얼마 동안만 업무 교환하기
위의 업무 교환의 변형으로 몇 시간 내지는 며칠동안 팀 개발자를 교환 할 수도 있다.

- 그룹 코드 리뷰하기
문화를 만들어가기 위한 재미있는 방법이다. 모두가 리뷰에서 이루어진 결정에 책임감을 느끼고 어떤 것이 품질을 만들어내는지 되새기게 된다. 올바르게 수행하는 것이 중요하다.
다음은 올바르게 수행하는 것의 의미다.
 1. 주석은 주관적, 개인적으로 표현되어서는 안된다.
 2. 누가 코드를 작성하느냐는 중요하지 않다.
 3. 커밋 히스토리를 뒤지지 않는다. 과거를 파헤치지 말고 미래를 변화시키는 데 집중한다.
 4. 주석은 반드시 객관적이고 생산적이어야 한다. 어떻게 코드를 개선할지에 집중해야 한다.
 ...

너무 많아서 생략한다. 하지만 간단히 방법만 언급하자면 코딩 실습하기, 사용할 기술은 가능한 자유롭게 선택하기, 내부 학습 모임을 만들기, 회사에서의 펫 프로젝트 시간을 허용하기, 외부 커뮤니티와 교류하기가 있다.

 

 

아무도 참여하려 하지 않는다면

힘이 빠지는 소주제다. 배움의 문화를 만들기 위해 노력을 해도 무관심하다면 어떻게 해야할까?

저자는 그런 장인들을 위한 조언들을 남긴다.

무언가에 관심을 갖도록 사람들의 행동을 변화시키기는 어려운 일이다.
더 나은 일터로 만들기 위해 모든 사람을 바꿀 필요는 없다.

다음은 배움의 문화를 조성하도록 위한 조언들이다.
- 모범을 보여라
- 관심을 보이는 사람들에게 집중하라
- 강제하지 마라
- 모두를 변화시키려 들지 말라
- 모임에 대한 약속을 제때 하라
- 허락을 구하지 마라
- 투덜대지 마라
- 리듬을 만들라

 

---

후기

동기부여를 위한 배움의 문화가 주제였다.

나는 이번에 언급된 방법 중에서 하나라도 겪어보지 못했다. 다만 다른 서비스업에 있는 사람들이 위에서 언급된 방법처럼 했다는 것만 들었다. 그럴 때마다 부러워했다. 나도 몸 담았던 회사에서 배움에 대한 문화나 복지가 있는지 알아보기도 했었지만, 대부분 교육에 대한 금액 지원뿐이였다. 금액을 지원해주는 것만으로 감지덕지라 생각했었는데 문제가 있었으니... 금액 지원에 대한 제약사항이 너무나도 터무니 없어 포기했다. 회사 내부 규정이라 언급은 안하겠다. 

 

지난 챕터의 커리어의 주인이 되라는 말이 생각난다. 나는 회사다니던 당시에 개인시간에 따로 스터디를 찾아가거나 했어야했다.

하지만 당시에 출퇴근 왕복 4시간으로 출근하기 위해 집에서 새벽 6시에 나가야했고 집에오면 보통 저녁 9시 정도가 일상이였다. 집은 단순히 잠만자러 가는곳이였으니, 시간이 없다는 핑계로 알아보지도 않았다.