jongfeel
commented
9 months ago 논의주제) 프로와 아마추어에 대한 논의는 아마 다른 분이 해주실 거라 믿고 다른 주제를 선택해 보려 합니다.
프로그래머가 하려는 것은 무엇인가? 라는 소주제를 가지고 방대한 분량을 연구 분석한 것 중에 프로그래머가 일을 잘 하는지 알아 보려면 적절한 수준으로 작업하고 있는지를 보면 된다고 했고 그 수준을 조절할 수 없으면 프로가 아니라고 했습니다.
다른 분들은 적절한 수준으로 작업하는지에 대한 판단을 어느 정도 하는지 얘기해 보면 좋겠습니다. 물론 판단은 선임/팀장/리더가 하고 작업만 하시는 분은 예외입니다.
7장 프로그래밍 작업의 다양성
어떤 행위를 더 깊이 설명하기 위해서는 더 가까이 뛰어 들어야 하고 이것이 프로그래밍에 관한 몇몇 미신적인 통념을 없애고 싶은 우리들이 해야 할 일이다.
프로그래밍의 프로와 아마추어
고등학생과 직업 프로그래머가 양 극단을 대표한다고 했을 때 이 양 극단은 다를 수도 혹은 같을 수도 있다.
그 차이는 분명한데, 아마 누가 그 프로그램을 사용할 것이냐에 있을 것이다. 자신이 사용할 것인지, 혹은 다른 누군가가 사용할 것인지. 프로도 자신이 사용할 프로그램을 만들기도 하지만 다른 사람이 그 프로그램을 사용할 경우를 대비한다. 즉, 다른 사람이 사용한다는 사실 하나가 프로그래머의 작업에 여러가지 영향을 미친다.
보통 문제를 단순하게 만들어 버리는 것은 문제를 정의하는 사람이 프로그램 자신일 경우밖에 없다. 프로는 자리에서 일어나 프로그램 수정을 허락하거나 요구 명세를 명확히 규정해 줄 다른 사람을 찾아가야 하기 때문이다.
프로는 프로그램을 잘 포장해서 냉혹한 세상으로 내보내야 한다. 그 후에는 자신에게 돌아오는 신랄한 비판에 따라 프로그램을 여러모로 수정해야 한다. 진정한 프로는 수정할 여지가 없을 만큼 완벽에 가깝게 만들겠지만, 이건 프로그래밍 전에 많은 고민을 해야 한다는 것과는 다른 문제다.
프로는 다른 사람을 위한 것이 아니더라도 작성한 프로그램에 대해 아마추어와 같이 깔끔하게 잊고 살 수 없다.
오늘날에는 아마추어가 하려는 작업을 대부분 시스템이 알아서 처리해주기 때문에 큰 격차가 생기고 있고, 그 격차는 점점 더 커지고 있다. 역설적이게도 그 격차가 커질수록 아마추어는 격차의 존재를 더욱 더 알지 못한다. 이유는 시스템이 어떤 일들을 자동으로 해주는지 점점 더 모르게 되기 때문이다.
시스템 설계자가 일을 더 잘 할수록 사용자에게 그의 존재는 점점 더 잊혀진다. 이는 관리자가 훌륭할수록 직원들이 그의 존재를 크게 의식하지 않게 되는 것과 같은 이치다.
관리자는 프로그래밍에 대해서는 아마추어이다. 그들은 강좌를 통해 프로그래밍 과제를 수행했고, 여러 방해가 있었지만 프로그램을 완성했다. 그리고 다음과 같이 생각했다. "우리도 정해진 시간 내에 프로그램을 다 만들었는데, 프로그래머들이 못할 이유는 뭐지? 우리가 일주일 만에 배울 수 있는 프로그래밍이 뭐가 어렵다는 걸까?"
이건 아마추어 자신이 프로와 별 차이 없다고 생각하는 것과 같은 종류의 착각인 것이다.
이런 배려는 프로그래머의 어려움을 경영진이 더 잘 이해할 수 있도록 하려는 의도와 달리 역효과를 낳고 말았다.
프로와 아마추어의 차이는 과거의 경험에 있다고 할 수 있다. 과거에 어떤 프로그램들을 만들어 봤는가뿐만 아니라 미래에 어떤 프로그램을 만들 것인가에도 큰 차이가 있다.
아마추어는 목적만 달성하는 프로그램의 결과를 얻을 뿐 어떻게든 만드는 데에 집중한다. 어려운 부분은 극복하는 게 중요하지 과정은 신경 쓰지 않는다.
그러나 프로는 눈 앞의 문제를 우회할 여러 가지 방법이 있으며 그 중 하나를 통해 급한 불을 끌 수도 있다. 그러나 그 일은 거기가 끝이 아니라 시작을 뿐이다. 자신이 왜 이해하지 못하는지를 이해해야만 하기 때문이다. 나중에 그 이해가 필요한 프로그램을 만들어야 할 때를 대비하는 것이다.
아마추어는 주어진 문제에 대해 배운다. 그리고 배운 것은 뽑낼 만한 장식이 될 수 있지만 발전의 장애가 되기도 한다. 프로는 자신의 직업에 대해 배운다. 지금 다루는 문제는 발전하는 과정의 한 단계일 뿐이다.
프로는 어떤 문제도 아마추어 만큼 심각하게 생각하지 않는다. 버그는 항상 있어왔기 때문이다. 이런 태도의 차이는 아마추어와 프로 간의 끊임 없는 마찰로 이어진다.
프로는 아마추어들이 잘못된 결과에 대해 여러 방면(컴퓨터, 운영자, 시스템, 천공기, 언어, 정부 등등)탓을 하는 것에 좋은 시선을 가지고 있지 않다. 아마추어는 프로들이 급한 상황인데도 너무 느긋해서 책임감이 없어 보인다고 여긴다.
프로그래머가 하려는 것이 무엇인가?
아마추어와 프로의 관계에는 불균형이 있다. 프로는 아마추어의 작품을 전문성이 떨어진다고 생각하지만, 이는 아마추어가 자신과 프로의 차이를 과소평가하는 것보다 더한 잘못이다. 진정한 프로는 아마추어보다 훨씬 잘 알아야 한다.
프로그램은 사람이 만드는 다른 모든 물건처럼 명확한 수명과 활용 범위를 염두해 두고 설계된다. 수백 년 동안 유지될 수 있을만큼 논리적인 방법으로 만든 장인의 작품처럼, 프로그램에는 과도하게 설계된 부분도 미진하게 설계된 부분도 있어서는 안 된다. 하지만 프로그래머는 가장 많은 작업을 요구하는 부분보다 가장 흥미로운 지적 도전을 질길 수 있는 부분에 더 많은 시간을 할애하는 직업병이 있다.
프로그램을 개발할 때는 그 용도에 따라 적절한 수준으로 노력을 기울여야 한다. 적절한 수준 이상으로 작업하는 것은 차라리 그 이하로 작업하는 것보다 더 프로답지 못하다. 프로그래머가 일을 잘하고 있는지 알려면 그가 주어진 문제에 대해 적절한 수준으로 작업하고 있는지를 보면 된다. 작업의 수준을 적절히 조절하지 못하는 사람은 프로가 되기에는 항상 실격이다.
프로그래머는 문제를 해결하고자 기울이는 노력 수준을 조정하는 데 보통 실패한다. 풀어야 할 문제가 무엇인지를 모르기 때문이다. 과거의 경험을 기반으로 현재의 문제를 가정하므로 일이 끝날 때까지 주어진 문제를 제대로 파악하지 못한다.
프로그래밍 목표를 어떻게 가정하느냐에 따라 성과가 얼마나 달라지는가를 알아보고자 작은 실험을 진행했다. 프로그래머 네 명에게 동일한 문제를 주고 문제 명세까지도 동일하게 줬다. 두 명과 나머지 두 명에게는 마지막에 다른 명세를 줬다.
프로그램을 가능한 바른 시일 안에 만들기를 지시받은 조는 다른 조에 비해 평균 2/5 컴퓨터 시간과 1/3의 개인 작업 시간을 사용했다. 그러나 만들어진 프로그램의 속도는 평균적으로 약 10배나 느렸다. (표 7-1의 인덱스 문제) 효율적인 프로그램을 요구받은 조의 프로그램의 속도가 다른 조에 비해 50% 더 빨랐다. (표 7-1의 파일 문제)
표 7-1 환경이 성과에 미치는 영향
위 실험은 문제 유형도 노력해서 향상시킬 수 있는 효율성의 정도에 영향을 끼친다는게 드러난다. 목표에 대한 인식 차이가 프로그래머가 어떤 일을 수행할 때에 행동 차이를 낳는다는 사실은 알 수 있다.
효율성을 추구하는 그룹이 더 많은 컴퓨터 시간과 개인 시간을 사용한 원인을 분석해 보면 빨리 완성하려는 그룹은 현재 방법이 맞지 않으면 버리고 다른 방법을 찾는데 비해 효율성을 추구하는 그룹은 어려움이 생겨도 접근 방법을 중간에 바꾸지 않는다. 그러면 효율성을 어느 정도 잃기 때문이다.
심리학적인 관점에서 보면 교훈은 명확하다. 동일한 객관적 사건이라고 해도 목표에 따라 프로젝트에 미치는 영향은 다르다. 따라서 프로그래머의 성과를 측정하거나 언어, 운영체제의 성능을 비교하려면 주어진 문제가 정확히 동일함이 보장되어야 한다.
실생활에서 두 그룹이 정확히 동일한 문제를 다루는 경우가 없으므로 한 그룹 내의 관리자와 프로그래머들이 전혀 다른 목표를 추구하고 있더라도 그 사실을 인지할 수 없을지도 모른다. 끊임없이 의사소통하여 목표를 공유하지 않는다면 일정이 지연되거나 프로그램의 속도가 느리거나 메모리를 많이 사용하는 등의 문제가 생긴다 해도 놀라지 말아야 한다.
하지만 목표를 아무리 잘 공유해도 어느 정도의 위험은 피할 수 없다. 목표가 추정에 영향을 주기 때문이다. 앞의 실험에서 목표가 성과에 미치는 영향을 발견한 후에 프로젝트 시작 전에 완료 시점까지 프로그램을 실행시켜 볼 횟수와 소요 기간을 각 프로그래머가 추정하도록 했다.
결과는 표 7-2와 같은데 빨리 완성하려는 그룹의 프로그래머는 상대적으로 훨씬 보수적인 추정치를 제시했다.
또 다른 흥미로운 결과는 목표를 명확히 수립할 때 두 가지 영향이 생긴다는 점이다. 프로그래머는 다른 목표를 희생해서라도 그 명확한 목표를 달성하려고 한다. 그리고 목표를 충족하기 위해 보수적으로 추정하게 된다.
목표 일정은 주어진 시간 자체에 영향을 준다는 것을 확인했다. 일이 주어진 시간을 다 채울 때까지 늘어날 수 있는 이유는 일정에 대한 다른 목표들의 상대적 중요성이 명확하지 않기 때문이다.
"프로그래밍 프로젝트는 제때에 끝날 수 없다"는 통념을 낳은 오해들을 불식시킬 수 있을 것이다.
프로그래밍 작업의 단계
"프로그래밍은 단일한 재능이 요구되는 단일한 작업이다" 라는 통념에 비해 프로는 요구 명세 수집에서 부터 최종 프로그램 납품에 이르는 과정 동안 다양한 재능이 필요한 다양한 작업을 해야 한다.
시스템 설계 업무에는 숲의 전체 모습을 놓치지 않는 시야가 필요하고 디버깅 업무에는 나무 하나하나를 자세히 살필 눈이 필요하다.
코딩을 할 때에는 쓸데없는 부분은 모두 없애야 하지만, 문서를 작성할 때에는 문단의 크기를 맞춰 때로는 간단한 문장도 늘려 써야 한다.
능력 있는 프로그래머가 관리자로는 실패할 수도 있는 것처럼, 훌륭한 설계자도 디버깅에는 서투를 수 있다.
적재적소에 필요한 재능을 투입하려면, 프로그래밍 작업을 단순히 프로그래밍이란 한마디로 싸잡을 것이 아니라 더 정밀하게 세분화해야 한다.
일반적으로 프로그래밍은 문제 정의, 분석, 흐름도 작성, 코딩, 테스트, 문서화로 이어지는 과정이 있는데 몇 가지 점에서 진실을 왜곡한다.
실제로 프로그래밍 프로젝트를 명확하게 정의된 단계로 나누는 것이 가능하다 할지라도 그다지 바람직하지는 않다. 업무마다 필요한 재능이 다르고, 프로젝트에 참여한 프로그래머들은 각자 다양한 종류의 재능을 가지고 있다. 작업을 여러 부분으로 분리하고 각 부분 작업을 해당 단계에서 동시에 수행하는 편이 좋을 수도 있다. 그러면 작업의 진척이 좀더 일정해지고 매일 변동될 프로그래밍 환경이나 프로그래머 컨디션에 영향을 덜 받을 것이기 때문이다.
이상적인 프로젝트에서는 모든 인력을 동시에 프로그래밍의 특정 단계로 몰아넣지 않아야 한다. 다행인 점은 각 단계의 구분이 실제로 그렇게 명확하지 않다는 점이다. 훌륭한 프로그래머는 어떤 작업에서 장애물에 맞닥뜨렸을 때 다른 작업으로 의식적이든 무의식적이든 전환한다. 일종의 경계 허물기를 한다.
프로그래밍이란 이름 아래 행해지는 작업이 지닌 다양성으로 인해 프로그래밍에 대한 심리학적 연구 결과에는 어느 정도 과정이 섞이게 된다. 집요하게 파고 들어야 하는 문제에 우월한 능력을 보이는 프로그래머가 있을 것인데 문제가 바뀌어 세부 사항보다는 전체 그림을 넓은 시각에서 바라보는 능력이 필요하다면 상황은 역전될지도 모른다. 이런 이유로 비슷한 연구인데도 결과가 30배가 차이나는 경우가 있다.
프로그래머들에게 규모가 큰 문제를 주면 극적이었던 차이는 줄어들게 된다. 문제의 규모가 크면 각 프로그래머가 잘하는 부분과 못하는 부분이 섞여 있을 것이기 때문이다.
30배라는 수치도 프로그램이 아닌 작업의 성격으로 프로젝트를 분리한다면 30배의 생산성 차이를 볼 수 있다. 비자아적 프로그래밍을 실천할 때의 결과가 이런 것임에 주목해야 한다. 프로그래머들이 프로그램을 소유한다면, 이런 잠재적인 생산성을 실현하지 못할 것이다.
버그를 찾는데 천재적인 사람들이 버그를 수정하는 임무에는 적절하지 않을 수도 있다. 이미 발견된 버그는 흥미를 끌지 못하기 때문이다. 버그를 프로그램에 적절한 방식으로 어느 정도 우아하게 수정하려면, 다른 특성을 지닌 프로그래머가 필요하다.
버그를 찾는 사람에게는 분석적인 사고력이 필요한 반면 버그를 수정하는 사람에게는 종합적인 사고력이 필요하다. 한 사람이 두 가지 일에 모두 뛰어날 수도 있지만, 그런 사람을 찾기 보다는 두 가지를 다 잘하는 팀을 찾는 편이 더 쉽다. 각 팀원의 소질과 단점을 인정하는 감각과 겸손함을 갖췄다면, 그 팀의 능력은 팀원 각자의 능력을 능가할 것이다.
요약
프로그래밍은 획일적인 한 덩어리의 행위가 아니다. 프로그래머 자신도 새 프로그램을 만들 때마다 다른 일을 하고 있다는 사실을 자주 잊는다.
프로그래밍에 관한 논의를 활성화시키려면 논의의 수준을 낮출 수밖에 없다. "무엇이 좋은 프로그래머를 만드는가?"란 주제에서 결론을 얻으려면 논의되는 내용보다 더 세부적인 면까지 고려해야 한다. 좋은 프로그래머를 만드는 요소가 훌륭한 우정을 만드는 요소와 비슷하다는 사실을 발견할 수 있는데 그건 상호 관심과 개성 존중이다.
질문
관리자에게
프로그래머에게
가장 잘하는 일 외의 다른 두 가지에 대한 약점을 극복하려고 당신은 어떤 노력을 하는가?
참고문헌
로젠은 컴퓨터 소프트웨어 분야의 중요한 고전적 논문을 모아 주석을 달았다. 신입은 이 모음집을 통해 자기 직업이 현재 모습을 하게 된 이유를 알 수 있게 될 것이다.
사멧은 크든 작든 모든 성과를 동일한 패턴에 담아 역사를 느끼게 해주려 했다. 두 가지 접근 방법으로 첫재, 모든 성과에 패턴을 부여하려는 시도로 프로그래밍 작업이 다양하고 복잡하다는 걸 보여준다. 둘재, 로젠처럼 가장 성공적이었던 성과만을 모아두면 어려움이 없었다는 인상을 주기 쉽기 때문에 사멧은 소프트웨어 개발 역사에 존재하는 수많은 시도와 실패를 매우 잘 포착해 냈다.
두 책은 프로그래밍 프로젝트 관리에 대한 대표적인 교본들이다. 메츠거의 책은 프로그래밍 프로젝트 관리에 대한 IBM의 내부 강좌에서 사용된 교재였고, 그 주제를 다룬 최초의 교본 중 하나이다. 렛츠의 책은 같은 주제에 대해 American Management Association이 펴냈다. 두 책에는 관리자의 격려 연설과 같은 유용한 정보가 많다.
내과의학적 관점에서 개인별 특성을 다룬 책으로, 모든 프로그래머가 다 똑같아 보이는 환상에 시달리는 사람들이 꼭 읽어야 할 책이다.
위의 책과 동일한 주제를 심리학적인 관점에서 다뤘다.
7장에 보태는 글: 프로그래밍 작업의 다양성
"프로그래밍은 획일적인 한 덩어리의 행위가 아니다(262쪽)." 오늘날 프로그래밍 작업의 다양성은 누가 봐도 명확하다.
프로그래머가 요청 받은 일은 무엇이든 할 수 있다는 실험 결과를 토대로 명확한 요구 명세를 개발하고 의사소통을 잘 하는 일에 시간을 투자하면 소득이 크리라 생각했고 이 주제에 관심을 가졌던 여러 조직이 많은 이득을 얻었다. (물론 이것이 프로그래머는 시키면 무슨 일이든 다 할 수 있음을 의미하지는 않는다)