[개발자 고민 상담소] 팀에 새로운 기술 적용을 제안하고 싶을 때, 생각해볼 점들

오늘의 고민

이 업계에서는 새로운 기술의 등장, 기존의 것이 버전 업데이트를 통해 크게 달라지는 건 특별한 일이 아닙니다. 우리는 늘 그런 상황에 처해왔고, 앞으로도 계속 처할 거예요. 개발자라면 누구나 알고 있는 사실이지만, 때때로는 잦은 변화에 매번 대처해야 한다는 사실이 힘들게 느껴지기도 합니다. 근데 뭐 어쩌겠어요

새로운 기술이 한 번 대두되면 우리는 종종 혼란에 빠집니다. 컨퍼런스에서 갑자기 그 기술에 대한 주제가 언급되기 시작하고, 경험이 풍부한 선배 개발자들이 소셜 미디어에 그 기술에 대한 영문 아티클을 공유하기 시작해요. 그 글에 달린 코멘트들이 긍정적인 방향으로 달리기 시작하면, 아 정말 이게 뜨려나보다. 이런 생각이 들기도 합니다. 그리고 해당 기술 공식 사이트에 들어가 봅니다. 모든 문제를 해결해 줄 것처럼 묘사되어 있군요. 흠... 그런데 우리 팀에선 그런 기술에 대해 관심이 하나도 없는 것 같습니다.

오늘은 이렇게 새로운 기술들이 자주 등장하고, 각각 나름대로 이전의 기술의 부족함을 보완했으니 앞으로 이걸 쓰는 게 좋다고 외치는 상황 속에서 혼란스러워하는 한 개발자의 고민을 가져왔습니다.

한 2년 차 프론트엔드 개발자의 고민
“최근에 참여했던 어떤 교육에서 React와 Redux를 배웠는데, 여러모로 저희 팀에 도입하면 좋을 것 같아서 제안을 해보고 싶습니다. 그런데 왠지 팀 분위기가 새로운걸 배우자, 도입해보자고 얘기했을 때 긍정적으로 반응할 것 같지가 않아서 말이 잘 안 나오네요. 답답한데, 어떻게 해야 React를 써보자는 이야기를 잘 전할 수 있을까요? 설득 포인트를 못 잡겠어요.”

팀에 새로운 기술을 써보자고 제안하고 싶을 때 어떻게 하는 게 좋을까요? 어떻게 해야 긍정적인 반응을 이끌 수 있을지, 아니 그 이전에 새로운 기술을 도입하는 것에 대해 어떤 생각을 해보면 좋을지 총 3명의 실무 개발자들의 의견을 들어봤습니다.

간단 요약 TL;DR

1. 스스로 결과물을 만들어 어떤 부분이 개선될 수 있는지 증명해보자. 내 생각, 어디서 들은 말, 유명한 사람의 말을 인용하는 것이 아니라 정말 우리 팀의 상황에 맞게 작은 부분에나마 테스트를 해보자.

2. 적용 과정에서 생길 수 있는 다양한 상황을 예측해보자. 장점도 당연히 있겠지만, 모두가 그 기술을 배우느라 소요될 기간과 이로 인해 프로젝트 기간이 늘어날 수도 있는 점, 생산성이 떨어질 수 있는 점 등 다양한 측면을 놓고 생각해봐야 한다.

3. 평소 동료들에게 나는 어떤 개발자였는가. 동료들을 설득하려면, 결국 평소에 쌓아왔던 신뢰관계 역시 무척 중요하다.

 

첫 번째 조언 "생산성 하락 가능성을 생각해보자"

by 이연복, K사 백엔드 개발자

새로운 것을 시도한다는 것은 그게 어떤 것이건 기본적으로 저항감이 생기기 마련입니다. 기존에 쓰지 않던 기술을 도입하는 상황에서, 그 팀의 역량은 제일 잘하는 팀원 기준이 아닌 가장 더딘 팀원 기준으로 봐야 하거든요. 예컨대 코틀린을 예로 들어볼게요. 기존의 자바 프로젝트를 코틀린으로 바꿔야 하는 상황인데, 저는 코틀린을 잘 알고 있고 다른 팀원들은 모른다고 가정해봅시다. 그렇다면 코틀린 자체가 아무리 편리한 점이 있다고 해도 초반 생산성이 얼마나 높아질 수 있을까요? 다른 팀원들도 학습을 진행하고, 실제로 코드에 적용하기까지 걸리는 시간이 필요할 테니 프로젝트 기간이 전반적으로 늘어날 가능성이 높죠.

