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

오간 이야기

시작 전에 처음 오신 분들께 요즘 고민을 여쭤봤는데 그게 그날 주제를 그대로 예고했습니다. 구청에서 오신 주무관님은 바이브 코딩으로 구축은 순식간에 되는데 운영과 유지보수가 부서의 고민이라고 했습니다. 공직은 담당자가 길어야 2년이면 바뀌는데 그렇게 만든 걸 뒤에 오는 사람이 이어받기가 쉽지 않습니다. 세 분 다 같은 자리에서 막혀 있었습니다.

첫 세션은 LG CNS의 전창원 님이었습니다. 작년까지 AI 연구소에 계시다가 올해 플랫폼 조직으로 옮겨 에이전트 플랫폼을 만들고 계십니다. 데모가 왜 운영으로 넘어가지 못하느냐는 질문에 되물으셨습니다. 각자 만든 플러그인이나 스킬을 남들이 쓸 수 있느냐는 것이었습니다. 만들 때 자기 자신을 고객으로 두고 만들기 때문입니다.

영상에서 LLM으로 옮겨오니 지금이 훨씬 어렵다고 하셨습니다. 영상 처리는 답이 딱 떨어지는데, 지금은 temperature를 0으로 맞추고 같은 프롬프트를 넣어도 답이 조금씩 바뀝니다. 고객은 왜 바뀌느냐고 묻고 통계적으로 그렇다고 설명하면 그냥 똑같이 해달라고 합니다. 그래서 내부 용어를 다 아는 Expert 기준과 일상적인 말로 묻는 Newcomer 기준으로 테스트셋을 두 벌 만드는데, 그렇게까지 해도 잘 안 된다고 덧붙이셨습니다.

가장 와닿았던 예시는 주간보고였습니다. 3년치 텍스트를 남겨두셔서 지금은 1분 만에 본인이 쓴 것처럼 나옵니다. 그런데 본인은 불릿으로 짧게 쓰는 편이고 길게 쓰는 사람도 있습니다. 한 사람에게 최적화된 스킬을 여러 사람이 쓰기 시작하면 각자 고치고 고친 것들이 서로 부딪힙니다. 데모가 운영으로 넘어가지 못하는 이유가 기술이 아니라 여기 있다는 이야기였습니다.

어느 금융 지주와 한 PoC 이야기가 이어졌습니다. 불안해서 답을 길게 달았더니, 고객이 처음에는 좋아했습니다. 그런데 시간이 지나며 반응이 달라졌습니다. 글자를 크게 해서 화면을 작게 보는 분들에게는, 정확하게 쓴 답이 화면에 들어오지 않았던 것입니다. 처음부터 100%를 생각하지 말고 최소한의 기능으로 시작해 덧붙이며 만든 걸 엎을 생각으로 해야 한다고 했습니다.

검증 방식도 구체적이었습니다. 1,000개 가까운 데이터셋을 만들어두고 바뀔 때마다 계속 돌리고 클로드로 뽑은 건 GPT에게 평가시키는 식으로 교차로 확인합니다. 테스트셋은 나중에 하겠다고 하면 결국 안 만들게 된다고 순서를 강조하셨습니다. 최종적으로 잘 나왔는지는 고객 피드백으로 아는데, 잘했을 때는 아무도 누르지 않고 못했을 때는 과감하게 누른다는 관찰이 붙었습니다.

보안은 처음부터 시스템을 만드는 경우가 없다고 했습니다. 기업들은 이미 위키나 협업 도구를 쓰고 거기 보안이 걸려 있으니, 모델에서 막는 대신 사용자의 접근 권한에 따라 롤 기반으로 권한을 매기고 최종단에 가드레일을 얹습니다. 거버넌스 이야기가 특히 인상 깊었습니다. 감시하고 막는 일이 아니라 계열사마다 비슷한 에이전트를 중복해서 만들기보다 함께 쓰게 하는 쪽을 고민하셨다고 했습니다. 에이전트가 들어왔다고 권한의 경계를 넓혀서는 안 된다고 했습니다.

두 번째 세션은 Datadog의 손우두 님이었습니다. 본인도 코딩을 잘 하지 않는다며 고객들이 AI 에이전트를 개발할 때 어떤 고민을 하는지 직접 겪어보려고 사주 앱을 만들어 오셨습니다. 발표 중에 네 가지를 물으셨습니다. AI가 어떤 작업을 무엇으로 처리하는지 보이는가, 토큰은 어디에 왜 쓰이는가, 답변을 믿어도 되는가, 공격을 감지할 수 있는가. 다 답할 수 있는 분이 있냐고 묻자 아무도 손을 들지 않았습니다.

3중 방어 슬라이드가 이날의 중심이었습니다. 모델 학습으로 막고 입력 분류기로 막고 전문가 레드팀까지 붙여도 잔여 공격 성공률이 1%로 남습니다. 미국 NIST는 프롬프트 인젝션 방어의 확실한 방법이 아직 없다고 했고 OWASP는 그것이 모델의 확률적 본질에서 기인한다고 했습니다. 영국 NCSC의 문장이 결론이었습니다. 방어선을 행동 단계로 옮긴다는 것입니다. 프롬프트 레벨에서는 통과시키되 에이전트 단에서 권한과 정당성을 판단해 런타임에 차단합니다.

시연보다 흥미로웠던 건 객석이었습니다. 발표가 진행되는 동안 대시보드에 실제 요청이 쌓이고 있었는데, 시스템 프롬프트를 요구하는 입력들이 그대로 잡히고 있었습니다. 사전에 맞춘 것도 아닌데 이런 공격이 재미 삼아 해보는 수준으로 퍼져 있었던 겁니다. 파이어사이드에서 그분이 뚫린 1%가 무엇이었는지 물었습니다. 어떤 프롬프트가 뚫렸는지는 모르겠다고 하면서 결국 AI가 뚫는 것 같다고 답했습니다. 사람이 하나하나 생각하는 게 아니라 AI에게 요청하니 병렬로 연쇄해서 돌아갑니다.

작은 팀이라면 무엇부터 시작해야 하느냐는 질문에는 가시성이 가장 중요하다고 답했습니다. 에이전트들이 어떤 역할을 어떻게 처리하는지가 보여야 비용도 평가도 자연스럽게 이어진다는 것입니다. 앞 세션이 다시 떠올랐습니다. 전창원 님도 로그가 얼마나 많으냐보다 한 요청을 처음부터 끝까지 연결해서 볼 수 있느냐가 중요하다고 했기 때문입니다. Datadog 데모에서 정확히 그 화면이 나왔습니다. 응답까지 40초가 걸린 요청이 있었는데 그 40초가 어디서 걸린 건지가 나뉘어 보였습니다.

라운드테이블에서는 열 개 조의 이야기가 나왔습니다. 한 조는 개인이 AI를 잘 쓰는 것과 조직이 잘 쓰는 것 사이의 간극을 셋으로 정리했습니다. 누가 어떻게 쓰는지 보이지 않는다는 것, 팀원마다 아웃풋 모양이 달라 해석에 시간이 더 든다는 것, 비개발 조직에는 PR 리뷰 같은 중간 단계가 없어 만든 사람 한 명이 다 떠안는다는 것입니다. 셋 다 규격이 없어 생기는 일이니 중간 과정은 자유롭게 두되 인풋과 아웃풋의 모양만 고정하자는 결론이었습니다. 만드는 건 이제 아무나 하지만 남이 쓰게 만드는 건 다른 일이었습니다.