2023년 프로그래머스에서 진행한 개발자 설문조사 리포트 를 보면, 직무별 평균 연소득에 데브옵스(DevOps)가 2위에 랭크되어 있는 것을 확인할 수 있다. 데브옵스라는 직무는 무엇이길래 이렇게 평균 연소득이 높은 것일까? 또, 데브옵스는 왜 이렇게 많은 사람들이 관심을 가지고 있을까? 

[그림1. 인프런 강의 포탈화면]

위키피디아에 따르면, 데브옵스에 대한 설명은 아래와 같다. 

“데브옵스는 개발(Dev)과 운영(Ops)의 합성어로, 소프트웨어 개발과 인프라의 운영 및 관리를 통합하여 속도와 효율성을 높이는 방법론을 말합니다. 데브옵스의 핵심은 개발팀과 운영팀 사이의 소통과 협업을 강조하는 것입니다. 이를 통해 소프트웨어를 보다 빠르게 개발하고 배포할 수 있으며, 이는 기업이 시장 변화에 빠르게 대응하고 비즈니스 가치를 제공하는 데 도움을 준다. 

데브옵스는 일반적으로 클라우드 컴퓨팅, 자동화, 지속적인 통합(Continuous Integration), 지속적인 배포(Continuous Deployment)등과 같은 다양한 기술과 방법론을 포함한다. 이는 문화적인 변화를 의미하며, 팀 간의 장벽을 제거하고 공동의 목표를 달성하기 위해 함께 일하는 환경을 조성하는 것을 목표로 한다.” 결국 데브옵스는 개발(Development)과 운영(Operations)을 같이하는 사람이라고 하는 것도 맞지만, 이는 직무에서 한정된 정의일 뿐이고, 조금 더 정확하게는 데브옵스 엔지니어가 맞는 말이다. 또, 데브옵스도 ’방법론’의 한 종류이기 때문에 일종의 패러다임이나 문화에 가깝다고 볼 수 있다. 

STEG에서는 DevOps의 중요성을 항상 강조하고 있고, RC카페에 올라와 있는 『Dev+Ops = E-GENE 노코드플랫폼』[1]이라는 글을 통해 이진 노코드플랫폼이 DevOps의 전 생명주기를 지원하고 있음을 강조하고 있다. 그렇다면 DevOps의 생명주기란 무엇일까? [1] https://cafe.naver.com/stegrnd/1396 DevOps의 생명주기 DevOps의 생명주기는 보통 계획, 개발, 빌드, 테스트라는 Dev의 4가지 단계와 릴리즈, 배포, 운영, 모니터링이라는 Ops의 4가지 단계가 합쳐진 8단계로 구성되어 있다. 

[그림2. 데브옵스의 8단계 생명주기]

[그림2]의 각 생명주기를 지원하기 위해서 여러 툴들이 존재한다. 생명주기별 대표적인 툴은 다음과 같다. 

“계획” 단계에서는 redmine, jira, asana라는 이슈트래커, pms같은 협업과 일감을 관리해주는 툴들이 있고, “개발” 단계에서는 버전 관리를 하거나 코드를 만드는 git, eclipse, intelliJ이, “빌드” 단계에서는 maven, gradle같은 패키징 툴이 있고, “테스트” 단계에서는 sonarQube, jacoco, apache jmeter등의 테스팅 툴, “릴리즈” 단계에서는 docker와 같은 컨테이너 툴, “배포” 단계에서는 aws ecs같은 컨테이너 오케스트레이션 툴, “운영” 단계에서는 k8s와 같은 인프라 툴, 마지막으로 “모니터링” 단계에서는 kibana, grafana, Prometheus등의 APM/모니터링 툴이 존재한다.

이 툴들은 유기적으로 각 단계를 지원하여 아래와 같은 무한대(∞)의 끊임없는 데브옵스 생명주기를 형성하는 데 도움을 준다. 

[그림3. 유기적으로 순환하는 dev-ops의 생명주기]

그러나 시간이 지나면서, 위의 생명주기들의 경계가 모호해지고 있다. 이에 따라 각 생명주기를 지원했던 툴들도 하나의 생명주기만 서포트하는 툴이 아닌, 일련의 과정들을 상호 서포트하는 툴로서 발전해 나가고 있는 추세이다. 

조금 더 자세히 알아보자. 먼저, CI/CD를 예로 들 수 있다. CI는 자동화된 빌드 및 테스트가 수행된 후, 개발자가 코드 변경 사항을 중앙 repository에 정기적으로 병합하는 소프트웨어 개발 방식으로, 버그를 신속하게 찾아 해결하고, S/W 품질을 개선하고, 새로운 S/W 업데이트를 검증 및 릴리즈하는데 걸리는 시간을 단축한다. 또한 아래에서 설명할 MSA 아키텍처에서 기능 간 상호작용에서 일어날 수 있는 여러 Conflict들을 방지하는 기능을 제공한다. CD는 프로덕션에 릴리즈하기 위한 코드 변경이 자동으로 빌드, 테스트 및 준비되는 소프트웨어 개발 방식으로, 적절하게 구현된 CI를 토대로 개발자는 언제나 빠른 배포나 표준화된 테스트 프로세스를 통과한 빌드 아티팩트를 보유하게 된다. 

또한 이 과정을 지원하기 위해 Github Action, Jenkins, Travis CI등의 툴이 제공된다. 또한, 모놀리식 아키텍처의 한계를 극복하기 위한 MSA(마이크로서비스 아키텍처)도 있다. 마이크로 서비스 아키텍처는 단일 애플리케이션을 작은 서비스의 집합으로 구축하는 설계 접근 방식이다. 각 서비스는 자체 프로세스에서 실행되고, 주로 HTTP 기반 API(애플리케이션 프로그래밍 인터페이스)라는 간편한 메커니즘을 사용하는 잘 정의된 인터페이스를 통해 다른 서비스와 통신한다. 마이크로 서비스는 비즈니스 기능을 중심으로 구축되며, 각 서비스는 단일 목적으로 한정되어 있다. 

다양한 프레임워크 또는 프로그래밍 언어를 사용하여 마이크로 서비스를 작성하고, 이를 독립적으로 단일 서비스 또는 서비스 그룹으로 배포할 수 있다. 또한 MSA는 DevOps와 상호보완적인 관계에 있다. MSA는 각각의 마이크로서비스가 독립적으로 개발되고 배포될수 있게 하는데, 이 복잡성을 DevOps가 관리한다. 결국 앞서 언급했던 『Dev+Ops = E-GENE 노코드플랫폼』의 글 내용처럼, E-GENE framework 위에서 portal과 console로 DevOps의 모든 생명주기를 관리하는 것이 STEG의 목표라고 볼 수 있다. 

컴플라이언스 관점에서도 『주식회사등의 외부감사에 관한 법률』 (이하 외감법)과 정보기술 일반통제의 요구사항으로 인해 IT기업이 아닌 일반 기업에도 IT서비스의 관리와 통제를 위해 ITSM의 도입이 필수적으로 요구되기에, 기업의 입장에서도 컴플라이언스 대응을 위해 No-Code 기반의 ITSM도입을 통한 대응이 훨씬 더 비용절감이 된다. 이를 위해 현재 STEG에서는 Wizard, Builder, UI Designer 등의 개발자가 아니어도 쉽게 다룰 수 있는 도구들을 지원하고 있다. 

[그림 4. E-GENE에서 지원하는 DevOps]

DevOps의 각 단계를 효과적으로 운영하기 위해서는 각 단계별 도구와 프로세스가 유기적으로 결합되어야 한다. 그러나 DevOps가 목표로 하는 지속적 통합과 배포를 달성하기 위해서는 각 단계가 단순하게 독립적으로 작동하는 것을 넘어, 계획 단계에서부터 팀 간의 협업과 빠른 피드백이 필수적이다. 특히, 변화하는 요구사항에 유연하게 대응하기 위해서는 기존의 순차적 접근 방식인 워터폴(Waterfall) 방법론으로는 한계가 있다. 

E-GENE PMS와 애자일 방법론 이를 보완하기 위해 등장한 방법론이 ‘애자일 방법론’으로, 전통적인 워터폴 방식과 달리 요구사항의 변화를 수용하고 빠른 피드백을 제공하는데 최적화되어 있다. 워터폴 방식은 건축과 같이 한번 설계를 시작하면 되돌릴 수 없는 구조물에 적합하다. 그러나 소프트웨어 개발은 이와 다르게 수정과 개선이 용이하다. 

Kent Beck의 저서 XP(Extreme Programming)에서는 이러한 점을 강조하며, 애자일이 소프트웨어 개발에서 필수적인 접근 방식임을 설명하고 있다. 그렇다면 애자일 방법론이란 무엇일까? 먼저, 애자일 방법론에 대한 정의는 아래와 같다. “애자일은 소프트웨어의 개발 방식 중 하나로, 일정한 주기를 가지고 끊임없이 프로토타입을 만들어 내며 때에 따라 필요한 요구를 더하고 수정하여 하나의 커다란 소프트웨어를 개발해 나가는 방법론이다.

” RC카페에 게시되어 있는 『NCLC 애자일 방법론에 발맞춰 나아가는 E-GENE 솔루션』 [1]이라는 기고문을 토대로 전통적인 Waterfall방식과 STEG에서 지원하는 NCLC(No-Code-Low-Code) Agile Model의 설명을 보면, 애자일 방법론과 워터폴 방법론 모두 요구사항(Requirements), 설계(Design), 구현(Requirements), 테스트(Testing), 이행(Deployment)의 5가지 순차적인 절차를 지니고 있지만, 가장 큰 차이는 워터폴 방법론이 일방적인 흐름을 지니는 데 반해 애자일 방법론 모델은 순환적인 흐름을 지니고 있다. 

워터폴 방식은 애자일 방식보다 ‘요구사항이 불변이거나 거의 없을 때’, ‘프로젝트의 전체 일정이 고정됐을 때’, ‘상세한 문서화가 필요할 때’인 상황에서 효과적이다. 그러나 현대의 프로젝트 상황에서는 요구사항이 바뀌는 경우가 대부분이기 때문에, 현재 거의 대부분의 기업에서는 Agile방식을 채택해야 한다고 볼 수 있다. 

[그림 5. 워터폴 방법론과 대비되는 E-GENE의 애자일 방법론 모델]

애자일 방법론의 핵심은 ‘고객의 요구사항에 대한 빠른 반응과 요구사항의 변동에 맞는 지속적인 개선’이기 때문에 애자일 방법론으로 빠르게 개발된 소프트웨어는 DevOps의 원칙에 따라 효과적으로 테스트, 배포, 모니터링 될 수 있고, STEG에서는 E-GENE에 탑재된 PMS 모듈로써 이를 지원하고 있다. 애자일 방법론을 활용하여 어떻게 빠른 피드백을 통한 지속적인 개선이 될 수 있을까? 바로 애자일 프로세스의 핵심 단위인 ‘스프린트’를 통해서이다. 

스프린트를 통해 개발 프로세스의 주기를 짧게 가져가고, 스프린트가 끝나면 피드백을 받아 즉시 반영하고, 또 새로운 스프린트를 구성하며 지속적인 개선을 이루어 나간다. 또한, 최근 소프트웨어 개발에서 복잡한 도메인을 소프트웨어에 녹여내기 위해 중요한 개념으로 자리잡은 DDD(Domain-Driven Design)패턴 역시 Dev-Ops와 애자일 방법론을 연결하는 중요한 역할을 한다. DDD는 개발자와 도메인 전문가가 동일한 언어(Ubiquitous Language)를 사용해 협업함으로써, 복잡한 도메인 요구사항을 효과적으로 구현하는데 초점을 맞춘다. 

