TTESays

[TE머묾] 보안은 즐겁다 3

문가용 기자

Published: 22:28, 16 Mar 2026 (Updated: 05:11, 17 Mar 2026)

Photo by Sincerely Media / Unsplash

💡

Editor's Pick
- 고전적 느낌 주는 광고판을 보고 취약점 개념을 다시 생각
- 고정적 개념의 취약점보다는 상대적 개념으로 바라보면
- 안전 자체에 대한 시야 넓어져야...성벽보다는 파도타기

1.

기자나 편집자 등 남의 철자 헐뜯는 게 직업인 사람은, 경력 초반 10년 정도는 거리 돌아다니는 게 괴롭다. 광고나 간판, 전단지를 보면 세상 천지에 한글 제대로 쓸 줄 모르는 사람만 있는 듯한 기분이 들 정도다. 빨간 매직 들고다니면서 교정해주고 싶은 욕구가 치솟는다. 물론 그러면 잡혀가기 때문에 한숨만 쉴 뿐이다. 이럴 때 옆에 누군가 있다면, 그 사람은 비자발적 교정지가 되어 국어 수업을 잠시 들어야 한다.

그러다 어느 날 - 몇 년차 정도에 이런 일이 일어나는지는 알 수가 없다 - 명백한 오탈자로 보이는 그 글자들 중에 좀 다른 것들이 섞여 있다는 걸 서서히 깨닫기 시작한다. 하루는 버스를 타고 지나가다 공사장 안내판이 보였다. 완공 후 건물에 붙을 이름이 ‘청춘삘딩’이 될 예정이라는 내용이었다. 새내기였다면 ‘삘’을 보고 한숨을 쉬었겠지만, 난 이제 머리 희끗한 경력직이다. 저렇게 명백한 오타를 저렇게 큰 글자로 인쇄해 저렇게 눈에 띄는 곳에 붙일 리가 없다는 전체 맥락이 먼저 생각나면서 오히려 그 이름에 대해 생각해보기 시작했다.

‘삘딩’은 저 먼 옛날 한글 맞춤법을 떠올리게 한다. ‘뉴스’를 ‘늬우스’로, ‘쿠바’를 ‘규바’로, ‘버스’를 ‘빠스’로, ‘라디오’를 ‘라됴’로 적던 때가 이제는 기억 속에 흐릿하다. 고전 만화 속 간판에 가끔 나타나거나, 박물관 사료 속에 어쩌다 한 번 등장하는 지나간 흔적이다. 우리 부모님들이 가끔씩 사용했다가 신지식 갖춰 하교한 어린 자녀들에게 면박을 당하곤 했던, 그런 기억들이 오히려 생생한.

그러다가 ‘청춘’이라는 단어로 옮겨간다. 이것도 ‘청년’에 밀려 사실상 사멸되기 직전에 있다는 느낌일 정도로 오래된 표현이다. ‘빠스’ 안에서 ‘라됴’ 틀어 ‘늬우스’ 듣던 시절, 종로 어느 번화가에 가면 붓 그림으로 그린 영화 포스터에 ‘맨발의 청춘’이라든가 ‘청춘교사’와 같은 제목이 붙어 있지 않았던가. 신축 건물 이름이 ‘청년삘딩’이었다면, 담당자나 인쇄소의 실수일 가능성이 높았을지 모르나, ‘청춘삘딩’이 되는 순간 ‘의도’가 묻어난다. 십중팔구 그 시절의 느낌을 내기 위한 작법일 것이다.

2.

보안 기자 경력이 미천했을 때, 소프트웨어나 OS에서 나타나는 취약점 소식에 한숨을 뱉곤 했다. 특히 비슷한 류의 취약점들이 반복해서 발견될 때, 그래서 비슷한 내용의 기사를 여러 번 찍어내야 할 때 마음속으로는 개발자들에게 유죄 판결을 내렸다. 개발할 때 졸면서 하는 건가, 똑같은 실수를 반복한다는 건 직무유기 아닌가, 양심 문제인가, 별별 생각이 다 들었다.

그러다 문득 알게 됐다. 취약점은 ‘고정된 상태’가 아니라 ‘큰 맥락 상의 상대적 관계’에 놓인 개념이라는 것을. 물론 개발자가 오타를 낸다거나 기본 보안 개념을 습득하지 못해 메모리 관리에서 부실히 한다거나 하는 ‘고정적 상태’의 취약점들도 상당수 존재한다. 하지만 ‘큰 맥락 상의 변화’로 인해 ‘원래는 정상이었다가 나중에 취약점으로 변질되는’ 유형의 취약점들도 결코 적지 않았다.

