Egloos | Log-in


의권의 '사여'


"참공에 의해 '몸이 쇠처럼, 몸에 납을 부은 것 처럼, 근육이 한 덩어리가 된 것처럼, 모발이 창 
이 된 것처럼(體整如鑄, 身如鉛灌, 肌肉如一, 毛髮如戟)'된 경지, 즉 사여(四如)의 경지에 도달해야 비 
로소 권법에 대해 이야기할 수 있다."

=========================================================
우선은 옮겨 놓고, 나중에 시간날때 글을 좀 달아야 되겠다.

10년간 운동을 안하다가,, 1년여 부터 다시 운동을 시작하면서 많은 깨달음(?)을 얻었다.
내가 배운게 부족했고, 나의 이해가 잘못된 면이 많았었다는 걸..
냉정하게 얘기하자면, 그때 가르쳐주셨던 분들이나 관련 글들을 썼던 분들도 이해가 좀 부족했던 면이 있다.
물론, 당시의 내 이해력과 훈련이 부족한게 제일 컸고.. ㅠㅠ

by 코퍼스 | 2017/06/15 11:17 | 몸공부/마음공부 | 트랙백 | 덧글(0)

왕향제 소년시절 일화

아래의 사이트에서 퍼왔습니다.
일화 자체 보다는, 아래에 나와 있는 '오행'에 대한 설명이 마음에 들어서요
그런데, '조금만 움직이면 담뱃대로 후려쳤다'라는 얘기는, 의례 이런류의 정적 수련을 하는 일화에 따라붙는 과장법이죠.


http://soohyun.compuz.com/zboard/view.php?id=taijiboard1&page=3&sn1=&divpage=2&sn=off&ss=on&sc=on&select_arrange=hit&desc=desc&no=5181



곽운심은 말년에 자기 아들과 왕향제를 가까이하고 지냈다. 또한 가끔씩 와서 배우는 꽤 유명한 제자들도 있었다. 곽공의 아들 곽호 이분은 권법에 그렇게 열심이지 않았다. 어느날 왕향제가 오행권중 벽권을 연습하는데 전진력(삼체식에서 전진식)이 너무 강하여 천으로 만든 신발이 쫙 찢어졌다. 이에 나름대로 미립을 터득했다고 생각한 왕향제 소년이 곽호한테 "사형 내가 붕권을 연습하는데 기운을 얻어서 신발도 찢어졌어" 곽호가 "그럼 그걸로 나를 쳐봐라"

왕향제 소년이 돌진하여 붕권으로 곽호의 가슴을 쳤는데 곽호가 손을들어 왕향제의 손목을 탁 한대 치자 도리어 왕향제 소년이 어떻게 당한지도 모른채 바닥에 주저앉았다. 서 너번 덤벼서 똑같은 일을 당하자 "사형이 쓴 권법은 무슨 권법입니까?" 곽호는 웃으면서 "형의권 이야." 

여기서 이상하다고 느낀 왕향제는 사부님이 자기들한테는 형의권의 진수를 가르켜주지 않는다고 생각하게됐다. 왕향제는 제자들중에 나이도 제일 어리고 형의권을 연습하여 진도가 빨랐고 총명, 영리하여 곽공의 사랑을 받았다 한다. 곽공은 자신이 수련할때에는 동네 인적이 없는 묘지에서 깊은 밤중에 홀로 연습했고 제자들을 비롯하여 아무도 가까이 오지 못하게 하였고 동네 사람들도 곽공이 성격이 괴퍅하고 사람을 죽인적이 있다는 사실을 알기에 아무도 가까이 가려 하지 않았다. 

어느날 어린 왕향제가 사부님 생각이 나서 걸치는 옷 한벌을 들고 묘지로 갔다. 그런데 곽운심은 자기들이 배우던 형의권과는 다른 동작으로 서있지 않는가. 한참 지켜보다가 바스락 소리를 냈다. 곽공이 "누구냐!" 그래서 들켰는데 어린 왕향제가 추위때문에 콧물도 흘리고 얼굴도 빨갛게 언것을 보았고 또 손에 든 옷을 보자 사연을 짐작하였다. 그리고 말년에 얻은 아들도 낙마하여서 죽었을때 왕향제의 효심에 감동하여 그를 자기의 마지막 제자로 생각하여 자신의 비전절기를 전했다. 

