Log4Shell 이후, 소프트웨어 공급망을 신뢰하는 방법은 완전히 바뀌었다

왜 지금 이게 문제인가 2021년 12월 Log4Shell(CVE-2021-44228)이 터졌을 때, 전 세계 보안팀이 가장 먼저 한 일은 “우리 시스템에 Log4j가 어디에 들어가 있는지” 파악하는 것이었다. 그리고 대부분 실패했다. 직접 의존성에는 없더라도, 3단계·4단계 전이 의존성(transitive dependency) 깊숙이 박혀 있는 Log4j를 찾아내는 것은 사실상 불가능했다. 이 사건은 단순한 취약점 하나가 아니라, 소프트웨어 공급망 전체의 투명성 부재를 드러냈다. 우리가 빌드하고 배포하는 아티팩트에 정확히 무엇이 포함되어 있는지, 누가 빌드했는지, 빌드 프로세스가 변조되지 않았는지—이 기본적인 질문에 답할 수 없었다. ...

September 25, 2025 · 4 min · 817 words · gnosyslambda

kube-scheduler의 속을 열어보면: 당신의 Pod는 어떻게 그 노드에 배치됐는가

왜 지금 이게 문제인가 “Pod가 Pending 상태로 멈춰 있습니다.” Kubernetes를 운영하는 팀이라면 한 번쯤 들어본 문장이다. 대부분의 경우 리소스 부족이 원인이지만, 클러스터가 1,000노드를 넘어가고 GPU 워크로드가 섞이기 시작하면 이야기가 완전히 달라진다. 스케줄러가 병목이 되는 것이다. 국내에서 AI 워크로드가 폭증하면서 이 문제는 더 이상 해외 빅테크만의 이야기가 아니다. 네이버 클라우드 HyperCLOVA 학습 클러스터, 카카오 클라우드의 GPU 인스턴스 풀, 그리고 수많은 스타트업의 A100/H100 클러스터에서 스케줄러 성능은 인프라 비용과 직결된다. GPU 한 장이 시간당 수만 원인 환경에서 스케줄링 지연 10초는 곧 돈이다. ...

July 22, 2025 · 4 min · 766 words · gnosyslambda