[Next.js & FireBase] 화면 설계, 문서 데이터베이스 설계

 

화면 설계

 

필요한 화면 정리 및 화면 전이도 만들기

 

- 화면 전이도란, 말 그대로, 어떤 화면에서 어떤 화면으로 전이(이동)이 가능한지를 정의하기 위해 만드는 그림이다.

- 한국에서는 '화면 흐름도', '플로 차트' 라는 말을 더 많이 쓰는 것 같다. (일본에서는 画面遷移図)

- 화면 전이도를 직접 그리려면, draw.io 와 같은 웹사이트나 프로그램을 사용해서 그릴 수 있지만, 나는 LLM에게 그냥 던져서 Mermaid 코드로 대충 작성해달라고 하고, 세부적으로는 직접 수정했다.

- Mermaid 코드는, Visual Studio Code를 사용하는 경우엔 Markdown Preview Mermaid Support 라는 확장 프로그램을 다운받아, .md 파일을 생성한 뒤 파일에 코드를 붙여넣은 뒤에 Ctrl+Shift+V를 누르면 바로 도식으로 확인할 수 있다.

- Mermaid 문법 자체는 되게 직관적이라 처음 봐도 바로 수정이 가능하다. (화살표 종류같은 옵션은 여러 가지 있으니, 필요할 경우엔 그 때 그 때 알아보면 될 것 같다.)

 

- 완성된 화면 전이도의 Mermaid 코드

