여러분의 AI 서비스, 정말 안전할까요?

오간 이야기

시작 전에 처음 오신 분들께 요즘 고민을 여쭤봤는데, 그게 그날 주제를 그대로 예고했습니다. 구청에서 오신 주무관님은 바이브 코딩으로 구축은 순식간에 되는데 운영과 유지보수를 어떻게 해야 할지가 부서의 고민이라고 했습니다. 공직은 담당자가 길어야 2년이면 바뀌는데, 그렇게 만든 것을 뒤에 오는 사람이 이어받기가 쉽지 않다는 것입니다. 자산운용사에서 오신 펀드매니저님은 네다섯 명이 쓰는 프로그램을 만들어 함께 쓰고 있는데 이걸 전사로 확장하려면 어떻게 해야 하는지를 물으러 오셨습니다. 1인 기업을 하시는 대표님은 데이터가 외부로 나가는 것을 꺼리는 작가들을 위해 자체 구축까지 해봤지만 여러 업체와 함께하려니 어렵더라고 했습니다. 세 분 다 같은 자리에서 막혀 있었습니다.

첫 세션은 LG CNS의 전창원 님이었습니다. 2020년에 입사해 작년까지 AI 연구소에 계시다가 올해 플랫폼 조직으로 옮겨 에이전트 플랫폼을 만들고 계십니다. 그전에는 CCTV 딥러닝을 하셨습니다. 데모가 왜 운영으로 넘어가지 못하느냐는 질문에 되물으셨습니다. 클로드 코드에서 각자 만든 플러그인이나 스킬을 남들이 쓸 수 있느냐는 것이었습니다. 이유는 단순했습니다. 만들 때 자기 자신을 고객으로 두고 만들기 때문입니다. B2B는 회사의 많은 사람이 쓰는데, 정해진 대로 넣어야 동작하던 예전 룰 기반 챗봇과 같은 구조가 된다는 이야기였습니다.

영상에서 LLM으로 옮겨오니 지금이 훨씬 어렵다고 하셨습니다. 영상 처리는 사람이 맞다처럼 답이 딱 떨어지는데, 지금은 temperature를 0으로 맞추고 같은 데이터에 같은 프롬프트를 넣어도 답이 조금씩 바뀝니다. 고객은 왜 바뀌느냐고 묻고, 통계적으로 그렇다고 설명하면 그냥 똑같이 해달라고 합니다. 그래서 테스트 데이터셋을 두 벌로 만드신다고 했습니다. 내부 용어를 다 아는 Expert 기준과, 일상적인 말로 묻는 Newcomer 기준입니다. 만드는 사람은 제품 이름을 다 아는 상태로 질문을 만들고 고객은 모르니 그 간극을 메우려는 것인데, 그렇게까지 해도 잘 안 된다고 덧붙이셨습니다. 중간에 있는 사용자를 위해서는 용어를 맞춰주는 해석이나 프롬프트 리라이트 제안 같은 기능을 앞단에 넣는다고 했습니다.

CCTV를 개발할 때 Python으로 구현한 부분의 속도 문제로 C로 다시 쓴 경험도 같은 이야기였습니다. 기능이 맞게 동작하는 것과 필요한 시간 안에 처리하는 것은 별개라는 뜻입니다. 지금 에이전트도 마찬가지여서, 답이 한 번 나온 것과 여러 요청을 감당하는 것은 다릅니다. 동시 요청과 응답 시간 같은 시스템 조건부터 확인해야 하는데 여기에 사용자의 질문 방식까지 달라지면, 소수의 데모만으로 준비가 끝났다고 보기 어렵다고 했습니다.

가장 와닿았던 예시는 주간보고였습니다. 3년치 텍스트를 남겨두셔서 지금은 1분 만에 본인이 쓴 것처럼 나온다고 합니다. 그런데 본인은 불릿으로 짧게 쓰는 편이고 길게 쓰는 사람도 있습니다. 한 사람에게 최적화된 스킬을 여러 사람이 쓰기 시작하면 각자 고치고, 고친 것들이 서로 부딪힙니다. 데모가 운영으로 넘어가지 못하는 이유가 기술이 아니라 여기 있다는 이야기였습니다. 그래서 먼저 고객들이 쓰는 방식의 평균치에 맞추고, 고객 인터뷰에서 너무 튀는 요구는 접는다고 했습니다. 개인의 소망을 말하는 경우가 있어서 그걸 다 받으면 감당이 안 된다는 것입니다.

어느 금융 지주와 한 PoC 이야기가 이어졌습니다. 불안해서 답을 길게 달았더니 고객이 처음에는 내용이 다 있다며 좋아했는데, 시간이 지나며 반응이 달라졌습니다. 글자를 크게 해서 화면을 작게 보는 분들에게는 정확하게 쓴 답이 화면에 들어오지 않았던 것입니다. 처음부터 100%를 생각하고 만들지 말고 최소한의 기능으로 시작해 덧붙이며, 만든 것을 엎을 생각으로 해야 한다고 했습니다. 토큰을 많이 썼으니 유지하고 싶다고 고집을 부리면 결국 고객에게 지적을 받는다는 것입니다. 긴 RAG 답변도 같은 문제로 짚었습니다. 사용자는 이미 잘 다듬어진 서비스를 쓰고 있으니, 답이 나온다는 것만으로는 부족하고 기존 도구보다 자기 업무에서 무엇이 더 편한지가 있어야 한다고 했습니다.

검증 방식도 구체적이었습니다. 900개에서 1,000개 가까운 데이터셋을 만들어두고 바뀔 때마다 계속 돌리고, 평가를 교차로 시킵니다. 클로드로 뽑은 것은 GPT에게 평가시키고 여유가 있으면 제미나이까지 돌린다고 했습니다. 순서도 강조하셨습니다. 코딩하는 사람 대부분은 플랜은 짜는데 결과에는 신경을 덜 쓰고, 테스트셋은 나중에 하겠다고 하면 결국 안 만들게 된다는 것입니다. 최종적으로 잘 나왔는지는 고객의 피드백으로 안다고 했습니다. 로그를 다 쌓고 좋아요·싫어요 같은 장치로 받는데, 잘했을 때는 아무도 누르지 않고 못했을 때는 과감하게 누른다는 관찰이 붙었습니다.

비용 통제를 묻다가 모델 라우터 이야기가 나왔습니다. 콘셉트는 괜찮지만 라우터 자체도 작은 LLM으로 판단하기 때문에 빨라야 하고 성능까지 좋기는 애매합니다. 결정적인 문제는 A/B 테스트가 되지 않는다는 점이었습니다. 작은 모델도 웬만하면 답변을 다 하기 때문에, 제대로 답한 것인지 하나하나 따지지 않으면 라우터의 성능을 비교할 방법이 없다는 것입니다. 아직은 의심의 눈초리로 본다고 하셨습니다.

보안은 처음부터 시스템을 만드는 경우가 없다고 했습니다. 기업들은 이미 위키나 협업 도구를 쓰고 있고 거기 보안이 걸려 있으니, 모델에서 막는 대신 사용자의 데이터 접근 권한에 따라 롤 기반으로 권한을 매기고 최종단에 가드레일을 얹어 이중 삼중으로 갑니다. 거버넌스에 대한 관점이 특히 인상 깊었습니다. 그룹 차원의 에이전트 플랫폼 TF에서 기술 검토를 맡으셨을 때, 감시하고 막는 일이 아니라 계열사마다 비슷한 에이전트를 중복해서 만들기보다 함께 쓸 수 있게 하는 쪽을 고민하셨다고 했습니다. 막기 위한 규칙만이 아니라 안심하고 나눠 쓰기 위한 규칙이기도 했다는 것입니다. 권한의 출발점은 사용자의 기존 권한이고, 임원도 직함만으로 모든 데이터를 보는 것이 아니라 실제 부여된 권한 안에서 접근합니다. 에이전트가 들어왔다고 그 경계를 넓혀서는 안 된다고 했습니다. 사용자가 할 수 있는 일이라고 해서 에이전트가 전부 자동으로 해도 되는 것은 아니어서, 조회와 외부 전송과 중요한 정보의 변경은 영향이 다르니 영향이 큰 행동에는 추가 승인이나 중단 조건을 둬야 한다고 덧붙였습니다.

객석에서 FDE와 온톨로지에 대한 질문이 나왔습니다. 회사의 공식 입장이 아니라 개인 견해라는 단서를 달고 두 가지 모두에 회의적이라고 답하셨습니다. 온톨로지는 맞는 것 같은데 당장 쓸 곳이 정확히 고민되지 않는다고 했고, FDE는 신입을 뽑아 그렇게 부르는 것이 고객이 기대하는 만족을 줄 수 있느냐가 다른 문제라고 했습니다. 근거로 든 사례가 분명했습니다. 어느 극장 체인의 편성 작업에서 딥러닝으로 표를 뽑아드렸더니 담당자가 애니메이션이 왜 심야에 있느냐고, 애니메이션은 아침에 해야 한다고 했다는 것입니다. 기술로는 나오지 않는 도메인 지식이었습니다. 어느 항공사 프로젝트에서는 4주 중 처음 2주를 미팅에만 들어가며 용어부터 익혔고 마지막 주에야 감을 잡으셨다고 했습니다.

