[ 펌 ] 프로그래머 생산성을 떨어뜨리는 15가지

원본 : http://www.ciokorea.com/slideshow/19128?slide=1#stage_slide

제품은 어제 출고됐어야 했다. 사용자들은 기능이 빠졌다며 불평한다. 상사의 상사는 지금 움직이지 않으면 정말 끝이라고 말하고 있다. 그 어느 것 하나 제대로 된 것이 없다.

모든 사람들이 코드가 소방용 호스에서 물이 쏟아져 나오듯이 코드가 흘러가기를 바라면서도 개발자들이 작업을 하기 위해 필요로 하는 것을 줄 생각은 하지 않는다. 예전에 같은 일을 했던 상사조차도 인력을 더 고용하거나 더 빠른 장비를 구매하거나 프로그래머들이 일을 더욱 쉽게 하는데 도움이 되는 것들을 하지 않는다.

오늘은 프로그래밍 중 경험하게 되는 15가지의 장애물에 관해 이야기해 보도록 하자. 비공식적으로 간단한 설문조사를 진행했다. 누군가 자신의 이야기를 들어주고 있다고 느낀 개발자들은, 솔직히 불평을 쏟아냈다

1. 회의 
가장 많은 불평의 주범은 회의였다. 상사들이 자질구레한 것들에 관해 떠드는 동안 어두운 회의실에 붙잡혀 있어야 한다. 또 프로그래머들은 회의 이후 소프트웨어라는 추상적 세계로 재진입하기 어렵다고 토로했다. 두뇌가 추상적인 알고리즘을 다룰 수 있도록 적절한 상태가 되기 위해서는 시간이 필요하며 회의 때문에 작업이 더욱 지연될 수 있다는 지적이었다.

2. 모든 이메일에 답장하기 
회의도 별로지만, 다른 것도 이에 못지 않다. 끝없는 이메일을 확인하는 것 또한 고역이다. 답장을 보내기 위해서는 몇 시간이 소요되며, 그 누구도 결과에 만족하지 않는다. 태도가 바르지 못한 개발자들은 이상한 자존심에 못 이겨 "tl;dr" 같은 대답을 남발할 것이다.

일주일에 하루씩 이메일을 금지하려는 팀도 있다. 아예 이메일을 포기하는 사람들도 있다. 이를 통해 과부하 문제를 해결할 수 있지만 의사소통을 희생해야 하는 단점이 있다. 갑자기 사람들이 서로 공조하지 않는 것이다. 정상일까?

3. 생산성 측정 시도하기 
"측정할 수 없는 것은 관리가 불가능하다." 관리팀이 종종 감동하는 격언이다. 그들은 소프트웨어의 커밋(Commit) 또는 라인(Line) 또는 수정된 버그의 수를 집계하기 시작한다. 그들은 집계가 측정이며 측정은 좋은 것이라고 생각한다.

이렇게 산출된 생산성 측정치는 프로그래머의 순위표(Leader Board)가 된다. 그들은 코드를 더 잘 만드는 대신에 라인 작성이나 버그 해결 또는 저장소에의 커밋과 같은 양적인 것에 집중하게 된다. 생산성을 측정하게 되면 과도한 기능이 적용된 코드로 가득 찬 긴 파일만 조장하게 되는 것이다.

애석하게도 이 문제를 해결할 수 있는 방법은 존재하지 않는다. 버그를 추적해야 하며 작업흐름을 정리하고 소프트웨어 개발을 조율해야 한다. 우아함을 측정하기란 불가능하다.

4. 프리마돈나 개발자 
프로그래머들에게 상사보다 못한 동료가 있다. 마지막 버전을 개발했으면서도 더 이상 프로젝트에 참여하지 않는 개발자가 그들이다. 모든 주택 건축업자들이 마지막 목수의 기술을 폄하하는 것처럼 모든 프로그래머들은 마지막 작업자의 개념 없는 행태를 재빠르게 찾아낼 수 있다.

사실 프로그래머가 말하는 것만큼 나쁜 경우는 드물다. 그리고 때로는 기술이 부족해서가 아닌 경우도 있다. 스타일이 서로 다르며, 스타일은 시간이 지나면서 바뀌게 된다. 마지막 세대는 현재의 라이브러리와는 다른 라이브러리를 갖고 있다. 그들은 현재의 새로운 것들을 알지 못했다.

그러나 이런 프리마돈나적인 태도는 문제가 될 수 있다. 자부심과 사리사욕 때문에 프로그래머들이 각자의 "올바른 방식"으로 적절한 코드를 버리고 재구성하면서 프로젝트가 지연되는 것이다.

5. '나중에 고치자' 기술적 부채 문제
프로젝트 계획에 있어서 개발하기 위한 충분한 시간이란 존재하지 않는다. 이에 따라 거친 부분을 다듬고 코드를 패치하며 가상의 접착 테이프를 떼어낸다. 어떤 스마트한 관리자는 회계직원의 "부채"라는 표현에 착안해 이를 "기술적 부채"라 부르기도 했다. 

