메뉴 건너뛰기

박영식 홈페이지

[진리] 자기검열은 학습된 (사회적)지식

[원문보기]

인지능력이 향상될 수록 판단이 앞서고 판단은 이성에 의한 것이다.


이성은 오류 투성이다.


일상과 이상의 천재와 바보 차이다.


'천재와 바보 차이'는 한장. 이성적 판단자의 논리로 일반화 되어 있기 때문에 수용하면 간단하다.


일반적인 생각(학습된 판단)은 이반적인 생각과 많은 차이가 있다.


이반 -> 일반적이지 않다. 이상적이다. 이상하다.


차이다. 잘못된, 틀린, 다른과 상대적일 뿐이다.


이반은 지식으로 인한 판단이 외부적으로 평가되었을 뿐 자체적인 검열이 동작(첨부, 들어가지 않은, 오염시키지 않은)하지 않은 순수한 상태이다.


이상은 이상과 중의적인 상태이다.


이상에 사회성이 들어가면 오류가 되고, 사회성이 결여되면(오염시키지 않으면) ideal;different 이다.


이상(ideal)적인 것을 찾는 다는 것은 이상(different)적을 것을 찾는 것과 같다.


디퍼런터를 인정하지 않는 것은 아이디얼도 인정하지 않는 것이다.


잘못된 것이다. 아니, 올바르지 않은 것이다. 기존(안정적인 것)을 유지하려는 보수이다.


자기검열이 생기기 시작하면 이상(ideal)과 이상(different)을 모두 추구할 수 없다.


끝...


새로운 것을 찾지 않는 다는 것은 사망이다.


암(cancer)은 이상(different)에 가까운 것으로 평가(90% 동의)되지만 이상(ideal)일 수도 있다.


적응기제가 동작하여 새로운 상황에의 적응인 가능성도 있다는 것이다.


하지만, 기존 체계에 반항하는 것이므로 또, 너무 앞서 갔을 때의 도태도 함의하고 있어 사멸(일단 정지, 보류)하는 것이다.


이상(different)이 많은 사회일 수록 발전성이 높다.


