A-1: 데이터베이스 개념과 첫 SELECT — 표·행·열, 그리고 의미 있는 첫 조회

안녕하세요, 데이터베이스의 세계로 함께 가는 홍순구 튜터입니다. 다시 만나서 반가워요.

지난 시간엔 우리 컴퓨터 안에 Oracle 데이터베이스를 띄우고, SELECT * FROM member 한 줄로 회원 8명을 조회하는 데 성공했죠. 그때는 "환경이 살아있다"를 확인하는 게 목표라, 결과가 화면에 뜨는 것만 즐겨도 충분했습니다.

오늘은 한 발 더 들어갑니다. 그 한 줄이 정확히 무슨 뜻이었는지, 화면에 떴던 그 표는 데이터베이스 안에서 어떻게 생긴 것인지를 제대로 알아볼 거예요. 이름 없이 슬쩍 지나갔던 테이블·행·열을 오늘 정식으로 만나고, 회원을 한 명 한 명 구분해주는 기본키라는 개념도 처음 마주합니다.

그리고 SELECT * 로 "그냥 다 보여줘"만 했던 지난 시간과 달리, 오늘은 "이 열만 골라서 보여줘" 같은 의미 있는 조회를 직접 작성해봅니다.

 오늘의 여정 — 표 한 장을 제대로 읽는 법

  ① 관계형 모델 — 데이터를 '표' 모양으로 담는다
  ② 테이블 · 행(row) · 열(column) — 표를 이루는 세 이름
  ③ 기본키(primary key) — 행 하나를 콕 집어 구분하는 열
  ④ 'SELECT *' 해부 — 그 첫 줄이 정확히 무슨 뜻이었나
  ⑤ 원하는 열만 골라 조회 — 모든 열 말고 필요한 열만
  ⑥ 두 표의 연결 — 회원과 게시물, 관계형의 '관계' 맛보기
        │
        ▼
   "이 조회는 정확히 8건" 을 눈으로 검산하기까지

지난 시간 띄워둔 환경 그대로 이어서 갑니다. 혹시 컨테이너를 껐다면 docker compose up -d 로 다시 켜고 시작할게요.

💡 오늘 수업의 핵심 — "데이터는 표(테이블) 모양으로 담기고, SELECT 로 원하는 만큼 골라 꺼낸다"

🎯 학습 목표

• 관계형 데이터베이스가 데이터를 표(테이블) 형태로 담는다는 것을 이해하고, 테이블·행(row)·열(column)을 구분할 수 있다.
• 각 행을 유일하게 구분하는 기본키(primary key) 가 왜 필요한지 설명할 수 있다.
• SELECT * 와 SELECT 컬럼명 의 차이를 알고, 원하는 열만 골라 조회하는 SQL 을 직접 작성할 수 있다.

Step 1: "데이터베이스, 데이터를 어떤 모양으로 담을까?"

지난 시간에 우리는 데이터베이스를 "데이터를 담아두는 거대한 창고", 그 창고를 관리하는 프로그램을 DBMS 라고 불렀어요. 그리고 우리가 쓰는 DBMS 가 Oracle 이고요.

오늘 던질 질문은 이겁니다. 그 창고는 데이터를 어떤 모양으로 담을까요?

여러분이 친구 명단을 정리한다고 생각해 보세요. 아마 엑셀 같은 표를 떠올릴 겁니다. 맨 윗줄에 이름·전화번호·생일을 적고, 그 아래로 한 명씩 가로로 채워 넣죠. Oracle 도 똑같아요. 데이터를 이런 표 모양으로 차곡차곡 담습니다.

이렇게 데이터를 표 형태로 담는 방식을 관계형 모델(relational model) 이라고 하고, 이 방식을 따르는 DBMS 를 관계형 데이터베이스(RDBMS, Relational DBMS) 라고 불러요. Oracle 도, 많이 들어보셨을 MySQL 도 모두 관계형 데이터베이스입니다. 세상에서 가장 널리 쓰이는 방식이죠. ★빈출 — 이 "관계형 데이터베이스와 SQL 개요" 가 SQLD 시험 2과목의 출발점이기도 해요.

