4년 9개월의 연구개발팀 생활 회고 🧑🏻🔬 (2부)
혼돈의 시기였다 🤨
데브렐과 관련해서 내 경험을 회고하고 있지만, 간략한 회고 안에 담기는 내용은 다소 지엽적일 수 있다. 하지만 10명 안팎의 팀에서 대내외적으로 변화를 겪던 팀이 자체적으로 개발 문화를 유지하고 적응하려던 순간들에서 얻을 인사이트는 적지 않다.
우리 팀 안에서 규칙과 개발 문화를 새로운 업무와 새로운 사람들에 맞춰서 다시 만드는 과정이 필요했다. 구 팀장님의 여러가지 노력과 시행착오 끝에 내가 들어갔을 때 정도의 팀 문화가 남아있는 정도였다. 팀 멤버들은 대부분 함께 최소 4-5년 이상을 지내온 사이였고, 그들은 이미 공통의 원칙이 익숙한 상태였다. 팀 차원에서나 회사 차원에서 변화의 과도기를 거치던 시기였고 특히 개발자 개인의 성장의 계기나 기회가 만들어지지 않는 환경이었다. 기존의 스크럼 스프린트, 회고 회의, 일일 회의, 위키 페이지(문서) 공유, 팀 기술 세미나 등이 새로운 방식으로, 새로운 동력으로 굴러가야 하는 상황이었다.
사실 입사 초기에는 일일 회의(daily reflection)가 무엇보다 싫었다. 일일 회의는 업무 시작 전 가벼운 분위기(커피나 다과와 함께☕️🍪)에서 크게 두 가지 사항을 팀 전체와 공유하는 자리였다. 크게 두 가지 사항을 공유한다. 지난 워킹 데이에 진행한 이슈와 문제사항 그리고 오늘 할 작업에 대해서 말한다. 그 자리가 내키지 않았던 건 당시의 부족했던 나의 소셜 스킬 탓도 있었지만, 이 활동의 목적과 방향성을 제대로 이해하지 못한 부분도 컸다. 신입 때 일의 모양이나 내용이 빈약했던 것과는 별개로, 어떤 목적을 가지고 이것을 하는지(WHY) 알지 못한 상태로, 그냥 기존의 방식에 형식상 녹아드는 모습이 되었다.
기존 팀원들도 오랫동안 해오던 루틴이 거의 형식만 남아있다는 사실을 다들 알고 있었다. 기존에는 동일한 엔진에서 여러가지 모듈과 파생되는 연구개발을 가지고 접점이 많았던 것과는 달리 이제는 팀 안에서 파트가 나뉘고 서로 다른 기술과 도메인을 다루게 되었다. 그렇게 팀원들은 이런 고충을 나누고, 팀 내 문화를 위한 방식들을 여러가지로 시도하게 되었다.
이렇게 저렇게 시도해보는 것도 의미가 있다 🧶
팀 내 개발 문화적 프로세스와 방식의 변화하고자 했던 시도를 무작위로 나열해본다.
- 일일 회의가 조금 비효율적이야: 출근하고 나서보다는 퇴근하기 N분전에 모여서 시간을 정하고 빠르게 공유하는게 어떨까?
- 파트가 나눠졌는데 굳이...?: 각 파트별로 별도로 이슈를 공유하고, 팀 전체 스프린트에서는 중요 이슈만 정제해서 공유하는게 어떨까?
- 기술 도입을 위한 공부는 같이!!: 각자 공부하는 것보다 정해진 시간, 같은 자료를 보고 튜토리얼, 과제를 같이 스터디해보자
- 회고가 너무 늘어진다: 회고 회의를 2-3일까지 하는 것이 정말 의미가 있는 것일까? 자신의 경험과 배운 점을 정리해서 공유하는 개인과 팀에게 도움이 된다는 믿음은 변함없지만, 더 효율적으로 진행할 방법은 없을까? 일단 파트별로... 😇
- 다른 팀은 뭘 연구개발해요?: 최소한 실 단위로는 공유될만한 가치가 있는 기술 내용은 정기적으로 세미나를 하고 테크 토크를 하자
팀 내에서는 이런 이슈들에 대한 방법적, 가치적 고민을 자주 하고 의견을 나누는 자리를 여러 번 가졌다. 그런 과정을 거치면서 나 스스로도 기술 자체에 대한 이슈보다도, 팀 내에서 자구적으로 개발 프로세스와 규칙 그것을 아우르는 팀 문화(작은 규모지만)에 대해 스스로 물음표를 깊이 파고드는 시간이 쌓여갔다.
사람을 조금씩 변화시켜야 문화가 정착한다 🐈
3-4년차에 접어들면서 팀원 한 명으로 인해 큰 의문이 생겨났다.
개발자들은 어떻게 움직일 수 있을까? (동기부여)
나와 1년 차이를 두고 들어왔던 팀원이었다. 1년 차이임에도 불구하고 나와는 다르게 팀 내 개발 문화와 맞지 않는 태도가 눈에 띄기 시작했다. 그 팀원도 팀에서 최소한 유지하고자 하는 팀 내 규칙과 가치를 분명히 이해한다고 생각했다. 하지만 방식이 계속 수정되더라도 유지되오던 팀원들의 공유 활동/공유하는 자세 등과 달리 '공유하는 것'을 다소 꺼리는 모습이 목격되었다. 그런 태도에 의문점이 더 커졌던 건, 팀 내 회의에서는 먼저 의견을 내거나 자신의 경험을 공유하는 일이 적었던 모습과 달리 사석에서는 말을 잘 하는 모습이 대비되었기 때문이었다. 공동의 규칙과 문화 안에서 가치있는 정보나 인사이트를 공유하는 일을 의미있게 여기는 사람으로서, 그런 모습이 이해가 쉽게 되지 않았다.
그 때부터는 단순히 나를 포함한 개발자라는 정체성을 가진 사람에 대한 궁금증이 깊게 자리잡았다. 팀을 구성하는 개개인으로서 자율성은 존중하면서 어떻게 하면 공통의 규칙과 문화를 이루는 일원으로서 융화시킬 수 있을까? 라는 고민도 해보게 되었다. 개발자라는 전문가/엔지니어/기술직의 특성에 대해서 나를 들여다보면서 이해해보려고도 했다. 게으르지만 self-motivated 되면 지적 호기심의 열정에 불을 지피는 개발자라는 사람. 팀과 기업의 지속적인 성장과 동기부여를 위한 문화 정착에는 개발자라는 플레이어가 개발 문화 안에 안착할 수 있도록 어떤 형태로든지 지원해주고 가이드해주는 프레임워크가 필요하지 않을까? 라는 고민을 하면서 첫 회사 생활의 마무리를 짓게 되었다.
