면목동인간의 일상

<DB> 커버링 인덱스란?

면목동인간 — Sun, 14 Jun 2026 00:26:16 +0900

커버링 인덱스란?

커버링 인덱스란 쿼리에 필요한 모든 칼럼을 포함하고 있는 인덱스를 의미한다. 예를 들어 책의 맨 뒤의 원하는 키워드에서 찾은 후 (1단계) 다시 그 페이지로 넘어가서 내용을 읽는(2단계)가 아닌 1단계에서 처리를 한다.

커버링 인덱스 적용 전

아래는 price만 인덱스가 걸려 있고, 그 상태에서 item_id, price, item_name을 SELECT 하는 쿼리를 실행했다고 가정하였다.

SELECT item_id, price, item_name FROM items WHERE price BETWEEN 50000 AND
100000;

김영한의 실전 데이터베이스 기본편/인프런

위의 쿼리를 분석해보면 인덱스에서 price 조건에 맞는 행의 item_id 5개를 찾았지만, item_name도 추가로 조회하기 때문에 원본 테이블에 5번 접근(5번 랜덤 I/O 발생)하여 item_name을 가져와야 한다. 위의 인덱스에는 item_name 포함되지 않기 때문에 원본 테이블을 무조건 접근해야 한다.

커버링 인덱스 적용 후

앞서 위에 price만 적용된 인덱스 말고 item_name까지 포함하는 인덱스가 걸려있고 위와 똑같이 SELECT 하는 쿼리를 실행했다고 가정하였다.

김영한의 실전 데이터베이스 기본편/인프런

위의 쿼리를 분석해보면 인덱스만 읽고 끝나므로, 원본 테이블 접근을 위한 랜덤 I/O가 완전히 사라져 훨씬 빠르고 효율적으로 동작한다.

장점

1. 디스크 I/O 감소

-> 일반 인덱스: 인덱스 읽기+테이블 읽기 이지만, 커버링 인덱스: 인덱스만 읽기 이므로 랜덤 I/O가 크게 감소한다.

2. 응답 속도 향상

-> 수백만 건 이상의 테이블에서는 체감 성능 차이가 상당할 수 있다.

단점

1. 인덱스 크기 증가

-> 커버링을 위해 칼럼을 많이 넣으면 인덱스 크기가 증가한다.

2. INSERT 성능 저하

-> 새 데이터 입력 시 원본 테이블뿐 아니라 인덱스도 갱신해야 한다. 인덱스가 크고 많을수록 INSERT 느려진다.

3. UPDATE 비용 증가

-> 인덱스 컬럼 수정 시 인덱스 재구성이 발생한다.

언제 사용하는가?

조회가 압도적으로 많은 서비스
대용량 테이블
자주 실행되는 핵심 쿼리
API 목록 조회
페이징 조회
통계 조회

정리

커버링 인덱스는 "쿼리에 필요한 모든 칼럼이 인덱스 안에 있어 테이블 접근 없이 인덱스만으로 결과를 반환하는 최적화 기법"이다. 조회 성능은 크게 향상되지만, 인덱스 크기 증가와 쓰기 성능 저하라는 비용을 함께 고려해야 한다.

본 포스팅은 “김영한의 실전 데이터베이스 기본편/인프런”를 학습한 내용을 정리한 것

<DB> 인덱스란?

면목동인간 — Mon, 8 Jun 2026 14:38:57 +0900

인덱스란

데이터베이스에서의 인덱스는 데이터를 빠르게 찾기 위한 색인이다. 일상 생활에서 책 내용을 찾을려면 처음부터 끝까지 모두 확인하는게 아닌 책 뒤의 특정 단어(색인)를 통해 바로 찾을 수 있다. 데이터베이스의 인덱스도 이와 동일한 개념이다.

인덱스 동작 원리

대부분의 관계형 데이터베이스에서 인덱스는 B+ Tree 구조를 사용하며, 원본 테이블과는 별개의 특수한 자료 구조다. 인덱스는 지정된 컬럼의 값과, 해당 값을 가진 실제 데이터 행의 위치(예: 주소값, 포인터,pk 등)를 한 쌍으로 지정하고, 인덱스 내부의 데이터는 항상 정렬된 상태를 유지한다. (아래는 items 테이블과 items 테이블의 item_name으로 인덱스를 나타낸 그림이다.)

김영한의 실전 데이터베이스 기본편/인프런

앞서 인덱스는 B+ Tree 구조를 가지고 있다고 했는데 여기서 B+ Tree 구조를 간단히 나타내면 아래와 같다.

김영한의 실전 데이터베이스 기본편/인프런

위의 자료구조를 통해 데이터를 조회 하는 방식은 아래과 같으며 알고리즘의 효율성을 나타내는 수학적 표기법으로 나타내면 O(log n)과 같다.

2개의 데이터 2로 1번 나누기, log₂(2)=1
4개의 데이터 2로 2번 나누기, log₂(4)=2
8개의 데이터 2로 3번 나누기, log₂(8)=3
16개의 데이터 2로 4번 나누기, log₂(16)=4
...
16,384개의 데이터 2로 14번 나누기, log₂ (16384)=14
...
1,000,000개의 데이터 2로 약 20번 나누기, log₂ (1,000,000)≈19.93
100,000,000개의 데이터 2로 약 27번 나누기, log₂ (100,000,000)≈26.57

이렇게 인덱스를 사용하게 되면 데이터가 많아질수록 차이가 극적으로 커지게 된다.

인덱스 생성, 조회, 삭제

-- 생성
CREATE INDEX 인덱스이름 ON 테이블이름 (컬럼1, 컬럼2, ...);

-- 조회
SHOW INDEX FROM 테이블이름;

-- 삭제
DROP INDEX 인덱스이름 ON 테이블이름;

인덱스 장점

1. 조회 속도가 압도적으로 빨라진다

-> 인덱스가 있으면 B+ Tree 구조를 이용해 조회 속도가 빠르지만 인덱스가 없으면 Full Table Scan으로 전체 테이블을 순차적으로 읽어야 한다.

2. WHERE 조건 검색이 빨라진다.

-> 검색 조건에 사용되는 컬럼에 인덱스가 있으면 빨라진다. (반드시 인덱스에 WHERE 조건할 컬럼이 있어야 한다.)

3. 정렬이 빨라질 수 있다.

-> 인덱스가 없으면 전체 데이터 조회 후 정렬을 해야 하지만 인덱스가 있으면 이미 정렬된 인덱스 순서를 사용하기 때문에 정렬 비용이 크게 감소한다. (이것도 반드시 ORDER BY 할 컬럼이 인덱스에 있어야 한다.)

4. JOIN 성능 향상

SELECT *
FROM orders o
JOIN users u
ON o.user_id = u.id;

user_id나 id에 인덱스가 있으면 JOIN할 사용자 테이블 위치를 즉시 탐색하기 때문에 성능이 향상 된다. 참고로 MYSQL에서는 PRIMARY KEY (기본 키)나 FOREIGN KEY (외래 키) 제약조건을 설정하면, 해당 컬럼에 대해 자동으로 인덱스를 생성한다. UNIQUE 제약조건도 마찬가지로 인덱스가 생성된다.)

인덱스 단점

1. 저장 공간을 추가로 사용한다.

-> 만약 테이블이 하나가 있고 인덱스를 N개 생성하였으면 인덱스 별도로 N개의 저장 공간이 필요하게 된다.

2. INSERT, UPDATE, DELETE가 느려진다.

-> 테이블에 삭제, 수정, 삭제를 하게 되면 생성된 인덱스 내부 데이터를 추가, 수정, 삭제를 해야하고 추가로 트리를 재정렬 해야하기 때문에 추가 비용이 발생하게 된다.

정리

인덱스는 데이터베이스에서 특정 데이터를 빠르게 찾기 위해 만드는 "색인"이며, 보통 B+ Tree 자료구조를 사용하여 전체 데이터를 훑는 O(N) 탐색을 O(log N) 수준으로 줄여 성능을 크게 향상시킨다. 대신 저장 공간을 추가로 사용하고 INSERT/UPDATE/DELETE 성능은 일부 감소한다.

본 포스팅은 “김영한의 실전 데이터베이스 기본편/인프런”를 학습한 내용을 정리한 것

<JPA> OSIV이란?

면목동인간 — Wed, 3 Jun 2026 23:37:06 +0900

OSIV이란?

JPA의 OSIV(Open Session In View) 는 웹 요청이 시작될 때 영속성 컨텍스트(EntityManager)를 생성하고, 응답이 끝날 때까지 유지하는 패턴이다.

OSIV 설정 방법

아래는 Spring Boot 환경에서 yaml 파일에 대한 설정 방법이고, Spring Boot에서는 기본적으로 OSIV가 활성화되어 있다.

spring:
  jpa:
    open-in-view: true

OSIV가 필요한 이유

JPA의 연관관계가 LAZY 로딩일 때 문제가 발생할 수 있다.

// 엔티티
@Entity
public class Order {

    @ManyToOne(fetch = FetchType.LAZY)
    private Member member;
}

// 서비스
@Transactional
public Order findOrder(Long id) {
    return orderRepository.findById(id).get();
}

// 컨트롤러
@GetMapping("/orders/{id}")
public String order(@PathVariable Long id) {

    Order order = orderService.findOrder(id);

    String memberName = order.getMember().getName();

    return memberName;
}

OSIV가 false일 경우

서비스 메서드 종료
트랜잭션 종료
영속성 컨텍스트 종료
컨트롤러에서 order.getMember() 호출
Lazy Loading 불가
LazyInitializationException 에러 발생

OSIV가 true일 경우

요청 시작 시 EntityManager 생성
서비스 트랜잭션 종료 후에도 유지
컨트롤러에서 Lazy Loading 가능
응답 완료 시 EntityManager 종료

OSIV 동작 구조

OSIV가 true인 경우

OSIV가 true인 경우 데이터베이스 커넥션 시작 시점부터 API 응답이 끝날 때 까지 영속성 컨텍스트 와 데이터베이스 커넥션을 유지한다. 그래서 View Template이나 API 컨트롤러에서 지연 로딩이 가능했던 것이다.

OSIV가 false인 경우

OSIV가 false인 경우 트랜잭션을 종료할 때 영속성 컨텍스트를 닫고, 데이터베이스 커넥션도 반환한다. 그리고 모든 지연로딩을 트랜잭션 안에서 처리해야 한다.

OSIV 장점

1. Lazy Loading이 편리

-> 별도 조회 없이 접근 가능

order.getMember().getName();

2. 개발 생산성 향상

-> 서비스 계층에서 필요한 데이터를 전부 조회해둘 필요가 없고, 컨트롤러에서 연관 객체 접근 가능하다.

OSIV 단점

1. 데이터베이스 커넥션을 오래 점유

-> OSIV true 상태에서는 영속성 컨텍스트가 요청 끝까지 유지된다. 상황에 따라 DB 커넥션이 예상보다 오래 사용될 수 있어 트래픽이 많아지면 문제가 될 수 있다.

2. N+1 문제를 숨긴다.

-> 컨트롤러에서 예상치 못한 추가 쿼리가 발생할 수 있다.

// 컨트롤러
orders.forEach(order -> {
    System.out.println(order.getMember().getName());
});

select * from orders;

select * from member where id=?
select * from member where id=?
select * from member where id=?
...

3. 계층 분리가 흐려짐

-> 원칙적으로는 Controller->Service->Repository 인데 Controller에서 Lazy Loading이 발생하게 되면 조회 로직이 프레젠테이션 계층까지 발생하게 된다.

실무에서는?

실무에서는 OSIV를 끄는 경우가 많으며, 서비스 계층에서 Fetch Join과 DTO을 사용하여 조회한다.

spring:
  jpa:
    open-in-view: false

정리

OSIV는 요청 시작부터 응답 완료 시점까지 영속성 컨텍스트를 유지하여 트랜잭션 종료 이후에도 Lazy Loading을 가능하게 하는 기능이다. 다만 개발 편의성을 높여주지만 성능 문제를 숨길 수 있기 때문에, 실무에서는 OFF 후 Fetch Join·DTO 조회를 적극 활용하는 방식이 많이 사용된다.

본 포스팅은 “ 실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화/인프런”를 학습한 내용을 정리한 것

<Spring Data JPA> 쿼리 메서드란?

면목동인간 — Sat, 9 May 2026 12:39:38 +0900

쿼리 메서드란?

Spring Data JPA에서 제공하는 쿼리 메서드 기능은 메서드 이름만으로 SQL/JPQL 쿼리를 자동 생성해주는 기능이다. 즉, 개발자가 쿼리를 작성하지 않아도 Repository 인터페이스에 메서드 작성만으로 DB 조회가 가능하다.

메서드 이름 규칙

쿼리 메서드는 아래와 같이 메서드 이름 규칙으로 만들어야 실제 JPQL로 변경하여 사용할 수 있으며, 키워드 + Entity 필드명 + CamelCase을 정확히 맞춰서 작성해야한다.

1. 조회 키워드

findBy
readBy
getBy
queryBy

findByUsername(String username)
// SELECT u FROM User u WHERE u.username = :username

2. 조건 키워드

Equals (생략 가능)
Is
Not
GreaterThan
LessThan
Between
Like
Containing
StartingWith
EndingWith
IsNull
IsNotNull
True
False

findByUsername(String username)
// SELECT u FROM User u WHERE u.username = :username

findByUsernameIs(String username)
// SELECT u FROM User u WHERE u.username = :username

findByUsernameNot(String username)
// SELECT u FROM User u WHERE u.username <> :username

findByAgeGreaterThan(int age)
// SELECT u FROM User u WHERE u.age > :age

findByCreatedDateBetween(LocalDate start, LocalDate end)
// SELECT u FROM User u WHERE u.age BETWEEN :start AND :end

findByUsernameContaining(String keyword)
// SELECT u FROM User u WHERE u.username LIKE %:keyword%

findByEmailEndingWith(String domain)
// SELECT u FROM User u WHERE u.username LIKE %:suffix

findByDeletedAtIsNull()
// SELECT u FROM User u WHERE u.deletedAt IS NULL

findByActiveTrue()
// SELECT u FROM User u WHERE u.active = true

3. AND/OR 조건

findByUsernameAndEmail(String username, String email)
// SELECT u FROM User u WHERE u.username = :username AND u.email = :email

findByUsernameOrEmail(String username, String email)
// SELECT u FROM User u WHERE u.username = :username OR u.email = :email

4. 정렬

OrderBy...Desc/Asc

findByAgeOrderByUsernameDesc(int age);
// SELECT u FROM User u WHERE u.age = :age ORDER BY u.username DESC

5. 개수/존재 여부

countBy
existBy

long countByUsername(String username);
// SELECT COUNT(u) FROM User u WHERE u.username = :username

boolean existsByEmail(String email);
// SELECT CASE WHEN COUNT(u) > 0 THEN true ELSE false END FROM User u WHERE u.email = :email

쿼리 메서드 주의할 점

쿼리 메서드는 너무 길어지면 가독성이 떨어지기 때문에 길어지면 @Query 사용을 권장한다. 그리고 Entity 필드명으로 JPQL이 생성 되기 때문에 Entity 필드명이 바뀔 경우 메서드도 추가로 수정해야 한다. 그렇지 않으면 애플리케이션 시작하는 시점에 오류가 발생하게 된다.

쿼리 메서드를 언제 사용 하는게 좋을까?

쿼리 메서드를 추천 하는 경우 1. 단순 조회 2. 조건 1~3개 정도 3. 빠른 개발 이며 비추천 하는 경우 1. 복잡한 통계 쿼리 2. 다중 JOIN 3. 성능 튜닝이 필요한 경우 이렇게 볼 수 있다.

정리

