한 줄 요약

엑셀 대신 DB를 쓰는 이유부터 표와 관계, ACID, SQL 주입 방어, 백업과 무료 DB 고르기까지 — 서비스의 기억을 다루는 법을 훑었다.

1. 오늘 배운 것

지난 회차에서 주방(백엔드)을 봤다면, 오늘은 그 주방의 재료를 어디에 두는가였다.

지금까지 다룬 데이터(목업, 화면에 잠깐 뜬 값)는 컴퓨터의 잠깐 기억(메모리)에만 있었다. 그래서 껐다 켜면 사라진다. 서비스가 되려면 데이터가 남아 있어야 하고, 그 영구 창고가 데이터베이스다.

오늘의 핵심 한 문장 데이터베이스는 서비스의 기억이다. 넣고 꺼내는 코드(SQL)는 AI가 쓰지만, 무엇을 어떤 모양으로 저장할지, 어떤 DB를 고를지, 어떻게 지킬지는 내가 정한다.

1-1. 엑셀로도 되는데 왜 DB인가

작을 때는 엑셀로도 된다. 하지만 세 가지가 다르다.

  엑셀·메모장 데이터베이스
규칙(스키마) 아무 칸에 아무거나 “이 표엔 이름·가격·분류가 들어간다”를 강제한다
속도 커지면 느려지고 멈춘다 수만 건에서도 순식간에 찾는다
동시 사용 같은 줄을 동시에 고치면 덮어쓴다 여러 사람이 동시에 안전하게 쓴다

세 번째가 데이터베이스를 낳은 계기이기도 했다. 두 사람이 엑셀의 같은 행을 동시에 고쳐 하루 주문이 꼬이는 문제 말이다.

비유 두 개면 감이 잡힌다. 도서관(책이 수만 권이어도 원하는 책을 금방 찾는다)과 마법 장난감 상자(“파란색 자동차만 다 꺼내 줘”라고 하면 그것만 꺼내 준다). 핵심은 쌓아 두는 곳이 아니라 원하는 것만 빠르게 찾아 주는 곳이라는 점이다.

1-2. 왜 종류가 많을까 — 60년의 역사

프레임워크와 똑같았다. 매 시대의 병목이 달랐고, 그때마다 새 도구가 나왔다.

시기 무슨 일이 무엇을 풀려고
1960년대 그냥 파일에 쭉 적음 —
1970년 에드거 코드가 “표로 나누고 관계로 잇자” 논문 같은 정보를 여기저기 중복해 적는 문제
1974년 질의 언어 SEQUEL 등장 (뒤에 SQL로) 표에게 말을 걸 방법
1979년 첫 상용 관계형 DB(Oracle) —
2000년대 NoSQL 등장 폭증하는 데이터, 제각각인 형태
오늘날 클라우드 데이터베이스 켜 두고 관리하는 부담

재미있는 곁가지 세 개도 들었다.

  • IBM은 자기 논문을 붙들고 망설였다. 이미 잘 팔리는 제품(IMS)이 있어서 새 아이디어가 그걸 갉아먹을까 봐 주저했고, 그 틈에 신생 회사 오라클이 먼저 시장을 차지했다. 새 기술이 좋아도 기존에 잘 팔리는 걸 가진 쪽은 주저한다 — 기술사에서 반복되는 장면이다
  • SQL은 원래 “시퀄”이었다. SEQUEL이라는 이름이 이미 상표로 등록돼 있어 모음을 빼고 SQL로 줄였다. 그래서 지금도 “에스큐엘”과 “시퀄” 둘 다 쓰인다
  • NoSQL의 No는 “쓰지 말자”가 아니다. 이름이 오해를 낳자 나중에 “Not Only SQL”로 다시 해석됐다

1-3. SQL과 NoSQL — 고르는 게 아니라 나눠 쓴다

  • SQL — 관계형 데이터베이스를 다루기 위한 언어. 엑셀 같은 표, 규칙이 엄격하고, 관계가 분명한 데이터와 정확성(돈·주문)에 강하다
  • NoSQL — 더 유연하고 다양한 저장 방식을 함께 쓰는 것. 모양이 자유롭고, 대규모·빠르게 변하는 데이터에 강하다

