Offcanvas

��������� ������

'ROI를 입증할 때' 애자일과 데브옵스가 비용을 절감하는 8가지 방식

복잡한 워크플로우의 수렁에 빠져 비용 절감에 애를 먹고 있다면, 애자일과 데브옵스가 다음과 같은 방식으로 도울 수 있다는 점을 기억할 만하다.   애자일(Agile) 방법론과 데브옵스(DevOps)가 좋다는 건 기술 리더라면 이제 누구나 안다. 아무도 명령 및 통제 타임라인과 수동 인프라 운영으로 점철돼 실패로 끝난 프로젝트가 가득했던 시절로 돌아가고 싶어 하지 않는다.  동시에 이러한 역량이 성숙해져 그만한 가치를 창출하려면 많은 시간과 노력을 투입해야 한다는 점도 모르지 않는다. 언젠가 임원진이 투자 대비 효과에 관해 물어볼 수도 있다.  서비스형 소프트웨어(SaaS) 제공업체라면 제품 개선, 신규 고객 유입, 그리고 매출 증가를 도모하고자 애자일과 데브옵스를 도입한다. 사용자 경험을 개선하고, 사용자 만족도를 높이며 출시 주기를 앞당길 수 있다는 기대에 애자일과 데브옵스에 투자한다.  하지만 일반 기업의 IT 부서는 애자일과 데브옵스의 비용 절감 효과도 입증해야 한다. 물론 아직 전 세계적 경기 침체 여부나 IT 예산의 방향성은 불명확하다. 그러나 IT 리더는 항상 최악의 상황에 대비해야 하므로 애자일과 데브옵스가 효율성을 높이고 비용을 줄이는 방식에 대해 알고 있어야 한다. 다음은 그 7가지 방식이다.    1. 최소기능제품(Minimum Viable Product, MVP)이 개발 기간을 단축시킨다  코파도(Copado)의 책임자 앤드류 데이비스는 애자일과 데브옵스가 해결하고자 하는 2가지 근본적인 목표를 공유하며 ‘모든 것을 측정하는 방법(How to Measure Anything)’이라는 책의 내용을 인용했다. 저자 더글라스 허버드는 광범위한 연구에서 어떤 요소가 프로젝트의 총 ROI에 가장 큰 영향을 미치는지 분석했다. ROI를 일정하게 예측한 2가지 요소는 프로젝트가 실행되기 전에 취소되었는지와 사용자들이 얼마나 빨리 유입됐는지였다.  비용을...

애자일 데브옵스 경기침체 비용절감 ROI 의사결정 지속적 전달 테스팅 자동화

2022.11.09

복잡한 워크플로우의 수렁에 빠져 비용 절감에 애를 먹고 있다면, 애자일과 데브옵스가 다음과 같은 방식으로 도울 수 있다는 점을 기억할 만하다.   애자일(Agile) 방법론과 데브옵스(DevOps)가 좋다는 건 기술 리더라면 이제 누구나 안다. 아무도 명령 및 통제 타임라인과 수동 인프라 운영으로 점철돼 실패로 끝난 프로젝트가 가득했던 시절로 돌아가고 싶어 하지 않는다.  동시에 이러한 역량이 성숙해져 그만한 가치를 창출하려면 많은 시간과 노력을 투입해야 한다는 점도 모르지 않는다. 언젠가 임원진이 투자 대비 효과에 관해 물어볼 수도 있다.  서비스형 소프트웨어(SaaS) 제공업체라면 제품 개선, 신규 고객 유입, 그리고 매출 증가를 도모하고자 애자일과 데브옵스를 도입한다. 사용자 경험을 개선하고, 사용자 만족도를 높이며 출시 주기를 앞당길 수 있다는 기대에 애자일과 데브옵스에 투자한다.  하지만 일반 기업의 IT 부서는 애자일과 데브옵스의 비용 절감 효과도 입증해야 한다. 물론 아직 전 세계적 경기 침체 여부나 IT 예산의 방향성은 불명확하다. 그러나 IT 리더는 항상 최악의 상황에 대비해야 하므로 애자일과 데브옵스가 효율성을 높이고 비용을 줄이는 방식에 대해 알고 있어야 한다. 다음은 그 7가지 방식이다.    1. 최소기능제품(Minimum Viable Product, MVP)이 개발 기간을 단축시킨다  코파도(Copado)의 책임자 앤드류 데이비스는 애자일과 데브옵스가 해결하고자 하는 2가지 근본적인 목표를 공유하며 ‘모든 것을 측정하는 방법(How to Measure Anything)’이라는 책의 내용을 인용했다. 저자 더글라스 허버드는 광범위한 연구에서 어떤 요소가 프로젝트의 총 ROI에 가장 큰 영향을 미치는지 분석했다. ROI를 일정하게 예측한 2가지 요소는 프로젝트가 실행되기 전에 취소되었는지와 사용자들이 얼마나 빨리 유입됐는지였다.  비용을...

2022.11.09

지속적 전달·통합은 구름과 찰떡궁합··· 클라우드 CI/CD 플랫폼 안내서

클라우드에 CI/CD 서비스를 호스팅하면 개발 파이프라인과 소스 코드 리포지토리 사이의 상호작용 속도를 높일 수 있다. 개발자들의 편의성도 개선의 여지를 가진다. 이미 시중에는 다양한 옵션이 등장해 있다.    소프트웨어 개발 및 생산 프로세스를 빠르게 하고자 한다면, 최소한 테스트 및 전달 프로세스의 일부를 자동화해야 한다. 이를 위해서는 CI/CD 파이프라인을 도입해야 할 가능성이 높다. 오류를 잡아내기 위한 테스트 스위트도 필요할 수 있다.  지속적 통합(Continuous integration)의 약자인 CI는 소프트웨어 개발, 패키지화, 테스트를 일관된 방식으로 자동화하기 위한 방법론이다. CI는 팀에 소스 코드 버전 관리 시 확인하는 변경사항이 빌드를 망가뜨리거나 소프트웨어에 버그를 유입시키지 않을 것이라는 자신감을 갖는 데 도움이 된다. CI의 종점은 일반적으로 소프트웨어 저장소의 메인 브랜치(Main Branch)에 대해 완료된 체크인(Check-in)이다. 지속적 전달(Continuous delivery )의 약자인 CD는 인프라 환경에 대한 테스트된 소프트웨어의 전달을 자동화한다. 일반적으로 고객이 평가를 확인하기 위해 생산에 직접 투입하는 것을 의미하지는 않는다. 일반적으로 조직은 빌드를 개발 환경에 넣으면서 CD를 시작한다. 개발자가 새로운 빌드를 완성하고 공개한 후, 일반적으로 테스트 환경으로 가서 더욱 광범위한 사용자(때로는 점당 내부 테스터, 베타 테스트에 자원한 더 큰 사용자 그룹, ‘도그 푸딩(Dog-fooding)’)들이 사용하면서 긴밀하게 모니터링한다. 마지막으로, 모든 것이 잘 되면 테스터가 승인하고 새 버전을 생산 환경에 투입한다. 각 CD 단계에는 구빌드로 신속하게 되돌리고 개발자가 새 빌드에서 해결할 수 있도록 버그 보고 티켓을 생성하는 옵션이 있다. 목표는 많은 빌드를 생산에 투입하는 것이 아니라 퇴보를 유발하지 않으면서 소프트웨어를 지속적으로 개선하는 것이다. 이 활동을 흔히 ‘...

지속적 전달 지속적 통합 클라우드 CI 클라우드 CD 애자일

2022.10.26

클라우드에 CI/CD 서비스를 호스팅하면 개발 파이프라인과 소스 코드 리포지토리 사이의 상호작용 속도를 높일 수 있다. 개발자들의 편의성도 개선의 여지를 가진다. 이미 시중에는 다양한 옵션이 등장해 있다.    소프트웨어 개발 및 생산 프로세스를 빠르게 하고자 한다면, 최소한 테스트 및 전달 프로세스의 일부를 자동화해야 한다. 이를 위해서는 CI/CD 파이프라인을 도입해야 할 가능성이 높다. 오류를 잡아내기 위한 테스트 스위트도 필요할 수 있다.  지속적 통합(Continuous integration)의 약자인 CI는 소프트웨어 개발, 패키지화, 테스트를 일관된 방식으로 자동화하기 위한 방법론이다. CI는 팀에 소스 코드 버전 관리 시 확인하는 변경사항이 빌드를 망가뜨리거나 소프트웨어에 버그를 유입시키지 않을 것이라는 자신감을 갖는 데 도움이 된다. CI의 종점은 일반적으로 소프트웨어 저장소의 메인 브랜치(Main Branch)에 대해 완료된 체크인(Check-in)이다. 지속적 전달(Continuous delivery )의 약자인 CD는 인프라 환경에 대한 테스트된 소프트웨어의 전달을 자동화한다. 일반적으로 고객이 평가를 확인하기 위해 생산에 직접 투입하는 것을 의미하지는 않는다. 일반적으로 조직은 빌드를 개발 환경에 넣으면서 CD를 시작한다. 개발자가 새로운 빌드를 완성하고 공개한 후, 일반적으로 테스트 환경으로 가서 더욱 광범위한 사용자(때로는 점당 내부 테스터, 베타 테스트에 자원한 더 큰 사용자 그룹, ‘도그 푸딩(Dog-fooding)’)들이 사용하면서 긴밀하게 모니터링한다. 마지막으로, 모든 것이 잘 되면 테스터가 승인하고 새 버전을 생산 환경에 투입한다. 각 CD 단계에는 구빌드로 신속하게 되돌리고 개발자가 새 빌드에서 해결할 수 있도록 버그 보고 티켓을 생성하는 옵션이 있다. 목표는 많은 빌드를 생산에 투입하는 것이 아니라 퇴보를 유발하지 않으면서 소프트웨어를 지속적으로 개선하는 것이다. 이 활동을 흔히 ‘...

2022.10.26

기고 | 이상적인 ‘데브옵스’ 풍경을 그려본다면?

