요구사항 분석과 모델링

개발과 분석은 다른 종류의 일이다

1장에서 소프트웨어 개발은 계획, 요구사항 분석, 설계, 구현, 시험, 유지보수의 여섯 단계를 거친다고 했다. 이 시리즈는 이제 3부(6~9장)로 접어들어 그중 요구사항 분석을 본격적으로 다룬다.

요구사항 분석을 시작하기 전에 짚고 넘어갈 게 있다 — 분석은 뒤이어 나올 구현(설계, 코딩, 시험)과 성격이 완전히 다른 활동이라는 점이다. 구현은 "무엇을 만들어야 하는가"가 이미 정해진 상태에서 시작한다. 범위가 뚜렷하고, 잘 만들었는지 검증하는 기준도 비교적 명확하다. 책마루 프로젝트로 치면 "재고가 0이 되면 품절 표시를 한다"는 요구사항이 확정된 다음, 그 로직을 실제로 코드로 옮기고 테스트하는 일이 구현이다. 이 일은 어렵긴 해도 목표가 흔들리지는 않는다.

분석은 다르다. 분석가는 아직 "정말 이게 맞는 요구사항인가"부터 다퉈야 한다. 책마루 사장님은 "재고가 실시간으로 보였으면 좋겠다"고 말하지만, 직원은 "매장 판매랑 온라인 판매랑 재고를 매번 실시간으로 맞추는 게 그렇게 쉬운 일이 아니다"라고 반박할 수 있다. 이 둘 사이에서 무엇이 진짜 필요한 것이고 무엇이 기술적으로 감당 가능한 것인지 협상하고 조율하는 게 분석가의 일이다. 확정된 게 별로 없는 상태에서 시작해서, 여러 이해관계자의 서로 다른 기대를 하나의 목표로 수렴시켜야 한다 — 그래서 분석은 개발보다 훨씬 더 사람을 상대하는 일에 가깝다.

이런 성격 때문에 재미있는 비대칭이 하나 생긴다. 프로젝트가 잘 끝나면 "설계를 잘했다", "코드가 깔끔하다"는 칭찬은 자주 듣지만 "분석을 잘했다"는 말은 잘 안 나온다. 반대로 프로젝트가 실패하면 십중팔구 "애초에 요구사항 분석이 잘못됐다"는 말이 나온다. 분석은 성공을 만들어내는 일이라기보다 실패를 막는 방어적인 활동에 가깝기 때문이다 — 눈에 띄지 않지만 없으면 반드시 티가 나는 일이라고 생각하면 된다.

요구사항 분석이란 무엇인가

요구사항 분석을 한 문장으로 정의하면, 시스템이 달성해야 할 목표를 확립하는 과정이다. 책마루 사장님이 "온라인 주문 되게 해주세요"라는 막연한 말로 프로젝트를 시작했다면, 분석가의 일은 이 말을 "손님은 우편번호로 배달 가능 여부를 확인할 수 있어야 한다", "재고가 0이 되면 자동으로 품절 표시된다" 같은 구체적이고 검증 가능한 문장들로 바꿔내는 것이다.

이 과정의 최종 산출물은 요구사항 명세서다. 이 문서가 얼마나 중요한지는 몇 가지 성격을 보면 알 수 있다.

• 약속 문서다. 요구사항 명세서는 개발사와 고객(책마루 사장님) 사이의 계약에 가깝다. 개발 중간에 "이 기능 넣어주기로 하지 않았나요?"라는 다툼이 생기면 이 문서가 기준이 된다.
• "무엇"만 담고 "어떻게"는 담지 않는다. 1장에서 다룬 원칙이 여기서 다시 등장한다. "배달 가능 지역을 자동으로 확인해야 한다"는 담되, "우편번호 매핑 테이블을 쓴다"거나 "지도 API를 쓴다"는 담지 않는다. 방법을 정하는 건 다음 단계인 설계의 몫이다.
• 시스템의 생명이 끝날 때까지 따라다닌다. 시험 단계의 테스트 계획도, 나중에 기능을 추가할지 말지 판단하는 기준도 결국 이 문서에서 나온다. 요구사항 명세서 없이 시스템을 만든다는 것은 "무엇을 검증할지 정하지 않고 만들겠다"는 것과 같다.

요구사항 분석이 유독 어려운 이유

분석이 개발보다 어렵게 느껴지는 데는 구체적인 이유들이 있다. 책마루 프로젝트를 기준으로 하나씩 짚어보자.

의사소통과 요구사항의 계속적 변화

사용자와 분석가 사이에 합의된 내용이라도, 시간이 지나고 나면 서로 다르게 기억하는 경우가 흔하다. 책마루 사장님이 "배달 가능 지역"이라고 말할 때 떠올리는 그림과, 개발자가 코드로 옮기며 떠올리는 그림이 처음부터 같으리라는 보장은 없다. 그래서 말로 하는 합의보다 그림이나 문서로 남기는 합의가 훨씬 안전하다 — 이후 장에서 다룰 여러 모델링 기법들이 결국 이 문제를 풀기 위한 도구다.

더 까다로운 건 요구사항 자체가 계속 바뀐다는 점이다. 사장님도 프로젝트가 진행되며 시스템을 점점 더 이해하게 되고, 그럴수록 "아, 이것도 필요하겠다"는 생각이 계속 늘어난다. 날아다니는 목표를 잡으려 들면 개발은 영영 끝나지 않는다. 그래서 어느 시점에는 요구사항을 **동결(freezing)**하고, 그 시점의 요구사항 명세서를 기준선 문서로 삼는다. 이후의 변경은 개발자와 사용자 양측의 동의를 거쳐야만 반영된다 — 4장에서 다룬 변경통제의 원칙이 여기서도 그대로 적용된다.

정치적 문제와 일 분담의 문제

분석은 순수하게 기술적인 작업이 아니라 상당 부분 정치적인 작업이다. 책마루라면 사장님과 직원의 요구가 부딪힐 수 있다. 사장님은 "주문만 잘 들어오면 된다"고 생각하지만 직원은 "포장 목록을 프린터로 뽑고 싶다"고 요구할 수 있다. 어느 쪽 목소리가 더 크게 반영되느냐는 순전히 기술적인 문제가 아니다. 방법론을 도입해 분석 과정을 체계적이고 공식적으로 만들면 이런 정치적 영향력을 최소화할 수 있지만, 완전히 없애기는 어렵다.

시스템 규모가 커지면 분석가 한 명이 다 감당할 수 없어 여러 명이 일을 나눠 맡는다. 이때 분야별로 깔끔하게 나누지 않으면 나중에 다시 합치는 게 훨씬 더 어려워진다 — 책마루처럼 작은 프로젝트에서도 "주문·결제 담당"과 "재고·배달 담당"을 초기에 명확히 갈라놓지 않으면, 두 영역이 겹치는 지점(예: 결제 완료 시점에 재고를 언제 차감할지)에서 혼선이 생긴다.

공식 기술 검토회: 요구사항 명세서가 완성되면 고객, 분석가, 개발자, 시험자가 한자리에 모여 검토하고 서명하는 절차를 거치는 게 원칙이다. 책마루처럼 작은 프로젝트에서 거창한 회의를 열 필요는 없지만, "사장님과 개발팀이 이 문서에 함께 동의했다"는 사실을 남기는 것 자체가 나중의 분쟁을 크게 줄여준다.

사용자와 함께 일하는 법 — 책마루의 두 이해관계자

요구사항을 모으는 방법은 인터뷰, 설문지, 회의록 작성 등 다양하지만, 방법보다 중요한 건 태도다. 책마루 프로젝트에서 분석가가 놓치기 쉬운 함정은 사장님 목소리에만 귀 기울이는 것이다. 사장님은 예산을 승인하는 사람이라 목소리가 크지만, 실제로 시스템을 매일 만지는 사람은 매장 직원이다.

이해관계자마다 요구사항을 뽑아낸 뒤에는 이걸 표로 정리해 서로 충돌하는지 확인하는 게 좋다. "주문 알림은 태블릿에 즉시 떠야 한다"(직원)와 "야간에는 알림이 울리지 않아야 한다"(직원, 다른 맥락)처럼 같은 사람의 요구사항끼리도 충돌할 수 있다. 이런 충돌을 요구사항 명세서 작성 단계에서 미리 걸러내지 못하면, 설계나 구현 단계에서 발견될 때 수정 비용이 훨씬 커진다는 건 1장에서 이미 확인한 원칙이다.

모델링이란 무엇인가

이제 이 장의 핵심 주제로 넘어간다. 요구사항을 글로만 나열하면 분량이 늘어날수록 사람들이 전체 그림을 놓치기 쉽다. 그래서 분석가는 모델링이라는 도구를 쓴다.

모델링이란 시스템의 동작이나 구조를 이해하기 위해 간단한 도해나 표기법으로 추상화하는 작업이다. 여기서 핵심은 "불완전해도 괜찮다"는 점이다. 좋은 모델은 우리가 지금 풀려는 문제와 관련 없는 세부사항은 과감히 생략하고, 정말 중요한 부분만 남긴다. 지도를 예로 들면 이해하기 쉽다 — 등산객용 지형도와 지질학자용 지질도는 같은 지역을 그리지만 완전히 다른 정보를 담는다. 어느 쪽도 "실제 산의 모든 것"을 담지 않지만, 각자의 목적에는 충분히 쓸모 있다.

모델의 세 요소: 표현, 규약, 상술

모델을 제대로 만들려면 세 가지가 필요하다.

