디자인과 연구

2003년 1월

(이 글은 2002년 가을 NEPLS 회의 기조연설에서 발췌한 것입니다.)

이 나라를 방문하는 사람들은 미국인들이 대화를 시작할 때 종종 "무슨 일을 하세요?"라고 묻는 것에 놀라곤 합니다. 저는 이 질문을 한 번도 좋아한 적이 없습니다. 깔끔하게 대답할 수 있었던 적도 거의 없었습니다. 하지만 드디어 문제를 해결했다고 생각합니다. 이제 누군가 저에게 무슨 일을 하냐고 물으면, 저는 그들의 눈을 똑바로 쳐다보며 "저는 새로운 Lisp 방언을 디자인하고 있습니다"라고 말합니다. 이 질문을 좋아하지 않는 모든 분들께 이 답변을 추천합니다. 대화는 즉시 다른 주제로 바뀔 것입니다.

저는 제가 프로그래밍 언어에 대한 연구를 하고 있다고 생각하지 않습니다. 저는 단지 건물이나 의자, 새로운 서체를 디자인하는 것과 같은 방식으로 언어를 디자인하고 있을 뿐입니다. 저는 새로운 것을 발견하려 하지 않습니다. 저는 그저 프로그래밍하기 좋은 언어를 만들고 싶을 뿐입니다. 어떤 면에서는 이러한 가정이 삶을 훨씬 더 쉽게 만듭니다.

디자인과 연구의 차이는 새로움 대 좋음의 문제인 것 같습니다. 디자인은 새로울 필요는 없지만, 좋아야 합니다. 연구는 좋을 필요는 없지만, 새로워야 합니다. 저는 이 두 길이 정상에서 수렴한다고 생각합니다. 최고의 디자인은 새로운 아이디어를 사용하여 이전의 것을 능가하고, 최고의 연구는 새롭을 뿐만 아니라 실제로 해결할 가치가 있는 문제를 해결합니다. 그래서 궁극적으로 우리는 같은 목적지를 향해 가고 있지만, 단지 다른 방향에서 접근하고 있을 뿐입니다.

오늘 제가 이야기할 내용은 목표물이 뒤에서 어떻게 보이는지입니다. 프로그래밍 언어를 연구 주제 대신 디자인 문제로 다룰 때 무엇을 다르게 해야 할까요?

가장 큰 차이점은 사용자에 더 집중한다는 것입니다. 디자인은 '이것은 누구를 위한 것이며, 그들은 이것으로부터 무엇을 필요로 하는가?'라는 질문으로 시작합니다. 예를 들어, 좋은 건축가는 자신이 만든 디자인을 사용자에게 강요하는 방식으로 시작하지 않고, 의도된 사용자를 연구하고 그들이 무엇을 필요로 하는지 파악하는 방식으로 시작합니다.

제가 "그들이 필요로 하는 것"이라고 말했지, "그들이 원하는 것"이라고 말하지 않았다는 점에 주목하십시오. 디자이너로 일하는 것이 일종의 즉석 요리사처럼 고객이 말하는 대로 무엇이든 만드는 것을 의미한다는 인상을 주고 싶지 않습니다. 이것은 예술 분야마다 다르지만, 저는 고객이 말하는 대로 정확히 만드는 사람들이 최고의 작업을 하는 분야는 없다고 생각합니다.

고객은 좋은 디자인의 척도가 사용자에게 얼마나 잘 작동하는지에 있다는 의미에서 항상 옳습니다. 만약 모든 사람을 지루하게 만드는 소설을 만들거나, 앉기 끔찍하게 불편한 의자를 만든다면, 당신은 형편없는 일을 한 것입니다. 그 소설이나 의자가 가장 진보된 이론적 원칙에 따라 디자인되었다고 말하는 것은 변명이 될 수 없습니다.

그럼에도 불구하고, 사용자에게 작동하는 것을 만든다는 것이 단순히 사용자가 말하는 것을 만든다는 의미는 아닙니다. 사용자들은 모든 선택지를 알지 못하며, 종종 자신이 진정으로 원하는 것에 대해 착각합니다.

