2016.10.04

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

Peter Wayner | InfoWorld

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

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


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달러를 청구한 업체는 기초로 무엇을 사용했는지 언급하지 않을 만큼 충분히 스마트했다.
 




2016.10.04

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

Peter Wayner | InfoWorld

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

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


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달러를 청구한 업체는 기초로 무엇을 사용했는지 언급하지 않을 만큼 충분히 스마트했다.
 


X