BoB 뉴스레터 2026년 7월 호

안녕하세요, 구독자 님!

뉴스레터를 구독하신 분들께 매번 감사드립니다.

🍎 BoB 뉴스레터 07월호 스토리

📢 07월 BoB 수료생&멘토 소식

🍧 동문들의 소식들을 기다립니다

뉴스레터가 여러분의 소식을 함께 전달해드립니다. 🎉

🏠 7년 된 DBMS 버그 발견부터 두 번의 탈락, ESORICS 게재까지

2차 발표를 앞둔 어느 날, QueryHouse 팀은 실행 로그에서 나와서는 안 되는 값을 발견했다. 같은 쿼리를 여러 DBMS에서 실행해 결과를 비교하는 도구, QueryHouse가 잡아낸 불일치였다. BoB 13기에 결성된 '쿼리전문점' 팀이 개발한 이 도구는 수많은 불일치를 쏟아냈고 대부분 오탐으로 끝났다. 그래서 이번에도 처음부터 버그라고 확신할 수는 없었다. 그러나 SQL 표준과 각 DBMS의 문서를 대조한 끝에, 팀은 SQLite에 약 5년간 남아 있던 로직 버그를 확인했다.

이후 MySQL에서는 약 7년 된 버그를 발견했고, Oracle에서 찾은 버그도 공식 확인을 받았다. 최종적으로 QueryHouse는 11개의 DBMS 로직 버그와 7개의 동작 불일치를 찾아냈다.

BoB 13기 프로젝트로 시작된 연구는 두 차례의 논문 탈락을 거쳐 ESORICS 2026 게재로 이어졌다. 시작 당시에는 멘토에게 “4개월 안에 가능한 프로젝트냐”는 질문을 받았던 팀이었다.

QueryHouse를 개발한 ‘쿼리전문점’ 팀의 논문이 세계적 보안 학술대회 ESORICS 2026에 채택되는 쾌거를 이뤘다. ESORICS는 컴퓨터 보안 분야의 주요 국제 학술대회로, 올해 행사는 9월 14일부터 18일까지 이탈리아 로마 사피엔차대학교에서 개최된다.

뉴스레터팀은 쿼리전문점 팀에게 첫 버그를 발견한 순간부터 구현 과정, 논문 투고와 팀의 이야기까지 물었다.

▲ QueryHouse 논문 첫 페이지. 연구팀은 LLM을 활용한 DBMS 차등 테스팅 기법을 제안했다.

“4개월 안에 할 수 있겠어요? 저는 못 할 것 같은데요”

Q. 멘토님은 처음부터 프로젝트의 성공 가능성을 높게 보셨나요?

가세혁 팀원: 킥오프 당시 멘토님이 “이걸 4개월 안에 할 수 있겠어요? 나는 못 할 것 같은데, 주제를 바꾸는 게 어떻겠어요?”라고 말씀하셨습니다. 저희는 “일단 해보겠습니다. 하다가 안 되면 말씀드리겠습니다”라고 답했습니다. 결국 처음 계획했던 목표를 달성했고, 예상보다 더 많은 결과까지 만들었습니다.

송주현 PL: 프로젝트가 순탄했다고 표현하기는 어렵습니다. 하지만 처음 계획했던 목표를 완수했고, 결과적으로는 초과 달성했다고 생각합니다. 그 배경에는 팀워크와 실행력이 있었습니다. 멘토링에서 새로운 지적이나 아이디어가 나오면 오랫동안 걱정하기보다 “아 그래? 그럼 오늘 구현하지 뭐”라고 바로 움직이는 팀이었습니다.

Q. 이 팀은 어떻게 꾸려졌나요?

PM 오서연님이 먼저 주제를 정한 뒤 팀원을 점차 모아 나갔습니다. PM님이 각자의 장점을 살려 역할을 명확하게 나눴고, 팀원들은 맡은 파트를 중심으로 프로젝트를 진행했습니다.

▲’쿼리전문점’ 팀의 활동 사진, (상)발표자료 발췌 (하)chatGPT 생성

"누가 봐도 이 값은 나오면 안 됐어요" — 발견부터 구현까지

Q. 첫 번째 버그를 발견한 순간을 기억하시나요?

박재민 팀원: 2차 발표를 앞두고 결과 로그를 보고 있었어요. QueryHouse는 여러 DBMS의 결과가 다른 사례를 계속 보여주는데, 대부분은 실제 버그가 아닌 오탐이었습니다. 그런데 그중 하나는 생김새부터 이상했어요. 누가 봐도 이 값이 나오면 안 된다고 생각해서 바로 전달했습니다.

송주현 PL: 여러 DBMS의 결과가 다르다고 해서 곧바로 버그라고 판단할 수는 없습니다. 실제 로직 버그일 수도 있지만, 특정 DBMS가 문서에 명시하지 않은 방식으로 기능을 구현했을 수도 있고, 문서 어딘가에 예외가 적혀 있을 수도 있어요.

Q. 그전에도 버그를 찾았다고 생각한 적이 있었다고요.

한 번은 “이번에는 진짜다”라고 생각해 다 같이 좋아했던 적이 있어요. 새우깡에 소주까지 꺼내면서 “이제 고생이 끝났다”는 분위기였는데, 다시 확인해보니 실제 버그가 아니었던 것으로 기억합니다. 😂 결과가 다르다는 이유만으로 모두 버그가 되는 것은 아니어서, 기뻐했다가 다시 원점으로 돌아간 경우가 있았습니다.

박재민 팀원 : SQLite FILTER 버그가 2차 발표 직전에 나왔어요. 발표에서 보여줄 명확한 성과가 필요했던 시기라 타이밍이 정말 절묘했습니다.

다만 이전에도 버그인 줄 알고 좋아했다가 오탐으로 확인된 경험이 있었기 때문에, 처음부터 마음 놓고 축하하지는 못했어요. SQL 표준과 문서를 끝까지 확인한 뒤에야 “이건 정말 버그가 맞다”고 확신할 수 있었습니다.

Q. 일반적인 소프트웨어 버그는 왜 못 찾았을까요?

DBMS 로직 버그가 가장 위험한 이유는 크래시나 오류 메시지처럼 명백한 증상이 없다는 점입니다. 시스템은 정상적으로 동작하는 것처럼 보이지만, 조용히 잘못된 값을 반환하죠.

저희가 발견한 사례 중에는 특정 실수 값을 SELECT 했을 때 값이 약 두 배로 반환되는 버그도 있었습니다. 겉으로는 쿼리가 정상적으로 실행된 것처럼 보이니까 개발자가 문제를 바로 알아차리기 어려워요.

예를 들어 DB를 마이그레이션한 뒤 이런 문제가 발생하면, 반환된 값을 이용하는 계산이나 비즈니스 로직까지 잘못 동작할 수 있습니다. 결국 해당 데이터에 의존하는 전체 연산 과정의 무결성이 깨지는 것이죠.

Q. 기존에 있는 방법들은 왜 이런 버그를 찾기 어려웠나요?