왜 하필 표일까요? 표는 누구나 한눈에 읽습니다. 가로줄과 세로 칸으로 가지런히 정렬되어 있어서, "누가 어떤 값을 가지고 있는지" 가 명확하거든요. 데이터를 어지럽게 늘어놓는 대신 격자에 맞춰 담는 것, 그게 관계형 데이터베이스의 출발점입니다.

💡 한 줄 정리

관계형 데이터베이스(RDBMS)는 데이터를 표(테이블) 모양으로 담는다. Oracle 과 MySQL 이 그 대표다.

Step 2: "표 하나를 뜯어보자 — 테이블·행·열"

말로만 표라고 하면 감이 안 오죠. 지난 시간에 봤던 그 회원 조회를 다시 띄워봅시다.

SELECT * FROM member;

실행하면 회원 8명이 이렇게 돌아옵니다.

이 표를 뜯어보면 세 가지 이름이 나옵니다. 지난 시간에 슬쩍 봤던 그 이름들을 이제 정식으로 만나요.

• 테이블(table) — 표 전체를 가리킵니다. 우리가 본 건 member(회원) 테이블이에요.
• 행(row) — 가로로 놓인 한 줄. 회원 한 명이 한 행을 차지합니다. 8명이니까 8행이죠. '레코드(record)'라고도 불러요.
• 열(column) — 세로로 놓인 한 칸. username·nickname 처럼 어떤 항목인지를 나타냅니다. '속성(attribute)'이라고도 합니다.

엑셀에 그대로 대응돼요. 시트 하나가 테이블, 가로줄이 행, 세로 칸이 열입니다.

   세로 한 칸이 '열(column)'              가로 한 줄이 '행(row)'
   ┌───────────┬──────────┬──────────┐
   │ member_id │ username │ nickname │   ← 맨 윗줄 = 열 이름표
   ├───────────┼──────────┼──────────┤
   │     1     │ jaehoon  │   ...    │   ← 한 줄(행) = 회원 한 명
   │     2     │ minji    │   ...    │
   └───────────┴──────────┴──────────┘
         ↑
     열 하나 = 모든 회원의 같은 항목 (예: username 칸 전체)

자기소개(bio)를 안 쓴 회원은 (빈칸)으로 남아 있죠? 이 빈칸을 데이터베이스에서 뭐라고 부르고 어떻게 다루는지는 SQL 을 더 깊이 배우면서 차차 만납니다. 오늘은 "비어 있을 수도 있다" 정도만 봐두세요.

💡 한 줄 정리

표 전체가 테이블, 가로줄 하나가 행(row), 세로 칸 하나가 열(column)이다. 회원 8명 = 8행, 항목 4개 = 4열.

Step 3: "한 명 한 명 어떻게 구분하지? — 기본키"

표를 보다가 이런 질문이 떠오를 수 있어요. 수많은 회원 중에서 특정 한 명을 콕 집어내려면 무엇으로 가리켜야 할까요?

이름(nickname)으로 가리키면 될까요? 위험합니다. 인스타그램 회원이 수백만 명이라면 '김민지'라는 이름을 가진 사람이 여럿일 수 있어요. "김민지를 찾아줘" 하면 데이터베이스가 누구를 줘야 할지 알 수 없죠.

그래서 표마다, 각 행을 절대 겹치지 않게 구분해주는 열 을 하나 둡니다. 이걸 기본키(primary key), 줄여서 PK 라고 불러요. member 테이블에서는 member_id 가 그 역할을 합니다.

SELECT member_id, username FROM member;

member_id 는 1, 2, 3 … 8 처럼 회원마다 다른 값을 가지고, 절대 겹치지 않으며, 비어 있는 법도 없습니다. 그래서 "member_id 가 3인 회원"이라고 하면 단 한 명, 박승우만 정확히 가리켜져요.

비유하자면 주민등록번호나 학번 같은 거예요. 같은 반에 '김민준'이 둘 있어도 학번은 절대 안 겹치니까, 학번만 대면 누구인지 단번에 정해지죠. 기본키가 바로 그 학번 역할입니다.

기본키는 두 가지 성질을 맛보기로 기억해두면 좋아요. 겹치지 않는다(유일하다), 그리고 반드시 값이 있다(비어 있을 수 없다). 이 성질을 더 정밀하게 따지는 건 다음 시간 데이터 모델링에서 본격적으로 다룹니다.

💡 한 줄 정리

