[실무를 잘하면 문제가 안 보인다]

매니저가 실무를 잘하면 문제가 해결되는 게 아니라, 문제가 안 보이게 된다. 이번 주에 내가 정확히 그 실수를 했다.

스타트업에 개발팀장으로 채용됐지만 여전히 실무 비중이 높고, 불과 얼마 전까지 실무만 파던 사람이다 보니 늘 경계하던 지점이 있었다. 매니징이 익숙지 않아 도망치고 싶을 때, 가장 자신 있는 실무 속으로 숨어버리는 것. 이번 주에 그 우려가 현실이 됐다.

[답답하면 본인이 뛰라는 말을 너무 잘 따랐다]
이번에 로드맵을 제시하면서 코멘트 기능과 버전 관리 기능의 일정을 잡았다. 내 판단으로는 이 기능들은 빠르게 나가는 것이 중요하지 섬세하게 검토를 거친 뒤에 나갈 필요는 없었다. 문서에 코멘트를 달 수 없고 버전 관리가 안 되는 상황 자체가 문제라고 생각했기 때문이다. 일단 해소만 하면 다음에는 나간 다음에 수정하면 된다. 그래서 그냥 내가 작업을 해서 내 기준으로는 적당히 ‘동작은 하네’라는 수준에서 내보냈다.

나는 ‘속도’라는 명분 뒤에 숨어 독단적으로 움직였다.

팀원들에게는 끊임없는 공유를 요구하면서, 정작 나는 “답답하니 내가 빨리 끝내겠다”는 오만한 판단으로 소통을 생략했다. ‘이 기능들은 지금 당장은 완성도보다 존재 자체가 중요하니까 빠르게 내보내겠습니다, 그러니 작업 시작할 테니까 받아서 확인해 주세요.’ 이런 과정이 없었기에 팀원들은 이 기능들이 훨씬 더 잘 나갔어야 하는 부분이 아니었나 하는 생각을 했고, 불안하다는 이야기를 했다.

내가 팀원들에게서 작업 상황이 공유되지 않으면 불안하듯, 나는 동시에 실무자이면서 내가 하겠다는 부분에 대한 태클을 걸 수 있는 사람이 실질적으로 없기 때문에 내가 하는 일에 대해 더 적극적으로 공유를 할 필요가 있다. 권한이 클수록 설명의 의무도 크다는 당연한 사실을 망각한 채, 내 작업에 아무도 태클을 걸 수 없다는 상황을 오히려 방종의 기회로 삼은 꼴이다.

[두 레일이 만나지 않으면]

우리 팀은 현재 두 가지 트랙으로 움직이고 있다. 첫 번째는 현재 제품의 수준을 끌어올리기 위한 정식 출시용 기능 개발이다. 다른 제품들에는 있는데 우리 제품에는 없으면 안 되겠다 싶은 것들을 채워 넣는 작업으로, 이번에 추가한 버전 관리와 코멘트 기능이 여기에 해당한다. 이쪽은 로드맵도 완성돼 있고 해야 할 일이 비교적 명확하다.

두 번째는 제품의 미래를 위한 신규 기능 기획이다. 어떤 기능이 들어가면 좋을지 알기 위해서는 별도의 인터뷰도 하고, 섬세한 시나리오와 타겟 고객군에 대한 가설도 수립해야 하며, 중간 단계에 만들어서 검증하기 위한 기획이 필요하다. 이 작업을 별도로 한 팀원이 진행하고 있었는데, 문제는 두 트랙이 너무 분리돼 있다 보니 서로의 진행 상황이 공유되지 않고 있었다는 점이다.

특히 그 팀원이 인터뷰를 10건 정도 진행하면서 얻은 인사이트를 기반으로 기획서를 작성했는데, 내가 그 사실 자체를 인지하지 못하고 있었다. 매니저가 팀원의 주요 작업물을 파악하지 못하고 있다는 건 업무 프로세스에 심각한 구멍이 났다는 뜻이다. 내가 실무의 재미에 빠져 혼자 달리는 동안, 팀원들은 안개 속을 걷는 기분이었을 것이다.

[해결책이라고 부를 수 있을까]

논의 끝에 몇 가지 해결책이 나왔다.

