보안 엔지니어

보안은 모두의 일이라고 정해 두면 대개 아무의 일도 되지 않습니다. 기능 마감이 있는 주에 점검을 미루는 결정은 누구에게나 합리적으로 보이고, 그 결정이 스무 번 반복되면 아무도 본 적 없는 코드가 운영 환경에서 돌아갑니다.

페이지덱이 구성원 마흔다섯 명이던 때 그 자리에 닿았습니다. 기업 고객 한 곳이 계약 전에 보안 검토 질문지를 보냈는데 항목이 200개였습니다. 접근 권한을 어떻게 나누는지, 저장된 데이터를 무엇으로 암호화하는지, 침해가 나면 몇 시간 안에 알리는지 같은 질문이었습니다. 태오가 이틀을 붙잡고 답을 채웠지만 절반은 답을 모르는 항목이었습니다. 모른다는 것이 문제의 절반이고, 그 절반을 알아볼 사람이 없다는 것이 나머지 절반이었습니다.

규원이 첫 보안 엔지니어를 뽑았습니다. 전담이 생기면서 달라진 것은 점검 항목이 늘어난 것이 아니라 점검이 일정 안에 자리를 갖게 된 것이었습니다. 미룰지 말지를 매주 판단하지 않게 됐습니다.

하루는 이미 벌어진 일과 벌어질 일 사이에서 나뉩니다. 다섯 가지가 반복됩니다.

1. 취약점 점검 — 직접 쓴 코드와 가져다 쓴 외부 코드를 모두 봅니다. 자동 검사가 목록을 만들어 주고, 사람이 그중 실제로 위험한 것을 골라냅니다. 자동 검사가 내놓는 항목은 대부분 우리 환경에서는 문제가 되지 않아서, 고르는 일이 실제 작업입니다.
2. 침해 흔적 확인 — 접근 기록과 실패한 로그인 시도를 봅니다. 새벽 3시에 한 계정이 다른 나라에서 접속한 기록처럼 평소와 다른 패턴을 찾습니다. 여기서는 빠르게 판단하고 필요하면 그 계정을 먼저 막습니다. 원인을 다 밝힌 뒤에 막으면 그사이에 일이 더 벌어집니다.
3. 설계 검토 — 새 기능이 만들어지기 전에 권한 모델을 봅니다. 외부 협력사에게 특정 문서만 열어 주는 기능을 만든다면, 누가 무엇에 닿을 수 있고 그 경계가 어디서 무너질 수 있는지를 만들기 전에 짚습니다. 만든 뒤에 고치는 것보다 훨씬 쌉니다.
4. 접근 권한 정리 — 누가 무엇에 닿을 수 있는지를 주기적으로 훑습니다. 실무에서 가장 많이 나오는 문제는 공격이 아니라 퇴사자의 계정이 살아 있거나 임시로 준 권한이 반년째 남아 있는 것입니다.
5. 대외 응답 — 고객이 보내는 보안 질문지에 답하고 필요한 인증 절차를 준비합니다. 이 일은 계약 일정에 직접 걸리므로 급한 순서에서 앞으로 나옵니다.

시간 배분이 이 역할의 어려운 지점입니다. 터진 일에만 붙어 있으면 같은 종류의 일이 계속 터집니다. 급한 대응과 구조를 고치는 일의 비율을 정해 두고, 대응에 쓴 시간을 기록해 두는 팀이 이 함정을 덜 겪습니다.

혼자 막을 수 없는 일이라 대부분의 시간이 다른 역할과의 대화입니다. 넷이 주로 붙습니다.

1. 백엔드 개발자 — 서버와 데이터 처리 쪽을 만드는 개발자입니다. 권한을 어디서 판정할지, 어떤 값을 암호화해 저장할지를 함께 정합니다. 가장 자주 만나는 상대입니다.
2. 데브옵스 엔지니어와 SRE — 배포와 운영 자동화를 맡는 쪽과 서비스 안정성을 공학적으로 관리하는 쪽입니다. 서버에 누가 접속할 수 있는지, 비밀 키를 어디에 두는지가 이들의 영역과 겹칩니다.
3. QA 엔지니어 — 품질을 검증하고 테스트 체계를 만드는 쪽입니다. 보안 점검 항목을 테스트 목록에 넣어 두면 사람이 매번 확인하지 않아도 됩니다.
4. 세일즈와 법무 — 고객 질문지와 규제 대응이 이쪽에서 들어옵니다. 수아가 계약 앞에서 받은 질문을 그대로 넘기고, 답이 아니라 확인이 필요한 항목은 함께 고객에게 되묻습니다. 규제 쪽 질문은 근거 문서가 함께 필요해서 준비 기간을 따로 잡습니다.

관계의 성격이 성과를 가릅니다. 막는 사람으로 보이기 시작하면 개발자들은 검토를 우회하는 경로를 찾습니다. 그래서 답을 빨리 주는 쪽이 중요합니다. 하루 안에 답이 오는 검토는 사람들이 먼저 찾아오고, 사흘 걸리는 검토는 건너뛰어집니다.

"이 기능 설계 리뷰에 보안 엔지니어 넣어 주세요. 권한 경계가 바뀝니다."

만들기 전에 검토를 받자는 제안입니다.

"퇴사자 계정이 아직 살아 있어요. 권한 정리 주기를 줄입시다."

공격보다 흔한 문제를 짚는 말입니다.

"그 질문지 절반은 우리가 답을 모르는 항목입니다."

점검 체계가 없어 대외 응답이 막혔다는 보고입니다.

페이지덱의 보안 엔지니어가 첫 달에 한 일은 질문지에 답하는 것이 아니라 답할 수 있는 상태를 만드는 것이었습니다. 접근 권한 목록을 만들고, 암호화하지 않고 저장된 항목을 찾아내고, 침해가 났을 때 누가 무엇을 하는지 한 장으로 적었습니다.

두 번째 달에 같은 질문지를 다시 받았을 때는 하루 만에 채웠습니다. 태오가 이틀을 쓰던 일이 그렇게 줄었고, 그보다 중요한 것은 모르는 항목이 열두 개로 줄었다는 점이었습니다. 그 열두 개가 다음 분기 작업 목록이 됐습니다.

이 역할을 뽑으면 보안이 해결된다고 보는 경우가 가장 많습니다. 전담이 생기니 그렇게 느껴집니다. 하지만 코드를 쓰는 사람은 여전히 개발자들이고, 한 사람이 스무 명이 만드는 것을 다 볼 수는 없습니다. 이 역할이 하는 일은 직접 막는 것이 아니라 막히는 구조를 만드는 것입니다. 해결됐다고 보면 다른 개발자들이 보안을 자기 일에서 지우고, 그때부터 한 사람이 병목이 됩니다.

출시 전 점검 단계라고 보는 것도 흔합니다. 다 만든 뒤에 통과 여부를 받는 절차로 다루기 쉽습니다. 그런데 권한 모델이 잘못된 것을 출시 직전에 알면 고치는 데 몇 주가 듭니다. 같은 문제를 설계 단계에서 짚으면 대화 한 번으로 끝납니다. 점검 단계로만 두면 그 역할은 일정을 막는 사람이 되고, 일정을 막는 사람은 다음부터 회의에 불리지 않습니다.