AI에게 SSH 서버 작업을 맡길 때 제가 꼭 확인하는 7가지

AI 코딩 도구로 웹사이트를 만들기 시작했을 때는 주로 로컬 파일을 고쳤습니다. 화면을 바꾸고 글을 추가한 뒤 문제가 생겨도 원본을 다시 열거나 이전 코드와 비교하면 됐습니다. 하지만 완성된 사이트를 운영하려면 결국 서버에 결과물을 올려야 했습니다.

현재 minml은 Astro로 만든 정적 사이트를 기존 서버에 직접 배포합니다. 저는 명령어를 모두 외워 입력하기보다 Codex 같은 AI 도구에 작업 목적을 설명하고, 로컬 확인부터 SSH 접속과 배포 후 점검까지 도움받고 있습니다. 편리하지만 운영 서버는 연습용 폴더와 다릅니다. 한 번 잘못 지운 파일은 방문자가 보는 사이트를 바로 망가뜨릴 수 있고, 같은 서버의 다른 사이트까지 영향을 받을 수도 있습니다.

그래서 저는 “서버에 접속해서 알아서 처리해줘”라고만 요청하지 않습니다. AI가 어떤 모델인지보다 어디까지 읽어도 되는지, 무엇을 바꿔도 되는지, 결과를 어떻게 확인할지를 먼저 정합니다. 이 글은 SSH 설치법이나 모든 서버에 통하는 보안 지침이 아닙니다. minml을 실제로 운영하면서 정한 일곱 가지 확인 순서입니다.

1. 접속하자마자 대상 서버부터 확인합니다

가장 먼저 확인하는 것은 파일이 아니라 서버의 정체입니다. SSH 별칭이 비슷하거나 여러 서버를 관리한다면 엉뚱한 장비에 접속한 상태에서도 명령 자체는 정상적으로 실행될 수 있습니다.

이번 글을 준비하면서도 처음에는 SSH 별칭으로 접속이 가능한지만 확인했습니다. 파일을 바꾸지 않고 호스트 이름, 현재 위치와 웹 서버 상태를 읽었습니다. 아래 명령과 출력에서는 실제 접속 정보와 서비스 이름을 플레이스홀더로 바꿨습니다.

ssh <서버별칭> "hostname; systemctl is-active <웹서버>"

<호스트 이름>
active

이 두 줄만으로 서버 구성이 모두 안전하다고 판단할 수는 없습니다. 다만 작업을 시작할 대상과 웹 서버의 현재 상태를 기록하는 첫 기준은 됩니다. 이후 문제가 생기면 “원래부터 중지돼 있었는지, 작업 뒤에 멈췄는지”를 구분하기도 쉬워집니다.

접속 계정의 권한도 확인합니다. 권한이 클수록 편하지만 잘못된 명령이 영향을 줄 범위도 넓습니다. AI에게 관리자 권한이 있다고 해서 넓은 범위의 수정까지 자동으로 허용한 것은 아니라고 생각합니다.

2. 처음에는 읽기 전용으로 조사합니다

서버 구조를 모르는 상태에서 수정과 조사를 한 번에 시키지 않습니다. 먼저 디렉터리 목록, 링크 대상, 실행 중인 서비스와 공개 주소의 응답만 확인하게 합니다. 제가 자주 요청하는 범위는 다음과 같습니다.

• 대상 사이트의 배포 디렉터리가 어디인지
• 현재 공개 중인 릴리스가 무엇인지
• Nginx가 어떤 디렉터리를 바라보는지
• 홈페이지와 주요 글이 어떤 HTTP 상태로 응답하는지
• 같은 서버에 다른 사이트가 있는지

이번 조사에서 minml 서버에는 releases/ 디렉터리와 current 링크가 있었고, current는 기존 릴리스 하나를 가리키고 있었습니다. 서버에는 minml과 관련 없는 사이트도 함께 있었습니다. 이 사실을 먼저 알았기 때문에 이후 작업 범위를 minml 배포 디렉터리로 한정할 수 있습니다.

읽기 전용 조사를 별도 단계로 두면 AI가 제시한 다음 작업도 검토하기 쉬워집니다. 실제 구조를 보기도 전에 예상 경로를 만들어내거나, 사용하지 않는 배포 방식을 전제로 설명하는 일을 줄일 수 있기 때문입니다.

3. 수정할 대상과 건드리지 않을 대상을 함께 적습니다

“minml을 배포해줘”라는 문장에는 사이트 코드, Nginx 설정, 인증서, 서버의 다른 디렉터리 중 어디까지 건드려도 되는지가 없습니다. 그래서 작업을 요청할 때 포함할 대상뿐 아니라 제외할 대상도 적습니다.

이번 글을 배포한다면 범위는 다음처럼 정할 수 있습니다.

구분	범위
수정 대상	로컬 minml 프로젝트, 새 글과 대표 이미지, minml의 새 릴리스 디렉터리
확인 대상	현재 릴리스 링크, Nginx 상태, minml 공개 주소와 사이트맵
제외 대상	같은 서버의 다른 사이트, 데이터베이스, 인증서와 방화벽 설정

이 구분은 AI를 믿지 못해서만 필요한 것이 아닙니다. 사람에게 서버 작업을 부탁할 때도 작업 범위가 명확해야 결과를 검토할 수 있습니다. “필요하면 다른 것도 정리” 같은 표현은 운영 서버에서는 사용하지 않습니다. 새 글 배포에 데이터베이스나 인증서 변경은 필요하지 않으므로 처음부터 제외합니다.

4. 변경 전에 복구할 지점을 확인합니다

백업이 있다는 말과 지금 작업을 되돌릴 수 있다는 말은 같지 않습니다. 백업 파일이 있어도 어디에 있는지 모르거나 복구 방법을 시험하지 않았다면 급할 때 바로 쓰기 어렵습니다.

minml은 소스와 이미지, 설정을 로컬 프로젝트에 보관하고 서버에는 배포 결과물을 릴리스별로 나눠 둡니다. 자세한 구성은 Astro 블로그 백업과 복구 방법에 정리했습니다. SSH 작업을 시작하기 전에는 최소한 다음 세 가지를 확인합니다.

1. 로컬 소스가 빌드 가능한 상태인지
2. 현재 공개 중인 릴리스가 무엇인지
3. 새 배포가 실패했을 때 어느 릴리스로 돌아갈지

이전 릴리스를 지우는 일은 새 릴리스 배포와 별도 작업으로 취급합니다. 새 결과물이 정상이라고 확인하기도 전에 과거 파일부터 정리하면 롤백할 선택지가 사라집니다. 디스크 정리가 필요하더라도 보존할 개수와 삭제할 정확한 경로를 다시 확인한 뒤 진행하는 편이 안전합니다.

5. 승인은 명령의 안전 보증서가 아닙니다

이번 SSH 접속 시험에서는 로컬 작업 환경의 제한 때문에 처음에 minml 별칭을 읽지 못했습니다. 이후 네트워크가 필요한 읽기 전용 접속 명령과 목적을 확인한 뒤 승인했고, 그제야 실제 서버에 접속했습니다. 제한을 몰래 우회한 것이 아니라 경계 밖 작업을 따로 드러낸 셈입니다.

OpenAI 공식 문서는 Codex의 샌드박스를 에이전트가 기본적으로 접근할 수 있는 파일과 네트워크 범위를 정하는 경계로 설명합니다. 그 경계를 넘어야 할 때는 승인 흐름이 작동합니다. 하지만 제가 승인 버튼을 누른 사실이 원격 명령의 내용까지 안전하다는 뜻은 아닙니다. 승인은 실행 권한이고, 명령 검토는 별도의 판단입니다.

그래서 승인 요청을 볼 때는 다음을 확인합니다.

• 왜 서버 접속이 필요한가
• 읽기만 하는가, 파일을 바꾸는가
• 명령에 대상 경로가 정확히 적혀 있는가
• 재귀 삭제나 넓은 와일드카드가 포함돼 있는가
• 실패했을 때 기존 사이트가 그대로 남는가

특히 삭제 명령은 축약된 경로나 아직 값이 정해지지 않은 변수에 기대지 않습니다. 서버 루트나 웹사이트 전체 디렉터리를 넓게 대상으로 삼지 않고, 먼저 실제 절대 경로를 출력해 확인합니다. AI가 승인을 요청했다는 이유만으로 그대로 허용하지 않고, 제가 요청한 목적과 명령이 일치할 때만 진행합니다.

6. 기존 파일 위에 덮지 않고 새 릴리스를 준비합니다

minml은 로컬에서 빌드를 마친 결과를 서버의 새 릴리스 디렉터리에 올린 뒤 current 링크를 바꾸는 방식으로 배포합니다. 자세한 글 작성 흐름은 Astro 블로그를 발행하는 과정에서 다뤘기 때문에 여기서는 AI 작업 통제에 필요한 부분만 설명하겠습니다.

중요한 점은 기존 공개 파일 위에 새 파일을 하나씩 덮어쓰지 않는 것입니다. 업로드가 중간에 끊기면 이전 HTML과 새 이미지가 섞인 상태가 될 수 있습니다. 새 릴리스 디렉터리를 별도로 준비하면 업로드와 파일 검사를 마칠 때까지 현재 사이트는 그대로 남습니다.

제가 AI에게 요청하는 순서는 다음과 같습니다.

