Background 배경

This speech was originally delivered by Bret Victor at CUSEC 2012.
이 연설은 원래 CUSEC 2012에서 브렛 빅터가 한 연설입니다.

Speech Transcript 음성 스크립트

So, unlike the previous session, I don’t have any prizes to give out. I’m just going to tell you how to live your life.
그래서 이전 세션과 달리 경품은 준비하지 않았습니다. 그냥 인생을 어떻게 살아야 하는지 알려드리려고 합니다.

This talk is actually about a way of living your life that most people don’t talk about. As you approach your career, you’ll hear a lot about following your passion, or doing something you love. I’m going to talk about something kind of different. I’m going to talk about following a principle — finding a guiding principle for your work, something you believe is important and necessary and right, and using that to guide what you do.
이 강연은 사실 대부분의 사람들이 말하지 않는 삶의 방식에 관한 이야기입니다. 커리어에 가까워질수록 열정을 따르거나 좋아하는 일을 하는 것에 대해 많이 듣게 될 것입니다. 저는 조금 다른 이야기를 해보려고 합니다. 저는 원칙을 따르는 것, 즉 중요하고 필요하며 옳다고 믿는 일의 지침이 되는 원칙을 찾아서 그 원칙에 따라 일을 하는 것에 대해 이야기하려고 합니다.

There are three parts to this talk. I’m first going to talk about the principle that guides a lot of my work, and try to give you a taste of what comes out of that. And I’m going to talk about some other people that have lived this way; what their principles are, what they believe in. But these are all just examples, to help you think about what you believe in, and how you want to live your life.
이 강연은 세 부분으로 구성되어 있습니다. 먼저 제 작업의 많은 부분을 이끌어가는 원칙에 대해 이야기하고, 그 원칙에서 나오는 결과를 여러분께 보여드리려고 합니다. 그리고 이런 방식으로 살아온 다른 사람들의 원칙이 무엇인지, 그들이 믿는 것이 무엇인지에 대해 이야기할 것입니다. 하지만 이 모든 것은 여러분이 무엇을 믿고, 어떤 삶을 살고 싶은지 생각해보는 데 도움을 주기 위한 예시일 뿐입니다.

So to begin with me: Ideas are very important to me. I think that bringing ideas into the world is one of the most important things that people do. And I think that great ideas, in the form of great art, stories, inventions, scientific theories, these things take on lives of their own, which give meaning to our lives as people. So, I think a lot about how people create ideas and how ideas grow. And in particular, what sorts of tools create a healthy environment for ideas to grow.
저부터 시작하겠습니다: 아이디어는 저에게 매우 중요합니다. 아이디어를 세상에 내놓는 것은 사람들이 하는 일 중 가장 중요한 일 중 하나라고 생각합니다. 그리고 위대한 예술, 이야기, 발명품, 과학 이론 등 훌륭한 아이디어는 그 자체로 생명을 얻고 우리 삶에 의미를 부여한다고 생각합니다. 그래서 저는 사람들이 어떻게 아이디어를 창출하고 아이디어가 어떻게 성장하는지에 대해 많이 생각합니다. 특히 어떤 종류의 도구가 아이디어가 성장할 수 있는 건강한 환경을 조성하는지에 대해 많이 생각합니다.

I’ve spent a lot of time over the years making creative tools, using creative tools, thinking about them a lot, and here’s something I’ve come to believe: Creators need an immediate connection to what they’re creating. That’s my principle. Creators need an immediate connection to what they create. And what I mean by that is when you’re making something, if you make a change, or you make a decision, you need to see the effect of that immediately. There can’t be a delay, and there can’t be anything hidden. Creators have to be able to see what they’re doing. Now I’m going to show a series of cases where I noticed that that principle was violated and I’ll show you what I did about that, and then I’m going to talk about the larger context in which I do this work.
저는 수년 동안 크리에이티브 도구를 만들고, 크리에이티브 도구를 사용하면서 많은 생각을 해왔고, 제가 믿게 된 것이 있습니다: 크리에이터는 자신이 만드는 콘텐츠와 즉각적인 연결이 필요하다는 것입니다. 이것이 제 원칙입니다. 크리에이터는 자신이 만든 콘텐츠와 즉각적인 연결이 필요합니다. 즉, 무언가를 만들거나 변경을 하거나 결정을 내릴 때 그 효과를 즉시 확인할 수 있어야 한다는 뜻입니다. 지연이 있어서는 안 되며 숨겨진 것이 있어서는 안 됩니다. 크리에이터는 자신이 무엇을 하고 있는지 볼 수 있어야 합니다. 이제 이 원칙을 위반한 사례들을 보여드리고 제가 어떻게 대처했는지 보여드린 다음, 제가 이 일을 하는 더 큰 맥락에 대해 이야기하겠습니다.

Here’s something I’ve come to believe: Creators need an immediate connection to what they’re creating. That’s my principle.
제가 믿게 된 것이 있습니다: 크리에이터는 자신이 제작하는 콘텐츠와 즉각적인 연결이 필요하다는 것입니다. 이것이 제 원칙입니다.

So, to begin with, let’s think about coding. Here’s how coding works: you type a bunch of code into a text editor, kind of imagining in your head what each line of code is going to do. And then you compile and run, and something comes out. So in this case, this is just JavaScript, drawing to a Canvas, and it draws this little scene with a tree. But if there’s anything wrong with the scene, or if I go and make changes, or if I have further ideas, I have to go back to the code, and I edit the code, compile and run, see what it looks like. Anything wrong, I go back to the code. Most of my time is spent working in the code, working in a text editor blindly, without an immediate connection to this thing, which is what I’m actually trying to make.
먼저 코딩에 대해 생각해 봅시다. 코딩은 텍스트 편집기에 여러 코드를 입력하면서 각 코드 줄이 무엇을 할 것인지 머릿속으로 상상하는 방식으로 작동합니다. 그런 다음 컴파일하고 실행하면 무언가가 나옵니다. 이 경우에는 캔버스에 그림을 그리는 자바스크립트이며, 나무가 있는 작은 장면을 그립니다. 하지만 장면에 문제가 있거나 변경 사항이 있거나 추가 아이디어가 있으면 다시 코드로 돌아가서 코드를 편집하고 컴파일하고 실행하여 어떻게 보이는지 확인해야 합니다. 잘못된 부분이 있으면 다시 코드로 돌아갑니다. 대부분의 시간은 제가 실제로 만들고자 하는 것과 직접적인 연관성 없이 텍스트 편집기에서 맹목적으로 코드 작업을 하는 데 소비됩니다.

So I feel that this goes against this principle that I have, that creators need an immediate connection to what they’re making, so I have tried to come up with a coding environment that would be more in line with this principle I have. So what I have here is I’ve got this picture on the side, and the code on the side, and this part draws the sky and this draws the mountains and this draws the tree, and when I make any change to the code, the picture changes immediately. So the code and the picture are always in sync; there is no compile and run. I just change things in the code and I see things change in the picture. And now that we have this immediate connection between the code and the picture, we can start thinking about ways of changing the code other than typing. So for example if this number here is the length of the branches. If I want to control that number, I just point my mouse to it, hold down the control key, and I can dial it up and down. So I can see what it looks like for big branches or small branches, and I can kind of converge on what feels right to me artistically. And this works great on any part of the code, I just point to it, and dial it up and down. Some of these numbers here, I know what they do but it’s kind of surprising to see them do it. And other ones are just completely surprising.
그래서 저는 이것이 제가 가지고 있는 원칙, 즉 크리에이터는 자신이 만드는 것에 즉각적인 연결이 필요하다는 원칙에 어긋난다고 생각해서 제가 가지고 있는 이 원칙에 더 부합하는 코딩 환경을 만들려고 노력했습니다. 그래서 여기에는 이 그림이 있고 옆에 코드가 있는데, 이 부분은 하늘을 그리고 이 부분은 산을 그리고 이 부분은 나무를 그리고 코드를 변경하면 그림이 즉시 변경됩니다. 따라서 코드와 그림이 항상 동기화되어 있어 컴파일하고 실행할 필요가 없습니다. 코드에서 무언가를 변경하기만 하면 그림에서 변경된 내용을 확인할 수 있습니다. 이제 코드와 그림이 즉각적으로 연결되었으므로 코드를 입력하는 것 외에 코드를 변경하는 방법을 생각할 수 있습니다. 예를 들어 여기 이 숫자가 나뭇가지의 길이라고 가정해 보죠. 이 숫자를 제어하고 싶으면 마우스를 가리키고 컨트롤 키를 누른 채 위아래로 움직이면 됩니다. 그래서 큰 가지와 작은 가지가 어떻게 생겼는지 볼 수 있고, 예술적으로 옳다고 느껴지는 부분에 집중할 수 있습니다. 이 기능은 코드의 어느 부분에서나 잘 작동하며, 해당 부분을 가리키고 위아래로 다이얼을 돌리기만 하면 됩니다. 여기 있는 숫자 중 몇 개는 기능을 알고 있지만 실제로 작동하는 것을 보면 다소 놀랍습니다. 그리고 다른 것들은 완전히 놀랍습니다.

So down here, I’ve got this for loop where I’m counting to sixteen, I’m putting sixteen little pink blossoms on every branch. And I can turn it down for less blossoms or turn it up for more. But, look at what I’m doing here: I’m just kind of moving the number up and down around twenty or so: and it has this really interesting shimmering effect; it kind of looks as if the wind was blowing through the tree. And the first time I saw this I immediately started thinking about how I could use this effect for an animation. How would I ever have discovered that if I had to compile and run between every change? So much of art, so much of creation is discovery, and you can’t discover anything if you can’t see what you’re doing.
여기 아래에는 16까지 세는 루프가 있고, 모든 가지에 16개의 작은 분홍색 꽃을 배치하고 있습니다. 꽃을 줄이거나 늘리려면 볼륨을 낮출 수 있습니다. 하지만 제가 지금 하는 일을 보세요: 20개 정도의 숫자를 위아래로 움직이고 있는데, 마치 나무에 바람이 부는 것처럼 보이는 정말 흥미로운 반짝임 효과가 있습니다. 이 효과를 처음 본 순간 이 효과를 애니메이션에 어떻게 사용할 수 있을지 바로 생각하기 시작했습니다. 모든 변경 사항을 컴파일하고 실행해야 했다면 어떻게 이 효과를 발견할 수 있었을까요? 예술의 많은 부분, 창작의 많은 부분은 발견이며, 자신이 무엇을 하고 있는지 볼 수 없다면 아무것도 발견할 수 없습니다.

So I’ve shown you adjusting the code, let’s add some code. I’d like to put a sun up here in the sky, so I’ll go to the end of the drawSky function, and I’ll want to fill a circle, so I start typing context.fillCircle, and as soon as I start typing, I get this autocomplete list of the different fill methods. So these are the things I can type there: fillCircle, fillRect, fillText. And as I move up and down this autocomplete list, I immediately see what each of them is doing. So, I don’t have to imagine what it would do from the method name. I don’t have to look at the documentation, I just see it, immediately.
코드를 조정하는 방법을 보여드렸으니 이제 코드를 추가해 보겠습니다. 여기 하늘에 태양을 배치하고 싶으므로 drawSky 함수의 끝으로 이동하여 원을 채우고 싶으므로 context.fillCircle을 입력하기 시작하면 입력하자마자 다양한 채우기 메서드의 자동 완성 목록이 표시됩니다. 여기에 입력할 수 있는 메서드는 fillCircle, fillRect, fillText입니다. 이 자동 완성 목록을 위아래로 움직이면 각 메서드가 무엇을 하는지 바로 확인할 수 있습니다. 따라서 메서드 이름에서 어떤 기능을 하는지 상상할 필요가 없습니다. 설명서를 볼 필요 없이 바로 볼 수 있습니다.

