231205 회의록

231205 회의록

안건

• MVP를 토대로 기대하고 있는 데모 시나리오를 바탕으로 QA 완료
• 기술적 도전거리
• 협업 과정에서 느꼈던 점

MVP를 토대로 기대하고 있는 데모 시나리오를 바탕으로 QA 완료

스플래쉬 스크린 + 타이틀 화면

• 유저 A가 처음에 앱을 실행하면 스플래쉬 스크린이 출력된다.
  • 스플래쉬 스크린이 출력되는 동안 서버와 한 번 통신하여 유효한 JWT 토큰을 갖고 있는지 검증한다.
    • 유효한 JWT 토큰이라면 바로 로그인 처리하고 메인 화면으로 이동한다.
    • 유효한 JWT 토큰이 아니라면 네이버 아이디로 네이버 OAuth 접근 토큰을 발급받아 서버에 전송하여 JWT 토큰을 받아오는 작업을 수행하기 위해 네이버 로그인 화면으로 이동한다.
• 스플래쉬 스크린이 사라지고 네이버 로그인 화면으로 이동한다.
  • 유저 A는 네이버 로그인 버튼을 클릭하여 로그인을 시도한다.
    • 이 때, 네이버 아이디로 로그인하여 네이버에서 OAuth 접근 토큰을 발급받고, 이것을 서버에 전송한다. 그럼 서버는 유저 A가 DB에 존재하는지 확인한 후, DB에 없다면 추가한다. 그리고 유저 A의 ID, 닉네임, JWT 생성일, 만료일을 페이로드로 갖고 있는 JWT 토큰을 클라이언트에 전송한다.
    • JWT 토큰을 클라이언트에서 Decode하고 얻은 닉네임이 Null이라면 회원 가입을 해야 하기 때문에 닉네임 입력 화면으로 이동한다.
    • 닉네임이 Null이 아니라면 이미 존재하는 회원이므로 로그인 처리하고 메인 화면으로 이동한다.
  • 회원 가입이 필요한 유저 A는 먼저 닉네임을 정한다. 닉네임을 정하지 않으면 로그인 처리가 되지 않는다.
    • 닉네임 제한은 아직은 딱히 없으며 닉네임을 입력하지 않는다면 확인 버튼이 활성화되지 않는다.
  • 닉네임을 정한 유저 A는 회원 가입을 성공하였고 프로필 사진을 고를 수 있다.
    • 먼저, 프로필 사진을 고르기 전에 갤러리 접근 권한을 클라이언트가 사용자에게 요청한다.
    • 사용자가 접근 권한을 허용하면 갤러리에서 사진을 고를 수 있다.
    • 사진 추가 버튼이 고른 사진으로 변경되며, 다시 클릭하여 다른 사진으로 변경할 수도 있다.
  • 유저 A가 닉네임과 프로필 사진을 모두 설정하면 메인 화면으로 이동하게 된다.
    • 메인 화면에서 유저 A가 뒤로 가기 버튼을 누르면 앱을 종료하게 된다.

메인 + 게임 대기 화면

• 유저 A는 메인 화면에서 유저 찾기, 게임 신청, 환경 설정 등 다양한 활동을 수행한다.
  • 클라이언트는 3초마다 유저 A의 현재 위치를 서버에 전송하고, 유저 A 근처에 있는 다른 유저들의 위치를 수신한다. 클라이언트는 다른 유저들의 위치 데이터를 토대로 지도에 MapPin 형태로 출력한다.
    • 지금은 자신을 제외한 모든 유저들의 위치를 수신하고 클릭할 수 있지만, 추후에 일정 거리 안에 들어오면 클릭 할 수 있게 변경할 예정이다.
    • 이 때, 회원 가입 및 로그인을 한 유저의 위치를 수신하면 실시간으로 지도에 MapPin으로 찍으며, 로그아웃 및 회원 탈퇴를 한 유저의 위치를 찍은 MapPin은 실시간으로 사라진다.
      • 여기서 필요한 몇 가지 수정할 사항
        • MapPin 클릭 시 해당 유저의 프로필 사진, 메시지 출력(비동기와 관련된 문제인 것으로 추정)
        • 다시 클릭 시 MapPin UI 제거
          • 그런데 다시 클릭해도 없어질 때 있고 안 없어질 때 있음
            • 이제 없어짐!!!!!!!!! 깜빡여서 문제
    • 10초 이상 활동이 없는 유저는 로그아웃 처리하여 클라이언트가 해당 유저의 정보를 수신하지 않게 된다.
  • 유저 A는 게임을 같이 하고 싶은 근처의 유저 B의 위치를 찍은 MapPin을 클릭하여 프로필 사진과 닉네임, 메시지를 보게 된다.
    • 그리고 하단에 Game Start 버튼을 클릭하여 게임을 신청한다. 게임을 신청하면 유저 A는 대기 화면으로 이동하게 된다.
    • 대기 화면으로 이동한 유저 A는 대기 화면에서 자신의 프로필 사진 및 닉네임과 상대방의 프로필 사진 및 닉네임을 확인할 수 있다.
  • 게임 신청을 받은 유저 B의 화면에 게임 신청 수락을 묻는 알림창이 출력되고, 유저 B는 게임 신청을 수락하거나 거절할 수 있다.
    • 유저 B는 게임 신청 수락 알림창에서 자신에게 게임을 신청한 유저 A의 프로필 사진, 닉네임, 메시지를 확인할 수 있다.
    • 유저 B가 게임 신청을 거절하게 되면 유저 B의 화면에서 알림창이 꺼지고, 유저 A도 대기 화면에서 벗어나 메인 화면으로 이동하게 된다.

