[칼럼] 企業에 CI/CD가 必要한 10가지 理由

이제는 企業이 提供하는 모든 製品, 서비스에서 소프트웨어를 分離할 수 없는 時代이다. 競爭業體와 顧客들, 投資者 및 職員들 모두 會社에서 만든 製品에 定期的으로 업데이트되는 소프트웨어를 要求하고 있다.

따라서 이러한 現實(및 데브옵스(DevOps))을 直視하고, 可能한 가장 效率的인 持續的인 統合 및 提供 파이프라인을 만드는 데 投資해야 한다. 이러한 戰略을 經營陣에게 어떻게 說得해야 할까? 먼저 競爭社를 言及하는 것으로 始作할 수 있다. 競爭社들은 이미 持續的인 統合 및 持續的인 提供(CI/CD: Continuous Integration/Continous Delivery)을 活用하고 있을 可能性이 높다. 萬若 그래도 더 具體的으로 說得할 理由가 必要하다면, 企業에 CI/CD가 必要한 10가지 理由를 提示하면 된다.

CI/CD는 무엇인가?

CI/CD는 自動化 機能을 使用하여 코드 開發 및 提供을 劃期的으로 簡素化할 수 있는 2段階의 프로세스다. 먼저 CI는 소스 코드 統合 및 버전 管理 等의 開發者 作業을 보다 效率的으로 遂行할 수 있도록 함으로써 소프트웨어를 보다 迅速하게 運營環境에 配置할 수 있도록 해주는 事前 段階다. 여러 開發者가 同時에 애플리케이션 開發 關聯 코딩을 하더라도, 새로운 코드 變更 事項들이 빌드(컴파일) 및 테스트되어 定期的으로 共有 리포지토리(情報 貯藏所)에 統合된다. 따라서 모든 開發이 終了된 時點부터 코드 品質 管理를 始作했던 旣存 方式의 短點(테스트 時 豫想치 못한 衝突 發生)李 解消된다.

CI의 다음 作業으로 CD는 소프트웨어 테스트 및 配布를 自動化한다. 嚴密히 區分하면 이 CD는 2가지로 나뉜다. 먼저 持續的인 提供(Continuous Delivery)을 통해 CI에서 有效性 檢證이 끝난 코드들을 貯藏所에 自動으로 릴리스 한다. 이를 통해 運營팀은 變更된 코드들을 貯藏所에서 가져와서 애플리케이션(프로덕션 環境)에 手動으로 配布할 수 있게 된다. 開發팀과 運營팀 사이에 意思疏通이 좀 더 원활해지는 것이 長點이다.

最終 段階는 持續的인 配布(Continuous Deployment)다. 卽, 소프트웨어의 變更 事項이 테스트를 通過하자마자 自動으로 最終 使用者에게 配布된다. 따라서 使用者의 피드백도 卽刻 反映하기 쉬워진다.

하나로 이어진 CI/CD 파이프라인을 想像하면 쉽다. 開發者들이 코드를 持續的으로 빌드 및 테스트를 하며, 檢證된 소스는 卽時 애플리케이션으로 使用者에게 排布가 되는 것이다. 이처럼 CI/CD가 結合되면, 强力한 最新 소프트웨어 開發 엔진이 되며, 이는 企業들에게 엄청난 利點을 提供한다.

CI/CD는 비즈니스에 어떠한 利點을 提供하는가?

CI/CD는 비즈니스에 수많은 利點을 提供한다. CI/CD를 採擇해야 하는 10가지 理由는 다음과 같다.

? 卓越한 코드 品質 保障

깃랩의 2021年 글로벌 데브섹옵스 設問調査(Global DevSecOps Survey) 參加者들은 데브옵스를 遂行해야 하는 가장 큰 理由는 코드 品質을 爲한 것이며, 데브옵스를 위해 팀에 가장 必要한 프로세스는 CI/CD라고 應答했다. CI/CD 파이프라인은 테스트 自動化를 提供하기 때문에 開發者들은 거의 實時間으로 코드 問題를 把握할 수 있다. 이러한 ‘迅速한 誤謬 解決(Failing Fast)’ 槪念을 통해 팀은 버그가 있는 코드로 인해 時間이나 資源을 浪費하지 않아도 되고, 開發者는 다른 프로젝트를 驅動할 때 끝없는 ‘修正’ 要請에 시달리지 않아도 된다. 時間과 費用을 節約할 수 있으며, 오로지 코딩에만 集中할 수 있다.

? 릴리스 速度를 短縮하여 더 迅速하게 提供

