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 -->