데브옵스 알아가기(5) : 3Ways - 제2방법
Updated:
전 편에 이어 3Ways의 제 2원칙에 대한 내용을 소개합니다.
이 글을 이해하기 위해서 먼저 앞에 있는 내용부터 차근차근 읽어보셔야 합니다. 적어도 데브옵스 알아가기 3편부터라도 읽는다면 도움이 될 것입니다.
- 데브옵스 알아가기 1편 - 애자일 vs 데브옵스
- 데브옵스 알아가기 2편 - 그럼 데브옵스란 ?
- 데브옵스 알아가기 3편 - 데브옵스 구현 전략
- 데브옵스 알아가기 4편 - 3Ways개요 및 제1원칙
2nd Way : The principle of Feedback
두번째는 개발과 운영 상호간 “신속하고 지속적”인 피드백이 일어나야 한다는 원칙이다.
“신속하고 지속적인” 피드백이라는 부분에 주목하시라.
피드백은 즉각적으로 주어져야 의미가 있다. 예컨대, 오늘 테니스 연습을 하고 나서, 1년쯤 후에 당신이 O월O일 연습했던 동작 중에 문제가 있다는 식으로 피드백이 주어진다면 어떻게 될까? 1년 전에 취했던 그 동작이 어떤 동작이었는지 정확히 기록해 놓지 않았다면 아무짝에도 쓸모가 없을 것이다. 무엇보다 이미 한 해 동안 문제가 있는 동작으로 연습해왔기 때문에 굳어진 습관을 바꾸는 데에는 배 이상의 수고가 든다.
그런데, 여기서 조직에 즉각적인 피드백이 일어나지 않는 원인을 생각해 볼 필요가 있다. 피드백을 자신의 작업 결과에 대한 공격으로 여긴다던가, 또는 개선이 필요하다는 의견 자체를 수치심으로 받아들인다면 이는 개인적인 성향이 아니라, 무언가 의견을 다는 것 자체를 예의에 어긋나거나 부정적인 행동 양식으로 여기는 암묵적인 조직 문화에서 기인하기 때문이다.
아마존에서는 이러한 서로의 작업에 토를 달지 않는 “아름다운 화합 문화”를 절대적으로 배격한다. 언제든, 누구든 문제를 발견하면 직설적으로 이야기할 수 있어야 결함을 찾아내고 제거할 수 있다고 본다.
조직 내에 지속적으로 피드백할 수 있는 문화와 시스템을 갖춤으로써 피드백을 주는 것과 받는 것 모두 부담스럽지 않은 자연스러운 업무의 일상으로 나타날 수 있도록 조성하는 것이 필요하다.
책에서는 이러한 피드백을 가속화하고 지속하기 위한 원칙으로 다음의 5가지를 제시한다.
① 복잡한 시스템에서 안전하게 작업할 수 있도록 해야 한다.
작업으로 인해 치명적인 시스템 오류가 발생할 가능성이 있다면 이를 빠르게 감지할 수 있는 시스템이 필요하다. 작업이 무사히 끝났다는 확인 메시지나 시그널이 즉각 전달됨으로써 작업자는 추가적인 상태 체크나 별도의 조치를 취하지 않아도 된다.
② 문제는 발생시점에서 즉시 확인해야 한다.
위에서 이야기한 것과 같이 현장에서 발생된 문제는 현장에서 바로 해결이 되어야 하며, 문제에 대한 피드백은 즉각적으로 주어져야 의미가 있다.
③ 스워밍(swarming)* 해결 및 지식축적
스워밍*이란 군사용어로 목표를 향해 집중적으로 떼를 지어 공격하는 전술을 말한다. 즉, 문제발생시 단순히 감지에서 끝나지 않고 적극적으로 문제를 해결해야 하며, 재발방지를 위해 필요한 리소스를 동원하는 것이다.
④ 품질활동을 실제에 더 가깝게 유지
검토, 리뷰, 승인과 같은 기술가치에 적접 기여하지 않는 불필요한 피드백은 제거한다. 오히려 개발자간 코드 리뷰 활동을 장려하여 품질에 기여할 수 있다.
⑤ 다운스트림 워크센터* 최적화
다운스트림 워크센터*란 고객과 공감대를 형성하는 고객 접점 업무 영역을 말한다. 즉, IT는 우리의 고객이 자신의 고객을 더 잘 상대할 수 있도록 해당 업무를 최적화해야 한다는 의미이다.
피드백을 위한 기술적 실천 방법
두번째 피드백 가속화를 위한 기술적 실천 방법들은 피드백 루프를 단축하고 증폭시키는 것들이다. 문제가 발생하자마자 이를 파악하고, 파악된 정보가 필요한 사람들에게 빠르게 전파되도록 하는 것을 목표로 한다. 피드백 활성화는 궁극적으로 문제해결, 더 나은 품질의 향상을 가져올 수 있다.
① 문제의 확인과 해결을 가능하게 하는 텔레메트리(telemetry) 생성
우리나라 말로 ‘원격 측정법’이라고 불리우는 텔레메트리는 관측 대상으로부터 떨어진 원격 지점에서 다양한 관측을 수행하고 그 데이터를 취득하는 기술을 말한다. 텔레메트리를 통해 운영중인 시스템의 다양한 데이터와 측정 자료를 수집하고 수신함으로써 원격에서도 모니터링이 가능하다.
APM도 일종의 텔레메트리로 볼 수 있다. 운영 시스템에 텔레메트리를 구축하게 되면 시스템의 문제를 즉각 인지하고, 원인까지도 파악 가능하기 때문에 현대적인 운영 환경에서는 꼭 필요한 기능이라 볼 수 있다.
문제는 이런 텔레메트리의 접근이 일부 인프라 운영자 또는 몇몇 담당자에게만 허용이 되어 있다는 것이다. 어플리케이션을 직접 개발하고 운영하는 담당자까지도 상시로 APM을 사용하게 된다면, 보다 조기에 문제를 발견할 수 있으며 예측도 가능하다.
또한 대량 로그가 발생하기 때문에 정작 운영 단계에서는 Critical 메시지를 제외한 대부분의 로그를 Off시키는 경우가 있는데, 이런 경우 결국에는 Critical 오류가 발행했을 때에만 문제가 인지가 되므로 조기경보나 사전 예측은 불가능하다.
텔레메트리 구축시 모든 것을 추적하기보다는 추적을 쉽게 하는 방법이 필요하다. 그리고 운영되는 시스템 외에 빌드-배포 과정에 대해서도 텔레메트리도를 생성한 다면 자동화된 빌드-배포 과정에서 문제 발생시 바로 인지가 가능하게 된다.
최근에는 ELK, Prometheus, Zipkin, Sleuth와 같은 오픈소스가 많아 텔레메트리를 쉽게 구축할 수 있다.
② 문제에 대한 더 나은 예측과 목표 달성을 위한 텔레메트리 분석
오래전에 신규 시스템을 오픈하고 얼마 동안 새벽마다 오는 전화에 시달린 적이 있다. 데이터 센터에 근무하는 OP요원이 시스템에 어떤 경고가 뜨면 개발 책임자였던 필자의 비상연락망으로 전화를 하였던 것이다. 그러나 OP 요원이 불러주는 경고용 메시지는 배치 Controller가 내보내는 메시지였고, 또한 프로그램 상태도 의도하지 않은 오류가 아니라, 정상적인 오류 메시지였다. APM을 주관하는 책임자는 인프라 팀이었고, 인프라 담당자가 APM에 경고를 위한 임계값 설정시 배치 Controller가 주는 메시지만 참고하였던 것이 문제였던 것이다. 그리고 개발팀에서는 APM이란 도구가 들어오는지도 몰랐기 때문에 (당시만 하더라도 인프라 담당자들만 사용했던 도구), 에러 메시지를 일부러 구분하여 코딩할 필요를 몰랐었다. 텔레메트리를 어렵게 구축하고도, 어떠한 측정 목표를 가지고 어떤 측정값을 이용해야 할지, 누구와 공유를 할 것인지 미리 정의하지 않는다면 무용지물이 될 것이다. 이와 마찬가지로 측정 결과 또한 올바른 분석을 통해 유효한 결과를 얻어야 한다. 특히 평균값과 표준 편차를 사용하는 정규 분포를 벗어나는 이상 징후에 대해서는 스무딩이나 콜모고로-스미르노프 같은 다양한 인텔리전트 분석 기법을 적용해야 한다. 그라파이트나 그라파나 같은 툴은 다양한 통계 기법으로 이상 탐지와 문제 해결을 위한 사고 예측이 가능한 대시보드를 제공해준다.
※ 데이터 스무딩
데이터 스무딩이란 데이터에서 원치 않는 잡음이나 동작을 제거하는 기법이다. 아래 그림과 같이 변이가 촘촘한 그래프에서 잡음을 제거해 나가다 보면 나머지 데이터와 큰 차이가 있는 있는 그래프만을 식별해 낼 수 있다. 이를 통해 이상 데이터를 탐지할 수 있다.
③ 개발-운영의 안전한 코드 배포를 위한 피드백 활성화
개발자가 소스 배포시 부담스러운 이유는 무엇일까? 예상치 못한 장애의 발생이 가장 두려울 것이다. 그렇다면 장애를 예방할 방법은 없을까? 각종 테스트와 텔레메트리를 통한 조기 예측 시스템 구축 등 만전을 기하더라도 100% 피해갈 수는 없다.
완벽한 대응은 불가능하더라도 조금이라도 오류 발생 가능성을 줄이기 위한 방책으로 개발-운영자간 피드백을 활성화하는 방법이 있다. 개발과 운영은 소스 코드 배포가 원활히 될 수 있도록 서로 도와야 한다.
애초에 데브옵스가 탄생한 배경 원인에 개발-운영간 갈등이 있었다. 그 갈등을 줄이기 위해 개발-운영간의 관계가 선순환되도록 해야 하는 것이 본 내용의 골자이다. 운영자가 개발 초기부터 관여함으로 운영의 지식을 개발팀에 제공하거나, 개발팀이 직접 운영 업무를 수행해 봄으로써 운영 측면의 관리 포인트를 감안하여 기능 개발에 반영할 수 있다. 상호간의 잦은 피드백과 업무 순환은 서로의 입장을 이해하여 높은 품질의 제품 개발에 기여할 것이다.
④ 가설주도 개발, A/B테스팅의 일상화
가설주도 개발이란 제품 또는 전략에 대한 새로운 가설을 검증하기 위하여 고안된 개발이다. 쉽게 이야기하면 프로토타입 개발 또는 MVP(Minimum Valuable Product) 모델 개발 등을 꼽을 수 있다. 시장에 전격 출시했을 경우 실패의 위험도가 높은 제품에 대해 작은 기능의 프로토타입이나 MVP를 만들어 출시하여 고객과 시장의 반응을 피드백 받음으로써 향후 출시될 제품에 대한 성공 여부를 짐작할 수 있다.
A/B 테스팅 기법은 마케팅 전략에서 생겨난 것으로 많은 기업들이 주로 고객 선호도를 조사하기 위해 사용한다.
“가설주도 개발과, A/B 테스팅을 일상화”는 일반적인 IT 현장의 프로세스 개선과는 조금 거리가 있다. 대신 B2C 업무 또는 성공적인 UI/UX 구현을 필요로 하는 조직의 IT 운영팀에서 이러한 방식의 개발이 고객의 고객 피드백을 이해함으로써 진짜 고객이 원하는 기능의 출시를 앞당길 수 있을 것이다.
⑤ 작업 품질 향상을 위한 리뷰/조정 프로세스 추가
저자는 나이트 캐피털사의 프로그램 배포 오류로 인한 금융 사고는 실패한 변경 통제와 테스팅에서 기인한다고 본다. 변경 통제가 있었는데도 실패했다는 건데, 신뢰도가 낮은 명령/통제 문화에서는 형식적인 변경 통제와 테스트로 오히려 없느니만 못한 상황이 되는 것이다.
또한 과도한 변경 통제는 기술가치흐름에 직접 기여하지 않는 제3자의 승인을 필요로 하는 것으로 승인을 획득하기 위한 보고와 이해의 과정에서 더 많은 커뮤니케이션과 불필요한 지연으로 인하여 리드타임이 증가되기도 한다.
코드의 품질을 향상시키면서도 효과적으로 이해당사자들을 이해시키기 위한 방법으로는 동료 검토(Peer Review)가 있는데 동료 검토의 효과성에 대해서는 이미 수십년간 검증되어 오고 있다. 정례화된 소스 코드의 리뷰는 조직에 들어온 신참자의 학습을 돕기도 한다. 리뷰에는 동료검토 외에 Pair Programming 이나 오버더 숄더(Over-the-shoulder), Tool-Assisted Code Review의 형태도 있다.
또한 의존성 관계가 있는 시스템 작업에 대해서는 변경 통제보다는 조정을 통해 충돌을 방지해야 한다. 강제적인 조정보다는 영향이 있는 시스템의 변경이 있을 경우 엔지니어 스스로가 미리 변경사항을 통보하고 영향도를 검토하게 하여 프로그램 수정이 다른 시스템에 미치는 범위를 인지하도록 하는 것이 필요하다.
정리
제 2원칙에서는 텔레메트리 구축을 위한 지표나 수학적 측정 방법 등이 소개되면서 어렵고 복잡해진 느낌이 들긴 하지만, 제 2원칙이 피드백에 대한 것임을 주목해야 한다.
우리가 생각하는 피드백이란 보통 주관적인 감정과 의견을 표현하는 것인데, 여기서의 피드백은 비언어적 시그널과 같은 기계적인 반응을 포함한다. 사실 주관적인 사람의 피드백은 말 그대로 개인적 차이가 크며 신뢰할 수 없는 경우가 많다.
제대로 된 피드백을 적기에 얻기 위해서는, 때로 감정없이 열심히 자기 일을 하는… 그러면서도 복잡한 수식을 계산하는 기계의 힘을 빌릴 필요도 있다. 문득 많은 일을 열심히 하지만 포장이나 Self 홍보에 서툴러서 고객이나 상사에게 좋은 피드백을 받지 못하는 개발자가 있다면, 3Ways에서 말하는 피드백 방법을 통해서는 좋은 평가를 받을 수 있지 않을까 하는 생각이 든다. 기계는 객관적으로 측정하고 반응할테니…
본 블로그의 주된 내용은 다음을 참고하여 작성하였음을 밝힙니다.
< EOF >