Search Results for '개발자'


2 posts related to '개발자'

  1. 2014/02/20 개발자에게 야근은 미친 짓이다
  2. 2012/12/26 [펌]개발자, 회사의 과거인가 미래인가

칼럼니스트 : 임백준

이메일

baekjun.lim@gmail.com

약력

한빛미디어에서 『누워서 읽는 퍼즐북』(2010), 『프로그래밍은 상상이다』(2008), 『뉴욕의 프로그래머』(2007), 『소프트웨어산책』(2005), 『나는 프로그래머다』(2004), 『누워서 읽는 알고리즘』(2003), 『행복한 프로그래밍』(2003)을 출간했고, 로드북에서 『프로그래머 그 다음 이야기』(2011)를 출간했다. 삼성SDS, 루슨트 테크놀로지스, 도이치은행, 바클리스은행 등에서 근무했고 현재는 뉴욕에 있는 모건스탠리에서 자바, C#, 스칼라 언어를 이용해서 금융관련 소프트웨어를 개발하고 있다. 뉴저지에서 아내, 두 딸과 함께 살고 있다.

이러저러한 사정 때문에 며칠 야근을 하게 되었다. 아침 8시부터 코딩을 시작해서 밤 12시까지 멈추지 않았다. 더 이상 몸이 견딜 수 없을 때 잠을 잤고, 다시 아침에 일어나서 새벽부터 코딩을 시작했다. 미국 동부에 폭설이 내려서 아침저녁으로 눈을 치워야 했던 것은 덤이다. 이런 식으로 끝까지 ‘달린’ 것은 5년 만의 일인 것 같다. 그리고 결론을 내렸다. 야근은 미친 짓이다.
프로그래머가 정신을 집중해서 양질의 코드를 만들어낼 수 있는 시간의 최대치는 하루에 2~3시간이라는 것이 정설이다. 내 경험에 비추어 봐도 그렇다. 나는 아침 9시에 사무실에 도착하고 오후 6시에 퇴근을 한다.
점심시간을 빼면 하루에 8시간을 컴퓨터 앞에 앉아 있는 셈이다. 하지만 컴퓨터 앞에만 앉아 있을 수는 없다. 미팅도 해야 하고, 클라이언트도 만나야 하고, 친구들과 잡답도 해야 하고, 커피를 마시느라 들락거리기도 해야 하고, 개인적인 용무도 봐야 한다.
이런저런 시간을 다 빼고 나면 손끝에서 코드를 뽑아낼 수 있는 물리적인 시간의 최대치는 5시간을 넘지 않는다. 그 5시간만 제대로 집중해서 코드를 만들어내면 그날 내가 할 수 있는 일은 모두 한 셈이다. 그나마 여기에서 5시간은 실제로 코딩을 하는 시간이 아니라 차분하게 컴퓨터 앞에 앉아 있을 수 있는 시간을 의미한다.
그럼 6시에 퇴근하는 대신 밤 11시까지 책상에 앉아 있으면 (즉, 야근을 하면) 코드를 뽑아낼 수 있는 시간이 5시간에서 10시간으로 늘어나는 것이 아닐까. 생산성이 두 배로 늘어나는 것이 아닐까. 바로 이것이 프로그래밍의 본질을 이해하지 못하는 책상물림들의 셈법이다.

