Daily NoPD/rEvieW2013.05.26 09:44
프로그래밍을 하다 보면 가장 자주 사용하게 되는 것이 조건 비교문이다. 사용자의 입력을 검증하기 위한 용도로 자주 사용될 뿐만 아니라 프로그램과 프로그램이 주고 받는 데이터를 확인하기 위해서도 자주 사용된다. 그런데 이런 과정이 많이 필요하거나 복잡한 로직에 따라 데이터를 검증해야 하는 경우에는 조건 비교문이 복잡해지고 가독성이 떨어질 수 밖에 없다. 시간이 지남에 따라 잘 정리되지 못한 코드는 유지보수가 힘들어지고 로직의 헛점으로 인해 프로그램에 오류가 발생할 가능성도 높아지게 된다.

정규표현식(Regular Expression)은 그 용도가 참 다양하지만 프로그래머들에게는 단순하면서도 아름답고 명료한 조건 비교문을 만들기 위하여 꼭 이해하고 있어야 하는 무척 중요한 것이라는 걸 많은 사람들이 알고 있다. 하지만 늘 시간이 부족한 프로그래머들이 체계적으로 정규표현식을 공부하는 것은 쉽지 않은 일이다. 정규표현식은 같은 문자열을 찾고 치환하는 방법이 수십가지가 될 수 있을 정도로 자유도가 높을 뿐만 아니라 표현식을 만드는 사람의 관점에 따라 다양하게 표현될 수 있기 때문이다. (한빛미디어, 한빛리더스 IT전문가 그룹)

 
한빛미디어에서 새롭게 출간된 "처음 시작하는 정규표현식 Regular Expressions" 은 일단 분량이 작아 야근으로 늦잠을 잔 프로그래머들이 만원 지하철 안에서도 충분히 읽을 수 있을 정도로 얇은 책이다. 그렇지만 얇다고 내용이 부실한 것도 아니다. 정규표현식을 거의 사용해보지 않은 사람들도 가장 기초적인 내용부터 중급 이상의 고급 정규표현식을 만들 수 있도록 예제 중심으로 책이 구성되어 있어 정규표현식의 기초를 잡기에 부족함이 없는 책이다.

그렇지만 조금 아쉬운 부분은 정규표현식을 이용할 수 있는 도구들을 너무 여러가지를 취급(?)하면서 내용이 전개되다 보니 오히려 도구들이 지원하는 정규표현식의 차이에 대해 시선이 분산되면서 읽는 동안 집중력이 떨어지는 구성이 되어 있다는 점이다. 두가지 정도의 정규표현식 도구만을 이용해서 내용을 전개하고 다양한 도구들의 미묘한 표현식 차이는 마지막에 간략하게 정리하고 그런 차이점이 있다는 정도를 알려줬다면 좋았을 것 같다는 생각이다.

정규표현식을 잘 다루는 사람들을 보면 단 한줄의 표현식으로 수십줄의 코드를 대체하는 경이로운 장면을 보여주곤 한다. 또 수백라인의 복잡한 로그 파일 속에서도 필요한 문자열들과 에러 메세지를 눈깜짝할 사이에 찾아내기도 한다. 그냥 부러워만 하기엔 정규표현식이 주는 효용가치가 너무 크다. 정규표현식을 시작하고 싶다면 한빛미디어의 "처음 시작하는 정규표현식 Regular Expressions" 를 선택해 보는 건 어떨까? 

YES24 에서 "처음 시작하는 정규표현식 Regular Expressions" 살펴보기 [바로가기] 

 
- NoPD - 
저작자 표시
신고
Posted by 노피디

세상에 있는 직업들을 나누는 방법은 여러가지가 있을 수 있다. 그 어떤 직업이 끊임없는 노력 없이 쉽게 얻을 수 있겠냐만은, ‘지속적인 학습이라는 관점에서 직업을 나누어 보자면 개발자는 죽는 그 날까지 공부해야만 하는 직업에 속하지 않을까? 매일 아침 눈을 떠 보면 어제 없던 수많은 프로그래밍 언어 기술들이 인터넷을 장식하고 있는가 하면 그 동안 있는 힘을 다해 갈고 닦은 코딩 스킬이 조용히 사람들의 관심에서 멀어져 가는 것도 심심치 않게 볼 수 있다는 것은 개발자의 직업 분류가 아주 적절(?)하다는 반증이다.

 

끊임없는 스킬업, 개발자의 숙명

 

이렇듯 상황이 결코 쉽지 않다 보니 눈을 뜨고 있는 동안 정신없이 새로운 것을 받아들이고 따라가는 게 일상이 되버린지 오래다. 새로운 프로그래밍 스킬에 대하여 지인과 토론을 하고 블로그 스피어 에서 갑론을박을 거듭하면는 과정을 통해 어느새 새로운 테크닉에 심취해 있는 나를 발견하곤 한다. 새로운 프로젝트의 시작은 그 동안 강호에서 갈고 닦은 스킬을 시험해 볼 수 있는 좋은 테스트 배드라고 생각되는 건 어찌보면 당연한 일인지도 모르겠다.

이러한 프로그래밍 스킬을 업그레이드 하기 위한 기본은 바로 자신이 다루는 프로그래밍 언어의 동작 원리를 이해하고 아키텍쳐를 내것으로 만드는 것이다. 우리가 바라보는 프로그래밍 언어의 기교적인 측면보다 이면에 깔려있는 기본을 제대로 이해하는 것이 필요하다는 이야기이다.

 

의사소통의 중요성

 

그런데, 헤아릴 수 없이 많은 시간과 노력을 통하여 고수 혹은 준고수에 이른 개발자들에게도 부족한 언어 스킬이 있으니, 이는 바로 사람의 언어이다. 개발자가 아름다운 로직만 만들고 다양한 기술을 이용하여 효과적이고 탄탄한 코드만 만들면 되지 사람의 언어까지 잘 해야 한다는 것은 무슨 궤변이냐고 하고 싶은 사람이 참 많을 것이다. 하지만, 아무리 뛰어난 무림의 고수라 할지라도 결국 고객 혹은 협업하는 사람과의 의사소통에 실패하면 결코 고수가 아니라고 생각한다. IT 라는 것이 사람이 편하기 위한 도구이고 현실의 사람과 동떨어져 생각할 수 없는 것이라는 점을 생각해 보면 왜 의사소통이 중요한지는 두 번 이야기 하지 않아도 알 수 있다.

 

논리적인 의사전달

 

개발 기간이 길고 중요한 데이터를 다루는 프로젝트 일수록 세밀한 테스트와 데이터 점검이 필수적이다. 첫 단추부터 잘못 끼워 프로젝트 말미에 회복이 불가능한 상태로 가지 않기 위해서다. 복잡한 시스템과 어플리케이션을 여러 사람이 함께 디버깅 하다 보면 예상치 못한 결과로 티격태격 하는 일이 왕왕 생기곤 한다. 실력이 출중한 사람이야 어렵지 않게 문제를 해결할 수 있겠지만 협업에서 보다 중요한 것은 다른 사람도 문제의 원인을 정확히 알고 유사한 상황에 대비할 수 있게 케이스를 공유하도록 해야 한다는 점이다. 특히나 고객과 함께 프로젝트를 하는 경우라면 보다 쉽고 논리적인 말로 고객에게 설명하고 상황을 이해시켜야만 한다.

 

사람의 언어스킬을 키우자

 

안그래도 할 것 많은 개발자들에게 대화의 능력까지 키우라는 게 부담이 되는 말이 될지도 모르겠다. 하지만, 옛말에 말 한마디로 천냥 빚을 갑는다라고 하지 않았던가? 어렵사리 구현하는 것보다 프로세스의 개선, 기존 작업 형태의 변경으로 쉽게 해결할 수 있는 일들도 얼마든지 많다. 개발자는 코드로 이야기 해야 한다는 말이 있긴 하지만, 때로는 사람과 사람의 대화로 보다 쉽게 해결할 수 있는 문제도 많다는 것을 인지하고 대화를 위한 사람의 언어스킬을 키우는 것도 우리의 목표로 삼는 것은 어떨까?


* 이 글은 월간 마이크로소프트웨어 2008년 7월호에 기고했던 내용을 편집한 글 입니다

- NoPD -
신고
Posted by 노피디

티스토리 툴바