반응형

VIEW와 INDEX의 이해와 활용법 총정리 💡

데이터베이스에서 성능을 좌우하는 두 가지 핵심 기술, VIEWINDEX. 제대로 알면 조회 속도와 유지보수 모두 잡을 수 있어요!

 

 

안녕하세요!

데이터베이스를 공부하는 분들이 가장 자주 접하게 되는 개념 중 하나가 바로 VIEW(뷰)INDEX(인덱스)입니다.

특히 대규모 데이터를 다루거나 성능이 중요한 서비스에서는 필수적으로 이해하고 써야 하는 기능이죠.

이번 글에서는 초보자도 쉽게 따라올 수 있도록, 이 두 개념을 실습 예제와 함께 완전 정복할 수 있도록 준비해봤어요.

"내 쿼리가 왜 이렇게 느리지?" 또는 "자주 쓰는 쿼리, 매번 복붙하기 귀찮아!" 이런 고민 한 번이라도 해보셨다면, 오늘 콘텐츠가 딱 맞을 거예요.

자, 그럼 VIEW와 INDEX의 세계로 함께 떠나볼까요?

1. VIEW의 개념과 쓰임새 ✨

VIEW(뷰)는 마치 테이블처럼 사용할 수 있는 가상의 테이블이에요.

실제 데이터를 저장하지 않고, SELECT 쿼리 결과를 마치 테이블처럼 다룰 수 있게 만들어주는 거죠.

데이터가 저장된 원본 테이블에는 손대지 않으면서, 필요한 데이터 조합을 따로 관리할 수 있어서 실무에서 정말 자주 쓰입니다.

📌 VIEW의 핵심 개념

  • SELECT 문을 기반으로 생성된 가상 테이블
  • 원본 테이블의 데이터에 종속되어 실시간 반영됨
  • 자주 사용하는 복잡한 쿼리를 단순하게 재사용 가능

🧠 VIEW를 왜 써야 할까?

처음에는 그냥 SELECT 문으로 조회하면 되지 않을까 싶죠.

하지만 프로젝트가 커지고, 다양한 조인과 필터 조건이 자주 반복될 때는 VIEW가 진가를 발휘합니다.

유지보수가 쉬워지고, 가독성이 좋아지고, 보안적으로도 유리해요.

구분 VIEW 사용 전 VIEW 사용 후
복잡한 쿼리 매번 JOIN, WHERE 반복 VIEW로 단순 호출
보안 전체 테이블 노출 VIEW로 필요한 열만 제공
유지보수 수정 시 모든 쿼리 일일이 수정 VIEW 쿼리만 변경하면 됨

🛠️ VIEW 생성 예제

CREATE VIEW recent_orders AS
SELECT o.order_id, o.customer_id, o.order_date, c.name
FROM orders o
JOIN customers c ON o.customer_id = c.id
WHERE o.order_date >= CURDATE() - INTERVAL 30 DAY;

위 VIEW를 만든 후엔, 그냥 SELECT * FROM recent_orders;만 하면 돼요!

복잡한 조인도 한 줄로 끝낼 수 있으니 얼마나 편한지 직접 실습하면서 느껴보세요 😊

 

 

2. VIEW 활용법: 쿼리 단순화와 재사용 🧩

VIEW를 잘 활용하면 복잡한 쿼리도 단순하게 만들 수 있고, 자주 쓰는 로직을 재사용할 수 있어요.

마치 함수처럼 반복되는 로직을 감싸놓는 개념이라고 생각하면 이해가 쉬워요!

🔁 반복되는 로직을 뷰로 감싸기

예를 들어,

최근 1개월 간 주문을 분석하는 쿼리를 여러 군데에서 쓰고 있다면, 매번 복사해서 붙여넣는 것보다 VIEW로 만들어두면 더 좋겠죠?

CREATE VIEW recent_sales AS
SELECT p.product_id, p.name, SUM(oi.quantity) AS total_sold
FROM order_items oi
JOIN products p ON oi.product_id = p.id
JOIN orders o ON oi.order_id = o.order_id
WHERE o.order_date >= CURDATE() - INTERVAL 30 DAY
GROUP BY p.product_id;

이제 단순히 SELECT * FROM recent_sales; 하면 복잡한 그룹 연산까지 한 번에 끝! 😄

📋 VIEW로 보안 제어까지 가능해요

회사에서는 특정 사용자에게 고객 개인정보까지 보여주는 건 문제가 될 수 있죠?

이럴 때도 VIEW를 통해 민감한 열은 숨기고, 필요한 정보만 보여주는 게 가능해요.

CREATE VIEW basic_customer_info AS
SELECT name, email
FROM customers;

