📚 [일상] Devops 이야기 - 1 - Devops가 뭐야?

Category: DailyLife | 📅 July 06, 2021

조직인가 역할인가

Devops (데브옵스). 이 단어가 유행한지도 벌써 5~6년은 지난듯 한데..
갑자기 이 이야기를 쓰는 이유는 우연치 않은 기회로
단어 뜻대로 이해하고 있는 HR 담당자 또는 CTO(?) 분들을 경험하고 나서 쓰게 됐다.

데브옵스, 개발운영. .운영개발… 구색갖추기 .. 여러가지로 쓰이고 있긴 하지만, 한마디로 말해보자면

한마디로, ” Devops 는 조직내에 운영과 개발이 서로 공존하는 시스템” 으로 볼 수 있다.

이 얘기는

“개발자가 개발도 하고 운영도 하고”
“운영자는 운영만 하는게 아니라 개발도 할 줄 알아야 하고”

이 뜻이 아니고 프로젝트를 진행하는 조직에 각각의 role을 가진 전문가들이 존재해야 한다는 얘기.. 😢

Devops 의 탄생(?) 배경

예전.. 아주 오래전(?)의 조직은 이런 식으로 구성되었던 걸로 기억한다.
그나마도 이렇게 구분되는 회사를 다녔다는게 다행인 듯 ㅎㅎㅎ

  • 기획팀 : 상상력을 동원하여 서비스를 기획함.
  • 개발팀 : 개발을 죽어라 함
  • 운영팀 : 개발팀이 반영한 내용을 반영(배포)하고 고객응대를 함. (대부분 SE가 담당함)

이렇게 하다보니 , 내가 맡은 일만 하고 퇴근하는 문화가 생겨 소통의 부재가 발생하여 서로의 입장만 강조하는 상황이 생기기도 하고
운영은 개발의 미완성으로 인하여 배포가 원활하게 끝난 적이 거의 없고, 밤새 수정-> 반영만 반복(😱)하는 일이 너무 자주 생겼다.

이를 안타깝게 여긴 선구자들은 고민을 시작했고 🤔 조직의 변화를 주게 되는데..

  • 기획팀 : 상상력을 동원하여 서비스를 기획함
  • 개발팀 : 개발을 죽어라 함 ( 개발은 바뀌는게 없구나 😱)
  • 검증팀 : 개발된 내용을 눈에 불을켜고 검증함.
  • 운영팀 : 검증팀에서 검증된 소스를 반영함

검증 조직의 등장으로 개발의 오류도 줄어들고, voC도 줄어들고..
뭔가 큰 성과를 이룬 듯 하였으나, 개발 <-> 검증간의 시간소요로 개발기간은 늘어나고 , 운영팀의 고질병인 휴먼에러 가 수시로 발생하게 되었다.😱

선구자들은 고민을 다시 시작하게 되고…🤔

오류도 줄여야 하고..
인력도 줄여야 하고.. 검증은 해야 겠고..

선진문물(?)이 궁금해진 선구자분들은 고민끝에 Agile 방식으로 대책을 세우게 되었다.

애자일 : 모든 과정의 의견을 수시로 공유하여 누구나 참여하는 프로젝트로 진행함.

  1. 개발이 기획에 참여하여 산으로 가는 배를 만들지 않게 되고..
  2. 개발은 commit전 local Test를 실시함. ( 이 후, 개발자들의 단가는 올라갔다. 😎 )
  3. 검증은 개발을 포함하여 사용자 테스트 등으로 검증을 나누어 실시하고 ( 아쉽게도 이 부분의 도입이 안된 회사는 아직도 많다.😢 )
  4. 운영은 각 단계별(개발-검증-상용)로 구분하여 배포 자동화등의 업무 효율화를 하고.. ( 이 방식의 도입으로 수많은 운영인력들이 백수가 될 뻔 함.. 😢 )
  5. 모든 과정은 협업툴(레드마인, 맨티스, Jira 등)을 이용하여 소통함

새로운 문제의 등장

개발팀, 검증팀, 운영팀이 조직적으로 나눠져 있게 됨에 따라, miss comm.이 발생하기도 하고, 능력자를 차지하기 위한 서로의 Power 싸움도 만만치 않게 되었고.. 밥그릇 싸움이 시작되었다. 😠😠

Devops 의 등장과 효과

이렇게 등장한 새로운 문제를 해결하기 위하여 각각의 역할로 나누어져 있던 조직을 개발-검증-운영을 모두 포함하는 하나의 조직으로 구성하는 Devops 의 용어가 등장하게 되었다고 본다.

Devops의 효과는 …

  • 소스의 형상관리를 통해 단계별로 같은 결과를 나타내게 되고 ( “내 PC에서는 잘되는데?” 를 없앰)
  • 형상관리된 시스템을 이용하여 빌드 & 배포 과정을 자동화 하고 단순화 하여 누구나 이용할 수 있도록 함. ( 배포오류 줄임 )
  • Testcase를 공유함으로써 누구나 체크될 수 있도록 함 ( 개발오류 줄임 )
  • trac , slack, trello 등의 다양한 소규모 소통 협업도구를 이용하여 수시로 소통하게 됨. ( 소통의 부재 줄임 )

오해의 발생

하나의 조직내에서 개발,검증,운영의 role이 생기다 보니 Manager 들은 적은인력으로 최대의 마진(?)을 만들기 위해 개발자 1~2명이 devops를 책임지게 하는 이상한 형태의 조직이 만들어지고.. 😢 개발자 1 ~ 2 명만 있으면 다 됨! “ 이라는 오해(?)가 소규모의 회사에서는 너도나도 국룰(?)처럼 적용되어 버렸다. 😢

결론

아직까지도 많은 업체들이 PM or PL 이 만능(개발도 하고, 배포도 하고, 관리도 하고 )이길 바라는 오해는 없어지지 않았고.. 취준생들은 개발, 검증, 운영의 토탈 전문가가 되어야만 이력서라도 내볼 수 있게 된 듯 하고.. 한우물만 파던 전문가들은 이직의 기회가 점점 줄어들고..

💭 Reviews
  • 나도 이 업계에 개똥처럼 구르면서 참 오래 몸담았구나..
  • 다음번엔 SRE 이야기를 써봐야 겠다.ㅋㅋㅋㅋ 😎
  • 📖 Please Note that....
  • [그딴거 없음]
  • 🏷️ Tags
  • #devops  
  • #데브옵스  
  • #SRE  
  • #IT이야기  
  • #데봅스