왕향제가 묻기를 "왜 사부님이 하시는 권법은 저희랑 틀린것입니까?"
"오행권은 여러 사람들의 권유에 못이겨 만든것이고 원래는 형의의 오행의 힘에 근거하여서 만든것이다." 
"그러면 오행의 힘이라는것은 정확하게 어떤것입니까?" 

"木은 신체의 모든 관절이 항상 나무처럼 구부려지고 또 나무의 꿋꿋한 뻗음처럼 구부림속에 
내뻗음(내뻗음-신근발골)을 항상 간직하라는 이야기이다. "

"土는 찰흙처럼 방송하고 움직임과 정지함이 들뜨지 않고 가라않고 두껍고 무거운 힘이다." 

"金은 쇠의 뾰족함을 일컫는 말이다. 힘을 쓸때에 관절들이 튀여나가는것. 힘쓸때의 강함이다." 

"火는 불똥이 몸에 튀었을때의 반응처럼 급하고 빠른 힘이다." 

"水는 힘을 쓸때 끊김이 없어야 하고 동작에 형태를 지어놓지 말아야 한다."

" 이런 다섯가지 힘들이 상부상조하여 항상 같이 있어야 한다."
"5행 12형의 힘은 참장에서 얻으며 참장이야말로 형의권의 무상절학이다." 

이리하여 왕향제는 그때부터 참장하는 법과 다른 여러가지 단련법들은 6시간씩 배우고 
곽공은 마루에 앉아서 왕향제가 조금이라도 움직이면 담뱃대로 쳤다고 한다. 



출처 - 초당야화   글쓴이: Lich  

by 코퍼스 | 2017/06/15 11:09 | 몸공부/마음공부 | 트랙백 | 덧글(0)

파이썬으로 작은 프로젝트를 진행해 본 소감

예전에 페북에 올렸던 단상인데, 그냥 백업용으로 여기에 다시 적는다.

오래간만에 개발 관련 포스팅.
(쓰기 귀찮은 마음도 있지만, 필 받았을 때 무언가 글로 남겨두고 싶어서리)

회사 업무의 일환(?)으로 네트워크 단말기들을 에뮬레이팅 해주는 
프로그램을 구현해야 되었다.

즉, 개별 mac 주소를 가진 수백개의 단말기들의 서버와의 인증과정(EAP 기반)을 수행할 수 있어야 한다는 요건이었는데,,

일 자체가 맥주소 변조와 패킷 스니핑, 인증 과정과 해당 프로토콜 구현이라,
hacking이나 해킹탐지 관련 솔루션 중에서 도움 될 만한 넘을 찾다가..
scapy라는 Python 기반 tool/library를 찾게 되었고,
이번 참에 파이썬도 한번 익혀보고자 해당 모듈로 업무를 진행했다.
(테스트로 2K개의 단말까지 커버하는 걸 보고, 순간 놀랐다
내가 짠게 이렇게 잘 돌아갈리가 ??, 
아직도 최대 성능은 잘 모르겠다.)

오랜시절 골수 Perl빠인 사람으로서 파이썬으로 실무를 해보면서 느낀 점들도 있지만,
트롤링될만한 요소들은 되도록 pass하려 한다.

다만, 몇 가지 느낀 점들을 적어보면,

. 파이썬도 쓸만하더라.. ㅋㅋ 이건 골수 Perl 팬으로서의 입장이니, 파이썬 애호가분들은 
괜히 눈 치켜 뜨지 마시길,,
확실히, 학습곡선은 Perl보다 낮은 것은 사실인 것 같다.
다만, 기존 모듈을 이용해 문제를 해결하는 수준을 얘기하는 것이지, 본인만의 잘 구현된 모듈 등을
만들기 위한 학습량은 결코 작지 않다는 것. 예전에 들었던 것보다, 언어의 스펙자체가 꽤 크다는 생각이 들었다.

. 다만, 텍스트 프로세싱 만큼은 Perl에 비해 뭔가 번잡스러운 느낌이 들었다.
앞으로도 텍스트처리는 Perl로 계속하게 될 터이지만, 이건 어디까지나 상대적인 것이다.

. 파이썬의 스레드는 GIL 기반이라 태생적인 성능 한계가 있지만, 반면에, 서너개의 스레드를 만들어 처리하는 것은
그만큼 쉽게 처리할 수 있다. 내 경우에는 처리하는 방식의 설계를 많이 고민하기는 했는데, 
메인스레드 3개로 일을 나누어서 처리했는데, 예상(워낙 안좋은 말이 많아서리) 보다는 쓸만하더라는..것.

. scapy라는 모듈은 굉장히 훌륭한 툴이자 개발프레임워크이긴 한데, 막상 내 입맛에 맞게 하는 것은
예상만큼은 쉽지 않았다. 일종의 허들 같은 진입장벽이 되는 부분이 좀 있다는 것.

. scapy는 파이썬 2.7 기반이라는 것, 현재 파이썬 3.x 대로 다시 개발되고 있는 것 같은데,, 
앞으로 1~2년은 좀 더 기다려야 되지 않을까 싶다.

. 파이썬 2.7의 print 를 쓰면서, 그 어색한 용법을 느끼며, 왜 귀도 아저씨가 기어코 버전 3에서 함수형식으로 바꿨는지 이해가 가더라.

. 사실, scapy 같은 환경을 Perl로 능히 할 수 있긴 하다.
좀 부실해보이지만 진짜 필요한 건 다있는, scaperl이라는 넘도 있고, 
기존의 REPL(인터렉티브쉘) 환경에서 Net, pcap 모듈을 연동해도 될 것으로 보였으니까.. 
이 부분은 언제 한번 개인적으로 시도해 보고 따로 포스팅하고 싶다.

. 지금 시대에 어느 언어가 좋으니, 나쁘니 하는 건 별 의미없는 것 같기도 하다
나름 다 장/단점이 있고, 어느정도 성숙된 결과, 거의 비슷한 성능과 생산성을 가졌으니,,
결국, 각자의 스타일대로, 처한 환경(협업 등)에 따라 쓰면 되는 것일 뿐

. 여러개의 프로그래밍 언어를 일정 수준 이상으로 익히는 것은, 단지 쓸 수 있는 연장의 숫자가 늘어나는 것이 
아니라 일종의 안목과 생각하는 깊이를 성장시키는 것 같더라는..

. 그럼에도, 불구하고 나이가 들어서인가? 예전처럼 새언어와 기술을 공부하는게 마냥 즐겁지는 않고,
뭔가 덤덩하고, 이슈가 생기면 기계적으로 분석해서 처리해 나갔다. 
아.. 옛날처럼 뭔가 막 흥분되고 재미있지가 않아..

by 코퍼스 | 2016/06/28 17:29 | IT | 트랙백 | 덧글(1)

개성공단 북측 근로자 임금 흐름도

개성공단의 북한 근로자 임금의 대부분이 북 노동당으로 흘러들어가서 핵이 되었고, 미사일이 되었고 어쩌고 하는데..

참,, 다 떠나서,,매년 600억 내외의 돈으로 몇 년 동안 알뜰살뜰 모아서 북쪽 애들은 잘도 만들었구나.. .

이미, 이 사항은 십 여년전에 논파된 사항인데도 '아님 말고 식'으로 또 떠들어대는구나..

그리고, 보수를 표방(자기들이 보수인줄 아는)하는 인간들도 무엇이 핵심인지 놓치고 있는 것 같다. 참, 답답하고, 한 치 앞을 안보는 
헛똑똑이들이 참 많은 것 같다.





아~~ 이글루스 살벌해졌네..^^

by 코퍼스 | 2016/02/16 11:18 | 이것저것 | 트랙백 | 덧글(6)

펄 크리스마스 캘린더에 기사 실음


