Log4j 긴급 패치와 후속 대응 기록
2021년 12월 Log4j 취약점이 알려졌을 때는 연차 중이었습니다. 평소라면 정기 배포 일정에 맞춰 변경을 검증했겠지만, 이번에는 영향을 받는 서비스를 확인하고 긴급 대응을 진행해야 했습니다.
여러 서비스가 공통 라이브러리를 사용하고 있어 한 서비스의 수정만으로 대응을 끝낼 수 없었습니다. 수정 대상과 적용 상태를 모아 보고, 정기 일정 밖에서 테스트와 배포를 진행했습니다.
취약점과 영향 범위
CVE-2021-44228은 Log4j의 JNDI lookup을 통해 공격자가 제어하는 입력이 코드 실행으로 이어질 수 있었던 취약점입니다. Apache 보안 문서에서는 이 취약점의 대상 컴포넌트를 log4j-core로 구분합니다. Log4j라는 이름이 들어 있다는 이유만으로 모든 관련 라이브러리를 같은 영향으로 볼 수는 없습니다.
서비스별로 사용하는 의존성과 실제로 배포된 파일을 확인해야 했습니다. 공통 라이브러리의 버전을 바꾸더라도 각 서비스가 새 버전을 포함해 빌드·배포되기 전에는 운영 환경에 반영되지 않습니다.
12월 10일의 긴급 대응
당시에는 영향을 받는 서비스 전반을 같은 대응 범위로 묶어 패치했습니다. 일부 서비스만 조치하고 나머지를 다음 정기 배포까지 남겨 두지 않으려는 판단이었습니다.
이것이 모든 서비스의 모든 배포 단계를 한순간에 바꿔야 한다는 뜻은 아닙니다. 어느 서비스가 검증 중인지, 적용됐는지, 추가 조치가 남았는지를 함께 관리하는 것이 필요했습니다.
미국 팀과의 시차도 있었습니다. 초기에 로컬에서 조치를 먼저 진행하고, 미국 쪽 업무가 시작된 뒤 진행 상황을 공유했습니다. 대응 중에는 완료된 변경뿐 아니라 아직 확인해야 할 대상도 함께 전달해야 했습니다.
배포 채널의 활용
평소 정기 배포에 사용하던 채널에서 수정과 검증, 적용 상태를 공유했습니다. 새로운 연락 경로를 만드는 대신 기존 배포 흐름을 사용하면서 일정과 우선순위를 바꿨습니다.
긴급 대응 중에도 “수정 완료”, “빌드 완료”, “운영 반영”은 다른 상태입니다. 서비스별로 어디까지 진행됐는지 구분할 수 있어야 다음 확인을 이어받을 수 있습니다.
12월 14일의 후속 패치
첫 조치 뒤에도 추가 패치가 필요해 12월 14일 다시 대응했습니다. 처음 적용한 버전으로 끝내지 않고 새로 확인된 내용에 따라 대상과 조치를 다시 살펴봐야 했습니다.
Apache의 보안 이력에도 최초 취약점의 수정 이후 후속 문제가 이어진 과정이 남아 있습니다. 당시의 대응 버전을 지금 설치 기준으로 그대로 사용하기보다, 현재 지원하는 Java·Log4j 버전과 보안 권고에 맞춰 판단해야 합니다.
적용 확인과 대응 기록
보안 패치는 수정 커밋이 있다는 사실만으로 완료되지 않습니다. 운영 중인 프로세스와 배포 파일에 변경이 반영됐는지 확인하고, 적용하지 못한 대상이 있다면 그 상태를 남겨야 합니다.
이번 대응에서도 서비스의 영향 범위와 배포 상태를 함께 보는 일이 필요했습니다. 평소 배포할 때 사용하던 검증·공유 과정은 유지하되, 정기 일정까지 기다릴 수 없는 변경을 우선 처리한 경험이었습니다.
다음 글에서는 정기 배포의 검증 단계와 일정 조율을 정리합니다.