• 개요

‘오버 엔지니어링’은 개발의 본질을 관통하는 단어다.

보통 지나치게, 과하게 코드를 구조화하고 효율화하는 것을 의미한다. 성숙하지 못한 개발자는 코딩을 업무에 활용하기보다 정해진 코딩으로 개발한다.

개발이라는 과정은 특수한 목적을 위한 시스템을 설계하는데에 있다. 지금의 개발자들이 비록 코딩에 스페셜리스트일지는 몰라도, 맹목적인 시스템 설계에 얽매여있는 것 같다.

사실 코딩이라는건 업무의 자동화를 돕는 도구여야 마땅하다. 때문에 개발이건 기획이건 코딩을 할 수 있다면 자신의 업무를 자동화할 수 있기 때문에 강력한 도구가 된다. 그런데 개발자들은 보통 그들의 주 무기로 코딩을 활용하기 때문에, 조금 더 깊은 코딩의 지식을 가진다. 그러다보니 코딩의 디테일에 얽매이기 쉽다. 개발의 바이블이라고 하는 것들에 얽매이기 쉽다. 지나치게 오버 엔지니어링 하게 되는 것은 무언가의 최종형태를 보고 배우기 때문이다.

그건 리스크가 크다. 최종형태는 사실 수직적인 지향점이 아니다. 계단식 학습방법은 접근은 쉽게 하지만 자칫 어떤 기술이 최종적인 목적지처럼 보이게 만든다. 하지만 사회는 보다 복잡해서 각각의 형태들은 비교불가능한 서로의 극단일 확률이 높다.

구체적으로 이게 무슨이야기냐면, 지속하는 프로덕트 개발자들은 종종 유지보수가 어려운 SI 직종의 코드를 나쁘게 평가하곤 한다. 그리고 보통의 경우 일을 대행하는 것보다 자신의 일을 하는 쪽이 더 나은 처우를 받기 때문에, 프로덕트 개발자쪽이 더 나은 개발자들처럼 보이는 경우도 있다. 그런 탓인지 SI의 유지보수가 어려운 코드는 질나쁜 코드로 곡해된다.

사실 유지보수성은 기회비용적인 측면으로 바라보아야한다. 프로덕트 개발자들의 업무는 ‘유지보수’ 측면이 강하다. 프로덕트의 핵심 컨셉은 이미 오래전에 구현되었고, 앞으로 하는 일들은 방향성을 유지하며 새로운 기능을 추가/유지보수 하는 것이다. 또 개입되어 있는 사람들은 어떠한가, SI 프로젝트에 비해 비교가 불가능한 수준으로 많다. 그만큼 레거시를 쌓아왔고, 그 레거시를 좋아하는 사람, 싫어하는 사람 등 다양한 관계가 얽혀있다. 심지어 프로덕트를 만드는 사람들 뿐 아니라 그 소비자 또한 이해관계자로서 고려되어야 하기 때문에, 특정한 약속과 규칙없이는 오래도록 프로덕트를 유지해나갈 수 없다.

그런데 SI는 어떠한가, 이해관계자의 수는 잠재군을 제외하면 10명이 안되는 경우도 허다하다. 그리고 시간과 돈은 리소스이기 때문에, 남들보다 빠르고 효율적으로(적은 가격으로) 일을 할 수 있다면 그것보다 더 좋은 경쟁력은 없다.(업무의 질이 비슷하다는 전제하에) 만약 유지보수까지 가능한 개발을 한다면 금상첨화이겠지만, 말 그대로 금 위의 한송이 꽃에 지나치지 않는다. 우리가 목적으로 삼아야하는 금은 ‘속도와 효율성’에 있다는 것이다. 한 마디로, 짧은 시간과 적은 비용으로 목적에 부합하는 ‘작동하는 코드’를 만들어오는 것, 그게 목표라는 뜻이다.

유지보수성은 이렇게 주로 개발 효율성과 트레이드오프 관계에 있는 것이다. 규칙에 맞는 코드와 쉬운 코드의 필요성이 서로 다른 것이다. 개발자는 코딩을 그 무기로 삼아서 문제에 맞게 활용할 수 있는 사람이어야지, 코딩 진리의 구도자가되어서는 안된다.

상황과 맥락에 맞는 기술활용이 그대를 더 가치있는 개발자로 만들것이다.