AI에게 일을 맡기는 시대, 인간은 무엇을 설계해야 하는가.
금융 AI에서 에이전트를 이야기할 때, 많은 사람은 먼저 “AI가 어디까지 자동화할 수 있을까?”를 떠올린다. 리포트를 작성하고, SQL을 만들고, 포트폴리오를 분석하고, 이상 거래를 탐지하고, 고객 문의에 답변하는 장면을 상상한다.
하지만 금융 AI를 실무 관점에서 보면 질문은 조금 달라진다.
“AI가 할 수 있는가?”보다 더 중요한 질문은 “AI가 틀렸을 때 시스템은 어떻게 반응하는가?”이다.
금융은 일반적인 소프트웨어와 다르다. 잘못된 추천 하나가 고객 손실로 이어질 수 있고, 잘못된 쿼리 하나가 왜곡된 의사결정을 만들 수 있으며, 잘못된 자동화 하나가 거래, 결제, 리스크 관리, 규제 대응에 직접적인 영향을 줄 수 있다.
그래서 금융 AI에서 에이전트는 단순한 생산성 도구가 아니다. 돈, 리스크, 규제, 평판과 연결된 실행 주체가 된다.
이 지점에서 필요한 개념이 바로 에이전틱 엔지니어링(agentic engineering)이다.
에이전틱 엔지니어링은 AI agent에게 더 많은 일을 자유롭게 맡기는 것이 아니다. 오히려 반대에 가깝다.
AI가 더 많은 일을 할수록, 우리는 그 주변에 더 정교한 구조를 만들어야 한다. 도구 접근 권한을 제한하고, 실행 과정을 기록하고, 중간 결과를 검증하고, 잘못된 상태가 만들어지지 않도록 설계하고, 사람이 이해할 수 있는 형태로 결과를 남겨야 한다.
예를 들어 금융 AI agent가 SQL을 작성한다고 해보자. 중요한 것은 “SQL을 생성했는가”가 아니다.
정말 중요한 질문은 다음과 같다.
- 허용된 테이블만 조회했는가?
- 민감 정보 컬럼에 접근하지 않았는가?
- metric definition을 정확히 사용했는가?
- 결과가 기존 대시보드와 일관되는가?
- 비용이 과도하게 발생하지 않았는가?
- 실행 로그와 의사결정 근거가 남아 있는가?
- 사람이 최종 결과를 이해하고 승인할 수 있는가?
이런 구조가 없다면 AI agent는 데모에서는 인상적일 수 있지만, 운영 환경에서는 위험하다.
금융 AI에서 좋은 에이전트 시스템은 “똑똑한 모델” 하나로 완성되지 않는다. 오히려 좋은 시스템은 여러 겹의 안전장치로 만들어진다.
첫 번째는 도메인 불변성(domain invariant)이다. 금융 시스템에는 절대 깨지면 안 되는 상태들이 있다.
예를 들어 승인된 결제인데 승인 코드가 없다든지, 리스크 판단은 있는데 판단 근거가 없다든지, 정산 완료 상태인데 정산 일자가 없다든지, 신용평가 결과는 있는데 사용된 모델 버전이 기록되지 않았다든지 하는 상태는 애초에 만들어지면 안 된다.
좋은 엔지니어링은 이런 오류를 나중에 감지하는 것이 아니라, 처음부터 표현할 수 없게 만드는 것이다.
두 번째는 빠른 피드백 루프다. AI agent는 피드백을 받을 때 더 잘 작동한다. 타입 에러, 테스트 실패, 시뮬레이션 결과, 과거 데이터 리플레이, dry-run 결과는 모두 agent에게 중요한 신호가 된다.
금융에서는 특히 historical replay가 중요하다. 새로운 fraud rule, 새로운 credit scoring strategy, 새로운 trading signal, 새로운 portfolio constraint를 바로 운영에 넣는 것이 아니라, 과거 데이터 위에서 먼저 재현해봐야 한다.
이 agent가 만든 전략이 과거 위기 구간에서는 어떻게 작동했는가? 특정 고객군에 과도하게 불리하게 작동하지는 않았는가? 승인율은 올렸지만 fraud loss를 키우지는 않았는가? 수익률은 좋아 보이지만 turnover와 transaction cost를 무시한 것은 아닌가?
이런 검증이 없으면 금융 AI는 “자동화”가 아니라 “자동화된 리스크”가 된다.
세 번째는 사람이 이해할 수 있는 trace다. AI가 만든 결과가 맞는지 보려면 최종 답만 봐서는 부족하다. 어떤 데이터를 봤고, 어떤 가정을 했고, 어떤 중간 판단을 거쳤고, 어디서 불확실성이 있었는지가 남아야 한다.
특히 금융에서는 설명 가능성이 단순히 모델 해석의 문제가 아니다. 그것은 운영 책임의 문제다.
누군가 물었을 때 답할 수 있어야 한다.
“왜 이 거래를 막았는가?” “왜 이 고객의 한도를 낮췄는가?” “왜 이 포트폴리오 리밸런싱을 추천했는가?” “왜 이 리포트의 수치가 기존 대시보드와 다른가?”
AI agent가 만든 결과라도, 최종 책임은 시스템을 운영하는 조직과 사람에게 있다. 그래서 금융 AI에서 trace, audit log, reason code, evidence reference는 선택사항이 아니라 핵심 설계 요소다.
네 번째는 코드 리뷰와 사람의 이해다. AI가 코드를 만들 수 있다고 해서 코드 리뷰가 사라지는 것은 아니다. 오히려 더 중요해진다.
AI는 테스트를 통과하는 코드를 만들 수 있다. 하지만 테스트를 통과한다고 해서 좋은 코드인 것은 아니다.
금융 시스템에서 중요한 것은 단순히 “작동하는 코드”가 아니다. 단순하고, 읽을 수 있고, 검증 가능하고, 확장 가능하고, 잘못된 사용을 막을 수 있는 코드여야 한다.
AI agent는 종종 눈앞의 목표를 달성하기 위해 이상한 우회로를 선택한다. 테스트를 통과시키라고 하면 근본 원인을 고치는 대신 테스트 자체를 약화시킬 수도 있다. 기능을 만들라고 하면 중복 코드, 하드코딩, 취약한 예외 처리, 모호한 권한 처리를 남길 수도 있다.
그래서 금융 AI에서 code review의 목적은 단순히 버그를 찾는 것이 아니다. 사람이 시스템을 이해하고 책임질 수 있는 상태로 유지하는 것이다.
앞으로 금융 AI의 경쟁력은 모델 성능만으로 결정되지 않을 것이다. 오히려 중요한 차이는 모델 주변의 운영 구조에서 나올 가능성이 크다.
누가 더 좋은 agent harness를 갖고 있는가? 누가 더 안전한 tool registry를 설계했는가? 누가 더 빠른 검증 루프를 만들었는가? 누가 더 명확한 audit trail을 남기는가? 누가 agent가 만든 결과를 사람이 이해할 수 있게 만드는가?
이것이 금융 AI에서의 진짜 차별점이 될 것이다.
결국 금융 AI에서 에이전틱 엔지니어링은 이런 철학에 가깝다.
AI를 믿어서 자동화하는 것이 아니라, AI가 틀릴 수 있음을 전제로 자동화하는 것.
좋은 금융 AI 시스템은 모델이 항상 맞을 것이라고 가정하지 않는다. 모델이 틀릴 수 있고, 맥락을 놓칠 수 있고, 과도하게 자신감 있게 답할 수 있고, 예상하지 못한 방식으로 도구를 사용할 수 있다고 가정한다.
그리고 그럼에도 불구하고 시스템이 안전하게 작동하도록 설계한다.
이것이 금융 AI에서 agent를 바라보는 가장 현실적인 관점이다.
AI agent는 금융 업무를 빠르게 만들 수 있다. 하지만 금융에서 중요한 것은 속도만이 아니다.
속도를 통제 가능한 구조 안에 넣는 것. 자동화를 검증 가능한 시스템 안에 넣는 것. 모델의 능력을 인간의 이해와 책임 안에 두는 것.
그것이 금융 AI에서 에이전틱 엔지니어링이 중요한 이유다.
함께 보면 좋은 글: AI Agent는 더 좋은 프롬프트가 아니라 더 좋은 Harness에서 나온다