드디어 나두 펄크리스마스 달력에 기사를 실었다.   Perl을 이용한 Excel 자동화에 관련된 기사로.
그간,  Perl 커뮤니티의 컨퍼런스나 세미나 등에서는 빠지지 않고 발표도 하고 그랬는데, 희한하게도 펄 크리스마스 달력에는
글을 싣지 못하였는데 이번에 소원 풀이 함.

특히, 편집해주신 Keedi님의 세밀함에 감동 먹음.


다른 재미난 기사들도 많으니 참고바람.
http://advent.perl.kr/2014/2014-12-04.html


by 코퍼스 | 2014/12/04 13:58 | IT | 트랙백 | 덧글(1)

영화 <엑소더스> 속, 모세의 스케일 아머

영화 엑소더스에 대한 아래 평도 재미있네^^

http://media.daum.net/entertain/culture/newsview?newsid=20141204105409084


그런데, 그것 보다는 포스터에 나오는 갑옷에 더 신경이 가네.

그나저나, 모세가 스케일 아머(물고기 비늘모양 찰갑)을 입고 있던데..
저 시기에 저게 있었나?

철기시대가 이집트의 경우에, BC12세기에시작했다고 하지만 완전히 철기로 접어든건 BC 1~2세기에서 AD쯤은 되어야 할 터인데..
무기는 그렇다 치고, 저 번쩍이는 스케일 아머를 만들 기술이 되었나?

이집트에서 람세스가 마치 스케일아머를 입은 것 처럼 보이는 벽화가 나오기는 했지만 아직 진위 여부가 확인된 건 아니고..

음.. 밀리터리 덕후나 고전무기 덕후들의 힘을 빌어야 할려나??





by 코퍼스 | 2014/12/04 13:52 | 이것저것 | 트랙백 | 덧글(0)

Data munging with Perl

좀 늦은감이 있지만 free ebook으로 풀린 "Data munging with Perl'을 소개합니다.

Data munging이란 raw data들을 원하는 형태로 가공/변형하여 원하는 정보를 얻게 하기 위한 일련의 절차라고 합니다.
내가 알기로는 이 'Data munging'이란 title을 딴 최초의 대중서(?)가 바로 이 'Data munging with Perl'입니다.
요즘에야 빅데이터다 뭐다 해서 'data munging'이라는 말이 ETL이라는 단어와 함께 가끔 사용되는데 이 책의 초판본이 내가 알기로는 2000년도 쯤이니까 벌써 13~14년이 되어가네요.

저자가 말하기를 예전에 짭잘한(^^) 수익을 안겨준 책인데, 최근에는 새로운 펄 모듈들도 많이 나왔고, Pelr에서의 기법이나 방식 등도 많이 변경되었기 때문에 예전 책을 사람들이 돈 주고  사는 걸 원치 않지만,   새로운 책을 저술할 여유는 없는 반면에 여전히 책에는 유효한 지식과 팁들이 담겨 있기 때문에 관련 내용을 PDF로 오픈한다고 합니다

음..최소한 learning perl  정도의 지식은 있어야 되지만 보다보면 꽤 도움이 되는 책이고,, 
나두 얼마전에 약간의 도움을 받았어요.
(시스템의 로그 파일을 받아서, 파싱 및 추출한 다음에 엑셀파일에 테이블과 차트로 만들어 주는 스크립트를 짰었는데 직접적인 도움이라기 보다는 쓸만한 팁을 제공받았었다)

펄을 이용한 데이터 처리에 관심있는 분들은 한번 훑어보기를 권합니다.
http://perlhacks.com/2014/04/data-munging-perl/

by 코퍼스 | 2014/10/16 19:32 | IT | 트랙백 | 덧글(0)

Rex를 이용한 하둡(Hadoop) 프로비저닝

거의 1년간을 불모지로 놔둔 이글루스인데.. 오늘 기사 찾아 이글루스에 들어왔다 조금 미안한(?) 
감정이 들었다.

작년 10월달쯤 공개 세미나에서 발표한 내용(그리고, 페이스북에서는 공개한)을 여기에도 올려서 포스트 숫자
(?)나 늘려야 되겠다.
=======================================================================================

