기술 블로그를 표로 쓰게 된 이유: 서술형 혐오자의 글쓰기 컨벤션 · DK 기술 블로그

TL;DR

기술 블로그를 쓰다 보니 서술형 문단보다 표/불릿이 편해졌다. 취향 문제가 아니라, 독자가 필요한 정보를 빨리 잡게 하려는 실무 습관이 붙었다.
다만 표가 항상 정답은 아니다. 이유/배경/판단 과정/실패 맥락이 필요한 곳은 서술이 필요하다. 나는 “정보 밀도”와 “읽는 방식”을 기준으로 형식을 고른다.
내 블로그에 적용한 금기 컨벤션도 있다. em-dash 금지, middle dot 대신 슬래시(/), AI 티 표현 제거, 숫자 정량화.

들어가며

기술 블로그를 처음 쓰기 시작했을 때는, 그냥 문장을 길게 썼다. 설명해야 할 내용이 있으면 문장으로 이어서 쓰고, 비교해야 할 게 있으면 문장 안에 나란히 넣는 식이었다.

그런데 쓰다 보니 불편한 지점이 계속 나왔다. 독자가 찾아야 하는 정보가 문장 안에 숨어 있고, 앞뒤 문맥을 다시 읽어야 의미를 잡을 수 있었다. 한 번은 도구 비교를 글로 썼는데, 다 읽고 나서도 “결국 뭐가 더 나은지” 한눈에 안 들어왔다. 그때 느꼈다. 내가 문제를 정리하는 방식과, 독자가 그 글을 읽는 방식이 다를 수 있다는 걸.

그 뒤로 내가 글을 쓰는 기준이 조금씩 바뀌었다. 핵심은 이것 하나다. 이 글에서 독자가 뭘 빨리 잡아야 하느냐에 따라 형식을 고르자는 것. 정보 타입과 읽는 방식에 따라 표/불릿/서술을 섞어 쓰게 됐다.

이 글은 그 기준을 정리한 것이다. “표는 무조건 좋다” 같은 주장이 아니다. 내가 왜 그렇게 쓰는지, 그리고 그렇게 썼을 때 불편한 지점까지 같이 적어둔 기록이다.

표/불릿을 택하는 기준

내가 형식을 고를 때 보는 건 두 가지다. 정보의 종류, 그리고 독자가 그 정보를 어떻게 읽으면 편할지.

표가 유리한 경우

비교가 필요한 내용은 표가 빠르다. 항목 간 차이가 명확해야 비교가 읽히기 때문이다. 예를 들어 이런 것들이다.

도구 A vs B의 특성 비교
옵션별 장단점
여러 선택지의 조건 차이를 한눈에 보여줘야 할 때
결정 로그: 판단 근거와 결과를 나중에 검증할 수 있게 남길 때

비교가 목적인데 문단으로 풀면, 독자는 문장마다 “아 이거 다른 항목이랑 대비되는구나” 하고 매핑해야 한다. 표로 두면 그 매핑이 이미 그려져 있다.

불릿이 유리한 경우

순서와 항목 열거는 불릿이 편하다. 예를 들면 이런 것들이다.

절차/단계/순서
체크리스트
요약 목록
조건이 여러 개일 때 각각 명시

순서가 중요한 내용을 문단으로 풀어버리면, 독자가 순서를 놓치기 쉽다. 불릿이나 번호로 두면 순서 보존이 명확해진다.

서술이 필요한 경우

문장이 필요한 경우도 분명히 있다. 특히 이런 내용이다.

이유/배경: 왜 그렇게 했는지
실패 맥락: 어떤 상황에서 망가졌는지
판단 과정: 여러 선택지 사이에서 어떻게 결정했는지
해석과 전후 관계: 문장만으로 풀어야 이해되는 부분

서술이 필요한 내용을 표에만 넣어버리면, 판단 과정이 빈칸처럼 보인다. 표는 사실을 깔끔하게 정리하는 데 강하지만, “왜”까지 담아내기엔 구조가 단단해서 오히려 제약이 된다.

한 줄로 정리하면 이렇다. 정보 타입과 읽는 방식에 따라 고르지, “있어 보여서” 고르지 않는다.

이 기준을 표로 다시 정리해 봤다.

정보 타입	적합한 형식	이유
도구/옵션 비교	표	항목 간 차이가 명확해야 비교가 읽힘
단계/순서	불릿/번호	순서 보존이 중요
판단 근거+결과	표(결정 로그)	나중에 검증/회고 가능해야 함
이유/실패 맥락	서술	전후 관계와 해석을 문장으로 풀어야 함
체크리스트/요약	불릿	항목이 많고 순서/항목 구분이 중요