그러나 이상(ideal)이란 프레임으로 가둬서 기득권을 유지하고 통제 함으로써 지배하는 사회에 있는 이상(different와 divergent는 당분간 숨죽이고 있는 게 좋다.




지금은 different에서 ideal로 가기 위한 과도기이며 common sense, general 밑에 숨죽이고 있어야 할 기간이 너무도 길다.




자기검열로 인해 창의력이 저하되는 환경이 너무도 안타깝다.


die = yesterday(old) = general = 일반 <> 이반(이상) = different ; ideal => future = live


보수는 죽음이고 진보는 삶이지만, 보수와 진보는 시점이 다르다.


미래에 살 사람은 진보로 가야한다.


과거에 살 것은 아니지 않은가?(연속성 결여는 내 뜻이 아니다. 전달해야할 내용이 너무 많다. t.t)


[스팸] 시간 도둑

[원문보기]

오늘 시간을 맞춰서 출근하면, 추운 날씨로 여러 어려움이 있을 것 같아(1호선 지연 등) 일찍 나왔다. 1호선으로 수원으로 향하는데, 저번에도 있었던, 종교 교리를 이야기하는 사람이 있었다. 그 때, 신문 기사로 "투명 인간"에 대한 것을 보고 있었는데, 어처구니 없음을 느끼며 흥분된 상태였나 보다. 다음 칸으로 가서 소음을 피하고 있는데, 몇 초 후 옮긴 칸으로 와서 또 중얼중얼 대었다. 나도 모르게 "아저씨 내리세요! 시끄럽지 하지 말고 내리세요"를 외치며 언성을 높였다. 그 사람은 자기가 잘못한 것을 얘기해 보라고 했다. 논리가 없음을 느끼고 다시 한 번 내리라고 얘기하고 난 자리에 앉았다.

그런 사람들은 시간 도둑이다. 스팸을 처리하기 위해 최근 기능을 개선했는데, 그도 차단해야할 조건에 들어 맞는다. 하등 도움이 안되고 새벽부터 출근하는 사람들의 안락한 시간을 뺏는 도둑질을 하기 때문에 내리라고 말할 수 있다.

스팸에 대해 탄소세를 부과하는 정책이 있다. 그런 사람들은 허가도 받지 않고 돈도 내지 않고 상행위를 하는 것이므로 요금을 부과해야 한다.

"당신은 도둑입니다."

"이 사람들이 지금 편하게 못 가서 직장에서 졸다가 짤리면 당신이 주거비와 생활비 줄겁니까?"

"아니면 시끄럽지 하지 말고 내리시죠"

"도둑님(무기 같은 건 없으시죠?)"


나이로 봤을 때, 무임승차했을 가능성도 있다. 출발지에서 도착지로 가는 요금 외의 구간을 이용하면 그것도 세금을 좀 먹는 도둑이다. 빨래 건조대로 후려 까야지!

[화장] CSS는 화장(makeup)하기?

[원문보기]

이 주제에 대해 다뤄보고 싶었다.


디자인은 화장하기(makeup)와 비슷한 것 같다.


개인적으로 화장을 안 하기 때문에 정확히는 알 수 없지만, 예뻐보일 때까지 계속하고, 남들 것을 모방하고 수정이 계속된다.


완전한 만족이란 없다. 80~90% 정도까지, 또는 시간이 허락될 때까지 계속 하는 것이다.


그리고 별로 일이 없는 날 연습도 한다.


화장하는데 많은 시간이 걸리는 것에 대해 조금이나마 이해할 수 있는 작업이다.


기능도 기능이지만 디자인도 이젠 높일 시기가 왔다.



[도서] 위풍당당, 프랑스 와인 여행자

[원문보기]

[위풍당당] 성석제

사자는 토끼 한 마리를 잡을 때도 최선을 다하는 법이다. 181쪽


[프랑스 와인 여행자]


샴페인은 프랑스 샹파뉴 지방에서 만드는 거품 있는 와인을 말한다. 그러나 많은 사람들은 거품이 있으면 모두 샴페인이라고 부른다. 제대로 구분해서 와인을 즐기고 싶다면 이점을 명심하기 바란다. 즉, 샹파뉴 지방에서 만든 거품 와인만이 샴페인이고, 샹파뉴 이외 지방에서 만들면 샴페인이 아니다. 물론 프랑스가 아닌 다른 나라에서 만든 거품 와인은 샴페인이 아니다. 이런 와인들의 총칭은 그저 스파클링 와인이다. 샴페인은 그 자체가 하나의 상품이다. 그래서 고유명사가 일반 명사화되었다. 샴페인이 되기 위한 조건이 하나 더 있다. '샹파뉴 방식'에 의거하여 거품 와인을 만들어야 한다. 샹파뉴 방식이란 곧 병 속에서 2차 발효를 하는 것이다. 거품을 병 속에 인위적으로 집어넣는 것은 샹파뉴 방식이 아니다. 결국 샴페인은 샹파뉴 방식으로 양조할 때에만 샴페인이라고 부를 수 있다. 그 외에는 샴페인 이름을 사용할 수 없다. 231쪽


생테밀리옹에서 전해 오는 이야기는 1620년 한 수녀원에서 마카롱이 탄생했다는 것이다. 단조롭고 심심한 수녀원에서 배꼽 빠지게 웃고 싶어서 그랬는지 몰라도 마카롱은 배꼽을 닮았다.~중략~

마카롱은 밀가루로 만드는 게 아니니 과자가 아니다. 계란 흰자와 아몬드 가루, 그리고 설탕으로 만든 머랭을 샌드위치처럼 포개고 그 사이에 잼이나 크림을 채우면 완성된다. 아몬드 맛이 주류를 이루는 이유는 이 때문이다. 320~321쪽


낼, 도서관 휴관이려나?

[잡담] '리얼'의 의미 퇴색

[원문보기]

10~20년 전 '원조'라는 말이 안 붙으면 2차로 가공된 또는 품질이 떨어진다는 의미가 부여되었다.

이제는 '리얼'이라는 말이 붙지 않으면, 가짜의, 짝퉁의 라는 이미지를 갖을지도 모른다.

오히려, '리얼'이란 단어를 써서 자신만, 해당 제품만 진짜고 나머지는 가짜라는 의미를 전가시키고 있다.

많은 가상화된 시스템과 환경이 나와 실제가 아닌 가상이 더 많아지고 있지만, 실제(리얼, real)는 가상(버추얼, virtural)에 상응하는 말이지, 진짜(true, pure)와 가짜(false, mixed or processed, not natural)과 대응하지는 않는다고 생각한다.

그러나 사람들은 real 이 진짜만을 의미하는 듯, 이게 붙지않으면, 모두 가짜라고 생각하게 만들고 있다.

natural 이라는 말이 나와서 그런데, '자연산'이란 단어가 역시 매우 저속하게 쓰이고 있어 안타깝다. 사실 양식과 구분하기 위해 쓰였던 말인데, 성형에 대응해 쓰이고 있어, 이런 말을 쓰는 사람들과 대화하게 되면 기분이 나빠진다.


원조, 리얼, 자연산


다음은 어떤 단어가 희생양이 될 것인가!

[handoff] 아이패드에서 전화 받기

[원문보기]

아이패드를 8로 업그레이드 하고, 갑자기 전화가 되었을 때 놀랐었다.


휴대폰 수리 후 이 기능이 되지 않아, 10분 이상 원인을 찾아봤다.


facetime 설정과 handoff 기능 활성화에도 되지 않았기 때문에 전화를 5번 정도 걸어서 테스트 했는데, 문제는 iCloud 로그인 이었다.


iCloud 쪽에 연락처 공유 기능이 있어서 해당 설정을 로그인으로 활성화 시켜야 전화가 되는 것이다.


이제 다시 아이패드에서도 전화를 걸거나 받을 수 있도록 설정이 되었다.


급 피곤하군...

현실에 충실하자

[원문보기]

 누군가로 부터 배려가 과도하다는 말을 들었다. 개인적으로 그런 배려 섞인 말을 하고, 행동을 하는데, 처음에는 좋은 인상으로 다가갈 수 있지만, 나중에는 과도함으로 남게될 수 있다고 느낀다.


 얼마 전에도 그런 말과 행동을 했음을 인정하고, 어떻게 바꿀 것인가에 대해 생각해봤다. 과도한 배려심이 오히려 자신을 너무 낮추는 결과를 초래해 인정받지 못 하는 상황이 이어진다면 나만 손해인 것이다. 현실에 충실하며 주장해야할 상황이라면 배려보다는 리딩이 오히려 좋은 결과로 이어질 수 있다고 생각한다.


 최근 새롭게 알게된 이가 자학하며 자신을 너무 낮추는 모습을 보았을 때, 자신감이 없어 보여 좋지 않은 인상으로 이어짐에 나 자신을 깨달을 수 있었다. 과하지 않게, 현실에 맞게 그 모습을 제대로 드러내도록 노력해야겠다.


 항상 살아오면서 이중적인 생활을 하고 있어, 도움이 되기도 하지만 역효과로 이어지는 경우가 많음을 느끼게 된다. 있는 그대로를 보여주지 못하고 가식적이 되어가는 자신을 합리화하고 있어, 항상 그렇게 생각한다. 남들이 날 가식적으로 생각할까? 그렇지도 모른다. 이 글에 여실이 드러나는구나.

[진리] 보이는 영역과 보이지 않는 영역

[원문보기]

세상은 너무 복잡화 되었다.


그래서 보이는 영역과 보이지 않는 영역은 명확해 보이는 보이면서도 알 수 없다.


시각화를 통해 보이도록 했지만, 보이도록만 했는지 가공을 통해 보여주고 싶은 부분만 시각화 했는지는 알 수 없다.


더럽거나 혐오스러운 부분을 가리기 위해 커튼이나 가림막, 덮개를 사용한 것 뿐이다.


덮개를 여는 것이 쉽다면 열어서 실체를 보면 된다.


그러나 덮개를 열 수 있는 방법을 제공하지 않거나 보여주고 싶은 부분만 보이도록 덮개를 열도록 한다면 그 문제는 심각해 진다.


두려운 부분을 가리고 싶은 욕구를 내재하고 있기 때문에 덮개를 열었을 때 친화적인 부분만 노출된다면 문제를 제기하지 않는다.


그러나 덮개를 열었을 때, 예상치 못한 내용을 보게 된다면 두려움에 쌓이게 된다.


덮개가 쌓여진 보이지 않는 영역에, 덮개를 열었을 때 보이는 영역이 노출된다면 그대로 받아들일 것인가?


현재는 무조건 yes로 되어있다. 덮개에 대한 검증도 할 수 없는 복잡한 시대에 접어들었기 때문이다.


덮개에 대한 검증. 또 하나의 "고양이 목에 방울 달기"가 되었다.


덮개에 대한 고민이 필요하다.

[CS] Cloud Service 사용

[원문보기]

AWS는 아마존 웹 서비스로 현재 1년 무료로 이용할 수 있다.

HOSTING 서비스처럼 가상 머신으로 활용할 수 있는 EC2는 익숙한 방식이다.


Azure는 MS 에서 제공하는데, 1개월 무료이고 기업은 3년동안 무료로 쓸 수 있는 경로를 제공하고 있다고 하니 조만간 시도해 볼 예정이다.


로컬 PC에 VMware로 이용하는 것보다 유지 부담을 줄일 수 있어, 테스트 환경 활용에 유용할 것으로 기대된다.


다면, aws는 한글화가 좀 더 필요하고, windows azure는 무료 지원이 좀 더 강화되며 좋을 것 같다.


aws 는 터미널 접속에 key 파일을 이용해야하는 약간의 설정이 필요하지만, windows는 rdp로 바로 접근 가능하다.


무료인데, 어떤 불편을 감수하지 못할까. ㅎ



[글쓰기] 나는 테스터다. 단위 테스트는 지양한다.

[원문보기]

개발자 입장에서 실제 사용자는 어떤 식으로 입력할지, 기능을 사용할지 알 수 없다.


물론 초기에 "A는 B에 입력하고, C를 D와 같이 사용하세요." 라고 하더라도, " A?, B?, C?, D? == 가, 나, 다, 라 "로 흘려 들을 수 있다. 사실 제품 제작자가 아닌 내 자신이 사용자가 된다면, 설명서에 집중하여 최대한 시행착오를 줄이려 노력한다 해도 결국 한 두가지를 간과하여 실패에 이른다.


자주 짧은 코드를 작성하고, 간단한 단위의 배포 소스를 수정해 적용하는 업무를 하고 있다. 아무리 코드의 양이 적더라도 단위 테스트 등을 통해 품질을 관리할 필요가 있다. 이는 확장성에 닿아 있기 때문이다. 그러나 나는 게으르기 때문에 테스트를 위한 코딩은 하지 않는다. 단지 디버깅 로그를 사용할 뿐이다. 또한 핑계를 하나 더 붙여서 사용자의 입력과 행동이 단위 테스트 범위를 넘어서는 경우가 많아 차라리 사용자 테스트를 통해 버그를 수정하고, 축적된 데이터를 분석하는 것을 선호한다.


그동안은 나의 게으름을 완전히 숨겨왔지만, 이를 정당화(?)해 줄만한 글을 읽었기에 옮겨 놓는다.


테스트는 해야 한다. 테스트, 테스트, 테스트. 하지만 나는 단 한번도 (a) 설정하는 데 걸리는시간이 100 시간/사람 이상 걸리지 않거나 (b) 수많은 공학적 자원을 빨아들이지 않거나 (c) 실제로 상관이 있는 버그를 발견하는 구조적인 테스트 프로그램을 본 적이 없다. 단위 테스트라는 것은 수많은 엔지니어에게 지루함을 견디고 아무것도 찾아내지 않는 것의 대가로 급여를 지급하는 수단에 불과하다 - 윌 쉬플리-


개인적으로 나는 테스트 주도 개발이라 생각했다. 작은 코딩을 하고 테스트하여 원하는 결과를 얻고, 같은 방식으로 새로운 함수를 만들거나 확장하는 식으로 코딩을 하기 때문이다. 그러나 적확하지는 않음을 깨달았다. 이런 개발방식은 차라리 주먹구구식에 가까울지도 모른다. 그래도 설계가 어느 정도 포함되어 있고, 규모 자체가 워낙 작기에 효율적이다.


보안 점검에서 좀 더 과격한 테스터의 관점을 더한다면 아래의 조언을 받아들일 수 있다.


과감하게 말하겠다. 당신의 망할 프로그램을 반드시 테스트해야 한다. 실행하라. 사용하라. 이상한 일들을 해보라. 키보드를 망가뜨려라. 지나치게 많은 항목을 더해보라. 2MB 짜리 텍스트 파일을 넣어보라. 그것이 어떻게 오동작하는지 발견하라. 이렇게 하는 것이 매우 중요하기 때문에 나는 지금 고함을 지르고 있다. - 윌 쉬플리 -


한국은 너무과도한 테스트를 했는지도 모른다. 정말 2MB 를 넣었더니 디버깅이 불가능한 수준으로 갔다. IT 테스트베드로 좋다는 것은 인정하지만, 실험정신이 너무 강했는지도 모른다.


내가 제작한 프로그램은 사용자가 IT 관련이 아니다. 물론 이것은 중요하지 않을 수도 있다. 정말 생각지도 못한 사용이 일어나기도 하여, 끔찍한 결과가 나온 적도 있다.(그렇게 끔직하진 않다.) 아무튼 난 단위 테스트라기 보다는 사용전 테스트와 사용자 테스트를 통해 코딩을 한다. 이건 단순 테스트 주도 개발이 아닌 "주먹구구식 사용자 테스트 주도 개발" 정도로 불러본다.

이전 1 ... 40 41 42 43 44 45 46 47 48 49... 57다음
첨부 (0)
위로