on
팀을 맡고, 한 달 동안 가장 공을 들인 일
이직을 한 지 한 달이 지났다. 새로운 회사에서 맡은 역할은 프론트엔드 조직의 테크 리드, 팀장 같은 거다.
이전 회사에서도 소규모 그룹을 리드하는 역할을 하고 있었기에, 새로운 직책을 맡는다는 것에 부담을 느끼지는 않았다. 차이가 있다면 공식 직함이 생겼고 권한이 더 많아졌으니 내 레버리지를 그만큼 더 넓혀야 한다는 것 정도?
앞으로 어떤 색깔을 가진 친구들과 일을 하게 될지 궁금했다. 출근한 첫 주부터 팀 동료들과 1:1로 이야기를 나누는 걸로 일을 시작했다. 관심사는 무엇이고, 잘하는 것은 무엇이며, 어떤 꿈을 갖고 있는지. 회사, 그리고 서로에게 기대하는 바는 무엇인지. 앞으로 만들어 갈 팀의 모습을 동료들과 함께 그렸다.
그렇게 8개의 Code of Conduct를 만들었다. 공유하는 정신은 어떤 장치 보다 강하다. 평소의 내 철학과 회사의 인재상이 큰 영향을 미친 것은 사실이지만 팀원들은 흔쾌히 동의를 해주었다.
- 사용자에게 가치를 줄 수 있는 일을 합니다.
- 경계를 넘어 서로 돕습니다.
- 서로 신뢰합니다.
- 수평적인 관계와 수직적인 의사결정의 조화를 추구합니다.
- 동료와 함께 성장합니다.
- 과학적으로 접근하고 경험적으로 학습합니다.
- 자신이 만든 결과물에 대해서 전문가로서의 책임감을 갖습니다.
- 규칙으로 정하지 않은 일은 스스로 생각하고 행동합니다.
한 달이 지났다.
8개는 너무 많은 것… 같다. 장황해서 집중을 하기가 어렵다. 우리가 집중해야 할 가치가 무엇일지 다시 고민을 했다. 나도 모르게 자주 쓰는, 내 머릿속의 한편을 굳건히 지키고 있는 문장 두 개가 떠올랐다.
- 서로 돕고 함께 성장하자.
- 일을 기다리지 말자.
그래, 2개로 줄이자. 줄이는 김에 내 생각도 정리를 하자.
하나, 서로 돕고 함께 성장하자.
팀이라는 울타리 안에 사람을 그저 모아 놓으면 알아서 협력할 거라는 생각은 오만하다. 팀이라는 경계는 그 자체로 의미가 없다. 울타리를 치우고 나면 남는 것은 사람뿐이다. 팀에 속한 구성원 사이에 흐르는 에너지의 색깔이 더 중요하다. 한자리에 모여 앉아서 각자의 모니터만 바라보고 있다면, 그걸 팀이라고 말하기는 어렵지 않겠는가. 아무런 시너지도 만들지 못한다. 서로를 엮는 무엇이 있어야 한다.
입사하고 며칠 동안 팀 동료들이 일하는 모습을 관찰했다. 자기의 책상에 앉아서, 자기의 일을 열심히 했다. 부지런한 친구들이다. 유일한 접점은 코드 리뷰. 팀이라고 부르기에는 부족했다.
팀원들과 “우리가 하는 일의 본질과 협업의 가치”에 대해서 이야기를 많이 나눴다. 공감대가 어느 정도 형성이 되자 팀원들이 먼저 새로운 활동을 제안하고, 자신이 학습한 것을 팀에 공유하기도 했다. 사람 사이에 교집합을 하나씩, 하나씩 만들었다.
- 일하는 중간중간 잡담을 하도록 유도한다.
- 데일리 미팅에서 서로 도울 수 있는 연결 고리를 찾아서 이어준다.
- 일정을 함께 추정하거나 페어 프로그래밍을 함으로써 생각과 관점을 공유한다.
- 설계를 동료와 함께 논의하도록 유도하여 부딪히는 순간을 만든다.
- 자신이 학습한 것을 공유하고 토론을 하도록 자극한다.
- 간단한 일이라도 담당자를 두 명을 할당해서 협업을 유도한다.
6번은 언뜻 보면 비효율을 만드는 것처럼 보이지만, 매우 중요하다. 단순히 두 사람이 붙어 앉아있다고 해서, 커피를 같이 마신다고 해서 사람과 사람 사이에 교집합이 생기지는 않기 때문이다. 서로 공유할 수 있는 목표롤 만들어주고 함께 일을 하도록 유도해야 한다. 어느 정도 슬랙(Slack: 물리적, 심리적 여유)을 만들어 주는 것도 중요하다. 마음에 여유가 없는 사람은 주변을 돌아보지 못한다.
효율이나 생산성에만 집착하면 이 모든 게 허튼 짓으로 보이겠지만 교집합이 점점 단단해져 신뢰가 쌓이고, 쌓인 신뢰가 우리를 더 빠르게 만들어 줄 수 있다면 기꺼이 투자할만하다.
둘, 일을 기다리지 말자.
프론트엔드만으로 완성할 수 있는 제품은 거의 없다. 여러 과정을 거치며 다양한 직군이 힘을 합쳐야 비로소 하나의 제품이 만들어진다. 협업이 중요하다. 협업을 하기 좋은 조직 구조를 생각하면 목표를 공유하는 교차 기능(Cross-Functional) 팀을 구성하는 게 좋을 것 같다. 하지만 이런 팀은 몇 가지 이유로 만들기가 어렵다.
교차 기능 팀에 속한 개인은 여러 직군이 모인 조직에서 기능적으로 고립되기가 쉽다. 팀에 자기 혼자만 프론트엔드 개발자인 상황을 떠올려 보라. 다양한 전문성을 가진 집단을, 한 명의 리더가 이끈다는 것 역시 생각만 해봐도 어렵다. 교차 기능 팀에 속한 개인은 탁월해야 하고, 이런 팀은 다른 종류의 리더십으로 이끌어야 한다. 채용 전쟁의 시대에 리소스 불균형도 해결하기 부담스러운 문제다. 교차 기능 팀을 구성하려다 이런 문제를 겪은 회사는 자연스레 기능(Functional) 조직으로 눈을 돌린다. 지금 다니고 있는 회사도 그렇다.
각각의 장단점이 있다. 누군가는 이중 구조(매트릭스 조직 같은)로 묶는 것만이 이 문제를 해결할 수 있는 유일한 방법이라고 주장한다. 무엇이 정답인지는 잘 모르겠다. 답은 모르지만 살아남는 데에 가장 유리한 구조를 선택하고, 그로 인해서 발생하는 단점을 극복하기 위해서 노력은 할 수 있다.
기능(Functional) 조직에 속해서 일을 하다 보면 일이 흐르는 과정이 아닌, 일 그 자체만을 쳐다보기가 쉽다. 웹 프론트엔드 파트는, 웹 프론트엔드 기술을 가진 친구들이 모여서, 웹 프론트엔드의 문제를 해결한다. 그러다 보니 눈앞에 보이지 않는 것들은 생각을 하기가 어렵다.
이런 분위기에서는 협업하는 부서에서 일이 오기를 기다리는 경우를 흔히 볼 수 있다. 내가 한 일과 협업 부서가 한 일이 목표한 지점에 제대로 도달했는지 확인해보지도 않고 QA로 제품을 넘긴다. QA 기간에 버그 리포트를 받고서야 부랴부랴 인터페이스를 맞춰 보고, 디자인을 검토하고, 놓친 스펙을 구현한다. 그렇게 추정은 빗나가고 출시는 미뤄진다.
기능 조직은 업무 완결성을 갖지 못한다. 어느 한곳이 망가지면, 모든 일이 멈춰버린다. 그래서 기능 조직을 운영할 때는 조직 간의 커뮤니케이션에 더 많은 에너지를 써야 한다. 기능 조직에 속한 프론트엔드 개발자는 더욱 그러하다. 디자인과 서버 사이, 그 어딘가에 있는 타고난 포지션도 한몫을 한다.
디자인이 없으면 디자이너를 찾아서 요청을 해야 하고, 디자이너가 없으면 더미로 구현을 할 수 있다. 서버 API가 없으면 서버 개발자를 찾아아야 하고, 서버 개발자가 없으면 인터페이스만 협의를 하고 Fake Server를 이용해서 구현을 할 수 있다. 이도 저도 안 된다면 문제가 있음을 관계자에게 알리고 일정을 재조율해야 한다.
일을 기다려서는 안 된다. 일이 흐르는 전체 흐름을 보고, 내 위치를 자각하고, 적극적으로 일을 챙겨야 한다. 함께 하는 일이니까. 그래야 일이 된다.
지금은 이 두 가지를 문화로 승화시키는 데에만 집중하기로 했다. 말은 누구나 하지만, 말을 현실로 만들기란 정말 어렵다. 꼰대스럽지 않음 위에 공감을 쌓아야 한다. 말 한마디, 문장 하나 매우 조심스럽게 사용하려고 노력한다. 설득하고 있지만 복종하지는 않았으면 좋겠다. 조급하지만 기다리려 애쓴다.
신뢰가 쌓여서 팀원 모두가 팀 안에서 소속감과 안정감을 느꼈으면 좋겠다.