.jpg)
.jpg)
30일 안에 회사 전체를 바꿀 수는 없지만 좋은 시작점이 될 수는 있어
간단한 데브옵스 툴과 팀원 소통 툴 알아보는 것부터 시작
[보안뉴스 문가용 기자] “데브옵스” 체제를 1주일 만에 구축하라는 임무가 떨어진다면 당신의 반응은 어떨까? 그런데 실제로 이에 준하는 명령들이 IT 담당자들에게 떨어지고 있는 게 사실이다. “데브옵스 혹은 애자일 체제의 장점인 유연함을 인지하기 시작한 기업들이 늘어나고 있기 때문”이라고 컨설팅 업체인 엑센추어 테크놀로지(Accenture Technology)의 클라우드 전략 담당자인 미하 크랄리(Miha Kralj)는 설명한다.
IT 서비스 관리 업체인 넥시언트(Nexient)의 수석 디렉터 네이트 베렌트스필슨(Nate Berent-Spillson)은 “30일이면 기초적인 데브옵스 파이프라인을 마련하기에 충분하다”고 말한다. “리포지터리에서 코드를 꺼내오는 것에서부터, 그 코드를 컴파일링하고, 실험하고, 구축하는 과정을 자동화 하는 것부터 시작해야 합니다. 그 단계가 완료되면 관계자들에게 전부 알려야 하겠지요.”
조직들이 빠르게 데브옵스를 구축하려는 데에는 여러 가지 이유가 있을 수 있다. “새로운 제품의 런칭을 앞당기거나, 요즘 시대에 소비자들로부터 요구되는 각종 ‘개발 관련 요구 사항들’을 충족시키려면 데브옵스가 반드시 필요하다고 느껴서일 수도 있습니다.” 기술 컨설팅 업체인 프라임 TSR(Prime TSR)의 운영 책임자인 팀 스톤(Tim Stone)의 설명이다. “뿐만 아니라 어떤 제품이나 서비스와 관련된 여러 정보와 지식을 갖추고 있는 핵심 인재를 놓치지 않기 위해서 체질 개선이 필요하다고 판단하는 경우도 많습니다.”
그래서 ‘디지털 변혁(digital transformation)’을 계획하고 있거나 이미 진행 중인 기업들이 빠르게 늘어나고 있다. 하지만 이게 절대 하루아침에 이뤄지는 것도 아니고, 쉽게 결정할 사안은 더더욱 아니라고 크랄리는 강조한다. “데브옵스를 도입하면 디지털 변혁을 가속화시킬 수 있습니다. 빠르게 변하는 시장의 상황에 유연하게 대처할 수 있고, 새로운 사업의 기회도 만들 수 있고요. 즉, 데브옵스를 빠르게 도입하면 할수록 그로 인한 이득을 더 풍성하게 누릴 가능성이 높아진다는 겁니다. 그 이득이라는 건 처음에는 IT 관련 부서들이 누리게 될 것이고, 서서히 사업 운영 팀들로도 번질 겁니다.”
1단계
빠르게 데브옵스를 구축해야 할 때 가장 먼저 해야 할 일은 즉시 사용 가능한 데브옵스 툴을 찾아내는 것이다. “대단히 많은 돈을 투자할 필요는 없습니다. 현재 가지고 있는 거, 혹은 쉽게 구할 수 있는 것부터 최대한 반복해서 써보세요. 그러다보면 자연스럽게 더 향상되어야 할 부분이 눈에 띌 겁니다.” 스톤의 제안이다.
“그 다음으로는 코드 체크인 및 체크아웃 과정을 구축해야 합니다. 코드를 가져다가 재활용할 때의 절차를 만들라는 것입니다. 구축과 배포의 파이프라인도 단순화시키고, 다양한 옵션과 도착지를 수동으로 변경시켜서 적용해야 합니다. 이 과정을 진행할 때의 핵심은 시작을 최대한 간단하게 하는 겁니다. 처음부터 바다 전체를 끓일 수는 없어요.”
베렌트스필슨은 조달 과정에서의 문제가 복잡해지는 걸 막기 위해 젠킨스(Jenkins)나 팀시티(Team City)와 같은 소프트웨어를 기반으로 한 기본 오픈소스 툴체인을 사용할 것을 권장한다. “자동 코드 테스트 과정에 코드 커버리지(code-coverage)라는 항목 넣는 것을 잊지 말아야 합니다. 이러한 수치들은 데브옵스 개발 과정에서 매우 중요한 지표가 됩니다.”
팀 구성원을 잘 선택하는 것 역시 초기 단계에서 중요한 문제다. 어쩌면 장기적 관점에서는 가장 핵심적인 문제일 수도 있다. 보험 회사인 리버티 뮤추얼(Liberty Mutual)에서 데브옵스 플랫폼을 총괄하는 데이비드 에링어(David Ehringer)는 “여태까지 지켜본 바로는, 가장 빠르고 확실하게 데브옵스로의 변환을 마친 조직들은, 구성원들 모두가 데브옵스에 대한 문화와 마인드를 잘 받아들인 곳”이라고 말한다. “속도만 빠른 게 아니라 안정적이기도 하더군요.”
그러면서 에링어는 “시간 압박을 받고 있는 데브옵스 팀이라면, 다양한 기능을 아울러야 한다”고 강조한다. “한 가지에만 특화되어 있어서는 데브옵스를 길게 가져갈 수 없게 됩니다. 여러 기능을 가진 구성원을 모아놓은 후에는 팀 전체의 목적을 한 사람 한 사람이 이해할 수 있고, 이를 바탕으로 파이프라인 혹은 환경의 처음과 끝을 전부 파악할 수 있을 만한 환경을 제공해야 합니다. 그리고 데브옵스 과정과 관련된 모든 사람들로부터 공감을 이끌어낼 수 있어야 합니다. 결국 데브옵스를 구성하는 과정에서 사람과 사람의 신뢰를 놓치지 않는 게 핵심이라는 겁니다.”
이는 어떤 식으로 접근 및 해결해야 할까? “데브옵스로의 변환이 진행되는 과정 중 중요한 지점들을 지날 때마다 구성원들에게 상세히 설명하고, 큰 목표를 이해시키고, 그 큰 목표라는 맥락 안에서 변경점이 갖는 의미를 알려주는 것이 신뢰 구축에 가장 효과적입니다. 체질 개선이라는 것의 성공을 어떻게 정의할 것인지, 이를 사람들에게 어떻게 이해시킬 것인지, 어떤 식으로 성공 여부를 측정할 것인지, 이를 직관적으로 노출시키려면 어떻게 해야 하는지 미리 생각해두는 것이 좋습니다.”
필요에 초점을 맞추다
조직이 촉박하게 데브옵스의 도입을 요구하고 있다면, 사장이 매우 즉흥적인 기분파이거나 그럴 만한 이유가 있어서일 것이다. 오라클(Oracle)의 오라클 클라우드(Oracle Cloud) 부문 부회장인 밥 킬린(Bob Quillin)은 “시작부터 계획을 크게 잡고 시작하는 건 촉박한 시간 속에서 데브옵스를 진행해야 할 경우, 어울리지 않는다”고 강조한다.
“회사가 30일을 요구했다면, 어떤 필요를 급하게 충족시켜야 하니까 그런 겁니다. 그 필요가 무엇인지 파악하고, 그 특정 필요에 맞춰서 데브옵스 환경을 구축해야 합니다. 이렇게 작게 시작하면, 가다가 잘못되더라도 어디서 잘못되었는지, 실수가 어디서 발생했는지도 금방 파악이 가능합니다.”
킬린은 “팀원들 간 아이디어 공유와 협업이 원활할 수 있도록 통신 채널을 만드는 것을 추천한다”고 말한다. “저는 개인적으로 슬랙(Slack)을 사용했을 때 많은 도움을 받았던 기억이 있습니다. 하지만 슬랙 말고도 비슷한 앱들이 많이 존재하니 취향과 필요에 따라 알아볼 수 있을 겁니다.”
베렌트스필슨은 “30일이 지나고 어느 정도 기본적인 파이프라인이 다 갖춰진 후에는 종과 호루라기를 덧붙이기 시작해야 한다”고 말한다. “급한 불을 껐으니 그 다음 해결할 문제들을 적용해보는 것이죠. 데이터베이스 버저닝 문제, 자동화 적용의 확장, API 실험, 자동 보안 스캔 등이 있을 수 있습니다.” 그런 다음 그는 “30일이면 생각보다 많은 일을 이뤄낼 수 있다”고 강조한다. “그렇다고 데브옵스를 전체 조직에 적용할 수는 없겠지만요. 충실한 시작을 하기에 30일은 짧은 시간이 아닙니다.”
스톤은 “데브옵스를 빠르게 적용하라는 건 대부분 상황에서 무리한 요구가 맞고, 그렇게 구축된 데브옵스는 수명이 길지도 않다”고 말한다. “정말 특별한 상황에서만 진행되어야 합니다. 하지만 큰 욕심과 야망을 버린다면, 데브옵스 혹은 애자일로의 체질 개선에 있어서 좋은 계기가 될 수도 있습니다.”
글 : 존 에드워즈(John Edwards)
[국제부 문가용 기자(globoan@boannews.com)]
간단한 데브옵스 툴과 팀원 소통 툴 알아보는 것부터 시작
[보안뉴스 문가용 기자] “데브옵스” 체제를 1주일 만에 구축하라는 임무가 떨어진다면 당신의 반응은 어떨까? 그런데 실제로 이에 준하는 명령들이 IT 담당자들에게 떨어지고 있는 게 사실이다. “데브옵스 혹은 애자일 체제의 장점인 유연함을 인지하기 시작한 기업들이 늘어나고 있기 때문”이라고 컨설팅 업체인 엑센추어 테크놀로지(Accenture Technology)의 클라우드 전략 담당자인 미하 크랄리(Miha Kralj)는 설명한다.
[이미지 = iclickart]
IT 서비스 관리 업체인 넥시언트(Nexient)의 수석 디렉터 네이트 베렌트스필슨(Nate Berent-Spillson)은 “30일이면 기초적인 데브옵스 파이프라인을 마련하기에 충분하다”고 말한다. “리포지터리에서 코드를 꺼내오는 것에서부터, 그 코드를 컴파일링하고, 실험하고, 구축하는 과정을 자동화 하는 것부터 시작해야 합니다. 그 단계가 완료되면 관계자들에게 전부 알려야 하겠지요.”
조직들이 빠르게 데브옵스를 구축하려는 데에는 여러 가지 이유가 있을 수 있다. “새로운 제품의 런칭을 앞당기거나, 요즘 시대에 소비자들로부터 요구되는 각종 ‘개발 관련 요구 사항들’을 충족시키려면 데브옵스가 반드시 필요하다고 느껴서일 수도 있습니다.” 기술 컨설팅 업체인 프라임 TSR(Prime TSR)의 운영 책임자인 팀 스톤(Tim Stone)의 설명이다. “뿐만 아니라 어떤 제품이나 서비스와 관련된 여러 정보와 지식을 갖추고 있는 핵심 인재를 놓치지 않기 위해서 체질 개선이 필요하다고 판단하는 경우도 많습니다.”
그래서 ‘디지털 변혁(digital transformation)’을 계획하고 있거나 이미 진행 중인 기업들이 빠르게 늘어나고 있다. 하지만 이게 절대 하루아침에 이뤄지는 것도 아니고, 쉽게 결정할 사안은 더더욱 아니라고 크랄리는 강조한다. “데브옵스를 도입하면 디지털 변혁을 가속화시킬 수 있습니다. 빠르게 변하는 시장의 상황에 유연하게 대처할 수 있고, 새로운 사업의 기회도 만들 수 있고요. 즉, 데브옵스를 빠르게 도입하면 할수록 그로 인한 이득을 더 풍성하게 누릴 가능성이 높아진다는 겁니다. 그 이득이라는 건 처음에는 IT 관련 부서들이 누리게 될 것이고, 서서히 사업 운영 팀들로도 번질 겁니다.”
1단계
빠르게 데브옵스를 구축해야 할 때 가장 먼저 해야 할 일은 즉시 사용 가능한 데브옵스 툴을 찾아내는 것이다. “대단히 많은 돈을 투자할 필요는 없습니다. 현재 가지고 있는 거, 혹은 쉽게 구할 수 있는 것부터 최대한 반복해서 써보세요. 그러다보면 자연스럽게 더 향상되어야 할 부분이 눈에 띌 겁니다.” 스톤의 제안이다.
“그 다음으로는 코드 체크인 및 체크아웃 과정을 구축해야 합니다. 코드를 가져다가 재활용할 때의 절차를 만들라는 것입니다. 구축과 배포의 파이프라인도 단순화시키고, 다양한 옵션과 도착지를 수동으로 변경시켜서 적용해야 합니다. 이 과정을 진행할 때의 핵심은 시작을 최대한 간단하게 하는 겁니다. 처음부터 바다 전체를 끓일 수는 없어요.”
베렌트스필슨은 조달 과정에서의 문제가 복잡해지는 걸 막기 위해 젠킨스(Jenkins)나 팀시티(Team City)와 같은 소프트웨어를 기반으로 한 기본 오픈소스 툴체인을 사용할 것을 권장한다. “자동 코드 테스트 과정에 코드 커버리지(code-coverage)라는 항목 넣는 것을 잊지 말아야 합니다. 이러한 수치들은 데브옵스 개발 과정에서 매우 중요한 지표가 됩니다.”
팀 구성원을 잘 선택하는 것 역시 초기 단계에서 중요한 문제다. 어쩌면 장기적 관점에서는 가장 핵심적인 문제일 수도 있다. 보험 회사인 리버티 뮤추얼(Liberty Mutual)에서 데브옵스 플랫폼을 총괄하는 데이비드 에링어(David Ehringer)는 “여태까지 지켜본 바로는, 가장 빠르고 확실하게 데브옵스로의 변환을 마친 조직들은, 구성원들 모두가 데브옵스에 대한 문화와 마인드를 잘 받아들인 곳”이라고 말한다. “속도만 빠른 게 아니라 안정적이기도 하더군요.”
그러면서 에링어는 “시간 압박을 받고 있는 데브옵스 팀이라면, 다양한 기능을 아울러야 한다”고 강조한다. “한 가지에만 특화되어 있어서는 데브옵스를 길게 가져갈 수 없게 됩니다. 여러 기능을 가진 구성원을 모아놓은 후에는 팀 전체의 목적을 한 사람 한 사람이 이해할 수 있고, 이를 바탕으로 파이프라인 혹은 환경의 처음과 끝을 전부 파악할 수 있을 만한 환경을 제공해야 합니다. 그리고 데브옵스 과정과 관련된 모든 사람들로부터 공감을 이끌어낼 수 있어야 합니다. 결국 데브옵스를 구성하는 과정에서 사람과 사람의 신뢰를 놓치지 않는 게 핵심이라는 겁니다.”
이는 어떤 식으로 접근 및 해결해야 할까? “데브옵스로의 변환이 진행되는 과정 중 중요한 지점들을 지날 때마다 구성원들에게 상세히 설명하고, 큰 목표를 이해시키고, 그 큰 목표라는 맥락 안에서 변경점이 갖는 의미를 알려주는 것이 신뢰 구축에 가장 효과적입니다. 체질 개선이라는 것의 성공을 어떻게 정의할 것인지, 이를 사람들에게 어떻게 이해시킬 것인지, 어떤 식으로 성공 여부를 측정할 것인지, 이를 직관적으로 노출시키려면 어떻게 해야 하는지 미리 생각해두는 것이 좋습니다.”
필요에 초점을 맞추다
조직이 촉박하게 데브옵스의 도입을 요구하고 있다면, 사장이 매우 즉흥적인 기분파이거나 그럴 만한 이유가 있어서일 것이다. 오라클(Oracle)의 오라클 클라우드(Oracle Cloud) 부문 부회장인 밥 킬린(Bob Quillin)은 “시작부터 계획을 크게 잡고 시작하는 건 촉박한 시간 속에서 데브옵스를 진행해야 할 경우, 어울리지 않는다”고 강조한다.
“회사가 30일을 요구했다면, 어떤 필요를 급하게 충족시켜야 하니까 그런 겁니다. 그 필요가 무엇인지 파악하고, 그 특정 필요에 맞춰서 데브옵스 환경을 구축해야 합니다. 이렇게 작게 시작하면, 가다가 잘못되더라도 어디서 잘못되었는지, 실수가 어디서 발생했는지도 금방 파악이 가능합니다.”
킬린은 “팀원들 간 아이디어 공유와 협업이 원활할 수 있도록 통신 채널을 만드는 것을 추천한다”고 말한다. “저는 개인적으로 슬랙(Slack)을 사용했을 때 많은 도움을 받았던 기억이 있습니다. 하지만 슬랙 말고도 비슷한 앱들이 많이 존재하니 취향과 필요에 따라 알아볼 수 있을 겁니다.”
베렌트스필슨은 “30일이 지나고 어느 정도 기본적인 파이프라인이 다 갖춰진 후에는 종과 호루라기를 덧붙이기 시작해야 한다”고 말한다. “급한 불을 껐으니 그 다음 해결할 문제들을 적용해보는 것이죠. 데이터베이스 버저닝 문제, 자동화 적용의 확장, API 실험, 자동 보안 스캔 등이 있을 수 있습니다.” 그런 다음 그는 “30일이면 생각보다 많은 일을 이뤄낼 수 있다”고 강조한다. “그렇다고 데브옵스를 전체 조직에 적용할 수는 없겠지만요. 충실한 시작을 하기에 30일은 짧은 시간이 아닙니다.”
스톤은 “데브옵스를 빠르게 적용하라는 건 대부분 상황에서 무리한 요구가 맞고, 그렇게 구축된 데브옵스는 수명이 길지도 않다”고 말한다. “정말 특별한 상황에서만 진행되어야 합니다. 하지만 큰 욕심과 야망을 버린다면, 데브옵스 혹은 애자일로의 체질 개선에 있어서 좋은 계기가 될 수도 있습니다.”
글 : 존 에드워즈(John Edwards)
[국제부 문가용 기자(globoan@boannews.com)]
Copyrighted 2015. UBM-Tech. 117153:0515BC
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-11-22] 
.jpg)
.jpg)
.jpg)
.jpg)
