어떤 문제를 해결하는가

Harness Docs는 작은 cross-functional product team이 제품 개발 문서를 함께 만들고 검토하고 배포할 때 겪는 반복적인 문제를 줄이기 위해 만들어졌습니다.

문제 1. 역할별 문서가 서로 분리되어 쉽게 어긋난다

작은 팀에서도 PM, 디자이너, 개발자, 리드가 보는 문서는 조금씩 다릅니다.

• 요구사항 문서
• UX flow 문서
• 기술 명세
• 정책 또는 의사결정 문서

이 문서들이 각각 따로 관리되면 같은 제품을 설명하면서도 내용이 조금씩 달라지기 쉽습니다. 그 결과 팀은 "무엇이 최신 판단인지", "어떤 문서를 믿어야 하는지", "어디서부터 맞춰야 하는지"를 계속 다시 확인해야 합니다.

Harness Docs는 역할별 문서를 하나의 시스템 안에서 구조적으로 관리하고, 문서 간 관계를 드러내는 방향을 지향합니다.

문제 2. 문서가 신선한지 직접 확인해야 한다

제품은 계속 바뀌지만 문서는 항상 그 속도를 따라가지 못합니다. 더 큰 문제는 문서가 오래됐는지 아닌지를 사람이 직접 읽고 비교해봐야 하는 경우가 많다는 점입니다.

그 결과 팀은 자주 이런 상황을 겪습니다.

• PRD는 바뀌었는데 UX Flow는 그대로 남아 있음
• UX Flow는 업데이트됐는데 Technical Spec은 예전 기준을 설명함
• 정책 결정은 바뀌었는데 연결된 다른 문서는 여전히 예전 결정을 전제로 작성되어 있음

Harness Docs는 문서 간 연결 관계와 변경 영향을 바탕으로, 사용자가 문서를 하나씩 직접 대조하지 않아도 어떤 문서가 신선한지 아닌지를 더 쉽게 알 수 있게 만드는 데 초점을 둡니다. "이 문서가 아직 최신인가"를 감으로 판단하는 대신, 다시 확인이 필요한 문서를 명확하게 드러내는 것이 핵심입니다.

문제 3. 검토와 승인 맥락이 문서 밖으로 흩어진다

문서를 수정하는 일과 그 문서가 팀 기준에서 충분히 검토되었는지를 판단하는 일은 다릅니다. 하지만 실제로는 댓글, 메신저, 회의, GitHub PR, 별도 문서가 섞이면서 공식적인 검토 상태를 한눈에 파악하기 어렵습니다.

그 결과:

• 누가 검토해야 하는지 불명확함
• 충분히 검토된 문서인지 다시 물어봐야 함
• 문제가 있는 문서를 누가 최종 판단할 수 있는지 분명하지 않음

Harness Docs는 문서 상태, 검토 상태, 최종 판단 맥락을 앱 안에서 추적합니다.

문제 4. GitHub는 배포에는 좋지만 문서의 상태를 설명해주지는 않는다

GitHub는 Markdown을 배포하고 변경 이력을 남기기에는 좋습니다. 하지만 GitHub만으로는 그 문서가 팀 기준에서 최신인지, 다시 확인이 필요한지, 어떤 관련 문서 변경의 영향을 받았는지를 설명하기 어렵습니다.

Harness Docs는 GitHub를 배포 채널로 사용하되, 문서의 상태와 맥락은 앱이 관리하는 방식을 취합니다.

Harness Docs가 지향하는 해결 방식

• 역할별 제품 문서를 하나의 시스템 안에서 구조적으로 관리
• 문서 간 연결 관계와 변경 영향을 바탕으로 어떤 문서를 다시 봐야 하는지 더 명확하게 표시
• 문서를 하나씩 직접 확인하지 않아도 어떤 문서가 최신인지 빠르게 파악 가능
• 검토와 배포 맥락을 앱 안에서 관리하고, GitHub는 배포 채널로 사용
• 비개발자도 CLI 없이 문서 작성, 검토, 배포 흐름에 참여 가능

한 문장 요약

Harness Docs는 제품 개발 문서가 역할별로 흩어지고, 최신 상태를 직접 확인해야 하며, 검토와 배포 맥락이 분리되는 문제를 줄이려는 제품입니다.