[3/26] No Edits, No Fiction: Security First, Security Last 세션 후기

한현상 님의 「No Edits, No Fiction - Security First, Security Last」

 

이 세션은 단순히 “생성형 AI 보안을 이렇게 해야 한다”는 원론적인 이야기보다,
실제 엔터프라이즈 고객사의 생성형 AI 프로젝트를 어떻게 설계했고, 그 과정에서 어떤 보안적 현실을 마주했는지를 구체적으로 보여준 발표였다.

특히 좋았던 점은, 발표 제목 그대로 포장 없이 실제 프로젝트의 고민과 제약, 운영 이슈까지 드러냈다
이론보다 실무가 궁금한 사람에게 훨씬 도움이 되는 내용이었다.

---

세션 개요

발표에서는 한 엔터프라이즈 고객사의 생성형 AI 프로젝트 사례를 중심으로 설명이 진행됐다.
프로젝트는 약 7개월간 진행된 실제 구축 사례였고, 고객사는 오랜 업력을 가진 대기업으로, 다량의 내부 문서와 데이터를 활용해 생성형 AI 기반 업무 활용 체계를 만들고자 했다.

발표 내용을 정리하면 고객의 목표는 대략 이런 방향이었다.

• 사내에 축적된 발주서, 계약서, 설계 관련 데이터 등을 더 효율적으로 활용하고 싶다
• 사람이 직접 찾아내던 계약 조건, 비용 차이, 설계상 쟁점을 더 빠르게 발견하고 싶다
• 전사 구성원이 활용할 수 있는 포털 형태의 AI 서비스가 필요하다
• 단순 챗봇이 아니라, 지속적으로 데이터가 반영되고 피드백이 누적되는 구조가 필요하다

즉, “LLM 하나 붙여보자” 수준이 아니라
기업 내부 데이터를 중심으로 한 RAG/포털형 생성형 AI 서비스를 만들고 싶었던 것이다.
이 프로젝트의 배경과 목표, 그리고 전사 데이터를 포털처럼 활용하고자 했다는 설명은 녹음 전사에서도 반복적으로 등장했다.

---

왜 이 세션이 흥미로웠나

생성형 AI 관련 발표는 많지만, 실제 현업에서는 늘 비슷한 질문이 따라온다.

• 우리 데이터가 외부로 나가면 안 되는데 가능한가?
• 금융권/망분리 환경에서도 쓸 수 있는가?
• 인증/인가를 어떻게 붙일 것인가?
• Guardrails는 정말 실무에서 쓸 만한가?
• 프롬프트 인젝션이나 개인정보 유출은 어떻게 막는가?
• 모델을 붙이는 것보다 운영과 보안이 더 어려운 것 아닌가?

이번 발표는 바로 이 질문들에 대해
이론이 아니라 실제 프로젝트에서 어떤 결정을 했는지를 보여줬다.

---

프로젝트의 핵심 방향: “AI 서비스”보다 먼저 “기반”을 만들다

가장 인상 깊었던 부분 중 하나는
발표자가 고객사에 처음부터 바로 AI 애플리케이션만 제안한 것이 아니라,
그 전에 Control Tower 기반의 클라우드 현대화/거버넌스 기반을 먼저 제안했다는 점이다.

즉, 순서가 이랬다.

1. 고객사의 데이터와 애플리케이션이 올라갈 수 있는 클라우드 기반 정비
2. 그 위에서 실제 Playground 형태의 생성형 AI 애플리케이션 설계
3. 인증, 권한, 보안 정책, 로그 수집, 운영 체계를 함께 구축

이걸 보면서 다시 느낀 건,
생성형 AI 프로젝트도 결국은 AI 모델보다 인프라와 거버넌스가 먼저라는 점이다.

모델은 붙일 수 있다.
하지만 엔터프라이즈에서는 그 전에 다음이 정리되어야 한다.

• 누가 쓰는가
• 어떤 데이터를 볼 수 있는가
• 어떤 경로로 접근하는가
• 로그는 어디에 남는가
• 사고가 났을 때 누가 대응하는가