NoSQL도 한 종류가 아니라 넷으로 갈린다. 문서(MongoDB), 키-값(Redis), 컬럼(Cassandra), 그래프(Neo4j). 그래프 DB가 “친구의 친구”를 따라가는 데 최적이라 소셜 네트워크가 쓰고, 키-값은 너무 단순해서 오히려 초고속이라 장바구니나 세션에 쓴다.

그래서 결론이 “하나를 고집하기보다 서비스의 부위별로 나눠 쓰는 방식이 일반적”이었다. 넷플릭스도 우버도 둘 다 쓴다. 다만 첫 서비스의 무난한 기본값은 SQL, 그중 PostgreSQL이다. 자료가 가장 많고 나중에 곤란해질 일이 적다.

1-4. 데이터의 모양 — 표, 관계, 키, 그리고 정규화

관계형 데이터베이스는 결국 표다. 표 하나 = 한 종류, 행 = 한 건, 열 = 항목.

같은 걸 두 번 적지 않는 것이 설계의 핵심이었다. “홍길동이 초코케이크를 샀다”를 한 줄에 다 적으면, 주문이 100건일 때 홍길동 주소가 100번 적힌다. 이사 가면 100군데를 다 고쳐야 하고 하나라도 놓치면 데이터가 어긋난다.

그래서 성격이 다른 것끼리 표를 나누고, 번호로 가리킨다. 주문 표는 이름·주소를 다시 적지 않고 “1번 회원”이라고만 쓴다. 이 번호를 키(key)라고 부른다. 이렇게 중복을 걷어내는 정리정돈이 정규화다.

관계는 대부분 두 모양이다.

  • 일대다(1:N) — 회원 1명이 주문 여러 건. 주문 표에 “누구의 주문인지” 칸 하나만 넣으면 끝
  • 다대다(N:M) — 학생 1명이 여러 수업을, 수업 1개도 여러 학생이. 이건 연결 표를 하나 새로 만들어야 한다. 그러면 N:M이 1:N 두 개로 풀린다

판단은 이 한 문장으로 된다. “A 하나가 B 여럿을, 동시에 B 하나도 A 여럿을 갖나?”

1-5. SQL 구경 — 거의 영어 문장이다

SELECT 이름, 가격 FROM 상품 WHERE 분류 = '케이크';

풀어 읽으면 “상품 표에서(FROM) 분류가 케이크인 것들의(WHERE) 이름과 가격을 줘(SELECT)”.

넣고·고치고·지우는 것도 단어만 바뀐다. SELECT(조회) · INSERT(넣기) · UPDATE(고치기) · DELETE(지우기). 이 넷이 지난 회차에 배운 CRUD다. 대부분의 서비스는 결국 이 네 동작의 반복이다.

외울 필요는 없었다. “아, 이 표에서 뭘 꺼내는(넣는) 거구나”를 알아보는 정도면 충분하다.

1-6. 틀리면 큰일인 데이터 — 트랜잭션과 ACID

A가 B에게 만 원을 보낸다. 컴퓨터가 할 일은 둘이다. ① A에서 빼기 ② B에 넣기. 그런데 ①만 하고 ② 직전에 정전이 나면? 만 원이 증발한다.

그래서 데이터베이스는 여러 동작을 하나의 묶음(트랜잭션)으로 처리한다. 원칙은 하나 — 전부 되거나, 전부 안 되거나. 중간에 반쪽만 남는 상태는 아예 존재하지 않는다. 이 성질을 포함한 네 약속을 묶어 ACID라고 부른다.

  뜻
A 원자성 반쪽 실행은 없다
C 일관성 규칙에 어긋난 상태로 끝나지 않는다
I 고립성 동시에 여러 명이 만져도 꼬이지 않는다
D 지속성 됐다고 하면 정전이 나도 남는다

