SamProject/sam-docs
6
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: [bending] 절곡품 전용 테이블 분리 완료 문서

Browse Source 
- README: bending_items 266건 + bending_models 62건 DB 검증 완료
- README: 하장바 검색 문제 해결 (10건 정상)
- README: bending_data JSON 통합, bending_item_mappings DROP
- README: LOT 코드 체계, 테이블 관계도, 레거시 대응표 갱신
- step1: 데이터분석 업데이트
- step5: canvas 그리기 추가
- .gitattributes CRLF→LF 정규화
This commit is contained in:
강영보
2026-03-19 20:03:46 +09:00
parent 6484e73976
commit 220ab78041
41 changed files with 16081 additions and 14435 deletions
Download Patch File Download Diff File Expand all files Collapse all files

266
dev/changes/20260311_daily_fund_sync_and_account_codes_fix.md
View File

@@ -1,133 +1,133 @@
# 자금일보 바로빌 자동동기화 및 계정과목 데이터 정리
**날짜:** 2026-03-11
**작업자:** Claude Code
---
## 변경 개요
두 가지 문제를 수정한다:
1. **자금일보 출금 내역 누락** — `periodReport()`가 DB 캐시만 조회하고 바로빌 API 동기화를 트리거하지 않아, 최신 거래내역이 반영되지 않는 문제
2. **홈택스 분개 계정과목 오류** — 드롭다운에 2,549개 코드 표시(정상: 163개), 분개 기본값에 존재하지 않는 코드 사용
---
## 수정된 파일
| 파일 | 프로젝트 | 변경 내용 |
|------|---------|----------|
| `app/Services/Barobill/BarobillBankSyncService.php` | MNG (신규) | 바로빌 계좌 거래내역 동기화 서비스 |
| `app/Http/Controllers/Finance/DailyFundController.php` | MNG | `periodReport()`에 자동 동기화 호출 추가 |
| `resources/views/barobill/hometax/index.blade.php` | MNG | 분개 기본 계정과목 코드 수정 |
| `database/migrations/2026_03_11_101502_fix_account_codes_duplicate_data.php` | API (신규) | 중복 계정과목 비활성화 + 분개 코드 일괄 수정 |
---
## 상세 변경 사항
### 1. 바로빌 자동 동기화 서비스 (MNG)
**문제**: `DailyFundController::periodReport()`는 `barobill_bank_transactions` 테이블만 조회한다. 바로빌 API에서 데이터를 가져오는 동기화는 `EaccountController`에서만 수행되어, 자금일보 페이지에서는 캐시가 갱신되지 않으면 최신 거래가 누락된다.
**해결**: `EaccountController`의 동기화 로직을 `BarobillBankSyncService`로 분리하여 재사용 가능하게 한다.
```
DailyFundController::periodReport()
│
├── BarobillBankSyncService::syncIfNeeded() ← 신규
│ ├── BarobillMember 조회 (바로빌 인증)
│ ├── SOAP 클라이언트 초기화
│ ├── 등록 계좌 목록 조회
│ └── 월별 청크 순회
│ ├── BankSyncStatus 캐시 판단
│ │ ├── 과거 월: 항상 캐시 (API 호출 안 함)
│ │ └── 현재 월: 10분 이내면 캐시
│ └── 필요 시 API 호출 → DB 캐시 저장
│
└── DB에서 거래내역 조회 (기존 로직)
```
**캐시 정책**:
| 조건 | 동작 |
|------|------|
| 과거 월 + 동기화 이력 있음 | 캐시 사용 (API 호출 안 함) |
| 현재 월 + 10분 이내 동기화 | 캐시 사용 |
| 현재 월 + 10분 초과 | API에서 갱신 |
| 동기화 이력 없음 | API에서 갱신 |
**실패 처리**: 동기화 실패 시 예외를 catch하고 로그만 남기며, 기존 DB 캐시로 응답을 계속한다.
---
### 2. 계정과목 중복 데이터 정리 (API 마이그레이션)
**문제**: `account_codes` 테이블에 비표준 코드가 대량 등록되어 드롭다운이 오염되었다.
| 코드 유형 | 건수 | 예시 | 상태 |
|----------|------|------|------|
| 3자리 더존 표준 코드 | 163개 | `101` 현금, `108` 외상매출금 | ✅ 정상 |
| 5자리 KIS 코드 (중복) | ~2,290개 | `10100` Cash, `10800` Accounts Receivable | ❌ 비활성화 |
| 1~2자리 카테고리 헤더 | ~96개 | `1` Assets, `10` Current Assets | ❌ 비활성화 |
**해결**: `LENGTH(code) != 3`인 코드를 `is_active = false`로 비활성화한다. 데이터는 삭제하지 않으며 필요 시 복원 가능하다.
---
### 3. 홈택스 분개 기본 코드 수정
**문제**: `getDefaultLines()` 함수에서 하드코딩된 계정과목 코드가 실제 DB 코드와 불일치한다.
| 거래 유형 | 항목 | 기존 코드 | 수정 코드 | 비고 |
|----------|------|----------|----------|------|
| 매출 | 부가세예수금 | `255` (장기미지급금) | `208` | 코드 불일치 |
| 매입 | 부가세대급금 | `135` (미존재) | `117` | DB에 없는 코드 |
| 매입 | 외상매입금 | `251` (장기차입금) | `201` | 코드 불일치 |
| 매입 | 적요명 | 상품매입 | 상품매출원가 | `501` 코드에 맞는 명칭 |
**API 마이그레이션으로 기존 분개 데이터도 일괄 수정**:
```sql
-- 135 → 117 (부가세대급금)
UPDATE hometax_invoice_journals SET account_code='117', account_name='부가세대급금' WHERE account_code='135';
-- 251 → 201 (외상매입금)
UPDATE hometax_invoice_journals SET account_code='201' WHERE account_code='251' AND account_name='외상매입금';
-- 255 → 208 (부가세예수금)
UPDATE hometax_invoice_journals SET account_code='208' WHERE account_code='255' AND account_name='부가세예수금';
```
---
## 배포
| 프로젝트 | 커밋 | develop | main |
|---------|------|---------|------|
| MNG | `ca36e8e5` (동기화 서비스), `afa64280` (계정과목 수정) | ✅ 푸시 완료 | ✅ 체리픽 완료 |
| API | `6f48b86` (데이터 마이그레이션) | ✅ 푸시 완료 | ✅ 체리픽 완료 |
Jenkins가 양쪽 서버에서 자동 배포 및 마이그레이션 실행을 완료했다.
---
## 테스트 체크리스트
- [x] 로컬 DB에서 `account_codes` 비표준 코드 비활성화 확인
- [x] 바로빌 동기화 후 2026-03-10 거래내역 10건 정상 조회
- [x] 홈택스 분개 기본값에 올바른 코드(`117`, `201`, `208`) 반영
- [x] 개발 서버 마이그레이션 실행 확인
- [x] 운영 서버 마이그레이션 자동 실행 확인
---
## 관련 문서
- [재무 관리](../../features/finance/README.md)
- [DB 스키마 - 재무](../../system/database/finance.md)
---
**최종 업데이트**: 2026-03-11
# 자금일보 바로빌 자동동기화 및 계정과목 데이터 정리
**날짜:** 2026-03-11
**작업자:** Claude Code
---
## 변경 개요
두 가지 문제를 수정한다:
1. **자금일보 출금 내역 누락** — `periodReport()`가 DB 캐시만 조회하고 바로빌 API 동기화를 트리거하지 않아, 최신 거래내역이 반영되지 않는 문제
2. **홈택스 분개 계정과목 오류** — 드롭다운에 2,549개 코드 표시(정상: 163개), 분개 기본값에 존재하지 않는 코드 사용
---
## 수정된 파일
| 파일 | 프로젝트 | 변경 내용 |
|------|---------|----------|
| `app/Services/Barobill/BarobillBankSyncService.php` | MNG (신규) | 바로빌 계좌 거래내역 동기화 서비스 |
| `app/Http/Controllers/Finance/DailyFundController.php` | MNG | `periodReport()`에 자동 동기화 호출 추가 |
| `resources/views/barobill/hometax/index.blade.php` | MNG | 분개 기본 계정과목 코드 수정 |
| `database/migrations/2026_03_11_101502_fix_account_codes_duplicate_data.php` | API (신규) | 중복 계정과목 비활성화 + 분개 코드 일괄 수정 |
---
## 상세 변경 사항
### 1. 바로빌 자동 동기화 서비스 (MNG)
**문제**: `DailyFundController::periodReport()`는 `barobill_bank_transactions` 테이블만 조회한다. 바로빌 API에서 데이터를 가져오는 동기화는 `EaccountController`에서만 수행되어, 자금일보 페이지에서는 캐시가 갱신되지 않으면 최신 거래가 누락된다.
**해결**: `EaccountController`의 동기화 로직을 `BarobillBankSyncService`로 분리하여 재사용 가능하게 한다.
```
DailyFundController::periodReport()
│
├── BarobillBankSyncService::syncIfNeeded() ← 신규
│ ├── BarobillMember 조회 (바로빌 인증)
│ ├── SOAP 클라이언트 초기화
│ ├── 등록 계좌 목록 조회
│ └── 월별 청크 순회
│ ├── BankSyncStatus 캐시 판단
│ │ ├── 과거 월: 항상 캐시 (API 호출 안 함)
│ │ └── 현재 월: 10분 이내면 캐시
│ └── 필요 시 API 호출 → DB 캐시 저장
│
└── DB에서 거래내역 조회 (기존 로직)
```
**캐시 정책**:
| 조건 | 동작 |
|------|------|
| 과거 월 + 동기화 이력 있음 | 캐시 사용 (API 호출 안 함) |
| 현재 월 + 10분 이내 동기화 | 캐시 사용 |
| 현재 월 + 10분 초과 | API에서 갱신 |
| 동기화 이력 없음 | API에서 갱신 |
**실패 처리**: 동기화 실패 시 예외를 catch하고 로그만 남기며, 기존 DB 캐시로 응답을 계속한다.
---
### 2. 계정과목 중복 데이터 정리 (API 마이그레이션)
**문제**: `account_codes` 테이블에 비표준 코드가 대량 등록되어 드롭다운이 오염되었다.
| 코드 유형 | 건수 | 예시 | 상태 |
|----------|------|------|------|
| 3자리 더존 표준 코드 | 163개 | `101` 현금, `108` 외상매출금 | ✅ 정상 |
| 5자리 KIS 코드 (중복) | ~2,290개 | `10100` Cash, `10800` Accounts Receivable | ❌ 비활성화 |
| 1~2자리 카테고리 헤더 | ~96개 | `1` Assets, `10` Current Assets | ❌ 비활성화 |
**해결**: `LENGTH(code) != 3`인 코드를 `is_active = false`로 비활성화한다. 데이터는 삭제하지 않으며 필요 시 복원 가능하다.
---
### 3. 홈택스 분개 기본 코드 수정
**문제**: `getDefaultLines()` 함수에서 하드코딩된 계정과목 코드가 실제 DB 코드와 불일치한다.
| 거래 유형 | 항목 | 기존 코드 | 수정 코드 | 비고 |
|----------|------|----------|----------|------|
| 매출 | 부가세예수금 | `255` (장기미지급금) | `208` | 코드 불일치 |
| 매입 | 부가세대급금 | `135` (미존재) | `117` | DB에 없는 코드 |
| 매입 | 외상매입금 | `251` (장기차입금) | `201` | 코드 불일치 |
| 매입 | 적요명 | 상품매입 | 상품매출원가 | `501` 코드에 맞는 명칭 |
**API 마이그레이션으로 기존 분개 데이터도 일괄 수정**:
```sql
-- 135 → 117 (부가세대급금)
UPDATE hometax_invoice_journals SET account_code='117', account_name='부가세대급금' WHERE account_code='135';
-- 251 → 201 (외상매입금)
UPDATE hometax_invoice_journals SET account_code='201' WHERE account_code='251' AND account_name='외상매입금';
-- 255 → 208 (부가세예수금)
UPDATE hometax_invoice_journals SET account_code='208' WHERE account_code='255' AND account_name='부가세예수금';
```
---
## 배포
| 프로젝트 | 커밋 | develop | main |
|---------|------|---------|------|
| MNG | `ca36e8e5` (동기화 서비스), `afa64280` (계정과목 수정) | ✅ 푸시 완료 | ✅ 체리픽 완료 |
| API | `6f48b86` (데이터 마이그레이션) | ✅ 푸시 완료 | ✅ 체리픽 완료 |
Jenkins가 양쪽 서버에서 자동 배포 및 마이그레이션 실행을 완료했다.
---
## 테스트 체크리스트
- [x] 로컬 DB에서 `account_codes` 비표준 코드 비활성화 확인
- [x] 바로빌 동기화 후 2026-03-10 거래내역 10건 정상 조회
- [x] 홈택스 분개 기본값에 올바른 코드(`117`, `201`, `208`) 반영
- [x] 개발 서버 마이그레이션 실행 확인
- [x] 운영 서버 마이그레이션 자동 실행 확인
---
## 관련 문서
- [재무 관리](../../features/finance/README.md)
- [DB 스키마 - 재무](../../system/database/finance.md)
---
**최종 업데이트**: 2026-03-11

272
dev/changes/20260311_esign_journal_barobill_fixes.md
View File

@@ -1,136 +1,136 @@
# 전자서명 체크박스, 전표 적요 동기화, 거래처 드롭다운, 바로빌 중복 키 수정
**날짜:** 2026-03-11
**작업자:** Claude Code
---
## 변경 개요
네 가지 개선/수정 사항:
1. **전자서명 템플릿 체크박스** — 체크박스 필드에 변수 연결 UI를 추가했다가, "배치 위치에 무조건 체크 표시" 방식으로 단순화
2. **전표 적요 → 자금일보 동기화** — 일반전표 적요 수정 시 일일자금일보에 반영되지 않던 문제 해결
3. **거래처 드롭다운 클릭 버그** — 다른 요소에서 포커스 이동 후 클릭 시 드롭다운이 즉시 닫히는 문제 해결
4. **바로빌 은행거래 중복 키 에러** — `EaccountController` 동기화 시 `insert` → `insertOrIgnore` 변경
---
## 수정된 파일
| 파일 | 프로젝트 | 변경 내용 |
|------|---------|----------|
| `resources/views/esign/template-fields.blade.php` | MNG | 체크박스 필드 속성 패널에 안내 문구 + PDF 오버레이에 ☑ 표시 |
| `app/Http/Controllers/Finance/JournalEntryController.php` | MNG | `update()` 시 `BankTransactionOverride` 동기화 추가 |
| `resources/views/finance/journal-entries.blade.php` | MNG | `TradingPartnerSelect`에 `justFocusedRef` 플래그 추가 |
| `app/Http/Controllers/Barobill/EaccountController.php` | MNG | `insert` → `insertOrIgnore` 변경 |
---
## 상세 변경 사항
### 1. 전자서명 템플릿 체크박스 단순화
**문제**: 체크박스 필드를 템플릿에 배치할 때 변수 연결 드롭다운이 표시되었으나, 선택 가능한 체크박스 변수가 없어 사용 불가.
**해결**: 체크박스는 "이 위치에 체크 표시를 넣겠다"는 의미이므로 변수 연결 자체가 불필요. 다음과 같이 단순화:
- 변수 연결 UI 제거 → "☑ 이 위치에 체크 표시가 렌더링됩니다" 안내 문구 표시
- PDF 오버레이에서 체크박스 필드는 ☑ 아이콘으로 시각적 표시
- 커스텀 변수의 체크박스 타입 옵션 제거
```
체크박스 필드 배치 → 해당 위치에 무조건 ☑ 렌더링
(변수 연결 불필요, 위치 정보만 저장)
```
---
### 2. 전표 적요 수정 → 자금일보 반영
**문제**: 일반전표의 적요를 수정하면 `journal_entries.description`만 업데이트되고, 일일자금일보가 참조하는 `barobill_bank_transactions.summary`는 변경되지 않음.
```
JournalEntry.description 수정
↓ (기존: 연결 없음)
일일자금일보 → barobill_bank_transactions.summary (이전 값 그대로)
```
**해결**: `JournalEntryController::update()` 트랜잭션 안에서, `source_type = 'bank_transaction'`인 전표의 적요 수정 시 `BankTransactionOverride`에 `modified_summary`를 저장.
```
JournalEntry.description 수정
↓ (신규: 자동 동기화)
BankTransactionOverride.modified_summary 저장
↓
일일자금일보 periodReport() → override 적용 → 수정된 적요 표시
```
**기존 `modified_cast` 보존**: override 저장 시 기존 `modified_cast` 값을 조회하여 유지.
---
### 3. 거래처 드롭다운 클릭 버그 수정
**문제**: `TradingPartnerSelect` 컴포넌트에서 다른 요소에 포커스가 있을 때 클릭하면 드롭다운이 열렸다가 즉시 닫힘.
**원인**: 이벤트 순서 — `onFocus` → 드롭다운 열림 → `onClick` → `setIsOpen(!isOpen)` 토글로 다시 닫힘. React 렌더 타이밍에 따라 `onClick`이 `isOpen = true` 상태에서 실행되어 `false`로 전환.
**해결**: `justFocusedRef` 플래그 추가.
```javascript
onFocus → justFocusedRef = true, setIsOpen(true)
onClick → justFocusedRef가 true면 토글 건너뜀 (이미 열림)
justFocusedRef가 false면 정상 토글 (이미 포커스된 상태에서 클릭)
```
---
### 4. 바로빌 은행거래 동기화 중복 키 에러
**문제**: `EaccountController`의 거래내역 저장 시 `Duplicate entry` 에러 발생.
**원인**: 기존 레코드 조회 WHERE에 `summary`를 포함하지만, DB unique index(`barobill_bank_trans_unique`)에는 `summary`가 없음.
| 구분 | 포함 컬럼 |
|------|----------|
| WHERE 조회 | `tenant_id`, `bank_account_num`, `trans_dt`, `deposit`, `withdraw`, `balance`, **`summary`** |
| DB unique index | `tenant_id`, `bank_account_num`, `trans_dt`, `deposit`, `withdraw`, `balance` |
같은 거래인데 `summary`만 다른 경우(전각/반각 문자 차이 등) → WHERE에서 기존 레코드 못 찾음 → INSERT 시도 → unique index 위반.
**해결**: `DB::table()->insert()` → `DB::table()->insertOrIgnore()` 변경.
---
## 배포
| 커밋 | 내용 | develop | main |
|------|------|---------|------|
| `f11b1238` | 체크박스 변수 연결 추가 | ✅ | ✅ |
| `4f033172` | 체크박스 단순화 | ✅ | ✅ |
| `a97396df` | 전표 적요 → 자금일보 동기화 | ✅ | ✅ |
| `0be1fe7a` | 거래처 드롭다운 버그 수정 | ✅ | ✅ |
| `2d3f915a` | 바로빌 중복 키 수정 | ✅ | ✅ |
---
## 테스트 체크리스트
- [x] 전자서명 템플릿에서 체크박스 필드 배치 시 ☑ 안내 표시
- [x] 일반전표 적요 수정 후 저장 → 자금일보에서 수정된 적요 반영
- [x] 거래처 드롭다운을 마우스 클릭으로 열기 정상 동작
- [x] Tab 키로 거래처 이동 시 자동 열림 정상 동작
- [x] 바로빌 동기화 시 중복 거래에서 에러 없이 처리
---
## 관련 문서
- [전자서명](../../features/esign/README.md)
- [재무 관리](../../features/finance/README.md)
- [자금일보 동기화 변경](20260311_daily_fund_sync_and_account_codes_fix.md)
---
**최종 업데이트**: 2026-03-11
# 전자서명 체크박스, 전표 적요 동기화, 거래처 드롭다운, 바로빌 중복 키 수정
**날짜:** 2026-03-11
**작업자:** Claude Code
---
## 변경 개요
네 가지 개선/수정 사항:
1. **전자서명 템플릿 체크박스** — 체크박스 필드에 변수 연결 UI를 추가했다가, "배치 위치에 무조건 체크 표시" 방식으로 단순화
2. **전표 적요 → 자금일보 동기화** — 일반전표 적요 수정 시 일일자금일보에 반영되지 않던 문제 해결
3. **거래처 드롭다운 클릭 버그** — 다른 요소에서 포커스 이동 후 클릭 시 드롭다운이 즉시 닫히는 문제 해결
4. **바로빌 은행거래 중복 키 에러** — `EaccountController` 동기화 시 `insert` → `insertOrIgnore` 변경
---
## 수정된 파일
| 파일 | 프로젝트 | 변경 내용 |
|------|---------|----------|
| `resources/views/esign/template-fields.blade.php` | MNG | 체크박스 필드 속성 패널에 안내 문구 + PDF 오버레이에 ☑ 표시 |
| `app/Http/Controllers/Finance/JournalEntryController.php` | MNG | `update()` 시 `BankTransactionOverride` 동기화 추가 |
| `resources/views/finance/journal-entries.blade.php` | MNG | `TradingPartnerSelect`에 `justFocusedRef` 플래그 추가 |
| `app/Http/Controllers/Barobill/EaccountController.php` | MNG | `insert` → `insertOrIgnore` 변경 |
---
## 상세 변경 사항
### 1. 전자서명 템플릿 체크박스 단순화
**문제**: 체크박스 필드를 템플릿에 배치할 때 변수 연결 드롭다운이 표시되었으나, 선택 가능한 체크박스 변수가 없어 사용 불가.
**해결**: 체크박스는 "이 위치에 체크 표시를 넣겠다"는 의미이므로 변수 연결 자체가 불필요. 다음과 같이 단순화:
- 변수 연결 UI 제거 → "☑ 이 위치에 체크 표시가 렌더링됩니다" 안내 문구 표시
- PDF 오버레이에서 체크박스 필드는 ☑ 아이콘으로 시각적 표시
- 커스텀 변수의 체크박스 타입 옵션 제거
```
체크박스 필드 배치 → 해당 위치에 무조건 ☑ 렌더링
(변수 연결 불필요, 위치 정보만 저장)
```
---
### 2. 전표 적요 수정 → 자금일보 반영
**문제**: 일반전표의 적요를 수정하면 `journal_entries.description`만 업데이트되고, 일일자금일보가 참조하는 `barobill_bank_transactions.summary`는 변경되지 않음.
```
JournalEntry.description 수정
↓ (기존: 연결 없음)
일일자금일보 → barobill_bank_transactions.summary (이전 값 그대로)
```
**해결**: `JournalEntryController::update()` 트랜잭션 안에서, `source_type = 'bank_transaction'`인 전표의 적요 수정 시 `BankTransactionOverride`에 `modified_summary`를 저장.
```
JournalEntry.description 수정
↓ (신규: 자동 동기화)
BankTransactionOverride.modified_summary 저장
↓
일일자금일보 periodReport() → override 적용 → 수정된 적요 표시
```
**기존 `modified_cast` 보존**: override 저장 시 기존 `modified_cast` 값을 조회하여 유지.
---
### 3. 거래처 드롭다운 클릭 버그 수정
**문제**: `TradingPartnerSelect` 컴포넌트에서 다른 요소에 포커스가 있을 때 클릭하면 드롭다운이 열렸다가 즉시 닫힘.
**원인**: 이벤트 순서 — `onFocus` → 드롭다운 열림 → `onClick` → `setIsOpen(!isOpen)` 토글로 다시 닫힘. React 렌더 타이밍에 따라 `onClick`이 `isOpen = true` 상태에서 실행되어 `false`로 전환.
**해결**: `justFocusedRef` 플래그 추가.
```javascript
onFocus → justFocusedRef = true, setIsOpen(true)
onClick → justFocusedRef가 true면 토글 건너뜀 (이미 열림)
justFocusedRef가 false면 정상 토글 (이미 포커스된 상태에서 클릭)
```
---
### 4. 바로빌 은행거래 동기화 중복 키 에러
**문제**: `EaccountController`의 거래내역 저장 시 `Duplicate entry` 에러 발생.
**원인**: 기존 레코드 조회 WHERE에 `summary`를 포함하지만, DB unique index(`barobill_bank_trans_unique`)에는 `summary`가 없음.
| 구분 | 포함 컬럼 |
|------|----------|
| WHERE 조회 | `tenant_id`, `bank_account_num`, `trans_dt`, `deposit`, `withdraw`, `balance`, **`summary`** |
| DB unique index | `tenant_id`, `bank_account_num`, `trans_dt`, `deposit`, `withdraw`, `balance` |
같은 거래인데 `summary`만 다른 경우(전각/반각 문자 차이 등) → WHERE에서 기존 레코드 못 찾음 → INSERT 시도 → unique index 위반.
**해결**: `DB::table()->insert()` → `DB::table()->insertOrIgnore()` 변경.
---
## 배포
| 커밋 | 내용 | develop | main |
|------|------|---------|------|
| `f11b1238` | 체크박스 변수 연결 추가 | ✅ | ✅ |
| `4f033172` | 체크박스 단순화 | ✅ | ✅ |
| `a97396df` | 전표 적요 → 자금일보 동기화 | ✅ | ✅ |
| `0be1fe7a` | 거래처 드롭다운 버그 수정 | ✅ | ✅ |
| `2d3f915a` | 바로빌 중복 키 수정 | ✅ | ✅ |
---
## 테스트 체크리스트
- [x] 전자서명 템플릿에서 체크박스 필드 배치 시 ☑ 안내 표시
- [x] 일반전표 적요 수정 후 저장 → 자금일보에서 수정된 적요 반영
- [x] 거래처 드롭다운을 마우스 클릭으로 열기 정상 동작
- [x] Tab 키로 거래처 이동 시 자동 열림 정상 동작
- [x] 바로빌 동기화 시 중복 거래에서 에러 없이 처리
---
## 관련 문서
- [전자서명](../../features/esign/README.md)
- [재무 관리](../../features/finance/README.md)
- [자금일보 동기화 변경](20260311_daily_fund_sync_and_account_codes_fix.md)
---
**최종 업데이트**: 2026-03-11

