본문 바로가기
Work/Conference

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

by ★용호★ 2018. 12. 17.






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. 더 웨더 컴퍼니에서의 데브옵스

일반적인 데브옵스

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


댓글