추정을 비난하지 마세요. 조직을 고치기 시작하세요.
I’m happy to translate the article for you, but I’ll need the full text of the post (the content you’d like translated). Could you please paste the article’s body here? I’ll keep the source line exactly as you provided and translate the rest into Korean while preserving the original formatting.
내가 계속 보는 패턴
팀은 기능을 5 story points 로 추정한다 – 복잡도 낮고, 요구사항이 명확하며, 도메인을 잘 이해하고 있다. 모든 추정 프레임워크에 따르면 작은 작업이다.
3주 후에 배포된다.
팀은 추정이 잘못됐다는 비난을 받는다. 리더십은 더 나은 grooming, 더 상세한 breakdowns, 더 엄격한 story points 를 요구한다. 팀은 더 열심히 노력한다. 다음 스프린트에서도 같은 일이 발생한다.
추정이 절대 문제였던 적은 없다.
현대 추정 프레임워크가 여전히 유효한 이유
| 차원 | 측정 항목 |
|---|---|
| 복잡도 | 이것을 이해하기 얼마나 어려운가? |
| 노력 | 얼마나 많은 원시 작업이 필요한가? |
| 불확실성 | 얼마나 많은 미지수가 존재하는가? |
| 위험 | 어떤 외부 요인이 이를 탈선시킬 수 있는가? |
각 차원은 점수를 부여받으며, 이들의 조합이 스토리 포인트를 결정합니다. 올바르게 적용될 경우, 5‑point story really is a 5‑point story – 팀은 복잡도, 노력, 그리고 기술적 미지수를 정확히 평가했습니다.
The Missing Piece: Organizational Friction
Estimation measures work. It was never designed to measure the environment the work has to travel through.
Between “estimated” and “delivered” sits everything the estimation framework doesn’t capture. I call it org friction – the invisible overhead that organizational structure, processes, and cross‑team dependencies impose on every piece of work.
That 5‑point story took three weeks not because the team mis‑judged the code, but because:
- A schema change needed approval from another team.
- The design review sat in a queue for days.
- Security had to sign off because it touches user data.
- The one person who understood the legacy service was unavailable.
- The engineer got only two focused hours per day between meetings, incidents, and “quick questions.”
None of this is an estimation error. It’s organizational drag – untracked, unowned, and invisible in tools like Jira or OKRs, yet it can consume 30‑40 % of a team’s capacity.
Source: …
Common Sources of Org Friction
| Category | Typical Symptoms |
|---|---|
| Cross‑team dependencies | 작업은 몇 시간 걸리지만, 대기는 며칠 걸린다 (예: Platform 팀 PR 리뷰, Design spec 최종화). |
| Process overhead | 원래 목적이 사라진 뒤에도 남아 있는 변경‑관리 보드, 아키텍처 검토 위원회, 컴플라이언스 게이트. |
| Knowledge silos | 핵심 컨텍스트를 단일 엔지니어 또는 PM이 보유하고 있어, 그들이 부재 시 작업이 정체된다. |
| Legacy process debt | 수동 배포 단계, 느린 테스트 파이프라인, 오래된 온보딩 문서 – 고칠 정도는 아니지만 모든 것을 느리게 만든다. |
| Decision latency | 공식적인 게이트는 없지만, 명확한 의사결정 권한이 없어 “yes”를 기다리는 상황. |
| Context‑switching tax | 추정은 집중 시간을 기준으로 하지만, 실제로는 지원 로테이션, 인시던트 대응, Slack 스레드, 비동기화 가능한 회의 등이 포함된다. |
| Misaligned incentives | 팀 A는 기능 출시를, 팀 B는 시스템 안정성을 측정한다; 팀 B는 팀 A가 파괴적인 변화를 배포하도록 도울 동기가 전혀 없다. |
팀이 지속적으로 납기 목표를 놓치면, 기본적인 반응은 추정 개선을 추진하는 것이다 – 더 많은 Grooming, 더 세분화된 분해, 더 엄격한 Story Point. 이는 핵심을 놓치는 접근이다.
추정 자체는 괜찮다. “예상”과 “실제 전달” 사이에 달라진 것은 작업의 복잡성이 아니라, 작업이 프로덕션에 도달하는 과정에서 마주한 마찰이었다.
실제 레버: 마찰 감소
마찰을 줄이는 것은 엔지니어링 문제가 아니라 리더십 문제입니다. 아래는 제가 엔지니어링 매니저로서 조직 마찰을 가시화하기 위해 도입한 가장 유용한 실천 방법입니다.
마찰 로그
- 스프린트마다 공유 문서를 만들기(예: Google Docs, Confluence 페이지). 이름을 **“마찰 로그”**라고 정합니다.
- 규칙: 코드 자체와 무관하게 누군가가 차단되거나, 지연되거나, 속도가 느려질 때마다 한 줄을 기록합니다:
무슨 일이 있었나요? – 얼마나 기다렸나요? – 어떤 마찰 원인인가? - 스프린트 중에는 분석 금지 – 기록만 합니다. 최소한의 노력으로 유지합니다.
- 2주가 지나면 팀 전체가 함께 읽어봅니다.
여러분이 보게 될 것
팀이 추정한 작업과는 전혀 관련 없는 시간 사용에 대한 사실적인 기록입니다. 제가 처음 시도했을 때, **스프린트 전체 시간의 40 %**가 다음과 같은 항목을 기다리는 데 사용되었습니다:
- 팀 간 리뷰
- 의사결정 지연
- 한 줄 구성 변경에 4일이 걸린 컴플라이언스 게이트
추정 자체는 정확했지만, 조직 비용이 많이 들었습니다.
마찰 로그의 장점
| 장점 | 설명 |
|---|---|
| 추정과 실제 전달을 구분 | 5포인트 스토리가 실제로 5포인트 스토리였음을 보여주고, 추가된 2주는 추정 오류가 아니라 조직 마찰 때문임을 명확히 합니다. |
| 공유되고 객관적인 데이터 세트 생성 | 의견이나 불만이 아니라 논쟁하기 어려운 사실만을 제공합니다. |
| 목표 지향적 개선 가능 | 가장 큰 마찰 원인을 파악하고, 이를 제거하거나 간소화하는 데 우선순위를 둡니다. |
요점
Estimations are good at measuring what we have to do.
Organizational friction measures how we get it done.
If you keep improving estimation while ignoring friction, you’ll only get better at being pessimistic. Make the friction visible, then work with leadership to reduce it. That’s where real delivery speed comes from.
조직 마찰 이해하기
갭을 확인하면 그것에 대해 이야기할 수 있습니다. 불평이 아니라 데이터를 제공합니다.
“우리 추정치는 항상 빗나가요” 라고 하면 어깨를 으쓱할 뿐입니다.
“이번 스프린트에 교차 팀 리뷰를 기다리며 11일을 소비했다는 로그가 있습니다” 라고 하면 대화가 시작됩니다.
리더는 숫자로 된 패턴에 반응합니다. 숫자가 당신의 전투를 골라줍니다. 한 스프린트가 지나면 가장 큰 마찰 원천이 명확해집니다. 모든 것을 고칠 필요는 없습니다—가장 자주 나타나는 것을 선택하고 다음 분기에 줄이기 위해 작업하세요.
- 아마도 플랫폼 팀의 스프린트 리뷰에 포함시켜 PR이 대기열에 머무르지 않게 할 수 있습니다.
- 혹은 레거시 서비스를 문서화해 한 사람에게 의존하지 않게 할 수 있습니다.
작지만 누적되는 개선.
조직 마찰은 누군가가 설계한 것이 아닙니다. 점진적으로 쌓여왔습니다:
- 한 번에 하나씩 합리적인 프로세스.
- 한 번에 하나씩 선의의 승인 게이트.
- 한 번에 하나씩 팀 경계.
각 결정은 개별적으로는 타당했지만, 함께하면 팀이 배포하는 모든 작업에 보이지 않는 비용을 부과했습니다.
추정이 문제인 것이 아니라, 조직 자체가 누구도 인정하고 싶어 하지 않을 정도로 비싸진 것입니다.
문제는 팀이 더 잘 추정할 수 있느냐가 아니라, 리더인 당신이 그 마찰을 명명하고 해결하려는 의지가 있느냐입니다. “예상”과 “실제 전달” 사이의 차이는 측정 오류가 아니라 리더십 기회이기 때문입니다.
원본 게시: pixari.dev.