플랜비에서 경기 참가와 권한, 스탯을 분리한 이유

농구 동호회 운영에서는 “오늘 경기에 나왔는가”와 “운영 정보를 바꿀 수 있는가”, “어떤 기록을 남겼는가”가 쉽게 한 덩어리로 취급돼요. 플랜비(plan-b)를 설계하며 이 3가지를 나누는 편이 자동화에도 더 알맞다고 봤어요.

직접 모델을 종이에 그려 보니, 참가 여부는 경기마다 달라지는 사실이고 운영 권한은 멤버의 역할에 가까웠어요. 개인 스탯은 경기 결과를 바탕으로 쌓이는 기록이었고요. 한 필드에 섞으면 AI가 요약할 때도 “참가하지 않은 사람”과 “기록이 없는 사람”을 구별하기 어려워집니다.

멤버 역할→경기 참가 기록→개인 스탯 집계

이 구조에서는 멤버, 경기 참가, 스탯이라는 3개 묶음이 각자 한 가지 질문에 답해요. 운영 권한은 “누가 변경할 수 있나”, 참가 기록은 “누가 이 경기에 나왔나”, 스탯은 “이 경기에서 무엇을 기록했나”예요. 역할 2개가 같은 경기에 참가할 수 있고, 참가자 1명에게 여러 스탯 항목이 연결될 수 있다는 점도 자연스럽게 표현됩니다.

적용해 봤더니 자동화 프롬프트도 짧아졌어요. 경기 운영 요약을 만들 때는 참가 기록과 운영 역할만 읽고, 개인 기록 요약이 필요할 때만 스탯을 더하면 돼요. 데이터가 목적별로 나뉘어 있으니 워크플로우가 불필요한 정보를 함께 전달하지 않게 됩니다.

테스트해 보면 확인할 질문은 4가지면 충분해요. 권한이 없는 멤버가 운영 변경 대상으로 잡히지 않는지, 불참자가 출전 명단에 들어가지 않는지, 참가 기록 없이 스탯이 만들어지지 않는지, 경기별 기록이 다른 경기로 섞이지 않는지예요. 3개 묶음과 2개 역할 상태를 조합해 보면 경계 사례도 빠르게 찾을 수 있어요.

• ✓권한은 역할
• ✓참가는 경기 사실
• ✓스탯은 경기 결과

돌려 보니 AI에게 “오늘의 참가자와 운영 담당만 요약해 달라”고 요청하는 흐름과 “개인 스탯을 집계해 달라”고 요청하는 흐름을 분리하기 쉬웠어요. 플랜비는 멤버, 회비, 출전 로테이션, 전술보드를 다루는 운영 매니저이므로, 이런 작은 데이터 경계가 이후 자동화의 설명 가능성에도 영향을 줍니다.

직접 만들어 보니 좋은 모델링은 항목을 많이 만드는 일이 아니라, 한 데이터가 답해야 할 질문을 하나로 좁히는 일에 가까웠어요.