nGrinder — 웹 콘솔로 관리하는 분산 부하 테스트

개념

레슨 1의 Locust와 무엇이 다른가

레슨 1에서 Locust는 파이썬 파일을 하나 만들고 내 노트북 터미널에서 locust 명령으로 띄웠다. nGrinder는 출발점이 다르다 — 설치된 웹 콘솔에 브라우저로 접속해서 스크립트를 등록하고, 실행 버튼을 누르고, 결과 그래프를 그 화면에서 본다.

모듈 16 레슨 9에서 JMeter를 "GUI 방식"으로 정리했는데, nGrinder는 GUI와 코드 사이의 제3의 방식 이다. 시나리오 자체는 Groovy나 Jython 코드로 쓰지만, 그 코드를 보관하고 실행하고 결과를 남기는 껍데기는 웹 화면이다.

컨트롤러와 에이전트

nGrinder를 이해하는 핵심은 두 역할의 분리다.

[브라우저]
    │  테스트 등록 · 실행 · 결과 조회
    ▼
[컨트롤러]  ← 테스트를 관리하는 중앙 서버 (웹 콘솔이 여기 있다)
    │  "지금부터 이 스크립트를 이만큼 돌려라"
    ├──▶ [에이전트 A]  서버 1에서 실제 요청 발생
    ├──▶ [에이전트 B]  서버 2에서 실제 요청 발생
    └──▶ [에이전트 C]  서버 3에서 실제 요청 발생
                          │
                          ▼
                    [테스트 대상 시스템]

• 컨트롤러 — 스크립트를 보관하고, 어떤 에이전트에게 얼마만큼의 가상 사용자를 맡길지 배분하고, 각 에이전트가 보고한 결과를 하나로 합쳐 그래프로 보여준다. 부하를 직접 만들지는 않는다.
• 에이전트 — 컨트롤러의 지시를 받아 실제로 요청을 쏘는 프로세스다. 여러 대의 서버에 나눠 띄울 수 있다.

레슨 1에서 Locust의 마스터-워커 구조를 봤다면 개념은 거의 같다. 마스터가 컨트롤러, 워커가 에이전트에 대응한다. 차이는 Locust는 분산 구성을 직접 짜야 하는 반면, nGrinder는 처음부터 분산을 전제로 만들어져 콘솔에서 "에이전트 3대 사용"처럼 숫자만 고르면 된다는 점 이다.

왜 분산이 필요한가

수만 명 동시 사용자를 시뮬레이션할 때 진짜 병목은 테스트 대상이 아니라 부하를 만드는 쪽 인 경우가 많다. 노트북 한 대의 CPU와 네트워크 포트가 먼저 한계에 부딪히면, 측정된 응답 시간이 늘어난 게 서버가 느려서인지 내 노트북이 못 버텨서인지 구분이 안 된다.

에이전트를 여러 서버에 흩어두면 한 대당 부담이 나뉘어 이 문제를 피할 수 있고, 실제 사용자가 여러 곳에서 접속하는 상황에도 더 가깝다. 모듈 16 레슨 3의 "병목 지점 찾기"가 의미 있으려면, 먼저 부하 생성기 자체가 병목이 아니어야 한다.

왜 국내에서 자주 보이는가

nGrinder는 네이버가 자사의 대규모 트래픽 환경에서 쓰던 도구를 오픈소스로 공개한 것이다. 여기서 두 가지 실무적 이점이 나온다.

• 한국어 자료와 커뮤니티가 두껍다. 설치 가이드, 사내 구축 후기, 트러블슈팅 글이 한국어로 많이 남아 있어 도입 비용이 낮다.
• 팀 공용 콘솔이라 협업에 강하다. 스크립트가 각자 노트북이 아니라 콘솔 한 곳에 모이고, 누가 언제 어떤 조건으로 돌렸는지 이력이 남는다. QA·개발·인프라가 같은 화면을 보며 "지난주 결과 대비 어떤가"를 이야기할 수 있다.

