brunch

You can make anything
by writing

C.S.Lewis

by JunHo Lee Dec 28. 2020

2020년 회고

Product Owner, 가족, 자기계발

이건 철저히 나를 위한 기록이다. Product Owner로서 지난 1년간 한 일들에 대한 회고이며 반성이다. 사실, 내 커리어적인 측면에서는 작년과 올해가 가장 많은 변화가 일어난 시기인데 작년부터 회고를 진행하지 못했다.

나의 에버노트와 notion을 보면 (거의)매년 연말에 회고를 하고 (지키지도 못할) 신년계획을 작성하기도 했는데 작년에는 얼마나 정신이 없었는지 혹은 얼마나 지쳐있었는지 그러지 못했다.(사실 작년 연말이 잘 기억이 나지 않음) 그래서 올해에는 꼭 작성을 했야겠다고 12월 초부터 마음을 먹었다.

사실, 이런 회고나 계획 같은게 없더라도 사는데 지장이 없다. 그런데 이상하게...기록이 없으면 사라지는 기억과 함께 지난 시간도 사라지는 느낌이다. 그래서 그런지 가급적이면 기억이 날 때 기록을 하려고 한다.

AI 학습데이터 Annotation 플랫폼과 애자일

2019년부터 2020년 3월까지 난 2개 팀의 팀장을 겸임했다. 하지만 회사가 급성장하면서 팀원들이 많아지다보니 나 혼자 2개의 팀을 운영하는데 어려움이 많았다. 그래서 프로젝트를 운영하는 팀의 팀장역할을 내려놓고 플랫폼 기획팀의 팀장으로서 AI Annotation Platform Product 개발 프로젝트를 시작했다.

기존 Product에서는 AI 학습데이터를 위한 (이미지 바운딩 같은)데이터 가공 프로젝트를 하나 오픈하는데 많은 리소스가 들어갔다. 이번 프로젝트에서는 Annotation Tool을 개발자의 코딩없이 고객이 플랫폼 내의 기능으로 바로 구성할 수 있도록 해야했다.

따라서, 우리회사의 비지니스에서는 이번 프로젝트가 굉장히 중요한 프로젝트였다.

이번 프로젝트로 인해 총 5개의 Product에 변화가 생긴다. 즉, 각 Product의 dependancy를 잘 파악해야 한다.

그리고 다국어를 지원해야 한다.

레거시는 가능한만큼 제거해야 한다.

레거시를 무조건 걷어내야만 한다고 생각하는 사람들이 있다. 그런데 레거시도 잘 파악해보면 그럴만한 이유가 있다. 대부분, 시간이 부족하다보니 안정적인 방법으로 개발되지 않았을 뿐이지 그 당시에는 주어진 시간 내에서 문제를 해결하고자 하는 노력들이었다.(그냥 그렇게 믿자)

그래서 레거시를 없애기 위해서는 그 만큼 시간적 여유와 리소스를 확보하는 것이 중요하다. 그런데 스타트업에서 그런 여유를 가지고 프로젝트를 진행하는 경우가 얼마나 있을까? 레거시를 완벽하게 제거하고 새로운 방식으로 문제를 해결할 것이 아니라면 레거시를 유지하는 것도 하나의 전략이다. 어정쩡하게 다시 개발하는 것은 레거시위에 레거시를 쌓을 뿐이다. 따라서, 레거시는 가능한만큼 제거해야 한다.

프로젝트 진행을 위해 애자일 방식을 도입했다. 그런데 사실 지금 생각해보면 이번 프로젝트에서는 워터폴방식의 개발이 더 맞았을 것 같다는 생각이 들었다. 애자일 방법론을 도입한다고 해서 개발이 빨리 진행되는 것은 아니다. 그리고 워터폴 개발 방법론이라고 하면 무조건 구식의 안 좋은 방법이라고 생각할 수 있는데 그건 잘못된 것이다. 상황에 맞는 개발 방법론이 있을 뿐이다.

프로젝트를 진행하면서 내가 지금까지 겪은 FE 개발자 중 최고의 개발자와 일을 함께했다. 사실, 이번 프로젝트는 Annotation Tool의 특성상 FE 개발의 난이도가 굉장히 높은 편이었는데 이 개발자 덕분에 많은 문제들이 해결되었다. 뛰어난 개발자와 일을 하다보면 기획자도 참 많이 배우게 된다.