팀에 한 명이라도 해당 기술에 능통한 사람이 있다면 리드를 하면 되니 시행착오를 줄일 수 있고 속도를 좀 더 빠르게 할 순 있겠지만, 다들 비슷비슷한 팀이라면 사실 새로운 기술을 도입한다는 건 조심스럽게 고려할 일인 것 같습니다. 한 달짜리 프로젝트가 두 달이 되고, 예상하지 못한 문제가 생길 테니까요. 물론 당연히 그 과정에서 성장하겠지만 팀 관리자 입장에서는 힘든 결정일 거예요. 이런 부분도 한 번 생각해보면 좋을 것 같아요.

정말 하고 싶다면, 작은 부분에서부터 증명해보기

팀마다 상황은 다르기에, 참고만 해주세요. 우선 제 생각에는 기존에 잘 돌아가고 있는 서비스가 있고 큰 문제가 없는데, 더 나은 방향(better)을 위해 새로운 기술을 도입한다는 일은... 잘 일어나진 않을 것 같아요. 굉장한 용기가 필요한 일이거든요. '더 좋아질 수 있기 때문에' 새로운 것을 도입하자는 논리는 팀원들을 설득하기에도 어려울 거고요. 이런 상황에서는 이걸 바꾸려고 하는 것이 내 욕심이 아닐까? 한 번 곰곰이 생각해보는 게 필요할 것 같아요.

그럼에도 불구하고 계속 마음이 그 기술에 간다면, 팀을 설득하는 과정이 험난할 거라는 걸 생각하셔야 하고 그 과정을 헤쳐나가기 위해선 내가 말로만, 또는 유명한 사람들의 말을 인용하는 게 아니라 증명을 하는 게 좋겠어요. POC(Proof of Concept)를 해도 좋고요. 내가 언제까지 POC를 해서, 기존의 것이 얼마만큼 좋아질 수 있는지 증명을 해보겠다. 그 후에 얘기하자... 뭐 그런 식으로요.

스터디 그룹을 조성해서 발표를 하는 수준을 넘어서 실제 결과물을 보여줘야 해요. 사이즈는 작아도 상관없어요. 기존에 운영하던 서비스 위에 새로운 걸 얹고 싶다면 최소한 POC를 진행해서 그 결과물을 갖고 팀원들과 심도 있는 논의를 하는 게 훨씬 나을 거예요. 결론적으로 도입이 되던 안되던, 스스로를 위해서도 그게 좋겠죠.

 

두 번째 조언 "내 판단이, 우리 팀 모두에게 최선일까"

by 홉스, 현 카카오 웹 개발자

주니어일 때는 이것저것 관심을 갖고 시도해보려는 태도는 중요하다고 생각해요. 모든 키워드를 다 듣고, 흐름을 이해하고, 더 이상 새로운 키워드가 잘 보이지 않을 만큼 요새 업계에서 회자되는 키워드를 계속 인식하는 건 필요하죠. 하지만 그렇게 알게 된 것들만을 토대로 팀에 새로운 기술 도입을 제안한다는 건 힘든 일일 것 같아요.

본인이 제안을 하고 싶다면, 일단 시간이 필요해요. 스터디를 하자고 하거나, 내가 공부한 것들을 정리해서 공유나 발표를 하거나. 기회가 된다면 회의 시간에 넌지시 계속 흘린다던가... 그렇게 해당 기술에 대한 인지를 시키고, 긍정적인 인상을 쌓은 후에 도입에 대한 제안을 할 수 있다고 생각해요. 새로운 기술에 대해서는 그게 쉽건, 어렵건 거부감이 들게 마련이거든요. 만약 기술 스택에 대한 결정을 스스로 내릴 수 있는 위치라면 얘기가 다르겠지만, 주니어라면 더더욱 시간이 필요하죠. 왜냐면 경험이 부족할 땐 내 판단이 우리 팀에 정말 (현재로서의) 최선인지 알 수 없거든요.

