마소콘(MASOCON) 2018 세션 내용 요약 정리

Session 1. 올바른 데이터 시각화와 탐색적 부석 도구를 찾아서 

서버 관점에서의 데이터

• 무수히 많은 트랜잭션을 표현하는 좋은지표 찾기
  • 평균 응답시간에 주의
    • 평균 값은 노멀했지만 사실 특정 시점에 문제가 있었을 수 있다
    • 백분위도 정확하지 않은 것은 마찬가지
  • 수많은 APM이 분포도를 사용
• 운영 곤점에서는 수많은 서버들 중 어떤 서버에 지연이 발생했는지 파악하는 것에 관심
  • 서버간의 관계
  • 지연시간

블록체인에서의 데이터

• 블록을 일정 시간마다 예전것부터 차례차례 가져옴
• ETL을 위해 Fluentd로 데이터 수집해서 엘라스틱서치, RDB, 하둡에 저장
  • 엘라스틱스택은 굉장히 단순한 구조로 사용

돈 버는 시각화를 위한 데이터 플랫폼

• 흐름 따라 데이터를 파악하기에는 엘라스틱스택이 적합하지만 그룹핑이나 데이터를 여러 방면으로 조합해서 보기에는 적합하지 않은 듯
• 비정형/정형/반정형 데이터 상관없이 분석할 수 있는 플랫폼을 만드는 것이 목표
• 데이터를 수집하는 커넥터들이 무수히 많은데 모든 커넥터를 만들 수는 없음
  • 로그스태시, fluentd, filebeat 등등
• 실시간 데이터와 CRM데이터를 결합하기 위해서는 키 기반의 연관성이 필요
• 시각화
  • 차트, 대시보드를 그리는 것만 중요한 것이 아니라 사소한 UI, UX에도 신경 써야함
    • 기존의 기능들을 어떻게 쉽게 잘 쓰도록 할 수 있을까를 고민
  • 원천이 되는 데이터들에 대한 고려
    • 정말 필요한 지표인가?
      • 단순 UV가 아닌 어떠한 이유로 UV가 하락했는지를 판단하기 위해서는 더 많은 지표가 필요
  • 시각화된 차트가 나오기까지의 전처리/분석 고려
    • 전처리가 나을지 후처리가 나을지 분석 설계
    • 자유도와 정합성을 동시에 만족 시킬 수 있는가 (가장 어려움)
  • 시각화 구현 자체의 고려
    • 쿼리의 복잡도
    • 필터링
  • 모니터링과 EDA는 명확한 차이가 있음
    • 차이를 혼돈하지 않는 것이 중요
  • 시각화는 개발이 끝났다고 안주하면 안됨. 다른 시각에서, 다른 더 유용한 차트를 만들기 위해서 끊임 없이 노력해야 발전하고 돈을 벌 수 있음

패널토론

• 각 구축 단계에서 고민 또는 준비해야할 것들은?
  • 어떤 데이터를 어떻게 수집할지 정하는 것이 중요
  • 데이터간의 연관성
  • 필요한 데이터만 수집하기 위해 정형화
  • 전문가들이 고객에게 어떠한 뷰를 보여줄지를 먼저 계획하고 설계
    • 시각화 요소들을 결정 후 개발 가능 여부를 판단
    • APM의 경우 개발하는 사람들의 여러 패턴들을 모두 수용할 수 있는 어플리케이션을 만드는 것이 어려웠음
      • 개발자의 입장에서 생각했던 도구에서 운영자의 입장에서 생각하는 도구로 관점 전환 중
  • 도구를 선택할 때 특정 기능에 특화된 도구를 원하는지, 아니면 범용적인 도구를 원하는지를 잘 파악해야함
• 시각화 도구
  • 서버/데브옵스/운영자들간의 원하는 시각화 도구가 다름
    • 시각화 도구에 대한 리서치를 충분히 해야 분야별 대응이 가능
  • 기본 시작은 오픈소스로 할 수 있겠지만 오픈소스의 커뮤니티 성향이나 회사의 방향성에 따라 다르기 때문에 자신의 서비스와 맞지 않을 수 있음
    • 결국에는 오픈 소스 기반에서 자체 개발로 전환하게 됨
• 모델링이 먼저인가? 아니면 수집이 먼저인가?
• 모델링을 할 수 있는 인재가 있으면 탐다운 방식으로 진행하는 것이 베스트
• 인재가 없으면 일단 데이터를 수집하는 것이 중요
• 조직에서 의사결정을 내리는데 중요한 키워드나 지표들을 파악한 후에 조직에 필요한 데이터를 모델링
• 어떤 것을 모델링 해야할지 모를 때는 조직을 먼저 관찰하는 것이 좋을 듯

Session 2. 글쓰는 개발자

글쓰는 목적

• 내적 동기가 꾸준함을 만들기 떄문에
• 약간의 강제성이 발전에 도움이 됨
  • 독서 모임에서 독후감을 쓰도록 강제
• 슬럼프를 이겨내기 위해 일기 쓰기 시작
  • 평소 생각, 스쳐지나가는 이야기들
  • 감정, 느낀점 등
• 업무에서 글쓰기 능력이 많은 도움이 됨
  • 메일, 보고서 등

글쓰기와 코딩의 상관관계

