주간 업무 보고 작성 규칙
작업 목록 나열을 막고 '무엇이 가능해졌는지'와 '막힌 것'을 반드시 쓰게 하는 주간보고 규칙.
내 환경에 맞게 만들기
무엇을 하는 규칙인가
이 규칙을 쓰는 이유
주간보고를 AI에게 맡기면 대개 **작업 목록**이 나온다. "A 기능 개발, B 버그 수정, C 회의 참석" 같은 나열은 쓴 사람도 읽는 사람도 얻는 것이 없다. 읽는 사람이 알고 싶은 것은 세 가지다. 무엇이 달라졌는지, 다음에 무엇이 오는지, 도와줄 일이 있는지. 아래 규칙은 그 세 가지가 빠지지 않게 만드는 것이 목적이다.
섹션 순서
이 순서를 바꾸지 않는다. 1. **이번 주에 달라진 것** 2. **다음 주에 할 것** 3. **막힌 것 / 도움이 필요한 것** 3번을 마지막에 두는 이유는 읽는 사람이 가장 오래 기억하는 자리이기 때문이다. 3번이 비면 "없음"이라고 쓰지 말고 **왜 없는지** 한 줄로 쓴다. 정말 없는 주는 드물다.
완료는 작업명이 아니라 결과로 쓴다
작업명을 그대로 옮기지 않는다. **그 일이 끝나서 무엇이 가능해졌는지**를 쓴다. - 이렇게 쓰지 않는다: `로그인 API 개발 완료` - 이렇게 쓴다: `외부 계정으로 로그인할 수 있게 됐다. 기존 가입자는 다음 로그인 때 자동 연결된다.` 두 번째 문장이 있어야 읽는 사람이 판단할 수 있다. 판단할 수 없는 문장은 보고가 아니라 기록이다.
수치는 근거와 함께 쓴다
진행률을 단독으로 쓰지 않는다. `70% 완료`는 정보가 아니다. **무엇이 끝났고 무엇이 남았는지**로 바꿔 쓴다. - 이렇게 쓰지 않는다: `마이그레이션 70% 진행` - 이렇게 쓴다: `전체 12개 테이블 중 8개를 옮겼다. 남은 4개는 외부 연동이 걸려 있어 다음 주에 순서를 정한다.` 숫자를 쓸 때는 **분모를 함께** 쓴다. 분모 없는 숫자는 해석할 수 없다.
막힌 것은 상태와 요청을 분리한다
막힌 것을 쓸 때 상태만 쓰고 끝내지 않는다. **무엇을 해주면 풀리는지**를 붙인다. - 이렇게 쓰지 않는다: `외부 API 문서가 부실해서 진행이 어렵다.` - 이렇게 쓴다: `외부 API 문서에 오류 코드 목록이 없다. 담당자 연락처를 알려주시면 직접 문의하겠다.` 요청이 없는 막힘은 읽는 사람이 도울 방법을 모른다.
분량과 톤
- 전체 **한 화면 안에** 들어가게 쓴다. 스크롤이 필요하면 항목을 합치거나 덜 중요한 것을 뺀다. - 평서 존댓말로 쓴다. 감탄사·느낌표를 쓰지 않는다. - 잘한 일을 강조하는 수식어를 붙이지 않는다. 사실만 쓰면 판단은 읽는 사람이 한다. - 확실하지 않은 것은 **확실하지 않다고 쓴다**. "아마 다음 주에 끝날 것 같다"는 "다음 주 완료 예정이나 외부 검토 일정에 따라 밀릴 수 있다"로 쓴다.
쓰기 전에 확인할 것
- 1·2·3번 섹션이 모두 있는가 - 완료 항목이 작업명 나열이 아니라 결과로 쓰였는가 - 숫자에 분모가 붙어 있는가 - 막힌 항목에 요청이 붙어 있는가 - 한 화면에 들어가는가 흔히 나오는 실패 예시는 `bad-examples.md`에 정리해 두었다. 처음 몇 번은 그것과 비교해 보면 빠르다.
원문 전문
넣기 전에 전부 읽어보실 수 있습니다. 이 파일은 AI에게 지시를 주는 문서입니다. 내용을 확인하고 넣으세요.
item.md
## 이 규칙을 쓰는 이유 주간보고를 AI에게 맡기면 대개 **작업 목록**이 나온다. "A 기능 개발, B 버그 수정, C 회의 참석" 같은 나열은 쓴 사람도 읽는 사람도 얻는 것이 없다. 읽는 사람이 알고 싶은 것은 세 가지다. 무엇이 달라졌는지, 다음에 무엇이 오는지, 도와줄 일이 있는지. 아래 규칙은 그 세 가지가 빠지지 않게 만드는 것이 목적이다. ## 섹션 순서 이 순서를 바꾸지 않는다. 1. **이번 주에 달라진 것** 2. **다음 주에 할 것** 3. **막힌 것 / 도움이 필요한 것** 3번을 마지막에 두는 이유는 읽는 사람이 가장 오래 기억하는 자리이기 때문이다. 3번이 비면 "없음"이라고 쓰지 말고 **왜 없는지** 한 줄로 쓴다. 정말 없는 주는 드물다. ## 완료는 작업명이 아니라 결과로 쓴다 작업명을 그대로 옮기지 않는다. **그 일이 끝나서 무엇이 가능해졌는지**를 쓴다. - 이렇게 쓰지 않는다: `로그인 API 개발 완료` - 이렇게 쓴다: `외부 계정으로 로그인할 수 있게 됐다. 기존 가입자는 다음 로그인 때 자동 연결된다.` 두 번째 문장이 있어야 읽는 사람이 판단할 수 있다. 판단할 수 없는 문장은 보고가 아니라 기록이다. ## 수치는 근거와 함께 쓴다 진행률을 단독으로 쓰지 않는다. `70% 완료`는 정보가 아니다. **무엇이 끝났고 무엇이 남았는지**로 바꿔 쓴다. - 이렇게 쓰지 않는다: `마이그레이션 70% 진행` - 이렇게 쓴다: `전체 12개 테이블 중 8개를 옮겼다. 남은 4개는 외부 연동이 걸려 있어 다음 주에 순서를 정한다.` 숫자를 쓸 때는 **분모를 함께** 쓴다. 분모 없는 숫자는 해석할 수 없다. ## 막힌 것은 상태와 요청을 분리한다 막힌 것을 쓸 때 상태만 쓰고 끝내지 않는다. **무엇을 해주면 풀리는지**를 붙인다. - 이렇게 쓰지 않는다: `외부 API 문서가 부실해서 진행이 어렵다.` - 이렇게 쓴다: `외부 API 문서에 오류 코드 목록이 없다. 담당자 연락처를 알려주시면 직접 문의하겠다.` 요청이 없는 막힘은 읽는 사람이 도울 방법을 모른다. ## 분량과 톤 - 전체 **한 화면 안에** 들어가게 쓴다. 스크롤이 필요하면 항목을 합치거나 덜 중요한 것을 뺀다. - 평서 존댓말로 쓴다. 감탄사·느낌표를 쓰지 않는다. - 잘한 일을 강조하는 수식어를 붙이지 않는다. 사실만 쓰면 판단은 읽는 사람이 한다. - 확실하지 않은 것은 **확실하지 않다고 쓴다**. "아마 다음 주에 끝날 것 같다"는 "다음 주 완료 예정이나 외부 검토 일정에 따라 밀릴 수 있다"로 쓴다. ## 쓰기 전에 확인할 것 - 1·2·3번 섹션이 모두 있는가 - 완료 항목이 작업명 나열이 아니라 결과로 쓰였는가 - 숫자에 분모가 붙어 있는가 - 막힌 항목에 요청이 붙어 있는가 - 한 화면에 들어가는가 흔히 나오는 실패 예시는 `bad-examples.md`에 정리해 두었다. 처음 몇 번은 그것과 비교해 보면 빠르다.
references/bad-examples.md
# 흔한 실패 예시와 교정 주간보고에서 반복적으로 나오는 네 가지 패턴이다. 왼쪽이 자주 나오는 문장, 오른쪽이 교정이다. ## 1. 작업 목록 나열 **자주 나오는 것** > 이번 주 작업 내역 > - 결제 모듈 개발 > - 로그인 버그 수정 > - 스프린트 회의 참석 읽는 사람이 얻는 것이 없다. 무엇이 달라졌는지 알 수 없고, 회의 참석은 결과가 아니다. **교정** > 카드 결제가 실제로 동작한다. 테스트 계정으로 승인·취소까지 확인했다. > 로그인 후 첫 화면이 비어 보이던 문제를 고쳤다. 원인은 캐시 만료 처리였고 같은 원인의 다른 화면 두 곳도 함께 고쳤다. 회의 참석은 결과가 없으면 쓰지 않는다. 회의에서 결정된 것이 있으면 그 결정을 쓴다. ## 2. 분모 없는 숫자 **자주 나오는 것** > 테스트 커버리지 개선 작업 80% 완료 80%가 무엇의 80%인지 알 수 없다. 남은 20%가 쉬운지 어려운지도 알 수 없다. **교정** > 핵심 모듈 5개 중 4개에 테스트를 붙였다. 남은 하나는 외부 결제사 응답을 흉내내야 해서 시간이 더 걸린다. ## 3. 요청 없는 막힘 **자주 나오는 것** > 디자인 시안이 아직 안 와서 화면 작업을 못 하고 있습니다. 읽는 사람은 이 문장을 읽고 무엇을 해야 할지 모른다. 상태 보고로 끝났다. **교정** > 목록 화면 시안을 기다리고 있다. 이번 주 안에 오지 않으면 임시 레이아웃으로 먼저 만들고 나중에 맞추려 한다. 그렇게 진행해도 괜찮은지 알려주시면 좋겠다. 막힘에는 **내가 생각한 대안**과 **필요한 결정**이 함께 있어야 한다. ## 4. 수식어로 채운 문장 **자주 나오는 것** > 매우 성공적으로 마이그레이션을 완료했으며, 큰 문제 없이 안정적으로 운영되고 있습니다! "매우", "성공적으로", "큰 문제 없이", "안정적으로"가 모두 판단이다. 근거가 없으면 읽는 사람은 이 판단을 검증할 수 없다. **교정** > 마이그레이션을 끝냈다. 이후 사흘간 오류 로그에 관련 항목이 없었고 응답 시간도 이전과 같은 수준이다. 같은 내용이지만 이쪽은 읽는 사람이 판단할 수 있다. 사실을 쓰고 판단은 넘긴다. ## 확인 순서 작성 후 위에서부터 훑으며 네 가지를 본다. 1. 작업명만 있는 항목이 있는가 2. 분모 없는 숫자가 있는가 3. 요청 없는 막힘이 있는가 4. 근거 없는 수식어가 있는가 하나라도 걸리면 그 문장만 고친다. 전체를 다시 쓸 필요는 없다.