Backlog Refinement와 AI: 실제로 무엇이 바뀌는가

AI가 Backlog Refinement를 어떻게 바꾸는지에 대한 실용적 분석: 무엇이 빨라지고, 어디서 리스크가 생기며, 팀의 시간이 어떻게 재분배되고, 무엇을 수동으로 확인해야 하는지.

26 Mar 2026 · 06:54 UTC18 분 소요

이 글은 AI가 크로스펑셔널 개발 팀의 고전적인 회의를 어떻게 바꾸는지 다루는 시리즈의 첫 번째 글입니다. 아래에서는 Backlog Refinement부터 시작하고, 다음 자료들에서는 Planning, Daily, Review, Retrospective를 각각 따로 다룬 뒤 마지막에 모든 내용을 종합한 개요 글로 정리하겠습니다.

먼저 범위를 명확히 하겠습니다. 아래에서 말하는 refinement는 반드시 별도의 공식 Scrum 이벤트를 뜻하는 것이 아니라, backlog items를 명확히 하는 정기적인 팀 세션과 실무를 의미합니다. 용어의 정확성을 위해 이 점이 중요합니다. Scrum Guide 2020 (RU PDF) 에서 refinement는 독립적인 event가 아니라 ongoing activity로 설명됩니다. Scrum Guide 2020 러시아어판에는 이 생각이 직접적으로 표현되어 있습니다. Product Backlog 정교화는 세부 사항, 순서, 크기를 추가하는 지속적인 활동입니다.

Backlog Refinement는 AI가 팀에 꽤 체감되는 이점을 주기 시작하는 첫 번째 지점 중 하나입니다. AI는 맥락을 더 빨리 모으고, 요구사항 초안을 준비하고, 인수 기준 초안을 빠르게 생성하고, 유사한 사례를 찾고, 열린 질문 목록을 정리하는 데 도움을 줍니다. 이런 주장은 더 실무적인 연구들에서도 뒷받침됩니다. 예를 들어 LLM-Assisted Requirements Engineering in Agile MDD 에서는 acceptance criteria 생성이 별도로 검증되었고, 산업 사례 Acceptance Test Generation with Large Language Models 에서는 사용자들이 AI 시나리오가 이전에 놓쳤던 사례를 발견하는 데 도움이 되었다고 언급했습니다. 바로 그래서 여기서 함정에 빠지기 특히 쉽습니다. 잘 정리된 초안을 정말로 이해 가능한 작업과 혼동하는 것입니다.

제 생각에 AI는 팀이 이제 덜 생각해도 된다는 의미에서 refinement를 단순화하지 않습니다. 오히려 AI는 그 주변의 가장 비싼 수작업, 즉 검색, 요약, 패키징, 1차 분해를 더 저렴하게 만듭니다. 따라서 팀 논의 자체의 가치는 사라지지 않고 이동합니다. 혼돈에서 작업처럼 보이는 무언가를 조립하는 데 드는 시간은 줄고, 이것을 실제로 작업에 착수할 수 있는지 이해하는 데 드는 시간은 늘어납니다.

“AI는 팀의 합의 자체가 아니라 그 합의를 위한 자료 준비를 가속한다”

왜 Backlog Refinement에서 변화가 가장 먼저 느껴지는가

Agile 실무에서 익숙한 팀 리추얼과 회의를 보면, refinement는 AI의 등장에 가장 민감한 것 중 하나입니다. 이유는 꽤 단순합니다. refinement 주변에는 역사적으로 수작업 지적 루틴이 많았습니다. 문서, 오래된 티켓, 대화, 사람들의 기억에서 흩어진 맥락을 모아야 합니다. 거친 비즈니스 아이디어를 이해 가능한 backlog item으로 바꿔야 합니다. 비즈니스 문제, 시나리오, 인수 기준, 제약, 열린 질문, 의존성, 가능한 경계 사례를 공식화해야 합니다.

AI는 바로 이 층에 특히 잘 들어맞습니다. 이는 오늘날 requirements engineering에서 LLM 적용을 논의하는 방식과도 잘 맞습니다. 모델은 요약, 요구사항의 1차 구조화, 초안 생성, 분석적 준비 지원에 강하지만, 도메인 정확성, 추적성, 최종 결정에 대한 책임이 필요한 곳에서는 약합니다. 그런 의미에서 refinement는 실제로 AI의 이점이 빠르게 느껴지고 동시에 신뢰성의 한계도 거의 즉시 드러나는 첫 번째 프로세스 중 하나가 됩니다. 이에 대해서는 개요 Challenges in applying large language models to requirements engineering tasks, 최신 체계적 문헌 고찰 Large Language Models (LLMs) for Requirements Engineering (RE): A Systematic Literature Review, 더 실무적인 연구 LLM-Assisted Requirements Engineering in Agile MDD에서도 잘 다루고 있습니다.

팀이 AI와 Agile 아티팩트를 활용해 backlog item을 분석하는 모습 — AI는 refinement 준비를 잘 가속하지만, 의미에 대한 집단적 검증을 대체하지는 않는다.

AI 이전의 refinement는 어땠는가

단순화해서 말하면, AI 이전의 refinement는 매우 자주 이해를 수작업으로 조립하는 과정이었습니다. backlog에는 완성된 작업이 아니라 오히려 비즈니스 의도가 들어갔습니다. onboarding 개선, 알림 추가, 관리자에게 새 보고서 제공, 기한이 지난 문의 수 줄이기 같은 것입니다. 그다음 Product Owner, 분석가 또는 리드 중 누군가가 수동으로 맥락을 모으기 시작했습니다. 오래된 고객 문의, 유사한 기능, 현재 아키텍처의 제약, 유효한 상태, 기존 알림, UI 패턴 등 논의 중에 갑자기 떠오를 수 있는 모든 것이 동원되었습니다.

그다음 같은 사람 또는 몇 사람이 수동으로 수집한 내용을 첫 초안으로 바꾸려 했다. 비즈니스 문제를 정리하고, 시나리오를 설명하고, 인수 기준을 작성하고, 열린 질문을 꺼내고, 가능한 제약을 표시하는 일이었다. 하지만 그런 초안이 이미 존재하더라도 회의는 여전히 팀 전체의 머릿속에 맥락을 다시 올리는 데 자주 쓰였다. 제품 책임자는 비즈니스가 원하는 것을 다시 설명했고, 분석가는 이미 밝혀낸 것을 이야기했고, 개발자들은 아키텍처 제약을 꺼냈고, QA는 경계 시나리오를 끌어냈고, 디자이너와 프런트엔드는 별도 화면이 필요한지, 그리고 그것이 어디에 들어갈지를 논의했다.

같은 케이스: AI 없이, 그리고 AI와 함께

일반적인 공식에 머물지 않기 위해 구체적인 케이스를 하나 들겠다. 제품은 기업 교육용 B2B LMS 플랫폼이다. 대형 고객은 직원에게 컴플라이언스, 보안, 내부 규정에 관한 필수 과정을 배정한다. 비즈니스에서 요청이 온다. 마감일까지 필수 과정을 완료하지 않은 직원에게 자동 이메일 알림을 추가해야 한다는 것이다.

언뜻 보면 이메일을 보내는 단순한 작업처럼 보인다. 하지만 첫 단계부터 실제로는 갈림길이 많다는 것이 분명해진다. 누구를 정확히 과정 미완료로 볼 것인지, 언제 알림을 보낼지, 발송을 어떻게 중복 제거할지, 고객이 이를 어떻게 설정하는지, 발송 로그가 필요한지, 시간대는 어떻게 할지, 이메일 언어는 무엇으로 할지, 보관 처리된 사용자와 비활성화된 사용자를 제외해야 하는지 등이다.

AI 없이 하는 방식에서 팀은 주로 긴 수동 준비와 회의에서의 방대한 대화를 통해 이런 질문에 도달했다. 먼저 제품 책임자가 고객 맥락을 꺼냈다. 그다음 분석가가 내부 자료를 직접 훑었다. 비슷한 과거 요청을 찾고, 알림 서비스를 살펴보고, 현재 assignment 상태, 스케줄러 작업의 존재, 언어 설정 필드와 시간대 필드를 확인했다. 이미 이 단계에서 실제 제약이 드러났다. 시스템에는 이메일 템플릿이 있지만 트랜잭션 이메일용뿐이고, 시간대는 사용자가 아니라 고객 수준에 저장되며, 발송 로그가 없고, 제품에 별도의 알림 모델도 없다.

그 후 분석가가 수동으로 요구사항의 첫 초안을 작성했지만 여전히 미성숙한 상태였다. 예를 들어 어떤 정확한 상태에서 알림을 보내야 하는지, 중복 제거 로직, UI를 위한 최소 작업 범위, 언어 fallback, 첫 버전의 경계가 확정되지 않았을 수 있다. 그리고 refinement에서 팀은 대화 도중에야 작업을 마저 정리했다. 바로 그 자리에서 알림은 필수 과정에만 필요하다는 것, 상태 not_started 와 in_progress 는 적합하지만 expired 는 첫 버전에 넣지 않는 편이 낫다는 것, 발송 저널이 없으면 지원팀과 고객 지원팀이 금세 질문에 파묻힌다는 것, 별도 보호 장치가 없으면 스케줄러 작업이 다시 실행될 때 중복이 생긴다는 것이 밝혀졌다.

AI와 함께하는 방식에서 같은 케이스는 다르게 보인다. 제품 책임자는 고객 지원팀의 요약, 최근 고객 문의, 원본 요청을 AI에 업로드한다. AI는 고객의 고통을 빠르게 묶고, 반복되는 기대를 추려내며, 문제 진술을 정리하도록 돕는다. 분석가는 AI에게 알림 흐름, 배정 상태, 스케줄러 작업, 언어 설정, 시간대, Jira의 유사 작업과 관련된 모든 것을 끌어오라고 요청한다. 백엔드는 현재 알림 아키텍처 설명을 미리 AI에 돌려 기술적 접근을 제안해 달라고 한다. 프런트엔드와 디자이너는 설정과 발송 이력을 어디에 넣는 것이 더 논리적인지 빠르게 확인한다. QA는 경계 사례와 시간 관련 위험의 초기 목록을 올린다.

여기서 보통 자연스러운 질문이 생긴다. AI가 무언가를 놓쳤다면 어떡하지? 특히 소스 기반이 클 때 이런 짧은 요약을 얼마나 신뢰할 수 있을까? 연구와 실무 사례는 여기서 꽤 냉정한 그림을 보여준다. LLM은 실제로 사용자 스토리, 인수 기준 초안, 1차 요구사항 생성 속도를 높일 수 있지만, 결과의 품질은 입력 맥락, 도메인, 이후의 인간 검토에 크게 좌우된다. 따라서 AI-Generated User Stories: Are They Good Enough? 와 LLM-Assisted Requirements Engineering in Agile MDD: 같은 더 실용적인 작업도 염두에 두는 것이 좋다. 이들은 강한 초안 생성과 개발 준비 완료가 같은 것이 아니라는 점을 잘 보여준다.

Cursor를 실무에서 사용한 제 경험상, 모델이 대량의 소스 배열에서 필요한 첫 번째 초안을 만들어낼 수 있는지에 대해 의심하는 경우는 꽤 드뭅니다. 훨씬 더 중요한 것은 다른 점입니다. 즉, 제가 과제를 얼마나 잘 정식화했는지, 어떤 제약을 설정했는지, 어떤 명확화 질문을 미리 추가했는지, 그리고 결과 검증을 어떻게 조직했는지입니다. 의심이 들 때 저는 "AI를 믿을까 말까"라는 질문으로 그것을 해결하려 하지 않고, 그저 요청을 더 명확히 하고, 소스를 별도로 보여 달라고 하며, 논쟁적인 부분을 분리해 달라고 하고, 사실과 가정을 구분하거나 다른 프레임으로 답변을 재구성해 달라고 요청합니다. 이런 의미에서 AI와의 작업은 코칭과 매우 비슷합니다. 단순히 생성을 촉발하는 것이 아니라 모델의 사고를 필요한 방향으로 이끄는 정확한 질문을 던지는 능력이 유용합니다.

물론 이것은 보편적인 규칙이 아니라 제 개인적인 경험입니다. 어쩌면 AI에 대한 신뢰, 명확화 질문의 품질, 관리 가능한 결과 검증에 관한 자료를 별도로 하나 더 쓸 수도 있습니다. refinement에서는 이것이 특히 중요합니다. 소스 기반이 클수록, 요약이 설득력 있을수록, 강력한 준비를 이미 검증된 이해와 혼동할 위험이 커집니다.

“소스 기반이 클수록, 요약이 설득력 있을수록, 강력한 준비를 이미 검증된 이해와 혼동할 위험이 커집니다”

그 결과 팀은 refinement에 더 이상 날것의 아이디어가 아니라 꽤 강력한 초안을 가지고 옵니다. 사용자 스토리 초안, 인수 기준 초안, 열린 질문, 리스크 목록, 사전 기술 접근 방식, UI 제안이 있습니다. 그래서 회의 자체가 더 짧고 더 구체적으로 변합니다. 팀은 더 이상 기본 맥락을 끌어올리는 데 그렇게 많은 시간을 쓰지 않고 주로 논쟁적인 부분을 논의합니다. expired,를 포함할지, 사용자별 별도 시간대를 둘지, 첫 릴리스에 발송 로그가 필요한지, 고정 트리거로 제한할지, 중복을 어떻게 방어할지, 그리고 첫 버전의 경계를 무엇으로 볼지입니다.

팀의 진전은 무엇인가?

팀이 AI를 막 사용하기 시작할 때, AI는 주로 빠른 첫 초안 생성기로 작동합니다. 그러나 성숙해짐에 따라 다음의 논리적인 단계는 일반 모델만으로 작업하는 것을 그치고, 이전에는 사람들의 기억 속에만 있던 것을 점차 팀의 관리 가능한 컨텍스트로 옮기기 시작하는 것입니다. 여기에는 제품 원칙, 인수 기준 템플릿, refinement에서 과제가 거부되는 빈번한 이유, 전형적인 경계 사례, 아키텍처 제약, 표준 명확화 질문 세트, 조직의 내부 규정, 조직 및 팀 수준의 Definition of Ready와 Definition of Done, 그리고 유사한 사례에 대한 좋은 해결책의 예가 포함될 수 있습니다.

그러면 첫 초안의 품질이 실제로 오르기 시작합니다. 모델이 갑자기 "도메인을 스스로 이해"했기 때문이 아니라, 팀이 자신들의 사고 패턴, 내부 제약, 검증 규칙을 체계적으로 AI에 내보내는 법을 배웠기 때문입니다. 그리고 여기서 refinement는 과제를 검증하는 장소일 뿐만 아니라, 팀이 점차 자신들만의 AI 계층을 훈련시키는 장소가 됩니다.

역할별로 무엇이 바뀌는가

아래에서는 역할을 추상적인 기능으로만 보는 것이 아니라, 필수 과정 알림에 관한 모델링된 사례에서의 구체적인 행동으로 보는 것이 유용합니다. 바로 그렇게 해야 AI가 없는 모드와 AI가 있는 모드의 차이가 진정으로 두드러집니다.

역할	AI 없이	AI와 함께
제품 오너	고객 맥락을 수동으로 끌어올리고, 고객 지원 팀의 요청을 취합하며, 회의에서 비즈니스 문제를 다시 설명한다.	익명화된 입력을 준비하고, AI에게 고객의 고통을 그룹화해 달라고 요청하며, 회의에 문제 정식화 초안과 논쟁적인 제품 결정 목록을 가져온다.
비즈니스 분석가	유사 사례를 찾고, 상태, 제약, 의존성을 수동으로 수집한 뒤, 그것을 모두 첫 번째 정식화 초안으로 다시 쓴다.	소스에 대한 AI 요청을 조직하고, 요약을 소스와 대조하며, 인수 기준을 편집하고, 열린 질문과 모델이 놓쳤을 수 있는 것을 기록한다.
백엔드 개발자	종종 refinement에서 처음으로 문제를 깊이 파고들며, 논의 도중에 알림 서비스의 제약과 중복 리스크를 끌어올린다.	회의 전에 기술 대안에 대한 첫 패스를 받고, 중복 제거, 스케줄러 작업, audit trail, 첫 버전의 경계를 미리 확인한다.
프론트엔드 개발자	회의에서 디자이너와 함께 별도 화면이 필요한지, 설정이 어디에 있어야 하는지, 최소 UI에 실제로 무엇이 포함되는지 파악하려 한다.	회의 전에 UI 내장 초안을 보고, 설정, 상태, 인터페이스 제약에 관한 논쟁적인 부분을 미리 표시한다.
품질 엔지니어 / QA 엔지니어	주로 회의에서 합류하고, 부정 시나리오, 상태 충돌, 시간 리스크를 이미 공통 대화 속에서 끌어낸다.	회의 전에 경계 사례의 시작 목록을 받고, AI가 중복, 시간대, 언어 fallback 시나리오, 사용자 상태에 따른 예외를 놓치지 않았는지 확인한다.
UX/UI 디자이너	논의 도중에 과제를 파악하고, 그 자리에서 새 화면, 설정 블록, 발송 이력이 필요한지 가늠한다.	프론트엔드와 함께 여러 UI 접근 방식을 빠르게 테스트하고, 백지 상태가 아닌 의미 있는 제안을 가지고 옵니다.
스크럼 마스터	참가자를 모으고, 시간을 지키며, 혼란스러운 컨텍스트 구축 속에서 길을 잃지 않도록 돕고, 논의가 옆길로 새면 팀을 본질로 되돌립니다.	조직적 메커니즘과 기본 컨텍스트 정렬에 쓰는 시간을 줄이고, 논쟁적인 결정의 퍼실리테이션, 미해결 질문 기록, 논의 품질 관리에 더 많은 시간을 씁니다.

장점, 리스크 및 확보되는 시간

리파인먼트에서 AI의 효용은 상당히 체감됩니다. 컨텍스트가 더 빨리 모이고, 작업 초안이 더 빨리 생기며, 논의가 더 쉽게 시작되고, 결과물이 더 잘 정리됩니다. 그러나 바로 리파인먼트에서 AI의 리스크도 매우 일찍 드러납니다. 가장 명백한 리스크는 거짓 명확성입니다. AI는 시각적·구조적으로 보기 좋은 깔끔한 백로그 항목을 만들 수 있습니다. 이 때문에 팀은 작업이 여전히 제품적·기술적 구멍을 안고 있음에도 이미 이해했다는 느낌에 스스로 속기 쉬워집니다.

여기서는 사물을 제 이름으로 부르는 것이 유용합니다. 첫째는 자동화 편향 과 과도한 의존, 즉 시스템의 권고를 지나치게 쉽게 받아들이고 능동적 검증에서 보다 수동적 모니터링으로 넘어가는 경향입니다. 생성형 AI를 위한 NIST 프로파일 에서는 이를 AI 시스템에 대한 과도한 신뢰로 직접 설명하며, 실증 연구 AI 의사결정 지원에서의 자동화 편향: 실증 연구 결과 에서는 시스템의 높은 인지된 유용성이 오류에 대한 거짓 동의를 높일 수 있는 반면, 사용자 교육의 질은 그러한 효과의 가능성을 낮춘다는 것을 보여줍니다. 둘째는 모델 환각 — 그럴듯하지만 출처로 확인되지 않은 결론입니다. 리파인먼트에서 이는 특히 중요합니다. AI는 거의 항상 문서, 티켓, 대화의 요약을 통해 작동하므로, 리스크는 “아름답지만 지어낸 인수 기준 초안”에만 있는 것이 아니라 원본 컨텍스트의 조용한 왜곡에도 있습니다. 그래서 리파인먼트에서 AI는 텍스트 스타일보다 컨텍스트의 사실에서 더 자주 틀리며, 이 리스크는 추상적 요약에서의 충실성과 사실성. 여기서 실질적 해독제는 꽤 간단합니다. 모델에게 사실과 가설을 분리하도록 요청하고, 출처 링크를 요구하며, 문서·티켓·팀 결정까지 빠르게 되짚을 수 있도록 간결한 요약을 만들게 하는 것입니다.

