값의 가치 (The Value of Values)

• Speaker: Rich Hickey
• Conference: JaxConf 2012 (opens new window) - July 2012
• Video: https://www.youtube.com/watch?v=-6BsiVyC1kM (opens new window)

[Google Bard 요약] Value Of Values는 Rich Hickey가 2014년에 발표한 컨퍼런스 연설의 텍스트입니다. 이 연설에서 Hickey는 정보와 사실의 개념을 탐구하고, 정보가 어떻게 가치를 창출하는지 설명합니다. 그는 또한 정보가 어떻게 우리 생각과 행동에 영향을 미치는지 논의합니다.

Hickey는 정보가 사실의 집합이라고 주장합니다. 사실은 특정 정보가 저장된 장소입니다. 사실에는 get과 set과 같은 작업이 있으며 이러한 작업은 사실이 어떻게 변경되는지 제어합니다. 사실의 위치를 전달하여 사실을 전달할 수 있습니다. 그러나 Hickey는 사실이 장소가 아니라고 주장합니다. 장소는 특정 공간의 특정 부분입니다. 장소는 특정 목적으로 사용됩니다. 메모리 주소와 디스크 섹터는 장소의 예입니다.

Hickey는 정보가 가치를 창출한다고 주장합니다. 정보는 우리 생각과 행동에 영향을 미칩니다. 정보는 우리에게 새로운 것을 배우고, 문제를 해결하고, 결정을 내리는 데 도움이 됩니다. 정보는 또한 우리에게 새로운 것을 창조하고, 새로운 것을 경험하고, 새로운 것을 연결하는 데 도움이 됩니다.

Hickey는 정보가 우리 삶에서 중요한 역할을 한다고 주장합니다. 정보는 우리를 더 나은 사람으로 만들 수 있습니다. 정보는 우리를 더 나은 세상으로 만들 수 있습니다.

그래서 가치의 가치. 여기 IT 부서에서 일하는 사람은 누구인가요? 모두 다요. 그렇군요 그게 무슨 뜻인가요? I.T.가 무슨 뜻이죠?

So The Value of Values. Who here works in I.T.? Everybody, I think. Alright. What does it mean? What does it stand for, I.T.?

IT

정보 및 기술.

Information and Technology.

Information

네, 아니면 다른 것들도요. 그렇다면 여기서 말하는 정보란 무엇을 의미할까요? 다른 키노트를 보시면 아시겠지만, 저는 키노트를 작성할 때 사전을 활용하는데, 사전에는 모든 답이 들어 있기 때문입니다. 제 사전에는 정보란 사실을 통해 지식을 전달한다는 뜻의 '알리다'라는 단어에 기반을 두고 있으며, 그 목적은 마음에 형태를 부여하는 것이라고 나와 있습니다. 그리고 정보는 바로 그러한 사실입니다. 그것이 바로 정보입니다. 정보는 사실입니다.

Yeah, or other things. So what do we mean when we say information? As you may know from my other key notes, all I do to make a key note is I use my dictionary because my dictionary has all the answers. And my dictionary says, information is based on the word inform which means to convey knowledge via facts and the purpose of that is to give shape to the mind. And information is just those facts. That's what information is. Information is facts.

What is Fact?

그렇다면 팩트란 무엇일까요? 사실이란 정보를 저장하는 공간이며, 모든 정보를 저장할 수 있는 공간이 있다는 점이 가장 큰 장점입니다. 팩트에는 get, set과 같은 연산이 있으며 다른 연산도 있을 수 있습니다. 이러한 연산은 사실이 어떻게 변할 수 있는지를 제어합니다. 사실의 또 다른 장점은 사실을 전달하기 쉽다는 것입니다. 사실을 전달하려면 그 위치만 전달하면 됩니다. 지금 얼마나 많은 사람들이 불편을 겪고 있을까요?

So what's a fact? Well, fact is a place where information is stored and what's great about that is that there's a place for every piece of information. Facts have operations like get and set and they may have other operations. Those operations control how facts can change. The other great thing about facts is that it's easy to convey them. To convey a fact, we just convey its location. How many people are uncomfortable right now?

맞아요. 사실이 아니죠? 이건 틀렸어요. 내가 방금 한 말은 전부 틀렸어. 완전히 틀렸어. 그리고 당신은 불편해야합니다. 이것은 사실이 아닙니다.

I am. This is not true, right? This is wrong. Everything that I just said was wrong. Dead wrong. And you should be uncomfortable. This is not what facts are.

Place

그렇다면 팩트 플레이스는 어떤 곳일까요? 글쎄요, 장소란 무엇인가요. 다시 사전으로 돌아가 보겠습니다. 장소는 공간의 특정 부분이며 공간은 중요한 단어입니다. 이에 대해서는 나중에 자세히 살펴보겠습니다. 특히 장소와 관련하여 중요한 부분은 장소가 구분되어 있다는 사실입니다. 장소로 명명된 위치에는 특정성이 있거나 그 반대의 경우도 있습니다. 우리는 장소에 대해 잘 알고 있죠? 일상 업무와 프로그래밍에서 장소에 대한 좋은 예가 있지 않나요? 메모리 주소도 장소이고 디스크 섹터도 장소입니다. 주소가 있고 우리는 그곳으로 갈 수 있고 그 내용을 다른 내용으로 대체할 수 있으며 우리는 장소라는 개념에 매우 익숙합니다.

So are facts places? Well, what's a place. Again, back to the dictionary. A place is a particular portion of space, and space is an important word. We're going to dig into it later. In particular, the part about place that matters is the fact that it's sort of delimited. There's a specificity to the location named by a place or vice versa. We know about places, right? We have good examples of places in our everyday work and programming, right? Memory addresses are places, disk sectors are places. They have addresses and we can go to them and we can substitute their contents with other contents and that we're very familiar with this notion of a place.

Information Systems

하지만 이러한 메모리 위치와 디스크 위치를 통해 우리가 방금 정의한 대로 정보에 관한 정보 시스템을 실제로 구축하고 있는지 생각해 보는 것이 매우 중요하다고 생각합니다. 특히 이번 컨퍼런스에서 우리는 일반적으로 메모리를 사용하고 객체를 사용합니다. 그리고 가변 객체는 장소에 대한 추상화에 지나지 않습니다. 특히 특정 장소 또는 특정 가변 객체에 대한 작은 추상화이며 메서드가 있습니다. 앞서 말씀드린 팩트에는 메서드가 있고 객체에는 메서드가 있다고 말씀드린 것처럼 말입니다. 이것이 우리가 시스템을 구축하는 핵심입니다. 다른 한편으로, 내구성 측면에서도 같은 종류의 개념이 있습니다. 테이블, 문서, 레코드 등 모든 것이 장소이며 모두 업데이트 개념이 있습니다.

장소에 가서 새로운 가치로 설정한다는 개념과 같은 것이죠. 이러한 개념은 우리가 시스템을 구축하는 기반이지만, 그 위에 추상화하여 그 내용을 숨기지 않는 일종의 추상화를 만들고 있습니다.

But I think it's quite important to think about whether or not with these memory places and disk locations we're actually building information systems that are about information as we just defined it. In particular, we use memory and we use objects typically, especially at this conference. And mutable objects are nothing more than abstractions over places. They're little abstractions that are over places especially or often particular mutable objects, and they have methods. Just like the thing I talked before about facts having methods and objects have methods. This is the core thing we're building systems out of. On the other side, on the durability side, we have the same kinds of notions. We have tables and documents and records, all of which are places, all of which have an update notion.

