현재 운영 중인 모바일 앱과 ERP 웹 시스템에 공통으로 사용하는 전자결재 기능을 개발한다.

전자결재 품의 종류는 다음 2가지이다.

1. 지출품의

2. 연차신청

모바일 앱과 ERP 웹은 서로 별도의 데이터를 운영하지 않는다.

반드시 동일한 서버 API와 데이터베이스를 사용하며, 모바일 앱에서 작성한 문서는 ERP 웹에서 즉시 조회 가능하고 ERP 웹에서 처리한 결재 결과도 모바일 앱에 즉시 반영되어야 한다.

전자결재의 기본 프로세스는 다음과 같다.

작성

→ 임시저장

→ 작성완료

→ 전송

→ 1차 결재

→ 다음 결재자 전달

→ 최종결재

→ 완료

반려가 발생한 경우:

결재대기

→ 반려

→ 신청자 확인

의 상태로 처리한다.

==================================================

1. 개발 전 기존 프로젝트 분석

==================================================

코드를 바로 수정하지 말고 먼저 현재 프로젝트 구조를 분석한다.

다음을 확인한다.

1. 모바일 앱 기술 스택

2. ERP 웹 기술 스택

3. 로그인 및 인증 구조

4. 회원 테이블

5. 부서 테이블

6. 직급/직책 정보

7. API 호출 방식

8. 파일 업로드 방식

9. 기존 알림 시스템

10. 현재 데이터베이스 구조

기존 회원 DB를 반드시 재사용한다.

전자결재를 위해 별도 회원 시스템을 만들지 않는다.

회원 정보에서 최소 다음 항목을 사용할 수 있어야 한다.

- 회원 고유번호

- 회원 이름

- 소속 부서

- 직급 또는 직책

- 재직 여부

기존 시스템과 충돌하지 않는 방식으로 개발한다.

==================================================

2. 전체 메뉴 구성

==================================================

전자결재 메뉴는 다음 4개 페이지로 구성한다.

1. 품의작성

2. 작성리스트

3. 송신함

4. 수신함

==================================================

3. 문서 상태 정의

==================================================

전자결재 문서 상태는 문자열을 직접 화면에 저장하지 말고 내부 상태값으로 관리한다.

권장 상태값:

DRAFT

작성중

READY

작성완료, 미전송

IN_PROGRESS

전송완료, 결재진행중

APPROVED

최종결재 완료

REJECTED

반려

WITHDRAWN

작성자가 회수

화면에는 다음과 같이 표시한다.

DRAFT → 작성중

READY → 전송대기

IN_PROGRESS → 결재진행중

APPROVED → 결재완료

REJECTED → 반려

WITHDRAWN → 회수

==================================================

4. 품의작성 페이지

==================================================

## 4.1 품의 종류 선택

페이지 상단에서 다음 중 하나를 선택한다.

- 지출품의

- 연차신청

품의 종류에 따라 입력 화면을 다르게 표시한다.

==================================================

5. 공통 입력 항목

==================================================

지출품의와 연차신청 모두 다음 항목을 입력한다.

1. 결재라인

2. 제목

3. 내용

4. 첨부파일

==================================================

6. 결재라인 선택

==================================================

'결재라인 선택' 버튼을 제공한다.

버튼 클릭 시 기존 회원 리스트를 표시한다.

회원리스트 출력 항목:

- 이름

- 부서

- 직급 또는 직책

회원 선택 순서대로 결재순서를 지정한다.

예:

1. 김대리

2. 이사

3. 대표이사

결재라인 선택 화면에서 다음 기능을 제공한다.

- 회원 검색

- 회원 선택

- 선택 취소

- 결재순서 변경

- 결재자 삭제

결재라인은 최소 1명 이상 선택해야 한다.

작성자 본인은 기본적으로 결재라인에서 제외한다.

단, 향후 정책 변경을 고려하여 서버에서 검증 가능하도록 구성한다.

==================================================

7. 결재 진행 방식

==================================================

결재는 순차결재 방식으로 구현한다.

예:

결재라인

1. 김대리

2. 이사

3. 대표이사

문서 전송 직후:

김대리 → 결재 가능

이사 → 대기

대표이사 → 대기

김대리 결재 후:

김대리 → 완료

이사 → 결재 가능

