개발자의 실수와 반성: 배포 후 후회했던 순간들

개발자로 일하면서 가장 오래 기억에 남는 실수는 작성한 코드가 틀렸다는 사실보다, 충분히 확인했다고 믿었던 결과가 실제 사용자 화면에서 다르게 나타났던 순간들입니다. 저는 배포를 끝내면 일이 마무리됐다고 생각하곤 했습니다. 하지만 진짜 책임은 그때부터 시작됐습니다. 작은 설정 하나, 무심코 넘긴 안내 문구 하나가 서비스 전체의 인상을 바꾸기도 했습니다.

새벽에 발견한 환경 설정 오류

첫 번째로 크게 후회한 일은 신규 기능을 배포하면서 실행 환경에 필요한 설정값 하나를 빠뜨린 사건입니다. 제 컴퓨터에서는 정상적으로 작동했기 때문에 마지막 확인에서도 문제를 찾지 못했습니다. 배포 직후 특정 메뉴를 누른 사용자에게만 빈 화면이 나타났고, 문의가 들어온 뒤에야 상황을 알았습니다. 원인은 복잡한 알고리즘이 아니라 설정 파일에 들어가야 할 주소 한 줄이었습니다.
당시 저는 변경된 파일 목록만 확인하고 실제 사용자의 흐름을 처음부터 끝까지 따라가 보지 않았습니다. 관리자 화면에서는 잘 보였고, 제가 자주 쓰는 기능도 멀쩡했기 때문에 괜찮다고 판단했습니다. 그러나 권한과 접속 경로가 다른 일반 사용자의 화면은 전혀 다른 결과를 보여줬습니다. 급하게 이전 버전으로 되돌린 뒤 누락된 값을 추가했지만, 이미 몇 시간 동안 일부 사용자는 기능을 이용하지 못한 상태였습니다.

금요일 오후에 배포했던 대가

또 한 번의 실수는 금요일 늦은 오후에 배포를 진행한 일이었습니다. 일정에 맞추려는 마음이 앞서서 주말 전에 일을 끝내고 싶었습니다. 변경 내용은 간단한 화면 수정이라고 생각했지만, 실제로는 여러 화면에서 함께 사용하는 공통 파일이 바뀌어 있었습니다. 배포 직후 일부 버튼의 위치가 어긋났고, 모바일 화면에서는 글자가 겹쳐 보였습니다. 평소보다 확인할 사람이 적은 시간대라 문제를 알아차리는 데 더 오래 걸렸습니다.
그때 저는 배포 시점을 기술적인 문제로만 봤습니다. 언제 올리든 결과만 같으면 된다고 생각했지만, 문제가 생겼을 때 누가 확인하고 누가 판단할 수 있는지도 중요한 조건이었습니다. 이후에는 금요일 오후처럼 대응이 어려운 시간에는 긴급한 변경이 아니면 배포하지 않았습니다. 꼭 진행해야 할 때는 담당자와 연락 가능한 시간을 먼저 맞추고, 문제가 생기면 어느 범위까지 되돌릴지 미리 적어두는 습관을 만들었습니다.

되돌리기 버튼이 없다는 사실

가장 아찔했던 순간은 배포 전 버전을 쉽게 복원할 방법을 준비하지 않았을 때였습니다. 변경 사항을 한꺼번에 올린 뒤 이상한 동작이 발견됐는데, 어느 부분이 원인인지 바로 특정하기 어려웠습니다. 이전 파일을 찾아 수동으로 복사하는 동안 시간이 계속 흘렀고, 그 사이 사용자들은 불편을 겪었습니다. 기능을 고치는 것보다 안전하게 이전 상태로 돌아가는 일이 더 어려울 수 있다는 사실을 그때 처음 실감했습니다.
이후 저는 작은 변경이라도 배포 단위를 지나치게 크게 만들지 않으려고 했습니다. 이전 버전의 파일과 변경 기록을 쉽게 확인할 수 있게 정리하고, 복원 절차를 문서로 남겼습니다. 문서는 거창한 설명서가 아니라 누구든 몇 분 안에 따라 할 수 있는 순서표에 가까웠습니다. 실제로 다음 장애가 발생했을 때 그 순서표 덕분에 당황하지 않고 기능을 원래 상태로 돌릴 수 있었습니다.

문구 하나를 가볍게 본 실수

기능 자체는 정상인데 사용자에게 잘못된 안내를 보여준 적도 있습니다. 저는 버튼 이름을 내부 용어에 맞춰 수정했지만, 그 용어를 처음 보는 사람에게는 의미가 불분명했습니다. 배포 후 문의 내용을 읽어보니 사용자들은 버튼이 작동하지 않는다고 생각하고 있었습니다. 실제로는 정상 처리된 뒤에도 안내 문장이 애매해서 실패한 것으로 받아들인 경우였습니다. 개발자에게는 자연스러운 표현이 사용자에게는 전혀 그렇지 않을 수 있다는 점을 놓쳤습니다.

실수 이후에 바뀐 제 기준

이런 경험을 겪고 나서 저는 배포를 완료하는 기준을 단순히 파일이 서버에 올라간 상태로 두지 않게 됐습니다. 실제 사용자의 주요 흐름을 직접 따라가고, 다른 화면 크기와 권한에서도 문제가 없는지 확인해야 비로소 끝났다고 생각합니다. 무엇보다 문제가 생기지 않을 것이라는 낙관보다, 문제가 생겼을 때 얼마나 빨리 알아차리고 되돌릴 수 있는지를 더 중요하게 봅니다. 완벽한 개발자는 실수하지 않는 사람이 아니라 실수를 숨기지 않고 다음 절차에 반영하는 사람에 가깝다고 느꼈습니다.
배포를 앞둔 개발자라면 변경된 코드만 바라보지 말고 사용자가 마주할 전체 과정을 천천히 걸어보셨으면 합니다. 어떤 시간에 올릴지, 문제가 생기면 누구에게 알릴지, 이전 상태로 어떻게 돌아갈지까지 생각하면 불안이 조금 줄어듭니다. 저 역시 지금도 배포 직전마다 예전의 빈 화면과 겹쳐진 글자를 떠올립니다. 그 기억은 실수를 부끄러워하는 데 머물지 않고, 더 신중하게 일하도록 만드는 가장 현실적인 체크리스트가 되었습니다.