SA 기획: 현행 분석에서 요구사항 추적표까지

검수 회의에서 고객이 말합니다. "주문 목록을 엑셀로 내려받으면 거래처별 소계가 있어야죠." 개발한 쪽은 요구사항 정의서를 펼칩니다. 거기에는 한 줄이 있습니다.

SFR-012 | 주문 목록 엑셀 다운로드 | 조회 조건에 맞는 주문을 엑셀 파일로 내려받는다

소계 이야기는 어디에도 없습니다. 이 기능은 완성된 걸까요, 덜 된 걸까요. 답은 코드가 아니라 저 한 줄에 달려 있고, 그 한 줄을 쓰는 사람이 SA입니다.

받아 적는 사람으로는 설명되지 않는 SA의 책임

SA는 System Analysis(또는 System Analyst)의 약자로, 주로 SI 프로젝트에서 고객의 업무를 분석해 시스템이 해야 할 일을 정의하는 역할을 가리킵니다. 흔히 이 역할을 "고객이 원하는 것을 받아 적어 개발자에게 전달하는 사람"으로 이해합니다. 통역사에 가까운 그림입니다.

그 그림으로는 위의 검수 회의가 설명되지 않습니다. 고객은 아마 처음부터 소계를 원했을 겁니다. 매일 그렇게 써 왔으니 따로 말할 이유가 없었을 뿐입니다. 받아 적기만 했다면 이 요구는 영영 문서에 들어오지 않습니다. 반대로 고객이 말한 것을 전부 적었다면 일정과 금액이 감당하지 못할 만큼 범위가 커집니다.

저는 SA의 본업을 받아 적기가 아니라 경계를 긋는 일로 봅니다. 고객이 말하지 않은 것 중 꼭 필요한 것은 찾아내서 넣고, 말한 것 중 이번에 하지 않을 것은 명시적으로 밖에 둡니다. 요구공학 국제 표준인 ISO/IEC/IEEE 29148도 요구공학을 발주자(acquirer)와 공급자(supplier) 사이를 중재하며 요구사항을 세우고 유지하는 기능으로 정의합니다. 한쪽의 말을 옮기는 일이 아니라 양쪽이 합의할 수 있는 선을 만드는 일이라는 뜻입니다.

현행 분석(As-Is)이 요구사항보다 먼저인 이유

SA의 첫 단계는 요구사항 수집이 아니라 현행 분석입니다. 지금 업무가 어떤 순서로, 누구의 손을 거쳐, 어떤 자료로 돌아가는지를 먼저 그립니다. 담당자 인터뷰도 하지만, 그보다 무게를 두는 것은 실제로 쓰이는 엑셀, 양식, 출력물, 메일입니다.

순서가 이런 이유는 사람이 자기 업무를 설명할 때 예외를 빼고 말하기 때문입니다. "주문이 들어오면 거래처에 넘긴다"는 설명 뒤에는 월말에만 다르게 처리하는 거래처, 담당자가 머릿속으로 맞추는 단가, 엑셀 매크로 안에 숨은 계산식이 있습니다. 시스템은 이 예외를 전부 알아야 돌아갑니다. 위의 소계도 현행 엑셀을 한 번 열어 봤다면 보였을 규칙입니다.

현행 분석이 끝나면 목표 모습(To-Be)을 그립니다. 바뀐 업무 흐름에서 무엇을 시스템이 맡고 무엇을 사람이 계속 하는지를 나눕니다. 이 나눔이 곧 요구사항 목록의 뼈대가 됩니다.

요구사항 정의서 한 줄이 계약 범위가 되는 구조

요구사항 정의서는 SA의 대표 결과물이고, 계약에서 가장 무거운 문서이기도 합니다. 요구사항마다 고유 번호가 붙고, 이 번호 단위로 개발하고 검수합니다. 국내 공공 사업의 제안요청서에서는 기능 요구사항을 SFR, 인터페이스를 SIR, 데이터를 DAR, 보안을 SER처럼 유형별 접두어로 나누는 관례가 흔합니다.

그래서 요구사항 한 줄의 문장이 곧 돈입니다. "빠르게 조회된다", "편리하게 입력한다" 같은 문장은 검수 때 양쪽이 서로 다르게 읽습니다. 29148은 좋은 요구사항 한 줄이 갖춰야 할 특성 아홉 가지를 꼽는데, 그중 실무에서 가장 자주 깨지는 것이 모호하지 않을 것(unambiguous)과 검증할 수 있을 것(verifiable)입니다. "조회 결과는 3초 안에 표시된다"는 검증할 수 있고, "빠르게 조회된다"는 검증할 수 없습니다.

위의 SFR-012도 같은 문제를 안고 있습니다. "엑셀 파일로 내려받는다"는 문장은 어떤 열이, 어떤 순서로, 어떤 합계와 함께 나오는지를 말하지 않습니다. 저라면 이 줄에 출력 열 목록과 소계 여부를 적거나, 현행 엑셀 양식을 첨부해 "이 양식과 같게"라고 못 박겠습니다. 어느 쪽이든 검수 회의에서 펼쳤을 때 답이 나오는 문장이어야 합니다.

범위 밖 목록도 같은 무게를 가집니다. 이번에 하지 않는 것을 적어 두지 않으면, 고객은 당연히 포함된 줄 알고 공급자는 당연히 빠진 줄 압니다. 저는 요구사항 정의서에서 이 목록이 빈 경우를 가장 위험한 신호로 봅니다.

요구사항 추적표가 지키는 것

요구사항은 정의서에 적힌 순간부터 사라질 위험을 안습니다. 설계서로 옮겨지면서 빠지고, 개발 중에 우선순위에 밀리고, 테스트 항목에서 누락됩니다. 요구사항 추적표(RTM)는 이걸 막는 표입니다. 요구사항 번호 하나마다 그것을 반영한 설계 항목, 구현한 프로그램, 확인한 테스트 케이스를 한 줄로 잇습니다.

SFR-012 → 화면설계 UI-ORD-03 → 프로그램 ORD_EXPORT → 테스트 TC-ORD-021

이 표에서 오른쪽이 비어 있는 줄이 곧 아직 끝나지 않은 일입니다. 반대로 요구사항 번호 없이 존재하는 프로그램은 누구도 요청하지 않은 기능이거나 문서에서 빠진 요구입니다. 추적표는 양방향으로 읽힐 때 쓸모가 있습니다.

변경도 이 표 위에서 관리됩니다. 개발 도중 고객이 소계를 추가해 달라고 하면, SA는 그것이 기존 SFR-012의 해석 범위 안인지, 새 요구사항인지를 판단하고 기록합니다. 새 요구사항이면 일정이나 비용 조정의 근거가 됩니다.

서비스 기획, 설계 역할과 헷갈리는 지점

SA와 가장 자주 섞이는 것이 서비스 기획입니다. 둘 다 요구를 모으고 정책을 정하고 화면의 흐름을 그립니다. 차이는 누구의 요구를, 어떤 약속 아래에서 다루느냐입니다. 서비스 기획은 불특정 다수의 사용자를 상대하고 출시 뒤에도 계속 제품을 바꿔 나갑니다. SA는 특정 고객 조직의 업무를 상대하고, 합의한 범위를 기한 안에 넘겨 검수받는 계약 구조 안에서 일합니다. 서비스 기획의 정책서는 다음 달에 바꿀 수 있지만, SA의 요구사항 정의서를 바꾸려면 변경 절차를 거쳐야 합니다.

SI 조직 안에서는 설계 역할들과도 경계가 겹칩니다. 흔히 AA(애플리케이션 아키텍트)는 소프트웨어 구조를, TA(기술 아키텍트)는 인프라와 기술 구성을, DA(데이터 아키텍트)는 데이터 모델을 맡습니다. SA는 이들에게 "무엇을" 넘기고 이들은 "어떻게"를 설계합니다. 다만 작은 프로젝트에서는 SA가 데이터 모델까지 그리는 일이 흔합니다.

여기서 하나 짚어 둘 것이 있습니다. SA라는 약어를 System Architect로 쓰는 회사도 있어서, 채용 공고의 SA가 분석가인지 아키텍트인지는 업무 설명을 봐야 압니다.

회사와 사업마다 달라지는 SA의 범위

SA가 어디서 시작해 어디서 끝나는지는 명세가 정하지 않고 조직이 정합니다. 공공 사업처럼 제안요청서에 요구사항이 이미 번호와 함께 주어지는 경우, SA의 일은 그 요구사항을 상세화하고 해석의 여지를 줄이는 쪽에 무게가 실립니다. 민간 프로젝트에서 요구사항이 정리되지 않은 채 시작하면, 현행 분석부터 요구사항 도출까지 SA가 처음부터 만들어야 합니다.

규모에 따라서도 다릅니다. 큰 SI 프로젝트는 업무 영역별로 SA를 여럿 두고 PL 아래에 배치합니다. 작은 프로젝트에서는 PM이 SA를 겸하거나, 개발자가 분석부터 구현까지 이어서 맡습니다. 개발자가 SA를 같이 할 때 무엇이 달라지는지는 별도 글에 적었습니다.

어느 형태든 변하지 않는 것은 하나라고 봅니다. 검수 회의에서 누군가 "이건 되는 거였나요?"라고 물었을 때, 펼쳐서 답할 수 있는 한 줄을 미리 써 두는 것이 SA의 일입니다.