인프런 영문 브랜드 로고
인프런 영문 브랜드 로고

인프런 커뮤니티 질문&답변

박상원님의 프로필 이미지

작성한 질문수

비전공자도 이해할 수 있는 DB 설계 입문/실전

[실습] 요구사항을 보고 DB 설계해보기 - JSCODE 커뮤니티 (1)

그냥 하나씩 만들어나가면서 DB 설계를 그때그때 하는건 틀린건가요?

작성

·

47

0

지금 제가 개인적으로 혼자 만들고 있는 프로젝트가 있습니다.

그냥 아이디어만 갖고 시작한건데요.

 

아래와 같은 순서로 만들고 있습니다.

 

(1) GPT한테 내가 원하는 기능을 설명한다.

(2) GPT한테 View 먼저 그려달라고 한다.

(3) View는 데이터 바인딩 안하고 그냥 하드코딩한다.

(4) View 보고 GPT랑 토의하면서 기능을 기획한다.

(5) 완성된 View를 보고 DB 모델링 한다. (보통 엔티티 하나나 두개정도가 됩니다)

(6) 백엔드를 붙인다.

 

이렇게 해서 하나씩 만들어나가고 있는데요. 이거 잘못된 방법이에요? 그냥 그때그때 DB 모델링에 필요한 컬럼이 생긴다고 하면 넣어주고 빼고 하면서 만들고있거든요.

답변 2

0

JSCODE 박재성님의 프로필 이미지
JSCODE 박재성
지식공유자

안녕하세요 상원님! 좋은 아이디어로 만들고 연습하고 계시네요:)

말씀해주신 방법을 봤을 때는 크게 잘못된 부분은 없어보입니다!

생각하신 순서대로 계속 만들어나가셔도 좋을 것 같습니다~!!

 

박상원님의 프로필 이미지
박상원
질문자

아 죄송합니다. 제가 글을 명확하게 못 쓴것 같습니다.

 

(1) GPT한테 내가 원하는 기능을 설명한다.

(2) GPT한테 View 먼저 그려달라고 한다.

(3) View는 데이터 바인딩 안하고 그냥 하드코딩한다.

(4) View 보고 GPT랑 토의하면서 기능을 기획한다.

(5) 완성된 View를 보고 DB 모델링 한다. (보통 엔티티 하나나 두개정도가 됩니다)

(6) View에 맞는 API를 만든다.

(7) View 하나를 완성한다.

(8) 1번으로 돌아간다.

 

이렇게 대략 20페이지 가량 만들어야 합니다.

총 엔티티도 10개 안쪽으로 될 거 같은데요.

 

이렇게 그냥 그때그때 View 하나에 필요한 엔티티를 하나씩 하나씩 모델링하고 넣어도 되는지 여쭤보고 싶습니다.

 

왜그러냐면, 이렇게 하면 나중에 DB설계가 꼬여서 문제가 생기는걸까 불안해서 그래요. 처음부터 기획을 완성하고 만들면 좋겠지만, 안타깝게도 저도 제가 만들어나가다보면 기획이 계속 수정이 되서요. 그리고 또 실제로 화면으로 만들어봐야만 아이디어가 생각이 나서요..

 

JSCODE 박재성님의 프로필 이미지
JSCODE 박재성
지식공유자

다시 한 번 자세히 설명해주셔서 감사해요:)

말씀해주신 대로 그때그때 필요한 엔티티를

하나씩 하나씩 모델링하면서 구성해나가셔도 괜찮습니다.

 

제가 알려드린 DB 설계 원칙을 어기지 않는 선에서 설계만 하신다면

DB 설계가 크게 꼬일일은 없습니다.

설령 DB 설계가 도중에 꼬인다고 하더라도 조금씩 수정해나가시면 됩니다.

저도 전체 View를 보고 DB를 설계하지 않고

View를 하나씩 봐가면서 DB를 설계해나갑니다.

그러다보면 실수로 DB 설계에서 놓치는 부분이 생기기도 하고

기획이 수정되어서 DB 설계를 일부 갈아엎기도 합니다.

하지만 이렇게 DB 설계를 수정하고 갈아엎는 과정이

잘못된 과정이 아니라 필수로 수반되는 과정입니다.

따라서 DB를 설계해나가시면서 수정 및 보완하는 식으로 진행하셔도 괜찮을 것 같습니다:D

박상원님의 프로필 이미지
박상원
질문자

답변 감사합니다~!!

0

인프런 AI 인턴님의 프로필 이미지

안녕하세요, 인프런 AI 인턴입니다. 박상원님께서 질문하신 ‘DB 설계를 그때그때 하는 방식’에 대해 말씀드리겠습니다.

설계 방식에 대한 고찰

DB 설계를 진행하면서 실시간으로 변경하는 방식은 초기 단계에서는 빠른 프로토타이핑이나 아이디어 구현에 도움이 될 수 있습니다. 특히, 개인 프로젝트에서 빠르게 진행하면서 여러 가지 아이디어를 테스트해보고 싶을 때 유용한 접근법일 수 있습니다. 그러나 몇 가지 고려할 점이 있습니다:

  1. 유연성의 장점과 단점: 초기에는 유연성이 큰 장점으로 작용할 수 있지만, 프로젝트가 커질수록 구조의 복잡성이 증가할 수 있습니다. 데이터 무결성을 유지하기 어렵고, 설계 변경에 대한 추적이 힘들어질 수 있습니다.

  2. 변경 비용: 실시간으로 구조를 변경하다 보면, 나중에 대규모 변경이 필요한 경우 작업이 복잡해지고, 다른 코드와의 의존성 문제로 인해 변경 비용이 커질 수 있습니다. 이런 문제는 특히 백엔드가 붙어 있는 상태에서는 더욱 까다로울 수 있습니다.

  3. 단계적 발전: 하드코딩을 통해 작업을 시작하는 것이 나쁜 것은 아니지만, 일정 수준의 DB 설계와 기획이 먼저 이루어지면 이후의 개발이 체계적이고 안정적일 수 있습니다. 요구사항 분석 및 설계 단계에서 엔티티 간의 관계, 제약조건을 명확히 해두면 나중에 발생할 수 있는 데이터 관련 문제를 미리 방지할 수 있습니다.

관련하여 시스템 전체에 대한 초기 설계 및 프로토타입 접근법에 대한 유익한 토론들은 아래 링크에서 확인하실 수 있습니다:

이 링크에는 비슷한 주제를 다루고 있는 Q&A와 기존의 답변을 포함하고 있으니 참고해 보시길 추천드립니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.