많은 회사를 거치진 않았지만 작은 스타트업에서 개발해 왔기 때문에 직접 기술적인 리딩을 할 경험도 주변에서 리드하는 모습도 가까이서 볼 수 있었는데,
그 역할에 대한 생각을 적어보려고 합니다.
Tech Lead
테크리드란 무엇인가?
테크 리드란 개발 리더, 테크니컬 리더, 리드 프로그래머, CTO 등 회사마다 부르는 용어는 다르지만 그 의미는 개발자들의 매니저로서 개발 분야 기술의 책임자입니다.
역할의 범위는 어디까지?
작은 스타트업에 주로 근무할 때를 떠올리면, 경영진과 개발자들 모두 처음에 원했던 테크 리드의 역할은 사내에서 사용하는 모든 기술을 다 이해하고
직접 구현할 수도 있으면서 개발 시 어려운 부분이 있다면 해결사 역할도 해주고 조언도 해주며 경영진과 개발자 간의 불편한 소통을 대신해 주어 기술적 난이도를 정확히 말해주고
일정 조율도 해주는 것이었습니다.
이 많은 역할 을 경험이 많아서 입사한지 한 달 안에 프로처럼 처리해 주는 모습을 기대합니다.
위와 같은 기대는 사실 허상이기도 하고 업무를 떠넘기고자 하는 욕구이기도 합니다.
자연스러운 스타트업에서의 테크리드!
작은 스타트업이면서 개발 인력이 적은 곳에 개발자들은 1명이 여러 명의 역할을 해줘야 합니다.
예를 들어 백엔드 개발자는 백엔드 서버는 물론 클라우드, 인프라 개발, 데이터베이스 관리, 데이터 엔지니어링, 분석, 크롤러, CI/CD, 문서 작성, 스케줄 관리, BtoB 미팅, 디자인/기획 협의 등
사실 선임 개발자고 밑에 개발 인원이 조금 더 있다면 자연스럽게 후임 개발자들과 업무를 나누며 백엔드 테크리드들이 하는 역할을 직접하게 됩니다.
거기에 더해 인력이 더 적을 시는 프론트엔드, 앱 개발도 병행해서 해야 되는 상황도 발생할 수 있습니다.
그렇게 시간이 지나 개발자들 간의 체계가 잡히기 시작하면 깃허브 이슈 관리, 코드 리뷰, 테스트 프로세스, 개발 컨벤션, 개발/배포 절차 등 많은 정의들을 테크 리더가 만들고 이에 맞춰 개발자들은 문서와 개발이 일체화 되어 가며 하는 일이 명확해집니다.
이렇게 되면 리드를 당하는 개발자들은 자기 개발만 신경쓰고 타 개발자들이 문서화하고 이슈, 태스크 등에 등록한 자료들을 통해 자료도 쉽게 찾아 사용할 수 있는 효율화된 개발 조직이 됩니다.
자연스럽게 테크리더들은 경영진들과 논의하며 다음 비지니스들에 대해 기술적 연구를 하고 개발자들과 상의해 가며 일정을 산출하고 매니징하기 시작하고 회사에서는 경험이 풍부한 시니어 개발자들을 더 채용하고 테크리더들은 소통하며 더 좋은 문화를 만들어 갑니다.
부자연스러운 스타트업에서의 테크리드?
**"자연스러운 스타트업에서의 테크리드"**는 기존 개발자들을 더욱 규합하고 서비스 운영 노하우와 개발 경험들울 가지고 시작할 수 있습니다.(다음에 들어오는 사람들에 대한 배려와 포용할 수 있는 개발 문화를 가지지 않으면 문제가 되겠지만...)
보통 초기 스타트업은 돈이 많지 않기 때문에 개발자는 주니어를 채용하고 이조차도 많은 인원을 채용하지도 않으며 기획자, 디자이너, 마켓터 등 개발을 원하는 비개발자들을 채용합니다.
주니어 개발자들은 열심히 서비스를 구현하고 런칭까지 성공시키면서 빠르게 성장하지만 당연하게도 개발 속도가 느렸을 거고 자신 없는 부분들을 드러내기도 했을 겁니다.
그러나 성공적인 런칭과 운영을 하며 다른 기술들을 공부하고 그 회사에 맞는 개발자들 간 프로세스들을 조금씩 확립해 나갈 즈음, 소수 인원의 개발자들은 힘에 부치기도 하고 잘하고 있는지 불안하기도 한 마음에 테크리드 채용을 원하기도 하고,
경영진들은 주니어 개발자들을 돕기 위해서 혹은 신뢰하지 못해서 "역할의 범위는 어디까지?" 에서 말한 허상에 가까운 테크리드 채용에 기대를 걸기 시작합니다.
그렇게 기대를 한 몸에 받고 들어온 테크리드들은 그 동안 구현해 놓은 개발 산출물들을 공부할 시간이 필요하지만 빠른 적응을 요구하기 시작합니다.(문서화가 많이 되어 있지 않고 개발 상태가 좋지 않을수록 더 많은 시간이 소요됨.)
그 동안 자연스럽게 테크리드를 해 오던 성장한 개발자들은 본인이 하던 일은 계속 하면서 테크리더로 들어온 인원에게 지속적인 교육까지 하게 되면서 일은 더 가중됩니다.
경력과 경험이 많은 테크리드 분이라도 사내에서는 그가 서비스 구성과 개발 현황, 기술들을 파악할 시간을 주어야 하는데 서비스가 빠르게 변화해야 하는 스타트업에서 이를 기다려주기는 힘듭니다.
묵묵히 파악하며 기술에 대한 조언 정도를 해야 하는 상황에 현재의 스케줄 조율과 이슈 트랙킹 등 많은 것들을 과중하기 시작하면서 제대로 파악하지 못한 상태는 지속되고 이런 상태로 선택과 조율, 협의가 계속 잘못 이뤄져 갑니다.
반대로 경험 많은 시니어 개발자를 테크리드로 채용했다면 높은 급여를 보장해 줘야 했을 것이기 때문에 테크리드를 위한 업무 파악을 시키는데 있어서도 회사적으로도 큰 손실이 됩니다.
차라리 위에서 말한 "자연스러운 스타트업에서의 테크리드" 의 리더가 경험 많은 시니어 개발자와 의견을 조율해 가며 기존 팀원들과 소통을 잘 해가며 업무 조율을 하는 것이 유리하다고 생각이 듭니다.
아니면 시니어 개발자로 채용해 어느정도 업무를 같이 해보고 추후 하고자 하는 의지와 역량에 따라 주변 개발자들과 조율해 이를 결정한다면 보다 나은 방법이 될 수도 있습니다.
테크리드에 대한 경험
첫 IT 회사에서 앱 개발자, 백엔드 개발자, 프론트엔드 개발자(나)로 개발자 3명이 있었는데 백엔드 개발자 분이 그 회사의 그나마 테크리드로서 역할을 했었습니다.
10년 넘는 경력이 있던 그 분은 react에 대한 경험이 적지만 최신 기술이라는 이유로 react를 도입했는데 연구 없이 도입해 사용 방법에 대해 잘 몰랐고 내가 입사하기 전에는 2명이서
개발을 해왔기 때문에 누군가에게 공유하는 일 또한 해보지 않았던 분이라 문서도 공유도 교육도 없는 분 이었습니다.
지금 생각해 보면 개발자로서 누군가한테 의지하지 말고 스스로 공부해서 처리해야 하는구나를 호되게 배웠던 회사였기에 어느 정도 개발자 인생에 대해 리드를 해주신건가 싶기도 합니다.
두번째 IT회사는 전체 인원이 같은 날짜에 입사해 모두 신입인데 첫 서비스를 만들기 위해 미션 수행을 하던 회사였는데,
이 회사에 같이 시작했던 빅데이터 대학원생, 데이터 엔지니어, 디자이너, 웹개발자 4명이서 개발을 시작했습니다.
이 중에서 그나마 서버 개발을 해 봤고 react 개발 경험이 있어 react-native 개발을 통해 앱도 개발할 가능성이 있었던 제가 자연스럽게 테크리드 역할을 맡게 됐습니다.
처음으로 인원들 마다의 업무를 분배하고 업무 난이도를 고려해 일정도 산출하고 그 스케줄을 조율하면서 문제가 있을 때마다 같이 고민하며 해결하는 재미가 있었습니다.
이 때 가장 힘들었던 건 부족한 경험에서 오는 자괴감이었습니다.
같은 직급이었지만 팀원들 모두 리딩에 잘 따라와 줬는데 클라우드, react-native, react 초기 설정, 백엔드 초기설정 등 모추 처음이었기 때문에 시간이 오래 걸렸고 여유가 없었습니다.
게다가 일정을 맞춰야 했기 때문에 분배한 업무가 잘 되지 않았을 때 동료들에게 가이드 해주거나 교육해 주지 않고 혼자서 업무 처리를 해 버렸습니다.
지금 생각해 보면 동료들의 성장과 나의 성장에도 회사를 위해서도 잘했던 행동은 아닌 것 같습니다.
하지만 여유가 없었던 주니어로서 리드 역할을 맡았으니 최선을 다 했던 걸로...
그 다음 회사에서는 입사하고 업무 교육을 잠시 받던 중 1달 동안 개발자들이 이해관계와 정치 싸움에 의해 모두 퇴사해 혼자 남았습니다.
6개월 동안 회사에 혼자 남아 개발 현황을 파악하며 유지보수하고 운영하고 업그레이드 했습니다.
그 동안 서비스를 위해 필요한 계정정보들부터 현재의 개발 상태, 배포 구성 등 운영과 개발에 필요한 문서들을 작성하기 시작했고 6개월 뒤 CTO로 입사한 분에게 이를 모두 인계 했습니다.
하지만 CTO 분은 입사하고 인계한 내용에 대해 공부하고 싶어하지 않았고 본인이 아는 스택으로 모두 재편하고자 했는데 이에 대해 데이터베이스 마이그레이션부터 개발 스택 선정에 대한 연구도 없이 강행 했습니다.
그 분의 리드 방식은 자신이 무엇을 하겠다는 말을 주변에 말하지 않고 혼자 갑자기 신기술에 대해 공부한 것이 있다며 실 서비스에 일정 부분 도입하고 전체 서비스에 팀원들이 마무리 해주길 원했습니다.
기존 서비스에 대해 전혀 파악하지 않고 신기술 적용 공부하듯 서비스에 도입하다 보니 ERD도 없고 데이터 마이그레이션도 하지 않아 기존 3년 간 모은 데이터들은 모두 손실됐고 비지니스와 직결됐던
배정 기능까지 문제가 생기면서 큰 문제들이 계속 발생됐고 발생한 문제들은 전체 그림을 공유하지 않았기 때문에 그 리더분에 의해서 해결되길 모두 기다리는 상황이었습니다.
그 CTO분은 결국 쫒겨나듯 나가는데 알고 보니 처음 말했던 거의 10년 경력은 실제로는 5년도 안되는 경력이었고 그 조차도 프론트엔드 경력이 대부분이었습니다.
거의 사기를 당한 경영진은 이후 CTO는 신중히 뽑겠다 했지만 결국 갑자기 게임업계 DBA로 계시던 분을 CTO로 영입하더니 모든 것을 인계해서 그 분을 구심점으로 돌아가길 원했습니다.
하지만 그 CTO분은 게임업계 개발 스택과 웹, 앱 개발 쪽의 개발 스택이 전혀 달랐고 DBA로서 DB만 보시던 분이었는데 역시 얼마 지나지 않아 게임업계로 돌아갔습니다.
시간이 지나 많은 분들이 입사하고 여유가 생기면서 개발도 하면서 자연스럽게 테크리드 업무들을 하게 됐습니다.
개발 과제에 대해 분석하고 타 팀과 협의 후 개발 팀 내 인원 분배, 일정 조율 등 전반적인 매니징을 진행하게 됐고,
또한 신기술 연구, 개발 스택 비교 등을 동료들에게 공유하고 함께 소통하며 근거 있는 개발 스택 선정을 했고 자연스럽게 팀원들과 소통해 깃허브 정책, 코드 컨벤션 등 개발 문화를 선진적으로 이끌 수 있었습니다.
이와 같은 경험들을 토대로 프리랜서로서도 테크리드 업무를 담당해 보다 나은 개발 정책과 문화를 자리 잡을 수 있도록 노력하고 있습니다.
이를 통해 크게 보고 매니징하며 더 여유있게 기술적으로 리딩할 수 있도록 더욱 성장하고자 하는 동기부여가 되는 것 같습니다.
마지막은 자기자랑처럼 끝나긴 했지만 아직 부족한 부분이 많다는 것은 리딩을 할수록 계속 느끼고 있고 꾸준히 공부하며 정말 팀에 필요한 것들을 찾아내 적재적소에 도입하고 모두와 좀 더 잘 소통하는 좋은 리더가 될 수 있게 노력할 것입니다.
RSA+AES 암호화 빙식 프로세스
Operating Architecture
