2018 마소콘 세션 내용 정리

md/Seminar/2018마소콘_SI기술부채.md

@@ -0,0 +1,26 @@
+# SW 품질프로세스로 보는 SI 프로젝트의 기술부채
+
+* 분석/설계의 부재 = 시간의 부재
+  * 기획 단계에서 요구사항 분석을 자세히 해야 함
+* SI에서도 최근 코드 품질에 관심이 높아짐
+  * 컨벤션 체크 -> 코드 품질 검사 -> 눈으로 확인
+* 개발 시작 단계가 가장 중요하다고 생각
+  * 분석/설계 과정이 중요하기 때문에 3~4개월은 분석/설계 기간을 할당
+  * 하지만 산출물 만들기에 급급해서 깊게 고민한 설계 문서가 아님
+* 산출물의 의미를 잘 생각하자
+  * 무언가를 이해하고 그려내고 서내려가는 과정에서의 고민의 결과
+  * 보여주기 식의 의미없는 문서는 안됨
+  * 그림으로 그려볼 수 있다는 것은 시스템에 대한 이해가 있다는 의미
+* 기술 부채를 제거하기 위해 해야할 일
+  * 분석 단계
+    * 요구분석 단계에서 프로젝트 구성원들이 같이 읽어보고 고민하는 시간을 많이 갖기
+    * 대화 많이 하기
+    * 코드 품질 올리기
+  * 설계 단계
+    * 구현을 할 수 있는 묘사를 할 수 있어야 함
+    * 화면 설계 -> 프로그램 설계 -> 데이터베이스 설계
+  * 개발 단계
+    * 진척률 관리의 맹점 확인
+    * 모든 구성원이 프로젝트에 관심을 가져야함
+    * 기획이 없어서 못했든 QA가 없어서 버그가 발생했든 모든 구성원의 협업이 이루어지지 않았기 때문에 발생한다고 생각
+    * 개발 -> 테스트 -> 결함관리

md/Seminar/2018마소콘_글쓰는개발자.md

@@ -0,0 +1,103 @@
+# 글쓰는 개발자
+
+## 글쓰는 목적
+
+* 내적 동기가 꾸준함을 만들기 떄문에
+* 약간의 강제성이 발전에 도움이 됨
+  * 독서 모임에서 독후감을 쓰도록 강제
+* 슬럼프를 이겨내기 위해 일기 쓰기 시작
+  * 평소 생각, 스쳐지나가는 이야기들
+  * 감정, 느낀점 등
+* 업무에서 글쓰기 능력이 많은 도움이 됨
+  * 메일, 보고서 등
+
+
+
+## 글쓰기와 코딩의 상관관계
+
+* 글쓰기 능력이 수반되어야 코딩을 짤때도 깔끔하고 논리있게 작성할 수 있다.
+* 다른 사람의 코드를 봤을 떄 그 사람의 스타일이나 성향을 파악할 수 있는 것 처럼 글의 문체나 글의 내용에 따라 그 사람의 인생이나 경험을 단편적으로나마 볼 수 있다.
+  * 자신의 경험을 기술하는 측면에서 코딩과 글쓰기는 유사한 것 같다.
+
+
+
+##개발자와 블로그
+
+* 강연자 : 우아한형제들 이동욱
+* 티스토리 유료 스킨
+
+* 티스토리 댓글 너무 구림
+  * 티스토리 댓글 API 이용해서  utterance 댓글로 마이그레이션
+* 일일커밋
+  * 코딩 + 글
+* 마크다운 포스팅
+  * 티스토리 에디터 너무 구림
+    * 생산성이 떨어짐
+  * markdown-tistory 제작
+    * Jojoldu/markdown-tistory
+  * VSCode로 마크다운 파일로 제작 후 변환
+
+
+
+## 글쓰기에서 책쓰기까지
+
+* 강연자 : 유동환
+* 블로그에 글쓰면서
+  * 의식적인 글쓰기
+  * 흥미로운 제목 만들기
+  * 쉬운 글쓰기
+  * 연말 회고
+
+
+
+## 일기를 쓰는 이유
+
+* 강연자 : 아이펀팩토리 이기곤
+* 삶의 의미를 찾기 위한 목표
+  * 삶을 스프린트 단위로 관리해보자
+    * 일기 쓰기
+* 일기
+  * 직장 / 출퇴근시 / 개인적인 일을 일기로 쓰기
+
+
+
+## 글쓰기가 어렵기만 한 개발자에게
+
+* 강연자 : 트레바리 정원희
+* 잘쓴 글
+  * 문장이 유려하거나 멋진 것보다는 읽기 쉽고 이해가 잘되는 글
+* 개발자도 글을 잘써야 한다고 생각
+  * 코딩도 글
+  * 궁극적으로 코드는 요구사항을 표현하는 언어 - 로버트 C 마틴
+  * 글 잘쓰는 사람의 코드는 간결하고 논리정연
+* 개발자도 글을 쓰며 일함
+  * 커밋 메시지
+  * 코드 리뷰
+* 개발자도 글을 잘 쓸 수 있을까?
+  * 개발자들은 간결하고 읽기 쉬운 코드를 고민한다.
+    * 글도 읽기 쉬워야한다.
+  * 리팩토링을 통해 코드를 다듬고 다듬는다.
+    * 글도 마찬가지로 다듬는 작업을 반복
+  * 다른 사람 코드를 유심히 읽으며 배운다.
+    * 오픈소스나 동료 코드를 보며 배우려 노력한다.
+    * 글쓰기도 다른 사람의 글쓰기에서 어휘나 단어 선택을 유심히 보고 배운다.
+  * 상호 피드백을 통해 더 나은 코드가 된다는 사실을 안다
+    * 코드 리뷰를 통해 서로의 코드에서 배운다.
+    * 다른 직종보다 다른 사람이 피드백 주는 것에 거부감이 덜하다.
+* 혼자 하면 오래 걸리고 힘듬
+  * Github과 같은 지식 공유
+
+
+
+## 개기자의 글쓰기
+
+* 강연자 : 마이크로소프트웨어 오세용 기자
+* 서평쓰기
+* 블로그 운영
+  * 칼럼 쓰기
+    * 스타트업 창업하면서 느낀 것들
+* 사색노트
+  * 일기처럼 아무 생각이나 글로 표현
+  * 글쓰기는 나를 보기 위함
+  * 상세히 작성하다보면 원인을 발견하게 됨
+

