혹시 우리는 규칙에 안심하는가

규칙이란 무엇일까?

규칙은 사전적 정의로 지키도록 정해 놓은 질서나 원칙. 방칙(方則) 라고 한다. 규칙은 사전적 정의로만 보아도 절대적이지 않다. 하지만 우리는 이 규칙이라는 것을 절대적으로 보는 경향이 있다. 규칙은 절대적이지 않다.

규칙과 법률의 차이

내가 A라는 프로토콜은 개발했고 이 A라는 프로토콜은 표준이 되었다. 프로토콜은 규칙이다.

프로토콜

프로토콜의 사전적 정의는 ‘규약’이다. A라는 프로토콜이 어떤 훅의 작성 방식을 무조건 DI 없이 작성해야하며 훅 내부에서 처리를 해야 한다 라고 했을때, 이 A라는 프로토콜은 아무리 정규화가 되고, 표준이 되어도 결국 법률적인 강제성을 지니지 않는다.

법률

B라는 법률이 어떤 훅의 작성 방식을 무조건 DI 없이 작성해야하며 훅 내부에서 처리를 해야 한다 라고 했을때, 이 B를 따르는 메쏘드는는 정규화가 되든, 표준이 되지 않든 무조건적인 강제성을 가지게 될 것이다.

규칙과 법률의 차이

• A를 어긴다 = 피드백을 통해 다음에 잘 하면 된다.
• B를 어긴다 = 허용 되지 않는다.

시민이라는 범주에 있고 그 속에 속한 우리 개발자는 A에 대해서 훨씬 더 많은 책임을 갖고 있다고 생각한다. 당연히 법은 지켜야하지만, 법을 지키는건 모든 시민의 의무이기 때문이다.

규칙은 언제든 안티패턴이 될 수 있다

규칙이나 프로토콜을 절대적인 기준으로 여길 때 가장 위험한 순간은, 그 규칙이 의도했던 맥락을 잃어버렸을 때다. 많은 규칙은 특정 시대의 기술 수준이나 한계를 해결하기 위해 만들어졌지만, 환경이 바뀌고 난 뒤에도 사람들이 ‘그냥 원래 그렇게 하니까’라는 이유로 계속 고수할 때 오히려 안티패턴이 되어버린다.

이처럼, 규칙은 언제든 시대의 산물일 뿐이며, 그 규칙이 만들어졌던 이유가 사라지면 더 이상 지켜야 할 필연성도 없다. 그러나 많은 사람들은 규칙을 마치 법률처럼 받아들이고, “왜 이 규칙이 생겼는가?”라는 질문을 멈추는 순간 규칙은 목적을 잃고 장애물로 변한다.

프로토콜에 대한 생각

내가 이 멘탈 모델 하나만으로 프로토콜을 구성할 수 없다고 생각한 이유는 Semantic Versioning이다.

react-hook-form

react-hook-form은 최근에 typescript 4에서 typescript 5 버전으로 업그레이드를 진행했다. Semantic Versioning에 따르면, react-hook-form 자체에서 어떠한 변화가 없다면 캐럿(^)으로도 업데이트가 가능하다. 하지만 우리 팀이 react-hook-form을 사용할 때, TypeScript 4 버전이 필수라고 한다면, 이는 BC라고 볼 수 있지 않은가? 이 프로젝트 하나만의 규칙으로 생각해서 Semantic Versioning을 따르기엔 다른 모든 것을 고려하기 힘든 모델이 아닌가? 라이브러리 입장에선 기능적 변화가 없기에 Minor Update로 생각할 수 있지만, 이 라이브러리를 사용하는 우리 팀 입장에선 Breaking Change이다.

*-lock 파일

당연히 lock 파일을 지우고 새로 받아오는 것은 정말 안티패턴이다. 하지만 lock 파일에 캐럿(^)으로 되어 있고, 만약 그 마이너 패치가 내 프로젝트에서 BC라면?

^4.9.0로 돼있다면 가장 최신 버전인 4.9.8버전으로 업데이트 할 수도 있는 상황인데, 이게 우리 팀에게 BC일수도 있다.

사실 나는 human issue로 업데이트 하거나, 무조건 이걸 따라야 한다거나 하는걸 선호하지 않는다.

사람의 실수를 어떻게 체크하고, 어떻게 따라갈 수 있는가에 대해서는 모든 사람들이 공감할 것이다.

• 우리 팀은 왜 내 로컬에서는 되는데 CI에선 안되는가에 대해 정말 많은 시간이 들 수도 있다.
• 똑같이 우리 팀원은 되는데, 왜 나만 안되지에 빠져 몇 시간을 허둥댈 수 있다.

이게 과연 효율적인 규칙인가? 이 규칙이 항상 적용될 수 있는가에 대해서 고민해볼 필요가 있다.

프로토콜을 맹신하지 말자

프로토콜은 단순히 우리 개발자들이 우리끼리 편하게 개발할 수 있도록 서로 약속해둔 ‘문화’이다. 이 ‘문화’에 대해선 각 개발자들끼리 서로 다를 수밖에 없다. 왜냐하면 이 ‘문화’는 각자의 생활과 살아온 사회를 반영하기 때문이다.

• 내가 A가 당연한 사회에서 살아왔고
• 누군가는 B에서 살아오는 것이 당연했다면

이 프로토콜은 당연히 실패한다. 내가 생각하는 것을 누구나 다 알거라고 생각하면 안된다.

결론

사실 법률적인 강제성을 가진 사례와 반대로 이런 법률은 많지 않다. 그만큼 우리 개발자들은 자율성이 높다고 생각하며 그만큼 책임감을 가져아한다고 생각한다. 우리는 이번 예시들을 통해 모든 것을 의심해볼 수 있는 능력을 얻을 수 있다.

• 규칙이나 프로토콜을 절대적 기준으로 맹신하지 않고,
• 팀과 프로젝트 상황에 따라 규칙의 의미를 판단하며,
• Semantic Versioning이나 캐럿(^) 범위 업데이트가 반드시 안전하다고 생각하지 않는다.

결국 중요한 것은 규칙 자체가 아니라, 상황과 맥락을 고려하여 유연하게 판단할 수 있는 역량이다. 이런 시각을 갖는다면, 단순히 “규칙을 지킨다”를 넘어, 실제 문제 상황에서 빠르고 정확하게 대응할 수 있는 힘이 생긴다.