대표이사 → 대기

이사 결재 후:

김대리 → 완료

이사 → 완료

대표이사 → 결재 가능

대표이사 결재 후:

문서 전체 상태를 APPROVED로 변경한다.

현재 결재순서에 해당하는 사용자만 결재할 수 있어야 한다.

프론트엔드 버튼 숨김만으로 권한을 제한하지 않는다.

서버 API에서도 반드시 현재 결재자 여부를 검증한다.

==================================================

8. 지출품의 작성

==================================================

지출품의를 선택하면 '지출항목 추가' 버튼을 표시한다.

지출항목 입력 필드는 다음과 같다.

1. 품명

2. 거래처명

3. 수량

4. 단가

5. 공급가액

6. 부가세

7. 금액

8. 증빙종류

9. 증빙파일

==================================================

9. 지출금액 자동계산

==================================================

기본 계산 방식:

공급가액 = 수량 × 단가

부가세 = 공급가액 × 10%

금액 = 공급가액 + 부가세

예:

수량 = 2

단가 = 100,000

공급가액 = 200,000

부가세 = 20,000

금액 = 220,000

금액 계산은 프론트엔드에서 실시간 표시하되 서버에서도 다시 계산하여 검증한다.

클라이언트에서 전달받은 최종금액을 그대로 신뢰하지 않는다.

금액은 정수 단위로 저장한다.

부가세 계산 시 소수점 처리 정책을 하나로 통일한다.

기본값은 원 단위 반올림으로 한다.

==================================================

10. 지출항목 추가 방식

==================================================

'지출항목 추가' 버튼 클릭

→ 지출항목 입력 폼 표시

→ 저장

→ 작성 화면에 등록된 항목 카드 또는 리스트 표시

→ 리스트 하단에 다시 '지출항목 추가' 버튼 표시

사용자는 여러 개의 지출항목을 반복적으로 등록할 수 있다.

각 지출항목은 다음 기능을 제공한다.

- 수정

- 삭제

문서 전송 전까지만 수정 및 삭제할 수 있다.

==================================================

11. 증빙종류

==================================================

다음 중 하나를 선택한다.

- 영수증

- 세금계산서

- 현금영수증

- 카드매출전표

- 기타

- 해당없음

각 지출항목별로 증빙파일을 첨부할 수 있도록 한다.

허용 파일 형식은 기존 파일 업로드 정책을 확인한 후 적용한다.

기본 권장 형식:

- JPG

- JPEG

- PNG

- PDF

서버에서 확장자와 MIME 타입을 모두 검증한다.

==================================================

12. 지출품의 합계

==================================================

모든 지출항목의 합계를 자동 계산한다.

다음 합계를 표시한다.

- 총 공급가액

- 총 부가세

- 최종 합계금액

계산식:

총 공급가액

= 모든 항목 공급가액의 합

총 부가세

= 모든 항목 부가세의 합

최종 합계금액

= 모든 항목 금액의 합

==================================================

13. 연차신청 작성

==================================================

연차신청을 선택하면 지출항목 버튼은 표시하지 않는다.

다음 전용 입력항목을 표시한다.

1. 연차구분

2. 사용 시작일

3. 사용 종료일

4. 사용일수

5. 사용사유

6. 업무인계자

7. 첨부파일

연차구분:

- 연차

- 오전반차

- 오후반차

- 시간차

기존 ERP 근태관리 시스템에 연차 데이터가 존재하는 경우 현재 잔여연차를 표시할 수 있도록 향후 확장 가능한 구조로 작성한다.

최종결재 완료 시 근태관리 시스템에 연차 사용정보를 자동 반영할 수 있도록 서비스 계층을 분리한다.

초기 버전에서 자동반영을 하지 않더라도 향후 연결이 가능해야 한다.

==================================================

14. 자동 생성 항목

==================================================

사용자가 직접 입력하지 않는 히든값은 다음과 같다.

1. 문서번호

2. 부서명

3. 담당자

4. 작성일

5. 요청일자

==================================================

15. 문서번호 생성

==================================================

형식:

소속명 첫 글자-YYMMDD-일련번호

예:

연구개발부

2026년 7월 6일

해당 날짜의 첫 번째 문서

결과:

연-260706-01

두 번째 문서:

연-260706-02

문서번호는 프론트엔드에서 생성하지 않는다.

반드시 서버에서 생성한다.

동시에 여러 사람이 문서를 생성해도 문서번호가 중복되지 않도록 DB 트랜잭션 또는 별도 시퀀스 관리 방식을 적용한다.

문서번호는 UNIQUE 제약조건을 적용한다.

==================================================

16. 자동 입력 정보

==================================================

부서명:

로그인한 작성자의 현재 부서명

담당자:

로그인한 작성자의 이름

작성일:

문서 최초 생성 일자

표시 형식:

2026년 07월 06일

DB 저장 형식은 날짜 또는 DATETIME 타입을 사용한다.

화면 표시용 문자열 자체를 DB에 저장하지 않는다.

요청일자:

기본값은 작성일과 동일하게 한다.

지출품의에서 사용자가 변경할 수 있도록 할지 여부는 기존 업무규칙 확인 후 결정한다.

==================================================

17. 저장

==================================================

작성 중 저장 시 문서 상태:

DRAFT

작성 완료 시:

READY

작성 완료 후 작성리스트에 표시한다.

READY 상태라도 전송 전까지는 수정할 수 있다.

==================================================

18. 작성리스트 페이지

==================================================

작성자가 작성 완료했지만 아직 전송하지 않은 문서를 카드 형태로 표시한다.

대상 상태:

READY

카드 표시정보:

- 문서종류

- 문서번호

- 제목

- 작성일

- 총금액 또는 연차기간

- 상태

카드 우측 하단에 '전송' 버튼을 표시한다.

카드 클릭 시 상세 레이어 창을 표시한다.

지출품의는 첨부된 지출품의서 이미지와 유사한 문서형 양식으로 표시한다.

레이어 창에서는 다음을 제공한다.

- 문서 상세보기

- 수정

- 삭제

- 닫기

문서 전송 전까지만 수정 및 삭제 가능하다.

==================================================

19. 전송 처리

==================================================

전송 버튼 클릭 시 확인창을 표시한다.

문구 예:

"결재를 요청하시겠습니까?

전송 후에는 내용을 수정할 수 없습니다."

확인 시:

1. 결재라인 존재 여부 검증

2. 필수입력값 검증

3. 지출항목 검증

4. 문서번호 확정

5. 전송일시 저장

6. 상태를 IN_PROGRESS로 변경

7. 첫 번째 결재자를 현재 결재자로 설정

8. 첫 번째 결재자에게 알림 전송

전송 이후 작성리스트에서는 제거되고 송신함에 표시한다.

==================================================

20. 송신함

==================================================

내가 전송한 품의서를 표시한다.

상단 탭:

- 진행중

- 완료

- 반려

진행중:

IN_PROGRESS

완료:

APPROVED

반려:

REJECTED

카드 표시정보:

- 문서종류

- 문서번호

- 제목

- 전송일자

- 현재 결재대상자

- 결재 진행률

- 상태

예:

제목:

Apple Developer Program 결제

전송일:

2026.07.06

현재 결재자:

이사 홍길동

결재진행:

1 / 3

카드 클릭 시 문서 상세 레이어 창을 표시한다.

==================================================

21. 수신함

==================================================

내가 결재할 문서와 이미 처리한 문서를 표시한다.

상단 탭:

- 대기

- 완료

대기:

현재 내가 결재할 차례인 문서

완료:

내가 결재 또는 반려 처리를 완료한 문서

대기 카드 표시정보:

- 문서종류

- 문서번호

- 신청자

- 신청자 부서

- 제목

- 요청일

- 결재요청일

- 결재 버튼

지출품의인 경우:

- 총금액

연차신청인 경우:

- 연차기간

추가 표시

==================================================

22. 결재 처리

==================================================

대기 문서 카드 또는 상세 레이어에서 '결재' 버튼을 제공한다.

결재 버튼 클릭 시 확인창:

"이 문서를 결재하시겠습니까?"

확인 후 서버에서 다음을 검증한다.

1. 로그인 사용자 확인

2. 해당 문서 존재 여부

3. 문서 상태가 IN_PROGRESS인지 확인

4. 현재 사용자가 현재 결재자인지 확인

5. 이미 결재 처리했는지 확인

검증 성공 시:

1. 결재 상태를 APPROVED 처리

