수학이나 전산학에서 "expression"은 "식"을 뜻합니다. 그런데 유독 프로그래밍, 소프트웨어 개발 쪽 사람들이 "expression"을 "표현식"으로 더 장황하게 번역하려는 경향이 있습니다. 그냥 "식"으로 쓰는 게 낫다는 것을 여러분께 설득해 보고자 합니다.

용어

우선 용어의 대응 관계를 살펴 봅시다. 전산학의 "expression"은 수학의 "expression"에서 왔다는 점이 명확해 보입니다. 수학의 "expression"은 "식"으로 번역됩니다. 이것도 명확합니다. 반대로, 덧셈식, 뺄셈식 등의 "식"을 영어로 뭐라고 번역해야 할까요? 라고 물으면 이것도 "expression"밖에 없습니다.

그런데 "expression"에 "식"이라는 뜻만 있는 것은 아닙니다. "expression"은

• (감정, 의견 등의) "표현"이기도 하고,
• 얼굴 "표정"이기도 하고,
• "식"이기도 합니다.

따라서, 문맥에 따라 구분해서 번역해야 합니다. 그런데 "표현식"은 여러 뜻을 그냥 다 넣어 버리는 것이죠. 이러면 마치 "state"를 "주국가"로 번역하거나, "score"를 "점수악보"로 번역하는 것과 비슷합니다. 곤란합니다.

그러면 왜 프로그래머들은 자꾸 "표현식"으로 쓰고 싶어하는 것일까요? 아마도 두 가지 이유인 것 같은데요. 하나는 "사전적 정의 1번"에 이끌리는 것입니다. "expression"을 사전에서 찾으면 "표현"이 가장 먼저 나오니까요. 또 하나는, 대부분의 프로그래머들이 초·중등교육 수학이나 기타 경로를 통해 "-식"으로 끝나는 말들을 배우고 온다는 것입니다. 공식, 등식, 부등식, 방정식, 다항식... 그러므로 이 "식"이 어떤 "식"인지를 왠지 구분해야 할 것만 같은 필요를 느끼는 것입니다.

수학의 "expression"

그러나 막상 들여다보면 그런 필요는 존재하지 않습니다. 굳이 그런 필요가 있다면 그건 수학 쪽일 것입니다. 수학에서는 이름이 "-식"인데 "expression"이 아닌 것들이 있으니까요.

• 예를 들어 7x + 5 < 2 라는 표기가 있으면
  • 7x + 5 < 2 전체는 "inequation"이고
  • 7x + 5 부분만 "expression"이라는 것이죠.

법으로 정해진 건 아니지만 일반적으로 영어권 수학 교육에서 이렇게 구분하는 것 같군요. 그렇다면 "inequation"이 "부등식"에, "expression"이 "식"에 대응하는 것이 뭔가 부자연스러워 보일 수도 있습니다.

하지만 실제로는 아무 문제도 되지 않고 있습니다. 대한수학회의 수학용어집에서도

• "expression"은 "식"
• "algebraic expression"은 "대수식"
• "linear expression"은 "일차식"
• "quadratic expression"은 "이차식"
• "homogeneous expression"은 "동차식"

식, 식, 식입니다. 그밖에 "expression"이 아닌 것들도 엄청나게 많이 "식"에 대응되어 있는데 "alternant"도 "교대식", "cardinal invariant"는 "기수적 불변식", "idempotent identity"는 "멱등식" 등등... 이렇게 "식"을 아낌없이 퍼부었지만 대한수학회는 "식"으로 인한 고통을 호소하지도 않고, "표현식" 같은 말을 창안할 필요도 느끼지 않습니다. 문맥에 따라 "식" 대신 "표현"을 선택하는 경우는 있어도 (예를 들어 "numerical expression"은 "수치적 표현"^[1]) 둘을 짬뽕해서 "표현식"을 쓰는 경우는 없는 것입니다.

"식"만 따로 쓰는 것이 왠지 꺼림칙해서 "표현식"을 쓰는 것은, 실은 근거 없는 공포에 의한 것입니다. "expression"은 이미 "식"에 대응되어 있고, 그렇게 쓰는 데에 문제가 없다는 것이 오랜 세월 입증되었습니다. 모호할 여지가 있다면 합성어들입니다. "대칭식"이 "symmetric expression"인지 "symmetric style"인지 헷갈린다는 것은... 네, 이론상 있을 수 있는 일이죠. 그러나 "식"만 쓰는 경우에는 그럴 일도 없는 것입니다.

전산학의 "expression"

그리고 이건 수학 얘기입니다. 전산학에서는 "부등식"은 "식"이 아니니까 좀 이상하다는 식의 거리낌도 전혀 없습니다. 7 * x + 5 < 2는 사실상 거의 모든 실용 언어에서 "expression"입니다!

파이선에서 '여기에는 식이 들어가야 한다'고 말하면, 이것은 즉 함수 적용이나 연산자 같은 것은 괜찮지만 def 같은 제어 구문은 넣으면 안 된다는 뜻입니다. 식은 식이고, 식끼리 조합하여 더 복잡한 식을 만들 수 있고, 식을 다른 식으로 최적화할 수 있고, 평가하여 값으로 교체할 수 있고, 내부적으로는 거의 항상 트리로 표현되고... 이 모든 속성에 관하여 논할 때 그냥 "식"이라고 쓰면 됩니다. 언어 구현체 코드를 봐도 exp, expr 등의 용어로 표현하는데, 이걸 다 그냥 "식"으로 옮겨도 아무런 문제가 안 생겨요. 한국어에서 "식"만 따로 썼을 때 다른 동음어·동철어가 많이 엮여 있거나 모호성이 증가할 여지도 없습니다.

전산학의 "표현"

"표현식"이 더 문제가 되는 점은 다른 역어와 겹친다는 것입니다. 전산학에서 "표현"은 매우 요긴한데, "representation"에 대응하기 때문입니다.

• 예를 들어 같은 자료에 대해서
  • "binary representation"과
  • "text representation"이 있을 수 있죠.
• 또 어떤 자료의 "memory representation"이 어떠한가를 논하는 것도 소프트웨어 개발에서 중요한 문제입니다.

이 "representation"은 도저히 "표현" 말고 없죠. 굳이 뜻 맞는 대안을 찾자면 "묘사"가 있겠습니다만... 딱 봐도 "representation"의 역어로 "표현" 대신 "묘사"를 정착시키기는 어렵겠죠?

"expression"을 "표현"으로 번역할 때에는 감정이나 의견의 "표현"을 뜻하는 것이고, 전산학에서 말하는 "표현"과는 무관합니다. 또 전산학에서 "expression"이 있을 때 그것이 어떤 개념을 "표현한 식"인 것도 아니에요. 이러면 "표현"이 아닌 것이 없게 됩니다. 예를 들어:

• "code"는 어떤 알고리듬을 "표현"한 것이니 "표현 코드"인가? 아니죠. 그냥 코드입니다.
• "AST"는 어떤 구문 구조를 "표현"한 것이니 "표현 트리"인가? 아닙니다. 그냥 트리예요.
• "UTF-8 byte string"은 어떤 텍스트를 특정한 인코딩으로 "표현"한 것을 말하는데, 그럼 "UTF-8 표현바이트열"로 번역할 것인가? 아니죠. 대체 왜. 그냥 "UTF-8 바이트열"이라고 하면 되잖아요.

마찬가지로 "표현식"이라고 할 필요가 전혀 없고 그냥 "식"이라고 하면 됩니다. 특히 "정규표현식"에 이르면 정말이지 변명의 여지가 없습니다. "정규식"이라고 썼을 때 이것이 "regular expression"이 아닌 다른 것으로 해석될 수가 없잖아요? "정규표현식"이라고 장황하게 쓸 필요가 없습니다. "표현"을 넣지 않아도 돼요.

결론

그런데 굳이 "정규식"을 냅두고 자꾸 "정규 표현식"을 미는 것이 누구일까요. 성이 정씨이고 이름이 규식인 분들인가요? 정 선생님... 하... 진짜... "expression"을 "식"으로 옮기면 "regular expression"의 역어는 선생님의 존함과 겹치는 것이 사실입니다. 하지만 그 고충을 성이 표씨이고 이름이 현식인 분들에게 떠넘겨서야 되겠습니까!! "regular expression"이 얼마나 유용한데, 나쁜 뜻도 아닌데, 이러실 필요가 있을까요? 정씨 인구가 표씨 인구보다 많다고 해서 이와 같은 전횡은 있어서는 안 될 일입니다.

각주

---

1. 사실 저는 대한수학회의 이 용어도 좀 의문입니다. "numerical expression"이 "식"이 아니라 "표현"이어야 할 이유가 있을까요? "numerical expression"이 "식"이 아닌 경우가 있나요? 저는 그냥 "수식"에 대응시켜 간결하게 썼어도 문제가 없었을 거라고 생각하지만, "수식"이 너무 과감하다면 "수치식"을 쓰면 되고, 아무튼 "수치적 표현"으로 장황하게 쓸 필요는 없을 텐데 말이죠. ↩︎