AI 위임의 경계 — 인프라 자동화의 빛과 그림자

TL;DR SSH 서버 운영과 DB 데이터 분석을 AI에게 위임한 경험을 정리합니다. 서버 설정 변경에서는 장애를 겪었고, DB 조회 위임에서는 데이터 정합성 분석에 효과적으로 활용했습니다. 두 경험을 통해 “AI에게 무엇을 맡기고 무엇을 직접 할 것인가”의 경계선을 그렸습니다.

1. 배경 — 인프라까지 확장한 이유

이전 글에서 사내 업무 자동화 체계(toolkit)를 구축한 과정을 다뤘습니다. devex로 이슈 플로우를, toolkit으로 데일리로그와 콘텐츠 파이프라인을 자동화했습니다.

그런데 실무에서는 서버 접속 인증 설정(kubeconfig) 교체나 DB 쿼리 같은 작업도 빈번합니다. 이런 인프라 영역까지 AI에게 위임할 수 있다면 생산성이 더 올라갈 것이라 판단했습니다.

결과적으로 두 가지 플러그인/스킬을 만들었습니다.

• claude-ssh-tools: SSH Gateway 기반 서버 운영 자동화 (독립 플러그인)
• toolkit:db-client: MySQL 다중 환경 RDS 접속 (toolkit 내 스킬)

두 영역 모두 작동은 했지만, 위임의 편리함과 위험성을 동시에 체감했습니다.

2. SSH — 장애를 겪고 경계를 그리다

2-1. 장애 사례

4개 클러스터가 병합된 kubeconfig에서 인증서를 교체하는 작업을 AI에게 위임했습니다. AI는 yaml.dump()로 파일 전체를 다시 썼습니다. 4개 클러스터 중 2개가 삭제되고 current-context가 변경되었습니다. 젠킨스 배포 파이프라인이 잘못된 컨텍스트로 실행되어 장애가 발생했습니다.

로컬과 서버의 kubeconfig 컨텍스트 이름이 달랐습니다. AI가 이를 구분하지 못하고 임의로 매칭하면서 401 오류가 발생했습니다.

2-2. 돌이켜 보면

AI를 너무 믿은 것이 실수였습니다. 특히 서버 설정 변경처럼 되돌리기 어려운 작업에서 AI에게 “알아서 해줘”라고 위임한 것은 판단 착오였습니다. 구체적인 교훈은 다음과 같습니다.

교훈	내용
로컬과 서버 환경은 다르다	AI는 로컬 상태를 기준으로 판단하지만, 서버의 실제 상태는 다를 수 있습니다
속도가 느리다	매 요청마다 SSH 커맨드를 개별 호출하므로, 사람이 직접 접속하여 연속 작업하는 것보다 느립니다
특이사항을 빠뜨린다	문서에 기록해둔 운영 규칙을 AI가 참조하지 않거나 일부만 적용하는 경우가 있습니다

3. DB — DQL 위임으로 데이터 분석을 맡기다

3-1. db-client 스킬

toolkit에 포함된 db-client 스킬은 NHN Cloud RDS에 MySQL 8.0 클라이언트로 접속합니다. 접속 가능한 환경은 다음과 같습니다.

환경	용도
GPU 멀티테넌시-개발	개발 환경 테스트/분석
GPU 멀티테넌시-운영	운영 환경 조회
앱 멀티테넌시-개발	개발 환경
앱 멀티테넌시-운영	운영 환경

인증 정보는 macOS Keychain에 db/{환경}/user, db/{환경}/password 패턴으로 저장합니다. 환경변수나 설정 파일에 비밀번호가 남지 않습니다.

3-2. 실제 활용 — 미터링 데이터 정합성 분석

GPU 멀티테넌시 서비스에서 미터링 기능의 데이터 정합성을 검증해야 했습니다. 미터링은 GPU 사용량을 시계열로 수집하고 집계하는 시스템입니다. 원본 데이터와 집계 결과의 일치 여부를 확인해야 했습니다.

AI에게 위임한 작업:

1. 구현 단계 정합성 체크: 미터링 기능이 구현될 때마다 관련 테이블의 데이터를 조회하여 정합성을 확인하고 보고서를 작성
2. 개발 환경 전체 테스트 후 분석: 개발 환경에서 전체 테스트를 실행한 뒤, 작업 데이터 정합성 분석을 요청. AI가 분석서를 작성하면, 이를 기반으로 교차 검증

AI가 작성한 분석은 정확했습니다. DQL(SELECT)만 사용하므로 데이터 변경 위험이 없습니다. 여러 테이블에 걸친 정합성 검증 쿼리를 매번 수동으로 작성하지 않아도 됩니다.

3-3. DB 위임의 한계

DQL만 사용하더라도 주의할 점은 있습니다.

