소프트웨어 개발자 김수보님의 글을 모비인사이드에서 소개합니다.
이 글은 기술 이야기는 아닙니다. 조직 이야기입니다. 그리고, 일반론도 아닙니다. 하지만, 해당되는 분이라면 한번쯤 고민해보셨으면 좋겠습니다.
DevOps는 그냥 “운영”이 아니다
SI만 하던 분들은 “개발운영”을 그냥 “운영”으로 이해합니다. 그냥 “운영”은 시스템이 멈춰서지 않도록 관리해주는 것에 가깝습니다. 제조업이나 공장 등 산업 인프라 쪽은 그게 매우 중요합니다. 쉬지 않고 대량생산을 해야 하니까요.
하지만, 인터넷 서비스는 그렇지 않습니다. 봄, 여름, 가을, 겨울 계절별로 마케팅을 합니다. 사업제휴에 따라 신규 기능이 막 추가 되기도 합니다. 규제가 생기면 거기에 맞추어 이것저것 수정을 해야 합니다. 즉, 시스템 자체가 판매 매장이기 때문에 변경이 발생될 수 밖에 없습니다.
비유하자면, “시스템 신규 구축”은 백화점을 건설하는 일입니다. 반면 “시스템 운영”은 매장을 운영하는 것입니다. 진열방식을 바꾸고 시즌별로 상품을 교체합니다. 건물의 변화는 없습니다. 하지만, 개발운영은 “매장 운영”을 하면서, 백화점을 증축하는 일입이다. 어떤 경우는 본점보다 더 큰 별관을 뒤에 지어야 합니다.
완전히 다른 업무이다.
그래서 개발 리소스의 핸들링 방법이 아예 다릅니다. 증축공사가 크면, 별도 개발팀을 꾸려야 합니다. 물론, 기존 건물의 설계도와 시공정보도 함께 있어야겠지요. 증축공사가 작아도, 계획 관리는 따로 해야 합니다. 고객들에게 불편을 끼치면 안되니까요. 먼지가 많이 나고 소리가 크면 영업에 방해가 됩니다.
같은 조직에 운영과 증축을 함께 시키면 조직의 생산성은 보통 1/4 이상으로 떨어집니다. 경영자는 비용이 줄어들거라고 생각하지만, 오히려 커지는 경우가 대부분입니다. 사업에도 집중하지 못하고, 증축일시도 지키지 못해 사업이 어려워지기까지 합니다.
이거 잘 이해해야 합니다. 그리고 잘 설명해줘야 합니다. 경영자는 100% 헷갈리고, 개발자들도 10% 밖에 이해하지 못합니다.
※ 참고 링크 : Delone and McClean 의 Information Systems Success Model
기술보다 업무로 이해해야 한다
갈라진 벽면에 시멘트를 발라 보수하는 것과, 증축하는 벽면에 시멘트를 붓는 것은 같은 기술입니다. 하지만, 공법이 완전히 다릅니다. 기술이 같다고 같은 일이 아니라는 뜻입니다.
개발자 분들은 “일”을 “기술”이 아니라 “업무(TASK)”로 보았으면 좋겠습니다. “금방 되요.” 이런 이야기 안했으면 좋겠습니다. 마감도 분명 업무이고, 잡무를 처리할 기타 개발자들이 따로 있는 게 아닙니다. 거기에 들어가는 시간도 절대 공짜가 아닙니다.
경영자는 김대리의 코딩 능력이 궁금한 게 아닙니다. 비용과 기간이 얼마나 되는지 궁금합니다. 거기서 “금방 됩니다”라고 이야기하는 건 넌센스입니다. 어떻게 해야 우리 회사가 적당한 비용에 원하는 시스템을 제때 가질 수 있는지 이야기하는 게 맞습니다.
DevOps는 사람을 줄이는 방법이 아니다
DevOps는 운영자 두 사람을 개발자 한 사람으로 줄이는 방법이 아닙니다. 개발(Dev)과 운영(Ops)을 분리하기 힘든 비즈니스를 “잘 해나가는” 방법입니다.
그런데, 한 사람이 모든 일을 다 처리하면 업무 효율은 오르겠지만, 생산성에 한계가 생깁니다. 푸쉬하면 조금 더 오르겠지만 근본적으로 바뀌지는 않습니다.
소프트웨어는 “소프트” 하긴 하지만 “도깨비 방망이”가 아닙니다. 들쭉날쭉한 생산량으로 비용예측을 할 수 없습니다. 인터넷 서비스는 “시스템”과 “개발팀”을 가지고 하는 사업입니다. 엄연히 원가와 비용이 있고 현금흐름과 자금회전주기도 있습니다. 생산단위 예측이 되어야 수지타산을 맞춰볼 수 있습니다.
DevOps는 전체 절차를 줄여서 서비스의 효율성과 기민성을 높이려고 하는 것입니다. 사람을 줄여 놓고, 비용이 줄어들기를 기대하는 것은 잘못된 접근입니다.
문제를 해결하지 못하면, 도구는 짐이다
Continuous Integration, Continuous Delivery 모두 중요하지만 그 출발점이 어디인지를 명확히 인지했으면 좋겠습니다. 인터넷 서비스를 하다보면 여러가지 문제에 부딪힙니다. 그 중 몇 개의 문제를 해결하기 위해 CI와 CD가 만들어졌습니다. 즉, CI, CD를 하면 모든 문제가 해결되는 것이 아니라는 뜻입니다.
사람이 문제를 푸는 거다
CI와 CD가 필요한 상황까지 서비스가 발전하는 것이 첫번째입니다. 그 상황이 되면 CI와 CD로 풀 수 없는 문제도 생기게 됩니다. 좋은 탈곡기가 들어왔다고 벼농사가 잘 되는 것은 아닙니다. DevOps는 “툴” 중의 하나란 걸 인지하시고, 함께 일하고 있는 “사람”에게 좀 더 집중했으면 합니다.
참고로, “개발운영”은 개발하면서 운영을 한다는 의미가 강합니다. 즉, 개발에 무게감이 더 실립니다. 반면 “운영개발”은 운영을 위해 개발한다는 뜻이 강합니다. 즉, 운영에 무게감이 더 실립니다. 사람마다 의견이 다를 수 있지만, 저는 그렇게 느낍니다.
※ 참고글 : DevOps의 ROI를 증명하기 위한 지표는 무엇일까? (David Leanwook, 2017.2.17)
저자가 영국분이신데 운영쪽으로 입문을 해서, 지금은 컨설턴트로 일을 하고 있습니다. 석사논문으로 운영팀의 ROI에 대한 연구를 했습니다. 조금 부럽네요. 개인적으로는 이런 연구와 시도들이 점차 IT산업의 격차를 벌릴 거라고 봅니다.
[IT의 중심에서] 시리즈
– (10) 개발상식1. 콘웨이의 법칙
– (9) 스타트업 개발자
– (8) 개발자 역할의 변화
– (7) 스타트업, 서비스 개발자가 되자
[fbcomments url=”http://ec2-13-125-22-250.ap-northeast-2.compute.amazonaws.com/2017/11/27/subokim-devops/” width=”100%” count=”off” num=”5″ countmsg=”wonderful comments!”]
