멤버 카드에 퀵팩트 정보 추가하기

멤버나 그룹의 흥미로운 사실들을 데이터베이스에서 가져와 카드 형태로 보여주는 기능을 구현했다. 커밋 메시지에 B1+B2+B3 로 표기한 건, 이 작업이 세 계층으로 명확히 분리됐다는 의도를 담은 것. 데이터베이스 스키마 설계부터 봇의 enrichment 로직, 마지막으로 프론트엔드 UI 렌더링까지 순서대로 쌓은 거다.

왜 이런 구조가 필요했나

처음엔 간단한 기능 요청이었을 수도 있다. "멤버 페이지에 더 흥미로운 정보를 보여주고 싶어." 하지만 단순히 고정된 텍스트를 하드코딩할 순 없었다. 정보는 계속 업데이트되고, 멤버 수도 증가하며, 나중에 다른 페이지에서도 같은 데이터를 써야 할 수도 있기 때문. 그래서 스키마-먼저 사고로 접근했다. 데이터의 형태를 먼저 정의하고, 그 다음에 어떻게 채울지, 어떻게 보여줄지 결정하는 순서. 이렇게 하면 나중에 변화에 대응하기도 쉽다.

3단계 구현 전략

B1 단계 — 데이터 기초 다지기

마이그레이션 파일을 먼저 작성하는 건 필수다. 팀원이 코드를 받아서 git pull 한 후 DB를 최신 상태로 유지하려면 마이그레이션 스크립트가 명확해야 한다. 또한 schema.sql 에 변경 사항을 반영하면, 나중에 새 개발자가 처음부터 DB를 구성할 때도 일관된 상태를 보장한다. 이 과정에서 "quickfacts 가 어떤 구조일까" 를 정해지는데, 이게 뒤의 두 단계 전체를 제약한다. 그래서 무시하고 넘어갈 수 없는 부분.

B2 단계 — 자동화로 데이터 채우기

스키마만으로는 데이터가 없다. enrich_members.py 는 이미 시스템에 있는 멤버/그룹 정보를 읽고, 각각에 맞는 quickfacts 항목들을 생성해서 DB에 저장하는 봇이다. 초기 데이터(groups-seed.txt, seed_groups.py)를 준비한 이유는, 개발 환경에서 테스트할 때 빈 DB로 시작하면 UI 개발을 못 한다는 걸 알기 때문. 봇이 제대로 작동하는지 확인하고, 프론트엔드가 그 출력을 제대로 렌더링하는지 검증하려면 샘플 데이터가 있어야 한다.

여기서 주의할 점 하나 — enrichment 봇은 멱등(idempotent)해야 한다. 같은 데이터를 여러 번 돌려도 중복이 생기지 않거나, 또는 깔끔하게 덮어써진다는 뜻. 봇이 크론잡으로 주기적으로 실행되거나, 운영 중에 재실행될 수 있기 때문이다. 이걸 간과하면 나중에 quickfacts 레코드가 중복으로 쌓이는 상황을 마주한다.

B3 단계 — 사용자 눈에 띄는 곳에

마지막이 UI 렌더링. GroupPage.astro 에서 quickfacts 데이터를 가져와서 카드로 표시한다. 이 단계에서는 DB와 봇이 이미 완성됐으므로, 어떻게 예쁘게 보일지, 정렬은 어떻게 할지, 반응형 디자인은 어떻게 맞출지 같은 UX에만 집중할 수 있다.

회고 — 이런 식으로 진행하면 좋은 이유

풀스택 기능을 이렇게 3단계로 나누는 건 단순한 업무 분배보다 더 깊은 의미가 있다.

첫째, 각 계층의 책임이 명확하다. 데이터 계층이 변하면 마이그레이션 파일을 보면 뭐가 바뀌었는지 알 수 있다. 봇 로직이 변하면 enrichment 코드만 수정하면 되고, UI가 변하면 컴포넌트만 건드린다. 만약 이 세 가지를 한 파일에 섞어서 했다면? 나중에 누군가가 "quickfacts 가 왜 안 나와?" 라고 물었을 때, 그게 데이터 문제인지, 봇이 안 돌았는지, 프론트 버그인지 추적하기 어려워진다.

둘째, 병렬로 진행할 수 있다. B1이 완료되면 B2와 B3는 동시에 진행 가능하다. 프론트엔드 개발자는 샘플 데이터로 UI를 만들고, 백엔드는 enrichment 로직을 완성하고, 나중에 통합 테스트만 하면 된다.

셋째, 테스트와 검증이 수월하다. 각 단계마다 작은 테스트 케이스를 만들 수 있다. DB 쿼리가 맞는지, 봇이 제대로 데이터를 수집하는지, UI가 null 값을 제대로 처리하는지. 작은 문제들을 각 계층에서 일찍 잡아낸다.

초기 데이터의 중요성도 놓치면 안 된다. groups-seed.txt 같은 파일이 있으면, 새 개발자가 onboard 할 때 한 번의 스크립트 실행으로 테스트 가능한 상태를 만들 수 있다. 이게 없으면 "어, DB가 비어있는데?" 하며 헤맬 수도 있다.

마지막으로, 비슷한 기능(예: 그룹 통계 보기, 멤버 트렌드 데이터 추가)이 나중에 필요할 때, 이번 quickfacts 구조를 그대로 따라 하면 된다. 패턴이 정해져 있으면 팀의 일관성도 높아진다.

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

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

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