벌써 한 해가 지났다
개발 일을 시작한게 2021년 4월 이었습니다
첫 취업을 한 회사에서 약 1년의 시간을 보냈었는데요
처음 마주하는 사회생활은 때론 즐거우면서도, 때론 어려운 일이었습니다
특히 팀원들이 “함께 일을 진행하며 공동의 목표로 달려간다” 를 제대로 수행하는것이 얼마나 어려운 일인지 알게된 해였습니다
이 때, 처음 겪는 문제들에 대해서 단편적으로 생각하는 일이 많았던것 같아요
“우리 리더는 뭐 하는거지?”, “왜 새로운 라이브러리를 도입하지 않는거야?”, “레거시를 빨리 새 도구로 마이그레이션 하는게 좋지 않나?” 와 같은 생각들 말이죠
그 뒤로 여러 해가 지났고, 2023년에 이르러 조금은 복합적인 생각을 갖게 된 것 같습니다
기업이 돌아가는 이유
스타트업의 이상적인 모델은, 새로운 가치를 창출함과 동시에 수익을 낼 수 있어야 한다고 생각합니다
저에겐 아직 두 가지 모두 어렵게 느껴지는데요
코로나가 한창 진행중일때 취업을 하고 코로나가 끝나는 무렵의 스타트업 시장을 경험하면서 많은 생각을 하게 된 것 같습니다
아직 기업 규모가 작은 스타트업 입장에서는 선택과 집중을 통해 생존을 위한 사투를 벌이게 됩니다
여기서 개발팀은 생산성을 최대한 끌어 올려야 하고, 선택의 기로에 놓이게 됩니다
“지금 프로젝트에 어떤 문제가 있는데, 잠깐 편법으로나마 해결할 수 있을것 같아. 나중에 해결하자” 라던가 말이죠
지금도 상당히 많은 팀에서 이루어지는 의사 결정이라고 생각하고, 틀린 결정이라고 생각하지 않습니다
문제는 이 이후인데요, 위 상황이 여러 번 반복되면 어느 순간 요구 사항에 비해 개발팀이 낼 수 있는 속도가 임계점에 도달했다는 것을 느낄 수 있습니다
팀 코드 베이스가 점점 무거워져 변경 사항을 적용하기 어려워 진다거나, 예상치 못한 사이드 이펙트가 관리가 되지 않는다거나 말이죠
결국 팀의 생산성은 떨어지게 되며, 개발팀에게 필요한 덕목인 유연하고 빠른 기능 개발을 수행하기가 어려워집니다
스타트업의 생명 주기
스타트업의 생명 주기는 초기(아직 투자를 받지 못했거나, 소액의 첫 투자를 받은 경우), 중기(몇 번의 시리즈 투자를 받았으며, 성장세가 보이는 단계), 후기(유니콘 혹은 상장을 진행할 만큼 중규모 이상의 기업이 된 경우)를 거친다고 생각합니다
여기서 단계별로 넘어갈 때, 위와같은 고민 사항들이 발생한다고 생각해요
초기에는 당장 돌아가는 코드를 생성하여 MVP를 구현하는게 중요했다면, 중기에는 어느정도 유지 보수 가능한 코드가 유지되어야 하고 후기에는 큰 팀이 움직일 수 있는 생산성을 챙기며 5년 10년 갈 수 있을 대비를 해야한다고 생각합니다
제가 재직중인 채널팀은 중기에 속하는 스타트업이라고 생각드는데요, 요즘엔 중기에서 후기로 넘어가는 과도기가 시작되었다는 생각이 들고있습니다
우린 어떻게 일하지?
채널팀에서 여러 TF와 개선 작업에 참여하며 느끼는 점들이 있습니다
다른 조직들에 비해서는 기능의 업데이트나 변경 사항이 자주 들어오는 느낌이고, 역시나 일정이 넉넉하진 않다
이제 개발팀이 다시 한 번 생산성을 업그레이드 할 시기가 도래했다는것을 느끼고 있고, 이를 위해서는 몇가지 생각해볼 주제들이 있습니다
조직 문화 개선
참 어려운 말입니다. 약 200여명의 조직 문화를 한 번에 개선한다는 것은 쉽지 않은 일이며, 기존의 작업 방식에서 어떤 문제가 있었고 어떻게 변해야 하는지 결정하는 일은 어려운 일입니다
특히, “모든 사람들이 각자 원하는 일 하는 방식”이 동일하도록 만드는 것은 불가능 합니다
내/외부적 요인
그렇다면 우선 “내가(혹은 우리 팀이) 할 수 있는 일”에 집중해 보기로 했습니다
여느 클라이언트 개발자분들은 공감하실 내용인데, 클라 개발은 항상 일정의 맨 뒷단에서 일정에 쫓기는 일이 많습니다 (API 나오는거 밀렸는데, 일정은 그대로)
이러한 상황에서, 우리가 할 수 있는 일은 생산성을 올려 더 빠른 개발 속도를 챙길 수 있도록 해야 한다고 생각해요
어떤 것들을 바꿔야 할까?
현재 채널 web-desk 팀의 모토는 “모든 개발자가 모든 도메인을 작업할 수 있어야 한다” 입니다
초기 인원이 적을 때는 적절한 방식이었을 것 같은데요, 점점 도메인이 많아지고 개발 인원이 많아지며 여러 문제들이 발생했습니다
1.
모르는 도메인에 대해 리뷰나 개선 작업을 진행하려면 히스토리를 아는 사람을 찾아가서 도메인 관련 지식을 물어봐야 한다
2.
버그가 발생할 경우, 담당자를 지정하기가 어렵다
3.
도메인에 필요한 개선 사항이 있더라도, 집중하여 챙길 수 있는 사람이 없다 보니 잘 챙겨지지 않는다
이러한 문제들을 해결하기 위해서, 요즘 많은 책을 읽고 여러 사례들을 찾아보고 있습니다
그렇게 든 생각은 다음과 같아요
web-desk의 도메인을 분류하고 리스트를 만들어야 합니다. 그리고 각 도메인마다 n명의 담당자를 지정한다
지정된 도메인 내부에서 주기적으로 이터레이션을 돌며 이슈 파악 및 개선/신규 개발을 진행해야 한다
재미 없는 도메인과 재미 있는 도메인을 연결하여, 한 조직이 2개의 도메인을 담당한다
더 빠른 배포를 진행할 수 있도록 기능별 배포 기능을 고도화 하고, CI 빌드 타임을 줄여 작업물을 빠르게 확인할 수 있어야 한다
나부터 시작해보자
조직이 처한 문제들이 정의되었고, 이를 해결하기 위한 액션들도 정의되었습니다
하지만 이를 제대로 성공시키기 위해서는 조직원들의 합의가 있어야 한다고 생각해요
분명 어렵겠지만, 지금부터 한 분 한 분 찾아가며 커피챗을 신청해 친해져볼 생각이구요
어떤 점들이 불편하고, 어떤 작업들을 좋아하고, 어떤 일을 하고싶은지 들어볼 생각입니다
개인적인 개선으로는, 핑계지만 작년에는 팀을 옮기면서 도메인 파악이 너무 바빠 기술적인 내용에 대해 많이 학습하지 못했는데요
조직의 리더나, 의견 제시자들은 항상 기술적인 이해도가 높아야 한다고 생각하기에 성장을 위해 매일 아침마다 책도 읽고, 공부도 시작했습니다.
앞으로 팀에서 개발적/문화적 부분들을 이끄는 사람이 되고 싶구요, 2024년을 돌아봤을 때 뿌듯한 일들을 많이 만들고 싶습니다
분명 어려운 길이겠지만, 응원해주셨으면 좋겠습니다. 읽어주셔서 감사합니다