2021.07.19

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

Matthew Tyson | InfoWorld
모든 데스옵스 시나리오에 적용할 수 있는 만능해답 같은 것은 없다. 하지만 이상적인 개발 과정과 툴체인을 묘사할 수는 있겠다. 여기 데브옵스의 각 조각이 어떻게 어울리고 조합될 수 있는지 살펴본다. 

데브옵스(Devops) 접근법는 개발 및 운영 활동을 아우르는 종합적인 관점을 취하고, 이들이 가장 효율적으로 상호작용할 수 있도록 조율한다. 하지만 이는 개념적 이상일 뿐이다. 기술적 관점에서 이상적인 데브옵스 풍경이란 무엇일까?

답은 ‘서술할 수 없다’이다. 신생 기업의 요구와 수백 명이 관여하면서 마이크로서비스 프로젝트를 시작하는 다국적 기업의 요구는 전혀 다르기 때문이다. 

그러나 증가하는 복잡성을 적절하게 흡수할 수 있는 이상적인 개발 흐름을 서술할 수는 있다. 또 아울러 CI/CD(지속적 통합/지속적 전달), 도커, 클라우드 컴퓨팅 같은 기술을 이 흐름에 접목하는 방식을 설명해볼 수 있다. 
 
Image Credit : Getty Images Bank

개발 : ‘내부의 고리’ 
한 개발자가 있다고 하자. 그는 소프트웨어를 당연히 수정할 것이고, 수정이 만족스럽다면 이를 버전 컨트롤로 커밋할 것이다. 버전 컨트롤은 소프트웨어 개발의 ‘내부 고리’와 데브옵스의 ‘외부 고리’ 사이의 접합 지점이다. 

개발자 커밋은 개발 브랜치, 기능 브랜치, 또는 (비공식적 환경에서) 메인 브랜치로 이어질 수 있다. 이상적으로는 자동화된 유닛 테스트의 실행이 있을 것이다. 이는 다양한 방식으로 일어날 수 있다. 프리-커밋 후크, 커밋 후크 등 선택지는 무한하다. 어쨌든 유닛 테스트를 통과하지 못하면 코드 변경은 브랜치로 수용되지 않는다. 

자동화된 테스팅 
일단 코드 변경이 수용되면 다음 단계는 ‘통합 테스트’다. 이는 지속적 통합(CI)에서 필수적이다. 다시 말해 코드는 계속적으로 더 큰 시스템에 통합되고 실행 환경에서 자동 및 수동 테스팅을 위해 전개된다.

자동화된 테스팅에는 한계가 없다. 모든 것이 가능하다. 셀레늄 스타일의 자동화된 UI 테스팅으로부터 정교한 로드 테스팅 스위트에 이르기까지 온갖 종류의 최신 자동화 툴이 소프트웨어를 완성하는 데 이용될 수 있다. 가끔은 자동화된 스모크 테스팅(automatedsmoke testing)이 테스트로 올라온 소프트웨어가 명목적으로 작용하고 있음을 보장한다. 

테스팅에 있어서 금과옥조가 있다면 ‘문제를 최대한 빨리 발견하라’이다. 

수작업 검증 테스트 
소프트웨어가 유닛 및 자동화된 통합 테스트를 통과했다면 이제 수작업 테스팅이 기다린다. 통상적으로 수작업 테스팅은 특정한 기능 및 수정 세트를 포착하는 특정한 분류 태그에 대해 이뤄진다. 프로덕션 환경으로 변경 사항을 적용시키는 데 있어 신중해야 하기 때문이다.

다시 말해 프로덕션 환경을 모방한 환경으로 소프트웨어를 배포하는 것이다. 여기서 소프트웨어는 수동으로 상호작용을 거치고, QA 담당자는 최선을 다해 문제를 찾으려 할 것이다. 문제를 발견하면 픽스가 병합될 수 있다. 

