3장 개인 행위로 보는 프로그래밍 #208
Comments
5 tasks
This was referenced Feb 1, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3부 개인 행위로 보는 프로그래밍
앞 장의 내용에서 프로그래밍 성과가 프로그래머마다 차이가 나는 원인으로 대부분 사회적인 요인에 기인한 것으로 설명했다. 그러나 대부분을 사회적 요인으로 돌린다 하더라도 여전히 남는 부분이 있다. 두 프로그래밍 구조가 아무리 비슷하더라도 최종 결과물은 다를 것이다. 이 차이를 개인에 관련된 여러 요인으로 설명한다.
실험을 수행하는 심리학자는 제일 먼저 모든 실험대상에게 같은 임무를 주었는지를 자문해야 한다. 아무리 잘 통제된 실험일지라도 실험대상에게 주어진 입무에는 많은 차이가 있기 마련이다. 또한 의미있는 결론을 얻기 위해선 임무의 차이를 먼저 찾아야 한다. 프로그래밍 입무는 여러 가지 측면에서 서로 매우 다르다. 따라서 제일 먼저 살펴볼 부분은 프로그래밍 임무 간의 차이다.
실험의 목적에 따라 달라지는데, 대상간의 개인차를 측정함이 목표라면 모든 실험 환경을 동일하게 만들어 환경이 유발하는 차이를 막아야 한다. (앞서 환경의 차이가 주는 내용을 학습했다.) 온도, 파티션등 실험 대상의 측정 목적에 영향을 줄 수 있는 모든 환경은 통일해야 한다.
반대로 측정하고자 하는 것이 온도나 환경에 의한 것이라면 그에 대한 차이를 제외한 나머지 요소를 똑같이 조성해야 한다.(업무, 시간 등등)
3부에서는 심리학자가 말하는 이런 개인차를 몇 가지로 나누어 다룬다. 두 사람에게 동일한 환경과 임무를 준다면 각 개인이 보이는 행동의 차이는 이요인들에 의해 나타난다고 간주하는 것이다. 따라서 우리가 관심을 가져아 할 개인차는 크게 개성, 지능, 훈련 또는 경험으로 분류할 수 있다.
물론 모든 것이 환경적인 요인에 의해 결정되는 것은 아니지만, 환경적인 요소에 따라 달라지는 내용이 많기 때문에, 이를 조심해야 한다. (총균쇠)
7장 프로그래밍 작업의 다양성
프로그래밍이란 단어는 무수히 많은 행위를 포괄한다. 단순하게 고등학생이 코드를 적는것 과 작업 프로그래머가 특수 목적의 온라인 컴퓨터를 위해 될수록 용량이 적은 프로그램을 개발하려 노력하는 것도 역시 프로그래밍이다.
프로그래밍의 프로와 아마추어
위에서 다룬 고등학생과 프로 프로그래머의 프로그래머 스펙트럼의 양 극단을 대표한다고 하자. 이 양 극단은 다를 수도 혹은 같을 수도 있다. 그러나 프로가 아마추어보다 프로그래밍에 대해 더 많이 공부하고 실습했음은 분명하다. (차이가 없는 경우도 존재하지만 대부분의 경우 차이가 존재한다.)
가장 큰 차이는 누가 그 프로그램을 사용할 것이냐에 있을 것이다. 아마추어는 자신만이 사용할 요량으로 프로그램을 만든다. 그러나 프로는 다른 누군가가 사용할 프로그램을 만든다. 물론, 프로도 자신만 쓸 프로그램을 만들기도 한다.
이 차이는 실제로 다른 사람이 그 프로그램을 사용할 때 나타나며, 다른 사람이 실제로 사용한다는 점이 프로그래머 작업에 여러가지 영향을 미친다.
아마추어는 문제를 단순하게 만들어 버리거나 정의하는 사람이 본인일 수 밖에 없다. 프로는 자리에서 일어나 프로그램 수정을 허락하거나 요구 명세를 명확히 규정해 줄 다른 사람을 찾아가야 하기 때문이다.
심지어 프로그램 개발을 마친 후의 일은 더 간단하다. 아마추어는 그냥 잊어버리면 끝인 반면에, 프로는 프로그램을 잘 포장하여 냉혹한 세상으로 내보내야 한다. 그 후에는 자신에게 돌아오는 신랄한 비판에 따라 프로그램을 여러모로 수정해야 한다.
아마추어는 주어진 문제에 대해 배운다. 그리고 그가 배운 것은 뽐낼 만한 장식이 될 수도 있고 발전의 장애가 될 수도 있다. 반면에, 프로는 자신의 직업에 대해 배운다. 지금 다루는 문제는 그가 발전하는 과정의 한 단계일 뿐이다.
또한, 프로는 어떤 문제도 아마추어만큼 심각하게 생각하지 않는다. 그에게는 항상 버그가 있었고 앞으로도 그럴 것이기 때문이다. 이런 태도의 차이는 프로와 아마추어 간의 끊임없는 마찰로 이어진다.
프로그래머가 하려는 것이 무엇인가?
아마추어와 프로의 관계에는 불균형이 있다. 아마추어는 프로가 직면하는 복잡성을 이해할 수 없기 때문이다. 그런데 프로도 아마추어의 작품을 전문성이 떨어진다고 비웃는 우를 자주 범한다. (매우 위험) 이는 아마추어가 자신과 프로의 차이를 과소평가하는 것보다 더한 잘못이다.
프로는 아마추어보다 훨씬 잘 알아야 한다. 아마추어는 우아한 에러 처리 루틴을 만들지 못할 수도 있다. 어떻게 만드는지 혹은 에러 처리 루틴이 무엇인지조차 모를 수 있다. 그러나 그에게 필요하지도 않은데 꼭 알아야 하는가? 아마추어가 그런 걸 모르는 것보다는, 프로가 개인적인 용도로 만든 작은 프로그램을 마치 수천 명의 사람이 5 내지 10년 동안 사용할 운영체제인 듯 대하려 하는 쪽이 더 나쁘다.
개인적인 경험으로도 당장 필요하지 않은 기술, 내용을 학습한 것에 대해서는 정말 도움이 되지 않은 것 같다.
프로그램은 사람이 만드는 다른 모든 물건처럼 명확한 수명과 활용 범위를 염두에 두고 설계된다. 수백 년 동안 유지될 수 있을 만큼 논리적인 방법으로 만든 장인의 작품처럼, 프로그램에는 과도하게 설계된 부분도 미진하게 설계된 부분도 있어서는 안 된다.
실제로 환경이 성과에 미치는 영향을 알아보기 위해 실험을 통해 알아본다.
효율성을 추구하는 그룹은 더 많은 컴퓨터 시간과 개인 시간을 사용한 원인은 예기치 않은 어려움에 부딪혔을 때 대처하는 방식의 차이가 큰 요인임을 발견했다. 빨리 완성하려는 그룹은 현재의 수단이 동작하지 않으면 버리고 다른 수단을 찾는다. 그러나 효율성을 추구하는 그룹은 어려움이 생겨도 접근 방법을 바꾸려고 하지 않는다.
따라서 양 그룹의 두 프로그래머가 처음에는 같은 접근 방법을 머릿속에 그리고 있었다 할지라도, 빨리 완성하는 것이 목표인 프로그래머는 전혀 다른 방법으로 끝을 맺는다.
실제 어려움의 원인이 결과와 다소 관계가 없다는 점도 중요하다. 예를 들어 컴파일러의 어떤 버그로 인해 여러 접근법 중 한 가지를 못 쓰는 상황이라고 하자. 그런 상황에서 빨리 완성하는 것이 목표인 그룹은 문제가 컴파일러 버그로 판명나기도 전에 이미 그 접근법을 포기한다. 반면에 효율성을 추구하는 그룹은 그 문제를 끝까지 파헤쳐 어쩔 수 없음을 알게 될 때까지 포기하지 않는다.
심리학 관점에서는 동일한 객관적 사건이라 할지라도 프로젝트의 목표에 따라 사건이 프로젝트에 미치는 영향은 다르다. 따라서 프로그래머의 성과를 측정하거나 언어, 운영체제의 성능을 비교하려면 주어진 문제가 정확히 동일함이 보장되어야 한다.
물론, 실생활에서 두 그룹이 정확히 동일한 문제를 동시에 다루고 있는 경우는 없다고 할 수 있다. 따라서 한 그룹 내의 관리자와 프로그래머들이 전혀 다른 목표를 추구하고 있더라도 그 사실을 인지할 수 없을지도 모른다. 결론적으로, 끊임없이 의사소통하여 목표를 공유하지 않는다면 일정이 지연된다거나 프로그램의 속도가 느리거나 메모리를 많이 사용하는 등의 문제가 생긴다 해도 놀라지 말아야 한다.
그러나 인생은 그렇게 간단하지 않다. 목표를 아무리 잘 공유해도 어느 정도의 위험은 피할 수 없다. 목표가 추정에 영향을 주기 때문이다. 앞의 실험에서 우리는 목표가 성과에 미치는 영향을 발견한 다시 확인한 결과로 알 수 있다.
최대한 빨리 완성하기를 요구 받은 프로그래머들이 상대적으로 훨씬 보수적인 추정치를 제시했다. 그리고 자신의 추정보다 더 나은 성과를 보였고, 효율적인 프로그램을 요구 받은 쪽과 비교해서도 더 나았다.(낙관적인 것을 제외해도)
신기하게 빠른 완성을 요구 받은 팀은 시간 추정을 거부하는 반응을 보였다.
여기서 목표를 명확하게 수립하면 생기는 두 가지 영향을 잘 알아봐야 하는데, 첫 째는 프로그래머는 다른 목표를 희생해서라도 그 명확한 목표를 달성하려 한다. 두번 째는 그 목표를 얼마나 잘 충족시킬지를 훨씬 더 보수적으로 추정한다.(또는 정확하게) 강조되지 않은 목표에 대해 프로그래머가 제시한 추정치는 믿을 게 못 된다.
이러한 실험의 결과가 일반적임을 증명한다면, 파킨슨의 법칙이 주는 의혹을 해소할 수 있고 동시에 수많은 관리자들을 악몽에서 구원할 수 있을 것이다. 파킨슨이 "일은 주어진 시간을 다 채울 때까지 늘어난다"고 말한 덕분에 우리는 목표 일정의 존재가 업무 능률에 영향을 준다는 걸 알게 됐다.
그러나 이제 우리는 목표 일정이 주어진 시간 자체에 영향을 준다는 것을 확인했다. 일이 주어진 시간을 다 채울 때까지 늘어날 수 있는 이유는 일정에 대한 다른 목표들의 상대적 중요성이 명확하지 않기 때문이다. 이런 식으로 사유해 나가면 "프로그래밍 프로젝트는 제때에 끝날 수 없다"는 통념을 낳은 오해들을 불식시킬 수 있을 것이다.
프로그래밍 작업의 단계
이번에는 또 다른 오해, "프로그래밍은 단일한 재능이 요구되는 단일한 작업이다"라는 통념에 대해서 알아보자.
적어도 프로는, 요구 명세 수집에서부터 최종 프로그램 납품에 이르는 과정 동안에 다양한 재능이 필요한 다양한 작업을 해야 한다.
적절하게 조직된 프로젝트에서는 프로그램 개발의 전 과정에 필요한 모든 재능을 모든 프로그래머에게 요구하지 않는다. 개인의 능력에 맞춰 업무를 할당하기 때문이다. 실제로 프로그래밍 작업의 한 단계에 적합한 어떤 재능이 다른 단계에서는 결점이 되기도 한다.
능력 있는 프로그래머가 관리자로는 실패할 수도 있는 것처럼, 훌륭한 설계자도 디버깅에는 서투를 수 있다. 반면에 디버깅에 큰 도움이 되는 사람이 설계 작업 동안에는 필요 없거나, 심지어 방해가 되는 어떤 재능으로 인해 프로젝트에서 제외될 수도 있다.
앞서 말한 때에 따라 팀장이 바껴야 하는 이유
적재잭소에 필요한 재능을 투입하려면, 프로그래밍 작업을 단순히 프로그래밍이란 한마디로 싸잡을 것이 아니라 더 정밀하게 세분화해야 한다.
일반적으로 프로그래밍은 문제 정의와 분석, 흐름도 작성, 코딩, 테스트, 문서화로 이어지는 일련의 과정으로 묘사된다. 이런 개략적인 관점에도 일말의 진실이 있기는 하지만, 몇 가지 점에서 진실을 왜곡한다.
우선, 작업의 순서가 그렇게 고정되어 있지는 않다. 예를 들어, 문서화가 테스트나 코딩, 흐름도 작성, 때로는 분석보다도 앞설 수 있다. 둘째, 기존 프로그램을 새로운 플랫폼이나 언어로 포팅하는 경우에서 보듯이 모든 단계가 항상 필요하지는 않다. 셋째, 각 과정을 꼭 일차원적으로 진행할 필요는 없다.
프로그래밍을 심리학적인 관점에서 연구하려면 이런 복잡한 행위들을 좀 더 간단한 단위로 분해해야 한다. 그러나 프로그래밍 과정은 순환적(또는 반복적)이므로 앞서 제시한 분류도 지나치게 정제한 것이다. 각 범주의 경계가 모호하거나 심지어 아예 구별되지 않기 때문이다.
실제로 프로그래밍 프로젝트를 명확하게 정의된 단계로 나누는 것이 가능하다 할지라도 그다지 바람직하지는 않다. 업무마다 필요한 재능이 다르고, 프로젝트에 참여한 프로그래머들은 각자 다양한 종류의 재능을 가지고 있다. 한 시기에 한 종류의 작업만 진행한다면, 그 외의 다른 재능들은 한동안 썩히는 셈이 된다.
따라서 작업을 여러 부분으로 분리하고, 각 부분 작업을 해당 단계에서 동시에 수행하는 편이 좋을 수 있다. 이렇게 하면 작업의 진척이 좀더 일정해지고 매일 변동될 프로그래밍 환경이나 프로그래머 컨디션에 영향을 덜 받을 것이기 때문이다.
예를 들어, 코딩이 매일 잘 되지는 않는다. 코딩을 하던 중에 일이 잘 풀리지 않음을 느낀다면, 코딩을 잠시 접어 두고 다른 종류의 기술과 마음가짐을 요하는 다른 작업에 눈을 돌리는 게 좋다. 그러나 그 시각에 해야 할 작업이 코딩뿐이라면, 일은 하면서 코딩에서 벗어날 방법이 없다.
실제로 작업하다 너무 하기 싫다면 문서화나 리팩터링을 통해 환기하는 것도 좋은 방법이라고 생각한다.
이 외에도 외부환경의 변화에 따른 작업의 단일화, 특정 단계의 고정으로 인한 과부화 등등의 단점이 존재하기에 이상적인 프로젝트는 반드시 인력을 동시에 몰아넣지 않아야 한다.
그러나 관리 메뉴얼을 문자 그대로 믿는 관리자는 이와 정확히 반대로 행동한다.
프로그래밍이란 이름 아래 행해지는 작업이 지닌 다양성으로 인해 프로그래밍에 대한 심리학적 연구 결과에는 어느 정도 과정이 섞이게 된다. 작은 프로그램을 개발하는 프로젝트의 성과를 실험하는 경우, 결과는 특정 작업 단계의 성과에 좌우된다.
프로그래머가 하는 작업들을 제대로 세분화해보면 전통적인 구분 간의 경계에는 분명 모호함이 있으나, 세분화해 보는 일 자체도 어느 정도 의미가 있다. 예를 들어 테스트 단계를 본다면 테스트라는 이름에는 적어도 세 가지 다른 행위가 포함되어 있음을 알 수 있다.
아주 넓은 의미에서, 이 세 가지 행위가 요구하는 기술과 개인 성격은 서로 다르다.
버그를 찾으려면, 완벽해 보이는 부분도 의심스럽게 바라보며 결점을 찾으려는 자세가 필요하다.
반면에, 버그의 발생 위치를 추적하려면 수도자의 끈기?와 동물적인 수집 본능?이 필요하다. 이런 추적하는 과정을 잘하는 사람이 존재할 수 있다.
하지만 버그를 잘 찾는 사람이 꼭 버그를 잘 수정하는 것은 아니다. (적절하지 않을 수 있다.) 버그를 프로그램에 적절한 방식으로 어느 정도 우아하게 수정하려면, 다른 특성을 지닌 프로그래머가 필요하다. 적응형과 균형감각...
정리하자면 버그를 찾는 사람은 분석적인 사고력이 필요한 반면, 수정하는 사람은 종합적인 사고력이 필요하다. 물론 한 사람이 두 가지 일에 모두 뛰어날 수도 있다. 그러나 그런 사람을 찾기 보다는 두 가지를 다 잘하는 팀을 찾는 편이 더 쉽다.
각 팀원의 소질과 단점을 인정하는 감각과 겸손함을 갖췄다면, 그 팀의 능력은 팀원 각자의 능력을 능가할 테니 말이다.
요약
프로그래밍은 획일적인 한 덩어리의 행위가 아니다. 소프트웨어 설계자들은 아마추어보다 프로가 더 다양한 도구를 필요로 한다는 사실을 자주 잊는다.
관리자들은 프로그래밍 작업의 단계가 명확하게 구분되지 않을 뿐더러 각 단계가 순차적으로 수행되지도 않는다는 점을 자주 잊는다.
프로그래밍의 다양한 성격 때문에 소프트웨어 설계자의 관리자, 프로그래머의 업무가 혼란스럽고 복잡해진다. 앞에서 좋은 프로그램에 대한 절대적인 정의를 내릴 수 없었듯이, 좋은 프로그래머나 좋은 관리자도 한마디로 규정할 수 없다. 심지어 좋은 소프트웨어를 정의하는 일도 쉽지 않다.
결과적으로, 프로그래밍에 관한 논의를 활성화시키려면 논의의 수준을 낮출 수밖에 없다. "무엇이 좋은 프로그래머를 만드는가?"란 주제에서 일반적으로 적용할 수 있는 결론을 얻으려면, 보통 논의되는 내용보다 훨씬 더 세부적인 면까지 고려해야 한다.
그리고 아마도 좋은 프로그래머를 만드는 요소가 훌륭한 우정을 만드는 요소와 비슷하다는 사실을 발견하게 될 것이다.
바로, 상호 관심과 개성 존중이다.
오래된 고전 책이라 업무에 있어서 시대차이를 느끼지만, 인간관계나 프로그래머의 본질적인 특성은 시대를 벗어나 획일적이라 느낀다.
논의사항
8장 개인의 성격
어떤 의미에서, 성격은 사람들 사이에서 볼 수 있는 모든 개인차를 포괄하는 개념이다. 인간의 행동을 조금만 관찰해도, 지능과 교육 정도에 따라 성격의 차이가 생김을 명백히 알 수 있다. 이때의 성격은 어떤 사람을 다른 사람과 구별해 주는 개인적 특성을 총체적으로 일컫는다. 이런 의미에서 성격은 그 사람의 정체성이다.
미치광이 파괴자
프로그래밍 초보인 기술자는 프로그래밍 교육 과정을 수강하도록 조치해 문제를 해결할 수 있지만, 전문가에게 교육은 답이 될 수 없었다. 그에겐 프로그래밍의 모든 면을 정복했다는 절대적인 자부심이 있었기 때문에, 교육을 받거나 다른 사람의 조언을 들을려고 하지 않았다.
변하는 성격
성격을 보편적으로 정의할 수 없지만, 성격이 프로그래밍에 끼치는 영향을 연구할 때 다음의 정의를 기반으로 할 수 있다.
성격이 고정적이지 않다는 점에 대해서 좀 더 부가적인 설명을 하자면, 분명히 성격은 잘 변하지 않는다. 그럴만한 이유가 없다면 성격은 변하지 않는다.
불행히도 성격이 바뀐 원인을 밝히는 것은 어렵다. 상냥했던 사람이 퉁명스러워졌다고 항상 치과에 가 보라고 할 수는 없다. 같은 양상을 보이는 성격 변화라도 원인은 다양할 수 있다. 육체적인 원인일 수도 있고, 심지어 완전히 외부적인 원인일 수도 있다.
개인의 성격에 관련된 문제가 생겼을 때 진짜 원인을 이해하지 않고서는 적절히 해결할 수 없다. 심리학적 지식이 그런 문제의 원인을 찾는 데 도움이 될 수는 있지만, 아무리 심리학에 정통해도 문제의 당사자가 입을 열지 않고서는 처방을 내릴 수 없다.
변하지 않는 성격
성격이 주변 환경의 변화에 적응하는 과정에서 변하는 것이라면, 성격의 변화를 그 사람이 속한 환경의 변화에 대한 신호로 볼 수 있다. 그러나 성격의 변화는 크든 작든 자주 있는 일이 아니다. 따라서 긴 안목으로 볼 때 더 관심을 가져야 할 부분은 프로그래머의 불변적인 성격이 그 직업 생활에 미치는 영향이다.
성격을 바라보는 일반적인 관점에 따르면, 성격은 그 사람이 가진 특질의 집합으로 볼 수 있다. 우리는 "이 사람은 보수적이고 착실하며 약삭빠르고, 저 사람은 숫기는 없지만 재치가 있다."는 식으로 성격을 묘사한다.
그러나 좋은 프로그램을 정의하기 어렵듯이 상황에 따라 너무 다양하기에 정의할 수 있는 최선은 프로그래머의 특정 특질과 특정 프로그래밍 업무의 관계를 밝히는 것이다.
의심이 많은잘 믿는위 내용과 같이 성격에 따라 모순적인 상황이 나오기 때문에 모든 조건은 절대 같을 수 없다. 모순적인 상황을 얼마나 잘 참을 수 있느냐는 그 사람이 정서적으로 얼마나 안정되어 있으냐에 따라 다르다.
그 기간에 따라서 다른데 관리자가 업무 과제를 자주 바꿔 주면 테스트 담당자에게 필요한 엄격한 성격 조건을 완화해도 괜찮다. 비자아적 프로그래밍에서는 이런 업무 교대가 자동으로 이뤄진다. 아무도 자신의 특정 성격 때문에 무자비한 공격을 받지 않아도 되기 때문이다.
비자아적 프로그래밍에서 항상 자신의 성격에 최고로 잘 맞는 업무에만 투입될 가능성이 없다. 안정성을 위해 잠재적인 능률을 희생하는 셈이다. 그러나 잠재된 능률을 모두 잃는 것은 아니다. 처음부터 각자의 성격에 상관없이 아무렇게나 배치하지는 않기 때문이다. 그리고 다른 사람의 신발을 신어 보는 것은 참을성을 기르는 좋은 방법이다.
실제로 사람을 그 성격에 가장 잘 맞게 배치하려는 시도는 실패하기 쉽다. 성격은 표면적으로 보이는 부분이 다가 아니기 때문에 겉으로는 똑같아 보이는 성격도 내면은 다를 수 있다. (대부분은 다를 것이라 생각한다.)
우호적인 사람은 완전히 마음을 놓고 있는 편안한 상태임을 나타내는 것일 수도 있지만, 반대로 불안한 상황에 처해 자신의 인상을 좋게 하려고 노력하기 때문에 그런 성격으로 보이는 것일 수도 있다.
따라서 사람의 성격을 파악할 때에는 표면을 관찰하는 것에 그칠 게 아니라 어느 정도 내면을 추론하기도 해야 한다.
이런 성격을 추론하는 능력도 대부분 경험적인 스킬로 쌓아진다고 생각한다.
프로그래머에게 꼭 필요한 성격
성격을 측정하는 것은 어렵다. 그리고 특정 작업과 성격을 연결 짓기란 거의 불가능하다. 그렇다고 프로그래밍에 적합한 성격을 가진 사람을 고르는 방법이 전혀 없을까?
프로그래밍 업무를 수행하는 데 프로그래머의 성격이 중요한 요소라면, 포기할 수 없는 문제다. 일반적인 경우는 힘들겠지만, 극단적인 경우를 놓고 보면 뭔가 의미 있는 결론을 얻을 수 있을 것이다.
성격과 프로그래밍의 본질적인 관계는 복잡 미묘하여 한마디로 말하기 힘들지만, 어떤 프로그래밍 실패로 이어지는지에 대해서는 몇 가지 단언할 수 있다.
프로그래밍은 지능보다 성격이 더 중요하다고 단언할 수 있다. (인성평가가 있는 이유?)
누군가 프로그래머로 크게 성장할지도 모르는데 조건만 따져서 아예 기회를 주지 않는 것은 잘못된 일이다. 그러나 지능이 평균 이하인 사람이 프로그래머기 되는 것을 막는 효과는 있다. 따라서 어느정도 평가를 통해 막는 효과를 볼 수 있다. (가장 기본이 되는 코테)
그러나 그와 비슷하게 지원한 사람의 성격을 근거로 사람을 뽑는 절차가 있는가? 하지만 성격은 변하기 때문에 결과가 일정하지는 않을 것이다.
이러한 사항들에 대해 심리학자들이 말하는 것 중 정말로 믿을 만한 부분은 지능이 성격보다 환경의 변화에 덜 반응한다는 것이다.
성격검사
융통성 없는 성격은 이상적인 프로그래머에게 적합하지 않다. 어떤 사람은 프로그래머가 정밀한 기계를 다뤄야 하므로 그 성격이 완고해야 한다고 믿는 것 같다. 하지만 실상은 컴퓨터가 융통성이 떨어지기 때문에 프로그래머는 오히려 융통성 있는 사고를 해야 한다.
실생활에 필요한 기능을 컴퓨터상에 구현하려면 프로그래머가 주입한 유연성이 필요한 것이다. 이러한 잘못된 세간의 믿음을 바로잡기 위해 프로그래머를 위한 성격검사법이 있으면 좋을 것 같지만 그것이 과연 가능할까?
현대의 대부분은 성격 장애를 찾아내는 데 목적을 둔다. (로르샤흐) 과연 모든 직업에서 지원자에게 정신병검사를 받도록 하는 행위가 과연 옳은가?
실제 기업에서도 어느정도 필요하다고 생각하지만, 직업의 귀천을 따지기 보다 잘 할 수 있는 수준으로 제한하는 게 좋다고 생각하긴 한다.
각 프로그래머의 유형에 따라 흥미 패턴이 있다 하더라도 이것은 해당 영역에 이미 종사하고 있는 사람들을 대상으로 조사한 결과일 뿐이고, 그 직업에 종사하기를 원하는 사람들을 조사한 결과가 아니다.
그러나 프로그래머라는 직업은 아직 걸음마 단계에 있다. 게다가, 고용자들이 평균적으로 자신이 채용한 프로그래머에 대해 만족하지 못하고 있다는 것은 어느정도 확실하다. 이런 상횡에서 현재의 프로그래머들을 미래의 프로그래머가 만족시켜야 할 모범 답안으로 살아야 하는가?
성격검사의 또 다른 문제는 피검사자가 속임수를 쓸 수 있다는 점이다. 성격검사를 비롯한 모든 심리검사는 검사를 고안한 심리학자가 검사를 받을 사람보다 똑똑하다는 가정을 전제한다. 만약 심리학 검사를 업으로 삼는 사람들을 대상으로 성격검사를 하면, 대체로 자신이 다른 사람보다 똑똑하다고 생각한다는 결과가 나올 것이다. 그러나 그들 스스로 그렇게 믿는다고 해서 사실이 되는 것은 아니다.
물론 심리학자들은 속임수의 가능성을 부정하거나 그 중요성 또는 빈도를 평가 절하할 것이다. 그러나 프로그래머들은 성격검사를 받을 때 실제로 속임수를 쓴다.
프로그래머에 대한 성격검사
앞에서 밝힌 성격검사의 문제점들은 염두에 두고, 프로그래머를 대상으로 실시한 성격검사의 결과를 살펴보면 다음과 같다.
요약
프로그래밍 업무는 매우 복잡하기 때문에 프로그래머로 성공하기 위한 요소 중 성격의 중요성이 보통 생각하는 것보다 훨씬 크다.
그러나 성격검사로 오떤 사람이 좋은 프로그래머가 될지 판별할 수는 없다. 그러기엔 검사법에 결함이 있을 뿐 아니라 프로그래밍 자체에 대한 우리의 이해도 깊지 않다.
너무 다양한 요건을 요구함.
하지만 특정 프로그래밍 업무에 필수적인 성격 요소를 추려낼 수는 있어 보인다. 어떤 성격의 소유자가 어떤 업무를 잘 하지 못할 것임을 알아내는 차원에서는 말이다.
결과적으로, 성격이라는 주제를 연구하면 프로그래머의 능률을 높이는 데 어느 정도 공헌하게 될 것이다.
논의사항
9장 지능 또는 문제해결력
겪어봐서 알겠지만, 프로그래머는 평균 이상의 지능을 가진 사람들이다.
과거에는 그럴 수 있을 수 있지만, 현대에는 그렇게 생각하지 않는다. 오히려 더 낮을 수 있다고 생각한다.
심리적 자세
잘못된 곳을 찾을 때에는 심리적 자세가 방해가 되기도 한다. 수많은 연구를 거쳐 사람의 눈은 기대한 면만 보는 경향이 있음이 증명됐다. (보고싶은 것만 본다.)
컴퓨터 프로그램에서 다양한 오류를 찾아낸다. 문법 오류나 잘못된 예약어, 잘못 선언된 상수 등은 간단하게 찾을 수 있고, 심벌 테이블이나 상호 참조 목록, 제어 흐름 분석은 상호 검증이 필요하다.
심리적 자세 외에 거리라는 개념도 염두에 둬야 한다. 어떤 단어를 다른 옳은 단어로 오인할 확률은 거리감으로 인해 단어마다 다르다. 읽은 사람이 지닌 심리적 자세와 관계없이 말이다.
그러나 프로그래밍 언어의 심벌에 대해서 거리를 그렇게 간단한 척도로 재면 어떤 심벌을 다른 것으로 오인할 확률에 대한 근사값밖에 얻을 수 없다.
자연어로 의미가 있는 심벌은 프로그램을 읽을 때 혼란스럽게 만들 여지가 특히 많다. 그 이유는 다음과 같다.
심리적 자세가 야기한 문제를 논할 때에는 주석문 예기가 빠질 수 없다. 코드에 주석을 다는 목적은 읽는 이가 코드를 직접 보기 전에 적당한 마음의 준비를 하게 만들려는 것이다.
그 코드가 정확하게 구현되어 있다면, 주석문은 확실히 효과가 있다. 그러나 코드가 부정확하다면, 읽는 사람의 심리적 자세가 주석문의 지배를 당하기 때문에 오류를 찾아내는 데 오히려 방해가 된다.
문제 해결의 여러 측면들
심리학에서는 심리적 자세를 지능보다는 인지의 일부로 본다. 그러나 앞절에서 봤듯이 심리적 자세가 문제 해결 행위에 영향을 줄 수 있음이 분명하다.
물론 심리적 자세는 문제 해결에 앞서 문제를 회피하는 데 영향을 준다. 문제를 모두 피하는 프로그래머가 문제를 안고 전전긍긍하는 프로그래머보다 지능적이다. 그 문제를 궁극적으로 해결하든 못하든 간에 말이다.
그러나 현실은 객관적인 척도가 부족하기에 프로그램 난이도를 판단할 때 담당 프로그래머가 얼마나 열심히 일 하느냐를 기준으로 삼곤 한다. 그 기준에 따르면 능력이 가장 떨어지는 프로그래머가 최고가 된다. 능력이 떨어지면 열심히 일하는 수밖에 없기 때문이다.
가장 문제가 되는 경우가 문제 회피다. 물론 뭘 모르는 관리자를 속이려는 의도의 문제 회피는 그렇지 않지만?? 어떤 행위가 문제 해결에 얼마나 도움이 될지를 알기 어려운 것처럼, 우리가 얼마나 많은 어려운 문제를 회피하고 있는가도 알기 어렵다.
일단 문제를 해결하고 나면 그 전까지 겪었던 어려움은 완전히 잊기 쉽다. 문제 해결을 어렵게 만드는 가장 일반적인 원인 중 하나가 일부 요소를 간과하는 것인데, 일단 어떤 요소가 중요함을 깨닫고 나면 해결은 간단해진다.
만약 그 문제를 다른 사람에게 설명한다면 그 요소도 함께 설명할 터이고, 설명을 들은 사람은 앚은 자리에서 문제의 9할을 해결할 수 있을 것이다. 그는 우리가 왜 그렇게 어려워했는지를 이해할 수 없을 것이다. 마찬가지로 우리도 자신의 능력을 의심하게 된다.
심리적 자세도 일종의 가정하기다. 가정이 좀 더 깊이 묻혀 있는 경우이기는 하지만, 문제 해결에 영향을 미치는 것은 마찬가지다. 그렇다면 문제 해결의 첫 번째 원칙이 가정하지 않는 것이라고 할 수 있는가?
이는 맞는 말이면서 완전히 틀린 말일 수 있다. 문제를 성공적으로 해결하려면 가정을 하지 않을 수 없다. 모든 문제를 해결할 때마다 무에서 시작해야 한다면 문제 해결 능력이 향상되기는 불가능할 것이다.
가정을 전혀 하지 않기보다 주어진 문제에 맞춰 적절히 가정하는 편이 더 지능적인 행위다. 즉, 지능적인 행위가 모든 문제를 해결하는 마법의 공식을 제시하는 것은 아니다. 그보다는 여러 공식을 갖춰 놓고 특정 공식에만 집착하지 않는 쪽이 지능적인 행위다.
프로그래밍을 위한 지능의 여러 측면
모든 종류의 지능적 행위에는 융통성이 필요하다. 정신적인 행위일지라도 몇몇 고정된 규칙으로만 수행된다면 지능적이라 할 수 없다. 그런 행위는 사람보다 기계가 수행하는 편이 낫다.
그러나 지능적 행위에서도 몇몇 고정된 규칙을 적용하는 것은 중요한 요소다. (약점을 덮을 만한 다른 방도가 없다면 다른 프로그래머와의 경쟁에서 불리하다.)
사람들은 저마다 다른 고유의 문제 해결 기법을 갖고 있다. 사람마다 잘 하는 것이 다르기 때문에 사람들은 각자 자기 능력의 강약에 맞는 해결 기법을 고르고 한다.
작업 환경에 따라 다른 형태의 지능적 행위를 취해야 하는 것과 마찬가지로 프로그래밍 단계에 따라 두각을 나타내는 프로그래머가 달라진다. (창의력과 선택 능력 중 어느 하나라도 부족한 프로그래머는 프로그램 설계 단계에서 능력을 발휘할 수 없다.)
적성 검사
현대에는 코딩테스트로 대체한다.
그러나 이것도 이론적인 추측일 뿐이다. 아직 적성 검사 결과의 유효성자체가 검증되지 않았다. 프로그래머에 대한 적성 검사는 적성 검사에서 높은 점수를 받은 사람들이 프로그래밍 교육기관에서 좋은 성적을 낸 학생들이었다는 연구 정도가 유효성을 입증할 근거가 될 뿐이다.
과연 코테에서 좋은 점수를 받는 사람이 책에서 말하는 좋은 개발자일까?
기본적인 커트라인인 경우로 생각하는 것이 좋아 보인다.
프로그래머를 대상으로 하는 적성 검사
상관성을 측정할 수 있지만, 그 수치가 과연 정확한가에 대한 생각
상관성에 관한 글
스스로 경험이 있다고 주장하는 프로그래머에게 왜 잠시 앉아 작은 프로그램을 작성하거나 멍세서를 읽은 후 구현 스케치를 해보라고 시키지 않는가? 이는 아마도 우리 스스로도 프로그램을 거의 읽어 보지 않으므로 실제로 발생할만한 상황이 아니라고 생각하기 때문일 것이다.
또는 경력자를 뽑을 때 지원자가 한 명뿐이더라도 그 사람이 운 좋게 능력 있는 사람이기를 막연히 바라고 있기 때문일 것이다. 지원자가 한 명뿐일지라도 당신의 아내감을 고르듯이 해야 한다.
요약
프로그래머를 고용하는 데 관계된 사람들은 좋은 프로그래머에게 필수인 자질이 무엇인지에 대해 저마다 의견이 있다.
어떤 프로그래머를 뽑느냐보다 어떻게 프로그래머를 양성할 것인가로 바뀐다.
즉, 좋은 프로그래머는 태어나는 것이 아니라 만들어진다. 따라서 우리는 프로그래머의 생산 즉, 훈련 과정에 관심을 가져야 한다.
논의사항
10장 동기 부여와 훈련, 경험
심리학에 따르면, 어떤 과제를 해결할 때의 능률은 과제가 무엇인가, 수행하는 사람이 그 과제를 얼마나 잘 이해하고 있는가와 함수 관계에 있다. 또 성격이나 지능과 같은 개인차에 의해 능률이 달라진다고 한다. 그러나 능률을 실질적으로 향상시키는 요인은 성격의 변화나 지능의 향상이 아니라 훈련과 경험에 있다.
심리학은 엄밀한 과학이 아니다.
다른 요인으로는 설명할 수 없는 그 불가사의한 부분은 동기부여의 몫이다. 심리학자들조차 동기 부여가 실제로 존재하는지 확신하지 못하고 있음에도, 여러 책에서 이 주제를 다루고 있다.
그러나 교육이나 훈련에 대한 논의를 진행하기 위해서는 동기 부여를 어설프게나마 짚고 넘어가야 한다. 이에는 두 가지가 이유가 있다. 첫째, 만약 동기 부여로밖에 설명할 수 없는 부분이 실재한다면 그 영역은 훈련이나 교육을 통해서 접근할 수 없는 곳일 것이다. 둘째, 동기 부여가 훈련이나 교육 자체에 지대한 영향을 미칠 수 있다.
동기 부여가 되지 않은 사람을 가르치기가 얼마나 힘들지 상상해 보라. 반대로 스스로 동기가 있는 사람이라면 배우는 것을 막을 도리가 없을지도 모른다.
동기 부여
다음은 한 표준적인 심리학 교과서에 수록된 동기에 대한 글의 첫머리다. 내가 지금까지 본 동기 부여에 대한 설명 중 최고라고 생각한다.
프로그래머는 일하는 도중에 잠깐씩 다른 생각을 할 수 있다는 사실을 굳이 확인할 필요는 없다. 그런데 관리자는 프로그래머의 능률이 떨어짐을 동기의 부족이라고 단정해 버리는 실수를 많이 범한다.
그래서 관리자는 부족한 내적 원동력을 보충할 외적 동력을 프로그래머에게 부여하려 한다. 사실 프로그래머에게 동기가 적어서라기보다는 너무 많아 문제인 상황에서도 말이다.
동기에 대한 연구 결과 중 가장 널리 알려지고 인정 받는 것은 동력을 높이면 처음에는 능률이 최대치까지 올라가지만 그 이상의 동력을 가하면 오히려 능률이 0까지 빠르게 떨어진다는 점이다.
특히 과제가 복잡할수록 이러한 능률의 급등락이 많이 나타난다. 이는 프로그래밍에 매우 중요한 의미가 있다.
예를 들어 버그 찾기에 너무 열중하는 것은 좋지 않으며 심지어 아무 일도 하지 않는 때보다 더 나쁠 수도 있다. 그동안 수많은 버그들이 프로그래머가 포기하고 중압감을 떨친 후에야 잡혔다. 프로그래머에게 빨리 버그를 없애라고 압박하는 것은 최악의 전략이다. 그러나 이것이 지금까지 가장 일반적인 전략이었다.
프로그래밍 관리자가 동기 부여에 대해 가장 먼저 품어야 할 의문은 프로그래머가 현재 얼마나 많이 동기 부여가 되어 있느냐다.(자신도 마찬가지) 그리고 그 답에 따라 동기를 더 부여해야 할지 또는 오히려 줄여야 할지를 결정해야 한다. (균형잡기)
지나치게 동기 부여가 되어 있는 상황이라면 프로그래밍 프로젝트가 압력을 못 이기고 침몰할 가능성이 높다.
개인의 처지에서는 아마도 방법이 없을 것이다. 스스로 그렇게 할 동기가 없는데 자신의 내적 원동력을 어떻게 바꿀 수 없기 때문이다. 그러나 실제로는 관리자와 비슷한 전략을 쓸 수 있다. 내적인 뭔가를 바꿀 기회를 만들기 위해 외부 환경을 바꾸는 것이다.
몇가지 실험을 통해 어떤 외적 요인들이 프로그래머에게 동기를 부여하는지를 알아본다.
가장 많이 선택한 항목은
급료 인상 또는 보너스였다. 그 뒤를 쫓는 2위는업무를 계획하는 데 관여한 정도였고,승진,과제의 질을 좀 더 높일 수 있는 추가 시간 부여가 공동 3위였다.최하위는
내 업무의 범위를 줄이는 것이었는데, 누구나 전체 계획에 좀 더 많이 관여하고 싶어한다는 사실에 비춰볼 때 이해할 수 있는 결과다.반대로 적은 선택을 받은 항목은
문서화, 복사 등등에 대한 보조 인력이었다. (지금은 완전히 대체 가능하다고 생각) 두 번째는높은 지위였는데, 이는승진이 많이 선택된 점을 볼 때 의아한 결과였다.그러나 이후의 또 다른 실험을 한 결과 사람들의 관념 속에는 승진이 새 직함을 얻는다기보다 급료 인상과 더 강하게 연결되어 있다는 사실이 밝혀졌다.
나머지 두 가지는
완료 목표일을 느슨하게 설정하는 것과완료 목표일을 정확하게 설정하는 것이었는데, 이들이 모두 하위권이라는 점은 뭔가 이상했다. 설문 조사를 실시할 당시는 응답자들이 진행하는 프로젝트의 데드라인이 6개월도 넘게 남아 있던 것이다. (즉, 환경적인 사항이 실험에 영향을 크게 준 것)이런 점이 동기를 연구하는 데 겪는 또 하나의 큰 어려움이다. 설문 조사를 통해 외적 요인들이 끼치는 실제 영향력을 밝혔다고 해도, 그것은 특정 시기의 특정 환경에서만 유효한 결과다.
돈은 저축과 급료가 늘고 갚을 빛이 점점 줄어들수록 그 중요성이 작아진다. 심지어 앞서 나온 일화와 같은 상황에서는 더 많은 돈으로 인해 직장을 떠날 수도 있다. (실제 스터디원들의 이야기도 동일했다.)
돈은 동기 부여에 대해 모호한 요인으로 볼 수 있다. (연구로 증명된 것이 없다.)
돈이 상징적인 의미를 주는 경우라면 그 프로그래머에게 동기를 부여하기 위해서는 추가 시간을 준다든가, 프로젝트를 계획하는 데 좀 더 많은 발언권을 준다는 식으로 볼 수 있다.
즉, 업무 자체가 프로그래머의 가장 큰 동기가 되어야 한다.
훈련과 수업, 교육
교육 과정에서 생기는 혼동은 크게 두 가지로 나뉘는데, 하나는 수업과 교육을 혼동하는 것이고, 다른 하나는 교육과 훈련을 혼동하는 것이다.
학습을 저해하는 요인들
의외로, 학습에 방해되는 요소가 있어서 배움에 실패하는 경우가 많다. 이때 의외라는 표현을 쓴 이유는 누군가를 가르칠 때 학습의 효과를 극대화하기 위한 각종 방책을 도입하는 것이 일반적이기 때문이다.
그런데 어린 아이가 학습하는 모습을 관찰해 보면, 그런 인공적인 환경 밖에서 훨씬 많은 것을 배운다는 사실을 알 수 있다. 우리가 원하는 형태로 아이가 학습하도록 조절하려면 의도적으로 벽을 만들고 문을 뚫어야 한다.
야생학습의 필요성.
우선 뭔가를 배우려면 알 만한 가치가 있는 것 중에서 아직 모르는 것이 존재한다는 사실을 인정해야 한다. 그런데 전문 프로그래머들은 그 사실을 인정하면 자신의 지위가 낮아진다고 여긴다. 진정한 프로라면 약점을 인정해도 잃을 것이 없음을 알고 있겠지만 말이다.
어떤 사람들은 약점을 가까스로 인정한다 해도 자신이 실패할 거라고 확신해 버리고 배우려 하지 않기도 한다. 그런 두려움은 자신감이 부족하기 때문이거나 비슷한 종류의 시도에서 실패한 경험이 있기 때문이다. 그러나 대부분 두려운 것은 실패 그 자체가 아니라 다른 사람들에게 자신이 실패하는 모습만 보이는 것이다.
어떤 경우에는, 그룹의 특성상 새로운 학습이 원천적으로 금지되고 이미 알고 있는 기술을 얼마나 잘 발휘하는지만 중요할 수 있다. 배우려면 실수에 관대해야 하는데, 관찰자가 존재할 때에는 그러기 어렵다. 따라서 작업자와 관찰자가 모두 잘 알고 있는 사안을 처리할 때 작업자는 늘 하던 방식을 택할 수밖에 없고, 결국 새로운 배움은 불가능하다.
다양한 프로그래밍 언어와 시스템에 대해서는 많은 논쟁이 있다. 그러나 배우기 쉬움과 사용하기 쉬움을 구별하여 다루는 논쟁은 거의 없다. 어떤 기능이 배우기 쉽다고 해서 사용하기에도 가장 쉽다는 법은 없다. 중요한 것은 기술의 확장성이다.
다시 말해, 그 기술을 처음 배울 때 적용했던 상황 외의 다른 상황에도 쉽게 적용할 수 있는가의 문제다. 일반론적인 기술을 하나 배우는 것은 지식의 목록에 한 항목이 추가되는 것 이상의 효과가 있다.
너무 특수해서 확장성이 전혀 없는 기술은 끝이 막힌 기술이라 할 수 있다.
프로그래밍에서 일정 규모의 문제들을 성공적으로 해결해 왔지만 그 규모를 넘어서는 문제는 제대로 해결하지 못하는 프로그래머를 심심치 않게 볼 수 있다.
그리고 반대의 경우도 꽤 있다. 규모가 큰 문제만 잘 해결하는 프로그래머도 있는 것이다.
어떤 끝이 막힌 기술 또는 프로그래밍 언어에 숙달된 프로그래머가 새로운 기술을 배우려면 잠시나마 현재 맛보는 만족감 중 일부를 버릴 각오를 해야 한다. 새 기술을 배우는 초기에는 시행착오가 많을 테고, 그럴 때마다 마치 예전의 초보자 시절로 돌아가는 듯한 느낌을 받을 것이다. 이런 상실에 대한 두려움은 새로운 프로그래밍 언어를 배울 때 특히 클 수 있다.
새로운 것에 대한 두려움과 실패에 대한 걱정, 자신의 약점을 인정하고 싶지 않은 마음에서도 마찬가지다. 그 외의 문제들은 간접적인 영향을 미치는데, 대부분 무엇을 배울지 또는 어떻게 배워야 할지를 잘못 이해해서 생기는 문제다.
프로그래밍 학습에는 대부분 교사가 없다. 교수 뿐만 아니라 학습에 필요한 필수인 요소들 또한 없다. 교과서도 참고서도 없으며, 소프트웨어를 실행할 하드웨어도 없다. 새 주제를 공부할 여유 시간도, 실제 상품에 적용할 신기술을 인증해 줄 권위자도 없고, 심지어 좀 더 경험이 많은 선배 프로그래머도 없다. 그런 요소가 없음으로 인해 학습은 지지부진해지고, 학습자는 첫 번째 고비에서 바로 포기하게 된다.
마찬가지로 대학에서도 나는 학문을 가르치는 것이 맞다고 생각하긴 한다. 대학에서 취업하는 방법을 가르친다고 한다면 학원과 다를 것이 없기 때문에 학문에 중점을 둬야한다고 생각한다.
학교는 배우는 곳, 직장은 일하는 곳이라는 생각은 꼭 프로그래밍 분야에 국한된 문제는 아니지만, 프로그래밍 분야는 어떤 분야와 비교해도 지속적인 학습이 중요한 분야이다. (천장이 없음)
프로그래밍을 학습하는 방법
스스로 발전하려 하는 프로그래머는 정식 훈련과 그가 필요한 교육을 받을 수 있도록 해주는 관리자의 배려에 의존하지 않을 수 없다. 순수하게 경험에만 의존하면 안 되는데, 경험한다고 반드시 뭔가를 배우는 것은 아니다.
프로그래머는 자신이 경험한 것을 배움으로 발전시키려면, 학습하는 방법을 배워야 한다. (야생학습)
요약
우리는 프로그래머의 성과를 향상시키는 데 두 가지 측면에서 영향력을 행사할 수 있다. 하나는 일을 하고 싶어하는 마음이고, 다른 하나는 업무를 수행하기 위해 필요한 지식이다.
전자를 동기부여, 후자를 훈련 또는 교육이라고 한다. 그러나 프로그래머가 어떤 상황에서 더 열심히 일하는지에 대해 알려진 바는 거의 없다.
앞 내용에서 언급했듯이 프로그래머는 매우 다양한 스킬을 요구하기 때문에 개개인의 목적이 다를 것이다. 돈, 직급, 명성, 자아실현 등등.. 그런 목표에 다가갈 수 있을 때, 더 열심히 하지않을까?
프로그래밍 교육이란 주제에 대해 현대는 어느정도로 달라졌는지 궁금하다. 개인적인 생각으론 과거와 다르게 많이 발전했다고 생각한다.
정규교육에서 벗어나지 못했다고 하는 부분도 시간이 몇십년이 지났지만 지금도 크게 달라진 것 같지는 않다.
논의사항
제가 이해한 바로는 처음부터 너무 큰 작업을 하려고 한다던가, 과도한 예측치 등등이 될 것 같습니다.
The text was updated successfully, but these errors were encountered: