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

Contenu connexe

Similaire à DevOps는 원격근무를 추구하면 안되는 걸까?

멸종하는 공룡이 되지 않으려면
멸종하는 공룡이 되지 않으려면멸종하는 공룡이 되지 않으려면
멸종하는 공룡이 되지 않으려면Byeongsu Kang
 
쿠키런 1년, 서버개발 분투기
쿠키런 1년, 서버개발 분투기쿠키런 1년, 서버개발 분투기
쿠키런 1년, 서버개발 분투기Brian Hong
 
131 deview 2013 yobi-채수원
131 deview 2013 yobi-채수원131 deview 2013 yobi-채수원
131 deview 2013 yobi-채수원NAVER D2
 
스마일게이트 서버개발캠프 - HGHSS - 합격하소서
스마일게이트 서버개발캠프 - HGHSS - 합격하소서스마일게이트 서버개발캠프 - HGHSS - 합격하소서
스마일게이트 서버개발캠프 - HGHSS - 합격하소서ServerDevCamp
 
Critical_Chain.pdf
Critical_Chain.pdfCritical_Chain.pdf
Critical_Chain.pdfJisung Ahn
 
소프트웨어 개발 프로세스 배경 설명
소프트웨어 개발 프로세스 배경 설명소프트웨어 개발 프로세스 배경 설명
소프트웨어 개발 프로세스 배경 설명Andrew Sungjin Kim
 
2021년 1월 30일 개발자 이야기
2021년 1월 30일 개발자 이야기2021년 1월 30일 개발자 이야기
2021년 1월 30일 개발자 이야기Jay Park
 