게임 화면

• 유저 B가 게임 신청을 수락하게 되면 유저 A는 대기 화면에서 대기하다가 TMI 퀴즈 게임 화면으로 이동하고, 유저 B는 바로 게임 화면으로 이동한다.
  • 유저 A와 B는 각각 자신과 상대방의 위치만을 지도에서 확인할 수 있다.
    • 자신과 상대의 위치 데이터을 토대로 지도에 MapPin으로 찍어주는 작업이 필요함
  • 게임 신청을 한 유저 A가 먼저 질문을 하며, 유저 B와 만난 다음 제시된 질문을 해야 한다.
    • 이 때, 질문은 상단에 한 줄로 나오며, 질문의 길이가 너무 길다면 생략하는 대신 질문 Text가 흐르면서 질문의 전체를 확인할 수 있다.
  • 유저 B는 해당 질문을 듣고 유저 A의 특징을 생각하면서 답을 맞춘다.
    • 답을 입력하지 않는다면 서버에 답안을 제출할 수 없게 된다.
  • 유저 B가 답을 제출했다면, 유저 A에게서 답안에 대한 검증을 요청하는 알림창이 뜬다.
    • 이 때 유저 B는 유저 A가 답안을 검증하기 전까지는 답을 추가로 입력하거나 제출할 수 없게 된다.
  • 유저 A가 답안을 검증했다면, 이번에는 유저 A가 답을 맞출 차례가 오고, 유저 B가 문제를 낸다.
  • 이것을 총 N번 반복한 후, 마지막에 자신과 상대방의 점수를 기록한 점수판이 출력되고, 유저 A와 B는 점수판을 확인하고 확인 버튼을 눌러 게임 화면에서 벗어날 수 있게 된다.
  • 어떤 유저가 앱을 꺼버려 통신이 끊어졌을 경우, 아직 게임을 하고 있는 다른 유저에게 통신이 끊어졌다는 알림창을 출력한다.

환경 설정 화면 + 사이드바

• 유저 A는 그냥 닉네임이나 프로필 사진이 마음에 들지 않아 환경 설정에서 변경하고 싶어져, 좌측 상단 버튼을 클릭하여 사이드바를 열고 환경 설정 버튼을 클릭하여 환경 설정 화면으로 이동하였다.
  • 먼저 닉네임을 변경하기 위하여 닉네임 변경 버튼을 클릭하였다.
    • 새로운 닉네임을 입력할 수 있는 알림창이 출력되고, 새로운 닉네임을 입력하고 변경 버튼을 누른다.
    • 그럼 클라이언트가 서버에 새로운 닉네임을 전송하고, 서버는 DB에서 유저 A의 닉네임을 변경하고 클라이언트에 요청이 성공했다고 응답한다.
    • 응답을 받은 클라이언트는 즉시 가지고 있는 유저의 정보를 서버에서 새로 수신하여 변경한다.
    • 환경 설정, 사이드 바 등등에서 유저의 닉네임이 변경된다.
  • 그리고 프로필 사진을 변경하기 위하여 프로필 사진 변경 버튼을 클릭하였다.
    • 새로운 프로필 사진을 고를 수 있는 알림창이 출력되고, 새로운 사진을 고르고 변경 버튼을 누른다.
    • 그럼 클라이언트가 서버에 새로운 사진 File을 전송하고, 서버는 DB에서 유저 A의 프로필 사진 URL을 변경하고 클라이언트에 요청이 성공했다고 응답한다.
    • 응답을 받은 클라이언트는 즉시 가지고 있는 유저의 정보를 서버에서 새로 수신하여 변경한다.
    • 사진이 표시되는 모든 UI에서 새로 수신한 프로필 사진 URL을 URI로 변경한 후 보여준다.
  • 닉네임과 프로필 사진을 변경한 유저 A는 다시 다른 유저와 게임을 하기 위하여 사이드바를 열어 지도 버튼을 클릭해 지도 화면으로 이동한다.
  • 유저 A는 더 이상 앱이 재미가 없어져 회원 탈퇴를 하고 싶어 환경 설정 화면에서 회원 탈퇴 버튼을 클릭하였다.
    • 회원 탈퇴를 묻는 알림참이 출력되고, 유저 A는 탈퇴 버튼을 누른다.
    • 회원 탈퇴 API 통신이 이루어지고 DB에서 유저 A의 데이터가 삭제되며, 유저 A는 로그인 화면으로 이동한다.

개선 사항

• 지도에서 MapPin 갱신 관련 문제
• 전체적인 다자인 개선
• 소켓 서버에 방을 깨는 API 추가 -> GameActivity를 벗어날 때 해당 이벤트를 뿌려서 방을 깸(가능하면)
• 게임 신청 수락, 답안 검증, 통신 끊어짐, 점수판 Dialog는 Dialog 이외의 부분을 터치해도 꺼지지 않도록 변경(버그 방지)

[BE] 기술적 고민

MVP

• 오늘 : 만들기
• 내일 : 연동 다 확인
  • 수요일 부터 PR 정상화
• 수,목, 다음주 월, 화 : 기술적 도전

기술적 도전 거리

• CI/CD
• 코드 리팩토링
• 테스트 코드
  • 학습
  • 유닛테스트?: 전체를 한번에 테스트하는 것이 아니라 유닛 단위(컨트롤러, 서비스 등) 단위로 테스트
• 부하 테스트 : 도전적
  • 부하 테스트 기법 개발 : ~ 목
    • 온라인/오프라인 여부 판단 [기술적 고민!!!!]
      • 소켓 연결로 판단 : 서버에 부담 적음. but stateful
      • last_polling_at으로 판단 : 서버에 부담 마니 감. but stateless
        • 진짜로 많이 가나?? : hmm…
  • 코드 (주변 유저 탐색 알고리즘 등) 개선 : ~ 화
• 추가 기능 구현…
• 작업 분배 : 기술적 도전거리 잘 드러나게 문서화 (있어보이게) 고려!
  • 공동 : 리팩토링
  • 선범 : 부하테스트
  • 승찬 : 테스트코드, CI/CD

멘토링 피드백

• 테스트코드 : 시간이 좀 걸릴 수 있음 ㅠㅠ
  • 유닛 테스트 정도만 해봐도 좋을 듯
  • nest.js 템플릿을 따라서 해보기
• 부하테스트 : 성능 개선 포인트 도출 → 성능 개선으로 이어가면 굿
  • 아파치 쪽 벤치마킹
  • AB, Jmeter 등
  • 여러가지 방식
    • 트래픽 부하 :
    • DB 부하 : 전국구 10만명 서버 응답 보장?
    • 동시에 걸어 보기
    • 소켓을 지원하는 테스트 도구 찾아보기
      • https://github.com/pgriess/wsbench
    • DB 테스트만 해도 충분할 듯
• CI/CD : Docket hub보다 같은 클라우드 플랫폼에서 가져오는 것이 좋아보일 수 있다.

[AOS] 기술적 고민

