개발 중간에 결과물을 확인할 수 있는 업체를 골라야 하는 이유

웹개발 외주를 맡길 때 많은 의뢰사가 완성된 결과물을 마지막에 한 번 확인하는 방식으로 프로젝트를 진행합니다.

처음에는 요구사항을 전달하고, 중간에는 개발 업체의 진행 보고를 받은 뒤, 약속한 날짜에 완성본을 검수하는 방식입니다.

프로젝트가 단순하고 요구사항이 명확하다면 가능할 수 있습니다.

하지만 회원가입, 결제, 관리자 페이지, 외부 API, 업무 로직처럼 여러 기능이 연결된 웹서비스라면 마지막에 처음 확인하는 방식은 위험할 수 있습니다.

기능이 모두 완성된 뒤에 방향 차이를 발견하면 이미 많은 화면과 데이터 구조가 만들어진 상태일 수 있기 때문입니다.

따라서 개발 업체를 선택할 때는 다음을 확인하는 것이 좋습니다.

프로젝트가 끝날 때까지 기다리지 않고, 실제로 작동하는 결과물을 중간중간 확인할 수 있는가?

문서상 진행률과 실제 결과물은 다를 수 있습니다

개발 업체가 다음과 같이 보고할 수 있습니다.

전체 개발 진행률: 70%

- 회원 기능 완료
- 결제 기능 완료
- 관리자 개발 중
- 모바일 작업 예정

하지만 70% 완료라는 숫자만으로는 실제 상태를 정확히 판단하기 어렵습니다.

• 회원가입은 되지만 인증 이메일이 발송되지 않을 수 있음
• 결제 화면은 있지만 실제 결제 결과가 저장되지 않을 수 있음
• 관리자 화면은 있지만 검색과 수정이 작동하지 않을 수 있음
• PC 화면은 완성됐지만 모바일은 사용할 수 없을 수 있음
• 정상적인 상황만 되고 오류 상황은 처리되지 않을 수 있음

진행률은 업무량을 표현하는 참고 정보일 뿐, 실제 사용 가능한 상태를 의미하지는 않습니다.

가능하면 테스트 주소에서 직접 가입하고 버튼을 누르며 결과를 확인해야 합니다.

중간 결과물을 확인하면 무엇이 달라질까?

1. 요구사항 해석 차이를 일찍 발견할 수 있습니다

같은 문장을 보고도 의뢰사와 개발 업체가 다르게 이해할 수 있습니다.

예를 들어 다음 요구사항이 있다고 가정해 보겠습니다.

관리자가 회원을 승인할 수 있어야 합니다.

의뢰사는 다음 흐름을 생각했을 수 있습니다.

1. 회원가입
2. 가입 대기
3. 관리자에게 알림
4. 관리자가 회원 정보 확인
5. 승인 또는 반려
6. 회원에게 결과 안내

반면 개발 업체는 관리자 목록에 승인 버튼 하나를 추가하는 것으로 이해했을 수 있습니다.

기능이 완성된 뒤 발견하면 다음 작업을 다시 수정해야 합니다.

• 회원 상태
• 로그인 제한
• 관리자 목록
• 알림
• 이메일
• 반려 사유
• 승인 이력

초기 단계에서 실제 화면과 동작을 확인하면 해석 차이를 빠르게 조정할 수 있습니다.

2. 사용자 흐름의 불편함을 확인할 수 있습니다

기획서상으로는 자연스러워 보였지만 실제로 사용하면 불편한 경우가 있습니다.

예를 들어 신청 기능이 다음과 같이 구성되어 있을 수 있습니다.

1. 회원가입
2. 이메일 인증
3. 프로필 작성
4. 신청서 작성
5. 파일 업로드
6. 결제
7. 신청 완료

각 기능은 정상적으로 작동해도 전체 과정이 너무 길어 사용자가 중간에 이탈할 수 있습니다.

작동하는 결과물을 중간에 확인하면 다음을 판단할 수 있습니다.

• 단계가 지나치게 많은가?
• 같은 정보를 반복 입력하는가?
• 사용자가 현재 단계를 알 수 있는가?
• 이전 단계로 돌아갈 수 있는가?
• 저장 후 나중에 이어서 작성할 수 있는가?
• 모바일에서도 입력하기 쉬운가?

화면 이미지나 설명만으로는 실제 사용성을 완전히 확인하기 어렵습니다.

3. 디자인과 개발 결과의 차이를 확인할 수 있습니다

Figma 디자인과 실제 웹 화면은 다르게 보일 수 있습니다.

• 글자 길이가 달라짐
• 실제 이미지 비율이 다름
• 브라우저에 따라 폰트가 다르게 표시됨
• 모바일 줄바꿈이 어색함
• 버튼과 입력창 상태가 빠짐
• 데이터가 많아지면 레이아웃이 깨짐
• 애니메이션의 속도와 느낌이 다름

