우리딸 생일을 축하한다.

사랑하는 딸아... 오늘이 두번째 생일이란다. 생일 진심으로 축하한다. 그리고 아빠는 네가 아빠 껌딱지라서 너무 행복하고 고맙다. ^^

DevOps Isn't Killing Developers – But it is Killing Development and Developer Productivity

안녕하세요. ^^

옥희 회원님께서 번역해 주신 DevOps관련 글입니다.
모든 개발자들이 개발 방법론 협업 방법에 대해서 항상 고민하고 있습니다.
이와 관련해 한번쯤 꼭 읽어 보시기를 권해드립니다.

출처 원문 : http://java.dzone.com/articles/devops-isnt-killing-developers

DevOps Isn't Killing Developers – But it is Killing Development and Developer Productivity

DevOps은 개발자를 힘들게 하지 않는다.-다만,  개발과 개발자의 생산성을 놀랍도록 끌어올린다.

이러한 DevOps Zone 은 PagerDuty와 새로운 C.A.L.M을 지속하고 DevOps 문화를 설립한 것을 수행한 분들에 의해 소개되었다. Devops은 개발자를 힘들게 하지 않는다 (적어도 내가 아는 한 어떤 개발자도 난처한 적 없다.) 그러나 Devops은 개발자를 미치게 만들거나, 소프트웨어를 개발하고 전달하며 우리가 대부분 생각하는 방법을 제시한다. 애자일(Agile)은 총이며, Devops는 방아쇠를 당긴다.

전달보단 흐름으로…..

 바다가 변화하듯, 소프트웨어 역시 개발되고 전달된다. 큰 규모의 폭포와 같은 소프트웨어 개발 프로젝트는 단계적인 전달과 나선형(Spiral) 접근법을 제공한다. 그리고 소규모팀들에게 제한된 시간에 일 할 코드를 전달한다.(사용중인 스크럼[Scrum]이나 다른 반복적인 애자일 방법들을 제시한다). 이제 트렌드가 스크럼에서 칸반(Kanban)으로 이동 하고 있다. 직관적인 하나의 계속적인 흐름(One-Piece Continuous Flow) 그리고 Devops에서 생산하는 코드의 계속적인 배치(Continuous Deployment) 도 주목 받고 있다.

 다양한 규모가 축소되는 방향으로 개발이 자꾸 집중되기 때문에, 일을 빠르게 끝마치기 위해 시간 틀(frame)을 시행한다. 이런 면과 기준 그리고 프로젝트 검토에서 조금씩 확실하게 최선을 다해 검토하고 진행 중인 일의 한계와 과업의 수준을 최적화 하기위해 통제(Control)한다. 이런 소프트웨어 제품의 규모에 따라서, 어떠한 프로젝트 팀은 1년 후에 완성된 결과물(프로젝트)을 전달하거나, 스크럼 팀(Scrum team)이 1달 후나 1주 후에 프로젝트를 완수하고, 어떤 개인적인 개발자는 몇 시간 후나 며칠 후에 개발을 시작한다.  “끝냈다”는 것의 뜻과 “작동중인 소프트웨어” 라는 것은  암호 혹은 부호로 처리가 되어 있고 잘 되거나 시험운행(테스트)하는 것이 가능하며 제작한 소프트웨어를 증명할 준비가 된 생산작업에 의해서 바뀔 수 있다는 것이다. -지금(“끝은 공유를 의미한다.(Done Means Released)”에서).

 지속적인 전달과 지속적인 배치는 지속적인 통합이라 말할 수 있다.. 작업에서 신속한 배치는 수작업으로 확인하는 담당자나 수작업 테스트 중일 때 있어서, 시간을 낭비하지 않는다. 개발자들은 코드를 제품출시 하기 전에  소프트웨어 제품을 시험운행하며, 소프트웨어에서 발생한 문제를 해결하기 위해, 해당 소프트웨어 제품의 모든 버그를 포착하여 문제를 해결해야 할  책임이 있다.(아카[aka]”시험운행 중으로서의 관찰”에서)

  그 이유는 데브옵(Devops)은 개발자들에게 소프트웨어 제품생산을 손쉽게 하며, (소프트웨어 제품)동작시 위험이 프로젝트 위험보다 더 중요하게 되며, (소프트웨어 제품)동작에 대해 측정한 것 역시 프로젝트를 측정한 것보다 중요하다. 소프트웨어 제품을 작업함에 있어서 시스템 가동시간과 순환시간(cycle time)은 획득한 가치나 속도로 대체한다. 다급한 마감시한에 대한 강조는 생산시 다급함에 대한 강조며 관심사 1순위로 대신하게 된다.

  데브옵(Devops)은 프로젝트를 전달하거나 심지어 기능을 전달하지 않는다. 이것은 최소화된 리드타임(생산부터 완성까지 걸리는 시간)과 작업에서 생산까지 최적화된 흐름, 화제를 놓치지 않으며, 쓸데없는 일을 하지 않음과 동시에 지연되고 미뤄진것은 신뢰할 수 있는 시스템으로 개선하는 것, 운영비용을 삭감하고 생산에서 개발까지 계속적인 조언으로 반영한다. 추가로, 표준화하고 자동화하는 절차가 가능한 많이 있다. 보통의 공학기술 보다 과정을 제어하고 생산하는 것이다.