Like the notion of going to the place and setting it to be a new value. These are the underpinnings from which we build systems but we're sort of making abstractions on top of them that don't hide what they're about.

PLOP

이에 대한 단어 또는 용어가 있는데, 저는 이를 PLOP이라고 부릅니다. 위치 지향 프로그래밍이란 바로 이런 것을 말하며, 새로운 정보가 이전 정보를 대체할 때마다 위치 지향 프로그래밍을 하고 있다는 것을 알 수 있습니다. 우리가 위치 지향 프로그래밍을 하는 이유는 컴퓨터 초창기에는 위치 지향 프로그래밍을 해야 했기 때문입니다. 가이 스틸이 4킬로바이트의 메모리를 가진 컴퓨터에서 이러한 시스템을 구축하는 것에 대해 이야기하는 멋진 강연을 본 적이 있습니다. 모든 메모리에서 주소를 알고 있었고, 2000부터 시작하는 짝수 주소는 점프 테이블에 사용되었고, 여기 있는 다른 주소는 데이터에 사용되었으며, 주소의 다른 부분은 코드에 사용되었다는 것을 알고 있었습니다. 때로는 두 가지 이상의 용도로 사용되기도 했는데, 예를 들어 지금은 아무도 이것을 코드에 사용하지 않으므로 데이터에 사용할 수 있고 그 반대의 경우도 마찬가지였습니다. 그렇게 해야만 했습니다. 다른 일을 할 수 있는 용량이 충분하지 않았습니다. 컴퓨터 메모리는 정말 작았습니다. 디스크는 매우 작았습니다. 모든 것이 매우 비쌌습니다. 그래서 저희는 장소 조작을 기반으로 하는 프로그래밍 방식을 채택했습니다. 완전히 말이 되더군요. 여기서 핵심 키워드는 말이 된다는 것입니다. 예전에는 말이 되곤 했죠. 이제 그런 한계는 사라졌습니다. 제가 프로그래밍을 해온 시간 동안 이 두 가지의 용량은 백만 배나 증가했습니다. 백만 배요. 어떤 사물의 크기가 백만 배로 커졌을 때 그 사물에 대해 알고 있는 사실이 그대로 유지되는 다른 어떤 것이 있을까요? 여러분의 자동차가 지금보다 백만 배 더 커졌다고 상상해 보세요. 어떤 규칙이 여전히 적용될까요? 어떤 특성이 여전히 사실일까요? 거의 모든 것이 달라졌지만, 우리는 훨씬 더 작았을 때 내린 결정을 그대로 유지하며 앞으로 나아가고 있습니다. 그렇다면 왜 여전히 PLOP이 지배할까요?

And I have a word for this or a term for this which I call, PLOP. PLace-Oriented Programming, which is what this is and you can tell when it's going on because anytime new information replaces old information, you're doing Place-Oriented Programming. There's a reason we do Place-Oriented Programming because way back in the early days of computers, we had to do Place-Oriented Programming. I saw Guy Steele give a great talk where he was talking about working, you know, building these systems on a computer that had four kilowords of memory. In every piece of memory, you knew the address, you knew the even number addresses starting at 2000 were used for jump table and these other addresses over here where used for data, and other parts of the addresses were used for code. Sometimes they were used for more than one thing because you knew, like right now, no one's using this for codes so we can use it for data and vice versa. You had to do it. There wasn't enough capacity to do anything else. Computer memories were really small. Disks were very small. Everything was very expensive. So we adopted an approach to programming that was based around the manipulation of places. It totally made sense. And the keyword there, the key aspect to that is it made sense. It used to make sense. Those limitations are gone. In the time that I've been doing programming, the capacity of these two things have increased a millionfold. A millionfold. What other thing in life you know has the same facts about it remain true when the size of something changes by a millionfold. Imagine if your car was a million times bigger than it is. What rules would still apply? What characteristics would still be true? Almost nothing but yet, we're retaining decisions we made when things were much much smaller and moving forward with it. So why does PLOP still rule?

Memory and Records

이것이 바로 여기서 중요한 질문입니다. 객체지향 프로그래밍에 대해 이야기할 때 흔히 메모리와 레코드, 이 두 가지에 대해 이야기합니다. 이 단어들은 컴퓨터가 있기 전부터 의미가 있었습니다. 그리고 우리는 그 의미를 이어받았습니다. "메모리는 RAM 칩의 주소를 의미하고 레코드는 데이터베이스 테이블의 슬롯을 의미합니다."라고 말했죠. 물론 단어의 수에는 한계가 있고 유추가 대충 맞아떨어지긴 하죠? 머릿속에서 기억과 기억 사이의 유추가 대충 맞아떨어지지만 문제는 우리가 이 일을 너무 오랫동안 해왔기 때문에 이런 것들이 무엇을 의미하는지에 대한 우리 자신의 신화를 믿고 있다는 것입니다. 하지만 기억과 기록의 사실로 돌아가야 합니다. 기억은 개방형 시스템이라는 사실입니다. 친구가 새 이메일 주소를 받았다고 해서 뇌에서 친구의 이메일 주소 셀을 찾아서 그 부분의 뉴런에 친구의 이메일 주소를 대체하는 것은 아닙니다. 뇌는 그렇게 작동하지 않습니다. 기억은 그렇게 작동하지 않습니다. 기억은 본질적으로 개방형 시스템이자 연상 시스템입니다. 주소 기반 시스템이 아닙니다. 기록 보관도 마찬가지입니다. 우리는 컴퓨터가 있기 전에 기록을 보관했습니다. 어떻게 했나요? 석판을 꺼내서 깎아내거나 파피루스를 꺼내서 거기에 무언가를 적었습니다. 새로운 정보를 얻었을 때 우리는 어떻게 했나요? 우리는 가서 대리석을 다듬고 새로운 것을 깎아내지 않았습니다. 파피루스에 가서 지우개 같은 것을 꺼내지 않았습니다. 컴퓨터가 나오기 전에 사람들이 회계 시스템을 만들 때 지우개도 사용하지 않았죠? 그들은 무엇을 사용했나요? 복식부기 회계 또는 원장 기반 회계를 사용했죠. 수정 입력만 했죠. 지우개를 가지고 돌아가지 않았죠. 컴퓨터가 나오기 전에는 그런 방식이 아니었죠.

That's the key question here. When we talk about Place-Oriented Programming, we often talk about these two things, memory and records. These words had meanings before we had computers, yeah? And we've taken them over. We've said, "Memory means addresses in RAM chips and records mean slots in database tables." And worse than just taking over these words, because obviously there's a limitation to a number of words and the analogies roughly hold, right? The analogies between memory and memory in your head roughly hold but the problem is, we've now been doing this for so long that we believe our own myths about what these things mean but we should go back to the facts of memory and records. The fact of memory is that it's an open system. If your friend gets a new email address, that doesn't go to your brain and find your friend's email address cells and replace his email address in that part, in those neurons in your brain. That's not how brains work. That's not how memory works. Memory is essentially an open system and an associative system. It is not an address-based system. Same thing, record keeping. We used to keep records before we had computers. What did we do? We took out the stone tablets and we chiseled the thing or we took out the papyrus and we wrote stuff there. When we had new information, what did we do? We did not go and smoothed over the marble and chiseled new stuff. We didn't go to the papyrus and take out erasers and things like that. When people built accounting systems before there were computers and they didn't use erasers either, right? What did they use? Double-entry accounting or ledger-based accounting. They only made correcting entries. They did not go back with erasers. That's not the way things worked before we had computers.

