데이터베이스

얻어갈 것

이번 레슨에서는 데이터베이스를 “서비스가 오래 기억해야 하는 정보를 담는 곳”으로 잡습니다. 목표는 SQL을 깊게 외우는 것이 아니라, AI가 만든 테이블 설계나 저장 코드를 봤을 때 무엇을 확인해야 하는지 아는 것입니다.

• API 요청 뒤에 데이터가 어디에 남는지 이해합니다.
• 테이블, 컬럼, row, 관계가 각각 어떤 역할을 하는지 잡습니다.
• AI가 만든 데이터베이스 설계와 SQL에서 먼저 봐야 할 지점을 익힙니다.

데이터베이스란

데이터베이스는 서비스가 오래 기억해야 하는 정보를 저장하는 곳입니다. 앞 레슨의 API가 프론트엔드와 백엔드 사이의 대화 통로였다면, 데이터베이스는 그 대화의 결과가 실제로 쌓이는 저장소입니다.

예를 들어 테트리스 게임에서 점수 저장 버튼을 눌렀다고 해보겠습니다. 화면은 API에 “이 사용자의 점수를 저장해줘”라고 요청합니다. 서버는 그 요청을 검사하고, 문제가 없으면 데이터베이스에 한 줄을 추가합니다. 나중에 랭킹 화면을 열면 서버는 다시 데이터베이스에서 점수 목록을 읽어와 화면에 돌려줍니다.

확대

처음에는 “DB를 붙인다”는 말을 너무 어렵게 생각하지 않아도 됩니다. 앱을 껐다 켜도 남아야 하는 정보가 생기면 데이터베이스가 필요해진다고 보면 됩니다.

반대로 화면에 잠깐만 보여주고 사라져도 되는 값은 꼭 데이터베이스에 저장하지 않아도 됩니다. 지금 누른 버튼 상태, 열려 있는 모달, 검색창에 입력 중인 임시 글자 같은 것은 보통 프론트엔드 상태로 충분합니다.

데이터베이스 구조 살펴보기

관계형 데이터베이스는 처음에는 엑셀 파일 여러 개처럼 생각하면 쉽습니다. 같은 종류의 데이터를 한 표에 모으고, 각 줄이 실제 데이터 하나를 나타냅니다.

확대

AI가 데이터베이스 설계를 만들어줬을 때는 먼저 table 이름보다 row의 의미를 봐야 합니다. users 테이블의 row 하나가 “사용자 한 명”인지, scores 테이블의 row 하나가 “한 번의 플레이 기록”인지가 분명해야 합니다. 이 기준이 흐리면 컬럼을 아무리 잘 붙여도 나중에 조회와 권한이 꼬입니다.

관계형 데이터베이스란

관계형 데이터베이스는 여러 테이블을 나누고, 필요한 연결을 만들어 데이터를 관리합니다. 모든 정보를 한 테이블에 몰아넣는 대신, 데이터의 종류별로 표를 나눈 뒤 id로 이어줍니다.

예를 들어 게시판을 만든다면 users와 posts를 나눌 수 있습니다. 사용자는 users 테이블에 저장하고, 게시글은 posts 테이블에 저장합니다. 그리고 게시글 row에는 작성자를 가리키는 user_id를 둡니다.

확대

이렇게 나누면 같은 사용자 정보가 게시글마다 반복되지 않습니다. 사용자의 닉네임이 바뀌어도 users의 한 줄만 바꾸면 되고, 특정 사용자가 쓴 글을 찾을 때도 posts.user_id를 기준으로 조회할 수 있습니다.

SQL이란

SQL은 데이터베이스와 대화하는 언어입니다. 사용자가 버튼을 누르면 프론트엔드는 API 서버에 요청을 보내고, 서버는 데이터베이스에 값을 넣거나 읽거나 수정합니다. 이때 서버 안쪽에서는 보통 SQL이나 SQL을 대신 만들어주는 라이브러리를 통해 데이터베이스와 대화합니다.

이런 기본 행동을 묶어서 CRUD라고 부릅니다. Create, Read, Update, Delete의 줄임말입니다. 앱에서 데이터를 만든다, 읽는다, 고친다, 지운다는 말은 결국 대부분 CRUD 흐름으로 이어집니다.

AI가 SQL이나 데이터 접근 코드를 만들어줬다면 다음 네 가지를 먼저 확인하세요.

• 어느 table을 대상으로 하나요?
• 어떤 column을 읽거나 쓰나요?
• 어떤 조건(WHERE)으로 row를 고르나요?
• 여러 사용자가 있는 서비스에서 다른 사람의 데이터까지 건드릴 위험은 없나요?

