알바몬의 플로우차트 발전시키기 (학습 이후)

2023. 1. 30. 23:55PM・PO/코드스테이츠 PMB

코드스테이츠 PMB 16기 W7D4
지난 글
 

[코드스테이츠 PMB 16기 W6D1] 알바몬의 플로우차트

1. 오늘 강의를 바탕으로 본인이 관심 있는 프로덕트에서 고객이 할 수 있는 행동에 대한 Flow Chart를 작성해 봅시다. 알바몬 알바몬은 220만 사용자를 보유한 구인/구직 앱 시장의 1위 서비스이다.

hnsl.tistory.com

 

1. 지난 2주 동안 강의를 바탕으로 본인이 관심 있는 프로덕트에서 유저가 할 수 있는 행동에 대한 Flow Chart를 만들어 봅시다.

알바몬

알바몬은 220만 사용자를 보유한 구인/구직 앱 시장의 1위 서비스이다. 저번 시간에는 간략하게 알바몬의 채용 프로세스에 대해 알아봤다. 

Flow Chart  BEFORE

개인과 기업 사용자 둘로 나누어 플로우차트를 작성했는데, 회원가입이나 로그인 등의 절차도 생략하고 가장 기본적인 과정만 그렸었다. 지금 보면 너무할 정도로 간단하게 작성한 것 같다.

Flow Chart  AFTER

다시 한번 작성해본 플로우차트에는 사용자의 흐름 뿐만 아니라 서버와 DB, 각 개체 간의 상호작용까지 표현해보았다. 위아래로 각각 개인과 기업의 플로우가 진행되고, 그 사이에 서버와 DB가 위치해 있다. 기존에 있었던 '합격' 분기점은 제외했다. 

서버와 DB를 가급적 한 곳에 놓고 일렬로 놓고 중복을 제거하고 싶었지만 선이 한 군데로 모여 오히려 불분명해지기 때문에 클라이언트의 요청에 각자 다른 DB가 필요하다면 서버 따로 표시했다. 또한 차트 내에서는 최대한 추가 설명을 배제하고 구별을 위해 필요한 경우에만 선 위에 텍스트를 추가했다. 보다 자세한 설명은 아래에서 확인할 수 있다.

 

2. 지난 2주동안 강의를 바탕으로 1번에서 선택한 행동 시 UI, 클라이언트, 서버, DB가 각각 어떻게 보이고 작동할지 예상하여 적어 봅시다.

2번은 Before & After를 비교하지 않고 기존의 텍스트로 했던 설명에 도식화를 추가하여 보완하는 방식으로 진행했다. 또한 2주가 지난 지금 다시 보았을 때 틀린 것 같은 내용을 수정하고 새로 알게된 내용을 추가했다.

로그인 (고객 & 기업)

  1. 고객이 앱을 실행하면 클라이언트가 서버로부터 받아온 로그인 화면을 출력한다. 개인 로그인 화면의 경우 '소셜 로그인' 서비스별 버튼이 표시되며, 기업 회원의 경우에는 표시되지 않는다.
  2. 고객이 정보를 입력하면, 클라이언트는 해당 정보를 로그인 방식에 해당하는 서버로 API 규격에 맞춰 전송한다. 알바몬 로그인을 했을 경우에는 자체 DB에서 회원 정보를 조회하고, 소셜 로그인의 경우 각 서비스별 서버와 DB에서 자체적으로 인증한 후 결과값을 받는다. 더욱 자세한 절차를 알고 싶다면 아래의 글을 참조하면 좋을 것 같다.
 

소셜로그인 구현하기(1)_그 원리와 절차에 대해서

지난 프로젝트 뿐 아니라 이번프로젝트에서, 그리고 어느 서비스에서든 핵심적인 기능이므로, 먼저 그 원리에 대해서 정리해보고자 한다. 소셜로그인 구현의 원리 소셜로그인을 진행하는 주체

hazel-developer.tistory.com

  1. 서버는 로그인 결과값과 함께 개인 회원인지 기업 회원인지 구분하고, 그에 맞는 UI 데이터를 클라이언트에게 응답한다.
  2. 클라이언트가 고객의 화면에 UI가 출력된다.

 

공고 등록 (기업)

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

 

공고 검색 (개인)

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

 

공고 지원 (개인)

  • 기업의 공고 등록과 거의 같은 프로세스이고 주고 받는 데이터와 DB만 다르다. 

 

지원 알림 (기업)

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

백엔드 서버 아키텍처 — Presentation Layer 3. 응답 유형에 따른 Variation 2— push notification

이 포스팅에서는 웹 서버의 응답 유형중 하나라고 볼 수 있는, push notification의 핵심 원리에 대해서 알아봅니다.

tech.junhabaek.net

 

이력서 조회 (기업)

  1. 기업 고객이 지원자의 ‘이력서 보기’ 버튼을 누르면 클라이언트가 해당 지원자의 이력서 정보를 서버에 요청한다.
  2. 서버가 전달 받은 지원자 정보를 통해 DB에 저장된 지원자의 이력서를 조회한다.
  3. 서버가 DB에서 출력된 이력서 정보와 정보를 표시하는 UI 정보를 클라이언트에게 보낸다.
  4. 고객의 화면에 지원자의 이력서 정보를 보여주는 UI가 출력된다.


글을 쓰다보니 소셜 로그인, 푸시 알림 등 기술적으로 아직 모르는 게 산더미였고 플로우차트도 그리 깔끔하게 작성하지 못 해서 아쉬웠다. 하지만 2주 전의 나와 비교했을 때는 확실히 더 많이 알게되고 발전한 것 같다.