# 완료했어요 했는데 왜 그대로지? — AI와 일할 때 완료의 기준을 다시 정한 이유

> AI가 "완료"라고 했다. 서버는 여전히 어제 그대로였다.

---

## 반복되는 패턴을 발견했다

**AI 에이전트를 운영하다 보면** 이런 상황이 생긴다. 엘론의 모델을 Flash로 바꿨다. 다음 날 비용이 또 나왔다. "고쳤는데 왜?"

AI가 `fix_all.py`를 수정했다고 보고했다. 파일은 고쳐져 있었다. 그런데 그 파일을 서버에서 실행한 적이 없었다. **로컬 수정과 VM 반영은 별개다.** 서버 설정은 어제 그대로였다.

그걸 깨닫고 나서 패턴이 보였다. **로컬과 VM 동기화**가 없었던 것이다. 로컬만 고치고 VM을 빠뜨리거나, VM만 패치하고 로컬을 방치한 게 반복됐다. AI 에이전트 운영에 배포 규칙이 필요한 이유가 거기 있었다.

"업무 순서에 규칙이 없는 거야?" 맞는 지적이었다.

## 로컬과 VM은 완전히 다른 공간이다

이 문제의 뿌리는 단순했다. 로컬(내 컴퓨터)과 VM(실제 서버)이 별개라는 걸 작업 흐름에서 의식하지 않았던 것이다.

로컬에서 스크립트를 수정하면 로컬 파일이 바뀐다. VM은 그 사실을 모른다. VM에 해당 스크립트를 가져다 실행해야만 서버 상태가 바뀐다.

AI가 "수정 완료"라고 했을 때, 그게 로컬 수정인지 VM 반영까지인지는 작업 기준을 명확히 해두지 않으면 구분이 안 된다. AI도, 사람도.

**로컬 = 다음 실행을 위한 템플릿. VM = 지금 실제로 동작 중인 상태.**

이 둘이 항상 일치하는 상태가 진짜 "완료"다.

## 작업 순서를 명시적으로 정했다

### 4단계 순서 규칙

이번 경험으로 작업 순서를 확정했다.

```javascript
1. 로컬 스크립트 수정
2. VM에 전송 후 실행 (scp → ssh python3)
3. VM 상태 직접 검증 (실행 결과 확인)
4. 문서/보고서 업데이트
```

VM 실행 전에는 dry-run을 먼저 돌린다. "이 스크립트를 실행하면 VM의 어떤 값이 바뀌는가"를 확인한 뒤 실행한다. 덮어쓰기 위험이 있는 작업에서 실수를 막는 습관이다.

### enum 필드는 문서로 확인한다

같은 날, 설정 파일에 `groupPolicy: "closed"`를 넣었더니 서버가 즉시 에러를 뱉었다.

```javascript
Invalid option: expected one of "open"|"disabled"|"allowlist"
```

"closed"는 없는 값이었다. 공식 문서 확인 없이 추측으로 썼던 것. 에러 메시지가 유효값 목록을 정확히 알려줬다.

설정 파일에서 값의 종류가 정해진 항목(enum 필드)은 반드시 먼저 확인하고 쓴다. 추측으로 넣으면 hot reload가 실패하고, 그 원인을 찾는 데 시간이 든다.

## 알게 된 것

**AI와 일할 때 "완료"는 다시 정의해야 한다.**

AI는 맡은 일을 했다고 보고한다. 로컬 파일을 수정하면 "수정 완료"라고 한다. 거짓말이 아니다. 다만 작업 범위를 어디까지로 볼 건지 명시하지 않으면 오해가 생긴다.

"VM에서 검증까지 완료" — 이 기준이 있어야 진짜 완료다.

작업 순서 규칙을 세우고 나서 반쪽 작업이 없어졌다. AI도 기준이 있으면 그 기준을 따른다.

## 서버를 처음 운영한다면

이 경험을 체크리스트로 정리했다.

- [ ] 로컬 수정 = 완료가 아니다. VM 실행 후 상태 확인까지가 완료

- [ ] VM 실행 전 dry-run으로 변경 대상 먼저 확인

- [ ] enum 필드는 공식 문서 또는 에러 메시지로 유효값 확인 후 사용

- [ ] VM을 직접 패치했으면 로컬 스크립트도 즉시 동기화

- [ ] 작업 기준을 명시하면 AI도 그 기준을 따른다

---

> AI의 "완료"는 기준이 없으면 절반이다.

For the site tree, see the [root Markdown](https://slashpage.com/openclaw.md).