AI Security Guardrail 설계: 개발팀의 보안 실수를 시스템으로 막는 법
AI Security Guardrail 설계: 개발팀의 보안 실수를 시스템으로 막는 법
2026년 9월 3일 공개된 티빙 침해사고 민관합동조사 결과는 개발자 입장에서 꽤 불편하게 읽힌다.
공격 기법이 특별히 새로운 것도 아니었기 때문이다.
조사 결과 공격자는 개발환경 접속키를 탈취해 내부 개발환경에 들어왔고, 이후 개발 프로젝트에서 운영환경 접속키를 추가 확보해 AWS 운영환경까지 침투했다. 소스코드를 포함한 기술자산은 361건, 약 30.35GB가 외부로 유출됐으며, 중복을 포함한 이용자 계정 약 3,954만 개가 영향을 받은 것으로 조사됐다.
더 충격적인 부분은 공격보다 그 전후다.
개발·운영환경 접속키가 소스코드에 노출되거나 사내 메신저로 공유됐고, 모든 개발자에게 전체 개발 프로젝트 접근 권한이 부여돼 있었다. 키의 발급·사용·변경·폐기와 정기점검 절차도 제대로 갖춰져 있지 않았다는 것이 조사 결과다. 2024년 모의해킹에서는 이미 소스코드 안 접속키 노출 문제가 발견됐지만 개선되지 않았다.
그리고 공격이 시작된 뒤에도 문제가 이어졌다.
실시간 네트워크·데이터 흐름을 탐지하고 차단하는 정보보호 체계 대신 CPU 부하 같은 시스템 모니터링에 주로 의존했고, 이상징후가 발생한 뒤 정보보호 조직에 공유되기까지 약 14시간이 걸렸다. 일부 접속기록은 약 6일만 보관됐으며, KISA 신고 역시 법정 시한을 넘긴 것으로 조사됐다.
이 사건을 단순히:
개발자가 키를 소스코드에 넣어서 사고가 났다.
정도로 정리하면 중요한 부분을 놓친다.
진짜 문제는 한 사람이 실수했을 때 그 실수가 Production 침해까지 그대로 이어질 수 있었던 시스템이다.
그리고 AI Coding Agent를 사용하는 지금은 이 문제를 조금 다르게 볼 필요가 있다.
사람이 보안을 놓칠 수 있다면 이제는 AI라도 한 번 더 보게 만들 수 있다.
다만 AI에게 보안을 “맡기는” 것이 아니다.
사람 → AI → 자동 보안 도구 → 권한 시스템 → Runtime 감시가 서로를 막아주는 구조를 만들어야 한다.
1. 이번 사고에서 가장 위험했던 건 Key 하나가 아니다
조사 결과를 개발 시스템 관점으로 단순화하면 이런 형태다.
개발자 Access Key 탈취
↓
개발환경 접근
↓
다수 프로젝트 접근
↓
Source Code 확보
↓
Source 안의 운영환경 Credential 확보
↓
Production 접근
↓
DB 접근
↓
데이터 대량 추출문제는 첫 번째 Key가 탈취됐다는 사실만이 아니다.
첫 Credential이:
Developer
→ Development에서 끝나지 않고,
Developer
→ Development
→ Source
→ Production Credential
→ Production
→ Database까지 이어졌다는 것이 더 위험하다.
좋은 보안 Architecture라면 중간마다 끊겨야 한다.
Developer Credential 탈취
↓
Development 일부 접근
X또는:
Source 탈취
↓
Production Credential 없음
X또는:
Production 접근 시도
↓
권한 부족 / MFA / 단기 Credential
X또는:
DB 대량 조회
↓
Anomaly Detection
↓
Session Kill + Alert
X공격자는 여러 방어선을 연속으로 통과해야 한다.
이를 Defense in Depth라고 한다.
이번 조사 결과에서 드러난 가장 큰 문제도 각각의 방어선이 충분히 독립적으로 작동하지 않았다는 점이다.
2. 보안은 개발자의 기억에 맡기면 안 된다
현실적인 개발팀에서 이런 대화는 꽤 흔하다.
"이 Key는 나중에 Secrets Manager로 옮기죠."
"일단 개발 서버니까 넣어둘게요."
"테스트 끝나면 지우겠습니다."
"이 Repository private인데 괜찮지 않나요?"문제는 대부분 악의가 없다는 것이다.
편해서 그렇게 한다.
일정이 급해서 그렇게 한다.
그리고 몇 달 뒤 아무도 기억하지 못한다.
그래서 보안 정책은:
개발자가 잘 지켜야 한다.에서 끝나면 안 된다.
더 좋은 시스템은:
개발자가 실수해도
실수가 Repository에 들어가지 못한다.여야 한다.
GitHub Push Protection이 대표적인 예다.
GitHub는 Push 과정에서 API Key나 Token 같은 Secret을 발견하면 Repository에 들어가기 전에 Push 자체를 차단할 수 있다. Secret Scanning은 Git History 전체에서도 Credential을 탐지할 수 있다.
즉:
개발자가 기억한다보다:
Git이 막는다가 강하다.
3. 이제 여기에 AI Security Reviewer를 하나 더 넣을 수 있다
2026년의 개발 환경에서는 한 단계 더 갈 수 있다.
Developer / Coding Agent
↓
Security Agent
↓
Deterministic Security Checks
↓
CI
↓
Runtime Security예를 들어 Codex가 Feature를 구현했다고 하자.
바로 PR을 올리지 않는다.
먼저 별도의 Claude나 다른 Agent가 Security Reviewer 역할을 맡는다.
Codex
→ 구현
Claude Security Review
→ 보안 관점 검토
CodeQL / Secret Scanner
→ 기계적 검증
CI
→ 최종 Gate중요한 것은 Claude가 작성한 코드를 Claude가 다시 고치는 구조가 아니라는 것이다.
Coding Agent
= 생산
Security Agent
= 의심
Security Tool
= 검출
Policy
= 차단각자의 역할을 나눈다.
4. AI Security Agent에게 “보안 확인해줘”라고 하면 안 된다
나쁜 요청:
보안 문제 없는지 확인해줘.이렇게 하면 결과가 모호하다.
대신 보안 계약을 고정한다.
이번 변경을 Security Reviewer 관점에서 검토한다.
반드시 확인:
Credential / Secret 노출
Authentication
Authorization
Privilege escalation
PII 접근
Logging
Network exposure
Dependency 변경
Encryption
Input validation
Production access
Cloud IAM
Data export 가능성
결과는:
CRITICAL
HIGH
MEDIUM
LOW
NOT VERIFIED
로 분리한다.
근거 없는 가능성은 취약점으로 단정하지 않는다.
코드를 수정하지 말고 Finding만 반환한다.이 Prompt 자체를 매번 작성할 필요도 없다.
security-review Skill로 만들어 두면 된다.
5. 하지만 AI가 Secret Scanner를 대체하면 안 된다
이 부분이 중요하다.
LLM이:
AKIA...같은 AWS Key를 발견할 수도 있다.
하지만 이런 건 AI가 할 일이 아니다.
GitHub Secret Scanning, Gitleaks, TruffleHog 같은 도구가 훨씬 적합하다.
현재 GitHub Secret Scanning은 알려진 Token뿐 아니라 Generic Secret 탐지에도 AI 기반 Detection을 일부 사용하며, Push Protection은 Credential이 Repository에 들어오기 전에 차단할 수 있다. GitHub MCP를 사용하는 AI 작업에서도 지원되는 환경에서는 Secret 노출을 차단하는 보호 기능이 적용된다.
따라서 역할은 이렇게 나누는 것이 좋다.
Secret Scanner
→ Secret 자체를 찾음
CodeQL / SAST
→ 알려진 코드 취약점 패턴 탐지
AI Security Reviewer
→ 여러 파일과 Architecture를 연결해 위험 판단
Human
→ 중요한 Architecture와 예외 승인AI는 보안 Tool 위의 reasoning layer로 사용하는 것이 좋다.
6. Repository에 Secret이 존재할 이유부터 없앤다
가장 먼저 해야 할 것은:
secret = "..."을 금지하는 것이다.
AWS도 Access Key를 Source Code나 Configuration에 넣는 방식을 명시적인 Anti-pattern으로 보고, 가능하면 IAM Role을 통한 Temporary Credential을 사용하고 장기간 보관해야 하는 Secret은 Secrets Manager 같은 전용 시스템에서 관리하도록 권장한다.
구조는:
Source Code
│
│ Secret 이름만 참조
▼
Runtime Identity
│
▼
Secrets Manager
│
▼
필요한 순간 Credential 획득이런 형태가 되어야 한다.
반대로:
Git
↓
API_KEY
↓
Production같은 연결이 존재하면 안 된다.
7. 가능하면 장기 Key 자체를 없앤다
더 좋은 방식은 Secret을 잘 숨기는 것이 아니라 없애는 것이다.
예를 들어 AWS 환경이라면:
Access Key
Secret Access Key를 개발자 PC나 Repository에 저장하는 대신:
IAM Role
STS
Temporary Credentials
OIDC같은 구조를 사용한다.
즉:
Permanent Credential보다:
Short-lived Credential이다.
만료 시간이 짧은 Credential은 탈취돼도 공격자의 활동 가능 시간을 줄인다.
AWS 역시 IAM Access Key가 필요할 때 가능하면 EC2·Lambda 등의 IAM Role과 단기 Credential을 사용하도록 권장한다.
8. 모든 개발자가 모든 Repository를 볼 필요도 없다
이번 티빙 조사 결과에서 상당히 눈에 띄는 부분이 모든 개발자에게 전체 개발 프로젝트 접근 권한이 부여돼 있었다는 것이다.
이건 공격자 입장에서 굉장히 좋다.
한 명만 뚫으면 된다.
Developer A Credential
↓
ALL PROJECTS좋은 구조는 다르다.
Developer A
→ iOS
Developer B
→ Backend Payment
Developer C
→ Recommendation
Security Team
→ Security Project그리고 필요할 때만 일시적으로 추가 권한을 준다.
이것이 Least Privilege다.
OWASP 역시 CI/CD와 개발 환경에서 개발자에게 필요한 기능만 허용하고 Project 관리 권한이나 불필요하게 높은 권한을 주지 않는 것을 권장한다.
9. 여기에서도 AI를 사용할 수 있다
재미있는 시스템을 하나 만들 수 있다.
Permission Review Agent다.
예를 들어 매일 새벽:
Security Agent
GitHub
AWS IAM
Secrets Manager
CI
Kubernetes의 Metadata를 읽는다.
그리고:
Developer A
최근 60일:
ios-app만 작업
현재 권한:
ios-app
backend
billing
infra
data-pipeline를 발견한다.
Agent가:
권한 과다 가능성을 Security Queue에 올린다.
다만 AI가 직접 Permission을 제거하면 위험하다.
따라서:
AI
→ 과도한 권한 후보 탐지
Policy Engine
→ 규칙 확인
Security/Human
→ 승인
IAM
→ 실제 변경형태가 적절하다.
10. Security Agent가 매 PR마다 보는 Architecture
추천 구조는 이렇다.
Developer / Coding Agent
│
▼
Git Diff
│
▼
┌───────────────┐
│ Security Agent│
└───────────────┘
│
┌──────┼───────┐
▼ ▼ ▼
Secret Auth Data Flow
Review Review Review
│ │ │
└──────┼───────┘
▼
Risk Report
│
▼
Deterministic Checks
│
┌──────┼────────┐
▼ ▼ ▼
Secret CodeQL Dependency
Scan Review
│
▼
CI Gate여기서 AI는:
"이 API가 새로 admin 권한을 요청하는데 정말 필요한가?"
"이 Repository에서 처음으로 production DB 접근 코드가 추가됐다."
"개인정보를 로그에 기록할 가능성이 있다."
"새 S3 bucket이 public access를 허용한다."
"API Response에 필요하지 않은 PII가 추가됐다."같은 Context-dependent 문제를 본다.
11. Security Agent는 Diff만 보면 안 된다
예를 들어 PR에 이런 코드가 추가됐다고 하자.
logger.info("login user: \(user)")컴파일도 된다.
Test도 통과한다.
Secret Scanner도 아무것도 못 찾는다.
하지만 user 안에:
email
phone
CI
birthDate같은 개인정보가 들어 있다면 문제가 될 수 있다.
AI Reviewer가 Repository의 User 모델과 Logging 코드를 함께 보면:
PII Logging Risk를 발견할 가능성이 있다.
이게 AI Security Review가 일반 정적 분석 위에서 할 수 있는 일이다.
12. PR에 새로운 권한이 생기면 Security Review를 자동 승격한다
모든 PR을 최고 수준으로 Review할 필요는 없다.
Risk를 분류한다.
LOW
UI
String
Layout
TestMEDIUM
Network API
Local Storage
DependencyHIGH
Authentication
Authorization
User Data
Encryption
Cloud IAM
PaymentCRITICAL
Production Credential
DB Migration
Admin Permission
Secret Management
Public Network Exposure그리고:
LOW
→ 일반 CI
MEDIUM
→ AI Security Review
HIGH
→ AI + Security Tool + Human
CRITICAL
→ Human Approval 필수로 간다.
13. GitHub Branch Protection과 결합한다
AI가 보안 경고를 했는데 개발자가:
일단 Merge하고 다음 Sprint에서 고치죠.라고 할 수 있다.
그래서 Policy가 필요하다.
예:
CRITICAL
→ Merge Block
HIGH
→ Security Approval Required
MEDIUM
→ Warning
LOW
→ AdvisoryCodeQL 역시 Repository 설정에 따라 Code Scanning Check를 Required Check로 만들어 문제가 해결되기 전 Merge를 막을 수 있다.
즉 중요한 것은:
AI가 말했다.가 아니다.
Policy가 Merge를 막았다.이다.
14. 이번 사고를 기준으로 가장 먼저 막아야 할 것은 Secret이다
추천 Pipeline의 첫 번째 Gate는 아주 단순하다.
Developer
↓
Local Commit
↓
Secret Scan
↓
Git Push
↓
Push ProtectionSecret이 발견되면:
STOP이다.
“다음에 고치기”가 없다.
GitHub Push Protection에서는 예외적으로 Bypass할 수도 있지만, 조직에서는 Delegated Bypass를 통해 별도 Reviewer 승인 절차를 둘 수 있다.
즉:
개발자가 스스로 우회보다:
Security Reviewer 승인 필요가 훨씬 안전하다.
15. Secret이 유출됐으면 삭제보다 Rotation이 먼저다
개발팀에서 의외로 자주 나오는 오해가 있다.
Git에서 Key 지웠습니다.그러면 끝난 게 아니다.
이미 Commit History에 존재할 수도 있고 외부로 복제됐을 수도 있다.
Credential이 노출됐다고 판단되면:
Revoke
↓
Rotate
↓
사용처 변경
↓
Git History 정리
↓
Access Log 확인순서가 더 중요하다.
AWS Secrets Manager도 Secret Rotation을 자동화할 수 있다.
AI Security Agent가 Secret 발견 시 바로 이런 Runbook을 생성하도록 할 수 있다.
16. AI에게 Incident Runbook도 맡길 수 있다
예를 들어 Security Agent가 Production Credential 노출을 발견했다.
그러면:
CRITICAL: AWS Credential exposed만 남기지 않는다.
자동으로:
1. Credential revoke 후보
2. 영향을 받는 Service
3. 최근 사용 기록
4. 접근 가능한 Resource
5. Rotation 대상
6. 관련 Repository
7. 관련 Deployment를 정리한다.
그리고 Security 담당자가:
EXECUTE를 승인한다.
이런 것이 AI의 좋은 사용 방식이다.
17. Runtime까지 가면 AI의 역할이 더 커진다
티빙 사고에서는 공격자가 5월 30일 1차 데이터 유출을 시도했고 DB Server 과부하로 이상징후가 감지돼 차단됐지만, 다음 날 가상서버를 생성해 이용자 정보 약 24GB를 저장한 뒤 외부로 유출하고 가상서버를 삭제한 것으로 조사됐다.
여기에서 중요한 질문이 생긴다.
왜 CPU가 올라갔는지는 봤는데
누가
어떤 Credential로
어떤 DB에서
얼마나 많은 데이터를 읽어
어디로 전송했는지는
즉시 연결되지 않았는가?Runtime Security는 CPU 그래프만 봐서는 부족하다.
18. AI Security Agent는 Runtime Event를 연결하는 데 유용하다
예를 들어 이런 Event가 동시에 발생한다.
03:11
새 VM 생성
03:14
DB SELECT 급증
03:16
Data Transfer 증가
03:18
평소 사용하지 않던 Credential 사용
03:21
해외 IP 연결
03:25
VM 삭제각 이벤트 하나만 보면 정상일 수도 있다.
하지만 연결하면:
Possible Data Exfiltration이다.
이런 Cross-system Correlation이 AI가 잘할 수 있는 영역이다.
CloudTrail
+
VPC Flow Log
+
DB Audit Log
+
IAM
+
Git Deployment
+
SIEM을 연결해 설명한다.
19. 그렇다고 AI에게 실시간 차단권을 바로 주면 안 된다
예를 들어 AI가:
공격 같습니다.라고 판단했다고 Production DB 전체를 끊으면 장애가 발생할 수 있다.
그래서 자동화 수준을 나눈다.
OBSERVE
→ 로그 분석
ALERT
→ Security Team 호출
CONTAIN
→ Session Kill / Key Disable 후보 제시
AUTO-CONTAIN
→ 명확한 규칙일 때만 자동 차단예를 들어:
Retired Credential 사용
Revoked Key 사용
Impossible Travel
금지된 국가에서 Admin Token 사용같은 명백한 상황은 자동 대응 가능성이 높다.
반면:
데이터 조회량이 조금 많음같은 것은 Human Review가 필요하다.
20. 결국 AI보다 먼저 필요한 건 로그다
AI가 아무리 강해도 Logging이 없으면 못 본다.
이번 조사에서도 일부 시스템 기록이 약 6일만 보관됐고 신규 장비에 로그관리 정책이 제대로 적용되지 않은 문제가 확인됐다.
AI Security Agent에게:
지난달 공격자가 무엇을 했지?라고 물어도 Log가 없으면 답할 수 없다.
따라서 먼저:
누가
언제
어떤 Credential로
어떤 Resource에
어떤 Action을 했고
얼마나 데이터를 읽었는가가 남아야 한다.
AI는 그 위에 올라간다.
21. Security Agent가 매일 새벽에 자동 점검하게 한다
개발자가 Security Dashboard를 매일 확인하지 않을 수 있다.
AI는 할 수 있다.
예를 들어 매일 새벽:
Security Agent
01. Git Secret Alert 확인
02. IAM 신규 권한 확인
03. Admin 권한 증가 확인
04. 오래된 Access Key 확인
05. Rotation 안 된 Secret 확인
06. 새로운 Public Endpoint 확인
07. 새로운 Dependency 확인
08. 최근 Critical Code Scan 확인
09. 비정상 Production Access 확인
10. 미해결 Security Finding 확인을 수행한다.
결과가 없으면 아무것도 하지 않는다.
문제가 있으면:
Security Inbox에 올린다.
22. 특히 “발견됐지만 안 고친 문제”를 AI가 추적하게 한다
이번 조사 결과에서 가장 아픈 부분 중 하나는 2024년 모의해킹에서 접속키 노출 문제가 발견됐지만 개선되지 않았다는 것이다.
보안에서는 발견보다 Closure가 중요하다.
그래서 Security Finding에 상태를 둔다.
OPEN
↓
ASSIGNED
↓
FIXED
↓
VERIFIED
↓
CLOSED그리고:
OPEN → 7일
HIGH
OPEN → 30일
CRITICAL ESCALATION같은 규칙을 둔다.
AI가 매일:
90일째 열린 HIGH Finding 3건을 찾아 Security Lead와 개발 책임자에게 올린다.
23. 모의해킹 보고서도 PDF로 끝나면 안 된다
흔한 구조:
Pentest
↓
PDF
↓
메일
↓
회의
↓
보관좋은 구조:
Pentest
↓
Findings DB
↓
Owner
↓
Deadline
↓
Fix
↓
Automated Verification
↓
Retest
↓
Close이다.
AI는 여기서 Pentest 보고서를 읽고 Finding을 Issue로 구조화하는 데 매우 유용하다.
24. 보안 전담인력이 적을수록 AI가 더 의미 있을 수 있다
이번 조사에서 티빙 임직원 265명 가운데 개발인력은 149명, 정보보호 전담인력은 약 4명 수준으로 조사됐다. 조사단은 이런 인력 규모로 상시 관제·취약점 점검·이상행위 모니터링 등에 한계가 있었다고 판단했다.
개발자 149명의:
PR
Dependency
IAM
Secret
Cloud
API
Database
Log를 4명이 모두 수동으로 보는 것은 현실적으로 어렵다.
여기서 AI가 의미가 있다.
AI는 보안 전문가를 없애는 것이 아니라:
149명 개발자
↓
AI Security Layer
↓
중요한 20건
↓
Security Team으로 Noise를 줄인다.
25. 추천하는 전체 Architecture
실제 개발팀이라면 이 구조가 가장 현실적이다.
Developer
│
▼
Coding Agent
│
▼
Git Commit
│
▼
Secret / Credential Scan
│
Secret 발견?
YES ───────→ BLOCK
│
▼
Pull Request
│
┌────────────────┼────────────────┐
▼ ▼ ▼
CodeQL Dependency AI Security
SAST Review Review
│ │ │
└────────────────┼────────────────┘
▼
Security Score
│
┌──────────┼──────────┐
▼ ▼ ▼
LOW HIGH CRITICAL
│ │ │
▼ ▼ ▼
CI Security Human
Review Approval
│
▼
Deploy
│
▼
Runtime
│
┌───────────────┼────────────────┐
▼ ▼ ▼
IAM Log DB Audit Network Flow
│ │ │
└───────────────┼────────────────┘
▼
AI Security Monitor
│
이상 행동 Correlation
│
┌───────────┴───────────┐
▼ ▼
ALERT AUTO-CONTAIN
│ 명확한 Rule만
▼
Security TeamAI 하나가 모든 것을 지키는 구조가 아니다.
AI가 여러 기존 보안 시스템 사이에서 놓친 연결을 찾는 구조다.
26. Repository는 이렇게 구성할 수 있다
project/
├── AGENTS.md
├── SECURITY.md
│
├── .security/
│ ├── policy.yaml
│ ├── data-classification.yaml
│ ├── permissions.yaml
│ └── exceptions.yaml
│
├── skills/
│ ├── security-review/
│ ├── dependency-review/
│ └── incident-triage/
│
├── src/
└── tests/SECURITY.md에는 인간이 읽을 원칙을 두고,
.security/policy.yaml에는 기계가 읽을 규칙을 둔다.
27. 예를 들어 Security Policy
secret:
hardcoded: deny
production_key_in_repo: deny
permissions:
new_admin_permission: human_approval
wildcard_resource: security_review
data:
pii_logging: deny
bulk_export: security_review
network:
new_public_endpoint: security_review
dependencies:
critical_vulnerability: deny
production:
direct_developer_access: deny이렇게 만들어 두면 AI Security Agent 역시 이 Policy를 기준으로 판단할 수 있다.
28. Coding Agent도 같은 규칙을 먼저 읽게 한다
이제 Codex나 Claude Code에게 기능을 구현시키기 전에:
AGENTS.md
SECURITY.md
.security/policy.yaml을 읽게 한다.
그러면 구현 단계부터:
Secret을 어디에 둘 것인가
새 Permission이 필요한가
PII를 다루는가
Public Endpoint인가
Logging에 개인정보가 들어가는가를 확인한다.
즉 Security Review가 PR 마지막에서만 발생하지 않는다.
Design
→ Implementation
→ Review
→ Runtime전체에 들어간다.
29. AI가 개발자의 보안 습관까지 조금씩 바꿀 수 있다
예를 들어 Agent가 매번:
이 변경은 Production IAM 권한이 추가되므로
Security Review가 필요합니다.라고 알려준다.
또:
이 Credential은 장기 Access Key 대신
Role 기반 Temporary Credential을 사용할 수 있습니다.라고 제안한다.
이게 반복되면 개발자도 자연스럽게:
Credential
→ Secrets Manager
Permission
→ Least Privilege
Production
→ Temporary Role
PII
→ Redaction을 기본값으로 생각하기 시작한다.
30. 하지만 AI가 보안 책임자가 되어서는 안 된다
이 글에서 가장 중요한 선이다.
AI가 있으니
보안팀이 없어도 된다.가 아니다.
오히려 반대다.
AI가 필요한 이유는:
Security Team의 시간을
정말 중요한 판단에 사용하기 위해서다.
AI Security Agent는:
찾기
분류
연결
요약
추적을 잘한다.
사람은:
위험 수용
Architecture 결정
Incident 대응
법적 판단
Production 차단 결정을 맡는다.
31. 티빙 사고에서 배울 가장 중요한 것은 “한 번의 실수”가 아니다
이번 사고는 개발자의 Credential 하나가 탈취된 것에서 시작했지만 조사 결과를 보면 그 뒤로 여러 방어선이 연속해서 제대로 작동하지 않았다.
Access Key 관리
Repository Secret
Project Permission
Production Credential
Network Access Control
DB Monitoring
Data Flow Detection
Log Retention
Incident Escalation
Vulnerability Closure이 중 몇 개만 제대로 작동했어도 피해 규모는 달라졌을 가능성이 있다.
따라서 문제를:
개발자가 Key를 잘못 관리했다.로 끝내면 다시 비슷한 사고가 난다.
보안에서 인간의 실수를 없앨 수는 없다.
대신 한 번의 인간 실수가 대규모 사고가 되지 못하도록 설계할 수 있다.
마무리
티빙 침해사고는 최신 Zero-day 하나 때문에 모든 것이 무너진 사건으로 보기는 어렵다.
2026년 9월 3일 공개된 민관합동조사 결과에서는 개발환경 접속키 관리, 전체 프로젝트 접근권한, 소스 내 운영환경 Credential, 미조치된 기존 취약점, 부족한 이상징후 탐지, 짧은 로그 보관, 사고 보고 지연까지 여러 문제가 함께 확인됐다.
그래서 개발팀이 얻어야 할 결론도:
개발자들에게 보안 교육을 더 하자.
에서 끝나면 부족하다.
교육은 필요하다.
하지만 사람은 다시 실수한다.
더 강한 구조는 이렇다.
Developer
↓
Coding Agent
↓
Secret Guard
↓
AI Security Review
↓
CodeQL / Dependency Scan
↓
Policy Gate
↓
CI
↓
Runtime Monitoring
↓
AI Correlation
↓
Security Team즉 보안을:
사람이 잘 기억해야 하는 규칙에서:
어기기 어려운 시스템의 기본값으로 바꾸는 것이다.
그리고 AI가 들어가면서 한 가지 새로운 선택지가 생겼다.
기존 보안 Tool이:
Secret 발견
취약점 발견
Dependency 문제 발견을 한다면 AI Security Agent는 그 위에서:
왜 위험한가
무엇과 연결되는가
어디까지 영향을 주는가
다음에 무엇을 해야 하는가
아직 해결되지 않은 문제는 무엇인가를 계속 추적할 수 있다.
특히 보안 전담인력이 개발조직에 비해 작은 회사라면 의미가 크다.
AI가 보안 전문가를 대신하는 것이 아니다.
보안 전문가가 모든 PR과 모든 IAM 변경과 모든 로그를 직접 보지 않아도 되도록, AI가 먼저 의심하고 자동화된 시스템이 먼저 막게 만드는 것이다.
궁극적인 목표는:
AI가 보안을 잘한다.가 아니다.
더 좋은 시스템은:
개발자가 실수하고
AI가 놓치고
Security Reviewer도 놓쳐도
마지막 Policy와 Runtime Control이
사고를 막는다.이다.
보안은 사람의 주의력에 의존할수록 약해지고, 여러 독립된 시스템이 서로를 검증할수록 강해진다.
AI는 그 방어선 중 하나가 될 수 있다.
그리고 2026년의 개발환경이라면 이제는 그 방어선을 굳이 빼둘 이유도 없다.
참고 자료
2026년 9월 3일 과학기술정보통신부 민관합동조사 결과를 인용한 연합뉴스 보도에 따르면 티빙 사고에서는 약 3,954만 계정과 소스코드를 포함한 기술자산 361건이 유출됐으며, 개발·운영환경 Credential 관리, 프로젝트 접근권한, 이상징후 탐지·보고, 취약점 개선 등 여러 보안 통제가 함께 미흡했던 것으로 조사됐다. 개인정보보호위원회는 개인정보 유출 규모와 관련 법 위반 여부 등을 별도로 조사하고 있다.
GitHub의 Secret Scanning과 Push Protection은 Source와 Git History에서 Credential을 탐지하고, 지원되는 Secret이 Repository에 들어가기 전에 Push 자체를 차단할 수 있다. CodeQL과 Code Scanning은 Pull Request 단계에서 보안 취약점을 탐지하고 Required Check로 활용할 수 있다.
AWS Well-Architected Security guidance는 장기간 Access Key를 Source Code나 설정 파일에 넣는 방식을 피하고, 가능한 경우 IAM Role 기반의 단기 Credential을 사용하며 필요한 Secret은 전용 Secret 관리 시스템에서 관리·회전하도록 권고한다.
핵심 참고 포인트
이번 사고에서 가장 중요한 교훈은 특정 개발자의 실수 하나가 아니라 Credential → Repository → Production → Database로 이어지는 공격 경로를 중간에서 차단할 독립적인 보안 통제가 충분히 작동하지 않았다는 점이다.
따라서 AI Security Agent 역시 단독 방어책으로 두면 안 된다. 가장 현실적인 구조는 Secret 차단 → 최소권한 → AI Security Review → 정적 분석 → CI Policy → Runtime Monitoring → Incident Response를 겹쳐 놓고, AI는 그 사이에서 Context 분석·우선순위·미해결 Finding 추적을 담당하게 만드는 것이다.