2. 결재자 이름 저장

3. 결재일시 저장

4. 다음 결재자 확인

다음 결재자가 있으면:

- 다음 결재자를 현재 결재자로 변경

- 다음 결재자에게 알림 전송

다음 결재자가 없으면:

- 문서 전체 상태를 APPROVED로 변경

- 최종결재일시 저장

- 신청자에게 최종결재 완료 알림 전송

==================================================

23. 반려 처리

==================================================

대기 문서에 다음 버튼을 제공한다.

- 결재

- 반려

반려 버튼 클릭 시 반려사유 입력창을 표시한다.

반려사유는 필수입력으로 한다.

반려 처리 시:

1. 현재 결재자 권한 검증

2. 현재 결재단계 REJECTED 처리

3. 반려자 저장

4. 반려일시 저장

5. 반려사유 저장

6. 문서 전체 상태 REJECTED 처리

7. 신청자에게 반려 알림 전송

==================================================

24. 결재선 표시

==================================================

첨부된 지출품의서 상단 결재란과 유사하게 표시한다.

예:

담당 | 이사 | 대표이사

각 결재칸에는 다음을 표시한다.

결재 전:

직책 또는 이름

대기 상태

결재 후:

홍길동

2026.07.06

14:32

결재자 이름은 크게 표시한다.

이름 아래 결재일시를 작게 표시한다.

결재일시는 실제 서버 처리시간을 사용한다.

클라이언트 시간이 아니라 서버 시간을 기준으로 한다.

==================================================

25. 지출품의서 상세 양식

==================================================

첨부된 이미지를 기준으로 지출품의서는 문서형 UI로 구현한다.

상단:

지출 (품의) 결의서

기본정보:

- 문서번호

- 부서명

- 담당자

- 작성일자

- 요청일자

결재영역:

- 결재순서

- 결재자 직책

- 결재자명

- 결재일시

본문:

- 제목

- 내용

지출항목 테이블:

- 품명

- 거래처명

- 수량

- 단가

- 공급가액

- 부가세

- 금액

- 증빙종류

합계:

- 총 공급가액

- 총 부가세

- 최종 합계금액

하단:

- 비고

- 계좌번호

- 첨부파일

모바일 화면에서는 실제 A4 크기를 그대로 축소하여 글자를 작게 만들지 않는다.

모바일에서는 가독성을 위해 반응형 카드/테이블 형식을 사용한다.

ERP 웹에서는 A4 문서형 레이아웃으로 표시한다.

동일한 데이터를 사용하되 모바일과 웹의 표현 방식만 다르게 한다.

==================================================

26. 연차신청 상세 양식

==================================================

연차신청은 별도의 문서 양식을 사용한다.

상단:

연차 사용 신청서

기본정보:

- 문서번호

- 부서명

- 신청자

- 작성일

결재영역:

- 결재자

- 결재상태

- 결재일시

신청내용:

- 연차구분

- 사용 시작일

- 사용 종료일

- 사용일수

- 사용사유

- 업무인계자

첨부파일

==================================================

27. 데이터베이스 설계

==================================================

기존 DB 구조를 먼저 확인한 후 실제 테이블명과 컬럼 규칙을 현재 프로젝트에 맞춘다.

권장 테이블:

1. approval_documents

전자결재 문서 기본정보

필드 예:

id

document_no

document_type

writer_user_id

writer_name_snapshot

department_id

department_name_snapshot

title

content

request_date

status

current_approval_order

sent_at

completed_at

rejected_at

created_at

updated_at

document_type:

EXPENSE

LEAVE

2. approval_lines

결재라인

필드:

id

document_id

approval_order

approver_user_id

approver_name_snapshot

approver_position_snapshot

status

approved_at

rejected_at

rejection_reason

created_at

updated_at

결재라인 상태:

WAITING

PENDING

APPROVED

REJECTED

3. approval_expense_items

지출항목

필드:

id

document_id

item_order

item_name

vendor_name

quantity

unit_price

supply_amount

vat_amount

total_amount

evidence_type

created_at

updated_at

4. approval_leave_details

연차신청 상세

필드:

id

document_id

leave_type

start_datetime

end_datetime

leave_days

leave_hours

reason

handover_user_id

created_at

updated_at

5. approval_files

첨부파일