타입스크립트를 예로 들어볼게요. 어려워서 그렇지, 사실은 코드 베이스가 커질수록 도입할 필요성이 점점 느껴지긴 하거든요. 하지만 내가 하고 싶다고, 필요한 것 같다고 느끼는 것과 실제 팀에 적용하는 건 다른 일이죠. 같은걸 개발한다고 해도 타입스크립트를 쓰면 초반에 시간이 더 걸리는게 맞고, 그런데 프로젝트는 항상 기간 제한이 있고, 이런 상황에서 나 빼고 다른 팀원들은 타입스크립트를 모두 새로 배워야 한다면? 설득하기가 어렵죠.

스스로 정말 너무 그 기술을 써보고 싶다면 조금씩 떼어서 해보겠다고 제안하는 것도 좋아요. 일부 기능만 시도해보던가, 운영 툴에 한 번 적용해본다던가 하는 수준의 제안은 할 수 있겠죠. 하지만 다른 팀원들 입장에서 생뚱맞게 보이는 기술을 갑자기 하겠다고 주장하면 난감할 테니, 아까 말한 대로 시간을 두고 지속 언급을 하거나 공유를 해두는 게 좋을 거라고 봐요.

건드리기보다, 파내려 가며 감각을 기르길

만약 컨퍼런스나 각종 미디어에서 여러 개의 기술이 언급되는데 내가 뭘 하는 게 좋을지 혼란스럽다면 그때에 가장 사용자가 많은, 메이저한 기술 하나만 잡고 깊게 파보는 게 중요한 것 같아요. 저는 처음 커리어를 시작했을 때 한 웹 프레임워크를 소스 레벨까지 뜯어봐야 하는 시간들이 있었는데 그게 결국 전체 커리어에 도움이 많이 되었어요. 그 기술은 사실 지금은 안 쓰는데, 쓰건 안 쓰건 상관없이 하나를 깊게 배워두니 새로운 것을 배울 때도 금세 비교가 되고 어떤 점이 개선되었는지 보였거든요.

이것저것 알아두는 것은 좋지만 조금씩 건드리기만 하는 것은 지양하고, 하나를 잡고 깊게 파 보세요. 소스 레벨까지 뜯어보세요. 그 기술이 이야기하는 철학까지 깊이 있게 이해해보려고 노력해보세요. 내가 그 철학에 동의하는가? 는 중요하지 않아요. 이렇게 깊게 하나를 이해해보면 다른 것을 배울 때에도 큰 도움이 됩니다.

그리고 새로운 기술이 나왔을 때, 그 기술이 앞으로도 계속 뜰지 아니면 금세 잊힐지 빠르게 판단하는 능력도 중요해요. 저 같은 경우는 우선 플러그인을 만들어봅니다. 그 기술이 문서화가 잘 되어있고, 구조화가 잘 되어있다면 만들기가 쉽겠죠. 예컨대 Vue.js 가 처음 등장했을 때 제가 이건 뜨겠구나! 싶었던 게 문서화가 너무 잘 되어있었기 때문이에요. 그런 기술이라면 자연스럽게 유저들이 많아지고 생태계가 금세 성장할 거고요. 생태계가 빠르게 생성되는 기술 치고 빨리 망하는 일은 없을 거예요. 이런 감각을 익히는 게 좋아요.

 

세 번째 조언 "결국, 신뢰관계가 중요"

by 강관우, 현 카카오 웹 개발자

일단 제안을 하는 방법에 대해서 생각해볼게요. 당연히 뜬금없이 발제하는 것보다는 점진적으로 팀원들이 조금씩 인지할 수 있도록 바닥에 깔아 두는 게 중요하겠죠. 관심 있는 게 생겼다고 바로 리서치를 한 뒤 그 결과를 갖고 이게 좋다, 해보자... 이러는 게 아니라 스터디 그룹이라도 만들어 보는 거예요.

