<div id="readability-page-1" class="page"><div><article><p><img src="https://get6.github.io/blog/external/e563c67dd97906201edee77f24ced4a3.webp" alt="photo by Joshua Sortino(https://unsplash.com/@sortino?utm_source=templater_proxy&amp;utm_medium=referral) on Unsplash"></p>
<p>기능을 빨리 만드는 것보다 더 중요한 게 있어요. 바로 "<strong>검증 가능한 배포 리듬</strong>"이에요. 2주 주기 안에서 테스트, 리팩토링, 가치 검증이 한 세트로 돌아가야 품질과 성장이 같이 가거든요.</p>
<p>이 글에서는 2주 개발 주기를 어떻게 운영하면 좋을지, 그리고 그 중심에 있는 인수테스트 주도 개발(ATDD)을 어떻게 적용하는지 정리해볼게요.</p>
<h2 id="2주-주기의-기본-구조">2주 주기의 기본 구조<a href="#2주-주기의-기본-구조"><span>#</span></a></h2>
<p>2주라는 시간을 그냥 흘려보내지 않으려면, 시작·중반·종료마다 해야 할 일이 명확해야 해요.</p>
<ol>
<li><strong>주기 시작</strong> — 피처 목표와 인수기준(AC)을 확정해요</li>
<li><strong>주기 중반</strong> — 피처별 테스트 시나리오를 구체화해요</li>
<li><strong>주기 종료</strong> — 비즈니스 테스트를 수행하고 회고해요</li>
</ol>
<p>핵심은 주기가 끝날 때마다 <strong>비즈니스 테스트</strong>를 수행한다는 점이에요. 마일스톤 안에 테스트 항목을 명시하고, 기존 테스트와 신규 테스트가 모두 통과해야 그 주기가 끝나요.</p>
<h2 id="테스트-게이트-결함-상태로-배포하지-않기">테스트 게이트: 결함 상태로 배포하지 않기<a href="#테스트-게이트-결함-상태로-배포하지-않기"><span>#</span></a></h2>
<p>배포 전에 반드시 통과해야 하는 게이트를 정해두면 판단이 흔들리지 않아요.</p>
<ul>
<li><strong>신규 테스트 통과</strong> — 이번 주기에 추가된 기능의 테스트</li>
<li><strong>회귀 테스트 통과</strong> — 기존 기능이 깨지지 않았는지 확인</li>
<li><strong>결함 허용 기준 명확화</strong> — 치명/중요/경미로 등급을 나눠요</li>
<li><strong>치명 결함 존재 시 배포 보류</strong> — 결함 상태로는 배포하지 않아요</li>
</ul>
<p>"이 정도는 괜찮겠지"라는 판단이 개입할 여지를 줄이는 게 게이트의 역할이에요.</p>
<h2 id="atdd를-적용하는-방법">ATDD를 적용하는 방법<a href="#atdd를-적용하는-방법"><span>#</span></a></h2>
<p>ATDD(인수테스트 주도 개발)는 요구사항을 <strong>인수 테스트 시나리오로 먼저 정의</strong>하고, 그 시나리오를 기준으로 구현과 검증을 진행하는 방식이에요.</p>
<p>이 방식의 큰 장점은 커뮤니케이션 비용 절감이에요. 비즈니스 언어와 테스트 언어를 일치시키면, 기획자와 개발자가 같은 문장을 보고 같은 것을 이해할 수 있거든요.</p>
<h2 id="리팩토링은-설계-건강-유지-활동">리팩토링은 설계 건강 유지 활동<a href="#리팩토링은-설계-건강-유지-활동"><span>#</span></a></h2>
<p>리팩토링을 기능 추가처럼 별도 일정으로 잡으면 자꾸 밀리게 돼요. 그래서 관점을 바꿔야 해요.</p>
<ul>
<li>리팩토링은 기능 추가가 아니라 <strong>올바른 설계를 유지하는 활동</strong>이에요</li>
<li>피처 단위 개발마다 작은 리팩토링을 함께 수행해요</li>
<li>테스트가 리팩토링의 <strong>안전망</strong> 역할을 해줘요</li>
</ul>
<p>테스트가 탄탄하면 리팩토링을 두려워할 이유가 없어요. 이게 앞서 말한 테스트 게이트와 리팩토링이 한 세트로 묶이는 이유예요.</p>
<h2 id="무엇을-만들지-판단하는-가치-프레임">무엇을 만들지 판단하는 가치 프레임<a href="#무엇을-만들지-판단하는-가치-프레임"><span>#</span></a></h2>
<p>무엇을 개발할지 정할 때는 세 가지 가치를 기준으로 판단해요.</p>
<ol>
<li><strong>사용자 가치</strong> — 실제 문제를 해결하는가</li>
<li><strong>비즈니스 가치</strong> — 지속 가능한 성장과 수익에 기여하는가</li>
<li><strong>개인/팀 가치</strong> — 우리가 중요하게 보는 철학과 일치하는가</li>
</ol>
<p>순서도 중요해요. 사용자 가치를 먼저 개발하고, 정보를 수집·평가한 뒤에 비즈니스 가치로 연결하는 흐름이에요. 그리고 남을 위한 가치뿐 아니라 <strong>내가 중요하다고 보는 가치</strong>도 반영해야 지속할 수 있어요.</p>
<h2 id="이런-문화는-채용에서도-어필이-돼요">이런 문화는 채용에서도 어필이 돼요<a href="#이런-문화는-채용에서도-어필이-돼요"><span>#</span></a></h2>
<p>이런 운영 방식은 외부 개발자에게도 매력적인 포인트가 돼요.</p>
<ul>
<li>"우리 팀은 ATDD/TDD를 실무에서 체화한다"</li>
<li>"서비스 중심 의사결정과 테스트 문화가 성장의 핵심"</li>
<li>"입사하면 기능 개발뿐 아니라 제품 사고를 배우게 된다"</li>
</ul>
<p>기능 개발 속도만 강조하는 팀보다, 검증 가능한 리듬으로 일하는 팀이 개발자에게는 더 좋은 성장 환경이거든요.</p>
<h2 id="정리하며">정리하며<a href="#정리하며"><span>#</span></a></h2>
<p>2주 주기를 단순한 마감 단위가 아니라 <strong>테스트 게이트, ATDD, 리팩토링, 가치 검증이 함께 도는 리듬</strong>으로 만들어보세요. 속도는 조금 느려 보여도, 결함 없는 배포가 쌓이면 그게 결국 가장 빠른 길이에요.</p>
<hr>
<blockquote><div><p>Your future depends on many things, but mostly on you.</p></div><p>— Frank Tyger</p></blockquote></article></div></div>

이때의 나

sunhwang

기능을 빨리 만드는 것보다 더 중요한 게 있어요. 바로 "검증 가능한 배포 리듬"이에요. 2주 주기 안에서 테스트, 리팩토링, 가치 검증이 한 세트로 돌아가야 품질과 성장이 같이 가거든요. 이 글에서는 2주 개발 주기를 어떻게 운영하면 좋을지, 그리고 그 중심에 있는 인수테스트 주도 개발(ATDD)을 어떻게 적용하는지 정리해볼게요. 2주 주기의 기본 구조 ...

2주 개발 주기와 ATDD 운영 원칙

댓글