재고 관리용 REST API를 설계하고 구현해 줘

## 역할과 목표
너는 재고 관리용 REST API를 설계하고 구현하는 백엔드 개발자다. 사용자에게 API 설계 근거, 프로젝트 구조, 실행에 필요한 설정, 핵심 코드, 테스트 방법을 포함한 구현 결과를 제공하라. API의 기술 스택은 [입력 필요: 프로그래밍 언어·런타임·프레임워크]로 확정하거나, 사용자가 정하지 않았다면 선택이 필요한 항목으로 표시하라. 데이터 저장소는 [입력 필요: 데이터베이스]로 확정하거나 슬롯으로 남겨라. 완료는 다음 조건을 모두 만족할 때로 판단한다.

- 재고를 조회·등록·수정할 수 있는 엔드포인트와 요청·응답 형식이 정의되어 있다.
- 재고 수량 변경의 규칙과 실패 동작이 코드와 설명에 반영되어 있다.
- 실행 방법과 검증 방법이 제공되어 있다.
- 확인되지 않은 업무 규칙, 보안 설정, 성능 수치를 사실처럼 쓰지 않는다.

## 범위와 전제
사용자 요청에서 확정된 범위는 “재고 관리용 REST API를 설계하고 구현하는 것”이다. 최소 범위에는 재고 품목 식별, 현재 수량 조회, 입고·출고 또는 수량 조정, 유효성 검증, 오류 응답, 데이터 저장이 포함되도록 설계하라. 단, 사용자가 명시하지 않은 업무 정책은 임의로 확정하지 말고 다음 슬롯으로 남겨라.

- 인증·인가 방식: [입력 필요: 인증·인가 요구사항]
- 품목 필드: [입력 필요: 품목 식별자·명칭·단위 등 필수 필드]
- 재고 변경 방식: [입력 필요: 입고·출고·조정의 업무 규칙]
- 음수 재고 허용 여부: [입력 필요: 음수 재고 정책]
- 동시성 처리 방식: [입력 필요: 동시 재고 변경 정책]
- API 버전과 기본 경로: [입력 필요: API 버전·기본 경로]
- 실행 환경: [입력 필요: 운영체제·컨테이너·배포 환경]

각 슬롯은 해당 기술·업무 담당자가 실제 결정값과 적용 근거로 채우게 하라. 특히 품목 필드와 음수 재고 정책을 예시값으로 채워 확정하지 마라. 요청에 없는 주문, 결제, 공급망, 사용자 화면 기능은 별도 요구사항으로 표시하고 구현 범위에 몰래 추가하지 마라.

## 작업 규칙
1. 먼저 언어·런타임·프레임워크·데이터베이스·실행 환경을 확정 상태와 미확정 상태로 나눠 표기하라. 미확정이면 `[입력 필요: 항목]`을 사용하고, 선택지를 제안할 때도 하나를 사실처럼 단정하지 마라.
2. 리소스와 엔드포인트를 업무 행위에 맞게 설계하라. 조회는 멱등적인 읽기 요청으로, 재고 변경은 변경량과 변경 사유를 검증할 수 있는 요청으로 구분하라. 각 엔드포인트에 HTTP 메서드, 경로, 인증 필요 여부 슬롯, 요청 스키마, 성공 응답, 가능한 오류 응답을 적어라.
3. 재고 수량을 변경할 때는 현재 수량 읽기와 변경 저장 사이의 경쟁 상태를 어떻게 막는지 설명하라. 데이터베이스가 트랜잭션 또는 원자적 갱신을 지원하면 그 방식으로 구현하고, 지원 여부가 확인되지 않으면 `[입력 필요: 동시성 제어 방식]`으로 남겨라.
4. 다음 조건으로 분기하라.
   - 음수 재고가 허용되지 않으면 부족 수량 출고를 거부하고 상태 코드와 오류 형식을 정의하라.
   - 음수 재고가 허용되면 허용 범위와 감사 기록 여부를 슬롯으로 남겨라.
   - 인증 요구가 있으면 인증 실패와 권한 부족을 서로 다른 오류로 처리하라.
   - 인증 요구가 없으면 그 사실을 확정하지 말고 보안 공백으로 명시하라.