이러한 협업 모델은 반복적이고 점진적인 개선을 지향하는 애자일 프로세스, 특히 스프린트와 스크럼의 구조와 매우 잘 맞는다. ’단거리’를 의미하는 스프린트처럼, 애자일 방법론에서의 스프린트는 프로젝트를 작은 단위로 나눈 시간 기한을 의미한다. 보통은 1~4주로 설정되지만, 이 기간 안에 개발 팀은 정해진 일정의 작업을 완료해야 한다. 스프린트 기간은 프로젝트의 전체 기간 동안 일정하게 유지되어야 하며, 각 스프린트는 명확한 목표와 결과물을 가지고 있어야 한다. 프로젝트가 ‘장거리 달리기’라면, 스프린트는 이 장거리 달리기를 구간별로 나눈 ‘단거리 달리기’라 볼 수 있다. 그러나 단거리 달리기에서는 달리기만 하는 것이 아니라, ‘결과물을 내는 것’이 핵심이라고 할 수 있다. 

그렇다면, 스프린트와 함께 애자일 방법론에서 항상 등장하는 ‘스크럼’이란 무엇일까? 

스크럼은 팀이 자체적으로 조직하고 일반적인 목표를 달성하도록 협업하기 위한 ‘프레임워크’다. 이를 통해 효율적인 프로젝트 전달을 위한 일련의 회의, 도구, 역할이 설명된다. 소프트웨어 팀은 스크럼을 사용해 복잡한 문제를 비용 효율적이며 지속적으로 해결할 수 있다. 요약하자면, 스크럼은 ‘스프린트’라는 정해진 기간 내에 고객 가치를 제공하는 자체 조직화 팀이라고 볼 수 있다. 

따라서, 애자일 방법론을 통해 프로젝트 팀은 스프린트를 나누고, 스크럼으로 팀을 구성하여 이 스프린트에서 협력을 통해 명확한 목표와 결과물을 제시하는 것이 애자일 방법론의 중점이다. 스크럼 팀은 보통 스크럼 리더, 프로덕트 담당자, 그리고 개발 팀으로 이루어져 있으며, 스프린트 내 정기적인 미팅(일일 스크럼, 스프린트 리뷰, 스프린트 계획, 스크럼 회고)등으로 상호 소통하고 협력한다. 

스크럼과 관련해서, 중요한 개념이 몇 개 등장하는데, 바로 일일 스크럼과 백로그다. 일일 스크럼이란, 매일매일 스크럼 팀을 짜는 것이 아니라 스크럼 팀에서 진행하는 15분 내외의 짧은 미팅을 말한다. 이 미팅에서는 각 팀원이 자신의 작업 상황을 공유하고, 그날의 작업 목표를 설정한다.

일일 스크럼에서는 보통 다음과 같은 3가지 질의응답에 대해 발표한다.

• 어제 무엇을 했는가(진행한 작업에 대한 보고)
• 오늘 무엇을 할 것인가(계획하는 작업에 대한 공유)
• 어떤 장애물이 있는가(문제점이나 도움이 필요한 부분 공유)

백로그는 크게 2가지로 나눌 수 있는데, 제품 백로그와 스프린트 백로그로 나눌 수 있다. 제품 백로그는 프로젝트가 성공하기 위해 완수해야 하는 기능, 요구사항, 개선사항 및 수정사항의 동적 목록으로, 요약하자면 ‘팀의 할 일 목록’이다. 

스크럼 팀의 프로덕트 담당자는 이 프로덕트 백로그의 관련 없는 항목을 제거하거나 고객의 새 요청을 추가해서 목록을 유지관리하고 업데이트 해야 한다. 스프린트 백로그는 개발 팀이 현재 스프린트 주기에서 완료해야 하는 항목의 목록이다. 스프린트 팀은 제품 백로그에서 작업할 항목을 선택한다. 스프린트 백로그는 유연하고, 스프린트 도중 변경될 수 있다. 

