비교 - 운영 포털 조회 표면 vs 쓰기 표면¶
비교 대상¶
- 조회 표면:
/portal/operations/overview,/review,/operators,/policies,/activity처럼 운영 상태를 읽어오는 계약 - 쓰기 표면: triage, resolve, reopen, policy override, operator 수정처럼 실제 상태를 바꾸는 계약
핵심 차이¶
| 항목 | 조회 표면 | 쓰기 표면 |
|---|---|---|
| 강점 | 현황 가시성, 운영 판단 보조, 대시보드와 포털 UX에 적합 | 실제 제어 가능, 상태 수정, 정책 적용과 예외 처리 수행 가능 |
| 약점 | 읽기만 가능해 문제를 직접 해결하지 못함 | 잘못 설계하면 권한 오남용, 감사 복잡도, 데이터 손상 위험이 커짐 |
| 적합한 역할 | 상황 파악, 병목 식별, 우선순위 결정, 운영 모니터링 | triage 조정, 리뷰 해결, 정책 변경, 운영자 관리 |
| 실패 시 위험 | 운영 포털이 보기 좋은 리포트에 그치고 실제 대응으로 이어지지 않음 | 잘못된 쓰기 권한이나 흐름 때문에 운영 일관성과 신뢰가 무너짐 |
이 저장소 맥락에서의 결론¶
Timebooks README는 운영 포털을 먼저 조회 표면으로 정리합니다. 이는 초기 운영 UX에서 "무엇이 일어나고 있는가"를 한눈에 파악하게 만드는 데 우선순위를 둔 것으로 읽을 수 있습니다. 하지만 운영 시스템이 완성되려면 읽기 표면만으로는 부족하고, 리뷰 해결과 정책 조정 같은 쓰기 표면이 명확한 권한과 감사 구조 안에 묶여야 합니다. 즉, 조회 표면은 운영의 관찰 계층이고 쓰기 표면은 운영의 개입 계층입니다.
언제 균형이 깨지는가¶
- 조회 표면만 강조하면 운영 포털이 상태판으로만 남고 실제 조치 흐름이 분리됩니다.
- 쓰기 표면만 강조하면 운영자가 전체 문맥 없이 상태를 바꾸게 되어 실수가 커집니다.
- 가장 좋은 상태는 조회 표면이 판단을 돕고, 쓰기 표면은 그 판단을 안전하게 실행하도록 역할이 나뉘는 것입니다.