더 빠르게 가라는 요청을 받았지만 인력은 더 주지 않을 때 어떻게 하나요?

Question

Accepted Answer

어차피 사람을 추가하는 것은 단기적으로 팀을 더 빠르게 만드는 일이 좀처럼 없습니다. 그러니 진짜 질문은 이것입니다: 팀의 *시간이 실제로 어디로 가고 있으며*, 그것에 대해 제가 무엇을 바꿀 수 있는가? 저는 "더 빠르게"를 더 오래 일하라는 요구가 아니라 레버리지를 찾으라는 신호로 다룹니다.

## 속도를 찾는 곳

- **모서리가 아니라 범위 잘라내기.** 더 빠르게 출시하는 가장 빠른 방법은 더 적게 만드는 것입니다. PM과 함께 무자비하게 우선순위를 정하고 가치를 전달하는 가장 작은 버전을 찾습니다. 대부분의 기능은 작업의 20%에서 가치의 80%가 나옵니다.
- **마찰과 대기 시간 제거하기.** 종종 병목은 코딩 속도가 아니라 — 느린 CI, flaky한 테스트, 고통스러운 배포, 느린 리뷰, 또는 승인 대기입니다. 30분짜리 빌드나 이틀짜리 리뷰 회전을 고치면 공짜로 진짜 속도를 삽니다.
- **진행 중 작업 줄이기.** 열 가지를 저글링하는 팀은 아무것도 끝내지 못합니다. 병렬로 더 적은 항목에 집중하면 더 빨리 출시됩니다.
- **반복적인 것 자동화하기.** 수동 테스트, 수동 릴리스, 수동 환경 설정 — 한 번 투자하면 영원히 절약합니다.
- **적극적으로 발목을 잡는 부채 갚기.** 전부가 아니라; 팀이 매일 걸려 넘어지는 부분만.
- **집중 시간 보호하기.** 더 적은 회의와 방해는 어떤 도구보다 큰 승리가 될 수 있습니다.

## 요청에 대응하는 법

저는 그냥 "불가능합니다"라고 하거나 조용히 받아들이지 않습니다. **트레이드오프**로 대응합니다: "기능 A와 B를 잘라내거나 테스트에서 더 높은 리스크를 감수하면 그 날짜를 맞출 수 있습니다. 제 추천은 이렇습니다." 이는 속도를 조용한 품질 도박이 아니라 공유되고 의식적인 결정으로 만듭니다.

## 피해야 할 함정

- **초과 근무 강제하기.** 짧은 스프린트를 사고 번아웃, 버그, 이탈로 갚습니다.
- **테스트와 리뷰를 조용히 건너뛰기.** 오늘의 속도, 다음 달의 장애.
- **아무것도 바꾸지 않고 날짜에 예라고 하기** — 그것은 그저 희망이고, 희망은 마감을 놓칩니다.

## 왜 중요한가

지속 가능한 속도는 사람을 쥐어짜는 게 아니라 낭비를 제거하는 데서 옵니다. 압박에 명확한 트레이드오프와 프로세스 개선으로 대응하는 Tech Lead는 — 전력 질주하다 충돌하고 최고의 엔지니어를 잃는 팀 대신 — 진정으로 빠르고 오래가는 팀을 구축합니다.