메뉴 건너뛰기

박영식 홈페이지

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

lispro062017.11.05 05:28조회 수 292댓글 2

    • 글자 크기

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


이성은 오류 투성이다.


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


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


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


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


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


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


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


이상에 사회성이 들어가면 오류가 되고, 사회성이 결여되면(오염시키지 않으면) 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)


lispro06 (비회원)
    • 글자 크기

댓글 달기

댓글 2
  • 지혜는 지식이 선행되어야 한다. 이상은 지식이 파괴하여 답보가 되거나 운이 좋아 혁신이 된다. 판단과 창의력은 지식이라는 베이스에서 같이 태어나지만 판단은 이성, 창의력은 감성에 의해 발현된다. 지식이 많을 수록 판단의 비중이 높고, 반대일 수록 창의력이 샘솟을 수 있다. 기존 판단에 순응할 수록 자기검열로 표현될 수 있고, 자기검열이 없을 수록 창의적인(그러나 제한적인[이미 검증된) 멋진 생각) 내용이 나온다 (신제품;신개념이 물론 안타깝게 문서로 검증되어 있다.) 모를 수록 용감하다. 용감해지는 것이 필요하다. 바보가 되어야 한다. 돈이 많은 바보가 되어야 한다. 돈이 많으면 천재든 바보든 지식에서 지혜로 이상(different 이면서 ideal한 것)들을 많이 만들 수 있다. 이상하자!

    [편집 전 : 마무리가 않좋다. 결국 자본주의라니....]

  • 이상(different, ideal, divergent)을 틀린(error, bad, 빨갱이, abnormal) 것으로 오도하는 적폐 세력은 빨리 정리되어야 한다.

[꿀팁] 무료 도메인 제공 사이트

[원문보기]

freenom 이란 사이트인데, 좀 헤매긴 했지만, 연결하는데 성공했다.


DNS 설정이 쉽지않고, 별도 포트로 운영하는 사이트라 걍 URL 연결로 처리했다.


1년까지 무료임.


[OS] windows 10 업데이트

[원문보기]

노트북의 최대 절전 모드 돌입(?) 문제로 도저히 작업을 할 수 없어, 이리 저리 알아보던 중,


CPU 사용률을 줄이는 방법을 찾았다.


일단, 70%로 해보고, WINDOWS 10을 설치하려다가 또 절전 모드로 들어가 실패했다.


출근하면서 선풍기로 냉각시키고 다시 시도하여 퇴근하니 설치 완료.


60%로 내리고 운영해 볼 예정이다.


효과가 있다면, 해당 방법을 추가해야겠다.


노트북이 아닌 이제 내가 절전 모드로 들어가야겠다.


zzzz......

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

[원문보기]

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


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


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


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


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


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


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


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


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


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


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


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

[세금] 주민세 납부

[원문보기]

음.. wetax 에서 낸다기에 그랬는데, etax 에서 할 걸 그랬다.


wetax에 가입하느라 !@#$%^%$#%^@!#$@%$%@#



다시 겨울이 오는 것 같다

[원문보기]

입에서 입김이 나온다. 보이지 않는 입김. 밤은 춥다. 냉기가 돌아 보일러의 온도를 높여 난방으로 전환했다. 그리고 다시 외출. 나는 외출 중.


3등 항해사

컨설팅은 조타수까지는 할 수 있지만, 선장이 되지는 못한다. 그러나 일부에서는 선장의 일을 시키기에 사고로 이어진다. 천한함사건 세월호 사건은 직무유기와 안전불감증의 안일함에서 일어났다. "같은 배를 탔다"라는 말이 계속 회자되고, "xx호"라고 이야기하는 것은 혼자 탈출할 수 없기 때문이다. 죽으면 같이 죽고 살면 같이 사는 것이다. 선장은 배를 버리지 않는다. 다만 탈출할 뿐? 배가 원하지 않는 방향으로 간다면 협의나 건의를 통해 방향을 바꿔야한다. 그러지 못할 것 같으면 빨리 떠나야지. 선장도 아닌데 키를 맞긴다면 거절해야 한다. 키를 어쩔 수 없이 잡아야 한다면, 선장이 해야할 일들을 모두 챙기고 난 다음 책임을 질 수 밖에. 키를 잡는 다는 건 책임을 져야한다는 것이다. 그것이 충분한 경험을 거친 뒤 오거나 그릇이 충분한 사람한테 넘겨지면 사고는 미미하다. 그러나 충분한 경험과 준비, 그릇이 되지 않는다면 침몰할 수 밖에. 아직 나에게 키가 오지 않은게 다행이다. 난 준비도 안 됬고, 그릇도 되지 않는다. 게다가 목숨을 바쳐 승객을 구할 승무원도 되지 않는다. 직장의 신에 나오는 고정도 일뿐.

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

[원문보기]

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


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


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


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


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


급 피곤하군...

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

[원문보기]

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


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


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


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


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


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


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



강원도, 부산, 그리고 서울

[원문보기]

지자체 프로젝트를 진행하면서, 전국을 순회하고 있다.


대전, 충청도는 방문지에 포함되어 있지 않으나, 남부지방으로 내려갈 때 지나가게 된다.


오늘은 운이 좋게 무정차 열차를 타고 서울로 올 수 있었다.


다음주는 대구로 가게 될 텐데 KTX가 불편하다.


단 시간에 긴 거리를 오가다 보니 아무래도 피로감을 많이 느끼게 된다.


그래도 진도까지 내려가는 사람들을 생각하며 참자.

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

[원문보기]

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


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


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


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


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


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


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


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


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


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

선발과 구원

[원문보기]

요즘은 선발로 나가고 있다.

그런데, 선발에서 물러날 때, 강판도 아니고, 다음 선발을 위해 교체가 되어 문제다. 출루한 주자들을 마무리해 준 것도 아니고, 1, 3루나 2루에 주자가 있는 상태에서 나간다는 게 문제다. 구원이 아무리 잘 던져도 한 점 이상은 내줄 수 밖에 없는 것이다. 뭐 사실 컨설팅이 이전 업체에 의해 이미 점수가 많이 나진체 나가는 경우가 많긴 하다. 그래서 이전 업체가 있다면 구원을 피할 수 없는 것이다. 그래서 이런 것을 감안하고, 이전 현황을 파악해 어느 정도 주자들이 출루했는지 확인해야 한다. 그래야 갑작스런 업무량이나 담당자와 어느 정도까지 협의 해야하는지 정할 수 있다. 이번 프로젝트는 거의 선발이라 부담이 없지만, 구원을 경험해서 마무리를 잘 할 수 있는 연습이 덜 된 만큼 연습이 필요하다.


나는 선발이다.

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