엔지니어링 팀의 집중력 예술: 적을수록 더 많은 것을 이룬다
"더 많이, 더 빠르게"의 함정
엔지니어링 리더로서 우리는 항상 팀의 생산성을 극대화하라는 요구를 받습니다. 이는 주로 "얼마나 많은 것을 얼마나 빨리 배포할 수 있는가"로 측정되곤 하죠. 하지만 여기에는 흔히 빠지기 쉬운 함정이 있습니다. 바로 "동시에 더 많은 일을 하면 더 많은 결과를 낼 수 있다"는 착각입니다.
"우리는 단지 누군가가 모든 작업에 조금씩 손을 대고 있다는 이유만으로 진전을 이루고 있다고 스스로를 속입니다."
하지만 진짜 중요한 질문은 이것입니다:
"더 많이 배포하기 위한 열쇠가 사실은 더 적게 하는 것이라면?"
가치 있는 것은 배포된 이후에만 존재한다
우리가 반드시 기억해야 할 점은, 무언가를 배포하고 그것이 실제로 사용되기 전까지는 아무런 가치도 없다는 것입니다. 따라서 우리의 목표는 항상 "무언가를 배포하는 것"이어야 합니다. 배포된 이후에야 비로소 학습하고, 적응하며, 필요하다면 방향을 수정할 수 있습니다.
하지만 현실에서는 종종 "아니오"라고 말하지 못하는 것이 문제입니다. 좋은 아이디어가 많다 보니, 모든 것을 시도하고 싶어지죠. 그러나 이런 결정(혹은 결정을 내리지 못하는 것)은 결국 가장 중요한 작업을 지연시키는 결과를 초래합니다.
핵심 원칙: 민첩한 엔지니어링 팀을 위한 5가지 방법
- 모든 작업을 가시화하라
- 작업을 작은 단위로 나눠라
- 진행 중인 작업을 제한하라
- 우선순위 작업에 팀 역량을 집중하라
- 예상치 못한 상황을 위한 여유를 남겨둬라
1. 모든 작업을 가시화하라
작업을 가시화한다는 것은 팀이 무엇을 하고 있는지 명확히 파악하는 것을 의미합니다. 이는 단순히 문제를 드러내는 것이 아니라, 해결책을 가능하게 만드는 도구입니다.
"작업을 가시화하면 현실을 무시할 수 없습니다. 모든 것이 한눈에 보이면, '작은 기능 하나쯤 더 추가해도 괜찮겠지'라는 착각을 유지할 수 없게 됩니다."
작업을 가시화하면 다음과 같은 이점이 있습니다:
- 우선순위를 명확히 정할 수 있습니다.
- 중단하거나 보류해야 할 작업을 식별할 수 있습니다.
- 팀이 "시작"이 아닌 "완료"에 집중하도록 도울 수 있습니다.
작업을 가시화하는 것은 마치 여행 가방을 싸는 것과 같습니다. 무작정 물건을 쑤셔 넣는 대신, 모든 것을 침대 위에 펼쳐놓고 "무엇이 정말 필요한가"를 신중히 선택하는 과정이죠.
2. 작업을 작은 단위로 나눠라
작업을 작은 단위로 나누는 것은 팀의 생산성을 극대화하는 가장 강력한 방법 중 하나입니다. 큰 작업은 팀의 에너지를 빨아들이는 "블랙홀"이 될 수 있습니다.
"작업이 너무 커지면 팀은 몇 달 동안 진전을 보이지 못한 채 끝없는 마감일을 쫓게 됩니다."
작업을 1~2주 단위로 나누는 것이 중요합니다. 이는 단순히 일정 관리의 문제가 아니라, 인간 심리와 팀 역학에 기반한 접근 방식입니다. 작은 단위의 작업은 다음과 같은 효과를 가져옵니다:
- 개발자들이 "작은 승리"를 자주 경험하며 동기부여를 유지합니다.
- 필요할 때 빠르게 방향을 전환할 수 있습니다.
- 코드 리뷰가 간소화되고, 협업이 자연스럽게 이루어집니다.
- 배포 리스크가 줄어듭니다.
"작은 작업 단위는 개발자들이 복잡한 기능 속에서 길을 잃지 않도록 돕습니다. 그들은 짧은 시간 안에 의미 있는 무언가를 완성할 수 있다는 확신을 갖게 됩니다."
작업을 작은 단위로 나누는 것은 느려 보일 수 있지만, 실제로는 "진행 상황을 가시화하고, 팀의 모멘텀을 유지하며, 지속적으로 가치를 전달"함으로써 더 빠르게 배포할 수 있게 만듭니다.
3. 진행 중인 작업을 제한하라
한 개발자가 여러 작업을 동시에 진행하는 것은 생산성을 높이는 방법처럼 보일 수 있지만, 사실은 그 반대입니다.
"여러 프로젝트를 동시에 진행하면, 마치 다섯 가지 요리를 한꺼번에 하려는 것과 같습니다. 결국 무언가를 태우거나, 재료를 빼먹거나, 모든 것이 두 배의 시간이 걸리게 됩니다."
컨텍스트 전환(한 작업에서 다른 작업으로 전환하는 것)은 특히 비용이 많이 듭니다. 연구에 따르면, 한 번의 전환 후 완전히 집중력을 되찾는 데 최대 23분이 걸릴 수 있다고 합니다. 동시에 여러 작업을 진행하면 다음과 같은 문제가 발생합니다:
- 코드 품질 저하
- 팀의 사기 저하
- 작업 완료율 감소
"진행 중인 작업을 제한하고, 팀이 한두 가지 작업에만 집중하도록 하면 더 많은 것을 배포할 수 있습니다. 그리고 더 높은 품질의 작업을 더 행복한 개발자들과 함께 배포할 수 있습니다."
4. 우선순위 작업에 팀 역량을 집중하라
"한 명의 개발자, 한 가지 기능"이라는 접근 방식은 흔히 볼 수 있지만, 이는 느린 배포와 지식 단절을 초래합니다. 대신, 팀의 역량을 최우선 작업에 집중하는 것이 중요합니다.
"최우선 과제에 가능한 많은 개발자를 투입하세요. 팀원들이 서로의 발을 밟을 정도로요. 그 후에야 다음 우선순위로 넘어가세요."
이 방식의 장점은 다음과 같습니다:
- 팀 전체에 지식이 자연스럽게 확산됩니다.
- 협업을 통해 더 빠르게 해결책이 도출됩니다.
- 코드 품질이 실시간 피어 리뷰를 통해 향상됩니다.
- 기능이 훨씬 더 빨리 배포됩니다.
"팀이 하나의 작업에 집중하면, 단순히 코딩하는 것을 넘어 함께 성장하는 환경을 만들 수 있습니다."
5. 예상치 못한 상황을 위한 여유를 남겨둬라
도로가 100% 용량으로 운영되면 교통 체증이 발생하듯, 팀도 100% 용량으로 운영되면 "정체"가 발생합니다. 예상치 못한 작업은 언제나 발생하기 마련입니다. 중요한 것은 그 타이밍과 구체적인 내용이 예측 불가능할 뿐이라는 점입니다.
"팀이 100% 용량으로 일하고 있다면, 사실상 적자를 운영하고 있는 것입니다."
여유를 남겨두는 것의 이점:
- 예상치 못한 문제에 유연하게 대응 가능
- 창의적인 사고와 실험의 여지 확보
- 품질 유지
- 개발자 만족도 상승
"여유를 가진 팀은 더 혁신적이고, 더 회복력이 있으며, 궁극적으로 더 생산적입니다."
결론: 적을수록 더 많은 것을 이룬다
GitHub의 경험에서 배운 교훈은 간단합니다. 더 많이 배포하기 위해서는 더 적게 해야 한다는 것입니다. 이를 위해 다음을 기억하세요:
- 작업을 가시화하여 현실을 직시하세요.
- 작업을 작은 단위로 나누어 모멘텀을 유지하세요.
- 진행 중인 작업을 제한하여 집중력을 높이세요.
- 우선순위 작업에 팀 역량을 집중하세요.
- 예상치 못한 상황을 위한 여유를 남겨두세요.
"팀의 진정한 역량은 얼마나 많은 작업을 동시에 처리할 수 있는지가 아니라, 얼마나 효과적으로 고객에게 가치를 전달할 수 있는지에 달려 있습니다."
적을수록 더 많은 것을 이룰 수 있습니다.
리더로서 가장 강력한 행동은 팀의 작업량을 줄이는 것일지도 모릅니다.