10-1 update.
다찌님의 트랙백을 읽고 다시 제 글을 읽어 보니, 너무 큰 문제에 대해서, 너무 단편적으로만 글을 썼다는 생각이 들었습니다. 물론 확장성을 고려해야 한다는 것에 저도 동감합니다.
그래도 한 가지 확실한 제 생각은 현재의 요구 사항에 집중해야 한다는 점입니다. 현재의 요구 사항에 맞춰서 확장성을 고려한 설계가 의미있지, 차후의 요구 사항을 "예측"해서 설계하는 것은 시스템의 복잡성을 가중 시키지 않나 생각합니다.
저도 이런 의문이 듭니다. 앞으로 충분히 발생할만한 상황이 있고, 그 요구 사항이 매우 중요한 경우 어떻게 해야 할까요? 고민되는 상황입니다. 상황에 따라 다른 결정이 나올수도 있지만, 지금 제 생각은 일단 내쳐야 한다고 생각합니다. 현재 요구 사항에 맞는 최적화된 해결책이 앞으로의 문제에 대한 대비책이 아닐까요?
다찌님의 의견처럼 짧은 릴리즈 단위와 주기적인 iteration이 정말 필요하다고 생각합니다. 신속 정확 배달이 생각나는 장면입니다. 짧은 릴리즈 단위와 주기적인 iteration이 수시로 변하는 요구 사항에 대응하고, 변경에 대한 최선의 대응책이 될 것 같습니다. 최초 최소한의 Architecture design decision과 짧은 릴리즈 단위, 주기적인 iteration이 좋겠군요.(적용 가능하다면,,)
실제 업무에서 짧은 릴리즈 단위와 주기적인 iteration을 적용할 만큼의 공부가 필요할 것 같습니다. 흥미롭군요^^
======================
학교의 S/W Architecture 수업 시간에 외국 대학 강의를 듣고 있습니다. 영어가 잘 안들리지만 그래도 열심히 듣고 있죠(하지만 너무 안들려요 ㅠㅠ).
저번 수업 시간에는 이런 내용이 나오더군요.
earlry design decision => reduce risk!
얼핏 보면 당연하듯이 보입니다. 또한 고객의 요구 사항(requirements)를 조기에 분석해서 아키텍쳐를 잡는게 중요하다고 강조합니다. 좋은 말입니다.
하지만 요즘 제 생각은 위 논리와 완전 반대로 흘러 가고 있습니다.
요즘에는 Implementing Lean S/W development와 Agile Software Deveopment 책을 읽고 있는데, 이 책에서는 (Agile 방법론에 입각한다고 할 수 있겠습니다.) 프로젝트 초기에 지나친 요구 분석과 지나친 아키텍쳐의 결정은 오히려 아키텍쳐의 유연성(fexiblility)를 떨어 뜨린다고 주장하고 있습니다.
차후 확장성을 고려해서 아키텍쳐를 구축하는게 오히려 복잡한 시스템을 만들고, 확장성을 떨어 뜨린다고 생각합니다. 확장성을 고려해서 일을 한게 오히려 확장성을 떨어 뜨리게 되는 결과를 불러 일으킨다는 것이죠.
Agile Software Development를 보면 초기 아키텍쳐 설계 시 시스템이 파일 시스템으로 충분하다고 생각하면, 심지어 DB가 아닌 파일 시스템까지 사용한다고 말하고 있습니다. 물론 극단적인 예이기는 하지만요.
Lazy Design Decision :: Early Design Decision is often caused Increase Risk!
그래서 제가 수정하고자 하는 문장은 위와 같습니다. 처음에는 often이 없었지만 한 발짝 물러나서 often을 넣었습니다^^.
유연한 설계를 위해서 골머리를 쌓기 전에, 더 쉬운 방법은 설계의 결정을 최소화 하는 것이다.
당연한 얘기인 것 같지만, 쉽게 지나치며, 받아 들이기에는 더더욱 힘든 내용입니다. 무조건 미뤄라 하는 식의 논조로 어느 누구를 설득시킬 수 없겠죠. 좀 더 고민해봐야 할 좋은 주제입니다.
Prev
Rss Feed