이 글은 지난 18년 동안 취약점을 찾으려고 몸으로 부딪히며 배운 경험을 바탕으로 쓴 개인적인 기록이다.
그래서 다른 사람의 경험과는 다를 수 있다.
어떤 부분은 불편할 수도 있다.
하지만 누가 맞고 틀리다는 이야기를 하려는 것은 아니다.
그저 “이런 식으로 생각하는 사람도 있구나” 정도로 읽어주면 좋겠다.
이전 글에서는 한국 보안이 왜 구조적으로 답답해지는지, 그리고 보안 진단이 왜 보고서로 끝나는 순간 죽어버리는지에 대해 썼다.
이번에는 그 다음 이야기를 해보려 한다.
취약점을 잘 찾는 사람은 어떤 사람인가.
그 감각은 왜 구조로 바뀌었는가.
그리고 AI는 그 구조 안에서 무엇이 되고 있는가.
1. 처음에는 다 감각이었다
처음에는 아무것도 없었다.
지금처럼 진단 항목도 없었고, 프로세스도 없었고, “동적 진단"이라는 말도 없었다.
동적 진단이란 실제 시스템에 입력을 넣고 반응을 보며 취약점을 찾는 방식인데, 지금은 하나의 업계 용어가 됐지만 그때는 그냥 “취약점을 찾는다"고 했다.
더 정확히 말하면 이상한 걸 계속 넣어보는 일에 가까웠다.
코드를 보는 경우도 많지 않았다.
대신 입력을 넣고, 반응을 보고, 머릿속에서 내부 동작을 계속 시뮬레이션했다.
이 시스템이 어떤 언어로 만들어졌을지, 어디에서 문자열이 끊길지, 어디서 필터링이 빠질지. 그걸 계속 상상하면서 테스트를 했다.
내가 아직도 기억하는 취약점이 하나 있다.
톰캣 파일 업로드 라이브러리에서, 파일명에 널 바이트를 넣으면 확장자 우회가 되는 문제였다.
지금 기준으로 보면 별것 아닌 이야기처럼 들릴 수 있다.
하지만 당시에는 “라이브러리 취약점"이라는 개념도 지금처럼 자연스럽지 않았다.
나는 그냥 C 언어에서 문자열이 널 바이트로 끝난다는 걸 알고 있었고, 그걸 웹 업로드 입력에 넣어봤을 뿐이다.
누가 가르쳐준 것도, 어떤 가이드라인에 있던 것도 아니었다.
그냥 지식과 감각이 연결된 결과였다.
초기의 취약점 탐지는 대부분 그런 식이었다.
2. 감각은 가이드라인이 되었고, 가이드라인은 복붙이 되었다
시간이 지나면서 그 감각은 정리되기 시작했다.
체크리스트가 생기고, 진단 가이드가 생기고, 자주 쓰는 페이로드 패턴이 문서화됐다.
여기까지는 자연스러운 진화다.
문제는 그 다음이다.
가이드라인은 원래 감각을 전달하기 위한 것이었는데, 어느 순간부터 감각을 대체하기 시작했다.
예를 들어 이런 식이다.
입력창이 있으면 정해진 페이로드를 복사해서 넣는다.
반응이 없으면 “취약점 없음"으로 넘어간다.
그 과정에서 아무도 묻지 않는다.
이 입력이 왜 위험할 수 있는지, 이 시스템이 내부에서 어떤 처리를 하고 있는지, 응답이 없다는 게 정말 안전하다는 의미인지.
이 질문들이 사라졌다.
그때부터 “해킹"이라고 부르기 민망한 작업들이 “동적 진단"이라는 이름으로 불리기 시작했다.
그 표현 자체가 나쁜 건 아니다.
다만 현실에서는 너무 자주 생각 없는 반복 작업을 그럴듯한 이름으로 포장한 것에 가까웠다.
3. 구조가 없을 때, 품질은 사람에게 의존한다
그 시기의 진단 조직은 구조가 없었다.
각자 했다.
잘하는 사람은 정말 잘했고, 아닌 사람은 놀랄 만큼 허술했다.
술 마시고 와서 대충 하는 사람도 있었고, 보고서만 적당히 쓰는 사람도 있었고, 퇴사 직전에 형식만 채우는 사람도 있었다.
개인을 탓하려는 이야기가 아니다.
구조가 없으면 품질은 결국 개인에게 의존한다.
그리고 그런 시스템은 반드시 무너진다.
문제를 해결하려고 사람을 늘렸다.
처음에는 좋아 보였다. 진단 속도가 빨라지는 것처럼 보였다.
하지만 곧 다른 문제가 생겼다. 리뷰였다.
열 명이 들어오면 열 명의 결과가 나온다. 그걸 누군가는 다 봐야 한다.
기준은 사람마다 다르고, 리뷰는 계속 반복되고, 수정은 끝나지 않는다.
어느 순간부터는 진단보다 검토가 더 힘들어진다.
이 시점에서 조직은 깨닫는다.
문제는 사람이 아니라 구조라는 것을.
4. 예산이 줄어들자, 구조를 바꿔야 했다
결정적인 계기는 예산이었다.
보안 진단 예산은 생각보다 쉽게 삭감되는 항목이었다.
예산이 줄어들면서 기존 방식은 유지할 수 없게 됐다.
사람을 계속 늘릴 수도 없었고, 리뷰 병목도 해결되지 않았다.
그래서 방향을 바꿨다.
먼저 항목을 잘라냈다.
어떤 항목은 “이건 찾아도 어차피 안 고친다"는 이유로 빠졌다.
어떤 항목은 “이걸 제대로 보려면 사람이 너무 많이 필요하다"는 이유로 빠졌다.
명분은 있었지만 솔직히 말하면 예산이 안 됐다.
그렇게 남은 것만 했다.
그리고 “누가 하느냐"에서 “어떻게 하느냐"로 기준 자체를 옮겼다.
개인의 실력으로 버티는 게 아니라 공정으로 품질을 유지하는 방향이었다.
깔끔한 결정이 아니었다. 포기가 먼저였다.
5. 진단에도 컨베이어벨트가 들어왔다
그다음 선택은 분업이었다.
파일 업로드, 인증, 권한, 명령 실행, 데이터 노출 같은 식으로 진단 영역을 나눴다.
한 사람이 전체를 보는 대신, 각자 자기 영역만 깊게 보게 했다.
한 사이트가 들어오면 컨베이어벨트를 타고 지나가듯 각 영역을 순서대로 통과하는 구조였다.
이 방식은 효과가 있었다.
전체 실력이 고르게 높지 않아도 됐다. 각자 한 영역만 잘하면 됐다.
리뷰 기준도 단순해졌다. 조직은 개인의 천재성에 덜 의존하게 됐다.
하지만 이 방식은 사람을 불편하게 만든다.
보안 진단을 하는 사람들은 생각보다 자존심이 강하다.
자기 머리로 시스템 전체를 읽어내고 싶어한다.
그런 사람들에게 이 구조는 자신이 기계의 한 부품이 된 것처럼 느껴진다.
그래서 떠나는 사람도 있었다.
그 감정은 틀리지 않았다. 나라도 싫었을 것이다.
그럼에도 구조는 남았고, 조직은 더 안정됐다.
그때 나는 포드가 왜 대단한지 처음으로 이해했다.
포드는 사람을 대체하려고 컨베이어벨트를 만든 게 아니다.
사람의 편차를 산업이 감당할 수 있는 형태로 바꾸기 위해 구조를 만든 것이다.
보안 진단에서도 그 논리는 그대로 적용됐다.
6. 취약점을 잘 찾는 사람과, 구조를 만드는 사람
여기서 중요한 분리가 하나 생긴다.
취약점을 잘 찾는 사람은 머릿속에 시뮬레이터가 있다.
파일명 하나를 보면 서버 내부가 그것을 어떻게 처리할지 상상한다.
응답 코드 하나에서 뒤에 있는 로직의 성격을 읽는다.
앞서 말한 톰캣 예시가 그런 방식이다. 아무도 가르쳐주지 않았지만, 시스템의 동작 방식을 머릿속에서 그릴 수 있었기 때문에 가능했다.
구조를 만드는 사람은 다른 걸 본다.
누가 무엇을 잘하는지, 어디서 병목이 생기는지, 어떻게 일관성을 유지할지를 설계한다.
이 사람은 꼭 최고의 해커일 필요가 없다.
대신 사람과 흐름과 기준을 동시에 볼 수 있어야 한다.
둘은 완전히 다른 능력이다.
그리고 조직에서는 자주 혼동된다.
뛰어난 해커가 팀장이 되면 잘 될 것 같지만, 실제로는 그렇지 않은 경우가 훨씬 많다.
반대로 감각은 평범하지만 구조를 잘 만드는 사람이 팀을 놀랍도록 안정적으로 운영하는 경우도 있다.
7. AI는 구조 안에서 가장 잘 동작한다
AI는 감정이 없다. 그리고 역할을 제한할수록 더 잘 동작한다.
이건 컨베이어벨트 방식과 거의 완벽하게 맞는다.
그래서 나는 실제로 실험을 해봤다.
Codex Agent SDK를 기반으로 진단 역할을 에이전트화하고, 영역별로 분리해서 태스크를 흘려보냈다.
파일 업로드, 인증·인가, 템플릿 인젝션, 예외 흐름 분석처럼 도메인을 나누고, 각 에이전트에게 그 영역에 필요한 지식과 절차만 넣었다.
결과는 예상보다 훨씬 좋았다.
취약점이 정말 많이 나왔다.
문제는 오히려 반대였다.
오탐이 있었고, 맥락이 끊기는 경우도 있었고, 같은 문제를 다른 이름으로 중복 보고하기도 했다.
결과를 후처리해야 했고, 맥락을 다시 붙여야 했다.
그럼에도 불구하고, 사람 진단자들과 기준을 맞추고 보고서 표현으로 끝없이 부딪히던 경험에 비하면 훨씬 단순한 문제였다.
AI는 자존심이 없다. 기준을 바꿔도 화내지 않는다. 새벽에 돌려도 컨디션이 없다.
사람과 일할 때 진짜 어려운 건 취약점이 아니라 사람이었다.
그 문제가 사라졌다.
8. 이제 문제는 ‘못 찾는 것’이 아니다
지금은 상황이 완전히 바뀌었다.
“어떻게 더 찾을까"는 이미 어느 정도 해결됐다.
AI를 통해 진단을 돌리면 결과는 계속 쌓인다.
개발자가 감당하기 어려울 정도로.
그런데 그 결과는 그대로 쓸 수 없다.
어떤 건 정확하고, 어떤 건 위험을 과장하고, 어떤 건 같은 현상을 다른 이름으로 중복 보고한다.
탐지 자체는 일정 수준을 넘어섰다.
이제 남은 문제는 해석과 정렬이다.
어떤 결과가 실제로 위험한지, 어떤 순서로 처리해야 하는지, 개발자가 이해할 수 있는 형태로 어떻게 바꿀지.
이게 지금의 진짜 병목이다.
그래서 질문이 바뀐다.
어떻게 더 많이 찾을까가 아니라, 이걸 어떻게 이해시키고 처리하게 만들 것인가.
9. 앞으로 필요한 사람
이 질문에 답할 수 있는 사람이 앞으로 중요해진다.
취약점을 잘 찾는 사람은 여전히 필요하다.
하지만 그것만으로는 부족하다.
앞으로 더 귀해질 사람은 탐지 결과를 해석할 수 있는 사람이다.
도메인별 진단 기준을 설계하고, 오탐과 중복을 줄이는 지식 베이스를 만들고, 그 결과를 개발자와 운영자가 실제로 처리할 수 있는 형태로 바꾸는 사람.
한마디로, 감각을 구조로 바꾸는 사람이다.
그 감각이 높을수록 좋다.
하지만 감각만 높아서는 안 된다.
10. 결론
나는 요즘 이걸 계속 생각한다.
어떻게 하면 AI가 더 많이 찾게 할까가 아니라
어떻게 하면 AI가 찾은 것을 조직이 이해하고 처리할 수 있게 만들 것인가.
이게 지금의 문제다.
참고 글
이 글은 아래 글들과 이어진다.