이전 글에서는 회원 등록 예제를 만들면서 회원 객체를 만들고, 메모리 저장소에 저장하고, 다시 조회하는 흐름을 살펴봤습니다.

그때 우리는 DB를 사용하지 않고 ArrayList에 회원을 저장했습니다.

private final List<Member> members = new ArrayList<>();

처음 배우는 단계에서는 이 방식이 좋습니다.

왜냐하면 DB 설정 없이도 요청 → 저장 → 조회 → 응답 흐름을 빠르게 이해할 수 있기 때문입니다.

하지만 실제 서비스에서는 메모리 저장소만으로는 부족합니다.

이번 글에서는 DB에 들어가기 전에, 왜 Repository가 필요하고 왜 결국 DB가 필요한지 정리해보겠습니다.

이번 글의 목표는 딱 하나입니다.

DB 들어가기 전 이유 이해하기

먼저 결론부터 보기

메모리 저장소는 배우기에는 쉽지만, 실제 서비스에는 한계가 있습니다.

가장 큰 이유는 이것입니다.

서버를 끄면 저장된 데이터가 사라집니다.

예를 들어 회원을 두 명 등록했다고 해보겠습니다.

kim
park

서버가 실행 중일 때는 회원 목록이 잘 보입니다.

하지만 Spring Boot 서버를 종료하고 다시 실행하면 이 데이터는 사라집니다.

왜냐하면 ArrayList는 프로그램이 실행되는 동안만 유지되는 메모리 공간이기 때문입니다.

메모리 저장소란?

메모리 저장소는 프로그램이 실행되는 동안만 데이터를 임시로 저장하는 방식입니다.

이전 예제에서는 이런 코드를 사용했습니다.

@Repository
public class MemberRepository {

    private final List<Member> members = new ArrayList<>();

    public void save(Member member) {
        members.add(member);
    }

    public List<Member> findAll() {
        return members;
    }
}

여기서 members 리스트가 임시 저장소 역할을 합니다.

회원이 등록되면 리스트에 들어가고, 회원 목록을 조회하면 리스트에 있는 값을 반환합니다.

초보자 입장에서는 구조를 이해하기 쉽습니다.

하지만 이 방식은 실제 서비스에 그대로 쓰기 어렵습니다.

메모리 저장소의 한계

메모리 저장소의 한계는 크게 세 가지입니다.

1. 서버를 끄면 데이터가 사라진다

가장 큰 문제입니다.

메모리는 프로그램이 실행되는 동안만 유지됩니다.

Spring Boot 서버를 종료하면 members 리스트도 함께 사라집니다.

즉, 아래처럼 회원을 등록해도

http://localhost:8080/members/new?name=kim

서버를 다시 시작하면 저장된 kim은 없어집니다.

실제 서비스에서 회원 정보가 서버 재시작마다 사라지면 사용할 수 없습니다.

그래서 데이터를 오래 보관할 공간이 필요합니다.

그 역할을 하는 것이 DB입니다.

2. 여러 서버가 함께 쓰기 어렵다

처음에는 서버 하나만 실행합니다.

하지만 실제 서비스에서는 서버를 여러 대 실행할 수 있습니다.

예를 들어 서버 A와 서버 B가 있다고 해보겠습니다.

사용자 1 → 서버 A
사용자 2 → 서버 B

서버 A의 메모리에 저장한 데이터는 서버 B의 메모리에는 없습니다.

즉, 각 서버가 자기 메모리만 따로 가지고 있습니다.

이러면 사용자마다 다른 데이터를 보게 될 수 있습니다.

그래서 여러 서버가 공통으로 사용할 수 있는 저장소가 필요합니다.

그 저장소가 DB입니다.

3. 검색, 수정, 삭제가 불편하다

ArrayList에 데이터를 저장하면 간단한 조회는 할 수 있습니다.

하지만 데이터가 많아질수록 관리가 어렵습니다.

예를 들어 이런 기능을 만든다고 해보겠습니다.

  • 이름으로 회원 찾기
  • 회원 정보 수정하기
  • 특정 회원 삭제하기
  • 가입일 기준으로 정렬하기
  • 중복 회원 검사하기

