옆 부서는 신입사원이 들어오면 기존 블럭에 대한 F/U을 시키는 것이 아니라 무조건 Test 작업부터 할당한다. 그래서 옆에서 보기에 참 불쌍(?)하다는 생각을 많이 했다.
Test 업무라는 것이 내가 만든 것이 아니라 대부분 남이 만들어 놓은 것을 대상으로 하는 지라 나름 부품 꿈을 안고 “개발자”의 길을 선택했는데 그것과는 사뭇 다른 일을 하고 있으니 어찌 흥이 나겠는가?
얼추 보면 최소 6개월에서 1년동안 이런 일을 한다.(리더가 특별히 계획을 가지고 이렇게 진행하는 것인지는 모르겠다. 아무래도 그 분이 그럴 것같지는 않고)
개인적으로 이렇게 하는 것에 그리 공감하는 편이 아니었는데 이번에 출장와서 겪은 일을 계기로 다른 생각이 들었다. 바로 “역지사지”, “사용자 입장에서 바라보기”가 그것이다.
많은 실은 대부분의 개발자들은 코딩을 할때 자신의 관점에서 작업한다. 자신의 관점이라 하면 어떤 방법을 사용하던 자신에게 주어진 요구사항에 맞게 프로그램이 동작하게 만드는 것이다. That’s it.
당연히 코딩하고, 시험하면서 필요한 부분을 확인하기 위해 로그 메시지도 출력하고, 상태 확인을 위한 디버깅 기능도 추가한다. 하지만 이런 것은 거의 100%가 자신을 기준으로 한 것이다. 즉 누구보다 해당 블럭을 잘 알고 있다는 것을 바틍으로 로그나 디버깅 기능을 추가하는 것이다.
그런데 정말 로그나 디버깅은 개발자 자신만 사용하는 것일까? 만일 그 사람이 다른 업무를 맡게 되었다면? 만일 퇴사했다면? 갑자기 동작에 문제가 있는데 연락이 안된다면? 담당자가 있는 곳이랑 전혀 반대의 시간대에서 문제가 발생했다면?
결코 로그나 디버깅 기능은 개발자를 위한 기능이 아니다. 개발자(담당자) 자신을 포함한 많은 사용자를 위한 기능이다.
그렇다면 어떻게 해야 할까?
쉽고 직관적이어야 한다.
당연한 이야기다. (대부분의 경우) 쓸데없는 소스 파일 이름, 함수 이름, 라인수를 찍어 로그를 지저분하게 하지 말고, 단순하게 error 문이나 Return -1 같은 거의 무의미한 내용을 출력하지 말고, 16진수를 0x도 없이 찍지 말고, 16진수를 10진수로 출력하지 말고, 디코딩이 필요한 값을 단순하게 숫자로 찍어서는 안된다.
한가지 정보를 얻기 위해 사용자가 몇 번의 명령어를 입력하게 해서는 안된다. 개발/시험 중에는 고작해야 1-2군데에서 그 명령어를 치겠지만 현장에서는 단위가 달라진다. 몇 십번에서 몇 백번 똑같은 명령을 입력하는 경우도 있다. 이런 어처구니 없는 불편함은 누구 잘못이겠는가? 모든 것이 자신을 기준으로 자신만을 생각하고, 사용자를 생각하지 않는 개발자 잘못이다.
그럼 처음에 왜 신입사원에게 Test 업무부터 시키는 것에 대한 생각이 바뀌었는지 답이 나온다. 바로 다른 사람이 만들어 놓은 불편한 로그/디버깅 기능을 체험하라는 것이다. 내가 다른 사람이 만들어 놓은 지저분한 로그를 분석할 때도 있고, 불편한 디버깅 기능을 이용해 봐야 정말 다른 사용자의 심정을 조금이라도 이해할 것이라고 생각하기 때문이다.
정말 부서내에 게시판을 하나 만들어놓고 다른 사람의 로그나 디버깅 기능을 이용하면서 느낀 불편한 점을 공유했으면 좋겠다. 모든 불편한 점을 해결할 수는 없을 테니 주기적으로 게시판에 올라온 것중에서 꼭 필요한 부분을 골라 activity로 잡아 개선하는 작업이 있으면 좋겠다.
그리고 시험 인력은 로그가 부정확하거나 불편한 점 역시 개선요구사항을 개발팀에 feedback을 줄 수 있는 분위기/체계가 있었으면 한다. 제대로 기능 동작은 기본이 아닌가? 단지 제대로 동작하는 것 그 이상을 목표로 삼아야 한다.
많은 경우 제대로 되지 않는 management나 process를 욕하는 경우가 많다. 하지만 시간이 가면 갈수록 결국 문제점은 개발자의 태도라는 생각이 든다. 개발자의 능력이 아니라 태도.
꼬랑지) 그래서 읽고 싶은 책. “소프트웨어, 누가 이렇게 개떡같이 만든거야” 중 (via Inuit Blogged)
geek들의 지적 만족을 위한 프로그램이 아니라 제품으로서의 소프트웨어를 만들어야 합니다
