[인생여행:독서] 프로그래밍의 심리학 The Psychology of Computer Programming

프로그래밍의 심리학 

The Psychology of Computer Programming

written by Gerald M. Weinbreg in 1971

1969년에 이탈리아에서 8주간의 휴가를 보내던 중에 영감이 떠올라 초안을 썼다.

어떤 출판사도 출판해주지 않다가 한회사를 만났는데, 이 책을 선택했던 그 당시 출판사의 편집자는 컴퓨터 서적 분야에 대한 이해가 부족하다고 해고당했다.

크게 4부로 이루어져 있다.

• 1부 인간 행위로 보는 프로그래밍
• 2부 사회 활동으로 보는 프로그래밍
• 3부 개인 행위로 보는 프로그래밍
• 4부 프로그래밍 도구

1부 인간 행위로 보는 프로그래밍

1장 : 프로그램 읽기

프로그램을 읽으면서 볼 수 있는, 또는 읽음으로써 찾을 수 있는 기계의 한계, 언어의 한계, 그리고 프로그래머의 한계. 어떤 프로그램이 현재의 모습을 갖게 된 데이는 다 이유가 있었다. 기계, 쓰여진 언어, 프로그래머의 무능 혹은 재능, 존재했던 외부 사건 등

라이브러리나 동료에게 프로그램을 구해서 코드 한 줄 한 줄 작성된 이유를 밝혀보라. 내가 작성한 프로그램도 마찬가지로.

프로그래머들은 자신의 코드를 다른 사람에게 검토해 달라고 요청하거나 다른 사람의 코드를 보며 자신의 능력을 키우는 것에 왜 그렇게 인색할까? 자칭 똑똑이들 보다 정말 유능한 프로그래머가 그런 일을 더 중요시해서, 항상 그렇듯 부익부 빈익빈 현상이 발생한다.

코드를 읽어 내려가면서 왜 이렇게 작성되어 있는지, 기계나 언어나, 사용하는 툴이나, 작성한 사람이나, 특정한 사건이 있었거나 하는 등등을 생각해 보는 습관을 가져야 겠다. 48년 전에 이런 책이 .. 역사의 위대함이란.

2장 : 좋은 프로그램이란 무엇인가?

좋은 프로그램이란 무엇인가라는 물음은 간단하지 않거니와 적절치도 않을 수 있다. 코드가 적게 쓰였다고 해서 좋은거야? 개발비용, 환경, 컴파일러, 기간 등 매우 많은 요소들이 존재. 종합적으로 판단해야 한다. 그 중 중요한 고려사항은 아래와 같다.

요구명세 : 프로그램이 주어진 요구 명세를 얼마나 만족시키느냐 즉, 얼마나 잘 작동하느냐가 문제인 것.

일정 : 출근버스 1분씩 기다리다 하루 26분 / 매일 10분씩 기다림 중 후자를 선호, 평균 기다림 시간은 후자가 4분이나 더 걸리는데..

적응성 : 환경이 변하면 그에 맞춰 프로그램을 수정할 수 있는지, 유전자 시스템, 기교를 부려서 얻은 이득과 되돌아 오는데 걸리는 낭비, 현대의 추상화나 제내릭 같은 것인가보다

효율성 : 실행 시간만이 효율성이 아니다. 실행시간을 줄이기 위해 입력 데이터를 사용자가 직접 입력해야 한다면 그것은 반대로 사용자가 프로그램을 사용하는 시간이 증가한다.

자신의 썼던 글을 40년 뒤에 다시 보면서 아직까지 유효한 것들이 많아서 저자는 놀랐음 : 기술은 아닐지도 모르지만, 인간의 행동에는 좀처럼 변하지 않는 일관성이 있는 것 같다.

프로그램은 수 없이 많은 요소로 인해 평가될 수 있다. 각각의 상황에 따라 다르다. 내 프로그래밍 경력에서 여러가지 판단을 내리게 될 텐데, 내가 어떤 상황에서도 적절한 평가를 할 수 있는 능력이 있다면? 그리고 저자가 40년후 자신의 글을 읽었을 때 인간 행동의 일관성을 보고 심리학을 공부하길 잘했다고 생각했을 듯, 적응성이 좋은 학문이네

3장 : 프로그래밍이란 행위를 연구할 방법은 무엇인가?

프로그래밍은 매우 복잡한 분야이므로 인간행동학에서 가능한 많은 연구결과를 차용함. 그 과정에서 함정에 빠질 우려가 있으므로 미리 대비함.

검증없이 내성법 사용 등..

아직 미숙한 분야에서 일어나는 최대 실수는 '지나친 신중함' 이다.  전혀 하지 않는 것보다 한 후에 실패하는 편이 낫다.

수년에 걸쳐 관찰하면서 최고의 프로그래머는 가장 introspective (자기 성찰적)인 사람이라는 걸 알게 됐다. 그들은 자신이 만들어 낸 오류를 발견하면 문제를 야기한 정신적, 물리적 과정을 검토한다.

프로그래밍은 나라는 인간이 하는 작업이기 때문에, 어떠한 실수나 버그가 있으면 내가 어떤 생각의 과정으로 그런 잘못을 야기했는지 생각해보자. 자기성찰적 프로그래머!

2부 사회 활동으로 보는 프로그래밍

그룹 : 같은 장소에서 일하는 프로그래머 집단, 엔지니어링 회사, 대학전산센터

팀 : 더 나은 제품을 만들기 위해 함께 일하는 프로그래머 모임.

프로젝트 : 그룹에 하나로 통합된 시스템을 만들어 내는 활동을 더한 것. 표준화, 문서화 등의 부차 기능을 담당하는 특별 팀들이 포함됨. 

그룹과 달리 팀에게는 항상 공통의 목표가 있다. 그것은 구성원들이 서로 가르치고 배워 각자 더 나은 능력을 가질 수 있도록 한다는 것이다. 제품과 상관없이 말이다.

4장 : 프로그래밍 그룹

비공식 조직을 이해해야 한다

• 게시판을 볼 수 있는 여비서의 전화와 전산센터 자판기 일화

물리적 환경은 작업공간의 배치를 의미하는데 이러한 환경이 사회적 상호작용에 미치는 영향은 매우 높더라. 

• 수동승강기를 자동승강기로 옮기자 비공식적 배달서비스를 제공하던 승강기 기사가 없어져서, 프로그래밍 작업 효율이 떨어지는 현상
• 디버깅 시간 15분을 위해 기다리던 대기실이 지식 공유의 장.

사회 심리학에 따르면 개인의 성격에는 여러 가지 유형이 있다고 한다. 3가지 차원으로 측정할 수 있다.

어떤 사람이 고분고분한가, 공격적인가, 고립적인가 이다. 

• 고분고분 : 다른 사람과 함께 일하고 도움이 되기를 좋아한다.
• 공격적 : 부와 특권을 얻기를 바란다.
• 고립적 : 창의성을 발휘할 수 있도록 홀로 일하길 바란다.

모든 사람에게는 이 3가지 성향이 모두 존재하지만, 대부분의 사람은 그 중 한 성향만 두드러지게 발현한다. 프로그래머는 대다수 고립적.

이게 뭐가 문젠데? 라고 묻는다면

어떤 프로그램을 흠모한다고 해서 그 프로그래머의 작품을 모방할 수는 없다. 왜냐면 읽지 않기 때문에. 단지  매너리즘^[각주:1]만 부추길 뿐이다.

이는 예술계에서 흔히 나타나는 현상

모두 어떤 화가처럼 보이는 방법은 알고 있는데, 그 화가처럼 그리는 방법을 아는 사람은 거의 없다.

고립성 -> 자기 프로그램에 지나친 애착을 가짐.

인간의 인지부조화^[각주:2] 심리

• 방금 포드 자동차 구입한 사람에게 여러 자동차 광고를 주면, 그 사람은 포드 자동차 광고만 보려고 하는 사례, 인지부조화에 빠질 가능성이 있는 정보를 일부로? 무의식적으로? 피하는 사례
• 자기 프로그램에 지나친 애착을 가진 프로그래머는 프로그램의 있는 모든 오류를 찾아내지 않을 것, 정확성만 증명하려 노력함. 
• 자신의 실수를 인정하지 않고 남탓을 하게 됨. 인지부조화에서 이러한 원일을 알 수 있음. 

