머릿속에 프로그램을 담고 있기 | undefined

2007년 8월

자신의 코드에 몰두하는 훌륭한 프로그래머는 수학자가 작업 중인 문제를 머릿속에 담듯 프로그램을 머릿속에 담아둘 수 있다. 수학자들은 초등학생들이 배우는 방식처럼 종이에 풀이를 적어가며 문제를 해결하지 않는다. 그들은 머릿속에서 더 많은 것을 한다. 자신이 자란 집의 기억 속을 거닐 듯이 문제 공간을 충분히 이해하여 그 공간을 탐색할 수 있게 된다. 최고의 프로그래밍도 마찬가지다. 전체 프로그램을 머릿속에 담고 자유자재로 조작할 수 있다.

이는 프로젝트 초기에 특히 중요하다. 처음에는 진행 중인 작업을 변경할 수 있는 것이 가장 중요하기 때문이다. 단순히 문제를 다른 방식으로 해결하는 것을 넘어, 해결하려는 문제 자체를 변경하는 것이다.

코드는 당신이 탐구하는 문제에 대한 당신의 이해를 나타낸다. 따라서 코드를 머릿속에 담고 있을 때 비로소 문제를 진정으로 이해하게 된다.

프로그램을 머릿속에 담는 것은 쉽지 않다. 몇 달간 프로젝트를 떠나 있다가 돌아오면 다시 완전히 이해하는 데 며칠이 걸릴 수 있다. 프로그램을 활발히 작업할 때도 매일 작업을 시작할 때 머릿속에 로드하는 데 30분이 걸릴 수 있다. 이는 최상의 경우에도 그렇다. 일반적인 사무실 환경에서 일하는 평범한 프로그래머들은 이 모드에 결코 진입하지 못한다. 더 극적으로 말하자면, 일반적인 사무실 환경에서 일하는 평범한 프로그래머들은 자신이 해결하는 문제를 진정으로 이해하지 못한다.

최고의 프로그래머들도 작업 중인 전체 프로그램을 항상 머릿속에 로드하고 있지는 않다. 하지만 도움이 될 수 있는 몇 가지 방법이 있다.

주의 산만을 피하라. 주의 산만은 여러 종류의 작업에 좋지 않지만, 특히 프로그래밍에는 더 나쁘다. 프로그래머는 자신이 처리할 수 있는 세부 사항의 한계에서 작업하는 경향이 있기 때문이다.

주의 산만의 위험은 그 지속 시간에 달려 있는 것이 아니라, 얼마나 뇌를 혼란스럽게 만드느냐에 달려 있다. 프로그래머는 사무실을 나가 샌드위치를 사 먹어도 머릿속의 코드를 잃지 않을 수 있다. 하지만 잘못된 종류의 방해는 30초 만에 당신의 뇌를 초기화시킬 수 있다.

이상하게도, 예정된 주의 산만이 예정되지 않은 것보다 더 나쁠 수 있다. 한 시간 뒤에 회의가 있다는 것을 알면, 어려운 작업은 시작조차 하지 않게 된다.

장시간 연속으로 작업하라. 프로그램 작업을 시작할 때마다 고정 비용이 발생하므로, 짧은 여러 세션보다 몇 개의 긴 세션으로 작업하는 것이 더 효율적이다. 물론 피곤해서 머리가 멍해지는 시점이 올 것이다. 이는 사람마다 다르다. 36시간 연속으로 해킹하는 사람들도 있다고 들었지만, 내가 해본 최대치는 약 18시간이고, 나는 12시간을 넘지 않는 덩어리로 작업할 때 가장 효율적이다.

최적의 시간은 육체적으로 견딜 수 있는 한계가 아니다. 프로젝트를 나누는 것에는 비용뿐만 아니라 이점도 있다. 때로는 휴식 후 문제로 돌아왔을 때, 무의식이 답을 준비해두었음을 발견하기도 한다.

간결한 언어를 사용하라. 더 강력한 프로그래밍 언어는 프로그램을 더 짧게 만든다. 그리고 프로그래머들은 적어도 부분적으로는 프로그램을 작성하는 데 사용하는 언어로 프로그램을 생각하는 것 같다. 언어가 간결할수록 프로그램은 짧아지고, 머릿속에 로드하고 유지하기가 더 쉬워진다.

강력한 언어의 효과를 극대화하려면 하향식 프로그래밍(bottom-up programming)이라는 스타일을 사용할 수 있다. 이는 여러 계층으로 프로그램을 작성하여 하위 계층이 상위 계층의 프로그래밍 언어 역할을 하는 방식이다. 이것을 제대로 하면, 가장 상위 계층만 머릿속에 담아두면 된다.

