Perl이라는 언어, 기억하시나요.
"There's More Than One Way To Do It (TMTOWTDI)."
이 철학이 개발자를 얼마나 오만하게 만드는지 아십니까.
저는 10년 전, 이 말을 '멋대로 짜도 된다'는 면죄부로 여겼습니다.
당시 저는 NAVER 검색 인프라실에 있었습니다.
텍스트 처리에 강력하다는 이유로 Perl 스크립트가 곳곳에 산재해 있었죠.
그때 제 눈에 들어온 것이 바로 'Perlsecret'이었습니다.
비밀 연산자라니, 이름부터 얼마나 자극적입니까.
이건 공식 문서에도 없는, 커뮤니티에서 발견된 일종의 '문법적 트릭'들입니다.
예를 들어볼까요.
!!
이걸 'Bang Bang' 연산자라고 부릅니다.
그냥 불리언(Boolean)으로 강제 형변환하는 겁니다.
0+
이건 'Venus' 연산자죠. 문자열을 숫자로 바꿉니다.
그리고 최악의 흑역사, 일명 'Goatse' 연산자 =()=가 있습니다.
이 연산자는 스칼라 컨텍스트에서 리스트의 아이템 개수를 셀 때 씁니다.
당시 저는 이게 너무 쿨해 보였습니다.
변수를 선언하고, 루프를 돌리고, 카운팅을 하는 3줄짜리 로직을 단 한 줄로 줄일 수 있었으니까요.
my $count = () = get_search_keywords();이렇게 짜 놓고 동료들에게 자랑했습니다.
"코드가 이렇게나 우아해졌다"고요.
그게 얼마나 멍청한 생각이었는지 깨닫는 데는 딱 3개월이 걸렸습니다.
검색 로직 개편 후 첫 대규모 트래픽이 몰리던 날이었습니다.
키워드 추출 모듈에서 간헐적인 데이터 오염이 발생했습니다.
새벽 2시에 장애 알람을 받고 팀원들이 붙었습니다.
그런데 로그를 따라가던 후배가 제 자리로 와서 묻더군요.
"현수 님, 이 부분... 대체 무슨 뜻인가요? 괄호랑 등호가 왜 이렇게 많아요?"
후배가 가리킨 건 제가 짠 그 '우아한' 코드였습니다.
문제는 그 줄이 아니었지만, 그 줄 때문에 디버깅 흐름이 턱하고 막힌 겁니다.
후배는 그게 무슨 고차원적인 비트 연산이나 시스템 콜인 줄 알고, 건드리지도 못하고 벌벌 떨고 있었습니다.
그 코드를 해석하느라 낭비된 시간이 30분입니다.
장애 상황에서 30분이면, 서비스 신뢰도가 나락으로 떨어지기에 충분한 시간이죠.
제가 짠 코드는 자산이 아니라 부채(Liability)였던 겁니다.
그날 새벽, 복구를 마치고 저는 해당 코드를 지웠습니다.
그리고 아주 지루하고, 누구나 아는 평범한 scalar(@array) 문법으로 고쳤습니다.
이른바 '비밀 연산자'들은 사실 언어의 파서(Parser)가 동작하는 방식을 교묘하게 이용한 해킹에 가깝습니다.
이걸 쓴다고 성능이 비약적으로 좋아지지도 않습니다.
그저 "나 언어 좀 깊게 안다"는 개발자의 쓸데없는 자의식 과잉일 뿐입니다.
코드는 내가 퇴사한 뒤, 내 자리에 앉을 이름 모를 후배를 위한 편지여야 합니다.
암호문이 되어서는 안 됩니다.
최신 기술 스택을 쫓는 것도 좋고, 언어의 기기묘묘한 기능을 파헤치는 것도 공부가 됩니다.
하지만 그걸 프로덕션 코드에 넣는 건 범죄입니다.
여러분이 지금 작성 중인 그 '천재적인 한 줄'.
내일의 여러분, 혹은 동료의 새벽잠을 뺏을 수 있다는 사실을 기억하십시오.
개발자는 마법사가 아닙니다.
우리는 그저 견고한 배관공이 되어야 합니다.