Value

이 이야기는 가치에 관한 이야기입니다. 가치를 정의해야 하는 또 다른 용어이므로 다시 한 번 사전으로 돌아가 보겠습니다. 가치에 대한 매우 흥미로운 정의가 몇 가지 있습니다. 첫 번째는 '상대적 가치'이며, 상대적인 것은 가치의 매우 중요한 측면입니다. 그다음은 특히 컴퓨터에서 가장 친숙할 수 있는 정의입니다. 다음 정의는 42에 적용되는 정의이기 때문이죠? 크기입니다. 숫자입니다. 우리가 다른 것을 측정하는 데 사용하는 개념이며, 가치라는 개념은 우리가 가장 쉽게 적응할 수 있는 개념이라고 생각합니다. 하지만 더 큰 가치의 개념은 의미와 비교 가능성, 상대적 가치에 관한 것입니다. 무언가를 측정할 때는 다른 무언가를 기준으로 측정해야 하기 때문에 이것이 더 큰 가치 개념입니다. 절대적인 측정값은 없습니다. 비교하는 부분이 중요합니다.

This talk is about values. It's another term we should define, and again, we just go back to the dictionary. There's some very interesting definitions for value. First is 'relative worth' and relative ends up being a very critical aspect of values because the next thing is the one is the one you're most probably familiar with especially in computer. Because this next definition is the one that applies to like 42, right? It's a magnitude. It's a number. It's something we use to measure something else and that notion of a value, I think, is the one we're most readily able to adapt. But again, the bigger notion of value is about meaning and about comparability and about relative worth. That's the bigger notion of value because when you measure something, you have to measure it in terms of something else. There's no absolute measurements. The comparing part is important.

Is a String a Value?

지금 질문은 '문자열이 값일까요?"입니다. 얼마나 많은 사람이 그렇게 생각하나요? 저는 이 문제를 좋아합니다. 모든 사람이 손을 들고 있는 것은 아니니 손을 들어 질문에 답하세요. 문자열이 값이 아니라고 생각하는 사람은 몇 명인가요? 얼마나 많은 사람이 '상황에 따라 다르다'고 생각하나요? 여러분은 항상 '상황에 따라 다르다'를 기다리죠? 그게 가장 좋은 답이니까 기다리는 거죠. 무엇에 따라 달라질까요? 불변인가요? 문자열이 불변이면 값입니다. 불변이 아니라면 값이 아닙니다. 프로그래밍 언어에서 일하거나 문자열이 변경 가능한 작업을 하는 사람이 얼마나 될까요? 돌아가고 싶은 사람이 몇 명이나 되나요? 아니요, 우리는 이걸 좋아하지 않습니다. 왜냐하면 지금 문자열은 무언가를 측정하지 않기 때문입니다. 크기나 양이 아니죠. 이러한 가치의 정의와 일치하지 않지만, 결국 불변의 문자열은 비교 가능한 것이 됩니다. 비교 가능성은 우리가 '이것은 어제와 같다'라고 말할 수 있을 때까지 논리를 수행하고 의사 결정을 내릴 수 있는 능력에서 비롯됩니다. 어제보다 더 큰가, 아니면 더 작은가? 이 문자열은 내가 이해한 바에 따라 이 사물을 올바르게 표시하고 있는가?"라고 말할 수 있습니다. 또는 우리가 정보로 하는 다른 모든 작업에서 비교 가능성 및 동일성 테스트는 일종의 맨 아래에 있으며, 이는 다른 가치 개념으로 돌아갑니다. 그래서 우리는 정말 돌아가고 싶지 않습니다.

The question right now is, 'Is a string a value?' How many people think it is? I love doing it, answer the questions by raising hands because not everybody has hands, by the way. How many people think a string is not a value? How many people think it depends? You always wait for 'it depends,' right? It's the best answer so you hold out for it. What does it depend on? Is it immutable? If the string is immutable, it's a value. If it's not immutable, it's not a value. How many people worked in programming languages or do work where strings were mutable? How many people want to go back? No. We don't like this. And it ends up that this equality notion of value because right now, string doesn't measure something, right? It's not a magnitude or an amount. It doesn't correspond to that definition of value, but it ends up that an immutable string is a comparable thing. Comparability is where we derive our ability to do logic and to make decisions until we can say, "This is the same as it was yesterday. Is it greater or less than what it was? Does this string label this thing correctly according to my understanding of it." Or anything else we do with information and that comparability and equality test is sort of at the bottom and that goes back to the other notion of value. So we really do not want to go back.

Programming Values

이제 사전적 정의가 아닌 프로그래밍에서 우리가 하는 일의 관점에서 매우 구체적으로 값에 대해 이야기하고자 합니다. 여기에는 많은 뉘앙스가 있지만 이 강연의 목적상 30분이라는 시간을 감안하여 값은 불변이고 값은 의미적으로 투명하다는 것에 초점을 맞추겠습니다. 값의 목적은 여러분이 비교와 동등성 테스트를 할 수 있도록 스스로를 노출시키는 것입니다. 가치는 메서드에 무언가를 캡슐화하여 실행하는 것이 아닙니다. 가치는 "나를 다른 것과 비교해보세요. 나의 정확한 의미 또는 나의 중요성이 무엇인지 말해주는 것입니다."라고 말하는 것입니다. 바로 라벨에, 바로 겉면에. 이것이 바로 가치입니다.

So now we want to talk about values, not from the dictionary definition but very specifically in terms of what we do in programming. There are lots of nuances to this but for the purpose of this talk, given that it's a half hour, I'm just going to focus onto values are immutable and values are semantically transparent. The purpose of a value is to expose itself to you so you can do that comparison and that equality test. Value's not about encapsulating something in methods and doing things. Value's about saying, "Compare me to something else. I'm telling you what my precise meaning or my significance is." Right on the label, right on the outside. That's what a value is about.

Value Propositions

이 강연을 하는 이유는 값(value)의 가치(value) 제안에 관한 것입니다. 무엇이 값을 좋게 만들까요? 원래 이 강연은 한 시간 분량이라 조금 빠르게 진행될 예정이지만, 값에는 몇 가지 특징이 있습니다. 첫 번째는 값를 공유할 수 있다는 것입니다. 값이 있다면, 불변하는 것이 있다면 그것을 다른 사람에게 주고도 걱정하지 않을 수 있을까요? 네, 걱정할 필요가 없습니다. 이제 둘 다 같은 가치를 참조하기 때문에 걱정할 필요가 없나요? 걱정해야 할 사람이 있나요? 아니요. 가치를 공유할 수 있습니다. 이는 매우 중요한 일입니다. 값은 재현 가능한 결과를 지원합니다. 함수를 정의할 때마다 동일한 값으로 함수를 호출하면 동일한 답을 얻을 수 있을까요? 그렇습니다. 함수를 매번 호출할 때마다 위치로 함수를 정의하면 같은 답을 얻을 수 있을까요? 아니요. 장소에 따라 다릅니다. 재현 가능한 결과가 정말 중요합니다. 테스트를 실행하고 재현 가능한 테스트를 실행할 수 있습니다. 현재 많은 사람들이 장소에 대한 테스트를 실행하고 있습니다. 그들은 당신에게 아무것도 말해주지 않습니다. 모두 해당 장소를 동일한 장소로, 동일한 가치로 되돌릴 수 있는 능력을 조건으로 합니다. 값의 또 다른 중요한 측면은 조작하기 쉽다는 것입니다. 어떤 프로그래밍 언어로든 값을 처음부터 아주 쉽게 만들 수 있습니다. 어떤 프로그래밍 언어로든 문자열을 만들 수 있나요? 네. 문자열 목록을 만들 수 있나요? 네. 숫자 목록은요? 네. 숫자 목록의 목록? 그래 숫자 목록의 지도를 만들 수 있나요? 그럼요. 이 멋진 인터페이스의 인스턴스를 다른 언어로 만들 수 있나요? 아니요, 그건 제작하기 쉽지 않아요. 프로그램을 작성하는 프로그램을 만드는 것도 쉽지 않죠. 테스트를 작성하는 프로그램을 만드는 것도 쉽지 않습니다. 값을 기반으로 하는 프로그램이 아니라면 값이라는 사실을 쉽게 조작할 수 있는 것이 중요합니다.

