PALDYNAI LAB
Databricks GenAI Associate

Databricks GenAI Associate 시험 노트개념 정리16 MIN

업무 요구를 모델 태스크와 체인으로 옮기기

말로 적힌 업무 요구를 다섯 태스크와 입력·출력 명세로 바꾸고, 프롬프트 템플릿·retriever·LLM·파서로 체인을 짜고, 프롬프트·RAG·파인튜닝 중 무엇을 고를지 판단하는 법입니다.

이 시험의 응시자 설명에는 「복잡한 요구사항을 다룰 수 있는 작업으로 쪼개는 문제 분해」가 명시되어 있습니다. Design Applications 영역의 두 번째 출제 목표가 그 자리이고, 문항은 대개 업무 요구를 문장으로 던져 놓고 그것을 어떤 모델 태스크와 어떤 체인 구성요소로 옮길지 고르게 합니다. 코드를 몰라도 풀 수 있지만, 요구를 읽고 「이건 분류 두 번과 요약 한 번이다」로 옮기지 못하면 보기 넷이 전부 그럴듯해 보입니다.

다섯 태스크로 옮겨 적기

말로 적힌 요구를 먼저 모델이 아는 태스크 이름으로 바꿉니다. 생성형 AI 애플리케이션에서 쓰는 것이 대개 다섯입니다.

태스크 입력 → 출력 요구에 나오는 말
요약(summarization) 긴 텍스트 → 짧은 텍스트 「핵심만」, 「보고용으로 줄여」
분류(classification) 텍스트 → 정해진 라벨 하나 「부서로 나눠」, 「긴급도를 매겨」
추출(extraction) 텍스트 → 구조화된 필드 「금액과 날짜를 뽑아」, 「표로 만들어」
생성(generation) 지시·자료 → 새 텍스트 「초안을 써」, 「답장을 만들어」
질의응답(QA) 질문 + 근거 → 답 「물어보면 답해」, 「사내 규정을 찾아 줘」

가르는 기준은 출력의 모양입니다. 출력이 정해진 후보 중 하나면 분류, 정해진 필드 묶음이면 추출, 자유로운 글이면 요약이나 생성입니다. 추출과 분류를 섞어 쓰는 오답이 흔한데, 「긴급도 1~5」는 후보가 정해져 있으므로 분류이고 「문의에 적힌 주문번호」는 값이 열려 있으므로 추출입니다.

QA는 나머지 넷과 결이 다릅니다. 근거를 어디서 가져오는가가 함께 정해져야 성립하고, 그 근거를 검색으로 가져오면 그게 RAG입니다. 그래서 요구에 「사내 문서를 보고 답한다」가 들어 있으면 태스크 하나가 아니라 검색과 생성 두 단계로 적어야 합니다.

입력과 출력 명세로 못 박기

태스크 이름을 붙였으면 각 단계를 입력·출력·실패로 적습니다. 이 세 줄이 곧 파이프라인 명세이고, 뒤의 평가와 가드레일이 여기에 매답니다.

단계 입력 출력 실패로 치는 것
1. 분류 문의 원문 category 넷 중 하나 후보 밖의 값, 빈 값
2. 추출 문의 원문 order_id·amount·due_date 원문에 없는 값을 지어냄
3. 검색 분류 결과 + 질문 청크 k개 관련 없는 청크만 옴
4. 생성 질문 + 청크 답변 초안 청크에 없는 사실을 씀

명세를 이렇게 적어 두면 「이 애플리케이션에서 무엇을 평가해야 하는가」라는 문항이 저절로 풀립니다. 3번은 recall@k 같은 검색 지표로, 4번은 근거 기반 여부로 잽니다. 한 단계에 태스크를 둘 넣지 않는 것이 명세의 기본이고, 넣는 순간 실패 원인을 가릴 수 없게 됩니다.

체인은 네 조각의 조립이다

체인(chain)은 정해진 순서로 이어 붙인 처리 단계의 묶음입니다. LLM 애플리케이션에서 쓰는 조각이 넷이고, 시험은 조각의 역할을 묻습니다.

  • 프롬프트 템플릿(prompt template) — 변수 자리를 비워 둔 프롬프트 틀입니다. {{question}}·{{context}}에 값을 꽂아 완성된 프롬프트를 만듭니다.
  • retriever — 질문을 받아 관련 있는 문서 조각을 돌려주는 구성요소입니다. Databricks에서는 Vector Search 인덱스를 감싼 것이 이 자리에 섭니다.
  • LLM — 완성된 프롬프트를 받아 텍스트를 내놓는 모델입니다. Model Serving 엔드포인트가 여기 붙습니다.
  • 출력 파서(output parser) — 모델이 낸 텍스트를 뒤에서 쓸 수 있는 자료형으로 바꿉니다. JSON 문자열을 딕셔너리로 만드는 것이 대표입니다.
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
from langchain_databricks import ChatDatabricks

