Theory/Project Management

프로젝트 초반에 완벽한 설계에 공들이 필요가 없는 이유

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


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

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

등이 있다.


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

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

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


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


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


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


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

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

    좋은 글 잘 읽었습니다. 저와 설계 철학이 비슷하시네요. 트랙백 걸고 가겠습니다.^^

  2. Favicon of http://blog.dahlia.kr/post/122172479197 참고 링크 M/D Reply

    건축을 비롯해 처음부터 완벽하고 올바른 설계를 하는 것을 강조하는 많은 분야들에는 하나 같이 대동소이한 정당화가 존재한다. “한번 만들면 바꿀 수 없다.”
    ...
    소프트웨어 공학은 한동안 건축의 메타포를 버리지 못했다.
    ...
    현대의 소프트웨어 개발은 점진적이며, duct tape programmer라는 말도 생겼을 만큼 ‘얼기설기’ 만들어서 ‘조금씩 고쳐나가는’ 것이 가능해졌을 뿐만 아니라, 그러한 것을 오히려 바람직한 개발 방식으로 본다.
    ...
    소프트웨어 개발이 점진적일 수 있게 된 이유는, 점진적으로 소프트웨어 개발을 빠르고 쉽게 할 수 있는 충분한 도구가 아주 많이 주어졌기 때문이다. 그리고 그러한 도구가 아주 많이 생겨날 수 있었던 이유는, 프로그래밍이라는 작업의 특수성에 기인한다.
    ...
    프로그래머들은 아주 운이 좋게도 스스로의 도구를 고치거나 만들어낼 수 있었다.

  3. Favicon of http://blog.weirdx.io/%EA%B8%B0%ED%9A%8D%EC%84%9C%EB%A5%BC-%EC%93%B0%EB%8A%94-.. minieetea님 글 인용자 M/D Reply

    대표적인 화면 1개를 그리고 그 화면에서 발생할 수 있는 베리에이션에 대해서는 별도의 문서로 작성하는 것이 좋다. 트리구조나 플로우로 먼저 정리한다.

    기획서는 요구사항이나 스펙등을 개발팀과 상호리뷰하고 공유하는데에 목적이 있다. 따라서 기획서는 잦은 리뷰와 업데이트, 팀 공유에 최적화 되어야 한다.

    기획서는 효율적인 커뮤니케이션을 위한 도구가 되어야 한다. 기획서의 우선순위는 커뮤니케이션, 공유, 리뷰, 도큐먼테이션이 되어야 한다.

  4. Favicon of https://mingrammer.com/translation-the-truth-is-in-the-code 옮긴이 M/D Reply

    코드 주석 및 외부 명세는 소프트웨어의 동작을 문서화한다.
    그러나 이들은 코드가 변경될 때 갱신되지 않을 수도 있다.
    그런 다음 이들은 곧 소프트웨어의 동작을 반영하지 않을 것이다.

    이와 반대로, 코드는 소프트웨어의 동작을 항상 반영한다. 코드는 이를 정의한다.

    코드를 이해하기 쉽게 만드는 일반적인 제안은 클린 코드를 작성하는 것이다.

알림

이 블로그는 구글에서 제공한 크롬에 최적화 되어있고, 네이버에서 제공한 나눔글꼴이 적용되어 있습니다.

카운터

Today : 79
Yesterday : 122
Total : 164,455

티스토리 툴바