남는 송출컴으로 리눅스 서버 구축, 나노클로 세팅부터 에이전트 자동화까지

시작하며

남는 송출컴이 놀고 있었다. 사양은 충분했고, 오히려 과했다. 그래서 새로 장비를 사는 대신 기존 자원을 서버로 전환해 보기로 했다. 목표는 단순하다. Claude Code와 Codex CLI를 안정적으로 돌리고, 게임 테스트 자동화까지 맡기는 것.

결론부터 말하면, CPU 선택이 생각보다 중요했다.

 

1. 그냥 쓰면 되지, 왜 CPU부터 바꿨을까

처음 송출컴 사양은 인텔 울트라 9 계열에 96GB 메모리, RTX 4070 Ti Super 구성이다. 일반 작업에는 전혀 부족함이 없다. 그런데 리눅스 기반 서버로 쓰려니 고민이 생겼다.

나는 게임 테스트를 End to End로 돌린다. 단순 빌드가 아니라 실제 화면을 띄워서 시나리오를 반복 실행한다. 이 과정에서 코어 간 성능 일관성이 꽤 중요하다.

(1) 리눅스에서 스케줄링이 마음에 걸렸다

① 모든 코어가 동일하게 동작하길 원했다

• 게임 테스트는 순간 피크가 반복적으로 발생한다
• 코어 특성 차이가 있으면 프레임이나 결과 로그가 달라질 수 있다

② 에이전트 작업도 동시에 돌아간다

• Claude Code
• Codex CLI
• 빌드 러너
• 로그 분석

이게 동시에 돌면 스케줄링이 예민해진다.

그래서 최종 선택은 Ryzen 7 9850X3D였다. 게이밍 CPU로 알려진 라인업이지만, 나는 오히려 서버에서 일관된 성능 분배가 더 마음에 들었다. “왜 서버에 게이밍 CPU를?”라는 질문을 받을 수 있지만, 내 사용 목적에는 더 잘 맞았다.

 

2. Ubuntu 24.04 데스크톱을 선택한 이유

처음엔 서버 버전만 생각했다. 그런데 나는 Headed 테스트, 즉 화면이 떠 있는 상태에서 자동화를 돌린다. 그래서 Ubuntu 24.04 Desktop을 설치했다.

GUI가 있는 게 생각보다 편하다.

(1) 화면이 보이는 상태에서 테스트 돌릴 때

① UI 기반 자동화가 바로 가능하다

• 추가 패키지 설치 과정이 단순하다
• 디버깅이 빠르다

② 원격 접속 후 상태 파악이 쉽다

• 로그만 보는 것보다 직관적이다
• 작업 중 멈춤 여부를 바로 확인 가능하다

나는 과거에 간호사로 일하던 시절에도 장비는 “직관성”이 중요하다고 느꼈다. 복잡한 시스템일수록 한눈에 보이는 환경이 사고를 줄인다. 서버도 비슷했다.

 

3. 나노클로 세팅과 에이전트 병렬 운영

기본 목표는 이거다.

Claude Code와 Codex를 수평적으로 병렬 운영하는 것.

중간 관리자 구조가 아니라, 두 모델이 서로 피드백을 주고받게 만드는 구조다.

(1) 디스코드를 컨트롤 타워로 만든 이유

① 어디서든 접근 가능하다

• 맥북
• 외부 모바일 환경
• 다른 테스트 머신

② 채널 단위로 프로젝트 분리가 쉽다

• 게임 프로젝트
• DB 프로젝트
• 이미지 생성 테스트

나는 채널별로 Claude와 Codex를 동시에 넣어두고, 서로 토론하게 만들었다. 일정 수준 논의 후 멈추고 나를 호출하게 세팅했다.

이 방식의 장점은 분명하다.

한 모델이 놓친 부분을 다른 모델이 짚는다.

 

4. Whisper, 이미지 파싱, 상태 모니터링까지 손봤다

처음엔 음성 입력이 바로 안 됐다. 그래서 Whisper 기반 중간단을 붙였다. 지금은 음성을 보내면 텍스트로 변환해서 모델에 전달한다.

(1) 내가 추가로 손본 기능들

① 이미지 파싱 기능

• 모델이 보낸 이미지 링크를 디스코드에서 바로 표시
• 양쪽 모델이 동일 이미지에 대해 피드백 가능

② 상태 모니터링 표시

• 활성화 / 대기 / 작업 중 구분
• 몇 분째 작업 중인지 표시

③ 서버 자원 모니터링

• CPU 사용률
• GPU 점유율
• 온도 및 업타임

이걸 왜 했냐면, 예전에 세션이 꼬여서 작업이 멈춘 걸 한참 뒤에 발견한 적이 있다. 그 뒤로는 “눈에 보이게” 만드는 쪽으로 설계를 바꿨다.

 

5. 게임 테스트 러너까지 붙여보니

현재는 3대 정도를 러너로 할당해 테스트 중이다.

 

🎮 실제 유저 환경을 흉내 내려면 이렇게 나눠봤다

• 스팀 OS 기반 기기 1대
• 중간급 사양 PC 1대
• 또 다른 일반 사용자급 머신 1대

이렇게 돌리면 패치 후 성능 차이가 금방 보인다.

솔직히 말하면, CPU 사용률이 100% 가까이 치솟는 순간도 많다. 그래서 추가 머신 증설도 고민 중이다. 서버는 항상 “남는 것 같다가도 부족해지는” 구조다.

 

6. 직접 써보니 체감은 어땠을까

며칠 돌려본 결론은 명확하다.

• 단일 모델보다 2개 병렬 운영이 훨씬 낫다
• 서버 자원은 생각보다 빨리 찬다
• 디스코드 기반 운영은 관리 피로도를 낮춘다

특히 코드 베이스 분석이나 UI 수정 피드백은 서로 교차 검증 구조가 확실히 유리했다. 혼자 쓸 때보다 실패율이 줄었다고 느꼈다.

 

마치며

남는 송출컴을 서버로 전환한 선택은 꽤 만족스럽다. 새 장비를 사지 않고도 충분히 확장 가능했고, CPU를 라이젠으로 바꾼 판단도 내 사용 패턴에서는 맞는 선택이었다.

만약 지금 남는 PC가 있다면, 단순히 처분하기 전에 한 번쯤 이런 구조로 돌려보는 것도 괜찮다. 특히 에이전트 자동화나 테스트 서버를 고민 중이라면, 생각보다 금방 체계가 잡힌다.

나는 다음 단계로 KVM 기반 원격 전원 제어까지 붙여볼 생각이다. 서버는 결국 통제력 싸움이다.