• 표현(Representation): 실제로 그리는 도형이나 그림 그 자체. 책마루 재고-공급자-상품의 관계를 사각형과 마름모로 그린 도표가 여기 해당한다.
• 규약(Convention): 그 도형이 무엇을 뜻하는지에 대한 약속. 사각형은 개체, 마름모는 관계를 나타낸다는 식의 표기법 정의다.
• 상술(Specification): 그림만으로는 다 담기지 않는 세부 설명을 텍스트로 보충하는 것. "배달 가능 여부"라는 항목이 정확히 어떤 값(예/아니오, 혹은 소요 시간)을 갖는지는 그림이 아니라 별도의 텍스트로 정의해야 한다.

세 가지가 다 갖춰져야 모델이 사용자와 개발자 사이의 대화 도구로 제 역할을 한다. 표현만 있고 규약이 없으면 그림은 예쁘지만 아무도 무슨 뜻인지 모른다.

소프트웨어 시스템을 보는 세 가지 관점

시스템 하나를 완전히 설명하는 모델은 없다. 대신 소프트웨어 공학에서는 시스템을 세 가지 관점으로 나눠서 본다 — 그리고 이 세 관점이 바로 앞으로 이어질 7장, 8장, 9장의 주제다.

기능 관점 — 무슨 일을 하는가

기능 관점은 시스템이 입력을 받아 어떤 출력을 만들어내는지, 즉 데이터에 어떤 계산과 변환이 일어나는지에 초점을 맞춘다. 책마루로 치면 "손님이 상품을 담은 장바구니(입력)가 결제 완료된 주문(출력)으로 바뀌는 과정에서 어떤 처리 단계들을 거치는가"를 보는 관점이다. 이 관점이 언제 일어나는지(순서)는 다루지 않는다 — 순서는 다음 관점의 몫이다.

동적 관점 — 시간에 따라 어떻게 바뀌는가

동적 관점은 시스템이 가지는 상태와, 그 상태를 바꾸는 사건에 초점을 맞춘다. 책마루 주문 하나를 예로 들면, 주문은 "접수됨" → "재고 확인 중" → "포장 중" → "배달 중" → "배달 완료"라는 상태를 순서대로 거친다. 이 상태들 사이의 전환이 언제, 무엇 때문에 일어나는지를 보여주는 게 동적 관점이다. 재고가 부족해 "품절 취소"로 빠지는 예외적인 흐름도 이 관점에서 다룬다.

정보 관점 — 무엇으로 이루어져 있는가

정보 관점은 시스템에 필요한 객체들과 그 객체들 사이의 관계를 정적으로 포착한다. 책마루라면 "상품", "주문", "손님", "재고"라는 객체들이 있고, "한 주문은 여러 상품을 포함한다", "한 손님은 여러 주문을 낼 수 있다" 같은 관계가 있다. 이 관점은 시간이 지나도 잘 변하지 않는다는 장점이 있어서, 시스템 개발의 튼튼한 기초가 되어준다. 데이터베이스 설계와 직결되는 관점이기도 하다.

왜 세 관점을 다 봐야 하는가

세 관점 중 어느 하나도 시스템의 전체 모습을 완벽하게 설명하지 못한다. 컴파일러처럼 입력을 변환해 출력하는 일이 본질인 시스템은 기능 관점이 두드러지고, 데이터베이스 시스템은 정보 관점이 두드러지며, 통신 시스템은 동적·기능 관점이 두드러진다. 하지만 어느 시스템이든 세 관점을 통합해야 요구사항이 빠짐없이 표현된다. 책마루 온라인 주문 시스템처럼 세 관점이 고르게 중요한 시스템 — 무엇을 처리하는지(기능), 주문이 어떤 순서로 상태를 바꾸는지(동적), 상품·주문·재고가 어떻게 연결되는지(정보) — 가 오히려 이 세 관점의 필요성을 가장 잘 보여주는 사례다.

핵심 정리

• 요구사항 분석은 개발(설계·구현·시험)과 성격이 다른 활동이다. 목표가 확정되지 않은 상태에서 이해관계자 간의 협상을 통해 목표를 확립해가는 과정이기 때문이다.
• 요구사항 명세서는 개발자와 고객 사이의 약속 문서이며, "무엇"을 만들지만 기록하고 "어떻게" 만들지는 기록하지 않는다.
• 분석이 어려운 이유는 의사소통 문제, 요구사항의 계속적 변화, 정치적 문제, 일 분담 문제 등 복합적이다. 요구사항 동결과 공식 기술 검토회 같은 절차가 이를 완화해준다.
• 모델링은 시스템을 이해하기 위해 불필요한 세부사항을 걷어내는 추상화 작업이며, 표현·규약·상술 세 요소로 구성된다.
• 소프트웨어 시스템은 기능·동적·정보 세 관점으로 나눠 볼 수 있으며, 이 세 관점의 통합이 있어야 요구사항이 완전하게 표현된다.

다음 장(7장 기능 모델링)에서는 이 세 관점 중 기능 관점을 구체적으로 다룬다. 책마루의 주문 처리 과정을 자료흐름도로 그려가며, 시스템을 큰 기능에서 작은 기능으로 쪼개나가는 구조적 분석기법을 살펴본다.