1장 인간 행위로 보는 프로그래밍 #202
Comments
5 tasks
This was referenced Jan 11, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1부 인간 행위로 보는 프로그래밍
컴퓨터 프로그래밍은 인간의 행위다.
수년에 걸쳐 경영자들은 자신의 사업에서 프로그래머라는 요소를 배제하기 위해 막대한 자금을 솓아 부었다.
1장 프로그램 읽기
프로그래머로써 자신이 맡은 업무가 아니더라도 프로그램을 읽는 것은 프로그래밍을 배운다는 의미에서 그다지 나쁜 일은 아니다.
과거엔 프로그래밍 환경이 좋지 못했기 때문에 실습뿐만 아니라 학습(읽기)을 통해서도 능력을 길렀다.
하지만 시대가 변함에 따라 컴퓨터와 씨름하느라 균형이 무너진다.
프로그래머라면 다른 사람의 프로그램을 읽어서 뭔가를 얻을 수 있다.
나쁜 예제라면 반면교사로 좋은 예제라면 프로그램의 흐름을 알거나 자신이 모르고 있는 부분을 명확하게 알 수 있을 것이다.
글쓰기에서도 badcase를 참고하는게 좋을 수 있다고 한다.
프로그램을 읽을 때 각 부분의 발단으로 구성된 개념적인 프레임워크를 토대로 읽어야 한다.
즉, 코드를 한 줄 만날 때마다 "이 코드가 왜 여기에 있을까?"를 생각하는 것이다.
문서화되지 않고 당시에 상황을 해결하기 위해 작성된 프로그램은 큰 단점이다.
기계의 한계
다른 협업자(미래의 나)가 오용하거나 이를 한계로 인식하지 않고 단점을 사실로 인정해버리는 경향이 있다.
언어적인 한계
언어의 한계로는 하이 레벨 언어를 사용하다 보면 하드웨어의 특정 기능을 사용할 수 없게 된다는 점이 있다.
언어적인 한계로 필요 이상의 제약이 발생하고 이 때문에 코드의 덩치는 커진다.
그러나 이런 제약이 사라지기 전까지 제약으로 인식되지 못할 수도 있다.
교외에 나가서야 도시의 공기가 혼탁했다는 사실을 깨닫게 되는 것처럼 말이다.
따라서 언어가 생겨남에 따라 현재에는 인식하지 못하는 새로운 한계가 드러날 수도 있다.
프로그래머의 한계
프로그래머는 사용하는 컴퓨터와 언어, 프로그래밍에 대한 지식에 대한 부족으로 많은 코드를 쓸데없이 추가할 수 있다.
특정 알고리즘에 대해 모르거나, 충분히 이해할 능력이 안 될 수도 있다.
역사의 흔적
해당 프로그램의 개발 역사 때문에 여전히 존재하는 문제점들을 발견하는 경우도 있다.
명세
명세는 프로그램, 프로그래머와 함께 진화한다.
프로그램을 작성하는 것은 일종의 학습이다.
프로그램이 하는 일이 우리가 그 프로그램에게 원했던 바로 그것이길 바란다. (프로그램은 동작헤야 한다.)
요약
어떤 프로그램이 현재의 모습을 갖게 된 데에는 다 이유가 있다.
코드를 세심히 읽기보다는 그저 훑기만 하기 때문에 그 이유를 모두 알아차릴 수는 없겠지만 읽다보면 기계, 언어, 프로그래머의 한계로 그런 모습이 되었거나 혹은 당시에 존재했던 외부 조건(사건), 주어진 명세 때문에 그렇게 작성되었음을 알 수 있다.
최종 산출물에 포함된 코드에는 각각 나름의 이유가 있고, 그 이유에는 심리적인 면이 있다.
논의사항
2장 좋은 프로그램이란 무엇인가?
프로그래밍을 인간의 행위로 연구하기 위해선 능률을 측정할 방법이 필요하다. (어떤 프로그래머가 우수한지)
프로그래밍은 단순한 인간의 행위가 아니라 복잡한 인간의 행위이기 때문에 답을 도출하기 까다롭다.
좋은 프로그램을 평가할 때 코드 자체만으로 좋다 나쁘다를 논할 수 없다.
보편적인 좋은 프로그래밍은 개개인의 사상으로 존재할 수 있지만, 사실이라고 해도 좋은 프로그램의 존재를 말할 수 없다.
즉, 프로그램을 개발하며 일어난 주변 환경과 실행 환경을 전혀 고려하지 않은 채 프로그램의 점수를 딱 정할 수 없다는 것
프로그램 평가 기준에서 그 프로그램이 실행될 기계와 컴파일러, 비용 환경 등을 고려하지 않을 수 없다.
프로그램 개발은 계획한 기간 안에 끝냈는가?, 개발 비용이 얼마나 들었는가? 주어진 환경 명세서를 만족 시키는 가 등등
단지 코드만 보고서는 이런 요소를 알 수 없다.
상대적인 척도도 불가능하다.
최고의 프로그램은 동작하며 명서세에 부합하는 프로그램이다.
요구 명세
프로그램에 요구하는 조건 중 가장 먼저 꼽히는 것은 정확성이다.
프로그램이 작동하지 않는 상황에서 효율성이나 적응성, 개발 비용 등의 다른 척도는 전혀 의미가 없다.
세상에 완벽한 프로그램은 절대 없다.
따라서 프로그램이 주어진 요구 명세를 얼마나 만족시키느냐 즉, 얼마나 잘 작동하느냐가 문제가 되는 것이다.
사용자 한 명을 위한 프로그램과 진정한 소프트웨어 사이에는 엄연한 차이가 있다.
사용자가 여럿이면 요구 명세도 여러 벌이 된다.
일정
요구 명세를 만족시키는가의 문제를 차지한다 해도 효율성이 최우선의 문제가 되지 않는다.
프로그래밍에서 계속 반복되는 문제는 일정을 맞추는 일이다. (마라톤)
개발 기간 중 크런치가 위험한 이유
적응성
대다수의 프로그램들은 일정 기간 동안 생명을 유지한다.
그리고 그 생명 주기 동안 대부분의 프로그램은 수정을 겪는다.
그렇다면 왜 사람들은 원래 작성된 코드를 버리고 처음부터 몽땅 새로 작성해야겠다고 결정하는 상황이 많은 것일까?
프로그램이 효율적으로 동작하게 만들려면 주어진 문제와 프로그램을 실행할 기계의 특성을 잘 활용해야 한다.
기계의 구조를 무시하면 프로그램은 잠재적으로 성능 면에서 큰 손해를 보게 되고, 문제의 특성을 잘 활용하면 프로그램을 더 작고 빠르게 만들 수 있다.
효율성을 추구하면 보통은 코드가 빡빡해져서 수정하기 어렵게 된다.
고수준 언어로 작업하다가 프로그램을 좀 더 효율적으로 만들려고 기계어로 내려가는 일도 가끔 있다.
이는 프로그램을 고수준 언어로 작성하는 이점 중 하나를 포기하는 것이다.
그리고 그렇게 하면 특정 기계에 얽매일 뿐 아니라, 당시의 만족스럽지 못한 프로그램 구현 상태에도 종속되는 것이다.
거꾸로, 일반적이고 수정하기 쉬운 프로그램을 요구하는 관리자들도 나중에는 프로그램이 느리거나 너무 크다고 불평하곤 한다.
우리는 이 사이에서 균형잡기를 해야 한다.
효율성
프로그램의 진정한 효율성은 언뜻 생각하기와 달리 쉽게 측정할 수 없다.
일단, 컴퓨터에서 실행시키는 데 필요한시간만이 효율성의 전부가 아니다.
실행 전후에 드는 시간이 컴퓨터의 실행 시간에 영향을 미칠 수 있다.
언어의 사소한 차이로도 컴파일러의 효율성은 크게 달라질 수 있다.
컴퓨터가 소비하는 시간만이 비용의 모든 요소인 것은 아니다.
사람이 소비하는 시간도 비용이다.
여기서 트레이드 오프 발생 앞서 다른 고수준 언어와 저수준 언어 그리고 효율성 측면의 생각
단순히 컴퓨터상의 실행 시간만 줄인다고 능사는 아닌 것이다.
결론적으로 컴퓨팅에서 효율성은 점점 더 애매해지고 있다.
현대에는 언어가 더 고수준에 가까워짐에 따라 최적화는 좀 나중의 문제로 보인다.
시간이 지날수록 효율성보다 효용성이 더 증가할 것이다.
요약
좋은 프로그램이란 무엇인가라는 물음에 다음과 같이 답할 수 있다.
코드의 품질을 평가하는 방법을 결정하는 새로운 요소 가운데 가장 큰 것은 경제적 요소이다.
이는 게임업계에서도 많이 증명된다.
실제 코드의 구조가 좋지 못하더라도 100만장을 판 인디게임이라면 성공한 게임이다.
고객을 만족시키고 소프트웨어적으로 성공했기 때문이다. (게임은 상품)
논의사항
3장 프로그래밍이란 행위를 연구할 방법은 무엇인가?
앞서 지적한 바와 같이, 프로그래밍은 엄연히 인간 행위(복잡한)의 한 형태임에도 그런 관점에서 프로그래밍을 연구한 사람은 거의 없다.
인간의 지식은 필연적으로 불완전하다.
우리는 앞으로 무엇을 알게 될지 그리고 무엇을 절대 알 수 없을지를 미리 알지 못한다.
그러나 이것 하나는 확실하다.
알려고 시도하지 않는다면 절대 알 수 없을 것이다.
프로그래밍은 인간 행위이므로 인간행동학을 참고하는 것이 현명해 보인다.
내성법
현대 인간행동학에서는 내성법을 비과학적인 것으로 취급하지만, 내성법은 인간행동 연구에서 항상 기초가 되어 왔다.
내성법을 통해 프로그래밍에서 뭘 관찰할 수 있을까?
예제와 같이 한 문장의 적절한 길이, 자료 구조의 선택, 프로그램 내 코드의 배치, 괄호의 사용, 컴파일러와 실행 모니터링 기능의 설계, 프로그래밍 교수법 또는 학습 기술 등등.
모두 내성법 아니고서는 인지하기 힘든 문제다.
그러나 프로그래머는 매일 부딪히는 이런 문제를 단순히 버그라고 생각한다.
내성법을 실천하지 않는다면 그 버그는 결국 그들을 잡아먹을 것이다.
위 같은 명제를 내성법을 통해 써봤자 법칙이 될리 없다.
어떤 명제가 법칙이 되기 위해서는 그 적용 한계가 어디인지까지 밝혀야 한다.
모든 법칙에는 한계가 있기 때문이다.
사실 보통 그 한계가 법칙 자체보다 더 중요하다.
그리고 법칙의 적용 한계는 다양한 경우를 조사해야 알 수 있다.
따라서 내성법 없이 조사한 결과는 빈약하겠지만, 조사가 뒷받침되지 않은 내성법의 결과는 그 가치를 의심받을 것이다.
관찰
내성법의 결과를 검증하는 방법 가운데 사람들이 자신이 어떻게 행동할것이라 생각하느냐가 아닌 그들의 실제 행동을 관찰하는 방법이 있다.
또는, 관찰의 결과로 새로운 논제가 생겨날 수도 있다.
관찰의 두번 째 문제점은 관찰은 관찰일 뿐이라는 것이다.
관찰을 할 때에는 매우 신중해야 한다. 프로그래밍은 극도로 복잡한 행위이기 때문이다. (각 상황은 여러 가지 면에서 차이가 있기 때문이다.)
세번 째 문제점은 관찰자와 피관찰자 사이에 생기는 간섭 현상이다. (불확정성 원리의 일종이다.)
그런 현상을 만드는 원인은 관찰 행위 그 자체였던 것이다.
이런 현상을 설명하는 호손 효과라는 이론이 있다.
피험자들이 실험에 참가하고 있다는 사실을 의식해서 평소와 다른 행동을 함으로써 결과에 영향을 미치는 현상을 말한다.
관찰자와 피관찰자 사이의 간섭 현상은 비단 산업심리학에서만 일어나는 것은 아닌 인간의 행동을 연구하는 모든 과학 분야에서 문제가 된다.
실제 관찰자들은 철저히 투명인간이되려고 노력하고 이를 통해 은밀하게 관찰한다.
컴퓨터 분야에서 사용하는 은밀한 관찰법으로는 사용자의 행동을 컴퓨터를 통해 직접 기록하는 것이다.
컴퓨터의 로그는 매우 자세한 수준까지 기록되기 때문에 그 자료를 통해 사용자 개개인까지도 연구할 수 있다. (통계)
실험
관찰해서 생긴 자료가 지나치게 방대하기 때문에 소요되는 비용을 줄이는 방법 가운데 실험 설계가 있다.
실험을 이용하면 더 적은 자료로도 연구하려는 행동에 관한 더 많은 정보를 얻을 수 있다.
그러나 실험 내재하는 가장 큰 문제은 실험이 지나치게 정제되어 가장 흥미로운 자료를 얻는 데 실패할 수도 있는다는 점이다.
너무 제약되어 피험자가 자연스러운 상황에서는 절대 하지 않을 행동을 할 수 있다.
다른 문제로는 실제 배치 시스템과 다를 수 있다던가 비용적인 문제가 있을 수 있다.
보통 프로그래밍을 사회적 행위가 아닌 개인 행위로 취급한다.
그러나 프로그래밍에 관한 연구는 프로그래머 그룹 차원에서 행하는 것이 적절하다는 증거가 여럿 있다.
개인 차원이 중요하지 않다는 뜻은 아니지만, 일반적인 프로그래머는 작업 시간 중 3분의 2를 다른 사람과 협업하는 데 소비한다.
심리학의 측정법
"프로그래밍을 몇 년이나 했는지"를 경험을 측정하는 척도로 삼는 것은 프로그래밍 심리학을 연구할 때 부딪히는 많은 측정 문제 중 하나에 불과하다.
인간의 행동을 관찰하거나 연구하는 과정에서 측정해야 할지도 모르는 항목이 수백만까지는 아니더라도 족히 수천 개는 된다.
이러한 많은 항목이 문제가 된다. (아직 심리학, 인간행동학이 중분히 성숙하지 못했기 때문)
그러나 인간의 행동을 연구할 때는 그렇게 단순하게 할 수가 없다.
심리학의 주제는 측정할 수 있는 것으로 정하는 게 아니라 알고 싶은 것으로 정한다. (따라서 가능한 많은 요소를 측정)
그 중 몇 개만이라도 주어진 문제를 꿰뚫는 통찰을 얻는 데 도움이 되길 바라면서 말이다.
실제로, 태어난 달이나 계절이 어떤 심리적 또는 물리적 변수와 상관관계가 있다는 취지로 시작한 연구가 있다. (통계적 사주 관점)
민간 지식은 통찰을 얻는 한 방편이 될 수 있다.
또 다른 방편이 있다면, 현재 다른 목적을 위해 사용되는 수단을 빌리는 것이다. (IQ검사 등)
그러나 가장 표준적인 과정은 역시 그 반대 방향이다. (문제에서 수단으로)
연구 대상을 잘 알지 못한다면 무엇을 측정해야 할지 미리 알 수 없는 노릇이다.
프로그래밍 심리학의 현재 수준에서는 질문을 찾는 것이 주된 작업이다.
기존 심리학의 측정 수단들을 이용할 수 있다지만, 그렇다 해도 아직 그 수단들을 시험하는 것이지 주제를 직접 다루는 수준은 되지 않는다.
논외로 궁금해진 MBTI와 개발자간의 상관성이 궁금해져서 알아봤다. 실제로 조사하고 이를 통해 통계를 작성하는 경우가 많다. 한국에서도 다양한 글이 있지만 아마 외국에서는 실제로 이를 통해 통찰을 얻기도 할 것 같다. 관련글
하지만, MBTI특성이 사람의 평균 수에 비례하지 않기 때문에 경향성을 보는 것이지 이를 통해 심리학의 문제를 해결할 수는 없는 것 같다.
인간의 행동을 연구한 선배 과학자들이 이미 경험했던 함정을 인지하지 못한 상태에서 얻은 측정을 가지고 성급하게 결론을 내는 것은 누구나 지양해야 할 일이다. (마치 갈릴레이의 사고 실험)
인간행동학의 기존 연구 자료 이용
기존의 인간행동학 연구에서 우리가 배울 부분은 주로 그 방법론이다.
프로그래밍은 매우 특수하므로, 그 결과를 프로그래밍 심리학에 그대로 적용하길 바라기는 어렵다.
기존 연구 결과는 답을 얻기보다는 통찰을 얻는 데 이용해야 한다.
너무 특화된 이론에는 현혹되지 않는 것이 좋다.
프로그래밍에 해당하지 않는 상황을 전제로 한 이론이기 쉽기 때문이다.
프로그래밍에는 올바른 해답이 없기 때문에 설사 있다고 해도 피험자보다 더 올바른 해답을 알고 있다는 보장은 없다.
컴퓨터 프로그래밍에 대한 가장 유용하고 포괄적인 모델을 제시하는 사회 과학은 인류학이다.
커뮤니케이션, 사회적 구조관계이다.
확실히 프로그래밍 관련 분야에서 심리학적으로 가장 많이 활용될 수 있는 부분이 인간관계론쪽이라 생각된다.
이런 개인적, 사회적인 측면 이후에는 프로그래머의 도구를 심리학적 관점에서 검토해야 한다.
도구는 잃어버린 프로그래밍 문명을 이해하기 위해 발굴하고 연구해야 할 유물인 것이다.
마지막으로 이런 논의를 모두 성공적으로 마치고 나면, 프로그래밍에 대한 신화적인 사회 통념과 신조를 충분히 객관적인 관점에서 고찰할 수 있을 것이다.
요약
프로그래밍은 복잡다단한 행위이기 때문에 우리는 인간행동학에서 가능한 많은 방법론과 연구 결과를 차용할 필요가 있다.
그러나 그 과정에서 함정에 빠질 우려가 있으므로, 프로그래밍 심리학을 직접 연구하려 할 때에는 통상적인 함정에 미리 대비해야 한다.
주요 문제점
그러나 아직 미숙한 분야에서 일어나는 최대 실수는 바로 지나친 신중함이다.
실험을 전혀 하지 않는 것보다 실험을 한 후에 실패하는 편이 더 낫다.
논의사항
The text was updated successfully, but these errors were encountered: