새로운 일을 시작할 때에는 불확실성을 이겨낼 수 있는 힘이 있어야한다.
결혼해서 10세 미만의 자녀를 둔 가장이라면, 아내의 동의가 가장 큰 힘일 것이다.
하지만 동의를 얻기위한 과정이 필요하다.
대부분의 사람들은 결론을 과정이라고 착각한다. 여기서 대부분은 나를 말한다.
결론은 승리일 것이다. 결론은 거룩한 것이다. 따라서 동의를 해야한다. 뭐 이런 식인 거다.
여기에는 그동안에 고생한 보상심리와, 자신감 아니 자만심이 포함되어있다.
이 말을 꼭 내 자신에게 해주고 싶다.
새로운 시작의 일을 할 때에는 시작을 어떻게 하는지가 가장 중요하다.
그렇지 않으면 나 스스로 고독하게 결론에 도달해야 한다.
Wednesday, March 20, 2019
Friday, November 24, 2017
Monday, September 18, 2017
기도의 목적
믿음 안에서 선한 삶을 결단하려고 할 때 사탄은 가장 약한 부분을 파고든다.
알면서도 매번 무너진다.
"오직 예수"라고 외치는 선교사님들의 마음이 조금 이해가 된다.
사회 관계, 가족, 가정, 자신에 대해서 매일 거듭나지
않으면 아무리 기도를 많이해도 나를 위한 기도일 뿐 남을 사랑하기위한 것은 없는 것 같다.
Monday, September 11, 2017
[Book] 행복은 깨어있는 사람에게 허락된다
https://books.google.co.kr/books?id=1tdbAgAAQBAJ&lpg=PT165&ots=2skQvS5eLV&dq=%EB%AA%A8%EB%93%A0%20%EA%B2%83%EC%9D%84%20%EB%B6%88%EC%82%AC%EB%A5%BC%20%EC%A7%80%EB%9D%BC%EB%8F%84&pg=PT3#v=onepage&q=%EB%AA%A8%EB%93%A0%20%EA%B2%83%EC%9D%84%20%EB%B6%88%EC%82%AC%EB%A5%BC%20%EC%A7%80%EB%9D%BC%EB%8F%84&f=false
Wednesday, February 10, 2016
About Startup #4 - 시작과 본질 Part.1 상승작용
Startup을 시작하는 유형은 대부분 크게 다르지 않다.
Startup이기 때문에...
외국에서는 본인 일을 하면서 Startup셋팅을 시작하고 정식 서비스가 이루어 지면서 본격적인 궤도에 진입이 예상될 시점에 본인 일을 그만두고 Startup에 올인한다고 한다.
이것은 초기에 서로간에 합의가 있어야 할 것이다.
하지만 한국인 성향상 무언의 합의를 하는 경우가 많다.
여기서 합의하는 당사자인 A와B의 이해 관계가 맞기 때문에 합의할 것이다.
성공한 Startup의 과정을 보면 미화된 부분이 많지만 공통적인 부분이 있다.
Apple의 경우 마케팅의 스티브 잡스, 개발의 워즈니악, 디자인의 조너선 아이브 등
서로의 역할이 명확하고 상승작용을 통해 여러 우여곡적이 있었지만 결국 세계 최고의 회사를 만들 수 있었다.
처음 회사를 만든 사람 즉 CEO는 이런 로망을 멤버 모집의 무시할 수 없는 수단으로 활용하고 이것은 당연하다.
문제는 이런 로망을 바라보고 참여하는 멤버에게 있다.
아무리 본인 능력이 뛰어나고 돈이 많더라도 Startup의 본질을 이해해야 하고 조직이 셋팅이 되기 전 CEO와 본인과 어떤 시너지를 낼 수 있을지에 대해 매우 깊이 고민해야 할 것이다. 사실 초기에 회사 가치보다는 CEO와 그 주변에 있는 키 멤버와 본인과의 관계가 전부일 것이다.
아무리 CEO의 달콤한 미래지향적인 비전을 제시하더라도, 아무리 많은 주식을 주더라도 결국 본인이 그 안에서 역할을 충실히 할 수 있어야 하고 여러가지 상황을 판단해서 참여하는 Startup이 정상 궤도에 오르기 까지 꾸준하게 일을 할 수 있어야 한다.
보다 직접적으로 말해서 CEO와 키 멤버들에게 회사의 성공을 바라기 보다는 그들과 본인과의 역할을 명확하게 나눠서 시너지를 낼 수 있는지에 대한 객관적인 판단이 되야 한다.
아무리 본인이 회사를 위해 희생을 하더라도 본인 역할이 시너지를 낼 수 없거나 본인으로 하여금 더 많은 리소스를 요구하거나 꾸준하게 일을 할 수 없다면 아쉽지만 그것은 본인 욕심이고 무책임으로 돌아온다.
비즈니스를 하다보면 업력도 훌륭하시고 사람과의 교류 즉 네트워킹에 매우 강점이 있는 분들이 있다. 이런 분들은 현재 그 분들이 얼마나 성공했느지가 별로 중요하지 않다. 항상 현재 진행형이고 주변에 업계에서 유명하고 성공한 훌륭한 선,후배가 있기 때문에 그들로 하여금 영광이 있기 때문이다.
이런 분들이 Startup을 하거나 키 멤버로 활동하시는 경우가 많다.
보통 기술만 있고 비즈니스 역량이나 마케팅 역량이 부족하기 때문에 이런 부분을 그런 분들이 채워주시기 때문이고 위에서 말한 시너지 효과를 톡톡히 누릴 수 있기 때문이다.
Startup의 키 멤버는 스티브잡스, 워즈니악, 조너선 아이브처럼 본인이 역할을 해 줘어야 하는데 단순히 희생은 본인이 할 수 있는 역할을 객관적으로 바라보지 못하게 한다.
그리고 언젠가 성공하리라는 희망은 본인 주도적이 아니라 기대고자 하는 마음이 강하게 작용하기 때문에 기업의 가치를 본질적으로 바라보지 못하게 한다.
모두가 Startup이라는 사실에 동의하고 시작했다면 철저하게 본인 주도적이 되어야 하고 그것이 다른 멤버들과 시너지를 낼 수 있어야 한다.
그럴 때 서로의 역할이 명확해 지고 가치없는 희생이 요구되지 않는다.
Startup이기 때문에...
외국에서는 본인 일을 하면서 Startup셋팅을 시작하고 정식 서비스가 이루어 지면서 본격적인 궤도에 진입이 예상될 시점에 본인 일을 그만두고 Startup에 올인한다고 한다.
만약 이런 경우는 어떨까?
멤버 일부는 본인 회사를 다니며 경영에 참여하고 일부는 올인해서 경영에 참여한다면...이것은 초기에 서로간에 합의가 있어야 할 것이다.
하지만 한국인 성향상 무언의 합의를 하는 경우가 많다.
여기서 합의하는 당사자인 A와B의 이해 관계가 맞기 때문에 합의할 것이다.
이 이해관계가 시작의 중요한 첫 단추가 된다.
성공한 Startup의 과정을 보면 미화된 부분이 많지만 공통적인 부분이 있다.Apple의 경우 마케팅의 스티브 잡스, 개발의 워즈니악, 디자인의 조너선 아이브 등
서로의 역할이 명확하고 상승작용을 통해 여러 우여곡적이 있었지만 결국 세계 최고의 회사를 만들 수 있었다.
오늘은 첫 단추, 상승작용에 대해 얘기하고 싶다.
Startup의 로망은 초기 멤버로 시작해서 투자를 받고 회사를 키우고 상장을 하여 초기에 받은 주식의 실제적인 경제적 가치를 인정받는 것에 있다.처음 회사를 만든 사람 즉 CEO는 이런 로망을 멤버 모집의 무시할 수 없는 수단으로 활용하고 이것은 당연하다.
문제는 이런 로망을 바라보고 참여하는 멤버에게 있다.
아무리 본인 능력이 뛰어나고 돈이 많더라도 Startup의 본질을 이해해야 하고 조직이 셋팅이 되기 전 CEO와 본인과 어떤 시너지를 낼 수 있을지에 대해 매우 깊이 고민해야 할 것이다. 사실 초기에 회사 가치보다는 CEO와 그 주변에 있는 키 멤버와 본인과의 관계가 전부일 것이다.
아무리 CEO의 달콤한 미래지향적인 비전을 제시하더라도, 아무리 많은 주식을 주더라도 결국 본인이 그 안에서 역할을 충실히 할 수 있어야 하고 여러가지 상황을 판단해서 참여하는 Startup이 정상 궤도에 오르기 까지 꾸준하게 일을 할 수 있어야 한다.
보다 직접적으로 말해서 CEO와 키 멤버들에게 회사의 성공을 바라기 보다는 그들과 본인과의 역할을 명확하게 나눠서 시너지를 낼 수 있는지에 대한 객관적인 판단이 되야 한다.
아무리 본인이 회사를 위해 희생을 하더라도 본인 역할이 시너지를 낼 수 없거나 본인으로 하여금 더 많은 리소스를 요구하거나 꾸준하게 일을 할 수 없다면 아쉽지만 그것은 본인 욕심이고 무책임으로 돌아온다.
비즈니스를 하다보면 업력도 훌륭하시고 사람과의 교류 즉 네트워킹에 매우 강점이 있는 분들이 있다. 이런 분들은 현재 그 분들이 얼마나 성공했느지가 별로 중요하지 않다. 항상 현재 진행형이고 주변에 업계에서 유명하고 성공한 훌륭한 선,후배가 있기 때문에 그들로 하여금 영광이 있기 때문이다.
이런 분들이 Startup을 하거나 키 멤버로 활동하시는 경우가 많다.
보통 기술만 있고 비즈니스 역량이나 마케팅 역량이 부족하기 때문에 이런 부분을 그런 분들이 채워주시기 때문이고 위에서 말한 시너지 효과를 톡톡히 누릴 수 있기 때문이다.
여기서 속지 말아야 할 부분이 있다.
그 분들의 영광을 보면서 나도 함께 희생하면 언젠가는 성공하겠지라는 생각이다.Startup의 키 멤버는 스티브잡스, 워즈니악, 조너선 아이브처럼 본인이 역할을 해 줘어야 하는데 단순히 희생은 본인이 할 수 있는 역할을 객관적으로 바라보지 못하게 한다.
그리고 언젠가 성공하리라는 희망은 본인 주도적이 아니라 기대고자 하는 마음이 강하게 작용하기 때문에 기업의 가치를 본질적으로 바라보지 못하게 한다.
모두가 Startup이라는 사실에 동의하고 시작했다면 철저하게 본인 주도적이 되어야 하고 그것이 다른 멤버들과 시너지를 낼 수 있어야 한다.
그럴 때 서로의 역할이 명확해 지고 가치없는 희생이 요구되지 않는다.
Sunday, September 28, 2014
Sunday, September 14, 2014
DevOps Isn't Killing Developers – But it is Killing Development and Developer Productivity
안녕하세요. ^^
옥희 회원님께서 번역해 주신 DevOps관련 글입니다.
모든 개발자들이 개발 방법론 협업 방법에 대해서 항상 고민하고 있습니다.
이와 관련해 한번쯤 꼭 읽어 보시기를 권해드립니다.
출처 원문 : http://java.dzone.com/articles/devops-isnt-killing-developers
이러한 DevOps Zone 은 PagerDuty와 새로운 C.A.L.M을 지속하고 DevOps 문화를 설립한 것을 수행한 분들에 의해 소개되었다. Devops은 개발자를 힘들게 하지 않는다 (적어도 내가 아는 한 어떤 개발자도 난처한 적 없다.) 그러나 Devops은 개발자를 미치게 만들거나, 소프트웨어를 개발하고 전달하며 우리가 대부분 생각하는 방법을 제시한다. 애자일(Agile)은 총이며, Devops는 방아쇠를 당긴다.
다양한 규모가 축소되는 방향으로 개발이 자꾸 집중되기 때문에, 일을 빠르게 끝마치기 위해 시간 틀(frame)을 시행한다. 이런 면과 기준 그리고 프로젝트 검토에서 조금씩 확실하게 최선을 다해 검토하고 진행 중인 일의 한계와 과업의 수준을 최적화 하기위해 통제(Control)한다. 이런 소프트웨어 제품의 규모에 따라서, 어떠한 프로젝트 팀은 1년 후에 완성된 결과물(프로젝트)을 전달하거나, 스크럼 팀(Scrum team)이 1달 후나 1주 후에 프로젝트를 완수하고, 어떤 개인적인 개발자는 몇 시간 후나 며칠 후에 개발을 시작한다. “끝냈다”는 것의 뜻과 “작동중인 소프트웨어” 라는 것은 암호 혹은 부호로 처리가 되어 있고 잘 되거나 시험운행(테스트)하는 것이 가능하며 제작한 소프트웨어를 증명할 준비가 된 생산작업에 의해서 바뀔 수 있다는 것이다. -지금(“끝은 공유를 의미한다.(Done Means Released)”에서).
지속적인 전달과 지속적인 배치는 지속적인 통합이라 말할 수 있다.. 작업에서 신속한 배치는 수작업으로 확인하는 담당자나 수작업 테스트 중일 때 있어서, 시간을 낭비하지 않는다. 개발자들은 코드를 제품출시 하기 전에 소프트웨어 제품을 시험운행하며, 소프트웨어에서 발생한 문제를 해결하기 위해, 해당 소프트웨어 제품의 모든 버그를 포착하여 문제를 해결해야 할 책임이 있다.(아카[aka]”시험운행 중으로서의 관찰”에서)
그 이유는 데브옵(Devops)은 개발자들에게 소프트웨어 제품생산을 손쉽게 하며, (소프트웨어 제품)동작시 위험이 프로젝트 위험보다 더 중요하게 되며, (소프트웨어 제품)동작에 대해 측정한 것 역시 프로젝트를 측정한 것보다 중요하다. 소프트웨어 제품을 작업함에 있어서 시스템 가동시간과 순환시간(cycle time)은 획득한 가치나 속도로 대체한다. 다급한 마감시한에 대한 강조는 생산시 다급함에 대한 강조며 관심사 1순위로 대신하게 된다.
데브옵(Devops)은 프로젝트를 전달하거나 심지어 기능을 전달하지 않는다. 이것은 최소화된 리드타임(생산부터 완성까지 걸리는 시간)과 작업에서 생산까지 최적화된 흐름, 화제를 놓치지 않으며, 쓸데없는 일을 하지 않음과 동시에 지연되고 미뤄진것은 신뢰할 수 있는 시스템으로 개선하는 것, 운영비용을 삭감하고 생산에서 개발까지 계속적인 조언으로 반영한다. 추가로, 표준화하고 자동화하는 절차가 가능한 많이 있다. 보통의 공학기술 보다 과정을 제어하고 생산하는 것이다.
당신은 LOC에 의해서 개발자 생산성을 판단하거나 기능의 강조점 이나 기능점 이거나 이야기의 강조할 점 이거나 빠르기나 작성된 많은 코드 몇 줄의 다른 측정법 등을 적은 코드로 판단한다. 사회 공공 기반 시설과 제시안 [플랫폼] 등을 이해하는 것에 대한 시간 학습은 확실히 만들고 설정을 올바르게 하는 것이다. 그것은. 또한, 계속적으로 발전시키고(Building) 전달하며, 다양한 경로를 계속적으로 배치하는 것이다. 옵스(ops)를 살피기 위해 돕는 것과 이슈를 해결하는 것은, 긴급한 고객의 다양한 요청에 응답하는 것이고 질문과 성능 문제에 대해 관찰하고 시스템을 감시하는 것은 일을 정확하게 하는 것이며, A/B 실험 운영하는 것을 돕는 것이다. 변화를 장려하고 준비하는 것은 시험운행하고 코딩(소프트웨어를 제작하고)하고 설계하며 필수적인 것에 대해 미리 시도하고 개발하는 것으로 부터 시간을 쓰는 것이다.
개발자들은 몇 시간뒤에 대기 중이었다가 옵스에 접속한다. 하루의 일과를 마치고 난 뒤(퇴근 후), 다시 말해서 (누군가의 호출에 시달리거나) 의무를 다하고 옵스에 접속한다는 것이다. 그리고 시간을 투자하며 문제해결을 위해서 지원 한다는 뜻은 정말 문제가 되게 하지 않기 위해서, 긴 밤과 주말을 바쳐가며 소프트웨어 제품의 이슈를 찾아내고 문제점을 해결하기 위해 도움을 주며, 다음날 피로에 쩔어도 자잘한 운영과 시험운행 및 시스템 대체 작동과 미리 운행(roll-forward)하고 다시 소스를 원복하고(commit 하기 전 roll-back), 프로젝트가 끝난 뒤에도 참여 하며, 프로그램이 뭔가 잘못 돌아가거고 시스템이 대체 작동되거나 미리 운행 (roll-forward)하거나 소스를 원복(원상복귀)시켜도 동작하지 않을 때 문제의 원인을 분석하는 것을 말하는 것이다.
당신은 중단과 운영상의 문제에 대해서 계획 할 수 없다. 그리고 당신은 그것들과 관련된 것을 또한 계획할 수 없다. 개발자들은 그들이 자주 베푸는 헌신에 대해 잊을 것이다. 그러면 왜 그들이 어째서 헌신하는가? 계획을 수립하거나 평가하는 것에 대해서 왜 신경을 쓰는 것인가? 가장 중요한 것에 집중하는 하기 전에, 제대로 우선순위를 매기는 것은 옵스나 고객이 갑자기 필요로 하는 것, 추가로 당신이 할 수 있는 것을 바로 실행하는 것 - 그렇지 않으면 뭔가 더 중요하거나 이슈화 된 것 그리고 그것을 미연에 방지하는 것이다.
개발자로서 옵스에 더욱 시간을 쓰고 책임감을 가지고 행동하는 것은 다중 작업 그리고 본연의 임무를 수행하는 것과 중단 및 비효율성을 가져오기도 한다(본연의 임무만 집중했을때 얻을 이익을 일컫는다). 개발자가 옵스에 참여해서 투자해야 할 시간이 증가하고, 손해보는 시간과 본인을 위한 일을 하지 못하는 것 등이 중단 및 비효율성을 의미한다. 이러한 것은 생산성이 지연되는 결과를 가져온다. 그리고 반면에, 문제해결에 참여한 사람들의 생각하는 능력에 있어서 매우 큰 영향을 주고 문제해결에 기여한다. 그렇지만 계속적인 개발 조언만으로도 개발자만의 작업흐름을 방해한다.
개발자가 코드를 확인한 뒤에, 계속적인 통합을 위해 단위별 테스트를 하는 것은 더욱 퍼포먼스를 증대시키고, 몇 초 혹은 몇 분이 빨라진 다는 점에서 개발자들이 개발자의 괴업과 함께 행동할 수 있게 된다. 그러나 작업을 위해 즉각적으로 배치하는 것이 의미하는 것은 통합테스트 단위를 더욱 확장하는 것을 통해 운영하는 것을 뜻하고, 시스템 시험운행과 계속적인 전달을 위한 다른 확인도 하는 것을 뜻한다(더 철저하게 시험운행 하는 것과 더욱 시간을 들여서 확인 하는 것).그리고 그 다음, 배치를 통해서 단계적으로 실행하며, 작업을 살피고 모든 일이 제대로 돌아가는지 확인 하면서, 어떤 것이 잘못 되었는지 확인 하는 것이다.
만약 거의 모든 단계들이 자동화되고 최적화 되어 있을지라도, 이것들 전부 추가 시간과 코딩하는 것을 떠나서 개발자의 주의가 필요하다.
작업의 흐름을 최적화 하는 것과 운영을 밖의 의미는 개발자의 에너지를 희생하는 것이다. 또는 개발일 그자체를 늦추는 일을 발생시킨다.
데브옵에서 방법이란, 개발자들(그리고 옵스) 과업을 변화하는 방법과, 그들이 관리되어 지는 것의 변화하는 방법을 이야기 하는 것이다. 그것은 또한 개발자들을 위해 중요한 기대와 통계, 장려책을 변화하기 위한 것이기도 하다.
데브옵의 성공은 운영중인 정보기술 통계에 의해 측정되고, 어떠한 범주의 프로젝트 전달 목표에 의한 것이 아니며, 일정과 비용, 발표할 목표나 최우선적인 헌신을 충족하는 것도 아니며, 혹은 심지어는 제품 디자인 목표에 만족하는 것도 아니다.
정보 기반시설로서의 코드와 함께 옵스는 개발자가 되었고, 설계하고 코딩 정보 기반시설과 정보 기반시설의 변화, 재활용과 재사용에 대한 생각과 복제와 리팩토링(단위로 묶는 것), 기술적인 의심과 시험 혹은 분석 가능성과 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.)
옥희 회원님께서 번역해 주신 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.)
Subscribe to:
Posts (Atom)