메타모픽 테스팅은 하나의 DBMS에서 의미가 같은 여러 쿼리를 실행하고 결과가 일치하는지를 확인합니다.

그런데 특정 함수 자체가 잘못 구현돼 있다면 변형된 쿼리들도 모두 똑같은 오답을 반환할 수 있습니다. 정답이 계속 나오든 오답이 계속 나오든 결과가 서로 같으면 테스트를 통과하는 구조입니다.

QueryHouse는 쿼리를 하나의 DBMS 안에서만 변형하지 않고, 같은 의미의 쿼리를 여러 DBMS에서 실행합니다. 서로 다른 DBMS 중 하나만 다른 결과를 반환하는 지점을 찾아내는 차분 테스팅을 적용한 것입니다.

Q. 독자들이 이해하기 쉽게 비유해주실 수 있을까요?

계산기 한 대가 2×3을 항상 7이라고 답한다고 가정해볼 수 있습니다. 식의 모양을 여러 방식으로 바꾸더라도 같은 계산기 안에서는 계속 7이 나올 수 있어요. 결과가 서로 같기 때문에 오류를 발견하기 어렵습니다.

QueryHouse는 계산기 한 대에 여러 문제를 주는 대신, 여러 계산기에 같은 문제를 풀게 합니다. 그중 하나만 다른 답을 내놓으면, 그 지점을 버그 후보로 확인하는 방식입니다.

Q. QueryHouse를 구현하면서 가장 어려웠던 부분은 무엇이었나요?

여러 DBMS에서 같은 의미의 쿼리를 실행하려면 단순히 문법만 바꿔서는 안 됩니다. 데이터 타입과 함수의 동작, DBMS별 세부 규칙까지 맞춰야 합니다.

저희는 오픈소스 SQL 트랜스파일러인 SQLGlot을 활용했습니다. 널리 사용되는 도구라 기본적인 기능은 바로 쓸 수 있을 것으로 생각했는데, 조금만 세부 기능으로 들어가면 직접 구현하거나 수정해야 할 부분이 계속 나왔습니다.

SELECT나 INSERT 같은 기본 문법은 비교적 잘 지원했지만, FTS5 같은 특수 기능은 아예 구현되지 않은 경우도 있었습니다. DBMS마다 정수형 크기가 달라 실행 결과에 차이가 생기는 경우도 있었고요.

연구에 활용하려면 변환된 쿼리가 실행되는 것만으로는 부족합니다. 변환 전과 후의 의미가 정말 같아야 하기 때문에, 필요한 기능을 하나씩 직접 수정해야 했습니다.

Q. 수정한 트랜스파일러는 이후에도 활용할 수 있나요?

연구에서 사용한 트랜스파일러 버전과 관련 코드는 공개할 예정입니다. QueryHouse와 유사한 방식의 후속 연구가 나온다면, 저희가 수정한 기능을 다시 활용할 수 있다는 점도 연구의 기여 중 하나라고 생각합니다.

새로운 DBMS를 추가할 때도 전체 시스템을 다시 만들지 않고 비교적 적은 코드로 확장할 수 있도록 설계했습니다. 논문에서도 이 확장성을 중요한 강점으로 제시했습니다.

"처음 계획에는 없던 기능이었습니다" — 프로젝트의 변경점

Q. LLM 기반 쿼리 변조는 처음부터 계획한 기능이었나요?

처음부터 핵심 기능으로 계획한 것은 아니었습니다. 의미적으로 복잡한 쿼리를 만드는 결정론적 변조 시스템을 새로 개발하려면 많은 시간과 노력이 필요합니다. 반면 LLM은 이미 SQL 의미론을 상당 부분 학습하고 있기 때문에, 짧은 기간 안에 시도할 수 있는 저위험·고효율 방식이라고 판단했습니다. 시스템의 기본 구조를 먼저 완성한 뒤, 더 다양한 쿼리를 생성하기 위한 개선 방법으로 LLM을 추가했습니다.

다만 도입하자마자 좋은 쿼리가 나온 것은 아니었어요. 당시 LLM이 저희가 수행하는 차분 테스팅의 목적을 제대로 이해하지 못했거든요. 실험을 돌리고 결과를 확인한 뒤 프롬프트를 수정하고, 다시 실험하는 과정을 계속 반복했습니다. LLM이 만들어낸 결과를 그대로 신뢰하지 않고, 실제로 유효한 쿼리인지 검증하는 과정도 필요했습니다.

Q. LLM 도입 이후 가장 기억에 남는 변화는 무엇이었나요?

우선 멘토링 분위기가 달라졌습니다. 그전까지는 저희가 구현한 결과를 보여드리고 멘토님께 피드백을 받는 느낌이 강했어요.

그런데 LLM이 생성한 쿼리와 예상하지 못한 실행 결과가 나오기 시작하면서부터는 "왜 이런 결과가 나왔을까"를 멘토님들과 함께 이야기하게 됐습니다. 일방적으로 피드백을 받는다기보다 연구 결과를 같이 해석하고 함께 토론하는 분위기로 바뀐 점이 기억에 남습니다.

Q. 실행 성능을 6배, 13배까지 높인 최적화는 어떻게 이뤄졌나요?

Oracle은 데이터베이스를 한 번 초기화하는 데 거의 1초가 걸렸습니다. 쿼리 하나를 실행할 때마다 초기화하면 실제 테스트보다 초기화 작업에 더 많은 시간이 소요됐습니다. 이를 해결하기 위해 쿼리 20개를 하나의 묶음으로 실행했습니다. 해당 묶음 안에서 문제가 발견되면 묶음 전체를 기록하고, 20개의 실행이 끝난 뒤 한 번만 초기화하는 방식으로 변경했습니다.

Q. 코어를 많이 사용하면 처리량도 계속 증가하나요?

병렬 실행에서는 코어 수를 두 배로 늘린다고 해서 처리량이 정확히 두 배로 증가하지 않았습니다. 스토리지나 메모리 등 하드웨어 병목이 발생하면서 어느 시점부터는 성능이 정체되거나 오히려 떨어지는 구간이 있었습니다. 무작정 병렬 실행 규모를 늘리지 않도록 처리량 증가가 멈추는 임계치를 자동으로 측정하고, 해당 지점에서 확장을 중단하는 코드도 추가했습니다.

Q. 버그를 제보했을 때 DBMS 벤더들의 반응은 어땠나요?

DBMS마다 버그를 제보하고 처리하는 방식에 차이가 컸습니다. SQLite는 오픈소스 프로젝트여서 비교적 빠르게 확인됐습니다. 제보 후 하루나 이틀 정도 만에 반응이 왔던 것으로 기억합니다.

MariaDB 사례도 흥미로웠습니다. 저희가 구현과 문서의 차이를 제보했는데, 버그를 수정하기보다 "그렇다면 문서가 잘못된 것"이라는 판단으로 문서를 수정해 문제를 종결했습니다.

가장 어려웠던 곳은 클로즈드소스인 Oracle이었습니다. 공식 채널에 접근하는 것부터 쉽지 않았거든요.

