성공적으로 새로운 기술을 도입하는 방법

개발자들은 업무를 진행하면서 퍼포먼스를 올릴수 있는 방법에 대해서 끊임없이 고민하고 연구한다. 몇 줄의 코드를 수정하거나 적절한 알고리즘을 도입하는 것으로도 유의미한 변화를 만들어 낼 수도 있지만, 때에 따라서는 새로운 기술을 도입해야하는 경우도 있다. 간단하게는 신규 라이브러리의 적용 부터, 크게는 자동화 프로세스의 구축이나 아키텍쳐의 변경까지, 그 종류는 매우 다양하다.

그러나 이를 성공적으로 수행하기 위해서는 단순히 기술 적용을 위한 난이도만 고려해서는 안된다. 혹시 회사에서 새로운 것을 시도해보려고 하는데 번번히 실패한 경험이 있지 않은가? 나는 꼭 필요한 것이라고 생각하고 시도했는데 생각보다 잘 풀리지 않아 포기한 경험이 있는가? 그렇다면 다음과 같이 성공적으로 새로운 기술을 도입하는 몇 가지 절차와 방법에 대해 주목해보자.

꼭 필요한 기술인지 다시 확인해보자

규모가 큰 회사일수록 신규로 도입되는 기술에 대한 검증이나 리스크 관리가 철저하게 진행되지만, 인원이 적은 소규모 기업이나 스타트업에서는 몇명의 의사 결정이 기술적인 방향성을 좌우하게 된다. 따라서 한가지 장점에만 매몰되어 잘못된 선택을 하게 된다면 많은 체력 소모와 자원 낭비가 뒤따르게 되므로 신중하게 결정하도록 해야한다.

많은 개발자들이 컨퍼런스나 기술 블로그등으로 새로운 기술을 접했을 때 장점만 보고 도입을 결정하는 실수를 범한다. 기술 도입을 통해 현재 맞닥뜨리고 있는 많은 문제들이 마법처럼 해결될것이라고 생각한다. 그러나 프로젝트에 기술적 환경이 뒷받침되지 않아 적용 불가능하거나, 막상 적용해 보니 검토가 충분치 않아 장점보다 단점이 많은 상황이 되어버릴 수도 있다. 또한 해당 기술을 도입하는데 리소스 낭비가 너무 심해 정작 중요한 작업들을 처리할수 없게 되어 버린다. 따라서 아래의 항목들을 확인해보고 다시 한번 필요한 기술인지 검증해 볼 필요가 있다.

1. 기술을 도입할수 있는 환경이 구축되었는지
2. 해당 기술의 장/단점은 무엇인지, 어떤 문제들을 해결할수 있는지
3. 해당 기술을 도입하는것 보다 우선 순위가 더 높은 작업은 없는지
4. 기술 도입 이후 유지보수/추가 적인 인력의 소모가 없는지

토이 프로젝트로 검증하자

새로운 기술의 도입은 언제나 보수적으로 접근해야한다. 검토가 충분치 않은 기술은 마치 검역이 안된 외래종과 같아서 기존 생태계를 교란시키는 악영향을 미칠수 있다.

이러한 ‘검역’의 절차를 대신할수 있는 것이 바로 토이 프로젝트이다. 대부분의 기술이 적용을 위한 훌륭한 문서들을 제공하고 있지만, 실제 적용 단계에서는 문서에 없는 문제들이 발생해서 우리들을 괴롭힌다. 이를 해결하기 위해서 적용을 목표로 하고 있는 코드와 유사한 토이 프로젝트를 생성하여 선행적으로 기술을 사용해 봐야한다. 이를 통해 장단점을 명확하게 하고, 현재 타겟 프로젝트의 구조 내에서 발생할수 있는 문제를 작은 단위로 체험할수 있게 된다. 또한 토이 프로젝트는 고려해야할 코드의 양이 적기 때문에 좀 더 빠르게 테스트해 볼 수 있으며, 이렇게 테스트한 코드는 다른 개발자들을 설득하거나 구조를 설명할 수 있는 훌륭한 샘플이 된다.

기술 도입의 공감을 얻자

기술을 적용하기 위해서는 ‘왜’ 라는 물음이 충족되어야한다. 다시 말해 왜 이 기술을 도입해야하며, 이로 인해 우리가 얻을수 있는 것들이 무엇인지 명확해야한다는 뜻이다. 만약 이것이 충족되지 않는다면 작업을 진행할수 없을 뿐더러, 시작하게 되더라도 적절한 지원을 받지 못하고 많은 리스크를 떠앉게 된다.

공감을 얻어야할 대상은 크게 두 부류로 나뉘는데 첫번째는 같은 개발자 동료들이다. ‘이미 중요한 이슈들이 많은데’, ‘굳이 저 기술을 도입해야해?’ 등 부정적인 의견이 지배적인 상황에서는 효과적으로 작업을 진행할 수 없다. 따라서 앞서 언급한 검토 단계에서 정리된 장단점과 파급 효과를 정리해 동료들에게 공유하자. 이 단계에서 의견 교환은 단방향이 아니라 양방향으로 진행되어야한다. 중요한점은 설득이 아닌 논의의 자리라는 것이다. 이렇게 수렴한 동료 의견 중, 그들이 우려하는 부분을 끝내 해결하지 못한다면 기술을 재검토하거나 기술 방향성을 바꿔볼 필요가 있다. 이를 모두가 수긍할 수 없더라도 논의를 통해 장기적인 방향성을 확인할수 있다면 다음에는 더 적절한 기술을 찾아낼수도 있다.만약 이 과정이 훌륭하게 진행되어 다수의 동의와 공감을 얻어냈을 경우 기술 도입은 일사천리로 진행될 것이다.

