빅픽처인터렉티브에는 2019년 10월에 합류해서 이제 입사한 지 2년이다. 플랫폼 개발팀의 백엔드 파트 리드로 입사했고 현재는 백엔드 개발 팀장이다. 최근 전사는 크루 단위로 조직을 개편했다. 이스포츠 대회를 담당하는 대회 크루와 온라인 코칭을 담당하는 크루에 속해 있으며 여기서 개발과 인프라를 담당하고 있다. 레벨업지지 플랫폼 개발을 위한 테크 리드를 진행하면서 빅픽처인터렉티브 만의 유니크한 개발 문화를 만드는 것이 중요하다고 생각하기에 그 부분에 특히 심혈을 기울이고 있다.
레벨업지지 플랫폼 개발 과정 중에 특별히 이야기해 줄 만한 에피소드가 있나?
빅픽처인터렉티브에 입사하고 처음 맡았던 프로젝트라 모든 면에 고생이 많았다. 그런데 그중 특히 개발자로서 생각의 변화가 가져다준 '프레임워크'와 '인프라 변경 작업'을 특별하다 생각이 드는 에피소드로 꼽고 싶다.
입사했을 당시에 초기 레벨업지지 플랫폼은 노드에 몽고디비로 구축되어 있었다. 거의 1인 개발이라고 봐도 될 만큼 한 명이 핵심 도메인 개발을 전부 담당하고 있었다. 그런데 이미 개발이 어느 정도 진척된 지금의 기준으로 판단해도 많은 팀이 참가하는 축에 속한 오버워치 오픈 디비전(대회 명)이 곧 예정되어 있었다. 기능적인 버그와 인프라 문제까지 겹쳐져 있었고 모니터링도 전무한 상태였다.
우선 배포 자동화와 인프라/어플리케이션 모니터링을 추가하고 들어오는 이슈들에 대한 추적을 시작했다. 그런데 트렌젝션 관리가 되지 않아 발생한 데이터 적합성 문제들과 도큐먼트 별로 형태가 다른 데이터들이 혼재해 있었다. 결국 최종 완성도와 트래픽을 고려했을 때 기존 코드를 그대로 사용하는 것은 힘들 것으로 판단했다. 그래서 스프링 프레임워크에 MySQL로 마이그레이션을 전격 결정했다.
당시 백엔드 파트에 계셨던 분들은 JVM기반 언어나 스프링 프레임워크를 처음 접하는 상태였다. 따라서 기술적인 부분과 이스포츠라는 도메인에 대해 구성원들 모두 스터디와 업무를 병행하면서 진행해야 했다. 다시 생각해봐도 쉽지 않은 과정이었지만 지금 와서 보면 모두 잘 따라와 줬기에 무사히 마이그레이션을 마칠 수 있었다고 믿고 있다.
마이그레이션 프로젝트는 프로덕트를 만든다는 것에 대해서 심도 깊게 생각해 볼 수 있는 기회가 되었다. 물론 개발자에게는 프레임워크의 숙련도와 같은 기술적인 역량이 중요하다. 그러나 문제 해결을 위한 접근 방법과 미래에 발생할 수 있는 리스크를 예상하는 작업도 이 못지않게 중요하다고 할 수 있다.
이 블로그에는 기술 카테고리가 있다
빅픽처가 가진 기술력에 대해서는 주로 이곳에서 보일 예정인데
팀장님도 작성자 중 하나로 알고 있다
어떤 내용을 중점적으로 다룰 예정인가?
얼리스테이지에서 가파르게 성장 중인 플랫폼을 개발하는 개발팀이 겪는 성장통에 대해서 다루고자 한다. 잠시 회사 이야기를 하면 레벨업지지의 개발사인 빅픽처인터렉티브는 본격적인 플랫폼 개발 이전부터 아카데미 교육, 대회 운영 및 방송 제작 등의 사업이 활발히 진행되고 있었다. 그런 측면에서 보면 레벨업지지는 E스포츠 플랫폼으로 매우 좋은 위치에서 시작할 수 있었다고 본다.
주기적으로 블리자드, 라이엇, 펍지 등 큰 규모의 대회가 유치되었기 때문에 필연적으로 '촉박한 일정의 클라이언트 요구 사항'과 '팀', '로스터', '대진표', '체크인', '채팅'과 같은 복잡한 분야의 도메인을 계속 상대해야 했다. 또 기능 개발이 어느 정도 완료된 이후에는 '하나원큐 롤 대회'(*페이커와 테디 선수가 해설을 맡아 화제가 됨), '리그 마스터즈 프로모션'(*에스카 류제홍 문호준 앰비션 등이 참여), 라이엇 공식 아마추어 리그인 '배틀 아카데미아' 등 단시간에 폭발적인 트래픽이 요구되는 작업에도 대응해야 했다.
얼리스테이지에서 가파르게 성장 중인 플랫폼을 개발하는 개발팀이라면 사업의 기회를 위해 또는 경쟁 서비스들 간의 우위를 점하기 위해 단기간에 많은 기능을 추가해야 하는 상황들에 직면하게 된다. 특히 급격하게 사용자가 불어나고 있는 상황이라면 더더욱 공감하리라 믿는다. 요구 사항을 만족시키기 위해서는 '기술 부채'를 쌓으면 나가가야 한다. 그런데 기술 부채는 요구 사항, 서비스 규모의 변화와 같은 외부적 환경 이외에도 구성원들의 역량 컨디션 등 내부적인 요인에 의해서 심각도가 달라지게 된다.
이러한 다양한 변수들로 인해서 정량적인 평가를 통해 기술 부채가 얼마나 쌓여있고, 언제 이것을 해야 하는지 판단하기 쉽지 않은 일이다. 2년여 기간 동안 백엔드 개발 리드를 하는 동안 Data Driven에서 DDD, 단일 데이터 소스에서 멀티 데이터 소스, EC2를 활용한 단일 인스턴스에서 컨테이너로 변화하면서 그 당시에 왜 그런 판단을 했었고, 어떤 변화가 있었는지에 대해 개발 영역을 중심으로 공유하고자 한다. 또한 이러한 변화의 과정을 겪고 회고를 진행하면서 다시 이런 과정을 밟는다면 기술 부채를 최소화하기 위해서 어떤 설계를 했을지 또 지금은 어떤 설계를 하고 있는지에 대한 내용을 같이 전하고자 한다.
팀장님의 팀원으로 누군가 지원한다면 무슨 이야기를 해주고 싶은가?
먼저는 새로운 것에 대한 거부감이 없고 동료들과 의견을 나누는 것에 거리낌이 없기를 기대한다. 백엔드 개발팀에서는 한 명 한 명이 각 크루의 핵심 도메인을 담당하고 있다. 그래서 기술 선택에 있어 자유도가 높은 편이다. 목적을 위해 알맞은 기술을 선택할 수 있는 것은 규모나 아키텍처에 대한 영향이 크다. 그러나 그 모든 것에 긍정적인 영향을 줄 수 있는 배경은 새로운 것에 대한 수용과 동료들과 그것을 나누고 발전해 나가는 문화다.
다음으로 솔직한 피드백을 주고받고 같이 성장하며 목표를 달성하는 것이다. 일반적으로 개발팀에서의 피드백은 코드 리뷰, 아키텍처 리뷰, 디자인 리뷰 같은 정형화된 형식이 있다. 또한 페어 프로그래밍이나 토론 혹은 면담과 같은 정형화되지 않은 형태의 피드백도 있다. 이러한 피드백은 노하우를 공유하고 서로의 고민을 덜어줄 때 더 쉽고 더 빠르게 목표에 도달할 수 있는 수단이 된다.
다만 솔직한 피드백을 주고받는 것을 매번 긍정적인 결과로 이어지게 하는 작업은 쉬운 일이 아니다. 이는 피드백을 주고받는 수단이나 방법이 정형화되어 있더라도 마찬가지이다. 관계란 구성원 간 신뢰, 상호 간의 감정 및 업무 및 개발 일정 등 여러 가지 요소들에 영향을 받는다. 상대방을 신뢰하고 부드럽게 피드백을 줄 수 있고 방어적이지 않고 열린 마음으로 다른 사람의 피드백을 받아들일 수 있는 자세가 있어야 한다.
끝으로 '가치'를 만드는 것에 즐거움을 찾을 수 있기를 바란다. 이 자리에 오기 전까지를 돌아보면 개발자가 매우 많은 대기업에서 반대로 단 4명이서 일하는 아주 작은 스타트업을 거쳤다. 그런데 빅픽처인터렉티브에 오기 전까지는 어디에서든 '가치'보다는 순수 엔지니어링에서 성취감을 느끼고 즐거움을 찾으려고 했다. 그로 인해 때로는 비즈니스와 동떨어진 개발을 할 때도 있고, 역설적이게 순수한 개발적인 측면에서도 재사용이 불가능한 설계 또는 오히려 효율적이지 않게 되는 설계를 할 때도 있었다.
이곳에 와 동료들과 함께 레벨업지지를 만들면서 '가치 있는 서비스를 만드는 것'에서 즐거움을 찾을 수 있게 되었다. 돌이켜보면 그동안 작업해 왔던 서비스들에게는 공감이나 신뢰가 부족했기 때문에 다른 곳에서 즐거움을 찾으려고 하지 않았나 하는 생각이다. 우리 서비스에 공감하고 '가치'를 만드는 것에 즐거움을 느끼게 되면서 반대로 순수하게 개발적인 측면에서도 더 많은 부분을 고려할 수 있게 되었다. 출근의 즐거움을 되찾을 수 있었다.
댓글