Q. 그럼 Oracle 버그는 어떻게 확인받았나요?

Oracle은 유지보수 계약을 체결한 B2B 고객을 중심으로 공식 버그 제보 채널을 제공하고 있었습니다. 저희는 해당 채널에 접근할 수 없었기 때문에 개발자 커뮤니티 게시판에 재현 사례를 올렸습니다. 처음 올린 곳은 운영자가 자주 확인하지 않는 게시판이었어요. 게시글을 본 다른 사용자가 "여기에는 운영자가 잘 오지 않으니 다른 채널에 올려보라"고 알려줬습니다.

안내받은 곳으로 글을 옮긴 뒤 약 일주일 만에 Oracle 측의 확인을 받을 수 있었습니다. 저희 입장에서는 거의 "오라클, 보고 있다면 저희 제보를 제발 한 번만 봐주세요"라는 간절한 마음으로 글을 올렸던 것 같습니다.

Q. 버그 11개 외에 다른 발견도 있었나요?

송주현 PL: 프로젝트를 진행하면서 11개의 실제 로직 버그뿐 아니라, 공식 문서에 명시되지 않은 DBMS 간 동작 차이인 불일치도 7개 확인했습니다.

또 문서에는 적혀 있지만 다른 DBMS를 사용하던 개발자가 쉽게 혼동할 수 있는 동작은 pitfall로 분류했습니다.

특히 DB를 다른 제품으로 이전할 때 이런 차이가 충분히 문서화돼 있지 않으면, 개발자는 같은 의미로 쿼리를 작성했다고 생각했는데 실제 결과는 다르게 나올 수 있습니다. 엄밀한 의미의 버그가 아니더라도 실무에서는 로직 버그와 유사한 문제를 일으킬 수 있습니다.

“ESORICS로 향하는 여정”

Q. 실제 버그를 다수 발견했는데도 처음 두 차례의 투고에서는 왜 탈락했나요?

처음에는 소프트웨어 공학 분야 국제학회에 두 번 제출했습니다.

저희는 차분 테스팅을 여러 DBMS에 적용하고, 쿼리 트랜스파일링과 변조를 결합한 점이 새로운 기여라고 생각했습니다. 하지만 리뷰어들은 약 20년 전 다른 소프트웨어를 대상으로 유사한 방법이 사용됐다는 점을 들어 방법론의 참신성이 부족하다고 평가했습니다.

답변서를 통해 “DBMS에 이 방식을 적용한 연구는 차별성이 있다”고 설명했지만, 두 차례 모두 그 간극을 좁히지 못했습니다.

Q. 두 번 연속 같은 평가를 받았을 때 연구를 포기할 생각은 없었나요?

연구 결과 자체에는 분명한 가치가 있다고 생각했습니다. 방법론의 새로움만으로 평가하기보다, 실제 상용 DBMS에서 오랫동안 발견되지 않았던 버그를 찾아냈다는 실용적 성과도 중요한 기여라고 봤습니다.

그래서 연구가 틀렸다기보다, 연구의 강점을 더 잘 평가해줄 수 있는 학회를 찾아야 한다고 판단했습니다.

Q. ESORICS로 방향을 바꾼 이유는 무엇인가요?

소프트웨어 공학 분야에서는 방법론의 참신성을 강하게 평가했다면, 보안 분야에서는 실제 시스템에서 의미 있는 버그를 발견한 실용적 결과도 중요한 기여로 볼 수 있다고 판단했습니다.

두 번째 탈락 결과가 나왔을 때 ESORICS 마감까지 시간이 거의 남지 않은 상태였습니다. 팀은 곧바로 논문을 수정해 제출했습니다.

ESORICS는 심사 결과가 나온 뒤 저희가 추가로 반박하거나 답변할 수 있는 구조가 아니었습니다. 사실상 한 번의 심사로 게재 여부가 결정되는 상황이었는데, 결과적으로 세 명의 리뷰어 모두 게재에 동의했습니다.

두 번의 탈락 뒤에 받은 결과여서 더 극적인 반전으로 느껴졌습니다.

“하나를 부탁하면 두세 개를 해온다”

Q. 일을 잘하면 더 많은 일이 배정됐다는 이야기도 있었습니다.

송주현 PL: 광희님이 IR을 개선하는 작업을 담당했습니다. 프로그래밍 언어 이론을 깊게 이해해야 해서 학습과 개발 모두 높은 수준에서 이뤄져야 하는 어려운 작업이었어요. 어느 날 PM이 “광희 님은 하나를 부탁하면 두세 개를 해온다”며 정말 일을 잘한다고 칭찬했습니다. 그런데 그렇게 계속 초과 달성하는 것이 쉽지는 않을 것 같아서 제가 따로 괜찮은지 물어본 적이 있습니다.

이광희 팀원: 업무 자체가 너무 어렵다기보다, 하나를 끝내고 PM님께 전달하면 조금 쉬려고 했는데 바로 다음 일을 주셨어요. 제가 계속 “이제 뭘 하면 되나요?”라고 물어본 게 문제였던 것 같습니다. 의례적으로 물어본 건데 PM님은 정말 다음 일을 주셨어요.

Q. PM은 관리만 담당했나요?

“PM은 원래 코드를 짜면 안 된다. 그것이 진짜 PM이다”라고 멘토님께서 조언도 주셨습니다. 그런데 오서연 PM은 일정과 업무만 관리한 것이 아니라 코드도 작성하고, 연구의 기술적·이론적인 부분에도 함께 참여했습니다. 관리와 구현을 모두 맡았다는 점에서 팀원들의 신뢰가 컸습니다.

Q. 여러 학교에서 모인 팀이 큰 갈등 없이 협업할 수 있었던 이유는 무엇인가요?

가세혁 팀원: PM이 역할과 일정을 명확하게 나눠줬습니다. 각자 맡은 파트가 분명해서 서로의 작업을 건드릴 일이 거의 없었어요. 각자 맡은 결과물을 PM에게 전달하면 PM이 전체 내용을 취합하고, 다음 일정과 업무를 배분하는 방식으로 진행됐습니다. 서로 다른 배경을 가진 팀원들의 강점을 잘 보고 역할을 나눈 것이 컸다고 생각합니다.

Q. 팀 안에 PM이 있었다면, 팀 밖에서는 멘토님들이 있었을 텐데요. 멘토의 역할은 어땠나요?

송주현 PL: 저는 킥오프와 1·2·3차 발표 과정을 지켜봤는데, 멘토님들이 부족한 점만 지적한다기보다 팀의 방향을 지지해준다는 느낌을 많이 받았습니다.

킥오프 당시에는 다른 팀들이 연구 방향에 대한 날카로운 지적을 많이 받았다는 이야기를 들어서 저희도 같은 상황을 예상했습니다. 그런데 발표가 끝난 뒤 녹음을 들어보니, 박세준 멘토님께서 “아직 팀을 정하지 않은 교육생이 있다면 이 팀에 참여해보기를 권하고 싶다”는 취지로 말씀해주셨습니다.

