닫기

DevOps: 개발팀 및 운영팀 사이의 장벽 허물기

DevOps란?

DevOps는 경쟁력을 제공합니다

"DevOps를 통해 제품을 자주 릴리스하고, 시기적절하게 시장 경쟁력을 갖추게 되었습니다. 이제 6개월마다 릴리스하는 대신 매일 제품을 릴리스할 수 있으며 몇 시간 안에 고객에게 수정 사항을 전달할 수 있습니다."

— Hamesh Chawla, Zephyr 엔지니어링 부서 부사장

DevOps란 소프트웨어 개발팀과 IT팀이 더 빠르고 안정적으로 소프트웨어를 빌드, 테스트 및 릴리스할 수 있도록 두 팀 간의 프로세스를 자동화하는 일련의 과정입니다. DevOps의 개념은 지금까지 상대적으로 사일로된 환경에서 일해 온 팀 간에 협업 문화를 구축하는 것입니다. 이를 통해 깊은 신뢰감을 쌓고, 소프트웨어 릴리스 속도를 높이고, 크리티컬 이슈를 빠르게 해결하고, 미리 계획하지 않은 업무를 더 잘 관리할 수 있는 등의 혜택이 보장됩니다.

DevOps는 최고의 소프트웨어 개발과 IT 운영을 결합한 합성어로, Atlassian에서 '브란젤리나'(Brad Pitt와 Angelina Jolie의 합성어) 다음으로 가장 유명한 단어입니다. 그리고 '브란젤리나'와 마찬가지로 DevOps도 배경 설명이 필요합니다. 

본질적으로 DevOps는 문화이자 운동이며 철학입니다.

DevOps는 사고방식의 변화, 협업 향상 및 긴밀한 통합을 강조하는, 개발팀 및 운영팀 간의 견고한 파트너십입니다. DevOps는 애자일, 지속적 배포, 자동화 등을 통합하며, 개발팀 및 운영팀이 더욱 효율적으로 작업하고 더 빠르게 혁신하며 기업과 고객을 대상으로 더 큰 가치를 제공할 수 있도록 돕습니다.

DevOps의 역사

2007년~2008년 즈음,  IT 운영 및 소프트웨어 개발 커뮤니티가 업계에 치명적인 문제가 있는 것 같다는 목소리를 내면서 DevOps 통합의 움직임이 시작되었습니다.

이들은 코드를 작성하는 사람과 코드를 배포하고 지원하는 사람이 조직적으로도 직무상으로 분리되어 있는 기존의 소프트웨어 개발 모델에 반기를 들었습니다.

개발자 및 IT/Ops 전문가는 서로 다른 목표(대개 경쟁하는 목표), 서로 다른 부서 리더십, 서로 다른 주요 성과 지표를 가지고 있었으며, 다른 층이나 심지어 다른 빌딩에서 근무하는 경우도 많았습니다. 그 결과 두 커뮤니티는 사일로화되어 각자의 분야나 투입 시간, 릴리스 실패, 고객 불만에만 신경 쓰는 팀이 되었습니다.

두 커뮤니티는 분명 더 좋은 방법이 있다는 데 동의하였고, 함께 모여 Patrick Dubois, Gene Kim, John Willis의 주도 아래 대화를 시작했습니다.

이제는 온라인 포럼 및 지역 모임에서 무엇이 시작되었는지가 소프트웨어 시대정신의 주요 주제이며, 여러분도 아마 같은 이유로 Atlassian을 방문하셨을 것입니다. 여러분과 여러분의 팀은 사일로화된 팀과 회사 내 커뮤니케이션 라인이 무너짐으로 인해 어려움을 겪고 있습니다.

계획 및 개발에 애자일 방법론을 사용하더라도 해당 코드를 문제 없이 실제로 활용하기 위해서는 노력이 필요합니다. DevOps와 DevOps가 팀에게 가져다주는 마법과 같은 효과에 대해 들으셨다면 '나도 경험해 보고 싶다'는 생각이 들 것입니다.

하지만 DevOps는 모든 것을 해결해 주는 마법이 아니며 변화는 하루아침에 일어나지 않습니다. 그럼에도 DevOps를 사용하면 고위 관리층이 대규모 이니셔티브를 시작하기를 기다릴 필요가 없습니다. DevOps의 가치를 이해하고 작지만 많은 변화를 이룩함으로써 바로 DevOps 여정을 시작할 수 있습니다. 이제 이러한 장점에 대 각각 자세히 살펴보겠습니다.

