AI 엔지니어링이란 무엇인가 — ML 엔지니어링과 뭐가 다를까
ChatGPT가 나온 이후, 채용 공고에 낯선 직군이 하나 늘었습니다. 바로 AI 엔지니어입니다. 데이터 사이언티스트도 아니고, ML 엔지니어도 아닌 이 직군은 정확히 무슨 일을 할까요? 코드와 함께 정리합니다.
한 문장 정의
AI 엔지니어링은 이미 학습된 파운데이션 모델(GPT, Claude, Gemini, Llama 등)을 활용해서 실제 제품과 서비스를 만드는 일입니다.
핵심은 "모델을 만드는 것"이 아니라 "모델을 쓰는 것"입니다. 이 차이가 ML 엔지니어링과의 결정적인 분기점입니다.
ML 엔지니어링 vs AI 엔지니어링
| 구분 | ML 엔지니어링 | AI 엔지니어링 |
|---|---|---|
| 모델 | 직접 학습시킴 | API로 가져다 씀 |
| 데이터 | 학습용 데이터셋 구축 | 컨텍스트(문서·검색 결과) 주입 |
| 주요 작업 | 피처 엔지니어링, 튜닝 | 프롬프트 설계, RAG, 에이전트 |
| 평가 | accuracy, F1 score | 출력 품질 평가(evals) |
| 진입 장벽 | 수학/통계 지식 필요 | 백엔드 개발 경험이면 시작 가능 |
과거에는 "감성 분석 기능"을 만들려면 데이터 수집·라벨링·학습에 몇 달이 걸렸습니다. 지금은 API 호출 한 번이면 됩니다.
import anthropic
client = anthropic.Anthropic()
response = client.messages.create(
model="claude-opus-4-8",
max_tokens=256,
messages=[{
"role": "user",
"content": "다음 리뷰의 감성을 긍정/부정/중립 중 하나로 분류해줘: '배송은 빨랐는데 면이 다 부서져 있었어요.'"
}]
)
print(response.content[0].text) # 부정모델 학습 없이 몇 줄로 끝났습니다. 그래서 AI 엔지니어의 시간은 모델이 아니라 모델 주변의 시스템에 쓰입니다.
AI 엔지니어가 실제로 하는 일 4가지
1프롬프트 엔지니어링 — 지시를 설계하는 일
단순히 "잘 부탁해" 수준이 아니라, 출력 형식·예외 처리·말투까지 명세하는 작업입니다. 프롬프트는 사실상 자연어로 쓰는 코드입니다.
system_prompt = """당신은 고객 문의 분류 시스템입니다.
규칙:
- 문의를 다음 중 하나로 분류: 배송 / 환불 / 제품불량 / 기타
- 반드시 JSON으로만 응답: {"category": "...", "urgent": true/false}
- 환불 요청 + 화난 어조면 urgent를 true로
"""포인트는 출력을 기계가 파싱할 수 있게 강제하는 것입니다. 요즘은 JSON 스키마를 API 레벨에서 강제하는 Structured Outputs 기능을 쓰는 게 표준입니다.
2RAG — 모델에게 "우리 회사 지식"을 주입하는 일
LLM은 우리 회사 내부 규정이나 어제 올라온 공지사항을 모릅니다. 그래서 질문과 관련된 문서를 검색해서 프롬프트에 끼워 넣는 패턴이 필요한데, 이게 RAG(Retrieval-Augmented Generation)입니다.
# RAG의 뼈대 — 실제로는 벡터 DB(Chroma, pgvector 등)를 사용
def answer(question: str) -> str:
# 1. 질문과 유사한 문서 검색 (벡터 유사도)
docs = vector_db.search(question, top_k=3)
# 2. 검색된 문서를 컨텍스트로 넣어서 질문
context = "\n\n".join(d.text for d in docs)
response = client.messages.create(
model="claude-opus-4-8",
max_tokens=1024,
messages=[{
"role": "user",
"content": f"다음 문서를 근거로 답변해줘.\n\n<문서>\n{context}\n</문서>\n\n질문: {question}"
}]
)
return response.content[0].text사내 문서 챗봇, 규정 검색기 같은 서비스가 전부 이 구조입니다. 실무의 상당 부분이 "검색 품질을 어떻게 올리느냐"(청킹 전략, 임베딩 모델 선택, 리랭킹)에 쓰입니다.
3에이전트 — 모델에게 도구를 쥐여주는 일
한 번 묻고 한 번 답하는 챗봇을 넘어서, 모델이 스스로 도구를 골라 쓰면서 여러 단계를 수행하게 만드는 것이 에이전트입니다. "메일함을 확인하고 → 중요한 메일을 요약해서 → 메신저로 보내줘" 같은 작업이죠.
핵심 메커니즘은 의외로 단순합니다. 모델에게 사용 가능한 도구 목록을 주고, 모델이 "이 도구를 이 인자로 실행해줘"라고 답하면 실행 결과를 다시 넣어주는 루프입니다.
tools = [{
"name": "search_mail",
"description": "메일함에서 조건에 맞는 메일을 검색한다",
"input_schema": {
"type": "object",
"properties": {"query": {"type": "string"}},
"required": ["query"]
}
}]
# 모델이 tool_use를 요청하면 → 실행 → 결과를 다시 전달 → 반복
# 이 루프가 에이전트의 전부입니다Claude Code, Cursor 같은 코딩 도구가 전부 이 패턴 위에서 동작합니다.
4평가(Evals) — "잘 되는지"를 숫자로 만드는 일
LLM의 가장 큰 골칫거리는 출력이 매번 다르고, 정답이 하나가 아니라는 것입니다. 프롬프트를 고쳤을 때 좋아졌는지 나빠졌는지 감으로 판단할 수는 없으니, 테스트 케이스를 만들어 자동으로 채점합니다.
test_cases = [
{"input": "환불해주세요 진짜 화나네요", "expected_category": "환불", "expected_urgent": True},
{"input": "배송 언제 오나요?", "expected_category": "배송", "expected_urgent": False},
]
passed = 0
for case in test_cases:
result = classify(case["input"]) # 위에서 만든 분류기
if result["category"] == case["expected_category"] and result["urgent"] == case["expected_urgent"]:
passed += 1
print(f"통과율: {passed}/{len(test_cases)}")정답이 명확하지 않은 작업(요약, 글쓰기)은 다른 LLM에게 채점을 시키는 LLM-as-judge 방식을 씁니다. 프롬프트를 바꿀 때마다 이 평가를 돌려서 회귀(regression)를 잡는 것이 실무의 핵심 루틴입니다.
그 외에 신경 써야 하는 것들
비용과 레이턴시
토큰 단위 과금이므로 프롬프트 길이 = 돈입니다. 반복되는 컨텍스트는 프롬프트 캐싱으로 90%까지 절감할 수 있습니다.
비결정성 처리
같은 입력에도 다른 출력이 나옵니다. 파싱 실패 시 재시도, 폴백 모델 같은 방어 로직이 필수입니다.
가드레일
사용자가 "이전 지시를 무시해"라고 입력하는 프롬프트 인젝션에 대한 방어도 AI 엔지니어의 몫입니다.
어떻게 시작하면 될까
- API로 뭔가 하나 만들어보기 — 챗봇 말고, 자기 업무를 자동화하는 작은 도구가 좋습니다. 메일 요약기, 회의록 정리기 같은 것.
- Structured Outputs로 파싱 가능한 출력 다루기 — LLM을 "함수"처럼 쓰는 감각이 생깁니다.
- RAG를 직접 구현해보기 — 프레임워크 없이 검색 → 프롬프트 조립을 직접 짜보면 원리가 잡힙니다.
- 평가 셋 만들기 — 테스트 케이스 10개만 만들어도 개발 방식이 달라집니다.
마치며
AI 엔지니어링은 결국 소프트웨어 엔지니어링에 새로운 부품(LLM)이 하나 추가된 것에 가깝습니다. 모델 내부의 수학을 몰라도, API·프롬프트·검색·평가라는 네 가지 축을 다룰 줄 알면 실무를 시작할 수 있습니다. 그리고 이 부품은 지금 소프트웨어 업계에서 가장 빠르게 발전하는 부품이기도 합니다.