사실 모든 프로젝트에는 기술적 부채가 존재하기 마련이다. 때로는 신속하게 갚을 수 있지만, 때로는 다음 세대를 황당하게 만드는 부채다. 마지막 세대가 개발하지 못했던 것을 개발해야 하기 때문이다. 이것은 규모만 다를 뿐 마치 국가 부채와도 같다.

6. 프로그래머가 아닌 관리자 
컴퓨터 공학 이외의 학문을 전공했지만 프로그래밍 프로젝트에 참여한, 항상 미소 짓는 행복한 사람들이 언제나 존재한다. 

아마도 그들은 사장의 자녀와 결혼했거나 적절한 시기에 적절한 곳에 있었을 것이다. 하지만 사장은 블랙베리도 힘들어하는 그런 사람을 관리자로 임명했다.

이런 사람을 놀리기 쉽기 때문에 이런 사람을 좋아하는 프로그래머도 있다. 그들에게 존슨(Johnson) DB에 큰 문제가 발생했다고 말하면 그들은 그 말을 믿고 이런 불운한 소식을 바로 보고할 것이다. 그러나 누군가는 상급 관리자로부터 질책을 받아야 한다. 

이런 사람들이 회의를 빈번히 소집하면서 방해를 일 삼기도 한다. 그들은 제대로 된 안내를 하지 못하며, 기껏해야 품질 시험 정도가 가능할 뿐이다.

7. 프로그래머 관리자 
프로그래머가 아닌 관리자들과 일하는 것에 대해 불평할 수 있겠지만, 때로는 프로그래밍 능력을 갖춘 관리자가 훨씬 더 안 좋을 경우가 있다.

전문 지식을 가진 관리자는 도리어 자신이 세운 새로운 목표에 맞춰 프로젝트를 너무 세부적으로 관리하며, 때로는 코드를 대폭 수정하기도 한다. 또는 8080 어셈블러(Assembler) 또는 C 또는 자바(Java)로 프로그래밍 하던 시절에 같은 코드를 어떻게 절반 수준으로 작성했는지 지껄이기도 한다. 

그들은 또 자신의 본연의 임무를 잊은 채 전체적인 그림 보다는 기술적인 세부사항에 더욱 집착하기도 한다

8.마초 프로그래머 '브로그래머'(brogrammers) 

프로그래머들은 종종 스스로에게도 문제가 있다고 인정하곤 한다. 의사소통 기술이 부족하며 감정이나 자아를 잘 고려하지 못한다. 강아지가 뼈다귀을 발견해 따라가는 것처럼 기술적 논쟁에 집착한다. 고객이 다른 것을 원하는지 여부는 상관 없다. 그저 기술적 논쟁에 매달리는 것이다.

프로그래머들은 또 종종 각자의 특이한 성격을 보유하고 있으며 프로그래머들간의 충돌로 팀이 깨질 수 있다. 동적 언어 또는 NoSQL 등에 관해 다른 관점을 가진 두 사람이 결국 같은 팀에 소속되는 일이 비일비재하다. 모든 것을 투표로 결정하기도 하며, 그 어떤 것도 이뤄지지 않는다. 모든 것들이 끝없는 전쟁의 시작일 뿐이다.

9. 이기적이거나 고독한 코드 개발자 
그의 코드에서 널 포인트(Null Point)를 발견했는가? 그것이 당신의 임무이다. 그리고 자아에 도취된 코드 개발자는 0으로 나누기 오류를 확인하지 않기 때문에 다시 한 번 살펴보아야 한다. 이것도 당신의 임무이다.

자아도취에 빠진 코드 개발자는 작업을 멋지고 빠르게 진행하지만 이 때문에 당신은 결국 더 많은 테스트를 실시해야 한다. 이런 지루한 일을 처리해 갈등이 발생하지 않도록 하는 것이 당신의 임무다.

그러나 많은 팀들이 너무 늦게 이런 사실을 깨닫는다. 테스트 초기에는 코드 덩어리들이 제대로 동작하지만 누군가 실제적인 데이터를 입력하기 시작하면 모두들 그 누구도 문제를 확인하지 못했다는 사실을 깨닫는다. 이런!

10. 형편 없는 문서화 
문서 작성에는 시간이 필요하다. 하지만 월급을 받는 이유는 코드를 개발하기 때문이다. 개발하는 코드로 평가를 받는 경우가 많다. 당신은 결과를 원하며, 우리는 단지 당신이 원하는 일을 하고 있는 것이다. 걱정하지 마라. 기억해 두고 있다가 나중에 모두 작성할 것이다.

인정한다. 때로는 문서작업이 필요하긴 하다. 그러나 수 개월 또는 수 년이나 지난 코드 버전과 관련된 일이다. 이 방법이 푸(Foo) 표에 데이터를 저장한다고 말했던가? 실수였다. 그것은 2세대나 전의 일이며, 코드를 수정하고 이런 오래된 설명자료를 고칠 시간이 없었다. 하지만 곧 수정할 것이다.

