요구사항, IA, 플로차트 작성

1. 들어가며: 기획자는 '화면'이 아닌 '프로세스'를 설계한다

IT 업계에서 서비스 기획자의 역할을 흔히 "스케치를 하고 화면을 그리는 사람"으로 오해하곤 합니다. 디자인 툴을 활용해 버튼을 배치하고 와이어프레임을 만드는 작업이 가장 눈에 띄기 때문입니다.

그러나 시각적인 화면은 기획자가 정의한 수많은 논리와 정책이 최종적으로 발현된 '결과물'일 뿐입니다. 진짜 기획자의 역할은 비즈니스의 모호한 요구사항을 개발과 디자인이 가능한 '구조적 언어'로 번역하고, 서비스의 시작부터 런칭 직전의 QA까지 전체 제품 수명 주기(Product Life Cycle)를 촘촘하게 관리하는 것입니다.

선박의 기준정보를 관리하는 신규 서비스를 직접 구축하며, 기획의 3대 뼈대인 요구사항, IA, 플로차트를 통해 문제를 해결하고 성장했던 실무 이야기를 공유해 보려고 합니다.

2. 요구사항 분석 및 정의: 화면 채우기 급급했던 날들에서 발견한 SRS의 핵심

프로젝트를 진행하다 보면 현업이나 고객분들에게 "이 화면에 이런 정보도 나오게 해달라", "저 기능도 넣어달라"는 수많은 요청을 받게 됩니다. 기획 초창기에는 저 역시 이 요청들을 화면에 무작정 채워 넣기 급급했었습니다. 일단 버튼을 만들고 인풋 박스를 배치하며 요구를 시각화하는 데만 몰두했던 것입니다. 하지만 신규 프로젝트를 이끌며 기획 프로세스를 깊이 되돌아보니 그 과정이 바로 요구사항 정의의 핵심이었습니다.

2.1 요구사항 분석의 4단계 절차

실무에서 저는 이 모호함을 명확함으로 바꾸기 위해 타당성 조사, 요구사항 도출 및 분석, 요구사항 정의, 요구사항 검증 및 관리라는 4단계 절차를 거치며 뼈대를 잡아나갔습니다.
[1. 타당성 조사] ➔ [2. 요구사항 도출/분석] ➔ [3. 요구사항 정의] ➔ [4. 요구사항 검증/관리]

• 타당성 조사

• 프로젝트 추진의 필요성과 리소스 대비 실현 가능성(Technical/Business Feasibility)을 검토합니다.

• 요구사항 도출 및 분석

• 현업(유저)으로부터 개발하고자 하는 시스템의 기능 사항을 청취하고 정리합니다. 기획자는 수동적으로 받아 적는 것이 아니라, 필요한 내용을 역으로 질의하고 사용자 관점의 시나리오 형태로 유스케이스(Use Case)를 정의해야 합니다.

• 요구사항 정의

• 분석된 시나리오를 기반으로 시스템 동작을 설명하는 기능(Functional) 항목과 시스템의 속성, 제약조건, 성능을 뜻하는 비기능(Non-Functional) 항목을 구분하여 명확한 문장으로 기술합니다.

• 요구사항 검증 및 관리

• "고객이 원하는 것이 맞는지", "개발이 가능한지", "테스트로 검증 가능한지" 여러 파트(개발/디자인/비즈니스)의 관점을 확인하고 피드백을 반영합니다. 이후 변경 이력(변경일, 변경 항목 등)을 지속적으로 트래킹합니다.

요구사항 분석 시 주의 사항

요구사항 분석 과정에서 제가 느낀 실무 주의 사항들이 있습니다.

• 내용은 최대한 상세하게 분석: '로그인 기능 필요'가 아니라 '어떤 수단으로, 어떤 예외 처리를 포함할 것인가'까지 파고들어야 합니다.

• 현업 담당자의 용어 그대로 기록: 커뮤니케이션 미스를 줄이기 위해 초기에는 도메인 전문가나 현업이 사용하는 단어를 그대로 아카이빙합니다.

• 서면 공유 및 컨펌: 정리된 내용은 반드시 메일이나 공식 협업 툴로 관계자에게 공유한 후 최종 컨펌을 받아 둡니다. 이는 추후 발생할 수 있는 범위 산정(Scope) 분쟁을 막는 방어선이 됩니다.

2.2 요구사항 정의서(SRS) 구성 항목 및 작성 예시

요구사항 정의서(Software Requirement Specification)는 "시스템이 어떻게(How) 수행될 것인가가 아니라, 무엇을(What) 수행할 것인가"에 대해 기술하는 문서입니다.

• 핵심 구성 항목: 요구사항 ID, 분류/항목, 상세 내용, 요청자/요청일자, 중요도(우선순위), 난이도, 수용 여부, 담당자, 담당자 의견, 비고

요구사항 정의서 실무 가이드 예시

요구사항 명세서 검토 체크리스트

아래 체크리스트를 통해 요구사항을 올바르게 정리했는지 확인할 수 있습니다.

• [ ] 모든 요구사항이 모호하지 않고 명확하며 구체적인가?

• [ ] 정상 흐름 외에 예외 상황과 에러 처리가 명시적으로 포함되어 있는가?

• [ ] 현재 인프라와 리소스로 기술적으로 구현 가능한 수준인가?

• [ ] 테스트 결과가 참/거짓으로 명확히 갈릴 수 있는 테스트 가능한 기준이 제시되어 있는가?

• [ ] 하나의 요구사항이 다른 요구사항의 논리와 충돌하지 않는가?

• [ ] 개인정보보호법 등 보안 및 규정 준수 사항이 누락 없이 반영되어 있는가?

