PI 이후 시스템화가 끊기지 않게 만드는 요구사항 정리법

왜 PI 문서는 구현 단계에서 다시 흔들릴까

PI 프로젝트가 끝나면 프로세스 맵, 역할 정의, 개선 과제, To-Be 시나리오가 정리됩니다. 그런데 실제 시스템 구축 단계에 들어가면 다시 질문이 생깁니다.

• 누가 어떤 조건에서 요청하는가
• 예외는 어디서 처리하는가
• 상태는 몇 단계로 바뀌는가
• 무엇을 기록으로 남겨야 하는가

즉, PI 산출물이 운영 방향은 보여주지만 시스템 구현 단위로 충분히 분해되지 않는 경우가 많습니다.

목차

1. PI 산출물과 구현 요구사항의 차이
2. 역할·상태·규칙·증거로 분해하는 법
3. 가상의 재제출 요구사항 예시
4. 해석 충돌과 변경 반영 순서

PI의 방향을 개발 가능한 질문으로 바꿉니다

PI는 업무의 목표와 개선 방향을 정하는 데 유용하지만, 시스템은 더 구체적인 결정을 요구합니다. ‘검토를 강화한다’는 문장만으로는 어떤 요청이 검토 대상인지, 누가 배정되는지, 어느 조건에서 반려되는지, 어떤 기록을 남기는지 구현할 수 없습니다. 요구사항 정리의 목적은 PI 결과를 훼손하지 않고, 사람이 합의해야 할 빈칸을 드러내는 데 있습니다.

좋은 요구사항은 화면 목록보다 업무 규칙을 먼저 설명합니다. 한 업무 단위가 언제 생성되고, 어떤 역할이 어떤 데이터를 입력하며, 상태가 어떻게 바뀌는지, 예외일 때 누가 판단하는지를 순서대로 정의합니다. 그 뒤에야 필요한 화면, 알림, 연계, 보고서를 정할 수 있습니다. 순서를 바꾸면 화면에 없는 예외가 막판에 발견되기 쉽습니다.

요구사항 카드에 넣을 항목

‘재제출 가능’이라는 요구에는 무엇이 빠져 있을까

다음은 가상의 문서 검토 업무입니다. PI 문서에는 ‘반려된 문서는 보완 후 재제출 가능’이라고 적혀 있습니다. 구현 단계에서는 이것만으로 충분하지 않습니다. 재제출은 기존 건을 이어받는가 새 건을 만드는가, 이전 검토 의견은 외부 제출자에게 어디까지 보이는가, 기한이 지나면 누가 연장하는가, 재제출 뒤 같은 검토자가 다시 맡는가를 정해야 합니다.

이 질문에 답한 뒤 요구사항은 ‘보완 요청 시 사유와 대상 항목을 기록하고, 제출자는 같은 건에 새 버전을 올린다. 이전 버전과 검토 이력은 내부 검토자가 확인할 수 있으며, 기한 연장은 정해진 역할의 승인으로만 변경한다’처럼 검증 가능한 문장이 됩니다. 이는 하나의 가상 예시이며 실제 규칙은 업무 책임자와 함께 정해야 합니다.

구현 전에 결정되지 않은 문장을 찾습니다

요구사항 리뷰에서 “누가”, “언제”, “어떤 조건에서”, “어디에 남는가”라는 단어에 답이 없으면 추가 확인이 필요합니다. 특히 대리 처리, 외부 사용자, 데이터 수정, 알림 실패, 취소·되돌림은 정상 흐름 문서에서 빠지기 쉽습니다. 질문을 이슈로 미루기보다 결정이 필요한 항목으로 관리하면 일정과 책임이 함께 보입니다.

업무 도중 바뀌는 값의 기준 시점을 정합니다