IaC(Infrastructure as Code)를 이용하면 팀에 사람을 추가하지 않고도 10배 더 많은 빌드를 수행할 수 있습니다. — Michael Knight, Atlassian 빌드 엔지니어

장점은 무엇입니까?

협업 및 신뢰

문화는 DevOps의 핵심 성공 요소입니다. 높은 성과를 내는 DevOps 팀에는 책임을 공유하고, 투명하게 업무를 진행하고, 빠른 피드백을 제공하는 문화가 구축되어 있습니다.

사일로화된 환경에서 업무를 수행하는 팀은 대게 DevOps의 '시스템적 사고'를  지키지 않습니다. '시스템적 사고'란 여러분의 행동이 여러분 팀뿐만 아니라 릴리스 프로세스에 관여하고 있는 다른 모든 팀에 어떤 영향을 미치는지를 파악하는 것입니다. 가시성 및 공유 목표가 없다는 것은 의존성 있는 계획의 결여, 잘못된 우선순위, 비난, '우리 문제가 아니라는 식'의 사고방식을 의미하므로 결국 속도 지연과 수준 이하의 품질로 이어집니다. DevOps는 전체적으로 개발 프로세스를 바라보는 태도를 변화시키며 개발 및 운영 사이의 장벽을 허뭅니다.

더 빠른 릴리스, 더 스마트한 업무 진행

가장 중요한 것은 속도입니다. DevOps를 활용하는 팀은 제품을 더 자주 릴리스할 수 있으며, 더 높은 품질과 안정성을 제공할 수 있습니다.

자동화 테스트 및 리뷰 주기가 부족하면 릴리스에서 생산으로 연결되는 과정이 막히며, 인시던트 응답 시간이 느리면 속도가 저하되고 팀의 신뢰성이 떨어집니다. 도구 및 프로세스가 서로 다르면 OPEX가 증가하고, 컨텍스트 전환이 발생하며, 업무 진행 속도가 느려집니다. 자동화와 표준화된 도구 및 프로세스를 통해 팀은 생산성을 높이고, 제품을 자주 릴리스하면서 문제도 줄일 수 있습니다.

문제 해결 시간 단축

가장 빠른 피드백 루프를 가진 팀이 성공하는 팀입니다.완전히 투명하며 원활한 커뮤니케이션을 통해 DevOps팀은 가동 중지를 최소화하고 그 어느 때보다 빠르게 이슈를 해결할 수 있습니다.

크리티컬 이슈를 빠르게 해결할 수 없다면 고객 만족도는 떨어집니다. 열린 커뮤니케이션이 부족하면 주요 이슈가 제대로 논의되지 못하여 팀 간의 갈등과 불만이 발생합니다. 열린 커뮤니케이션은 개발팀 및 운영팀이 함께 모여 이슈를 해결하고 인시턴트를 수정하고 릴리스 속도를 높이는 데 도움이 됩니다.

계획되지 않은 업무를 쉽게 관리

어떤 팀이든 계획되지 않은 업무를 마주하게 됩니다. 계획되지 않은 업무는 대개 팀 생산성에 영향을 미칩니다. 프로세스를 확립하고 명확한 우선순위를 지정하면 개발팀 및 운영팀은 계획한 업무에 계속해서 집중하는 동시에 계획되지 않은 업무도 더 잘 관리할 수 있습니다.

계획되지 않은 업무를 다른 팀이나 시스템으로 전환하거나 우선순위를 지정하는 것은 비효율적이며 팀원이 진행하던 업무에 계속 집중할 수 없게 만듭니다. 그러나 가시성 향상 및 사전 회고를 통해 팀은 계획되지 않은 업무를 더 잘 예측하고 공유할 수 있습니다.

DevOps의 CALMS 프레임워크

문화

DevOps 문화는 한 단어로는 '협업', 두 단어로는 '다기능 협업'이라고 요약할 수 있습니다.

이 세상의 모든 도구와 자동화 시스템은 개발 팀원과 IT/Ops 전문가에게 진심으로 협력하고자 하는 마음이 없다면 쓸모가 없습니다. DevOps는 도구의 문제를 해결하는 것이 아니라, 사람 간의 문제를 해결하기 때문입니다. 따라서 어느 날 회사 사무실에서 고개를 내밀어 주위를 둘러보았을 때 불현듯 DevOps 문화를 느낄 수 있는 것이 아닙니다. DevOps 문화를 조성할 수 있는 몇 가지 간단한 방법이 있습니다.

