Jim Bird는 캐나다 캘거리에 있는 BIDS Trading Technology(주식,증권거래 관련) 회사의 CTO입니다.
그리고, 아래글은 Dzone이라는 사이트내 Devops카테고리에 실렸던 포스팅입니다.

Devops를 우리말로 번역하면 ‘운영개발’, ‘개발운영’ 정도인데 여전히 우리나라에서 생소한 분야입니다.
그래서 Devops를 소개드릴겸 번역글을 올려봅니다.

실시간으로 서비스를 운영할 수 밖에 없는 서비스 회사들은 이미 오래전부터 해오던 일입니다.
포털, 이통사, 인터넷 커뮤니티 등이 있겠네요. 속칭 시스템을 손으로 돌린다고 합니다.
IT서비스 회사에서는 개발과 운영을 분리해서 관리하기 힘들기 때문입니다.

반대로 폭포수 개발방법론의 대표격인 공공부문이나 금융은 개발과 운영을 합쳐서 관리하지 않습니다.
업무 안정성이 우선이고 작은 오류가 큰 사고로 이어지기 때문입니다.
하지만 어떤 기업이든 웹서비스는 운영개발로 움직이더군요.
실리콘밸리에서도 사실 이론만큼 매끄럽게 되는 곳은 없다고 합니다.
하지만 많은 서비스 기업들이 Devops 체제로 움직인다고 합니다.

아래글은 북미 쪽의 많은 기업 프로젝트들이 대규모의 아웃소싱 구조에서 소규모 내부 개발팀 중심으로 바뀌고 있음을 짐작하게 합니다.
Devops는 사실 개발자들이 매우 개발에 집중하기 어려운 환경입니다.
하지만 저자는 개발의 미래가 결국 Devops가 되지 않을까라고 끔찍한 예상을 하는군요.
모든 IT 분야에서 그렇게 되긴 힘들겁니다.
하지만, 점점 더 빨라지는 온라인 비즈니스에서 ‘운영개발’은 피하기 힘들다는 생각이 드는군요.

“Devops는 개발자들에게 개발역량 외의 다른 것도 요구합니다.
커뮤니케이션 스킬이나 비즈니스 인사이트 같은 건대요.
이건 다음번에 설명드릴 기회가 있지 않을까 싶습니다.”

※ 원문 : DevOps Isn’t Killing Developers – But it is Killing Development and Developer Productivity(2014.8.4)
※ 저자 : Jim Bird

Devops은 개발자를 죽이지 않는다. (적어도 내가 아는 한 죽은 개발자는 없다.)
하지만 Devops은 개발 자체나 일반적으로 알고 있는 소프트웨어 개발방법들을 죽이고 있다.
애자일이 그 시작이었고 Devops는 방아쇠가 되었다.

1. Devops는 하나의 흐름이다.

소프트웨어 개발 및 배포 방법이 크게 달라지고 있다.

대규모의 폭포수 개발방법론 프로젝트들이 점진적 배포와 나선형(Spiral) 개발방식으로 바뀌고 있다.
스크럼과 반복적 애자일 방법을 사용해서 일정기간 내 작동하는 코드를 만들어내는 소규모팀으로 바뀌고 있다.
사람들은 스크럼에서 Kanban이나 One-Piece Continuous Flow로 이동하고 있다.
One-Piece Continuous Flow는 Devops에서 실시간으로 일관성 있는 코드 배포를 가능하게 하는 방법이다.

개발의 규모와 중점사항들은 계속해서 줄어든다.
마찬가지로 의사결정을 하거나 일을 끝내야 하는 시간도 점점 줄어든다.
개발단계, 마일스톤, 스프린트를 위한 프로젝트 리뷰, 그리고 기한을 넘긴 업무를 Lean Control 하기 위한 스프린트 리뷰들, 타스크 레벨 최적화.(주. 모두 애자일 방법에 대한 이야기입니다.)
그리고 배포가능한 것들의 크기(프로젝트 팀이 1년 동안 배포할 수 있는 것에서부터 스크럼 팀이 한 달 안에 끝낼 수 있어가 개인개발자가 몇일 또는 몇시간 동안 일할 수 있는 크기까지) 등등
이런 모든 것들을 해야 하는 시간들이 줄어들고 있다.

이제는 ‘개발이 끝났다’,’소프트웨어가 돌아간다’는 뜻이 ‘코딩, 테스트, 데모준비가 완료되었다’가 아니라 ‘상용에서 돌아갈 준비가 완료되었다’는 의미로 바뀌었다. 즉, 배포할 준비가 되었다는 뜻이다.

