알기 위해 쓰는 기술 블로그

알기 위해 쓰는 기술 블로그

AI 뉴스 썸네일

기술 블로그의 주제를 이미 잘 아는 분야로만 제한하면 시작하기는 편해요. Sean Goedecke는 아직 완전히 이해하지 못한 주제를 골라 쓰면서 빈틈을 찾고, 조사 과정에서 생각을 고쳐 나가요. 글 한 편을 쓰며 자신의 이해도를 확인하는 방식이에요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
학습	문장으로 설명하다 막히는 지점이 이해의 빈틈이에요	다음에 무엇을 조사해야 할지 구체적으로 보여 줘요
글의 구조	반론 가능한 주장 하나를 세우고 근거를 찾아요	생각 모음보다 논점과 조사 범위가 선명해져요
초보자의 강점	막 배우기 시작한 사람은 처음 막혔던 부분을 기억해요	전문가가 건너뛰기 쉬운 문제의 출발점을 설명할 수 있어요
AI 활용	LLM으로 기술적 오류와 논리의 빈틈을 찾아요	글쓴이가 생각하는 과정은 남기면서 피드백을 받을 수 있어요

1. 기술 블로그는 이해한 내용을 적는 곳만은 아니에요

Goedecke는 게시하는 글마다 최소 두 가지를 배운다고 말해요. 하나는 글을 쓰게 만든 최초의 발견이고, 다른 하나는 집필 중 새로 확인한 사실이에요. 쓰는 동안 배운 것이 없다면 공개할 만큼 흥미로운 글이 아닐 수 있다고 봐요. 2

머릿속에서는 여러 단계를 건너뛰어도 생각이 자연스럽게 이어져요. 문장으로 옮기면 사정이 달라져요. 용어를 정의하고 원인과 결과를 연결하는 순간, 근거가 약하거나 앞뒤가 맞지 않는 부분이 눈에 들어와요. "이 설명이 사실인가"라는 질문이 생긴 곳이 바로 다음 조사 지점이에요.

728x90

저자는 모든 글에서 하나의 주장을 펼쳐요. 단편적인 생각을 모으거나 다른 글에 동의하는 수준에서 끝내지 않아요. 어느 정도 반론이 가능한 주장을 정하면 예상되는 비판에 답할 근거가 필요해져요. 덕분에 검색 범위와 글의 중심도 자연스럽게 좁아져요.

제약은 꾸준히 쓰는 데도 도움을 줘요. 무엇이든 자유롭게 쓰려고 하면 후보가 너무 많아 첫 문장을 고르기 어려워요. 주장 하나와 예상 반론을 먼저 정하면 필요한 사례, 자료, 설명의 순서가 보이기 시작해요. 기술 글에서는 "이 도구가 좋다"보다 "어떤 조건에서 기존 방식보다 낫고, 어디서 실패하는가"처럼 검증할 수 있는 문장이 출발점이 될 수 있어요.

쓰다가 의견이 바뀌면 조사가 작동한 거예요

원문에 소개된 글들은 처음의 가설과 다른 곳에 도착해요. AI 위치 추론 글은 모델 입력문의 한계에서 출발했지만 최신 모델의 능력 변화로 논점이 옮겨갔어요. C2PA 글은 보편적 도입 문제에서 시작해 공개 키 기반 구조와 로컬 기기의 개인 키 관리까지 파고들었어요. 결론이 처음 생각과 달라진 과정 자체가 조사 결과예요.

첫 원고의 결론이 서론보다 선명해지는지도 확인할 만해요. 끝까지 조사하며 썼다면 처음보다 용어와 판단 기준이 정교해져요. 이때 서론을 다시 쓰면 독자가 실제 논점에 더 빨리 닿을 수 있어요. 처음 세운 결론을 끝까지 지키는 것보다 새로 확인한 사실에 맞춰 고치는 편이 믿을 만한 글을 만들어요.

막 배우기 시작한 사람에게도 설명할 자리가 있어요

전문가는 익숙한 배경지식을 독자도 안다고 여기기 쉬워요. 막 배우기 시작한 사람은 자신이 어디서 막혔는지 기억해요. 기술 해법을 설명하기 전에 애초에 어떤 문제를 풀려는지, 기존 방식은 왜 부족했는지부터 짚을 수 있어요.

초보자가 전문가처럼 보이지 않으려면 자신의 경험 범위를 분명히 밝혀야 해요. 저자는 실명과 경력을 공개해 독자가 전문 분야를 판단할 수 있게 해요. 글에서도 확인한 사실, 자신의 해석, 아직 남은 의문을 구분하면 과장된 권위를 피할 수 있어요. 공개가 부담스럽다면 비공개로 쓰거나 가까운 동료에게만 공유해도 사고를 정리하는 효과는 남아요.

LLM은 논증의 빈틈을 찾는 검토자로 써요

원문은 비공개 글도 LLM으로 기술적 피드백을 받을 수 있다고 설명해요. 다만 모델은 주장을 지나치게 약하게 만들거나 필요 이상의 단서를 권할 때가 있어요. 피드백이 틀릴 수도 있으므로 제안 자체를 근거로 삼으면 안 돼요.

활용 범위를 좁히면 쓸모가 분명해져요. 정의가 문단마다 달라지는지, 주장과 근거 사이에 빠진 단계가 있는지, 반례가 될 조건은 무엇인지 물어볼 수 있어요. 답을 그대로 붙이는 대신 지적받은 부분의 원자료를 다시 확인해야 해요. 생각하고 조사하는 일은 글쓴이에게 남고, LLM은 검토 범위를 넓히는 역할을 맡아요.

왜 중요한가요

개발자는 코드, 설계 문서, 장애 보고서, 의사 결정 기록을 계속 써요. 자신이 이해한 범위를 문장으로 확인하는 습관은 블로그 밖에서도 도움이 돼요. 설명이 막히는 지점을 찾으면 설계의 전제, 측정하지 않은 비용, 팀마다 다르게 쓰는 용어를 배포하기 전에 드러낼 수 있어요. 2

좋은 출발점은 거창한 주제가 아니어도 돼요. 최근 도입한 라이브러리가 어떤 문제를 해결하는지, 익숙한 API가 특정 조건에서 왜 느려지는지처럼 업무에서 생긴 의문 하나면 충분해요. 먼저 반론 가능한 문장으로 적고, 근거를 찾으며 결론을 바꿀 여지를 남겨 두면 글쓰기와 학습이 같은 작업이 돼요.

참고 자료

1. 아직 이해하지 못한 것에 대해 블로그를 써라 — GeekNews
2. Blog about things you don't understand yet — Sean Goedecke