IT의 중심에서

중년 개발자가 살아 가는 IT 현장 이야기

DevOps 란 무엇일까?

이 글은 기술이야기는 아닙니다. 조직이야기입니다.
그리고, 일반론도 아닙니다.
하지만, 해당되는 분이라면 한번쯤 고민해보셨으면 좋겠습니다.


road-to-devops-roi-7-638
클라우드 서비스를 하는 클라우드먼치는 이미 오래전에 DevOps에 대한 ROI를 따졌다. 이 부문이 DevOps에 대한 필요성이 가장 높았기 때문이다.

DevOps는 운영+증축이다.

SI만 하던 분들은 “개발운영”을 그냥 “운영”으로 이해합니다.
그냥 “운영”은 시스템이 멈춰서지 않도록 관리해주는 것에 가깝습니다.
제조업이나 공장 등 산업 인프라 쪽은 그게 매우 중요합니다.
쉬지 않고 대량생산을 해야 하니까요.

하지만, 인터넷 서비스는 그렇지 않습니다.
봄,여름,가을,겨울. 계절별로 마케팅을 해야합니다.
사업제휴에 따라 신규 기능이 막 추가 되기도 합니다.
규제가 생기면 거기에 맞추어 이것저것 수정을 해야 합니다.
즉, 시스템 자체가 판매매장이기 때문에 변경이 발생될 수 밖에 없습니다.

비유하자면, “신규구축”은 백화점을 건설하는 일입니다.
반면 “시스템 운영”은 매장을 운영하는 것입니다.
진열방식을 바꾸고 시즌별로 상품을 교체합니다.
건물의 변화는 없습니다.

하지만, 개발운영은 “매장 운영”을 하면서, 백화점을 증축하는 일입니다.
어떤 경우는 본점보다 더 큰 별관을 뒤에 지어야 합니다.

팀 운영방법이 다르다.

그래서 개발 리소스의 핸들링 방법이 아예 다릅니다.

증축공사가 크면, 별도 개발팀을 꾸려야 합니다.
물론, 기존 건물의 설계도와 시공정보도 함께 있어야겠지요.

음, 증축공사가 작아도 “계획 관리”는 해야 합니다.
고객들에게 불편을 끼치면 안되니까요.
먼지가 많이 나고 소리가 크면 영업에 방해가 됩니다.

같은 조직에 운영과 증축을 함께 시키면 조직의 생산성이 보통 1/4 로 떨어집니다.
경영자는 비용이 줄어들거라고 생각하지만, 오히려 커지는 경우가 많습니다.
사업에도 집중하지 못하고, 기한도 늘어나기 일쑤라 사업이 어려워지기까지 합니다.

이거 잘 이해해야 합니다.
그리고 잘 설명해줘야 합니다.
경영자는 100% 헷갈리고, 개발자들도 10% 밖에 이해하지 못합니다.

devops3
사업팀과 전략팀, 개발부서 간에 관리하는 상이한 지표들. 즉, “DeLone”, “McClean”이 이야기하는 전통적인 IT성공모델이 달라졌다는 것을 의미한다.

※ 참고 링크 : Delone and McClean 의 Information Systems Success Model

기술보다 업무로 이해해야 한다.

갈라진 벽면에 시멘트를 발라 보수하는 것과,
증축하는 벽면에 시멘트를 붓는 것은 같은 기술입니다.
하지만, 공법이 완전히 다릅니다.
기술이 같다고 같은 일이 아니라는 뜻입니다.

개발자 분들은 “일”을 “기술”이 아니라 “업무” TASK로 보았으면 좋겠습니다.
“금방 되요.” 이런 이야기 안했으면 좋겠습니다.
마감도 분명 업무이고, 잡무를 처리할 기타 개발자들이 따로 있는 게 아닙니다.
거기에 들어가는 시간도 절대 공짜가 아닙니다.

사장님은 김대리의 코딩능력이 궁금한 게 아닙니다.
비용과 기간이 얼마나 되는지, 그게 궁금한겁니다.
비용과 기간에 대한 질문을 능력에 대한 질문으로 받아들여서,
“금방 됩니다”라고 이야기하는 건 넌센스입니다.
어떻게 해야 우리 회사가 제때에 적당한 비용으로 원하는 시스템을 가질 수 있는지 이야기해줘야 맞습니다.