이 역설에 대한 답은, 사용자를 위해 디자인해야 하지만, 사용자가 단순히 원한다고 말하는 것이 아니라 사용자가 필요로 하는 것을 디자인해야 한다는 것입니다. 의사가 되는 것와 매우 유사합니다. 환자의 증상만 치료할 수는 없습니다. 환자가 증상을 말하면, 당신은 그에게 실제로 무엇이 잘못되었는지 파악하고 그것을 치료해야 합니다.

사용자에 대한 이러한 집중은 좋은 디자인의 대부분의 실제 관행이 파생될 수 있는 일종의 공리이며, 대부분의 디자인 문제가 이 주변에 집중됩니다.

좋은 디자인이 사용자가 필요로 하는 것을 해야 한다면, 사용자는 누구일까요? 제가 디자인이 사용자를 위한 것이어야 한다고 말할 때, 좋은 디자인이 어떤 종류의 최저 공통 분모를 목표로 한다는 것을 의미하지는 않습니다. 당신은 원하는 어떤 사용자 그룹이든 선택할 수 있습니다. 예를 들어, 도구를 디자인한다면, 초보자부터 전문가까지 누구를 위해서든 디자인할 수 있으며, 한 그룹에게 좋은 디자인이 다른 그룹에게는 나쁠 수 있습니다. 요점은, 어떤 사용자 그룹을 선택해야 한다는 것입니다. 저는 어떤 의도된 사용자를 참조하지 않고는 좋은 디자인이나 나쁜 디자인에 대해 이야기할 수 없다고 생각합니다.

의도된 사용자에 디자이너 자신이 포함될 때 가장 좋은 디자인을 얻을 가능성이 높습니다. 자신을 포함하지 않는 그룹을 위해 무언가를 디자인할 때, 그것은 당신보다 덜 세련된 사람들을 위한 것이지, 더 세련된 사람들을 위한 것이 아닌 경향이 있습니다.

그것은 문제입니다. 왜냐하면 사용자를 아무리 자비롭게 내려다본다 해도, 그것은 필연적으로 디자이너를 타락시키는 것 같기 때문입니다. 저는 미국에서 공공 주택 단지 중 자신이 그곳에 살 것이라고 예상한 건축가가 디자인한 곳은 거의 없을 것이라고 생각합니다. 프로그래밍 언어에서도 같은 것을 볼 수 있습니다. C, Lisp, Smalltalk는 자신들의 디자이너가 사용하기 위해 만들어졌습니다. Cobol, Ada, Java는 다른 사람들이 사용하기 위해 만들어졌습니다.

만약 당신이 바보들을 위해 무언가를 디자인하고 있다고 생각한다면, 당신은 바보들을 위해서도 좋은 것을 디자인하고 있지 않을 가능성이 높습니다.

가장 세련된 사용자를 위해 무언가를 디자인하더라도, 당신은 여전히 인간을 위해 디자인하고 있는 것입니다. 연구에서는 다릅니다. 수학에서는 인간이 이해하기 쉽기 때문에 추상화를 선택하는 것이 아니라, 증명을 더 짧게 만드는 것을 선택합니다. 저는 이것이 일반적으로 과학에서도 마찬가지라고 생각합니다. 과학적 아이디어는 인체공학적일 필요가 없습니다.

예술 분야에서는 상황이 매우 다릅니다. 디자인은 전적으로 사람에 관한 것입니다. 인체는 이상한 것이지만, 의자를 디자인할 때는 그것을 위해 디자인하는 것이며, 피할 수 있는 방법이 없습니다. 모든 예술은 인간의 관심사와 한계에 영합해야 합니다. 예를 들어, 회화에서는 다른 모든 것이 동일하다면 사람이 있는 그림이 없는 그림보다 더 흥미로울 것입니다. 르네상스의 위대한 그림들이 모두 사람들로 가득 차 있었던 것은 단순히 역사적 우연이 아닙니다. 만약 그렇지 않았다면, 회화는 지금과 같은 명성을 얻지 못했을 것입니다.

좋든 싫든, 프로그래밍 언어도 사람을 위한 것이며, 저는 인간의 뇌가 인체만큼이나 울퉁불퉁하고 특이하다고 생각합니다. 어떤 아이디어는 사람들이 이해하기 쉽고 어떤 아이디어는 그렇지 않습니다. 예를 들어, 우리는 세부 사항을 처리하는 능력이 매우 제한적인 것 같습니다. 바로 이 사실 때문에 프로그래밍 언어가 애초에 좋은 아이디어가 된 것입니다. 만약 우리가 세부 사항을 처리할 수 있었다면, 우리는 그냥 기계어로 프로그래밍할 수 있었을 것입니다.

