멋쟁이 사자처럼 프론트엔드 심화과정 4기 - Day 5
오늘은 데이터 베이스를 전반적으로 배웠다.
이때까지는 백엔드에서 단순히 데이터베이스에 있는 데이터들을 꺼내서 나에게 주면, 그걸 보여주기만 했기 때문에 데이터베이스에 대해서 깊은 이해와 관심은 가지고 있지 않았다. 단순한, 정말 단순한 쿼리문은 사용할 수 있지만 그 정도에서 그치면 안된다는 것을 깨달았기 때문에 오늘 수업도 시작부터 많은 호기심을 가진 채로 시작했다.
1. 시스템이란?
시스템이란 뭘까?
강사님께서는 수업을 하면서 종종 단어 자체에 대한 질문을 하신다. 나는 시스템이란 흐름 이라고 생각했다.
하지만 강사님의 설명을 듣다 보니 단순히 '흐름' 이라고만 정의 내리기에는 모자란 것 같았다. 항상 이해하기 쉽게 예를 들어 설명을 해주시곤 하는데 이번에는 병원에 갔을 때를 예를 들어 설명해 주셨다.
병원에 가게 되면 진료접수를 하고, 처리를 어떻게 해서 어떤 약도 처방받게 된다.
이걸 종이에 적어서 기록할 수도 있지만, 그 일을 대신해주는 것이 시스템이라고 했다.
그래서 개발자는 코드를 짜는 사람이 아니라, 문제를 시스템으로 해결하는 사람이라고 했다.
이렇게 이해하면 이해하기 쉬운 것 같아서 좋은 것 같다. 물론 이대로만 이해하면 안되겠지만 ㅎ...
2. 데이터 모델링이란?
시스템이라는 게 단순히 어떤 일을 자동화하는 도구만은 아니라는 걸 알게 되면서, 자연스럽게 “그럼 그 시스템 안에는 어떤 데이터가 있어야 하지?”라는 질문으로 이어졌다.
이 질문에 답하기 위한 과정이 바로 데이터 모델링이었다.
데이터 모델링은 생각보다 훨씬 체계적인 과정이었다. 총 세 단계로 이루어져 있다.
- 개념적 설계(Conceptual Design)
→ 이건 쉽게 말하면 "어떤 데이터가 필요할까?"를 정리하는 단계다.
예를 들어, 커피숍 시스템이라면 ‘회원’, ‘메뉴’, ‘주문’ 같은 개념들이 있다. - 논리적 설계(Logical Design)
→ 이제 그 개념들을 관계형 데이터베이스의 테이블 형태로 구체화하는 단계.
회원 테이블에는 이름, 이메일, 비밀번호 같은 필드가 있고, 주문은 회원과 메뉴를 참조하게 된다. - 물리적 설계(Physical Design)
→ 마지막으로는 DBMS에 실제 테이블로 구현되는 형태로 설계하는 단계다.
데이터 타입이나 인덱스 같은 구체적인 설정들도 이 단계에서 결정된다.
정말 놀라웠던 건 이 모든 과정이 코드를 단 한 줄도 작성하지 않고도 이루어진다는 것이었다.
그만큼 논리적으로 사고하는 힘이 중요하다는 걸 느꼈다.
3. 정규화란?
정규화는 사실 수업 전에 들어본 적은 있었지만, 정말 모르고 있던 개념이었다.
‘중복 제거’라고만 막연히 알고 있었는데, 수업을 들으면서 좀 더 본질적인 의미를 이해하게 됐다.
1) 1 정규화
가장 기본이 되는 1정규형(1NF) 은 ‘원자값만 허용’하는 것이라고 한다.
즉, 하나의 셀에는 하나의 값만 들어가야 한다.
예를 들어, 메뉴 테이블의 '크기' 칼럼에 tall, grande 같이 여러 값이 들어가 있으면 그건 정규화를 위반한 것이라고 했다.
이걸 듣고 “와... 나 예전에 저렇게 짜본 적 있었는데...” 싶어서 머쓱했다.
사실 프론트에서는 백엔드가 주는 데이터를 받아서 화면에 뿌려주는 데 집중하다 보니, 이런 DB 설계 원칙에 대해서 깊게 생각하지 않았던 것 같다.
2) 2정규화
2정규화는 1정규화를 만족한 상태에서, 부분적 함수 종속을 제거하는 것이다.
쉽게 말하면, 복합키를 사용하는 테이블에서 키의 '일부분'에만 의존하는 속성들을 따로 분리하라는 뜻이다.
이 개념을 듣고 처음엔 좀 헷갈렸는데, 계속 반복해서 들으니까 이해가 되기 시작했다.
단순히 테이블을 나누는 게 아니라, 속성 간의 관계를 고민해야 한다는 게 포인트다.
3) 3정규화
3정규화는 2정규화를 만족한 상태에서, 이행적 종속을 제거하는 것이다.
즉, 어떤 속성이 키가 아닌 다른 속성을 통해 다시 다른 속성을 결정하는 경우,
그 관계를 끊어내고 테이블을 분리해야 한다.
이건 “A가 B를 결정하고, B가 C를 결정하면, A는 C도 결정하는 거 아냐?”
라는 흐름을 없애는 작업이다.
이쯤 되니까 정규화는 단순히 ‘테이블을 잘게 쪼개는 것’이 아니라
‘데이터의 의존 관계를 끊고 명확하게 만드는 작업’이라는 걸 확실히 느끼게 됐다.
4) 3.5정규화
3.5정규화는 이름은 특이하지만, 개념은 꽤 명확하다.
모든 결정자가 반드시 후보키여야 한다는 것.
즉, 누군가 값을 결정할 수 있는 위치에 있다면, 그 사람은 키여야 한다는 얘기다.
키가 아닌데도 값을 결정하고 있으면, 그건 구조적으로 문제가 있다는 뜻이다.
이걸 들으면서 약간 조직도 같은 느낌이 들었다.
누군가 권한이 있으려면, 그에 합당한 위치(키)를 가져야 한다.
그게 안 되면 혼란이 생기니까.
3. 키(Key) 의 개념
그리고 키의 개념도 이번에 좀 정리됐다.
뭔가 주키, 후보키, 외래키 같은 말들이 헷갈렸었는데, 이걸 한 장의 표로 정리하면서 깔끔하게 정리가 되었다.
- Primary Key (기본키): 테이블에서 고유하게 한 레코드를 식별하는 키
- Foreign Key (외래키): 다른 테이블의 기본키를 참조해서 관계를 맺는 키
- Surrogate Key (대리키): 의미 없는 일련번호 키 (요즘 ORM에서 많이 사용함)
이걸 들으면서 프론트엔드에서 API 응답을 받을 때 userId, productId, orderId 처럼 넘겨주는 것들이
다 이 키에서 출발한 거라는 걸 깨달았다.
즉, API 설계도 결국 데이터 모델링과 정규화 위에 쌓인 것이다.
4. 다섯번째 강의를 마무리 하며....
오늘 수업을 들으면서 정말 많은 생각이 들었다.
나는 지금까지 프론트엔드 개발자라는 이유로 “데이터는 백엔드가 주겠지~” 하며 한 발 뒤에 물러나 있었던 것 같다.
하지만 그건 개발자로서 무책임한 태도라는 걸 오늘 느꼈다.
개발자는 코드를 짜는 사람이 아니라, 문제를 시스템으로 해결하는 사람이다.
이 말이 계속 마음에 남는다.
문제를 파악하고, 그 문제를 해결하기 위해 어떤 데이터를 저장하고, 어떻게 관계를 맺을지 고민하는 것.
그게 진짜 개발자의 일이라는 걸 느낄 수 있었다. 또한, 어떤 개발자가 되어야 할지도 조금은 그려지는 것 같다.