이 뷰에만 SELECT 권한을 주면, 주소, 카드 정보 같은 민감 정보는 자동으로 차단됩니다.

보안 + 유지보수 + 개발 효율성까지, 한 번에 잡을 수 있는 게 바로 VIEW죠!

✅ VIEW 활용 요약

활용 목적 VIEW의 역할
반복 쿼리 간소화 복잡한 쿼리 하나로 캡슐화
보안 강화 민감 정보 노출 방지
가독성 개선 간단한 SELECT로 명확한 표현 가능

VIEW는 단순한 쿼리 단축 도구가 아닙니다.

현업에서는 유지보수성과 보안을 확보하는 핵심 기술로 쓰인다는 점, 꼭 기억해두세요!

 

 

3. INDEX란? 꼭 필요한 이유 📚

여러분, 책에서 원하는 내용을 빨리 찾으려면 어떻게 하시나요?

그렇죠, 목차를 보죠.

데이터베이스에서 그 목차 역할을 하는 게 바로 INDEX입니다.

INDEX가 없으면, 모든 데이터를 처음부터 끝까지 다 뒤져야 해서 시간이 오래 걸려요.

하지만 INDEX가 있다면, 원하는 데이터를 단번에 ‘점프’해서 찾을 수 있죠.

이게 바로 성능 차이의 핵심입니다.

📌 INDEX의 기본 개념

  • 테이블에서 특정 컬럼의 값을 빠르게 찾기 위한 자료 구조
  • B-Tree 구조가 가장 흔하게 사용됨
  • 주로 WHERE 절, JOIN 조건, ORDER BY, GROUP BY에 영향

📈 INDEX가 왜 중요한가요?

SELECT 쿼리가 느려터졌을 때, 대부분은 INDEX 미사용이 원인이에요.

아무리 서버 성능이 좋아도, 수십만 건을 무작정 스캔하면 당연히 느려지죠.

상황 INDEX 없음 INDEX 있음
데이터 조회 Full Scan (전체 탐색) 빠른 위치 기반 탐색
검색 속도 수십 초 이상 1~2초 이내
쿼리 효율성 비효율적 최적화됨

🛠️ INDEX 생성 예제

CREATE INDEX idx_customers_email
ON customers(email);

위처럼 자주 검색하는 email 컬럼에 인덱스를 생성하면,

SELECT * FROM customers WHERE email = 'aaa@domain.com' 같은 쿼리가 훨씬 빨라져요!

❗주의: INDEX는 만능이 아닙니다

INDEX가 무조건 좋다고 생각하면 큰일 납니다!

데이터 삽입/수정이 자주 일어나는 테이블에서는 오히려 성능을 떨어뜨릴 수 있어요.

그만큼 인덱스를 필요한 곳에만 선택적으로 사용하는 센스가 필요합니다.

 

다음 단계에서는 실제로 INDEX가 성능을 얼마나 개선하는지 실습을 통해 직접 확인해볼게요!

 

 

4. INDEX를 활용한 성능 개선 사례 🚀

INDEX를 어떻게 적용하느냐에 따라 데이터베이스 성능은 천차만별입니다.

단순한 예제를 통해 인덱스의 진짜 효과를 체감해보면, 왜 실무에서 인덱스를 아끼지 말라고 하는지 몸소 느낄 수 있어요.

📋 시나리오: 사용자 이메일로 로그인 조회

어느 날 서비스에서 고객 로그인이 엄청 느려졌다는 민원이 들어옵니다.

문제는 이 쿼리 👇

SELECT * FROM users WHERE email = 'user@example.com';

이 테이블에는 100만 명의 회원 정보가 있고, email 컬럼에는 인덱스가 없었습니다.

결과적으로 전체 데이터를 훑어보는 Full Scan이 발생하고, 로그인 응답 속도가 5~6초까지 늘어났죠. 😨

✅ 인덱스 적용 후 변화

CREATE INDEX idx_users_email ON users(email);

인덱스 한 줄 추가했을 뿐인데, 조회 속도는 0.1초 미만으로!

그야말로 속도 혁명이에요.

서비스 속도 불만도 사라졌고, 서버 부하도 확 줄었습니다.

📊 성능 비교 요약

항목 인덱스 없음 인덱스 적용
쿼리 시간 5.2초 0.07초
서버 CPU 사용률 85% 25%
동시 사용자 응답 느림, 병목 빠름, 안정적

💡 INDEX 사용 팁

  • WHERE 조건에 자주 쓰이는 컬럼에만 인덱스 적용
  • EXPLAIN 명령으로 인덱스 사용 여부 확인
  • 너무 많은 인덱스는 오히려 느려질 수 있음 (삽입/수정 시 부담 증가)

