과거형말하기

FrontPage|FindPage|TitleIndex|RecentChanges| UserPreferences P RSS

FrontPage내가가는까페 과거형말하기

스푼벤딩을 할때, 이것이 구부러질 것이다라고 생각하면 안된다고 한다. 이것이 구부러졌다라고 생각해야 구부러진다고 한다. 여기 대단히 재미있는 사실이 있다. 원하는 것을 이루려면 과거형으로 말하라. But why?

이에 대한 가능한 가설 한가지를 세워볼 수 있다.

자연에는 어딘가 모르지만 일어났던 사건들을 기록하는 장치가 있다고 가정한다. 아라야식이나 아카샤 기록이 바로 그런 장치에 대한 가정이다. 내 머리 속에는 과거에 대한 기억이 있고, 자연의 장치에는 과거에 대한 기록이 있다.

만약 둘이 일치하지 않는다면?

미래에 대한 것은 일치하지 않을 수 있을 것이다. 아니, 일치할 필요가 없을 것이다. 은행에 돈을 넣어 놨는데, 통장에 찍힌 것과 실제 은행 컴퓨터에 기록되어 있는 잔고랑 다르다면 이건 보통 일이 아니다. 하지만 10년 후에 이 사람이 받을 이자에 대해서는 어떤 일이 중간에 일어날지 모르므로 다르다고 해서 큰일나는 것은 아니다. 따라서 과거에 대한 기록이 일치하지 않는다면, 이것은 자연이 해결해야 할 가장 시급한 문제가 될 수 있을 것이다.

과연 어떤 것을 기준으로 일치시킬 것인가? 보다 선명한 기록을 가지고 동조화시킨다고 해 보자. 그렇다면, 가능한 해답의 윤곽이 보다 선명해진다. 과거형으로 말해야 한다. 자연이 해결해줄 우선 순위, 급속 상승한다. 선명하게 기억해야 한다. 아주 세세한 부분까지. 어떤 사건에 대한 장소, 시간, 그때의 느낌, 가능한 구체적으로 세세하게, 그럴듯하게 구성해서 기억해야 한다. 그래야 내 기록이 진짜라고 자연이 평가할 가능성이 높아진다.

또 한가지. 자연의 목적은 특정인에게 잘 해주는 것이 아닐 것이다. 전체의 질서와 조화도가 증가하면 자연의 목적은 완수된 것이다. 그것이 서로 다른 기록에 대해 자연이 가만히 있지 않고 개입할 수 밖에 없는 이유일 것이다. 그렇다면 이러한 방법으로 얻은 결과가 자연의 질서와 조화도를 증가시키기만 하면... 이건 Win-Win 이다.

따라서, 결정적인 기법 한가지가 이렇게 얻은 결과의 일부분을 다시 환원하는 것이다. 그리고 감사하는 것이다. 이것은 프로그램의 일부다. 이걸 안 하는 것은 남의 서버 침입해서 자신의 IP 주소 남기고 오는 것과 같은 어리석은 짓이다. 설마 자연이 어떤 사건에 대해서 발생전과 발생후의 조화도와 질서의 정도를 추적, 평가하는 기능이 없을 것이라고는 생각하지는 않는 것이 좋을 것 같다. 그리스, 로마 신화에 보면 이 마지막 과정을 놓침으로써 얻었던 모든 걸 잃는 얘기가 자주 나온다.

이것은 모든 white magic 의 기본 원리이다. 이것은 일종의 해킹이다. 하지만 크래킹은 아니다. Black magic (흑마술) 은 크래킹이다. 남의 계정 들어가서 아이템 뺏는 행위이다. 남을 희생시키고 자신의 이득을 구하는 행위이다. 자연의 질서와, 조화도에 대해서는 개떡으로 생각한다.

과거형말하기는 굳이 문법적으로 따지면 "현재완료형말하기"이다. 하지만 내용을 이해한 사람에게 그것이 중요하랴?

white magic이 자연의 개입을 바라는 것이라면 black magic은 자연과는 대비되는 어떤 존재의 개입을 바라는 것인가. 그렇다면 black magic이 자연의 질서에는 관심없는게 당연하다. black magic은 다른 존재의 법칙에 충실해야만 발동할테니...

It's not you want, desire and make something to be done... It was destined to be done by that time... and you're just realizing and wonder after it is done..

과거형말하기는 컴퓨터 소프트웨어 개발의 요구사항과도 관련이 있다.

요구사항이란 앞으로 개발될 소프트웨어가 이러이러했으면 좋겠다는 고객의 "요구" 집합을 말한다. 보통 개발 초기에 개발자와 고객 간의 미팅을 통해 이런 요구사항을 명확히 한다. 대부분의 경우 고객은 이 요구사항이 얼마나 지켜졌느냐로 그 소프트웨어의 완성도를 판단한다.

그런데 이 요구사항이 어떻게 제시되느냐가 산출물로서의 프로그램에 큰 영향을 끼친다. 요구사항이 어떤 순서로 제시되느냐, 심지어는 어떤 시제로 제시되느냐가 결과로서의 프로그램에 큰 영향을 끼친다.

최근의 심리학 연구에서 흥미로운 결과를 발견했다. "내일은 한국과 브라질의 경기날입니다. 결과가 어떻게 될까요?"라는 질문과, "어제는 한국과 브라질의 경기가 있었습니다. 결과가 어땠나요?"라는 질문에 대해 사람들의 대답은 큰 차이가 있었다. 또 "XX 교수는 여름 휴가 때에 유럽 여행을 간다, 그 여정이 어떨까?"와 "XX 교수는 여름 휴가로 유럽 여행을 다녀왔다. 그 여정이 어땠을까?"도 비슷했다. 각각에 있어 후자 경우(과거시제)가 훨씬 더 풍부하고, 자세하며, 구체적인 정보를 끌어냈다. 이 사실은 요구사항에도 적용이 되어서, 요구사항의 내용을 "미래 완료형"이나 "과거형"으로 표현하는 방법(Wiki:FuturePerfectThinking)도 있다. "This system will provide a friendly user interface"보다, "This system will have provided a friendly user interface"가 낫다는 이야기다.

어찌되었건, 우리는 요구사항이 표현된 "글" 자체에 종속되고, 많은 영향을 받는다.

see also ConwaysLaw



"; if (isset($options[timer])) print $menu.$banner."
".$options[timer]->Write()."
"; else print $menu.$banner."
".$timer; ?> # # ?>