💡
본 글은 Security Career re:Boot 2025 참석 회고 입니다. 멘토링 세선을 들으면서 한 고민과 깨달음에 대해서 기록하였습니다. 세션의 내용을 기록하고 공유하는 것이 목적이 아닌 점을 말씀 드립니다.
🚩
멘토링 이후 2주간 요기요, Flex 등에서 기술 면접을 보게 되었습니다. 멘토링과 기술 면접에서 공통되게 느낀 반성하게 되는 부분이 많습니다. 이런 부분은 깃발(🚩)을 통해 기록하였습니다.
A. 행사 소개
Security Career re:Boot 2025는 보안 업계의 주니어를 위한 멘토링 행사입니다.
보안 업계에서 다양한 역할로 활동하시는 세 분의 멘토님의 이야기를 들었습니다.
Security Career re:Boot 2024[1]에 이어 2번째로 진행된 행사로서
AWS Security Specialist 신은수님의 링크드인[2]을 통해 신청하게 되었습니다.
A.1. 참여 목적
2025년 첫 목표로 Kubestronaut으로 설정하고 CKS를 준비하게 되면서,
Security Engineer 분들이 하고 계시는 보안이 정확히 무엇을 의미하는지
그리고 DevOps Engineer가 바라볼 수 있는 보안은 어떤 것들이 있을지
학문적인 호기심이 생겨서 멘토링을 신청하게 되었습니다.
A.2. 발표 세션
클라우드 보안을 위한 준비와 전략 - 신은수 멘토님, Security Sepcialist SA, AWS
보안커리어 관리전략과 AI - 문광석 멘토님, IT 보안 파트, 코리안리 (LG CNS 보안컨설팅)
DevSecOps 톺아보기 - 김동현 멘토님, CEO, Cremit Inc. (전 샌드버드)
B. 회고
Security Engineer가 어떤 일을 하고 어떤 것을 배우는지를 보며
DevOps Engineer의 역할과 기본에 대해서 반성하고 고민할 계기가 되었습니다.
바쁜 와중에도 주말에 긴 시간 내주신 멘토님들과
많은 질문으로 고민을 나눠주신 같은 멘티님들에게 감사한 시간이었습니다.
식단을 하고 있어서 제공해주신 치킨, 피자를 많이 먹지 않고 왔는데…
집가니까 바로 생각이 나면서 엄청나게 후회를 했습니다. ㅠㅠㅠㅠ…
역시 먹을 기회 있을떄 먹어야 하는….
B.1. 마음가짐에 대한 반성
엔지니어의 범용성과 전문성에 대해서 고민할 수 있는 시간이었습니다.
예전부터 근래까지는 DevOps Roadmap[3]이나 채용 공고들을 확인하면서
“이걸 전부다 다 할 수 있는 사람이 있나?”와 같은 도피성 생각을 많이 했습니다.
하지만 멘토링을 들으면서 아래와 같은 생각을 고민하게 되었습니다.
스스로 이런 기술들을 배우지 않고 몇 줄의 설명으로 판단한 적이 없는가?
스스로 이런 기술들이 필요한 시점을 고민하고 공감하려 노력한 적이 있는가?
트레이드 오프(trade-off)란 핑계에 숨어 어려움을 피한 적은 없는가?
🚩
임금체불로 이직을 결정하게 되었는데, 경력 기술서(이력서)를 좋게 봐주신 덕에 여러 곳의 면접을 볼 수 있었습니다. 역시나 멘토링 세션에서 '아차' 했던 부분들을 면접에서도 그래도 느꼈습니다.
범용성 측면에서 로그/모니터링 분야를 제대로 배우지 않는 점이 후회되었습니다.
전문성 측면에서 IaC, K8s 등을 정확히 끝까지 파지 않는 부분들이 후회되었습니다.
근본적으로 그런 상황들을 야기한 핑계들을 많이 후회하게 되었습니다.
B.2. 기반 기술에 대한 생각들
한 멘티 분께서 지원자 채용의 선별 기준에 대해서 여쭤보셨습니다.
이 질문에 대해서 다양한 답변 중에서 신은수 멘토님의 답변이 기억에 남습니다.
회사에서 SSO 업무를 했다고 쓰면 “SAML과 OIDC의 차이점을 설명해주세요”라고 물어봅니다. 이때, 대답하지 못한다면 SSO를 써봤을 뿐 그 매커니즘을 모르는 거잖아요.
이력서를 작성하면 다양한 키워드를 적게 되고
대다수 기술 면접은 이런 키워드들에서 시작된 꼬리물기 질문을 받게 됩니다.
이런 시간들로 지원자의 기반 기술 이해도를 검증하는 시간들을 가지게 됩니다.
🚩
1차적으로 기술 면접을 많이 준비하지 못한 것도 문제였으나, 근본적으로 기반 기술을 대하는 태도에 결함이 있다고 생각합니다. 예를 들어, "쿠버네티스의 네트워크 흐름은 어떤 경로로 흘러갈까요?"는 알아도 "aws-vpc-cni Prefix Mode에서 aws-load-balancer-controller IP Mode"에서 네트워크 흐름은 어떤 경로로 진행되는가?는 설명하기 어렵습니다. 이런 기술적인 결정에서 가설, 검증, 기록, 복기의 과정을 더 해야할 것 같습니다.
B.3. DevSecOps에 대한 생각
저는 가장 궁금했던 DevSecOps 문화의 첫 발걸음을 물어봤습니다.
궁극적인 궁금증은 문화라고 하는 것이 무엇인가?의 의문이기도 했습니다.
첫 답변으로 김동현 멘토님의 말씀이 기억에 남습니다.
문화를 만들어가려면 기분이 좋은 것들이 만들어져야 합니다.
“이것을 했더니 속도도 빨라지고 더 안전해졌다.” 와 같은 성공 사례를 만드는 것이 중요합니다. 따라서 첫 단추로서 성공사례를 어떻게 만들지 고민할 것 같다.
경력 기술서에 작성한 FinOps 문화에 대해 고민을 많이 했습니다.
과연 우리의 성공사례가 무엇이었는지 묻는다면 대답하기 어려운 것 같습니다.
🚩
문화라고 기록하였으나 "어떤 기술로 무엇을 해결했다"가 다수였습니다. 전 직장에서 8개월 동안 비용 절감 업무를 수행했습니다. 이 과정에서 피크 대비 월 70% 비용을 절감할 수 있었습니다. 이를 위해 분류, 시각화, 최적화, 마이그레이션, 팀 구성을 하였습니다. 면접장에 들어가기 전까지 이런 행위들이 FinOps를 이룬다고 생각했습니다. 하지만 결국 두 가지 질문의 답을 재직 기간 동안 찾지 못했습니다. 1. 지속가능한 문화란 무엇인가? 2. 조직과 팀의 동기부여를 위해서 무엇을 하였는가?
같은 질문에 문광석 멘토님의 답변은 직관적으로 다가왔습니다.
많은 내용들을 말씀해주셨지만 핵심적인 내용만 요약하면 다음과 같습니다.
무언가를 바꾼다면 그것으로 더욱 편리해져야만 한다.
DevSecOps를 예시로 들면 보안 취약점은 가장 빠른 시점에 감지되어야 한다.
그리고 감지와 동시에 어떻게 바꿔야 하는지도 친절하게 알려줄 수 있어야 한다.
개발자가 이를 손쉽게 조치할 수 있어야 한다.
작년 7월, 보안 사고가 발생했고 이를 확인 및 검토하는 과정에서
다량의 IAM Credential이 식별되었으며 Vault Radar[4]으로 집계했습니다.
이후 Vault Radar PR Check을 통해서 커밋 레벨에서 키 감지가 가능해졌습니다.
하지만
근본적으로 IAM Credential이 필요없는 편리한 개발 환경은 구축하지 못했습니다.
또한 이미 기록된 Hash를 지우거나 IAM Credentials을 자동으로 로테이션하는 가이드도 부족했던 것 같습니다. 이런 방향에 대해서 스스로 더 많은 길을 찾으면 좋을 것 같습니다.
B.4. Hardening & Next Step에 대한 생각
Admission Controller, Security Standard, Security Context 부터
SecComp, AppArmor, SELinux까지 너무 다양한 보안 강화가 존재합니다.
특히 CKS를 준비하면서 광범위하고 많은 분야의 보안 강화를 실습하게 되었습니다.
그리고 “이게 정말로 뭐가 막아지기는 하는 거야?”라는 생각에 도착했습니다.
Happy Hour*을 통해서 이런 종류의 질문을 김동현 멘토님께 드렸습니다.
“다양한 기법들이 존재하는데, 이것들이 정말로 작동을 잘하는지 어떻게 알 수 있을까요? 그리고 이것들 다음에는 무슨 조치들을 해야하는 걸까요?”
Happy Hour* : 식후 멘토님 1분과 멘티 N명이 편하게 의사소통을 나누는 자리
김동현 멘토님께서는 Hardening과 Runtime Audit에 대해서 말씀해주셨습니다.
보안 강화(Hardening)은 대부분 단발성 작업들이다.
이는 한 번 구축하고 자동화한다면 추가적인 작업이 필요 없다.
지속가능한 작업이 존재하며 런타임 감사(Runtime Audit) 등이 있다.
이 답변을 듣고 CKS 준비하며 사용한 falco[5]가 생각이 났습니다.
Falco를 사용하면 컨테이너 런타임의 Linux Kernel 이벤트 모니터링이 가능합니다.
즉, SecComp 등으로 권한 분리를 했을때 권한이 없는 작업을 하는 것을 감지할 수 있습니다.
결국,
Runtime Audit이라는 것의 핵심도
어떤 이벤트의 관측가능성을 끌어올리는 일이라고 느꼈으며
로그 & 모니터링 시스템의 본질과 크게 다르지 않다고 느꼈던 것 같습니다.
(자동으로 확장되듯이 자동으로 격리가 된다면 그 또한 완벽하다…)