Continuous Delivery와 Continuous Deployment가 Continuous Integration을 대체했다.
신속한 상용배포란 수작업 테스트를 할 시간을 전혀 배려하지 않는다는 뜻이다.
물론 개발자들이 상용배포 전에 버그를 잡을 시간을 별도로 고려하지 않는다.
신속한 상용배포에서는 그냥 상용에서 테스트하고 문제가 발생되면 바로 조치한다.

Devops는 개발자들을 상용환경에 밀착시키기 때문에 운영 리스크가 개발 리스크보다 훨씬 커진다.
그리고 운영지표가 프로젝트(개발) 지표보다 훨씬 중요해진다.
시스템 운영 및 상용배포 소요 시간이 성과나 속도보다 중요해졌다.
프로젝트 일정에 대한 스트레스는 운영 및 호출 중에 불 끄는 스트레스로 바뀌었다.

Devops는 프로젝트 산출물이나 기능을 배포하는 것에 대한 이야기가 아니다.
Devops는 지연시간을 최소화하고 다음과 같은 것들에 대한 효과를 극대화하기 위한 이야기다.
– 작업에서 상용화까지의 시간을 최소화, 쓸데없는 일을 인식하고 제거하는 것, 시스템의 신뢰성을 높이고 운영비용을 낮추는 것, 운영에서 개발까지 이어지는 피드백 구조를 만드는 것, 그리고 가능한 많이 표준화하고 자동화하는 것.

Devops는 엔지니어링 이라기보다 생산, 제조 공정(process, flow)의 통제에 가깝다.

2. Devops는 개발자의 생산성을 죽인다.

Devops는 개발자의 생산성을 죽이기도 한다.

만일 당신이 LOC에 의해 개발자들의 생산성을 측정할 수도 있다. Function points, Feature points, Story points, velocity 등등 다양한 측정 수단으로 개발된 코드량을 측정할 수도 있다. 하지만 운영업무나 중간중간 해야하는 다른 일들, 그리고 부족한 코딩시간 때문에 개발자들은 훨씬 더 적은 량의 코딩을 할 수 밖에 없다.

인프라와 플랫폼을 배우는 시간, 그리고 어떤 것이 어떻게 설치되어 있고 제대로 설치되어 있는지 이해하는 시간.
Continuous Delivery와 Continuous Deployment를 만들고 그것들을 유지시키기.
이슈를 조사하고 해결하거나 긴급한 고객 요청에 대답하거나, 성능 문제를 들여다보기.
시스템이 제대로 돌아가는지 모니터링하고, A/B 테스트를 실험하는 것, 변경관리를 하고 수정하기.

이런 모든 것들이 개발자가 요구사항을 분석하고, 설계, 코딩, 테스트하는 시간들을 빼앗아 간다.

3. 방해하기나 중복작업의 결과

Devops에서는 여러가지 방해요소들과 우선순위의 변화들에 대해서 개발자들을 보호할 수 없다.
엄격한 WIP limit을 가진 kanban이나 빡빡한 run shop 안이라고 하더라도 말이다.
아니 굳이 그렇게 해야할 필요가 없다.

오히려 개발자들은 운영과 고객들에 대해 책임감을 느낄 필요가 있다.
그리고 상용환경에서 나온 피드백에 빠르게 반응해야 하고, 문제에 뛰어들어가 가능한 빨리 해결해야 할 필요가 있다.
즉 모두가(특히 가장 훌륭한 개발자들이) 거의 항상 운영에 투입될 수 있어야 한다.

개발자들은 일과 후에도 운영대기를 해야 한다.
즉, 일이 끝난 후에는 삐삐를 들고 다녀야 한다. 이것을 삐삐의무라고 한다.
그리고 문제 같지 않은 문제 해결을 위해 전화통을 붙잡고 있어야 하고, 밤새도록 또는 주말내내 불을 꺼야 한다.
제품 이슈를 추적하고 오류 해결을 지원해야 하며, 피곤한 다음날에도 총연습 등에 더 많은 시간을 보내야 한다.

이런 등등의 수~~~많은 (개발의) 방해요소들을 겪어야 한다.

개발자들은 이런 방해요소들에 대한 대책을 미리 세울 수도 없다.
이것은 점점 더 개발자들이 개발 약속을 잊어버리게 된다는 것을 의미한다.
그러면 (개발자들을 괴롭히는) 그 사람들은 도대체 왜 일정을 약속한거며 왜 자꾸 일을 방해하는걸까?
더 중요한 일이 나타나서 그 일을 미루기 전에 당장 우선순위가 높은 일(just-in-time prioritization)부터 먼저하라.

개발자들이 운영이나 기술지원업무에 대한 참여도가 클수록, 중복작업이나 일 갈아타기는 늘어난다.
방해요소와 비효율성도 당연히 늘어난다. 시간은 파괴되고 집중도는 떨어진다.
이것은 생산성 뿐 아니라 사람들의 사고 능력이나 문제해결능력을 장기적으로 저하시키게 된다.

