블로그 AI 작성 기본 지침

이 저장소에서 게시글을 작성·수정할 때는 기존 글의 문체와 Markdown 규칙을 우선 따른다. 독자는 한국어를 사용하는 개발자이며, 목적은 검색 노출용 문장 생산이 아니라 실제 문제 해결에 도움이 되는 기술 기록을 만드는 것이다.

최우선: AI 말투 금지

사람이 직접 겪고 검증하며 쓴 기술 글처럼 작성한다. 과도하게 친절하거나 결론을 반복하는 AI식 문장을 쓰지 않는다.

“물론”, “좋은 질문”, “도움이 되었으면”, “살펴보자”, “알아보자”, “정리하면” 같은 관용적 도입·마무리를 남발하지 않는다.
“~할 수 있습니다”, “~하는 것이 중요합니다”, “~를 권장합니다”만 반복하지 않는다. 무엇을, 왜, 어떤 조건에서 해야 하는지 단정적으로 쓴다.
근거 없는 평가어(“강력한”, “최적의”, “완벽한”, “획기적인”)를 쓰지 않는다.
독자에게 말을 거는 표현(“여러분”, “당신”, “쉽게”, “간단히”)보다 기술 대상과 조건을 주어로 쓴다.
같은 내용을 요약·재진술해 분량을 늘리지 않는다.
AI가 답변하는 형식의 인사, 사과, 후속 제안, 체크리스트성 마무리를 넣지 않는다.

좋은 예:

sync = true는 동일 키의 동시 Cache Miss를 한 인스턴스 안에서 직렬화한다.

피할 예:

sync = true를 사용하면 캐시 성능을 효과적으로 개선할 수 있습니다. 이제 이 옵션을 자세히 알아보겠습니다.

동작 범위, 버전, 실행 환경을 분명히 쓴다. 예: 단일 인스턴스인지, Redis Cluster인지, Spring Data Redis 버전이 무엇인지.
장점만 쓰지 말고 실패 조건, 비용, 대안이 필요한 경계를 함께 쓴다.
확인하지 못한 사실을 단정하지 않는다. 추측은 추측이라고 표시하거나 검증 방법을 적는다.
외부 문서나 코드에서 가져온 내용은 출처를 링크하고, 긴 원문 인용 대신 맥락에 맞게 요약한다.
코드 예시는 컴파일 또는 실행 가능성을 확인한다. 의사 코드는 의사 코드임을 표시한다.

시스템 아키텍처, 요청 흐름, 처리 루프처럼 여러 구성 요소의 관계를 보여주는 도표는 본문 ASCII 박스나 화살표로 그리지 말고 별도 이미지로 만든다.
구조도 이미지는 images/{category}/ 아래에 저장하고, 글에서는 절대 경로 Markdown 이미지와 설명 캡션을 사용한다. 예: ![Spring 요청 흐름](/images/spring/request-flow.svg){: .align-center}
구조도는 SVG를 우선한다. 텍스트, 화살표, 박스의 선명도와 수정 가능성이 중요하기 때문이다. 사진·일러스트처럼 래스터 이미지가 필요한 경우에만 PNG 또는 JPG를 사용한다.
이미지 안의 용어, 버전, 포트, 프로토콜, 방향은 본문 설명과 일치시킨다. 확인하지 못한 구성 요소나 성능 수치를 이미지에 넣지 않는다.
이미지에는 핵심 관계만 남긴다. 세부 설정, 복사할 코드, 디렉터리 트리는 이미지로 옮기지 않고 본문 코드 블록이나 표로 유지한다.
새 구조도를 추가하거나 기존 ASCII 도표를 교체할 때는 대체 텍스트와 한 줄 캡션을 함께 작성한다. 캡션은 이미지 내용을 반복하지 말고 도표가 설명하는 범위를 적는다.
기존 이미지 경로와 파일명을 수정 요청 없이 바꾸지 않는다. 새 이미지가 필요하면 기존 파일을 덮어쓰지 말고 목적이 드러나는 새 이름을 사용한다.