AI 엔지니어링 기초 정리: 프롬프트·RAG·워크플로·에이전트, 언제 무엇을 쓸까

핵심 메시지

• AI 엔지니어는 모델을 만드는 사람이 아니라 모델 주변의 도구·검색·에이전트 구조를 설계하는 사람이며, 핵심 역량은 아키텍처 판단이다.
• 프롬프트 → 컨텍스트 캐싱 → RAG → 워크플로 → 에이전트 순으로 올라가되, 평가 기준을 통과하는 가장 낮은 단계에서 멈추는 것이 정답이다.
• 컨텍스트 창이 100만 토큰이어도 100만 토큰이 모두 유용하지는 않다. 토큰을 늘리기보다 압축하고 걸러내는 것이 엔지니어의 부가가치다.
• 평가 세트를 먼저 만들지 않으면 개선하고 있는지 개선하는 느낌만 받는지 구분할 수 없다.
• 언어모델은 새로운 공격면을 만들기 때문에 입력·정책·실행·출력·모니터링 각 계층마다 가드레일이 필요하다.

쉽게 이해하기

발표자는 언어모델을 이해하는 데 필요한 최소 지식으로 데이터, 토큰, 임베딩, 트랜스포머 네 가지를 꼽는다. 모델은 글자를 보지 못하고 토큰이라는 번호만 보며, 그 번호를 다차원 공간의 좌표(임베딩)로 바꿔 단어 사이의 거리로만 의미를 파악한다. 트랜스포머 안에서는 단어끼리 서로 참조하는 어텐션 블록과 각 표현을 개별적으로 다듬는 피드포워드 블록이 반복되고, 그 결과로 한 번에 한 토큰씩 예측이 이어진다.

학습은 사전학습, 지시 미세조정, 강화학습 정렬의 세 단계로 나뉜다. 사전학습만 거친 모델은 질문에 답하는 대신 문장을 이어 쓰려 하고, 지시 미세조정을 거쳐야 비로소 지시를 따르며, 강화학습 단계에서 답변의 형식과 거절 기준 같은 태도가 잡힌다. 이후 필요하면 큰 모델을 작은 모델로 증류해 비용과 지연을 줄인다.

강연의 절반은 한계를 다룬다. 환각과 편향, 지식 컷오프뿐 아니라 긴 컨텍스트 문제를 특히 강조한다. 긴 컨텍스트 모델은 책 전체를 이해시키는 대신 책 속에 사실 하나를 심어 두고 그것을 찾게 하는 방식으로 훈련되기 때문에, 정보를 많이 넣을수록 전체를 활용해 답할 가능성은 오히려 떨어진다는 설명이다.

그래서 제안하는 것이 사다리식 접근이다. 먼저 평가용 질문·답변 세트를 만들고 프롬프트와 예시만으로 통과하는지 본다. 통과하지 못하면 미리 아는 정적 자료는 컨텍스트 캐싱으로 붙이고, 사용자가 무엇을 물을지 모를 때만 RAG를 쓴다. 단계가 오른쪽으로 갈수록 자율성은 늘지만 비용·지연·디버깅 난이도가 함께 오르고 통제력은 줄어든다.

메모리와 보안도 실무 항목으로 다룬다. 메모리는 최근 대화(작업 기억), 과거 세션(일화 기억), 사용자 선호(프로필 기억)의 세 층으로 나눠 관리하고, 출처와 확신도가 붙은 사실만 저장하며 읽기·쓰기를 명시적으로 호출해 추적 가능하게 하라고 권한다. 보안 쪽에서는 입력 필터링, 주제 제한, 출력 검열, 형식 검증, 도구 권한 최소화 같은 가드레일을 계층별로 배치하라고 정리한다.

주요 인사이트

• 에이전트를 쓸 신호는 '다음 단계가 지금 단계에서 알게 될 내용에 달려 있을 때'다. 단계와 순서를 미리 알 수 있으면 워크플로가 더 싸고 빠르고 디버깅하기 쉽다.
• 에이전트 루프에는 반드시 종료 조건이 필요하며, '결과가 충분히 좋아질 때까지'처럼 주관적인 기준보다 3회 같은 고정 반복 횟수가 실제로는 더 잘 작동했다고 말한다.
• 에이전트는 얇게, 도구는 두껍게 두는 편이 낫다. 에이전트 수를 늘리기보다 하나의 범용 에이전트가 잘 만든 도구를 쓰게 하고, 가능하면 도구를 MCP로 노출해 어느 클라이언트에서든 쓰게 하라는 조언이다.
• 미세조정은 새 지식을 넣는 수단으로는 약하다. 지식은 RAG나 캐싱으로 넣고, 미세조정은 프롬프트가 실패했고 실제 운영과 같은 라벨 데이터가 이미 많을 때, 혹은 로컬 모델로 프라이버시를 지켜야 할 때 선택하라고 본다.
• 링크드인이 스킬 적합도 챗봇을 내놨을 때 '적합하지 않다'는 답만 돌려준 사례를 든다. 적합 여부는 맞혔지만 사용자가 원한 '왜'와 '어떻게'가 빠졌고, 이는 평가가 실제 사용자 상호작용을 반영하지 못하면 생기는 실패라고 짚는다.

자주 묻는 질문

관련 AI 소식