애자일 | 스크럼 & 칸반 프레임워크

I’m ready to translate the article for you, but I need the text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source link at the top and preserve all formatting, markdown, and code blocks as requested.

Agile이란?

이전 모듈에서는 agile이라는 용어가 DevOps 문화의 핵심 측면, 즉 고객 요구와 피드백에 신속하게 대응하는 능력을 설명했습니다. Agile(대문자 “A”)은 보다 구체적인 의미를 갖습니다. 이는 DevOps 실천과 밀접하게 연계된 소프트웨어 개발 및 프로젝트 관리에 대한 공식적인 접근 방식을 말합니다.

전통적인 워터폴 모델에서 Agile로 전환하면 더 빠른 전달, 향상된 품질, 그리고 고객 기대와의 강력한 정렬을 달성할 수 있습니다. Agile은 협업, 지속적인 개선, 자동화, 그리고 고객 중심을 강조하며, 궁극적인 목표는 고품질 소프트웨어를 보다 빠르고 신뢰성 있게 제공하는 것입니다.

Agile 선언문과 핵심 가치

Agile 선언문은 2001년에 경직되고 프로세스 중심적인 개발 모델에 대한 대안을 찾던 소프트웨어 개발자 그룹에 의해 만들어졌습니다. 선언문은 네 가지 핵심 가치 진술을 정의하며, Agile 팀이 더 높게 평가하는 항목을 강조합니다:

• 프로세스와 도구보다 개인과 상호작용
• 포괄적인 문서보다 작동하는 소프트웨어
• 계약 협상보다 고객 협업
• 계획을 따르는 것보다 변화에 대응

이러한 가치는 프로세스, 문서, 계약, 혹은 계획을 없애는 것이 아니라, 유연성, 피드백, 그리고 사람 중심의 결과를 강조합니다. 선언문은 구체적인 방법이나 도구를 규정하지 않아 팀이 자신의 상황에 가장 적합한 실천 방식을 선택할 수 있도록 의도되었습니다.

Scrum Framework

Scrum은 스프린트(보통 1~4주)라는 짧고 시간 제한된 반복을 통해 팀이 협업하고 복잡한 문제를 해결하도록 돕는 Agile 프레임워크입니다. Scrum은 이벤트, 아티팩트, 역할이라는 세 가지 핵심 요소로 구성됩니다.

Events

• Sprint Planning – 팀이 스프린트 동안 작업할 백로그 항목을 선택합니다.
• Daily Scrum (Standup) – 진행 상황과 장애물을 공유하기 위한 짧은(≈15분) 일일 회의입니다.
• Sprint Review – 팀이 완료된 작업을 이해관계자에게 시연합니다.
• Sprint Retrospective – 팀이 스프린트를 되돌아보며 개선점을 도출합니다.

Artifacts

• Product Backlog – 제품에 대한 기능, 개선, 버그 수정 등을 우선순위별로 정리한 목록입니다.
• Sprint Backlog – 현재 스프린트에 선택된 백로그 항목들의 부분집합입니다.
• Task Boards – To Do, In Progress, Done 형태로 작업을 시각화하는 도구입니다.
• Sprint Burndown Chart – 남은 작업량을 시간에 따라 그래프로 표시해 스프린트 진행 상황을 추적합니다.

Roles

• Product Owner – 이해관계자를 대표하고 제품 백로그를 관리합니다.
• Scrum Master – Scrum 실천을 촉진하고 장애물을 제거하며 지속적인 개선을 이끕니다.
• Scrum Team – 제품을 개발하고 엔지니어링 품질 및 전달을 책임집니다.

Scrum 팀은 velocity를 메트릭으로 사용하여 각 스프린트에서 완료할 수 있는 작업량을 추정하고, 이를 통해 계획 수립과 예측 가능성을 높입니다.

Kanban 프레임워크

Kanban(일본어로 “간판”)은 제조업에서 효율성을 높이기 위한 방법으로 시작되었으며 소프트웨어 개발에서도 널리 채택되고 있습니다.

핵심 실천

• 작업 시각화 – 작업 항목이 카드 형태로 칸반 보드에 표시되고, 워크플로 단계(예: To Do, Doing, Done)를 나타내는 열을 통해 이동합니다. 열은 개발 및 테스트 단계와 같이 팀의 실제 프로세스를 반영하도록 맞춤 설정할 수 있습니다.
• 풀 기반 모델 – 팀에 여유가 있을 때만 작업이 진행으로 끌어오므로 과부하를 줄이고 품질을 향상시킵니다.
• 작업 진행 중 제한 (WIP) 한도 – 동시에 활성화해서 작업할 수 있는 항목 수를 제한하여 흐름을 유지합니다.

주요 지표

• 리드 타임 – 요청부터 전달까지의 전체 시간.
• 사이클 타임 – 항목에 실제로 작업하는 데 걸린 시간.
• 누적 흐름 다이어그램(CFD) – 시간이 지남에 따라 작업 항목이 다양한 상태로 이동하는 모습을 보여줍니다. 영역이 확대되는 것은 병목 현상이나 비효율을 나타낼 수 있습니다.

비교: Scrum vs. Kanban

결론

애자일은 사고방식과 가치를 제공하고, 스크럼과 칸반은 그 가치를 적용하는 실질적인 방법을 제공합니다. 두 프레임워크 모두 DevOps를 보완하여 더 빠른 피드백, 지속적인 개선, 그리고 보다 신뢰할 수 있는 소프트웨어 제공을 가능하게 합니다.