그 이야기를 듣고 “이 연구 방향 자체에는 문제가 없구나. 이제 제대로 구현하면 되겠다”는 확신을 얻었습니다.

QueryHouse는 프로젝트 이후에도 이어졌다

Q. 프로젝트 결과가 논문 외의 활동으로도 이어졌나요?

QueryHouse로 발견한 DBMS의 특이 동작이나 pitfall을 활용해 DreamHack에 문제를 출제한 적도 있습니다.

연구 과정에서 확인한 결과를 논문에만 남기는 것이 아니라, 다른 사람들이 직접 문제를 풀며 DBMS의 동작 차이를 경험할 수 있도록 확장한 사례입니다.

▲ 쿼리전문점 팀이 출제한 Dreamhack CTF 문제. 출처: https://dreamhack.io/wargame/challenges/1739

“완벽하지 않아도 먼저 시작했으면 좋겠습니다”

Q. BoB 프로젝트를 준비하는 후배들에게 전하고 싶은 조언이 있나요?

오서연 PM: 처음에는 아이디어가 지금처럼 구체적이지 않았습니다. BoB에서 주제를 제안하고, 사람들이 모여 협업하면서 점차 구체화됐습니다. 아이디어나 작은 호기심을 혼자 가지고 있기보다 다른 사람과 공유하고, 실제로 실행해보는 것이 중요하다고 생각합니다.

이광희 팀원: 처음부터 거대한 프로젝트를 만들려고 하기보다 명확한 목표를 먼저 세우고, 그 문제를 해결하면서 조금씩 확장하는 방식이 좋다고 생각합니다. 연구 과정에서는 실패가 계속 발생하기 때문에 작은 단위로 결과를 확인하고, 그 결과를 바탕으로 다음 단계로 나아가는 것이 중요합니다.

김민지 팀원: 저희 팀의 주제는 다른 프로젝트와 비교해도 흔하지 않은 도전이었다고 생각합니다. BoB에는 뛰어난 역량을 가진 분들이 많은 만큼, 익숙하지 않은 주제라고 해서 너무 두려워하지 않았으면 좋겠습니다. 처음부터 모든 것을 완벽하게 준비하려 하면 오히려 시작하지 못할 수도 있습니다. 완벽하지 않더라도 먼저 시작해보고, 프로젝트를 진행하면서 방향을 구체화해나가는 것이 중요하다고 생각합니다.

박재민 팀원: BoB를 단순히 수료하거나 상을 받기 위한 과정으로만 생각하지 않았으면 좋겠습니다. 프로젝트에서 깊이 다룬 주제가 이후 커리어에도 영향을 줄 수 있습니다. 자신이 앞으로 무엇을 하고 싶은지를 생각하면서 BoB 활동과 프로젝트에 참여하면 좋겠습니다.

가세혁 팀원: 이번 프로젝트를 통해 퍼저를 처음 만들어봤습니다. 처음에는 내가 할 수 있을지 걱정되는 주제라도, 한 가지 문제에 집중해 처음부터 끝까지 해보면 실제 성과를 만들 수 있다는 것을 배웠습니다. 완벽하게 준비됐다고 느낄 때까지 기다리기보다, 일단 시작하고 기왕 시작했다면 끝까지 해보는 것이 중요하다고 생각합니다.

현민애 팀원: 프로젝트를 진행하며 가장 중요한 것 중 하나는 진행 상황과 막히는 부분에 대해 팀원들과 구체적으로 공유하는 자세인 것 같습니다. 초기 아이디어에서 프로젝트를 구체화하다 보면 방향성이 조금씩 바뀔 수도 있는데, 때 '너무 처음 주제에서 벗어나는 것이 아닐까?' 하고 너무 크게 고민하며 멈춰 서기보다는, 막히는 지점이 생겼을 때 멘토님이나 PL분께 조언을 구하며 차근차근 다음 단계로 나아가는 과정 그 자체가 중요한 것 같습니다. 너무 부담 갖지 말고, 팀원들과 적극적으로 소통하면서 한 단계씩 성실하게 나아가면 좋은 결과가 있을 것 같습니다!

송주현 PL: 좋은 프로젝트와 연구를 위해서는 내가 하려는 연구가 기존 연구와 무엇이 다른지, 그 차이를 어떻게 보여줄 것인지 먼저 설계해야 합니다. BoB 멘토링에서도 킥오프 단계부터 “선행 연구는 조사했는가”, “기존 연구와 무엇이 다른가”, “어떤 방식으로 기여를 증명할 것인가”를 계속 질문합니다. 그런 의미에서 BoB에는 좋은 연구를 만들기 위한 토양이 이미 마련돼 있다고 생각합니다. 산업계뿐 아니라 학계에서도 인정받을 수 있는 연구를 할 수 있다는 자신감을 가졌으면 좋겠습니다.

결론: AI가 줄인 것은 일자리가 아니라, 단순 반복에 머무를 여지다

AI가 보안 직무 전체를 없애고 있다는 근거는 아직 약하다. 국내 정보보호산업은 여전히 큰 규모를 유지하고 있고, 국내외 정부와 기관은 AI 보안관제와 AI 레드티밍, AI 프라이버시 리스크 관리에 투자를 이어가고 있다.

다만 AI가 보안 업무의 일부를 바꾸고 있다는 점은 분명하다. 1차 로그 확인과 이벤트 분류, 알림 triage, 보고서 초안 작성 같은 반복 업무는 AI가 빠르게 보조하기 시작했다. 이 변화는 특히 신입이 경험을 쌓던 방식을 흔든다. 그 위에는 새로운 일이 생긴다. AI가 만든 결과를 검증하고, 보안관제 룰을 고도화하고, LLM의 취약성을 점검하고, 프롬프트 인젝션을 막고, AI 에이전트의 권한을 통제하는 일이다.

신입이 준비해야 할 역량도 따라 달라진다. 많은 경보를 처리하는 능력보다 그 경보가 왜 위험한지 설명하는 능력이 중요하다. AI가 쓴 보고서를 다듬는 능력보다 그 보고서가 실제 로그와 맞는지 확인하는 능력이 중요하다. KISA 아카데미의 2026년 교육 목록에 AI 보안운영·위협탐지 실무인력 양성 같은 과정이 등장한 것도, 보안관제가 사라지는 직무가 아니라 AI를 전제로 다시 교육되는 직무가 되고 있다는 신호다.

보안의 중심은 자동화가 아니라 검증이다. AI가 더 빨라질수록, 사람에게 요구되는 것은 더 정확한 판단이다.

🎥 거부할 권리는 있는데, 거부는 되는가: AI 학습거부권(옵트아웃)의 실효성

▲ 출처: gpt 생성

잊힐 권리 대신 등장한 '거부할 권리'

