쓰레기 같은 코드는 개발자의 숙명.

우리는 대부분 쓰레기 같은 코드를 만든다.

품질을 위한 도전과 사용자의 요구, 비즈니스 모델의 변화에 따라서 만들어지는 코드의 운명은 대부분 쓰레기 코드로써 운영을 마치는 경우가 많다.

필자도 대부분의 코드는 쓰레기 코드가 된 경우가 많았고, 서비스가 동작중이라고 하지만... 조금만 요구조건이나 비즈니스의 상황이 바뀌게 되면 해당 코드는 쓰레기가 되는 경우가 대부분이다.

개발자라고 한다면, 자신의 코드와 서비스에 대해서 애정을 가지고 철학을 부여해야 하면서, 생명력을 부여해야 하지만, 대부분의 개발환경은 쓰레기를 만들 수밖에 없는 상황으로 진행된다.

물론... 개발자가 정신 차리고, 기획자나 경영진의 요구를 적당하게 무마하면서 서비스의 호흡을 조정하면서 쓰레기 같은 코드가 아니라, 의미 있는 서비스와 꽤 훌륭하게 만들어진 코드를 만들 수 있는 기회들이 있다.

하지만... 정말 쓰레기 같은 코드는...

해당 서비스나 코드가 그 생태계에 어울리지 않은 배경 디자인과 구조적인 결함으로 시작되었다면, 빠르게 쓰레기 코드에 대해서 정제를 해야 한다. 특히나, 특정 비즈니스 환경에서는 동작하지 말아야 할 구조들이 생각보다 많다.

전송되지 말아야 할 정보들이 전송되거나, 아무리 보안 정책과 기술을 적용했다고 하더라도, 그런 방식으로 동작하면 안 되는 경우가 있다. 안타깝지만... 아마추어라면 '일단 서비스'가 동작하고 '사용자'가 사용하면 되는 것 아니냐고 이야기할 수 있다.

하지만, 실 비즈니스의 세계에서 '보안규정'이나 '동작 규칙'을 어기게 된다면, 해당 코드로 만들어진 서비스들은 위법한 행위를 하는 것이고, 이와 관련된 내부 구조를 인증이나 검토하는 과정에서 그동안 비즈니스를 위해서 준비된 행위들 자체가 부정되고, 비즈니스에 엄청난 타격을 주는 것을 모르고 진행하는 경우가 있다.

기획자나 개발자가 관련 규정과 법제도, 데이터의 생성 규칙과 운영규칙을 잘 모르기 때문에 그렇게 만들었다고 하지만, 실제 비즈니스를 운영하는 사람의 입장에서는 이러한 태도는 매우 어이없는 상황이 만들어진다.

더군다나, 관련 규정이나 환경에 대한 스터디도 제대로 하지 않고 진행된 쓰레기는 코드 품질의 문제와 비즈니스 품질의 문제에서 전혀 품질 컨트롤이 안되어진 것에 대해서 그 누구도 책임지지 않게 되며, 해당 소프트웨어는 그냥 해당 생태계에서 부정적인 판단으로 서비스를 중단하게 된다.

짧게 시작된 가능성을 보고, 사용자들에게 서비스가 제공되는 구성들은 실 세계에서는 '실험'적인 상황으로 동작되면 안 된다.

쓰레기 같은 코드는 초기에는 분명 만들어진다.

필요한 요건, 구조, 품질 등을 파악했다면, 쓰레기 코드를 선언하고. 버전업을 하고, 사용자에게 정말 사용할 수 있는 코드로 다시 만들어져야 한다.

프로토타입은 당연 쓰레기 코드이다.

그 쓰레기 코드로 테스트 이외의 실 서비스의 규정과 법규를 무시하고 동작하게 되는 상황을 만난다면 당신은 어떻게 할 것인가?

비즈니스를 책임지는 사람은 영속적인 서비스를 구성해야 하며, 그 생태계에서 사용하는 사람들은 서비스를 신뢰할 수 있어야 한다. 

물론, 초기 상황을 수면 아래로 잠기게 하고, 필요한 형태까지 진행하다가 큰 문제를 만드는 것은 개발자의 책임이 아니라 비즈니스를 책임지는 조직에서만 책임을 가지면 된다고 반문할 수 있다.

하지만, 단언컨대... 개발자는 서비스의 영속성을 가지기 위해서 책임을 다해야 한다. 이 부분은 그 누구에게도 타협할 수 있는 서비스의 책임이라고 생각한다.