AI Native Web Application
missionary
교회 선교 운영의 모든 것을 하나의 플랫폼으로
Overview
프로젝트 배경
매년 여름·겨울 약 10,000 명의 교인이 9개 해외선교와 10개 국내선교에 각 선교마다 50~700명 규모로 참여합니다.
이 대규모 선교 운영 과정에서 발견한 구조적 문제를 해결하기 위해 시작된 프로젝트입니다. 등록 신청부터 팀 편성, 회계, 보고서까지 6개 이상의 도구에 흩어져 있던 워크플로우를 하나의 통합 플랫폼으로 일원화하고 있습니다.
현재 관리자용 어드민 시스템(선교·등록·유저·연계지 관리)을 구현한 상태이며, Next.js 16 + NestJS 11 모노레포 구조로 4개 패키지를 관리합니다.
Problem
무엇이 문제였나
“6개 이상의 도구에 흩어진 워크플로우를 하나의 통합 플랫폼으로 일원화”
선교 기간이 되면 각 선교별 준비팀이 독립적으로 선교를 준비합니다. 이 과정에서 다음과 같은 문제가 반복적으로 발생했습니다.
첫째, 프로세스별 도구 파편화입니다. 선교 운영에 필요한 업무마다 서로 다른 도구를 사용하고 있어, 데이터와 워크플로우가 분산되었습니다.
둘째, 통합 관리 뷰의 부재입니다. 관리자가 선교 전체 현황을 하나의 시스템에서 파악할 수 없었습니다.
셋째, 정보 접근성 한계입니다. 자신이 담당한 업무 외에는 진행 상황을 확인하기 어려워, 팀 간 협업에 병목이 발생했습니다.
넷째, 포맷 비통일입니다. 선교팀마다 문서 양식과 관리 방식이 달라, 교회 차원의 일관성 유지가 불가능했습니다.
실제 선교 준비팀원 인터뷰에서 이 문제들은 더 구체적으로 드러났습니다. 등록 쿼터 관리 기능이 없어 공식 시스템을 우회해 팀 내 자체 등록 링크를 별도로 운영하고 있었고, 명단 접근 권한이 준장·등록담당자에게만 열려 있어 방배정·버스·식수 배정 같은 업무가 1인에게 집중되고 있었습니다. "어쩔 수 없이 자체적으로 팀 내에서 자체 등록 링크를 또 만들어" — 시스템이 있어도 신뢰하지 못해 우회하는 상황이 반복되고 있었습니다.
AS-IS
등록 신청
도구: Google Form
한계: 차수마다 재생성, 응답 데이터 분산
개인정보 수집
도구: 교회 자체 시스템
한계: 등록 데이터와 연동 불가
공지 및 대원 소통
도구: 카카오톡
한계: 이력 관리·검색 어려움
준비팀 문서 관리
도구: Notion
한계: 팀별 포맷 제각각
회계·영수증 관리
도구: 엑셀, 한글 문서
한계: 수작업, 버전 충돌
선교 보고서 관리
도구: 한글 문서
한계: 정보 파편화, 버전 관리 어려움
Process
어떻게 해결했나
흩어진 도구들을 하나로 묶기 위해, 선교 운영 전체를 관리하는 어드민 시스템을 개발했습니다. 선교 관리, 등록 관리, 유저 관리, 연계지 관리를 하나의 플랫폼에서 처리할 수 있도록 구현했으며, 구체적으로 다음 세 가지에 집중했습니다.
01
모노레포 아키텍처 설계
사용자앱(Next.js) + 관리자앱(Next.js) + API서버(NestJS) + 디자인시스템을 pnpm workspace로 통합했습니다. 패키지 간 타입 공유와 일관된 린트/빌드 파이프라인을 구축하고, Prisma를 ORM으로 채택해 PostgreSQL 스키마를 18개 모델로 설계했습니다.
02
동적 폼 빌더 구현
Google Forms를 대체하는 드래그앤드롭 폼 빌더를 구현했습니다. 관리자가 선교별 커스텀 등록 양식을 설계할 수 있으며, 텍스트·선택·파일 업로드 등 다양한 필드 타입을 지원합니다. 응답 데이터는 자동으로 대원 프로필과 연동됩니다.
03
일관된 어드민 대시보드 패턴
선교·등록·유저·연계지 각 도메인별로 일관된 관리 대시보드를 구축했습니다. 목록 조회, 상세 확인, 생성/수정/삭제를 동일한 UI 패턴으로 제공하며, overlay-kit 기반 슬라이드 패널과 모달로 페이지 이동 없이 빠르게 작업할 수 있습니다. 흩어지기 쉬운 오버레이의 상태 선언·이벤트 핸들링·렌더링 로직을 overlay-kit의 선언적 API로 한 곳에 모아 관리합니다.
04
상세 화면과 폼 설계
각 도메인의 상세 화면은 슬라이드 패널 또는 모달로 구성되며, 데이터의 생성과 수정을 폼 기반으로 처리합니다. React Hook Form + Zod로 타입 안전한 폼 검증을 구현하고, TanStack Query로 서버 상태를 관리하여 수정 즉시 목록에 반영됩니다. 폼 빌더에서 정의한 커스텀 필드도 동적으로 렌더링되어, 도메인마다 다른 입력 양식에 하나의 패턴으로 대응합니다.
Development Process
어떻게 만들었나
Claude의 Agent Team 모드를 활용하여, 5명의 AI 에이전트가 협업하는 방식으로 개발했습니다. 각 에이전트가 역할에 맞는 산출물을 생성하고, 파이프라인을 따라 검증·구현·테스트까지 일관된 프로세스로 진행합니다.
Product Owner
요구사항 정의, PRD 작성
Product Designer
UI/UX 설계, 디자인 스펙
Frontend Engineer
React/Next.js 구현
Backend Engineer
NestJS API 구현
QA Engineer
테스트 전략, 코드 검증
개발 싸이클
What's Next
앞으로의 계획
Retrospective
회고
실제 선교를 준비하는 사용자를 인터뷰하고, 문제를 정의하고, 해결하는 전체 과정을 경험했습니다. 프론트엔드 개발자로서 한 프로젝트의 기획부터 설계, 구현, 테스트까지 전체 싸이클을 직접 경험할 수 있었던 것이 가장 큰 수확이었습니다.
특히 AI 에이전트(PO, PD)를 통해 PRD와 디자인 스펙을 작성하고, 검토하고, 구체화하는 과정이 예상보다 긴 시간이 필요했습니다. 더 많은 시간과 노력을 들일수록 좋은 결과물이 나온다는 것을 체감했습니다.
아직 해결해야 할 문제들이 많이 남아있습니다. 어드민 기능 추가와 고도화, 사용자 앱 개발, 개인정보 처리 방침, 운영 비용 산정, 더 실질적인 유저 인터뷰와 문제 정의가 필요합니다. 현재 교회 선교 담당 부서와 도입을 논의 중이며, 결정되면 사용자 온보딩, 기존 데이터 마이그레이션 같은 현실적인 과제도 기다리고 있습니다.
하지만 문제는 해결하라고 있는 것이라 생각합니다. 하나씩 풀어가다 보면 세상을 바꾸진 못하더라도, 내가 속한 작은 세상의 문제는 해결할 수 있지 않을까 — 그런 기대를 갖고 계속 만들어 나가고 있습니다.
다음 프로젝트
🤖 my-harness →