애자일 가치와 스크럼 | 정보처리기사 필기

핵심 요약

애자일(Agile)은 변화하는 요구에 대응하면서 짧은 주기로 동작하는 소프트웨어를 제공하고, 고객의 피드백으로 개선하는 가치와 원칙이다. 스크럼(Scrum)은 이러한 개발에 사용할 수 있는 경량 프레임워크다. 애자일과 스크럼은 같은 말이 아니며, XP 등 다른 실천 방법도 있다.

1. 애자일의 네 가지 가치

더 중요하게 여기는 것	비교 대상	올바른 해석
개인과 상호작용	프로세스와 도구	도구보다 사람이 협력하여 문제를 해결하는 일이 중요하다
동작하는 소프트웨어	포괄적인 문서	실제 동작 결과를 중시하되 필요한 문서는 작성한다
고객과의 협력	계약 협상	계약 체결 뒤에도 고객과 계속 요구를 확인한다
변화에 대응하기	계획을 따르기	계획을 세우되 피드백과 환경 변화에 맞게 조정한다

오른쪽 항목에 가치가 없다는 뜻이 아니다. 문서를 작성하지 않는다, 계약을 무시한다, 계획 없이 개발한다는 설명은 애자일의 뜻을 잘못 해석한 것이다.

애자일의 원칙은 고객 만족을 위한 조기·지속적 인도, 요구 변경 수용, 짧은 인도 주기, 업무 담당자와 개발자의 협업, 자율적인 팀, 효과적인 의사소통, 동작 결과 중심의 진척 판단, 지속 가능한 속도, 기술적 우수성, 단순성, 자기조직화, 정기적인 성찰과 개선으로 연결된다. 원칙의 표현을 기계적으로 외우기보다 어떤 개발 행동을 지지하는지 판단한다.

2. 스크럼의 기본 구조

스크럼은 경험을 통해 배우는 경험주의와 낭비를 줄이는 사고를 바탕으로 한다. 경험주의의 세 기둥은 투명성·점검·적응이다. 진행 상황과 결과를 함께 확인할 수 있어야 점검이 의미가 있고, 발견한 문제를 실제 방식에 반영해야 적응이 이루어진다.

스크럼의 다섯 가치는 헌신·집중·개방성·존중·용기다. 이는 역할이나 회의 이름이 아니라 팀이 일하는 태도다.

세 가지 책임

책임	핵심 역할	잘못된 해석
프로덕트 오너(Product Owner)	제품 가치를 높이고 프로덕트 백로그의 내용과 순서를 관리	팀의 모든 작업 방법을 직접 지시하는 사람
스크럼 마스터(Scrum Master)	스크럼의 이해·적용과 팀의 효과성을 돕고 장애물 제거를 지원	매일 업무를 할당하고 실적을 보고받는 감독자
개발자들(Developers)	스프린트 계획을 구체화하고 사용 가능한 증분을 함께 생성	코딩 담당자만 포함하고 시험·설계 담당자는 항상 제외

스크럼 팀은 필요한 역량을 함께 갖춘 교차 기능적 팀이며, 내부적으로 누가 무엇을 어떻게 할지 관리한다. 프로덕트 오너는 여러 이해관계자의 요구를 조정하지만 해당 책임 자체는 위원회가 아니라 한 사람에게 있다.

스프린트

스프린트(Sprint)는 목표를 달성하기 위해 일하는 한 달 이하의 고정 길이 기간이다. 하나가 끝나면 다음 스프린트를 시작한다. 스프린트 중에도 세부 범위는 학습 결과에 따라 조정할 수 있지만 스프린트 목표를 위태롭게 하거나 품질을 낮춰서는 안 된다.

반복 기간이 있다는 사실만으로 스크럼은 아니다. 목표, 책임, 점검과 적응, 사용 가능한 결과가 함께 작동해야 한다.

계획·개발과 데일리 스크럼·리뷰·회고는 한 달 이하 스프린트 안에서 이루어진다. 완료한 증분은 리뷰 전에도 전달할 수 있다.

3. 주요 이벤트 비교

이벤트	핵심 질문과 목적	구분할 점
스프린트 계획	이번 스프린트의 가치·목표, 선택할 일, 수행 방법을 정한다	제품 전체의 모든 상세 일정을 처음에 확정하는 회의가 아니다
데일리 스크럼	스프린트 목표에 대한 진행을 점검하고 다음 작업 계획을 조정한다	개발자들을 위한 15분 이벤트이며 상급자 보고가 목적이 아니다
스프린트 리뷰	증분과 달라진 상황을 이해관계자와 점검하고 다음 방향을 조정한다	제품·결과에 대한 점검이다
스프린트 회고	사람·상호작용·프로세스·도구 등의 개선 방법을 찾는다	팀의 일하는 방식에 대한 점검이다

스프린트가 다른 이벤트를 담는 용기 역할을 한다. 리뷰는 제품, 회고는 과정이라는 차이를 먼저 기억한다. 한 달 스프린트 기준 계획은 최대 8시간, 리뷰는 최대 4시간, 회고는 최대 3시간이며 더 짧은 스프린트에서는 보통 더 짧다. 데일리 스크럼은 15분이다.

4. 산출물과 완료 판단

산출물	의미	연결되는 약속
프로덕트 백로그	제품을 개선하기 위해 필요한 일의 정렬된 목록	프로덕트 목표
스프린트 백로그	스프린트 목표, 선택된 백로그 항목, 이를 인도할 계획	스프린트 목표
증분(Increment)	기존 결과에 더해지는 사용 가능한 결과	완료의 정의(Definition of Done)

백로그는 한 번 확정한 뒤 수정할 수 없는 문서가 아니다. 내용을 더 작고 명확하게 나누는 백로그 정제도 계속 수행한다. 정제 자체를 별도의 공식 스크럼 이벤트로 세지는 않는다.

완료의 정의는 결과물이 갖춰야 할 공통 품질 기준이다. “개발자가 코딩을 끝냈다”만으로 증분이 완료되는 것은 아니다. 시험 등 완료 기준을 충족해야 한다. 스프린트 리뷰를 기다려야만 결과물을 배포할 수 있는 것도 아니다.

번다운 차트는 남은 작업량을 시간에 따라 나타내는 진척 확인 도구다. 남은 작업량이 줄어드는 추이를 보는 것이며, 그래프 하나가 제품 가치나 품질을 모두 보여주지는 않는다.

5. XP와의 비교

XP(eXtreme Programming)는 변화에 빠르게 대응하면서 소프트웨어 품질을 유지하기 위한 개발 실천을 강조한다. 대표 가치는 의사소통·단순성·피드백·용기·존중이다.

실천	의미
짝 프로그래밍	두 사람이 함께 코드를 작성·검토한다
테스트 주도 개발(TDD)	먼저 실패하는 시험을 만들고 통과할 코드를 작성한 뒤 개선한다
지속적 통합	변경을 자주 통합하고 자동 시험으로 문제를 조기에 발견한다
리팩터링	외부 동작을 유지하면서 내부 구조를 개선한다
작은 릴리스	작고 사용 가능한 결과를 자주 제공한다
공동 코드 소유	특정 개인만 수정할 수 있는 구조보다 팀의 공동 책임을 중시한다

스크럼은 팀의 책임·목표·이벤트·산출물, XP는 구체적인 개발 실천을 구분 단서로 삼는다. 실제로는 함께 사용할 수 있다.

6. 상황과 오답 판별

고객이 매달 사용 가능한 결과를 확인하고 우선순위를 바꾸려 한다면 애자일의 짧은 인도와 피드백이 적합하다. 팀이 제품 시연 후 다음 제품 방향을 논의한다면 리뷰이고, 협업 중 병목을 찾아 다음 스프린트의 작업 방식을 바꾸려 한다면 회고다.

“계획을 바꾸면 애자일이 아니다”, “스크럼 마스터가 모든 작업을 배정한다”, “데일리 스크럼은 고객의 최종 인수 회의다”, “증분은 시험하지 않은 코드 묶음이다”는 모두 적절하지 않다.

애자일 가치와 스크럼 책임의 연결

Scrum Guide 2020 기준의 구분

실제 작업을 수행하는 Developers가 크기 산정에 책임을 진다.

스프린트는 한 달 이하의 고정 길이 이벤트이다. 목표가 쓸모없어졌다면 Product Owner가 취소할 권한을 갖는다. 진행 중 범위는 목표를 위험하게 하지 않는 선에서 Product Owner와 Developers가 협의해 명확히 하거나 재협상할 수 있다. 목표를 보존하는 범위 조정과 목표를 무시하는 무제한 변경은 다르다.

Backlog Refinement는 항목을 더 작고 명확하게 다듬는 지속적인 활동이며, Scrum Guide에서 별도의 공식 이벤트로 정의하지 않는다. Sprint Review는 결과와 환경 변화를 이해하고 적응하는 자리이지 유일한 출시 승인 관문이 아니다. Done을 충족한 가치 있는 Increment는 Review 전에도 전달할 수 있다.

XP의 단순 설계는 현재 필요한 요구를 명확하고 중복 적게 구현하는 실천이다. 미래의 모든 가능성을 미리 구현하는 과잉 설계와 다르다. 지속 가능한 속도는 과도한 초과근무를 반복하지 않고 품질과 작업 속도를 유지하는 것이다. TDD는 실패하는 테스트 작성→최소 구현으로 통과→리팩터링의 흐름으로 이해한다.

가치와 경험주의의 기둥

스크럼의 다섯 가치는 헌신(Commitment)·집중(Focus)·개방성(Openness)·존중(Respect)·용기(Courage)이다. 경험주의의 세 기둥인 투명성·점검·적응과 다른 목록이다. XP의 의사소통·단순성·피드백·용기·존중과도 일부만 겹친다. 가치는 팀이 협력하는 태도를, 기둥은 사실을 드러내고 관찰해 조정하는 경험적 운영 원리를 설명한다.