현대적 보안, 2026년 버전

2020년에 최재훈님이 쓴 “현대적 보안”이라는 글이 있다. 당시에 나는 국내 OTT 회사의 첫번째 보안 엔지니어로써 문화와 보안 엔지니어링 원칙을 어떻게 해야, 안전하면서도 편한 보안을 구축할 수 있을까 고민을 크게 던져준 글이다. 6년이 지난 지금 읽어도 핵심 원칙은 여전히 유효하다. Zero Trust, SaaS 활용, 동기화된 실패 회피, 상상력의 중요성. 그런데 세상이 많이 변했다. 클라우드 네이티브가 기본값이 됐고, AI가 코드를 짜고, 공급망 공격이 일상이 됐다. 원문의 프레임워크 위에 2026년의 현실을 덧입혀보려 한다.

100만 유저가 이용한 온라인 강의 서비스, 국내 1,2위를 다퉜던 OTT 서비스, 글로벌 B2B 엔터프라이즈 SaaS 서비스들에서 보안 엔지니어로 일해보며 보안을 고민해왔다. 원문 저자가 말한 “이렇게까지 하겠어?”라고 방심하면 바로 그쪽으로 공격이 들어오는 살벌한 시장의 감각에 깊이 공감한다. OWASP Seoul을 운영하고, 멘토링 해주고, 고객으로 만나는 실무자들의 고민도 결국 비슷하다. 어디서부터 손대야 할지 모르겠다는 것.

무엇이 현대적 보안이 아닌가, 2026년 버전

원문에서 지적한 것들이 해결됐을까? 안타깝게도 대부분 그대로다. 몇 가지를 2026년 맥락으로 업데이트하면 이렇다.

ISMS 인증 받았으니 안전하다고 믿는다. 101개 항목 체크리스트를 통과하면 보안이 완성된다고 착각한다. 2024년 쿠팡 3,370만 건 유출 사고가 터졌을 때, 쿠팡은 ISMS-P 인증을 보유한 회사였다. 인증이 무의미하다는 게 아니다. 인증은 최소 기준이지 목표가 아니라는 거다.

클라우드 썼으니 보안은 CSP가 알아서 한다고 믿는다. 책임 공유 모델을 이해 못 하는 조직이 아직도 많다. AWS가 인프라를 보호해줘도, 그 위에서 돌아가는 애플리케이션과 데이터는 우리 책임이다. S3 버킷 퍼블릭으로 열어놓고 “AWS 쓰는데 왜 뚫렸지?” 하는 사고가 2026년에도 계속 터진다.

망분리했으니 괜찮다고 믿는다. 원문에서도 지적했지만 6년이 지나도 이 미신은 건재하다. 물리적 망분리가 논리적 접근통제를 대체할 수 없다. 망분리된 환경에서도 빌드 파이프라인 하나, USB 하나, 내부자 하나면 뚫린다.

AI 도입했으니 보안도 자동화됐다고 믿는다. AI 기반 위협 탐지 솔루션 도입하면 끝이라고 생각한다. 정작 그 AI 솔루션에 들어가는 API 키 관리는 엉망이고, AI가 만들어내는 새로운 공격 표면은 신경도 안 쓴다.

DevOps 했으니 DevSecOps도 된 거라고 믿는다. 파이프라인에 SonarQube 하나 붙여놓고 DevSecOps 한다고 주장한다. 보안이 개발 프로세스에 녹아든 게 아니라, 개발 끝나고 보안 스캔 한 번 돌리는 게 전부다.

누구도 믿지 말라, 그런데 진짜로

원문에서 Zero Trust를 강조했다. 당시에는 “Buzzword가 된 감이 있으나”라고 썼다. 2026년 현재, Zero Trust는 Buzzword를 넘어 규제 요건이 되어가고 있다. 미국 연방정부는 Zero Trust 아키텍처 도입을 의무화했고, NIST SP 800-207이 사실상의 표준이 됐다.

문제는 Zero Trust를 “VPN 대신 ZTNA 쓰는 것”으로 이해하는 조직이 많다는 거다. 도구를 바꾸면 Zero Trust가 구현되는 게 아니다. 원문에서 말한 핵심은 여전히 유효하다. “각각의 자원은 스스로를 보호한다. 내부 시스템일지라도 외부 시스템으로 취급한다. 검증하고 모니터링하라.”