So I want a circle, and I’m going to adjust the x coordinate and the y coordinate, change the radius a bit. That looks about right. Probably it should be yellow, so I’m going to set the fill style, context.fillStyle, same autocomplete as before, choose fillStyle, gives me white by default, and I can change that color code the same way I change any number, I hit the control key, and I get a color palette. So I can choose a nice yellow for my sun. Although, the white was kind of interesting, I thought. I kind of didn’t expect that. But, with white, it now looks like the moon instead, right? Hey look, it’s night time! So having this immediate connection allows ideas to surface and develop in ways that would be impossible before.
이제 원이 필요하므로 x 좌표와 y 좌표를 조정하고 반지름을 약간 변경하겠습니다. 이제 괜찮아 보입니다. 아마도 노란색이어야 할 것 같으므로 채우기 스타일, context.fillStyle을 설정하고 이전과 동일한 자동 완성, fillStyle 선택, 기본적으로 흰색을 제공하고 숫자를 변경하는 것과 같은 방식으로 색상 코드를 변경하고 컨트롤 키를 누르면 색상 팔레트가 나타납니다. 그래서 태양을 멋진 노란색으로 선택할 수 있습니다. 그래도 흰색이 좀 흥미로웠어요. 예상하지 못했거든요. 하지만 흰색으로 바꾸니 이제 달처럼 보이네요, 그렇죠? 봐요, 밤이잖아요! 이렇게 즉각적인 연결을 통해 이전에는 불가능했던 방식으로 아이디어가 떠오르고 발전할 수 있습니다.

But there’s still a problem here, I think, which is I’ve got this picture, and I’ve got this code over here and I have to maintain the mapping between the two in my head. So I’ve got all these lines of code, and just looking at this line I don’t immediately know what it does. So here’s what I can do. I can hold down the option key, and my cursor changes to a magnifying glass, and now as I roll over each line of code, it’s highlighting in the picture what’s being drawn in that line. So, if I want to know what’s going on in this function, I just roll down the function and see what highlights. So here I’ve got two calls to draw mountain; I don’t know which is which; well, that’s that mountain, and that’s that mountain. And this has to work the other way too; if I see part of the picture, I have to know what code was responsible for drawing it. So I do the same thing; I hold down the option key, and now as I move over each pixel of the picture, you’ll see on the right it’s jumping to the line of code that drew that pixel. So that drew the sky, and that drew the tree, and that drew the blossom. So this is really important for maintaining that mapping, but it’s also really useful just for navigating around. So you know, I want to make the sun a little bit bigger; I jump there, and make it a little bigger. Or I want to bring up the tree a little bit; I jump there, and bring up the tree a little bit; I want to bring up the mountains a little bit, so I jump there, bring up the mountains a little bit; and I can make these changes as quickly as I think of them, and that is so important to the creative process. To be able to try ideas as you think of them. If there is any delay in that feedback loop, between thinking of something and seeing it, and building on it, then there is this whole world of ideas which will just never be. These are thoughts that we can’t think.
하지만 여기에는 여전히 문제가 있습니다. 이 그림이 있고 이 코드가 있는데 이 둘 사이의 매핑을 머릿속에서 유지해야 한다는 것입니다. 그래서 이 코드 줄을 보면 이 코드가 무엇을 하는지 바로 알 수 없습니다. 그래서 제가 할 수 있는 방법은 다음과 같습니다. 옵션 키를 누르고 있으면 커서가 돋보기로 바뀌고, 이제 각 코드 줄을 롤오버하면 해당 줄에 그려진 내용이 그림에 강조 표시됩니다. 따라서 이 함수에서 무슨 일이 일어나고 있는지 알고 싶으면 함수를 롤다운하여 무엇이 강조 표시되는지 확인하면 됩니다. 예를 들어 산을 그리라는 두 개의 호출이 있는데 어느 것이 어떤 산인지 모르겠고, 저쪽이 저 산이고 저쪽이 저 산입니다. 그림의 일부가 보이면 어떤 코드가 그 그림을 그렸는지 알아야 합니다. 옵션 키를 누른 상태에서 그림의 각 픽셀 위로 이동하면 오른쪽에 해당 픽셀을 그린 코드 줄로 이동하는 것을 볼 수 있습니다. 그래서 하늘이 그려지고, 나무가 그려지고, 꽃이 그려지는 식이죠. 이는 매핑을 유지 관리하는 데도 중요하지만 탐색하는 데에도 매우 유용합니다. 예를 들어 태양을 조금 더 크게 만들고 싶으면 저기로 뛰어가서 조금 더 크게 만들 수 있습니다. 또는 나무를 조금 더 크게 만들고 싶으면 저기로 점프해서 나무를 조금 더 크게 만들고, 산을 조금 더 크게 만들고 싶으면 저기로 점프해서 산을 조금 더 크게 만드는 등 생각나는 대로 빠르게 변화를 줄 수 있어서 창작 과정에 매우 중요한 요소입니다. 생각나는 대로 아이디어를 시도할 수 있다는 것이죠. 무언가를 생각하고 그것을 보고 그것을 바탕으로 구축하는 피드백 루프가 조금이라도 지연된다면, 아이디어의 세계는 영원히 존재하지 않을 것입니다. 이런 생각은 우리가 생각할 수 없는 생각입니다.

Ideas are very important to me. And the thing about ideas is that ideas start small. Ideas start out tiny, weak and fragile. In order to develop and mature, ideas need an environment where the creator can nurture them. Kind of take care of them, feed them, and shape their growth. And to me, that’s what the principle of immediate connection is all about. And because ideas are so precious to me, when I see this principle violated, when I see ideas stillborn or stunted because their creator couldn’t see what they were doing, I feel that’s wrong. And not wrong in the sense of violating some UI guideline or going against some best practice, but wrong in a deeper sense then that. And I’ll come back to this, but I want to show you another example of following this principle.
아이디어는 저에게 매우 중요합니다. 아이디어의 핵심은 아이디어는 작게 시작한다는 것입니다. 아이디어는 작고 약하고 연약하게 시작됩니다. 아이디어가 발전하고 성숙하기 위해서는 아이디어를 만든 사람이 키워줄 수 있는 환경이 필요합니다. 보살피고, 먹이를 주고, 성장을 도울 수 있는 환경 말이죠. 이것이 바로 즉각적인 연결의 원칙입니다. 아이디어는 저에게 매우 소중하기 때문에 이 원칙이 위반되는 것을 볼 때, 아이디어의 창작자가 무엇을 하고 있는지 볼 수 없어서 사산되거나 발육이 부진한 아이디어를 볼 때 저는 그것이 잘못되었다고 느낍니다. UI 가이드라인을 위반하거나 모범 사례에 어긋난다는 의미에서 잘못된 것이 아니라 그보다 더 깊은 의미에서 잘못된 것입니다. 다시 이 이야기로 돌아와서 이 원칙을 따르는 또 다른 예를 보여드리겠습니다.

So in this code here, there is no state, there is no persistent state, there is no time, there is no interactivity. And I was thinking about how we would handle those aspects of coding in a way that’s in line with these principles I have: creators need immediate connection. So what I have here is a little platform game. Here is my little guy, he can run around, he can jump, he can die. And the code for him is over here. So this code makes him run around, this makes him jump, this makes him collide with things… and down here, I’ve got some code for this little turtle. And the turtle is not doing much right now because I haven’t finished writing his code, so, I’m just going to do that right now. Say on each tick his x position plus equals his direction times the time interval, one sixtieth of a second times some speed, which, um, I dunno? Could be fast, could be slow, if it’s negative, he walks backwards. And these are all ideas I can use for other enemies but I think turtles are supposed to be slow, so let’s set that speed for our turtle. And up here, I’ve got some code that says, when my guy collides with the turtle, he gets some Y velocity, so he bounces into the air, and the turtle gets stomped. So that looks like that. And the turtle gets up after a bit.
따라서 여기 코드에는 상태도 없고, 지속 상태도 없고, 시간도 없고, 상호작용도 없습니다. 제작자는 즉각적인 연결이 필요하다는 제 원칙에 부합하는 방식으로 코딩의 이러한 측면을 어떻게 처리할 수 있을지 고민했습니다. 그래서 제가 만든 것이 작은 플랫폼 게임입니다. 여기 작은 녀석이 있는데, 뛰어다니고 점프하고 죽을 수도 있습니다. 그리고 그를 위한 코드가 여기 있습니다. 이 코드는 거북이를 뛰어다니게 하고, 점프하게 하고, 사물과 충돌하게 하고... 그리고 여기에는 이 작은 거북이를 위한 코드가 있습니다. 거북이는 아직 코드 작성이 끝나지 않았기 때문에 지금은 별다른 행동을 하지 않으므로 지금 바로 코드를 작성하겠습니다. 매 틱마다 거북이의 X 위치 플러스에 방향 곱하기 시간 간격, 즉 60분의 1초 곱하기 어떤 속도, 음, 글쎄요? 빠를 수도 있고 느릴 수도 있고, 음수이면 뒤로 걷는다는 뜻이죠. 다른 적들에게도 사용할 수 있는 아이디어지만 거북이는 느려야 하니까 거북이에게 그 속도를 설정해 봅시다. 그리고 여기에는 거북이와 충돌할 때 거북이가 Y자 속도를 얻어서 공중으로 튀어 오르고 거북이가 밟히도록 하는 코드가 있습니다. 그렇게 생겼습니다. 그리고 거북이는 잠시 후 일어납니다.

The problem is, I don’t want the player to be able to get up here yet. I want the player to bounce off the turtle, and go through this little passageway down here. And he’ll have to go around and solve puzzles and whatnot, and then come back and get the star. So, the turtle is too bouncy right now. Now of course I can just turn that down on the code, and now I can try it but now it’s not bouncy enough. So while it’s nice that I can adjust the code while it’s running, without having to stop and recompile and find my place again, I can’t immediately see what I need to see, which is whether or not he can make that jump.
문제는 플레이어가 아직 여기까지 올라갈 수 없기를 원한다는 것입니다. 플레이어가 거북이에서 튀어나와 여기 아래 작은 통로를 통과했으면 좋겠어요. 그리고 돌아다니면서 퍼즐 등을 풀고 다시 돌아와서 별을 얻어야 하죠. 거북이는 지금 너무 탱탱해요. 물론 코드에서 이를 낮출 수 있고 이제 시도해 볼 수 있지만 지금은 충분히 탱탱하지 않습니다. 실행 중인 코드를 멈추고 다시 컴파일하고 제 자리를 찾을 필요 없이 조정할 수 있다는 점은 좋지만, 거북이가 점프할 수 있는지 여부를 즉시 확인할 수는 없습니다.

So here’s what I’m going to do. I’m going to bounce off the turtle, and pause the game. So I pause the game, and now there’s this slider up here, which lets me rewind through time. And now, I can rewind to back before I made the jump, and change the code, make it less bouncy, and now when I move it forward, it’s going to simulate it, using the same input controls, the same keyboard commands recorded as before, but with the new code.
그래서 이렇게 하려고 합니다. 거북이에서 튀어나와 게임을 일시 정지하겠습니다. 게임을 일시정지했더니 여기 슬라이더가 있어서 시간을 되돌릴 수 있습니다. 이제 점프를 하기 전으로 되감고 코드를 변경하여 덜 튀어오르게 만든 다음 앞으로 이동하면 이전과 동일한 입력 컨트롤, 동일한 키보드 명령을 사용하지만 새로운 코드를 사용하여 시뮬레이션을 할 수 있습니다.

This is not good enough. I need to be able to see the changes immediately. I need to be able to see immediately whether or not my bounciness is correct. None of this stuff. And if you have a process in time, and you want to see changes immediately, you have to map time to space. So here’s what I’m going to do. I’m going to bounce off my turtle, pause the game, and now hit this button here, which shows my guy’s trail. So now I can see where he’s been. And when I rewind, this trail in front of him is where he is going to be. This is his future. And when I change the code, I change his future. So I can find exactly the value I need, so when I hit play, he slips right in there.
이것만으로는 충분하지 않습니다. 변경 사항을 즉시 확인할 수 있어야 합니다. 내 바운스가 올바른지 여부를 즉시 확인할 수 있어야 합니다. 이런 건 없습니다. 시간 단위의 프로세스가 있고 변경 사항을 즉시 확인하려면 시간을 공간에 매핑해야 합니다. 그래서 이렇게 하려고 합니다. 거북이에서 튀어나와 게임을 일시 정지한 다음 여기 이 버튼을 누르면 내 친구의 흔적이 표시됩니다. 이제 그가 어디로 갔는지 알 수 있습니다. 그리고 되감으면 이 앞의 흔적이 그가 갈 곳입니다. 이것이 그의 미래입니다. 내가 코드를 바꾸면 그의 미래도 바뀌죠. 그래서 제가 필요한 값을 정확히 찾을 수 있고, 재생을 누르면 그는 바로 그 안으로 들어갑니다.

