IBM Technology는 2026년 4월 15일 영상에서 AI agent를 production에서 굴리려면 system design, tool and contract design, retrieval engineering, reliability engineering, security and safety, evaluation and observability, product thinking이 필요하다고 정리했다.
프롬프트 엔지니어라는 말은 이제 반쯤 직무명을 잘못 붙인 것에 가깝다.
물론 prompt는 여전히 중요하다.
근데 실제 agent가 API를 부르고, DB를 읽고, 파일을 고치고, 외부 시스템에 side effect를 만드는 순간부터 문제는 문장력이 아니다.
문제는 시스템이다.
도구 계약이 흐리면 agent는 상상으로 빈칸을 채운다.
retrieval이 흔들리면 틀린 문서를 들고 자신 있게 답한다.
retry와 timeout이 없으면 실패한 API 앞에서 멍하니 기다린다.
observability가 없으면 사고가 나도 “아까 뭘 했더라”부터 시작한다.
이쯤 되면 “프롬프트 좀 잘 쓰는 사람” 한 명으로는 안 된다.
agent를 만든다는 건 작은 백엔드 시스템, 검색 시스템, 보안 경계, 실험 플랫폼, UX까지 같이 설계하는 일에 가깝다.
살짝 과장하면 이렇다.
prompt engineer는 agent 시대의 입구고, agent engineer는 출구까지 책임지는 사람이다.
문 앞에서 인사만 잘한다고 집이 튼튼해지진 않는다.
건물은 배관과 전기와 비상구에서 진짜 실력이 드러난다.
한 줄로 먼저 적으면 이렇다.
AI agent engineer에게 필요한 역량은더 멋진 prompt가 아니라작게 쪼갠 시스템,명확한 tool contract,검증 가능한 retrieval,실패 복구,권한 경계,trace와 eval,사람이 믿고 쓸 UX다.
지금 답
AI agent engineer에게 필요한 7가지 역량은 아래처럼 볼 수 있다.
System design: agent를 단일 prompt가 아니라 여러 component가 협업하는 시스템으로 설계한다.Tool and contract design: agent가 호출하는 tool의 입력, 출력, 실패 조건, 금지 범위를 명확히 만든다.Retrieval engineering: model이 볼 context를 어떻게 찾고, 자르고, 랭킹하고, 검증할지 설계한다.Reliability engineering: timeout, retry, fallback, circuit breaker, 상태 복구를 넣는다.Security and safety: prompt injection, 과한 권한, 위험한 side effect, 승인 흐름을 다룬다.Evaluation and observability: trace, log, grader, dataset, regression test로 agent를 측정한다.Product thinking: agent가 언제 묻고, 언제 멈추고, 언제 사람에게 넘길지 설계한다.
이 7개는 IBM Technology 영상의 골격이다.
하지만 여기서 멈추면 그냥 영상 요약이다.
TECHTAEK 관점에서는 이걸 바로 운영 체크리스트로 바꿔야 한다.
내가 보는 핵심은 간단하다.
agent는 “말을 잘하는 모델”이 아니라 “행동하는 시스템”이다.
행동하는 시스템에는 계약이 필요하다.
행동하는 시스템에는 로그가 필요하다.
행동하는 시스템에는 실패했을 때 멈추는 규칙이 필요하다.
행동하는 시스템에는 사람이 이해할 수 있는 설명과 승인 지점이 필요하다.
이 네 가지가 없으면 agent는 데모에서는 빛나고, 운영에서는 자꾸 물음표를 만든다.
데모에서 멋진 agent는 많다.
근데 금요일 오후에 장애 안 내는 agent는 조금 더 귀하다.
금요일 오후는 신성하다.
그 시간에 agent가 이상한 tool call을 날리면 우정에도 금이 간다.
왜 prompt보다 system design인가
AI agent를 만들 때 제일 흔한 착각은 agent를 prompt 하나로 보는 것이다.
처음에는 그럴 수 있다.
LLM에 역할을 주고, 지시를 넣고, 도구 몇 개를 붙이면 agent처럼 움직인다.
하지만 실제 운영에서는 곧 component가 늘어난다.
LLM이 있다.
tool router가 있다.
retrieval이 있다.
database가 있다.
외부 API가 있다.
approval flow가 있다.
logging과 trace가 있다.
evaluation dataset이 있다.
deployment와 rollback이 있다.
이걸 하나의 긴 prompt로 밀어 넣으면 prompt가 아니라 서랍장이 된다.
서랍장은 물건을 넣기 좋지만, 서버 장애를 복구하진 않는다.
OpenAI Agents SDK 문서도 agent를 model, instructions, tools, guardrails, MCP servers, handoffs, structured outputs를 묶는 core unit으로 설명한다.
중요한 건 “agent 하나가 모든 걸 다 한다”가 아니다.
문서는 오히려 작은 specialist 하나를 깨끗하게 정의하고, 필요할 때만 agent를 나누라고 설명한다.
Anthropic도 비슷한 얘기를 한다.
agentic system은 latency와 cost를 성능과 맞바꾸는 경우가 많고, 많은 상황에서는 retrieval과 in-context examples를 붙인 단일 LLM call만으로도 충분할 수 있다고 말한다.
이건 꽤 현실적인 조언이다.
agent부터 만들지 말라는 얘기다.
먼저 workflow를 본다.
고정 경로로 풀리는 문제인지 본다.
retrieval만 붙여도 되는지 본다.
tool call 하나로 끝나는지 본다.
그 다음에도 여전히 복잡하면 agent를 본다.
그래서 첫 번째 역량은 system design이다.
모델을 어떻게 고를지가 아니라, 이 작업이 agent까지 갈 일인지부터 판단하는 역량이다.
내 기준으로 agent가 필요한 순간은 셋이다.
첫째, 단계 수를 미리 고정하기 어렵다.
둘째, 중간 tool 결과를 보고 다음 행동이 바뀐다.
셋째, 실패했을 때 되돌아가거나 다른 길을 찾아야 한다.
이 셋이 없으면 agent보다 workflow가 낫다.
workflow가 더 재미없어 보여도 운영에서는 자주 이긴다.
재미없는 설계가 오래 버티는 경우가 많다.
운영은 파티가 아니라 장거리 이사다.
역량 1: system design
system design은 agent를 “무슨 모델로 만들까”보다 넓게 보는 능력이다.
질문은 이런 식이어야 한다.
입력은 어디서 들어오는가?
agent가 볼 수 있는 데이터는 어디까지인가?
어떤 tool은 읽기 전용이고, 어떤 tool은 side effect를 만드는가?
state는 어디에 저장되는가?
한 번 실패한 작업은 어떻게 재시도하는가?
사용자가 중간에 취소하면 어디까지 롤백되는가?
긴 작업은 어떻게 resume되는가?
어떤 로그가 남아야 나중에 설명할 수 있는가?
이 질문에 답하지 않고 prompt만 고치면, agent는 똑똑해지는 게 아니라 즉흥성이 늘어난다.
즉흥성은 데모에서는 매력적이다.
운영에서는 불안하다.
좋은 system design은 agent를 component로 나눈다.
planner.
tool caller.
retriever.
validator.
approver.
logger.
evaluator.
user-facing responder.
꼭 다 분리된 서비스로 만들라는 뜻은 아니다.
먼저 머릿속 설계에서 역할이 나뉘어야 한다는 뜻이다.
OpenAI Agents SDK의 “starting point” 표도 비슷한 흐름을 보여준다.
single specialist를 깨끗하게 정의하는 단계, runtime loop와 state를 이해하는 단계, sandbox가 필요한 단계, handoff와 ownership을 설계하는 단계, guardrails와 human review를 붙이는 단계, traces와 evaluation으로 개선하는 단계가 서로 다르다.
한 화면에서 한 번에 다 해결할 수 없다.
그래서 agent engineer는 “어떤 기능을 붙일까”보다 “어떤 설계 질문을 먼저 풀까”를 잘라야 한다.
처음부터 멀티에이전트와 MCP와 sandbox와 eval을 다 붙이는 건 멋있지만, 대체로 무겁다.
작게 시작한다.
작은 agent 하나를 만든다.
그 agent의 입력과 출력과 tool surface를 고정한다.
trace가 남는지 본다.
실패 하나를 고친다.
그 다음 넓힌다.
이게 느려 보여도 실제로는 빠르다.
한 번 꼬인 agent 시스템을 디버깅하는 것보다 훨씬 빠르다.
역량 2: tool and contract design
agent는 tool을 통해 세상과 만난다.
그러니까 tool contract가 흐리면 agent의 행동도 흐려진다.
여기서 contract란 “이 tool은 이런 입력을 받고, 이런 출력을 주며, 이런 경우 실패하고, 이런 일은 하지 않는다”라는 약속이다.
예를 들어 get_user라는 tool이 있다고 하자.
입력이 그냥 id: string이면 너무 넓다.
사용자 이름인지, 내부 UUID인지, 이메일인지, CRM ID인지 모른다.
agent는 그럴듯한 값을 넣어볼 수 있다.
그럴듯함은 tool call에서 위험하다.
반대로 입력이 user_id, format, required, example, allowed pattern까지 적혀 있으면 agent가 덜 헤맨다.
OpenAI 도구 문서도 Agents SDK에서는 tool wiring이 단일 API request가 아니라 agent definition과 workflow design 안으로 들어간다고 설명한다.
한 specialist가 직접 호출해야 하는 tool인지, manager agent가 계속 user-facing reply를 소유하고 specialist를 tool처럼 노출할지, side effect가 있으면 approval이 필요한지 나눠야 한다.
Anthropic도 tool definition에 prompt engineering만큼 신경 써야 한다고 말한다.
좋은 tool definition에는 예시, edge case, 입력 형식, 다른 tool과의 경계가 들어가야 한다.
이건 내가 agent workflow를 굴릴 때도 계속 맞는 말이다.
도구 이름 하나만 바꿔도 agent 행동이 바뀐다.
parameter 설명 하나만 추가해도 tool call 성공률이 달라진다.
반대로 비슷한 tool이 5개 있으면 agent가 자꾸 헷갈린다.
tool이 많다고 agent가 강해지는 게 아니다.
tool이 많으면 선택지도 많아진다.
선택지가 많아지면 잘못 고를 기회도 늘어난다.
그래서 tool contract의 기본 원칙은 세 가지다.
이름은 행동을 드러낸다.
입력은 좁게 만든다.
출력은 다음 단계가 바로 읽을 수 있게 만든다.
추가로 side effect가 있으면 tool 이름에 흔적을 남긴다.
get_invoice와 send_invoice는 절대 같은 결로 두면 안 된다.
preview_refund와 execute_refund도 나눠야 한다.
read_file과 write_file도 나눠야 한다.
사람이 보기엔 당연하다.
agent에게도 당연하게 만들어줘야 한다.
당연함은 설계자가 만들어주는 것이다.
AI가 알아서 알아차리겠지, 그 문장은 대체로 비용 청구서로 돌아온다.
역량 3: retrieval engineering
AI agent가 틀리는 이유가 항상 모델 때문은 아니다.
엉뚱한 context를 줬기 때문에 틀릴 때가 많다.
retrieval engineering은 이 문제를 다룬다.
무엇을 검색할지.
어떤 문서를 넣을지.
어떤 단위로 chunking할지.
검색 결과를 어떻게 rank할지.
오래된 문서를 어떻게 제외할지.
출처를 어떻게 남길지.
모델이 모르는 걸 모른다고 말하게 할지.
OpenAI Retrieval 문서는 semantic search가 키워드가 거의 겹치지 않아도 의미적으로 가까운 결과를 찾을 수 있다고 설명한다.
또 vector store는 파일을 chunk, embed, index하는 container이고, ranking option과 score threshold로 결과 품질을 조정할 수 있다고 설명한다.
이건 agent engineer에게 꽤 중요하다.
RAG를 붙였다는 말은 시작일 뿐이다.
retrieval 품질이 agent 품질의 천장이 된다.
잘못된 문서가 들어오면 agent는 잘못된 문서를 바탕으로 똑똑하게 틀린다.
똑똑하게 틀린 답은 제일 귀찮다.
문장도 매끄럽고 근거도 있는 척한다.
그래서 retrieval에는 최소한 아래 점검이 필요하다.
문서 출처가 최신인가?
문서가 기능별로 잘 쪼개졌는가?
chunk가 너무 커서 핵심이 묻히지 않는가?
chunk가 너무 작아서 맥락이 사라지지 않는가?
검색 결과에 score나 파일 출처가 남는가?
비슷한 문서가 여러 개일 때 우선순위가 있는가?
삭제되거나 만료된 문서가 계속 검색되지 않는가?
retrieval 실패를 eval dataset에 넣었는가?
내가 특히 중요하게 보는 건 “retrieval이 실패했을 때 agent가 어떻게 행동하는가”다.
agent가 문서를 못 찾았으면 못 찾았다고 말해야 한다.
대체 문서를 찾았으면 대체라고 말해야 한다.
근거가 약하면 결론도 약하게 말해야 한다.
이게 없으면 RAG는 grounding이 아니라 confidence generator가 된다.
confidence는 좋은데, 틀린 confidence는 진짜 피곤하다.
자신감 있는 후배가 잘못된 링크 들고 뛰어오는 느낌이다.
열정은 고맙지만 일단 링크부터 다시 보자.
역량 4: reliability engineering
agent는 API를 부른다.
API는 실패한다.
네트워크는 끊긴다.
외부 서비스는 느려진다.
rate limit은 갑자기 온다.
파일 시스템은 생각보다 까다롭다.
여기서 reliability engineering이 필요하다.
IBM 영상이 말한 reliability engineering은 backend engineer에게 익숙한 영역이다.
timeout.
retry.
backoff.
fallback.
circuit breaker.
idempotency.
state recovery.
partial failure handling.
agent는 “한 번 물어보고 답하는 챗봇”일 때보다 훨씬 많은 실패 지점을 가진다.
예를 들어 환불 agent를 생각해보자.
주문 조회는 성공했다.
결제 provider call은 timeout이 났다.
ticket update는 성공했다.
고객 이메일 발송은 실패했다.
agent가 이 상황을 어떻게 설명하고, 어디까지 재시도하고, 무엇을 멈춰야 할까?
이건 prompt 문제가 아니다.
운영 설계 문제다.
agent engineer는 아래 질문을 해야 한다.
tool call은 idempotent한가?
같은 요청을 두 번 보내도 안전한가?
retry 횟수는 어디서 멈추는가?
timeout 이후 상태는 어디에 남는가?
부분 성공은 어떻게 표시하는가?
사용자에게 어떤 메시지를 보여주는가?
사람 승인 전에는 side effect가 멈추는가?
OpenAI guardrails와 human review 문서는 run이 계속 갈지, pause할지, stop할지를 정하는 통제 장치로 guardrails와 human review를 설명한다.
특히 취소, 수정, shell command, 민감한 MCP action 같은 side effect 앞에서는 human-in-the-loop approval을 시작점으로 제안한다.
이게 reliability와 연결된다.
위험한 작업은 자동 retry보다 승인과 pause가 먼저다.
어떤 실패는 재시도하면 해결된다.
어떤 실패는 재시도하면 사고가 커진다.
agent engineer는 이 둘을 구분해야 한다.
실패는 다 같은 실패가 아니다.
일부 실패는 귀찮다.
일부 실패는 비싸다.
일부 실패는 회의가 생긴다.
회의가 생기는 실패는 미리 막자.
역량 5: security and safety
agent는 attack surface다.
이 말은 이제 과장이 아니다.
agent가 tool을 호출할 수 있으면, 공격자는 agent가 tool을 잘못 호출하게 만들려고 한다.
prompt injection은 그 대표적인 예다.
retrieved document 안에 악성 instruction이 들어갈 수 있다.
사용자 입력에 system prompt를 무시하라는 문장이 들어갈 수 있다.
웹 페이지가 agent에게 다른 행동을 시킬 수 있다.
email, ticket, issue, PR description도 모두 입력이 될 수 있다.
그래서 security and safety는 “유해 답변 필터” 정도로 끝나면 안 된다.
권한 경계가 필요하다.
tool별 allowlist가 필요하다.
위험 action 앞의 approval이 필요하다.
read와 write가 분리되어야 한다.
민감 정보는 model context에 안 넣는 설계가 필요하다.
OpenAI Agent definitions 문서는 conversation history와 run context의 경계를 분명히 설명한다.
conversation history는 model이 보는 것이고, run context는 code가 보는 것이다.
model이 알 필요 없는 authenticated user info, database client, logger, helper function 같은 runtime dependency는 local context에 둘 수 있다.
이 경계가 중요하다.
모든 것을 model에게 알려주는 건 편하다.
하지만 편하다고 안전한 건 아니다.
agent가 필요한 정보와 runtime이 필요한 정보는 다르다.
보안 설계는 이 차이에서 시작한다.
내 기준에서 agent 보안 기본값은 이렇다.
읽기 전용으로 시작한다.
쓰기 tool은 별도 이름으로 둔다.
삭제 tool은 더 별도 이름으로 둔다.
외부 전송 tool은 approval을 요구한다.
DB write는 sandbox나 staging에서 먼저 검증한다.
비밀값은 model context에 넣지 않는다.
retrieval 문서에는 instruction과 content를 구분하는 규칙을 둔다.
trace에는 민감값 masking을 넣는다.
이 정도도 귀찮다.
하지만 agent가 실제 행동을 하기 시작하면 귀찮음이 안전장치가 된다.
귀찮은 체크리스트는 오늘의 나를 괴롭히지만, 내일의 나를 살린다.
내일의 나는 대체로 고마워한다.
역량 6: evaluation and observability
agent를 운영하려면 “느낌상 좋아졌다”가 제일 위험하다.
느낌은 출발점으로는 괜찮다.
배포 기준으로는 부족하다.
OpenAI Agents SDK 문서는 tracing이 기본 server-side SDK path에서 켜져 있고, model calls, tool calls, handoffs, guardrails, custom spans 같은 구조화된 record를 볼 수 있다고 설명한다.
그리고 trace는 두 가지 일에 쓰라고 한다.
하나는 한 번의 workflow run에서 무슨 일이 있었는지 디버깅하는 일이다.
다른 하나는 agent workflow evaluation으로 넘어갈 고신호 예시를 모으는 일이다.
이 흐름이 중요하다.
trace가 먼저다.
eval은 그 다음이다.
무작정 benchmark부터 만들면 뭘 측정해야 할지 모른다.
먼저 실제 실패 trace를 본다.
어떤 tool이 잘못 호출됐는지 본다.
retrieval 결과가 틀렸는지 본다.
handoff가 엉뚱했는지 본다.
guardrail이 너무 느슨했는지 본다.
그 다음 실패 유형을 dataset으로 만든다.
OpenAI agent evals 문서도 비슷하게 설명한다.
처음에는 trace grading으로 workflow-level issue를 잡고, 그 다음 dataset과 eval run으로 반복 가능한 측정으로 옮기라고 한다.
Anthropic의 agent eval 글도 agent는 여러 turn, tool call, state 변경, 중간 결과 적응 때문에 평가가 어렵고, eval이 production에서만 문제를 잡는 reactive loop를 줄인다고 설명한다.
그러니까 agent engineer에게 observability는 옵션이 아니다.
agent가 무슨 일을 했는지 모르면 개선할 수 없다.
agent가 왜 그렇게 했는지 모르면 신뢰할 수 없다.
agent 변경이 좋아졌는지 측정하지 못하면 배포할 수 없다.
최소 로그는 이 정도다.
user request id.
agent version.
prompt or instruction version.
model.
tool call name.
tool call arguments.
tool result summary.
retrieval source ids.
latency.
cost or token usage.
guardrail result.
human approval decision.
final outcome.
여기서 중요한 건 모든 원문을 다 저장하라는 게 아니다.
민감 정보는 줄이고, 재현에 필요한 구조를 남기라는 뜻이다.
로그를 너무 많이 남기면 또 다른 보안 문제가 된다.
로그를 너무 적게 남기면 디버깅이 된다.
중간이 어렵다.
그래서 agent engineer가 필요하다.
prompt만 잘 쓰는 사람은 이 중간을 잘라주기 어렵다.
역량 7: product thinking
agent engineer에게 product thinking이 필요한 이유는 단순하다.
agent는 사람이 쓰기 때문이다.
그리고 사람은 agent가 언제 확신하고, 언제 모르는지 알고 싶어 한다.
agent가 무엇을 할 수 있는지 알고 싶어 한다.
어디까지 자동으로 할지 알고 싶어 한다.
실패했을 때 다음 행동이 뭔지 알고 싶어 한다.
이건 UX 문제다.
동시에 신뢰 문제다.
AI agent는 늘 같은 방식으로 예측 가능한 소프트웨어가 아니다.
같은 요청도 context, retrieval, tool state, external API 상태에 따라 결과가 달라질 수 있다.
그렇다면 product는 이 불확실성을 숨기면 안 된다.
오히려 잘 드러내야 한다.
예를 들어 agent가 주문 취소를 도울 때, 사용자는 아래를 알고 싶다.
주문을 실제로 취소했는가?
아직 승인 대기인가?
환불은 요청됐는가?
이메일은 발송됐는가?
실패한 단계가 있는가?
다시 시도해도 안전한가?
사람 상담원에게 넘겨야 하는가?
이걸 UX에 반영하지 않으면 agent는 뭔가 한 것 같은데 사용자는 불안하다.
불안한 자동화는 오래 못 간다.
product thinking은 “사람이 믿을 수 있는 경계”를 만드는 일이다.
언제 묻는가.
언제 멈추는가.
언제 설명하는가.
언제 사람에게 넘기는가.
언제 자신감 점수를 낮춰 말하는가.
언제 최종 action 전에 preview를 보여주는가.
TECHTAEK에서 agent 글을 계속 쓰는 이유도 여기에 있다.
agent는 개발 도구 같지만, 결국 운영 제품이다.
내부 tool도 product다.
나 혼자 쓰는 자동화도 product다.
내일의 내가 사용자다.
내일의 나는 오늘의 내가 남긴 애매한 로그를 보면 기분이 나빠진다.
그러니 오늘 친절하게 남기자.
7가지 역량을 운영 체크리스트로 바꾸면
아래 표는 IBM 영상의 7가지 축을 내가 실제 agent 운영 기준으로 바꾼 것이다.
| 역량 | 운영 질문 | 최소 산출물 | 안 하면 생기는 일 |
|---|---|---|---|
| System design | agent가 필요한 문제인가, workflow로 충분한가 | component map | prompt가 비대해진다 |
| Tool contract | tool 입력과 출력이 모호하지 않은가 | schema, examples, errors | agent가 상상으로 호출한다 |
| Retrieval | 올바른 context를 찾고 검증하는가 | source id, chunk/ranking rule | 틀린 문서를 근거로 답한다 |
| Reliability | 실패와 재시도를 통제하는가 | timeout, retry, fallback | 무한 대기 또는 중복 실행 |
| Security | 권한과 side effect를 막는가 | allowlist, approval, masking | prompt injection과 과권한 |
| Eval/observability | 행동을 측정하고 재현하는가 | trace, dataset, grader | “느낌상 좋아짐” 배포 |
| Product thinking | 사람이 믿고 쓸 수 있는가 | status, preview, escalation | 사용자 불안과 재사용 실패 |
이 표에서 제일 먼저 볼 건 tool contract다.
왜냐하면 가장 빨리 고칠 수 있기 때문이다.
tool 이름을 바꾼다.
parameter를 좁힌다.
예시를 추가한다.
에러를 명확히 한다.
side effect를 분리한다.
이것만으로도 agent가 덜 헤맨다.
그 다음은 trace다.
trace가 없으면 고쳐도 뭘 고쳤는지 모른다.
agent가 왜 이상한 선택을 했는지 추측해야 한다.
추측으로 디버깅하면 피곤하다.
추측은 회의에서만으로도 충분히 많다.
코드에서는 로그를 보자.
agent engineer의 첫 주 학습 순서
처음부터 모든 역량을 깊게 파면 지친다.
그래서 첫 주는 이렇게 잡는 게 좋다.
첫째 날은 agent와 workflow 차이를 정리한다.
Anthropic의 workflow와 agents 구분을 읽고, 내가 만들려는 것이 고정 경로인지 open-ended task인지 나눈다.
둘째 날은 tool schema를 본다.
지금 쓰는 function tool이나 MCP tool 중 하나를 골라 이름, description, parameter, output, error를 고친다.
셋째 날은 retrieval 실패를 하나 잡는다.
엉뚱한 문서가 들어와서 답이 틀린 사례를 찾는다.
chunk, ranking, source freshness 중 뭐가 문제였는지 적는다.
넷째 날은 reliability rule 하나를 만든다.
timeout과 retry 횟수를 정한다.
같은 action이 두 번 실행되면 안 되는 tool은 idempotency key를 생각한다.
다섯째 날은 security boundary를 만든다.
read/write tool을 나눈다.
외부 전송이나 삭제는 approval을 요구하게 한다.
여섯째 날은 trace를 본다.
한 run에서 어떤 model call, tool call, retrieval result, guardrail이 있었는지 볼 수 있게 만든다.
일곱째 날은 eval case를 세 개 만든다.
성공 case 하나.
실패해야 하는 case 하나.
헷갈리는 edge case 하나.
이 정도면 agent engineer 입문으로 충분하다.
책 열 권보다 실패 trace 하나가 더 빨리 가르쳐줄 때가 있다.
물론 책도 좋다.
근데 trace는 핑계를 안 들어준다.
좋은 agent engineer가 먼저 고치는 것
좋은 agent engineer는 prompt부터 늘리지 않는다.
먼저 tool을 본다.
tool 이름이 모호한지 본다.
schema가 느슨한지 본다.
도구 결과가 너무 길거나 너무 자유로운지 본다.
다음은 retrieval을 본다.
agent가 틀린 문서를 봤는지 확인한다.
문서를 못 찾았는데 답을 만든 건 아닌지 본다.
source freshness가 깨졌는지 본다.
그 다음은 trace를 본다.
agent가 어느 순간 방향을 잃었는지 본다.
tool call 직전 prompt가 어땠는지 본다.
guardrail이 작동했는지 본다.
마지막으로 prompt를 본다.
prompt가 중요하지 않아서가 아니다.
prompt는 시스템 위에서 작동하기 때문이다.
시스템이 흐리면 prompt를 아무리 다듬어도 흔들린다.
반대로 시스템이 선명하면 prompt는 짧아져도 잘 돈다.
내가 좋아하는 순서는 이렇다.
tool contract.
retrieval quality.
trace.
eval.
prompt.
이 순서는 재미없다.
하지만 실전에서는 잘 먹힌다.
재미있는 건 launch demo가 해주고, 운영자는 재미없는 걸 맡자.
세상은 그렇게 균형을 맞춘다.
언제 agent engineer까지 필요 없나
모든 팀에 agent engineer라는 직함이 당장 필요한 건 아니다.
아직 agent가 텍스트 요약만 한다면 필요 없다.
tool call이 없다면 필요 없다.
retrieval도 없고 DB도 안 건드린다면 필요 없다.
사람이 결과를 항상 복붙 전에 검수한다면 필요성이 낮다.
단발성 내부 실험이면 과할 수 있다.
그런 경우에는 prompt template, checklist, manual review로 충분하다.
하지만 아래 조건 중 3개 이상이면 agent engineering을 진지하게 봐야 한다.
- agent가 외부 API를 호출한다.
- agent가 파일을 쓰거나 코드를 수정한다.
- agent가 DB를 읽거나 쓴다.
- agent가 여러 step을 스스로 결정한다.
- agent가 retrieval 결과를 근거로 판단한다.
- agent가 고객이나 팀원에게 직접 결과를 보낸다.
- agent 결과가 비용, 보안, 계정, 환불, 배포에 영향을 준다.
- agent 실패가 반복되는데 원인을 재현하기 어렵다.
이 조건이 보이면 prompt만 더 잘 쓰는 단계는 지났다.
이제 system design과 observability를 붙일 때다.
여기서 계속 prompt만 고치면, 깔끔한 문장으로 더 복잡한 사고를 만든다.
문장은 예쁜데 시스템은 아픈 상태.
그거 은근히 속상하다.
작은 팀용 agent engineering 템플릿
작은 팀은 거창한 플랫폼부터 만들 필요가 없다.
다음 템플릿이면 시작할 수 있다.
## Agent Card
name:
owner:
job:
input:
output:
tools:
read_only_tools:
write_tools:
approval_required:
retrieval_sources:
failure_modes:
timeout:
retry:
trace_fields:
eval_cases:
human_escalation:
이 문서 하나가 꽤 많은 사고를 줄인다.
owner가 없으면 아무도 책임지지 않는다.
job이 넓으면 agent가 다 하려고 한다.
tools가 넓으면 잘못 부른다.
approval_required가 없으면 위험한 action도 그냥 간다.
eval_cases가 없으면 변경 후 좋아졌는지 모른다.
처음엔 이걸 .md 파일로 둬도 된다.
코드가 아니어도 된다.
중요한 건 agent를 제품처럼 다루기 시작하는 것이다.
그리고 이 템플릿을 채우다 보면 agent가 필요 없는 경우도 보인다.
그게 좋은 신호다.
모든 문제를 agent로 풀지 않는 것도 agent engineer의 실력이다.
망치가 생겼다고 모든 벽을 두드리면 집주인이 운다.
우리도 마음속 집주인을 지켜야 한다.
실수 TOP 7
첫 번째 실수는 prompt를 계속 길게 만드는 것이다.
문제가 tool contract인데 prompt만 길어지면 해결이 늦어진다.
두 번째 실수는 tool을 너무 많이 붙이는 것이다.
agent에게 tool 30개를 주고 똑똑하게 고르길 기대하면, 실패했을 때 원인도 30개가 된다.
세 번째 실수는 retrieval을 붙이고 source freshness를 안 보는 것이다.
오래된 문서가 검색되면 agent는 오래된 세계관으로 답한다.
네 번째 실수는 retry를 무조건 선으로 보는 것이다.
조회 실패는 retry가 맞을 수 있다.
결제, 삭제, 발송 실패는 retry 전에 idempotency와 approval을 봐야 한다.
다섯 번째 실수는 trace 없이 eval부터 만드는 것이다.
뭘 실패했는지 모르면 eval도 흐릿해진다.
여섯 번째 실수는 보안을 답변 필터로만 보는 것이다.
agent 보안은 권한, tool boundary, local context, approval, log masking까지 포함한다.
일곱 번째 실수는 product thinking을 마지막에 붙이는 것이다.
사용자가 agent 상태를 이해하지 못하면 좋은 시스템도 불안하게 느껴진다.
이 실수들은 다 연결되어 있다.
결국 agent를 prompt 덩어리로 보느냐, 운영 시스템으로 보느냐의 차이다.
운영 시스템으로 보면 귀찮은 질문이 늘어난다.
하지만 그 질문들이 사고를 줄인다.
귀찮은 질문은 예방접종 같은 거다.
맞을 때 별로지만 나중에 고맙다.
FAQ
prompt engineering은 이제 의미 없나?
아니다.
prompt는 여전히 중요하다.
다만 production agent에서는 prompt만으로는 부족하다.
tool schema, retrieval, reliability, security, trace, eval이 같이 있어야 prompt도 안정적으로 작동한다.
AI agent engineer는 백엔드 개발자여야 하나?
꼭 그렇진 않다.
하지만 백엔드식 사고가 많이 필요하다.
API 계약, 실패 처리, timeout, retry, 로그, 권한 경계, 테스트를 이해하면 훨씬 유리하다.
7가지 역량 중 어디부터 시작해야 하나?
내 기준으로는 tool contract와 trace부터다.
tool contract는 바로 고칠 수 있고 효과가 크다.
trace는 agent가 실제로 무엇을 했는지 보여준다.
그 다음 retrieval, eval, reliability를 순서대로 다듬으면 된다.
RAG를 붙이면 retrieval engineering은 끝난 건가?
아니다.
RAG는 시작이다.
chunking, ranking, source freshness, score threshold, query rewrite, 문서 제거 정책, eval case까지 봐야 한다.
retrieval이 틀리면 agent는 틀린 근거로 자신 있게 답할 수 있다.
eval은 언제부터 만들어야 하나?
처음부터 거대한 eval platform을 만들 필요는 없다.
하지만 실패 case는 초반부터 모아야 한다.
trace에서 자주 보이는 실패를 3-5개 골라 작은 regression set으로 만들면 된다.
guardrail과 human review는 어디에 넣어야 하나?
위험한 side effect 앞에 둔다.
취소, 삭제, 발송, 결제, DB write, shell command, 민감한 MCP action은 자동 실행보다 pause와 approval을 먼저 생각한다.
또 입력, 출력, tool call 주변에 각각 guardrail을 둘 수 있다.
agent framework를 바로 써도 되나?
써도 된다.
다만 framework가 감추는 prompt, tool call, state, trace 구조를 이해해야 한다.
Anthropic도 framework가 빠른 시작을 도와주지만, abstraction이 debugging을 어렵게 만들 수 있다고 경고한다.
AI agent engineer라는 직무명을 써야 하나?
직무명은 회사마다 다를 수 있다.
중요한 건 이름이 아니라 책임 범위다.
agent를 만드는 사람이 prompt, tool, retrieval, reliability, security, eval, product boundary를 함께 봐야 한다는 점이 핵심이다.
관련 글
- Gemini CLI subagents는 언제 쓰고 언제 위험한가 2026 — context 분리·usage limit·편집충돌 체크리스트
- OpenAI Agents SDK sandbox는 언제 쓰고 언제 과한가 2026 — Manifest·격리실행·복구성 분기표
- Claude Code subagents 늘릴수록 왜 더 느려질까 2026 — context 분리와 ownership 설계 체크리스트
공식 출처
- IBM Technology YouTube, The 7 Skills You Need to Build AI Agents, 2026년 4월 15일 영상.
- YouTube transcript mirror, The 7 Skills You Need to Build AI Agents — IBM Technology transcript, 2026년 4월 17일 확인.
- OpenAI API Docs, Agents SDK — Choose your starting point, agent definition, handoffs, guardrails, observability, eval 흐름.
- OpenAI API Docs, Agent definitions, model, instructions, tools, guardrails, MCP, handoffs, structured outputs 구성.
- OpenAI API Docs, Using tools, Agents SDK에서 tool wiring과 specialist ownership을 나누는 기준.
- OpenAI API Docs, Retrieval, semantic search, vector store, ranking, chunking 기준.
- OpenAI API Docs, Integrations and observability — Tracing, model call, tool call, handoff, guardrail trace 기준.
- OpenAI API Docs, Evaluate agent workflows, trace grading, dataset, eval run 흐름.
- Anthropic Engineering, Building effective agents, workflow와 agent 구분, simplicity, tool documentation 기준.
- Anthropic Engineering, Demystifying evals for AI agents, agent eval의 난도와 production 전 검증 필요성.
- Anthropic Engineering, Writing effective tools for AI agents, tool definition과 evaluation-driven tool 개선 기준.
마무리 판단
AI agent engineer는 prompt를 버리는 사람이 아니다.
prompt가 시스템 안에서 제대로 작동하게 만드는 사람이다.
그래서 이 직무의 핵심은 더 긴 instruction이 아니다.
작은 system design.
명확한 tool contract.
검증 가능한 retrieval.
복구 가능한 reliability.
좁은 security boundary.
측정 가능한 eval과 trace.
사람이 믿고 쓸 product thinking.
이 7개가 있어야 agent가 데모를 지나 운영으로 간다.
agent가 답변만 할 때는 prompt가 빛난다.
agent가 행동하기 시작하면 engineering이 빛난다.
그리고 행동하는 agent를 만들 거라면, 이제 문장보다 배관을 봐야 한다.
배관은 티가 잘 안 난다.
하지만 터지면 모두가 안다.