• 글쓰기 능력이 수반되어야 코딩을 짤때도 깔끔하고 논리있게 작성할 수 있다.
• 다른 사람의 코드를 봤을 떄 그 사람의 스타일이나 성향을 파악할 수 있는 것 처럼 글의 문체나 글의 내용에 따라 그 사람의 인생이나 경험을 단편적으로나마 볼 수 있다.
  • 자신의 경험을 기술하는 측면에서 코딩과 글쓰기는 유사한 것 같다.

개발자와 블로그

• 강연자 : 우아한형제들 이동욱

• 티스토리 유료 스킨 사용 중

• 티스토리 댓글 너무 구림

  • 티스토리 댓글 API 이용해서 utterance 댓글로 마이그레이션

• 일일커밋

  • 코딩 + 글

마크다운 포스팅

• 티스토리 에디터 너무 구림
  • 생산성이 떨어짐
• markdown-tistory 제작
  • Jojoldu/markdown-tistory
• VSCode로 마크다운 파일로 제작 후 변환

글쓰기에서 책쓰기까지

• 강연자 : 유동환
• 블로그에 글쓰면서
  • 의식적인 글쓰기
  • 흥미로운 제목 만들기
  • 쉬운 글쓰기
  • 연말 회고

일기를 쓰는 이유

• 강연자 : 아이펀팩토리 이기곤
• 삶의 의미를 찾기 위한 목표
  • 삶을 스프린트 단위로 관리해보자
    • 일기 쓰기
• 일기
  • 직장 / 출퇴근시 / 개인적인 일을 일기로 쓰기

글쓰기가 어렵기만 한 개발자에게

• 강연자 : 트레바리 정원희
• 잘쓴 글
  • 문장이 유려하거나 멋진 것보다는 읽기 쉽고 이해가 잘되는 글
• 개발자도 글을 잘써야 한다고 생각
  • 코딩도 글
  • 궁극적으로 코드는 요구사항을 표현하는 언어 - 로버트 C 마틴
  • 글 잘쓰는 사람의 코드는 간결하고 논리정연
• 개발자도 글을 쓰며 일함
  • 커밋 메시지
  • 코드 리뷰
• 개발자도 글을 잘 쓸 수 있을까?
  • 개발자들은 간결하고 읽기 쉬운 코드를 고민한다.
    • 글도 읽기 쉬워야한다.
  • 리팩토링을 통해 코드를 다듬고 다듬는다.
    • 글도 마찬가지로 다듬는 작업을 반복
  • 다른 사람 코드를 유심히 읽으며 배운다.
    • 오픈소스나 동료 코드를 보며 배우려 노력한다.
    • 글쓰기도 다른 사람의 글쓰기에서 어휘나 단어 선택을 유심히 보고 배운다.
  • 상호 피드백을 통해 더 나은 코드가 된다는 사실을 안다
    • 코드 리뷰를 통해 서로의 코드에서 배운다.
    • 다른 직종보다 다른 사람이 피드백 주는 것에 거부감이 덜하다.
• 혼자 하면 오래 걸리고 힘듬
  • Github과 같은 지식 공유

개기자의 글쓰기

• 강연자 : 마이크로소프트웨어 오세용 기자
• 서평쓰기
• 블로그 운영
  • 칼럼 쓰기
    • 스타트업 창업하면서 느낀 것들
• 사색노트
  • 일기처럼 아무 생각이나 글로 표현
  • 글쓰기는 나를 보기 위함
  • 상세히 작성하다보면 원인을 발견하게 됨

Session3. SW 품질프로세스로 보는 SI 프로젝트의 기술부채

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

Session4. 더 웨더 컴퍼니에서의 데브옵스

• 강연자 : 조지훈
  • chj2339@naver.com

일반적인 데브옵스

• 데브옵스 란
  • 개발 방법론은 아니라고 생각함
  • 개발 라이프사이클을 단축 시키는 것이 목표
  • 빨리 더 자주 고객들을 위해 서비스를 업데이트
  • 비즈니스 목표와 연관이 되어야함
• 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등의 서비스 연계

Session5. 기술 부채의 늪 탈출기

• 강연자 : 허진수 럭스로보

• 이슈 관리

  • 컨플루언스
  • 지라

• 데일리 스탠드업 미팅

  • 오프라인에서 안하고 슬랙에서 미팅
  • 어제한일/오늘할일/불편한점

• 깃

  • 깃랩 사용
  • Git Flow 사용
    • 팀에 맞는 규칙으로 변형해서 사용
    • master/develop 브랜치는 언제든 릴리즈 될 수 있는 브랜치이기 때문에 엄격하게 관리
      • GitLab MR을 거쳐야만 머지
      • GitLab MR 요청 시에는 요청 내용에 대해 상세히 작성하도록 강제
      • 요청 내용이 명확해야 코드리뷰를 하는 사람이 편함
      • 진행 상황에 대해서는 커뮤니케이션을 줄이기 위해 이모티콘에 의미 부여해서 사용

• 코드 리뷰

  • 자질구레한 것들에 집중하는 것을 피해야함
  • 각 줄의 실수를 잡아내는 것이 아님
  • 전체적인 큰 그림 파악과 방향성 검토

• CI/CD

  • Jenkins
    • 코드 커밋이 발생하면 빌드 수행해서 오류가 없는지 파악
    • GitLab MR이 열리면 코드를 머지해서 오류가 없는지 파악
    • 태그를 붙여서 자동 릴리즈 수행 (tag-push)
    • Jenkins Pipeline 사용