The reason to give this talk is sort of the value propositions of values. What makes values good? Originally, this talk was an hour long so this is going to go a little bit fast but there's a bunch of characteristics of values that are valuable. The first is that values can be shared. If you have a value, if you have an immutable thing, can you give that to somebody else and not worry? Yes, you don't have to worry. Do they have to worry about you now because they both now refer to the same value? Anybody have to worry? No. Values can be shared. That's very, very valuable. Values support reproducible results. If you define a function in terms of values every time they call that function with the same values, will you get the same answer? Yes. If you define a function in terms of places every time you're on that function, will you get the same answer? No. It depends what's in the place. Reproducible results really matter. They allow you to run tests and reproducible tests. So many people running tests now of places. They don't tell you anything. They're all conditional upon your ability to bring that place back to the same place, to the same value. Another critical aspect of values is that they're easy to fabricate. You can make up a value from scratch in any programming language quite readily. Can you make a string in any programming language? Yeah. Can you make a list of strings? Sure. A list of numbers? Yeah. A list of a list of numbers? Yeah. A map of a list of numbers? Yeah. Can I make an instance of your fancy interface in any other language? No. It's not easy to fabricate that. It's not easy to make programs that write programs. It's not easy to make programs that write tests. If your programs are not based around values so the fact of values are easy to fabricate is important.

알겠습니다. 값은 언어와 무관합니다. 방금 그 얘기를 했잖아요. 목록, 문자열, 숫자 또는 지도의 개념입니다. 이것은 프로그래밍 언어와는 아무 상관이 없습니다. 제가 방금 말한 것들요. 전혀요, 그렇죠? 그런 것들의 집합체도 그것과 아무 관련이 없습니다. 일반적인 개념이죠? 이러한 아이디어, 가치의 개념은 일반적입니다. 그리고 저는 우리가 프로그래밍 설계와 시스템에서 특수성의 실제 원인에 대해 충분히 자주 생각하지 않는다고 생각합니다. 우리는 구체성을 좋아합니다. 우리는 Java를 사용합니다. 모든 새로운 아이디어에는 새로운 클래스가 있습니다. 모든 새로운 사물은 새로운 것을 얻습니다. 그러면 어떤 일이 발생하나요? 코드가 폭발적으로 증가하기 때문입니다. 코드가 엄청나게 폭발적으로 증가합니다. 객체는 재사용을 지원해야 하는데, 특히 타입 언어에서는 정반대로 작동합니다. 매번 새로운 것을 만들기 때문에 재사용이 거의 이루어지지 않는데, 코드가 많아진다는 것은 무엇을 의미할까요? 코드가 많다는 것은 버그가 많다는 뜻입니다. 바로 그거죠.

값에 대한 또 다른 흥미로운 점은 값과 값의 집합이며, 이 부분에 집중해 주셨으면 합니다. 42에 대해 이야기했습니다. 문자열에 대해 이야기했습니다. 일종의 원자적인 것에 대해 이야기했습니다. 하지만 불변하는 것의 목록은 그 자체로 불변하는 것이고 그 밖에도 여러 가지가 있습니다. 그래서 집합을 구축할 때 더 큰 것들도 가치인데, 우리는 여기서 멈추는 경향이 있다고 생각합니다. "당연히 문자열은 불변이어야 하는데 불변의 집합이라고? 도저히 이해할 수 없어."라고 말하죠. 하지만 이해해야 합니다. 불변 문자열과 동일한 바람직한 속성을 모두 가지고 있기 때문입니다. 더 이상 변경 가능한 문자열을 가진 프로그램을 원하는 사람은 없습니다. 변경 가능한 컬렉션을 가진 프로그램을 더 이상 원하지 않는 이유는 무엇일까요? 그럴 필요가 없으며 이렇게 함으로써 얻을 수 있는 정말 중요한 이점이 있습니다. 예를 들어 객체와 비교해 보겠습니다. 어떤 객체가 있는데 이를 공유하고자 한다면 어떻게 해야 할까요? 객체를 정의하고, 객체에 대한 인터페이스를 정의하고, 그 밖의 모든 것을 정의한 다음에는 무엇을 해야 할까요? 동시 접속 환경이라면 어떻게 해야 할까요? 그 객체에 대해 무엇을 해야 할까요? 일종의 잠금 정책 같은 거겠죠? 아주 아주 어려운 일이죠. 사실 많은 언어가 이를 잘 정의할 수 있는 리소스를 제공하지 않습니다. 마치 냅킨이 있고 그 위에 이 객체를 어떻게 사용할지 정의한 것과 같습니다. 하지만 그렇게 정의했는데 어떻게 복사할지, 복제 시맨틱은 무엇인지 등 다른 종류의 문제가 발생할 수 있습니다. 이 작업을 완료하고 모든 클래스에 대해 이 작업을 수행한 후 이제 이러한 것들을 조합한 무언가를 만든다고 가정해 보겠습니다. 아니요. 모든 것이 사라집니다. 모든 것을 다시 해야 합니다. 잠금 정책이 있는 이 모든 것들의 복합체는 이제 더 이상 잠금 정책이 없습니다. 새로운 정책을 만들어야 합니다. 새로운 복제 정책과 다른 모든 것을 다시 만들어야 합니다. 값은 값으로 집계됩니다. 모든 혜택은 집계에 적용됩니다.

Alright. Values are language independent. So I just talked about that already. The notion of a list or string or number or a map. This has nothing to do with the programming language. Those things I just said. Nothing at all, right? Nor any of the aggregates of those things has nothing to do with that. They're generic, right? These ideas, the notions of values are generic. And I think it's something that we don't think about often enough in our programming designs and our systems that the actual cause of specificity. We love specificity. We use Java. Every new idea gets a new class. Every new thing gets a new thing. What does that cause to happen? We get this explosion of code. Just a tremendous explosion of code. Objects were suppose to support reuse that done the exact opposite thing especially in typed languages. You get very little reuse because you make a new thing every time, and what does more code mean? More code equals more bugs. Right away.

