프론트엔드 개발자를 위한 백엔드, Supabase로 장바구니와 주문 로직 짜기

 

 

프론트엔드 개발자가 실제 서비스 구축 단계에서 가장 큰 벽을 느끼는 순간은 화면에 그려진 데이터를 서버에 영구적으로 저장하고 관리해야 할 때입니다. 특히 장바구니에 상품을 담거나 결제를 통해 재고를 차감하는 로직은 단순히 API를 호출하고 응답을 받아오는 것 이상의 복잡한 트랜잭션 개념을 요구합니다. 많은 프론트엔드 개발자가 백엔드 영역을 '요청을 보내면 알아서 처리되는 블랙박스'로 여기곤 하지만, 이 내부 구조를 이해하지 못하면 데이터 정합성이 깨지거나 보안 사고로 이어지는 취약한 애플리케이션을 만들게 됩니다. 이 글에서는 백엔드 경험이 부족한 분들을 위해, 데이터베이스가 어떻게 데이터를 보호하고 비즈니스 로직을 처리하는지 핵심 원리를 설명합니다.

프론트엔드 개발자를 위한 Supabase 백엔드 속성 과외

서버리스 환경이 보편화되면서 Supabase와 같은 도구를 활용하면 프론트엔드 개발자도 손쉽게 백엔드 인프라를 구축할 수 있게 되었습니다. 하지만 단순히 데이터를 JSON 형태로 저장하고 불러오는 것과 관계형 데이터베이스(RDBMS)를 제대로 설계하는 것은 완전히 다른 영역입니다. 백엔드 속성 과외의 첫 번째 핵심은 Supabase를 단순한 API 저장소가 아닌, 엄격한 규칙을 가진 데이터베이스로 바라보는 것입니다. 프론트엔드에서 컴포넌트 간의 데이터 흐름을 props로 관리하듯, 데이터베이스는 테이블 간의 외래 키(Foreign Key) 관계를 통해 데이터의 무결성을 보장합니다. 또한 클라이언트에서 요청하는 모든 데이터 접근은 RLS(Row Level Security)라는 정책을 통해 필터링됩니다. 즉, 화면에서 버튼을 감추는 것만으로는 보안이 완성되지 않으며, 데이터베이스 레벨에서 '누가 어떤 데이터를 볼 수 있는지'를 명시적으로 제어해야만 안전한 서비스가 가능해집니다. 만약 이러한 제약 조건 없이 개발한다면, 삭제된 상품의 리뷰가 덩그러니 남거나 개발자 도구 조작만으로 타인의 정보를 열람하는 치명적인 보안 구멍이 생길 수 있음을 명심해야 합니다.

장바구니 상태 관리를 데이터베이스 시각으로 전환합니다

프론트엔드 상태 관리 라이브러리인 Redux나 Zustand를 사용할 때는 장바구니를 단순히 상품 객체가 담긴 배열로 관리하는 경우가 많습니다. 하지만 데이터베이스 관점에서 장바구니를 설계할 때는 '중복 방지'와 '실시간 동기화'라는 두 가지 핵심 문제를 고려해야 합니다. 사용자가 이미 담은 상품을 다시 장바구니에 넣었을 때, 데이터베이스는 새로운 행을 추가하는 대신 기존 수량만 업데이트하는 'Upsert' 로직을 수행해야 합니다. 또한 브라우저 세션이 끊기거나 기기를 변경하더라도 장바구니 데이터가 유지되도록, 로컬 스토리지에 의존하는 방식에서 벗어나 사용자 ID와 상품 ID를 복합키로 설정하여 유니크한 관계를 맺어주는 것이 중요합니다. 단순히 배열에 push하는 방식과 달리, 데이터베이스의 유니크 제약 조건(Unique Constraint)을 활용하면 중복 데이터의 유입을 원천적으로 차단하고 데이터의 일관성을 시스템 레벨에서 보장할 수 있습니다. 이처럼 화면상의 상태(State)가 아니라 영구적인 데이터(Record)로서 장바구니를 바라보면, 사용자 경험의 끊김 없이 데이터를 보존하는 백엔드 설계를 이해할 수 있습니다.

안전한 주문 로직은 클라이언트가 아닌 서버가 통제합니다

쇼핑몰 프로젝트에서 가장 위험한 실수는 최종 결제 금액 계산이나 재고 차감 로직을 프론트엔드 자바스크립트 코드에서 처리하는 것입니다. 클라이언트 코드는 사용자가 얼마든지 조작할 수 있기 때문에, 상품 가격이나 할인율 계산은 반드시 서버 내부, 즉 데이터베이스의 트리거(Trigger)나 저장 프로시저(Stored Procedure)에서 수행되어야 합니다. 주문 버튼을 눌렀을 때 프론트엔드는 단순히 '주문 생성 요청'만 보낼 뿐, 실제 재고가 남아있는지 확인하고 재고를 차감한 뒤 주문서를 생성하는 일련의 과정은 하나의 트랜잭션(Transaction)으로 묶여야 합니다. 이 과정 중 하나라도 실패하면 모든 작업이 취소되는 원자성(Atomicity)을 보장해야 하는데, 이는 프론트엔드 코드로 구현하기 어려운 백엔드 고유의 영역입니다. 만약 이를 프론트엔드에서 순차적으로 처리한다면, 결제는 성공했으나 네트워크 오류로 재고가 차감되지 않는 데이터 불일치 사태가 발생할 수 있습니다. 따라서 주문 로직을 구현할 때는 클라이언트의 역할을 최소화하고, 모든 데이터 변경 과정을 데이터베이스 함수에게 위임하여 '모 아니면 도'의 안전한 처리를 보장해야 합니다.

프론트엔드 개발자가 위험한 로직을 구분하면 서비스가 성장합니다

백엔드 지식을 갖춘 프론트엔드 개발자가 된다는 것은 모든 API를 직접 만들 수 있어야 한다는 의미가 아닙니다. 중요한 것은 어떤 로직이 클라이언트에서 처리해도 안전한지, 그리고 어떤 로직이 반드시 서버의 통제하에 있어야 하는지를 구분하는 안목을 기르는 것입니다. 장바구니와 주문 로직을 통해 살펴본 것처럼, 데이터의 신뢰성과 보안은 화면을 예쁘게 만드는 것만큼이나 서비스의 품질을 결정짓는 중요한 요소입니다. 백엔드 개발자와 협업할 때 API의 응답 값만 요청하는 것이 아니라, 데이터가 처리되는 트랜잭션 시점과 예외 처리에 대해 구체적으로 논의할 수 있다면 여러분은 단순한 UI 구현가를 넘어 서비스 전체의 안정성을 설계하는 시니어 레벨의 개발자로 성장할 수 있습니다. 기획 단계에서부터 데이터 무결성 이슈를 예상하고 백엔드 팀에게 필요한 제약 조건을 먼저 제안하는 개발자야말로, 팀 내에서 대체 불가능한 가치를 지닌 동료로 인정받게 될 것입니다.