서비스 구조화 방법론 SSF가 비즈니스에 기여하는 과정

서비스 구조화 방법론인 SSF는 특정 서비스에 대한 비즈니스(BM)를 이해하여 단계적으로 구체적 실행 계획으로 전환하는 특성을 지녔습니다. 이로 인해 비즈니스에 대한 작업 이해도를 향상시키고, 데이터 이해도를 높임으로써 고객사 비즈니스에 기여합니다. 오늘은 이에 대한 정리를 해 보겠습니다.

SSF의 특징과 구조화를 통한 비즈니스 기여 방법

앱을 개발하는데 있어 세세한 비즈니스 전략과 모델까지 알 필요는 없습니다. 심지어 고객사가 이를 자세히 알려주지도 않습니다. 그러나 최소한 고객사 비즈니스가 어떻게 구성되어 있고, 작동하는 지에 대한 이해는 필요합니다.

고객사가 앱을 개발하려는 이유와 그 앱이 어떻게 구성, 작동되어야 하는지 파악하기 위해서는 고객사 비즈니스에 대한 이해가 필요합니다. 전문적 수준의 사업 전략, 분석 능력까지는 아니어도 일반적 이해를 할 정도의 비즈니스 이해 능력은 있어야 합니다.

그러나 대부분의 개발 프로젝트에 투입되는 인력은 이에 대한 이해가 없습니다. 심지어 소비자 측면의 이해와 사업적 이해의 차이를 구분하지 못하는 경우도 있습니다.

이로 인해 개발된 앱은 사업적 가치가 없는 전략적으로 활용이 어려운 프로그램이 됩니다. 이런 상황은 고객사에게 상당한 비용 부담으로 작용합니다. 이는 다시 해당 사업의 수익성에 악영향을 끼치게 됩니다.

플랜앤서치의 SSF는 체계적으로 사업에서 이어지는 목적 타당한 개발을 위한 설계를 제공합니다. 이렇게 개발된 앱은 단순히 개발 완료된 앱으로써 가치 이상의 사용자 데이터 자산의 축적과 활용이라는 측면에서 다 많은 미래 가치를 지니게 됩니다.

SSF가 고객사 비즈니스에 기여하는 과정을 설명하는 이미지

목적 타당한 앱 개발을 통해 비즈니스에 기여하는 SSF

많은 IT 개발 프로젝트 현장이 고객사 비즈니스 타당성 보다는 앱을 개발한다는 자체에 더 큰 의미를 둡니다. 그러므로 고객사가 요구하는 기능과 UI가 포함된 작동되는 앱이 납품하는 것을 목표로 개발을 하게 됩니다.

그러나 여기에는 몇 가지 문제점이 있습니다.

• 고객사 비즈니스 전략/전술 수행을 위한 앱 적합성

• 사업 자산으로의 앱의 가치

• 투자 수익률 측면의 앱

이러한 사실은 에러 없이 작동 가능한 앱 이상의 사업적으로 활용 가능한 앱이냐가 고객사에게는 중요함을 의미합니다.

이런 사업적 활용 가능한 앱을 개발 하기 위해서는 선행되어야 하는 것이 있습니다.

1. 고객사 비즈니스에 대한 이해 (상품과 업무 처리 등)

2. 고객사 전략의 이해 (시장 경쟁 구조와 고객사 포지션 등)

3. 사용자 가치와 적절한 제공 가능성에 대한 이해

기본적으로 위의 3유형의 이해가 선행되지 못한다면 개발되는 앱은 고객사 사업을 위한 활용 가능성이 낮게 됩니다.

물론 여기에는 전제가 있습니다. '고객사가 개발사에게 명확한 요구 사항을 정리 해 제공한다면' 문제가 없다는 것입니다.

그러나 작게는 수 십억 원에서 많게는 수백억 원을 주고 개발사에게 개발을 맡기는 것은 개발 요구 사항을 구체적으로 할 만큼 상황이 되지 않는다는 것을 의미합니다. 이 의미가 고객사의 사업 계획, 전략적 이해가 부족함을 말하는 것은 아닙니다. 단지 이를 개발적으로 전환하는 능력에 대한 것에 한정됩니다. 그래서 외주 개발을 맡기기도 하는 것입니다. 아니면 외주 개발을 맡기더라도 고객사 주도적으로 단순 작업 만을 맡길 것입니다.

안타깝게도 형식적인 요구 사항 정리 이상의 고객사 비즈니스 이해를 바탕으로 한 요구 사항 구체화와 이에 이어진 기능/로직 설계 역량을 가진 개발자와 기획자가 현저히 적다는 사실은 개발의 사업 목적 타당성을 낮게 만드는 요인입니다.

플랜앤서치의 SSF는 이런 문제를 최소화하기 위한 단계적 구조화 기획 방법론입니다. 최소한 시기마다 어떤 기획을 해야 하고, 이 기획을 하기 위해서 어떤 사전 설계가 완료되어야 함을 구체적으로 보여줍니다. 또한 이를 구조화하여 과정이 만들어 내는 복잡성을 관리합니다.

앱 개발이 특정 고객사 사업 목적에 타당성을 가지기 위해서는 어떤 과정을 거쳐야 하는가? 서비스 제공 중 발생되는 쓰레기 데이터에 빠져 잘못된 판단을 하지 않기 위해서는 어떻게 앱을 개발해야 하는가를 보여주는 방법론이 SSF(Service Structuring Framework)인 것입니다.

앱 개발 설계 및 구조화를 통해 비즈니스에 기여하는 SSF

아주 원초적인 질문일 수도 있지만 개발 현장에서 많이 나타나는 문제는 '어떤 앱을 개발해야 하는가?'가 있습니다. 경력 많은 PM, PL 뿐 아니라 DA, AA 등 설계자들도 투입된 프로젝트에서도 '어떤 앱을 개발해야 하는가?'에 대한 답을 하지 못해 개발이 공전하고 있는 것을 보게 됩니다. 이는 국내 IT 개발 프로젝트의 전문성이 주로 '어떻게 개발해야 하는가?'에 포커스되어 있기 때문입니다.

이는 기초 설계에 대한 역량 문제일 수도 있지만, 실제적으로는 개발 조직의 체계적 유기성에 문제가 있음을 의미한다 생각합니다.

실제 단기 성과 중심 프로젝트 관리에서는 즉각적인 작동 가능한 코드와 화면을 생산할 수 있게 팀을 꾸림니다. 이는 마치 기초 과학 연구가 없이 바로 제품 생산이 가능한 공학에 투자가 집중되는 것과 같습니다.

또한 맨먼스 중심 프로젝트 비용 산정 구조도 한 몫합니다. 개발자 단가가 상대으로 우위인 상황에서 높은 비용 청구를 위해 초기 분석/설계팀을 개발자로 꾸리게 됩니다. 이 때문에 분석/설계는 코드 분석과 설계 중심으로 이루어지게 됩니다.

그러나 이런 상황이 가져오는 문제는 '어떤 앱을 개발할 것인가?'를 해결할 수 없다는 것입니다. 다행히 고객사가 이를 제공해준다면 문제 없이 빠르게 앱을 개발해 나갈 수 있어 고객사와 개발사 모두 만족스러울 것입니다. 그러나 상당수 IT 개발 프로젝트 현장은 '어떤 앱을 개발할 것인가?'에 대한 문제를 안고 있습니다.

'어떤 앱을 개발할 것인가?'에 대한 작업을 개발 한정하여 보면 BA입니다. 작업자는 비즈니스 아케텍처입니다. 애플리케이션 아키텍처, 데이터 아키텍처와 다른 '비즈니스 아키텍처'라는 용어에서 알 수 있듯이 개발자는 아닙니다.

고객사의 비즈니스 요구를 개발 가능한 설계로 전환하는 작업을 하는 담당자가 BA입니다. 그러므로 비즈니스 이해와 이를 연결하는 개발적 이해를 동시에 가진 융합적 인력을 의미합니다.

보통 이런 사람을 도메인 전문가라 불러야 합니다. 단지 해당 분야 앱 프로젝트에 많이 참여해 본 경헝으로 도메인 전문성을 규정하기에 도메인 전문가를 많이 투입해도 BA가 이루어지지 않는 것입니다.

SSF는 체계적으로 BA 설계를 지원합니다. 제공할 서비스 가치와 목표 사용자를 아우르는 서비스 가설에 바탕한 아키텍처를 제공함으로써 개발 시 BA를 더 원활하게 만듭니다.

지금까지 SSF가 비즈니스에 기여하는 과정에 대하여 설명해 보았습니다. 댓글 또는 메일로 질문을 주시면 더 세부적 사항에 대한 정리 글을 제공 드리도록 하겠습니다.