블로그 글 작성 규칙

이 문서는 이 블로그의 기존 어투와 설명 방식을 AI가 글 작성·수정에 적용하기 위한 규칙이다. 반말 몇 개를 끼워 넣는 것보다, 의문이 생긴 지점에서 실제 동작과 판단 근거를 따라가는 흐름을 우선한다.

분석 범위와 사용 기준

대상: _posts의 2020-01-01 첫 글부터 2024-12-12까지, 파일명 기준 101개 글.
전체 파일의 본문 발췌와 도입·마무리를 확인하고, 직접 작성한 분석·문제 해결 글은 본문을 더 살펴 특징을 추렸다. 글마다 같은 비중으로 문체를 평균내지는 않았다.
현재 저장소의 파일을 기준으로 했다. 과거 게시 당시 버전을 복원한 분석은 아니며, 본문에 나중에 추가된 링크가 있을 수 있다.
2025년 이후 글은 문체의 기준에서 제외한다. 기존 글을 고칠 때는 수정 대상의 기술 내용과 작성 의도를 별도로 참고한다.
Jekyll 기본 예제, 테스트 글, 외부 논문 발췌, 과제 명세 번역은 저자의 어투를 판단하는 주된 근거로 쓰지 않는다. 강의 메모는 메모형 글의 구성에만 참고한다.
관찰한 특징을 아래에 규칙으로 정리했다. 문단 길이나 강조 횟수에 기계적인 할당량을 두지는 않는다.

1. 기본 목소리

기본은 개발자가 공부하거나 코드를 만지며 이해한 내용을 풀어쓰는 평서체다. 독자를 가르치는 강사나 제품을 소개하는 사람처럼 쓰지 않는다.

설명은 ~이다, ~한다, ~된다, ~인 셈이다로 쓴다.
판단이나 아직 확인하지 못한 부분은 ~같다, ~라고 생각한다, ~일 수도 있다로 사실과 구분한다. 확실한 사실까지 전부 흐리지 않는다.
근데, 그럼, 사실, 이때, 결국 같은 연결어를 문맥에 맞게 쓴다. 매 문단 앞에 억지로 붙이지 않는다.
얘, 요거, 그냥, 귀찮다, 생각해보자 같은 구어는 대상과 이유가 분명할 때 자연스럽게 허용한다.
굉장히, 진짜, 꽤나가 기존 글에 보이지만, 이것들을 반복한다고 같은 어투가 되지는 않는다. 구체적인 설명을 먼저 쓴다.
;;, -_-;, .. 같은 표정이나 감탄은 필수가 아니다. 거친 표현과 자조도 원문의 맥락 없이 새로 만들지 않는다.
존댓말 글도 일부 있지만 일반 기술 분석 글의 기본은 평서체로 잡는다. 원문이 존댓말인 경우에는 그 글의 말투를 우선한다.

2. 시작은 다룰 문제부터

분야의 중요성을 소개하거나 “이번 글에서는 알아보겠습니다”로 예고하지 않는다. 무슨 상황에서 어떤 부분이 궁금하거나 불편한지를 바로 보여준다.

쓸 수 있는 출발점:

코드나 도구를 사용하다 예상과 달랐던 동작.
익숙한 설명에서 빠져 있는 조건.
구현을 보면 궁금해지는 구조나 비용.
나중에 다시 보기 위해 정리할 필요가 있는 내용.

실제로 겪은 일을 전달받지 않았다면 “회사에서 문제가 터졌다”, “직접 돌려봤다”, “반나절 걸렸다”처럼 경험을 만들어내지 않는다. 이런 경우 개념의 의문이나 구체적인 가정에서 시작한다.

3. 설명은 동작을 따라간다

원리의 이름과 장단점을 나열하고 끝내지 않는다. 독자가 다음 결과를 따라갈 수 있도록 원인과 동작을 잇는다.

어떤 상황이나 입력을 생각하고 있는지 잡는다.
코드·메모리·함수 호출·파일에서 실제로 무엇이 일어나는지 설명한다.
그 동작 때문에 어떤 결과나 비용이 생기는지 연결한다.
해결 방법을 설명할 때는 바뀌는 동작과 적용 조건을 같이 적는다.

이 순서는 설명을 점검하는 기준이지 모든 글의 고정 목차가 아니다. 짧은 팁은 필요한 부분만 쓰고, 실습기는 실제 시도 순서로 풀어도 된다.

“성능이 떨어진다”만 쓰기보다 어느 할당, 복사, 접근, 대기에서 비용이 생기는지 쓴다. 숫자나 작은 상황을 가정하면 이해가 쉬운 경우 파일 5000개 중 1개를 바꾼다면처럼 구체화한다. 가정한 숫자를 측정값처럼 제시하지 않는다.