두 번째 세션은 Datadog의 손우두 님이었습니다. 본인도 코딩을 잘 하지 않는다며, 고객들이 AI 에이전트를 개발할 때 어떤 고민을 하는지 직접 겪어보려고 사주 앱을 만들어 오셨습니다. 요청을 정리하는 분류, 생년월일로 계산하고 DB에서 해설을 조회하는 분석, 그 데이터로 LLM을 호출하는 해석까지 에이전트 셋으로 나뉜 구조였습니다. 발표 중에 네 가지를 물으셨습니다. 지금 AI가 어떤 작업을 무엇으로 처리하는지 보이는가, 토큰은 어디에 왜 쓰이는가, 답변을 믿어도 되는가, 민감정보 유출이나 공격이 들어왔을 때 감지할 수 있는가. 네 가지에 다 답할 수 있는 분이 있냐고 묻자 아무도 손을 들지 않았고, 본인도 답을 잘 못한다며 같이 배워가는 단계라고 했습니다.

가장 중요한 슬라이드는 3중 방어였습니다. 모델 학습으로 막고 입력 분류기로 막고 전문가 레드팀까지 붙여도 잔여 공격 성공률이 1%로 남습니다. 2025년 11월 기준 Claude Opus 4.5를 대상으로 적응형 공격을 100회 시도한 수치였습니다. 100회 중 1회이고 0%에 도달하지 못합니다. 미국 NIST는 프롬프트 인젝션 방어의 확실한 방법이 아직 없다고 했고, OWASP는 그것이 모델의 확률적 본질에서 기인한다고 했습니다. 영국 NCSC의 문장이 결론이었습니다. 그러므로 방어선을 행동 단계로 옮긴다는 것입니다. 실제 구현은 프롬프트 레벨에서는 통과시키되, 그 역할을 처리하는 에이전트 단에서 요청한 사용자에게 권한이 있는지와 정당한 요청인지를 판단해 런타임에 차단하는 방식이었습니다. 앞 세션에서 나온 경계를 넓혀서는 안 된다는 말과 같은 결론이었는데, 두 분이 사전에 맞춘 것이 아니었습니다.

시연보다 흥미로웠던 것은 객석이었습니다. 발표가 진행되는 동안 대시보드에 실제 요청이 쌓이고 있었는데, 시스템 프롬프트를 요구하는 입력들이 그대로 잡히고 있었습니다. 사전에 맞춘 것도 아닌데 이런 공격 패턴이 재미 삼아 해보는 수준으로 퍼져 있었던 것입니다. 나중에 토큰을 많이 쓴 사용자를 확인해보니 그 공격을 시도한 분이었습니다. 지금은 차단을 걸지 않고 모니터링 모드로만 두셨다고 했습니다. 그날 참석자들이 쓴 비용은 0.02달러 정도였고 모델별로 토큰과 비용이 나뉘어 보였습니다. 요청마다 시스템 프롬프트와 사용자 프롬프트를 다시 넣으면 토큰이 그만큼 나가기 때문에 프롬프트 레벨 캐싱으로 비용을 아낄 수 있다고 했습니다. 본인이 걸어둔 평가 항목 하나는 그 자리에서 결과가 뜨지 않았는데, 화면을 보시더니 아직 운영에는 못 올라갈 것 같다고 했습니다.

파이어사이드에서 앞서 인젝션을 시도했던 분이 뚫린 1%가 무엇이었는지 물었습니다. 본인이 AI를 운영하고 있어 막아야 하는 입장이라고 했습니다. 어떤 프롬프트가 뚫렸는지는 모르겠다고 하면서, 테스트하며 느낀 것은 결국 AI가 뚫는 것 같다는 이야기였습니다. 프롬프트를 조금씩 바꿔가며 시도하는데 사람이 하나하나 생각하는 것이 아니라 AI에게 요청하니 병렬로 연쇄해서 돌아가고, 거기서 잡히는 한두 케이스가 크리티컬하게 느껴진다는 것입니다. 인젝션 통제나 평가 지표는 UI에 기본 가이드라인이 들어 있고, 운영하면서 계속 바꿔간다고 했습니다. 이 인젝션이 왜 일반 프롬프트로 감지됐지 싶은 것을 보고 다음부터 인젝션으로 판단하게끔 항목을 추가하는 식입니다. 작은 팀이라면 무엇부터 시작해야 하느냐는 질문에는, 엔터프라이즈는 토큰 비용을 가장 많이 이야기하지만 본인은 가시성이 가장 중요하다고 답했습니다. 에이전트들이 어떤 역할을 어떻게 처리하는지가 보여야 비용도 평가도 자연스럽게 이어진다는 것입니다.

