벽에 곤충이 앉아 있다.

바람을 불어 본다.


어떤 것들은 바람을 견디며 찰싹 달라 붙고,

어떤 것들은 재빨리 도망을 간다.


사람에 대한 경계를 하는 녀석들이 주로 도망을 갈 것이라 생각된다.


혐오하는 곤충을 꼼짝못하게하고 없애려 고안했지만,

대개 혐오하는 녀석들은 도망을 가는 것에 익숙하다.


"-할게/-할께"의 맞춤법 문제에서 "-할게"만 표준어이다. 이 규정은1988년 1월 맞춤법 고시되었고 고시대로라면 89년 3월부터 적용한다라고 되어있다.

1988년 1월 19일: 한글 맞춤법 고시(문교부 고시 제88-1호)
국어연구소가 1987년 9월 문교부에 보고한 '한글 맞춤법'이 1988년 1월 19일 문교부 고시 제88-1호로 확정 고시되었다. 부칙에 이 한글 맞춤법을 1989년 3월 1일부터 시행한다고 명기하였다. 이로써 1933년에 조선어학회가 제정한 '한글 마춤법 통일안'은 55년만에 새 모습으로 나타나게 되었다. 조선어학회가 제정한 '한글 마춤법 통일안'이 1988년 '한글 맞춤법'으로 바뀐 것은 단순히 명칭에서 '통일안'이 없어진 차이만 있는 것은 아니다. 민간 학회가 만든 안이 정부에 의해 받아들여졌다는 '격상'의 의미도 있다. 그러나 내용면에 있어 '한글 마춤법 통일안'과 대폭 달라진 것은 아니다. 형태음소적 표기의 대원칙은 조금도 흔들리지 않았다. 다음은 '한글 맞춤법'(1988)이 '한글 맞춤법 통일안'(1933)과 달라진 내용이다.
새 맞춤법에서는 단어를 사전에 올릴 적의 자모 순서를 정하여 놓음으로써 종래에 사전 간의 표제어의 순서가 달랐던 점을 바로잡을 수 있게 되었다. 접두사처럼 쓰이는 글자가 붙어서 된 말이나 합성어에서도 두음법칙의 지배를 받도록 규정하였다. 접미사처럼 쓰이는 한자는 본음대로 적기로 하였다. 모음이나 'ᄂ' 받침 뒤에 이어지는 한자음 '렬, 률'은 어두가 아니더라도 '열과 율'로 적기로 하였다. 비성절음인 자음은 독립적인 표기를 않기로 하여 '가ᄒ다'가 아니라 '가타'로 하였다. 의문을 나타내는 어미 이외의 어미에는 된소리를 쓰지 않기로 하여 '-ᄅ께'로 적던 것을 '-ᄅ게'로바꾸었다. 성과 이름은 붙여 쓰기로 하였다.

아, 억울해. 고등학교 3년동안의 시간동안 저 습관이 잘 안들어, 요즘도 ~할께로 자주 쓰려고 한다. (뭐 그렇다고 다른 표준어 규정을 잘지키느냐면 그것도 아니지만. ㅎㅎ)

P.S. 지금 귀에선, 롤러코스터의 "습관"이라는 노래가 들린다. "습관이란게 무서운 거더군~"

참고로, 최근 맞춤법 규정은 "한국 어문 규정집" 이라는 검색어로 검색할 수 있으며, 돌아다니는 파일명은 "한국어문규정집(2012).hwp" 이다.


  1. sss 2014.09.23 11:22

    요즘 왜케 맞춤법에 집착하세요? ^^ 나쁘다는건 아니지만 괜히 궁금해서요 ^^

    • Coolen 2014.10.04 16:29 신고

      글을 잘쓰기 위함이지요. 요즘 더 그러나요? 제가?
      근데 누구시옵니까? ^^

구글의 Gmail이 사용자의 메일을 지우지 않고도 쓸 수 있도록 용량을 계속 늘려주는 것은, 시중의 동일 가격 하드디스크의 용량 증가율이 그 보다는 큰 것을 담보로 하는 것일게다.


그런 의미에서 기록을 남기자면, 15GB 중 3.53GB(23%) 사용이라한다.

  1. 지양 2014.09.02 14:20

    저는 모든 개인정보를 구글신께 바치고 85% 사용 중입니다. ㅎㅎㅎ

