부지런한 개발자, 게으른 개발자

Mike Hadlow는 영국 브라이튼에 근무하는 소프트웨어 아키텍쳐입니다.
‘개발자가 열심히 일하는 걸 어떻게 평가할 것인가?’하는 것은 IT업계에서는 해묵은 주제입니다.
아래 번역글이 실제로 일을 하지 않는 개발자들의 변명으로 이용된다면 글쓴이가 꽤 불편할 것 같은데요.

소프트웨어 개발은 눈에 보이지 않습니다.
따라서, 처음 소프트웨어 개발을 접하는 관리자에게는 의미있는 정보일 수 있어서 번역해보았습니다.

어떻게 측정하고, 어떻게 평가할 수 있을까요? 그리고, SI 현장에서는 적용할 수 있을까요? 어려운 주제입니다.

소프트웨어 개발은 육체노동이 아니라, 지식노동이고 창조적 활동에 가깝습니다.
장점은, 비교적 작은 노동으로도 정말로 훌륭한 걸 만들 수도 있다는 것입니다.
단점은, 시간에 비례해서 결과의 품질이 높아지거나 기대효과가 커지거나 하지 않는다는 것입니다.
그리고, 아직 이런 소프트웨어 개발과정을 효과적으로 다룰 수 있는 수단은 없다는 것입니다. 그래서 아직도 많은 프로젝트가 건설공정에 맞추어 진행되고 있습니다.

소프트웨어적 창의활동이 예술에 머무르지 않고, 산업화되려면 어떻게 해야할까요?
아직 산업계의 정답은 없습니다. 다행히 이것은 전 세계적으로 비슷한데요.
이 글은 영국에서도 효과적 수단을 가지지 못하고 있음을 나타내는 것이어서 눈여겨볼만 합니다.

---

※ 원제 : Are Your Programmers Working Hard, Or Are They Lazy?
※ 저자 : 2013.12.12, Mike Hadlow, 브라이튼, 영국, 소프트웨어 아키텍쳐, EasyNetQ and Suteki Shop.의 저자

사람들이 육체적인 일을 할 때, 얼마나 열심히 일하는지 아는 건 매우 쉽다.
그들이 육체적으로 얼마나 많이 움직이는지, 얼마나 많이 땀을 흘리는지 보기만 하면 된다.
또한, 결과를 쉽게 볼 수도 있다. 벽돌은 점점 높아지고, 파헤쳐놓은 땅은 점점 더 넓어진다.
힘들게 일한 것을 인지하고 보상해 주려는 감정은 꽤 기본적인 인간의 본능이다.
그것은 우리가 인내력을 요하는 스포츠에 매료되는 이유 중 하나이기도 하다.

그러나, 육체적으로 힘든 것에 대한 보답 본능은, 창조적 기술을 사용하는 직원들을 관리할때는 문제가 된다. 지식 노동을 효과적으로 하는 사람들은 종종 열심히 일하는 것처럼 보이지 않기 때문이다.

(경험)
2004년에, 나는 한 케이블 TV회사의 billing and provisioning 시스템을 운영하는 커다란 팀의 신입 개발자였다. 모든 큰 시스템 처럼 그 시스템도 수많은 독립 컴포넌트들과 그것을 관리하는 관리자 및 작은 팀들로 구성되어 있었다. 아날로그 TV와 디지털 TV 현행화 시스템은 거의 완전히 분리되어 있으며, 각각 다른 팀이 관리하고 있었다.

(아날로그 TV팀 사례)
아날로그 TV팀은 MS Biztalk 초기 버전에 기반한 그들의 시스템을 사용하고 있었다.
우리직원 네 명과 생산라인에서 운영 및 개발을 하고 있는 MS 직원 한 팀이 있었다.
그들 모두 정말 열심히 일하는 것처럼 보였다. 종종 밤새도록 일했고, 주말에도 나오기도 했다.
생산라인에 이슈가 생기면 그들 모두 하던 일을 그만두고, 한 사람 뒤에 주욱 둘러서서 무엇이 틀렸는지 어떻게 고쳐야 하는지를 논의했다.
그것이 일상적인 광경이었고 누구나 볼 수 있었다.
적어도 외부에서 보기에 그들은 팀으로 서로 끌어주기도 할 뿐더러 정말로 정말로 열심히 일하는 것처럼 보였다.

(디지털 TV팀 사례)
디지털 TV 프로비져닝 팀은 달랐다. 코드는 거의 한 사람에 의해서 작성되었다. Dave 였다. 나는 유지보수 팀에서 신입 개발자였다. 처음에 나는 그 코드를 이해하는데 종종 어려움을 겪곤했다. 그의 손이 닿은 모든 곳에서 긴 process는 없었다. 대신 몇몇 라인의 코드로 작성되어진 작은 클래스와 메소드로 가득차 있었다.
나를 포함한 동료들은 Dave 가 일을 너무 복잡하게 만든다고 불평했다.

