왜 한 대가 아니라 여러 PC를 묶게 되었나

한 장비에서 대화 모델, 문서 처리, 임베딩과 백그라운드 작업을 함께 돌리면 평소에는 작동해도 사용자가 질문하는 순간 문제가 드러났습니다. 이미 메모리를 차지한 작업 때문에 대화 모델을 올리지 못하거나, 짧은 질문이 긴 배치 작업 뒤에서 기다렸습니다.

장비를 추가해도 각 앱이 제각각 모델을 호출하면 해결되지 않았습니다. 어느 장비가 무엇을 하는지, 작업이 중단되면 누가 이어받는지, 검증되지 않은 결과를 언제 검색에 넣는지가 없었기 때문입니다.

검증할 때는 모델·런타임 버전, 입력 자료, 주요 설정과 결과를 한 묶음으로 저장합니다. 다른 조건을 그대로 둔 채 한 요소만 바꾸어 다시 실행하고, 예상과 다른 결과와 아직 확인하지 못한 한계까지 기록해야 이 설명을 자신의 환경에 안전하게 적용할 수 있습니다.

구성은 사용자 채널, 제어 영역, 작업 영역, 지식 영역으로 나눴습니다. 웹과 메신저는 요청을 받기만 하고, 조정자는 우선순위와 작업 소유권을 관리하며, 워커는 실제 모델 실행을 담당합니다. 결과는 검증 상태가 확인된 뒤 지식 영역으로 이동합니다.

‘장비가 아니라 운영 영역을 나눴습니다’ 단계에서 기준으로 삼을 원칙은 “사용자 요청 경로와 백그라운드 작업 경로를 먼저 나눴습니다.”입니다. 한 번의 성공 사례보다 조건을 고정한 반복 확인과 실패 기록이 실제 적용 범위를 더 분명하게 보여 줍니다.

비교표에는 측정 날짜와 버전, 사용한 입력 조건을 함께 붙입니다. 숫자가 비슷해도 오류 유형과 운영 부담이 다를 수 있으므로 단일 점수로 합치기 전에 각 열이 실제 업무에 미치는 영향을 따로 해석합니다.

최소 구성은 조정자 한 대와 워커 한 대입니다. 조정자는 낮은 사양이어도 되지만 상시 켜져 있어야 하고, 워커가 사라져도 요청을 대기 상태로 보존해야 합니다. 세 번째 장비부터는 새로운 전용 코드를 만들지 않고 동일한 heartbeat 형식으로 능력을 보고하게 합니다.

조정자가 직접 모델을 실행하지 않게 한 이유는 상태 판단과 고부하 작업을 같은 장애 영역에 두지 않기 위해서입니다.

완료 여부는 느낌이 아니라 관찰 가능한 기준으로 정합니다. 같은 입력을 반복했을 때 결과가 유지되는지 확인하고, 달라진다면 버전·설정·데이터 가운데 어떤 조건이 원인인지 좁힌 뒤 다음 단계로 넘어갑니다.

스타터 키트의 SQLite 조정기에서는 사용자 요청 우선 처리, RAM 제한, 만료 작업 회수, 늦은 중복 결과 거부와 만료 시각 확인을 자동시험으로 검증했습니다. 이 검증은 스케줄링 규칙이 의도대로 작동한다는 증거입니다.

반면 실제 모델 적재·해제, 운영체제별 온도 센서 수집, Telegram과 웹 연결은 장비 환경에 맞춘 어댑터가 필요합니다. 이 부분을 완성 기능처럼 말하지 않는 것이 운영 기록의 중요한 원칙입니다.

체크리스트는 한 번에 모두 통과시키기보다 각 항목에 확인 날짜와 결과를 붙여 사용합니다. 한 항목이 실패했을 때는 다음 단계로 넘어가기 전에 영향 범위를 적고, 수정 후 같은 입력으로 재시험해야 완료 여부를 객관적으로 판단할 수 있습니다.

• 검증됨: 큐·우선순위·RAM 차단·임대 회수·중복 거부
• 설계 예시: 모델 전환과 체크포인트
• 환경별 구현 필요: 센서·메신저·런타임 어댑터

이 시리즈는 장비 인벤토리부터 조정자, heartbeat, 선점, 임대 회수, 자원 보호, 지식 분리와 복구 시험의 순서로 이어집니다. 설치 명령 하나보다 예상 상태가 실제로 관측되는지를 통과 기준으로 삼습니다.

‘이후 글에서 확인할 것’ 단계에서 기준으로 삼을 원칙은 “사용자 요청 경로와 백그라운드 작업 경로를 먼저 나눴습니다.”입니다. 한 번의 성공 사례보다 조건을 고정한 반복 확인과 실패 기록이 실제 적용 범위를 더 분명하게 보여 줍니다.

결과를 다시 재현할 수 있도록 시작 전후의 상태와 확인 시각을 함께 남깁니다. 정상 사례뿐 아니라 빈 입력, 자원 부족이나 재시작 같은 실패 조건 하나를 포함하면 이 단계가 어디까지 견디는지 더 분명해집니다.