EP13. List를 이용한 상품 관리 애플리케이션 만들기 1편

 

---

요구사항 분석

 

애플리케이션을 만들 때 가장 먼저 해야 하는 일은 코드를 작성하는 것이 아니라,

무엇을 만들어야 하는지 명확히 정리하는 것이다.

 

이번 예제는 상품을 관리할 수 있는 애플리케이션을 만드는 것이 목표다.

 

예제에서 정한 요구사항은 다음과 같다. 

이 애플리케이션에서 상품은 총 네 가지 정보를 가진다. 
상품 번호, 상품 이름, 가격, 재고 수량이 그것이다.

먼저 상품 번호는 1부터 시작하며, 상품이 하나 추가될 때마다 1씩 증가해야 한다. 
또한 동일한 상품 번호를 가지는 상품은 존재할 수 없다. 
즉, 상품 번호는 각 상품을 구분하는 고유한 값으로 사용된다.

상품 이름은 1글자 이상 100글자 이하의 문자열이어야 한다. 
다만 상품 번호와는 다르게, 동일한 상품 이름을 가지는 상품은 존재할 수 있다. 
즉, 이름은 중복 가능하지만 길이 제한은 지켜야 한다.

가격은 0원 이상 1,000,000원 이하의 값을 가질 수 있어야 한다. 
재고 수량은 0개 이상 9,999개 이하의 값을 가질 수 있다. 
따라서 가격과 재고 수량 모두 음수가 될 수 없으며, 각각 정해진 범위를 벗어나지 않도록 관리해야 한다.

이 애플리케이션에서 상품에 대해 가능한 기능은 다음과 같다.
첫째, 상품을 하나씩 추가할 수 있어야 한다.

둘째, 상품을 조회할 수 있어야 한다. 조회 기능은 상품 번호를 기준으로 하나의 상품을 조회하는 기능, 
전체 상품 목록을 조회하는 기능, 그리고 상품 이름에 포함된 특정 문자열을 기준으로 검색하는 기능을 
포함해야 한다.

셋째, 상품 정보를 수정할 수 있어야 한다. 수정은 상품 번호를 기준으로 이루어지며, 
상품 번호를 제외한 나머지 정보인 상품 이름, 가격, 재고 수량을 변경할 수 있어야 한다.

넷째, 상품을 제거할 수 있어야 한다. 삭제 역시 상품 번호를 기준으로 
특정 상품 하나를 제거할 수 있어야 한다.

정리하면, 이번 애플리케이션은 상품 번호를 기준으로 상품을 식별하고, 
상품 추가, 조회, 검색, 수정, 삭제 기능을 제공하는 구조라고 볼 수 있다. 
또한 각 상품 데이터에는 이름 길이, 가격 범위, 재고 수량 범위 같은 
기본적인 제약 조건이 함께 존재한다.

 

이런 요구사항을 먼저 정리해두면, 단순히 “상품을 저장한다”에서 끝나는 것이 아니라

어떤 데이터를 어떤 규칙 아래 다뤄야 하는지가 구체적으로 보이기 시작한다.

 

예를 들어 상품 이름은 중복이 가능하지만 상품 번호는 중복되면 안 된다는 점을 보면,

상품 번호는 식별자 역할을 한다는 것도 자연스럽게 알 수 있다.

또 가격과 재고 수량에는 범위 제한이 있으므로, 나중에는 입력 검증도 필요하겠다는 점까지 미리 생각해볼 수 있다.

 

행동 요구사항도 중요하다. 상품에 대해 가능한 동작은 크게 상품 추가, 상품 조회, 상품 정보 수정, 상품 제거로 나눌 수 있다.

여기서 조회도 하나만 있는 것이 아니라

상품 번호로 단건 조회, 전체 목록 조회, 이름에 특정 문자열이 포함된 상품 검색처럼 세분화되어 있다.

 

이런 요구사항을 하나씩 정리해보면,

결국 이번 애플리케이션은 상품이라는 데이터를 중심으로 CRUD와 검색 기능을 구현하는 구조라는 것을 알 수 있다.

 

즉, 요구사항 분석은 단순히 기능 목록을 읽는 단계가 아니라,

이후에 어떤 클래스가 필요하고 어떤 데이터 구조가 적절한지 결정하는 출발점이라고 볼 수 있다.

 

---

프로젝트 생성

 

이번 예제에서는 Spring Initializr를 사용해 스프링부트 프로젝트를 생성한다.

이런 방식으로 시작하면 웹 애플리케이션을 만들기 위한 기본 구조가 자동으로 준비되기 때문에,

개발자는 세세한 초기 설정보다 실제 기능 구현에 더 집중할 수 있다.

 

프로젝트 생성 예시는 다음과 같다. 

 

 

여기서 그룹과 아티팩트는 프로젝트의 고유한 이름과 패키지 구조를 정하는 데 사용된다.

