팀에 새로운 도구를 도입하고 싶다.

개발 생태계는 빠르게 변화하고 있고, 10년 이상 ‘트렌드’로 자리 잡던 도구와 방식이 한순간에 레거시가 되기도 한다. 개발자는 늘 새로운 것에 끌리기 마련이고 회사에서 새 프로젝트를 기존과 다른 방식으로 진행해보고 싶다는 생각은 누구나 한 번쯤 가져봤을 것이다. 새로운 것에 대한 도입은 팀원들과 협의가 필요하고, 이 과정이 순조롭게 진행될 수도 있고 긴 논의가 필요할 수도 있다.

이 글은 누구 한쪽의 편을 들기 위한 글도 아니고 최신 트렌드의 도구를 도입해야 한다는 글도 아니다. 팀의 프로젝트를 만들어가는 개발자가 새로운 것을 도입하는 데 겪을 수 있는 약간의 갈등과 그 갈등의 의미에 대해 생각해보며 작성한 글이다.

먼저, 나의 주장을 돌아보자

팀에 새로운 도구 도입을 주장하기 전, 내 주장이 정말 우리 팀의 고통을 해결하기 위한 것인지 되돌아볼 필요가 있다. 혹시라도 단순히 새로운 도구가 궁금한 것이라면 이 도구에 대한 이야기는 ‘도입에 대한 논의’가 아닌 ‘공유’ 정도에 머물러도 괜찮다. 문제 해결을 위한 수단이 아니라 호기심에 끌리는 것이었다면 아직 팀에 도입을 주장하기엔 위험하지 않을까?

생각이 다르기 때문에 한 팀이다

호기심 해결이 아닌 문제 해결을 위한 주장이라는 확신을 얻고, “A를 도입하면 현재 우리가 겪고 있는 문제1, 2, 3을 해결할 수 있고 Test를 작성하기도 쉬워지고 그 외에 여러 장점이 있습니다.”라고 소개한다.

팀이 크면 클수록, 모두가 즉시 이 문장에 대해 공감하지 못할 확률이 높다.

당연한 말이지만, 사람마다 생각하는 바가 다르기 때문이다. 누군가는 나의 주장처럼 ‘A로 얻을 수 있는 장점’에 초점을 맞출 수도 있지만, 누군가는 ‘A에 대한 학습비용 대비 얻는 장점이 크지 않다.‘라고 생각하거나 ‘A를 도입하면 생길 수 있는 장점이 있지만, 단점 1, 2가 생기는 문제’에 대해 의문을 제기할 수 있다.

나는 관심을 가져온 구조 혹은 라이브러리이고 오랜 시간 프로덕트 도입을 고민해왔지만, 이는 나 혼자 했던 고민이다. 당연히 러닝커브 대비 장점을 고려해야 하고, 새로운 것을 도입했을 때의 단점도 예민하게 생각해봐야 한다.

이는 매우 당연한 과정이고 잘 논의하여 하나의 타협점을 찾아가는 팀이 좋은 팀이라고 생각한다.

100% 완벽한 도구는 없다. 내가 주장하는 도구는 이 단점과 러닝커브 대비 우리 팀의 문제를 해결할 수 있고 장기적 관점에서 도움이 될 것이라는 확신이 있어야 한다.

어떤 방법이 필요할까

새로운 것에는 시간이 필요하다. 페어 코딩이 필요할 수도 있고, 잘 설명된 문서나 발표자료 같은 것들이 필요할 수도 있다. 내 의견을 좀 더 어필하고 싶다면 가장 효과적인 전략이 무엇일지 고민하는 시간도 필요하다.

맹목적으로 반대하는 사람은 없다. 도구가 익숙하지 않거나, 익숙하게 만들 만큼 가치 있다는 것에 공감하지 못하거나, 그냥 어려울 수 있다. 이미 기존 방법으로 문제를 잘 해결하고 있다고 믿고 있다면, 내가 제안하는 도구는 ‘새롭지만 러닝커브’일 수 있다. 그 어떤 이유에서라도 그 이유에 ‘공감’해야 하고 상대방을 동료로서 이해하며 ‘설득’해야 한다.