첫째, 아마존의 Working Backwards에서 press-release를 먼저 쓰는 것과 비슷하게, 개발 사이클이 시작될 때 배포 시점의 공지사항을 미리 작성하기로 했다. 그리고 사이클이 끝나면 회고를 매번 진행한다. 작업 전에 무엇을 할 것인지, 끝나고 나면 무엇이 됐는지를 명확히 공유하는 것을 통해 불일치를 줄이고자 하는 것이다. 사실 이 아이디어는 팀원이 먼저 제안해 줬는데, 듣는 순간 적극적으로 동의했다.

둘째, 기획 담당 팀원의 작업도 기존에 개발팀이 사용하던 프로젝트 트래킹 툴에 올리기로 했다. 기획서가 필요한 작업인지, 바로 진행해도 되는 작업인지에 대한 판단 프로세스도 함께 정리했다. 긴급한 작업이라면 바로 이슈를 배정하고, 검토가 필요한 작업이라면 기획서를 먼저 작성해서 피드백을 받은 뒤에 후속 작업을 진행하는 식이다. 기획서에 지나치게 시간을 들이기보다는 핵심 위주로 빠르게 작성하고 피드백 사이클을 돌리는 것을 원칙으로 삼았다.

솔직히 이 정도가 최선이냐고 물으면 자신 있게 그렇다고 말하기는 어렵다. 가급적 소규모 조직이니 실시간으로 공유되는 것이 더 좋겠지만, 당장 이보다 더 나은 방법을 떠올리기 힘들었다. 이건 아직 매니저로서 경험이 부족한 내 한계라고 봐야 할 것이다.

[그래도 달리긴 잘 달렸다]

아쉬운 이야기만 한 것 같아서 좋은 이야기도 하겠다.

이번에 기존에 별도의 프로젝트로 관리되던 클라이언트, 서버, 어드민을 하나의 모노레포로 통합했다. 공용 환경설정 서브모듈도 만들고, 없었던 CI/CD도 추가했다. 이전에는 DB에 변경을 하려면 일일이 페이지에 들어가서 값을 입력하고, 제대로 됐는지 확인하려면 스테이징에 직접 올려서 검증하는 방식으로 개발을 했기 때문에 개발팀의 속도가 나오지 못했다. 지난 주에 인프라 동일성 맞추기와 마이그레이션 자동화가 이루어졌고, 이번 주에 모노레포 반영이 완료되면서 마침내 전반적으로 개발이 달릴 수 있는 환경을 갖추는 데에 성공했다.

그 결과 포럼, 코멘트, 버전 관리, 공지사항 등 꽤 방대한 업데이트가 일주일 만에 이루어졌다. 리액트에 지식이 모자란 내가 클라이언트에 직접 손을 대서 개발을 진행할 수 있는 상태로 만든 것이고, 디자이너가 직접 Cursor를 이용해서 디자인 관련 세밀한 조정을 하고 개발자가 PR에서 리뷰 후 머지하는 것도 몇 차례 문제 없이 진행 가능한 것을 확인했다.

핑계지만 어쩌면 내가 개발에 너무 매몰됐던 것도, 이 가속도에 취해 ‘팀’이라는 존재를 백미러 밖으로 밀어내 버렸기 때문일 것이다. 외부에서 보면 업데이트만 많이 됐네 싶었겠지만, 내부에서는 개발 프로세스 전반이 처음부터 다 갈아엎어지는 작업이 병행됐다. 인프라 변경의 승리라고 부를 만하다.

[같이 달려야 한다는 것]

손자병법에서도 이야기하듯, 조직의 성취를 위해 가장 기본이 되는 것은 구성원이 같은 방향을 바라보도록 하는 것이다. 이 정도 작은 규모의 조직에서 팀원의 역량을 제대로 끌어내지 못하면 가질 수 있는 경쟁력이란 너무나 약하다. 아무리 도구가 좋아지고 개인의 속도가 빨라진들, 팀원의 역량을 하나로 모으지 못하는 리더는 조직의 잠재력을 갉아먹을 뿐이다.

이번 주의 ‘기술적 승리’는 달콤했지만, 그 대가로 치른 ‘매니징의 부재’는 뼈아프다. 앞으로는 실무에 너무 몰두하지 않고 팀원 관리에 신경을 쓰기 위한 시스템적인 장치와 마인드셋의 변경을 고민해 봐야겠다.

잘 달렸다. 다만 다음에는 같이 달리자.