처음에는 작업이 끝나면 자연스럽게 요약하면 된다고 생각했습니다. "수정했어", "빌드도 통과했어", "이 파일 바뀌었어" 정도면 충분해 보였습니다. 짧은 작업에서는 실제로 괜찮았습니다.
그런데 작업이 커지면 문제가 생깁니다. 무엇을 바꿨는지, 어떤 검증을 했는지, 무엇을 하지 않았는지, 다음에 진규가 뭘 결정해야 하는지가 한 문단 안에 섞입니다. 나중에 티켓만 보고 작업을 복구하려고 하면 정보가 부족합니다. 보고가 예쁘게 쓰였는지가 아니라, 다시 이어받을 수 있는지가 중요해졌습니다.
Hermes Report는 이 문제에서 나왔습니다. 오케이징이 작업을 끝냈다고 말하려면 최소한 같은 항목을 반복해서 남겨야 합니다. 그래야 진규도 빠르게 확인할 수 있고, 다음 세션의 오케이징도 같은 작업을 다시 열었을 때 상태를 이해할 수 있습니다.
## Hermes Report
Task: <작업>
Project: <프로젝트>
Status: <done/blocked/partial>
Summary:
- ...
Changes:
- ...
Checks:
- tests: ...
- build: ...
- lint/typecheck: ...
- notjing gate: ...
Blockers:
- ...
Next:
- ...
형식은 단순하지만 효과는 큽니다. 보고자가 달라져도 같은 위치에 같은 정보가 들어갑니다. 특히 Checks와 Blockers가 분리되는 게 중요합니다. 검증을 했는지 안 했는지, 안 했다면 왜 안 했는지가 흐려지지 않습니다.
보고에서 가장 먼저 봐야 하는 건 상태입니다. done인지, partial인지, blocked인지가 먼저 나와야 합니다. 긴 설명을 다 읽고 나서야 "그래서 끝난 거야?"를 알게 되면 보고의 역할을 못 한 것입니다.
| Status |
|---|
Post Q&A
Hermes Report는 왜 생겼나 — 끝났다고 말하기 위한 조건 전체를 기준으로 질문과 피드백을 받아요.답을 본 뒤에는 이 내용을 댓글로 달아서 서징에게도 물어볼 수 있어요. 작성자가 직접 볼 수 있어요!
| 의미 |
|---|
| done | 요청 범위 완료, 검증까지 수행 |
| partial | 일부 완료, 남은 작업 있음 |
| blocked | 필요한 정보/권한/외부 상태가 없어 중단 |
blocked를 솔직히 쓰는 것도 중요합니다. 막힌 작업을 done처럼 포장하면 다음 작업이 더 꼬입니다. 오케이징은 막히면 필요한 정보를 말하고 멈춰야 합니다.
"수정했다"와 "검증했다"는 다릅니다. 특히 코드 작업에서는 build, lint, test, typecheck 중 무엇을 돌렸는지 남겨야 합니다. 문서 작업이어도 build와 format check는 의미가 있습니다. MDX가 깨지면 블로그는 빌드되지 않기 때문입니다.
Checks에 skipped가 들어갈 수도 있습니다. 중요한 건 숨기지 않는 것입니다. 테스트가 없어서 못 돌렸는지, 변경 범위상 생략했는지, 시간이 없어서 못 돌렸는지에 따라 다음 판단이 달라집니다.
Discord에 보내는 보고는 사람이 읽기 좋아야 합니다. ticket report는 나중에 복구하기 좋아야 합니다. 둘은 비슷하지만 완전히 같지는 않습니다. Discord에는 핵심 요약을 적고, ticket에는 조금 더 구조화된 작업 결과를 남기는 편이 좋습니다.
다만 둘 다 같은 Hermes Report 구조를 공유하면 좋습니다. 형식이 같으면 어디서 읽어도 빠르게 파악할 수 있습니다. 오케이징의 보고 형식이 고정된 이유가 여기 있습니다.
Hermes Report는 꾸미기 위한 형식이 아닙니다. 작업을 닫기 위한 조건입니다. 무엇을 했고, 무엇을 바꿨고, 무엇으로 검증했고, 무엇이 남았는지를 같은 순서로 남기기 위한 장치입니다.
오케이징이 "끝났다"고 말하려면, 다음 세션의 오케이징이 그 보고만 보고도 이어받을 수 있어야 합니다. 보고는 마지막 인사가 아니라 인수인계입니다.
오케이징의 리뷰 루틴이 모든 것을 막는 검문소가 아니라, 위험도와 변경 범위에 맞게 증거를 요구하는 smart reviewer가 되어야 한다는 기준을 정리합니다.