state lock 오류가 났다고 바로 stale lock은 아닙니다. 내 터미널이 끝났어도 CI runner나 다른 작업이 같은 state를 쓰고 있을 수 있습니다. 잠금을 무시하면 기다리는 문제를 동시 쓰기 문제로 바꿀 수 있습니다.
같은 잠금을 보고 있는지 먼저 확인
오류의 Lock ID, Operation, Who, Created, Path와 현재 backend·workspace를 비밀값 없이 기록합니다. CI 작업 ID·실행 상태·runner 프로세스를 함께 맞춥니다. 예를 들어 노트북의 plan이 잠금을 얻지 못해도 동일 workspace의 배포 job이 아직 apply 중이면 정상적인 충돌 방지입니다. Created가 오래됐다는 사실만으로 그 작업이 죽었다고 판단할 수 없습니다.
Terraform 잠금 문서는 backend별 잠금 지원과 자신의 남은 잠금만 해제해야 하는 조건을 설명합니다. -lock=false로 작업을 통과시키는 것은 잠금 소유자를 확인하는 절차가 아닙니다. Ctrl+C 한 번이 언제나 stale lock을 만든다는 설명도 정확하지 않습니다.
실행 중·미확인·종료 확인을 다른 상태로 기록
실행 중이면 종료 또는 정상적인 중단 절차를 기다립니다. runner에 접근하지 못해 상태를 모르면 해제 보류로 기록합니다. 소유 작업 종료가 확인됐고 같은 backend·workspace에서 새 쓰기를 시작하지 않도록 조정했다면, backend의 감사 기록과 state 버전·백업을 보존한 뒤 공식 절차의 해제를 검토할 수 있습니다. 잠금 ID를 추측하거나 다른 workspace의 ID를 재사용하지 않습니다.
해제 뒤에는 자동 apply보다 계획의 변경·삭제·교체 내용을 먼저 검토합니다. 잠금이 사라진 것은 리소스와 state가 일치한다는 증거가 아닙니다. 여기서는 원격 state에 접근하거나 강제 해제를 실행하지 않았으며, 특정 backend 복구 성공을 보고하는 글이 아닙니다.