4. 질문과 개인 의견의 역할

질문은 설명의 분기점에 쓴다. 예: “그럼 삽입할 위치를 찾는 비용은 어디로 갔을까?”
질문을 계속 던져 분위기만 만들지 않는다. 질문 뒤에는 실제 근거나 동작 설명이 따라와야 한다.
개인 의견은 이유를 붙인다. “불편하다”면 타이핑, 디버깅, 호출 단계 등 어디가 불편한지 적는다.
자료에서 확인한 내용, 직접 관찰한 결과, 추측을 구분한다. 불확실한 부분을 저자의 확신으로 바꾸지 않는다.
기존 글의 강한 표현이나 옛 기술 설명을 기술적 정답의 근거로 쓰지 않는다. 문체와 사실 검증은 별개다.

5. 문단과 글의 모양

한 가지 동작이나 생각을 짧은 문단으로 풀고, 다음 단계로 넘어갈 때 빈 줄을 둔다.
문장이 조금 길어져도 인과관계가 읽히면 괜찮다. 반대로 원문의 잦은 줄바꿈을 한 문장 한 줄 규칙으로 복제하지 않는다.
소제목은 실제 대상이나 작업을 붙인다. 메모리 할당, 중간 삭제, const를 붙일 때처럼 본문의 내용을 가리킨다.
핵심 인사이트, 압도적인 장점, 완벽한 해결책 같은 홍보성 제목은 피한다.
목록은 명령어, 서로 독립적인 조건, 여러 해결 방법에 쓴다. 인과관계를 설명하는 본문까지 전부 목록으로 바꾸지 않는다.
표는 같은 기준으로 비교할 내용이 있을 때만 쓴다. 표에 담기지 않는 전제는 바로 아래에서 설명한다.
굵은 글씨는 놓치면 설명을 잘못 이해할 핵심 조건이나 판단에 쓴다. 기술 용어마다 강조하지 않는다.
인용문은 실제 인용에 쓴다. 자기 결론을 명언처럼 보이게 하려고 인용 상자를 만들지 않는다.
구분선, 번호, 같은 깊이의 소제목을 모든 단락에 반복하지 않는다.
오탈자, 잘못된 띄어쓰기, 불필요한 빈 줄은 흉내 내지 않는다.

6. 기술 용어와 전제

cpp, msvc, heap, thread, include 같은 용어를 한국어 설명 안에서 자연스럽게 쓴다. 코드의 정확한 식별자는 보존한다.
독자가 이미 알 만한 단어마다 한국어·영어·약자를 세 겹으로 붙이지 않는다. 뜻이 필요한 곳에서만 설명한다.
기본 개념을 생략할 수 있지만, 글의 결론을 결정하는 전제까지 생략하지 않는다.
성능 비교에서는 자료형, 데이터 크기, 순서 유지 여부, 할당 방식, 접근 패턴 등 관련 조건을 적는다.
항상, 무조건, 비교도 안 되게, 거의 모두 같은 단정에는 그만한 근거가 필요하다. 측정이 없으면 성능 배수나 승패를 만들어내지 않는다.
최적화 방법은 제거하는 비용과 남는 비용을 함께 설명한다. 동기화나 수명 관리가 필요한 기법을 이름만 붙여 해결된 것처럼 쓰지 않는다.
외부 자료를 요약했다면 출처를 밝힌다. 직접 실험한 결과처럼 서술하지 않는다.
C/C++ 언어와 표준 라이브러리는 cppreference를 우선 참고하고 해당 항목의 문서로 연결한다. eel.is의 표준 초안 링크는 사용하지 않는다. MSVC나 Windows의 구현·확장 기능은 Microsoft 공식 문서를 참고한다.

7. 글 종류별 차이

종류	우선할 흐름	피할 것
기술 분석·비교	의문 → 내부 동작 → 비용·차이 → 적용 조건	정의와 장단점만 늘어놓기
버그·실습 기록	증상 → 시도 → 확인한 원인 → 수정·남은 문제	실패한 시도를 지워 처음부터 답을 알았던 것처럼 만들기
도구·팁	쓰는 상황 → 기능·명령 → 주의점	짧은 메모를 긴 입문 강의로 부풀리기
강의·자료 메모	출처 → 주제별 핵심 → 필요한 설명	자료 속 경험을 저자의 경험으로 바꾸기
회고·의견	실제 사건 → 느낀 점 → 생각의 변화·현재 판단	기술 글에 회고 말투를 무리하게 섞기

8. 마무리

