OKKYCON 2017 참석 후기

세미나·2017.12.18 19:06

대문

OKKYCON 2017에 다녀왔습니다!
세미나 순서와 연사분들의 소개는 OKKYCON페이지에서 상세하게 확인하실 수 있습니다.

눈이 굉장히 많이와 사람들이 오실수있으실까 싶었는데 정말 많은 분들이 와주셔서 깜짝 놀랬습니다.

0

믿음님의 기조 연설로 세미나가 시작되었습니다!
개발자의 커뮤니케이션과 협업에 대한 이야기가 진행될 예정입니다.
리뷰 작성하고나니 엄청난 스크롤 압박을 보고..
바로 본문으로 진행하겠습니다.
유익한 글이 되셨으면 좋겠습니다^^;

1. Extreme Programming(XP), 더 나은 소프트웨어 품질을 위한 일의 방법 - 정윤진 (Pivotal)

1

피보탈?

  • Apache Tomcat의 코드를 70% 이상을 작성
  • 스프링프레임워크 개발자들 전체가 소속
  • 기타 여러 오픈소스를 개발/배포 하는 오픈소스 회사

소프트웨어 전문, 오픈소스 전문 회사인 피보탈에서 어떻게 협업을 하는지에 대한 이야기

Extreme Programming?

  • 비지니스 오너 혹은 은행장 등의 분들이 오히려 API에 대한 요구사항이 높아짐
  • 문제는 이런 API 형태로 전환하기 위한 필요한 기술, 이런 기술을 구현하는 사람들이 협업에 필요한 문화는 전과 완전히 다름
  • 문제는 이런 요구에 대한 제대로된 문화가 잘 없음
    • 구글의 문화를 은행에서 바로 적용할수 있는건 아님
  • Agile, Lean, 12 factor, Cloud Native, DevOps, Micro Services, CI/CD
    • 이런 내용들을 안다고 해서 바로 적용할 수가 없음
    • 피보탈에선 이 모든 것을 전부 프로덕션으로 가기 위한것
    • It's all about Production
  • Agile
    • 개발에서 배포까지 수행하고 피드백을 받는 동작을 반복하는 것
    • 개발한 코드를 어떻게 지속적으로 프로덕션에 전송할 수 있을까
    • 코드가 계속 커지는 상황에서도 어떻게 그 속도를 유지할 것인가
  • Lean
    • 이 Core Feedback Loop를 "사용자가 원하는 방향으로" 진행하는 것

A Product Story

  • Small Sized / Cross Function Team
    • 풀스택 개발자는 거의 존재하지 않으며, 있다 하더라도 여러분이 데려오기엔 너무나 힘든 존재
    • 다만, 팀이 풀스택이 될 수 있다고 생각함

2011년 백엔드/프론트엔드/인프라 각각 1명씩으로 이루어진 팀에서 근무 (+ 사장님 1명)했던 이야기

  • 커스텀 소프트웨어를 만들기로 함
    • 드랍박스, AWS WorkDocs와 비슷한 클라우드 소프트웨어
    • 프론트엔드 개발자분이 4시간만에 Mock 소프트웨어를 만들어서 사장님 앞에서 발표
    • 발표현장에서 사장님이 바로바로 피드백을 줌
    • 기획서를 보고 감으로만 하는게 아니라, 실제 눈앞에서 기능을 보면서 바로바로 피드백을 주니 기획이 좀 더 명확하게 진행됨
  • 서비스 구조
    • 클라이언트 요청 -> nodejs 서버 -> mongodb에 사용자정보/버켓정보 등록, 오픈스택 스위프트에 파일등록
  • 해당 서비스 개발에 대한 상세한 이야기
  • N(N-1) / 2
    • 필요한 커뮤니케이션의 횟수
    • 똑같은 이야기를 계속 반복하지 않아도 됨
    • 개발을 하는 시간보다 미팅을 하는 시간이 많아지는 경우가 발생
    • 우리 같은 경우 개발자는 3명이기 때문에 커뮤니케이션 리소스 비용이 굉장히 절약
    • nodejs 파일 전송이 느린점을 개선하기 위해 오전에 회의하고 오후에 바로 적용
    • 앞단에서 Nginx를 두어서 Nodejs로 갈 request와 오픈스택 스위프트로 갈 request를 분기처리
  • 굳이 스크럼을 하지 않더라도, 소규모 인원에선 자연스레 비슷하게 진행됨
    • 실제로 우리팀은 애자일 방법론에 대한 지식이 전무한 상태였지만, 지금 생각해보면 애자일과 유사했음

우리의 문제

대부분의 서비스에서 발생하는 문제

  • 데이터복제/백업 없음
    • 환경 구축이 제대로 되기 전에 사용자 트래픽이 발생
  • 오픈스택의 빠른 발전으로 API문서가 실제 서비스와 일치하지 않음
    • 실제로 문서보다 코드보는게 더 나을때가 많음
  • 개발/스테이징/프로덕션 개념 없음
    • 시작부터 오픈까지 3개월만에 완료
  • 배포전 테스트 없음 / 테스트 코드 작성 없음

시작하는 서비스에서 발생하는 문제

  • 프로덕션에 마구 접속 및 변경을 감행
  • 개성이 강한 멤버들의 성격이 자주 충돌
    • 좋을땐 되게 잘되지만, 충돌할땐 답이 없음
    • 3명이 돌아가며 골고루 스트레스 받다보니 3명다 이야기를 하지 않는 상황도 발생
  • 서비스가 커지고, 베타로 인해 실 사용자가 발생함에 따라 배포속도가 떨어짐
    • 점점 더 제품화 하는데 시간이 걸리기 시작

위 경험에서 얻은 교훈

  • 일을 진행하는데 작은 규모의 팀은 매우 효율적
  • 서로 다른 전문성을 가진 사람들이 팀을 이루면 어려운 문제를 해결 할 수 있다.
  • 자신이 당면한 문제를 즉각 공유해야 해결이 빠르다
  • 팀 구성원의 성향이 다르면 감정적 문제가 걷잡을 수 없이 커지는 경향이 있다.
  • 스타트업은 제품이 나빠서가 아니라, 보통 팀이 깨져서 무너진다.
    • 하다보면 1명이 팀 배포코드의 50%이상을 담당하는 경우가 있음
    • 자연스레 결과물에 대한 공유가 잘 안되는경우가 많음