• 운영 DB 부하: 대량 조회 쿼리가 운영 DB에 부하를 줄 수 있습니다. 개발 환경에서 충분히 검증한 뒤 운영에 적용하는 단계가 필요합니다.
• 쿼리 결과의 보안: AI 컨텍스트에 DB 조회 결과가 남습니다. 개인정보나 민감 데이터가 포함된 테이블은 위임 범위에서 제외해야 합니다.
• 스키마 이해의 한계: AI가 테이블 간 관계를 완벽히 이해하지 못하면 잘못된 JOIN이나 누락된 조건이 나올 수 있습니다. 분석서를 그대로 신뢰하지 않고 교차 검증하는 이유입니다.
• DML은 위임 범위 밖: INSERT, UPDATE, DELETE는 AI에게 위임하지 않습니다. 데이터 변경은 되돌리기 어렵고, 영향 범위를 AI가 판단하기 어렵습니다.

4. 경계선 — 무엇을 맡기고 무엇을 직접 할 것인가

4-1. 판단 기준

두 영역의 경험을 종합하면, AI 위임의 적합도를 결정하는 기준이 보입니다.

기준	위임 가능	주의 필요	위임 부적합
가역성	읽기 전용 (SELECT, 상태 조회)	백업+검증+롤백 가능한 쓰기	즉시 효력, 되돌리기 불가
환경 일치	로컬 == 서버	차이를 사전 확인 후 진행	로컬 ≠ 서버, 확인 불가
긴급도	여유 있는 정기 작업	—	긴급 대응 (AI는 느리다)
검증 가능성	사람이 결과를 교차 검증 가능	—	실행 즉시 효력, 검증 전 영향 발생

가역성을 읽기/쓰기 이분법으로 나누면 현실과 맞지 않습니다. 인증서 교체는 쓰기지만, 백업 후 실행하고 검증한 뒤 실패 시 롤백할 수 있습니다. 중요한 것은 “되돌릴 수 있는가”이고, 그 조건은 백업·검증·롤백 절차가 갖춰져 있느냐입니다.

4-2. 실무 적용

판단 기준을 실무 작업에 적용하면 다음과 같습니다.

작업	적합도	방식
서버 상태 조회	적합	서브 에이전트 위임
DB 데이터 정합성 분석 (SELECT)	적합	AI 분석 → 교차 검증
반복 쿼리 자동화	적합	쿼리 생성 + 실행 위임
정기 인증서 교체	주의 필요	플래닝 확인 → 백업 → AI 실행 → 교차 검증
복잡한 병합 kubeconfig 수정	주의 필요	로컬/서버 환경 차이로 예기치 못한 결과 가능
긴급 설정 변경	부적합	사람이 직접 접속하여 처리
DML (데이터 변경)	부적합	되돌리기 어려움, 영향 범위 판단 불가

4-3. 인증서 교체를 다시 맡긴다면

장애를 겪은 뒤 인증서 교체를 “적합”에서 “주의 필요”로 격하했습니다. 하지만 앞으로 사용하지 않겠다는 의미는 아닙니다.

사람이 직접 교체해도 실수는 발생합니다. 4개 클러스터 × 3대 서버를 수동으로 교체하다 한 곳을 빠뜨리는 것은 사람에게도 일어나는 실수입니다.

차이는 작업 전 플래닝의 구체성입니다. 장애 이전에는 “인증서 교체해줘”라고 위임했습니다. 지금은 다음 절차를 거칩니다.

1. AI에게 교체 계획을 먼저 요청합니다. 어떤 서버의 어떤 컨텍스트를 어떤 방식으로 진행할 것인지 구체적인 플래닝을 받습니다.
2. 플래닝을 검토하고 승인합니다.
3. AI가 실행합니다. 백업을 먼저 만들고, kubectl config set-credentials로 인증서 필드만 갱신합니다.
4. AI가 모든 컨텍스트를 검증합니다.
5. 로컬에서 교차 검증하여 최종 확인합니다.

“알아서 해줘”에서 “계획을 보여줘 → 확인 → 실행 → 함께 검증”으로 바뀐 것입니다.

5. 교훈

1. 가역성과 검증 가능성이 위임의 기준입니다. SELECT는 맡기고, 되돌릴 수 없는 쓰기는 직접 합니다. 백업+검증+롤백 절차가 갖춰진 쓰기는 주의하며 위임할 수 있지만, 처음부터 “적합”이라고 판단한 것은 실수였습니다.

2. “알아서 해줘”가 아니라 “계획을 보여줘”입니다. AI에게 실행을 바로 맡기는 것이 아니라, 구체적인 플래닝을 먼저 받고 검토한 뒤 실행하는 구조가 안전합니다. 사람이 해도 실수하는 작업이라면, AI가 하더라도 검증 체계가 핵심입니다.

3. 같은 “인프라”라도 위험도 스펙트럼이 있습니다. SSH 서버 설정 변경과 DB SELECT 조회는 같은 인프라 영역이지만, 위험도가 완전히 다릅니다. 작업별로 가역성·환경 일치·긴급도·검증 가능성을 판단해야 합니다.

이 글은 Claude와 함께 작업했습니다.