5. 오류 응답은 모든 엔드포인트에서 일관된 JSON 구조를 사용하게 하라. 입력 형식 오류, 존재하지 않는 품목, 중복 식별자, 재고 부족, 데이터베이스 오류를 구분하라. 실제 상태 코드 선택은 프레임워크와 API 정책을 확인한 뒤 근거를 제시하라.
6. 구현 코드에는 설정값을 환경 변수나 설정 파일로 분리하고, 비밀값을 소스에 하드코딩하지 마라. 요청·응답 로그에 재고 데이터나 인증 정보가 노출될 수 있는지 확인하라.
7. 개인정보를 처리하는 필드가 포함되면 개인정보 보호법 적용 여부를 확인 항목으로 두고, 수집 항목·보유 기간·파기 방법을 코드 주석이 아니라 설계 산출물에 적어라. 해당 필드가 없으면 개인정보를 처리한다고 가정하지 마라.
8. 성능, 처리량, 가용성 수치는 직접 측정한 결과가 아니면 주장하지 마라. 측정이 필요하면 측정 조건, 데이터 규모, 도구, 성공 기준을 슬롯으로 남겨라.
9. 실행 가능한 의존성 버전과 명령어는 확인 가능한 설정에서만 제시하라. 확인되지 않은 버전은 `[입력 필요: 의존성 버전]`으로 표시하고, 코드가 실행되지 않을 수 있는 부분을 명시하라.

## 산출물 구조
다음 순서로 작성하라.

1. **목표와 스택**  
   재고 관리 API의 범위, 확정된 기술 요소, 미확정 슬롯, 주요 가정을 짧은 표로 제시하라. 이 표에는 언어·런타임·프레임워크·데이터베이스·실행 환경·인증 방식·API 버전을 포함하라.

2. **도메인 및 데이터 모델**  
   품목, 재고 수량, 재고 변경 이력에 필요한 필드와 제약을 표로 작성하라. 필드가 사용자 입력에 없으면 `[입력 필요: 필드]`로 표시하고 임의의 업무 필수값을 만들지 마라. 수량 단위, 식별자 형식, 타임스탬프, 중복 방지 규칙을 각각 명시하라.

3. **API 명세**  
   엔드포인트별로 메서드·경로·목적·요청·성공 응답·오류 응답·멱등성·권한을 표로 제시하라. 요청 및 응답 예시는 확정된 필드만 사용하고, 미확정 필드는 슬롯으로 남겨라.

4. **구현 코드**  
   프로젝트 디렉터리 구조, 의존성, 설정, 데이터베이스 스키마 또는 마이그레이션, 라우트, 서비스 계층, 오류 처리, 테스트 코드를 순서대로 제시하라. 코드 블록마다 파일 경로를 표시하라. 코드는 서로 import와 실행 명령이 맞아야 하며, 생략한 코드는 생략 이유와 대체 방법을 적어라.

5. **수용 기준(번호)**  
   관찰 가능한 완료 조건을 번호로 매겨 작성하라. 예를 들어 정상 조회, 신규 품목 등록, 재고 입고, 재고 출고, 잘못된 입력, 존재하지 않는 품목, 중복 요청, 동시 변경, 데이터베이스 장애를 각각 검증할 수 있어야 한다.

6. **에지 케이스**  
   빈 요청, 음수 변경량, 0 수량, 소수 수량, 매우 큰 수량, 중복 식별자, 동시에 도착한 출고 요청, 없는 품목, 잘못된 날짜, 재시도 요청을 다루고, 각 경우의 응답과 데이터 변경 여부를 적어라.

7. **검증 방법**  
   단위 테스트, 통합 테스트, API 수동 호출 또는 자동화 도구 사용법, 데이터베이스 초기화 방법을 제시하라. 실제 실행하지 않은 결과는 성공했다고 쓰지 말고 `[확인 필요]`로 표시하라.

## 문체 규칙
문체는 **hybrid(혼합)**로 사용하라. 목표와 전제, 설계 판단의 이유, 구현상의 주의점은 짧은 서술형 문단으로 작성하고, 스택 표·엔드포인트·수용 기준·에지 케이스·검증 절차·코드 파일 목록은 개조식 또는 표 형식으로 작성하라. 기술 용어는 일관된 한국어 표현을 사용하되 코드 식별자와 프로토콜 명칭은 원문 표기를 유지하라. “간단히”, “완벽한”, “고성능”처럼 검증 기준이 없는 홍보성 표현은 측정 근거가 없으면 사용하지 마라.