필드:

id

document_id

expense_item_id

file_category

original_name

stored_name

file_path

mime_type

file_size

uploaded_by

created_at

6. approval_history

모든 처리 이력

필드:

id

document_id

user_id

action

from_status

to_status

comment

created_at

action 예:

CREATE

UPDATE

READY

SEND

APPROVE

REJECT

WITHDRAW

DELETE

==================================================

28. 스냅샷 데이터 저장

==================================================

결재문서는 과거 기록 보존이 중요하다.

따라서 user_id만 저장하지 말고 작성 당시 정보를 함께 저장한다.

예:

writer_user_id

writer_name_snapshot

department_id

department_name_snapshot

approver_user_id

approver_name_snapshot

approver_position_snapshot

나중에 사용자의 부서나 직급이 변경되어도 과거 결재문서 내용은 변경되면 안 된다.

==================================================

29. API 구조

==================================================

현재 프로젝트의 API 규칙을 우선 사용한다.

권장 API:

문서 작성:

POST /api/approvals

문서 수정:

PUT /api/approvals/{id}

문서 삭제:

DELETE /api/approvals/{id}

작성완료:

POST /api/approvals/{id}/ready

문서 전송:

POST /api/approvals/{id}/send

내 작성리스트:

GET /api/approvals/drafts

송신함:

GET /api/approvals/sent

수신함 대기:

GET /api/approvals/received/pending

수신함 완료:

GET /api/approvals/received/completed

문서 상세:

GET /api/approvals/{id}

결재:

POST /api/approvals/{id}/approve

반려:

POST /api/approvals/{id}/reject

첨부파일 업로드:

POST /api/approvals/{id}/files

첨부파일 삭제:

DELETE /api/approvals/{id}/files/{fileId}

==================================================

30. 동시결재 방지

==================================================

결재 API는 반드시 DB 트랜잭션을 사용한다.

동일한 결재 요청이 두 번 전달되어도 중복결재가 발생하지 않아야 한다.

예:

사용자가 결재 버튼을 빠르게 두 번 클릭

모바일 통신 오류로 API 재전송

이 경우에도 결재 이력은 한 번만 생성되어야 한다.

서버에서 현재 상태와 현재 결재자를 다시 확인한 후 처리한다.

==================================================

31. 모바일 앱과 ERP 웹 동기화

==================================================

모바일 앱과 ERP 웹은 반드시 같은 API를 사용한다.

금지사항:

- 모바일 전용 DB 생성

- ERP 웹 전용 결재 상태 관리

- 서로 다른 결재 로직 사용

업무규칙은 서버에서 통합 관리한다.

모바일 앱:

API 호출

→ 데이터 표시

ERP 웹:

동일 API 호출

→ 데이터 표시

결재 처리:

서버 공통 서비스 실행

==================================================

32. 알림

==================================================

기존 푸시 알림 시스템이 존재하면 연동한다.

다음 상황에서 알림을 발송한다.

1. 새로운 결재 요청 도착

2. 다음 결재순서 도착

3. 최종결재 완료

4. 품의 반려

예:

"[전자결재] 새로운 지출품의 결재 요청이 도착했습니다."

"[전자결재] Apple Developer Program 결제가 최종 승인되었습니다."

"[전자결재] 연차신청이 반려되었습니다."

==================================================

33. 권한 검증

==================================================

서버에서 반드시 다음을 검증한다.

작성자만:

- 전송 전 문서 수정

- 전송 전 문서 삭제

현재 결재자만:

- 결재

- 반려

문서 관련자만:

- 문서 상세조회

- 첨부파일 조회

URL 또는 document_id를 변경하여 다른 사람의 문서를 임의 조회할 수 없어야 한다.

==================================================

34. 파일 보안

==================================================

전자결재 첨부파일은 공개 URL에 그대로 노출하지 않는다.

다운로드 또는 조회 시:

1. 로그인 확인

2. 문서 접근권한 확인

3. 파일 전달

방식으로 처리한다.

==================================================

35. UI 공통사항

==================================================

모바일 앱에서는 카드 UI를 사용한다.

카드에 너무 많은 정보를 표시하지 않는다.

카드:

핵심정보

상세 레이어:

전체정보

방식을 사용한다.

모든 리스트에 다음 상태 표시를 일관되게 사용한다.