요즘 유럽에서 나름 '핫(hot)'하다는 Rex를 이용해서 hadoop cluster를 자동으로 provisioning 한 내용을 
슬라이드쉐어에 올렸어요
http://www.slideshare.net/rainmk6/hadoop-meet-rexhow-to-construct-hadoop-cluster-with-rex

해당 내용은, 10월10일에 "빅 데이터 활용을 위한 오픈소스 프레임워크 기술 세미나"에서 발표한 내용입니다.

by 코퍼스 | 2014/01/13 18:57 | IT | 트랙백 | 덧글(0)

맥북에서 gd library 인스톨하는 것은 삽질이었다.

맥북 OS X 10.8 에서 Perl로 간단한 그래프하나 찍는 거 만들려다 라이브러리 문제로 거의 이틀을 삽질했다. 
해결하고 보니 참 쉬운 문제였는데...
문제는 gd library를 만드는데 있었는데.. 이 넘이 만들어지고 나서 테스트해보면
Incompatible libpng version in application and library
에러를 토해내고 뻗는거였다.

libgd 빌들 할 때, configure와 Make 파일 내의 libpng12를 모두 찾아서 libpng(symbolic linkfile) 나 최신의 libpng15로 바꿔주면 되는 거였다.
하긴.. 최신 gd library 소스 안에는 빌드스크립트가 빠져있어서.. 예전 소스를 받아서 처리했는데 그것도 한 몫한것 같다.
참고로,  맥에서 brew로는 제대로 인스톨되지 않는다. 

해맨 이유는 참고했던 외국 사이트의 애들이 제대로 해결못했다는 내용에 선입관이 생긴것과.. 
빌드 스크립트 내에서 libpng체크하는 부분만 보고서는.. 알아서 최신 버전 파일에 대한 심볼릭 링크를 
참고할 것이라고 생각하고 더 안본거였다.

흠..빌드 스크립트를 왜 그따위로 짰을까? 해결하고 나니 쓸데없는데 너무 시간을 썼다.
가뜩이나 스트레스 많이 받는데.. 대낮부터 술이 땡기네..

by 코퍼스 | 2013/02/06 14:53 | 트랙백 | 덧글(0)

빅데이터 처리에서 R언어는 좀 많이 과대평가된 것 같다.

R 스크립트 언어는 물론 좋은 언어이고,  통계처리에 특화된 만큼 다양한 통계관련 라이브러리를 제공하고 
그 결과에 대한 그래프처리까지 내준다.
요즘 나오는 스크립트 언어들 처럼, 단 몇 줄로 많은 일을 처리해준다. 

그런데,, 실제로 데이터 처리에서 쓰이는 수학/통계 루틴들은 뻔히 정해져 있고, 그 정도는 Perl, Pyton 등에서 
이미 훌륭하게제공되고 있다.  
물론 그래프/차트 처리도 말할 것은 없다.
(Perl의 각종 Data, PDL 모듈은 물론이고 Python의 Numpy, Scipy library등에서 쉽게 가져다 쓸 수 있다.)

하둡과의 연계가 매끄럽다고 얘기하는 이들은 무슨 근거로 그렇게 얘기해주는 지 모르겠고.. 
현재 R 관련 프로젝트에서 제공해주는 정도의 편리함( HDFS access, 기타)은 다른 스크립트들에서도 
똑같은 것들이 있고, 분산처리 환경에서의 제약사항이나 불편한 정도는 R도 역쉬 똑같이 가지고 있다.
 
게다가 그 편하다는 각종 수학 루틴들도 실무에서는 그냥은 가져다 쓸 수 없다.
로우 데이터를 가공하고, 처리해서 변환시켜야 되는 과정은 똑같기 때문이다.

예를 들어, 쇼핑몰 등에서의 사용자 거래 로그를 이용해서 사용자별 혹은 아이템별 기호의 유사도를 측정하자고 가정해보자.
inner product나 cosine similarity를 계산할 때, R의 %*% 식이나 cosine() 펑션을 그대로 쓸 수는 없지 않는가?


by 코퍼스 | 2013/01/18 11:37 | IT | 트랙백(2) | 덧글(0)

◀ 이전 페이지          다음 페이지 ▶