기본키(primary key, PK)는 각 행을 유일하게 구분하는 열이다. member 표에서는 member_id. 주민번호·학번처럼 겹치지 않고 비어 있지 않다.

Step 4: "그래서 첫 SELECT 가 무슨 뜻이었나 — SELECT * 해부"

이제 지난 시간 그 한 줄로 돌아가봅시다. 우리가 무심코 실행했던 이 문장이요.

SELECT * FROM member;

한 토막씩 끊어 읽으면 뜻이 또렷해집니다.

• SELECT — "조회해라", 즉 무엇을 보여줄지 고르는 명령이에요.
• 별표(*) — "모든 열". 별표 하나가 "이 표의 열 전부"를 뜻합니다.
• FROM member — "member 테이블에서".

이어 붙이면 "member 테이블에서 모든 열을 보여줘" 가 됩니다. 그래서 결과로 회원 8명(8행)이, member_id·username·nickname·bio 네 개 열을 모두 달고 돌아온 거예요.

SQL 의 매력이 여기 있어요. 거의 영어 문장처럼 읽힙니다. SELECT(선택해라) … FROM(~로부터). 질문(SQL)을 던지면 데이터베이스가 답(결과)을 돌려주는, 지난 시간에 봤던 그 흐름 그대로입니다.

💡 한 줄 정리

SELECT * FROM member 는 "member 테이블에서 모든 열을 보여줘"라는 뜻이다. 별표(*)가 '모든 열'을 가리킨다.

Step 5: "다 말고 원하는 열만 — 컬럼 골라 조회"

별표(*)는 모든 열을 가져옵니다. 그런데 늘 전부가 필요한 건 아니에요. 회원 목록에서 영문 아이디와 한글 이름만 보고 싶을 때가 있죠.

그럴 땐 별표 대신 원하는 열 이름을 콤마로 나열 하면 됩니다.

SELECT username, nickname FROM member;

결과를 보면 username 과 nickname 두 열만 나왔어요. member_id 와 bio 는 빠졌죠. 마치 명함첩 전체에서 "이름과 전화번호만" 뽑아 보는 것과 같아요. 필요한 정보만 골라 보는 겁니다.

여기서 중요한 포인트 하나. 행 수는 여전히 8 입니다. 회원을 거른 게 아니라 열만 골랐으니까요. 열을 고르는 것과 회원(행)을 고르는 것은 전혀 다른 일이에요. 이 차이를 지금 확실히 잡아두면 나중에 헷갈리지 않습니다.

열 순서도 마음대로 바꿀 수 있어요. SELECT nickname, username FROM member 라고 쓰면 한글 이름이 먼저 나옵니다.

⚠️ 함정 — 배울 때는 SELECT * 가 편하지만, 실무에서는 필요한 열만 콕 집어 쓰는 걸 권장해요. 늘 모든 열을 가져오면 안 쓸 데이터까지 함께 옮겨오느라 느려질 수 있거든요. "필요한 열만 고르는" 습관을 지금부터 들여두면 좋습니다.

이게 바로 지난 시간에 예고했던 "원하는 열만 골라 보기"의 정체예요. 그럼 "원하는 회원만"(특정 조건에 맞는 행만) 골라 보는 건 어떻게 할까요? 그건 조건을 거는 법을 따로 배워야 하는데, 그 본격적인 조회는 SQL 을 직접 짜기 시작하는 다음 카테고리에서 깊게 다룹니다.

💡 한 줄 정리

SELECT username, nickname FROM member 는 원하는 두 열만 골라 조회한다. 열을 고르는 것은 행을 거르는 것과 다르다 — 행 수는 그대로 8.

Step 6: "회원 말고 게시물도 — 두 번째 테이블과 '관계' 맛보기"

우리 데이터베이스에는 회원만 있는 게 아니에요. 회원들이 올린 게시물 도 있습니다. 표가 하나 더 있다는 뜻이죠.

SELECT * FROM post;

게시물 12개가 나왔어요. post 테이블의 열은 post_id(게시물 기본키)·member_id·caption(글 내용)·created_at(작성일)입니다.

