클라우드로 옮긴 뒤 약 일주일 동안은 노트북 없이 모바일에서 개발을 이어갈 수 있었다. 처음에는 WSL을 다시 켤 일이 많지 않을 것 같았다. 하지만 새 기능을 개발하며 npm 패키지를 설치하려는 순간 예상하지 못한 문제가 생겼다.
패키지 저장소에 연결되지 않았고, 확인 과정에서 DNS 조회와 관리형 프록시 연결 문제가 드러났다. 코드의 오류가 아니라 개발 환경의 네트워크 경로에서 막힌 작업이었다. 여러 설정을 확인해도 그 자리에서 해결되지 않아 기존 WSL2 Ubuntu를 다시 실행했다. 같은 패키지 저장소에 WSL에서는 정상적으로 접근할 수 있었다.
같은 프로젝트, 서로 다른 작업공간
그동안 Cloud에서 설정을 조정하고 새로운 Codex 작업 대화도 여러 번 만들었다. 처음에는 대화방만 바꾸는 것처럼 생각했다. 하지만 이전 작업공간에 남아 있던 미커밋 변경사항은 새 작업공간이나 WSL에 자동으로 옮겨지지 않았다. GitHub에 연결되어 있어도 마찬가지였다.
새 대화를 만든 것이 네트워크 오류의 원인이라는 뜻은 아니다. 네트워크 장애와 코드 동기화 문제는 별개였다.
WSL 저장소를 확인하니 GitHub의 최신 main보다 46개 커밋 뒤처져 있었다. WSL에도 별도의 미커밋 변경사항이 남아 있었다. Cloud의 미반영 코드와 WSL의 로컬 변경사항을 모두 보존하면서 작업을 이어가야 했다.
미반영 작업을 WSL에서 복구하다
Cloud 작업공간에는 17개 파일의 변경사항이 남아 있었다. 기존 작업을 덮어쓰지 않도록 별도 작업공간에 보존하고, 파일 일치 여부와 민감정보를 확인한 뒤 WSL로 옮겼다.
WSL에 남아 있던 미커밋 파일도 그대로 유지했다. 복원한 변경사항은 GitHub 최신 main 기준으로 충돌 없이 적용됐고, 자동 검증 결과는 다음과 같았다.
- 서버 측 자동 테스트 34개 통과
- 웹 자동 테스트 47개 통과
- 웹 프로덕션 빌드 성공
이후 별도 개발 브랜치에 커밋하고 Pull Request를 생성했다. 자동 검사는 통과했고, main 병합과 운영 배포는 기존 서비스에 미칠 영향을 더 확인하기 위해 보류했다.
다시 두 환경을 오가며
WSL이 멈췄을 때는 Cloud로 옮겼고, 이번에는 Cloud에서 막힌 작업을 WSL에서 이어갔다. 처음 Cloud를 설정할 때만 해도 이렇게 빨리 WSL을 다시 켤 줄은 몰랐다.
이번에는 두 환경에 남아 있는 변경사항을 하나씩 확인하는 데 예상보다 시간이 걸렸다. 다음에도 비슷한 상황이 생기면 먼저 각 작업공간의 커밋 여부부터 확인하게 될 것 같다. 당분간은 Cloud와 WSL을 모두 남겨 두고 필요한 쪽에서 작업을 이어갈 생각이다.