앞선 글에서 리더의 역할은 성과를 만들어 내는 것이라고 했다. 성과를 만들어내기 위해서는 올바른 목표를 향해 달려가는 것도 중요하지만, 빠른 속도로 달려가는 것 역시 중요하다. 조직에 속해서 일을 하다 보면 다양한 이유로 인해 개인의 생산성이 저하될 수 있다. 리더의 중요한 역할 중 하나는 이러한 병목 지점을 잘 예상하고, 잘 진단하고, 이를 잘 제거해서 팀이 제 능력을 100% 발휘하게끔 판을 깔아주는 것이다.

팀 업무 프로세스

팀 생산성 회고

어떤 문제를 해결하기 위해서는 우선 그 문제가 존재한다는 사실을 인지해야 한다. 팀의 생산성이 저하되는 문제 역시 마찬가지로 생산성이 저하되고 있다는 것을 적시에 파악해야 하는데, 여기에는 팀의 목표 달성률을 주기적으로 모니터링하는 것이 큰 도움이 된다. 팀의 목표를 정한다는 것은 팀이 일할 방향과 속력을 모두 정하는 것이기 때문에, 팀의 생산성에 대해 어느 정도 예상치를 정했다는 의미이다. 이 예상치를 회고의 기준으로 삼는 것이 적절하다. 팀의 목표 달성률을 적당한 주기로 살펴보고, 예상보다 느려지는 경우 팀이 일하는 방식에 문제가 있을 수 있다고 생각해야 한다. 물론 목표 자체가 너무 어려운 것일 수도 있는데, 이런 경우에는 목표를 하향 조정하면 된다.

문제가 있다는 것을 인지했다면, 그 다음 순서는 문제 원인을 파악하는 것이다. 보통 팀 회고를 통해 문제 원인을 분석하곤 하는데, 개인적으로 생각하는 이 방식의 문제는 회고가 보통 개인의 기억에 너무 크게 의존한다는 것이다. 조직에 속해 일하다 보면 내가 메인으로 하는 업무 외에도 수많은 컨텍스트를 동시에 따라가면서 멀티태스킹을 하게 되는데, 그러다 보니 어느 작업에 얼마만큼의 시간을 쏟았는지 정확히 기억하지 못하는 경우가 많다. 그렇기에 각자가 생각하는 비효율의 수준이 왜곡될 가능성이 존재한다. 이런 왜곡을 줄이기 위해, 가능한 경우 팀이 어떤 일에 얼마만큼의 시간을 쏟는지를 잘 기록하고 추적해서 객관적인 데이터를 쌓으려고 시도해보면 좋다. 예를 들면 외부에서 요청이 너무 많이 들어와서 문제라고 생각하는 경우, 요청 창구를 일원화하고 매일 몇 개의 요청이 들어오는지를 추적할 수 있다. 이러한 데이터는 자동화가 필요한 작업에 대해 중요한 인사이트를 제공하기도 한다.

일반적으로 발생하는 비효율

라포랩스에서 3년 정도 일하면서 보았던, 일반적으로 발생하는 업무상 비효율은 아래와 같다.

• 외부 요청 및 운영성 업무가 너무 많다.

  원래 해야 하는 일 외적으로 발생하는 외부 요청이나 운영성 업무가 너무 많은 경우, 팀 생산성이 심각하게 저하될 수 있다.

  외부 요청이나 운영성 업무가 많은 상황은 보통 제품을 부실하게 기획하고 만들어서 발생하는 경우가 잦다. 타 팀이 스스로 처리할 수 있는 어드민 화면을 만들어주지 않았다던가, 발생할 수 있는 예외 케이스를 고려하지 안/못하고 설계 및 개발을 해서 수기 처리를 해야 하는 상황이 많아지는 것이다. 그래서 외부 요청이나 운영성 업무는 일종의 부채로 봐야 한다. 일부 케이스를 수기로 대응한다는 결정을 하면 일시적으로 제품 개발을 더 빠르게 할 수 있지만, 이에 대한 운영 비용은 마치 이자처럼 지속적으로 지불해야 한다.

  팀은 외부 요청 및 운영성 업무라는 부채의 양을 적절한 수준으로 관리할 필요가 있다. 부채가 너무 많아지는 경우, 설계를 개선하거나 어드민을 개발하거나 자동화를 하는 등의 방식을 통해 부채의 양을 조절할 수 있다.

