이 상황이 끔찍한 이유는 이렇다

프로젝트에 참여하다보면
정말 수백명의 인원이 함께 하는 프로젝트가 이런식의 관리로
어찌어찌 릴리즈되는 것을 접할 기회가 많습니다.
(아쉽게도 정말 많습니다).

그런 끔찍한 상황을 만드는 원인 중에 하나가
아키텍처 설계 단계에서 생각지 못했던 문제가 쏟아져나오고
이를 대응할 수 있는 여유를 가질 수 없기 때문입니다.
(아마도 아키텍처 설계 단계에서는 완벽한 설계라고 생각했을지도 모르지요).

한국에서만 이렇지...뭐...라고 생각할지도 모르겠지만
사실은 어디나 그런 문제는 있는것 같습니다.
사람이 하는 거니깐요.

http://byulbada.egloos.com/2279847

핵심 뱅킹 변환의 최악 사례 및 기타 끔찍한 스토리 라는 제목의 글에서는
이런 문제를 살짝 들여다보게 합니다.
http://www.ibm.com/developerworks/kr/websphere/techjournal/1008_col_simmons/1008_col_simmons.html

물론 알고 보면 IBM 제품을 최적화해서 사용하자는 주장같긴 하지만
아키텍처에 대해 누구나 겪을 수 있는 문제를
잘 표현해주고 있는듯 합니다.
발생한 일 -> 이 상황이 끔찍한 이유는 이렇다...라는 패턴으로 이야기를 풀어가고 있습니다.
사례에 대한 설명이 조금 짧은게 아쉽네요.

글의 마지막에 필자가 쓴것처럼 프로젝트를 바라보는 관점을 바꾸지 않는다면
매일매일이 힘든 하루가 될것 같더군요.
이론적으로(많은 책에서 언급하는 것처럼) 문제 해결을 즐겁게 받아들이는것은
간단해보이지만 현실계에서는 여전히 쉽지 않은 일 같구요. ^^

이 기사에서 설명한 것과 같은 끔찍한 상황이 때때로 발생하는 것이 오히려 즐겁다고 말할 수 있겠다.
왜냐하면, 이런 상황을 해결해나가면서 분명히 흥미와 희열을 느끼기 때문이다