리스트만으로도 만들 수는 있지만, 기능이 많아지면 코드가 복잡해집니다.

DB는 이런 데이터 관리 기능을 훨씬 체계적으로 처리할 수 있습니다.

그래서 왜 DB가 필요할까?

DB는 데이터를 오래 보관하고 관리하기 위한 저장소입니다.

쉽게 말하면, DB는 서비스의 데이터 창고입니다.

회원 서비스라면 DB에 이런 정보가 저장될 수 있습니다.

  • 회원 ID
  • 이름
  • 이메일
  • 비밀번호
  • 가입일

게시판 서비스라면 이런 정보가 저장될 수 있습니다.

  • 게시글 ID
  • 제목
  • 내용
  • 작성자
  • 작성일

즉, DB는 서비스가 꺼졌다 켜져도 유지되어야 하는 데이터를 저장합니다.

메모리 저장소와 DB를 비교하면 이렇게 볼 수 있습니다.

구분메모리 저장소DB
데이터 유지서버 종료 시 사라짐서버를 꺼도 유지됨
학습 난이도쉬움설정과 개념이 더 필요함
실제 서비스 사용부적합적합
데이터 검색/관리직접 구현 필요SQL, 인덱스 등 활용 가능

처음에는 메모리 저장소로 흐름을 배우고, 그다음 DB로 넘어가는 것이 좋습니다.

Repository는 왜 필요할까?

여기서 중요한 질문이 하나 생깁니다.

"어차피 DB를 쓸 거면 Service에서 바로 DB에 저장하면 안 되나?"

가능은 합니다.

하지만 좋은 방식은 아닙니다.

Service가 DB 저장 방식까지 직접 알게 되면 코드가 복잡해집니다.

그래서 데이터 저장과 조회는 Repository가 담당하게 나눕니다.

Service = 어떤 규칙으로 처리할지 판단
Repository = 데이터를 어디에 어떻게 저장할지 담당

즉, Repository는 데이터 접근을 담당하는 계층입니다.

Repository의 역할

Repository는 데이터를 저장하고 조회하는 역할을 합니다.

회원 기능을 기준으로 보면 Repository는 이런 일을 합니다.

  • 회원 저장하기
  • 회원 전체 조회하기
  • ID로 회원 찾기
  • 이름으로 회원 찾기
  • 회원 삭제하기

즉, Repository는 데이터와 관련된 작업을 모아두는 곳입니다.

처음에는 이렇게 기억하면 됩니다.

Repository는 데이터 창고와 대화하는 코드입니다.

지금은 그 창고가 ArrayList이고, 나중에는 그 창고가 DB로 바뀌는 것입니다.

저장소가 바뀌어도 Service는 덜 흔들리게 하기

Repository를 나누는 가장 큰 장점은 저장 방식이 바뀌어도 코드 영향이 줄어든다는 점입니다.

처음에는 메모리에 저장합니다.

MemberRepository → ArrayList에 저장

나중에는 DB에 저장합니다.

MemberRepository → MySQL 또는 H2에 저장

이때 Controller와 Service의 흐름은 크게 바뀌지 않을 수 있습니다.

왜냐하면 Service는 Repository에게 이렇게 말할 뿐입니다.

회원 저장해줘.
회원 목록 조회해줘.

Repository 내부가 ArrayList인지 DB인지는 Service가 자세히 몰라도 됩니다.

이렇게 역할을 나누면 코드가 더 유연해집니다.

흐름으로 다시 보기

회원 등록 요청이 들어오면 흐름은 이렇게 됩니다.

브라우저
  ↓
Controller
  ↓
Service
  ↓
Repository
  ↓
저장소

여기서 저장소는 처음에는 메모리입니다.

Repository → ArrayList

나중에는 DB가 됩니다.

Repository → Database

즉, Repository는 Service와 저장소 사이의 연결 지점입니다.

예시 코드 다시 보기

메모리 저장소를 사용하는 Repository는 이렇게 생겼습니다.

@Repository
public class MemberRepository {

    private final List<Member> members = new ArrayList<>();

    public Member save(Member member) {
        members.add(member);
        return member;
    }