• 안 해도 되는 일을 한다.

  종종 ROI가 잘 나오지 않는 비생산적인 일을 별 생각 없이, 혹은 그저 관성적으로 하는 경우가 있다. 예를 들면 기획 및 개발을 과하게 꼼꼼하게 하거나, 별 의미 없는 팀 회의를 반복하는 것이다.

  제품 개발은 특성상 어쩔 수 없이 느리므로, 제품팀은 항상 효율을 따져야 한다. 무언가를 만든다는 것은 다른 무언가를 만들지 않는다는 결정과 동일하다. 원하는 모든 것을 만들 수 없기 때문에, 제품팀은 무엇을 만들지 않을지를 아주 잘 선택해야 한다. 이런 관점에서, 제품팀은 항상 스스로 최선의 ROI로 일을 하고 있는 것인지 잘 따져봐야 한다. 이때 도움이 되는 것은 본인과 팀이 어떤 일을 했는지 잘 기록해뒀다가 이를 기반으로 본인과 팀의 생산성을 회고하는 것이다. 이를 다른 팀원과 함께 보면서 각 업무의 필요성에 대해 자주 논의하면 팀 전체적으로 우선순위를 판단하는 능력을 기를 수 있다.

• 제품 개발 경험 및 도구가 좋지 않다.

  제품 개발 프로세스나 개발 환경 등이 좋지 않은 경우, 제품팀 구성원이 자신의 퍼포먼스를 100% 발휘하기가 어려울 수 있다. 예를 들어, 코드베이스에 레거시가 많고 코드베이스의 복잡도가 높으면 이를 읽고 이해하는 데 시간이 더 오래 걸리기 때문에 제품 개발이 느려질 수밖에 없다. 또다른 예시로, 베타 앱에서 네트워크 호출의 request / response를 확인하는 등의 디버깅 도구가 부족하면 QA로 발견된 문제의 원인을 찾는 데 더 오래 걸릴 것이다.

  제품 개발 경험 및 도구는 회사가 작을 때는 각 팀이 필요할 때마다 직접 만들어서 사용하다가, 조직이 일정 규모 이상 커지면 플랫폼 팀을 따로 둬서 제품 개발 프로세스를 관리하는 것이 적절하다고 본다.

프로젝트 관리 방법론에 대하여

IT 회사들을 보면 대부분 스프린트, 스크럼, 칸반 등 애자일 방법론에서 나온 프로젝트 관리 방법론을 활용한다. 솔직히 말하면 이런 방법론에 대해 큰 흥미가 없다. 애자일 관련된 책도 한 권도 읽어보지 않았는데, 읽는다고 일을 더 잘하게 될 것 같지 않아서 그렇다.

일반적인 스마트폰 애플리케이션이나 웹서비스를 제작하는 팀은 자연스럽게 스크럼, 스프린트, 칸반과 같은 형태로 일하게 될 것이라고 예상한다. PMF를 찾기 위한 가장 쉬운 방법은 실제로 유저가 제품을 쓰게 하고 이에 대한 반응을 보는 것이다. 화장품 같은 제품은 온전한 제품과 브랜딩이 나와야 이 반응을 볼 수 있겠지만, 소프트웨어는 아주 빠르게 작은 단위로 개발하고 출시해서 유저의 반응을 확인할 수 있다. 이걸 하지 않을 이유가 없으므로 소프트웨어 개발팀은 제품 개발 사이클을 극단적으로 줄여야 한다. 이때 팀이 적은 개수의 일에 집중하면 스프린트 형태가 자연스럽게 도출되고, 여러 개의 태스크를 연속적으로 굴리면 칸반 형태가 자연스럽게 도출된다.

당연하게도 모든 소프트웨어 개발 조직에 애자일 방법론이 들어맞지는 않는다. 항공기에 탑재될 소프트웨어를 생각해보라. 애자일 방법론을 적용하는 건 자살 행위이다. 항공기 소프트웨어는 훨씬 더 긴 사이클로, 일정한 릴리즈 주기를 가지고, 매우 많은 테스트셋을 거친 이후에 배포되어야 마땅하다. 그러므로 중요한 것은 각 프로세스의 세부 규칙과 정책을 이해하는 것이 아니라, 왜 이런 프로세스가 나오게 됐는지를 이해하는 것이다.

팀 문화

피드백 문화

