1. LLM 모델을 통한 SSH 작업 경험
- Gemini 와 Antigravity를 사용했을때는 SSH 명령을 그대로 전달해 원격 서버에 작업을 시키면 모델이 잘 수행하는것을 확인하였습니다.
- 반면 OpenCode와 로컬모델 Gemma 4 E4B 모델(예: 4‑billion 파라미터)을 연동하였을때, 그리고 현재 사용 중인 Gemma 4 26 B 모델은 동일한 SSH 명령어를 그대로 주면 매끄럽게 처리하지 못했습니다.
- 이를 계기로 다른 형태의 원격 작업 방식을 고민하게 되었고, 자연스럽게 Ansible을 떠올리게 되었습니다.
2. Ansible을 선택한 이유
- Ansible 명령어는 로컬에서 실행이 되고, 뒷 단에서 Python 모듈(
ansible‑core)을 통해 SSH 세션을 관리해 주죠. LLM이 직접 세션을 관리하지 않아도 됩니다. - 사용자는 "어디에서 어떤 명령을 실행한다"는 세부 사항을 직접 정의할 필요가 없으며, 플레이북을 작성하면 모든 원격 작업이 Ansible → SSH 흐름으로 수행됩니다.
- 따라서 복잡한 SSH 절차를 LLM이 직접 다룰 필요 없이, 플레이북만 전달하면 모델이 작업을 안정적으로 수행할 수 있습니다.
3. Ansible 자동화와 LLM 활용 가능성
그러나, Ansible 자체가 이미 자동화… 잖아요? 그러니 LLM을 통해서 Ansible을 실행하는 것과 사람이 직접 ansible을 실행하는것에 큰 차이가 없지 않을까요?
그럼에도 다음과 같은 보조 작업을 LLM에 위임하면 효율이 높아질 것으로 기대됩니다.
| 보조 작업 | LLM에 위임했을 때 기대 효과 |
|---|---|
| 인벤토리 파일 자동 생성 | 인프라 현황 파악이 빨라짐 |
| 변수(파라미터) 파일 맞춤 작성 | 재사용 가능한 파라미터 관리 용이 |
| 호스트(노드) 핑 확인 | 서비스 가용성 사전 검증 |
| 작업 결과 보고·문서화 | 마크다운 등 깔끔한 출력물 확보 |
3. 모델별 성능 검증 결과
Gemma 4 4B 모델
- 간단한 보고서 작성: MAC 주소, 인터페이스 상태, 업·다운 여부 등을 조회해 마크다운으로 정리하는 작업을 충분히 잘 수행했습니다.
- 에러 대응은 안됨: 에러가 발생하면 한없이 해매는걸 보게 됩니다. 차라리 문제를 해결하지 말고 그냥 에러메시지를 정리하라고 지시해야 합니다.
Gemma 4 26 B 모델
- 기본적으로 4B 모델 보다 오류 복구 능력이 뛰어난듯 보이지만, 그래도 에러 해결능력이 만족스럽지 못했습니다.
- Gemma 4 26B 모델 또한 그냥 에러를 다 해결하지 말고 정리를 하라고 한 다음, 인터넷이 가능한 환경에서 최신 ChatGPT·Gemini 수준의 모델을 활용해 디버깅하는 것이 가장 현실적 이라는 판단이 들었습니다.
온‑프레미스 환경에서의 역할 구분
| 역할 | 담당 모델 | 주요 업무 |
|---|---|---|
| SSH 접속·명령 전송 | Ansible (검증된 플레이북) | 원격 서버와 연결, 명령 실행 |
| 실행 상태 감시 | 4 B 모델 | Ansible이 정상 동작하는지 확인 |
| 결과 정리·문서화 | 4 B 모델 | 마크다운·리포트 자동 생성 |
| 오류 상황 수집·전달 | 4 B 모델 | 발생 원인·정황을 정리해 인터넷으로 전송 |
| 최종 디버깅·해결 | 인터넷 연결이 가능한 대형 모델 (ChatGPT·Gemini 등) | 수집된 정보를 바탕으로 문제 해결 |
5. 앞으로의 포커스
현재 저는 4B 모델을 실행 감시·결과 정리·오류 정보 수집에 활용하고, Ansible을 실제 원격 작업 수행에 맡기는 구조로 접근하고 있습니다.
이 방식이 온‑프레미스 환경에서 LLM이 제공할 수 있는 가치를 최대화할 것으로 기대합니다. 사실 ansible을 실행하는것이 문제가 아니라, 실행 내용을 정리하고, 인프라에 대한 형상을 정리하는것 또한 큰 공수가 들어가는 일 중에 하나니까요.
모델별로 할 수 있는 일을 분리하여 활용하자는 의견은 저 뿐만이 아니라, YouTube에 올라오는 여러 영상에서 확인할 수 있었습니다. ^^.
