Google Design Docs에 대한 설명입니다.

구글 내부에서는 소프트웨어 설계를 정의하는 디자인 문서를 비공식 정으로 사용한다고 합니다. 비공식 문서라서 엄격한 가이드라인이 있는 것은 아니지만 그동안 수많은 디자인 문서가 만들어지면서 유용한 구조가 자리 잡았다고 합니다.

맥락과 목표, 목표가 아닌 것을 명확히 설명하고 실제 디자인에 대한 설명과 다이어그램, 제약 조건을 명시하고 다른 대안이나 우려사항은 없는지를 설명하지만 바쁜 사람들도 쉽게 읽을 수 있을 정도로 짧아야 한다고 합니다.

디자인 문서를 작성하는 것도 비용이기 때문에 작성할 때 고민해야 하는데 보통 의사 결정에 대한 설명 없이 구현에 대한 설명만 있다면 문서를 작성하는 것보다는 바로 프로그래미을 작성하는게 더 좋은 선택이라고 얘기합니다.

이렇게 만든 문서는 반복을 통해서 개선한 뒤 리뷰를 통해서 다듬고 이후에도 계속 유지 관리를 하면서 시간이 지나면 소프트웨어가 만들어 진 후 다시 학습에 사용된다고 합니다.

----

디자인 문서나 테크 스펙을 많은 조직에서 사용합니다만 개인적으로 디자인 문서를 좋아하는 편은 아닙니다. 조직의 상황이나 문제에 따라 다르긴 하겠습니다만 일반적으로는 디자인 문서를 작성하는 것이 실제 할일보다는 너무 장황하게 느껴서 오히려 일이 느려지는 느낌을 많이 받는 편입니다. 실제 일보다 서류 작업이 많은 보수적 조직에 닮아가는 느낌이 어느 정도 있습니다.

물론 문서를 작성하고 형식에 맞게 설명을 하면서 구현자 스스로도 정리를 하게되는 효과도 있고 다른 사람도 이해할 수 있게 문서로 남음으로써 이해도도 높이고 히스토리가 되는 장점도 있다고 생각합니다. 이렇게 되려면 문서의 실용성이 상당히 많이 검증되어야 합니다만 일반적으로는 협업시에 제출해야할 서류 정도로 쓰이는 경우가 많아서 너무 사소한 일에도 문서를 작성해야 하거나 너무 추상적인 문서가 작성되는 상황을 종종 보게 됩니다.

물론 개인 취향이 많이 반영되어 있긴 합니다. 문서의 필요성은 중요하긴 하지만 저는 일반적으로 좀 장황하게 느껴지는 편입니다.

https://www.industrialempathy.com/posts/design-docs-at-google/