Spring Data JPA의 쿼리 메서드는 메서드 이름을 규칙(CamelCase + 키워드)에 따라 해석해 자동으로 JPQL을 생성하는 기능이다. 주로 SELECT 조회에 사용되며, DELETE는 지원하지만 UPDATE는 지원하지 않아 @Query나 변경 감지를 사용해야 한다. 간단한 조건 조회에는 매우 편리하지만, 복잡한 쿼리는 가독성과 한계 때문에 별도의 방법을 사용하는 것이 좋다.

본 포스팅은 “실전! 스프링 데이터 JPA/인프런”를 학습한 내용을 정리한 것

<JPA> 일대다(1:N) 단방향 연관관계 맵핑 시 주의할 점

면목동인간 — Wed, 29 Apr 2026 15:51:51 +0900

일대다(1:N) 연관관계란?

일대다(1:N) 연관관계는 하나의 엔티티가 여러 개의 엔티티와 관계를 맺는 구조를 의미한다. 예를 들어 객체 구조에서 Team과 Member가 있을 때, 하나의 Team에는 여러 명의 Member가 속할 수 있고 각 Member는 하나의 Team에만 속하게 된다. 이러한 관계를 데이터베이스 테이블로 설계할 경우, 외래키는 항상 ‘다(N)’에 해당하는 쪽에 위치하게 되므로 Member 테이블에 Team의 기본키를 참조하는 외래키가 포함된다. 이때 일대다 연관관계에서 일 쪽에 외래키를 관리하며 연관관계의 주인이 된다.

예제

아래의 코드는 일대다 관계에서 일 쪽에 단방향 연관관계의 주인이 될 때 주의할 점이다.

@Entity
public class Member {

    @Id
    @GeneratedValue
    @Column(name = "MEMBER_ID")
    private Long id;
    
    private String name;
    
    // getter, setter 생략
}

@Entity
public class Team {

    @Id
    @GeneratedValue
    @Column(name = "TEAM_ID")
    private Long id;
    
    private String name;
    
    @OneToMany
    @JoinColumn(name = "TEAM_ID")
    private List<Member> members = new ArrayList<>();
    
    // getter, setter 생략
}

public class JpaMain {

    public static void main(String[] args) {

        // 엔티티 매니저 생성 및 트랜잭션 생략

        Member member1 = new Member();
        member1.setName("member1");
        em.persist(member1);

        Team team1 = new Team();
        team1.setName("Team1");
        team1.getMembers().add(member1);
        em.persist(team1);

        // 엔티티 매니저 종료 및 트랜잭션 생략
    }
}

실행결과

Hibernate: 
    /* insert for
        hellojpa.Member */insert 
    into
        Member (name, MEMBER_ID) 
    values
        (?, ?)
Hibernate: 
    /* insert for
        hellojpa.Team */insert 
    into
        Team (name, TEAM_ID) 
    values
        (?, ?)
Hibernate: 
    update
        Member 
    set
        TEAM_ID=? 
    where
        MEMBER_ID=?

위의 코드를 실행하니 쿼리가 3개가 나왔다. 분명 영속한 객체(insert 하는)는 2개인데 insert 2개랑 update 1개 발생하였다.

update가 발생한 이유?

지금 Team이 연관관계 주인이며, Member를 컬렉션으로 가지고 있는 단방향 관계이다. 즉, 외래키는 Member 테이블에 존재하지만, 이를 설정하는 주체는 Team이다. 코드를 보면 먼저 Member를 생성하고 persist를 호출하여 insert가 실행된다. 이 시점에는 Member가 어떤 Team에도 속해 있지 않기 때문에, 외래키 값(Team의 FK)은 null인 상태로 저장된다. 이후 Team을 생성하고 member1을 Team의 members 컬렉션에 추가한 뒤 persist를 호출하면, JPA는 이 시점에서 연관관계가 설정되었다고 인식한다. 하지만 이미 Member는 insert 된 상태이므로, 새로 insert 할 수는 없고 기존 데이터의 외래키 값을 수정해야 한다. 따라서 JPA는 Member 테이블의 외래키를 업데이트하기 위해 추가로 update 쿼리를 실행하게 된다.

정리하면, Member를 먼저 저장할 때는 연관관계 정보가 없어서 FK가 null로 insert되고, 이후 Team에 Member를 추가하면서 FK 값을 반영하기 위해 update가 발생하는 것이다.

구조를 지양하는 이유?

이 구조(일대다 단방향 + Team이 연관관계 주인)를 실무에서 잘 사용하지 않는 이유는 성능과 설계 측면에서 비효율적이기 때문이며, 가장 큰 문제는 불필요한 update 쿼리 발생이다. 앞서 본 것처럼 insert 한 번으로 끝낼 수 있는 작업이 insert + update로 늘어나 성능 손해가 발생한다. 또한 이 방식은 데이터 흐름이 직관적이지 않는다. 실제 데이터베이스에서는 외래키가 Member 테이블에 존재하기 때문에, Member가 Team을 참조하는 구조가 자연스럽다. 그런데 객체에서는 Team이 Member를 관리하게 되므로, 객체 구조와 DB 구조가 어긋나는 문제가 생긴다. 이로 인해 유지보수 시 혼란이 발생할 수 있다.

정리

