온보딩 문서의 법무 정책 갭, 실제로는 커뮤니케이션 부족이었다

처음엔 간단해 보였다. 새 사이트를 론칭할 때마다 온보딩 문서를 쓰고, 개발팀·운영팀·법무팀이 다 읽으면 끝. 그럼 다음 팀원이나 신입도 같은 순서로 따라가면 된다고 생각했다. 실제로는 그렇지 않았다.

산발적인 법무 체크리스트의 폐해

온보딩 문서를 쓸 때마다 법무 담당자에게 물어봤다. "이 단계에서 뭘 확인해야 하나요?" 하지만 항상 일관된 답변이 나오지 않았다. 어떤 사이트는 약관 심사가 먼저였고, 어떤 사이트는 라이선스 검증이 우선이었다. 정책 자체는 바뀌지 않았는데, 매번 다르게 기록되면서 각 팀은 자신의 경험만 의존하게 됐다. 새로 합류한 팀원은 "이전에는 어떻게 했대" 같은 구전 지식에 의존하게 되고, 체크리스트가 실제로는 단순한 참고 정보일 뿐이었다.

문제는 여기서 끝나지 않았다. 다국어 지원 사이트를 온보딩할 때, 각 팀은 URL 슬러그나 언어 설정을 다르게 해석했다. 개발팀은 slug.lang 방식을 쓰려 했고, 운영팀은 다른 구조를 제안했으며, 법무팀은 "왜 이걸 들어야 해?" 같은 반응을 보였다. 그들이 우리를 모르는 게 아니라, 문서에 명시되지 않았기 때문이었다.

법무 중앙화와 기술 표준의 교점

이번 커밋은 이런 산발성을 하나로 모은 작업이었다. 온보딩 문서를 다시 정리하면서 법무 정책을 "중앙화"했다는 것은, 흩어진 조각들을 한데 모아 누구든 같은 관점에서 읽을 수 있게 만들었다는 뜻이다. 각 사이트마다 법무 단계가 어디에 위치하고, 어떤 순서로 진행되며, 누가 최종 승인하는지를 명확히 했다.

동시에 slug.lang 같은 기술적 명명법도 기록에 남겼다. 이건 단순한 기술 노트가 아니다. 이 기호 하나가 "우리가 다국어 사이트를 이렇게 구성하기로 결정했다"는 팀의 합의를 대표한다. 내부 정책이나 운영자 간 약속을 문서에 남기지 않으면, 신입이 들어올 때마다 같은 질문이 반복된다.

문서는 계속 살아있어야 한다

이 작업을 하면서 깨달은 건, 온보딩 문서는 한 번 쓰고 끝내는 게 아니다는 것이다. 새로운 사이트가 나올 때마다, 또는 정책이 바뀔 때마다 문서와 현실이 어긋난다. 그 갭을 방치하면 다음 온보딩이 틀어진다.

팀 리더 입장에서 생각해보면, 문서 "정정"은 코드 리뷰보다 느리지만 더 넓은 영향을 미친다. 코드는 특정 기능에만 관여하지만, 온보딩 문서는 앞으로 들어올 모든 팀원의 첫 경험을 결정한다. 그래서 이런 '정리 작업'이 우선순위에서 밀려나면 부채가 누적된다. 정책은 있는데 기록이 없고, 기술 표준은 쓰이는데 명시되지 않고, 각 팀은 자기 해석대로만 일한다.

이번에 법무 갭을 채운 것은 "법무팀이 요구하니까"가 아니라, 팀 전체가 같은 언어로 말하기 위함이었다. 다국어 처리 표준도 마찬가지. 이건 개발팀만의 문제가 아니라 전체 워크플로우의 일관성 문제였다.

앞으로도 새 사이트를 만들거나 정책이 바뀔 때마다 이 문서를 꺼낼 것이다. 매번 "어, 이거 여기에는 없네?" 하고 고치고, 또 고치고. 문서가 정책보다 한 발 뒤처지는 건 당연하다. 중요한 건 그 갭을 빨리 알아채고 메우는 것.

🛒 이 글과 어울리는 추천 상품

• 사무의자 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.