Exception을 보고 흥분하지 않으면 개발자가 아니다.(1)

얼마전, 개발 단계 중반에 접어 든 PM분이 방문하였다.

“아르모니오님. 단위테스트에 대해 개발자들의 불만이 많습니다. 개발이 완료되었다고 하면 완료되었다는 증빙을 해야 하는 것이 맞지 않나요? 그 증빙을 개발 내용에 맞게 개발자 스스로 테스트를 해서 그 결과를 모두가 알 수 있게 남겨놓으라고 했는데. 이게 잘못된 건가요?”

“음. 개발 완료의 정의를 어떻게 내리는 가에 대한 질문인 거 같군요. 개발 진척도를 관리하기 위해 최소 단위로 개발목록을 작성하고 하나하나 완료시 진척도가 올라가게 하고 있겠죠. 그럼 여기서 단위 개발에 대한 완료를 어떻게 정의하고 합의를 이루어 가는 지 보겠습니다. PM님은 개발의 완료를 어떻게 보고 계시죠?

“그건 누구나 알고 있지 않나요? 개발자가 그 개발건에 대해 정의되고 합의된 개발내용을 코딩하고 테스트를 거쳐 최종 결과가 구현되는 것이죠.”

“그 구현이 되었다는 것을 모두가 인정할 수 있게 증빙, 증적을 요구하신 거구요.”

“맞습니다. 그렇지 않으면 개발이 완료되었다는 것을 누가 믿겠습니까? 그걸 믿었다가 거꾸로 당한 PM들이 많고 저도 그런 경험이 있어서 이 부분은 프로젝트 관리 차원에서라도 반드시 해야 하는 것입니다. 그리고, 그 개발자는 완료되었다는 것을 어떻게 알겠습니까? 테스트를 해서 아는 거 아닌가요?”

“그렇다면 개발자가 첨부한 증빙자료는 어떻게 믿으실 거죠?”

“하하! 그렇게 질문하실 줄 알았습니다. 그래서 현업 담당자들도 바로 테스트를 하라고 했죠. 개발자의 테스트결과가 맞는지, 그리고 요구했던 내용이 들어가 있는지, 그리고, 사용성과 통상적인 내용도 요청 드렸습니다. 그렇게 하면 통합테스트 때 부드럽게 흘러가고 프로젝트는 당연히 성공으로 가겠죠. “

“그럼, 단위 개발의 완료는 현업 담당자의 테스트 완료 및 결함/변경사항 완료라고 정의하면 되겠습니까?”

“저도 그 부분이 가장 이해가 가지 않습니다. 당연한 내용인데 이 부분에서 많이 부딪힙니다. 그래서, 어쩔 수 없이 이 부분은 양보했습니다. 개발자가 단위 개발에 대한 테스트 완료 및 증빙자료 작성,제출이 완료라고 했죠.’

“단위 개발들이 서로 연결되어 최종 구현이 완성되는 것인데요. 그렇다면 연결된 다른 단위 개발의 완료 없이 기능을 제대로 테스트 할 수 있을까요? “

“그 부분도 제가 양보했습니다. 만약 연결된 다른 단위 개발의 미완료로 인해 테스트가 어렵다면 그 부분은 보류했다가 추후 업데이트 하는 걸로요. 하지만 저는 이 부분도 이해가 가지 않습니다. 개발 계획을 작성할 때 그 부분에 대해 고려해서 작성해야 하지 않나요? 그 부분을 고려하지 않고 계획을 세워 놓고 PM인 저한테 안 된다고 얘기하는 것은…..”

“한 개발자가 책임지고 있는 개발 목록에 대해서는 그 순서를 맞춰서 계획을 세울 수 있습니다. 하지만 여러 개발자의 개발 순서를 맞출 수는 없습니다. 또한, 설계 단계에서 개발팀별, 개발자별 개발 범위를 나눌 때 서로의 영향도를 최소화 하여 나누게 됩니다.

서로 무슨 개발을 하는지 모르게 해야 한다.

각 프로세스간 영향도가 없도록 설계하듯이 개발자간 개발영역 분담도 서로 영향이 없어야 합니다. 타 개발자가 어떤 개발을 하는 지 알 필요가 없어야 하고, 타 개발의 진척 여부에 따라 자신의 개발에도 영향이 있다면 그건 잘못된 설계이고 분명 문제가 발생하게 됩니다. 이러한 내용은 프로젝트 진행에도 관계 됩니다. “

“그 부분은 저도 알고 있습니다. 그래서, 타 개발건 때문에 테스트가 안되는 건은 보류로 하고 넘어가기로 한 것입니다.”

