3분기부터 본격적으로 플랫폼 팀을 리드하면서 개발뿐만 아니라 디자인, 기획, 데이터까지 함께 살펴보게 되었다. 리더 미팅에서는 우리 팀이 어떤 성과를 내고 있는지, 서비스를 유지하기 위해 얼마나 비용을 쓰고 있는지 공유해야 했다. 배포 일정을 지키는 것에 더해 프로젝트에서 세운 가설을 어떻게 검증하고 있는지, 배포 이후 유저가 어떤 행동을 보이는지, 앱을 사용하다가 어디서 많이 이탈하는지도 알아야 했다.
책임지는 범위가 넓어지면서 부담도 커졌다. 이런 내용을 제대로 파악하고 팀이 더 높은 수준으로 일하려면, 우선 필요한 정보를 볼 수 있는 환경부터 갖춰야겠다고 생각했다.
그래서 기기의 고장률을 낮추기 위해 기기 관측 시스템을 만들었고, 기획자와 디자이너가 데이터를 직접 살펴볼 수 있도록 메타베이스를 도입했다. 서버에는 그라파나를, 앱에는 센트리를 도입했다. 당시에는 이렇게 도구를 갖추면 팀원들이 문제를 더 쉽게 파악하고 대응할 수 있을 거라고 생각했다.
하지만 예상과 다르게 일부 도구는 잘 사용되지 않았고, 유지보수 비용은 꾸준히 늘어났다. 팀원들에게 사용을 권하고 대시보드도 직접 만들어줬지만, 기기 관측 시스템은 일부 기능만 사용했고 메타베이스도 기대만큼 활용하지 않았다. 반면 개발자들은 도입한 도구를 잘 사용하고 있었다.
단순히 비개발자가 새로운 도구를 익히는 데 더 어려움을 느껴서라고 생각할 수도 있었다. 하지만 그렇게만 보면 사용을 계속 권하는 것 외에는 할 수 있는 일이 없었다. 이미 들인 비용에 매달리지 않고 팀원들의 일을 줄이려면, 같은 도구 도입인데 왜 다른 결과가 나왔는지 돌아봐야 했다.
생각해보니 개발자에게는 당장 필요한 도구를 주었지만, 기획자와 디자이너에게는 종이를 자르는 데 가위나 칼이 필요한 상황에서 문서 재단기를 준 셈이었다.
문서 재단기를 쓰면 많은 종이를 한 번에 빠르게 자를 수 있다. 하지만 잘라야 할 종이가 몇 장 없거나 저마다 다른 모양으로 잘라야 한다면, 오히려 준비하는 데 시간이 더 걸리고 불편할 수 있다. 내가 생각한 도구의 장점과 팀원들이 실제 업무에서 느끼는 편리함은 달랐다.
반대로 서버나 앱 개발자는 “OO 기능이 안 돼요”라는 문의만으로 문제를 찾아야 할 때가 많다. 문의조차 남기지 않고 이탈하는 유저도 있다. 문제가 발생했는지 수시로 확인하고 원인을 추적할 수 있어야 했기 때문에, 관측 도구가 업무에 바로 도움이 되었던 것이다.
이 차이를 돌아보면서 도구를 고를 때 팀원들이 지금 어떤 문제를 겪고 있는지, 그 도구를 업무에 활용하려면 무엇이 더 필요한지 충분히 살펴보지 못했다는 생각이 들었다.
함께 자라기
메타베이스도 도입하고 대시보드를 만들어주는 것만으로는 충분하지 않았다. 데이터를 볼 수 있게 된 뒤에도 어떤 지표를 살펴봐야 하는지, 그 숫자를 어떻게 해석하고 다음 행동으로 옮길지 판단하는 과정이 남아 있었다.
아무리 좋은 데이터와 대시보드가 있어도 이를 읽고 해석할 수 없다면 말짱 도루묵이다. 관측 시스템도 마찬가지다. 지표를 잘 수집하고 알림을 설정해두더라도, 누군가 확인하고 의미를 해석한 뒤 조치해야 한다. 도구를 갖추는 데 집중하느라 그 도구로 함께 일하는 방법을 익히는 과정은 충분히 챙기지 못했다.
그렇다면 이런 도구를 잘 쓰는 사람을 뽑으면 해결될까? 단기적으로는 도움이 되겠지만, 채용만으로 해결할 수 있는 문제는 아니라고 생각했다. 회사마다 도메인과 비즈니스가 다르고 중요하게 보는 지표도 다르기 때문이다. 도구를 다룰 줄 알아도 우리 서비스에서 무엇을 보고 어떻게 판단해야 하는지는 함께 익혀야 한다.
그래서 각자의 업무 안에서 필요한 지식을 익히고, 서로의 생각을 나눌 수 있는 자리를 만들기 시작했다.
백엔드 인턴들과는 주기적으로 테크 밋업을 하고, 코틀린 전환을 준비하면서 『코틀린 인 액션』으로 스터디를 진행했다. 언어의 차이에서 어떤 이점을 얻을 수 있는지, 코드를 작성할 때 무엇을 유의해야 하는지, 좋은 코드는 어떤 코드인지 이야기를 나눴다. 테크 밋업에서는 서로 맡은 프로젝트의 도메인을 공유하면서 전체 서비스의 흐름을 이해하고, 기술적으로 어떤 방향으로 나아가야 할지 논의했다.
아직은 내가 경험과 지식을 전달하는 탑다운 방식의 비중이 크다. 그래도 배운 내용을 조금씩 흡수하고, 왜 이렇게 설계하고 개발하는지 생각하는 연습을 하면서 각자의 의견이 나오기 시작했다. 내가 보지 못한 관점을 팀원들이 이야기해줄 때도 있다. 그렇게 함께 자랄 수 있는 환경을 만들어가고 있다.
기획자, 디자이너와는 성윤님의 데이터 리터러시 강의로 스터디를 진행했다. 데이터를 분석하는 방법을 배우면서, 같은 데이터를 각자 어떻게 해석했는지도 공유했다.
이전에는 어떤 기능의 리텐션이 떨어지면 “유저가 관심이 없는 것 같다”는 이야기로 끝나곤 했다. 이제는 어떤 성향의 유저가 관심을 보이고, 어떤 패턴으로 기능을 사용하는지까지 이야기한다. 반대로 관심을 보이지 않는 유저는 어떤 특성이 있는지 살펴보고, 이들을 위해 어떤 액션을 할지도 함께 제안한다.
애드몹 광고가 노출되지 않는 문제를 바라보는 방식도 달라졌다. 예전에는 광고 물량이 없어서 노출되지 않았다고 생각했다면, 이제는 광고가 송출되는 방식과 우리 기능의 구조를 함께 살펴본다. 그 구조에서 왜 문제가 생겼는지 설명하고, A안과 B안으로 실험해 특정 지면부터 결과를 확인한 뒤 확대하겠다는 계획까지 이야기할 수 있게 되었다.
같은 문제를 두고 나누는 이야기에 깊이가 생겼다. 이런 변화를 보면서 팀원들이 많이 성장했다는 걸 느꼈다. 동시에 내가 기대했던 변화에도 함께 배우고 익숙해질 시간이 필요했다는 생각이 들었다.
해결 방법만큼 순서와 속도도 중요하다
처음 도구를 도입할 때는 좋은 방법을 알려주면 자연스럽게 업무 방식도 바뀔 거라고 생각했다. 하지만 팀원들은 이미 하던 일을 계속하면서 새로운 도구까지 익혀야 했다. 내가 기대하는 모습에 빨리 도달하려고 할수록, 팀원들에게는 해야 할 일이 더 늘어나는 셈이었다.
회사마다 오랫동안 유지해온 업무 방식이 있고, 그 방식으로 일하게 된 배경도 있다. 더 좋은 기술이나 방법이 나와도 쉽게 바꾸지 못하는 이유는 저마다 다르다. 바꿀 필요를 느끼지 못할 수도 있고, 시간이 조금 더 걸리더라도 익숙한 방식이 편할 수도 있다. 바꾸는 데 드는 시간과 비용이 부담스러울 수도 있다.
물론 익숙하다는 이유로 계속 같은 방식으로 일하다 보면 비효율적인 과정을 불편하게 느끼지 못할 때도 있다. 그래서 회고를 통해 우리가 한 일과 성과를 돌아보고, 어떻게 하면 더 잘 일할 수 있을지 살펴보는 시간이 필요하다.
다만 개선이 필요하다는 것과 지금 바로 바꿀 수 있다는 것은 별개의 문제였다. 조직이 적응하는 속도보다 빠르게 바꾸거나, 바꾼 뒤에 일이 더 느려지고 불편해진다면 다음 시도에 대한 거부감도 커질 수 있다. 내가 도구를 도입하면서 겪었던 어려움도 여기에 가까웠다.
이후 한 팀원이 AI를 사용하는 모습을 보고, 크롬 도구와 스킬을 연동하는 방법을 알려준 적이 있다. 지금 하던 작업을 좀 더 편하게 할 수 있는 방법을 알려주자, 이후에는 적극적으로 AI를 활용하기 시작했다. 앞서 도구 사용을 계속 권하던 때와는 반응이 달랐다. 당장 하고 있는 일에 도움이 되니 자연스럽게 사용으로 이어졌다.
이 경험 이후로는 도구를 더 많이 사용하게 만드는 데 집중하기보다, 팀원들이 지금 어떤 일을 어렵게 하고 있는지 먼저 살펴보려고 했다. 반복해서 겪는 문제가 있다면 그때 필요한 방법을 찾고, 바꾸는 과정에서 생길 부담도 함께 고려하기로 했다.
모노레포 전환도 그런 문제에서 출발했다. 백엔드에서는 서로 다른 레포에서 연관된 작업을 하다 보니 PR이 나뉘고, CI도 각각 돌아가면서 깃허브 액션의 사용 한도가 빠르게 소진되고 있었다. AI를 적극적으로 사용하면서 레포마다 하네스와 작업 히스토리를 다르게 관리하는 문제도 생겼다. 토큰 소모가 많아지고 컨텍스트가 충돌하기도 했다.
이를 해결하기 위해 레포를 모노레포로 통합했다. 모듈러 모놀리스와 멀티 모듈도 고려했지만 바로 도입하지는 않았다. 멀티 레포에서 모노레포로 옮기는 것만으로도 각자의 개발 환경과 작업 방식을 바꿔야 했기 때문이다. 테크 세션에서는 개념과 앞으로의 방향을 공유하고, 우선 모노레포에 적응할 시간을 가졌다. 실제로 통합 직후부터 매끄럽게 돌아가지는 않았고, 사용하면서 생기는 문제를 하나씩 보완했다.
레포를 통합한 뒤에는 작업에 필요한 맥락을 함께 관리하는 쪽으로 개선을 이어갔다. LLM 위키를 도입해 각자 다른 작업을 하더라도 공통된 맥락을 참고할 수 있도록 개발 문서를 정리했다. 아직 토큰 소모량이나 작업 속도의 변화를 측정하지는 못했지만, 현재 사용하는 팀원들의 반응은 긍정적이다.
처음 기대만큼 사용되지 않았던 메타베이스도 같은 관점에서 다시 살펴보고 있다. 실제 담당자들과 인터뷰하면서 어떻게 사용하고 있고 어떤 부분이 어려운지 듣고 있다. 이를 바탕으로 데이터를 쉽게 이해할 수 있는 위키를 만들고, SQL을 잘 모르더라도 데이터 모델 문서를 참고해 AI로 필요한 대시보드와 지표를 구성할 수 있도록 준비하고 있다.
이렇게 업무 방식을 조금씩 개선하다 보니, 그 과정에서 하는 일을 서로 알 수 있게 남기는 것도 필요했다. 새 기능은 결과가 눈에 보이지만, 에러율을 낮추거나 운영 중 발생한 이슈를 해결하는 일은 비즈니스에 큰 영향을 주지 않는 이상 다른 직군에서 자세히 살펴보기 어렵다. 그래서 매주 각자 한 일을 공유하면서, 기능 개발과 함께 서비스를 안정적으로 유지하기 위해 어떤 일을 했는지도 기록하기로 했다.
잔 하나에 넘치지 않게 하기
팀이 일하는 방식을 돌아보는 동안, 나 자신이 일하는 방식도 함께 돌아보게 되었다. 팀원들에게 적응할 시간이 필요했던 것처럼, 나에게도 넓어진 역할을 감당할 여유가 필요했다. 하지만 당시에는 우리 팀이 성과를 내고 필요성을 증명해야 한다는 강박이 앞섰다.
퇴근한 뒤에도, 출근하기 전에도 어떻게 팀을 이끌어야 할지, 어떤 일을 해야 할지 계속 생각했다. 그러다 보니 팀원들이 해야 할 일에 내가 개입하거나 대신 처리하는 일도 종종 생겼고, 점점 부하가 쌓였다. 도구가 잘 사용되지 않자 대시보드를 직접 만들어주던 것도 이런 마음과 연결되어 있었던 것 같다.
제대로 쉬지 못하니 여유도 없어졌다. 숲보다 나무만 보고 결정할 때가 있었고, 예상한 대로 일이 진행되지 않거나 결과가 나오지 않으면 스트레스도 많이 받았다. 그 과정에서 팀원들에게도 압박을 줬던 것 같다.
그래서 의도적으로 부담을 조금 내려놓고, 회사 일에서 떨어져 있는 시간을 만들어야겠다고 생각했다.
한편으로는 요즘 분위기를 보면서 회사 밖에서도 스스로 설 수 있어야겠다는 마음이 들었다. 별도의 안정적인 수입을 만들어보고 싶어 게임을 만들기 시작했다. 여전히 개발하는 일이지만, 회사 업무와는 다른 곳에 관심을 두게 되었다.
악기도 배우면서 개발에서 아예 떨어져 있는 시간도 만들고 있다. 관심을 두는 일이 늘어나니 이전보다 강박이 줄었고, 생활에도 조금씩 활력이 생겼다. 운동도 전보다 꾸준히 하게 되는 것 같다.
마무리
이렇게 팀과 내가 일하는 방식을 돌아보던 중, 최근 조직이 바뀌면서 플랫폼 리더에서 테크리드로 역할이 변경되었다. 플랫폼 리더 역할을 못해서 바뀌었다기보다는, 개발을 책임지는 역할과 제품을 기획하는 역할이 상충하는 순간이 있었고 책임과 권한의 경계를 나누기도 어려웠다. 이번 변화로 나도 부담을 조금 덜게 되었다.
이제는 제품을 더 빠르고 안정적으로 출시하는 데 힘을 쏟을 수 있게 되었다. 내 전문성을 발휘할 수 있는 영역이라 이전보다 자신감을 가지고 리드 역할을 할 수 있을 것 같다. 그 안에서도 팀원들이 겪는 어려움을 먼저 살펴보고, 함께 적응할 수 있는 속도로 바꿔가려고 한다.
직접 제품을 기획하고 사용자 관점에서 전략을 세워본 경험도 남았다. 지금 부업을 하거나 게임을 만들 때 그 경험의 도움을 받고 있고, 개발 실무 안에서 바라보던 시야도 넓어졌다. 앞으로 어떤 일을 하고 싶은지, 다음 커리어를 어떤 방향으로 가져갈지 생각할 때도 이 시간이 도움이 될 것 같다.