![[심층분석] AI 에이전트에게 '보안 감각'을 심는 방법 — reverse-skill이 보여준 스킬 라우터 설계](/newsimg/KEH55l2HIDXc4jbe.png)
AI는 코드를 잘 쓰는데, 왜 보안 작업 앞에서는 헤맬까요
요즘 Claude Code나 Cursor, Cline 같은 AI 코딩 도구 안 써보신 분 거의 없을 거예요. 웹 API 하나 만들어달라고 하면 뚝딱 만들어주고, 테스트 코드도 알아서 붙여주죠. 그런데 여기에 APK 파일 하나를 던져놓고 "이 앱 안에 API 키가 하드코딩돼 있는지 확인해줘"라고 하면 갑자기 분위기가 이상해져요. 어떤 때는 jadx를 쓰고, 어떤 때는 apktool을 쓰고, 또 어떤 때는 갑자기 존재하지 않는 명령어를 만들어내면서 자신 있게 실행하려 들거든요.
왜 이럴까요? 코드 작성은 AI가 학습한 데이터가 어마어마하게 많은 영역이에요. 반면 리버스 엔지니어링(이게 뭐냐면, 이미 완성돼서 배포된 프로그램을 거꾸로 뜯어서 내부가 어떻게 동작하는지 알아내는 작업이에요)이나 침투 테스트(허락받은 시스템을 실제 공격자처럼 찔러보면서 취약점을 찾아내는 일)는 완전히 다른 세계예요. 여기서 중요한 건 "코드를 얼마나 잘 쓰느냐"가 아니라 "지금 상황에서 어떤 도구를 어떤 순서로 쓸지 판단하는 감각"이거든요.
reverse-skill이라는 프로젝트는 바로 이 빈틈을 겨냥해요. AI에게 새로운 도구를 하나 더 붙여주는 게 아니라, 이미 존재하는 수십 개 도구 사이에서 길을 찾아주는 '내비게이션'을 만들어준 거예요. 저장소 설명에 있는 문장이 핵심을 잘 요약해요. "명령어를 추측하는 대신, 반복 가능한 워크플로를 실행한다."
핵심 발상: 도구를 늘리지 말고, '목차'를 만들어라
스킬이 뭐냐면
먼저 용어 하나만 정리하고 갈게요. 요즘 AI 에이전트 생태계에서 말하는 스킬(Skill)은 거창한 게 아니에요. 그냥 마크다운으로 쓴 작업 설명서예요. "안드로이드 앱을 분석할 때는 이런 순서로, 이런 도구를 쓰고, 이런 함정을 조심해라" 같은 내용을 문서로 적어둔 거죠.
그런데 여기서 재밌는 게, 왜 굳이 문서로 쪼개놓느냐는 거예요. 이유는 컨텍스트 창(AI가 한 번에 기억할 수 있는 정보의 양) 때문이에요. AI의 작업 기억을 책상이라고 생각해보세요. 책상은 넓지 않은데 참고 서적을 100권 다 펼쳐놓으면 정작 중요한 페이지를 못 봐요. 그래서 "목차만 항상 올려두고, 필요한 책만 그때그때 꺼내 보는" 방식을 쓰는 거예요. 이걸 점진적 공개(progressive disclosure)라고 부르는데, 어려운 말 같지만 결국 "필요할 때만 읽어라"예요.
파이프라인을 따라가 봅시다
이 프로젝트가 공개한 처리 흐름은 대략 이래요.
1. 사용자 요청 — "이 바이너리 뭐하는 놈인지 봐줘"
2. RULES.md — 전체 원칙을 먼저 읽어요. 헌법 같은 역할이에요.
3. MASTER-ROUTING.md / master-route.ps1 — 1차 분기점. "APK냐, ELF 실행파일이냐, 프론트엔드 JS 암호화냐, PCAP 패킷 덤프냐, CTF 문제냐"를 판단해요.
4. case-init / scope.md — 여기가 제일 중요해요. 권한과 네트워크 범위를 확인하는 단계인데, 원문에 명시적으로 no target ACT until ready(준비되기 전에는 대상에 손대지 않는다)라고 못 박아뒀어요.
5. 시나리오별 스킬 — 판단이 끝나면 해당 상황 전용 문서로 넘어가요.
6. 도구 / MCP / 스크립트 실행
7. 타임라인 + Evidence→Finding→Path 기록
8. 리포트 + field-journal(작업 일지)
4번 단계가 왜 인상적인가
솔직히 저는 4번이 이 프로젝트에서 가장 잘 만든 부분이라고 봐요. 보안 작업에서 사고가 나는 지점은 기술이 부족해서가 아니라 "어디까지 건드려도 되는지 합의가 없는 상태에서 손을 대서"인 경우가 훨씬 많거든요.
건물 공사에 비유하면 이래요. 벽을 부수는 기술은 누구나 배울 수 있어요. 그런데 프로가 되는 건 망치를 들기 전에 도면과 허가증을 확인하는 습관이 있느냐예요. scope.md라는 파일 하나로 "점검 대상, 허용 범위, 네트워크 프로필"을 강제로 문서화하게 만든 건, AI에게 이 습관을 절차로 심어놓은 거예요. AI는 사람과 달리 "어? 이건 좀 아닌 것 같은데" 하는 직감이 없으니까, 이런 게이트를 코드 흐름 자체에 박아두는 게 훨씬 안전하죠.
Evidence → Finding → Path, 환각을 막는 3단 구조
결과 기록 방식도 눈여겨볼 만해요. 증거(Evidence) → 발견(Finding) → 경로(Path) 순서로 적게 되어 있어요.
- Evidence: 실제로 화면에 찍힌 출력, 파일 내용, 응답 값
- Finding: 그 증거로부터 내린 결론
- Path: 그 결론에 도달한 재현 가능한 경로
- 문서 기반이라 강제력이 약해요. AI가 지시를 건너뛰면 안전 게이트도 함께 무너져요. 모델 성능에 결과가 크게 좌우돼요.
- PowerShell 스크립트(
master-route.ps1) 중심 흐름이 보이는데, macOS나 리눅스 사용자에게는 경로가 다를 수 있어요. - 스킬이 많아지면 라우팅 정확도가 떨어져요. 선택지가 늘수록 잘못된 분기로 갈 확률도 늘어나거든요.
- 최종 검증은 결국 사람 몫이에요. 오탐(false positive, 실제로는 문제가 없는데 있다고 보고하는 것)을 걸러내는 건 자동화가 가장 어려운 영역이에요.
- 0~1개월: HTTP와 네트워크 기초부터. Burp Suite Community 버전으로 내 로컬 앱 트래픽을 들여다보세요. 연습은 반드시 DVWA, WebGoat처럼 일부러 취약하게 만든 학습용 앱에서 하세요.
- 1~3개월: CTF 도전. 국내 워게임 사이트나 Hack The Box처럼 합법적으로 마련된 환경에서 감을 익히세요. 리버싱은 무료인 Ghidra로 시작하면 충분해요.
- 3개월 이후: 우리 서비스에 접목. 위협 모델링(우리 서비스를 노리는 사람은 어디를 먼저 볼까 상상해보기)을 하고, 발견한 것을 증거-발견-경로 형식으로 문서화하는 습관을 들이세요.
- 여러분 팀은 AI 에이전트에게 어디까지 권한을 주고 계세요? 읽기만? 아니면 명령 실행까지?
- 팀의 반복 작업을 문서화해서 AI에게 물려준 경험이 있나요? 효과가 있었나요?
- 자동화된 점검 결과를 얼마나 신뢰하시나요? 오탐을 걸러내는 나름의 기준이 있으신가요?
이게 왜 필요할까요? AI는 그럴듯하게 말하는 데 최적화된 모델이에요. 그래서 "SQL 인젝션 취약점이 발견되었습니다" 같은 문장을 증거 없이도 아주 자연스럽게 써낼 수 있어요. 이걸 그대로 보고서에 올렸다가 실제로는 없는 취약점이면? 팀 신뢰도가 한 번에 날아가요. 기자가 기사 쓸 때 "누가, 언제, 어디서 그렇게 말했는지" 출처를 붙이는 것과 똑같은 장치라고 보면 돼요.
온디맨드 부트스트래핑: 필요할 때 도구를 스스로 챙긴다
부트스트래핑이라는 말이 좀 낯설 수 있는데, 원래 "자기 신발끈을 당겨서 스스로 일어난다"는 뜻이에요. 여기서는 작업에 필요한 도구 환경을 에이전트가 알아서 점검하고 갖춘다는 의미로 쓰였어요.
전제 조건은 단순해요. Java/JDK(jadx와 apktool용), Node.js 22.12 이상(JS 도구와 MCP 서버용), Python 3.x(Frida와 보조 스크립트용), 그리고 AI 코딩 클라이언트 하나. 이 정도만 있으면 나머지는 필요할 때 확인하고 채우는 구조예요.
이게 실무에서 왜 반가운지 아세요? 보안 도구 환경은 정말 지저분해요. IDA Pro는 팀장님 노트북에만 있고, Burp Suite는 사내 점검용 VM에 있고, Ghidra는 내 맥북에 깔아뒀는데 버전이 달라서 안 되고… 이런 상황이 일상이거든요. 저장소에 kali(칼리 리눅스 환경용 안내), burp-mcp-full(웹 프록시 도구 Burp를 AI가 조작할 수 있게 연결), CTF-Sandbox-Orchestrator(CTF 문제 풀이용 격리 환경 관리) 같은 디렉터리가 따로 있는 것도 "환경 편차"라는 현실 문제를 인정한 설계로 보여요.
참고로 여기 나오는 MCP(Model Context Protocol)는, 쉽게 말해 AI가 외부 프로그램과 대화할 때 쓰는 표준 규격이에요. USB-C 같은 거죠. 예전에는 도구마다 연결선이 다 달랐는데, 이제 규격이 통일되니까 "Burp를 AI에 꽂는다"는 게 실제로 가능해진 거예요.
자기 진화 경험고: LLM의 치명적 약점 보완하기
세 번째 축은 자동 진화하는 경험 저장소예요. reports/와 field-journal이 그 역할을 해요.
LLM 기반 에이전트의 가장 아픈 약점이 뭘까요? 세션이 끝나면 다 잊는다는 거예요. 어제 세 시간 삽질해서 "이 앱은 루팅 탐지가 있어서 Frida를 바로 붙이면 튕긴다"는 걸 알아냈어도, 오늘 새 대화창에서는 똑같이 튕기고 똑같이 당황해요. 원문의 문제 정의에도 정확히 이 표현이 있어요. "경험이 재사용되지 않아서 같은 실수가 반복된다."
자동차 정비소를 생각해보세요. 좋은 정비소는 차량별 작업 일지를 남겨요. "이 모델은 이 볼트가 잘 부러지니 토크 조심" 같은 메모가 쌓이면, 신입 정비사도 베테랑의 시간을 물려받을 수 있죠. 작업 일지를 파일로 남기고 다음 세션에서 읽히게 만든 건 이 문제에 대한 아주 현실적인 해법이에요. 화려하진 않지만, 화려한 것보다 잘 굴러가요.
비슷해 보이는 것들과 무엇이 다를까
단일 MCP 서버만 붙이는 방식
Burp MCP 하나만 연결해두는 것과 비교하면, 그건 도구 하나에 리모컨을 달아준 것에 가까워요. 리모컨은 편하지만 "지금 TV를 켤 상황인가, 에어컨을 켤 상황인가"는 여전히 사람이 판단해야 하죠. reverse-skill은 리모컨이 아니라 어떤 리모컨을 집을지 알려주는 안내서를 만든 거예요. 층위가 달라요.
프롬프트 모음집 / awesome 리스트
"보안 관련 프롬프트 100선" 같은 저장소도 많아요. 이건 레시피 책이에요. 레시피는 훌륭한데, 냉장고를 열어보고 "오늘 뭘 만들지" 정하는 건 안 도와줘요. 라우팅 문서는 바로 그 "뭘 만들지" 단계를 담당해요.
자동 스캐너 (Nuclei, ZAP 같은 도구)
스캐너는 정해진 체크리스트를 아주 빠르게 훑어요. 건강검진 기본 패널 같은 거죠. 놓치기 쉬운 것들을 싸고 빠르게 걸러줘요. 반면 스킬 라우터 방식은 전문의 진료에 가까워요. 증상을 보고 어떤 검사를 추가할지 판단하는 흐름이니까요. 둘은 경쟁 관계가 아니라 보완 관계예요. 실무에서는 스캐너로 넓게 훑고, 의심 지점을 라우터 흐름으로 깊게 파는 조합이 자연스러워요.
범용 에이전트 프레임워크
LangGraph 같은 걸로 직접 워크플로를 짜는 방법도 있어요. 자유도는 최고인데, 도메인 지식을 내가 다 채워 넣어야 해요. 이 프로젝트의 진짜 자산은 코드가 아니라 문서에 녹아 있는 판단 기준이에요. 그게 얇은 마크다운 레이어라는 점이 오히려 강점이에요. 우리 팀 상황에 맞게 그냥 텍스트를 고쳐 쓰면 되니까요.
한계도 솔직하게
칭찬만 하면 재미없으니 약점도 짚을게요.
한국 개발자에게 주는 시사점
1) 기술보다 법이 먼저예요
이건 정말 중요해서 먼저 말할게요. 한국에서는 정보통신망법상 정당한 접근 권한 없이 남의 정보통신망에 침입하는 행위는 형사처벌 대상이에요. "취약점을 찾아 알려주려 했다"는 선의도 면책 사유가 되지 않아요. 심지어 내 서비스라도 클라우드나 호스팅 업체 약관에서 부하 테스트·스캔을 제한하는 경우가 있어서, 사전 확인이 필요해요.
그래서 scope.md 게이트는 단순히 기술 편의 기능이 아니에요. 실무에서 꼭 남겨야 하는 것들, 즉 점검 대상 범위, 허용 기간, 승인자, 비상 연락처를 문서로 남기게 강제하는 장치로 쓸 수 있어요. AI 도구를 쓰든 안 쓰든, 이 습관 하나는 그대로 가져가시면 좋겠어요.
2) 공격보다 방어에서 더 쓸모 있어요
많은 분들이 "난 보안 담당이 아닌데" 하실 텐데, 오히려 서비스 개발자에게 유용한 시나리오가 있어요.
예를 들어 우리 회사 안드로이드 앱이 있다고 해봐요. 정식 승인을 받고, 우리가 배포한 우리 APK를 대상으로 이런 걸 확인할 수 있어요. 난독화가 실제로 걸려 있는지, 빌드 산출물에 서버 주소나 키가 그대로 박혀 있지 않은지, 디버그 플래그가 꺼져 있는지. 이건 남을 공격하는 게 아니라 우리 결과물을 공격자 시점에서 검토하는 일이에요. 릴리스 체크리스트에 넣기 딱 좋죠.
3) 라우터 패턴 자체를 훔쳐오세요
보안에 관심 없는 분에게 제가 가장 권하고 싶은 건 이거예요. 이 프로젝트의 아키텍처는 보안과 무관하게 그대로 응용할 수 있어요.
장애 대응을 예로 들면 이렇게 되겠죠. 장애 신고 접수 → 라우팅 문서에서 어떤 시스템 문제인지 분기 → 서비스별 런북 열기 → 확인 명령 실행 → 타임라인 기록 → 포스트모템 작성. 지금 팀 위키에 흩어져 있는 문서들에 "어떤 상황에 어떤 문서를 읽어라"는 목차 한 장만 얹으면 골격이 나와요. 30분이면 초안 만들 수 있고, AI 에이전트에게 물려주는 순간 효과가 눈에 보여요. 신입 온보딩, 배포 절차, 데이터 마이그레이션 전부 같은 구조가 통해요.
학습 로드맵 제안
마무리: 스킬이 새로운 패키지가 되는 시대
저는 이 프로젝트를 보안 도구로만 보지 않아요. "판단과 절차"를 패키지로 배포하는 시대의 초기 사례로 보여요. npm이 코드 재사용 방식을 바꿨듯이, 앞으로는 스킬 저장소가 노하우 재사용 방식을 바꿀 수도 있어요.
다만 여기엔 새로운 위험도 따라와요. 스킬 문서는 결국 내 터미널에서 명령을 실행하도록 AI를 유도하는 텍스트예요. 남이 만든 마크다운을 그대로 물려주는 건 생각보다 큰 신뢰를 주는 행동이에요. 앞으로는 "이 스킬 팩의 출처가 어디고, 안에 어떤 명령이 들어 있는지" 검토하는 문화가 필요해질 거예요. 코드 리뷰하듯 스킬 리뷰를 하게 되는 날이 곧 오겠죠.
마지막으로 질문 몇 개 던지고 싶어요.
🔗 출처: GitHub