QA 담당자가 만족했다면 코드 패키지는 UA, 다시 말해 이용자 수용 테스팅(User Acceptance Testing)으로 올라갈 수 있다. 이는 여러 방식으로 이루어질 수 있지만, 핵심은 더 많은 사람들, 다시 말해 비즈니스 애널리스트, 여타 관계자들이 소프트웨어를 시험하는 것이다. 이들의 시험이 끝나면 소프트웨어는 비즈니스 현장, 즉 프로덕션에 투입될 준비가 된 것이다. 

프로덕션으로의 변경을 모니터링 
프로덕션으로의 변경의 경우 규모가 클수록 더 많은 검증 활동이 이루어진다. 동시에 새로운 단계, 즉 모니터링도 진행된다. 모니터링과 로깅은 전체 시스템이 제대로 작용하는 지를 확인하는 데 필수적이다. 이는 클라우드 시대에 커다란 개선을 이룬 또 하나의 분야이다. 다양한 로깅 및 모니터링 툴이 시중에 나와있다.

마이크로서비스의 영역에 있어서 프로덕션으로의 전개는 때에 따라 좀더 까다롭다. 마이크로서비스의 요소들이 단계적으로 전개될 수 있기 때문이다. 네트워크 트래픽은 갱신된 노드로 점증적으로 라우팅 되어 이들이 다른 컴포넌트와 의도한 대로 상호작용하는 지를 검증한다.  

데브옵스 내의 여러 역할 
이러한 프로세스를 바라보는 또 다른 방식은 사람이 하는 역할이다. 역할이란 사람들이 하는 업무이지 굳이 직함을 말하는 것은 아니다. 크게는 3가지 역할을 규정할 수 있다. 코드를 수정하는 사람, 코드의 유효성을 검사하는 사람, 실행 중인 시스템을 관리하는 사람이다. 

이들은 개발자, 테스터, 관리자라고 불린다. 

물론 자세히 들어가면 역할은 더 다양해진다. 예를 들어 새로운 코드 변경을 테스팅 하는 QA 엔지니어는 UA 서버 상의 요구사항을 검증하는 비즈니스 애널리스트와 전혀 다르다. 이들은 모니터를 구성하여 프로덕션 시스템이 특정 파라미터 내에서 실행되고 있는지를 검증하는 데브옵스 엔지니어와 전혀 다르다. 그러나 이들 활동은 거시적으로 코드가 의도대로 작용하는 지를 검증하는 것이다. 

이제 이러한 시각을 바탕으로 실무자가 업무에서 이용하는 특정한 툴에 대해 살펴본다.

컨테이너 : 개발-운영 결합 부분 
특히 많은 분야와 이어지는 기술이 컨테이너다. 실무적으로 도커를 의미한다. 도커가 런타임 니즈를 정의하는 전개 가능한 덩어리(컴포넌트)로 개발자의 소프트웨어를 분할할 수 있게 해준다. 따라서 개발자는 컨테이너 개발을 목표로 할 수 있고, 관리자는 컨테이너를 시스템 전반에 걸쳐 공통 분모로 이용할 수 있다.

컨테이너 수준에서 전개 가능한 유닛은 최고의 용량 및 수요 요건조차도 지탱하기에 충분하다. 쿠버네티스는 가장 인기 있는 컨테이너 클러스터 관리 시스템이 되었고, 단순한 기술은 아니지만 기능들은 인상적이다. 다시 말해 여러 지역 및 연동 서비스에 걸쳐 대형 클러스터를 관리할 수 있다.

- 컨테이너와 개발 
그러나 컨테이너화는 개발자의 ‘내부 고리’를 위한 손쉬운 수단은 아니다. 컨테이너가 코드, 빌드, 테스트 사이클에 복잡성을 추가하기 때문이다. 개발자가 ‘익스플로디드’ 개발 환경을 더 보편적으로 이용하는 이유이다. 여 환경에서 개발자는 컨테이너화되지 않은 로컬 환경에서 코드를 실행한다. 

유닛 테스트는 코드 품질에 있어서 개발자의 최전방 방어선이다. 어찌됐든 도커는 개발자를 위해 몇몇 측면을 더 단순하게 만들 수 있다. 예를 들어 몽고DB(MongoDB), 포스트그레SQL(PostgreSQL) 등의 데이터스토어의 표준화된 버전을 패키징 하면 개발자는 코딩 시 이를 쉽게 이용할 수 있다.  

- 컨테이너 및 테스트 데이터 
마찬가지로 도커 및 도커 컴포즈를 이용해 테스트 데이터로 데이터베이스를 시작한다면 이는 개발 환경에 혜택이 된다. 

따라서 도커는 데브옵스 환경을 통일하는 데 있어 핵심이고, 개발자에게 특정한 혜택을 제공하지만, 실제 코딩 작업에서는 임피던스 불일치가 있다. 

CI/CD 파이프라인 툴링 
이제 여러 요소를 데브옵스 파이프라인으로 연결하는 데 쓰일 수 있는 툴을 검토해보자. 많은 툴이 있다. 

- 스스로 실행하기 
가장 오래된 CI 서버는 젠킨스이고, 이는 여전히 인기가 있고 강력하다. 하지만 중대한 결함이 있다. 부실한 문서이다. 젠킨스와 무수한 젠킨스 플러그인을 이용해 거의 무엇이든지 할 수 있다. 그러나 이는 흔히 스스로 극복해야 하는 경험이다. 

젠킨스는, 흔히 클라우드 VM 상에서, 이용자가 스스로 설치하고 운영하는 서버이다. 그 후 이는 지휘자 역할을 한다. 깃허브 또는 다른 버전 관리 시스템 풀링, 빌드 및 테스트 실행, 도커 레지스트리와의 연동, 표적 환경으로의 전개 등이다. 최근의 솔루션에는 여러 SaaS 제품이 있다. 몇 가지를 살펴보자. 

- SaaS 선택지 
깃랩 CI/CD(GitLab CI/CD) 및 서클CI(CircleCI)는 인지도가 높은 최근의 지속적 통합 제품이다. 그렇다고 해서 이들이 이 인기 있는 시장에서 경쟁하는 유일한 업체라는 것은 전혀 아니다. 새로운 회사들이 편리하고 효과적으로 데브옵스 문제를 해결하기 위해 시장에 진입하고 있다. 안정된 회사인 제이프로그(JFrog)가 출시한 시퍼블(Shippable) 역시 인기가 높아지고 있는 새로운 선택지이다.

- 테스팅 툴 
테스팅 자동화 툴인 셀레늄(Selenium)은 CI 툴인 젠킨스의 자연스러운 후속작이다. 젠킨스와 마찬가지로 이용자 스스로 설치하고 구성하는 무료 오픈 소스 소프트웨어이다. 이는 앱피움(Appium)이나 여러 클라우드 공급업체의 SaaS 제품과 대조된다. 

CI/CD 분야와 마찬가지로 테스팅 역시 매우 활발한 시장이다. 

- 인프라 툴링 
AWS 클라우드포메이션(AWS CloudFormation), 앤서블(Ansible), 셰프(Chef), 퍼핏(Puppet), 테라폼(Terraform) 등의 코드형 인프라 툴(Infrastructure-as-code tools)은 도커와 쿠버네티스의 호스팅에 쓰이는 기저 시스템을 제어한다. 이들 툴은 특정 수준의 시스템 복잡성을 요구하지만, 일정 시점이 되면 데브옵스 프로세스에서 절대적으로 필요해진다. 
 
가능한 한 모든 것을 자동화하라
일반적으로, 데스옵스의 임무는 개발과 운영을 결합되고 협업적인 시스템으로 통합하는 것이다. 이상은 최대한 자동화하는 것이고, 인간 개입이 적절할 때에는 언제든지 필수적인 작업을 반복 가능한 1회 클릭으로 실행하는 것이다. 

모든 프로젝트와 조직은 진행형이다. 소프트웨어의 성질을 감안한다면 변화는 언제나 기준의 이동과 연관된다. 그러나 거시적인 그림과 연관 툴을 적절히 이해할 수 있다면 변화와 변화에 따른 온갖 복잡성에 대처하는 계획을 세울 수 있을 것이다.

* Matthew Tyson는 다크 호즈 그룹의 설립자다. ciokr@idg.co.kr



