앨런 케이

발언은 출처 원문에 있는 문장 그대로예요. 한국어는 저희가 옮겼고, 원문 보기를 누르면 영어 원문이 나와요.

• 미래 발명하기

  “미래를 예측하는 가장 좋은 방법은 미래를 발명하는 것이에요.”

  원문 보기원문 접기

  The best way to predict the future is to invent it.

  저희 풀이앨런 케이가 1971년 PARC 회의에서 발언한 내용이에요.

• 소프트웨어와 하드웨어

  “소프트웨어에 정말 진심인 사람이라면 자신만의 하드웨어를 직접 만들어야 해요.”

  원문 보기원문 접기

  People who are really serious about software should make their own hardware.

  저희 풀이크리에이티브 씽크 세미나에서 진행된 강연이에요.

• 관점의 가치

  “관점을 바꾸는 것은 IQ 80점을 올리는 것과 같은 가치가 있어요.”

  원문 보기원문 접기

  A change in perspective is worth 80 IQ points.

  저희 풀이크리에이티브 씽크 세미나에서 진행된 강연이에요.

• 기술의 정의

  “기술이란 당신이 태어났을 때 세상에 없었던 모든 것을 말해요.”

  원문 보기원문 접기

  Technology is anything that wasn't around when you were born.

  저희 풀이홍콩에서 열린 기자 회견이에요.

• 약점을 보완하는 채용

  “저는 시작은 잘하지만 마무리는 서툴기 때문에, 일을 끝맺음할 사람들을 고용했어요.”

  원문 보기원문 접기

  I hired finishers because I'm a good starter and a poor finisher.

  저희 풀이개인적인 업무 스타일과 채용에 관한 대화예요.

• 소프트웨어 구조의 무결성

  “오늘날 대부분의 소프트웨어는 수백만 개의 벽돌을 쌓아 올린 이집트 피라미드와 같아요. 구조적 무결성 없이 그저 수천 명의 노동력과 무식한 힘으로 만들어진 것이죠.”

  원문 보기원문 접기

  Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves.

  저희 풀이현대 소프트웨어 공학의 상태에 대해 논의하는 중이에요.

• 단기적인 사고의 위험

  “기본적으로 지난 25년 동안 컴퓨팅 분야에서 발생한 많은 문제는 설계자가 단기적인 문제만 해결하려 하고, 그 아이디어가 채택되었을 때 확장 가능할지 고민하지 않은 시스템에서 비롯되었어요.”

  원문 보기원문 접기

  Basically, a lot of the problems that computing has had in the last 25 years comes from systems where the designers were trying to fix some short-term thing and didn't think about whether the idea would scale if it were adopted.

  저희 풀이시스템 설계의 장기적인 문제들을 성찰하는 내용이에요.

• 창의성의 본질

  “대부분의 창의성은 한 맥락에서 사물이 더 놀랍게 다가오는 다른 맥락으로 전이되는 과정이에요.”

  원문 보기원문 접기

  Most creativity is a transition from one context into another where things are more surprising.

  저희 풀이과학과 예술에서 창의적인 전환이 어떻게 일어나는지 설명해요.

• 신중한 설계

  “동전의 뒷면처럼, 훌륭한 프로그래머나 언어 설계자라도 프로그래밍의 열기에 빠져 있을 때는 끔찍한 확장을 만드는 경향이 있어요. 설계는 천천히 신중하게 할 때 가장 잘 되기 때문이죠.”

  원문 보기원문 접기

  The flip side of the coin was that even good programmers and language designers tended to do terrible extensions when they were in the heat of programming, because design is something that is best done slowly and carefully.

  저희 풀이왜 설계를 코딩의 열기에서 분리해야 하는지 논의해요.