- 작성중

- 전송대기

- 결재진행중

- 결재완료

- 반려

로딩 중에는 중복 버튼 클릭을 방지한다.

API 처리 중:

- 버튼 disabled

- 로딩 표시

처리 완료 후 리스트를 새로고침한다.

==================================================

36. 검색 및 필터 확장 고려

==================================================

초기 개발부터 향후 다음 조건 검색이 가능하도록 API를 설계한다.

- 문서종류

- 문서번호

- 제목

- 작성자

- 부서

- 상태

- 작성기간

- 결재기간

초기 화면에서 모두 구현하지 않더라도 API 구조는 확장 가능하게 한다.

==================================================

37. 개발 순서

==================================================

다음 순서대로 개발한다.

1단계

현재 프로젝트 분석

결과 보고:

- 모바일 구조

- ERP 웹 구조

- 회원 DB

- 로그인 구조

- API 구조

- 파일 업로드 구조

2단계

DB 설계

작성할 것:

- 테이블

- 컬럼

- 인덱스

- 외래키

- 상태값

3단계

전자결재 서버 서비스 개발

- 문서 작성

- 문서 수정

- 결재라인 저장

- 지출항목 저장

- 연차정보 저장

- 문서번호 생성

4단계

작성/작성완료/전송 기능

5단계

순차결재 기능

6단계

반려 기능

7단계

작성리스트

8단계

송신함

9단계

수신함

10단계

모바일 상세 UI

11단계

ERP 웹 문서형 UI

12단계

첨부파일

13단계

푸시알림

14단계

보안 및 권한 검증

15단계

통합 테스트

==================================================

38. 테스트 시나리오

==================================================

반드시 다음을 테스트한다.

시나리오 1

지출품의 작성

→ 항목 3개 추가

→ 저장

→ 작성리스트 확인

시나리오 2

작성문서 전송

→ 첫 번째 결재자 수신함 확인

시나리오 3

1차 결재

→ 두 번째 결재자에게 이동

시나리오 4

최종결재

→ 문서 상태 APPROVED

→ 신청자 송신함 완료 탭 표시

시나리오 5

중간 결재자 반려

→ 전체 문서 REJECTED

→ 신청자 반려 탭 표시

시나리오 6

전송 후 수정 시도

→ 서버에서 차단

시나리오 7

현재 결재자가 아닌 사용자가 결재 API 호출

→ 서버에서 차단

시나리오 8

결재 버튼 중복 클릭

→ 결재 1회만 처리

시나리오 9

모바일에서 결재

→ ERP 웹에서 즉시 상태 확인

시나리오 10

ERP 웹에서 결재

→ 모바일 앱에서 즉시 상태 확인

==================================================

39. 중요 개발 원칙

==================================================

1. 기존 프로젝트 구조를 먼저 분석하고 기존 방식에 맞춰 구현한다.

2. 새로운 인증 시스템을 만들지 않는다.

3. 기존 회원 테이블을 사용한다.

4. 모바일과 ERP 웹은 같은 API와 DB를 사용한다.

5. 결재 권한은 프론트엔드가 아니라 서버에서 검증한다.

6. 금액 계산도 서버에서 다시 검증한다.

7. 결재 처리는 DB 트랜잭션을 사용한다.

8. 과거 문서 보존을 위해 작성자/부서/결재자 정보는 스냅샷으로 저장한다.

9. 전송 후 문서는 수정할 수 없다.

10. 결재이력을 반드시 기록한다.

11. 기존 기능을 임의로 변경하거나 삭제하지 않는다.

12. 각 개발 단계 완료 후 변경된 파일과 구현내용을 보고한다.

==================================================

40. Codex 작업 방식

==================================================

한 번에 전체 기능을 구현하지 않는다.

먼저 현재 프로젝트를 분석하고 다음 내용을 보고한다.

1. 관련 기존 파일 목록

2. 데이터베이스 구조

3. 인증 구조

4. 회원/부서 구조

5. API 구조

6. 모바일 화면 구조

7. ERP 웹 화면 구조

8. 파일 업로드 구조

9. 예상 변경파일

10. 신규 생성파일

11. DB 변경사항

12. 구현 순서

분석 결과를 먼저 보고한 후 실제 개발을 단계별로 진행한다.