Index
Date
의 회의록 마스터 : 고주형
Participants
TEAM FIRE (고주형 윤영기 이하령) + WonYong Jeong
Discussion topics
리허설 총평
굉장히 잘함
비쥬얼 굳
내용적 굳
충실 시간, 결과물 ㅇㅈ
역할 균형 ㅇㅈ
빡빡 잘함
할 말 2개
우리가 한계점 - 시스템 성능
하반기 계획
1. 시스템
초반 제품 설명
핵심 기술 내용이 길다 -> 하나의 컨텍스트를 여러 장표
동기/비동기 대기에 관한 우려
비동기 상황으로 풀어나갔다 -> 1~2페이지로 끝
심사위원에게 의미있는것
기술적 어려움 겪었넹 -> 풀어낸 경험이 있구나... -> 이게 어필 포인트구나
= 기술적인 성장했구나
... 따라서 내용은 디텔하게 설명할 필요 없다!
성능 개선을 했다!
2. 하반기 계획
우리 제품의 청사진이 뭘까??
이후계획 장표->이벤트 개최
뒤에 BM과 불일치
BM 근거는 좋았어. 표 분석 좋아.
다른 곳에서 유효했으니까 => 우리 고객이 낯설지 않게 과금할 수 있게 해줄거야.
기술적 성장 4명 -> 100명
기술적인 도모
비지니스적인 제품성은 4명에서 백명이다(기술 한계 극복)
동접자를 올리고자 한다
계획적
성능적
=> 하반기 챌린지 들어남
한방에 입장 인원을 늘릴 수 있는 시도
제품 완결성에 필요한 기능 보강하겠구나
= 하반기가 충실하겠다
여기서 우리가 울릴것은 동접자 수를 올리는 것이다
이 비엠의 핵심은 접속자수다! = 우린 동접자 지원한다
다시 생각해볼 것
모도코를 들어갈 동기를 준다!
동기적인 부분 1번
성능 2번
두개를 다취할 수 있으면 베스트
우선 순위는 어디냐!
더 피드백
우리 서버의 Scaling 전략
서버가 Scaling이 되냐!
늘리는 기준이 뭐냐!
부하 테스트를 해야 돼 = 스트레스 테스트
성능 검증 => 1차 임계치 => 그 사용자 넘어가면 인스턴스 몇개가 돼야 해 => 이런 지표는 가져야 돼! => 하반기에 하반기 계획 중 하나다! (jmeter, ngrinder)
설문조사 정돈
-> 이벤트 개최 -> 다양 피드백 -> 우리가 MVP2 => 반영할 피드백은 이거다!
왜?
심사위원은 여러 생각이 들것이기 때문에 부정적인 피드백은 노출할 필요가 없다!
MVP2에 반영할 의사결정에 노출할 녀석만 넣자!
시스템 구성도 들으며 든 생각
MultiAZ 구성을 더 얘기할까?
ScaleOut 어떻게할 것인가요? 미리 다 생각함.
부하테스트 어떻게 할 것인가요?
굳이 더 수정하진 말고 질문 들어올 때 더 설명하자!
발표자는 감성을 판다.
들어가서 우리팀 정말로 단합이 잘 된다라는 것을 보여주자!
아이돌 인사처럼.
인사만 잘하자!
추가한다면?
하반기에 나올 우리 제품에 대한 청사진
BM에 대한 Difference 결론은 하나
=> 동접수 올릴게!
그래야 말이 맞음
=> 나머지는 우선순위상 중요하지 않다
=> 현시점에서는 이렇게 생각했는데요.. 충분히 고려하겠습니다.
결론
성능 -> BM -> 하반기 계획
셋 다 잡음
QnA
방어용 Appendix에 넣어
과거에 한 것
미래에 할 것 (질문 여지 있음)
하반기에 계획에 관련된 것
성능 검증
확장에 대한 임계치 -> 시스템 구성도
제품 막바지에 MVP2에서 API 성능 검증 -> 서버 역량의 임계치 -> 사용량 대비 적절한 인스턴스 수를 알아내겠다.
질문
하반기 계획 불분명, 적다 등
