외주 개발을 맡기고 나면 발주자가 자주 놓이는 상태는 "지금 잘 되고 있는지 모르겠다"입니다. 개발사는 순조롭다고 말하는데 손에 잡히는 건 없고, 한참 뒤에 화면을 처음 봤을 때는 이미 되돌리기 어려운 상태인 경우가 있습니다. 스프린트는 이 문제를 방법론으로 푸는 게 아니라 확인 지점을 달력에 못 박아 두는 방식으로 풉니다.
이 글은 이론서 요약이 아닙니다. 개발자가 스프린트를 어떻게 돌리는지가 아니라 발주자가 2주마다 무엇을 요구하고 무엇을 확인하는지를 다룹니다. 다음 미팅에서 바로 꺼낼 수 있는 문장과 기준만 남겼습니다.
스프린트는 고정된 기간 하나를 작업 단위로 잘라, 그 안에서 계획과 개발과 확인을 한 바퀴 끝내는 운영 방식입니다. 기간은 1주에서 4주 사이로 잡는 경우가 많고, 이 글은 외주에서 자주 쓰이는 2주를 기준으로 씁니다. 중요한 건 기간의 길이가 아니라 그 기간이 끝날 때마다 반드시 무언가를 보여줘야 한다는 강제성입니다.
발주자 입장에서 폭포수와 스프린트의 실질적 차이는 딱 하나입니다. 폭포수는 범위를 고정하고 기간을 밀어서 맞추고, 스프린트는 기간을 고정하고 범위를 조절해서 맞춥니다. 그래서 폭포수에서는 "언제 끝나요"가 흔들리고, 스프린트에서는 "이번에 뭐가 들어가요"가 흔들립니다.
이 차이가 발주자가 쥐는 레버를 바꿉니다. 폭포수에서 발주자가 할 수 있는 건 완성본을 기다렸다가 검수하는 것뿐입니다. 스프린트에서는 2주마다 순서를 다시 정할 권한이 생깁니다. 대신 그 권한을 쓰려면 2주마다 시간을 내야 합니다.
세 단어는 서로 다른 층에 있습니다. 애자일은 사고방식입니다. 한 번에 완성해서 넘기는 대신 짧게 만들고 확인하고 고치자는 태도에 가깝습니다. 스크럼은 그 태도를 팀 운영 규칙으로 옮긴 틀입니다. 역할과 회의와 산출물의 이름이 정해져 있습니다. 스프린트는 스크럼 안에서 작업을 잘라 담는 기간 단위입니다.
발주자 각도로 다시 쓰면 이렇습니다. 애자일은 "왜 짧게 끊는가"에 대한 답이고, 스크럼은 "누가 어떤 회의에 들어가는가"에 대한 답이고, 스프린트는 "그래서 언제 무엇을 받는가"에 대한 답입니다. 발주자가 매일 쓰게 되는 건 세 번째입니다. 앞의 둘은 개발사 내부 운영에 가깝고, 발주자가 관여할 여지가 적습니다.
그래서 개발사가 "저희는 애자일로 합니다"라고 말해도 그 말만으로는 확인할 항목이 생기지 않습니다. 스크럼을 규칙대로 돌리는 팀도 있고, 회의 이름만 빌려 쓰는 팀도 있고, 방법론 이름 없이 2주씩 끊는 팀도 있습니다. 셋 다 그 자체로 문제는 아닙니다.
발주자가 물어야 할 것은 방법론의 이름이 아니라 "몇 주마다, 무엇을, 어떤 형태로 받게 되나요" 한 문장입니다. 이 글의 나머지는 그 한 문장을 푸는 데 씁니다. 개발사가 스크럼이라고 부르든 자기 식 2주 사이클이라고 부르든, 발주자가 확인할 것은 같습니다.
외주는 구조적으로 정보가 한쪽에 몰립니다. 개발사는 코드와 일정과 남은 작업을 다 보고 있고, 발주자는 회의록과 구두 보고만 봅니다. 이 격차는 개발사가 성실해도 사라지지 않습니다. 볼 수 있는 통로 자체가 없기 때문입니다.
스프린트는 그 통로를 2주마다 강제로 엽니다. 개발사는 "지금 잘 되고 있습니다"라고 말할 수 없고, 눌러볼 수 있는 화면을 내놓아야 합니다. 말과 결과물이 어긋나면 그 자리에서 드러납니다.
손실의 크기도 달라집니다. 요구를 잘못 전달했거나 개발사가 잘못 이해했을 때, 폭포수에서는 그 오해가 다음 확인 지점까지 계속 자랍니다. 스프린트에서는 최대 2주치에서 멈춥니다. 발주자가 얻는 실익은 "빨리 만든다"가 아니라 "틀린 걸 늦게 알지 않는다"입니다.
한 가지 더 있습니다. 개발사가 인력을 뺐거나 다른 프로젝트에 밀렸을 때, 그 신호가 산출물의 빈틈으로 먼저 나타납니다. 계약서를 아무리 잘 써도 그 사실을 한참 뒤에 알면 손쓸 방법이 줄어듭니다.
받아야 할 것은 네 가지입니다. 첫째, 직접 눌러볼 수 있는 화면. 둘째, 이번 스프린트에서 계획했는데 못 끝낸 항목의 목록. 셋째, 다음 2주에 하겠다는 항목의 목록. 넷째, 개발사가 발주자에게 요청하는 결정 사항입니다.
이 중에서 발주자가 자주 빠뜨리는 게 두 번째입니다. 완료된 것만 보고받으면 이월된 작업이 조용히 쌓이고, 마지막 스프린트에 한꺼번에 터집니다. 못 끝낸 항목을 명시적으로 요구하는 것이 스프린트 운영에서 발주자가 하는 실질적인 행동입니다.
반대로 받지 않아도 되는 것도 있습니다. 전체 진행률 퍼센트, 작성한 코드 줄 수, 투입 시간 집계 같은 숫자는 발주자가 검증할 수 없는 수치입니다. 검증할 수 없는 숫자는 안심의 근거가 아니라 판단을 흐리는 요소입니다.
"동작하는 화면"이라는 말은 개발사와 발주자가 미팅에서 실제로 어긋나는 표현입니다. 어긋나지 않으려면 세 층으로 갈라서 말해야 합니다.
첫째 층은 디자인 시안입니다. 이미지 파일이고 클릭되지 않습니다. 둘째 층은 클릭되는 목업입니다. 화면이 넘어가지만 입력한 값은 저장되지 않고, 보이는 데이터는 미리 박아둔 가짜입니다. 셋째 층은 실제로 저장되고 다시 불러와지는 화면입니다.
스프린트 산출물로 인정할 것은 셋째 층입니다. 판별법은 간단합니다. 내가 값을 입력하고, 브라우저를 완전히 껐다가 다시 켜서 그 값이 남아 있으면 셋째 층입니다. 남아 있지 않으면 목업입니다.
확인 방식도 정해두는 게 좋습니다. 개발사가 화면을 공유하며 시연하는 것과, 발주자가 스테이징 주소와 테스트 계정을 받아 자기 노트북에서 눌러보는 것은 다릅니다. 시연은 준비된 경로만 지나가지만, 직접 눌러보면 준비되지 않은 경로에서 무엇이 깨지는지가 보입니다.
첫 2주는 다른 스프린트와 성격이 다릅니다. 개발 환경을 세우고 저장소를 만들고 배포 경로를 뚫는 작업이 들어가기 때문에, 눈에 보이는 화면은 얇게 나올 수 있습니다. 이걸 성과 부진으로 오해하고 압박하면 오히려 기반 작업을 건너뛴 채로 진행되어 나중에 비용이 커집니다.
다만 첫 스프린트에서도 반드시 확보해야 할 것이 있습니다. 스테이징 환경 주소와 테스트 계정, 코드 저장소 접근 권한, 배포가 실제로 한 번 돌아간 기록입니다. 화면이 한 장뿐이어도 이 세 가지가 있으면 이후 스프린트는 확인 가능한 상태로 굴러갑니다.
저장소 접근 권한을 첫 스프린트에 받아두는 게 특히 중요합니다. 프로젝트 후반에 요청하면 인수인계 협상처럼 취급되지만, 첫 주에 요청하면 절차의 일부로 처리됩니다. 코드를 읽을 줄 몰라도 상관없습니다. 권한이 계정에 걸려 있다는 사실 자체가 나중에 상황이 나빠졌을 때 선택지를 남깁니다. 첫날부터 이름을 걸어둬야 할 자산이 저장소 말고도 여럿이라, 목록은 2026년 IT 외주 개발 인수인계 완전 가이드에서 한 번에 확인하는 편이 빠릅니다.
첫 스프린트 리뷰에서 물을 질문은 하나로 충분합니다. "다음 스프린트부터는 제가 직접 눌러볼 수 있는 화면을 받게 되나요"입니다. 여기서 답이 흐리면 산출물의 형태를 그 자리에서 문서로 정해두는 편이 낫습니다.
리뷰는 길 필요가 없습니다. 30분에서 60분 안에 끝나는 게 서로에게 낫고, 길어진다면 그건 리뷰가 아니라 설계 회의가 섞인 것입니다. 아래는 발주자가 그 시간 안에 확인할 항목입니다.
| 확인 항목 | 발주자가 하는 행동 | 통과 기준 | 이걸 안 하면 생길 수 있는 일 |
|---|---|---|---|
| 산출물 접근 | 스테이징 주소와 테스트 계정을 받아 직접 연다 | 내 기기에서 열리고 로그인된다 | 시연에서만 되는 화면을 완성으로 착각한다 |
| 데이터 잔존 | 값을 넣고 브라우저를 껐다 다시 연다 | 넣은 값이 그대로 보인다 | 목업을 인수 대상으로 잘못 센다 |
| 이월 항목 | 계획했는데 못 끝낸 목록을 문서로 받는다 | 항목별로 남은 이유가 한 줄씩 있다 | 이월분이 마지막 스프린트에 몰린다 |
| 다음 계획 | 다음 2주 항목을 백로그 순서와 대조한다 | 순서와 어긋난 항목마다 지금 하지 않으면 나중에 무엇이 더 드는지 설명을 들었다 | 기술적으로 편한 순서대로 개발이 흘러간다 |
| 결정 요청 | 개발사가 막혀 있는 결정을 받아 적고 기한을 준다 | 결정마다 담당자와 회신일이 적힌다 | 개발이 발주자 답변 대기로 멈춘다 |
표의 마지막 줄이 실무에서 자주 무너지는 지점입니다. 개발이 멈추는 원인이 개발사가 아니라 발주자의 미결정인 경우도 있습니다. 리뷰에서 결정 요청을 받아 적고 회신일을 적어두면 나중에 책임 소재를 다툴 일이 줄어듭니다.
백로그는 아직 만들지 않은 것 전부를 한 줄씩 적어 순서를 매겨둔 목록입니다. 요구사항 문서와 다른 점은 순서가 있다는 것입니다. 문서는 무엇을 만들지를 적고, 백로그는 무엇을 먼저 만들지를 적습니다.
스프린트 운영에서 발주자가 실제로 쥐는 권한은 이 순서 하나입니다. 어떻게 만들지는 개발사가 정하고, 무엇을 먼저 만들지는 발주자가 정합니다. 이 경계를 넘나들면 양쪽 다 불편해집니다.
순서를 개발사에 맡기면 악의가 없어도 기술적으로 편한 순서로 흐르기 쉽습니다. 인증과 권한과 관리자 기능처럼 먼저 세워두면 나중이 편한 것들이 앞에 오고, 사업 가설을 검증하는 화면이 뒤로 밀리는 경우가 있습니다. 개발사 입장에서는 합리적인 판단이지만, 발주자 입장에서는 돈이 다 나간 뒤에야 검증할 화면을 만나게 됩니다.
백로그를 처음 세우는 단계에서 범위 자체가 흔들린다면 순서보다 범위가 먼저입니다. 무엇을 넣고 무엇을 뺄지 판단하는 절차는 MVP 범위 확정 절차와 경계 기능 판단에 단계별로 정리해두었습니다.
우선순위는 감이 아니라 질문으로 매깁니다. 항목 하나를 놓고 아래 네 가지를 묻고, 답에 따라 위나 아래로 옮깁니다. 네 질문은 순서대로 통과시키는 관문이 아닙니다. 한 항목에 네 개를 모두 적용해 이동 방향을 모으는 방식입니다. 여러 사람이 각자 중요하다고 말하는 상황에서 이 표가 판정 기준 역할을 합니다.
| 질문 | 예일 때 이동 | 아니오일 때 이동 | 걸러내는 것 |
|---|---|---|---|
| 이게 없으면 서비스가 한 바퀴 돌지 않나요 | 맨 위로 | 현재 순서 유지 | 있으면 좋은 기능이 필수로 둔갑하는 경우 |
| 이번에 확인하려는 사업 가설에 직접 닿나요 | 위쪽 | 현재 순서 유지 | 검증과 무관한 완성도 작업 |
| 나중에 하면 이미 만든 걸 뜯어야 하나요 | 위쪽 | 아래쪽 | 순서를 미뤄 비용이 커지는 구조 작업 |
| 지금 안 정해도 되는 결정을 미리 굳히나요 | 아래로 | 현재 순서 유지 | 이른 확정으로 선택지를 잃는 항목 |
네 질문 중 세 번째와 네 번째가 서로 반대 방향으로 작동합니다. 세 번째는 미루면 비싸지는 것을 앞으로 당기고, 네 번째는 지금 정할 필요가 없는 것을 뒤로 미룹니다. 둘 다 걸리는 항목이 있다면 개발사에 "이걸 지금 안 정하면 나중에 무엇을 다시 만들어야 하는지"를 물어보고 그 답으로 결정하면 됩니다.
순서를 정할 때 금액이나 공수를 기준으로 삼는 건 권하지 않습니다. 공수 추정치는 개발사가 제시하는 숫자이고 발주자가 검증하기 어렵습니다. 발주자가 검증할 수 있는 건 사업적 필요이지 기술적 난이도가 아닙니다.
들어가지 않아도 됩니다. 계획 회의는 개발사가 항목을 쪼개고 공수를 추정하는 자리라 발주자가 판단할 근거가 거의 없습니다. 그 자리에 앉아 있으면 추정치 논쟁에 끌려 들어가기 쉽고, 발주자가 기술적 난이도를 두고 협상하는 이상한 구도가 만들어집니다.
대신 계획 확정본을 문서로 받습니다. 다음 2주에 하겠다는 항목 목록이면 충분하고, 리뷰 전날까지 받는 것으로 정해두면 됩니다. 발주자가 그 문서에서 확인할 것은 두 가지입니다. 내가 정한 백로그 순서와 어긋난 항목이 있는지, 그리고 이번에 이월된 항목이 다시 계획에 들어가 있는지입니다.
순서와 어긋난 항목이 보이면 그 자체를 문제로 삼을 필요는 없습니다. 기술적으로 함께 해야 효율적인 항목이 있어서 순서를 조정한 경우가 있기 때문입니다. 물어볼 것은 "왜 순서를 바꿨나요"가 아니라 "이 항목을 지금 하지 않으면 나중에 무엇이 더 드나요"입니다. 이 질문에는 발주자도 이해할 수 있는 답이 돌아옵니다.
계획 확정본을 매번 받아두면 부수 효과가 하나 더 생깁니다. 나중에 일정을 두고 이견이 생겼을 때, 무엇을 언제 하기로 했는지가 문서로 남아 있습니다. 구두로만 오간 계획은 시간이 지나면 양쪽 기억이 갈라집니다. 소통 기록을 어떤 형태로 남기는지는 2026년 IT 외주 프로젝트 커뮤니케이션 완전 가이드에 유형별로 정리돼 있습니다.
원칙은 진행 중인 스프린트는 잠근다입니다. 2주짜리 계획을 세워두고 사흘째에 항목을 끼워 넣으면, 그 스프린트에서 무엇이 밀렸는지 아무도 설명할 수 없게 됩니다. 잠그는 이유는 개발사를 편하게 해주려는 게 아니라 결과를 해석 가능하게 유지하려는 것입니다.
그래서 스프린트 중 요청은 세 갈래로 처리합니다. 급하지 않으면 다음 스프린트 백로그 최상단에 올립니다. 급하면 지금 스프린트에서 무엇을 빼고 대신 넣을지를 같이 말합니다. 정말 급하면 스프린트를 중단하고 다시 계획하는데, 이건 비용이 발생하는 선택이라는 걸 알고 해야 합니다.
두 번째 갈래가 핵심입니다. "이것도 넣어주세요"는 요청이 아니라 지시이고, "이걸 넣는 대신 무엇을 빼면 되나요"는 협상입니다. 기간이 고정된 방식에서 무언가를 더하려면 무언가는 빠져야 합니다. 이 교환 규칙을 킥오프에서 합의해두면 매 스프린트마다 다시 싸울 일이 없습니다. 킥오프에서 정해야 할 항목은 2026년 IT 외주 개발 킥오프 미팅 완전 가이드에 목록으로 있습니다.
계약된 범위 자체를 넘어서는 요청은 백로그 순서 문제가 아니라 계약 문제입니다. 이때는 스프린트 안에서 처리하지 말고 변경 요청서로 분리해야 금액과 일정이 함께 조정됩니다. 양식과 절차는 2026년 IT 외주 개발 변경 요청서(CR) 작성 완전 가이드에 정리돼 있습니다.
여기서 다루는 건 2주마다 나오는 산출물과 이월 목록만으로 판단하는 방법입니다. 스프린트마다 완료된 항목 개수를 세는 것만으로는 부족합니다. 항목의 크기가 매번 다르기 때문에 개수는 비교 가능한 지표가 아닙니다. 발주자가 볼 것은 개수가 아니라 이월이 반복되는 패턴입니다.
한 스프린트에서 계획한 것 중 일부가 남는 건 정상입니다. 눈여겨볼 것은 같은 항목이 두 번, 세 번 연속으로 이월될 때입니다. 같은 항목이 세 번 연속 이월된다면 그 항목만의 문제가 아닐 가능성을 봐야 합니다. 추정 방식, 투입 인력, 기존 코드 상태 중 무엇이 달라졌는지를 물어볼 시점입니다.
그때 물어볼 질문은 세 가지입니다. 이 항목이 처음 추정보다 커진 이유가 무엇인지, 이번 스프린트에 실제로 투입된 인원이 계약 때와 같은지, 이 작업이 기존 코드의 어떤 부분에 막혀 있는지. 세 질문 모두 발주자가 기술을 몰라도 답을 받아 적을 수 있습니다.
답이 계속 모호하거나 이월이 계속 쌓인다면 그건 이미 지연입니다. 지연을 확인한 다음의 대응 절차는 2026년 IT 외주 개발 일정 지연 대응 완전 가이드에서 단계별로 다룹니다.
국내 외주에서는 계약 시점에 범위와 금액을 확정하는 고정가 방식을 자주 만나게 됩니다. 그래서 "우리는 애자일로 하겠습니다"라고 말해도 계약서는 폭포수인 경우가 생깁니다. 이건 모순이 아니라 계약과 운영을 분리하면 풀리는 문제입니다.
| 구분 | 고정가 폭포수 | 고정가 계약 + 스프린트 운영 | 기간 정액 계약 |
|---|---|---|---|
| 범위가 정해지는 시점 | 계약서 서명 시점 | 계약서에서 총량, 스프린트에서 순서 | 스프린트마다 |
| 변경을 처리하는 방법 | 변경 요청서와 추가 계약 | 범위 안은 교환, 범위 밖은 변경 요청서 | 다음 스프린트에 반영 |
| 발주자가 내야 하는 시간 | 착수와 검수 시점에 집중 | 2주마다 리뷰와 순서 결정 | 상시 |
| 총액 예측 가능성 | 높음 | 높음 | 낮음 |
| 맞는 상황 | 만들 것이 문서로 확정된 경우 | 총액은 묶어야 하는데 세부는 바뀔 수 있는 경우 | 방향 자체를 탐색하는 경우 |
총액은 묶어야 하는데 세부 화면까지 계약 시점에 확정하기는 어렵다면 가운데 열이 맞습니다. 총액이 정해져야 자금 계획이 서고, 그렇다고 아직 결정되지 않은 화면을 계약서에 억지로 적어 넣으면 나중에 그 문장이 발목을 잡습니다. 이 조합을 쓰려면 계약서에 네 문장을 넣으면 됩니다.
이 네 문장이 없으면 스프린트는 구두 약속으로 남습니다. 일정 관련 조항을 계약서에 어떻게 배치하는지는 2026년 IT 외주 개발 일정·마일스톤 관리 완전 가이드에서 항목별로 확인할 수 있습니다.
다릅니다. 이 둘을 구분하지 않은 채 진행하면 프로젝트 끝에서 분쟁이 납니다. 스프린트 리뷰는 방향 확인이고, 최종 검수는 계약상 인수입니다.
리뷰에서 "좋습니다"라고 말한 것이 그 기능을 계약상 인수했다는 뜻이 되면, 발주자는 매 리뷰마다 계약서를 들고 앉아야 합니다. 그러면 리뷰가 무거워지고 결국 형식만 남습니다. 반대로 리뷰에서 통과시킨 걸 최종 검수에서 전부 다시 뒤집으면 개발사가 리뷰를 신뢰하지 않게 됩니다.
실무적으로는 이렇게 갈라두면 됩니다. 리뷰에서는 "이 방향이 맞는가"만 판정하고, 그 자리에서 나온 수정 요청은 백로그로 들어갑니다. 최종 검수는 계약서에 적힌 검수 기준과 절차에 따라 별도로 진행합니다. 검수 절차와 사인오프 문서는 2026년 IT 외주 개발 산출물 검수·사인오프 완전 가이드를 참고하세요.
결제를 스프린트에 붙일지도 미리 정해야 합니다. 스프린트마다 결제하면 관리가 번거롭고, 착수금과 잔금 두 번으로만 나누면 중간에 문제가 생겼을 때 쓸 카드가 없습니다. 단계를 나누는 방식은 2026년 IT 외주 개발 마일스톤 결제 구조 설계 가이드에 유형별로 정리돼 있습니다.
AI 기능이 들어가면 스프린트 산출물의 성격이 한 구간에서 바뀝니다. 일반 기능은 "버튼을 누르면 저장된다"로 확인이 끝나지만, 챗봇이나 문서 처리 같은 기능은 같은 입력에도 결과가 달라질 수 있어서 동작 여부만으로는 확인이 끝나지 않습니다.
그래서 이런 프로젝트에서는 스프린트 산출물이 화면 하나가 아니라 평가용 질문 목록과 그에 대한 응답 결과표가 되는 구간이 생깁니다. 발주자가 리뷰에서 받을 것은 그 결과표이고, 지난 스프린트와 같은 형식으로 놓고 어느 항목이 좋아지고 어느 항목이 나빠졌는지를 봅니다. 평가셋을 어떻게 설계하고 인수 기준을 계약서에 어떻게 적는지는 2026년 IT 외주 개발 AI·LLM 기능 발주 완전 가이드에 따로 정리돼 있습니다. 이 글에서 정하는 건 하나입니다. 그 결과표를 2주마다 받는 고정 산출물로 잡는다는 것입니다.
맡길 팀을 고를 때도 기준이 갈립니다. 앱이나 웹 서비스를 만들고 그 안에 AI 기능이 하나 들어가는 형태라면 프로덕트 개발팀이 맡는 게 맞습니다. 포텐랩이 그 영역을 맡습니다. 반대로 AI 자체가 제품인 경우, 예를 들어 사내 문서를 검색하는 챗봇이나 검색 증강 방식의 지식 시스템처럼 응답 품질이 제품의 본질인 경우는 트리숲(TreeSoop)이 맡습니다. 맞지 않는 쪽에 맡기면 스프린트마다 확인해야 할 것이 서로 어긋나서 양쪽 다 손해입니다.
스프린트라는 말만 쓰고 실제로는 폭포수로 굴러가는 경우가 있습니다. 아래 신호가 보이면 리뷰에서 바로 물어보는 게 좋습니다.
| 보이는 신호 | 실제로 벌어지고 있을 수 있는 일 | 다음 리뷰에서 던질 질문 |
|---|---|---|
| 리뷰가 화면 공유 시연으로만 끝난다 | 발주자가 직접 열 수 있는 환경이 없다 | 제가 접속할 주소와 계정을 언제 받을 수 있나요 |
| 이월 항목 목록을 준 적이 없다 | 계획 대비 실적을 추적하지 않는다 | 이번에 계획했다가 못 끝낸 항목이 무엇인가요 |
| 백로그 순서를 발주자가 본 적이 없다 | 순서를 개발사가 단독으로 정하고 있다 | 다음 2주 항목 목록을 리뷰 전날까지 주실 수 있나요 |
| 매번 "거의 다 됐습니다"가 반복된다 | 완료 기준이 합의돼 있지 않다 | 이 항목이 끝났다고 판단하는 기준이 무엇인가요 |
| 리뷰 날짜가 계속 미뤄진다 | 내놓을 산출물이 없다 | 날짜는 유지하고 완성된 범위만 보여주시면 어떨까요 |
마지막 줄이 실무에서 특히 쓸모 있는 문장입니다. 리뷰 날짜를 미루기 시작하면 스프린트의 핵심 장점인 고정된 확인 지점이 사라집니다. 보여줄 게 적더라도 날짜는 지키고, 적은 이유를 듣는 편이 낫습니다.
있습니다. 세 가지 경우에는 스프린트를 억지로 붙이지 않는 게 낫습니다.
첫째, 만들 것이 외부 규정이나 상위 문서로 이미 완전히 고정된 경우입니다. 순서를 바꿀 여지가 없는데 2주마다 순서를 논의하면 회의만 늘어납니다. 둘째, 작업 자체가 짧아서 스프린트 한두 개로 끝나는 경우입니다. 이때는 중간 확인 한 번이면 충분합니다.
셋째는 특히 중요합니다. 발주자가 2주마다 시간을 낼 수 없는 경우입니다. 스프린트는 발주자가 순서를 정하고 결정을 회신한다는 전제 위에서 돌아갑니다. 리뷰에 참석하지 못하고 결정 요청에 회신이 늦으면, 개발은 발주자 대기 상태로 멈춥니다. 이 경우에는 스프린트의 장점이 거의 남지 않고, 대기 시간만 일정에 얹힙니다.
그래서 스프린트를 하기로 정하기 전에 스스로에게 물어야 할 질문은 방법론에 관한 게 아닙니다. "나는 2주에 한 시간을 확보할 수 있는가"와 "그 자리에서 순서를 정할 권한이 나에게 있는가", 이 두 가지입니다. 둘 중 하나라도 아니라면 참석할 사람을 먼저 정해야 합니다.
개발사와의 다음 미팅에서 합의할 항목은 여섯 개입니다. 계약서를 다시 쓰지 않아도 회의록에 남기는 것만으로 상당 부분이 정리됩니다.
여섯 개 중에서 하나만 고른다면 첫 번째입니다. 날짜가 고정되면 나머지는 그 자리에서 자연스럽게 요구하게 됩니다. 반대로 날짜가 유동적이면 나머지 다섯 개를 합의해도 실행되지 않습니다.
포텐랩은 발주자가 개발 배경 없이도 판단할 수 있도록 스프린트마다 확인 항목을 문서로 고정해 운영합니다. 자체 집계한 수행완수율은 97%입니다. 스프린트를 처음 적용하는 단계라면 MVP 뜻과 개발 방법 2026: 정의·범위·비용·외주 발주 완전 가이드에서 범위와 발주 절차를 함께 확인해두면 첫 백로그를 세우기가 훨씬 수월합니다.
세 단어는 층이 다릅니다. 애자일은 짧게 만들고 확인하고 고치자는 사고방식이고, 스크럼은 그 태도를 역할과 회의로 정해둔 팀 운영 틀이며, 스프린트는 스크럼 안에서 작업을 잘라 담는 기간 단위입니다. 발주자가 매일 쓰게 되는 건 세 번째입니다. 개발사가 셋 중 무엇을 쓰든 발주자가 확인할 것은 몇 주마다, 무엇을, 어떤 형태로 받는가 한 문장입니다.
네 가지입니다. 직접 눌러볼 수 있는 화면, 이번에 계획했는데 못 끝낸 항목의 목록, 다음 2주에 하겠다는 항목 목록, 그리고 개발사가 발주자에게 요청하는 결정 사항입니다. 이 중 못 끝낸 항목 목록을 명시적으로 요구하는 것이 중요합니다. 완료된 것만 보고받으면 이월된 작업이 조용히 쌓이다가 마지막 스프린트에 한꺼번에 터집니다.
디자인 시안과 클릭만 되는 목업은 해당하지 않습니다. 실제로 값이 저장되고 다시 불러와지는 화면이라야 스프린트 산출물로 인정할 수 있습니다. 판별법은 간단합니다. 값을 입력하고 브라우저를 완전히 껐다가 다시 켰을 때 그 값이 남아 있으면 맞고, 남아 있지 않으면 목업입니다.
어떻게 만들지는 개발사가 정하고, 무엇을 먼저 만들지는 발주자가 정합니다. 순서를 개발사에 맡기면 악의가 없어도 기술적으로 편한 순서로 흐르기 쉽습니다. 인증·권한·관리자 기능처럼 먼저 세워두면 나중이 편한 것들이 앞에 오고, 사업 가설을 검증하는 화면이 뒤로 밀리는 경우가 있습니다.
가능합니다. 계약서에서는 총량과 금액을 고정하고, 그 범위 안에서 순서만 스프린트로 조정하는 방식입니다. 계약서에 스프린트 길이와 리뷰 주기, 리뷰 산출물의 형태, 범위 안에서의 순서 조정 권한, 범위를 넘는 요청의 변경 요청서 처리를 명시해두면 됩니다. 이 문장들이 없으면 스프린트는 구두 약속으로 남습니다.
아닙니다. 스프린트 리뷰는 방향 확인이고 최종 검수는 계약상 인수입니다. 리뷰에서는 이 방향이 맞는지만 판정하고, 그 자리에서 나온 수정 요청은 백로그로 넣습니다. 최종 검수는 계약서에 적힌 기준과 절차에 따라 별도로 진행해야 프로젝트 끝에서 분쟁이 나지 않습니다.