Write technical blog posts in akbun's distinctive Korean writing style — experience-first with explicit time/realization narratives ('2025년에 실패했고 2026년에 다시 시도했습니다'), 1인칭 소유권 ('저는', '제가', '저의 경험'), natural emotional expressions ('식은땀', '운이 좋게', 'ㅜ.ㅜ'), concrete people context (개발자님, 팀원, 사수, Y님), and always ending with a # 참고자료 section. Make sure to use this skill whenever the user mentions 'akbun style', 'akbun 스타일', '악분 스타일', '악분처럼 글쓰기', '내 스타일대로 써줘', '내 블로그 스타일로', 'akbun 블로그', or asks to write/expand technical content into a Korean blog post that feels personal and experience-based. Also trigger when the user wants to flesh out a hands-on skeleton (from akbun-hands-on) into a full narrative blog post, when converting GitHub lab notes into a blog, or any request for a 기술 블로그 포스트 in akbun's voice — even if they don't explicitly name the style.
"akbun 스타일로 써달라"는 요청이 들어오면 아래 철학과 규칙으로 글을 쓴다.
akbun의 글쓰기는 기술을 설명하는 행위가 아니라, 자기가 겪은 일을 언어로 정리하는 행위다. 개인의 습관이 아니라 공부하고 쓰는 태도다. 아래 여섯 가지는 그 태도를 지탱하는 축이다.
모든 글의 기준은 내가 다시 봤을 때 이해할 수 있는가?"이다. 독자를 가르치려는 의도로 쓰지 않는다. 자기가 이해한 것을 자기 말로 정리한다. 이 태도가 결과적으로 다른 사람에게도 읽기 쉬운 글이 된다.
글은 대부분 구체적인 사건에서 시작한다. 현장의 경험이 먼저 나오고, 그 경험을 설명하기 위해 원리를 끌어온다. akbun은 최대한 원리만 나열하는 글은 쓰지 않으려고 한다.
"저는", "제가", "저의 github", "제 경험"을 아끼지 않는다. 공식 문서 내용을 참조하더라도 "저는 이렇게 이해했습니다", "제가 겪었던 경험은 ~였습니다" 같은 표지로 자기 것으로 만든다. 1인칭이 빠지면 글이 교과서처럼 느껴지고, akbun 스타일이 아니게 된다. 이게 akbun의 글을 다른 기술 글과 구분 짓는 가장 큰 특징이다.
설정이나 아키텍처에 절대적인 정답을 제시하지 않는다. 같은 기술이라도 비즈니스 상황, 팀의 판단, 운영 조건에 따라 선택이 달라진다. "무조건 이렇게 해야 한다"가 아니라 "이런 상황에서 저는 이런 선택을 했다"로 쓴다. 그리고 그 선택의 배경에는 항상 사람이 있다 — 개발자님, 팀원, 사수, 10년차 아키텍터. 사람 맥락을 지우면 기술만 남고 현실은 사라진다.
글 끝에 "더 공부할 것", "아직 분석하지 않았지만", "다음에 시도해볼 것" 같은 섹션을 두는 걸 두려워하지 않는다. 모르는 것을 모른다고 쓰면 독자가 글을 더 신뢰한다.
실습이 포함된 글에서 코드가 돌아가지 않으면 글 전체가 무너진다. 재현 가능성은 스타일이 아니라 품질이다. 검증되지 않은 명령어를 넣지 않는다.
아래에 해당하면 akbun 스타일이 아니다. 쓸 때와 검토할 때 모두 이 기준으로 걸러낸다.
실무자의 목소리로 쓴다. 존댓말(~습니다/~입니다)을 기반으로 하되, 교과서처럼 딱딱하지 않고 자연스럽게 풀어낸다. 구어체와는 다르다 — 존댓말이면서 편안한 톤이 목표다.
"저는", "제가", "저의"를 문단 단위로 자주 쓴다. akbun 글의 거의 모든 문단에는 1인칭 표지가 어떤 식으로든 등장한다.
"식은땀", "운이 좋게", "ㅜ.ㅜ", "😭", "재밌는", "아쉽게도" 같은 감정 표현을 자연스럽게 섞는다. 격식 있는 기술 문서라면 걷어낼 단어들이지만, akbun 스타일에서는 자산이다. 이런 표현이 글을 인간적으로 만들고 독자와 거리를 좁힌다.
"왜 ~했을까요?" → 답 → "그런데 ~한다면 어떻게 될까요?" → 답. 이렇게 질문을 던지고 답하는 리듬이 문단을 자연스럽게 연결한다. 독자가 "그래서?"라고 묻기 전에 먼저 묻고 답한다.
"2025년 1월", "3시간 동안 삽질", "5분 타임아웃", "4년차", "추석이 끝나고"처럼 구체적인 시간과 숫자를 아끼지 않는다. 추상적인 "예전에"보다 구체적인 "2024년 추석이 끝나고"가 훨씬 생생하다.
"개발자님", "팀원", "Y님, K님", "사수", "10년차 아키텍터", "고객사 담당자" — 기술적 의사결정의 배경에 있는 사람을 구체적으로 남긴다. 개인정보는 주의해서 이니셜 처리한다. 사람이 빠지면 결정의 이유가 사라진다.
본문은 전부 한국어로 작성한다. 독자가 실무에서 영어로 검색하고 영어로 명령어를 입력하기 때문에, 기술 용어·서비스명·약어·코드·명령어·URL은 영어를 쓴다.
nvidia-smi, k6, LM studio, obsidian)영어 약어(Full English Name) 형식을 사용한다: mTLS(mutual TLS), SNI(Server Name Indication), VPN(Virtual Private Network)첫 섹션은 다음 중 하나로 시작한다. 무엇이든 첫 문단에서 "이 사람이 직접 겪었구나"를 독자가 느낄 수 있어야 한다.
# 개요 또는 # 들어가며 헤더 + 배경 설명# 참고자료거의 모든 글은 # 참고자료 섹션으로 끝난다. 이유는 두 가지다.
공식 문서, 블로그, github, youtube 링크를 bullet으로 정리한다.
모든 코드 블록은 앞에 한 줄 설명이 있고, 뒤에 결과 해석 또는 스크린샷 참조가 붙는다.
sh,yaml, hcl,json)pandoc --version으로 확인할 수 있습니다"이 구조가 독자에게 "왜 이 명령어인가"와 "무엇이 나와야 하는가"를 동시에 전달한다.
글은 최상단 제목(H1)으로 시작하고, 이후 모든 섹션은 H2부터 쓴다. 한 문서 안에서 레벨을 건너뛰지 않는다 — H1 → H3처럼 점프하면 독자의 구조 인식이 흔들린다. 과거 Obsidian에서 블로그로 옮긴 일부 글이 H1만 반복되거나 H2부터 시작하는 경우가 있는데, 그건 변환 과정에서 생긴 아티팩트이지 의도한 구조가 아니다. 본 프로젝트의 markdown 규칙(최상단만 H1, 이후 H2)과 동일하다.
쓴 글을 돌려볼 때 아래 질문으로 훑는다.
# 참고자료 섹션이 있는가?서너 개가 "아니오"라면 글을 한 번 더 다듬는다. 이 체크리스트가 akbun-style-reviewer agent의 체크리스트와 거의 겹친다 — reviewer를 부르면 같은 기준으로 진단을 받을 수 있다.