제 2 장 이론적 배경
제 1 절 DevOps 의 등장 배경 1. 개발과 운영간의 갈등 2. 소프트웨어 개발 방법론 제 2 절 DevOps 의 이해
1. DevOps 의 유래
2. DevOps 의 정의와 현황 제 3 절 DevOps 적용 사례
제 4 절 DevOps 의 성공요인에 대한 선행 연구
—————————————————————————
[내용 서술]
제 2 장 이론적 배경
제 1 절 DevOps 의 등장 배경 1. 개발과 운영간의 갈등
Daniels 와 Davis(2016)은 DevOps 에 대해 이해하기 위해서는 DevOps 를 둘러싼 여러가지 소프트웨어 개발방법론과 소프트웨어 관련 기업이 가지고 있는 이슈와 같은 배경 지식에 대해 먼저 파악해야한다고 한다.
소프트웨어 기술의 발달과 수요의 증가로 기술이 점점 고도화되고 분업화되어가면서 역할과 책임 또한 분명하게 나눠지게 되었다. 소프트웨어를 위한 작업은 크게 개발과 운영으로 나뉘어질 수 있으며 이둘은 작업의 목표에 의해 서로 상반된 입장을 가지게 되었다. 넷플릭스나 유튜브와 같은 실시간 스트리밍 서비스 또는 온라인 게임 서비스 등 인터넷을 이용하는 모든 소프트웨어 기업의 경우 24 시간 서버를 중단할 수 없는 상태 즉 “무중단”으로 운영되는 시스템이라고 할 수 있다. 전인석(2015)에 의하면 “무중단 환경에서는 서비스가 유지되는 상태에서 배포를 해야하고, 서비스 장애가 발생하면 안되기 때문에 운영자와 개발자 간의 커뮤니케이션이 매우 중요하다.”고 한다.
운영자들은 일상의 재해, 예를 들어 정전사태에서도 시스템이 손상되지 않도록 장애를 최소화해야하는 의무를 가지고 있다.(Loukides, 2013) 또한 개발자들이 충분한
테스트와 검증을 거치지 않고 올리는 불안정한 프로그램 소스들을 배척하여 로그인조차
되지 않는 최악의 상태를 막아야한다. 반면, 개발자들은 고객의 요구에 의해 다양하고 최신의 기능을 되도록 짧은 시간내에 개발하여 운영시스템에 반영해야만 한다. (전인석, 2015)
이은정(2014)에 따르면 “개발자들은 변경과 개선을 통해 체계를 발전시키려 하고, 운영자들은 변화보다는 현 체계를 중단 없이 안전하게 유지하려고 한다. 이러한 업무상 상반되는 성격은 개발과 운영이 업무상 충돌하는 것과 더불어 각기 다른 분야로
인식되는 고정관념을 낳았다.”고 한다.
한편 전문적인 소프트웨어 회사가 아닌 소프트웨어 부서가 별도로 존재하는 기업의 경우 리더의 IT 지식이나 경험이 거의 없기 때문에 최근의 IT 기술의 동향이나 현실을 제대로 이해하지 못하고 막연한 추측으로 인력 배치에 예산을 적게 투자하거나
불필요한 부분에 예산을 낭비하는 경향이 있다. 또한 소프트웨어 담당자에게 무리한 요구와 기대를 하게 되고, 현재 담당자가 업무를 제대로 수행하지 못하더라도 비슷한 경험을 지닌 다른 인재를 데려오면 일이 바로 해결될 것이라는 믿음을 가지고 있다.
그럴 경우 안정된 일자리를 보장받지 못하는 불안정한 분위기가 조성될 수 있고 운영자와 개발자 간의 더더욱 갈등이 심화될 수 밖에 없다. 이는 비단 소프트웨어 기업만의 문제가 아니라 대규모 조직의 고질적인 문제인 개인이나 부서이기주의를 가리키는 “사일로 효과”와 맞물려 더 심화된다. 사일로는 원래 곡식을 저장해두는 굴뚝 모양의 창고를 의미한다.
Tett(2015)에 따르면 “생각과 행동을 가로막는 편협한 사고의 틀, 심리 상태를 가리키기도” 하며 “사일로에 갇힌 이들은 무엇이 문제인지 파악하지 못하고, 혹은 버젓이 드러난 문제를 문제로 인지하지 못한다. 스스로 만들어놓은 관료제, 분류 체계 안에 생각과 행동이 갇혀버렸기 때문이다”라고 설명한다.
Daniels 와 Davis(2016)에 의하면 "내가 X 를 하는 방법을 아는 유일한 사람이라면, 그들은 나를 없애 버릴 수 없습니다” 와 같은 사고방식을 가지고 다른 팀이나 동료들을 배척하기 위해 당장 직관적으로 이해할 수도 없고, 설명하는 가이드도 만들어놓지 않은 복잡하고 최신의 기술이나 소프트웨어 솔루션을 이용하여 담당업무를 본인이나 본인의 팀만 알도록 방어벽을 치는 행동을 한다고 한다. 그러나 소프트웨어 지식이나 경험이 부족한 관리자들이나 임원들은 그 현상에 대한 근본적인 원인에 대해 파악하지 못하고 독보적인 소프트웨어 담당자나 부서에 전적으로 책임과 권한을 부여하여 본래 시스템이 발전되고 안정적으로 운영되어야하는 두가지 목표 중 하나는 포기해야하는 사태에 이르게 되고 만다.
또한 Daniels 와 Davis(2016)는 조직의 비난 문화(Blame Culture)에 대해 소개하는데 비난 문화란 “개인이나 조직 수준에서 실수 할 때 사람들을 비난하고 처벌하는 경향이 있는 문화”를 의미한다. 이는 MaGregor 의 XY 이론과도 연관이 있다고 볼 수 있다. X 이론의 관점에서는 “리더가 조직구성원을 미성숙하고 피동적인 사람으로 대하게 되면 관료주의적 문화와 합리적 문화와 같은 조직 문화를 형성하게 된다는 주장을 가지고 있다고 한다.” (Zammuto and O’Conner, 1992; 권중생, 2000) 이러한 조직
분위기에서는 더 많은 사일로를 양성해낼 수 있으며 상반된 목표를 가진 부서 간의 의사소통이나 발전의 노력이 부족할 수 있다.
이를 보완하기 위해서는 학습조직(learning organization)과 뻔뻔스러움(Blamelessness) 문화를 장려해야한다. 이는 똑똑한 사일로를 고립된 공간에서 해방시키고 모든
구성원들이 조직에 필요한 기술을 학습하면서 지식을 공유하고 함께 발전해 나가는 방향을 추구하고 있으며, 비난 문화와는 반대로 업무 사고가 발생했을 때 사고의 원인과 해당 업무의 흐름을 모두 알고 있는 책임자가 바로 해고되는 것이 아니라 오히려 다같이 적극적으로 원인을 분석하며 실패를 학습하도록 유도하여 새로운 것에 대한 도전과 개선하고자 하는 의지를 높이고, 의사소통을 적극적으로 할 수 있도록 하는 효과가 있다고 볼 수 있다.(Daniels and Davis, 2016)
2. 소프트웨어 개발 방법론 작성 전략
A. 소프트웨어 개발 방법론의 정의 B. 소프트웨어 개발 방법론의 종류 C. 각 방법론에 대한 설명
폭포수 모델과 애자일의 익스트림 프로그래밍(XP), 린은 대표적인 소프트웨어 개발방법론이다.
최초의 폭포수 모델은 1970 년에 윈스턴 W.로이스에 의해 제안됐습니다. 이 방법이 적용된 대표적인 사례로는 미국 국방성과 미 항공우주국(NASA)에 의해 채택된 대규모 SW 개발을 꼽을 수 있으며, 이 외 다수의 대규모 정부 프로젝트에서 이 방법이
사용됐습니다.
폭포수 모델은 요구사항 분석에서 구현까지 한번에 순차적으로 진행되는 방식으로 갑작스러운 변경에 유연하게 대응하기가 힘들다는 단점이 있다. 반면 RUP 는 기존
개발단계를 짧은 기간동안 여러번 진행하여 점진적으로 제품을 완성하고 중간의 변경사항에 대해 유연하게 대처가 가능하다. (김동협, 2012)
워터 폴 방법론 또는 모델은 하드웨어 엔지니어링에서 적응 된 프로세스의 한 단계에서 다음 단계로의 순차적 진행에 중점을 둔 소프트웨어 개발 프로세스입니다. 이 모델의 원동력 중 하나는 버그가 발견 된 개발 프로세스의 초기 단계에서 버그를 수정하는 것이 더 쉽고 어떤 작업이 시작되기 전에 프로세스의 각 단계가 완전히 완료되도록하는 것이 었습니다. 다음. 초기 단계는 요구 사항 사양, 설계, 구현, 통합, 테스트, 설치 및 유지 보수였으며 한 단계에서 다른 단계로 진행 과정이 시각화되었습니다.
소프트웨어 개발방법론인 폭포수 개발 방식과 익스트림 프로그래밍(XP) 방식, Lean 개발방법론, ITIL(IT Infrastructure Library), 애자일, 소프트웨어 관련의 모든 커뮤니티(Community of Practice and Community of Interest), 조직내의 팀원간의 비난이 오가는 문화(Blame Culture, blameful culture), 부서 이기주의 정신을 가리키는 사일로(Silos), 비난 문화와 반대격인 조직내 문화로써 사고가 일어났을 때 오히려 적극적으로 원인을 분석하며 실패를 학습하도록 유도하는 문화(Blamelessness), 애자일 스프린트의 프로젝트 회고전(Retrospective), 학습 조직(Organizational Learning), 문제가 발생 직후 원인에 대해 분석하는 사후 부검(Post-Mortem) 등에 대해 설명하며 이들 모두가 DevOps 정의에 포함된다고 한다.
제 2 절 DevOps 의 이해 1. DevOps 의 유래
데브옵스(DevOps)는 2009 년, 벨기에의 소프트웨어 개발자인 Patrick Debois 에 의해 생겨난 용어로서 개발(Development)과 운영(Operations)이라는 단어가 축약되어 합쳐진 것이다. Foster(2016)은 [그림 2.2.2.1 DevOps 의 정의 DAWN FOSTER(2016) ] linux.com 에서 “DevOps 의 대부”로도 불리고 있다고 한다. 그는 대기업내에서
개발부터 네트워크 관리, 프로젝트 관리까지 소프트웨어 영역에서 다양한 역할을 15 년 넘게 맡아왔으며 2008 년 토론토의 한 Agile 컨퍼런스에 참여한 후 작업을 빠르게 끝내기 위해 개발자들과 운영팀간의 갈등을 해결 할 수 있는 방법에 대해 고민하게 되었다. 그리고 다음해 열린 O’Reilly Velocity 컨퍼런스의 “10+ Deploys per Day: Dev and Ops Cooperation at Flickr”라는 Seminal Talk 동영상에서 실행가능한 새로운 소프트웨어를 구축, 테스트 및 배포하는 유일한 방법은 개발 및 운영을 투명하게 만들고
통합하는 것이라는 주장에 영감을 받아 devopsdays 라는 컨퍼런스 조직을 만들게 되었다.(Rapaport, 2014)
Rapaport(2014)는 설립자인 Patrick Debois 에 대해서만 언급하였으나, Dodson(2013) 에 의하면 Stephen Nelson-Smith, Julian Simpson, John Willis, Kris Buytaert 등이 커뮤니티에서 아이디어를 주고 받다가 조직을 설립하게 되었다고 한다. (devopsdays, 2017) devopsdays 조직은 “소프트웨어 개발과 IT 인프라 운영 그리고 이들 사이의 교차점을 다루는 전세계 기술 컨퍼런스 시리즈”이며 그들이 다루고자 하는 주제는 주로
“자동화, 테스트, 보안 및 조직 문화”라고 한다. (devopsdays, 2017)
devopsdays 컨퍼런스는 2009 년에 벨기에 겐트(Ghent) 도시에서 최초로 개최되었다.
이때 70 명 이하의 사람들이 참여했는데 이들이 컨퍼런스의 다음 시리즈의 촉매 역할을 하였다. (Dodson, 2013) 2010 년에는 시드니, 상 파울로 등 4 개 도시에서 컨퍼런스가 열렸다. 현재는 2018 년까지 40 개 넘는 도시에서 컨퍼런스가 열릴 예정으로 [챠트 2.1.1]과 같이 꾸준히 증가하는 추세이다.
2. DevOps 의 정의와 현황
앞서 언급한 바와 같이 DevOps 는 개발(Development)과 운영(Operations)이라는 단어가 축약되어 합쳐진 용어이다. DevOps 에 대해 여러가지 정의가 혼용되고 있어 어떤 것이 정확한 정의인지에 대한 논쟁이 계속되고 있다. (Daniels, Davis 2016)
DevOps 라는 용어의 창시자이자 devopsdays 의 설립자인 Patrick Debois 은 2012 년 DevOps 리더십 시리즈 인터뷰에 출연하여 일회성 BMC 팟캐스트 호스트인 Tom Debois 의 DevOps 가 무엇이냐는 질문에 대해 아직도 많은 사람들에게 이 질문을 받고 있다고 답했다. 그는 그 용어를 생각해 내기 전에 애자일방법론으로 개발하는
프로젝트에 참여한 경험을 떠올리며 “애자일을 수행하는 동안 함께 작업할 수 있는 개발과 운영이 필요했다”고 한다. “DevOps 라는 용어를 ‘협업’으로 보고 있으나, 실제로 이것은 좁은 정의라고 할 수 있다. 그저 개발과 운영만이 협력하는 것이 아니라 모든 사일로, 비즈니스의 모든 부분, 기업 및 조직이 비즈니스 목표를 달성하기 위해 협력하게 되는 것”이라고 정의했다. (Little, 2012)
O'Reilly Media 의 컨텐츠 전략 담당 부사장인 Mike Loukides 는 그의 저서인 “What is DevOps?”에서 아마존의 엘라스틱 블록 스토리지(Elastic Block Storage, EBS)
서비스의 정전사태를 언급하며 일상의 사건 사고에도 안정되고 유연한 시스템 운영을 강조하면서 “운영은 사라지지 않고 개발의 일부가 된다. 대규모 데이터, 웹 성능 최적화, 애플리케이션 미들웨어 및 대규모 분산 환경에서의 내결함성을 이해하는 일종의
개발자를 구상하기보다는 개발팀에 운영 전문가가 필요하다. 인프라가 사라지지 않으며 코드로 이동한다. 인프라 관리자, 시스템 관리자 및 기업 IT 그룹은 인프라를 유지 관리하는 코드를 작성할 수 있도록 진화한다. 그들은 격리되기보다 애플리케이션을 만드는 개발자와 협력하고 협업해야한다. 이것이 비공식적으로 알려진 DevOps 라는 움직임(Movement)“이라고 정의내렸다. (Loukides, 2013)
BASS 외 2 명(2015, 28p)은 “우리의 DevOps 의 정의는 수단보다는 목표에 초점을 맞춘다.”고 말하며 “데브옵스는 높은 품질을 유지하면서 시스템에 대한 변경 사항의 적용과 그 변경 사항을 일반적인 생산 환경에 적용되는 동안의 필요한 시간을 줄이기 위한 일련의 실천방법(practices)이다”라고 정의했다.
Daniels 와 Davis(2016)은 DevOps 에 대해 “일부는 이를 소프트웨어 개발 방법으로 정의할 수도 있고 구성 관리 및 연속 제공과 같은 일련의 도구 및 기술이라고 생각할 수도 있다. 우리는 대신 devops 가 소프트웨어 개발과 현장에 관련된 사람들의 직업 생활을 향상시키려는 문화 운동이라고 주장할 것이다”라고 말했다.
Ebert 외 3 명(2016)은 (그림 2.2.2.2 DevOps 의 정의 Ebert 외 3 명(2016)) DevOps 를
“신속하고 유연한 개발 및 프로비저닝 비즈니스 프로세스에 관한 것”이라고 정의하며
“이는 개발, 납품 및 운영을 효율적으로 통합하여 전통적으로 분리된 사일로들을 낭비없고(lean) 유연하게 연결하도록 촉진(facilitating)한다고”한다. 또한 DevOps 는
“개발, 품질 보증 및 운영 간의 공동 작업으로의 문화 전환을 의미한다”고 정의했다.
아마존 웹서비스에서는 “데브옵스는 애플리케이션과 서비스를 빠른 속도로 제공할 수 있도록 조직의 역량을 향상시키는 문화 철학, 방식 및 도구의 조합”이라고 정의내리고 있다.
정리해보면 DevOps 의 정의는 사회적 관점과 기술적 관점으로 나눠볼 수 있다. 사회적 관점은 개발자와 운영자의 갈등으로 인해 소프트웨어 제품의 출시가 지연되는 상황을 문제로 인식하고 이를 해결하기 위한 방안으로서 서로의 입장을 이해하고 소통하는 문화를 제시한 경우이다. 기술적 관점에서는 복잡한 서버 관리와 시스템 배포의 잠재적 위험으로 인해 소프트웨어 개발 프로세스가 지연되는 것을 문제로 인식하고 이를
해결하기 위해 각종 시스템 자동화 관리 툴과 클라우드 서비스, PaaS 등의 기반 기술을 DevOps 팀에서 적극적으로 사용해야 한다는 것이다.
Puppet Labs 는 2013 년부터 연간 DevOps 보고서를 발행하기 시작했다. 2013 년 보고서에 의하면 2012 년 1 월부터 2013 년 1 월 사이 구인구직 사이트인 indeed.com 에서는 2011 년에 비해 DevOps 에 대한 구인 목록이 75% 증가했고
링크드인닷컴에서는 DevOps 기술에 대한 멘션이 50%나 증가했다. 또한 부서 구성비율 조사결과 IT 운영 70%, 개발 23%, QA/기타 7%로 나타나 DevOps 부서가 어느정도 비율인지는 알 수 없었으나 다음해인 2014 년도 보고서에서는 2013 년 12 월 110 개의 국가에서 9,200 명 이상의 IT 종사자들을 대상으로 설문조사를 한 결과 DevOps 개념이 생겨난지 5 년만에 전체 대상자 중 16%(1,485 명)이 DevOps 부서 소속이며 이 중 55%
가 DevOps 엔지니어 또는 시스템 엔지니어라는 사실을 발견했다. 그후 2015 년 19%, 2016 년 22%, 2017 년 27%의 비율로 지속적으로 늘어나고 있다. (Puppet Labs, 2013- 2017) [챠트 2.2.1 Puppet Labs 2017 년 보고서 소프트웨어 부서 비율]
참고 문헌
<동양문헌>
Len BASS & Ingo WEBER & Liming ZHU, ( 원 서 출 판 : Addison-Wesley Professional, 2015), <DevOps 아키텍트를 위한 첫번째 데브옵스 지침서> (김영기, 박득형 역), 서울 : 에이콘 , 2016
Gillian Tett, (원서출판 : The Silo Effect/Simon & Schuster Intl), “사일로 이펙트 : 무엇이 우리를 눈 멀게 하는가” (신예경 옮김) 서울 : 어크로스, 2016
권 중 생 . (2000). 변 혁 적 리 더 십 , 조 직 문 화 및 구 성 원 의 방 어 적 행 동 의 관 계 . 산업경제연구, 13(2), 157-176.
박 수 용 , 조 황 희 , “ 소 프 트 웨 어 경 쟁 력 향 상 방 안 연 구 : SW Roadmap”, 과학기술정책연구원, 2012
김동협, “애자일 방법론을 적용한 프로젝트의 품질 향상을 위한 감리 방안
“, 건국대학교 정보통신대학원 정보통신학과, 2012
이지원, “기업용 업무지원 시스템에서의 DevOps 를 적용한 SW 유지보수 프레임워크”
서강대학교 정보통신대학원 소프트웨어공학 전공 , 2013
전 인 석 , “ 보 안 을 고 려 한 무 중 단 환 경 에 서 개 발 운 영 조 직 통 합 관 리 (DevOps)” , 한국정보보호학회, 情報保護學會誌, Vol.25 No.1, (47~52page), 2015
이은정, “ 개발운영조직 통합관리(DevOps) 프로세스 연구 ”, 高麗大學校 融合 소프트웨어專門大學院, 2015
디지털 타임스, “[용어 아하!] 폭포수 방법론”, (2013-04-16),
http://www.dt.co.kr/contents.html?article_no=2013041702012269746002, (검색일: 2017.07.08)
Amazon webservices, “데브옵스란 무엇입니까?”,
https://aws.amazon.com/ko/devops/what-is-devops/ (검색일: 2017.07.07)
<서양문헌>
Mike Loukides, “What is DevOps?” , O'Reilly Media , 2012, (71p).
Katherine Daniels and Jennifer Davis, “Effective DevOps”, O'Reilly Media , 2016 , (9~ 36page).
McGregor. D. “Human Side of Enterprise”, New York : McGraw-Hill. 1960.
Christof Ebert, Gorka Gallardo, Josune Hernantes, and Nicolas Serrano, “DevOps”, IEEE SOFTWARE 0740-7459 http://www.computer.org/SOFTWARE, 2016 , 94p.
Puppet Labs, “2013-2017 State of DevOps Report”, (https://puppet.com/resources/white-paper/), 2013-2017.
Waqar Hussain, Tony Clear, Stephen MacDonell from Software Engineering Research Lab, “Emerging Trends for Global DevOps: A New Zealand Perspective”, ICGSE(IEEE International Conference on Global Software Engineering), 2017.
devOpsdays, https://www.devopsdays.org/, (검색일 : 2017.07.06).
Jessica Dodson , “A Brief and Incomplete History of DevOps”, July 29, 2013, http://blog.sonatype.com/2013/07/a-brief-and-incomplete-history-of-devops/ , ( 검 색 일 : 2017.07.07).
Richard Rapaport , “A Short History of DevOps
”, 23 Dec 2014, https://www.ca.com/us/rewrite/articles/devops/a-short-history-of-devops.html , (검색일 : 2017.07.06).
Dawn Foster, ”What is DevOps? Patrick Debois Explains” , June 21, 2016 https://www.linux.com/blog/what-devops-patrick-debois-explains, ( 검 색 일 : 2017.07.07).
Christopher Little, ”Patrick Debois on DevOps - What it is, what it's not (Part A)”, 2012. 2. 29 , https://communities.bmc.com/community/historical/devops-mkt- topic/blog/2012/02/28/patrick-debois-interview-on-devops--what-it-is-what-its-not (검색일 : 2017.07.07).
Zammuto, R. F., & O’Conner. E. J., Gaining Advanced Manufacturing Technologies’ Benefits : The Role of Organization Design and Culture.
Academy of Managemnet Review. 17.4, 1992. (701-728page)
저자명, 제목, 날짜, 사이트주소(검색일자)
년도 내용
2009 Patrick Debois에 의해 벨기에 겐트(Ghent)에서 devopsdays 조직을 설립하여 컨퍼런스 행사를 개최했다.
2010 윌슨(Willis)과 데이먼 에드워즈(Damon Edwards), 앤드류 클레이 셰퍼 (Andrew Clay Shafer) 등의 지지자들의 도움으로 미국 컨퍼런스를 개최했다.
2011 가트너(Gartner)의 카메론 하이트(Cameron Haight)라는 분석가가 2015 년까지 전 세계 2000개 비즈니스 중 20%가 DevOps 를 받아들일 것으로 예견했다. 451 Research 의 Jay 2012 방갈로르에서 보스턴에 이르기까지 전세계의 여러 Devopsdays 컨퍼런스가 개최되었다.
2013 O'Reilly Media의 콘텐츠 전략 담당 부사장인 Mike Loukides 는 “What is DevOps?”라는 소책자를 발간했다. 그는 devopsdays 조직의 설립자 Debois 와 함께 DevOps 의 정의를 2014 2014년에는 는 끊임없이 진화하는 기술 세계에 새로운 도전과 기회를 DevOps 의
개념으로 제시합니다. 모바일 환경에서 새로운 장치, 응용 프로그램, 콘텐츠 및 트랜잭션이
우리가 공예품을 연습하는 데 사용하는 도구 외에도 우리 문화의 동등하게 중요한 부분은 우리의 가치관, 규범 및 지식입니다. 사람들의 업무 방식, 우리가 사용하는 기술, 우리가 일하는 방식에 영향을 미치는 기술 및 사람들이 기술에 영향을주는 방식을 조사하는 것은 우리 조직 및 업계의 경관에 대한 의도적 인 결정을 내리는 데 도움이 될 수 있습니다.
(Dodson, 2013)
Devops 는 다른 소프트웨어 개발 방법론이 아닙니다. Agile 또는 XP 와 같은 소프트웨어 개발 방법론과 관련이 있으며 영향을 받지만 소프트웨어 개발 방법 또는 인프라 자동화 및 지속적인 제공과 같은 기능을 포함 할 수 있습니다. 이러한 부분을 합한 것 이상의 의미가 있습니다. 이러한 개념은 관련성이 있으며 devop 환경에서 자주 볼 수 있지만, 그 개념에만 초점을 맞추면 더 큰 그림, 즉 devop 의 힘을주는 문화적 측면과 대인 관계 측면을 놓칠 수 있습니다. DevOps 는 처음에는 단순한 개념으로서 개발자와 IT 간의 의사 소통 채널로 생각되어 왔으며, 프로세스 시작부터 증분 빌드 시스템에 솔루션 배포에 이르기까지 자동화가 포함되어 전체 개발 라이프 스타일을 포함하도록 확장되었습니다. , 애자일 방법으로지지 된 것과 같은 이 아이디어는 이제 특히
인터넷에 배포 된 동적 응용 프로그램에 대해 채택 된 "지속적인 전달"이라는 또 다른 용어를 형성했습니다.
82%의 응답자가 DevOps 전략에서 중요한 핵심 동인으로 오픈소스를 꼽았습니다.
출처: DEVOPS, 오픈소스 및 비즈니스 민첩성(OPEN SOURCE AND BUSINESS AGILITY), 2015 년 6 월 16 일, IDC
(Loukides,2012)
Netflix 의 NoOps 에 관한 Adrian Cockcroft 의 기사는 몇 달 동안 연기 된 논란을 일으켰습니다. Adrian 의 기사에 대한 John Allspaw 의 자세한 답변은 중요한
사실입니다. Adrian 이 "NoOps"로 묘사 한 것은 실제로는 아닙니다. 작업이 사라지지 않습니다. 책임은 시간이 지남에 따라 변할 수 있고, 변화 할 수 있으며, 변화함에 따라 직업 설명도 변할 수 있습니다. 그러나 당신이 그것을 어떻게 자르더라도, 동일한 일이 수행 될 필요가 있고, 그 일 중 하나는 작업입니다. Adrian 이 Netflix 에서 NoOps 로 부르는 것은 Etsy 에서의 운영과 다른 점이 전부는 아닙니다. 그러나 그것은 단지 질문을 요구합니다. 21 세기의 "운영"이란 무엇을 의미합니까? NoOps 가 작업을 의심스러운 작업과 비슷한 것으로 대체하는 움직임 인 경우 확실한 혼란이 있습니다. 이제 열정의 일부가 사라 졌으므로 우리가 작업에서 의미하는 바를 이해하고 그 변화가 어떻게 변했는지 알아볼 시간입니다.
김정보, 정진영, 김정인, “중소규모 SW 개발 프로젝트를 위한 시각화 기반의 Tool-Chain 품질관리 방법 제안 ”, 멀티미디어학회논문지 (18(4), 546-556), 2015
소프트웨어 개발 방법론이란 소프트웨어 공학원리를 소프트웨어 개발 생명주기에 적용한 개념으로서 정보시스템을 개발하기 위한 작업 활동, 절차, 산출물 기법 등을 체계적으로 정리한 것이다.
작성 전략
소프트웨어 개발 방법론의 정의 소프트웨어 개발 방법론의 종류 각 방법론에 대한 설명
