코드 공통화, 정말 필요한가? – 유지보수의 함정과 리스크

개발자라면 한 번쯤은 들어봤을 겁니다. "중복을 없애고, 상수와 기능을 공통화하자!" 이 말은 듣기엔 그럴듯하고, 코드의 깔끔함과 효율성을 추구하는 것처럼 보입니다. 하지만 정말 모든 경우에 이런 공통화가 유리할까요? 사실 공통화된 코드가 때로는 눈에 보이지 않는 함정을 만들어, 유지보수와 수정 작업에서 예상치 못한 리스크를 초래할 수 있습니다.

어쩌면 우리는 개발을 위한 개발에 빠져, 정작 중요한 목적을 잊고 있을지도 모릅니다. 제품을 위한 개발, 사용자와 운영을 위한 개발이 아닌, 코드 자체의 완벽함을 추구하는 방향으로 나아가는 것이죠. 이 칼럼에서는 공통화된 상수와 기능이 어떻게 사이드 이펙트를 유발하고, 분리된 코드가 어떻게 리스크를 줄여줄 수 있는지 이야기해보려고 합니다.

1. 공통화된 기능과 상수의 리스크

상수와 기능을 공통화하는 것은 코드의 중복을 줄이고 일관성을 유지하는 방법으로 자주 권장됩니다. 하지만 이런 공통화가 항상 최선의 선택은 아닙니다. 공통화된 상수나 기능은 수정이 발생할 때, 그 변경 사항이 의도치 않게 여러 곳에 영향을 미칠 수 있습니다.

공통화된 코드가 널리 퍼져 있을수록 수정의 영향 범위가 넓어지고, 사이드 이펙트는 기하급수적으로 늘어날 수밖에 없습니다. 반면에, 분리된 코드가 더 안전합니다. 코드의 변화가 필요한 곳에만 국한되기 때문에, 리스크가 한정되고 관리가 훨씬 수월해집니다.

2. 중요한 상수와 로직, 그 공통화의 기준

물론, 변하지 않을만한 상수나 로직을 공통화하는 것은 좋은 접근입니다. 예를 들어, 국가 코드나 통화 단위처럼 변동성이 거의 없는 데이터는 공통화하면 중복을 줄이고 관리 효율을 높일 수 있습니다. 하지만 이러한 상수는 이미 라이브러리에서 제공되거나 표준으로 정의된 경우가 많습니다. 따라서 이러한 경우에는 자체적으로 공통화를 시도하기보다는, 검증된 라이브러리를 사용하는 것이 훨씬 더 나은 선택입니다.

라이브러리에서 제공하는 표준 로직을 사용하는 것은 팀의 유지보수 부담을 줄이고, 코드의 신뢰성을 높이는 데 큰 도움이 됩니다. 변하지 않을 상수를 공통화하는 건 유의미하지만, 대부분의 경우 이미 정의되어 있는 것을 사용하는 것이 현실적이고 효율적인 선택입니다.

3. 개발을 위한 개발에서 벗어나라

코드를 공통화하는 주된 이유 중 하나는 "더 나은 관리"를 위한 것입니다. 하지만 여기서 한 가지 중요한 질문을 던져야 합니다. 우리는 누구를 위해 개발하고 있는가? 우리의 최종 목표는 사람이 사용하는 제품을 만드는 것입니다. 개발의 과정에서 운영과 사용자 경험을 고려하지 않는다면, 결국 우리는 개발을 위한 개발을 하고 있을지도 모릅니다.

운영을 위한 개발이란, 실질적인 사용자 경험과 운영의 안정성을 중심으로 코드를 설계하고 유지보수하는 것을 의미합니다. 불필요한 추상화와 공통화는 오히려 운영에 부정적인 영향을 미칠 수 있습니다. 개발 과정에서 끊임없이 스스로에게 묻는 것이 중요합니다: "이 방식이 실제 운영에 얼마나 도움이 될 것인가?"

4. 리스크 관리의 중요성

코드 관리에서 가장 중요한 요소 중 하나는 리스크를 최소화하는 것입니다. 공통화된 상수나 기능은 수정 시 전체 코드베이스에 사이드 이펙트를 유발할 수 있지만, 필요한 부분에 적절히 분리된 코드는 리스크가 제한적입니다.

리스크 관점에서, 각 모듈이 독립적일수록 변경에 대한 영향이 한정되고 예측 가능한 범위 안에서 통제될 수 있습니다. 따라서, 코드의 공통화보다는 필요한 곳에만 적절히 분리하는 것이 리스크를 줄이고 안정성을 높이는 방법입니다.

5. 개발자의 역할: 결과를 기준으로 판단하라

애초에 우리가 새로운 개발을 기획할 때, 개발자가 코드를 보고 기획하는 것이 아니라 기획자가 결과물을 보고 개선점을 찾습니다. 따라서 "여기만 고치면 여기만 동작한다"는 단순한 논리는 비판의 대상이 아닙니다. 개발자는 변경된 코드가 동작하는 모든 부분을 체크하고, 그 모든 부분에서 원하는 결과를 내도록 책임을 져야 합니다.

코드의 변화가 발생했을 때, 그 변경이 시스템 전체에 어떻게 영향을 미치는지 꼼꼼히 확인하는 것이 개발자의 역할입니다. 기획자가 보는 것은 코드가 아니라 결과물이기 때문에, 개발자는 그 결과가 문제없이 동작하도록 전체적인 검토와 테스트를 수행해야 합니다.

결론

개발은 궁극적으로 사람이 사용하는 제품을 만들기 위한 과정입니다. 그럼에도 불구하고 종종 "개발을 위한 개발"로 변질될 때가 있습니다. 모든 코드를 하나로 엮어 공통화하려는 시도는 유지보수성을 높이려는 의도로 시작되지만, 실제로는 사이드 이펙트를 초래하고 리스크를 증가시킬 수 있습니다.

변하지 않을 로직이나 상수는 공통화하는 것이 유리할 수 있지만, 대부분의 경우 그것들은 이미 라이브러리로 제공되거나 표준화되어 있는 것들이 많습니다. 직접 공통화를 시도하기보다는, 이를 활용하는 것이 더 나은 선택일 수 있습니다.

그리고 개발의 역할은 단순히 "여기만 고치면 여기만 동작한다"는 방식으로 비판하는 것이 아니라, 변경된 부분이 동작하는 모든 곳을 꼼꼼히 확인하고 필요한 모든 부분에서 적절하게 동작하는지 확인하는 것입니다. 기획자가 결과물을 보고 개선점을 찾는다는 사실을 고려하면, 개발자는 단순히 코드 변경에 그치는 것이 아니라, 결과물이 전반적으로 어떻게 영향을 받는지를 충분히 검토하고 테스트하는 책임을 져야 합니다.

개발자는 전체적인 시스템의 동작을 책임지고, 모든 영향을 받는 부분을 체크하고 개발하는 것이 중요합니다. 이는 운영의 안정성을 확보하고, 실질적인 결과물을 제공하는 데 있어 필수적인 과정입니다. 결론적으로, 우리는 개발 자체를 위한 것이 아닌, 운영과 사용자를 위한 개발을 해야 하며, 이 과정에서 개발자의 역할은 단순히 코드 변경을 넘어서 전체 시스템을 꼼꼼히 관리하는 데 있습니다.