Prompt와 Agent 업무

“전문가처럼 잘 요약해 줘”는 읽기에는 자연스럽지만 검토자마다 성공의 뜻이 다릅니다. 누구를 위한 결과인지, 어떤 결정을 지원하는지, 반드시 보존할 숫자·조건과 제외할 추측이 무엇인지부터 씁니다. 고객 문의 분류라면 허용 label과 겹칠 때의 우선순위, 문서 요약이라면 문단 근거와 날짜·금액 보존을 명시합니다. 이 정보가 있어야 model 후보와 사람 정답을 같은 기준으로 비교할 수 있습니다.

입력 계약에는 field와 출처도 필요합니다. 사용자가 작성한 질문, database의 승인된 record, 검색으로 가져온 외부 문자열과 과거 model 답변은 신뢰 수준이 다릅니다. 어떤 부분이 instruction이고 어떤 부분이 처리할 data인지 delimiter와 role로 구분합니다. 외부 문서 안의 “이전 규칙을 무시하라”는 문장을 명령으로 승격하지 않으며 application에서 tool·secret·network 권한을 제한합니다.

출력에는 형식과 실패 행동을 함께 둡니다. 단순히 JSON이라고 쓰지 말고 field 이름·type·enum·필수 여부와 근거가 없을 때 `unverified`를 반환할지, 재시도를 요청할지, 사람에게 넘길지를 정합니다. Model이 schema 모양을 맞춰도 값의 사실성은 별도입니다. Parser·schema validator, 계산 code, 원문 대조와 권한 검사가 각각 어느 실패를 막는지 기록합니다.

긴 prompt가 자동으로 좋은 계약은 아닙니다. 충돌하는 규칙, 실행 계층이 확인할 수 없는 선언과 같은 뜻의 반복은 token·latency를 늘리고 핵심을 흐립니다. 반대로 짧더라도 업무 경계가 명확하고 실패 test를 통과하면 충분할 수 있습니다. 글자 수 목표 대신 대표·경계·실패 사례에서 어느 문장이 실제 결과를 바꾸고 어느 검증기가 오류를 잡는지 근거로 다듬습니다.

왜 이런가

성공과 실패를 먼저 정의해야 prompt 변경을 취향이 아니라 같은 업무 기준으로 비교할 수 있기 때문입니다.

언제 문제가 되는가

모호한 주문을 길게 늘리면 자연스러운 답 한 개만 보고 승인하고 숫자 누락·근거 조작·빈 입력 같은 실패를 놓칩니다.

초보자가 자주 하는 오해

역할을 부여하거나 “반드시 정확하게”라고 쓰는 문장만으로 사실 검증과 권한 통제가 완성되는 것은 아닙니다.

직접 확인하는 방법

현재 prompt에서 목적·입력 출처·금지·출력 schema·실패 상태를 표시하고 각각을 검증하는 test 또는 code가 있는지 대조하십시오.

System message에는 서비스 전반의 목적, 허용 범위와 실패 원칙처럼 오래 유지될 규칙을 둡니다. User message에는 현재 사용자의 과업, 대상과 입력을 둡니다. Assistant history는 이전 출력 기록이지 항상 참인 지식이나 새로운 운영 규칙이 아닙니다. Tool 결과와 검색 문서는 외부에서 온 data이므로 그 안의 문장이 명령처럼 보여도 더 높은 권한을 얻지 않게 경계를 표시합니다.

Role 우선순위를 설명하는 문장만으로 공격이 사라지지는 않습니다. Model은 확률적 문자열 생성기이고 복잡한 문맥에서 경계를 잘못 따를 수 있습니다. 비신뢰 문서가 secret을 요구해도 model이 secret 자체를 볼 수 없도록 하고, 외부 전송·삭제·결제는 server의 allowlist·권한 검사와 사람 승인으로 막습니다. Prompt는 방어의 한 층이고 실행 권한의 최종 판정자는 application입니다.

역할 충돌을 의도적으로 시험합니다. User가 system의 출력 제한을 바꾸라고 할 때, 검색 문서가 다른 목적을 주장할 때, 과거 assistant가 틀린 label 정의를 말했을 때와 system이 비어 있을 때를 평가합니다. 정상 사례만 있으면 model이 우연히 잘 따르는지 경계가 실제로 유지되는지 알 수 없습니다. 실패 출력과 어느 층에서 중단됐는지를 함께 기록합니다.

업무 규칙과 사용자 선택도 구분합니다. 예를 들어 “한국어로 답한다”는 서비스 기본값일 수 있지만 사용자가 영어 번역을 요청할 수 있다면 override 조건이 필요합니다. 절대 금지와 기본 선호를 같은 강도로 쓰면 충돌이 늘어납니다. 각 규칙의 owner, 허용 override와 violation 처리 방식을 정하고 변경 시 role conflict set을 회귀 실행합니다.

왜 이런가

입력의 권한을 구분해야 외부 data의 지시문과 과거 model 오류가 운영 규칙으로 오르는 것을 줄일 수 있기 때문입니다.

언제 문제가 되는가

검색 문서와 system rule을 한 문자열로 합치면 prompt injection이 명령처럼 처리되고 어느 출처가 결과를 바꿨는지 추적하기 어렵습니다.

초보자가 자주 하는 오해

System role은 model이 절대 어길 수 없는 보안 경계가 아니며 secret·tool 권한을 넣어도 되는 안전 금고가 아닙니다.

직접 확인하는 방법

비신뢰 문서에 규칙 무시·외부 전송 문자열을 넣은 뒤 model 답뿐 아니라 application의 tool·network·secret 접근이 차단되는지 시험하십시오.

Hugging Face 공식 chat template 문서가 설명하듯 chat은 결국 model이 처리하는 token sequence로 바뀝니다. `{role: user, content: ...}` 같은 객체는 application 표현이고 tokenizer template가 `<|user|>`나 `[INST]` 같은 model별 control token을 붙입니다. 같은 대화라도 다른 template를 적용하면 model이 학습 때 보지 못한 배열이 되어 성능이 크게 나빠질 수 있습니다. Model family 이름만 맞는다고 입력 형식까지 맞는 것은 아닙니다.

공식 tokenizer의 `apply_chat_template` 경로와 실제 runtime rendering을 비교합니다. Generation 시작 marker, turn 종료 token, system role을 합치는 방식과 multi-turn 순서를 확인합니다. Rendered 문자열에 이미 special token이 있는데 tokenizer가 다시 BOS·EOS를 붙이면 중복될 수 있습니다. UI에 보이는 message만 저장하지 말고 렌더링 결과 또는 hash와 token ID·길이를 evidence에 남깁니다.

Template는 context budget에도 영향을 줍니다. Role marker와 예시가 늘수록 실제 업무 data에 쓸 token이 줄고 긴 입력은 truncation될 수 있습니다. 어느 쪽을 자르는지, system 규칙이나 최신 user 질문이 잘리지 않는지를 exact tokenizer에서 측정합니다. Template 최대 길이와 model architecture의 context maximum, runtime의 현재 allocated context를 같은 숫자로 오해하지 않습니다.

Model 또는 runtime을 바꿀 때 golden render test를 실행합니다. 고정 messages에 대해 control token 순서, generation marker와 token 수가 예상과 같은지 확인하고 실제 정상·충돌·빈 입력 결과를 비교합니다. Runtime default template가 update로 바뀌었거나 client가 이미 렌더링한 문자열을 server가 다시 감쌌다면 prompt text가 같아도 회귀할 수 있습니다. Weight·tokenizer·template·runtime을 독립 revision으로 관리합니다.

왜 이런가

Model은 role 객체가 아니라 template가 만든 token sequence를 읽으므로 잘못된 직렬화는 prompt 문구 전체의 의미를 바꿀 수 있기 때문입니다.

언제 문제가 되는가

UI message만 저장하면 special token 중복, generation marker 누락과 runtime default 변경이 만든 회귀를 재현할 수 없습니다.

초보자가 자주 하는 오해

Instruct 또는 chat이라는 model 이름이 모든 runtime에서 올바른 template를 자동 선택하고 영구히 고정한다는 뜻은 아닙니다.

직접 확인하는 방법

대표 messages를 official tokenizer와 배포 runtime에서 렌더링해 문자열·token ID·길이와 종료 marker를 비교하고 hash로 고정하십시오.

Few-shot은 몇 개의 입력·출력 쌍으로 원하는 형식과 판단 방식을 보여 줍니다. 먼저 사람이 label 정의와 업무 규칙을 만들고 실제 유입에서 대표적인 예시를 고릅니다. 단순한 환불 문의만 여러 개 넣기보다 환불과 교환 단서가 함께 있는 사례, 필요한 주문 번호가 없는 사례와 `unknown` 출력처럼 판단 경계를 드러내는 예시가 유용합니다. 예시는 규칙을 보충하지만 taxonomy 자체를 대신하지 않습니다.

정답뿐 아니라 왜 다른 label이 아닌지 검토할 수 있어야 합니다. 그러나 긴 reasoning을 그대로 예시에 넣는 것이 항상 낫지는 않습니다. 불필요한 내부 설명은 token을 쓰고 model이 표현을 복제할 수 있습니다. 사용자에게 필요한 짧은 근거 field와 검증 가능한 evidence만 제공하고, 민감한 실제 고객 data는 비식별화하거나 권한 있는 test fixture로 대체합니다.

예시 수에는 고정 정답이 없습니다. Model context, 예시 token 길이, 업무 다양성과 평가 개선을 함께 봅니다. 한 예시를 추가했을 때 경계 품질이 오르지만 입력 truncation과 p95가 악화된다면 retrieval로 현재 질문과 관련된 검증 예시만 선택할 수 있습니다. 예시 없는 instruction baseline, 작은 묶음과 큰 묶음을 같은 gold set에서 비교해 한계효용을 확인합니다.

예시 leakage와 순서 편향을 검사합니다. Few-shot 문장과 test item이 거의 같으면 실제 일반화보다 점수가 높아집니다. 고객·문서·시간 단위로 분리하고 label 순서와 고유명사를 바꿔도 판단이 유지되는지 봅니다. 다수 label 예시가 뒤쪽에 있다고 그 label로 쏠리지 않는지 confusion matrix를 확인하고 통과한 example set을 prompt version과 함께 hash로 저장합니다.

왜 이런가

예시는 업무 경계를 구체화하지만 잘못 고르면 표면 표현·순서·다수 label을 모방해 평가를 왜곡할 수 있기 때문입니다.

언제 문제가 되는가

쉬운 정상 예시를 임의의 고정 개수로 채우면 실제 비용이 큰 혼합·불충분 입력에서 실패하고 context만 낭비합니다.

초보자가 자주 하는 오해

예시가 많을수록 항상 정확하고, few-shot에 들어간 정답을 맞히면 새로운 업무 사례에도 일반화됐다는 뜻은 아닙니다.

직접 확인하는 방법

예시 없음·작은 묶음·후보 묶음을 같은 분리 test에서 비교하고 순서 변경·경계 label·token·p95 결과를 함께 보십시오.

Autoregressive model은 현재까지의 token으로 다음 token 후보의 점수를 계산하고 하나를 선택하는 일을 반복합니다. Hugging Face 공식 generation strategy에서 greedy decoding은 각 단계의 가장 가능성 높은 token을 고릅니다. Sampling은 확률 분포에서 무작위로 token을 선택하고 beam search는 여러 candidate sequence를 유지합니다. 이 이름들은 문장 생성 경로를 설명하며 답이 외부 사실과 맞는지 검사하는 평가기는 아닙니다.

Greedy는 같은 환경에서 표현 변동을 줄이는 출발점이 될 수 있지만 sequence 전체의 가장 좋은 업무 답을 보장하지 않습니다. 앞 단계의 높은 확률 선택이 뒤의 반복이나 잘못된 결론으로 이어질 수 있습니다. 반대로 sampling은 여러 표현과 아이디어를 탐색할 수 있지만 낮은 확률의 부정확하거나 형식에 맞지 않는 token도 선택할 수 있습니다. 어떤 방식이 적합한지는 업무 오류 비용과 평가 결과로 결정합니다.

분류·추출처럼 output space가 작고 검증이 쉬운 일은 낮은 변동 baseline과 schema를 먼저 시험합니다. 창작 후보 생성은 반복 결과의 유용성·중복·금지 내용과 사람이 고르는 비용을 측정합니다. 대화는 안정성과 표현 다양성의 중간 범위를 찾을 수 있습니다. “정확 작업은 항상 0, 창작은 항상 1” 같은 보편 숫자를 복사하지 않고 model·runtime별 실제 distribution을 봅니다.

비교할 때 prompt·template·model과 평가 set을 고정합니다. Greedy와 sampling을 한 번씩 실행해 좋은 문장만 고르지 말고 정상·경계·실패 입력에서 여러 번 실행합니다. 정답·근거, schema, 누락, 반복·다양성과 p95·token을 raw output별로 저장합니다. Decoding 변경이 숨은 prompt·model 변경과 섞이지 않게 한 번에 한 변수를 바꿉니다.

왜 이런가

선택 전략을 사실성 스위치로 오해하지 않아야 오류에 맞는 근거 검색·validator·model 개선을 선택할 수 있기 때문입니다.

언제 문제가 되는가

틀린 답이 반복될 때 temperature만 낮추면 같은 잘못을 더 일관되게 생성하고 근거 부족이나 prompt 오류를 숨길 수 있습니다.

초보자가 자주 하는 오해

Greedy는 항상 가장 정확하고 sampling은 항상 창의적이라는 단일 순위가 모든 model·업무에 적용되는 것은 아닙니다.

직접 확인하는 방법

동일 manifest에서 전략별 반복 raw output을 모아 품질·schema·다양성·지연을 하위 집합별로 비교하십시오.

Temperature는 일반적으로 logits의 상대적 선명도를 바꿔 높은 점수 후보에 확률이 얼마나 몰리는지에 영향을 줍니다. Top-p는 누적 확률이 임계 범위에 들어오는 후보 집합에서 sampling하도록 제한합니다. 값의 허용 범위, 0 처리와 다른 filter와의 적용 순서는 runtime·version에 따라 다를 수 있습니다. Client가 보낸 parameter가 server에서 무시되거나 default로 바뀌지 않았는지 request와 resolved config를 확인합니다.

두 값을 동시에 크게 바꾸면 어느 설정이 결과를 바꿨는지 알기 어렵습니다. 먼저 지원되는 baseline을 두고 temperature 하나 또는 top-p 하나를 단계적으로 조정합니다. 품질·schema와 함께 distinct answer, self-repetition과 금지 content 비율을 측정합니다. 숫자를 “창의성 70점”처럼 직접 해석하지 말고 해당 model·prompt·업무에서 관찰한 결과 범위로 문서화합니다.

출력 길이는 별도 계약입니다. `max_new_tokens`는 새로 생성할 token의 상한이고 context maximum은 입력과 출력에 사용할 전체 공간과 관련됩니다. 너무 낮으면 JSON closing brace·근거가 잘리고 너무 높으면 반복·지연·비용과 자원 점유가 늘 수 있습니다. 예상 output token 분포와 가장 긴 정상 결과를 측정해 상한을 정하고 초과 시 부분 결과를 소비하지 않는 실패 처리를 둡니다.

EOS token, stop 문자열과 schema 완료 조건도 시험합니다. Stop 문자열이 정상 문장이나 JSON value 안에 포함되어 조기 종료되는지, 여러 token으로 나뉜 stop을 streaming client가 올바르게 처리하는지 확인합니다. Model이 종료 token을 내지 않을 때 상한이 작동하고 client 취소 뒤 server 자원이 회수되는지도 봅니다. Template의 end-of-turn과 API stop 목록이 중복되면 실제 output으로 검증합니다.

왜 이런가

후보 분포와 종료 조건은 서로 다른 실패를 만들므로 분리해야 형식 오류·다양성 부족·무한 생성의 원인을 찾을 수 있기 때문입니다.

언제 문제가 되는가

여러 값을 한꺼번에 조정하면 우연히 좋은 output만 남고 JSON 잘림·stop 충돌과 server parameter 무시를 재현하지 못합니다.

초보자가 자주 하는 오해

Temperature·top-p 숫자는 model과 runtime을 넘어 같은 창의성 수준을 뜻하거나 낮을수록 사실이 맞는 공통 척도가 아닙니다.

직접 확인하는 방법

Resolved generation config와 raw response를 저장하고 한 변수씩 바꾼 반복 test에서 schema 종료·stop·상한·p95를 확인하십시오.

Ollama 공식 structured outputs 문서처럼 request에 JSON schema를 제공하고 Pydantic·Zod 같은 도구로 response를 검증할 수 있습니다. JSON Schema는 JSON data의 구조와 validation semantics를 기술하는 형식입니다. 필수 field, type, enum, array item과 추가 field 허용 여부를 명확히 하면 자유문 parsing보다 application contract를 안정적으로 만들 수 있습니다. 사용 중인 runtime이 지원하는 schema subset과 error behavior는 exact version에서 확인합니다.

Schema 통과는 `amount`가 number라는 사실을 확인할 수 있지만 그 금액이 원문과 같은지, 최신 정책인지와 해당 사용자가 볼 수 있는 record인지는 증명하지 않습니다. `source_paragraph`가 실제 문서에 존재하는지 조회하고 합계·날짜 범위는 code로 계산하며 authorization을 server에서 다시 검사합니다. Model이 만든 confidence 숫자도 calibration 평가 없이 실제 확률로 사용하지 않습니다.