정적인 디자인 시안만 승인하고 마지막에 개발 결과를 보면 예상과 다른 부분이 많을 수 있습니다.

중간 결과를 확인하면서 다음 상태까지 검수하는 것이 좋습니다.

• 데이터가 없는 상태
• 데이터가 1개인 상태
• 데이터가 많은 상태
• 글이 짧은 경우
• 글이 긴 경우
• 오류가 발생한 경우
• 로딩 중인 경우
• 모바일 화면

4. 관리자 페이지의 운영 가능성을 확인할 수 있습니다

사용자 화면은 비교적 꼼꼼히 검수하지만 관리자 페이지는 프로젝트 마지막에 확인하는 경우가 많습니다.

하지만 실제 서비스 운영에서는 관리자 기능이 매우 중요합니다.

중간 단계에서 다음 업무를 직접 해보는 것이 좋습니다.

• 회원 검색
• 상태 변경
• 신청 승인
• 콘텐츠 등록
• 이미지 업로드
• 결제 확인
• 문의 처리
• 엑셀 다운로드
• 관리자 권한 설정

기능은 존재하지만 실제 운영하기 불편한 경우도 있습니다.

예를 들면 다음과 같습니다.

• 회원을 찾기 어렵다.
• 상태 변경 과정이 복잡하다.
• 저장 버튼 위치가 불편하다.
• 삭제 실수를 막을 장치가 없다.
• 필요한 정보가 한 화면에 보이지 않는다.
• 엑셀 다운로드 결과가 화면과 다르다.
• 같은 작업을 여러 번 반복해야 한다.

운영 담당자가 개발 중 관리자 화면을 확인하면 실제 업무에 맞게 개선할 수 있습니다.

5. 변경 비용을 줄일 수 있습니다

개발이 많이 진행된 뒤 변경하면 연결된 기능도 함께 수정해야 할 수 있습니다.

예를 들어 회원 유형을 다음처럼 바꾸고 싶다고 가정해 보겠습니다.

기존 구조

• 일반 회원
• 관리자

변경 구조

• 개인 회원
• 기업 관리자
• 기업 직원
• 운영 관리자

이 변경은 단순히 회원가입 화면만 수정하는 일이 아닙니다.

• 데이터베이스
• 권한
• 메뉴
• 로그인
• 관리자
• 결제
• 통계
• 알림

여러 영역에 영향을 줄 수 있습니다.

초기 회원 구조를 작동하는 화면으로 확인했다면 큰 변경이 발생하기 전에 문제를 발견할 수 있습니다.

어떤 형태의 중간 결과물을 받아야 할까?

프로젝트 단계에 따라 확인할 결과물이 달라질 수 있습니다.

1. 요구사항 정리 문서

개발 전에 다음 내용을 확인합니다.

• 사용자 유형
• 핵심 기능
• 사용자 흐름
• 관리자 업무
• 외부 연동
• 포함 범위
• 제외 범위
• 완료 기준

문서가 지나치게 길 필요는 없지만, 서로 같은 프로젝트를 이해하고 있는지 확인할 수 있어야 합니다.

2. 화면 설계 또는 와이어프레임

화면 설계에서는 다음을 확인합니다.

• 페이지 목록
• 메뉴
• 콘텐츠 순서
• 입력 항목
• 버튼
• 화면 이동
• 상태
• 관리자 구조

디자인 전에 구조를 확인하면 디자인 수정 비용을 줄일 수 있습니다.

3. 디자인 시안

다음 항목을 확인합니다.

• 브랜드 분위기
• 메인 화면
• 주요 하위 화면
• 모바일 화면
• 공통 UI
• 입력 화면
• 데이터 화면

모든 화면을 한 번에 디자인하기보다 주요 화면의 방향을 먼저 확정할 수도 있습니다.

4. 테스트 URL

실제 브라우저에서 작동하는 개발 버전입니다.

• 회원가입
• 로그인
• 데이터 입력
• 저장
• 수정
• 검색
• 관리자
• 결제 테스트
• 모바일 화면

테스트 URL이 있으면 의뢰사가 직접 기능을 검수할 수 있습니다.

5. 기능별 데모

프로젝트 전체가 완성되지 않아도 특정 흐름을 먼저 확인할 수 있습니다.

예를 들면 다음과 같습니다.

이번 주 확인 범위

1. 회원가입
2. 이메일 인증
3. 로그인
4. 비밀번호 찾기
5. 관리자 회원 조회

기능별로 확인하고 승인하면 다음 단계로 넘어갈 수 있습니다.

중간 결과물은 얼마나 자주 확인해야 할까?

모든 프로젝트에 같은 주기가 적합한 것은 아닙니다.

작은 홈페이지

• 주요 디자인 확정
• 개발 중간 확인
• 최종 검수

일반적인 웹서비스