두번째는, 경영진이나 PM 등의 비개발자 직군이다. 만약 기술 도입의 범위가 작다면 비개발자 직군에게 공감을 얻을 필요 없이 기능 조직 내에서 빠르게 의사 결정을 해서 업무를 진행하면 된다. 그러나 범위와 리소스가 큰 작업의 경우 일정을 관리하는 비개발자 직군에게 협조를 요청해야한다. 당연한 이야기지만 기술 도입에 따른 장단점을 개발자적인 시각에서만 풀어내면 비개발자 직군은 필요성에 대해 공감하지 않을것이다. 그보다는 회사의 입장에서, 다시 말해 비즈니스 관점에서 생각해보는것이 경영진을 설득하는데 더 효과적이다. 예를 들어, 아키텍쳐를 변경해서 코드 간의 종속성과 빌드 시간을 줄이고 도메인 로직의 응집력을 높이고 싶다는 의견은 경영진이나 비개발자의 시각에서 전혀 와닿지 않을 것이다. 그보다는 신기술 도입을 통해 안정성과 피쳐의 개발 속도가 높아지고 결과적으로 빠른 개발 주기를 통해 시장을 선점하거나 많은 기획을 검증해볼수 있다는 설명이 이전의 내용들보다 효과적으로 작용할 수 있을것이다.

중요한것은 기술적인 근거가 중요하지 않다는 뜻이 아니라 설득하고 공감을 얻어낼 대상이 누군가에 따라서 전략을 다르게 취해야한다는 것이다. 우리의 언어가 아닌 상대방의 언어로 변환하여 의견을 전달하는것이 이 단계의 핵심이다.

1. 동료 개발자들에게 공감을 얻어내자. 부정적인 의견이 있더라도 논의를 통해 긍정적인 방향성으로 유도해내자.
2. 비개발자 직군을 설득해야하는 경우, 비즈니스 적인 관점에서도 기술 도입을 해야하는 이유를 찾아보자

분할 정복하자

적용 범위가 큰 경우 대다수의 개발자들은 범위내 변경사항을 최소화 시키면서 기술을 적용시키고 싶어한다. 예를 들어, 대규모 레거시를 걷어내고 새로운 아키텍쳐를 적용하는 작업을 가정해보자. 개발자에게 이상적인 작업 환경은 새로운 프로젝트를 생성하여 기존 프로젝트를 새 아키텍쳐에 맞게 이관하는 것이다.

그러나 현실적으로 코드의 양이 너무나도 많을것이므로 이렇게 할수도 없을뿐더러, 진행한다고 해도 작업 기간 동안에는 정상적으로 서비스 운영이 어렵다. 회사 측면에서는 정상적으로 서비스를 운영하면서 기술을 도입하길 원한다. 비유하자면 우리는 날아가는 로켓위에 올라타 로켓의 부품을 교체하면서 목표까지 안정적으로 도달하는 방법을 연구해야한다.

가장 심플한 방법은 작은 단위 부터 적용해 나가는 것이다. 모든 기술을 한번에 적용하려는 욕심을 버리고 가장 작은 단위부터 수정을 시작한다. 예를 들어 e-커머스 앱을 모듈화 한다면 가입-결제-구매-유저 등의 패키지를 순차적으로 적용해나가는 것이다. 기간과 그에 따른 마일스톤을 정해 하나씩 처리해나간다면 결국 초기에 설정한 목표에 도달할수 있을것이다.

또한, 이렇게 큰 범위의 수정 사항이 적용되고 있는 동안에는 다른 수정사항이나 기술 도입을 최대한 지양한다. 하나의 기술이 완전히 모든 코드에 적용된 다음 새로운 기술을 도입해야한다. 그렇지 않으면 진행 상황 체크가 어려우며 각 파일 마다 코드 작성 방식이 다른 혼란한 결과가 초래될 것이다.

다시 한번 강조하지만, 당장 레거시를 걷어내고 새로운 기술이 적용된 안락한 코드 위에서 빠르게 개발하는 것을 원하더라도, 계획대로 차근차근 적용해나가는것이 중요하다. 때로는 멀리가는 것처럼 보여도 그 길이 지름길 일 수 있다.

결과를 공유하자

성공적으로 기술을 도입했다면, 이에 그치지 않고 팀원들에게 결과를 공유하는것이 좋다. 이 때, 기술 도입 전/후의 퍼포먼스 상승 효과나 개선에 대한 객관적인 수치들이 포함되면 더욱 효과적이다.

이를 통해 긍정적인 평가를 받을 수 있으며, 다음 작업에서도 선례가 만들어져 좀 더 원활하게 업무를 진행할수 있는 선순환이 만들어진다. 열심히 작업을 했는데 그 결과를 자축하며 묻어버리기에는 너무 아깝다. 따라서 본인이 만들어 낸 결과를 적극적으로 공유하도록 하자.

결론

모든 내용들이 너무 기본적인 내용들이라 시시하다고 생각할수도 있다. 그러나 많은 개발자들이 이 내용들을 무시하고 오로지 본인이 해결하고 싶은 부분에만 집중하기 때문에, 신기술 도입이 번번히 실패로 끝나는 경우를 보았다.

물론, 각 회사의 상황에 따라 기술 도입에 대한 난이도가 천차만별이겠지만 적어도 챙길수 있는 부분은 잘 준비해서 전략적으로 움직이는게 중요하다고 생각한다. 따라서, 개인적 경험에 기반하여 쓴 이 글이 많은 개발자들에게 조금이나마 도움이 될 수 있었으면 좋겠다.