실패를 숨기지 않는 field를 설계합니다. 근거가 없을 때 필수 값을 억지로 만들게 하지 말고 `status: unverified`, `missing_fields`와 빈 evidence를 허용할 수 있습니다. 반대로 null과 빈 문자열의 뜻이 다르면 schema와 업무 code가 같은 해석을 쓰게 합니다. Parser 실패, schema violation, 근거 불일치와 정책 위반을 다른 error code로 남겨 재시도·사람 검토·중단을 결정합니다.

Prompt에 schema를 문자로 반복할 때와 API의 native schema option을 함께 쓸 때 token 비용과 충돌을 봅니다. Structured output 기능이 있어도 정상·경계·긴 문자열·Unicode·escape와 streaming 완료를 평가합니다. 재시도는 횟수·시간 상한을 두고 같은 잘못된 결과를 무한 반복하지 않습니다. Schema version 변경은 consumer code와 함께 contract test하고 이전 version을 처리할 migration 또는 rollback을 준비합니다.

왜 이런가

구조 오류와 사실·권한 오류를 분리해야 parser 통과를 과신하지 않고 실패에 맞는 복구 경로를 선택할 수 있기 때문입니다.

언제 문제가 되는가

Valid JSON만 세면 model이 만든 틀린 숫자·가짜 근거와 권한 밖 record가 모두 성공으로 기록될 수 있습니다.

초보자가 자주 하는 오해

JSON schema 또는 낮은 temperature를 사용하면 출력 내용까지 결정적이고 사실적으로 보장되는 것은 아닙니다.

직접 확인하는 방법

Schema validator 뒤에 원문 존재·계산·업무 rule·authorization 검사를 연결하고 각 오류 fixture가 다른 상태로 중단되는지 시험하십시오.

Sampling 비교에서는 seed를 기록해 같은 pseudo-random 경로를 재실행하는 데 도움을 받을 수 있습니다. 그러나 PyTorch 공식 reproducibility 문서가 설명하듯 release·platform과 CPU·GPU가 달라지면 완전한 재현을 보장하지 못할 수 있습니다. Runtime이 seed를 실제로 지원·적용하는지, batch와 concurrency에서 요청 순서가 random state에 영향을 주는지도 확인합니다. Seed parameter 이름만 있다고 deterministic service라고 부르지 않습니다.

재현 manifest에는 model·weight hash, tokenizer·chat template, prompt·example·schema hash, generation config, input 순서와 runtime·library·driver·hardware를 둡니다. Quantization, attention backend와 parallelism도 수치 차이를 만들 수 있습니다. Container digest와 environment를 보존하고 resolved server config·rendered prompt·raw output을 연결합니다. 움직이는 latest tag와 main branch는 비교 기준으로 사용하지 않습니다.

Deterministic algorithm option은 반복성을 높일 수 있지만 지원되지 않는 연산에서 error가 나거나 성능이 달라질 수 있습니다. 연구 재현 환경과 production throughput 환경이 다르면 두 조건을 모두 명시하고 품질 차이를 확인합니다. CPU와 GPU 결과가 약간 다른 상황에서 문자열 완전 일치만 고집하기보다 업무 정답·schema·중요 실패가 같은지와 수치 허용 범위를 사전에 정합니다.

한 seed의 좋은 결과를 candidate 대표로 선택하지 않습니다. 여러 seed 또는 반복 run에서 품질·schema·diversity·p95 distribution을 보고 최악 하위 집합과 변동 폭을 기록합니다. Bug는 가능한 exact seed와 stack으로 재현하되 재현되지 않아도 production failure를 지우지 않습니다. Model·runtime update 뒤에는 이전 seed set과 새 random sample을 함께 실행해 고정 fixture 과적합을 줄입니다.

왜 이런가

생성 결과에는 random state 외에도 library·kernel·parallel execution이 영향을 주므로 seed 하나만으로 변경 원인을 설명할 수 없기 때문입니다.

언제 문제가 되는가

같은 seed 한 번이 일치했다고 재현 가능으로 승인하면 platform update·동시 부하에서 달라지는 실패와 성능을 놓칩니다.

초보자가 자주 하는 오해

Seed를 고정하면 모든 장치·runtime version에서 문자가 영원히 동일하거나 model 답의 정확성이 보장되는 것은 아닙니다.

직접 확인하는 방법

Exact manifest에서 seed set을 반복하고 다른 machine·candidate의 업무 metric 분포와 deterministic option의 지연 비용을 비교하십시오.

먼저 baseline을 immutable version으로 고정하고 결과를 보기 전에 gate를 정합니다. 업무 정답·근거, schema·필수 field, 거절·누락, 다양성 목표 범위, p95·token과 오류를 분리합니다. 정상·경계·실패 하위 집합의 최소 기준을 두어 전체 평균이 높아도 숫자 추출·빈 근거·안전 거절 같은 필수 실패가 숨지 않게 합니다. 목표와 판정자는 candidate output을 보기 전에 승인합니다.

Candidate는 같은 model·template·gold set·runtime과 hardware에서 최소 여러 번 실행합니다. Prompt 문구를 비교하면서 model·quant와 temperature도 동시에 바꾸지 않습니다. 각 output, schema error, latency와 token usage를 request manifest에 연결하고 사람 판정에는 rubric과 disagreement 처리를 둡니다. Self-check나 model judge는 보조 신호일 뿐 계산·근거와 독립 novice reviewer를 대신하지 않습니다.

모든 offline gate를 통과한 뒤 제한된 canary traffic에서 production 분포와 privacy를 지키며 관측합니다. Schema failure, 보류·거절, 사용자 수정, p95와 downstream error를 baseline과 비교합니다. 사전에 정한 stop condition을 넘으면 자동 또는 승인된 절차로 traffic을 이전 prompt·template·config에 되돌립니다. 같은 failure input이 이전 version에서 실제로 회복되는지 확인해야 rollback 준비가 증명됩니다.

Evidence에는 owner·reviewer, 목적과 적용 범위, exact source·version, raw result 위치, limitation과 결정 날짜를 남깁니다. Model·runtime·template·schema, 업무 taxonomy와 입력 분포가 바뀌면 재검토합니다. 이전 version을 덮어쓰지 않고 deprecation·retirement 시점을 관리합니다. 최종 결론은 “이 prompt가 더 좋다”가 아니라 어느 exact 조건에서 어떤 gate를 통과했고 어떤 실패에는 hold인지여야 합니다.

왜 이런가

Prompt와 sampling은 code 없이도 사용자 행동과 downstream system을 바꾸므로 배포·복구 가능한 변경 단위로 다뤄야 하기 때문입니다.

언제 문제가 되는가

좋은 예시 한 개를 보고 prompt를 덮어쓰면 회귀 범위, template·sampling 원인과 복구본을 잃고 production에서 기준을 낮추게 됩니다.

초보자가 자주 하는 오해

Prompt는 문자열이므로 review·version·canary 없이 즉시 바꿔도 안전하거나 model update와 독립적으로 영구 승인되는 것은 아닙니다.

직접 확인하는 방법

동일 manifest 반복, 하위 집합 gate와 canary stop을 실행한 뒤 이전 version으로 같은 실패 input을 복구하고 evidence ID를 남기십시오.

OpenAI 공식 function calling 흐름은 tool을 model에 제시하고, model의 call을 받은 application이 함수 code를 실행한 뒤 result를 다음 model 요청에 전달하는 단계로 나뉩니다. Model이 `send_email`이라는 JSON을 만들었다는 사실은 email이 전송됐거나 현재 사용자가 전송 권한을 얻었다는 뜻이 아닙니다. Dispatcher는 등록한 exact tool version만 찾고 이름·argument·caller context와 policy가 모두 맞을 때만 executor에 넘깁니다.

Tool 선택도 실패할 수 있습니다. Model이 아무 call 없이 답하거나, 잘못된 tool을 고르거나, 같은 turn에 dependency가 있는 call을 병렬로 만들 수 있습니다. Application은 zero·one·many 경우를 명시적으로 처리하고 병렬 실행이 side effect 순서와 충돌하지 않는지 판단합니다. “Model이 알아서 하나를 고를 것”이라는 가정 대신 normal·ambiguous·conflicting request를 contract test합니다.

Model argument에는 client가 보내면 안 되는 값이 있습니다. 현재 user ID, tenant, 권한 scope와 server가 알고 있는 order ID를 model에게 다시 만들게 하면 다른 resource를 추측할 수 있습니다. 이런 authoritative 값은 authenticated session·server state에서 주입하고 model은 실제 업무에 필요한 제한된 선택만 냅니다. Tool 이름·description에도 언제 쓰고 언제 쓰지 않는지와 output 의미를 분명히 적습니다.

