설문·평가 수집 시스템 개발 시 검색과 필터 설계를 초기에 정해야 하는 이유를 설명합니다. 자유입력 대비 구조화 저장의 차이, 필터 대상 항목 추리기 기준, 사후 추가 비용까지 실무 관점에서 정리했습니다.
- 검색·필터를 먼저 정해야 하는 이유: 데이터 모델·화면·통계 전반을 좌우하는 첫 설계
- 필터 대상 항목 추리기: 응답자·기간·문항별 답변·소속을 정하는 기준과 우선순위
검색·필터를 먼저 정해야 하는 이유: 데이터 모델·화면·통계 전반을 좌우하는 첫 설계
행사가 끝나고 보고자료를 만들다 보면 어김없이 이런 요청이 온다. "정회원 응답만 따로 뽑아 주시고, 소속별로도 나눠 주세요." 이때 바로 답할 수 있느냐 없느냐는 개발 완성도의 문제가 아니라, 접수 폼을 설계한 그 순간 이미 결정돼 있다.
필터는 조회 옵션이 아니라 저장 구조다
검색·필터를 "나중에 관리자 화면에 붙이는 부가 기능"으로 생각하면 설계가 꼬이기 시작한다. 어떤 값으로 나중에 나눠 볼지가 먼저 정해져야, 그 값이 선택 버튼·코드값 형태의 구조화된 컬럼으로 저장된다. 소속을 자유입력으로 받으면 같은 기관인데도 표기가 제각각 흩어져서 사후 필터가 사실상 불가능해진다.
| 항목 | 자유입력 텍스트로 저장 | 구조화된 선택값으로 저장 |
|---|---|---|
| 사후 필터 | 표기가 흩어져 조건 검색 불가 | 조건 선택만으로 즉시 추출 |
| 통계 집계 | 값 정리 작업을 먼저 거쳐야 함 | 등급·소속·기간별 집계 즉시 가능 |
| 요금·할인 연동 | 사람이 건별로 확인 | 규칙 연결로 자동 계산 |
접수 단계에서 함께 설계돼야 하는 이유
필터 대상 항목 추리기: 응답자·기간·문항별 답변·소속을 정하는 기준과 우선순위
사무국 직원이 응답 엑셀을 열고 처음 던지는 질문은 거의 정해져 있다. "정회원 응답만 골라볼 수 있나요?" 이 질문에 바로 답하지 못한다면, 필터를 나중에 붙인 탓이다. 필터 대상 항목은 개발 착수 전에, 이미 현장에서 쓰이는 질문에서 추리면 된다.
1단계 — 데이터를 열자마자 나오는 질문부터 나열한다
- 누가 응답했나: 응답자 유형·회원 등급(정회원·준회원·학생회원)
- 언제 응답했나: 조사 기간, 사전등록 전후
- 어느 소속인가: 소속 기관·부서
- 어떤 문항에 어떤 답변을 했나: 선택형 답변값
포인트는 시스템이 이미 구분하고 있는 기준부터 후보에 넣는 것이다.
개발 후에 검색·필터를 추가할 때의 비용: 사후 설계 리스크 vs 초기 설계
행사를 마치고 자료 정리 중이라고 하자. 사무국에서 연락이 온다. "소속별로 참가자 정리해서 보내주세요." 그런데 응답 데이터가 이름·소속·문의사항까지 하나의 자유입력 텍스트에 몰아 담겨 있다면, 이 요청은 그대로 엑셀 수작업이 된다. 필터 추가가 비싼 이유가 정확히 여기서 시작된다.
비용의 본질은 필터 화면이 아니라 밑에 있는 데이터
| 항목 | 개발 후 추가(사후 설계) | 처음부터 반영(초기 설계) |
|---|---|---|
| 데이터 저장 | 자유입력 텍스트로 한 덩어리 저장 | 소속·직급·참석 세션 등 항목별 구조화 컬럼 |
| 필터 추가 시 재작업 | 기존 응답 전체 마이그레이션 + 데이터 정제 | 옵션 값 추가만으로 필터 즉시 동작 |
| 검색 속도 | 조건마다 전수 스캔 → 만 건 단위에서 조회가 수 초 | 인덱싱·페이징 설계로 결과 즉시 |
| 통계·엑셀 내보내기 | 가공 없이는 집계 자체가 불가 | 필터 결과 그대로 엑셀 다운로드 |
"필터 하나 추가하는 게 뭐가 어렵냐"라는 말이 나오지만, 실제 비용은 이미 쌓인 데이터를 다시 구조화하는 작업에서 나온다. 정제 중 응답 하나가 잘못 묶이면 통계 전체가 흔들리기 때문에, 검증에 드는 공수가 개발 자체보다 커지는 경우도 생긴다.
실시간 대시보드는 초기 설계의 결과물
개인정보 응답 데이터의 검색 권한 설계: 누가 무엇을 검색할 수 있는지 정하기
개발자에게 "응답 목록에 검색만 넣어 주세요"라고 말하는 순간, 그 검색창은 곧 개인정보 조회 도구가 됩니다. 설문·평가 응답에는 이름, 연락처, 소속이 함께 담기기 때문입니다. 실제 운영 중에 심사위원 계정으로 로그인해 참가자 이름을 검색해 보는 순간 "아, 이 화면은 아무나 보면 안 되는구나"를 깨닫는 경우가 많은데, 그때는 이미 화면이 다 나온 뒤입니다.
역할별 검색 범위부터 표로 정한다
| 항목 | 사무국 전체 관리자 | 심사위원·평가 담당자 | 협찬사 담당자 |
|---|---|---|---|
| 검색 대상 | 전체 응답(신원 포함) | 익명화된 응답만 | 자신이 수집한 데이터만 |
| 이름·연락처 필터 | 가능 | 불가(마스킹 처리) | 자기 부스 방문자만 |
| 엑셀 내보내기 | 가능 | 별도 권한 부여 시만 | 자기 데이터만 |
역할이 세 종류면 검색 화면도 사실상 세 벌입니다. 하나의 강력한 검색창에 나중에 권한을 붙이는 것보다, 처음부터 역할별로 검색 가능 필드를 다르게 설계하는 편이 구조도 단순해집니다.
동의 범위와 조회 범위를 일치시킨다
구축 전 확정용 기획 문서 체크리스트와 맺음
구축 전 확정용 기획 문서 체크리스트와 맺음
여기까지 읽으셨다면 감이 오실 겁니다. 검색과 필터는 개발 막바지에 붙이는 기능이 아니라, 데이터 모델·관리자 화면·통계·권한을 한 번에 결정하는 출발점이라는 것이요. 그래서 견적을 요청하거나 구축을 시작하기 전에, 사무국이 먼저 채워 넣을 기획 문서 하나를 정리해두시길 권합니다.
확정용 기획 문서, 이 여섯 가지가 전부입니다
- 필터 대상 필드 목록과 수집 방식 — 소속, 직급, 참가 유형, 세션 등 어떤 항목을 선택형(드롭다운)으로 받고 어떤 항목을 직접 입력으로 받을지 확정. 선택형이어야 필터가 정확히 동작합니다.
- 필터 조건별 우선순위 — 현장 접수대에서 가장 자주 쓸 조건(예: 미결제 + 당일 등록) 순으로 1순위를 정하기
- 예상 응답 규모와 검색 속도 목표 — 수백 건과 수만 건은 화면 설계가 다릅니다. "검색 누르면 3초 안에" 같은 체감 기준까지 적어두세요.
- 역할별 조회 권한표 — 사무국, 운영 스태프, 심사위원장이 각각 어디까지 보고 다운로드할 수 있는지 행으로 정리
- 엑셀 다운로드·통계 집계 양식 — 보고용 시트의 행·열 구성을 미리 샘플로 만들어 첨부
- 익명 처리 기준 — 심사 점수나 강연 평가에서 이름·소속을 어느 시점에 누가 볼 수 있는지 규칙화