md/Seminar/2018마소콘_기술부채의늪탈출기.md

@@ -0,0 +1,29 @@
+# 기술 부채의 늪 탈출기
+
+* 강연자 : 허진수 럭스로보
+* 이슈 관리
+  * 컨플루언스
+  * 지라
+* 데일리 스탠드업 미팅
+  * 오프라인에서 안하고 슬랙에서 미팅
+  * 어제한일/오늘할일/불편한점
+* 깃
+  * 깃랩 사용
+  * Git Flow 사용
+    * 팀에 맞는 규칙으로 변형해서 사용
+    * master/develop 브랜치는 언제든 릴리즈 될 수 있는 브랜치이기 때문에 엄격하게 관리
+      * GitLab MR을 거쳐야만 머지 
+      * GitLab MR 요청 시에는 요청 내용에 대해 상세히 작성하도록 강제
+      * 요청 내용이 명확해야 코드리뷰를 하는 사람이 편함
+      * 진행 상황에 대해서는 커뮤니케이션을 줄이기 위해 이모티콘에 의미 부여해서 사용
+* 코드 리뷰
+  * 자질구레한 것들에 집중하는 것을 피해야함
+  * 각 줄의 실수를 잡아내는 것이 아님
+  * 전체적인 큰 그림 파악과 방향성 검토
+
+* CI/CD
+  * Jenkins
+    * 코드 커밋이 발생하면 빌드 수행해서 오류가 없는지 파악
+    * GitLab MR이 열리면 코드를 머지해서 오류가 없는지 파악
+    * 태그를 붙여서 자동 릴리즈 수행 (tag-push) 
+    * Jenkins Pipeline 사용

md/Seminar/2018마소콘_더웨더컴퍼니_데브옵스.md

@@ -0,0 +1,94 @@
+# 더 웨더 컴퍼니에서의 데브옵스
+
+* 강연자 : 조지훈
+  * [email protected]
+
+
+
+## 일반적인 데브옵스
+
+* 데브옵스 란
+  * 개발 방법론은 아니라고 생각함
+  * 개발 라이프사이클을 단축 시키는 것이 목표
+  * 빨리 더 자주 고객들을 위해 서비스를 업데이트
+  * 비즈니스 목표와 연관이 되어야함
+* CAMS (데브옵스를 바라보는 관점)
+  * Culture
+    * 문화가 가장 중요하다고 생각
+    * 사일로의 해체
+      * 개발/테스트/기획 하는 조직이 명확하게 구분이 되어 있는 것을 타파하고자 하는 것이 데브옵스의 문화
+      * 명확히 구분되어 있으면 커뮤니케이션이 단절됨
+      * 문화적인 요소는 가장 관계가 크다고 생각
+    * 리더십의 지원
+      * 각 조직의 분리를 합하려면 리더십의 지원이 필요
+    * 비즈니스 목표가 공통된 목표
+    * 조직의 구조
+  * Automation
+    * 인프라에서 서비스까지 모든 것을 자동화
+    * 라이프 사이클의 각 단계를 파이프라인화
+    * 도구도 팀과 협업 문화가 기반이 된 상태여야 퍼포먼스를 낼 수 있음
+    * 실수를 최소화
+  * Measurement
+    * 시스템 모니터링
+    * 시스템 로그
+    * 사용자의 피드백
+    * 라이프 사이클 주기
+  * Sharing
+    * 지식과 경험의 공유
+      * 공유가 잘 이루어지면 앞의 세가지 모두 개선될 확률이 높아짐
+    * 자유로운 접근
+    * 사일로의 탈피
+    * 리더십의 지원
+
+
+
+## 더 웨더 컴퍼니의 데브옵스
+
+* 릴리즈 주기
+  * 애자일 방식으로 개발 진행
+    * 스프린트, 스크럽, 코드 리뷰
+  * 2주 단위로 릴리즈 수행 (스프린트 단위)
+    * 신규 API는 충분한 품질 점검 과정을 거쳐 릴리즈 수행
+    * 개발팀 단위로 업무 시간 내 다운타임 없이 릴리즈 수행
+* Culture
+  * 데브옵스 엔지니어의 업무는 대부분 옵스에 해당
+    * 옵스 업무를 자동화 하기 위해 개발
+    * 데브옵스와 데브옵스 엔지니어는 개념이 다름
+  * 팀 구성
+    * 팀 리더 : 프로젝트 총괄
+    * 세일즈 엔지니어링 : 고객 상대
+    * 개발팀(애자일 스프린트 팀 - 6~8명으로 구성)
+      * 프로덕트 오너 : 개발팀 총괄
+        * 리드 디벨로퍼 : 스크럼 마스터
+        * 디벨로퍼 : 3~4명
+        * QA : 1 ~2명
+        * DevOps Engineer : 1명
+  * 커뮤니케이션
+    * 슬랙
+      * 언제든지 대화에 참여해서 함께 토론
+      * 커뮤니케이션 비용이 낮아짐
+      * 리모트 업무 특성상 시차가 발생하여 커뮤니케이션이 어려운데 히스토리가 남기 때문에 대화가 이어짐
+      * 굉장히 중요한 역할 수행하고 있음
+  * 리더십
+    * 사일로간의 벽을 허무는데 중요한 역할자
+    * 조직간 협업 지원
+  * 작은 변화와 많은 릴리즈
+    * 릴리즈 배포 주기를 짧게함
+    * 롤백이 쉬움
+* Automation
+  * Terraform
+  * Chef
+  * Docker와 Kubernetes를 도입하게 되면 Terraform이나 Chef의 역할이 줄어들기 때문에 시스템 구성을 조정 할 필요가 있음
+* Measurement
+  * 모니터링
+    * Datadog
+  * 알람
+    * pagerduty
+* Sharing
+  * 슬랙
+    * 메신저
+    * 화상회의
+    * 자료공유
+    * 히스토리
+    * 주제별 채널
+    * DataDog, PagerDuty등의 서비스 연계

md/Seminar/2018마소콘_데이터분석.md