실무에서 왜 필요한가

성능 테스트 결과를 두고 팀이 가장 자주 막히는 지점은 숫자 자체가 아니라 재현과 공유 다. "제 로컬에서는 이렇게 나왔는데요"라는 말이 나오는 순간 논의가 멈춘다. nGrinder처럼 콘솔에 스크립트와 실행 이력이 함께 남는 구조는, 같은 조건을 누구나 다시 돌려볼 수 있게 만들어 이 논쟁을 없앤다.

또 국내 기업 QA 채용에서 nGrinder가 요구사항에 등장하는 경우가 드물지 않다. 도구를 외울 필요는 없지만, "컨트롤러-에이전트 구조가 왜 대규모 부하에 유리한지"를 설명할 수 있으면 다른 분산 도구를 만나도 같은 틀로 이해할 수 있다.

실습 과제

과제 1 — 구조 그려보기 (10분)

"동시 사용자 30,000명"을 목표로 하는 부하 테스트를 nGrinder로 구성한다고 가정하고, 컨트롤러 1대와 에이전트 몇 대가 어떻게 배치될지 그림으로 그린다. 각 화살표에 무엇이 오가는지도 적는다.

과제 2 — 도구 선택 판단하기 (10분)

다음 세 팀에 Locust와 nGrinder 중 어느 쪽을 권할지 정하고 이유를 한 줄씩 적는다.

1. 파이썬에 능숙한 개발자 3명, 동시 사용자 500명 규모, CI에서 매 배포마다 자동 실행하고 싶다
2. QA 5명이 각자 다른 시나리오를 만들고 결과를 주간 회의에서 함께 비교하고 싶은 팀
3. 사내 서버 여러 대를 동원해 수만 명 규모의 이벤트 오픈 트래픽을 미리 검증해야 하는 팀

과제 3 — 병목 구분하기 (5분)

부하를 올렸더니 응답 시간이 나빠졌다. 이게 테스트 대상 서버의 한계인지 부하 생성기의 한계인지 구분하려면 무엇을 확인해야 할지 두 가지 이상 적는다.

자가 체크리스트

• nGrinder가 k6·Locust와 다른 점(웹 콘솔 기반)을 설명할 수 있다
• 컨트롤러와 에이전트의 역할을 각각 한 문장으로 구분해 말할 수 있다
• Locust의 마스터-워커 구조와 대응 관계를 설명할 수 있다
• 부하 생성기 자체가 병목이 될 수 있다는 점을 설명할 수 있다
• 팀 상황에 따라 Locust와 nGrinder 중 어느 쪽이 맞을지 판단할 수 있다

흔한 실수

• 에이전트 한 대로 수만 명을 만들려 한다. 부하 생성기가 먼저 한계에 도달하면 측정값 전체를 믿을 수 없게 된다. 에이전트 쪽 CPU·네트워크 사용률을 함께 봐야 한다.
• 컨트롤러가 부하를 만든다고 오해한다. 컨트롤러는 조율과 집계 담당이다. 부하를 늘리고 싶으면 에이전트를 늘려야 한다.
• 웹 콘솔이라 "코드가 필요 없다"고 생각한다. 시나리오는 여전히 Groovy나 Jython 코드로 작성한다. 콘솔은 관리 껍데기일 뿐이다.
• 도구가 바뀌었다고 지표 해석 기준까지 새로 배우려 한다. 모듈 16 레슨 3에서 배운 평균의 함정, p95, 실패율은 nGrinder의 TPS· 응답 시간 그래프에도 똑같이 적용된다.

참고 자료

• nGrinder 공식 문서 — 컨트롤러·에이전트 설치와 첫 테스트 실행 가이드
• nGrinder GitHub 저장소 — 릴리스 노트와 이슈에서 실제 운영 사례를 볼 수 있다