이 표 자체도 내 컨벤션의 예시로 볼 수 있다. 비교/기준 성격의 내용은 표가 빠르다는 걸 보여주려고 넣었다.

내가 금지한 기호와 글투

내 블로그에는 몇 가지 피하는 컨벤션이 있다. 전부 취향에서 시작한 건데, 쓰다 보니 이유도 생겼다.

em-dash 금지

em-dash는 문장 중간에 넣는 가로선이다. 문장에 쉼표 대신 호흡을 넣거나, 부연을 덧붙일 때 자주 쓰인다. 그런데 기술 글에서 이걸 호흡용으로 쓰면, 내가 느끼기엔 AI 티로 보일 때가 많았다. 특히 “em-dash 기호”가 문장 안에 자주 끼어 있으면, 무슨 역할인지 애매해진다. 부연인지, 대조인지, 그냥 장식인지.

그래서 나는 em-dash를 거의 안 쓴다. 대신 콜론(:)이나 문장을 나누는 식으로 처리한다. 예컨대 “이 글에서는 A, B, C를 다룬다. 특히 B에 집중” 같은 문장이 있으면, 나는 이걸 “이 글에서는 A, B, C를 다룬다. 특히 B에 집중”처럼 자르거나, 콜론으로 연결한다.

em-dash 금지는 내 블로그뿐 아니라, 대장님에게 보내는 글 초안에도 비슷하게 적용한다. 과잉 겸양 표현이나 AI 같은 문장 결을 빼는 방향과 같은 계열이다.

middle dot 대신 슬래시(/)

middle dot은 항목 사이 구분으로 자주 쓰인다. 예를 들면 “자율/에이전트형”, “AI/AGI/AX/Agent” 같은 식이다. 나는 이걸 거의 slash(/)로 바꾼다. “자율/에이전트형”, “AI/AGI/AX/Agent”처럼.

이유는 단순하다. 내 눈엔 slash가 더 읽기 쉽다. middle dot이 두 개 이상 연속되면 점처럼 보여서, 항목과 항목 사이 경계가 흐려질 때가 있다. slash는 경계 느낌이 더 분명했다. 이건 철저히 내 읽기 편차 기준이다.

AI 티 표현 제거

이건 “사람 글처럼 보이게 하자”는 방향의 습관이다. 내가 피하는 패턴은 대표적으로 이런 것들이다.

과잉 겸양: “Happy to reshape if you’d prefer” 류의 문장. 기술 글에서 이런 결은 이상하게 비어 보인다.
기계적 병렬 나열: 비슷한 구조의 불릿이 의미 차이 없이 길게 늘어지는 것.
접속사 남발: “그리고”, “또한”, “따라서”가 문장마다 붙는 것.
결론 공식화: 모든 문단이 비슷한 톤의 결론으로 닫히는 것.

이런 패턴을 다 피한다는 건 아니고, 눈에 띄는 정도가 있으면 줄이려는 쪽이다. 기준은 “내가 읽었을 때 기계적으로 느껴지는가”다.

숫자 정량화

“많이”, “자주”, “거의”, “꽤” 같은 표현을 숫자로 바꾸려는 습관도 있다. 예를 들면 이런 식이다.

“처리가 꽤 빠르다” → 가능하면 시간/범위로 적는다
“여러 번 호출한다” → 호출 횟수나 범위를 적는다
“자주 실패한다” → 가능하면 빈도나 조건을 적는다

물론 모든 걸 숫자로 바꿀 수 있는 건 아니다. 다만 숫자로 적을 수 있는 걸 애매한 말로 넘기면, 나중에 그 문장을 다시 읽을 때 내가 무슨 뜻으로 썼는지 흐려진다. 정량화는 내 기억을 선명하게 하려는 목적도 있다.

표가 만능은 아니다: 표로 써서 망한/애매했던 지점

표만 쓰다 보면 불편한 지점이 분명히 있다. 내 경험에서 나온 것들이다.

맥락이 필요한 판단을 표에만 넣으면 독자가 판단 과정을 건너뛴다

예를 들어 어떤 결정을 표로 정리했다고 하자. 선택지, 기준, 결과가 표에 들어가면 깔끔하다. 그런데 “왜 이 기준을 썼는지”, “왜 다른 선택지는 버렸는지”가 빠져 있으면, 독자는 결과만 보고 넘어가게 된다. 나중에 그 결정을 다시 검토할 때 근거를 찾기 어렵다.

그래서 나는 결정 로그 성격의 표를 쓸 때, 표 바깥에 판단 과정을 짧게라도 붙인다. 표만 덜렁 두지 않으려는 이유다.

표가 길어지면 오히려 읽기 어렵다

