요약

  • 조직이 Codespaces 보존 정책을 수정하거나 없애도, 기존 작업공간에 배정된 기간은 바뀌지 않는다. 새 조건은 생성 시점에 적용된다.
  • 멈춘 작업공간도 저장공간을 사용한다. 자동 삭제는 푸시하지 않은 변경이 있어도 진행되므로, 비용을 줄이려면 환경의 퇴거와 작업 결과의 반출을 따로 확인해야 한다.

작업은 저장했다. 창도 닫았다. 그러니 회사가 개발 환경을 정리해도 괜찮다는 판단에는 두 번의 비약이 있다. 파일을 저장한 곳은 원격 저장소가 아니라 클라우드의 가상 머신일 수 있다. 브라우저 탭을 닫아도 그 머신이 멈추는 것은 아니다.

GitHub Codespaces는 다시 접속해 작업을 이어갈 수 있는 편의를 판다. 이 편의가 비용 관리와 만나는 지점에서는 ‘닫았다’, ‘멈췄다’, ‘삭제했다’가 서로 다른 동사다. 마지막 동사를 잘못 고르면 청구 대상 자원과 함께 아직 밖으로 나오지 않은 작업까지 정리된다.

그렇다면 보존 기간만 줄이면 될까. GitHub의 조직 정책 문서는 더 묘한 답을 준다. 기간은 작업공간을 만들 때 정해지고, 이후 정책을 수정하거나 삭제해도 기존 작업공간의 기간은 그대로다.

절약 방침에는 입사일이 있다

가령 조직이 삼십 일을 칠 일로 줄였다고 하자. 이는 설명을 위한 가정이다. 과거 삼십 일을 배정받은 환경은 새 방침만으로 칠 일짜리가 되지 않는다. 앞으로 만드는 환경이 적용 가능한 새 조건을 받는다. 비용 절감 회의에서 가장 빨리 바뀌는 것은 설정 화면이고, 오래된 환경의 운명은 별도의 일이다.

이 방식에는 안정성이라는 장점이 있다. 이미 받은 작업 시간을 새 정책이 갑자기 깎지 않는다. 대신 관리자는 현존하는 환경을 직접 살펴야 한다. 정책의 현재 값만으로 전체 자원이 언제 사라지는지 알 수 없기 때문이다.

Codespaces 생명주기 문서는 실행 중의 컴퓨팅 사용과 중지 후에도 남는 저장공간 사용을 구분한다. 저장공간 사용은 삭제할 때까지 계속 누적된다. 삭제는 그다음 사용을 멈추지만, 해당 월에 이미 쌓인 사용량을 지우지는 않는다.

조직의 통제 범위 역시 저장소 간판만으로 정해지지 않는다. 조직 보존 정책은 조직이 비용을 내는 Codespaces에 적용된다. 조직 소유 저장소에서 만들었어도 개인이 비용을 부담하는 환경은 그 이유만으로 정책 대상이 되지 않는다. 생성 시 적용되는 조직·저장소·개인 설정의 제한 가운데 가장 짧은 기간이 쓰인다.

실제 절감액을 계산하려면 해당 회사의 환경 목록, 배정 기간, 아직 푸시하지 않은 작업, 청구 내역이 필요하며 공개 문서에는 이 자료가 없다. 다만 최신 설정이 오래된 저장공간 사용을 곧바로 끝내주지 않는다는 작동 방식은 분명하다.

삭제 시계는 코드의 가치를 모른다

자동 삭제 안내에 따르면, 기본적으로 중지 상태에서 삼십 일 동안 사용하지 않은 환경은 삭제된다. 다시 연결하면 기간이 초기화되고, 멈춘 뒤 다시 계산한다. 따라서 만든 지 오래된 환경이 반드시 먼저 삭제되는 것은 아니다.

개인 설정은 영 일부터 삼십 일까지 가능하다. 영 일은 중지할 때 삭제한다는 뜻이며, 유휴 시간 초과로 멈추는 경우도 포함한다. 숫자 하나로 대기 중인 저장공간을 줄일 수 있지만, 돌아와서 그대로 이어 쓰는 편의도 함께 줄어든다.

더 중요한 조건은 작업의 상태다. 자동 삭제는 푸시하지 않은 변경이 있어도 진행된다. 저장 버튼을 눌렀다는 기억이 원격 저장소의 확인을 대신할 수 없다. 삭제 시계는 회사가 그 코드에 얼마나 많은 시간을 들였는지 묻지 않는다.

일부 개인용 환경에는 수동으로 지울 때까지 유지하는 선택지도 있다. 그동안 저장공간 사용은 계속된다. 조직의 보존 정책을 적용받는 조직 소유 환경에서는 이 유지 기능을 사용할 수 없다. ‘최대 삼십 일’이라는 짧은 문장으로 모든 환경의 수명을 설명하면 이런 차이가 사라진다.

반출한 상자를 열어봐야 한다

GitHub는 환경을 실행하지 않고도 변경을 브랜치로 내보내는 방법을 제공한다. 지출 제한 등으로 환경을 다시 열 수 없을 때 유용한 출구다. 하지만 현재 체크아웃된 브랜치만 대상이며, 다른 브랜치는 함께 나오지 않는다. 100 MiB를 넘는 파일은 해당 푸시와 내보내기를 막는다.

그래서 내보내기 버튼을 누른 기록보다 도착한 내용이 중요하다. 필요한 변경이 목적지 브랜치에 있는지, 다른 브랜치에 독자적인 작업이 남았는지, 개발 환경을 다시 만들 수 있는지를 확인해야 한다. 브랜치 하나를 옮겼다고 작업실 전체의 복제본을 확보한 것은 아니다.

회사에 필요한 정리 계획은 여기서 선명해진다. 새 환경의 보존 조건을 정하고, 기존 환경마다 작업을 회수하고, 남겨둘 편의의 가치를 판단한다. 설정 화면은 첫 번째 일을 해준다. 나머지 두 가지를 누군가의 일로 정해야 절약이 실제 공간까지 도착한다.