# Gemini CLI 마스터하기(심화): v22 - 실전 예제: 인터랙티브 모드로 K8s 애플리케이션 디버깅하기

이전 단계에서 Gemini CLI가 Kubernetes 클러스터와 상호작용하는 방법을 배웠습니다. 이제 이 지식을 활용하여 실제 DevOps 시나리오, 즉 **Kubernetes에 배포된 애플리케이션을 디버깅하는 과정**에 Gemini 에이전트를 적용하는 실전 예제를 살펴보겠습니다. 인터랙티브 모드의 '안전성'과 LLM의 '지능'이 결합되어 복잡한 디버깅 작업을 어떻게 효율적으로 수행할 수 있는지 확인할 수 있습니다.

---

## 1. 디버깅 시나리오: CrashLoopBackOff 상태의 파드

우리의 `backend` 애플리케이션이 Kubernetes 클러스터에 배포되어 있습니다. 그런데 갑자기 모니터링 시스템에서 `backend` 애플리케이션에 문제가 발생했으며, 관련 파드 중 하나가 `CrashLoopBackOff` 상태에 빠졌다는 경고를 받았습니다. 이제 Gemini 에이전트의 도움을 받아 문제의 원인을 파악하고 해결책을 찾아보겠습니다.

### 사전 준비:

*   `INTERACTIVE=1`로 설정하고 `gemini web`을 실행하여 인터랙티브 모드에 접속합니다.
*   `kubeconfig` 파일이 올바르게 설정되어 Gemini CLI가 K8s 클러스터에 접근할 수 있는지 확인합니다.

## 2. 인터랙티브 모드를 통한 K8s 디버깅 과정

### 단계 1: 문제 파드 식별 및 상태 확인

*   **사용자:** 웹 인터페이스의 프롬프트 입력창에 "default 네임스페이스에서 `CrashLoopBackOff` 상태인 파드가 있는지 확인해 줘."
*   **에이전트 로그:** "요청 분석: `CrashLoopBackOff` 상태 파드 검색. K8s API `list_resources` 호출 준비."
*   **행동 제안 카드:** "제안된 행동: `list_resources(api_version='v1', kind='Pod', namespace='default', field_selector='status.phase=Running')` ... (여기서 에이전트는 모든 파드를 가져온 후 상태를 필터링하거나, 직접 `field_selector`를 활용할 수 있습니다)"
*   **사용자:** 승인.
*   **에이전트 응답:** "default 네임스페이스에서 `backend-deployment-abc12-xyz34` 파드가 `CrashLoopBackOff` 상태입니다."

### 단계 2: 문제 파드의 상세 정보 확인

*   **사용자:** "저 `backend-deployment-abc12-xyz34` 파드에 대한 자세한 정보를 알려줘."
*   **에이전트 로그:** "요청 분석: 특정 파드 상세 정보 확인. K8s API `list_resources` 호출 준비."
*   **행동 제안 카드:** "제안된 행동: `list_resources(api_version='v1', kind='Pod', namespace='default', name='backend-deployment-abc12-xyz34', verb='describe')` (또는 `kubectl describe pod`와 유사한 정보 추출)"
*   **사용자:** 승인.
*   **에이전트 응답:** `kubectl describe pod backend-deployment-abc12-xyz34`의 요약된 출력 결과를 제시합니다. 특히 **Events 섹션**에서 오류 메시지(예: `Failed to pull image`, `Error: OOMKilled`, `CrashLoopBackOff` 이유)나 `Last State`의 `Terminated` 이유를 강조하여 보여줍니다.

### 단계 3: 파드 로그 분석

`kubectl describe pod` 결과에서 에러가 명확하지 않다면, 로그를 확인해야 합니다.

*   **사용자:** "이 파드의 로그를 가져와서 에러 메시지가 있는지 확인해 줘."
*   **에이전트 로그:** "요청 분석: 파드 로그 확인. K8s API `get_logs` (가상의 K8s tool) 호출 준비."
*   **행동 제안 카드:** "제안된 행동: `get_logs(pod_name='backend-deployment-abc12-xyz34', namespace='default')`"
*   **사용자:** 승인.
*   **에이전트 응답:** 파드 로그의 최근 몇 줄을 보여주며, "Connection refused" 또는 "java.lang.NullPointerException"과 같은 명백한 에러 메시지를 강조합니다.

### 단계 4: 로그 분석 및 해결책 제안

*   **사용자:** "로그에 'Connection refused' 에러가 계속 나오는데, 이게 무슨 의미이고 어떻게 해결해야 할까?"
*   **에이전트 로그:** "요청 분석: 'Connection refused' 에러 의미 및 해결책 제시. LLM 추론 중."
*   **에이전트 응답:** "로그에 'Connection refused' 에러가 발생했다는 것은 애플리케이션이 외부 서비스(데이터베이스, 다른 마이크로 서비스 등)에 연결을 시도했지만 거부당했음을 의미합니다. 가능한 원인과 해결책은 다음과 같습니다.
    1.  **서비스 미시작/오류:** 연결하려는 서비스(예: 데이터베이스 파드)가 정상적으로 실행 중인지 확인하세요. `kubectl get pods -l app=database`
    2.  **포트 불일치:** 애플리케이션이 잘못된 포트로 연결을 시도하고 있을 수 있습니다. 컨테이너 환경 변수나 설정 파일을 확인하세요.
    3.  **네트워크 정책/방화벽:** 연결을 차단하는 네트워크 정책이 설정되어 있을 수 있습니다. `kubectl get networkpolicy` 명령으로 확인하세요.
    4.  **서비스 이름 오류:** 연결하려는 서비스의 이름이 올바른지 확인하세요. `kubectl get svc`"

### 단계 5: (선택 사항) 해결 행동 제안 및 승인

에이전트가 문제의 원인을 파악하고 특정 변경을 제안할 수도 있습니다. (이 단계는 에이전트의 K8s 변경 권한에 따라 달라집니다.)

*   **에이전트 로그:** "로그 분석 결과, `backend-service`의 포트 설정이 잘못된 것 같습니다. 서비스의 포트를 8080에서 8000으로 수정하는 패치 작업을 제안합니다."
*   **행동 제안 카드:** "제안된 행동: `patch_service(name='backend-service', namespace='default', spec={'ports': [{'port': 8000}]})`"
*   **사용자:** 제안된 변경이 올바른지 검토 후 **'승인(Approve)'** 또는 **'거부(Deny)'**를 결정합니다.

## 3. 요약

인터랙티브 모드의 Gemini CLI는 K8s 애플리케이션 디버깅 과정을 혁신합니다. 복잡한 `kubectl` 명령어를 자연어로 대체하고, LLM의 지능으로 K8s의 방대한 출력을 해석하여 문제 해결에 필요한 핵심 정보를 신속하게 제공합니다. 또한, 모든 변경 작업은 사용자의 승인을 거치므로, 안전하게 클러스터를 관리하고 디버깅할 수 있습니다.

K8s 디버깅 실전 예제를 통해 에이전트의 강력함을 경험했습니다. 이제 에이전트의 '지능'을 더욱 정교하게 다듬는 방법, 즉 **동적 프롬프트 템플릿 엔진을 커스터마이징**하여 에이전트의 성격과 응답 방식을 완전히 제어하는 방법을 살펴보겠습니다.