Agile_2
1편에서는 '왜' 애자일을 도입하게 되었고, 어떤 준비 과정을 거쳤는지를 공유드렸습니다.
팀 구성과 한계, 그리고 자발적인 공감대를 바탕으로 우리만의 애자일 방식이 어떻게 시작되었는지를 돌아봤죠.
이제부터는 본격적으로 애자일을 도입한 이후의 변화에 대해 이야기하려고 합니다.
이번에는 우리 팀이 실제로 애자일을 어떻게 적용하고 운영하고 있는지. 구체적인 사례를 통해 살펴보겠습니다.
우리 팀은 모든 프로젝트를 2주 단위 스프린트를 기준으로 운영하고 있으며, 작업 단위는 Azure DevOps의 Epic → Feature → User Story → Task/Bug 구조로 체계적으로 관리하고 있습니다.
구분 | 일정 | 내용 |
|---|---|---|
스프린트 계획 | 첫째 주 월요일 오전 | 이번 스프린트에 포함할 유저 스토리를 선정하고, 각 작업을 구체화합니다. |
백로그 정제 | 스프린트 중 1회 이상 | 다음 스프린트에 포함될 유저 스토리를 미리 정리하고, 모호한 요구사항을 구체화합니다. |
스프린트 리뷰 | 둘째 주 금요일 오후 | 스프린트에서 완료한 기능을 이해관계자 앞에서 시연하고, 피드백을 받습니다. |
스프린트 회고 | 리뷰 직후 | 팀 내부에서 스프린트 동안의 좋았던 점과 아쉬웠던 점을 돌아보고, 개선점을 도출합니다. |
우리 팀은 매일 10~15분간 짧게 업무 진행 상황과 이슈를 공유합니다. 이 시간을 형식적인 보고 자리가 아닌, 편하게 이야기 나누는 시간으로 만들고자 했습니다.
특히 막히는 부분이나 도움이 필요한 작업에 관해 부담 없이 터놓고 이야기할 수 있는 시간이 되도록 했는데, 정식 회의로 잡으면 오히려 피하게 되는 경우가 많으므로 오히려 이런 가벼운 루틴이 더 효과적이었습니다.
스프린트 계획의 핵심은 유저 스토리를 팀 전체가 함께 검토하고, 작업 규모를 함께 추정하는 것입니다.
우리는 스프린트 시작일에 모여, 아래와 같은 순서로 계획을 진행합니다.
이런 방식은 개발자 간의 이해 차이를 자연스럽게 좁히는 데 도움이 되었고, 서로의 관점을 공유하면서 더 나은 추정을 도출할 수 있었습니다.
우리 팀은 스토리 포인트를 단순히 "걸리는 시간"이 아닌, 작업의 상대적인 크기와 복잡도를 추정하는 도구로 활용했습니다.
추정에는 피보나치 수열 (1, 2, 3, 5, 8, 13...)을 기준으로 삼았고, 불확실성이 큰 작업일수록 숫자 간 간격이 커지는 특징을 활용해 작업 간 난이도나 규모 차이를 더 명확하게 표현할 수 있었습니다.
우리가 사용한 스토리 포인트 추정 방법은 아래와 같습니다.
이런 방식은 단순한 수치 추정 그 이상으로, 팀의 이해 차이를 좁히고 서로의 관점을 맞춰가는 과정이었습니다.
또한 스프린트 회고 시간에 예측과 실제를 비교하면서 우리 팀만의 추정 기준이 점점 정교해지는 계기가 되기도 했습니다.
정확한 스토리 포인트 추정을 위해서는 유저 스토리 자체가 명확하고 구체적이어야 했습니다.
우리 팀은 유저 스토리를 다음과 같은 프로세스로 작성하고 정제했습니다:
유저 스토리의 개념과 좋은 작성 기준(INVEST등)은 앞선 핵심 개념 정리 섹션에 포함되어 있습니다.
디자이너 없이 개발자만으로 구성된 팀의 특성상, 유저 스토리마다 간단한 와이어프레임을 함께 준비했습니다.
와이어프레임은 화면에 어떤 요소가 있고, 어떤 흐름으로 작동해야 하는지를 시각적으로 정리해 유저 스토리만으로는 놓칠 수 있는 인터랙션과 레이아웃의 이해를 돕는 데 큰 역할 을 했습니다.
우리팀에서 실제로 사용했던 유저스토리와 와이어프레임, 인수 조건은 아래와 같습니다.
1. 그룹 추가 버튼 동작
[추가] 버튼을 클릭하면 Group 추가 모달이 열려야 한다.
2. Group 이름 설정
그룹명(Group Name)은 필수 입력 항목이다.
최소 1자, 최대 70자까지 입력 가능하며, 한글/영문/숫자/특수문자 입력 가능하다.
중복 확인 버튼을 통해 그룹명 중복 여부를 확인할 수 있어야 한다.
유효성 검사 결과는 하단에 메시지 형태로 즉시 반영되어야 하며, 유효하지 않은 경우 확인 버튼은 비활성화되어야 한다.
3. 사용자(User) 설정
전체 사용자 목록에서 사용자를 선택하여 그룹에 추가할 수 있어야 한다.
검색 필드를 통해 사용자 목록을 필터링할 수 있어야 하며, 입력값 기반으로 결과를 표시해야 한다.
사용자 목록은 모달이 열릴 때 서버에서 조회하여 표시한다.
좌측 목록에서 사용자 선택 후 > 버튼 클릭 시 그룹에 포함되고, < 버튼 클릭 시 제외된다.
동일 사용자의 중복 추가는 허용되지 않으며, 이미 추가된 사용자는 전체 목록에서 제외되어야 한다.
...이러한 흐름은 개발 이전 단계에서 “어떤 결과물이 나와야하는가”에 대한 공통된 상을 맞추는 데 많은 도움이 되었고, 특히 리뷰나 QA 과정에서도 기대치에 대한 불일치가 줄어드는 효과가 있었습니다.
우리 팀은 Azure DevOps의 칸반 보드를 활용해 스프린트 내 작업 상태를 시각적으로 관리하고 있습니다.
이 보드는 진행 상황을 한눈에 파악할 수 있게 해주며, 필요한 협업이나 조율이 즉각 이뤄질 수 있도록 돕는 중요한 도구입니다.
스프린트 계획 시 각 작업에 대해 초기 담당자만 정해두고, 이후에는 작업을 완료한 사람이 다음 작업을 자유롭게 선택해 가져가는 방식을 채택했습니다.
이런 유연한 구조 덕분에,
우리팀에서 사용했던 스프린트 칸반 보드의 일부를 캡처한 사진입니다.
우리 팀은 기능 개발이 끝났다고 해서 ‘완료’로 간주하지 않았습니다.
단위 테스트와 인수 조건 충족까지 포함된 상태를 ‘완료(Definition of Done)’로 정의했습니다.
Azure DevOps의 Acceptance Criteria 기능을 적극적으로 활용했습니다.
→ 이러한 기준을 명확히 정해둠으로써, “이 작업이 진짜 끝난 게 맞나?” 하는 논의나 혼란이 줄어들었습니다.
백로그 정제 회의는 프론트엔드/백엔드 각 최소 1명 이상 참여를 원칙으로 했지만, 실제로는 대부분 팀원 전원이 참석했습니다.
이 회의 자체도 하나의 작업으로 스프린트에 포함시켜, 단순한 준비 작업이 아닌 정식 개발 프로세스의 일부로 인식할 수 있도록 했습니다.
→ 덕분에 다음 스프린트가 더 매끄럽게 시작될 수 있었고, 작업 분배의 정확도도 점차 높아졌습니다.
스프린트 종료 시에는 Azure DevOps의 보드를 띄워놓은 상태로 스프린트 리뷰를 진행했습니다.
이해관계자가 참석한 자리에서, 완료된 유저 스토리 단위로 기능을 시연했습니다.
스프린트 리뷰 직후에는 Azure DevOps의 Retrospectives Extension을 활용해 회고(Retrospective)를 진행했습니다.
우리 팀은 4L 기법을 도입해, 피드백을 정리된 형식으로 수집하고 공유했습니다.
4L 기법이란?
회고 진행 방식
이 시간에는 자연스럽게 작업량에 대한 피드백도 오갔습니다.
“이건 과했네요”, “이번엔 부담이 덜했어요”처럼 솔직한 대화를 나눌 수 있는 시간으로 자리잡았습니다.
회고가 단순한 피드백 시간에 머물지 않도록, 우리 팀은 별도의 “회고 개선사항 적용 규칙” 문서를 운영하고 있습니다.
매 스프린트 회고 후
→ 도출된 액션 아이템을 문서화하고
→ 다음 스프린트에 반영할 루틴으로 정리합니다.
예시 : 실제 반영된 개선 규칙
항목 | 적용 방식 |
|---|---|
유저 스토리 정제 시 유효성 검증 여부도 함께 논의 | 회의 전 체크리스트 포함 |
API 스키마 변경 시 공유 방식 명확화 | User Story 코멘트 + Teams 공유 |
가능한 경우 PR은 작은 단위로 분할 | 기능 단위 PR 권장, 리뷰 피드백 효율 ↑ |
이렇게 도출된 규칙은 모두가 인지할 수 있도록 공유되고, 다음 스프린트의 기준점이 되어 이를 통해 일하는 방식을 개선시킬 수 있습니다.
각 스프린트 단계에서 체크리스트를 정해두고, 작업 누락 없이 일관된 품질을 유지할 수 있도록 운영했습니다.
이전 스프린트 미완료 작업 정리 및 Carry Over 처리신규 유저 스토리 정제 여부 확인 (요구사항 + 인수 조건 포함)기술 부채, 리팩토링, 성능 개선 등 포함 여부 검토스토리 포인트 추정 완료
매일 오전 데일리 스크럼 진행주요 변경 사항은 Teams 채널과 유저스토리 코멘트로 공유PR 리뷰 타이밍 관리 (지연 방지 목적)
이번 스프린트 작업이 dev 환경에 반영되었는지 확인누락된 항목 / 미배포 작업 정리회고용 4L 작성
도출된 개선 사항을 “회고 개선 사항 적용 규칙” 문서에 반영적용 대상 확인 및 실제 루틴 반영 여부 정리
이처럼 스프린트 리뷰와 회고, 그리고 후속 조치까지 정착된 프로세스로 이어지도록 설계함으로써, 단순히 "돌아보기"에서 끝나지 않는 지속 가능한 개선 구조를 만들어가고 있습니다
애자일을 도입하고 가장 먼저 마주한 벽은 바로 스토리 포인트 추정이었습니다.
스프린트 계획 회의에서 피보나치 수열(1, 2, 3, 5, 8…)을 기준으로 스토리 포인트를 정해보자고 했지만…
“이게 3인가, 5인가?”
“이 정도면 1 아님?”
막상 숫자를 고르려니 기준이 없어 감을 잡기 어려웠습니다.
팀원 대부분이 스토리 포인트에 대한 경험이 없었고, 비교할 만한 유사 작업도 부족해 추정 결과가 매우 들쑥날쑥했습니다.
어떤 유저 스토리는 3포인트로 추정했지만 실제로 며칠이나 걸리기도 했고, 5포인트였지만 의외로 금방 끝나는 경우도 있었습니다.
이런 시행착오가 반복되면서, 우리는 점차 우리 팀만의 기준과 감각을 갖춰나가기 시작했습니다.
“이 정도 복잡도면 5로 보는 게 맞겠네.”
“전에 했던 그 작업이랑 비슷하니까 3 정도?”
비슷한 경험을 기반으로 관점을 나누는 과정만으로도 팀 전체가 점점 비슷한 추정 감각을 공유하게 되었고, 자연스럽게 예상과 실제 간의 오차도 줄어들기 시작했습니다.
아직도 완벽하지는 않지만, 매 스프린트를 거칠수록 조금씩 더 나아지고 있다는 점에서 의미 있는 변화였습니다.
무엇보다 중요한 점은, 이런 시행착오를 그냥 넘기지 않고 스프린트 회고 시간에 솔직하게 공유했다는 것입니다.
이처럼 팀원 간 피드백을 주고받는 시간을 통해, 문제점을 함께 인식하고 액션 아이템으로 정리했습니다.
그리고 도출된 개선사항은 다음 스프린트에 바로 반영할 수 있도록 체계적으로 관리했습니다.
시행착오를 피하지 않고, 회고를 통해 하나씩 해결해 나가는 루틴이 우리 팀의 애자일 문화 기반이 되었습니다.
📌 아래는 실제 회고에서 도출된 액션 아이템을 시각화해 관리한 예시입니다.
아래는 첫 번째 스프린트와 마지막 스프린트의 주요 지표 비교입니다.
애자일 도입 이후, 계획 수립 정확도와 실행력 모두가 점차 향상되었다는 것을 확인할 수 있습니다.
Sprint | Story Point | Canceled | New | Done | Total Work Item |
|---|---|---|---|---|---|
첫 번째 | 22 | 2 | 3 | 47 | 52 |
마지막 | 31 | 0 | 0 | 54 | 54 |
이처럼 처음보다 더 많은 작업을 예측 가능하고 안정적으로 마무리할 수 있는 팀으로 성장하고 있음을 수치로 확인할 수 있었습니다.
이전에는 진행 상황을 누군가에게 보고하는 방식이 많았지만,
지금은 데일리 스크럼, 리뷰, 회고 등 팀 중심의 소통 루틴이 생기며,
자연스럽게 진행 중인 상황을 공유하고 논의하는 분위기가 만들어졌습니다.
“막히는 부분은 스크럼에서 바로 이야기하자.”
→ 문제 해결 속도가 빨라졌고
→ 서로 도와주는 문화가 생겼습니다.
중요한 결정이나 변경사항은 말로만 하지 않고,
Azure DevOps나 Teams에 코멘트로 남기는 습관이 생겼습니다.
예전에는 그냥 지나쳤던 대화들이 이제는 팀의 기록으로 남아 공유되고 있습니다.
프론트엔드/백엔드/시니어 관계없이 모두가 유저 스토리 정제, 리뷰, 회고에 함께 참여합니다.
예전에는 “지시받은 일”이라는 느낌이 강했다면, 지금은 “내가 맡겠다고 한 일”이라는 인식이 생겼습니다.
유저 스토리를 함께 논의하고, 그 작업을 직접 선택하고, 필요한 정의까지 함께 만들어 가니 자연스럽게 책임감도 커졌습니다.
작업 흐름 전체가 스스로 관리되는 구조로 바뀌었습니다.
“알아서 해”가 아니라 “같이 이해하고, 각자 책임지는” 분위기가 자리잡았습니다.
실수가 생겨도 자연스럽게 회고 시간에 공유합니다.
“이번 스토리는 좀 과했네요…”
“정의가 애매해서 헷갈렸어요…”
서로를 탓하기보다는 무엇을 개선할 수 있을지를 중심으로 논의했습니다.
이후 회고에서 나온 의견은 액션 아이템으로 정리되어 다음 스프린트에 반영되고, 필요한 경우 팀의 루틴에도 반영되었습니다.
이렇게 우리는 더 잘 이야기하게 되었고, 스스로 책임지는 흐름 안에서 일하게 되었습니다.
애자일을 직접 경험한 팀원들은 어떤 생각을 했을까요?
다음은 애자일 방법론 도입 이후 팀원들이 솔직하게 남긴 피드백입니다.
🧑💻 한상훈 매니저
스프린트를 운영하면서, 기간 내에 무엇을 해야 하는지, 어떤 결과를 만들어야 하는지 작업의 목표를 보다 명확하게 이해할 수 있었습니다. 특히 스토리 포인트를 기반으로 작업량의 크기와 난이도를 가늠할 수 있게 되면서, 계획 수립과 업무 분배가 수월해졌습니다. 매 스프린트마다 확인 가능한 결과물이 쌓이는 과정을 통해 우리가 점진적으로 발전하고 있다는 사실도 자연스럽게 체감할 수 있었습니다.
🧑💻 조하은 매니저
애자일하게 일한다는 말은 익숙했지만, 실제로 애자일 방식의 핵심을 이해하고 팀원들과 배경지식을 공유하며 일하니, 일하는 방식에 대한 공감대가 생겨 훨씬 유기적으로 협업할 수 있었습니다. 2주 단위로 결과물을 점검하고 피드백을 반영하면서 점진적으로 완성도를 높여갔고, 그 덕분에 최종 데드라인에도 계획한 결과물을 무리 없이 맞출 수 있었습니다. 반복적으로 검토하고 개선하는 애자일의 사이클이 실제 업무 흐름에 잘 녹아들어 생산성과 만족도가 모두 높았습니다.
🧑💻 박결 매니저
올해 초 '함께 자라기'라는 책을 읽으며 애자일 방법론에 대해 깊이 고민해볼 기회가 있었습니다. 당시에는 "좋은 건 알겠는데, 이 방식이 과연 우리 팀에 필요할까?"라는 의문이 있었지만, 직접 애자일을 도입하고 실천하면서 많은 곳에서 애자일 방법론을 도입하는 이유를 체감할 수 있었습니다.
도입 초기에는 우여곡절도 많았고, 익숙하지 않아 어려운 점도 적지 않았지만, 스프린트를 반복할수록 점점 팀의 호흡이 맞아간다는 것을 느꼈습니다. 가장 기억에 남는 건 백로그 정제 시간이었습니다. 하나의 유저 스토리에 대해 다양한 관점에서 의견을 나누고, 이를 통해 요구사항을 구체화하는 과정은 쉽지 않았지만 의미 있는 경험이었습니다.
이러한 과정을 통해 우리가 진짜 만들고자 하는 것이 무엇인지 더 명확히 이해할 수 있었고, 결과적으로 프로덕트의 완성도도 높아졌다고 느꼈습니다.
