사내 AI를 함께 쓰면 느려집니다. 장비를 바꿔야 할까요?

여러 명이 쓸 때 사내 AI가 느려진다면, 장비를 바꾸기 전에 동시에 들어오는 실제 업무로 처리 한도를 시험하세요. 짧은 질문과 긴 문서가 섞일 때도 필요한 답을 제시간에 받는지 확인합니다. 이 글에서는 맥미니·Ollama 서버를 기준으로, 긴 업무를 따로 처리할지, 동시 요청을 제한할지, 장비를 늘릴지 판단하는 방법을 설명합니다.

직원 열 명이 하루에 한 번씩 짧은 질문을 보내는 상황과 두 명이 동시에 긴 거래 자료를 요약하는 상황은 다릅니다. Ollama 공식 문서도 문맥 길이와 병렬 처리 수가 메모리 사용에 영향을 준다고 설명합니다. 장비 사양만으로 몇 명까지 쓸 수 있다고 정하기보다, 팀에서 실제로 처리할 자료를 시험에 넣는 이유입니다.

장비를 바꾸기 전에 시험할 세 가지 업무

팀의 실제 요청 한도를 찾는 시험 순서

한 건을 끝까지 처리
대표 문서를 넣고 정답·첫 응답·완료 시간과 오류를 기록합니다.
같은 조건에서 동시 요청 증가
한 번에 시작하는 수를 늘리며 대기와 메모리, 품질 변화를 확인합니다.
업무가 섞인 상황 재현
짧은 질문과 긴 문서가 실제 비율로 들어오는 상황을 시험합니다.
통과한 범위로 운영 설정
업무 기준을 지킨 범위 안에서 요청 제한과 대기 안내를 정합니다.

이 방법은 서버가 이미 있지만 업무 시간에 느려지거나, 새 문서 처리를 추가하려는 팀에 맞습니다. 서버를 아직 구성하지 않았다면 구축 가이드에서 실행 경로부터 정하세요. 시험은 다음 세 종류를 나누면 해석하기 쉽습니다.

업무 종류	입력과 기대 결과	중점적으로 볼 지표
짧은 질의	짧은 질문에서 필요한 항목을 답하기	첫 응답과 전체 완료 시간
긴 문서 정리	정해진 길이의 문서에서 금액·조건·일정 추출	입력 처리 시간, 누락, 메모리
문서 검색 후 답변	질문에 맞는 자료를 검색해 인용과 함께 답하기	검색 시간과 생성 시간, 올바른 근거

기술 담당자는 모델 API 단독 시험과 직원이 쓰는 전체 경로 시험을 분리합니다. 모델은 빠른데 웹 화면이 느리다면 업로드, 문서 파싱, 검색, 대기열에 시간이 쓰였을 수 있습니다. 직원이 체감하는 한도를 정하려면 최종적으로 웹 화면에서 결과를 확인하기까지의 시간을 측정합니다.

먼저 ‘쓸 만하다’의 기준을 적습니다

업무 담당자는 시험 전에 최대 대기 시간과 필수 답변 항목을 정합니다. 대화형 문의는 첫 문장이 빨리 나와야 하고, 밤에 모아 처리하는 자료 정리는 다음 업무 시작 전에 모두 끝나는지가 더 중요할 수 있습니다. 두 업무에 같은 시간 기준을 적용하면 과도한 장비를 사거나 필요한 용량을 놓치기 쉽습니다.

아래는 시험 양식입니다. 수치는 팀의 업무 기한과 현재 수동 처리 방식을 기준으로 채웁니다.

결정할 항목	팀에서 작성할 기준	기준을 넘었을 때 선택
첫 응답 대기	사용자가 기다릴 수 있는 시간	진행 상태 표시, 요청 제한 검토
전체 완료	문서 한 건 또는 묶음의 처리 기한	긴 업무 분리, 처리 시간대 조정
필수 품질	빠지면 안 되는 숫자·조건·근거	모델·입력·검색 방식 재평가
실패 대응	재시도할 오류와 사람에게 넘길 오류	보류 큐와 대체 처리 경로
피크 업무량	동시에 시작하는 요청과 입력 길이	이 조건을 포함해 수용 범위 시험

빠른 답변이라도 금액이나 예외 조항이 빠지면 업무에 쓰기 어렵습니다. 시험마다 같은 정답표로 검수하고, 속도와 품질을 한 행에 남기세요. 품질 기준을 통과한 구성끼리 비교해야 증설 판단이 의미를 갖습니다.

