회사가 개발자를 고문하는 16가지 방법

회사가 개발자를 고문하는 16가지 방법 - Andrew C. Oliver | InfoWorld

훌륭한 개발자들을 확보하려면 그만큼 훌륭한 환경을 제공해야 한다. 점점 더 구인경쟁이 치열해지는 가운데 식사를 무료로 제공하거나 노동시간의 일부를 자유롭게 활용할 수 있도록 '유급' 여유 시간을 주는 기업이 나타나는 것도 이 때문이다. 

그러나 모든 기업이 개발자의 중요성을 인식하고 있는 것은 아니다. 몇몇 기업들은 여전히 개발자를 혹사시킨다. 여기 개발자를 힘들게하는 다양한 유형을 소개한다. 이 가운데 한 두 가지 이상을 하고 있다면 그 기업은 최고의 개발자들을 다시는 채용하지 못하게 될 것이다.

 

1. 지옥 같은 보안

필자는 맥아피(McAfee) 프록시가 헬로월드자바(HelloWrold.java)에 집(Zip) 파일을 금지해 놓은 곳에서 일했었다. 이는 빌드 툴 다운로드에서 예시까지 모든 것들이 금지됨을 뜻한다. 또 다른 회사에서는 맥아피 데스크톱 시큐리티(McAfee desktop security)가 프로세서가 건드리는 모든 파일마다 악성 코드 여부를 확인했다.

심지어 지난번 체크한 이후로 변화되지 않은 파일들까지 모두 단일 스레드 방식으로 검사했는데 그 때문에 모든 작업마다 CPU 코어 하나로 수천 개의 파일 컨텐츠를 확인하는 과정을 거쳐야 했다. IDE 시작하는데 30분이 소요됐고 빌드를 시작하는데 또다시 10분이 추가적으로 소요됐다. 심지어 그 빌드가 단 세개의 소스 파일만 건드리고 몇 초 가량만 실행되었음에도 말이다.

 

2. 고문 툴

솔직히 말해 서브버전(Subversion)과 깃(Git) 이외의 모든 버전/구성 관리 툴들은 너무 느리거나 사용하기 고통스럽다. 특히 클리어케이스(ClearCase)는 모든 개발자들을 고문하는 대표적인 툴이다.

 

3. 유지보수팀

몇몇 회사들은 여전히 모든 귀찮은 일을 처리하는 별도의 팀을 운영한다. 그러나 진지하게 말해 누구도 만약 더 좋은 직장이 있다면 절대 '유지보수팀'에서 일하고 싶어하지 않는다. 그리고 더 좋은 직장을 잡을 기회는 자주 생기는 편이다.

 

4. 강제된 윈도우

닷넷(.Net)을 사용하지 않는 개발자에게 윈도우를 개발 환경으로 사용하도록 강요하는 것은 꽤나 가학적인 조치다. 강제된 윈도우는 개발자들에게 아마추어 개발자나 쓰는 쓰레기를 동일하게 사용하며 그들과 같은 한계에 갇히라는 의미다. (필자의 팀원들 중 몇 명은 필자가 그들에게 리눅스를 강요했다고 이야기할 것이다. 그러나 이건 윈도우 강제보다는 훨씬 낫다)

 

5. 모든 라이브러리 잠그기

과거에 필자가 IBM에서 일하던 시기에, 오픈소스건 아니건 개발 시간을 두 달 이상 줄여주지 않는다면 서드파티 라이브러리를 절대 사용하지 말라는 지침을 받았다. 변호사에게 서드파티 라이브러리 사용에 필요한 법적 심사를 의뢰하는 비용이 필자의 두 달치 월급 이상이었기 때문이다. 그 후 곧바로 필자는 시급을 올렸다. 물론 공식적인 심사 과정을 거치지 않고 라이브러리를 어디서 어떻게 써야 하는지를 상세히 검토하는 정책이 필요한 거지만 그랬다 하더라도 '낙천적 잠금'은 보통 문제가 없다. 그렇지 않으면 모든 개발자들에게 바퀴부터 다시 발명하라고 강요하는 악랄한 행위를 저지르는 것일테니까.

 

6. 웹스피어

보라, IBM이 마침내 READ_COMMITTED를 추가한 지금, 필자는 DB2을 쓸 수 있게 되었다. 그러나 웹스피어(WebSphere)는 너무나도 고통스럽다. 제발 웹스피어를 부팅하거나 WAR 파일을 배치하는데 필수적인 50 GUI 화면을 거치지 않았으면 좋겠다. 웹스피어는 한마디로 개발자 학대 그 자체다. 정말 최악인데 지금까지 항상 그래왔다. 만약 여기서 다른 어느 것도 얻어낼 수 없다면 웹스피어를 과감하게 삭제하라. 그렇지 않으면 개발자들이 뒤에서 당신을 욕할 것이다. 만약 개발자들이 욕을 하지 않는다면 더 실력있는 개발자로 교체하는 편이 낫다.

 

7. 죽음의 행진

개발자들에게 지속적인 죽음의 행진을 강요한다면 그들을 소진시키는 일이 된다. 또한 개발자 스스로도 임시방편으로 일을 처리했다고 느끼게 된다. 어느 누구도 큰 골치거리를 몇 주간이나 계속해서 청소하고 싶어하지 않는다. 따라서 단기간의 유지보수는 해답이 될 수 없다. 그 대신 개발자들에게 그들이 원하는 시간보다 약간 적은 시간을 부여하라. 초과하면 경비 초과를 유발하고 부족하면 개발자 학대다.

 

8. 아, 2010년은 좋은 시절이었지

놀라운 것은 3~4년된, 더구나 한번도 테스트하지 않은 (아마도 윈도우용) IDE를  표준 개발환경으로 쓰라고 하는 기업이 있다는 것이다. 그러나 개발자들이여, 우리가 분명히 알아야 하는 것은 지금과 같은 경쟁적인 노동 시장에서는 더 좋은 복지 혜택과 새 버전을 사용할 기회를 제공할 다른 기업이 분명히 있다는 점이다.

 

9. 미안하지만, 우리는 지겨운 일만 한다

필자도 힙스터해커(HipsterHacker) 아키텍쳐를 싫어한다. “오, 좋아 보이니 저것도 또 다운로드 해줄게”하는 식으로 개발된 시스템이기 때문이다. 그렇다고 개발자들에게 새로울 것 하나 없는 똑같은 세트로 코드를 개발하라고 하면 개발자들은 자신들의 경력을 심사숙고 하게 될 것이다. 따라서 둘을 적절하게 포용해야 한다. 개발자들이 새로운 것들도 접할 수 있게 하면서 안정적인 아키텍쳐로 위험을 최소화시키도록 해야 한다.

 

10. 무한 모래시계의 VM

기업 IT 인프라를 완전히 가상화한 기업들이 있다. 심지어 개발 환경까지 가상화됐다. 그렇다면 "와, 끝내주네!"가 결론일까? 하지만 안타깝게도 하드웨어에 자금을 덜 지원했거나 이를 제대로 최적화하지 않아 모든 게 느려졌고 이는 엄청난 고문이 되기도 한다. 몇몇 사람들은 명상에 심취해서 두 시간이 넘는 빌드 프로세스를 개의치 않을 수도 있다. 그러나 필자는 그런 종류의 사람이 절대 아니다.

11. 가짜-스크럼 일일 회의

최악의 죄인들을 위해 마련된 특별한 지옥이 있다. 바로 관리 상황 업데이트를 위한 일일 스크럼(scrum) 회의다. 이 회의는 중요한 개발 사항을 전달하는 자리가 아니다. 경영진에게 그들이 일을 하느라 매우 바쁘고 그래서 계속 회사에 붙어 있어야 한다는 점을 납득시키기 위해 최소 5~6분씩 이야기하는 자리다.  이 회의는 보통 12명 이상이 참석하는데 사실 그들 대부분 그 자리에 있을 필요가 없다. 30분에서 45분, 혹은 그 이상 회의가 진행되는데 (실제 스크럼 회의는 5~6분 정도면 끝난다), 말하지 않는 참석자들은 다들 정신이 나가 있기 마련이다.

 

더 최악은 모두가 작업간 전환(context switching)이 있을 것임을 알기 때문에 이런 회의 전에 일을 하지 않는다는 점이다. 회의 후 점심식사도 또 한 시간은 걸리는데 당장 열심히 일할 필요가 없기 때문이다. 기본적으로 이런 회의는 팀의 오전 전체를 잡아먹고 사기를 저하시키며 아무런 결론도 나지 않는다. 뭔가 빠르게 실행하는 법을 익히던가 아니면 회의를 취소하라.

 

12. 형식주의

형식주의는 양복을 차려 입는 것에 그치지 않고 생각지도 못한 방식으로 드러난다. 역설적으로 평상시 환경이 격식 수준을 설정하기 더 까다로워 더 어렵지만, 개발자들은 양복 입는 환경에 대해 오랫동안 강하게 저항해왔다.

 

필자가 J보스(Jboss)에서 일할 때 세 명의 개발 이사들이 차례로 필자에게 양복 셔츠와 바지 조합을 입지 말고 차라리 마트에서 괜찮은 옷을 사라고 돈을 주겠다고 했었는데, 그들의 제안은 진심이었다. 그들은 만약 J보스(구멍 난 샌달 군단)가 양복을 차려 입고 나타나면, 경영진이 점차 개발자들에게 정장을 다시 강요할 것이라는 걱정을 하고 있었던 것이다.

 

이 캐주얼 환경은 사실 인위적인 구조다. 최근 필자는 “이게 우리가 욕을 더 이상 못한다는 의미인가요?”라고 즉각 되물었던 인사 관리자를 채용하면서 기준을 정하려고 했었다. 그 때 필자가 생각했던 기준은 이거였다. “아니 욕은 좋아. 언제 어디서나 이유가 있건 없건 매일 욕을 달고 사니까. 단, 고객만 옆에 없다면 말이야”

 

사람들이 (가령 더러운 농담을) 이야기하는 방식과 사람들이 생각하는 방식 (“가장 기술적으로 타당한”) 사이에는 캐주얼한 환경과 형식적인 환경 사이의 차이가 있다. 이러한 차이는 더 많은 규칙을 요구하는 더 큰 환경 때문에 발생하기도 하고 혹은 사람들이 절차, 발언, 복장 등에 있어서 격식과 과도한 '형식주의'를 너무 좋아해서 나타나기도 한다. 개발자들에게 형식주의를 위해 모든 것을 틀에 맞추라고 하는 것은 그들의 정신과 생각에 대한 학대다.

 

13. 인질 사태로의 경영

부하 테스트가 실패하면 경영진은 근본 원인과 그 해결방안을 듣고 싶어할 것이다. 그들은 이미 구축된 것을 걷어낼 수 있다고 위협하기도 하는데 이는 개발 절차를 망치는 완벽한 길이다. 경영진이 너무 세세하게 관리하고 동시에 과도하게 권위를 주장하는 것은 프로젝트 테스트의 일반적인 반복 과정에 방해만 될 뿐 아니라 개발자들이 무언가를 시도하거나 의도치 않은 주의를 끄는 것을 기피하게 만든다.

 

연관된 기능성을 이해하지 않은 채 과감하고 즉각적인 파괴행동으로 개발자를 위협하는 것은 기껏해야 급조된 제품을 양산하는 결과로 이어질 뿐이다. 프로젝트가 공황상태에 빠진 고객이나 경영자에게 휘둘리도록 하는 것은, 그 상황이 개발자들의 통제를 벗어난다 하더라도 설사 미리 경고를 했더라도 그 결과에 책임을 지게 되도록 만든다. 목표와 데드라인 가이드는 프로젝트를 완료하기 위해 존재하는 것인데 흔들리는 회오리바람은 이를 파괴시킨다.

 

14. 우리는 이 부근을 묻는다

의심스러운 기기가 제한된 포트를 통해 스카이프(Skype)에 접속하려는 시도를 발견한 개발자가 있다고 가정하자. 그는 이것이 규칙에 위반되는지 모르고 있다. 그는 가이드라인에 대해 문의했지만 어떤 세부 지침도 제공되지 않았다. 축하한다. 당신의 회사는 방금 모호하고 사전 공지 되지 않았거나, 문서화 되지 않은 제약을 지키지 않았다며 개발자를 처벌했다. 이 사건으로 인해 그가 회사를 나갈 가장 빠른 길을 찾는다고 해서 놀라지 말기 바란다.

 

15. 세부사항이라고, 세부사항

잘난 체 하는 상사: “고객이 수정을 문의했는데 그걸 시간 안에 추가할 수 있나?”

코더: “아니오. 중대한 아키텍처 수정이 필요합니다. 우리는 시작하기 전에도 물어봤고 그런 류의 확장을 가능케 하는데 시간을 쓰지 말라는 이야기를 들었습니다”

 

요구조건들이 애초부터 정해지는 일은 드물다. 그러나 앞서 경우처럼 있음직한 변화를 고려하지 않고 최단 경로를 택하도록 개발자들을 압박하는 것은 훗날 그 요구가 제기됐을 때 개발자들을 곤란한 상황에 처하게 만든다.

 

16. 그냥 어떻게 작동하는지 말해

몇몇 관리자들은 원인에 대한 가설을 제기하기를 거부하고 적절한 조사도 없이 문제에 대한 즉각적인 솔루션만을 요구한다. 보통 “당신 전문가 아닌가? 이걸 그냥 설명하거나 해결할 순 없나?”라는 식의 언어적 공격과 같이 오기도 한다. 그러나 솔루션을 찾기 위해서는 그 원인을 조사하고 가설을 설정하고 테스트해야 한다. 우리는 결코 결론으로 앞서갈 수가 없다. 문제 해결 방법은 추측과 확인 이후에 오는 것이다. editor@idg.co.kr

연구학습용 정보출처 : http://www.itworld.co.kr/news/81229