온보딩 문서 생성: 새 개발자가 첫 실행까지 도달하는 가이드

온보딩 문서 생성의 목표는 저장소 전체를 길게 설명하는 것이 아니라, 새 개발자가 프로젝트를 실행하고 첫 작업의 위치를 찾게 하는 것입니다. 코드로 확인할 수 있는 사실과 팀에 물어봐야 하는 맥락을 나누면 자동 생성 초안을 더 유용하게 검토할 수 있습니다.

첫 실행을 위한 문서 구조

• 프로젝트가 해결하는 문제와 주요 사용자.
• 필요한 런타임·도구와 접근 권한 요청 경로.
• 설치, 환경 설정, 로컬 실행, 테스트 명령.
• 주요 폴더와 진입점, 요청이 처리되는 흐름.
• 첫 작업 예시와 리뷰·배포 담당자.

환경변수는 이름과 용도, 발급 경로를 설명하고 실제 비밀값은 문서에 넣지 마세요.

자동으로 만들 초안과 사람이 보완할 내용

저장소의 설정 파일, 스크립트, 소스 구조는 실행 가이드의 근거가 됩니다. 반면 특정 설계를 선택한 이유, 권한 승인 담당자, 장애 대응 관행은 코드에 없을 수 있습니다. 알 수 없는 내용을 그럴듯한 답으로 채우지 않고 확인 항목으로 남기세요.

Specify에서 시작하는 순서

1. GitHub 저장소를 문서 프로젝트에 연결합니다.
2. 온보딩에 필요한 문서를 선택해 생성을 시작합니다.
3. 생성된 명령과 파일 경로를 현재 개발 환경에서 확인합니다.
4. 팀의 접근 절차와 결정 배경을 보완합니다.
5. 이후 코드 변경 때 관련 문서와 수정안을 함께 검토합니다.

GitHub 문서 연동 가이드는 연결 범위와 반영 정책을 설명합니다. 문서 생성 시간과 완성도는 저장소·소스 정보에 따라 달라집니다.

문서를 처음 보는 사람이 검증해야 합니다

기존 담당자에게는 당연한 권한이나 환경 설정이 신규 합류자에게는 빠져 있을 수 있습니다. 익숙하지 않은 사람이 안내만 보고 설치·실행·테스트를 해보게 하고, 막힌 단계와 추가로 물어본 질문을 기록하세요. 생성 완료 자체를 온보딩 성공으로 측정하지 않습니다.

유지할 체크리스트

런타임 버전, 실행 명령, 환경변수 이름, 디렉터리 구조, 배포 절차가 바뀌면 가이드를 다시 확인합니다. API를 다루는 첫 과제가 있다면 API 문서 최신화 체크리스트도 함께 사용하세요.

개발문서 자동화 기능에서 범위를 확인하고 워크스페이스를 시작하세요.