” 보류라는 건 개발자 자신으로서는 미완료라는 것으로 인식됩니다. 이 부분이 개발자들이 저항하는 부분이죠. 개발자는 차별성을 지닌 creator의 본성을 가지고 있습니다. 그 차별성으로 인해 독립적으로 개발하려 합니다. 또한, creator의 본성으로 인해 완벽하려고 합니다. 이 두가지가 합쳐져서 타 개발건으로 인해 자신의 개발건이 ‘보류’, 즉 미완성으로 남는 다는 것에 인정하려 하지 않는 것입니다. 이러한 본성은 Exception을 보면 그냥 지나치지 않는 모습을 보면 알 수 있습니다. Exception이 타인의 개발 건이라고 하더라도 관심을 가지게 됩니다. 어떻게 해서든지 해결하려고 하고, 그 에러가 해결됬을 때 만족감을 느끼게 됩니다. 자신의 코드에 빨간줄이 보이거나 에러가 발생하면 모든 힘을 쏟아 해결합니다. 조금이라도 문제가 없이 완벽한 코드로 만들려고 하죠.

그런데 다른 단위 개발때문에 완료로 하지 못하고 보류라고 해야 한다니, 인정할 수 없는 부분이죠. PMS에는 완료로 되어 있더라도 말이죠. 그리고, 증빙자료에 대해서도 자신의 단위개발이 완료되었다는 것을 보여주기 위해 완벽을 기하려고 합니다. 다른 사람이 자신의 개발건에 대해 이러쿵저러쿵 얘기하는 것을 싫어하니까요. 결국, 실제 개발 시간보다 증빙자료를 만드는 데 더 시간을 쏟게 되고, 그렇게 해도 만족되지 않을 경우 심한 자괴감이 들게 됩니다. 개발을 하는 건지, 자료를 만드는 건지 헷갈리게 되죠. 프로젝트 종반이 되어 테스트 데이터가 쌓이면 쉽게 작성할 수 있는데도 초중반까지 테스트를 위한 자료를 만들어야 하는 것에 불만이 생길 수 밖에 없습니다.

또 하나 있습니다. 고객 현업에게 단위테스트를 하게 했다고 했는데, 그것은 단위 개발 목록과 각 단위 개발에 대한 설계까지 고객 현업에게 숙지하라는 것과 같은 얘기입니다. 단위개발목록은 개발자에 맞춰 IT의 관점에서 나누어진 목록입니다. 그 내부까지 테스트 하려면 최소한 설계 문서에 대해 숙지하고 그 결과를 예측할 수 있어야 하는 것입니다. 그리고, 단위개발 단계에서 현업의 테스트로 인해 결함 아닌 결함, 즉, 다른 단위개발이 완료되면 해결되거나, 합의되지 않은 건에 대해 오해로 인한 건들이 발생하게 됩니다. 항상 완벽하려고 하는 개발자에게 결함이라는 것은 개발자 자신에 대한 부정입니다.

그래서, ‘결함’과 ‘개선’ 두 단어에 대해 민감하게 반응하죠.

PM님이 그렇게 하시는 것도 이해가 갑니다.

그 출발점은 개발자에 대한 불신이겠죠.

개발자에 대한 불신 때문에 개발자의 본성이 발현되지 못하고 억누르는 방향으로 프로젝트를 진행하게 되면, 완료가 되더라도 성공적인 프로젝트라고는 할 수 없습니다. 이전에 말씀드린 것처럼 성공한 프로젝트는 개발자의 본성이 최대로 구현되어 창조적이고 개성적인 프로젝트가 되는 것입니다.”

“말씀 모두 이해가 가고 인정합니다. 개발자의 불신은 그 동안 경험으로 쌓인 것입니다. 그렇다고 무턱대고 믿고 갈 수는 없지 않습니까? 개발자는 완료되었다고 해 놓고 통합테스트 때 결함이 쏟아져 나오는 걸 보면 알 수 있지 않습니까? 물론 저의 생각대로 한다고 해서 통합테스트 때 결함이 적게 나오는 것은 아니겠죠. 단위개발이 완료될 때마다 테스트 결과를 제출하고 서브PL이 테스트 하고 또, 현업이 테스트를 해서 교차 검증까지 이렇게 두번, 세번 확인을 하는 게 최선이라고 생각해서 그렇게 한 것입니다. 이게 잘못된 방법이라면 좋은 방법은 무엇입니까? “

-> 2화에 이어집니다.