자신의 작업을 스스로 검토하는 것이 적절치 않음을 알 수 있다.

그러므로

비 자아적 프로그래밍 (egoless pregramming)

자아의 문제는 사회적 환경과 더불어 프로그래머의 가치 체계를 재구성함으로 극복할 수 있다.

( 자아의 문제란 자기 스스로 자기 것을 평가할 때 발생하는 객관적이지 못한 문제와, 매너리즘에 빠질 수 있는 등 여러가지 문제. "나도 모르는 사이에 그렇게 생각해버리는" 심리적인 실수들. )

인간으로써 자신이 지닌 한계를 인식하는 능력

폰 노이만의 사례. 이 문제를 일찍이 깨닫고 자신의 한계를 인정한 사람.

우주 추적 시스템을 만들었던 빌의 사례. 컨디션이 좋지 않은 날의 코딩(13개의 기계어로 구성된 매우 작고 함축적인 코드 이었음)과 동료가 20개가 넘는 오류를 찾음

자신이 코드를 읽어야 하는 모든 사람을 위해 프로그램을 명확하고 이해하기 쉽게 만들려 노력하는 사례를 보고 => 비 자아적 프로그래밍의 이점이 오류를 찾는데만 있는게 아니구나.

그리고 경험적으로 비 자아적 프로그래밍을 실천하는 그룹의 능력수준은 특별한 교육 없이도 저절로 높아진다.

내가 속한 그룹이나 환경이 얼마나 중요한 영향을 미치는지 생각해 보게된다. 좋은 팀을 선택할 수 있는 영감이 될 것.

5장 : 프로그래밍 팀

혼자 일하는 게 아닐때 기술적인 요구사항의 충돌이 대인 관계의 갈등으로 번질 가능성이 있으며, 이를 현명하게 해결하기 위해 사회적인 장치를 갖추어야 한다는 생각에서 출발.

목적한 시스템을 개발하는 데 필요한 최소의 전문 기술과 최소의 시간이 있다.

그러나 이 수치들은 정확히 정의하기 어려울 뿐 아니라 프로그래밍에서 '추정' 은 항상 불확실성이 개입되기 때문에

관리자는 상식적으로 봤을 때 계획된 시간 내에 주어진 업무를 절대 수행할 수 없는 팀을 구성하곤 한다. 

이런 팀은 마감 시한이 닥쳐 현실을 직시해야만 하는 상황이 되어서야 일정 연기를 요청한다.

최단 일정은 오로지 최고의 팀을 프로젝트에 투입할 때에만 달성 가능하며, 팀의 인원을 최소로 투입하려면 프로젝트 일정이 늦어짐을 각오해야 한다.

이 말은 프로그래밍 기술이 다소 부족하더라도 일정을 연기해 줄 여유가 있고 능력이 최저 수준 이하만 아니라면, 어떤 프로그램이든 만들 수 있다.

일정에 관해서 ( 이지만.. 비단 프로그래밍 분야만이 아닌듯... )

• 파킨슨의 법칙^[각주:3]을 주의해야 한다.
• 주어진 시간을 다 채울 때까지 작업을 지연시킨다. ( 심리적인 요인에 영향을 더 많이 받는 파킨슨의 법칙 )

• 최고로 낙관적인 상황만을 가정하지 않는다.
• 관리자들이 기한을 최단시간으로 설정하는데 이러한 원인이 있다. 낙관적인 상황만 가정하고 기한을 잡기 때문. 이런 상상에 빠져들지 말자.

일정의 착오가 생겨 팀에 인력을 충원하는 등의 인력충원이 일어나면, 작업을 더 많은 사람이 분담할 수록 전체 작업의 통합이 더 어려워진다는 점을 고려해야 한다.  즉, 작업을 통합하는데 소요되는 시간때문에 충원한 인력 수 만큼 작업의 효율이 정비례하진 않음. ( 파킨슨의 법칙과 연관성이 있다. )

그 충원을 위한 프로그래머들을 조직하는데 걸리는 시간도 생각하면 효율은 더 떨어짐.

=>