Another interesting thing about values is values aggregate to values and this is something I really want you to focus on. We talked about 42. We talked about a string. We talked about a sort of atomic thing. But a list of immutable things is itself an immutable thing and so on and so forth. So as you build aggregates, those bigger things are also values, and I think that we tend to stop. We say, "Of course, strings should be immutable but an immutable collection? Oh, I can't even comprehend it." But you should. It has all the same desirable attributes that that immutable string did. Nobody wants a program with mutable strings anymore. Why don't you want a program with mutable collections anymore? You shouldn't and there's really important benefits you get from doing this. For instance, compare it to objects. If you have an object and you want to share it, what do you want to do? You have to define the object, define the interface for it and everything else but then you have to do what? What if it's in a concurrent environment? What do you have to have for that object? Some sort of locking policy, right? Very, very difficult thing. In fact, a lot of languages don't give you any resources for defining it well. It's like there's this napkin and on it, we defined how we're going to use this object. But if you've done that and there's also other kinds of problems like, how do you copy it, what are the cloning semantics, whatever. Let's say you've done that work and you've done that work for everyone of your classes and now, you build something that's a composite of those things, do you get a lock policy from combining them? No. It all falls away. You have to do it all, do over again. This composite of all these things for which I have lock policies now no longer has a lock policy. I have to come up with a new one. I have to come up with a new cloning policy and everything else over again. Values aggregate to values. All the benefits apply to aggregates.

가치를 통해 얻을 수 있는 다른 이점도 많으며, 우리는 이를 항상 목격합니다. 가치는 전달하기 쉽습니다. 내가 유용하다고 생각하는 정보가 있다면 그 가치를 전달할 수 있고, 내가 보고 있던 것을 전달했다는 것을 알 수 있습니다. 제가 흥미로운 것을 보고 제가 본 장소를 여러분에게 전달한다면, 실제로 제가 여러분에게 전달한 것은 무엇일까요? 아무것도 아니죠? 여러분이 그 장소에 가서 제가 본 것과 완전히 다른 것을 본다면 정보가 아닌 것이 확실합니다. 다른 방식으로도 작동합니다. 내가 무언가를 인식하고 싶을 때, 그것이 가치라면, 특히 그것이 가치의 집합이고 복합적인 것이라면, 나는 시간을 들여서 그것을 볼 수 있습니다. 장소를 중심으로 무언가를 인식하고 싶다면 어떻게 해야 할까요? 시작해서 살펴보고 싶은 장소가 많은데 어떻게 해야 할까요? 세상을 멈춰야 해요. 그렇지 않으면 한 곳을 바라보다가 다른 곳으로 고개를 돌리면 무언가가 바뀌어서 전체를 인식할 때쯤에는 일관된 것이 없다는 것을 알 수 있기 때문입니다. 일관된 무언가를 기반으로 결정을 내리는지 모르겠습니다.

이것도 기억과 관련이 있습니다. 어떻게 기억을 하나요? 프로그램 실행 중에 어떤 객체를 만났는데 기억하고 싶으면 어떻게 하나요? 그냥 참조를 저장하면 됩니다. 그것만으로는 충분하지 않죠? 그럼 어떻게 해야 할까요? 복제해야 합니다. 어떻게 복제하나요? 상황에 따라 다르죠. 바로 그거야. 상황에 따라 다르죠.

There are other benefits you get from values and we see these all the time. Values are easy to convey. If I have some piece of information I think is useful, I can send you that value and I know I've communicated to you what I was seeing. If I see something interesting and I communicate to you the place where I saw it, what have I actually conveyed to you? Nothing, right? Not the information, that's for sure because if you go look at that place and see something totally different from what I saw. It works the other way as well. When I want to perceive something, if it's a value, I can take my time and look at it especially if it's a set of values, if it's a composite thing. If I want to perceive something that's based around places, how do I do that? There's a bunch of places I want to start and look at it, what do I have to do? I have to stop the world. Please stop while I look at these places, because otherwise, I'll look at one and as I turn my head to the other, something will change and by the time I sort of perceived the whole thing, I don't know they had anything consistent. I don't know they're making a decision based on anything consistent.

This also goes to memory. How do you remember anything? If you encounter an object during the course of your program running and you want to remember it, what do you do? You just store the reference. Not good enough, right? What do you have to do? Clone it. How do you do that? It depends. Exactly. It depends.

제가 여러분에게 바라는 또 다른 한 가지는 이러한 가치 제안이 시스템으로 확장되고 특히 가치가 최고의 인터페이스를 만들기 때문에 상자보다 더 크게, 프로세스보다 더 크게 생각하기 시작하라는 것입니다. 이제 여기서 더 이상 논쟁의 여지가 없다고 생각합니다. 이미 하고 있는 일이라고 생각합니다. 유선으로 무엇을 보내시나요? 아직도 CORBA나 DCOM을 사용하시나요? 아뇨, 없어요 다 이유가 있어서 죽었잖아요? 이제 우리는 값을 사용합니다. 필요한 경우 JSON이나 XML을 보내기도 하지만, 둘 다 값의 표현입니다. 따라서 양쪽 끝에서 쉽게 변경할 수 있는 인터페이스를 구축할 수 있습니다.

값의 또 다른 측면은 특히 큰 규모에서 매우 흥미롭지만 작은 규모에서도 마찬가지라는 것입니다. 세상을 잠그고 나면 어떤 것을 어떻게 인식하는지에 대해 이야기했었죠? 이는 큰 차원에서도 마찬가지입니다. 읽기 트랜잭션에 대해 들어본 사람이 얼마나 되나요? 네. 읽기 트랜잭션을 좋아하는 사람은 얼마나 되나요? 아니요. 전체 아이디어가 직관적이지 않고 물리학에 위배됩니다. 물리학에서는 서로를 바라보기만 하면 됩니다. 사물을 보기 위해 모든 것을 멈출 필요는 없습니다. 따라서 값으로 프로그래밍하고 특히 스토리지에서 값을 사용할 때 다시 한 번 조정이 줄어듭니다.

또 다른 이점은 위치 유연성입니다. 소규모로 시스템을 구축하고 값을 전달하는 프로세스로 시스템을 정의한 후 "저기요? 시스템의 해당 부분을 더 빠른 언어로 다시 작성하거나 다른 상자에서 실행하고 싶습니다."라고 결정할 수 있습니다. 프로그래밍 언어와 관련된 객체 및 특정 사항을 사용하는 경우 이러한 작업을 수행하는 것이 간단할까요? Java 인터페이스를 전달할 때 다시 작성하는 것이 쉬운가요... 아니면 Ruby 인터페이스라고 가정할 때 Java로 다시 작성하는 것이 쉬운가요? 아니요. 하지만 큰 틀에서는 그렇게 하지 않습니다. 크게 보면 이렇게 하지 않습니다. 크게 보면 우리는 값을 전달하지만, 작게 보면 프로그래밍 언어에서 불쾌한 일을 하기 시작합니다. 그리고 이러한 불편한 작업 때문에 물건을 옮길 수 없게 됩니다. 다른 스레드로 옮길 수 없습니다. 다른 언어로 옮길 수도 없고요. 다른 상자로 옮길 수도 없고요. 하지만 값을 사용한다면 가능합니다. 이를 저는 위치 유연성이라고 부릅니다.

The other thing I want you to do is start thinking bigger, bigger than your box, bigger than your process because these value propositions extend to your systems and in particular, values make the best interfaces. Now here, I don't think we have any arguments. I think we're already doing this. What do you send around on the wire? Anybody still using CORBA or DCOM? No, no. They died for good reasons, right? We now use values. We send around JSON or XML or you know, if you have to, but both are representations of values. And that allows us to build interfaces to things that are easy to change on both ends.

