| AI 적용 판단 |
과제에 AI가 필요한지, 필요하다면 어떤 형태가 가장 단순한지, 지금 만들 조건이 갖춰졌는지를 정하는 일. |
| 해법의 사다리 |
맨 아래 칸의 규칙·조회부터 검색, 분류·예측 모델, 생성 모델 호출, 워크플로, 맨 위 칸의 에이전트까지 가벼운 해법에서 무거운 해법 순으로 세운 틀. 아래 칸으로 목적을 이룰 수 있으면 위 칸을 고르지 않는다. |
| 규칙·조회 |
입력과 규칙이 정해져 결과가 하나인 일을 조건 분기나 데이터베이스 조회로 처리하는 방식. |
| 검색 증강 생성 |
검색으로 근거 문서를 찾고 그 근거에 묶어 답을 생성하는 구성. 모델이 모르는 사내 문서나 최신 정보를 근거로 답을 풀어 써야 할 때 쓰며, 원문 확인만 필요하면 검색으로 충분하다. |
| 워크플로 |
LLM과 도구를 미리 정한 코드 경로로 엮은 시스템(Anthropic의 정의). |
| 에이전트 |
LLM이 스스로 과정과 도구 사용을 정하는 시스템. 단계 수를 예측할 수 없는 열린 문제에 쓴다. |
| 라우팅 |
입력을 분류해 전문화된 후속 처리로 보내는 워크플로 형태. |
| 평가자-최적화자 |
한 호출이 결과를 만들고 다른 호출이 평가와 피드백을 주는 반복 구조. 평가 기준이 분명할 때 쓴다. |
| 자동화와 보조 |
사람의 일을 대신하는 것(자동화)과 사람의 일을 돕는 것(보조). 위험이 크면 사람이 통제권을 쥐는 보조가 흔하다. |
| 고영향 인공지능 |
AI 기본법 제2조제4호가 정한 영역(채용·대출 심사 등의 판단·평가, 공공서비스 자격 결정, 학생 평가 등)에서 활용되며 생명·안전·기본권에 중대한 영향을 줄 수 있는 인공지능시스템. |
| 생성형 인공지능 |
입력 데이터의 구조와 특성을 모방해 글, 소리, 그림, 영상 등을 생성하는 인공지능시스템(AI 기본법 제2조제5호). |
| 인공지능사업자 |
인공지능을 개발해 제공하는 자(개발사업자)와 그것을 이용해 제품·서비스를 제공하는 자(이용사업자). 국가기관등도 포함된다. |
| 사전 고지 |
고영향·생성형 인공지능을 이용한 제품·서비스가 그 인공지능에 기반해 운용된다는 사실을 이용자에게 미리 알리는 의무(AI 기본법 제31조제1항). |
| 결과물 표시 |
생성형 인공지능의 결과물이 생성형 인공지능으로 생성되었다는 사실을 표시하는 의무(제31조제2항). |
| 고영향 확인 |
사업자가 고영향 해당 여부를 사전에 검토하고, 필요하면 과학기술정보통신부장관에게 확인을 요청할 수 있게 한 절차(제33조). |
| 자동화된 결정 |
완전히 자동화된 시스템(AI 포함)으로 개인정보를 처리해 이루어지는 결정(개인정보 보호법 제37조의2). 행정기본법 제20조에 따른 행정청의 자동적 처분은 제외한다. 권리·의무에 중대한 영향을 미치면 거부권이 생긴다. |
| 성공 기준 |
기능이 성공했는지 판정하는 기준. 지표, 데이터, 기준값, 기준선, 측정 방법을 갖춰야 한다. |
| 출시 차단 기준 |
넘지 못하면 다른 지표가 좋아도 출시하지 않는 기준. 법·계약 위반이나 사용자 피해로 이어지는 항목에 둔다. |
| 개선 목표 |
출시 뒤 추적하며 끌어올릴 수준. 사용에 지장이 없는 품질 항목에 둔다. |
| 기준선 |
비교의 출발점이 되는 현재 수준. 사람이나 기존 시스템의 성능. |
| 정밀도 |
양성으로 판정한 것 가운데 실제 양성의 비율. 잘못 잡으면 피해가 큰 기능에서 지킨다. |
| 재현율 |
실제 양성 가운데 양성으로 잡아낸 비율. 놓치면 피해가 큰 기능에서 지킨다. |
| 거짓 양성·거짓 음성 |
아닌 것을 맞다고 판정한 오류와, 맞는 것을 놓친 오류. 두 비용을 따져 지킬 지표를 정한다. |
| F1 점수 |
정밀도와 재현율을 하나로 묶은 조화 평균 지표. |
| 입력 계약 |
기능이 받는 입력의 범위(언어, 형식, 길이, 필수 정보)와 범위 밖 입력의 처리 규칙. |
| 출력 계약 |
기능이 돌려주는 결과의 형식, 빈 값 처리, 검증 실패 처리 규칙. |
| 구조화 출력 |
응답이 지정한 JSON 스키마를 따르도록 제약하는 기능. 거절이나 max_tokens 도달 시에는 어긋날 수 있다. |
| 스키마 |
결과의 필드 이름, 형식, 필수 여부를 정한 명세. |
| TTFT |
요청을 보낸 뒤 첫 토큰이 나오기까지의 시간. 사용자가 화면 앞에서 기다리는 기능의 체감 지연을 좌우한다. |
| 스트리밍 |
전체 출력이 끝나기 전에 응답을 보내기 시작하는 방식. 전체 시간은 같아도 체감 반응성을 높인다. |
| 일괄 처리 |
즉시 응답이 필요 없는 대량 요청을 모아 비동기로 처리해 비용과 처리량을 개선하는 방식. 예를 들어 Anthropic의 Message Batches API는 비용을 50% 줄이고 대부분 1시간 안에 끝나며, 24시간 안에 끝나지 않으면 만료된다(2026-10-22 확인). |
| max_tokens |
출력 토큰 수의 상한. 닿으면 문장이나 구조화 데이터 중간에서 생성이 멈추므로, 길이 조절이 아니라 비용·지연의 상한으로 쓰고 중단 사유를 확인한다. |
| 평가 |
모델이나 기능의 성능을 재는 구조화된 시험. 평가 세트, 채점 방식, 성공 기준으로 이뤄진다. |
| 평가 세트 |
평가에 쓰는 입력과 기대 결과의 묶음. 실제 사용 분포를 대표해야 한다. |
| 경계 사례 |
관련 없는 입력, 지나치게 긴 입력, 해로운 입력, 사람도 판정이 갈리는 애매한 사례처럼 실패하기 쉬운 사례. |
| 보류 세트 |
고칠 때 보지 않고 최종 판정에만 쓰는 평가 세트의 일부. 과적합을 잡는다. |
| 과적합 |
같은 평가 세트에 맞춰 고친 결과, 점수가 실제 성능보다 높아지는 현상. |
| 코드 채점 |
정확 일치, 문자열 포함, 형식 검증처럼 코드로 판정하는 채점. 가장 빠르고 믿을 만하다. |
| LLM 채점 |
루브릭을 준 LLM이 결과를 판정하는 채점. 복잡한 판단에 맞지만 사람과 대조해 신뢰도를 먼저 확인해야 한다. |
| 사람 채점 |
사람이 판정하는 채점. 품질의 기준이지만 느리고 비싸 기준 데이터와 보정에 쓴다. |
| 루브릭 |
평가 항목별 판정 기준과 점수 척도를 구체적으로 적어 채점의 일관성을 높이는 채점 기준표. |
| 위치 편향 |
LLM 채점기가 응답의 제시 순서에 따라 판정을 달리하는 경향. 순서를 바꿔 가며 쌍 비교로 줄인다. |
| 블라인드 비교 |
평가자가 어느 버전인지 모르는 상태로 두 결과를 나란히 비교하는 평가. |
| 역량 평가 |
아직 잘 못하는 과제로 구성해 낮은 통과율에서 시작하는 평가. |
| 회귀 평가 |
이미 잘하던 일을 계속 잘하는지 확인하는 평가. 통과율이 거의 100%여야 한다. |
| 평가 포화 |
평가 과제를 모두 통과해 더 이상 개선 여지를 보여 주지 못하는 상태. |
| pass@k |
k번 시도 가운데 적어도 한 번 성공할 확률. |
| pass^k |
k번 시도가 모두 성공할 확률. 매번 같은 품질이 필요한 기능에 맞다. |
| 오프라인 평가 |
준비한 평가 세트로 사용자에게 내보내지 않고 결과를 재는 평가. |
| 온라인 지표 |
실제 운영에서 재는 지표(재생성, 상담 전환, 이탈, 신고, 구매 전환). |
| A/B 실험 |
사용자를 무작위로 나눠 두 안의 지표를 비교하는 실험. 위험이 낮고 트래픽이 충분할 때 쓴다. |
| 지어낸 답 |
근거 없는 내용을 사실처럼 만들어 내는 실패(할루시네이션). 줄일 수 있지만 없앨 수는 없다. |
| 과잉 거절 |
답할 수 있는 질문까지 거절하는 실패. 틀린 답의 비율에는 잡히지 않으므로 답할 수 있는 질문의 거절률을 따로 잰다. |
| 형식 오류 |
약속한 출력 형식을 지키지 않아 화면이나 연동이 깨지는 실패. |
| 지수 백오프 |
다시 시도할 때마다 기다리는 간격을 늘려 가는 재시도 방식. |
| 단계적 축소 |
AI 기능이 멈춰도 핵심 업무가 더 단순한 경로로 계속되게 하는 설계. |
| 사전 승인 |
모든 결과를 사람이 확인한 뒤 내보내는 개입 방식. |
| 조건부 이관 |
확신이 낮거나 위험 조건에 걸린 건만 사람에게 보내는 개입 방식. |
| 사후 표본 점검 |
자동 반영 뒤 일부를 정기적으로 점검하는 개입 방식. |
| 이의 제기 처리 |
결과를 받은 사람이 요청하면 사람이 다시 처리하는 개입 방식. |
| 형식적 승인 |
검토자가 근거나 권한 없이 거의 모든 결과를 그대로 승인해 감독이 작동하지 않는 상태. |
| 자동화 편향 |
사람이 AI의 추천을 따져 보지 않고 받아들이는 경향. 형식적 승인의 원인이 된다. |
| 엄격한 도구 입력 |
도구 이름과 입력값이 정의한 스키마를 따르게 하는 설정(strict tool use). |
| 신뢰 보정 |
사용자가 AI를 어떤 상황에서는 믿고 필요할 때는 다시 확인하도록 신뢰 수준을 맞추는 일. |
| 암묵적·명시적 피드백 |
로그에 남는 사용자 행동(암묵적)과 사용자가 일부러 남기는 의견(명시적). |
| 배경 오류 |
시스템이 잘못 작동하는데 사용자도 시스템도 오류로 인식하지 못하는 실패(Google PAIR의 background errors). 조용한 실패라고도 부른다. |
| 섀도 테스트 |
실제 요청의 복사본을 새 버전에 보내되 사용자에게는 기존 버전의 결과만 돌려주는 시험. |
| 카나리 |
변경을 작은 비율의 실제 트래픽에 시간 제한을 두고 먼저 배포해 대조군과 비교하며 평가하고, 문제가 없으면 노출을 단계적으로 넓히는 방법. |
| 대조군 |
같은 기간에 기존 버전을 쓰는 비교 집단. |
| 중단 기준 |
출시 전에 정한, 넘으면 확대를 멈추고 되돌리는 지표와 기준값. 판정 최소 표본을 함께 정한다. |
| 기능 플래그 |
코드 배포 없이 기능을 켜고 끄거나 노출 범위를 바꾸는 장치. |
| 가드레일 지표 |
실험이나 출시에서 목표 지표가 좋아지더라도 허용 한도를 넘어 나빠지면 안 되는 지표(신고율, 환불률 등). |
| 모델 수명 주기 |
모델의 지원·사용 중단 상태와 그 변화. 예를 들어 Anthropic은 Active, Legacy, Deprecated, Retired로 나누고 은퇴한 모델로 보낸 요청은 실패한다. 상태와 일정은 벤더와 제공 플랫폼마다 확인한다. |
| 회고 |
사고의 경위, 영향, 조치, 원인, 재발 방지 조치를 담은 기록과 그 논의. |
| 비난 없는 회고 |
개인이나 팀을 탓하지 않고 기여 원인을 찾는 데 집중하는 회고. |