일대다 단방향 연관관계에서 ‘일(1)’ 쪽을 연관관계의 주인으로 설정하면, 실제 외래키는 ‘다(N)’ 쪽 테이블에 존재함에도 불구하고 이를 ‘일’ 쪽에서 관리하게 되어 구조가 비직관적이 된다. 이로 인해 엔티티를 저장할 때 외래키 값이 즉시 반영되지 못하고, insert 이후 추가적인 update 쿼리가 발생하는 비효율이 생긴다. 또한 객체 구조와 데이터베이스 구조가 어긋나 유지보수와 성능 측면에서 불리하다. 따라서 실무에서는 일대다 단방향 대신, 외래키를 가진 ‘다(N)’ 쪽을 연관관계의 주인으로 하는 다대일 중심의 설계를 사용하는 것이 바람직하다.

본 포스팅은 “자바 ORM 표준 JPA 프로그래밍 - 기본편/인프런”를 학습한 내용을 정리한 것

<Docker> 볼륨(Volume)이란?

면목동인간 — Thu, 2 Apr 2026 16:23:18 +0900

볼륨이란?

볼륨이란 도커 컨테이너에서 데이터를 영속적으로 저장하기 위한 방법이다. 볼륨은 컨테이너 내의 저장 공간을 사용하지 않고, 호스트 내의 저장 공간을 공유해서 사용한다.

볼륨을 사용하는 이유?

예를 들어 mysql의 이미지로 컨테이너를 실행시켰는데, mysql 업데이트를 하게 되어 새로운 mysql 이미지로 컨테이너를 띄우게 된다면 기존 내부에 있던 데이터가 같이 삭제하게 된다. 이를 막기 위해 볼륨을 활용하면 된다.

볼륨 활용 전 예제

아래 예제는 mysql 컨테이너를 실행한 후 실제 데이터베이스를 만들고 볼륨을 활용하기 전과 후의 차이를 비교하는 것이다.

docker run -e MYSQL_ROOT_PASSWORD=password123 -p 3306:3306 -d mysql

mysql 이미지를 받고 컨테이너까지 실행하는 명령어다.

docker exec -it [MySQL 컨테이너 ID] bash

실행 중인 mysql 컨테이너에 접근하는 명령어이다.

mysql -u root -p

show databases;

create database testDb

show databaeses;

컨테이너에 접근 후 위의 명령어를 입력하면 아래와 같이 mysql 서버에 들어간 것이다. 그 후 데이터베이스를 생성하고 목록을 보면 아래와 같이 나올 것이다.

docker stop [MySQL 컨테이너 ID]
docker rm [MySQL 컨테이너 ID]

docker run -e MYSQL_ROOT_PASSWORD=password123 -p 3306:3306 -d mysql
docker exec -it [MySQL 컨테이너 ID] bash

mysql -u root -p
show databases;

그 후 컨테이너를 종료 하고 삭제 후 다시 컨테이너를 실행하게 되면 아래와 같이 데이터베이스가 없어진 것을 확인할 수 있다.

볼륨 활용 후 예제

볼륨을 활용하기 앞서 호스트의 저장 공간에 데이터를 저장하기 위해 다음과 같이 별도의 저장할 디렉터리를 만들어야 한다. ex) C:\Users\oniic\docker-mysql

docker run -e MYSQL_ROOT_PASSWORD=password123 -p 3306:3306 -v "C:/Users/oniic/docker-mysql/mysql_data:/var/lib/mysql" -d mysql

위의 명령어에서 -v 옵션에서 앞이 호스트에 공유할 경유이고 뒤가 컨테이너의 데이터가 저장되는 경로이다. 명령어를 실행하면 호스트의 mysql 관련 데이터가 아래와 같이 저장된 것을 확인할 수 있다. 이제 mysql 접속 후 데이터베이스를 생성하고 컨테이너를 종료 및 제거 후 다시 실행하면 데이터베이스가 제거되지 않은 것으로 확인할 수 있다.

여기서 주의할 점이 있는데 호스트 디렉토리에서 mysql_data를 미리 만들어 놓으면 안 된다. 그래야 처음 이미지를 실행시킬 때 mysql 내부에 있는 /var/lib/mysql 파일들을 호스트 컴퓨터로 공유받을 수 있다. mysql_data 디렉터리를 미리 만들어놓을 경우, 기존 컨테이너의 /var/lib/mysql 파일들을 전부 삭제한 뒤에 mysql_data로 덮어씌워 버린다.

정리

볼륨은 컨테이너의 데이터를 영속적으로 저장하기 위한 메커니즘이다. 기본적으로 컨테이너는 삭제되면 내부 데이터도 함께 사라지는데 이를 해결하기 위해 볼륨을 사용한다.

본 포스팅은 “비전공자도 이해할 수 있는 Docker 입문/실전 /인프런”를 학습한 내용을 정리한 것

<Docker> 도커란?

면목동인간 — Mon, 23 Mar 2026 21:19:43 +0900

도커란?

도커는 컨테이너를 사용하여 각각의 프로그램을 분리된 환경에서 실행 및 관리할 수 있는 툴이다.

컨테이너란?

도커에서 컨테이너란 하나의 컴퓨터 내에서 독립적인 여러 개의 컴퓨터 환경을 구성할 수 있는데 그 여러 개 중의 하나의 컴퓨터를 컨테이너라고 한다.

위의 컨테이너들은 컴퓨터 내에서 각각 독립적인 컴퓨터 환경이라고 보면 되고, 각 컨테이너마다 각자의 저장 공간을 가지고 있으며, 일반적으로는 A 컨테이너 내부에서 B 컨테이너 내부에 있는 파일에 접근할 수 없다. 그리고 각 컨테이너마다 고유의 네트워크를 가지고 있다(각각 ip를 가지고 있다).

