17강 (이론) 데이터베이스 설계하기

안녕하세요 비전공자를 위한 바이브코딩 올인원 클래스 17강 데이터베이스 설계하기 입니다 우리가 강의 초반에 MVC 패턴에 대해서 배웠어요. 코딩을 할 때 만드는 부분들을 크게 세 갈래로 나누면 모델, 데이터를 어떻게 저장하는지 하고 뷰, 그 다음에 데이터를 어떻게 보여주는지 어떤 데이터를 가져와서 어떻게 꾸며서 보여주는지라고 했어요. C, 컨트롤러, 이 데이터들을 어떻게 편집하고 움직이는지 이런 것들을 배웠습니다. 지금 여태까지 한 것들은 주로 뷰에 굉장히 초점이 많이 맞춰져 있었어요. 사용자들이 어떤 주소를 접속하면 랜딩 페이지를 보여주고 그런 부분들에 많이 초점이 맞춰져 있었고 또 컨트롤을 조금 했습니다. 조금 뭐였냐면 회원가입, 회원가입은 데이터를 생성하는 과정이죠. 로그인 데이터를 보내서 인증 정보를 받아오는 과정 컨트롤도 조금 하긴 했어요. 그리고 모델 부분은 물론 회원가입 자체도 로그인 자체도 어떻게 보면 조그만한 표 하나가 있어서 그걸 통해서 하는 거기 때문에 모델을 일부라고 볼 수도 있지만 여태까지 대부분의 시간은 인터페이스, 보여주는 거에 집중을 많이 했어요. 진짜 서비스가 되려면 근데 모델이 필요하겠죠. 제가 전에 말씀드린 대로 모던한 그런 현대의 모든 서비스들은 기본적으로 모델 래퍼입니다. 모델이 메인이 되고 그 껍데기를 우리가 씌워놓은 거예요. 그래서 모델을 어떻게 설계하는지가 되게 중요하고 그 모델을 설계하는 법을 알려면 데이터베이스에 대해서 조금 알아야 돼요. 그래서 원래 데이터베이스가 공대 다니시는 분들은 다양한 전공에서 한 학기 과목입니다. 한 학기 과목이어서 매우 많은 걸 배워요 데이터베이스에 대해서 하지만 우리가 알아야 되는 건 그 정도까지 필요가 없습니다 우리는 핵심적으로 코딩을 실현하기 위해서 데이터베이스와 관련된 기초 원리 그것만 알면 돼요 그다음은 AI와 상의하면서 하면 되기 때문에 데이터베이스가 어떻게 최적화되고 이런 것까지 전문적으로 배울 필요는 없습니다 그래서 제가 정말로 여러분들께 필요한 내용만 추리고 추려서 딱 핵심만 설명드릴 테니까 한번 집중해서 이해해 보시기 바랍니다 데이터베이스라고 하면 사실은 데이터라는 것은 텍스트입니다 더 밑으로 물리적인 레벨로 내려가면 바이너리 101010 이런 게 써져 있는 애들이고 바로 위 레벨은 텍스트로 이렇게 질서정연하게 써놓은 게 데이터예요 데이터베이스라고 하는 것은 그렇게 관리가 되면 안 되고 매우 체계적으로 관리가 돼야 됩니다 빨리 가져올 수 있어야 되고 빨리 검색할 수 있어야 되고 빨리 쓸 수 있어야 되고 그리고 여러 데이터들 같이 금방 볼 수 있어야 되고 어마어마한 양을 처리할 수 있어야 되고 또 정합성도 맞아야 돼요 정합성이라는 것은 데이터 간에 모순이 없거나 그런 문제들 보안 문제들 백업 문제들 복원 문제들 이런 문제들이 엄청 많아요 그래서 그냥 우리가 단순히 파일 형태로 데이터를 관리할 수 없습니다 데이터베이스 매니지먼트 시스템이라고 하는 DBMS라는 것을 하나 도입해서 서비스를 운영하게 돼요 DBMS는 전 세계에 엄청나게 많은 종류가 있습니다. 데이터베이스 역사도 굉장히 길기 때문에 그래서 보면은 이거는 이제 투표예요. 투표에서 점유율이랑 조금 상관이 없을 수는 있습니다. 근데 DBMS에 어떤 것들이 있는지 보여주셨는데 1등이 뭐죠? PostgreSQL. 투표에서는 1등이에요. 근데 실제 사용은 그만큼 못합니다. 왜냐면 PostgreSQL은 오픈소스예요. 오픈소스고 오픈소스라는 것은 보증이 되지 않는다는 거죠. 보증이 되지 않다 보니까 투표에서는 굉장히 높은 점수를 봤는데 대기업들이 발주를 줄 때는 책임자가 있어야 되니까 그런 오픈소스만 많이 쓸 수가 없어요. 그래서 개발자들이 제일 좋아하는 투표 압도적 1위는 PostgreSQL인데 실제 점유율은 조금 다르다 이렇게만 아시면 되고 MySQL, SQLite, 마이크로소프트 SQL도 제가 알기로 지금 마이크로소프트 거죠 이렇게 쭉 있습니다 그래서 SQLite도 이건 그냥 사실 어디든 따라오는 오픈소스 같은데 이렇게 이제 많이 쓰고 있고 우리 실습에서는 데이터 커넥트는 PostgreSQL을 써요 그걸 한번 Firebase가 정교하게 래핑 좀 더 전에 말씀드렸죠? 원래는 PostgreSQL은 자체 프로토콜도 있고 좀 어려운 시스템이에요 그래서 코드로 가져오려면 SQL 쿼리문도 좀 쓸 줄 알아야 되고 되게 복잡한데 그거를 서비스 형태로 포장을 해서 백엔드에서 서비스 그죠? 그래서 데이터 커넥트라는 서비스로 그냥 제공을 하고 우리가 가져다 쓸 때도 그냥 SDK까지 그냥 데이터베이스 쓰고 있고 이런 것들을 그냥 코드 한 줄을 쓸 수 있게 도와주기까지 합니다. 그래서 뭐랄까, 순수 PostgreSQL은 아니지만 어쨌든 우리 데이터 커넥트도, Firebase 데이터 커넥트도 PostgreSQL 기반으로 돌아가고 있다. 그렇게 아시면 될 것 같고요. 여기 위에서 한 다섯 개까지는 관계형 데이터베이스라고 불러요. 관계형 데이터베이스. 그리고 그 밑에 요거는 이제 NoSQL, 관계형 데이터베이스가 아니에요. NoSQL인데 물론 NoSQL 하시는 분들 주장은 Not Only SQL이라서 SQL도 하는데 더 많은 기능이 있다 이렇게 주장을 하긴 합니다. 그런데 위에 DBMS들은 관계형 데이터베이스 4개는 기본적으로 굉장히 형식을 중요하게 여깁니다. 저장 형식을 굉장히 중요하게 하고 성능 이런 걸 되게 중요하게 하는데 요런 몽고 DB 같은 어떤 NoSQL 계열은 뭐냐면 유연성 데이터를 아무렇게나 막 저장해도 어쨌든 쓸 수 있게 그렇게 이제 해요 근데 이거는 장점이 있긴 합니다 특히 이제 AI 시대 비정형 데이터라고 부르는 어떻게 보면 딱 형식이 안 정해져 있는 데이터들을 이제 유연하게 처리를 할 수 있기 때문에 굉장히 요즘 많이 또 쓰이고 있어요 그래서 점점 올라오고 있고 뭐 다양한 DB들 쭉 있습니다 레디스 이런 건 캐싱이라고 해서 속도 위주의 데이터 탐색을 캐싱해놨다가 속도 위주로 돌리고 이런 것들을 많이 쓰고요. 다양하게 쭉 있습니다. 그래서 파이어스토어도 있네요. 파이어스토어도 이제 원래 우리 데이터 커넥트 나오기 전에 제가 수업을 파이어스토어로 했어요. 파이어스토어도 NoSQL입니다. NoSQL이고 파이어베이스 일부로 구현이 되어 있어요. 이런 DBMS들이 있다. 그리고 DBMS 두 가지가 있다 그랬죠. 우리 옛날에 프로그래밍 랭귀지 배울 때 인터프리터 랭귀지와 컴파일 랭귀지가 있다고 얘기했던 것처럼 데이터베이스도 우리가 두 가지가 있다는 걸 기억하면 좋아요. 관계형 데이터베이스가 있고 그 다음에 NoSQL, 관계형이 아닌 데이터베이스가 있다. 그렇게 이제 생각하시면 되고 저는 근데 관계형 데이터베이스를 여러분들이 하는 걸 추천드려요 왜냐하면 그게 정석이고 일단 첫 번째로 두 번째로 제가 누누이 말씀드리지만 AI 코딩 시대에는 엄격한 걸 써야 됩니다 엄격한 거 그래야 우리가 문제를 조기 발견할 수 있어요 AI가 기본적으로 굉장히 난잡하게 일을 하기 때문에 불확실하게 일을 하기 때문에 다른 AI를 둘러싼 모든 분야는 미리 만들어진 것, 엄격한 것, 이런 것들로 둘러싸 버려야 돼요. 그러면 AI가 그 틀 안에서만 움직이기 때문에 실패할 가능성이 굉장히 떨어지게 됩니다. 마찬가지로 우리가 NoSQL을 쓰게 되면 물론 NoSQL도 충분히 좋습니다. 제가 옛날에 수업을 NoSQL로 했었고 오히려 구현은 더 빨라요. 구현은 더 빠른데 NoSQL을 쓰게 되면 초기에는 아 이게 엄청 쉽다, 좋다 이렇게 생각하지만 뒤에 시간이 갈수록 문제가 쉽게 발생할 수 있어요. 제가 사용하고 있는 저희한테 납품하는 업체 중에 NoSQL을 쓰는 데가 있는데 실수를 해가지고 저한테 엄청 혼난 적이 있습니다. 그쪽 개발자들이 저희 데이터를 덮어 쓰는 거예요. 왜냐하면 형식이 제대로 안 갖춰져 있으니까 저희 데이터하고 다른 회사 데이터하고 이런 게 다 모양이 조금씩 다른 거예요. 모양이 다 다르니까 얘네가 이제 저희 데이터가 어떻게 생겼는지까지 확인을 못하고 그거를 이제 자기들이 그 데이터 구조를 쓰겠다고 덮어 써버린 거예요. 해외에서 제가 폭풍 영어로 이런 언프로페셔널한 조치에 대해서 항의를 했고 거기서 사과를 엄청 했습니다. 사과를 하고 고치고 저한테 크레딧도 주고 자기들이 실수를 너무 심하게 했는데 보통은 관계형 데이터베이스에서는 그런 실수가 일어나진 않아요. 그런 실수가 일어나지 않고 그래서 오히려 고수들, 내가 머릿속에 모든 걸 알고 있는 정교한 고수들이 저는 오히려 NoSQL 스킬을 써야 되고 우리가 잘 모를수록 관계형 데이터베이스를 써야 된다고 주장을 하는데 보통은 이제 아무렇게나 해도 허용을 하니까 반대로 가요. 초보들이 자꾸 NoSQL을 쓰고 싶어 하고 고수들은 자기가 익숙하니까 이제 그냥 관계형 데이터베이스를 쓰고 싶어 하고 그런 경우가 좀 있습니다. 그래서 우리가 좀 생각해 볼 필요가 있어요. 계속 제가 누누이 말씀드리지만 AI와 함께 작업을 할 때는 엄격한 것을 써야 된다. 그래서 우리는 데이터 커넥트, PostgreSQL 기반의 그런 데이터베이스를 씁니다. 데이터베이스에서 엄격하게 저장한다는 게 뭐냐? 제가 앞에 우리 코딩을 한다는 것에서 오브젝트 오리엔티드 프로그래밍에 대해서 설명드린 적이 있어요. 모델에 대해서 설명드리면서. 그러면서 제가 동양철학을 가져왔어요. 동양철학을 서양 사람들이 잘못 해석해서 이상하게 이해하고 있는데 실제로 우리가 현대시대에도 컴퓨터공학에서 동양철학 그대로 쓰고 있다고 말씀드리면서 이런 말씀을 드린 적이 있어요. 컴퓨터 공학에서 우리가 어떤 걸 설계할 때 두 가지 영역이 있다고 그랬어요. 첫 번째 영역은 뭐죠? 박제되는 영역. 그러니까 우리가 고정하고자 하는 영역이 있고 두 번째는 뭐예요? 그 고정된 디자인을 바탕으로 쭉쭉쭉 뭔가 이렇게 뽑아내는 영역. 생성하는 영역이 있는 거예요. 청사진이 있고 생산품이 있는 거죠. 우리 그때 자동차. T모델이 있고 T모델이라는 건 뭐죠? 그냥 T모델이라는 건 컨셉이에요. 그죠? 디자인. 그런데 a T모델. 뭐 티모델 더 티모델 이건 내가 만질 수 있는 지금 번호판이 달린 이름이 달린 자동차라 그랬어요 그래서 이제 그런 두 가지 영역이 존재한다 티모델이라는 컨셉적인 그런 내용과 실제 우리가 만질 수 있는 자동차가 존재한다 그랬어요. 그게 이제 근데 OOP에서도 쓰지만 우리 관계형 데이터베이스에서 똑같은 컨셉을 씁니다. 그러니까 사실 2600년 전부터 우리 데이터베이스 그리고 OOP에 오기까지 우리가 사람이 사고하는 틀이 똑같은 거예요. 그리고 그 출처는 뭐예요? 원래 옛날 사람들이 생각하기에 신이 이 세상을 어떻게 창조했을까 그걸 바탕으로 우리가 컴퓨터 속 세상을 어떻게 창조할까가 이어지는 내용입니다. 그래서 위에 클래스 타입의 코드로 박제된 영역이고 밑에가 인스턴스 오브젝트 레코드 프로그램이 돌면서 끝없이 우리가 변하는 영역을 나눠서 관리를 한다 그리고 여기서 이쪽으로 만드는 거를 인스턴시에이션, 크리에이션, 얼로케이션, 이니셜라이제이션, 디클레이션 이런 단어를 쓰고 주로 DB에서는 create을 많이 써요 create, create을 많이 쓰고 우리 HTTPS 프로토콜 배웠죠? 거기서는 create 대신에 post라는 단어를 많이 씁니다 포스트, 아시겠죠? 포스트라는 단어를 많이 써요 요거는 클래스 타입인데 우리 데이터베이스는 클래스와 타입을 뭐라고 부르냐면 스키마라고 불러요, 스키마 클래스 타입들을 다 모아놓은 그런 것들이 스키마 스키마라는 건 뭐죠? 그것도 구조, 설계 이런 뜻이에요 스키마를 짠다 이제 그런 식으로 부른다는 거 이해하시고 잠깐 떠올려 보세요 왜냐하면 우리 이제 곧 들어갈 거예요 지금 다음 페이지부터 표로 들어갈 건데 그리고 OOP에서 배웠던 내용 결국에는 붕어빵 틀이 있고 붕어빵이 있다 이런 거죠 붕어빵 틀을 우리가 만들어 놓고 붕어빵 틀 가지고 붕어빵을 쭉쭉 만들어 놓은 방식으로 코딩이 이루어지고 데이터 저장이 일어난다 그렇게 이제 보시면서 다음 페이지로 넘어가겠습니다 이제 익숙한 뭔가 그림이 또 나왔어요. 예전에 OOP 배울 때 표를 한참 봤었는데 관계형 데이터베이스도 표입니다, 표. OOP는 오히려 표로 비유를 한 거라면 관계형 데이터베이스는 진짜로 표라고 불러요. 테이블이라고 불러요. 그래서 관계형 데이터베이스라는 것 자체가 뭐냐? 어려운 개념이 아닙니다. 그냥 데이터 타입을 하나의 표로 나타내고, 그렇죠? 한 데이터 타입을 한 표로 나타내요. 그다음에 그 타입들 간의 관계. 관계, 표 간의 관계 표 간의 관계를 통해서 데이터를 표현하는 그런 데이터베이스를 우리가 관계형 데이터베이스라 그러고 우리가 관계형 데이터베이스에 그러면 디자인이 되는 부분을 스키마라고 불러요. 스키마 표 하나로 보면 일단 표 하나로 보면 어디가 스키마예요? 위가 스키마에요 그죠? 우리가 어떤 이 첫 행에 어떤 열들을 만들 건지에 대해서 정의를 해놓죠, 표현했을 때. 그게 이제 디자인의 영역이에요. 우리 OOP 때 엄청 많이 했었죠? 여기가 디자인의 영역이에요. 그리고 밑에는 이제 또 오브젝트의 영역이겠죠? 디자인의 영역에 해당하는 요 하나하나를 뭐라 볼래요? attribute 속성이라고도 하고, 그 다음에 field. 왜냐하면 우리가 이제 출판등록번호를 쓰세요 하고 이렇게 빈칸 이렇게 해서 사람들이 입력해서 보내면 여기에 써질 거 아니에요. 빈칸은 이제 field죠. 내가 지금 텍스트를 입력할 곳이라는 의미에서 field라고 씁니다. 그래서 이것들을 field라고도 불러요. 여러 개니까. field들이 있는 거예요. 그래서 이렇게 이제 위에 디자인의 영역이 존재를 한다. 그렇게 보시면 되겠습니다. 그래서 요거가 스키마에요 스키마 그런데 표가 하나만 있으면 요게 스키마 끝이겠지만 표가 여러 개 있으면 표가 뭐가 있는지 그리고 그 표 각각의 첫째 행 그러니까 열들이 어떻게 구성되어 있는지 첫째 행에 무슨 열이 있는 거야 출판등록번호 열이 있고 사명이란 열이 있고 창사일이란 열이 있고 소개란 열이 있고 출판사란 열이 있는 거잖아요 그죠? 첫째 행이 어떻게 구성되어 있는지 혹은 똑같은 표현으로 열들이 무슨 값들을 가지는지가 우리의 데이터베이스 설계 스키마라고 불러요 디자인의 영역이 있으면 오브젝트의 영역도 있는 거죠 그래서 그걸 record라고 불러요 이 표에 기록된 하나의 record 기록물 기록단위 뭐 이런 느낌에서 레코드해요 그래서 예를 들어서 이번엔 또 다른 표를 가져왔는데 제가 일부러 표를 교체해서 보여드리는 건 나중에 이 관계를 보여드리기 위해서요 책이라는 표는 ISBN 이거 뭔지 아시죠? 책의 고유번호, 출판사 제목, 소개 상태, 작가의 기재 첫째 행을 통해서 필드를 정해놨습니다 이제 여기 스키마고 근데 우리가 이 스키마에 따라서 쓰는 거 하나하나가 뭐예요? 하나하나가 레코드예요 그리고 이거는 우리 코딩 영역에서는 똑같은 거를 인스턴스나 오브젝트라고 부릅니다 책 인스턴스 혹은 책 오브젝트 실제 책에 대한 얘기고 그다음에 레코드 물론 그런 게 있어요 책도 한 가지 책을 여러 개 출판하잖아요 그러니까 책 자체도 클래스일 수 있어요 그래서 우리가 좀 어려울까 봐 말씀 안 드리지만 클래스와 오브젝트의 상대적인 관점이 대디자인에서 파생된, 찍혀 나온 디자인들이 있는데 그 디자인들도 결국에는 실물에 비하면 클래스 영역이 있을 수 있어요. 그죠? 우리 더 큰, 더 근원적인 디자인한테는 그게 오브젝트로 생성되는 거지만 이것도 계층 구조가 있다 이런 거는 나중에 알아두세요. 우리가 책이라는 거대한 컨셉이 있고 거기에 이제 제목과 책의 종류들을 나열하면 책이라는 거대한 컨셉 밑에서는 얘네들이 오브젝트들이지만, 레코드들이지만 또 얘가 실제 인쇄한 책들을 보면, 만질 수 있는 책을 보면 걔는 또 얘의 오브젝트죠. 오브젝트의 오브젝트. 클래스의 클래스도 존재한다. 그렇게 보시면 되겠습니다. 그냥 재미로 들으세요. 혹시 이 책은 실물이 아닌데 이것도 디자인 아닌가요? 하시는 분 있을까봐 제가 설명을 드리는 거예요. 맞습니다. 근데 우리 책이라는 표의 관점에서 보면 얘는 실물이고 책이라는 컨셉에서 보면 그리고 이 책 제목이나 이런 거 디자인에 대해서 또 실제 인쇄된 책을 보면 얘의 입장에서는 걔도 오브젝트인 거죠. 그러면 우리 실제 인쇄된 책은 이 구조에서는 책이라는 표의 오브젝트의 오브젝트죠. 이 책이라는 표는 만져지는 책에 비해서 이 데이터 구조 안에서는 클래스의 클래스라고 보시면 되겠습니다. 어쨌든 그래서 이 하나하나 행을 레코드라고 부른다. 그렇게 보시면 되겠습니다. 이제 우리가 표를 봤어요. 표도 쉽죠? 우리 평생 써왔어요. 참고로 표라는 뜻이 저는 예전에 유튜브에서 봤나 그래요. 표라는 뜻이 원래는 왕에게 보고를 하던 그런 틀을 표라고 불렀습니다. 한자로 옛날에는 왕이 뭔가를 보려고 하면 줄글로 보고를 하면 안 되고 표를 그려서 이번에 거둔 세금 몇만 섬 사용한 세금 몇만 섬 어디로 군율에 얼마를 썼고 표로 정리를 해서 드려야 왕도 그걸 보고 통치를 좀 쉽게 하겠죠. 그것처럼 어떻게 보면 표라는 것 자체가 이미 우리 직관이 굉장히 오래된 그런 형식이에요 그래서 어렵지 않습니다 표 자체는 어렵지 않아요 관계형 데이터베이스에서 조금 더 어려운 부분들은 그 표 간의 관계를 어떻게 묘사할 거냐 관리를 할 거냐에 대해서요 이것도 핵심은 쉽습니다 핵심은 쉽기 때문에 잘 집중해서 들어보세요 우리가 출판사가 있고 책이 있어요 출판사 하나는 여러 가지 책을 출판할 수 있습니다 그런데 책은 이제 자기가 나온 출판사가 있죠 그리고 출판사 엄청 예외적으로 출판사 두 곳이 같이 출판한다 저는 그런 경우는 본 적이 없어요 우리 서점에 가면 항상 책은 하나의 출판사 하나의 출판사에서 나왔습니다 그래서 출판사와 책의 관계를 우리가 어떻게 묘사할 거냐 한 출판사는 여러 가지 책을 만들어낼 수 있고 한 책은 이제 한 출판사에서 나왔어요. 이 관계를 출판사와 책이 1대N 관계를 가진다고 해요. 1대N, one to many. 그러니까 출판사 하나에 책이 여러 가지. 간단하죠? one to many라는 관계를 가진다. 그래서 출판사라는 표가 있었죠, 표. 그리고 책이라는 표가 있었어요. 출판사라는 타입을 표로 표현한 거고, 책이라는 타입을 표로 표현한 건데 이 출판사와 책이라는 타입은 본원적으로 1대N의 관계를 가진다는 것, relation을 가진다는 것 이해하시죠? 이걸 어떻게 우리가 앞으로 관리를 할 거냐 한번 보겠습니다 관계형 데이터베이스의 relation 일단 이런 생각을 한번 해볼게요 간단하게 우리가 출판사에다가 출판사 표에다가 자기 출간한 책을 쓸 수 있는 방법이 있는지 한번 보겠습니다 출판사가 이렇게 있어요, 표가. 그래서 원래 앞에 출판등록번호, 사명, 창사일, 소개, 출판수가 이렇게 있었어요. 그래서 여기 이걸 써놨는데 이제 출간한 책을 이 표에다 기록을 하고 싶은 거예요. 그럼 어떻게 해야 되죠? 이게 한 레코드가 한 출판사니까 여기 이제 열을 늘려야 되겠죠, 그죠? 첫 번째 책, 두 번째 책, 세 번째 책, 출간한 네 번째 책. 근데 이게 문제가 뭐예요, 이렇게 하면? 그러니까 지금 이제... 제가 지금 설명드리려고 하는 것은 출판사 표에다가 그 출판사가 출간한 책들을 넣을 수 있는지에 대한 내용이에요 출판사 표에다가 그 출판사가 출간한 책을 넣을 수 있을지 보는 거예요 근데 이제 우리 문제가 뭐냐면 레코드 하나가 출판사 하나기 때문에 세로로는 이걸 더 쓰지 못한단 말이에요 여기다가 데이터 형식이 딱 정해져 있는데 여기다 책을 뭘 쓸 수 있는 방법 없고 이제 가로로 확장을 해야 되죠 이 출판사에 추가된 데이터들을 막 확장을 해야 된단 말이에요 근데 이게 문제가 뭐냐면은 책이 한 개면 되는데 수십 개예요 아니면은 뭐 어떤 출판사는 한 개 출간했고 어떤 거는 1만 개를 출간했어요 그럼 표의 크기를 어떻게 조정해야 돼요? 최대 책수를 가진 대로 하고 나머지는 다 비고, 놀고 뭐 이런 일들이 이제 벌어질 수 있는 거죠. 그리고 최대 책수를 했는데 거기가 또 출간했어요. 그러면 또 스키마를 변경해야 돼요. 근데 우리가 뭐라 그랬죠? 우리 철학적으로, 동양철학적으로, 도덕경 철학 혹은 이제 기독교 철학적으로, 그리스 철학적으로 우리가 이 디자인의 세계는 바뀌면 안 된다 그랬어요. 디자인의 세계는 최대한 최대한 고정된 우리가 빨리 바뀌고 생기고 없어지는 거는 이 오브젝트의 세계여야 되지 이 첫 행 이 구조가 어떻게 생겼는지는 바뀌면 안 된다고 했어요 그러니까 출판사에다가 우리가 책을 기록을 하면 그 철학이 위배가 되는 거예요 출판사한테 출판사라는 표한테 출판사의 표에다가 각 출판사가 출간한 책을 우리가 넣을 수는 없다는 거예요 무슨 말인지 이해하시죠? 그래서 우리가 이제 반대로 또 책에서는 우리가 이걸 기록할 수 있는지 볼게요. 책은 하나의 출판사만 가져야겠죠? 그러니까 책들이 막 있어요. 여기 열을 하나 딱 추가했어요. 출판사. 그러면 앞으로 뭐해요? 이 한 열만 쓰면 돼요. 그죠? 이 책은 모든 책은 하나의 출판사를 가지니까 이 열이면 충분해요. 그죠? 이 정도는 우리가 영구적으로 책에 어느 출판사에서 나왔는지 써놔도 그죠? 변화가 없어요. 아까 책은 막 책 1, 책 2, 책 3, 책 4 해서 막 열이 막 바뀌어야 되고 막 커졌다 작아졌다 뭐 해야 되지만 책은 그럴 일 없어요. 그냥 무조건 출판사 한 곳에서 나왔기 때문에 책이라는 표 안에다가 어느 출판사 출신인지 써놓을 수 있다는 거예요. 이해하셨죠? 이건 괜찮죠. 왜 괜찮죠? 우리 철학에 위배되잖아요. 우리 설계와 실제 오브젝트를 분리한다는 철학에 위배되잖아요. 이렇게 출판사라는 거를 한 번만 딱 써놓으면 앞으로 영원히 책이 새로 레코드가 추가되든 삭제되든 수정되든 여기 출판사 하나만 써주면 되는 거예요. 그래서 이렇게 기록하는 건 된다 하는 거예요. 이게 우리 관계형 데이터베이스의 핵심적인 개념이에요. 이거를 저는 사실 좋은 교수님도 뵙고 강의는 조금 부족하신 연구로는 매우 훌륭하시죠 그런 교수님도 뵙지만 처음에 관계형 데이터베이스를 너무 어렵게 가르쳐요 강사들도 그렇고 교수님도 그렇고 별거 아니에요 이유를 알아야 돼요 왜 우리가 이렇게 하는지 일대에는 이렇게 합니다 이게 중요한 게 아니라 왜 이렇게 하는지 우리가 이 세상을 창조했던 철학 우리가 상상하기 신이 있었다면 어떻게 창조했을까 이 철학을 우리가 가져와서 지금 이걸 설계를 했는데 그런데 건들면 안 되는 영역을 우리가 마구잡이로 건들기 시작하면 어떻게 되는 거예요? 어떻게 되는 거예요? 이 철학의 위배가 되니까 그 철학을 위배하지 않는 방법을 찾다 보니까 이렇게 된 거지 사고의 과정이 있는 거예요 단순히 우리가 Why 없이 What을 와가지고 이렇게 쓰는 게 최적이야 내가 알려줬으니까 그냥 그렇게 써 하면은 우리가 기억을 못해요 기억을 못합니다 이해를 해야지 이해를 해야 기억을 하고 활용할 수 있어요 그래서 우리가 이제 뭘 봤죠 출판사에다가는 책을 넣지 못한다 출판사에다가 출판사표에다가는 책을 넣는 순간 이게 한 권일지 만 권일지 모르기 때문에 열이 바뀐다는 거고 열이 바뀐다는 거고 스키마가 바뀐다는 거고 스키마가 바뀐다는 건 디자인이 바뀐다는 거고 이건 우리 철학에 어긋난다 하지만 책이라는 표에다가 출판사를 넣는 건 전혀 문제가 없다 왜냐? 이건 한 열만 추가하면 되고 한 열만 추가됐기 때문에 더 이상 바뀔 이유가 없어요 한 열만 쓰면 되기 때문에 그래서 이런 식으로 이제 우리가 할 수 있고 또 한편 우리가 생각해 보면 이런 거예요 이것만 써 놓으면 이론상 모든 데이터는 다 있는 거예요 그리고 출판사표에다가 각 책을 안 써놔도 이론상 모든 데이터는 다 필요한 데이터는 있는 거예요 왜냐하면 우리가 예를 들어서 출판사가 출간한 책을 찾고 싶으면 출판사표에 가서 책을 찾는 건 안 되니까 안 되지만 여기 와서 출판사별로 이 레코드들을 모아서 쿼리를 하면 되는 거예요 그러니까 우리가 책을 보고 어느 출판사에서 나왔어 라는 데이터도 추적이 가능하지만 이렇게 저장해 놓으면 출판사별로 어떤 책을 출판했는지도 이 출판사별로 모아보면 돼요 우리 엑셀에서 많이 해보셨죠 필터로 모아보면 그냥 그것도 데이터를 볼 수 있는 거예요 그러니까 그쪽에다 기록 안 해놔도 여기만 기록해놔도 제대로 기록해놔도 아무 문제가 없는 거예요 데이터 전체를 파악하는 데 있어서 다만 이제 이거를 아까 전에 위에서 출판사 하나를 딱 바로 뽑는 속도하고 이 출판사들별로 이 책을 모으는 속도하고는 좀 다르긴 하겠죠 근본적으로 데이터를 못 찾지는 않는다는 거예요 그것도 이제 이렇게 쓰는 이유 중에 하나입니다. 근본적으로 문제없다. 그리고 또 하나 잠깐 말씀드린 NoSQL은 어떻게 해요? NoSQL은 둘 다 허용하는 거예요. 출판사가 책을 쓰는 것도 허용해요. 그러니까 딱 표가 세팅이 안 되어 있는 거예요. 그래서 그냥 책이라고 하는데 밑에다가 책을 막 여러 개 쓸 수 있어요. 책이라는 열을 하나 만들고 그 하위 열을 만들어서 이제 트리 구조로 막 책들을 쓸 수 있어요. 그래서 출판사 하나만으로도 책 내용까지도 그냥 다 통합할 수 있어요. 그런데 그렇게 하면 책이라는 데이터 타입이 출판사마다 달라질 수 있고 책의 개수도 달라질 수 있고 관리하기가 훨씬 힘들어지는 거예요, NoSQL이. 유연하지만 틀이 없기 때문에. 그리고 또 검색도 어렵겠죠. 얘는 책을 만 권 갖고 있고 얘는 한 권 갖고 있고 이러면 출판사별 책을 보고 싶다 그러면 여기서 그냥 정렬만 하면 되는데 우리 책표가 있으면. 그런데 NoSQL은 각 도큐먼트를 들여다보고 책이라는 애를 찾아가지고 뭔가 이제 처리를 해줘야 돼. 그래서 그냥 이제 인덱싱이라고 해서 미리 미리 그거를 이제 처리할 거라고 예고를 해 놓습니다. 그래서 조금 성능을 개선하는 그런 방식으로 씁니다. 근데 기본은 기본은 RDS에요. 지금 배우고 있는 그래서 이런 식으로 어 출판사 쓰면 된다 하면 되고 자 이제 그 잠깐만요. 근데 만약에 만약에 이런 문제가 있을 수 있어요. 출판사가 같은 이름을 가지고 있어요. 그럴 수 있죠. 동명이인 것처럼 해외 출판사랑 우리나라 출판사가 같은 이름을 갖고 있거나 그런 일이 있을 수 있어요. 그래서 우리가 이제 출판사를 기록하는데 출판사를 기록하는데 그냥 출판사 이름을 쓰는 게 아니라 출판사의 고유번호를 써주는 거예요. 이렇게 그래서 이 고유번호들을 뭐라 부르냐면 고유번호들을 뭐라 부르냐면 잘 들으세요. 중요한 개념이 키(key)라고 해요. 키 그래서 이제 이 표에서 이 표, 그러니까 책이라는 표에서의 각 책의 고유번호는 우리가 primary key라 그래요 그래서 우리 책이라는 표가 있으면 얘가 primary key가 되는 거야 ISBN은 제가 알기로는 고유합니다 그래서 primary key가 되는 거고 이제 근데 이 출판사의 고유번호라는 것은 출판사의 고유번호라는 것은 책이랑은 무관하죠 그런데 출판사 표에 이게 써져 있어요 출판사 표를 가보면 출판사 표의 자기 고유번호는 또 써져 있어요 그러니까 출판사 표에서는 얘가 primary key인 거고 책의 표에서는 얘가 primary key인 거예요 근데 내가 외부 표, 밖에 있던 표의 primary key를 내 열에 이렇게 딱 붙여버린 거예요 그래서 이걸 따라가면 출판사라는 표가 있어서 그 출판사 정보가 이렇게 레코드로 되어 있는 거죠 그래서 이거를 책 입장에서, 책이라는 표의 입장에서 뭐라 부르느냐 foreign key라고 불러요 다른 표의 primary key를 내가 여기 추가해놨다. 그래서 foreign key, 외부에서 왔다. Foreigner가 이제 외국인이죠. 외부에서 온 그 키다. 그래서 이건 이제 우리 자체 데이터의 키가 아니고 외부 연결을 나타내기 위해서 가져온 키다. 그래서 foreign key라고 부릅니다. 자, 다시 한 번 말씀드릴게요. 내 표, 책이라는 표가 있어요. 책이라는 표에서 내 레코드들의 고유번호를 구해준다고 했어요. 우리 동양철학에서 그걸 뭐라고 한다고 했죠? 명. 이름 명 자. 천재적인 거예요, 사실. 2600년 전 사람들도. 명이라는 걸 해서 고유번호, 고유 이름을 붙여주는데 이거 말고 우리 책이라는 거 말고 여기 이제 책이 각각이 출판사 하나씩을 가지는데 그 출판사도 고유번호가 있겠죠 그래서 이거는 사실은 그 출판사의 표에 있던 primary key예요 그걸 이제 우리가 책에 연결해주기 위해서 가져왔어요 참고로 그 표에서는 얘가 고유하겠지만 이 표에서 출판사 번호들은 중복이 될 수 있겠죠 왜냐면 이 책도 한 출판사에 나오고 이 두 책 다 같은 출판사에서 나오면 여기선 고유하지 않아요 저쪽에서 고유한 거지 저 출판사라는 표는 표에서는 두 개 있으면 안 되겠죠 그죠? 거기서는 이제 고유하지만 여기선 고유하지 않아요 한 출판사가 여러 책을 낼 수 있기 때문에 그래서 이렇게 써놓으면 이게 책 표에서는 뭐라고요? foreign key 라고 부른다는 거예요. 그래서 이거는 외부 표의 primary key들을 내가 가져왔다. 그래서 우리 표에서는 foreign key를 열로 가지고 있다. 이렇게 표현을 하는 거예요. 이해하시죠? 잠깐 비유를 들자면 우리 1대 n 스키마였어요. 우리가 출판사 대 책은 1대 n. 그러면 그냥 요약하자면 이런 거예요. 주인과 가방. 우리 공항에서 승객이 있고 가방이 있어요. 우리가 두 가지 방법으로 관리를 할 수 있죠. 주인한테 어떤 가방에 바코드를 붙여놓고 주인한테 그 가방의 리스트를 이제 줄 수 있어요. 실제로 줍니다. 둘 다 하는 거죠. 여권에다 꽂아주죠. 영수증처럼 꽂아줍니다. 그런 방식이 있고 또 하나는 뭐예요? 가방에다가 주인 정보를 우리가 태그로 달아놓을 수 있어요. 실제 공항에서 둘 다 합니다. 근데 우리 관계형 데이터베이스에서는 가방에다가 이름표를 붙이는 시스템입니다. 왜냐? 한 승객이 여러 가방을 가질 수 있잖아요. 그럼 그 여러 가방에다가 이름표를 붙이면 이름표는 하나씩만 붙이면 된다는 거예요. 승객한테 가방 표식을 붙인다 그러면 가방 수에 따라서 각자 승객마다 다른 개수만큼의 바코드 이런 걸 갖고 있어야 되지만 우리가 가방한테는 한 개의 이름표만 붙이면 그 관계를 표현할 수 있다는 거예요 그래서 1 대 n의 관계라는 것은 승객과 가방의 여러 개의 가방을 어떻게 관계를 표현할 거냐 해서 가방에다가 주인 태그 이름표를 붙이는 거예요 그리고 그 이름표를 뭐라 불러요? foreign key라고 부르는 거예요 주인 한 명 고유한 한 명이니까 foreign key라고 부른다 그렇게 기억하시면 되겠습니다 관계형 데이터베이스의 1대N 관계에 대해서 우리가 좀 봤어요 자 이제 N대N 보겠습니다 N대N 관계 우리 1대1 관계는 쉬워요 1대1 관계는 뭐 foreign key 넣어도 되지만 당연한 내용이고 너무 없죠 그냥 서로 넣어도 돼요 서로 출판사에다가 출판사가 한 권씩만 출간하는 이상한 일이 있다고 가정을 하면 그런 일은 없지만 그냥 출판사 표에도 책 넣어놓고 책 하나니까 한 열 넣어놓고 책 표에도 출판사 한 열 넣어놓고 끝이에요 1대1은 우리가 안 했어요 1대N은 했습니다 1대N은 개념을 배웠고 그다음 조금 어려운 게 N대N Many to Many 이게 대략 어떤 느낌이냐면 이런 거 우리가 채팅방 채팅방도 데이터로 있을 거예요 우리가 말해서 페이스북 채팅방 카카오톡 채팅방 이런 게 있으면 단체로 들어가는 방들이 있다 그러면 채팅방 제목도 있고 얼마나 오래된지 안에 있는 메시지도 있고 되게 뭐가 많잖아요. 그러니까 채팅방이 있고 그다음에 사용자가 있어요. 사용자. 그러면 사용자와 채팅방의 관계는 뭐죠? 사용자와 채팅방의 관계. n 대 n이에요. 그렇죠? 잘 들어보세요. 예를 들어서 한 사용자는 여러 채팅방에 들어갈 수 있나요? 그렇죠? 여러 채팅방에 들어갈 수 있나요? 그렇습니다. 그렇죠? 한 채팅방은 여러 사용자를 가질 수 있나요? 그렇습니다. 그렇죠? 그걸 우리가 n 대 n 관계라고 하는 거예요. 한 사용자도 여러 채팅방에 들어갈 수 있고 한 채팅방에도 여러 사용자가 들어올 수 있어요. 그렇죠? N대N 관계라고 해요. 그래서 이걸 Many-to-Many라고 하는데 이거는 이제 우리 관계형 데이터베이스에서 어떻게 표들 간의 관계를 나타내느냐 그걸 이제 좀 설명을 간략히 드리겠습니다. 쉬워요. 어떻게 나타내냐면 기본적으로 세 표를 하나 만들어요. 중간표, 정션 테이블 혹은 링킹 테이블이라고 해서 테이블끼리 연결하는 테이블이다 해서 링킹 테이블이라는 걸 만들어요. 그래서 N대N 연결 관계. 우리 사람과 채팅방의 관계는 뭐라고 얘기할 수 있죠? 참여라는 걸로 할 수 있어요. 그러니까 한 사람이 여러 채팅방에 참여할 수 있는 거죠. 한 채팅방에 여러 사람이 참여할 수 있는 거죠. 그러니까 우리 참여를 기록을 해두면 참여를 기록해두면 그 관계를 묘사할 수 있어요 예를 들어서 이 사람은 이 채팅방, 이 채팅방, 이 채팅방에 참여를 하고 있고 그 사람은 이 채팅방, 이 채팅방, 이 채팅방에 참여하고 있고 하나하나의 선을 다 레코드로 나타내는 거예요 그러면 이게 N대N 묘사가 완벽하게 됩니다 어렵다고 제가 경고했는데 좀 쉽네요 그래서 우리가 이걸 보면 이 채팅방에 들어온 사람을 어떻게 찾아요? 내가 지금 이 채팅방이라고 하는 애를 기준으로 정렬을 해보면 거기에 어떤 사람들이 들어와 있는지 파악할 수 있어요 반대로 한 사람이 어떤 채팅방에 들어왔는지 보고 싶으면 어떻게 해야 돼요? 이 표가 있으면 특정 사람 아이디로 쭉 찾아서 걔가 들어가 있는 채팅방들을 확인하면 되는 거죠 그래서 이런 테이블, 참여 상태라고 하는 테이블을 하나 딱 만들면 정션 테이블, 링킹 테이블을 만들면 이 둘의 관계가 어떻게 묘사되어 있는지를 알 수 있는 거예요. 그래서 n-n이 약간 관계형 데이터베이스의 꽃이죠. 아예 관계용 표를 하나 따로 만들어서 관리를 하는 거기 때문에 관계를 묘사하는. 그래서 우리가 이제 실제 개발에서는 n-n인데 지금처럼 참여처럼 실세계에서 쓰는 용어가 생각이 안 날 때가 있어요. 그럴 때는 보통 관계형 데이터베이스에서 핵심이 되는 내용은 다 배운 거예요. 단순하죠. 단순합니다. 물론 우리가 심화로 배우면 배울 건 많지만 우리가 알아야 될 건 이 정도예요. 그리고 이제 실제 서비스는 또 물론 또 다른 문제가 있긴 합니다 뭐냐면은 이 데이터 타입이 엄청 많다는 거죠 넷플릭스만 해도 예를 들어서 수강생 진도율 어디와 강의와는 어떤 관계고 영상과는 어떤 관계고 수강생과는 어떤 관계고 정산 우리 강사님들 정산해 드릴 때 수강률과는 어떤 관계고 이런 것들을 다 정의하다 보면 서비스 데이터베이스 스키마 짜는 것만 해도 매우 복잡한 일이 될 수 있어요 근데 제가 13년을 이 IT 쪽에 있었는데 저희 결론은 이렇습니다 스키마가 복잡한 서비스는 성공하기 쉽지 않아요 왜 그러냐면 인지 부하에 대해서 제가 말씀드렸지만 우리 데이터가 복잡하다는 것은 사용자가 사용하기 복잡하다는 거예요. 그러니까 진짜 우리가 설계를 잘했다면, UX를 설계를 잘했다면 데이터도 단순할 가능성이 커요. 인스타그램 얼마나 단순해, 인스타그램. 그렇죠? 사용자 있고, 포스트 있고, 좋아요 있고, 뭐 그 정도. 거의 끝이에요, 그게. 그게 다예요. 타임라인을 보여주는 알고리즘, 꽤 알고리즘이 있다는 거지. 그게 다입니다. 친구 관계, 뭐 이 정도. 사용자 간의 링킹 테이블 엄청 단순한 서비스예요 대단한 성공을 거뒀죠 그래서 핵심만 알면 됩니다 오히려 내가 지금 너무 데이터베이스가 복잡해지고 있다 그러면 내가 기획을 잘했는지 고민하는 게 좋아요 데이터베이스를 더 파고들어서 공부한다는 느낌보다는 그래야 사용자들이 보기에도 이게 깔끔하고 단순한 서비스 바로 쓸 수 있는 서비스다 라는 느낌을 줄 수 있습니다 원래 실습에서는 블로그, 포스팅을 할 수 있는 그런 시스템을 얘기했기 때문에 그런 스키마만 대충 어떻게 생기냐? 우리 AI가 같이 짤 거긴 해요. 하지만 대충 생각해보면 이런 거예요. 우리가 Authentication에 있는 표가 있어요. 그거는 파이어베이스에서 세팅을 했기 때문에 따로 있는 표고, 걔가 프로필 기능은 없기 때문에 확장을 해야겠죠. 그래서 사용자 타입 프로필을 만들어서 1대1로 연결을 해주면 됩니다. 1대1로 연결은 되게 쉽다고 했어요. 그래서 확장이 되는 거고 여기 프로필 사진 같은 걸 넣을 수 있다 이렇게 보시면 되고 그다음에 이 사람이 무슨 블로그 포스팅을 썼어요, 그죠? 포스팅을 썼으면 여기 무슨 권한 같은 것도 넣긴 해야 되겠네요 이 사람이 이제 작성자 권한인지 그냥 회원인지 일반 회원인지 이런 것도 넣어야 되겠지만 일단은 우리 관계에만 좀 집중해 보겠습니다, 관계에만 사용자는 여러 포스트를 쓸 수 있죠, 그죠? 여러 포스트를 쓸 수 있기 때문에 사용자와 포스트는 1대N 관계예요, 1대N 관계 그리고 포스트에는 또 여러 개 댓글을 달 수 있죠. 그래서 포스트와 댓글도 1대N 관계예요. 한 포스트가 여러 사용자를 가지는 경우는 블로그는 거의 없습니다. 요즘에 기자들이 여러 기자명을 쓰더라고요. 저는 사실 그것도 제 취향에 맞지 않습니다. 왜 그러냐면 뭔가 내가 온전히 책임을 안 지고 자 이렇게 많은 사람들이 참여했으니까 일단 들어봐 이런 느낌으로 강요하는 느낌이 있어서 안 좋아하지만 어쨌든 원래 블로그는 우리 페이스북, 포스팅, 인스타그램 마찬가지입니다. 한 사용자가 여러 포스트를 올리지, 한 포스트를 여러 사용자가 협업해서 올리는 경우는 없어요. 그래서 1대N 관계. 댓글도 그렇습니다. 댓글과 포스트의 관계는 한 포스트에 여러 댓글이 달리지, 한 댓글이 여러 포스트에 달리지는 않아요. 그러니까 내용이 같을 수는 있어도 우리가 댓글을 생성할 때는 딱 포스트에 소속돼서 생성을 하기 때문에 이것도 1대N 관계입니다. 그리고 댓글도 작성자가 있어요 댓글을 쓴 사람이 있기 때문에 그리고 한 사용자가 여러 댓글을 쓸 수 있고 한 댓글을 여러 사용자가 쓰지는 않죠 이것도 1대N 관계예요 그래서 1대N을 나타내면 N 쪽에 우리가 이름표를 달아준다 1대N 그러면 N 쪽에 이름표를 달아줬어요 1대N 하면 얘와 얘 사이에 1대N은 이 이름표를 통해서 달아줬고 얘와 얘 사이의 1대N 관계는 이 이름표를 통해서 달아줬어요. 그런 식으로 우리 데이터베이스 스키마가 구성이 되는 거예요. 그러면 아까 전에 디자인이 너무 복잡한 거 아닌가요? 이렇게 생각할 수 있는데 생각해보시면 모든 댓글이 딱 두 개의 열만 가지면 되는 거예요. 이름표 두 개. 이런 거 자체가 문제는 아니죠. 아까 전에 이름표가 1만 개인지 1개인지 모를 때가 문제지 이름표 두 개로 고정해 놓는 거는 우리 관계형 데이터베이스처럼 안 어긋납니다. 그래서 이런 식으로 이름표 두 개를 붙이면 관계가 된다. 그렇게 보시면 되겠습니다. 저는 조금 더 복잡한 서비스를 만들고 있죠. 그래서 이런 식으로 프로젝트 태스크 마일스톤 이런 식으로 저글이라고 하는 서비스를 여러분들한테 시연하면서 만들고 있는데 출시할 건데 이건 좀 더 복잡합니다. 왜냐하면 프로젝트 단위가 있고 그 다음에 태스크, 마일스톤 있고 여기 추가 안 한 것도 있어요. 예를 들면 수금 일정, 수금 계산서 일정 이런 것도 어떻게 보면 프리랜서 입장에서 관리해야 되는 그런 다른 컨텍스트가 있어요. 그래서 그런 것들까지 다 하면 조금 더 복잡할 거예요. 그래서 여러분들의 선택은 각자 지금 하고 계신 프로젝트에 맞게 하시면 되는 거예요. 그리고 이 개념만 알아두시면 되고 AI랑 대화할 때 이거를 직접 얘기하지는 않습니다. 무슨 필드가 있어야 되고 일대일이고 엔대엔이고 직접 얘기하시면 매우 훌륭하지만 우리가 비전공자고 초심자를 대상으로 하는 강의이기 때문에 직접 얘기하지는 않을 거예요. 하지만 우리가 뭘 알려줘야 되는지 데이터 타입을 알려주고 그 관계들에 대해서 우리가 대략적인 개념이 있어야 되고 그리고 각 데이터 타입들이 가지고 있는 어떤 필드들에 대해서도 우리가 대략적으로 알고 있으면 훨씬 대화하기 편해요. 제가 이제 데이터베이스를 모르던 시점, 아주 오래 전이죠. 우리 팀원들이랑 같이 프로젝트를 할 때는 제가 그거에 대해서 잘 모르기 때문에 십 몇 년 전 얘기인데 잘 몰라서 우리 개발자들이 항상 어려워했어요. 왜냐면은 이게 이제 저는 계속 세상의 컨셉을 얘기하고 있는데 이 친구들은 실제로 그런 방식을 구현할 수 있는 방법이 없는 거예요. 표와 관계로 설명을 해주면 바로 구현해 주는데 표와 관계가 아니라 내가 이 세상에 있는 어떤 철학적인 기획의 내용을 얘기해 봐야 개발자들이 작업을 못하는 거죠. 그러니까 AI도 마찬가지겠죠. AI도 우리가 훨씬 더 유연하고 많은 것을 알고 학습이 되어 있기 때문에 더 잘할 수는 있겠지만 근원적으로 우리가 하나도 모르면 AI가 또 엉망으로 만들어집니다. 그래서 관계형 데이터베이스를 이해하는 그런 시간을 가져봤습니다. 데이터베이스 별거 아니죠. 우리 같이 잘 이해를 해봤고 오늘 강의도 수강하시느라고 고생 많으셨고 다음 시간에 뵙도록 하겠습니다. 감사합니다.