DoD 실험: 위장된 진단 도구

Source: Dev.to

이것은 Definition of Done 실험을 문서화한 시리즈의 2부입니다. Part 1: Trying to Fix “Done” Before It Breaks Us

두 스프린트가 지나도 가설은 대부분 검증되지 않음

실험은 충분히 실행되지 않았습니다:

• DoD와의 한 차례 정제 세션,
• 그에 의해 의미 있게 형성된 하나의 티켓, 그리고
• 전달 시간에 대한 결론을 내리기엔 너무 많은 환경적 잡음.

예상치 못한 결과가 나타났습니다. DoD는 주로 추정 방식을 바꾸지는 않았고, 대신 핸드북을 만들도록 강제했습니다. 그 핸드북은 이제 팀이 코드에 대해 이야기하는 방식을 재구성하고, DoD 자체가 해결할 수 없는 문제들을 드러내고 있습니다.

여섯 항목이 열네 페이지가 되다

• DoD 자체는 최소 수준이다: “항상 포함” 아래 여섯 항목, 몇 개의 조건부 항목, 그리고 명시적인 “절대 가정하지 않음.” → 한 페이지.
• 그러나 시행에는 공유된 정의가 필요하다.
  • “Errors are handled”(오류가 처리됨)는 DomainError 패턴을 설명하고 오류가 상태 레이어를 통해 어떻게 전파되는지에 대한 페이지를 가리킨다.
  • “Styling uses prefixes”(스타일링에 접두사를 사용)에는 구체적인 예시가 필요하다.
  • “Code follows existing patterns”(코드가 기존 패턴을 따름)는 그 패턴이 사람들의 머리 밖 어딘가에 존재하지 않으면 의미가 없다.

DoD는 따라서 목차가 되었고; 핸드북은 그것이 강제로 구현하는 시스템이다.

이것은 예상된 바였다—문서화된 지식 아키텍처는 항상 전제 조건이었다.
예상하지 못한 것은 양이며, 그 지식이 이전에 얼마나 암묵적이었는가이다. 이를 기록하는 것이 복잡성을 발명한 것이 아니라, 시스템이 운영되고 숨겨왔던 암묵적 지식의 양을 드러낸 것이다.

오늘날 열네 페이지—린터가 기술 부채가 아니라, prose(문장) 없이도 강제해야 할 것을 시행하기 시작하면 더 적어질 것이다.

문서 살아있게 유지하기

Fourteen pages is a liability if it remains one person’s opinions dressed as consensus.
→ 14페이지는 한 사람의 의견을 합의처럼 꾸민 상태로 남아 있다면 부채가 됩니다.

Mitigation (structural):

• The handbook lives in the monorepo, written in Markdown and Mermaid, editable in the same PR as the feature that depends on it.
  → 핸드북은 모노레포에 존재하며, Markdown과 Mermaid로 작성되고, 해당 기능과 동일한 PR에서 편집할 수 있습니다.
• “Update handbook” is a DoD item itself.
  → “핸드북 업데이트” 자체가 DoD 항목입니다.

Logic:

1. When you introduce a pattern, document it in the same commit.
   → 패턴을 도입할 때, 같은 커밋에 문서화합니다.
2. When you notice something missing, fix it where you are.
   → 무언가 누락된 것을 발견하면, 현재 위치에서 바로 수정합니다.

The handbook isn’t a parallel artifact owned by someone—it’s part of the codebase, subject to the same review process.
→ 핸드북은 누군가가 별도로 소유하는 병행 아티팩트가 아니라, 코드베이스의 일부이며 동일한 리뷰 프로세스의 대상입니다.

So far, this structure is holding. Multiple developers have edited the handbook unprompted, in the same PRs as feature work. That validates that ownership is starting to distribute.
→ 지금까지 이 구조는 유지되고 있습니다. 여러 개발자가 자발적으로 기능 작업과 같은 PR에서 핸드북을 수정했습니다. 이는 소유권이 분산되기 시작했음을 검증합니다.

What hasn’t happened yet is pushback—someone proposing to change an existing pattern rather than just adding to it. A handbook nobody challenges may indicate passive compliance rather than genuine shared ownership. That distinction matters, and it’s something I’m now watching for explicitly.
→ 아직 일어나지 않은 것은 반발입니다—기존 패턴을 단순히 추가하는 것이 아니라 변경을 제안하는 사람입니다. 아무도 도전하지 않는 핸드북은 진정한 공동 소유보다는 수동적 순응을 나타낼 수 있습니다. 이 구분은 중요하며, 저는 이제 이를 명시적으로 주시하고 있습니다.

Source: …

문서화가 피드백을 비인격화한다

핸드북이 나오기 전에는 코드 리뷰 피드백이 개인적인 느낌이었다:

“이 변수 이름을 다르게 짓는 게 좋겠어요.”
“이 오류 처리 로직이 완전하지 않아요.”

각각의 코멘트는 암묵적으로 권위를 주장한다.

이제는 페이지가 있다. 명명 규칙은 문서에 적혀 있고, 오류 처리에는 흐름도가 있다. 코멘트가 이렇게 말한다면:

“명명 규칙에 따라 hci‑ 접두사를 사용해야 합니다” (문서 링크)

대화가 바뀐다. 리뷰어가 취향을 주장하는 것이 아니라, 합의된 규칙을 인용하고 있는 것이다. 수정은 사람이 아니라 시스템으로부터 온다.

이 두 스프린트 동안 전체 PR의 약 3분의 1이 명시적으로 핸드북 항목을 참조했다—의견이 담긴 코멘트 대신 링크가 사용된 것이다. 개발자들은 빈틈을 발견하면 추가를 제안했다. 핸드북은 공유 언어를 만들었을 뿐 아니라, 사람과 피드백 사이에 거리를 두는 역할도 했다.

하나의 티켓, 실제 수치

Ticket: 오류 코드 문서화 및 통합 (기술 부채 티켓)

개발자는 작업을 시작했지만 혼란스러운 상황을 발견했습니다—오류 코드가 일관된 패턴 없이 여기저기 흩어져 있었습니다. 본능적으로 그 안에 있는 동안 시스템을 고치자는 생각이 들었습니다. 그는 코드베이스 전반에 걸쳐 오류 코드가 작동하는 방식을 리팩토링하기 시작했는데, 결국 필요하지만 범위에 포함되지 않음입니다.

• “인접 코드 리팩토링”은 DoD에서 명시적으로 “절대 가정하지 않음” 아래에 있습니다.
• 티켓은 이를 염두에 두고 정제되었습니다.

리팩토링은 추정에 포함되지 않았습니다. 왜냐하면 계약에 포함되지 않았기 때문입니다. 개입은 리팩토링 중간에 발생했으며, 사전에 일어나지 않았습니다. 대응은 간단했습니다: DoD가 방금 적용되었으므로 이번 경우는 통과하지만—그 줄을 보세요. 추정에는 이 작업이 포함되지 않았습니다; 이 작업이 없었다면 티켓은 제시간에 완료되었을 것입니다.

반대 의견은 없었습니다. 스프린트 리뷰에서 개발자는 직접 이 대화를 제기했으며, 이는 앞으로 DoD가 어떻게 도움이 될 수 있는지에 대한 예시였습니다. DoD는 리팩토링을 멈추게 하지 않았고, “예상보다 오래 걸렸다”는 숨겨진 투자를 드러나게 했습니다. 그 가시성이 바로 레버리지입니다.

제품이 본 것

Product은 DoD에 저항하지 않았고—채택했다. 정제는 체계적이 되었다:

1. 티켓을 가져온다.
2. DoD를 통과한다.
   • “항상 포함” — 얼마나 오래?
   • “절대 가정하지 않음” — 필요할까?
   • 비용은?

그들의 반응은 단순한 준수가 아니었다. 그들은 DoD 항목을 티켓 템플릿에 직접 삽입하는 것을 제안했다.

실제 테스트는 아직 오지 않았다: DoD‑완료 추정치가 예상보다 크게 높은 티켓이 나타날 때. 그때 시스템은 다음 중 하나를 선택한다:

• 명시적인 트레이드‑오프를 만든다—작업을 포함하거나 문서화된 부채로 연기한다, 또는
• “그냥 배포한다”는 압박에 굴복한다.