여기에 2026년 관점을 추가하자면, 검증 대상이 확장됐다. 예전에는 “사람”을 검증하면 됐다. 이제는 서비스 계정, API 키, 토큰, 워크로드 아이덴티티까지 검증해야 한다. 클라우드 환경에서 기계 대 기계 통신이 사람의 접근보다 압도적으로 많아졌기 때문이다. 사람한테는 MFA 걸어놓고, 서비스 계정은 만료 기한 없이 admin 권한으로 돌아가는 조직이 수두룩하다.

원문에서 퍼블릭 클라우드가 온프레미스보다 앞서간다고 했다. 각각의 리소스를 접근할 때마다 검증하고 모니터링하는 체계가 잡혀있기 때문이라고. 이건 2026년에도 맞는 말이다. 다만 그 체계를 제대로 활용하는 조직이 여전히 소수라는 게 문제다. IAM 정책은 *:*로 열어놓고, CloudTrail 로그는 쌓기만 하고 안 보고, GuardDuty 알람은 너무 많이 와서 다 무시한다.

동기화된 실패를 피하라

원문의 이 섹션이 특히 좋았다. “자동화와 관리용이성은 적극적으로 추구할 미덕이다. 그러나 이 둘을 쫓다 동기화된 실패에 빠지지 않게 조심하자.”

2026년에 이 원칙이 더 중요해진 영역이 있다. 바로 Kubernetes와 마이크로서비스다.

Kubernetes 클러스터 하나에 모든 서비스를 올린다. 관리가 편하니까. 그런데 그 클러스터의 control plane이 죽으면? etcd가 날아가면? 전부 다 같이 죽는다. 멀티 클러스터로 분리하면 복잡해지니까 안 한다. 그러다 장애 한 번에 전사 서비스가 내려간다.

서비스 메시 도입했다. Istio든 Linkerd든. 편하다. 모든 서비스 간 통신이 메시를 통과한다. 그런데 메시 자체에 장애가 나면? 2023년에 실제로 Istio 버그로 대규모 장애가 난 사례가 있다. 모든 것을 하나로 통합하면 그 하나가 SPOF(Single Point of Failure)가 된다.

원문에서 VPN의 함정을 지적했다. 여러 네트워크에 VPN으로 동시 접속하면 로컬 랩탑을 중심으로 모든 네트워크가 통합된다고. 이건 2026년에 더 심해졌다. 재택근무가 일상이 되면서 개발자 랩탑이 사실상의 네트워크 허브가 됐다. 회사 VPN, AWS VPN, 고객사 VPN, 개발용 클라우드 계정. 한 랩탑에서 다 접속한다. 그 랩탑이 뚫리면 모든 네트워크로 lateral movement가 가능하다.

해결책은 원문과 같다. 네트워크를 엮는 대신 해당 서비스만 선별해서 묶어라. 각 서비스는 상호검증해라. 한쪽의 실패가 다른 쪽으로 전이되지 않게 해라. 2026년에 추가할 건, 이걸 “설계 원칙”이 아니라 “기본값”으로 만들어야 한다는 거다. 의식적으로 분리하는 게 아니라, 통합하려면 의식적으로 결정해야 하는 구조로.

SaaS를 활용하라, 그러나 공급망을 이해하라

원문에서 SaaS를 적극 활용하라고 했다. 공격자의 관심과 자원을 분산시킬 수 있다는 논리였다. “공격자가 여러분의 시스템에 침투하려면 써드파티 서비스부터 뚫어야 한다. 보안 정책과 시스템이 매우 상이한 두 개의 시스템을 동시에 공격해 들어가기란 매우 어렵다.”

이 논리는 여전히 유효하다. 다만 2026년 관점에서 한 가지를 추가해야 한다. SaaS를 쓰면 그 SaaS가 공급망의 일부가 된다. 그리고 공격자들이 이걸 알아챘다.

SolarWinds 사태(2020)가 신호탄이었다. 그 후로 Kaseya(2021), Okta(2022), CircleCI(2023), 그리고 최근의 크라우드스트라이크 사태(2024)까지. 보안 도구, 인증 서비스, CI/CD 플랫폼 자체가 공격 대상이 됐다. 하나만 뚫으면 그걸 쓰는 수천 개 고객사를 한꺼번에 공격할 수 있으니까.

그렇다고 SaaS를 안 쓸 수는 없다. 모든 걸 직접 만들면 더 위험하다. 대신 공급망 리스크를 명시적으로 관리해야 한다. 첫째, 써드파티 서비스가 뚫렸을 때 영향 범위가 어디까지인지 파악하라. 둘째, 해당 연동을 즉시 끊을 수 있는 체계를 갖춰라. SOC 2 리포트 확인하는 것보다 이게 더 중요하다.

원문에서 “외부 서비스를 전체 보안 체계 사슬의 일부로 엮어 넣으면 강력한 지지대를 세울 수 있다”고 했다. 맞다. 동시에 그 사슬의 한 고리가 끊어졌을 때 전체가 무너지지 않게 설계해야 한다. 이건 앞서 말한 “동기화된 실패 회피”와 연결된다.

물은 여전히 위로 흐르지 않는다

원문의 CI/CD 섹션을 읽으면서 무릎을 쳤다. “개발 환경에서 스테이징과 운영으로 넘어가는 일련의 과정에서 하위 시스템이 상위 시스템에 침투적인 방식으로 지시를 내린다. 빌드 서비스가 운영 환경의 크레덴셜을 들고 운영 환경에 직접 접속해 배포를 진행한다.”

6년이 지났는데 이 문제는 더 심해졌다. GitHub Actions가 대중화되면서 “yaml 파일 하나로 배포까지”가 너무 쉬워졌다. 편의성이 올라간 만큼 위험도 올라갔다.

전형적인 패턴이 이렇다. GitHub Actions 워크플로우에서 AWS 키를 환경변수로 읽어서 aws s3 cp로 배포한다. 이 워크플로우 파일은 저장소에 있고, 저장소에 쓰기 권한 있는 개발자는 누구나 수정할 수 있다. 악의적인 PR 하나로 그 키를 외부로 빼돌릴 수 있다. 개발 환경이 운영 환경으로 가는 고속도로인 셈이다.

CircleCI 침해 사고(2023)가 정확히 이 패턴이었다. 공격자가 CircleCI 엔지니어 계정을 탈취해서 고객사들의 환경변수에 저장된 시크릿을 싹 긁어갔다. 중앙집중적인 빌드 시스템의 위험이 현실화된 거다.

원문의 해결책은 Pull 방식 배포다. “개발 환경은 빌드 산출물을 생성하는 책임만 다한다. 산출물이 준비되면 운영 환경의 배포 시스템이 그 산출물을 가져와서 검증하고 배포하면 된다.” Argo CD, Flux 같은 GitOps 도구가 이 방식이다. 빌드 시스템이 운영 환경 크레덴셜을 갖지 않는다. 중력을 따르는 구조다.

2026년에 추가할 건 OIDC 기반 인증이다. GitHub Actions에서 AWS로 배포할 때, 장기 크레덴셜(Access Key) 대신 OIDC로 임시 토큰을 받는 방식. 크레덴셜이 저장소에 저장되지 않으니 유출 위험이 줄어든다. AWS, GCP, Azure 모두 이 방식을 지원한다. 그런데 아직도 Access Key를 환경변수에 박아놓는 조직이 대다수다. 설정이 조금 더 복잡하다는 이유로.

권한보다는 합의와 시스템이다

원문의 이 섹션이 가장 실용적이면서도 과소평가된 부분이다. “과거에는 모든 것이 권한으로 정의됐다. 운영서버에 들어갈 권한, VPN을 열 권한 등등. 그러나 이러한 권한 체계는 실제로는 작동하지 않는다.”

2026년에도 마찬가지다. 권한 체계의 문제점을 몇 가지 더 구체화하면 이렇다.

권한은 한번 주면 회수가 안 된다. 프로젝트 끝났는데 권한은 그대로다. 팀 이동했는데 권한은 그대로다. 퇴사했는데… 이건 좀 회수하지만, 외주 끝난 협력사 계정은? 실제로 권한 감사 해보면 “이 사람 누구야?”가 수두룩하다.

권한이 있으면 쓰게 된다. 장애 대응용으로 운영 DB 접근권한 받아놨는데, 편하니까 일상적인 데이터 조회에도 쓴다. 권한이 있으면 남용하게 되어 있다. 인간의 본성이다.

권한 부여 과정이 병목이 된다. 기안 올리고, 승인 받고, 설정하고. 급할 때는 이 프로세스를 우회한다. 우회가 반복되면 그게 관행이 된다.

원문에서 제안한 해결책은 합의 시스템이다. “야간에 담당자가 VPN 시스템에 접근하면 감사 조직을 포함해 대여섯 명에게 알람이 간다. 그 중 셋이 승인/합의 버튼을 누르면 담당자는 VPN과 내부 시스템에 접근할 수 있다.”

2026년에는 이걸 구현하는 도구가 많아졌다. Teleport, StrongDM, Boundary 같은 제품들이 Just-in-Time 접근 제어를 제공한다. 평소에는 권한이 없다가, 요청하면 승인 워크플로우를 거쳐 임시 권한이 부여되고, 작업 끝나면 자동으로 회수된다. Slack이나 Teams와 연동해서 승인 요청을 받을 수도 있다.