특히 UPDATE와 DELETE는 조건을 잘못 잡으면 한 줄이 아니라 여러 줄을 바꿀 수 있습니다. 바이브코딩으로 만든 코드라도 저장, 수정, 삭제 로직은 “어떤 row만 바뀌어야 하는지”를 꼭 물어봐야 합니다.

DB 서비스 살펴보기

데이터베이스를 고를 때는 이름이 두 종류로 섞여 나와서 헷갈릴 수 있습니다. PostgreSQL, MySQL, SQLite는 데이터베이스 엔진에 가깝고, Supabase나 Neon은 데이터베이스를 만들고 운영하기 쉽게 해주는 서비스에 가깝습니다.

처음 프로젝트에서는 독특한 선택지보다 문서와 예제가 많은 메이저 선택지가 유리합니다. AI도 많이 쓰이는 도구일수록 흔한 구조, 에러 메시지, 예제 코드를 더 안정적으로 다룹니다.

다만 “무조건 Supabase를 쓰세요”처럼 외울 필요는 없습니다. 더 중요한 것은 내가 필요한 것이 단순한 로컬 저장인지, 여러 사용자가 공유하는 서버 데이터인지, 로그인과 권한까지 필요한지 구분하는 일입니다.

데이터베이스 설계 순서

AI에게 데이터베이스 설계를 맡길 때는 “테이블 만들어줘”보다 먼저 요구사항과 저장해야 할 데이터를 쉬운 말로 정리해주는 편이 좋습니다. 데이터베이스 설계는 결국 “서비스가 무엇을 해야 하는지”와 “그 일을 하려면 어떤 정보를 기억해야 하는지”에서 나옵니다.

요구사항과 데이터가 선명할수록 좋은 테이블 설계가 나옵니다. 반대로 필요한 기능이 흐릿하면 AI도 화면에 보이는 단어를 대충 컬럼으로 옮기거나, 아직 필요 없는 테이블을 너무 많이 만들기 쉽습니다.

추천 순서는 이렇습니다.

• 서비스가 기억해야 하는 데이터를 먼저 적습니다.
• 비슷한 데이터끼리 table로 묶습니다.
• table마다 row 하나가 무엇을 의미하는지 정합니다.
• 각 table의 column과 타입을 정합니다.
• table끼리 어떤 id로 연결되는지 확인합니다.
• MVP에서 아직 필요 없는 데이터는 빼거나 나중으로 미룹니다.

예를 들어 테트리스 랭킹이라면 처음부터 복잡한 사용자 프로필, 친구 관계, 시즌 랭킹까지 넣을 필요는 없습니다. MVP에서는 scores 테이블에 플레이어 이름, 점수, 생성 시간을 저장하는 정도로 시작할 수 있습니다. 로그인이 붙는 순간 users 테이블과 연결할지 다시 판단하면 됩니다.

AI에게 시켜볼 일

아래 P1 프롬프트는 만들려는 앱의 데이터베이스 초안을 잡을 때 쓸 수 있습니다. 결과를 받은 뒤에는 테이블 이름보다 “row 하나의 의미”와 “어떤 id로 연결되는지”를 먼저 보세요.

내가 만들려는 앱은 "OOO"야.

MVP에서 필요한 기능:
- OOO
- OOO
- OOO

데이터베이스 초안을 잡아줘.

정리 방식:
- 저장해야 하는 데이터 목록
- 필요한 테이블과 각 테이블의 의미
- 각 테이블에서 row 하나가 뜻하는 것
- 주요 컬럼과 타입
- 테이블 사이의 관계
- 지금은 넣지 않아도 되는 테이블이나 컬럼

주의:
- 비개발자도 이해할 수 있게 설명해줘.
- 너무 미래 기능까지 설계하지 말고 MVP 기준으로 줄여줘.
- UPDATE/DELETE에서 어떤 조건을 확인해야 안전한지도 알려줘.

마무리

데이터베이스는 서비스가 계속 기억해야 하는 정보를 담는 곳입니다. API가 요청과 응답의 약속이라면, 데이터베이스는 그 결과가 쌓이는 실제 기억 공간입니다.

처음에는 SQL 문법을 많이 외우기보다 table, row, column, 관계를 읽는 힘이 더 중요합니다. AI가 설계를 대신 만들어줘도 “이 row가 무엇을 뜻하는가”, “어떤 조건으로 읽고 쓰는가”, “다른 사람의 데이터까지 건드리지는 않는가”를 확인할 수 있어야 합니다.

다음 레슨에서는 앱을 만들 때 라이브러리와 프레임워크를 왜 쓰는지, 그리고 프로젝트의 큰 틀과 추가 도구를 어떻게 나눠 생각할지 봅니다.