요청을 받는 사람과 문제를 다시 쓰는 사람: BRM이 일하는 방식

조직에서 "이런 걸 만들어 달라"는 요청은 끊이지 않는다.

대시보드를 만들어 달라, 보고서를 자동화해 달라, 알림 기능을 넣어 달라. 이 요청들을 빠르게 접수하고 정확하게 전달하는 사람은 유능해 보인다. 그러나 BRM(Business Relationship Manager)이 하는 일은 그 지점에서 시작되는 것이 아니라, 오히려 그 지점을 의심하는 데서 시작된다.

BRM 후보 과정에서 학습한 내용을 한 문장으로 요약하면 이렇다.

좋은 분석가는 요청을 그대로 전달하지 않고, 그 요청 뒤의 필요와 가치, 그리고 다음 행동을 분명하게 만든다.

 

이 글은 그 한 문장이 실제 업무에서 어떻게 작동하는지를 단계별로 풀어낸 기록이다.

 

1. 문제는 '요청'의 형태로 도착하지 않는다
가장 흔한 실수는 현업의 요청을 곧바로 문제라고 부르는 것이다. "회의실 예약 앱을 만들어 달라"는 말은 문제가 아니라 해결책의 형태다. "예약이 불편하다"는 말 역시 문제가 아니라 증상이다. 진짜 문제는 그 뒤에 있다. 반복되는 예약 충돌로 참석자 조율 시간이 늘고, 중요한 회의의 시작이 지연된다.

이 문장이 좋은 이유는 두 가지를 담고 있기 때문이다. 하나는 맥락(반복 충돌)이고, 다른 하나는 영향(조율 시간 증가, 회의 지연)이다. IIBA의 핵심개념 모형은 '필요(Need)'를 해결책이 아니라 다뤄야 할 문제나 기회로 정의한다. 그러나 필요만 적어서는 부족하다. 어떤 맥락에서, 어떤 이해관계자에게, 어떤 가치가 생기는지 연결되어야 비로소 "기능 요청이 아니라 업무 문제로 다시 쓴 문장"이 된다.

여기서 한 가지를 의도적으로 보류한다는 점이 중요하다. 문제를 정의하는 단계에서는 원인과 해결책을 아직 확정하지 않는다. 왜 지금 필요한지, 어떤 가치와 닿아 있는지만 적는다. 원인으로 너무 빨리 점프하는 순간, 분석은 가설을 검증하는 일이 아니라 결론을 정당화하는 일로 변질되기 때문이다.

 

2. 들은 것과 확인된 것은 다르다
문제를 다시 썼다면, 이제 그것을 뒷받침할 사실이 필요하다. 요구 도출은 "인터뷰를 했다"는 사실만으로 끝나지 않는다. IREB는 요구의 출처를 이해관계자 · 문서 · 시스템 세 가지로 구분한다. 담당자에게 묻는 것은 이해관계자 출처이고, 업무 시스템과 처리 로그가 실제로 어떤 데이터를 갖고 어떻게 도는지 확인하는 것은 시스템 출처다. 좋은 도출은 이 세 출처를 교차시킨다. 상담원의 말, 응대 기준서, 티켓 처리 로그를 함께 봐야 한다.

그리고 가장 본질적인 규율이 여기 있다. 양이 아니라 구분이다. 상담원이 "월요일마다 문의가 폭증한다"고 말했더라도, 티켓 로그로 확인하기 전까지 그것은 사실이 아니다. 엄밀히 말하면 사실인 것은 단 하나, "상담원이 그렇게 말했다"는 발언 자체다. "실제로 폭증한다"는 것은 추정이고, "원인은 담당자 부족"이라는 말은 결론이 아니라 원인 후보일 뿐이다.

미확인 항목을 다루는 방식이 분석가의 수준을 가른다. 미확인 항목은 빼는 것이 아니라 '확인 대상'으로 남긴다. 모름을 감추면 다음 분석이 그 위에서 무너지고, 모름을 남기면 다음 분석이 안전해진다. 모름은 결함이 아니라 다음 행동의 좌표다.

 

3. 불편을 길게 설명하는 능력 vs 현재를 구조화하는 능력
현재상태 분석에서 요구되는 것은 불편을 길게 묘사하는 능력이 아니라, 업무와 시스템을 구조화하는 능력이다. 예컨대 고객 환불 처리는 여섯 개의 요소로 분해된다. 흐름(접수→승인→환불), 시스템 연동(CRM·주문), 데이터(문의 유형·처리 상태), 정책과 제약(승인 기준), 예외(부분 환불), 병목(승인 대기). 모르는 칸은 비워두지 않고 "모름"으로 명시한다.

이 구조 위에서 핵심 질문이 던져진다. "그래서 새로 만들 일인가, 아니면 기준과 책임을 먼저 정리할 일인가?", "엑셀 때문에 느리니 시스템을 만들자"는 방향이 완전히 틀린 것은 아니지만 분석으로는 약하다. 느림은 증상이고, 실제 원인 후보는 승인 기준이 문서와 메일에 흩어져 있거나, 처리 상태 데이터가 어긋나거나, 책임 주체가 불명확한 데 있을 수 있다.

그래서 '간극(Gap)'의 정의가 중요해진다. 간극은 해결책의 이름이 아니라, 현재상태와 목표상태 사이의 차이다. "새 환불 시스템 도입"은 간극이 아니다. "처리 흐름과 책임 기준이 서로 연결되어 있지 않다"가 간극이다. 목표상태 역시 시스템의 이름이 아니라 *접수·승인·처리·상태 업데이트가 하나의 흐름으로 이어지는 업무 상태*로 기술된다. 분석가가 해결책의 언어가 아니라 차이의 언어로 말할 수 있을 때, 비로소 해결책의 선택지가 열린다.

 

4. 기술 사실을 사업 언어로 번역한다
여기까지가 비즈니스 분석(BA)의 영역이라면, BRM의 영역은 이 분석을 조직의 의사결정으로 옮기는 일이다.

도메인·기술 이해는 기술을 많이 아는 능력이 아니라, 기술 사실을 현업이 선택할 수 있는 사업 언어로 바꾸는 능력이다. 주문 시스템에 이미 상태 알림 기능이 있다면, "개발이 가능하다"가 아니라 "새 시스템 없이도 고객 대기 시간을 줄일 수 있다"고 번역되어야 한다. 반대로 데이터가 여러 시스템에 흩어져 있다면 "연동이 어렵다"에서 멈추지 않고 비용·기간·운영 책임·오류 리스크를 함께 말해야 한다. ITIL 4의 네 가지 차원(조직, 정보와 기술, 파트너, 가치 흐름)은 이때 "무엇을 함께 보아야 하는가"를 점검하는 체크리스트로 쓰인다.

그리고 아무리 좋은 개선안이라도 회사가 지금 중요하게 보는 목표와 따로 놀면 단발성 개선에 그친다. 전략 정렬은 분석한 문제를 응답 시간, 반복 문의 감소, 운영비 절감 같은 측정 가능한 목표에 연결하는 일이다. 회사의 방향이 문서로 명확하지 않을 때조차 그냥 넘기지 않는다. "어떤 기준으로 우선순위를 정할 것인가"라는 질문을 남긴다. 방향의 공백도 관리해야 할 이슈이기 때문이다.

 

5. 관계가 움직였는가 — BRM의 진짜 영역
이 모든 분석이 작동하려면 한 가지 전제가 필요하다. 상대가 자료를 내주고 함께 풀겠다고 말할 만큼의 신뢰다. 파트너십은 "좋은 관계를 만들었다"는 말로 증명되지 않는다. 관계가 실제로 움직였는가로 증명된다. 처음에 "우리 업무를 모른다"며 경계하던 고객센터가, 처리 로그를 공유하고 승인자를 소개하며 "같이 기준을 정해보자"고 말하기 시작했다면 그때 관계가 움직인 것이다. 요청 처리자와 전략 파트너의 차이는 바로 이 지점에서 드러난다.

관계가 열리면 BRM은 수요를 형성한다. BRM Institute는 BRM을 사업 기능과 사업 파트너 사이의 전략적 연결자로 정의하며, 그 역할을 수요를 자극하고(stimulate), 드러내고(surface), 형성하는(shape) 일로 설명한다. "대시보드를 만들어 달라"는 요청 뒤에는 의사결정에 필요한 상태가 늦게 보인다는 문제가, "알림을 넣어 달라"는 요청 뒤에는 책임 기준이 흐리다는 문제가 숨어 있다. 수요 형성은 이 표면 요청을 업무 목표가 보이는 문장으로 다시 쓰는 일이다.

그다음에야 가치 동인을 붙인다. "대시보드를 만든다"는 해결안이지 가치가 아니다. 가치는 일이 빨라진다, 실수가 줄어든다, 고객 불편이 줄어든다 처럼 변화의 방향으로 적는다. 그리고 거기에 추적 가능한 지표를 잇는다. 평균 처리 시간, 재작업 건수, 반복 문의율. 지표가 처음부터 확정값일 필요는 없다. 중요한 것은 "좋아진다"는 막연한 말을 측정 가능한 변화로 바꾸는 것이다.

마지막은 조율이다. 여러 부서가 "좋다"고 말해도 누가 언제 무엇을 할지 정하지 않으면 일은 멈춘다. 조율은 합의에서 끝나지 않고 책임자, 다음 행동, 일정, 확인 기준까지 남길 때 비로소 실행이 된다.

 

마치며 - 결국 하나의 습관
열여섯 장에 걸친 개념을 다 익히고 나서 남은 것은 의외로 단순한 습관 하나였다.

모든 판단에서 사실과 추정과 다음 확인을 분리하고, 어떤 권고를 하든 남는 리스크와 다음 검증 행동을 함께 적는다.

문제정의에서 조율까지, 모든 단계가 이 습관의 변주였다. 요청을 필요로 다시 쓰는 것도, 발언을 사실과 추정으로 가르는 것도, 모름을 확인 대상으로 남기는 것도, 가치를 지표로 옮기는 것도 결국 불확실한 것을 불확실한 채로 정직하게 다루면서, 그럼에도 다음 행동을 분명히 만드는 일이다.

요청을 받는 사람은 일을 처리하고, 문제를 다시 쓰는 사람은 방향을 만든다. BRM은 후자가 되기로 선택한 사람의 이름이다.