미국 개발자 일지: 벌써 새로운 팀에서의 두 달
적응 중에 있습니다
벌써 새로운 팀에서 일을 시작한 지 두 달이 되어간다.
첫 3주는 온보딩(onboarding)으로 이 팀의 디자인 아키텍처 다큐먼트부터 여러 온보딩 목록들을 끝내며 시간을 보냈다. 4주 차가 되었을 때 팀에서 이제 막 API 디자인 다큐먼트가 완성되어 가는 프로젝트 첫 지라(jira) 태스크를 맡았다.
그로부터 한 달 뒤인 현재,
자연스레 이전 팀과는 다른 분위기의 현재 팀을 체득해 가는 중이다. 여러 차이점이 있는데 크게 매니징, 미팅, 프로젝트 진행 스타일로 세분화된다.
1. 매니징
제일 큰 차이점은 매니징이었다.
이전 팀의 매니저는 팀 미팅(sync up meeting)을 주도하면서 각각의 엔지니어에게 맡겨진 태스크에 대해 정확한 기한과 혹시나 막힌 사항이 있다면 그것에 대해 자세하게 논의했다. 현재 팀의 매니저는 미팅을 할 때 외부 팀과의 협업 관련 티켓의 진척도 외에는 별다른 피드백을 주진 않는다.
그래서인지, 이번 팀에서 일을 하면서 챗GPT(chatGPT)가 완전히 모든 걸 대체할 수 없다는 걸 다시금 실감했다. 엔지니어에게 적당한 당근과 채찍을 주는 중간관리 매니저는 언제나 꼭 필요하다는 것을. 단지 그 중간관리 매니저의 수는 지금보다 줄어들고 보다 정확한 관리를 하는 사람이 필요하겠지만. 그래서 이전 팀에서 만난 매니저들이 얼마나 팀을 잘 관리하고 프로젝트가 효과적으로 진행될 수 있도록 하는지 더 극명하게 보였다.
2. 미팅
그다음은 매일 경과보고 미팅(sync up meeting)의 차이다.
이전 팀은 각각의 엔지니어가 맡겨진 태스크에 온전히 시간을 쏟아붓기 위해 미팅을 간소화했다. 그래서 주 2회가 전부였고 미팅 시간을 효율적으로 하기 위해 미팅 전에 서로에게 맡겨진 태스크와 막힌 사항에 대해 팀 공통 다큐먼트(confluence page)에 미리 올리고 막힌 사항들만 논의하는데 시간을 보냈다. 지금 미팅은 약 8명의 엔지니어가 주 4회 경과보고 미팅(sync up meeting)을 하고 어떨 때는 맡겨진 태스크 내용을 반복하는 보고사항이 많다.
3. 프로젝트 진행 스타일
이전 팀에서도 완전히 새로운 API를 빌드업하는 프로젝트에 속했어서 일의 진행상황을 처음부터 끝까지 볼 수 있었다. 그때 당시 중요한 아키텍처 안건사항은 Principal/시니어 엔지니어가 논의를 했고 밑에 주니어 엔지니어들은 이미 결정된 내용을 가지고 코드 변경을 진행했다. 그러나 이번 팀은 디자인 아키텍처 회의가 진행되는 것과 동시에 코드 변경이 이루어지고 있다. 코드 변경을 해야 되는 세부 컴포넌트도 완벽히 분리가 안 되기 때문에 다른 엔지니어와 협업을 할 때 git rebase, git pull을 계속해야 함과 동시에 때로는 그 과정에서 오는 에러(conflict error)를 해결하는데 시간을 보내는 경우가 더 많다
그 외에는 코드 리뷰를 해 주는 속도, 협업할 때의 스타일 등의 차이가 있었다.
이미 그전 팀의 스타일에 적응해서 그런 거겠지만, 여러 가지 면에서 '조금 더 효율적으로 일을 진행할 수 있지 않을까'라는 의문이 생겼다.
무엇보다 '이 팀에서의 매니저의 역할은 뭐지'라는 고민도 했다. 특히 협업에서 오는 느린 피드백을 개선해야 하는 상황일 때가 그러했다.
내 선에서는 PR(Pull Request)을 이미 했고 다른 엔지니어들의 코드 리뷰(code review)만 남은 상황이었다. 두 명의 코어 엔지니어에게 리뷰를 부탁했는데, 엔지니어 A는 코드 리뷰를 해주고 마지막으로 엔지니어 B의 코드 리뷰만 남았다. 엔지니어 B가 내가 만든 코드 변경과 관련해서 이전에 많은 경험이 있기에 엔지니어 A가 엔지니어 B를 태깅하며 코드 리뷰를 해줄 것을 다시 한번 부탁했다. 그러나 엔지니어 B에게 2-3일이 지나도 코드 리뷰가 이루어지지 않았다. 그 엔지니어한테 DM 도 보내고 매일 경과보고(Sync up meeting)에서도 여러 번 언급했지만 그 당시에는 알겠다고 하고선 (아무래도 그분도 여러 미팅에 계속 들어가야 되고 하는 일이 많아서 그런지) 상태는 그대로였다.
결국 4일째 되는 날, 매니저한테 DM을 보내 엔지니어 B에게 코드 리뷰를 할 수 있는지 다시 한번 요청했다. 매니저는 다음날이 되어서야 팀 채널에 그저 내가 코드 리뷰를 받았는지 물어봤다. 그제야 엔지니어 B가 내 코드 변경이 아직 WIP(진행 중의 줄임말, work in progress)인 줄 알았다며 알겠다고 했지만, 하루가 또 지나갔고 결국 1:1 미팅에서 내가 그 자리에서 직접 리뷰를 부탁해 드디어 일주일 만에 리뷰를 받을 수 있게 됐다.
이런 비슷한 상황들을 계속 겪으며 어느 날은 답답한 나머지, 프로젝트에 제대로 참여한 지 2주째 되는 날 다른 principal engineer에게 이런 사항에 대해 질문을 했다. 친절한 Principal engineer은 그래도 당돌할 수 있는 나의 질문들에 대해 따로 답변을 해주고 1:1 미팅까지 잡아 함께 의논하는 시간을 가졌다.
Principal engineer가 설명해 준 내용은 다음과 같다.
“언제나 디자인이 완벽하게 끝난 자체에서 프로젝트가 이루어지지는 않는다. 그게 agile project의 의미 아니겠느냐. 물론 중간중간 바뀌는 것에서 어려움은 있지만 그 과정에서 우리가 그전에는 알아차리지 못했던 것들을 알게 되는 경우도 있다. 오히려 모든 걸 완벽하게 한 상태에서 일을 진행하려고 하면, 나중에 더 큰 문제가 생길 수 있다.”
또한 엔지니어 B와 협업하는 것에서 오는 더뎌짐도 나와 1:1 미팅을 한 엔지니어는 일단 엔지니어 B의 리뷰가 남은 부분에 대해서는 그대로 두고 현재 일에만 집중한 뒤, 그 리뷰가 남은 부분도 현재 branch에 merge 한 다음, 언제나 코드 변경이 생기면 현재 branch를 up-to-date 하는 방향으로 할 것을 제안해 줬다.
그리고 자신도 내 질문을 그 전날 받고 곰곰이 생각해 보기를, "우리가 더 API 리뷰를 더 많은 사람들에게 받았으면 좋았을 것 같다"라고 인정했다. 단지 다들 너무 바쁘기에 어느 정도 API 다큐먼트가 진척이 된 상황에서 해야 되므로 그 시점을 정하는 것이 언제나 고민이라는 부분도 나눠줬다.
경과보고 미팅(Sync up meeting)에 대해서도, 물론 내가 제안한 방식처럼 미팅 이전에 서로가 어떤 상태이고 막히는 점은 없는지를 미리 적을 수도 있지만, 뭐든 건 다 장단점이 있다고도 설명해 줬다. 어떤 엔지니어들은 그걸 아예 보지 않기도 하고, 그렇기에 경과보고 미팅(sync up meeting)에서 서로가 무엇을 하고 있는지 나누는 거 자체가 어찌 보면 새롭게 배울 수 있는 단계(learning curve)에 좋다는 설명도 덧붙였다.
Principal engineer와 약 1시간 반의 1:1 미팅을 마치고 그동안 고구마 같았던 상황에서 사이다를 마신 듯한 해소를 맛봤다. 여전히 일의 진척도 면에서는 별로 효율적이지 않다는 생각은 있었지만, principal engineer의 말처럼 뭐든지 장단점이 있고 서로 다 노력하고 협업하는 상황에 나만 궁시렁 댈 수는 없는 노릇이었다. 무엇보다 당돌하고 버릇없을 수 있는 주니어 엔지니어의 질문을 귀담아듣고 소중한 시간을 내어 하나하나 설명해 준 principal engineer에게 고마웠다. 리모트로 일해서 얼굴 한 번 제대로 본 적이 없지만, 이런 팀원들과 일할 수 있는 건 큰 행운이다.
각각의 정해진 역할 속에서 자신이 맡은 일에 더해 나는 더 큰 기여를 하고 싶은 욕심이 있었다. 내가 이전 팀에서 이 새로운 팀으로 투입된 것도 그런 이유에서 일 거라는 짐작에서였다. 그러나 무언가 새로운 안건을 제안해도 때로는 잊히거나 현상 유지를 하는 분위기 속에서 적절한 타협점을 찾는 중이다. 분명히 이 속에서도 무언가를 배우게 될 테니. 내게 맡겨진 일들을 잘 마무리 짓고, 어떻게 하면 더 효율적으로 의사소통할 수 있는지를 계속 모색해 나가야지.