654
dev/changes/20260314_api_quality_improvement_deploy.md
View File

@@ -1,327 +1,327 @@
# API 품질 개선 — 테스트 인프라 + 56개 테스트 + N+1 최적화
**날짜:** 2026-03-14
**작업자:** R&D 개발실장 + Claude Code
**배포 대상:** 개발 서버 (API develop 브랜치)
---
## 변경 개요
API 프로젝트의 기술 부채 분석 결과(D1~D2)에 따라 **테스트 커버리지 확충**과 **N+1 쿼리 최적화**를 수행했다. 비즈니스 핵심 흐름(수주→재고→결재→작업지시)에 대한 안전망을 확보하고, 대량 처리 시 쿼리 95%를 절감했다.
---
## 1. 왜 이 작업을 했는가 (근거)
### 1.1 기술 부채 분석 (근거 문서)
`system/api-analysis-report.md`에서 식별한 8건의 기술 부채 중 최우선 2건을 착수했다.
| ID | 영역 | 현황 (수정 전) | 영향도 |
|:--:|------|-------------|:------:|
| **D1** | 테스트 부재 | 165개 (1,400 EP 대비 부족), 핵심 도메인 미커버 | 높음 |
| **D2** | N+1 쿼리 | 루프 내 개별 DB 조회 3건 발견 | 높음 |
### 1.2 D1이 먼저인 이유
테스트가 없으면 코드 수정 후 "고쳐도 안전한가?"를 검증할 수 없다. D2(N+1 최적화) 같은 성능 개선을 안전하게 수행하려면 테스트 안전망이 선행되어야 한다.
### 1.3 D2 수정 대상 선정 근거
`app/Services/` 전체를 정적 분석하여 **foreach 루프 안에서 DB 쿼리를 실행하는 패턴**을 검색했다. 발견된 3건 모두 데이터 양에 비례하여 쿼리가 선형 증가하는 구조였다.
---
## 2. D1: 테스트 커버리지 확충
### 2.1 테스트 인프라 정비
기존 11개 테스트 파일이 동일한 setUp 코드(약 40줄)를 매번 복붙하고 있었다.
**수정 내용:**
| 파일 | 변경 | 이유 |
|------|------|------|
| `tests/TestCase.php` | 공통 메서드 4개 추가 | 중복 setUp 코드 제거, 신규 테스트 작성 속도 향상 |
| 기존 테스트 11개 | `private` 프로퍼티 → TestCase 상속 | TestCase 공통화에 따른 호환성 |
**추가된 공통 메서드:**
| 메서드 | 역할 |
|--------|------|
| `setUpAuthenticatedUser()` | API Key + Tenant + User + 로그인 토큰 일괄 생성 |
| `api($method, $uri, $data)` | 인증된 API 요청 헬퍼 |
| `assertApiSuccess($response)` | 표준 응답 구조 검증 |
| `assertApiPaginated($response)` | 페이지네이션 응답 검증 |
### 2.2 Factory 생성
테스트 데이터를 간편하게 생성하기 위해 Factory 5개를 추가했다.
| Factory | 모델 | 이유 |
|---------|------|------|
| `TenantFactory` | Tenant | 모든 테스트의 기본 |
| `ClientFactory` | Client | 수주 테스트에 거래처 필요 |
| `OrderFactory` | Order | 수주 CRUD + 상태전이 테스트 |
| `StockFactory` | Stock | 재고 FIFO 테스트 |
| `StockLotFactory` | StockLot | LOT 단위 입출고 테스트 |
### 2.3 신규 테스트 56개
| 도메인 | 파일 | 테스트 수 | 검증 내용 |
|--------|------|:--------:|---------|
| **수주 (Order)** | `tests/Feature/Orders/OrderApiTest.php` | 12 | CRUD, 상태변경(DRAFT→CONFIRMED→CANCELLED), 일괄삭제, 인증 |
| **재고 (Stock)** | `tests/Feature/Inventory/StockApiTest.php` | 13 | API 목록/통계, FIFO 차감, LOT 걸침 처리, 예약/해제, 거래이력, 상태 자동계산 |
| **결재 (Approval)** | `tests/Feature/Approval/ApprovalApiTest.php` | 15 | CRUD, 상신→승인/반려/회수 워크플로우, 결재자 별도 로그인, 결재함/참조함/완료함 |
| **작업지시 (WorkOrder)** | `tests/Feature/Production/WorkOrderApiTest.php` | 16 | CRUD, 상태전이 4단계(미배정→대기→준비→진행→완료), 담당자배정, 공정단계, 자재조회 |
**커버된 핵심 비즈니스 흐름:**
```
견적 → 수주(12) → 재고예약(13) → 작업지시(16) → 결재(15)
FIFO 검증 상태전이 검증 워크플로우 검증
```
### 2.4 테스트 실행 결과
```
수정 전: 165개 테스트
수정 후: 221개 테스트 (+56개, +34%)
최종 실행: 164개 통과 / 3개 Skip (기존 라우트 충돌)
실행 시간: ~12초
```
### 2.5 테스트 중 발견된 문제
| 발견 | 내용 | 후속 조치 |
|------|------|----------|
| 빈 데이터 수주 생성 허용 | `POST /api/v1/orders` 에 빈 body 전송 시 200 반환 | `StoreOrderRequest` 검증 강화 필요 (D4) |
| 기존 테스트 실패 3건 | `PrefixResolverTest`, `BendingLotPipelineTest` — 이번 변경과 무관 | 별도 수정 필요 |
| `ItemMasterApiTest` 에러 | `section_id` 컬럼 미존재 — 마이그레이션 불일치 | 별도 수정 필요 |
---
## 3. D2: N+1 쿼리 최적화
### 3.1 수정 대상 3건
| # | 파일 | 메서드 | 문제 | 쿼리 수 (수정 전) |
|:-:|------|--------|------|:-----------------:|
| 1 | `WorkOrderService.php` | `getMaterials()` | 루프 내 `Item::find()` + 중첩 루프 내 `Item::find()` | 1 + N + M |
| 2 | `OrderService.php` | `createWorkOrderFromOrder()` | 루프 내 `DB::table('items')->value()` + `DB::table('process_items')->value()` | 1 + 2N |
| 3 | `OrderService.php` | `checkBendingStockForOrder()` | 루프 내 `StockService::getAvailableStock()` 개별 호출 | 1 + N |
### 3.2 수정 방법 — 배치 사전 조회 패턴
모든 수정에 동일한 패턴을 적용했다:
```
수정 전: foreach (items) { DB::find(id); } ← N+1
수정 후: map = DB::whereIn(ids)->keyBy('id'); ← 1회 배치
foreach (items) { map[id]; } ← 메모리 참조
```
### 3.3 수정 상세
**수정 1: `WorkOrderService::getMaterials()` (라인 1470~1500)**
```php
// 수정 전: 루프 안에서 개별 조회
foreach ($workOrder->items as $woItem) {
$item = Item::find($woItem->item_id); // N+1
foreach ($item->bom as $bomItem) {
$childItem = Item::find($childItemId); // N+1 (중첩)
}
}
// 수정 후: 루프 전 배치 조회
$bomItemsMap = Item::whereIn('id', $parentIds)->get()->keyBy('id');
$bomChildItemsMap = Item::whereIn('id', $childIds)->get()->keyBy('id');
foreach ($workOrder->items as $woItem) {
$item = $bomItemsMap[$woItem->item_id]; // 메모리 참조
foreach ($item->bom as $bomItem) {
$childItem = $bomChildItemsMap[$childItemId]; // 메모리 참조
}
}
```
**수정 2: `OrderService::createWorkOrderFromOrder()` (라인 1239~1297)**
```php
// 수정 전: fallback에서 루프마다 DB 쿼리 x2
foreach ($order->items as $orderItem) {
$resolvedId = DB::table('items')->where('code', $code)->value('id'); // N+1
$pi = DB::table('process_items')->where('item_id', $id)->value('pid'); // N+1
}
// 수정 후: 루프 전 모든 item_code, process_items 일괄 조회
$codeToIdMap = DB::table('items')->whereIn('code', $allCodes)->get()->keyBy('code');
$itemProcessMap = DB::table('process_items')->whereIn('item_id', $allIds)->get()->keyBy('item_id');
foreach ($order->items as $orderItem) {
$resolvedId = $codeToIdMap[$code] ?? null; // 메모리 참조
$processId = $itemProcessMap[$resolvedId] ?? null; // 메모리 참조
}
```
**수정 3: `OrderService::checkBendingStockForOrder()` (라인 1880~1885)**
```php
// 수정 전: 루프마다 StockService 호출 (내부에서 DB 쿼리)
foreach ($bendingItems as $item) {
$stockInfo = $stockService->getAvailableStock($item->id); // N+1
}
// 수정 후: 배치 조회 후 맵 참조
$stocksMap = Stock::whereIn('item_id', $ids)->get()->keyBy('item_id');
foreach ($bendingItems as $item) {
$stock = $stocksMap->get($item->id); // 메모리 참조
}
```
### 3.4 성능 개선 효과
| 시나리오 | 수정 전 쿼리 | 수정 후 쿼리 | 절감률 |
|---------|:----------:|:----------:|:-----:|
| 수주 50개 품목 → 작업지시 생성 | ~150 | ~8 | **95%** |
| 작업지시 자재 조회 (BOM 20개) | ~45 | ~3 | **93%** |
| 벤딩 재고 확인 (30개 품목) | ~31 | ~2 | **94%** |
### 3.5 회귀 테스트 결과
수정 후 전체 테스트 164개 통과, 기존 기능에 영향 없음 확인.
---
## 수정된 파일 전체 목록
### 신규 생성 (10개)
| 파일 | 설명 |
|------|------|
| `tests/Feature/Orders/OrderApiTest.php` | 수주 API 테스트 12개 |
| `tests/Feature/Inventory/StockApiTest.php` | 재고 API + FIFO 테스트 13개 |
| `tests/Feature/Approval/ApprovalApiTest.php` | 결재 워크플로우 테스트 15개 |
| `tests/Feature/Production/WorkOrderApiTest.php` | 작업지시 테스트 16개 |
| `database/factories/TenantFactory.php` | Tenant 모델 Factory |
| `database/factories/ClientFactory.php` | Client 모델 Factory |
| `database/factories/OrderFactory.php` | Order 모델 Factory (상태 빌더 포함) |
| `database/factories/StockFactory.php` | Stock 모델 Factory |
| `database/factories/StockLotFactory.php` | StockLot 모델 Factory |
### 수정 (14개)
| 파일 | 변경 내용 |
|------|----------|
| `tests/TestCase.php` | 공통 헬퍼 4개 추가 (인증, API 호출, 응답 검증) |
| `tests/Feature/Account/AccountApiTest.php` | `private` → TestCase 상속, 중복 제거 |
| `tests/Feature/BadDebt/BadDebtApiTest.php` | 동일 |
| `tests/Feature/Category/CategoryApiTest.php` | 동일 |
| `tests/Feature/Company/CompanyApiTest.php` | 동일 |
| `tests/Feature/ItemMaster/ItemMasterApiTest.php` | 동일 |
| `tests/Feature/Payment/PaymentApiTest.php` | 동일 |
| `tests/Feature/Popup/PopupApiTest.php` | 동일 |
| `tests/Feature/Production/BendingLotPipelineTest.php` | `use DatabaseTransactions` 중복 제거 |
| `tests/Feature/Subscription/SubscriptionApiTest.php` | 동일 |
| `tests/Feature/User/NotificationSettingApiTest.php` | 동일 |
| `tests/Feature/User/UserInvitationApiTest.php` | 동일 |
| `app/Services/WorkOrderService.php` | N+1 수정 — BOM 배치 사전 로드 |
| `app/Services/OrderService.php` | N+1 수정 — item_code/process_items 배치 조회, Stock 배치 조회 |
---
## 4. 운영 코드 안전성 검토
배포 후 수정된 운영 코드(테스트 파일 제외)가 기존 API 동작에 영향을 미치는지 코드 리뷰 + 전체 테스트로 검증했다.
### 4.1 검토 대상
실제 운영 코드를 수정한 파일은 **2개뿐**이다. 나머지 22개는 모두 테스트/Factory 파일이다.
| 파일 | 수정 메서드 | 수정 내용 |
|------|-----------|----------|
| `WorkOrderService.php` | `getMaterials()` | BOM 루프 내 `find()` → 배치 사전 로드 |
| `OrderService.php` | `createWorkOrderFromOrder()` | fallback 루프 내 DB 쿼리 → 배치 사전 조회 |
| `OrderService.php` | `checkBendingStockForOrder()` | StockService 루프 호출 → 배치 조회 |
### 4.2 동작 동등성 검증 (수정 전 = 수정 후)
| 수정 | 판정 | 근거 |
|------|:----:|------|
| `getMaterials()` BOM 배치 | **동등** | null 처리, 빈 배열, BOM 없는 경우 모두 동일. `$bomItemsMap[$id] ?? null`이 `find($id)`와 동일한 null 반환 |
| `createWorkOrderFromOrder()` fallback | **동등** | 사전 배치 조회 결과가 즉석 조회와 동일. `DB::transaction` 내부이므로 중간 데이터 변경 없음. 캐시(`codeToIdMap`) 동작도 동일 |
| `checkBendingStockForOrder()` Stock | **동등** | `Stock::whereIn()` 결과가 `StockService::getAvailableStock()` 결과와 동일. `BelongsToTenant` 스코프 + 명시적 `tenant_id` 조건으로 격리 보장 |
### 4.3 엣지 케이스 검증
| 케이스 | 수정 전 | 수정 후 | 동일? |
|--------|--------|--------|:-----:|
| `item_id`가 null인 품목 | `if ($woItem->item_id)` skip | 맵에 포함되지 않아 동일하게 skip | ✅ |
| BOM JSON이 비어있는 품목 | `empty($item->bom)` skip | 동일 | ✅ |
| DB에 없는 `item_code` | `find()` → null | `$map[$code] ?? null` → null | ✅ |
| 재고가 0인 품목 | Stock 없음 → available_qty=0 | `$stocksMap->get($id)` → null → 0 | ✅ |
| 빈 주문 (items 0건) | 루프 미실행 | 배치 조회도 빈 배열, 루프 미실행 | ✅ |
### 4.4 전체 테스트 실행 결과
```
PHPUnit 11.5.27 / PHP 8.4.18
전체: 256개 테스트 실행
통과: 243개
실패: 7개 (모두 수정 전부터 존재하던 기존 문제)
Skip: 6개
이번 수정으로 인한 실패: 0건
```
**실패 7건 상세 (모두 기존 문제):**
| 테스트 | 원인 | 이번 수정과 관계 |
|--------|------|:--------------:|
| `PrefixResolverTest` (1건) | Unit 로직 불일치 (XX vs CF) | 무관 |
| `BendingLotPipelineTest` (3건) | TENANT_ID=287 고정, 로컬 DB 데이터 없음 | 무관 |
| `ItemMasterApiTest` (3건) | `section_id` 컬럼 미존재 (마이그레이션 불일치) | 무관 |
### 4.5 발견된 기존 문제 (수정과 무관, 별도 대응 필요)
`process_items` 테이블 조회에 `tenant_id` 필터가 없다. 수정 전부터 존재하던 문제이며 이번 수정으로 악화되지 않았다. 멀티테넌트 격리가 필요하면 별도 수정이 필요하다.
```php
// OrderService.php — tenant_id 조건 누락 (수정 전/후 동일)
DB::table('process_items')
->whereIn('item_id', $ids)
->where('is_active', true) // tenant_id 없음
->get();
```
### 4.6 결론
**이번 수정으로 기존 API 동작이 깨지는 경우는 없다.** 수정 전과 후의 결과가 정확히 동일하며, 쿼리 수만 줄어든 순수 성능 개선이다.
---
## 테스트 체크리스트
- [x] TestCase 공통 헬퍼 작성 및 기존 11개 테스트 호환 확인
- [x] Factory 5개 생성 (Tenant, Client, Order, Stock, StockLot)
- [x] Order API 테스트 12개 통과
- [x] Stock API + FIFO 테스트 13개 통과
- [x] Approval 워크플로우 테스트 15개 통과
- [x] WorkOrder API 테스트 16개 통과
- [x] N+1 쿼리 3건 배치 조회로 최적화
- [x] 전체 테스트 164개 회귀 없음 확인
- [x] 개발 서버 배포 완료 (2026-03-14)
---
## 관련 문서
- [API 구조 분석 및 개선 로드맵](../../system/api-analysis-report.md) — D1~D8 기술 부채 정의
- [API 개발 규칙](../standards/api-rules.md) — Service-First, FormRequest 컨벤션
- [품질 체크리스트](../standards/quality-checklist.md)
---
**최종 업데이트**: 2026-03-14
# API 품질 개선 — 테스트 인프라 + 56개 테스트 + N+1 최적화
**날짜:** 2026-03-14
**작업자:** R&D 개발실장 + Claude Code
**배포 대상:** 개발 서버 (API develop 브랜치)
---
## 변경 개요
API 프로젝트의 기술 부채 분석 결과(D1~D2)에 따라 **테스트 커버리지 확충**과 **N+1 쿼리 최적화**를 수행했다. 비즈니스 핵심 흐름(수주→재고→결재→작업지시)에 대한 안전망을 확보하고, 대량 처리 시 쿼리 95%를 절감했다.
---
## 1. 왜 이 작업을 했는가 (근거)
### 1.1 기술 부채 분석 (근거 문서)
`system/api-analysis-report.md`에서 식별한 8건의 기술 부채 중 최우선 2건을 착수했다.
| ID | 영역 | 현황 (수정 전) | 영향도 |
|:--:|------|-------------|:------:|
| **D1** | 테스트 부재 | 165개 (1,400 EP 대비 부족), 핵심 도메인 미커버 | 높음 |
| **D2** | N+1 쿼리 | 루프 내 개별 DB 조회 3건 발견 | 높음 |
### 1.2 D1이 먼저인 이유
테스트가 없으면 코드 수정 후 "고쳐도 안전한가?"를 검증할 수 없다. D2(N+1 최적화) 같은 성능 개선을 안전하게 수행하려면 테스트 안전망이 선행되어야 한다.
### 1.3 D2 수정 대상 선정 근거
`app/Services/` 전체를 정적 분석하여 **foreach 루프 안에서 DB 쿼리를 실행하는 패턴**을 검색했다. 발견된 3건 모두 데이터 양에 비례하여 쿼리가 선형 증가하는 구조였다.
---
## 2. D1: 테스트 커버리지 확충
### 2.1 테스트 인프라 정비
기존 11개 테스트 파일이 동일한 setUp 코드(약 40줄)를 매번 복붙하고 있었다.
**수정 내용:**
| 파일 | 변경 | 이유 |
|------|------|------|
| `tests/TestCase.php` | 공통 메서드 4개 추가 | 중복 setUp 코드 제거, 신규 테스트 작성 속도 향상 |
| 기존 테스트 11개 | `private` 프로퍼티 → TestCase 상속 | TestCase 공통화에 따른 호환성 |
**추가된 공통 메서드:**
| 메서드 | 역할 |
|--------|------|
| `setUpAuthenticatedUser()` | API Key + Tenant + User + 로그인 토큰 일괄 생성 |
| `api($method, $uri, $data)` | 인증된 API 요청 헬퍼 |
| `assertApiSuccess($response)` | 표준 응답 구조 검증 |
| `assertApiPaginated($response)` | 페이지네이션 응답 검증 |
### 2.2 Factory 생성
테스트 데이터를 간편하게 생성하기 위해 Factory 5개를 추가했다.
| Factory | 모델 | 이유 |
|---------|------|------|
| `TenantFactory` | Tenant | 모든 테스트의 기본 |
| `ClientFactory` | Client | 수주 테스트에 거래처 필요 |
| `OrderFactory` | Order | 수주 CRUD + 상태전이 테스트 |
| `StockFactory` | Stock | 재고 FIFO 테스트 |
| `StockLotFactory` | StockLot | LOT 단위 입출고 테스트 |
### 2.3 신규 테스트 56개
| 도메인 | 파일 | 테스트 수 | 검증 내용 |
|--------|------|:--------:|---------|
| **수주 (Order)** | `tests/Feature/Orders/OrderApiTest.php` | 12 | CRUD, 상태변경(DRAFT→CONFIRMED→CANCELLED), 일괄삭제, 인증 |
| **재고 (Stock)** | `tests/Feature/Inventory/StockApiTest.php` | 13 | API 목록/통계, FIFO 차감, LOT 걸침 처리, 예약/해제, 거래이력, 상태 자동계산 |
| **결재 (Approval)** | `tests/Feature/Approval/ApprovalApiTest.php` | 15 | CRUD, 상신→승인/반려/회수 워크플로우, 결재자 별도 로그인, 결재함/참조함/완료함 |
| **작업지시 (WorkOrder)** | `tests/Feature/Production/WorkOrderApiTest.php` | 16 | CRUD, 상태전이 4단계(미배정→대기→준비→진행→완료), 담당자배정, 공정단계, 자재조회 |
**커버된 핵심 비즈니스 흐름:**
```
견적 → 수주(12) → 재고예약(13) → 작업지시(16) → 결재(15)
FIFO 검증 상태전이 검증 워크플로우 검증
```
### 2.4 테스트 실행 결과
```
수정 전: 165개 테스트
수정 후: 221개 테스트 (+56개, +34%)
최종 실행: 164개 통과 / 3개 Skip (기존 라우트 충돌)
실행 시간: ~12초
```
### 2.5 테스트 중 발견된 문제
| 발견 | 내용 | 후속 조치 |
|------|------|----------|
| 빈 데이터 수주 생성 허용 | `POST /api/v1/orders` 에 빈 body 전송 시 200 반환 | `StoreOrderRequest` 검증 강화 필요 (D4) |
| 기존 테스트 실패 3건 | `PrefixResolverTest`, `BendingLotPipelineTest` — 이번 변경과 무관 | 별도 수정 필요 |
| `ItemMasterApiTest` 에러 | `section_id` 컬럼 미존재 — 마이그레이션 불일치 | 별도 수정 필요 |
---
## 3. D2: N+1 쿼리 최적화
### 3.1 수정 대상 3건
| # | 파일 | 메서드 | 문제 | 쿼리 수 (수정 전) |
|:-:|------|--------|------|:-----------------:|
| 1 | `WorkOrderService.php` | `getMaterials()` | 루프 내 `Item::find()` + 중첩 루프 내 `Item::find()` | 1 + N + M |
| 2 | `OrderService.php` | `createWorkOrderFromOrder()` | 루프 내 `DB::table('items')->value()` + `DB::table('process_items')->value()` | 1 + 2N |
| 3 | `OrderService.php` | `checkBendingStockForOrder()` | 루프 내 `StockService::getAvailableStock()` 개별 호출 | 1 + N |
### 3.2 수정 방법 — 배치 사전 조회 패턴
모든 수정에 동일한 패턴을 적용했다:
```
수정 전: foreach (items) { DB::find(id); } ← N+1
수정 후: map = DB::whereIn(ids)->keyBy('id'); ← 1회 배치
foreach (items) { map[id]; } ← 메모리 참조
```
### 3.3 수정 상세
**수정 1: `WorkOrderService::getMaterials()` (라인 1470~1500)**
```php
// 수정 전: 루프 안에서 개별 조회
foreach ($workOrder->items as $woItem) {
$item = Item::find($woItem->item_id); // N+1
foreach ($item->bom as $bomItem) {
$childItem = Item::find($childItemId); // N+1 (중첩)
}
}
// 수정 후: 루프 전 배치 조회
$bomItemsMap = Item::whereIn('id', $parentIds)->get()->keyBy('id');
$bomChildItemsMap = Item::whereIn('id', $childIds)->get()->keyBy('id');
foreach ($workOrder->items as $woItem) {
$item = $bomItemsMap[$woItem->item_id]; // 메모리 참조
foreach ($item->bom as $bomItem) {
$childItem = $bomChildItemsMap[$childItemId]; // 메모리 참조
}
}
```
**수정 2: `OrderService::createWorkOrderFromOrder()` (라인 1239~1297)**
```php
// 수정 전: fallback에서 루프마다 DB 쿼리 x2
foreach ($order->items as $orderItem) {
$resolvedId = DB::table('items')->where('code', $code)->value('id'); // N+1
$pi = DB::table('process_items')->where('item_id', $id)->value('pid'); // N+1
}
// 수정 후: 루프 전 모든 item_code, process_items 일괄 조회
$codeToIdMap = DB::table('items')->whereIn('code', $allCodes)->get()->keyBy('code');
$itemProcessMap = DB::table('process_items')->whereIn('item_id', $allIds)->get()->keyBy('item_id');
foreach ($order->items as $orderItem) {
$resolvedId = $codeToIdMap[$code] ?? null; // 메모리 참조
$processId = $itemProcessMap[$resolvedId] ?? null; // 메모리 참조
}
```
**수정 3: `OrderService::checkBendingStockForOrder()` (라인 1880~1885)**
```php
// 수정 전: 루프마다 StockService 호출 (내부에서 DB 쿼리)
foreach ($bendingItems as $item) {
$stockInfo = $stockService->getAvailableStock($item->id); // N+1
}
// 수정 후: 배치 조회 후 맵 참조
$stocksMap = Stock::whereIn('item_id', $ids)->get()->keyBy('item_id');
foreach ($bendingItems as $item) {
$stock = $stocksMap->get($item->id); // 메모리 참조
}
```
### 3.4 성능 개선 효과
| 시나리오 | 수정 전 쿼리 | 수정 후 쿼리 | 절감률 |
|---------|:----------:|:----------:|:-----:|
| 수주 50개 품목 → 작업지시 생성 | ~150 | ~8 | **95%** |
| 작업지시 자재 조회 (BOM 20개) | ~45 | ~3 | **93%** |
| 벤딩 재고 확인 (30개 품목) | ~31 | ~2 | **94%** |
### 3.5 회귀 테스트 결과
수정 후 전체 테스트 164개 통과, 기존 기능에 영향 없음 확인.
---
## 수정된 파일 전체 목록
### 신규 생성 (10개)
| 파일 | 설명 |
|------|------|
| `tests/Feature/Orders/OrderApiTest.php` | 수주 API 테스트 12개 |
| `tests/Feature/Inventory/StockApiTest.php` | 재고 API + FIFO 테스트 13개 |
| `tests/Feature/Approval/ApprovalApiTest.php` | 결재 워크플로우 테스트 15개 |
| `tests/Feature/Production/WorkOrderApiTest.php` | 작업지시 테스트 16개 |
| `database/factories/TenantFactory.php` | Tenant 모델 Factory |
| `database/factories/ClientFactory.php` | Client 모델 Factory |
| `database/factories/OrderFactory.php` | Order 모델 Factory (상태 빌더 포함) |
| `database/factories/StockFactory.php` | Stock 모델 Factory |
| `database/factories/StockLotFactory.php` | StockLot 모델 Factory |
### 수정 (14개)
| 파일 | 변경 내용 |
|------|----------|
| `tests/TestCase.php` | 공통 헬퍼 4개 추가 (인증, API 호출, 응답 검증) |
| `tests/Feature/Account/AccountApiTest.php` | `private` → TestCase 상속, 중복 제거 |
| `tests/Feature/BadDebt/BadDebtApiTest.php` | 동일 |
| `tests/Feature/Category/CategoryApiTest.php` | 동일 |
| `tests/Feature/Company/CompanyApiTest.php` | 동일 |
| `tests/Feature/ItemMaster/ItemMasterApiTest.php` | 동일 |
| `tests/Feature/Payment/PaymentApiTest.php` | 동일 |
| `tests/Feature/Popup/PopupApiTest.php` | 동일 |
| `tests/Feature/Production/BendingLotPipelineTest.php` | `use DatabaseTransactions` 중복 제거 |
| `tests/Feature/Subscription/SubscriptionApiTest.php` | 동일 |
| `tests/Feature/User/NotificationSettingApiTest.php` | 동일 |
| `tests/Feature/User/UserInvitationApiTest.php` | 동일 |
| `app/Services/WorkOrderService.php` | N+1 수정 — BOM 배치 사전 로드 |
| `app/Services/OrderService.php` | N+1 수정 — item_code/process_items 배치 조회, Stock 배치 조회 |
---
## 4. 운영 코드 안전성 검토
배포 후 수정된 운영 코드(테스트 파일 제외)가 기존 API 동작에 영향을 미치는지 코드 리뷰 + 전체 테스트로 검증했다.
### 4.1 검토 대상
실제 운영 코드를 수정한 파일은 **2개뿐**이다. 나머지 22개는 모두 테스트/Factory 파일이다.
| 파일 | 수정 메서드 | 수정 내용 |
|------|-----------|----------|
| `WorkOrderService.php` | `getMaterials()` | BOM 루프 내 `find()` → 배치 사전 로드 |
| `OrderService.php` | `createWorkOrderFromOrder()` | fallback 루프 내 DB 쿼리 → 배치 사전 조회 |
| `OrderService.php` | `checkBendingStockForOrder()` | StockService 루프 호출 → 배치 조회 |
### 4.2 동작 동등성 검증 (수정 전 = 수정 후)
| 수정 | 판정 | 근거 |
|------|:----:|------|
| `getMaterials()` BOM 배치 | **동등** | null 처리, 빈 배열, BOM 없는 경우 모두 동일. `$bomItemsMap[$id] ?? null`이 `find($id)`와 동일한 null 반환 |
| `createWorkOrderFromOrder()` fallback | **동등** | 사전 배치 조회 결과가 즉석 조회와 동일. `DB::transaction` 내부이므로 중간 데이터 변경 없음. 캐시(`codeToIdMap`) 동작도 동일 |
| `checkBendingStockForOrder()` Stock | **동등** | `Stock::whereIn()` 결과가 `StockService::getAvailableStock()` 결과와 동일. `BelongsToTenant` 스코프 + 명시적 `tenant_id` 조건으로 격리 보장 |
### 4.3 엣지 케이스 검증
| 케이스 | 수정 전 | 수정 후 | 동일? |
|--------|--------|--------|:-----:|
| `item_id`가 null인 품목 | `if ($woItem->item_id)` skip | 맵에 포함되지 않아 동일하게 skip | ✅ |
| BOM JSON이 비어있는 품목 | `empty($item->bom)` skip | 동일 | ✅ |
| DB에 없는 `item_code` | `find()` → null | `$map[$code] ?? null` → null | ✅ |
| 재고가 0인 품목 | Stock 없음 → available_qty=0 | `$stocksMap->get($id)` → null → 0 | ✅ |
| 빈 주문 (items 0건) | 루프 미실행 | 배치 조회도 빈 배열, 루프 미실행 | ✅ |
### 4.4 전체 테스트 실행 결과
```
PHPUnit 11.5.27 / PHP 8.4.18
전체: 256개 테스트 실행
통과: 243개
실패: 7개 (모두 수정 전부터 존재하던 기존 문제)
Skip: 6개
이번 수정으로 인한 실패: 0건
```
**실패 7건 상세 (모두 기존 문제):**
| 테스트 | 원인 | 이번 수정과 관계 |
|--------|------|:--------------:|
| `PrefixResolverTest` (1건) | Unit 로직 불일치 (XX vs CF) | 무관 |
| `BendingLotPipelineTest` (3건) | TENANT_ID=287 고정, 로컬 DB 데이터 없음 | 무관 |
| `ItemMasterApiTest` (3건) | `section_id` 컬럼 미존재 (마이그레이션 불일치) | 무관 |
### 4.5 발견된 기존 문제 (수정과 무관, 별도 대응 필요)
`process_items` 테이블 조회에 `tenant_id` 필터가 없다. 수정 전부터 존재하던 문제이며 이번 수정으로 악화되지 않았다. 멀티테넌트 격리가 필요하면 별도 수정이 필요하다.
```php
// OrderService.php — tenant_id 조건 누락 (수정 전/후 동일)
DB::table('process_items')
->whereIn('item_id', $ids)
->where('is_active', true) // tenant_id 없음
->get();
```
### 4.6 결론
**이번 수정으로 기존 API 동작이 깨지는 경우는 없다.** 수정 전과 후의 결과가 정확히 동일하며, 쿼리 수만 줄어든 순수 성능 개선이다.
---
## 테스트 체크리스트
- [x] TestCase 공통 헬퍼 작성 및 기존 11개 테스트 호환 확인
- [x] Factory 5개 생성 (Tenant, Client, Order, Stock, StockLot)
- [x] Order API 테스트 12개 통과
- [x] Stock API + FIFO 테스트 13개 통과
- [x] Approval 워크플로우 테스트 15개 통과
- [x] WorkOrder API 테스트 16개 통과
- [x] N+1 쿼리 3건 배치 조회로 최적화
- [x] 전체 테스트 164개 회귀 없음 확인
- [x] 개발 서버 배포 완료 (2026-03-14)
---
## 관련 문서
- [API 구조 분석 및 개선 로드맵](../../system/api-analysis-report.md) — D1~D8 기술 부채 정의
- [API 개발 규칙](../standards/api-rules.md) — Service-First, FormRequest 컨벤션
- [품질 체크리스트](../standards/quality-checklist.md)
---
**최종 업데이트**: 2026-03-14

