Overcoming Challenges in Agile and DevOps Integration: A Qualitative Study
브라질과 독일의 업계 전문가 6명을 대상으로 한 인터뷰에 기반한 이 질적 연구는 애자일(Agile)과 데브옵스(DevOps)를 통합하는 과정에서의 핵심적인 문화적, 구조적, 프로세스적, 기술적 과제들을 식별하고, 조직이 이러한 장벽을 극복하고 소프트웨어 전달을 개선하는 데 도움이 될 수 있는 네 가지 전략적 솔루션 영역을 제안한다.
원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기
당신이 거대하고 복잡한 공장(DevOps) 안에서 고속 레이싱 카(Agile)를 운전하려고 한다고 상상해 보세요.
**애자일(Agile)**은 드라이버와 같습니다. 그들은 속도를 높이고, 코너를 빠르게 돌며, 승객(고객)이 지금 당장 원하는 것에 따라 경로를 변경하고 싶어 합니다.
**데브옵스(DevOps)**는 피트 크루(Pit Crew)와 공장 바닥과 같습니다. 그들은 자동차가 안전하기를, 엔진이 매끄럽게 돌아가기를, 그리고 경주를 멈추지 않고도 수리가 자동으로 이루어지기를 원합니다.
당신이 공유한 논문은 이 두 세계를 결합하려고 할 때 어떤 일이 발생하는지에 대한 연구입니다. 연구진은 브라질과 독일의 숙련된 "레이스 메카닉"과 "드라이버" 6명을 인터뷰하여 왜 이 결합이 그토록 어려운지, 그리고 어떻게 해결할 수 있는지를 찾아냈습니다.
다음은 그들의 발견을 쉬운 용어로 정리한 내용입니다:
핵심 문제: 왜 섞기 어려운가?
연구진은 가장 큰 장애물이 보통 도구나 코드가 아니라, 바로 사람과 규칙이라는 것을 발견했습니다. 그들은 문제들을 네 가지 범주로 분류했습니다:
"잘못된 생각"의 문화 (문화적 및 조직적 장벽):
- 비유: 드라이버는 "애자일"이 "규칙 없이 마음껏 달려라"라는 뜻이라고 생각하는 반면, 피트 크루는 "데브옵스"가 "새로운 로봇 팔을 사는 것"이라고 생각하는 상황을 상상해 보세요.
- 실제: 사람들은 종종 이러한 개념을 오해합니다. 그들은 소프트웨어 도구(예: GitLab)를 구매하면 데브옵스 팀이 된다고 생각하거나, 애자일이 엄격하고 경직된 체크리스트를 따르는 것이라고 생각합니다. 실제로 애자일은 유연한 마인드셋에 관한 것이고, 데브옵스는 단순히 도구가 아니라 협업에 관한 것입니다. 또한, 사람들이 새로운 시도를 하는 것을 방해하는 "비난 문화"도 존재합니다.
"유리 벽" (구조적 제약):
- 비유: 드라이버는 차 안에 있고 메카닉은 차고에 있습니다. 그들 사이에는 두꺼운 유리 벽이 있습니다. 서로 볼 수는 있지만, 대화를 나누거나 도구를 쉽게 주고받을 수는 없습니다.
- 실제: 기업들은 종-종 서로 소통하지 않는 부서들을 가지고 있습니다(사일로 현상). 코드를 작성하는 사람들(개발자)과 서버를 운영하는 사람들(운영자)은 종종 다른 방에 있으며 서로 다른 상사를 두고 있습니다. 또한, 때때로 기업의 의사 결정 속도가 너무 느리거나, 소프트웨어를 빠르게 업데이트하는 것을 허용하지 않는 외부 기업(예: 애플이나 구글 앱 스토어)에 의존하기도 합니다.
"너무 복잡한 규칙서" (프로세스 및 방법론의 복잡성):
- 비유: 팀이 다른 종류의 자동차를 위해 작성된 500페이지짜리 지침서를 따르려고 노력하고 있으며, 이로 인해 속도가 느려지고 있습니다.
- 실제: 기업들은 종종 거대하고 경직된 프레임워크(예: SAFe)를 팀에 강요하곤 합니다. 이는 너무 많은 서류 작업과 회의를 추가합니다. 고장 난 것을 고치는 것(긴급함)과 새로운 것을 만드는 것(혁신) 사이의 균형을 맞추기가 어려워집니다.
"사각지대" (기술적 한계):
- 비유: 드라이버는 속도를 내고 있지만 대시보드가 고장 났습니다. 엔진이 과열되고 있다는 것을 차에 불이 붙기 전까지는 알 수 없습니다.
- 실제: 때때로 시스템이 실시간으로 일어나는 일을 "볼" 수 있도록 설정되어 있지 않습니다. 무언가 고장 나면 데이터가 여러 도구에 흩어져 있기 때문에 왜 그런 일이 발생했는지 파악하는 데 오랜 시간이 걸립니다.
해결책: 경주를 어떻게 해결할 것인가?
인터뷰에 응한 전문가들은 이러한 문제들을 해결하기 위한 네 가지 주요 방법을 제시했습니다:
"슈퍼 팀" 구축 (팀 구조 및 자율성):
- 해결책: "드라이버"와 "메카닉"을 나누는 대신, 드라이버가 곧 메카닉인 팀을 만듭니다.
- 아이디어: 코드를 작성하는 사람이 그것을 운영하는 책임도 진다면, 그들은 더 나은 코드를 작성할 것입니다. 그들은 밤중에 깨어나서 직접 고쳐야 하기 때문에 무언가를 망가뜨리고 싶어 하지 않을 것입니다. 이 팀들에게 모든 작은 변화에 대해 상사에게 허락을 구하지 않고도 스스로 결정을 내릴 수 있는 권한을 부여하십시오.
"팀 정신" 변화 (문화 및 협업):
- 해결책: 무언가 고장 났을 때 사람을 비난하는 것을 멈추고, "어떻게 시스템을 고칠 것인가?"를 묻기 시작하십시오.
- 아이디어: 사람들이 두려움 없이 실수를 인정할 수 있는 안전한 환경을 만드십시오. 모두가 무엇이 일어나고 있는지 알 수 있도록 업무를 가시화하는 도구(공유 화이트보드 등)를 사용하십시오. 보상 체계를 개인이 가장 빠른 데 집중하는 것이 아니라, 팀이 승리하도록 돕는 데 보상을 주는 방식으로 바꾸십시오.
규칙에 유연해지기 (프로세스 및 변경 관리):
- 해결책: 규칙서를 맹목적으로 따르지 말고, 원칙을 따르십시오.
- 아이디어: 특정 회의와 같은 규칙이 팀의 속도를 높이는 데 도움이 되지 않는다면 폐지하십시오. 작게 시작하십시오. 공장 전체를 하룻밤 사이에 바꾸려고 하지 마십시오. 하나의 작은 팀을 골라 그것이 작동함을 증명한 다음, 천천히 확장하십시오. 현재 상태가 어디인지 정직하게 밝히고, 준비가 되지 않았다면 애자일인 척하지 마십시오.
대시보드와 도구 업그레이드 (자동화 및 인프라):
- 해결책: 지루한 일들을 자동화하고 더 나은 센서를 설치하십시오.
- 아이디어: 인간이 수동으로 하지 않도록 코드를 테스트하고 업데이트를 배포하는 로봇(자동화)을 사용하십시오. 업데이트가 나가는 일정(예: 매주 화요일)을 정해두는 "열차" 시스템을 구축하여, 모두가 언제 변화가 있을지 예상할 수 있게 하십시오. 이는 무언가를 망가뜨릴 위험을 줄여줍니다.
결론
이 연구는 당신이 이 문제를 해결하기 위해 단순히 소프트웨어를 살 수는 없다고 결론짓습니다. 당신은 문화를 바꿔야 합니다.
이것은 느리고 무거운 화물선을 제트보트로 바꾸려는 것과 같습니다. 단순히 더 빠른 엔진을 다는 것(도구)만으로는 부족하며, 크루가 어떻게 협력하는지, 어떻게 의사 결정을 내리는지, 그리고 자신들의 책임을 어떻게 바라보는지에 대한 방식을 바꿔야 합니다. 가장 성공적인 팀은 소프트웨어를 만드는 사람과 그것을 운영하는 사람이 같은 팀으로서 동일한 목표를 공유하고 서로를 신뢰하는 팀입니다.
한계점: 연구진은 단 6명과 대화했다는 점을 인정하며, 따라서 그들의 조언이 매우 영리할지라도 세상의 모든 기업에 들어맞지는 않을 수 있다고 말합니다. 그들은 이 아이디어들이 모두에게 효과가 있는지 확인하기 위해 더 많은 연구가 필요하다고 제안합니다.
연구 분야의 논문에 파묻히고 계신가요?
연구 키워드에 맞는 최신 논문의 일일 다이제스트를 받아보세요 — 기술 요약 포함, 당신의 언어로.