데브옵은 개발자 생산성 역시 기여한다.

데브옵은 또한 개발자의 생산성에 기여한다.

 당신은 LOC에 의해서 개발자 생산성을 판단하거나 기능의 강조점 이나 기능점 이거나 이야기의 강조할 점 이거나 빠르기나 작성된 많은 코드 몇 줄의 다른 측정법 등을 적은 코드로 판단한다. 사회 공공 기반 시설과 제시안 [플랫폼] 등을 이해하는 것에 대한 시간 학습은 확실히 만들고 설정을 올바르게 하는 것이다. 그것은. 또한, 계속적으로 발전시키고(Building) 전달하며, 다양한 경로를 계속적으로 배치하는 것이다. 옵스(ops)를 살피기 위해 돕는 것과 이슈를 해결하는 것은, 긴급한 고객의 다양한 요청에 응답하는 것이고 질문과 성능 문제에 대해 관찰하고 시스템을 감시하는 것은 일을 정확하게 하는 것이며, A/B 실험 운영하는 것을 돕는 것이다. 변화를 장려하고 준비하는 것은 시험운행하고 코딩(소프트웨어를 제작하고)하고 설계하며 필수적인 것에 대해 미리 시도하고 개발하는 것으로 부터 시간을 쓰는 것이다.

다중 작업(Multi-Tasking)과 일의 중단에 대한 영향

데브옵에서의 최우선의 변화와 일의 중단으로부터 독자 여러분은  개발자를 보호할 수 없고, 당신이 칸반과 엄격하게 WIP 제한을 사용할지라도,  심지어는 딱 맞게 경영할지라도-이건 독자여러분이 원치 않을 것이다. 개발자들은 운영을 원활하게 하며 고객에 대응할 필요가 있고, 생산한 것으로부터 조언을 받고 수정할 수도 있으며, 문제를 해결함과 동시에 되도록 이면 빠르게 실수를 발견하고 해결하는 것에 도움을 주는 것 이다. 모두에게 이것이 의미하는 것은, 특히 가장 재능있는 개발자들은, 모든 시간을 할애하지 않더라도 대부분 옵스를 필요하게 될 수 있다.

  개발자들은 몇 시간뒤에 대기 중이었다가 옵스에 접속한다. 하루의 일과를 마치고 난 뒤(퇴근 후), 다시 말해서 (누군가의 호출에 시달리거나) 의무를 다하고 옵스에 접속한다는 것이다. 그리고 시간을 투자하며 문제해결을 위해서 지원 한다는 뜻은 정말 문제가 되게 하지 않기 위해서, 긴 밤과 주말을 바쳐가며 소프트웨어 제품의 이슈를 찾아내고 문제점을 해결하기 위해 도움을 주며, 다음날 피로에 쩔어도 자잘한 운영과 시험운행 및 시스템 대체 작동과 미리 운행(roll-forward)하고 다시 소스를 원복하고(commit 하기 전 roll-back), 프로젝트가 끝난 뒤에도 참여 하며, 프로그램이 뭔가 잘못 돌아가거고 시스템이 대체 작동되거나 미리 운행 (roll-forward)하거나 소스를 원복(원상복귀)시켜도 동작하지 않을 때 문제의 원인을 분석하는 것을 말하는 것이다.

  당신은 중단과 운영상의 문제에 대해서 계획 할 수 없다. 그리고 당신은 그것들과 관련된 것을 또한 계획할 수 없다. 개발자들은 그들이 자주 베푸는 헌신에 대해 잊을 것이다. 그러면 왜 그들이 어째서 헌신하는가? 계획을 수립하거나 평가하는 것에 대해서 왜 신경을 쓰는 것인가? 가장 중요한 것에 집중하는 하기 전에, 제대로 우선순위를 매기는 것은 옵스나 고객이 갑자기 필요로 하는 것, 추가로 당신이 할 수 있는 것을 바로 실행하는 것 -  그렇지 않으면 뭔가 더 중요하거나 이슈화 된 것 그리고 그것을 미연에 방지하는 것이다.

  개발자로서 옵스에 더욱 시간을 쓰고 책임감을 가지고 행동하는 것은 다중 작업 그리고 본연의 임무를 수행하는 것과 중단 및 비효율성을 가져오기도 한다(본연의 임무만 집중했을때 얻을 이익을 일컫는다). 개발자가 옵스에 참여해서 투자해야 할 시간이 증가하고, 손해보는 시간과 본인을 위한 일을 하지 못하는 것 등이 중단 및 비효율성을 의미한다. 이러한 것은 생산성이 지연되는 결과를 가져온다. 그리고 반면에, 문제해결에 참여한 사람들의 생각하는 능력에 있어서 매우 큰 영향을 주고 문제해결에 기여한다. 그렇지만 계속적인 개발 조언만으로도 개발자만의 작업흐름을 방해한다.

