안녕하세요 FS-ISAC의 팟캐스트 FinCyber Today입니다. 저는 FS-ISAC의 최고기업대외협력책임자 엘리자베스 히스필드입니다. 생성형 AI가 멋지고 혁신적인 접근 방식에서 절대적인 경제적 필수 요소로 자리 잡으면서 기업과 팀은 AI에 대해 생각하는 수준을 넘어 AI처럼 생각하는 방법을 익혀야 하는데요. Akamai의 부사장 겸 CTO인 패트릭 설리번 님과 이 기술에 대한 이야기를 나눠보겠습니다. 주제는 AI 툴의 비결정적 특성을 보안팀에서 익히고 활용하는 방안입니다. 이 자리에 와주셔서 감사합니다. 진심으로 감사드립니다. 이 주제로 대화할 수 있다니 대단히 설레네요. 둘 다 AI에 푹 빠져 있으니까요. 비결정적 리스크 관리에 대해 이야기해 봅시다. 기본 규칙과 기초적인 개념부터 알아보죠. 생성형 AI 모델의 비결정성이란 무엇인가요? 기초 개념을 아는 게 중요한 것 같아요. 제 생각엔 말이죠 다들 그렇게 열광하는 생성형 AI를 살펴보면 이러한 모델이 하는 일의 핵심은 복잡한 행렬 곱셈을 대량으로 수행한 다음 가장 가능성이 높은 결과로 다음 단어를 완성하려고 시도하는 거예요. 그런데 설정 방식에 따라 모델은 가장 가능성이 높은 답변을 제시할 수도 있지만 가능성이 낮은 답변을 대안으로 선택할 수도 있어요. 그 의미는 무엇이며 왜 '비결정적'이라는 말을 쓸까요? 이번에 특정한 인풋으로 모델을 실행했을 때 그 모델이 완전히 정적이고 시스템에 아무런 변화가 없었더라도 다음에 실행했을 때는 다른 결과가 나온다는 점 때문이에요. 다시 실행하면 또 다른 결과가 나오죠. 여러모로 이러한 방식은 기존에 운영되어 온 수많은 시스템과 달라요. 그래서 이를 제대로 이해하려면 사고방식의 전환이 필요해요. 보안 테스트를 예로 들면 잠복해 있는 대량 주입 페이로드가 지금 당장 발동하지 않았다고 해서 취약점이 없다는 보장은 없잖아요. 바로 다음번에 테스트를 실행했을 때는 똑같은 애플리케이션에서 똑같은 페이로드가 대량 주입을 일으켜 부정적인 결과를 초래할 수 있기 때문이죠. 그래서 사람들이 이를 제대로 이해하는 것이 중요한 것 같아요. 지적인 차원에서 비결정성을 이해하는 것만으로는 부족해요. 실제로 경험해 봐야 해요. 직접 다루어 보고 면밀히 모니터링하면서 그 현상을 지켜봐야 해요. 페이로드가 잠복해 있는 상황에서 모든 것을 똑같이 실행했을 때 나타나는 결과를 말이죠. 그러면 비결정성의 의미와 그게 보안에 미치는 영향을 제대로 알 수 있을 겁니다.
비결정성을 어떻게 이해하고 활용해야 할까요? 특히 기업 차원에서요. 챗봇이 핵심이 아니라는 점을 아는 게 중요한 것 같아요. 핵심은 더욱 복잡한 워크플로, 에이전틱 워크플로 등이죠. 맞아요. 좋은 소식은 현재 회원사들의 어떤 보안팀에는 풍부한 교육 기회를 적극적으로 활용하고 있는 뛰어난 인재들이 분명히 있다는 거죠. 이들은 훨씬 앞서 나가고 있어요. 그래서 리더는 기본기에 집중해야 해요. 어떻게 하면 기본기를 다지고 보안 컴플라이언스 부서의 모든 구성원이 비결정성을 깨우치게 할 수 있을까요? 감사팀부터 공격자팀과 AppSec팀에 이르는 모든 구성원이 말이죠. 어떤 이들은 기본기에 대한 교육을 지루하다고 생각하겠지만 기본기를 쌓는 게 중요해요. 워크숍을 활용할 수도 있겠죠. AI 워크숍이나 AI 해커톤을 통해 비결정성을 손쉽게 직접 체험해 볼 수 있을 거예요. 현상을 실제로 겪어 보는 게 중요한 것 같아요. 그러면 감사팀에서는 이런 고민을 하게 될 거예요. "안전하다고 확신해도 될까?" "테스트 결과는 정상인데" "더 넓은 관점에서 보면 어떨 것 같아?" "다음번에 정적 시스템에서 실행할 때는 비정상으로 나올지도 몰라" -맞아요 -모두의 이해가 필요해요. 좋아요. 기초 개념에 대해 알아보았는데요. 이제는 기회에 대해 이야기해 보죠. 금융 부문에서 활용할 수 있는 기회에 대해서요. 특히, 생성형 AI의 이 새로운 특성이 어떤 기회를 가져다 줄까요? 기업마다 AI 기술을 도입하는 속도는 제각각이에요. 어떤 리더는 이렇게 말하더군요. "우리는 이미 입지가 탄탄한 기업이지만" "AI가 가져다주는 기회를" "별 볼일 없는 스타트업과 핀테크 기업에" "넘겨주지는 않겠다"라고요. 위험 감수 의지가 있다는 것은 좋은 일이에요. AI 채택 과정에서 기업이 AI 툴을 가장 먼저 도입하게 될 분야 중 하나는 개발 보조 툴일 텐데요. 그 성과가 조금씩 나오고 있어요. 개발자 생산성이 높아졌기 때문이죠. 지난주에 저희 파트너사인 Apiiro에서 최근 발표한 연구 보고서를 읽어봤는데요. 그에 따르면 생성형 AI 보조 툴을 사용할 경우 커밋되는 PR 수를 기준으로 소프트웨어 업데이트 횟수가 4배 증가해요. 실행 중인 다양한 AST 툴을 모두 고려한다면 그 증가율은 평균 10배가 될 거예요. 그중 상당수는 중복되는 툴이지만 전반적으로 업무 속도가 향상되므로 기업에 큰 도움이 되죠. 하지만 보안팀, 특히 AppSec팀이 자동화할 방법을 찾지 못하면 비즈니스 흐름에 뒤쳐질 거예요. 이런 기회가 있고 또 다른 기회는 지원 범위에요. 유용한 툴들이 수많은 알림을 쏟아내는데요. 보안 침해 보고서를 읽어보면 이런 내용이 나오곤 하죠. 심각한 인시던트가 발생했습니다. 툴에서 알림도 발송됐어요. 여기서도 알림을 받고 저기서도 알림을 받았어요. 그런데 인간 분석가가 개입할 정도의 알림이 아닌 경우가 많았어요. 지원 범위가 더 넓었다면 AI 시스템이 직접 조치를 취할 수 있었을 테고 더욱 면밀한 검토가 필요한 기준도 -낮출 수 있었을 거예요 -맞아요. 그런 것도 기회죠.
기회에 대한 이야기를 나눠 봤는데요. 이제 리스크에 대해 이야기해 보죠. 기업이 생성형 AI를 도입하면서 직면하게 되는 리스크는 무엇이며 그에 따라 이전과는 조금 다른 방식으로 리스크를 관리해야 한다고 생각하시나요? 도입에 따른 어떤 리스크가 있을까요? 첫 번째로 AppSec 분야를 살펴보죠. 개인적으로 약 20년 동안 AppSec 리스크에 대처해 왔는데요. AppSec에 문제가 발생했을 때 발견되는 대표적인 안티패턴은 데이터에 코드나 명령어를 섞어 놓은 경우죠. 데이터는 여기에 명령어는 저기에. SQL 명령어는 데이터베이스에 있어야 하는데 그렇지 않으면 많은 문제를 낳아요. 운영 체제 명령어가 해석되면 또 다른 종류의 위험이 발생해요. 저희가 목격한 바로는 생성형 AI를 활용해 명령어와 데이터를 한데 섞어 버리는 경우가 있어요. - 그렇군요 - 칵테일 만들듯이 그러면 문제가 되죠. 이런 모델을 생각해볼 수 있어요. 3가지 유해 요소죠. 다시 말하자면, 외부 데이터가 있습니다. 그 데이터는 유입되는 쿼리일 수도 있고 시스템에 입력된 학습 데이터일 수도 있죠. 그리고 내부 데이터가 있어요. RAG이나 기밀 데이터에 접속하는 다른 유형의 시스템에서 사용하죠. 현재는 그 기밀성을 유지할 방법과 그 데이터에 접속할 수 있는 사용자에 대한 수많은 규칙을 두고 있어요. 세 번째 요소는 통신 채널인데요. API를 통한 직접 연결은 최악의 문제를 낳죠. 이메일이나 소프트웨어 제어 모듈, 공개 저장소 Slack 등의 툴에 대한 접속 경로도 통신 채널이에요. 현재 이 3가지 유해 요소가 모두 한곳에 있다면 어느 정도 리스크가 존재한다는 거겠죠. 그렇다면 강력한 대응책이 필요할 거예요. 그 리스크에 대처하려면요. 셋을 둘로 낮출 수 있다면 셋에 모두 대처하는 것보다 승산이 훨씬 더 높을 거예요. 특히 기업이 최첨단 모델을 기반으로 구축된 툴을 활용하고 있다면 그 툴이 모든 걸 뒤섞는 주범이 될 수 있겠군요? 그럴 수 있어요. 최첨단 모델이 외부 데이터를 실어다 줄 거예요. 애초부터 -온갖 외부 데이터가 유입되는 거죠 -그렇군요. 공격자가 악용할 수 있겠죠? 그 안에 뭐가 있는지 알고 있다면 만들어낸 인풋으로 그 부분을 건드릴 수 있어요. 거기에 다른 유해 요소가 더해지면 기업은 힘든 상황에 처할 거예요. 확실히 지금 그런 리스크에 노출되어 있어요. 겉으론 정상으로 보이지만 실제로는 그렇지 않은 리스크에는 어떻게 대처하시나요? 어떻게 관리하세요? 왜냐하면 예전에는 "모 아니면 도"였잖아요. "흑 아니면 백"인 시대였으니까요. 지금 같은 시대에서는 모델이 내놓는 결과물은 모든 게 괜찮아 보이고 이치에 맞는 것 같아요. 모델을 둘 이상 사용해야 할까요? 어떻게 옳고 그름을 판단하고 어떻게 검증해야 할까요? 어려운 문제죠. 이러한 시스템은 맞을 때도 있고 틀릴 때도 있는데 늘 확신에 차 있으니까요. 다양한 기법이 있어요. 한 가지는 모델을 감독하는 모델이에요. 이전 요청의 변형을 살펴보는 거죠. 중요도에 따라 어떤 시스템에 대해 기업에서는 이렇게 말해요. "사람을 시스템에서 배제할 준비가 안 됐다. 사람을 통한 안전 장치를 마련할 것이다"라고요. 한편, 보안에서는 사람이 가장 취약한 고리라고들 하죠. 그래서 다시 그런 방식으로 돌아간다는 게 아이러니해요. 이러한 방법들은 보완적인 관리 대책일 뿐이에요. 반드시 명심해야 할 건 매우 확신에 찬 답변이 완전히 틀린 것일 수 있다는 거예요. 지금의 성숙도에서는 말이죠. 그러한 관점에서 '오류'를 어떻게 알 수 있는지에 대해 이야기 나누고 싶은데요. 물론 평가가 마련되어 있어요. 설계를 시도하는 단계에서는 AI가 AI를 검증하는 경우도 있고 인간이 참여하는 경우도 봤어요. 그러면 인간이 검증하는 데 드는 시간이 더 걸릴 수 있습니다. 애초에 그냥 인간이 처리하고 값비싼 새 시스템을 -도입하지 않았을 때 -그렇죠. 걸리는 시간보다 말이죠. 평가하고 검증하는 방법은 많아요. 자동도 있고 수동도 있고 다양하죠. 게다가 수많은 규제 요건도 준수해야 하는데요. 어떻게 하면 GRC의 일반적인 요구사항과 모든 제반 사항을 계속 준수할 수 있을까요? 이 모든 문제를 해결해 나가면서요? 문제가 눈에 띄지 않는 방식으로 발생하고 해결하는 데도 시간이 걸리잖아요. 맞습니다. 이 분야에서 이루어지는 혁신으로 인한 속도 차는 엄청납니다. 제가 경력 내내 봐온 그 어떤 기술보다도 반감기가 짧아요. 규제가 적용되는 속도보다도 빠르죠. 이러한 속도 차에 대처하고 있는 GRC 동료들에게 공감이 필요해요. 하지만 동시에 매우 강력한 규제의 상당 부분은 기본 원리에 기반을 두고 있어요. 그중 상당수가 이 분야에도 적용될 거예요. 기초적인 거예요. 예를 들면 해당 기술이 어디에 적용되었는지 제대로 파악하고 있나요? 결정성과 비결정성에 대해 이야기를 나누었는데요. 이 점을 꼭 염두에 두셨으면 해요. 해당 모델을 알고 있고 그 시스템에 대한 관리 권한이 있다면 이를 조작할 수 있고 해당 시스템을 설정하여 온도를 0도로 설정할 수도 있고 결정적 시스템으로 전환할 수도 있다는 점이에요. 보안팀과 컴플라이언스팀이 비즈니스에 어느 정도 긴장감을 주는 것이 오히려 도움이 되는 경우가 있어요. 어떤 시스템은 굳이 비결정적일 필요가 없잖아요. 법률, 회계처럼 소위 '딱딱한' 분야라면 기발한 독창성까지는 필요하지 않아요. 에이전트의 예측 가능성이 더 중요한 분야도 있을 테고요. 어떤 분야에서는 시스템에서 인간이 독창적이라고 인식하는 걸 만들어내려면 가능성이 낮은 결과에 대해서도 더 폭넓게 -샘플링해야 한다고 주장하죠 -맞아요. 어려운 질문을 던져봐야 해요. 시스템 내에서 그 정도의 비결정적 동작이 정말로 필요한지 그 필요성을 검증하고 그 근거를 제시해야 해요. 가능한 한 결정적으로 만들려고 노력해야 한다는 거네요. 제가 들은 또 다른 방법은 사람들이 작업을 세분화하는 건데요. "이건 에이전틱과 하위 에이전트 워크플로에 속해" "이 하위 에이전트는 이 작업만 해"라는 식이면 문제가 발생했을 때 추적할 수 있죠. 반면에 모든 사람이 수많은 단계를 거치는 하나의 워크플로만 있다면 어디서 문제가 발생했는지 파악하기가 너무 어려워요. 작업을 작은 구성 요소로 세분화할 수 있으면 시스템의 결정성을 높일 수 있어요. 시스템을 자동화하더라도 말이죠. 네, 또 다른 훌륭한 예시 같아요. 그런 경우라면 보안팀과 컴플라이언스팀의 철저한 검토를 받는 편이 결과가 더 좋을 거예요. 일종의 업무 분장이잖아요. -네, 맞아요 -요소를 적절히 배치하는 거죠. 운영을 뒷받침하는 탄탄한 기본 원칙을 초석으로 활용하는 것이 좋아요. 이러한 시스템을 구별하여 취급하지 않고 기존의 검토 기준을 적용하는 것이 도움이 되는 경우도 있어요. 그렇지만 한편으로 공격자들은 비결정적 특성을 활용해 기회를 포착해요. 무작정 시도해보고 생각지도 못한 기발한 결과가 나오기를 바라는 거죠. 그러면 바람직하지 않은 경우가 생기잖아요. 결정성을 너무 높여서 그 독창성을 제한한다면 공격자에게도 유리한 환경이 되잖아요. 그렇지 않나요? 네, 앞으로를 내다보고 AppSec 사례로 돌아가 볼게요. 기존에는 사람이 활용할 수 있는 방식으로 API와 -애플리케이션을 개발해 왔어요 -그렇죠. 사람에겐 검색 기능을 제공하죠. 앞으로는 에이전트나 챗봇에 데이터를 공급하기 위한 API와 웹 애플리케이션을 개발하게 될지도 몰라요. 사람들이 주어진 조건에 따라 자신에게 가장 적합한 금융 기관을 선택한다면 아마 그 결정은 에이전트나 챗봇을 통해 내릴 거예요. 그러면 학습 정보를 제공하는 봇에 대응하는 방식과 이러한 에이전트에 대응하는 방식에는 해당 사용 사례에 최적화하기 위한 다른 처리가 필요할 수 있죠. 현재 일반적인 웹 방문자를 대상으로 하는 것과는 다르게요. 이건 좋은 사례에요. 고객이 적법하게 기술을 사용하는 경우죠. 당연히 사칭범이나 악의적인 수단으로 툴을 활용하는 사람들도 있을 거예요. 또한 더 많은 자동화와 사이트로 유입되는 더 많은 봇에 대응해야 하고 위임된 신원을 확인하느라 씨름해야 할 거예요. 내가 내 신원의 정당한 소유자이지만 나 대신 에이전트가 일을 처리하게 하는 거죠. 이러한 현상은 이미 나타나고 있고 아직은 극초기 단계에요. 이는 IAM 측면에서 권한 부여와 관련된 여러 과제를 팀에 안겨주겠죠. 할 일이 많을 거예요. 네, 이건 패널 토론에서 앞서 나왔던 내용인데요. 써드파티 및 공급망 리스크 또는 n차 리스크라는 새로운 차원의 문제도 있습니다. 에이전트 간에 소통이 이루어지는 경우 공급업체의 에이전트가 다른 에이전트와 대화를 하는데 그 내용을 전혀 파악할 수 없다는 거죠. 블랙박스가 블랙박스를 겹겹이 싸고 있는 셈이에요. 이 문제에 대해서는 어떻게 생각해야 할까요? 이미 공급망 관리 리스크라는 과제에 직면해 있는 상황에서 이제는 가시성을 대폭 떨어뜨리는 또 다른 계층을 더하고 있어요. 이 문제에 대해 어떻게 생각해야 할까요? 클라이언트 측면에서 바로 앞에 놓인 첫 번째 과제는 누군가가 에이전트를 활용하고 있다면 이를 적절히 탐지하고 올바르게 처리하여 그게 승인받을 수 있는 위임된 신원인지 확인하는 거예요. 그게 첫 번째 단계죠. 그러면 백엔드에서는 써드파티 서비스를 활용하고 있을 텐데 이 서비스에서는 또 n차 서비스를 호출하고 있을 테죠. 이런 방법으로 공급망 리스크에 대처하고 있을 텐데요. 올해 초, 회원사인 Pat Opet이 SaaS 공급업체에 보낸 공개 서한에서 오늘날 생태계에 존재하는 문제점을 날카롭게 지적했던 것 같아요. 그 해결책의 일부는 SaaS 공급업체가 다운스트림에서 벌어지는 일을 더욱 투명하게 공개하는 거고 공격자들 때문에 불가피하게 그렇게 되고 있어요. 서한의 내용이 현실화되는 거죠. LLM이 많이 회자되었고 생성형 AI의 대명사처럼 되었지만 소규모 언어 모델의 잠재력에 대한 이야기도 많이 들리는데요. 특히 사용 사례가 아주 특수한 경우에는요. 닭 잡는 데 소 잡는 칼을 쓸 필요는 없잖아요. 소규모 언어 모델이 비결정적 리스크에 대처할 방안이 될 수 있을까요? 제 생각엔 그래요. 보안팀이 비즈니스에 긴장감을 불어넣는 또 다른 사례죠. 이런 어려운 질문을 던질 수 있어요. "LLM의 모든 기능과 그에 따른 모든 리스크를 감수해야 할 필요가 있을까?" LLM을 대상으로 한 위협 모델링은 너무 힘든 일이잖아요. 이런 것들을 고려해야 하기 때문이에요. "금융 애플리케이션에 대량살상무기를 만드는 법을 물어봐도 될까?" 이 내용은 학습 데이터에 따라 위협 모델의 일부가 될 수 있죠. -맞아요 -보안팀이 비즈니스에 대한 문제를 제기해요. 앞서 이야기했듯이요. "정말로 비결정적 모델이 필요한가요?" "이 시나리오에서는 결정적 모델로도 괜찮지 않을까요?" 사용할 모델은 설정을 통해 관리할 수 있죠. 마찬가지로, 이렇게 검토해 봐야 돼요. "정말 LLM이 필요한가요, 이 사용 사례에서는 SLM으로도 충분하지 않나요?" 보안팀이 모두에게 더 나은 결과를 가져다줄 비즈니스 방침을 제시하는 또 다른 사례가 될 수도 있어요. 실제로 점점 더 많은 기업이 이런 질문을 던지고 있다는 건 긍정적인 변화라고 생각해요.
모델과 온도에 대해서도 조금 이야기 나눴는데요. 컨텍스트를 조절하는 것도 중요하죠? 컨텍스트가 끝없이 방대해지도록 내버려둘 수는 없잖아요. 그러면 당연히 결과물의 품질이 떨어지고요. 아웃풋이 많아지고 인풋도 늘어나고 그러면 비용도 더 많이 발생하죠. 컨텍스트를 제한하는 방법으로 프롬프트를 더 예측 가능하게 만드는 방법이 있을 거예요. 방법은 있어요, 프롬프트 템플릿도 있고 프롬프트 라이브러리도 있으니까요. 프롬프트를 더욱 예측 가능하게 만든다면 적어도 입력되는 인풋은 더 엄격히 관리되겠죠. 다양한 측면에서 발생하는 비결정성도 어느 정도는 관리할 수 있을 거예요. 제 생각에 중요한 건 직원 교육을 통해 다양한 측면이 있다는 사실을 알리는 거예요. 그래야 직원들이 어떤 수단이 있는지 알게 되고 한 가지 방안만 있는 게 아님을 이해할 테죠, 어떻게 생각하세요? 전적으로 동의해요. 역사를 되돌아보면 새로운 트렌드를 받아들일 때마다 안타깝게도 보안 측면에서 문제점이 드러나곤 했어요. 전자상거래의 시대가 시작됐을 때 SQL 인젝션 공격이 기승을 부려 웹 애플리케이션에서 데이터베이스 전체가 유출되곤 했죠. 그 경험을 통해 애플리케이션 인풋을 검증하는 법을 배워 이후에는 더 나은 대응을 할 수 있었고 클라우드 컴퓨팅으로 넘어갔을 때도 비슷한 패턴이 나타났죠. 이번 트렌드를 받아들이면서 이런 기대를 해봐요. 민감한 백엔드 데이터와 연동된 웹 애플리케이션의 도입이나 클라우드의 도입에서 얻은 교훈을 활용할 수 있지 않을까요? 과거의 경험에서 얻을 만한 게 있지 않을까요? 어떤 기업이 실제로 큰 고통을 겪는 모습을 지켜보면서 그 고통에서 교훈을 얻을 일 없이요. 부디 그럴 수 있기를 바라고 심각한 침해로 이어지기 전에 그 리스크를 줄일 수 있기를 바랍니다.
좋아요, 지금까지 많은 내용을 다뤘어요. 이번 대화를 통해 사람들이 꼭 기억하길 바라는 점을 하나만 꼽자면 어떤 게 있을까요? 흥미로운 점이 많은데요. 핵심은 정보 보안팀이 기본 사항을 확실하게 이해하는 거예요. 다시 말씀드리지만 AI에 대한 기초 교육을 마련해야 해요. 워크숍이나 해커톤과 같은 기회를 통해 직접 경험해 볼 수 있으면 더 좋고요. 다들 이미 기본 원칙은 가지고 있어서 AI를 이해하고 경험해 보면 그 원칙을 어디에 적용해야 할지 알게 될 거예요. 이상입니다.