모든 데스옵스 시나리오에 적용할 수 있는 만능해답 같은 것은 없다. 하지만 이상적인 개발 과정과 툴체인을 묘사할 수는 있겠다. 여기 데브옵스의 각 조각이 어떻게 어울리고 조합될 수 있는지 살펴본다.  데브옵스(Devops) 접근법는 개발 및 운영 활동을 아우르는 종합적인 관점을 취하고, 이들이 가장 효율적으로 상호작용할 수 있도록 조율한다. 하지만 이는 개념적 이상일 뿐이다. 기술적 관점에서 이상적인 데브옵스 풍경이란 무엇일까? 답은 ‘서술할 수 없다’이다. 신생 기업의 요구와 수백 명이 관여하면서 마이크로서비스 프로젝트를 시작하는 다국적 기업의 요구는 전혀 다르기 때문이다.  그러나 증가하는 복잡성을 적절하게 흡수할 수 있는 이상적인 개발 흐름을 서술할 수는 있다. 또 아울러 CI/CD(지속적 통합/지속적 전달), 도커, 클라우드 컴퓨팅 같은 기술을 이 흐름에 접목하는 방식을 설명해볼 수 있다.    개발 : ‘내부의 고리’  한 개발자가 있다고 하자. 그는 소프트웨어를 당연히 수정할 것이고, 수정이 만족스럽다면 이를 버전 컨트롤로 커밋할 것이다. 버전 컨트롤은 소프트웨어 개발의 ‘내부 고리’와 데브옵스의 ‘외부 고리’ 사이의 접합 지점이다.  개발자 커밋은 개발 브랜치, 기능 브랜치, 또는 (비공식적 환경에서) 메인 브랜치로 이어질 수 있다. 이상적으로는 자동화된 유닛 테스트의 실행이 있을 것이다. 이는 다양한 방식으로 일어날 수 있다. 프리-커밋 후크, 커밋 후크 등 선택지는 무한하다. 어쨌든 유닛 테스트를 통과하지 못하면 코드 변경은 브랜치로 수용되지 않는다.  자동화된 테스팅  일단 코드 변경이 수용되면 다음 단계는 ‘통합 테스트’다. 이는 지속적 통합(CI)에서 필수적이다. 다시 말해 코드는 계속적으로 더 큰 시스템에 통합되고 실행 환경에서 자동 및 수동 테스팅을 위해 전개된다. 자동화된 테스팅에는 한계가 없다. 모든 것이 가능하다. 셀레늄 스타일의 자동화된 UI ...

데브옵스 젠킨스 지속적 통합 지속적 전달 지속적 테스트 도커 컨테이너

2021.07.19

모든 데스옵스 시나리오에 적용할 수 있는 만능해답 같은 것은 없다. 하지만 이상적인 개발 과정과 툴체인을 묘사할 수는 있겠다. 여기 데브옵스의 각 조각이 어떻게 어울리고 조합될 수 있는지 살펴본다.  데브옵스(Devops) 접근법는 개발 및 운영 활동을 아우르는 종합적인 관점을 취하고, 이들이 가장 효율적으로 상호작용할 수 있도록 조율한다. 하지만 이는 개념적 이상일 뿐이다. 기술적 관점에서 이상적인 데브옵스 풍경이란 무엇일까? 답은 ‘서술할 수 없다’이다. 신생 기업의 요구와 수백 명이 관여하면서 마이크로서비스 프로젝트를 시작하는 다국적 기업의 요구는 전혀 다르기 때문이다.  그러나 증가하는 복잡성을 적절하게 흡수할 수 있는 이상적인 개발 흐름을 서술할 수는 있다. 또 아울러 CI/CD(지속적 통합/지속적 전달), 도커, 클라우드 컴퓨팅 같은 기술을 이 흐름에 접목하는 방식을 설명해볼 수 있다.    개발 : ‘내부의 고리’  한 개발자가 있다고 하자. 그는 소프트웨어를 당연히 수정할 것이고, 수정이 만족스럽다면 이를 버전 컨트롤로 커밋할 것이다. 버전 컨트롤은 소프트웨어 개발의 ‘내부 고리’와 데브옵스의 ‘외부 고리’ 사이의 접합 지점이다.  개발자 커밋은 개발 브랜치, 기능 브랜치, 또는 (비공식적 환경에서) 메인 브랜치로 이어질 수 있다. 이상적으로는 자동화된 유닛 테스트의 실행이 있을 것이다. 이는 다양한 방식으로 일어날 수 있다. 프리-커밋 후크, 커밋 후크 등 선택지는 무한하다. 어쨌든 유닛 테스트를 통과하지 못하면 코드 변경은 브랜치로 수용되지 않는다.  자동화된 테스팅  일단 코드 변경이 수용되면 다음 단계는 ‘통합 테스트’다. 이는 지속적 통합(CI)에서 필수적이다. 다시 말해 코드는 계속적으로 더 큰 시스템에 통합되고 실행 환경에서 자동 및 수동 테스팅을 위해 전개된다. 자동화된 테스팅에는 한계가 없다. 모든 것이 가능하다. 셀레늄 스타일의 자동화된 UI ...

2021.07.19

내년에도 75%는 기대 이하?··· 우리가 데브옵스에 실패하는 이유

애플리케이션 및 서비스를 신속하게 제공하길 원하는 IT 리더들이 데브옵스로 뛰어들고 있다. 하지만 개발과 운영을 결합한 일은 생각보다 까다로운 작업이다.  프로젝트 규모와 상관없이 IT에 데브옵스를 통합하기 시작한 조직이 많다. 데브옵스(DevOps)는 신속한 애플리케이션 및 기능 딜리버리, 개발팀과 운영팀 간의 커뮤니케이션 및 협업 개선, 문제 해결 시간 단축, 반복적인 IT 서비스 딜리버리 등 다양한 이점을 제공하지만 반드시 성공이 보장되는 건 아니다.    가트너는 “데브옵스가 빠르게 주류로 자리 잡고 있지만 문화, 자동화, 플랫폼 설계에 관해 상대적으로 새로운 이 접근방식이 어떻게 약속한 것을 제공할 수 있는지 불확실하다”라면서, 많은 조직이 여전히 데브옵스 관행을 구축하고 확장하는 데 어려움을 겪고 있다고 말했다. 심지어 오는 2022년까지 무려 75%의 데브옵스 이니셔티브가 조직 차원의 교육 및 변화와 관련된 문제로 기대치를 충족하지 못할 것이라고 가트너는 예상했다.  데브옵스 이니셔티브에서 피해야 할 보편적인 함정은 다음과 같다.  1. 필요한 역량의 부재 기술적 역량 격차는 IT의 모든 측면에 영향을 미칠 수 있으며 데브옵스도 예외는 아니다. 데브옵스의 개발팀 또는 운영팀 구성원이 이에 필요한 기술 역량을 갖추지 못한다면 데브옵스의 이점을 얻으려는 시도는 실패할 가능성이 크다.  美 콘텐츠 서비스 업체 하이랜드(Hyland)의 수석 부사장 겸 CIO 샘 바빅은 “팀원들이 하드 스킬과 소프트 스킬을 모두 갖추는 게 중요하다”라고 언급했다.  그에 따르면 하이랜드는 여러 비즈니스 부문에 데브옵스와 자동화를 적용하고 있다. 바빅은 “회계, 재무, 영업, 마케팅 등 비즈니스 부문의 운영 관련 요구사항을 충족하기 위해 IT 조직 내에서 이 관행을 활용하고 있다”라면서, “또 하이랜드는 데브옵스를 사용하여 다양한 채널을 통해 고객에게 제공되는 소프트웨어 제품도 개발한다”라고 설명했다...

데브옵스 기술 격차 자동화 지속적 전달 전문가 조직 변화 문화 소프트웨어 개발

2021.05.14

애플리케이션 및 서비스를 신속하게 제공하길 원하는 IT 리더들이 데브옵스로 뛰어들고 있다. 하지만 개발과 운영을 결합한 일은 생각보다 까다로운 작업이다.  프로젝트 규모와 상관없이 IT에 데브옵스를 통합하기 시작한 조직이 많다. 데브옵스(DevOps)는 신속한 애플리케이션 및 기능 딜리버리, 개발팀과 운영팀 간의 커뮤니케이션 및 협업 개선, 문제 해결 시간 단축, 반복적인 IT 서비스 딜리버리 등 다양한 이점을 제공하지만 반드시 성공이 보장되는 건 아니다.    가트너는 “데브옵스가 빠르게 주류로 자리 잡고 있지만 문화, 자동화, 플랫폼 설계에 관해 상대적으로 새로운 이 접근방식이 어떻게 약속한 것을 제공할 수 있는지 불확실하다”라면서, 많은 조직이 여전히 데브옵스 관행을 구축하고 확장하는 데 어려움을 겪고 있다고 말했다. 심지어 오는 2022년까지 무려 75%의 데브옵스 이니셔티브가 조직 차원의 교육 및 변화와 관련된 문제로 기대치를 충족하지 못할 것이라고 가트너는 예상했다.  데브옵스 이니셔티브에서 피해야 할 보편적인 함정은 다음과 같다.  1. 필요한 역량의 부재 기술적 역량 격차는 IT의 모든 측면에 영향을 미칠 수 있으며 데브옵스도 예외는 아니다. 데브옵스의 개발팀 또는 운영팀 구성원이 이에 필요한 기술 역량을 갖추지 못한다면 데브옵스의 이점을 얻으려는 시도는 실패할 가능성이 크다.  美 콘텐츠 서비스 업체 하이랜드(Hyland)의 수석 부사장 겸 CIO 샘 바빅은 “팀원들이 하드 스킬과 소프트 스킬을 모두 갖추는 게 중요하다”라고 언급했다.  그에 따르면 하이랜드는 여러 비즈니스 부문에 데브옵스와 자동화를 적용하고 있다. 바빅은 “회계, 재무, 영업, 마케팅 등 비즈니스 부문의 운영 관련 요구사항을 충족하기 위해 IT 조직 내에서 이 관행을 활용하고 있다”라면서, “또 하이랜드는 데브옵스를 사용하여 다양한 채널을 통해 고객에게 제공되는 소프트웨어 제품도 개발한다”라고 설명했다...