또한, 언어는 주로 완성된 프로그램을 위한 형태가 아니라, 프로그램이 개발되어야 하는 수단이라는 점을 기억하십시오. 예술 분야의 누구라도 두 상황에 대해 다른 매체를 원할 수 있다고 말할 수 있을 것입니다. 예를 들어, 대리석은 완성된 아이디어를 위한 멋지고 내구성 있는 매체이지만, 새로운 아이디어를 개발하기에는 절망적으로 유연하지 못한 매체입니다.

프로그램은 증명과 마찬가지로, 과거에 잘못된 시작이 사방으로 뻗어나갔던 나무의 가지치기된 버전입니다. 따라서 언어의 시험은 단순히 완성된 프로그램이 그 안에서 얼마나 깔끔하게 보이는지가 아니라, 완성된 프로그램으로 가는 경로가 얼마나 깔끔했는지입니다. 우아한 완성 프로그램을 제공하는 디자인 선택이 우아한 디자인 프로세스를 제공하지 않을 수도 있습니다. 예를 들어, 저는 중첩된 백쿼트로 가득 찬 몇 개의 매크로 정의 매크로를 작성했는데, 지금은 작은 보석처럼 보이지만, 그것들을 작성하는 데는 몇 시간 동안 가장 추악한 시행착오를 겪었고, 솔직히 말해서, 저는 아직도 그것들이 정확한지 완전히 확신하지 못합니다.

우리는 종종 언어의 시험이 완성된 프로그램이 그 안에서 얼마나 잘 보이는지에 달린 것처럼 행동합니다. 같은 프로그램이 두 가지 언어로 작성되었을 때, 한 버전이 훨씬 짧은 것을 보면 매우 설득력 있어 보입니다. 예술의 방향에서 문제에 접근할 때, 이러한 종류의 시험에 의존할 가능성이 적습니다. 대리석과 같은 프로그래밍 언어로 끝나고 싶지 않을 것입니다.

예를 들어, 소프트웨어 개발에서 Lisp에서 읽기-평가-출력 루프(read-eval-print loop)라고 불리는 대화형 최상위 레벨(toplevel)을 갖는 것은 엄청난 이점입니다. 그리고 이것을 갖게 되면 언어의 디자인에 실제적인 영향을 미칩니다. 예를 들어, 변수를 사용하기 전에 선언해야 하는 언어에서는 잘 작동하지 않을 것입니다. 최상위 레벨에 표현식을 입력할 때, x에 어떤 값을 설정한 다음 x에 대한 작업을 시작할 수 있기를 원합니다. x의 타입을 먼저 선언해야 하는 것을 원하지 않습니다. 당신은 두 전제 중 하나에 이의를 제기할 수 있지만, 만약 언어가 편리하려면 최상위 레벨을 가져야 하고, 필수적인 타입 선언이 최상위 레벨과 호환되지 않는다면, 타입 선언을 필수로 하는 어떤 언어도 프로그래밍하기 편리할 수 없을 것입니다.

실제로 좋은 디자인을 얻으려면 사용자에게 가까이 다가가고, 가까이 머물러야 합니다. 특히 초기에는 실제 사용자에게 아이디어를 끊임없이 조정해야 합니다. 제인 오스틴의 소설이 그렇게 좋은 이유 중 하나는 그녀가 가족에게 소설을 소리 내어 읽어주었기 때문입니다. 그래서 그녀는 자기만족적인 예술적인 풍경 묘사나 허세 부리는 철학적 사변에 빠지지 않습니다. (철학은 그 안에 있지만, 라벨처럼 붙여진 것이 아니라 이야기에 녹아 있습니다.) 일반적인 "문학" 소설을 펼쳐서 자신이 쓴 것이라고 친구들에게 소리 내어 읽어준다고 상상해 보면, 그런 종류의 것이 독자에게 얼마나 부담스러운 일인지 너무나도 절실히 느낄 것입니다.