CI/CD 이點에 對해 더 궁금한 사람이라면 글로벌 金融會社인 골드만삭스(Goldman Sachs)의 成功事例를 살펴보는 것이 좋다. 이 會社의 技術 部署는 2週 마다 1個의 코드를 빌드했지만, 以後 하루 1,000個 以上으로 늘어났다. 統合 CI/CD 파이프라인은 소프트웨어 릴리스 速度를 높이는 데 있어 터보 엔진과도 같다. 코드를 더 빨리 릴리스하고, 더 많은 새로운 코드를 開發할 수 있게 됨에 따라 끝없이 릴리스가 可能하다. 成功的으로 CI/CD 파이프라인이 作動하면, 結局 企業 次元에서도 高費用의 開發者 리소스를 最大限 活用할 수 있어 利得을 얻을 수 있다.

? CI/CD 파이프라인: 自動化로 費用 節減

소프트웨어 開發 프로세스에 사람의 介入이 必要 없게 되면, 時間과 費用을 節減할 수 있다. 이러한 理由로 成功的인 데브옵스 遂行事例의 土臺는 바로 自動化다. CI/CD는 핸드오프(作業者 變更: 開發 協業 中 어떤 사람이 다른 同僚에게 다양한 業務 關聯 情報 또는 責任을 移轉하는 것. 例를 들어, 顧客이 營業 社員에게 니즈를 正確히 言及한다. 營業 社員은 이를 開發者에게, 開發者는 테스터에게, 테스터는 運營팀에게 알리게 되는 데 各 段階마다 元來의 情報가 損失된다.), 소스 코드 管理, 버전制御 시스템 및 配布 메커니즘은 勿論, 많은 테스트 機能을 自動化한다.

이 中에서도 테스트가 가장 重要하다. 2021年 깃랩 設問調査에 따르면, 테스트가 릴리스 遲延의 가장 큰 原因으로 確認되었다. 遲延된 릴리스는 費用과 브랜딩, 弘報 및 評判 等의 側面에서 비즈니스에 影響을 미칠 뿐만 아니라 迅速한 市場 出市에 依存하는 企業에게는 致命的이다. 傳統的으로 소프트웨어 테스트는 手動으로 進行되었고, 엄청나게 많은 時間이 所要되었기 때문에 企業들은 1年에 한두 番 程度만 새로운 코드를 릴리스 하는 境遇가 많았다. 反面 오늘날 企業들은 常時 릴리스가 可能해야 하며, 이를 위해서는 自動化된 소프트웨어 테스트가 매우 重要하다.

? 誤謬 隔離

소프트웨어 開發 分野에서 데브옵스 및 CI/CD가 注目받기 前에는, 開發팀이 코드에 問題가 있다는 것을 알아도 問題가 發生한 正確한 位置를 把握하는 데는 어려움을 겪었다. 그런데 CI/CD와 自動化된 테스트로 인해 狀況이 달라졌다. 開發者는 코드 誤謬를 쉽게 識別한 다음, 이를 隔離함으로써 生産性을 크게 向上시킬 수 있게 되었다.

? 簡素化된 롤백(以前 버전 되돌리기)

開發者는 CI/CD 파이프라인을 통해 誤謬를 迅速하게 解決하고, 훨씬 더 빠르게 復舊할 수 있다. 이는 코드를 運營環境으로 轉換하고, 問題가 있으면 롤백하면 되는 簡單한 프로세스이다. 코드를 쉽게 롤백할 수 있는 機能은 팀의 時間과 에너지, 리소스를 節約하고, 問題가 있는 코드를 보다 迅速하게 修正할 수 있도록 해준다.

? 持續的인 피드백

데브옵스 플랫폼의 一部로 動作하는 統合 CI/CD 프로세스는 비즈니스 利害關係者들을 비롯해 팀의 모든 사람들이 무슨 일이 일어나고, 어디에서 일어나는지, 그리고 무엇이 잘못되었는지 確認할 수 있는 方法을 提供한다. 이것은 單純한 것처럼 들릴 수 있지만, 實際로 소프트웨어 開發에서의 싱글 윈도우(現況을 한 곳에서 把握하는 方式)는 거의 革新的이라 할 수 있다.

過去에는 使用하는 툴이 너무 많았기 때문에 프로젝트 管理者가 여러 部分들을 살펴봐야 했고, 여러 사람들에게 狀態 업데이트를 要請해야 했다. 이러한 狀況에서 開發者와 運營 專門家들은 더 나은 結果를 얻지 못했고, 特히 問題가 發生하면, 이는 時間과 리소스 浪費를 招來했다.

? 最適의 透明性과 責任性

CI/CD 파이프라인은 持續的인 피드백을 통해 全體 소프트웨어 開發 프로세스를 비즈니스 側面에서 完全히 透明하게 處理한다. 製品 管理者는 프로젝트 狀態를 한 눈에 確認하고, 必要에 따라 責任 素材를 追跡할 수 있다.

? MTTR(Mean Time to Resolution, 平均 解決 時間) 改善

