비즈니스 로직과 커맨드 통신에 따른 동작 시나리오에 관하여: 기획 그렇게 하면 안됩니다!

보통 서비스기획이라고 하면, 화면을 그리고 플로우를 만든다.

서비스기획을 처음 시작할 때 상위 기획 추상화부터 차근차근 해나가면 아주 좋겠지만, 당장에 작업이 들어가야 하면서 나의 연차로는 도저히 저 너머의 것부터 상상하기 어렵기 때문에 우리는(나는) 보통 화면을 그리고, 화면 간의 플로우를 이어 나가며 개발자에게 문서를 전달한다.

 

실제로 앞단의 서버를 설계하는 개발자와 주로 일하기 때문에, 화면과 함께 정책 정의를 설명해야 개발자 분들도 좀 더 이해하기 쉬울 것이다.

개발자의 언어와 기타 보통 사람(기획자 포함)의 언어는 아주 다르므로, 어려운 용어 써가며 방대하게 말해봤자 실제 설계에는 상상과 같이 구현이 안될 수 있기 때문이다.

 

이전까지 거쳐온 프로젝트는 단순히 모바일에서 구현되는 것이고, 원래 있던 것의 개선 작업 정도기 때문에 이 방법이 가능했었다.

그러나 우리 회사는 기본적으로 기기(IoT)와 서버 간 통신, 사용자 클라이언트단과 서버 간 통신이 함께 존재하며, 기기의 통신을 받아오는 부분은 모바일보다 더욱 명확해야 하기 때문에 비즈니스 로직에 대해서만 구체화할 것이 아니라 실제 서버에서 동작되어야 하는 시작조건과 종료조건 그리고 api 통신이 발생하는 시점에 대한 정의까지 요구되곤 했다.

 

나는 디자이너가 아닌 기획자이고, 제품에 대한 높은 이해도를 바탕으로 기능을 구현해야 하므로 더욱이 서버구조와 설계 구현에 관한 상세 요청이 더욱 필요했다.

 

때문에 개발자와의 더욱 원할한 소통을 위해 '대규모 시스템 설계 기초' 스터디를 진행한 바 있고, 벌써 한 회차만 남겨두고 있다. 이 부분은 다른 글에서 다룰 예정이며(꼭 남겨야지..) 다시 본론으로 돌아오자 

 

오늘 글로 어떤 지식을 정리하고, 정보를 남기려는 것은 아니다. 어느 정도 포함될 수는 있겠지만.. 그저 요즘 내가 프로젝트를 통해 느끼는 어려움과 깨달음을 간단하게나마 정리하기 위해 잊어버리기 전에 글을 작성하는 것이다.

 

최근 회사 신규 사업을 위해 하드웨어(기계)를 신규로 개발하며, 서버를 구축하고 기계와 기계관리시스템, 이 값을 받아오는 서버, 사용자앱까지 총 네 개의 시퀀스 통신을 논의하고 더욱 명확한 정의가 필요하여 내/외부 관계자와 계속해서 소통하는 일이 진행 중에 있다.

내가 PM은 아니고, 비즈니스 의사결정에 있어 운영앱을 통해 최초 MVP 버전을 선런칭하기로 해서, 운영앱 담당 기획자인 내가 기획자 포지션으로 합류하게 되었다. 덕분에 모바일 내에서만 이루어지는 동작과 기기간 단순 통신만이 아닌 기기간 커맨드 통신 백엔드 서버 개발과의 소통 방식에 대해 경험해 볼 수 있는 기회가 되었다.

 

기기와 백엔드 서버는 화면으로 소통하지 않는다. 

 

시퀀스 다이어그램(사용자 동작 시나리오)과 연동규격서를 만들어 소통한다.

마이크로소프트 UML 시퀀스다이어그램 만들기 캡쳐: 예제로 가져옴

https://support.microsoft.com/ko-kr/topic/uml-%EC%8B%9C%ED%80%80%EC%8A%A4-%EB%8B%A4%EC%9D%B4%EC%96%B4%EA%B7%B8%EB%9E%A8-%EB%A7%8C%EB%93%A4%EA%B8%B0-c61c371b-b150-4958-b128-902000133b26

UML 시퀀스 다이어그램 만들기 - Microsoft 지원

 

물론 회사 바이 회사이고, 아직 나도 이제 막 경험하는 단계라 정답이라고 할 수는 없다.

백엔드 개발은 시퀀스 다이어그램을 통해 어느 시점에 어떤 커맨드 통신이 이뤄지고, 이때 어떤 결과가 발생해야 하는가가 매우 명확해야 한다.

특히나 단어의 정의에 대해 집요할 정도로 어떤 의미로 이 단어를 선택했는지, 어떻게 동작이 되기를 기대했는지를 굉장히 디테일하게 다뤄야 한다. 상호간 이해가 일치할 때 원하는 결과를 얻을 수 있다.

(개발은 다 이렇겠지만)

 

특히 연동 규격서에 따른 기기 통신 설정은 한 번 그 값을 결정하고 나면, 구조를 서버에서 임의로 변경하지 못하기 때문에 어디까지 기기 통신을 통해서 결과를 만들어낼 것인지와 어디부터는 서버가 조정할 것인지 그 범위를 결정하는 것은 매우 중요하다.

 

다시금 느낀 건 화면을 만들 때 단순히 보기에 예쁘고, 좋아 보여서가 아니라 개발단에서 어떻게 동작해야 하는지 그리고 기존에 이미 설계된 페이지인 경우 어떻게 구조를 변경해야 하는지(왜 변경이 필요한지, 가급적 변경X), 각 동작을 수행했을 때 기대하는 api 통신은 무엇인지 고려해야 한다는 것이다.

 

이번 프로젝트가 잘 마무리 되기를 바라며(여러개이긴한데), 종종 느낀 점을 남겨 나의 성장기를 기록해보려고 한다.

이렇게 정리하다보면 나도 여러 인사이트를 남겨 주시는 글들처럼 개념도 정리하고, 나의 학습도 잘 기록해볼 수 있겠지.