[ AI 프로젝트 ] 프론트부터 만든 민원처리 시스템 개발일지

세상이 너무나 좋아졌습니다. 

바이브 코딩으로 진행하게되었고, 기존 바이브 코딩  전에는 정말 DB 설계부터 기본이 튼튼하게 가야하는 것이 일반적인데.. 

이제 비교적 간단한 프로젝트는 그런 순서조차 상관 없게 된 것 같습니다. 

 

이번 프로젝트를 간략하게 현재까지 무엇을 했는지 설명드리겠습니다.

 

안녕하세요!
요즘 저는 공무원 업무 생산성을 높이고, 민원인의 불편함을 줄이는 민원처리 시스템을 만들고 있어요.
기술 스택은 대략 이런 느낌입니다:

• 🖥️ React + TypeScript + SWC
• 🗄️ Supabase(PostgreSQL, Storage, Edge Functions)
• 🧠 민원 분류/답변 보조용 AI 파이프라인

그런데 저는 조금 특이한 방식으로 시작했어요.

---

0. 왜 프론트부터 시작했나? 🧭

보통은

DB → API → 프론트

이 순서가 익숙하죠.

하지만 이번 프로젝트는 반대로 갔습니다.

✅ 프론트 먼저
✅ 그 뒤에 Supabase 스키마 설계

이유는 단순했어요.

화면을 먼저 만들면
“어떤 데이터가 진짜 필요한지”가 제일 빨리 보이거든요.

즉,
UI가 스키마를 이끄는 방식으로 MVP를 빠르게 현실화하는 전략이었습니다. 🚀

---

1. 2025-12-04 — 서비스 뼈대 세우기 🧱

이날은 한마디로
**“민원 서비스의 골격과 사용자 동선을 확정한 날”**이었어요.

1-1) 라우팅 구조 확정 🧩

서비스 기본 동선은 이렇게 잡았습니다.

• 🏠 / : 민원 목록
• 🔍 /civil/:id : 민원 상세
• ✍️ /reply/:id : 민원 답변

이 구조가 확정되면
사용자는 자연스럽게

목록 → 상세 → 답변

흐름으로 이동할 수 있어요.
이게 생각보다 엄청 중요합니다.

기능이 있어도
사용자가 “도달”하지 못하면 없는 기능이니까요. 😄

---

1-2) 상세 → 답변 UX 연결 🔗

상세페이지에 “답변하기” 버튼을 붙이는 작업이 진행됐고,
이로써 실제 서비스 느낌이 확 살아났습니다.

이 시점에서 저는
“이제 진짜 민원 시스템처럼 굴러가겠는데?”
라는 감각을 처음 받았어요.

---

1-3) Supabase FK 타입 지뢰 발견 💥

그리고…
현실이 저를 반겨줍니다.

에러의 핵심은 이거였어요:

• civil_complaints.id → bigint
• civil_replies.complaint_id → uuid

➡️ 서로 타입이 달라 FK가 걸리지 않는 문제

이건 정말 전형적인 초기 설계 실수 포인트죠.

그날의 교훈은 아주 명확했습니다:

🧨 “ID 타입은 초반에 통일하지 않으면
관계형 DB가 반드시 복수한다.”

---

✅ 12/04 요약

이날 저는

• 🧱 서비스 기본 뼈대와 사용자 이동 흐름을 만들었고
• 🔗 상세→답변 동선을 연결했으며
• 💥 DB 설계에서 반드시 정리해야 할 핵심 이슈(FK 타입 불일치)를 확인했습니다.

지금 돌아보면
**‘MVP의 뼈가 세워진 날’**이었어요.

---

2. 2025-12-08 — Hope(희망게시판) 연동과 운영 감각의 시작 🌊

이날은 분위기가 확 달라졌습니다.

이전이 “뼈대”였다면,
이제는 **“진짜 데이터”와 “운영 현실”**을 만나기 시작한 날이었어요.

---

2-1) 상세 조회 400 에러 🧪

Supabase REST 호출 중에
400 Bad Request가 발생했습니다.

이런 에러는 보통:

• 컬럼 타입 불일치
• 필터 조건 오류
• select 컬럼/스키마 불일치

같은 **“질문 자체가 잘못된 상황”**에서 자주 나와요.

그날 저는 이렇게 느꼈습니다.

😇 400은 서버가 말하는
“너 지금 질문 방법이 틀렸어”라는 신호다.

---

2-2) “직접 작성 시 작성일 누락” 🕒

이번엔 더 서비스스러운 문제가 등장했어요.

직접 민원을 작성하면 작성일이 누락되는 현상

이게 왜 치명적이냐면:

• 📌 목록 정렬이 깨지고
• 📌 최신/과거 기준이 흐려지고
• 📌 시스템 신뢰도가 떨어져요.

결국 이 문제는

• DB default를 둘지
• 프론트에서 명시 저장할지
• 혹은 둘 다 안전장치로 갈지

정책 결정을 요구하는 포인트였습니다.

---

2-3) “답변이 달리면 상태는 자동으로 완료” ✅

여기서 요구사항이 한 단계 업그레이드됩니다.

답변이 등록되면
목록에서 상태가 자동으로 “완료”가 되게 해달라.

사용자 관점에서는 너무 당연한 기대죠.

• 답변이 있는데 상태가 그대로면
  → “이 시스템 믿어도 되나?”
  라는 감정이 생기니까요 😅

이 요구는
이제 시스템이 MVP를 넘어 ‘운영 가능한 서비스’로 가고 있다는 신호였습니다.

---

2-4) 대규모 페이지 연동 고민 🧠

그리고 결정적으로
실전 운영 난이도가 열리는 질문이 나왔어요.

page=1 ~ page=2262
모든 데이터를 연동해서
실시간으로 목록에 추가할 수 있을까?

이 시점부터는 단순 구현을 넘어

• 증분 수집
• 중복 방지 키
• 동기화 전략
• 성능/비용 밸런스

같은
운영형 설계의 세계가 열립니다. 🌪️

---

2-5) AI 분류 흐름과 시스템 결합 🤖

또한 같은 흐름에서

• 담당부서 자동 분류
• 답변 불필요 판단

같은 AI 학습 파이프라인이
서비스와 자연스럽게 맞물리기 시작했어요.

이건 제 개인적으로 가장 기대되는 파트입니다.

“민원 시스템이 단순 CRUD가 아니라
공무원의 업무를 실제로 덜어주는 도구가 되는 지점”

---

✅ 12/08 요약

이날 저는

• 🌊 Hope 실데이터를 붙이며 운영 현실을 만났고
• 🧪 400 에러, 작성일 누락 같은 실전 이슈를 확인했으며
• ✅ 답변→상태 자동화 같은 완성도 요구를 구체화했고
• 🤖 AI 분류 기능이 서비스와 결합되는 방향성을 잡았습니다.

---

3. 이번 구간에서 얻은 핵심 교훈 3가지 🧠

1. 프론트 먼저 전략은 생각보다 강력하다
   • UI가 먼저 있으면
     DB 요구사항이 현실적으로 정리된다.
2. ID 타입은 초반에 통일하자
   • FK는 절대 봐주지 않는다 😇
3. 운영형 기능은 작은 자동화에서 시작한다
   • “답변이 달리면 상태 자동 변경”
     이런 디테일이 서비스 신뢰도를 만든다.

---

4. 다음 단계로 가기 위해 🎯

이제 다음 챕터는 이런 흐름이 될 것 같아요.

• 🗄️ Hope/Civil 데이터 구조 통합 정리
• 🧩 답변 이벤트 기반 상태 동기화 완성
• 🔁 대규모 페이지 크롤링/동기화 전략 확정
• 🧠 담당부서 분류 모델 실제 운영 반영
• 📊 관리자/공무원용 업무 대시보드 확장

---

마무리 🌿

이번 12/04~12/08 구간은
제가 느끼기에

“MVP 뼈대를 세우고,
진짜 서비스의 운영 현실로 진입한 분기점”

이었습니다.

그리고 무엇보다도

작은 문제 하나(작성일 누락, 상태 미반영)가
실제 서비스 신뢰도를 크게 흔든다는 걸

현장에서 체감한 시간이었어요.

다음 글에서는
희망게시판 대량 수집 전략과
Supabase 구조를 어떻게 정리했는지를
좀 더 구체적으로 기록해보려 합니다 😊

 

 

라고 정리를 친절하게 ChatGPT 가 해주었습니다. 

 

실제로 느낀점은,,, 어마무시하게 편해졌습니다. 

 본래 Cluade AI 를 사용하며 생산성이 어마무시한 정도까지 왔기에 해당 AI 보다 기존 ChatGPT 로는 얼마만큼의 성과와 생산력이 상승될까 했는데.. 

만족스럽습니다. 

달 220달러가 부담스러우시다면 ChatGPT 유로도 정말 좋을 것 같다는 평가입니다.

 

이번에 진행한 내용은 구체적인 명세서 없이 진행하다보니 여러 오류가 반복되어 발생했지만, 

정확한 명세서만 있다면 오류없이 구동가능한 서비스가 바로 만들어질 것이라 믿어 의심치않게되었습니다.