3. • 2018년 부터 AWS 공식 Technology Partner
• 웹/앱 서비스의 QA 테스트를 자동화 해주는 SaaS 솔루션을
개발 & 운영하고 있습니다.
• 매 2주마다 패치를 3년째 하고 있습니다.
• 전원 원격 근무를 하고, 모든 회의를 원격으로 하고 있습니다.
12. • 킥오프 부터 납기일 까지 수개월 동안
기획 - 개발 - 테스트 - 배포를 1 바퀴만 돕니다.
• 주간, 월간 회의를 하며 보고서를 준비해야 합니다.
• 실무 및 관리자들이 수시로 회의를 잡습니다.
• 1개월 6개월 혹은 1년 이후의 계획까지 세웁니다.
• 최종까지 합의된 건은 바꾸기 매우 어렵습니다.
13. • 회의 하느라 개발할 시간이 없습니다.
• 보고서가 수십개 버전이 존재해서 어느게 최종인지
알기 어렵습니다.
• 보고서 만드느라 관리할 시간이 없습니다.
• 협의에 지쳐서 기존 안을 수정할 생각을 하지 못합니
다.
• 일정에 업무를 맞춰야만 할뿐,
일정을 업무에 맞게 조정하기 힘듭니다.
15. • 매 2주 단위로 기획 - 개발 - 테스트 - 배포의
Cycle을 반복합니다.
• 시작하기 전에 모든 안건을 같이 리뷰하고
계획을 세우며, Issue 생성 및 공수 산정을 합니다.
• 전체 회의는 2주에 1번만 합니다.
• 매일 자신의 업무 상황을 간략히 기록/공유합니다.
17. • 스프린트는 업무의 주기(Cycle)을 말합니다.
• 1 Sprint = 2 Weeks = 10 Working Days
• 이전 2주간 한 일들을 모두 리뷰 합니다.
• 회사/개발/운영/마케팅 모든 안건을 논의합니다.
• 이번 2주간 할 일을 모두 Issue로 정의합니다.
• 이번 2주간 할 일의 Story Point를 추정합니다.
• 2주에 1번만 하루종일 합니다. (격주 화요일)
• 자신과 관련된게 아니면 회의중 딴짓을 해도 좋습니다.
19. • Story Point는 공수를 추정하기 위한 단위입니다.
• 1 Point = 8시간 = 1 working day
• 인간은 하루종일 업무에만 집중할수 없습니다.
그래서 가중치를 줍니다.
• 2주 = 10 working day * 가중치 0.8 = 8 point
• 1인당 각 Issue에 할당된 총합이 8 포인트를
넘기지 않으면 됩니다.
• 1인당 각 Issue의 총 개수가 20개를 넘지 않도록 주의합
니다.
21. • 8포인트를 2주 동안 잘 쪼개는게 중요합니다.
• 1시간내로 끝나는잡무 = 0 point
• 1시간 이상 걸리는 업무 = 0.1, 0.2, 0.3 point
• 1시간 이상 걸리는데 잘 모르겠음 = 0.5 point
• 8시간(하루) 소요 = 1 point
• 여러번 해보고 피드백을 받으면서 점점 정확한?
추정이 가능해 집니다.
23. • Story Point를 세우고 추정을 하는건
일을 많이 하고 이를 독촉하기 위함이 아닙니다.
• 작업자가 자신의 역량보다 너무적게 또는
무리하게 일을 해서 생기는 부작용을 막기 위함 입니
다.
• 또한 추정을 통해 현재 팀의 업무 역량을 알수 있습
니다.
• 전체의 업무 상황과 역량을 빨리 파악하는덴
Burn Down Chart 가 효과적 입니다.
26. • Scrum 회의를 Did List 작성으로 간소화 하였습니다.
(scrum 회의는 매일아침 10분간 같이 오늘 할일을 이야기 하는 자리입
니다)
• 누가 언제 무엇을 하고 있는지 Did List에 남깁니다.
• 모두가 서로 무엇을 하고 있는지 알수 있습니다.
• 따로 보고서를 제출하거나 보고회의를 잡지 않습니
다.
• Did List 작성은 반드시 의무화 하고 있습니다.
(회사 - 근로자간 신뢰의 근간 및 원격근무의 필수요소)
30. • 모두가 개발 서버를 공유합니다.
• 운영 환경과 개발 환경이 혼재 되어 있습니다.
• 패치는 수동으로 하거나 반자동 입니다.
• 시스템은 손으로 Setup 및 Upgrade 합니다.
• CI/CD (Continuous Integration) 는 주니어의 업무입니다
.
• 아무나 OP(운영)의 설정을 건드릴수 있습니다.
• 한번 배포되면 웬만해선 건들지 않습니다.
31. • 개발하다가 실수로 운영서버를 건드려서 장애가 납니
다.
• 남이 개발서버를 수정하는 바람에 내가 개발을 못합니
다.
• 누가 왜 만들었는지 알수없는 리소스가 존재합니다.
• Full DR 또는 일부만 DR 하는데 얼마나 걸릴지 모릅니
다.
• 패치날은 하루종일 일한 후 밤새서 일하는 날입니다.
• 퇴사자가 작정하고 OP를 날리면 복구할 방법이 없습
니다.
• 오래된 서버가 자주 문제를 일으킵니다.
33. • 나만의 local 개발 환경(vagrant)과 AWS 환경이 모두 제공됩니다.
• 모든 인프라와 어플리케이션은 수동세팅 없이 IaC로만 관리됩니
다.
• Daily CD: IaC를 이용하여 모든 어플리케이션 리소스를
매일 새것으로 교체 합니다.
• GitHub 커밋 기록이 곧 인프라/어플리케이션의 수정 기록입니다.
• 장애 발생시 서버 교체에 얼마나 걸릴지 CD 기록으로 알수 있습
니다.
• CD/CI 는 시니어 개발자 및 패치 담당자의 역할입니다.
• Full Test 및 Patch에 길어도 반나절이면 충분합니다.
35. • 모든 개발자는 각자의 AWS 계정을 발급 받습니다.
• QA, OP 역시 각자의 AWS 계정으로 독립되어 있습니다
.
• Root 계정의 AWS Organization으로 모든 AWS 계정을
묶어서 관리합니다.
• Last Pass 를 이용하여 임원, 시니어, 주니어 순으로
계정 및 설정 정보 노출을 제한합니다.
• QA/OP 는 임원외엔 IAM 으로만 계정에 접근 가능합니
다.
• DV/QA/OP 모두 VPN 으로만 EC2에 접근 가능합니다.
39. • 모든 개발자는 각자의 로컬 Vagrant 환경에서
개발을 시작합니다.
• Vagrant는 각 MSA 서버들을 VM으로 로컬에서
띄울수 있도록 해줍니다.
• Vagrant는 마음대로 수정하고 언제든 버리고
다시 띄울수 있는 sandbox 입니다.
• Vagrant 환경도 IaC화 되어 있어 띄우기만 하면
모든 스택이 자동으로 세팅되어 제공됩니다.
• AWS 상에서 개발하는데 드는 불편함과
비용에 대한 걱정을 줄일수 있습니다.
41. • AWS 부터는 HBsmith 전용 IaC인 Johanna를 이용합니다.
• run_create.py 만 하면 모든 리소스가 내 AWS 계정에
프로비저닝 됩니다.
• run_terminate.py 만 하면 띄운 모든 리소스를
깨끗히 삭제할수 있습니다.
• run_create_*.py / run_terminate_*.py 로
원하는 리소스를 찍어서 띄우고 삭제할수 있습니다.
• DV/QA/OP 모두 설정값의 내용만 다를뿐 같은 소스코드,
같은 스키마의 설정을 이용합니다.
(DV에서 가능한 것들은 QA, OP에서도 모두 가능합니다.)
• Johanna의 git commit 기록이 곧 인프라 수정의 기록입니다.
43. Johanna에 대한 더 자세한 이야기는
마이크로소프트웨어 398호에 있습니다
!
구매 부탁드립니다 :)
45. • Johanna의 최고 장점은 쉬운 Daily CD 입니다.
• 매일 자동으로 Web, EC2, ELB 등의 리소스를
새것으로 교체 합니다.
• 매일 자동으로 교체하기 때문에 서버를 장시간
운영해서 발생하는 이슈가 없습니다.
• 매일 자동으로 교체하기 때문에 언제든지
문제없이 패치가 가능하다는 것을 알수 있습니다.
• 패치에 걸린 기록이 남기 때문에 DR 상황에서
서버 교체에 얼마나 시간이 걸릴지 알수 있습니다.
50. • 결정은 임원이 책임은 직원이 집니다.
• 실수하면 시말서를 제출해야 합니다.
• 중요한 정보는 소수 (주로 흡연자) 만이 알고 있습니다.
• 운영중에 문제가 안생기길 기도합니다.
• 정보는 입으로 전달되며 문서는 오래된 것이 대부분입니다.
• 소스코드, 문서는 여기저기 흩어져 있습니다.
• 이메일을 뒤져서 업무 히스토리를 추적합니다.
• 갈등이나 문제는 술로 풉니다.
• 휴가/퇴근을 쓸때 눈치가 많이 보입니다.
• 코드 리뷰를 KPI로 설정합니다.
51. • 정보는 독점되고 공유되지 않습니다.
• 직원들은 관리자와 임원들을 두려워 합니다.
• 한번 터진 문제는 같은 이유로 또 다시 터집니다.
• 임직원들 사이에 사적인 그룹이 형성됩니다.
• 계획이나 약속만 있고 실천은 없습니다.
• 임원들에 대한 직원들의 신뢰가 없습니다.
• 직원들에 대한 임원들의 신뢰가 없습니다.
• 모두가 야근과 주말 출근을 자주 합니다.
• 이직률이 높습니다.
• 코드 리뷰를 싫어합니다.
54. • 기록으로 남지 않는 것은 관리되지 않습니다.
• 인사/재무/기획/운영/코드 자료가 모든 구성원이 볼수 있도록 공개되어 있
습니다.
(심지어 임원들이 주기적으로 리마인드 까지 해줍니다)
• JIRA, Confluence, GitHub 같은 협업툴을 적극 사용합니다.
• 사람이 쓰는 Slack 채널은 #general 만 운영 합니다.
• 문제가 생겼을때 최선의 미덕은 정직(사실대로 빠른 전파)입니다.
• 공유된 문제는 특정인이 아닌 모두의 책임입니다.
• 의사결정의 실행은 직원이 책임은 임원이 집니다.
• 코드 리뷰는 문화지 업무가 아닙니다.
• 술을 마시지 않아도 갈등을 풀수 있습니다.
56. • Code Review은 문화입니다: No Respect, No Review
• 코드 작성전 논의는 JIRA/Confluence 에서
• 코드 작업후 논의는 GitHub 에서
• No Merge, Not Done
• Fast Merge
• Code Freeze
• QA/OP 패치 전 PR 은 반드시 정리
• 리뷰가 덜된 PR은 2 Sprint내 Merge
60. • 가끔 점심 회식을 합니다.
• 대신 분기에 1번 또는 상하반기에 1번씩 전체 워크샵을 갑니
다.
• 공기 좋은 곳에서 질 좋은 음식을 먹습니다.
• 회사의 과거, 현재, 미래에 대해 같이 이야기 합니다.
• 간단한 액티비티/해커톤/페어 프로그래밍도 합니다.
• 커피는 마시지만 술은 거의 안마십니다.
63. • 외부 고객도 중요하지만 내부 고객(임직원)은 더 중요합
니다.
• 임원들이 돌아다니며 팀의 모든 임직원과 1:1 로 밥을 먹
고 커피를 마십니다.
• 최소 2시간 부터 4~5시간 까지 이야기를 나누기도 합니
다.
• 가벼운 근황공유 부터 속 깊은 이야기 까지 대화를 나눕
니다.
• One-to-One 때 나온 피드백이 좋은 개선을 불러온적이
많습니다.
65. • 최신 MacBook Pro를 지급합니다. (32G Ram)
• 2년 근속시 개인소유, 2년에 한번 업그레이드 합니다.
• 업무용 SW는 회사에서 사줍니다.
• 외부 컨퍼런스, 미팅 비용은 회사에서 대줍니다.
• 경조사 지원, 병원비 지원, 명절선물 지원 있습니다.
• 코스트코 회원 카드 (비즈니스)를 줍니다. - 한정
67. • 장애가 발생하면 제때 대응이 가능한가요?
=> 시스템 알람 뿐만 아니라 임직원들이 서로 전파합니다.
• 개발자들이 일 잘 하고 있는지 확인이 가능한가요?
=> 업무 상황이 시스템에 모두 기록되어
누가 뭐 하는지 실시간으로 서로 알수 있습니다.
• 일정을 맞추기 어렵지 않나요?
=> 업무를 추정하여 완급을 조절합니다.
68. • DevOps 팀이 원활한 원격근무가 가능하려면:
• 추적가능하고 재현가능한 자동화 달성
• 명확하고 투명한 정보 공유
• 시스템을 바탕으로 업무
• 원칙과 프로세스를 꾸준히 지키고 유지
• 실행은 직원이 책임은 임원이
• 이 모든게 며칠이 아닌 수개월 수년동안의 지속적인 실험/개선의 결과입
니다.