국내 대기업 개발팀에서 대학 전산팀으로 직장을 옮기면서 참 많은것들이 바뀌었다. 이전에 개발하던 방식은 B2B 개발로 개발이 필요한 feature들에 대한 협상을 Staff 부서에서 진행하고, 세부 일정을 잡아 개발을 진행했다. Feature 도출 → 설계 → 개발 → BT → SW 통합테스트 → 제품 통합테스트 의 과정으로 약 6개월 가량의 시간이 주어진다. 여기서 내가 있던 개발팀은 개발 → BT 까지 실제로 개발을 진행하는 기간은 1달 남짓 되었던 것 같다. 사실 이것 마저도 동시에 여러 업체의 branch와 선행개발 등을 함께 했기 때문에 충분한 시간은 아니었다.

개발이 완료된 코드인데 SW 통합테스트, 제품 통합테스트 단계에서 오류가 발생되면 전체 일정에 문제가 생겼기 때문에 팀 전체에 비상이 걸렸다. 통합테스트에서 나온 오류들은 엑셀로 정리되어 개발팀으로 전달되고, 해당 오류들은 각 파트별로 그리고 다시 모듈별로, 마지막으로 해당 개발자에게 할당되었다. 여기서 얼마나 오류가 발생되지 않고 잘 개발 했느냐가 모듈장, 파트장, 개발팀장의 KPI였다.

이러한 환경이었으니 개별 개발자들이 받는 압박은 엄청났다. 생각해보면 개발인력의 부족이 가장 근본적인 원인이었는데 근본적인 원인을 해결할 수 없으니 어떻게 해서든 버그가 발생한 원인을 만들어야 했다. 여기서 나왔던게 해법이 포스트모템(postmortem) 과 5 Why였다. 개발자 본인이 오류를 발생시킨 원인을 5번 파고 들어보자는 것이다. 가령 코드에서 Null 포인트 execption 오류가 발생했다고 생각해보자.

Null point execption 발생 → 왜 발생 하였는가?(1 Why) → 방어코드를 넣지 않았음 → 왜 방어코드를 넣지 않았는가?(2 Why) → multi thread가 접근 가능한 코드 영역임을 몰랐음 → 왜 Multi thread 영역을 몰랐는가?(3 Why) → …

위와 같은식으로 발생한 모든 오류에 대해 개발자들이 직접 원인을 작성했다. 위와 같은 과정의 결론은 거의 대부분 비슷했다. “체크리스트에 오류가 발생한 부분을 추가한다", "전체 코드에 대해 comment 처리를 강화한다." 등 모든 개발자가 괴로워지는 방식이었다.

위와 같은 환경에서 개발을 하다가 대학으로 직장을 옮기고 실시간으로 사용자와 맞닥들이는 학사시스템을 개발하게 되니 새삼 분위기가 달랐다. 이전에는 개발자 본인의 실수로 인한 버그들을 수정했다면 이제는 사용자의 실수로 인한 오류를 수습해주는 일들이 주 업무가 되었다. 처음에는 너무나 어이없는 실수를 반복하는 사용자들을 이해할 수가 없었다. 페이지 상단에 대문짝만하게 써놓은 내용, 심지어 실수가 반복되는 것을 방지하기 위해 띄우는 Alert까지 무시하며 오류(여기서 오류는 시스템 오류라기 보다는 사용자가 의도하지 않은 데이터가 입력된 경우)를 발생시키는 게 답답하기만 했다. 이전 회사에서는 실수를 하게 되면 대역죄인 취급을 하는 것을 욕하면서도 나도 모르게 그 문화에 익숙해졌던 것 같다.

그러다가 졸업식을 하루 앞둔 어느날 전체 졸업생 합계 데이터가 맞지 않는 일이 발생했다. 전체 데이터를 검증해본 결과 특정 단과대학에서 졸업사정 프로그램을 잘못 돌려 일부 학생을 누락시킨 상황이었다. 이미 학위증 출력까지 끝난 상황에서 이 일을 누가 수습해야 하느냐 책임에 대한 돌림판(?)이 돌아가기 시작했다. 개인적으로 누군가의 잘못을 밝히기 위해 자료를 찾고 결과 리포트를 하는 일을 정말 싫어하는데 이번엔 어쩔수 없었다. 찾아본 결과 놀랍게도 해당 자료를 생성한 사번이 내 사번이었다. 곰곰히 생각해보니 육아휴직이 끝나고 돌아온지 얼마되지 않은 직원이 업무에 어려움을 호소해 내가 도와준다고 프로그램을 돌려줬었는데 그 때 실수를 했던것이다.

괴로웠다. 당장 수습도 수습이지만 내가 이런 초보적인 실수를 했다는 것이 창피했다. 시스템 로그까지 볼 수 있는 사람은 나밖에 없는데 적당히 얼버무리고 넘어갈까 고민도 됐다. 많은 고민 끝에 결국 스스로 실수를 인정하고 죄송하다고 말씀드리며 수습은 직접 하겠다고 했다. 그런데 놀랍게도 갑자기 분위기가 바뀌었다. 서로 잘못을 따지며 범인을 찾아달라던 A부서와 B부서의 갈등이 폭발 직전이었는데 갑자기 생각지도 못했던 제3자인 내가 나타나 잘못을 인정한 것이다. 그러자 모든 상황이 정리가 되었다. 서로 책임을 묻던 A, B 부서 양쪽에서 자기 소속 학생이니 직접 정리하겠다, 중앙 부서인 자기 부서에서 직접 정리하겠다 하면서 서로 수습을 하겠다고 나섰다. 전산 담당자인 나는 최종 데이터만 다시 맞춰달라는 것이다. 이렇게 졸업식 전날 있었던 사고는 훈훈하게 하나의 에피소드로 남았다.

이 사건을 계기로 실수에 대한 나의 생각이 변한것 같다. 사용자들의 실수가 있더라도 그 사람이 부족하다는 생각 보다는 그럴 수 있지 라는 생각을 하게 됐다. 그리고 그 실수를 줄이는 방법이나 실수 한것을 스스로 복구할 수 있는 쪽으로 프로그램 개선 방향을 잡았다. 그리고 스스로 잘못을 인정하는게 너무 창피했는데 실수를 인정하는 일이 조금 쉬워졌다. 밑에 직원의 실수로 인한 문제를 보고할 때도 내가 매니징 하지 못했던 부분을 함께 보고했고, 막내 PL인 나로 인해 다른 개발자들보다 많은 일들을 하게 된 후배 개발자에게도 미안하다는 말을 먼저 하는 등 소통의 방식에 변화가 생겼다. 작은 변화였지만 내 스스로도 마음이 편해졌고, 협업에 있어서도 이전보다 부드럽게 진행된다는 것을 느낄 수 있었다. 그래서 후배직원이 어느정도 주체적으로 업무를 맡을 수 있을 때 이 이야기를 가장 먼저 해준다. 실수해도 괜찮다.

…물론 처음 업무를 가르칠때는 엄격한 모습을 보이는 편이다. 업무를 ‘대충’ 하려는 모습을 보았을 때 혹은 직접 확인하지 않고 “~인 것 같다”는 식의 이야기를 들었을 때는 정말 집요하게 짚고 넘어간다. 꼰대라고 해도 어쩔수 없다…안되는건 안되는거야ㅠㅠ