11. 문서화에의 맹종 
문서가 제대로 기록되어 있지 않은 프로젝트로 고생한 경험한 경험이 모두들 있다. 반면 코드를 너무 장황하면서도 적게 개발해 프로젝트가 실패하는 경우도 다반사다. 어떤 사람들은 책장에 꽂혀있는 바인더들을 보여주면서 "문서 기록량에 따라 비용을 지급했다"고 말하기도 한다. 이 모든 것들을 읽기 위해서는 엄청나게 오랜 시간이 걸린다.

프로그래머들은 때로는 "배틀스타 갤럭티카(Battlestar Galactica)" 또는 "닥터 후(Dr. Who)"에 관해 논의하는 것과 같은 방식으로 의견서 요건을 취급하는 경우가 있다. 요약이나 요점 없이 아주 세세한 부분을 포함하여 끝 없이 문서를 작성하는 것이다. 

개념이나 이해 대신에 코드의 기능에만 치중하게 되면 이런 부분들이 굉장히 모호해질 수 있다. 결국 코드를 그저 다른 말로 바꾸는 수준에 그친다. 

12. 집중력을 저하시키는 환경 
어떤 고객은 사무실을 방문해 자신의 컴퓨터를 사용해 개발하기를 요청했다. 그러나 그 컴퓨터를 원하는 환경으로 설정하는 데만 1주일이 소요됐었다. 사무실 공간도 협소햇으며, 반나절은 전날 밤에 무슨 일이 있었는지에 관해 떠들고 나머지 반나절은 그날 저녁에 무슨 일을 할지에 관해 이야기하는 6명의 인턴과 함께 한 회의실에서 작업을 진행했었다. 즐겁기는 했지만 작업을 거의 처리하지 못했다.

프로그래머는 때로는 도서관처럼 조용한 공간이 필요하다. 담소, 두드리는 소리, 벨소리 등으로 인해 프로그래머는 추상적 공간을 벗어나 현실로 돌아오게 된다. 그리고 다시 업무 모드로 돌아가기 위해서 시간이 소요된다.

많은 기업들이 프로그래머들에게 탁구대 같은 장난감을 선사하지만 개발자들은 집중을 위한 조용한 환경이 필요하다는 사실을 잊곤 한다.

13. '문화적 적합성' 
비슷한 사람들이 모인 팀들이 더 나은 결과물을 도출해 낸다. 공통점을 찾을 수 없는 팀은 금방 실패한다. 의사소통은 절대로 이루어지지 않으며 결국 중구난방으로 일하게 된다.

최고의 작업 환경이 무엇인지에 관해 일반화하기도 하지만, 이는 경우에 따라 다를 수 있다. 때로는 모두를 가까운 거리에 모아두는 것이 도움이 될 수 있다. 빌드(Build)가 완성되기를 기다리고 있을 때 누군가 질문을 던진다고 해서 크게 방해가 되지는 않는다. 모두에게 공통적인 메시지를 전달할 때는 매우 효율적일 수 있다.

하지만 복잡한 알고리즘을 생성할 때는 간섭, 대화, 심지어 키보드 타이핑 소리가 방해가 될 수 있다. 이럴 때 자신만의 사무실이 필요하게 된다.

14. 레거시(Legacy) 기술에의 집착 
다이스닷컴(Dice.com)에는 7만 개 이상의 직업 목록이 있다. 이 중 제목에 (Cobol)이 포함된 목록은 680개에 달한다. 여전히 약 1% 정도를 차지하고 있다. 이런 오래된 것을 왜 다시 개발할까?

때로는 오래된 코드의 유지 비용을 까맣게 잊어버리는 경우가 있다. 모든 것들을 재해석해야 하고 때로는 맞춤형 코드도 필요하다. 일부 코드는 ASCII 이전에 개발되었기 때문에 입력과 출력이 뒤집혀 있다. 오래된 시스템은 때로 데이터베이스에 무엇이 들어있는지 파악하기 위해 공백 글자를 세야 하기도 한다. 이 때문에 더 많은 작업이 필요하다.

이로 인해 프로그래머는 스크린 스크래핑(Screenscraping), 재형식화(Reformatting), 임시 시스템에 능함에도 불구하고 새로운 로직을 작성하기보다는 중간 로직을 개선하는데 더 많은 시간을 보내게 된다

15. 최신과 최고에의 욕망 
우리 모두는 이런 사람과 회의를 진행한 경험이 있다. 그는 자바를 "할아버지 세대의 것"으로 치부한다. Node.js 는 너무 오래된 2012년의 것이다.

최신 툴이 재미있기는 하지만, 지난 주에 작업할 것을 몇 시간에 걸쳐 코드를 변환하지 않은 채 개발에 사용할 수 없다. 최신을 즐기는 사람들은 항상 모든 API를 버리고 이것들을 다시 작성해 다른 사람도 어쩔 수 없이 코드를 다시 작성하게 만든다.

경우에 따라서는 새로운 툴이 다듬어지지 않은 경우도 있다. Node.js는 손쉽게 사용할 수 있지만 처음부터 사람들이 쓰레드(Thread)를 작성하는데 있어서 직면하는 장애물에 대해 다시 학습하는 경우에나 가능한 이야기다. 때로는 최신 기술로 더 나은 결과물을 도출할 수 있지만, 모든 것에는 대가가 따르기 마련이다.