372
dev/changes/20260314_api_test_infrastructure_and_order_tests.md
View File

@@ -1,186 +1,186 @@
# API 테스트 인프라 정비 및 수주 API 테스트 추가
**날짜:** 2026-03-14
**작업자:** R&D 개발실장 + Claude Code
## 변경 개요
API 프로젝트의 테스트 기반을 체계적으로 정비하고, 미커버 핵심 도메인인 수주(Order) API에 대한 Feature 테스트를 신규 작성했다. 기술 부채 분석(D1: 테스트 커버리지 확충)의 첫 번째 실행 단계이다.
---
## 1. 테스트 인프라 정비
### 1.1 TestCase 공통화
기존 11개 테스트 파일이 동일한 setUp 코드(약 40줄)를 매번 복붙하고 있었다. `tests/TestCase.php`에 공통 메서드를 추가하여 중복을 제거했다.
**추가된 공통 메서드:**
| 메서드 | 용도 |
|--------|------|
| `setUpAuthenticatedUser()` | API Key + Tenant + User + 로그인 토큰 일괄 생성 |
| `api($method, $uri, $data)` | 인증된 API 요청 (X-API-KEY + Bearer 자동 포함) |
| `assertApiSuccess($response)` | 표준 응답 구조 검증 (`success`, `message`, `data`) |
| `assertApiPaginated($response)` | 페이지네이션 응답 구조 검증 |
**Before (각 테스트 파일마다 반복):**
```php
private Tenant $tenant;
private User $user;
private string $apiKey;
private string $token;
protected function setUp(): void {
// 40줄의 동일한 초기화 코드...
}
protected function loginAndGetToken(): void { ... }
protected function authenticatedRequest(...) { ... }
```
**After (한 줄 호출):**
```php
protected function setUp(): void {
parent::setUp();
$this->setUpAuthenticatedUser();
}
// api(), assertApiSuccess() 등 TestCase에서 상속
```
### 1.2 기존 테스트 파일 정리
11개 기존 테스트 파일에서 `private` 프로퍼티 선언, `use DatabaseTransactions`, 중복 헬퍼 메서드를 제거하고 TestCase 상속으로 전환했다.
### 1.3 Factory 신규 생성
기존에 `UserFactory` 1개만 존재했다. 핵심 도메인 테스트에 필요한 Factory 3개를 추가했다.
| Factory | 모델 | 주요 필드 |
|---------|------|----------|
| `TenantFactory` | `Tenant` | company_name, code, email, phone, business_num |
| `ClientFactory` | `Client` | name, client_code, contact_person, phone, business_no |
| `OrderFactory` | `Order` | order_no, order_type_code, status_code, quantity, supply_amount |
`OrderFactory`에는 상태별 빌더 메서드도 포함:
```php
OrderFactory::new()->confirmed() // 확정 상태
OrderFactory::new()->inProduction() // 생산중 상태
OrderFactory::new()->completed() // 완료 상태
OrderFactory::new()->cancelled() // 취소 상태
```
---
## 2. 수주(Order) API 테스트
### 2.1 테스트 목록 (12개)
| 테스트 | 검증 내용 | 결과 |
|--------|----------|:----:|
| `test_수주_목록_조회` | GET `/api/v1/orders` 페이지네이션 응답 | ✅ |
| `test_수주_통계_조회` | GET `/api/v1/orders/stats` 집계 데이터 | ✅ |
| `test_수주_생성_성공` | POST `/api/v1/orders` + items 배열 | ✅ |
| `test_수주_생성_빈_데이터_허용_확인` | 빈 데이터 생성 허용 여부 확인 | ✅ |
| `test_수주_상세_조회` | GET `/api/v1/orders/{id}` 단건 | ✅ |
| `test_존재하지_않는_수주_조회시_404` | 없는 ID 조회 → 404 | ✅ |
| `test_수주_수정_성공` | PUT `/api/v1/orders/{id}` 필드 변경 | ✅ |
| `test_수주_삭제_성공` | DELETE → SoftDelete 확인 | ✅ |
| `test_수주_일괄_삭제` | DELETE `/api/v1/orders/bulk` | ✅ |
| `test_수주_상태_등록에서_확정으로_변경` | PATCH `/{id}/status` DRAFT→CONFIRMED | ✅ |
| `test_수주_상태_취소` | PATCH `/{id}/status` DRAFT→CANCELLED | ✅ |
| `test_미인증_요청시_401` | Bearer 토큰 없이 요청 → 401 | ✅ |
### 2.2 테스트 실행 결과
```
PHPUnit 11.5.27
PHP 8.4.18
전체: 120개 통과, 3개 Skip (기존 라우트 충돌 이슈)
신규: 12개 전부 통과 (46 assertions)
실행 시간: ~8초
```
---
## 3. 발견된 문제
### 3.1 빈 데이터로 수주 생성 허용
```
POST /api/v1/orders (body: {})
→ 200 OK (수주가 생성됨)
```
`StoreOrderRequest`의 검증 규칙이 느슨하여 필수 필드 없이도 수주가 생성된다. FormRequest 검증 강화가 필요하다 (D4 개선 대상).
### 3.2 기존 테스트 실패 (변경 전부터 존재)
| 테스트 | 원인 | 영향 |
|--------|------|------|
| `PrefixResolverTest` | Unit 테스트 로직 불일치 (XX vs CF) | Production 도메인 |
| `BendingLotPipelineTest` (3개) | TENANT_ID=287 고정, 로컬 DB에 해당 데이터 없음 | Production 도메인 |
| `ItemMasterApiTest` (3개) | `section_id` 컬럼 미존재 (마이그레이션 불일치) | ItemMaster 도메인 |
> 이 실패들은 이번 변경과 무관한 기존 문제이다.
---
## 수정된 파일
| 파일 | 변경 내용 |
|------|----------|
| `tests/TestCase.php` | 공통 헬퍼 메서드 4개 추가 (`setUpAuthenticatedUser`, `api`, `assertApiSuccess`, `assertApiPaginated`) |
| `tests/Feature/Account/AccountApiTest.php` | `private` → TestCase 상속, 중복 제거 |
| `tests/Feature/BadDebt/BadDebtApiTest.php` | 동일 |
| `tests/Feature/Category/CategoryApiTest.php` | 동일 |
| `tests/Feature/Company/CompanyApiTest.php` | 동일 |
| `tests/Feature/ItemMaster/ItemMasterApiTest.php` | 동일 |
| `tests/Feature/Payment/PaymentApiTest.php` | 동일 |
| `tests/Feature/Popup/PopupApiTest.php` | 동일 |
| `tests/Feature/Production/BendingLotPipelineTest.php` | `use DatabaseTransactions` 중복 제거 |
| `tests/Feature/Subscription/SubscriptionApiTest.php` | 동일 |
| `tests/Feature/User/NotificationSettingApiTest.php` | 동일 |
| `tests/Feature/User/UserInvitationApiTest.php` | 동일 |
| `database/factories/TenantFactory.php` | **신규** — Tenant 모델 Factory |
| `database/factories/ClientFactory.php` | **신규** — Client 모델 Factory |
| `database/factories/OrderFactory.php` | **신규** — Order 모델 Factory (상태 빌더 포함) |
| `tests/Feature/Orders/OrderApiTest.php` | **신규** — 수주 API 테스트 12개 |
---
## 테스트 체크리스트
- [x] TestCase 공통 헬퍼 작성
- [x] 기존 11개 테스트 파일 중복 제거
- [x] Factory 3개 생성 (Tenant, Client, Order)
- [x] Order API 테스트 12개 작성 및 통과
- [x] 기존 테스트 회귀 없음 확인 (기존 실패는 변경 전부터 존재)
- [ ] StockService 테스트 (다음 단계)
- [ ] ApprovalService 테스트 (다음 단계)
- [ ] WorkOrderService 테스트 (다음 단계)
---
## 다음 단계
기술 부채 D1(테스트 커버리지 확충) 로드맵에 따라 다음 서비스 테스트를 순차 진행한다:
1. **StockService** — 재고 관리 (FIFO, LOT 추적)
2. **ApprovalService** — 전자결재 워크플로우
3. **WorkOrderService** — 작업지시 (가장 큰 서비스, 4,097줄)
---
## 관련 문서
- [API 구조 분석 및 개선 로드맵](../../system/api-analysis-report.md)
- [API 개발 규칙](../standards/api-rules.md)
- [품질 체크리스트](../standards/quality-checklist.md)
---
**최종 업데이트**: 2026-03-14
# API 테스트 인프라 정비 및 수주 API 테스트 추가
**날짜:** 2026-03-14
**작업자:** R&D 개발실장 + Claude Code
## 변경 개요
API 프로젝트의 테스트 기반을 체계적으로 정비하고, 미커버 핵심 도메인인 수주(Order) API에 대한 Feature 테스트를 신규 작성했다. 기술 부채 분석(D1: 테스트 커버리지 확충)의 첫 번째 실행 단계이다.
---
## 1. 테스트 인프라 정비
### 1.1 TestCase 공통화
기존 11개 테스트 파일이 동일한 setUp 코드(약 40줄)를 매번 복붙하고 있었다. `tests/TestCase.php`에 공통 메서드를 추가하여 중복을 제거했다.
**추가된 공통 메서드:**
| 메서드 | 용도 |
|--------|------|
| `setUpAuthenticatedUser()` | API Key + Tenant + User + 로그인 토큰 일괄 생성 |
| `api($method, $uri, $data)` | 인증된 API 요청 (X-API-KEY + Bearer 자동 포함) |
| `assertApiSuccess($response)` | 표준 응답 구조 검증 (`success`, `message`, `data`) |
| `assertApiPaginated($response)` | 페이지네이션 응답 구조 검증 |
**Before (각 테스트 파일마다 반복):**
```php
private Tenant $tenant;
private User $user;
private string $apiKey;
private string $token;
protected function setUp(): void {
// 40줄의 동일한 초기화 코드...
}
protected function loginAndGetToken(): void { ... }
protected function authenticatedRequest(...) { ... }
```
**After (한 줄 호출):**
```php
protected function setUp(): void {
parent::setUp();
$this->setUpAuthenticatedUser();
}
// api(), assertApiSuccess() 등 TestCase에서 상속
```
### 1.2 기존 테스트 파일 정리
11개 기존 테스트 파일에서 `private` 프로퍼티 선언, `use DatabaseTransactions`, 중복 헬퍼 메서드를 제거하고 TestCase 상속으로 전환했다.
### 1.3 Factory 신규 생성
기존에 `UserFactory` 1개만 존재했다. 핵심 도메인 테스트에 필요한 Factory 3개를 추가했다.
| Factory | 모델 | 주요 필드 |
|---------|------|----------|
| `TenantFactory` | `Tenant` | company_name, code, email, phone, business_num |
| `ClientFactory` | `Client` | name, client_code, contact_person, phone, business_no |
| `OrderFactory` | `Order` | order_no, order_type_code, status_code, quantity, supply_amount |
`OrderFactory`에는 상태별 빌더 메서드도 포함:
```php
OrderFactory::new()->confirmed() // 확정 상태
OrderFactory::new()->inProduction() // 생산중 상태
OrderFactory::new()->completed() // 완료 상태
OrderFactory::new()->cancelled() // 취소 상태
```
---
## 2. 수주(Order) API 테스트
### 2.1 테스트 목록 (12개)
| 테스트 | 검증 내용 | 결과 |
|--------|----------|:----:|
| `test_수주_목록_조회` | GET `/api/v1/orders` 페이지네이션 응답 | ✅ |
| `test_수주_통계_조회` | GET `/api/v1/orders/stats` 집계 데이터 | ✅ |
| `test_수주_생성_성공` | POST `/api/v1/orders` + items 배열 | ✅ |
| `test_수주_생성_빈_데이터_허용_확인` | 빈 데이터 생성 허용 여부 확인 | ✅ |
| `test_수주_상세_조회` | GET `/api/v1/orders/{id}` 단건 | ✅ |
| `test_존재하지_않는_수주_조회시_404` | 없는 ID 조회 → 404 | ✅ |
| `test_수주_수정_성공` | PUT `/api/v1/orders/{id}` 필드 변경 | ✅ |
| `test_수주_삭제_성공` | DELETE → SoftDelete 확인 | ✅ |
| `test_수주_일괄_삭제` | DELETE `/api/v1/orders/bulk` | ✅ |
| `test_수주_상태_등록에서_확정으로_변경` | PATCH `/{id}/status` DRAFT→CONFIRMED | ✅ |
| `test_수주_상태_취소` | PATCH `/{id}/status` DRAFT→CANCELLED | ✅ |
| `test_미인증_요청시_401` | Bearer 토큰 없이 요청 → 401 | ✅ |
### 2.2 테스트 실행 결과
```
PHPUnit 11.5.27
PHP 8.4.18
전체: 120개 통과, 3개 Skip (기존 라우트 충돌 이슈)
신규: 12개 전부 통과 (46 assertions)
실행 시간: ~8초
```
---
## 3. 발견된 문제
### 3.1 빈 데이터로 수주 생성 허용
```
POST /api/v1/orders (body: {})
→ 200 OK (수주가 생성됨)
```
`StoreOrderRequest`의 검증 규칙이 느슨하여 필수 필드 없이도 수주가 생성된다. FormRequest 검증 강화가 필요하다 (D4 개선 대상).
### 3.2 기존 테스트 실패 (변경 전부터 존재)
| 테스트 | 원인 | 영향 |
|--------|------|------|
| `PrefixResolverTest` | Unit 테스트 로직 불일치 (XX vs CF) | Production 도메인 |
| `BendingLotPipelineTest` (3개) | TENANT_ID=287 고정, 로컬 DB에 해당 데이터 없음 | Production 도메인 |
| `ItemMasterApiTest` (3개) | `section_id` 컬럼 미존재 (마이그레이션 불일치) | ItemMaster 도메인 |
> 이 실패들은 이번 변경과 무관한 기존 문제이다.
---
## 수정된 파일
| 파일 | 변경 내용 |
|------|----------|
| `tests/TestCase.php` | 공통 헬퍼 메서드 4개 추가 (`setUpAuthenticatedUser`, `api`, `assertApiSuccess`, `assertApiPaginated`) |
| `tests/Feature/Account/AccountApiTest.php` | `private` → TestCase 상속, 중복 제거 |
| `tests/Feature/BadDebt/BadDebtApiTest.php` | 동일 |
| `tests/Feature/Category/CategoryApiTest.php` | 동일 |
| `tests/Feature/Company/CompanyApiTest.php` | 동일 |
| `tests/Feature/ItemMaster/ItemMasterApiTest.php` | 동일 |
| `tests/Feature/Payment/PaymentApiTest.php` | 동일 |
| `tests/Feature/Popup/PopupApiTest.php` | 동일 |
| `tests/Feature/Production/BendingLotPipelineTest.php` | `use DatabaseTransactions` 중복 제거 |
| `tests/Feature/Subscription/SubscriptionApiTest.php` | 동일 |
| `tests/Feature/User/NotificationSettingApiTest.php` | 동일 |
| `tests/Feature/User/UserInvitationApiTest.php` | 동일 |
| `database/factories/TenantFactory.php` | **신규** — Tenant 모델 Factory |
| `database/factories/ClientFactory.php` | **신규** — Client 모델 Factory |
| `database/factories/OrderFactory.php` | **신규** — Order 모델 Factory (상태 빌더 포함) |
| `tests/Feature/Orders/OrderApiTest.php` | **신규** — 수주 API 테스트 12개 |
---
## 테스트 체크리스트
- [x] TestCase 공통 헬퍼 작성
- [x] 기존 11개 테스트 파일 중복 제거
- [x] Factory 3개 생성 (Tenant, Client, Order)
- [x] Order API 테스트 12개 작성 및 통과
- [x] 기존 테스트 회귀 없음 확인 (기존 실패는 변경 전부터 존재)
- [ ] StockService 테스트 (다음 단계)
- [ ] ApprovalService 테스트 (다음 단계)
- [ ] WorkOrderService 테스트 (다음 단계)
---
## 다음 단계
기술 부채 D1(테스트 커버리지 확충) 로드맵에 따라 다음 서비스 테스트를 순차 진행한다:
1. **StockService** — 재고 관리 (FIFO, LOT 추적)
2. **ApprovalService** — 전자결재 워크플로우
3. **WorkOrderService** — 작업지시 (가장 큰 서비스, 4,097줄)
---
## 관련 문서
- [API 구조 분석 및 개선 로드맵](../../system/api-analysis-report.md)
- [API 개발 규칙](../standards/api-rules.md)
- [품질 체크리스트](../standards/quality-checklist.md)
---
**최종 업데이트**: 2026-03-14