DevOps는 애자일과 많이 닮았지만 운영도 포함된 개념입니다. 프로젝트 또는 제품 중심 팀을 구축하여 기능 기반 팀을 대체하는 것은 올바른 선택입니다. 여기에는 개발, QA, 제품 관리, 설계, 운영, 프로젝트 관리 및 프로젝트에 필요한 기타 스킬셋도 포함되어 있습니다. Atlassian에는 제품 팀과의 마케팅까지도 다루고 있습니다.

공통 목표를 공유하고 이러한 목표를 함께 달성하는 계획을 세우는 등 협업 환경을 조성하는 몇 가지 요소가 있습니다. 일부 회사에서는 프로젝트 기반 팀으로 갑자기 전환하는 일이 너무도 많이, 그리고 너무도 빠르게 일어납니다. 그러니 더 세분화된 단계로 나눠야 합니다. 개발팀은 운영팀에서 적합한 팀원이 스프린트 계획 수립 세션, 일일 스탠드업, 스프린트 데모에 참여하도록 초대할 수 있으며 그렇게 해야 합니다. 운영팀은 핵심 개발자를 초대할 수 있습니다. 이는 서로의 프로젝트, 아이디어 및 노력을 지속적으로 파악할 수 있는 애자일하고도 유기적인 방법입니다. 주제 영역 지식에 대해 듣고 의견을 교환한 시간을 통해 릴리스 관리와 긴급한 문제 해결이 더욱 효율적으로 이루어질 수 있습니다.

긴급한 문제는 DevOps 문화를 효과적으로 테스트하는 계기가 됩니다. 개발팀, 운영팀, 고객 지원팀이 팀으로서 함께 모여 문제를 해결합니까? 모든 사람이 동료가 당시 보유하고 있던 정보와 리소스를 바탕으로 가능한 한 최고의 결정을 내렸다는 가정에 따라 논의를 시작합니까? 인시던트를 출시 후에 분석할 때 어느 팀에서 문제가 발생했느냐를 따지기보다 프로세스를 수정하는 데 초점을 맞추고 있습니까? 답변이 '예'라면 여러분의 팀은 DevOps의 문화를 중심으로 운영되고 있는 것입니다.

성공한 회사 대부분은 모든 부서와 모든 조직 체계에 DevOps 문화를 적용하고 있습니다. 이러한 회사에서는 열린 커뮤니케이션 채널을 갖추고 정기적으로 대화를 진행하며, 모든 사람의 목표를 지정하고 필요에 따라 조정하고, 고객 만족은 제품 관리팀과 개발팀 모두의 책임이라고 생각합니다. 즉, DevOps는 한 팀이 하는 일이 아니라 모든 팀이 함께하는 일이라는 것을 알고 있습니다.

자동화

자동화에 투자하면 반복적인 수동 업무를 없애고, 반복 가능한 프로세스와 안정적인 시스템을 만들 수 있습니다.

자동화 빌드, 테스트, 배포 및 프로비저닝은 이러한 단계를 갖추고 있지 않은 팀이 일반적으로 시작해야 하는 과정입니다. 모두에게 도움이 되는 시스템을 구축하는 것보다 개발자, 테스터 및 운영자가 협력해야 하는 것이 더 중요한 이유는 무엇입니까?

자동화를 처음 접하는 팀은 보통 지속적 배포로 시작합니다. 지속적 배포란 대부분 클라우드 기반 인프라로 촉진된 자동화 테스트를 통해 각 코드 변경 사항을 실행한 다음, 성공적인 빌드를 패키징하고, 자동화 배포를 사용하여 생산을 추진하는 과정입니다. 짐작할 수 있듯이 지속적 배포는 쉽고 빠르게 만들어낼 수는 없지만 ROI는 충분한 가치가 있습니다.

그 이유가 무엇일까요? 컴퓨터는 사람보다 더 엄격하고 충실하게 테스트를 실행하기 때문입니다. 이러한 테스트를 통해 버그 및 보안 문제가 더 빨리 찾아내므로 개발자는 문제를 더 쉽게 해결할 수 있습니다. 또한, 자동화된 배포는 IT/Ops팀에 환경 간 서버 '드리프트'를 경고하므로 릴리스 시기에 발생할 수 있는 의외의 문제를 줄이거나 없애줍니다.

