.jpg)
.jpg)
데브옵스는 속도와 질 모두 잡는 방법...속도만 중시해선 안 돼
자동화 기술, 반드시 필요해...전사적인 문화 변신 전제되어야
[보안뉴스 문가용 기자] 현재 IT 세계의 가장 큰 변화 두 가지를 꼽으라면 ‘클라우드’와 ‘데브옵스’다. 클라우드 관리 업체인 라이트스케일(RightScale)이 최근 발표한 보고서에 의하면 대기업의 84%와 중소기업의 72%가 데브옵스 환경을 기업 내 구축했다고 한다. 이들이 데브옵스를 이처럼 빠르게 받아들이는 이유는 데브옵스가 제공하는 유연성, 고객 만족도, 직원 사기 향상, 생산력 증가 등의 긍정적인 효과를 기대하기 때문이다.
.jpg)
하지만 데브옵스를 시작한다고 해서 이런 효과들이 하늘에서부터 마구 쏟아지는 건 아니다. 도입하려면 잘 해야 한다. 보안 전문업체인 CA 테크놀로지스는 최근 “애자일과 데브옵스로 속도와 고객 가치 높이기”라는 보고서를 통해, 데브옵스 구축을 성공적으로 한 기업은 비용을 26% 절감하고 사업은 37% 성장시켰으며 앱의 질은 33% 높였다고 발표한 바 있다. 하지만 이러한 결과는 ‘잘 구축한’ 기업들에게만 허락된 것이다. 다음은 데브옵스를 성급히 도입했을 때 흔히들 하는 실수들이다.
1. 질보다 속도를 중시한다
솔직히 ‘데브옵스’를 부랴부랴 도입하려는 기업 운영자들의 마음 속은 온통 ‘속도’뿐이다. 데브옵스라는 게 있다며? 출시 속도가 더 빨라진다며? 하지만 세상 모든 일이 다 그렇듯, 속도에만 집중하면 질은 반드시 떨어지게 되어 있다. 앱 개발 전문가들 역시 ‘속도만을 위주로 한 개발 문화는 적폐 대상’이라고 입을 모은다. 버그 투성이 앱을 빠르게 출시해봤자, 시장에서 좋은 평가 듣지 못한다는 단순한 원리를 윗분들은 왜 그리 모르시는지.
데브옵스는 질과 속도의 균형을 잡기 위한 개발 원리이지 속도를 바짝 올려주는 프로세스는 아니다. 그렇기 때문에 데브옵스에 투입된 개발 팀은 초기 단계서부터 여러 가지 시험을 해보는 것이 정석이다. 이렇게 개발 초기 단계에서부터 시행되는 시험 과정을 ‘시프팅 테스트(shifting test)’라고 부른다. 하지만 리서치 업체인 다이멘셔널리서치(Dimensional Research)에서 조사한 바에 따르면 시프팅 테스트를 하는 업체가 19%도 되지 않은 것으로 나타났다.
2. 코드 활용을 자주하지 않는다
속도만 위주로 해 문제가 되는 업체가 있는 반면 속도조차 제대로 올리지 못하는 업체들도 있다. 소프트웨어 개발 업체인 퍼펫(Puppet)이 발표한 자료에 따르면 “데브옵스를 잘 활용하는 팀들은 하루에도 여러 번 코드를 사용(deploy)하는 반면, 데브옵스의 장점을 발휘하지 못하는 팀들은 새로운 코드를 한 달에 한 번이나 1년에 몇 번 사용할 뿐”이라고 한다. 숫자를 살펴보면 잘 하는 팀은 한 해 평균 1460회 코드를 활용하고, 그렇지 않은 팀은 평균 7회에 그쳤다.
3. 실험 단계에 언제까지나 머무른다
데브옵스를 도입할 때 대부분의 전문가들은 ‘작게 시작하라’고 조언한다. 그리고 실제로 많은 기업들이 이 조언을 따른다. 라이트스케일의 보고서에 따르면 데브옵스를 도입한 조직의 30%만이 전사적인 데브옵스 환경 마련에 성공했다고 하며, 사업 운영 조직에만 28%, 특정 프로젝트나 팀에만 도입한 조직이 27%나 되었다고 한다. 또 다른 업체인 소스랩스(Sauce Labs)에서 비슷한 주제로 진행한 설문에서는 “전사적인 도입”을 한 곳이 10%에 불과했다.
‘작게 시작하라’는 말이 ‘데브옵스는 원래 작게 도입해야 한다’는 말로 해석되고 있는 곳이 생각보다 많다는 수치다. CA 테크놀로지스에서 실시한 조사에 의하면 “데브옵스 성숙도가 높은 곳이 1/3”이라고 하는데, “그렇기 때문에 데브옵스로 바꿔서 오히려 비용이 높아지고 성장률이 떨어지는 경험을 한 곳이 2/3 정도 된다”고 해석이 가능하다. 실험 기간을 너무 오래 지속하는 건 ‘성숙’의 측면을 간과하고 있다는 뜻이다.
4. 문화적인 변신 시도가 이뤄지지 않는다
데브옵스 전문가들은 데브옵스에 맞게 사람과 문화를 바꾸는 게 가장 어려운 일이라는 데에 동의한다. CA 테크놀로지스의 보고서에 의하면 “설문 응답자의 34%가 조직 문화가 변화를 수용하기에 너무 경직되어 있다고 답했으며, 28%가 관리급 임원들이 변화에 대한 이해를 하지 못하고 있다고 답했다”고 한다. 여기서 말하는 변화는 당연히 데브옵스를 말한다. 데브옵스가 ‘작업 방식’에만 국한된 개념이 아니라는 걸 임원급부터 이해하고, 이를 각 부서 팀장이나 관리자들에게 전파해 도입시키는 것이 중요하다. 윗사람의 지시만으로 이뤄지는 성격의 것이 아니라는 뜻이다.
5. 훈련이나 경험 없이 무조건 앞으로 앞으로
4번과 연결되어 있는 부분으로, IT 담당자들이라면 데브옵스를 자동으로 할 줄 안다고 생각하는 경우가 많다. 아무리 IT 전문가라도 데브옵스라는 공정이 생소할 수 있다. 이들에게도 훈련과 경험이 필요하다. 2016년에 발간된 ‘SDxCentral 클라우드 자동화 및 데브옵스 보고서’에 의하면 데브옵스 관련 툴을 사용하지 않는 기업 중 68%가 ‘사용할 줄 아는 사람이 없어서’라고 답했다고 한다. CA 테크놀로지스의 보고서에도 비슷한 항목이 있다. 32%가 “조직 내에 데브옵스 관련 전문가가 부족해 제대로 된 데브옵스 도입이 이뤄지지 않고 있다”고 답한 것이다.
6. 자동화의 부족
역사상 최악의 데브옵스 실패로 꼽힐만한 사건 하나를 소개한다. 세계적인 금융업체인 나이트캐피탈(Knight Capital)의 IT 담당자 한 사람이 여덟 개 서버에 새로운 거래 소프트웨어를 배포했다. 7개 서버에서는 정상 작동이 확인되었으나, 이 담당자는 마지막 서버에서 설정을 살짝 잘못했다. 그러자 소프트웨어를 통해 통제 불가능한 거래가 일어나기 시작했고, 결국 회사는 4400억 원의 손실을 입었다. 이 때문에 회사 주가까지 폭락했다.
이 사건이 주는 교훈은 무엇일까? 데브옵스를 통해 소프트웨어를 배포할 때, 자동화를 적극 활용해야 한다는 것이다. 데브옵스는 꾸준한 코드 활용과 배포를 전제로 한 공정이다. 이걸 일일이 사람이 하는 건 ‘구멍’을 어디선가 내겠다는 것과 다름이 없다. 모든 반복 작업이 이뤄지는 곳에서 되도록 자동화를 사용해 ‘인간적인 실수’를 막는 것이 데브옵스의 핵심이다.
7. 기존 툴로는 새로운 일을 할 수 없다
CA 테크놀로지스의 보고서에 의하면 36%의 응답자가 “데브옵스 제대로 하려면 제대로 된 툴이 필요하다”고 답했다고 한다. 35%는 “제대로 된 데브옵스 툴 구하는 게 어렵다”고 답하기도 했다. 지속적인 배포를 가능하게 해주는 툴이나 독커(Docker) 있다고 데브옵스를 위한 준비가 다 되었다고 볼 수는 없다는 게 전문가들의 의견이다. 게다가 데브옵스를 위해서 필요한 툴이 공식처럼 정해진 것도 아니라는 점도 문제를 더 복잡하게 한다. 데브옵스를 도입하려는 목적, 기업이 진행하는 사업의 성격 등에 따라 필요한 툴은 각양각색으로 나눠진다.
8. 너무 자잘하게 조직을 나눈다
데브옵스 및 애자일에 대한 가장 큰 ‘오해’는 ‘중앙관리 없이 개별적으로 코드를 만든다’ 혹은 ‘마스터 코드 없이 유닛화된 코드들을 모아서 뭔가를 만든다’는 것이다. 그래서 자유를 너무 과하게 부여하거나, 너무 조직을 잘게 쪼개서 뭉쳐놓기가 어렵게 된다. 전통의 ‘워터폴(waterfall)’ 방식에 익숙한 개발자들에게 갑자기 180도 다른 환경을 강제하면, 쉽게 적응하기가 힘들다. 조직이나 코드의 모듈화에 적응할 시간을 줘야 한다. 클라우드도 현재 ‘하이브리드 형태’가 가장 널리 사용되고 있듯이 데브옵스도 처음부터 개별화와 모듈화에만 집중해서는 안 된다.
9. 보안은 무시한다
최근 몇 년 동안 여러 시행착오를 통해 발견된 바, 데브옵스에서 가장 큰 어려움 중 하나는 보안이다. CA 테크놀로지스의 보고서에는 데브옵스의 가장 큰 장애물로 보안이 꼽혔다(38%). 퍼펫의 연구 보고서에서는 데스옵스가 잘 도입된 조직은 그렇지 않은 조직에 비해 보안 문제 해결하는 데에 시간을 적게 투자한다고 나왔다. 무슨 말이냐면, 데브옵스가 잘 정착된 곳은 개발 과정 중에 보안 문제를 해결하는 법을 익혔고, 그렇지 않은 곳은 여전히 보안을 무시하고 있다는 것이다.
[국제부 문가용 기자(globoan@boannews.com)]
자동화 기술, 반드시 필요해...전사적인 문화 변신 전제되어야
[보안뉴스 문가용 기자] 현재 IT 세계의 가장 큰 변화 두 가지를 꼽으라면 ‘클라우드’와 ‘데브옵스’다. 클라우드 관리 업체인 라이트스케일(RightScale)이 최근 발표한 보고서에 의하면 대기업의 84%와 중소기업의 72%가 데브옵스 환경을 기업 내 구축했다고 한다. 이들이 데브옵스를 이처럼 빠르게 받아들이는 이유는 데브옵스가 제공하는 유연성, 고객 만족도, 직원 사기 향상, 생산력 증가 등의 긍정적인 효과를 기대하기 때문이다.
▲ 옜다, 데브옵스![ⓒ iclickart]
하지만 데브옵스를 시작한다고 해서 이런 효과들이 하늘에서부터 마구 쏟아지는 건 아니다. 도입하려면 잘 해야 한다. 보안 전문업체인 CA 테크놀로지스는 최근 “애자일과 데브옵스로 속도와 고객 가치 높이기”라는 보고서를 통해, 데브옵스 구축을 성공적으로 한 기업은 비용을 26% 절감하고 사업은 37% 성장시켰으며 앱의 질은 33% 높였다고 발표한 바 있다. 하지만 이러한 결과는 ‘잘 구축한’ 기업들에게만 허락된 것이다. 다음은 데브옵스를 성급히 도입했을 때 흔히들 하는 실수들이다.
1. 질보다 속도를 중시한다
솔직히 ‘데브옵스’를 부랴부랴 도입하려는 기업 운영자들의 마음 속은 온통 ‘속도’뿐이다. 데브옵스라는 게 있다며? 출시 속도가 더 빨라진다며? 하지만 세상 모든 일이 다 그렇듯, 속도에만 집중하면 질은 반드시 떨어지게 되어 있다. 앱 개발 전문가들 역시 ‘속도만을 위주로 한 개발 문화는 적폐 대상’이라고 입을 모은다. 버그 투성이 앱을 빠르게 출시해봤자, 시장에서 좋은 평가 듣지 못한다는 단순한 원리를 윗분들은 왜 그리 모르시는지.
데브옵스는 질과 속도의 균형을 잡기 위한 개발 원리이지 속도를 바짝 올려주는 프로세스는 아니다. 그렇기 때문에 데브옵스에 투입된 개발 팀은 초기 단계서부터 여러 가지 시험을 해보는 것이 정석이다. 이렇게 개발 초기 단계에서부터 시행되는 시험 과정을 ‘시프팅 테스트(shifting test)’라고 부른다. 하지만 리서치 업체인 다이멘셔널리서치(Dimensional Research)에서 조사한 바에 따르면 시프팅 테스트를 하는 업체가 19%도 되지 않은 것으로 나타났다.
2. 코드 활용을 자주하지 않는다
속도만 위주로 해 문제가 되는 업체가 있는 반면 속도조차 제대로 올리지 못하는 업체들도 있다. 소프트웨어 개발 업체인 퍼펫(Puppet)이 발표한 자료에 따르면 “데브옵스를 잘 활용하는 팀들은 하루에도 여러 번 코드를 사용(deploy)하는 반면, 데브옵스의 장점을 발휘하지 못하는 팀들은 새로운 코드를 한 달에 한 번이나 1년에 몇 번 사용할 뿐”이라고 한다. 숫자를 살펴보면 잘 하는 팀은 한 해 평균 1460회 코드를 활용하고, 그렇지 않은 팀은 평균 7회에 그쳤다.
3. 실험 단계에 언제까지나 머무른다
데브옵스를 도입할 때 대부분의 전문가들은 ‘작게 시작하라’고 조언한다. 그리고 실제로 많은 기업들이 이 조언을 따른다. 라이트스케일의 보고서에 따르면 데브옵스를 도입한 조직의 30%만이 전사적인 데브옵스 환경 마련에 성공했다고 하며, 사업 운영 조직에만 28%, 특정 프로젝트나 팀에만 도입한 조직이 27%나 되었다고 한다. 또 다른 업체인 소스랩스(Sauce Labs)에서 비슷한 주제로 진행한 설문에서는 “전사적인 도입”을 한 곳이 10%에 불과했다.
‘작게 시작하라’는 말이 ‘데브옵스는 원래 작게 도입해야 한다’는 말로 해석되고 있는 곳이 생각보다 많다는 수치다. CA 테크놀로지스에서 실시한 조사에 의하면 “데브옵스 성숙도가 높은 곳이 1/3”이라고 하는데, “그렇기 때문에 데브옵스로 바꿔서 오히려 비용이 높아지고 성장률이 떨어지는 경험을 한 곳이 2/3 정도 된다”고 해석이 가능하다. 실험 기간을 너무 오래 지속하는 건 ‘성숙’의 측면을 간과하고 있다는 뜻이다.
4. 문화적인 변신 시도가 이뤄지지 않는다
데브옵스 전문가들은 데브옵스에 맞게 사람과 문화를 바꾸는 게 가장 어려운 일이라는 데에 동의한다. CA 테크놀로지스의 보고서에 의하면 “설문 응답자의 34%가 조직 문화가 변화를 수용하기에 너무 경직되어 있다고 답했으며, 28%가 관리급 임원들이 변화에 대한 이해를 하지 못하고 있다고 답했다”고 한다. 여기서 말하는 변화는 당연히 데브옵스를 말한다. 데브옵스가 ‘작업 방식’에만 국한된 개념이 아니라는 걸 임원급부터 이해하고, 이를 각 부서 팀장이나 관리자들에게 전파해 도입시키는 것이 중요하다. 윗사람의 지시만으로 이뤄지는 성격의 것이 아니라는 뜻이다.
5. 훈련이나 경험 없이 무조건 앞으로 앞으로
4번과 연결되어 있는 부분으로, IT 담당자들이라면 데브옵스를 자동으로 할 줄 안다고 생각하는 경우가 많다. 아무리 IT 전문가라도 데브옵스라는 공정이 생소할 수 있다. 이들에게도 훈련과 경험이 필요하다. 2016년에 발간된 ‘SDxCentral 클라우드 자동화 및 데브옵스 보고서’에 의하면 데브옵스 관련 툴을 사용하지 않는 기업 중 68%가 ‘사용할 줄 아는 사람이 없어서’라고 답했다고 한다. CA 테크놀로지스의 보고서에도 비슷한 항목이 있다. 32%가 “조직 내에 데브옵스 관련 전문가가 부족해 제대로 된 데브옵스 도입이 이뤄지지 않고 있다”고 답한 것이다.
6. 자동화의 부족
역사상 최악의 데브옵스 실패로 꼽힐만한 사건 하나를 소개한다. 세계적인 금융업체인 나이트캐피탈(Knight Capital)의 IT 담당자 한 사람이 여덟 개 서버에 새로운 거래 소프트웨어를 배포했다. 7개 서버에서는 정상 작동이 확인되었으나, 이 담당자는 마지막 서버에서 설정을 살짝 잘못했다. 그러자 소프트웨어를 통해 통제 불가능한 거래가 일어나기 시작했고, 결국 회사는 4400억 원의 손실을 입었다. 이 때문에 회사 주가까지 폭락했다.
이 사건이 주는 교훈은 무엇일까? 데브옵스를 통해 소프트웨어를 배포할 때, 자동화를 적극 활용해야 한다는 것이다. 데브옵스는 꾸준한 코드 활용과 배포를 전제로 한 공정이다. 이걸 일일이 사람이 하는 건 ‘구멍’을 어디선가 내겠다는 것과 다름이 없다. 모든 반복 작업이 이뤄지는 곳에서 되도록 자동화를 사용해 ‘인간적인 실수’를 막는 것이 데브옵스의 핵심이다.
7. 기존 툴로는 새로운 일을 할 수 없다
CA 테크놀로지스의 보고서에 의하면 36%의 응답자가 “데브옵스 제대로 하려면 제대로 된 툴이 필요하다”고 답했다고 한다. 35%는 “제대로 된 데브옵스 툴 구하는 게 어렵다”고 답하기도 했다. 지속적인 배포를 가능하게 해주는 툴이나 독커(Docker) 있다고 데브옵스를 위한 준비가 다 되었다고 볼 수는 없다는 게 전문가들의 의견이다. 게다가 데브옵스를 위해서 필요한 툴이 공식처럼 정해진 것도 아니라는 점도 문제를 더 복잡하게 한다. 데브옵스를 도입하려는 목적, 기업이 진행하는 사업의 성격 등에 따라 필요한 툴은 각양각색으로 나눠진다.
8. 너무 자잘하게 조직을 나눈다
데브옵스 및 애자일에 대한 가장 큰 ‘오해’는 ‘중앙관리 없이 개별적으로 코드를 만든다’ 혹은 ‘마스터 코드 없이 유닛화된 코드들을 모아서 뭔가를 만든다’는 것이다. 그래서 자유를 너무 과하게 부여하거나, 너무 조직을 잘게 쪼개서 뭉쳐놓기가 어렵게 된다. 전통의 ‘워터폴(waterfall)’ 방식에 익숙한 개발자들에게 갑자기 180도 다른 환경을 강제하면, 쉽게 적응하기가 힘들다. 조직이나 코드의 모듈화에 적응할 시간을 줘야 한다. 클라우드도 현재 ‘하이브리드 형태’가 가장 널리 사용되고 있듯이 데브옵스도 처음부터 개별화와 모듈화에만 집중해서는 안 된다.
9. 보안은 무시한다
최근 몇 년 동안 여러 시행착오를 통해 발견된 바, 데브옵스에서 가장 큰 어려움 중 하나는 보안이다. CA 테크놀로지스의 보고서에는 데브옵스의 가장 큰 장애물로 보안이 꼽혔다(38%). 퍼펫의 연구 보고서에서는 데스옵스가 잘 도입된 조직은 그렇지 않은 조직에 비해 보안 문제 해결하는 데에 시간을 적게 투자한다고 나왔다. 무슨 말이냐면, 데브옵스가 잘 정착된 곳은 개발 과정 중에 보안 문제를 해결하는 법을 익혔고, 그렇지 않은 곳은 여전히 보안을 무시하고 있다는 것이다.
[국제부 문가용 기자(globoan@boannews.com)]
Copyrighted 2015. UBM-Tech. 117153:0515BC
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-11-22] 
.jpg)
.jpg)
.jpg)
.jpg)