구현 단계에서 자주 빠지는 것은 ‘현재 값’을 보여 주는 규칙과 ‘요청 당시 값’을 기준으로 판단하는 규칙의 차이입니다. 예를 들어 구매 요청을 제출한 뒤 작성자의 부서가 바뀌면, 새 부서의 승인자가 검토해야 하는지 제출 당시 결재선을 유지해야 하는지를 요구사항에서 정해야 합니다. 이 기준이 없으면 화면은 최신 조직 정보만 보여 주고, 운영팀은 건별로 메일로 판단하게 됩니다.

첫 적용은 조직·역할·금액처럼 업무 진행 중 바뀔 수 있는 값 하나를 골라, 기준 시점과 변경 뒤의 후속 행동을 카드에 적는 방식이 좋습니다. 변경이 재검토 사유인지, 기존 승인과 첨부를 유지할 수 있는지, 누구에게 알릴지를 함께 정합니다. 이 결정은 화면 표시뿐 아니라 연계, 시험 시나리오, 운영 문의의 기준이 되므로 기술 설계로 넘기기 전에 업무 책임자가 확정해야 합니다.

개선 과제 하나를 요구사항 카드로 다시 씁니다

요구사항 변경이 생기면 해당 규칙을 참조하는 화면, 시험, 운영 문서까지 함께 확인해 서로 다른 해석이 남지 않도록 합니다. 변경 이유와 적용 시점도 연결하면 운영 인수 시의 질문을 줄일 수 있습니다.

현재 PI 산출물의 개선 과제 하나를 골라 표의 여섯 항목으로 다시 적어 보세요. 답이 없는 칸은 개발팀이 추정할 대상이 아니라 업무 담당자가 결정해야 할 요구사항입니다.

요구사항은 한 번 확정한 뒤 닫아 두는 문서가 아닙니다. 시제품 검토와 사용자 테스트에서 새로운 질문이 나오면, 화면 수정 요청으로만 관리하지 말고 원래의 역할·상태·규칙·증거 항목 중 무엇이 바뀌었는지 갱신해야 합니다. 이렇게 하면 변경이 누적돼도 왜 화면과 테스트가 달라졌는지 설명할 수 있습니다. 우선순위 역시 기능 수가 아니라 운영 위험과 결정의 긴급도를 기준으로 정하는 편이 좋습니다.

요구사항을 구현 가능한 결정으로 바꾸는 순서

PI 이후 요구사항이 흐려지는 순간은 현장의 개선 의견을 곧바로 화면 목록으로 옮길 때입니다. “승인을 빠르게 해 달라”는 요청에는 승인 단계를 줄이라는 뜻일 수도, 긴급 경로를 따로 만들라는 뜻일 수도, 현재 어디에서 멈췄는지 보이게 해 달라는 뜻일 수도 있습니다. 먼저 업무 목표와 실패 조건을 확인하고, 그 다음 역할·입력·상태·판단 규칙·근거·알림으로 나눠 적어야 개발과 운영이 같은 문제를 말하게 됩니다. 요구사항 카드 하나에는 정상 흐름만이 아니라 누가 거절할 수 있는지, 무엇이 바뀌면 다시 검토해야 하는지도 포함합니다.

요구사항 카드는 한 문장을 구현 항목으로 바꾸기 전에 의사결정의 순서를 고정합니다. 업무 목표와 실패 조건을 먼저 적고, 역할·입력·상태·판단 규칙·근거·알림을 연결합니다. 값이 바뀌는 요구에는 기준 시점과 재검토 조건을, 외부 연계가 있는 요구에는 지연·중복·실패 때 유효한 값을 덧붙입니다. 마지막에는 각 규칙을 확인할 관찰 가능한 결과와 수동 처리 범위를 적습니다. 이 순서를 따르면 화면 편의 요청과 운영 규칙 변경이 한 항목으로 섞이는 일을 줄일 수 있습니다.

관찰 가능한 예시로 모호한 요구를 검증합니다