[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스
[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스
[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스Hee Jae Lee
 
애자일 하라
애자일 하라애자일 하라
애자일 하라진수 허
 
하드웨어 스타트업의 소프트웨어 이야기
하드웨어 스타트업의 소프트웨어 이야기하드웨어 스타트업의 소프트웨어 이야기
하드웨어 스타트업의 소프트웨어 이야기Mijeong Park
 
2014.04.24.nrise 개발환경
2014.04.24.nrise 개발환경2014.04.24.nrise 개발환경
2014.04.24.nrise 개발환경Moon Soo Kim
 
꿀밋업시리즈3탄_Spring Boot를 활용한 마이크로서비스 개발과 페어프로그래밍(TDD)
꿀밋업시리즈3탄_Spring Boot를 활용한 마이크로서비스 개발과 페어프로그래밍(TDD)꿀밋업시리즈3탄_Spring Boot를 활용한 마이크로서비스 개발과 페어프로그래밍(TDD)
꿀밋업시리즈3탄_Spring Boot를 활용한 마이크로서비스 개발과 페어프로그래밍(TDD)VMware Tanzu Korea
 
모바일 Rpg 게임서버 리팩토링
모바일 Rpg 게임서버 리팩토링모바일 Rpg 게임서버 리팩토링
모바일 Rpg 게임서버 리팩토링기환 천
 
Pivotal Labs 고객사례 - Coinone
Pivotal Labs 고객사례 - CoinonePivotal Labs 고객사례 - Coinone
Pivotal Labs 고객사례 - CoinoneVMware Tanzu Korea
 
"행복한 백발의 개발자"라는 제목으로 2024-03-06 어느 IT 업체에서 직책자로 승진한 분들을 대상으로 한...
"행복한 백발의 개발자"라는 제목으로 2024-03-06 어느 IT 업체에서 직책자로 승진한 분들을 대상으로 한..."행복한 백발의 개발자"라는 제목으로 2024-03-06 어느 IT 업체에서 직책자로 승진한 분들을 대상으로 한...
"행복한 백발의 개발자"라는 제목으로 2024-03-06 어느 IT 업체에서 직책자로 승진한 분들을 대상으로 한...Myeongseok Baek
 
PyCon2020 NLP beginner's BERT challenge
PyCon2020 NLP beginner's BERT challengePyCon2020 NLP beginner's BERT challenge
PyCon2020 NLP beginner's BERT challengeYoongi Kim
 
INFCON2023-지속 가능한 소프트웨어 개발을 위한 경험과 통찰
INFCON2023-지속 가능한 소프트웨어 개발을 위한 경험과 통찰INFCON2023-지속 가능한 소프트웨어 개발을 위한 경험과 통찰
INFCON2023-지속 가능한 소프트웨어 개발을 위한 경험과 통찰Myeongseok Baek
 
Business Driven Development.pdf
Business Driven Development.pdfBusiness Driven Development.pdf
Business Driven Development.pdfssuser24f6db
 
이승재, 박경재, NDC Replay 제작기: static website, static backoffice, NDC2017
이승재, 박경재, NDC Replay 제작기: static website, static backoffice, NDC2017이승재, 박경재, NDC Replay 제작기: static website, static backoffice, NDC2017
이승재, 박경재, NDC Replay 제작기: static website, static backoffice, NDC2017devCAT Studio, NEXON
 
커뮤니티와 함께한 예비개발자 성장기- 조성수님
커뮤니티와 함께한 예비개발자 성장기- 조성수님커뮤니티와 함께한 예비개발자 성장기- 조성수님
커뮤니티와 함께한 예비개발자 성장기- 조성수님NAVER D2
 

Similaire à DevOps는 원격근무를 추구하면 안되는 걸까? (20)

멸종하는 공룡이 되지 않으려면
멸종하는 공룡이 되지 않으려면멸종하는 공룡이 되지 않으려면
멸종하는 공룡이 되지 않으려면
 
쿠키런 1년, 서버개발 분투기
쿠키런 1년, 서버개발 분투기쿠키런 1년, 서버개발 분투기
쿠키런 1년, 서버개발 분투기
 
131 deview 2013 yobi-채수원
131 deview 2013 yobi-채수원131 deview 2013 yobi-채수원
131 deview 2013 yobi-채수원
 
스마일게이트 서버개발캠프 - HGHSS - 합격하소서
스마일게이트 서버개발캠프 - HGHSS - 합격하소서스마일게이트 서버개발캠프 - HGHSS - 합격하소서
스마일게이트 서버개발캠프 - HGHSS - 합격하소서
 
Critical_Chain.pdf
Critical_Chain.pdfCritical_Chain.pdf
Critical_Chain.pdf
 
소프트웨어 개발 프로세스 배경 설명
소프트웨어 개발 프로세스 배경 설명소프트웨어 개발 프로세스 배경 설명
소프트웨어 개발 프로세스 배경 설명
 
2021년 1월 30일 개발자 이야기
2021년 1월 30일 개발자 이야기2021년 1월 30일 개발자 이야기
2021년 1월 30일 개발자 이야기
 
[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스
[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스
[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스
 
애자일 하라
애자일 하라애자일 하라
애자일 하라
 
하드웨어 스타트업의 소프트웨어 이야기
하드웨어 스타트업의 소프트웨어 이야기하드웨어 스타트업의 소프트웨어 이야기
하드웨어 스타트업의 소프트웨어 이야기
 
2014.04.24.nrise 개발환경
2014.04.24.nrise 개발환경2014.04.24.nrise 개발환경
2014.04.24.nrise 개발환경
 
꿀밋업시리즈3탄_Spring Boot를 활용한 마이크로서비스 개발과 페어프로그래밍(TDD)
꿀밋업시리즈3탄_Spring Boot를 활용한 마이크로서비스 개발과 페어프로그래밍(TDD)꿀밋업시리즈3탄_Spring Boot를 활용한 마이크로서비스 개발과 페어프로그래밍(TDD)
꿀밋업시리즈3탄_Spring Boot를 활용한 마이크로서비스 개발과 페어프로그래밍(TDD)
 
모바일 Rpg 게임서버 리팩토링
모바일 Rpg 게임서버 리팩토링모바일 Rpg 게임서버 리팩토링
모바일 Rpg 게임서버 리팩토링
 
Pivotal Labs 고객사례 - Coinone
Pivotal Labs 고객사례 - CoinonePivotal Labs 고객사례 - Coinone
Pivotal Labs 고객사례 - Coinone
 
"행복한 백발의 개발자"라는 제목으로 2024-03-06 어느 IT 업체에서 직책자로 승진한 분들을 대상으로 한...
"행복한 백발의 개발자"라는 제목으로 2024-03-06 어느 IT 업체에서 직책자로 승진한 분들을 대상으로 한..."행복한 백발의 개발자"라는 제목으로 2024-03-06 어느 IT 업체에서 직책자로 승진한 분들을 대상으로 한...
"행복한 백발의 개발자"라는 제목으로 2024-03-06 어느 IT 업체에서 직책자로 승진한 분들을 대상으로 한...
 
PyCon2020 NLP beginner's BERT challenge
PyCon2020 NLP beginner's BERT challengePyCon2020 NLP beginner's BERT challenge
PyCon2020 NLP beginner's BERT challenge
 
INFCON2023-지속 가능한 소프트웨어 개발을 위한 경험과 통찰
INFCON2023-지속 가능한 소프트웨어 개발을 위한 경험과 통찰INFCON2023-지속 가능한 소프트웨어 개발을 위한 경험과 통찰
INFCON2023-지속 가능한 소프트웨어 개발을 위한 경험과 통찰
 
Business Driven Development.pdf
Business Driven Development.pdfBusiness Driven Development.pdf
Business Driven Development.pdf
 
이승재, 박경재, NDC Replay 제작기: static website, static backoffice, NDC2017
이승재, 박경재, NDC Replay 제작기: static website, static backoffice, NDC2017이승재, 박경재, NDC Replay 제작기: static website, static backoffice, NDC2017
이승재, 박경재, NDC Replay 제작기: static website, static backoffice, NDC2017
 
커뮤니티와 함께한 예비개발자 성장기- 조성수님
커뮤니티와 함께한 예비개발자 성장기- 조성수님커뮤니티와 함께한 예비개발자 성장기- 조성수님
커뮤니티와 함께한 예비개발자 성장기- 조성수님
 

Plus de Jesang Yoon

AWS Cloud Job Fair 2022 발표자료
AWS Cloud Job Fair 2022 발표자료AWS Cloud Job Fair 2022 발표자료
AWS Cloud Job Fair 2022 발표자료Jesang Yoon
 
Amazon Aurora로 안전하게 migration 하기
Amazon Aurora로 안전하게 migration 하기Amazon Aurora로 안전하게 migration 하기
Amazon Aurora로 안전하게 migration 하기Jesang Yoon
 
Project TIMAT - infrastructure as code
Project TIMAT - infrastructure as codeProject TIMAT - infrastructure as code
Project TIMAT - infrastructure as codeJesang Yoon
 
AWS S3를 이용한 효과적인 SPA 배포
AWS S3를 이용한 효과적인 SPA 배포AWS S3를 이용한 효과적인 SPA 배포
AWS S3를 이용한 효과적인 SPA 배포Jesang Yoon
 
AWS Lambda를 이용한 CI/CD 기법
AWS Lambda를 이용한 CI/CD 기법AWS Lambda를 이용한 CI/CD 기법
AWS Lambda를 이용한 CI/CD 기법Jesang Yoon
 
대기업에서 스타트업 까지 - 윤제상
대기업에서 스타트업 까지 - 윤제상대기업에서 스타트업 까지 - 윤제상
대기업에서 스타트업 까지 - 윤제상Jesang Yoon
 
node.js 실무 - node js in practice by Jesang Yoon
node.js 실무 - node js in practice by Jesang Yoonnode.js 실무 - node js in practice by Jesang Yoon
node.js 실무 - node js in practice by Jesang YoonJesang Yoon
 

Plus de Jesang Yoon (7)

AWS Cloud Job Fair 2022 발표자료
AWS Cloud Job Fair 2022 발표자료AWS Cloud Job Fair 2022 발표자료
AWS Cloud Job Fair 2022 발표자료
 
Amazon Aurora로 안전하게 migration 하기
Amazon Aurora로 안전하게 migration 하기Amazon Aurora로 안전하게 migration 하기
Amazon Aurora로 안전하게 migration 하기
 
Project TIMAT - infrastructure as code
Project TIMAT - infrastructure as codeProject TIMAT - infrastructure as code
Project TIMAT - infrastructure as code
 
AWS S3를 이용한 효과적인 SPA 배포
AWS S3를 이용한 효과적인 SPA 배포AWS S3를 이용한 효과적인 SPA 배포
AWS S3를 이용한 효과적인 SPA 배포
 
AWS Lambda를 이용한 CI/CD 기법
AWS Lambda를 이용한 CI/CD 기법AWS Lambda를 이용한 CI/CD 기법
AWS Lambda를 이용한 CI/CD 기법
 
대기업에서 스타트업 까지 - 윤제상
대기업에서 스타트업 까지 - 윤제상대기업에서 스타트업 까지 - 윤제상
대기업에서 스타트업 까지 - 윤제상
 
node.js 실무 - node js in practice by Jesang Yoon
node.js 실무 - node js in practice by Jesang Yoonnode.js 실무 - node js in practice by Jesang Yoon
node.js 실무 - node js in practice by Jesang Yoon
 

DevOps는 원격근무를 추구하면 안되는 걸까?

  • 1. DevOps 팀은 원격근무를 추구하면 안되는 것일까? 2019. 10. 31 jesang.yoon@hbsmith.io
  • 3. • 2018년 부터 AWS 공식 Technology Partner • 웹/앱 서비스의 QA 테스트를 자동화 해주는 SaaS 솔루션을 개발 & 운영하고 있습니다. • 매 2주마다 패치를 3년째 하고 있습니다. • 전원 원격 근무를 하고, 모든 회의를 원격으로 하고 있습니다.
  • 6. • 장애가 발생하면 제때 대응이 가능한가요? • 개발자들이 일 잘 하고 있는지 확인이 가능한가요? • 일정을 맞추기 어렵지 않나요?
  • 7. DevOps 팀은 원격근무 를 추구하면 안되는 걸까 요? 출처: Auction
  • 9. • HBsmith의 DevOps 팀은 어떤 프로세스로 일하고 있는가? • HBsmith의 DevOps 시스템은 어떻게 되어 있는가? • HBsmith의 DevOps 문화는 어떤가?
  • 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
  • 58. QA 테스트 OP 배포 Issue 생성/지 정 스프린트 회의 Issue 세부논의 JIRA/Confluence PR 생성 GitHub Code Review GitHub Issue 및 PR 정리 OP 테스트 Merge 되지 못한 PR은 논의 후 Close 1 Sprint = 2 Weeks = 10 Working Days Merge 되지 못한 PR은 논의 후 Reopen Code Freeze
  • 60. • 가끔 점심 회식을 합니다. • 대신 분기에 1번 또는 상하반기에 1번씩 전체 워크샵을 갑니 다. • 공기 좋은 곳에서 질 좋은 음식을 먹습니다. • 회사의 과거, 현재, 미래에 대해 같이 이야기 합니다. • 간단한 액티비티/해커톤/페어 프로그래밍도 합니다. • 커피는 마시지만 술은 거의 안마십니다.
  • 63. • 외부 고객도 중요하지만 내부 고객(임직원)은 더 중요합 니다. • 임원들이 돌아다니며 팀의 모든 임직원과 1:1 로 밥을 먹 고 커피를 마십니다. • 최소 2시간 부터 4~5시간 까지 이야기를 나누기도 합니 다. • 가벼운 근황공유 부터 속 깊은 이야기 까지 대화를 나눕 니다. • One-to-One 때 나온 피드백이 좋은 개선을 불러온적이 많습니다.
  • 65. • 최신 MacBook Pro를 지급합니다. (32G Ram) • 2년 근속시 개인소유, 2년에 한번 업그레이드 합니다. • 업무용 SW는 회사에서 사줍니다. • 외부 컨퍼런스, 미팅 비용은 회사에서 대줍니다. • 경조사 지원, 병원비 지원, 명절선물 지원 있습니다. • 코스트코 회원 카드 (비즈니스)를 줍니다. - 한정
  • 67. • 장애가 발생하면 제때 대응이 가능한가요? => 시스템 알람 뿐만 아니라 임직원들이 서로 전파합니다. • 개발자들이 일 잘 하고 있는지 확인이 가능한가요? => 업무 상황이 시스템에 모두 기록되어 누가 뭐 하는지 실시간으로 서로 알수 있습니다. • 일정을 맞추기 어렵지 않나요? => 업무를 추정하여 완급을 조절합니다.
  • 68. • DevOps 팀이 원활한 원격근무가 가능하려면: • 추적가능하고 재현가능한 자동화 달성 • 명확하고 투명한 정보 공유 • 시스템을 바탕으로 업무 • 원칙과 프로세스를 꾸준히 지키고 유지 • 실행은 직원이 책임은 임원이 • 이 모든게 며칠이 아닌 수개월 수년동안의 지속적인 실험/개선의 결과입 니다.
  • 70. 저희와 같이 성장할 개발자를 찾고 있습니다. 연락주세요 :) hello@hbsmith.io