시험 환경을 고정하는 기록표

시험 사이에 모델과 설정이 함께 바뀌면 무엇이 개선됐는지 찾기 어렵습니다. 첫 시험의 환경표를 만들고, 다음 시험에서는 바꾼 항목을 표시합니다.

동시 요청의 영향만 비교할 때는 모델 태그, 양자화, 문맥 길이를 같게 유지합니다.
모델 후보를 비교할 때는 입력과 품질 기준을 맞추고 모델만 바꿉니다.

구분	기록할 내용
장비	칩, 메모리, OS, 디스크 여유, 함께 실행한 프로그램
실행 도구	Ollama와 웹 화면의 버전, 모델 연결 경로
모델	태그, 식별값, 양자화, 설정한 문맥 길이
요청	질문 버전, 입력 문서 식별값, 입력 길이, 출력 상한
부하	동시에 시작한 수, 요청 간격, 반복 횟수, 시험 지속 시간
상태	모델을 처음 불러온 요청인지, 이미 적재된 상태인지
평가	필수 답변 항목, 제한 시간, 오류 분류, 검사 담당자

원문 문서가 바뀌면 같은 파일명이어도 시험 입력은 달라집니다. 문서 버전이나 해시 등 내부 식별값을 남기고, 시험 로그에는 필요한 식별 정보만 기록합니다. 여러 사람이 쓰는 장비라면 시험 중 다른 작업이 있었는지도 적어, 외부 부하 때문에 생긴 차이를 구분합니다.

한 요청에서 피크 업무까지 늘리는 순서

개발 담당자는 먼저 모델을 불러오는 첫 요청과, 이미 메모리에 올라온 뒤의 요청을 따로 기록합니다. 이후 동시 요청을 1·2·4처럼 단계적으로 늘립니다. 팀에서 가장 많은 요청이 몰리는 때가 두 단계 사이에 해당하면 그 요청 수도 시험합니다. 각 단계에서는 시작과 종료 시각, 성공·실패, 결과 품질을 개별 요청 단위로 남깁니다.

같은 시험을 반복해 결과의 편차를 봅니다. 짧은 시험을 통과한 뒤에는 실제 업무가 이어지는 시간 동안 혼합 요청을 보내, 대기열이 줄어드는지와 메모리·디스크 상태가 계속 안정적인지 확인합니다.

동시 시작 수와 모델 내부 병렬 설정은 구분하세요. 요청 네 건을 한꺼번에 보냈더라도 일부는 대기할 수 있습니다. Ollama의 병렬 설정과 메모리 조건을 기록하고, 대기 시간을 포함해 읽어야 직원이 겪을 지연을 설명할 수 있습니다.

평균 대신 느린 요청까지 읽습니다

첫 응답 시간은 요청 시작부터 첫 내용이 보일 때까지, 전체 완료 시간은 결과를 모두 받을 때까지입니다. 중간에 연결만 열리거나 빈 메시지가 온 시점을 첫 답변으로 세지 않도록 측정 기준을 통일합니다. 스트리밍을 쓰지 않는 경로에서는 직원이 보는 완료 시간과 서버 내부 생성 지표를 구별합니다.

완료 시간을 짧은 순서로 정렬하면 보통의 대기와 느린 쪽 요청의 경험을 나눠 살필 수 있습니다.

p50은 짧은 순서로 정렬했을 때 가운데에 있는 값으로, 보통의 대기 시간을 보여줍니다.
p95는 짧은 순서로 정렬했을 때 약 95% 지점의 값으로, 느린 쪽 요청의 대기 시간을 보여줍니다.

가상 예시: 평균은 20초, 한 요청은 65초

모두 30초 안에 완료

요청별 완료 시간: 20초 · 20초 · 20초 · 20초
평균 완료 시간: 20초
30초를 넘긴 요청: 0건 → 시간 기준 통과

한 요청이 30초 초과

요청별 완료 시간: 5초 · 5초 · 5초 · 65초
평균 완료 시간: 20초
30초를 넘긴 요청: 1건 → 지연 원인 확인

두 경우 모두 요청마다 시작부터 완료까지 측정하고, 한 건당 30초 이내를 시간 기준으로 정했습니다. 평균만 보면 65초 걸린 요청을 놓칩니다.

