17일차 회고｜회원 인증·ERD와 Supabase 협업｜AI 오케스트레이션 개발자 국비지원

로그인 기능에서 팀 프로젝트 설계까지

오늘은 기존에 만들었던 FastAPI·Streamlit·Supabase 기반 CRUD 기능을 확장하고, 새로운 쇼핑몰 팀 프로젝트를 준비했다.

앞부분에서는 회원 인증과 회원 정보 수정, 비밀번호 변경, 로그인 상태에 따른 화면 구성을 점검했다. 이후에는 팀원들과 쇼핑몰 프로젝트의 주제와 기능을 정하고, ERD와 데이터베이스 테이블, 역할 분담, GitHub 협업 방식 등을 설계했다.

오늘은 코드를 많이 작성하는 것보다 팀원 모두가 같은 구조와 기준으로 개발할 수 있도록 프로젝트의 기반을 만드는 데 집중한 하루였다.

회원 인증과 로그인 상태 관리

먼저 회원가입·로그인·로그아웃과 같은 회원 인증 기능을 다시 점검했다.

Streamlit 화면에서는 로그인 여부에 따라 사용자에게 보여주는 메뉴가 달라져야 한다. 로그인하지 않은 상태에서는 회원가입과 로그인 메뉴가 필요하고, 로그인한 이후에는 회원 정보 수정이나 로그아웃과 같은 기능을 이용할 수 있어야 한다.

또한 회원 정보와 비밀번호를 수정하는 기능을 통해 프론트엔드에서 입력한 데이터가 FastAPI를 거쳐 Supabase까지 전달되는 흐름을 확인했다.

Streamlit 입력
→ API Client 요청
→ FastAPI 처리
→ Supabase 데이터 수정
→ 결과를 Streamlit 화면에 표시

기능 하나만 보면 단순해 보이지만, 로그인 상태와 입력값 검증, API 응답, 오류 메시지까지 함께 생각해야 자연스러운 화면을 만들 수 있다는 점을 배웠다.

상품 관리 화면 정리

기존에 만들었던 상품 CRUD 기능도 다시 정리했다.

상품 관리 화면에서는 다음 기능이 하나의 흐름으로 작동하도록 구성했다.

• 상품 등록
• 상품 전체 조회
• 상품 한 개 조회
• 상품 정보 수정
• 상품 삭제

상품 관리 기능은 이번 쇼핑몰 프로젝트에서도 참고할 수 있는 기본 예제가 됐다. 지금까지 만든 회원 인증·정보 수정 백엔드와 상품 관리 프론트엔드 코드는 Git에 커밋해 새로운 팀 프로젝트의 기반으로 활용하기로 했다.

쇼핑몰 팀 프로젝트 주제 선정

팀 프로젝트의 주제는 기존에 구현한 회원과 상품 기능을 이어서 활용할 수 있는 쇼핑몰로 정했다.

각자 완전히 다른 주제의 테이블을 만들 수도 있었지만, 자동차·음악·책처럼 서로 관련 없는 기능이 섞이면 하나의 프로젝트로 보이기 어렵다. 따라서 처음에는 각 기능을 개별적으로 구현하더라도 나중에 연결할 수 있도록 하나의 쇼핑몰이라는 주제 안에서 기능을 나누기로 했다.

기존의 회원과 상품 기능에 다음 기능을 추가하기로 했다.

• 카테고리
• 상품 리뷰
• 상품 문의
• 장바구니
• 주문

나는 이 가운데 카테고리 CRUD와 PLAN.md, 디렉터리 규칙 정리를 담당하기로 했다.

기능별 난이도가 다른 이유

기능의 난이도는 CRUD 개수보다 다른 테이블과 얼마나 많이 연결되는지, 추가로 처리해야 하는 규칙이 얼마나 많은지에 따라 달라졌다.

기능난이도주요 이유

카테고리	쉬움	이름을 중심으로 비교적 독립적인 CRUD 구현 가능
상품 리뷰	보통	회원과 상품을 연결하고 작성자를 확인해야 함
상품 문의	보통	회원·상품 연결과 문의 상태·답변 처리가 필요함
장바구니	어려움	회원별 조회, 상품 수량, 중복 상품 처리 등이 필요함
주문	어려움	주문과 주문 상품을 분리하고 여러 테이블을 연결해야 함

특히 주문은 하나의 테이블만으로 표현하기 어려워 orders와 order_items처럼 주문 정보와 주문 상품 정보를 나누는 구조를 검토했다.

장바구니도 단순히 데이터를 등록하는 것에서 끝나지 않는다. 같은 상품을 다시 담았을 때 수량을 늘릴지, 새로운 데이터를 만들지 정해야 하고, 로그인한 회원이 자신의 장바구니만 조회할 수 있도록 구성해야 한다.

이번 프로젝트에서는 제한된 시간 안에 완성하는 것이 중요하기 때문에 실제 쇼핑몰의 모든 규칙을 구현하기보다, 우선 각 기능의 기본 CRUD를 완성한 뒤 시간이 남으면 관리자 기능과 테이블 간 연결을 확장하기로 했다.

ERD를 이용한 데이터베이스 설계

팀원들이 각자의 Supabase에 테이블을 따로 만드는 것이 아니라, 하나의 팀 프로젝트와 데이터베이스를 함께 사용하기로 했다.