```mermaid
graph LR
    %% 그룹 정의
    subgraph Common [메인]
        Main[메인화면]
    end

    subgraph Shopping [쇼핑 프로세스]
        ProductList[상품목록화면]
        ProductDetail[상품상세화면]
        Wishlist[찜목록화면]
        Cart[장바구니화면]
        Order[주문화면]
    end

    subgraph OrderInfo [주문 정보]
        OrderHistory[주문내역화면]
        OrderDetail[주문상세화면]
    end

    subgraph User [유저/계정]
        Login[로그인화면]
        SignUp[회원가입화면]
        Profile[회원정보화면]
    end

    subgraph MyPage [고객지원]
        Inquiry[문의화면]
        InquiryHistory[문의내역화면]
    end

    %% 연결 관계
    Common --> ProductList
    Common --> Login
    Common --> Profile
    Common --> Inquiry
    Login <--> SignUp
    
    ProductList --> ProductDetail
    ProductList --> Cart
    ProductDetail <--> Cart
    
    Cart <--> Order
    Order --> OrderHistory
    OrderHistory <--> OrderDetail
    Wishlist <--> Cart
    
    Profile --> Wishlist
    Profile --> InquiryHistory
    Profile --> OrderHistory
    Inquiry <--> InquiryHistory

    User --> Common
    Shopping --> Common
    MyPage --> Common
    OrderInfo --> Common

    %% --- 스타일 정의 ---
    %% 1. 메인 (진한 회색/검정)
    classDef clsMain fill:#212121,stroke:#fff,stroke-width:2px,color:#fff;
    %% 2. 유저 (푸른 계열)
    classDef clsUser fill:#1A237E,stroke:#fff,stroke-width:1px,color:#fff;
    %% 3. 쇼핑 (초록 계열)
    classDef clsShop fill:#1B5E20,stroke:#fff,stroke-width:1px,color:#fff;
    %% 4. 고객지원 (보라 계열)
    classDef clsSupport fill:#4A148C,stroke:#fff,stroke-width:1px,color:#fff;
    %% 5. 주문정보 (주황 계열)
    classDef clsOrderInfo fill:#4A548C,stroke:#fff,stroke-width:1px,color:#fff;

    %% --- 스타일 적용 ---
    class Main clsMain;
    class Login,SignUp,Profile clsUser;
    class ProductList,ProductDetail,Wishlist,Cart,Order clsShop;
    class Inquiry,InquiryHistory clsSupport;
    class OrderHistory,OrderDetail clsOrderInfo;

 

- 완성된 Mermaid 코드는, Mermaid Live Editor 에서 이미지 파일로 저장할 수 있다.

- 개발 과정에서 수정할 여지는 있다.

 

 

로고 디자인

- 로고 디자인은 Shopify 에게 맡겼다.

- 프롬프트 잘 쓰는 법을 다들 따로 배우는 이유를 새삼 실감할 수 있었다. 좀처럼 마음에 들게 만들어주지 않는다.

- 배경을 투명하게 하는데에는 QuillBot 을 사용했다.

- 로고 이미지는 투명화후에 약간 깨져서 직접 수정했고, 텍스트도 깨지길래 수정해서 붙여주었다.

 

화면별 UI 설계

- 구글 Stitch가 UI 디자인을 기깔나게 해준다는 것을 알았기 때문에, 앞에서 정리한 화면들을 구글 Stitch를 통해 디자인했다.

- 메인화면(좌) 와 장바구니 화면(우) 디자인.

- 어제 생성했던 화면들 이 충분히 만족스러웠기 때문에, 거의 그 디자인 그대로 해달라고 요청했다.

- 이런식으로, 문의하기 화면, 주문이력 화면, 로그인 화면 등도 부탁해서 만들었다.

- 세부적인 수정은 추가 프롬프트 입력으로 부탁하기보단 그냥 직접 하는게 나을 것 같아서 이정도로 해놓기로 했다.

 

 

 

 

문서 데이터베이스 설계

 

 

Firebase와 NoSQL

- 이 프로젝트의 백엔드는 Firebase로 만들기로 했는데, Firebase는 내가 그 동안 써온 관계형 데이터베이스가 아니라, NoSQL, 그 중에서도 문서형 데이터베이스를 사용한다.

- 그래서, 문서형 데이터베이스가 무엇인지, 그리고 어떻게 설계해야 하는지를 공부할 필요가 있었다.

- 그래서 공부했다.

 

 

DB 설계 - ER도

```mermaid 
erDiagram
    USERS ||--o{ FAVORITES : has
    USERS ||--o{ CART_ITEMS : has
    USERS ||--o{ ORDERS : places
    USERS ||--o{ INQUIRIES : writes

    PRODUCTS ||--o{ FAVORITES : "referenced in"
    PRODUCTS ||--o{ CART_ITEMS : "referenced in"
    PRODUCTS ||--o{ ORDER_ITEMS : "referenced in"

    ORDERS ||--o{ ORDER_ITEMS : contains

    USERS {
        string userId PK
        string email
        string nickname
        string address
        string phone
        datetime signInDate
        boolean isAdminister
    }

    FAVORITES {
        string productId PK
        datetime addedAt
        string productRef FK
    }

    CART_ITEMS {
        string productId PK
        datetime addedAt
        integer quantity
        string productRef FK
    }

    PRODUCTS {
        string productId PK
        string name
        number price
        integer stock
        string image
        string description
    }

    ORDERS {
        string orderId PK
        string userId FK
        string status
        datetime date
        string address
    }

    ORDER_ITEMS {
        string productId PK
        integer quantity
        string productRef FK
        string snapshotName
        number snapshotPrice
        string snapshotImage
    }

    INQUIRIES {
        string inquiryId PK
        string userId FK
        string content
        datetime date
        string status
    }

    %% style classes
    classDef parent fill:#000000,stroke:#000000,color:#ffffff,stroke-width:2px
    classDef child fill:#1e3a8a,stroke:#1e40af,color:#ffffff,stroke-width:2px

    %% apply to entities
    class USERS,PRODUCTS,ORDERS,INQUIRIES parent
    class FAVORITES,CART_ITEMS,ORDER_ITEMS child

- 일단 LLM에 컬렉션 구조를 작성해서 보내고, Mermaid 코드를 작성해달라고 했다.

 

- 이거로 그린 ER도는 다음과 같다.

- 검은색 컬렉션이 상위 컬렉션으로, 이 컬렉션들에 has 혹은 contains로 연결된 파란색 컬렉션이 그 서브 컬렉션이다.

- ORDERS(주문 내역)과 ORDER_ITEMS(주문 상품들) 컬렉션에 대해서 설명하자면, 어떤 유저가 주문 내역을 조회할 때, 주문 상태, 주문 날짜, 주문 주소를 먼저 조회하고, 특정 주문 정보를 눌러서 주문 상세 화면으로 넘어가면 주문한 물품들을 확인할 수 있다.

- 이 때, FireStore(Firebase의 DB)는 얕게 탐색을 하기 때문에, ORDERS를 불러들일 때 서브 컬렉션인 ORDER_ITEMS까지는 불러들이지 않는다.

- 또, snapshotName, snapshotPrice, snapshotImage엔 주문 당시의 상품의 이름, 가격, 이미지를 저장한다. PRODUCTS를 참조하게 되면, 예전의 주문 정보가 보존되지 않게 되어버리기 때문에, 이런 방식을 택하게 되었다.