기계적으로 키보드를 두드리는 ‘타자’와 코드를 짜는 프로그래밍을 같은 일로 착각하는 것이다. 그러한 착각이 참이면 이런 식의 셈법도 성립한다. 하지만 프로그래밍은 ‘양’의 노동이 아니라 ‘질’의 노동이다. 손가락이 아니라 머리로 하는 일이다.
프로그래밍을 할 때 프로그래머의 두뇌는 CPU 레지스터와 메모리의 확장된 버전이 된다. 수많은 변수의 상태와 상호작용이 두뇌에 기억되고, 각종 클래스와 패키지 이름, 구현해야 하는 알고리즘 개요, 다른 하위시스템과의 상호작용, 방금 수정한 버그 내용, 사용자 요구사항 내용 등이 모두 기억된다.
1차원적인 기억의 문제가 아니다. 기억한 내용들이 서로 다차원적인 방식으로 상호작용하는 것을 실시간으로 파악하고 판단해야 한다. 엉망으로 꼬이고 엉킨 실타래의 끝을 놓치지 않고 추적하는 것이다. 열 개의 볼링핀을 저글링하는 서커스 단원처럼 한순간도 잡생각을 할 수 없는 고도의 집중력을 요구하는 일이다.
이런 수준의 집중력을 하루에 2~3 시간 이상 발휘할 수 있는 사람은 없다. 괴물 같은 사람이라도 5시간이 한계다. 사람에 따라서 하루 평균 2~3시간 발휘할 수 있는 집중력을 특정한 날에 몰아서 발휘하는 사람도 있다. 대신 그런 사람은 더 긴 휴식시간을 필요로 한다.
핵심은 지속가능한(sustainable) 양질의 집중력을 하루 평균 얼마나 발휘할 수 있느냐 하는 것이다. 매일 10시간씩 컴퓨터 앞에 앉아 있는다고 해서 10시간 내내 양질의 코드를 생산할 수 있는 것이 아니라는 이야기다.
사람이 사용할 수 있는 정신적인 에너지는 정해져 있다. 그날 쓸 분량을 다 쓰고 나면 당연히 회복할 시간이 필요하다. 책을 읽거나, 영화를 보거나, 연인과 데이트를 하거나, 친구와 잡담을 나누어야 한다. 충분한 수면을 취해야 하는 것은 물론이다.
에너지가 바닥난 사람을 컴퓨터 앞에 앉혀두면 그가 할 수 있는 일은 “잠자코 앉아있기”말고 아무 것도 없다. 키보드 위에서 영혼이 담기지 않은 손가락 놀림만 분주하다.
그래서 '코드를 짜기 위한 야근'이라는 표현은 '따뜻한 얼음'이나 '둥근 삼각형'처럼 형용모순이다. 말 자체가 성립하지 않는다. 에너지가 고갈된 상태에서는 정상적인 코드를 만들어내는 것이 불가능하다. 코드가 아니라 버그만 생산한다.
일하는 시늉만 무성하고 실제로 일은 아무 것도 이루어지지 않는다.
야근을 하면서 실제로 프로그래밍을 할 수 있는 경우는 낮에 집중력을 발휘할 만한 일을 아무것도 하지 않았을 경우로 국한된다.
이런 이유 때문에 익스트림 프로그래밍 진영에서는 오래 전부터 프로그래머가 일주일에 40시간 이상의 노동을 수행하지 말아야 한다고 주장해왔다. 프로그래머의 인권이나 노동권에 대해서 말하는 것이 아니다. 소프트웨어 프로젝트의 진정한 ‘성공’을 원한다면 프로그래머를 양계장의 닭처럼 쥐어짜는 것이 결코 도움이 되지 않는다는 사실을 깨달아야 한다고 말하고 있는 것이다.
생산성 하락도 문제지만, 정상적인 시간과 비용에 포함되지 않는 암시장이 형성되는 것도 큰 문제다. 프로젝트 관리자나 물주들이 프로그래머들의 ‘야근’을 당연한 것으로 여기면서 의존하기 때문에 프로젝트의 단가가 비정상적인 방식으로 산정된다.
이러한 암시장 효과로 인해서 프로젝트 일정이 주먹구구식으로 정해지고 프로젝트에 참여한 프로그래머들의 개인적인 삶이 담보로 저당 잡힌다. 이러한 악순환 속에서 소프트웨어의 ‘품질’을 찾는 것은 알래스카에 가서 야자나무를 찾는 것과 마찬가지다.
결론을 내려 보자. 그대가 프로그래머라면 하루에 2시간 이상 코드를 생산할 수 없다고 해서 조금도 자책하지 않기 바란다. 2시간 이상 코드를 만들어낼 수 있는 사람은 세상에 없다. 그대의 상사가 야근을 하라고 하면 어쩔 수 없이 야근을 하되 '시체처럼 앉아있기' 이상을 하려고 노력하지 마라. 그렇게 하지 않아도 된다.
열심히 야근을 하는 것처럼 보이는 세상의 다른 모든 프로그래머도 그대와 다르지 않다. 원래 다 그런 것이다.
그대가 프로그래머에게 일을 맡기는 사람이라면 (프로젝트 관리자든 아니면 프로젝트에 돈을 대는 물주든) 하루에 2시간 이상 코드를 생산할 수 있다고 말하는 사람을 진심으로 두려워하기 바란다. 시키지도 않았는데 기꺼이 야근을 하겠다고 말하는 사람을 호환마마보다 더 무서워하기 바란다.
그 사람은 프로그래머가 아니기 때문이다. 그는 좀비다. 언제 그대를 물어뜯을지 모르는 영혼 없는 존재다.
*본 칼럼 내용은 본지 편집방향과 다를 수 있습니다.


