나도 개발자로 9년 정도 일했기에 크고 작은 사고를 쳤다. 정확한 내용은 기적은 잘 나지 않지만, rm 옵션이나 파라미터 순서를 잘못 써서 자료를 날린 다거나 DB 명령을 잘못해서 인덱스가 꼬인다거나 하는 일들 말이다. 작업하다가 1~2시간 짜리 내 로컬 작업을 날리는 일도 물론 있었다. 복구 되기도 하고, 백업을 소홀히 해서 복구를 못하는 경우도 있다.
코딩과 개발이 주 업무가 아닌 경력으로 넘어오면서 제품의 장애로 이어지거나 개발 과정에 누가되는 그런 일은 거의 없지만, 역시 컴퓨터를 교체하거나 부주의로 개인 자료를 날리기도 한다. 어제도 폴더를 하나 날려 먹었다.
나는 업무 log와 회의록 등을 Markdown형식으로 관리하는데 이를 위해 VSCode를 잘 쓰고 있다. 하지만 VSCode는 문서보다는 코드개발을 위해 만들어진 도구이다보니 Markdown 문서를 관리하는데 최적화된 에디터가 새로운 것이 뭐가 있는지 탐색하다가 Zettlr 라는 오픈소스 마크다운 에디터를 테스트 해보고 있었다. 나름 흥미롭게 이것저것 시도해보다가 Zettlr의 Workspace에 내 기존 폴더를 추가 했다가 Delete를 했다. Delete를 하니 정말 삭제할거냐고 창이 떴다. 당시 내 생각은
- 실제 폴더를 삭제하는게 아니라 Workspace에서 참조를 삭제하는 기능이겠지?
- 삭제하더라도 Trash에서 살릴 수 있겠지?
라는 생각으로 Yes를 눌렀다.
그런데 파일도 사라졌을 뿐 아니라 Trash에서도 찾을 수 없었다!
Zettlr 의 FAQ의 관련 항목을 찾아보니 삭제하면 Trash로 간다고 되어있었다. 실제로 테스트를 해본 결과 간단한 폴더는 Trash로 잘 이동한다. 하지만 내가 날린 폴더와 비슷한 폴더로 테스트 해보았더니 Trash에 남지 않고 날라가는 것이 재현되었다! 내 폴더는 Sub 폴더도 여러 깊이로 되어있고, Text포맷이 아닌 다른 문서도 있어서 그런게 아닐까 원인이 예상되었다. 하지만 그저 파일럿으로 테스트하는 프로그램이었으니 앞으로 사용을 안 하면 되고 이런 상황이 되니 정확한 원인을 찾아서 뭐하리.. 하는 생각이 들어 정확한 재현 시나리오를 찾는 것은 안하기로 했다.
이것은 Zettlr 프로젝트의 잘못도 아니고, 오픈소스 생태계의 잘못도 아니고, Mac을 만든 Apple의 잘못도 아니고 그저 내 부주의의 결과다. 아주 중요한 폴더는 아니였지만 마음에는 꽤 충격이 있었다. 이에 반성문으로서 블로그에 기록을 님긴다.
결론
- 믿을 수 있는 VSCode 계속 쓰자
- ‘혹시나’ 했을때 ‘역시나’가 벌어진다.
- 백업을 잘하자