사람을 줄이는 방법이 아니다.

DevOps는 운영자 두 사람을 개발자 한 사람으로 줄이는 방법이 아닙니다.
개발Dev과 운영Ops을 분리하기 힘든 비즈니스를 “잘 해나가는” 방법입니다.

그런데, 한 사람이 모든 일을 다 처리하면 업무 효율은 오르겠지만 생산성에 한계가 생깁니다. 푸쉬하면 조금 더 오르겠지만 근본적으로 바뀌지는 않습니다.

소프트웨어는 “소프트” 하긴 하지만 “도깨비 방망이”가 아닙니다.
들쭉날쭉한 생산량으로 비용예측을 할 수 없습니다.
인터넷 서비스는 “시스템”과 “개발팀”을 가지고 하는 사업입니다.
엄연히 원가와 비용이 있고 현금흐름과 자금회전주기도 있습니다.
생산단위 예측이 되어야 수지타산을 맞춰볼 수 있습니다.

DevOps는 전체 절차를 줄여서 서비스의 효율성과 기민성을 높이려고 하는 것입니다.
사람을 줄여 놓고, 비용이 줄어들기를 기대하는 것은 잘못된 접근입니다.

문제를 해결하지 못하면, 도구는 짐이다.

Continuous Integration(CD), Continuous Delivery(CI).
모두 중요하지만 그 출발점이 어디인지를 명확히 인지했으면 좋겠습니다.
인터넷 서비스를 하다보면 여러가지 문제에 부딪힙니다.
그 중 몇 개의 문제를 해결하기 위해 CI와 CD가 만들어졌습니다.
즉, CI, CD를 하면 모든 문제가 해결되는 것이 아니라는 뜻입니다.

문제를 푸는 건 사람이다.

CI와 CD가 필요하려면 우선 서비스가 잘되어야 합니다.
1인기업에 서버 2대인데 CD까지 생각하는건 약간 사치스러운 느낌입니다.

그런데 서비스가 아주 잘되는 상황이라면,
CI와 CD로 커버가 가능한 그 이상도 생기게 됩니다.
좋은 탈곡기가 들어왔다고 벼농사가 잘 되는 것은 아닙니다.
DevOps는 “툴” 중의 하나란 걸 인지하시고,
함께 일하고 있는 “사람”에게 좀 더 집중했으면 합니다.

참고로, “개발운영”은 개발하면서 운영을 한다는 의미가 강합니다.
즉, 개발에 무게감이 더 실립니다.
반면 “운영개발”은 운영을 위해 개발한다는 뜻이 강합니다.
즉, 운영에 무게감이 더 실립니다.
사람마다 의견이 다를 수 있지만, 저는 그렇게 느낍니다.

※ 참고글 : DevOps의 ROI를 증명하기 위한 지표는 무엇일까? (David Leanwook, 2017.2.17)

저자가 영국분이신데 운영쪽으로 입문을 해서, 지금은 컨설턴트로 일을 하고 있습니다.
석사논문으로 운영팀의 ROI에 대한 연구를 했습니다.
조금 부럽네요.
개인적으로는 이런 연구와 시도들이 점차 IT산업의 격차를 벌릴 거라고 봅니다.

끝.

DevOps 란 무엇일까?”에 대한 2개의 댓글

  1. 알아가는 청년개발자
    2020년 5월 6일

    와 … 안녕하세요 . 지나가다가 글보고 감탄해서 댓글 남깁니다… 너무 유익한 글보다가 타고타고 전체적으로 읽게 되네요 만나봬서 밥한끼 하고싶습니다

    • subokim
      2020년 5월 7일

      아, 좋은 덧글 감사합니다. 꾸벅.

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Google photo

Google의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

%s에 연결하는 중

정보

이 엔트리는 이(가) IT 산업이야기, 스타트업에 2017년 11월 15일에 게시하였습니다.

내비게이션

%d 블로거가 이것을 좋아합니다: