넘블을 아시나요? 디프백 연계_ 내가 만드는 나만의 유형테스트 회고 (1탄) - 설계

 

개발자로 일하다 보면 가끔 스스로를 돌아보게 되는 순간이 있다.

• 이대로 괜찮은가?
• 다른 신규 스택도 써보고 싶은데.
• 새로운 것을 만들어보고 싶다.
• 협업도 하고 싶어!

이러한 생각들로 고민하게 된 중에, 넘블을 알게 되었다.

 

디프백 연계 내가 만드는 나만의 유형 테스트

 

     [스펙]     

• Spring Boot: 3
• JDK: Java 17 / Gradle
• Naver Cloud / (Git Action)

제목에서 알 수 있듯이 디자이너, 프론트엔드, 백엔드가 협업하여 서비스를 만들게 된다. 네트워킹 데이도 있어서 별 고민 없이 참여했다.

네트워킹 데이에서는 넘블 측에서 블로그에 소개를 남겨주셨더라..

 

개발자 네트워킹 모임을 찾고 계신가요? 안녕하세요! Team Numble의 제이입니다! | by juya | numble.it | Jun, 2023 | Medium

개발자 네트워킹 모임을 찾고 계신가요?

 

 

주제에 맞게 MBTI (Myers-Briggs Type Indicator) 검사를 기반으로 개발을 진행해야 했는데 서비스를 구축하기 전에 기획 단계에서는 대부분의 사람들이 그렇 듯 기획부터 백엔드 구성과 프론트엔드 구성을 어떻게 할지 논의하게 됬다. 우리 팀은 기획 단계에서 MBTI를 활용하는 방법에 대해 고민하다가, 이미 기존에 MBTI를 활용한 서비스들이 많이 있어 난항을 겪었다.

 

아이디어를 나누면서 나온 결론은,  '멸종 위기 종' 에 대한 정보를 제공하는 것을 목표로 하는 것이 어떨까? 로 시작해 멸종 위기 종 테스트라는 서비스 (서비스명: 플러피 / Fluffi)가 탄생했다.

 

 

 

앞서 서비스를 정한 후 대략적인 플로우를 살펴보자면 아래와 같은 플로우로 진행된다.

1. 사용자는 웹에 접속하여 MBTI 유형 테스트를 시작한다
2. 사용자는 질문 리스트를 조회하고 첫 번째 질문에 대한 답변을 선택한다.
3. 사용자는 다음 질문으로 이동하여 답변을 선택하는 과정을 반복한다.
4. 모든 질문에 대한 답변을 완료한 후, 사용자는 결과 페이지로 이동하여 자신의 MBTI 유형을 확인한다.
5. 사용자는 MBTI 유형별 특징과 멸종 위기 종에 대한 정보를 조회할 수 있다.
6. 사용자는 회원 가입을 통해 결과를 저장하고, 언제든지 다시 접속하여 결과를 확인할 수 있다.

 

 

크게 개발 서비스로 구현되어야 하는 도메인은 크게 MBTI 와 회원 도메인이였고, 이번 프로젝트에서 팀 구성은 백엔드 3명, 프론트엔드 2명, 디자이너 1명으로 구성 되어 백엔드에서는 서비스에 맞게 R&R을 나누기로했다.

 

• MBTI 로직 설계 (담당 하게 된 부분)
• 회원 (로그인, 회원가입 + 인증)
• 서버 (Naver Cloud 및 CI/CD 구축)

본격적으로 서비스 개발하기 앞서 프론트앤드 분들과 몇 가지 협의를 하고 진행했다.

 

---

⇒ 피그마 상 구조는 새 테스트로 고정되어 있지만, 추후 멸종 위기 동물이 추가될 것을 고려하여 확장 가능한 구조로 설계할 것

     : 멸종 위기 동물 종을 관리하는 별도의 테이블을 만들어 동물과 MBTI 데이터를 맵핑하고, 클라이언트 단에서 결과 데이터를 하드 코딩하는 대신, 서버에서 DB에 정보를 저장하고 해당 정보를 클라이언트에게 응답해 동일한 프레임 안에서 응답 받는 데이터만 달라지는 형태로 구성

 

⇒ MBTI 결과 계산을 백엔드에서 진행할지, 프론트엔드에서 결과 값을 계산 후, 서버 단에 응답해 결과를 저장할 것인지 논의 필요

   : 유저가 회원 가입 후 결과 데이터를 확인할 때, 어떤 답변을 선택했는지는 별도로 저장할 필요가 없으며, 답변 선택 시마다 서버와의 통신을 하는 것은 불필요하다고 판단되어 클라이언트에서 결과 계산 후 결과 데이터만 전달하기로 협의

 

---

위의 사항을 고려해 ERD와 API 설계 전에 MBTI 검사 구조를 먼저 생각해 보았다.

• MBTI는 16가지 유형으로 구분되며 각 유형은 4개의 알파벳 조합으로 표현된다.
• ISTJ,ISFJ,INFJ,INTJ,ISTP,ISFP,INFP,INTP,ESTP,ESFP,ENFP,ENTP,ESTJ,ESFJ,ENFJ,ENTJ

각 유형은 개인의 선호하는 태도(내향 또는 외향), 인식 방식(감각 또는 직관), 정보 처리(사고 또는 감정), 결정 방식(판단 또는 인식)에 따라 분류된다. 즉, 유형별로 4개의 알파벳 조합으로 MBTI 질문지와 답변지를 만들 수 있다.

 

 예를 들어,

• 외향(E) vs 내향(I)
  • 질문 1
    • 답변 선택(E)
    • 답변
  • 질문 2
    • 답변 선택(E)
    • 답변
  • 질문 3
    • 답변 선택(I)
    • 답변
• 직관(S) vs 감각(N)
• 사고(T) vs 감정(F)
• 판단(J) vs 인식(P)

위의 예시처럼, 외향과 내향을 판별하는 질문지 3개와 그에 따른 답변에 따라 외향인지 내향인지 판단할 수 있으며, 나머지 유형들도 알파벳 조합으로 판단할 수 있다.

 

이러한 구조로 설계하기 위해서는 질문지를 12개로 구성하고, 각 질문마다 답변이 2개씩 나오므로 총 24개의 답변을 처리하면 된다.

 

위의 내용들의 바탕으로 나온 ERD와 API 스펙이다.

 

ERD

 

API 명세

 

대략적인 설계 적인 부분은 위와 같이 마무리 되었으며, 개발 회고는 추후에 다시 써보고자 한다.

 

여기 까지 짧은 회고 글을 마친다. 그럼 💸💸 (이만 🤗)

 

[짧은 회고와 느낀점?]

• 이번에 진행 된, 넘블에서 얻어 갈 수 있는 것은 무엇이며, 가장 중요하고 어려운게 무엇일지 생각 해 보았다. 이번 주제는 확장하기에는 쉬우나 비교적 무겁지 않은 주제였던 만큼 많은 논의와 협의가 중요하지 않았나싶다. 디-프-백 연계 프로젝트인 만큼 충분한 논의와 협의가 필요 하다. 개발적인 완성도도 중요하지만, 같은 분야에 있어서 개발 가치관이나 일하는 형태는 모두 달라 원하는 바, 궁금해하는 바를 명확하게 표현하고 서로 협의해가는 과정은 필수적으로 있어야 할 것이다.
• 직장인이 하기에는 비교적 부담스러운 시간일 수도 있다. 실제로 팀 대부분이 직장인이였고, 실제 개발할 시간이 많지 않아서 시간 맞추는 게 여간 부담되기도 한다. * 체력 필수