내부 가이드 문서의 팀원명 참조 정리
목차
docs/hedvion-CLAUDE.md 파일을 정독하면서 특정 팀원명을 문서에서 완전히 제거했다. 겉으로는 간단한 텍스트 정리지만, 그 뒤에는 팀 문서를 어떻게 관리할 것인가에 대한 생각이 있었다.
왜 개인명을 문서에서 제거하는가
공유 문서, 특히 팀 정책이나 가이드에 특정 인물의 이름을 박아두는 건 생각보다 여러 문제를 낳는다.
문서 생명주기의 관점에서:
- 그 팀원이 팀을 떠나거나 역할이 바뀔 때마다 문서를 찾아 갱신해야 한다.
- 과정에서 누락되거나 중복으로 남아 있을 확률이 높다.
- 1년 후 신입이 문서를 읽을 때, "이건 jerry가 정했어"라는 정보는 이미 의미가 없어진다.
정책의 명확성:
- 구체적인 이름이 있으면 규칙이 "특정 상황의 예외" 또는 "특정 사람의 선호도"처럼 읽힐 수 있다.
- 하지만 작성자를 익명화하면 정책 자체로 읽힌다. 즉 "왜" 이 규칙이 있는지가 더 중요해진다.
팀 자산화:
- 개인 크레딧을 빼면 문서는 팀 전체의 소유물이 된다.
- 누구든 필요하면 수정·개선할 때 심리적 진입장벽이 낮아진다.
변경 작업
docs/hedvion-CLAUDE.md에서 팀원명이 직접 언급된 부분을 모두 찾아 제거했다.
| 항목 | 작업 내용 | 결과 |
|---|---|---|
| 직접 언급 제거 | "팀멤버: jerry" 류의 표현 | 문서는 정책·가이드로만 읽힘 |
| 컨텍스트 유지 | 정책이나 가이드 내용 자체 | 문서의 의미·지침 변함없음 |
| 재검증 | 제거 후 검색으로 완전성 확인 | "완전 제거"를 확실히 함 |
작업 규모는 작았지만, 정말 완전하게 남은 것이 없는지 확인하는 데 신경을 썼다. 검색을 다시 돌려서 jerry라는 단어가 정말 사라졌음을 확인했다.
이렇게 해야 하는 이유: 팀 리딩 관점
내가 이 변경을 회고로 남기는 이유는, 이게 단순 정리가 아니라 팀 문서 관리의 철학과 맞닿아 있기 때문이다.
코드 리뷰와의 비유:
코드도 마찬가지다. 깃 히스토리(commit author)는 누가 썼는지 추적하지만, 코드 자체에는 "이 함수는 alice가 짰으니까"라고 쓰지 않는다. 문서도 똑같이 생각해야 한다. 누가 썼는지는 버전 관리가 기록하고, 문서 본문은 정책으로 읽혀야 한다.
문서의 시간 초월성:
팀원은 왔다 갔다 하지만, 정책·가이드는 (대부분) 남는다. 개인명을 빼면 문서가 "한 사람의 규칙"에서 "팀의 표준"으로 격상된다. 이건 의외로 강력한 신호인데, 신입도 이 문서를 "팀 정책"으로 읽고, 경력 팀원도 필요하면 자신감 있게 수정할 수 있게 된다.
배운 점
이 작업을 통해 깨달은 게 있다면:
- 공개되거나 팀 전체가 읽는 문서라면, 개인명이나 "특정 상황의 우회"를 제거하는 정기 정리가 도움 된다.
- 문서를 쓸 때부터 "이건 누가 쓸까 vs. 이 팀이 결정할 것"을 구분하면, 나중에 손댈 것도 줄어든다.
- 폐기되거나 역사적 맥락이 필요한 부분은 문서 맨 아래 "변경 이력" 섹션으로 분리하는 게 깔끔하다.
이 작업은 작은 정리였지만, 문서도 코드처럼 주기적인 리뷰 대상이어야 한다는 깨달음을 준 경험이었다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.