AI Native 서비스 종합 프로젝트

사내 지식지원 서비스의 목표를 “정확한 답변”이라고만 쓰면 팀마다 완료 기준이 달라집니다. 대표 질문 set의 task success, 근거 span의 support, 권한 없는 source 노출 0건, P95 latency와 성공당 비용처럼 관찰 가능한 조건으로 바꿔야 합니다. 일부는 개선 방향을 보는 metric이고 개인정보 노출처럼 반드시 0이어야 하는 항목은 hard gate입니다.

Out of scope와 실패 시 기본 행동도 제품 계약에 포함됩니다. 근거를 찾지 못하면 추측 대신 모른다고 답하고 사람에게 넘길지, 최신성 기준을 넘은 문서를 사용할지 결정해야 합니다. Data owner, model과 prompt 변경 owner, incident 연락처를 명시하면 기술 선택이 사용자 결과와 운영 책임으로 연결됩니다.

Architecture diagram에는 React, PostgreSQL 같은 제품 상자만 그리지 않고 사용자 identity와 document가 어느 trust boundary를 넘는지 표시합니다. Browser에서 API로 가는 token, ingest가 object storage에서 읽는 원문, agent host가 MCP server에 보내는 tool input과 결과가 각각 다른 공격면입니다. Secret은 model context가 아니라 host나 server의 credential 경계에 남겨야 합니다.

Threat model은 악성 문서가 prompt injection으로 tool을 유도하는 경우, 다른 tenant의 vector가 검색되는 경우, 승인 화면과 실제 parameter가 달라지는 경우를 data flow에 대입합니다. 최소 권한과 input validation은 예방, trace와 audit는 탐지, tool disable과 credential revoke는 복구 control입니다. 각 control을 실제 abuse test와 owner에 연결해야 그림이 운영 문서가 됩니다.

원문을 ingest할 때 source ID, revision, owner, ACL, parser와 content hash를 먼저 저장하고 chunk와 embedding은 그 원문에서 파생된 artifact로 연결합니다. 파일 이름만 같다고 같은 문서로 취급하면 수정과 삭제가 어느 vector에 반영됐는지 알 수 없습니다. Reconciliation job은 원문과 index revision의 차이를 찾아 허용 freshness 안에 수렴시키는 책임을 가집니다.

Query 경로에서는 사용자 권한으로 허용된 candidate만 만들고 rerank와 context packing 단계마다 source identity를 유지합니다. Answer citation은 실제 사용한 span과 revision을 가리켜야 합니다. 권한 변경과 삭제를 주입한 뒤 cache, vector candidate와 최종 답에서 정해진 시간 안에 사라지는지 확인해야 data contract가 검색 품질과 보안을 함께 지켰다고 말할 수 있습니다.

검색 tool과 ticket 생성 tool을 분리하면 읽기와 상태 변경에 다른 policy를 적용할 수 있습니다. 생성 tool은 input schema 외에도 domain validation, 권한, idempotency key와 preview를 제공해야 합니다. Host가 보여 준 대상과 server가 실제 실행한 대상이 같은지 audit identity로 연결해야 승인 UI가 장식이 되지 않습니다.

Agent loop에는 최대 step과 token뿐 아니라 같은 operation 반복 탐지, tool error별 recovery와 사람 handoff가 필요합니다. 여러 agent가 조사 결과를 병렬로 만들 수는 있지만 동일 ticket이나 database row를 바꾸는 작업은 한 owner와 transaction으로 직렬화해야 합니다. Prompt 지침은 행동 선택을 돕지만 server authorization과 concurrency control을 대신하지 못합니다.

Release evidence pack은 source commit, dependency lock, test와 eval 결과, image digest, migration revision과 configuration schema를 하나의 release identity로 묶습니다. Canary에서는 HTTP 200뿐 아니라 citation support, 권한 위반, tool success와 성공당 비용을 확인합니다. Hard gate가 실패하면 traffic을 늘리지 않고 원인을 고친 뒤 같은 frozen case를 다시 실행합니다.

운영 인계는 만든 사람이 옆에서 설명하지 않아도 새 담당자가 dashboard에서 run을 찾고 tool을 차단하며 rollback과 restore를 수행할 수 있는지를 시험합니다. Runbook에는 owner, alert 의미, 안전한 첫 진단, credential revoke, data 복구와 알려진 risk를 적습니다. 장애 주입 뒤 사용자 결과와 안전 조건이 모두 회복됐다는 evidence가 있어야 project를 완료로 판정할 수 있습니다.

교육용 휴가 안내 서비스에서 담당자가 공지 초안 revision 7을 승인했다고 가정합니다. 발송 전에 다른 담당자가 날짜를 바꾸어 revision 8이 됐습니다. 시스템은 승인된 7과 현재 8의 불일치를 감지하고 발송을 보류해야 합니다. 날짜만 바뀌었다는 이유로 사소한 변경으로 넘기면 사용자가 승인하지 않은 일정이 전달됩니다.

