Intellectual Wanderlust

발로 연주한 Canarios

alankang — Fri, 23 Oct 2009 22:58:29 +0900

지난 번에 올렸던 두 곡(Baden Jazz, Recuerdos de la Alhambra)에 이어서 요번에는 17세기 스페인 춤곡인 Canarios 입니다. 제가 연주할 줄 아는 곡 중에 가장 발랄한 곡입니다 ㅎㅎ 결혼식 때 연주하다가 삑싸리 왕창 났었죠. 이번에도 물론 삑싸리는 많습니다:

OOP와 생산성 - 다형성의 문제점?

alankang — Wed, 22 Jul 2009 01:51:35 +0900

Object Oriented Programmer's Productivity 를 읽고 씁니다. 글에서 주장하는 바를 간략히 요약하자면 이렇습니다:

OOP 하면 동적 디스패치(dynamic dispatch, 대충 쉽게 말해서 다형성)가 가장 먼저 떠오르는데,
동적 디스패치는 코드를 읽기 어렵게 만들기 때문에 위험하고, OOP는 이를 장려하기 때문에 결국 문제가 된다.
OOP의 장점은 다형성에 있다기 보다는 캡슐화에 있는데, 그 이유는 구조적 프로그래밍에 비해 전역 변수를 덜 쓰도록 장려하기 때문이다.

1)번은 동의하는 바이고(OOP란 조건문을 줄이는 것 참고), 2,3번에는 동의하지 않습니다. 하나씩 따져보면

1. "동적 디스패치는 코드를 읽기 어렵게 만든다"는 주장에 대해

이 문제는 정적인 프로그램(즉 소스 코드)과 동적인 프로세스(dynamic process) 사이의 간극이 넓어지면 프로그램을 분석하기가 어려워진다는 문제의 한 가지 사례인데요(혹시 부연 설명이 필요하시면 Goto 문과 AOP, 그리고 Subtext 참고), 간단히 말해서 코드를 읽다 말고 실제로 무엇이 실행되는지 파볼(drill-down) 필요가 생기지만 않는다면 문제될 것이 없습니다. 그러니깐, 설계를 잘 하면 된다는 말입니다.

이 맥락에서 올바른 설계란... 대충 중요한 것을 꼽자면 첫째, 일반화(generalization)가 올바르게 되어 있고(즉, LSP 혹은 contract - design by contract에서 말하는 - 를 잘 지키고 있고), 둘째, 클래스 및 인스턴스의 이름이 적절히 지어져 있으며(intention revealing), 3) 해당 코드의 주변부와 추상화의 수준(level of abstraction)에 일관성이 있는 것을 말합니다.

이런 상황이라면 특정 오퍼레이션(operation)에 대한 구현 코드(method)의 내용이 무엇인지 궁금해할 일이 없습니다.

사실 동적 디스패치가 코드 읽기를 어렵게 만든다는 식의 문제 제기라면 글쓴이가 좋아하는 Haskell(함수형 언어의 일종입니다)도 문제가 되는데요, 왜냐하면 higher-order programming이라는 것 자체가 함수를 인자로 넘기거나 함수를 반환값으로 받아서 쓰는 것이고 이렇게 되면 결국 늘상 일어나는 일이 동적 디스패치거든요.

2. "OOP의 장점은 다형성에 있다기 보다는 캡슐화에 있는데, 그 이유는 구조적 프로그래밍에 비해 전역 변수를 덜 쓰도록 장려하기 때문이다"는 주장에 대해

다형성은 문제이고 캡슐화가 진정한 장점이라는 얘긴데 그럴거면 OOP라는 것이 있을 이유가 없고 그냥 모듈화 프로그래밍(modular programming)이라는 말이면 충분하겠죠.

캡슐화라는 것은 구조적 프로그래밍이나 객체지향 프로그래밍과 직교적(orthogonal)인 개념으로 보는 것이 자연스럽습니다. 대부분의 구조적 언어는 모듈화 프로그래밍을 지원하고 있고, 객체지향 언어 또한 마찬가지라서 프로그래머가 어떻게 잘 쓰느냐에 따라 캡슐화가 잘 될 수도 있고 아닐 수도 있습니다.

이를테면 코드와 데이터를 묶으려면 구조체에 함수 포인터 넣어두고, 각 함수는 첫번째 인자로 자신이 속한 구조체를 받으면(python의 self와 유사) 되는 것이죠. 구조체가 없거나 함수 포인터가 없는 언어(구조적 언어의 요건은 모두 갖추었으나 함수 포인터가 없는 언어로는... 이를테면 QBasic이나 QuickBasic이 그렇습니다)라면 prefix나 postfix로 그룹핑을 하는 관습을 만들면 그만입니다(실제로 널리 쓰이던 관습입니다. namespace 개념이 없거나 약했거든요).

뭐 구현 가능성에 대해서는 그렇다치고, 구조적 프로그래밍에 비해 객체지향 프로그래밍이 캡슐화를 좀 더 강조하고 있다는 주장도 있는데 이 또한 별 설득력이 없습니다(시스템을 모듈로 나누는 기준에 대하여 참고. 추측컨데 저자가 구조적 프로그래밍을 충분히 경험해보지 못한 것이 아닌가 싶습니다).

저자는 캡슐화의 단적인 예로 전역 변수(global variable) 문제를 들고 있는데 이에 대해서는 의존의 자기유사성을 참고하시면 좋겠습니다. 전역 변수 문제라는 것은 사실 스케일의 차이만 있을 뿐 일반적인 의존성 문제의 하나이고, 객체지향 프로그래밍을 하건 구조적 프로그래밍을 하건, 전역 변수가 있건 없건 항상 존재하는 문제이고 신경 써야 하는 문제입니다.

게다가 자바처럼 전역 변수라는 개념이 아예 없는 언어에서도 전역 변수 문제는 여전히 존재할 수 있고(전역 변수가 없지만 전역 변수 문제는 존재한다는 표현이 좀 이상하지만 뭐 맞는 말입니다) 실제로 많은 개발자들이 이 문제로 허덕이고 있습니다. 이에 대해서는 모드 없는 소스코드 중 "모드와 숨은 변수들" 섹션 참고하시기 바랍니다.

