외주 프리랜서의 분석 & 설계 단계: SRS 승인으로 스코프를 고정하는 법

이 단계가 없으면, 4~12주가 흔들립니다

외주 프로젝트에서 가장 위험한 말 중 하나입니다.

첫 번째 글 **외주 프리랜서를 위한 스코프 방어 전략**에서는
클라이언트의 “모호한 3문장”을 명확한 범위 문서 + 근거 있는 견적/일정으로 바꾸는 방법을 다뤘습니다.

그리고 그 다음이 바로 오늘 이야기할 **【2. 분석 & 설계 단계】**입니다.

이 단계의 목적은 단 하나예요:

“우리가 만들기로 합의한 것”을 문서로 고정하고(=Baseline),
이후 변경은 ‘변경 요청’으로 다룰 수 있게 만드는 것.

---

분석 & 설계 단계에서 실제로 일어나는 일

프리랜서 프로젝트 시퀀스 다이어그램의 2단계는 보통 1~2주가 잡힙니다.

산출물	주요 작업	예상 소요
SRS (요구사항 분석서)	초안 작성 → 피드백 → 수정 → 승인	816h + 12h + 2~4h + 10m
시스템/화면 설계서	설계서 작성 → 피드백 → 수정 → 최종 승인	824h + 12h + 2~8h + 10m

<Figure src="/blog/analysis-design/infographic-flow-ko.png" alt="분석 & 설계 단계 흐름" caption="계약에서 코드로 가는 길은 ‘분석’으로 연결됩니다" className="max-w-[700px] mx-auto" />

여기서 중요한 건 “문서” 자체가 아닙니다.
승인(사인오프) 입니다.

승인 없이 개발로 들어가면, 3단계(개발)에서 이런 문장이 나오기 시작합니다:

• “아 그거 당연히 포함 아닌가요?”
• “이건 화면 나오면 바꿔주세요”
• “그럼 이것도 같이 되게 해주세요”

그리고 그 순간부터 프로젝트는 무한 수정 모드가 됩니다.

---

SRS는 ‘문서’가 아니라 ‘방어막’입니다

<Figure src="/blog/analysis-design/infographic-shield-ko.png" alt="SRS 방패" caption="승인된 SRS는 스코프 크립의 화살로부터 일정을 보호합니다" className="max-w-[500px] mx-auto" />

SRS(요구사항 분석서)는 보통 아래 질문에 답하는 문서예요.

1. 무엇을 만들까? (범위/목표/제약)
2. 누가 쓰나? (사용자/여정/권한)
3. 언제 완료로 볼까? (수락 기준/완료 정의)
4. 리스크는 뭐고, 빠진 건 뭔가? (비기능/가정/이슈)
5. 얼마나 걸리나? (공수/일정/마일스톤)

이 질문들에 답을 한 번이라도 고정된 형태로 합의해야,
개발 단계에서 흔들리지 않습니다.

---

uDocit으로 SRS 초안을 ‘5개의 섹션’으로 분해하기

SRS를 처음부터 손으로 만들면, 보통 이렇게 됩니다:

• 노션에 템플릿 찾기 → 붙여넣기
• PRD/회의록/카톡 내용을 여기저기 복사
• 누락/모호함 때문에 피드백 라운드 3~5회
• 결국 “최신본”을 아무도 확신 못 함

uDocit은 이 과정을 문서 기반으로 자동 구조화합니다.

1) 리스크부터 열어보기 (SRS의 앞부분)

• BLOCK(차단) 이슈는 SRS 승인 전에 해결
• WARNING(경고)은 SRS에 ‘결정/가정’으로 명시

2) 프로젝트 개요 = 범위/목표/제약의 기준선

여기서 꼭 합의해야 하는 것들:

• MVP 정의(핵심 기능)
• 제외 범위(Out of scope)
• 일정 제약(예: 3개월, 특정 이벤트 전)

3) 사용자 유형/여정 = 화면 설계의 출발점

“사용자”가 하나로 뭉개져 있으면 화면설계서가 붕괴합니다.
uDocit은 사용자 유형을 분리하고, 목표/권한/여정을 정리해 줍니다.

4) 사용자 스토리 + 수락 기준 = 분쟁을 막는 체크리스트

수락 기준(AC)을 한 문장으로 정리하면:

“이 기능이 완료되었다고 판단할 조건” 입니다.

외주에서 AC가 없으면, 최종 검수 단계에서 이런 일이 벌어집니다:

• “여기 버튼 하나 더…”
• “이건 당연히 이렇게 동작해야…”
• “그럼 이 케이스도 되는 거죠?”

AC가 있으면, 논점이 바뀝니다:

• ✅ “이 AC를 충족했는가?”
• ✅ “새로운 AC를 추가할 것인가(=변경 요청)?”

5) 타임라인 = ‘그냥 3개월’이 아니라 ‘16주짜리 계획’으로

이 타임라인은 설계서 단계에서도 중요합니다.

• 화면/기능이 늘어나면 → 일정도 늘어난다
• 일정이 고정이면 → 범위를 줄여야 한다

즉, 설계서 피드백 = 일정 피드백이기도 합니다.

---

“피드백 라운드”를 줄이는 승인 방식

분석 & 설계 단계가 오래 걸리는 이유는 대부분 이거예요:

코멘트가 ‘수정 지시’로 들어오기 때문입니다.

uDocit으로 초안을 만들었다면, 이제 피드백을 이렇게 바꿔 요청하세요.

피드백 요청 템플릿 (그대로 복사해서 쓰세요)

질문을 바꾸면, 코멘트가 “무한 수정”이 아니라 “의사결정”이 됩니다.

---

설계서는 ‘예쁜 화면’이 아니라 ‘해석이 없는 화면’입니다

SRS가 승인되면 다음은 시스템/화면 설계서입니다.
이 단계에서 흔히 터지는 문제는 해석의 여지예요.

• 버튼을 어디에 둘지
• 어떤 상태(로딩/오류/빈 화면)를 처리할지
• 권한에 따라 화면이 어떻게 달라지는지

여기서 uDocit의 사용자 스토리 + 수락 기준이 설계서의 뼈대가 됩니다.

화면설계서에 꼭 붙여야 하는 5가지 (체크리스트)

---

마지막으로: 승인(사인오프) 문장을 남겨두세요

외주에서 가장 강력한 스코프 방어는
“논리”가 아니라 승인 기록입니다.

이 한 문장이 있으면, 개발 단계에서 “그건 당연히 포함” 논쟁이 줄어듭니다.

---

다음 단계: 개발 착수 전에 ‘질문 폭탄’을 막는 방법

분석 & 설계 단계가 끝나면, 드디어 개발 단계(3단계)로 들어갑니다.

다음 글에서는:

• 개발 중 “이 케이스 어떻게 해요?” 질문을 줄이는 방법
• 수시 변경 요청을 “범위 외 추가비용 협의”로 전환하는 방법

을 uDocit 워크플로우로 이어서 정리할 예정입니다.

---

직접 해보세요

계약 후 “바로 개발”로 뛰어들기 전에,
SRS 초안 → 피드백 → 승인을 먼저 만들어보세요.

지금 무료로 시작하기 →