@@ -0,0 +1,68 @@
+## 서버 관점에서의 데이터
+
+* 무수히 많은 트랜잭션을 표현하는 좋은지표 찾기
+  * 평균 응답시간에 주의
+    * 평균 값은 노멀했지만 사실 특정 시점에 문제가 있었을 수 있다
+    * 백분위도 정확하지 않은 것은 마찬가지
+  * 수많은 APM이 분포도를 사용
+* 운영 곤점에서는 수많은 서버들 중 어떤 서버에 지연이 발생했는지 파악하는 것에 관심
+  * 서버간의 관계
+  * 지연시간
+
+
+
+## 블록체인에서의 데이터
+
+* 블록을 일정 시간마다 예전것부터 차례차례 가져옴
+* ETL을 위해 Fluentd로 데이터 수집해서 엘라스틱서치, RDB, 하둡에 저장
+  * 엘라스틱스택은 굉장히 단순한 구조로 사용
+
+
+
+## 돈 버는 시각화를 위한 데이터 플랫폼
+
+- 흐름 따라 데이터를 파악하기에는 엘라스틱스택이 적합하지만 그룹핑이나 데이터를 여러 방면으로 조합해서 보기에는 적합하지 않은 듯
+- 비정형/정형/반정형 데이터 상관없이 분석할 수 있는 플랫폼을 만드는 것이 목표
+- 데이터를 수집하는 커넥터들이 무수히 많은데 모든 커넥터를 만들 수는 없음
+  - 로그스태시, fluentd, filebeat 등등
+- 실시간 데이터와 CRM데이터를 결합하기 위해서는 키 기반의 연관성이 필요
+- 시각화
+  - 차트, 대시보드를 그리는 것만 중요한 것이 아니라 사소한 UI, UX에도 신경 써야함
+    - 기존의 기능들을 어떻게 쉽게 잘 쓰도록 할 수 있을까를 고민
+  - 원천이 되는 데이터들에 대한 고려
+    - 정말 필요한 지표인가?
+      - 단순 UV가 아닌 어떠한 이유로 UV가 하락했는지를 판단하기 위해서는 더 많은 지표가 필요
+  - 시각화된 차트가 나오기까지의 전처리/분석 고려
+    - 전처리가 나을지 후처리가 나을지 분석 설계
+    - 자유도와 정합성을 동시에 만족 시킬 수 있는가 (가장 어려움)
+  - 시각화 구현 자체의 고려
+    - 쿼리의 복잡도
+    - 필터링
+  - 모니터링과 EDA는 명확한 차이가 있음
+    - 차이를 혼돈하지 않는 것이 중요
+  - 시각화는 개발이 끝났다고 안주하면 안됨. 다른 시각에서, 다른 더 유용한 차트를 만들기 위해서 끊임 없이 노력해야 발전하고 돈을 벌 수 있음
+
+
+
+## 패널토론
+
+* 각 구축 단계에서 고민 또는 준비해야할 것들은?
+  * 어떤 데이터를 어떻게 수집할지 정하는 것이 중요
+  * 데이터간의 연관성
+  * 필요한 데이터만 수집하기 위해 정형화
+  * 전문가들이 고객에게 어떠한 뷰를 보여줄지를 먼저 계획하고 설계
+    * 시각화 요소들을 결정 후 개발 가능 여부를 판단
+    * APM의 경우 개발하는 사람들의 여러 패턴들을 모두 수용할 수 있는 어플리케이션을 만드는 것이 어려웠음
+      * 개발자의 입장에서 생각했던 도구에서 운영자의 입장에서 생각하는 도구로 관점 전환 중
+  * 도구를 선택할 때 특정 기능에 특화된 도구를 원하는지, 아니면 범용적인 도구를 원하는지를  잘 파악해야함
+* 시각화 도구
+  * 서버/데브옵스/운영자들간의 원하는 시각화 도구가 다름
+    * 시각화 도구에 대한 리서치를 충분히 해야 분야별 대응이 가능
+  * 기본 시작은 오픈소스로 할 수 있겠지만 오픈소스의 커뮤니티 성향이나 회사의 방향성에 따라 다르기 때문에 자신의 서비스와 맞지 않을 수 있음
+    * 결국에는 오픈 소스 기반에서 자체 개발로 전환하게 됨
+* 모델링이 먼저인가? 아니면 수집이 먼저인가?
+  * 모델링을 할 수 있는 인재가 있으면 탐다운 방식으로 진행하는 것이 베스트
+  * 인재가 없으면 일단 데이터를 수집하는 것이 중요
+  * 조직에서 의사결정을 내리는데 중요한 키워드나 지표들을 파악한 후에 조직에 필요한 데이터를 모델링
+    * 어떤 것을 모델링 해야할지 모를 때는 조직을 먼저 관찰하는 것이 좋을 듯
+