데이터 설계와 커뮤니케이션

게시판 사례 - 데이터베이스 설계

게시판을 하나 떠올려 보시면 가장 먼저 보이는 것은 제목, 글쓴이, 날짜, 조회수, 추천 수 같은 항목들일 것입니다. 그러나 기획자의 관점에서 보면 이것은 단순한 화면 구성 요소가 아니라, 모두 데이터의 결과물입니다. 화면에 보이는 숫자 하나, 아이콘 하나, 심지어 ‘N’ 표시처럼 사소해 보이는 요소까지도 모두 데이터베이스에 저장된 값을 기반으로 계산되고 노출된 것입니다.

예를 들어 새로운 글이 올라왔을 때 표시되는 ‘New’ 아이콘은 단순한 디자인 장식이 아닙니다. 글 작성 시점과 현재 시점을 비교하는 로직이 존재하고, 그 차이가 특정 기준을 넘지 않았을 때만 아이콘이 표시되도록 정책이 설계되어 있습니다. 즉, 아이콘 하나 뒤에도 시간 데이터와 비교 로직, 노출 정책이라는 설계가 숨어 있습니다. 이처럼 게시판 화면은 단순한 목록이 아니라, 데이터 설계와 정책의 집합체입니다. 기획자가 이 사실을 인지하지 못하면 화면은 만들 수 있을지 몰라도 구조는 만들 수 없습니다.

 

데이터 설계는 곧 정책 설계

게시판을 기획할 때 단순히 “제목, 작성자, 날짜를 보여준다”라고 정리하는 것만으로는 충분하지 않습니다. 더 중요한 질문은 이것입니다. 제목은 몇 글자까지 허용할 것인가? 줄임표 처리를 할 것인가? 두 줄까지 노출할 것인가? 모바일에서는 어떻게 보일 것인가?

어떤 기획자는 제목을 한 줄로 깔끔하게 정리하길 원할 수 있습니다. 반면 또 다른 기획자는 사용자가 입력한 제목은 최대한 그대로 보여줘야 한다고 판단할 수도 있습니다. 이 차이는 취향의 문제가 아니라 정책의 차이이며, 결국 데이터 길이 제한, 저장 구조, UI 노출 방식에 영향을 미칩니다.

‘New’ 아이콘 정책 역시 마찬가지입니다. 새 글에 7일 동안 깜빡이는 아이콘을 붙이겠다고 정한다면, 하루에 수십 개의 글이 올라오는 서비스에서는 화면이 지나치게 복잡해질 수 있습니다. 그렇다면 3시간만 표시할지, 깜빡임을 없애고 정적인 아이콘으로 바꿀지, 혹은 상단 5개 글에만 표시할지 등을 고민해야 합니다. 데이터는 단순히 저장하는 것이 아니라, 어떻게 보이게 할지까지 함께 설계되어야 합니다. 이 과정은 철저히 기획자의 영역입니다.

 

공지사항 게시판에서 데이터를 덜어내는 이유

공지사항 게시판을 설계한다고 가정해 보겠습니다. 자유게시판에서 사용하던 모든 데이터를 그대로 가져오는 것이 과연 맞을까요? 반드시 그렇지는 않습니다. 공지사항의 목적은 정보 전달입니다. 그렇다면 추천 수가 과연 필요한 요소일까요? 추천 수는 사용자 반응을 수치로 보여주는 데이터이지만, 공지의 중요도를 왜곡할 가능성이 있습니다. 추천이 많은 공지가 더 중요하다는 인식을 만들 수 있기 때문입니다. 공지는 추천 여부와 무관하게 중요합니다. 따라서 추천 수는 과감히 제거하는 것이 정책적으로 더 타당할 수 있습니다.

조회수 역시 마찬가지입니다. 조회수가 높으면 더 중요한 공지처럼 보일 수 있습니다. 하지만 공지는 원칙적으로 모두가 확인해야 하는 정보입니다. 변별력을 줄 필요가 없다면, 오히려 조회수를 제거하는 것이 더 목적에 부합합니다. 글쓴이 정보 또한 대부분의 경우 ‘관리자’로 통일된다면 굳이 개별 작성자명을 노출할 이유가 없습니다. 특정 커뮤니티처럼 운영진의 개성이 중요한 경우가 아니라면, 글쓴이 정보는 의미를 가지지 못합니다. 댓글 역시 신중해야 합니다. 공지사항이 토론의 장이 아니라면, 댓글은 불필요한 논쟁을 유발할 수 있습니다. 목적이 전달이라면, 상호작용 기능을 제거하는 것이 더 명확한 구조가 될 수 있습니다.