OOP 덕에 전역 변수가 많이 줄었다는 것은 아쉽게도 착각입니다. 일례로 Singleton Pattern을 보세요. 이건 사용이 장려되고 있는 (디자인 패턴이라는 탈을 쓰고 나타난) 전역 변수 아닌가요?

3. 결론 및 부연

첫째, 동적 디스패치가 일어나는 부분이 읽기 어렵다면 그건 설계/코딩을 잘못했기 때문입니다. 아무리 좋은 도구라도 쓰는 사람이 잘 쓰지 못하면 문제가 생기는거죠.

둘째, 캡슐화라는 것은 그걸 ADT(Abstract Data Type)라고 표현했건, 모듈이라고 표현했건 간에 객체지향프로그래밍과 무관하게 예전부터 있어 왔던 개념과 별 다른 점이 없습니다. 애초에 모든 (쓸모있는) 프로그래밍 언어는 조합(combination)과 추상화(abstraction) 요소를 갖추고 있는데(Structure and Interpretation of Computer Programs), 객체지향언어도 예외는 아닌 것이죠.

프로그래밍 언어로 프로그래밍 안하기

alankang — Tue, 30 Jun 2009 02:02:48 +0900

오늘의 잡생각 – 프로그래머를 읽고 씁니다:

까놓고 말해서 블로그에서 진정한 OOP가 어쩌니, SOLID가 저쩌니, 패턴이 어떠니, Separation of Concern이 저떠니하고 추상적인 썰이나 풀고 놀면서, 용어가 중요하니, 책을 쓰니마니 하는 선수들을 보면 싹수가 노란것처럼 보이는데…

딱히 저를 두고 하신 말씀이야 아니겠지만(저는 듣보잡이니깐) 제가 마침 요즘 블로그에 위와 같은 얘기들을 자주 쓰던 참이라 좀 찔리지 말입니다. 그래서 나름의 변명해명을 해보려고 합니다.

프로그래밍을 배웠으면 일단 소프트웨어를 만들어 보기는 해야겠죠. 혹은 다른 누군가에게 프로그래밍 언어를 가르칠 수도 있겠습니다. 하지만 프로그래밍 언어를 다른 재미난 용도로 쓸 수도 있습니다. 프로그래밍 언어로 사고(thinking)도 합니다.

프로그래밍 언어를 사고의 도구로 쓰겠다는 생각은 물론 제 창작물이 아닙니다. 이를테면, SICP(Structure and Interpretation of Computer Programms)는 이러한 생각을 염두에 두고 쓰여졌습니다. 이 책의 저자들은 프로그래밍을 절차적 인식론(procedural epistemology)으로 취급합니다. 자세한 인용은 Programming language as a tool of thought 페이지를 참고하세요. 김창준님도 예전에 비슷한 생각을 잠깐 언급한 적이 있죠.

남 얘기 말고 제 얘기를 해보자면, 저는 최근 1년 가까이 프로그래밍을 안하고 있습니다. 그 대신 기획을 하고 있는데, 프로그래밍을 하면서 몸에 익힌 다양한 사고 방식으로부터 많은 도움을 받고 있고, 이러한 지식을 기획에 활용하기 위해 의도적으로 연결점을 찾는 노력을 하고 있는데 (자기가 한 일을 자기가 판단하는게 좀 웃기긴 하지만) 여러가지 성과가 있다고 생각합니다. 일하면서 느끼는 바를 조금씩 정리하고 있는데, 언젠가 기회가 되면 하나씩 정리해서 블로그에 올릴 생각입니다. (항상 하는 말이지만, 누군가에게는 도움이 되겠죠)

정리하자면 이렇습니다.

프로그래밍 혹은 프로그래밍 언어를 보는 입장은 사람마다 다양할 수 있습니다. 각자의 입장에 따라 무엇을 중요한 성과로 볼 것인지가 달라지겠죠. 아주 거대한 소프트웨어를 만들어서 돈을 많이 버는 것을 중요한 성과로 생각할 수도 있는 것이고, 기술적으로 별 볼일 없는 아주 작은 소프트웨어(이를테면 Perl로 몇 줄 끄적거린 오리지널 위키)이더라도 이를 통해 사회에 지대한 공헌을 했으면(이를테면 위키피디아의 탄생) 이를 중요한 성과로 생각할 수도 있는 것이죠.

다양한 입장을 서로 존중해주면 좋겠습니다.

PS: 요즘은 Masterminds of Programming이라는 책을 읽고 있습니다. 다양한 언어의 설계자들과 인터뷰한 내용을 모아놓은 책인데, 그야말로 프로그래밍 언어를 보는 엄청나게 다양한 입장들의 향연입니다 :-) 매 페이지마다 떡밥이 주렁주렁.

IF문 안쓰기 캠페인

alankang — Mon, 29 Jun 2009 12:20:47 +0900

얼마 전에 OOP란 조건문(if)을 줄이는 것이라는 글을 썼는데요, 그 이후로 몇몇 분들이 직/간접적으로(Google Reader의 공유 기능 혹은 이메일) 재미있는 사이트를 하나 알려주셨습니다. 바로 Anti-IF Compaign 입니다. IF를 쓰지 말고 서브타입 다형성을 쓰자는 캠페인입니다. 일부 페이지에 적힌 날짜를 보니 올해 4월 쯤 만들어진 것 같습니다.

캠페인 설명(what is the anti-if compaign) 부분을 대충 요약하자면: IF-반대 캠페인의 목적은 객체지향 패러다임에 대한 의식을 고양하기 위한 것이며, 이를 통해 더 좋은 설계(flexibility, comprehensibility, testability, ability to evolve)를 할 수 있도록 하기 위함이라고 하는군요.

IF를 객체지향적 코드로 대체하는 예시도 제공하고 있는데 뭐 그냥 전형적인 replace-conditional-with-polymorphism 사례입니다.

