AI 코딩 에이전트 운영 규칙을 먼저 세운 날

## 들어가며

2026년 7월 13일 작업은 서비스를 새로 올리거나 장애를 처리한 날이 아니라, AI 코딩 에이전트를 운영 업무에 투입하기 전에 기준을 세운 날이었다. Cline이 서버 관리 작업을 도울 수 있으려면 명령 실행 능력만으로는 부족했다. 어떤 언어로 답할지, 기술 설명을 어떤 순서로 할지, 판단이 애매할 때 어디서 멈출지를 먼저 정해야 했다.

원문에는 Cline 규칙 파일을 만들고, 여러 서버의 SSH 접속 설정을 확인하고, 문서 저장 기준과 원격 파일 편집 도구의 역할을 정리한 과정이 남아 있다. 공개 글에서는 실제 호스트 이름과 주소, 내부 경로처럼 환경을 특정할 수 있는 값은 쓰지 않는다. 대신 server-a, server-b, server-c처럼 일반화해서, 작업의 의도와 운영상 의미를 중심으로 정리한다.

## 운영 환경과 고민

운영 환경에는 여러 서버가 있었다. 각 서버는 SSH 설정에 등록된 별칭으로 접근했고, 역할도 서로 달랐다. 이런 환경에서 AI 에이전트를 함께 쓰면 반복 작업과 문서화에는 도움이 되지만, 규칙 없이 사용하면 응답 방식과 작업 흐름이 들쑥날쑥해질 수 있다. 그래서 먼저 에이전트가 따라야 할 운영 기준을 파일로 남기는 일이 필요했다.

핵심은 한국어 응답, 기술 설명 우선, 변경 이유를 먼저 설명한 뒤 명령어를 제시하는 흐름이었다. 또한 확실하지 않은 부분은 임의로 처리하지 않고 사용자에게 확인하도록 했다. 서버 운영에서는 작은 오해가 설정 변경이나 접속 장애로 이어질 수 있다. 에이전트가 빠르게 처리하는 것보다, 멈춰야 할 때 멈추는 기준을 갖는 것이 더 중요했다.

문서 저장 기준도 함께 정리해야 했다. 작업내역, Docker 관련 문서, 스크립트 문서가 각자 다른 방식으로 쌓이면 나중에 자동 기록이나 검색을 붙이기 어렵다. 원문에는 문서 유형별 저장 위치와 기존 작업내역 양식을 참고한 내용이 남아 있었다. 공개 글에서는 구체적인 내부 저장소 경로나 디렉터리 구조는 제외하고, 문서 분류와 형식을 표준화했다는 점만 남긴다.

## 문제를 풀어간 과정

먼저 Cline의 글로벌 규칙 파일을 새로 만들었다. 응답 첫 줄에 테스트 헤더를 출력하도록 하고, 한국어 응답과 기술 설명 우선 원칙을 정의했다. 변경 작업에서는 이유를 먼저 설명한 뒤 명령어를 제시하도록 했고, 애매한 내용은 사용자 확인을 거치도록 했다. 이는 단순한 말투 설정이 아니라, 운영자가 기대하는 작업 절차를 에이전트에게 명문화한 작업이었다.

다음으로 운영자 역할과 서버 관리 범위를 규칙에 반영했다. 원문에는 실제 서버 이름이 기록되어 있었지만, 여기서는 server-a, server-b, server-c로 바꿔 적는다. 중요한 것은 에이전트가 여러 서버를 같은 기준으로 다루되, 접속 방식과 역할을 혼동하지 않도록 기준을 세웠다는 점이다.

이후 SSH 접속 환경을 확인했다. SSH config에 등록된 항목을 분석해 각 서버의 접속 별칭, 포트, 사용자 정보가 어떻게 구성되어 있는지 살폈다. 실제 HostName, 내부 IP, 공인 IP, 계정명은 공개 문서에 남기면 안 되므로 제외한다. 운영 관점에서 의미 있는 부분은 에이전트가 정해진 별칭을 기준으로 서버에 접근할 수 있고, 이 접속 방식이 규칙에 반영되었다는 사실이다.