승인 화면에는 달라진 날짜와 수신 범위를 다시 표시합니다. 재승인은 새 내용에 대한 결정으로 기록하고 이전 승인과 연결하되 덮어쓰지 않습니다. 나중에 잘못된 공지가 발송되면 어떤 내용에 대한 승인이었는지 재구성할 수 있어야 합니다. 승인자의 신원과 결정 시각을 연결하면 내용 변경 뒤 과거 승인이 잘못 재사용됐는지 확인할 수 있습니다.

반례는 승인 여부를 참·거짓 값 하나로 저장하는 설계입니다. 내용이 바뀌어도 참이 남으면 다른 요청이 과거 승인을 재사용할 수 있습니다. 대상과 revision이 없는 승인은 어떤 변경에 대한 결정인지 입증하지 못합니다. 값 하나 대신 승인된 내용의 식별과 적용 범위를 함께 저장하는 것이 이 실패를 막는 핵심입니다.

검증에서는 승인 뒤 내용 변경, 수신자 변경과 권한 철회를 각각 주입합니다. 모든 불일치가 외부 발송 전에 차단되는지 확인합니다. 변화가 없는 정상 승인도 실행되어야 하므로 보류만 되는 시스템을 완성으로 판단하지 않습니다. 외부 발송 건수를 결과에 포함해야 화면만 보류하고 뒤에서 발송하는 잘못된 구현도 거부할 수 있습니다.

교육용 수강 신청 서비스는 신청 행을 저장한 뒤 안내 메시지를 보냅니다. 외부 메시지 서비스가 접수했지만 응답이 끊겼다고 가정합니다. 신청을 취소하고 처음부터 다시 만들면 신청 중복이나 이미 도착한 안내와의 불일치가 생길 수 있습니다. 이미 생성된 신청의 식별자를 보존해야 후속 조회가 새 신청이 아니라 원래 사건을 추적합니다.

신청 식별자에 연결된 알림 상태를 미확인으로 남기고 외부 접수 식별자로 조회합니다. 접수가 확인되면 새 메시지 없이 완료 기록을 보완합니다. 조회할 근거가 없으면 재발송 위험을 담당자에게 보여 주고 일괄 재시도를 멈춥니다. 미확인 상태의 시작 시각과 다음 확인 담당자를 남겨 무기한 방치되는 부분 성공도 줄입니다.

반례는 HTTP 오류를 받았으므로 외부 작업도 없었다고 단정하는 코드입니다. 연결 오류는 결과를 전달받지 못했다는 뜻일 수 있습니다. 네트워크 결과와 업무 결과를 나누어 저장해야 이런 불확실성을 숨기지 않습니다. 같은 오류 코드라도 외부 접수 전과 접수 후의 복구 선택이 다르므로 장애 주입 시점을 남깁니다.

검증에서는 저장 전, 저장 후, 외부 접수 후라는 세 지점에서 장애를 주입합니다. 저장 전 장애에는 신청과 발송 예정 기록이 모두 없어야 합니다. 저장 후에는 유효한 신청 한 건과 발송 예정 기록을 보존하고, 외부 접수 후에는 알림을 확정 또는 명시적 미확인 상태로 남깁니다. 두 시스템의 합계를 대조해 누락된 예정 기록과 중복 결과를 찾습니다. 재처리 뒤 원래 작업 식별자가 유지되는지 확인하면 복구 과정에서 새 업무가 만들어지는 결함을 찾습니다.

교육용 문서 지원 서비스에서 새 담당자에게 일부 문서가 검색되지 않는 사건을 줍니다. 원인은 색인 세대 전환 중 이전 경로가 남은 것으로 설정합니다. 자료에는 정상 세대, 현재 세대와 실패 질문을 남기되 원인 답안을 먼저 알려 주지는 않습니다. 사건 조건을 고정해야 문서를 고친 뒤 다른 담당자의 결과가 실제로 나아졌는지 비교할 수 있습니다.

담당자는 요청 기록과 검색 대상을 대조해 잘못된 경로를 찾고 제한된 환경에서 이전 검증 경로로 복구합니다. 같은 질문의 근거 문서와 권한 거절 사례를 함께 확인합니다. 답이 돌아왔다는 사실만으로 권한 조건도 지켜졌다고 가정하지 않습니다. 복구 과정에서 현재 데이터가 사라지지 않았는지도 확인해 빠른 정상 응답만으로 성공을 판단하지 않습니다.

반례는 개발자가 기억하는 파일 위치를 말해 주어야만 진행되는 인수입니다. 그 위치와 선택 이유를 문서에 보완하고 다른 담당자가 처음부터 다시 수행합니다. 문서 수정 후 같은 사람이 기억으로 성공한 결과만으로 재현성을 판단하지 않습니다. 막힌 지점마다 누락된 관찰인지 잘못된 절차인지 구분하면 문서 분량보다 실제 사용성이 개선됩니다.

최종 제출물에는 원인 가설, 제외한 가설, 복구 전후 증거와 남은 한계를 포함합니다. 인수자는 각 조치가 어느 실패를 해결했는지 설명해야 합니다. 이 연결이 불명확하면 자료를 늘리기보다 필요한 관찰과 절차를 정확히 보완합니다. 남은 한계의 담당자와 재확인 조건을 적어 인수 뒤에도 미검증 부분이 완료로 오해되지 않게 합니다.