대부분의 프로그래머에게는 사각지대가 있습니다. 분산 시스템을 디버깅하거나 새로운 프레임워크와 씨름하는 일은 기꺼이 해내면서도, 단 10초면 끝날 수 있는 수동 텍스트 편집에는 20분을 허비하곤 합니다. 이유는 항상 같습니다. 정규 표현식(regex)이 마치 의미 없는 노이즈처럼 보이기 때문입니다. 전형적인 패턴은 1990년대 모뎀에서 전송된 듯한 슬래시, 백슬래시, 문장 부호의 벽입니다. 이러한 시각적 혼란은 유능한 사람들조차 진정으로 가치 있는 기술로부터 멀어지게 만듭니다.
다행인 점은 정규 표현식이 어렵지 않다는 것입니다. 다만 밀도가 높을 뿐입니다. 기호들이 좁은 공간에 엄청난 양의 의미를 담고 있기 때문에, 실제로는 매우 정밀한 설명임에도 불구하고 눈에는 무작위로 보이는 것입니다. 올바른 멘탈 모델을 갖게 되면, 기호를 하나씩 해독하려 애쓰는 대신 기호가 묘사하는 형태를 읽게 됩니다. 그렇게 되면 노이즈는 완전히 사라집니다.
프로그램이 아닌 패턴
근본적인 변화는 정규 표현식이 실제로 무엇인지 이해하는 데서 시작됩니다. 여러분이 작성하는 대부분의 코드는 절차적입니다. 이것을 하고, 그다음에 저것을 하고, 이 조건을 확인하고, 다시 루프를 도는 식이죠. 하지만 정규 표현식은 절차가 아닙니다. 그것은 텍스트가 어떤 모습이어야 하는지를 설명하는 정적인 패턴입니다. 어떻게 검색할지에 대한 지침을 작성하는 것이 아니라, 매칭 엔진에 스케치를 건네주고 실행은 엔진에 맡기는 것입니다.
다음과 같이 일상적인 언어로 형태를 설명한다고 생각해보세요:
- 다섯 자리 숫자.
- 이메일 주소.
- 대문자로 시작하는 줄.
정규 표현식이 하는 일은 이 전부입니다. 다만 압축된 알파벳을 사용할 뿐이죠. \d{5}를 볼 때, 여러분은 마법을 보는 것이 아닙니다. "숫자 하나가 다섯 번 반복됨"을 보는 것입니다. ^[A-Z]를 볼 때, 여러분은 "줄의 시작, 그 뒤에 대문자 하나"를 보는 것입니다. 기술의 핵심은 암기가 아닙니다. 패턴을 슥 보고 그것을 다시 일상적인 언어 설명으로 번역하는 법을 배우는 것입니다. 일단 번역이 가능해지면 위압감은 사라집니다.
실제로 시간이 낭비되는 곳
사람들은 보통 충분히 고생하고 나서야 정규 표현식을 배우곤 합니다. 더 나은 접근 방식은 오후 시간을 통째로 낭비하기 전에, 패턴이 절실히 필요한 작업들을 미리 알아보는 것입니다.
200페이지 분량의 문서에서 모든 날짜를 찾아야 한다면, 정규 표현식은 단 한 번의 패스로 이를 찾아낼 것입니다. 애플리케이션이 수락하기 전에 사용자가 실제 URL을 입력했는지 검증해야 한다면, 패턴을 통해 주소의 기본적인 형태를 강제할 수 있습니다. 웹사이트에서 복사한 텍스트를 정리하면서 여러 개의 공백을 하나의 공백으로 합쳐야 한다면, 교체용 정규 표현식은 단 네 글자면 충분합니다. 지저분한 서버 로그에서 데이터를 추출해야 한다면, 정규 표현식은 종종 비정형 텍스트와 구조화된 보고서 사이를 잇는 유일하고 합리적인 가교가 됩니다.
다음과 같은 간단한 규칙을 세워보세요. 만약 수동으로 텍스트 편집을 50번 정도 반복해야 할 상황이라면, 멈추십시오. 대신 패턴을 작성하세요. 수동 반복은 느릴 뿐만 아니라 신뢰할 수도 없습니다. 47번째 사례를 놓치거나 33번째에서 오타를 낼 수도 있습니다. 패턴은 작업을 단 한 번, 정확하게 수행하며, 여러분이 적용하려 했던 규칙을 문서화해 줍니다.
효과적인 학습 루프
기억에만 의존해서 완벽한 패턴을 타이핑하려고 하지 마세요. 그렇게 하면 좌절감만 쌓입니다. 대신, 구문 속에서 길을 잃지 않고 계속 앞으로 나아갈 수 있는 긴밀한 루프를 따르십시오.
- 말로 형태를 설명하세요. 특수 문자를 건드리기 전에, 원하는 바를 정확히 적으세요. "숫자 네 자리, 그 뒤에 대시, 그 뒤에 숫자 두 자리, 그 뒤에 대시, 그 뒤에 숫자 두 자리." 명확하게 말할 수 없다면, 패턴으로 만들 수도 없습니다.
- 초안을 만드세요. 가능한 가장 넓은 범위의 기호를 사용하여 설명을 기본적인 패턴으로 변환하세요. 완벽함에 집착하지 마세요. 여러분은 지금 프로토타입을 만들고 있는 것입니다,