행이 너무 많은 표는 보기엔 정리된 것 같아도, 실제로는 읽는 부담이 크다. 한눈에 들어오지 않고, 눈이 위아래로 계속 움직여야 한다. 표가 정보 전달 수단이지, 정보를 욱여넣는 수납함이 되면 안 된다고 느꼈다.

그래서 나는 표를 쓸 때 행을 선별한다. 모든 조건을 다 넣기보다, 비교를 위해 꼭 필요한 항목만 남기려고 한다. 표가 길어지면 차라리 여러 표로 나누거나, 일부는 서술로 뺀다.

표에서 생략한 근거가 나중에 질문으로 돌아온다

표에서 어떤 내용을 “굳이 안 적어도 되겠지” 하고 뺐는데, 나중에 그 부분이 질문으로 돌아오는 경우가 있었다. 특히 기술 글에서는 “왜 이 항목만 있고 저 항목은 없냐” 같은 질문이 나오기 쉽다. 표가 깔끔할수록, 생략한 부분이 더 눈에 띌 수 있다.

그래서 나는 표를 쓰고 나면, 생략한 게 무엇인지도 한 번 더 본다. 아예 안 적어도 되는 건지, 아니면 서술이나 각주라도 붙여야 하는 건지.

내 방식의 한계 / 반박 포인트

이 방식이 만능이라고 주장하려는 건 아니다. 내 경험과 취향에서 나온 기준이고, 한계가 분명하다.

내 취향/경험 기반이라 보편 답은 아니다

내가 표/불릿을 편하게 느끼는 건, 내가 정보를 읽는 습관과 관련이 있다. 다른 사람은 서술형에서 더 빨리 정보를 잡을 수도 있다. 내 기준은 내 읽기 방식에 맞춰진 거라, 누구에게나 같은 답이 되진 않는다.

독자가 이미 익숙한 domain이면 서술형도 충분히 빠를 수 있다

어떤 topic은 독자가 이미 맥락을 알고 있어서, 서술형으로 풀어도 바로 이해한다. 그런 글까지 억지로 표로 바꿀 필요는 없다. 오히려 서술형이 더 자연스러울 수 있다. 내가 형식을 고르는 기준은 “독자가 이미 아는 내용인지”도 일부 반영한다.

블로그가 아니라 다른 문맥이면 기준도 달라져야 한다

이 글에서 말하는 기준은 블로그에 맞춰진 것이다. 보고서, 이메일, 코드 주석, 기획 문서처럼 문맥이 달라지면, 같은 기준을 그대로 쓰면 안 맞을 수 있다. 예를 들어 코드 주석은 표보다 짧은 문장이 나을 때가 많고, 이메일은 빠른 전달이 중요해서 불릿이 자주 유리하다. 문서가 서면 내 기준도 달라진다.

표만능으로 가면 글이 건조해지고, 판단 과정이 비어 보일 수 있다

표가 많아지면 글은 정리돼 보이지만, 대신 온도가 내려간다. 그리고 앞서 말했듯 판단 과정이 비어 보일 수 있다. 그래서 나는 혼합형으로 간다. 표는 필요한 곳에만, 이유/맥락은 서술로. 둘 중 하나만 쓰지 않는다.

정리

기술 블로그를 표로 쓰게 된 이유는 단순하다. 독자가 필요한 정보를 빨리 잡게 하려는 실무 습관이 붙었고, 그 결과 정보 타입과 읽는 방식에 따라 형식을 고르는 기준이 생겼다.

표/불릿/서술을 각각 다른 목적으로 쓴다. 비교와 기준은 표, 순서와 체크는 불릿, 이유와 판단 과정은 서술. 그리고 em-dash/middle dot을 줄이고, AI 티 표현을 덜고, 숫자를 정량화하려는 습관도 붙었다.

다만 이 기준은 내 경험에서 나온 거라 범용 정답은 아니다. 표가 만능도 아니다. 표가 길어지면 오히려 읽기 어렵고, 맥락을 표에만 넣으면 판단 과정이 비어버린다. 그래서 나는 혼합형으로 쓴다.

이 글의 내용도 결국 내 방식이 어떻게 생겼는지 기록한 것이다. 남의 정답으로 삼기보다, 각자 자기 기준을 세우는 데 참고만 하면 된다.

참고: em-dash 금지와 middle dot 대신 slash 사용은 내 블로그/대장님용 글 초안 공통 컨벤션(2026-08-11, 2026-08-19)에서 유래한 것. 정량화 습관은 p50 30s, p95 90s, LLM 3~4회처럼 수치/범위를 적는 기술글 작성 경험에서 굳어진 것. 이 글 자체도 그 컨벤션으로 썼다. 표 예시의 “판단 근거+결과 → 표(결정 로그)” 항목은 earlier draft에서 강조한 결정 로그 표기 관행과 이어진다.