2021.05.14

데브섹옵스란? 기업이 관심 가질 이유는?

데브섹옵스는 그저 하나의 트렌드가 아니다. 기업이 이를 근간부터 진지하게 고민해야 할 이유를 살펴본다. 꽤 축약된 용어인 '데브옵스(DevOps)'에 알파벳 3개가 더 붙은 것이 불편하겠지만 '데브섹옵스(Devsecops)'는 데브옵스 마인드셋에 있어 논리적이고 필수적인 연장선이다. 데브옵스는 조직 내의 '사일로'를 파괴하여 개발자와 운영팀이 협력하고 가능할 때마다 자동화를 활용할 수 있도록 하는 과정을 개괄적으로 정의한 것이다. 그 목적은 더욱 개선되고 안정적인 소프트웨어를 신속하게 공개하는 것이며, 그 과정에 처음부터 보안을 적용하는 것은 당연한 수순이다. 보안에 특수한 전문가가 필요한 경우가 많다. 이로 인해 데브옵스 전략에서 이런 인재들이 사전 공개 또는 심지어 공개 후 단계까지도 배제되는 위험이 종종 발생한다. 그 결과는 다소 짜증나는 것부터 잠재적으로 비극적인 것까지 다양하다. 레드햇의 수석 보안 아키텍트 마이크 버셀에 따르면 데브섹옵스의 진정한 핵심은 처음부터 데브옵스를 제대로 도입하는 것이다. 그는 "데브옵스를 실행하지만 그 과정의 핵심에 보안을 적용하지 않으면 데브옵스를 적절히 수행하는 것이 아니다. 그렇다고 해서 보안이 모든 것을 주물러야 한다는 뜻은 아니다. 왜냐하면 그렇게 되면 모든 것이 마비되기 때문이다. 데브옵스 사이클에 보안이 포함되도록 설계하면 된다. 그것이 데브섹옵스다"라고 말했다. 버셀은 이어 툴, 프로세스, 문화를 융합하는 것이 훌륭한 데브섹옵스 접근 방식이라고 말했다. "보안 전문가를 참여시키고 팀에 합류시키며 다양한 지식 영역을 프로세스에 적용하도록 하면 모두가 그들의 전문 지식을 이용할 수 있는 방식으로 데브옵스 모델의 보안을 자동화할 수 있다"라고 그는 덧붙였다. 시놉시스(Synopsys)의 수석 컨설턴트 미어라 라오는 버설의 의견에 동의하면서, 오늘날 많은 조직들이 툴 도입을 애자일 또는 데브옵스...

애자일 데브옵스 지속적 전달 지속적 통합 데브섹옵스

2018.08.21

데브섹옵스는 그저 하나의 트렌드가 아니다. 기업이 이를 근간부터 진지하게 고민해야 할 이유를 살펴본다. 꽤 축약된 용어인 '데브옵스(DevOps)'에 알파벳 3개가 더 붙은 것이 불편하겠지만 '데브섹옵스(Devsecops)'는 데브옵스 마인드셋에 있어 논리적이고 필수적인 연장선이다. 데브옵스는 조직 내의 '사일로'를 파괴하여 개발자와 운영팀이 협력하고 가능할 때마다 자동화를 활용할 수 있도록 하는 과정을 개괄적으로 정의한 것이다. 그 목적은 더욱 개선되고 안정적인 소프트웨어를 신속하게 공개하는 것이며, 그 과정에 처음부터 보안을 적용하는 것은 당연한 수순이다. 보안에 특수한 전문가가 필요한 경우가 많다. 이로 인해 데브옵스 전략에서 이런 인재들이 사전 공개 또는 심지어 공개 후 단계까지도 배제되는 위험이 종종 발생한다. 그 결과는 다소 짜증나는 것부터 잠재적으로 비극적인 것까지 다양하다. 레드햇의 수석 보안 아키텍트 마이크 버셀에 따르면 데브섹옵스의 진정한 핵심은 처음부터 데브옵스를 제대로 도입하는 것이다. 그는 "데브옵스를 실행하지만 그 과정의 핵심에 보안을 적용하지 않으면 데브옵스를 적절히 수행하는 것이 아니다. 그렇다고 해서 보안이 모든 것을 주물러야 한다는 뜻은 아니다. 왜냐하면 그렇게 되면 모든 것이 마비되기 때문이다. 데브옵스 사이클에 보안이 포함되도록 설계하면 된다. 그것이 데브섹옵스다"라고 말했다. 버셀은 이어 툴, 프로세스, 문화를 융합하는 것이 훌륭한 데브섹옵스 접근 방식이라고 말했다. "보안 전문가를 참여시키고 팀에 합류시키며 다양한 지식 영역을 프로세스에 적용하도록 하면 모두가 그들의 전문 지식을 이용할 수 있는 방식으로 데브옵스 모델의 보안을 자동화할 수 있다"라고 그는 덧붙였다. 시놉시스(Synopsys)의 수석 컨설턴트 미어라 라오는 버설의 의견에 동의하면서, 오늘날 많은 조직들이 툴 도입을 애자일 또는 데브옵스...

2018.08.21

데브옵스 도입·활용은 이렇게··· 채택해야 할 접근법 5가지

많은 기술 조직이 이제 데브옵스를 중시하고 있다. 대개 상반되는 다음 두 가지 ‘임무'와 문화를 통합시키는 방안으로 간주한다 : - 애자일(Agile) 개발 팀은 빠른 속도로 비즈니스 요구사항을 충족하고, 애플리케이션을 변화시켜야 한다. - 반면 운영 팀은 시스템 성능을 유지시키고, 컴퓨팅 환경을 안전하게 보호하고, 컴퓨팅 리소스를 관리해야 한다. 애자일 팀은 운영 팀이 느리고 경직되어 있다고 생각한다. 반면 시스템 엔지니어는 애자일 개발자들이 운영과 관련된 필요사항을 지원하지 않고, 무모하게 행동해 애플리케이션 배포가 생산 환경에 문제를 발생시키도록 만든다고 생각한다. 일반적으로는 그럴 수 있다. 그러나 두 팀은 각각 ‘동기 부여 요소’, ‘개념’, ‘도구’가 다르다. 그리고 이런 ‘불일치’ 및 ‘부조화’가 비즈니스 문제를 초래할 수도 있다. 계속 규모가 커지는 신생 창업회사를 예로 들어보자. 개발 속도와 애질리티(민첩성)에 미치는 영향은 최소화 하면서 안정성을 보장해주는 운영 절차를 발전시켜야 한다. 대기업은 신뢰도를 낮추지 않고, 또는 규제를 준수하면서 더 빠르게 고객이 이용하는 애플리케이션과 내부 워크플로를 개선할 방법을 찾아야 한다. 데브옵스는 이런 문화적 ‘상충’, 운영 원칙들, 애플리케이션을 빠르게 배포하는 동시에 안정적으로 운영하고, 상충과 저하를 줄이는 새로운 베스트 프랙티스를 제시하는 데 목적을 두고 있다. 통상 운영 단계를 자동화하고, 구성을 표준화하는 프랙티스(실천법)를 제시하는 방법으로 문제를 극복하고, 목적을 달성한다. - 개발 팀의 경우, 코드 개발에서 테스트, 보안 적용, 여러 환경에서의 애플리케이션 운영과 관련된 단계들을 표준화 및 자동화하는 프랙티스들이다. - 그리고 운영 팀의 경우, 생산 환경의 문제를 더 빨리...

애자일 컨테이너 데브옵스 지속적 전달 마이크로서비스

2018.04.10

많은 기술 조직이 이제 데브옵스를 중시하고 있다. 대개 상반되는 다음 두 가지 ‘임무'와 문화를 통합시키는 방안으로 간주한다 : - 애자일(Agile) 개발 팀은 빠른 속도로 비즈니스 요구사항을 충족하고, 애플리케이션을 변화시켜야 한다. - 반면 운영 팀은 시스템 성능을 유지시키고, 컴퓨팅 환경을 안전하게 보호하고, 컴퓨팅 리소스를 관리해야 한다. 애자일 팀은 운영 팀이 느리고 경직되어 있다고 생각한다. 반면 시스템 엔지니어는 애자일 개발자들이 운영과 관련된 필요사항을 지원하지 않고, 무모하게 행동해 애플리케이션 배포가 생산 환경에 문제를 발생시키도록 만든다고 생각한다. 일반적으로는 그럴 수 있다. 그러나 두 팀은 각각 ‘동기 부여 요소’, ‘개념’, ‘도구’가 다르다. 그리고 이런 ‘불일치’ 및 ‘부조화’가 비즈니스 문제를 초래할 수도 있다. 계속 규모가 커지는 신생 창업회사를 예로 들어보자. 개발 속도와 애질리티(민첩성)에 미치는 영향은 최소화 하면서 안정성을 보장해주는 운영 절차를 발전시켜야 한다. 대기업은 신뢰도를 낮추지 않고, 또는 규제를 준수하면서 더 빠르게 고객이 이용하는 애플리케이션과 내부 워크플로를 개선할 방법을 찾아야 한다. 데브옵스는 이런 문화적 ‘상충’, 운영 원칙들, 애플리케이션을 빠르게 배포하는 동시에 안정적으로 운영하고, 상충과 저하를 줄이는 새로운 베스트 프랙티스를 제시하는 데 목적을 두고 있다. 통상 운영 단계를 자동화하고, 구성을 표준화하는 프랙티스(실천법)를 제시하는 방법으로 문제를 극복하고, 목적을 달성한다. - 개발 팀의 경우, 코드 개발에서 테스트, 보안 적용, 여러 환경에서의 애플리케이션 운영과 관련된 단계들을 표준화 및 자동화하는 프랙티스들이다. - 그리고 운영 팀의 경우, 생산 환경의 문제를 더 빨리...

2018.04.10

애자일 방법론의 가치를 극대화하는 방법

애자일 개발 프로세스를 진행하거나 참여 중인 사람이라면, 그리고 스크럼(scrum) 방법론과 같은 애자일 모델을 선택한 사람이라면 제품 오너와 고객 니즈, 그리고 여러 팀을 결과 산출에 맞춰 조정하기 위한 기본적인 프로세스를 갖추고 있다고 할 수 있다. 각 팀이 맡고 있는 책무를 뚜렷하게 정의하고, 미팅 스트럭처를 규정하고 일정을 정했으며, 백로그를 관리하기 위한 애자일 협업 툴을 갖춘 상태다. 이 모든 구조, 프로세스, 그리고 협업의 조합이 제대로 갖춰져 있다면 그 어떤 분야의 팀도 애자일 프랙티스를 수월하게 수행할 수 있다. 사실, 애자일 방법론은 애자일 마케팅 등 다양한 비 기술적 분야에도 적용되고 있다. 그렇다면 좋은 소프트웨어를 개발하는 데 있어서 애자일 프로세스만으로 충분할까? 그렇지 않다. 애자일 프로세스 외에도 테크놀로지가 뒷받침 된 일련의 규율이 존재해야만 애자일 방법론의 가치를 극대화 할 수 있다. 애자일의 가치를 극대화 한다는 것은 이 방법론을 통해 기업에서 만족할만한 성과를 거둔다는 의미다. 오늘 이 글에서 다룰 주제는 아래와 같다. - 애자일 협업 툴이 주요 소프트웨어 개발 라이프사이클(SDLC)을 확실히 지원하도록 하려면 어떤 기술적 문제들을 고려해야 하는가? - 애플리케이션이 제작 준비가 되었는지, 그리고 변경 내용을 제작 및 컴퓨팅 환경에 반영하기 위한 프로세스를 갖추고 있는지 소프트웨어 개발팀에서 어떻게 확인할 수 있는가? 애자일 개발 방법론의 기술적 부채 정의 및 해결 애자일 개발에서 사용자 시나리오를 구성하기 위해서는 많은 타협과 절충안에 도달해야만 한다. 특히 사용자 시나리오를 구성 시 기능적인 측면에서 타협이 많이 논의 되는데, 스토리 포인트를 예측하기 위해 애자일 추정(agile estimation)을 사용할 경우 더욱 그러하다. 사용자 시나리오가 끝나면, 이제 개발팀에서 그 이행에 대한 기술적 결정을 내릴 시간이다. 이러한 결정을 내릴...

애자일 QA 지속적 전달 스크럼 기술 부채 지속적 통합 SDLC 코드 브랜치

2017.12.22

애자일 개발 프로세스를 진행하거나 참여 중인 사람이라면, 그리고 스크럼(scrum) 방법론과 같은 애자일 모델을 선택한 사람이라면 제품 오너와 고객 니즈, 그리고 여러 팀을 결과 산출에 맞춰 조정하기 위한 기본적인 프로세스를 갖추고 있다고 할 수 있다. 각 팀이 맡고 있는 책무를 뚜렷하게 정의하고, 미팅 스트럭처를 규정하고 일정을 정했으며, 백로그를 관리하기 위한 애자일 협업 툴을 갖춘 상태다. 이 모든 구조, 프로세스, 그리고 협업의 조합이 제대로 갖춰져 있다면 그 어떤 분야의 팀도 애자일 프랙티스를 수월하게 수행할 수 있다. 사실, 애자일 방법론은 애자일 마케팅 등 다양한 비 기술적 분야에도 적용되고 있다. 그렇다면 좋은 소프트웨어를 개발하는 데 있어서 애자일 프로세스만으로 충분할까? 그렇지 않다. 애자일 프로세스 외에도 테크놀로지가 뒷받침 된 일련의 규율이 존재해야만 애자일 방법론의 가치를 극대화 할 수 있다. 애자일의 가치를 극대화 한다는 것은 이 방법론을 통해 기업에서 만족할만한 성과를 거둔다는 의미다. 오늘 이 글에서 다룰 주제는 아래와 같다. - 애자일 협업 툴이 주요 소프트웨어 개발 라이프사이클(SDLC)을 확실히 지원하도록 하려면 어떤 기술적 문제들을 고려해야 하는가? - 애플리케이션이 제작 준비가 되었는지, 그리고 변경 내용을 제작 및 컴퓨팅 환경에 반영하기 위한 프로세스를 갖추고 있는지 소프트웨어 개발팀에서 어떻게 확인할 수 있는가? 애자일 개발 방법론의 기술적 부채 정의 및 해결 애자일 개발에서 사용자 시나리오를 구성하기 위해서는 많은 타협과 절충안에 도달해야만 한다. 특히 사용자 시나리오를 구성 시 기능적인 측면에서 타협이 많이 논의 되는데, 스토리 포인트를 예측하기 위해 애자일 추정(agile estimation)을 사용할 경우 더욱 그러하다. 사용자 시나리오가 끝나면, 이제 개발팀에서 그 이행에 대한 기술적 결정을 내릴 시간이다. 이러한 결정을 내릴...

2017.12.22

이제는 '마이크로서비스'가 대세··· 이점은? 전제조건은?

2011년 그 개념이 처음 만들어진 마이크로서비스(Microservice)는 이내 미래지향적 애플리케이션 개발 기업과 조직 사이에서 반향을 불러 일으켰다. 그리고 단 몇 년이 지난 현재 어느덧 '주류'로 부상하고 있다. 엔진엑스(Nginix)의 최근 조사에 따르면, 36%의 기업들이 현재 마이크로서비스를 이용하고 있다. 뿐만 아니라 26%를 이의 활용을 조사하는 단계다. 그렇다면 마이크로서비스 아키텍처란 정확히 무엇일까? 내가 속한 조직의 문화, 스킬, 필요 사항에 부합할까? 애플리케이션 개발 프로젝트에 마이크로서비스를 고려해야 하는 7가지 이유, 성공하기 위해 필요한 5가지 전제조건을 알아봤다. 마이크로서비스의 이점 서비스 지향형 아키텍처(SOA)의 변종인 마이크로서비스는, 애플리케이션들을 느슨하게 연결된 서비스들로 해체할 수 있는 아키텍처를 의미한다. 세분화 된 서비스와 가벼운 프로토콜이 특징인 마이크로서비스는 높은 모듈성을 제공하고, 애플리케이션을 더 쉽게 개발, 테스트, 배포, (더 중요하게)변경 및 유지관리 할 수 있다. 십중팔구 현재 몸담고 있는 기업과 기관, 조직에는 전체 애플리케이션을 획일적 시대에 개발된 애플리케이션들이 많을 것이다. 하나의 코드베이스 위에 구현하기 위해 중앙화된 다계층 아키텍처를 사용했던 애플리케이션들 말이다. 이런 클라이언트-서비스 모델은 데스크톱이 IT를 지배했던 시절에는 탁월한 선택이었다. 그러나 모바일 장치와 클라우드가 증가 또는 부상하면서, 다양한 장치에서 상시 백엔드 데이터를 사용할 수 있도록 만들어야 한다. 그런데 획일적인 아키텍처는 여기에 도움을 주지 않는다. 변경을 할 때마다 전체 애플리케이션을 업데이트해야 하기 때문이다. 또 기능을 추가하거나 새롭게 조정을 하려 시도할 때마다 새로운 버그가 발생할 가능성이 있다. 더 큰 단점은 모든 것이 하나의 코드베이스에 묶여 있기 때문에 특정 기능이나 서비스를 확장할 수 없다는 것이다. 무조건 전체 ...

애자일 데브옵스 지속적 전달 마이크로서비스 서비스 지향형 아키텍처 증분형 개발

2017.06.22

2011년 그 개념이 처음 만들어진 마이크로서비스(Microservice)는 이내 미래지향적 애플리케이션 개발 기업과 조직 사이에서 반향을 불러 일으켰다. 그리고 단 몇 년이 지난 현재 어느덧 '주류'로 부상하고 있다. 엔진엑스(Nginix)의 최근 조사에 따르면, 36%의 기업들이 현재 마이크로서비스를 이용하고 있다. 뿐만 아니라 26%를 이의 활용을 조사하는 단계다. 그렇다면 마이크로서비스 아키텍처란 정확히 무엇일까? 내가 속한 조직의 문화, 스킬, 필요 사항에 부합할까? 애플리케이션 개발 프로젝트에 마이크로서비스를 고려해야 하는 7가지 이유, 성공하기 위해 필요한 5가지 전제조건을 알아봤다. 마이크로서비스의 이점 서비스 지향형 아키텍처(SOA)의 변종인 마이크로서비스는, 애플리케이션들을 느슨하게 연결된 서비스들로 해체할 수 있는 아키텍처를 의미한다. 세분화 된 서비스와 가벼운 프로토콜이 특징인 마이크로서비스는 높은 모듈성을 제공하고, 애플리케이션을 더 쉽게 개발, 테스트, 배포, (더 중요하게)변경 및 유지관리 할 수 있다. 십중팔구 현재 몸담고 있는 기업과 기관, 조직에는 전체 애플리케이션을 획일적 시대에 개발된 애플리케이션들이 많을 것이다. 하나의 코드베이스 위에 구현하기 위해 중앙화된 다계층 아키텍처를 사용했던 애플리케이션들 말이다. 이런 클라이언트-서비스 모델은 데스크톱이 IT를 지배했던 시절에는 탁월한 선택이었다. 그러나 모바일 장치와 클라우드가 증가 또는 부상하면서, 다양한 장치에서 상시 백엔드 데이터를 사용할 수 있도록 만들어야 한다. 그런데 획일적인 아키텍처는 여기에 도움을 주지 않는다. 변경을 할 때마다 전체 애플리케이션을 업데이트해야 하기 때문이다. 또 기능을 추가하거나 새롭게 조정을 하려 시도할 때마다 새로운 버그가 발생할 가능성이 있다. 더 큰 단점은 모든 것이 하나의 코드베이스에 묶여 있기 때문에 특정 기능이나 서비스를 확장할 수 없다는 것이다. 무조건 전체 ...

2017.06.22

마이크로소프트, 비주얼 스튜디오·애저에 '지속적 전달' 기능 추가

마이크로소프트가 비주얼 스튜디오 2017 IDE에 지속적 전달(continuous delivery) 기능을 추가한다. 새롭게 발표된 '비주얼 스튜디오 익스텐션용 컨티뉴어스 딜리버리 툴'를 이용하면 개발자들은 비주얼 스튜디오 팀 서비스 클라우드 ALM 플랫폼 상에서 자동화된 구축, 테스트, 배포 프로세스를 구축할 수 있게 된다. 이번 툴은 애저 앱 서비스 및 애저 컨테이너 서비스를 겨냥해 ASP.Net 4와 ALP.Net 코어 애플리케이션과 공조되도록 개발됐다. 개발자는 IDE 내 알림 기능을 통해 제품 파이프라인을 모니터링할 수 있다. 회사에 따르면 이번 툴이 등장한 목적은 개발자들이 데브옵스 파이파인을 자동화하고 최신성을 유지할 수 있도록 하기 위해서다. 개발자들은 비주얼 스튜디오 팀 서비스 대시보드의 빌드 실패 알림을 클릭함으로써 빌드 품질에 대한 정보 알림을 확인할 수 있게 된다. 마이크로소프트 비주얼 스튜디오 선임 프로그램 매니저 아미드 메트왈리는 "이번 익스텐션은 팀 서비스(Team Services) 상에서 빌드와 릴리즈 정의를 구축한다. 그리고 난 후 첫 빌드와 배치를 자동으로 출범시킨다. 이후 사용자가 리포지토리에 변화를 반영하면 팀 서비스는 새로운 빌드와 배치 작업에 착수하게 된다"라고 설명했다. 한편 현재 다운로드 가능한 해당 익스텐션 버전은 비주얼 스튜디오 2017 릴리즈 캔디데이트 3 이상의 버전과만 호환된다. 이 익스텐션이 인기 있는 젠킨스 CD/CI 플랫폼과 호환되는지를 묻는 질문에 마이크로소프트 블로그 게시판은 비주얼 스튜디오 팀 서비스가 요구된다고 게시돼 있다.  ciokr@idg.co.kr

마이크로소프트 애저 비주얼 스튜디오 지속적 전달 컨티뉴어스 딜리버리

2017.02.09

마이크로소프트가 비주얼 스튜디오 2017 IDE에 지속적 전달(continuous delivery) 기능을 추가한다. 새롭게 발표된 '비주얼 스튜디오 익스텐션용 컨티뉴어스 딜리버리 툴'를 이용하면 개발자들은 비주얼 스튜디오 팀 서비스 클라우드 ALM 플랫폼 상에서 자동화된 구축, 테스트, 배포 프로세스를 구축할 수 있게 된다. 이번 툴은 애저 앱 서비스 및 애저 컨테이너 서비스를 겨냥해 ASP.Net 4와 ALP.Net 코어 애플리케이션과 공조되도록 개발됐다. 개발자는 IDE 내 알림 기능을 통해 제품 파이프라인을 모니터링할 수 있다. 회사에 따르면 이번 툴이 등장한 목적은 개발자들이 데브옵스 파이파인을 자동화하고 최신성을 유지할 수 있도록 하기 위해서다. 개발자들은 비주얼 스튜디오 팀 서비스 대시보드의 빌드 실패 알림을 클릭함으로써 빌드 품질에 대한 정보 알림을 확인할 수 있게 된다. 마이크로소프트 비주얼 스튜디오 선임 프로그램 매니저 아미드 메트왈리는 "이번 익스텐션은 팀 서비스(Team Services) 상에서 빌드와 릴리즈 정의를 구축한다. 그리고 난 후 첫 빌드와 배치를 자동으로 출범시킨다. 이후 사용자가 리포지토리에 변화를 반영하면 팀 서비스는 새로운 빌드와 배치 작업에 착수하게 된다"라고 설명했다. 한편 현재 다운로드 가능한 해당 익스텐션 버전은 비주얼 스튜디오 2017 릴리즈 캔디데이트 3 이상의 버전과만 호환된다. 이 익스텐션이 인기 있는 젠킨스 CD/CI 플랫폼과 호환되는지를 묻는 질문에 마이크로소프트 블로그 게시판은 비주얼 스튜디오 팀 서비스가 요구된다고 게시돼 있다.  ciokr@idg.co.kr

2017.02.09

안전하게! 쉽게! 빠르게!··· '데이터 가상화'가 데브옵스와 찰떡궁합인 이유

데브옵스와 지속적 전달(continuous delivery)를 적극 이용하려 할 때 데이터가 걸림돌일 수 있다. 이에 대한 해답 중 하는 데이터 가상화다.  Image Credit : Getty Images Bank 개발에서 라이브(live) 데이터를 사용한다는 것은, 실제 작업부하를 테스트할 수 있고 실제적인 결과물을 얻을 수 있다는 의미다. 그러나 영국 아동용품 소매점 키디케어(Kiddicare)가 최근 깨달은 것처럼 커다란 보안 리스크 요인이기도 하다: 이 회사는 실제 고객명, 배송 주소, 이메일 주소, 전화번호를 테스트 사이트에 사용했는데 그 과정에서 데이터가 추출돼 피싱에 악용되는 사태에 직면해야 했다. 2015년 크라우드펀딩 사이트 패트레온(Patreon)의 사례도 있다. CEO 잭 콘테는 이 크라우드펀딩 사이트 사용자 230만 명의 이름, 배송 주소, 이메일 주소가 유출됐다고 인정했다. 그는 당시 “웹사이트의 디버그 버전을 통해” 발생했다고 전했다. 그리고 올해 초 호주 시드니대학(Sydney University)의 한 개발자는 6,700명의 장애 학생들의 개인정보와 의료정보가 담긴 데이터베이스의 암호화되지 않은 카피가 들어있는 노트북을 분실하기도 했다. '해브 아이 빈 판드?'(Have I Been Pwned?) 사이트를 운영하는 보안 전문가 트로이 헌트는 “키디케어와 패트레온 같은 사고에서 실제 데이터 취급의 위험성을 볼 수 있다. 이 문제가 얼마나 심각해질 수 있는지를 보여주는 업계 사례가 있다”라며 다음과 같이 말했다. “현장 데이터를 테스트에 이용하려는 물류기업을 생각해보자. 누군가 이들 두 환경에 접속해있는데, 그게 제품 데이터에 대한 접속권을 가진 테스트 환경의 링크된 SQL 서버일 수 있다. 나는 이런 상황이 큰 위험을 초래하는 것을 자주 보아왔다. 개발자들로부터 흔히 듣게 되는 변명은 ‘...

애자일 델픽스 데브옵스 지속적 전달 데이터 가상화 데이터 시뮬레이션

2016.05.25

데브옵스와 지속적 전달(continuous delivery)를 적극 이용하려 할 때 데이터가 걸림돌일 수 있다. 이에 대한 해답 중 하는 데이터 가상화다.  Image Credit : Getty Images Bank 개발에서 라이브(live) 데이터를 사용한다는 것은, 실제 작업부하를 테스트할 수 있고 실제적인 결과물을 얻을 수 있다는 의미다. 그러나 영국 아동용품 소매점 키디케어(Kiddicare)가 최근 깨달은 것처럼 커다란 보안 리스크 요인이기도 하다: 이 회사는 실제 고객명, 배송 주소, 이메일 주소, 전화번호를 테스트 사이트에 사용했는데 그 과정에서 데이터가 추출돼 피싱에 악용되는 사태에 직면해야 했다. 2015년 크라우드펀딩 사이트 패트레온(Patreon)의 사례도 있다. CEO 잭 콘테는 이 크라우드펀딩 사이트 사용자 230만 명의 이름, 배송 주소, 이메일 주소가 유출됐다고 인정했다. 그는 당시 “웹사이트의 디버그 버전을 통해” 발생했다고 전했다. 그리고 올해 초 호주 시드니대학(Sydney University)의 한 개발자는 6,700명의 장애 학생들의 개인정보와 의료정보가 담긴 데이터베이스의 암호화되지 않은 카피가 들어있는 노트북을 분실하기도 했다. '해브 아이 빈 판드?'(Have I Been Pwned?) 사이트를 운영하는 보안 전문가 트로이 헌트는 “키디케어와 패트레온 같은 사고에서 실제 데이터 취급의 위험성을 볼 수 있다. 이 문제가 얼마나 심각해질 수 있는지를 보여주는 업계 사례가 있다”라며 다음과 같이 말했다. “현장 데이터를 테스트에 이용하려는 물류기업을 생각해보자. 누군가 이들 두 환경에 접속해있는데, 그게 제품 데이터에 대한 접속권을 가진 테스트 환경의 링크된 SQL 서버일 수 있다. 나는 이런 상황이 큰 위험을 초래하는 것을 자주 보아왔다. 개발자들로부터 흔히 듣게 되는 변명은 ‘...

2016.05.25

벤더 기고 | 데브옵스가 기업을 삼킨다, 아틀라시안 ADLM 솔루션에 주목할 이유

2011년 투자자이자 창업가인 마크 앤드리슨(Marc Andressen)은 “소프트웨어가 세상을 삼킨다”(software eats the world)라고 표현했다. 5년 여가 지난 오늘날, 그의 말은 이제 누구도 반박하지 않는 현실이 되었다. 사실상 모든 기업에게 소프트웨어는 이제 비즈니스의 핵심으로 자리매김했으며, 기업 곳곳에서 소프트웨어 관련 업무가 진행되고 있다. 그리고 규모가 큰 기업일수록 이 현상은 더욱 뚜렷하다. 이에 따라 애플리케이션 개발에 대한 방법론 또한 변화 발전하고 있다. 전통적인 워터폴(Waterfall) 방식에서 애자일(Agile) 방식으로, 다시 지속적 전달(Continuous Delivery) 방식으로의 진화가 대표적이다. 이 과정에 등장한 ADLM(Application Development Lifecycle Management)은 애플리케이션 개발과 관리 배포 과정을 지속적인 라이프사이클로 간주하고 주기 전반에 걸쳐 관리와 개발 프로세스를 통합한다는 개념이다. 이 밖에 소프트웨어 개발 및 운용과 관련해 데브옵스, 린(lean) 개발, 자동화, 디지털 변혁 등의 유행어 등이 오늘날의 소프트웨어 현실을 반영하는 용어로 널리 활용되고 있다. 2002년 설립 이래 호주 최대의 소프트웨어 기업으로 도약한 아틀라시안은 총 5만 1,000곳의 고객사를 확보한 ADLM 분야 선도 기업이다. 전세계 50대 기업 중 40곳이 아틀라시안의 솔루션을 이용하고 있을 정도다. 가트너는 ADLM 솔루션이 갖춰야 할 요소로 ▲소프트웨어 요구사항 정의 및 관리, ▲소프트웨어 변경 및 구성 관리, ▲ 애자일에 초점이 맞춰진 프로젝트 플래닝, ▲버전관리와의 통합, ▲결함관리를 포함한 품질관리를 제공, ▲리포팅 기능, 워크플로우 제공, ▲다른 ADLM 도구와의 통합 지원을 제시한 바 있다. 아틀라시안은 이들 요소에 빠짐없이 대응하는 토탈 이슈 관리, 협업 솔루션을 갖췄다는 점에서 특히 독보적이다. 애자일 솔루...

협업 애자일 아틀라시안 지라 지속적 전달 모우소프트 ADLM 컨플루언스

2016.03.30

2011년 투자자이자 창업가인 마크 앤드리슨(Marc Andressen)은 “소프트웨어가 세상을 삼킨다”(software eats the world)라고 표현했다. 5년 여가 지난 오늘날, 그의 말은 이제 누구도 반박하지 않는 현실이 되었다. 사실상 모든 기업에게 소프트웨어는 이제 비즈니스의 핵심으로 자리매김했으며, 기업 곳곳에서 소프트웨어 관련 업무가 진행되고 있다. 그리고 규모가 큰 기업일수록 이 현상은 더욱 뚜렷하다. 이에 따라 애플리케이션 개발에 대한 방법론 또한 변화 발전하고 있다. 전통적인 워터폴(Waterfall) 방식에서 애자일(Agile) 방식으로, 다시 지속적 전달(Continuous Delivery) 방식으로의 진화가 대표적이다. 이 과정에 등장한 ADLM(Application Development Lifecycle Management)은 애플리케이션 개발과 관리 배포 과정을 지속적인 라이프사이클로 간주하고 주기 전반에 걸쳐 관리와 개발 프로세스를 통합한다는 개념이다. 이 밖에 소프트웨어 개발 및 운용과 관련해 데브옵스, 린(lean) 개발, 자동화, 디지털 변혁 등의 유행어 등이 오늘날의 소프트웨어 현실을 반영하는 용어로 널리 활용되고 있다. 2002년 설립 이래 호주 최대의 소프트웨어 기업으로 도약한 아틀라시안은 총 5만 1,000곳의 고객사를 확보한 ADLM 분야 선도 기업이다. 전세계 50대 기업 중 40곳이 아틀라시안의 솔루션을 이용하고 있을 정도다. 가트너는 ADLM 솔루션이 갖춰야 할 요소로 ▲소프트웨어 요구사항 정의 및 관리, ▲소프트웨어 변경 및 구성 관리, ▲ 애자일에 초점이 맞춰진 프로젝트 플래닝, ▲버전관리와의 통합, ▲결함관리를 포함한 품질관리를 제공, ▲리포팅 기능, 워크플로우 제공, ▲다른 ADLM 도구와의 통합 지원을 제시한 바 있다. 아틀라시안은 이들 요소에 빠짐없이 대응하는 토탈 이슈 관리, 협업 솔루션을 갖췄다는 점에서 특히 독보적이다. 애자일 솔루...

2016.03.30

데브옵스에 보안 통합 '데브시크옵스'··· 효과는? 전망은?

데브옵스(DevOps)는 개발, IT 운영, 보안, 품질 보증을 통합해 자동화하는 개념이자 기법이며 철학이다. 간단히 말하자면 여러 부서가 힘을 합해 소프트웨어 개발 주기와 테스트 기간을 앞당기고, 자동화 수준을 높이고, 코드의 품질과 보안 수준을 높인다는 것이다. 데브옵스는 이를 위해 여러 부서의 팀이 서로 협력해 계획을 수립하고, 코드와 빌드를 구현하고, 테스트와 배포를 하고, 운영 및 모니터링하는 연결된 고리를 만든다. 이렇게 하면 소프트웨어를 효율적이면서도 유연하게 개발할 수 있으며, 결과물의 품질을 높일 수 있다. 데브옵스의 장점은 잘 알려져 있다. 소프트웨어 품질을 높이고, 시장화를 앞당기고, 거버넌스와 컴플라이언스(정책 및 규제 준수) 위험을 줄이는 것 등을 예로 들 수 있다. 그러나 정보 보안이 이 과정에 어떤 역할을 할 수 있는지에 대한 질문이 새롭게 부상하고 있다. 오늘날 기존의 데브옵스를 넘어선 지평을 추구하는 기업들이 있다. 이들은 애플리케이션 개발의 모든 과정에 정보 보안을 포함시키는 프로세스인 데브시크옵스(DevSecOps)를 추구한다. 그러나 몹시 까다로운 프로세스라는 점이 문제다. 보안 부서와 IT 부서의 미묘한 관계는 익히 유명하다. 사실 데브옵스 팀을 운영하는 조직에서는 이들의 관계가 더 나쁘다고도 알려져 있다. 또 데브옵스와 데브시크옵스는 운영 모델과 목적이 다르다. 데브옵스는 운영 팀을 개발 팀에 합류 시키는데 목적을 둔다. 프로젝트가 끝날 무렵에 투입시키는 방식이 아니다. 정상적인 기업이라면 운영 팀(Ops)에 거의 다 완성된 결과물을 보내는 방식을 이용하지 않는다. 데브시크옵스에서는 원칙은 동일하자만 대상이 다르다. 보안을 '나중에 관여하는' 고립된 부서로 취급하지 않는다. 개발 프로젝트의 모든 단계에 통합시킨다. 데브옵스 트렌드를 선도하는 구글과 아마존 데브옵스 모델을 도입한 대다수 기업들이 수많은 혜택을 조기에 누리고 있는 것으로 조사됐...

데브옵스 지속적 전달 데브시크옵스 DevSecOps

2016.03.08

데브옵스(DevOps)는 개발, IT 운영, 보안, 품질 보증을 통합해 자동화하는 개념이자 기법이며 철학이다. 간단히 말하자면 여러 부서가 힘을 합해 소프트웨어 개발 주기와 테스트 기간을 앞당기고, 자동화 수준을 높이고, 코드의 품질과 보안 수준을 높인다는 것이다. 데브옵스는 이를 위해 여러 부서의 팀이 서로 협력해 계획을 수립하고, 코드와 빌드를 구현하고, 테스트와 배포를 하고, 운영 및 모니터링하는 연결된 고리를 만든다. 이렇게 하면 소프트웨어를 효율적이면서도 유연하게 개발할 수 있으며, 결과물의 품질을 높일 수 있다. 데브옵스의 장점은 잘 알려져 있다. 소프트웨어 품질을 높이고, 시장화를 앞당기고, 거버넌스와 컴플라이언스(정책 및 규제 준수) 위험을 줄이는 것 등을 예로 들 수 있다. 그러나 정보 보안이 이 과정에 어떤 역할을 할 수 있는지에 대한 질문이 새롭게 부상하고 있다. 오늘날 기존의 데브옵스를 넘어선 지평을 추구하는 기업들이 있다. 이들은 애플리케이션 개발의 모든 과정에 정보 보안을 포함시키는 프로세스인 데브시크옵스(DevSecOps)를 추구한다. 그러나 몹시 까다로운 프로세스라는 점이 문제다. 보안 부서와 IT 부서의 미묘한 관계는 익히 유명하다. 사실 데브옵스 팀을 운영하는 조직에서는 이들의 관계가 더 나쁘다고도 알려져 있다. 또 데브옵스와 데브시크옵스는 운영 모델과 목적이 다르다. 데브옵스는 운영 팀을 개발 팀에 합류 시키는데 목적을 둔다. 프로젝트가 끝날 무렵에 투입시키는 방식이 아니다. 정상적인 기업이라면 운영 팀(Ops)에 거의 다 완성된 결과물을 보내는 방식을 이용하지 않는다. 데브시크옵스에서는 원칙은 동일하자만 대상이 다르다. 보안을 '나중에 관여하는' 고립된 부서로 취급하지 않는다. 개발 프로젝트의 모든 단계에 통합시킨다. 데브옵스 트렌드를 선도하는 구글과 아마존 데브옵스 모델을 도입한 대다수 기업들이 수많은 혜택을 조기에 누리고 있는 것으로 조사됐...

2016.03.08

'데브옵스 도입을 더 쉽게' 도우미 도구 8종

데브봅스(Devops)의 인기가 뜨겁다. 소프트웨어 개발과 운영의 간극을 메우고, 개발자와 시스템 관리자의 관계를 매끄럽게 만들어주는 장점을 갖고 있기 때문이다. 전통적으로 이 두 집단은 소프트웨어 개발, 테스트, 앱의 생산 배표를 놓고 갈등을 빚어온 관계이다. 그러나 데브옵스는 이를 해결하는 효과를 안겨줄 수 있다. 최근에는 데브옵스를 도와주는 도구들도 다수 등장했다. '퍼펫'(Puppet), 셰프(Chef) 등의 구성(설정) 관리 도구가 가장 잘 알려져 있다. 그러나 구성 관리를 위한 도구만 있지 않다. 다음은 데브옵스를 염두에 두고 있는 기업들이 참고할 만한 8가지 도구들이다. ciokr@idg.co.kr

애자일 데브옵스 셰프 퍼펫 지속적 전달

2016.02.15

데브봅스(Devops)의 인기가 뜨겁다. 소프트웨어 개발과 운영의 간극을 메우고, 개발자와 시스템 관리자의 관계를 매끄럽게 만들어주는 장점을 갖고 있기 때문이다. 전통적으로 이 두 집단은 소프트웨어 개발, 테스트, 앱의 생산 배표를 놓고 갈등을 빚어온 관계이다. 그러나 데브옵스는 이를 해결하는 효과를 안겨줄 수 있다. 최근에는 데브옵스를 도와주는 도구들도 다수 등장했다. '퍼펫'(Puppet), 셰프(Chef) 등의 구성(설정) 관리 도구가 가장 잘 알려져 있다. 그러나 구성 관리를 위한 도구만 있지 않다. 다음은 데브옵스를 염두에 두고 있는 기업들이 참고할 만한 8가지 도구들이다. ciokr@idg.co.kr

2016.02.15

벤더 기고 | 데브옵스를 올바르게 구현하는 방법

* 본 기고문은 벤더가 작성한 것으로 네트워크 월드 편집진의 수정을 거쳤다. 그러나 벤더의 시각이 일부 남아 있을 수 있다. 데브옵스(DevOps) 도입이 증가하고 있다. 의심의 여지가 없다. 가트너에 따르면, 올해 글로벌 2000 기업의 25%가 데브옵스를 도입해 활용할 전망이다. 문제는 데브옵스로의 전환이 쉽지만은 않다는 점이다. 엔터프라이즈에는 기존 프로세스, 조직, 시스템, 사일로가 가득하기 때문이다. 변화에 대한 저항이 거의 확실히 발생한다. 자동화는 속도와 통일성을 가져다 줄 수 있다. 그러나 가시성과 관리성이라는 도전 과제가 수반되기 마련이다. 데브옵스 생태계가 성숙해지고 있지만 너무나도 많은 툴이 존재하며, 데브옵스를 성공적으로 도입할 수 있도록 해주는 분명한 청사진이 아직 없다. 애자일 선언서(Agile manifesto)는 구체적인 가이드라인이 아니라 높은 차원의 '성명서'에 가깝다 그렇다면 데브옵스 이행의 중요 전제조건은 뭘까? 다른 이들의 성공과 실패에서 무엇을 배울 수 있을까? 지금부터 이에 관한 내용을 소개하겠다. * 균형 잡힌 추진. 위에서 아래로의 하향식 참여와 몰입이 중요하다. 최고위층이 변화의 필요성을 인식해 승인해야 한다. 그래야 장애물을 제거하고, 올바른 장소에 자원을 투자하고, 권한을 위임할 수 있다. 또 데브옵스를 기업의 우선순위로 추진할 수 있다. 그러면서도 독단적인 강제와 강요는 피해야 한다. 실제 실천은 아래로부터 위로의 상향식이 되어야 한다. 각 팀이 필요한 기술, 시스템 전달 프로세스의 구현 방법, 가장 합리적인 방식을 스스로 파악해야 있어야 한다. 하나로 모든 것을 처리할 수 있는 방법은 없다. 팀의 전문성을 이용, 최상의 토대를 구축해야 한다. 즉 하향식과 상향식이 균형 잡혀야 최상의 결과를 이끌어낼 수 있다. * 적합한 스킬. 튼튼한 코딩 토대와 더불어 지속적인 통합, 배포, 테스트, 품질, 가상화, 클라우드, 프로비저닝, 조율 및 통일, 모니터링...

애자일 자동화 데브옵스 지속적 전달 제비아랩스

2016.02.05

* 본 기고문은 벤더가 작성한 것으로 네트워크 월드 편집진의 수정을 거쳤다. 그러나 벤더의 시각이 일부 남아 있을 수 있다. 데브옵스(DevOps) 도입이 증가하고 있다. 의심의 여지가 없다. 가트너에 따르면, 올해 글로벌 2000 기업의 25%가 데브옵스를 도입해 활용할 전망이다. 문제는 데브옵스로의 전환이 쉽지만은 않다는 점이다. 엔터프라이즈에는 기존 프로세스, 조직, 시스템, 사일로가 가득하기 때문이다. 변화에 대한 저항이 거의 확실히 발생한다. 자동화는 속도와 통일성을 가져다 줄 수 있다. 그러나 가시성과 관리성이라는 도전 과제가 수반되기 마련이다. 데브옵스 생태계가 성숙해지고 있지만 너무나도 많은 툴이 존재하며, 데브옵스를 성공적으로 도입할 수 있도록 해주는 분명한 청사진이 아직 없다. 애자일 선언서(Agile manifesto)는 구체적인 가이드라인이 아니라 높은 차원의 '성명서'에 가깝다 그렇다면 데브옵스 이행의 중요 전제조건은 뭘까? 다른 이들의 성공과 실패에서 무엇을 배울 수 있을까? 지금부터 이에 관한 내용을 소개하겠다. * 균형 잡힌 추진. 위에서 아래로의 하향식 참여와 몰입이 중요하다. 최고위층이 변화의 필요성을 인식해 승인해야 한다. 그래야 장애물을 제거하고, 올바른 장소에 자원을 투자하고, 권한을 위임할 수 있다. 또 데브옵스를 기업의 우선순위로 추진할 수 있다. 그러면서도 독단적인 강제와 강요는 피해야 한다. 실제 실천은 아래로부터 위로의 상향식이 되어야 한다. 각 팀이 필요한 기술, 시스템 전달 프로세스의 구현 방법, 가장 합리적인 방식을 스스로 파악해야 있어야 한다. 하나로 모든 것을 처리할 수 있는 방법은 없다. 팀의 전문성을 이용, 최상의 토대를 구축해야 한다. 즉 하향식과 상향식이 균형 잡혀야 최상의 결과를 이끌어낼 수 있다. * 적합한 스킬. 튼튼한 코딩 토대와 더불어 지속적인 통합, 배포, 테스트, 품질, 가상화, 클라우드, 프로비저닝, 조율 및 통일, 모니터링...

2016.02.05

'코드로 인프라 관리하기'··· IAC 방법론 뜬다

지난 몇 년간 인간의 개입 필요성을 줄여주는 자동화가 IT 분야의 주요 트렌드로 자리잡았다. 가상화는 개발자들이 생산 시스템과 격리된 공간에서 작업을 할 수 있는 가상 서버 공간을 탄생시켰다. 이제 20분 정도면 VM웨어(VMware)와 하이퍼-V(Hyper-V) 같은 하이퍼바이저를 구현할 수 있다. Credit: CERN   그러나 가상 작업공간 프로비저닝이 늘 간단한 것은 아니다. 많은 시간이 필요한 프로세스가 요구될 수 있으며, 이를 구현할 전문성을 가진 사람이 없을 수도 있다. 개발자가 개발 작업을 위한 가상 환경을 요청한 후, VM 준비까지 2주를 기다려야 할 수 있다. 이런 상황에 IAC(Infrastructure as Code)가 필요하다. IAC는 유연성이 떨어지는 스크립팅이나 수동 프로세스 대신 코드를 이용해 시스템을 자동으로 구축, 관리, 프로비저닝 하는 IT 인프라 프로비저닝 프로세스의 일종이다. 이에 따라 IAC를 때론 '프로그래밍이 가능한 인프라'라고 부르기도 한다. 당연한 말이지만 코드가 탄탄하면 프로세스를 앞당기고 인적 실수를 없앨 수 있다. 쏘우트워크스 유럽(ThoughtWorks Europe)의 지속적 전달(Continuous Delivery) 책임자인 키프 모리스는 "IAC는 클라우드, 마이크로서비스, 지속적 전달 시대에 IT 인프라를 관리할 수 있는 방법이다. IT 인프라를 소프트웨어처럼 다룬다는 기본 개념을 갖고 있다. 이는 손쉽고 빠르게, 안전하면서도 믿을 수 있게 변화를 추구하는데 도움을 준다"라고 설명했다. 코드를 이용함으로써 가상 머신이나 콘테이너를 설정 및 구성하는 프로세스를 자동화하면서 이를 반복적으로 빠르게 되풀이 하는 방안을 만들어낼 수 있다. 예를 들어 애플리케이션을 개발하는 가상 환경을 구축하고 싶다면, 동일한 코드를 실행시켜 VM 생성 프로세스를 반복할 수 있다. IAC는 IT 프로세스를 자동화한다는 ...

애자일 데브옵스 셰프 퍼펫 지속적 전달 IaC 프로그래머블 인프라

2015.12.24

지난 몇 년간 인간의 개입 필요성을 줄여주는 자동화가 IT 분야의 주요 트렌드로 자리잡았다. 가상화는 개발자들이 생산 시스템과 격리된 공간에서 작업을 할 수 있는 가상 서버 공간을 탄생시켰다. 이제 20분 정도면 VM웨어(VMware)와 하이퍼-V(Hyper-V) 같은 하이퍼바이저를 구현할 수 있다. Credit: CERN   그러나 가상 작업공간 프로비저닝이 늘 간단한 것은 아니다. 많은 시간이 필요한 프로세스가 요구될 수 있으며, 이를 구현할 전문성을 가진 사람이 없을 수도 있다. 개발자가 개발 작업을 위한 가상 환경을 요청한 후, VM 준비까지 2주를 기다려야 할 수 있다. 이런 상황에 IAC(Infrastructure as Code)가 필요하다. IAC는 유연성이 떨어지는 스크립팅이나 수동 프로세스 대신 코드를 이용해 시스템을 자동으로 구축, 관리, 프로비저닝 하는 IT 인프라 프로비저닝 프로세스의 일종이다. 이에 따라 IAC를 때론 '프로그래밍이 가능한 인프라'라고 부르기도 한다. 당연한 말이지만 코드가 탄탄하면 프로세스를 앞당기고 인적 실수를 없앨 수 있다. 쏘우트워크스 유럽(ThoughtWorks Europe)의 지속적 전달(Continuous Delivery) 책임자인 키프 모리스는 "IAC는 클라우드, 마이크로서비스, 지속적 전달 시대에 IT 인프라를 관리할 수 있는 방법이다. IT 인프라를 소프트웨어처럼 다룬다는 기본 개념을 갖고 있다. 이는 손쉽고 빠르게, 안전하면서도 믿을 수 있게 변화를 추구하는데 도움을 준다"라고 설명했다. 코드를 이용함으로써 가상 머신이나 콘테이너를 설정 및 구성하는 프로세스를 자동화하면서 이를 반복적으로 빠르게 되풀이 하는 방안을 만들어낼 수 있다. 예를 들어 애플리케이션을 개발하는 가상 환경을 구축하고 싶다면, 동일한 코드를 실행시켜 VM 생성 프로세스를 반복할 수 있다. IAC는 IT 프로세스를 자동화한다는 ...