결국 제품 백로그는 전체 제품의 ‘미래’에 대해 나타내고, 스프린트 백로그는 ‘현재’ 팀이 집중해야 할 작업들을 구체화하여 나타낸다. 많은 사람들이 백로그와 관련한 개념이 나오면 백로그와 이슈의 차이점에 대해 굉장히 많이 헷갈려 한다. 그러나 ‘일의 종류와 우선순위’에 대해서 생각해보면 헷갈릴 필요가 없다. 이슈는 프로젝트 진행 중 발생하는 버그, 문제점, 질문 등을 의미한다. 

이슈는 보통 실시간으로 처리해야 하는 일로 인식된다. 백로그는 프로젝트에서 처리해야 할 모든 작업들을 포함하는 목록이다. 백로그는 프로젝트의 미래 계획을 나타내고, 이슈와는 달리 스프린트나 다른 개발 주기에 따라 계획되고 수행된다. 현재는 미래에 포함되므로, 이슈 또한 백로그에 포함된다. 

다만 프로젝트 팀은 이슈와 백로그를 구분지을 수도, 이슈를 최우선 백로그로 설정할 수도 있다. PMS마다 이슈와 백로그를 다르게 정의할 수도 있기 때문에, 이를 합쳐 ‘작업’으로 정의하는 경우도 많다. E-GENE PMS는 기존 개발된 Collabo PMS와 IT PMS를 통해 통상의 프로젝트 및 간소화방법론 등의 다양한 방법론을 통한 프로젝트를 효율적으로 진행할 수 있게끔 지원하고 있다. 

물론 기존의 IT PMS에서도 애자일 방법론을 통한 프로젝트를 지원하고 있었지만 2024년 5월 새로이 개발된 Agile PMS를 통해 상기 기술된 애자일 프로세스를 지원하며, 프로젝트를 효과적으로 진행하고 발전해 나갈 수 있는 DevOps의 발판을 제공하여 [그림 4]의 DevOps 생명주기를 완성한다.

먼저, 마일스톤, 프로덕트 백로그, 스프린트 등의 순차적 메뉴 배치로 사용자로 하여금 애자일 프로세스에 능숙하지 않아도 애자일스러운 프로젝트를 수행할 수 있게 한다. 또한, 회사마다 다른 애자일 프로세스를 고려하여 표준화된 애자일 프로세스만을 구현하되 사용자화(Personalized)하여 사용할 수

 있게끔 구조를 개선하였다.

[그림 6. E-GENE Agile PMS]

이제 더이상 현대 소프트웨어 개발에서 DevOps와 애자일 방법론은 선택이 아닌, 필수가 되었다. 

E-GENE PMS는 이러한 흐름에 맞추어 민첩하고 효율적인 방안으로 이를 지원해야 한다. 먼저, 클라이언트의 요구사항 변동을 실시간으로 수용할 수 있는 매니징 툴이 될 수 있게끔 변화하는 요구사항을 빠르게 반영할 수 있게 지원하는 것이 핵심이어야 한다.

 또한, 스프린트 동안의 성과를 측정 및 분석할 수 있는 지표를 제공하여, 팀이 스프린트 목표를 얼마나 달성했는지 평가할 수 있는 기준을 지원해야 한다. 이는 스프린트 회고 시 개선점을 도출하고, 다음 스프린트를 더욱 효율적으로 계획하는 데 도움을 준다. 마지막으로, 스프린트 기간 동안 팀의 집중도를 유지하기 위해, 불필요한 작업이나 간섭을 최소화하고 편의성을 높이는 기능을 제공해야 한다. 

E-GENE PMS는 이러한 방향으로 진화함으로써 DevOps와 애자일 방법론의 핵심을 실현하고, 복잡한 프로젝트 환경에서도 효율성을 극대화하는 모듈로 자리잡을 수 있을 것이다. 

에스티이지/R&D/조영준 프로