예를 들어 com.jiwoo.product.management 같은 패키지 구조는 이후 자바 클래스가 어떤 이름 공간 안에 놓일지를 결정한다.

아티팩트 이름도 단순한 문자열이 아니라, 이 프로젝트가 어떤 역할을 하는지 드러내는 식별자라고 볼 수 있다.

 

또 Java 버전과 패키징 방식(JAR/War), 설정 파일 형식(Properties/YAML)도 함께 선택하게 된다.

이런 것들은 당장 처음 구현할 때는 크게 체감되지 않을 수 있지만,

프로젝트의 실행 방식과 구조에 영향을 주는 기본 설정들이다.

 

특히 Spring Web을 추가했다는 것은 이 프로젝트가 단순한 자바 프로그램이 아니라,

HTTP 요청을 받고 응답할 수 있는 웹 애플리케이션으로 동작할 준비를 갖춘다는 의미이기도 하다.

 

---

데이터 구조 정의

 

요구사항을 보면 이번 애플리케이션의 핵심 데이터는 결국 상품(Product) 이다.

따라서 기능 구현에 들어가기 전에, 상품이 어떤 정보로 이루어져 있는지를 코드로 먼저 표현하는 것이 중요하다.

이런 역할을 하는 것이 바로 Product 클래스다.

 

package com.jiwoo.product.management;

public class Product {
    private Long id;
    private String name;
    private Integer price;
    private Integer amount;
}

 

이 클래스는 상품 하나를 표현하기 위한 가장 기본적인 데이터 구조다.

id는 상품 번호, name은 상품 이름, price는 가격, amount는 재고 수량을 의미한다.

즉, 요구사항에서 말한 “상품은 네 가지 정보를 가진다”는 내용을 코드로 옮긴 결과라고 볼 수 있다.

 

여기서 중요한 점은, 지금은 아직 기능을 구현하지 않았더라도

데이터 구조를 먼저 정의해두면 이후 코드가 훨씬 명확해진다는 것이다.

 

상품 추가 기능을 만들 때는 Product 객체 하나를 생성해서 리스트에 넣으면 되고,

상품 조회는 이 객체를 찾아 반환하면 되며, 상품 수정은 해당 객체의 값을 바꾸는 방식으로 접근할 수 있다.

즉, Product 클래스는 나중에 만들어질 모든 기능의 중심이 되는 기본 단위다.

 

또한 이렇게 클래스로 데이터를 표현하는 것은 단순히 값을 여러 개 묶어두는 것 이상의 의미가 있다.

상품에 대한 정보가 하나의 타입으로 정의되면, “이 값들이 하나의 상품이다”라는 개념이 코드 안에서 분명해진다.

 

---

long vs Long

 

Product 클래스에서 id를 long이 아니라 Long으로 작성한 이유를 이해하려면,

먼저 자바의 기본형과 래퍼 클래스의 차이를 알아둘 필요가 있다.

long은 자바의 프리미티브 타입(기본형) 이고, Long은 그 기본형을 객체처럼 다룰 수 있게 만든 래퍼 클래스다.

 

가장 큰 차이는 메모리에 저장되는 방식이다.

프리미티브 타입은 그 값 자체만 저장할 공간이 필요하다. 예를 들어 long은 숫자 값을 직접 담는다.

반면 Long은 객체이기 때문에, 값 자체뿐 아니라 그 객체를 위한 인스턴스가 만들어지고,

그 인스턴스를 가리키는 참조 개념도 함께 생긴다.

그래서 일반적으로는 프리미티브 타입이 더 가볍고 성능 면에서도 유리한 경우가 많다.

 

그렇다고 항상 프리미티브 타입만 쓰는 것이 정답은 아니다.

래퍼 클래스는 프리미티브 타입에는 없는 장점도 가지고 있다.

대표적으로 null을 가질 수 있다는 점이 있다.

예를 들어 아직 id가 부여되지 않은 상태를 표현하고 싶다면 long은 무조건 숫자 값을 가져야 하지만,

Long은 null로 “아직 값이 없음”을 표현할 수 있다.

 

또한 ArrayList<Long> 같은 컬렉션의 요소로 사용할 수도 있다.

자바의 제네릭 컬렉션은 기본형을 직접 담을 수 없기 때문에, 이런 경우 래퍼 클래스가 필요하다.

 

또 실무에서 많이 접하게 되는 JPA 같은 라이브러리도 보통 엔티티의 식별자 타입으로 래퍼 클래스를 사용하는 경우가 많다.

왜냐하면 데이터가 아직 저장되지 않은 상태를 null로 표현해야 하는 경우가 있기 때문이다.

이런 맥락을 생각하면, 지금 예제에서 Long id를 사용하는 것도 단순한 취향 차이가 아니라

확장성과 표현력까지 고려한 선택이라고 볼 수 있다.