구름 COMMIT이 어느덧 5회차를 맞이했습니다. 2023년 2월 COMMIT은 Purple IO CTO 김충섭 님이 성공적으로 신기술을 도입하는 법을 들려주셨어요. 사내에 신기술 도입을 검토하고 있거나 도입에 실패한 아픔이 있는 분, 신기술 도입 과정이 궁금한 분들을 위해 준비했습니다.
새로운 기술을 도입하는 게 혁신이 될 수 있지만 언제나 성공하는 건 아니에요. 어떤 점을 주의해야 할지 살펴보겠습니다.
🎤 이 아티클은 김충섭 님의 2월 COMMIT 세미나 내용을 바탕으로 재구성되었습니다.
개발자 외길 인생
저는 대학교 졸업 후 병역 특례를 마치고 퍼플웍스 창업 멤버로 합류했습니다. 지금까지 17년 정도 개발을 하고 있어요. 그동안 새로운 기술을 공부하고 도입하면서 실패도 했었고요.
제 학습 단계를 보면 처음 기술을 배우는 단계가 있고, 어느 정도 기술을 익히고 나면 새로운 기술을 도입하게 됩니다. 경험이 부족하다 보니 실패를 거듭한 다음부터는 적정기술을 고민하게 됐죠.
오늘은 새로운 기술을 도입하고 실패했던 이야기를 해볼게요.
FOMO
FOMO(Fear Of Missing Out)는 비트코인이 등장했을 때 처음 접했던 용어인데요. 당시 동료분이 1만 원을 주고 샀는데 다음 날 10만 원이 됐다고 하니 저도 사야 할 것 같더라고요. 최근에는 ‘본디(Bondee)’라는 앱이 뜨고 있죠. 트위터 팔로워분들이 친구 추가하자고 많이 올리시더라고요.
FOMO는 흐름을 놓치거나 소외될까봐 두려워하는 심리를 뜻합니다. 사실 비트코인을 사거나 본디를 이용할 필요는 없는데 괜히 좋은 기회를 놓치는 것 같은 느낌이 들죠.
개발도 비슷합니다. 이런 말 들어보신 적 있을 거예요. “이번에 발표한 건데 Node.js랑 호환되면서 응답 속도는 100배 빠르고 2023 신기술 TOP 10에 든 그거 모르세요?” 기술 공부를 열심히 해서 취업했는데 또 다른 신기술을 배워야 할 것 같은 느낌이 듭니다. 사실 Node.js를 잘 쓰면 되는데 자꾸 Node.js가 끝났다고 하니 휘둘리게 되죠.
개발자와 신기술
신기술은 끊임없이 쏟아집니다. 트위터, 페이스북, 유튜브 등을 보면 좋다고 하는 기술이 넘쳐나요. DEVIEW, if kakao, AWS 등 콘퍼런스에서도 새로운 기술이 계속 나오고요. 오늘 짠 코드도 내일이면 레거시가 되니 새로운 기술이 나올 때마다 공부해야 하는 압박감에 시달립니다.
그렇다고 새로운 기술을 무작정 도입할 수는 없습니다. 기술을 도입할 때 어떤 점을 검토하면 좋을지 정리해볼게요.
1. 신기술을 도입했을 때 리스크보다 이점이 큰가
2. 많이 사용하고 있는 기술인가
→ 그렇지 않다면 내부 구조를 잘 이해하고 수습할 수 있는 인력이 있는가
3. 팀원들의 공감을 얻었는가
→ 개발 환경 / 개발 능력 / 조직 구조에 적합한가
4. 지속 가능한 기술인가
새로운 기술을 도입하려면 일단 배워야 합니다. 기술을 공부하는 동안 새로운 기능을 만들 수 없으니 그만큼 시간이 더 필요하죠. 도입하고 문제가 없다면 좋겠지만, 대부분 문제가 생기니 트러블슈팅에도 시간이 필요합니다. 이 모든 리스크를 감수하고 도입하는 게 맞을지 고민하는 게 첫 번째입니다.
그다음, 많이 사용하는 기술이어야 정보가 풍부하고 검색이 편합니다. 물론 정보가 부족해도 내부 구조를 파악해 수습할 자신이 있다면 도입할 수 있겠죠?
가장 중요한 건 팀원들의 공감을 얻는 단계입니다. 결국 기술은 팀원들과 함께 쓰는 거니까요. 우리 회사의 개발 환경, 팀원들의 개발 능력에 적합한지 체크해야 합니다.
도입하려는 기술이 지속 가능한지, 오버엔지니어링은 아닌지도 경계해야 해요. 불필요한 곳에 MSA(MicroService Architecture)와 쿠버네티스를 도입한다면 그게 오버엔지니어링입니다. 특히 쿠버네티스는 잘못 도입하면 유지보수가 어려워 더 많은 리소스를 투입해야 합니다.
또, AWS의 EKS(Elastic Kubernetes Service)도 매니지먼트 서비스라 사용하기 쉽다고 생각할 수 있는데 버전이 올라갈 때마다 설치하고 신경 쓸 게 많아요.
의외로 이런 고민을 하지 않고 그냥 써보고 싶어서 새로운 기술을 도입하는데요, 제가 도입에 실패했던 사례를 공유해볼게요.
신기술 도입 실패 사례 #1
Spring Roo
제가 한때 ‘Ruby on Rails’에 열광했었습니다. 당시에 블로그를 만들려면 일주일 정도 걸렸었는데, Ruby on Rails로는 15분 만에 만들 수 있었어요. console 기능과 CoC(Convention over Configuration)도 너무 좋아서 Ruby on Rails가 개발의 미래라고 생각했습니다. Spring MVC를 사용하는 우리 회사가 너무 올드하게 느껴지더라고요.
우연히 Spring 프로젝트 중 Ruby on Rails와 비슷한 Spring Roo를 보게 되었습니다. 이것저것 검색해보니 Spring Roo가 Spring에서 공식적으로 지원하는 프로젝트더라고요. Spring MVC에서 console이나 설정 부분만 바뀐 느낌이었고요. 도입했다가 실패하면 걷어내고 다시 Spring MVC를 쓰면 되겠다고 안일하게 생각했습니다. 결국 도입했고요. 어떻게 됐을까요?
정확히 한 달 뒤에 뒤집고 새로 만들었어요. Spring Roo를 도입해서 얻는 이점이 하나도 없었던 거죠. 우리 회사에는 이미 Spring MVC 전문가가 있는데 엉뚱한 기술을 갖고 온 거예요. 많이 사용하는 기술도 아니었고요. 팀원들에게도 물어보고 도입해야 했는데 Ruby on Rails에 빠진 나머지 혼자 저질렀던 겁니다. Ruby on Rails 팬인 저만의 자기만족이 일으킨 참사였어요.
신기술 도입 실패 사례 #2
Go 언어
Go 언어에 열광하던 시기였습니다. 한창 자바를 쓰고 있던 와중에 새로운 언어를 찾다가 Go를 발견했어요. 구글이 만들었고 문법도 간결하고 빠르더라고요. 비동기 작업도 편하고 컴파일 속도도 빨랐습니다. 마침 Go 책을 쓰신 분과 일하고 있기도 했고요.
배송조회 API를 만들어야 해서 고민 없이 Go를 선택했습니다. 역시나 이점이 없는 선택이었어요. 당시에 Go는 공식 패키지 매니저가 없어 패키지 관리도 어려웠고, id 지원도 부실했습니다. 팬심 때문에 열심히 했던 것 같아요.
Go를 써보신 분들은 아시겠지만 파싱하는 작업이나 JSON 데이터를 다루기도 약간 까다롭습니다. 근데 Node.js는 쉽잖아요. 지금 생각해 보면 Node.js로 만들었으면 오픈소스 기여도 많이 받아 잘나가는 API가 되지 않았을까 싶어요.
신기술 도입 실패 사례 #3
Micronaut
더 이상의 실패는 없을 줄 알았는데 또 한 번 겪게 됩니다. 이때는 AWS 람다(Lambda)에 열광했었습니다. 서버 관리가 싫었거든요. 저희는 Spring을 사용하고 있었기 때문에 Java로 Serverless에 배포해야 하는데 상당히 무거웠습니다. Lambda는 좋지만, Java를 사용하기는 어려운 환경이었어요.
검색하다가 Micronaut 프레임워크를 발견했죠. Micronaut은 Spring하고 똑같이 생겼는데 부팅 속도가 훨씬 빠르더라고요. 또 도입합니다.
도입하고 보니 Spring Boot랑 비슷한데 조금 달라서 문제였어요. 아예 다르면 코드를 다르게 작성할 텐데 비슷해서 Spring Boot처럼 작성했는데 작동하지 않더군요. Micronaut은 버전업이 빨라 사용법이 계속 바뀌는 것도 문제였어요. 사용자도 적었고요. 결론적으로 이점이 있지만 크지 않았습니다.
실패 사례를 공통적으로 살펴보면 기술 자체는 죄가 없었습니다. 제가 기술에 과하게 열광하면서 순간적으로 판단력이 흐려졌던 거죠. 무엇보다 많이 사용하지 않는 기술은 도입하면 안 되는데 그때는 안 되면 수습하면 된다는 생각으로 머릿속이 가득했습니다. 밤새서 처음부터 다시 만들면 되니까요. 팀을 고려하지도 않았던 거죠.
개발자의 성장
그리고 실수
처음 개발자가 되면 무엇을 모르는지 모릅니다. 그래서 열심히 배우다 보면 어느 정도 자신감이 붙는데 이때가 가장 위험한 상태입니다. 뭔가 아는 것 같지만 여전히 무엇을 모르는지 모르거든요.
몇 번 실수하다 보면 내 선택이 잘못됐다는 걸 깨닫고 좌절합니다. 경험이 없어서 예측을 못 하는 거죠. 여기서 좌절하지 않고 꾸준히 성장하면 소수의 사람만 깨달음에 도달합니다.
자신감이 넘치는 시기를 가장 조심하셔야 해요. 이때 무언가 도입하고 싶다는 욕망도 가장 강하거든요.
보통 기술 소개 페이지에는 좋은 내용밖에 없습니다. 최종적으로 기술을 도입하기로 할 땐 해당 기술의 단점은 무엇인지, 그 기술과 비슷한 다른 라이브러리는 무엇이 있는지 꼭 확인해야 해요.
팁을 하나 드릴게요. 저는 주로 ‘vs’와 ‘is bad’를 붙여서 검색합니다. 예를 들어 ‘redux react’에서 상태 관리를 도입하고 싶으면 ‘redux vs’, ‘redux is bad’를 검색해 블로거분들이 비교한 글을 찾아봐요.
기술은 여러 개의 장점보다 하나의 단점이 큰 문제를 일으킬 수 있습니다. 이 라이브러리만 도입하면 3명이 하던 일을 혼자 할 수 있을 것 같지만 아니거든요. 시간이 지나 보면 문제는 여전하고 3명이 하던 일을 5명이 수습할 수도 있습니다.
회사와 신기술
회사 입장에서 신기술 도입은 분명 장점이 있습니다. 브랜딩에 도움이 되기도 하거든요. 무엇보다 지금 사용하는 기술은 언젠가 레거시가 되니 항상 신기술 도입에 대비해야 합니다.
문제는 신기술을 다루는 개발자를 뽑기 어렵고, 많은 시행착오가 있다는 거예요. 회사 입장에서는 정해진 기간에 정해진 예산으로 기능을 만들어야 하는데 스터디와 수습이 필요한 신기술 자체가 리스크가 됩니다.
테슬라 홈페이지는 어떤 기술을 사용해 만들었을까요? 세계 최고의 테크 기술을 가지고 있는 테슬라 홈페이지는 왜인지 Java, Node.js, Python 중 하나로 백엔드를 만들었을 것 같고, 프론트엔드는 React나 Vue, Svelte 아니면 Astro를 썼을 것 같다고 생각했어요. 소스를 보니 PHP(drupal)에 jQuery로 만들어져 있었습니다. 오래된 기술이지만 그만큼 안정적이죠. 구매 페이지는 React로 만들어져 있었지만요. 테슬라 홈페이지를 본 순간, 이게 적정기술이란 생각이 들었습니다.
사실 정답은 없습니다. 회사마다 상황, 규모, 문화, 개발 능력이 다르기 때문이에요. 우리 회사의 상황에 맞게 도입하는 게 중요하다고 생각합니다.
새로운 기술을 도입하기로 했다면
먼저 같은 팀 동료나 기술을 잘 이해하고 있는 누군가에게 물어보세요. “제가 이런 이유로 저런 기술을 도입하려고 하는데 어떨까요?”라고요. 상대방을 설득하다 보면 자기 생각도 정리가 되거든요. 이야기하기 불편한 사람을 설득하는 것도 좋은 방법이에요. 감정적인 트러블이 있는 분이 아니라 기술적으로 치고받는 분이 있다면 그분과 이야기하는 거죠.
작은 조직에서는 물어볼 사람이 없을 수 있습니다. 그러면 SNS를 적극적으로 활용해 보세요. 트위터, 페이스북, OKKY 같은 커뮤니티에 질문하면 좋은 답변을 받을 수 있습니다.
러버덕 디버깅이라는 방법이 있는데요, 저희 회사는 재작년에 모든 직원에게 러버덕을 나눠드렸습니다. 러버덕에게 신기술은 이런 장단점이 있고, 이런 점이 걱정된다는 걸 이야기하다 보면 자연스럽게 문제가 해결된다는 방법론입니다. 실존하는 방법이에요. 조직이 작거나 얘기할 사람이 없는 경우에는 생각보다 도움이 될 거예요.
무엇보다 정말 이 기술이 우리에게 필요한지 고민해야 합니다. 신기술이고 유행이라고 해서 도입하는 건 아닌지 생각해 보세요.
신기술 도입하기
희망편
신기술을 도입하는 절차는 보통 다음과 같습니다.
1. 기술 검토
2. 스터디
3. 사이드 프로젝트(맛보기)
4. 사례 공유 / 공감대 형성
5. 일부 적용(기능 또는 서비스)
6. 적용 확대
저는 스터디와 사이드 프로젝트가 중요하다고 생각해요. 기술을 바로 도입하는 케이스는 거의 없습니다. 내부적으로 스터디를 하고 무엇이든 하나를 만들어 보고 도입하실 거예요.
도입이 최종적으로 결정돼도 바로 전체에 적용하면 안 됩니다. 가볍고 작은 것부터 적용하면서 확대해야 해요.
스터디의 옳은 예
도커
저는 도커 스터디를 하면서 굉장히 많이 배웠습니다. 당시에는 도커가 많이 알려지지 않은 기술이었어요. 더 배우고 싶어서 모임을 만들었는데 모임 이름을 엄청 고민하다가 어떤 분이 무조건 뒤에 ‘코리아’를 붙이라고 하셔서 ‘도커 코리아’라는 이름의 모임을 시작했습니다. ‘코리아’가 붙으니 부담이 되더라고요. 더 열심히 공부했습니다. 이 모임이 쿠버네티스 스터디, 44BITS로 발전했고요. 주말마다 오프라인 밋업을 가졌고, 도커 본사랑도 연이 닿아 본사에서 이야기를 나눈 적도 있습니다.
사이드 프로젝트의 옳은 예
mysetting
사이드 프로젝트를 하는 것도 중요하다고 생각해요. mysetting은 개인적으로 진행한 사이드 프로젝트인데요, 새로운 기술을 테스트해보고 싶어서 만들었습니다. Dark Mode, Tailwind, Supabase(Postgres REST API), Algolia(Search Engine), Toast UI Editor(Markdown Editor), AWS SQS와 Lambda(Serverless) 등 궁금한 기술이 정말 많았거든요.
mysetting을 먼저 구상한 건 아니고, 저 기술들로 무언가를 만들려고 하다 보니 탄생한 서비스입니다. 개발자분들은 보통 서로의 에디터 테마, 개발 폰트, 사용하는 프로그램이나 기술, 장비 등을 궁금해하거든요. mysetting에서는 각자가 사용하는 기술, 운영체제, 장비 등을 공유하고 필터링해서 볼 수 있습니다.
mysetting 덕분에 다양한 기술을 써보면서 시야를 넓힐 수 있었어요. 만족스럽게 테스트한 기술은 실제 프로젝트에 적용해 사용하고 있습니다.
빠른 태세 전환의 옳은 예
hasura
아주 간단한 백엔드 서비스를 만들고 싶었던 적이 있었어요. 조건은 오직 테이블 생성과 수정이 편한지, API 개발이 쉬운지, 최소한의 코드로 만들 수 있는지였습니다.
그러다 ‘Prisma’를 찾았어요. 모델링만 해주면 바로 테이블을 생성하고 API가 나오더라고요. 제가 무언가를 짤 필요가 없었습니다. 스터디를 하고 도입을 검토하다가 ‘nexus-prisma’를 발견했습니다.
Nexus 프레임워크는 ‘Code-First’ 철학을 갖고 있습니다. nexus-prisma로 시작하면 코드 에러가 발생할 수 없는 구조를 만들어 주죠. 한창 또 빠져들어서 nexus-prisma까지 도입을 결정해 전사 세미나도 진행했습니다.
그러다 순간 깨달았어요. 간단한 백엔드 서비스를 만들려고 시작했는데 오히려 복잡해졌다는 걸요. nexus-prisma가 처음 보면 이해도 잘 안되고 복잡하거든요. 서비스의 기술적 완성도는 높아졌지만 실제로 쓰기는 어려운 상태였습니다. 지인분이랑 이야기하다가 그분에게 hasura를 소개받았어요.
hasura는 스키마 정의부터 사용까지 1분이면 되고, GraphQL도 제공해 주고 REST API도 만들어줍니다. 기본 조회, 1:N 조회, 계산 함수도 있고, 정렬과 페이징도 됩니다. Insert, Update, Transaction, 구독도 실시간으로 지원하고요. 가장 좋은 건 코드를 작성하지 않아도 쓸 수 있다는 거예요. 지금도 매우 만족스럽게 사용하고 있습니다. 복잡한 비즈니스 로직에는 적합하지 않은 기술이지만, 저평가된 기술 중 하나라고 생각해요.
추가로 고려할 것
기술보다 중요한 건
팀원의 공감입니다. 일단 회사 대표나 의사 결정자가 신기술에 부정적이면 도입이 쉽지 않아요. 이럴 땐 정말 철저하게 준비해서 설득해야 하죠.
새로운 기술을 테스트하고 도입할 여유가 없는 회사도 있습니다. 스터디 할 시간도 없다면 일단 회사 레거시를 최대한 개선하고, 인력을 충원하는 데 집중해야 해요.
모두가 반대하는 기술을 도입하고 싶다면 회사를 차리시면 됩니다. 회사 대표가 되어 쓰고 싶은 기술을 쓰거나 팀장급이 되어 의사 결정권을 가지면 돼요. 그래도 소통 없는 도입은 절대 좋은 결과를 가져올 수 없습니다.
팀원인데 신기술을 도입하고 싶다면 잘하는 팀원이 돼야 합니다. 잘한다는 게 추상적이지만 팀장과 팀원을 설득할 수 있어야 해요. 기술에 대한 이해도 뛰어나야 하고 팀 내 기술적인 평판이 좋아야 합니다.
관성은 변하기 어려워요. 논리적으로 설득하기도 어렵죠. 예를 들어 회사에서 비효율적으로 하는 일이 있다고 가정해 볼게요. 누가 봐도 비효율적인데 효율적이라고 생각하는 기능을 도입하면 효율이 좋아질까요? 이미 관성으로 굳어져 있어서 어떻게 보면 비효율적인 게 가장 효율적인 상태일 수 있습니다. 억지로 도입하면 오히려 리스크가 커질 수 있어요. 다른 곳에서 개선할 방법을 찾는 게 나을 수 있어요.
벤치마크보다는 생산성을 체크하는 게 중요해요. 속도가 빠르다고 무작정 도입하는 게 아니라 모두가 익숙하고 빠르게 작업할 수 있는 생산성 높은 기술을 선택해야 합니다.
마무리
신기술을 도입하는 과정이 언뜻 복잡해 보일 수 있습니다. 핵심은 어떤 기능인지가 아니라 그 기술이 정말 우리 프로젝트에 도움이 될지 판단하는 거예요.
새로운 기술이 무조건 좋을까요? 새로운 기술을 쓰는 것보다 기존에 사용하던 기술을 깊게 파보는 것도 좋은 선택입니다. 네이버도 MySQL을 잘 쓰는 회사잖아요.
실패하는 것도 좋은 경험이라고 생각합니다. 새로운 기술을 성공적으로 도입할 확률이 그다지 높지 않거든요. 중요한 건 실패할 수 있다고 생각하고 대비해야 한다는 거예요. 실패에서도 배울 점은 있습니다.
신기술 도입에 정답은 없습니다. 오늘 전해드린 이야기도 한 스타트업에서 17년 정도 개발한 사람의 경험일 뿐이에요. 스타트업의 본질은 개발을 통해 문제를 해결하는 거잖아요. 유행에 휩쓸리지 말고 본질적인 문제 해결에 집중해 보세요.
Edit Sunny Design Lil