이미지란?

도커에서 이미지란 프로그램을 실행하는데 필요한 설치 과정, 설정, 버전 정보 등을 포함하고 있다. 즉, 프로그램을 실행하는데 필요한 모든 것을 포함하고 있다. 예를 들어 MySql 서버를 이미지로 만들었다면, 이 이미지를 Docker로 실행시키는 순간 MySql 서버가 컨테이너 환경에서 실행된다.

정리

도커는 컨테이너를 사용하여 프로그램을 분리된 환경에서 실행할 수 있고 이미지는 프로그램을 실행하는데 필요한 정보이다.

본 포스팅은 “비전공자도 이해할 수 있는 Docker 입문/실전 /인프런”를 학습한 내용을 정리한 것

<DB> 뷰(View)이란?

면목동인간 — Sat, 14 Mar 2026 23:58:07 +0900

뷰(View)이란?

뷰는 가상의 테이블이다. 즉 데이터를 가지고 있지 않는다. 뷰는 데이터를 저장하는 테이블이 아니고, 복잡한 쿼리문 자체를 저장하고 있다.

뷰(View)를 사용하는 이유

편리성: 복잡한 쿼리를 단순화하여 쉽게 재사용 가능.
보안성: 원본 테이블에 대한 접근 권한을 주지 않고, 뷰를 통해서만 제한된 데이터에 접근하도록 허용할 수 있다.
논리적 독립성: 원본 테이블의 구조가 일부 변경 되더라도, 뷰의 정의만 수정하면 뷰를 사용하는 프로그램의 코드는 바꿀 필요가 없을 수도 있다.

뷰 생성

CREATE VIEW 뷰이름 AS SELECT 쿼리문;

DROP VIEW IF EXISTS v_category_order_status; -- 만약 뷰가 이미 존재한다면 제거
CREATE VIEW v_category_order_status AS
SELECT
    p.category,
COUNT(*) AS total_orders,
SUM(CASE WHEN o.status = 'COMPLETED' THEN 1 ELSE 0 END) AS 
completed_count,
SUM(CASE WHEN o.status = 'SHIPPED' THEN 1 ELSE 0 END) AS shipped_count,
SUM(CASE WHEN o.status = 'PENDING' THEN 1 ELSE 0 END) AS pending_count
FROM
    orders o
JOIN
    products p ON o.product_id = p.product_id
GROUP BY
    p.category;

뷰 조회하기

SELECT * FROM v_category_order_status;

-- WHERE 절이나 ORDER BY 사용 가능
SELECT *
FROM v_category_order_status
WHERE category = '전자기기';

뷰 수정하기

ALTER VIEW v_category_order_status AS
SELECT
    p.category,
SUM(p.price * o.quantity) AS total_sales, -- 매출액 컬럼 추가!
COUNT(*) AS total_orders,
SUM(CASE WHEN o.status = 'COMPLETED' THEN 1 ELSE 0 END) AS 
completed_count,
SUM(CASE WHEN o.status = 'SHIPPED' THEN 1 ELSE 0 END) AS shipped_count,
SUM(CASE WHEN o.status = 'PENDING' THEN 1 ELSE 0 END) AS pending_count
FROM
    orders o
JOIN
    products p ON o.product_id = p.product_id
GROUP BY
    p.category;

뷰 삭제하기

DROP VIEW v_category_order_status;

뷰를 삭제해도 원본 테이블의 데이터는 단 하나도 손상되거나 변경되지 않는다.

뷰(View)의 장점

편리성과 재사용성: 복잡한 SELECT 쿼리를 뷰 뒤에 숨길 수 있다.
보안성: 뷰는 데이터베이스에 대한 권한 제어를 가능하게 한다. 개인 정보 칼럼과 같은 민감한 정보에 대한 권한 제어가 가능하고, 특정 칼럼만 노출하게 할 수 있다.
논리적 데이터 독립성: 데이터베이스 구조가 변경되더라도 기존과 같은 형태의 뷰를 만들어 두면, 응용 프로그램은 실제 테이블 구조가 바뀐 것을 알 필요 없이 기존 코드 그대로 사용할 수 있다. 즉, 뷰는 내부 테이블 구조의 변화를 숨겨 주는 추상화 계층 역할을 한다.

뷰(View)의 단점

성능 문제: 뷰 안에 복잡한 쿼리가 있을 경우 사용자는 가벼운 쿼리라고 착각하지만 실제로는 시스템에 큰 부하를 주는 쿼리를 날리고 있을 수 있다.
업데이트 제약: 뷰는 INSERT, UPDATE, DELETE가 가능하지만 JOIN, 집계 함수, GROUP BY, DISTINCE 등을 사용한 복잡한 뷰에서는 불가능하다. 왜냐하면 뷰의 한 행을 수정하는 것이 원본 테이블들의 데이터를 어떻게 바꿔야 하는지에 대한 명확한 규칙을 특정할 수 없기 때문이다. 뷰가 오직 하나의 기본 테이블만을 참조하고, 뷰의 모든 컬럼이 기본 테이블의 실제 칼럼을 직접 참조하는 경우에는 뷰에 데이터를 추가/수정할 수 있다. 이 경우 원본 테이블의 값이 변경된다.

정리

