2013.12.12

ITWorld 용어 풀이 | 데브옵스(DevOps)

박재곤 기자 | ITWorld
데브옵스는 개발(Development)와 운영(Operation)을 합친 말로, 개발과 운영 간의 상호 작용을 원활하게 하는 모든 것을 의미하는 포괄적인 개념입니다. 그렇다고 개발과 운영을 동시에 수행한다는 말은 아닙니다.

IT 관리 관점에서 개발과 운영은 당연히 다른 업무이면서 상호 연결되는 것이 분명합니다. 개발팀이 현업에서 필요로 하는 요구사항을 수용해 애플리케이션을 개발하듯, 운영팀은 개발팀에서 만들어 낸 애플리케이션을 IT 인프라 상에서 운영해야 하기 때문입니다.

각자의 역할이 분명한 이 두 팀 간의 상호 작용에 중점을 둔 데브옵스가 부상하게 된 것은 개발과 운영 간에는 커다란 관점의 차이가 있고, 이러한 차이가 효율적인 IT 운영을 심각하게 저해하기 때문입니다.

변경이라는 한 가지 요소만 놓고 생각해 봐도 차이는 분명해집니다. 개발팀은 변경이 자신의 가치를 증명하는 것이라고 생각합니다. 새로운 것을 계속 만들어내지 않으면 개발팀은 존재의 의미가 없어집니다. 하지만 운영팀에게 변경은 적 그 자체입니다. 변경은 운영팀의 지상과제인 안정적인 운영을 방해하는 요소이기 때문입니다.

게다가 이 두 팀의 이런 관점은 독립적으로 볼 때 옳은 것입니다. 여기에다 기업의 규모에 따라 두 팀은 전혀 다른 조직 구조에서 서로 다른 부서장 아래 있는 경우가 많고, 심한 경우 지리적으로도 따로 떨어져 있습니다.

과연 어떤 문제가 발생하는지 예를 들어 보겠습니다. 개발팀에서 애플리케이션에 새로운 기능을 추가하거나 기존 기능을 수정하는 이른바 ‘변경’을 가해 실제 운영 중인 시스템에 적용하기 위해 운영팀으로 넘겨 줍니다. 운영팀은 이를 받아 실제 배치를 위한 준비를 합니다. 배치를 위한 스크립트도 짜고 실제 운영 환경에 맞게 환경설정 파일도 편집합니다.

가장 좋은 경우는 운영팀이 이전 환경에서 한 것과 같은 작업을 반복하는 것이고, 가장 나쁜 경우는 새로운 버그를 발견하거나 만들어내는 것입니다.

문제가 발견되면 운영팀은 문제 해결을 위한 프로세스에 따라 개발팀을 불러 들입니다. 여기서 운영팀은 개발팀이 잘못된 코드를 줬다고 주장하고, 개발팀은 테스트에서 문제없었던 것이므로 운영팀이 뭔가 잘못 설정한 것이라고 주장합니다. 어디서건 문제가 발생할 수 있는 곳은 많은 것이 사실입니다. 문제의 원인은 발견하지도 못했는데, 시간은 자꾸 지나가고, 그렇다고 원래의 안정된 상태로 되돌릴 확실한 방법도 없습니다. 이후의 이야기는 바로 ‘느린 IT’란 결론으로 이어지는 슬픈 이야기입니다.

이런 문제는 처음 변경사항을 배치할 때만 발생하는 것은 아닙니다. 데브옵스의 필요성을 극명하게 보여주는 경우이긴 하지만, 실제로 데브옵스는 이런 배치가 이뤄지기 이전부터, 그리고 이뤄지고 난 이후 오랫동안 필요한 것입니다.

어떤 방식으로든지 데브옵스가 구현되면 그 이점은 확연하게 드러날 것입니다. 앞서 예를 든 최악의 경우는 발생하지 않을 것이고, IT는 민첩하게 변화에 대응할 수 있으니까 말이죠. 특히 민첩성의 관점에서 데브옵스는 애자일 개발 방법론이 실제로 기업 차원에서 100% 성과를 올리기 위한 요소로 평가되기도 합니다. 민첩한 개발은 민첩한 운영없이는 반쪽의 성과 밖에 얻을 수 없기 때문입니다.

데브옵스는 다소 넓은 의미를 가지는 개념이기 때문에 이를 실제로 구현하는 방법에 대해서는 다양한 접근이 가능합니다. 일각에서는 별도의 데브옵스팀이 필요하다고 보기도 하고, 한편에서는 이 방법이 또 다른 팀을 만드는 일이라고 평가하기도 합니다.

어떤 방식으로든 데브옵스가 실현되기 위해서는 개발팀과 운영팀 양쪽에 기술적 제도적 변화가 필요한 것이 사실입니다. 이런 변화의 조건으로는 조직 문화의 변화를 위한 평가 및 보상, 통합된 프로세스, 그리고 통합된 툴이 제시되고 있습니다. 특히 개발과 운영에 대한 기존 평가 방식을 그대로 유지하는 구조로는 데브옵스의 이상을 구현하기 어렵다는 것이 전문가들의 공통된 지적입니다.  editor@itworld.co.kr


