기획 대신 해주는 개발자는 그만: 백로그 정제(Refinement) R&R과 DoR(Definition of Ready) 구축 가이드

작성자: 테크 리더십 & 조직 효율성 인사이트
태그: #백로그정제 #BacklogRefinement #DoR #DefinitionOfReady #PM리더십 #테크리더십 #Agile #개발문화

📌 들어가는 글: "에러 메시지는 개발자님이 적당히 써주세요"의 비극

"개발자님, 외부 서버 장애 나면 사용자한테 무슨 에러 메시지 보여줘야 해요?"
"아, 그거 그냥 개발자님이 적당히 자연스럽게 하나 써서 넣어주세요."

IT 조직에서 너무나 흔하게 펼쳐지는 풍경입니다. 백로그 정제(Refinement)나 기획 검토 미팅이 제대로 작동하지 않는 조직에서는, 기획자가 해야 할 비즈니스 정책 수립과 스펙 명확화 작업이 통째로 생략된 채 개발자에게 넘어옵니다.

그 결과, 개발자는 코딩을 하기도 전에 다음과 같은 질문들에 답하며 '비즈니스 소설'을 써야 합니다:

• "예외 발생 시 결제 취소를 해줘야 하나, 아니면 적립금으로 환불해줘야 하나?"
• "사용자가 필수 항목을 안 적었을 때 안내 팝업 문구는 뭐라고 해야 하지?"
• "외부 연동 대행사 담당자 연락처나 API 문서는 어디서 찾아야 하지?"

개발자가 기술적 예외(Technical Edge Case)를 도출하는 것은 당연한 개발 프로세스입니다. 하지만 비즈니스 예외 정책과 유저 경험(UX) 판단까지 개발자가 대신 고민하고 있다면, 그것은 개발을 하는 것이 아니라 기획을 대신해주고 있는 상태입니다.

이번 글에서는 백로그 정제(Refinement)의 명확한 역할 분담(R&R)과 함께, 무분별하게 들어오는 일감으로부터 개발팀을 보호하는 방화벽: DoR(Definition of Ready) 구축 전략을 다룹니다.

👥 1. 백로그 정제(Refinement)의 역할별 명확한 R&R

결론부터 말해, 백로그 정제는 PO/PM과 테크 리드(TL), 개발팀이 함께하는 공동 작업입니다. 하지만 무작정 모여서 회의하는 것이 아니라, '무엇(What)'을 정의해오느냐와 '어떻게(How)' 쪼개느냐로 역할이 엄격히 나뉘어야 합니다.

📊 역할별 책임 구획 (R&R Matrix)

⚡ 2. 왜 지금 개발팀은 정제 미팅에서 고통받는가?

체계가 없는 조직에서 발생하는 가장 큰 비극은 PM의 '기획 정제' 과정이 전면 생략된 채 '단어 한두 개'로 일감이 던져지는 구조 때문입니다.

[ 기존의 잘못된 구조 (기획 독박 구조) ]
  PM: "소셜 로그인 추가해 주세요" (단어 제시)
    └─► 개발자/TL: API 문서 탐색 + 예외 정책 수립 + 유저 문구 작성 + DB 설계 + 코딩 + QA 기준 작성 (독박)

[ 바람직한 구조 (R&R 분리 구조) ]
  PM: 비즈니스 목적 + AC 작성 + API 문서 확보 (What & Why 정제)
    └─► TL: 아키텍처 영향도 분석 & Task 분해 가이드 (Feasibility)
          └─► 개발자: 기술 예외 발굴 + DoD 적용 + 세부 코딩 & 테스트 (How)

개발자가 코드를 작성하는 시간보다 "이럴 땐 어떻게 처리해야 하지?"를 고민하며 PM을 찾아다니거나 스스로 정책을 지어내는 시간이 더 길어진다면, 그 팀의 생산성은 바닥을 칠 수밖에 없습니다.

🛡️ 3. 현장 적용을 위한 방화벽: DoR (준비 완료의 정의)

개발팀이 정제 미팅(Refinement Session)에서 무의미하게 소모되는 것을 막으려면, "이 기준을 맞추지 않은 일감은 정제 미팅 안건으로 받아들이지 않는다"는 DoR(Definition of Ready)이라는 방화벽을 세워야 합니다.