2021.07.19

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

Matthew Tyson | InfoWorld
모든 데스옵스 시나리오에 적용할 수 있는 만능해답 같은 것은 없다. 하지만 이상적인 개발 과정과 툴체인을 묘사할 수는 있겠다. 여기 데브옵스의 각 조각이 어떻게 어울리고 조합될 수 있는지 살펴본다. 

데브옵스(Devops) 접근법는 개발 및 운영 활동을 아우르는 종합적인 관점을 취하고, 이들이 가장 효율적으로 상호작용할 수 있도록 조율한다. 하지만 이는 개념적 이상일 뿐이다. 기술적 관점에서 이상적인 데브옵스 풍경이란 무엇일까?

답은 ‘서술할 수 없다’이다. 신생 기업의 요구와 수백 명이 관여하면서 마이크로서비스 프로젝트를 시작하는 다국적 기업의 요구는 전혀 다르기 때문이다. 

그러나 증가하는 복잡성을 적절하게 흡수할 수 있는 이상적인 개발 흐름을 서술할 수는 있다. 또 아울러 CI/CD(지속적 통합/지속적 전달), 도커, 클라우드 컴퓨팅 같은 기술을 이 흐름에 접목하는 방식을 설명해볼 수 있다. 
 
Image Credit : Getty Images Bank

개발 : ‘내부의 고리’ 
한 개발자가 있다고 하자. 그는 소프트웨어를 당연히 수정할 것이고, 수정이 만족스럽다면 이를 버전 컨트롤로 커밋할 것이다. 버전 컨트롤은 소프트웨어 개발의 ‘내부 고리’와 데브옵스의 ‘외부 고리’ 사이의 접합 지점이다. 

개발자 커밋은 개발 브랜치, 기능 브랜치, 또는 (비공식적 환경에서) 메인 브랜치로 이어질 수 있다. 이상적으로는 자동화된 유닛 테스트의 실행이 있을 것이다. 이는 다양한 방식으로 일어날 수 있다. 프리-커밋 후크, 커밋 후크 등 선택지는 무한하다. 어쨌든 유닛 테스트를 통과하지 못하면 코드 변경은 브랜치로 수용되지 않는다. 

자동화된 테스팅 
일단 코드 변경이 수용되면 다음 단계는 ‘통합 테스트’다. 이는 지속적 통합(CI)에서 필수적이다. 다시 말해 코드는 계속적으로 더 큰 시스템에 통합되고 실행 환경에서 자동 및 수동 테스팅을 위해 전개된다.

자동화된 테스팅에는 한계가 없다. 모든 것이 가능하다. 셀레늄 스타일의 자동화된 UI 테스팅으로부터 정교한 로드 테스팅 스위트에 이르기까지 온갖 종류의 최신 자동화 툴이 소프트웨어를 완성하는 데 이용될 수 있다. 가끔은 자동화된 스모크 테스팅(automatedsmoke testing)이 테스트로 올라온 소프트웨어가 명목적으로 작용하고 있음을 보장한다. 

테스팅에 있어서 금과옥조가 있다면 ‘문제를 최대한 빨리 발견하라’이다. 

수작업 검증 테스트 
소프트웨어가 유닛 및 자동화된 통합 테스트를 통과했다면 이제 수작업 테스팅이 기다린다. 통상적으로 수작업 테스팅은 특정한 기능 및 수정 세트를 포착하는 특정한 분류 태그에 대해 이뤄진다. 프로덕션 환경으로 변경 사항을 적용시키는 데 있어 신중해야 하기 때문이다.

다시 말해 프로덕션 환경을 모방한 환경으로 소프트웨어를 배포하는 것이다. 여기서 소프트웨어는 수동으로 상호작용을 거치고, QA 담당자는 최선을 다해 문제를 찾으려 할 것이다. 문제를 발견하면 픽스가 병합될 수 있다. 

QA 담당자가 만족했다면 코드 패키지는 UA, 다시 말해 이용자 수용 테스팅(User Acceptance Testing)으로 올라갈 수 있다. 이는 여러 방식으로 이루어질 수 있지만, 핵심은 더 많은 사람들, 다시 말해 비즈니스 애널리스트, 여타 관계자들이 소프트웨어를 시험하는 것이다. 이들의 시험이 끝나면 소프트웨어는 비즈니스 현장, 즉 프로덕션에 투입될 준비가 된 것이다. 

프로덕션으로의 변경을 모니터링 
프로덕션으로의 변경의 경우 규모가 클수록 더 많은 검증 활동이 이루어진다. 동시에 새로운 단계, 즉 모니터링도 진행된다. 모니터링과 로깅은 전체 시스템이 제대로 작용하는 지를 확인하는 데 필수적이다. 이는 클라우드 시대에 커다란 개선을 이룬 또 하나의 분야이다. 다양한 로깅 및 모니터링 툴이 시중에 나와있다.

마이크로서비스의 영역에 있어서 프로덕션으로의 전개는 때에 따라 좀더 까다롭다. 마이크로서비스의 요소들이 단계적으로 전개될 수 있기 때문이다. 네트워크 트래픽은 갱신된 노드로 점증적으로 라우팅 되어 이들이 다른 컴포넌트와 의도한 대로 상호작용하는 지를 검증한다.  

데브옵스 내의 여러 역할 
이러한 프로세스를 바라보는 또 다른 방식은 사람이 하는 역할이다. 역할이란 사람들이 하는 업무이지 굳이 직함을 말하는 것은 아니다. 크게는 3가지 역할을 규정할 수 있다. 코드를 수정하는 사람, 코드의 유효성을 검사하는 사람, 실행 중인 시스템을 관리하는 사람이다. 

이들은 개발자, 테스터, 관리자라고 불린다. 

물론 자세히 들어가면 역할은 더 다양해진다. 예를 들어 새로운 코드 변경을 테스팅 하는 QA 엔지니어는 UA 서버 상의 요구사항을 검증하는 비즈니스 애널리스트와 전혀 다르다. 이들은 모니터를 구성하여 프로덕션 시스템이 특정 파라미터 내에서 실행되고 있는지를 검증하는 데브옵스 엔지니어와 전혀 다르다. 그러나 이들 활동은 거시적으로 코드가 의도대로 작용하는 지를 검증하는 것이다. 

이제 이러한 시각을 바탕으로 실무자가 업무에서 이용하는 특정한 툴에 대해 살펴본다.

컨테이너 : 개발-운영 결합 부분 
특히 많은 분야와 이어지는 기술이 컨테이너다. 실무적으로 도커를 의미한다. 도커가 런타임 니즈를 정의하는 전개 가능한 덩어리(컴포넌트)로 개발자의 소프트웨어를 분할할 수 있게 해준다. 따라서 개발자는 컨테이너 개발을 목표로 할 수 있고, 관리자는 컨테이너를 시스템 전반에 걸쳐 공통 분모로 이용할 수 있다.

컨테이너 수준에서 전개 가능한 유닛은 최고의 용량 및 수요 요건조차도 지탱하기에 충분하다. 쿠버네티스는 가장 인기 있는 컨테이너 클러스터 관리 시스템이 되었고, 단순한 기술은 아니지만 기능들은 인상적이다. 다시 말해 여러 지역 및 연동 서비스에 걸쳐 대형 클러스터를 관리할 수 있다.

- 컨테이너와 개발 
그러나 컨테이너화는 개발자의 ‘내부 고리’를 위한 손쉬운 수단은 아니다. 컨테이너가 코드, 빌드, 테스트 사이클에 복잡성을 추가하기 때문이다. 개발자가 ‘익스플로디드’ 개발 환경을 더 보편적으로 이용하는 이유이다. 여 환경에서 개발자는 컨테이너화되지 않은 로컬 환경에서 코드를 실행한다. 

유닛 테스트는 코드 품질에 있어서 개발자의 최전방 방어선이다. 어찌됐든 도커는 개발자를 위해 몇몇 측면을 더 단순하게 만들 수 있다. 예를 들어 몽고DB(MongoDB), 포스트그레SQL(PostgreSQL) 등의 데이터스토어의 표준화된 버전을 패키징 하면 개발자는 코딩 시 이를 쉽게 이용할 수 있다.  

