Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
본 글은 승인 플로우 설계 시 UI와 API가 각각 어떤 책임을 가져야 하는지 설명합니다. 단순히 버튼 비활성화만으로는 보안이 불충분하며, 서버는 요청의 권한, 승인 상태, 버전 일치 여부 등 다층적인 검증을 수행해야 함을 강조합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기승인 플로우를 설계할 때, '미승인이라면 버튼을 누를 수 없다'는 것만으로는 등록을 허용해도 좋다는 근거가 결정되지 않습니다. UI는 조작의 이유를 전달하고, API는 저장된 근거로부터 실행 가능 여부를 판단합니다. 그 위에, 판단한 내용과 저장할 내용을 일치시켜야 합니다.
이 글은 총 12회에 걸친 설계 교재 중 제2회를 정리한, AI 지원을 통한 개인의 설계 연습입니다. 다루는 의뢰 및 인물은 가상의 것입니다. 2026년 10월 13일에 기존 학습용 API를 코드 읽기를 통해 확인했지만, 이번 승인/인증/권한/AI 기능은 미구현/미검증입니다. 아래의 그림과 ADR도 설계안으로 읽어 주십시오.
가상의 의뢰 REQ-001
은 '사내 매뉴얼의 문의처를 업데이트하는 것'입니다. 작업 담당자는 사토, 등록 조작을 하는 사람은 다나카입니다. 희망 기한은 2026년 10월 16일이며, 완료 조건은 '새로운 문의처로 수정되었고 총무가 내용을 확인했음'입니다.
이 의뢰에 대해 화면에서 다음 값이 전송되었다고 생각합니다.
{"request_id": "REQ-001", "approved": true, "approver": "상장"}
하지만 서버가 관리하는 기록에서는 미승인입니다. 이 경우, 화면의 값을 근거로 등록하면 이용자가 전송 내용을 수정하기만 해도 승인을 통과할 수 있습니다.
그래서, 승인 상태, 승인자의 사용자 ID, 승인 일시, 승인한 의뢰의 버전, 변경 이력을 서버 측에 보관하는 방안으로 합니다. 승인 기록 자체도 권한을 확인한 승인 조작만이 업데이트할 수 있어야 합니다. '서버에 저장되어 있다'는 것만으로는 신뢰할 수 있는 기록이 되지 않습니다.
버전을 가지는 이유도 구체적입니다. 문의처 A로의 변경을 버전 2에서 승인한 후, 의뢰가 문의처 B로 바뀌어 버전 3이 되었다면, 버전 2의 승인을 버전 3에 흘려 쓰지 않습니다. 과거에 승인된 이력은 남기면서, 현재 내용은 재승인을 요구하는 규칙입니다.
UI에서는 미승인의 등록 버튼을 비활성화하고, '승인 후에 등록할 수 있습니다'라고 표시합니다. 이는 오조작을 줄이기 위해 필요합니다. 다만, API로 직접 요청이 전송되는 경로도 고려하면, 표시만으로는 최종 판정에 할 수 없습니다. OWASP의 권한(Authorization) 가이드도 각 요청에서의 권한 확인과 서버 측에서의 판정을 권장하고 있습니다.
이 연습에서는 등록 요청을 받은 서버가 다음을 확인할 방안으로 했습니다.
사용자 ID는 인물을 구별하는 수단이며, 권한의 증명과는 별개입니다. 또한, 자기 승인을 금지할지, 승인 후에 승인자의 권한이 변경된 경우 어떻게 할지는 업무 규정으로 결정해야 합니다.
거부할 때는 작업 태스크를 늘리지 않고, 이유를 반환합니다. 거부 로그의 추가와 업무 데이터를 변경하지 않는 것은 양립 가능합니다. 로그에는 처리 단계나 허가된 식별자를 남기고, 의뢰 전문을 무조건 기록하는 설계는 하지 않습니다.
책임을 분리할 목적은 함수나 파일을 늘리는 것이 아니라, 무엇을 확인해야 무엇이 바뀌는지 추적할 수 있도록 하는 것입니다.
그림은 미래의 구성안입니다. 입력 검증은 타입이나 필수 항목을 확인하고, 업무 판단은 그 사람이 그 의뢰를 실행해도 좋은지 확인합니다. 변환은 의뢰 내용을 태스크 항목에 대응시키고, 저장은 신규 태스크를 만듭니다. 입력의 형태가 올바른 것과, 실행이 허용되는 것을 섞지 않습니다.
내부 저장 처리로부터 승인 판단을 분리한다면, 외부에서 등록할 수 있는 모든 입구를 같은 확인 경로로 통하게 합니다. 승인이 붙은 새로운 API를 만들어도, 오래된 등록 API에 직접 보내면 확인 과정을 우회할 수 있는 구성으로는 목적을 달성할 수 없습니다. 같은 판정을 각 함수에 복제하는 것이 아니라, 입구부터 저장까지의 경로를 확인합니다.
다만, 확인을 등록 직전으로 두는 것만으로는 충분하지 않습니다. 버전 2를 대조한 직후 다른 조작으로 버전 3이 되는 경우나, 같은 등록 요청이 두 번 도착하는 경우가 남아 있습니다. 버전 확인과 쓰기의 일관성, 중복 등록 처리는 다음 설계 과제입니다. 위의 그림을 그렸다고 해서 방지된 것은 아니라고 취급합니다.
코드 읽기를 통해 확인한 현재의 학습용 API는 태스크를 메모리상의 딕셔너리에 임시 저장합니다. 등록 시에는 입력 검증과 ID 중복 판정이 있고, 업데이트 처리는 대상의 존재를 확인하고 status만 변경합니다. 재시작 후 남는 DB 저장이나, 승인 확인은 없습니다.
Current Task
은 다음 6개 항목입니다. REQ-001을 대응시키면, 등록 예시는 다음과 같습니다.
⚠️ [IMG:N] 형식 토큰은 이미지 placeholder 입니다. 번역하지 말고 원래 위치에 그대로 유지하세요.
| Task 항목 | 가상 등록 예시 | 의미 |
|---|---|---|
id | TASK-001 | 작업 태스크의 ID. 원 요청 ID와는 별개 |
department | 총무 | 작업 부서 |
title | 사내 매뉴얼 문의처 업데이트 | 작업명 |
owner | 사토 | 작업 담당자. 등록 조작자인 다나카가 아님 |
status | 미착수 | 작업 진행 정도 |
done_when | 새로운 문의처로 수정되어, 총무가 내용을 확인 완료함 | 완료를 판정하는 조건. 기한이 아니다 |
TASK-001
과 초기 상태는 연습용 지정값입니다. 현재 등록 처리는 전송된 ID를 사용하며, 서버에 의한 ID 발급은 별도로 검토할 안건입니다.
원 요청 ID, 등록 조작자 ID, 희망 기한, 승인 정보는 현재 6개 항목에는 없습니다. 우선 기한은 요청 기록에서 보관하는 방안으로 하고, 태스크와의 관련성이나 조작 기록의 저장 형식을 별도로 정의합니다. 기한을 문장에 포함하면, 기한 순 정렬이나 기한 만료 판정에 추가적인 추출 규칙이 필요하기 때문입니다.
또한, 요청에서 작업 태스크를 신규 생성하는 처리와, 작업 중인 태스크를 '확인 대기'로 갱신하는 처리는 별개입니다. status가 '확인 대기', '완료'이기 때문에, 누가 요청의 어느 버전을 승인했는지 알 수 없습니다.
다음은 초안 접수 방식을 선택합니다. 가상의 제약 조건은 '초안까지의 기간이 당초 예정의 절반이 되었다'입니다. 구체적인 일수나 공수는 미산정입니다.
| 비교 | A 안: 필수 폼 | B 안: 자유문 AI 정리 |
|---|---|---|
| 입력 | 이용자가 항목을 채움 | AI가 항목안・부족 정보를 정리 |
| ... |
이 실습의 ADR-001에서는, A 안을 잠정적으로 채택합니다. 초안 단계에서는 부품과 확인 범위를 좁히고, AI 출력 평가나 오류 수정은 미루기 때문입니다. 한편, 이용자의 입력 부담이나, 항목에 담기지 않는 사정 전달의 어려움은 수용할 결점으로 남깁니다. A 안의 실현 기간이나 효과를 보장한 판단은 아닙니다.
ADR에는 '상태・배경・결정・영향'을 작성합니다. Michael Nygard의 원저도, 결정의 이유와 부정적 영향을 포함하는 기록을 제안하고 있습니다. 이번에는 영향 외에, 재검토할 조건으로 입력 시간, 도중 이탈률, 반송 건수 및 사유, 총무의 확인・수정 시간을 측정하는 안을 남겼습니다. 비율의 분모, 기간, 기준값, 판단자는 평가 전에 정합니다.
더 나아가, 가상의 추가 조건을 설정합니다. '입력 측은 개선되었으나, 총무가 보충란을 읽고 요점을 정리하는 시간은 변하지 않았다'. 이는 실측 결과가 아닙니다.
이 조건이라면, 접수 전체를 B 안으로 전환하기 전에 남은 부담을 조사합니다. 빈번하게 발생하는 사정을 폼의 선택 항목에 추가할 방안과, 보충란을 AI가 요약하고 총무가 확인하는 방안을 작게 비교합니다. 양쪽 안에서 동일한 요청・확인 담당 등의 조건을 맞추고, 확인과 수정의 합계 시간, 중요 정보 누락・오류, 입력자 부담, 비용을 봅니다. 항목 추가가 입력 부담을 늘릴 가능성도, AI 요약 수정하는 수고를 포함하여 판단합니다.
채택・추가 검증・보류의 기준을 먼저 정하고, AI를 더해도 검증・사람의 승인은 유지합니다. 설계 이유가 기록되어 있다면, 조건 변경 시 'AI를 사용하고 싶다'가 아니라, 어떤 부담이 남아 있고 무엇을 비교해야 하는지로 돌아갈 수 있습니다.
다음은, 동시 변경과 이중 등록, 실패 시 무엇이 남는지, 결과 불명 시 어떻게 대조할지를 API와 저장 설계에 녹여냅니다.
공개 자료 확인일: 2026년 10월 13일.