blah/Mini-Journal

컴파일러야 부탁해

이고란. 2025. 5. 31. 23:24

C++을 공부하고 있다. 그놈의 객체지향이 뭔지 좀 느껴보려고.

 

Django를 하면서 상속은 받아봤지만, JavaScript에서 prototype을 대충 써봤지만, Java를 깔짝대면서 맛은 보긴 했지만.

 

역시 모자라다. Java, C#, TypeScript… 여러 선택지가 있지만 C++을 골랐다. 이유는 내가 지금 하고 있는 게 C라서. 앞으로 어떤 커리어 패스를 밟아나가야 할지 감이 없으니 좀 더 진입장벽이 낮은 걸 하기로 했다. C도 더 이해할 겸해서.

 

보면서 감탄했던 지점이 한두 가지가 아니다. 초창기 C언어에서 고통 받았던 지점에 대한 해소와 새로운 트렌드의 도입을 어떻게든 해냈달까. 제일 재밌었던 건 참조형과 캐스팅이었다. 런타임의 속도는 늦추지 않으면서 보다 휴먼 에러를 줄여줄 수 있는 디자인. zero-cost abstraction이라는 말이 뭔지 알 거 같기도 하고 아닌 거 같기도 하고.

 

그러면서 Rust에 대한 관심이 생겼다. Rust에 대한 내 인상은 '더럽게 깐깐한 스펙을 통해 죽여주는 성능을 달성한 언어'인데, 지금은 아니고 한… 어… 몇 년 후에는 맛보지 않을까? 아님 말고ㅎ; 하여간 다른 언어를 들여다보아야 얻는 관점이 있다. 일정 이상 최적화가 됐다면 거의 모든 것은 트레이드오프이기 때문에. 해당 언어가 무엇을 희생하고 무엇을 얻었는지, 어째서 그런 선택을 했는지 이해할 수 있다면 자신의 언어를 다시 마주했을 때 새로운 부분을 느끼게 될 것이다. 일종의 소격 효과인 셈.


나는 아직 컴파일러-운영체제-하드웨어 간의 책임에 대해 잘 모르는데, 예를 들어 함수의 반환값을 명시적으로 지정하지 않은 분기로 진입해서 함수가 종료될 경우 어떤 환경에서는 0을 반환하는가 하면 어떤 환경에서는 쓰레기값을 반환한다. 그런데 그 반환값을 가지고 true-false를 평가해버리면 동작이 달라지게 된다. 처음에는 다른 운영체제에서 발생했기에 '아 운영체제 문젠가 보다' 싶었지만 생각해보면 컴파일러가 결정할 문제였던 거 같다. 아마 운영체제 별로 지원하는 컴파일러 종류나 버전이 달랐던 게 아닐까.

그런데 또 Windows에서는 SEH(Structured Exception Handling)이란 게 있는데, division by zero에 대한 예외 처리를 운영체제 레벨에서 한다는 거 같다. 아마 CPU에서 레지스터에 들어간 값을 가지고 나누기 연산을 할 때 뭔가 감지를 해서 운영체제가 잡아낼 거 같은데 잘은 모르겠고. 진정한 프로그래밍의 고수라면 이런 지점을 알아야겠지만 나는 가짜 프로그래머라서 별다른 관심이 가지 않는다.

 

나는 Python으로 프로그래밍 공부를 시작했는데, 물론 요즘 Python도 대강의 "컴파일 에러"를 잡아주지만, C언어만큼 깐깐하지는 않았던 거 같다. 나는 외부 라이브러리를 많이 안 써봐서 흔히 말하는 "생태계"를 체감한 적이 없다. 뭔가 프로그래밍으로 다른 분야 쌩구현을 해볼 일도 없었다. 그래서인지 이렇게 깐깐한 strong type이나 컴파일러가 존재하는 언어가 마음에 든다. 생산성은 모르겠고, 멍청한 내게 계속해서 정보를 알려줄 존재가 필요한 거지.

 

컴파일러야 앞으로도 잘 부탁해!