📋 개발팀이 PM에게 요구해야 할 DoR 체크리스트

다음 4가지 질문에 모두 YES라고 답할 수 없는 티켓은 정제 미팅에 올릴 수 없도록 규정합니다.

[ 우리 팀의 DoR (Definition of Ready) 체크리스트 ]

[ ] 1. 비즈니스 목적과 주요 유저 시나리오가 명확히 작성되어 있는가?
       • 이 기능을 왜 만드는지, 사용자가 어떤 플로우로 이용하는지 명시

[ ] 2. 정상 케이스에 대한 인수 조건(Acceptance Criteria, AC)이 최소 3개 이상 작성되어 있는가?
       • "무엇이 확인되어야 이 작업이 성공했는가?"에 대한 기준

[ ] 3. 외부 연동이 필요한 경우, 연동 API 문서 링크 및 테스트 계정이 확보되어 있는가?
       • 개발자가 대행사에 직접 연락해 문서를 구하러 다니지 않도록 미리 준비

[ ] 4. 화면 개발인 경우, 디자인 시안(Figma 등) 및 와이어프레임이 확정되어 있는가?
       • 디자인 미정으로 인한 개발 중단 리스크 방지

🔄 4. 선순환을 만드는 4단계 백로그 정제 프로세스

DoR 체계를 바탕으로 실무에서 즉시 적용할 수 있는 가벼운 4단계 정제 워크플로우입니다.

  Step 1. DoR 충족        Step 2. 사전 검토        Step 3. 정제 미팅        Step 4. 공수 입력
┌──────────────────┐    ┌──────────────────┐    ┌──────────────────┐    ┌──────────────────┐
│ PM이 DoR을 맞춘  │ ─► │ TL/개발팀의      │ ─► │ 예외 케이스 도출 │ ─► │ 3~5일 단위 Task  │
│ 티켓을 백로그 생성│    │ 30분 사전 검토   │    │ & DoD/AC 최종확인│    │ 분해 및 공수 산정│
└──────────────────┘    └──────────────────┘    └──────────────────┘    └──────────────────┘

1. DoR 충족 백로그 작성: PM이 위 DoR 체크리스트를 충족하는 티켓을 스프린트 시작 최소 2~3일 전에 작성합니다.
2. 사전 검토 (Pre-review): 테크 리드와 담당 개발자가 미팅 전 API 문서나 기획서를 20~30분 정도 미리 훑어보며 기술적 의문점을 메모합니다.
3. 정제 미팅 (Refinement Session): 다 같이 모여 기획 설명을 듣고, 기술적 예외 케이스(Edge Case)를 도출하며, 팀의 DoD(Definition of Done)를 확인합니다.
4. Task 분해 및 공수 입력: 요구사항을 3~5일(Man-Day) 이하의 세부 Task로 분해하고, 스토리 포인트나 공수를 산정합니다.

🎯 맺음말: R&R의 구분이 만드는 건강한 조직 문화

백로그 정제에 R&R과 DoR 기준을 도입하는 것은 PM과 개발자 사이에 담을 쌓자는 뜻이 아닙니다. 오히려 각자의 전문성을 극대화하여 서로를 존중하는 협업 문화를 만드는 과정입니다.

• PO/PM은 "단어 던지기"에서 벗어나 스펙을 명확히 정의하는 기획의 책임감을 갖게 됩니다.
• 테크 리드/개발자는 기획 정책을 지어내느라 낭비되던 시간을 줄이고, 완성도 높은 아키텍처 설계와 코드 작성, 테스트에 집중할 수 있는 시간을 확보하게 됩니다.

오늘 우리 팀의 백로그를 열어보세요. 그리고 PM에게 정중하게 DoR 체크리스트를 제시해 보세요. 감에 의존하는 개발 문화에서 벗어나, 데이터와 정제된 스펙으로 소통하는 건강한 테크 조직으로 전환되는 첫걸음이 될 것입니다.

본 가이드가 도움이 되셨다면 조직 내 PM, Tech Lead, 그리고 엔지니어링 리더 분들과 공유해 보세요!