게시판 하나에 숨어있던 생각지 못한 복잡함
새로운 플랫폼을 만들려는 클라이언트들이 자주 요청하는 기능 중 하나가 바로 게시판입니다.
일종의 커뮤니티 기능인데, 사람들 사이에 유대감이 생기고 커뮤니티가 형성되면 초기 플랫폼 활성화와 접속자 수에 큰 영향을 미치니까 꽤 매력적이고 효과적인 기능이죠.
그런데 이 게시판 기능이 생각보다 신경 쓸 게 많습니다.
"게시판 기능? 그냥 글 쓰고 댓글 달고 하면 되는 거 아닌가?"
처음에는 저도 그렇게 생각했어요. 기본적인 CRUD만 구현하면 되는 거 아닌가 싶었거든요. 이건 뭐 너무 기본 중의 기본이니까 신경 쓸 부분이라고 하기도 민망할 정도로요.
그런데 문제는 이게 앱이라면 구글과 애플의 앱 심사를 통과해야 한다는 점이었습니다. 그리고 이 두 회사는 커뮤니티 기능에 대해 생각보다 까다로운 기준을 가지고 있어요.
특정 글이나 사용자에 대한 신고 기능이 있어야 하고, 신고를 했다면 24시간 내 검토한다는 명확한 안내도 있어야 해요. 차단 기능도 필수고요. A사용자가 B사용자를 불쾌하게 여겨서 안 볼 권리를 보장해야 하거든요.
"아, 그럼 신고 버튼 하나 추가하면 되겠네?"
이것도 생각보다 간단하지 않았어요.
실제 진행 중이던 프로젝트에서 이런 일이 있었습니다.
개발적인 부분, 즉 기본적인 CRUD만 신경 쓰고 커뮤니티 기능을 기획했다가 뒤늦게 이 부분을 발견하게 된 거죠. 단순한 신고 기능만 넣어두었고, 구체적인 피드백 시스템은 설계가 미흡했어요.
한창 디자인을 진행 중이었고 프론트 개발 작업이 들어가기 직전이었거든요. 불행인지 다행인지 아직 늦지는 않았지만, 그래도 약간의 멘붕 상태였죠.
여기서 골치 아픈 건, 제대로 된 신고 처리 시스템을 만들려면 백엔드까지 손봐야 하는데 백엔드 개발은 이미 끝나 있었다는 점이었어요. 백엔드가 제일 먼저 개발되어야 하니까요.
그래서 고민이 됐습니다. "신고 기능을 제대로 추가하려면 일정이 늘어나는데, 그렇다고 앱 심사에서 통과하려면 무조건 추가가 필요한 기능이고..."
앱 스토어 정책을 꼼꼼히 읽어보니까, 핵심은 사용자를 보호하는 장치가 '있느냐'였지 반드시 완벽한 자동화 시스템일 필요는 없었어요.
그래서 이렇게 접근해 봤어요:
신고 기능 활용하기 이미 구현되어 있던 신고 기능을 베이스로, 신고 시 사용자 ID와 게시글 정보가 로그에 쌓이도록 했어요.
프론트에서 즉시 차단 신고를 하면 바로 그 사용자의 모든 게시물이 신고자에게 보이지 않도록 처리했습니다. 서버에서 삭제하는 게 아니라 클라이언트에서만 필터링하는 방식으로요.
클라이언트에게는 "신고 로그가 이렇게 쌓일 테니, 정말 문제가 있는 경우에는 어드민 페이지에서 이렇게 조치하시면 됩니다"라는 어드민 운영 가이드를 제공했어요.
결과적으로는 앱 심사를 무사히 통과했습니다. 심사관들도 커뮤니티 기능에 대해서는 별다른 지적을 하지 않았고요.
하지만 이 과정에서 깨달은 게 있어요.
타이밍이 정말 중요하다는 점이에요. 이런 정책 검토는 기획 단계에서부터 해야 하는데, 개발 막바지에 발견하니까 선택의 여지가 많지 않았어요.
그리고 당연하다고 생각했던 것들을 의심해봐야 한다는 것도요. 게시판 기능은 정말 수도 없이 봐왔고, 만들어봤던 기능인데도 이런 함정이 있을 줄 몰랐거든요.
이 경험 이후로는 사용자가 뭔가를 올릴 수 있는 기능들 - 댓글, 리뷰, 사진 업로드, 채팅 같은 것들이 들어간 프로젝트에서는 기획 초기부터 플랫폼 정책을 꼼꼼히 살펴보게 됐어요.
특히 이런 것들을 체크해 보죠:
해당 플랫폼의 사용자 생성 콘텐츠 정책
신고/차단 시스템이 어느 정도까지 필요한지
운영진이 어떤 식으로 관리해야 하는지
이용약관에 뭘 추가해야 하는지
게시판 기능은 정말 익숙하고 당연해 보이는 기능입니다. 이미 수없이 봐왔고, 사용해 봤던 기능이니까요.
하지만 이미 건넌 돌다리라고 해서 항상 안전한 건 아니더라고요. 플랫폼이 바뀌고, 정책이 업데이트되고, 상황이 달라지면서 예상치 못한 복잡함이 숨어있을 수 있거든요.
앞으로는 아무리 간단해 보이는 기능이라도 한 번 더 점검해 보는 습관을 가져야겠어요.
당연하다고 생각하는 순간이 가장 위험한 순간이니까요.