---

아키텍처에서 눈에 들어온 포인트

발표에서 소개된 구조를 아주 단순화해서 정리하면 다음과 같다.

• 사용자 접근 구간
• 포털/프론트엔드
• API Gateway 중심의 진입점
• Cognito 기반 인증
• Lambda를 활용한 권한/사용자 정보 처리
• Bedrock + SageMaker 조합
• 테넌트 분리 기반의 접근 정책
• 다중 FM 또는 외부 모델 연동 가능성
• 온프레미스/외부 환경과의 연계
• Guardrails 및 로깅/모니터링 체계

특히 발표에서는
애플리케이션이 동작하는 구간과 데이터를 소싱하는 구간을 구분해서 설명했고,
권한이나 부서별 특성에 따라 테넌트 단위 분리를 고려했다는 점이 강조됐다.

이 부분은 생성형 AI 서비스가 “하나의 공용 챗봇”이 아니라,
조직 구조와 권한 체계를 반영한 기업용 서비스여야 한다는 현실을 잘 보여준다.

---

금융권/프라이빗 환경에서의 가장 큰 고민: 퍼블릭 AWS 서비스와의 충돌

세션에서 가장 실무적으로 흥미로웠던 내용은
금융권 수준의 프라이빗 구성 요구와 AWS 서비스 특성 사이의 충돌이었다.

발표에서는 고객이 금융권이기 때문에 다음 같은 조건이 중요했다고 설명했다.

• 데이터 주권
• 망분리 성격의 요구
• 외부 공개 최소화
• 내부 사용자 중심의 접근 구조

문제는 AWS의 여러 서비스가 기본적으로 퍼블릭 성격을 갖고 있다는 점이다.
대표적으로 발표에서는 Cognito가 당시에는 프라이빗 링크 구성이 어려운 서비스였기 때문에, 프라이빗 아키텍처 안에서 인증을 설계하는 데 큰 고민이 있었다고 말했다.

 

이 부분이 인상 깊었던 이유는,
실무에서는 “서비스 하나를 쓰면 끝”이 아니라
그 서비스가 우리 규제 환경에 맞는가를 먼저 따져야 하기 때문이다.

 

발표에서는 이 문제를 우회하기 위해 Lambda와 Secrets Manager 등을 활용해
권한 확인과 사용자 식별 정보를 내부적으로 처리하는 방향을 설명했다.

 

즉, 인증 자체보다 더 중요한 건
인증 흐름이 프라이빗 아키텍처를 깨지 않도록 만드는 것이었다.

---

Guardrails는 만능이 아니었다

이 세션의 핵심 키워드 중 하나는 단연 Guardrails였다.

발표에서는 Guardrails를 다음처럼 나눠 설명했다.

• 입력 가드레일
• 출력 가드레일
• 콘텐츠 필터
• 허용되지 않은 주제 필터
• 프롬프트 공격 방어
• 개인정보 필터
• 환각 대응을 위한 그라운딩

그리고 여기서 매우 중요한 현실적인 이야기가 나왔다.
기본 Guardrails만으로는 한국 기업 환경에 충분하지 않다는 점이다.
발표자는 AWS 기본 Guardrails가 주로 미국/유럽 기준이라, 한국형 개인정보나 산업별 정책에 맞춘 세밀한 커스터마이징이 필요하다고 설명했다.

예를 들어 한국 기업 환경에서는 다음이 중요하다.

• 주민등록번호 패턴
• 한국식 운전면허번호나 식별체계
• 산업별 금칙 주제
• 사내 보안 정책에 따른 비공개 정보
• 부서/직급/업무별 접근 제한

그런데 이런 것들은 기본 제공 필터만으로는 충분히 막기 어렵다.
결국 실무에서는 다음이 필요해진다.

• 조직별 커스텀 룰
• 한국어 기반 금칙어/패턴 정비
• 지속적인 업데이트
• 샘플 기반 검증
• 사용자 피드백 반영

발표에서도 Guardrails는 한 번 넣고 끝나는 정적 정책이 아니라,
계속 운영하고 손봐야 하는 영역이라고 설명했다.

---

“보안”은 차단만이 아니라 운영이다

이번 세션에서 특히 좋았던 점은
보안을 단순히 “막는 기능”으로 보지 않았다는 점이다.

발표에서는 다음 같은 내용이 함께 언급됐다.

• API Gateway 앞단에 WAF 적용
• 주기적인 로그 인스펙션
• Control Tower 기반 중앙 로그 수집
• CloudTrail, SCP 등 정책/행위 데이터 통합
• SIEM 연계
• 사용자 시도 로그 확인
• 운영 중 발생 가능한 우회/탐색 행위 추적

질의응답에서도 프롬프트 인젝션이나 위협 탐지를 위한 모니터링 계층, SIEM 연동 여부가 질문으로 나왔고, 발표자는 WAF와 로그 점검, Control Tower 기반 수집 체계를 설명했다.

이 부분이 좋았던 이유는
생성형 AI 보안에서 많은 사람이 “금칙어 몇 개 넣으면 되지 않나”라고 생각하지만,
실제로는 관측 가능성(Observability)과 운영 체계가 없으면 통제가 불가능하기 때문이다.

결국 생성형 AI 보안도 기존 보안과 마찬가지로
다음이 필요하다.

• 예방
• 탐지
• 기록
• 분석
• 개선

---

비용 이야기도 현실적이었다

질의응답에서 비용 관련 답변도 꽤 인상적이었다.

발표자는 처음 제안했던 아키텍처를 기준으로 비용을 100이라고 하면,
실제 구축/운영 단계에서는 대략 40 수준까지 낮아진 케이스라고 설명했다.
이는 초기 추정보다 리소스를 덜 쓰게 되었고, 실제 사용자 패턴이 안정화되면서 구조가 더 현실적으로 조정되었기 때문이라고 했다.

 

여기서 느낀 점은 두 가지다.

첫째, 생성형 AI 프로젝트는 초기에 비용을 크게 잡기 쉽다.
둘째, 실제로는 사용자 수보다 질의 패턴, 토큰 사용량, 서비스 방식, 권한 구조가 더 큰 변수다.

즉 “사용자 20만 명”보다 중요한 건
그 20만 명이 실제로 어떤 질의를 얼마나 자주, 어떤 모델로 호출하느냐이다.

---

요구사항보다 더 어려운 것: 고객도 원하는 형상을 모른다

이 발표에서 가장 현실적이었던 대목은 이것이었다.

고객도 생성형 AI 서비스를 어떻게 써야 할지 명확히 모르는 상태에서 프로젝트가 시작된다.

발표자는 프로젝트 중반 이후, 고객이 처음 생각했던 형상과 실제 구현되는 서비스 사이의 간극 때문에 딜레이가 발생했다고 설명했다.
하지만 이를 단순히 고객 탓으로 보지 않았고, 시장에 레퍼런스가 적고 모두가 처음 해보는 영역이기 때문에 자연스러운 현상이라고 말했다.

이 대목이 특히 좋았다.

실제로 생성형 AI 프로젝트는 요구사항 문서보다 훨씬 불확실성이 크다.

왜냐하면 고객이 원하는 것은 보통 이런 수준이기 때문이다.

• 우리 문서를 잘 찾게 해달라
• 똑똑하게 답해줬으면 좋겠다
• 보안은 확실했으면 좋겠다
• 비용은 적당했으면 좋겠다
• 내부망에서도 되어야 한다

문제는 이걸 시스템으로 풀면 수십 개의 의사결정 포인트가 나온다는 점이다.

그래서 이 세션은
생성형 AI 프로젝트가 기술 프로젝트이면서 동시에 정의되지 않은 요구를 구체화하는 프로젝트라는 점을 잘 보여줬다.

---

내가 이 세션에서 얻은 핵심 인사이트

이번 세션을 들으면서 정리한 핵심 포인트는 다음 5가지다.

1. 생성형 AI 보안은 모델 보안만의 문제가 아니다

인증, 인가, 네트워크, 로그, 컴플라이언스, 데이터 소유권, 운영 체계까지 같이 봐야 한다.
발표에서도 보안의 출발점을 컴플라이언스와 데이터 소유권, 인증/인가 체계로 설명했다.

2. 엔터프라이즈에서는 “프라이빗하게 만들 수 있는가”가 핵심이다

특히 금융권처럼 규제가 강한 환경에서는 AI 품질보다 먼저
“이 서비스가 폐쇄적이고 통제 가능한 구조인가”가 중요하다.

3. Guardrails는 기본 기능보다 운영 전략이 더 중요하다

기본 제공 기능만으로는 부족하고,
한국어·국내 규제·산업별 정책에 맞춘 커스터마이징이 필요하다.
그리고 이건 한 번 설계한다고 끝나지 않는다.

4. 사용자 권한과 테넌트 분리는 반드시 설계 초기에 들어가야 한다

나중에 붙이기 어려운 문제다.
발표에서도 Cognito와 테넌트 분리, 사용자 권한 기반 접근 통제가 핵심 축으로 설명됐다.

5. 생성형 AI의 보안 운영은 결국 “로그”와 “관찰”이다

차단 정책만큼 중요한 것이 시도 로그, 호출 로그, 정책 위반 로그다.
WAF, CloudTrail, SIEM 연계처럼 기존 보안 운영 체계와 연결되어야 실무에서 굴러간다.

---

개인적인 후기

이번 세션은 “AI 보안”이라는 단어를 훨씬 현실적으로 보게 만든 발표였다.

보통 생성형 AI 보안이라고 하면
프롬프트 인젝션, 데이터 유출, 환각 같은 키워드만 먼저 떠올리기 쉽다.
그런데 실제 현업에서는 그보다 먼저 이런 문제를 마주한다.

• 이걸 누가 쓸 수 있는가
• 내부망에서 어떻게 접근시키는가
• 퍼블릭 서비스와 프라이빗 요구사항의 충돌을 어떻게 해결하는가
• 로그는 어디까지 남길 것인가
• Guardrails를 누가 운영할 것인가
• 고객의 애매한 요구사항을 어떻게 구조화할 것인가

즉, 생성형 AI 보안은
“새로운 공격기법 몇 개를 막는 문제”가 아니라
기존 엔터프라이즈 보안 아키텍처 위에 AI를 어떻게 얹을 것인가의 문제에 더 가깝다는 생각이 들었다.

개인적으로는 특히 다음 두 문장이 오래 남았다.

• 엔터프라이즈는 대부분 프라이빗하게 간다
• Guardrails는 넣고 끝나는 기능이 아니라 계속 운영해야 하는 체계다

결국 이 세션은
생성형 AI 시대에도 보안의 본질은 크게 바뀌지 않는다는 걸 보여줬다.

다만 달라진 것은 대상이 서버와 애플리케이션에서
모델, 프롬프트, 응답, 데이터 흐름까지 확장되었다는 점이다.

---

마무리

이번 AWS 한국 사용자 모임 세션은
생성형 AI 보안에 관심 있는 사람뿐 아니라,
클라우드 아키텍처, 엔터프라이즈 시스템, IAM, 로그 기반 운영에 관심 있는 사람에게도 정말 배울 점이 많았다.

특히 좋았던 건
“화려한 AI 데모”보다
실제 고객 요구, 규제 환경, 아키텍처 제약, 운영 현실을 중심으로 설명했다는 점이다.

생성형 AI 프로젝트를 고민하는 조직이라면
이 세션의 메시지는 꽤 명확하다.

AI를 붙이기 전에,
누가 어떤 데이터를 어떤 경로로 쓰게 할 것인지부터 설계해야 한다.
그리고 그 설계의 중심에는 여전히 보안이 있다.