Extreme Programming

  • 코드의 크기가 커질수록 프로덕션 배포는 점점 느려지게 됨
    • 이를 해결하기 위해 Test 코드가 필요
  • 일정 규모 이상이 되면 테스트 작성을 포기
    • => 애자일은 작은 신규 프로젝트에서만 가능 이라고 생각하는분들이 많음
  • 수천줄의 코드 -> 백만줄의 코드로 늘어나면서 발생할수 있는 문제
    • 업데이트에 무슨 문제가 발생할지 아무도 모름
    • 책임/롤백계획서/업데이트해야하나?/QA통과함? 등에 대한 이유로 다들 꺼리기 시작함
    • 팀에 속해 있지만, 개발은 결국 혼자하게 됨
    • XP에선 혼자서 코드를 잘못 생성하는 경우를 만들지 않도록 함

피보탈의 업무패턴

  • 08:30 아침식사
    • 아침밥 먹으면서 서로 이야기하라고 만든 시간
    • 메일을 쓰지 않음
    • 아침식사시간에 공유할 내용을 전달
  • 09:00 스탠딩 미팅
    • 모든 팀이 함께하는 스탠딩 미팅
  • 09:05 팀 스탠드 미팅
    • 오늘 내가 누구랑 일할지, 어떤 일을 할지 이야기함
  • 09:30 Pair 업무 시작
    • 해당 부분을 잘하는 사람과 Pair를 구성
    • 실리콘벨리의 높은 연봉의 개발자들을 1명씩 일을 시키지 않고, 같이 일을 시키는 이유
    • 2명이 같이 일하면 품질이 80%이상 올라감
  • 11:30 점심식사
  • 13:00 오후 Pair 업무 시작
  • 18:00 아무도 없음

Balanced Team

DB팀, 서버개발팀, 인프라팀, 프론트엔드 팀 등의 서로 다른 스택을 가진 팀의 구성원들 중 프로덕트를 위해 별도의 팀을 구성

  • 서로에 대한 신뢰가 쌓임
    • 내가 못하는 것을 잘함
  • 내가 DB를 잘 못했지만, 팀원들로 인해 배우게 되는 등 몰랐던 점들을 많이 배우게 됨
  • 서로 다양한 목소리가 나옴
  • 프로덕트 매니저 & 개발자가 한 PC로 개발을 하는 상황도 종종 보게 됨
    • 모니터2, 키보드2, 마우스2로 구성

TDD in Pivotal

  • 모든 행동은 테스트로 코딩 되어야 함
    • 모든 행위는 테스트 코드가 있어야 함
  • TDD를 하는 이유는 프로덕션 배포를 위함
  • QA팀을 두지 않는 이유?
    • QA팀을 통해 테스트를 할경우 문제 발견시 다시 개발팀에게 전달
    • 개발팀은 이미 새로운 서비스/기능을 개발중에 다시 버그수정
    • 이런 일이 반복될수록 배포가 점점 늦어지게 됨
  • 30분 ~ 3시간안에 완료될 단위로 이슈를 쪼개서 개발/배포

피보탈에서 배운 교훈

  • 옆자리에 앉은 사람이 코드/테스트를 작성하는 걸 보고 있으면 혼이 나간다
  • 프로덕트 팀을 작게 유지하며 페어로 일하는 것은 "다양한 장점이 있다"
  • 두명의 개발자가 앉으면 생선성은 20% 감소하지만, 품질은 80% 증가한다
    • SI에서 특히 인건비에 대한 질문을 정말 많이들 하심
    • 생산성이 높다고 해서 코드의 안정성이 높다고 할순 없음
  • 서로 다른 역할의 구성원이 페어로 일하게 되면 다양한 문제 해결이 가능하다
    • 디자인 & 백엔드 개발자가 같이 일하는 경우가 빈번함
  • 팀이 지속적으로 상향 평준화 된다
  • "답장 없는 매일 보다는 대화가 더 효율적인 방법이다"
    • 내가 찾으면 알수있는 것을 질문으로 들고가면 혼남

스프링부트의 수장 필 웹이 한말

  • 코드를 제품으로서 높은 품질로 제공
  • 변화하는 환경에 적응하도록 코드를 작성하라
  • 미래에 변경이 쉽도록 코드를 작성해야 한다
  • 한줄의 추가 코드는 한줄의 추가 메인터넌스

애자일은 1년 걸릴 프로젝트를 1달만에 만드는 방법론이 아님

Q & A

Q. 메일 보다는 대화를 하라고 했는데, 상황에 따라 당사자가 이해를 못할 경우가 많은데, 이럴때 계속 대화하기 보다는 메일로 남기는게 더 좋을것같은데 어떤지?
(누군가 반복적으로 잘못된 질문을 하는것을 방지하기 위해 메일을 남기는게 어떤지?)

  • 팀내 구성원이 8명정도인데 그 구성원들은 팀 프로덕트에 대한 내용은 구성원이 거의다 알고 있음
    • 본인의 내용만 알고 있는 사람은 거의 없음
  • 소프트웨어 회사이다보니 자주되는 질문은 이슈트래커, 코드를 통해 확인할 수 있도록 구성함
  • 페어를 통해 전체가 지식을 자주공유하기 때문에 한명에게 집중포화되도록 하는 상황을 만들지 않음

Q. PM으로서 가장 먼저 점검해야할 것이 무엇인지?

  • 첫번째 질문은 "이거 왜 만들어요?"
  • 두번째 질문은 "이 프로덕트의 스폰서가 누구에요?"
  • 이 2개의 질문을 기반으로 새로운 팀 구성을 시작
  • 피보탈팀 & 고객팀으로 구성해서 시작

Q. 원격 근무자들과 어떻게 협업하시는지

  • 원격 Pair 도구를 사용
    • 화면과 음성을 공유
    • 오피스에서 오랫동안 같이 Pair한 사람이라는 전제하에 시작
  • 최근에 글로벌하게 사업을 진행하다보니, 타임존에 맞게 지사를 개설
    • 피보탈은 글로벌 18개 지역에 둠
    • 200개 기능을 1명이 만들면 인수인계도 부담이 되기 때문에 타임존에 맞춰 스토리를 분산시킴