1. 로컬에서 새 글을 포함해 전체 빌드
2. 생성된 페이지와 이미지 경로 검사
3. 서버에 새 릴리스 디렉터리 생성
4. 완성된 빌드 결과만 새 릴리스에 업로드
5. 새 릴리스 안의 주요 파일 존재 여부 확인
6. current 링크를 새 릴리스로 전환
7. 실패하면 직전 링크 대상으로 복구

이 구조는 전환 시간을 줄이고 롤백을 단순하게 만들지만, 저는 별도로 측정하지 않은 상태에서 “완전한 무중단 배포”라고 부르지는 않습니다. 웹 서버 설정, 캐시와 외부 서비스까지 포함하면 확인할 범위가 더 넓기 때문입니다.

7. 홈페이지 200만 보고 끝내지 않습니다

배포가 끝난 뒤 홈페이지가 열리는 것만으로 성공이라고 판단하면 새 글 누락, 잘못된 리디렉션과 404 설정을 놓칠 수 있습니다. 이번 글을 쓰기 전 서버에서 현재 기준을 실제로 확인했습니다.

확인 항목	작업 전 결과	의미
홈페이지	200	현재 사이트가 정상 응답
존재하지 않는 시험 주소	404	없는 페이지가 홈으로 위장되지 않음
통합한 과거 글 주소	301	새 글로 영구 이동
Nginx	active	웹 서버 실행 중
현재 릴리스	current 링크로 확인	복구 기준점 확보

새 글을 올린 뒤에는 여기에 새 주소의 200, 사이트맵 포함 여부, 대표 이미지의 200을 추가로 확인합니다. 기존 글 몇 편도 열어보고, 같은 서버의 다른 사이트가 정상인지도 확인합니다. 다른 사이트는 수정 대상이 아니지만 서버 공용 설정을 실수로 건드리지 않았는지 판단하는 지표가 됩니다.

빌드 성공과 배포 성공도 구분합니다. 빌드는 로컬 파일이 Astro 규칙에 맞는지 확인하지만, 서버에 잘못된 폴더를 올리거나 링크를 전환하지 못하는 문제까지 알려주지는 않습니다. 반대로 공개 주소가 열린다고 해서 사이트맵과 모든 이미지가 정상이라는 뜻도 아닙니다. 그래서 단계별 결과를 따로 확인합니다.

제가 실제로 사용하는 요청 방식

긴 보안 지침을 매번 새로 쓸 필요는 없지만, 목적과 경계는 짧게라도 명시합니다. 아래와 같은 형태로 요청하면 조사와 변경이 섞이는 것을 줄일 수 있었습니다.

먼저 SSH로 대상 서버와 현재 배포 상태를 읽기 전용으로 확인해줘.
결과를 보고한 뒤 새 릴리스를 준비하고, 변경이 필요한 명령은 실행 전에 알려줘.

수정 대상: minml의 새 릴리스와 current 링크
확인 대상: Nginx 상태, 새 글, 대표 이미지, 사이트맵, 301과 404
건드리지 않을 대상: 같은 서버의 다른 사이트, 데이터베이스, 인증서, 방화벽
실패 시: 기존 current 대상을 유지하거나 직전 릴리스로 복구

프로젝트에 반복해서 적용할 규칙은 AGENTS.md 같은 파일에 적어둘 수도 있습니다. 다만 규칙 파일이 있다고 해서 매번 결과 확인을 생략하지는 않습니다. 실제 서버 상태는 지난 작업 이후 달라질 수 있기 때문입니다.

AI에게 맡겨도 최종 범위는 제가 정합니다

AI 덕분에 제가 직접 외우지 못한 명령도 이해하고 실행할 수 있게 됐습니다. 그렇다고 운영 서버를 통째로 위임했다고 생각하지는 않습니다. AI는 파일과 상태를 빠르게 조사하고 반복 검사를 수행하지만, 어떤 사이트를 바꿀지와 어느 위험까지 감수할지는 운영자가 정해야 합니다.

제가 중요하게 보는 것은 AI가 한 번도 틀리지 않는다는 믿음이 아닙니다. 잘못된 판단이 나오더라도 실제 변경 전에 발견하고, 문제가 생겨도 이전 상태로 돌아갈 수 있는 과정입니다. 대상 서버 확인, 읽기 전용 조사, 범위 지정, 복구 지점, 승인 검토, 새 릴리스와 사후 점검을 나누는 이유도 여기에 있습니다.

앞으로 서버 작업 방식이 바뀌거나 실제 실패와 복구 사례가 생기면 이 글에 결과를 추가할 예정입니다. 지금까지의 결론은 간단합니다. AI에게 SSH 작업을 맡길 수는 있지만, “알아서”보다 “여기까지만, 이 순서로, 이 결과를 확인하며”라고 요청할 때 훨씬 안심할 수 있었습니다.

참고한 공식 문서

• Codex 샌드박스 설명
• Codex 승인과 보안
• Codex에서 SSH 호스트 연결하기