계산 방식과 표본 수를 함께 기록하세요. 표본이 적으면 느린 요청 한 건이 결과를 크게 바꾸므로, 원래 측정값과 최댓값도 함께 확인합니다. 오류 요청은 완료 시간 집계에서 빠지기 쉬우므로 오류 수와 중단된 요청을 별도로 셉니다.

Ollama의 eval_count / eval_duration × 10^9는 출력 생성 구간의 초당 토큰 수를 구하는 식입니다. 입력을 읽고 줄을 서서 기다리는 시간은 이 숫자와 다르므로, 생성 속도와 전체 완료 시간을 각각 기록합니다.

시험 양식	기록할 값
조건	장비·모델·질문 버전, 동시 요청, 처음 적재 여부
시간	요청 수, 첫 응답과 완료의 p50·p95·최댓값
오류	성공 수, 시간 초과, 취소, 메모리 관련 실패
자원	메모리·스왑·디스크 상태, 대기열 변화
품질	필수 항목 통과 수, 누락·잘못된 숫자·잘못된 인용
판정	통과 여부, 제한할 업무, 다음에 바꿀 항목

결과에 따라 무엇을 바꿀까

짧은 질문은 기준을 통과하지만 긴 문서가 섞일 때 전체 대기가 늘었다면, 개발 담당자는 긴 요청을 별도 대기열로 분리해 시험합니다. 업무 담당자는 긴 자료를 즉시 처리할 필요가 있는지 정합니다. 업무를 나눈 뒤 같은 시험에서 품질과 처리 기한을 모두 충족하면, 현재 장비에 그 처리 방식을 적용합니다.

시험에서 드러난 문제	먼저 적용할 변경	다음 시험의 판단
한 건부터 품질 미달	입력 구조·검색 결과·모델 비교	필수 품질을 통과한 구성 확보
한 건은 통과, 동시 요청에서 지연	요청 수 제한과 대기 안내	실제 피크가 기한 안에 해소되는지
긴 입력에서 자원 부족	자료 분할, 문맥 범위·병렬 설정 조정	조건 누락 없이 품질과 자원 개선
웹 경로만 느림	업로드·검색·생성의 단계별 시간 측정	시간이 몰린 단계를 고친 뒤 전체 재시험
제한을 걸어도 업무 기한 초과	장비 후보 또는 허용된 외부 처리 비교	같은 자료·품질에서 처리 기한 충족

외부 API 보조를 선택할 때는 보낼 수 있는 자료의 범위를 먼저 정합니다. 장비 증설은 새 장비에서 같은 입력과 판정표로 비교하세요. 메모리가 늘었다는 사실보다 업무 기준을 충족하는 요청 수가 늘었는지가 구매 판단에 직접 연결됩니다. 외부 API와 장비 증설의 선택 기준은 클라우드·로컬 선택 기준에 정리했습니다.

운영에서 다시 시험해야 하는 시점

모델, 문맥 길이, 문서 검색, 동시 요청 설정이 바뀌면 기존 시험의 전제가 달라집니다.

개발 담당자는 설정 변경 전후에 같은 시험표로 검사합니다. 업무 담당자는 새 결과가 업무 기준을 충족하는지 확인하고 승인합니다.

문서가 길어지거나 직원들이 같은 시각에 작업하기 시작한 경우에도 실제 피크를 다시 기록합니다.

검사에 실패한 요청을 계속 자동 재시도하면 부하가 늘 수 있습니다. 재시도 횟수와 간격, 대기 안내, 수동 전환 기준을 함께 정하세요. 재부팅과 백업 복구 같은 서비스 유지 조건은 사내 AI 서버 운영 점검표로 별도 관리합니다.

로보텍스트에 맡기면 무엇을 받나요?

로보텍스트는 실제 업무 문서로 속도와 답변 품질을 확인할 시험을 설계하고, 모델만 쓰는 경로와 웹 화면·검색까지 거치는 경로를 나눠 확인합니다. 결과가 늦어지는 지점에 맞춰 대기열, 요청 제한, 검수와 재처리를 연결합니다. 고객은 업무별 처리 한도와 운영 설정, 변경 뒤 같은 조건으로 다시 검사할 시험표를 받습니다.

hello@robotext.co.kr로 **「사내 AI 성능 시험 상담」**이라고 보내주세요. 첫 답변에서는 장비 사양·모델·주요 작업·기다릴 수 있는 시간을 여쭙고, 이를 바탕으로 시험할 업무와 통과 기준을 함께 정하겠습니다.