날아다니는 스파게티 코드에 대하여

최근 어떤 분에게 아래와 같은 흥미로운 이야기를 들었다.

 

서비스의 성공과 같은 후행 지표는 운적인 요소가 많이 작용하는 지표이기 때문에 선행지표를 최대한 좋게 하거나 시도 횟수를 높이는 것이 조금 더 유효한 액션이다. 타석에 여러번 들어서야 홈런칠 확률이 높아진다는 뜻이다. 이러한 관점에서 유명한 유니콘 스타트업은 빠른 실험을 위해 속도를 내야한다면 스파게티 코드를 작성한다.

 

이분의 말은 오버엔지니어링 하지 않는게 중요하다 라는 뜻에서 이런 말을 하신 것 같다.

하지만 순간 엥? 뇌정지가 왔다. 어느정도 스파게티 코드일까..?

 

하지만 이 얘기를 듣고 여러 생각을 했다. 먼저 스파게티 코드로 작성하면 빠르게 작업할 수 있나? 라는 생각이 들었다.

작업은 빠르겠지만 프로덕트 전체 생애에서 이것이 효율적인지는 생각해봐야하는 문제다.

마치 전기차가 자동차로 한정했을 때는 친환경적이지만 LTA 관점에서는 다른 문제를 갖고 있는 것처럼.

 

언제나 작업은 완성도와 걸린 시간으로 평가해야한다.. 오히려 스파게티 코드로 인한 버그 + 스파게티 코드를 고치면서 발생하는 비효율(변수명 변경)  + QA 수정 사항 이런 것들을 다 합치면 시간이 1~2시간 더 걸린다고 해도 설계를 조금이라도 해서 코드를 작성하는게 이득 아닌가?

 

생각해보니 저 명제에 영향을 주는 요인이 너무 많다.

개발자의 능력, 만약 천재 개발자라면 스파게티로 작성해도 버그 하나 없이 동작 하겠지?

작업의 양이나 난이도에 따라 또 달라지는데 작업량이 적으면 설계라는게 어쩌면 필요하지 않을 수도..?

스파게티화의 정도, 어느정도의 스파게티 코드인가?

참 어려운 문제다..

그냥 장난으로 던져진 돌이였나보다.. 그 돌에 맞아 생각이 많아졌다.

 

날아다니는 스파게티 코드는 생각하지 않기로 했다.

그냥 오버엔지니어링만 조심해야겠다.