실행 상태를 사용자에게 구분해 보여 줍니다. “제안됨”, “승인 대기”, “실행 중”, “성공”, “부분 실패”를 한 완료 문구로 합치지 않습니다. 성공은 model의 자연어가 아니라 authoritative API response와 resource state로 확인합니다. Audit trace에는 run·call ID, caller, tool/schema version, validated argument hash, policy·approval과 side-effect ID를 연결합니다.

왜 이런가

제안과 실행을 분리해야 model 오류가 실제 외부 상태 변경이나 권한 상승으로 곧바로 이어지지 않기 때문입니다.

언제 문제가 되는가

Tool call JSON을 바로 함수에 넘기면 모르는 tool·다른 tenant ID·중복 결제가 model 출력 한 번으로 실행될 수 있습니다.

초보자가 자주 하는 오해

Function calling을 지원하는 model은 application 권한·업무 규칙과 실제 함수 성공까지 이해하고 보증하는 실행 엔진이 아닙니다.

직접 확인하는 방법

등록하지 않은 이름, 다른 tenant resource, zero·duplicate·parallel call fixture를 보내 실제 side effect 0과 명확한 오류 상태를 확인하십시오.

OpenAI 공식 문서는 strict mode가 function call을 schema에 맞게 만들고 object의 `additionalProperties: false`와 required field 같은 조건을 요구한다고 설명합니다. 이것은 자유로운 text parsing보다 안정적인 시작점입니다. Enum, numeric range와 nested object를 사용해 허용 모양을 좁히고 optional의 뜻을 명확히 합니다. 사용 중인 API가 지원하는 JSON Schema subset과 strict fallback 여부를 exact response에서 확인합니다.

Valid argument가 valid action은 아닙니다. `{invoice_id: "A-19", amount: 50000}`이 schema를 통과해도 invoice가 현재 tenant 소유인지, 이미 환불됐는지, 사용자의 한도 안인지와 currency가 맞는지는 모릅니다. Server가 database의 current version과 caller permission을 조회하고 stale resource·business conflict를 별도 오류로 돌려줍니다. Model이 보낸 role·owner field로 authorization하지 않습니다.

Tool interface를 좁게 만들면 invalid state를 줄일 수 있습니다. `execute(action, payload)`나 raw SQL 대신 `get_invoice`와 `request_refund`를 분리합니다. 이미 UI에서 선택한 invoice ID는 server context로 결박하고 model에는 reason category 같은 필요한 parameter만 맡깁니다. 항상 연속 실행되는 안전한 두 단계를 하나의 transaction tool로 묶을 수도 있지만 승인 경계와 rollback이 다른 작업은 분리합니다.

Output도 schema와 semantic validation이 필요합니다. Tool result의 field type, size와 required value를 확인하고 HTML·script·외부 instruction, secret·PII를 정제합니다. Result가 `success: true`여도 실제 resource ID와 상태를 재조회할 수 있습니다. Model에는 다음 판단에 필요한 최소 field와 stable error code를 주고 내부 stack trace·credential·전체 database row를 그대로 노출하지 않습니다.

왜 이런가

구조 validation과 업무 authorization은 막는 실패가 다르므로 둘을 연결해야 valid JSON을 안전한 실행으로 오해하지 않습니다.

언제 문제가 되는가

Schema 통과만 성공으로 세면 다른 사용자의 유효한 ID, 정책 밖 금액과 이미 처리된 resource가 정상 호출로 실행됩니다.

초보자가 자주 하는 오해

Strict mode는 model argument의 schema 준수를 높이지만 내용의 진실성·권한·현재 상태와 side effect 안전을 인증하지 않습니다.

직접 확인하는 방법

형식은 맞지만 다른 tenant·초과 금액·stale version인 fixture를 실행해 schema 통과 뒤 domain·authorization gate가 각각 거절하는지 확인하십시오.

Tool catalog가 넓을수록 model이 잘못 선택할 후보와 공격자가 노릴 capability가 늘어납니다. 현재 turn에 필요한 namespace·tool만 노출하고 read-only 조회, additive write, destructive action과 arbitrary network·code 실행을 위험 tier로 나눕니다. 범용 shell·browser·SQL은 sandbox·allowlist 없이 production agent에 주지 않습니다. Tool search를 쓰더라도 발견된 server와 tool version의 trust를 검증합니다.

MCP 2026-07-28 tools specification은 server가 입력 validation, 접근 통제, rate limit과 output 정제를 하고 client가 민감 작업 확인, tool result validation, timeout·audit를 고려하도록 명시합니다. Tool annotation은 trusted server가 아니면 신뢰할 수 없는 hint입니다. Remote server가 `readOnly`라고 주장했다는 이유로 실제 endpoint review·approval을 생략하지 않습니다.

Authentication은 caller가 누구인지 확인하고 authorization은 그 caller가 현재 resource에 어떤 action을 할 수 있는지 판단합니다. MCP authorization 같은 transport framework를 사용해도 invoice·document별 정책은 application이 수행해야 합니다. Access token은 대상 resource·audience와 scope에 묶고 다른 server token을 그대로 downstream에 넘기지 않습니다. Browser·model context·prompt·tool result에 master credential을 넣지 않습니다.

Rate와 resource budget도 권한입니다. Read-only search가 전체 customer database를 dump하거나 arbitrary URL로 요청하면 confidentiality·availability를 해칠 수 있습니다. Query scope, rows·bytes, egress domain, context에 돌려줄 결과 크기와 per-user·run quota를 둡니다. Credential rotation·revocation, server compromise와 tool list update 때 기존 run이 새 권한을 자동 상속하지 않게 version과 expiry를 확인합니다.

왜 이런가

Prompt injection이 성공해도 agent가 볼 수 있고 실행할 수 있는 capability가 작으면 실제 피해 범위를 제한할 수 있기 때문입니다.

언제 문제가 되는가

Master token과 broad SQL·URL tool을 주면 비신뢰 문서 한 줄이 tenant 전체 read, 외부 전송이나 resource 고갈로 이어질 수 있습니다.

초보자가 자주 하는 오해

MCP 연결 성공, OAuth login 또는 readOnly annotation 하나가 모든 tool argument·resource와 downstream 권한을 자동 승인하지 않습니다.

직접 확인하는 방법

권한 없는 user·tenant, scope 밖 tool, 대량 read와 비허용 egress를 호출해 server의 0 data·0 side effect, rate와 audit를 확인하십시오.

Tool failure는 모두 같은 자연어 오류가 아닙니다. Malformed argument는 model이 schema에 맞춰 고칠 수 있고 429·일시적 5xx는 backoff 뒤 제한 retry가 가능할 수 있습니다. 401·403은 credential·권한 문제이고 409 같은 business conflict는 resource 상태가 바뀌었음을 뜻할 수 있습니다. 오류 class별 최대 retry, 사람 handoff와 공개할 detail을 contract에 둡니다.

Mutation request에는 idempotency key를 사용합니다. Key를 run·logical action과 결박하고 server가 이전 response·side-effect ID를 돌려주도록 합니다. Timeout이 났다고 새로운 key로 다시 결제하면 첫 요청이 실제 성공한 뒤 중복될 수 있습니다. Status endpoint나 resource state를 조회해 unknown 결과를 해소하고 정확히 한 번 실행을 쉽게 약속하지 말며 중복 탐지·보상 절차를 문서화합니다.

Tool result는 model이 다음 계획에 사용하는 observation이므로 성공·실패와 authoritative state를 명확히 담습니다. Protocol error, tool execution error와 domain error를 구분해 model이 수정 가능한 누락 field와 권한 실패를 다르게 처리하게 합니다. 그러나 내부 topology·stack·secret을 포함한 오류를 그대로 주면 공격자가 탐색에 사용할 수 있습니다. 사용자에게는 오류 ID와 복구 가능한 다음 행동을 제공합니다.

Batch의 부분 실패를 숨기지 않습니다. 세 건 중 한 건만 실행됐으면 완료가 아니라 executed·failed·not_attempted 목록과 side-effect ID를 남깁니다. Compensation이 실제 원상 복구인지 별도 반대 transaction인지, 외부 email처럼 되돌릴 수 없는지를 tool별로 표시합니다. Agent가 목표를 축소하거나 실패 item을 빼고 success라고 말하지 않게 acceptance test가 전체 ledger를 확인합니다.

왜 이런가

Network timeout과 model 반복은 정상적으로 발생할 수 있어 mutation을 재실행 가능한 protocol로 만들지 않으면 중복 피해가 생기기 때문입니다.

언제 문제가 되는가

모든 오류를 세 번 재시도하면 권한 우회 시도·중복 결제·rate 폭주가 생기고 partial success가 완료로 잘못 표시됩니다.

초보자가 자주 하는 오해

Agent prompt에 “중복 실행하지 마”라고 쓰는 것은 server idempotency key·상태 조회와 transaction 설계를 대신하지 않습니다.

직접 확인하는 방법

Response 전 connection을 끊고 같은 logical action을 재개해 side-effect ID 하나만 존재하며 batch의 실행·실패·미실행이 정확히 보이는지 확인하십시오.

Agent는 목표를 계획하고 tool을 실행해 observation으로 다음 행동을 정하는 loop처럼 보입니다. Production에서는 이 loop의 상태가 chat text에만 있으면 안 됩니다. Immutable goal과 acceptance criteria, caller·tenant, plan revision, current step, tool call·result, approval과 side-effect ID를 durable store에 둡니다. Model context는 필요한 view이고 system of record는 application state입니다.

각 step은 pending·approved·executing·succeeded·failed·held 같은 명확한 상태 전이를 가집니다. Process가 crash하면 checkpoint에서 이미 성공한 mutation을 찾아 idempotency key로 재사용하고 아직 실행하지 않은 step만 계속합니다. “아마 성공했음”을 다음 prompt에 넣지 않고 authoritative API나 resource version을 조회합니다. Resume 시 tool·policy version이 달라졌다면 새 승인·평가를 요구할 수 있습니다.

Parallel agent와 human edit는 stale state를 만듭니다. Resource ETag·version, compare-and-set 또는 lock으로 변경 충돌을 감지합니다. 첫 agent가 읽은 잔액·문서를 두 번째 agent가 바꾼 뒤 그대로 실행하지 않게 approval에 resource version을 묶습니다. Observation timestamp와 provenance를 기록하고 cache 결과의 freshness·scope를 검증합니다.

Memory와 audit 목적도 분리합니다. 사용자 선호 같은 장기 memory를 task authorization이나 확정 사실로 쓰지 않습니다. Trace에는 재현에 필요한 input·schema·policy decision과 state ID를 남기되 raw secret·개인정보·전체 reasoning을 무제한 보존하지 않습니다. Retention·access·redaction policy와 incident legal requirement를 정하고 model output보다 tool·policy log를 중심 evidence로 삼습니다.

왜 이런가

Agent는 여러 단계와 장애를 넘으므로 실제 상태를 durable하게 관리해야 중복 실행·부분 완료와 stale observation을 복구할 수 있기 때문입니다.

언제 문제가 되는가

Chat history만 원장으로 쓰면 crash 뒤 무엇이 실행됐는지 몰라 같은 action을 반복하고 model의 잘못된 완료 문구를 사실로 저장합니다.

초보자가 자주 하는 오해

긴 context나 memory 기능은 database transaction, resource version과 감사 가능한 side-effect ledger를 자동 제공하지 않습니다.

직접 확인하는 방법

두 번째 step 실행 직후 process를 중단·재개하고 mutation 중복 0, 정확한 current state와 changed resource conflict가 탐지되는지 시험하십시오.

Agent budget은 token 하나로 끝나지 않습니다. 최대 model turn·tool call, wall-clock timeout, model·API 비용, read bytes·output tokens와 mutation 수를 따로 둡니다. 사용자가 요청한 업무 크기와 위험 tier에 맞춰 사전에 정하고 한도를 늘릴 권한도 분리합니다. Budget이 거의 끝났다고 남은 작업을 생략한 뒤 완료라고 표시하지 않습니다.

Loop는 같은 tool 이름만으로 찾기 어렵습니다. 같은 argument hash, 같은 error·observation, resource state 변화 없음과 plan 문구만 바뀌는 패턴을 추적합니다. 403을 다른 ID로 계속 시도하거나 검색어만 조금 바꿔 같은 문서를 읽는 것도 진행 없는 반복입니다. Tool별 retry counter와 run 전체 progress metric을 결합하고 threshold에서 새 call을 막습니다.

중단 상태에는 현재까지의 verified progress를 제공합니다. 목표, succeeded·failed·not_attempted step, 실제 변경과 side-effect ID, 마지막 오류 class·evidence와 사람이 승인하거나 수정할 정확한 다음 행동을 보여 줍니다. Raw chain-of-thought를 요구하지 않고 audit 가능한 fact와 decision만 전달합니다. Handoff 후 새 caller가 권한과 context를 다시 검증합니다.

Kill switch는 UI button뿐 아니라 server policy로 새 tool call과 credential 발급을 차단해야 합니다. 진행 중 call을 취소했을 때 downstream이 이미 실행했는지 조회하고 batch queue·task를 drain하거나 revoke합니다. Timeout·user cancel·incident stop과 normal success를 다른 terminal state로 기록합니다. Kill switch·resume와 previous orchestrator rollback을 정기적으로 연습합니다.

왜 이런가

확률적 계획과 외부 장애는 반복을 만들 수 있어 명시적 상한과 handoff가 없으면 비용·resource와 side effect가 계속 늘어나기 때문입니다.

언제 문제가 되는가

Max step만 prompt에 쓰면 model이 무시하거나 application이 계속 호출하고, 한도 직전 남은 item을 숨겨 거짓 완료를 만들 수 있습니다.

초보자가 자주 하는 오해

Agent가 스스로 완료라고 말하거나 같은 오류에 사과하면 실제 progress·예산과 안전한 terminal state가 확인된 것은 아닙니다.

직접 확인하는 방법

동일 403·timeout·변하지 않는 search result를 연속 제공해 threshold에서 새 call이 차단되고 정확한 partial ledger와 handoff가 나오는지 확인하십시오.

Approval UI는 function name보다 실제 결과를 설명해야 합니다. “send_email 호출 허용?”이 아니라 정확한 수신자, 제목·본문, 첨부, 외부 domain과 되돌릴 수 없음을 보여 줍니다. 결제는 통화·금액·수취인·수수료와 변경 전후를, 삭제는 전체 대상 수와 retention·복구 가능성을 표시합니다. Batch를 축약할 때 전체 목록과 filter·총합을 검토할 경로가 필요합니다.

승인 뒤 argument가 바뀌는 time-of-check/time-of-use 문제를 막습니다. Approval record에 authenticated caller, tool/schema version, canonical argument hash, resource version, expiry와 one-time nonce를 저장합니다. Executor는 현재 request와 모두 일치할 때만 실행하고 수신자·금액·file·resource가 달라졌으면 재승인을 요구합니다. Client의 boolean `approved`나 model의 “사용자가 동의함” 문장을 신뢰하지 않습니다.

위험 기반 policy로 automation 범위를 정합니다. Public read는 자동, private read는 authorization·audit, reversible internal draft는 preview와 idempotency, 외부 발송·금전·삭제·공개·권한 변경은 explicit approval이 필요할 수 있습니다. 고위험·대규모 action에는 two-person rule과 시간 지연을 적용합니다. Tool을 작게 만들고 safe default·dry run을 제공해 불필요한 확인을 줄입니다.

Approval 자체도 공격 test를 합니다. 만료·재사용, 다른 caller, argument 한 글자 변경, stale resource와 clickjacking·숨긴 대상, cancel 뒤 실행을 확인합니다. 사용자가 거절하면 model이 wording을 바꿔 같은 action을 반복 제안하지 않게 decision scope를 저장합니다. External email처럼 rollback이 불가능한 action은 recall을 약속하지 말고 test recipient·draft와 최종 발송을 분리합니다.

왜 이런가

사람이 본 대상과 executor가 실행할 대상이 같아야 승인이 실제 의도·위험 확인으로 기능하기 때문입니다.

언제 문제가 되는가

승인 token을 argument와 묶지 않으면 model이 승인 후 수신자·금액을 바꾸거나 오래된 승인을 다른 action에 재사용할 수 있습니다.

초보자가 자주 하는 오해

Confirmation dialog를 한 번 띄우거나 client가 approved=true를 보내면 server-side 권한·현재 상태와 의미 있는 동의가 보장되지 않습니다.

직접 확인하는 방법

승인 뒤 recipient·amount·resource version·caller를 각각 바꾸고 executor가 side effect 0으로 재승인을 요구하는지 시험하십시오.

Direct prompt injection은 user가 운영 지침을 바꾸려 하고 indirect injection은 검색 문서·webpage·email이나 tool result 안의 문자열이 model 행동을 유도합니다. “이전 지시를 무시”라는 문구만 차단하면 다른 언어·encoding·이미지와 더 자연스러운 요청을 놓칩니다. System·user·data 경계를 표시하되 model이 완벽히 지킨다고 가정하지 않고 실행 계층에서 capability를 제한합니다.

Model에게 필요 없는 secret과 broad tool을 보여 주지 않습니다. Secret vault는 executor가 exact destination·scope에서 사용하고 값 자체를 model context에 반환하지 않습니다. Egress allowlist, DNS·redirect 검증, URL scheme·IP range 제한과 response size를 둡니다. Search 문서가 외부 URL로 customer list를 보내라고 해도 customer read·arbitrary POST·credential이 한 agent에 동시에 조합되지 않게 분리합니다.