원본 :http://www.zdnet.co.kr/column/column_view.asp?artice_id=20140218180039&type=xml
2014/02/20 18:38 2014/02/20 18:38
Tags: ,

개발자는 소프트웨어 회사의 가장 중요한 자산이면서 서로 상반된 2가지 가치를 가지고 있다.

첫 번째는 ‘과거의 가치’이고
두 번째는 ‘미래의 가치’이다.

나는 과거의 개발자일까? 미래의 개발자일까? 스스로 판단하기는 어려울 것이다. 동료나 경영진에게 내가 퇴사를 하면 어떻게 될까?라는 질문을 해보면 짐작할 수 있다.

내가 퇴사를 하면 과거에 개발해 놓은 제품들을 어떻게 하지?라는 생각이 가장 먼저 들면 ‘과거의 개발자’에 가깝다.

반대로 내가 퇴사를 하면 과거에 개발해 놓은 제품들은 문제가 없는데 미래에 개발할 제품은 누가 개발하지?라는 생각이 들면 ‘미래의 개발자’라고 볼 수 있다.

회사나 개발자 입장에서 권장되는 개발자 타입은 미래 가치를 많이 지닌 “미래의 개발자”이다. 미래의 개발자가 지금은 가치가 적은데 미래에 가치가 높다는 의미가 아니다. 미래에 가치가 더 있고 시간이 흐를수록 점점 가치가 높아진다는 의미다.

과거의 가치를 더 많이 가지고 있는 ‘과거의 개발자’는 본인이 아니면 유지보수가 어렵게 소프트웨어를 개발해 놓았고, 대부분의 지식이 머리 속에 있기 때문에 동료나 신입개발자와 지식을 공유하기 어렵다. 본인이 의도해서 그렇게 한 것은 아니지만 결과적으로 자신이 과거에 만들어 놓은 소프트웨어를 인질삼아 회사와 인질극을 벌이고 있는 것과 같다.

물론 이런 개발자가 퇴사를 한다고 회사가 망하는 것은 아니지만 적게든 많게든 타격을 입게 되고 심한 경우 회사는 퇴락의 길을 걷기도 한다. 따라서 회사는 이런 개발자에게 질질 끌려 다니곤 한다. 이런 상태의 개발자는 스스로도 상황의 피해자일 뿐이다.

미래의 가치를 가진 ‘미래의 개발자’는 자신이 과거에 만들어 놓은 소프트웨어들은 후배들이 유지보수를 수월하게 할 수 있도록 개발 과정에서 적절히 문서화를 해 놓았고, 아키텍처를 깨끗하게 만들었으며 모든 이슈는 이슈관리시스템에 기록으로 남겨 놓았다. 그리고 Peer review를 통해서 이미 많은 지식을 동료들과 공유를 한 상태다.

