이 AI 용어들 들어봤지만 모르겠어? 이제 그만 끝내자

AI 용어의 폭증은 기술 자체의 빠른 추상화 계층 분화에서 비롯된다. 과거에는 '머신러닝', '딥러닝' 정도의 큰 범주만 알면 됐지만, 트랜스포머 아키텍처가 표준이 된 이후 토큰화(tokenization), 임베딩(embedding), 어텐션(attention) 같은 모델 내부 동작을 가리키는 용어부터, 컨텍스트 윈도우(context window)·온도(temperature)·토큰처럼 추론 시점에 개발자가 직접 제어하는 파라미터, 그리고 RAG(검색 증강 생성)·파인튜닝·프롬프트 엔지니어링·에이전트처럼 애플리케이션 설계 패턴을 지칭하는 용어까지 계층별로 쏟아지고 있다. 여기에 환각(hallucination), 그라운딩(grounding), 가드레일(guardrail)처럼 신뢰성·안전성 영역의 용어와 MCP·임베딩 벡터 DB 같은 인프라 용어가 더해지면서, 같은 '모델'이라는 단어도 맥락에 따라 전혀 다른 추상화 수준을 가리키게 됐다. 이 용어들이 단순한 마케팅 신조어가 아니라 실제 동작 원리와 직결된 개념이라는 점이 핵심이다. 예컨대 컨텍스트 윈도우는 모델이 한 번에 처리할 수 있는 토큰 수의 물리적 한계이고, temperature는 다음 토큰 확률 분포를 얼마나 평탄하게 만들지를 조절하는 샘플링 파라미터다.

엔지니어 입장에서 이 용어들을 '대충 알고 넘어가는 것'과 '정확히 이해하는 것'의 차이는 곧바로 구현 품질과 비용으로 나타난다. RAG와 파인튜닝을 혼동하면 단순히 최신 정보를 주입하면 될 일에 불필요하게 비싼 학습 파이프라인을 구축하게 되고, 컨텍스트 윈도우와 토큰 과금 구조를 이해하지 못하면 프롬프트에 불필요한 데이터를 채워 넣어 응답 지연과 API 비용을 동시에 키운다. 환각의 발생 메커니즘(모델은 사실을 '조회'하는 게 아니라 그럴듯한 토큰을 '생성'한다)을 이해하지 못한 채 LLM을 결정론적 API처럼 다루면, 프로덕션에서 검증 레이어 없이 출력을 신뢰하는 위험한 설계로 이어진다. 반대로 용어 뒤의 원리를 정확히 알면, '에이전트가 필요한가 아니면 단순 함수 호출로 충분한가', '시스템 프롬프트로 제어할 일인가 가드레일로 막을 일인가' 같은 아키텍처 판단을 근거 있게 내릴 수 있다.

한국 개발자가 실무에서 취해야 할 행동은 명확하다. 첫째, 자신이 쓰는 LLM API 문서를 용어집 삼아 정독하면서 추상화 계층별로 용어를 정리하는 것이 좋다 — 모델 동작 용어(어텐션, 임베딩), 추론 제어 용어(temperature, top-p, max_tokens, 컨텍스트 윈도우), 애플리케이션 패턴 용어(RAG, 툴 콜링, MCP), 안전성 용어(가드레일, 그라운딩)를 섞어 쓰지 말고 구분해야 의사소통과 설계가 명확해진다. 둘째, 용어를 외우는 데 그치지 말고 작은 실험으로 체감하는 것이 중요하다. temperature를 0과 1로 바꿔보며 출력 변화를 관찰하거나, 동일 질문을 RAG 유무로 비교해보는 식으로 개념과 실제 동작을 연결하면 면접·설계 회의에서 '아는 척'이 아닌 실질적 판단이 가능해진다. 셋째, 팀 내에서 용어 정의를 합의해 두는 것을 권한다. '에이전트', '파인튜닝', '프롬프트' 같은 단어는 사람마다 가리키는 범위가 달라 회의에서 미묘한 오해를 낳기 쉬우므로, 프로젝트 위키에 공통 용어집을 두면 커뮤니케이션 비용을 크게 줄일 수 있다.