소프트웨어 세계에서 이 아이디어는 Worse is Better로 알려져 있습니다. 사실, Worse is Better 개념에는 여러 아이디어가 혼합되어 있어서 사람들이 Worse가 실제로 Better인지 아닌지에 대해 여전히 논쟁하고 있습니다. 하지만 그 혼합된 아이디어 중 하나는 새로운 것을 만들고 있다면, 가능한 한 빨리 프로토타입을 사용자에게 보여주어야 한다는 것입니다.

대안적인 접근 방식은 헤일 메리 전략이라고 불릴 수 있습니다. 프로토타입을 빠르게 내놓고 점진적으로 다듬는 대신, 한 번의 긴 터치다운 패스로 완전하고 완성된 제품을 만들려고 시도하는 것입니다. 제가 아는 한, 이것은 재앙의 레시피입니다. 수많은 스타트업들이 인터넷 버블 동안 이런 식으로 스스로를 파괴했습니다. 저는 이것이 성공한 사례를 들어본 적이 없습니다.

소프트웨어 세계 외부의 사람들이 깨닫지 못할 수도 있는 것은 Worse is Better가 예술 전반에 걸쳐 발견된다는 것입니다. 예를 들어, 드로잉에서는 이 아이디어가 르네상스 시대에 발견되었습니다. 이제 거의 모든 드로잉 교사는 정확한 드로잉을 얻는 올바른 방법은 물체의 윤곽을 따라 천천히 작업하는 것이 아니라고 말할 것입니다. 왜냐하면 오류가 누적되어 결국 선들이 만나지 않을 것이기 때문입니다. 대신 대략 올바른 위치에 몇 개의 빠른 선을 그린 다음, 이 초기 스케치를 점진적으로 다듬어야 합니다.

대부분의 분야에서 프로토타입은 전통적으로 다른 재료로 만들어졌습니다. 금속으로 새겨질 서체는 처음에는 종이에 붓으로 디자인되었습니다. 청동으로 주조될 조각상은 밀랍으로 모델링되었습니다. 태피스트리에 수놓아질 패턴은 종이에 수묵으로 그려졌습니다. 돌로 지어질 건물은 나무로 더 작은 규모로 테스트되었습니다.

15세기에 유화가 처음 인기를 얻었을 때 그렇게 흥미로웠던 점은, 실제로 프로토타입 으로부터 완성된 작품을 만들 수 있었다는 것입니다. 원한다면 예비 드로잉을 만들 수 있었지만, 그것에 얽매이지 않았습니다. 그림을 완성하면서 모든 세부 사항을 작업하고 심지어 주요 변경 사항도 만들 수 있었습니다.

소프트웨어에서도 이것을 할 수 있습니다. 프로토타입은 단지 모델일 필요가 없습니다. 그것을 완성된 제품으로 다듬을 수 있습니다. 저는 가능할 때마다 항상 이렇게 해야 한다고 생각합니다. 그것은 도중에 얻는 새로운 통찰력을 활용할 수 있게 해줍니다. 하지만 아마도 더 중요한 것은, 그것이 사기 진작에 좋다는 것입니다.

사기는 디자인에서 핵심입니다. 사람들이 그것에 대해 더 많이 이야기하지 않는 것이 놀랍습니다. 제 첫 드로잉 선생님 중 한 분이 저에게 말했습니다. 그림을 그릴 때 지루하면, 그 그림은 지루해 보일 것이라고요. 예를 들어, 건물을 그려야 하는데, 벽돌 하나하나를 개별적으로 그리기로 결정했다고 가정해 봅시다. 원한다면 그렇게 할 수 있지만, 중간에 지루해져서 각 벽돌을 관찰하는 대신 기계적으로 만들기 시작하면, 그 그림은 단순히 벽돌을 암시했을 때보다 더 나빠 보일 것입니다.