So, creators need to be able to see what they’re doing. If you’re designing something embedded in time you need to be able to control time. You need to be able to see across time, otherwise you’re designing blind.
따라서 크리에이터는 자신이 무엇을 하고 있는지 확인할 수 있어야 합니다. 시간에 맞춰 무언가를 디자인하는 경우 시간을 제어할 수 있어야 합니다. 그렇지 않으면 맹목적인 디자인이 될 수 있습니다.

As I was playing with this, I noticed it’s fun to play with gravity. So I can make gravity a little negative and he starts to float up in the air. And I can kind of play with that and try to get him to stay there. And you could probably make an entire game around just the mechanic here, it’s gravity manipulation. In fact, I bet I could fiddle with any part of this code and come up with an idea for a game. Even if I just comment out the first statement in the code, now my guy can’t move left – he can only move right. Which sounds kinda silly, but Terry Cavanagh actually made a beautiful game around that concept called “Don’t Look Back”. Terry Cavanagh, he made another really wonderful game which you might have seen, called “VVVVVV”, spelled as the letter v six times. And, the way that game works, is that you can’t jump. Instead, you can only flip upside down, and you fall up instead of falling down. So it kinda works like this. You can walk on the ceiling or you can walk around on the ground. And so you have these levels which kinda look like this, and you kinda walk around… You have to learn how to navigate a terrain like this. And so if you had like a, something like that, you wouldn’t be able to jump over it. You’d have to flip over and flip over; he got an amazing amount of gameplay out of this concept.
이걸 가지고 놀다가 중력을 가지고 노는 것이 재미있다는 것을 깨달았어요. 그래서 중력을 약간 부정적으로 만들면 공중에 떠다니기 시작하죠. 그걸 가지고 놀면서 그를 거기에 머물게 할 수 있죠. 중력 조작이라는 메커니즘만으로 게임 전체를 만들 수도 있겠죠. 사실 이 코드의 어떤 부분이라도 만지작거리다 보면 게임 아이디어를 떠올릴 수 있을 것 같아요. 코드의 첫 번째 문만 주석 처리해도 이제 왼쪽으로 움직일 수 없고 오른쪽으로만 움직일 수 있습니다. 다소 우스꽝스럽게 들리겠지만, 실제로 Terry Cavanagh는 이 개념을 바탕으로 "Don't Look Back"이라는 멋진 게임을 만들었습니다. 테리 캐버나그는 여러분도 보셨을지도 모르는 "VVVVV"라는 정말 멋진 게임을 만들었는데, 철자가 V로 6번 바뀌는 게임입니다. 이 게임의 작동 방식은 점프할 수 없다는 것입니다. 대신 거꾸로 뒤집기만 할 수 있고 떨어지지 않고 위로 올라갈 수 있습니다. 이런 식으로 작동합니다. 천장 위를 걸을 수도 있고 바닥을 걸어 다닐 수도 있습니다. 그래서 이렇게 생긴 레벨이 있고, 이리저리 걸어 다니면서 이런 지형을 탐색하는 방법을 배워야 합니다. 그래서 이런 지형이 있다면 뛰어넘을 수 없습니다. 뒤집고 또 뒤집어야 하죠. 그는 이 콘셉트에서 놀라운 게임플레이를 만들어 냈습니다.

So again, being able to try ideas as you think of them. This example, and the last one with the tree, these are both very visual programs; we’re able to see our changes just by seeing how the picture changes. So I was thinking about, how we could do more abstract coding that’s more in line with this principle. How can we write a generic algorithm in such a way that we can see what we’re doing. So as an example, let’s take a look at binary search. Super quick refresher on how binary search works: you have an array of values that are in order, and you have a key, which is the value you’re trying to locate within the array. And you keep track of two variables, which are the lower and upper bounds of where you think that value could possibly be; right now, it could be anywhere. And you look right in the middle of that range – if what you find is too small, then the key has to be after that. Look in the middle of the range, if what you find is too big, the key has to be before that. And you kinda keep subdividing your range until you narrow in on the value you’re looking for. And in code, binary search looks like this. And from my perspective, you can’t see anything here. You can’t see anything. I see the word ‘array’, but I don’t actually see an array. And so in order to write code like this, you have to imagine an array in your head, and you essentially have to play computer. You have to simulate in your head what each line of code would do on a computer. And to a large extent, the people that we consider to be skilled software engineers are just those people that are really good at playing computer. But if we’re writing our code on a computer… why are we simulating what a computer would do in our head? Why doesn’t the computer just do it… and show us?
다시 말하지만, 생각나는 대로 아이디어를 시도해 볼 수 있습니다. 이 예제와 나무를 사용한 마지막 예제는 모두 매우 시각적인 프로그램으로, 그림이 어떻게 변하는지를 보는 것만으로도 변화를 확인할 수 있습니다. 그래서 저는 어떻게 하면 이 원리에 더 부합하는 추상적인 코딩을 할 수 있을까 생각했습니다. 어떻게 하면 우리가 하는 일을 볼 수 있는 방식으로 일반적인 알고리즘을 작성할 수 있을까요? 이진 검색을 예로 들어보겠습니다. 이진 검색의 작동 원리를 간단히 설명하자면, 순서대로 나열된 값 배열이 있고 배열 내에서 찾으려는 값인 키가 있습니다. 그리고 그 값이 있을 수 있는 위치의 하한과 상한인 두 개의 변수를 추적합니다(지금은 어디든 있을 수 있습니다). 그리고 그 범위의 한가운데에서 찾은 값이 너무 작으면 키는 그 뒤에 있어야 합니다. 범위의 중간을 살펴보고, 너무 큰 값이 나오면 열쇠는 그 앞에 있어야 합니다. 그리고 원하는 값의 범위를 좁힐 때까지 범위를 계속 세분화해야 합니다. 코드에서 이진 검색은 다음과 같이 보입니다. 제가 보기에는 아무것도 보이지 않습니다. 아무것도 보이지 않죠. '배열'이라는 단어는 보이지만 실제로 배열은 보이지 않습니다. 따라서 이런 코드를 작성하려면 머릿속에 배열을 상상해야 하고, 기본적으로 컴퓨터 게임을 해야 합니다. 각 코드 줄이 컴퓨터에서 어떻게 작동할지 머릿속으로 시뮬레이션해야 합니다. 그리고 우리가 숙련된 소프트웨어 엔지니어라고 생각하는 사람들은 대부분 컴퓨터 게임을 정말 잘하는 사람들입니다. 하지만 우리가 컴퓨터로 코드를 작성한다면 왜 컴퓨터가 할 일을 머릿속에서 시뮬레이션하는 것일까요? 왜 컴퓨터가 그냥 실행해서 우리에게 보여주지 않을까요?

So. Let’s write binary search. Function “binary search” takes a key and an array. And then over here on this side, it’s saying “Ok, it takes a key and an array, such as what? Give me an example; I need something to work with here.” So, for instance, my array might be ‘a’, ‘b’, ‘c’, ‘d’, ‘e’, ‘f’. And let’s say for instance we’re looking for the ‘d’. So now let’s start coding. The lower bound starts out as zero. Over here it says ‘low equals zero’, nothing amazing there. Upper bound starts out at the end of the array, so high equals array length minus one. And over here, it says ‘high equals five’. So I have my abstract formula in the code. Over here, it’s giving me the concrete value corresponding to these example arguments. So I don’t have to maintain this picture in my head; it’s just showing it to me.
그래서. 이진 검색을 작성해 보겠습니다. "이진 검색" 함수는 키와 배열을 받습니다. 그리고 여기 이쪽에서 "좋아, 키와 배열이 필요한데, 예를 들면? 예를 들어 여기 작업할 무언가가 필요해요."라고 말합니다. 예를 들어 제 배열은 'a', 'b', 'c', 'd', 'e', 'f'가 될 수 있습니다. 예를 들어 'd'를 찾고 있다고 가정해 봅시다. 이제 코딩을 시작하겠습니다. 하한은 0으로 시작합니다. 여기에는 '낮음은 0과 같다'라고 쓰여 있습니다. 상한은 배열의 끝에서 시작하므로 높음은 배열 길이에서 1을 뺀 값입니다. 그리고 여기에는 '높음은 5와 같다'라고 적혀 있습니다. 코드에 추상적인 공식이 있습니다. 여기에서는 이 예제 인수에 해당하는 구체적인 값을 제공하고 있습니다. 따라서 머릿속에서 이 그림을 유지할 필요 없이 그냥 보여주기만 하면 됩니다.

So now I need the index in the middle of the array, so I’m going to take the average of those two. Mid equals low plus high over two, and… well, that’s obviously not right. Two point five is not a valid array index. So I guess I need to round this off. So I’m going to add the floor function and it rounded it down to two. And I caught that bug literally the second I typed it, instead of writing the entire function in twenty unit tests. So now I get the value out of the array… and then I need to subdivide my range, which, so there’s an if statement which I’ll just paste in here. So in this case, the value I found is less than the key, so it’s taking this first branch of the if statement. This is adjusting the lower bound. Of course if the key was smaller, then it would take this branch of the if statement and adjust the upper bound. Or, if the key was ‘c’, then we would’ve just happened to find it on the first shot, and we’d return the index.
이제 배열의 중간에 인덱스가 필요하므로 이 둘의 평균을 구하려고 합니다. 중간은 2보다 낮은 값에 높은 값을 더한 값인데... 이건 분명히 옳지 않습니다. 2.5는 유효한 배열 인덱스가 아닙니다. 그래서 반올림해야 할 것 같습니다. 그래서 바닥 함수를 추가하고 2로 반올림했습니다. 그리고 20개의 단위 테스트에서 전체 함수를 작성하는 대신 입력하자마자 버그를 발견했습니다. 이제 배열에서 값을 가져온 다음 범위를 세분화해야 하므로 여기에 붙여넣을 if 문이 있습니다. 이 경우에는 찾은 값이 키보다 작기 때문에 if 문의 첫 번째 분기를 가져옵니다. 이것은 하한을 조정하는 것입니다. 물론 키가 더 작다면 if 문에서 이 분기를 가져와 상한을 조정할 것입니다. 또는 키가 'c'였다면 첫 번째 샷에서 우연히 발견했을 것이고 인덱스를 반환했을 것입니다.

So this is the first iteration of this algorithm. And now what we need to do, is loop. We’ve subdivided the array, we need to keep subdividing until we narrow in on what we’re looking for. So, we need to loop; I will just loop. While 1, do all this. And now what we have are three columns corresponding to three iterations of this loop. So this first column here is exactly what you saw before. Low and high span the entire array, we found a ‘c’, it was too low, so we adjusted our lower bound, and loop up to here. Second iteration, bounds are tighter; we found an ‘e’. Adjust the upper bound. Third iteration, loop up to here; low and high are the same. We’ve narrowed it down to a single candidate – it’s indeed the key we’re looking for, and we returned this index. So there’s nothing hidden here; you see exactly what the algorithm is doing at every point. And I can go up to here and try different keys, so I can see how the algorithm behaves for these different input arguments.
이것이 이 알고리즘의 첫 번째 반복입니다. 이제 우리가 해야 할 일은 반복입니다. 배열을 세분화했으니 원하는 대상을 좁힐 때까지 계속 세분화해야 합니다. 그래서 반복해야 합니다. 그냥 반복하겠습니다. 1 동안 이 모든 작업을 수행합니다. 이제 이 루프의 세 번의 반복에 해당하는 세 개의 열이 생겼습니다. 여기 첫 번째 열은 앞서 보셨던 것과 정확히 일치합니다. 배열 전체에 걸쳐 낮은 값과 높은 값이 있는데, 'C'가 너무 낮아서 하한을 조정하고 여기까지 반복합니다. 두 번째 반복에서는 경계가 더 엄격해져 'e'를 찾았습니다. 상한을 조정합니다. 세 번째 반복, 여기까지 반복하여 하한과 상한이 동일합니다. 단일 후보로 범위를 좁혔습니다. 이것이 바로 우리가 찾고 있는 키이며, 이 인덱스를 반환했습니다. 따라서 여기에는 숨겨진 것이 없으며 모든 지점에서 알고리즘이 정확히 무엇을 하고 있는지 볼 수 있습니다. 그리고 여기로 올라가서 다른 키를 시도해 볼 수 있으므로 다양한 입력 인자에 대해 알고리즘이 어떻게 작동하는지 확인할 수 있습니다.