평론가 D는 일종의 문화 잡식가다. 그 잡식성이 소화불량을 일으키지 않고, 몇몇 소화도구를 만들어 다른이들이 쉽게 하지 못한 방법으로 인문학 장르를 넘나들며 자기만의 평론세계를 만들어 낸다. 그리고 그 내면을 잘 정리하여 다른 이들에게 전달마저 참 쉽게, 자칫 현학적인 방식으로 하지만 크게 벗어나지 않는 선에서 참 훌륭하게 해 낸다.


내가 파악한 그의 소화도구란 문장의 반복, 소재들이 가지는 속성들의 대칭, 그리고 그만의 특징인 영화와 소설에서 보이는 인물간의 유사성을 비교 등인데, 그가 하는 많은 인터뷰와 진행하는 리뷰의 프레임에서 발견할 수 있다.


하지만 기본적으로 그의 성실함이 모든 것을 임기응변으로 가능하지 않음을 말해준다. 성실함에 바탕을 두고 인터뷰이나 리뷰 대상을 꼼꼼히 살핀다. 물론 위의 도구들이 자동으로 작동하리라 상상이 된다. 머리위로 가위손같은 도구들이 책을 읽을 때 찰칵거리는 상상이 된다.


그가 가지고 있는 소화도구에 대한 전반적인 느낌은 그의 기술은 언어 구조적인 문제로부터 출발하는 것에 있다. 그는 기본적으로 가벼운 대화에서는 썰렁한 유머를 구사한다. 이것은 발화의 형식으로 하는 유희 혹은 내용에서 1차적인 유추 혹은 필받았을 땐 1차 유추의 메타적인 종합으로 하는 유희를 즐기는 것으로 그의 직업과 일상에서 비슷한 기술이 작용하고 있다 말할 수 있겠다.


끝.


요정들의 음식인 렘바스(Lembas). 이거 하나 먹고 하루 종일 걸을 수 있다나? 하루 식사분량의 힘을 낼 수는 없을 지라도, 고칼로리의 초콜렛 과자들은 렘바스 아류가 아닌가 싶다.

Tracefs: A File System to Trace Them All

Akshat Aranya, Charles P. Wright, and Erez Zadok
Stony Brook University

https://www.usenix.org/legacy/publications/library/proceedings/fast04/tech/full_papers/aranya/aranya_html/index.html


참고삼아...

어렴풋하지만, 고등학교 때인지 대학때인지 즈음에, 그것이 C언어를 배울 무렵인지 한참 배우고 나서인지 알 수 없지만, 다음과 같은 문장이 걱정스러웠던 적이 있다.


void functin()

{

int i;

for( i=0; i<100; i += 1 ) {

if( i > 50 ) {

return;

}

}

}


매우 간단한 문법이다. 100회를 돌지만, 50이 넘는 순간 함수 자체를 탈출하라는 것이지 않은가. 문제는 for 문을 break가 아닌 return으로 탈출하는 것에 대한 사용법인데, 이 구문에 대한 이해는 for 문장은 단순히 if, goto 의 조합으로 다시 쓸 수 있는 것 이상도 이하도 아닌 것에 대한 언어구현상의 확신을 필요로 한다.


void functin()

{

int i;


i = 0;

loop:

if( i< 100 ) {

goto loop_end;

}

if( i > 50 ) {

return;

}

i += 1;

goto loop;

loop_end:


}


이 정도 되겠다. 이런 동치인 문법으로 표현이 가능하다는 구현상의 확신(?)이 체화되기까지 시간이 지나야만 단순한 저 문법조차 쉽게 쓸 수 있다는 것인데, 저게 두려웠던 이유는 for 라는 녀석이 내부적으로 뭔가를 임시로 만들어 놨는데, return이라는 무지막지한 녀석을 동원하여 임시데이터를 없애지 못하고 순간 탈출하는게 아닌가 하는 것에 있었다.


그런데, 요즘의 다른 언어 문법에서 보이는 iterator 를 넘기는 구문으로서의 for 같은 경우는 사실 저런식으로 언어 구현에 대한 확신이 숨겨져 있는 경우가 있다. 문법은 쉬워보이지만, 그 구현에 대한 확신이 없을 때 생기는 두려움.


예를 들어 다음과 같은 javascript가 있을 때,


function ()

{

for( var it in someObject ) {

if( someObject[it] %3 == 0 ) {

delete someObject[it];

}

}

}


저 delete가 someObject 의 Key operation에 어떤 영향을 줄까에 대한 구현상의 이해가 가독성을 떨어뜨리지 않나 싶다. 물론 이것은 for 의 구현에 대한 두려움이라기보다는 object의 iterator에 대한 두려움이긴하다. 저 비슷한 것을 C++의 STL 사용예로 확인한다면,


