20일차 회고｜Git push 오류 해결·공공주택 미니프로젝트 설계｜AI 오케스트레이션 개발자 국비지원

오늘은 1차 미니프로젝트의 기존 프로토타입을 점검하고, 앞으로 구현할 기능과 협업 방식을 구체화했다. 작업 중 발생한 GitHub push 오류도 직접 원인을 확인하며 해결했다.

GitHub push 오류 해결

로컬 프로젝트를 GitHub에 올리려 했지만 다음과 같은 오류가 발생했다.

Can't push refs to remote.
Try running "Pull" first to integrate your changes.

먼저 git status로 확인했을 때 작업 폴더는 깨끗한 상태였다. 하지만 push를 실행하자 origin이라는 원격 저장소를 찾을 수 없다는 메시지가 나왔다.

git remote -v

확인 결과 원격 저장소 이름이 일반적으로 사용하는 origin이 아니라 a로 등록되어 있었다. 다음 명령어로 이름을 변경했다.

git remote rename a origin

이후 다시 push했지만, 이번에는 원격 저장소의 커밋이 로컬보다 앞서 있어 push가 거절됐다.

Updates were rejected because the tip of your current branch is behind
its remote counterpart.

원격 변경 내용을 먼저 가져오면서 커밋 기록을 깔끔하게 유지하기 위해 rebase 방식을 사용했다.

git pull --rebase origin main
git push -u origin main

그 결과 원격 변경 내용과 로컬 작업이 정상적으로 정리됐고, GitHub push도 완료할 수 있었다.

이번 오류를 해결하며 작업 파일에 문제가 없어도 원격 저장소 이름이나 커밋 순서 때문에 push가 실패할 수 있다는 점을 배웠다. 오류가 발생하면 바로 여러 명령어를 입력하기보다 git status와 git remote -v부터 확인하는 것이 중요했다.

중간에 나타난 PowerShell의 가상환경 실행 정책 오류는 Git push 문제와는 별개의 문제라는 것도 구분할 수 있었다.

공공주택 청약 서비스 프로토타입 점검

팀에서는 현재 만들어진 서울 공공주택 청약 정보 서비스를 실행해 보며 구현된 기능을 확인했다.

현재 프로토타입에는 다음과 같은 기능이 들어가 있었다.

• Supabase 이메일 기반 회원가입과 로그인
• 사용자용 청약 공고 조회
• 관심 공고 즐겨찾기
• 관리자용 공고 등록·조회·삭제
• 즐겨찾기가 많은 공고 순위 조회
• 사용자별 즐겨찾기 내역 확인
• listings, favorites, profiles, admins 테이블 연동

JWT 인증은 아직 수업에서 배우지 않았기 때문에 이번 프로젝트에서는 Supabase가 제공하는 인증 기능을 활용하기로 했다.

기존 기능을 살리는 방향으로 개선하기

처음부터 새로운 서비스를 만드는 것보다 현재 프로토타입을 기반으로 작은 기능을 하나씩 추가하는 방향이 현실적이라고 판단했다.

논의한 개선 아이디어는 다음과 같다.

• 즐겨찾기 여부를 색상이나 메시지로 표시
• 공고 이미지와 원문 링크 제공
• 회원가입 시 관심 지역과 개인 조건 입력
• 자격 조건을 입력창 대신 체크박스나 선택 상자로 구성
• 마감된 공고 처리
• 즐겨찾기 순위와 사용자별 조회 기능 개선
• 사용자의 조건에 맞는 공고 추천
• 공고 댓글 기능 검토

아직 모두 구현한 것은 아니며, 각자 맡을 기능의 범위를 정하기 위한 아이디어로 정리했다.

일반 기능과 AI 기능 구분하기

오늘 가장 중요하게 고민한 부분은 어떤 기능에 AI가 필요한가였다.

일반적인 DB 기능AI를 활용하기 좋은 기능

선택한 지역의 공고만 조회	자연어로 조건을 입력해 공고 찾기
신혼부부 공고 필터링	복잡한 자격 조건을 쉬운 말로 설명
즐겨찾기 순위 계산	비슷한 지역이나 대안 공고 추천
마감일이 지난 공고 처리	사용자 상황에 맞춘 공고 상담
보증금과 월세 계산	이전 대화를 기억하는 연속 상담

회원가입 때 선택한 조건으로 공고를 필터링하는 것은 Supabase 쿼리만으로도 구현할 수 있다. 반면 “내 상황에 맞는 공고를 알려줘”처럼 자연어를 이해하고 이유까지 설명해야 한다면 Gemini와 같은 AI 모델이 더 적합하다.

다만 Gemini가 Supabase의 데이터를 자동으로 알고 있는 것은 아니다. 백엔드에서 관련 공고를 조회한 뒤 그 데이터를 프롬프트에 넣어 전달하거나, 이후 벡터 DB를 이용한 검색 구조를 만들어야 한다.

따라서 첫 번째 목표는 기본 챗봇을 완성하는 것으로 정하고, 시간이 남으면 다음 기능을 추가하기로 했다.

• 최근 대화 내용 기억
• Redis를 이용한 대화 또는 캐시 관리
• 사용자 정보 기반 맞춤 추천
• 벡터 DB를 활용한 공고 검색

한 기능의 전체 흐름 이해하기

작은 기능 하나를 수정하더라도 화면만 바꾸면 끝나는 것이 아니었다.

Supabase 테이블
→ FastAPI 스키마·서비스·라우터
→ API 클라이언트
→ 관리자·사용자 Streamlit 화면

예를 들어 자격 조건을 체크박스로 변경하면 DB 컬럼, 백엔드 API, 관리자 등록 화면, 사용자 조회 화면을 모두 함께 확인해야 한다.

그래서 프론트엔드와 백엔드를 완전히 나누기보다, 각자 하나의 기능을 맡아 DB부터 UI까지 전체 흐름을 구현하는 방식이 이번 프로젝트에 더 적합하다고 정리했다.

Streamlit 화면이 느린 이유 살펴보기

프로토타입을 사용하면서 버튼이나 체크박스를 누를 때 화면 전환이 느린 부분도 확인했다.

가능한 원인으로는 다음과 같은 항목을 살펴봤다.

• Streamlit의 화면 재실행 방식
• 반복되는 백엔드 API 요청
• Supabase 조회 시간
• 같은 데이터를 계속 다시 불러오는 구조

Redis 캐시를 사용하면 반복 조회를 줄일 수 있지만, 현재는 데이터와 사용자가 많지 않다. 따라서 무조건 Redis를 추가하기보다 어느 구간이 실제로 느린지 먼저 확인하는 것이 우선이라고 생각했다.

데이터가 많아졌을 때는 DB 인덱스를 이용해 모든 데이터를 처음부터 확인하지 않고 필요한 위치를 빠르게 찾을 수 있다는 점도 함께 복습했다.

안전한 협업을 위한 규칙

Supabase 테이블을 여러 명이 함께 수정하면 실수로 컬럼이나 테이블을 삭제할 위험이 있다. 실제 공고 데이터를 많이 입력한 뒤 테이블이 삭제되면 복구하기 어려우므로 다음과 같은 규칙이 필요했다.

• 테이블이나 컬럼을 삭제하기 전에 팀원에게 알리기
• 가능하면 삭제보다 추가와 수정을 우선하기
• 테이블 생성 SQL과 샘플 데이터를 백업하기
• 개인 브랜치에서 작업하기
• 작은 기능 단위로 자주 병합하기
• 수정한 기능과 이유를 기록하기

오늘의 회고

오늘은 단순히 기능 아이디어를 많이 내는 것보다 정해진 시간 안에 완성할 수 있는 최소 기능을 먼저 만드는 것이 중요하다는 점을 느꼈다.

또한 추천이라는 이름이 붙었다고 모두 AI 기능은 아니었다. 조건이 명확하면 DB 필터링으로 해결할 수 있고, 자연어 이해와 설명이 필요할 때 AI를 사용하는 것이 적절했다.

우선 월요일까지 각자 맡은 핵심 기능을 완성하고, 화요일에는 기능 통합과 문서·발표 준비를 진행할 예정이다. 앞으로는 새로운 기술을 무작정 추가하기보다 현재 서비스에 꼭 필요한지 먼저 판단하며 프로젝트를 진행해야겠다.