그러자, Dave는 나를 곁으로 데려와서 객체 지향 프로그래밍에 대한 책 몇 권을 읽어보게 했다.
그는 나에게 설계패턴과 SOLID 원칙, 유닛테스트를 가르쳐주었다. 코드가 이해되기 시작하고 나서부터, 나는 일을 하면 할수록 그가 만들어 놓은 유연한 설계에 대해 더욱더 감사하게 되었다.
생산라인에서는 나로 인한 장애도 없었고 , 나는 콧노래를 부르며 일을 할 수 있었다.
코드를 바꾸는 것이 너무도 편했다. 그래서 새로운 기능을 구현하는 것이 종종 너무 쉬웠다.
유닛테스트에서는 버그가 거의 발생되지 않았다.

하지만, 결과적으로 우리는 전혀 열심히 일하는 것처럼 보이지 않았다.
우리는 5시 30분에 집에 갔고, 나는 주말에 일하지 않앗다.
우리는 시스템 장애시 무엇이 잘못되었는지 이런저런 추측을 하느라 다른 사람들의 책상에서 웅성거리지도 않았다.

외부에서는 우리가 아날로그 TV팀보다 훨씬 쉬운 일을 한 것처럼 보였을 것이다.
그러나 사실, 요구사항은 비슷했다. 우리는 더 잘 설계했고, 더 잘 소프트웨어를 구현했으며, 더 잘 인프라를 지원할 수 있게 만들었다. 특히 단위테스트에 대해 더많이 신경을 썼다.

(경영진의 시각)
경영진은 실적에 기반해서 급여를 올려주겠다고 했다.
그러나 사장이 나와 면담하게 되었을때, 그는 정말로 열심히 일하는 사람에게 급여를 올려주는 것이 공정하다고 말했다. 그리고, 우리팀이 회사에 그다지 신경쓰지 않는 것처럼 보이며 주말과 저녁을 포기하는 영웅들과 비교할 수도 없다고 열심히 설명을 했다.

(시사점)
케이블 회사는 드문 사례다.
좋고 나쁜 설계의 결과가 어떤 팀 행동을 만들어내는지 직접 보여주고 있다.

하지만, 대부분의 조직에서는 그런 비교를 할 수 없다.
땀에 쩔어 주말과 밤늦게까지 일하고 계속 소방수를 하는 사람이, 정말 정말 복잡한 시스템 작업들을 훌륭하게 하고 있는 것인지, 아니면 그냥 실패만 하고 있는지 알 수 없다.
두 개 이상의 팀이 같은 문제를 풀기 위해 경쟁하는 경우가 아니라면, 누가 제대로 하고 있는지 알기 힘들다.
반대로, 구석에서 9시부터 5시까지 일하는 사람은 어떻게 생각하는가?
인터넷이나 보면서 대부분의 시간을 보내는 사람인 것처럼 보이는가?
아니면 그가 안정적인 일만 하는 숙달된 사람이거나, 다른사람들보다 더 쉬운 일만 하는거라고 생각하는가?

일반적인 관찰자를 보자.
첫번째 직원은 정말 열심히 일하고 있고, 두번째는 그렇지 않다.
열심히 일하는 건 좋은 사람이고, 게으른 건은 나쁜 사람이다. 그렇지 않은가?

(나의 견해)
나는 힘든 일이 일어난다는 것은 실패의 조짐이라고 생각한다.
소프트웨어 개발은, 압박이 높고pressurised 일을 집중해서 할 수 없는interrupt driven 환경에서는 제대로 되지 않는다.
오랜 시간 일하는 건 종종 좋은 생각이 아니다.
어려운 문제를 푸는 좋은 방법은 때때로 생각하는 걸 멈추고 산책을 하는 것이다.
아니면, 잠을 자면서 잠재의식이 문제를 풀게 하라.

내가 가장 좋아하는 책 중에 G.H.Hardy(20세기 선구적 영국 수학자)가 쓴 A Mathematician’s Apology 이라는 책이 있다. 그 책에서 그는 자신의 일상을 기술했다.
‘나는 아침에 4시간 일을 하고, 오후에는 크리켓 경기를 봅니다.’
그는 하루에 4시간 이상 심리적 작업을 하는 것은 무의미하고 비생산적이라고 했다.

(부탁)
관리자 분들께 ‘열심히 일하는 것처럼 보이는 것 말고’, 일의 결과와 동작하는 소프트웨어로 판단하라고 말하고 싶다.
‘본능과 반대되겠지만, 개발자와 함께 앉아있지 마라.’
개발 결과물은 관습화되고 본능적인 지표와 아무런 관련이 없다는 걸 알아야 한다. 
오히려, 원격작업이 더 낫다.
하루 8시간씩 컴퓨터 앞에 머리를 처박고 앉아있는 걸 보거나, 개발자 뒤에서 ‘고맙게도’ ‘유용한’ 제안을 하지말고, 결과물로 직원들을 평가하라.