알바몬의 플로우차트 분석 (학습 이전)

2023. 1. 16. 19:39카테고리 없음

코드스테이츠 PMB 16기 W6D1
코드스테이츠 PMB 16기 W6D11. 오늘 강의를 바탕으로 본인이 관심 있는 프로덕트에서 고객이 할 수 있는 행동에 대한 Flow Chart를 작성해 봅시다.

알바몬

알바몬은 220만 사용자를 보유한 구인/구직 앱 시장의 1위 서비스이다. 오늘은 알바몬의 채용 과정에 대해 플로우 차트를 그려보고 클라이언트와 서버, UI와 데이터베이스가 어떻게 작동할지 간략히 예상해볼 것이다.

알바몬의 Flow Chart

이번 과제로 알바몬을 선택한 이유는 데이터를 주고 받는 과정이 많고, 개인・기업 회원으로 클라이언트가 나뉘어져 있었기 때문이다. 플로우를 두 개로 나눠서 생각해야 하기 때문에 좀 더 다방면으로 생각해볼 수 있을 것 같았고, 나중에 디벨롭할 부분이 많을 것 같았다. 하지만 개인 회원으로만 사용해보고 기업 회원으로는 사용해본 적이 없어서 '이렇겠지'라고 생각하며 작성했기 때문에 실제 프로세스와는 많이 다를 수 있다.

실제로 과제를 해보니 이것저것 전부 고려하자면 한없이 복잡해질 것 같아서 핵심적인 플로우만 남겼다. 회색 원은 플로우의 시작과 끝을 의미하는데, 개인/기업이라고 써진 원이 시작점이다. 기업이 지원자 중에 합격자를 선별하면 알바몬에서의 채용 프로세스는 끝나기 때문에 END로 간다.

주황색 원은 고객이 수행해야 하는 동작이자 단계이다. 이력서 작성과 공고 검색이 병렬로 있는 이유는 알바몬이 둘 중 어느 것을 먼저하라고 요구하지 않기 때문이다. 그렇다고 둘이 어떤 시점이나 조건에 의해 분기되는 것이 아니기 때문에 분기점을 사용하지 않았다.

초록색 마름모는 흐름이 나뉘는 분기점이다. 기업 회원이 합격자를 결정함에 따라 어떤 회원은 합격해서 한 프로세스를 끝내게 되고, 어떤 회원은 다시 공고를 검색해야 하기 때문에 분기점으로 나누었다. (물론 합격하길 포기할 수도 있지만..)

실선으로 표시된 화살표들은 고객의 행동이 실제로 다음 단계로 넘어가는 것을 의미하며, 점선으로 표시된 선은 어떤 행동이 다른 행동에게 영향을 미치는 경우에 표시했다. 에를 들면, '지원 알림'은 '공고 지원'이 이루어져야만 스텝을 밟을 수 있다.

 

2. 1번에서 선택한 행동 시 UI, 클라이언트, 서버, DB가 각각 어떻게 보이고 작동할지 예상하여 적어 봅시다.

처음에 질문을 봤을 때는 '어떻게 예상하고 어떻게 적어야 되는 거지?'라고 생각하며 감을 잡지 못 했다. 그래서 일단 UI, 클라이언트, 서버, DB를 한 줄씩 써놓고 각자의 역할을 적으려고 시도해보았다. 그런데 조금 적다보니 이럴 거면 그냥 사전에서 배껴 적는 게 나을 것 같다는 생각이 들었다. 그래서 위에서 작성한 플로우차트의 단계에서 각각 어떻게 이것들이 상호작용하는지 적어보았다.

혹시라도 오해할까봐 적는 Warning  — 모든 내용이 뇌피셜입니다.

앱 실행 (고객 & 기업)

  1. 고객이 앱을 실행하면 앱 클라이언트가 서버에 자신의 식별 정보를 보내고 초기 데이터를 요청한다.
  2. 서버는 고객의 클라이언트로부터 받은 식별정보를 통해 개인 회원인지 기업 회원인지 구분하고, 그에 맞는 UI 데이터를 클라이언트에게 응답한다.
  3. 고객의 화면에 UI가 출력된다.

 

