Archive for the ‘최고의 설계자’ tag
소프트웨어 공학의 사실과 오해 5 – 설계
http://www.yes24.com/24/goods/1418676
설계
요구사항을 설계로 옮겨갈 때 솔루션 프로세스의 복잡성 때문에 ‘파생 요구사항’(특정 설계 솔루션에 대한 요구사항)이 급증한다. 이런 설계상의 요구사항은 종종 원래의 요구사항보다 50배 넘게 늘기도 한다.
- 중략 -
모두들 요구사항 추적 용이성(traceability)이 바람직하다고 생각하지만 (부분적으로는) 요구사항의 폭발적 증가 때문이 이를 실현하기는 어렵다.p.145, 146
현재 진행중인 프로젝트의 프로덕트 백로그(요구사항 리스트 비슷한 것)를 사용자 관점의 것과 개발자 관점의 것으로 2개 관리하자라는 말을 들었을 때, 이 얘기를 하면서 반대했던 기억이 있다. 개발자 관점의 것은 사용자 관점의 것보다 50배나 많아질 수도 있으니까.
소프트웨어 문제에 대해 최상의 솔루션이 하나인 경우는 거의 없다. – 중략 – 문제가 정의됐을 때 훌륭한 설계자들이 모두 동일한 최상의 설계 솔루션을 제시하는 경우는 거의 없다. (“최고의 설계자들이 모인 방에서 두 명의 설계자가 동의한다면 그게 다수 의견이다.”라는 말은 소프트웨어 분야에서 내가 좋아하는 인용구 중 하나다.)
p.150
전적으로 동의하지만, 동시에 이 얘기가 오해를 불러일으킨다고 생각한다. 좋은 설계를 찾기위한 노력을 게을리 하는데 좋은 구실이 되기 때문이다. 하지만 분명히 좋은 솔루션과 나쁜 솔루션이 존재하므로 더 좋은 솔루션을 찾기 위한 노력은 계속되어야 한다. 또 다른 오해는 몇 가지 설계를 두고 논쟁이 생겼을 때 어차피 정답은 없다는 이유로 토론을 회피하는 것이다. 하지만 이 경우에 논쟁의 대상이 되는 몇 가지 설계가 최상의 솔루션들인 경우는 거의 없으며 기본적인 설계 원칙들도 지키지 못하는 경우가 많다. 한 마디로 나같은 보통의 개발자에게는 해당되지 않는 얘기다.
전문 설계자들은 설계 작업에서 핵심을 파악할 때 경험적, 시행착오적 접근방법을 사용한다는 것이다. 관련된 문제에 대한 예전의 설계를 기반으로 해서 설계 솔루션을 하나 생각하고, 마음속으로 이 솔루션에 대표적인 데이터를 조금 넣어보고, 이 데이터에 대한 작동을 모의실험한 다음, 이 솔루션에서 데이터에 대한 출력을 뽑아낸다. – 중략 – 후보 솔루션을 약간 수정해 확인된 문제를 제거하고, 샘플 데이터를 다시 적용해본다. 출력이 맞게 나올 때까지 이 과정을 반복한다.
p.154, 155
다들 이런 경험을 가지고 있을 것 같다. 책에서는 이런 설계 방식을 ‘편의적’ 설계라고 부르는데, 이런 연구 결과를 토대로 다음과 같은 결론을 도출한다.
설계는 예측 가능한, 구조화할 수 있는, 규격화할 수 있는 프로세스와는 거리가 멀고, 너저분하고 시행착오적인 것임을 알 수 있다. 그리고 기억해야 할 것은, 이 연구결과는 최고의 설계자들을 조사해서 얻은 것이라는 점이다. 이보다 못한 설계자들은 훨씬 더 너저분한 프로세스로 작업할 것임은 쉽게 상상할 수 있다.
p.155
“너저분한 프로세스”에 가슴이 아프다. ^^;;
복잡한 프로세스로 인해 최적의 설계는 보통 불가능하므로, 우리는 ‘만족스러운’ 솔루션을 위해 노력해야 한다. 만족스러운(최적이 아니라) 솔루션은 훌륭한 설계에 대한 조건을 충분히 만족시켜, 그 접근방법을 선택해 작업을 계속 하는 데 따르는 위험을 감수할만한 가치가 있는 것을 의미한다(최적의 설계는 불가능하거나 비용대비 효율이 낮다는 전제하에)
p.156
현실과 적절하게 타협할 필요가 있다라는 말로 이해할 수 있는데, 나같이 “만족스러운 솔루션”을 만드는 것도 벅찬 사람에게는 해당되지 않는 얘기다.