게으른 프로그래머의 힘 "혁신의 시작은 불평불만에서"

열심히 일하는 것이 미덕이라고 말하는 사람은 프로그래머를 만나 본 적이 없는 사람이다. 그렇다. 열심히 도랑을 파는 사람은 몽상을 하는 사람보다 더 긴 도랑을 파며 쟁기를 사용하는 농부는 하늘만 쳐다보는 사람보다 더 많은 곡식을 얻는다. 하지만 프로그래밍은 다르다. 이마의 땀과 사용자 만족 사이에는 선형적인 관계가 존재하지 않는다.

때로는 프로그래머가 밤샘 근무하는 것이 도움이 될 때도 있지만, 프로그래머는 똑똑하고 느긋한 것이 더 나은 경우가 많다. "열심히 일하고 겸손하라"는 격언을 무시하는 코드 개발자들은 종종 놀라운 성과를 올리며, 그 모든 것이 너무 열심히 일하지 않도록 주의하기 때문이다. 진정한 천재는 자신의 일을 컴퓨터에 떠넘겨 절대적인 최소한만 처리하는 방법을 찾는다. 어쨌든 컴퓨터가 작업을 하도록 하는 것이 진정한 컴퓨터 프로그래머의 일이다.

Credit: TRF_Mr_Hyde via Flickr

여기 느긋한 프로그램의 힘을 입증하는 13가지 기법과 툴이 있다. 다음 번에 상사가 소매를 걷어 붙이고 콘솔을 잡을 때라고 말한다면 수면실로 들어가자.

느긋한 계산법
한 똑똑한 프로그래머가 어느 순간 자신의 소프트웨어가 식의 모든 부분을 성실하게 계산하지 않는다면 더욱 빠르게 실행될 것임을 깨달았다. “필요할 때 호출”이라고도 부르는 이 기능은 이제 하스켈(Haskell), F#, 파이썬 3.0 같은 프로그래밍 언어의 공식적인 일부가 되었다.

가장 간단한 예는 이 전략을 활용한 널 포인터 확인 작업이다. 이 스테이트먼트(Statement)에서 계산 루틴을 시작하기 전에 객체 x가 널이 아닌지 확인한다.

if (x && x.calculation()) then …

x의 존재를 시험하면 충돌이 방지된다. 더욱 정교한 예에서 느긋한 계산법으로 계산 트리(를 쳐낼 수 있는 시점을 파악하기 위해 미리 예측함으로써 결국 버려질 끝없는 양의 계산을 피할 수 있다. 처음에 간단한 시험을 실시하면 나중에 방대한 양의 계산 사이클을 줄일 수 있다. 데이터 구조가 일부 정수론 예제에서와 마찬가지로 잠재적으로 무한하다면 느긋한 계산법을 통해 프로그램이 실질적으로 끝낼 수 있다.

이 기법은 해스켈 같은 함수형 언어의 속도를 높이는 데만 유용한 것이 아니다. 스마트한 프로그래머는 극히 일부만 사용하는 값을 계산하는데 몇 시간을 보내지 않는다. 누군가 사용하고 싶을 때만 계산을 실행하는 느긋한 스위치를 추가할 것이다. 이럴 때는 최소량의 작업만 하는 것이 옳다.

캐싱(Caching)
왜 같은 말을 반복해야 할까? 웹 프로그래밍을 하는 사람이라면 누구나 사이트에 방문하는 모든 사람에게 같은 말을 반복해야 한다는 사실을 알고 있다. 캐싱이 해답이며, 이는 웹사이트뿐만이 아니다. 같은 문제를 다시 계산하는 모든 코드는 정답의 사본을 유지해 속도를 높일 수 있다.

꼭 최종 정답일 필요는 없다. 복잡한 캐시는 문제의 여러 부분에 대해 부분적인 답을 유지할 수 있다. 어떤 부분에서 다시 계산해야 하는 경우 다시 할 필요가 없는 부분의 캐시를 활용할 수 있다. 예를 들어, 웹 페이지를 모은 웹사이트는 페이지의 다양한 부분의 블록을 캐시 처리한 후 블록에서 페이지 전체를 구성하는 경우가 많다.

정말로 게으른 사람들은 프로그래머에게 캐싱이 더 많은 작업을 필요로 한다고 불평할 수도 있다. 정답을 찾는 코드를 완성한 후에는 정답의 캐시를 유지하기 위해 그 위에 다른 계층을 작성해야 한다. 이 추가적인 계층 이야기는 맞을 수 있지만 줄일 수 있는 다른 작업은 잊고 있는 것이다. 좋은 캐시는 추가 워크로드를 처리하기 위해 서버 팜을 확장하는 모든 작업을 줄일 수 있다. 확장은 캐싱 코드를 작성하는 것보다 작업이 더 많을 때가 많다.

모든 것을 한 번만 지정하자.
필자가 프로그래밍에 관해 배운 가장 중요한 규칙은 각 상수를 코드에 한 번씩만 작성해야 한다는 점이다. 소프트웨어가 페이지 주변에 1인치 여백을 두도록 지정하는 경우 1의 값은 상수의 정의에 한 번만 나타나야 한다. 그리고 그 상수를 다른 모든 곳에서 사용한다.

이런 단순하고 조직화된 게으름은 그만한 가치가 있다. 여백을 1.5인치로 늘리는 등 값을 변경하고 싶다면 코드를 한 번만 변경해야 한다.

또한 상수의 이름에 약간의 힌트를 주어 여백 값에 MarginSizeInInches 같은 이름을 붙일 수 있다. 이를 통해 별도의 주석을 작성하는 문제를 줄일 수 있고, 이 주석형 상수는 코드 전반에서 해당 상수를 따라 다닌다.

물론 상수 이름이 길면 입력량이 더 많아지지만 대부분의 프로그래밍 편집기는 자동 완성을 제공하기 때문에 더 많은 작업을 줄일 수 있다.

프레임워크 : 궁극의 지름길
한 프로젝트에서 고객사 임원이 새로운 웹사이트를 원했기 때문에 필자는 웹사이트를 만든 후 그에게 워드프레스(WordPress)를 사용했다고 말하는 실수를 범했다. 큰 실수였다. 그의 친구가 골프를 치던 중 그에게 워드프레스는 블로그를 위한 것이며, 브로셔웨어(Brochureware)가 될 것이라고 말했다. 필자가 바보였을까?

결국 이 임원은 CFO를 괴롭혀 전문적인 웹사이트를 위해 5,000달러를 할당하도록 했다. 결과물은 보기 좋았으며 매우 매끄럽게 작동했다. 왜냐하면 내부가 모두 워드프레스로 구성되어 있었기 때문이다. 5,000달러를 청구한 업체는 기초로 무엇을 사용했는지 언급하지 않을 만큼 충분히 스마트했다.

어떤 사람들은 사람들이 에베레스트산을 오르는 것과 같은 이유로 커스텀 코드를 좋아한다. 그들은 얼마의 비용이 발생하든 스스로 하는 것을 좋아한다. 스마트한 프로그래머는 워드프레스나 드루팔(Drupal) 같은 좋은 오픈소스 프레임워크를 다운로드하고 거인의 어깨에 편승한다. 새로운 코드를 작성하는 경우에도 몇 줄이 되지 않는다.

자신만의 코드를 작성하느라 땀을 흐리는 것이 큰 실수인 경우가 많다. 그리고 프레임워크의 오픈소스 코드는 수천, 최소 수백 명의 사람들이 시험해 본 것이다. 항상 이상적이지는 않지만 100미터 달리기를 99미터 선에서 시작하는 것과 같다. 또한 코드를 시험하고 버그 보고서 또는 수정사항을 업로드하면 다른 모든 사람이 설치할 때 도움을 받는다.

자동화 : 역사상 최고
일부 C 성애자들은 여전히 자신만의 메모리를 맬록(malloc)으로 작성했다가 완성되었다고 생각할 때 풀어준다. 이들의 관점에서 참조 계수와 가비지 컬렉션은 약골들을 위한 것이다. 물론 존 헨리(John Henry)처럼 여전히 곡괭이를 사용하는 광부들이 있을 수 있다.

프로그래밍 언어가 발달해서 좋은 점은 자동화이며, 툴은 그 어느 때보다도 발전했다. 메모리 관리, 형식 검사, 병렬 처리는 자동 툴로 재창조되어 프로그래머들이 스스로 처리하던 모든 지저분한 잡일을 대체한다.

게으른 프로그래머는 이런 툴을 거부하지 않는다. 자동화 툴은 모든 결점에도 불구하고 여전히 평균적인 인간보다는 낫다는 사실을 알고 있기 때문이다. 물론 매우 똑똑한 해커는 추가적인 시간을 들이고 미치도록 빠른 예술품을 만들 수 있지만 시스템의 가장 중요한 부분의 내부 루프에만 해당하는 이야기이다. 나머지는 일반적인 코드를 대량으로 찍어내고 자동화된 툴이 최악의 실수를 막아주도록 하는 것이 낫다.

데브옵스(DevOps) : 의인화된 게으름
어떤 사람들은 코드를 최신 상태로 유지하고 서버를 구동하라는 사용 지침을 작성하는 스크립트 작성자를 비웃는다. 파일의 압축을 해제하여 디렉터리에 복사하는 것이 뭐가 그리 어려울까?

물론 대부분의 관리 작업은 그리 어렵지 않으며, 대부분의 보편적인 유닉스 명령은 두 글자로 이루어져 있지만 요점을 놓칠 때가 있다. 느긋함을 유지하고 배치 및 유지보수를 자동화하는 것의 목적은 빠르게 그리고 무엇보다도 일관되게 처리하도록 하는 것이다. 야간 교대조도 아침 8시 팀과 동일하게 작업을 처리하며 커피를 마셨는지 여부는 상관이 없다.

자동화는 엄격함과 안정성을 제공한다. 물론 데브옵스팀은 crontab을 실행시킬 때 버튼조차 누르지 않는 모습으로 뚱뚱하고 게을러 보이지만, 모든 것이 더욱 매끄럽게 진행된다. 인간이 루프에서 벗어날 때만큼 실수가 많을 때가 없다.

코드 재사용
바보나 처음부터 시작한다. 사실 오늘 필자는 여름에 작성한 코드 중 다섯 줄을 변경하고 다시 실행시켰다. 오 예. 다시 동작할 기회를 기다리면서 코드 저장소에서 기다리고 있었다.

스마트한 개발자는 가능한 자주 코드를 재사용한다. 이것이 오픈소스 움직임의 주된 목표 중 하나였다. 자유가 아니라 느긋함이었다. 우리가 우리의 코드를 재사용하면 엄청난 작업 시간을 절약할 수 있다.

유연한 코드
필자는 프로그래밍을 시작하기 전에 낮잠 자는 것을 좋아한다. 완전히 꿈나라에 빠지는 것은 아니지만 잠깐의 외도로 코드의 모든 기능을 상상할 시간을 확보한다. 필자가 자는 것처럼 보이지만 코드를 가능한 유연하게 만드는 방법을 계획하고 있는 것이다.

이런 느긋함은 언제나 도움이 된다. 일반적으로 좋은 프로그래머는 미래에 파라미터 또는 세부사항을 변경할 필요가 있을 때를 대비하며 자신의 코드에 유연함을 적용하려 노력한다. 회의론자들은 유연함을 추가하면 코드가 더 길어질 수 있다고 불평한다. 그들은 종종 근시안적인 지름길을 택한다. 더 많은 파라미터를 추가하고 절차를 분리하여 유연성을 추가한다고 해서 그렇게 많은 시간이 소요되는 것은 아니다. 그렇다. 라인이 추가되고 파일 크기가 커지지만 누군가 코드를 변경하고 싶을 때 이런 추가적인 키 클릭은 언제나 도움이 된다.

핵심은 코드와 아키텍처를 충분히 잘 이해하여 유연성을 추가해야 할 때를 아는 것이다. 이를 본능적으로 알 수 있게 되면 느긋하면서도 효율적일 수 있는 방법을 얻게 된다. 그리고 일반적으로 낮잠이 도움이 된다.

문서화는 문제를 줄인다.
글쓰기는 어려운 일이며 작가는 자신의 능력을 절대로 충분히 인정하지 않는다는 사실은 잘 알려져 있지만, 프로그래머는 느긋함에 의해서 글을 쓴다. 프로그래머는 코드에 관한 문서를 작성하여 다른 사람들이 성가시지 않도록 한다. 바보의 바다에서 질문을 재치 있게 받아 넘기고 싶은 생각이 없기 때문에 스위치의 기능에 관해 설명하는 페이지를 작성한다. 물론 명확하고 정확하게 쓰려면 좀 더 많은 작업이 필요하지만 장기적으로 사람들이 자신을 귀찮게 하지 않도록 예방할 수 있다.

희박한 주석
물론, 주석 작성의 경우 적을수록 좋다. 그렇다. 자신이 좋아하는 인간 언어에서 몇 단어를 섞어 컴퓨터 언어를 이해하기 쉽도록 해야 한다. 사실 계약서에는 주석이 없는 경우 대금을 지불하지 않는 요건이 포함되어 있는 경우가 많다.

하지만 주석을 느긋하게 작성하려면 직관적인 논리에 기초하여 깔끔하고 단순한 코드를 작성해야 한다. 물론 이상하거나 이해하기 어려운 것을 작성한다면 자신의 천재성을 설명하는 메모를 남긴다. 하지만 정말로 이상하거나 이해하기 어려운 것을 작성해야 할까? 최고의 해결책은 약간의 낮잠 시간을 통해 매우 깔끔한 아키텍처를 고민하는 것이다. 그러면 많은 주석을 작성하거나 업데이트에 시간을 보낼 필요가 없다.

앞서 언급한 상수 방법과 마찬가지로 변수의 이름이 길면 코드에 문서화를 혼합한다. 이 문서화는 선언에 첨부될 뿐인 주석과는 달리 변수가 사용되는 모든 곳에 따라 다닌다.

자동화된 테스트
몇 번의 키 입력으로 놀라운 코드를 작성할 때 누가 이를 두 번 세 번 확인해야 할까? 그리고 새로운 코드가 기존의 코드와 충돌하지 않는지 확인할 수 있는 사람은 누구일까? 코드가 작동하는지 자동으로 확인하기 위한 느긋한 프로그래머의 뜻밖의 선물인 단위 테스트를 실시한다.

어떤 사람들은 썬이 자바를 개발할 때 가장 잘한 일이 수 백 개의 단위 테스트를 구축한 일이라고 말한다. 소프트웨어도 멋지지만 단위 테스트는 소프트웨어가 예측 가능한 방식으로 동작하도록 한다.

자동화된 메타툴(Metatool)
가비지 컬렉션 같은 자동화된 관리 툴뿐만이 아니다. 퍼펫(Puppet)이나 쉐프(Chef) 같은 자동화된 데브옵스 툴만도 아니다. 모든 관리 작업을 하나의 거대한 시스템으로 통합하는 거대한 메타툴이 존재한다. 허드슨 & 젠킨스(Hudson and Jenkins)의 로고는 얼빠진 집사 만화 캐릭터로 더치 커피 한 잔을 즐기는 동안 모든 쓸모 없는 코드 작업을 정리하기 위해 개발된 완벽한 상징이다.

일단 코드를 확인하면 자동화된 메타툴 시스템이 단위 테스트 실행, 코드 백업, 배치 등 다른 모든 작업을 처리한다. 게으른 사람을 위한 궁극의 비서와도 같으며, 이 때문에 이런 소위 말하는 지속 통합 툴이 프로그래머를 위한 궁극의 비서인 것이다.

컴파일러(Compiler)
우리는 많은 기본적인 툴을 처음부터 당연하다는 듯이 느긋한 사람을 위한 발명품으로써 여겼다. 컴파일러 개발자가 아니었다면 우리는 여전히 기계 연산 코드와 씨름하면서 그 중간값을 레지스터 2 또는 3에 넣어 두었는지 기억하기 위해 애를 쓰고 있을 것이다. 종이 테이프 또는 자기 테이프 등 대용량 저장소 툴의 발명가가 없었다면, 조명과 스위치가 달린 전면 패널을 통해 이런 값들을 활용하고 있었을 것이다. 영화에서는 멋져 보이지만 사용하기는 쉽지 않다.

컴퓨팅의 거의 모든 부분의 목적이 새로운 일련의 툴을 개발하여 우리의 삶을 좀 더 편리하게 하는 것이었다. 거의 모든 툴 또는 앱이 불평 불만에서 시작되었다. 인터넷의 시작부터 스냅챗(Snapchat)까지 오랜 시간이 걸렸지만 그 한 걸음 한 걸음이 느긋함 속에서 누리는 간단한 연습이었다. 몇 년이 지나면 아예 키보드 없이도 프로그래밍이 가능할지 모른다.