Q. HR권한을 팀 단위로 주는지, 회사단위로 하는지/ 팀단위로 한다면 회사의 문화와 안맞으면 어떻게 하는지?

  • 한국의 스타트업은 사업이 잘되면 가장 먼저 투자하는게 HR
  • 하지만 좋은 개발자는 이미 좋은 곳에서 일하고 있음
  • 사람이 많아지면 기존의 문화가 깨져버릴경우가 많음
    • 5명이였던 회사에 있던 문화가 신규 채용된 45명의 목소리가 더 커지게 됨
    • 그러다보니 기존멤버 5명이 본인의 권한을 놓지 않으려고 함
    • 결정/배포 등을 항상 이 5명을 통해야하다보니 45명이 아무리 개발을 빨리하고 많이해도 속도는 전과 크게 달라지지 않음
  • 피보탈에서는 며칠간 피보탈에 직접와서 3~4명과 Pair를 진행함
    • Pair를 통해 채용할지 말지를 결정
  • Pair를 통해 팀간의 기술격차가 현저하게 나지 않음
  • 피보탈에선 개인 랩탑을 기본적으로 제공하지 않음
    • Pair를 위한 아이맥을 제공
    • 내 자리가 어딘지 고정시킬수없음

2. 디자이너와 개발자와의 협업을 위한 디자인 시스템 - 김요한 (GS SHOP)

2

디자이너와 개발자들의 협업은 예전부터 비효율적인 경우가 많았음

Atomic Design

  • 디자인 방법론
  • 인풋박스, 버튼 등을 먼저 디자인
    • 이러한 단위를 원자 (Atomic)
  • 원자를 모아 분자로
    • 분자를 다시 모아서 새로운 더 큰 단위로
  • 컴포넌트는 원자의 집합, 분자의 집합 등 여러 단위의 집합을 나타냄

Design System

  • 디자인 시스템?
    • 팀이 제대로 디자인 하기 위한 문서/가이드 라인
    • UI 컴포넌트 등의 라이브러리/패턴등을 가지고 있음
  • 대표적인 디자인 시스템 사례
    • Materail Design
    • 구글에서 만든 템플릿이자 UI 가이드
    • Atlassian Design
    • 디자인 컴포넌트를 전부 react 컴포넌트로 개발
    • 쓸려면 import 해서 바로 쓸수가 있는 형태

Building Design System

  • 과연 문서만으로 개발자 & 디자이너간 문제를 해결할 수 있을까?
    • airbnb의 react-sketchapp을 참고하여 개발 시작
  • 전통적 방법
    • 디자인 -> 스타일코드 -> 프로덕트
    • 디자이너가 포토샵과 같은 파일로 디자인
    • 퍼블리셔에게 PSD 파일을 전달하여 코드로 전환
    • 개발자가 퍼블리싱된 파일을 실제 프로덕트로 개발
    • 디자인이 변경 될 경우 (1px이라도..) 이 과정을 처음부터 다시 해야함
  • 근본적으로 방식이 변경되어야 한다고 생각함
    • 스타일코드 -> 디자인 -> 프로덕트
    • react-sketchapp을 이용할 경우 스타일 코드를 작성하면 렌더링 결과물을 바로 보여줌
  • React SketchApp
    • 코드로 디자인을 할 경우 Real Data를 사용할수 있게 됨
    • Mock 데이터를 쓸 필요가 없음
    • API 가 구축되어 있으면 편하게 구축 가능
    • 여러 사이즈의 동일한 결과물을 코드만 변경해서 생성 가능
    • 다른 나라 언어들을 사용할 경우에도 코드만 변경하면 반영 가능
  • 디자인의 요소와 개발 요소를 하나의 코드로 관리 하게 되면 불필요한 비용이 굉장히 많이 줄어들게 됨
  • React는 현재 프론트엔드에서 주도적 역할을 하고 있음
    • 스케치앱에선 Image, Text, View 컴포넌트만 사용하면 됨

누가 디자인 시스템을 구축해야하는가?

  • 초기엔 개발자가 환경을 구축하고 틀을 잡음
    • 이후엔 퍼블리셔분들에게 디자인 제품을 스케치코드로 제작해달라고 요청
  • 러닝커브가 높음
    • 코드가 어렵다기보다는 동작하는 환경의 이해가 더 어렵다.
    • 그래서 개발자가 먼저 환경과 구조를 잡아야할것
  • UI가 직관적으로 생성할수가 없음
    • 코드를 작성해야 화면을 그릴수 있기 때문에 직관적으로 그려나갈수가 없음
    • 직관성은 디자인시스템의 목적이 아닐수 있음

Airbnb 헤드디자이너의 이야기

코드를 디자인 도구로 사용한다.
단지 레이아웃과 디자인 뿐 아니라 로직과 데이터를 고려한 디자인 자산을 만드는 것이다.
이를 통해 디자이너와 개발자간의 간극을 줄이고, 더불어 디자인 스펙 문서의 의존성을 줄여 이상을 좀 더 현실로 다가서게 한다.

Q & A

Q. 디자이너는 코드를 만지면서 만족도를 느끼게 해줘야하는데, 디자이너가 이 맛을 느끼게 하는데 얼마나 오랜 시간이 필요했고,
얼마나 만족했는지 알고 싶음

  • 개인적으로는 이상적으로 디자이너가 코드를 작성해야 한다고 생각함
  • 현실적으로 불가능하니 퍼블리셔 분들에게 컴포넌트를 다 생성해달라고 요청함
  • 주변을 보면 디자이너가 코드를 작성하고 싶어함
    • 하지만 디자이너 주변 분들은 디자이너 분들에게 코드 작성법을 가르쳐주지 않으려고 함
  • 디자이너 분들에게 교육을 진행하려고 함

eBrain HR 컨설팅 소개 - 김재희

  • 개발자 전문 리쿠르팅 회사
  • 도메인/언어 등의 변경/이직을 원할 경우 어떻게 해야하는지 모르는 분들은 꼭 연락주시길 바람


3. 애자일은 애자일이란 단어를 버려야 한다 - 신정호 (우아한형제들)

3

애자일을 통해 성공적으로 프로덕트를 출시하신 분들도 계시겠지만, 굳이 이렇게 자극적은 단어를 사용한 이유는 애자일이란 단어에 담긴 형식적인 내용들을 제거하기 위함

  • 보행자가 교통사고가 안나는 법

    • 길을 건널때,
    • 좌우를 살피고,
    • 파란불에,
    • 손을 들고,
    • 건널목을 건너면 됨
  • 누구나 아는 내용이지만 사고는 여전히 난다.

    • 여러 다양한 상황이 있기 때문
  • 프로젝트를 성공하는 법

    • 회고/추정/짧은주기의 릴리즈
    • 스프린트 계획 회의, 현황판
    • 테스트 케이스
    • 잘하면 프로젝트는 성공
  • 현실성이 낮다

    • 교통사고 안나는 법 == 프로젝트 성공하는 법