뷰(View)는 하나 이상의 테이블로부터 생성되는 가상의 테이블이다. 실제 데이터를 저장하지 않으며 주로 SELECT 문을 통해 정의된다. 이를 통해 데이터 접근을 단순화하고 보안 및 데이터 독립성을 높일 수 있다.

본 포스팅은 “김영한의 실전 데이터베이스 기본편/인프런”를 학습한 내용을 정리한 것

<SQL> SQL 실행 순서

면목동인간 — Tue, 3 Mar 2026 21:21:17 +0900

SQL 실행 순서

SQL 실행 순서는 우리가 SQL을 작성하는 순서와 실제 SQL이 쿼리를 처리하는 순서가 다르다.

SQL 쿼리의 논리적 순서

FROM: 가장 먼저 실행. 어떤 테이블에 데이터를 가져올지 결정
WHERE: FROM에서 가져온 테이블의 개별 행을 필터링한다.
GROUP BY: WHERE 절의 필터링을 통과한 행들을 기준으로 그룹을 형성한다.
HAVING: GROUP BY를 통해 만들어진 그룹들을 필터링한다.
SELECT: 위의 조건을 통과한 행 또는 그룹들에 대해 보고자 하는 칼럼을 선택하고, 집계 함수(SUM, AVG 등등), 별칭(AS) 등이 이 단계에서 이루어진다.
ORDER BY: SELECT 절에서 선택된 최종 결과 후보들을 지정된 순서로 정렬한다. (SELECT가 ORDER BY 보다 먼저 실행하기 때문에 별칭을 사용할 수 있다.)
LIMIT: 정렬된 결과 중에서 최종적으로 반환할 행의 개수를 제한한다.

FROM -> WHERE -> GROUP BY -> HAVING -> SELECT -> ORDER BY -> LIMIT

SQL 실행 순서 쿼리 예제

2026년 3월 3일 이전에 들어온 주문 중에서(WHERE), 고객별로 그룹화하여(GROUP BY), 주문 건수가 3회 이상인 고객을 찾아서(HAVING), 고객의 이름과 총 구매 금액을 조회하고(SELECT), 총 구매 금액을 기준으로 내림차순 정렬하고(ORDER BY), 3개의 데이터만 출력해라(LIMIT).

SELECT
    customer_name,
SUM(price * quantity) AS total_purchase -- 5단계
FROM
    order_stat -- 1단계
WHERE
    order_date < '2026-03-03' -- 2단계
GROUP BY
    customer_name -- 3단계
HAVING
COUNT(*) >= 3 -- 4단계
ORDER BY
    total_purchase DESC -- 6단계
LIMIT 3; -- 7단계

정리

SQL 실행 순서는 작성한 SQL 순서와 다를 수 있다. 실제 물리적인 실행 순서는 FROM -> WHERE -> GROUP BY -> HAVING -> SELECT -> ORDER BY -> LIMIT와 같다.

본 포스팅은 “ 김영한의 실전 데이터베이스 입문 - 모든 IT인을 위한 SQL 첫걸음(SQL부터 차근차근)/인프런”를 학습한 내용을 정리한 것

<운영체제> CPU 스케줄링 알고리즘

면목동인간 — Mon, 12 Jan 2026 21:52:12 +0900

CPU 스케줄링 알고리즘

CPU 스케줄링 알고리즘은 다양하고 운영체제마다 다른 알고리즘을 사용하고 있다. 아래는 7가지 알고리즘에 대한 설명이다.

선입 선처리 스케줄링

선입 선처리 스케줄링은 FCFS 스케줄링이라고 불린다. 이는 준비 큐에 삽입된 순서대로 프로세스를 처리하는 비선점형 스케줄링 방식이다. 공정해 보이지만, 프로세스들이 기다리는 시간이 길어질 수 있다.

FCFS 스케줄링

A 프로세스가 15ms 실행 동안 B 프로세스는 15ms를 대기하고, B 프로세스가 5ms 실행 동안 C 프로세스는 1ms를 실행하기 위해 15ms+5ms를 대기하게 된다. 위 스케줄링의 평균 대기 시간은 (20+15+0) / 3 대략 12초 정도 걸린다.

최단 작업 우선 스케줄링

앞서 FCFS 스케줄링의 단점을 방지할려면 CPU 사용 시간이 긴 프로세스는 나중에 실행하고, CPU 사용 시간이 짧은 프로세스는 먼저 실행하면 된다. 기본적으로 비선점형 스케줄링으로 분류되며, 이를 최단 작업 우선 스케줄링이라고 하고 SJF 스케줄링이라고 한다.

SJF 스케줄링

위의 SJF 스케줄링은 실행 시간이 짧은 프로세스 부터 실행되며 C 프로세스가 1ms 실행 동안 B 프로세스는 1ms 대기하고, B 프로세스가 5ms 실행 동안 C 프로세스는 1ms+5ms만 대기하면 된다.

라운드 로빈 스케줄링

라운드 로빈 스케줄링 스케줄링은 RR 스케줄링이라고 하며, 선입 선처리(FCFS) 스케줄링에 타임 슬라이스라는 개념이 더해진 스케줄링 방식이다. 타임 슬라이스란 각 프로세스가 CPU를 사용할 수 있는 정해진 시간을 의미한다. 즉 정해진 시간 동안 돌아가며 CPU를 이용하는 선점형 스케줄링이다. 프로세스가 완료되지 않았다면 다시 큐의 맨 뒤에 삽입된다. 이때 문맥 교환이 발생한다.

RR 스케줄링

