1차(MVP) 구축 제안 · 동작 데모 포함

검증 기반 시민 여론 플랫폼
1차 구축 제안서

신뢰가 존재 이유인 서비스라면, 만드는 순서도 신뢰를 지켜야 합니다

신영진 | 백엔드 개발 · 시스템 운영 파트너

1차 범위를 먼저 만들어 봤습니다

기획 의도 문서와 요구사항서를 읽고, 스코어보드와 의견·투표 흐름을 실제로 동작하게 구현했습니다

여론 스코어보드

찬성이 많은 순이 아니라 참여량 순으로 정렬합니다. 어느 쪽이 우세한지가 아니라 어떤 이슈에 시민이 모였는지를 보여주는 것이 이 화면의 역할이라고 보았습니다

의견 목록 · 연령 필터

방을 나누지 않고 하나의 공간에 모으되 보는 방식만 나눈다는 기획 의도를 그대로 반영했습니다. 연령·카테고리로 걸러볼 수 있습니다

참여와 공개

한 의견에 한 번만 참여하고, 결과는 연령대별로 나누어 보여줍니다

의견 상세 · 찬반 참여

참여 후 집계와 연령대별 분포가 함께 표시됩니다. 누가 어느 쪽을 선택했는지는 공개하지 않습니다

참여자 구성 공개

요구사항에는 없지만 기획 의도의 대표성 원칙을 화면으로 구현했습니다. 편향 여부를 스스로 드러내는 것이 오히려 수치의 설득력을 높입니다

가장 먼저 말씀드릴 것

1차 범위에서 조작 방지를 "구현하겠다"고 약속드리기 어렵습니다. 그 이유와 대안을 먼저 말씀드립니다

이메일·간편 로그인으로는 1인 1참여를 보장할 수 없습니다
이메일 계정은 한 사람이 얼마든지 만들 수 있고, 간편 로그인도 마찬가지입니다. 이 상태로 외부에 공개하면, 기획 의도 문서에서 '조급함의 역설'로 직접 짚으신 상황 — 저희가 막으려는 어뷰징이 저희 플랫폼에서 벌어지는 일 — 이 실제로 발생할 수 있습니다.

11차는 제한 공개로구조와 흐름을 검증하는 목적으로 운영하고, 본인인증이 붙는 2차부터 전면 공개하는 순서를 제안드립니다

2수치의 성격을 명시본인인증 전까지는 스코어보드 수치를 대외 인용 가능한 지표로 쓰지 않는다는 원칙을 화면에도 표기합니다

3가능한 억제 장치는 적용이메일 단계에서도 넣을 수 있는 장치는 모두 넣습니다 — 한 계정 한 의견 1회 참여, 동일 IP·기기 반복 참여 탐지 기록, 짧은 시간 내 대량 참여 차단

4한계를 문서로 남김무엇을 막을 수 있고 무엇을 막을 수 없는지 문서로 정리해 전달드립니다. 2차 본인인증 설계의 출발점이 됩니다

중립성 · 조작 방지 · 민감정보

성패가 이 세 가지에 달렸다고 보신 만큼, 설계에서 각각 어떻게 다룰지 말씀드립니다

운영자 불개입	정렬 기준을 참여량 하나로 고정합니다. 가중치나 추천 순 같은 기준을 두면 그 자체가 개입 여지가 됩니다. 운영자 계정에는 의견 생성·삭제 기능을 아예 만들지 않고, 불가피한 조치(법령 위반 게시물 등)는 삭제가 아닌 상태 변경으로 처리해 이력이 남게 합니다
색과 표현의 중립	찬성·반대에 빨강·파랑을 쓰지 않습니다. 정당 색을 연상시켜 화면 자체가 정파적으로 읽힐 수 있기 때문입니다. 데모에서는 청록·황토를 썼습니다. 사소해 보이지만 중립성이 의심받는 서비스에서는 먼저 눈에 들어오는 부분입니다
조작 방지	한 계정은 한 의견에 1회만 참여하도록 데이터 구조에서 제약합니다. 화면에서 막는 방식은 우회가 가능하므로 데이터베이스 차원에서 중복을 거부하는 구조로 만듭니다. 반복 참여 시도는 기록으로 남겨 2차 분석에 활용합니다
민감정보 보호	정치적 견해는 민감정보이므로, 누가 무엇에 투표했는지 조회할 수 있는 화면을 만들지 않습니다. 집계는 합계로만 조회되고, 개인 단위 조회 기능이 없으면 유출 위험 자체가 줄어듭니다. 연령·지역은 통계 목적의 구간 값으로만 저장하고 생년월일이나 상세 주소는 받지 않습니다

민감정보를 다루는 서비스에서 가장 안전한 설계는 보호를 잘하는 것이 아니라 애초에 덜 가지는 것입니다. 1차에서는 필요한 최소한만 수집하는 방향으로 잡았습니다.

2차 본인인증을 얹을 수 있는 회원 구조

1차에서 이렇게 만들어 두면, 2차에서 회원 데이터를 다시 만들지 않아도 됩니다

01로그인 수단 분리

