Second System Syndrome (뭐 이따위로 만들었어?)

프레드 브룩스가 얘기한 "Second System Syndrome"은 주변에서 흔하게 접할 수 있습니다.

현재의 개발자들이 과거에 선배들이 만들어 놓은 First System의 문제 요소를 지적하며 Second System을 만들어야 한다고 주장합니다. 이러한 현상은 정말로 지겹게 봐왔습니다. 즉, 선배들이 만든 시스템을 "뭐 이따위로 만들었어? "하고 생각하면서 Second System을 만들어야 하는 온갖 이유를 대면서 경영자를 현혹시킵니다.

이렇게 주장하는 개발자들은 어리고 경험도 부족하기 때문에 First System이 얼마나 어려운 문제를 다루고 있었는지 제대로 이해하지 못합니다. 또 자신들이 문제로 지적하고 있는 요소들 외에 얼마나 많은 복잡한 이슈들을 First System에서 해결하고 있는지 알지 못합니다. 또한 과거의 문제를 근사하게 해결했다는 성과를 뽑내고 싶은 욕구도 있습니다.

이렇게 만들어진 Second System은 대부분의 경우 First System을 얕잡아 보기 때문에 예상치 못한 이슈들과 많이 부딪히게 되고 예상된 일정을 지키지 못하게 됩니다. 또 이미 First System에서 해결했던 수많은 문제들이 Second System에서는 버그로 나타나는 경우가 허다합니다.

v1.0이 허접하고 문제도 많다고, 기능을 잔뜩 붙여서 v2.0을 만들었지만, 고객들이 기능은 적어도 문제가 적은 v1.0을 다시 찾는 일을 보는 것은 그리 어렵지 않습니다. 비록 v2.0이 예상된 일정을 훨씬 넘겨서 어렵게 출시가 됐는데도 말입니다.

Third System Syndrome이란 현상이 없는 이유는 Second System Syndrome의 쓴맛을 본 경영자가 세번째는 허용을 하지 않기 때문이겠죠.

이렇게 Second System Syndrome이 일어나는 결정적인 이유는 First System을 만들어 놓은 개발자들이 달랑 소스코드만 남겨 놓았기 때문인 경우가 대부분입니다. Second System을 주장하는 개발자들은 대부분이 이 First System을 유지보수하는 하는 개발자들이고 지겹도록 문제점만을 봐왔기 때문입니다. 그러면서도 본인들도 Second System을 만들면서 달랑 소스코드와 별 쓸모 없는 문서 몇 개 만들어 놓는 것이 고작입니다.

애초에 정상적인 체계를 갖추고 개발에 모든 정보가 지식화가 되어서 동료들간에 또 후배에게 전달이 되어 있었다면 이러한 First System의 무조건적인 비판은 일어나지 않을 겁니다.

만약에 현재 여러분이 문제가 많은 First System을 유지보수 하느라고 고생을 하고 있고 이를 만든 선배들은 이미 퇴사를 하였다면, 무조건적으로 Second System을 주장하지 말고 냉정한 판단을 해야 합니다. Second System이 실패하는 일은 너무나 흔하니까요. First System의 기반을 완전히 무시하는 것은 그동안 개발팀이 쌓아온 재산을 무시하는 것과 다름이 없습니다. 차라리 First System의 Refactoring이나 Rearchitecturing을 통해서 문제 해결을 시도하면서 좀더 지식과 경험을 쌓고, 

"자신의 First System을 만들 때를 대비해서 내공을 쌓아가세요."