Offcanvas

How To / 개발자 / 디지털 트랜스포메이션 / 애플리케이션

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

2017.12.22 Isaac Sacolick  |  InfoWorld


코드 브랜칭 기준을 정립할 것
애자일 개발 관행의 가장 기초가 되는 것이 바로 코드를 버전 관리하고, 다양한 활동 경로로 개발을 브랜칭하며, 릴리즈 코드를 각각 별개의 테스트 및 생산 환경으로 나누어 패키징하는 능력이다.

지난 몇 년간 여러 도구의 성능은 눈에 띄게 개선되었으며, 많은 개발팀들이 과거에는 고급 소스 코드 관리라고 여겨졌던 것들을 기트(Git) 같은 툴을 사용하여 할 수 있게 되었다. 퍼포먼스가 우수한 애자일 팀일수록 이러한 툴을 활용하여 효율성을 증대시키고 각기 다른 개발 활동에 맞춘 유연한 개발 프로세스를 가능케 한다.

이러한 유연성의 핵심은 바로 코드를 파생(branch) 및 통합(merge)시키는 능력이다. 코드 파생은 여러 가지 비즈니스에 맞춘 개발 경로를 제공하여 개발자들이 독립적인 코드 카피에서 작업할 수 있다. 개발팀은 영구적, 일회성 파생 코드를 적절히 조합하여 필요에 따라 각 브랜치를 하나로 통합할 수 있다. 대부분 개발팀에는 개발, 테스팅, 생산을 지원할 표준 브랜치가 존재한다. 하지만 다음과 같은 것들을 지원하기 위한 일회성 브랜치를 생성할 수도 있다.

- 특정 기능을 자체적인 브랜치 내에서 개발하여 완성 후 나머지와 통합.

- 생산상의 문제를 해결해 개발 중인 코드를 편입시키지 않고 디플로이 해야 할 경우를 위한 패치

- 상당 수준의 코드 변경을 요하며, 각 테스팅이 생산 릴리즈를 위해 충분히 준비가 될 때까지 별개의 브랜치에서 이루어 질 수 있도록 하는 컴포넌트 또는 아키텍쳐 업그레이드.

코드리뷰 제도화를 통한 퀄리티 및 개발자 협업 개선
기트와 같은 소스 코드 매니지먼트 툴의 또 다른 특징은 코드 리뷰를 형식화 한다는 것이다. 기트에서 개발자들은 주로 개발 또는 기능 브랜치에서 작업하며 필요에 따라, 혹은 정책에 맞춰 코드를 만든다. 코드가 완성되면, 개발자의 풀(pull) 요청을 통해 이러한 변경 사항들이 개발 브랜치나 기능 브랜치에서 나와 테스팅 브랜치로 옮겨 간다. 두 번째 개발자가 이러한 풀 요청을 테스팅에 통합한다.

이러한 협업 프로세스는 개발자들로 하여금 브랜치 통합 전에 코드 리뷰를 할 수 있게 한다. 코드 리뷰를 통해 안 좋은 코드나 표준에 맞지 않는 코드를 골라 낼 수도 있겠지만, 동료가 코드를 이해하고 읽을 수 있도록 하기 위해 지식 이전을 가능케 하기도 한다. 이는 특히 팀 멤버들 간에 책임을 공유하고 시니어 개발자들이 주니어 개발자들의 멘토가 되어주는 애자일 개발 방법론에서는 더 중요하다.

지속적인 통합 및 딜리버리 이행
애자일 팀이 프로세스 효율성과 퀄리티를 높이기 위해 다음으로 하는 일이 바로 코드 패키징 및 런타임 환경으로의 딜리버리 방식의 자동화를 손 보는 것이다.

과거 많은 애플리케이션의 제작 및 딜리버리가 수동적으로 각 단계를 거쳐 진행됐다. 개발자가 통합 개발 환경(integrated development environment, IDE)에서 한 단계를 진행한 후, 그 아웃풋을 스크립트를 이용하여 패키징 한다. 그리고 그 파일을 저장소에 FTP하여 승인된 변경 요청을 받은 오퍼레이션팀 직원이 여러 단계를 거쳐 해당 코드를 타깃 런타임 환경으로 전달한다.

이러한 수동 프로세스는 에러에 취약할 뿐 아니라 변경 사항을 주기적으로 생산 환경에 디플로이 하고자 하는 비즈니스에도, 테크놀로지팀에게도 비효율적이다.

이러한 단계들을 자동화 하는 것이 하나의 솔루션이 될 수 있다. 개발팀과 오퍼레이션팀이 협업하여 애질리티 및 오퍼레이션 상의 안정성을 개선하면, 데브옵스가 등장한다. 주요 데브옵스 관행은 아래와 같다.

- 브랜치 통합이 빈번하며 애플리케이션 빌드 프로세스가 자동화 된 지속적 통합 (continuous integration, CI)

- 버튼 한 번 누르는 것으로 선택된 런타임 환경으로 소프트웨어를 푸시하는 지속적 전달(continuous delivery, CD)

지속적 통합 및 딜리버리(CI/CD)에는 자동화 된 테스팅이 필요하다. CI/CD는 릴리즈 매니지먼트 전략(release management strategy)의 일환으로 모든 기관들에서 애자일 개발 프로세스의 일환으로 정립해야 하는 전략이다. 코드 디플로이를 원하는 앞선 개발 기관들일수록 더 빈번하게(하루에 한 번, 혹은 그 이상으로 자주) 지속적 디플로이먼트를 선택한다.

자동화와 프로세스 개선을 위한 애자일 이용
이런 식의 자동화나 협업이 가능하다는 것이 마법처럼 들릴 수도 있지만, 분명한 것은 이런 성과가 결코 하루 아침에 이루어진 것이 아니라는 사실이다. 오랜 시간에 걸쳐, 그것도 많은 비즈니스 문제들에 대처하고 해결하려 노력한 끝에 얻어진 결과물일 것이다.

가장 좋은 시작점은 우선 이러한 솔루션을 도입했을 때 소비자에게 미치게 될 영향이다. 자동화 및 협업 니즈를 사용자 시나리오로써 구체화 하고 그 디플로이먼트를 백로그에 우선 순위화 하여 소프트웨어 개발 프로젝트처럼 관리해야 한다. 그렇게 함으로써 이러한 솔루션의 이행을 시작하고 향후 개선 사항들을 위한 로드맵을 그릴 수 있게 될 것이다.

* Isaac Sacolick은 애자일과 데브옵스, 데이터 과학 분야를 주로 다루는 전문 기고가다. 스타CIO의 대표이자 CIO닷컴 등에서 오랜 기간 블로거로 활약해왔다. ciokr@idg.co.kr

 

CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

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

Copyright © 2024 International Data Group. All rights reserved.