CI/CD 파이프라인이 提供하는 可視性 德分에 데브옵스 팀은 問題를 迅速하게 把握하고, 빠르게 解決할 수 있다. 問題를 迅速하게 解決하는 能力은 核心 開發 指標인 MTTR(Mean Time to Resolution)의 主要 要素이다. MTTR이 좋을수록 데브옵스 팀은 더욱 效率的으로 作業하고, 더 빨리 소프트웨어를 出市할 수 있으며, 이러한 MTTR은 비즈니스 收益에 直接的인 影響을 미친다.

? Metrics(指標) 데이터 모니터링

팀과 비즈니스 側面에서는 코드가 實際 環境에서 어떻게 動作하는지 알아야 하지만, 旣存 소프트웨어 開發 遂行事例에서는 이를 모니터링할 만한 統計 指標가 없는 境遇가 많았다.(예를 들어 데브옵스 現況을 把握하는 데 도움을 주는 指標에는 리드 타임, 配布 頻度, 變更 失敗率, 平均 復舊 時間 等이 있다.) 理想的인 環境이라면 팀이 먼저 코드 問題를 把握하고, 最終 使用者가 이를 認識하기 훨씬 前에 롤백할 수 있어야 한다. CI/CD 파이프라인은 다양한 指標에 對한 持續的인 피드백을 提供하여 理想的인 環境을 實現할 수 있다. 제대로 動作하지 않는 버그가 많은 코드 및 애플리케이션을 願하는 企業은 없기 때문에 이러한 指標 데이터에 對한 액세스는 單純히 時間만 節約하는데 그치지 않는다.

? 白鷺그의 重要하지 않은 缺陷 減少

CI/CD는 時間과 費用을 節減시켜준다. 이에 開發者는 時間이 不足하여 그동안 修正할 수 없었던 오래된 코드들을 더 明確하고 效率的으로 만드는 作業이 可能하게 됐다. 卽 開發者들이 旣存에 處理하기 곤란했던 白鷺그(結局 누가 時間을 따로 낼 수 있는 가의 理由로 白鷺그라고 부른다.) 및 些少한 缺陷에 對해서도 作業할 수 있다는 아이디어는 데브옵스와 CI/CD가 팀에 가져온 게임 체인저이다.

IT 企業 顧客社의 經營陣들이 많이들 궁금해하는 部分 中 하나가 바로 CI/CD의 重要性이다. CI/CD를 導入하게 되면 開發부터 애플리케이션 配布까지의 過程이 迅速하다. 코드 빌드의 回數도 많은 데 同時에 保安 테스팅과 使用者의 피드백까지 反映된다.

또다른 長點도 紹介하며 이 글을 마치고자 한다. 最近 java의 빈틈을 노려서 Log4j라는 컴퓨터 歷史上 最惡의 脆弱點 攻擊이 發生한 적이 있다. CI/CD 파이프라인이 없는 企業들은 ‘어느 地點’李 攻擊 當했는 지 把握하기도 쉽지 않았던 反面에, 미리 構築했던 企業들의 境遇 迅速하게 把握 後, 從屬性(Dependency) 項目의 脆弱點에 빠르게 對應이 可能했다. 正常的인 開發 사이클이 恒時 維持가 可能하다.

글 / 현태호 깃랩(GitLab) 韓國 支社長
整理 / IT東亞 金榮宇(pengo@itdonga.com)

筆者 紹介

현태호 支社長은 30年 以上 컴퓨터 소프트웨어 및 SaaS 비즈니스 分野에서 다양한 經歷을 保有한 專門家이다. 2020年 12月부터 公式的으로 깃랩의 韓國 支社長으로 赴任한 그는 國內의 多樣한 엔터프라이즈 企業들이 데브섹옵스(DevSecOps) 文化를 導入해 디지털轉換(DT)과 革新을 이루어야 한다고 强調하고 있다.

現 支社長은 서강대학교에서 經營學을 專攻했고, 서울대학교 大學院에서 最高經營者過程(AMP)을 修了하였다. 또한 1997年과 2013年 하버드 비즈니스 스쿨 經營者 課程을 修了했다.

깃랩 入社 以前에는 15年間 韓國IBM과 IBM 아시아地域 本部에서 營業 및 마케팅 部署에서 일했으며, 머큐리 인터랙티브에서 專務 理事로서 該當 企業을 애플리케이션 테스팅 1位 企業으로 성장시켰다. 以後 VMware 韓國支社長, HP엔터프라이즈 소프트웨어 事業部 總括 責任者를 歷任하며 假想化 소프트웨어, Cloud 및 SaaS 비즈니스를 管理했고, 最近까지 클릭(Qlik)에서 韓國 支社長으로 勤務했다.

※ 본 콘텐츠의 內容은 IT東亞의 編輯 方向과 다를 수 있습니다