외울 건 없고 감 하나면 된다. 돈·주문·예약처럼 틀리면 큰일인 데이터는 이 성질이 강한 SQL DB가 안전하다.

그리고 실전에서 요구할 문장도 하나 배웠다 — “동시에 두 명이 마지막 하나를 요청하는 상황도 테스트하고 안전하게 처리해 줘.”

ACID는 백업이 아니다. 실수로 지운 걸 되돌려 주지는 않는다.

1-7. 데이터가 커지면 — 색인과 마이그레이션

색인(index)은 두꺼운 전공책 맨 뒤의 찾아보기다. “삼투압 → 245쪽”처럼. 그 덕에 처음부터 한 장씩 넘기지 않는다. 자주 찾는 항목에 색인을 만들어 두면 수백만 건에서도 순식간에 찾는다. 없으면 처음부터 전부 뒤진다.

다만 공짜가 아니다. 넣고 고칠 때마다 색인도 갱신해야 하고 공간도 든다. 그래서 많이 거는 게 아니라 실제로 자주 쓰는 검색에 최소한만 거는 게 빠른 DB다.

비전공자의 실전 팁이 좋았다. AI에게 “색인 넣어줘”만 하지 말고, “사용자는 자기 주문만 최근순 20개 본다”처럼 실제 화면의 질문을 문장으로 주는 것.

마이그레이션은 이미 데이터가 들어 있는 DB의 구조를 안전하게 바꾸는 작업이다. “DB 구조 변경을 Git처럼 이력으로 관리하는 것”이라 생각하면 된다.

칸을 삭제하는 변경은 그 안의 데이터가 영구히 사라질 수 있다. 구조를 바꾸기 전엔 반드시 백업.

1-8. 사용자를 다루기 — 회원 표와 로그인 유지

로그인·회원가입은 화면 기능 같지만 뿌리는 데이터다.

  • 회원가입 = 회원 표에 행 하나 넣기(Create)
  • 로그인 = 그 이메일로 행을 찾아(Read) 대조

결국 CRUD의 조합이다. 여기서 꼭 지킬 세 가지.

  1. 비밀번호는 절대 원문으로 저장하지 않는다. 칸 이름을 password가 아니라 password_hash로 두면 스스로 상기하기 좋다
  2. 이메일은 유일(unique)하게. 같은 이메일로 두 번 가입되지 않게 제약을 건다
  3. 필요한 것만 모은다. 안 받아도 되는 정보는 처음부터 안 받는 게 가장 안전한 보관이다

로그인 상태를 유지하는 방식은 두 갈래다. 쿠키는 그 증명을 실어 나르는 상자이고, 그 상자에 무엇을 담느냐에서 갈린다.

  • 세션 — 서버가 상태를 기억하고, 브라우저엔 번호표(세션 ID)만 준다. 저장소에서 지우면 즉시 무효라 강제 로그아웃이 쉽다
  • 토큰(JWT) — 서버가 서명한 증명서를 통째로 준다. 서버가 기억하지 않아 확장에 강하지만 즉시 무효화가 어렵다

토큰 내용은 암호가 아니라 그냥 인코딩이다. 가진 사람은 누구나 열어 본다. 서명이 막는 건 못 바꾸게이지 못 보게가 아니다. 그래서 민감정보를 토큰에 넣으면 안 된다.

그리고 오늘 가장 실용적이었던 결론. 인증은 직접 만들지 말 것. MDN조차 세션 관리를 직접 구현하지 말라고 못 박는다. 검증된 Auth 서비스에 맡기고, 우리 몫은 “무슨 방식인지 이해하고 믿을 만한 도구에 맡기는 판단”까지다.

1-9. 지키기 — SQL 주입, 개인정보, 백업

SQL 주입. 프로그래머 사이에 전설적인 만화가 있다. 아들 이름이 Robert'); DROP TABLE Students;-- 이라서 학생 기록이 전부 지워졌다는 이야기다. 이름에 DB 명령어처럼 생긴 문자가 들어 있었고, 프로그램이 그걸 이름이 아니라 명령으로 실행한 것이다. 25년 넘게 보안 위협 1위권을 지키는 공격이다.

방어법은 확실하다. 명령(레시피)과 사용자 입력(재료)을 섞지 않는 것. 자리표(?)를 미리 비워 둔 명령을 만들고 입력값은 따로 건네면, DB가 그 입력을 무조건 데이터로만 취급한다. 이걸 파라미터화 쿼리라고 한다.

옛날이야기가 아니다. 2015년 영국 통신사 TalkTalk이 이 공격으로 뚫렸는데, 공격자는 십대들이었고 이용된 구멍은 3년 반 전에 이미 패치가 나와 있던 것이었다. 규제기관의 총평이 짧고 매서웠다 — “가장 기본적인 보안 조치조차 하지 않았다.”

대부분의 큰 사고는 새로운 마법이 아니라, 오래전에 답이 나온 기본을 안 지켜서 벌어진다.

개인정보. 데이터는 모아 두는 순간 자산이자 책임이 된다. 원칙은 네 개였다. 덜 모으고(최소 수집), 비밀번호는 해시하고, 민감정보는 남에게 맡기고(결제는 PG사에), 목적 밖으로 쓰지 않는다. 한 줄로는 이렇다 — 가장 안전한 데이터는 애초에 안 가진 데이터다.

백업. 해커가 없어도 데이터는 사라진다. 실수 한 번으로.

  • 픽사 「토이 스토리 2」 — 잘못된 명령으로 영화 파일이 눈앞에서 지워지는데, 백업 시스템도 한 달째 고장 나 있었다. 영화를 살린 건 재택근무하던 직원이 집 컴퓨터에 두었던 2주 전 사본이었다
  • GitLab(2017) — 여러 겹의 백업이 모두 조용히 고장 나 있어 6시간치를 잃었다
  • Ma.gnolia(2009) — 백업을 원본과 같은 시스템에 뒀다가 함께 사라져 서비스가 문을 닫았다

그래서 3-2-1 규칙이다. 3벌(원본 1 + 사본 2), 2종(서로 다른 매체), 1벌은 다른 장소에. 그리고 가장 중요한 것 — 복구가 진짜 되는지 가끔 확인한다. 열어본 적 없는 백업은 백업이 아니다.

1-10. 무엇을 고를까 — 무료 DB, 로컬과 클라우드

무료로 진짜 데이터베이스를 쓸 수 있다. 다만 전제 하나. 무료 티어는 배우기·초기 버전용이지 큰 규모의 운영용이 아니다.

시작 전에 확인할 것도 네 가지였다. 용량 한도, 미사용 시 일시정지, 자동 백업 포함 여부, 정책 변경 가능성. 특히 자동 백업은 무료 요금제에 없는 경우가 많다.

클라우드만 있는 게 아니라 내 컴퓨터에 직접 설치하는 길도 있다.

  • SQLite — 설치도 서버도 없다. DB 전체가 파일 하나다. 가장 가볍게 시작하기 좋다
  • PostgreSQL · MySQL — 회사들이 실제로 쓰는 그 오픈소스 DB를 내 컴퓨터에 무료로
  • Docker — 설치가 번거로우면 명령 한 줄로 띄우고, 필요 없으면 통째로 지운다

흔한 흐름은 “로컬에서 만들고 → 세상에 낼 때 클라우드로”다. 개발·학습·오프라인은 로컬, 24시간 남에게 열려면 클라우드.

1-11. 오늘의 질문 — 앞으로 DB는 어떻게 될까

수업을 들으며 든 질문이다. 지금은 다들 클라우드 DB를 쓰는데, 앞으로는 어떻게 될까. 정답이 있는 질문은 아니라서, 지금 보이는 흐름과 그래도 남을 것으로 나눠 적어 둔다.