RR 스케줄링은 타임 슬라이스 크기가 중요하다. 타임 슬라이스 크기가 지나치게 크면 FCFS 스케줄링과 다를 바 없고, 반대로 지나치게 작으면 문맥 교환이 발생하는 비용이 커 CPU는 프로세스를 처리하는 일보다 프로세스를 전환하는 데 사용하게 된다.

최소 잔여 시간 우선 스케줄링

최소 잔여 시간 우선 스케줄링은 SRT 스케줄링이라고 하며, 최단 작업 우선(SJF) 스케줄링과 라운드 로빈(RR) 스케줄링을 합친 스케줄링이다. 즉, 작업 시간이 짧은 프로세스를 먼저 실행하며 타임 슬라이스 크기만큼 우선적으로 실행하는 방식이다.

우선순위 스케줄링

우선순위(Priotity) 스케줄링은 프로세스들에 우선순위를 부여하고, 가장 높은 우선순위를 사진 프로세스 부터 실행하는 스케줄링이다. 우선순위 대로 실행 되는데 만약 우선순위가 높은 프로세스가 큐에 들어오면 그 프로세스가 바로 실행하게 된다. 다만, 큐에 우선순위가 높은 프로세스가 계속 들어오게 되면 낮은 프로세스들은 연기가 되어 기아 현상이 발생하게 된다. 이를 방지하기 위해 에이징이 있는데 오랫동안 대기한 프로세스의 우선순위를 높이는 방식이다.

다단계 큐 스케줄링

다단계 큐 스케줄링 MLQ 스케줄링이라 하며 앞서 우선순위(Priority) 스케줄링의 발전된 형태이다. MLQ 스케줄링은 우선순위별로 준비 큐를 여러 개 사용하는 방식이다. 다단계 큐 하에서는 우선순위가 가장 높은 큐에 있는 프로세스들을 먼저 처리하고 비어 있으면 그다음 우선순위 큐에 있는 프로세스들을 처리한다.

MLQ 스케줄링

위의 큐를 여러 개 두면 프로세스를 우선순위를 구분하여 실행하는 것이 편리하다. 또한 큐별로 타임 슬라이스를 여러 개 지정할 수도 있고, 큐마다 다른 스케줄링 알고리즘을 사용할 수 있다. 다만 우선순위가 높은 큐에 프로세스가 계속 들어온다면 우선순위가 낮은 큐에 있는 프로세스는 연기될 여지가 있다.

다단계 피드백 큐 스케줄링

다단계 피드백 큐 스케줄링은 다단계 큐(MLQ) 스케줄링의 발전된 형태이다. MLQ 스케줄링은 프로세스들이 큐 사이를 이동할 수 없다. 이런 방식대로면 우선순위가 낮은 프로세스는 계속 연기될 여지가 있으며 기아 현상이 발생할 수 있다. 이를 보완한 스케줄링이 다단계 피드백 큐(MLFQ) 스케줄링이다. 보완한 것은 프로세스들이 큐 사이를 이동할 수 있다는 것이다.

MLFQ 스케줄링

위의 그림에서 프로세스가 타임슬라이스 만큼 실행한다고 가정하였다. 그런데 만약 프로세스가 해당 큐에서 실행이 끝나지 않는다면 다음 우선순위 큐에 삽입되어 실행된다. 그리고 해당 큐에서 실행이 끝나지 않는다면 프로세스는 또 다음 우선순위 큐에 삽입된다. 즉 CPU를 오래 사용하는 프로세스의 우선순위는 낮아지게 된다.

MLFQ 스케줄링

위의 그림에서 실행을 못 끝낸 프로세스가 다음 우선순위로 내려갔다. 이렇게 프로세스가 못 끝낸 상태로 우선순위가 내려간다면 낮은 우선순위에 있기 때문에 큐에 오래 기다리게 되는데 우선순위가 높은 큐로 이동시키는 에이징 기법을 적용하여 기아 현상을 예방할 수 있다. MLFQ 스케줄링은 CPU 이용 시간이 길면 낮은 우선순위로 이동시키고, 낮은 우선순위에서 오래 기다린다면 높은 우선순위 큐로 이동시키는 스케줄링이다.

정리

선입 선처리(FCFS) 스케줄링: 준비 큐에 삽입된 순서대로 CPU를 할당
최단 작업 우선(SJF) 스케줄링: 준비 큐에 삽입된 프로세스들 중 CPU 사용 시간의 길이가 가장 짧은 프로세스부터 CPU를 할당
라운드 로빈(RR) 스케줄링: 정해진 시간만큼만 돌아가며 CPU를 할당
최소 잔여 시간 우선(SRT) 스케줄링: 최단 작업 우선(SJF) 스케줄링과 라운드 로빈(RR) 스케줄링을 합친 스케줄링
우선순위(Priority) 스케줄링: 가장 높은 우선순위의 프로세스에 CPU를 할당
다단계 큐(MLQ) 스케줄링: 우선순위 별로 다단계 큐에 프로세스를 삽입하여 우선순위가 높은 큐에 CPU를 할당
다단계 피드백 큐(MLFQ) 스케줄링: 다단계 큐(MLQ) 스케줄링의 발전된 형태이며, 프로세스가 큐 사이를 이동할 수 있는 스케줄링

본 포스팅은 “혼자 공부하는 컴퓨터 구조 + 운영체제/강민철 저”를 읽고 학습한 내용을 정리한 것