각 규칙에는 관찰 가능한 예시를 붙입니다. ‘권한 있는 사용자만 승인할 수 있다’보다 ‘승인 대기 상태의 재무 승인자는 승인·반려를 할 수 있고, 작성자는 열람만 할 수 있다’가 시험 가능한 요구입니다. 반려 후 재제출, 승인자 부재, 연계 실패, 기한 만료 같은 예외도 같은 형식으로 적습니다. 이때 모든 예외를 기능으로 만들 필요는 없습니다. 수동 절차로 처리할 경우에도 누가 판단하고 어디에 사유를 남기는지는 정해야 합니다.

요구가 바뀌면 변경 이력에는 문장 수정만 남기지 말고 영향받는 화면, 연계, 시험, 교육 자료, 운영 절차를 확인 목록으로 연결합니다. 사용성 검토에서 버튼 위치를 바꾼 것이 실제로 승인 권한이나 상태 의미를 바꾸는지까지 확인해야 합니다. 이렇게 하면 PI의 통찰이 프로젝트 중간에 사라지지 않고, 운영에서 다시 질문받을 때도 어떤 근거로 설계했는지 설명할 수 있습니다.

우선순위는 구현 난이도보다 운영 위험으로 정합니다

모든 빈칸을 동시에 해결할 수는 없습니다. 승인 없이 상태가 바뀌는 위험, 잘못된 권한이 오래 남는 위험, 마감 업무가 멈추는 위험처럼 영향과 복구 난이도가 큰 규칙부터 확정합니다. 반대로 화면의 편의 개선은 핵심 규칙이 안정된 뒤에 다룰 수 있습니다. 우선순위 판단의 근거를 카드에 남기면, 일정 압박 속에서도 왜 특정 요구를 먼저 결정했는지 팀이 공유할 수 있습니다.

개발자가 추정해야 하는 빈칸을 줄입니다

전문가는 요구사항을 읽고 역할, 기준 시점, 예외, 증거 위치를 스스로 추정해야 하는 부분이 어디인지 표시합니다. 업무팀은 빠른 구현을 위해 세부 규칙을 나중에 정하고 싶을 수 있지만, 개발팀이 임의로 정한 규칙은 운영에서 다시 바꾸기 어렵습니다. 반대로 모든 가능성을 문서에 적기보다, 위험이 큰 예외부터 결정하고 수동 처리로 남길 범위를 명확히 하는 편이 실용적입니다.

개발자가 추정한 빈칸은 리뷰 의견으로만 남기지 않고 결정 대장에 올립니다. 질문, 결정권자, 필요한 근거, 답변 기한, 미결일 때 적용할 임시 절차를 분리하면 구현을 계속할 수 있는 범위와 멈춰야 할 범위가 보입니다. 사용자 시험에서 새로운 해석이 나오면 버튼 문구만 고치지 않고 원 요구사항과 시험 결과, 운영 안내를 함께 갱신합니다. 외부 연계가 늦어 임시 값을 썼다면 그 적용 범위와 교체 책임도 남깁니다. 이 연결이 요구를 기능 목록이 아니라 운영 규칙으로 유지합니다.

요구 해석이 갈릴 때 확인하고 다음 변경에 반영합니다

업무와 개발의 해석이 다르면 화면 문구를 먼저 고치기보다 원래 목표와 실패 조건을 다시 확인합니다. 그 뒤 역할, 기준 시점, 예외, 증거 중 어느 규칙이 비어 있는지 결정합니다. 합의한 결과는 요구사항과 시험 시나리오에 함께 반영하고, 이미 구현된 부분은 영향 범위를 확인합니다. 이 순서가 있어야 회의의 구두 합의가 운영 규칙으로 남습니다.

요구사항의 결정자는 구현 중 질문이 생겼을 때 응답할 책임도 가져야 합니다. 답변이 새 규칙이 된다면 원 문서, 시험, 운영 안내에 같은 변경을 반영합니다. 이를 생략하면 개발팀의 기록과 현장의 해석이 서로 달라질 수 있습니다. 이력과 적용 시점을 함께 남기면 이후 변경도 같은 기준으로 검토할 수 있습니다.