<div id="readability-page-1" class="page"><div><blockquote>
<p><a href="https://doong-jo.github.io/posts/why-dev-team-priority-must-be-business-first.html">원문</a>은 제 개인 블로그에서 확인하실 수 있어요.</p>
</blockquote>
<h2 id="두-가지-경험">두 가지 경험</h2>
<p>커리어 초기에는 기술 자체가 좋았습니다. 코드를 깔끔하게 작성하는 것, 생산성을 높이는 도구를 만드는 것, 구조를 개선하는 것. 그 자체가 의미 있다고 느꼈고, 그런 일에 시간을 쏟는 것이 당연하다고 생각했습니다.</p>
<p>그런데 두 가지 경험이 그 생각을 바꾸었습니다.</p>
<p>첫 번째는 회사에서 겪은 일입니다. 당시 우리 팀은 사업에 집중해야 할 시점에 기술에 너무 많은 자원을 투자했습니다. 내부 인프라를 고도화하고, 범용 라이브러리를 만들고, 개발 환경을 정비하는 데 공을 들였습니다. 매출 부진이 꼭 개발에만 집중했기 때문은 아니었습니다. 그럼에도 가장 수익성이 나지 않는 팀이 사라질 수밖에 없었고, 제품 개발과 직접적으로 연관이 있지 않은 엔지니어들(인프라를 담당하거나 내부 라이브러리를 만들던 동료들)이 회사를 떠나야 했습니다. 개인의 잘못이 아니었습니다. 하지만 그 장면은 오래 기억에 남았습니다.</p>
<p>두 번째는 창업을 경험할 때 입니다. 2주 동안 열심히 기능을 만들었습니다. 코드도 깔끔히 잘 작성했다고 자부했습니다. 그런데 출시하고 보니 아무도 그 기능을 사용하지 않았습니다. 허무했습니다. 그때 깨달았습니다. 빠른 출시와 높은 코드 품질 중 하나를 선택해야 한다면, 답은 빠른 출시라는 것을. 사실 머리로는 알지만 기술적인 면도 놓치고 싶지 않은 엔지니어의 성향을 못버렸던 것 같습니다. 물론 둘 다 잘하면 좋겠지만, 고객에게 닿지 않은 코드는 아무리 훌륭해도 의미가 없었습니다.</p>
<h2 id="기준이-없으면-주장이-강한-사람이-이깁니다">기준이 없으면 주장이 강한 사람이 이깁니다</h2>
<p>이 경험들을 되새기다 보니, 팀 안에서 반복적으로 목격하는 장면이 겹쳐 보였습니다.</p>
<p>누군가는 DX(개발자 경험)를 가장 중요하게 생각하고, 누군가는 클린 코드를, 누군가는 제품 개발 속도를 우선합니다. 저마다 자신의 우선순위가 옳다고 생각하고, 그 기준에서 일을 합니다. 팀 전체가 합의한 기준이 없으니 각자의 직관과 선호가 충돌합니다.</p>
<p>그 충돌의 결과는 대개 정해져 있습니다. 주장이 강하고 고집이 센 사람, 또는 경력이 많거나 오래 다닌 사람의 의지대로 흘러갑니다. 논리가 이기는 것이 아니라, 영향력이 이깁니다.</p>
<p>자신의 아이디어나 제안이 받아들여지지 않을 때, 그 이유를 납득할 수 없으면 답답하고 화가 나기 마련입니다. 그리고 자신의 의견을 관철시키기 위해 설득하고 싸우는 데도 에너지가 들어갑니다. 이 모든 것이 불필요한 비용입니다. 일 자체가 아니라, 우선순위를 둘러싼 소모전에 에너지가 낭비됩니다.</p>
<h2 id="우리의-코드는-왜-존재하는가">우리의 코드는 왜 존재하는가</h2>
<p>이 문제는 결국 하나의 질문으로 귀결됩니다. <strong>우리는 왜 고용되었는가.</strong></p>
<p>엔지니어는 매일 코드를 작성합니다. 그 코드를 장인 정신으로 깔끔하게 작성하고 싶은 욕구는 자연스럽고, 저도 충분히 이해합니다. 하지만 코드는 비즈니스를 구현하기 위해 존재합니다. 클린 아키텍처와 멋진 개발 환경이 목적의 본질이 아닙니다.</p>
<p>비즈니스의 본질은 단순합니다. <strong>매출을 늘리거나, 비용을 줄이는 것.</strong> 우리가 만드는 기능, 우리가 고치는 버그, 우리가 개선하는 시스템은 결국 이 두 가지 중 하나에 기여해야 합니다. 그렇지 않다면, 그 일의 우선순위는 진지하게 따져볼 필요가 있습니다.</p>
<h2 id="비즈니스-중심의-우선순위">비즈니스 중심의 우선순위</h2>
<p>이 관점에서 정리한 우선순위 기준은 다음과 같습니다.</p>
<ol>
<li><strong>장애 / 서비스 문제</strong></li>
<li><strong>고객 기능 개발</strong></li>
<li><strong>개발 생산성 개선 </strong>(반복적인 낭비 제거)</li>
<li><strong>구조 개선 / 리팩토링</strong></li>
</ol>
<p>누군가는 이렇게 반문할 수 있습니다. "그러면 서비스의 버그 수정이나, 기능을 개발하는 일만 계속하게 되는 것 아닌가요?" 엔지니어로써 더 다양한 기술적인 경험과 깊이를 채우고 싶은 마음을 이해하지 못하는 것은 아닙니다. 하지만 그렇게 해야 합니다. 회사는 (그렇게 마케팅하는 곳도 있지만)자아실현 하는 곳이 아닌 본질은 이익 창출을 목적으로 하는 곳입니다. 1번과 2번은 결과가 실제 고객에게 닿는 일이기에 당연히 그 일들을 먼저 해야합니다.</p>
<p>3번과 4번은 다릅니다. 결과물이 고객에게 직접 전달되지 않습니다. 따라서 그 일이 기능 개발보다 우선순위가 높아지려면 반드시 임팩트를 따져봐야 합니다.</p>
<p><code>임팩트 = (낭비되는 시간) × (영향받는 사람 수) × (발생 빈도)</code></p>
<p>이 공식으로 계산한 임팩트가 충분하지 않다면, 또는 측정할 수 없다면 과감히 포기하거나 미루는 것이 옳다고 생각합니다. 3번과 4번에 해당하는 일이 가치 없다는 뜻이 아닙니다. 기능 개발의 우선순위를 매출과 사용자 획득 지표를 가지고 예상 임팩트를 예상하여 우선순위를 정하듯 기술 집약적인 일들도 측정 가능한 근거가 필요하다는 뜻입니다. 이렇게 임팩트를 측정한 내용들을 기반으로 팀을 설득하여 우선순위를 조정할 때도 큰 도움이 됩니다.</p>
<h2 id="원칙이-주는-자유">원칙이 주는 자유</h2>
<p>우선순위 기준이 팀 안에 명확히 존재하면, 감정 소모가 줄어듭니다. 내 아이디어와 제안이 지금 채택되지 않았을 때, 그 이유를 납득할 수 있습니다. "지금 우리 팀의 우선순위상 2번인 고객 기능 개발이 더 급하기 때문에, 내가 제안한 리팩토링은 지금 시점에 적절하지 않다"는 것을 이해할 수 있게 됩니다. 반박이 아니라 납득입니다.</p>
<p>반대로, 지금 하고 있는 일이 왜 중요한지도 명확해집니다. 우선순위 기준이 있으면 팀 전체가 같은 언어로 대화할 수 있습니다. 설득의 근거가 개인의 선호가 아니라, 비즈니스 임팩트가 됩니다.</p>
<p>기준은 제약이 아닙니다. 오히려 불필요한 논쟁과 소모전에서 팀을 자유롭게 합니다. 우선순위 원칙 없이 각자 다른 방향을 보는 팀은, 결국 에너지를 일이 아닌 충돌에 씁니다.</p>
<p>어떤 팀에 있든, 한 번쯤은 물어볼 만한 질문이 있습니다. "우리 팀의 우선순위 기준은 무엇인가?" 그 대답이 팀원마다 다르다면, 그것 자체가 이미 문제의 시작입니다.</p></div></div>

sdong001.log

원문은 제 개인 블로그에서 확인하실 수 있어요.
두 가지 경험
커리어 초기에는 기술 자체가 좋았습니다. 코드를 깔끔하게 작성하는 것, 생산성을 높이는 도구를 만드는 것, 구조를 개선하는 것. 그 자체가 의미 있다고 느꼈고, 그런 일에 시간을 쏟는 것이 당연하다고 생각했습니다.
그런데 두 가지 경험이 그 생각을 바꾸었습니다.
첫 번째는 회사에서 겪은 일입니다. 당시 우리 팀은 사업에 집중해야 할 시점에 기술에 너무 많은 자원을 투자했습니다. 내부 인프라를 고도화하고, 범용 라이브러리를 만들고, 개발 환경을 정비하는 데 공을 들였습니다. 매출 부진이 꼭 개발에만 집중했기 때문은 아니었습니다. 그럼에도 가장 수익성이 나지 않는 팀이 사라질 수밖에 없었고, 제품 개발과 직접적으로 연관이 있지 않은 엔지니어들(인프라를 담당하거나 내부 라이브러리를 만들던 동료들)이 회사를 떠나야 했습니다. 개인의 잘못이 아니었습니다. 하지만 그 장면은 오래 기억에 남았습니다.
두 번째는 창업을 경험할 때 입니다. 2주 동안 열심히 기능을 만들었습니다. 코드도 깔끔히 잘 작성했다고 자부했습니다. 그런데 출시하고 보니 아무도 그 기능을 사용하지 않았습니다. 허무했습니다. 그때 깨달았습니다. 빠른 출시와 높은 코드 품질 중 하나를 선택해야 한다면, 답은 빠른 출시라는 것을. 사실 머리로는 알지만 기술적인 면도 놓치고 싶지 않은 엔지니어의 성향을 못버렸던 것 같습니다. 물론 둘 다 잘하면 좋겠지만, 고객에게 닿지 않은 코드는 아무리 훌륭해도 의미가 없었습니다.
기준이 없으면 주장이 강한 사람이 이깁니다
이 경험들을 되새기다 보니, 팀 안에서 반복적으로 목격하는 장면이 겹쳐 보였습니다.
누군가는 DX(개발자 경험)를 가장 중요하게 생각하고, 누군가는 클린 코드를, 누군가는 제품 개발 속도를 우선합니다. 저마다 자신의 우선순위가 옳다고 생각하고, 그 기준에서 일을 합니다. 팀 전체가 합의한 기준이 없으니 각자의 직관과 선호가 충돌합니다.
그 충돌의 결과는 대개 정해져 있습니다. 주장이 강하고 고집이 센 사람, 또는 경력이 많거나 오래 다닌 사람의 의지대로 흘러갑니다. 논리가 이기는 것이 아니라, 영향력이 이깁니다.
자신의 아이디어나 제안이 받아들여지지 않을 때, 그 이유를 납득할 수 없으면 답답하고 화가 나기 마련입니다. 그리고 자신의 의견을 관철시키기 위해 설득하고 싸우는 데도 에너지가 들어갑니다. 이 모든 것이 불필요한 비용입니다. 일 자체가 아니라, 우선순위를 둘러싼 소모전에 에너지가 낭비됩니다.
우리의 코드는 왜 존재하는가
이 문제는 결국 하나의 질문으로 귀결됩니다. 우리는 왜 고용되었는가.
엔지니어는 매일 코드를 작성합니다. 그 코드를 장인 정신으로 깔끔하게 작성하고 싶은 욕구는 자연스럽고, 저도 충분히 이해합니다. 하지만 코드는 비즈니스를 구현하기 위해 존재합니다. 클린 아키텍처와 멋진 개발 환경이 목적의 본질이 아닙니다.
비즈니스의 본질은 단순합니다. 매출을 늘리거나, 비용을 줄이는 것. 우리가 만드는 기능, 우리가 고치는 버그, 우리가 개선하는 시스템은 결국 이 두 가지 중 하나에 기여해야 합니다. 그렇지 않다면, 그 일의 우선순위는 진지하게 따져볼 필요가 있습니다.
비즈니스 중심의 우선순위
이 관점에서 정리한 우선순위 기준은 다음과 같습니다.
장애 / 서비스 문제
고객 기능 개발
*개발 생산성 개선 *(반복적인 낭비 제거)
구조 개선 / 리팩토링
누군가는 이렇게 반문할 수 있습니다. "그러면 서비스의 버그 수정이나, 기능을 개발하는 일만 계속하게 되는 것 아닌가요?" 엔지니어로써 더 다양한 기술적인 경험과 깊이를 채우고 싶은 마음을 이해하지 못하는 것은 아닙니다. 하지만 그렇게 해야 합니다. 회사는 (그렇게 마케팅하는 곳도 있지만)자아실현 하는 곳이 아닌 본질은 이익 창출을 목적으로 하는 곳입니다. 1번과 2번은 결과가 실제 고객에게 닿는 일이기에 당연히 그 일들을 먼저 해야합니다.
3번과 4번은 다릅니다. 결과물이 고객에게 직접 전달되지 않습니다. 따라서 그 일이 기능 개발보다 우선순위가 높아지려면 반드시 임팩트를 따져봐야 합니다.
임팩트 = (낭비되는 시간) × (영향받는 사람 수) × (발생 빈도)
이 공식으로 계산한 임팩트가 충분하지 않다면, 또는 측정할 수 없다면 과감히 포기하거나 미루는 것이 옳다고 생각합니다. 3번과 4번에 해당하는 일이 가치 없다는 뜻이 아닙니다. 기능 개발의 우선순위를 매출과 사용자 획득 지표를 가지고 예상 임팩트를 예상하여 우선순위를 정하듯 기술 집약적인 일들도 측정 가능한 근거가 필요하다는 뜻입니다. 이렇게 임팩트를 측정한 내용들을 기반으로 팀을 설득하여 우선순위를 조정할 때도 큰 도움이 됩니다.
원칙이 주는 자유
우선순위 기준이 팀 안에 명확히 존재하면, 감정 소모가 줄어듭니다. 내 아이디어와 제안이 지금 채택되지 않았을 때, 그 이유를 납득할 수 있습니다. "지금 우리 팀의 우선순위상 2번인 고객 기능 개발이 더 급하기 때문에, 내가 제안한 리팩토링은 지금 시점에 적절하지 않다"는 것을 이해할 수 있게 됩니다. 반박이 아니라 납득입니다.
반대로, 지금 하고 있는 일이 왜 중요한지도 명확해집니다. 우선순위 기준이 있으면 팀 전체가 같은 언어로 대화할 수 있습니다. 설득의 근거가 개인의 선호가 아니라, 비즈니스 임팩트가 됩니다.
기준은 제약이 아닙니다. 오히려 불필요한 논쟁과 소모전에서 팀을 자유롭게 합니다. 우선순위 원칙 없이 각자 다른 방향을 보는 팀은, 결국 에너지를 일이 아닌 충돌에 씁니다.
어떤 팀에 있든, 한 번쯤은 물어볼 만한 질문이 있습니다. "우리 팀의 우선순위 기준은 무엇인가?" 그 대답이 팀원마다 다르다면, 그것 자체가 이미 문제의 시작입니다.

개발팀의 우선순위가 비즈니스 중심이어야 하는 이유

댓글