[Finaitech 5대 원칙 1/5] 똑똑한 AI보다 통제 가능한 AI가 먼저다.

'finaitech' 선언문에서 우리는 5가지 원칙을 이야기했습니다. 오늘 그 첫 번째 원칙인 **"똑똑한 AI보다 통제 가능한 AI가 먼저다"**에 대해 깊이 파고 들어가 보겠습니다.

 

AI Agent를 도입한다고 할 때, 우리는 종종 '얼마나 똑똑한가'에만 집중합니다. "이 AI가 얼마나 사람처럼 말하는가?", "얼마나 복잡한 업무를 처리하는가?" 같은 질문이 앞섭니다.

 

하지만 금융 아키텍트의 관점은 달라야 합니다.

---

'슈퍼 인턴'에게 '대표이사 카드'를 주는 격

새로운 AI Agent를 도입하는 것을, **'엄청나게 유능한 신입 인턴'**을 채용하는 것에 비유해 봅시다.

 

이 인턴(AI-Agent)은 24시간 일하고, 지치지 않으며, 수백만 건의 데이터를 순식간에 분석합니다. 정말 '똑똑'합니다.

그런데 이 '슈퍼 인턴'에게 이런 권한을 준다면 어떨까요?

• 전 고객의 개인정보와 계좌 원장을 마음대로 열람할 권한
• 아무런 결재선 없이 자금을 이체할 수 있는 권한
• 누가 시켰는지 기록도 남기지 않고 시스템 설정을 변경할 권한

상상만 해도 끔찍한 금융 사고로 이어질 수 있습니다. 아무리 똑똑해도 '통제'되지 않는 인턴은 '시한폭탄'일 뿐입니다. AI Agent도 마찬가지입니다.

 

'통제 가능한 AI'를 만든다는 것은 거창한 개념이 아닙니다. 딱 3가지로 요약됩니다.

1. 신원 (Identity): 이 Agent는 '누구'인가?
2. 권한 (Permission): 이 Agent는 '무엇을' 할 수 있는가?
3. 감사 (Audit): 이 Agent는 '무엇을' 했는가?

---

1. 신원 (Identity): AI에게 '사원증'을 발급하라

사람 직원이 사내 시스템에 접근할 때 ID와 비밀번호를 쓰듯, AI Agent도 시스템에 접근할 땐 고유한 '신원'이 필요합니다.

[구체적인 예] '여신 심사 Agent'와 '마케팅 Agent'라는 두 AI가 있다고 가정해 봅시다.

• '여신 심사 Agent'(agent-loan-reviewer)가 고객 신용 점수를 조회할 때, 시스템은 "아, '여신 심사팀' 소속의 AI가 정상적인 업무로 조회하는구나"라고 알아야 합니다.
• 만약 '마케팅 Agent'(agent-marketing)가 동일한 신용 점수를 조회하려 한다면, 시스템은 "어? '마케팅팀' AI가 왜 이 민감 정보에 접근하려 하지?"라며 접근을 차단해야 합니다.

이를 구현하는 방법은 다양하지만, AI Agent가 실행되는 **'플랫폼 계층(Platform Layer)'**의 통제를 예로 들어보겠습니다. 우리가 쿠버네티스(K8s) 환경에서 Agent를 운영한다면, 다음과 같이 '신원'을 정의할 수 있습니다.

 

[소스코드 예시: AI Agent 신원 정의 (개념적 YAML)]

YAML

# K8s ServiceAccount 정의 예시

# "AI Agent에게 'agent-loan-reviewer'라는 이름의 사원증을 발급합니다."

 

apiVersion: v1

kind: ServiceAccount

metadata:

  name: agent-loan-reviewer  # AI Agent의 고유 ID (신원)

  namespace: finance-ai-agents

 

설명: 위 코드는 agent-loan-reviewer라는 고유한 ID(신원)를 생성합니다. 이제 이 Agent가 시스템 어딘가에 접속하면, "저는 agent-loan-reviewer입니다"라는 사원증을 제시하게 됩니다.

---

2. 권한 (Permission): '업무 분장표'를 명확히 하라

'사원증'이 생겼다면, 이제 그 사원증으로 '무엇을 할 수 있는지' 정해줘야 합니다. 이것이 **'권한 관리(RBAC: Role-Based Access Control)'**입니다.

 

핵심 원칙은 **'최소 권한의 원칙(Principle of Least Privilege)'**입니다. AI Agent는 자신의 업무를 수행하는 데 필요한 '최소한의' 권한만 가져야 합니다.

 

[구체적인 예] '여신 심사 Agent'(agent-loan-reviewer)의 업무 분장표(권한)는 다음과 같아야 합니다.

• [허용] 고객 신용 정보 DB - 읽기(Read)
• [불가] 고객 계좌 - 이체(Write)
• [불가] 마케팅팀 DB - 접근 불가(No Access)

[소스코드 예시: AI Agent 권한 부여 (개념적 YAML)] '여신 심사 AI'의 '업무 분장표'를 **'플랫폼 계층(K8s)'**에서 코드로 정의해 봅시다.

YAML

# K8s Role 정의 예시

# "'agent-loan-reviewer' 사원증을 가진 AI의 업무 분장표(Role)입니다."

 

apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

  namespace: finance-ai-agents

  name: loan-reviewer-role

rules:

- apiGroups: ["db.finaitech.com"]  # (가상의) 고객 DB API 그룹

  resources: ["credit-scores"]       # '신용 점수'라는 자원에 대해

  verbs: ["get", "list", "watch"]    # '읽기' (조회, 목록보기) 권한만 부여

 