지난 호에서 살펴본 것처럼, 이미 학습된 모델의 파라미터에서 특정 개인정보만 골라내 지우는 일은 여전히 기술적으로 어렵다. 그 현실적 대안으로 떠오른 것이 '학습거부권(opt-out)'이다. 삭제를 요청하는 대신, 애초에 내 데이터가 학습에 쓰이지 않도록 미리 막겠다는 발상이다. 이론은 간단하다. 그런데 실제로 옵트아웃 버튼을 눌러본 사람이라면 안다 — 그 버튼이 약속하는 것과 실제로 지켜지는 것 사이에는 상당한 간극이 있다.

기업마다 다른 그림: OpenAI와 Meta 비교

가장 먼저 눈에 띄는 것은 '기본값(default)'의 차이다. OpenAI의 경우 개인 이용자용 서비스인 ChatGPT는 이용자가 별도로 거부하지 않는 한 대화 내용이 모델 학습에 활용될 수 있다는 것이 기본 정책이다. 반면 기업용 서비스인 ChatGPT Team, Enterprise, API는 정반대로 조직이 명시적으로 동의하지 않는 한 기본적으로 학습에 데이터를 쓰지 않는다. 같은 회사 안에서도 개인 이용자와 기업 고객 사이에 정보 비대칭이 존재하는 셈이다.

옵트아웃을 켜더라도 한계는 있다. 설정을 변경하면 그 시점 이후의 새 대화부터만 학습 대상에서 빠지고, 이미 학습에 쓰인 과거 대화는 소급해서 제외되지 않는다. 저장된 대화 기록 자체가 삭제되는 것도 아니어서, 옵트아웃은 어디까지나 '앞으로의 사용'만 통제할 뿐 이미 지나간 일에는 손을 대지 못한다.

Meta의 경우는 더 복잡하다. 유럽 이용자를 대상으로 페이스북·인스타그램의 공개 게시물을 AI 학습에 활용하는 정책을 두고, Meta는 이를 GDPR상 '정당한 이익(legitimate interests)'을 법적 근거로 내세우며 옵트아웃 방식을 채택했다. 유럽 프라이버시 단체 noyb는 이 절차를 이용자에게 사유까지 적어 내게 하는 "불필요하게 복잡한 저지 장치"라고 비판했다. 18세 미만 이용자의 데이터는 학습에서 제외되고 비공개 메시지는 학습에 쓰이지 않는다는 것이 Meta의 설명이지만, 정작 미국 이용자에게는 이 옵트아웃 자체가 아예 제공되지 않는다. 같은 회사의 같은 기술이, 어느 나라 법이 적용되느냐에 따라 완전히 다른 이용자 권리로 갈리는 것이다.

'사후 동의는 불가능하다' — 옵트아웃의 근본적 한계

옵트아웃이 구조적으로 안고 있는 문제는 결국 타이밍이다. 크롤링하고, 학습시키고, 그다음에야 이용자에게 거부할 기회를 주는 순서 자체가 성립하기 어렵다는 지적이 규제 당국에서도 나오고 있다. 캐나다 개인정보보호 당국은 한 AI 기업의 학습 데이터 수집 관행을 조사한 결정문에서 사후 동의는 성립할 수 없다는 원칙을 명시적으로 확인했다. 이는 개별 기업의 정책 문제를 넘어, '일단 모아서 학습시킨 뒤 이용자에게 빠져나갈 창구를 열어준다'는 업계 전반의 관행 자체가 법적으로 더 이상 안전지대가 아니라는 신호로 읽힌다.

한국의 옵트아웃: 안내서 속 사례와 딥시크의 방향 전환

한국 개인정보보호위원회의 「생성형 인공지능 개발·활용을 위한 개인정보 처리 안내서」는 실제 심의 사례를 통해 옵트아웃의 위치를 보여준다. LLM 성능 개선을 위해 이용자 프롬프트를 학습데이터로 수집·이용하는 것이 적법한지를 판단한 사례에서, 위원회는 학습데이터 수집 사실과 거부 방법(opt-out)을 대화창 알림으로 여러 차례 고지해 이용자의 예측 가능성을 높였다는 점을 적법성 판단의 근거 중 하나로 들었다. 즉 한국에서 옵트아웃은 그 자체로 권리라기보다는, 기업이 개인정보를 적법하게 추가 이용했다고 주장하기 위한 '이용자 이익 침해를 완화하는 장치' 중 하나로 다뤄지고 있다.

실제 업계 움직임도 있다. 중국 AI 기업 딥시크는 2025년 초 국내 서비스 잠정 중단 사태 이후, 올해 2월 국내 개인정보 처리방침을 개정하면서 이용자가 자신의 데이터를 AI 학습에 쓰지 못하도록 직접 차단할 수 있는 학습거부권(옵트아웃)을 공식화했다. 다만 이 발표 이후에도 국내 이용률 하락세는 이어지고 있어, 옵트아웃 도입이 곧바로 신뢰 회복으로 이어지는 것은 아니라는 점을 보여준다.

옵트아웃으로 충분한가

정리하면 학습거부권은 세 겹의 한계를 안고 있다. 첫째, 켜는 시점 이후의 데이터만 보호하고 이미 학습된 과거 데이터에는 소급 적용되지 않는다. 둘째, 국가·지역별 법제에 따라 제공 여부와 절차의 난이도가 크게 갈린다 — 같은 기업이라도 EU 이용자와 미국 이용자가 갖는 권리가 다르다. 셋째, '일단 수집 후 거부 기회 제공'이라는 순서 자체를 문제 삼는 규제 흐름이 등장하고 있어, 옵트아웃이 사전 동의(opt-in)를 완전히 대체할 안정적 해법인지도 불확실하다.

결국 옵트아웃은 완벽한 해결책이라기보다, 잊힐 권리의 기술적 한계와 사전 동의의 산업적 부담 사이에 놓인 과도기적 타협에 가깝다. 다음 호에서 다룰 각국 규제 현황은 이 타협이 앞으로 어느 방향으로 굳어질지를 가늠하는 단서가 될 것이다.

[참고자료]

👑 Sovereign AI 격차, AI를 쓰는 나라와 통제하는 나라

▲ 출처: 박한신, “[단독] 초과세수 5조 투입…'소버린 AI' 개발한다”, 한경, 2026.07.02.

소버린 AI가 바꾸는 기술주권의 기준…인프라·모델·데이터·거버넌스까지 국가 경쟁력의 핵심으로

인공지능이 산업의 생산성을 높이는 도구를 넘어 국가 행정과 경제, 안보를 떠받치는 기반으로 자리 잡고 있다. 이제 국가 경쟁력을 가르는 기준은 AI 서비스를 얼마나 빠르게 도입했는지가 아니다. AI가 작동하는 데 필요한 기술과 데이터, 컴퓨팅 자원을 누가 소유하고 있으며, 위기 상황에서도 이를 스스로 운영하고 통제할 수 있는지가 더욱 중요해지고 있다.

이러한 변화 속에서 주목받는 개념이 ‘소버린 AI(Sovereign AI)’다. AI를 많이 사용하는 국가에서 한 단계 더 나아가, AI의 판단과 운영을 외부에 전적으로 의존하지 않는 국가로 전환해야 한다는 요구다.

