4장 프로그래밍 도구 #212
Comments
5 tasks
This was referenced Feb 10, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
{{ message }}
4부 프로그래밍 도구
11장 프로그래밍 언어
프로그래밍 언어에 대한 수많은 논문은 있지만 그에 비해 심리학과 관련괸 내용은 찾기 힘들다. 미래의 컴퓨터를 상상하며 시간을 보내는 사람들 말고, 주어진 프로그래밍 언어를 써야만 하는 일반적인 사람에 대한 고려가 없는 것이다.
시대가 발전함에 따라 기계는 계속 변화하지만, 사람은 그대로이다.
따라서 프로그래밍 언어란 무엇인가를 이해하려고 노력하는 것보다 사람을 먼저 고려하고 기계와 수학을 나중으로 미루는 것이 더 중요하다. (심리학에 영향이 있는 부분만 다룰 것이다.)
프로그래밍 언어에 대한 논의는 언어란 무엇인가 그리고 언어에 있는 여러 의미를 고려할 때 프로그래밍 언어를 어느 선까지 언어로 볼 수 있는지를 살피는 것 시작한다.
언어 설계는 대부분의 일반 프로그래머들과 별로 관련이 없으므로 일반적으로 더 필요성이 큰 문제인 기존의 프로그래밍 언어 가운데 어떤 것을 선택할지에 집중할 것이다.
프로그래밍 언어와 자연 언어
프로그래밍 언어라는 개념은 프로그래밍이라는 개념 자체와 함께 탄생한 것이다.
프로그래밍 언어라는 개념의 뿌리가 너무 깊으므로 프로그래밍 언어가 진짜 언어가 아님을 증명하려는 시도는 너무 현학적인 일일 것이다. 언어라는 것은 우리가 그렇게 부르면 언어인 것이다.
겉으로는 실용적인 것이 최고라고 하지만 마음속 깊은 곳에서는 모든 프로그래머가 프로그램이 단지 작동하는 것만으로는 충분하지 않으며 다른 여러 측면에서도 옳아야 한다고 생각한다. 나중에 언어의 설계와 프로그램 테스트를 논의할 때 프로그램의 미학적 가치와 실용적 가치 사이의 연관 관계가 우연이 아님을 보게 될 것이다.
매우 매우 동의한다. 간단하게 가독성을 예로 네이밍을 중요하게 생각한다면 해당 클래스가 한 가지 책임 이상을 가진다면 그 만큼 네이밍이 모호해지거나
and가 들어가는 등 미학적으로 거리가 멀어진다. 이는 SRP와 연관되어 책임을 한 가지만 지는, 유연해지는 것과 직접적인 연관성이 있다."아름다움이 진리이며, 진리는 아름다움이어라."
프로그래밍 언어 설계
일반적으로 우리는 새로운 언어를 배운 다음에야 현재 사용하는 언어의 단점을 명확하게 인지할 수 있다. 머릿속에 자리 잡은 프로그래밍 언어의 표준은 계속 변하고 만약 언어를 설계한다면 이를 반드시 고려해야 한다.
세상의 다른 표준은 거의 변하지 않지만 프로그래밍 표준만 계속해서 변화하는 이유는 기계의 경직성과 그에 따른 프로그래밍 언어의 경직성에 있다. 새로운 기계와 마주친 사람은 자신이 원하는 것과 지금 눈앞에 존재하는 것 사이의 간극을 좁히려 할 텐데, 그러려면 자신을 기계에 맞추든가 아니면 기계를 자신에게 맞추는 수밖에 없다.
기계, 특히 컴퓨터를 변화시키는 일도 가능하지만, 그렇게 하는 데 걸리는 시간은 보통 우리가 기계에 맞추는 데 걸리는 시간보다 훨씬 길기 마련이다. 어떤 의미에서는 컴퓨터를 인간의 성향과 한계에 더 잘 들어맞도록 우리에게 맞추려는 시도가 바로 프로그래밍 언어라 할 수 있다.
기계가 경직된 만큼 그 기계를 성공적으로 사용하려는 사람은 더 유연해져야 한다. 이 현상을 두고 인본주의자들은 비인간화라 생각하는지도 모르겠다. 일반적인 인간관계에서는 반드시 주고받는 것이 있어야 하기 때문이다. 한 쪽은 주기만 하고 상대는 받기만 하는 관계는 완전한 인간관계가 아니며, 양쪽의 인간성을 왜곡하는 결과를 낳기 쉽다.
우리는 어떤 프로그래밍 언어에 익숙해져 갈수록 그 언어에 점점 얽매이게 된다. 그 이유는 대부분 그 과정에서 너무 많은 투자를 했기 때문이다.
이는 사람은 현재 상황이 주는 고통이 아무리 크더라도 상황을 바꾼 후 결과가 확실하지 않다면 그냥 참고 안주한다. 프로그래머가 프로그래밍 언어를 배울 때도 마찬가지다. 첫 번째 언어를 배울 때 즉, 그가 아직 어떤 언어에도 투자한 바가 없을 때에는 아무런 문제가 없다.
그러나 두 번째부터는 얘기가 다르다. 이미 익숙한 언어를 사용할 때는 누리는 편안함을 버리고 낮선 언어를 사용하면서 겪게 될 고난을 선택하기란 쉽지 않다. 그 고난을 이겨 낸 후의 보상이 명백하지 않은 한 말이다.
만약 특정 언어에 종속되지 않은 범언어적인 원리들을 밝히고 가르칠 수 있다면, 그래서 초보자까지도 새로운 언어를 배울 때 그런 일반적인 척도를 기준으로 삼을 수 있다면, 위와 같은 상황이 나아질 수 있다. 그러나 오늘날 대학 등의 교육 현장은 정확히 반대로 가튼 것 같다.
지금도 그러하다는 것이 굉장히 신기하고, 이유가 궁금해지기도 한다.
원리를 가르치지도 않고, 대조적인 두 언어를 동시에 가르치는 일도 없다. 또 언어를 가르친다 해도 프로그래밍의 여러 측면을 폭넓게 보여줄 수 있는 언어를 택하면 좋을 텐데, 보통은 간단하고 작위적인 언어를 택한다. 이는 학생들에게 프로그램을 작성할 능력을 최대한 빨리 심어 주려는 목적이며 프로그램의 종류는 상관하지 않는다는 뜻이다. 물론 전혀 가치가 없다고 말할 순 없지만 학생이 프로그래머로 성장하는 데 한계를 긋게 될 가능성이 있다.
프로그래밍 언어의 심리학을 이해하려면, 프로그램을 읽는 것 이상이 필요하다. 프로그램이 작성되는 과정을 관찰해야 하며, 프로그래머를 직접 면담해야 할 수도 있다. 그러나 사실은 그렇게 해도 전부 파악할 수는 없다. 직관적으로 금방 파악할 수 있는 것 이상을 얻으려면, 다양한 경로를 통해 다양한 정보를 축적해야 한다.
이렇게 일이 복잡한 까닭은 프로그래머 자신조차 자기 행동의 이유을 명확히 알지 못하는 경우가 많은 탓이다. 이는 인간 행동을 다루는 모든 연구에서 공통적으로 겪게 되는 걸림돌이다.
심리학적 관점에서 프로그래밍 언어나 기계를 평가할 때는 나쁜 프로그래밍에 대한 책임을 서툰 프로그래머에게 모두 전가하는 손쉬운 길을 택해서는 안 된다. 앞서 다룬 환경의 공통적인 요소처럼 프로그래머가 언어를 배우는 과정에선 종합적인 요소를 평가하고 코스트를 체크해야 한다.
요약
프로그래밍 언어를 언어로 취급하는 사고방식으로 인해 인간과 기계의 의사소통이 진보하지 못하고 있다. 어떤 것을 언어라고 부른다고 진짜 언어가 되는 것은 아니며, 오히려 잘못된 편견을 가지게 됨으로써 결국 엉뚱한 방향으로 연구가 진행된다.
프로그래밍 언어가 진보하려면, 성배(은총알)를 찾으려는 즉, 프로그래밍을 위한 진짜 언어를 찾으려는 노력을 그만둬야 한다. 프로그래밍 언어는 절대로 인간의 언어와 같을 수 없기 때문이다. 우리가 추구해야 할 것은 프로그래밍 언어를 더 자연스럽게 만드는 일이다.
다시말하자면, 컴퓨터를 잘 사용하기 위해 우리의 생각하는 방식을 바꾸고 있는 중인지도 모른다. 그렇게 하면 안 될 이유가 있을까? 인간의 다른 발명들도 모두 인간을 바꿔놓지 않았던가?
세월이 흐르면서 생각보다 많은 프로그래밍 용어와 개념들이 일상에 들어왔다. (추상적이였던 개념을 잘 설명하기 위한 좋은 단어)
논의사항
12장 프로그래밍 언어 설계에 필요한 원칙
일관성
프로그래밍 언어에서 어떤 면을 어렵게 느낄 것인지에 대한 경험 자료를 가끔 일반 심리학의 연구 결과에서 찾을 수 있다. 바로 일관성의 원칙이다.
일반 심리학 연구 결과에 따르면 어떤 목록을 얼마나 잘 기억할 수 있는가는 그 목록에 담겨 있는 정보의 내용과 밀접한 관련이 있다고 한다. 그런데 이때 정보의 내용이란 그 사전적 의미처럼 단순하지 않다. 목록에 포함되어 있는 것뿐만 아니라 목록에 있지 않지만 그 목록을 기억해야 하는 사람의 머릿속에 들어 있는 것도 정보의 내용에 포함되기 때문이다.
위 이진수 목록보다 아래 이진수를 더 외우기 어려울 수 있다. 이는 앞서 말한 이진수 체계에 대한 정보의 기반으로 외우기 때문이다. 즉, 목록에서 빠진 항목이 얼마나 많으냐가 외우기 어려운 정도를 결정하기 때문이다.(외워야 할 정보의 증가)
반대로 이진수 체계를 모르는 사람일 경우는 달라진다. 다른 사람의 눈엔 일련의 난수로 보이기 때문이다.
이와 같은 현상은 프로그래밍 언어에서도 자주 발생한다.
예로는 람다, 최신 기능의 적용 (C#의 경우 is not)을 예로 들 수 있을 것 같다.
프로그래밍 언어의 일관성을 굳이 한문장으로 정의하자면 "동일한 표현은 그 위치와 상관없이 동일하게 동작한다. "프로그래밍 언어가 이 원칙에서 멀어질수록 배우기가 어렵고 프로그래머가 오류를 범할 가능성도 커진다.
앞서 말한 일관적이지 못한 문법은 프로그래머가 여러 가지 의미론적인 시도를 하는 데 장애물이 된다. (이는 협업자간의 컨벤션이 통일되어야 함을 의미한다.) 예외가 너무 많아 프로그래머가 스스로 그 언어에 정통했다는 자신감을 갖기가 어렵기 때문이다. (자신이 알고 있는 지식과 충돌)
이런 충돌을 회피하기 위해선 한 가지 언어에 대한 깊이가 있다면 다른 언어를 학습할 때 차이점을 두고 공부하는 것이 효율적이라는 생각이다. 최근 C#에서 C++넘어가야 하는 일이 있었는데, 알고있는 지식을 활용한 학습법이 가장 효과가 좋았다.
모든 원칙에 탄탄한 근거가 뒷받침되는 것은 아니며, 그렇게 근거가 빈약한 원칙일수록 검증하기 않고 슬그머니 넘어가곤 한다. 그중 대표적인 것이 명확성의 원칙이다. "모든 언어에는 반드시 문자 집합과 명확하고 결정력 있는 문법이 있어야 하기 때문에..."
포트란의 예제 말고도 유행하는 수학 문제?의 논제도 명확성의 문제로 보인다. (n = 8 / 2(2+2)) 다만 이는 프로그래밍 영역이 아닌 수학에 대한 인지적인 부분.
또한 이런 명확성에 관련된 프로그래밍 영역의 문제는 IDE가 발달하면서 대부분은 체크가 되는 것 같기도 하다.
간결성
인간의 정신에 선천적인 용량의 한계가 있음을 언급했다. (이는 LTM, STM정도로 생각해도 좋을 것 같다.)
우리는 단어를 사용하는 습관이 있다. 다른 연구를 통해서도 우리의 사고 과정에서 단어로써 치환 과정이 쉽게 일어남을 확인할 수 있다. (이는 청크와 추상화 개념에 대한 설명)
심리학에서는, 여러 작은 단위를 조합하여 커다란 단위 하나로 묶고 그렇게 만들어진 큰 단위도 각각을 구성한 하위 단위와 마찬가지로 쉽게 다루는 인간의 정보 처리 능력을 의미덩이 만들기(chunking)라 부른다.
프로그래밍 언어의 설계자가 활용할 수 있는 의미덩이는 제한되어 있다. 프로그래머가 그 언어를 사용하기 전부터 이미 알고 있거나 그 언어를 사용하면서 바로 익힐 수 있음 직한 의미덩이들만 가능하다. 그러나 동일한 것을 여러 방법으로 표현하는 수단을 제공하여 프로그래머에게 그 이상의 의미덩이를 사용할 기회를 줄 수 있다.
글을 쓸 때는 정보를 중복함으로써 얻어지는 효과부터 부담이 더 큰 편이기 때문에, 프로그래밍 언어에서 잘 만들어진 디폴트 체계는 충분한 가치가 있다.
근접성과 순차성
잘 설계된 프로그래밍 언어는 좋은 기억력과 마찬가지 방식으로 프로그래머를 도와준다. 즉, 관련된 정보를 쉽게 찾을 수 있는 곳에 담아 두는 것이다.
이에 관련하여 우리가 관심을 가져야 할 기억력과 종류에는 두 가지가 있다. 바로 공감각적 기억력과 순차적 기억력이다.
프로그램에서 근접성의 개념은 공감각 기억에, 순차성의 개념은 순차적 기억에 대응한다. 근접성은 프로그램에서 서로 관련 있는 부분이 모두 한 장소에 나타나는 성질을 의미한다. 근접성이 좋지 않으면, 소스코드를 가지고 작업하는 프로그래머는 지금 페이지와 관련 있는 다른 페이지의 내용을 모두 기억할 수 있을 정도로 공감각 기억력이 뛰어나지 않는 한 계속 여러 페이지를 봐야한다.
프로그래밍 언어에서 근접성을 높이는 방법 가운데 하나는 압축이다. 극단적으로 얘기해서, 전체 프로그램이 한 페이지에 들어간다면 당연히 관련 있는 모든 부분이 그 페이지에 모여 있을 수밖에 없다.
책에서 말하는 과거 사례에서 볼 수 있듯이 코드가 더 유연하고(예술적) 논리적으로 변경되어야 하는 이유를 알 수 있다.
전통과 혁신
실수할 가능성은 최소로 줄이면서 쉽게 표현할 수 있으려면, 프로그래밍 언어가 자연스러워지는 것이 가장 필요하다. 자연스러움은 앞서 보았듯이 일관성을 통해서도 얻을 수 있지만, 이는 이미 그 언어에 어느 정도 경험이 쌓인 프로그래머들에게만 효과가 있다.
어떤 언어를 처음 첩할 때에 일관성을 인식하기는 어렵다. 오히려 프로그래머가 이미 지닌 기준에 의해 이상하다는 느낌을 받게 되기 쉽다.
객체지향 언어가 점점 서로를 닮아가는 과정이라 생각된다.
프로그래밍 언어가 자연어와 비슷해질 수 있는 영역으로는 철자법도 있다. 자연어로 씨은 글을 읽을 때, 우리는 종종 철자법이 틀려서 심지어 전혀 말도 안 되는 다른 단어로 바뀌는 경우에도 그 사실을 의식하지 못하고 넘어가곤 한다. 말할 때에는 당연히 철자법으로부터 더더욱 자유롭다.
반면에, 프로그래밍 언어는 대부분 의도가 무엇인지 뻔한 경우까지도 오류로 감지할 정도로 철자법에 대해서 극히 엄격하게 대처한다. 축약어도 어떤 단어의 또 다른 철자다.
프로그래머들은 저마다 너무 다르기 때문에, 프로그래머가 이미 아는 개념이나 구조에 새로운 언어를 부합하도록 만드는 데는 분명한 한계가 있다. 숫자 리터럴이나 단순한 산술 연산 같은 형식은 모든 프로그래머가 다 익숙하리라 예상되지만, 사람마다 제각기 선호하는 방식이 다르다는 문제에 봉착하는 건 시간 문제다.
같은 사안에 대해 가능성을 두 개 이상 제공하면 즉, 언어를 느슨하게 만들면 개인의 성향에 좀 더 맞춰 줄 수 있다. 어떤 의미에서 보면 느슨한 언어는 프로그래머 개인의 선호에 대한 적응성이 뛰어나다고 할 수 있다.
느슨함 외에도 언어의 적응성을 높이는 방법에는 여러 가지가 있다. 특정 프로그램 또는 모든 종류의 프로그램을 위한 새로운 뭔가를 만들 수 있도록 해주는 기능이 이에 해당한다. 함수 또는 하위 루틴을 정의할 수 있는 기능이 대표적인 예다.
최근에는 거의 모든 언어에서 지원하는 기능이라 생각한다.
특수 목적 언어, 범용 언어, 장난감 언어
만약 특정한 응용 분야만을 대상으로 특수 목적 언어를 설계한다면, 대화의 주제가 한정되기 때문에 심리적 이익을 처음부터 누릴 수 있다. 즉, 통계용 언어에는 복소수 연산 기능이 필요 없고, 문자열 처리 언어에는 복잡한 산술 연산이 필요 없으며, 기계 제어 언어에는 산술보다는 기하학 기능이 더 많을 것이다.
그러나 이렇게 언어의 기능을 제한한 이유가 목적한 분야의 문제들이 일정 정도 이상으로 커지지 않을 것이라는 가정 때문인 경우도 가끔 있다.
특수 목적의 프로그래밍 언어를 사용하는 사람이 신용하지 않는 사람보다 위와 같은 한계를 잘 인식하지 못하는 것은 언어가 사용하는 사람의 사고방식을 좌지우지하기 때문이다. (프로그램과 데이터를 조직화하는 방식 자체를 언어가 결정한다는 뜻)
대부분의 경우, 프로그래머는 자신의 기술 수준이 올라갔을 때 자기 충족적인 만족감을 느끼지만, 특수 목적의 프로그래밍 언어를 사용할 때에는 그와 상관없이 만족감을 느끼게 되기도 한다. 언어에 의해 사고방식이 굳어져서 언어와 자신이 그 언어에 대해 알고 있는 범위 내로 문제를 제한해 파악할 수 있기 때문이다.
어떤 프로그래밍 언어가 그것이 목적한 특수한 일을 잘 처리하면 할수록 그 사용자의 사고는 더욱 더 좁아지는 결과가 된다. 이 모순에서 벗어날 방법은 없어 보인다. (자연 도태에 관한 기본 정리)
그러나 진정한 전문 프로그래머는 하나에 너무 잘 적응한 나머지 오히려 다른 것에는 적응할 수 없게 되는 함정에 빠져 있을 여유가 없다. 문제는 그 함정을 어떻게 피할 수 있느냐다. 아직은 해답을 찾을 길이 요원하지만 계속해서 연구하는 방식으로 찾아내야 한다.
특수 목적 언어는 해당 분야에 적합한 데이터 구조를 제공하고, 그로 인해 좀 더 간결한 프로그램이 가능하며, 사용자의 기존 지식에 잘 부합해야 성공할 가능성이 높다. 특수한 데이터 구조를 제공하면 그 구조와 연관되어 자주 쓰이는 연산기능도 함께 제공하기 마련이다. (그래픽스 쉐이더 코드 언어)
프로그래머가 아닌 사람들을 주된 사용자로 설정한 특수 목적 언어는 사용자의 기존 지식과 유사한 모습을 띠도록 설계된다. 그렇지 않으면 쉽게 적응할 수 없다.
이 과정도 나름의 균형잡기라고 생각된다.
요약
과연 지금은 몇 개 정도의 프로그래밍 언어가 존재할까?
프로그래밍 언어 수가 이렇게 폭발적으로 증가하는 것을 수영장 배수구에 조류가 무수히 자라나는 현상과 동일시해야 할까? 아니면 꼭 필요한 창조적 노력의 건강한 분출로 봐야 할까?
어떤 언어를 간단히 뚝딱 만들어서 책에 싣거나 프로그래머 앞에 던져 놓고 끝낼 수 있는 시절은 지났다.
이론가들은 프로그래밍 언어의 대화적 성격으로 눈을 돌려야 한다. 그래야만 자신들이 연구하는 것은 기호 조작이 아니라 인간 행위임을 깨닫게 될 것이다.
논의사항
13장 그 외의 프로그래밍 도구들
프로그래머가 사용하는 도구에는 프로그래밍 언어만 있는 것이 아니다. 프로그래머는 문서를 읽거나 쓰고 운영체제와 씨름하며 버그를 잡아내는 데 많은 시간을 소비한다. 그런 작업도 사회과학에서 배워 올 만한 부분이 있을 것이다.
그러나 심리학적 관점에서 볼 때 그런 작업들은 프로그래밍 언어보다 항상 무시받아 왔다. 하지만 그런 작업들의 중요성은 언어 못지않다.
프로그램 테스트 도구
프로그램에도 좀 다른 영역이 있다고 생각한다. 버그에 대한 손실이 크게 차이나는 부분이 있는데, 바로 의료와 과학분야와 문화와 예술분야의 차이다. 물론 버그가 발생하지 않는 것이 베스트이지만, 두 영역에서 발생한 버그의 차이는 매우 크게 다르다.
게임에서 발생한 버그와 의료체계에서 발생한 버그의 무게는 많이 다르다.
사실은 자잘한 오류 자체가 존재하지 않는다. 하이픈 한글자 빼먹은 오류마저도 엄청난 재앙을 초래한다. 프로그래밍에서 잘못의 크기와 그로 인해 발생하는 문제 사이에 아무런 연관 관계가 없다. 그것이 프로그래밍의 본질이다.
따라서 프로그램 테스트 작업의 목표를 어떤 공식으로 제시하기란 어렵다. 모든 오류의 제거를 목표로 할 것인가? 그러나 그것은 불가능한 일이다.
분명히, 프로그램 테스트에는 가능한 모든 수단이 동원되어야 한다. 그러나 프로그래밍 도구의 설계자들은 테스트에 대해 별로 관심이 없다.
중요한 것은 테스트 작업은 그 무엇보다 심리학적인 문제다. 신뢰의 문제를 예로 이상적인 테스트 도구란 우리가 프로그램을 신뢰할 수 있을 만큼만 신뢰하도록 도와주는 장치라 할 수 있다. 오류가 있는 프로그램을 합격 처리하거나 오류가 없는 프로그램을 쓸데없이 더 테스트하지 않도록 해줘야 한다는 뜻이다.
어떤 프로그램의 테스트 결과를 신뢰할 수 있으려면 얼마나 많은 코드가 테스트의 대상이 되었는지 알아야 한다. 가장 간단한 방법은 테스트 도구가 그 테스트의 대상이 되었는지 알아야 한다. 가장 간단한 방법은 테스트 도구가 테스트 과정에서 실행되는 코드 영역과 그렇지 않은 영역을 기록해 두었다가 나중에 결과와 함께 출력해 주는 것이다.
인간은 사물을 자신이 보고 싶은 대로 판단하는 경향이 있다. 그러나 우리는 프로그램을 있는 그대로 판단해야 한다. (객관성이 필요, 비자아 프로그래밍) 그러기 위해서는 프로그램 테스트 도구의 도움이 절실하다.
사람들은 자신의 프로그램을 낙관적으로 보고 일단 신뢰하는 경향이 있으므로, 테스트 도구는 그 신뢰를 깨는 데 원칙을 두고 설계되어야 한다.
테스트 결과에 대한 신뢰도를 결정하는 요인에는 그 테스트의 과정 자체만 있는 것이 아니다. 어떤 프로그램을 얼마나 많이 테스트해야 신뢰할 만한 결과를 얻을 수 있는지는 경험에 비추어 판단되기 때문이다.
일관성, 근접성, 간결성이 테스트를 더 쉽게 만들어 준다.
이는 앞서 다룬 객체지향의 영향에 해당된다.
테스트를 빨리 끝내고픈 유혹을 이이기 위해서는 프로그래머가 테스트 분량을 미리 계획하여 명시하도록 시스템 차원에서 강제하는 것도 좋은 방법이다. (분량을 채우지 못하면 보고하거나 자동 실행하여 분량을 파악)
심리학적 측면에서 프로그래머가 테스트 작업을 하는 걸 도울 수 있는 방법이 또 하나 있다. 앞 장에서 근접성을 논할 때 얘기한 대로, 어떤 프로그래머가 오류의 근원을 찾는 데 어려움을 겪고 있다면 잘못된 코드 영역을 살피고 있기 때문인 경우가 많다.
프로그래머가 일단 한 장소에 갇히면 다른 장소로 눈을 돌리게 만들기가 굉장히 어렵다. 따라서 디버깅을 못해 고생하고 있는 동료에게 줄 수 있는 가장 좋은 도움은 그가 다른 곳을 보게 만드는 것이다.
핵심은 프로그래머가 한 영역에 집착하지 않도록 하는 것이다.
운영체제
프로그래밍 언어 설계에서 끝없는 논쟁거리 중 하나는 디버깅 도구가 어디에 위치해 있어야 좋은가 하는 문제다.
디버깅 도구가 언어의 일부여야 할까, 아니면 운영체제에 포함되어야 할까? 지금 여기서 특정한 방향으로 결론을 내려고 이 얘기를 꺼낸 것은 아닌 양쪽 모두의 충분한 이유가 있다.
언어에 디버깅 도구가 포함되어야 한다는 사람들은 프로그래머가 단지 디버깅만을 위해 새로운 언어를 배워야 하는 건 불합리하다라고 말하지만 언어를 통해 디버깅을 하면 프로그래머와 실제 운영체제 사이에 언어라는 계층이 위치함으로써 운영체제의 여러 실질적인 측면을 프로그래머가 보지 못할 수 있다.
프로그래머들은 운영 환경이 어떻든 간에 결국에는 자신에게 유리한 방향으로 적응하게 된다. 운영 환경이 나쁘든 상관이 없다. 한 명이 어떤 행동을 하여 전체 운영에는 해를 끼쳤지만 자신은 이득을 봤다면 다른 프로그래머들도 그 행동을 따라할 것이다.
시스템이 효과적이고 능률적으로 사용되도록 확실히 보장하려면, 효과적이고 능률적인 사용법을 가장 쉬운 사용법으로 만드는 게 최선이다. 설계가 잘된 운영체제라면 가장 많이 사용되는 또는 그래야 할 작업제어 루틴 목록을 사용자에게 제공할 수 있을 것이다. 그렇다면 프로그래머들은 자연히 시스템을 잘 사용하게 된다.
시분할 대 배치
문서화
문서화는 프로그래밍에서 피마자유와 같은 존재다.
피마자유는 아주까리 씨에서 추출한 기름으로 독특한 냄새가 나지만, 피부진정등에 효과등을 지닌 특징이 있다. (과거에는 질병을 고치는 효능이 있다고 믿음)
관리자는 문서화가 프로그래머에게 유용한 작업이라고 생각하지만, 프로그래머는 문서화를 싫어한다. 문서화는 잘할 때에만 가치가 있지, 그렇지 않다면 한 하느니만 못하다.
프로그래머가 좋은 문서를 만들도록 강제할 방법은 없다. 잘하는 척 하면서 쓸모없는 문서를 만드는 방법은 너무나 다양하기 때문에 강제로 시켜봤자 안 좋은 문서를 쏟아낼 뿐이다. 따라서 유일한 희망은 문서를 잘 만들면 자신에게도 이득이 된다고 프로그래머를 납득시키는 방법뿐이다.
프로그래머가 문서화를 쓸모없다고 생각한다면, 문서화는 작업량을 최소화하는 방향으로 진행될 것이다. 그러나 문서화 작업이 가시적인 효과를 거둔다면, 모든 프로그래머가 어느 정도 좋은 문서를 만들려 할 것이다.
따라서 문서화의 이점을 프로그래머들이 체감할 수 있는 환경을 조성해야 한다.
우리는 문서화에 너무 많은 부분을 기대하는 잘못을 범하곤 한다.
첫째, 사람마다 프로그램의 문서를 읽는 목적이 전부 다르므로 모두 동일한 수준으로 만족시키는 문서 체계는 존재하지 않는다. 따라서 우리는 어느정도 적당한 목적을 하나 세우고 그에 부합할 만큼만 좋은 문서를 만드는 노력을 해야 한다.
둘째, 아무리 문서화를 잘해도 불가능한 것들이 있다. 예를 들어, 어떤 프로그램을 스물다섯 단어만 사용해서 비전문가에게 이해시키기는 불가능하다.
어떤 프로그램에 대한 문서를 활용하려면 반드시 노력과 사전 지식이 어느정도 필요하다. 영어를 못하는 사람은 영어를 읽지 못한다. (프로그래밍 협업자 끼리의 문서화와 팀내 영역에 대한 문서화는 다르다.)
깊이는 문서화에서 중요한 개념 중 하나다. 시스템이 클수록 더욱 그러하다. 일정 규모 이상의 시스템에서는 문서를 읽는 사람마다 얻으려 하는 정보의 상세 수준이 다르다. 깊이가 가장 얕은 문서라도 읽는 사람이 그것을 읽을 수 있는지 여부를 판단할 만큼 충분히 상세해야 한다.
문서화라 해서 마치 책처럼 물리적으로 존재하는 문서만 생각하는 것은 근시안적인 사고다. 아마도 프로그래밍 문서화 문제는 프로그램들을 그것이 실행되는, 바로 그 컴퓨터를 이용해 문서화하기 시작하기 전까지 정말로 해결됐다고 할 수 없을 것이다. (지금은 매우 자동화되어 있다.)
책이라는 매체에 분명한 한계가 있고, 그정도로 유연한 매체가 아닐 뿐더라 속도를 따라잡지 못한다. 또한 시스템이 복잡해지는 것에 따라 좀 더 능동적인 안내자가 필요하다.
이런 모든 과정에는 비용이 든다.
흐름도 추출기, 의존성 View와 같은 것을 문서화로 볼 수 있을까? 이는 디버깅 도구 쯤으로 생각할 수 있다.
책에서 말하는 가장 좋은 형태는 모든 질문과 답변을 단일 저장소에 모아서 원하는 정보를 쉽게 찾아볼 수 있는 환경을 제공하는 것이라 말한다. 문서의 내용을 항상 최신으로 유지시키는 장치만 갖춘다면 이 방식은 프로그래머가 곧 문서이던 시절로 우리를 돌려놓아 줄 것이다. 회사나 시스템 규모가 작을 때에는 명시적인 문서화에 그렇게 신경 쓸 필요가 없다.
어떤 프로그래머든 자신이 알고 있는 걸 모두 문서에 다 써 넣을 수는 없으며, 설령 그럴 수 있다 해도 모든 사용자가 자신이 원하는 정보를 문서에서 스스로 찾아낼 수는 없다. 이 방식에서 문제가 발생하는 경우는 프로그래머가 회사를 떠날 때인데, 비자아적 프로그래밍이 실천되고 있다면 크게 문제될 것은 없다.
문서화에 대해 프로그래밍 심리학적으로 논해야 할 사항은 프로그래머들이 문서화를 누구나 잘할 수 있는 작업 혹은 프로그래머가 될 정도로 똑똑하지는 않은 사람이 하는 업무라고 착각하고 있다는 사실 정도가 유일하다.
요약
시스템은 복잡하다. 컴퓨터 시스템은 단지 하드웨어뿐인 것도 아니고, 소프트웨어뿐인 것도 아니며, 심지어 인간 + 하드웨어 + 소프트웨어인 것도 아니다. 시스템과 함께 발달한 공식/비공식적인 절차도 시스템의 일부다.
논의사항
The text was updated successfully, but these errors were encountered: