'변화의 중개인' 비즈니스 애널리스트를 아시나요?

비즈니스 애널리스트(BA)란 애플리케이션 개발할 때 사용자의 요구를 반영한 개발이 되도록 하는 사람을 가리킨다. 기존 솔루션을 커스터마이징 하든 혹은 아예 처음부터 시작하든 관계 없다. BA는 기업의 IT 부서와 다른 부서 간의 가교 역할을 맡기도 한다.



그래서 비영리 기관 IIBA(International Institute of Business Analysis)는 BA를 ‘변화의 중개인’라고 부른다. 비즈니스 분석은 기업, 정부, 비영리 단체 등 다양한 기관 내부에 변화를 야기하고 그러한 변화를 유지하기 위한 규율 잡힌 접근 방식이다. 따라서 이를 실행하는 BA는 비즈니스 시스템 애널리스트, 시스템 애널리스트, 필요 요건 엔지니어, 프로세스 애널리스트, 엔터프라이즈 애널리스트 등으로 불리기도 한다.

BA의 핵심 직무
벨뷰 대학 교수이자 동 대학 비즈니스 분석 및 매니지먼트 학위 프로그램의 학술 프로그램 디렉터인 밥 그레고리는 "BA의 직무 중 가장 중요한 것은 기술적, 기능적 필요 요건을 파악하고 우선 순위를 정하는 것이다. 필요 요건을 설명하고 이를 통해 IT에 고객이 원하는 것을 설명하고 설득하는 역할을 맡는다. 실질적인 제품 오너는 기업이라고 해도 마치 자신이 제품 오너인 것처럼 일해야 하는 직종이다”라고 말했다.

BA의 또 다른 책무는 비즈니스 리더, 소프트웨어 사용자에게 소프트웨어 도입 이후 가능해지는 비즈니스 프로세스를 설명하고 소프트웨어가 어떻게 효율성을 개선해 가치를 창출할 것인지 이해시키는 것이다. 아이디어 측면을 충분히 강조하면서도 기술적으로 가능한지, 기능적으로 논리적인지를 충실히 설명해야 한다.

시장조사업체 포레스터 리서치의 수석 애널리스트 제프리 하몬드는 “이 시스템이 어떤 기능을 하는가, 어떻게 그러한 기능을 수행하는가, 그리고 어디서 인풋을 얻어야 하는가, 어떻게 하면 앞으로의 행보에 대한 모든 이들의 동의를 얻어낼 수 있을 것인가 등의 질문을 던져야 한다. BA는 필요 요건을 파악하고 우선 순위를 정해 이들에 대한 피드백과 승인을 얻어 내야 한다”라고 말했다.

유능한 BA가 되기 위해서는 커뮤니케이션 스킬을 갖추고 협업도 추진할 수도 있어야 한다. 하몬드는 “부처간 원하는 것이 서로 다를 때는 BA가 이들 간에 합의를 이끌어 내 일관성 있는 결과를 도출하고 모든 이를 한 방향으로 끌고 가야 한다. 그래서 BA에게는 다소 틀에서 벗어난 사고가 필요하다. 다양한 의견을 가진 이들로부터 공통된 합의를 끌어 내려면 기존 방법과 다른 창의적 해법을 생각할 수 있어야 한다"라고 말했다.


계속 변화하는 BA의 역할과 책임
소프트웨어 개발 속도에 대한 기대가 더 짧아지면서 BA의 역할도 변화하고 있다. 최근 기업 IT 부서는 전통적인 폭포수 방식(waterfall methodology)을 버리고 애자일, 데브옵스 등 더 반복적이고 지속적인 방법론을 택하고 있다. 이에 따라 일부 기업은 BA의 직무를 확대해 사용자 요구를 수집하고 현업과 IT의 가교 역할을 하며 새로운 소프트웨어 애플리케이션을 도입하는 것까지 BA의 직무 범위에 포함시키고 있다.

이렇게 되면 BA의 역량을 평가함에 있어 단순히 이들이 찾아낸 필요 요건의 수만 보는 것이 아니라, 이러한 필요 요건이 실제 사용자의 요구를 얼마나 잘 반영하는지, 새로운 소프트웨어가 비즈니스 요구를 잘 반영하는지, 또 얼마나 잘 활용되고 있는지, 사용자 만족도는 어떤지 등이 모두 고려된다.

하몬드는 “이는 기존 제품 매니저에 대한 평가와 비슷하다. BA가 많은 기업에서 제품 매니저라는 타이틀을 갖는 것도 이 때문이다. 특히 BA 직무가 IT 부서가 아닌 디지털 비즈니스 부서에 있다면 이런 경향이 더 강하다. 어쩌면 BA를 제품 매니저로 바꾸는 것도 더 좋을 수도 있다. 제품 매니저 역시 궁극적으로는 소프트웨어의 기능성을 보장하고 고객의 수요를 맞추는 역할을 하므로 기능적 의사 결정 측면에서 BA보다 더 강력한 책임을 진다"라고 말했다.

단, 이를 결정하는 데 있어 중요한 것은 타이틀보다 그 사람의 특성이다. 그는 "원래 BA이던 사람을 데려와 제품 매니저로 임명한다고 해서 하루 아침에 제품 매니저가 되는 것은 아니다. 제품 매니저 책무를 수행할 의사가 있는 사람에게 맡겨야 한다”라고 말했다.

새로운 툴과 BA 투입의 타이밍
최근의 BA는 소비자 요구를 파악할 때 다양한 툴을 사용한다. 실시간 사용자 데이터와 애널리틱스 프로그램을 활용해 트렌드를 파악하고, 애플리케이션 관련 잠재된 문제를 찾아낸다. 에모는 “IT와 디지털, 그리고 소프트웨어 개발과 비즈니스의 구분이 모호해지고 있다. BA나 제품 매니저에 대한 관심이 커지는 것도 이 때문이다"라고 말했다. 실제로 일부 기업은 BA와 협업하거나 BA 팀을 두고 일할 수 있는 제품 매니저 직책을 만들기도 했다.

소프트웨어 개발 방식이 더 빠르고 반복적으로 바뀌는 것도 BA의 업무에 변화를 주고 있다. 주로 특정 개발 프로젝트에서 BA가 개입해야 하는 타이밍에 차이가 있다. 전통적 폭포수 환경에서는 BA는 프로젝트의 초기 단계에 참여한다. 사용자 필요 요건을 수집, 분석, 서열화해 이를 개발자에게 넘기고 이후 다른 소프트웨어 개발 프로젝트에 배치되는 식이다.

반면 애자일 개발 프로젝트에 참여하는 BA는 프로젝트 과정 전반에 걸쳐 프로젝트에 남게 되며, 심지어 수 차례 릴리즈가 나올 동안 팀에 남아 있기도 한다. 기업은 프로젝트 규모와 복잡도에 따라 BA를 한 번에 여러 프로젝트에 투입하거나, 하나의 프로젝트에만 투입하기도 한다. 여러 BA를 대규모 소프트웨어 개발 프로젝트에 함께 투입하는 경우도 있다.

반면 일부 IT 부서는 인 하우스 애플리케이션 개발 프로젝트에서 비즈니스 애널리스트의 참여를 아예 배제하기도 한다. 에모는 "특히 모바일 마케팅 앱이나 일시적인 세일즈 프로모션 앱 같은 애플리케이션 개발 작업에는 BA를 투입하지 않을 가능성이 크다. 이런 프로젝트는 데브옵스 개발 방식을 따르거나 아주 가볍게 운용되기 때문이다"라고 말했다.

이어 “이런 프로젝트는 지속적인 딜리버리를 유지하는 가운데 아주 빠르게 진행되며, 긴 필요 요건 문서보다 데이터에 의해 주도되는 경우가 많다. 오늘날 특히 디지털 전자상거래와 같은 디지털 위주의 애플리케이션에서 보이는 경향은 전통적 의미에서 비즈니스 애널리스트가 참여할 여지가 거의 없다"라고 덧붙였다.

반면 백 오피스 애플리케이션과 핵심 비즈니스 소프트웨어 제품 등 필요 요건을 식별하고 문서화하는 것이 중요한 개발 작업의 경우 BA가 거의 예외 없이 투입된다. 에모는 “이들 애플리케이션의 상당수가 엄격한 규제를 받고 있으므로, BA가 투입돼 필요 요건을 문서화하고 컴플라이언스를 확인해 줄 필요가 있다”라고 말했다. ciokr@idg.co.kr