Why Your Enterprise Tech Stack Isn’t Ready for AI Agents — Christopher Lovejoy & Saul Howard

한 줄 핵심

의료처럼 규제가 강한 기업 환경에서 AI 에이전트를 제대로 쓰려면 POC 성능만이 아니라 감사 추적, 데이터 격리, 인간 승인, 평가까지 포함한 운영 가능한 아키텍처를 처음부터 설계해야 한다.

시간별 요약

1. 0:00
   왜 의료가 어렵고, 무엇이 다른 규제 업무로 전이되는가 의료는 강한 규제, 엄격한 절차, 사람의 삶에 직접 영향을 주는 특성 때문에 AI 배포가 특히 어렵다. 이곳에서 얻는 교훈은 금융, 국방, 정부처럼 과정 준수가 중요한 다른 규제 산업에도 그대로 적용된다.
2. 1:57
   기업용 POC 엔터프라이즈 POC는 고객과 사용 사례를 정하고, 지표를 합의한 뒤, 짧은 기간에 제한된 인력으로 결과를 보여주는 방식으로 진행된다. 이 단계에서는 애플리케이션 계층, 제어면, 데이터면, 모델 제공자에 접근하는 형태로 빠르게 연결을 만든다.
3. 2:49
   실제 빌드가 연결되는 것 POC는 데이터 레이크와 애플리케이션 계층 등 여러 영역에서 데이터를 끌어와 성과를 내도록 구성된다. 성능 지표를 만족하면 이해관계자들은 만족하지만, 이 시점의 연결은 아직 운영 환경을 견딜 만큼 깊지 않다.
4. 3:39
   모두가 어려운 부분은 끝났다고 가정한다 사람들은 AI가 정확하게 동작했다는 사실만 보고 핵심 난제가 해결됐다고 착각하기 쉽다. 실제 난점은 그다음 날부터 시작되는 운영화이며, 감사 추적과 보안, 승인 흐름 같은 요구가 한꺼번에 등장한다.
5. 4:28
   다음 날 쏟아지는 질문들 운영 전환 단계에서는 민감한 데이터가 어떻게 흐르는지, 누가 결정을 승인하는지, 신뢰할 수 없는 데이터가 모델을 오염시키지 않는지, Epic나 Salesforce 같은 시스템과 어떻게 통합되는지 같은 질문이 나온다. 이 영상은 그중 감사 추적, 데이터 처리, 인간 승인, 평가를 중심으로 다룬다.
6. 5:19
   감사 추적은 개발자 로그가 아니다 감사 추적은 Datadog 같은 개발 로그가 아니라, 에이전트의 모든 행동과 데이터 접근, 권한 근거를 빠짐없이 남겨야 하는 법적·보안적 기록이다. 따라서 법정에서 설명 가능한 증거 체인을 제공할 수 있어야 하며, 설계 단계에서 무엇을 쉽게 만들지 먼저 정해야 한다.
7. 7:03
   불변 이벤트 로그와 그 대가 append-only 이벤트 로그는 시스템의 단일 진실 공급원 역할을 하며, 감사 가능성을 거의 자동으로 만들어 준다. 대신 쓰기는 쉬워지지만 읽기는 더 어려워지고, 이를 보완하려면 캐시와 스냅샷, 파생 뷰가 필요하다.
8. 8:46
   의료 데이터는 실제로 어떤 형태인가 의료 데이터는 PHI이고, 구조화·비구조화가 섞이며, 매우 크고, 엄격한 접근 제어를 요구한다. 어떤 고객은 데이터가 자체 환경, 예를 들면 on prem VPC 밖으로 나가는 것조차 허용하지 않기 때문에 저장 방식도 그 제약을 반영해야 한다.
9. 10:28
   로그 안이 아니라 옆에 두는 object storage 이벤트는 에이전트가 무엇을 했는지 기록하고, 실제 의료 데이터는 schema driven object storage에 분리해 둔다. 이렇게 하면 특정 시점의 데이터 상태를 되돌릴 수 있고, 감사와 재현 가능성을 유지하면서도 데이터 구조를 보존할 수 있다.
10. 11:20
    데이터를 보지 않고 에이전트를 디버깅하기 로그와 데이터 저장소를 분리하면 개발자는 PHI를 직접 보지 않고도 에이전트가 어떤 단계를 거쳤는지 추적하고 관찰할 수 있다. 같은 구조는 zero trust에 유리하며, 토큰을 통해 필요한 시점에만 데이터 접근을 허용하게 만든다.
11. 12:15
    Zero trust와 lethal trifecta zero trust와 토큰 기반 접근 제어는 에이전트가 한 번 받은 데이터와 다른 민감 데이터에 동시에 접근하지 못하게 만드는 핵심 장치다. 이렇게 하면 prompt injection과 lethal trifecta 위험을 줄일 수 있다.
12. 13:07
    예측할 수 없을 때의 에스컬레이션 에스컬레이션은 언제 발생할지 사전에 정확히 알기 어렵고, 규칙 기반이든 불확실성 기반이든 동적으로 일어난다. 따라서 인간 승인 경로를 예측 가능한 예외가 아니라 시스템의 정상 흐름으로 설계해야 한다.
13. 13:58
    인간과 모델을 같은 종류의 에이전트로 다루기 인간과 LLM을 같은 추상화로 다루면, 어느 단계에서든 모델이 하던 일을 사람이 이어서 수행하고 그 다음 단계도 그대로 진행할 수 있다. 또한 공통의 context 정의를 두면 같은 정보를 prompt나 UI로 각각 변환하기 쉬워진다.
14. 14:49
    왜 평가가 어려운가 LLM은 비결정적이어서 작은 변화가 출력에 어떤 영향을 줬는지 분리하기 어렵고, 오프라인 데이터셋은 실제 운영 데이터를 대표하지 못하거나 시간이 지나며 낡아질 수 있다. 그래서 일반적인 평가 방식만으로는 생산 환경 품질을 안정적으로 재기 어렵다.
15. 15:39
    기본 원리에서 자연스럽게 생기는 평가 불변 이벤트 로그는 특정 시점으로 재생해 prompt, model, code 변경의 직접 효과를 확인하게 해 준다. 인간과 에이전트를 같은 작업 축에서 비교하면 eval score를 얻을 수 있고, object storage를 쓰면 고객 환경의 생산 데이터 위에서도 민감정보를 노출하지 않고 평가할 수 있다.
16. 17:20
    무엇을 단순하게 남길지 정하는 아키텍처 아키텍처는 제약을 진지하게 받아들이고, 시스템 안에서 무엇을 단순하게 유지할지 선택하는 일이다. 기존 기업 시스템의 패턴을 AI에 맞게 새 조합으로 엮되, 처음부터 생산 수준의 제약을 기준으로 설계해야 한다.
17. 18:08
    어디서 실패하고, 어디서 성공하는가 실패는 POC의 높은 정확도 위에 eval, security, auditability를 뒤늦게 덧붙일 때 생기며, 시스템이 취약하고 일반화하기 어려워진다. 반대로 성공은 처음부터 운영 가능한 엔터프라이즈 제약을 전제로 primitives를 쌓고, 그 위에서 다시 POC 수준의 성능을 복원하는 방식에서 나온다.

실무 인사이트

• 기업용 AI 에이전트는 모델 성능보다 감사 추적, 접근 제어, 재현 가능성 같은 운영 기초가 먼저 갖춰져야 한다.
• PHI나 민감 데이터를 다루는 환경에서는 이벤트 로그와 데이터 저장소를 분리해 observability와 데이터 접근을 분리하는 설계가 유리하다.
• 평가는 별도 기능으로 붙이기보다, 불변 로그·인간 승인·데이터 격리 같은 기본 원리 위에서 자연스럽게 나오도록 설계하는 편이 더 강하다.