전산화에서 AI 전환까지…정보기술의 역할이 달라졌다.

지난 60여 년간 정보기술의 발전은 크게 전산화, 정보화, 디지털 전환, 인공지능 전환의 단계로 이어졌다.

초기 전산화는 인간이 수행하던 계산과 기록을 컴퓨터에 맡기는 것에서 시작됐다. 이후 데이터통신과 인터넷이 확산되면서 컴퓨터는 서로 연결됐고, 정보는 저장되는 자원에서 사회 전체로 전송·유통되는 자원으로 변화했다. 웹의 등장은 정보의 생산과 소비 문턱을 낮췄으며, 전자상거래와 전자정부, 온라인 커뮤니티 등 새로운 사회 구조를 만들었다.

디지털 전환의 시대에는 클라우드와 빅데이터, 모바일, 사물인터넷을 활용해 조직의 업무 방식과 서비스 구조를 재설계했다. 현재 진행되는 인공지능 전환, 이른바 AX(AI Transformation)는 여기서 한 단계 더 나아간다. AI를 일부 업무에 적용하는 것을 넘어 조직의 운영 체계와 의사결정 구조 자체를 AI 중심으로 바꾸는 과정이다.

특히 생성형 AI와 자율형 AI 에이전트가 확산되면서 AI는 단순한 보조 도구가 아니라 조직의 경험과 전문성을 학습하고 판단하는 핵심 시스템으로 발전하고 있다. 국가와 기업의 경쟁력 역시 AI를 얼마나 전략적으로 내재화했는지에 따라 달라질 가능성이 커졌다.

하지만 AI가 내리는 판단은 독립적으로 만들어지지 않는다. 모델이 어떤 데이터를 학습했는지, 데이터의 품질과 대표성은 충분한지, 누가 데이터에 접근하고 이를 통제하는지에 따라 결과가 달라진다. 잘못된 데이터가 잘못된 결과를 만든다는 ‘GIGO(Garbage In, Garbage Out)’ 원칙이 AI 시대에 더욱 중요해진 이유다.

AI 경쟁력은 결국 데이터의 양과 품질, 접근성, 통제 구조에 의해 결정된다. 개인정보 보호와 산업 활용, 국가 핵심 데이터의 보호, AI 안전성과 설명 가능성, 책임성을 함께 다루는 데이터 거버넌스가 새로운 권력으로 부상하고 있다.

소버린 AI, ‘무엇을 스스로 결정할 수 있는가’의 문제.

주권의 핵심은 외부의 간섭 없이 최종적인 의사결정을 내릴 수 있는 능력이다. AI가 국가 운영과 산업, 안보를 좌우하는 기반이 되면서 이러한 주권의 개념도 AI 영역으로 확장되고 있다.

소버린 AI는 모델과 데이터, 컴퓨팅 인프라, 전문 인재로 이어지는 AI 가치사슬의 핵심을 특정 국가나 기업에 종속되지 않고 독자적으로 확보·통제하는 능력을 의미한다. 단순히 자국에서 개발한 AI 모델 하나를 보유하는 것으로 완성되는 개념이 아니다.

AI 모델은 해외 기업의 서비스를 이용하면서 데이터는 외부 클라우드에 저장하고, 연산은 특정 기업의 반도체와 소프트웨어에 전적으로 의존한다면 실질적인 통제권을 확보했다고 보기 어렵다. 소버린 AI의 본질은 AI 역량을 타국이나 특정 기업에 의존하지 않고 국가가 스스로 결정하고 통제할 수 있는가에 있다.

따라서 소버린 AI를 구성하는 요소는 독자적인 컴퓨팅 인프라와 파운데이션 모델뿐 아니라 데이터, 소프트웨어 생태계, 연구개발 역량과 전문 인재까지 포함한다. 이들 요소가 하나의 가치사슬로 연결되지 않으면 일부 기술을 확보하더라도 다른 영역의 종속으로 인해 전체 통제권을 잃을 수 있다.

‘디지털 강국’의 성과 뒤에 남은 기술 의존.

한국은 초고속 정보통신망과 전자정부, 디지털 행정 서비스 분야에서 빠른 성과를 거뒀다. 행정정보의 디지털화와 온라인 민원 서비스, 공공데이터 활용 등은 세계적으로도 높은 평가를 받아왔다.

그러나 서비스 활용의 성공이 곧 기술주권의 확보를 의미하지는 않는다.

1990년대 이후 공공과 민간 부문에서 확대된 정보기술 아웃소싱은 비용을 줄이고 외부 전문성을 신속하게 활용할 수 있다는 장점이 있었다. 반면 시스템의 기획과 설계, 검증까지 외부 사업자에게 맡기면서 조직 내부에 핵심 기술역량과 노하우가 충분히 축적되지 못하는 한계도 나타났다.

2000년대에는 국내 기업이 대규모 시스템통합 사업을 수행하며 정보화 시장을 이끌었다. 그러나 서버와 운영체제, 데이터베이스 관리시스템 등 기반 기술은 해외 제품에 크게 의존하는 구조가 형성됐다. 국내 기업은 고객의 업무를 분석하고 응용시스템을 구축·운영했지만, 제품의 지식재산권과 라이선스, 기술표준과 업그레이드 방향을 결정하는 권한은 해외 공급자에게 집중됐다. 이러한 의존 구조는 클라우드와 AI 환경에서도 반복될 가능성이 있다.

그 결과 한국은 정보기술을 매우 잘 활용하는 국가가 됐지만, 기반 기술을 직접 소유하고 발전 방향을 통제하는 역량에는 상대적으로 취약하다는 지적을 받는다. 눈에 보이는 시스템과 서비스 구축에 투자가 집중되는 동안 원천 소프트웨어와 핵심 지식재산, 장기적인 기술 생태계는 충분히 성장하지 못했다는 것이다.

AI 시대에는 이러한 구조가 더 큰 위험으로 이어질 수 있다. 해외 거대언어모델 API에 대한 과도한 의존은 행정·산업 데이터의 통제 문제를 발생시킬 수 있으며, 해외 GPU와 고성능 컴퓨팅 자원에 대한 의존은 공급망 변화와 비용 증가에 국가 AI 전략이 흔들리는 결과를 초래할 수 있다.

이에 따라 정보기술 투자의 기준도 ‘어떤 시스템을 구축했는가’에서 ‘어떤 핵심 자산을 우리가 소유하고 통제하는가’로 전환할 필요가 있다.

소버린 AI 실현을 위한 네 가지 핵심 과제.

소버린 AI를 실현하려면 인프라와 원천기술, 데이터 주권, 거버넌스를 하나의 체계로 구축해야 한다. 우선 데이터센터와 전력, AI 가속기, 네트워크 등 핵심 인프라를 안정적으로 확보해야 한다. 모든 장비를 국산화하기보다는 공급망 위기에도 국가의 핵심 AI 시스템을 독자적으로 운영할 수 있는 ‘전략적 자율성’을 갖추는 것이 중요하다.

