지난 11월 28일 서울 강남파이낸스센터 21층 대회의실에서 GitLab 코리아 18번째 밋업이 오프라인으로 진행됐습니다.
인포그랩과 GitLab 코리아는 지난 17번째 밋업에 이어 이번 밋업도 오프라인 행사로 준비했 는데요. 밋업 주제는 ‘VSM(Value Stream Management)*으로 완성하는 DevSecOps & Slack Bot(슬랙봇)** 자동화’였습니다. DevOps의 Value Stream(가치 흐름)과 자동화가 밋업의 주요 키워드였어요.
이번 밋업은 세 개의 세션으로 진행됐는데요. 세션 1에서는 신철호(Dexter) 인포그랩 이사가 ‘DevOps VSM’을 주제로 GitLab의 VSM 솔루션 기능을 소개했고요. 세션 2에서는 임희호(Chad) 인포그랩 DevOps 엔지니어가 ‘DevOps 자동화는 GitLab으로’를 주제로 GitLab을 활용해 DevOps 업무를 자동화하는 방법을 설명하고, 시연했습니다. 세션 3에서는 손성훈(Jeff) 인포그랩 DevOps 엔지니어가 ‘비개발자도 DevOps 누리기’를 주제로 ‘슬랙봇을 사용해 블로그 배포를 자동화하는 방법’을 발표하고 시연을 선보였죠. 이날 밋업의 주요 발표 내용을 자세히 살펴보겠습니다.
*VSM: Value Stream Management 기능의 줄임말. 이는 고객을 향하는 가치 흐름(Value Stream)을 좋게 만들도록 관리하는 방법임
**슬랙봇: 메신저 서비스인 ‘슬랙’에 기반한 봇(bot). 이는 특정 작업을 기억하도록 채널 또는 다이렉트 메시지(DM)에서 사용자에게 리마인더를 전달하는 등 다양한 기능을 자동으로 수행함
‘DevOps 동작 상태’ 판단 기준의 한계
세션 1에서는 Value Stream과 VSM(Value Stream Management), Value Stream Mapping 개념, Value Stream 사례, GitLab의 VSM 솔루션 등을 다뤘습니다. 먼저 신철호(Dexter) 인포그랩 이사는 ‘조직에서 DevOps가 잘 작동하는지’ 판단하는 몇 가지 질문을 던졌는데요. 질문은 다음과 같습니다. 1)DevOps를 구축하고, CI/CD 파이프라인이 돌아간 다음 뭐가 달라졌나요? 2)한 달에 몇 번 배포하나요? 배포할 때 문제가 얼마나 안 생기나요? 3)요구사항을 처음에 전달받고 코드를 작성하기 전까지 준비시간이 보통 얼마나 걸리나요? 4)코딩을 시작해서 고객에게 리뷰받기까지 시간이 보통 얼마나 걸리나요? 5)요구사항을 전달받고 코드를 작성하기까지 걸린 시간을 어떻게 기록하고, 알 수 있나요?
신 이사에 따르면, ‘사람들이 1)번 질문에는 쉽게 답할 수 있다’고 합니다. CI/CD 파이프라인이 어느 정도 돌아가면 대부분 사람이 ‘CI/CD 자동화가 개발 일정이나 품질을 맞추는 데 도움이 되고, 개선이 조금 이뤄졌다’고 말하죠. 실제 이를 피부로 느끼기도 하고요. 2)~5)번 질문은 답변하기 쉽지 않은 질문이었습니다. 신 이사가 밋업 청중에게 이 질문을 던졌을 때, 3)번 질문을 제외하면 답변하는 분이 없었는데요. 한 분만 3)번 질문에 “일주일 걸린다”고 답변했죠. 신 이사는 “우리가 DevOps를 성숙도 높게 사용하면 이러한 질문의 답을 머릿속에 두고 즉각 말할 수 있을 것”이라고 말했습니다.
이어서 신 이사는 DevOps 성숙도를 판단하는 글로벌 기준으로 ‘Google DORA 4 Keys’를 설명했는데요. DORA 4 Keys는 속도 측면에서 배포 내역(Deployment History)과 평균 변경 리 드 타임(Mean Lead Time For Changes)을, 안정성 측면에서 변경 실패율(Change Failure Rate)과 서비스 복원 시간(Time To Restore Service)을 측정하죠. 배포 내역은 배포 주기, 평균 변경 리드 타임은 코드 변경부터 운영 배포까지 리드 타임이고요. 변경 실패율은 배포하다가 실패한 비율, 서비스 복원 시간은 배포하다가 실패했을 때 복원한 시간이죠. 신 이사는 “DevOps를 구축한 조직은 대부분 이 정도 데이터를 수집, 정리하려 한다”고 말했습니다.
아울러 신 이사는 DevOps 성숙도를 평가하는 기준으로 ‘DevOps Maturity Assessment’도 소개했는데요. 이날 밋업에서 공유한 DevOps Maturity Assessment 표는 신 이사가 DORA의 DevOps 성숙도 평가 설문을 확장해서 만든 버전이었습니다. 기술, 프로세스, 문화 측면에서 DevOps 성숙도를 리커드 척도*로 정성 평가하죠. 신 이사는 “이 두 가지 기준(Google DORA 4 Keys, DevOps Maturity Assessment)만으로 DevOps 성숙도를 평가할 수 없지만 이를 활용해 DevOps를 다음에 더 잘하기 위한 활동, 그 활동으로 실제 DevOps를 개선하는 작업을 진행한다”고 설명했습니다.
그러나 이러한 기준만으로 ‘DevOps가 잘 동작하는지’ 판단하기에는 한계가 있는데요. 신 이사는 Google DORA 4 Keys의 단점으로 ‘무엇을 개선해야 하는지 알려주지 않는다’고 지적했습니다. DevOps Maturity Assessment는 ‘의사 결정에 충분한 수준으로 정성 데이터가 나오지 않는’ 문제가 있고요. DevOps가 잘 동작하는지 판단하려면 이 두 가지 기준을 적절히 활용해야 하는데요. 신 이사는 ‘VSM이 여기에 도움이 될 수 있다’고 밝혔습니다.
*리커드 척도: 설문 조사 등에 사용되는 심리 검사 응답 척도 중 하나. 응답자가 제시된 문장에 얼마나 동의하는지를 답변하도록 함
Value Stream, VSM이 문제를 푸는 방식
신 이사는 VSM(Value Stream Management)을 설명하기에 앞서 글로벌 정보기술 연구·자문 기업인 가트너가 제시한 ‘Hype Cycle for Agile & DevOps(2022년)’를 소개했는데요. 이 자료는 ‘신생 기술의 성숙도를 향한 시장 기대’를 보여주죠. 특히 VSM이 ‘기술업계에서 떠오르는 신생 기술이자 글로벌 연구기관에서도 주목하는 중요한 기술임’을 보여주는 자료이기도 한데요. Hype Cycle for Agile & DevOps를 보면 2022년에 Value Stream Management Platform, Value Stream Delivery Platform이 Agile과 DevOps 분야에서 두각을 나타내고 있고요. 두 기술의 성숙도는 혁신 트리거(Innovation Trigger) 단계부터 기대치 폭등의 정점(Peak of Inflated Expectations) 단계까지 걸쳐져 있었습니다. 이 기술은 2~5년 내로 안정기에 도달할 걸로 전망되고요.
그렇다면 도대체 VSM이 뭘까? 신 이사는 먼저 Value Stream 개념부터 설명했는데요. 이는 제품이나 서비스가 고객에게 가치를 제공하도록 수행하는 순차적 단계를 나타낸 겁니다. 이는 ‘기능 요청(Feature Request)→정의하기(Define)→빌드하기(Build)→검증하기(Validate)→릴리즈하기(Release)→새로운 가치 증가(New Increment Of Value)’ 순서로 이뤄지는데요. 즉, 소프트웨어나 서비스에서 작은 기능을 완성도 높게 만들어 고객 가치를 지속적으로 높여가는 과정이죠. 기능 요청 단계에서 가치를 만들기까지 걸리는 전체 시간을 ‘리드 타임’이라고 하는데요. Value Stream은 이 리드 타임을 반복 수행해서 고객 가치를 반복해 만드는 일입니다.
VSM은 고객을 향하는 가치 흐름을 좋게 만드는 관리 방법인데요. 이는 고객 가치를 만드는 활동 흐름인 Value Stream을 가속화하는 데 도움이 되는 다양한 관행과 기술을 포함합니다. 신 이사는 그 과정을 이렇게 설명했는데요. 먼저 Value Stream을 평가하고요. Value Stream Map을 그립니다. 그다음, 개선 활동을 적용하고 데이터를 만들며, 피드백과 개선 활동을 반복하죠. 특히 작업을 가시화하면 고객 경험을 개선하기 위해 지연, 낭비, 부가가치가 없는 작업을 제거하는 데 필요한 인사이트를 얻을 수 있고요.
앞서 VSM 과정에서 ‘Value Stream Map을 그린다’고 언급했죠. 이러한 행위를 ‘Value Stream Mapping’이라고도 하는데요. 이는 모든 이해 관계자가 모여 Value Stream의 주요 단계, 전달되는 결과물, 지연 시간 등을 시각화 지도로 그리는 활동을 뜻합니다. VSM의 핵심 활동인데요. Value Stream Mapping으로 Value Stream에서 개선할 영역을 발견하고, 고객 만족 요건을 이행하는 데 필요한 총시간을 가시화할 수 있습니다. Value Stream Mapping을 수행하는 워크숍도 있는데요. 워크숍에서는 현재 Value Stream 상태를 Map으로 그리고 분석하며, 미래 상태 Map을 그리고 현재와 미래 격차를 줄이는 액션 아이템을 도출하죠.
신 이사는 앞서 ‘Google DORA 4 Keys’와 ‘DevOps Maturity Assessment’ 같은 DevOps 성숙도 평가 기준만으로 ‘DevOps가 잘 동작하는지’ 판단하기에는 한계가 있다고 설명했는데요. Google DORA 4 Keys는 ‘무엇을 개선해야 하는지’ 알려주지 않고, DevOps Maturity Assessment는 ‘의사 결정에 충분한 수준으로 정성 데이터가 나오지 않는다’고 지적한 바 있습니다.
GitLab의 VSM 솔루션은 이 한계를 보완하는 기능을 제공하죠. 이는 리드 타임(Lead Time)·사이클 타임(Cycle Time)·새로운 이슈(New Issues)·배포(Deploys) 등 핵심 메트릭(Key metrics), 배포 주기(Deployment Frequency)·변경 리드 타임(Lead Time for Changes)·서비스 복원 시간(Time to Restore Service)·변경 실패율(Change Failure Rate) 등 DORA 메트릭(DORA metrics), 총시간(Total time 또는 평균 완료 시간(Average time to completion)) 등 여러 지표를 한 곳에서 보도록 지원합니다. 통합 뷰(View) 환경에서 여러 지표를 동시에 함께 확인할 수 있는데요. 따라서 GitLab의 VSM 솔루션에는 ‘DevOps 동작 상태’를 종합적으로, 다각도로 꼼꼼하게 파악할 수 있다는 장점이 있습니다.
인포그랩이 GitLab VSM으로 Value Stream 관리하는 방법
이어서 신 이사는 GitLab의 VSM 솔루션으로 인포그랩의 Value Stream을 관리하는 방식을 시연했는데요. 앞서 언급했다시피 GitLab에서 VSM 분석 대시보드를 보면 회사의 Value Stream 관련 지표를 확인할 수 있습니다. 배포한 뒤 ‘Incident’라는 항목을 대시보드에 만들면 이 Incident를 기준으로 장애 데이터를 측정할 수 있죠. 대시보드에서는 전체 Value Stream, 특정 제품의 Value Stream 등을 보도록 구성할 수 있는데요. 신 이사는 “’저 정도 데이터쯤이야’라고 생각할 수도 있지만 사내 도구를 사용해 실제로 데이터를 수합하려고 해보면 이게 생각보다 쉽지 않다는 걸 알 수 있다”라고 말했습니다.
아울러 GitLab의 VSM 솔루션에서는 맞춤형 대시보드를 만들 수도 있는데요. 예를 들어, Severity, Priority에 따라 지표를 판단하도록 대시보드를 구축할 수도 있고요. DORA 메트릭을 기준으로 대시보드를 만들 수도 있습니다. 이때 월별 배포 주기나 월별 서비스 복원 시간 등을 확인할 수 있죠. 또 개발팀의 생산성도 GitLab의 VSM 솔루션으로 파악할 수 있는데요. GitLab에서는 Merge Request를 토대로 ‘얼마나 자주 merge 됐는지’를 보고 생산성 높낮이를 평가할 수 있습니다. 예를 들어, 하루 안에 merge가 끝난 아이템, merge 되는데 23일이나 걸린 아이템 등을 보고 ‘merge 하는 데 시간이 오래 걸릴 수밖에 없는 일이 뭔지’ 찾아내고, 이를 토대로 업무를 개선할 수 있죠. 신 이사는 “GitLab은 Git에 기반하기에 VSM 솔루션으로 개발자 한명 한명의 생산성을 쉽게 추적할 수 있다”고 설명했습니다.
세션 1을 마무리하며 신 이사는 VSM의 장점을 이렇게 정리했습니다. Value Stream을 관리하면 ‘다운타임’이라는 낭비를 줄일 수 있고요. 낭비되는 일을 자동화하면 고객 만족을 얻을 기회를 늘릴 수 있습니다. 그렇다면 현재 소프트웨어 개발 환경에서 ‘낭비’에 해당하는 일은 어떤 게 있을까요? 신 이사는 재작업/반복 작업, 고객에게 필요 없는 고품질 작업, 불필요한 작업, 대기 시간 등을 꼽았는데요. 예를 들어, ‘데이터베이스를 정규화하느냐, 마느냐’를 많이 고민하는 것도 그중 하나죠. 신 이사는 “DevOps 성숙도가 높은 회사는 배포 주기가 빠르고, 안정적이고 지속적으로 배포할 환경이 있으며, 고객 가치를 계속 만드는 곳일 가능성이 높다”며 “낭비 업무를 줄여 자동화를 구현하고, 레버리지가 높은 일을 하도록 하는 게 고객 가치를 높이는 일”이라고 강조했습니다.
자동화로 VSM을 최적화해야 하는 이유
세션 2에서는 자동화로 VSM(Value Stream Management)을 최적화해야 할 필요성과 GitLab에서 이슈·Merge Request(MR), CI/CD 파이프라인, 컴플라이언스 파이프라인을 자동화하는 방법을 설명했습니다. 즉, VSM으로 프로젝트에서 개선할 업무를 찾아 이를 자동화로 향상하는 게 이 세션의 목표였는데요. 세션 2 연사인 임희호(Chad) 인포그랩 DevOps 엔지니어는 먼저 VSM 대상이 될 프로젝트를 예시로 들며 여기서 개선해야 할 문제를 제시했습니다.
임 엔지니어는 이 프로젝트에서 n명의 개발자가 에픽, 이슈, MR로 협업하는 상황을 가정했는데요. 이들은 각자의 환경에서 빌드, 테스트, 보안 활동을 수행하고 있습니다. 개발자별로 환경이 각각 다르다 보니 일관성이 떨어지기도 하고, 개발 일정 때문에 보안 활동이 빠질 때도 있는데요. 임 엔지니어는 “이렇게 작업이 수동으로 이뤄지면 휴먼 에러가 발생하기 쉬워서 프로젝트 품질의 일관성이 떨어지고, 효율적이지 않다”고 지적했습니다.
위에 있는 ‘GitLab Value Stream Management’ 이미지는 이 프로젝트의 VSM 상태와 비슷한 VSM을 시각화해 보여주는데요. 민트색 부분은 현재 DevSecOps에서 가치를 창출하는 부분입니다. 빨간색 부분은 가치를 창출하지 못하는 부분이고요. 연보라색 부분은 유휴 시간이죠. 이미지를 보면 ‘많은 리소 스가 가치를 창출하지 못하는 데 쓰이고 있음’을 확인할 수 있는데요. 임 엔지니어는 여기서 다음과 같은 문제 인식을 공유했습니다.
첫째, 프로젝트 계획코드 작성 단계 문제인데요. 프로젝트가 커지고 협업이 많아질수록 이슈 관리나 변환 요청을 처리하는 데 시간과 노력이 많이 들어갑니다. 이는 중요한 작업이지만 개발자가 핵심 업무인 개발에 집중하기 어렵게 하죠. 둘째, 테스트배포 단계 문제입니다. 각 개발자는 수동으로 환경을 설정하거나 라이브러리를 업데이트하는 작업을 반복하는데요. 이 과정에서 시간이 오래 걸리고, 효율성이 떨어지기도 합니다. 각 개발자의 환경은 저마다 다르기에 일관성이 부족할 수 있고요. 오류가 생기기 쉽습니다. 그 결과, 개발자의 업무 효율성이 낮아지고, 이는 전체 프로젝트 진행에 영향을 줄 수도 있죠. 피드백 주기가 길어져 사용자 경험이 악화할 가능성도 있고요.
임 엔지니어는 자동화로 이 문제를 개선하는 방안을 제시했는데요. 자동화를 활용하면 프로젝트의 VSM 상태가 위 이미지의 ‘Desired DevSecOps’와 같이 향상될 걸로 내다봤습니다. 아까 민트색 부분이 DevSecOps에서 가치를 창출하는 부분이라고 설명했는데요. 위 이미지의 Desired DevSecOps에서 민트색 부분이 큰 비중을 차지하는 걸 확인할 수 있죠. 임 엔지니어는 “가치를 창출하는 부분에 집중하면서 리소스 낭비가 줄어들 수 있다”고 말했습니다.
이슈·MR·CI/CD·컴플라이언스 파이프라인 자동화하기
이어서 임 엔지니어는 자동화로 위 문제를 개선하는 방법을 소개했는데요. 구체적으로는 GitLab의 Triage 기능을 활용한 이슈·MR 관리 자동화, CI/CD 파이프라인을 활용한 빌드·테스트·보안 자동화, 컴플라이언스 파이프라인 자동화를 시연했습니다. 참고로 Triage 기능은 GitLab에서 제공하는 에픽, 이슈, MR, 브랜치 등을 관리하는데요. 이는 복잡한 프로젝트 환경을 관리하도록 설계되었고요. 사용자 정의 규칙을 설정하여 자동으로 이슈를 분류하고, 적절한 레이블을 적용하도록 지원합니다.
이슈·MR 관리 자동화, CI/CD 파이프라인을 활용한 빌드·테스트·보안 자동화, 컴플라이언스 파이프라인 자동화에는 다음 효과가 있습니다. 첫째, 이슈·MR을 자동화하면 프로젝트 관리 방식을 개선할 수 있고요. CI/CD 파이프라인으로 빌드·테스트·보안을 자동화하면 프로젝트의 일관성을 보장하고, 피드백 속도를 올려 프로젝트 생산성도 높일 수 있죠. 셋째, GitLab에서 제공하는 컴플라이언스 프레임워크를 사용해서 프로젝트의 파이프라인을 효율적으로 구성하고, 조직의 규정을 준수할 수 있습니다.
임 엔지니어는 GitLab의 Triage 기능으로 이슈·MR 관리 자동화를 시연할 때, 다음 활동을 진행했는데요. 첫째, 정책에 의해 이슈 관리를 자동화하고요. 둘째, 이슈 요약 보고서를 생성했습니다. 셋째, Triage 자동화와 코드 리뷰 봇을 결합했죠. 임 엔지니어는 이 시연에서 다음과 같은 인사이트를 도출했는데요. 첫째, 정책이 잘 결정될수록 자동화를 더 효율적이고 엄격하게 적용할 수 있습니다. 따라서 각 조직에 맞는 정책을 잘 정해야 하고요. 둘째, 시연에서 수동으로 Triage 기능을 실행했는데요. 스케줄러나 특정 레이블이 붙으면 파이프라인이 실행하도록 만들 수 있으므로 이렇게 사용성을 높이는 것도 좋습니다. 셋째, 코드 리뷰 봇처럼 다양한 자동화 도구를 결합할 수도 있는데요. 자동화 파이프라인을 추가해 커밋 내역을 기준으로 블로그 포스팅을 자동화하는 일도 구현할 만합니다.
아울러 CI/CD 파이프라인으로 빌드·테스트·보안 자동화를 시연할 때는 다음 활동을 선보였습니다. 첫째, 빌드·테스트·보안 검사 파이프라인을 자동화했고요. 둘째, 자동화로 출력되는 결과물을 활용했습니다. 이 시연에서 임 엔지니어가 제시한 인사이트는 다음과 같은데요. 첫째, 배포 자동화로 피드백 주기를 줄여 VSM을 개선할 수 있고요. 둘째, MR을 생성할 때 OpenAI API로 설명(Description)을 자동으로 작성하는 방법을 구상해 볼 수도 있습니다.
마지막으로 컴플라이언스 파이프라인 자동화를 시연할 때는 다음 활동을 진행했는데요. 첫째, 컴플라이언스 파이프라인 프로젝트를 생성했고요. 둘째, 최상위 그룹인 GitLab 밋업에 ‘DevSecOps’라는 이름을 붙여 이를 컴플라이언스 파이프라인으로 등록했습니다. 셋째, 이후 준비된 스프링부트 프로젝트에 컴플라이언스 파이프라인을 적용했고요. 넷째, 스프링부트 CI/CD 파이프라인에 컴플라이언스 파이프라인이 합쳐져 동작했죠. 임 엔지니어는 “Triage 기능으로 이슈와 MR 관리를 자동화해 프로젝트 관리 방식을 개선할 수 있었고, CI/CD 파이프라인을 구축해 가치를 창출하는 주기를 줄일 수 있었다”며 “또 컴플라이언스 파이프라인으로 모든 프로젝트에 파이프라인을 손쉽게 주입하고 일관성도 만들 수 있었다”고 시연 의의를 설명했습니다.
앞서 임 엔지니어가 선보인 시연 가운데 ‘Triage 기능으로 이슈 관리를 자동화하는 방법’이 있었죠. 인포그랩 공식 홈페이지 기술 블로그에 들어오시면 ‘Triage로 GitLab 이슈 관리 개선하기’라는 글에서 자세한 방법을 확인하실 수 있습니다.
콘텐츠 배포 자동화 봇을 개발한 배경
세션 3에서는 슬랙봇을 활용해 인포그랩 기술 블로그에 콘텐츠 배포 업무를 자동화한 사례를 발표했습니다. 해당 도구를 직접 개발한 손성훈(Jeff) 인포그랩 DevOps 엔지니어는 비개발자도 DevOps를 누릴 수 있도록 ‘비개발 업무에 자동화 도구를 도입한’ 배경과 구체적인 개발 과정을 소개했는데요. 이 도구의 개발 과정은 내년 1월 인포그랩 기술 블로그에서 자세히 공개할 예정입니다. 따라서 이 글에서는 자동화 도구의 도입 취지와 개발 배경, 과정을 핵심만 짚어 간략히 전달하겠습니다.
손 엔지니어는 먼저 개발자 경험의 의미를 짚으면서 테크니컬 라이터와 같은 비개발자 경험의 중요성을 환기했는데요. DevOps 측면에서 ‘개발자 경험’ 수준을 판단할 때, 다음 요소를 측정한다고 하죠. 첫째, ‘개발자가 코드베이스를 얼마나 쉽고 빠르게 배포할 수 있는지’고요. 둘째, ‘자동화된 프로세스로 기획 단계에 있는 아이디어를 어떻게 디자인하고, 구현하며, 배포하고, 운영하는지’입니다. 셋째, ‘개발자가 현재 자신의 개발 환경에 얼마나 만족하는지’인데요. 손 엔지니어는 ‘개발자뿐만 아니라 비개발자 경험을 개선할 필요성도 느꼈다’고 해요. 그는 “회사에는 개발자만 있는 게 아니다”며 “디자이너도 있고, 기획자도 있는데 ‘이들의 경험을 확장할 수 없을까?’라는 고민이 들었다”고 밝혔습니다.
그중에서도 손 엔지니어가 주목한 비개발자 경험은 바로 ‘테크니컬 라이터의 경험’이었는데요. 그는 올봄 인포그랩에 입사한 테크니컬 라이터에게서 내부 테크니컬 라이팅 업무와 관련해 수많은 문의를 받았습니다. 테크니컬 라이터가 그에게 자주 한 문의는 크게 네 가지인데요. 첫째, 문법/파이프라인 오류, 둘째, GitLab 이슈/Merge Request(MR) 만들기, 셋째, 마크다운 문법, 넷째, 리뷰/승인 절차였죠. 이 문의를 한 테크니컬 라이터는 마크다운 문법을 사용해 본 경험이 없어서 여기에 익숙해지는 데 시간이 오래 걸렸고요. 사내 리뷰 승인 절차에 적응하는 데 초반에 어려움이 있었습니다.
이에 손 엔지니어는 테크니컬 라이터의 업무 경험을 향상하는 방법을 고민해 봤고요. ‘테크니컬 라이터가 블로그나 공식 문서를 얼마나 쉽고 빠르게 편집할 수 있는지’, ‘자동화된 프로세스로 글을 얼마나 빠르게 발행할 수 있는지’, ‘테크니컬 라이터가 현재 글을 쓰는 환경에 얼마나 만족하는지’를 생각해 봤습니다. 그는 “테크니컬 라이터가 글을 웹사이트에 배포하려면 특정 절차와 규칙을 지켜야 하는데 이를 자동화 프로세스로 제어하고, 아이디어 단계부터 글 작성, 편집, 리뷰, 배포 단계까지 모든 프로세스를 자동화고자 했다”며 “테크니컬 라이터가 글을 쓰는 환경에 만족하도록 만들고 싶었다”고 말했습니다.
슬랙봇의 작동 방식과 효과
손 엔지니어는 마크다운 문법과 VS Code를 사용하지 않고, 사내에서 주로 쓰는 노션으로 GitLab에 콘텐츠를 바로 배포하는 시스템을 만들고자 했는데요. 앞서 언급한, 슬랙봇을 활용해 인포그랩 기술 블로그에 콘텐츠 배포 업무를 자동화한 게 바로 그 결과물이었습니다. 손 엔지니어가 개발한 콘텐츠 배포용 슬랙봇의 작동 방식은 명확한데요. ‘인포그랩 봇’이라는 이름의 이 슬랙봇은 슬랙, 노션, GitLab과 연동돼 있고요. 모든 로직이 슬랙봇 안에서 처리됩니다.
인포그랩에서는 기술 블로그에 글을 배포할 때 꼭 입력해야 할 메타 데이터가 있습니다. GitLab ID, 저자 이름, md 파일명, 커버 이미지, <!--truncate--> 등이죠. 앞서 언급했듯 슬랙봇은 노션과 연동됐는데요. 슬랙 채널에 명령어를 입력해 슬랙봇을 호출한 다음, 콘텐츠 제목과 콘텐츠 업로드 채널을 선택하고 ‘제출하기’ 버튼을 누르면 자동으로 필수 메타 데이터 입력 여부를 검사하고요. 이 중 하나라도 빠지면 콘텐츠를 올릴 수 없게 이뤄졌습니다. 콘텐츠 업로드 관련 모달창에는 누락된 필수 메타 데이터 옆에 ‘X’ 표시가 뜨고요.
그러나 필수 메타 데이터가 모두 입력돼 있으면 ‘V’ 표시가 나오고요. ‘계속하기’ 버튼을 눌러 다음 절차로 넘어갈 수 있죠. 이때부터 GitLab에 해당 콘텐츠의 이슈와 MR이 자동 생성되고요. MR에 레이블도 자동으로 달립니다. 콘텐츠를 배포하는 파이프라인까지 자동으로 실행되고요. 파이프라인 실행이 끝나면 리뷰 앱으로 콘텐츠 배포 상태를 미리 확인할 수 있죠. 슬랙봇으로 콘텐츠 배포 업무를 자동화하면서 테크니컬 라이터는 GitLab에 콘텐츠 배포용 이슈와 MR을 일일이 생성하고, 레이블을 손수 달아야 할 필요가 없어졌죠.
슬랙봇으로 기술 블로그에 콘텐츠 배포 업무를 자동화한 성과는 이렇습니다. 블로그에 콘텐츠를 더 자주 배포할 수 있게 됐고요. GitLab 가이드와 블로그 관련 CI/CD 실패율은 5%로 낮아졌죠. 원클릭으로 스테이징 환경에 콘텐츠를 배포하면서 시간도 절약되고요. 테크니컬 라이터의 업무 만족도가 높아졌습니다. 손 엔지니어는 “테크니컬 라이터든, 개발자든, 엔지니어든 모두가 익숙하게 사용하고 쉽게 수정하며, 내부 프론트엔드 엔지니어와 백엔드 엔지니어도 모두 기여하도록 만들고 싶었다”고 말했는데요. “개발자뿐만 아니라 ‘팀 구성원 모두가 만족할 수 있는 업무 경험을 만드는 것이 DevOps’라고 생각하고, 그렇게 나아가려 한다”는 포부로 발표를 마무리했습니다.
맺음말
지금까지 GitLab 코리아 18번째 밋업의 주요 발표 내용을 살펴봤습니다. 이 글의 요점은 다음과 같은데요.
1.Value Stream은 제품이나 서비스가 고객에게 가치를 제공하도록 수행하는 순차적 단계입니다.
2.VSM(Value Stream Management)은 고객을 향하는 가치 흐름을 좋게 만드는 관리 방법입니다.
3.Value Stream Mapping은 모든 이해 관계자가 모여 Value Stream의 주요 단계, 전달되는 결과물, 지연 시간 등을 시각화 지도로 그리는 활동입니다.
4.GitLab의 VSM 솔루션은 리드 타임(Lead Time)·사이클 타임(Cycle Time)·새로운 이슈(New Issues)·배포(Deploys) 등 핵심 메트릭(Key metrics), 배포 주기(Deployment Frequency)·변경 리드 타임(Lead Time for Changes)·서비스 복원 시간(Time to Restore Service)·변경 실패율(Change Failure Rate) 등 DORA 메트릭(DORA metrics), 총시간(Total time 또는 평균 완료 시간(Average time to completion)) 등 여러 지표를 한 곳에서 보도록 지원합니다.
5.GitLab의 Triage 기능으로 이슈와 MR 관리를 자동화해 프로젝트 관리 방식을 개선할 수 있고, CI/CD 파이프라인을 구축해 가치를 창출하는 주기를 줄일 수 있으며, 컴플라이언스 파이프라인으로 모든 프로젝트에 파이프라인을 손쉽게 주입하고 일관성도 만들 수 있습니다. 이는 프로젝트의 VSM을 개선하는 데 도움이 됩니다.
6.인포그랩은 콘텐츠 배포를 자동화한 슬랙봇을 개발해 테크니컬 라이터의 업무 편의성을 높였습니다. 이는 테크니컬 라이팅 업무의 VSM을 향상하는 데 유익한 도구이죠. 개발자뿐만 아니라 ‘팀 구성원 모두가 만족할 수 있는 업무 경험을 만드는 것’도 DevOps가 될 수 있습니다.
인포그랩은 GitLab 및 DevOps에 대한 맞춤 기술 지원을 제공합니다. GitLab(Omnibus/Cloud Native Hybrid) 구축 관련한 지원이 필요하시면 문의하기 로 연락 주십시오.