2-08 · 담당자의 최종 검토 절차 설계하기
1. 실습 목표
두 번째 과정 원본 검토 자료와 마지막 과정 최종 검토 결과의 저장 위치, 작성자, 연결 키, 변경 규칙과 실패 처리를 설계합니다. Agent 초안과 담당자 결론을 같은 필드에 덮어쓰지 않습니다.
2. 시작 지점
working-paper.json 12건은 모두 담당자 확인이 필요하고 최종 검토 결과는 0건입니다.
브라우저에서는 student/11-day2-complete의 working-paper 화면과 첫 과정 화면이 함께 보입니다. 이 실습은 저장 API나 최종 결론을 추가하지 않고, 다음 과정에서 활성화할 담당자 검토 영역의 책임 경계를 설계합니다.
3. 구현 범위 및 요구사항
| 항목 | Agent 초안 | 최종 검토 결과 |
|---|---|---|
| 저장 | working-paper.json 읽기 전용 | 이전 기록을 보존하는 별도 SQLite 이력 |
| 작성자 | Agent 실행 | CONTROL_REVIEW 사용자 |
| 값 | 근거 기반 설명·추가 확인 | normal, follow_up, control_exception |
| 변경 | 원본 수정 안 함 | 수정도 새 이력 추가 |
| 연결 | agent_run_id, generated_at, change_id | 같은 검토 자료 시각과 사례 |
- 새 검토 자료 시각에는 과거 결론을 자동 연결하지 않습니다.
- 화면 제어가 아니라 서버에서 권한·입력·지정 표본을 검증합니다.
- 네트워크에서 같은 요청이 다시 전송되어도
review_action_id로 중복 저장을 막습니다. - 파일 오류·권한 거부·빈 메모·충돌 요청은 저장 전에 중단합니다.
4. 실습 프롬프트
Agent 초안과 담당자의 최종 검토 결과를 분리하는 저장 계약을 설계해 주세요. 코드는 수정하지 마세요.
현재 `working-paper.json`과 검토 자료 API에는 Agent 초안만 있고 담당자의 결론을 저장하는 계약은 없습니다. `user_roles.csv`, 검토 자료 구조와 기존 API 방식을 확인하고 두 결과의 책임을 분리해 주세요.
설계가 끝나면 Agent 초안을 변경하지 않으면서 담당자의 최초 검토와 수정 이력을 모두 남길 수 있어야 합니다. 다음 구현에서 바로 사용할 수 있도록 저장과 오류 계약을 구체적으로 작성해 주세요.
- Agent 초안과 담당자 검토 결과의 소유자·저장 위치·허용 값 비교
- 검토 자료와 담당자 결과를 연결할 키와 자료 생성 시각 정의
- 담당자 수정의 기존 행 변경이 아닌 새 이벤트 기록
- 동일 요청 ID 재전송과 다른 내용 재전송의 충돌 처리 정의
- 사용자 권한, 결론 값과 메모 길이에 대한 검증 기준 작성
- 과거 결론의 자동 연결과 화면에만 의존하는 권한·완료 검증 금지
답변은 비교표, 저장·수정·재전송 계약, 대표 실패 사례와 미결정 사항만 간단히 제공해 주세요.5. 예상 결과
Success
- 초안과 최종 검토 결과의 저장·책임·변경 경계가 분리됨
- U701 허용, U601 거부를 서버에서 검사하도록 설계함
- 수정은 새 이력, 같은 요청은 중복 없음
- 새 검토 자료 시각은 검토 0건에서 시작
- working-paper 12건을 기준으로 담당자 입력·완료 집계·CSV 계약이 정의됨
6. 대표 실패 사례 및 복구
Failure
- 검토 자료 JSON에 최종 검토 결과 필드를 추가함
- 첫 과정 상태를 최종 검토 결과로 복사함
- 기존 이력을 UPDATE·DELETE하도록 설계함
Info
시간이 부족하면 표의 다섯 행과 권한·중복 저장 방지·새 검토 자료 중단 조건만 확정합니다. 구현은 마지막 과정에서 진행합니다.
7. 다음 실습
첫 과정 Action Plan을 바탕으로 나만의 Agent 적용 계획을 완성합니다.