기술 측면에서는 AI 반도체와 시스템 소프트웨어, AI 프레임워크, 파운데이션 모델을 직접 이해하고 수정·통제할 수 있는 역량이 필요하다. 글로벌 기술과 오픈소스를 활용하되 반드시 통제해야 할 핵심 기술은 국내에 축적하고, 연구기관·기업·정부가 기술개발부터 실증과 사업화까지 연결되는 생태계를 조성해야 한다.

데이터 주권도 단순히 데이터의 국외 이동을 차단하는 개념이 아니다. 국가와 국민이 무엇을 개방하고 보호할지, 어떤 조건으로 데이터를 활용할지를 스스로 결정할 수 있어야 한다. 개인정보 보호와 데이터 활용이 충돌하지 않도록 가명정보와 마이데이터 등 안전한 활용 장치도 함께 마련할 필요가 있다.

아울러 데이터를 한곳에 모으는 방식에서 벗어나 기관과 산업의 데이터를 안전하게 연결하는 거버넌스로 전환해야 한다. 데이터의 품질과 표준, 상호운용성을 확보하고 AI의 투명성·설명 가능성·책임성을 제도화할 때 소버린 AI는 폐쇄적인 국산화 정책이 아닌 지속 가능한 국가 혁신 전략으로 자리 잡을 수 있다.

소버린 AI는 ‘완전한 자급자족’이 아니다.

소버린 AI는 해외 기술을 배제하고 모든 것을 국내에서 개발하자는 구호가 아니다. 글로벌 기술과 오픈소스를 활용하면서도 국가의 핵심 기능과 전략자산만큼은 스스로 이해하고 수정하며 통제할 수 있어야 한다는 의미에 가깝다.

이를 위해서는 인프라, 하드웨어·소프트웨어, 데이터, 거버넌스를 각각 분리해 지원하는 산발적인 정책에서 벗어나야 한다. 네 가지 요소를 하나의 가치사슬로 연결하고, 기술 개발부터 실증과 사업화, 공공 수요 창출까지 이어지는 장기적인 생태계를 설계해야 한다.

AI 시대의 기술주권은 얼마나 많은 AI 서비스를 도입했는지로 측정되지 않는다. 국가의 판단을 뒷받침하는 모델과 데이터, 인프라를 누가 소유하고 통제하는지가 진정한 경쟁력을 결정한다.

한국이 ‘AI를 잘 활용하는 국가’를 넘어 ‘AI의 방향을 스스로 결정할 수 있는 국가’로 도약하기 위해서는 이제 질문을 바꿔야 한다.

✅ CTEM이 보여주는 변화(3) - 지금 왜 보안에서 우선순위화가 중요한가

보안팀은 그 어느 때보다 많은 정보를 보고 있다. 새롭게 공개되는 취약점은 끊임없이 늘어나고, 외부 공격표면은 클라우드와 SaaS, 아이덴티티 환경으로 확장됐다. 각종 보안 솔루션은 더 많은 경고와 이벤트를 실시간으로 쏟아낸다. 겉으로 보면 보안 조직은 과거보다 훨씬 넓은 가시성을 확보한 듯 보인다. 그러나 역설적으로, 보안 운영은 이전보다 더 어려워졌다. 더 많이 보고 있음에도 무엇을 먼저 처리해야 하는지 결정하기가 갈수록 어려워지고 있기 때문이다.

이 변화는 단순히 업무량이 늘어난 문제로만 보기 어렵다. 지금 보안 조직이 마주하는 근본적인 어려움은 더 이상 “무엇을 볼 수 있느냐”에 있지 않다. 오히려 이미 지나치게 많은 정보가 주어져 있는 상황에서, 그 가운데 실제로 중요한 위험이 무엇인지 가려내는 일이 더 큰 과제가 되고 있다. 최근 Continuous Threat Exposure Management(CTEM)가 주목받는 배경 역시 여기에 있다. CTEM은 취약점을 더 많이 찾기 위한 접근이라기보다, 조직에 실제로 의미 있는 노출을 식별하고 우선순위를 정하는 운영 방식이라는 점에서 현재 보안의 문제의식을 상징적으로 보여준다.

▲ [출처] - AI 생성 사진

보안은 이미 충분히 많은 것을 보고 있다

오늘날 보안 조직은 정보 부족보다 정보 과잉에 가까운 현실에 놓여 있다. 취약점 관리 도구는 수천, 수만 개의 이슈를 보여주고, 공격표면 관리 체계는 지속적으로 새로운 외부 노출 지점을 식별한다. 여기에 EDR, SIEM, 이메일 보안, 클라우드 보안 등 여러 도구에서 생성되는 경고와 이벤트까지 더해지면 보안팀은 사실상 과잉 신호 속에서 일하게 된다.

문제는 이런 환경에서 흔히 ‘가시성이 높아졌다’는 표현이 마치 보안 수준이 함께 올라간 것처럼 받아들여진다는 점이다. 물론 더 넓은 가시성은 중요하다. 하지만 더 많이 본다고 해서 위험이 자동으로 줄어드는 것은 아니다. 취약점을 수만 개 발견해도, 그 가운데 무엇이 실제 공격으로 이어질 가능성이 높은지 판단하지 못하면 조직의 보안 상태는 근본적으로 달라지지 않는다. 오히려 정보가 많아질수록 우선순위를 정하지 못한 채 대응이 분산되고, 중요한 문제를 놓칠 가능성은 더 커질 수 있다.

결국 지금 보안 운영의 병목은 탐지 부족이 아니라 실행의 혼잡에 있다. 보고 있는 것은 충분히 많지만, 그중 무엇을 먼저 처리할지 결정하는 기준은 여전히 불분명한 경우가 많다. 이 지점에서 보안은 단순히 더 많이 찾는 체계가 아니라, 더 중요한 것을 먼저 골라내는 체계로 옮겨갈 필요가 있다.

모든 취약점과 노출은 같은 위험이 아니다

우선순위화가 중요한 이유는 모든 이슈를 같은 기준으로 다룰 수 없기 때문이다. 실제 보안 운영에서 위험은 단순한 개수나 점수만으로 설명되지 않는다. 예를 들어 CVSS 점수가 높은 취약점이라도 내부망에만 존재하고, 보완 통제가 충분히 적용돼 있으며, 실제 공격 경로상 악용 가능성이 낮다면 시급성은 떨어질 수 있다. 반대로 점수는 상대적으로 낮더라도 인터넷에 노출된 핵심 자산에 존재하고, 공격자들이 이미 활발히 악용하는 유형이라면 훨씬 먼저 대응해야 할 가능성이 크다.

이처럼 현실의 위험은 개별 취약점 자체보다 그것이 놓인 맥락에 의해 달라진다. 자산이 외부에 노출돼 있는지, 비즈니스적으로 얼마나 중요한 시스템인지, 다른 취약점이나 권한 문제와 연결돼 공격 경로를 만들 수 있는지, 이미 탐지나 차단을 위한 보완 통제가 존재하는지 같은 요소들이 함께 고려돼야 한다. 결국 취약점의 수나 경고의 양은 출발점일 뿐, 실제 우선순위는 맥락을 반영한 해석을 통해서만 정할 수 있다.