이런 합리적인 개발 과정을 통해서 본인은 분석, 설계 능력이 꾸준히 향상되어 왔으며, 회사도 성장에 걸맞게 프로세스와 개발문화가 발전되어 왔다. 유지보수에 허덕이지 않으므로 신기술에 대한 연구에 소홀하지 않아서 미래에는 과거 제품들보다 한 단계 수준 높은 제품을 만들어 낼 것이다.

언뜻 보기에는 과거의 엄청난 폭풍 코딩을 통해서 짧은 시간에 많은 제품을 만들어내는 성과를 낸 ‘과거의 개발자’가 영웅처럼 보이지만 미래의 가치를 지닌 ‘미래의 개발자’가 진정한 영웅이다.

필자는 대기업부터 작은 소기업까지 여러 소프트웨어 회사를 다니면서 개발자와 경영진을 대상으로 소프트웨어 개발에 대해서 강연이나 세미나를 많이 한다. 그럴 때 이런 질문을 하곤 한다.

“오늘 회사를 그만둬도 당장 큰 문제가 발생하지 않는 사람 손들어 보세요”.
“오늘 회사를 그만두면 회사가 당장 큰 일 나는 사람 손들어 보세요”.

이 두 가지 질문 중에서 두 번째 질문에 손을 드는 사람이 상당히 많다. 특히 주변에 특정인을 가리키며 손을 들라고 하는 경우가 많다. 이런 사람은 십중팔구 ‘과거의 개발자’이다.

과거에 엄청나게 많은 일을 해냈지만 대부분은 유지보수에 치여 본인도 발전 못하고 격무에 시달리고 있는 경우이다. 수많은 문제와 이슈는 본인만 알고 있어서 수시로 불려 다니고 정작 본인은 개발할 시간이 없고 발전도 어렵다.

물론 ‘과거의 개발자’양산이 개발자에게 책임이 있는 것은 아니다. 소프트웨어 개발 환경이 회사에서 제공하는 프로세스, 시스템이 열악한 상태에서 전적으로 개발자의 내공에 의존을 하기 때문에 개발자도 어쩔 수 없이 ‘과거의 개발자’가 되어 버리는 것이다.

‘과거의 개발자’가 주도하는 회사는 엄청난 개발자 Risk를 안고 있는 것이다. 뛰어난 개발자가 많지만 이들이 한두 명만 나가도 회사가 휘청대며, 유지보수에 발목을 잡혀서 앞으로 나가기 어려운 상태인 경우가 많다.

회사는 개발자가 개발에 전념할 수 있고 개발 과정에서 꾸준히 성장할 수 있도록 환경을 제공해야 한다. 개발자 경력을 보장하는 것은 물론이고 프로세스와 기반시스템을 제대로 갖추고 개발문화 구축에 제도적인 노력해야 한다. 그렇게 해서 개발자 내공에 의존하는 개발이 아닌 시스템에 의존한 개발이 되어야 한다. 그런 환경에서야 개발자가 최고의 활약을 할 수 있다.

그래야 개발자도 행복하게 개발을 할 수 있고 회사도 개발자 Risk가 줄어든다. 이런 환경에서 성장하는 개발자는 신참때는 주로 코딩을 하지만 고참이 되어 갈수록 설계, 분석에 집중하고 문서를 통한 협업에 능숙해진다. 이런 방법이 개발자와 회사 모두에게 좋은 방법이다.

여전히 개발자의 내공에 의존한 개발 환경을 가진 회사에서 유지보수에 허덕인다고 개발자를 탓하지는 말자. 지금이라도 ‘미래의 개발자’를 위한 환경에 대해서 고민해보자.

책에도 다 있고 이론은 많지만 현실에서 실천이 어려운 것이다. 이론으로는 배울 수 없고 경험에 의해서 밖에 배울 수 없기 때문이다. 책과 이론은 약간의 도움을 줄 뿐이다.


원본 : http://techit.kr/14467


2012/12/26 09:49 2012/12/26 09:49
Tags: