커뮤니티 제보로 데이터 품질 관리하기

기존엔 서비스 내 캐릭터 정보를 팀에서만 일방적으로 관리했다. 몇십 명의 로스터를 직접 조사·유지하는 방식인데, 규모가 커질수록 오류가 생기기 쉽고, 사용자가 발견한 정보 오류를 반영할 채널이 없었다. 이번 작업은 사용자가 직접 정보 오류를 신고하고 수정을 제안할 수 있도록 위젯을 추가한 것이다. 동시에 글로벌 사용자를 고려해 다국어 지원을 기본 설계로 잡았고, 로스터도 85명에서 134명으로 확장했다.

사용자 피드백 루프의 필요성

데이터 기반 서비스는 정보가 생명이다. 특히 커뮤니티를 대상으로 하는 플랫폼에서 "이 정보가 이상한데?"라는 제보가 얼마나 빠르게 들어오고, 얼마나 빨리 처리되느냐가 신뢰도를 좌우한다. 운영팀이 모든 정보를 완벽하게 유지할 수 없으니, 사용자를 정보 품질 관리의 파트너로 삼는 게 맞다.

RequestWidget.astro를 페이지에 임베드하면, 사용자는 별도 양식을 찾아다니지 않고도 바로 그 자리에서 "이거 잘못됐어요" 또는 "새로 추가해 주세요"라는 제보를 보낼 수 있다. 백엔드 API(content-request.ts)에서 요청을 수신해 처리하는 구조로 설계했으니, 운영 부담을 최소화하면서도 사용자 참여를 활성화할 수 있다.

다국어 설계를 초기부터 고려한 이유

이 기능을 만들면서 i18n을 처음부터 붙인 건, 서비스가 이미 여러 언어 사용자를 갖고 있었기 때문이다. 요청 위젯의 라벨, 버튼, 메시지들을 하드코딩하면 나중에 다국어를 추가할 때마다 코드를 뜯어야 한다. 그래서 ui.ts에 언어별 문구를 미리 정의하고, 컴포넌트가 참조하도록 설계했다.

이건 팀 리딩 관점에서도 중요한 판단이었다. "일단 영어로 만들고 나중에 다국어 추가하자"는 말은 거의 언제나 "나중에 안 한다"와 같다. 아키텍처에 다국어 계획이 없으면, 첫 요청이 들어올 때도 비용이 크다. 작지만 체계적인 초기 설계가 장기 유지보수를 결정한다.

변경 파일별 역할 분석

로스터 49명 확장의 의미

로스터가 85에서 134로 늘어난 건 단순히 "더 많은 데이터"가 아니라, 팀 업무 우선순위가 변했다는 신호다. 기존엔 핵심 대상만 관리했지만, 이제 커버리지를 넓히는 데 리소스를 투입한다는 뜻이다. 이 규모의 데이터 추가를 할 땐 보통:

• 마이그레이션 스크립트 작성 후 검증
• 기존·신규 데이터 스키마 일관성 확인
• 버그 발생 시 롤백 경로 준비

이런 선행 작업들이 있었을 거라고 본다.

회고: 기능 추가와 데이터 확장을 함께 설계할 때

이 작업에서 배운 건, 기능과 데이터 변경을 동시에 할 땐 각각의 변경 범위를 명확히 해야 한다는 것이다. 요청 위젯이 추가되면 사용자로부터 "이것도 수정해 달라"는 제보가 쏟아질 텐데, 그 제보들을 얼마나 빠르게 처리할 운영 체계가 있는지 함께 설계해야 한다. API만 만들어 배포하면, 결국 누가 언제 그 요청을 처리할지가 흐릿해진다.

또한 로스터 134명으로 확장하니, UI 성능 최적화도 이제 아젠다에 올라왔다. 목록 페이지의 렌더링 속도가 느려질 수 있으니 가상 스크롤이나 페이지네이션을 검토해야 한다. 한 커밋에 담긴 세 가지 변화(위젯 추가, 다국어, 데이터 확장)가 연쇄적으로 새로운 작업을 만들어낸 셈이다.

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

• 기계식키보드 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →

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