• [ ] 마일스톤에 맞게 우선순위(상/중/하)가 적절히 설정되어 있는가?

3. 서비스 구조 설계(IA, 플로차트)

3.1 정보 구조도(IA, Information Architecture)

이제 본격적으로 서비스의 전체 화면과 메뉴 구조를 체계적으로 설계하는 정보 구조도(IA, Information Architecture) 수립 단계로 넘어갑니다. 백지 상태에서 방대한 선박 데이터들을 마주했을 때, 유저가 시스템 안에서 길을 잃지 않도록 대메뉴와 서브메뉴를 분류하고 그룹화하여 촘촘한 Depth 구조를 짜 내려가는 과정이 필요했습니다.

• Depth 설계 규칙: 사용자의 복잡도를 낮추고 피로도를 줄이기 위해 가급적 모든 메뉴는 3Depth 이하로 설계하는 것을 원칙으로 삼았습니다. 물론 선박 관리 시스템처럼 복잡한 구조에서는 단계별로 노출되어야 하는 화면이 많아질 수 있지만, 이 역시 명확한 논리적 근거 하에 Depth를 최소화하려는 노력이 선행되어야 합니다.

• 화면 ID 가이드 규칙: IA에 등록되는 모든 페이지는 고유의 화면 ID를 가집니다.

• 1~2 Depth 메뉴명 약자: 대메뉴의 영문 이름을 알파벳 대문자 2개로 줄여 사용합니다. (예: 회원 관리 ➔ MB)

• Depth별 구분 코드: Depth별 숫자로 구분하여 화면 간 규칙을 부여합니다. (예: MB_01, MB_01_01)

• 화면 형태 구분 약자: 상세 내용에 따라 형태(List, Detail, Popup 등)를 접미사로 붙여 구분하는 것도 가능합니다.

• 절대 규칙: ID는 결코 중복되어선 안 되며, 기획 변경으로 인해 특정 ID가 수정되거나 삭제되더라도 해당 ID를 다른 화면에 재사용하지 않는 것이 히스토리 관리의 철칙입니다.

• IA 핵심 구성 요소: 분류, 서비스 Depth(1/2/3), 서비스 화면 번호, 화면 ID, 페이지 정의 및 요구사항, 세부 사항, 진행 단계(대기/기획중/완료)

3.2 플로차트(Flowchart)

플로차트는 화면 및 기능 단위로 사용자의 이동 동선과 시스템의 처리 과정을 도식화하는 문서입니다. 사용자가 어떤 프로세스대로 서비스를 이용하고 시스템이 내부적으로 어떻게 작동하는지 한눈에 파악할 수 있도록 돕습니다.

특히 제가 진행했던 선박 관리 서비스는 기획하다 보면, 수많은 화면들이 유기적으로 얽혀 동작하거나 복잡한 데이터 예외 상황들이 쉴 새 없이 발생하곤 했습니다. 초기에는 기존 방식대로 스토리보드(화면 설계서)의 와이어프레임 옆에 텍스트로 예외 케이스들을 아무리 길고 상세하게 적어두어도, 제 기획 의도를 100% 전달하기가 너무나 어려웠습니다.

이 문제를 해결하기 위해, 국제 표준 기호(시작, 프로세스, 판단 분기 등)를 준수한 플로차트를 그려 개발자분들에게 함께 전달했습니다. 사용자의 동선이 꼬이지 않도록 조건 분기(마름모)에 따른 흐름을 명확하게 단선화하는 데 집중했습니다.

플로차트 작성 시 준수해야 할 국제표준 규칙

• 표준 기호 활용: 시작/종료(둥근 사각형), 프로세스(직사각형), 비교/판단(마름모) 등 국제 표준 기호를 엄격히 준수합니다.

대표 국제 플로차트 도형(ISO 5807 국제 표준)

• 시선의 흐름: 전체적인 사용자 동선이 좌측에서 우측, 혹은 위에서 아래로 자연스럽게 흘러가도록 구성합니다.

• 판단의 분기: 마름모(비교/판단) 기호를 사용할 때 결과값은 대개 Yes일 경우 아래 화살표, No일 경우 좌/우 화살표로 뺍니다.

• 입출력의 원칙: 비교 및 판단에 대한 입·출력선은 반드시 논리적으로 명확해야 하며, 복잡하게 꼬이지 않도록 프로세스당 흐름을 단선화합니다.

• 추천 툴: 실무에서는 Draw.io, Visio, Axure, 혹은 최근 큰 인기를 끌고 있는 Figma와 Miro를 주로 사용합니다.

4. 결론: 단단한 뼈대가 무결점 서비스를 만든다

선박 기준정보 서비스를 기획하며 느낀 점은, 기획자는 단순히 '화면을 그리는 사람'이 아니라 촘촘한 '논리'와 유기적인 '프로세스'를 구축하는 시스템 아키텍트에 가깝다는 것입니다.

초기에 화면 디자인에만 치중했다면 이 방대한 데이터 서비스를 절대 런칭하지 못했을 것입니다. 앞단에서 요구사항을 정제하고, IA로 뼈대를 세우고, 플로차트로 동선을 정리했기에 가능한 결과였습니다.

이번 글에서 서비스의 상위 개념과 구조를 탄탄하게 다졌다면, 다음 게시물에서는 이렇게 작성한 구조들을 바탕으로 디자이너, 개발자와 소통하기 위한 최종 설계도인 '최종 화면 설계서(스토리 보드)'를 만든 경험을 공유해 보려고 합니다. 더불어 서비스 런칭 직전, 제품의 퀄리티를 최상으로 끌어올리기 위해 직접 테스트(QA)를 수행하며 겪었던 실무 이야기로 다시 돌아오겠습니다.

Ryu