이런 ‘설득’과정들을 통해서 ‘어느 정도 알고 있다’라고 생각한 내 지식과 생각에 빈틈이 없었는지 확인해볼 수 있다.

공감도 하고 설득도 해봤는데 잘 받아들여지지 않는다면 어떻게 해야할까? 내 의견이 타당했는지 한번 돌아보고 그럼에도 바뀌지 않는다면 이제 아군이 필요할 때이다.

모든 걸 한 번에 바꾸려 했다가는 반란이 일어날 것이다.
반란이 일어나면 어렵게 얻은 신뢰를 잃고 모든 노력이 수포가 된다.
감당할 수 있는 변화의 속도는 팀에 따라 다르다.
모두에게 '완벽한 변화'를 강요하지 마라. '아군'을 모집해서 주장의 타당성을 인정받는 게 중요하다."

- 심플 소프트웨어 Chapter 18~19 내용 中-

내 의견에 찬성한다고 해서 ‘아군’이고 그렇지 않다고 해서 ‘적군’이라는 것이 아니다. 모두의 동의를 얻으려는 방법을 고수하다 보면 내가 얻고자 했던 ‘개선’에 초점을 맞추는 본질이 쉽게 흐려질 수 있다. 아군을 얻고, 그 아군이 나의 주장을 지지해주고 그 과정을 통해 내가 커버할 수 없는 부분을 아군이 도와주는 형태가 바람직한 상황이다. 물론 이 과정에서 실제 내 의견이 타당하지 않다고 결론 날 수도 있다.

내 의견이 꼭 받아들여져야 한다는 고집은 내려두고 ‘본질’에 집중하는 것이 제일 중요하다.

결과에 대한 회고

팀에 새로운 것에 관해 주장하고 도입하는 과정이 끝났다면 기술과 프로세스에 대한 회고가 필요하다.

기술적 회고

모든 의사결정은 돌아보면 후회되는 부분이 생길 수 있다. 당장 되돌아보면 그때의 결정이 최선일 수 있지만, 지나고 나면 그렇지 않을 수 있다. 예를 들어, 상태를 별도로 관리하는 것을 예전에는 ‘View와 Data를 분리하고 비즈니스 로직을 안전하게 설계하는 것’이라고 생각했지만, 지나서 생각해보면 ‘Single source of truth’ 컨셉과 맞지 않는다는 생각이 들 수 있다.

새로운 경험과 환경을 마주하면서 생각은 확장되고 관점은 변한다. 미래의 내가 과거의 결정들을 어떻게 생각하는지 한 번씩 되돌아보는 경험이 또 다른 성장이 될 수 있다고 생각한다. 치열한 논의를 통해 도입했던 도구나 방식이 미래에 돌아봤을 때 적절하지 않다고 생각된다면 그 내용을 팀에 공유하는 것으로 ‘함께 성장’을 이룰 수 있지 않을까?

프로세스 회고

반대하는 팀원의 의견을 듣고 조율하는 과정에서 내가 선택한 전략이 최선이었는지, ‘더 좋은 것’에 대한 추구가 아닌 ‘고집’은 아니었는지 되돌아보자. 팀이 성장하고 문제를 더 나은 방법으로 해결하는 것도 중요하지만 그것보다 중요한 것은 팀원 간에 신뢰를 잃지 않는 것이라고 생각한다.

마무리

팀 차원에서 새로운 것을 도입하기는 쉽지 않은 일이다. 사람마다 중요하게 생각하는 가치는 다르고 이 ‘다름’은 ‘틀림’이 아니다. 팀의 방향에 대해 논의하고 새로운 것에 대해 합의하는 과정에서 ‘같이 성장’할 수 있다고 생각한다.