적재적소에 쓰는 INDEX는 성능의 신세계입니다.

다음 파트에서는 VIEW와 INDEX를 활용한 실습 예제로 이해를 더 탄탄하게 만들어 볼게요!

 

 

5. 실습 예제 ① : 자주 조회되는 데이터를 VIEW로 만들어보기 🔍

이제 이론은 충분히 배웠으니, 직접 실습해보는 시간이 왔어요!

이번 예제에서는 최근 한 달간 가장 많이 주문된 상품 데이터를 조회하는 복잡한 쿼리를 VIEW로 만들어서, 얼마나 편하게 쓸 수 있는지 체험해볼 거예요.

자주 사용하는 데이터를 매번 긴 SQL로 조회하는 것보다 VIEW로 묶어두면 훨씬 효율적이죠.

📌 시나리오 설명

  • 테이블: orders, order_items, products
  • 목표: 최근 30일간 상품별 판매량을 집계하여 정렬된 리스트 출력

🔧 원래 쿼리 (VIEW 없이)

SELECT p.name, SUM(oi.quantity) AS total_sold
FROM orders o
JOIN order_items oi ON o.order_id = oi.order_id
JOIN products p ON oi.product_id = p.id
WHERE o.order_date >= CURDATE() - INTERVAL 30 DAY
GROUP BY p.name
ORDER BY total_sold DESC;

처음에는 괜찮지만, 이 쿼리를 매번 쓰다 보면 복잡하고 실수도 많아져요.

그래서 이렇게 바꿔보겠습니다👇

✅ VIEW로 재구성

CREATE VIEW monthly_top_products AS
SELECT p.name, SUM(oi.quantity) AS total_sold
FROM orders o
JOIN order_items oi ON o.order_id = oi.order_id
JOIN products p ON oi.product_id = p.id
WHERE o.order_date >= CURDATE() - INTERVAL 30 DAY
GROUP BY p.name;

이제 정렬만 따로 붙여서 아래처럼 호출하면 끝이에요!

SELECT * FROM monthly_top_products
ORDER BY total_sold DESC;

🎯 실습 요약

구분 VIEW 미사용 VIEW 사용
쿼리 길이 10줄 이상 2~3줄로 간결
유지보수 쿼리 수정 시 반복 필요 VIEW만 수정하면 적용
가독성 낮음 높음

이렇게 실습을 통해 VIEW가 얼마나 강력한 재사용 도구인지 확인해봤습니다.

다음은 INDEX 적용 전후로 쿼리 속도를 직접 비교해보는 실습이 이어집니다!

 

 

6. 실습 예제 ② : INDEX 적용 전후 속도 비교 실습 ⏱️

이제 진짜 중요한 실습입니다.

INDEX가 얼마나 성능 향상에 도움이 되는지 눈으로 직접 확인해보는 시간이에요.

데이터베이스 튜닝에서 가장 많이 언급되는 키워드 중 하나가 인덱스인데요,

"그냥 한번 만들어봐~"보다 확실한 근거가 중요하죠.

📋 실습 환경

  • 테스트 테이블: users (약 100만 건 데이터)
  • 대상 쿼리: 이메일 기준 사용자 검색

🔍 INDEX 적용 전

SELECT * FROM users WHERE email = 'user1000@example.com';

결과: 평균 5.3초 ⏳

전체 데이터를 처음부터 훑는 Full Table Scan이 발생합니다.

이건 큰 서비스에서는 "망하는 길"이에요.

🚀 INDEX 생성 후

CREATE INDEX idx_users_email ON users(email);

다시 동일한 쿼리를 실행해보면?

평균 0.09초 ⚡ 60배 이상 빨라진 걸 확인할 수 있습니다!

📊 실습 비교 정리

조건 INDEX 없음 INDEX 적용
조회 시간 5.3초 0.09초
사용 인덱스 없음 idx_users_email
성능 개선율 - 약 60배 ↑

🔚 마무리

이번 실습을 통해 VIEW와 INDEX의 실질적인 활용법과 중요성을 체감하셨길 바랍니다.

단순한 개념 설명을 넘어, 진짜 현장에서 사용하는 방식대로 따라해보면 실력이 더 빠르게 늘어요.

앞으로 여러분의 쿼리가 조금 더 짧아지고, 서비스 속도는 훨씬 빨라지는 경험이 되기를 응원합니다.

 

그럼 다음 콘텐츠에서 더 실전적인 팁으로 다시 만나요! 🙌

반응형

+ Recent posts