- 컨테이너 및 테스트 데이터 
마찬가지로 도커 및 도커 컴포즈를 이용해 테스트 데이터로 데이터베이스를 시작한다면 이는 개발 환경에 혜택이 된다. 

따라서 도커는 데브옵스 환경을 통일하는 데 있어 핵심이고, 개발자에게 특정한 혜택을 제공하지만, 실제 코딩 작업에서는 임피던스 불일치가 있다. 

CI/CD 파이프라인 툴링 
이제 여러 요소를 데브옵스 파이프라인으로 연결하는 데 쓰일 수 있는 툴을 검토해보자. 많은 툴이 있다. 

- 스스로 실행하기 
가장 오래된 CI 서버는 젠킨스이고, 이는 여전히 인기가 있고 강력하다. 하지만 중대한 결함이 있다. 부실한 문서이다. 젠킨스와 무수한 젠킨스 플러그인을 이용해 거의 무엇이든지 할 수 있다. 그러나 이는 흔히 스스로 극복해야 하는 경험이다. 

젠킨스는, 흔히 클라우드 VM 상에서, 이용자가 스스로 설치하고 운영하는 서버이다. 그 후 이는 지휘자 역할을 한다. 깃허브 또는 다른 버전 관리 시스템 풀링, 빌드 및 테스트 실행, 도커 레지스트리와의 연동, 표적 환경으로의 전개 등이다. 최근의 솔루션에는 여러 SaaS 제품이 있다. 몇 가지를 살펴보자. 

- SaaS 선택지 
깃랩 CI/CD(GitLab CI/CD) 및 서클CI(CircleCI)는 인지도가 높은 최근의 지속적 통합 제품이다. 그렇다고 해서 이들이 이 인기 있는 시장에서 경쟁하는 유일한 업체라는 것은 전혀 아니다. 새로운 회사들이 편리하고 효과적으로 데브옵스 문제를 해결하기 위해 시장에 진입하고 있다. 안정된 회사인 제이프로그(JFrog)가 출시한 시퍼블(Shippable) 역시 인기가 높아지고 있는 새로운 선택지이다.

- 테스팅 툴 
테스팅 자동화 툴인 셀레늄(Selenium)은 CI 툴인 젠킨스의 자연스러운 후속작이다. 젠킨스와 마찬가지로 이용자 스스로 설치하고 구성하는 무료 오픈 소스 소프트웨어이다. 이는 앱피움(Appium)이나 여러 클라우드 공급업체의 SaaS 제품과 대조된다. 

CI/CD 분야와 마찬가지로 테스팅 역시 매우 활발한 시장이다. 

- 인프라 툴링 
AWS 클라우드포메이션(AWS CloudFormation), 앤서블(Ansible), 셰프(Chef), 퍼핏(Puppet), 테라폼(Terraform) 등의 코드형 인프라 툴(Infrastructure-as-code tools)은 도커와 쿠버네티스의 호스팅에 쓰이는 기저 시스템을 제어한다. 이들 툴은 특정 수준의 시스템 복잡성을 요구하지만, 일정 시점이 되면 데브옵스 프로세스에서 절대적으로 필요해진다. 
 
가능한 한 모든 것을 자동화하라
일반적으로, 데스옵스의 임무는 개발과 운영을 결합되고 협업적인 시스템으로 통합하는 것이다. 이상은 최대한 자동화하는 것이고, 인간 개입이 적절할 때에는 언제든지 필수적인 작업을 반복 가능한 1회 클릭으로 실행하는 것이다. 

모든 프로젝트와 조직은 진행형이다. 소프트웨어의 성질을 감안한다면 변화는 언제나 기준의 이동과 연관된다. 그러나 거시적인 그림과 연관 툴을 적절히 이해할 수 있다면 변화와 변화에 따른 온갖 복잡성에 대처하는 계획을 세울 수 있을 것이다.

* Matthew Tyson는 다크 호즈 그룹의 설립자다. ciokr@idg.co.kr

X