2008년 8월 23일, 서울 Perl Mongers 김도형님과 여러분들의 노력으로 "Korean Perl Workshop 2008, Rising Perl"가
열렸습니다. 수 시간동안 20분짜리 정규발표들과 5분짜리 짧은 발표(Lightening Talk라고 하네요 ^^)가 있었고,
토요일 오후였음에도 대부분의 참석자들이 오후1시에서 9시까지 긴 시간동안 자리를 뜨지않고 즐겁게 발표들을 들었습니다.
저 역시, 새로운 이야기도 들었고, 간혹 머리를 통! 하게하는 깨우침도 받았습니다. Perl에 대한 사랑과 애정어린 비판도 있었고,
무거운 지식과 가벼운 이야기들이 8시간 내내 강연장을 달구었습니다.
저의 부족함에도 불구하고 1세대라는 이유로(*^^*) 강연자의 한사람으로 초대되어 여러분들께 제 생각을 말씀드릴 기회를 얻었습니다.
다른 발표자분들의 훌륭한 내용과 재기넘치는 발표 속에 행사의 수준을 끌어내리는 악역이 되면 어떡하나 하는 걱정도
있었지만, 용감하게 2번째 순서에 20분 발표를 마쳤습니다. 발표 15분째 5분 남았다고 일깨워주는 옛날 자명종 시계소리같은 따르릉 소리가
가장(?) 기억에 남는군요 ^^.
그 날, 발표했던 자료를 정리해서 여기 올립니다. 자료 자체에는 '말'이 없어서 그냥 pdf로 만들기는 뭐해서
말을 글로 정리해서 같이 올립니다.
발표내용
안녕하십니까, ...(생략)
발표내용은 Perl언어의 활용에 있어서 기본적인 기술을 향상시키는데 어떤 것이 요구되는가에 대한 저의 견해입니다.
개인적인 경험에 비추어 볼 때, 기초지식을 익힌 후 어떤 것을 했더니 해결방법들이 많아지더라는 지극히 개인적인 의견입니다.
그 내용은 다섯 가지로, Regular Expression의 정복, Reference의 활용, Package를 사용한 모듈화, CPAN을 이용하는 것, 유연함을 유지하는 것에 대한 의견입니다.
Perl의 문법은 다른 언어에 비해 크게 어렵다고 생각진 않습니다만, 일반적인 문법을 이해하고
난 후 가장 먼저 부딪혔던 것이 Regular Expression이었던 것 같습니다.
Regular Expression은 Perl이라는 언어가 가장 잘한다는 텍스트 데이터의 분석과 처리의 핵심을 차지합니다.
더구나, Regular Expression은, 이제, Perl과 같은 스크립트 언어에서만 국한되는 것이 아니라 다양한 언어에서
널리 사용되고 있는 만큼 반드시 마스터 해야 할 대상입니다.
저 역시 Regular Expression에 어느 정도 자신이 붙으면서 비로소 Perl이란 언어를 제대로 사용할 수 있겠다는
생각을 가지게 되었습니다.
Regular Expression의 사용에 있어서 실력이 붙으려면 어떻게 해야 할까요? 물론 문법은 잘 알아야죠.
공백과 주석을 쓰라던가, Lazy Quantifier를 사용하라는 등의 좋은 조언들이 있습니다.
그 외에 더 기억해 주셨으면 하는 내용이 있습니다.
첫째는 엄격함입니다.
Regular Expression으로 분석 처리할 데이터가 엄격한 형식을 갖추고 있다면 큰 문제가 되지 않습니다.
그러나, 데이터에는 예측하기 어려운 것들이 많습니다. 이러한 변칙에 대해서 억측하지 않아야 된다는 것입니다.
왼쪽에 설정파일의 일반적인 모습을 보여주고 있는데요, 특별한 점은 없어 보이죠.
이 데이터에서 설정 키와 설정 값을 추출하는 코드가 오른쪽에 있습니다. 괜찮아 보이죠?
하지만 파일 이름이 equal이라면 어떻게 될까요? 이 경우 $value 변수에는 equal 사인이 아니라 빈 문자열이 assign됩니다.
원치 않는 결과죠. 파일 이름에 대해 억측했기 때문에 이런 오류가 나오는 것이죠.
수정은 점 대신에 \w를 사용하는 것입니다.
물론 여기에 공백까지 처리해 주면 더 완전하겠습니다.
두 번째도 비슷한 보기입니다만 데이터 보다는 Regular Expression 엔진이 어떻게 동작하는가에 대한 내용입니다.
변수 $txt에 "Korean Perl Workshop 2008"이라는 문자열이 있고, 그 오른 쪽의 코드로 $year 변수에
숫자를 추출하여 저장하려고 합니다.
$year 변수에는 어떤 값이 들어갈까요?
2008이 아니라고 생각하신다면 센스가 있는 분이십니다.
이 경우 $year에는 8이 들어갑니다. 이른바 greedy quantifier의 특성 때문입니다.
앞의 .* 패턴이 가능한 많은 문자들을 먹어 치운 후 숫자 character class에 맨 끝의 8자 하나만 남겨주기 때문이죠.
이 경우 * 뒤에 ? 하나를 붙여주면 해결됩니다.
정리하면, 입력되는 데이터에 대해 억측하기 보다는 Regular Expression을 엄격하게 만들어서
다양한 경우에 대비할 수 있어야 하고,
Regular Expression을 만들면 그 결과를 속단하지 말고 차분히 따져보는 습관을 가져야
Regular Expression을 제대로 쓸 수 있게 된다는 것이죠.
그래서, 테스트가 또 강조됩니다.
Regular Expression을 엄격하게 만드는 것 만큼 확인해 보는 것이 중요합니다.
조금이라도 복잡하다고 느껴지면 실제 프로그램에 사용하기 전에 테스트를 거쳐보시기 바랍니다.
Regular Expression이 제대로 만들어졌는지 확인하기 위한 방법은 다양한 내부변수들을 활용하는 것입니다.
여기 보이는 것처럼 Perl은 Regular Expression과 관련한 다양한 내부변수들을 가지고 있습니다.
앞에서 보여드린 이 잘못된 Regular Expression에서 $year변수를 출력해보는 간단한 테스트만
실행해도 실제 사용 전에 문제를 찾아내고 고칠 수 있습니다.
하물며 복잡한 Regular Expression에서는 더 말할 필요도 없겠죠.
이렇게 확인을 위한 간단한 코드를 만들어서 제대로 만든 것인지 검토하는 습관을 가지면
Regular Expression과 Perl에 대한 skill 향상에 큰 도움이 되리라 확신합니다.
다음은 Reference에 대한 내용입니다.
Perl의 Reference는 C언어의 Pointer와 같지는 않지만 유사한 것 같습니다.
Reference를 잘 이해하고 사용하면 Perl의 활용도가 높아집니다.
Reference는 배열이나 해쉬 자체를 서브루틴으로 넘기거나 서브루틴에서 return 받을 때
사용되는 등 여러가지 활용이 많지만, 제가 가장 많이 활용하는 것은 데이터를 구조화 하는 것입니다.
위 "AA상품을 구매한 광진구 홍길동씨, 3십만원에 샀고 까다롭다"라는 상품과 고객의 구매관계에 대한 정보를 저장하는 두 가지 방법이 아래에 표현되었습니다.
위쪽은 서로 관계된 데이터가 제각각 떨어져서 개별적인 해쉬들로 들어갑니다.
아래쪽은 관계된 데이터가 database라는 하나의 해쉬에 모두 들어갑니다.
어느 쪽이 읽기가 좋습니까? 아래쪽이죠.
Reference를 사용하면 이렇게 데이터를 구조화할 수 있습니다.
이 경우는 해쉬의 해쉬의 해쉬인데요, 해쉬의 배열, 배열의 해쉬, 해쉬의 배열의 해쉬의 배열의 해쉬의 배열의 배열의 해쉬도 만들 수 있습니다. 심지어는 서브루틴의 리퍼런스를 저장해서 사용할 수도 있습니다.
만일 Perl에 Reference가 없었다면, 제가 계속해서 Perl을 사용했을까 할 정도로
저 개인적으로는 반드시 알아야만 Perl의 활용도가 커지는 기술이라고 생각합니다.
아직 Reference를 많이 사용하지 않으신다면 조금만 문서를 거들떠 보시기 바랍니다.
다음은 Package에 관한 내용입니다.
Package는 객체지향적 프로그래밍의 도구이기도 합니다만, 오늘 여기서는 너무 깊게 가지 말고
모듈화에 대해서만 이야기 하겠습니다.
Package를 세 번째 '반드시 알아야 할 것'으로 꼽은 이유는 이 것이 복잡한 프로그램에 있어서
특정 관심사에 대해 다루는 서브루틴들을 묶어내는데 필수적인 기술이기 때문입니다.
왼쪽은 한 뭉치의 서브루틴들이네요.
Get 어쩌고 저쩌고…
오른쪽은 좀 더 체계가 있어 보입니다.
Reference에서 본 모양과 비슷합니다.
…
사실 Reference가 맞습니다만, 여기서는 객체 또는 모듈이라고 부르는 것이 좋겠습니다.
왼쪽의 경우는 모든 관심사를 혼자서 다 다루는 모양입니다.
반면, 오른쪽은 disk에 대한 관심사는 disk객체가, memory에 대해서는 mem 객체가, cpu는 cpu 객체가 다루는 것으로 보입니다.
이렇게, 간편하게 관심사를 분리해서 다룰 수 있게 하는 것이 Package입니다.
OOP라고 말하는데, 여기서는 소극적으로 관심사라고 말하겠습니다.
이렇게 관심사를 분리하면 프로그램을 만들고 유지하기가 편해집니다. Main 패키지에서는
다른 패키지를 불러서 사용할 뿐이니 그 패키지와 main 패키지의 로직은 분리되고, 따라서 main 패키지의 로직이 단순해집니다.
관심사의 분리는 다른 표현으로 문제의 분리라고 할 수 있습니다.
복잡한 문제를 복잡하게 풀어 내는 것이 실력은 아니죠. 복잡한 문제를 단순한 문제들로
분리해 내는 것이 실력이라고 본다면, 패키지를 사용해서 문제를 분리해 낼 수 있어야
Perl의 skill이 향상된 것이라고 말할 수 있겠지요.
왼쪽은 패키지와 그에 속하는 서브루틴을 만드는 단순한 예제로 MyPackage.pm 파일의 내용이고,
오른쪽은 그 패키지를 사용하는 코드입니다.
이 내용을 다 설명 드리진 않겠습니다.
깊이 들어가자면 이 보다 더 많은 내용을 알아야 하지만,
Package를 처음 만들어서 시작하자면 이 정도 만으로도 출발은 할 수 있다는 것을 보여 드리기 위해서 만든 간단한 코드입니다.
또, 눈치 채셨겠지만, Package에서도 reference는 중요한 부분을 차지하고 있다는 점도 말씀 드리고 싶습니다.
Package를 만듦으로써 자신의 코드를 배포하는 것도 쉬워집니다. 패키지와 패키지의 사용이 완전히 분리될 수 있기 때문이죠.
물론 subroutine들을 모아놓고 이를 require해서 쓰는 방법도 있지만, 그 경우는 데이터를 main 로직과 라이브러리 간에 분리하기가 쉽지 않죠.
저는, Package를 사용하게 되면 Perl에 관한 기술력에 있어서 한 차원 높은 단계로 올라가는 것이라고 감히 말씀 드립니다.
아직 Package를 만들어보지 않으셨다면, 꼭 문서들을 읽어보시고 Perl을 더욱 즐길 수 있기를 바랍니다.
다음은 CPAN에 관한 내용입니다.
Package를 만들어서 사용할 수 있게 되면, 코드들이 단순해지고 유지하기도 좋습니다.
하지만, Package를 직접 만들기 전에 먼저 CPAN에 들러 보시길 강력히 권합니다.
이미 있는 것이라면 굳이 직접 만들 필요는 없죠.
Perl을 배운지 얼마 안돼서 어떤 시스템의 특정 디렉터리 트리 아래에 특정 파일들을 지워야 하는 일이 있었습니다.
잘 기억이 안 납니다만, Recursive한 서브루틴을 만들어서 처리했죠.
왼쪽이 제가 재발명한 바퀴…도 아니고 ``바꾸''입니다. ^^
뭐가 잘 못되었을까요? … 현재 디렉터리와 parent 디렉터리에 대한 처리를 빼먹었습니다.
그 결과 잘 못 만든 코드 때문에 시스템을 날려버릴 뻔 했던… 일이 있었던거죠. ^^
CPAN에서 File::Find라는 모듈을 찾아서 썼다면, 일도 간단하고, 사고도 없었을 일이죠.
오른 쪽은 정상적인 바퀴, File::Find를 사용한 프로그램입니다.
훨씬 더 간단해지고 실수의 우려도 없는 버전이죠.
뭔가 고민이 생겼다면 먼저 CPAN 사이트를 찾아가시고, 거기 없다면 진짜 발명을 하셔야죠.
CPAN은 라이브러리의 집합일 뿐만 아니라, Perl의 정신이라고 생각합니다.
Perl 정신의 또 다른 구현체이고, CPAN이 있음으로써 비로소 Perl이 완전해졌다는 생각이 듭니다.
CPAN에는 가벼운 라이브러리부터, 데이터베이스, GUI, 네트워크, 프레임워크에 이르기 까지 다양한 모듈들이 있습니다.
여기 꼭 맞는 격언이 있죠. ``꼭 필요한 모듈은 항상 존재한다''
이 CPAN을 잘 활용하는 것 만으로도 ``오! Perl 꽤나 하는데?'' , 이런 소릴 들을 수 있을 겁니다.
사용하는 모듈의 내용을 더 알고 싶다? 그러면 CPAN에 제공된 모듈들을 직접 열어 보십시오.
물론, C를 사용해서 Perl을 확장하는 메커니즘에 대한 이해가 있어야 온전한 이해가 되겠지만, 굳이 그렇지 않더라도 많은 영감을 얻을 수 있을 겁니다.
고양이가 생존하는 데 있어 유연함이야말로 가장 큰 힘이 되지 않을까 생각됩니다.
싸가지가 좀 없다는 것을 빼면 멋진 동물이죠. ^^
다른 언어에서도 마찬가지지만, Perl을 사용함에 있어서도 유연함은 큰 무기입니다.
보통은 실력이 있어야 유연해지겠지만, Perl에 있어서는 유연한 정신 그 자체가 실력이라는 생각이 듭니다.
왼쪽에 국가별 인구 데이터가 있습니다.
이 데이터를 왼쪽 아래처럼 인구 순으로 정렬하여 출력하는 것이 숙제입니다.
오른쪽 위에는 좀 긴 버전의 스크립트가 있고, 그 아래에는 map, sort 등을 한 줄에 나열한 짧은 것이 있습니다.
어떤 것이 옳은 답일까요?
…
모두 옳습니다.
그럼, 어떤 것이 더 나은 답일까요?
…
가릴 수 없습니다.
Perl의 모토, “There Is More Than One Way To Do It” 에 이른 바와 같이, 방법은 여러 가지이고, 그 것이 해결책을 제시한다면 모두 옳은 것입니다.
그러니,… 어떤 것이 멋진 코드일까 하는 것을 고민하기 보다는 자연스럽게 흘러나오는 코드를 선택하시고 즐기시길 바랍니다.
즉, 어떤 멋진 코드를 선택할 것인가 하는 의미 없는 고민에서 벗어나 자기 능력과 환경에 맞는 코드를 선택하는 유연함을 갖추시면
실력은 자연스럽게 커나갈 것이라고 확신합니다.
이런 저런 기술들을 읽히고 나면, Perl이 아주 강력하다는 것에 대해서 동의하고 자꾸 자꾸 매력에 빠져들게 됩니다.
돌멩이를 쓰던 원시인에게 도끼를 주고 사용법을 알려주면, 돌멩이를 집어 던지고 도끼를 열심히 사용하게 되겠죠.
웬만한 짐승도 한방에 빠샤!!
나무도 한방에 빠샤!!
호두처럼 단단한 것도 한방에 깔 수 있고,
그러다 보니 사과도 깎아 먹고 손톱도 도끼로 깎습니다. 오버죠.
도끼가 좋은 것이긴 하지만 만능이 될 수는 없죠.
Perl이 좋은 언어이긴 하지만 거기 빠져선 안 된다는 이야깁니다..
역설적이게도 저는 Perl을 배우면서 더욱 유연해진 것 같습니다.
이런 코드, 저런 코드, 길고 짧은 코드, 쉬운 것과 어려운 것, 그 어간에 있는 것들, 그러한 것들을 줄 세우지 않게 되고…
Perl이 설치되지 않은 컴퓨터를 보고 참을 수 없긴 하지만,...
Perl이 있어도 Perl을 사용하지 않을 수 있는 정도는 된 듯 합니다. ^^
다른 컴퓨팅 언어와도 불필요한 비교를 할 필요는 없다고 봅니다.
여기 Java도 차고, 저기 C++도 차고, Python도 차고, Perl도 차고 필요에 따라 뽑아서 쏘면 되니까요. ^^
말하자면, Perl이라는 언어도 도구일 뿐이지, 절대 목표는 아닌 만큼 언어의 선택과 언어를 대하는 것에 있어서도 유연한 자세를 유지했으면 한다는 이야기입니다.
이런 자리(워크샵)가 있다는 것에 놀랍고 감사 드립니다.
Perl을 만드신 Larry Wall형님(^^ 54년생이죠 ^^)에게 먼저 감사드리고,
어려운 컨퍼런스를 기획하고 준비하신 김도형님과 많은 분들, 노고에 감사 드립니다.
부족한 사람을 초대해 주신 것도 감사 드립니다.
특히, 부족한 이야기에 끝까지 귀 기울여 주신 여러분께(이 페이지에서 글을 읽어주신 여러분께도) 깊이 깊이 감사 드립니다.
