보안은 보안 담당자가 알아서 챙기는 영역이라고 생각했던 때가 있었습니다. 저도 처음에는 기능이 잘 작동하고 화면이 문제없이 보이면 충분하다고 봤습니다. 하지만 로그인, 입력값, API, 데이터베이스, 클라우드 설정을 하나씩 살펴보면서 보안은 모든 IT 직무와 연결된다는 것을 알게 됐습니다. 프런트엔드의 입력값 검증, 백엔드의 권한 처리, 데이터 직무의 개인정보 관리, 클라우드의 IAM 설정 모두 서비스 신뢰와 직결됩니다. 저는 보안을 나중에 붙이는 기능이 아니라 처음 설계부터 함께 고민해야 하는 기본 기준이라고 생각합니다. 이 글에서는 그 이유를 제 경험과 함께 정리해 보겠습니다.
IT 보안이 “내 직무와 무관하다 “는 착각
IT 취업을 준비할 때 보안을 별도 트랙으로만 바라보는 시각이 꽤 흔합니다. 정보보안 엔지니어나 모의해킹 전문가처럼 보안을 직무명으로 달고 있는 사람에게나 필요한 지식이라는 인식이죠.
제가 처음 개발 공부를 시작했을 때도 그랬습니다. 백엔드 기능이 돌아가는지, 프런트엔드 화면이 제대로 렌더링 되는지에만 집중했고, 보안은 나중에 전문가가 붙여주는 것이라고 생각했습니다. 그 생각이 얼마나 위험한 출발점인지는 한참 뒤에야 실감했습니다.
실제 IT 서비스는 단일 직무가 독립적으로 완결되지 않습니다. 사용자가 로그인 폼에 아이디와 비밀번호를 입력하는 순간부터 그 데이터는 프런트엔드를 거쳐 백엔드로 전달되고, 데이터베이스에 저장되며, 클라우드 인프라 위에서 동작합니다. 이 흐름 중 어느 한 지점이라도 허술하면 IT 보안 전체가 흔들립니다.
각 직무가 자신의 영역에서 최소한으로 알아야 할 보안 기초를 정리하면 다음과 같습니다.
- 프런트엔드 개발자: 입력값 검증, XSS(크로스 사이트 스크립팅) 방어, 인증 토큰 저장 위치
- 백엔드 개발자: 비밀번호 해싱, SQL Injection 방어, API 접근 제어, 권한 분리
- 데이터 직무: 개인정보 비식별화, 접근 권한 최소화, 데이터 보관 기준
- 클라우드·인프라 직무: IAM 권한 설정, 보안 그룹, 네트워크 분리, 로그 모니터링
- QA 직무: 비정상 입력 테스트, 권한 우회 시나리오 검증, 오류 메시지 노출 여부 확인
- 기획·PM 직무: 정보 수집 범위 정의, 권한 정책 설계, 개인정보 처리 흐름 검토
OWASP Top 10은 웹 애플리케이션에서 가장 빈번하게 발생하는 보안 취약점을 순위별로 정리한 문서입니다. 여기서 OWASP란 Open Worldwide Application Security Project의 약자로, 소프트웨어 보안 개선을 목적으로 운영되는 비영리 재단입니다. 이 문서가 보안 전문가용이 아니라 웹 개발자 일반을 대상으로 제작되었다는 점이 시사하는 바가 큽니다(출처: OWASP).
직무별 보안 연결이 서비스 신뢰를 만드는 방식
IT 보안이 중요한 이유를 “해킹을 막기 위해서 “라고만 생각하면 절반만 맞습니다. 보안은 사용자가 서비스를 안심하고 쓸 수 있는 조건을 만드는 작업입니다. 기능이 아무리 뛰어나도 개인정보가 한 번 유출되면 서비스 신뢰는 단기간에 무너집니다.
XSS(Cross-Site Scripting)는 공격자가 악성 스크립트를 웹 페이지에 삽입해 다른 사용자의 브라우저에서 실행되도록 하는 공격 방식입니다. 쉽게 말해 댓글창이나 검색창에 악의적인 코드를 넣어 다른 사람의 로그인 정보를 훔쳐가는 수법입니다. 프런트엔드 개발자가 입력값 검증을 소홀히 하면 이 공격의 통로가 열립니다. 저는 이 개념을 처음 접했을 때 “나는 화면만 만드는데 이게 내 문제인가 “라고 생각했는데, 실제로는 프런트엔드가 가장 먼저 막아야 할 관문이었습니다.
백엔드에서는 SQL Injection이 대표적인 위협입니다. SQL Injection이란 공격자가 데이터베이스 쿼리에 악의적인 명령어를 삽입해 데이터를 무단으로 조회하거나 삭제하는 공격입니다. 쿼리를 작성할 때 사용자 입력값을 직접 문자열로 이어 붙이면 이 공격에 노출됩니다. 제 경험상 이 부분은 처음에는 이론으로만 이해하다가 실제 코드를 짜보고 나서야 위험성이 피부로 와닿았습니다.
클라우드 환경에서는 IAM(Identity and Access Management) 권한 설정이 핵심입니다. IAM이란 클라우드 리소스에 접근할 수 있는 사용자와 권한 범위를 관리하는 시스템입니다. 모든 계정에 관리자 권한을 주는 설정은 편리하지만, 한 계정이 탈취되면 전체 인프라가 위험해집니다. 최소 권한 원칙, 즉 필요한 권한만 부여하는 방식이 IT 보안의 기본 설계 원칙입니다.
데이터 직무도 예외가 아닙니다. 개인 식별 정보가 포함된 데이터를 분석 목적으로 그대로 사용하다가 문제가 된 사례는 국내외에 적지 않습니다. “이 데이터에 개인 식별 정보가 포함되어 있나요? “라고 먼저 확인하는 습관이 데이터 직무에서의 보안 출발점이라고 생각합니다.
보안 설계 원칙을 처음부터 적용해야 하는 이유
“기능을 먼저 만들고 보안은 나중에 붙이면 된다 “는 생각은 IT 서비스 개발에서 가장 위험한 착각 중 하나입니다. 서비스 규모가 커지고 사용자가 늘어난 뒤에 인증 구조나 권한 정책을 뜯어고치려면 코드 전체를 다시 설계해야 할 수도 있습니다. 솔직히 이건 예상 밖의 비용과 시간이 드는 일입니다.
CISA(미국 사이버보안 및 인프라 보안국)의 Secure by Design 원칙은 소프트웨어 보안을 개발 마지막 단계의 점검 항목이 아니라 설계 초기부터 내재화해야 하는 기준으로 정의합니다. 여기서 Secure by Design이란 보안 기능을 외부에서 덧붙이는 방식이 아니라 제품 설계 단계부터 보안 요구사항을 구조 안에 녹여 넣는 접근 방식입니다(출처: CISA).
제가 직접 경험해 보니 이 원칙은 거창한 이야기가 아닙니다. 처음 API를 설계할 때 “이 엔드포인트는 누가 호출할 수 있어야 하는가 “를 먼저 정의하는 것, 로그인 기능을 만들 때 비밀번호를 평문이 아닌 해싱 처리된 형태로 저장하는 것처럼 아주 작은 질문과 습관에서 시작됩니다.
NIST Cybersecurity Framework 2.0은 사이버보안을 식별, 보호, 탐지, 대응, 복구, 거버넌스의 6개 기능으로 체계화한 프레임워크입니다. 여기서 거버넌스란 보안을 특정 팀의 책임으로 한정하지 않고 조직 전체의 운영 기준으로 삼는 관리 체계를 의미합니다. 이 관점에서 보면 보안은 보안 팀이 단독으로 책임지는 영역이 아니라 모든 IT 직무가 자신의 자리에서 함께 지켜야 하는 서비스의 기본 체력입니다.
처음부터 보안을 고려하면 협업도 훨씬 쉬워집니다. 개발자가 “이 API는 어떤 권한 기준으로 막아야 하나요? “라고 묻거나, 기획자가 “이 화면에 민감 정보를 노출해도 괜찮은가요? “라고 확인하는 문화가 자리 잡히면, 나중에 대규모로 수정해야 하는 상황을 상당 부분 줄일 수 있습니다.
보안을 어렵고 멀리 있는 개념으로 느끼는 분들에게 한 가지를 권하고 싶습니다. 지금 작성 중인 코드, 지금 다루고 있는 데이터, 지금 설정 중인 서버가 어떤 위험을 가질 수 있는지 딱 한 번만 더 질문해 보는 것입니다. 그 질문 하나가 서비스 신뢰를 지키는 출발점이 됩니다.