본문에서 이미 설명한 내용을 항목별로 전부 되풀이하지 않는다. 마지막에 남는 판단, 적용할 조건, 아직 확인하지 못한 부분 중 필요한 것을 쓰고 끝낸다.

“여러분도 활용해보세요”, “더 나은 개발자로 성장할 수 있습니다” 같은 독려는 붙이지 않는다. 짧은 메모는 내용이 끝난 자리에서 그대로 끝나도 된다.

9. 수정 예시

아래 문장은 규칙 적용을 설명하기 위해 새로 쓴 예시이며, 과거 글의 인용이 아니다.

소개형 문장

수정 전: “이번 글에서는 list와 vector의 핵심 차이를 심층적으로 살펴보겠습니다.”
수정 후: “list는 중간 삽입이 O(1)이라고 한다. 근데 삽입할 위치를 찾는 비용은 별개다.”

강조만 있는 설명

수정 전: “vector는 압도적인 캐시 효율로 탁월한 성능을 제공합니다.”
수정 후: “vector는 원소가 연속으로 붙어있다. 작은 원소를 순서대로 읽으면 한 캐시 라인에 들어온 옆 원소도 같이 쓸 수 있는 셈이다.”

조건 없는 해결책

수정 전: “더블 버퍼링으로 락 경쟁을 완전히 해결할 수 있다.”
수정 후: “읽는 쪽과 쓰는 쪽의 버퍼를 나눌 수는 있다. 근데 읽기가 끝나기 전에 그 버퍼를 다시 쓰면 똑같이 문제가 생긴다. 교체 시점과 버퍼 수명은 따로 맞춰줘야 한다.”

10. AI에게 전달할 작성 지시

이 저장소의 BLOG_WRITING_RULES.md를 기준으로 글을 작성하거나 수정한다. 일반 기술 글은 평서체와 짧은 문단을 사용하고, 의문이 생기는 지점에서 시작해 실제 동작과 비용을 따라 설명한다. 구어와 개인 판단은 맥락에 맞게 쓰되, 전달받지 않은 경험·측정·감정은 만들어내지 않는다. 강조, 홍보성 소제목, 반복 요약을 줄인다. 기존 글을 고칠 때는 핵심 내용과 메타데이터를 유지하고, 잘못된 단정은 근거와 적용 조건을 확인해 고친다. 결과물은 바로 게시할 수 있는 본문으로 작성한다.

작성 후 확인할 것:

첫 문단에 실제로 다룰 의문이나 상황이 있는가?
주장 뒤에 동작과 이유가 이어지는가?
근거 없이 더 강해진 주장이나 만들어낸 경험이 없는가?
해결 방법의 조건과 남는 비용이 드러나는가?
구어를 억지로 넣거나 강조·목록·요약을 반복하지 않았는가?
원문의 기술 내용, 링크, 코드, 제목·날짜·태그를 의도 없이 바꾸지 않았는가?

문체를 확인한 대표 글

아래 인용은 현재 저장소에 있는 원문 표현이다. 전체 대상 중 규칙의 근거를 다시 확인하기 좋은 글을 골랐다.

글	원문 표현	확인할 특징
std::atomic_flag의 delete fuction 탐방기	“책 따라서 예제 코드를 쓰고 돌려보고있었다.”	실제 문제에서 시작해 라이브러리 구현으로 들어감
bomb lab 2	“깔끔한 솔루션이 아닌 정말로 어떻게 이것저것 해보면서 해결을 해왔는지를 다루고있다.”	정답만 남기지 않고 해결 과정을 기록
unsignedChar	“굳이 char이아닌 unsigned라고 명시했는지 궁금해서”	명세의 작은 의문에서 이유를 찾아감
예외 처리	“이게 맞….나?”	실제 코드에 대한 의문과 개인 판단
NRVO	“이것도 그만알아보자.”	설명을 끝내고 장황한 결론을 붙이지 않음
커널 모드 동기화	“오개념을 잡아보자.”	익숙한 표현의 의미와 전제를 다시 따짐
purecall	“그게뭐지?하고 찾아보게 된 글”	궁금증을 곧바로 글의 출발점으로 사용
const 멤버함수로 변경시 조심점	“대충 이런 느낌으로 수정”	코드와 결과를 따라가며 원인과 방지책 설명
빌드 시간을 줄이기 위한 노력들	“이미 빌드가 다된 프로젝트에서 파일 하나 코드 한줄을 수정한다고 생각해보자.”	작은 가정을 놓고 비용과 해결책을 연결
BitFlagEnumClass	“사실상 casting하는 로직만 귀찮지않게 따로 빼놨을 뿐인 수준”	불편함에서 시작하고 구현의 규모를 과장하지 않음