배경
- 약 8,000명 IT 기획자 커뮤니티의 자료실, 구글 시트 한 장
- 톡방에 올라온 링크를 운영자 1인이 수기 등록, 1,274건 누적
- 전원 편집권 개방으로 삭제 리스크, 카테고리 85개
- 2026년 1월 운영진 모집, 정비, 운영, 구독 3개 팀 구성
AI 자동화 · 커뮤니티 자료실
기획자 커뮤니티 자료실 재구축 ⬜
문제
- 시트 스크롤로만 찾을 수 있어 검색 불가
- 깨진 링크, 만료 자료, 임시 메모 약 350건 혼재
- 멤버 89%가 자료실 대신 AI 검색과 검색엔진 사용
- 등록·정비가 운영자 한 사람에게 집중
솔루션
- 기획자 44명 설문으로 문제 정의, 정리 기준 합의
- 1,274건을 AI로 1차 정제 후 사람 검수, 대분류 6개, 소분류 19개로 재분류
- URL이나 파일을 넣으면 AI가 제목, 요약, 분류를 채우고 운영진 2인이 승인하는 등록 체계
- 유의어, 초성, 오타 허용 검색, 무료 인프라로 비용 0원
성과
- 1,274건 → 공개 자료 663건 + 실무 Q&A 67건 (2026-09-03 오픈 기준)
- 카테고리 85개 → 6대분류, 19소분류
- UX 감사로 이슈 42건 발견, 치명 6건 전부 수정
- 운영 회의 5회 주재, 운영진 4인 등록·검수 체계 합의
Background
배경
1. 서비스 맥락 및 프로젝트 배경
맥비기획은 카카오톡 오픈채팅 4개 방으로 운영되는 약 8,000명 규모의 IT 기획자 커뮤니티입니다. 커뮤니티 운영자가 톡방에 올라오는 기획 자료 링크를 구글 시트 한 장에 모아 온 것이 자료실이었고, 2025년 말까지 1,274건이 쌓였습니다. 운영자 혼자 수집, 분류, 정비를 감당하기 어려워지자 2026년 1월 운영진을 모집했고, 정비팀, 운영팀, 구독서비스팀으로 나뉜 운영진 중 저는 운영팀에서 자료실 시스템을 맡았습니다.
2. 기존 업무 흐름 (As-Is)
자료 한 건이 자료실에 올라가고 찾아지는 과정은 다음과 같았습니다.
- 수집: 멤버가 톡방에 링크를 공유하면 운영자가 발견해 시트에 행 추가
- 분류: 운영자가 카테고리 이름을 직접 적어 넣음. 같은 뜻의 카테고리가 여러 이름으로 생겨 85개까지 늘어남
- 탐색: 멤버는 시트를 열어 스크롤하거나 브라우저 찾기로 검색. 정렬, 필터, 태그 없음
- 정비: 편집권이 전원에게 열려 있어 누구나 수정·삭제 가능. 깨진 링크는 발견한 사람이 있어야 정리
등록은 한 사람에게 몰리고, 찾기는 스크롤에 의존하고, 지우는 것은 누구나 할 수 있는 구조였습니다.
3. 운영상 문제점
2026년 5월 시트를 전수 분석한 결과입니다.
- 노이즈: 1,274건 중 링크나 제목이 비었거나 원글이 삭제된 것, 서비스가 종료된 것, 만료된 단축 URL, 색인용 마커가 약 350건(27%)이었습니다.
- 검색 불가: 카테고리 85개가 한 시트에 나열돼 있어 원하는 자료를 찾으려면 끝까지 스크롤해야 했습니다.
- 이탈: 6월 설문에서 멤버 89%가 자료를 AI 검색과 챗봇에서, 82%가 검색엔진에서 찾는다고 답했습니다. 커뮤니티와 자료실은 32%였습니다.
- 1인 의존과 삭제 리스크: 등록과 정비가 운영자 한 명에게 집중됐고, 전원 편집권이라 실수로 지워도 되돌릴 방법이 없었습니다.
자료가 없어서가 아니라, 찾을 수 없고 믿을 수 없어서 안 쓰는 자료실이었습니다.
Problem
문제
찾을 수 없음
1,274건이 시트 한 장에 85개 카테고리로 나열돼 있어 검색과 필터가 없었습니다. 설문에서 "찾는 데 시간이 오래 걸린다"가 50%, "내 상황에 맞는 자료를 골라내기 어렵다"가 59%였습니다.
믿을 수 없음
깨진 링크와 만료 자료가 27%를 차지했고 발행일과 요약이 없어 최신 여부를 알 수 없었습니다. 설문에서 "무엇을 믿어야 할지 어렵다" 55%, "최신 정보인지 판단하기 어렵다" 50%였습니다.
한 사람에게 묶인 등록과 정비
톡방 링크를 시트로 옮기는 일, 카테고리를 정하는 일, 깨진 링크를 지우는 일이 모두 운영자 한 명의 손에 있었습니다. 운영진을 모집했지만 함께 일할 도구와 규칙이 없었습니다.
누구나 지울 수 있는 구조
편집권이 전원에게 열려 있어 실수나 악의로 자료가 사라질 수 있었고, 백업이나 복구 수단이 없었습니다. 열려 있음이 오히려 등록을 망설이게 했습니다.
Goal
목표
유효한 자료만 남기고 검색으로 찾기
노이즈 27%를 걷어내고 남은 자료를 6개 대분류, 19개 소분류로 재분류해, 검색과 필터로 10초 안에 찾을 수 있게 하는 것을 목표로 했습니다.
등록 1인 → 멤버 제안 + 운영진 승인
누구나 제안하되 운영진 2명이 승인해야 게시되는 체계로 바꿔, 등록을 운영자 한 명에게서 떼어내면서 신뢰는 지키는 것을 목표로 했습니다.
설문으로 확인한 신뢰 요소를 구조에 반영
실무 사례(73%), 출처·맥락(52%), 업데이트 시점(36%)이 신뢰를 만든다는 답을 근거로, 자료마다 요약, 출처, 발행일, 형식을 갖추는 것을 목표로 했습니다.
인프라 비용 0원
커뮤니티 자료실이라 수익이 없으니 무료 한도 안에서 상시 운영되는 구성을 목표로 했습니다.
Solution
솔루션 작동 방식
자료 한 건이 올라가고 찾아지는 순서입니다. 사람이 하는 일은 제안과 검수뿐이고, 분류, 게시, 알림은 자동입니다.
- 제안(누구나): 등록 폼에 URL을 붙여넣거나 파일을 올립니다. 같은 링크가 이미 있으면 등록 전에 알려줍니다.
- 분석(자동): AI가 원문이나 파일 본문을 읽어 제목, 한 줄 요약, 대분류와 소분류, 태그, 형식을 채웁니다. 받아서 쓰는 자료인지 읽는 자료인지 판정해 양식·템플릿과 콘텐츠 메뉴 중 어디에 둘지도 정합니다.
- 검수(운영진): 등록 요청이 운영진에게 메일로 가고, 서로 다른 운영진 2명이 승인하면 게시됩니다. 제목과 설명을 다듬을 수 있고, 반려는 사유를 남깁니다. 7일 넘게 밀리면 리마인드 메일이 갑니다.
- 게시(자동): 승인 순간 사이트에 공개되고 제안자에게 결과 메일이 갑니다. 파일은 이때 커뮤니티 공용 드라이브로 옮겨집니다.
- 탐색(누구나): 자동완성, 유의어 60여 개, 오타와 초성 허용, 대·소분류 필터로 찾습니다. 결과가 0건인 검색어는 따로 모아 유의어와 수집 우선순위에 반영합니다.
What I did
실행
설문과 정리 기준으로 문제 정의
운영진 의견이 노션, 시트, 자동화 등 도구 이야기로 흩어져 있어, 먼저 사용자에게 물었습니다. 기획자 44명 설문을 설계, 수집, 분석해 "찾기 어렵다"보다 "내 상황에 맞는 것을 고르기 어렵다"와 "믿기 어렵다"가 핵심임을 확인하고, 이를 자료마다 요약, 출처, 발행일을 갖추고 검색으로 좁히는 요구사항으로 바꿨습니다. 시트 1,274건을 전수 분석해 즉시 제거, 보류, 유지 기준을 문서로 만들어 운영진 합의를 받았습니다.
정제·이관과 자료 체계 설계
빈 링크, 삭제된 원글, 종료된 서비스, 만료 단축 URL 등 약 350건을 AI로 1차 걸러내고, 애매한 것은 사람 검수 큐로 분리했습니다. 톡방 질문이 카테고리로 들어가 있던 87건은 실무 Q&A로 따로 뺐습니다. 카테고리 85개를 대분류 6개, 소분류 19개로 정리하고, 자료를 양식·템플릿(받아서 쓰는 것), 콘텐츠(읽는 것), 실무 Q&A 세 종류로 나눴습니다.
MVP에서 운영 스택으로 단계 전환
운영진 합의가 "비용 0"이었기 때문에 5월에 구글 시트, 드라이브, Apps Script만으로 첫 버전을 만들어 등록, 검수, 검색 흐름을 검증했습니다. 검색과 동기화에 한계가 보이자 6월에 Next.js와 Supabase로 옮기고, 8월 시트 동기화를 끊어 사이트 DB를 원본으로 확정했습니다. 6월부터 9월까지 347회 커밋으로 검색 강화, 파일 본문 분석, 지표 대시보드, 의견 보드, 운영 가이드를 붙였습니다.
UX 감사와 오픈 전 점검
7월에 홈, 검색, 등록, 승인, 접근성을 나눠 감사해 이슈 42건(치명 6, 높음 9, 중간 15, 낮음 12)을 찾았습니다. 자동 분석이 실패하면 등록 자체가 막히던 문제, 두 운영진이 동시에 승인하면 한쪽이 유실되던 문제 같은 치명 6건은 전부 고쳤습니다. 8월 31일 최종 점검 회의에서 등록·승인 방식, 파일 한도, 오픈 일자, 역할 분담을 결정하고 9월 3일 정식 오픈했습니다.
운영 체계와 인수인계 문서
5월부터 8월까지 운영 회의 5회를 주재하며 회의 자료와 회의록을 남겼고, 관리 화면 안에 운영 가이드, 업데이트 내역, 백로그를 두어 운영진이 바뀌어도 같은 방식으로 일할 수 있게 했습니다. 삭제 후보 217건은 커뮤니티 운영자에게 재검토를 받아 207건 삭제를 확정하고 8건을 복원했습니다.
Result
결과
정량적 변화
2026년 9월 3일 정식 오픈 기준입니다.
- 자료 정제시트 1,274건 → 공개 자료 663건 + 실무 Q&A 67건 (노이즈 약 350건 제거, 재검토로 8건 복원)
- 자료 체계카테고리 85개 → 대분류 6, 소분류 19, 자료 종류 3
- 등록 주체운영자 1인 수기 등록 → 누구나 제안 + 운영진 2인 승인, 운영진 4인이 주 2건씩 신규 등록
- 품질 점검UX 감사 이슈 42건 발견, 치명 6건 전부 수정
- 구축 기간과 비용MVP 5월 → 운영 스택 6월 → 정식 오픈 9월 3일, 인프라 비용 0원
운영 변화
- 등록, 검수, 자료 수정, 통계가 모두 사이트 안에서 이뤄지고, 시트는 매일 자동 복사되는 읽기 전용 백업이 됐습니다.
- 자료를 지워도 숨김·복구가 가능하고, 거절한 제안은 사유와 함께 남아 같은 자료가 다시 올라와도 판단할 수 있습니다.
- 결과 0건 검색어를 모아 유의어와 수집 우선순위에 반영하는 루틴이 생겼습니다.
사용자 관점
- "기획서"를 검색하면 RFP, 제안서, 화면설계서, 스토리보드까지 함께 찾아주고, 메뉴와 분류로 바로 좁힐 수 있습니다.
- 자료마다 한 줄 요약, 형식, 태그가 붙어 열어보기 전에 내 상황에 맞는지 판단할 수 있습니다.
사업 관점
- 운영진이 바뀌어도 이어갈 수 있는 도구와 문서가 갖춰져, 커뮤니티가 검토 중인 유료 구독 서비스의 기반이 됐습니다.
- 무료 구성이라 자료와 방문이 늘어도 비용이 그대로입니다.
Decisions
주요 결정
1. 열린 편집 vs 제안 후 승인
누구나 편집할 수 있는 시트는 참여를 열어 두는 장점이 있었지만, 실제로는 등록이 운영자 한 명에게 몰리고 삭제 리스크만 남았습니다. 열려 있음보다 믿을 수 있음이 자료실의 가치라고 판단해, 멤버는 제안만 하고 운영진 2명이 승인해야 게시되는 구조로 바꿨습니다. 대신 제안은 URL만 붙여넣으면 AI가 나머지를 채우게 해 참여 부담을 줄였습니다.
2. 비용 0 vs 확장성
운영진 첫 합의가 비용 0이었고 노션은 파일 5MB 제한 때문에 자료 보관에 맞지 않았습니다. 처음부터 웹 앱을 만들면 비용은 없지만 검증 없이 개발 리소스가 들어갑니다. 구글 시트, 드라이브, Apps Script로 첫 버전을 만들어 흐름을 검증한 뒤, 검색과 동기화 한계가 확인된 시점에 Next.js와 Supabase로 옮겼습니다. 두 번 만드는 비용을 감수하고 잘못된 구조에 갇히지 않는 쪽을 택했습니다.
3. 2인 승인 원칙 vs 운영 속도
2인 승인은 신뢰를 지키지만 운영진이 직접 올리는 자료까지 3명이 관여하게 됩니다. 8월 31일 회의에서 멤버 제안은 2인 승인을 유지하되, 운영진이 실명으로 등록한 자료는 다른 운영진 1명이 확인 후 승인하는 것으로 정했습니다. 관리자 단독 승인은 사유를 기록하는 예외로만 남겼습니다.
4. 전면 삭제 vs 보관
노이즈를 걷어낸 뒤에도 오래된 자료를 지울지 남길지가 갈렸습니다. 운영진 의견은 "옛 자료도 의미가 있으면 남긴다"였지만, 삭제 기준 없이는 정비가 멈춥니다. 링크가 죽었거나 내용이 갱신돼 틀린 것만 삭제 후보로 잡고, 커뮤니티 운영자의 재검토를 거쳐 확정했습니다. 삭제도 되돌릴 수 있게 백업을 남겼습니다.
Retrospective
배운 점과 아쉬운 점
오픈 후 지표는 아직 쌓는 중
방문, 검색 성공률, 다운로드는 GA와 PostHog로 추적하고 있지만, 오픈 3주라 "자료실을 다시 쓰게 됐다"고 말할 수치는 아직 없습니다. 설문에서 확인한 이탈(AI 검색 89%)이 얼마나 돌아오는지가 다음 검증 과제입니다.
한 사람 명의의 인프라
배포, DB, 인증, 분석 계정이 대부분 제 개인 명의로 돌아갑니다. 비용 0을 지키느라 생긴 구조인데, 운영진이 바뀌면 지속성 리스크가 됩니다. 8월 회의에서 공유했고 명의 분산이 다음 과제입니다.
요약 채움률
정제 직후 자료의 한 줄 요약이 4%만 채워져 있었습니다. 무료 모델 일일 한도 때문에 며칠에 걸쳐 나눠 채웠는데, 이관 전에 배치 계획을 세웠으면 오픈 전 검수 시간을 더 벌 수 있었습니다.
다른 프로젝트
안재찬 · asa0677@naver.com