DevOps 또 다른 장점은 'CaC(Configuration as Code)'이라는 개념입니다. 개발자는 더 안정적이며 유지하기 쉽다는 이유로, 구성이 가능한 모듈식 애플리케이션을 만들기 위해 노력합니다. 이와 동일한 개념은 이러한 애플리케이션이 클라우드에 있든지 기업의 자체 네트워크에 있든지와 관계없이 호스팅하는 인프라로 확장될 수 있습니다.

시스템은 언제나 변화합니다. 그러나 우리는 프로비저닝 코드를 사용하여 겉으로 보기에 시스템이 변하지 않는 것처럼 보이게 만들 수 있습니다. 이로써 손상된 서버를 수리하는 것보다 다시 프로비저닝하는 것이 더 빨라집니다. 이는 더 안정적일 뿐만 아니라 위험도 줄어듭니다. 개발팀 및 운영팀은 모두 프로비저닝 코드를 통해 새 언어 또는 기술을 통합하고, 서로 업데이트 내용을 공유할 수 있습니다. 호환성 이슈는 릴리스 도중에 나타나는 것이 아니라 즉각적으로 분명하게 나타납니다.

DevOps 세계에서 자동화 유형이 'CaC(Configuration as Code)' 및 '지속적 배포'만 있는 것은 아니지만, 이 두 유형은 개발 및 운영 사이의 장벽을 허무는 데 도움이 되므로 특별히 언급할 가치가 있습니다. 또한, DevOps에서 자동화 배포를 사용하여 철저한 테스트를 거친 코드를 똑같이 프로비저닝된 환경에 전송하면 '내 컴퓨터에서 수행하는 업무'는 무의미해집니다.

소프트웨어의 맥락에서 '린'이란 보통 가치가 낮은 활동을 없애고 빠르고 적극적이며 애자일하게 움직인다는 의미입니다. DevOps와 가장 관련 있는 개념은 지속적인 개선과 실패 인정입니다.

DevOps 사고방식을 가지면 어디서든 지속적인 개선 기회를 포착할 수 있습니다. 주기적인 회고 등 일부는 명확하게 보이므로 팀의 프로세스를 개선할 수 있습니다. 그러나 그 외에 제품을 처음 사용하는 사용자를 대상으로 각기 다른 온보딩 접근 방식을 사용하는 A/B 테스트 등은 기회를 포착하기 어렵습니다.

Atlassian에는 지속적 개선을 주요 아이디어로 만들어 주는 애자일 개발 방법론이 있습니다. 애자일 방법론을 가장 먼저 도입했던 사람은 고객이 현재 가지고 있는 단순한 제품이 6개월 후에 고객이 갖게 될 완벽한 제품보다 더 가치 있음을 증명했습니다. 제품이 계속해서 개선된다면 고객은 떠나지 않습니다.

한편, 실패는 피할 수 없습니다. 따라서 여러분의 팀이 실패를 받아들이고 문제를 복구하여 이를 통해 교훈을 얻도록 해야 합니다. 누군가는 이런 과정을 '단단해지는 과정'이라고도 합니다. Atlassian은 가끔이라도 실패하지 않는다는 것은 그만큼 충분히 노력하지 않았음을 의미한다고 생각합니다.

Atlassian은 팀에게 어렵지만 독창적인 큰 목표를 던지고 팀이 이러한 목표를 이룰 수 있는 자율성과 리소스를 갖추게 합니다. 또한, 똑똑하고 열정이 넘치는 사람들을 고용하지만 그들이 실패를 겪기를 바라기도 합니다.

DevOps의 컨텍스트에서 실패는 처벌받아야 하는 범죄가 아닙니다. 팀은 언젠가는 반드시 문제가 생길 것이라고 가정하므로 빠른 탐지 및 복구가 가능하도록 빌드합니다. (이를 완벽하게 설명해 주는 예시를 보려면 Nexflix의 Chaos Monkey에 대해 읽어 보시기 바랍니다.) 출시 후에는 코드를 잘못 작성한 팀원을 찾는 것보다 프로세스의 어디가 잘못되었는지, 어떻게 프로세스를 강화할 수 있는지에 집중합니다. 그 이유는 바로 지속적 개선과 실패가 밀접하게 관련되어 있기 때문입니다.

DevOps는 개발에 운영의 개념을 포함하도록 발전했으며, 바로 이것이 Chef의 운영 방식입니다. 우리는 더 이상 문제를 다른 부서로 미룰 수 없습니다. Chef의 엔지니어들은 고객에게 소프트웨어를 제공하기 위해 QA를 책임지고 자체 테스트를 작성하고 실행해야 합니다. — Julian Dunn, Chef 제품 관리자