프로젝트, 스크럼으로 하겠습니다.

  • 누군가는 "망했다" 생각한다.
    • 이미 비슷한 경우로 망했던 분들
    • 문제는 애자일 이라고 단정
  • 형식적으로 망하는 프로젝트 징후
    • 맹신
    • 목표없는 작은 주기
    • 의미없는 회의
    • 기준없는 추정
    • 자발적이지 않은 교육
    • 겉치레적인 시스템 평가
    • 이슈갯수를 얼마나 done 시키냐/커밋을 얼마나 했느냐로 성과를 평가한다는 등

결국 손사래 친다.

  • 오히려 애자일을 모르는 분들과 함께하는 것은 쉽다
  • 반대로 해보신분들과 함께 할때 더 힘이 많이듬
  • 문제는 애자일 형식에 얽매이는 것임을 상기

형식에 얽매이지 않은 경험 공유

역할, 스케줄링, 회고 - 배민 라이더스 TFT, 배민 2.0

  1. 역할
  • 방법론에서 SM, PMO가 필요하다고 하던데..
    • 중요한건 직책이 아니라 역할
    • 누가 다 파악을 할것인지, 파악을 기반으로 어떤 결정을 내릴 수 있는지, 누가 책임을 질것인지
  • 파악
    • 파악을 하지 못하면 예상을 할 수도 없고, 의견을 제시할 수도 없다.
    • 정책, 요구사항 / 통신 프로토콜/ UI,UX진행사항 / 요구사항에 대한 테스트케이스 / 커밋기록/ 현황판 중심 데일리 미팅 등을 겪음
    • 현황판을 사용할 경우 이슈번호와 해당 이슈에 대한 리스크에 관해서만 이야기함
  1. 결정
  • 내부의 결정은 크게 고민할 필요 없음
  • 외부의 도움이 필요한 경우
    • 결정에 필요한 배경과 결정해야할 케이스의 객관식 리스트를 공유
    • 피드백 요청
  1. 책임
  • 퇴사, 감봉, 시말서...?
  • 매 시점마다 파악이 다 되어있었고, 최선의 결정을 했다면 책임은 없어진다
    • 부끄럽지 않다면, 각오해도 괜찮아

수평적 관계

방법론에서 사람들의 수평적 관계가 중요하다고 하던데...

  • 중요한건 수평적 관계가 아니라 부딪칠 수 있는 케이스를 정리하는 것
  • 겪은일 1) 기획자 vs 디자이너
    • 와이어프레임 그리지 않음
    • 정책/요구사항만 텍스트로 바로 작성
    • 디자이너는 와이어 프레임없이 자유롭게 그림
  • 겪은일 2) 기획자 vs 개발자 vs 품질책임자
    • 나는 이렇게 생각하지 않았는데??
    • 품질책임자는 제품에 대한 센스가 높기 때문에 이들의 책임이 굉장히 중요함
    • 기획자의 언어와 개발자의 언어는 차이가 나는데, 이런 차이를 줄여줄 수 있음
  • 겪은일 3) 기획자 vs 품질책임자
    • 정책이 정해져 있지 않은 경우
    • 상상의 나래를 펼치게 되면 고려해야할 테스트 케이스가 수만가지가 되버림
    • 데일리 정책 회의 진행
  • 겪은일 4) 디자이너 vs 개발자
    • 디자이너와 개발자간 구현 목표가 큰 차이가 남
    • 시간상 도저히 요구사항만큼 안나오는 경우가 있어 타협이 필요
    • ToDo List를 생성하여 관리
  • 겪은일 5) 최고의사결정자 vs TFT
    • 일정의 문제
    • 명확한 정량적 수치로 상황 공유
    • 목표치는 15%, 현 상황은 8% 등
  • 겪은일 6) 포토팀 & 어드민 운영팀 vs TFT
    • 팀 외 협업에서 놓치고 있는게 없는지 계속해서 유관부서에 물어봐야함
  • 중요한건 수평적 관계가 아니라 부딪칠 수 있는 케이스를 정리하는 것

스케줄링

방법론에는 스프린트 회의, 현황판, 추정, 데일리 미팅이 중요하다고 함

  • 중요한건 정량적 파악 (스케줄링)
    • 워킹데이 계산
    • 구정 등 실제 일할 수 있는 기간 계산
    • 휴가 계산
    • 테스트 일수를 예측
    • 개발완료의 기준
    • 늘 어디쯤인지 파악해라

스프린트 회의, 언제 어떻게 해야하는 걸까?

  • 겪은일
    • 회고 1일, 스프린트 회의 1일 하다보면 이틀을 그냥 소모하게 됨 => 회고와 스프린트을 같이 진행
    • 회고에 바로 이어서 스프린트 회의 진행
    • 정책 및 요구사항 발표
    • 구현 이슈 논의
    • 모호한 상황 명확하게 파악 및 결정

스프린트 어떻게 나눠야 하는 것인가?

  • 부분 미완성이지만 흐름을 먼저 볼것인가?
    • 정책 및 요구사항이 결정나지 않았을때 일반적으로 사용
  • 부분 완성으로 기능을 먼저보일 것인가?
    • 정책이 완전히 결정났을 경우
  • 겪은 일)
    • 현재 중요한 파트는 어디인가?
    • 기획중심 / 구현중심 / 테스트 중심

회고

  • 회고는 서로의 감정을 다치지 않고, 보다 나은 스프린트를 위한 준비를 해야한다고 하던데..
    • 서로의 좋은점, 나쁜점을 포스트잇에 기록만 하다가 하루가 끝남
  • 회고는 해결된 것과 해결할 것을 명확히 하는 시간
    • 스프린트 1에선 무언가 진행된게 없기 때문에 목탄의 이야기를 전달
    • 스프린트 4에선 이미 상당히 진행된 상태이기 때문에 남은 일정, 목표했던 사항들 점검
    • 스프린트 Risk에는 개인의 심리적 안정감을 체크
  • 회고의 중요한 시간은 아웃풋을 공유하는 것
    • 모두가 딴생각을 할수가 있음
    • 시연하는 시간을 가짐 (아웃풋 공유)
  • 남은일
    • 스프린트가 종료되었지만 완성하지 못한 일들
    • 시간이 지나면 남은 일을 어디까지 했는지 모를텐데?
    • 이때 테스트 케이스를 기준으로 다시 정리
  • 회고라는 것이 서로의 감정을 상하게 할수 있는 시간
    • 회고가 끝날때마다 다같이 화이팅을 외침

