요구사항을 정하지 못한 채 개발을 시작하면 생기는 일

기능보다 먼저 정해야 하는 문제와 우선순위

따뜻한기술 · Jeensuk Yang · 2026.08.25 · 읽는 데 약 6분

프로젝트가 흔들리는 이유는 요구사항 문서가 짧아서가 아닙니다. 해결할 문제와 우선순위, 그리고 무엇이 되면 끝인지에 대한 합의 없이 개발을 시작했기 때문입니다. 요구사항은 기능을 나열한 문서가 아니라, 프로젝트가 흔들릴 때마다 돌아와 확인하는 판단 기준입니다.

1. "일단 개발부터 시작하자"는 순간

대부분의 프로젝트는 이렇게 시작합니다.

여기서부터 수정이 시작됩니다. 수정은 대개 기능 하나를 고치는 일로 시작해서, 결국 "그러면 이건 왜 이렇게 되어 있죠"라는 질문으로 되돌아갑니다. 일정은 밀리고, 같은 회의를 세 번째 하게 됩니다.

이 상황에서 누군가 일을 못 한 것은 아닙니다. 요청한 쪽도, 정리한 쪽도, 만든 쪽도 각자 자리에서 합리적으로 판단했습니다. 다만 판단의 기준이 서로 달랐고, 그 차이를 확인할 자리가 없었을 뿐입니다.

2. 요구사항이 없다는 것은 문서가 없다는 뜻이 아닙니다

요구사항 정의를 문서 작성 업무로 생각하면, 문서가 두꺼워질수록 안전해진다고 믿게 됩니다. 실제로는 그렇지 않습니다.

• 문서가 30장이어도 왜 만드는지가 빠져 있을 수 있습니다.
• 화면 설계가 전부 그려져 있어도, 그 화면이 어떤 문제를 없애는지는 적혀 있지 않을 수 있습니다.
• 기능 목록이 길수록 무엇이 먼저인지는 오히려 흐려집니다.

요구사항의 본질은 분량이 아니라 팀이 같은 문제와 같은 성공 기준을 보고 있는 상태입니다. 그래서 요청받은 문장을 그대로 옮겨 적는 대신, 한 번 되물어 봐야 합니다.

왼쪽은 해결책이고, 오른쪽이 요구사항입니다. 이 둘을 구분하지 않으면, 검색창은 만들어졌는데 사용자는 여전히 원하는 것을 못 찾는 결과가 나옵니다. 기능은 완성됐지만 문제는 남아 있는 상태입니다.

3. 합의 없이 시작하면 반복되는 다섯 가지

① 사람마다 다른 결과물을 상상합니다

"고객 관리 화면"이라는 같은 단어를 두고, 한쪽은 목록과 검색을, 다른 쪽은 이력 관리와 통계를 떠올립니다. 그림을 보기 전까지는 서로 같은 이야기를 하고 있다고 믿습니다.

② 우선순위가 없으면 모든 기능이 필수가 됩니다

무엇을 먼저 할지 정해 두지 않으면, 일정이 부족해졌을 때 뺄 것을 고를 수 없습니다. 결국 전부 조금씩 미완성인 상태로 마감을 맞습니다.

③ 개발 중 의사결정이 반복되어 재작업이 늘어납니다

구현 도중에 결정이 필요해지면, 만드는 사람이 임시로 결정하거나 답을 기다립니다. 임시 결정은 나중에 뒤집히고, 기다림은 일정이 됩니다.

④ 완료 기준이 없으면 검수가 끝나지 않습니다

"어떤 상태가 되면 끝인가"를 정하지 않으면, 검수는 새 의견을 받는 자리가 됩니다. 다 만들었는데도 승인이 나지 않는 프로젝트는 대부분 여기에 걸려 있습니다.

⑤ 지연의 원인이 사람에게 돌아갑니다

기준이 없으면 무엇이 지연을 만들었는지 설명할 방법도 없습니다. 그래서 설명은 자주 사람의 문제로 정리됩니다. 실제로는 의사결정 구조와 정보 부족의 문제였는데도 그렇습니다.

4. 기능보다 먼저 정해야 하는 것

착수 전에 합의해야 할 것은 기능 목록이 아니라 다음 일곱 개의 답입니다.

1. 우리가 해결하려는 문제는 무엇인가
2. 이 문제를 가장 크게 겪는 사용자는 누구인가
3. 해결되었다고 판단할 수 있는 변화는 무엇인가
4. 이번에 반드시 포함해야 할 범위는 무엇인가
5. 이번에는 하지 않을 것은 무엇인가
6. 일정·예산·기술·정책상의 제약은 무엇인가
7. 의견이 갈릴 때 최종적으로 정하는 사람은 누구인가

여기서 오해가 하나 생기기 쉽습니다. "그러면 전부 확정한 다음에 개발하라는 말인가"입니다. 그렇지 않습니다.

최소 합의는 문제·사용자·목표·우선순위·완료 기준입니다. 이건 착수 전에 정합니다.
세부 설계는 화면 구성, 문구, 예외 처리, 세부 규칙입니다. 이건 만들면서 정해도 됩니다.

