에이전트 신뢰성 엔지니어링: 소프트웨어 엔지니어의 새로운 영역
이 분야가 중요한 이유
요즘 프로덕션 에이전트는 단일 프롬프트로 돌지 않는다. 검색 모듈, 도구 호출 모듈, 안전 가드, 요약기, 서브에이전트 여럿을 시스템 프롬프트와 도구 정의로 한 컨텍스트 안에 겹겹이 쌓아 조립한다. 문제는 이렇게 붙여 놓으면 한 모듈에 준 지시가 옆 모듈로 새어 흐른다는 데 있다. 2026년 6월 arXiv에 올라온 “Instruction Bleed”(2606.26356)는 이 현상을 정면으로 다룬다. 한 모듈에 “간결하게 답하라"고 적어 두면, 정작 무관해야 할 안전 검증 모듈까지 검사를 대충 건너뛰는 식으로 행동이 오염된다. 데모에서는 멀쩡하던 에이전트가 프로덕션에서 설명 못 할 실패를 내는 원인의 상당수가 여기서 나온다.
근본 원인은 LLM이 모든 텍스트를 같은 무게로 읽는다는 점이다. OpenAI가 “Instruction Hierarchy"에서 짚었듯, 모델은 개발자 시스템 프롬프트와 사용자 입력, 도구 출력을 본래 같은 우선순위로 취급한다. 모듈이 늘어날수록 누가 누구의 지시를 침범하는지 통제하기 어려워지고, 한 줄 추가가 시스템 반대편에서 회귀를 일으킨다. 그래서 모델을 더 키우는 일과 별개로, 조립된 시스템이 의도대로 격리되어 도는지를 책임지는 자리가 갈라져 나왔다. 이게 에이전트 신뢰성 엔지니어다. 모델 정확도가 아니라 시스템 신뢰도를 지키는 사람이고, 멀티모듈 에이전트가 표준이 된 지금 빠르게 전담 직무로 굳고 있다.
필요한 역량
이 일은 신뢰성 엔지니어링(SRE) 감각 위에 LLM 시스템 특유의 비결정성 통제를 얹은 교집합이다. 도구를 만드는 일도, 오케스트레이션을 짜는 일도 아니다 — 조립된 모듈들이 서로를 오염시키지 않게 경계를 긋고, 그 경계가 지켜지는지 끝없이 측정하는 일이다.
- 프롬프트 모듈 격리. 시스템 프롬프트, 도구 정의, 서브에이전트 지시를 한 컨텍스트에 욱여넣지 않고 명확한 경계로 나눈다. 어떤 지시가 어느 범위까지만 유효한지 설계하고, 무관한 모듈이 서로의 톤·정책·제약을 끌어다 쓰지 못하게 막는다.
- 지시 스코핑과 우선순위. 신뢰된 시스템 지시, 사용자 입력, 도구가 되돌려 준 텍스트의 권한 등급을 분리한다. 인스트럭션 하이어라키 개념을 실제 프롬프트 구조로 번역해, 낮은 권한 텍스트가 높은 권한 정책을 덮어쓰지 못하게 한다.
- 간섭 평가 하니스. 모듈 A에 지시를 바꿔 넣고 모듈 B의 행동이 흔들리는지 자동으로 잡아내는 회귀 스위트를 짠다. 골든셋·시나리오·적대적 케이스를 CI에 묶어, 프롬프트 한 줄 수정이 멀리 떨어진 모듈을 깨뜨리는 순간 빨간불이 켜지게 한다.
- 런타임 가드. 배포 후에도 도는 방어선을 둔다. 지시 누출이 의심되는 출력 차단, 정책 위반 감지, 모듈 경계를 넘는 이상 행동에 대한 서킷 브레이커와 롤백을 건다.
- 관찰 가능성. 모든 모듈 호출과 지시 주입 지점을 트레이싱한다. 실패가 났을 때 어느 모듈의 어떤 지시가 어디로 새어 흘렀는지 사후에 읽어낼 수 있어야 한다.
커리어 경로
수요는 분명한데 공급이 얇다. 에이전트를 데모까지 만들어 본 사람은 많아도, 모듈 수십 개가 얽힌 프로덕션 시스템을 신뢰성 관점에서 디버깅해 본 사람은 드물다. “데모는 도는데 모듈 하나 추가했더니 엉뚱한 곳이 깨진다"를 설명하고 막을 수 있느냐가 채용의 핵심이다. 그래서 평범한 백엔드도, 순수 ML 리서처도 아닌 어중간한 교집합 — SRE·플랫폼 경험에 LLM 시스템 감각을 더한 미드~시니어가 무게중심이다.
진입 경로는 두 갈래다. SRE·플랫폼·신뢰성 엔지니어로 출발해 사내 에이전트 인프라를 맡으며 비결정성 통제로 넘어오거나, AI 엔지니어링·프롬프트 쪽에서 일하다 평가와 런타임 안전 레이어로 내려오는 식이다. 직함은 아직 굳지 않아 Agent Reliability Engineer, AI Reliability Engineer, Agent Safety Engineer 등으로 흩어져 있고, 보상은 동급 SWE보다 10~20% 위를 얹는 곳이 늘고 있다. 네카라쿠배든 막 시리즈 A를 받은 스타트업이든, 에이전트를 프로덕션에 띄운 조직이라면 이 역할이 더는 선택이 아니라 플랫폼 팀의 정식 업무가 됐다.
가장 빠른 검증법은 직접 깨뜨려 보는 것이다. 모듈 서너 개짜리 작은 에이전트를 만들어, 한 모듈에 일부러 강한 지시를 넣고 다른 모듈의 출력이 어떻게 오염되는지 측정한다. 그다음 격리와 스코핑을 손보고, 간섭 회귀 스위트를 CI에 붙이고, 출력에 런타임 가드를 건다. 이 한 사이클을 돌려 본 경험이 이력서의 어떤 키워드보다 강하다.