개발자가 코드를 확인한 뒤에, 계속적인 통합을 위해 단위별 테스트를 하는 것은 더욱 퍼포먼스를 증대시키고, 몇 초 혹은 몇 분이 빨라진 다는 점에서 개발자들이 개발자의 괴업과 함께 행동할 수 있게 된다. 그러나 작업을 위해 즉각적으로 배치하는 것이 의미하는 것은 통합테스트 단위를 더욱 확장하는 것을 통해 운영하는 것을 뜻하고, 시스템 시험운행과 계속적인 전달을 위한 다른 확인도 하는 것을 뜻한다(더 철저하게 시험운행 하는 것과 더욱 시간을 들여서 확인 하는 것).그리고 그 다음, 배치를 통해서 단계적으로 실행하며, 작업을 살피고 모든 일이 제대로 돌아가는지 확인 하면서, 어떤 것이 잘못 되었는지 확인 하는 것이다.

만약 거의 모든 단계들이 자동화되고 최적화 되어 있을지라도, 이것들 전부 추가 시간과 코딩하는 것을 떠나서 개발자의 주의가 필요하다.

  작업의 흐름을 최적화 하는 것과 운영을 밖의 의미는 개발자의 에너지를 희생하는 것이다. 또는 개발일 그자체를 늦추는 일을 발생시킨다.

기대와 통계(예측) 및 변화해야 할 우대정책

  데브옵에서 방법이란, 개발자들(그리고 옵스) 과업을 변화하는 방법과,  그들이 관리되어 지는 것의 변화하는 방법을 이야기 하는 것이다. 그것은 또한 개발자들을 위해 중요한 기대와 통계, 장려책을 변화하기 위한 것이기도 하다.

 데브옵의 성공은 운영중인 정보기술 통계에 의해 측정되고, 어떠한 범주의 프로젝트 전달 목표에 의한 것이 아니며, 일정과 비용, 발표할 목표나 최우선적인 헌신을 충족하는 것도 아니며, 혹은 심지어는 제품 디자인 목표에 만족하는 것도 아니다.

• 어떻게 하면 빠르게 팀이 중요한 변화나 문제에 반응할 수 있는가: 작업시간을 변화하는 것과 코딩하는 방법이나 속도 대신 작업 하는 것에 있어서 시간의 흐름(Cycle Time)
• 얼마나 자주 생산하기 위해 변화를 주장하는가.(이것은 여전히 통계적인 면이 있다. 대부분 사람들은 가장 흥분하게 되는 이유는-하루에 얼마나 많은 시간 혹은 1시간에 분당 소요하는 것이나 넷픽스(Netflix)나 아마존(Amazon) 배치의 변화
• 얼마나 자주 실수를 만드는가 - 변화/실패의 비율
• 시스템 의존도와 가동시간-MTBF and especially MTTD and MTTR
• 변화의 비용 - 그리고 전반적인 운영과 지원 비용 등

데브옵스(Devops)는 데브 보다 더욱 옵스다.

  더욱 소프트웨어는 빠르게 배급되고 더욱 생산성이 증하하며, 개발은 유지보수하는 방향으로 가고 있다. 프로젝트 관리는 부수적인 관리와 과업(Task) 관리에 의해 대체되었다. 더욱 많이 짧게 수평적으로 계획하는 것이나 계획하는 것은 제시간에 순차적으로 우선시하는 것과 분류하는 것으로 대체되었다.

  정보 기반시설로서의 코드와 함께 옵스는 개발자가 되었고, 설계하고 코딩 정보 기반시설과 정보 기반시설의 변화, 재활용과 재사용에 대한 생각과 복제와 리팩토링(단위로 묶는 것), 기술적인 의심과 시험 혹은 분석 가능성과 TDD에서 TDI(Test Driven Infrastructure)를 만드는 것에 대해 생각한다. 그들은 더욱 더 날렵하고, 매우 자주 작게 변화를 만들으며, 짬을 만들어서 프로그래밍 하는 것과 시간을 쓰고, 서류작업을 들한다.

  그리고 개발자들은 더욱 옵스같이 일을 하기위해 시작한다. 지원과 동작에 대한 책임을 자발적으로 한다. 동작에대한 위험으 첫번째로 생각하고, 제반시설에 대해 관리하며, 제작하는 것의 도구나, 장기간의 설계목표와 함께 동작지원에 대한 즉각적인 단기간 수요의 조화를 이룰 수 있는 방법을 찾는다.

  이것 중 어느 것도 온라인 사업에서 오랫동안 일한 사람에겐 놀라운 일이 아니다. 독자분들이 시스템을 넘겨주고 고객은 그 시스템을 사용하기 시작하며, 최우선적으로 변화하며, 독자 여러분 들도 일하고 계획 역시 변화해야 하는 것이다.

  이런 식으로 일하는 것은 개발자를 위해서 좋지 않거나 필수적으로 최악이다. 그러나 오늘날 일하는 것과 많은 개발자들이 어떻게 생각 하는 지에 것은 근본적으로 다르다. 더욱 미친듯이 바쁘고 지속적으로 빈번한 방해요인이 오히려 근무시 해야할 일을 잘되게 한다. 동시에 더욱 원칙적이고 더욱 의지한다. 더욱 투명해진다. 더욱 책임감과 의무를 갖는다. 개발은 덜하는 것과 출시, 배포, 동작과 지원에 더 집중한다.

  개발자들과 그들의 관리자들 운영중인 정보기술의 더욱 큰 그림의 부분이 되어가며 사용할 필요가 있고, 앱을 설계하는 것과 작성하고 코드를 넘겨주는 것보다 더욱 중요한다. 이것은 아마도 소프트웨어 개발의 미래일 수 있다. 그러나 모든 개발자가 이것을 좋아하지 않거나 혹은 좋아하기도 한다.

Published at DZone with permission of Jim Bird, author and DZone MVB. (source)
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

아무 연관도 없는 내가 왜 OKJSP를 운영하는가?

2013년 5월 OKJSP 운영을 맡게 되었다. 

14년전 개인이 만들고 개인이 운영하던 사이트를 내가 받았다. 내 주관으로 재 해석을 하고 대표님과 함께 OKJSP의 미래 모습과 밑그림만 가지고 개편작업을 시작했다.

결과는 참혹했다.

내가 개발한 신무기를 가지고 나와 뜻을 같이하는 동맹군과 함께 개편이라는 전쟁터에 나섰지만 지원군으로 생각했던 본거지는 나를 무시하며 지원을 해주지 않았고 동맹군은 길어지는 전쟁에서 하나 둘씩 떨어져 나갔다.
결국 전쟁에서 참혹하게 패배했고 남은것은 쓰라린 교훈과 1년이라는 시간이다.

다시 전쟁터에 나섰다.
이번에는 나와 뜻을 함께한 딱 한명의 동맹군이고 그 동맹군에게 전권을 위임하고 나는 본거지에서 지원을 하기로 했다. 여전히 나에게는 수많은 위험들이 있다. 언제 돌아설지 모르는 동맹군을 지원해야 하고 후방에서의 여러가지 정치적인 압박을 홀로 감당해야 한다.

하지만 이렇게 나서는 이유는 
첫째,
내가 가고자 하는 길이 뜬구름 같지만 그 뜬 구름같은 길이 맞다는 확신이 있다.

둘째,
이 전쟁을 무기를 팔려고 하는 기회로 생각하거나 전쟁에서 승리하여 독재 국가를 만들려 하거나 민주주의의 탈을 쓰고 자본주의의 이윤 추구에만 집중하지 않고 개발자들의 삶을 대변해 주는 전쟁임을 객관적인 시각으로 인지하고 있다.

셋째,
내가 만든 사이트도 아니고 개발도 모르고 내가 개편작업을 하지 않는 상황에서 아무런 도움없이 가장 빠르고 완성도 있게 만들 수 있는 유일한 방법이다.

넷째,
어차피 고도화 하는 2차, 3차 전투에 나서야 하기 때문에 노하우를 축척하고 향후 전투에서 리소스를 가장 줄일 수 있는 방법은 방향을 잡고 완성도 있는 기술적인 밑바탕 위에 어떤 것이든 담을 수 있는 캔버스를 만드는 중이기 때문이다.

정치적으로 목표를 위해 방향을 잡으라고 압박이 오지만 오히려 그것이 독이될 수 있다.
1년동안 운영하면서 느낀것은 운영진과 회원들의 방향이 같아야 발전이 이뤄진다. 그 방향은 내가 아무리 개발자라 할 지라도 알 수 없다. 그 방향은 커뮤니티를 통해 알아가는 것이다. 그래서 캔버스를 만든것이다. 캔버스 위에 어떤 내용으로 채워질 지는 이것저것 그려보고 커뮤니티들의 반응을 살펴 보면서 알 수 있는 것이다. 이것이 기존회원들과 신규 회원들을 모두 섭렵하며 변화할 수 있는 방법임을 1년동안의 고생을 통해서 알게 된 노하우다.

이 전투는 이제 시작이다.
이전에는 독립국가의 틀 안에서 만족하고 그 안에서만 티격태격 했지만 이제는 밖으로 나가야 할 때이다. 그러기 위해서 이제 무기를 만들기 시작했고 군대를 조직해서 처음 하는 전투이다. 이 전투의 목적은 어떻게 전투를 해 나가야 하는지 알아가는 과정이지 승리를 위한 전투는 아니다 승리를 위한 전투는 노하우가 쌓인 이후에 2차 전투가 될 것이다.
이런 관점이 아닌 승리를 위한 전투를 하게 된다면 결국 궁극적인 목적이 이윤추구의 도구로 전략하게 될 것이고 결국 여느 커뮤니티 사이트 처럼 개발자들의 영향력을 펼칠 수 있는 사이트라는 승리는 영원히 이뤄질 수 없을 것이다.

그 누구도 그 영향력에 대한 모습을 직,간접의 이윤추구라는 안개속에서 볼 수 없기 때문이다.

몇 백만원이면 벌써 완성도 있는 사이트를 만들고 지금쯤 수익을 내면서 운영하고 있겠지만 그렇지 않고 정치적인 압박을 받고 스스로의 자괴감이 들고 개발자들의 어려운 점들을 이해해 나가면서 내가 이렇게 나가는 것이 맞다는 확신이 선다.

내가 초등학교2학년때 처음 애플 컴퓨터를 보고 꿈꾸었던 개발자의 꿈을 20대 초반에 다시 접했을 때 그것은 재미와 꿈의 대상이 아니고 나를 돈벌게 해 주는 수단으로 전락했다.

이제 SW개발 교육이 정기 교육과정으로 채택되는 이 시점에 나와같은 꿈을 꾸는 학생들에게 SW개발이 돈을 벌게 해 주는 수단으로 전락하지 않고 꿈을 키워나가고 꿈이 곧 인생의 성공의 시발점이 되도록 연결해 주고 싶다. 내가 그들에게 그런 영향력을 줄 수 있는 방법이 OKJSP인 것이다.