개념
QA에서 BA로 — 같은 눈, 반대 방향
QA는 요구사항 문서를 받아 모호함과 누락을 찾는다(모듈 2). BA는 그 문서를 만든다. 같은 눈이 반대 방향을 본다. QA 시절 "이 경우는 어떻게 되나요?"라고 묻던 질문을, BA는 현업과 사용자에게 먼저 던져 답을 요구사항에 넣는다. 그래서 요구사항 리뷰를 잘하던 QA는 BA로 넘어가기 좋은 출발점에 서 있다.
BABOK v3 — BA 일의 지도
IIBA(International Institute of Business Analysis)의 BABOK 가이드는 비즈니스 분석의 표준 지식 체계다. 현재 판은 v3이며, 6개 지식 영역과 50개 기법으로 구성된다.
| 지식 영역 | 무엇을 하나 | QA 경험과의 연결 |
|---|---|---|
| 비즈니스 분석 계획·모니터링 | 분석 접근·이해관계자 참여·거버넌스 계획 | 테스트 계획과 같은 구조 |
| 도출과 협업 | 이해관계자에게서 정보를 끌어내고 확인 | 요구사항 리뷰 회의의 질문(모듈 2 레슨 6) |
| 요구사항 생명주기 관리 | 추적·유지·우선순위·변경 승인 | 추적성(모듈 2 레슨 5), 변경 통제(모듈 44 레슨 7) |
| 전략 분석 | 현재 상태·목표 상태·변화 전략·위험 | 위험 분석(모듈 4) |
| 요구사항 분석·설계 정의 | 요구사항 명세·모델링·검증·확인 | 테스트 가능한 요구사항(모듈 2 레슨 2), 결정표·상태 전이(모듈 3) |
| 솔루션 평가 | 구현된 솔루션이 가치를 내는지 평가 | 인수 테스트, 출시 후 지표(레슨 4) |
"도출과 협업" 영역의 다섯 과업 — 도출 준비, 도출 수행, 결과 확인, 비즈니스 분석 정보 전달, 이해관계자 협업 관리 — 이 이 레슨의 뼈대다.
이해관계자 분석 — 누구에게 물을 것인가
도출의 첫 실수는 물어볼 사람을 빠뜨리는 것 이다. 영업 담당자에게만 물어 만든 요구사항은 정산 담당자가 쓰기 어렵고, 관리자에게만 물으면 현장 사용자의 실제 흐름이 빠진다.
[이해관계자 목록 — 가맹점 정산 시스템 개편]
역할 관심 영향력 관여 방법
정산 담당(현업) 정확성, 마감 시간 단축 높음 인터뷰 + 관찰 + 워크숍
재무팀 회계 처리, 감사 대응 높음 인터뷰 + 산출물 검토
가맹점(외부) 정산 명세 이해 쉬움 중간 설문 + 문의 데이터
CS 정산 문의 대응 중간 문의 데이터 + 인터뷰
운영·개발 배치 안정성, 변경 용이성 높음 워크숍
감사·컴플라이언스 규정 준수 증적 높음 규정 검토 + 확인영향력과 관심으로 2x2를 그리면 관여 수준을 정할 수 있다. 영향력과 관심이 모두 높은 이해관계자는 밀착 관리, 영향력은 높지만 관심이 낮으면 요약 보고로 만족 유지 한다.
도출 기법 고르기
BABOK은 50개 기법을 다루지만, 실무에서 자주 쓰는 도출 기법은 몇 가지다.
| 기법 | 강점 | 약점 | 잘 맞는 상황 |
|---|---|---|---|
| 인터뷰 | 깊이, 개인적 우려 파악 | 시간, 한 사람의 관점 | 핵심 이해관계자, 민감한 주제 |
| 워크숍 | 여러 관점 동시 합의 | 진행 난이도, 목소리 큰 사람 | 흐름 합의, 우선순위 |
| 관찰(쉐도잉) | 말하지 않는 실제 행동 | 관찰 효과, 시간 | 현업 업무 흐름, 예외 처리 |
| 문서 분석 | 기존 규정·양식·시스템 | 현실과 다를 수 있음 | 현행 파악, 규정 기반 업무 |
| 설문 | 많은 사람의 의견 | 깊이 부족 | 외부 사용자, 우선순위 경향 |
| 프로토타입 | 보여 주고 반응 받기 | 해결책에 고정될 위험 | 화면 중심 요구, 모호한 요구 |
관찰 은 QA 출신 BA가 특히 잘 쓸 수 있는 기법이다. 모듈 5 레슨 4의 "세심하게 관찰하기"와 같은 태도로 현업을 본다. 현업 담당자는 인터뷰에서 "정산은 시스템이 다 해 줘요"라고 말하지만, 관찰하면 매일 아침 엑셀로 예외 건을 따로 맞추고 있다. 그 엑셀이 숨은 요구사항 이다.
인터뷰 진행
[정산 담당 인터뷰 60분 구성]
5분 목적 설명, 기록 동의
15분 업무 흐름: "어제 하루 정산 업무를 처음부터 끝까지 이야기해 주세요."
15분 예외: "평소와 다르게 처리해야 했던 건은? 가장 최근 사례는?"
10분 고충: "가장 시간이 많이 드는 일, 가장 실수가 나기 쉬운 일은?"
10분 목표: "새 시스템에서 딱 하나만 좋아진다면?"
5분 정리, 자료 요청(양식·엑셀·규정), 후속 확인 일정"어제 하루"와 "가장 최근 사례"처럼 구체적인 과거 를 묻는다. "보통 어떻게 하세요?"는 이상적인 절차를, "어제 어떻게 했나요?"는 실제 절차를 끌어낸다.
업무 흐름 모델링 — AS-IS와 TO-BE
도출한 내용은 업무 흐름으로 그린다. BPMN(Business Process Model and Notation)은 업무 흐름 표준 표기법이다. 모든 기호를 쓸 필요는 없고, 기본 요소만으로 충분하다.
| 요소 | 표기 | 뜻 |
|---|---|---|
| 이벤트 | 원 | 시작·중간·종료 |
| 활동 | 둥근 사각형 | 수행하는 일 |
| 게이트웨이 | 마름모 | 분기·병합(조건) |
| 수영 레인 | 가로 띠 | 역할·조직·시스템 |
| 흐름 | 화살표 | 순서 |
[AS-IS 정산 흐름 — 텍스트로 표현]
레인: 시스템 | 정산 담당 | 재무
(시작: 매일 06:00)
시스템 → 거래 집계 배치
시스템 → ◇ 집계 오류? ─ 예 → 정산 담당: 엑셀로 수동 보정 → (다시 집계로)
└ 아니오 ↓
정산 담당 → 예외 건(취소·부분 환불) 엑셀로 대사 ← 숨은 수작업
정산 담당 → 정산 명세 확정
재무 → ◇ 금액 5천만 원 초과? ─ 예 → 재무 승인
└ 아니오 → 자동 지급
(종료: 지급 완료)AS-IS를 그리면 개선 지점 이 보인다. 위 흐름에서는 엑셀 수동 보정과 예외 건 대사가 개선 대상이다. TO-BE는 개선된 목표 흐름이다. AS-IS와 TO-BE의 차이가 곧 요구사항의 뼈대가 된다.
draw.io(모듈 22 레슨 10)로 BPMN을 그리고, 게이트웨이마다 조건이 모두 정의되어 있는지 확인한다. 게이트웨이의 조건은 곧 레슨 6의 비즈니스 규칙이다.
결과 확인 — 들은 것을 되돌려 보여 준다
도출한 내용은 반드시 이해관계자에게 확인받는다. 확인 방법은 들은 것을 다른 형태로 보여 주는 것 이다. 인터뷰 내용을 흐름도로 그려 보여 주면 "아, 여기 빠졌어요. 이 경우엔 재무팀이 아니라 리스크팀이 먼저 봐요" 같은 교정이 나온다. 텍스트로 요약만 보내면 대부분 "네, 맞아요"로 끝난다.
실무에서 왜 필요한가
요구사항 단계의 결함은 가장 비싸다. 모듈 44 레슨 4의 진단 예시처럼 운영 결함의 절반이 요구사항에서 만들어지는 조직이 드물지 않다. 도출을 체계적으로 하면 이 결함이 만들어지지 않는다. QA 경력자가 BA 역량을 가지면 요구사항 단계에서 품질을 앞당기는 가장 효과적인 사람이 된다.
채용시장에서의 위치
금융·공공 SI의 "업무 분석가", 대기업 IT 조직의 "현업 요건 분석", 스타트업의 "서비스 기획자" 공고는 도출과 업무 흐름 모델링 경험을 요구한다. BABOK 기반 자격(IIBA의 ECBA·CCBA·CBAP)은 해외와 외국계에서 인정받는다. 면접에서 AS-IS 흐름도 한 장과 거기서 찾은 숨은 수작업 이야기를 할 수 있으면 강하다.