(이 글은 3년 전에 써 놓고 지금 올립니다.)

최근에 겪은 일

#1 특정 기능을 위한 서버 프로그램의 데모를 진행하였는데, 계속 버그같은 동작이 나와서 문제가 발생하였다.  결국 데모는 거의 실패 수준이었는데 다행히 원청 업체의 이해로 버그 수정을 하는 것을 전제로 프로젝트를 진행할 수 있게 되었다. 나중에 소스 코드를 받아서 분석하니 버그로 발견된 많은 부분이 사용상에서 그렇게 동작 하도록 의도된 코드였다고 확인 되었다.  담당자가 왜 그렇게 동작하도록 되어 있는지를 제대로 설명하거나 공유하지 않았던 것이다.

#2 모 프로젝트의 계약을 위한 설명자료와 내용을 정리해서 타업체에 보내야 하는 상황. 그 프로젝트는 일년 넘게 진행한 프로젝트라 문제점과 진행한 과정을 모두 알고 있었는데 타업체에 보내야하는 설명하는 자료에는 그런 내용이 전혀 없이 간단한 계약서 한장만 보내졌다. 부랴부랴 회수하고 정리를 다시하고 설명하는 자료와 통화를 여러번한 뒤에야 수습되고 진행 될 수 있었다. 담당자에게  왜 그런 문건을 보냈는지 궁굼해서 이야기를 해 보니 이미 (본인이) 다 알고 있어서 굳이 설명할 필요가 없고, 문의오면 대답해 주면 된다는 답변을 들었다.   부실한 설명으로 오해하기 딱 좋은 상황이고 그로 인해서 문의 오기 전에 프로젝트가 쫑 나는 것에 대한 걱정은 아예 없었다.

두건의 내용은 전혀 다른 프로젝트이고 전혀 다른 상황이지만 의외로 문제의 원인은 같다. 그것은 상대방에 대한 공감하는 능력, 문제를 내 관점에서가 아니라 상대방 관점에서 보는 능력이 혹은 관심이 결여되었거나 부족해서 발생하는 문제이다.

상대방에게 내가 아는 것의 결과물을 설명하는 것이 아니라 상대방에게 필요한 과정과 내용을 충분히 설명하여서 그 결과물의 의미를 설명했어야 한다.  프로그래머가  사용자에게 자신의 스타일로 만든 시스템을 강요하는 것은 상대방의 입장에서 결과물을 어떻게 사용해야 한다는 것을 생각해 본적이 없는 것이었다. 그래서 자신이 테스트한 방법 대로만 문제가 없으면 되는 것이라고 생각하고 시스템을 릴리즈 하는 것이다.

문제는 해결 방법이다.

이러한 문제는 항상 발생하는 사람들에게서만 발생되고,  반복된다.

이에 대해서 고민하는 중에 좋은 분에게서 들은 이야기는

“사람을 바꾸려 하지 말고 사람을 바꿔라”

이다.  언뜻 보면 이해하기 어려운 말인데 한편으로는 이해가 되면서 반대로 실행하기 어려운 말이 되었다.

---

3년이 지나서 글을 다시 읽어 보니 그때와 다른 생각이 드는 것은
문제는 그런 성향의 팀장/담당자임을 알면서도 맡긴 사람이 (내가) 잘못이라는 것이다.

개선이 되겠거니 , 배우겠지 하는 생각으로 진행한 것이 다 문제가 된 부분이었다.

나에게 문제가 있었다는 성인 군자 같은 말이나 결론인 것 같아서 안 올렸었는데 ,

생각해 보면, 좀더 빨리 다른 시스템을 고민했어야 한다는 점이다.