The other aspect of values is it's very interesting especially in the large but it's also true in the small, right? We talked about how do I perceive something after I lock the world down? That applies in the large as well. How many people have ever heard of read transactions? Yeah. How many people like read transactions? No. The whole idea is counter-intuitive and violates physics. In physics, we just look at each other. We don't have to stop everything in order to look at things. So when we're programming with values and using values especially in storage, we, again, have reduced coordination.

Another benefit we get is location flexibility. If in the small you build a system and the system is defined in terms of processes that are communicating values, and you decide, "You know what? That part of the system, I want to re-write that in a faster language or I want to run that on a different box." Is that straightforward to do if you're using objects and specific things related to your programming language? If I'm passing Java interfaces, is it easy for me to re-write... or let's say Ruby interfaces, is that easy for me to re-write that in Java? No. But we know, we don't do this in the large. In the large, we don't do this. In the large, we communicate values but in the small, in a programming language, we start doing icky things. And those icky things keep us from being able to move stuff. We can't move it to another thread. We can't move it to another language. We can't move it over to another box. But if we're using values, we can. That I would call location flexibility.

Facts are Values

이제 정보 기술로 돌아가서 사실로 돌아가 보겠습니다. 사실에 대한 첫 번째 사실은 사실(fact)은 값이라는 것입니다. 사실이 장소가 아닙니다. 앞의 슬라이드는 거짓말이었습니다. 여기 있는 모든 사람이 "하지만 사실은 변하지 않나요? 한때는 대통령이 있었지 않았나요? 새 대통령도 있지 않나요?"라고 묻습니다. 아니요, 사실에는 시간이 포함되기 때문에 변하지 않습니다. 어떻게요? 그게 무슨 뜻일까요? 다시 말하지만, 사전은 모든 것을 알고 있습니다. 사실이란 무엇을 의미할까요? 사실이란 일어난 일, 일어났거나 존재했던 것으로 알려진 것을 의미합니다. 라틴어에서 유래한 이 단어는 과거 분사 라틴어에서 유래한 것으로, 일어난 일을 의미합니다. 사실은 일어난 일입니다. 장소가 아닙니다. 바꿀 수 있는 것이 아닙니다. 빌 클린턴은 대통령이었습니다. 그가 대통령이었다는 사실은 언제나 사실일 것입니다. 우리는 새로운 대통령을 가질 수 있습니다. 새로운 이메일 주소를 사용할 수 있는 것처럼 새로운 사실이죠.

So let's get back to information technology and back to facts. The first fact about facts is that facts are values. They're not places. That slide upfront was a lie. Everybody in here's saying, "But don't facts change? Don't we have a president at one time? Don't we have a new president?" No, they don't because facts incorporate time. How is that? What does that mean? Again, the dictionary knows everything because what does fact mean? Fact means something that happened, something known to have happened or existed. It comes from Latin and it comes from a past participle Latin that means something that happened. A fact is something that happened. It's not a place. It's not something you can change. Bill Clinton was president. The fact that he was president will always be a fact. We can have new presidents. That's a new fact, just like you can have new email addresses.

Facts! = Recent Facts

사실에 대한 또 다른 중요한 점은 사실을 고려할 때 최근의 사실만으로는 충분하지 않다는 것입니다. 다시 정보의 핵심으로 돌아가 보겠습니다. 정보는 사람들이 지식을 전달할 수 있도록 알려주는 것이지만, 지식은 사실에서 파생됩니다. 우리는 의사 결정을 내릴 때 시간을 비교하고, 서로 다른 두 가지를 비교하고, 사실을 결합하고, 특히 서로 다른 시점을 사용합니다. 세상의 어떤 자산이나 속성의 현재 가치만 알고 있다고 상상해 보세요. 여러분의 의사 결정 능력이 얼마나 향상될까요? 끔찍할 것입니다. 정말 끔찍할 텐데도 우리는 가장 최근의 사실만 알고 있는 시스템을 구축하고 있습니다. 다른 것은 아무것도 모릅니다. 하지만 우리는 정보와 의사 결정 지원 시스템을 만들어야 합니다.

결론은 사실을 업데이트할 수 없다는 것이고, 사실을 업데이트할 수 없는 이유는 과거를 바꿀 수 없기 때문이며, 과거의 문서가 바로 사실이라는 것입니다.

The other thing about facts is that it's very important when you consider facts that it's insufficient for you to consider recent facts. And again, we'll go back to the whole point of information. Information is to inform so that people can convey knowledge, but knowledge is derived from facts. When we try to make decisions, we compare times, we compare two different things, we combine facts and especially we use different time points. Imagine if you only knew the present value of any property or attribute in the world. How good would your decision making capability be? It will be awful. It will be absolutely terrible and yet, we're building systems that only know the most recent set of facts. We don't know anything else. But we're supposed to be making information and decision making support system.

So the bottom line is that you can't update a fact and the reason why you can't update a fact is because you can't change the past and that's what facts are, the documentation of the past.

Information Systems

다시 돌아가서 정보에 관한 정보 시스템을 구축한다는 것이 무엇을 의미하는지 다시 한 번 생각해 보겠습니다. 그것은 시스템이 근본적으로 사실에 관한 시스템이라는 것을 의미합니다. 사실을 유지하고, 사실을 조작하고, 사용자에게 사실을 제시하여 사용자가 의사 결정을 내릴 수 있도록 영향력을 제공하는 것입니다. 지금 우리는 이 일을 하고 있다고 생각하지 않습니까? 정보 기술 분야에서 우리는 의사 결정 지원 시스템인 시스템을 구축하고 있다고 생각하죠? 하지만 우리는 사실 중심의 인프라를 사용하고 있지 않습니다.

사실의 시간적 측면에 도달하기 전에 가장 낮은 수준의 개념에서, 우리는 확실히 가치 지향적인 시스템을 구축해야 합니다. 그렇다고 프로그래밍 언어가 프로세스 지향적인 구조를 가져서는 안 된다는 말은 아닙니다. 물론 그래야 하지만 우리는 이를 구분하지 않습니다. 어떤 프로그램을 보면 두 가지 다른 부분이 있을 것입니다. 프로그램에는 일종의 기계와 같은 부분이 있을 것입니다. 로딩 도크가 있고 물건이 들어오고 컨베이어 벨트를 타고 이동한 다음 분류됩니다. 물건이 분할되어 어떤 물건은 이쪽으로 가고 어떤 물건은 저쪽으로 가죠.

모든 프로그램에는 프로세스 지향적이며 일종의 기계와 같은 측면이 있습니다. 그리고 우리는 작은 기계와 유사한 구조를 사용할 수 있는 프로그래밍 언어를 만들었습니다. 이것들은 일을 합니다. 문제는 우리가 이 기술을 정보를 포함한 모든 것에 적용한다는 점인데, 정보는 작은 기계가 아닙니다. 전혀 기계와 같지 않기 때문에 이러한 프로세스 구조를 분리해야 합니다. 특히 장소와 관련된 모든 구성 요소는 정보 모델에서 전혀 역할이 없다는 점을 명심해야 합니다. 이는 컴퓨터가 작동하는 방식의 아티팩트입니다. 소프트웨어가 정보 관리 및 의사 결정 지원을 수행해야 하는 경우 소프트웨어가 수행해야 하는 작업과는 아무런 관련이 없습니다.

