LLM을 제대로 쓰는 팀의 공통점: 토큰·컨텍스트·확률을 업무 판단으로 바꾸는 법
LLM의 내부 원리를 모두 배워야 하는 것은 아니지만, 토큰·컨텍스트·확률·평가를 모르면 비용과 품질을 감으로 운영하게 됩니다. 비개발자와 개발자가 함께 사용할 수 있는 실무 언어로 정리했습니다.
한 줄 답변: 팀에 필요한 LLM 리터러시는 모델 구조를 암기하는 일이 아니라 입력이 토큰과 비용으로 바뀌고, 제한된 컨텍스트 안에서 확률적으로 출력되며, 품질은 평가셋과 사람 검토로 확인된다는 사실을 업무 설계에 반영하는 능력이다.
AI를 자주 쓰는 팀에서도 토큰, 컨텍스트, temperature, 평가라는 단어는 개발팀의 영역으로 남아 있습니다. 그러다 비용이 예상보다 늘거나, 같은 질문에 답이 달라지거나, 긴 문서를 넣었는데 중요한 조건이 빠질 때 원인을 찾지 못합니다. 모든 사람이 모델을 직접 학습할 필요는 없지만, 업무를 설계하는 사람은 모델의 한계를 알아야 합니다.
토큰은 왜 업무 비용과 연결되는가?
모델은 글자 수가 아니라 토큰 단위로 입력과 출력을 처리합니다. 한국어와 코드, 표, JSON은 토큰화 방식이 다를 수 있고, 같은 문서라도 전처리 방식에 따라 길이가 달라집니다. 중요한 건 정확한 단가를 외우는 것이 아니라 업무별 입력·출력·재시도를 기록하는 것입니다.
| 관찰값 | 업무에서 묻는 질문 |
|---|---|
| 입력 토큰 | 매 요청에 같은 자료를 다시 보내고 있는가? |
| 출력 토큰 | 다음 시스템이 쓰지 않는 설명을 만들고 있는가? |
| 재시도 | 오류를 고치지 않고 같은 요청을 반복하는가? |
| 도구 호출 | 검색·OCR·임베딩 비용을 빼먹었는가? |
컨텍스트 윈도우가 크다고 모든 것을 넣으면 안 된다
긴 컨텍스트는 더 많은 자료를 넣을 수 있다는 뜻이지, 모든 자료를 정확히 기억한다는 뜻은 아닙니다. 문서가 길어질수록 서로 다른 적용 범위가 섞이고 중요한 조건이 묻힐 수 있습니다. 검색·요약·상태 저장을 분리해 필요한 구간만 전달하는 이유입니다.
확률적 출력은 업무 계약으로 통제한다
같은 입력에 항상 같은 문장이 나온다고 가정하면 자동화가 불안정해집니다. 다음 단계가 필요한 필드, 허용된 값, 모를 때의 반환값, 확신도가 낮을 때의 행동을 출력 계약으로 정합니다. 형식이 맞아도 내용이 사실이라는 뜻은 아니므로 근거와 평가를 함께 둡니다.
| 계약 | 예시 |
|---|---|
| 필수 필드 | category, evidence, next_action |
| 허용 값 | urgent / normal / unknown |
| 모름 처리 | unknown과 사람 검토 대기 |
| 근거 | 원문 구간 또는 문서 ID |
| 외부 행동 | 승인 없이는 발송하지 않음 |
모델 비교는 취향이 아니라 동일 조건 평가다
'이 모델이 더 똑똑하다'는 말은 업무 판단에 부족합니다. 동일한 입력, 동일한 출력 계약, 동일한 평가셋, 동일한 제한 시간과 비용 조건에서 비교해야 합니다. 모델의 일반적인 순위를 선언하기보다 내 업무에서 어떤 오류가 줄고 어떤 비용이 늘었는지 기록합니다.
비개발자도 알아야 할 최소 평가 언어
- 정확성: 정답이나 완료 조건을 만족했는가
- 완결성: 필수 정보가 빠지지 않았는가
- 근거성: 사람이 원문으로 확인할 수 있는가
- 일관성: 같은 유형에서 결과가 흔들리지 않는가
- 안전성: 금지 행동과 민감정보 노출을 피했는가
- 비용성: 사람 재작업까지 포함해 감당 가능한가
평가 항목을 업무 언어로 바꾸면 개발자와 실무자가 같은 결과를 놓고 이야기할 수 있습니다.
LLM을 설명하는 문장이 운영을 망친다
'모델이 이해했다', '거의 사람처럼 판단한다', '최신 정보를 알고 있다' 같은 표현은 운영 기준이 아닙니다. 무엇을 입력했고 어떤 근거를 사용했으며 어떤 조건에서 실패하는지를 말해야 합니다. 팀 내부 문서에서 과장 표현을 줄이는 것만으로도 기대와 실제의 간극이 작아집니다.
리터러시 교육의 완료 조건
교육을 들었는지가 아니라 업무 하나를 입력·출력·비용·실패·평가로 설명할 수 있는지가 완료 조건입니다. 실무자는 결과를 검수하는 기준을 만들고, 개발자는 그 기준을 로그와 테스트로 구현해야 합니다.
2주 파일럿 체크리스트
- 팀이 자주 쓰는 LLM 업무 하나를 골라 입력·출력·재시도·도구 호출을 기록한다.
- 대표 입력 30건과 필수 결과 필드를 정해 골든셋을 만든다.
- 같은 조건에서 모델 또는 프롬프트 변경 전후의 품질·비용·지연을 비교한다.
- 오답을 사실 오류·누락·형식 오류·안전 오류로 분류한다.
- 팀 문서에 업무별 출력 계약과 사람 검토 기준을 남긴다.
LLM 리터러시는 어려운 수식을 많이 아는 것이 아닙니다. 토큰과 비용, 컨텍스트와 정보 선택, 확률적 출력과 평가, 모델의 가능성과 업무의 책임을 연결해서 말할 수 있는 능력입니다. 이 공통 언어가 있어야 도입 논의가 감이 아니라 실험으로 바뀝니다.
공식 참고 자료
자주 묻는 질문
비개발자도 토큰을 알아야 하나요?
정확한 토큰화 구현까지 알 필요는 없지만 입력·출력 길이와 재시도가 비용과 지연에 영향을 준다는 점은 알아야 업무를 설계할 수 있습니다.
컨텍스트가 크면 답변이 항상 좋아지나요?
아닙니다. 자료가 많아질수록 오래된 정보와 적용 범위가 섞이고 중요한 조건이 묻힐 수 있습니다. 필요한 구간을 검색·선별해 전달해야 합니다.
같은 질문에 답이 달라지는 것이 문제인가요?
모든 업무에서 문제는 아니지만 분류·추출·외부 발송처럼 반복성과 예측 가능성이 필요한 업무에는 출력 계약과 평가 기준이 필요합니다.
모델을 비교할 때 무엇을 같게 해야 하나요?
입력, 출력 형식, 평가셋, 시간 제한, 비용 조건을 같게 두고 품질·누락·안전·사람 재작업을 비교해야 합니다.
LLM 교육의 완료 조건은 무엇인가요?
팀이 대표 업무 하나를 입력·출력·비용·실패·평가 관점으로 설명하고 사람 검토 기준까지 문서화할 수 있으면 실무 교육의 목표에 도달한 것입니다.
우리 팀의 AI 업무를 어디까지 자동화할 수 있는지, 그리고 어떤 승인·로그·평가가 필요한지 먼저 점검해보세요.
AX 셀프리뷰 시작하기