헝가리안 표기법, 무엇인가?

작년(2020년) 정보처리기사 실기 시험 문제에 ‘헝가리안 표기법에 대해 간략히 설명하시오’라는 문제가 출제돼 정보처리기사 수험생들 사이에서 논란이 일어난 적이 있습니다. 최신 트렌드를 문제 출제에 반영하겠다면서 이와는 동떨어진 구식 표기법에 대한 내용을 물어보는 문제를 출제했다는 게 논란의 이유입니다.
여기서는 헝가리안 표기법이 무엇인지, 또 왜 사용을 피해야 하는지에 대해 설명합니다.

변수명 등에는 띄어쓰기를 할 수 없기 때문에 이를 대신할 방법이 필요한데, 소문자로 시작하되 본래 띄어쓰기가 들어가야 할 부분의 다음 글자를 대문자로 표기하는 ‘카멜 케이스'(Camel case)라는 표기법이 있습니다. 예를 들어 ‘Camel case’를 camelCase라고 적는 식입니다. 이 모양이 마치 낙타의 혹을 연상시킨다 하여 이런 이름이 붙었습니다.
여기서 파생된 표기법 중 하나가 바로 이 포스트에서 설명할 ‘헝가리안 표기법'(Hungarian notation)입니다. 헝가리 출신의 프로그래머 찰스 시모니(Charles Simonyi)가 마이크로소프트사의 개발 책임자로 재직할 당시 고안한 표기법으로, 변수의 자료형 등을 접두어 형식으로 표현하는 방식입니다. 예를 들어 어떤 문자열 변수의 변수명을 name이라고 한다면 앞에 s를 붙여 sName이라고 하는 식입니다.
헝가리안 표기법의 연원은 60-70년대 C언어 이전 타입시스템이 없는 언어로 거슬러 올라가는데, 말 그대로 타입시스템이 없었기 때문에 변수명에 변수형을 명시할 필요가 있었습니다. 이후 타입시스템이 있는 언어의 등장으로 굳이 그럴 필요가 없어졌지만 이것이 ‘헝가리안 표기법’이라는 이름으로 부활해 널리 쓰이게 된 것은 당시 IDE의 기능이 빈약했기 떄문에 이 방식이 상당히 편리했기 때문입니다.

헝가리안 표기법은 예를 들어 i는 정수, f는 부동소수점 실수, sz는 NULL로 끝나는 문자열 등으로 하지만 꼭 그렇게 해야만 하는 것은 아니고 개발자마다 차이가 있습니다. 필자의 경우 비주얼 베이직(Visual Basic)을 사용하면서 헝가리안 표기법을 처음 접했는데, 텍스트박스는 txt, 라벨은 lbl, 버튼은 btn 식으로 객체명에 3글자의 접두어를 쓰는 것이 시쳇말로 ‘국룰’이었습니다.

하지만 시간이 갈수록 IDE의 발전과 동적 언어의 대두로 헝가리안 표기법의 부작용이 부각되기 시작하고, 마이크로소프트에서마저 헝가리안 표기법을 사용하지 말 것을 권고하고 있으며, 다른 유수의 IT 기업에서도 헝가리안 표기법의 사용을 권장하지 않는다(not recommended)고 규정하고 있습니다.
오늘날 헝가리안 표기법의 사용을 피해야 할 이유들은 다음과 같습니다.

• 요즘 나오는 성능 좋은 IDE를 사용하면 스크롤을 올리지 않고도 어떤 변수명의 변수형을 손쉽게 알 수 있습니다. 따라서 변수명에 변수형을 명시할 필요성이 떨어집니다.
• 어떤 변수형인지 명백해 보이는 변수명에도 접두어를 붙이는 불합리함이 생기게 됩니다. 독자 여러분 중에는 학창시절 학교에서 한문을 배울 때 옥상가옥(屋上架屋)이라는 고사성어를 들어 보신 분들이 계실 것입니다. 마치 지붕 위에 또 올려놓은 지붕처럼 사물이나 일이 무의미하게 거듭됨을 뜻하는 말인데, 헝가리안 표기법에서 이러한 상황이 벌어집니다.
  예를 들어, 게임 프로그램을 만든다고 했을 때 남은 기회를 lives라는 변수로 선언해야 하는데 정수형으로 하고 헝가리안 표기법을 따른다면 iLives 정도가 될 것입니다. 그런데 이렇게 하면 코드를 읽는 입장에서는 ‘lives는 라이프 수(세 번 죽으면 게임오버)니까 정수형임이 명백한데 굳이 그 앞에 i를 붙여서 정수형임을 명시해야 하는 이유가 있는가?’ 하는 의문이 제기될 수도 있습니다.
• 또한, 이렇게 헝가리안 표기법에 의해 일일이 추가된 접두어는 코드를 파악하는 데 장애물이 되기도 합니다. 앞의 게임 프로그램 예를 들면 변수명을 lives, score, health 등으로 적으면 될 걸 굳이 iLives, lScore, fHealth 등으로 일일이 접두어를 붙이면 가독성에도 좋지 않은 영향을 끼치게 됩니다.
• 변수형 접두어 때문에 변수명이나 함수 인자 등을 기억하기 힘들어지는 문제가 있을 수 있습니다.
• 변수형이 중간에 바뀌는 경우가 있을 수 있는데 이러면 변수명과 변수형 사이의 모순이 발생하게 되므로 변수명도 바꿔야 하는 번거로움이 생깁니다. ‘변수형 바꾸는데 왜 굳이 변수명까지 바꾸는 쓸데없는 고생을 사서 해야 하는가?’ 하는 의문이 들게 하는 대목입니다. 애초에 헝가리안 표기법을 쓰지 않으면 이런 고생을 할 이유가 없다는 점을 생각하면 당연히 들 수밖에 없는 의문입니다. 이런 점 때문에 특히 동적 타입 언어(자바스크립트, 파이썬, PHP 등)에서는 적합하지 않은 표기법입니다.

정리하자면, 옛날에는 정적 타입 언어가 대세였고 IDE가 빈약했기 때문에 헝가리안 표기법이 장점을 발휘했으나 오늘날에는 동적 타입 언어가 유행하고 있고 IDE의 기능이 강력해지면서 헝가리안 표기법의 장점이 퇴색되고 오히려 코드 파악을 어렵게 만들어 유지보수를 방해하는 요소로 작용하고 있기 때문에 더 이상 헝가리안 표기법을 쓰지 말 것을 권고하고 있는 추세입니다.

다만, 헝가리안 표기법을 완전히 배척할 필요까지는 없는데, 헝가리안 표기법에 의해 객체 이름을 명명해야 할 경우가 있을 수 있기 때문입니다. 또한, 데이터의 논리적인 상태를 명시하는 ‘Apps Notation’에도 이 방식이 지금도 간간이 쓰이고 있습니다.
결론은, ‘헝가리안 표기법은 필요한 경우 사용해도 좋으나 가급적이면 피하는 것이 좋다’고 할 수 있겠습니다.