예전에는 절대로 부술 수 없는 것처럼 추앙되던 암호화 알고리즘(SHA-1 등)이 기술 발전 때문에 이제는 그 자체로 취약점 취급을 받는다. 웹 통신의 표준이었던 HTTP는 어떤가? HTTPS에게 자리를 내준 지 오래고, 스스로는 브라우저가 경고를 내게 만드는 골칫거리로 전락했다. 각종 디지털 신기술이 몰려오면서 조금이라도 오래된 기술과 프로토콜에는 ‘레거시’라는 딱지가 붙으며, 사용자들 편하라고 만들어 둔 매크로 같은 기능들은 공격자들이 하도 악용해 이제 없다시피 한 것이 되어버렸다.

우리가 뻔질나게 드나드는 사이버 공간과, 우리 지문이 수없이 묻어나는 현대 장비들에는, 개발자가 수십년 뒤 미래와 기술 발전 흐름을 정확히 꿰뚫는 능력을 갖지 않는 이상 발생 자체를 차단할 수 없는 유형의 취약점들이 존재할 수밖에 없다. 세계 1위 천재가 개발해도, 수조 단위 자본이 뒷받침 되는 거대 프로젝트 운영사라도 방지할 수 없다. 심지어 요즘은 오픈소스가 개발의 주재료가 되면서 의존성(dependency) 문제도 얽히기 시작해 상황은 더 복잡해지고 있다.

3.

애초에 ‘취약하다’나 ‘약하다’라는 단어 자체가 절대적 개념일 수 없다. 뭔가를 기준으로 덜 강할 때 ‘약하다’고 하고, 그 약한 부위가 특정될 때 그것을 ‘취약하다’고 말한다. 그 ‘취약한 부분’도, 다른 부분에 비해 상대적으로 허술해서 취약한 거지, 절대적인 게 아니다. 다이아몬드로 구성된 벽체 중 한 지점이 콘크리트라면, 제아무리 바위덩이 같은 콘크리트라 해도 취약점 취급 당한다.

취약점을 개발자의 직무유기라든가 무책임과 같은 개념에 연결짓는 건 너무나 간편한 일이다. 너무 간편해 실제 현장에서 많이 자행된다. 어느 날 취약점이 나왔을 때, 개발자를 추궁해 책임을 물게 하거나 닥달해 패치를 만들어내게 하는 거, 다 여기에 속한다. 이렇게 했을 때 단기적인 것 외에는 고쳐지는 게 있던가? 그랬다면 대 소프트웨어의 시대에 취약점의 굴레에서 벗어나지 못해 허덕이는 지금과 같은 상황은 없었거나, 덜 숨막혔을지도 모른다.

장기적 개선을 위해서는 취약점이 ‘상대적’ 개념이라는 걸 이해해야 한다. 당대에는 정상이었던 것이 미래로 옮겨가면서 점점 낡은 게 되어가는 흔한 자연 섭리가 사이버 공간에서도 고스란히 실현되는 것뿐이라고, 시야를 넓혀야 한다. 늙어간다고 화내지 않듯, 내 손때 묻은 도구가 폐기물이 되어가는 과정에 속을 끓이지 않듯, 더 나아가 만물이 탄생 직후부터 예외 없이 죽음 쪽으로 나아가는 사실에 분노하지 않듯, 취약점을 보고 ‘개발자 유죄’를 떠올리면 도움될 게 없다는 것이다.

‘기술이 한 단계 나아갔으니 방어력도 강화해야 되겠구나.’
‘절대적일 것 같았던 프로토콜이 새것으로 교체가 되는구나.’
‘이거, 이거, 개발자가 또 한눈 팔고 안일하게 일했구나’ 대신 이런 생각으로 취약점을 바라보면 ‘안전이라는 게 절대적 기준’이 아니라는 것에 도달한다. 성벽을 둘러쳐 자산을 보호하는 개념의 보안은 이미 오래 전에 폐기처분됐다는 게 떠오른다. ‘항상 세기와 수위가 변하는 파도 위에서 넘어지지 않게 하는 것’이 보안의 할 일이라는 것이 상기된다.🆃🆃🅔

by 문가용 기자(anotherphase@thetechedge.ai)