[개발 기초] Nexus란 무엇인가? 실무 개발자 관점으로 쉽게 이해하기

프로젝트에 처음 투입되면 팀원들에게 이런 말을 듣게 됩니다.

"패키지는 Nexus 통해서 받으세요"
"빌드한 Artifact Nexus에 올려주세요"
"CI 빌드가 Nexus 바라보고 있어요"
ㅤ

처음엔 이런 생각이 들죠. "그냥 npm install, pip install 하면 되는데 왜 굳이...?"

저도 처음엔 그랬습니다. 하지만 이해하고 보니, Nexus는 단순한 개발 편의 도구가 아니라 운영 안정성과 패키지 관리를 위한 핵심 인프라였습니다.

---

📦 Nexus란 무엇인가?

Sonatype Nexus Repository의 줄임말로, 한 줄로 정의하면 이렇습니다.

"패키지(Dependency)와 빌드 산출물(Artifact)을 관리하는 저장소 서버"

 

쉽게 비유하자면 다음과 같습니다.

• Git: 소스코드 저장소 (코드 창고)
• Nexus: 패키지/아티팩트 저장소 (패키지 창고)

---

❌ 많이 오해하는 부분들

1. "코드에 Nexus 라이브러리를 설치하는 건가?"

아닙니다. npm install nexus 같은 개념이 아닙니다. Nexus는 별도 서버로 운영되는 '저장소 서비스'입니다.

2. "내 코드에서 Nexus를 호출해야 하나?"

그렇지 않습니다. 소스코드 내부에는 Nexus 관련 코드가 들어가지 않습니다. 대신 프로젝트의 설정 파일에 저장소 위치만 명시합니다.

# .npmrc 예시
registry=http://nexus.company.com/repository/npm-group/

---

🎯 Nexus의 핵심 역할 2가지

① 패키지 프록시 (Proxy)

외부 저장소(npm, PyPI, Maven Central 등)에서 패키지를 받아와 사내 Nexus 서버에 캐싱합니다.

• 장점: 외부망 장애 시에도 내부 캐시를 통해 빌드가 가능하며, 외부 서버 통신 속도 문제에서 자유로워집니다.

② 빌드 산출물 저장 (Hosted)

빌드 결과물(JAR, Docker Image, Python Wheel 등)을 외부가 아닌 사내 Nexus에 업로드하여 관리합니다.

• 흐름: Build → Nexus 저장 → 배포(Deploy)

---

🔄 실무에서의 개발/배포 흐름

개발할 때

평소와 똑같이 npm install, npm run build를 수행합니다. 단지 외부 저장소 대신 내부 Nexus를 바라보도록 설정되어 있을 뿐입니다.

CI/CD 파이프라인

Git Push 
   ↓
Jenkins/GitLab CI 
   ↓
Build (Dependency는 Nexus에서 받고, 결과물은 Nexus에 올림)
   ↓
Deploy (Nexus에서 완성된 산출물만 가져와 배포)

---

🗂️ Git과 Nexus, 역할의 차이 (핵심!)

많은 분이 헷갈려 하는 부분입니다.

구분	역할	관리 대상
Git	"어떤 버전"을 쓸지 관리	package.json, package-lock.json
Nexus	"어디서" 받을지 관리	node_modules, jar, docker image
ㅤ

즉, Git은 코드의 형상을 관리하고, Nexus는 그 코드가 빌드/실행되기 위한 재료와 결과물을 관리합니다.

---

💡 왜 Nexus를 쓰는가?

1. 외부 장애 영향 최소화: 외부 저장소가 죽어도 내부 캐시로 빌드 유지 가능.
2. 빌드 재현성 보장: 팀원 모두가 동일한 버전의 패키지를 사용하도록 통제.
3. 보안과 통제: 검증되지 않은 패키지 사용 방지.
4. 내부 공통 라이브러리 배포: 팀 간 common-utils, shared-sdk 등 공유 패키지 관리 용이.
5. 폐쇄망 대응: 금융, 공공 프로젝트 등 외부 접속이 차단된 환경에서 필수.

---

💬 요약

Nexus는 개발 편의 도구라기보다 "빌드와 배포를 안정화하는 인프라 보험"입니다. 평소엔 존재감이 없지만, 사고가 나면 왜 있는지 비로소 보이는 도구