비즈니스 분석가 면접 가이드

답변 구조 — 목적 → 이해관계자 → 의사결정 → 데이터 → 요구사항 → 검증

대시보드가 지원할 의사결정, 사용자, 사용 빈도, 현재 문제를 확인합니다. 경영진, 운영 사용자, 재무, 데이터 엔지니어링, 규제, 원천 시스템 책임자를 파악합니다. 각 지표의 정의, 책임자, 정보원, 계산 방식, 필터, 세분성, 갱신 빈도, 한계를 기록합니다. 권한, 내보내기, 상세 보기, 알림, 이력 요구사항도 확인합니다. 와이어프레임으로 구성을 검증하고 인수 조건과 UAT 시나리오로 출시 전에 해결책을 확인합니다.

답변 구조 — 해결책보다 문제를 먼저 확인

현재 프로세스의 어느 부분이 느리고, 오류가 많고, 불투명하거나 규제상 부족한지 확인합니다. 누가 요청하고, 누가 승인하며, 이후 무엇이 일어나는지 파악합니다. 입력 항목, 검증, 라우팅 규칙, 승인 단계, 에스컬레이션, 거절, 재제출, 알림, 보고, 감사 이력, 예외를 문서화합니다. 처리량, SLA, 역할, 규제, 연동이 비기능 요구사항을 결정합니다. “자동 시스템”은 해결책이며 실제 요구사항은 사업 성과와 의사결정 규칙입니다.

답변 구조 — 변경 확인 → 영향 평가 → 우선순위 결정 → 공유

먼저 이유와 긴급성을 확인합니다. 새로운 요구, 누락된 요구사항, 규제, 선호, 기술 제약, 테스트 결과 중 무엇인지 파악합니다. 제품, 개발, QA, 사업 부서와 범위, 일정, 비용, 의존성, 데이터, 연동, 테스트, 교육, 위험에 미치는 영향을 평가합니다. 변경은 이번에 포함하거나, 연기하거나, 다른 항목과 교환하거나, 거절합니다. 결정과 이유를 기록하고 숨은 범위 확대를 막기 위해 제공 범위와 제외 범위를 명시합니다.

답변 구조 — 현재 상태 → 병목 → 근본 원인 → 미래 상태 → 지표

등록부터 완전한 사용 시작까지 단계, 책임자, 시스템, 인계, 의존성, 승인, 문서, 예외를 시각화하고 총시간뿐 아니라 각 단계의 시간을 측정합니다. 고객 유형, 제품, 지역, 위험, 채널별로 나눕니다. 수기 입력, 누락 문서, 규제 검토 적체, 중복 승인, 연동 부족 같은 원인을 찾고 영향과 실행 가능성으로 평가합니다. 문서 사전 검증, 자동 알림, 병렬 작업, 셀프서비스, 위험 기반 라우팅, 승인 축소를 검토합니다. 중앙값 및 90백분위 시간, 완료율, 재작업, 만족도, 규제 예외를 측정하고 제한된 시험부터 시작합니다.

답변 구조 — 범위 → 참여자 → 흐름 → 예외 → 통제

시작, 종료, 관련 팀과 시스템, 사업 목표를 정의합니다. 현재 상태에는 참여자, 단계, 입력과 출력, 결정, 인계, 대기 시간, 문제, 예외를 기록합니다. 스윔레인 다이어그램으로 책임을 명확히 하고 실제 담당자와 검증합니다. 미래 상태에는 변경하거나 제거할 단계, 자동화, 새로운 통제, 역할 변경, 예외 처리를 보여 줍니다. 가정, 미해결 사항, 의존성, 성공 지표도 포함하고 경영진용 요약본과 운영용 상세본을 구분합니다.

답변 구조 — 조인 → 필터링 → 월·카테고리별 집계 → 매출 합계

