"이 회의록을 챗GPT에 올려서 정리하면 금방 끝날 텐데…."
"복잡한 SQL을 AI에게 보여주면 성능 개선 방법을 알려주지 않을까?"
"시스템 장애 로그를 입력하면 원인을 더 빨리 찾을 수 있을 것 같은데…."
생성형 AI를 업무에 활용하는 직장인이 늘어나면서 한 번쯤 해봤을 법한 생각입니다.
실제로 생성형 AI는 긴 문서를 요약하고, SQL을 설명하고, 보고서 초안을 작성하는 데 도움을 줄 수 있습니다.
하지만 금융회사에서 근무하는 직장인이라면 여기서 반드시 확인해야 할 문제가 있습니다.
바로 AI에 입력하는 자료가 외부로 전달되어도 되는 정보인지 여부입니다.
신용카드회사나 은행, 보험회사 등 금융회사의 업무자료에는 고객 개인정보뿐 아니라 금융거래 정보, 내부 시스템 구성, 보안 정책, 업무 처리 절차 등 중요한 정보가 포함될 수 있습니다.
단순히 이름과 주민등록번호만 지우면 안전할까요?
회사에서 승인한 AI 서비스라면 어떤 자료든 입력해도 괜찮을까요?
AI가 학습하지 않는다고 안내하는 서비스라면 정보 유출 위험이 없을까요?
이번 글에서는 금융 IT 업무 경험을 바탕으로 생성형 AI 활용 시 발생할 수 있는 정보보안 위험과 안전하게 활용하기 위한 실천 방법을 알아보겠습니다.
※ 이 글은 일반적인 정보보안 원칙을 설명하기 위한 글입니다. 실제 업무에서는 소속 회사의 AI 이용 지침, 정보보호 정책, 개인정보 처리 기준 및 관련 법령을 우선 적용해야 합니다.
전체 목차
- 생성형 AI가 금융회사 업무에 빠르게 확산되는 이유
- 회사 자료를 AI에 입력하면 어떤 일이 발생할까?
- AI에 입력하면 위험할 수 있는 금융회사 정보 5가지
- 이름과 카드번호를 지우면 안전할까? 마스킹과 익명처리의 차이
- 금융 IT 업무에서 발생할 수 있는 AI 보안 사고 사례
- 금융 IT 직장인이 지켜야 할 AI 보안 수칙 7가지
- 개인용 AI와 기업용 AI는 무엇이 다를까?
- AI에 회사 자료를 잘못 입력했다면 어떻게 해야 할까?
- 안전하게 AI를 활용하는 실무 질문 예시
- AI 사용 전 1분 보안 체크리스트
- 자주 묻는 질문
- 마무리
1. 생성형 AI가 금융회사 업무에 빠르게 확산되는 이유
생성형 AI는 사용자가 입력한 질문이나 자료를 바탕으로 문장, 코드, 요약문 등 다양한 결과물을 생성하는 기술입니다.
금융 IT 업무에서는 특히 다음과 같은 분야에 활용 가능성이 있습니다.
| 업무 분야 | AI 활용 사례 |
| 회의록 정리 | 회의 메모 요약, 요청사항 분류 |
| 보고서 작성 | 장애 보고서, 개선 검토서 초안 |
| SQL 분석 | 쿼리 구조 설명, 성능 점검 항목 도출 |
| 시스템 운영 | 장애 원인 후보 정리, 점검 순서 작성 |
| 개발 업무 | 예제 코드 작성, 오류 원인 검토 |
| 현업 지원 | 기술적인 내용을 쉬운 문장으로 설명 |
이러한 업무는 반복적으로 수행되는 경우가 많습니다.
따라서 AI를 활용하면 문서 초안을 작성하거나 검토 항목을 정리하는 시간을 줄일 수 있습니다.
문제는 AI가 업무에 유용하다는 이유만으로 회사 자료를 자유롭게 입력해서는 안 된다는 점입니다.
금융회사의 데이터는 일반적인 공개 정보와 성격이 다르기 때문입니다.
특히 고객의 금융거래 정보나 내부 시스템 정보는 잘못 취급할 경우 개인정보 침해, 보안 사고, 법적 문제 등으로 이어질 수 있습니다.
AI 활용에서 중요한 것은 무엇을 할 수 있는가 보다 어떤 정보를 사용해도 되는가를 먼저 판단하는 것입니다.
2. 회사 자료를 AI에 입력하면 어떤 일이 발생할까?
AI 보안을 이해하려면 먼저 사용자가 입력한 자료가 어떻게 처리될 수 있는지 알아야 합니다.
① 입력한 내용이 서비스 사업자의 시스템으로 전달될 수 있습니다
일반적인 클라우드 기반 AI 서비스는 사용자가 입력한 질문이나 파일을 서비스 제공자의 서버에서 처리합니다.
예를 들어 회사 PC에서 외부 AI 서비스에 회의록을 업로드했다면 해당 자료가 외부 서비스의 처리 환경으로 전달될 수 있습니다.
이때 데이터가 저장되는 위치, 보관 기간, 접근 권한 등은 서비스의 계약과 설정에 따라 달라집니다.
② 대화 내용이 저장될 수 있습니다
일부 AI 서비스는 사용자의 대화 내역을 제공하거나 일정 기간 데이터를 보관할 수 있습니다.
보관 여부와 기간, 삭제 기능은 서비스 및 이용 환경에 따라 다릅니다.
따라서 AI 화면에서 대화가 보이지 않게 되었다고 해서 관련 데이터가 모든 처리 환경에서 즉시 사라졌다고 단정해서는 안 됩니다.
③ 서비스에 따라 모델 개선에 사용될 수 있습니다
AI 서비스마다 입력 데이터의 학습 및 모델 개선 활용 정책이 다릅니다.
일부 서비스는 사용자의 설정이나 계약 조건에 따라 입력 데이터를 모델 개선에 활용할 수 있으며, 다른 서비스는 기본적으로 그러한 용도로 사용하지 않을 수 있습니다.
따라서 'AI에 입력한 정보는 무조건 학습된다'거나 '절대 학습되지 않는다'라고 일반화하는 것은 정확하지 않습니다.
반드시 해당 서비스의 최신 데이터 이용 정책과 회사 계약 조건을 확인해야 합니다.
④ 다른 기능이나 외부 시스템으로 전달될 가능성도 확인해야 합니다
AI 서비스에 연결된 외부 앱, 플러그인, 검색 기능, 자동화 기능 등이 있다면 사용자가 제공한 정보가 추가적인 시스템에서 처리될 수 있습니다.
실제 데이터 흐름은 사용 중인 서비스와 기능, 접근 권한 설정에 따라 다릅니다.
따라서 회사 자료를 처리하기 전에는 AI 자체뿐 아니라 연결된 기능의 권한과 데이터 처리 방식도 확인해야 합니다.
AI 데이터 처리 시 확인할 사항
| 확인 항목 | 주요 질문 |
| 데이터 전송 | 입력 자료가 어디에서 처리되는가? |
| 데이터 보관 | 대화와 파일이 저장되는가? |
| 모델 학습 | 입력 자료가 모델 개선에 활용되는가? |
| 접근 권한 | 누가 입력 자료에 접근할 수 있는가? |
| 외부 연동 | 연결된 다른 서비스로 정보가 전달되는가? |
| 삭제 정책 | 자료 삭제와 보관 기간은 어떻게 관리되는가? |
여기서 중요한 사실이 있습니다.
AI 서비스가 데이터를 학습에 사용하지 않는다고 해도 회사 자료의 외부 전송이 자동으로 허용되는 것은 아닙니다.
정보의 외부 반출 가능 여부는 별도로 판단해야 합니다.
3. AI에 입력하면 위험할 수 있는 금융회사 정보 5가지
금융 IT 업무에서는 다양한 종류의 정보를 다룹니다.
그중 특히 주의해야 할 정보는 다음과 같습니다.
① 고객 개인정보
대표적으로 다음과 같은 정보가 있습니다.
- 고객 이름
- 주민등록번호
- 전화번호
- 주소
- 계좌번호
- 카드번호
- 고객 식별번호
- 개인별 거래 내역
이러한 정보는 개인정보 보호 관련 법령과 회사 내부 규정에 따라 관리해야 합니다.
특히 카드번호나 계좌번호가 포함된 자료는 일반적인 문서보다 더욱 신중하게 취급할 필요가 있습니다.
② 고객 금융거래 정보
고객의 거래 일시, 이용 금액, 가맹점 정보, 결제 패턴 등도 주의해야 합니다.
이름이 없더라도 거래 내역의 조합으로 특정 고객을 알아볼 가능성이 있기 때문입니다.
예를 들어 특정 날짜의 고액 결제 내역과 이용 지역, 고객 속성이 함께 포함된다면 개인을 추정할 수 있는 단서가 될 수 있습니다.
③ 내부 시스템 구성 정보
금융 IT 담당자가 자주 접하는 정보 중에는 다음과 같은 내용이 있습니다.
- 내부 시스템 구성도
- 서버 및 네트워크 주소
- 데이터베이스 구조
- 내부 API 명세
- 시스템 간 연계 방식
- 인증 및 접근통제 설정
이러한 정보는 외부에 공개될 경우 보안 위험을 높일 수 있습니다.
따라서 실제 시스템 구성을 외부 AI에 무단으로 입력해서는 안 됩니다.
④ 계정 및 인증정보
특히 위험한 정보입니다.
- 비밀번호
- API 키
- 접근 토큰
- 인증서 관련 비밀정보
- 데이터베이스 접속정보
- 관리자 계정정보
이러한 정보는 일부가 노출되더라도 심각한 문제가 발생할 수 있습니다.
AI에 질문할 때는 실제 인증정보 대신 의미 없는 가상 문자열을 사용해야 합니다.
⑤ 회사 내부 기밀 및 미공개 업무정보
고객정보가 포함되지 않았더라도 외부 공개가 허용되지 않은 정보가 있습니다.
예를 들어 신규 서비스 출시 계획, 내부 감사 결과, 미공개 사업 전략, 보안 취약점 분석 결과 등이 해당할 수 있습니다.
개인정보가 없다는 이유만으로 회사 자료를 외부 AI에 입력해도 되는 것은 아닙니다.
4. 이름과 카드번호를 지우면 안전할까? 마스킹과 익명처리의 차이
금융 IT 담당자가 AI를 사용할 때 흔히 생각하는 방법이 있습니다.
"고객 이름만 지우고 입력하면 되지 않을까?"
"카드번호 가운데 자리를 별표로 바꾸면 안전하지 않을까?"
하지만 단순한 마스킹만으로 모든 정보보안 위험이 해결되는 것은 아닙니다.
마스킹이란?
마스킹은 정보의 일부를 가리거나 다른 문자로 대체하는 방법입니다.
예를 들어 다음과 같습니다.
원본 자료 예시
고객명: 김OO
카드번호: [실제 카드번호]
거래일시: 2026-10-20 14:30
거래금액: 3,500,000원마스킹 자료 예시
고객명: ***
카드번호: ****-****-****-****
거래일시: 2026-10-20 14:30
거래금액: 3,500,000원이처럼 직접적인 식별정보를 가리는 것은 정보 노출 위험을 줄이는 데 도움이 될 수 있습니다.
하지만 거래 시각과 금액 등 다른 정보가 남아 있다면 특정 거래나 개인을 알아볼 가능성이 존재할 수 있습니다.
가명정보란?
가명정보는 추가정보를 사용하지 않고는 특정 개인을 알아볼 수 없도록 처리한 개인정보를 의미합니다.
가명처리를 했더라도 관련 법령에 따라 개인정보로서 보호와 관리가 필요합니다.
따라서 가명정보라고 해서 외부 AI에 자유롭게 입력할 수 있는 것은 아닙니다.
익명정보란?
익명정보는 시간, 비용, 기술 등을 합리적으로 고려할 때 다른 정보를 사용하더라도 더 이상 특정 개인을 알아볼 수 없는 정보를 말합니다.
하지만 실제로 익명처리가 충분한지 판단하는 일은 단순하지 않습니다.
특히 여러 데이터가 결합될 수 있는 금융 분야에서는 재식별 가능성을 신중하게 검토해야 합니다.
마스킹·가명처리·익명처리 비교
| 구분 | 의미 | AI 활용 시 주의사항 |
| 마스킹 | 정보 일부를 가리거나 대체 | 다른 정보로 식별될 가능성 확인 |
| 가명처리 | 추가정보 없이는 개인을 알아보기 어렵게 처리 | 여전히 개인정보 보호 의무 적용 |
| 익명처리 | 합리적으로 고려할 때 특정 개인을 알아볼 수 없도록 처리 | 익명처리 적정성과 회사 정책 확인 |
| 가상 데이터 | 실제 개인·거래와 무관하게 만든 자료 | 학습 및 예시 작성에 상대적으로 적합 |
AI 활용을 연습하는 단계에서는 실제 고객정보를 가공해 사용하는 것보다 처음부터 가상의 데이터를 만들어 사용하는 방법이 더 적절할 수 있습니다.
단, 가상 데이터도 실제 회사의 기밀 구조나 업무 규칙을 그대로 드러내지 않도록 주의해야 합니다.
5. 금융 IT 업무에서 발생할 수 있는 AI 보안 사고 사례
다음은 이해를 돕기 위한 가상의 사례입니다.
실제 특정 금융회사에서 발생한 사건을 의미하지 않습니다.
사례 1. 현업 회의록을 외부 AI에 업로드한 경우
DW 운영담당자가 현업과 개선 회의를 진행했습니다.
회의 내용을 빠르게 정리하기 위해 녹취록 전체를 개인용 AI 서비스에 업로드했습니다.
그런데 녹취록에는 내부 시스템명, 프로젝트 일정, 담당자 정보 등이 포함되어 있었습니다.
이 경우 문제가 될 수 있는 부분은 무엇일까요?
첫째, 해당 자료의 외부 서비스 입력이 허용되는지 확인하지 않았습니다.
둘째, 녹취 및 전사 자료에 개인정보와 내부 업무정보가 포함되어 있을 수 있습니다.
셋째, 서비스의 데이터 처리 조건을 확인하지 않았습니다.
따라서 회의록 작성의 편리함보다 자료의 보안 등급과 회사 정책을 먼저 확인해야 합니다.
사례 2. 실제 SQL을 입력해 성능 개선을 요청한 경우
개발자가 운영 SQL의 성능을 개선하고 싶어 외부 AI에 쿼리 전체를 입력했습니다.
그런데 SQL에는 실제 고객 테이블명, 내부 업무 규칙, 시스템 구조를 추정할 수 있는 정보가 포함되어 있었습니다.
SQL 자체에 고객 이름이 없더라도 회사의 내부 데이터 구조가 드러날 수 있습니다.
따라서 실제 운영 SQL을 외부 AI에 입력하기 전에는 회사 정책과 자료의 민감도를 확인해야 합니다.
사례 3. 장애 로그에 인증정보가 포함된 경우
IT 운영담당자가 시스템 오류를 분석하기 위해 장애 로그를 AI에 입력했습니다.
그런데 로그 일부에 인증 토큰이나 내부 서버 주소가 포함되어 있었습니다.
이 경우 단순한 문서 노출을 넘어 인증정보 유출 위험까지 발생할 수 있습니다.
특히 실제 인증정보가 노출되었다면 신속한 보안 대응이 필요할 수 있습니다.
사례 4. 고객정보를 일부 마스킹한 뒤 업로드한 경우
데이터 분석 담당자가 고객 이름과 카드번호를 가린 거래 데이터를 AI에 입력했습니다.
하지만 자료에는 상세 거래 시각, 이용 지역, 금액, 고객 속성이 남아 있었습니다.
이러한 정보의 조합으로 특정 개인을 알아볼 가능성이 있다면 개인정보 보호 위험이 남아 있을 수 있습니다.
따라서 일부 식별정보를 가렸다는 이유만으로 안전하다고 판단해서는 안 됩니다.
사례별 위험 요약
| 사례 | 주요 위험 |
| 회의록 업로드 | 내부 업무정보 및 개인정보 노출 |
| 실제 SQL 입력 | 데이터 구조와 업무 규칙 노출 |
| 장애 로그 입력 | 인증정보 및 시스템 정보 노출 |
| 거래 데이터 마스킹 후 입력 | 재식별 및 금융거래 정보 노출 |
이러한 사례에서 공통적으로 확인할 수 있는 문제는 자료를 입력하기 전에 정보의 민감도와 외부 전송 가능 여부를 충분히 검토하지 않았다는 점입니다.
6. 금융 IT 직장인이 지켜야 할 AI 보안 수칙 7가지
실제 업무에서 활용할 수 있도록 핵심 보안 수칙을 일곱 가지로 정리하겠습니다.
수칙 1. 회사가 승인한 AI 도구만 사용합니다
회사 업무에 AI를 사용하기 전에는 해당 도구가 업무용으로 승인되어 있는지 확인해야 합니다.
개인적으로 가입한 AI 서비스가 편리하더라도 회사 자료를 처리하는 데 사용해도 된다는 의미는 아닙니다.
수칙 2. 입력할 자료의 보안 등급을 먼저 확인합니다
고객정보, 내부 기밀정보, 시스템 정보 등이 포함되어 있는지 확인합니다.
자료의 외부 전송이 허용되는지 판단하기 어렵다면 임의로 입력하지 말고 관련 담당 부서에 확인해야 합니다.
수칙 3. 필요한 정보만 최소한으로 입력합니다
AI에 질문할 때 반드시 필요한 정보만 제공하는 것이 좋습니다.
예를 들어 SQL의 일반적인 성능 개선 원리를 알고 싶다면 실제 고객 테이블과 운영 SQL 전체를 제공할 필요가 없을 수 있습니다.
수칙 4. 실제 자료 대신 가상 데이터를 우선 활용합니다
SQL 예제나 장애 분석 연습에는 실제 운영 데이터 대신 가상의 테이블, 컬럼, 거래정보를 사용하는 것이 좋습니다.
이때 실제 내부 시스템 구조를 그대로 재현하지 않도록 주의합니다.
수칙 5. API 키와 비밀번호 등 인증정보를 입력하지 않습니다
실제 인증정보는 AI 질문에 포함하지 않아야 합니다.
오류 분석이 필요하다면 인증정보를 제거한 안전한 예시를 사용하고, 관련 로그의 공유 가능 여부를 확인합니다.
수칙 6. AI 결과를 검증하고 운영 시스템에 바로 적용하지 않습니다
AI가 작성한 SQL이나 프로그램 코드는 오류가 있을 수 있습니다.
특히 데이터 변경, 권한 설정, 시스템 재시작 등 실제 서비스에 영향을 줄 수 있는 작업은 검증과 승인 절차가 필요합니다.
수칙 7. AI 사용 기록과 사고 대응 절차를 확인합니다
회사가 AI 사용 기록 관리나 승인 절차를 운영한다면 이를 따라야 합니다.
또한 잘못된 자료 입력이나 정보 노출이 의심될 때 누구에게 신고해야 하는지 미리 확인하는 것이 좋습니다.
AI 보안 수칙 7가지 요약
| 번호 | 보안 수칙 | 핵심 행동 |
| 1 | 승인된 AI 사용 | 회사 이용 지침 확인 |
| 2 | 정보 등급 확인 | 외부 전송 가능 여부 검토 |
| 3 | 최소 정보 입력 | 필요한 내용만 제공 |
| 4 | 가상 데이터 활용 | 실제 고객·운영 데이터 사용 지양 |
| 5 | 인증정보 보호 | 비밀번호·토큰·API 키 입력 금지 |
| 6 | 결과 검증 | 테스트와 변경관리 절차 준수 |
| 7 | 사고 대응 준비 | 기록 관리 및 신고 절차 확인 |
이 일곱 가지 원칙은 AI 활용을 막기 위한 규칙이 아니라, 업무 효율성과 금융정보 보호를 함께 달성하기 위한 기본적인 안전장치입니다.
7. 개인용 AI와 기업용 AI는 무엇이 다를까?
AI 서비스를 선택할 때 개인용과 기업용의 차이를 궁금해하는 경우가 많습니다.
일반적으로 기업용 서비스는 조직의 업무 활용을 고려한 관리 기능을 제공할 수 있습니다.
예를 들어 다음과 같은 기능입니다.
- 조직 계정 및 사용자 관리
- 접근 권한 통제
- 관리자 설정
- 보안 관련 관리 기능
- 데이터 이용 및 보관 조건에 관한 계약
- 조직 단위의 이용 정책 설정
다만 모든 기업용 AI 서비스가 동일한 기능을 제공하는 것은 아닙니다.
또한 기업용 서비스를 사용한다고 해서 모든 자료가 자동으로 안전하게 처리되는 것도 아닙니다.
개인용과 기업용 비교
| 구분 | 개인용 AI | 기업용 AI |
| 주요 이용 대상 | 개인 사용자 | 조직 및 업무 사용자 |
| 계정 관리 | 개인 중심 | 조직 관리 기능 제공 가능 |
| 데이터 이용 조건 | 서비스·설정에 따라 다름 | 계약 및 설정에 따라 다름 |
| 접근 통제 | 개인 계정 중심 | 조직별 권한 관리 가능 |
| 업무자료 사용 | 회사 정책 확인 필요 | 승인 범위와 정보 등급 확인 필요 |
| 보안 책임 | 사용자 주의 필요 | 조직의 관리·감독도 중요 |
핵심은 서비스 이름에 '기업용'이라는 단어가 들어 있는지가 아닙니다.
회사에서 해당 서비스를 어떤 조건으로 승인했으며, 어떤 종류의 데이터를 처리하도록 허용했는지가 중요합니다.
8. AI에 회사 자료를 잘못 입력했다면 어떻게 해야 할까?
AI를 사용하다가 실수로 내부 자료를 입력했다면 어떻게 해야 할까요?
가장 중요한 것은 문제를 숨기거나 혼자 해결하려고 하지 않는 것입니다.
① 추가 입력과 공유를 중단합니다
해당 자료를 더 이상 입력하거나 다른 서비스로 전달하지 않습니다.
② 회사의 정보보호 담당 부서에 신속하게 알립니다
소속 회사의 보안 사고 신고 절차에 따라 관련 사실을 알립니다.
개인정보가 포함되어 있다면 개인정보 보호 담당 조직의 검토가 필요할 수 있습니다.
③ 입력한 정보의 종류와 범위를 확인합니다
어떤 자료를 입력했는지, 개인정보나 인증정보가 포함되었는지, 파일을 업로드했는지 등을 확인합니다.
필요한 기록은 회사의 지침에 따라 보존해야 합니다.
④ 삭제 가능 여부와 추가 조치를 확인합니다
AI 서비스에서 제공하는 삭제 기능을 이용할 수 있는지 확인할 수 있습니다.
다만 대화 삭제만으로 모든 데이터가 즉시 완전히 삭제된다고 단정해서는 안 됩니다.
서비스의 보관 정책과 회사의 대응 절차를 함께 확인해야 합니다.
⑤ 인증정보가 포함되었다면 별도 대응이 필요할 수 있습니다
API 키나 비밀번호, 접근 토큰 등이 노출되었다면 관련 담당 부서에서 해당 인증정보의 폐기·재발급·교체 등 필요한 조치를 검토해야 합니다.
이 과정에서는 해당 인증정보를 사용하는 시스템에 미치는 영향도 고려해야 합니다.
⑥ 사고 처리 결과를 기록하고 재발 방지 방안을 마련합니다
실수의 원인을 확인하고 필요한 교육이나 절차 개선을 진행하는 것이 중요합니다.
실제 법적 신고 의무와 처리 기한은 사고의 내용, 적용 법령, 피해 여부 등에 따라 달라질 수 있으므로 담당 조직의 판단을 따라야 합니다.
9. 안전하게 AI를 활용하는 실무 질문 예시
그렇다면 금융 IT 담당자는 AI를 어떻게 활용하는 것이 좋을까요?
회사에서 허용한 환경과 사용 범위를 지킨다는 전제하에, 실제 내부자료 없이도 활용할 수 있는 방법을 살펴보겠습니다.
예시 1. 가상의 SQL 분석
질문
"다음은 실제 업무와 관계없는 가상 SQL이야. 처리 구조를 설명하고 성능 점검 시 확인할 항목을 정리해 줘."
SELECT
CATEGORY,
COUNT(*) AS CNT,
SUM(AMOUNT) AS TOTAL_AMOUNT
FROM SAMPLE_TRANSACTION
WHERE TXN_DATE >= '20261001'
AND TXN_DATE < '20261101'
GROUP BY CATEGORY;이러한 질문은 실제 고객정보나 내부 데이터베이스 구조를 제공하지 않고도 SQL 분석 방법을 학습하는 데 도움이 됩니다.
예시 2. 가상의 장애 상황 분석
질문
"일반적인 웹 서비스에서 응답 시간이 증가하고 일부 요청이 시간 초과되는 가상 상황이야. 시스템 자원, 네트워크, 데이터베이스 관점에서 가능한 원인과 점검 항목을 정리해 줘. 원인을 단정하지는 마."
이 방식은 실제 내부 로그를 입력하지 않고도 장애 분석 관점을 정리할 수 있습니다.
예시 3. 보고서 양식 작성
질문
"금융 IT 시스템 개선 검토서에 사용할 일반적인 보고서 양식을 만들어 줘. 배경, 현황, 문제점, 개선 방향, 위험, 일정, 후속 조치 항목으로 구성해 줘. 실제 회사 정보는 포함하지 마."
이처럼 양식만 먼저 작성한 뒤 실제 업무자료는 회사에서 승인한 환경에서 작성·관리할 수 있습니다.
예시 4. 현업 요청사항 분류 체계 만들기
질문
"DW 운영 업무에서 자주 발생하는 요청사항을 조회 성능, 데이터 품질, 신규 데이터 제공, 권한 관리, 운영 문의 등으로 분류하는 일반적인 기준을 제안해 줘."
실제 현업 요청사항을 입력하지 않아도 분류 기준을 설계하는 데 참고할 수 있습니다.
예시 5. AI 결과 검증 체크리스트
질문
"AI가 작성한 SQL을 검토할 때 결과 정확성, 데이터 변경 위험, 성능, 보안, 예외 처리 관점에서 확인할 체크리스트를 만들어 줘."
이러한 방식은 AI를 직접적인 의사결정자가 아니라 검토를 돕는 도구로 활용하는 예시입니다.
10. AI 사용 전 1분 보안 체크리스트
업무 중 AI를 사용하기 전에 다음 항목을 확인해 보겠습니다.
AI 사용 전 확인사항
-
회사에서 사용을 승인한 AI 도구인가?
-
입력하려는 자료가 외부 처리에 허용된 정보인가?
-
고객 개인정보나 금융거래 정보가 포함되어 있지 않은가?
-
내부 시스템 구성이나 보안정보가 포함되어 있지 않은가?
-
비밀번호, API 키, 접근 토큰 등이 포함되어 있지 않은가?
-
실제 자료 대신 가상의 예시로 질문할 수 없는가?
-
연결된 외부 기능과 데이터 처리 조건을 확인했는가?
-
AI 결과를 담당자가 검증할 계획이 있는가?
-
운영 적용 시 필요한 승인 절차를 알고 있는가?
이 가운데 하나라도 판단하기 어려운 항목이 있다면 자료 입력을 보류하고 회사의 관련 담당 부서에 확인하는 것이 안전합니다.
AI 활용 판단 기준
| 상황 | 권장 판단 |
| 공개된 기술 개념을 질문 | 회사의 일반 이용 정책 범위에서 활용 검토 |
| 가상의 SQL 예제 분석 | 승인된 도구에서 활용 가능 여부 확인 |
| 실제 고객 거래 내역 입력 | 임의 입력 금지, 별도 적법성·승인 검토 |
| 내부 장애 로그 업로드 | 정보 등급 및 회사 승인 여부 확인 |
| 비밀번호·API 키 입력 | 입력 금지 |
| 보고서 양식 작성 | 실제 기밀정보 없이 초안 작성 가능 |
| 운영 SQL 자동 실행 | 별도 검증 및 승인 절차 필요 |
11. 자주 묻는 질문
Q1. 챗GPT에 회사 자료를 올리면 무조건 외부에 공개되나요?
반드시 그렇지는 않습니다.
외부 AI 서비스에 자료를 입력하는 것과 불특정 다수에게 공개되는 것은 서로 다른 개념입니다.
하지만 자료가 서비스 제공자의 시스템에서 처리되거나 저장될 수 있으므로 외부 전송 및 처리에 관한 회사의 허용 여부를 확인해야 합니다.
Q2. AI가 학습하지 않는다고 하면 회사 자료를 올려도 되나요?
그렇지 않습니다.
모델 학습에 사용되지 않는다는 조건은 중요한 확인 사항이지만, 회사 자료의 외부 전송을 허용한다는 의미는 아닙니다.
데이터 저장, 접근 권한, 보관 기간, 계약 조건, 회사 정책 등을 함께 확인해야 합니다.
Q3. 고객 이름과 카드번호를 지우면 안전한가요?
단순히 직접 식별정보를 가렸다고 해서 완전히 안전하다고 볼 수는 없습니다.
거래 시각, 금액, 이용 지역 등 다른 정보와 결합해 개인을 알아볼 가능성이 남아 있을 수 있습니다.
Q4. 회사에서 승인한 기업용 AI에는 모든 자료를 입력해도 되나요?
아닙니다.
기업용 AI라도 회사에서 허용한 사용 범위와 정보 등급을 지켜야 합니다.
특히 개인정보와 금융거래 정보, 내부 기밀정보는 별도 기준이 적용될 수 있습니다.
Q5. 실제 SQL에 고객정보가 없으면 외부 AI에 입력해도 되나요?
반드시 그렇지는 않습니다.
SQL에는 내부 테이블 구조, 업무 규칙, 시스템 구성 등이 드러날 수 있습니다.
따라서 고객정보 포함 여부뿐 아니라 회사의 기밀정보에 해당하는지도 확인해야 합니다.
Q6. AI에 입력한 대화를 삭제하면 모든 문제가 해결되나요?
대화 삭제 기능과 실제 데이터 보관·삭제 정책은 서비스마다 다를 수 있습니다.
따라서 삭제만으로 모든 위험이 해소된다고 단정해서는 안 되며, 회사의 보안 사고 대응 절차를 따라야 합니다.
Q7. 금융 IT 직장인이 AI를 가장 안전하게 시작하는 방법은 무엇인가요?
회사에서 승인한 AI 환경을 이용하고, 실제 고객정보나 내부 기밀정보가 없는 공개 자료와 가상의 예시부터 활용하는 것이 좋습니다.
회의록 양식 작성, SQL 개념 설명, 점검 체크리스트 작성 등으로 시작할 수 있습니다.
12. 마무리｜AI 활용 능력만큼 정보보안 판단 능력도 중요합니다
생성형 AI는 금융 IT 업무의 생산성을 높일 수 있는 유용한 도구입니다.
회의록 정리, SQL 분석, 보고서 작성, 장애 원인 검토 등 다양한 업무에 활용할 수 있습니다.
하지만 금융회사에서 AI를 사용할 때는 일반적인 업무 편의성보다 먼저 확인해야 할 사항이 있습니다.
바로 고객정보 보호와 회사의 정보보안 기준입니다.
AI가 편리하다는 이유로 내부 자료를 무단으로 입력하거나 실제 운영 정보를 검증 없이 활용한다면 오히려 새로운 위험을 만들 수 있습니다.
오늘 내용을 세 가지로 정리하겠습니다.
첫째, AI에 입력한 정보는 서비스와 계약 조건에 따라 외부 시스템에서 처리·보관될 수 있으므로 데이터 처리 방식을 확인해야 합니다.
둘째, 고객 개인정보뿐 아니라 금융거래 정보, 내부 시스템 구조, 인증정보, 회사 기밀정보도 보호해야 합니다.
셋째, 회사에서 승인한 AI 환경을 사용하고 가상 데이터 활용, 최소 정보 입력, 결과 검증 등의 원칙을 지켜야 합니다.
오랫동안 금융 IT 업무를 수행한 직장인은 시스템 안정성과 정보보안의 중요성을 잘 알고 있습니다.
이러한 경험은 AI 시대에도 중요한 경쟁력이 될 수 있습니다.
새로운 기술을 적극적으로 활용하되, 그 기술이 가져올 수 있는 위험까지 함께 판단하는 능력이 필요하기 때문입니다.
금융 IT 직장인의 올바른 AI 활용은 'AI를 얼마나 잘 쓰는가'뿐 아니라 '어떤 정보를 입력하지 말아야 하는가'를 아는 것에서 시작합니다.
함께 읽으면 좋은 글
[생활 속 금융 기술 #10] 50대 금융 IT 직장인의 AI 활용법｜회의록·SQL·보고서 작성 시간을 줄이는 실전 노하우
생성형 AI를 회의록, 보고서, SQL 분석, 시스템 운영 업무에 활용하는 방법을 알아봅니다.
[생활 속 금융 기술 #09] 카드 결제가 갑자기 안 되는 이유｜금융 IT 담당자는 시스템 장애를 어떻게 찾아낼까?
금융 IT 운영담당자가 시스템 로그와 모니터링 지표를 이용해 장애를 분석하는 과정을 설명합니다.
[생활 속 금융 기술 #08] 내가 쓰지 않은 카드 결제 문자가 왔다면?
신용카드 부정 사용 대응과 이상거래탐지시스템(FDS)의 원리를 살펴봅니다.
다음 글 예고
[생활 속 금융 기술 #12] 금융 IT 직장인의 SQL 성능 개선 기초｜조회가 느려지는 이유와 실행 계획 확인법
같은 데이터를 조회하는 SQL인데 어떤 쿼리는 빠르고 어떤 쿼리는 느린 이유는 무엇일까요?
다음 글에서는 SQL 실행 계획, 인덱스, 파티션, 데이터 분포, 통계정보 등 조회 성능에 영향을 주는 요소를 실무 관점에서 쉽게 설명하겠습니다.
