이 문서를 들어가기 전에 PMP 란? 읽어주시길 바랍니다.
본 문서는 위와 같은 내용으로 작성되었습니다.

이 문서에 대하여
1. 본 문서는 Smooth 팀을 관리 하기 위한 PMP 문서입니다.
2. 수집한 데이터들은 크게, 계획(Plan)과 경험으로 이뤄져 있으며, 계획(Plan)에 따른 관리 대상 및 계획 점검의 방법은 수시로 Update 됩니다.
3. 경험의 경우 Wiki의 Footer(e.x. Project Logging)로 관리하며, 프로젝트를 진행하면서 직면한 모든 상황에 대한 기술입니다.

1. 개발 목표
   • 개인 목표
   • 팀 목표
2. 프로젝트
   • 주제 선정 동기
   • 프로젝트 기대점
3. 프로젝트 관리&계획
   • 업무 분담
     1. 프로젝트 목표, 업무 분담 관리 계획
     2. 프로젝트 협업, 일정 관리
     3. 위험 관리
   • 일정
   • 커뮤니케이션
   • 프로젝트 품질

• 목표 : MSA 구조를 이해하고 설계하기!

💬 (도착) 상태가 되기 위한 관리 방안

1. 기존 기술 스택의 작동 원리를 제대로 파악하여 정리하는 습관을 들인다.
2. MSA 구조에 대한 책을 통해 전체적인 구조를 이해한다.(Start DDD)
3. 새로운 기술 스택을 접할 때마다 작동 원리부터 이해하는 습관을 들인다. 

• 목표 : 서버 아키텍처를 이해하고 성능을 개선을 경험하기!

💬 (도착) 상태가 되기 위한 관리 방안

1. 대용량 서비스를 고려한 설계 및 개발 능력을 갖춘 상태
    - 대용량 서비스에서 고려해야 할 배경지식을 쌓는다. 
       - 책을 통해 사전 배경지식을 이해한다.
           - 책 (1회독) : 대규모 시스템 설계 기초
       - 프로젝트의 기능에서 적용할 수 있는 부분을 정리하고 활용 및 계획을 수립한다.
    - 서비스가 분산될 때를 고려한다. → MSA를 이해하고 적용한다.
       - 강의와 책을 통해 MSA에 대한 이해와 구현 방법을 공부하고 적용한다.
           - 강의 (완강) : Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA)
           - 책 (1회독) : 도메인 주도 설계로 시작하는 마이크로서비스 개발

2. 사용한 기술 및 방법에 대해 이유를 설명할 수 있는 상태
    - 기술을 사용할 때는 항상 사용 이유를 정리하고 기록한다.
    - 사용 과정에서 선택이 필요한 상황에서는 목적에 따라 비교해야 할 측면을 설정하고 항목 별 우선순위에 따라 기술을 선택한다. 

3. 성능 측정 및 기능을 개선하는 습관
    - 코드를 작성하기 전에 병목 발생 및 성능에 영향을 줄 수 있는 지점을 미리 생각하고 작성한다.
    - 기능을 개발한 이후에는 성능 측정 도구를 활용하여 성능을 측정한다.
        - 측정 도구 : nGrinder
    - 미리 작성한 병목 지점에 대한 생각과 측정 도구를 통해 얻은 결과를 비교한다.
    - 팀원과의 협의를 통해 성능 개선 항목의 우선순위를 설정하고 '개선 방법' 및 '기대 효과'를 작성하고 측정한 후 '실제 결과'를 정리한다.

• 목표 : 클린 코드를 작성하는 개발자가 되기!

(도착 상태 상세)
- 파일의 목적에 맞는 깔끔한 코드
- 재사용이 이루어지는 코드들은 쉽게 재사용 할 수 있는 구조
- 직관적으로 이해되는 이름

💬 (도착) 상태가 되기 위한 관리 방안
- 1주일에 한 번 자가 검진하며 코드를 더 개선할 수 있는지 고민한다.
- 2주일에 한 번 프론트 개발 경력이 있는 병찬님과 함께 코드리뷰하며 목표가 잘 지켜지고 있는지 점검한다.

• 목표 : 유지 보수하기 쉬운 코드를 작성하기!

💬 (도착) 상태가 되기 위한 관리 방안

1. 유지보수 하기 쉬운 설계에 대한 통찰력을 갖춘 상태
[설계 단]
- 주요 기능 단위 개발 시 컴포넌트 다이어그램을 먼저 설계함으로서 적절한 설계인가에 대해 점검한다.
- 디자인 패턴의 경우, 선택한 디자인 패턴과 다른 디자인 패턴을 비교하여 프로젝트에 적절한 설계패턴임을 설명할 수 있다.

[코드 단]
- 프로토콜 지향 프로그래밍을 통해 다양한 상황에서 유연하게 대처할 수 있는 코드를 작성한다.
- 스토리보드 사용을 지양하여, 재사용 가능한 UI 개발한다.
- 자주 사용하는 컴포넌트는 미리 정의하여 사용한다.
- 각 모듈(또는 기능)별로 폴더링을 구성하여, 프로젝트 폴더 구조를 직관적으로 이해할 수 있게 구성한다.
- 같은 기능 구현 시, First-party로 제공되는 것이 있으면 비교해보고 최대한 First-party 사용을 지향한다.
  - 너무 많은 코드양이나 학습의 난이도가 있는 경우를 기준으로 선정

2. RxSwift를 이해하고 상황에 맞는 비동기 코드를 작성한다.
- 새로운 기능 단위의 개발을 시작하기 전에, 비동기 흐름에 대해 먼저 구상한다.
- Rx 관련 새로운 지식을 학습한 경우, notion에 daily로 정리하고, 블로그에 포스팅한다.
- 상황에 따라 다양한 Rx 연산자를 사용하도록 노력한다.

팀원의 공통된 개인 목표를 바탕으로 팀 목표를 선정하였습니다.

• 1년 뒤에 봐도 부끄럽지 않은 코드를 작성하자!

❓ 부끄럽지 않은 코드
다른 사람들이 이 프로젝트를 잡아도 금방 개발할 수 있을 만큼 쉽게 이해할 수 있는 코드입니다.
이 코드를 작성하기 위해서는 해당 아키텍처의 전체적인 흐름을 읽을 수 있어야 합니다.

• 기술 스택에 항상 '왜'라고 묻는 습관을 들이자

왜 쓰는지 아는 것은 그 기술 스택이 어떻게 작동하는지 아는 상태이다. 그 기술 스택을 작동 원리부터 공부하여 제대로 파악하는 것이 중요하다.

💬 팀 목표 세부 관리 방안

1. 변수 또는 클래스 이름을 clear하고 직관적으로 작성하도록 노력한다.
    - 프론트엔드와 백엔드에서 사용하는 naming에 차이가 없게끔 한다. 백엔드의 naming을 기준으로 프론트엔드가 맞춰 짓는다. 
2. 포지션(프론트엔드/백엔드)의 기능 설계 시 미팅을 열어, 참석을 원칙으로 하며 상호간 포지션의 이해도를 높이도록 한다.
    - 단, 미팅은 필수가 아닐 수 있고 문서로 대체가 가능하다.
3. 새로운 기술 또는 오픈소스를 도입 시, 관련해서 적합한 선택이었는가에 대해서 고민하고 Wiki의 Footer 부분에 흔적을 남긴다.
    - 팀원에게 직접 설명하는 시간을 가지어 의문을 갖는 태도를 기를 수 있도록 한다.

본 문서를 시작하기 전에, Discord 서비스에 대해서 잠깐 읽어주세요.

1. 조원 모두 다 평소에도 자주 사용하는 서비스로 애착이 깊으며, 이해도가 높다.

2. 채팅 서버, 시그널링 서버, 미디어 서버, presense 서버, 알림 서버 등 MSA 관점에서 확장 시킬 수 있는 프로젝트로 적합하다.

3. 음성, 영상 채팅의 주제에서 고려해야 할 기능들은 작동 원리를 제대로 파악하는 것이 중요하므로
기술 스택의 이해부터 시작하는 목표와 적합하다.

4. 디스코드 커뮤니티 구조는 카테고리부터 각각의 채널, 스레드까지 복잡한 구조를 가지고 있다. 전체적인 흐름을 이해하고
클린 코드로 리팩토링 하기에 아주 적합한 주제이다.

1. 대용량 서비스 설계

• 대용량 서비스 설계 및 구현을 경험하기 위해 다수의 사용자, 다양한 서비스들의 연관 관계 속에서 안정적으로 서비스되고 있는 애플리케이션들을 고려했다.
• 대용량 서비스 설계 과정에서 벤치마킹 대상으로 삼을 수 있다.

2. 커뮤니티 단위의 메신저 구조 설계

• 디스코드의 서버처럼 커뮤니티 단위로 사용자가 자유롭게 의사소통하는 환경의 개발을 경험하고 싶다.
• 특히 서버의 채널처럼 사용자가 자유롭게 커스터마이징하여 만들어가는 공간을 개발하며 사용자 친화적인 웹사이트 개발 경험을 갖고 싶다.
• 디스코드는 커뮤니티-카테고리-채널-스레드와 같은 계층적 구조를 바탕으로 커뮤니티 내 권한, 알림, 멤버 등을 자유롭게 설정할 수 있고 또한 각 채널마다 구성을 달리 할 수 있다.

3. 실시간 채팅, 실시간 음성, 화상 채팅

• 단순히 텍스트 메세지를 전달하는 메신저가 아닌 다양한 수단을 통해 의사소통을 진행하는 서비스를 설계하고 개발하면서 제공 서비스에 따른 다양한 서버 아키텍처 설계에 대한 경험과 다양한 의사소통 방법을 매끄럽게 화면에 표현하는 경험을 갖고 싶다.
• 애플리케이션의 생명주기에 따른 소켓 통신의 이벤트 처리를 경험할 수 있다.
  • 백그라운드 : 실시간 미팅(화면공유, 음성 등) 시
  • 포그라운드 : 여러 서버(디스코드의 server, 확장된 Room 개념)에서의 실시간 메시징 이벤트 처리
  • 네트워크 환경 : reconnection에 따른 socket 상태 처리

• 목표 : MSA 구조를 이해하고 설계하기! (msa 구조의 데이터 동기화 문제를 kafka message queue를 이용하여 해결)

API Gateway 서버

• server routing
• token validation filter 처리

채팅 서버

• websocket를 통해 통신을 처리하며 kafka를 이용하여 비동기 작업을 통해 메세지를 처리한다
• 카프카의 구조를 파악하고 여러 클러스터를 관리하며 성능 개선을 이룬다.

인증 서버

• jwt token 방식 인증 구현
• access token 인증, refresh token + redis 캐시 저장

알림 서버

• 채팅 아키텍처의 흐름에 맞는 알림 서버 구현
• kafka message queue를 이용한 비동기 처리.
• fcm 연동

• 목표 : 서버 아키텍처에 대한 이해와 함께 성능 개선을 경험하자!

시그널링 서버, 미디어 서버 개발

• 시그널링 서버와 미디어 서버 개발을 통해 미디어 스트림 전송과 관련한 아키텍처 설계 및 개발 경험을 한다.
• 사용자의 수에 따른 연결 관리와 미디어 스트림의 분배 방법을 달리하면서 동일한 기능에 대한 성능 개선을 한다.

커뮤니티 서버, 채팅 룸 서버 개발

• 커뮤니티 단위의 메신저 구조와 사용자의 커스터마이징에 대응할 수 있는 효과적인 도메인 설계를 한다.
• 타 마이크로 서비스(유저 서비스, 상태관리 서버, etc.) 간의 연동을 통해 MSA에 대한 이해와 개발을 한다.

• 목표 : 클린 코드를 작성하는 개발자가 되기

UI/UX 설계, Websocket 연동, WebRTC 연동

• 상당한 양의 클라이언트 코드 속에서 css 선택자명, 변수명, 파일명, 함수명 일관되고 쉽게 이해할 수 있게 작성한다.
• 파일의 목적에 맞게끔 적절히 기능을 나누고, 중복되는 코드는 쉽게 재사용할 수 있게끔 분리하여 작성한다.

UI/UX 설계

• Figma 이용해서 기존 디스코드 웹 UI를 아카이빙한다.

Websocket 연동

• Websocket을 통해 실시간 채팅을 연결한다.

WebRTC 연동

• websocket과 함께 연결하여 음성/영상 통화 기능의 개발한다.

사용자가 커스터마이징하는 서비스

• 사용자가 서버를 생성하고 채널을 취향에 맞게 커스터마이징하는 디스코드를 구현하며 사용자 친화적인 웹을 개발한다.

• 목표 : 유지 보수하기 쉬운 코드를 작성하기!

UI/UX 설계

• Figma 이용해서 기존 디스코드 앱 UI 아카이빙
• 자주 사용하는 색상 및 아이콘 등 asset 정의
  • 기존 UIKit을 extension 하여 custom

채팅 구현

• StompClient 로 채팅 메시징 처리
• 통신 환경에 대한 적절한 UseCase를 선별하여 ViewModel 설계

Web RTC 연동

• WebRTC client side 구현
  • Starscream 라이브러리 사용 (단순 websocket 통신 연결)
    • URLSession의 경우 iOS 13이후에서부터 웹소켓 통신 지원 + 안정성의 문제
• WebRTC 화면 publishing

FCM 연동

• Appdelegate 단에서 메시지 수신
• 수신된 메시지별 server/channel 알림
  
  

프로젝트 목표 달성을 위해, 정기/데일리 회의를 통해 각자 업무를 확인합니다.
본 프로젝트의 회의는 아래와 같이 진행됩니다.

1️⃣ 회의 종류
- 정기 회의 (매주 1회)
- 데일리 스크럼(매일 14:00)

2️⃣ 주요 회의 내용
- 정기 회의) 1주일간의 업무 계획을 공유한다.
    - 단, 예상 가능한 범위 내에서 이야기를 진행하며, 고민사항 등은 간단히 언급 정도만 한다.
- 데일리 회의) 전날 업무에 대한 회고 + 금일 업무 계획을 공유한다.

3️⃣ 규칙
  - 회의를 할 때마다 회의록을 작성하여 기록한다.
  - 정기 회의는 팀원의 요청이 있을 시 언제든지 가질 수 있다.
  - 정기 회의는 1시간을 넘기지 않는다.
  - 스크럼 회의는 10~20분을 가진다.

• 소스 코드 버전 관리
  • Github를 통해 프로젝트 소스코드를 관리한다.
  • 각 인원 별로 branch를 다르게 구성하여 develop branch로 push한다.
  • develop branch에서 main branch로는 조장이 확인하여 push한다.

[소스코드 버전 관리 R&R]
- 박병찬, 김희동(BE) : 개인 브랜치에 push / 최종 병합은 상대가 approve 시 Merge
- 김민지(Web) : 본인 확인 및 궁금한 사항 등 [박병찬] 팀원에게 PR 확인 요청(approve 시 Merge) 
- 김두리(iOS) : 본인 확인 및 Merge  

** 최종 소스코드 관리자 : 김희동 
- 파일 디렉토리, branch 등 전체 관리

• 프로젝트 일정 관리 문서
• Discord + Github Webhook
• Google SpreadSheets
• Github Wiki

(last update) 22.01.07.

위험은 프로젝트 요구사항에 따른 위험, 프로젝트 관리에 따른 위험으로 나뉘며 프로젝트 진행 시 계속 변동된다.

1️⃣ 위험 요소

프로젝트 요구사항에 따라 프로젝트 일정에 차질이 생길 수 있다.

2️⃣ 관리 계획

• 프로젝트 요구사항에 따른 위험이 발생한다면, 즉시 회의를 소집해 프로젝트 일정을 조정하거나 프로젝트 요구사항을 조정한다.
• 이미 발생한 위험 요소는 정기 회의를 통해 어떻게 진행되고 있는지 공유한다.

3️⃣ list-up

• 김민지-Risk 요소

a.
1️⃣ 위험 요소

Github의 다양한 기능을 사용하는데 있어서 미숙하여, 실제 업무와 프로젝트 관리툴(Github) 간의 차이가 있다.

2️⃣ 관리 계획

• Github 사용이 미숙한 팀원이 도움을 요청한 경우 다른 팀원이 사용을 돕는다.
• Github 사용의 매뉴얼을 작성하여 공유한다.[소스코드 버전 관리 R&R]

b.
1️⃣ 위험 요소

일정 테스크 완료 시 프로젝트 관리 툴을 이용하여 다른 팀원들에게 테스트 완료가 되었음을 전파하는데 있어 어려움이 있다.

2️⃣ 관리 계획

• 데일리 스크럼을 통해 완료한 일과 오늘 해야할 일을 시간 순으로 공유한다.
• 업무 중 태스크를 완료하였다면, 오프라인 업무 중일 경우에는 직접 이야기를 하고 온라인 업무 중일 경우 디스코드의 태스크-코드 채널을 통해 이야기한다.

• 일정

• 워크플로우
• 갈등 관리