    public List<Member> findAll() {
        return members;
    }
}

이 코드는 지금은 ArrayList에 저장합니다.

하지만 나중에 DB를 연결하면 Repository 내부 구현이 바뀔 수 있습니다.

중요한 것은 역할입니다.

Repository는 데이터를 저장하고 조회한다.

이 역할은 저장소가 메모리든 DB든 변하지 않습니다.

Service는 무엇에 집중해야 할까?

Service는 데이터 저장 방법보다 서비스 규칙에 집중해야 합니다.

예를 들어 회원가입에서는 이런 규칙이 있을 수 있습니다.

  • 이름이 비어 있으면 가입 불가
  • 이미 같은 이름이 있으면 가입 불가
  • 조건을 통과하면 저장

이런 판단은 Service가 담당합니다.

@Service
public class MemberService {

    private final MemberRepository memberRepository;

    public MemberService(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }

    public Member join(Member member) {
        if (member.getName() == null || member.getName().isBlank()) {
            throw new IllegalArgumentException("이름은 비어 있을 수 없습니다.");
        }

        return memberRepository.save(member);
    }
}

Service는 Repository를 사용하지만, 저장소가 ArrayList인지 DB인지는 깊게 신경 쓰지 않는 쪽이 좋습니다.

초보자가 헷갈리기 쉬운 부분

1. Repository는 DB 그 자체인가?

아닙니다.

Repository는 DB가 아니라 DB와 대화하는 코드입니다.

지금은 DB 대신 메모리 리스트와 대화하고 있습니다.

나중에 DB를 연결하면 Repository가 DB와 대화하게 됩니다.

2. 메모리 저장소는 쓸모없는가?

쓸모없지 않습니다.

학습 단계에서는 아주 좋습니다.

DB 설정 없이도 저장과 조회 흐름을 이해할 수 있기 때문입니다.

다만 실제 서비스에서는 데이터가 사라지면 안 되므로 DB가 필요합니다.

3. DB를 배우기 전에 Repository를 왜 배울까?

DB를 바로 배우면 설정과 문법 때문에 흐름을 놓치기 쉽습니다.

먼저 Repository 역할을 이해하면, 나중에 DB를 붙일 때 훨씬 이해하기 쉽습니다.

즉, Repository는 DB로 가기 위한 중간 다리입니다.

4. Controller에서 바로 DB를 쓰면 안 될까?

작은 예제에서는 가능할 수 있습니다.

하지만 기능이 늘어나면 Controller가 너무 많은 일을 하게 됩니다.

Controller는 요청과 응답에 집중하고, 데이터 접근은 Repository로 분리하는 것이 좋습니다.

오늘 배운 것

이번 글에서는 DB에 들어가기 전에 Repository 개념을 정리했습니다.

핵심은 아래와 같습니다.

  • 메모리 저장소는 서버를 끄면 데이터가 사라짐
  • 실제 서비스에서는 데이터를 오래 보관하기 위해 DB가 필요함
  • Repository는 데이터를 저장하고 조회하는 역할
  • Repository는 저장소와 대화하는 코드
  • 처음에는 ArrayList를 사용하고, 나중에는 DB로 바꿀 수 있음
  • Service는 저장 방법보다 서비스 규칙에 집중하는 것이 좋음

정리

메모리 저장소는 Spring Boot 흐름을 배우기에 좋은 출발점입니다.

하지만 실제 서비스에서는 데이터가 사라지면 안 됩니다.

그래서 결국 DB가 필요합니다.

이때 Repository는 Service와 DB 사이에서 데이터를 저장하고 조회하는 역할을 합니다.

처음에는 이렇게 기억하면 됩니다.

Service = 규칙을 처리하는 곳
Repository = 데이터를 다루는 곳
DB = 데이터를 오래 보관하는 곳

DB를 배우기 전에 Repository의 역할을 먼저 이해하면, 나중에 H2나 MySQL을 연결할 때 훨씬 덜 헷갈립니다.

다음 글에서는 H2 또는 MySQL을 연결해서 실제 DB에 데이터를 저장하는 흐름을 정리해보겠습니다.