애자일은 말이나 형식이 아닌, 끈질기게 물고 늘어져서 행동으로 보여줘야 되는 것

3_1

(발표가 끝나고 많은 분들이 추가로 궁금하신 내용을 여쭤보러 오셨습니다!)

4. 협업도구로 제대로 말하기 - 김동수 (마켓컬리)

4

  • 마켓컬리?

    • 2015년 5월 서비스 오픈
    • 밤 11시까지 주문하면 새벽 문앞으로 배송
    • 자체물류센터와 물류시스템 운영
    • 2017년 11월 월 60억 달성, 매월 20% 성장중
    • 130명 이상의 구성원이 여러 협업도구와 노력으로 지속적 개선중
  • 협업 도구? (by 위키피디아)

    • 사람들이 협업하는데 도움
    • 협업 도구의 목적은 둘 이상의 개인으로 구성된 그룹이 공통의 목표 또는 목적을 달성하는 것을 지원

지금까지 써왔던 협업 도구들

  • 경험해본 도구들

    • 우편, FAX
    • 그룹웨어
    • 이메일
    • 문서도구
    • 위키, 이슈트래커
    • GIT
    • 트렐로
    • 이전의 메신저
    • 최근의 협업용 메신저
  • 2002년 하나인포테크

    • 유선전화, Fax
    • MS Exchange Server + Outlook
    • MS Office
    • CVS
    • 버디버디, MSN 메신저, 네이트온
  • 2006년 지어소프트

    • 휴대폰, Fax
    • MS Exchange Server + Outlook
    • Gmail
    • MS Office
    • SVN
    • Redmine, Jira, Confluence
    • 네이트온, U2 메신저
  • 2012년 KTH

    • 휴대폰
    • MS Exchange Server + Outlook
    • Gmail
    • MS Office, Google Cloud
    • SVN, Git
    • Jira, Confluence
    • 파란 메신저, Yammer
  • 2013년 KT 뮤직

    • 휴대폰
    • MS Exchange Server + Outlook
    • Gmail
    • MS Office, Google Cloud
    • SVN, Git
    • Jira, Confluence
    • MS Office Communcator (사람들이 굉장히 싫어했음)
  • 2017년 마켓컬리

    • 휴대폰
    • Google GSuite
    • Git(Github)
    • Jira, Confluence
    • Slack

협업 도구 도입 사용후기

  • 협업 도구에 로그인하는데 까지는 쉬움 (제대로 쓰게 하는 것에 비하면)
  • 저항은 공기처럼 어디에나 있음
    • 사람에 따라서 변화가 다 좋은것은 아님
  • 유행따라, 내 실적때문에 바꿀것은 더더욱 아님
  • 구성원들의 변화 필요성이 있거나, 확실히 지금의 문제를 해결할 솔루션이 되는 경우 변경해야 제대로 정착할 가능성이 높아짐
  • 변화를 주도하는 사람이 평생 회사에 있을것이 아니라면 혼자서는 지속적인 발전/유지하기는 불가능
    • 도입후 지속적인 관심과 요구를 계속 반영해야함

협업 도구 변경을 고려하고 있다면

  • 무엇이 원활한 협업을 더디게 만드는지 식별
  • 구성원들의 요구사항을 잘 수집
  • 잘 정착할 수 있도록 영향력 있는 조력자를 만들어야함 (특히 기업문화, 총무팀, 인사팀 등)
  • 사용료가 발생하는 경우, 그 가치로 최종 결정권자를 설득

협업도구를 평가할 때

  • 얼마나 사용하기 쉬운가
  • 검색할 수 있는가
  • 구성원간 열려 있고 공유가 쉬운가
  • 다른 도구와 연동이 원활한가
    • 개발툴, 모니터링툴간의 연동
  • 사용료 대비 가치가 충분한가
  • 마켓컬리 도구
    • GSuite
    • 메인계정 저장소
    • 메일
    • 달력
    • 문서
    • 화상회의
    • Slack
    • 검색 용이
    • 개인 생활과 분리하기 위해
    • Github
    • 사용성

협업도구의 발전 방향

  • 정보에 대한 접근성이 모두에게 수평적으로 제공
  • 검색, 동시작업
  • 다른 도구와의 통합/보안을 중심으로 발전중

각 도구별 목적

  • 전화
    • 긴급상황 전달
    • 텍스트로는 설명이 어려울때
    • 이력이 남지 않음
  • 이메일
    • 회사에 따라 주/부 커뮤니케이션 도구
    • 메일 삭제, 계정 삭제시 대화내용도 같이 삭제되어 백업 필수
  • 메신저
    • 메인 커뮤니케이션 도구
    • 빠른 의사소통
    • 퇴근 후에도 업무의 연장이 될 수 있음
  • 문서도구
    • 화려한 문서를 작성하려고 하다보면 핵심에 집중하지 못하는 경우가 있음
  • 위키
    • 워드/파워포인트 등 문서작성 도구 대체
    • 동시작업 지원으로 작업효율성 향상
    • 작성자가 퇴사해도 삭제되지 않음

마켓컬리 협업 도구 도입 경과

  • 2017.05

    • 카카오톡 -> 슬랙으로
    • 4번의 사용법 교육과 메뉴얼 배포
    • 계정생성 및 관리를 총무팀으로 이관
    • 전직원 슬랙 사용중
    • 전 사원 프로필 사진 촬영후 프로필 사진 업데이트
  • Jira/Confluence 전사 확대

    • 메인 문서 도구
    • 4번의 사용법 공유
  • 2017.07

협업, 소통이 잘되려면

  • 상대방이 이해할수 있어야 함
  • 단어가 정확
  • 날짜도 정확
  • 검색이 가능하도록
  • 에티켓은 기본
  • 사례 1)
    • 용어가 변경됨을 공유
    • 고도몰 솔루션을 사용하니 고도몰이란 용어로 사용하고 있었더니 혼용되는 경우가 발생
    • 고도몰 -> 컬리몰 이란 단어로 변경하여 전체 채널에 공유
  • 사례 2)
    • 특정 네트웍에서 서비스가 안되서 제보
    • 접속이 안되요!?
    • 어느 사이트, 어느 URL에서 안되는지 정확히 전달하지 않으면 대화가 계속 우회하게 됨
  • 위키 도구 사용
    • 개발자는 반드시 설계를 하고, 동료 리뷰후 개발 시작
    • 다이어그램은 draw.io 또는 노트/화이트보드에 그린 것을 찍어서 사용


