리뷰

[세미나] [2월 COMMIT] 스타트업과 적정기술 : 성공적으로 신기술을 도입하는 법

nooblette 2023. 2. 15. 20:32

세미나 소개

- 구름에서 매달 진행하는 개발자를 위한 세미나

 

COMMIT - 구름 공식 블로그 (goorm blog)

COMMIT은 COMMUNICATION과 IT의 합성어로 한 달에 한 번 수요일에 기술, 개발, 성장, 조직 문화 등에 관한 이야기를 나누려고 해요.

blog.goorm.io

매번 메일로 알림을 받아서 관심있는 주제라면 들어보려고 노력하고 있다. 이번 회차 주제는 "성공적으로 신기술을 도입하는 법"

아래 내용은 세미나를 들어보면서 정리했던 내용이다. 누구나 관심있고 궁금할 수 있는 내용이라 블로그에도 올려두려고 한다(문제가 되면 지울 것)

신기술 도입 원칙

  • 리스크보다 큰 이점이 있는가
    • 리스크 : 신기술을 도입하고나면 (높은 확률로) 어떠한 트러블 슈팅이 발생
    • 그럼에도 불구하고 도입을 할 만한가
  • 많이 사용하고 있는 기술인가
    • 대중적이라면 구글링이나 관련 내용을 찾았을때 많이 나오는가(이슈 발생시 빠르게 조치를 취할 수 있어야함)
    • 아니라면 내부 구조를 잘 이해하고 수습하고 있는가
  • 팀원들의 공감을 얻었는가
    • 개발환경, 개발능력, 조직구조에 적합한가
    • 내가 없더라도 유지보수가 가능한가
  • 지속 가능한 기술인가
    • 2,3년내로 커밋한 이력이 없는 오픈소스다 → 경계(최근코드기여)
    • 오버엔지니어링 경계(MSA, K8S..) → 잘 쓰다가 버전업하고 안될 수도 있음
    • 실제로 도입을 했다가 커뮤니티가 망해버리는 불상사가 발생하기도 함
💡 많은 개발자들이 “그냥 쓰고싶어서” 도입하는 경우가 많다

 

신기술 도입 실패사례의 공통점

  • 특정 기술에 과하게 몰입 → 기술에 몰입한 나머지 판단력이 흐려짐
  • 많이 사용하지 않는 기술이더라도 잘 수습하면 되겠지라는 자신감
  • 팀원들을 고려하지 않음

 

개발자의 성장 곡선

뭔가 아는 것 같지만 무엇을 모르는지 여전히 모르는 상태 가장 자신이 넘치고 가장 위험한 상태

→ 신기술 도입할때 가장 주의해야할 시기

 

신기술을 도입하기 전에 주의할 것

기술의 단점찾기 / 내가 모르는 내용 알아보기

  • 기술 소개 페이지는 좋은 내용만 가득하다
  • 이 기술을 비롯한 유사한 다른 라이브러리는 무엇이 있을지
  • 최종적으로 기술을 검토할 때 단점과 다른 기술과의 비교는 필수
    • 추천 검색어
      • “vs” e.g.) redux cs
      • “is bad” e.g.) redux is bad, because ….
  • 여러개의 장점보다 하나의 단점이 더 큰 문제를 일으킬 수 있음

잘못된 판단으로 인한 신기술 도입의 결과

  • 신기술이 모든 문제를 해결해줄 것 같다 → 문제는 여전히 남아있음
  • 더 적은 사람이 할 수 있다 → 잘못된 기술은 더많은 인력 투입을 초래함

 

회사와 신기술

장점

  • 신기술 도입은 회사 브랜딩에 도움이 된다
  • 회사의 성장이 개인의 성장이 될 수 있다

주의할 점

  • 지금 새로운 기술도 언젠가 레거시가 된다
  • 회사 입장에서는 빠른 기간에 정해진 기술을 도입해야하는데, 레거시를 걷어내고 신기술을 도입하는 과정 자체가 리스크가 됨 → 회사와 개발자간에 이해관계가 설득이 되어야함

무조건 신기술을 도입하는게 답은 아니다

  • 신기술을 도입하기전에는 스터디를 하고 적용을 시도할 시점이 필요함
  • 오래된 기술이 나쁜 것은 아님 → 관련 내용들이 많고 안정적일 수 있다
  • 옛날 기술과 새로운 기술을 적절하게 사용해야함
    • 테슬라 메인 홈페이지도 php(drupal) + 제이쿼리도 구성되어있다
    • 하지만 결제페이지는 리액트로 되어있다
💡 회사의 규모, 상황, 개발문화, 사람들에 따라 다르기때문에 일반적인 상황에 정답은 없다
→ 결국 나의 상황에 맞게 고려를 해야한다

 

신기술을 도입을 위해 필요한 과정

신기술 도입하기

  1. 기술 검토
  2. 스터디
  3. 사이드프로젝트를 통한 기술 맛보기
  4. 팀원과 사례 공유 및 공감대 형성
  5. mission critical하지 않은 작은 기능과 서비스부터 일부 적용
  6. 적용 확대

도입하기로 했으면 내부적으로 스터디를 하고 맛보기를 위한 사이드 프로젝트를 진행

→ 사례 공유를 하며 팀원들과 공감을 하는 과정이 중요

 

고민된다면 물어보자

  • 상대방을 설득을 해야 그 기술을 도입할 수 있는것
    • 상대방을 설득하다가 내가 설득이 될 수 있음(말하다보니 도입하면 안되겠네…..?)
  • 회사 내 팀 동료에게 물어보자
  • 기술을 잘 이해하고 있는 사람에게 물어보자
  • 기술적으로 이견이 있어 불편한 사람이 있다면 그 사람에게도 물어보자
    • 이러한 사람도 설득할 수 있다면…?
  • 제가 ~~한 이유로 ~ 기술을 도입하려고 하는데 어떨까요?

 

러버덕 디버깅

러버덕 디버깅 관련 글 : https://onwah.tistory.com/9

러버덕 인형한테 신기술 도입을 위해서 말하다보면 생각이 정리되고 자연스럽게 문제가 해결될 수 있다

(단지 신기술 도입 뿐만 아니라, 디버깅 중 막혔거나 코드가 생각한대로 동작하지 않을때에도 활용할 수 있을 것 같다)

 

다시한번 고민

진짜 필요한가?

  • 도입하기전에 다시한번 생각
  • 그냥 신기술을 쓰고싶은건 아닌지
  • 유행에 따라 도입하는건 아닌지

 

성공적인 적용 사례

hasura

  • 간단한 백엔드 서비스
    • 편리한 테이블 생성,수정
    • API 개발에 편리(CRUD + 각종 검색 조건)
    • 최소한의 코드로 만들 수 있는가
  • 검토
    • prisma 낙점
  • nexus-prisma
    • Nexus 프레임워크의 “Code-First” 철학
    • 코드를 안전하고 빠르게
    • 다시 스터디
    • 전사 세미나를 통해 공감
    • 도입

hasura 간단 소개

(실제로 파트에서 내부적으로 작게 써먹어보면 좋을 것 같다)

  • 기능
    • 스키마 정의부터 사용까지 1분(Graph QL, REST API)
    • 기본 조회, 1 : N 조회, 계산(COUNT, SUM, AVG, MAX, MIN …) 함수, 정렬, 페이징 등..
    • insert, update, upsert(insert or update), transaction 지원
    • 실시간 구독 지원
    • 인증, 인가 지원
    • Event 트리거
    • CLI Migration 지원
  • 용도
    • 간단한 게시판을 보여주는 용도
  • 실제 후기
    • 팀원들도 만족
    • 코드를 작성하지 않아도 쓸 수 있다
    • 여러개의 내부 시스템에서 적용 중

 

신기술 도입을 위해 추가로 고려할 것

기술보다 중요한 것

  • 스터디 → 사이드 프로젝트 선행(인력, 시간적 리소스 투입이 요구됨)
  • 팀원들의 공감
    • 회사 또는 의사결정자가 신기술에 부정적인가?
      • 도입이 쉽지 않을 것
      • 설득이 쉽지 않음을 인지하고 더 철저하게 준비해야함
  • 새로운 기술을 테스트하고 도입할 수 있는 여유가 있는가
    • 회사일이 너무 바쁘다면 우선 레거시 개선(자동화 등..)과 인력 충원에 집중 → 일 자체를 분배할 수 있는 환경이 선행되어야함
  • 리소스 소요
    • 스터디, 사이드프로젝트, 트러블 슈팅하는데 에생각보다 많은 리소스가 소요됨

원활한 신기술 도입을 위한 방안

  • 회사 대표 또는 팀장(결정권자)가 된다
    • 새로운 기술 도입 부담이 적다
    • but, 팀원과 소통 없는 일방적인 도입은 좋지 않다
  • 잘하는 팀원이 된다
    • 기술에 대한 이해도가 뛰어나고 팀내에 기술적인 평판이 좋아야함
    • 지금 기술도 제대로 못쓰는데 추진해봤자 좋은 인상을 받지 못함
    • 팀장과 팀원을 설득해야함
  • 관성은 변하기 어렵다
    • 관성(기존에 회사에서 잘 쓰던 것들)은 논리적으로 설득하기 어렵다
    • 원래 비효율적으로 하던일을 개선하기위해 효율적이라고 생각하는 기능을 도입하는게 정말 효율적일까?
    • 괜히 도입했다가 다시 적응하고 이슈 해결하는게 더 비효율적일 수 있다
    • 신기술 도입이 아닌 다른 방안으로 도입할 방법을 고민해본다
  • 벤치마크보단 생산성
    • 익숙하고 생산성이 좋은것이 최고
    • 무조건 가볍고, 빠른 새로운 기술을 적용한다기보다는 결국 생산성을 끌어올릴 수 있는 기술을 사용해야함
  • 상황에 맞게 적절한 판단
    • 일정이 한달남았는데 갑자기 신기술 도입해서 한다? 이러한 도입은 불가능함
  • 실패하기
    • 새로운 기술을 항상 성공적으로 도입할 확률은 매우 희박
    • 실패를 가정하고 대비하자
    • 실패하더라도 그 과정속에서 라이브러리, 코드를 보면서 배울점이 있다

 

새로운 기술이 무조건 좋을까?

  • 무조건 새로운 기술보다 기존 사용 기술을 깊고 안정적으로 서비스하는 것도 중요하다
    • 네이버 - MySQL을 오랜 시간 검증해서 사용
    • 쿠팡 - MSA를 위한 비타민 프레임워크를 안정적으로 서비스
  • 신기술 도입에 정답은 없다 → 항상 상황에, 환경에 맞게 적용해야한다
  • 기존 코드로 문제없이 서비스가 운영된다면 → 굳이 새로운 기술을 도입해야할 필요가 없다
  • 회사가 바쁜상황에서 신기술 도입은 무리
    • 지금 상황이 바쁘다면 레거시 자동화, 인력충원 등을 통해 바쁜상황을 먼저 해결해야함

 

신기술 도입을 위한 개인적으로 인지해야할 것

  • 논리적 설득
    • 이걸 도입하면 이런 장점이 있고 우리 프로젝트에 이러한 면에서 도움이 될 것이다~
  • 신기술 도입을 위해서는 스터디, 사이드 프로젝트, 트러블 슈팅이라는 과정이 필요함
  • 신기술 도입은 리스크가 있음, 이보다 기존 기술을 깊게 파고드는게 더 좋을 수 있다
    • 원래 잘하던 것을 더 깊게 파는것이 생산성 증대로 이어질 수 있다
  • 개발과 기술을 통해 어떤 서비스, 상황, 사람에 문제를 해결하는게 개발자의 역할이지 새로운 기술을 도입하는게 개발자의 역할이 아님
  • 신기술이더라도 언제든지 망할 수 있음을 주의하고 탈출할 준비를 해야함
    • 다운되더라도 크게 문제되지 않을 작은 서비스부터 적용해가면서 신기술을 점진적으로 도입해야함
    • 시작부터 전사에 적용할 것이 아니라 미션 크리티컬하지 않은 작은 부분부터 도입해서 사용하다가 기술이 계속 인기가 유지된다면 점진적으로 전사 서비스로 확대하는게 좋음
    • 큰 기업에서 만든 기술, 많이쓰는 기술, 깃허브에 스타가 많은 기술을 사용하는게 좋다
  • 단순히 신기술을 도입하여 유지보수를 하는 것으로는 인정받기 힘들다
    • 유지보수의 어떠한 측면에서 도움이 돼서 신기술을 도입했고 실제로 좋은 성과로 이어져야 인정받을 수 있다
저작자표시