프로젝트를 진행하는데 커뮤니케이션에 생각보다 많은 리소스가 들어갔다. BE, FE, iOS, Android 개발자들 뿐만 아니라 대용량 데이터를 처리하는 Data Engineering팀과도 유기적으로 협업을 해야했기 때문이다. 커뮤니케이션의 대상자가 많으면 대상자들 모두 관련 내용을 확인했는지, 확인을 했으면 모두 동일하게 이해하고 있는지 확인을 해야하는 과정이 굉장히 중요하기 때문에 리소스가 많이 들어갈 수 밖에 없다. 이 리소스를 아까워하면 더 큰 재앙이 온다.

6월에 신규 Product을 오픈했다. 그리고 각 유관부서의 다양한 요청사항과 개선사항이 빠른 속도로 증가했다.

그러다보니 우선순위를 정말 잘 선정하기 위해서 극한의 집중을 했다. 스프린트 하나에 들어갈 주요 티켓의 우선순위를 정말 신중하게 선택해야 했다. 정말 급하고 중요한 것은 당연히 우선적으로 진행한다. 그런데 아무리 중요한 기능이라도 개발기간이 너무 길어지면 안 된다. 그래서 쪼갤 수 있는 부분을 쪼갠다.

우선순위는 선정하는 건 사실, 중요한 것을 고르는 것이 아니라 중요하지 않는 것을 하나씩 제거하는 것이다. 그래서 10개 중에서 1개를 고르는 일보다 30개 중에서 3개를 고르는 일이 더 어려운 것이다. 30개의 요청사항 중 3개의 티켓을 고르는 것은 27개의 덜 중요한 것을 선정하는 것이기 때문이다.

어느덧 시스템이 안정화되면서 스프린트를 좀 더 안정적으로 운영할 필요가 있었다. 단순히 스프린트 내 티켓을 완료하는 것을 넘어 팀이 한 스프린트 내에서 소화할 수 있는 스토리포인트의 총 합계를 알 수 있어야 하고 이를 토대로 주기적인 배포계획을 세울 수 있어야 했다. 그래서 몇 가지 변화를 시도했다. 스프린트 회의에서 개발 진행 관련 사항을 투명하게 모두 공개하도록 했다. 스프린트 내에서 팀원 각자 진행한 스토리포인트를 기록했다. 계획되었었던 양과 실제 진행한 양을 모두 기록했다. 계획한 양과 실제양이 차이가 많이 나면 이는 계획을 잘못 수립한 문제이기 때문에 스토리포인트 산정에 문제가 있는 것이다. 스토리포인트의 산정을 시간단위에서 업무난이도 단위로 조정했다. 시간단위로 스토리포인트를 산정을 하는 것은 정확하게 공수를 산정하여 리소스를 효율적으로 사용하기 위함이지만 시간단위로 하는 것 자체가 정확할 수 없는 단위이다. 실제 개발자가 해당 개발에 온전히 집중한 시간을 측정하기 어렵기 때문이다.

그러다보니 내가 스크럼마스터 역할을 하고 있었다. PO와 SM 역할은 이해관계가 다르기 때문에 동일한 사람이 하면 안 된다고 하는 사람들도 있는데 난 별다른 문제점을 느끼지 못했다. 단지, 내 업무가 기하급수적으로 늘어날 뿐이었다.

프로젝트를 진행하는 중간에 사이드 프로젝트로 채용사이트를 하나 만들어서 오픈했다.

AI 학습데이터 가공이란 것이 결국 사람이 하는 것이기 때문에 프로젝트에 알맞은 사람을 모집하는 것도 우리 비지니스 중 하나이다. 그래서 실제로 채용플랫폼을 만들어서 데이터라벨러 채용시장이 일반 알바 채용 시장과 다른점은 무엇인지, 가치가 있는 비지니스인지 증명해 보고 싶었다. 1개월 준비하고 MVP 버전을 만들어서 오픈했는데 생각보다 반응이 괜찮았다. 채용플랫폼이 시스템적으로는 별거 아니지만 영업팀 입장에서는 하나의 판매상품이 생긴일이라 그들이 목표를 달성하는데 긍정적 역할을 했다.

그리고 10월이 되고 내부에서 세무, 회계 정보를 관리할 수 있는 세무/회계 시스템 개발 프로젝트를 시작했다. 이 무렵, 둘째가 태어나고 나 개인적으로 굉장히 힘든 시간이었는데 팀원이 프로젝트를 정말 잘 진행해줘서 아주 훌륭하게 마무리 되었다.