먼저 데이터의 세분성을 확인합니다. 매출이 주문 단위인지 주문 항목 단위인지 확인하고, 카테고리가 항목에 속한다면 그 세분성에서 집계해야 조인으로 금액이 부풀지 않습니다. 주문 항목을 product_id로 제품에, 날짜와 상태를 위해 주문에 조인하고 완료 주문만 필터링한 뒤 월과 카테고리로 그룹화해 항목 매출을 합산합니다. 할인과 환불이 있다면 총매출인지 순매출인지 확인합니다. 월별 합계를 재무 데이터와 대조하고 카테고리 누락, 취소 및 테스트 주문 제외도 확인합니다.

답변 구조 — 목표 → 서비스 품질 → 효율 → 고객 성과 → 가드레일

빠른 해결, 만족도 향상, 비용 관리, 에스컬레이션 축소, 성장 지원 중 목표가 무엇인지 확인합니다. 지표는 고객 경험과 효율의 균형을 맞춰야 합니다. 최초 응답 및 해결 시간, SLA 준수, 적체량, 재개 및 에스컬레이션, 최초 해결률, CSAT, 고객당 문의 수, 건당 비용, 유형별 문의량을 사용합니다. 우선순위, 채널, 고객 유형, 제품, 지역별로 나눕니다. 처리 시간만 최적화해 품질을 해치지 않도록 속도, 품질, 업무량, 원인을 함께 보여 줍니다.

답변 구조 — 검증 → 분해 → 세분화 → 진단 → 제안

갱신 시각, 원천 시스템, 필터, 기간, 환불, 통화, 정의 변경을 확인합니다. 다음으로 매출을 트래픽과 리드, 전환율, 평균 단가, 가격, 수량, 제품 구성, 지역, 채널, 신규 및 기존 고객으로 분해합니다. 어떤 채널, 제품, 시장, 고객층이 하락을 만들었는지 찾고 계절성, 광고비, 경쟁, 재고 부족, 가격, 파이프라인 품질, 기술 오류, 보고 오류를 조사합니다. 주요 원인에 직접 대응하고 불확실성과 필요한 다음 데이터를 밝힙니다. 모바일 전환이 낮다면 퍼널과 성능을, 트래픽이 낮다면 채널과 캠페인을 조사합니다.

답변 구조 — 사용자 → 목표 → 이점 → 검증 가능한 조건

“[사용자]로서 [이점]을 위해 [기능]을 원한다”는 형식으로 누가 무엇을 왜 필요로 하는지 보여 줍니다. 이점이 명확하면 트레이드오프가 생겨도 팀이 합리적으로 판단할 수 있습니다. 인수 조건은 완료 상태를 구체적이고 검증 가능하게 정의하며 주요 흐름, 입력 검증, 권한, 오류, 경계 조건, 데이터 규칙, 필요한 비기능 요구사항을 포함합니다. 예를 들어 지원 관리자가 우선순위와 SLA 상태로 티켓을 필터링한다면 사용 가능한 필터, 기본 상태, 조합, 빈 결과, 권한, 내보내기, 응답 시간을 정의합니다. 개발 전에 사업, 개발, QA, 디자인과 검증합니다.

답변 구조 — 사업상 이유, 기능 내용, 제공 가능한 단위

BRD는 문제, 목표, 범위, 이해관계자, 상위 요구사항, 가정, 제약, 성공을 기술하며 왜 필요한지와 어떤 사업 성과를 목표로 하는지 보여 줍니다. FRD는 흐름, 규칙, 필드, 권한, 연동, 보고, 예외처럼 시스템이 무엇을 해야 하는지 기술합니다. 사용자 스토리는 애자일 팀을 위한 작고 제공 및 검증 가능한 단위입니다. 필요한 문서 수준은 제공 방식과 위험에 따라 다르며, 규제 대상 은행 프로세스는 작은 내부 화면 변경보다 공식적인 근거가 더 필요합니다.

답변 구조 — 범위 → 사용자 → 시나리오 → 데이터 → 결함 → 승인