측정

데이터가 없으면 지속적인 개선을 위한 노력이 실제 개선으로 이어진다고 증명하기가 어렵습니다. 다행히도, 사용자가 제품을 사용한 시간, 블로그 게시물이 판매로 이어졌는지 여부, 중요한 경고가 로그에 자주 등장하는지 등 성능을 측정하는 도구 및 기술이 많이 있습니다.

무엇이든 측정할 수 있다고 해서 모든 것을 측정해야 하는 것은 아닙니다. 애자일 개발 방법에 따라 다음 기본사항을 확인해 보세요.

  • 개발에서 배포에 이르기까지 얼마의 시간이 소요되었습니까? 
  • 버그 또는 장애가 얼마나 자주 반복됩니까?
  • 시스템 장애 발생 후 복구하는 데 시간이 얼마나 소요됩니까?
  • 현재 여러분의 제품을 사용 중인 사용자는 몇 명입니까?
  • 이번 주에 등록/해지한 사용자는 몇 명입니까?

기초가 탄탄하면 기능 사용, 고객 경험 및 SLA(서비스 수준 계약)와 관련된 더 복잡한 메트릭을 포착할 수 있습니다. 이렇게 얻게 되는 정보는 로드맵을 작성하고 다음 계획을 세부적으로 세울 때 도움이 됩니다.

이러한 유용한 데이터는 모두 여러분의 팀이 결정을 내리는 데 도움을 주지만, 다른 팀, 특히 다른 부서의 팀과 공유될 때 더 강력한 힘을 발휘합니다. 예를 들어, 여러분의 마케팅 팀에서는 판매할 수 있는 새롭고 눈부신 기능을 원하지만, 여러분은 제품의 기술적 부채로 인해 상당한 고객 이탈을 겪고 있다고 해 봅시다. 로드맵에 도움이 되는 사용자 데이터를 제공하면 비록 기능이 부족하고 수정할 사항은 많더라도 이해 관계자의 합의와 동의를 얻기 쉬워집니다.

DevOps는 한 사람이 하는 일이 아니라 모두가 함께해야 하는 일입니다. — Christophe Capel, Jira Service Desk 주요 제품 관리자

공유

개발팀과 운영팀 간의 오랜 마찰은 대부분 공유하는 부분이 부족하여 발생합니다. Atlassian은 책임과 성공을 공유하면 이러한 차이를 좁히는 데 큰 도움이 될 것이라고 생각합니다. 개발자는 운영팀의 큰 부담 중 하나인 페이저를 도와 즉각적으로 호의를 얻을 수 있습니다. DevOps는 애플리케이션을 빌드한 사람들이 애플리케이션의 출시와 실행에도 참여해야 한다는 아이디어를 중심으로 합니다.

이는 개발자를 고용하여 단순히 훌륭한 운영을 해주기 바라는 것이 아니라, 개발자 및 운영자가 애플리케이션 라이프사이클의 모든 단계를 함께한다는 것을 의미합니다.

DevOps를 활용하는 팀은 대개 역할을 돌아가며 맡으며, 개발자가 최종 사용자가 발견한 이슈를 해결하면서 이와 동시에 생산 문제를 해결합니다. 이 개발자는 고객이 보고한 긴급한 이슈에 대응하며, 필요한 경우 패치를 생성하고, 고객이 보고한 결함을 백로그로 만듭니다. '지원하는 개발자'는 애플리케이션이 실제로 사용되는 방법에 대해 자세히 알게 됩니다. 또한, 운영팀을 적극적으로 지원함으로써 개발팀은 신뢰와 상호 존중을 형성합니다.

힘든 시기를 함께 겪으면 성공의 달콤함 또한 더욱 깊어집니다. DevOps 문화는 예를 들어 제품을 릴리스하는 날 개발팀이 운영팀에게 베이글을 사다 주는 일 등을 통해 굳건해집니다.

동료들의 긍정적인 피드백은 급여와 경력에 대한 욕심만큼이나 우리에게 동기를 유발해 줍니다. 따라서 심각한 버그가 영향을 주기 전에 이를 찾아낸 팀원을 많은 사람 앞에서 칭찬하는 것은 매우 중요합니다. 만약 여러분의 부서에 이러한 직원에게 보상을 줄 수 있는 재량이 있다면 반드시 활용하시기 바랍니다.

DevOps 여정을 시작할 준비가 되셨습니까?

여정 시작하기