ERD는 데이터베이스의 테이블과 관계를 그림으로 나타낸 것이다. 어떤 테이블이 어떤 정보를 가지고 있고, 서로 어떤 키로 연결되는지 한눈에 확인할 수 있다.

예를 들어 상품 리뷰는 회원과 상품을 연결해야 한다.

users
  └── product_reviews ── products

이때 다른 테이블의 데이터를 가리키는 값을 외래 키(Foreign Key)라고 한다. 테이블끼리 외래 키로 연결하면 존재하지 않는 회원이나 상품에 리뷰가 작성되는 문제를 줄일 수 있다.

팀에서는 ERDCloud를 이용해 테이블 구조를 만들고, 생성된 SQL을 Supabase에 적용하는 방향으로 진행했다. 모든 테이블에는 기본적으로 다음 시간 정보를 포함하기로 했다.

created_at: 데이터가 처음 등록된 시간
updated_at: 데이터가 마지막으로 수정된 시간

이를 통해 데이터가 언제 생성됐고 마지막으로 언제 변경됐는지 확인할 수 있다.

PLAN.md와 공통 개발 규칙

개발을 시작하기 전에 PLAN.md에 프로젝트의 전체 계획을 정리하기로 했다.

계획서에는 다음 내용을 포함했다.

• 프로젝트 주제와 목표
• 핵심 기능
• 테이블과 컬럼
• 데이터 자료형
• 테이블 간 관계
• CRUD 기능
• 디렉터리와 파일 구조
• 팀원별 담당 업무
• GitHub 브랜치와 코드 통합 방법

각자 코드를 먼저 작성한 뒤 구조를 맞추면 파일 위치나 함수 이름이 달라져 통합 과정에서 문제가 생길 수 있다. 반대로 공통 구조를 먼저 정하면 담당 기능은 달라도 비슷한 방식으로 코드를 작성할 수 있다.

기능 개발 외에도 GitHub 저장소 초기 설정, 코드 통합과 충돌 해결, ERD 및 테이블 생성, 문서 정리, 발표처럼 공통으로 필요한 업무를 나눴다. 난이도가 높은 주문 기능을 맡은 사람이 공통 작업까지 모두 담당하지 않도록 업무량도 함께 조정했다.

협업 도구의 초대와 권한 문제

Supabase·ERDCloud·Notion·GitHub를 함께 사용하면서 계정과 접근 권한 문제도 발생했다.

팀원이 초대받은 이메일과 실제 서비스에 가입한 이메일이 다르면 초대된 프로젝트가 보이지 않거나 사용 권한이 없다는 메시지가 나타날 수 있었다. 네이버와 구글 계정을 혼용하면서 어떤 계정으로 가입했는지 혼란이 생기기도 했다.

이를 해결하기 위해 다음 사항을 하나씩 확인했다.

• 서비스에 가입한 이메일과 초대 이메일이 같은지 확인
• 초대 메일을 수락했는지 확인
• 팀 프로젝트 접근 권한 확인
• 기존 조직과 불필요한 프로젝트 정리
• 팀원 모두에게 동일한 프로젝트가 보이는지 확인

공유 데이터베이스의 접속 정보는 팀원 모두에게 필요하지만, Supabase 키가 들어 있는 .env 파일은 GitHub에 올리지 않고 각자의 개발 환경에 따로 설정해야 한다는 점도 중요하다.

오늘의 실습 결과

오늘 팀 프로젝트에서는 기능 코드를 바로 작성하기보다 다음 준비 작업을 우선 진행했다.

• 쇼핑몰 프로젝트 주제 확정
• 추가 CRUD 기능 선정
• 팀원별 담당 기능 배정
• 공통 작업 역할 분담
• ERD 작성
• 테이블 생성 SQL 준비
• Supabase 팀 프로젝트 공유
• GitHub 저장소와 협업 방식 정리
• PLAN.md 및 디렉터리 규칙 작성

기존 회원과 상품 기능은 기본 코드로 활용하고, 새롭게 맡은 기능의 코드는 다음 작업부터 본격적으로 구현하기로 했다.

오늘의 회고

개인 실습에서는 CRUD 기능이 각각 독립적으로 보였지만, 쇼핑몰이라는 하나의 프로젝트로 묶어 보니 테이블의 관계와 업무 규칙이 훨씬 중요하게 느껴졌다.

카테고리는 비교적 독립적이지만 리뷰는 회원과 상품이 필요하고, 장바구니와 주문은 여러 데이터와 처리 과정이 함께 움직여야 한다. 같은 CRUD라도 어떤 데이터와 연결되느냐에 따라 난이도가 크게 달라진다는 것을 이해할 수 있었다.

또한 팀 프로젝트에서는 코드를 빨리 작성하는 것만큼 공통 구조를 정하는 과정이 중요했다. 데이터베이스와 디렉터리 구조, 파일 이름, 역할 분담이 명확하지 않으면 각자 만든 코드를 합칠 때 더 큰 문제가 생길 수 있기 때문이다.

다음에는 내가 담당한 카테고리 CRUD를 공통 디렉터리 규칙에 맞춰 구현하고, FastAPI·Supabase·Streamlit이 정상적으로 연결되는지 테스트해야겠다. 이후에는 상품과 카테고리의 관계까지 확장해 쇼핑몰의 전체 구조 안에서 동작하도록 만들어보고 싶다.