엔지니어링 팀 집중의 기술: 적게 하면 더 많이 할 수 있음

• 엔지니어링 팀은 종종 "더 많은 기능을 더 빠르게 출시"해야 한다는 압박을 받음
• 하지만 너무 많은 작업을 동시에 진행하면 오히려 생산성이 떨어짐
• "더 많이 출시하는 비결은 오히려 덜 하는 것" - Less is More

핵심 원칙

• 모든 작업을 가시화함
• 작업을 작은 단위로 정의
• 진행 중인 작업을 제한함
• 용량에 맞게 자원을 할당함
• 보너스: 혹시 모를 것을 위해 여유 공간을 확보함

# 모든 작업을 가시화함

• 작업을 가시화하면 현실을 직시하게 됨
• 모든 작업이 한눈에 보이면 다음과 같은 장점이 있음
  • 우선순위를 명확히 설정 가능
  • 불필요한 작업을 중단하거나 일시 중지 가능
  • 팀이 시작한 작업을 완료하도록 집중 가능
• 목표는 모든 작업을 영원히 추적하는 것이 아님 → 현실을 명확히 파악하고 더 나은 의사 결정을 내리기 위함

# 작업을 작은 단위로 정의함

• 작업이 너무 크면 팀의 에너지가 소진되고 진행 상황이 명확하지 않음
• 작업 단위를 1~2주 정도로 제한
  • 개발자는 단기적 성과를 통해 동기 유지
  • 빠르게 피드백 받고 수정 가능
• 작은 작업 단위의 장점
  • 코드 리뷰가 더 쉬워짐
  • 자연스러운 지식 공유
  • 팀원 간의 협력이 강화됨
  • 배포 위험 감소
• 작업 단위를 줄이면 속도가 빨라짐 → 복잡한 기능에 압도되지 않고 모멘텀 유지 가능

# 진행 중인 작업을 제한함

• 여러 기능을 동시에 처리하면 오히려 생산성이 저하됨
• 맥락 전환 비용이 발생 → 새로운 작업에 적응하는 데 최대 23분 소요됨
• 진행 중인 작업이 많아질수록 다음과 같은 문제가 발생
  • 품질 저하
  • 버그 증가
  • 팀의 사기 저하
• 팀 수준의 과부하 신호
  • 개발자당 4개 이상의 작업 수행
  • 예상보다 완료 시간이 길어짐
  • 완료된 기능보다 진행 중인 기능이 많음
• 개인 수준의 과부하 신호
  • 집중력 저하
  • 코드 리뷰 응답 시간 증가
  • 상태 회의에서 우선순위 설명 어려움

# 용량에 맞게 자원을 할당함

• "한 명의 개발자가 하나의 기능을 맡는다"는 접근 방식은 비효율적임
• 가장 중요한 작업에 팀의 리소스를 집중
  • 협업 강화 → 문제 해결 속도 향상
  • 코드 품질 향상 → 실시간 피어 리뷰 활성화
  • 작업 완료 속도가 빨라짐
• 개발자들이 협업을 통해 더 깊은 이해 가능
• 팀 단위 성과를 장려해야 함 → 개인 성과보다는 팀 성과에 중점

# 여유 공간을 확보함

• 100% 용량으로 운영하면 오히려 성과가 저하됨
• 예상치 못한 작업은 불가피함 → 언제 발생할지 모를 뿐임
• 여유 공간이 없으면 발생하는 문제
  • 팀이 반응적으로 일하게 됨
  • 품질 저하
  • 혁신 감소
  • 기술 부채 증가
• 여유 공간이 있으면 다음과 같은 장점이 있음
  • 예상치 못한 문제에도 유연하게 대응 가능
  • 창의적인 문제 해결 가능
  • 높은 품질 유지
  • 지속 가능한 작업 속도 유지
• 적정 여유 공간은 약 20% → 팀 특성에 따라 조정 가능

핵심 전략 요약

• 작업을 가시화 → 현실을 직시할수 있게
• 작업을 작은 단위로 정의 → 모멘텀을 유지
• 진행 중인 작업 제한 → 집중력을 높임
• 용량에 맞게 자원 할당 → 우선순위에 맞춰 집중
• 여유 공간 확보 → 유연성 확보

결론

• 더 많은 작업을 하기 위해서는 덜 하는 전략이 필요함
• 팀의 성과는 얼마나 많은 기능을 동시에 처리했는지가 아니라, 얼마나 효과적으로 고객에게 가치를 제공했는지로 측정됨
• 리더의 역할은 팀에 더 많은 작업을 추가하는 것이 아니라, 불필요한 작업을 덜어내는 것임