조사하다가 손이 미끄러지는 순간

한 줄 요약

조사 중에 무언가를 바꾸면, 그 뒤로 우리가 보는 모든 값이 원래 값인지 우리가 만든 값인지 알 수 없게 된다. 꼭 바꿔야 하면 바꾸기 전 상태를 먼저 굳히고, 바꾸고, 확인하고, 되돌린다.

왜 이게 필요했나

고객사 조사는 대개 읽기 권한으로 시작한다. 그런데 반나절쯤 지나면 반드시 이런 순간이 온다 — "이 설정값만 잠깐 올려 보면 바로 알 수 있을 텐데." 실제로 그렇다. 그 값을 올리면 5분 만에 답이 나온다. 문제는 그 5분 뒤의 세계다.

바꾼 뒤에는 세 가지가 동시에 흐려진다. 첫째, 지금 보이는 증상이 원래 증상인지 우리가 만든 증상인지 알 수 없다. 둘째, 고객이 그 사이에 본 로그와 지표가 오염된다. 셋째, 나중에 "언제부터 이렇게 됐죠" 라는 질문에 우리가 답의 일부가 된다.

여기서 흔한 오해가 하나 있다. "작은 변경이니 괜찮다" 는 것이다. 작은 변경일수록 되돌리는 것을 잊는다. 그리고 되돌렸다고 믿는 것과 되돌렸다는 것이 증명되는 것은 다르다.

어떻게 동작하나

순서는 네 단계다.

1  굳힌다   바꾸기 전 상태를 지문으로 기록한다 (파일 해시·크기·권한)2  바꾼다   한 건만, 무엇을 왜 바꾸는지와 되돌리는 명령을 함께 적고3  확인한다 바꾼 것이 의도한 효과를 냈는지 값으로 본다4  되돌린다 되돌린 뒤 1번의 기록과 견주어 다르지 않음을 보인다

1번이 가장 자주 빠진다. 굳혀 두지 않으면 4번에서 증명할 것이 없다. "원래대로 되돌렸습니다" 는 말은 검증할 수 없는 문장이고, 고객은 그 말을 믿을 수도 안 믿을 수도 없다. 반면 "되돌린 뒤 스냅샷과 견주었더니 내용이 다른 파일이 0개입니다" 는 확인할 수 있는 문장이다.

굳히는 기록에는 무엇을 담아야 하나. 파일의 내용 지문(sha256) 과 크기 와 권한은 반드시 담는다. 여기에 수정 시각도 담되, 비교할 때는 따로 다룬다. 되돌린 파일은 내용이 같아도 수정 시각이 다르기 때문이다 — 이것은 실패가 아니라 우리가 손댄 자국이다. 자국을 지우려 하지 말고 보고서에 적는다.

그런데 그보다 먼저 물어야 할 것이 있다. 정말 바꿔야 답이 나오는가. 많은 경우 같은 질문에 읽기 전용으로 답하는 길이 있다. 설정 파일을 열어 값을 읽고, 데이터베이스를 읽기 전용으로 열어 세고, 로그를 세고, 이미 있는 조회 도구를 돌려 본다. 이 길을 30분쯤 찾아보고 나서 바꾸기로 결정해도 늦지 않다.

읽기 전용인지 아닌지를 스스로 속이지 않는 방법은 쓴 명령을 기록하는 것이다.

굳히는 범위도 정해야 한다. 서버 전체를 지문으로 뜨면 시간이 오래 걸리고, 그 사이에도 로그가 자라기 때문에 다음 비교가 온통 빨강이 된다. 반대로 바꿀 파일 하나만 뜨면 그 옆에서 딸려 바뀐 것을 놓친다. 실무에서는 바꿀 대상이 속한 디렉터리 한 겹을 뜬다 — 설정 디렉터리를 통째로 굳히면, 편집기가 만든 백업 파일이나 임시 파일이 남았을 때도 그대로 드러난다. 로그처럼 계속 자라는 자리는 범위에 넣되 비교할 때 따로 다루거나, 애초에 범위 밖으로 두고 그 사실을 적어 둔다.

굳힌 파일 자체도 안전한 자리에 둔다. 조사 대상 디렉터리 안에 스냅샷을 만들면 그 파일이 다음 비교에서 '새로 생긴 파일' 로 잡히고, 더 나쁘게는 우리가 고객 서버에 파일을 하나 남긴 것이 된다. 스냅샷과 기록은 우리 작업 디렉터리에 두고, 넘길 때 함께 넘긴다. 답마다 어떤 명령으로 얻었는지 적어 두면, 그중에 UPDATE 나 리다이렉션이 섞여 있는지가 눈에 보인다. 적지 않으면 "조회만 했다" 는 기억만 남는다.

현장에서 만나는 모습

첫째, 바꾸는 것은 한 번에 하나다. 두 가지를 같이 바꾸면 효과가 어느 쪽에서 왔는지 모른다. 그리고 되돌릴 때도 하나씩 되돌려야 무엇이 남았는지 안다.

둘째, 되돌리는 명령을 바꾸기 전에 적는다. 바꾼 뒤에 적으려 하면 원래 값을 기억에 의존하게 된다. 3이었는지 30이었는지는 30분 뒤에 놀랍도록 흐려진다.

셋째, 승인을 문장으로 남긴다. 조사 중의 임시 변경도 누군가의 동의를 받는다. "운영팀 최 과장 구두 승인 13:40" 한 줄이면 충분하다. 이 줄이 없으면 나중에 그 변경은 우리가 몰래 한 것이 된다.

넷째, 되돌림을 증명할 때 수정 시각 차이는 숨기지 않는다. 내용이 같고 시각만 다르면 그대로 "내용은 동일, 수정 시각만 변경" 이라고 적는다. 시각까지 원래대로 맞춰 놓으면 그때부터는 우리가 흔적을 지운 것이 된다.

다섯째, 이것은 승인된 변경 작업과 다른 이야기다. 계획을 세우고 중단 기준을 정하고 고객 승인을 받아 반영하는 변경은 별도의 규율이 있다. 여기서 다루는 것은 그 앞 단계 — 조사 중에 손이 미끄러지는 순간에 대한 첫 주의 규율이다.

실무에서 진짜 중요한 것

• 먼저 읽기 전용으로 답할 길을 찾는다. 쓴 명령을 적어 두면 스스로 속이지 않는다.
• 바꾸기 전에 굳힌다. 굳혀 두지 않으면 되돌렸다는 것을 증명할 수 없다.
• 한 번에 하나만, 되돌리는 명령을 미리 적어 둔다.
• 되돌림은 말이 아니라 견준 결과로 낸다. 남은 자국은 지우지 말고 적는다.

다음 실습에서 할 것

(가상) 수원페이의 운영 서버를 손에 쥔다. 먼저 다섯 가지 질문에 읽기 전용 수단만으로 답하고 쓴 명령을 함께 남긴다. 그다음 디렉터리 상태를 지문으로 굳히는 도구를 만들고, 그 도구에 견주는 기능을 더한다 — 채점기는 파일을 더하고 지우고 내용을 바꾸고 권한만 바꾸고 시각만 바꾼 자리를 만들어 여러분의 도구가 다섯 가지를 갈라내는지 본다. 그리고 꼭 바꿔야 하는 설정 한 줄을 승인과 되돌림 명령과 함께 바꾸고, 조회기로 효과를 확인하고, 실제로 되돌려 스냅샷과 내용이 다른 파일이 0개임을 증명한다.