팀 확장과 피드 기능으로 그룹 페이지 완성하다

그룹 시스템이 16팀 규모까지 커지면서, 단순한 목록 페이지론 역부족이 됐다. 한 스프린트에 팀 확장, 일정 타임라인, 소식/링크 피드, 정책페이지를 모두 구축하고 배포했는데, 이 경험에서 배운 점들을 정리해본다.

팀 확장의 배경: 왜 16개일까?

처음엔 그룹 시스템이 4-5개 팀 수준의 소규모 조직만 상정하고 만들어졌다. 데이터 구조도, UI도, 초기화 로직도 다 그 규모에 맞춰져 있었다. 그런데 조직이 성장하면서 팀이 늘어났고, 더 이상 미룰 수 없게 됐다.

여기서 중요한 건 단순히 숫자를 16으로 변경하는 것만 아니었다는 점. 팀 수 확장은 네 가지 신규 기능들의 토대였다.

• 일정 타임라인: 팀이 많아질수록 누가 언제 뭘 하는지 가시성이 떨어진다 → 통합 캘린더/타임라인 필수
• 소식 피드: 각 팀의 소식을 흩어지게 하지 말고 한 곳에서 보고싶다는 요청
• 공식링크 피드: 팀별 중요 자료/문서를 중앙화하면 더 빨리 찾을 수 있다
• 정책페이지: 팀이 많아질수록 일관된 규칙/가이드가 필요

결국 팀 확장이 정보 구조 개편의 신호였던 것.

네 가지 기능을 한 스프린트에 짜넣다

변경된 파일들을 보면 이 작업의 규모가 느껴진다:

이런 식으로 bot 쪽 데이터 준비 스크립트들(enrich_, backfill_, seed_*)이 한꺼번에 들어갔다는 건 초기화/마이그레이션 스크립트의 중요성을 보여주는 케이스다. 기능만 만들고 데이터는 나중에 하려고 하면 절대 끝나지 않는다.

기술 선택: 왜 이렇게 설계했나

1. Enrich vs Seed의 구분

• enrich_new_groups.py: 앞으로 새 팀이 추가될 때마다 자동으로 돌 로직. 팀당 기본 설정(대표 이미지, 설명, 카테고리)을 한 번에 채운다
• seed_*.py: 특정 시점에 수동으로 도는 데이터 초기화 스크립트. 소식, 링크, 일정 같은 콘텐츠를 대량 입력할 때 유용

이 구분이 없었으면 매번 팀이 추가될 때마다 수동으로 여러 곳을 터치했을 것. 하나의 팀당 5-6개의 필드를 채우려면, 16팀이 오면 80번의 클릭과 타이핑이 필요하다.

2. Backfill로 시간을 사고 팔다

backfill_schedule.py는 일종의 기술 부채 결제 같은 작업이다. 원래 팀들이 이미 일정을 여럿 갖고 있었는데, 타임라인 UI가 없었으니까 그 데이터를 활용할 수 없었다. Backfill을 돌려서 이전 일정들을 시스템에 등록하면:

• 사용자는 "어? 우리 팀의 지난 3개월 일정이 벌써 보여?"라는 경험을 얻는다
• 데이터 신뢰도가 올라간다
• 팀장들이 수동으로 다시 입력해야 하는 수고를 줄인다

한 번에 여러 개를 칠 때의 트레이드오프

이 작업을 하면서 느낀 고민들이 있었다.

"기능별 PR로 쪼갤 걸" vs "한 묶음으로 갈 걸"

한 묶음으로 간 이유:
- 팀 확장이 일정/소식/링크 없이는 의미 없다
- 순서대로 하면 배포까지 3주가 필요했을 것
- 팀원들이 "아직도 그룹 시스템 개편 중이네?" 하는 답답함을 줄이고 싶었다

주의할 점이었던 것:
- PR 리뷰가 한 번에 크다 → 체크리스트를 미리 준비했다 (bot 스크립트 검증, UI 테스트, 데이터 정합성 등)
- 배포 후 문제가 나면 롤백이 복잡하다 → docs/PLAN.md에 각 단계의 rollback 절차를 남겼다
- 팀원들이 "뭐가 바뀌었어?" 하고 헷갈린다 → 커밋 메시지와 문서를 이해하기 쉽게 다듬었다

배포 순서도 중요했다

1. Bot 스크립트 먼저 (enrich, backfill, seed) — 검증만 끝나면 미리 도는 것도 OK
2. 데이터 준비 완료 후 UI 배포 (GroupPage.astro)
3. 문서 동시 업데이트

이 순서가 중요한 이유는, UI가 먼저 가면 빈 타임라인을 사용자가 보게 되기 때문이다. 데이터가 먼저 준비되어야 첫 인상이 좋다.

다음엔 어떻게 할까

이런 대규모 피처를 다시 해야 한다면:

• 피처 플래그(feature flag) 준비: 개발 중엔 새 기능을 감춰두고, 준비가 끝나면 일괄 활성화
• 데이터 마이그레이션 테스트 자동화: backfill이나 seed 스크립트는 스테이징에서 여러 번 돌려서 검증
• 롤링 배포 계획: 팀 수 확장 같은 건 점진적으로 할 수 있게 설계하기

이번 작업은 "한 스프린트에 네 개 기능을 다 밀어붙일 수 있다"는 자신감과 "다음땐 좀 더 체계적으로" 하는 교훈을 동시에 줬다. 팀이 커질수록 정보 구조가 복잡해진다는 걸 다시 한 번 느꼈고, 그걸 체계적으로 준비하는 게 얼마나 중요한지 알게 됐다.

🛒 이 글과 어울리는 추천 상품

• 모니터 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.