스터디를 한 2주 한다고 가정해보면, 매일매일 조금씩이라도 스터디원들과 그 기술에 대해 얘기할 수 있잖아요. 어제 이런 시도를 해봤는데 좋더라, 이런 부분은 우리 시스템의 이런 문제를 해결하는 데에 도움이 될 것 같다 이런 논의를 한다던가. 이렇게 공부하면서 쌓아나간 근거가 있다면 설득의 배경이 될 거고, 그걸 바탕으로 제안해볼 수 있겠죠.

설득의 기본, 신뢰

그런데 이런 학습 외에 중요한 것이 있는데, 평소 쌓아온 동료들과의 신뢰관계라고 생각해요. 아까 말한 스터디 그룹도 사실 동료들과의 관계가 없다면 만들 수가 없겠죠. 그러니 내가 평소 신임을 얻어왔고, 기술적인 부분에서도 전문성을 인정받고 있는 사람인지를 생각해보는 것도 중요하다고 생각해요. 근데 결국 이 모든 건 시간이 필요한 일이고, 우리 팀에 이 기술이 적당한지를 판단하는 것도 경험이 없으면 힘든 일이에요. 그래서 조급하게 생각하기보다는 시간을 갖고 동료들에게 선한 영향력을 끼쳐나가는 게 기본이라고 생각해요.

신기술을 도입하자는 논리 자체는 좋아요. 당연히 그 기술도 기존의 불편함을 개선하기 위해서 나온 부분이 있을 테니까요. 그런데 결국 동료들을 설득하지 못한다면 '그걸 지금 해야 하는가?', '그런 리소스가 있는가?' 이런 질문들과 바로 부딪히게 되죠. 논리적으로는 고개를 끄덕일 수 있어도, 마음이 설득되지 않으면 굳이 그걸 하지 않아도 될 이유를 더 생각하게 되는 것 같아요. 아무리 근거가 충분하더라도 '그래, 한 번 해보자'를 이끌어낼 수 있는 건 결국 평소 그 제안하는 사람이 어떤 동료였는가가 중요한 것 같아요.

---

마무리

개발자가 늘 새로운 기술에 대해 관심을 갖고 동향을 읽어나가는 것도 좋지만, 그것을 실제로 도입할 때에는 조직 측면에서 바라보는 시각도 필요한 것 같군요!

그리고 결국 이 모든 걸 판단하고, 제안하려면 절대적으로 경험이 중요한 것 같아요. 즉, 커리어를 시작한 지 얼마 안 되었을 때는 그 기술이 정말 우리 팀이 마주한 상황에 적합할지, 그걸 적용함으로써 어떤 일이 벌어질 수 있을지 혼자 다양한 수를 놓고 보기 어렵다는 의미죠. 따라서 앞으로 그런 고민이 들 때는 이런 포인트에 대해 생각해보면 어떨까요?

• 나의 제안은 실제로 우리 팀이 마주한 문제 해결을 위한 것인가, 또는 '더 나아질 수도 있는 가능성'을 위한 것인가?
• 도입함과 동시에 현실적인 어려움은 어떤 것들이 있을까? (학습에 필요한 기간, 일시적 생산성 저하, 프로젝트 기간 지연,...)
• 나는 팀원들에게 이 기술이 가져다줄 생산성 향상에 대해 정확한 근거와 산출물을 토대로 이야기할 수 있을까?
• 기존 프로젝트에 영향을 주지 않는 범위 내에서 도입해볼 수 있는 방법이 있을까? (신규 프로젝트 / 기능만 새로운 기술 기반으로 하는 것을 고려한다거나)

그리고 결국 그 기저에는 팀 내에서 내가 좋은 신뢰관계를 쌓아왔는지도 생각해보는 게 좋겠네요. 결국 사람들의 마음이 움직이지 않으면 모든 과정이 더뎌질 테니까요. 결국 사람 문제

오늘의 고민상담소 내용이 도움이 되셨길 바라며, 또 유익한 내용으로 금방 다시 찾아오겠습니다.

'개발자 고민상담소'는 현실적인 고민에 부딪혀있는 개발자분들께 도움이 되고자 시작한 연재 시리즈입니다. 현업 개발자들의 솔직한, 또 각자 다른 의견들을 한 데 모아 들려드림으로써, 여러분의 고민이 좀 더 나은 방향으로 나아갈 수 있도록 도와드리고자 합니다. >> 프로그래머스 방문하기 <<