주의할 점도 있다. SSH 설정이나 접속 규칙을 변경할 때는 실행 전 기존 설정을 백업하고, 현재 접속 세션을 유지한 상태에서 별도 터미널로 새 접속이 되는지 확인해야 한다. 설정을 잘못 바꾸면 원격 접속 자체가 막힐 수 있기 때문에, 운영 중인 서버에서는 작은 수정도 검증 절차와 함께 진행해야 한다.

문서 저장 규칙도 같은 흐름으로 정리했다. 작업내역, Docker 문서, 스크립트 문서를 분류하고, 기존 작업내역 파일 형식을 참고해 앞으로도 같은 구조로 기록할 수 있게 했다. 마지막으로 VS Code SSH FS 확장 프로그램의 역할을 검토했다. 이 도구는 파일 편집, 탐색, 생성과 같은 작업에는 적합하지만 Shell 명령 실행, Docker 관리, 서비스 제어에는 맞지 않았다. 그래서 파일 편집은 SSH FS로, 명령 실행과 서버 관리는 Cline으로 맡기는 방식이 자연스러웠다.

## 검증하면서 확인한 것

검증은 먼저 규칙 파일에서 시작했다. 새로 만든 규칙 파일의 전체 내용을 확인하고, 줄 수와 섹션 수를 점검했다. 테스트 헤더가 실제 응답에 반영되는지도 확인했다. 규칙 파일은 작성 자체보다 실제 동작 여부가 중요하다. 에이전트가 규칙을 읽고 기대한 방식으로 응답해야 운영 절차로 쓸 수 있기 때문이다.

다음으로 SSH 접속 환경을 검증했다. 여러 서버의 SSH config 항목을 살펴보고, server-a를 통해 문서 저장소의 작업내역 목록을 조회했다. 원문에는 기존 작업내역 파일 개수까지 확인한 기록이 있다. 공개 글에서는 내부 경로와 주소를 제외하지만, 에이전트가 문서 위치에 접근할 수 있고 기존 기록을 읽을 수 있다는 점은 중요한 검증 결과였다.

마지막으로 문서 양식과 도구 역할을 확인했다. 기존 작업내역 파일들이 일관된 형식으로 관리되고 있는지 보고, 그 양식을 이후 기록의 기준으로 삼을 수 있는지 판단했다. SSH FS에 대해서는 할 수 있는 일과 없는 일을 나눠 보았다. 파일 편집 도구에 명령 실행까지 기대하지 않고, Cline에는 서버 명령과 Docker 관리 같은 실행 작업을 맡기는 식으로 경계를 세운 것이다.

## 운영하면서 배운 점

이번 작업에서 가장 크게 남은 점은 AI 에이전트 도입도 운영 표준화의 일부라는 것이다. 에이전트가 명령을 실행할 수 있다고 해서 곧바로 운영에 투입할 수 있는 것은 아니다. 응답 방식, 확인 절차, 문서 저장 기준, 서버 접속 방식이 먼저 정리되어야 한다. 그래야 사람이 기대하는 흐름과 에이전트의 행동이 어긋날 가능성이 줄어든다.

또 하나는 도구를 역할에 맞게 나눠야 한다는 점이다. SSH FS는 파일을 열고 수정하는 데 강점이 있고, Cline은 명령 실행과 서버 관리 흐름을 다루는 데 더 적합하다. 문서 저장 규칙은 별도로 정리해 두어야 작업 기록이 흩어지지 않는다. 결국 이 날의 작업은 눈에 띄는 구축보다, 앞으로 자동화와 문서화가 흔들리지 않게 만드는 기반 정리에 가까웠다.

## 해시태그

#AI에이전트 #Cline #서버운영 #SSH설정 #운영표준화 #문서자동화 #홈랩 #VSCode #작업내역 #인프라관리