• 책임 분리 & 소켓 프로그래밍 & Activity, Fragment의 생명 주기와 관련된 문제
  • 게임을 수락한 유저는 게임 실행이 되는데, 게임을 신청한 유저는 게임을 하지 못 하는 상황이 발생함
  • QuizFragment에 필요한 소켓 이벤트를 QuizFragment의 onViewCreated에서 연결한다면, WaitFragment에서 대기하다가 QuizFragment로 이동한 유저는 그 전에 소켓에서 emit한, 퀴즈 게임을 시작한다는 quiz 이벤트에 대한 코드를 처리할 수가 없게 됨
  • 따라서, 소켓 이벤트 처리를 달아주는 작업을 GameActivity가 관리하는 QuizViewModel에서 수행하도록 하고 그것을 GameActivity의 onCreate에서 호출한다면, 생명 주기를 고려하였을 때 onViewCreated 이후에 collect하는 모든 소켓 이벤트에 대한 처리를 할 수 있음
• parentFragmentManager vs childFragmentManager
  • MapFragment에서 SettingFragment로 이동한 후 다시 지도 Fragment로 이동한 경우 네이버 지도의 기본 화면이 출력되는 현상이 발생함.
  • parentFragmentManager로 NaverMap Fragment를 추가하고 있어 지도 Fragment가 아닌 NaverMap Fragment로 교체했기 때문에 발생하는 현상으로 보임.
  • childFragmentManager로 바꿔줌으로써 MapFragment 내에서 NaverMap Fragment를 추가하도록 수정하였더니 SettingFragment에서 다시 MapFragment로 와도 현재 유저의 위치를 중심으로 지도 UI가 잘 그려지는 것을 확인하였음.
• 핀 갱신 딜레이에 따른 깜빡임 해결
  • 현재 구현된 코루틴의 정확한 구조 확인 필요
• 직군별 멘토링(안드로이드)
  • 버그 열심히 고쳐보자
  • 권한 관련 시나리오 추가
  • 핀의 경우 위치면 변경
  • 소켓 룸 폭파 방지
    • 의도치 않게 네트워크가 끊겼을 때 처리(방이 폭파되지 않게)
  • 권한 문제(권한 물어본 후에 gps 킬 수 있도록 해야 함)
    • gps 가 꺼져있을 경우 튕기는문제→ gps 키라는 알림 보내야할 것 같음.

협업 과정에서 느꼈던 점

BE

• 안드로이드와 협업하기 위해 서버에서 개발용 도구(API와 스웨거 등)를 마련해야 한다는 걸 느낌
• 연동은 한 번에 되는 일이 없음… 충분히 마진을 가지고 테스트에 임해야 한다는 걸 배움

AOS

• 서버에서 수신한 데이터나 로직을 바탕으로 UI를 구성하는 작업이 많이 어려웠습니다.
• 서버에서의 지속적인 갱신 또는 갱신 과으로 인해 동기/비동기 처리에 대한 문제가 발생 하였습니다.

멘토링 피드백

• 시나리오 기반 QA 굿 : 데모의 법칙을 조금이라도 줄이는 방법
  • 아직까지 좀 불안함 : 시간이 많이 걸림 → 다음주까지 빠르게 안정화!!
• 사용자가 늘면 맵핀을 찍는 거 자체가 문제임 :
  • 특정 줌 레벨에서만, 몇 명의 사용자만으로 제약사항을 줘서 문제를 줄이는 것도 방법
• Null 뜨는 거 등 마무리 미흡한 부분 : 시연할 때는 없어야 함
• 최종발표에서는 완성했다는 느낌 → 디자인 요소를 더 넣어보자!(이미지 등, 좀 더 게임같아 보이게)
  • 화면전환 효과를 좀 넣어주자
    • 지금 너무 확확 바뀌어서 딱딱함…
• 발표자리에서는 시나리오 기반으로 설명하기 어려움
  • 시나리오를 가시화 시켜야 함 → 피그마 등으로 플로우차트 준비?
  • 자연스럽게 설명 할 수 있는 방법
• 지도 관련 :
  • 적은 공간에 많은 유저가 있을 때 어떻게 할건가?
  • 유저들/데이터 관리 → 핵심 기술로서 소개 → 정리 잘 해서 설명하기
• 요청
  • 보내는 요청과 받는 요청이 한 번에 되어야 할 필요가 있나?
    • 나누는 것 고려해보기
• 게임 설명
  • 데이터 처리 방법과 게임 흐름 한 방에 납득시키도록 설명 준비하기
• 게임 진행중에 지도를 보고 있을 필요가 있나?
  • 게임방 화면으로 하면 왜 안되지?
  • 우리 앱은 지역 커뮤니티 활성화! → 게임 아님
    • 처음에 소개할때 잘 잡고 가기