UAT가 다룰 흐름, 역할, 시스템, 연동, 보고, 사업 규칙을 정의합니다. UAT는 사업상 사용 준비가 됐는지 확인하는 과정이지 QA의 전체 테스트를 반복하는 과정이 아닙니다. 청구 담당자, 관리자, 규제, 운영, 보고 담당자가 참여하며 표준, 서류 누락, 고액, 거절, 에스컬레이션, 중복, 예외 등 실제 사례 기반 시나리오를 사용합니다. 경계, 권한, 상태 전환, 알림, 감사 이력, 보고, 하위 시스템을 포괄하는 테스트 데이터를 준비합니다. 결함은 심각도, 책임자, 상태, 사업 영향과 함께 기록하고 버그, 교육 부족, 새 요청을 구분합니다. 핵심 시나리오 통과, 잔여 위험 수용, 운영 준비를 기준으로 승인합니다.

답변 구조 — 공통 이해 → 제약 → 선택지 → 문서화

사업 문제와 원하는 결과를 명확히 하고 개발팀과 기술 제약, 의존성, 연동, 데이터 모델, 성능, 보안을 확인합니다. 복잡한 요구사항을 사업 규칙, 사용자 흐름, 데이터, API 동작, 권한, 오류, 보고로 나눕니다. 다이어그램, 예시, 테스트 데이터로 모호함을 줄이고 더 작은 MVP나 단계적 제공 같은 선택지와 트레이드오프를 개발팀에서 얻습니다. 혼자 기술 설계를 결정하지 않고 사업 목표를 달성하며 선택의 대가가 보이는 상태를 만듭니다. 합의, 미해결 사항, 가정, 인수 조건을 기록합니다.

답변 구조 — 측정 → 세분화 → 진단 → 개선

목표에 맞게 사용을 정의합니다. 로그인, 기능 실행, 흐름 완료, 반복 사용, 사업 성과 중 무엇인지 정합니다. 역할, 팀, 지역, 교육 여부, 출시 후 경과 시간별로 나눕니다. 인지 부족, 불명확한 가치, 사용성 문제, 잘못된 권한, 기존 절차 유지, 요구사항 부적합이 원인일 수 있습니다. 사용 퍼널, 문의, 인터뷰, 업무 관찰로 진단합니다. 교육, 안내, UX 개선, 기존 도구 종료, 권한 수정, 요구사항 재검토를 수행하고 클릭이 아니라 시간 절감, 오류 감소, SLA 개선 같은 목표 성과로 측정합니다.

답변 구조 — 사업 가치 → 긴급성 → 위험 → 공수 → 의존성

이번 기간의 사업 목표가 매출, 규제, 고객 경험, 비용, 위험 중 무엇인지 확인합니다. 각 요구사항을 가치, 긴급성, 규제 및 운영 위험, 사용자 영향, 공수, 의존성, 가정의 확신도로 평가합니다. 점수는 투명성을 높이지만 판단을 대신하지는 않습니다. 규제나 사업 연속성 요구사항은 필수일 수 있습니다. 필수, 고가치, 빠른 성과, 선행 조건, 후속 항목으로 분류하고 채택 또는 연기 이유를 설명합니다. 20개 요청이 실제로는 5개 근본 문제에서 나온 것인지도 확인해 개별 기능보다 원인 해결을 우선합니다.

답변 구조 — 현재 비용 → 오류 위험 → 자동화 비용 → 이점 → 제안

노동 시간, 오류, 지연, 감사 위험, 수행하지 못하는 고부가가치 업무를 현재 비용으로 평가합니다. 재무나 규제 업무에서는 시간보다 위험 감소가 더 중요할 수 있습니다. 구축 또는 구매, 유지보수, 예외 처리, 통제, 테스트, 교육, 연동 비용과 비교하고 처리량 증가에 따른 미래 비용도 봅니다. 프로세스가 안정적이고 규칙 기반이며 빈번하고 오류가 많고 정보원이 명확하다면 자동화를 권합니다. 규칙 변경이나 사람의 판단이 많다면 표준화와 부분 자동화부터 시작합니다.

답변 구조 — 생산성 정의 → 기준선 → 사용 → 성과 → 가드레일