5. 생산성 지향의 커뮤니케이션과 기업 문화 - 최영근 (오마이랩)

5

  • 자기소개
    • 개발 -> 경영/전략/HR
    • 피고용인 -> 고용인 -> 피고용인
    • 고용인의 입장으로 한번 경험해본것이 협업에 굉장히 큰 도움이 됨
    • IT 산업 -> 여행 산업
    • 도메인 지식이 필요한 영역으로 이동
    • 논리적으로는 맞지 않는 단어인데 업계에서 일반적으로 쓰이는 용어등이 있음을 발견

소프트스킬의 시대

  • 연구자료
    • WSJ 조사결과 92%의 응답자가 소프트 스킬이 기술적인 능력과 동등하거나 더 중요하다고 답함
    • ICMS에선 IT 전문가에게 소프트 스킬이 하드스킬보다 18%더 가치가 있다고 발표
  • 커뮤니케이션 == 패시브 스킬
  • 90% : 53%
    • 하나의 스프린트로 90%의 기능을 달성하면
    • 3번의 스프린트로 진행하면 53%로 낮아짐
    • 그만큼 소통이 어려움
  • 왜 개발자들은 다 안된다고 할까?

WHY?

  • 방법론만 바라보다 목표를 잃게 되는 경우가 많음

  • 커뮤니케이션의 목적은 정보 전달

    • 화자가 아닌 청자 중심의 전달
    • 우리가 개발자지만, 우리의 대화는 받는 사람이 편한 커뮤니케이션을 해야함
  • vs 경영진 (+의사결정자)

    • 왜 경영진은 커뮤니케이션할까?
    • 이분들이 궁금한것은 의사결정할 수 있게 정보를 달라는것
    • 신속한 정확한 의사 결정을 할 수 있게 대화
    • 단기적 효과, 숫자의 힘을 무시하지말자
    • 개발자들은 장기적 효과를 바라보는 경향이 있는데, 이대는 단기적 효과가 필요함
    • 집행 요약을 자주 쓰면 권한이 서서히 넘어온다
    • 집행요약: 단기 요약 경영 보고서
    • 참고자료를 다 같이 하기 보다는, 그 요약본 + 본인의 선택을 함께 첨부해서 결정권자가 편하게 결정할수 있도록 제공
  • vs 세일즈

    • "고객이 원하잖아요" 에 숨어있게 하지 말라
    • Customer Wants -> Customer Needs로 끌어내야함
    • 목적을 확인후, 현재 안되는 상황에서 우회할 수 있는 방안을 제시
  • vs 자기자신

    • 우리는 연구원이 아니다 (대부분)
    • 비지니스 성공이 성과로 인정받는다.
    • 나 자신의 지적 호기심으로 선택을 하는것은 아닌지 고민해봐야함
    • 정말 우리 조직의 성공을 위해 필요한 선택인지?

관성을 이겨라

  • 성문하라 (규칙화)

    • 문서화 시켜서 힘을 주는것 (무언의 압박)
    • Culture Code Deck, 포스터, 캠페인, 회의록
    • 넷플릭스의 Culture Code Deck
    • 우리는 계약관계 (우린 가족이 아니다)
    • 프로페셔널 (우리는 프로 스포츠 팀)
    • 우리의 존재이유는 조직의 비지니스 목표 달성
    • 유비쿼터스 Language
    • 프로덕트 모든 구성원이 사용할 공용의 단어장
    • 인바운드 API?
      • 우리쪽으로 들어오는 API 인줄알았더니, 입국하는 고객을 위한 API였음
    • OTA에 대한 정의가 서로 달라 같은 의견을 1시간동안 토론을 경험
    • 회의록을 쓰자
    • Goals, Discussion Points, Agreements, Action Items
    • 중요한 비지니스 회의실엔 꼭 위 4가지를 작성할 것
      • 회의중에 연결되지 않은 부분은 Action Items로 기입하여 이후 진행사항을 추적
  • 박터지게 싸우자

    • "다 내가 잘되자는거냐? 우리가 잘되려고 하는거지"
    • 자주 말하라. 마법같은 주문이 된다
    • 이기려는 자세가 없어짐
    • 마치 이중인격처럼 설득되면 과격한 리액션과 칭찬
  • 업무용 메신저를 카톡처럼 쓰지 맙시다

    • 본인의 편의대로 커뮤니케이션 채널을 활용하지마라
  • 정원사는 한명 필요하다

    • 조직문화를 만드는 것은 정원을 가꾸는것과 같다.

Q & A

Q. 고객들과 회의시에 회의록까지 작성했음에도 다른 이야기를 할때가 있는데, 어떻게 하면 웃으면서 대화를 진행할 수 있을지

  • 고객을 이길수 있는 방법은 없을듯해서... ㅠ

Q. 유비쿼터스 랭귀지 방법론

  • Deck이 눈앞에 보이지 않으면 아웃데이트 될때가 많음
  • 회의시 애매한 단어는 항상 명확하게 정의하려고 노력함
  • 애매한 단어가 명확하게 정의 되면 바로 유비쿼터스 랭귀지 페이지를 편집

Q. 사내에서 이야기 되는 정보/아이디어들을 지속적으로 노출시키는 노하우

  • 잔디 개발의 경험으로 다양항 커뮤니케이션을 요구하는 고객분들을 만날수 있었음
  • 정보의 투명화 수준은 개인적인 생각으론 오버 커뮤니케이션이 옳다고 생각
  • 협업 도구들을 별도로 구성하기 보다는 통합 서비스를 사용함
    • 컨텍스트 스위칭 비용이 많이 발생한다고 생각
  • 회사에서 전문적으로 커뮤니케이션에 대해 계속 고민해야하지 않을까라고 생각함

Q. 의견을 내는데 있어 심리적 안정감을 얻을 수 있는 방법

  • 선택의 책임은 제안자가 아니라, 관리자가 가져야 한다고 생각함
  • 심리적 안정감은 윗 사람이 잘해야 가질 수 있음

