파이썬을 오래 써온 개발자라도 문자열 리터럴의 세부 규칙 앞에서는 한 번씩 멈칫하게 된다. 세브사이트(sebsite.pw)에 올라온 짧은 글은 두 줄짜리 퀴즈로 이 지점을 정확히 찌른다. 겉보기에 비슷한 두 줄의 코드가 있는데, 하나는 문법 오류(syntax error)이고 다른 하나는 정상적으로 동작하며 그 결과 문자열의 내용은 asdf\'가 된다. 이 차이를 만드는 핵심은 r 접두사, 즉 raw 문자열 리터럴이다.
raw 문자열이 역슬래시로 끝날 수 없는 이유
r 접두사를 붙이면 raw 문자열이 되어 역슬래시 이스케이프가 특별하게 해석되지 않는다. 그래서 r'asdf\'처럼 쓰면 역슬래시가 그대로 문자로 남을 것 같지만, 실제로는 그렇게 단순하지 않다. 원문이 지적하는 핵심은 raw 문자열도 일반 문자열과 '똑같은 방식으로 렉싱(lexing)된다'는 점이다. 즉 렉서 단계에서는 역슬래시가 여전히 뒤따르는 따옴표를 특별하게 취급한다. 그 결과 raw 문자열은 역슬래시로 끝날 수 없다. 역슬래시 뒤의 따옴표가 문자열의 끝으로 인식되지 않기 때문인데, 흥미롭게도 그 따옴표가 실제로 '이스케이프되는' 것은 아니다. 값 자체는 이스케이프 처리가 안 되는데, 문자열의 경계를 찾는 렉싱 단계에서는 이스케이프 규칙이 여전히 적용되는 셈이다.
이 어긋남은 언어 설계의 순수함보다는 구현 편의에서 비롯됐다. 원문은 이 처리가 애초에 '구현을 단순화하기 위해' 도입된 것이라고 설명한다. raw 문자열을 위해 완전히 별도의 렉싱 경로를 두는 대신, 일반 문자열과 동일한 토큰화 로직을 재사용하면서 값 해석 단계에서만 역슬래시를 다르게 다루는 방식이다. 덕분에 구현은 간결해졌지만, 사용자 입장에서는 'raw인데 왜 역슬래시로 못 끝내지?'라는 직관에 반하는 제약이 남았다.
f-문자열은 렉서 안에서 파서를 부른다
더 흥미로운 대목은 f-문자열이다. 원문에 따르면 f-문자열을 렉싱하려면 중괄호 안의 표현식에 대해 '완전한 파이썬 파서'를 호출해야 한다. 문자열의 토큰화라는 비교적 저수준 작업이, 사실은 그 안에서 언어의 전체 문법을 다시 파싱하는 작업을 품고 있다는 뜻이다. 그렇기 때문에 중괄호 안의 표현식은 따옴표를 포함할 수 있고, 여러 줄로 나뉠 수도 있으며, 심지어 주석까지 담을 수 있다. 이 표현식은 괄호로 감싸지지 않았고 주석 처리되지 않은 }, !, : 중 하나를 만났을 때 비로소 종료된다.
이 종료 규칙은 겉으로 잘 드러나지 않는 부작용을 낳는다. :가 표현식의 끝을 의미할 수 있기 때문에, f-문자열 안에서 람다 표현식과 대입 표현식(assignment expression, 이른바 바다코끼리 연산자)은 반드시 괄호로 감싸야 한다. 람다의 콜론이나 슬라이스처럼 :를 쓰는 문법이 포맷 스펙 구분자와 충돌하기 때문이다. 결과적으로 f'{lambda x: x}' 같은 코드는 그대로 쓸 수 없고 괄호가 강제된다.
실무에서 무엇을 기억할까
이런 세부 사항은 평소에는 눈에 띄지 않다가, 코드 생성이나 템플릿 처리, 정규식 패턴 조립처럼 문자열을 기계적으로 만들어내는 순간 문제로 튀어나온다. 특히 윈도우 경로나 정규식을 raw 문자열로 다룰 때 '역슬래시로 끝나는 리터럴'을 만들려다 문법 오류를 만나는 경우가 대표적이다. 이럴 때는 raw 문자열 뒤에 일반 문자열을 이어 붙이거나 역슬래시를 별도로 처리하는 식의 우회가 필요하다. f-문자열 안에 복잡한 표현식을 넣을 때 괄호를 습관적으로 감싸두는 것도 같은 맥락의 방어책이다.
무엇보다 이 글이 상기시키는 것은, 언어의 표면 문법이 항상 깔끔한 개념 모델을 따르지는 않는다는 사실이다. raw 문자열의 역슬래시 제약과 f-문자열의 파서 재귀는 모두 구현상의 선택이 문법으로 굳어진 사례다. 파이썬처럼 성숙한 언어에서도 렉서와 파서의 경계, 그리고 값 해석과 토큰화의 경계가 완전히 분리되어 있지 않다는 점은, 언어 도구를 만들거나 코드 자동 생성을 다루는 실무자라면 한 번쯤 곱씹어볼 만하다. 문법이 직관에 어긋날 때, 그 이면에는 대개 '구현을 단순하게 하려던' 실용적 타협이 숨어 있다.