공고 등록 (기업)

  1. 고객이 UI의 '공고 등록' 버튼을 누르면 클라이언트가 서버에게 공고 등록 작성 페이지를 요청한다.
  2. 서버가 클라이언트에게 공고 등록 작성 페이지에 대한 데이터를 보낸다.
  3. 고객의 앱 화면에 공고를 등록할 수 있는 페이지가 출력되고, 양식에 맞게 작성한 뒤 '완료’ 버튼을 누른다.
  4. 클라이언트가 입력된 공고 정보를 서버에게 보내며 등록을 요청한다.
  5. 서버가 전달 받은 공고 정보를 공고 DB에 저장한 뒤, 클라이언트에게 등록이 완료되었다고 응답한다.
  6. 고객의 화면에 '등록 완료'라는 팝업이 출력된다.

 

공고 검색 (개인)

  1. 고객이 검색하고자 하는 단어를 검색란에 입력하고 검색 버튼을 누른다.
  2. 클라이언트가 검색어를 서버에게 전달하며 검색 결과를 요청한다.
  3. 서버가 클라이언트로부터 받은 검색어와 매칭되는 정보를 공고 DB에서 조회한다.
  4. 서버가 DB에서 출력된 결과값과 검색 결과 페이지의 UI 데이터를 클라이언트에게 보낸다.
  5. 고객의 화면에 결과값을 보여주는 UI가 출력된다.

 

공고 지원 (개인)

  • 공고 등록과 같은 프로세스이고 주고 받는 데이터만 바뀔 것이라 생각하여 생략한다.

 

지원 알림 (기업)

  1. 클라이언트가 실시간으로 서버에게 새로운 지원이 있는지 물어보는 요청을 한다.
  2. 개인 회원으로부터 지원이 생기면, 서버가 클라이언트에게 요청을 받아 DB로부터 개인회원의 지원 정보를 조회하고, 출력값을 보낸다.
  3. 응답 받은 앱 클라이언트가 기업 회원에게 푸시 알림을 보낸다.

 

지원자 조회 (기업)

  1. 고객이 지원자의 ‘이력서 보기’ 버튼을 누르면 클라이언트가 지원자의 정보를 보내며 해당 지원자의 이력서 정보를 서버에 요청한다.
  2. 서버가 전달 받은 지원자 정보를 통해 DB에 저장된 지원자의 이력서를 조회한다.
  3. 서버가 DB에서 출력된 이력서 정보와 이력서를 표시하는 UI 정보를 클라이언트에게 보낸다.
  4. 고객의 화면에 지원자의 이력서 정보를 보여주는 UI가 출력된다.
  5. 고객이 앱을 실행하면 앱 클라이언트가 서버에 자신의 식별 정보를 보내고 초기 데이터를 요청한다.
  6. 서버는 고객의 클라이언트로부터 받은 식별정보를 통해 개인 회원인지 기업 회원인지 구분하고, 그에 맞는 UI 데이터를 클라이언트에게 응답한다.
  7. 고객의 화면에 UI가 출력된다.

 

이후 프로세스는 개인적인 경험상 기업에서 이력서에 적힌 전화번호로 직접 지원자에게 합격을 알리고 추가 면접을 공지하는 등의 프로세스를 거쳤다. 따라서 알바몬의 시스템을 이용하지 않기 때문에 이력서 조회까지만 생각해보았다. 기업이 이력서를 열람했을 때 지원자에게 푸시 알림을 통해 알려주는 서비스도 있긴 하지만, 필수적 플로우가 아닌 선택적인 기능이기 때문에 고려하지 않았다.


이번 주부터 본격적으로 시작인데, 첫날 과제를 이렇게 제약조건 없이 자유롭게 작성하게 하는 것은 험난한 미래를 알리는 복선인 것일까? 나중에 이 차트가 어떻게 구체화되고 복잡해질지 기대도 되고 걱정도 된다.