Q. 내성적인 개발자들을 끌어낼수 있는 방법

  • 개인적인 경험 공유
  • 내성적인 분들을 끌어내려고 노력했지만 잘 안되었음
  • 회고시간에 그럴필요가 없음을 발견
  • 내성적이든 아니든 그 사람이 행복하게 개발할 수 있게 해주는것이 좋은 방법임
  • 굳이 외향적인 사람들의 필드로 내성적인 사람들을 던지는건 옳지 않았음

Q. 메일 작성팁

  • 끝까지 다 안읽는다는것을 전제로 작성

Q. 정원사들로 인해 커뮤니케이션이 위축되지는 않을지

  • 검열과 가이드는 다름
  • 슬랙은 사실상 공개채널의 성향이 약함

Q. 회의가 결론이 안날때 어떻게 결정하는지 & 커뮤니케이션

  • 회의가 결론이 안나면 억지로 결론내려고 하지 않음
  • 어정쩡한 결론을 낼바에는 하루종일 회의를 함
  • 맛대가리 없는 절충안은 다 같이 망하는 길
  • 어찌됐든 하나로 결정되어야 함
  • 커뮤니케이션 룰을 위반하는 사람은 경고를 줘야한다고 생각함

6. 협업의 미신 5가지 - 근거 기반 협업으로 가기 위해 - 김창준 (애자일 컨설팅)

6

IT업계에 떠도는 5가지 미션에 대한 이야기

1. 그 친구는 프로그래밍을 잘하는데 협업을 못해?

  • 이 말의 의미는 무엇일까?
  • 프로그래밍을 잘하는 기준에 협업이 포함되지 않은것 같음
  • 이전 연구에선 뛰어난 사람과 뛰어나지 않은 사람을 구분하는데 쉬운 기준을 세웠음
    • 1명씩 실험실에 두고 문제를 잘푸는지 확인
  • 1990년 이후부터 여러명을 데려와 실제 실무에서 하듯이 실험을 시작하니 결과가 다르게 나타나기 시작함
  • 7년차로 이루어진 잘하는 그룹 A와 평범한 그룹 B를 모아 신입 개발자에게 조언을 요청함
    • 뛰어난 그룹은 사회적인 요소를 얘기
    • 보통의 그룹은 사회적인 요소를 얘기하지 않음
    • 실제로 성과를 내는 사람들은 협업을 잘하는 사람이라는 결과가 나타남
  • 프로그래밍을 잘하는 기준의 변경이 필요하기 시작
    • 프로그래밍은 자판속도가 중요한게 아님
    • 프로그래밍의 개념을 좀 더 넓게 봐야함
  • 프로그래밍의 개념에는 협업/소통이 포함되어야 함
    • 프로그래밍과 협업은 분리하기 어려움

1-1. 컴퓨터화의 병목 == 사회적 요소

  • 알고리즘을 통해 컴퓨터화 하기 쉬운 직업이 어떤 것인지 추출해봄
  • 어떤 직업이든 사회적인 요소가 필요할수록 컴퓨터화 하기 어려운 직업임
  • 컴퓨터화하기 쉬운 직업일수록 현재 임금이 낮음
    • 컴퓨터화하기 어려운 직업일수록 현재 임금이 높음
  • 컴퓨터 프로그래머는 컴퓨터화될 확률이 48%
  • 소프트웨어 개발자는 컴퓨터화될 확률이 4.2%
  • 이 둘의 차이는 협상과 인터랙션
    • 소프트웨어 개발자는 협상과 인터랙션을 많이하지만, 컴퓨터 프로그래머는 이런 행위를 하지 않는 직업
  • 내 직업을 보존하는데 있어서도 협업과 소통은 중요한 요소
  • 협업은 프로그래밍을 잘하기 위한 필수요소
  • 알고리즘 테스트는 판단하기 쉽기 때문에 사용하는데 위험하다고 생각

2. 팀의 퍼포먼스는 가장 잘하는 사람이 좌지우지 한다?

  • MIT 집단지성 랩에서 굉장히 중요한 발표를 함

  • 어떤 문제를 줘도 잘 해결하는 집단이 있는지 연구해봄

    • CQ
    • 어떤 집단은 어떤 문제를 줘도 잘 해결하지만, 어떤 팀은 어떤 문제를 줘도 해결을 못함
    • 재밌는 것은 각 팀의 최고 IQ, 평균 IQ와는 무관하게 결과가 나옴
    • 공감력/말을 골고루 하는 것으로 CQ를 예측할 수 있음
  • 구글의 HR팀의 연구 결과

    • 탁월한 팀을 찾는 연구
    • 그 팀의 퍼포먼스는 구성된 개개인이 중요하지 않음
    • 가장 중요한 요소는 심리적 안정감
    • 내가 어떤 질문/의견을 냈을때 비난받지 않는다는 심리적안정감이 있을수록 좋은 퍼포먼스를 발휘함
  • 단순한 일일수록 개개인의 퍼포먼스가 중요하지만, 복잡한 일일수록 팀이 중요함

3. 전문가들을 모아놓으면 일을 잘한다?

  • 전문가를 얘기할때 사회적인 요소를 빼놓을때가 많음

  • 협력은 오래한다고 늘지 않음

  • 매일 3번씩 평생을 이빨을 닦지만 전문가는 아닌것처럼 그냥 한다고 전문가가 되진 않음

  • 2개의 전문가 집단을 두고, 1개의 집단에겐 15분동안 어떻게 협업할지 이야기하고 시작하게 하고, 다른 집단에겐 바로 일을 시작하라고 함

    • 2번째 집단은 오히려 비전문가의 집단보다도 못한 결과
    • 1번째 집단은 전문가 집단 다운 결과를 냄
  • 어떻게 협력할지 의식적으로 수행하는 것이 중요함

4. 협력을 잘하는 것은 서로 좋은 관계를 유지하는 것?

  • 협력 == 인간관계가 좋은것?
  • 우리가 생각하는 좋은 관계는 무엇일까?
  • 회피적으로 하면서 좋은 관계일 수 있음
  • 좋은 예
    • 신혼 부부 시절에 얼마나 많이 싸웠는가 조사를 해봄
    • 15년 후에 이혼한 비율을 확인해봄
    • 신혼 부부 시절에 많이 싸웠을수록 덜 이혼
    • 신혼때 안싸운다는 것은 누군가는 참고 있다는것 => 갈등처리가 성숙하지 못하다는것
  • 개발팀에서도 자주볼수있음
    • 개발팀장이 팀내에서 항상 좋은 관계를 유지하려고함
    • 부정적인 감정을 얘기할 수 있는 팀이 퍼포먼스가 좋음
    • 물론 하더라도 감정을 심하게 상하도록 하면 안됨
  • 참는 것이 좋은 협력관계가 아님