흐름 ① 관리 부담이 계속 사라지는 쪽으로. 직접 사서 관리 → 클라우드에서 빌리기 → 안 쓰면 0으로 줄어드는 방식까지 왔다. 무료 DB 비교표에 나온 “유휴 상태에서 scale-to-zero”가 그 예다. 켜 두는 것 자체를 신경 쓰지 않는 방향이다.

흐름 ② DB가 백엔드를 흡수하는 쪽으로. Supabase처럼 DB 하나가 로그인·파일 저장·API까지 함께 준다. 그래서 “어떤 DB를 고를까”가 점점 “어떤 백엔드를 고를까”에 가까워진다.

흐름 ③ 사람의 일이 옮겨 가는 쪽으로. SQL을 AI가 대신 쓰면서, 내 일은 질의를 작성하는 것에서 무엇을 저장할지 설계하고 결과를 검증하는 것으로 옮겨 간다. 오늘 수업이 문법을 안 가르치고 표와 관계를 가르친 이유가 이것 같다.

그래도 남을 것. 도구가 편해질수록 오히려 사람에게 더 남는 것들이 있다. 데이터의 모양을 정하는 판단, 틀리면 큰일인 데이터를 알아보는 감각(ACID), 개인정보에 대한 책임, 그리고 백업. 이건 어떤 서비스로 옮겨 가도 대신해 주지 않는다.

한 가지 반대 방향도 있다. 편해지는 것과 공짜인 것은 다른 문제다. 오늘 자료에서도 한 서비스는 무료 티어를 없앴다. “쉬워진다”가 “싸진다”를 뜻하지는 않는다.

(이 항목은 내 정리와 추측이라, 나중에 다시 읽을 때 얼마나 맞았는지 확인해 볼 것.)

왜 필요한가

오늘 배운 것 중 내가 직접 타이핑할 SQL은 거의 없다. 코드는 AI가 쓴다. 그런데 AI에게 무엇을 요구할지는 알아야 한다.

  • 표를 어떻게 나눌지 → 정규화와 관계를 알아야 판단한다
  • 파라미터화 쿼리로 처리해 달라 → SQL 주입을 알아야 요구한다
  • 이 요금제에 자동 백업이 있나 → 백업 참사를 알아야 확인한다

오늘의 산출물은 코드가 아니라 “내 서비스가 무엇을 기억해야 하는지”를 그린 데이터 설계도였다.

2. 실습 / 코드 — 받은 과제와 진행 방식

이 글을 쓰는 시점에는 아직 만들지 못했다. 아래는 수업에서 받은 과제와 진행 순서를 정리해 둔 것이고, 실제로 만든 뒤에 결과를 이 절에 덧붙인다.

왜 Todo 앱인가

할 일을 추가·조회·완료·삭제하는 앱이라 CRUD의 교과서다. 그리고 데이터가 DB에 저장돼 껐다 켜도 남는지를 눈으로 확인할 수 있다.

방식은 에이전틱이다. 목표(PRD)를 주면 에이전트가 계획·설치·구현을 하고, 나는 검토·판단·수정을 한다.

1부 — PRD 먼저, 그다음 DB 구조 설계받기

[무엇] 내 컴퓨터에서 도는 Todo(할 일) 앱.
[기본 기능(CRUD)] 할 일 추가 / 목록 보기 / 완료 표시 / 삭제
[저장] 데이터는 내 컴퓨터의 무료 DB에 저장 (껐다 켜도 남기)
[내가 넣고 싶은 기능] <- 여기에 1~2개 직접 적기
  예: 마감일 표시 / 카테고리(태그) / 오늘 할 일만 보기 / 검색
[규칙] 무료 도구만. 비밀값은 .env로.

코드보다 DB 구조를 먼저 받는 것이 핵심이었다.

위 PRD로 만들 Todo 앱의 DB 구조(어떤 표·열·관계)를 먼저 설계해서
구조도로 그려 보여줘. 내 커스텀 기능도 반영해서.
로컬 무료 DB(예: SQLite)를 쓸 거야.