• 주 1회 또는 1~2주 단위
• 기능 묶음별 확인
• 주요 의사결정 시 별도 확인

복잡한 업무 시스템

• 핵심 흐름별 데모
• 사용자·관리자 기능을 분리해 검수
• 데이터와 권한 구조 조기 확인

너무 자주 확인하면 개발 흐름이 끊길 수 있고, 너무 늦게 확인하면 수정 비용이 커질 수 있습니다.

업체와 적절한 공유 주기를 미리 정하는 것이 좋습니다.

중간 검수에서 의뢰사가 해야 할 일

중간 결과물을 받았다고 단순히 화면을 둘러보는 것으로 끝내면 안 됩니다.

실제 사용자처럼 행동해 보는 것이 좋습니다.

사용자 기능

• 처음 가입한다.
• 잘못된 값을 입력한다.
• 비밀번호를 찾는다.
• 신청서를 작성한다.
• 중간에 페이지를 닫는다.
• 모바일에서 이용한다.
• 결제 실패를 시도한다.

관리자 기능

• 회원을 검색한다.
• 승인과 반려를 처리한다.
• 잘못된 데이터를 수정한다.
• 게시물을 등록한다.
• 엑셀을 내려받는다.
• 관리자별 권한을 확인한다.
• 삭제 후 복구 가능성을 확인한다.

피드백을 전달하는 방법

중간 결과물을 확인한 뒤에는 피드백을 명확하게 전달해야 합니다.

좋지 않은 예시는 다음과 같습니다.

전체적으로 좀 불편해요.
디자인이 생각했던 것과 달라요.
조금 더 고급스럽게 바꿔 주세요.

좋은 피드백은 다음처럼 구체적입니다.

화면:
기업 회원가입 2단계

현재:
사업자번호를 입력한 뒤 다음 버튼을 눌러야 오류를 확인할 수 있습니다.

요청:
입력칸에서 벗어나는 즉시 형식 오류를 표시해 주세요.

이유:
사용자가 마지막 단계에서 다시 돌아오지 않도록 하기 위함입니다.

가능하면 다음 정보를 포함하세요.

• 화면
• 현재 동작
• 원하는 동작
• 변경 이유
• 우선순위
• 참고 이미지

피드백을 한 곳에 모아야 합니다

이메일, 메신저, 전화, 회의에서 요청이 흩어지면 누락될 수 있습니다.

다음 도구를 활용할 수 있습니다.

• Notion
• Google Sheets
• Jira
• Linear
• Trello
• GitHub Issues
• 프로젝트 관리 도구

간단한 표로도 충분합니다.

중간 확인이 개발자를 감시하는 것은 아닙니다

중간 결과물 공유의 목적은 개발자를 압박하거나 작업 시간을 감시하는 것이 아닙니다.

목적은 다음과 같습니다.

• 요구사항 차이 확인
• 우선순위 조정
• 운영 문제 발견
• 수정 비용 감소
• 일정 위험 조기 확인

실제 결과를 함께 보며 의사결정하면 의뢰사와 개발 업체 모두 불필요한 재작업을 줄일 수 있습니다.

업체 상담 시 물어볼 질문

• 개발 중간 결과는 어떤 방식으로 공유하나요?
• 테스트 URL을 받을 수 있나요?
• 보통 어느 주기로 데모를 진행하나요?
• 기능별로 검수하고 승인할 수 있나요?
• 피드백은 어떤 도구로 관리하나요?
• 변경 요청의 비용과 일정 영향은 어떻게 안내하나요?
• 관리자 페이지도 중간에 확인할 수 있나요?
• 모바일 화면은 언제 확인할 수 있나요?
• 완료 전 전체 검수 기간은 얼마나 되나요?

계약서나 일정표에 넣을 수 있는 내용

- 주요 기능별 개발 완료 시 테스트 URL을 제공한다.
- 의뢰사는 결과물을 확인하고 정해진 기간 내 피드백을 전달한다.
- 합의된 요구사항과 다른 오류는 수정한다.
- 새로운 기능이나 범위 변경은 비용과 일정을 별도로 합의한다.
- 각 단계의 승인 이후 발생한 큰 구조 변경은 별도 협의한다.

프로젝트에 따라 구체적인 방식은 달라질 수 있습니다.

마무리

웹개발 외주에서 가장 위험한 방식 중 하나는 프로젝트 마지막 날에 결과물을 처음 확인하는 것입니다.

중간에 실제로 작동하는 결과물을 확인하면 다음 문제를 줄일 수 있습니다.

• 요구사항 해석 차이
• 사용자 흐름의 불편
• 관리자 운영 문제
• 디자인과 개발 결과의 차이
• 뒤늦은 대규모 수정

업체를 선택할 때 포트폴리오와 비용만 보지 말고, 개발 과정이 얼마나 투명하게 공유되는지도 확인하는 것이 좋습니다.