또 하나의 리스크 층이 있습니다 — 데이터입니다. 위 사례에서 AI는 고객 문의, 내부 시스템 설명, 사용자 신호를 다룹니다. 따라서 팀은 무엇을 모델에 전달할 수 있고 무엇은 안 되는지 미리 합의하는 것이 중요합니다. 생성형 AI의 리스크는 프롬프트에만 국한되지 않습니다. 개인 데이터는 입력, 출력, 심지어 모델의 암기/재생을 통해서도 나타날 수 있습니다. 따라서 업무에 개인 데이터나 민감한 고객 컨텍스트가 등장한다면 기본적인 데이터 위생 원칙은 필수여야 합니다. 프롬프트 내 데이터 양을 최소화하고, 가능하면 입력을 익명화하고, 필터링 없이 원시 내보내기를 모델로 끌어오지 않고, 처리 목적을 명확히 이해하며, “우리는 개인 데이터를 처리하지 않습니다” 또는 “모델은 익명입니다” 같은 제공자의 주장을 검증 가능한 조직적·기술적 통제 없이 믿지 않는 것입니다. 별도로 처리의 법적 근거, 최소 필요 필드 집합, 프로세스 내 역할과 책임, 그리고 적용되는 경우 데이터 주체에 대한 고지 요건을 미리 정해 두는 것이 유용합니다. 시나리오에 개인 데이터가 포함되고 규모나 리스크가 두드러진다면 DPIA가 필요한지 미리 평가하고 그 결정을 별도로 기록할 만합니다. 유럽 맥락에서는 이는 GDPR 제5조, AI 시스템 개발에 관한 CNIL의 실무 권고, 그리고 생성형 AI에 관한 EDPS 지침 및 EDPB 의견 28/2024.

그리고 여기서 또 하나의 중요한 질문이 생깁니다. 전문가들의 확보된 시간은 어디로 가는가? 가장 단순한 선택은 그 안에 더 많은 작업을 밀어넣으려는 것입니다. 더 성숙한 선택은 이 절약분을 결정의 질, 기술 부채 감소, 내부 템플릿 개발, 교육, 문서화, 그리고 적어도 팀 주의력의 더 나은 관리에 투자하는 것입니다. 시리즈의 마지막 개관 기사에서 AI가 프로세스뿐 아니라 팀 시간 사용의 문화도 바꾼다는 점을 별도로 다루겠습니다.

무시할 수 없는 새로운 숨은 비용

효율성에 관한 논의가 지나치게 매끄럽게 보이지 않도록 반대 측면도 덧붙이는 것이 중요합니다. AI는 새로운 유형의 작업 없이 “순수한 절약”을 주는 경우가 드뭅니다. 이제 일부 시간은 데이터 준비, 소스 접근 설정, 프롬프트와 템플릿 유지보수, 출처 검증, 결정 문서화, 인간 검토에 쓰입니다. 이러한 관점은 생성형 AI의 리스크 관리 실무와도 잘 맞습니다. 예를 들어 생성형 AI를 위한 NIST 프로파일 자동화의 이점뿐만 아니라 oversight, documentation 및 관리적 통제의 필요성도 강조합니다.

Backlog Refinement 1회당 작업량 시나리오 추정(시나리오)

아래는 "시장 평균"이 아니라, 동일한 7인 팀(PO, BA, 백엔드, 프론트엔드, QA, designer, 스크럼 마스터)이 수행하는 동일한 Backlog Refinement에 대한 시나리오 모델입니다. 이는 작고 잘 이해된 story가 아니라, 하나의 크거나 상당히 불확실한 backlog item에 대한 추정입니다. 이 수치의 가치는 분 단위 정확도가 아니라 비용 구조의 비교에 있습니다. 즉, 예전에는 시간이 어디로 갔고 지금은 어디로 가는지입니다.

이제부터는 회의 자체의 소요 시간이 아니라, 하나의 큰 backlog item에 대한 인시(사람-시간) — 준비, 논의, 회의 후 짧은 보완 — 를 말합니다. 회의 자체도 보통 단축되지만, 일부 작업은 비동기 준비, 추가 확인 실행, 필수 수동 검증으로 옮겨갈 뿐입니다.

작업량 계산에 대한 참고: 과거에는 Scrum Guide 2017 (RU PDF) 에서도 refinement가 ongoing process로 설명되었고, 개발 팀의 가용 용량의 10%를 넘지 않는 것이 보통이라는 기준이 있었습니다. Scrum Guide 2020 (RU PDF) 에는 이 기준이 더 이상 없으므로, 아래 표는 규범이 아니라 두 운영 모드를 비교하기 위한 시나리오 모델로 읽는 것이 좋습니다.

별도로 분명히 해둘 점: 아래 "AI 사용" 열에는 이 시나리오가 작동하기 위한 기본적인 새로운 작업 — 입력 데이터 준비, 추가 질의, 요약 초안의 1차 검토, 논쟁 지점 검증, 최소한의 인간 검토 — 이 이미 포함되어 있습니다. 즉, 표의 최종 이익은 새로운 비용을 고려하기 전의 "순수한" 절감이 아니라, 이를 기본적으로 포함한 후의 보다 현실적인 시나리오 추정입니다.

이 추정을 재현 가능하게 하려면 간단한 공식으로 계산하는 것이 편리합니다: T_AI = T_base × ((1 − p) + p × s) + o. 여기서 T_base 는 AI 없는 시간, p 는 가속되는 작업의 비율, s 는 해당 부분의 가속 계수, o 는 데이터 준비, 추가 질의, 결과 검증을 위한 새로운 작업입니다.

아래는 바로 이 기본 시나리오에 맞춘 보정된 예시입니다. 이 예시의 목적은 보편적 기준을 증명하는 것이 아니라, 동일한 모델이 하나의 구체적 사례에서 표의 수치를 어떻게 재현할 수 있는지 보여주는 것입니다. 실제 팀에서는 이러한 매개변수를 최근 3–5회의 Backlog Refinement로 보정한 뒤 자신만의 범위를 얻는 것이 좋습니다.

# Calibrated to reproduce the table (base scenario)
# T_ai = T_base * ((1 - p) + p * s) + o
roles = {
    "PO": {"T_base": 4.5, "p": 0.75, "s": 0.20, "o": 0.7},
    "BA": {"T_base": 10.0, "p": 0.70, "s": 0.20, "o": 0.6},
    "BE": {"T_base": 3.5, "p": 0.75, "s": 0.20, "o": 0.6},
    "FE": {"T_base": 3.0, "p": 0.75, "s": 0.20, "o": 0.3},
    "QA": {"T_base": 3.0, "p": 0.50, "s": 0.20, "o": 0.2},
    "UX": {"T_base": 3.0, "p": 0.50, "s": 0.20, "o": 0.2},
    "SM": {"T_base": 2.5, "p": 0.50, "s": 0.20, "o": 0.0},
}

def t_ai(x):
    return x["T_base"] * ((1 - x["p"]) + x["p"] * x["s"]) + x["o"]

total_base = sum(r["T_base"] for r in roles.values())
total_ai = sum(t_ai(r) for r in roles.values())

print("Total base:", round(total_base, 1))
print("Total AI:", round(total_ai, 1))
print("Gain:", round(total_base - total_ai, 1))

for role, x in roles.items():
    print(role, round(t_ai(x), 1))

역할	AI 없음	AI 사용(새 작업 포함)	무엇이 바뀌는가
제품 책임자	4.5시간	2.5시간	고객 맥락을 더 빨리 수집하지만, 입력 준비와 추가 질의에 일부 시간을 씀
비즈니스 분석가	10시간	5시간	수동 검색과 재작성이 줄고, 검증, 편집, AI가 중요한 것을 놓치지 않았는지 확인하는 데 더 많은 시간을 씀
백엔드 개발자	3.5시간	2시간	첫 기술 분석을 더 빨리 얻지만, 아키텍처 제약과 중복 위험을 별도로 확인함
프론트엔드 개발자	3시간	1.5시간	UI 통합과 설정을 더 빨리 평가하지만, 논쟁 지점 검증에 더 일찍 참여함
품질 엔지니어 / QA 엔지니어	3시간	2시간	경계 사례와 시간적 위험을 더 일찍 얻지만, 누락과 부정 시나리오 검증에 더 많이 관여함
UX/UI 디자이너	3시간	2시간	첫 UI 접근 방안을 더 빨리 수집하고 불필요한 인터페이스 옵션을 미리 걸러냄
스크럼 마스터	2.5시간	1.5시간	조직적 맥락 정렬에 드는 시간이 줄고, 결정 촉진과 미해결 질문 기록에 더 많은 시간을 씀
합계	29.5시간	16.5시간	시나리오 이익 — 기본적인 새로운 작업을 고려한 후에도 이러한 Backlog Refinement 1회당 약 13 인시

시나리오 범위: 이익이 어떻게 달라질 수 있는가

시나리오	AI 없음	AI 사용	순수 이익	이런 경우
신중	24–28시간	18–21시간	4–10시간	출처가 불완전하고 수동 검증이 많으며, 팀이 이제 막 AI 작업 템플릿을 구축하는 중입니다.
기본	28–32시간	15–18시간	10–15시간	모델링된 사례가 대략 이렇게 보입니다: AI가 준비를 잘 가속하지만 검증을 위한 새로운 작업이 이미 고려되어 있습니다.
강함	30–36시간	14–17시간	13–19시간	팀에 좋은 출처, 반복 가능한 템플릿, 데이터 위생과 수동 검증에 대한 명확한 규칙이 있습니다.

