실적은 좋은데 개발 조직은 망가지는 이유

매출과 인원이 꾸준히 늘면 조직도 건강하다고 보기 쉬워요. 하지만 빌드와 배포가 특정 사람에게 묶이고, 낡은 문서가 방치돼도 실적은 한동안 잘 나올 수 있어요. 이 간극을 설명하는 개념이 ‘역량 실명’이에요.
핵심 요약
| 구분 | 핵심 | 왜 볼 만한가요 |
| 성장과 채용 | 빠른 채용이 반복되면 현재 방식에 익숙한 사람만 조직의 기준을 다시 만들 수 있어요 | 인원 증가가 기술 역량의 증가를 뜻하지 않는 이유를 보여줘요 |
| 개발 기반 | 한 사람만 다루는 빌드와 고참의 대기가 필요한 배포가 남아도 좋은 실적이 문제를 가릴 수 있어요 | 매출 지표와 개발 조직의 건강 지표를 따로 봐야 해요 |
| 개선 조직 | 중앙 조직이 표준과 절차를 모두 통제하면 현업의 판단과 책임감이 약해질 수 있어요 | 우수성 센터를 만들기 전에 권한 배분을 점검하게 해요 |
1. 회사가 필요한 역량을 알아보지 못할 때
이언 레펠은 성공한 기업이 한때 성장을 이끈 역량을 더 이상 알아보거나 보상하지 못하는 상태를 ‘역량 실명’이라고 불러요. 경쟁에서 바로 밀려나는 실패와는 달라요. 브랜드와 현금, 기존 고객이 버팀목이 되면 내부 기술 기반이 약해진 채로도 오래 살아남을 수 있다는 설명이에요. 1
글은 멕시코테트라라는 물고기를 비유로 들어요. 같은 종이라도 강에서는 눈을 쓰지만 동굴에서는 시각 조직의 발달이 억제돼요. 저자는 엔지니어의 역량도 조직 환경이 보상하지 않으면 겉으로 드러나지 않는다고 봐요. 이 비유는 과학적 조직 진단 도구라기보다, 환경과 행동의 관계를 이해하기 위한 관점으로 읽는 편이 맞아요. 2
빠른 채용이 회사의 기준을 바꿔요
급성장기에는 정해진 기간 안에 많은 사람을 뽑아야 해요. 채용 목표를 맞추려고 기준을 낮추면, 외부 경험이 적고 사내 방식만 익힌 구성원이 곧 다음 면접관이 될 수 있어요. 이런 과정이 반복되면 ‘좋은 엔지니어링’보다 ‘지금의 혼란에서 무리 없이 일하는 능력’이 선택 기준으로 굳어요.
문제는 구성원의 선의나 실력 부족만으로 설명하기 어려워요. 조직이 어떤 행동에 시간과 보상을 주는지가 더 직접적인 원인이에요. 자동화나 문서화를 제안해도 우선순위 밖으로 밀리고, 장애 때마다 숙련자의 대기로 해결하면 사람들은 그 방식에 적응해요. 개선안을 계속 내는 쪽이 오히려 일을 복잡하게 만든다는 평가를 받을 수도 있어요.
좋은 실적이 기술 부채를 가릴 수 있어요
외부에서 보는 지표는 멀쩡할 수 있어요. 브랜드는 강하고 마진도 유지되며 직원 수도 늘어요. 내부에서는 작성자만 실행할 수 있는 빌드 파이프라인, 고참이 붙어 있어야 하는 배포, 믿기 어려운 사내 위키가 일상으로 남을 수 있어요.
경영진이 매출과 기술 기반을 같은 건강 지표로 보면 이 차이를 놓쳐요. 배포 성공률, 변경 실패율, 복구 시간, 신규 구성원의 첫 배포까지 걸리는 시간처럼 개발 흐름을 직접 보여주는 수치가 필요한 이유예요. 특정 담당자가 휴가를 갔을 때 멈추는 업무가 무엇인지 확인하는 것도 단순하지만 꽤 정확한 점검법이에요.
우수성 센터가 답이 아닐 수도 있어요
문제가 커지면 표준과 모범 사례를 관리하는 우수성 센터를 만들기 쉬워요. 공통 도구와 지원 체계를 제공한다면 도움이 돼요. 반대로 모든 템플릿과 절차를 중앙에서 정하고 현업에 의무로 부과하면, 실제 결과를 책임지는 팀의 판단권이 줄어요.
좋은 기준은 현업이 더 안전하고 빠르게 일하도록 도와야 해요. 승인 단계만 늘리거나 문서 작성 자체를 목표로 삼으면 기존 관료주의에 새 이름을 붙인 셈이 돼요. 중앙 팀은 통제자가 아니라 반복되는 문제를 제거하는 지원 조직에 가까워야 해요.
왜 중요한가요
성장 중인 회사라면 채용 인원보다 역량이 재생산되는 방식을 봐야 해요. 새로 합류한 엔지니어가 기존 문제를 발견하고 말할 수 있는지, 개선 제안이 실제 작업 시간으로 배정되는지, 핵심 운영 지식이 여러 사람에게 전달되는지 확인해야 해요.
진단은 거창할 필요가 없어요. 빌드와 배포를 처음 온 사람이 문서만 보고 수행할 수 있는지 시험해 보세요. 최근 장애에서 특정 고참의 기억에 의존한 순간도 찾아보세요. 같은 문제가 반복된다면 개인의 헌신으로 버티기보다 자동화와 문서화에 시간을 배정해야 해요.
이 글의 관점이 모든 대기업이나 장수 기업에 그대로 맞는 건 아니에요. 안정적인 시장에서도 기술 기반을 꾸준히 관리하는 회사가 있고, 중앙 표준이 규제와 보안 때문에 꼭 필요한 경우도 있어요. 다만 실적이 좋다는 이유만으로 개발 조직까지 건강하다고 결론 내리면, 문제를 발견할 시기를 놓칠 수 있어요. 2
참고 자료
- 성공한 기업은 어떻게 눈이 멀어가는가 — GeekNews
- How Successful Companies Go Blind — Ian Reppel
'IT & AI' 카테고리의 다른 글
| 스타링크 위성 10만 기 신청, 속도보다 먼저 봐야 할 조건 (0) | 2026.07.12 |
|---|---|
| 초지능 경쟁을 2040년까지 늦추자는 Plan A의 설계 (0) | 2026.07.12 |
| Git diff를 함수 단위로 읽는 sem, 코드 변경 추적이 달라져요 (0) | 2026.07.12 |
| AI로 법령을 읽고, 대한민국 제도 100개를 한 장에 담았어요 (0) | 2026.07.11 |
| AI가 코드를 써도 중복은 빚으로 남아요 (0) | 2026.07.11 |