KUR Creative


오버 띵킹의 함정을 조심하라

오버 엔지니어링을 조심하라

프로그래밍에서 오버 엔지니어링은 필요 없는데 과도한 설계를 하여 과도한 코드를 짜는 경우를 의미한다.
그런데 오버 엔지니어링은 일단 돌아는 간다. 그것보다 더 나쁜 것이 있었으니
이름하야 오버-띵킹 이다.
resource/thinking.png

내가 자주 빠지는 함정 중에 하나를 드디어 파악했다.

프로그래밍의 단계

프로그래밍에는 단계가 있다.

  1. 코드를 짜지 않고 띵킹을 하며 설계를 주로 해야 하는 단계가 있는가 하면
  2. 그냥 목표를 향해 미친 개처럼 달려야 할 때가 있다.

그런데 자신이 잘 모르는 분야에서는 1.은 통하지 않는다.
모르는 도메인에서 띵킹만 하고 있으면 그건 완전 시간낭비다.

처음 접하거나 익숙하지 않은 도메인이라면
그냥 마구 달려들어서 짜고 돌려보고 짜고 돌려보면서 시행착오를 거쳐야 한다.
이럴 때는 테스트도 필요 없다. 그냥 목표를 달성할 때까지 마구 달려야 한다.

그러면서 도메인과 해결하려는 문제에 대해 알아가야 한다 - 이를 "요구사항을 채굴 한다" 라고 표현하기도 한다.

목표를 달성했다면 이제서야 다시 띵킹을 하면서
막 달리면서 생성했던 코드를 이리저리 쪼개고 합치면서 더 성숙한 프로그램을 만들면 된다.

이걸 반대로 하면 큰일 난다!

흔한 프로젝트 멸망 패턴 두가지

오버띵킹 Overthinking

잘 알지도 못하는데 띵킹만 하고 있으면 - 시간이 남아 돌면 생각보다 흔하게 일어난다
정작 실제로 코딩을 할 때는 쓸데없는 코드만 잔뜩 만들게 되거나
아무 쓸모도 없이 복잡하기만 한 구조에서 똥에 똥을 치대게 될 수 있다.
resource/thonking.jpg
물론 시간이 남아도니까 또 리팩토링 할 수 있겠지만... 쓸데 없는 곳에 낭비한 인생이 아깝다.

흔한 소프트웨어 개발 양상

띵킹을 하고 조심스럽게 설계해야할 때 마구 달리고 있으면 - 시간이 촉박하면 흔하게 일어난다 -
어느 순간 프로젝트의 복잡도가 닝겐이 관리할 수 없는 레벨이 되어 버린다.
테스트까지 짜두지 않았다면.. 어느 순간 잡을 수 없는 버그가 등장하여 프로젝트가 그대로 망해버릴 수도 있어 굉장히 위험하다.
resource/we-r-2-busy(with square wheel).png

사실 2는 누구나 경험하게 된다. 시간이 충분한 프로젝트는 거의 없으니까.
그러나 2의 경우 거지같더라도 일단은 돌아가는 코드가 나오게 된다.
어떤 면에서는 그냥 좆같은 코드일 뿐 고객에게는 상관 없을 수도 있다.

오버띵킹의 함정

오버띵킹시간이 충분한 개인 프로젝트에서 생각보다 자주 일어난다.

아무도 재촉하는 사람도 없고 내 맘대로 해도 아무도 뭐라 안 한다.
얼마든지 코드 품질로 딸딸이를 칠 수 있고 함슬람을 쓰던 어셈을 쓰던 진짜 내 좆대로 가능하다.

어느 순간 완벽한 설계 혹은 깔끔하고 심플한 구조, 완벽한 성능 등 쓸데 없는 것에 신경쓰다가
정신을 차려보면 코드는 안 짜고 띵킹에 띵킹만 계속 하게 된다.
개인 프로젝트를 많이 해본 사람이면 사실 완성한 프로젝트보다 띵킹만 하다 접은 프로젝트가 훨씬 더 많을 것이다.

오버띵킹은 생각 이상으로 위험하다

그 도메인에서 산전 수전 공중전 다 겪은 고인물이 아닌 이상 오버띵킹이 산출하는 건 아무것도 없다.

완벽한 설계와 구조라고 생각하면서
아무짝에도 쓸모 없고 혼자만 알아보는 요구사항 문서 같은 것을 만들어낼 수는 있지만
거기에 맞춰서 코딩하다보면 곧 아무 짝에도 쓸모 없다는 것을 깨닫게 된다.

결론

내가 오버 띵킹에 빠져서 얼마나 많은 시간을 낭비했는지 모르겠다...

개인 프로젝트를 진행하는 사람들은 오버띵킹의 함정에 빠지지 않게 조심하자.




요약


과거 블로그 댓글

#from/old-blog#sw-design설계
kur2002190925Archivekur2006111331