팀이 일을 잘하기 위해서 가장 중요한 요소 중 하나는 팀 내에서 피드백이 잘 오가는 문화를 형성하는 것이다. 피드백은 팀원을 성장시키고, 불필요한 일에 시간을 낭비하지 않도록 도와주고, 설계를 개선시켜 부채를 줄여준다. 피드백은 매우 효율적인 shift left(원점 회귀) 전략이다. 서로의 생각을 더욱 빠른 시점에 공개해서 피드백을 요청한다면 shift left의 효과가 극대화될 수 있다.

피드백 잘하는 문화, 말로는 쉬운데 실제로 어떻게 만들 수 있을까? 핵심 기업 문화에 ‘피드백을 잘 합시다’를 붙여놓고 피드백을 하라고 해서 구성원들이 피드백을 많이 하는 것은 아니다. 일상 생활에서 주로 사용하는 화법이 아니고, 상호간에 불편한 상황을 만들 수 있기 때문이다. 나는 피드백을 잘 주고받는 문화의 핵심이 심리적 안전감이라고 생각한다. 내가 작업물을 공개하고 피드백을 받을 때 비난이 아니라 따뜻한 비판을 할 것이라는 확신. 나를 비난하기 위한 피드백이 아니라 나를 더 나은 인간으로 만들어주고 싶다는 따뜻한 마음에서 피드백을 줄 것이라는 확신. 나를 깎아내리고 본인을 추켜세우기 위한 피드백이 아니라 오로지 팀이 일을 더 잘하기 위해서 피드백을 줄 것이라는 확신. 이런 확신은 팀원간의 개인적인 유대감과 신뢰 관계에서 온다. 우리가 서로를 좋은 동료라고 생각하고, 서로 함께 일하고 싶어한다고 확신하는 순간, 사람들은 피드백 받기를더 이상 두려워하지 않는다. 두려워하지 않는다.

이렇게 팀원간의 유대감과 신뢰관계가 잘 형성됐다면, 이제 리더가 나서서 피드백을 주고 받는 모습을 많이 보여주기만 하면 된다. 사람을 향하는 것이 아니라 작업물을 향하도록, 냉랭한 표정 대신 따뜻한 미소와 함께, 감정적으로 우기는 것이 아니라 논리적으로 탄탄한 설득으로 피드백을 주는 것이 시작이다. 그렇게 피드백을 주다 보면 팀원이 종종 반론을 하고, 반론을 하다 보면 가끔 먼저 나서서 피드백을 한다. 이때 팀원의 피드백을 잘 수용하는 모습을 보여줘야 한다. 이러다 보면 리더가 나서지 않아도 팀원들이 숨쉬듯 자연스럽게 피드백하는 문화가 형성될 수 있다.

피드백은 선택적으로 수용하는 것이 필요하다. 왜냐하면 피드백을 준 사람은 실제로 일을 한 사람에 비해 해당 맥락에 대한 이해도가 부족할 가능성이 높기 때문이다. 개인의 판단은 항상 어떤 상황이냐에 따라 옳고 그름이 달라진다. 자신이 판단을 내린 당시 상황에 대해 이해도가 가장 높은 사람은 나 자신일 가능성이 높기 때문에, 피드백은 그저 스스로를 회고하기 위한 재료 정도로 삼는 것이 적절하다.

유대감, 애정, 셀레브레이션

라포랩스를 다니는 동안 두 개의 팀을 리딩했었다. 첫 팀을 리딩할 때는 팀원들의 일에 많이 관여했다. 팀원들의 연차가 비교적 낮았기 때문이다. 스크럼을 자주 하고, 업무 관련 회의에도 함께 들어가는 경우가 많았고, 설계 및 코드 리뷰도 꼼꼼하게 하고, 이런저런 잔소리도 많이 했다.

시간이 지나 맡은 두 번째 팀은 모두가 혼자 알아서 일할 수 있는 역량의 팀원으로 구성되어 있었다. 당시 팀을 어떻게 운영할지 고민하다가 내린 결론이, 팀원 모두가 혼자서도 알아서 일할 수 있는 능력을 갖췄으므로 가장 효율적으로 일하려면 각자 컨텍스트 스위칭 없이 일을 하나씩 맡아서 처리하는 게 좋겠다고 생각했다. 그래서 각자 독립적인 큰 일을 하나씩 맡아서 처리하도록 했다. 이런 상황에서 팀 회의나 설계 및 코드 리뷰는 굳이 필요하지 않으니 최소한으로 줄였다. 그렇게 한 6개월 정도 일해보니, 업무 효율 자체는 좋았지만 내가 외주를 하는 건지 회사를 다니는 건지 알 수가 없어졌다. 팀으로 일하는 맛이 떨어졌고, 팀에 대한 소속감이 잘 느껴지지 않았다.

이런 경험을 통해, 팀에 대한 소속감이 여러 의미로 중요하다는 것을 배웠다. 돈 아낄 궁리만 하는 회사들이 괜히 팀끼리 회식하라고 회식비 주는 게 아니라는 생각이 들었다. 팀원끼리의 유대감, 팀에 대한 소속감 및 애정을 만들어내는 것은 정말 중요하다. 위에서 이야기한 것처럼 피드백을 주는 데도 중요하지만, 그 이상의 가치가 있다. 회사는 인생에서 가장 많은 시간을 보내는 공간이다. 이런 공간에서 가장 많은 시간을 보내는 팀에 애정을 느끼면 개인의 인생이 매우 행복해진다. 출근이 즐거워지고, 일이 즐거워지고, 팀에 몰입할 수 있고, 개인의 능력을 120% 발휘할 수 있게 된다. 물론 이러한 애정이 과해져서 조직 내 정치로 번지면 안 되겠지만.

회사에서 사적으로 친해지는 것에 대해 호불호가 꽤 갈릴 텐데, 나는 팀에 대한 애정을 만들어내기 위해서는 팀끼리 사적인 시간을 어느 정도 같이 보내는 것이 필요하다고 생각한다. 다만 그것을 회사에서 굳이 티내서 다른 사람들이 소외감을 느끼게 하지만 않으면 된다. 사적인 시간 외에 또 중요한 포인트는 셀레브레이션이다. 팀이 이뤄낸 크고 작은 성취에 대해 샤라웃을 해주고, 인정해주고, 축하해주고, 성취감을 같이 공유하는 것이 효과적이다. 이건 당신의 성공이기도 하지만 팀의 성공이기도 하다는 메세지를 잘 전달해주고, 성공의 기쁨을 함께 누리는 것이다.

팀의 신뢰 자본 관리

팀의 신뢰 자본이란, 다른 팀이 우리 팀에 대해 가지고 있는 업무적인 신뢰도와 호감을 의미한다.

팀의 신뢰 자본은 팀이 일을 되게 만드는 데 상당히 중요한 역할을 한다. 혼자 일을 잘하는 데 한계가 있는 것처럼, 팀으로 일을 잘하는 데도 한계가 있다. 더 영향력이 큰 프로젝트를 하고 싶을수록 우리 팀 외의 도움이 필요한 경우가 많아진다. 여러 팀이 협업할 때 가장 큰 어려움은 커뮤니케이션일 것이다. 당신의 팀이 하고 싶은 그 일이 우리 팀 리소스를 빼서 도와줄 만큼 충분히 중요한 일인지 설득하고, 여러 팀의 우선순위를 잘 조율하는 것은 끔찍한 과정이다. 이때 신뢰 비용이 충분히 쌓여 있으면 이러한 커뮤니케이션과 협업의 비용이 극단적으로 낮아질 수 있다.

그러므로 신뢰 자본을 잘 관리하는 것이 중요하다. 가장 중요한 것은 일단 팀이 일을 잘하는 것이다. 저 팀이랑 일을 하면 말이 잘 통하고, 별 탈 없이 프로젝트가 진행되고, 기분이 상하는 일이 없었다는 경험을 심어줘야 한다. 또 다른 중요한 포인트로, 신뢰 자본을 쌓으려면 먼저 우리가 일시적인 손해를 보면서 투자를 해야 한다. 도움을 청하는 팀이 있으면 웬만해서는 도와주는 게 좋다. 그러면 우리 팀이 정말 중요한 일을 할 때 다른 팀들이 도와줄 것이다. 이는 죄수의 딜레마와 비슷하다고 생각한다. 다른 팀을 도와줄지 말지의 기로에 섰을 때, 도와주지 않는 것이 일시적인 리소스 측면에서 이득이다. 하지만 모두가 도움을 주지 않는다는 선택을 하면 협업이 원활하게 이루어지지 않으므로 오히려 회사 전체적인 관점에서 손해가 발생한다. 일정 규모 이상의 프로젝트는 반드시 협업이 필요한데, 이런 프로젝트들이 멈추는 회사가 된다. 따라서 Tit-for-Tat 연구의 교훈을 삼아 먼저 도움을 주고 신뢰를 쌓는 것이 우월 전략이다.