💡 핵심 인사이트
넥서스(Nexus)는 스크럼의 창시자인 켄 슈와버가 직접 고안한 대규모 애자일 프레임워크로, 3~9개의 스크럼 팀이 하나의 제품을 만들 때 발생하는 '가장 끔찍한 문제인 코드 충돌과 파이프라인 의존성(Dependency)'을 전담해서 풀어주는 [넥서스 통합팀(NIT)]을 별도로 두는 것이 핵심입니다.
Ⅰ. 넥서스의 탄생 (통합의 늪)
여러 팀이 코딩을 하다 보면 내 코드가 남의 코드를 망가뜨리는 일이 매일 발생합니다. LeSS처럼 규칙을 없애고 "너희들끼리 소통해서 알아서 합쳐!"라고 방목하면, 개발자들이 서로 싸우거나 수만 줄의 충돌(Merge Conflict)을 해결하느라 일주일 밤을 새우게 됩니다.
스크럼 창시자는 이 현실적인 지옥을 인정했습니다. "여러 팀이 코드를 합칠 때(Integration)는 무조건 누군가 총대를 메고 교통정리를 해주는 전담반이 필요하다." 그렇게 만들어진 것이 3~9개 팀(약 100명 이내)에 최적화된 Nexus(연결고리) 프레임워크입니다.
Ⅱ. 핵심 심장: 넥서스 통합팀 (NIT, Nexus Integration Team)
이것이 넥서스만의 유일무이한 특징입니다. 기존 8개의 스크럼 팀 외에, 마치 특수부대 같은 **'통합 전담 제9의 팀(NIT)'**을 하나 더 띄웁니다.
NIT의 구성과 임무
- 구성원: 제품 책임자(PO) 1명, 스크럼 마스터 1명, 그리고 **각 8개 실무 개발팀에서 차출된 코딩 에이스 1명씩(대표자)**이 모여 NIT를 구성합니다.
- 주 임무 (코딩 안 함): 이들은 자신들의 고유 기능(로그인, 결제)을 개발하지 않습니다. 8개 팀이 뿜어내는 수만 줄의 코드가 충돌 없이 매일 매끄럽게 하나의 시스템으로 합쳐지도록(CI/CD), 통합 환경을 구축하고 의존성 에러가 터지면 달려가서 불을 끄는 네트워크 교통경찰 역할을 합니다.
Ⅲ. 넥서스의 이벤트 추가 (기존 스크럼에 덧붙이기)
넥서스는 기존 스크럼(플래닝, 데일리, 리뷰, 회고)을 그대로 하되, 그 앞뒤에 '넥서스(전체 통합) 이벤트'를 샌드위치처럼 하나씩 더 끼워 넣습니다.
- 넥서스 스프린트 계획 회의
- 개별 팀 회의를 하기 전에, 각 팀 대표들이 먼저 모여 "우리 팀이 이 기능 짤 때 너희 DB 건드릴 텐데 괜찮아?"라며 거대한 의존성 지도를 미리 정리하고 일감을 분배합니다.
- 넥서스 일일 스크럼 (Nexus Daily Scrum)
- 매일 아침 15분짜리 팀 스탠드업을 하기 직전, 각 팀 대표들만 모여 "우리 팀 오늘 A 모듈 고칠 거니까 니네 에러 날 수도 있어!"라며 통합 시 발생할 장애물을 먼저 공유합니다. 이 정보가 각 팀의 일일 스크럼으로 전파됩니다.
- 넥서스 스프린트 리뷰
- 8개 팀이 찢어져서 데모하지 않습니다. 다 합쳐져서 완벽하게 통합된 단 1개의 시스템(통합 증분)을 PO 앞에서 다 같이 시연합니다.
📢 섹션 요약 비유: 넥서스는 오케스트라의 **'지휘자와 수석 연주자(NIT) 시스템'**입니다. 8개의 악기 파트(스크럼 팀)가 각자 연습(개발)을 하되, 바이올린 수석과 첼로 수석들이 따로 모여 템포를 맞추는 지휘자 파트(NIT)가 존재합니다. 이 수석들이 먼저 음정(의존성)을 맞추고 자기 팀으로 돌아가서 전파해야만 100명이 연주할 때 불협화음(코드 충돌) 없는 하나의 교향곡(통합 시스템)이 완성될 수 있습니다.