GitHub Pull Request를 Notion 주간 보고서로 만드는 방법
Leina로 병합 및 열린 GitHub PR의 출처 링크가 포함된 주간 보고서를 준비하고, 채팅에서 초안을 검토한 뒤 Notion에 추가하세요.
주간 엔지니어링 보고서를 작성한다는 것은 보통 수십 개의 pull request를 수동으로 훑어보고, 링크를 복사하고, 무엇이 병합되었고 무엇이 아직 검토가 필요한지 파악하는 일을 의미합니다.
Leina를 사용하면 이 워크플로를 팀 채팅에서 직접 자동화할 수 있습니다. GitHub와 Notion을 연결하면 에이전트가 PR을 수집하고, 출처 링크가 포함된 구조화된 요약을 작성하고, 승인된 버전을 Notion 워크스페이스에 추가할 수 있습니다. 이를 안정적으로 만드는 핵심은 초안 단계와 쓰기 단계를 분리하여 게시 전에 숫자를 검증할 수 있도록 하는 것입니다.
이미 알고 있는 기록과 초안을 비교할 수 있도록, 완료된 한 주를 기준으로 시작하세요.
보고 범위 정의
AI 에이전트에게 기록을 가져오도록 요청하기 전에, 보고서에 포함될 항목에 대한 명확한 경계 규칙을 정하세요. 첫 실행에서는 단일 저장소와 완료된 한 주를 기준으로 하세요.
| 섹션 | 포함 규칙 | 전달하는 내용 |
|---|---|---|
| 이번 주 병합됨 | 병합 타임스탬프가 지정된 시작 및 종료 경계 내에 있음 | 해당 기간 동안 대상 브랜치에 들어간 변경 사항 |
| 현재 열림 | 쿼리 시점에 PR이 열려 있음 | 진행 중인 작업, 초안 상태, 문서화된 검토 차단 요소 |
열린 PR에 대한 참고: 열린 PR 목록은 쿼리 시점의 저장소를 설명합니다. 이전 주 말에 열려 있던 항목을 보고하려면 저장된 스냅샷이나 그 이후 상태 변경에 대한 증거가 필요합니다. 날짜가 지정된 보고서를 보관하면 향후 비교를 위한 스냅샷을 확보할 수 있습니다.
GitHub의 상태 및 병합 날짜 검색 한정자를 사용하여 소스 기록을 확인할 수 있습니다:
repo:OWNER/REPOSITORY is:pr is:merged merged:2026-09-28T00:00:00+00:00..2026-10-04T23:59:59+00:00
저장소와 날짜를 바꾸되, 시간대는 보고서와 일관되게 유지하세요. 이 예시는 UTC를 나타내는 +00:00을 사용합니다. 팀이 다른 시간대에서 작업한다면 보고 기간에 맞는 적절한 오프셋을 사용하세요.
GitHub와 Notion 연결
Leina Console에서 두 워크스페이스 연결을 승인하세요:
- GitHub: 대상 저장소를 읽을 수 있는 계정과 요약에 필요한 PR 세부 정보를 제공하는 연결을 사용하세요.
- Notion: 저장 단계에서는 의도한 페이지의 내용을 읽고 추가할 수 있는 연결을 사용하세요.
Integrations에서 사용 가능한 작업을, Connections에서 승인된 계정을 확인하세요. 요청하는 멤버도 해당 연결을 사용할 권한이 필요합니다. 연결된 팀 채팅에서 보고서 초안을 작성한 뒤, 검토 후 Notion에 작성하세요.
검토 가능한 초안을 요청하는 프롬프트
출처 링크와 누락된 정보에 대한 명시적 처리를 요구하는 프롬프트로 시작하세요. 다음 요청을 복사하여 조정하세요:
[owner/repository]에 대한 주간 엔지니어링 보고서를[timezone]기준[start timestamp]부터[end timestamp]까지 작성해 주세요.
- 병합된 PR: 해당 기간 내에 병합된 모든 PR을 나열하세요. 각 PR에 대해 번호, 제목, 작성자, 병합 시간, 출처 링크, PR 설명 및 도구를 통해 확인 가능한 변경 사항을 바탕으로 한 1~2문장의 변경 요약을 포함하세요.
- 현재 열린 PR: 현재 시점에 열려 있는 PR을 나열하고, 초안 상태와 문서화된 검토자 또는 차단 요소를 명시하세요.
- 누락된 맥락: PR 설명이 비어 있거나 영향이 불분명한 경우, *“영향 미문서화”*로 명시적으로 표시하세요—비즈니스 이유나 결과를 지어내지 마세요.
- 검색 고지: 검색 타임스탬프를 기록하고, 지원되는 경우 범위 내 모든 결과 페이지를 검색하며, 불완전한 검색이나 접근 불가능한 기록을 보고하세요.
완전한 초안을 여기 채팅에 반환하세요. 아직 Notion에 작성하지 마세요.
팀에서 표준화된 markdown 레이아웃을 사용한다면 빈 주간 보고서 템플릿을 서식 참고 자료로 제공할 수도 있습니다.
GitHub와 대조하여 초안 확인
Notion에 아무것도 올리기 전에 기록 목록을 비교하고 요약을 표본 점검하세요:
- GitHub 검색과 개수 대조: GitHub 검색에서 병합 한정자 쿼리를 실행하세요. PR 수가 에이전트의 병합 목록과 일치하나요?
- 경계 타임스탬프 확인: 시간 범위의 양 끝에 가까운 PR을 소스 목록과 비교하세요. 해당 타임스탬프와 선택에 사용된 시간대를 확인하세요.
- 병합과 닫힘 구분: 병합 없이 포기된 닫힌 PR이 실수로 병합 섹션에 들어가지 않았는지 확인하세요.
- 병합과 배포 구분: 코드를
main에 병합했다고 해서 자동으로 프로덕션에 배포된 것은 아닙니다. 배포 기록이나 해당 환경으로의 배포를 확인하는 다른 명시적 출처가 없는 한, 실제로 병합된 내용에 요약을 집중하세요. 릴리스 태그만으로는 코드 버전을 식별할 뿐입니다. - 환각 요약 확인: PR 제목이 단순히 “fix typo” 또는 “chore: deps”라면, 에이전트가 정교한 아키텍처 개선을 지어내지 않았는지 확인하세요.
누락된 부분—예를 들어 빠진 PR 설명—을 발견하면 미문서화로 표시된 채로 두세요. 미문서화된 변경 사항을 강조하는 것은 팀이 PR 설명을 개선하는 데 유용한 피드백입니다.
검토된 보고서를 Notion에 추가
초안이 정확해 보이면 Leina에게 지정된 Notion 페이지에 보고서를 작성하도록 지시하세요:
검토된 보고서를
[Notion page URL]의"[repository] — [reporting period]"제목 아래에 추가하세요.
- 먼저 해당 제목이 이미 존재하는지 확인하세요. 존재한다면, 아무것도 수정하기 전에 기존 섹션을 보여주세요.
- 페이지의 다른 모든 기존 콘텐츠를 보존하세요.
- 작성 후, 추가된 섹션을 다시 읽고 Notion 페이지 링크를 반환하세요. 쓰기 결과가 불확실하면 재시도 전에 페이지를 확인하세요. 확인할 수 없다면 알려주세요.
이렇게 하면 문서가 변경되기 전에 검토 지점을 확보할 수 있습니다. 이는 요청하는 워크플로이며, 연결 권한이 Leina가 수행할 수 있는 작업을 결정합니다. 팀과 공유하기 전에 저장된 섹션을 확인하세요.
이 워크플로가 팀에서 원활하게 작동하면 이 프롬프트를 재사용 가능한 Skill로 전환하고 새로운 보고 기간에 동일한 형식을 재사용할 수 있습니다. 팀원에게는 여전히 관련 연결 권한이 필요합니다.