그 순간이 이것이 프로세스인지 연극인지를 드러낼 것이다.

Adoption at capacity

직접적인 대화에서는 동기가 갈라집니다:

• 옹호자는 시스템이 작동하는 것을 보고 이를 옹호합니다.
• 회의론자는 더 조심스럽습니다—프로세스 프레임워크는 왔다가 사라졌고, 이번 것은 보장된 성과 없이 더 많은 오버헤드처럼 보이기 때문입니다.

회의론자에게 다가간 프레이밍은 열망적인 것이 아니라 방어적인 것이었습니다:

이것은 우리를 위한 것이지, 다른 누구를 위한 것이 아니다.
우리가 만들기로 합의한 것을 명확히 한다.
기술 부채를 명시적으로 추적한다.
그리고 격차가 문제로 떠오르면, 우리는 이를 조기에 파악할 수 있다.

End of part 2.

DoD가 드러낸 것

DoD는 티켓의 “완료”가 무엇을 의미하는지 명확히 하려는 목적이었습니다. 하지만 결국 범위를 명확히 하는 결과가 나왔습니다.

핸드북에는 오류 처리, WebComponent 패턴, 상태 관리, 스타일링 규칙, SSR 고려 사항, 인증 흐름 등—총 14페이지에 걸친 기술적 결정들이 일관된 경계 안에 문서화되어 있습니다.

• 핸드북 패턴에 대해 스탠드‑업에서 논의가 필요할 때, 전체 인원의 80 %가 맥락을 전혀 모릅니다.
• 스프린트 리뷰에서 DoD 준수를 평가할 때, 대부분의 참석자는 이를 판단할 수 없습니다.

DoD가 요구하는 협업은 현재의 의식(ritual)과 맞지 않습니다—의식이 잘못된 것이 아니라, 그 의식이 더 넓은 그룹을 대상으로 하기 때문입니다.

핸드북을 다시 읽어보니, 한 가지 질문이 떠올랐습니다: 이것은 실제로 누구의 작업을 설명하고 있는가?

답은 “풀스택 팀의 프론트엔드 파트”가 아니라, “API를 소비하는 제품 팀”에 가깝습니다. 우리 모노레포는 자체 백엔드 관심사—인증, 세션, SSR—를 가지고 있습니다. 백엔드 팀과의 접점은 계약 수준에 불과합니다: API 형태, 응답 포맷, 오류 코드 등. 일상적인 협업은 최소합니다.

이는 비판이 아닙니다. 팀은 진화하고, 구조는 변합니다. 하지만 DoD는 우리가 실제로 무엇을 구축하고 있는지를 명확히 하도록 강요했고, 그 결과는 자체적인 협업 리듬이 필요할 수도 있는 경계를 제시합니다.

그 모습이 어떻게 될지는 아직 모릅니다. 다음 단계는 구체적입니다:

1. 실제 협업 흐름을 매핑한다.
2. 전용 프론트엔드 의식 옵션을 평가한다.
3. 불일치가 마찰인지 단절인지 테스트한다.

이것이 Part 3입니다.

현재 상황

추정 가설은 아직 검증되지 않았습니다. 이를 올바르게 테스트하려면 보호된 세분화, 추정치와 실제값을 추적, 그리고 더 많은 샘플이 필요합니다.

현재 존재하는 것:

• 다수의 개발자가 편집한 모노레포 내 14페이지 분량의 핸드북.
• 제품팀이 티켓 템플릿에 삽입하기를 원하는 DoD.
• 피드백을 비인격화하는 공유 언어.
• 이제 무시할 수 없는 구조적 불일치.

DoD는 추정을 개선하기 위해 고안되었습니다. 그러나 대신 추정이 보완해오던 문제를 드러냈습니다.

궁극적으로 전달을 개선할 수 있을지는 아직 미정입니다. 팀에게는 질문이 **“왜 이렇게 오래 걸렸나요?”**에서 **“우리가 실제로 무엇을 만들기로 합의했나요?”**로 바뀌었으며, 이는 전혀 다른 출발점입니다.

여기에 서술된 견해와 실험은 저 개인의 것이며, 고용주를 대변하지 않습니다.