프로그래밍 팀의 크기와 구성에 대해 언제나 통용되는 기본 원칙은 

최소의 비용으로 최고의 프로그래밍을 원한다면, 가능한 한 최고의 프로그래머들을 구하고 그들에게 최소한의 인원으로도 문제가 없을 만큼의 충분한 시간을 주어야 한다.

현재 최고의 생상성을 내는 팀이 장기적으로도 그러하려면

당장은 팀에 거의 아무 도움이 못 될지라도 상대적으로 미숙한 프로그래머를 한 명 이상 포함시키는 것이 좋다. 그런 팀은 목표가 하나 이상이다. 즉 생산과 훈련이라는 두 가지 목표. 

사회심리학자들은 이를 증명했다.

한 명 이상의 구성원이 그룹의 목표를 공유하지 못하면 단지 그 구성원 한 사람의 문제로 끝나지 않는다.

그룹 내의 분열이 일어나거나, 일부 동료의 무관심한 태도를 피부로 느낄 수밖에 없기 때문에 업무 능률이 떨어지게 된다는 것.

이 경우가 프로그래밍 분야에서 극단적인 사례로 나타남. IBM 7명 각각 할당된 프로그램 부분, 1명이 팀의 결정을 받아들이지 않았고 자기만의 입출력 루틴 작성, 후에 큰 오류가 생김. 찾기도 어려움. => 이루지 못한 합의가 시간이 한참 지난 후에 피할 수 없는 혹독한 대가.

한 회사 내에 어떤 그룹이 본분을 충실히 이행하고 있는지 평가할 만한 능력을 지닌 사람이 없다면, 본래 목표를 벗어나 헤매는 문제를 해결하고 바로잡을 방법이 없다.  시스템 프로그래머들이 쓸떼없는 것을 작업을 계속하고, 시간낭비하고 정작 필요한 것들을 하지 못했던 사례에서..

사회과학자들이 말하는 리더쉽이란 사람들에게 영향을 주는 능력.

민주적인 팀이 위기 상황에 잘 대처한다는 사실.

관리자들은 인정하지 않고 그 증거로 중앙 집권적으로 조직된 집단이 리더 한 사람을 중심으로 모였을 때 얼마나 빠르고 결단력 있게 행동하는지.

리더가 그 상황에 딱 맞는 사람인 경우엔 그것이 옳다. 히틀러나 박정희 처럼.. 히틀러라는 한 인간이 그 상황에 가장 완벽하게 어울리는 인물인 것.

하지만 항상  그 상황에 적절한 리더를 찾을 수 있을까 하는 측면에서 보면, 어떤 팀도 완벽하게 민주적일 순 없다. 여러가지 문제들이 있다. 외부로부터 리더가 온다던지, 인성문제가 있다던지...등등

근시안적인 리더는 경영진이 요구하는 바를 무엇이든 해내겠다고 약속하는 것이 그들을 기쁘게 하기 위한 최고의 방법이라고 생각할지도 모르지만

궁극적으로 경영자는 제대로 지켜지는 약속을 원하고( 당장의 기쁨을 원하는 것이 아님. ), 리더가 팀원들이 그 약속을 목표로 인정하게 만들어야만 지킬 수 있다.

• 경영자가 약속 이행을 아무리 강하고 요구한다 해도, 진정으로 원하는 것은 결과물 자체다.

리더가 자신의 판단에 더 큰 확신이 있으며 리더 자리를 잃는다 해도 먹고 사는데 아무 지장이 없음을 알고 있으면 그의 힘은 몇 배나 더 강할 것.

자신의 전문성을 의심하는 리더는 덧 없는 약속들 (보너스) 가운데 감춰진 온갖 종류의 위협에 쉽게 무너지고 말 것.

기초를 탄탄히 공부해야 하는 이유. 확신이 생긴다는 것.

헤럴드의 사례. "자 이제 결정을 내리세요. 내가 문제를 이해하는 유일한 사람이라면, 당신들은 내 식으로 해야하는 겁니다. 그게 아니라면 당신들은 아무 거리낌없이 날 자르고 다른 사람을 고용할 수 있겠죠. 이건 내 문제가 아니라 당신들 문제입니다. 그러니 괜찮으시다면, 전 그만 일하러 가 봐야겠습니다."

리더쉽이 지닌 역설중 하나. 언제든 물러날 준비가 되어 있는 리더 만이 진정한 성공이 열쇠를 쥐고 있다. ( 리더쉽 뿐만이 아니다. 인생에도 적용되는 문제 )

기술도 얻기 힘든 요소지만, 친화력보다는 기술 쪽이 사거나 훈련시키기에 쉽다. 기존 팀들의 친화의 중요성. 기술 때문에 기존 팀의 친화력 깨는 위험성..

지금 당장 드는 생각은 역시나 심리적인 것들은 프로그래밍에 국한되는게 아니라는 것. 프로그래밍 때문에 알게된다기 보다, 원래 알고 있던건데 프로그래밍에도 적용이 되네? 이런 식이다.

그리고 프로그래밍 영역에서 좋은 팀이 얼마나 중요한지, 좋은 리더나 관리자가 왜 필요한지 생각해보게 된다.

6장 : 프로그래밍 프로젝트

이전 장 읽다보니, 지금 필요한 주제가 아니다. 넘긴다.

3부 개인 행위로 보는 프로그래밍

프로와 아마추어의 차이.

프로그래머가 되면 실패할 확률이 높은 사람

• 스트레스가 많은 상황을 어느 정도 견딜 수 있는 능력? (외부에서 업무와 일정이 주어지는 직업 프로그래머)
• 프로그래밍 업무가 매우 다양하기 때문에 잦은 변화에 잘 적응하지 못하는 성격
• 겸손 ( 몇 가지 간단한 기술을 익히고 스스로 전문가라고 자만하다가 그로서는 어쩔 수 없는 컴퓨터의 힘 앞에 박살나는 비극 )
• 자신감
• 유머감각 ( 컴퓨터는 자신 앞에 앉은 사람을 모두 바보로 만드는 기계이다. -> 웃어 넘길수 있어야 한다는 의미인듯. ) 

자신감과 겸손함 비유 적절

겸손함이 지나쳐 자기비하를 쉽게 하는 사람은 자신이 택한 방법이 틀릴 수도 있다는 비판 정신을 지나치게 발휘해 자신감을 상실한다.

물론, 비판정신이 없는 자신감은 브레이크 없는 기관차 만큼이나 위험하다.

하지만 자신감 없는 비판 정신은 기관차는 없고 브레이크만 있는 형국.. 사고의 위험은 없겠지만 뭔가를 이루는 것 더더욱 없다.

다른 사람이 작성한 프로그램을 많이 디버깅해 본 사람은 그 문제에 대한 원작자의 설명을 새겨듣지 말아야 한다. 그 설명을 너무 믿으면 디버깅에 실패하게 만든 원작자의 잘못된 가정들을 자신도 받아들이게 되기 때문. 

이건 심리적 차원에서 받아들여야. 프로그래밍 만의 문제가 아니다.

동기부여의 중요성

동기 부여가 되지 않은 사람을 가르치기가 얼마나 힘들지 상상해 보라. 

반대로 스스로 동기가 있는 사람이라면 배우는 것을 막을 도리가 없다.

동기부여  -> 양 많아지면 -> 부담, 압력

동기부여를 더 해야할지, 조금 줄여야 할지 생각

훈련을 선행하지 않은 교육은 불가능하다.

운영체제의 개념을 제대로 배우려면 컴퓨터 사용 경험이 필수이고, JCL 문법을 다루는 능력이 필수이다. 따라서 JCL 문법을 훈련시키는 데 실패하면 운영체제 개념을 가르치는 데로 실패. 

알파벳을 훈련한 후에 영어 교육을 받아야 함을 의미하는 듯.

의미가 없어보일 지라도 기초라고 하는 것들을 훈련해야 함.

새로운 것에 대한 두려움과 실패에 대한 걱정, 자신의 약점을 인정하고 싶지 않은 마음은 모두 학습에 직접 악영향을 미친다.

기술의 확장성

기술을 처음 배울 때 적용했던 상황 외의 다른 상황에서도 쉽게 적용할 수 있는가의 문제. 일반론적인 기술 하나를 배우는 것은 지식의 목록에 한 항목이 추가되는 것 이상의 효과

스위프트는 그러한 종류의 언어인가?

*/ 내게 필요한

경험한다고 반드시 뭔가를 배우는 것은 아니다.

프로그래머가 자신이 경험한 것을 배움으로 발전 시키려면, 학습하는 방법 을 배워야 한다. ( 경험한 것 -> 학습 -> 배움  => 학습하는 방법을 배워야 배움을 얻을 수 있네.. 내가 간과하고 있던 것임. )

뭔가를 학습하는 방법을 배우는 첫 단계는

 자신이 무엇을 알고 있고 무엇을 모르는지를 배우는 것이다. ("너 자신을 알라") 

독학하는 사람은 수업을 듣는 학생보다 유리한 점은 학습 내용을 자신의 필요에 꼭 맞도록 조절할 수 있다는 점.

근거 

사람은 각기 다른 성향을 가지고 있고 학습도 마찬가지. 

어떤이는 시각적으로, 어떤이는 청각으로 더 잘 이해함. 어떤이는 직접 해보면서 익힘,

또 어떤 클래스는 수준이 높음, 어떤이는 수준이 너무 낮음

학교에서는 학생 개인에 맞춰 지도가 불가능 하므로 획일화 함. 하지만 독학은 자동으로 개인별 집중을 받는것이나 마찬가지

문제는 독학하는 사람이 그것을 잘 활용할 수 있느냐에 있다.

두 학생이 25 - 16 라는 답으로 각각 19, 41 을 제출했다고 하자. 정답은 9 이기 때문에 두 개 모두 틀린 답으로 처리되고 바보취급을 당할 것. 

독학을 할 때는 각각의 답에 포함된 추가 정보를 모두 사용해야 한다. 

예로 어떤 프로그램을 작성하고 실행했는데 정확하게 동작하지 않을 경우, 그 프로그램의 출력에는 수 많은 정보가 들어있다. 

대부분의 프로그래머는 그 정보를 눈여겨보지 않고 그저 프로그램이 잘못됐다는 정보로만 받아들인다.

출력이 정확하다면 두 번 생각할 것 없이 프로그램을 손에서 놓아 버린다.

학습은 능동적인 추구다. 프로그래밍을 학습할 때 능동적으로 배움을 추구해야 하는 경우는 두 가지 있다. 프로그램이 정확하게 동작할 때와 그렇지 않을 때다. 

프로그램이 정확하게 동작할 떄는 3보 정도 뒤로 물러서서 달성한 성과를 전체적으로 관조해야 한다. 

- 다른 프로그램에서는 문제가 많았는데 이 프로그램은 왜 성공했을까?

- 왜 전에는 문제가 많았던 걸까?

- 처음부터 다시 시작한다면 더 쉽게 혹은 더 효율적으로 작성할 수 있을까?

- 만약 그러하다면 지금 당장 실행할 수 있는 일은 무엇일까?

프로젝트가 끝낫을 때 프로그래머에게 하루쯤 휴가를 주는 것이 좋다. 프로그래머에게 프로젝트의 결과를 스스로 평가할 기회를 주는 것.

프로그램이 정확히 동작하지 않으면 더 많은 배울 기회가 생긴다.

*/

컴퓨터 프로그래밍 훈련에 대한 당신의 개인적인 역사를 기록해보라.

어떤 경험에서 무엇을 배웠고 어떤 것에서 가장 많은 배움을 얻었는지.

작성한 내용을 바탕으로 미래의 학습 계획을 세워보라.

내가 생각을 하는 뇌에 대해 신경쓰기 시작한다. 이것이 이책의 가장 큰 득. 

---

1. 항상 틀에 박힌 일정한 방식이나 태도를 취함으로써 신선미와 독창성을 잃는 일 [본문으로]
2. 기존에 가지고 있던 것과 반대되는 새로운 정보를 접했을 때 개인이 받는 정신적 스트레스나 불편한 경험 [본문으로]
3. 공무원의 수는 업무량과는 직접적인 관계 없이 심리적 요인에 의하여 꾸준히 증가한다는 이론이다. [본문으로]