DDirong

IT 프로젝트 산출물, 언제 누구에게 무엇을 받을까

마지막 수정 2026년 9월 23일

IT 프로젝트 산출물은 각 단계를 맡은 사람이 다음 사람에게 넘기는 문서이고, 개발 착수일을 기준으로 시점과 작성자를 정해 받습니다. 착수 전에는 도메인 전문가에게 업무 규칙 정의서를, 기획에게 PRD와 화면설계서를 받고, 개발 착수 무렵에는 디자인에게 UI 디자인을, 개발에게 ERD와 API 명세서를 받으며, 오픈 전에는 테스트 결과와 배포, 롤백 절차를 받습니다. 문서를 다 받을 필요는 없고, 읽을 사람이 없는 문서는 뺍니다.

산출물은 왜 시점과 역할로 나눠 받을까요?

앞 사람의 문서가 다음 사람의 작업 재료이기 때문입니다. 기획이 기능을 정의해야 서버 개발이 시작되고, 디자인이 나와야 화면 개발이 붙습니다. 디자인 시안 확정이 몇 주 밀리면 퍼블리싱과 화면 개발이 한꺼번에 멈춥니다.

작성자를 정해 두는 데도 이유가 있습니다. PM이 모든 문서를 직접 쓰면 틀린 내용을 걸러 줄 사람이 없습니다. 개발 공수는 개발에게, 업무 규칙은 그 일을 매일 하는 사람에게 받습니다. PM은 받을 날짜를 정하고 들어온 문서를 확인합니다.

단계마다 누구에게 무엇을 받나요?

앞쪽 문서는 도메인 전문가와 기획이, 중간 문서는 디자인과 개발이, 뒤쪽 문서는 QA와 PM이 씁니다. 아래는 외부 납품 기준의 긴 목록이고, 보통은 여기서 골라 씁니다.

착수 4주 전: 업무 파악

도메인 전문가, 곧 그 업무를 실제로 하는 사람에게 업무 규칙 정의서, 현행 프로세스, 예외 케이스 목록을 받습니다. 업무 담당자가 쓰는 용어를 그대로 받아 적어야 뒤에서 말이 어긋나지 않습니다.

착수 3주 전부터 2주 전: 기획과 설계

기획에게 PRD, 서비스 정책서, 용어 사전을 받고 이어서 유저 플로우와 화면설계서를 받습니다. PRD에는 왜 만드는지, 어디까지 만드는지, 무엇을 보고 완료로 판단하는지가 들어가야 합니다. PM은 지표 정의서를 쓰고, 개발에게 공수 산정을 받아 일정표를 짭니다.

착수 1주 전: 디자인

디자인에게 UI 디자인, 디자인 시스템, 개발 전달 파일, 그리고 빈 화면과 로딩, 오류 때를 그린 상태별 디자인을 받습니다. 전체가 끝날 때까지 기다리지 말고 우선순위가 높은 화면부터 받아 개발로 넘깁니다.

개발 착수: 기술 설계

개발에게 시스템 아키텍처, ERD와 테이블 명세, API 명세서를 받습니다. API 명세서가 이때 나와 있으면 서버가 완성되기 전에도 화면 개발이 가짜 응답으로 먼저 움직입니다. PM은 결정 로그를 열어 오픈까지 고칩니다.

개발 중반부터 QA 착수까지

QA에게 테스트 케이스를, 기획에게 사용자 매뉴얼과 운영자 매뉴얼을 받고, QA를 시작할 때 개발에게 개발 완료 보고를 받습니다. 이 보고에 구현하지 못한 항목과 알려진 제약이 빠지면 테스트하는 사람이 이미 아는 문제를 버그로 다시 올립니다.

오픈 2주 전: 배포 준비

QA에게 테스트 결과 리포트를, 개발에게 배포와 롤백 절차를 받고, 옮길 기존 데이터가 있으면 전환계획서도 받습니다. PM은 오픈 체크리스트를 씁니다. 발주처가 있다면 인수 테스트를 거쳐 검수확인서에 서명을 받는 것으로 끝납니다.

작은 프로젝트라면 몇 건을 받나요?

네 명이 10주 동안 만드는 사내 도구라면 열여섯 건 정도면 됩니다. 사내 회의실 예약 서비스 모아를 가정한 예시입니다.

모아: 사내 회의실 예약, 10주
다은  PM, QA 겸임
민수  기획, 디자인 겸임
지혜  개발
서윤  총무팀, 도메인 전문가

착수 4주 전
  서윤  업무 규칙 정의서
        예외 케이스 목록
착수 2주 전
  민수  PRD, 화면설계서
  지혜  개발 공수 산정
  다은  일정표
개발 착수
  민수  UI 디자인, 상태별 디자인
  지혜  ERD와 테이블 명세
        API 명세서
  다은  결정 로그, 오픈까지 갱신
개발 중반
  다은  테스트 케이스
QA 착수
  지혜  개발 완료 보고
오픈 2주 전
  다은  테스트 결과 리포트
        오픈 체크리스트
  지혜  배포와 롤백 절차

민수가 기획과 디자인을 함께 하니 디자인 시스템과 개발 전달 파일은 뺐습니다. 받을 사람이 민수 자신이라서입니다. 발주처가 없어 요구사항 추적표와 검수확인서가 없고, 지난 예약 기록은 옮기지 않기로 해서 전환계획서도 없습니다.

우리 프로젝트에는 어디까지 필요할까요?

문서마다 누가 읽는지 물어보고, 읽을 사람이 없으면 뺍니다.

1인 개발이라면 남에게 넘기려고 쓰는 문서가 대부분 빠집니다. 화면설계서와 상태별 디자인은 UI 디자인 하나로 대신하고, 업무 담당자도 QA 담당도 따로 없으니 업무 규칙 정의서와 테스트 케이스도 뺍니다. 남는 것은 PRD, UI 디자인, 결정 로그, ERD와 테이블 명세, API 명세서, 배포와 롤백 절차에 혼자라서 놓치기 쉬운 오픈 체크리스트를 더한 일곱 건입니다.

구축형 납품은 반대입니다. 발주처가 결과를 확인하고 인수해야 하므로 요구사항 추적표, 인수 테스트, 운영자 매뉴얼, 검수확인서가 붙습니다. 기존 시스템을 대체한다면 현행 프로세스와 전환계획서도 필요합니다.

빼도 되는지 헷갈리면 이 기준을 씁니다.

  • 메뉴가 열 개 이하라면 화면설계서 목차가 정보구조도 역할을 합니다.
  • 화면만 보고 쓸 수 있는 기능이라면 사용자 매뉴얼 대신 화면 안의 안내 문구로 충분합니다.
  • 기존 업무를 대체하지 않는 신규 서비스라면 현행 프로세스는 비교할 대상이 없습니다.

뺀 문서에는 이유를 한 줄 남깁니다. 나중에 합류한 사람이 묻지 않아도 되고, 상황이 바뀌면 다시 넣을 근거가 됩니다. 사람이 둘 이상이라면 업무 규칙 정의서, PRD, 화면설계서, 상태별 디자인, 결정 로그, ERD와 테이블 명세, 배포와 롤백 절차는 되도록 남깁니다.

받은 산출물은 어떻게 검수하나요?

처음부터 읽기 전에, 미리 정해 둔 질문 두세 개에 답이 있는지부터 봅니다. 질문은 이 문서를 받을 다음 사람이 어디서 막힐지를 기준으로 정합니다.

  • PRD는 이번에 만들지 않는 범위가 이유와 함께 적혔는지, 수용 기준이 맞고 틀림을 가릴 수 있는 문장인지 봅니다.
  • 업무 규칙 정의서는 계산식에 실제 숫자 예시가, 규칙마다 예외가 붙었는지 봅니다.
  • 화면설계서는 화면 ID가 있는지, 빈 상태와 로딩, 오류 상태가 그려졌는지 봅니다. UI 디자인은 그 화면 ID와 하나씩 맞는지 봅니다.
  • ERD와 테이블 명세는 업무 규칙의 계산식과 보관 기간, 삭제 정책이 들어갔는지 봅니다.
  • 테스트 케이스는 요구사항 ID가 연결됐는지, 기능 하나를 보는 케이스와 업무 흐름을 끝까지 따라가는 케이스가 나뉘었는지 봅니다.
  • 배포와 롤백 절차는 되돌리는 방법을 실제로 한 번 해 봤는지 묻습니다.

업무 판단이 들어간 PRD, 화면설계서, 테스트 케이스는 PM 혼자 통과시키지 말고 도메인 전문가가 확인한 뒤에 완료로 봅니다.

늦거나 덜 된 산출물은 어떻게 하나요?

늦은 문서는 그 문서를 기다리는 사람이 누구인지부터 보고, 기다리는 사람이 많은 것부터 풉니다. 디자인 한 건이 늦으면 화면 개발과 QA가 줄줄이 밀리지만, 릴리즈 노트가 하루 늦는다고 멈추는 사람은 없습니다.

원인이 작성자 밖에 있을 때도 많습니다. 업무 담당자의 회신이나 정하지 못한 질문 하나에 걸린 경우입니다. 이때는 작성자를 재촉하기보다 그 질문을 결정 로그에 미결로 올리고 누가 언제까지 답할지 붙입니다. 완성된 부분만 먼저 받아 넘겨도 됩니다.

덜 된 문서는 빠진 곳을 짚어 돌려보냅니다. 막연히 다시 봐 달라고 하기보다 오류 상태 화면 세 개가 빠졌다고 말하면 한 번에 고쳐집니다. 보완이 두 번 넘게 오가면 기준이 맞지 않은 것이니, 완성 예시를 보여 주고 기대치부터 맞춥니다.

띠롱에서는

띠롱의 PM 모드에서 1인 개발, 소규모, 자사 SaaS, 구축형 납품 가운데 프로젝트 성격을 고르면 받을 산출물 목록이 채워집니다. 1인 개발은 일곱 건부터 시작합니다. 산출물은 착수 4주 전부터 오픈 2주 전까지 여섯 시점과, PM부터 QA까지 여섯 포지션으로 나뉜 한 표에 놓이고 지연된 것이 맨 앞에 나옵니다. 산출물마다 작성 양식과 완성 예시, 검수 기준이 붙어 있어 담당자가 제출하면 검수를 시작해 완료로 표시하거나 보완을 요청합니다.

PM 모드는 관리자 승인 후 7일간 임시로 쓸 수 있습니다. 서버 운영 비용 때문에 둔 기간이며 이용 요금은 없고 유료 전환이나 자동 결제도 없습니다. 로그인한 뒤 모드 메뉴에서 사용을 요청하면 됩니다.