개발자가 제일 무서워하는 말, "아무것도 안 했는데요"

둘 다 맞는 말이었다

개발 일을 하다 보면 묘하게 긴장되는 말이 있다. "어제는 잘 됐는데 갑자기 안 돼요." "아무것도 수정한 게 없는데요." "프로그램에 문제가 있는 것 같아요."

이 말들이 틀렸다는 뜻은 아니다. 실제로 프로그램에 오류가 있을 수도 있다. 다만 개발자는 그 말을 들은 순간 머릿속에서 수십 가지 가능성을 펼치기 시작한다.

그리고 원인을 찾고 나면 대개 결론은 하나로 모인다. 사용자도 맞았고 개발자도 맞았다. 서로 보고 있는 범위가 달랐을 뿐이다. 이 글은 그 범위의 차이가 어디서 생기는지, 그리고 그 차이를 줄이려면 양쪽이 무엇을 하면 되는지에 대한 이야기다.

"아무것도 안 했는데요"의 진짜 의미

사용자는 프로그램을 수정하지 않았다. 그 말은 사실일 수 있다. 하지만 프로그램에 들어가는 데이터나 주변 환경은 바뀌었을 수 있다.

주문관리 프로그램에서 엑셀 주문서를 내려받아 업로드하는 업무를 생각해 보자. 늘 같은 쇼핑몰에서 받은 원본 파일을 그대로 올렸다는데, 어느 날 갑자기 오류가 난다.

확인해 보면 쇼핑몰이 다운로드 엑셀의 컬럼 순서를 바꿨거나, 예전에는 없던 열 하나를 추가했거나, '수취인 전화번호' 같은 헤더 이름을 바꿔 놓은 경우가 있다. 사용자 입장에선 똑같이 내려받아 올렸으니 아무것도 바꾼 게 없다. 개발자 입장에선 입력 데이터의 형식이 달라졌다. 둘 다 자기 자리에서는 맞는 말이다.

"어제는 잘 됐는데요", 무엇이 달라졌나

이 말을 들으면 개발자는 먼저 묻는다. 어제와 오늘 사이에 무엇이 달라졌을까.

프로그램 소스는 그대로여도 바깥은 계속 움직인다. 외부 API 응답, 운영체제 업데이트, 브라우저 정책, 파일 인코딩, 엑셀 서식, 사용자 권한, 네트워크 상태가 하루 사이에 바뀔 수 있다. 이 가운데 사용자가 직접 바꾼 것은 하나도 없을 수 있다. 밤사이 자동으로 깔린 업데이트 하나가 아침 업무를 멈추게 하는 일도 드물지 않다.

그래서 장애 원인을 찾는 일은 누가 뭘 건드렸는지 추궁하는 과정이 아니다. 어느 조건이 달라졌는지 찾는 과정에 가깝다. 사람을 찾기 시작하면 대화가 방어로 흐르고, 조건을 찾기 시작하면 대화가 비교로 흐른다.

"프로그램에 문제가 있는 것 같아요"

개발자로서 마음이 가장 무거워지는 말 중 하나다. 아직 원인은 확인되지 않았는데 문제가 프로그램으로 확정된 것처럼 들리기 때문이다.

물론 실제 버그라면 고쳐야 한다. 다만 더 빨리 해결하려면 "프로그램이 문제예요"보다 "어느 화면에서 어떤 파일로 무엇을 했는데 어떤 메시지가 나왔어요"가 훨씬 좋은 출발점이다. 앞의 말은 결론이고 뒤의 말은 단서다. 단서가 있으면 개발자는 같은 화면에서 같은 파일로 문제를 다시 일으켜 볼 수 있다.

결론으로 시작한 대화는 결론을 확인하는 데 시간을 쓴다. 단서로 시작한 대화는 바로 재현으로 넘어간다. 같은 문제라도 첫 문장에 따라 해결까지 걸리는 시간이 달라진다.

사용자에게 필요한 것은 기술 용어가 아니다

문제가 생겼을 때 네 가지만 알려 줘도 원인을 찾는 속도가 크게 달라진다. 언제부터 생겼는지, 어떤 화면에서 어떤 작업을 했는지, 화면에 뜬 오류 메시지가 무엇인지, 그리고 어제 성공한 파일과 오늘 실패한 파일을 나란히 비교할 수 있는지다.

이 가운데 마지막이 가장 힘이 세다. 성공한 파일과 실패한 파일이 함께 있으면 개발자는 추측 대신 비교를 할 수 있다. 열 개수, 헤더 이름, 날짜 형식처럼 눈으로 확인할 수 있는 차이가 대부분 거기서 드러난다.

특히 주문서 엑셀처럼 외부 시스템에서 내려받는 자료는 '원본 파일 그대로'라는 설명만으로 형식이 같다고 볼 수 없다. 원본을 만드는 쪽이 바뀌면 원본도 바뀐다.

개발자도 바꿔야 할 점이 있다

사용자에게 "파일이 바뀌었네요"라고 설명하는 것으로 끝나선 안 된다. 실무 시스템이라면 들어온 컬럼명을 검증하고, 빠진 항목을 알려 주고, 예상과 다른 양식이 들어왔을 때 무엇이 다른지 구체적으로 보여 줘야 한다. "업로드 실패"와 "'수취인 전화번호' 열을 찾지 못했다"는 같은 오류라도 사용자가 할 수 있는 일이 전혀 다르다.

가능하다면 바뀐 주문서 양식을 감지해 사용자에게 컬럼 매핑을 요청하거나, 관리자가 손쉽게 컬럼 연결을 고칠 수 있게 만들어야 한다. 그러면 쇼핑몰이 양식을 바꾼 날에도 개발자를 기다리지 않고 업무를 이어 갈 수 있다.

결국 좋은 업무 프로그램은 사용자가 아무것도 안 했는데도 바뀔 수 있는 것을 어느 정도 예상하고 대응하는 프로그램이다. 바깥이 바뀌는 건 막을 수 없지만, 바뀌었다는 사실을 빨리 알려 주는 건 만들 수 있다.

회고

"아무것도 안 했는데요"는 거짓말이 아닐 때가 많다. 단지 서로 보고 있는 범위가 다른 것이다. 사용자는 작업 절차를 보고, 개발자는 데이터와 시스템의 상태까지 본다.

다음에 누군가 "어제는 잘 됐는데 갑자기 안 돼요"라고 말하면, 곧바로 잘잘못부터 가리지 않는 게 좋다. 어제와 오늘의 입력값부터 비교해 보면 의외로 답이 빨리 나온다.

엑셀 양식 검증을 위해 복잡한 프로그램을 따로 작성할 필요는 없다. 82엑셀(82excel.com)을 쓰면 소스 몇 줄만으로 열 이름과 필수 항목, 값의 형식을 검사할 수 있다. 업로드 화면에 이 검증을 붙여 두면 쇼핑몰이 양식을 바꾼 날에도 무엇이 달라졌는지 업로드 전에 바로 알 수 있다.

용어 쉽게 보기

글에 나온 용어를 개발자가 아닌 분도 읽을 수 있게 풀었다.