이 대목에서 앞 세션이 다시 떠올랐습니다. 전창원 님도 로그가 얼마나 많으냐보다 한 요청을 처음부터 끝까지 연결해서 볼 수 있느냐가 중요하다고 했기 때문입니다. 어떤 질문이 들어왔고 무엇을 검색했으며 어떤 모델과 도구를 거쳤는지, 어디서 느려지거나 재시도가 늘었는지를 함께 보는 것입니다. 그 기록만으로 답이 옳은지가 확정되지는 않지만 어디부터 확인할지는 좁힐 수 있다고 했습니다. 그리고 Datadog 데모에서 정확히 그 화면이 나왔습니다. 응답까지 40초가 걸린 요청이 있었는데 그 40초가 LLM 호출에서 걸린 것인지 내부 API 처리에서 걸린 것인지가 나뉘어 보였습니다. SI 회사에서 플랫폼을 만드는 사람과 옵저버빌리티 회사의 세일즈 엔지니어가 서로 모르는 채로 같은 문장에 도착해 있었습니다.

라운드테이블에서는 열 개 조의 이야기가 나왔습니다. 한 조는 개인이 AI를 잘 쓰는 것과 조직이 잘 쓰는 것 사이의 간극을 셋으로 정리했습니다. 회사가 전원 결제를 해줘도 누가 어떻게 쓰는지 보이지 않는다는 것, 팀원마다 아웃풋 모양이 달라 해석에 시간이 더 든다는 것, 비개발 조직에는 PR 리뷰 같은 중간 단계가 없어 만든 사람 한 명이 다 떠안는다는 것입니다. 셋 다 규격이 없어 생기는 일이니 중간 과정은 자유롭게 두되 인풋과 아웃풋의 모양만 고정하자는 결론이었습니다. 다른 조에서는 대기업이 폐쇄망을 쓰거나 AI 벤더와 직접 협약을 맺는다는 이야기가 나왔고, 학습에 쓰지 않겠다는 약속 정도가 돌아온 답이었다고 했습니다. 결국 폐쇄망을 쓰거나 서로를 믿고 약속을 잘하거나 두 가지밖에 없었다는 정리였습니다.

마지막 조의 정리가 길었습니다. 회사들이 바이브 코딩 콘테스트를 많이 하는데 문제는 그다음입니다. 각자 만들어 쓰다가 서빙하고 싶어지면 잘 만들어진 것만 추려지지 않은 채로 내부 개발팀에 넘어오고, 개발팀은 그 코드가 동작할 보장이 없으니 분석과 개선 작업을 떠안습니다. 개발 비용은 싸졌는데 운영 비용이 점점 커지는 상태가 됐다는 것입니다. 비개발자가 기능을 붙여 나가다 단일 HTML 파일이 11만 줄이 된 사례도 나왔고, 고객이 문제를 꺼내지 않는 예스맨 같은 LLM의 성격이 여기 영향을 미쳤다고 보셨습니다. 프롬프트를 회사가 볼 수 있느냐는 문제도 꺼냈습니다. 개인정보라는 이유로 못 보게 하는 회사가 있고, 비싼 비용을 내니 업무용만 써야 한다며 다 봐야 한다는 쪽도 있습니다. 앞으로 계약이나 사내 규정에 들어갈 것 같다고 했습니다.

두 세션과 열 개 조가 각자 다른 곳에서 출발했는데 도착지가 비슷했습니다. 만드는 것은 이제 아무나 하지만 남이 쓰게 만드는 것은 다른 일이고, 그게 어디서 막히는지는 보이지 않으면 알 수 없습니다. 한 요청을 처음부터 끝까지 연결해서 보자는 말과, 가시성부터 확보하자는 말과, 인풋과 아웃풋의 모양만 고정하자는 결론이 같은 자리를 가리키고 있었습니다. 완벽하게 막는 것은 되지 않습니다. 3중으로 막아도 100번에 한 번은 뚫리고, 그 한 번을 이제는 사람이 아니라 AI가 찾아냅니다.