프로젝트 기록을 어떻게 남길 것인가

상황

이 블로그는 완성된 튜토리얼을 모으기보다, 실제 프로젝트를 만들고 운영하면서 배운 점을 기록하기 위해 시작한다.

좋은 기록은 나중에 다시 읽었을 때 바로 쓸 수 있어야 한다. 그래서 글마다 문제 상황, 확인한 증거, 판단 과정, 다음에 반복하지 않을 기준을 남긴다.

글의 기본 구조

앞으로 프로젝트 기록은 가능하면 아래 흐름을 따른다.

## 상황

## 문제

## 처음 생각한 가설

## 확인한 증거

## 해결한 방식

## 배운 점

## 다음에는 이렇게 할 것

공개 기준

프로젝트 기록을 공개할 때는 실제 맥락을 남기되, 공개하면 안 되는 정보는 제거한다.

• 토큰, 계정, 내부 URL, 고객명은 쓰지 않는다.
• 장애나 비용 기록은 원인과 판단 기준 중심으로 정리한다.
• 코드 조각은 문제를 설명하는 데 필요한 만큼만 남긴다.
• 추측과 확인된 사실을 구분한다.

태그 기준

태그는 나중에 다시 찾기 쉬운 단어로 붙인다.

• debugging
• deployment
• analytics
• frontend
• backend
• infra
• product
• retrospective

첫 운영 원칙

길게 쓰려고 미루지 않는다. 한 프로젝트에서 하나만 배워도 글 하나로 남긴다.