며칠 전, Node.js를 설치한 뒤 실행하려 했는데 이런 메시지가 딱 뜨는 거예요.
node: /lib64/libm.so.6: version `GLIBC_2.27' not found
순간 당황했죠. ‘어라? 이게 뭐지?’ 하고 검색해보니까 꽤 많은 분들이 비슷한 상황을 겪고 있더라고요. 특히 CentOS 7이나 그 이하 버전을 쓰는 분들이요. 결국 꽤 고생해서 해결했는데요—이 글에서 그 과정을 모두 공유해볼게요. 혹시 저처럼 고생하는 분들이 있다면, 이 글이 도움이 되셨으면 좋겠어요.
문제 원인과 확인 방법
먼저, 이 오류가 왜 생기는지를 알아야겠죠. 핵심은 GLIBC 버전 불일치예요.
Node.js나 다른 바이너리 프로그램이 GLIBC_2.27
이상을 필요로 하는데, CentOS 7은 기본적으로 GLIBC_2.17
까지만 지원하거든요.
확인은 이렇게 해보면 돼요:
strings /lib64/libc.so.6 | grep GLIBC
이 명령어를 실행하면 현재 시스템에서 지원하는 GLIBC 버전 목록이 쭉 나와요. 저도 해봤더니 GLIBC_2.17
까지만 있더라고요. 그래서 node 실행 시 라이브러리를 찾지 못하고 에러를 뿜는 거죠.
해결방법: glibc 2.28 이상 수동 설치
자, 이제부터는 해결 단계예요. 여기서 중요한 건 시스템 전체를 업그레이드하지 않고 필요한 버전의 glibc만 별도로 설치하는 거예요. 이렇게 하면 안정성도 유지하고, 원하는 프로그램도 쓸 수 있죠.
1. 필요한 패키지 설치
먼저 빌드 도구가 있어야 glibc를 직접 설치할 수 있어요.
yum groupinstall "Development Tools"
yum install -y gcc gcc-c++ kernel-devel
2. glibc 다운로드 및 빌드
GNU 공식 사이트에서 소스 파일을 다운로드해 컴파일하는 방식이에요.
wget http://ftp.gnu.org/gnu/libc/glibc-2.28.tar.gz
tar -xvzf glibc-2.28.tar.gz
cd glibc-2.28
mkdir build
cd build
../configure --prefix=/opt/glibc-2.28
make -j$(nproc)
make install
여기서 --prefix
는 기존 라이브러리를 덮어쓰지 않고 따로 설치하기 위한 옵션이에요. 덕분에 기존 시스템에 영향 없이 사용할 수 있어요.
설치한 glibc 적용하는 방법
이제 설치는 완료했으니, 문제는 node가 새로 설치한 GLIBC를 사용하도록 하는 거예요.
export LD_LIBRARY_PATH=/opt/glibc-2.28/lib:$LD_LIBRARY_PATH
이걸 .bashrc
나 .zshrc
파일에 넣어두면 로그인할 때마다 자동으로 설정돼요.
그리고 node를 실행할 땐 이렇게 실행하면 됩니다:
LD_PRELOAD=/opt/glibc-2.28/lib/libc.so.6 node your_script.js
이제 node가 새 GLIBC를 읽기 때문에 더 이상 오류가 나지 않아요. 저는 이렇게 해서 바로 해결됐어요.
CXXABI 에러가 추가로 뜨는 경우
혹시 다음처럼 CXXABI 관련 오류가 나면?
/lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found
이건 libstdc++
라이브러리 버전이 낮아서 생기는 문제예요. glibc와 비슷하게 GCC를 최신으로 업데이트해야 해결돼요.
GCC 업데이트 요약
wget http://ftp.gnu.org/gnu/gcc/gcc-10.2.0/gcc-10.2.0.tar.gz
tar -xvzf gcc-10.2.0.tar.gz
cd gcc-10.2.0
./contrib/download_prerequisites
mkdir build
cd build
../configure --disable-multilib --enable-languages=c,c++
make -j$(nproc)
make install
/usr/local/lib64
경로가 환경 변수에 잘 포함되어 있어야 하니까 이 부분도 꼭 확인해 주세요.
glibc 설치 후에도 문제가 생긴다면?
모든 과정을 따라 했는데도 GLIBC_2.27 not found
같은 에러가 계속된다면, 몇 가지 추가 확인이 필요해요. 특히 기존의 node
바이너리가 시스템 기본 glibc를 참조하고 있을 가능성이 크거든요.
이럴 땐 아래 방법을 써보세요.
1. 새 GLIBC를 기본으로 잡고 node 실행
/opt/glibc-2.28/lib/ld-2.28.so --library-path /opt/glibc-2.28/lib $(which node)
이렇게 실행하면, node가 직접 새 glibc 라이브러리를 사용해 실행돼요. 저도 이 방법으로 확인했는데 오류 없이 잘 작동했어요.
2. glibc 버전 정상 적용 확인하기
ldd --version
위 명령어로 glibc 버전이 2.28 이상으로 나오면 설정이 잘 된 거예요.
또는 node 실행 후 아래처럼 직접 확인도 가능해요.
strings $(which node) | grep GLIBC

여기서 GLIBC_2.27
, GLIBC_2.28
같은 문구가 나와야 돼요. 없으면 node 자체를 다시 빌드하거나 다른 바이너리를 받아야 할 수도 있어요.
저의 팁 하나 더: nvm 대신 바이너리 직접 설치
저는 원래 nvm(Node Version Manager)으로 node를 설치했었는데, nvm은 glibc 의존성이 꽤 까다롭더라고요. 그래서 이참에 node 공식 홈페이지에서 LTS 버전 바이너리를 직접 내려받아 /opt/node
아래에 설치했어요.
wget https://nodejs.org/dist/v18.20.3/node-v18.20.3-linux-x64.tar.xz
tar -xf node-v18.20.3-linux-x64.tar.xz
mv node-v18.20.3-linux-x64 /opt/node
그리고 환경 변수만 추가했어요:
export PATH=/opt/node/bin:$PATH
이렇게 하면 glibc 버전 충돌도 훨씬 덜하고, 안정적으로 돌아가더라고요. nvm 쓰시는 분들도 한 번쯤 고려해볼 만해요.
꼭 확인할 체크리스트
GLIBC_2.27 이상
이 필요한 바이너리인지 확인했나요?- glibc를 별도 경로(
/opt/glibc-2.28
)에 설치했나요? - LD_LIBRARY_PATH 환경변수 설정했나요?
- node 실행 시 새 glibc 라이브러리를 명시적으로 사용하고 있나요?
- CXXABI 오류가 추가로 발생하지 않나요?
이 체크리스트를 하나하나 따라가면 대부분 문제는 해결될 거예요.
자주 묻는 질문 (FAQ)
Q1. CentOS 7에서 glibc 2.27 이상을 설치하면 시스템이 불안정해지지 않나요?
A1. 네, 그럴 수 있어요. 그래서 기존 시스템 glibc를 교체하지 않고, 별도 경로(/opt/glibc-2.28
)에 병행 설치하는 방식이 안전합니다. 시스템 전역에 영향 없이 특정 프로그램만 새 glibc를 사용하게 할 수 있어요.
Q2. glibc 설치 시 make
오류가 나요. 어떻게 해야 하나요?
A2. Development Tools
패키지가 빠져 있을 수 있어요. 아래 명령어로 설치하고 다시 시도해보세요.
yum groupinstall "Development Tools"
yum install -y gcc gcc-c++ kernel-devel
Q3. glibc를 여러 버전 설치하면 충돌하지 않나요?
A3. 설치 경로를 나눠서 사용하면 충돌은 거의 없습니다. 중요한 건 LD_LIBRARY_PATH
와 LD_PRELOAD
를 명확하게 지정해 주는 거예요.
Q4. Node.js 버전은 어떤 게 GLIBC_2.27 이상을 요구하나요?
A4. 보통 Node.js v16 이상부터는 GLIBC_2.27 이상을 요구하는 경우가 많아요. 특히 공식 LTS 바이너리를 사용하는 경우 의존성 확인이 꼭 필요합니다.
Q5. glibc 업데이트 후에도 CXXABI
에러가 납니다. 해결 방법은요?
A5. 이건 GCC의 libstdc++ 라이브러리 버전이 낮아서 발생하는 문제예요. GCC를 9 이상으로 업그레이드하면 해결돼요. 설치 후엔 /usr/local/lib64
가 제대로 연결됐는지 꼭 확인해 주세요.
마무리하며
사실 처음에 GLIBC_2.27 not found
에러를 봤을 땐 막막했어요. 시스템 전체를 업그레이드해야 하나 싶었거든요. 하지만 이렇게 필요한 버전만 별도로 설치해서 문제를 해결하고 나니, 다음에 비슷한 문제가 생겨도 당황하지 않을 자신이 생겼어요.
정리하자면, 핵심은 기존 시스템을 건드리지 않고 glibc를 별도로 설치해 사용하는 것이에요. 그렇게 하면 안정성과 호환성을 모두 챙길 수 있거든요.
혹시 지금 비슷한 문제로 고생 중이라면, 위 과정을 하나씩 따라 해보세요. 잘만 하면 저처럼 깔끔하게 해결할 수 있을 거예요.
혹시 진행 중 궁금한 부분이나 안 되는 점이 있다면 댓글로 물어봐 주세요. 가능하면 제가 아는 한 최대한 도와드릴게요! 그리고 다음 글에선 ldd
, ldconfig
를 활용한 라이브러리 추적법이나 musl
libc를 활용한 바이너리 독립 실행 방법도 다뤄볼게요.