🙂 서론
개발자로 일을 하면 항상 수많은 trade off 속에서 선택의 기로에 선다. 이 선택의 기로마다 어떤 근거에 의해 한쪽을 선택해야 하는데, 일을 하면서 아~그렇구나 원래 쓰는구나 그렇게 바뀌었구나 하고 아무 생각 없이 넘어가버리면 나중에 비슷하지만 다른 선택을 해야할 때 현재의 상황에 적절하지 않게 결정해버리는 일이 발생한다. 사례를 한번 살펴보자.
🔍 사례 - Header namming convention
사내에서 유통되는 api에서 custom header의 이름은 모두 x- prefix가 붙어있었다. 관용적으로 비표준 헤더에 대해 x-가 붙어있었던 것 같다.
👀 TMI:
x-prefix들은 "eXperimental" 또는 "eXtension"의 약자이다.
왜 굳이 x-를 붙여서 사용할까? 하고 좀 찾아보니 mdn에 다음과 같이 나와있었다.
Custom proprietary headers have historically been used with an X- prefix, but this convention was deprecated in June 2012
출처: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers
즉, 2012년 이후로 header에 x-를 안붙이는것으로 표준이 바뀌었다는 것이다. 표준이 바뀐거니까 단편적으로 생각했을땐
"오! 그러면 굳이 x-를 안붙여도 되겠네! 그럼 이제 사용할 헤더에는 붙이지 말아야겠다"
라고 단순하게 생각할 수 있다. 그러나 이 표준이 바뀐 🌟이유🌟를 좀 더 유심히 읽어보자.
because of the inconveniences it caused when nonstandard fields became standard in RFC 6648
출처: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers
즉, x-가 붙어있던 비표준 헤더가 표준 헤더가 되는 경우 x-를 떼고 표준화 하거나 둘다 지원하던가 하는 등의 불편함을 야기하기 때문에 해당 컨벤션을 없앤것이다!
🤷 어쨌든 그냥 표준을 따르면 되지 않을까?
그럴수도 있지만 필자는 아니라고 생각한다. 현재 사내에서 사용하고 있는 사례를 살펴보면
1. 사내에서 쓰는 비표준 헤더가 덜컥 표준헤더로 바뀔일이 전혀 없다.
2. 오히려 x-로 인해 비표준 헤더라는것이 명확하게 표기되기 때문에 개발할 때 인식하기 편하다.
💡 즉, 무지성으로 표준을 따르기 보다는 표준으로 결정된 🌟이유🌟를 따져보고, 현재 나의 상황에 맞게 적용하는 것이 중요하다.
🤟 결론
어떤 일을 하던지, 어떤 현상이 일어나던지, 어떤 정책이 정해지던지 다 그렇게 될만한 이유가 있다. 심지어 코드를 유지보수 할 때도 그 코드가 오래되고 이상하더라도 이유가 있고 그때는 그게 최선이었다. 이유를 다른말로 하면 본질이다. 본질을 파악하고 나에게 맞게 커스텀하여 적용하자.