여기서 앞서 배운 게 바로 쓰인다. 태그를 넣으면 todos와 tags가 다대다가 되어 todo_tags 연결 표가 필요하다. 그 그림이 맞게 나왔는지 내가 읽고 확인하는 것이 내 일이다.

2부 — 로컬에 만들어 돌리기

이 PRD와 방금 합의한 DB 구조로 Todo 앱을 만들어 줘.
데이터는 로컬 SQLite 파일 하나(todo.db)에 저장하고,
브라우저에서 localhost로 열리게 해 줘.
.env와 todo.db는 .gitignore에 넣어.
먼저 전체 계획을 보여주고, 각 단계 끝에 뭘 확인하면 되는지 알려 줘.

에이전트가 계획→설치→파일 생성→DB 만들기까지 스스로 한다. 내가 할 일은 셋이었다.

  1. 계획 한 번 읽기 — PRD와 맞는지
  2. 위험한 명령은 승인 — 이 프로젝트 폴더 안인지 확인
  3. 잘 되던 순간마다 Git 커밋 — 되돌릴 지점 만들기

통과 기준도 명확했다. 할 일을 추가하면 목록에 뜨고, 새로고침·앱 재시작 후에도 남는다. 그리고 DB 뷰어로 todo.db를 열어 todos 표에 행이 실제로 쌓였는지 확인한다.

3부 — 같은 앱을 클라우드로

같은 Todo 앱을 로컬 SQLite 대신 Supabase(무료 클라우드 Postgres)에
저장하도록 바꿔 줘. 접속 키는 .env로 빼고,
RLS(행 수준 보안)를 켜서 허용된 접근만 되게 해 줘.

RLS를 켜지 않으면 공개 키로 누구나 데이터에 접근할 수 있다. 지난 회차에서 배운 그 지점이 그대로 이어졌다.

자주 막히는 곳

증상 확인 / 해결
npm install에서 better-sqlite3 빌드 에러 네이티브 모듈이라 빌드 도구가 필요. 에러를 그대로 에이전트에 주고 “내 OS 기준 빌드 도구를 설치·확인해 줘”
포트가 already in use 이전 서버가 아직 떠 있음. 그 창을 끄거나 다른 포트로
추가했는데 새로고침하면 사라짐 화면에만 있고 DB엔 안 들어감. “추가한 할 일을 DB에 저장하고 다시 읽어오게 해 줘”
코드 고쳤는데 반영 안 됨 개발 서버를 껐다 켜기 (특히 .env 수정 후)
todo.db를 GitHub에 올려버림 .gitignore에 추가. 이미 커밋했다면 “git 이력에서도 빼 줘”까지

같은 걸 계속 못 고치면 마지막으로 되던 지점으로 되돌리고 문제를 잘게 쪼개 다시 시킨다.

만들고 나서 이 절에 덧붙일 것

  • PRD에 넣은 나만의 기능 (마감일 · 태그 · 검색 중 무엇을, 왜)
  • 에이전트가 그려 준 DB 구조도 — 표와 관계가 1-4에서 배운 대로 잡혔는지
  • 완성 화면, 그리고 앱을 껐다 켜도 데이터가 남는 장면
  • 실제로 막힌 지점과 해결 (4번 표에 추가)

3. 그림 / 스크린샷

한 덩어리 데이터를 표로 나누고 번호로 잇는 방식과 일대다, 다대다 관계
그림 1. 표로 나누고 번호로 가리킨다 — 그리고 관계의 두 모양
계좌 이체가 반쪽만 실행되는 문제와 트랜잭션으로 묶어 막는 방식, ACID 네 가지
그림 2. 전부 되거나, 전부 안 되거나 — 트랜잭션과 ACID
사용자 입력을 명령문에 이어 붙이면 명령으로 실행되는 문제와 파라미터화 쿼리로 막는 방식
그림 3. 레시피와 재료를 섞지 않는다 — SQL 주입 방어
백업의 3-2-1 규칙과 개인이 실천하는 예
그림 4. 백업의 3-2-1 규칙

4. 막혔던 점과 해결

막힌 지점 궁금했던 이유 정리한 답
엑셀로도 되는데 왜 굳이 DB인가? 작은 서비스면 표 하나로 충분해 보였다 셋이 다르다. 규칙을 강제해 뒤죽박죽을 막고, 수만 건에서도 빠르고, 여러 사람이 동시에 써도 안 꼬인다. 특히 세 번째는 엑셀로는 아예 안 되는 영역이고, 애초에 DB가 태어난 이유이기도 하다
SQL과 NoSQL 중 하나를 골라야 하나? 비교표를 보니 우열을 가려야 할 것 같았다 고르는 게 아니라 나눠 쓴다. 큰 서비스도 부위별로 둘 다 쓴다. 다만 첫 서비스는 SQL(PostgreSQL)이 기본값이고, “소셜 관계 중심이다” “초고속 임시 저장이 필요하다” 같은 특별한 이유가 생겼을 때 NoSQL을 후보에 올리면 된다
쿠키에는 무엇을 담아야 하나? 로그인 정보를 담는다고만 알고 있었다 쿠키는 상자일 뿐이고, 안에 무엇을 담느냐가 갈린다. 세션 방식이면 세션 ID(번호표)만, 토큰 방식이면 서명된 토큰을 담는다. 어느 쪽이든 진짜 민감한 정보 자체를 담지는 않는다. 쿠키는 사용자가 조작할 수 있고, 토큰 내용은 누구나 열어 볼 수 있기 때문
로컬 DB와 클라우드 DB 중 언제 뭘 쓰나? 둘 다 무료라 기준이 없었다 개발·학습·오프라인은 로컬, 남에게 24시간 열려면 클라우드. 흔한 흐름은 로컬에서 만들고 낼 때 클라우드로 바꾸는 것이라, 처음부터 “나중에 클라우드 DB로 바꿀 수 있게 해 줘”라고 요구해 두면 편하다

5. 스스로 확인하기

  • 엑셀 대신 DB를 쓰는 이유 세 가지를 말할 수 있는가?
  • 한 덩어리 데이터를 표로 나눠야 하는 이유를 예로 설명할 수 있는가?
  • 1:N과 N:M을 구분하는 질문 한 문장을 말할 수 있는가?
  • SELECT … FROM … WHERE … 한 줄을 내 서비스 예로 풀어 말할 수 있는가?
  • 트랜잭션이 필요한 데이터의 예를 셋 댈 수 있는가?
  • 색인이 왜 빠른지, 그리고 왜 아무 데나 걸면 안 되는지 설명할 수 있는가?
  • SQL 주입을 막는 방법을 AI에게 요구할 문장으로 쓸 수 있는가?
  • 세션 방식과 토큰 방식의 차이를 “즉시 로그아웃” 기준으로 설명할 수 있는가?
  • 3-2-1 규칙을 내 상황에 대입해 말할 수 있는가?
  • 내가 쓰는 무료 DB에 자동 백업이 포함되는지 아는가?

6. 더 알아볼 것

  • Todo 앱 실습 먼저 끝내기 — 2번의 순서대로 PRD → DB 구조 → 로컬 SQLite → Supabase
  • 내 무료 DB 요금제에 자동 백업이 포함되는지 실제로 확인하기 (없으면 직접 백업 주기 정하기)
  • 만들어 둔 서비스의 표 구조를 다시 보며 “이 정보, 여기저기 똑같이 적히고 있진 않나?” 점검하기
  • Supabase RLS 정책을 직접 읽고 무엇을 허용·차단하는지 설명해 보기
  • 색인을 걸기 전후로 조회 속도가 얼마나 달라지는지 직접 재 보기
  • NoSQL 네 갈래 중 하나를 골라 어떤 서비스가 왜 쓰는지 사례로 살펴보기
  • 지난 회차부터 밀린 숙제: PowerShell 기초, 비동기를 코드로 확인하기

참고 자료