태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

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

2009/02/06 00:55 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed

프레드 브룩스가 얘기한 "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을 만들 때를 대비해서 내공을 쌓아가세요."

저작자 표시 비영리 변경 금지

전규현 소프트웨어이야기

Trackback Address: http://allofsoftware.net/trackback/73 관련글 쓰기
  1. "First System의 기반을 완전히 무시하는 것은 그동안 개발팀이 쌓아온 재산을 무시하는 것과 다름이 없습니다."
    정말 중요한 얘기 같습니다.
    그나저나 이 글을 읽으니 『Refactoring』을 무지무지 읽고 싶어지네요.

  2. 아리새펜촉님 반갑습니다.
    많은 소프트웨어 회사들이 어려워지고 망해가는 한 원인이기도 합니다.

  3. 좋은 글 잘 봤습니다, 꼭 소프트웨어가 아니라도
    모든 상황에 적용할 수 있는 이야기인 것 같네요. ^^
    저 역시 의욕에만 넘쳐 기존의 것들을 무시했다가 피본 적이 있어요.

  4. 비밀병기님 안녕하세요.
    모든 원리는 통하는 법인가 봅니다.

문서를 작성하면 더 오래 걸린다는 고정관념

최근에 국내 유수 대학의 컴퓨터 공학 교수를 만난 적이 있다. 그 교수님도 문서를 작성하면서 Software를 개발하면 더 오래 걸린다고 굳게 믿고 있었다. 어느 정도 이해가 되는 상황이다. 원래 소프트웨어 공학은 실전에서..

이슈를 모으기도 정말 어렵다.

많은 회사들이 개발 프로세스 개선을 하겠다고 선진 개발 방법론을 흉내내거나 실패한 대기업의 프로세스를 가져다가 적용하곤 한다. 복잡한 프로세스와 많은 Template를 가져다가 적용해보려고 하는데 대부분은 실패를 한다. 기초..

변화에 실패하는 9가지 고정관념

회사는 끊임없이 변화하지 않으면 지속 성장하지 못한다. 하지만 변화는 피와 살을 깍는 고통을 동반하고 또 많은 회사가 변화에 실패해서 성장하지 못하거나 사라져간다. 보통의 사람들은 대부분 변화를 싫어하고 기존에 하던대로 계속..

좋은 프로그래머가 되는 24가지 방법

1. 프로그래밍에 열정이 있어야 한다. 열정이 없고 즐기지 못하면 평생하기 어려운 일이다. 2. 프로그래밍 기초 원리를 완전히 이해해야 한다. 원리를 모르면 근본적인 해결을 할 수 없다. 3. 문제 해결 능력을 키워야 한다...

요즘 실리콘밸리에서는...

얼마전 실리콘밸리의 한 Startup company에서 CTO로 일하고 있는 오랜 친구가 한국에 놀러와서 같이 여행을 갔다. Informix에서 소프트웨어 엔지니어로 시작해서 한 20년 정도 일한 중국인 친구다. 같이 일을..

전문가 vs. 책임자

우리나라 조직문화는 전문가보다 책임자를 선호한다. 조직의 장이 책임을 지고 모든 일을 알아서 하는 것이다. 상명하복 관계 위주다. 경영자가 SW개발에 대해서는 잘 모르는 경우 누구 한명이 책임지고 개발해줬으면 하는 생각을 하..

소프트웨어 회사의 자산은?

소프트웨어 회사의 자산은 무엇일까? 흔히 개발자가 소프트웨어 회사의 재산이라고 한다. 이런 회사일 수록 회사가 가지고 있는 것은 정말 개발자밖에 없다. 또한 파악하기 어려운 한 무더기의 소스코드가 있다. 개발자들이 나가면 이..

관리자가 이런 일까지?

우리나라 SW 조직에서 관리자란 위치는 참 애매한 위치다. 물론 전문 관리자라면 얘기가 다르지만 왕년에 SW를 조금 개발해 본 경우가 애매하다. 개발팀에서 가장 경험이 많은 SW 개발자들이 주로 팀장이 되곤 한다. 이 경우와..

과거의 성공이 발목을 잡을 때

수많은 소프트웨어 회사들이 첫번째 성공을 거두고 나서 두번째 도약에 실패하고 사라져간다. 물론 첫번째 성공도 어렵지만 이미 성공의 경험이 있고 방법을 알고 있는 회사들이 두번째 또는 세번째에는 많이 실패하는 이유가 무엇일까?..

스펙을 제대로 작성하는 것은 구식이다?

'소프트웨어 개발 방법이 얼마나 발전했는데 아직도 스펙을 제대로 작성하고 개발을 하는가?' 라고 하면서 스펙 작성에 반대하는 주장을 하는 사람들이 있다. 스펙, 설계를 작성하고 구현을 하고 테스트를 하는 방식으로 개발하는 것..