19일차 회고｜권한별 화면 구성·공공주택 MVP 기획｜AI 오케스트레이션 개발자 국비지원

 

오늘은 기존에 만든 회원가입·로그인·상품 관리 기능을 바탕으로 일반 사용자와 관리자의 화면을 구분했다. 이후 팀원들과 미니 프로젝트 주제를 논의하며, 짧은 개발 기간 안에 완성할 수 있는 MVP 범위를 정했다.

사용자와 관리자 화면 구분

하나의 데이터베이스를 사용하더라도 로그인한 사용자의 역할에 따라 보여주는 화면과 사용할 수 있는 기능이 달라야 한다.

일반 사용자는 상품 정보를 조회할 수 있지만 등록·수정·삭제 기능은 사용할 수 없도록 구성했다. 반면 관리자는 상품을 조회하는 것뿐만 아니라 새로운 상품을 등록하고 기존 정보를 관리할 수 있다.

전체 흐름은 다음과 같다.

• 회원가입 후 로그인
• 로그인한 사용자 정보 확인
• 일반 사용자와 관리자 화면 구분
• 일반 사용자는 상품 조회
• 관리자는 상품 등록·조회·수정·삭제
• 로그아웃하면 로그인 상태 해제

같은 데이터를 사용하더라도 사용자용 페이지와 관리자용 페이지가 서로 다른 역할을 한다는 점을 이해할 수 있었다.

코드를 교체하는 과정에서 이전에 만들었던 사용자 화면이 보이지 않는 문제도 있었다. 강사님 코드를 적용하면서 기존 파일이 바뀐 것으로 예상되어, 현재 실행 중인 프런트엔드와 파일 구성을 다시 확인했다. 여러 앱을 함께 실행할 때는 어떤 파일과 실행 경로를 사용하고 있는지 정확하게 구분해야 한다는 점을 배웠다.

미니 프로젝트 주제 검토

수업 후반에는 팀원들과 미니 프로젝트 주제를 논의했다. 여행 지원금 안내, AI 냉장고, 공공주택 공고 서비스 등 여러 아이디어를 검토한 결과, 서울의 청년·공공주택 공고를 한곳에서 확인할 수 있는 서비스를 유력한 주제로 정했다.

서비스의 핵심 기능은 다음과 같이 정리했다.

• 회원가입과 로그인
• 주택 공고 목록 조회
• 공고의 제목·지역·설명·원문 링크 제공
• 관심 있는 공고 찜하기
• 마이페이지에서 찜한 공고 조회 및 삭제
• 관리자 페이지에서 공고 관리
• 공고별 찜 수와 인기 공고 차트 표시

기존에 실습한 Streamlit·FastAPI·Supabase 구조를 뼈대로 활용하고, 상품 데이터를 주택 공고 데이터로 변경하면 기본 프로토타입을 빠르게 만들 수 있을 것으로 판단했다.

공공데이터 사용이 어려운 이유

공공주택 공고는 PDF나 표 형태로 제공되는 경우가 많고, 신청 자격도 1인 가구·신혼부부·고령자·수급자 등으로 복잡하게 나뉜다. 따라서 실제 공고 전체를 가져와 서비스에 맞는 데이터로 가공하려면 예상보다 많은 시간이 필요하다.

이번 프로젝트에서는 처음부터 모든 공고를 처리하지 않고 약 10개의 공고만 준비하기로 했다. 데이터 항목도 제목·지역·간단한 설명·원문 링크처럼 꼭 필요한 정보부터 사용한다. 실제 데이터를 정리하기 어렵다면 먼저 목업 데이터를 넣어 기능을 완성한 후 교체하는 방법도 검토했다.

이를 통해 서비스 개발에서는 기능 구현뿐만 아니라 데이터를 수집하고 정리하는 과정도 큰 작업이라는 점을 알게 되었다.

RAG와 벡터 DB 검토

팀 논의 중에는 AI가 공공주택 자료를 참고해 답변하는 RAG 기능도 검토했다.

RAG는 크게 세 단계로 이해할 수 있다.

1. Retrieve: 데이터베이스나 문서에서 질문과 관련된 정보를 찾는다.
2. Augment: 찾은 정보를 AI에게 보낼 질문에 추가한다.
3. Generate: AI가 제공받은 정보를 바탕으로 답변을 만든다.

일반 데이터베이스가 ID나 조건을 기준으로 데이터를 찾는다면, 벡터 DB는 문장의 의미를 숫자로 변환해 비슷한 의미의 자료를 찾는다. 예를 들어 “청년주택에 입주하고 싶다”라는 질문과 의미상 가까운 공고를 검색하는 방식이다.

다만 RAG를 제대로 구현하려면 문서 전처리, 임베딩, 벡터 DB, 검색 결과 연결 과정이 추가로 필요하다. 현재 프로젝트 기간을 고려하면 구현 난도가 높기 때문에, 우선은 Supabase에 저장된 공고를 조건에 따라 조회하는 기능부터 완성하기로 했다. AI 기능을 억지로 추가하기보다 실제로 작동하는 핵심 기능을 먼저 만드는 것이 중요하다고 판단했다.

Redis 역시 임시 데이터 저장, 캐시, 실시간 찜 수 관리 등에 사용할 수 있지만 프로젝트에 꼭 필요한지 확인한 뒤 적용하기로 했다.

애자일 방식으로 MVP 만들기

오늘 팀 논의에서 가장 중요했던 부분은 완벽한 계획을 세운 뒤 개발을 시작하는 것이 아니라, 작은 프로토타입을 먼저 만들어 가능성을 확인하는 것이었다.

우선 기존 프로젝트에서 불필요한 날씨 조회와 서버 확인 기능 등을 제거하고 다음 기능만 남기기로 했다.

• 로그인
• 공고 조회
• 찜하기
• 찜한 공고 모아보기
• 관리자용 공고 관리

이 기능들이 연결되는지 먼저 확인한 다음 시간이 남으면 검색 조건, 차트, 인기 공고 등의 기능을 추가한다. 다음 날 점심까지 1차 프로토타입을 만들어 팀원들과 확인하기로 했다.

오늘의 회고

오늘은 단순히 화면을 만드는 것에서 벗어나 사용자의 역할에 따라 기능을 구분하는 방법을 생각해 볼 수 있었다. 또한 좋은 아이디어라도 데이터 확보와 개발 기간을 고려하지 않으면 완성하기 어렵다는 점을 배웠다.

특히 RAG나 벡터 DB처럼 새로운 기술을 넣는 것보다 회원가입, 로그인, 조회, 찜하기처럼 서비스의 핵심 흐름을 먼저 완성하는 것이 중요하다는 점이 기억에 남았다.

다음에는 사용자와 공고 사이의 찜 데이터를 어떤 테이블 구조로 연결할지 정리하고, 기존 상품 관리 코드를 공공주택 공고 서비스에 맞게 변경해 봐야겠다.