---

# K8s RoleBinding 정의 예시

# "위에서 만든 '업무 분장표'를 'agent-loan-reviewer' 사원증에 연결합니다."

 

apiVersion: rbac.authorization.k8s.io/v1

kind: RoleBinding

metadata:

  name: bind-loan-agent-to-role

  namespace: finance-ai-agents

subjects:

- kind: ServiceAccount

  name: agent-loan-reviewer  # '누구에게' (신원)

roleRef:

  kind: Role

  name: loan-reviewer-role   # '무슨 권한을' (업무 분장표)

  apiGroup: rbac.authorization.k8s.io

 

설명: 위 코드는 agent-loan-reviewer라는 AI에게 credit-scores라는 데이터에 대한 읽기(get, list) 권한만 정확히 부여합니다. 만약 이 Agent가 이체(transfer)나 삭제(delete)를 시도하면, 시스템은 이 '업무 분장표'에 없으므로 즉시 차단합니다.

---

3. 감사 (Audit): '업무 일지'를 빠짐없이 기록하라

마지막으로, 이 Agent가 언제, 어디서, 무엇을 했는지 모든 행적을 **'감사 로그(Audit Trail)'**로 남겨야 합니다.

 

이는 단순히 'CCTV'를 설치하는 것과 같습니다. 평소에는 아무도 보지 않지만, 사고가 터졌을 때 이 로그는 '누가' 잘못했는지 알려주는 유일한 증거가 됩니다.

 

[구체적인 예] 새벽 3시에 특정 고객의 계좌 잔액이 0원이 되는 사고가 발생했습니다. 담당자가 즉시 로그를 확인합니다.

 

[소스코드 예시: AI Agent 감사 로그 (개념적 JSON Log)]

JSON

[

  {

    "timestamp": "2025-10-24T02:59:59Z",

    "actor_id": "agent-fraud-detector", // '누가' (사기 탐지 AI)

    "action": "READ",

    "resource": "customer:12345:transactions",

    "status": "SUCCESS"

  },

  {

    "timestamp": "2025-10-24T03:00:01Z",

    "actor_id": "UNKNOWN (IP: 123.45.67.89)", // '누가' (!!신원 불명!!)

    "action": "WRITE",

    "resource": "customer:12345:balance",

    "data": { "new_balance": 0 },

    "status": "!!FAILURE: FORBIDDEN!!" // (권한 없음으로 실패)

  },

  {

    "timestamp": "2025-10-24T03:00:02Z",

    "actor_id": "agent-fraud-detector", // '누가' (사기 탐지 AI)

    "action": "ALERT",

    "resource": "security-team",

    "message": "Unauthorized WRITE attempt detected on customer:12345",

    "status": "SUCCESS"

  }

]

 

설명: 이 로그를 통해 우리는 AI Agent(agent-fraud-detector)가 아니라 '신원 불명의 존재'가 공격을 시도했으나, '권한(Permission)' 설정(원칙 2) 덕분에 실패했음을 1분 만에 파악할 수 있습니다. 이것이 '통제 가능한 AI' 시스템입니다.

---

통제는 '겹겹의 방어막'입니다 (Defense in Depth)

지금까지 우리는 AI Agent가 실행되는 **'플랫폼 계층(K8s)'**에서의 통제 방법을 예시로 들었습니다. 하지만 실제 금융 시스템의 '통제'는 단 하나의 방어막으로 끝나지 않습니다.

 

성공적인 거버넌스는 여러 계층에서 겹겹이 방어막을 치는 '심층 방어(Defense in Depth)' 전략을 따릅니다.

1. 애플리케이션 계층: AI Agent가 호출하는 서비스(MSA) 내부에서 Spring Security 등을 통해 "이 Agent가 이 업무(비즈니스 로직)를 수행할 자격이 있는가?"를 검증합니다.
2. API 게이트웨이 계층 (원칙 2): 시스템의 '정문'에서 "이 Agent가 이 API를 호출할 자격이 있는가?"를 검문합니다.
3. 플랫폼 계층 (오늘의 예시): K8s 등에서 "이 Agent가 다른 서비스(Pod)에 아예 통신할 수 있는가?"를 제어합니다.
4. 인프라/네트워크 계층: "이 Agent가 실행되는 VM/서버가 애초에 운영 DB 네트워크에 접근할 수 있는가?"를 통제합니다.

어느 한 계층이 뚫리더라도, 다음 계층의 방어막이 위험을 차단할 수 있어야 합니다. 이것이 '원칙 1'이 추구하는 진정한 '통제 가능한 AI' 아키텍처입니다.

---

결론: '통제'는 '혁신'의 브레이크가 아닌 '안전벨트'입니다.

첫 번째 원칙 "똑똑한 AI보다 통제 가능한 AI가 먼저다"는 AI 도입을 늦추자는 이야기가 아닙니다.

오히려 더 빠르고 과감한 혁신을 위해 '안전벨트'를 먼저 매자는 뜻입니다.

1. **신원(Identity)**을 부여해 AI를 식별하고,
2. **권한(Permission)**을 설정해 AI의 행동 범위를 제어하며,
3. 감사(Audit) 로그를 통해 모든 활동을 투명하게 추적할 수 있을 때,

우리는 비로소 AI Agent라는 강력한 '슈퍼 인턴'에게 안심하고 더 많은 일을 맡길 수 있습니다.

 

다음 글에서는 이 '통제'를 구현하는 가장 강력한 아키텍처 패턴인 "원칙 2: AI Agent의 데이터 접근은 API 게이트웨이를 통하라" 편으로 찾아뵙겠습니다.