이처럼 데이터베이스 설계는 무엇을 추가할 것인가보다 무엇을 제거할 것인가에 대한 판단이 더 중요합니다.

 

데이터베이스는 기획자가 방향을 정한다

많은 사람들이 데이터베이스 설계는 개발자의 영역이라고 생각합니다. 그러나 실제로 개발자는 기획자가 정의한 정책을 구현하는 역할에 가깝습니다. 기획자는 어떤 데이터를 수집할지, 어떤 데이터를 저장할지, 어떤 데이터를 노출할지, 어떤 데이터를 수정 가능하게 둘지, 어떤 데이터는 절대 수정하지 못하게 할지를 먼저 정의해야 합니다. 이 정의가 명확해야 개발자는 ERD를 설계하고 테이블을 구성할 수 있습니다.

ERD는 기술적 설계도처럼 보이지만, 그 출발점은 기획자의 정책입니다. 관계를 어떻게 맺을지, 어떤 데이터가 중심이 될지, 종속 데이터는 무엇인지 결정하는 것은 기획 단계에서 이루어집니다. 데이터베이스는 기술적 산출물이지만, 구조의 방향성은 정책에서 나옵니다. 그리고 정책은 기획자가 만듭니다.

 

기획자의 역할은 데이터를 만지는 것이 아니라, 기준을 만드는 것

기획자가 직접 데이터를 삭제하거나 테이블을 생성하는 것은 아닙니다. 기획자의 역할은 데이터를 어떻게 다룰 것인지에 대한 기준을 만드는 것입니다.공지사항에서 추천 수를 없애겠다는 결정, 조회수를 비공개하겠다는 판단, 댓글을 막겠다는 정책은 모두 데이터 노출 기준을 정의하는 작업입니다. 이러한 기준이 명확해야 개발자는 구현 범위를 이해할 수 있습니다.

데이터베이스를 집에 비유하자면, 집을 짓는 것은 개발자의 역할일 수 있습니다. 그러나 몇 개의 방이 필요한지, 거실이 중심이 될지, 창문을 어디에 둘지는 기획자의 설계에 가깝습니다. 공간의 목적을 정하지 않으면 구조도 의미를 가지지 못합니다. 그래서 종종 긴장이 발생하기도 합니다. 개발자는 기술적 난이도와 리소스를 먼저 고려하고, 기획자는 사용자 경험과 비즈니스 가치를 우선시합니다.

이때 중요한 것은 기술적 설명을 모두 이해하려 애쓰는 것이 아니라, 왜 이 기능이 필요한지를 분명히 전달하는 것입니다. “이 기능은 고객 신뢰를 높이기 위해 반드시 필요하다”거나 “이 구조가 바뀌면 구매 전환율이 개선될 가능성이 높다”는 식으로 목적을 중심으로 설명해야 합니다. 기술적 한계가 제시되면 “그렇다면 어떻게 하면 가능할까요?”라고 묻는 것이 더 생산적입니다. 해결 방향을 함께 찾는 태도가 협업의 핵심입니다.

디자이너와의 커뮤니케이션에서도 마찬가지입니다. 마음에 들지 않는 디자인이 나오더라도 즉각적으로 부정하지 말고, 긍정적인 피드백으로 시작하는 것이 좋습니다. “이 디자인은 다른 프로젝트에서 더 빛날 것 같다”거나 “이번에는 조금 더 단순하게 가보면 어떨까요?”라는 식의 접근은 관계를 해치지 않으면서 방향을 조정할 수 있는 방법입니다. 그래서 기획자는 단순히 요구사항을 전달하는 사람이 아니라, 팀의 균형을 맞추는 조율자라고 할 수 있는 것입니다.

 

정리하자면, 기획자는 구조를 설계하는 사람이다

결국 데이터베이스 설계란 화면 뒤에서 서비스가 어떻게 작동할지를 정의하는 일입니다. 무엇을 저장하고, 무엇을 보여주고, 무엇을 허용하고, 무엇을 제한할지 결정하는 과정입니다. 기획자는 기술자가 아닐 수 있습니다. 그러나 서비스의 구조를 이해하고 방향을 제시하는 사람입니다. 데이터는 숫자와 문자열의 집합이 아니라, 사용자 경험과 비즈니스 전략이 녹아 있는 자산입니다. 데이터를 이해하는 기획자는 화면을 넘어 구조를 설계할 수 있습니다. 그리고 구조를 이해하는 기획자는 서비스의 본질을 다룰 수 있습니다.