프로토타입을 점진적으로 다듬어 무언가를 만드는 것은 계속 몰입하게 해주기 때문에 사기 진작에 좋습니다. 소프트웨어에서 제 규칙은 '항상 작동하는 코드를 유지하라'는 것입니다. 한 시간 안에 테스트할 수 있는 것을 작성하고 있다면, 즉각적인 보상에 대한 기대가 당신을 동기 부여할 것입니다. 예술, 특히 유화에서도 마찬가지입니다. 대부분의 화가들은 흐릿한 스케치로 시작하여 점진적으로 다듬습니다. 이런 식으로 작업하면, 원칙적으로 결코 미완성처럼 보이는 것으로 하루를 마칠 필요가 없습니다. 실제로 화가들 사이에는 이런 말이 있습니다. "그림은 결코 완성되지 않는다, 그저 작업을 멈출 뿐이다." 이 아이디어는 소프트웨어 작업을 해본 사람이라면 누구에게나 익숙할 것입니다.

사기는 세련되지 않은 사용자를 위해 무언가를 디자인하기 어려운 또 다른 이유입니다. 스스로 좋아하지 않는 것에 계속 관심을 갖기 어렵습니다. 좋은 것을 만들려면 "와, 이거 정말 대단하다"라고 생각해야지, "이런 쓰레기 같은 것, 저 바보들이 좋아하겠지"라고 생각해서는 안 됩니다.

디자인은 인간을 위해 무언가를 만드는 것을 의미합니다. 하지만 인간은 사용자만이 아닙니다. 디자이너도 인간입니다.

이 모든 시간 동안 제가 "디자이너"에 대해 이야기하고 있었다는 점에 주목하십시오. 디자인은 대개 좋은 결과를 내기 위해 한 사람의 통제하에 있어야 합니다. 하지만 여러 사람이 연구 프로젝트에 협력하는 것은 가능한 것 같습니다. 이것은 저에게 연구와 디자인 사이의 가장 흥미로운 차이점 중 하나로 보입니다.

예술 분야에서 유명한 협력 사례들이 있었지만, 대부분 핵융합이라기보다는 분자 결합의 사례였던 것 같습니다. 오페라에서는 한 사람이 대본을 쓰고 다른 사람이 음악을 쓰는 것이 일반적입니다. 그리고 르네상스 시대에는 북유럽의 숙련공들이 이탈리아 그림의 배경에 풍경을 그리는 데 종종 고용되었습니다. 하지만 이것들은 진정한 협력이 아닙니다. 로버트 프로스트의 "좋은 울타리가 좋은 이웃을 만든다"는 말의 예시에 가깝습니다. 좋은 디자인의 사례들을 함께 붙일 수는 있지만, 각 개별 프로젝트 내에서는 한 사람이 통제권을 가져야 합니다.

저는 좋은 디자인이 한 사람이 모든 것을 생각해야 한다고 말하는 것이 아닙니다. 당신이 판단을 신뢰하는 사람의 조언보다 더 가치 있는 것은 없습니다. 하지만 이야기가 끝나면, 무엇을 할지에 대한 결정은 한 사람에게 달려 있어야 합니다.

연구는 협력자들이 할 수 있는데 왜 디자인은 할 수 없을까요? 이것은 흥미로운 질문입니다. 저는 답을 모릅니다. 아마도 디자인과 연구가 수렴한다면, 최고의 연구 또한 좋은 디자인이며, 사실 협력자들이 할 수 없을 수도 있습니다. 가장 유명한 과학자들 중 많은 수가 혼자 일했던 것 같습니다. 하지만 여기에 어떤 패턴이 있는지 말할 만큼 충분히 알지 못합니다. 단순히 많은 유명 과학자들이 협력이 덜 흔했던 시기에 일했기 때문일 수도 있습니다.

과학 분야에서 어떤 이야기가 있든, 예술 분야에서는 진정한 협력이 거의 찾아볼 수 없을 정도로 드뭅니다. 위원회에 의한 디자인은 나쁜 디자인의 동의어입니다. 왜 그럴까요? 이 한계를 극복할 방법이 있을까요?

저는 그렇지 않다고 생각하는 경향이 있습니다. 좋은 디자인은 독재자를 필요로 한다는 것입니다. 한 가지 이유는 좋은 디자인은 하나의 통일된 조각이어야 하기 때문입니다. 디자인은 인간만을 위한 것이 아니라, 개별 인간을 위한 것입니다. 만약 디자인이 한 사람의 머릿속에 들어맞는 아이디어를 나타낸다면, 그 아이디어는 사용자의 머릿속에도 들어맞을 것입니다.

관련 글: