오늘은 새로운 수업 진도 대신 1차 미니프로젝트의 청약 공고 관리 기능을 보완하고 직접 테스트했다.
이번 작업의 핵심은 하나의 청약 공고에 여러 장의 이미지를 등록하고, 공고문에서 추출한 정보를 실제 서비스 형식에 맞게 입력하는 것이었다.
다중 이미지 업로드 기능 보완
기존에는 청약 공고마다 대표 이미지 한 장만 사용할 수 있었다. 하지만 실제 공고문에는 건물 전경뿐만 아니라 약도, 주차장, 방 내부, 부엌, 화장실 등 여러 사진이 포함될 수 있다.
이를 반영하여 하나의 공고에 최대 20장의 사진을 등록할 수 있도록 기능을 보완했다.
- 최대 업로드 장수: 20장
- 이미지 한 장의 최대 크기: 5MB
- 한 번에 올릴 수 있는 전체 용량: 60MB
- 이미지 업로드 제한 시간: 15초에서 180초로 변경
- 선택한 이미지의 개수와 전체 용량 표시
- 업로드 전 이미지 미리보기 제공
- 첫 번째 사진을 목록의 대표 이미지로 사용
20장에 각각 5MB를 적용하면 최대 100MB가 될 수 있다. 이렇게 큰 파일을 한 번에 보내면 업로드가 중간에 멈출 가능성이 있어 전체 용량을 60MB로 제한했다.
단순히 장수만 늘리는 것이 아니라 실제 업로드 과정에서 발생할 수 있는 문제까지 고려해야 한다는 점을 알게 됐다.
사용자·관리자 상세 화면 개선
공고 목록에서는 기존처럼 대표 이미지 한 장만 보여주고, 상세 정보를 펼치면 등록된 전체 사진을 확인할 수 있도록 구성했다.
상세 화면에서는 사진이 한 줄에 네 장씩 배치된다. 공고 목록에 모든 사진을 표시하면 화면이 복잡해질 수 있기 때문에 목록과 상세 화면의 역할을 나눈 것이다.
- 목록 화면: 대표 이미지 한 장 표시
- 상세 화면: 등록된 전체 이미지 표시
- 사용자와 관리자 화면에 같은 이미지 구성 적용
- 공고 설명보다 위쪽에 이미지 배치
이 작업을 통해 많은 정보를 한 화면에 무조건 보여주는 것보다 사용자가 필요한 순간에 확인할 수 있도록 구성하는 것이 중요하다는 점을 배웠다.
수정 화면의 사진 관리 분리
수정 화면에서는 공고 정보와 사진을 따로 관리할 수 있도록 기능을 분리했다.
기존 사진마다 삭제 버튼을 제공하고, 새로운 사진을 추가할 때는 남은 등록 가능 장수를 안내하도록 구성했다. 사진을 삭제할 때는 실수를 방지하기 위해 확인 과정도 거치게 했다.
특히 중요하게 확인한 부분은 공고명이나 보증금 같은 일반 정보만 수정했을 때 기존 사진이 삭제되지 않는지였다.
- 기존 사진을 한 장씩 삭제
- 새로운 사진만 추가
- 사진 삭제 전 확인
- 공고 정보 수정 시 기존 사진 유지
- 사진을 수정해도 입력 중인 공고 정보 유지
기능을 분리하니 수정 화면의 역할이 더 명확해지고, 사용자가 실수로 사진을 잃을 가능성도 줄일 수 있었다.
이미지 저장 과정의 예외 처리
여러 장의 이미지를 다루면 일부 사진만 업로드된 뒤 오류가 발생할 수도 있다. 이때 이미 올라간 파일을 그대로 두면 Storage에 사용하지 않는 파일이 계속 쌓인다.
이를 막기 위해 업로드 도중 실패하면 먼저 올라간 파일을 다시 삭제하도록 처리했다.
또한 다음과 같은 상황도 함께 점검했다.
- 다른 공고에서 사용 중인 이미지는 삭제하지 않기
- 공고 삭제 시 연결된 이미지도 함께 정리하기
- 대표 이미지도 전체 이미지 목록에 포함하기
- 정보만 수정할 때 추가 사진을 그대로 유지하기
- 목록 데이터가 삭제되기 전에 연결된 이미지 경로 확보하기
단순히 화면에서 사진이 보이는 것만 확인하는 것이 아니라 데이터베이스와 Storage의 상태까지 함께 생각해야 한다는 것을 배웠다.
실제 청약 공고 데이터 추출
기능 확인을 위해 금천구 예술인주택 공고문에서 서비스 등록에 필요한 정보를 추출했다.
같은 공고 안에서도 호실마다 면적과 임대조건이 달랐기 때문에 하나의 행으로 합치지 않고 총 7개 호실로 나누어 정리했다.
추출한 주요 정보는 다음과 같다.
- 공고명과 공고번호
- 주택명과 동·호수
- 도로명주소와 지번주소
- 전용·공용·공급면적
- 보증금과 월 임대료
- 신청 시작일과 마감일
- 신청자격과 소득·자산 기준
- 접수·계약·입주 일정
- 문의처와 원문 URL
공고문에 포함된 이미지도 분리했다.
- 현장 약도
- 건물 전경
- 주차장
- 방 내부
- 부엌
- 화장실
- 연습실
- 커뮤니티실
- 계단
- 옥상
문서 안에는 장식용 이미지도 포함되어 있었기 때문에 모든 이미지를 그대로 등록하지 않고, 실제 주택 정보와 관련된 사진만 구분해야 했다.
상세설명 형식 정리
상세설명은 긴 문장으로 작성하지 않고 사용자가 빠르게 내용을 확인할 수 있도록 항목형으로 정리했다.
**신청자격** : 서울 거주 만 19세 이상 무주택 문화예술인
**소득기준** : 도시근로자 월평균 소득 70% 이하
**자산기준** : 소득 50% 이하인 경우 총자산 2억 4,500만 원·자동차 4,542만 원 이하
**공급 구성** : 총 7호(가동 3호·나동 4호)
**추가 자격** : 금천구 거주자 우선, 예술활동 증명서류 제출 필수
**주의사항** : 외국인은 신청할 수 없으며 관리비와 세대별 공과금은 별도입니다.
주소, 면적, 보증금처럼 이미 별도의 입력란이 있는 정보는 상세설명에서 반복하지 않았다. 핵심 조건만 남기니 사용자가 공고의 신청 가능 여부를 더 빠르게 판단할 수 있었다.
테스트 결과
기존 기능이 새 이미지 기능 때문에 고장 나지 않았는지도 자동화 테스트로 확인했다.
- 백엔드 테스트: 122개 통과
- 관리자 프론트엔드 테스트: 178개 통과
- 사용자 프론트엔드 테스트: 154개 통과
- 기존 청약 공고 112건 조회 확인
- 대표 이미지만 있는 기존 공고의 상세 이미지 표시 확인
실제 사진 등록은 데이터베이스와 Storage에 파일을 생성하는 작업이므로, 테스트용 공고를 직접 등록하면서 최종 화면을 확인하기로 했다.
오늘의 회고
오늘은 사진 여러 장을 등록하는 기능이 단순히 파일 선택 기능만 추가한다고 완성되는 것이 아니라는 점을 알게 됐다.
업로드 장수와 용량 제한, 대표 이미지 결정, 일부 업로드 실패 처리, 개별 삭제, 공고 수정 시 이미지 유지까지 여러 상황을 함께 고려해야 했다.
또한 실제 공고문을 서비스 데이터로 옮기는 과정에서는 문서의 내용을 그대로 복사하기보다 데이터베이스 구조에 맞게 분리하고 정리하는 작업이 중요했다. 특히 호실마다 임대조건이 다른 경우에는 각각 별도의 데이터로 등록해야 검색 결과도 정확해진다.
다음에는 테스트 공고를 직접 등록하여 관리자와 사용자 화면에서 전체 사진이 제대로 표시되는지 확인하고, 사진을 삭제하거나 공고명만 수정해도 나머지 이미지가 유지되는지 점검할 예정이다.
#AI오케스트레이션 #국비지원개발자과정 #미니프로젝트 #다중이미지업로드 #Streamlit #FastAPI #Supabase #청약정보서비스 #데이터전처리 #개발회고
'AI 오케스트레이션 캠프 > 일차별 회고' 카테고리의 다른 글
| 24일차 회고 | 공공임대 청약 통합 안내 서비스 최종 발표와 미니프로젝트 마무리 | AI 오케스트레이션 개발자 국비지원 (0) | 2026.08.12 |
|---|---|
| 23일차 회고|안전한 일괄 삭제·Gemini 문서 분석|AI 오케스트레이션 개발자 국비지원 (0) | 2026.08.11 |
| 21일차 회고|Redis·GitHub 협업과 청약 공고 검색|AI 오케스트레이션 개발자 국비지원 (1) | 2026.08.07 |
| 20일차 회고|Git push 오류 해결·공공주택 미니프로젝트 설계|AI 오케스트레이션 개발자 국비지원 (0) | 2026.08.06 |
| 19일차 회고|권한별 화면 구성·공공주택 MVP 기획|AI 오케스트레이션 개발자 국비지원 (0) | 2026.08.05 |
댓글