Tool result는 신뢰된 API에서도 공격 payload를 포함할 수 있습니다. HTML·Markdown link, hidden instruction과 file content를 sanitize·quote하고 source·trust label을 붙입니다. Result schema가 맞아도 text field의 instruction을 system command로 승격하지 않습니다. 다음 tool call은 원래 user goal, server policy와 authorization을 다시 통과하며 result가 추천한 tool name·argument를 직접 실행하지 않습니다.

OpenAI safety best practice처럼 대표 사용자 행동뿐 아니라 system을 깨려는 adversarial input을 red-team합니다. 공격 성공 metric은 model이 거절 문구를 썼는지가 아니라 unauthorized data read, secret exposure, non-allowlisted egress, approval bypass와 mutation이 실제 0인지입니다. Encoding·멀티턴·tool result·부분 권한·long context와 legitimate 업무를 방해하는 false positive도 함께 평가합니다.

왜 이런가

Model 수준 방어는 실패할 수 있으므로 공격자가 명령을 주입해도 사용할 capability와 data path를 제한해야 실제 피해를 막을 수 있기 때문입니다.

언제 문제가 되는가

문구 filter와 “외부 지시는 무시” prompt만 두면 변형 공격이 broad tool·secret·egress를 조합해 data를 외부로 보낼 수 있습니다.

초보자가 자주 하는 오해

Model이 공격 문장에 “거절합니다”라고 답하면 background tool·network·data access도 안전했다는 뜻은 아닙니다.

직접 확인하는 방법

비신뢰 문서·tool result에 encoded exfiltration 지시를 넣고 trace에서 secret read·비허용 egress·무승인 mutation이 모두 0인지 확인하십시오.

평가 manifest에는 model·prompt, exposed tool/schema, dispatcher·policy, credential scope, runtime과 gold trace set을 고정합니다. Normal success, ambiguous goal, missing input, 401·403, rate limit·timeout, malformed output, duplicate call, stale resource, direct·indirect injection과 partial failure를 포함합니다. Candidate마다 다른 tool·권한을 쓰면 변경 내용을 공개하고 common baseline을 유지합니다.

Metric은 task success·정확한 final state, schema·authorization, unauthorized read/write·exfiltration·approval bypass, duplicate mutation, max step·cost·p95와 human handoff completeness로 나눕니다. 무단 action과 중복 mutation 같은 필수 안전 gate는 0이어야 하며 평균 success로 상쇄하지 않습니다. 결과를 보기 전 threshold와 reviewer를 정하고 최소 여러 번 실행해 변동을 봅니다.

Trace는 caller·goal부터 call·policy·approval·tool result·side effect와 terminal state를 연결합니다. 개인정보·secret은 redact하되 source·argument·result hash와 resource version으로 incident를 재현합니다. Shadow·sandbox에서 실제 mutation 없이 시작하고 제한 canary에서 kill switch, queue drain과 credential revocation을 확인합니다. Production에서 feedback·near miss와 error를 다시 evaluation set에 넣습니다.

Rollback은 model만 이전 것으로 바꾸는 일이 아닙니다. Prompt, tool registry·schema, dispatcher, policy·credential configuration과 state migration을 previous compatible stack으로 복구합니다. 같은 failure trace의 unauthorized action·duplicate·p95와 handoff가 회복되는지 시험합니다. NIST의 pre-deployment testing·human oversight·change·incident 관리 원칙처럼 owner, limitation, 승인 범위와 재검토 trigger를 evidence에 남깁니다.

왜 이런가

Agent는 model·tool·권한과 외부 상태를 연결하므로 일반 답변 품질만으로 실제 위험·복구 능력을 판단할 수 없기 때문입니다.

언제 문제가 되는가

Task success 평균만 높이면 단 한 번의 무단 전송·중복 결제와 kill switch 실패가 숨고 이전 compatible stack도 없어집니다.

초보자가 자주 하는 오해

Model benchmark 또는 prompt injection 몇 문장 통과가 application 전체 tool 권한·장애·canary와 incident readiness를 인증하지 않습니다.

직접 확인하는 방법

고정 정상·공격·장애 trace를 3회 이상 실행해 모든 필수 gate와 kill switch·previous stack rollback을 side-effect ledger로 확인하십시오.

좋은 시작점은 model 목록이 아니라 사용자의 반복 업무입니다. 상담원이 invoice의 공급자·일자·총액을 입력하는지, 개발자가 boilerplate와 test 초안을 쓰는지, 회의 담당자가 transcript에서 action item을 찾는지 관찰합니다. 입력 format·빈도·변동, 현재 소요 시간과 자주 틀리는 지점을 기록하고 automation이 줄일 시간과 새로 만들 위험을 함께 적습니다.

성공은 검토 가능한 output으로 표현합니다. “좋은 요약” 대신 필수 조항·숫자·예외가 모두 있고 원문 문단을 찾을 수 있음, “정확한 OCR” 대신 total·tax·date field가 각각 threshold를 통과함처럼 정합니다. 평균에 숨으면 안 되는 critical field와 자동 처리·사람 보류 경계를 결과를 보기 전에 owner가 승인합니다.

한 model의 capability를 workflow 전체로 확장하지 않습니다. Vision model이 영수증을 설명해도 정확한 field OCR은 다르고, ASR transcript가 있어도 action item과 speaker attribution은 별도 stage입니다. Code model이 test를 작성해도 compiler·security와 repository review가 필요합니다. Specialist model·deterministic code와 사람 판단의 교집합을 설계합니다.

작은 pilot은 낮은 위험·높은 반복과 명확한 validator가 있는 업무에서 시작합니다. 최종 외부 발송·결제·merge를 자동화하기 전에 draft·추천·검토 queue로 시간을 줄입니다. Baseline에는 현재 사람 workflow의 품질·시간·correction을 측정합니다. Candidate가 실제 총 처리 시간을 줄이는지, review burden과 새로운 오류가 얼마나 생기는지 함께 비교합니다.

왜 이런가

사용자 결과와 오류 비용이 있어야 서로 다른 model output을 같은 업무 가치·위험으로 비교할 수 있기 때문입니다.

언제 문제가 되는가

Model demo의 자연스러운 한 결과로 시작하면 실제 빈 입력·표·잡음·dependency 같은 분포에서 실패하고 사람 검토 시간이 더 늘 수 있습니다.

초보자가 자주 하는 오해

작은 local model이라는 사실만으로 업무 범위가 안전하거나 검증·권한·개인정보와 사람 책임이 자동 해결되는 것은 아닙니다.

직접 확인하는 방법

현재 수작업 20건에서 입력·결과·소요 시간·수정 유형과 치명적 오류를 기록하고 candidate의 같은 항목과 비교하십시오.

원본을 받는 ingest에서 file type·size, source·owner, consent·license와 malware를 확인합니다. Image rotation·crop, audio resample·segment, text normalization과 code context selection을 deterministic preprocessing으로 나눕니다. Exact tool·parameter와 output hash를 저장해 model 결과가 바뀌었을 때 원본·전처리·model 중 무엇이 달라졌는지 설명할 수 있게 합니다.

Model output에는 source를 가리키는 좌표를 보존합니다. OCR field는 page·bounding box, ASR sentence는 audio start/end·speaker, summary claim은 paragraph ID, code patch는 base commit·file line과 연결합니다. 이 provenance를 LLM이 임의 생성한 ID가 아니라 pipeline이 authoritative mapping으로 붙입니다. 다음 stage는 text만 받지 않고 schema·source reference와 validation state를 받습니다.

각 stage는 success·hold·partial·error를 명확히 정의합니다. Corrupt file·unsupported language, truncation, low confidence와 rule conflict를 빈 문자열이나 추측으로 바꾸지 않습니다. Timeout·retry와 batch partial state를 기록하고 사람 queue에는 원본·candidate·오류 이유와 수정 UI를 제공합니다. Correction은 원본을 덮지 않고 reviewer·timestamp와 별도 version으로 저장합니다.

배포 manifest에는 preprocessing, model·runtime, prompt·schema, validator·glossary·pronunciation dictionary와 UI version을 둡니다. Stage 하나를 바꿔도 downstream metric을 전체 회귀합니다. Previous compatible pipeline과 intermediate schema migration을 보존하고 같은 failure sample이 rollback 뒤 회복되는지 확인합니다. Final asset·record에서 전체 lineage를 evidence ID로 추적합니다.

왜 이런가

여러 AI·code 단계가 연결되면 최종 오류만으로 원인을 알 수 없어 source·version과 stage 상태가 필수이기 때문입니다.

언제 문제가 되는가

Intermediate text만 복사하면 OCR 숫자 오류를 요약 model 문제로 오판하고 원본 위치·전처리·수정자를 찾거나 rollback할 수 없습니다.