5. 분업을 잘하는것이 협업을 잘하는 것?

  • 린스타트업을 발표하면서 린과 스타트업을 발표하고 린스타트업을 발표하지 않으면 어떤지?
    • 한 친구는 린만, 다른 친구는 스타트업만 한다면?
  • 실제 현실에서 많이 볼 수 있음
    • 국가별로만 조사하고, 전체조사를 안하는 경우
  • 우리 머릿속 협업은 분업외에는 없다는 것
  • 팀은 구성원들간의 링크가 있는 구조, 워크 그룹은 팀장님을 중심으로 각자 링크가 뻗어져 있는 구조
    • 현실엔 대부분 워크 그룹
  • 연구결과 팀이 워크그룹보다 압도적으로 성과가 좋음
    • 일이 불확실할수록 팀의 성과가 훨씬 더 좋음
  • 팀이 더 성과가 좋은 이유로 동료간 커뮤니케이션으로 나타남
  • 일이 복잡하고 불확실할수록 분업을 세분화하고, 서로 얘기를 안하게 됨
    • 일이 복잡한데 세분화 한다고 복잡함이 줄어들진 않음
  • 팀의 효과성을 측정하는 좋은 방법은 상호간의 커뮤니케이션 모니터링
    • 성과가 좋은 팀은 서로 업무가 달라도 참견할 수 있는 팀
    • 분업을 해서 서로 말하는 것을 제거하는 것은 팀의 성과를 낮추는 일
  • 분업을 잘하는 것은 협업을 잘하는것이 아니다.

Q & A

Q. 팀이 지나치게 나눠져있을때 협업이 잘 안된다고 하셨는데, 어느 정도는 분업되어 있어야 하지 않는지?

  • 일단 공감
  • 사례 공유
    • 장애가 난 서버 개발자만 혼이 나고, 나머지는 커피마시러 나가는 상황을 봄
    • 그 팀장은 몇달 뒤에 팀 퍼포먼스가 너무 낮아 좌천됨
    • 132번 서버가 죽었다고 했을때 담당 서버 개발자만 혼나는게 아니라, 팀원 전체가 함께 회의를 하고 공유하는것이 더 좋지 않을까 생각
    • 팀원들에게 공동의 목표가 있고, 서로 의지할 수 있는 관계라는 것을 알려주는게 중요
  • 왜 캐네디 시절엔 NASA의 성과가 좋을까
    • 당시 청소부에게 당신의 목표는 무엇이니까라고 질문
    • 청소부의 답변은 "인간을 달에 보내는것"
    • 본인의 Task 를 개인의 Task만 보는게 아니라 조직의 Task를 보는것
    • 조직의 구성원의 목표는 똑같아야함 (조직의 목표를 얘기해야함)
  • 분업을 하더라도 구성원에게 팀의 목표를 계속 상기시켜줘야함

Q. SI 프로젝트(1회성) 팀에서 어떻게 협업을 하는지

  • 굉장히 불리한 상황
    • 팀이 지속되지 않고, 계속 구성원이 바뀌는 상황
  • 70:20:10 법칙
    • 팀의 퍼포먼스는 70%가 서로 만나기전에 결정됨
    • 20%는 서로 만나고 컴퓨터 세팅 하는 시기에 결정
    • 10%는 일을 하는 과정에서 결정
    • 우리가 무슨 일을 할건지 등 목표가 퍼포먼스의 대부분을 결정
    • 이미 달리고 있는 중간에 바꾸기가 너무 힘듬
    • 6개월 동안의 프로젝트라면 초반 1주일이 가장 중요한데, SI 프로젝트에선 초반이 가장 널널함
    • 이 시기에 제일 집중해서 모범을 만들어야함
    • 회의의 가치는 내가 모호할때가 가장 높음
    • 다 정리되고 회의를 하면 변경될 요소가 별로 없음

Q. 의견을 내면 그 사람이 일을 하게 되니 점점 의견을 안내게 되는데, 어떻게 하면 팀의 과제로 가져갈 수 있을지

  • 사장님이 바뀌어야하니 간단한 문제는 아님
  • 좋은 출발은 일단 우리끼리라도 해보는 것이 중요
  • 이렇게 하면 심리적 안정감을 얻게 됨
  • 누가 뭘 할지 결정은 하지 않고, 아이디어만 쭉 내보는 시간을 가짐
    • 우리 팀에 도움이 될만한 아이디어
  • 팀원이 5명이면 일감을 5개를 나눠주기보다는 2개씩 2번 주는게 훨씬 협업에 좋음
    • 각각 1개씩 주면 분업이 되버림

Q. 실수 만회를 얼마나 했는지도 성과측정에 포함시키는게 어떤지?

  • 좋은 점과 안좋은점이 같이 있음
  • 현재 많은 조직이 개인평가가 다수이므로 실제 적용은 어렵다고 생각
  • 성과평가라는게 있긴 하지만, 직장인들에게 얼마나 효과가 있을까?
    • 성과를 좋게 받아 연봉이 올라도 기분좋은 것은 한달~두달밖에 효과가 없음
    • 평가체계에 포함시키느냐 마느냐가 크게 그사람의 하루하루에 영향을 끼치지 않음
  • 성과평가하기 이전에 그 문화에 그 사람이 얼마나 만족감을 받는지가 중요함
  • 제도를 통해서 변화는 크게 일어나지 않음
  • 조직의 변화는 조직내 개인의 랭크와 관계 없이 발생
    • 인턴이 호주의 대형병원 문화를 변화시킨 경우도 있음

후기

협업/소통에 관해 갖고 있던 생각을 크게 변화시킬 수 있는 기회였습니다.
특히 김창준님의 발표에서 분업이 좋은 협업이 아니다에서 머리를 한대 맞은듯한 느낌이였습니다.
좋은 연사분들의 좋은 강의를 볼 수 있게 해주신 eBrain 분들께 정말 정말 감사드립니다.
다음에도 좋은 세미나에서 뵙겠습니다!


블로그가 도움이 되셨다면 아래 광고 클릭을 부탁드립니다!

좋은 리뷰와 광고클릭은 앞으로 계속 글을 쓰는데 큰 힘이 됩니다!


Posted by 창천향로 창천향로

태그

관련 글

티스토리 툴바