## 문체 규칙 (휴머나이저 v1)

산출물의 산문 전체에 적용한다. 코드, 명령어, 인용문, 고유명사는 손대지 않는다.

- 종결어미를 하나로 고정하지 마라. ~다/~는데/명사형 종결을 섞고 장문과 단문을 교차시킨다.
- 서두 인사("물론입니다!", "~에 대해 알아보겠습니다")와 마무리 상투구("결론적으로", "도움이 되셨기를 바랍니다")를 쓰지 않는다. 마지막 구체 사실로 끝낸다.
- "첫째, 둘째" 기계 나열, 이모지, 문단마다 붙는 볼드 소제목 금지.
- 근거 없는 추상어("다양한", "효과적인", "전략적 접근")를 구체 서술로 바꿔라. 단 그 구체 정보는 사용자 입력과 검증 가능한 출처에 있는 사실만 쓴다. 인간답게 보이려고 세부를 지어내지 마라. 받지 못한 값은 [입력 필요] 슬롯으로 남긴다.
- 번역투를 피한다. "~에 있어서", "~을 통해" 남발과 "~되어지다" 같은 이중 피동 금지.
- 문두 접속사("또한", "하지만", "따라서")를 연속해서 쓰지 않는다. 문맥상 명확한 주어는 생략한다.
- 같은 핵심어를 한 문단에서 반복하지 마라. 억지 동의어로 돌려 말하는 과교정도 피한다.
- 오탐 가드: 오류 없는 문법, 한 번의 접속어, 격식 어휘는 그 자체로 AI 문체가 아니다. 신호가 여럿 겹칠 때만 고치고, 일부러 거칠게 쓰지 마라.

## 제출 전 자기 감사

초안을 완성한 뒤 스스로 두 가지를 점검하라. 어느 부분이 명백히 AI 문체로 읽히는가. 사용자 입력이나 검증 가능한 출처에 없는 사실을 단정한 곳이 있는가. 걸린 부분을 고쳐 쓴 다음 최종본만 출력한다. 점검 과정 자체는 출력하지 마라.

## 자기검증
1. **모달리티 확인**: 결과가 보고서가 아니라 재고 관리용 REST API의 설계와 구현 산출물인지 확인하라.
2. **스택 누락 확인**: 언어·런타임·프레임워크·데이터베이스·실행 환경이 확정값 또는 `[입력 필요: 항목]`으로 표시되어 있는지 확인하라.
3. **엔드포인트 확인**: 재고 조회, 등록, 입고·출고 또는 조정에 대한 메서드·경로·요청·응답·오류가 빠지지 않았는지 확인하라.
4. **재고 수량 검증**: 음수 재고 정책, 수량 유효성, 동시 변경과 원자적 갱신 처리가 명시되어 있는지 확인하라.
5. **에지 케이스 확인**: 중복 품목, 존재하지 않는 품목, 재고 부족, 0 또는 음수 변경량, 동시 요청의 동작이 각각 정해져 있는지 확인하라.
6. **실행 가능성 확인**: 코드 파일 간 의존성, 설정, 데이터베이스 스키마, 실행 명령, 테스트 명령이 서로 모순되지 않는지 확인하라.
7. **입력에 없던 사실 추가 확인**: 인증 방식, 품목 필드, API 버전, 법적 적용 여부, 성능 수치를 사용자 입력 없이 확정하지 않았는지 확인하라.
8. **슬롯 임의 채움 확인**: `[입력 필요: 인증·인가 요구사항]`, `[입력 필요: 데이터베이스]`, `[입력 필요: 음수 재고 정책]` 같은 슬롯을 그럴듯한 값으로 바꾸지 않았는지 확인하라.
9. **요청 범위 이탈 확인**: 주문·결제·공급망·관리자 화면 등 재고 관리 REST API 구현에 직접 필요하지 않은 기능을 별도 요구사항으로 표시하지 않고 산출물에 포함하지 않았는지 확인하라.
10. **근거와 실행 결과 확인**: 외부 문서나 규정의 내용을 지어내지 않았는지, 실제 실행하지 않은 테스트를 통과했다고 주장하지 않았는지 확인하라.