초보자가 자주 하는 오해

Final output이 schema를 통과하거나 자연스러우면 upstream stage와 provenance도 올바르다는 뜻은 아닙니다.

직접 확인하는 방법

최종 field·문장·audio 한 항목에서 source page/span, preprocess, model·validator, correction·approval과 rollback artifact를 역추적하십시오.

목표 issue, base commit, 변경할 module과 acceptance criteria를 좁혀 제공합니다. Model은 repository 전체 invariant, dependency version과 hidden configuration을 알지 못해 존재하지 않는 API·불안전 default를 만들 수 있습니다. Output을 patch suggestion으로 받고 예상하지 않은 file·generated binary·lockfile 대규모 변경을 거절합니다. 한 번에 review 가능한 diff를 유지합니다.

Sandbox는 최소 filesystem·network와 disposable environment를 사용합니다. Repository secret, production credential·개인정보와 signing key를 prompt·environment에 넣지 않습니다. Install script와 build가 외부로 data를 보내거나 host path를 바꾸지 않게 dependency source·hash와 egress를 통제합니다. Generated command를 terminal에 blind paste하지 않고 exact target·effect를 읽습니다.

Compiler·typecheck, formatter·lint, unit·integration과 기존 regression을 clean checkout에서 실행합니다. Model이 implementation과 test를 함께 만들면 같은 오해가 둘에 복제될 수 있으므로 spec·기존 behavior와 사람이 만든 boundary·negative fixture를 사용합니다. NIST SSDF가 권고하는 secure development practice처럼 이전 vulnerability regression, input fuzz와 static/dynamic analysis를 risk에 맞게 pipeline에 통합합니다.

Reviewer는 요구사항, architecture, error·authorization·data handling과 dependency license를 확인합니다. Test 통과가 유지보수성·업무 의도와 보안을 모두 보증하지 않습니다. Merge 후 feature flag·canary에서 production-like input과 metric을 보고 issue·base commit, patch·artifact hash, toolchain·test와 승인자를 보존합니다. 회귀 시 previous artifact·config로 rollback합니다.

왜 이런가

Generated code는 실제 권한과 data를 다루는 실행물이므로 자연어 답보다 기존 secure SDLC의 모든 검증을 더 엄격히 적용해야 하기 때문입니다.

언제 문제가 되는가

Model이 만든 code·test를 같은 prompt에서 받고 바로 배포하면 공통 오해, secret 노출·dependency 위험과 production-only 오류를 놓칩니다.

초보자가 자주 하는 오해

Code가 compile되거나 model이 “안전하다”고 설명하면 authorization·business invariant와 vulnerability까지 검증된 것이 아닙니다.

직접 확인하는 방법

Clean sandbox에서 build·기존/negative/security test를 실행하고 code owner가 최소 diff·dependency·rollback을 evidence와 함께 승인했는지 확인하십시오.

Hugging Face 공식 task 설명은 summarization을 긴 text의 짧은 version을 만드는 sequence-to-sequence task로 설명하고 extractive와 abstractive를 구분합니다. Extractive는 원문 문장을 고르므로 표현 추가는 적지만 문맥이 끊길 수 있고, abstractive는 읽기 좋게 새 text를 만들어 원문에 없는 연결·인과를 만들 수 있습니다. 사용 목적에 맞는 유형과 허용 편집 범위를 먼저 정합니다.

긴 input은 model context보다 클 수 있습니다. Truncation이 어느 section을 자르는지 token map으로 확인하고 document structure에 맞춰 chunk합니다. Chunk별 요약을 다시 요약하면 작은 누락·오류가 누적되고 서로 다른 section의 예외가 합쳐질 수 있습니다. Table·footnote·appendix와 최신 revision을 보존하고 summary claim마다 source paragraph ID를 붙입니다.

평가는 핵심 coverage, faithfulness, forbidden addition, critical omission과 readability로 나눕니다. 날짜·금액·단위·고유명사, 부정·조건·예외와 면책은 parser·source lookup으로 대조합니다. ROUGE 같은 overlap과 model judge 하나가 이러한 업무 위험을 대신하지 않습니다. Reviewer는 source와 나란히 보고 claim별 pass·edit·reject를 남깁니다.

사용자 correction을 “취향”과 사실 오류로 분류합니다. Too long·tone 수정과 missing condition·invented fact는 다른 root cause입니다. Document type·length·language별 하위 집합과 빈·중복·contradictory source를 평가합니다. Exact source/model/prompt·chunk·generation config를 고정하고 candidate가 실패한 document를 previous summary pipeline으로 복구합니다.

왜 이런가

요약은 정보를 의도적으로 줄이므로 무엇을 생략해도 되는지와 원문에 없는 내용을 만들지 않는지를 업무가 정의해야 하기 때문입니다.

언제 문제가 되는가

자연스러움과 길이만 평가하면 금액·예외·부정 하나가 빠져도 높은 점수를 받고 실제 결정이 반대로 바뀔 수 있습니다.

초보자가 자주 하는 오해

Abstractive summary가 원문보다 잘 읽히거나 overlap 점수가 높으면 모든 claim이 source에 의해 뒷받침된다는 뜻은 아닙니다.

직접 확인하는 방법

Summary claim별 source paragraph를 열어 숫자·조건·예외를 대조하고 truncation map에 필수 section이 모두 포함됐는지 확인하십시오.

Translation은 text sequence를 다른 언어 sequence로 바꾸는 task입니다. Exact source·target language, script, locale, domain·tone과 target audience를 정합니다. 같은 영어→한국어라도 계약, UI, 기술 문서와 marketing은 용어·높임말·문장 구조가 다릅니다. Model card의 지원 언어와 실제 domain gold set을 확인하고 unsupported·mixed-language input을 보류합니다.

Approved glossary, product·API name과 do-not-translate list를 versioning합니다. Number·currency·unit·date, placeholder·HTML tag·Markdown link와 code span의 count·identity를 자동 비교합니다. BiDi text, Unicode normalization과 line break가 output format을 깨지 않는지 봅니다. 표·caption·cross-reference numbering은 sentence translation 밖에서 document structure로 검증합니다.

사람 reviewer는 정확성, fluency, terminology, style·locale과 critical omission·addition을 segment별로 판정합니다. 전문 분야는 해당 domain·언어를 아는 reviewer가 필요합니다. Back-translation이나 다른 model 간 합의는 오류 단서를 줄 수 있지만 같은 잘못된 뜻을 되돌릴 수 있어 source-target 대조를 대신하지 않습니다. 법적·안전·의료 output은 승인 전 draft입니다.

Document consistency를 봅니다. 같은 term·actor와 pronoun이 장마다 달라지거나 표 heading·footnote가 누락될 수 있습니다. Translation memory·glossary와 context window를 사용하되 오래된 approved phrase가 새 source revision과 충돌하지 않는지 확인합니다. Source·target hash, segment ID·model/config, automatic flags와 reviewer edit를 보존하고 language/domain별 regression을 실행합니다.

왜 이런가

번역은 단어 치환이 아니라 문서·domain 의미를 다른 언어로 보존하는 작업이라 유창성만으로 승인할 수 없기 때문입니다.

언제 문제가 되는가

문장별 자연스러움만 보면 product term·placeholder·표 번호와 계약의 부정·예외가 문서 전체에서 달라질 수 있습니다.

초보자가 자주 하는 오해

Back-translation이 source와 비슷하거나 bilingual model 점수가 높으면 전문 reviewer와 source 대조가 불필요한 것은 아닙니다.

직접 확인하는 방법

Gold document에서 glossary·number·placeholder parity 자동 test와 전문 reviewer의 segment error taxonomy·document consistency를 함께 확인하십시오.

OCR engine과 multimodal model의 document 설명은 다른 output입니다. “식당 영수증”이라는 설명은 vendor·date·tax·total 숫자의 정확성을 보장하지 않습니다. Tesseract 공식 guide는 rescaling, binarization, noise removal, skew·border와 page segmentation이 품질에 영향을 준다고 설명합니다. Input image의 DPI·focus·rotation·background와 table·single line·sparse layout을 분류합니다.

Preprocessing recipe를 versioning하고 raw image와 OCR engine이 실제 본 image를 함께 보존합니다. Auto deskew가 작은 글씨를 자르거나 threshold가 얇은 획을 없앨 수 있으므로 한 setting을 모든 document에 적용하지 않습니다. Page segmentation mode와 language data, OCR version을 exact하게 기록하고 receipt·form·table profile을 분리 평가합니다.

Metric은 character·word error와 field exact match, table structure로 나눕니다. Total 한 자리, bank account·invoice ID와 checkbox 상태는 전체 CER이 낮아도 치명적일 수 있어 independent gate입니다. Bounding box·page를 유지하고 subtotal+tax=total, date range·ID checksum과 allowed currency를 code로 검증합니다. Conflict·low confidence는 source crop과 함께 사람 queue로 보냅니다.

