Today
-
Yesterday
-
Total
-
  • 프로젝트 초반에 완벽한 설계에 공들이 필요가 없는 이유
    Programmer/Etc 2014. 3. 19. 10:38

    프로젝트 초반에 설계에 많은 시간과 공을 들이는 것에 대해서 부정적으로 생각한다. 혹시나 오해하는 분이 계실까봐서 미리 말하자면, 설계가 필요없다는 것은 아니다. 프로젝트의 과정을 간단히 말하면 "설계-구현-테스트"의 반복이며 각각의 비중은 같다. 즉, 설계와 테스트의 단계 역시 구현과 동일하게 중요하다. 하지만, 아래 설명할 몇가지 이유로 프로젝트 초반에 설계를 결정지으려고 하기보다는, 프로젝트 초반에는 대략적인 스케치로 시작해서 프로젝트 전반에 걸쳐 반복 작업을 통해서 구체화하여야한다.


    프로젝트 전반에 걸쳐서 설계는 수시로 변할 수 밖에 없다. 그 이유를 몇가지 나열하자면,

    1. 프로젝트를 수행하면서 프로젝트에 대한 이해가 넓고 깊어진다. 프로젝트의 배경 지식과 더불어 개발의 지식과 경험도 늘어간다. 프로젝트의 이해도가 높아지면서, 더 좋은 설계로 개선할 필요가 생긴다.
    2. 프로젝트 중간에 고객의 요구 사항이 변경되거나 주변 상황(예를 들면, 새로운 기술이나 단말기의 출연)이 변화한다.
    3. 프로젝트 초기에 미쳐 예상하지 못한 수많은 함정이 실제 구현에서 발견된다.

    등이 있다.


    이제 당신은 설계 변경이 일어날 때마다

    • 구체화된 설계서에서 변경의 영향을 받는 모든 곳을 찾아서 일일이 수정하거나[각주:1]
    • 어설프게 수정된 또는 변경사항이 전혀 반영이 안된 설계 문서를 남겨둔다.

    전자는 일이 고되고, 후자는 설계서의 존재 이유가 없어진다.


    소프트웨어는 수정이 쉽다. 소프트웨어와 비교되는 것은 하드웨어인데, 자동차나 건물은 이미 만들어진 부분에 대한 수정이 매우 어렵다. 이런 경우에는 초반에 많은 시간이 들더라도 충분한 시간과 노력을 기울여서 최대한 완벽한 설계를 만들어야겠다. 반면, 소프트웨어를 변경하는 작업은 상대적으로 수월하다. 중간에 잘못된 설계를 발견하거나 요구 사항이 변경되어도, 설계[각주:2]를 변경하고 코드를 고치면 된다. 이 과정에서 들어가는 비용이 초반에 완벽한 설계에 매달린 비용보다 훨씬 저렴하다.


    프로젝트의 진행은 움직이는 과녁에 화살을 맞추는 것과 같다. 프로젝트 초기에는 과녁과 매우 먼 거리에 있어서 움직이는 과녁의 중앙, 소위 골드를 맞추기는 어렵다. 내가 움직이는 방향이 과녁의 방향과 대략 일치하면 그 방향으로 걸어간다. 과녁과 나의 거리는 점점 좁혀진다. 과녁이 움직이거나 방향이 어긋났다는 것을 발견하면 그에 맞게 걸어가는 방향을 수정한다. 이 방법을 따르면 목표물 근처에 꽤 근접하게 된다. 이제 골드를 맞출 확률이 매우 높아졌다.


    설계는 프로젝트가 진행되는 동안 내내 반복되는 작업니다. 프로젝트 초기에 완변한 설계는 매우 어렵다. 오히려 프로젝트를 진행되면서, 요구 사항에 잘 부합하는 설계가 더 잘 드러난다. 대부분의 개발자들이 프로젝트 중후반에 가면 "다음 번에 다시 설계하면 더 잘 만들텐데..."라고 하지 않던가. 게다가 완벽하지 못한 설계 때문에 구현에 문제가 생겨도 쉽게 이를 해결할 수 있다. 당신이 지금 작업하는 것은 소프트하다.


    전술한 내용을 실제로 활용하는 방법은

    • 설계는 화이트보드 등과 같이 쉽게 그리고 지울 수 있는 도구를 이용한다. 굳이 특별한 도구(예를 들면, Visio)[각주:3]를 쓸 필요가 없다. 여럿이 설계에 참여할 때는 화이트보드 만한 것이 없다.
    • 때로는 코드로 설계하고 이야기한다. 소스 코드가 다이어그램보다 표현력이 좋은 경우가 꽤 많다.
    • 코드에서 설계가 드러나지 않는다는 것은 설계나 코드 구현에 문제가 있다는 것이다. 코드에서 자료 구조만 뽑아내도 설계가 드러나기 마련이다.
    • 화이트보드의 내용을 자료로 남기고 싶으면 사진을 찍어라. 사진을 찍는 도구는 주변에 널려있다.[각주:4]
    • 문서화가 필요한 경우는 설계 과정에서 자주 거론되는 영역을 발견했을 때이다. 이런 문서는 가능하면 공용 저장소에 남겨서 참여자들이 접근가능하도록 하라.
    1. 시간과 노력을 기울여 수정했지만, 이후에도 여러번의 설계 변경이 발생할 것을 우리는 알고 있다. [본문으로]
    2. 설계 문서를 말하는 것이 아니다. 설계는 무형의 생각이다. 설계 문서는 이것을 다이어그램이나 활자로 남겼을 뿐이다. 잘짜여진 소스코드와 주석이 설계 문서를 대신하는 경우도 많다. [본문으로]
    3. 도구는 비용이 많이 든다. 비용은 단지 구매 비용만을 말하지 않는다. 도구를 익히는 비용은 생각보다 비싸다. [본문으로]
    4. 스마트폰을 비싸게 샀으면 이런때에 이용해라. [본문으로]

    댓글

Designed by Tistory.