에러가 발생하지 않는 실패가 가장 무서웠다

사내용 웹 툴을 반년 동안 만들었다.

Claude와 채팅으로 대화하면서 조금씩 개발했다. 나는 현업 담당자일 뿐, 전문 개발자는 아니다.

그 과정에서 수많은 실패를 겪었다.

하지만 가장 무서웠던 것은 에러가 발생하는 실패가 아니었다.

에러는 멈춘다. 멈추면 알아차릴 수 있다. 그다음은 고치는 것만 남는다.

무서운 것은, 화면상으로는 성공했지만 실제로는 아무 일도 일어나지 않은 실패 쪽이었다.

의외였던 점은, 수정하는 데 걸리는 시간이 어느 쪽이나 크게 차이가 나지 않았다는 것이다.

원인만 파악할 수 있다면, 대처 과정의 어려움은 비슷했다.

달랐던 것은 그 이전이었다.

• 에러가 발생하는 실패는,
  알아차릴 때까지 0초. 상대방이 알려준다.
• 에러가 발생하지 않는 실패는,
  알아차리기까지 10일이 걸린 적이 있다.

10일은 실제 기록이다. 나중에 쓰겠다.

더 골치 아팠던 것은, 어떻게 알아챘는지 제대로 설명할 수 없었다는 점이었다.

우연히 다른 것을 조사하고 있었다. 어렴풋이 걸렸다.

—그런 계기로만 발견되었다.

절차로 만들 수 없다.

그래서 다음에도 똑같이 찾아낼 수 있다고 장담할 수 없다.

이 글은, 그 '에러를 발생시키지 않은 실패했던 것'들을 모아둔 기록이다.

첫 번째 건 가장 단순한 것이었다.

백업을 하지 않았다.

시스템 자체가 고장 난 것이 아니었다. 애초에 백업을 안 한 것이다.

이유도 명확하다. 업데이트할 때마다 수동으로 파일을 복사하는 것이 귀찮아서, '나중에 모아서 하자'라는 생각으로 생략되어 있었다.

여기에 알아차린 것은, 백업을 점검했기 때문이 아니었다.

버전 관리를 어떻게 할지 하는 다른 이야기를 하던 도중에 우연히 알게 되었다.

생각해보면 당연한 일이라, 안 해둔 것이 아무 일도 일으키지 않는다.

에러도 발생하지 않고, 경고도 나오지 않는다. 알아차할 기회 자체가 존재하지 않는다.

대처로는 더블 클릭 한 번으로 일체를 ZIP 파일로 저장하고, 변경 내용을 기록에 자동으로 기록하는 툴을 만드는 것으로 결정했다.

이때 조건을 하나 정했다.

수동 복사보다 수고가 줄어드는 것.
줄이지 않으면 또 똑같이 생략되기 때문이다.

귀찮아서 생략된 시스템을, 귀찮은 상태 그대로 다시 만들어도 의미가 없다.

실측으로 11개 파일, 약 1.2MB. 보존 기간은 30세대(generation)로 했다.

툴을 만들고 나니 다음 문제가 생겼다.

언제 할지를 정할 수 없었던 것이다.

처음에는 수정하기 전만 백업했다. 고장 났을 때 돌아가면 좋겠다는 생각이었다.

다음으로는, 수정 전과 후 둘 다 백업하도록 했다.

그리고 최종적으로는, 수정이 끝난 후에만 하는 형태로 정착했다.

정상적으로 작동하는 것을 확인한 상태를 남기는 것이, 되돌릴 때 헤매지 않기 때문이다.

규칙이 정해질 때까지 여러 번 다시 하고, 내용물을 여러 번 열어보았다.

그 과정에서 깨달았다.

압축 파일 안에 같은 이름의 파일이 2개 들어있다.

원인은 내가 했던 작업이었다.

복원이 제대로 되는지 확인하기 위해 압축 파일을 풀어서 프로그램 폴더에 덮어썼다. 그때, 압축 파일 안에 있던 관리용 파일도 함께 복사되어 그대로 남았다.

그것이 다음부터 백업 수집 대상이 되고 말았다.

대상 17개가 원래의 16개로 돌아올 때까지—발각까지 10일이 걸렸다.

지키기 위해 만든 것이, 조용히 망가져 있었다.

게다가 고장 난 것은, 제대로 복원 테스트를 한 나 자신이었다.

이 10일 동안, 백업은 매번 '성공했습니다'라고 표시되었다.

실제로는 압축에 성공했다. 내용물이 1개 많은 것만 누구에게도 알려지지 않았다.

여기서부터가 본론이다.

작동하지 않는 것이 아니라, 작동하고 있지만 다른 것을 보고 있는 실패가 3번 있었다.

재부팅한 후, 서버는 정상적으로 작동했다.

다만, 실제 데이터가 보이지 않았다.

원인은 시작하는 방식에 있었다.

이 툴은, 시작할 때 공유 폴더에 쓸 수 있는지 여부를 단 한 번 판정하고, 쓰지 못하면 로컬 테스트용 데이터로 전환되는 구조였다.

자동 실행이, 네트워크 준비가 끝나기 전에 돌아갔다.

그리고 한번 전환되면, 나중에 연결되어도 되돌릴 수 없다.

대처로, 연결될 때까지 기다리는 시스템을 넣었다.

10초 간격으로 최대 6회, 총 60초 동안 기다리게 했다.

반년 동안 가장 아찔했던 것이 바로 이것이었다.

계기는, 툴에 접근할 수 없게 된 것이었다.

평소처럼 화면을 열려고 해도, 연결되지 않는다.

서버를 멈추고 다시 시작했다. 그래도 연결되지 않았다.

가장 기본적인 대처법이 통하지 않았다.

뒤에서는 움직이고 있었다.

멈췄다고 생각한 것이, 멈춰있지 않았다.

Claude에게 방법을 물어보고 나온 명령어를 PowerShell에 붙여넣고 실행했다.

그때 알게 되었다.

같은 통신 포트에서 서버가 2개 돌아가고 있었다.

Windows에서는 특정 설정이 유효할 경우, 두 번째 것이 구동되어 버린다.

에러는 발생하지 않는다. 두 개 모두 '정상적으로 시작했습니다'라고 표시된다.

그리고, 브라우저가 어느 쪽에 연결될지는 불확실하다.

고쳤다고 생각한 것이 반영되지 않는다는 현상도, 이것으로 설명이 붙었다.

나아지지 않았던 것이 아니었다. 수정한 쪽을 보고 있지 않았던 것이다.

대처는 두 번째 것이 구동될 수 없도록 설정하고, 시작에 실패하면 안내가 나오게 하는 것이었다.

화면에서 보이는 것만으로는, 무엇이 돌아가고 있는지 알 수 없었다.

알게 된 것은, 명령어로 뒤를 들여다봤을 때였다.

프로그램을 업데이트한 후, '프로세스를 재시작해 주세요'라고 안내했다.

그것으로는 반영되지 않았다.

오래된 프로세스가 완전히 종료되지 않아, 새로운 코드가 로드되지 않았던 것이다.

결과적으로, 옛 설정 그대로, 자동 알림 메일이 계속 전송되었다.

전송은 성공하고 있다. 수신처도 형식도 맞다. 내용만 오래된 것이다.

대처로, 업데이트 시에는 프로세스가 아닌 PC 본체를 재시작하는 운영으로 바꿨다.

3건 모두, 화면상으로는 정상적으로 작동한다.

'작동하고 있습니까?'라고 물으면, 대답은 항상 '예'였다.

또 다른 유형이 있다. 고쳤다고 생각한 것이, 고쳐지지 않은 경우.

담당자의 메일 주소가, 사용자 각자의 브라우저 안에 저장되는 구조로 되어 있었다.

매번 입력하는 수고를 덜기 위한 것이다.

그 때문에, 코드 쪽을 수정해도, 한 번 사용해 본 사람의 브라우저에는 오래된 주소가 계속 남아있었다.

자신의 화면에서 고쳐져 있어도, 다른 사람의 화면에서는 고쳐지지 않았다.

확인할 수가 없었다.

대처로, 서버 측 설정 파일을 유일한 정보원으로 삼고, 화면은 거기서 가져오는 방식으로 바꿨다. 브라우저에 저장하는 것은 폐지했다.

주소가 내장되어 있던 곳은, 5군데 있었다(화면 3곳, 주기적 실행 구조 2곳).

최종적으로, 설정 파일 1곳으로 통합했다.

데이터 파일을 새로 두었는데도 기능이 작동하지 않는 경우가 있었다.

원인은 단순해서, 두는 전에 재시작했기 때문이다. 두고 난 후에 재시작하지 않았던 것이다.

할 일은 맞다. 순서만 거꾸로였다.

그리고 순서가 거꾸로여도, 에러는 아무것도 발생하지 않는다.

어떤 조작을 해도, 상태가 의도한 대로 변하지 않는 버그가 있었다.

1차 때는, 관련 데이터를 인계하는 구현이었기 때문에, 오래된 상태가 계속 남아있었다.

2차 때는, 그 데이터를 지우는 구현으로 바꿨다. 그래도 표시가 바뀌지 않았다.

3차 때에야, 마침내 근본적인 원인이 밝혀졌다.

애초에, 그 상태를 독립된 것으로 가지고 있지 않았던 것이다.

수정 시도는 3번.

처음 2번은, 고쳤다고 생각하며, 완전히 다른 곳을 건드리고 있었다.

마지막으로, 해결되지 않은 이야기를 하나 남긴다.

매일 아침 정해진 시간에 자동 전송되는 메일이, 어느 날 보내지지 않았다.

조사해도 알 수 없었다.

• 설정은 유효하게 되어 있다
• 실행을 멈출 조건 체크는 모두 해제되어 있다
• 그 시간에 본인이 그 PC로 작업하고 있었다. 즉 로그인 상태였다.
  실행된 기록 자체가, 로그에 없다

남아있던 것은, 예정 시간의 42분 후에 '시작을 놓쳤다'는 경고가 단 1건뿐이었다.

그리고, 수동으로 실행하면 성공한다.

여기서, 원인 규명을 중단했다.

다음 날 아침 로그에 기록이 남아있는지 여부로 판단한다는 방침으로, 먼저 나아갔다.

그 후로는, 문제없이 작동하고 있다 원인은 결국 알 수 없다.

지금 돌이켜보면, 이것은 일회성의 이레귤러(irregular) 였던 것 같다.

전부를 해명하지 않는다는 판단도 운영 과정이었다.

다만 '모르니까 방치'는 아니다.

다음번에 같은 일이 생기면 알아차릴 수 있도록, 확인할 장소만 정해두었다.

반년 동안 해보면서, 바꾼 것이 3가지 있다.

첫째. '작동했습니다'를, 그대로 받아들이지 않기로 했다.

성공 표시가, 성공했다는 증명이 될 수 없다.

백업은 매번 '성공했습니다'라고 나오고, 서버는 두 개 모두 '정상적으로 시작했습니다'라고 나왔다.

두 번째. 확인하는 절차를 작업 순서 옆에 적기로 했다.

'했는지 여부'가 아니라 '결과가 올바른지'를 확인할 줄을, 절차서에 추가했다.

세 번째. 모르는 것은, 모른 채로 두기로 했다.

그 대신, 알아차릴 장소만 미리 정해두었다.

이렇게 나열해보니, 에러가 발생하는 실패는 꽤 친절했다.

멈춰주고, 어디서 멈췄는지도 알려주니까.

무서운 것은, 항상 침묵하는 쪽이었다.

이 글은 Zenn에도 게재되어 있습니다.