'이 규칙 왜 있는 거지?' — 무시하기 전에 던져야 할 한 가지 질문

'이 규칙 왜 있는 거지?' — 무시하기 전에 던져야 할 한 가지 질문

개발하다 보면 이런 순간을 자주 만나요. API가 '이렇게 쓰면 안 된다'고 막아두거나, 예전 동료가 짜놓은 코드에 누가 봐도 쓸데없어 보이는 검증 로직이 들어 있거나, 운영체제가 '이 작업은 허용 안 한다'며 거부할 때요. 이럴 때 머릿속엔 자연스럽게 이런 생각이 떠오르죠. '에이, 그냥 우회하면 되잖아?'

마이크로소프트의 베테랑 엔지니어 레이먼드 첸이 오래 운영해온 블로그 'The Old New Thing'에서 바로 이 지점을 짚었어요. 메시지는 단순해요. 어떤 규칙을 깨거나 우회하려고 하기 전에, 그게 왜 거기 있는지부터 이해하라는 거예요.

체스터턴의 울타리 이야기

이걸 설명할 때 자주 나오는 비유가 '체스터턴의 울타리'인데요. 이게 뭐냐면, 들판 한가운데 울타리가 하나 서 있어요. 어떤 사람이 와서 '이거 왜 여기 있어? 쓸모없어 보이는데 치워버리자'고 해요. 그러자 현명한 사람이 답해요. '네가 이 울타리가 왜 여기 있는지 모른다면, 나는 네가 그걸 치우게 둘 수 없어. 가서 이유를 알아봐. 알고 나서도 필요 없다 싶으면 그때 치워.'

소프트웨어도 똑같아요. 그 검증 로직은 3년 전 어떤 고객사에서 터진 끔찍한 버그를 막으려고 누군가 밤새워 넣은 것일 수 있거든요. 그 API 제약은 우리 눈엔 안 보이는 메모리 정렬 문제나 보안 구멍을 조용히 막고 있을 수도 있고요.

우회가 위험한 진짜 이유

레이먼드 첸이 평생 다뤄온 주제가 바로 윈도우 API의 하위 호환성인데요. 사람들이 '문서엔 없지만 이렇게 하면 동작하더라'며 꼼수를 쓰면, 마이크로소프트는 다음 버전에서 그 꼼수가 안 깨지게 하려고 별별 고생을 다 해요. 왜냐면 규칙을 우회한 코드는 그 규칙이 지키던 전제가 바뀌는 순간, 아주 찾기 힘든 방식으로 터지거든요.

예를 들어볼게요. 어떤 함수가 '이 값은 절대 null이면 안 된다'고 막아뒀다고 해요. 귀찮아서 검증을 우회하고 null을 슬쩍 넣었더니 신기하게 잘 돌아가요. 그런데 그건 '지금 이 버전'에서 우연히 안 터지는 것뿐이에요. 라이브러리가 업데이트되거나 입력 데이터가 조금만 달라지면 전혀 엉뚱한 곳에서 죽고, 그때는 원인을 찾느라 며칠을 날리게 되죠. 규칙은 보통 '미래의 나'를 지키려고 있는 거예요.

그래도 규칙이 틀렸을 때는?

물론 모든 규칙이 옳은 건 아니에요. 정말 시대에 뒤처졌거나 처음부터 잘못 만든 규칙도 있죠. 핵심은 '규칙을 절대 깨지 마라'가 아니라 이유를 이해한 다음에 깨라예요. 이유를 알고 나면 둘 중 하나가 돼요. '아, 이래서 있었구나' 하고 그대로 두거나, '이 이유는 이제 유효하지 않으니 안전하게 치워도 되겠다'고 근거를 갖고 판단하거나. 어느 쪽이든 무작정 우회하는 것보다 훨씬 안전하죠.

한국 개발자에게

레거시 코드 많이들 만지시잖아요. '이거 왜 있는지 아무도 모름'인 채로 지웠다가 운영 장애 내본 경험, 한 번쯤 있으실 거예요. git blame으로 누가 언제 왜 넣었는지 추적하고, 관련 이슈와 커밋 메시지를 찾아보는 습관이 결국 이 이야기의 실천판이에요. 코드 리뷰에서 '이거 왜 이렇게 하셨어요?'라고 묻는 것도 마찬가지고요. 답이 안 나오면 함부로 손대지 않는 게 오히려 고수의 자세예요.

마무리

핵심은 한 줄이에요. 모르고 깨면 사고, 알고 깨면 결정. 여러분 코드베이스엔 '왜 있는지 모르지만 일단 우회해둔' 부분이 있나요? 그게 사실은 무엇을 막고 있었을지 한번 들여다보는 건 어떨까요?