21일차 회고｜Redis·GitHub 협업과 청약 공고 검색｜AI 오케스트레이션 개발자 국비지원

 

오늘은 Redis의 역할과 연결 방법을 학습하고, GitHub 협업 환경을 정리했다. 이후 팀 미니프로젝트에서는 서울 25개 자치구를 이용한 청약 공고 검색 기능을 구현하고 관리자 화면부터 API와 DB까지 통합 테스트했다.

Redis의 역할과 연결 점검

Redis는 데이터를 메모리에서 빠르게 읽고 쓸 수 있는 저장소다. 모든 데이터를 영구적으로 보관하기보다는 로그인 세션, 캐시, 현재 진행 중인 채팅처럼 빠른 처리가 필요한 정보를 관리할 때 활용할 수 있다.

Redis 연결이 제대로 되지 않을 때는 다음 항목을 점검했다.

• .env의 REDIS_URL이 올바르게 작성됐는지 확인
• 환경 변수 이름이나 주소가 중복되지 않았는지 확인
• 가상환경이 활성화됐는지 확인
• Redis 연결에 필요한 패키지가 설치됐는지 확인
• .env를 수정한 후 실행 중인 서버 재시작

팀 프로젝트에 Redis를 활용할 방법도 생각해봤다. 사용자가 챗봇과 대화하는 동안에는 Redis에 현재 대화를 임시로 저장하고, 대화가 끝나면 필요한 내용을 요약해 기존 DB에 저장하는 방식이다.

다만 이는 오늘 실제로 구현한 기능이 아니라 프로젝트에 적용할 수 있는 구조를 검토한 단계다.

GitHub 팀 협업 환경 정리

엔코아 조직 계정의 팀 프로젝트 저장소와 멤버 초대 상태를 확인하고 협업 방법을 정리했다.

코드를 바로 develop 브랜치에 올리는 것이 아니라, 각자 작업한 브랜치에서 develop 브랜치로 Pull Request를 보내기로 했다. 이후 작성자를 제외한 팀원 한 명 이상이 코드를 확인하고 승인해야 병합할 수 있다.

이 과정을 통해 Pull Request는 단순히 코드를 합치는 기능이 아니라, 팀원이 변경 내용을 확인하고 오류를 줄이는 검토 과정이라는 점을 다시 이해했다.

청약 공고 서비스의 방향 정리

우리 서비스는 사이트 안에서 청약 신청을 받는 서비스가 아니다.

사용자가 SH 청약 공고를 자치구, 보증금, 월세 등의 조건으로 편하게 검색하고, 관심 있는 공고의 원문 URL을 통해 실제 신청 사이트로 이동할 수 있도록 돕는 서비스다. 따라서 사이트 내부의 청약 신청과 신청 취소 기능은 개발 범위에 포함하지 않는다.

자치구 기반 공고 검색 기능 개선

기존 검색 기능에서는 다음 조건을 사용할 수 있도록 백엔드 로직을 확인했다.

• 지역 검색
• 최대 보증금 검색
• 최대 월세 검색
• 여러 조건을 함께 사용하는 복합 검색

이 과정에서 사용자가 지역을 직접 입력하면 같은 장소도 서울, 서울특별시 관악구, 관악구처럼 서로 다르게 저장될 수 있다는 문제를 발견했다.

이를 해결하기 위해 관리자와 사용자 화면에 서울 25개 자치구 선택 기능을 적용했다. 자치구 목록은 여러 화면에 반복해서 작성하지 않고 다음 상수 파일로 분리했다.

• FE_Admin/core/constants.py
• FE_User/core/constants.py

관리자 등록 화면은 처음 열었을 때 자치구를 선택해 주세요가 표시되며, 반드시 자치구를 하나 선택해야 공고를 등록할 수 있도록 만들었다.

관리자와 사용자 조회 화면에는 다음 기능을 적용했다.

• 기본 검색값은 전체
• 특정 자치구를 선택하면 해당 지역 공고만 조회
• 자치구·최대 보증금·최대 월세 조건을 함께 적용
• 공고 카드의 지역 표현을 자치구로 통일

백엔드의 DB 컬럼과 API 파라미터는 기존 location을 그대로 사용했다. 기존 백엔드가 부분 일치 검색을 지원하고 있어 새로운 컬럼을 만들거나 DB 구조를 변경할 필요는 없었다.

이번 기능과 관계없는 즐겨찾기와 공고 삭제 코드는 수정하지 않았다.

방과 후 통합 테스트

방과 후에는 Claude Code의 브라우저 기능을 이용해 실제 Streamlit 화면을 테스트했다. 관리자 로그인은 직접 진행하고, 이후 테스트 공고 등록과 검색 검증은 Claude Code를 활용했다.

테스트를 위해 다음 공고 두 건을 등록했다.

1. [TEST] 관악구 매물
   • 자치구: 관악구
   • 보증금: 20,000,000원
   • 월세: 300,000원
2. [TEST] 성북구 매물
   • 자치구: 성북구
   • 보증금: 40,000,000원
   • 월세: 500,000원

관리자 조회 화면에서는 전체·관악구·성북구·강남구 검색을 확인했다. 강남구를 선택했을 때 두 테스트 공고가 표시되지 않는 것도 정상적으로 확인했다.

보증금과 월세의 경계값도 테스트했다.

• 관악구 + 최대 보증금 20,000,000원: 표시
• 관악구 + 최대 보증금 19,999,999원: 미표시
• 성북구 + 최대 월세 500,000원: 표시
• 성북구 + 최대 월세 499,999원: 미표시

사용자 화면에서도 자치구 검색이 예상대로 작동했으며, 공고 제목·주택명·자치구·면적·모집 인원·보증금·월세·신청 기간·상세 설명·원문 URL이 정상적으로 표시됐다.

마지막으로 GET 요청을 이용해 DB와 검색 API까지 확인했다.

• 관악구와 성북구 테스트 공고가 각각 1건씩 존재
• location에 자치구가 올바르게 저장
• 자치구 검색 API가 정상적으로 결과 반환
• 등록 후 입력 폼과 자치구 선택값 초기화

모든 테스트를 통과해 추가 코드 수정은 하지 않았다.

테스트 중 확인한 주의 사항

기존 공고 중에는 location이 서울로 저장된 데이터가 있었다. 이 데이터가 관악구나 성북구 검색 결과에 나오지 않는 것은 검색 오류가 아니라 기존 데이터와 새 데이터의 저장 형식이 다르기 때문이다.

면적이 화면에서 25.0㎡처럼 소수점 한 자리로 표시됐지만 실제 저장값에는 문제가 없었다. 단순한 화면 표시 문제이므로 이번 작업에서는 수정하지 않았다.

관리자 로그인은 Streamlit의 session_state를 이용하고 있어 브라우저를 새로고침하면 로그인이 해제될 수 있다는 점도 확인했다.

오늘의 회고

오늘은 검색 코드를 만드는 것만큼 DB에 저장되는 데이터의 형식을 통일하는 것이 중요하다는 점을 배웠다. 사용자가 값을 자유롭게 입력하게 하는 것보다 고정된 선택지를 제공하면 데이터가 일정해지고 검색 결과도 더 정확해진다.

기능 구현 후에는 한 화면만 확인하는 것이 아니라 관리자 등록, 관리자 조회, 사용자 조회, API 응답, DB 저장 결과를 하나의 흐름으로 테스트해야 실제 서비스가 제대로 연결됐는지 판단할 수 있었다.

AI 코딩 도구를 사용할 때도 작업을 지나치게 잘게 나누기보다 관련 코드 확인부터 구현, 실행, 오류 수정, 핵심 테스트까지 하나의 기능 단위로 요청하는 편이 효율적이라는 점을 경험했다.

다음 작업에서는 즐겨찾기와 마이페이지, 즐겨찾기가 많은 공고 순 정렬, 원문 URL 이동, 전체 통합 테스트, README와 실행 방법, 배포 환경을 차례대로 점검할 예정이다.