prompt = ChatPromptTemplate.from_template(
    "아래 자료만 근거로 답하십시오.\n\n자료:\n{context}\n\n질문: {question}"
)
llm = ChatDatabricks(endpoint="databricks-llama-4-maverick", temperature=0)
chain = prompt | llm | StrOutputParser()

순서는 늘 템플릿 → LLM → 파서이고, RAG면 그 앞에 retriever가 붙어 {context} 자리를 채웁니다. 문항이 조각을 뒤섞어 배열 문제로 내면 이 순서로 되돌립니다.

체인과 에이전트(agent)를 가르는 선도 여기 있습니다. 체인은 사람이 순서를 미리 못 박아 둔 것이라 같은 입력이면 같은 경로를 밟고, 에이전트는 어떤 도구를 몇 번 부를지 모델이 그때그때 정합니다. 단계가 정해져 있고 매번 같다면 체인이 더 싸고 빠르며 디버깅도 쉽습니다. 요구에 「질문에 따라 어떤 시스템을 조회할지 달라진다」 같은 말이 있을 때 비로소 에이전트가 필요한 자리이고, 그 도구를 어떻게 정의하는지는 다음 노트에서 다룹니다.

복잡한 요구를 작업으로 쪼개기

요구가 한 문장이어도 태스크는 여럿일 수 있습니다. 「월요일 아침마다 지난주 고객 문의를 모아 팀별 요약 보고서를 만들고, 환불 관련 문의는 따로 표로 뽑아 달라」를 쪼개 보면 이렇습니다.

  1. 지난주 문의를 가져온다 — 모델이 필요 없는 데이터 조회입니다.
  2. 문의마다 팀을 붙인다 — 분류.
  3. 환불로 분류된 것에서 주문번호·금액·요청일을 뽑는다 — 추출.
  4. 팀별로 묶어 줄인다 — 요약.
  5. 보고서 문장으로 엮는다 — 생성.

쪼갤 때 지키는 것이 셋입니다. 모델이 필요 없는 단계를 모델에 맡기지 않습니다(1번은 SQL입니다). 각 단계의 출력이 다음 단계의 입력 형식과 맞는지 확인합니다. 그리고 순서를 바꾸면 비용이 줄어드는지 봅니다 — 3번을 2번 앞에 두면 환불이 아닌 문의에도 추출을 돌리게 되므로 호출 수가 몇 배로 늡니다.

시험은 이 마지막 감각을 자주 건드립니다. 「비용을 줄이려면 어느 단계를 앞에 두는가」라는 물음의 답은 대개 범위를 좁히는 단계를 먼저입니다.

프롬프트·RAG·파인튜닝 중 고르기

같은 요구를 세 가지 방식으로 풀 수 있고, 고르는 기준이 정해져 있습니다.

무엇이 문제인가 고르는 것 이유
말투·형식·단계가 안 맞는다 프롬프트 모델이 아는 것을 다르게 꺼내는 문제입니다
모델이 모르는 사내·최신 지식이 필요하다 RAG 지식을 검색으로 그때그때 넣습니다
답에 출처를 달아야 한다 RAG 어느 문서에서 왔는지 남습니다
지식이 자주 바뀐다 RAG 인덱스만 갱신하면 됩니다
형식·문체가 매우 특수하고 예시로도 안 잡힌다 파인튜닝 예시 수천 건으로 모델 자체를 맞춥니다
프롬프트가 너무 길어 비용·지연이 문제다 파인튜닝 긴 지시를 가중치로 옮깁니다

판단은 싼 것부터입니다. 프롬프트로 되는지 보고, 지식이 모자라면 RAG를 얹고, 그래도 안 되면 파인튜닝을 검토합니다. 「최신 사내 정책을 반영해야 한다」에 파인튜닝을 고르는 보기가 늘 섞여 있는데, 정책이 바뀔 때마다 다시 학습해야 하므로 오답입니다. 반대로 「출력이 사내 서식 그대로여야 하고 예시 수천 건이 이미 있다」면 파인튜닝이 답이 되는 자리입니다.

셋은 배타적이지 않습니다. RAG로 근거를 넣고 프롬프트로 형식을 잡는 조합이 실무의 기본값이고, 문항이 「가장 적은 노력으로」라고 적으면 대개 조합의 앞쪽 두 개까지가 답입니다.

연습 문제

  1. 「문의마다 담당 부서를 넷 중 하나로 지정하라」는 요구가 가리키는 태스크는?
    ① 요약
    ② 분류
    ③ 추출
    ④ 생성
    ②. 출력이 정해진 후보 중 하나입니다. 값이 열려 있으면 추출이지만 여기서는 넷으로 못 박혀 있습니다.
  2. RAG 체인의 구성요소를 실행 순서대로 배열하시오.
    (가) LLM (나) 프롬프트 템플릿 (다) 출력 파서 (라) retriever
    (라) → (나) → (가) → (다). 검색으로 자료를 가져와 템플릿의 빈자리를 채우고, 모델이 답을 내고, 파서가 뒤에서 쓸 형태로 바꿉니다.
  3. 다음 중 RAG가 프롬프트나 파인튜닝보다 알맞은 상황을 둘 고르시오.
    ① 답변 말투를 정중하게 바꾸고 싶다
    ② 사내 규정이 분기마다 바뀌는데 답이 최신이어야 한다
    ③ 답에 근거 문서 링크를 달아야 한다
    ④ 출력 JSON 키 이름을 바꾸고 싶다
    ⑤ 프롬프트가 길어 토큰 비용이 크다
    ②와 ③. 바뀌는 지식과 출처 제시가 RAG의 자리입니다. ①④는 프롬프트로 풀고, ⑤는 파인튜닝을 검토하는 신호입니다.
  4. 「지난주 문의 5만 건 중 환불 건만 골라 주문번호를 뽑는다」를 두 단계로 나눌 때, 비용을 줄이는 순서는?
    ① 추출 → 분류
    ② 분류 → 추출
    ③ 요약 → 추출
    ④ 순서는 비용과 무관하다
    ②. 범위를 좁히는 분류를 먼저 돌려야 추출 호출이 환불 건에만 들어갑니다. ①은 5만 건 전부에 추출을 돌립니다.
  5. 파이프라인 명세를 적을 때 한 단계에 태스크를 하나만 두는 이유로 가장 알맞은 것은?
    ① 프롬프트가 짧아져 비용이 준다
    ② 어느 단계가 틀렸는지 가려낼 수 있다
    ③ 모델을 더 작은 것으로 바꿀 수 있다
    ④ 검색 정확도가 올라간다
    ②. 실패를 단계에 귀속시킬 수 있어야 평가와 수정이 됩니다. 나머지는 부수적이거나 상황에 따라 달라집니다.
  6. 출력 파서가 맡는 일로 알맞은 것은?
    ① 질문과 비슷한 문서를 찾아 온다
    ② 프롬프트의 변수 자리를 채운다
    ③ 모델이 낸 텍스트를 뒤 단계가 쓸 자료형으로 바꾼다
    ④ 모델 엔드포인트를 고른다
    ③. ①은 retriever, ②는 프롬프트 템플릿의 일입니다.
  7. 다음 요구를 태스크에 짝지으시오.
    (가) 계약서에서 계약 금액과 만료일을 뽑는다 (나) 회의록을 다섯 줄로 줄인다 (다) 사내 규정을 근거로 질문에 답한다 (라) 고객에게 보낼 사과문 초안을 만든다
    ① 요약 ② 추출 ③ 생성 ④ 질의응답
    (가)–②, (나)–①, (다)–④, (라)–③.
  8. 「출력이 사내 서식과 문체를 정확히 따라야 하고, 그런 문서 8천 건이 이미 쌓여 있으며, 서식은 몇 년째 그대로다」는 요구에 가장 알맞은 접근은?
    ① 프롬프트에 예시 셋을 넣는다
    ② Vector Search 인덱스를 만든다
    ③ 파인튜닝을 검토한다
    ④ 더 큰 모델로 바꾼다
    ③. 형식·문체가 매우 특수하고 학습에 쓸 예시가 대량으로 있으며 자주 바뀌지 않는, 파인튜닝의 세 조건이 모두 맞습니다. 지식이 바뀌는 문제가 아니므로 ②는 자리가 아닙니다.

이 여덟 문항의 공통 절차는 셋입니다. 요구를 태스크 이름으로 옮기고, 단계마다 입력·출력을 적고, 무엇이 모자란지 보고 프롬프트·RAG·파인튜닝 중 가장 싼 것을 고르는 것. 설계 영역의 문항은 대부분 이 세 걸음 중 한 자리를 묻습니다.

Databricks GenAI Associate 시험 노트 전체 보기