이게 단순히 “보안 강화”가 아니다. 원문에서 말한 대로 “편의성에서도 합의 시스템이 더 나을 것이다.” 권한 기안서 쓰고 결재 기다리는 것보다, Slack에서 버튼 하나 누르고 동료 승인 받는 게 빠르다. 그리고 모든 접근이 기록으로 남으니 감사도 쉽다.

새로운 공격 표면: AI와 기계 아이덴티티

원문에 없던 섹션을 하나 추가해야 한다. 2020년 이후 보안 지형을 가장 크게 바꾼 두 가지가 있다.

첫째, AI의 보편화다. ChatGPT 이후로 모든 회사가 AI를 도입하고 있다. 문제는 AI 애플리케이션이 새로운 공격 표면을 만든다는 거다. LLM에 들어가는 API 키, RAG 시스템이 접근하는 내부 데이터, 프롬프트 인젝션을 통한 시스템 명령 실행. 전통적인 웹 보안 프레임워크로는 커버가 안 되는 영역이다.

AI 코딩 어시스턴트도 리스크다. Copilot이 코드를 짜주는데, 가끔 학습 데이터에서 본 시크릿 패턴을 그대로 제안한다. 개발자가 무심코 수락하면 코드에 박힌다. AI가 만드는 코드도 사람이 만든 코드와 똑같이 리뷰하고 스캔해야 한다.

둘째, 기계 아이덴티티의 폭발적 증가다. 마이크로서비스, 서버리스, 컨테이너. 서비스 하나 배포할 때마다 서비스 계정이 생기고 API 키가 생기고 토큰이 생긴다. 클라우드 환경에서 이런 기계 아이덴티티가 사람 아이덴티티의 10배에서 50배에 달한다는 통계가 있다.

사람한테는 MFA 걸고, 90일마다 비밀번호 바꾸게 하고, 접근 로그 감사한다. 그런데 서비스 계정은? API 키는? 만료 기한 없이 발급해서 환경변수에 박아놓고 잊어버린다. 퇴사자가 만든 키가 2년째 운영 환경에서 돌아가고 있어도 아무도 모른다. 2024년 쿠팡 사고의 한 축이 바로 이거였다. 내부자가 인증 시스템 개발 권한을 악용했는데, 그 권한 자체가 과도했고 모니터링도 안 되고 있었다.

원문의 Zero Trust 원칙을 여기에 적용하면 답이 나온다. 기계 아이덴티티도 사람처럼 관리해라. 최소 권한 원칙, 주기적 로테이션, 접근 로그 모니터링, 미사용 크레덴셜 비활성화. 말은 쉬운데 실행이 어렵다. 일단 뭐가 있는지부터 파악이 안 되니까. 여기서부터 시작해야 한다.

상상력과 영감을 믿자

원문의 이 섹션을 그대로 인용하고 싶다. “보안이라 하면 딱딱하고 내 일이 아니고 성가시고 가급적 피해야 할 일인가? 상당히 많은 사람이 그러한 감정을 느낀다. 그러나 그 감정이 두려움에서 비롯되지 않는지 차분히 생각해보자.”

2026년에도 이 말이 유효하다. 아니, 더 중요해졌다. 보안 위협이 복잡해질수록 체크리스트로는 대응이 안 된다. 공격자가 어떻게 들어올지 상상하고, 창의적으로 막아야 한다.

원문에서 ssh 접속이 필요한 이유를 질문하라고 했다. “장애시 문제 진단을 하러 접근하는 경우가 99%인가? 그렇다면 로그 분석 등 모니터링 체계를 제대로 갖추기만 해도 대부분의 문제가 해결되지 않는가?”

2026년 버전으로 바꾸면 이렇다. 이 API 키가 필요한 이유는 뭔가? 만료 기한 없이 발급된 이유는? 이 서비스 계정에 admin 권한이 있어야 하는 이유는? 이 시크릿이 코드 저장소에 있어야 하는 이유는?

질문을 던지면 대부분 “원래 그렇게 해왔으니까”라는 답이 돌아온다. 그게 바로 바꿔야 할 지점이다.

원문에서 VPN 대신 AppStream을 쓰면 어떠냐고 제안했다. 2026년에는 선택지가 더 많다. Cloudflare Access, Tailscale, Twingate. 발상을 바꾸면 도구는 넘친다. 문제는 발상을 바꾸는 거다.

