79 lines (54 loc) · 2.71 KB

블로그 품질 가이드

브랜드 문장

새로운 비즈니스 확장으로 복잡해지는 내부 시스템을 정리하고, 레거시를 구조적으로 개선하는 플랫폼 엔지니어

기본 원칙

기술 글은 감상보다 판단 기준이 먼저 보여야 한다.
구현 자랑보다 문제 정의와 대안 비교가 먼저 나와야 한다.
글 하나가 읽히고 끝나면 안 된다. 같은 문제를 다시 만났을 때 재사용 가능한 기준이 남아야 한다.
공개 글은 포트폴리오다. 초안이나 메모 수준의 글은 private로 둔다.

기술 글 톤

기본 문체는 단정형 하다체로 쓴다.
도입과 마무리만 제한적으로 부드럽게 쓸 수 있다.
"배웠다", "느꼈다"는 문장만으로 끝내지 않는다. 무엇이 바뀌었는지까지 적는다.
추상 표현 대신 수치, 조건, 실패 사례를 우선한다.

공개용 엔지니어링 글 템플릿

1. 문제와 비즈니스 맥락

왜 이 문제가 운영 또는 비즈니스 비용으로 이어졌는가
누가 이 결과를 소비하는가

2. 시스템 요구사항과 제약

성능, 정확성, 복구, 운영 조건
리소스 한계나 조직 제약

3. 대안 비교와 선택 근거

실제로 검토한 대안 2개 이상
버린 대안과 이유

4. 실제 아키텍처와 구현

데이터 흐름
핵심 상태 모델
중요한 설정값과 선택 이유

5. 실패와 수정

장애, 병목, 잘못된 가정
어떻게 관측했고 어떻게 수정했는가

6. 검증과 결과

단위 테스트
통합 테스트
운영 확인 방식
수치 결과

7. 재사용 가능한 판단 기준

다음에도 그대로 가져갈 기준
아직 남은 한계

공개 정책

visibility 기본값은 public이다.
시리즈는 기본적으로 공개 자산이 아니라 학습 자산으로 보고, 공개 필요성이 생기기 전까지 private로 둔다.
엔지니어링 글은 philosophy, design, implementation 평균이 3.0 이하이면 private로 둔다.
featured는 아래 조건을 모두 만족할 때만 허용한다.
- 엔지니어링 글
- 시리즈 아님
- brandFit >= 4.0
featured는 점수만으로 자동 결정하지 않는다. 현재 단계에서는 수동 큐레이션 목록으로 관리한다.

리뷰 체크리스트

첫 세 문단 안에 문제와 비용이 드러나는가
대안 비교가 실제로 존재하는가
설정값과 구조가 왜 그렇게 됐는지 설명하는가
장애 또는 실패 장면이 포함되어 있는가
결과가 수치 또는 운영 변화로 확인되는가
읽고 나면 한 문장으로 재사용 가능한 기준이 남는가