Vision LLM 후처리가 OCR 오류를 자연스럽게 고칠 수 있지만 원문과 다른 값을 만들 수도 있습니다. Correction마다 original OCR, normalized value와 rule·reviewer를 남깁니다. 실제 scanner·mobile camera, blur·shadow·rotation·small font와 개인정보 redaction을 test set에 포함합니다. Raw document 접근·retention을 제한하고 candidate preprocessing/model failure를 previous pipeline으로 되돌립니다.

왜 이런가

OCR 오류는 image 획·layout과 전처리에서 생기며 숫자 한 글자가 업무 결과를 바꿀 수 있어 field 중심 평가가 필요하기 때문입니다.

언제 문제가 되는가

전체 CER와 자연어 설명만 보면 total·ID·table column 오류가 평균에 숨고 LLM 후처리가 잘못된 값을 그럴듯하게 확정합니다.

초보자가 자주 하는 오해

더 큰 vision model이나 더 강한 binarization을 쓰면 모든 문서 layout·작은 글씨와 field 계산이 자동 해결되는 것은 아닙니다.

직접 확인하는 방법

Document type·capture 조건별 raw/crop에서 critical field exact match와 bounding box·계산 conflict를 확인하고 사람 correction 원인을 추적하십시오.

Hugging Face 공식 ASR task는 speech signal을 text output으로 mapping하는 일입니다. Audio file 하나의 성공을 회의실 전체로 일반화하지 않습니다. Sample rate, channel·codec, language·accent, microphone 거리, noise·overlap과 segment length를 기록합니다. Stereo를 mono로 바꾸거나 resample·silence split한 recipe와 exact ASR model·decoder를 manifest에 둡니다.

WER는 substitution, deletion과 insertion을 reference word 수에 대해 요약하는 중요한 metric이지만 normalization에 따라 값이 달라집니다. Punctuation·number spelling과 casing rule을 고정하고 raw와 normalized transcript를 둘 다 보존합니다. 제품명·사람 이름·날짜·금액·부정 표현과 명령은 별도 critical term recall·exact match로 측정합니다.

Diarization과 timestamp는 별도 오류원입니다. 누가 말했는지가 틀리면 action owner가 바뀌고 overlap에서 짧은 반대 의견이 삭제될 수 있습니다. Segment start/end와 speaker ID를 transcript·summary claim에 연결하고 사람이 클릭해 원본 audio를 들을 수 있게 합니다. ASR 뒤 LLM이 문맥으로 숫자를 바꿔도 source audio와 reviewer 승인 없이는 확정하지 않습니다.

회의 workflow에는 transcript readability뿐 아니라 action item precision·recall, reviewer correction time과 final approval이 필요합니다. Noise·remote speaker·code-switching·긴 silence와 empty/corrupt audio를 하위 집합으로 둡니다. Consent, recording notice·voice data access와 retention을 적용하고 model·vocabulary update 뒤 이전 failure clip과 전체 회귀를 반복합니다.

왜 이런가

같은 WER라도 이름·숫자·부정과 speaker 오류의 업무 피해가 달라 source span과 critical term 평가가 필요하기 때문입니다.

언제 문제가 되는가

Clean studio WER만 보면 실제 회의의 overlap·잡음·고유명사와 잘못된 action owner를 놓치고 요약이 오류를 숨깁니다.

초보자가 자주 하는 오해

Transcript가 읽기 좋거나 ASR 뒤 LLM이 문장을 교정하면 원래 음성의 숫자·speaker·의도가 정확히 복구됐다는 뜻은 아닙니다.

직접 확인하는 방법

실제 microphone·noise별 gold audio에서 WER와 critical term·speaker·timestamp, action item과 사람 correction time을 각각 측정하십시오.

Hugging Face 공식 TTS task는 text에서 natural-sounding speech를 생성하며 여러 language·speaker model이 존재한다고 설명합니다. Exact model·speaker/reference, language, sample rate, text normalization과 synthesis config를 고정합니다. Model이 audio array를 반환했다는 사실은 해당 언어 발음, 긴 문단 일관성과 실제 playback device의 명료도를 보증하지 않습니다.

Test script에는 숫자·날짜·단위, 영문 acronym, Korean·foreign name, URL·code와 punctuation·quote를 넣습니다. Pronunciation error, intelligibility, unexpected pause·speed, clipping·silence와 loudness를 분리합니다. Waveform peak·audio 길이를 code로 검사하고 headphone·phone speaker·background noise에서 사람이 듣습니다. ASR round-trip은 보조 신호이지 독립 청취를 대신하지 않습니다.

Voice cloning reference에는 speaker의 명시적 consent, license·allowed purpose, 보존·삭제·철회와 보상 조건을 둡니다. Colleague·celebrity의 공개 audio를 permission으로 오인하지 않습니다. Fraud·impersonation 위험이 있는 전화·public announcement는 explicit approval·disclosure와 access·audit를 강화합니다. Voice file과 embedding을 biometric-like sensitive asset으로 취급합니다.

Output audio는 합성 여부와 publisher context를 적절히 표시합니다. Script·model, voice authorization, edit action과 final asset hash를 provenance로 연결합니다. C2PA 같은 Content Credentials는 source·history trust signal을 제공할 수 있지만 발음·내용의 사실성 자체를 증명하지 않습니다. Canary audience에서 issue를 수집하고 previous approved audio로 rollback할 수 있게 합니다.

왜 이런가

TTS는 사람 identity와 청취 가능한 media를 만들므로 text 정확성만이 아니라 실제 발음·audio 품질과 동의·사칭 위험을 다뤄야 하기 때문입니다.

언제 문제가 되는가

Naturalness sample 하나만 들으면 숫자·이름 오류, 긴 audio clipping과 reference speaker 권리·disclosure 문제를 배포 후 발견합니다.

초보자가 자주 하는 오해

Public audio가 있거나 local에서 합성했다는 사실은 voice clone 사용 동의·license와 공개 권리를 자동 부여하지 않습니다.

직접 확인하는 방법

Critical pronunciation·audio metric과 독립 청취, voice consent·allowed purpose·deletion, disclosure·asset provenance를 모두 확인하십시오.

Evaluation manifest에는 raw source set, expected stage output, exact preprocessing·model·validator와 reviewer rubric을 둡니다. 정상뿐 아니라 corrupt·long·table·small text, dialect·noise·overlap, number·name·negative, insecure code와 voice rights missing case를 포함합니다. Candidate마다 같은 split을 최소 여러 번 실행하고 data leakage와 benchmark-only tuning을 막습니다.

Metric은 stage quality, critical field·term, end-to-end task success, p50·p95, resource와 human correction rate·time으로 나눕니다. Code security regression, summary invented fact, OCR total, ASR action owner, TTS consent 같은 필수 gate는 0 failure를 요구할 수 있습니다. 자동 점수와 사람 rubric disagreement를 기록하고 결과를 본 뒤 threshold를 낮추지 않습니다.

W3C WCAG 안내처럼 prerecorded synchronized media에는 dialogue뿐 아니라 중요한 sound information을 포함한 caption을 제공합니다. ASR draft를 그대로 publish하지 않고 speaker·time sync와 의미를 검수합니다. Transcript·caption은 hearing access뿐 아니라 검색·검토 evidence가 되지만 privacy·retention을 따릅니다. Image·document에도 필요한 alt·source view를 제공해 reviewer가 원본을 확인할 수 있게 합니다.

Offline gate 뒤 shadow·limited canary에서 실제 user correction·drop-off와 incident를 관측합니다. Previous preprocessing/model/validator/UI와 approved code·document·audio asset으로 rollback하고 같은 failure가 회복되는지 시험합니다. Owner, limitation, rights·consent expiry와 input·model·policy 변화 같은 재검토 trigger를 evidence에 남깁니다. 전체 결론은 exact workflow version과 task별 pass·hold입니다.

왜 이런가

여러 stage와 사람이 연결되므로 최종 품질뿐 아니라 correction 부담·접근성·권리와 전체 compatible rollback이 운영 성공을 결정하기 때문입니다.

언제 문제가 되는가

평균 end-to-end 점수만 보면 critical stage 오류와 늘어난 사람 교정, caption·voice consent와 previous schema incompatibility가 숨습니다.

초보자가 자주 하는 오해

각 model의 공개 benchmark가 높거나 stage별 demo가 성공하면 실제 연결 pipeline·사람 UX와 publish 권리까지 승인된 것은 아닙니다.

직접 확인하는 방법

동일 source set의 stage·critical·correction·p95 gate와 caption·rights를 3회 이상 확인하고 previous full pipeline으로 failure를 복구하십시오.