AI 시나리오에 이미 고려된 새로운 작업

아래 표는 첫 번째 표의 최종 이익을 무효화하지 않습니다. 단지 어떤 새로운 행동으로 인해 절감된 시간의 일부가 다시 프로세스로 돌아가는지, 그리고 그럼에도 불구하고 순효과가 여전히 눈에 띄는 이유를 설명할 뿐입니다.

새로운 작업 영역	AI와 함께 나타나는 것	왜 필요한가
입력 데이터 준비	정리, 익명화, 필요한 맥락 추출	모델에 쓰레기를 과부하시키지 않고 불필요한 데이터를 끌어오지 않기 위해
추가 질의	반복 실행, 답변 범위 명확화, 사실과 가정 분리 요청	첫 번째 그럴듯한 답변을 최종 이해로 받아들이지 않기 위해
템플릿 설정	프롬프트, 스토리 템플릿, 결과 형식 규칙	AI가 무작위 텍스트가 아니라 유용하고 반복 가능한 초안을 내도록 하기 위해
사실 검증	출처 링크, 용어, 상태, 제약 검증	회의 전에 모델의 환각과 거짓 명확성을 잡아내기 위해
신뢰 문서화	수동으로 무엇을 확인했고 왜 그 결과를 신뢰할 수 있는지 기록	팀이 예쁜 초안으로 책임을 바꿔치기하지 않도록 하기 위해

단계별 차이

단계	AI 없이	AI와 함께
회의 전 맥락 수집	문서, 티켓, 사람들의 기억을 오래 수동으로 검색	출처에 대한 첫 패스와 간단한 요약이 눈에 띄게 빨라짐
작업 정의 초안	수동으로 작성되며 종종 미완성으로 남음	팀이 비판하고 다듬을 수 있는 강력한 초안이 있음
Backlog Refinement 자체	이해를 맞추는 데 많은 시간이 소요됨	초점이 논쟁적인 결정, 의존성, 첫 버전의 경계로 이동함
회의 후 다듬기	작업 정의를 거의 처음부터 다시 작성해야 하는 경우가 많음	결과물이 이미 잘 정리되어 있어 수동 보완이 덜 필요함

refinement를 위한 AI 준비 품질 체크리스트

중요: 이 Definition of Ready는 팀의 내부 관행이며 Scrum Guide의 일부가 아닙니다. 여기서는 AI 준비 과정에서의 거짓 명확성, 누락, 모호한 책임을 방지하기 위한 장치로 필요합니다.

AI 초안을 위한 Definition of Ready

사실과 가정이 분리됨: 팀은 무엇이 출처에서 가져온 것인지, 무엇이 모델이 제안한 것인지 이해함.

핵심 제품 및 기술 주장에 대한 출처 링크 또는 명확한 지시가 있음.

열린 질문이 깔끔한 텍스트 아래 숨겨지지 않고 명시적으로 드러남.

도메인 용어, 상태, 제약, 역할, 의존성이 검증됨.

각 핵심 주장에 대해 증거 수준이 명확함: 출처의 사실인지, 작업 가설인지, 모델의 가정인지.

경계 사례, 부정적 시나리오, 시간적 위험이 별도로 검증됨.

어떤 데이터를 모델에 전달할 수 없었는지, 어떤 데이터 위생 조치가 적용되었는지 명확함.

주장 유형별 검증 담당자가 지정됨: 비즈니스 로직, 아키텍처 실현 가능성, 테스트 가능성, 데이터 처리.

팀은 AI 초안이 거의 완성된 작업이 아니라 토론을 위한 원료라는 데 합의함.

이 체크리스트가 너무 추상적으로 남지 않도록, email 알림 사례에서 어떻게 보일지 살펴보겠습니다:

AI는 상태 not_started, in_progress 및 expired 를 포함하자고 제안함 — 팀은 expired 가 첫 버전에 대해 확인된 규칙이 아니라 아직 가설임을 명시적으로 표시함.
간단한 요약에는 사용자의 타임존에 따라 알림을 보내야 한다고 되어 있음 — 백엔드는 이를 출처와 대조하고 현재 시스템에서 타임존이 클라이언트 수준에서만 저장되며 시간대 간 전환과 DST는 별도로 확인해야 함을 확인함.
AI는 발송 이력을 솔루션의 "당연한" 부분으로 추가함 — 제품 책임자와 BA는 이것이 첫 버전의 필수 부분인지 다음 릴리스의 개선인지 별도로 결정하는데, 여기에는 감사와 지원 부하 문제도 있기 때문임.
QA는 단순한 경계 사례 목록이 아니라 스케줄러 작업 재실행 시 중복, 언어 fallback 시나리오, archived 및 비활성화된 사용자 예외, 마감 기한 관련 부정적 시나리오를 확인하는 구체적인 과제를 받음.
백엔드는 rate limits, throttling, deliverability, 재발송 및 제공자 오류 시 시스템 동작을 별도로 확인함.
PO와 BA는 알림 정책을 추가로 검증함: 누구에게 알림을 보낼 수 있는지, 어디에 opt-out 또는 고객 예외가 필요한지, 필수 과정에 대해 허용되는 동작은 무엇인지.

이런 사례에서는 프로덕션에 가까워질 때 자주 떠오르는 두 가지 실무 사항도 별도로 논의하는 것이 유용합니다: "왜 이메일이 도착하지 않았는지"에 대한 제대로 된 진단이 없으면 deliverability가 빠르게 지원 및 고객 지원 팀의 부하로 변하고, quiet hours와 캘린더 윈도우는 종종 "추가 옵션"이 아니라 고객사의 기업 요구사항이 됩니다.

누가 무엇을 수동으로 검증하는가

무엇을 검증하는가	담당자	LMS 사례의 예
목표 및 제품 정책	PO와 BA	누구에게 언제 알림을 보낼지, 어떤 예외가 허용되는지, 첫 버전의 경계는 어디인지.
규칙 및 상태의 정확성	BA	어떤 상태가 "미완료"로 간주되는지, `expired` 를 어떻게 처리할지, 그리고 이것이 출처에서 어디까지 확인되었는지.
아키텍처 제약	백엔드 개발자	중복 제거, 스케줄러 작업, 멱등성, 감사 로그, rate limits, 재발송 시 동작.
첫 버전의 UI 경계	프론트엔드 개발자 및 UX/UI 디자이너	설정이 어디에 있는지, 별도 이력 화면이 필요한지, 어떤 인터페이스 시나리오가 실제로 첫 버전에 포함되는지.
부정적 및 시간적 시나리오	품질 엔지니어 / QA 엔지니어	DST, 타임존, 언어 fallback 시나리오, archived 및 비활성화된 사용자 예외, 스케줄러 작업 재실행 시 중복.
결정 및 열린 질문 퍼실리테이션	스크럼 마스터	무엇이 이미 결정되었는지, 무엇이 여전히 논쟁적인지, 팀이 어디서 의식적인 타협을 해야 하는지.
데이터 위생 및 데이터 허용성	PO/BA 및 있는 경우 Security 또는 DPO	모델에 무엇을 전달할 수 있는지, 무엇을 익명화해야 하는지, AI 준비 실행 전 어떤 검증이 필수인지.

팀에 권하고 싶은 것

AI 초안이 잘 보인다는 이유만으로 완성된 작업으로 간주하지 말 것.
회의 전에 팀이 수동으로 확인해야 하는 컨텍스트 부분과 회의 중에 확인해야 하는 부분을 명확히 합의한다.
공용 채팅을 "있는 그대로" 사용하는 것에 그치지 않고, 자체적인 제품 및 프로세스 패턴을 점진적으로 팀 AI 레이어로 이전한다.
준비가 빨라졌다는 이유만으로 refinement를 기계적으로 축소하지 않는다.
확보된 시간을 품질, 학습, 문서화, 기술 부채, 또는 팀의 주의력 회복 중 어디에 쓸지 의식적으로 결정한다.

이 시나리오의 적용 범위에 대해서도 별도로 기억할 필요가 있다. AI의 효과는 문서 성숙도, 내부 소스 접근성, 제품의 도메인 복잡성, 그리고 팀이 암묵적 지식을 반복 가능한 컨텍스트로 전환하는 능력에 따라 크게 달라진다. 원본 데이터가 빈약한 곳에서는 AI가 패키징을 가속화할 수는 있지만, 반드시 의사결정의 품질을 개선한다고 보기는 어렵다.

결론

아주 짧게 말하자면, refinement에 대한 AI의 주요 효과는 이렇게 정리할 수 있다. AI는 팀의 합의 자체를 가속하는 것이 아니라, 합의를 위한 자료 준비를 가속한다. 그래서 refinement의 입력 단계가 빨라진다. 컨텍스트가 더 빨리 모이고, 초안이 더 빨리 나오고, 기본적인 질문과 리스크가 더 빨리 드러나고, 결과물이 더 빨리 정리된다.

하지만 이것이 refinement를 자동으로 더 쉽게 만들지는 않는다. 준비 비용이 낮아지는 순간, AI가 아직 제대로 잘하지 못하는 것들의 가치가 커지기 때문이다. 도메인을 이해하고, 실제 제약을 감지하고, 거짓 명료함을 알아채고, 데이터를 신중하게 다루고, 팀이 의식적인 타협을 하도록 돕는 일 말이다.

따라서 refinement에서 AI를 바라보는 가장 좋은 방식은 이렇다. AI는 실무 주변의 값비싼 수작업 일부를 없애지만, 의미에 대한 인간의 검증을 더욱 중요하게 만든다. backlog item을 생산하기가 더 쉬워질수록, 어떤 항목이 실제로 논의할 준비가 되었는지, 어떤 항목이 단지 좋아 보일 뿐인지 이해하는 것이 더 중요해졌다. 그리고 시리즈의 다음 글들에서는 이 변화가 프로세스뿐 아니라 팀 시간 활용 문화에 어떤 영향을 미치는지 살펴보는 것이 흥미로울 것이다.

출처 및 참고 자료

← 모든 에세이