24일차 회고 | 공공임대 청약 통합 안내 서비스 최종 발표와 미니프로젝트 마무리 | AI 오케스트레이션 개발자 국비지원

 

오늘은 5명이 함께 진행한 공공임대 청약 통합 안내 서비스 미니프로젝트를 최종 발표와 함께 마무리했다.

짧은 기간 동안 Streamlit, FastAPI, Supabase를 연결해 하나의 서비스를 만들고, GitHub를 이용한 협업과 테스트, 발표까지 경험했다.

프로젝트의 세부 구현 과정은 아래 글에 따로 정리했다.

• 공공임대 청약 통합 안내 서비스 미니프로젝트 전체 회고

이번 글에서는 같은 기능을 다시 길게 설명하기보다 24일차에 진행한 최종 발표와 프로젝트 마무리 과정을 중심으로 돌아보려고 한다.

---

오늘 진행한 내용

오늘은 새 기능을 많이 추가하기보다 지금까지 팀원들이 만든 기능을 하나의 서비스로 확인하고 발표할 내용을 정리하는 데 집중했다.

주요 작업은 다음과 같다.

• 사용자·관리자 화면 실행 상태 확인
• FastAPI와 Supabase 연결 상태 점검
• 담당 기능의 발표 범위 정리
• 시스템 구조와 데이터 흐름 설명 준비
• 발표 화면과 README 확인
• 최종 발표 진행
• 프로젝트 결과와 남은 과제 정리

기능을 만들 때는 각자 맡은 코드에 집중했다면, 발표를 준비할 때는 팀원들의 기능이 전체 서비스 안에서 어떻게 연결되는지를 다시 살펴봐야 했다.

---

우리가 완성한 서비스

이번 프로젝트에서는 여러 곳에 흩어진 공공임대·분양 청약 공고를 한곳에서 확인할 수 있는 서비스를 만들었다.

사용자는 회원가입과 로그인 후 청약 공고를 검색하고, 관심 있는 공고를 즐겨찾기로 관리할 수 있다.

공고의 위치를 기준으로 주변 지하철, 마트, 병원도 확인할 수 있으며 Gemini를 이용한 AI 상담과 사이트 이용 안내 기능도 사용할 수 있다.

관리자는 별도의 화면에서 청약 공고와 이미지를 등록·수정·삭제하고, 즐겨찾기 순위와 서비스 로그를 확인할 수 있다.

전체 구조는 다음과 같다.

사용자·관리자
→ Streamlit 화면
→ FastAPI API
→ Supabase 데이터베이스와 Storage
→ 처리 결과를 다시 화면에 표시

수업에서 각각 따로 배웠던 기술이 실제 서비스 안에서는 하나의 흐름으로 연결된다는 것을 확인할 수 있었다.

---

내가 담당한 기능

내가 주로 담당한 부분은 청약 공고 데이터 구조와 관리자 등록·관리 기능, 사용자 청약정보 조회 화면이었다.

주요 작업은 다음과 같다.

• 청약 공고 데이터 구조 개편
• 서울 25개 자치구 선택과 조건 검색
• 관리자 청약정보 등록·수정·삭제
• 등록 후 입력값 유지와 직접 초기화
• 보증금과 월세를 읽기 쉬운 금액으로 표시
• 제곱미터와 평수 함께 표시
• 상세주소와 공고 원문 링크 추가
• 신청 마감 D-day와 마감 공고 구분
• 공고 정렬과 페이지네이션
• 공고 한 건에 여러 이미지 연결
• 여러 공고 선택 후 안전한 일괄 삭제
• PDF·HWPX 기반 Gemini 자동 등록

처음에는 청약정보를 화면에 등록하고 보여주는 것만 생각했다.

하지만 기능을 계속 확장하면서 데이터베이스 구조, API 요청, 화면 상태, 이미지 파일과 예외 처리까지 함께 생각해야 했다.

---

발표에서 기능보다 문제 해결 과정을 설명했다

발표 시간이 제한되어 있어 구현한 모든 기능을 자세히 보여줄 수는 없었다.

그래서 내가 담당한 기능 가운데 다음 내용을 중심으로 발표했다.

• 청약 공고 데이터를 어떤 기준으로 나누어 저장했는지
• 공고 한 건에 여러 이미지를 어떻게 연결했는지
• 사용자에게 D-day와 정렬이 왜 필요한지
• 페이지네이션 전에 전체 데이터를 정렬해야 하는 이유
• 여러 공고를 안전하게 삭제하기 위해 어떤 확인 절차를 넣었는지

코드 내용을 그대로 읽는 대신 다음 순서로 설명하려고 했다.

어떤 문제가 있었는가
→ 왜 기존 방식으로는 부족했는가
→ 어떤 구조로 해결했는가
→ 사용자에게 무엇이 달라졌는가

발표를 준비하면서 기능을 직접 만들었다고 해서 그 기능을 제대로 설명할 수 있는 것은 아니라는 점을 느꼈다.

다른 사람이 이해할 수 있도록 설명하려면 내가 먼저 기능의 목적과 처리 흐름을 정확하게 알아야 했다.

---

Gemini 자동 등록 기능도 최종 반영했다

미니프로젝트 2일차에는 PDF와 HWPX 청약 공고를 분석하는 Gemini 자동 등록 기능을 프로토타입으로 만들었다.

이후 테스트와 보완을 진행해 최종적으로 관리자 화면에 자동 등록 기능을 추가했다.

처리 과정은 다음과 같다.

PDF·HWPX 공고 업로드
→ 글자와 이미지 추출
→ Gemini가 청약정보 구조화
→ 날짜·숫자·필수값 검증
→ 관리자가 결과와 이미지 확인
→ 선택한 공고만 등록

AI가 만든 값을 바로 데이터베이스에 저장하지 않고 프로그램 검증과 관리자 확인을 거치도록 했다.

Gemini가 정해진 JSON 형식으로 답하더라도 실제 날짜나 금액을 잘못 읽을 수 있기 때문이다.

이번 기능을 만들면서 자동화의 목적은 사람의 판단을 없애는 것이 아니라, 반복 입력을 줄이고 중요한 부분을 사람이 확인할 수 있게 만드는 것이라고 느꼈다.

---

GitHub 협업에서 배운 점

이번 프로젝트에서는 기능마다 Issue를 만들고 브랜치를 나누어 작업했다.

Issue 작성
→ 기능 브랜치 생성
→ 구현
→ 테스트
→ 커밋
→ Pull Request
→ develop 병합

처음에는 GitHub를 코드를 저장하는 공간 정도로 생각했다.

하지만 프로젝트를 진행하면서 GitHub는 누가 어떤 기능을 작업하고 있는지 공유하고, 변경 이유와 테스트 결과를 기록하는 협업 도구라는 것을 알게 됐다.

PR을 작성할 때도 단순히 기능 이름만 적지 않고 다음 내용을 함께 정리했다.

• 기존 문제
• 문제의 원인
• 해결 방법
• 변경된 파일
• 테스트 결과
• 아직 확인하지 못한 부분

이런 기록이 있어야 나중에 코드를 다시 볼 때도 왜 그렇게 만들었는지 이해할 수 있었다.

---

프로젝트에서 가장 크게 배운 점

이번 프로젝트에서는 단순히 FastAPI나 Streamlit 사용법만 배운 것이 아니었다.

첫째, 화면에서 기능이 보인다고 해서 개발이 끝난 것은 아니었다.

버튼을 눌렀을 때 API가 어떤 데이터를 받고, 데이터베이스에는 어떻게 저장되며, 실패했을 때 무엇이 남는지까지 확인해야 했다.

둘째, 삭제와 자동화에는 반드시 확인 과정이 필요했다.

일괄 삭제에는 삭제 대상을 보여주는 단계가 필요했고, AI 자동 등록에는 추출 결과를 검증하고 관리자가 수정하는 단계가 필요했다.

셋째, 모든 작업을 AI에게 맡길 필요는 없었다.

정해진 문서 구조에서 글자와 이미지를 꺼내는 작업은 일반 코드가 더 안정적이었다. AI는 추출한 내용의 의미를 판단하고 구조화하는 부분에 사용하는 것이 효과적이었다.

넷째, 테스트는 정상 동작만 확인하는 과정이 아니었다.

잘못된 파일, 중복 요청, 일부 업로드 실패, 잘못된 페이지 번호처럼 문제가 생길 수 있는 상황도 함께 확인해야 했다.

마지막으로 Git, 문서 작성과 발표도 개발 과정의 일부라는 것을 배웠다.

---

아쉬웠던 점

프로젝트는 마무리했지만 모든 기능이 완벽하게 끝난 것은 아니다.

실제 배포 환경에서의 전체 동작 확인과 다양한 형식의 PDF·HWPX 문서 분석은 더 진행할 필요가 있다.

Gemini 자동 등록도 다음 내용을 추가로 확인해야 한다.

• 문서 형식에 따른 추출 정확도
• 잘못 연결된 이미지 수정 과정
• 기존 공고와의 중복 검사
• 등록 일부 실패 시 Storage 파일 정리
• 실제 응답 시간과 사용 비용

프로젝트가 끝났다고 해서 모든 문제가 사라지는 것은 아니었다.

현재 가능한 기능과 앞으로 개선할 부분을 구분해 기록하는 것도 중요했다.

---

24일차를 마치며

기초부터 다시 배우는 입장에서 처음 프로젝트를 시작했을 때는 Streamlit, FastAPI와 Supabase가 각각 따로 떨어진 기술처럼 느껴졌다.

하지만 이번 프로젝트를 통해 화면에서 입력한 데이터가 API를 거쳐 데이터베이스에 저장되고, 다시 사용자 화면에 표시되는 전체 흐름을 경험할 수 있었다.

정답 코드가 없는 상태에서 데이터 구조를 정하고, 오류의 원인을 찾고, 기능의 안전장치를 고민하는 과정은 예제 코드를 따라 작성할 때와 많이 달랐다.

특히 이번 프로젝트에서는 기능을 동작하게 만드는 것에서 끝나지 않고 사용자가 어떻게 사용할지를 생각하는 것이 중요했다.

AI 도구의 도움으로 코드를 빠르게 작성할 수는 있지만, 그 코드가 왜 필요한지와 어떤 문제를 해결하는지는 내가 이해하고 설명해야 했다.

첫 번째 미니프로젝트는 끝났지만, 이번에 부족했던 부분을 다시 확인하면서 다음 프로젝트에서는 데이터 구조, 예외 처리, 테스트와 문서화를 처음부터 함께 계획해보고 싶다.

#AI오케스트레이션 #엔코아AI캠퍼스 #미니프로젝트 #FastAPI #Streamlit #Supabase #GeminiAPI #GitHub협업 #청약정보서비스 #프로젝트회고