---
# System prepended metadata

title: PMP 2차 Review + FeedBack
tags: ['20220105', PMP]

---

PMP 2차 Review + FeedBack
===

###### tags: `20220105` `PMP`

### ver 2.0

PMP 2차 미팅 리뷰
---



























































































- 일자: 2022.01.05 09:00 - 10:10
- 참석인원: 여승환 이사님, 홍혜주 주임님, LEMONADE(김완기, 이강호, 홍석기)

---


## 이사님 피드백
### 표지

- 레몬 사진이 팀의 아이덴티티를 나타내기엔 레몬이 안달려있기 때문에, 레몬인걸 누구도 모르겠다.

### 하신 말씀들

전체적으로 뭐가 빠진것 같은지 물어보심.

질문을 하려면 기준이 정확한 기준이 있어야함.

---
## 총평
**Plan 중에 개발 계획이 빠졌고**
**how가 구체적이지 않다.** 

---

너희들이 작성한 how는 how가 아니라 **what**이다.

todo를 조금 더 구체적으로가 빠졌다. 

구체적인 개발 계획 / 일정이 잡아놓아야한다. 

작성한 7개 todo에 대해서 플젝 전반에 녹아야있어야 한다. 

억지로 맥락은 찾았을지도 모르겠는데, 맥락을 내렸다는것은 -> 
**그 데이터가 명료하게 보여야해.**

비어놓은것을 억지로 채워놔서. 이 사단이 난것 아닐까?

PMP는 나의 데이터가 되어야한다. // pmp 작성이 나의 성장 지름길이다!
묵시적으로 했던 것들을 -> **명시적으로 선언을 하자**! 가 PMP의 작성 이유다.

management -> 그걸 도달하고자 하는 방법 (협업계획)
plan -> **그 구체적 방법**

**Project Management만 있고, Plan 이 없다.**

- 유연하다는것은 내가 내 계획에 받아들여서 조율이 가능한게 유연하다는뜻!

workflow는 … 
- plan중에 work에 해당하는 부분이다.
- 하나의 plan으로 해결할 수 없다.

내 플젝이 PMP에 충분히 담겨져있냐. 그게 PMP가 잘 작성되었는지 판단하는 방법이다.

프로젝트 안에 수많은 가치가 충돌한다! 
-> 그래서 관리가 필요하다.
-> Management를 위한 management도 필요하다. 

**Plan이 너무너무 빠졌다!**

좋은 목표란?
-> 정량적이고 구체적인 목표. 
-> 항상 사실 정성적으로 끝나는데 … 
-> 그럼 이걸 구체화 하는 방법은? 그게 plan이다. // 계획이 구체적이고 정량적이여해.
-> 나의 현실적인 / 아둥바둥해서 도달할 수 있는 목표를 설정하는 것. //
-> 꿈을 대단하게 설정하는 것과는 또 좀 다르다.
-> 뚜렷한 목표의식을 가지고 있는 운동선수 // 끊임없이 자신의 상태를 점검한다… 

// 우리는 .. 구체적인 plan이 없다… 
//
// 대면은 오늘이 마지막. 
// 국어? 에 대한 피드백을 주신것이다.
// 데이터를 만드는 방법에 대해서 피드백을 준거다.
// 매순간의 우리의 데이터를 만들어야한다.
// 로그가 010101011로만 있으면 뭐하냐, 걔네를 볼 수 있고, 해석하고 읽을 줄 알아야 좋은 데이터이다. 
// 도달했는지 내가 알 수 있어야해!!!!!!!!!!!
// 이거 어떻게하지? 왜 하기로했지? -> 머야 이거 왜나왔지.

- 원하는 일을 매번 할 수는 없겠지만.. 이런 훈련이 되어있다면? 훨씬 자연스럽게 오래할 수 있다.
- 지금 이것이 현재의 트레이닝하는 것이다.
- 바람이 부는 것을 잘 활용하고 / 데이터를 잘 뽑아야한다.

성장시킨다 / 성장한다? -> 이거는 우리한테 달려있다.

**어떤 서비스도 소재로 사용될 수 잇을 것 같다** -> 말이 좀 별로다.
ㄴ 여기 국어가 정말 별로다.
ㄴ 내가 하는 모든일이 설명 가능해야한다. // 문서에도 컨벤션이 있다 … 국어도 잘하자.
ㄴ 팀의 목표만 보면 / **서비스의 형태가 중요하진 않다..** 이런 방향으로!
ㄴ 더 조건이 있어야 할 것 같다.
ㄴ 크림을 선택한 이유를 공고히 적어야한다. 그것이 더 추가되어야 한다.

완기)
내 목적이 … 답을 메겨주기를원하는건지 / 끝까지 완성이 완성인지에따라 다르다.
-> 결과를 중간에 점검 받고 싶다.
-> 계획이 없으니까 … 정확히 MVVM에 대해서 공부하고 분석하고.. 계획이 있으면 점검이 필요없지 않을까?
-> 중간에 내가 잘하고 있느냐, 라고 물어본다면 그 해답은 본인에게만 잇다. (그 설정한 계획에 부합하는지 판단해야한다.)

## *많은 후회는 날 천천히 가게 할 뿐이다.* 후회하지 말자.


### 완기

왜? 이런 목표가 나온 이유는 뭘까?
>- 솔직한 의견 : 채용 시장 요구사항, 협업을 위해 많은 사람이 함께 사용가능한 다양한 패턴 필요.
채용에 대한 목표는 나의 현재의 큰 범주에서의 목표일 뿐
현재 나의 목표는 2달 후 나의 상태
>- MVVM은 MVC에서 벗어나는 첫 번째 관문으로 많은 블로그글을 확인할 수 있었음.
>- MVVM 패턴을 적용하려고하는데 모르잖아. 일단 뭔지 알아야 자세히 배울텐데.
 어떻게 배울거야??
>- 아무것도 모르면서??
모를 땐 러닝 커브를 가파르게 가져갈 수 있는 방법을 찾아보자.
    경험자 추천 결과 얻게 된 방법들은 ?
    
        - "스탠포드 강의 들으세요~"
        - "medium에 MVVM 패턴에 대한 자료가 설명이 잘되있어요"
        - "오픈 소스를 분석해보는 것"

#### Plan
- MVVM 패턴 분석
    - 조사한 것 중 괜찮다는 평이 많은 Rawenderich MVVM Pattern 튜토리얼을 여러번 진행하자.
        - 제시된 MVVM 구조에 대한 이론적 이해와 코드 구성을 이해하자.
        - 하지만 이 튜토리얼이 가진 구조도 예시일 뿐이니까 좀더 다양한 경험이 필요하다.
        - MVVM 구조에 대해 예시코드를 작성하고, 글을 써서 IOS 오픈 채팅방에 뿌려보자. 욕을 오지게 먹고, 배우자.
    - MVVM의 형태로 구현된 오픈 소스를 여러 개 조사 및 정리 후, 공통적인 특징을 분석하고 찾아낸다.
    -> MVVM의 설계에 대해서 보다 다양한 코드 경험을 통한 이해력을 높일 수 있지 않을까?

-> MVVM 패턴 이해에 대한 검증: MVVM 패턴에 대한 이해한 글을 작성해서, iOS 개발 인턴에게 공유해서 피드백을 받아보자.

- 결국 해야할 일은 KREAM 각 뷰에 MVVM 패턴 적용
    - 직접 적용하면서 MVVM 패턴의 구조를 이해할 수 있어야 한다.
    - 구현 전에 구현할 뷰 내부에 각 컴포넌트가 뷰, 뷰모델, 모델 중 어디에 속할지 미리 나누자. 컴포넌트 간 어떤 관계를 가지는지까지 고려하자
        - 뷰: UI 로직
        - 뷰모델: 비지니스 로직
        - 모델: 데이터 자체
        - 뷰가 뷰모델을 가지고, 뷰모델이 모델을 가지는 관계
        // 나눈 결과가 실제로 MVVM 패턴에 부합해야함.
    - 계획했던 분리된 컴포넌트의 구조를 실제 코드로 구현하고, 컴포넌트 간 소유 관계를 판단한다. 소유 관계를 바탕으로 구조가 적합하지 않다라고 판단되면 문제 발생 지점을 찾고, 디버깅 진행 체크 포인트를 하나씩 넘겨가며 실제 MVVM에서 원하는 흐름으로 진행되는지 파악할 것. 
    - 원하는 흐름대로 안간다. 멘토에게 도움을 받자
    - Dev Camp의 장점은 같은 분야를 함께 공부하는 동료가 있다는 점
    - 구현 중 의구심이 든 부분에 대해 동료와 공유하고 같이 고민해보자
    - 만약 MVVM이 잘됐다. Clean Architecture를 추가해서 적용해보자.

내가 구현한 코드의 흐름을 MVVM 구조와 함께 ReadMe에 담자.

MVVM에 대한 명확한 정의 습득

### 강호
진짜 내가 MSA를 만들려면 어떻게 해야 할까?
먼저 어떤 것들이 구성요소로 관리되고 필요한지에 대해서 알아야겠지?
그렇다면 일단 조사가 먼저이겠군
- msa 아키텍처에 대한 조사 -> 그럼 이 조사를 어떻게 할거야?
    - 블로그 읽고 통신 방법, 서버를 나누는 단위, 웹 프레임워크, 오픈소스 도구들을 장단점 용도 비교하고 추가적으로 조사했던 내용들을 스스로 요약 및 설명 할 수 있는 단계까지 이해하기
    - 이해한 내용을 바탕으로 일일업무일지에 기록
- msa 설계하기
    - 조사한 내용을 바탕으로 서버 아키텍처를 스스로 그려보기
    - 내가 설계한 서버를 나누는 단위, 통신 방법, 도구 사용 이유를 바탕으로 합당한지 캠프장님께 아키텍처 리뷰 받기
    - 피드백 내용을 바탕으로 구현해야 할 순서 정하기, 일정도 정해야지 - 여기서 스펙과 내가 사용해야할 도구에 대해서 사용방법, 사용 난이도, 호환성을 바탕으로 설정하기
        - 너무 많은 부분을 수정, 변경 해야한다면: 1.이해한 부분이 잘못되었다면 다시 1번으로 2. 서버 아키텍처 재 설계 하기
- msa 구성하기
    - 구현 과정간 설계 단계에서 예상하지 못했던 문제(주로 에러)들이 발생하잖아 그런 거들을 어떻게 해결할거야? -> 디버깅을 통한 원인 분석 -> 해결 방법 인터넷 검색(스택오버플로 질문 포함), 동료 간 질문을 통해서 공유하고 문제를 해결해본다. -> 이걸 일일 업무 일정에 기록한다. and 팀원 공유 기록에 저장해 도움도 주자!.
        - 만약 동료간 질문을 통해서도 문제가 해결이 안된다면, 멘토님 또는 주변 지인찬스 이용해 2일이상 이 문제를 핸들링 해야 한다면, 방법을 변경 또는 기능을 축소하는 식으로 진행한다.
    - 만약 진행간 변경 사항들이 생긴다면 선택지들에 대한 조사, 우리가 가진자원을 바탕으로 고려해서 선택하기(단, 조사와 선택은 하루를 넘기지 않는다. + 동료나 멘토들의 의견도 종합해보기)
    - 구성 진행간 만약 일정보다 수월하게 진행 될 시에 msa에 추가적으로 새롭게 도입되면 좋은 도구들(테스트 자동화, CI/CD) 이런 것들을 조사하고 도입해 볼만하지 않을까?



### 석기

#### Atomic design Pattern?

##### 가장 우선시 되어야 하는 일부터 적어봅시다. 💪

###### 1. 화면 구성 조사
- 홈 화면, SHOP 화면, 상품 상세 화면, 프로필 화면 등 모든 화면에 보이는 요소들을 수집한다.
- 수집된 요소들을 바탕으로 나눌 수 있는 가장 작은 단위로 나눈다.
- 예를 들어 버튼 하나, 아이콘 하나(돋보기 아이콘, 스크랩 아이콘 등) 가장 작은 단위로 쪼개 분석한다.
- 가장 작은 단위가 곧 `Atom` 이다.
- molecule도 추가예정.

##### atoms(원자들)
###### atoms이란?
- atomic design pattern 에서 가장 기본이 되는, 즉 가장 작은 레고 하나라고 보면 된다.
- **간단하게 말하면, `HTML Tag` 하나라고 보면 된다!**
###### atoms을 어떻게 만들어야 할까.
- 화면 분석 결과에 따라 화면을 구성하는 모든 것들을 잘게 나눈다. 
- 나눈 결과를 바탕으로 가장 작은 컴포넌트를 atom으로 지정하여 코드로 구현한다.
    - 어떻게 잘게 나눌건지?
        - 정말 혼자서 쓰이는 친구들 예를 들어) 버튼, 아이콘, `input` 태그 들... 같은 것들, `HTML Tag` 단위로 나눌것이다.
    - 어떻게 atom을 작성할까?
        - atom들이 가질 수 있는 속성들(props)을 고려하여 작성한다. ⬇️
            - atom을 가져다 쓸때, 글자색 / 배경색/ 테두리 색 등을 자유롭게 설정할 수 있어야하기 때문이다.
            - 이벤트를 바인딩도 있을수도, 없을수도 있으니 그 부분을 유동적으로 적용할 수 있도록 작성해야한다.
        - 상위 단계(분자, 유기체 등)어디서든 가져다가 붙여서 사용할 수 있도록 margin / padding 속성은 자제할 것이다

###### molecules(분자들)
- `Atom` 을 조합하여 `molecules` 를 만든다. 그 기준은 아래와 같다.
- 앞선 단계에서 잘게 나눈 `Atom` 들 중 
> 화면 분석을 통해 2개 이하의 `Atom`이 붙어있는 컴포넌트가 있다면 `molecules` 로 조합하고,

> 여러개의 `Atom` 이 비슷한 기능을 한다면 조합한다.

- 해당 `molecules` 내부에서는 `API` 통신이 들어가지 아니한다.

- `Atom` 자체에는 `margin`, `padding` 이 들어가지 않지만, `molecules` 에는 `atom`에 해당 속성을 첨부에 조정 할 수 있다.

- 예를 들면,
> 화면 상단에 고객센터 / 로그인 / 마이페이지 가 적혀있는 부분이 `molecules` 이다.

###### organisms
- 간단히 말하자면 `Organisms` 부터는 컴포넌트가 최종적인 모습을 가진다.
- `API` 통신이 필요한 부분에 추가한다.
    - 서버로부터 받은 데이터를 포함하고 있는 `Atom` 이나 `molecule` 에게 내려준다.
- `Organisms` 는 이제 `Template`이나 `Page` 에서 레이아웃 상 위치만 계산에 붙인다는 생각으로 작성한다.
- 예를 들면, Header, Global navigation이 해당된다.

###### template
- `Organism` 의 위치를 정해준다.
- 즉, 화면상 위치할 곳을 계산

##### 그럼 Atomic 을 제외하고 추가할 것은 없을까?
- CI/CD 

---

### 개인화 된 추천서비스를 설명 해야해

 - 결국 타당한 이유가 있는 논리로 결과가 도출 되었는지에 대해 알 수 있어야해
 - 구체적인 수치는 더더욱 중요함 - 정량적인 자료가 있어야 함



추천? -> 추천 결과에 대한 설명 제공
이유? -> 어떤 알고리즘을 활용했기 때문에 이런 결과
알고리즘이 여러 개 -> 각 알고리즘 별 가중치 우리 어떻게 구현했는지를 설명

-> 개인화된 추천 서비스를 구현하는 방법들?
이해해야한다.

### PLAN
1. 어떤 방법으로 개인화 추천 서비스를 구현할거야? 조사 (기술)
    - 검색해온다. 합치면 각자 조사 내용 공유하고, 적용하고 싶은 것 고르고 조사하고 문서화하기 - 일요일까지
        - 발생할 수 있는 문제점을 파악해오기
        - 장점 / 단점에 대한 조사
    - 각자 조사한 내용 중, 선택해야함. 하지만 어떤 기준으로 선택할 건지?
        - 기준 : 투표로 가자 - 너무 많은 기준들이 적용 가능해서 오히려 기준을 결정하는 일에 너무 많은 자원을 쏟지 않기 위함
    - 조사한 내용들을 모두 예비 후보들이 될 수 있기 때문에 문서화함
    - 투표에서 선정된 알고리즘은 각 개인 별로 다른 카테고리에 해당하는 더미 데이터를 활용하여 프리 테스트(예제 코드 구현)를 하고, 시행착오를 공유함

#### 1번은 다음주까지!

2. 더미 데이터 - 10일 소요 예상.
    - 선택한 알고리즘을 바탕으로 어떤 데이터가 필요한지 조사 결과 종합
    - 결과를 바탕으로 데이터 수집 방법 수립
        - 예상되는 수집 방법
            1. Kream  크롤링(완기, 강호)
            2. kaggle 데이터 셋 활용(다운로드)
            3. 데이터 만들기(전원 취금이니) -> **유저데이터를 만들어야 함**
        - 데이터 검증
            1. 토탈띠
            2. 추출띠
            3. AI띠

3. 실제 추천 시스템 적용 및 설명
    - 선정된 알고리즘에 구현 로그를 쌓을 수 있도록 함.
        - 어떤 로그를 남길 것인가?
            - 
    - 선정된 알고리즘을 더미 데이터에 적용 후 결과와 구현 로그를 함께 분석
        - 해당 알고리즘의 결과가 납득가능한지 확인해야함.
        - 분석 결과가 우리가 분석하고 예측한결과와 다를경우
            - 1. 더미 데이터 유효성 재검증
            - 2. 알고리즘 재검증 -> 외부의 도움이 필요함
            - 3. 
    



<!-- 
추천 시스템 구현하기
===


## 추천에 필요한 데이터

### 추천 받을 사람과 연관 없는 경우, 추천에 필요한 데이터

- **상품(미디어 콘텐츠) 데이터**
    - 해당 상품의 스펙, 규격, 특징 데이터를 사용 
        --> 상품의 특징을 DB화 하여 표현할 수 있을 때 사용
- **사용자의 행동 이력**
    - 유사한 특징을 지는 사람 또는 과거 구매이력이 비슷한 사람들은 동일한 상품을 선호
        --> 검색이나, 장바구니, 수량 조정, 상세 페이지를 보는 행위 등을 분석 // 갓 출시한 신상품은 행동 이력 데이터가 없어서 추천이 어려움.
- **전문가 또는 직원의 지식**
    - 제 3자의 지식과 경험에 기반하여 해당 상품의 가치를 평가하고 제안하는 기법
        --> ex) 'MD추천상품', '의학 논문에 소개된 슈퍼 푸드'
       
       
### 추천 받을 사람과 연관 있는 경우, 추천에 필요한 데이터

- **행동 데이터**
    - 특정 상품 구매 상세 페이지 방문하였다면, 해당 상품과 연관되는 상품을 함께 노출

- **과거 행동이력 데이터**
    - 과거 구매 이력이나 행동 이력을 종합적으로 검토해 학습
    --> 커머스나, 배달 앱 : '선물'할 용도로 구매했다면, 개인의 취향과 상관없는 추천이 이뤄질 가능성이 있음
- **설문조사 등 마케팅 데이터**
    - 추천 대상자의 프로필을 기반으로 추천
        - 화장품이나 의류 서비스들이 많이 채택하는 방식



![](https://i.imgur.com/JIsqKFk.png)

A-2 연관 상품 유형 : '유사성' & '상호보완성'
A-3 상품 선호 유형 : 고객의 행동 이력을 점수화하고, 높게 나온 상품과 콘텐츠를 추천

참고
---
추천 관련 콘텐츠 조사 및 정리
https://www.beusable.net/blog/?p=4023 -->