2015.12.24

애자일·지속적 전달 모델이 대변하는 '문화적 변화'

비즈니스 혁신 가속 임무를 가진 IT 리더들이 전통적인 IT 프로젝트 관리법을 바꾸고 있는 중이다. 소프트웨어와 서비스 신판에 있어서 지속적 전달(continuous delivery) 모델을 선택하고 있는 것이다. 하지만 CIO를 비롯한 여러 전문가들에 따르면 이 떠오르는 IT 배치 모델을 성공적으로 도입하기 위해서는 비즈니스 이해당사자와의 강력한 협업은 물론 교차-교육이 필요하다. 시스코의 운영 부문 선임 부회장 레베카 자코비는 “이것을 IT의 완전한 문화적 변화라고 본다. 과거 해왔던 방식에서 빠르게 바뀔 필요가 있다”라고 이번 주 초 CIO 100 심포지엄에서 이야기했다. 자코비가 말하는 ‘과거’에는 비즈니스 리더들이 CIO에게 두꺼운 제품 요건 책자를 들이미는 단계적 IT 서비스(phased IT service) 전달 주기 방식이 포함된다. 소프트웨어 구축에 12개월에서 24개월 정도를 들이는 방식이다. 하지만 소비자가 온라인과 모바일 애플리케이션을 통해 데이터에 접속하는 세계에서 ‘요청한대로 작업하고 다 되면 갖다 주는’ 모델로는 충분하지 않다. 무엇보다도 비즈니스 요건은 변덕스러운 소비자들의 기능과 기능성 선호사향을 맞추기 위해 급속하게 변화하기 때문이다. 오늘날에는 잦은 버전 업그레이드가 완성 제품보다 더 선호되고 있으며, 이에 따라 소프트웨어 전달 방식이 재검토되고 있다. 많은 CIO들은 애자일 개발과 데브옵스 모델을 현실 업무에 채택하는 중이다. 그리고 소프트웨어가 준비되면 (애자일에서 완료라는 말은 거의 볼 수 없다) 그들은 지속적으로 이를 갈고 닦고 손봐서 새로운 비즈니스 요건에 부합하게 만든다. 애자일 개발이 IT-비즈니스 협업을 돕는다 CIO 100 심포지엄에서 패널로 이야기했던 CIO들은 그들의 사업체가 애자일 개발을 수용하기 위해 변화해온 과정 및 여러 방법들에 대해 이야기했다. 2006년부터 6월 승진 전까지 시스코의 CI...

협업 애자일 문화 지속적 전달 컨티뉴어스 딜리버리

2015.08.18

비즈니스 혁신 가속 임무를 가진 IT 리더들이 전통적인 IT 프로젝트 관리법을 바꾸고 있는 중이다. 소프트웨어와 서비스 신판에 있어서 지속적 전달(continuous delivery) 모델을 선택하고 있는 것이다. 하지만 CIO를 비롯한 여러 전문가들에 따르면 이 떠오르는 IT 배치 모델을 성공적으로 도입하기 위해서는 비즈니스 이해당사자와의 강력한 협업은 물론 교차-교육이 필요하다. 시스코의 운영 부문 선임 부회장 레베카 자코비는 “이것을 IT의 완전한 문화적 변화라고 본다. 과거 해왔던 방식에서 빠르게 바뀔 필요가 있다”라고 이번 주 초 CIO 100 심포지엄에서 이야기했다. 자코비가 말하는 ‘과거’에는 비즈니스 리더들이 CIO에게 두꺼운 제품 요건 책자를 들이미는 단계적 IT 서비스(phased IT service) 전달 주기 방식이 포함된다. 소프트웨어 구축에 12개월에서 24개월 정도를 들이는 방식이다. 하지만 소비자가 온라인과 모바일 애플리케이션을 통해 데이터에 접속하는 세계에서 ‘요청한대로 작업하고 다 되면 갖다 주는’ 모델로는 충분하지 않다. 무엇보다도 비즈니스 요건은 변덕스러운 소비자들의 기능과 기능성 선호사향을 맞추기 위해 급속하게 변화하기 때문이다. 오늘날에는 잦은 버전 업그레이드가 완성 제품보다 더 선호되고 있으며, 이에 따라 소프트웨어 전달 방식이 재검토되고 있다. 많은 CIO들은 애자일 개발과 데브옵스 모델을 현실 업무에 채택하는 중이다. 그리고 소프트웨어가 준비되면 (애자일에서 완료라는 말은 거의 볼 수 없다) 그들은 지속적으로 이를 갈고 닦고 손봐서 새로운 비즈니스 요건에 부합하게 만든다. 애자일 개발이 IT-비즈니스 협업을 돕는다 CIO 100 심포지엄에서 패널로 이야기했던 CIO들은 그들의 사업체가 애자일 개발을 수용하기 위해 변화해온 과정 및 여러 방법들에 대해 이야기했다. 2006년부터 6월 승진 전까지 시스코의 CI...

2015.08.18

기고 | '개념에서 의의까지' 데브옵스 따라잡기

데크옵스라는 용어의 정의를 추적하다 보면 ‘애자일’, 시스템 관리’ ‘린’(lean) 등의 유행어 집합을 접하게 된다. 결국 동어반복에 그치는 설명들이다. 여기 좀더 이해가 쉬운 해설을 제시한다. 데브옵스(DevOps)의 기본 개념은 개발자(Developer)와 운영자(Operator)라는 두 가지 역할을 동시에 수행한다는 것이다. 얼핏 단순한 복합 직무로 여겨질 수 있다. 그러나 사실 데브옵의 개념을 보다 잘 이해하기 위해서는 개발자와 운영자 두 직무가 지금까지 어떤 역할을 수행해왔는지를 잠시 생각해볼 필요가 있다. 운영자의 책무는 업타임(uptime)과 안정성을 보장하는 것이었다. 그 역할을 수행하는 가장 간단한 방법은 시스템의 통로를 걸어 잠그고 변화를 최소화하는 것이다. 이와 반대로 소프트웨어 개발자는 변화를 만들어내는 사람이다. 기본 역할에서부터 그 방향성이 정반대인 것이다. 즉, 데브옵스의 시작은 두 역할 사이의 벽을 허무는 것에서부터 출발한다. 여기 그 사례를 살펴보자. 수 년, 길게는 수십 년 전부터 시스템 관리자들은 반복적 작업과 설정을 자동화하기 위해 몇몇 스크립트(배시(bash), 펄(pearl), 오크(awk), 세드(sed))를 작성해왔다. 이들 스크립트는 코드지만, 시스템 관리자들이 작성하는 코드는 프로그래머들이 따라야 하는 방법론들 중 무엇도 따르지 않았다. 이는 어떤 요청이나 공식적인 테스트 프로세스, 배치 프로세스도 갖추지 않았으며 소스 코드 통제에도 포함되지 않았다. 어떤 작업 표준도 가지지 않으며 이들 코드는 생산 코드와는 다른 프로그래밍 언어를 취했다. 코드의 대상 가운데는 프로그래머가 재사용 가능한 것도 있었지만 프로그래머들은 그것의 존재를 알지 못했다. 두 직무 사이의 공동 작업 구조가 있었다면 지식과 활동, 근본적으로는 코드베이스의 공유까지 가능했을 것이다 시스템 관리 작업의 자동화와 반복은 프로그래머들이...

애자일 디봅스 데브옵스 지속적 전달

2015.06.22

데크옵스라는 용어의 정의를 추적하다 보면 ‘애자일’, 시스템 관리’ ‘린’(lean) 등의 유행어 집합을 접하게 된다. 결국 동어반복에 그치는 설명들이다. 여기 좀더 이해가 쉬운 해설을 제시한다. 데브옵스(DevOps)의 기본 개념은 개발자(Developer)와 운영자(Operator)라는 두 가지 역할을 동시에 수행한다는 것이다. 얼핏 단순한 복합 직무로 여겨질 수 있다. 그러나 사실 데브옵의 개념을 보다 잘 이해하기 위해서는 개발자와 운영자 두 직무가 지금까지 어떤 역할을 수행해왔는지를 잠시 생각해볼 필요가 있다. 운영자의 책무는 업타임(uptime)과 안정성을 보장하는 것이었다. 그 역할을 수행하는 가장 간단한 방법은 시스템의 통로를 걸어 잠그고 변화를 최소화하는 것이다. 이와 반대로 소프트웨어 개발자는 변화를 만들어내는 사람이다. 기본 역할에서부터 그 방향성이 정반대인 것이다. 즉, 데브옵스의 시작은 두 역할 사이의 벽을 허무는 것에서부터 출발한다. 여기 그 사례를 살펴보자. 수 년, 길게는 수십 년 전부터 시스템 관리자들은 반복적 작업과 설정을 자동화하기 위해 몇몇 스크립트(배시(bash), 펄(pearl), 오크(awk), 세드(sed))를 작성해왔다. 이들 스크립트는 코드지만, 시스템 관리자들이 작성하는 코드는 프로그래머들이 따라야 하는 방법론들 중 무엇도 따르지 않았다. 이는 어떤 요청이나 공식적인 테스트 프로세스, 배치 프로세스도 갖추지 않았으며 소스 코드 통제에도 포함되지 않았다. 어떤 작업 표준도 가지지 않으며 이들 코드는 생산 코드와는 다른 프로그래밍 언어를 취했다. 코드의 대상 가운데는 프로그래머가 재사용 가능한 것도 있었지만 프로그래머들은 그것의 존재를 알지 못했다. 두 직무 사이의 공동 작업 구조가 있었다면 지식과 활동, 근본적으로는 코드베이스의 공유까지 가능했을 것이다 시스템 관리 작업의 자동화와 반복은 프로그래머들이...

2015.06.22

IDG 설문조사

회사명:한국IDG 제호: ITWorld 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 편집인 : 박재곤 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.

10.4.0.6