여기서 흥미로운 점 하나. post 표에 member_id 열이 있죠? 이건 "이 게시물을 누가 썼나"를 가리킵니다. 1번 게시물의 member_id 가 1이니까, 1번 회원(jaehoon)이 쓴 글이에요. 2·3번 게시물도 member_id 가 1이니 역시 jaehoon 의 글이고요.

   post 표 (일부)
   post_id   member_id   caption
   ───────   ─────────   ──────────────────
      1          1        첫 게시물입니다 #안녕
      2          1        오늘도 코딩 #개발
      4          2        아침 커피 한 잔 #카페
                 │
                 └──▶ 이 숫자가 member 표의 member_id 를 가리킨다
                      (1 = jaehoon, 2 = minji …)

이게 바로 관계형 데이터베이스의 '관계'예요. 회원 정보를 게시물마다 다시 적는 대신, 회원은 member 표에·게시물은 post 표에 따로 담아두고, member_id 라는 열로 둘을 이어주는 거죠. 이렇게 다른 표를 가리키는 열을 외래키(foreign key) 라고 부르는데, 정식 설계 이야기는 다음 시간으로 미뤄둘게요.

데이터를 살펴보면 재미있는 구석이 있어요. post 표의 member_id 에 7번과 8번은 한 번도 안 나옵니다. 즉 7번(taeyang)과 8번(narae)은 게시물이 한 개도 없는 회원이에요. 나중에 회원과 게시물을 연결해서 보는 '조인'을 배울 때, 이렇게 게시물이 0개인 회원들이 아주 중요한 연습 상대가 됩니다. 지금은 "이런 경계 사례가 일부러 들어있구나" 정도만 봐두세요.

💡 한 줄 정리

게시물은 post 테이블에 따로 담기고, post.member_id 가 "누가 썼는지"를 member 표와 연결한다. 이 표끼리의 연결이 관계형의 '관계'다.

Step 7: "내 결과를 믿을 수 있나 — 우리 데이터셋과 검산 습관"

마지막으로, 앞으로 이 강의 내내 우리와 함께할 이 데이터에 대해 짧게 이야기할게요.

눈치채셨겠지만 우리 데이터셋은 일부러 작게 만들었어요. 회원 8명, 게시물 12개죠. 왜 이렇게 작을까요? 결과를 눈으로 셀 수 있게 하기 위해서예요.

"이 조회는 정확히 몇 건이 나와야 한다"를 미리 알 수 있으면, 결과가 맞는지 스스로 검산할 수 있어요. SELECT * FROM member 는 8건. 만약 7건이나 9건이 나오면 뭔가 잘못된 거죠. 그런데 데이터가 수백만 건이라면 이 검산이 불가능해집니다. "이 결과가 맞나?" 를 확인할 길이 없어지고, 배우는 사람은 자기가 짠 SQL 을 믿지 못하게 돼요.

그래서 우리 데이터에는 경계 사례 가 일부러 심어져 있어요.

• 게시물이 0개인 회원 — 7번(taeyang)·8번(narae)
• 자기소개(bio)가 빈칸인 회원 — 3번·5번·8번

이런 "끝부분 사례"들이 나중에 더 복잡한 조회를 배울 때 함정을 정확히 짚어줍니다. 평범한 데이터만 있으면 놓칠 실수를, 이 경계 사례들이 잡아주거든요.

혹시 환경 잡기가 잘 안 되는 분들을 위해, 똑같은 데이터를 담은 공유 데이터셋(읽기 전용)도 안내합니다. 지난 시간에 본 무설치 경로처럼, 환경이 막혀도 강의를 따라올 수 있게 준비해뒀어요.

오늘부터 들일 습관 하나만 약속해요. 조회를 짤 때마다 "이건 몇 건 나올까?"를 먼저 예상하고 실행하기. 예상과 실제 결과를 맞춰보는 것, 그게 SQL 실력이 자라는 가장 빠른 길입니다.

💡 한 줄 정리

우리 데이터셋은 결과를 암산으로 검산할 수 있게 작게(회원 8·게시물 12) 만들었다. 조회 전에 "몇 건 나올까"를 먼저 예상하는 습관이 핵심이다.

마무리

오늘 수고 많으셨어요! 지난 시간에 그냥 화면에 떴던 그 표가, 이제는 "테이블에 행과 열로 담긴 데이터"로 또렷하게 보이시죠?

오늘 배운 핵심 세 가지

