16건이 모두 마감일 미정이었습니다 — 정체성이 흐려진 도메인 노드를 살리는 5축 보강하기
"시간 박스 16건이 모두 마감일 미정이었습니다"
운영 중인 PM 도구의 데이터를 정리하다가 이상한 패턴을 발견했습니다.
"시간 박스"라는 도메인 노드(Epic 성격의 노드)가 16건 있었는데, 활성 16건이 모두 마감일 미정 상태였어요. 처음 설계할 때 "시간 박스"는 이름 그대로 시간의 경계 안에서 끝나는 작업 묶음이었습니다. 마감일이 핵심 정체성이었어요.
그런데 운영하면서 마감일을 비워두는 흐름이 누적됐고, 결국 16건 전부가 시간 경계 없는 상태가 됐습니다. 시간 박스라는 이름은 남아 있는데, 시간 박스의 정체성은 사라진 거예요.
처음에는 단순한 데이터 정리 문제로 봤습니다. "마감일 채우면 되겠지" 하고 폼을 손보려고 했어요.
그런데 작업을 시작하니 문제가 다층이라는 게 드러났습니다. 정체성이 흐려진 도메인 노드는 한 곳만 고친다고 살아나지 않습니다. 화면 표시·생성 흐름·관계 모델·AI 추천·정책 문서 다섯 축을 동시에 보강해야 했어요.
같은 날 6단계 작업이 145분에 걸쳐 진행됐습니다. 이번 글은 그 과정과 발견한 패턴을 정리한 회고입니다.
16건이 흐려진 정체성의 신호였습니다
"활성 16건 전부가 마감일 미정"은 단순한 데이터 누락이 아니었어요.
사용자가 마감일을 비워두는 흐름이 16번 반복됐다는 건, 시스템이 마감일의 중요성을 사용자에게 전달하지 못하고 있다는 신호였습니다. 단순 폼 가드 하나로 안 풀리는 문제예요.
진단해보니 네 가지 결함이 동시에 작용하고 있었습니다.
화면: 카드에 "진행률 바"만 표시되어 마감일이 중요하다는 신호가 없음
생성 흐름: 마감일이 선택 필드라 비워둬도 통과
관계 모델: "닫힐 준비된 시간 박스"를 자동 인식하는 메커니즘 없음
AI 추천: 시간 박스 종료 후 후속 액션 안내 없음
한 가지만 고쳐서는 효과가 안 나옵니다. 폼만 막아도 사용자는 가짜 마감일을 넣고 빠져나가요. 화면만 바꿔도 생성 흐름이 그대로면 데이터가 또 누적됩니다.
정체성 재정의는 다층 보강이 필요한 작업이었어요.
6단계 도미노 작업
같은 날 6단계가 시간 순으로 진행됐습니다. 핵심만 요약하면 이렇습니다.
1단계: 카드 본질 교체 (대시보드)
대시보드의 시간 박스 카드를 "진행률" 표시에서 "시점 시그널" 표시로 바꿨습니다. 시점 시그널은 세 가지 분류로 나뉘었어요.
마감 넘김
이번 달 마감
장기 정체
카드를 보면 "이건 시간 박스다, 시간이 중요하다"는 신호가 즉시 전달됩니다. 진행률 바는 시각 노이즈만 만들고 있었어요.
2단계: 생성 폼에서 마감일 필수화 + 정체성 안내
새 시간 박스를 만들 때 마감일을 필수 입력으로 바꾸고, 폼 상단에 짧은 안내를 추가했습니다.
"시간 박스 — 마감일이 떠오르지 않으면 영구 능력 노드나 다른 분류로 만드세요"
이 안내가 중요했어요. 사용자가 무심코 비워두는 게 아니라 의식적으로 선택하게 만드는 장치입니다. 마감일이 없으면 다른 노드 타입으로 가라는 명시적 가이드.
3단계: 시각 노이즈 제거
멤버 row의 정보 가치 0인 도형들을 제거하고, 공통 칩 컴포넌트로 UI를 통일했어요. 화면이 정체성을 명확히 드러내려면 노이즈가 적어야 합니다. 정보 전달에 기여하지 않는 시각 요소는 정체성을 흐립니다.
4단계: "닫힐 준비" 시그널 신규
모든 멤버가 resolved 상태인 시간 박스를 자동으로 별도 카테고리로 분류했습니다. "닫힐 준비된 시간 박스"가 한눈에 보이게 됐어요.
여기서 한 가지 함정이 있었습니다. 자동 status 로직만 믿으면 일부 멤버 타입(QnA, Action 같은)을 빠뜨릴 위험이 있어요. derived 상태 계산식을 전체 멤버 타입을 다 포함하도록 점검해야 했습니다.
5단계: AI 추천 + 한 클릭 액션 동선
"닫힐 준비된 시간 박스"에 AI 추천을 붙였어요. 후속 plan 추천, 신규 제안, 회고 자료 세 갈래로 한 추천에 다 담았습니다.
여기서 중요한 결정 하나가 있었어요. read-only 추천은 가치가 절반밖에 안 됩니다. 추천을 보여만 주면 사용자가 "그래서 어떻게?" 다시 추론하게 됩니다. 그래서 [+ 등록] / [연결] 버튼으로 한 클릭에 액션이 가능하게 만들었어요.
6단계: 의미 확장 + 정책 갱신
마지막으로 "시간 박스"의 의미를 한 단계 확장했습니다. 단순 시간 경계가 아니라 "시간 박스 + 도메인 묶음"으로. 그리고 이 묶음을 활용하는 4시점 운영 모델(회고·계획·보고·학습)을 정책 문서로 만들었어요.
여기서 다른 도메인 노드(영구 능력 노드 등)와의 충돌을 검증했습니다. "이 의미 확장이 다른 노드의 영역을 침범하지 않는가"를 확인하는 절차였어요.
정체성 재정의는 5축 동시 보강이 필요합니다
6단계를 정리하고 보니 한 가지 패턴이 보였어요. 다섯 축을 동시에 보강해야 정체성이 살아납니다.
축 1: 화면 표시
카드·대시보드·목록에서 노드의 정체성을 즉시 전달해야 합니다. 진행률 바 같은 일반 시각 요소가 아니라, 이 노드 타입의 핵심 가치를 표현하는 시각 요소가 필요해요. 시간 박스라면 시점 시그널.
축 2: 생성 흐름
새로 만드는 시점에서 정체성을 강제해야 합니다. 핵심 필드를 필수화하고, 폼 상단에 정체성 안내를 두는 거예요. 만든 후에 정정하려면 비용이 큽니다.
축 3: 관계 모델
자동 status, derived 상태, 분류 로직이 노드 정체성을 반영해야 합니다. "닫힐 준비된 시간 박스" 같은 의미 있는 상태를 자동으로 인식하는 메커니즘이 필요해요.
축 4: AI 추천 / 시스템 안내
정체성에 맞는 다음 액션을 시스템이 먼저 제안해야 합니다. 사용자가 "이걸로 뭐 하지?" 추론하게 두지 않습니다.
축 5: 정책 문서
코드 변경만으로 끝나면 미래에 또 흐려집니다. 정책 문서에 정체성을 명시하고, 다른 도메인 노드와의 경계까지 적어둬야 합니다.
한 축만 고쳤다면 어떻게 됐을까
각 축을 단독으로 고쳤을 때의 결과를 상상해보면 명확합니다.
화면만 바꾸면: 생성 흐름이 그대로니 데이터는 또 누적
생성 폼만 막으면: 사용자가 가짜 마감일 넣고 빠져나감
관계 모델만 바꾸면: 화면에 안 보이니 효과 없음
AI 추천만 추가하면: read-only면 가치 절반
정책 문서만 갱신하면: 코드와 안 맞아서 결국 무시됨
한 축만 보강해서는 정체성이 살아나지 않습니다. 다섯 축이 같은 메시지를 보내야 사용자가 "이 노드는 이런 거구나" 인식하게 됩니다.
옛 16건은 그대로 두기로 했습니다. 다 정리하려면 데이터 마이그레이션 부담이 컸고, 앞으로 새로 만드는 것부터 정체성을 강제하는 게 효율적이었어요. 옛 데이터는 자연 감소 또는 사용자가 직접 정리하도록.
의사결정자가 점검할 4가지
도메인 모델 정비·제품 정체성 재정의·시스템 리팩토링을 검토하실 때 점검할 일반 체크리스트입니다.
1. 데이터 패턴이 정체성 흐려짐의 신호인지 확인합니다
특정 필드가 대량으로 비어 있거나, 특정 상태로만 누적된다면 단순 데이터 정리 문제가 아닐 가능성이 큽니다. 시스템이 정체성을 사용자에게 전달하지 못하고 있다는 신호일 수 있어요.
2. 정체성 재정의가 필요하면 5축을 동시에 봅니다
화면 표시, 생성 흐름, 관계 모델, AI 추천, 정책 문서. 한 축만 고치면 다른 축에서 다시 흐려집니다. 5축 동시 보강이 정체성 재정의의 기본 단위예요.
3. 자동 status·derived 로직 빠진 멤버 타입 없는지 점검합니다
자동 분류 로직만 믿으면 일부 멤버 타입을 빠뜨릴 위험이 있습니다. 새로 추가된 멤버 타입이 derived 상태 계산식에 포함되는지 정기적으로 점검합니다.
4. AI 추천에 한 클릭 액션 동선을 같이 깝니다
read-only 추천은 가치가 절반입니다. 사용자가 추천을 보고 "그래서 어떻게?" 추론하게 두지 않습니다. [등록] / [연결] 같은 한 클릭 액션 버튼이 추천을 완성합니다.
비슷한 발상이 다른 도메인 모델 결정에서도 흐릅니다. 한 곳만 고치지 않는 것, 시스템 전체가 같은 메시지를 보내게 만드는 것, 새로 만들어지는 것부터 정체성을 강제하는 것. 도메인 모델링의 핵심 기준입니다.
마무리
PM 도구의 시간 박스 노드 16건이 모두 마감일 미정 상태였습니다. 단순 데이터 누락이 아니라 정체성이 흐려진 신호였어요. 같은 날 6단계가 145분에 걸쳐 진행됐고, 5축 동시 보강이 필요하다는 패턴을 발견했습니다.
핵심 교훈은 세 가지입니다.
대량의 동일 누락 패턴은 정체성 흐려짐의 신호다 — 단순 데이터 정리로 끝나지 않음
정체성 재정의는 5축 동시 보강이 필요하다 — 화면·생성·관계·AI 추천·정책
새로 만드는 것부터 정체성을 강제한다 — 옛 데이터 마이그레이션보다 새 흐름의 가드가 효율적
도메인 모델·제품 정체성·시스템 리팩토링을 검토하신다면, 이번 글의 4가지 체크리스트(정체성 신호 진단 / 5축 동시 보강 / 자동 로직 점검 / 한 클릭 액션 동선)를 한 번 살펴보시길 추천합니다. 한 곳만 고치는 작업이 자주 반복된다면, 5축을 한꺼번에 보는 시야가 도미노를 막아줍니다.