구분의 기준은 간단합니다. 나중에 바뀌면 방향이 바뀌는 것은 먼저 정하고, 나중에 바뀌어도 방향이 그대로인 것은 나중에 정합니다. 목표가 바뀌면 만든 것의 대부분이 흔들리지만, 버튼 문구가 바뀌면 버튼 문구만 바뀝니다.

5. 개발 전에 정리할 최소 요구사항 7가지

새 프로젝트를 시작할 때 A4 한 장이면 충분합니다. 일곱 칸을 채우는 것이 목표입니다.

담당자, 결정권자, 일정, 기술적 제약, 연결되는 기존 시스템은 이 표 옆에 따로 적어 둡니다. 일곱 칸 중에서 실제로 가장 자주 비어 있는 칸은 5번(비범위)과 7번(완료 기준)입니다. 그리고 프로젝트가 길어지는 원인도 대개 이 두 칸에 있습니다.

6. 같은 요청을 다시 써 보면

실제 프로젝트에서 자주 보는 형태를 각색한 예시입니다.

오른쪽 문장 안에는 다섯 가지가 들어 있습니다. 문제(고객을 찾는 데 오래 걸린다), 사용자(고객지원 담당자), 목표(1분 안에), 범위와 비범위(검색·조회는 하고, 내려받기·분류는 안 한다), 완료 기준(5명이 20건을 찾으면 완료)입니다.

왼쪽 문장으로 시작하면 만드는 사람마다 다른 것을 만들 수 있습니다. 오른쪽 문장으로 시작하면 서로 다르게 만들 여지가 거의 없습니다. 길이는 세 배가 됐지만, 회의는 절반으로 줄어듭니다.

7. 요구사항이 바뀔 때 지켜야 할 원칙

요구사항은 바뀝니다. 써 보면 알게 되는 것이 있고, 시장이 움직이기도 합니다. 변경 자체는 실패가 아닙니다. 변경의 영향을 확인하지 않고 넘어가는 것이 문제입니다.

• 왜 바꾸는지 이유를 한 줄로 남깁니다. 석 달 뒤에는 아무도 기억하지 못합니다.
• 바뀌는 기능만 보지 말고, 일정·비용·품질에 무엇이 따라오는지 함께 확인합니다.
• 새로 넣는 것이 있으면 이번에 뺄 것을 같이 정합니다. 넣기만 하면 일정은 반드시 밀립니다.
• 누가 언제 승인했는지 남깁니다.
• 바뀐 내용을 관련된 사람 모두에게 같은 문장으로 공유합니다. 한 사람만 모르면 그 부분에서 다시 어긋납니다.

이 다섯 가지를 지키면, 변경은 사고가 아니라 결정이 됩니다.

8. 개발 착수 전 10분 체크리스트

착수 회의 마지막 10분에 이 열 개를 함께 확인하시면 됩니다. 하나라도 비어 있다면, 그 칸이 이번 프로젝트에서 가장 먼저 문제가 될 자리입니다.

• 해결할 문제가 한 문장으로 설명되는가
• 주요 사용자가 누구인지 명확한가
• 기대하는 결과가 정의되어 있는가
• 필수 기능과 선택 기능이 구분되어 있는가
• 이번에 하지 않을 범위가 적혀 있는가
• 완료 여부를 판단할 기준이 있는가
• 기술·일정·정책상의 제약을 확인했는가
• 의사결정자가 정해져 있는가
• 변경 요청을 기록할 곳이 있는가
• 참여자 모두가 같은 내용을 확인했는가

견적 금액이 회사마다 크게 갈리는 이유도 결국 이 지점과 이어져 있습니다. 관련해서는 견적이 회사마다 두세 배씩 차이 나는 이유에서 따로 정리했습니다.

마무리

요구사항을 정한다는 것은 앞으로 일어날 모든 변화를 미리 맞히는 일이 아닙니다. 지금 해결해야 할 문제와 우선순위, 그리고 무엇이 되면 끝인지를 팀이 함께 고르는 일입니다.

이 합의를 하느라 착수가 며칠 늦어질 수 있습니다. 그래도 대체로 그 편이 빠릅니다. 뒤에서 줄어드는 재작업과 회의가, 앞에서 쓴 며칠보다 크기 때문입니다.

다음 프로젝트 착수 회의에서 위 체크리스트 열 개를 화면에 띄워 놓고 함께 읽어 보시는 것부터 시작해 보시면 좋겠습니다.

※ 6장의 고객 관리 사례는 여러 프로젝트에서 자주 보이는 형태를 각색한 예시이며, 특정 고객사나 프로젝트의 내용이 아닙니다.
※ 이 글의 판단 기준은 따뜻한기술의 프로젝트 경험을 기준으로 한 것이며, 업계 통계나 조사 결과가 아닙니다. 재작업 비율과 같은 수치는 검증 가능한 출처가 없어 사용하지 않았습니다.