캠페인에 참여하고 싶은 사람은 사이트에 서명을 하고 본인의 홈페이지에 배너를 걸어달라고 하는데(Kent Beck 횽아가 1등으로 서명을 했군요 ㅋ), 글쎄요... 취지는 좋으나 이름을 잘못지은 캠페인의 또다른 사례(비슷한 사례로는 개발자 좀 살려주세요 캠페인이 있죠. 이건 그래도 취지에 심하게 공감하기 때문에 배너를 달긴 달았습니다)를 보는 것 같아서 거시기 합니다.

시스템을 모듈로 나누는 기준에 대하여

alankang — Thu, 25 Jun 2009 13:15:45 +0900

이 글에서는 OOP란 조건문(if)을 줄이는 것에서 인용한 David Parnas의 논문 - On the criteria to be used in decomposing systems into modules - 을 소개/요약하고자 합니다.

이런 이야기를 별로 안 좋아하는 분들도 계신 것 같습니다만, 그래도 뭐 누군가에게는 이런 글도 도움이 되겠죠. 적어도 저는 이런 고민/공부를 통해 프로그래밍을 더 잘할 수 있게 되었고, 더 중요하게는, 생각하는 방식 자체에도 많은 긍정적 영향을 받았다고 생각합니다.

1. 소개

저자는 워낙 유명한 사람이니 설명을 생략하고 논문 자체에 대해서만 간단히 소개하겠습니다. 1972년에 CACM에 실린 논문이며, 정보 은닉(information hiding)과 계층적 구조(hierarchical structure)라는 원칙에 의거하여 시스템을 모듈화하는 것이 좋다는 제안을 담고 있습니다.

2. 요약

논문의 앞부분은 정보은닉을 설명합니다. 동일한 시스템에 대한 두 가지 모듈화 사례를 제시한 후 이 중 정보 은닉에 기반한 모듈화가 다양한 장점을 갖는다는 점을 보이고 있습니다. 여기에서 말하는 정보 은닉이란 "내부의 작동 방식에 대해 최대한 숨기는 방식으로 설계된 인터페이스 혹은 정의"를 말합니다. 이렇게 모듈화가 될 경우 다음과 같은 장점을 얻을 수 있습니다. 첫째, 각 모듈간 간섭이 최소화되기 때문에 병렬 개발이 가능해집니다. 둘째, 시스템의 구체적인 작동 방식이 개별 모듈 내부로 응집되기 때문에 변화가 생길 경우 이에 대한 여파가 최소화 됩니다(논문 내에서 직접 언급하고 있지는 않지만 ripple effect가 최소화 된다는 얘기입니다). 셋째, 전체 시스템이 아닌 각 모듈 단위만으로도 이해가능한 의미있는 단위가 됩니다.

후반부는 계층적 구조와 재활용성을 설명합니다. 정보 은닉이라는 기준에 더하여 명확한 계층 구조라는 기준까지 만족하면 하위 모듈에 대한 재활용성을 획득할 수 있다는 주장입니다. 여기에서 말하는 명확한 계층 구조란 쉽게 말해서 상위 수준의 모듈과 하위 수준의 모듈을 명확히 나누고 상위에서 하위로의 의존만 발생되는 구조를 이야기 합니다. 이렇게 할 경우 새로운 상위 수준의 모듈을 만들면서 기존의 하위 수준 모듈 중 일부를 재활용할 수 있게 되니까요. 현존하는 거의 대부분의 라이브러리/API들이 이런 식으로 재활용 됩니다.

여기에서 제안된 설계는 두 단계의 수준으로 구성되어 있지만 대부분의 소프트웨어는 여러 단계의 수준을 갖겠죠.

3. 부연

정보 은닉(information hiding)은 OOP의 고유한 특성이라기 보다 모듈화 프로그래밍(modular programming)이라는 스타일의 특성이며, OOP는 이 개념을 자연스럽게 흡수하고 있는 것입니다. 한편, 이 논문이 소개하는 방식의 계층적 구조는 재활용성을 높여주기는 하지만 제약이 있습니다. 하위 수준의 모듈만 재활용될 수 있다는 제약이죠. 상위 수준의 모듈이 재활용 되려면 하위 수준에서 상위 수준으로 올라가는 의존 관계가 필요해지는데, 이렇게 하면 순환 참조(circular dependency)가 만들어지고 결국 상위/하위 모두 독립적으로 재활용되기가 힘들어집니다.

순환 참조가 일어나지 않는 방법으로 하위 모듈에서 상위 모듈로 올라가는 의존을 만들 필요가 있게 되는 것이죠. OOP에서는 다형성을 통한 의존성 역전으로 이 문제를 해결합니다.

점심시간이 끝났네요 --; 다음에는 다형성, 의존성 역전, 상속의 관계에 대해 써보도록 하겠습니다.

OOP란 조건문(if)을 줄이는 것

alankang — Sun, 21 Jun 2009 13:48:59 +0900

OOP에 대해서, 아는 사람은 다 알만한 이야기 및 이 글에서 인용하고 있는 大山님의 글 객체지향 프로그래밍에 대한 오해와 진실 1편, 2편을 읽고 씁니다(3년 전 글입니다). 딱히 관련 글이라기 보다는 읽고 떠오르는 생각들 몇 가지 + 제가 평소에 가지고 있던 생각을 늘어 놓으려고 합니다.

OOP를 바라보는 (유일하게 올바른 관점이 아닌 다양한 관점 중) 한 가지 관점에 대해 쓰고자 합니다. 하나의 대상을 한 측면에서만 보는 것 보다는 여러 측면에서 보면 좀 더 그 대상에 대해서 잘 알 수 있을 것이라고 생각하기 때문입니다. 제가 제시하고자 하는 관점은 다음과 같습니다:

“OOP는 무엇을 제거 혹은 대체하고자 하는가?”

1. 레퍼런스와 포인터 산술연산

예를 들어 자바나 C#의 레퍼런스(reference) 개념을 살펴보죠. 레퍼런스는 보안성, 편의성, GC 효율성 등을 향상시키기 위해 기존의 포인터 개념으로부터 산술연산(arithmatic operations)을 제거하였습니다. (결과적으로 보안성, 편의성, GC 효율성 등이 향상 되었는지 아닌지에 대한 판단은 각자 알아서)

포인터는 전지전능한 주소지칭 수단인데, 사실은 전지전능한 주소지칭 수단이 없어도 모든 프로그램을 작성할 수 있다는 것을 알게 된 것이죠(성능 이슈 등을 제외한다면).

2. 구조적 프로그래밍과 GOTO

또 다른 예로, 구조적 프로그래밍은 프로그램의 흐름을 제어하는 방법 중 goto를 제거(다익스트라 식으로 표현하자면 의미있는 프로그래머 독립 좌표계 – programmer independent coordinates - 를 훼손하는 장치들을 제거)하였습니다. 구조적 프로그래밍에서는 다음 세 가지 수단만으로 모든 프로그램의 흐름 제어를 구현해냅니다:

순서(sequence) – 쉽게 말해서 코드가 위에서 아래로 실행되는 것
선택(selection) – 쉽게 말해서 if와 switch
반복(iteration) – 쉽게 말해서 while(혹은 do, until, for 등)

조건문(if)과 결합된 goto 문은 전지전능한 흐름제어 수단인데, 사실은 전지전능한 흐름제어 장치가 없어도 모든 프로그램을 작성할 수 있다는 것을 알게 된 것이죠(성능 이슈 등을 제외한다면).

3. OOP와 무엇?

드디어 본론인데요, OOP는 뭘 제거(혹은 대체)하였을까요? 혹자는 OOP가 구조적 프로그래밍을 대체한다고 말하는데 1/3 쯤 맞는 표현이라고 생각합니다. OOP는 구조적 프로그래밍의 세 가지 흐름 제어 수단(sequence, selection, iteration) 중에서 선택(selection) – 즉 if 문 – 을 제거합니다.

구조적 프로그래밍에 대한 설명에서 “조건문(if)과 결합된 goto 문은 전지전능한 흐름제어 수단”이라고 표현하였는데 이 중 goto는 제거되었으나 if는 살아남은 것이 구조적 프로그래밍이라면 if 까지도 제거하고자 하는 흐름을 OOP라고 보는 관점이 있을 수 있다는 것이죠.

오해의 소지가 있으니 잠깐 부연하자면, 모든 if를 제거해야 진정한 OOP라는 류의 주장은 아닙니다. 이에 대해서는 글 뒷부분에서 좀 더 이야기하도록 하겠습니다(진정한 OOP 따위 대체 뭔가요, 먹는거임? 우걱우걱).

그럼 조건문을 무엇으로 대체하고 있나요? 다형성(polymorphism)이죠. 그냥 다형성이라고 하면 너무 광범위하죠. 이를테면 파라메터 다형성(parametric/parameterized polymorphism)은 OOP 보다는 Generic Programming과 관련이 있습니다. OOP의 핵심이라고 하는 다형성은 특히나 서브타입 다형성(subtype polymorphism)을 말합니다. 이후에는 그냥 다형성이라고만 쓰겠습니다.

그럼 다형성이 조건문을 어떻게 대체하나요? 조건문이란 애초에 선택(selection)을 위한 것인데, 여기에서 선택이란 특정 변수의 값에 따라 이후에 실행할 코드가 달라지도록 하는 것을 말합니다. if 문에서는 조건절의 boolean 값에 따라 선택이 수행되는 것이고, 다형성에서는 메시지(message)에 담긴 파라메터(메시지를 받는 대상 개체도 파라메터로 칩시다. 파이선 self 마냥)에 따라 선택이 수행됩니다.

4. 다형성과 의존성 역전(DI – Depedency Inversion)

if를 다형성으로 대체하는 것이 정말 OOP를 특징지을만큼 중요한가요? 네, 전 그렇다고 생각합니다. 이쯤에서 밥 삼촌(Uncle Bob)을 인용해주어 (올바른) 권위에의 호소를 한 번 시도하도록 하겠습니다:

프로그램이 어떤 언어로 작성되었는지는 중요치 않습니다. 만약 의존성이 역전되어 있다면 이는 객체지향적 설계인 것입니다(It doesn't matter what language a program is written in. If its dependencies are inverted, it has an OO design).

--Robert Cecil Martin, Agile Software Development

if 얘기 하다말고 갑자기 왜 의존성 역전(DI) 떡밥이 나왔을까요? 그 전에, 애초에 의존성 역전이라고 할 때 이 역전이란 뭘 뒤집었다는 뜻일까요? David Parnas 큰형님이 지금으로부터 무려 37년 전에 쓴 논문에 답이 나옵니다:

첫째, 하위 계층의 서비스를 활용함으로써 시스템의 일부가 이득을 취했다(간결해졌다). 둘째 상위 계층을 들어내더라도 여전히 유용하고 사용 가능한 산출물(하위 계층 서비스들)이 남는다. (…중략…) 만약 하위 계층의 모듈이 상위 계층의 모듈을 사용하게끔 설계를 했다면 올바른 위계를 얻어낼 수 없었을 것이고 시스템의 일부만 들어내기가 훨씬 더 어려웠을 것이며, 계층이라는 말 자체가 의미를 잃게 될 것이다(First, parts of the system are benefited (simplified) because they use the services of lower levels. Second, we are able to cut off the upper levels and still have a usable and useful product. (..omitted...) If we had designed a system in which the "low level" modules made some use of the "high level" modules, we would not have the hierarchy, we would find it much harder to remove portions of the system, and "level" would not have much meaning in system).

--On the Criteria to be used in Decomposing Systems into Modules

시스템을 모듈화할 때 계층 간의 위계를 명확히 나누고 상위 계층이 하위 계층을 사용(즉 의존)하도록 만들어야 한다는 주장이며 이는 구조적 프로그래밍 혹은 모듈화 프로그래밍의 핵심 설계 원칙 중 하나입니다. 여기에서 상위 계층이란 좀 더 추상적인(abstract) 계층을 말하고 하위 계층이란 좀 더 구체적인(concrete) 계층을 말합니다. 그림으로 그려보면 아래와 같습니다:

모든 화살표가 위에서 아래로 내려가는 모습을 담고 있습니다. 의존성 역전이란 바로 이러한 의존관계를 뒤집는다는 의미로, 의존성 역전이 일어난 설계에서는 화살표 일부가 아래에서 위로 올라갑니다. UML로 치자면 속이 빈 삼각형 화살표(generalization 혹은 realization)로 표현합니다:

의존성 역전이 가능한 이유는 하위 계층이 상위 계층에 의존하면서도 순환 참조(circular dependency)가 일어나지 않게 만들어서 이를 통해 원래 David Parnas가 강조하던 목적(시스템의 일부를 쉽게 들어낼 수 있도록 하는 것)을 여전히 달성할 수 있게 되기 때문입니다.

순환 참조는 어떻게 끊나요? 즉, 위 그림의 속이 빈 삼각형 화살표는 언어에서 어떻게 표현될까요? 상속으로 표현합니다. 자바로 치자면 extends 혹은 implements가 되겠죠. 대표적 사례는? Observer Pattern. (다시 보니 위 그림은 별로 예쁘지 않군요. 대충 예쁜 의존성 역전의 사례를 상상해주세요)

잠깐 딴소리: 아마도 GoF 패턴책이 번역된 후로, 다른 커뮤니티는 모르겠고, 자바 개발자들 사이에서 extends는 꼬지고 implements는 좋은거라는 미신이 널리 퍼졌죠. 좀 과장하자면 구현 상속은 delegation(and/or composition)으로 대체하고 오직 타입 상속이 쵝오, 뭐 이런 얘기인데 “extends == 구현 상속”, “implements == 타입 상속”이라는 잘못된 공식이 오해의 원인이 아니었을까 추측해봅니다. 자바의 경우 “extends == 구현 상속+타입 상속”이라고 해야 맞습니다. 즉, implements이건 extends이건 타입 상속은 일어나는거죠. 단 extends를 했을 때는 구현 상속이 따라오게 되어 있는데 이 때의 문제를 잘 인지하고 해결할 수 있으면 그냥 쓰면 되는 것이죠.

이를테면 blackbox reuse vs. whitebox reuse 문제 같은 것이 있는데, 애초에 public/published 구분 잘 하고, protected 따위 안쓰고 메서드는 몽땅 public, 필드는 몽땅 private 같은 몇 가지 원칙들만 잘 지키면 문제의 소지가 크게 줄어듭니다.

다시 본론으로 돌아와서 지금까지의 얘기를 정리해보자면 이렇습니다:

OOP는 구조적 프로그래밍의 selection(if/switch)을 서브타입 다형성으로 대체합니다.
if를 서브타입 다형성으로 대체하면 하위 계층 뿐 아니라 상위 계층 까지도 더 잘 모듈화할 수 있습니다.
이러한 생각을 표현하는 말이 의존성 역전(DI) 입니다.

5. OOP의 나머지 개념들은 뭔가?

그럼 캡슐화(encapulation), 정보은닉(information hiding)은 안중요한가요? 중요합니다. 다만 OOP와 별 관련 없이 원래 있던 개념들입니다.

6. if는 다 잡아 없애야 진정한 OOP인가?

if 뿐만 아니라 switch도 다 없애야 진정한 OOP라능. 농담입니다. --;

두 가지를 이야기할 수 있겠습니다. 첫째, 진정한 OOP 아무 짝에도 쓸모 없습니다. 그런거 추구하지 마세요. 둘째, 상위 계층의 모듈화를 저해하는 if만 제거하세요. 다른 말로 바꿔서 표현하자면, 도메인 로직을 서술하기 위한 if는 남겨두세요.

7. OOP에 대하여 지금 서술한 관점이 킹왕짱인가?

저는 그렇다고 생각합니다. 하지만 “제일 좋은 관점”이랑 “완전한 관점”은 다른 것이죠. 제일 좋은 관점이라고 믿고 있기는 하지만 이 관점만으로 밀기엔 불충분하고 생각도 덜 다듬어진 것 같습니다. 따라서 여러 관점을 머리 속에 담아두고 그때그때 가져다 쓰는 식으로 생각하고 있습니다.

디자인이란 서로를 이롭게 연결하는 것

alankang — Sun, 21 Jun 2009 01:10:00 +0900

Kent Beck이 4월에 쓴 글 “Design is beneficially relating elements”를 요약 및 부연설명 해보려고 합니다. 기획자/개발자/디자이너 모두에게 이로운 글이라고 생각합니다. 앞으로 이 글에서 “디자인”이라는 용어가 나오면 기획자는 “기획”, 개발자는 “설계”, 디자이너는 “디자인”이라고 생각하고 읽으시기 바랍니다. 이 글을 써봐야지 써봐야지 하다가 이런저런 핑계로 못쓰고 있었는데 술김에 씁니다(Nature of Order 발표회 뒷풀이에서 맥주 세 잔을 마셨습니다 ㅎㅎ).

…

퍼머컬처(permaculture)라는 개념이 있습니다. 영속적인(permanent)이라는 단어와 농업(agriculture)이라는 단어를 합친 말로 “지속가능한 농법”이라는 뜻입니다. 고 노무현 대통령님이 봉하마을에 도입하셨던 오리 농법도 퍼머컬처의 사례입니다. 퍼머컬처에서는 시스템을 이루는 주요 요소들 다양한 방식으로 최대한 연결시키는 것을 중요하게 여깁니다. 예를 들어 오리 농법에서 오리의 역할은 1) 잡초방제, 2) 해충방제, 3) 양분 공급, 4) 써레질, 중경탁수, 5) 벼 자극, 6) 왕우렁이 방제와 같이 다양합니다. (고백하자면 사실 저는 써레질이 뭔지, 중경탁수가 뭔지, 왕우렁이가 뭔지 잘 모릅니다 ㅋ)

Kent Beck은 퍼머컬처의 디자인 원리를 이렇게 소개합니다:

“Design is beneficially relating elements”

이 문장은 두 가지 뜻을 지닙니다.

첫째, relating을 elements에 대한 형용사로 볼 경우 “디자인은 서로 이롭도록 연결된 요소들이다”라는 뜻이 되고 이는 곧 디자인의 결과물(product)을 뜻합니다. 디자인의 결과물은 다양한 요소들(elements), 이들 사이의 관계들(relationships), 그리고 이로 인해 발생하는 이로움들(benefits)로 구성됩니다.

둘째, relating을 동사로 볼 경우 “디자인은 요소들을 서로 이롭도록 연결하는 것이다”라는 뜻이 되고 이는 곧 디자인의 과정(process)을 뜻합니다. 디자이너는 요소들(elements)을 새로 도입하거나 제거하거나 조정합니다. 또 요소들 사이에 새로운 관계들(relationships)을 만들거나 끊거나 조정합니다. 이 과정을 통해 이로움들(benefits)을 향상시키게 됩니다.

한편, “Design is beneficially relating elements”라는 문장은 매우 추상적인데 이는 고의적인 선택입니다. 소프트웨어라는 것은 프랙탈적(fractal) 성격을 지니기 때문에(의존dependency의 자기유사성self-similarity 참고) 이를 구현(implementation), 디자인(design), 아키텍처(architecture) 등으로 명확히 구분하는 것은 오히려 여러 스케일들 사이에 존재하는 관계들에 대한 디자이너의 사고를 제약하는 결과를 가져온다는 것이죠.

여기에서 Kent Beck은 이러한 구분을 임의적(arbitrarily)이라고 표현하고 있는데 매우 적절하다고 생각합니다. 인간이 합리적이라고 생각해왔던 많은 구분 방식들이 실제로는 임의적인 경우가 많으며 대상에 대한 올바른 인식을 방해하는 경우가 많습니다. 얼마전 게임UX포럼에서 인간경험이라는 주제로 발표를 한 적이 있는데, 저는 이를테면 사용성(usability)과 오락성(playability)의 구분도 임의적인 측면이 있다고 생각합니다.

“요소들을 서로 이롭도록 연결하는 것”에 대하여 Kent Beck이 소개하는 사례는 다음과 같습니다:

소스 코드에서 두 개의 표현식(expressions)이 한 문장 안에서 연결
분산 시스템의 두 컴퓨터 사이의 연결
겉보기에 경쟁 관계에 있는 두 비즈니스 스폰서 사이를 상호이익이 되도록 연결

말 그대로 동일한 테마가 시공간에 걸쳐 여러 스케일에서 반복되고 있습니다.

이러한 연결은 공간적인 측면에서 뿐만 아니라 시간적인 측면에서도 이루어질 수 있습니다. 이를테면 처음에는 당장 필요한 수준에 맞는 요소를 도입한 후 시간이 지남에 따라 더 나은 요소로 대체하는 식으로 말이죠.

Nature of Order 발표회 후기

alankang — Sun, 21 Jun 2009 00:47:15 +0900

The Nature of Order 발표회에 다녀왔습니다. The Nature of Order는 패턴 언어의 창시자로 유명한 건축가 Christopher Alexander의 최근 저서(총 네 권으로 이루어져 있습니다)입니다.

발표회는 예정보다 30분 정도 늦게 시작했고, 예정보다 30분 정도 시간이 더 소요되어서 예정보다 1시간 정도 늦게 끝났습니다. 그리고 예정에 없던 뒷풀이(?)가 있어서 거기까지 따라갔다가 왔습니다. 에또 예정에 없던 UX recipe 모임과의 합류가 이루어지면서 예정에 없던 반가운 몇몇 분들을 뵐 수 있었습니다.

초반에는 김창준님이 Pattern Languages –> Morphogenetic Sequences –> Generative Codes로 이어지는 C.A 사상의 흐름을 간략히 설명해주셨습니다. 이 글을 참고하시면 좋겠습니다.

그 다음에는 원형 테이블에 8명씩 둘러 앉아서 두 명씩 짝을 지어 그림 그리기 놀이를 했습니다. 이름을 뭐라 할까요, generative pair drawing 정도로 하면 적당할까요? 저는 uxfactory의 황리건님과 함께 그렸는데 작품명은 “피카소의 외계인”이었습니다 ㅎㅎ

다음으로는 각 테이블 별로 발제자 분들이 자신이 정한 주제에 대해 10분씩 설명하는 형식으로 발표가 진행되었습니다. OST와 유사한 형태였습니다. 10분씩 세 번의 이터레이션이 있었기 때문에 모든 발표자의 이야기를 다 들을 수는 없었고, 저는 1) 교육, 2) 지식 습득과 커뮤니티, 3) 프로그래밍 이렇게 세 가지를 들었습니다. 각 발표를 들으면서 C.A가 주장하는 15가지 속성은 상당히 범용적이면서도 구체적이어서 여러 분야에 적용해볼 수 있는 유용한 도구가 될 수 있을 것이라는 생각을 했습니다. 특히 TDD에 대한 새로운 관점(center가 지속적으로 파생되며 서로를 보완해가는 과정으로서의 TDD)을 얻게 된 것이 큰 소득이었습니다. 이는 TDD에만 적용된다기 보다는 좀 더 넓은 함의를 지닌다고 생각합니다. 충분히 고민해볼 필요가 있다고 생각합니다.

뒷풀이 자리에서는 최근 머리속을 떠나지 않는 고민(모듈식 설계에 대하여)에 대해 이야기를 나누었는데 이에 대해서는 다음 글에서 쓰도록 하겠습니다.

[릴레이] 나의 독서론

alankang — Sat, 20 Jun 2009 16:52:37 +0900

이틀 전에 받았는데 바쁘다는 핑계로 지금에야 씁니다.

릴레이 규칙

독서란 [ ]다. 의 네모를 채우고 간단한 의견을 써주세요.
앞선 릴레이 주자를 써주시고
릴레이 받을 두 명을 지정해 주세요.
릴레이는 6월 20일까지만 지속됩니다.
기타 세칙은 릴레이의 오상 참조

릴레이 참여자 목록

릴레이는 Inuit님이 시작하셔서:

buckshot (독서는 월아이다)
고무풍선기린 (독서란 소통이다)
mahabanya (독서란 변화다)
어찌할가 (독서란 습관이다)
김젼 (독서란 심심풀이 호두다)
엘군 (독서란 삶의 기반이다)
무 (독서란 지식이다)
Oddlyenough (독서란 가랑비입니다)
마키디어(독서란 연애다)
파아랑 (독서란 새벽 3시다)
송동현 (독서란 수집이다)
Crete (독서란 겸손으로의 길이다)
피타고라스 (독서란 나를 찾아가는 여행이다)

buckshot (독서는 월아이다)
고무풍선기린 (독서란 소통이다)
류한석 (독서란 영혼의 지적 갈등을 해속하기 위한 몸부림이다)
mahabanya (독서란 변화다)
어찌할가 (독서란 습관이다)
모노피스 (독서란 사진이다)
FROSTEYe (독서란 공유다)
nnow (독서란 반성이다)
banho (독서란 나만의 향수다)
addict. (독서란 저자와 함께 머리를 맞대고 내 문제를 푸는 시간이다)
shadow-dancer (독서란 현실 도피의 수단인 동시에 현실 극복을 위한 무기다)

를 거쳐 저에게 도착했습니다.

피타고라스님, shadow-dancer님 감사합니다. 덕분에 재미있는 릴레이에 참여할 수 있게 되었습니다.

나에게 독서란 [연결짓기]이다.

저에게 독서란 다양한 분야의 책 사이에 존재하는 관련성을 찾아서 이어주는 재미난 놀이입니다.

읽은 책을 개인위키에 정리하고 관련된 내용들을 서로 연결하다 보면 섬들 사이에 다리가 놓이고 어떨 때는 섬들이 서로 합쳐져서 제법 거대한 대륙이 되기도 합니다. 특히 기대하지 못했던 관련성을 우연히 찾아냈을 때의 짜릿한 쾌감은 독서의 숨은 재미 중 하나입니다. 저는 계획 없이 그날 기분 따라 내키는대로 책을 읽기 때문에 더욱 연결짓기를 중요하게 생각합니다. 최근 목표 중 하나는 지리(공간축)와 역사(시간축)를 공부하는 것인데, 이를 통해 책들을 새로운 축으로 연결지을 수 있게 될 것이라고 믿고 있기 때문입니다.

연결 수가 늘고 연결 강도가 높아지는 과정을 통해 지식을 나의 것으로 만들 수 있다고 생각합니다. 학습의 기본은 연결과 반복이니까요.

릴레이는 종료하겠습니다.

릴레이는 6월 20일까지만 지속된다는 규칙이 있으니 릴레이를 받으실 분을 지정하지 않도록 하겠습니다.

믿음을 가지면 아이폰님은 오실거임

alankang — Tue, 09 Jun 2009 04:13:05 +0900

잘 보십쇼.

Ko,r,e,a, South

하앍하앍.

애플 야 이 ㅆㅂㄼㅈㄺㅎㅑㅏㅓ돟쟉ㅎㄱㄹㄷ,ㅏ/ㄻㅅㅎㄷㅎㄱ사ㅣ

가카, 경제를 살리려면 명텐도 접고 맹박폰을 하셔야 합니다.

진화심리학 지못미

alankang — Tue, 09 Jun 2009 00:41:23 +0900

이글루스 모벨리의 진화심리학 논란을 읽다보니 불현듯 "진화심리학을 만만하게 보도록 진화된 인류 보편적 심리 메커니즘"이 존재할지도 모른다는 생각이 듭니다. 옹호하는 쪽이건 비판하는 쪽이건.

진화심리학, C. 다윈 지못미.

에또... 특별히 성선택이 자주 언급되고 있는 점에서 R.피셔, J.M.스미스, A.자하비, D.버스, G.밀러 등도 지못미.

에또... 최근에 이보디보 읽은 기념으로다가, 종합설 이후로 찬밥 신세였던 발생학도 지못미.

니들이 고생이 많습니다.

가카께서는 왜 손가락을 다쳤나

alankang — Mon, 08 Jun 2009 19:05:16 +0900

가카께서 경례를 못한다는 지적이 많았죠. 최근에는 (거수)경례 뿐 아니라 국기에 대한 경례도 못한다는 점을 지적하며 손가락을 다치신게 아니냐는 추측도 나오고 있습니다.

그렇다면, 가케께서는 과연 왜 손가락을 다치셨을까요. 제가 좋아하는 근본원인분석(RCA)을 해본 결과 그 이유는 바로바로...

나이록 방석을 안갓다 놔서 방법을 당한 것.

깔고 안진 나이록
방석 갓다 노라
안 갓다 노면
방법 한다
방법 하면
손발리 오그라진다
갓다 노면 안한다

--방법할매

아아.. 가카..

명박혐짤 주제에 의한 변주

alankang — Thu, 04 Jun 2009 02:23:40 +0900

청와대의 ‘雨中식사’

위 혐짤을 보면서 후보시절 사진이 하나 떠올랐으니:

이명박의 손님 접대 방법.

될성부른대통령은후보때만봐도알아본다.

킨들2 사용기 #2

alankang — Sun, 31 May 2009 22:15:12 +0900

이달 초에 쓴 킨들2 사용기 #1에서 이어지는 글입니다. 킨들2를 쓰기 시작한지 거의 한 달 정도 지났고 그 동안 이런 저런 문서들도 많이 보고 책은 네 권(Learning UML 2, Designing Gestural Interfaces, Designing and Engineering Time, The Back of The Napkin) 읽었습니다. 그 사이에 알게 된 점, 느낀 점, 바뀐 점 등등을 적어보려고 합니다.

1. 킨들DX에 대한 생각

이달 초에(그러니까, 제가 킨들2를 구입한 직후에 ㅎㅎ) 킨들DX가 발표되었습니다. 주된 차이는 다음과 같습니다:

더 넓어진 화면(6 –> 9.7)과 이에 따라 더 높아진 해상도(600*800 –> 824*1200)
Native PDF 지원

그 밖에도 스토리지 용량 증가, 자동 화면 회전 등 몇 가지 기능이 추가되었으나 가장 중요한 특징은 위 두가지라고 생각합니다. 이에 따른 장점은:

인터넷의 수많은 논문들을 편하게 볼 수 있다는 것. ㅜㅠ 그리고 킨들2에서는 죽었다 깨어나도 이런 경험을 줄 수 없다는 것.

화면 해상도와 Native PDF 지원은 어찌보면 한 세트입니다. 왜냐하면 킨들2의 경우 해상도 자체가 낮기 때문에(600*800) Native PDF 지원이 된다고 하더라도 가독성이 매우 떨어지기 때문이죠. 따라서 킨들2로는 해킹을 하건 어쩌건 간에 하드웨어 제약(해상도) 때문에 원활한 PDF 지원이 불가능합니다.

반면, 단점도 있는데요:

화면을 키우면서 제품 자체도 더 크고 두꺼워져서(8*5.3*0.36 –> 10.4*7.2*0.38) 휴대성이 떨어집니다. 결정적으로 무게가 두 배(10.2 –> 18.9)나 늘어버렸습니다. 한 손으로 들기에 약간 부담스럽겠죠.

사람마다 다르겠지만 저는 장점에 비해 단점이 크다고 생각해서 그냥 킨들2에 만족하기로 했습니다. 킨들2를 최근에 구매한 사람의 경우 추가 비용을 지불하면 킨들DX로 바꿔준다고 하는데 저는 그냥 킨들2 쓸랍니다.

2. 킨들2에서 PDF 읽기

앞에서도 언급한 바와 같이 킨들2는 Native PDF 지원이 안됩니다. 아마존에서 실험적인 PDF 변환 서비스를 제공하고 있기는 하지만 예상할 수 있듯이 변환 결과가 썩 맘에 들지는 않습니다.

현재 수제(homebrew) 업데이트 파일을 이용하여 Native PDF 지원 기능을 추가하는 방법이 알려져 있는데요 자세한 방법은 이 글(Savory)를 참고하세요. 5월 31일 현재 최신 버전은 아래와 같이 작동합니다:

PDF를 documents 폴더에 복사
연결을 해제하고 몇 분 기다리면
두 개의 문서가 생깁니다. 하나는 PDF에서 텍스트와 이미지를 추출하여 eBook 형태로 변환한 문서이고 다른 하나는 아예 PDF를 이미지로 랜더링한 결과를 저장한 문서(코믹북 포멧)입니다.

기존 방식(PDF를 이메일로 전송 –> 몇 분 기다리면 변환된 파일의 링크를 담고 있는 답장이 도착 –> 변환된 파일을 다운로드 받은 후 킨들의 documents 폴더에 복사)에 비해 훨씬 편하죠. 그냥 복사하고 기다리기만 하면 되니까.

하지면 몇 가지 단점이 있습니다.

eBook 형태로 변환된 문서의 품질이 그다지 좋지 않습니다. 예를 들어 2단으로 구성된 문서(대부분의 논문들)의 경우 단 인식을 제대로 못하고 좌/우 문장을 혼합해버리는 경우가 있습니다. 이렇게 되면 거의 읽을 수가 없습니다 ㅜㅠ
이미지를 추출하여 만들어진 코믹북 포멧은 일단 형태가 완벽해서 좋습니다. PDF를 이미지로 랜더링한 것이기 때문이죠. 하지만 그렇기 때문에 발생하는 단점: 1) 밑줄을 그을 수가 없고, 2) 킨들2의 낮은 해상도 때문에 어지간한 PDF는 확대 없이 읽을 수 없으며, 3) 킨들2에 내장된 코믹북 뷰어에 아직 버그가 많아서 이미지를 확대/축소하다보면 소프트웨어가 멈춰버릴 때가 있습니다.

단점을 잔득 써 놓으니 무진장 후진 것 같은데요, 막상 써보면 또 그렇지만도 않습니다. 다음은 뽐뿌용 화면:

멋지죠? 코믹북 뷰어의 화면 회전 기능을 이용하면 아래와 같이 볼 수도 있습니다:

하악. (출처는 http://blog.fsck.com/2009/04/savory-screenshots.html)

3. 숨은 기능들

Home 화면에서 Al+Shift+M 을 누르면 지뢰찾기(Minesweeper)가 실행됩니다. (대체 왜!?)
글 읽는 중에 Alt+Shift+숫자키를 누르면 줄간격이 바뀝니다. 기본 줄간격은 3.
만화책보기: USB 연결 후 pictures 폴더를 만들고 그 밑에 폴더 하나 만들고 그림 파일(jpg, png, gif)을 복사하면 됩니다. Home 화면에서 Alt+Z를 눌러서 새로고침을 해보면 pictures 폴더 밑에 만들어둔 하위 폴더 이름에 해당하는 책이 나타날거예요.
Alt+Shift+G를 누르면 스크린샷이 생성됩니다.

4. 기타

전자책 구매: 지난 포스트에서는 O’Reilly에서도 킨들용 전자책 구매가 가능하다고 알려드렸는데요, 목록이 하나 추가되었습니다 - 바로바로 http://www.pragprog.com. 프로그래머들 사이에서 유명한 출판사죠. 특히 Beta-book을 볼 수 있어서 좋을 것 같습니다. 근데 전 아직 여기서 산 책이 없어요. 요즘은 프로그래밍 보다는 다른 쪽에 관심이 더 많아져서요….

악세서리: 지난 포스트에서 킨들 가죽 케이스와 독서용 라이트가 마음에 안든다고 말씀드렸었죠? 이를 대체할 제품을 계속 찾고 있는데, 제법 괜찮아 보이는 놈들을 찾았습니다.

이렇게 생긴 놈이고요, 좌측에 붙은 하얀 것은 독서용 라이트이고, 별매이며, 올 여름에 출시될 예정입니다:

출처는 http://www.buymedge.com/p_products.html. 하악

5. 한 달 사용 후의 느낌

한줄 요약: 제가 산 전자제품 중 컴퓨터 다음으로 유용하게 쓰이고 있습니다.

게임UX포럼 발표자료 - 인간경험

alankang — Wed, 27 May 2009 23:14:21 +0900

5월 22일에 홍익대학교 디자인혁신센터에서 게임 UX 포럼 2009가 있었습니다. 저는 “인간 경험(Human Experience)”이라는 주제로 발표를 했었는데요, 늦었지만 발표 자료를 올립니다. 각 페이지에 관련 자료에 대한 링크를 적절히 달았고, 문서 제일 끝에 “기타 참고자료”를 추가하였습니다.

Human Experience.pptx

나름대로 열심히 준비하긴 했는데 공부하시는 분들이나 실무하시는 분들께 얼마나 도움이 됐을지는 알 수 없네요.