And by looking across this data, I can develop an intuition for how this algorithm works. So I’m trying different keys here, and say I try looking for a ‘g’. And this looks a little different. It’s not actually returning. And the reason for this is, I’m looking for a key which is not actually in the array. And the only way of breaking out of this loop, is by finding the key. So it’s kinda stuck here looping forever. So we can take a look at this and see what went wrong, where’s the algorithm going off the rails. These first few iterations look fine, but this iteration looks weird, because low is greater than high. Our range is completely collapsed. So if we get to this point, then we know the key can’t be found. So I see this faulty condition, and I say, “Oh, that’s not right; low has to be less than or equal to high.” Okay, well, I’ll just put that over as the condition of my while statement. Low, less than equal to high, and then that would break out of the loop, and I would return some signal to say that it couldn’t be found. So here we have three iterations of the loop, couldn’t be found, we return a not found value. So that’s what it might be like to write an algorithm without a blindfold on.
그리고 이 데이터를 살펴봄으로써 이 알고리즘이 어떻게 작동하는지에 대한 직관을 키울 수 있습니다. 그래서 저는 여기서 다른 키를 시도해보고 'g'를 찾아본다고 가정해 보겠습니다. 이것은 조금 다르게 보입니다. 실제로는 돌아오지 않습니다. 그 이유는 배열에 실제로 없는 키를 찾고 있기 때문입니다. 그리고 이 루프에서 벗어나는 유일한 방법은 키를 찾는 것입니다. 그래서 여기서 영원히 반복되는 것입니다. 따라서 우리는 이것을 살펴보고 무엇이 잘못되었는지, 알고리즘이 어디에서 잘못되었는지 확인할 수 있습니다. 처음 몇 번의 반복은 괜찮아 보이지만 이 반복은 낮은 값이 높은 값보다 크기 때문에 이상하게 보입니다. 범위가 완전히 무너졌습니다. 이 지점에 도달하면 키를 찾을 수 없다는 것을 알 수 있습니다. 그래서 저는 이 잘못된 조건을 보고 "아, 이건 옳지 않아요. 로우는 하이보다 작거나 같아야 해요."라고 말합니다. 알았어요, 그럼 그 조건을 내 동안 문의 조건으로 넣겠습니다. 낮음, 높음보다 작거나 같으면 루프에서 벗어나고, 찾을 수 없다는 신호를 반환합니다. 여기에서는 루프를 세 번 반복하고, 찾을 수 없으면 찾을 수 없음 값을 반환합니다. 눈가리개를 착용하지 않고 알고리즘을 작성하는 것이 이와 비슷할 수 있습니다.

So I’ve got this principle, again, that creators need to be able to see what they’re doing. They need this immediate connection with that they’re making. And I’ve tried to show this principle through three coding examples, but that’s just because this is a software engineering conference, I thought I was supposed to talk about programming. But to me, this principle has nothing to do with programming in particular. It has to do with any type of creation. So I’d like to show you a couple more demos, just to show you the breadth of what I have in mind here.
그래서 저는 크리에이터가 자신이 무엇을 하고 있는지 볼 수 있어야 한다는 원칙을 가지고 있습니다. 제작자는 자신이 만들고 있는 콘텐츠와 즉각적인 연결이 필요합니다. 저는 이 원칙을 세 가지 코딩 예시를 통해 설명하려고 했지만, 소프트웨어 엔지니어링 컨퍼런스이기 때문에 프로그래밍에 대해 이야기해야 한다고 생각했습니다. 하지만 제가 보기에 이 원리는 특별히 프로그래밍과 관련이 없습니다. 모든 유형의 창작물과 관련이 있습니다. 그래서 제가 염두에 두고 있는 것의 폭을 보여드리기 위해 몇 가지 데모를 더 보여드리려고 합니다.

So, to begin with, let’s take a look at a different branch of engineering. So here I have an electronic circuit that I drew. I’m not quite done drawing it, so let me finish up there. And we’ll put 2. And now we have a working circuit. I mean I assume it’s a working circuit. I don’t actually see anything working here. So this is exactly the same as writing code, that we work in a static representation. But what we actually care about is the data. The values of the variables, so we can’t see that here. Now in a circuit, the variables are the voltages on these different wires. So each of these wires has a voltage that’s changing over time, and we have to be able to see that. Now, if I was building this circuit on a lab bench, building it physically, I could at least take an oscilloscope and kinda poke around and see what’s going on in the different wires, what’s going on here, or here. So at the very least, I should be able to do that. So what I have here, is a plot of the voltage on this wire over time. You can see it’s high, it’s low, high and low, so this is clearly oscillating. If I built this physically, also I would be able to see the circuit doing something. In this case I have these two LED’s up here. These are LED’s, little lights, presumably they’re there for a reason. I can hit Play, and watch it simulate out in real time. So now you can see what the circuit is doing.
우선 다른 엔지니어링 분야를 살펴봅시다. 여기 제가 그린 전자 회로가 있습니다. 아직 다 그리지 않았으니 여기서 마무리하겠습니다. 이제 2를 넣으면 작동하는 회로가 생겼습니다. 제 말은 이게 작동하는 회로라고 가정합니다. 실제로는 아무것도 작동하지 않는 것 같습니다. 코드를 작성할 때와 똑같이 정적인 표현으로 작업하는 것이죠. 하지만 우리가 실제로 신경 쓰는 것은 데이터입니다. 변수의 값이므로 여기서는 볼 수 없습니다. 이제 회로에서 변수는 여러 전선의 전압입니다. 따라서 각 전선에는 시간에 따라 변하는 전압이 있으며 이를 볼 수 있어야 합니다. 만약 제가 실험실 벤치에서 이 회로를 물리적으로 구축한다면 최소한 오실로스코프를 가지고 여러 전선에서 무슨 일이 일어나고 있는지, 여기 또는 여기에서 무슨 일이 일어나고 있는지 살펴볼 수 있을 것입니다. 그래서 최소한 그렇게 할 수 있어야 합니다. 이 그림은 시간 경과에 따른 전선의 전압 그래프입니다. 높고, 낮고, 높고, 낮은 것을 볼 수 있으므로 이것은 분명히 진동하고 있습니다. 이것을 물리적으로 만들면 회로가 무언가를 하는 것을 볼 수 있습니다. 이 경우에는 여기 두 개의 LED가 있습니다. 이 LED는 작은 불빛인데, 아마도 이유가 있을 겁니다. 재생을 누르면 실시간으로 시뮬레이션되는 것을 볼 수 있습니다. 이제 회로가 어떻게 작동하는지 볼 수 있습니다.

In order to design a circuit like this, you have to understand the voltage on every wire. You have to understand how all the voltages are changing throughout the entire circuit. And just like coding, either the environment shows that to you, or you simulate it in your head. And I have better things to do with my head than simulating what electrons are doing. So what I’m gonna do, I’m gonna spread these out a bit. So same circuit, spread out a little bit, and I’m going to add the voltage at every node. So now you can see every voltage throughout the circuit. And I can even hit Play and watch it all kind of simulate out in real time.
이와 같은 회로를 설계하려면 모든 전선의 전압을 이해해야 합니다. 전체 회로에서 모든 전압이 어떻게 변화하는지 이해해야 합니다. 코딩할 때와 마찬가지로 환경이 이를 보여주거나 머릿속으로 시뮬레이션해야 합니다. 전자가 하는 일을 시뮬레이션하는 것보다 머릿속으로 더 좋은 일을 할 수 있습니다. 그래서 제가 할 일은 이것들을 조금 펼쳐보겠습니다. 동일한 회로를 조금 펼쳐서 모든 노드에 전압을 추가하겠습니다. 이제 회로 전체의 모든 전압을 볼 수 있습니다. 재생을 누르면 실시간으로 시뮬레이션되는 것을 볼 수도 있습니다.

Although, what I prefer to do, is just move my mouse over it, and I can kind of look in areas that are interesting to me and see what the values are. I can compare any two nodes. So if you look at say the node over here, while I mouse over this one, you see the shadow of the one I’m mousing over is overlaid on that. The shadow of the one I’m mousing over is actually overlaid on all of them. And so I can compare any two nodes just by mousing over one of them and looking at the other one.
하지만 제가 선호하는 방법은 마우스를 마우스로 움직이기만 하면 관심 있는 영역을 살펴보고 값이 무엇인지 확인할 수 있습니다. 두 노드를 비교할 수 있습니다. 예를 들어 여기 있는 노드에 마우스를 올려놓으면 마우스를 올려놓은 노드의 그림자가 그 위에 겹쳐져 있는 것을 볼 수 있습니다. 제가 마우스를 올려놓은 노드의 그림자가 실제로는 모든 노드에 겹쳐져 있습니다. 따라서 두 노드 중 하나에 마우스를 올려놓고 다른 노드를 보는 것만으로 두 노드를 비교할 수 있습니다.

And again, I can immediately see results of my changes. So I’ve got this 70k resistor here. I want to change its value, I just click and drag it, and now I see the waveforms change immediately. And you’ll notice that when I click and drag, it leaves behind the shadow of the waveform before I started dragging, so I can compare. I can immediately see the results of my changes.
그리고 다시 변경한 결과를 즉시 확인할 수 있습니다. 여기 70k 저항이 있습니다. 값을 변경하고 싶어서 클릭하고 드래그하면 파형이 즉시 변경되는 것을 볼 수 있습니다. 그리고 클릭하고 드래그하면 드래그하기 전의 파형 그림자가 남기 때문에 비교할 수 있습니다. 변경한 결과를 즉시 확인할 수 있습니다.

Two golden rules of information design: Show the data. Show comparisons. That’s all I’m doing here. But even this isn’t quite good enough. What we’re seeing here are the voltages, but in electronics there are actually two data types. There is voltage and there is current. And what we’re not seeing is the current, flowing through each of these components. And in order to design a circuit, you need to understand both the voltage and the current. You need to understand the interplay between the two. That’s what analog design is.
정보 디자인의 두 가지 황금률: 데이터를 표시하세요. 비교를 표시하세요. 이것이 제가 여기서 하는 전부입니다. 하지만 이것만으로는 충분하지 않습니다. 여기서 보고 있는 것은 전압이지만 전자 제품에는 실제로 두 가지 데이터 유형이 있습니다. 전압과 전류가 있습니다. 그리고 우리가 보지 못하는 것은 이러한 각 구성 요소를 통해 흐르는 전류입니다. 따라서 회로를 설계하려면 전압과 전류를 모두 이해해야 합니다. 둘 사이의 상호 작용을 이해해야 합니다. 이것이 바로 아날로그 설계입니다.

The two golden rules of information design: Show the data. Show comparisons.
정보 디자인의 두 가지 황금률: 데이터를 표시하세요. 비교를 표시하세요.

So what I’m gonna do is spread these out a little bit more. And now I’m gonna replace each of these components with a plot of the current going throw it over time. So each of these blue boxes represents a component. And you can see which component it is, because it has a little badge in the corner, a little icon, but now you can see everything that’s going on in the circuit. You can see how the current changes, you can see how the voltage and the current changes. There’s nothing hidden, there’s nothing to simulate in your head.
그래서 제가 할 일은 이것들을 조금 더 펼치는 것입니다. 이제 각 컴포넌트를 시간 경과에 따른 전류의 플롯으로 바꾸겠습니다. 이 파란색 상자는 각각 컴포넌트를 나타냅니다. 모서리에 작은 배지와 작은 아이콘이 있기 때문에 어떤 구성 요소인지 알 수 있지만 이제 회로에서 일어나는 모든 일을 볼 수 있습니다. 전류가 어떻게 변하는지, 전압과 전류가 어떻게 변하는지 볼 수 있습니다. 숨겨진 것도 없고, 머릿속으로 시뮬레이션할 것도 없습니다.

