backoffice

백오피스 backoffice 구축 시나리오 3가지

IT 기업 및 스타트업이 백오피스 backoffice를 만드는 방법은 다양합니다. 기업마다 팀마다 그 니즈와 상황이 다양하기 때문인데요. 이렇게 백오피스를 만드는데 있어서 발생할 수 있는 대표적인 시나리오 3가지에 대해 생각해보겠습니다.

1) 기획 - 디자인 - 개발

안정적인 조직이나 팀 문화에 이상적인 시나리오입니다. 조직 스타일에 따라 기획 - 개발 또는 디자인 - 개발로 이루어질 수도 있습니다.

해당 방식의 장점은 무엇일까요? 우선 확실한 하나의 프로젝트로 인식될 수 있습니다. 백오피스 툴을 만들고 배포하는데 있어서 놓치는 이슈도 줄어들고 버그도 적고 완성도도 높을 가능성이 있습니다.

여러명이 참여하는 만큼 시간과 리소스가 많이 소요되는데요. 기획 - 디자인 - 개발 영역의 담당자가 동시에 해당 프로젝트에만 집중할 수도 있겠지만, 리소스가 부족한 스타트업의 경우 컨베이어 벨트처럼 진행될 수도 있습니다. 대부분 '기획' 담당자가 제품이 의도대로 만들어졌는지 불가능한 이슈는 없는지 등을 내부 고객에게 전달될 때까지 확인을 하게 됩니다.

Good scenario(이하 Good): 모든 것이 계획대로 됩니다. 버그는 거의 없고 내부 사용자도 만족합니다. 비즈니스의 일정과 요구사항에 맞게 완성되었습니다.

Bad scenario(이하 Bad): 생각보다 기획에 시간이 많이 들어갑니다. 요구사항도 계속해서 늘어납니다. 겨우 기획을 마무리했지만 지금 개발하기가 어려운 상황입니다. 일정은 밀리고 백오피스 툴은 준비되지 않습니다. 서비스 운영팀이 개발 쪽에 어쩔 수 없이 계속 수기 요청을 합니다. 개발자는 백오피스를 구축할 시간이 더 부족해지는 악순환에 빠집니다.

2) 개발

개발자가 처음부터 끝까지 만들 수도 있습니다. 백오피스 툴은 자사의 고객들을 위한 서비스나 앱에 비해 UI, 디자인 또는 UX, 사용자 경험의 중요성이 덜 강조되는 편이기 때문에 기획자나 디자이너가 참여하지 않는 경우도 있는데요. 당연히 사내 도구의 퀄리티가 높아질수록 생산성이 높아지지만 완벽하게 만들기보다는 빠르게 실행해야 하는 상황에서는 기획, 디자인 등의 작업을 거치는게 병목이 될 수도 있습니다.

백오피스 툴은 사용자가 적고 일정 수준까지는 기술적인 난이도가 상대적으로 낮기 때문에 개발자 입장에서 커리어나 흥미도 측면에서 아쉬움이 있을 수 있습니다. 그럼에도 일반적인 앱, 서비스와 마찬가지로 필수적으로 해야하는 작업이 있기 때문에 처음부터 모든걸 만들기에는 부담스러울 수 있는데요. 개발자는 미리 만들어진 백오피스, 어드민 프레임워크를 가져다 활용하게 됩니다. 개발 언어나 프레임워크의 특성에 따라 중장기적인 결과가 달라질 수 있습니다.

Good: 백오피스를 구축해본 개발자가 담당자가 되었습니다. 예전에 이용했던 프레임워크의 베이스가 마침 사내 주개발 언어이고, 프레임워크도 큰 틀은 그대로이지만 꾸준히 발전해왔습니다. 크게 에너지를 들이지 않고 적정 수준으로 툴을 배포하게 됩니다.

Bad: 담당자가 백오피스를 처음 개발해봅니다. 별로 내키지 않던 프로젝트이지만 가능한 사람이 이외에 없습니다. 새로 나온 프레임워크가 흥미로워 보입니다. 일단 최소한의 노력으로 배포하게 됩니다. 내부 사용자가 원하는 기능들이 아직 없습니다. 담당 개발자는 또 다른 프로젝트로 급히 합류하고 해당 툴은 추가 개선이 되지 않고 비효율의 시간이 흐릅니다. 다른 개발자가 살펴보지만 어떻게 만들어야할지 모릅니다. 새 개발자에게 익숙한 다른 프레임워크를 선택하여 새로 만들게 됩니다.

3) 외주

외주는 크게 2가지 방향이 있습니다. 데이터베이스 등 기반 레벨부터 요청을 하거나 DB 데이터와 API 등은 내부에서 구축하고 UI 개발만 맡길 수 있습니다.

내부 프로젝트도 마찬가지지만 외주사의 역량이나 관계에 따라 완성도와 확장성이 갈리게 됩니다. 완성도가 낮은 경우 버그가 많거나 사용성이 너무 좋지 않아 내부 사용자의 불만이 커지고, 외주사에 다시 맡기거나 처음부터 프로젝트를 다시 해야할 수도 있습니다. 내부 IT, 개발 조직이 직접 유지보수하거나 새로운 기능을 추가할 수 있는지도 관건입니다.

Good: 외주 개발사와 소통도 잘 되고, 업무 범위도 명확합니다. 결과물에 대해 내부 사용자들도 만족스럽습니다. 내부 개발자들이 코드를 살펴볼 수 있고, 유지보수 및 개선이 가능합니다. 비용도 저렴한 것은 아니지만 합리적입니다.

Bad: 요구사항 범위에 대한 커뮤니케이션 오류가 자꾸 발생합니다. 내부 사용자들은 적당히 살펴보고 괜찮다고 생각합니다. 하지만 나중에 알고보니 치명적인 이슈가 발견됩니다. 하지만 내부 개발자가 수정하는 것이 불가능합니다. 해당 외주 개발자에게 수정 요청을 하려 하지만 추가 비용이 너무 크게 책정됩니다.