따라서 오늘날 보안팀이 마주한 과제는 더 많은 항목을 나열하는 일이 아니다. 이미 충분히 많은 정보는 존재한다. 중요한 것은 그 정보를 동일한 무게로 다루지 않고, 조직에 실제로 더 큰 영향을 미칠 수 있는 이슈부터 선별하는 능력이다. 보안에서 우선순위화가 핵심이 된 이유는 바로 여기에 있다.

CTEM은 왜 지금 주목받는가

이러한 변화 속에서 CTEM은 단순한 업계 키워드 이상의 의미를 갖는다. CTEM은 더 많은 취약점이나 노출을 식별하기 위한 프레임이라기보다, 이미 과잉에 가까운 정보 속에서 어떤 노출이 조직에 실질적인 위험을 만드는지 지속적으로 판단하고, 그에 따라 대응 순서를 정하려는 접근에 가깝다. 다시 말해 CTEM의 핵심은 발견 자체가 아니라, 발견한 문제를 어떻게 해석하고 어떤 순서로 줄여나갈 것인가에 있다.

이 점에서 CTEM은 오늘날 보안 운영이 어디로 이동하고 있는지를 잘 보여준다. 보안팀은 더 이상 발견한 모든 문제를 동일한 긴급도로 다룰 수 없다. 같은 취약점이라도 자산의 중요도와 외부 노출 정도, 공격 경로상 위치에 따라 의미가 달라지고, 대응 우선순위 역시 달라질 수밖에 없다. CTEM은 바로 이 차이를 운영 차원에서 구조화하려는 시도라고 볼 수 있다.

중요한 것은 CTEM을 하나의 기술 용어로 소비하는 데 그치지 않는 것이다. CTEM이 주목받는 이유는 새로운 약어이기 때문이 아니라, 지금 보안 조직이 실제로 필요로 하는 질문을 담고 있기 때문이다. 무엇을 더 많이 볼 것인가가 아니라, 무엇을 먼저 줄여야 하는가. CTEM은 그 질문을 가장 직접적으로 드러내는 사례다.

보안 운영의 기준은 무엇으로 바뀌고 있나

이 변화는 취약점 관리에만 국한되지 않는다. 더 넓게 보면 보안 운영 전반의 기준 자체가 달라지고 있다. 과거에는 무엇을 얼마나 많이 식별할 수 있는지가 중요한 지표였다면, 이제는 확보한 데이터를 바탕으로 실제 위험을 얼마나 줄였는지가 더 중요한 평가 기준이 되고 있다. 이는 단순히 운영 효율의 문제가 아니라, 복잡해진 환경에서 실질적인 보안 성과를 어떻게 정의할 것인가의 문제이기도 하다.

같은 맥락에서 보안팀의 성과를 측정하는 방식도 달라질 필요가 있다. 얼마나 많은 취약점을 스캔했는지, 얼마나 많은 티켓을 닫았는지, 얼마나 많은 경고를 처리했는지 같은 지표는 여전히 의미가 있다. 그러나 이런 수치만으로는 조직의 위험이 실제로 얼마나 줄어들었는지 설명하기 어렵다. 앞으로 더 중요해질 질문은 핵심 자산의 위험이 얼마나 빠르게 완화됐는지, 실제 공격 가능성이 높은 노출이 얼마나 우선적으로 줄어들었는지에 가까울 것이다.

결국 보안의 방향은 수집 중심에서 실행 중심으로, 개별 이슈 관리에서 맥락 기반 위험 관리로 이동하고 있다. 우선순위화는 이 변화의 부산물이 아니라 중심에 놓인 원칙이다. 복잡성과 과잉이 일상이 된 환경에서, 무엇을 먼저 처리할 것인지에 대한 판단 없이는 어떤 가시성도 실질적인 성과로 이어지기 어렵다.

우선순위화는 선택이 아니라 운영의 전제가 되고 있다

오늘날 보안의 문제는 더 많은 것을 보지 못해서 생기는 경우보다, 너무 많은 것들 속에서 무엇이 더 중요한지 결정하기 어렵기 때문에 생기는 경우가 많다. 취약점도, 노출도, 경고도 계속 늘어나는 환경에서 보안팀이 가져야 할 핵심 역량은 더 많은 정보를 모으는 능력이 아니라, 중요한 것부터 빠르게 판단하고 실행하는 능력이다.

이 점에서 CTEM은 하나의 기술 트렌드라기보다 보안 운영이 어디로 향하고 있는지를 보여주는 신호에 가깝다. 앞으로의 보안은 얼마나 많이 발견했는가보다, 무엇을 먼저 줄였는가, 그리고 실제 위험을 얼마나 효과적으로 낮췄는가로 평가받게 될 가능성이 크다. 우선순위화는 효율을 높이기 위한 선택이 아니라, 보안 성과를 만들어내기 위한 운영의 전제가 되고 있다.

결국 지금 보안에서 가장 중요한 질문은 모든 것을 보고 있는가가 아니다. 정말 중요한 것을 먼저 줄이고 있는가, 바로 그 질문이 앞으로의 보안 운영을 가르는 기준이 될 가능성이 크다.

[참고자료]

📢 신규 '친구 초대 누적 레이스' 안내

안녕하세요, BoB 뉴스레터 구독자 여러분!

매달 뜨거운 성원을 보내주셨던 ‘BoB 뉴스레터 퀴즈 이벤트’가 예산상의 이유로 6월호를 마지막으로 잠정 중단하게 되었습니다. 그동안 퀴즈에 적극적으로 참여하며 반짝이는 보안 지식을 나눠주신 모든 분께 진심으로 감사드립니다.

하지만 아쉬워하긴 이릅니다! 더욱 묵직한 혜택을 담은 장기 프로젝트가 찾아옵니다! 💎

퀴즈 이벤트의 아쉬움을 달래기 위해, 2026년 7월호 부터 [BoB 뉴스레터 친구 초대 누적 레이스]를 새롭게 시작합니다.

주변에 보안 트렌드를 함께 나누고 싶은 분들이 있다면, 이번 호 링크를 활용해 지금부터 미리미리 나만의 초대 포인트를 빌드업해 두세요! 😉

E D I T O R

🚨 BoB 가족들의 소중한 소식을 기다리고 있습니다. 🚨

함께 공유하고 싶은 소식, 수상 내역, 행사기타 소소한 일상까지 구독자분들의 공유를 기다립니다.

- 함께 만들어가는 BoB 뉴스레터 -  

bobnews@bobnews.kr

Best of the Best 뉴스레터팀 7기

(13449) 경기도 성남시 수정구 대왕판교로 815(시흥동 321) 기업지원허브 혁신기술존 4층

대표번호: 02-405-6512~5 | Fax: 02-565-6052