프로그램을 계속 다시 작성하라. 프로그램을 다시 작성하는 것은 종종 더 깔끔한 설계를 가져온다. 하지만 그렇지 않더라도 이점이 있다. 프로그램을 다시 작성하려면 완전히 이해해야 하므로, 프로그램을 머릿속에 로드하는 데 이보다 더 좋은 방법은 없다.
다시 읽을 수 있는 코드를 작성하라. 모든 프로그래머는 읽기 쉬운 코드를 작성하는 것이 좋다는 것을 안다. 하지만 가장 중요한 독자는 바로 당신 자신이다. 특히 초기에는 더욱 그렇다. 프로토타입은 자기 자신과의 대화이다. 그리고 자신을 위해 작성할 때는 우선순위가 달라진다. 다른 사람을 위해 작성한다면, 코드를 너무 밀집하게 만들고 싶지 않을 수 있다. 프로그램의 일부는 입문서처럼 내용을 펼쳐 놓아야 가장 읽기 쉬울 수 있다. 반면에 머릿속에 쉽게 다시 로드할 수 있도록 코드를 작성한다면, 간결함을 추구하는 것이 최선일 수 있다.
소규모 그룹으로 작업하라. 머릿속에서 프로그램을 조작할 때, 당신의 시야는 자신이 소유한 코드의 경계에서 멈추는 경향이 있다. 다른 부분들은 잘 이해하지 못하며, 더 중요하게는, 마음대로 다룰 수 없다. 따라서 프로그래머의 수가 적을수록 프로젝트는 더 완벽하게 변화할 수 있다. 처음에는 종종 그렇듯이 프로그래머가 한 명뿐이라면, 전체를 아우르는 재설계를 할 수 있다.
여러 사람이 같은 코드를 편집하게 하지 마라. 다른 사람의 코드를 자신의 코드만큼 잘 이해할 수는 없다. 아무리 철저하게 읽었더라도, 당신은 그저 읽었을 뿐, 직접 작성한 것이 아니다. 따라서 한 코드 조각이 여러 저자에 의해 작성되었다면, 그 누구도 단일 저자가 이해하는 만큼 잘 이해하지 못한다.

물론 다른 사람들이 작업 중인 것을 안전하게 재설계할 수는 없다. 단순히 허락을 받아야 하기 때문만은 아니다. 당신 스스로도 그런 생각을 하지 않게 된다. 여러 저자가 있는 코드를 재설계하는 것은 법을 바꾸는 것과 같고, 당신 혼자 통제하는 코드를 재설계하는 것은 모호한 이미지의 다른 해석을 보는 것과 같다.

여러 사람을 프로젝트에 투입하고 싶다면, 프로젝트를 구성 요소로 나누어 각자에게 하나씩 맡겨라.

작게 시작하라. 프로그램은 익숙해질수록 머릿속에 담아두기 쉬워진다. 일단 완전히 탐색했다고 확신하면, 일부를 블랙박스처럼 취급할 수 있다. 하지만 프로젝트를 처음 시작할 때는 모든 것을 봐야만 한다. 너무 큰 문제로 시작하면, 결코 완전히 포괄하지 못할 수도 있다. 따라서 크고 복잡한 프로그램을 작성해야 한다면, 가장 좋은 시작 방법은 사양서(spec)를 작성하는 것이 아니라 문제의 하위 집합을 해결하는 프로토타입을 작성하는 것일 수 있다. 계획의 장점이 무엇이든 간에, 프로그램을 머릿속에 담아둘 수 있는 장점에 의해 종종 상쇄된다.

프로그래머들이 우연히 이 여덟 가지 사항을 모두 충족시키는 경우가 얼마나 많은지 놀랍다. 누군가 새로운 프로젝트 아이디어를 가지고 있지만, 공식적으로 승인되지 않았기 때문에 비번 시간에 해야 하는데, 이는 주의 산만이 없어 더 생산적인 것으로 판명된다. 새 프로젝트에 대한 열정에 이끌려 한 번에 여러 시간 동안 작업한다. 처음에는 단순한 실험이기 때문에 "프로덕션" 언어 대신 단순한 "스크립팅" 언어를 사용하는데, 사실 이 언어가 훨씬 더 강력하다. 그는 프로그램을 여러 번 완전히 다시 작성한다. 이는 공식 프로젝트에서는 정당화될 수 없지만, 이것은 사랑으로 하는 일이고 그는 완벽하게 만들고 싶어 한다. 그리고 그 외에는 아무도 볼 사람이 없으므로, 자기 자신을 위한 메모 외에는 어떤 주석도 생략한다. 그는 어쩔 수 없이 소규모 그룹으로 작업한다. 아직 아무에게도 아이디어를 말하지 않았거나, 너무 가망 없어 보여서 다른 누구도 작업할 수 없기 때문이다. 그룹이 있더라도, 코드가 너무 빨리 변해서 여러 사람이 같은 코드를 편집할 수 없다. 그리고 프로젝트는 아이디어 자체가 처음에는 작기 때문에 작게 시작한다. 그는 단지 시도해보고 싶은 멋진 해킹 아이디어가 있을 뿐이다.

더욱 놀라운 것은 공식적으로 승인된 프로젝트 중 이 여덟 가지를 모두 잘못 하는 경우가 얼마나 많은지이다. 사실, 대부분의 조직에서 소프트웨어가 작성되는 방식을 보면, 마치 일부러 잘못된 방식으로 일을 하려는 것 같다. 어떤 의미에서는 그렇다. 조직이라는 것이 생긴 이래로 조직의 정의적인 특성 중 하나는 개인을 교체 가능한 부품처럼 취급하는 것이다. 이는 전쟁과 같이 더 병렬화 가능한 작업에는 잘 작동한다. 대부분의 역사에서 아무리 용맹한 개별 전사들의 군대라도 잘 훈련된 직업 군인들의 군대가 이길 것이라고 믿을 수 있었다. 하지만 아이디어를 내는 것은 그리 병렬화 가능하지 않다. 그리고 프로그램은 바로 아이디어다.

조직이 개인의 천재성에 의존하는 것을 싫어한다는 것이 단순히 사실일 뿐만 아니라, 그것은 동어반복이다. 적어도 현재의 조직 개념에서는, 그렇게 하지 않는 것이 조직의 정의의 일부이다.

어쩌면 우리는 개인들의 노력을 결합하되 그들을 교체 가능하게 요구하지 않는 새로운 종류의 조직을 정의할 수 있을지도 모른다. 논쟁의 여지는 있지만 시장은 그러한 조직 형태이다. 비록 시장을 조직화가 불가능할 때 기본적으로 얻게 되는 '퇴화된 경우'로 묘사하는 것이 더 정확할 수 있지만 말이다.

아마도 우리가 할 수 있는 최선은 조직의 프로그래밍 부문이 나머지 부분과 다르게 작동하도록 만드는 것과 같은 어떤 종류의 편법일 것이다. 어쩌면 최적의 해결책은 대기업이 아이디어를 자체적으로 개발하려 하지 않고, 단순히 구매하는 것일 수도 있다. 하지만 해결책이 무엇이든 간에, 첫 번째 단계는 문제가 있다는 것을 깨닫는 것이다. "소프트웨어 회사"라는 문구 자체에 모순이 있다. 두 단어가 서로 반대 방향으로 끌어당기고 있다. 대규모 조직의 훌륭한 프로그래머는 조직과 불화할 수밖에 없다. 조직은 프로그래머가 추구하는 것을 방해하도록 설계되어 있기 때문이다.

훌륭한 프로그래머들은 어쨌든 많은 것을 해낸다. 하지만 종종 자신을 고용한 조직에 대한 사실상의 반항적인 행동을 요구한다. 프로그래머의 행동 방식이 그들이 하는 일의 요구 사항에 의해 결정된다는 것을 더 많은 사람들이 이해한다면 도움이 될 것이다. 그들이 무책임해서 다른 모든 의무를 내팽개치고 장시간 몰입하여 작업하고, 사양서를 먼저 작성하는 대신 바로 프로그래밍에 뛰어들고, 이미 작동하는 코드를 다시 작성하는 것이 아니다. 그들이 불친절해서 혼자 일하는 것을 선호하거나, 문을 열고 인사하는 사람들에게 으르렁거리는 것이 아니다. 겉보기에는 무작위적인 짜증 나는 습관들의 집합에는 단 하나의 설명이 있다. 바로 프로그램을 머릿속에 담아두는 힘이다.

이것을 이해하는 것이 대규모 조직에 도움이 되든 안 되든, 그들의 경쟁자들에게는 확실히 도움이 될 수 있다. 대기업의 가장 약한 점은 개별 프로그래머들이 훌륭한 작업을 하도록 허용하지 않는다는 것이다. 따라서 당신이 작은 스타트업이라면, 이곳이 그들을 공격할 지점이다. 하나의 거대한 두뇌로 해결해야 하는 종류의 문제들을 맡아라.

이 글의 초고를 읽어준 Sam Altman, David Greenspan, Aaron Iba, Jessica Livingston, Robert Morris, Peter Norvig, Lisa Randall, Emmett Shear, Sergei Tsarev, Stephen Wolfram에게 감사드립니다.