void function( std::map<std::string, int> & m )

{

for( std::iterator it = m.begin(); it != m.end(); it.next() ) {

if( it->second % 3 == 0 ) {

m.remove(it);

}

}

}


(컴파일 않고 요새 잘 안쓰던 C++ 문법을 쓰려니 저게 안돌아가면 어쩌나 하는 마음도 있지만, 아뭏든)

오픈소스인 STL 구현을 따라가면 사실 어떤 문제가 있을지 확인할 수 있는 부분이다. 하지만, 언뜻보아도, 지운데이터의 다음 it.next()를 참조하는 것은 오류가 발생할 것 같다. 그래서 next를 구한다음 remove하는 방식으로 바꿔야한다. 이게 기존의 for에 대한 이해가 있고, 거기에 iterator를 따라가는 형태로 구현했으니 망정이지, javascript 처럼 next()에 대한 처리를 수작업으로 하지 않는 경우엔 구현에 대한 궁금증이 증폭되게 마련이다.


이런 두려움 혹은 호기심은 내 코딩 속도를 저하시키는 요인 중의 요인이다. ㅎ.


우리가 살고 있는 생태계는 태어나고 성장하고 먹고, 먹히고, 돕고, 도움을 받고, 이용하고, 이용당하고, 변이를 일으키고, 살아 남고, 죽는 무수한 관계의 집합체이다. 이런 균형이 이루어지는 자연의 상태를 설계자의 관점을 두고 분석하는 방법을 세가지로 나누자면, 누군가 조정하고 있다고 생각하는 것과 적절한 규칙만 두고 그 안에서 치고받고는 상관하지 않는다고 생각하는 것과 적절한 규칙조차 치고받고의 결과라고 생각하는 것으로 볼 수 있다.


인터넷 세상에서 많은 플랫폼이 설계되고 만들어진다. 그것의 예는 메일이 될 수도 있고, 메신저가 될 수도 있고, 검색 사이트나 게임 사용자들, 그리고 광고 네트워크도 될 수도 있다. 조금 더 작게는 게시판 몇개가 모이는 카페나 유머사이트가 될 수도 있다. 중요한것은 자연계의 무수한 관계의 집합체처럼 무수한 사용자들이 상호 작용을 하고 있는 것이다.


만든 플랫폼을 균형을 이루어 발전시키고자 할 때, 가장 오래된 자연계에서 모방하고 싶은 생각이 드는 생각은 그야말로 자연스러운 것이다. 이때 플랫폼 설계자는 생각을 하게 된다. 빅데이터를 분석해서 완전 조정가능하다 아니다 몇가지 규칙만 세우고 문제가 되는 부분이 발견되면 보수하자, 그리고 이도저도 아니고 최대한의 자유를 두고 자연정화를 기다리자.


정말 가능한 것일까? 생태계를 분석하고 균형을 이루는 이론을 도출하여 내가 만든 다른 생태계에 적용하는 것이 가능한 것일까? 프랑켄쉬타인의 몸 일부를 담당시켜가며 어기적거리며 걷게되는 것을 최대한 자연스럽게 만드는 것이 우리가 하는 것일까?

하양, 까망


갑자기 머리가 하얘졌어.

완전 까맣게 잊고 있었네.

어느 회사든지 사내 업무 전산화가 되어 있고, 업무 전산화를 위한 기술팀이 존재한다. 그 팀이 사내에 있든, 외주 팀이든, 외부 솔루션을 사온 상태든 어떤 식으로든 고유 업무에 대한 전산화된 시스템이 있으며, 이 시스템이 일반화된 소프트웨어를 이용하지 않고 주문제작되어 있는 조직을 가정한다.


전산화된 시스템을 이용하여 일처리하는 직원들이 과연 시스템 개선을 위해 노력할지 의문이 드는데, 내 과거 사례에서도 그랬지만,직원들이 시스템 개선을 이루지 못하고 적응하는 방법을 찾아 버린 순간 (즉, 개선에 대한 우선순위가 낮아져도 되는 이유가 발견된 순간), 공은 최종 소비자의 불편신고센터를 통한 접수만 남게 된다. 전산화된 시스템이 수준이 낮아서 직원들이 낮은 수준의 기술을 불편함을 감수하고 사용하는 조직. 이렇게 되지는 말아야한다.


그럴려면, 개발팀이 조직내에 있어야한다. 개발팀 수장은 조직이 효율적으로 바뀌고 있는 것을 몸소 확인해야한다. 술이나 먹지말고 공부좀하면서 돌아다녀야지.

+ Recent posts