상부상조하자

원문의 마지막 메시지다. “개발 조직과 보안 조직은 한 몸일 수 없다. 전자는 본질적으로 수행 조직이고 후자는 감사 조직이기 때문이다. 그러나 그런 까닭에 서로를 존중하고 함께 임무를 수행해야 한다.”

6년이 지나도 이게 가장 어렵다. DevSecOps라는 말은 널리 퍼졌는데, 실제로 개발팀과 보안팀이 협력하는 조직은 드물다. 보안팀은 여전히 “안 돼”라고 말하는 조직이고, 개발팀은 보안을 우회할 방법을 찾는다.

원문에서 말한 대로다. “서로가 서로를 경멸하는 곳에선 기만이 성행하며 진정한 성취보다는 일신의 안전과 편의만을 쫓는다.”

바꾸려면 구조를 바꿔야 한다. 보안팀이 “감사하고 지적하는 조직”에서 “개발팀의 생산성을 높여주는 조직”으로 포지셔닝을 바꿔야 한다. 보안 스캔 자동화해서 개발자가 PR 단계에서 취약점 알 수 있게 해주고, 권한 신청 프로세스 간소화해서 기안서 쓰는 시간 줄여주고, 인시던트 대응 플레이북 만들어서 장애 때 헤매지 않게 해주고.

개발팀도 마찬가지다. 보안팀이 요청하는 로그 포맷, 접근 제어 인터페이스, 감사 추적 기능을 “귀찮은 추가 작업”이 아니라 “제품의 일부”로 받아들여야 한다. Kubernetes 도입하면서 보안팀한테 알리지도 않고, 나중에 컴플라이언스 감사에서 터지는 조직이 아직도 있다.

OWASP Seoul 운영하면서 느끼는 건, 보안과 개발 사이의 벽을 허무는 게 기술 문제가 아니라 문화 문제라는 거다. 도구는 이미 충분하다. 서로 이야기하고, 서로의 고충을 이해하고, 같이 해결책을 찾으려는 의지가 필요하다.

한국적 맥락

원문은 글로벌 스탠다드를 기준으로 썼다. 한국에서 이걸 그대로 적용하려면 부딪히는 벽이 있다.

ISMS 인증 체계가 “체크리스트 컴플라이언스” 문화를 만들었다. 규정에 있는 항목은 지키고, 없는 건 신경 안 쓴다. Zero Trust 아키텍처? ISMS 항목에 없다. 기계 아이덴티티 관리? 명시적으로 없다. 공급망 보안? 최근에야 조금씩 들어가기 시작했다.

그 결과, 글로벌 기준에서는 기본인 것들이 한국에서는 “과한 보안”으로 치부된다. 글로벌 고객을 상대하는 한국 회사들이 SOC 2 인증 받으려다 멘붕 오는 이유다. 평소에 하던 것들이 SOC 2 기준에서는 한참 부족하니까.

규제가 바뀔 때까지 기다리면 몇 년이 걸릴지 모른다. 스스로 글로벌 스탠다드에 맞추는 게 현실적이다. ISMS는 한국 시장에서 영업하는 데 필요한 최소 기준이고, 실제 보안은 그 위에 별도로 쌓아야 한다.

마무리하며

원문 저자가 말했듯이, “현대적 보안은 잘 정리된 이론은 아니다. 이것은 개인적 경험에 바탕을 둔 조언에 가깝다.”

2026년 버전도 마찬가지다. 6년 사이에 클라우드 네이티브가 기본값이 됐고, AI가 일상이 됐고, 공급망 공격이 현실화됐다. 그런데 핵심 원칙은 변하지 않았다.

누구도 믿지 마라. 검증하고 모니터링해라. 동기화된 실패를 피해라. 편의를 위해 모든 걸 통합하지 마라. SaaS를 활용하되 공급망 리스크를 관리해라. 권한보다 합의와 시스템으로 접근해라. 상상력을 발휘해라. 개발과 보안이 협력해라.

이 원칙들을 2026년의 기술 스택에 적용하면 “현대적 보안”이 된다. 체크리스트가 아니라 사고방식이다. 도구가 아니라 문화다.

원문의 마지막 문장을 빌려 마무리한다. “적어도 이 글이 보안이란 문제와 그 주변여건에 대해 한번 더 고민하는 계기가 되길 바란다.”

이 글은 최재훈님의 “현대적 보안”(2020)을 기반으로 2026년 관점에서 재해석해본 것입니다.

Ben DH Kim – Notes from Building Cyber Security Startup