[소프트웨어 장인] 5장 영웅, 선의 그리고 프로페셔널리즘

말도 안되는 일정 속에서 팀원 모두가 프로젝트를 성공해내길 바라며, 모두 영웅이 되고 싶어했다. 전형적인 폭포수 방식으로 진행되었던 프로젝트에서 모두가 프로페셔널하지 못했다. 고객이 실제로 무엇을 원하는지 이해하려 하지 않았고 다른 대안을 제시하지도 않았다. 고객을 만날 수도 없기는 했지만, 요구사항에 대해서 질문을 하지도, 실행할 수 없다는 이야기도 하지 않았다. 우리는 그냥 주어진 환경을 있는 그대로 두고, 무작정 일을 밀어 붙였다. 그때는 그것이 프로페셔널이라고 생각했다.

우리는 프로젝트를 구한 영웅으로, 불가능한 일을 해낸 사람으로 보이고 싶었던 것이다. 결국 그 모든 노력은 헛고생으로 끝났다. 일정은 늦춰졌고 비즈니스 부서의 그 누구도 우리가 얼마나 노력했는지 알아주지 않았다. 우리는 명예를 얻지도 못했고, 그저 값싸게 노예처럼 일하는 개발자들에 불과했다.

우리는 일을 잘못하고 있었다. 당시에 우리가 어떤 취급을 받았는지 떠올리면 가슴이 아프다. 아직도 그러한 일이 비일비재하다는 사실에 더욱 속이 상한다. 공장 노동자처럼, 노예처럼 행동했고 회사에도 해를 끼쳤다.

우리는 전혀 프로답지 못했다. 한번도 ‘아니오’라고 말하지 않았기 때문이다.

‘아니오’라고 말하는 방법 배우기

보통 상급 관리자들은 계약 기간 내에 프로젝트를 끝내려는 욕심에 의도적으로 무리하게 일정표를 만들어 개발자들을 밀어 붙인다. 그 모든 기능들을 주어진 일정 안에 완료한다는 것이 불가능함을 알고 있으면서도 상급 관리자의 요구를 그냥 받아들이고 그대로 실행한다.

이에 따른 결과는 참혹하다. 릴리즈 버젼 소프트웨어에 버그가 가득하고 고객은 화를 내며 신뢰는 바닥으로 추락한다.

정작 불가능한 것을 알면서도 그렇게 개발자들을 압박한 바로 그 상급 관리자 자신은 집에 일찍 들어가고 주말을 가족들과 즐긴다. 그러고는 모든 책임을 개발자들에게 뒤집어 씌운다. 모든 문제는 개발자들의 능력이 부족해서, 개발자들이 더 열심히 하지 않아서, 개발자들이 약속을 지키지 않아서 라고 한다.

재앙의 기억

대형 이동 통신사에세 일을 할떄였다. 새로운 모바일 포털 서비스를 선보이려는 마케팅 부서의 기획아래 시스템을 개발했다. 개발팀의 요구사항을 들어주지 않은 마케팅 부서는 오픈을 강행했다가 5일 내내 복구와 다운이 반복되는 애플리케이션을 런칭하게 되었다. 몇주가 지나서 모든 기능들이 안정화 되었지만, 개발팀원으로서 나쁜 평판만 생겼다.
결국 대부분의 개발자들은 거의 동시에 그 회사를 떠났고 이부분은 회사에 더 큰 문제가 되었다.
애플리케이션의 두번째 버전은 3개월 일정으로 계획되었고, 3개월이 아닌 9개월이 걸렸다.

교훈

마케팅 매니저가 프로페셔널하지 못했지만 우리 개발자들은 그런 상황 전체를 피할 수 있었다.
매니저 뿐만 아니라 개발자들도 이미 불가능하다고 알고 있는 것에 대해 “해보겠다”라고 말하지 말았어야 했다.

회의 때마다 개발 일정에 여유가 없음을 통보하고, 상용 시스템에 대한 부하 점검이 필요함을 이메일 기록으로 남겼어야 했다.
상용화 수준에 미달되는 저품질의 소프트웨어가 될 수밖에 없다면 주어진 조건들을 거부했어야 했다.

우리가 영웅이 될 수 있다는 망상에 사로잡혀 프로페셔널하게 행동하지 못했다. 우리는 ‘아니오’라고 말할 수 있어야 했다.

프로답게 행동하기

빡빡한 일정을 다루는 가장 좋은 방법은 필요한 모든 것을 분석하여 가능한 위험과 우려사항을 터놓고 관계자들과 소통하는 것이다. 불명확하거나 불편한 사실들, 걱정되는 사항들을 최대한 이른 시점에 문제제기해야 한다.

괸리자와 개발자 간에 협상이 되어야 하지만 협상 기술이나 제대로 된 근거 자료가 부족해서 개발자들이 압력에 그냥 굴복하고 말 때가 부지기수다. 개발자들은 논쟁하고 싶지 않아서 또는 긍정적인 태도를 부여주고 싶어서 “최선을 다해 노력하겠다”라고 대답해 버린다.

차드 파울러는 저서 “열적적인 프로그래머”에서 그저 실망시키지 않기 위해서 말하는 ‘네’는 거짓말에 지나지 않는다고 했다. 그냥 거짓말이 아니라 중독적이고 파괴적인 습관이다. 양의 탈을 쓴 나쁜 습관이다.

‘아니다’라고 말할 때 우리는 무언가 실패한 듯한, 무언가 협조하길 거부한 기분 좋은 팀원이 되지 못한 기분이 든다. 무조건 ‘네’라고 하는것은 언뜻 보기에는 긍정적인 사고방식 같지만, 그 이면에는 대단히 이기적인 욕구가 숨어 있다. ‘네’라고 말할 때 사람들은 그 말을 믿고 그에 의존해서 계획을 짠다는 것을 반드시 기억해야 한다.

관리자가 그의 상사 또는 그의 직접적인 고객에게 실제 프로젝트의 상황을 투명하게 밝히지 않는다고 느낄 때가 있다. 개발자들의 우려사항을 다른 관계자들과 공유하지 않고 그냥 모든 것이 괜찮다고만 할 때도 있다. 상황이 정말 나빠질 때는 관리자에게 해당 이슈를 전달할 것을 요구하고 그렇게 하지 않는다면 우리가 직접 그 관리자의 상사가 포함된 미팅을 소집해서 문제 상황을 공유할 것이라고 말해야 한다.

다툼을 피하지 말고 부딪혀서 어려운 결정을 내릴 수 있어야 한다. 우리가 정직하고 투명한 방법을 사용한다면 누군가 부당하게 피해를 입는 일없이 팀 전체는 물론 회사에도 이득이 될 것이다.

대안 제시

모든 ‘아니오’에는 반드시 하나 이상의 대안들이 따라와야 한다. 최소한 브레인스토밍은 해보아야 한다. 어떤 때는 단지 문제를 어떻게 풀어야 할지 방법을 모를 수도 있다. 이때는 최대한 이른 시점에 그 사실을 정직하게 알려야 한다. 무언가 약속은 할 수 없더라도 문제 대응이 어떻게 되고 있는지 진척 상황을 계속 공유해야 한다. 아무리 나쁜 상황에서도 우직한 정직함을 보여줄 수 있다면 프로페셔널의 조건 중 하나를 갖춘 것이다.

뜻박의 실용적인 대안

정부의 규제 기관에 거래 정보를 신고하는 프로젝트를 수행했을떄 일이다. 진행 중에 규제에서 정한 의무 사항을 모두 만족시키는 것이 어렵다는 것을 알앗다. 규제 당국으로의 자동 보고 시스템에 모든 종류의 금융 거래를 일정 내에 구현할 수가 없었다.

비즈니스 부서에서는 개발 범위나 일정에 대한 협상이 없었다. 자동 보고 시스템에 모든 종류의 거래들을 구현해 넣든가, 아니면 고객사가 벌금을 내게 하고 우리의 평판에 해를 입든가 둘중 하나였다.

유리했던 점은, 애자일 형태로 프로젝트를 진행하고 있었고, 모든 팀이 화이트보드에 진척도는 물론 모든 문제점과 병목 요소까지 기록해 두고 있었다는 점이다. 백로그 또한 전체 팀에 공유되고 있었고 일의 진척도를 시각적으로 보여 줌으로써 비즈니스팀이 우리가 처한 상황을 이해하기 쉽게 하여 일정을 맞출 수 없음을 납득시키는 데 도움이 되었다.

그로인해 다른 실용적인 대안에 눈을 돌릴 수 있었다. 개발팀이 ‘아니오’라고 말함으로써 수동으로 하는 방법을 함께 사용하여 일정 안에 맞추어 시스템을 오픈할 수 있었다.

꺠어 있는 관리자

훌륭한 관리자들은 자신이 개발팀의 일부이며 개발자들과 함께 공동의 목표를 위해서 일한다는 것을 이해한다. 투명성은 관리자와 팀이 험난한 상황을 이겨낼 수 있게 한다. 좋은 관리자는 외부의 압력으로부터 개발자를 보호하고 팀이 가진 장애요소들을 제거한다.

요약

고객이 내리는 결정이 소프트웨어 프로젝트에 전체적으로 어떤 파급효과가 있을지 고객 스스로 이해하고 있다고 기대하기는 어렵다. 이 부분을 파악해서 알려주는 것은 우리들의 몫이다. 의도한 대로 동작할 수 없거나, 실행 불가능한 무리한 일정에 대해서 “아니오”라고 답하는 것은 우리의 의무다.

고객은 문제를 들고 프로페셔널을 찾아간다. 프로페셔널들이 그들의 경험과 지식을 활용해 그 문제를 다룰 방법들에 어떤 것들이 있고 각각의 장단점이 무엇인지를 알려주길 기대한다.

고객의 결정은 프로페셔널이 제공한 정보를 기반으로 이루어져야 한다. 프로페셔널이 생각하기에 올바르지 않은 결정을 고객이 밀어붙이려 한다면 당연하게도 그것을 거부한다. 우리도 그래야 한다.

참조

• 소프트웨어 장인