심지어는 Continuous Deployment의 피드백 시스템 자체도 개발자의 흐름을 끊어놓는다.
개발자가 코드를 체크인한 후에, Continuous Integration 내에서 유닛 테스트를 돌리는 것은 빠르고, 몇 초, 몇 분 밖에 걸리지 않아야 한다. 그래야 방해없이 계속해서 전진할 수 있기 때문이다.
그러나 상용에 바로 배포한다는 것은 통합 테스트, 시스템 테스트, 그리도 더 많은 테스트를 하고, 제대로 작동하는지 모니터링을 하고, 오류가 발생하면 즉시 조처하는 등의 수많은 단계들을 한 번에 통과하겠다는 것과 같다.

아무리 많은 것들이 자동화되어 있고 최적화되어 있더라도 이 모든 과정은 시간을 필요로 하고 개발자들의 관심을 필요로 한다.
운영업무에 참여하고 빠져나오는 프로세스를 최적화 한다는 것은 개발자들의 개발흐름을 희생한다는 의미이다. 그리고 물론 개발업무 자체를 느리게 만든다.

4. 기대치, 지표, 인센티브가 바뀌어야 한다.

Devops에서는 개발자들이 일하는 방식이 바뀌게 된다. 따라서 관리방법도 바뀌게 된다.
그래서 개발자들에 대한 기대와 평가지표, 인센티브 등이 바뀌어야 한다.

Devops의 성공은 운영상의 IT지표들에 의해 측정되어야 한다.
(개발지표인) 프로젝트 범위나 일정, 비용으로 평가해서는 안된다.
스프린트 일정이나 배포 일정 등등에 영향을 받아서도 안된다.
다음과 같은 지표로 평가 받을 수 있어야 한다.

• 얼마나 팀이 빠르게 문제에 대응하는가? 배포일정이 아니라 대응시간과 상용화 시간으로 측정해야 한다.
• 얼마나 자주 변경내역을 서버에 배포하는가?
• 얼마나 자주 실수하는가? – 변경 대비 실패 비율
• 시스템 신뢰성과 가동시간
• 변경 비용 – 전체 관점에서

5. Devops는 개발이라기보다 운영이다.

더 많은 소프트웨어가 더 빨리 배포되고 더 자주 상용화 될수록, 개발은 유지보수로 변화된다.
프로젝트 관리는 끝나고 운영이슈나 운영업무 타스크의 관리가 시작된다.
설계나 계획기간은 점점 더 짧아진다. 그때 그때 우선순위에 따라서 일하게 된다.

Infrastructure as Code에서 운영자는 개발자가 된다.
운영자가 인프라 구조를 설계하고 코딩한다.
변경에 대해서도 고민하고 코드의 재사용성, 가독성, 중복, 리팩토링, 기술부채 등등을 고민한다.
그들은 점점 더 애자일하게 되고, 일을 작게 나누어서 자주 배포하고, 문서작업보다 개발에 더 집중하게 된다.

그리고 개발자들은 운영자처럼 일하게 된다.
운영과 기술지원에 대한 책임여부를 이야기하게 되고, 제일 먼저 운영상의 위험을 걱정하게 된다.
그리고 단기적인 문제해결과 장기적인 설계 이슈 사이의 균형을 잡으려고 애를 쓰게 된다.

온라인 비즈니스에서 잠깐이라도 일해본 경험이 있는 사람에게는 전혀 놀라운 이야기가 아니다.
시스템을 가동시키고 고객이 이용하기 시작하면 모든 것이 달라진다.
일하는 방식과 계획들이 모두 새롭게 정의되어야 한다.

이렇게 일하는 방식이 개발자들에게 딱히 더 좋은 것도 아니고 나쁜 것도 아니다.
하지만 일반적으로 개발자들이 일하는 방식과는 확실히 다르다.
훨씬 더 정신산만하고 방해하는 요소들이 중심에 있는 업무처리 방식이다.
동시에 더 훈련되어 있고 더 Lean하게 일해야 하는 방식이기도 하다.
더 투명하고 더 책임과 의무가 따르는 방식이다.

“개발은 적게 배포, 기술지원, 운영은 더 많게!!!”

개발자들과 개발 관리자들은 IT운영이라는 더 큰 그림에 참여하는 것에 익숙해질 필요가 있다.
그것은 앱을 설계하고 코드를 만들고 배포하는 그 이상의 것에 관한 것이다.
이것이 소프트웨어 개발의 미래일지 모른다.

물론 모든 개발자들이 좋아하지는 않을 것이다.
그리고 모든 개발자들이 Devops를 잘하지도 않을 것이다.