일일 업무보고 작성

상사가 보는 것은 상세 내역이 아니라 "오늘 무슨 작업을 얼마나 했는가"다.
진행상황 문서([[progress-log]])는 근거와 판단 과정을 남기지만, 일일보고는 그것을
한눈에 들어오는 개괄로 줄인 것이다. 둘을 혼동해 원인 분석과 수치를 늘어놓으면
읽는 사람이 오늘의 분량을 파악하지 못한다.

서식 (고정)

=========================
업무일:YYYY-MM-DD (요일)
-------------------------
[프로젝트] 진행한 작업

- 작업 내용 1
- 작업 내용 2

기타 특이 사항
-------------------------
[프로젝트] 진행한 작업

- 작업 내용 1
- 작업 내용 2
=========================

• 맨 위·맨 아래는 = 줄, 항목 사이는 - 줄
• 항목 제목은 [프로젝트] 무엇을 했는가 — 프로젝트 태그를 반드시 붙인다
• 불릿은 개괄식. 문장이 아니라 항목으로 끊는다
• 기타 특이 사항은 있을 때만 쓴다. 없으면 그 줄을 통째로 뺀다
  (논의 필요·대기·차단 등 상사의 판단이 필요한 것만)

🔴 프로젝트 태그는 고정 표기를 쓴다

날마다 달라지면 같은 프로젝트로 안 읽힌다. 임의로 바꾸지 않는다.

확정된 태그는 이 스킬 폴더의 기록/프로젝트_태그.md 에 표로 둔다.
사내 표기는 조직 밖에서 의미가 없으므로 스킬 본문이나 공유 저장소에 적지 않는다.

| 프로젝트 | 태그 |
|---|---|
| <프로젝트 이름> | `[<사내 공식 표기>]` |

새 프로젝트의 태그는 사용자에게 확인하고 그 파일에 추가한다.
⚠️ 🔴 표기가 오타로 보여도 사내 공식 표기일 수 있으니 임의로 고치지 말고 물어본다.
실제로 오타로 보이는 표기를 받아 묻지 않고 그대로 쓰지도, 말없이 고치지도 않고 확인했고
오타로 밝혀졌다. 상사에게 나가는 문서라 한 글자가 매일 반복되므로 물어볼 값이었다.

---

1. 오전·오후로 최소 2개 항목

점심시간을 비워서 작성하는 서식이므로 오전 몫과 오후 몫이 각각 있어야 한다.
업무가 아예 없던 날이 아닌 이상 반드시 2개 이상으로 나눈다.

• 오전·오후 작업이 같은 종류여도 나눈다(진행분을 110건 중 70건 → 110건 중 110건 처럼)
• 한쪽에 몰렸거나 점심시간까지 이어진 작업은 적당히 갈라서 배분한다
• 🔴 업무가 실제로 없었던 오전/오후에 작업을 만들어 채우는 것은 사용자가 요청했을 때만 한다.
  요청이 오면 그렇게 쓴다 — 사용자에게 사정이 있는 것이고, 판단할 일이 아니다

2. 항목 수

개수	판정
2~3	일반적
4~5	많은 편, 허용
6	상한
1	업무가 없던 날에 한함

7개 이상이면 잘못 쓴 것이다 — 결과물 단위가 아니라 행동 단위로 쪼갠 것이다.
항목을 가르는 기준은 결과물이다(§3). 결과물이 하나면 거기까지 간 조사·수정·확인은
한 항목의 불릿이지 별개 항목이 아니다.
한 항목에 여러 결과물이 섞여 제목이 A 및 B 처럼 두 겹이 되면 그때 나눈다.

3. 🔴 결과물 기준으로 쓴다 — 과정과 행동은 쓰지 않는다

보고 단위는 "무엇을 만들었나"다. 거기 도달하려고 한 행동이 아니다.
행동을 나열하면 매일 비슷한 말이 반복되고, 상사는 그날 무엇이 남았는지 모른다.

결과물   조사 자료 / 문서 / 지시서 / 동작하는 기능 / 처리한 건수 / 확정된 사양
행동     조사함 · 검토함 · 수정함 · 확인함 · 회신함

🔴 우리 작업 흐름 안에서 오간 것은 결과물이 아니다.
지시하고 → 만들고 → 검토하고 → 고치는 과정은 한 세트로 묶여 하나의 결과물을 낸다.
그 안쪽은 밖에서 볼 일이 아니다.

쓰면 안 되는 것	예
지시서 작성·발행	검사 카메라 작업지시서 발행
결과 검수·승인·회신	구현 결과 검수 및 승인
내부 방향 결정·합의	적용 방향 확정
재실행·재시도 그 자체	치수 2회 수정 후 재실행
도구·역할 이름	작업을 누가·무엇으로 했는지

전부 최종 결과물 한 줄로 합친다. 위 다섯 줄은 실제로는
검사 카메라 적용 — 손목 장착 카메라로 부품 촬영 동작 구현 하나다.

하려던 것·다음에 할 것을 오늘 한 것처럼 쓰지 않는다. 근거는 이 순서로 찾는다.

① 이번 세션의 대화 내용         가장 정확하다
② 프로젝트의 작업내역.md         코드 레벨 완료 로그
③ git log --since=<오늘>         실제로 커밋된 것
④ 진행상황 문서의 오늘자 절

⚠️ 근거 문서는 과정 기록이다. 절 제목을 그대로 옮기면 행동 보고가 된다.
그 절들을 읽고 "그래서 오늘 남은 것이 무엇인가" 를 다시 뽑아야 한다.

실패로 끝난 날도 결과물이 없다고 쓰지 않는다. 원인이 밝혀졌으면 그것이 그날의 결과물이다
— 간섭 원인 규명 처럼 적는다.

4. 짧게

• 불릿 한 줄은 한 호흡에 읽히는 길이로. 수치는 분량을 보여줄 때만
  (110건 중 70건, 약 600컬럼) — 기술 수치(mm, 초)는 넣지 않는다
• 원인·근거·과정은 빼고 결과와 분량만 남긴다

5. 🔴 우리끼리 쓰는 말을 그대로 내보내지 않는다

작업 중에 우리가 붙인 이름은 보고서 밖에서 통하지 않는다. 읽는 사람은 그 대화에 없었으므로
무슨 말인지 알 수 없고, 되물어야 하는 보고서는 실패한 보고서다.

내보내면 안 되는 것	예	풀어 쓰면
단계·차수 약칭	A단계 통과	카메라 거치대 재설계 완료
문서 절 번호	§79 참조	(빼거나 내용을 한 줄로)
커밋 해시·브랜치명	a2425ce	(빼기)
코드 옵션·함수·변수명	--showcase 신설	시연용 간편 실행 모드 추가
사내 축약어·프로젝트 은어	B5 재생	(실제로 한 일로)
영문 약어	IK 모델	로봇 동작 계산 모델

판정 기준: 그 단어를 오늘 처음 보는 사람이 읽어도 무슨 작업인지 짐작되는가.
짐작이 안 되면 우리끼리 쓰는 말이다.

⚠️ 단, 회사 공식 명칭·시스템명·프로젝트 태그는 그대로 쓴다(사내 시스템명·이슈 트래커명 등).
없애야 할 것은 우리가 임의로 붙인 이름이다.

⚠️ 이 검사는 마지막에 따로 한다. 나에게는 그 단어에 이미 뜻이 있어서 전문 용어로
보이지 않는다 — 쓰면서는 눈에 안 띈다.

6. 🔴 제목에 대상을 밝힌다

제목만 읽고 "무엇을" 했는지 알 수 있어야 한다. 서술어만 있고 대상이 빠지면 읽는 사람은
불릿까지 내려가야 뜻을 안다 — 한눈에 보이라고 쓰는 보고서가 아니게 된다.

대상이 빠짐	대상을 밝힘
원인 수정	카메라 장착 방향 오류 수정
오류 사항 수정	적재 쿼리 오류 수정
문서 작성 완료	설비 변경 이력 문서 작성 완료
테스트 진행	이상탐지 모델 정확도 테스트 진행

점검법: 제목에서 수정·조사·작성·확인 같은 서술어를 지웠을 때 남는 말이 있어야
한다. 아무것도 안 남으면 대상이 빠진 것이다.

⚠️ 앞 항목이 문맥을 대신해 주지 않는다. 보고서는 항목마다 따로 읽힌다.
그리고 대상이 같아도 한 일이 다르면 다른 항목이다(조사 / 수정 / 정상화).

7. 🔴 어제 제목과 겹치지 않게 — 일일보고는 이어서 읽힌다

상사는 어제 것을 기억한 채 오늘 것을 본다. 며칠에 걸친 작업이라고 제목까지 같으면
"이거 저번에 한 거 아닌가" 가 되고 진척이 없어 보인다.

✗  9/2 검사 카메라 작업     9/3 검사 카메라 작업     9/4 검사 카메라 작업
○  9/2 검사 카메라 선정     9/3 카메라 장착부 설계   9/4 촬영 동작 구현

여러 날치를 한 번에 쓸 때는 제목을 세로로 훑어본다 — 위에서 아래로 읽어 작업이
나아가는 것이 보여야 한다. 같은 말이 두 번 나오면 뒤엣것을 고친다.
진행률이 있으면 그것이 가장 좋은 구분이다(110건 중 70건 → 110건 완료).

🔴 지난 제목은 기억나지 않는다 — 파일로 확인한다. 제출한 보고는 이 스킬 폴더의
기록/YYYY-MM-DD_주간.md 에 남긴다(맨 앞에 제목만 세로로 모아 둔다).
새 보고를 쓰기 전 가장 최근 기록의 제목 목록부터 읽는다. 세션이 바뀌면 지난주에 무슨
제목으로 냈는지 알 방법이 이것뿐이다.

🔴 제출과 기록은 같은 턴에 한다. 미루면 절차 0번이 한 주 비어 버린다.

8. 🔴 주간계획을 함께 낸다 — 상세설명란에

일일보고에는 차주 계획이 같이 들어간다.

위치    제출 양식의 상세설명란     🔴 코멘트가 아니다
시점    제출 전                  제출하고 나면 수정이 안 된다
대상    다음 주에 할 일           이번 주 한 일이 아니다

주 단위 보고를 낼 때(보통 금요일, 또는 주간분을 한 번에 낼 때) 반드시 함께 뽑는다.
본문과 같은 원칙(개괄식·결과물 기준·내부 용어 없이)을 쓰되, 아직 하지 않은 일이므로
"무엇을 만들 것인가" 로 적는다.

[프로젝트A] 이상탐지 모델 조건별 비교 자료 보완
[프로젝트A] 시뮬레이션 컨베이어 구간 설계 자료 작성

⚠️ 분량은 일일보고보다 짧다. 2~4줄이면 족하다. 날짜별로 쪼개지 않는다.

🔴 제출 양식에는 일일 항목 말고도 칸이 있다. 양식 전체를 채우는지 확인한다.
이 절이 없던 때 주간계획을 통째로 빠뜨렸고, 제출한 뒤에는 고칠 수 없었다.

---

절차

0. 🔴 기록/ 의 최근 파일에서 지난 제목 목록을 먼저 읽는다                     §7
1. 오늘 한 일을 시간 순으로 나열한다                                        §3 근거 순서
2. 🔴 각각에 "그래서 남은 결과물이 무엇인가"를 적고, 같은 결과물끼리 묶어
   2~5개 항목으로 만든다 (행동 단위로 쪼개지 않는다)                        §2 §3
3. 오전 몫 / 오후 몫으로 배분한다                                          §1
4. 각 항목에 [프로젝트] 태그와 제목을 붙이고 불릿 2~4개로 줄인다
5. 상사의 판단이 필요한 것만 「기타 특이 사항」에 한 줄로
5-B. 🔴 주 단위로 낼 때는 주간계획을 함께 뽑아 상세설명란에 넣는다            §8
6. 🔴 완성한 문장을 §3·§5·§6·§7 로 한 번 훑는다 — 과정·검수·지시가 남았는지,
   내부 용어가 없는지, 제목마다 대상이 있고 앞날과 겹치지 않는지            (쓰면서는 안 보인다)
7. 서식대로 출력한다 — 코드 블록으로 감싸서 그대로 복사할 수 있게
8. 🔴 제출한 원문을 기록/YYYY-MM-DD_주간.md 에 남긴다 (제목만 세로로 모은 목록 포함)

하지 않는 것

• 진행상황 문서의 절 제목을 그대로 옮기지 않는다 — 그건 과정 기록이다(§3)
• 누가·무엇으로 했는지 쓰지 않는다. 담당자 본인의 보고이므로 주체는 자명하고,
  작업 도구·역할 분담은 보고 대상이 아니다
• 원인 분석·기술적 판단을 넣지 않는다 — 물어보면 그때 답한다
• "예정", "계획" 을 항목으로 세우지 않는다 — 특이 사항 한 줄이면 족하다
• 자화자찬·난이도 호소를 넣지 않는다
• 🔴 주간계획을 일일보고 본문이나 코멘트에 쓰지 않는다 — 자리는 상세설명란이다(§8)

⏳ 듣다 만 피드백은 추측으로 메우지 않는다

사용자가 "개선의 여지가 보이는데 일단 여기서 마무리하자" 류로 말하고 무엇이 걸렸는지는
말하지 않는 일이 있다. 그때가 가장 고치고 싶어지는 순간이다.

🔴 임의로 추측해 고치지 마라. 엉뚱한 곳을 고쳐 놓고 반영했다고 여기게 된다.
다음에 보고를 쓸 때 먼저 물어보고, 받은 답을 기록/ 에 남긴다.

아직 답을 못 받은 항목이 있다면 그것은 이 스킬이 아니라 설치처의 기록/ 에 적는다.
스킬 본문은 규칙의 자리이고, 특정 시점의 미해결 상태는 그 조직의 기록이다.

예시

=========================
업무일:YYYY-MM-DD (수)
-------------------------
[프로젝트A] 스키마 변경 작업 및 변경사항 문서 작성 완료

- 약 600컬럼의 스키마 변경 추가 진행
- 변경 내역 문서 이슈 트래커 등록 진행
-------------------------
[프로젝트A] 적재 쿼리 변경

- 스키마 변경에 따른 적재 쿼리 수정
- 110건중 70건 진행 완료

추가로 생긴 테이블에 대한 적재 방향성 논의 필요
=========================

연계

• 근거가 되는 상세 기록은 [[progress-log]] · 각 프로젝트의 작업내역.md
• 주간 단위로 묶을 때도 같은 원칙(개괄·분량 중심)을 요일별로 적용한다

이력 (필수 기록)

• 생성일: 2026-09-04
• 업데이트 횟수: 6
• 최근 업데이트: 2026-09-15 (사용 이력의 교훈을 본문으로 승격, 미해결 항목을 이력 밖으로 꺼냄)
• 사용 이력 — 교훈은 전부 본문에 반영됐다.
  • 2026-09-15 — 공용 저장소로 이관하며 일반화(사내 표기·업무 예시·직함을 걷어냄) + 이력 66줄 압축. 🔴 이력에만 묻혀 있던 미해결 항목(사용자가 말하지 않은
    개선 여지 — 다음에 먼저 물을 것)을 본문 §미해결로 꺼냈다. 이력에 두면 보고를 쓸 때 안 읽힌다.
    원본은 SKILL.md.bak_20260915
  • 2026-09-11 — 🔴 주간계획 누락으로 지적받음("코멘트 말고 상세설명에 주간계획 추가해 주세요").
    이미 제출돼 수정 불가 → §8 신설, 절차 5-B 추가. 양식의 다른 칸을 아예 보지 않은 것이 원인
  • 2026-09-04 — 프로젝트 태그 표기를 확정(오타로 보였으나 확인 후 결정). 표는 로컬 기록/ 로 분리
  • 2026-09-04 — 주간 5일치에서 가장 큰 결함 발견: 항목이 지시서 발행·결과 검수 처럼
    우리 작업 흐름 안의 행동으로 채워져 있었다(원인: 진행 문서의 절 제목을 그대로 옮김).
    사용자 지적 "지시하고 만들고 검토하는 것은 한 세트" → §3 을 결과물 기준으로 재정립,
    §7(제목 겹침) 추가. 이때 구 §2 "조사→수정→확인은 나눈다"는 행동 단위여서 폐기
  • 2026-09-04 — 제목에 대상이 없어 지적(원인 수정 및 …) → §6 신설
  • 2026-09-04 — 첫 출력에서 A단계 통과 를 그대로 써 지적 → §5 신설, 절차 6번(최종 점검) 추가
  • 2026-09-04 — 신규 생성. 사용자가 회사 제출용 서식과 규칙을 직접 제시