Well, let's go back and sort of revisit what would it mean to build information systems that are about information. It would mean that the systems would be fundamentally about facts. It would be about maintaining facts, manipulating facts and presenting facts to users to give them leverage so they can make decisions. Now, we think we're doing this, right? When we're in information technology, we think we're building systems that are decision support systems? But we're not using infrastructure that's fact-oriented.

In the most bottom level of notion before you even get to the temporal aspect of facts, we should certainly be building systems that are value-oriented. Now, that's not to say the programming languages shouldn't have process-oriented constructs. Of course, they should but we don't distinguish them. If you look at any program, it's going to have two different parts. There's going to be the part of your program that's sort of like a machine. It's got a loading dock and stuff comes in, you put on a conveyer belt and it moves and then, it gets sorted. It gets split and then, some stuff goes over here and some other stuff goes over there.

All programs have this aspect to themselves which is process-oriented and it's sort of like a machine. And we built programming languages that may allow us to use constructs that are analogous to little machines. They do stuff. The problem is we apply that technology to everything including to information and information is not a little machine. It's not at all like a machine and so you have to separate out these process constructs. And in particular, one of the big take-aways should be that place, that all of your constructs related to place have no role at all in an information model. They are artifacts of the way computers work. They have nothing to do with what software is suppose to be accomplishing if your software is supposed to be accomplishing information management and decision support.

Decision Making

이 강연의 가장 큰 장점 중 하나는 우리가 의사결정을 하기 때문에 여러분 모두 이미 알고 계시겠죠? 우리는 스스로 의사 결정을 내리는 데 무엇이 필요한지 잘 알고 있습니다. 우리는 현재와 과거를 끊임없이 비교합니다. 트렌드를 파악하려고 노력합니다. 변화의 속도를 파악하려고 노력합니다. 시간이 지남에 따라 일어난 일들을 더해야 합니다. 거의 항상 시간적 측면이 필요합니다.

One of the great things about this talk is, I think, you all already know this because we do decision making, right? We know what it takes to support our own decision making. We're constantly comparing the present to the past. We're trying to spot trends. We're trying to see the rate of change. We need to add stuff up that's happened over time. We almost always need a temporal aspect.

Programmer I.T.

이것이 사실인지 어떻게 알 수 있을까요? 글쎄요, 정말 간단합니다. 우리는 프로그래머입니다. 우린 할 일이 있죠. 우리만의 작은 사업도 있죠? 물건을 만들죠. 뭘 만들죠? 구체적인 결과물은 무엇인가요? 소스 코드를 만들죠? 그리고 우리가 하는 일에는 운영 측면이 있습니다. 무엇을 하나요? 우리는 프로그램을 실행하고 이 두 가지에 대한 정보를 유지 관리합니다. 프로그래머의 IT를 살펴보겠습니다. 우리가 직접 구축하는 우리 자신의 IT 시스템을 살펴봅시다. 소스 제어. 제자리에서 업데이트되고 있나요? 얼마나 많은 사람들이 소스 제어를 위해 파일 시스템의 디렉터리를 사용하나요? 프로그램에 새로운 수정 사항이 있으면 그냥 디렉토리에 넣으시나요? 손을 들고 싶지 않으신가요? 네, 당연히 아니죠. 제자리에서 업데이트하는 게 아니니까요. 날짜와 시간이 없는 소스 제어 시스템을 사용하는 사람이 있나요? 아니요, 당연히 없죠. 우리가 무슨 일을 하고 있는지 어떻게 알 수 있을까요? 이 정보가 없다면 작은 소프트웨어 비즈니스를 운영하는 데 필요한 결정을 어떻게 내릴 수 있을까요? 절대 안 돼요.

그럼 운영 IT는 어떻게 되나요? 우리는 시스템을 운영하는데, 운영 중인 시스템으로 무엇을 하나요? 로깅합니다. 로깅하고 또 로깅합니다. 무슨 일이 일어나는지 다 기록하죠? 업데이트가 적용된 로그를 사용하시나요? 마지막 지연 시간이 5초였다는 로그를 사용하는 분 있나요? 그래요? 아니요. 모든 항목에 타임스탬프를 찍지 않는 로그를 사용하는 사람은 없나요? 아니요, 당연히 없습니다. 이런 정보가 없다면 시스템이 어떤 일을 하고 있는지 어떻게 이해할 수 있을까요? 어떻게 의사 결정을 내릴 수 있을까요? 저희는 방법이 없다는 것을 알고 있습니다. 방법이 없으니 이렇게 하지 않습니다.

How can I tell you I know this is true? Well, it's really straightforward. We're programmers. We have stuff to do. We have our own little businesses, right? We make stuff. What do we make? What's our concrete artifact? We make source code, right? And then, we have an operations aspect to what we do. What do we do? We run our programs and we maintain information about both these things. Let's look at programmer I.T. Let's look at our own I.T. systems, the ones we build for ourselves. Source control. Is it update in place? How many people use a directory on the file system for source control? And when you have a new edit to your program, you just put it in the directory? You really don't want to raise your hand. No, of course not. It's not update in place. Anybody use a source control system that doesn't have dates and times on stuff? No, of course not. How would we possibly know what we were doing? How can we possibly make the decisions we need to do to run our little software business if we didn't have this information? No way.

Okay, what about our operations I.T.? We run our systems, what do we do with our running systems? We log. We log and log. We keep track of everything that's happening, right? Anybody use an update in place log? Anyone use a log that says the last latency was five? Yeah? No. Anybody use a log that doesn't put time stamps on every entry? No, of course not. How could we possibly understand what our systems were doing if we didn't have this information? How can we make decisions? We know there's no way. No way so we don't do this.

Big Data

빅 데이터. 모든 것이 연결되어 있습니다. 빅 데이터란 무엇일까요? 저는 빅 데이터의 일정 비율이 바로 이것이라고 주장하고 싶습니다. 기업이 프로그래머에게 "당신이 가진 데이터베이스는 내가 마지막으로 말한 것만 기억하고, 당신의 데이터베이스, 로그는 우리 비즈니스에서 일어난 모든 일을 알고 있기 때문에 당신이 내게 준 데이터베이스보다 더 좋습니다. 당신은 모든 것을 알고 있습니다. 모든 일에는 때가 있는 법이죠. 제 데이터베이스에는 그런 정보가 없으니 그걸로 가서 좋은 비즈니스 의사 결정 정보를 찾아보자고요. 마지막 일 외에는 아무것도 기억하지 못합니다.

로그에는 모든 정보가 있습니다. 로그에는 타임스탬프가 있지만, 이 부분에서 우리가 사후 대응을 하고 있다는 점이 정말 안타깝습니다. 로그를 마이닝하면 정보를 참조할 수 있는 훨씬 더 좋은 방법을 알 수 있습니다. 우리는 활용 가능한 방식으로 정보를 저장하는 방법을 알고 있습니다. 로그는 그렇지 않습니다. 로그에 대한 MapReduce는 그렇지 않습니다. 로그도 엉터리로 가득 차 있죠? 프로그램 운영 자체에 대한 정보로 가득 차 있습니다. 거기에는 비즈니스 가치 정보가 있습니다. 아직 이를 저장할 데이터베이스를 구축하지 못했지만 이는 저희의 잘못입니다.

So big data. It's all connected. What is big data? I will contend that a certain percentage of big data is this. It's businesses telling programmers, "That database you have, I like better than the one you gave me because the one that you gave me only remembers the last thing I told it and your database, your logs, they know everything that happened in our business. You know everything. You have times for everything. Let's go mine that, find some good business decision making information because my database, it doesn't have it. It doesn't remember anything other than the last thing.

The logs have all the information. The logs have the time stamps, but I think it's really sort of a shame here because we're being reactive in this area. Mining logs, we know much better ways to reference information. We know how to store information in ways that's leverage-able. Logs are not that. MapReduce over logs is not that. Logs are full of crap, too, right? They're full of stuff about the program operation itself. There is business value information in there. We haven't built databases to store that yet, but that's sort of our fault.

The Space Age

저는 우리가 '우주 시대'라고 부르고 싶은 시대로 나아가고 있다고 생각합니다. 공간은 모든 사물이 있고 모든 사건이 일어나는 무한한 공간이라는 또 다른 정의가 있습니다. 공간의 정의에서 정말 흥미로운 점은 가장 오래된 언어로 된 가장 오래된 정의로 거슬러 올라가면 공간의 정의는 항상 장소와 시간을 모두 포함한다는 것입니다. 공간은 이 두 가지 중 하나에만 적용되는 개념이 아니었습니다. 공간은 항상 두 가지와 연결되어 있으며 여기에는 특정한 물리학적인 측면이 있습니다. 따라서 새로운 것이 실패하지 않는다면, 매일 매일, 24시간 내내, 계속해서 새로운 것을 부를 수 있다면, 당신은 한 장소에서 달리는 것이 아닙니다. 우주에서 달리는 것이죠. 사물의 가장자리가 보이지 않습니다. 구분되지 않습니다. 새로운 자료가 필요하면 얻을 수 있습니다.

S3가 채워지지 않는다면 그것은 클라우드가 아니라 공간입니다. 매번 S3에 파일을 올리고 싶다면 물론이죠. 가장자리가 걱정되시나요? 대부분의 경우 우리는 공간의 한계에 대해 걱정하지 않습니다. 여러분은 그럴지 모르지만 저는 그렇지 않아요.

I think we're moving into what I would like to call The Space Age. One more definition, space, the unlimited expanse in which all things are located and all events occur. What's really interesting about the definition of space is that it has always, if you go back to the oldest definitions in the oldest languages, the definition of space has always incorporated both place and time. It's never been something that applied only to one or the other of those two things. It's always connected to two and there's a certain physics aspect to that. So if new never fails, if you can call new day after day, 24/7, over and over and over again, you are not running in a place. You're running in space. You're not seeing the edges of things. You're not delimited. You need new stuff, you'd get it.

If S3 never fills up, that's not the cloud, that's space. If every time you want to put a file on the S3, sure. Are you worried about the edge of it? I mean, most of the times, we don't worry about the edge of space. I mean, maybe you do but I don't.

New Facts, New Space

따라서 정보 시스템에는 다른 접근 방식이 필요합니다. 새로운 사실에는 새로운 공간이 필요하다고 말해야 합니다. 이것이 장소 지향 프로그래밍의 종말이어야 합니다. 우리는 이 프로그래밍의 시설을 아주 오랫동안 가지고 있었습니다. 이렇게 할 여유가 있다면 다른 일을 할 이유가 있을까요? "로깅을 하고 싶은데 할 수 없잖아?"라고 생각하시는 분 없나요? 내 디스크가 5메가바이트밖에 안 되거든요."라고 생각한 적이 있나요? 수천 달러나 하는 5메가바이트 디스크를 사용해 본 적이 있으신가요? 더 이상 그런 방식은 아니죠? 그러니 이 정도는 감당할 수 있습니다. 이 접근 방식을 취하면 많은 흥미로운 일이 일어날 것입니다. 가비지 컬렉션을 통해 메모리에서 일어나는 많은 일들이 스토리지에서도 일어날 것입니다. 쓰레기가 생길 것입니다.

So information systems should have a different approach. They should say that new facts require new space. This should be the end of Place-Oriented Programming. We've had the facilities of this programming a very long time. If you could afford to do this, why would you do anything else? Anybody feels like, "I wish I could log but I can't? Because my disk is only 5 megabytes." Anybody ever had a 5 megabyte disk that cost thousands of dollars? That's not that way anymore, right? So you can afford to do this. Lots of interesting things will happen when you take this approach. A lot of the things that happen in memory with garbage collection are going to happen with storage. There will be garbage.

Summary

하지만 괜찮습니다. 이런 것들은 우리가 관리 방법을 배우고 있는 것들이니까요. 요약하자면, 안타깝게도 우리는 계속해서 위치 지향 프로그래밍을 사용하고 있고 그 근거는 사라졌다고 생각하며, 더 슬픈 것은 우리가 이와 같은 새로운 것, 새로운 프로그래밍 언어와 새로운 데이터베이스를 계속 만들고 있지만 여전히 이 접근 방식을 취하고 있으며 적어도 10년 이상, 확실히 지난 5년 동안 유효하지 않은 위치 지향성을 사용하고 있다는 것입니다. 근거는 사라졌습니다.

앞서 나열한 모든 이점을 놓치고 있으며, 이러한 이점 중 하나에 대해 한 시간 동안 이야기할 수 있습니다. 가치를 사용하면 엄청난 이점이 있습니다. 우리도 알고 있죠? 우리가 직접 사용하는 정보 시스템을 보세요. 우리는 이미 알고 있다는 것을 증명하고 있습니다. 우리는 로그를 덮어쓰지 않습니다. 소스 제어를 덮어쓰지 않습니다. 우리는 준비되어 있습니다... 우리가 지원하는 비즈니스를 위해 우주 시대에 맞춰 우리 스스로를 위한 우주 시대를 맞이하고 있습니다.

빅 데이터 푸시, 로그 마이닝, 그 밖의 모든 것, 모든 것을 추적하고 모든 시간을 기록하는 것에 대한 수요가 분명히 존재합니다. 기업들은 여기에 엄청난 가치가 있다는 것을 알고 있습니다. 그들은 그것을 원합니다. 수요는 아주 분명합니다. 우리에게는 이를 수행할 수 있는 리소스가 있으며, 이를 실현하는 것이 과제라고 생각합니다. 제가 추천하고 싶은 것은 프로그램을 구축하는 방식에 정보 지향적인 접근 방식을 취하는 것입니다.

감사합니다.

청중 박수] [청중 박수 But that's okay. These are things that we're learning how to manage. So to summarize, unfortunately, I think we continue to use Place-Oriented Programming and the rationale is gone, and the sadder thing is we continue to make new things that are like this, brand new programming languages and brand new databases that still take this approach, still use a place orientation that's been invalid for at least a decade but certainly for the last five years. The rationale is gone.

We're missing out on all those benefits I listed before and I could talk to you about any one of those benefits for an hour. There this huge number of benefits to using values. We recognize them, right? Look at our information systems that we use for ourselves. We're proving we already know that. We don't overwrite our logs. We don't overwrite our source control. We're ready... we're in the space age for ourselves where we need to be in the space age for the businesses we're supporting.

There's definitely demand for this, this whole big data push and mining logs and everything else and tracking everything and keeping the time of everything. Businesses know there's tremendous value here. They want it. The demand is quite obvious. We have the resources to do it and I think that the challenge is to make sure that we do. What I would recommend is that you try to take an information-oriented approach to the way you build your programs.

Thanks.

[Audience applause]