So what we have here is a different way of representing the circuit. Just in general, you could draw any circuit with these blocks and instead of being made out of little squiggly symbols, it’s made out of data. And I think it’s important to ask: Why do we have these squiggly symbols in the first place? Why do they exist? They exist because they’re easy to draw with pencil on paper. This is not paper. So when you have a new medium, you have to rethink these things. You have to think how can this new medium allow us to have a more immediate connection to what we’re making. How can this new medium allow us to work in such a way that we can see what we’re doing.
그래서 여기에는 회로를 표현하는 다른 방법이 있습니다. 일반적으로 이 블록으로 어떤 회로든 그릴 수 있지만, 작은 구불구불한 기호 대신 데이터로 만들어져 있습니다. 그렇다면 애초에 왜 이런 구불구불한 기호를 사용해야 할까요? 왜 존재할까요? 종이에 연필로 그리기 쉽기 때문에 존재합니다. 이것은 종이가 아닙니다. 따라서 새로운 매체가 등장하면 이러한 것들을 다시 생각해야 합니다. 이 새로운 매체를 통해 어떻게 하면 우리가 만들고 있는 것과 더 즉각적으로 연결될 수 있을지 생각해야 합니다. 어떻게 하면 이 새로운 매체를 통해 우리가 하고 있는 일을 볼 수 있는 방식으로 작업할 수 있을까요?

And it’s really the same situation with programming. Our current conception of what a computer program is — a list of textual definitions that you hand to a compiler — that’s derived straight from Fortran and ALGOL in the late ’50’s. Those languages were designed for punchcards. So you’d type your program on a stack of cards, and hand them to the computer operator (it’s the guy in the bottom picture), and you would come back later. So there was no such thing as interactivity back then. And that assumption is baked into our current notions of what programming is.
프로그래밍도 마찬가지입니다. 컴퓨터 프로그램이 무엇인지에 대한 현재의 개념(컴파일러에 전달하는 텍스트 정의 목록)은 50년대 후반의 Fortran과 ALGOL에서 바로 파생된 것입니다. 이 언어들은 펀치카드용으로 설계되었습니다. 따라서 카드 더미에 프로그램을 입력한 후 컴퓨터 운영자(아래쪽 사진에 있는 사람)에게 전달하고 나중에 다시 돌아와야 했습니다. 그 당시에는 상호작용이라는 개념이 없었죠. 그리고 그 가정은 현재 프로그래밍에 대한 우리의 개념에 그대로 녹아 있습니다.

C was designed for teletypes. That’s Ken Thompson and Dennis Ritchie up there. Ritchie made C. And there are no video displays in this picture. Ritchie is basically typing on a fancy typewriter that types back to him. Any time you use a console or a terminal window, you’re emulating a teletype. And even today, people still think of a REPL or an interactive top-level as being interactive programming. Because that’s the best thing you could do on a teletype.
C는 텔레타이핑을 위해 설계되었습니다. 저기 켄 톰슨과 데니스 리치입니다. 이 사진에는 비디오 디스플레이가 없습니다. Ritchie는 기본적으로 멋진 타자기로 타이핑을 하고 있고, 그 타자기가 다시 타이핑을 해줍니다. 콘솔이나 터미널 창을 사용할 때마다 텔레타이프를 모방하는 것입니다. 그리고 오늘날에도 사람들은 여전히 REPL이나 대화형 최상위 레벨을 대화형 프로그래밍이라고 생각합니다. 텔레타이프에서 할 수 있는 최고의 기능이기 때문입니다.

So I have one more demo I want to show because I want to emphasize that this principle, immediate connection, is not even about engineering, it’s about any type of creation. So I want to move to a different field entirely, so let’s think about animation.
이 원리, 즉 즉각적인 연결은 엔지니어링에 관한 것이 아니라 모든 유형의 창작물에 적용된다는 점을 강조하고 싶어서 데모를 하나 더 보여드리려고 합니다. 그래서 완전히 다른 분야로 넘어가서 애니메이션에 대해 생각해 보겠습니다.

So I’ve got this painting here, of a tree and a leaf on it and I want to make a little video with the leaf kinda drifting down the tree. And the normal way of doing this in a conventional animation package like Flash, is through keyframes. So you basically say where you want the leaf to be at different points in time, and then you hit Play and see what it looks like. So, I’m gonna say: ok, at frame 20, I’m gonna create a keyframe and the leaf should be there. And at frame 40, create a keyframe and the leaf should be there, and I’m just totally guessing here. I can not see the motion. I can not feel the timing, I’m just throwing things in time and space. 

So I’ve got this leaf at different points in time, and I’m gonna add a tween, which tells Flash to connect the dots. And then I’m gonna hit Play and see what it looks like. And it looks ridiculous, it looks like billiard balls bouncing back and forth. 

And the thing is I kind of know what I want, right? It’s a leaf. I want a leaf drifting down from a tree. And I can even perform that with my hand: leaf drifting down from a tree. But Flash doesn’t know how to listen to my hand. But maybe there’s a new medium that does know something about listening to my hand. 

So what I’m gonna show you here is a little app I made for performing animation. And we’re not really set up to do a live demo off the iPad so I’m just gonna play you a video of me making a video. The way this scene is going to play out is the leaf is gonna kind of drift down from the tree, and the scene is gonna pan over and the rabbit is gonna do something. And two things: one, this is going to move pretty quickly, and second, I’m going to be using both hands at almost all times. So I’ve got these different layers, the background, the mid-ground and the foreground. I’m choosing which layer to move using my left thumb. I’m gonna move my leaf to its position. I’m gonna move my bunny off stage and start time rolling. Now I’m gonna perform the leaf drifting down from the tree. Run it back, check out how that looked. The motion looks pretty good but the leaf kinda needs to rock back and forth. So I’m gonna pull out a rotation controller, run it back, find where the leaf is about to break off, and record the rotation. And I added a little flip there just because it felt right at the moment. It wasn’t even planned. Stop, because I want to pan over. So I’m gonna drag a whole bunch of layers at once, I grab all the layers into a list, I turn down the sensitivity of the background layers so they’ll move slower for a kind of parallax effect. I only want to move horizontally so I pull out a horizontal dragger and check out how it looks. I don’t quite like the parallax so I adjust the sensitivities just a little bit, try it out again, I like that better, so I get ready to go, I run it back to the beginning so I can get back into the rhythm of the piece. The leaf hits, I wait a beat, and I start panning. And I don’t know how many frames I waited, I don’t know how long it was, I went when it felt right.
제가 여기서 보여드릴 것은 애니메이션 연주를 위해 만든 작은 앱입니다. iPad에서 라이브 데모를 할 수 있는 환경이 아니기 때문에 제가 만드는 동영상을 보여드리겠습니다. 이 장면은 나뭇잎이 나무에서 떨어지고 장면이 전환되고 토끼가 무언가를 하는 식으로 진행됩니다. 그리고 두 가지 중요한 점은 첫째, 이 장면은 매우 빠르게 움직일 것이고 둘째, 저는 거의 항상 양손을 사용해야 한다는 것입니다. 그래서 배경, 중경, 전경 등 다양한 레이어가 있습니다. 저는 왼손 엄지 손가락으로 이동할 레이어를 선택합니다. 나뭇잎을 그 위치로 이동하겠습니다. 토끼를 무대 밖으로 옮기고 타임롤링을 시작하겠습니다. 이제 나뭇잎이 나무에서 떨어지는 장면을 연출하겠습니다. 다시 실행해서 어떻게 보이는지 확인해 보세요. 동작은 꽤 괜찮아 보이지만 나뭇잎이 앞뒤로 흔들려야 해요. 그래서 회전 컨트롤러를 꺼내서 다시 실행하고 나뭇잎이 떨어지려는 위치를 찾아 회전을 기록하겠습니다. 그리고 그 순간 느낌이 좋아서 거기에 약간의 플립을 추가했습니다. 계획된 것도 아니었어요. 멈춰요, 뒤집고 싶으니까요. 그래서 한 번에 많은 레이어를 드래그하고 모든 레이어를 목록으로 가져온 다음 배경 레이어의 감도를 낮추어 시차 효과를 위해 느리게 움직이도록 합니다. 수평으로만 이동하고 싶어서 수평 드래거를 꺼내서 어떻게 보이는지 확인합니다. 시차가 마음에 들지 않아서 감도를 조금만 조정하고 다시 시도해 보니 더 마음에 들어서 다시 처음으로 돌아가서 곡의 리듬에 맞춰서 실행합니다. 나뭇잎이 닿으면 비트를 기다렸다가 패닝을 시작합니다. 몇 프레임을 기다렸는지, 얼마나 오래 기다렸는지 모르겠고, 적절하다고 생각될 때 갔어요.

So I panned over this winter scene and kind of slowed down to a stop. And then I run it back, because I want to do something with my bunny. Throw away these tools because I’m done with them. And wait until I think my bunny should move and he hops away. And I have got a few different poses for my bunny. So I pull those out. And then I find the point where the bunny is about to take off the ground. Which is right there. I switch his pose and I kind of toggle between the poses as he hops away. And then I run it back because I wanna check out how it looked and I’m just gonna bring that up full screen for you. This is the piece.
그래서 이 겨울 장면을 패닝하고 속도를 늦춰서 멈췄어요. 그런 다음 토끼와 함께 무언가를 하고 싶어서 다시 실행했습니다. 이 도구들은 다 썼으니 버리죠. 그리고 토끼가 움직여야 한다고 생각될 때까지 기다렸다가 토끼가 뛰어내립니다. 그리고 토끼를 위한 몇 가지 포즈가 있습니다. 그래서 그것들을 꺼내요. 그런 다음 토끼가 땅을 벗어나려는 지점을 찾습니다. 바로 저기예요. 토끼의 포즈를 바꾸고 토끼가 뛰어내릴 때 포즈를 전환합니다. 그런 다음 어떻게 보이는지 확인하고 싶어서 다시 실행해서 전체 화면으로 보여드리겠습니다. 이것이 바로 그 작품입니다.

So I made that in 2 minutes, performing with my hands like a musical instrument. Very immediate connection between me and what I was trying to make.
그래서 악기처럼 손으로 연주하면서 2분 만에 만들었습니다. 제가 만들고자 했던 것과 매우 즉각적으로 연결되었죠.

One of the inspirations for this tool was an animation that I tried to make several years ago. Not that one but it also began with a leaf drifting down from a tree. And I spent all day in Flash trying to keyframe that leaf. Couldn’t do it. And so that was the end of that. I still have my storyboards. Sometimes I play the music I wrote for the piece. But the piece itself is locked in my head. And so I always think about the millions of pieces that are locked in millions of heads. And not just animation, and not just art, but all kinds of ideas. All kinds of ideas including critically important ideas, world-changing inventions, life-saving scientific discoveries. These are all ideas that must be grown. And without an environment in which they can grow, or their creator can nurture them with this immediate connection, many of these ideas will not emerge. Or they’ll emerge stunted.
이 도구에 대한 영감 중 하나는 몇 년 전에 만들려고 했던 애니메이션이었습니다. 그 애니메이션은 아니지만 나무에서 나뭇잎이 떨어지는 장면에서 시작되었습니다. 그 나뭇잎을 키프레임으로 만들려고 하루 종일 플래시로 작업했죠. 할 수 없었어요. 그렇게 끝이 났죠. 저는 아직도 스토리보드를 가지고 있습니다. 가끔은 작품을 위해 작곡한 음악을 연주하기도 하죠. 하지만 작품 자체는 제 머릿속에 갇혀 있어요. 그래서 저는 항상 수백만 개의 머릿속에 갇혀 있는 수백만 개의 작품에 대해 생각하죠. 애니메이션뿐만 아니라 미술뿐만 아니라 모든 종류의 아이디어가 그렇습니다. 매우 중요한 아이디어, 세상을 바꾸는 발명품, 생명을 구하는 과학적 발견을 포함한 모든 종류의 아이디어요. 이 모든 아이디어는 반드시 성장해야 합니다. 아이디어가 성장할 수 있는 환경이 조성되지 않거나 창작자가 즉각적인 연결을 통해 아이디어를 육성할 수 없다면 이러한 아이디어 중 많은 아이디어가 나오지 않을 것입니다. 아니면 발육 부진에 빠지게 될 것입니다.

So I have this principle that creators need an immediate connection and all of those demos that I just showed you simply came from me looking around, noticing places where this principle was violated, and trying to fix that. It’s really all I did. I just followed this guiding principle and it guided me to what I had to do.
그래서 저는 크리에이터에게 즉각적인 연결이 필요하다는 원칙을 가지고 있으며, 방금 보여드린 모든 데모는 이 원칙이 위반된 부분을 발견하고 이를 고치려고 노력한 결과물입니다. 그게 제가 한 전부입니다. 저는 이 원칙을 따랐을 뿐이고, 이 원칙이 제가 해야 할 일을 안내해 주었습니다.
But I haven’t said much about the most important part of the story, which is why. Why I have this principle. Why I do this.
하지만 이 이야기에서 가장 중요한 부분에 대해서는 많이 언급하지 않았습니다. 제가 이 원칙을 가지고 있는 이유입니다. 내가 이 일을 하는 이유.

When I see a violation of this principle, I don’t think of that as an opportunity. When I see creators constrained by their tools, their ideas compromised, I don’t say: Oh good, an opportunity to make a product. An opportunity to start a business. Or an opportunity to do research or contribute to a field. I’m not excited by finding a problem to solve. I’m not in this for the joy of making things. Ideas are very precious to me. And when I see ideas dying, it hurts. I see a tragedy. To me it feels like a moral wrong, it feels like an injustice. And if I think there’s anything I can do about it, I feel it’s my responsibility to do so. Not opportunity, but responsibility.
이 원칙을 위반하는 것을 볼 때 저는 그것을 기회라고 생각하지 않습니다. 크리에이터가 도구의 제약을 받고 아이디어가 훼손되는 것을 볼 때 저는 그렇게 말하지 않습니다: 제품을 만들 수 있는 기회라고 말하지 않습니다. 창업의 기회라고 생각하죠. 아니면 연구를 하거나 한 분야에 기여할 수 있는 기회라고 생각하죠. 저는 해결해야 할 문제를 찾아서 흥분하지 않습니다. 저는 무언가를 만드는 즐거움을 위해 이 일을 하는 것이 아닙니다. 아이디어는 저에게 매우 소중합니다. 그리고 아이디어가 죽어가는 것을 보면 마음이 아픕니다. 비극을 보는 것 같죠. 제게는 도덕적 잘못처럼 느껴지고 불의처럼 느껴지죠. 그리고 제가 할 수 있는 일이 있다고 생각되면 그렇게 하는 것이 제 책임이라고 생각합니다. 기회가 아니라 책임이죠.

Now this is just my thing. I’m not asking you to believe in this the way I believe I do. My point here is that these words that I’m using: Injustice, Responsibility, Moral wrong, these aren’t the words we normally hear in a technical field. We do hear these words associated with social causes. So things like censorship, gender discrimination, environmental destruction. We all recognize these things as moral wrongs. Most of us wouldn’t see a civil rights violation and think “Oh good, an opportunity.” I hope not.
이제 이건 그냥 제 생각입니다. 제가 믿는 방식대로 믿으라는 것이 아닙니다. 제가 여기서 말하고자 하는 것은 제가 사용하는 단어들입니다: 불의, 책임, 도덕적 잘못 등은 기술 분야에서 흔히 듣는 단어가 아닙니다. 이러한 단어는 사회적 대의와 관련된 단어입니다. 검열, 성 차별, 환경 파괴 같은 것들 말이죠. 우리 모두는 이러한 것들을 도덕적 잘못으로 인식합니다. 우리 대부분은 인권 침해를 보고 "오, 좋은 기회다"라고 생각하지 않을 것입니다. 그러지 않기를 바랍니다.

Instead, we’ve been very fortunate to have people throughout history who recognized these social wrongs and saw it as their responsibility to address them. And so there’s this activist lifestyle where these persons dedicate themselves to fighting for a cause that they believe in. And the purpose of this talk is to tell you that this activist lifestyle is not just for social activism. As a technologist, you can recognize a wrong in the world. You can have a vision of what a better world could be. And you can dedicate yourself to fighting for a principle. Social activists typically fight by organizing but you can fight by inventing.
하지만 역사적으로 이러한 사회적 부조리를 인식하고 이를 해결하는 것이 자신의 책임이라고 생각한 사람들이 있었기에 우리는 매우 운이 좋았습니다. 그래서 이러한 사람들이 자신이 믿는 대의를 위해 싸우는 데 헌신하는 활동가적 라이프스타일이 존재합니다. 이 강연의 목적은 이러한 활동가적 라이프스타일이 사회 운동에만 국한되지 않는다는 것을 알려드리기 위한 것입니다. 기술자로서 여러분은 세상의 잘못을 인식할 수 있습니다. 더 나은 세상에 대한 비전을 가질 수 있습니다. 그리고 원칙을 위해 싸우는 데 헌신할 수 있습니다. 사회 운동가들은 보통 조직을 통해 싸우지만, 여러분은 발명을 통해 싸울 수 있습니다.

So now I’d like to tell you about a few other people who have lived this way, starting with Larry Tesler. Larry has done a lot of wonderful things in his life, but the work I’m gonna tell you about he did in the mid ’70s at Xerox PARC. And at the time, there really wasn’t such a thing as personal computers. The notion of personal computing was very young and Larry and his colleagues at PARC felt that they had transformative potential, that personal computing could change how people thought and lived. And I think all of us in this room would agree that they turned out to be right about that.
이제 래리 테슬러를 시작으로 이런 방식으로 살아온 몇 명의 다른 사람들에 대해 말씀드리고자 합니다. 래리는 그의 인생에서 많은 훌륭한 일을 해왔지만, 제가 말씀드리고자 하는 것은 70년대 중반에 제록스 PARC에서 했던 일입니다. 당시에는 개인용 컴퓨터라는 것이 존재하지 않았습니다. 개인용 컴퓨터라는 개념은 아주 어렸고, 래리와 PARC의 동료들은 개인용 컴퓨터가 사람들의 생각과 생활 방식을 바꿀 수 있는 혁신적 잠재력을 가지고 있다고 생각했습니다. 그리고 이 자리에 있는 우리 모두는 그들의 생각이 옳았다는 데 동의할 것입니다.

But at the time, software interfaces were designed around modes. So, in a text editor for instance, you couldn’t just type and have words appear on the screen like on a typewriter. You would be in command mode and if you wanted to insert text you’d have to press I to go into insert mode then Escape back out to command mode or maybe you’d hit A to go into append mode. Or if you wanted to move text around you’d hit M go to the Move mode and then you’d have to select and you’d be in the mode to select and move things around. And Larry would watch people using the computer — they actually pioneered the concept of software user studies, another thing that he did — but he would watch people using the software and he found that many people even after training and weeks of use, many people would not become comfortable with the computer.
하지만 당시 소프트웨어 인터페이스는 모드를 중심으로 설계되었습니다. 예를 들어 텍스트 편집기에서는 타자기처럼 입력만 하면 화면에 단어가 나타나도록 할 수 없었습니다. 명령 모드에서 텍스트를 삽입하려면 I 키를 눌러 삽입 모드로 전환한 다음 다시 이스케이프 키를 눌러 명령 모드로 돌아가거나 A 키를 눌러 추가 모드로 전환해야 했습니다. 또는 텍스트를 이동하려면 M을 눌러 이동 모드로 이동한 다음 선택하면 선택 및 이동 모드에 들어가게 됩니다. 래리는 사람들이 컴퓨터를 사용하는 모습을 지켜보곤 했는데, 실제로 소프트웨어 사용자 연구라는 개념을 개척하기도 했는데, 래리는 사람들이 소프트웨어를 사용하는 모습을 지켜보면서 많은 사람들이 교육을 받고 몇 주 동안 사용해도 컴퓨터에 익숙해지지 않는다는 것을 알게 되었습니다.

And he believed that it was these modes that were to blame. That the complexity of modes was a kind of barrier that many people couldn’t cross. And so this kind of represented a threat to this dream of what personal computing could be. So Larry made it his personal mission to eliminate modes from software. And he formed a principle: No person should be trapped in a mode. His slogan that he would go around saying was ‘Don’t mode me in’ and he had it printed on his t-shirt. And this principle informed everything that he did. He thought about it with all the work that he did. And eventually he came up with a text editor called Gypsy, which essentially introduced text editing as we know today. There was an insertion point. And when you typed, words appeared on the screen. To select text, he invented modeless selection with click and drag. So you just click and drag over the text you want to select like using a highlighter — one of the first uses of drag. To move text around, he invented these commands that he called Cut, Copy, Paste. You select and cut. Later on you paste in whenever you’re ready. You’re never trapped in a mode, you never have to switch between modes. When you hit W on the keyboard you get W on the screen. Always.
그리고 그는 이러한 모드가 문제라고 생각했습니다. 모드의 복잡성은 많은 사람들이 넘을 수 없는 일종의 장벽이라고 생각했습니다. 그래서 이런 종류의 모드는 개인용 컴퓨팅에 대한 꿈을 위협하는 요소라고 생각했습니다. 그래서 래리는 소프트웨어에서 모드를 없애는 것을 개인적인 사명으로 삼았습니다. 그리고 그는 어떤 사람도 모드에 갇혀서는 안 된다는 원칙을 세웠습니다. 그는 '나를 모드에 가두지 마세요'라는 슬로건을 티셔츠에 인쇄해 다니며 외쳤습니다. 그리고 이 원칙은 그가 하는 모든 일에 영향을 미쳤습니다. 그는 모든 일을 할 때마다 이 원칙에 대해 생각했습니다. 결국 그는 집시라는 텍스트 편집기를 고안해냈고, 이는 오늘날 우리가 알고 있는 텍스트 편집의 시초가 되었습니다. 삽입 지점이 있었습니다. 타이핑을 하면 화면에 단어가 나타났죠. 텍스트를 선택하기 위해 그는 클릭 앤 드래그 방식의 모델리스 선택을 발명했습니다. 형광펜을 사용하듯 선택하려는 텍스트를 클릭하고 드래그하기만 하면 되는데, 이것이 드래그의 첫 번째 용도 중 하나입니다. 텍스트를 이동하기 위해 그는 잘라내기, 복사, 붙여넣기라는 명령을 발명했습니다. 선택하고 잘라냅니다. 나중에 준비가 되면 언제든지 붙여넣으면 됩니다. 모드에 갇히지 않고 모드 간에 전환할 필요도 없습니다. 키보드에서 W를 누르면 화면에 W가 표시됩니다. 언제나.

And he would watch people using his software and he found that someone who had never seen a computer before — which was most people back then — could be up and running in like half an hour. So this was clearly a transformative change in enabling people to connect with computers. And his ideas about modelessness spread to the rest of the desktop interface which was then being invented at PARC at the same time. And today they’re so ingrained in the computing experience that today we kind of take them for granted.
그리고 그는 사람들이 자신의 소프트웨어를 사용하는 것을 지켜보면서 컴퓨터를 한 번도 본 적이 없는 사람(당시 대부분의 사람들이 그랬죠)이 30분 만에 컴퓨터를 사용할 수 있다는 사실을 발견했습니다. 이는 사람들이 컴퓨터와 연결될 수 있도록 하는 혁신적인 변화였습니다. 그리고 모델리스에 대한 그의 아이디어는 같은 시기에 PARC에서 개발되던 나머지 데스크톱 인터페이스에까지 확산되었습니다. 그리고 오늘날에는 컴퓨팅 경험에 깊이 뿌리내려 오늘날 우리는 이를 당연한 것으로 받아들이고 있습니다.

Now I said that Larry made the elimination of modes his personal mission. That’s actually his words, and if you think he’s exaggerating, here’s Larry’s license plate for the last 30 years. Nowadays of course Larry has a website, at nomodes.com and he’s on twitter: @nomodes. And so like I said, Larry has done a lot of amazing work in his career but his self identity is clearly associated with this cause.
래리가 모드 제거를 개인적인 사명으로 삼았다고 말씀드렸습니다. 실제로 래리가 한 말인데, 과장이라고 생각하신다면 지난 30년 동안 래리의 번호판을 보시면 됩니다. 물론 요즘 래리는 nomodes.com에 웹사이트를 운영하고 있으며 트위터도 운영하고 있습니다: @nomodes. 앞서 말했듯이 래리는 자신의 커리어에서 놀라운 일을 많이 해왔지만 그의 자아 정체성은 이 대의와 분명히 연관되어 있습니다.

And so I’d like to ask: What exactly did Larry do? Like how could we best describe what Larry did? A typical biography might say Larry Tesler invented Cut, Copy, Paste. Which is true, but I think that’s really misleading, because this invention was very different than say, Thomas Edison inventing the phonograph. Edison basically just stumbled over the technology for audio recording and he built it out as a novelty. And he came up with this list of possible applications for his technology but he didn’t have any cultural intent. Whereas what Larry did was entirely a reaction to a particular cultural context.
그래서 저는 래리가 정확히 무엇을 했는지 묻고 싶습니다. 래리가 한 일을 어떻게 가장 잘 설명할 수 있을까요? 일반적인 전기에서는 래리 테슬러가 잘라내기, 복사하기, 붙여넣기를 발명했다고 말할 수 있습니다. 사실이지만 이 발명은 토마스 에디슨이 축음기를 발명한 것과는 매우 다르기 때문에 오해의 소지가 있다고 생각합니다. 에디슨은 기본적으로 오디오 녹음 기술을 우연히 발견하고 이를 참신한 아이디어로 발전시켰습니다. 그리고 그는 자신의 기술을 응용할 수 있는 목록을 생각해냈지만 문화적 의도는 전혀 없었습니다. 반면 래리는 전적으로 특정 문화적 맥락에 대한 반응이었습니다.

So another thing that you might hear is that Larry Tesler solved the problem of modeless text manipulation. Solved the problem. And obviously that’s true, he worked on this problem for a long time, eventually solved it. But I think that’s really misleading too, because this problem that he solved only existed in his own head. Nobody else saw this as a problem. For everybody else modes were just how computers worked. There wasn’t anything wrong with them any more than we think there’s something wrong with having two arms. It just kind of was a fact of life.
래리 테슬러가 모델 없는 텍스트 조작 문제를 해결했다는 소식도 들릴 수 있습니다. 문제를 해결했습니다. 분명히 그는 이 문제를 오랫동안 연구했고 결국 해결했습니다. 그러나 그가 해결한 이 문제는 자신의 머릿속에만 존재했기 때문에 그것도 정말 오해의 소지가 있다고 생각합니다. 다른 누구도 이 문제를 문제라고 생각하지 않았습니다. 다른 사람들에게는 모드가 컴퓨터의 작동 방식일 뿐이었으니까요. 우리가 팔이 두 개인 것을 문제라고 생각하는 것처럼 컴퓨터에는 아무런 문제가 없었습니다. 그냥 삶의 일부였죠.

So the first thing that Larry did was that he recognized a wrong that had been unacknowledged in the culture. And the thing is, that’s how many great social changes began as well. So a 150 years ago, Elizabeth Cady Stanton had to stand up and say: women should vote. And everybody else said ‘That’s crazy, what are you talking about’. Today, we recognize gender discrimination as a wrong. Back then, it was part of society, it was invisible. She had to recognize it, and she had to fight it. And to me, that’s a much closer model to what Larry did than the Thomas Edison model of inventing a bunch of random technology so he could patent it.
그래서 래리가 가장 먼저 한 일은 문화에서 인정되지 않았던 잘못을 인정한 것이었습니다. 그리고 그 일로 인해 많은 위대한 사회적 변화가 시작되었습니다. 150년 전 엘리자베스 캐디 스탠튼은 여성도 투표권을 가져야 한다고 외쳤습니다. 다른 사람들은 모두 '미쳤어, 무슨 소리야'라고 말했죠. 오늘날 우리는 성차별을 잘못된 것으로 인식하고 있습니다. 그 당시에는 성차별이 사회의 일부였고 눈에 보이지 않았죠. 그녀는 그것을 인식하고 싸워야만 했죠. 제 생각에는 토마스 에디슨이 특허를 얻기 위해 무작위로 기술을 발명하는 모델보다 래리가 한 일에 훨씬 더 가까운 모델이라고 생각합니다.

Now to be clear I’m not making any judgements about the relative importance or the impact of these two people, I’m just talking about their motivations and their approach. Both of them recognized a cultural wrong, they envisioned a world without that wrong and they dedicated themselves to fighting for a principle. She fought by organizing, he fought by inventing.
이 두 사람의 상대적 중요성이나 영향력에 대해 어떤 판단을 내리는 것이 아니라 그들의 동기와 접근 방식에 대해 이야기하는 것임을 분명히 하고자 합니다. 두 사람 모두 문화적 잘못을 인식하고 그러한 잘못이 없는 세상을 상상했으며 원칙을 위해 싸우는 데 헌신했습니다. 그녀는 조직으로 싸웠고, 그는 발명으로 싸웠습니다.

And many other seminal figures in computing had similar motivations. So certainly Doug Engelbart. Doug Engelbart basically invented interactive computing. The concept of putting information on a screen. Navigating through it. Looking at information in different ways. Pointing at things and manipulating them. He came up with all this at a time when real-time interaction with a computer was just almost unheard of. Today he is best known as the inventor of the mouse, but what he really invented is this entirely new way of working with knowledge. His explicit goal from the beginning was to enable mankind to solve the world’s urgent problems. And his vision, he had this vision of what he called knowledge workers using complex powerful information tools to harness their collective intelligence. And he only got into computers because he had a hunch that these new things called computer things could help him realize that vision. Everything that he did was almost single-mindedly driven by pursuing this vision.
그리고 컴퓨팅 분야의 다른 많은 저명한 인물들도 비슷한 동기를 가지고 있었습니다. 더그 엥겔바트도 마찬가지입니다. 더그 엥겔바트는 기본적으로 대화형 컴퓨팅을 발명했습니다. 화면에 정보를 표시하는 개념입니다. 탐색하는 개념입니다. 다양한 방식으로 정보를 보는 것. 사물을 가리키고 조작하는 것. 그는 컴퓨터와의 실시간 상호 작용이 거의 전례가 없던 시절에 이 모든 것을 생각해 냈습니다. 오늘날 그는 마우스의 발명가로 가장 잘 알려져 있지만, 그가 실제로 발명한 것은 완전히 새로운 지식 작업 방식입니다. 처음부터 그의 분명한 목표는 인류가 세계의 시급한 문제를 해결할 수 있도록 하는 것이었습니다. 그리고 그는 복잡하고 강력한 정보 도구를 사용하여 집단 지성을 활용하는 지식 근로자에 대한 비전을 가지고 있었습니다. 그리고 컴퓨터라는 새로운 사물이 그 비전을 실현하는 데 도움이 될 것이라는 직감이 있었기 때문에 컴퓨터에 뛰어들었습니다. 그가 한 모든 일은 거의 전적으로 이 비전을 추구하기 위해 추진되었습니다.

Here’s Alan Kay. Alan Kay ran the lab at Xerox PARC where we got the desktop interface, so things like windows and icons, command menus. He also invented object-oriented programming and lots of other things. His goal, and I quote, was to ‘amplify human reach, and bring new ways of thinking to a faltering civilization that desperately needed it.’ Isn’t that great? His approach was through children. He believed that if children became fluent in thinking in the medium of the computer, meaning if programming was a form of basic literacy like reading and writing, then they’d become adults with new forms of critical thought, and new ways of understanding the world. And we’d have this more enlightened society, similar to the difference that literacy brought to society. And everything that he did, everything he invented, came out of pursuing this vision, this goal with children. And following principles that he adopted from Piaget and Montessori, Jerome Bruner, these people who would study how children think.
앨런 케이입니다. 앨런 케이는 데스크톱 인터페이스, 즉 창과 아이콘, 명령 메뉴 등을 개발한 제록스 PARC에서 연구소를 운영했습니다. 그는 또한 객체 지향 프로그래밍과 다른 많은 것들을 발명했습니다. 그의 목표는 '인간의 영향력을 확대하고 새로운 사고방식을 절실히 필요로 하는 흔들리는 문명에 새로운 사고방식을 가져다주는 것'이었습니다. 대단하지 않나요? 그의 접근 방식은 어린이를 통한 것이었습니다. 그는 아이들이 컴퓨터라는 매체를 통해 사고하는 데 능숙해진다면, 즉 프로그래밍이 읽기, 쓰기와 같은 기본적인 문해력의 한 형태라면 새로운 형태의 비판적 사고와 세상을 이해하는 새로운 방식을 가진 어른이 될 수 있다고 믿었습니다. 그리고 문맹 퇴치가 사회에 가져온 변화와 비슷하게 더 계몽된 사회가 될 것입니다. 그리고 그가 한 모든 일, 그가 발명한 모든 것은 아이들과 함께 이 비전, 이 목표를 추구하면서 나온 것입니다. 그리고 피아제와 몬테소리, 제롬 브루너 등 아이들의 사고 방식을 연구한 사람들의 원칙을 따랐습니다.

And the figure probably most widely associated with software activism is Richard Stallman. Stallman started the GNU project which today makes up a big chunk of any Linux system. He also started the Free Software Foundation, wrote GCC, GPL, many, many other things. His principle is that software must be free, as in freedom, and he has very precise meaning associated with that statement. He’s always been very clear that software freedom is a matter of moral right and wrong. And he has taken a particularly uncompromising approach in his own life to that.
소프트웨어 행동주의와 가장 널리 알려진 인물은 아마도 리처드 스톨만일 것입니다. 스톨만은 오늘날 모든 리눅스 시스템의 큰 부분을 차지하는 GNU 프로젝트를 시작했습니다. 그는 또한 자유 소프트웨어 재단을 시작했고, GCC, GPL 등을 만들었습니다. 그의 원칙은 소프트웨어는 자유와 마찬가지로 자유로워야 한다는 것이었고, 그 말에는 매우 정확한 의미가 담겨 있습니다. 그는 소프트웨어의 자유는 도덕적 옳고 그름의 문제라는 점을 항상 분명히 해왔습니다. 그리고 그는 자신의 삶에서 그 문제에 대해 특히 타협하지 않는 접근 방식을 취했습니다.

All of these tremendously influential people dedicated their lives to fighting for a particular ideal with a very clear sense of right and wrong. Often really fighting against an authority or mainstream that did not recognize their wrong as being wrong. And today, the world is still very far from any of their ideals and so they still see a world in crisis and they keep fighting. They’re always fighting.
이 엄청나게 영향력 있는 사람들은 모두 옳고 그름에 대한 명확한 의식을 가지고 특정 이상을 위해 싸우는 데 평생을 바쳤습니다. 종종 자신의 잘못을 잘못으로 인정하지 않는 권위나 주류에 맞서 싸웠습니다. 그리고 오늘날 세상은 여전히 그들의 이상과는 거리가 멀기 때문에 그들은 여전히 위기에 처한 세상을 보고 계속 싸우고 있습니다. 그들은 항상 싸우고 있습니다.

Now I’m not saying you have to live this way. I’m not saying that you should live this way. What I’m saying is that you can. That this lifestyle is an option that’s available to you. And it’s not one you’re gonna hear about much. Your career counselor is not going to come back to you and say you should start a personal crusade. In a social field, they might, but not in technology. Instead the world will try to make you define yourself by a skill.
여러분에게 꼭 이렇게 살아야 한다고 말하는 것은 아닙니다. 꼭 이렇게 살아야 한다고 말하는 것이 아닙니다. 제가 말씀드리고 싶은 것은 여러분도 할 수 있다는 것입니다. 이 라이프스타일은 여러분이 선택할 수 있는 옵션입니다. 그리고 그것은 여러분이 많이 듣게 될 이야기는 아닙니다. 여러분의 커리어 카운슬러는 여러분에게 개인적인 성전을 시작해야 한다고 말하지 않을 것입니다. 사회 분야에서는 그럴 수 있지만 기술 분야에서는 그렇지 않습니다. 대신 세상은 기술로 자신을 정의하려고 할 것입니다.

That’s why you have a major in college. That’s why you have a job title. You are a software engineer. And you’ll probably specialize to be a database engineer or a front-end engineer, and you’ll be given front-ends and asked to engineer them. And that could be worthwhile and valuable, and if you want to spend your life pursuing excellence and practicing a skill, you can do that. That is the path of a craftsman. That is the most common path. The only other path you really hear about much is the path of the problem solver. So I see entrepreneurship and academic research as kind of two sides of that coin. There is the field. There’s the set of problems in that field, or needs in the market. You go in, you choose one, you work it, you make your contribution there. Maybe later on, you choose another problem, you work it, you make your contribution there. Again, that could be worthwhile and valuable and if that’s what you want to do, then you can take that path.
그래서 대학에서 전공을 하는 것입니다. 그래서 직함이 있는 것입니다. 여러분은 소프트웨어 엔지니어입니다. 그리고 데이터베이스 엔지니어 또는 프론트엔드 엔지니어로 전문화할 수 있고, 프론트엔드가 주어지고 이를 설계하라는 요청을 받게 될 것입니다. 그리고 그것은 보람 있고 가치 있는 일이 될 수 있으며, 탁월함을 추구하고 기술을 연마하는 데 평생을 보내고 싶다면 그렇게 할 수 있습니다. 그것이 장인의 길입니다. 이것이 가장 일반적인 길입니다. 여러분이 많이 듣는 유일한 다른 길은 문제 해결자의 길입니다. 그래서 저는 기업가 정신과 학술 연구는 동전의 양면과 같다고 생각합니다. 현장이 있습니다. 해당 분야의 문제 또는 시장의 니즈가 있습니다. 그 분야에 들어가서 한 가지를 선택하고, 연구하고, 거기서 기여하는 것이죠. 나중에 다른 문제를 선택해서 해결하고 거기서 기여를 할 수도 있습니다. 다시 말하지만, 그 일이 보람 있고 가치 있는 일이라면 그 길을 택할 수 있습니다.

But I don’t see Larry Tesler on either of those paths. I wouldn’t say that he was contributing to the field of user experience design because there was no such thing. He didn’t choose some open problem to solve, he came up with some problem that only existed in his own head, and no one else even recognized. And certainly he did not define himself by his craft, he defined himself by his cause. By the principle he fought to uphold. And I’m sure if you look at Wikipedia it will say that he’s a computer scientist or a user experience something but to me that’s like saying Elizabeth Cady Stanton was a community organizer. No, Elizabeth Cady Stanton established the principle of women’s suffrage. That’s who she was. That was the identity she chose and Larry Tesler established the principle of modelessness. He had this vision, and he brought the world to that vision.
하지만 래리 테슬러는 그 어느 쪽에도 속하지 않았습니다. 사용자 경험 디자인이라는 분야가 존재하지 않았기 때문에 그가 사용자 경험 디자인 분야에 기여했다고 말하기는 어렵습니다. 그는 해결해야 할 공개적인 문제를 선택한 것이 아니라 자신의 머릿속에만 존재하고 아무도 알아채지 못한 문제를 생각해 냈습니다. 그리고 확실히 그는 자신의 기술로 자신을 정의한 것이 아니라 자신의 대의로 자신을 정의했습니다. 그가 지키기 위해 싸웠던 원칙으로요. 위키피디아를 보면 그가 컴퓨터 과학자나 사용자 경험 전문가라고 나와 있지만, 제게는 엘리자베스 캐디 스탠튼이 지역사회 조직가였다고 말하는 것과 마찬가지입니다. 아니요, 엘리자베스 캐디 스탠튼은 여성 참정권 원칙을 확립한 사람입니다. 그게 바로 그녀였죠. 그것이 그녀가 선택한 정체성이었고 래리 테슬러는 모델리티의 원칙을 확립했습니다. 그는 비전을 가지고 있었고, 그 비전을 실현하기 위해 세상을 이끌었습니다.

So, you can choose this life. Or maybe it will end up choosing you. It might not happen right away. It can take time to find a principle because finding a principle is essentially a form of self-discovery, that you’re trying to figure out what your life is supposed to be about. What you want to stand for as a person.
따라서 여러분은 이 삶을 선택할 수 있습니다. 아니면 삶이 당신을 선택하게 될 수도 있습니다. 당장 그런 일이 일어나지 않을 수도 있습니다. 원칙을 찾는다는 것은 본질적으로 자기 발견의 한 형태이며, 자신의 삶이 무엇이어야 하는지 알아내는 것이기 때문에 원칙을 찾는 데는 시간이 걸릴 수 있습니다. 어떤 사람으로 서고 싶은지.

It can take time to find a principle because finding a principle is essentially a form of self-discovery.
원칙을 찾는다는 것은 본질적으로 자기 발견의 한 형태이기 때문에 원칙을 찾는 데 시간이 걸릴 수 있습니다.

Took me like a decade. Ten years before any real understanding of my principles solidified. That was my twenties. When I was young I felt I had to live this way but I would get little glimmers of what mattered to me but no big picture. It was really unclear. This was very distressing for me. What I had to do was just do a lot of things. Make many things, make many types of things. Study many things, experience many, many things. And use all these experiences as a way of analyzing myself. Taking all these experiences and saying ‘Does this resonate with me?’. Does this repel me? Do I not care? Building up this corpus of experiences that I felt very strongly about for some reason and trying to make sense of it. Trying to figure out why. What is this secret ingredient to all these experiences that I’m reacting to so strongly.
10년이 걸렸어요. 제 원칙에 대한 이해가 확고해지기까지 10년이 걸렸습니다. 그때가 제 20대였죠. 어렸을 때는 이렇게 살아야 한다고 생각했지만, 제게 중요한 것이 무엇인지 조금씩은 알았지만 큰 그림은 없었습니다. 정말 불분명했죠. 이는 저에게 매우 괴로운 일이었습니다. 제가 해야 할 일은 그저 많은 일을 하는 것이었어요. 많은 것을 만들고, 많은 종류의 것을 만들어야 했습니다. 많은 것을 공부하고, 많은 것을 경험하고. 그리고 이 모든 경험을 저 자신을 분석하는 방법으로 활용해야 했습니다. 이 모든 경험을 가지고 '이것이 나에게 공감을 주는가? 이것이 나를 격퇴하는가? 내가 신경 쓰지 않는가? 어떤 이유에서인지 매우 강하게 느꼈던 경험의 집합을 만들고 그것을 이해하려고 노력합니다. 그 이유를 알아내려고 노력합니다. 이 모든 경험에 내가 그렇게 강하게 반응하는 이 비밀스러운 요소는 무엇일까요?

Now I think everyone’s different. And all the guys I talked about they have their own origin stories which you can read about. I will just say that confining yourself to practicing a single skill can make it difficult to get that broad range of experience which seems to be so valuable for this sort of work.
지금은 모두가 다르다고 생각해요. 그리고 제가 이야기한 모든 사람들은 저마다의 성장 스토리를 가지고 있습니다. 다만 한 가지 기술만 연습하면 이런 종류의 작업에 매우 중요한 폭넓은 경험을 쌓기 어려울 수 있다는 점을 말씀드리고 싶어요.

And finally, if you choose to follow a principle, a principle can’t just be any old thing you believe in. You’ll hear a lot of people say they that want to make software easier to use. Or they want to delight their users. Or they want to make things simple. That’s a really big one right now. Everyone wants to make things simple. And those are nice thoughts and maybe kind of give you a direction to go in but they’re too vague to be directly actionable. Larry Tesler likes simplicity. But his principle was this specific nugget of insight: No person should be trapped in a mode. And that is a powerful principle because it gave him a new way of seeing the world. It divided the world in right and wrong in a fairly objective way. So, he could look at somebody selecting text and ask: Is this person in a mode? Yes or no? If yes, he had to do something about that. And likewise, I believe that creators need powerful tools. It’s a nice thought, but it doesn’t really get me anywhere. My principle is that creators need this immediate connection. So I can watch you changing a line of code and I can ask: Did you immediately see the effect of that change? Yes or no? If no, I got to do something about that.
마지막으로, 원칙을 따르기로 했다면 그 원칙이 단순히 오래된 것일 수는 없습니다. 많은 사람들이 소프트웨어를 더 쉽게 사용하고 싶다고 말하는 것을 듣게 될 것입니다. 또는 사용자를 만족시키고 싶다고 말합니다. 또는 일을 단순하게 만들고 싶다고 말하기도 합니다. 지금은 정말 큰 변화입니다. 누구나 일을 단순하게 만들고 싶어 하죠. 좋은 생각이고 방향성을 제시할 수도 있지만 너무 모호해서 직접 실행에 옮기기에는 무리가 있습니다. 래리 테슬러는 단순함을 좋아합니다. 하지만 그의 원칙은 구체적인 통찰의 덩어리였습니다: 어떤 사람도 모드에 갇혀서는 안 된다는 것입니다. 이 원칙은 그에게 세상을 보는 새로운 시각을 제공했기 때문에 강력한 원칙입니다. 그것은 세상을 상당히 객관적인 방식으로 옳고 그름으로 나누었습니다. 그래서 그는 텍스트를 선택하는 사람을 보고 '이 사람이 모드에 빠져 있나요? 예, 아니오? 만약 그렇다면 그는 무언가 조치를 취해야 했습니다. 마찬가지로 크리에이터에게는 강력한 도구가 필요하다고 생각합니다. 좋은 생각이지만 실제로는 아무런 도움이 되지 않습니다. 제 원칙은 크리에이터에게는 즉각적인 연결이 필요하다는 것입니다. 그래야 여러분이 코드 한 줄을 변경하는 것을 보고 물어볼 수 있습니다: 그 변경의 효과를 즉시 보셨나요? 예, 아니오? 그렇지 않다면 뭔가 조치를 취해야 합니다.

And again, all those demos that I showed you came out of me doing that, of me following this principle and letting it lead me to exactly what I needed to do. So if you’re guiding a principle and bodies of specific insight, it will guide you. And you will always know if what you’re doing is right.
그리고 제가 보여드린 모든 데모는 제가 이 원칙을 따르고 그 원칙이 제가 해야 할 일로 정확히 인도하도록 하는 데서 나온 것입니다. 따라서 원칙과 구체적인 인사이트가 있다면 그 원칙이 여러분을 안내할 것입니다. 그리고 자신이 하고 있는 일이 옳은지 항상 알 수 있습니다.

There are many ways to live your life. That’s maybe the most important thing you can realize in your life, is that every aspect of your life is a choice. But there are default choices. You can choose to sleepwalk through your life and accept the path that’s been laid out for you. You can choose to accept the world as it is. But you don’t have to. If there is something in the world you feel is a wrong and you have a vision for what a better world could be, you can find your guiding principle. And you can fight for a cause. So after this talk, I’d like you to take a little time and think about what matters to you. What you believe in. And what you might fight for.
인생을 살아가는 방법에는 여러 가지가 있습니다. 인생에서 가장 중요한 것은 삶의 모든 측면이 선택이라는 사실입니다. 하지만 기본 선택이 있습니다. 인생의 몽유병에 빠져 정해진 길을 받아들이는 것을 선택할 수도 있습니다. 세상을 있는 그대로 받아들이기로 선택할 수도 있습니다. 하지만 그럴 필요는 없습니다. 세상에 잘못되었다고 생각하는 것이 있고 더 나은 세상에 대한 비전이 있다면, 그 비전을 실현하기 위한 원칙을 찾을 수 있습니다. 그리고 대의를 위해 싸울 수 있습니다. 그러니 이 강연이 끝나면 잠시 시간을 내어 자신에게 중요한 것이 무엇인지 생각해 보시기 바랍니다. 여러분이 무엇을 믿는지. 그리고 무엇을 위해 싸울 수 있는지.

Thank you. 감사합니다.