---
# System prepended metadata

title: 201215 데일리스크럼

---

# 201215 데일리스크럼

### 오늘 할 일

- 발표 준비


원호찡 발표 스케치

소개 -> 우리가 사용한 기술 말하기 (2분) -> 데모 (2분) ( 4분++ ?? )
-> 1. SDK 부가 설명 -> 2. 서버 설명 -> Admin 설명  

1. santry 설명 길게할 필요 x 
2. 1,2,3 을 연결 하는 하나의 흐름 ?! 
3. 우리가 이번 프로젝트를 진행하면서 정했던 목표가 ~ 있었다. 이걸 
달성하기 위해서 ~~~~~ 했다~ 

4. 소개 -> 데모 -> 어떤 기술들로 구성? -> 구성하면서 있었던 고민들 -> 그 고민들을 해결하기 위한 걸 SDK -> Server -> Admin 으로 말하면 될듯
5. 
6. 기술 그래프 집중이 X , 집중하려면 
7. 데모 만들기 ~ !


원호
전체를 아울러서 설명하는 걸로 하면 4번 구성이 좋을 거 같긴함 
Q. 데모를 보여주면서 있었던 장면들을 찍어서 이렇게하면쫌~ ? ? ??? ??? 봣던 기억이 있으니까 상기되면서 저런 부분이 이/ㅅ었지?????
기술 특장점??! 무언가 관련된 그림을 가지고 와서 설명하거나?!

은빈 
SDK는 PPT 로  그려서 그냥 보여주면 될 거같다.
Server- Jest, HTTP Request ???!  (석민의 마음 알아야 함)
Server- Pm2 , mongoDB , Artillery , 

Webpack 최적화





소개
1페이지 발표자 : 안녕하십니까. 저희는 에러 모니터링 플랫폼을 만든 Santry팀입니다~ 

바로 데모부터 보여드리겠습니다~~ (15초 가량)

데모시작! 
(~2분) ( 처음켜서, 로그인하고, 새 프로젝트만들기 , IDE NPM install 하고, 코드에 init ,Setting 하고 ....  이슈화면, 이슈상세)
데모끝! 


이 서비스를 구성하는 기술스택은 다음과 같다 ( 좀더 한 눈에 들어오는 그림 ) -> 한문장 

고민 ~ 
저희는 ~ 한 고민(목표)가 있었습니다.

우선 SDK 에서는 

그리고 서버에서는 

마지막으로 Admin 에서 

~~ 

주니어개발자 석민이의 모험 (전체이용가)
Error 전송과정
- 갓석민
- SDK를 거칠때 에러정보가 가공되어 서버에 전송되는 모습을 보여줌
    - @santry/type에서 타입정의, @santry/core에서 클래스 상속등, 전략패턴을 보여줌
    - lerna를 통한 버전관리 => 만약 우리 모듈에서 버그가 발견되었으면 바로 수정후 배포하는 과정
- 서버에서는 SDK 토큰을 통해서 해당 프로젝트를 검색하고 이슈를 분류함
    - Error 토큰으로부터 verify를 통해 프로젝트 검색
    - 
- 어드민에서 해당 에러를 강조표시한 사진을 찍어서 보여줌

감사합니다~ 

혜라 
SDK - 플랫폼 쉬운 확장이 중요 
monorepo, 구조 

Server - 성능이 중요 ( 에러 양 많음 )
PM2, Artillery -----

Admin - 통계, 커뮤니티 활동 하려고 필요 
Q. 에러 그냥 CI 로 파악하면되는데 왜 Admin 페이지가 필요할까?
나의 생각 : 차트랑 커뮤니티 때문임 
왜이렇게 생각햇냐면 우리 조건에 

- 프로젝트의 멤버들에게 관련한 이슈를 할당할 수 있게끔하고 해결/작업중/미해결 과 같은 상태로 분리될 수 있게 작업.
- 모든 Issue 에는 댓글을 달 수 있게끔 작업.
-  Root 계정과 더불어 일반 사용자 계정에 권한(Owner, Member)을 분리해서 관리할 수 있도록 구성.
-  SDK 를 통해서 수집된 오류 및 로그들을 이벤트 그룹화 및 시각화해서 볼 수 있도록 제공.

이 있기 떄문임 

그래서 Admin 은 차트와 커뮤니티 기능 위주로 쓰면 되지 않을까? 하고 생각함. 


프로젝트를 진행하며 잡았던 목표 1)다양한 플랫폼에서 2)안정적으로 에러 모니터링을 해준다.

다양한 플랫폼을 지원하는 SDK가 필요했고
쏟아지는 에러 속에서 버틸 수 있는 서버가 필요했다.

1) Vanilla javascript 를 기준으로 SDK를 만들기 시작했는데 플랫폼이 확장되며 중복되는 코드가 늘어났고 구조를 잡을 필요가 있었음 -> 전략 패턴을 잘 짯다 -> 근데 배포 하려고 보니깐 기존에 npm publish 로는 하게되면은 의존성 문제가 발생한다. -> 그래서 lerna 를 이용해서 monorepo 해서 잘 관리하고 있다 . ^_^ V 
예상질문: Lerna가 뭔가요? <- 잘모르겠지만 용그림입니다 답변감사합니다.


2) 기존 마이크로 서버만을 사용했었는데 -> 더 좋은서버를 쓰고 싶었고, 그 서버의 리소스를 최대한 활용하고 싶었다. -> PM2 -> 활용을 해서 테스트를해봤다. 근데 어느날 로직을 추가해고 테스트하니깐, 갑자기 느려졌다. -> 생각을해보니 이슈를 그룹핑하는게 문제였다. -> 해결하려고 보니 트랜젝션을 써서, 순서를 맞추는 건데 그렇게 하면 처리속도가 느려진다. -> ~~아 디비설계 문제구나... 몽고디비를 그렇게 쓰면 안되는 거였구나... ㅠ_ㅠ~~ DB 설계를 관계형으로 했을경우 이런 문제가 발생하는구나. Join이 나오긴 했지만 관계형으로 설계할 경우 이러이러한 단점이 있습니다.

3) 프론트 테스트를 포기해야하나