회원 정보와 로그인 수단을 별도로 둡니다. 한 회원에 이메일·간편로그인·본인인증을 여러 개 연결할 수 있어, 2차에서 인증을 추가해도 기존 계정이 유지됩니다

02인증 등급 필드

회원마다 인증 수준(미인증 / 본인인증 완료)을 기록합니다. 2차에서 인증 회원의 참여만 따로 집계하거나, 두 수치를 나란히 보여주는 것이 가능해집니다

03중복 판별 키 자리 확보

본인인증은 사람 단위 식별값(CI 등)을 제공합니다. 이 값을 담을 자리를 미리 두고 중복 불가 조건을 걸어두면, 2차 연동 시 1인 1계정이 데이터 구조에서 보장됩니다

04과거 참여 이력 승계

미인증 상태의 참여 기록을 남겨두면, 인증 후 해당 회원의 이력으로 이어집니다. 인증 시점을 함께 기록해 두면 1차·2차 데이터를 구분해 볼 수도 있습니다

토론 기능 확장 — 의견에 댓글을 다는 구조는 게시글과 별도 테이블로 두면 1차 구조를 바꾸지 않고 추가할 수 있습니다. 다만 토론은 조작 방지보다 운영 부담이 훨씬 큰 기능입니다. 신고·비공개 처리 기준을 먼저 정하지 않고 열면 운영자 불개입 원칙과 충돌하게 되므로, 본인인증이 붙은 뒤에 여는 순서를 권장드립니다.

기술 스택과 예산 내 범위

개발 인력이 없으시다고 하여 쉬운 표현으로 적었습니다

화면반응형 웹

앱 설치 없이 PC와 휴대폰 브라우저에서 같은 주소로 열립니다. 언론이 링크를 인용하기에도 유리합니다

서버검증된 백엔드

회원·의견·투표를 처리합니다. 널리 쓰이는 방식으로 만들어 이후 다른 개발자가 이어받기 쉽게 합니다

데이터관계형 DB

중복 참여를 데이터 차원에서 거부하려면 관계형 구조가 적합합니다. 집계 정확성이 핵심인 서비스에 맞습니다

배포클라우드 + 자동 SSL

초기 트래픽은 작은 구성으로 충분하며, 언론 인용 등으로 급증할 때 서버를 키울 수 있는 구조로 둡니다

기능	15일 범위	비고
회원가입·로그인 (이메일)	포함	2차 인증 확장 가능한 구조로 설계
의견 게시 (작성·목록·상세)	포함
찬반 투표 및 집계	포함	중복 참여 데이터 차원 차단
카테고리 분류	포함
스코어보드	포함	서비스 핵심 화면
연령 태그·필터	포함
참여자 구성 공개	포함	요구사항 외 · 대표성 원칙 구현
디자인·반응형 대응	포함	기능 화면 중심, 별도 시안 제작은 제외
서버 구성·배포	포함	계정은 발주사 명의
간편 로그인(소셜) 연동	협의	일정상 이메일 우선, 여유 시 추가
댓글·토론 / 관리자 페이지 / 본인인증	2차	요구사항서 기준 제외

15일 일정에 대한 조건 — 짧은 일정이라 범위 변경 여지가 없습니다. 착수 전에 화면 목록을 문서로 고정하고, 진행 중 추가 요청은 2차로 분류하는 방식을 제안드립니다. 그래야 일정을 지킬 수 있습니다.

성공적인 마무리의 기준

이 프로젝트는 기능이 동작하는 것만으로는 성공이라고 보기 어렵습니다

1숫자를 설명할 수 있는 것"이 수치가 왜 이렇게 나왔는가"에 답할 수 있어야 합니다. 참여 기록이 남고, 집계 방식이 공개되고, 정렬 기준이 고정되어 있으면 답할 수 있습니다

2운영자가 개입할 수 없는 것개입하지 않겠다는 약속이 아니라, 개입할 기능이 없는 상태. 이것이 중립성을 구조로 보장한다는 말의 실제 의미라고 봅니다

32차로 이어지는 것본인인증을 붙일 때 회원 데이터를 새로 만들지 않아도 되는 상태. 1차 설계가 2차의 발목을 잡지 않는 것이 이번 범위의 숨은 목표입니다

4한계가 문서로 남는 것1차에서 막을 수 있는 것과 없는 것이 정리되어, 다음 판단의 근거가 되는 것

확인이 필요한 부분 — 운영 주체가 법률 검토와 함께 확정될 예정이라고 하셨는데, 계약 상대와 데이터 보관 주체가 정해져야 개인정보 처리 설계를 확정할 수 있습니다. 또한 연령 정보를 어떤 방식으로 받으실지(직접 입력 / 2차 인증 시 자동), 1차 오픈을 어느 범위까지 공개하실지도 함께 정해주시면 좋겠습니다.

숫자보다 먼저
구조를 만들겠습니다

신뢰가 존재 이유인 서비스라면, 만드는 순서도 신뢰를 지켜야 한다고 생각합니다.
데모는 직접 눌러보실 수 있습니다.