2013.12.12

ITWorld 용어 풀이 | 데브옵스(DevOps)

박재곤 기자 | ITWorld
데브옵스는 개발(Development)와 운영(Operation)을 합친 말로, 개발과 운영 간의 상호 작용을 원활하게 하는 모든 것을 의미하는 포괄적인 개념입니다. 그렇다고 개발과 운영을 동시에 수행한다는 말은 아닙니다.

IT 관리 관점에서 개발과 운영은 당연히 다른 업무이면서 상호 연결되는 것이 분명합니다. 개발팀이 현업에서 필요로 하는 요구사항을 수용해 애플리케이션을 개발하듯, 운영팀은 개발팀에서 만들어 낸 애플리케이션을 IT 인프라 상에서 운영해야 하기 때문입니다.

각자의 역할이 분명한 이 두 팀 간의 상호 작용에 중점을 둔 데브옵스가 부상하게 된 것은 개발과 운영 간에는 커다란 관점의 차이가 있고, 이러한 차이가 효율적인 IT 운영을 심각하게 저해하기 때문입니다.

변경이라는 한 가지 요소만 놓고 생각해 봐도 차이는 분명해집니다. 개발팀은 변경이 자신의 가치를 증명하는 것이라고 생각합니다. 새로운 것을 계속 만들어내지 않으면 개발팀은 존재의 의미가 없어집니다. 하지만 운영팀에게 변경은 적 그 자체입니다. 변경은 운영팀의 지상과제인 안정적인 운영을 방해하는 요소이기 때문입니다.

게다가 이 두 팀의 이런 관점은 독립적으로 볼 때 옳은 것입니다. 여기에다 기업의 규모에 따라 두 팀은 전혀 다른 조직 구조에서 서로 다른 부서장 아래 있는 경우가 많고, 심한 경우 지리적으로도 따로 떨어져 있습니다.

과연 어떤 문제가 발생하는지 예를 들어 보겠습니다. 개발팀에서 애플리케이션에 새로운 기능을 추가하거나 기존 기능을 수정하는 이른바 ‘변경’을 가해 실제 운영 중인 시스템에 적용하기 위해 운영팀으로 넘겨 줍니다. 운영팀은 이를 받아 실제 배치를 위한 준비를 합니다. 배치를 위한 스크립트도 짜고 실제 운영 환경에 맞게 환경설정 파일도 편집합니다.

가장 좋은 경우는 운영팀이 이전 환경에서 한 것과 같은 작업을 반복하는 것이고, 가장 나쁜 경우는 새로운 버그를 발견하거나 만들어내는 것입니다.

문제가 발견되면 운영팀은 문제 해결을 위한 프로세스에 따라 개발팀을 불러 들입니다. 여기서 운영팀은 개발팀이 잘못된 코드를 줬다고 주장하고, 개발팀은 테스트에서 문제없었던 것이므로 운영팀이 뭔가 잘못 설정한 것이라고 주장합니다. 어디서건 문제가 발생할 수 있는 곳은 많은 것이 사실입니다. 문제의 원인은 발견하지도 못했는데, 시간은 자꾸 지나가고, 그렇다고 원래의 안정된 상태로 되돌릴 확실한 방법도 없습니다. 이후의 이야기는 바로 ‘느린 IT’란 결론으로 이어지는 슬픈 이야기입니다.

이런 문제는 처음 변경사항을 배치할 때만 발생하는 것은 아닙니다. 데브옵스의 필요성을 극명하게 보여주는 경우이긴 하지만, 실제로 데브옵스는 이런 배치가 이뤄지기 이전부터, 그리고 이뤄지고 난 이후 오랫동안 필요한 것입니다.

어떤 방식으로든지 데브옵스가 구현되면 그 이점은 확연하게 드러날 것입니다. 앞서 예를 든 최악의 경우는 발생하지 않을 것이고, IT는 민첩하게 변화에 대응할 수 있으니까 말이죠. 특히 민첩성의 관점에서 데브옵스는 애자일 개발 방법론이 실제로 기업 차원에서 100% 성과를 올리기 위한 요소로 평가되기도 합니다. 민첩한 개발은 민첩한 운영없이는 반쪽의 성과 밖에 얻을 수 없기 때문입니다.

데브옵스는 다소 넓은 의미를 가지는 개념이기 때문에 이를 실제로 구현하는 방법에 대해서는 다양한 접근이 가능합니다. 일각에서는 별도의 데브옵스팀이 필요하다고 보기도 하고, 한편에서는 이 방법이 또 다른 팀을 만드는 일이라고 평가하기도 합니다.

어떤 방식으로든 데브옵스가 실현되기 위해서는 개발팀과 운영팀 양쪽에 기술적 제도적 변화가 필요한 것이 사실입니다. 이런 변화의 조건으로는 조직 문화의 변화를 위한 평가 및 보상, 통합된 프로세스, 그리고 통합된 툴이 제시되고 있습니다. 특히 개발과 운영에 대한 기존 평가 방식을 그대로 유지하는 구조로는 데브옵스의 이상을 구현하기 어렵다는 것이 전문가들의 공통된 지적입니다.  editor@itworld.co.kr


X