• 💡 하나 — 관계형 데이터베이스는 데이터를 표(테이블) 모양으로 담는다. 표 전체가 테이블, 가로줄이 행(row), 세로 칸이 열(column)이다.
• 💡 둘 — 기본키(primary key)는 각 행을 유일하게 구분하는 열이다. member 표에서는 member_id. 주민번호·학번 같은 역할을 한다.
• 💡 셋 — SELECT * 는 모든 열, SELECT username, nickname 은 원하는 열만 골라 조회한다. 회원과 게시물은 member_id 로 서로 연결된다.

다음 시간 예고

오늘 우리는 이미 만들어진 표를 들여다봤어요. 다음 시간엔 한 발 물러나서, "이 표들이 왜 이렇게 생겼는지"를 종이 위에서 직접 설계해봅니다. 회원·게시물·댓글·좋아요·팔로우 같은 인스타그램의 구성요소를 어떤 표로, 어떤 관계로 나눌지 그려보는 데이터 모델링 의 시작이에요. 오늘 맛본 기본키와 "표끼리 연결" 개념이 거기서 정식 이름(식별자·관계)을 얻습니다.

그리고 오늘 "원하는 열만" 골라봤듯이, "원하는 회원만"(특정 조건의 행만) 콕 집어 보는 조건 검색은 SQL 을 본격적으로 직접 짜기 시작하는 곳에서 깊게 다룹니다. 오늘 띄운 환경 그대로 이어가니, 컨테이너는 끄지 말고 그대로 두면 돼요.

과제

오늘 과제는 표를 직접 들여다보며 테이블·행·열·기본키 감각을 익히는 거예요. 작은 데이터라 결과를 눈으로 검산하기 좋습니다.

[기초] 표의 세 가지 이름 직접 확인하기

member 와 post 를 각각 SELECT * 로 조회하고, 각 표의 행이 몇 개인지(=몇 건인지) 세어보세요. member 는 8건, post 는 12건이 나오면 정답입니다. 그리고 각 표에 열이 몇 개이고 열 이름이 무엇인지도 적어보세요. (예: member 는 4열 — member_id, username, nickname, bio.)

[응용] 원하는 열만 골라 조회하기

post 표에서 post_id 와 caption 두 열만 골라 조회하는 SQL 을 직접 작성해 실행하세요. 결과가 12행·2열로 나오는지 확인합니다. 추가로 열 순서를 바꿔서(caption 을 먼저) 조회하면 결과가 어떻게 달라지는지도 비교해 보세요.

[심화] 기본키 후보 찾아보기

member 표에서 member_id 말고도 "각 회원을 유일하게 구분할 수 있을 것 같은" 열이 또 있을까요? 후보를 하나 찾아보고, 그 열을 기본키로 삼으면 어떤 점이 좋고 어떤 점이 불안한지(예: 값이 도중에 바뀔 수 있는지) 생각해서 적어보세요. 정답을 맞히는 것보다 "왜 그렇게 생각했는지"가 더 중요합니다.

생각해볼 주제

1. 왜 데이터를 '표' 모양으로 담을까?

세상의 데이터가 다 표로 딱 떨어지진 않아요. 예를 들어 친구의 친구로 끝없이 이어지는 인맥 관계나, 폴더 속의 폴더 같은 구조는 표 하나로 담기 어색합니다. 그런데도 가장 널리 쓰이는 데이터베이스는 여전히 '표(관계형)' 방식이에요. 표 모양이 주는 장점은 무엇이고, 반대로 표로 표현하기 어색한 데이터는 어떤 게 있을지 떠올려 보세요.

2. 기본키는 왜 '바뀌지 않는 값'이어야 할까?

회원을 구분하는 기본키로 username(아이디)을 쓰면 안 될까 잠깐 고민해봤죠. 만약 username 을 기본키로 정했는데 어떤 회원이 아이디를 바꾸고 싶어한다면 무슨 일이 벌어질까요? 그 회원의 게시물처럼 다른 데이터가 그 아이디를 가리키고 있었다면요? 기본키가 변할 때 생기는 연쇄 효과를 상상해 보세요.

3. 작은 데이터로 배우는 것의 가치

우리 데이터셋은 회원 8명짜리입니다. 실무 데이터는 수백만 건이죠. "결과를 눈으로 검산할 수 있다"는 것이 학습에서 왜 그렇게 중요할까요? 반대로, 작은 데이터로만 연습하면 놓치게 되는 것은 무엇일지도 함께 생각해 보세요.