생산성이 유망 활동 증가, 영업 주기 단축, 전환 개선, 파이프라인 증가, 예측 정확도 개선, 인당 매출 중 무엇인지 정의합니다. 도입 전 기준선과 가능하다면 비교군 또는 단계적 출시를 마련합니다. 올바른 사용과 성과를 함께 측정합니다. 관리 시간, 후속 연락, 응답 시간, 단계 이동, 전환, 영업 주기, 데이터 품질, 예측 정확도, 인당 매출을 봅니다. 만족도, 고객 경험, 잘못된 인센티브를 가드레일로 둡니다. 팀, 지역, 경력, 시장별로 나눠 확대, 교육, 단순화, 요구사항 재검토를 결정합니다.

답변 구조 — 목표 확인 → 트레이드오프 시각화 → 근거 활용 → 결정

먼저 근본 목표를 확인합니다. 영업의 유연성과 규제팀의 통제처럼 서로 다른 인센티브에서 갈등이 생깁니다. 영향, 대상 사용자, 위험을 시각화하고 설정, 권한, 단계적 제공, 업무 변경으로 두 목표를 모두 충족할 수 있는지 검토합니다. 매출, 위험, 처리량, 오류, 비용, 고객 영향 데이터를 판단에 사용합니다. 상위 권한이 필요하다면 해결되지 않은 갈등만 전달하지 않고 선택지와 권고안을 가지고 결정을 요청합니다. 결정, 이유, 연기된 요구사항을 기록합니다.

답변 구조 — 사업 영향, 선택지, 트레이드오프

비용 증가, 일정 연장, 신뢰성 저하, 보안 위험, 수동 처리, 출시 지연 같은 사업 결과로 바꿔 설명합니다. 기술 용어만으로는 도움이 되지 않습니다. 구체적인 선택지를 비교합니다. A는 8주 만에 완전 제공, B는 3주 만에 핵심만 제공하고 예외는 수동 처리, C는 기존 제품을 사용하지만 보고에 제약이 있다는 식입니다. 각 선택의 대가를 명확히 하고 간단한 그림, 예시, 테스트 데이터로 이해를 돕습니다. 목적은 이해관계자를 기술자로 만드는 것이 아니라 충분한 정보로 결정하게 하는 것입니다.

답변 구조 — 문제 → 분석 → 해결책 → 출시 → 결과

긴 처리 시간, 높은 오류율, 과도한 수작업, 불투명성, 민원, 규제 위험처럼 명확한 전후 비교가 있는 사례를 고릅니다. 프로세스 맵, 사용자 인터뷰, 병목 측정, 데이터 검토, 근본 원인 분석을 설명합니다. 해결책과 요구사항, 이해관계자 합의, 업무 및 시스템 변경, UAT, 교육, 출시에 대한 자신의 기여를 보여 줍니다. 시간 단축, 오류 감소, SLA 개선, 비용 절감, 만족도 향상 같은 결과와 배운 점으로 마무리합니다.

답변 구조 — 모호함 → 가정 → 검증 → 결정

모든 정보를 기다리면 진행에 지장이 있었던 이유, 부족했던 데이터, 이용할 수 있었던 정보를 보여 줍니다. 가정을 기록하고 가치가 큰 정보 공백부터 채우며, 이해관계자에게 확인하고, 시나리오나 대리 데이터를 사용하고, 제공을 단계화한 방법을 설명합니다. 무모하지도 멈춰 있지도 않은 판단을 보여 줍니다. 불확실성을 드러내 근거 있는 결정을 내리고 이후 정보가 늘었을 때 조정한 내용과 결과를 설명합니다.

답변 구조 — 배경 → 세부 사항 → 위험 → 행동 → 결과

세부 사항을 주의 깊게 살펴 재작업, 규제 위험, 데이터 오류, 고객 피해, 출시 장애를 막은 사례를 사용합니다. 배경과 중요성, 요구사항 검토, 경계 테스트, 데이터 대조, 예외 분석, 사용자 검증처럼 체계적으로 발견한 방법을 보여 줍니다. 인수 조건 추가, 승인 중단, 이해관계자 재조율, 보고 수정, 통제 도입 같은 행동과 구체적인 결과를 설명합니다. 완벽주의가 아니라 사업 성과를 지킨 이야기여야 합니다.