3-01 · 담당자 검토 이력과 권한 저장하기
1. 실습 목표
두 번째 과정 원본 검토 자료를 바꾸지 않고 최종 검토 결과를 별도 SQLite 이력에 새 행으로만 저장합니다. 권한·입력·지정 표본을 저장 전에 확인합니다.
2. 시작 지점
- 시작 체크포인트:
student/11-day2-complete working-paper.json: 지정 표본 12건, 모두 담당자 확인 필요- 이번 실습에서 생성할 항목:
review_events이력과 마지막 과정 SQLite
브라우저에서 첫 과정 집계와 working-paper 12건을 기준 결과로 확인합니다. 이번 단계에서는 저장 API를 직접 호출해 권한·입력·이력 보존 계약을 확인합니다.
3. 구현 범위 및 요구사항
초안과 최종 검토 결과 분리
- Agent 원본은
working-paper.json읽기 전용입니다. - 최종 검토 결과는
normal,follow_up,control_exception만 허용합니다. - 이력은
change_id,agent_run_id, 검토 자료generated_at에 연결합니다. - 새 검토 자료 생성 시각에는 과거 결론을 자동 연결하지 않습니다.
이전 기록을 보존하는 SQLite
backend/data/day3_reviews.sqlite3의review_events에 요청 ID, 결론, 메모, 검토자, 원본 검토 자료와 생성 시각을 저장합니다.- 수정도 새 행이며 기존 행을 UPDATE·DELETE하지 않습니다.
- 현재 결론은 현재 검토 자료에 연결된 가장 최근 이력에서 계산합니다.
서버 권한·입력 검증
- U701의
CONTROL_REVIEW만 허용하고 U601은403으로 거부합니다. - 현재 지정 표본 12건, 세 결론과 1–1000자 메모를 Pydantic과 서버에서 검사합니다.
- 실패 요청은 이력을 추가하지 않습니다.
요청 식별자 기록
- 요청마다 UUID
review_action_id를 받아 이력에 저장합니다. - 새 ID의 수정은 새 이력으로 남깁니다.
- 같은 요청 ID의 재전송과 충돌 방지는 다음 화면 연결 단계에서 추가합니다.
4. 실습 프롬프트
Agent 초안은 보존하고 담당자의 최종 검토 결과를 별도 이력으로 저장해 주세요.
현재 검토 자료 화면에는 Agent 초안과 근거가 표시되지만 담당자의 최종 검토 결과를 저장할 수 없습니다. 기존 SQLite, Pydantic과 사용자 권한 확인 방식을 살펴보고 담당자 검토를 별도 이력으로 저장해 주세요.
구현이 끝나면 권한이 있는 담당자는 검토 대상에 결론과 메모를 남길 수 있어야 하며, 이후 수정도 이전 기록을 보존한 새 이벤트로 저장되어야 합니다.
- 요청 ID, 검토 자료 ID와 생성 시각, 변경 ID, 검토자, 결론, 메모와 저장 시각 기록
- 기존 검토 이력과 분리된 `review_events` 테이블 구성
- 최초 검토와 수정의 기존 행 변경 없는 추가형 저장
- 저장 전 활성 검토 권한, 검토 대상 포함 여부, 허용 결론과 메모 길이 검사
- 잘못된 사용자, 권한 없음, 잘못된 입력과 없는 사례에 대한 오류 구분
- Agent 초안, 원본 검토 자료와 기존 화면 유지
- 입력 화면, 완료 집계, CSV 내보내기와 중복 요청 방지 기능 추가 금지
허용되는 요청과 거부되는 요청을 한 번씩 확인하고 기존 검사 명령을 실행해 주세요. 구현 후에는 변경 파일과 테이블, 실제 API 응답과 저장 결과, 원본 유지 여부와 남은 위험만 간단히 알려 주세요.5. 예상 결과
Success
- 종료 체크포인트:
student/12-review-storage-ready- 첫 결론 뒤 수정: 이력 2건, 현재 결론 1건
- U601·잘못된 입력: 저장 없음
- 원본 검토 자료와 기존 이력 유지, 실행 중 생성되는 DB 미추적
- 저장 API 직접 호출로 U701 성공·U601 거부·이력 보존 확인
- 검토 화면·완료 집계·CSV와 중복 요청 방지는 아직 연결 전
6. 대표 실패 사례 및 복구
Failure
change_id를 UNIQUE로 두거나 현재 결론을 UPDATE함- 권한 실패 뒤 이력을 저장함
- 검토 자료 시각 없이 과거 결론을 연결함
Info
개발용 마지막 과정 DB만 프로세스 종료 후 제거하고 새 DB에서 저장·거부·수정 순서를 다시 실행합니다. 같은 오류가 두 번 나거나 10분 지연되면
student/12-review-storage-ready로 이동합니다.
직접 확인할 결과
- working-paper 화면에서 표본 12건과 Agent 초안을 기준 결과로 확인합니다.
- 저장 API를 직접 호출해 U701 성공, U601 거부와 새 요청 ID 수정 결과를 확인합니다.
- API 호출 전후의 첫 과정 집계와 working-paper 12건이 동일한지 확인합니다.
7. 다음 실습
저장 API를 검토 화면·완료 상태에 연결합니다.