[#Memo] Back-Office System

백오피스 시스템에 대한 메모

기본적으로, 고객과의 접점이 있는 영역을 의미하는 프론트 오피스 이외 영역의 업무를 의미한다.

1.보통 개발을 다 끝낼 때 쯤에야 만들고 있던 기능을 완벽히 이해하게 된다. 기획서가 여러 장이어도, 내용을 모두 담지 못하기도 하고… 꼭 다 챙겼다 싶어도 테스트 할 때에는 누락된 것들이 생긴다. 따라서, 전사의 업무 프로세스 및 비즈니스 로직(=히스토리)을 이해하고 있어야 한다.

2. ✨구성원들의 생산성에 즉각적인 도움을 줄 수 있다**✨ **기본적으로 소모적이고 반복적인 업무를 자동화하고, 복잡한 업무를 단순화하며, 이해하기 어렵고 파편화 된 운영에 필요한 모-든 데이터들을 다룬다.

개인적인 관점에서는 아래의 두 특징이 두드러진다.

• 릴리즈 후 피드백이 매우 빠르게 온다.

• 앱, 브라우저, DTO 보다는 자바스크립트에 대해 많이 고민하게 된다. (DTO를 고민하지 못하는 건 좀 아쉬운 점)

아무래도, 운영팀 구성원들이 사용하는 페이지다 보니 특정 개발 건이 릴리즈 되고 나면 편의성이나 심미성에 대한 피드백을 바로바로 받을 수 있다. 고객의 반응을 살피는 것과 달리 사용자와 직접 커뮤니케이션을 할 수 있어 덜 답답하다.

또, 아무래도 퍼포먼스에 집중하기 보다는, 복잡한 데이터를 어떻게 보여주기 쉽게 파싱할 지에 대해 고민하다 보니 쓰기 편리한 데이터 구조나, 보기에 더 나은 표현 방법에 대해 고민하게 된다. 여기서 ES6가 굉장히 빛을 발한다.

3. 사용자의 개별요구 조건을 있는 그대로 구현하게 되면 무거워진다.

서비스 운영 기간이 아주 다행히도 길어진다면, 그에 따른 업무 필요 기능도 많아질 수 밖에 없기 때문에 히스토리의 관리가 반드시 필요하다. 빠른 속도로 업무를 위한 자동화가 추가되다보면 시스템이 복잡해지기 때문이다. 현재 다루고 있는 데이터가 어디까지 영향이 미치는지 파악하고 있어야 하고, 더이상 호출될 필요 없는 api나 데이터, 컴포넌트들은 dummy가 되어버리기 전에 걷어내는 게 좋을 것 같다.

4. ✨스터디를 할 수 있는 여유 및 기술적 고민✨

팀 내에 시니어분들이 많이 없다는 것은 부담일 수 있지만, 반대로 열정 많은 주니어들이 폭주 기관차처럼 달려도 어느정도 관리가 가능한 스펙트럼이 나온다. 보통 새로운 기술이 나와도, 실 서비스에 바로 반영하는 것은 팀에 있어 부담이 큰 반면, 백오피스의 경우 어느정도 가능하다는 말이다. 물론 공부와 마이그레이션에 대한 부담은 각자가 지는 거지만…. 또한 당장 나가지 않으면 큰일나는 배포가 잦지 않기 때문에 리뷰가 깐깐해진다. 릴리즈 후에 리팩토링은 필수로 진행하게 되는 것 같다.