기술 블로그를
AI로 운영한 3개월
그리고 솔직한 숫자

시간을 줄이면 퀄리티가 떨어진다고 생각했습니다.
아니었습니다.

마케터도 작가도 아닌데

 
AI 관련 영상이나 글을 보면 다들 쉽게 되는 것처럼 보입니다. 프롬프트 하나 넣으면 기획서가 나오고, 버튼 하나로 콘텐츠가 완성됩니다. 그런데 막상 내 업무에 대입해보면 뭔가 어긋납니다. 결과물이 어색하거나, 어디서부터 시작해야 할지 모르겠거나. 저도 그랬습니다. 마케터도 아니고 작가도 아닌데, 블로그를 제대로 운영할 수 있을까 싶었습니다.
 
개발자로 십수 년을 살았습니다. 글을 잘 쓴다는 말을 들어본 적도 없고, 콘텐츠 기획이라는 개념은 더더욱 낯설었습니다. 기술 블로그는 쓰는 사람이 좋아서 쓰는 거지, 운영이라는 단어를 붙이기엔 어딘가 거창한 느낌이었습니다. 그냥 알고 있는 걸 정리해서 올리는 공간 정도로 생각했습니다. 꾸준히 쓰는 것만으로도 충분하다고 스스로를 설득하면서요.
 
그런데 12월부터 방식을 바꿨고, 3개월이 지났습니다.

비수기에 나온 숫자

1월 374PV, 2월 694PV. 한 달 사이 86% 성장입니다.

 
숫자를 꺼내기 전에 맥락을 하나 짚겠습니다. 기술 블로그는 구조적으로 PV가 낮은 장르입니다. 타겟이 좁고, 검색 유입도 느리고, 바이럴이 거의 없습니다. 일반적인 라이프스타일 블로그나 재테크 블로그와 단순 비교하기 어려운 장르입니다. 게다가 이 기간은 블로그 비수기였습니다. 연초는 대부분의 기술 블로그가 조용해지는 시기거든요. 검색량도 줄고, 새로운 유입도 뜸해집니다. 그 타이밍에 이 숫자가 나올 줄은 저도 솔직히 몰랐습니다.
 

 
참여율 40%대도 마찬가지입니다. 기술 글은 훑고 나가는 독자가 많습니다. 제목 보고 들어왔다가 첫 문단에서 이탈하는 경우도 흔합니다. 40%면 끝까지 읽는 사람이 상당하다는 뜻입니다. 시간을 줄였는데 오히려 더 읽히는 글이 됐다는 게 스스로도 흥미로웠습니다. 퀄리티를 지키면서 속도를 올리는 게 가능하다는 걸, 숫자로 확인한 순간이었습니다.

방향을 잡는 쪽은 언제나

글을 쓰기 전에 AI와 먼저 이야기합니다. 주제 선정부터 같이 합니다. 이 글이 지금 나올 타이밍인지, 비슷한 글과 어떻게 달라야 하는지를 먼저 검토합니다. 단순히 "이런 글 써줘"가 아니라, 시장에서 이 글이 어떤 위치를 가질 수 있는지를 같이 따져봅니다.
 
실제 사례가 있습니다. GPU 역사 시리즈를 연재하던 중에 UE5 편을 쓸 시점이 됐을 때, AI와 함께 이 글이 링크드인에서 반응을 얻을 수 있는지 분석했습니다. 기술 직군 독자들이 어떤 맥락에서 이 주제에 관심을 가질지, 어떤 각도로 접근하면 공유가 일어날 수 있는지를 같이 정리했습니다. 그 예측이 정확히 통했습니다. 운이 아니라 기준이 있었습니다.
 
주제가 잡히면 저는 5분 안에 초안 구조를 씁니다. 완성된 글이 아니어도 됩니다. 흐름만 잡히면 됩니다. 그걸 AI에게 넘기고, 나온 결과물을 다시 다른 AI와 함께 교차검토합니다. 퇴고까지 끝내면 글 한 편에 30분 내외입니다. 이미지 생성, 태그, slug 추천까지 포함해서입니다. 예전에 글 한 편 쓰는 데 몇 시간씩 붙잡혀 있던 것과는 완전히 달라진 흐름입니다.
 
중요한 건 AI가 글을 쓴 게 아니라는 겁니다. 구조는 제가 잡았고, AI는 그 위에서 움직였습니다. 무엇을 쓸지, 왜 이 순서인지, 어떤 독자를 향한 글인지는 전부 제가 결정했습니다. AI는 그걸 실행하고 다듬는 역할이었습니다. 편집자 겸 마케터와 일하는 느낌이었는데, 방향을 잡는 쪽은 언제나 저였습니다. 그 차이가 결과물의 밀도를 갈랐다고 봅니다.

순서가 가지는 의미

ChatGPT로 초안을 잡는 건 객관적인 거리를 만들어주기 때문입니다. 제 생각에 너무 가깝게 붙어 있으면 글이 좁아지는데, ChatGPT가 그 거리를 잡아줬습니다. 지금은 Claude로 같은 역할을 가져왔고요.
 
Gemini는 다른 이유로 씁니다. 구글 검색 중심으로 학습된 모델이다 보니, 일반 독자가 어떻게 읽을지를 체크하는 데 쓸 만합니다. ChatGPT로 파고들고, Gemini로 대중성을 살짝 곁들이는 식입니다.
 
부수적으로는 Gemini, ChatGPT, 그리고 저 셋이서 돌아가며 교차검증을 하니까 할루시네이션이 걸러지기도 하고요.
 
도구를 많이 쓴 게 아니라, 각 도구가 잘 하는 걸 구분해서 배치한 겁니다.

십수 년이 남긴 감각

십수 년을 개발자로 일하면서 비개발 직군과 항상 같이 일했습니다. 기획자, PM, 마케터, 운영팀. 그분들의 언어로 기술을 설명하고, 업무 흐름에 맞춰 개발 결과물을 이어붙이는 게 일상이었습니다. 다양한 도메인을 거치면서 자연스럽게 생긴 감각이 있습니다. 개발을 모르는 현직자가 새로운 도구 앞에서 어디서 막히는지, 그리고 그 막히는 지점을 어떻게 돌아갈 수 있는지에 대한 감각입니다.
 
AI 앞에서도 비슷한 장면이 반복됩니다. 영상 보고 따라 해봤는데 내 업무엔 안 맞았던 경험, 결과물은 나왔는데 어딘가 어색해서 쓰질 못하는 경험. 막히는 지점이 도구가 아니라 구조에 있는 경우가 대부분입니다. 내 업무의 흐름을 먼저 잡고, 그 위에 AI를 얹는 순서가 필요한데, 그 순서를 잡는 방법을 가르쳐주는 곳이 많지 않습니다. 대부분의 AI 교육이 도구 사용법에서 멈추는 이유이기도 합니다.
이번에 블로그를 직접 운영하면서 다시 확인한 것들이었습니다. 코딩이 하나도 없는 워크플로우로, 기술 블로그 비수기에 86% 성장이 가능했습니다. 이게 블로그만의 이야기가 아니라는 걸, 기획서를 쓰고 보고서를 만들고 콘텐츠를 생산하는 현직자라면 아마 감이 오실 겁니다.

비슷한 글

빠르게 생성하고, 다시 검증한다.
프로세스가 만들어내는 리뷰 품질

 지난 포스팅인 [개발자의 종말, 구현자의 시작]에서 언급했던 AI 워크플로우를 기억하시나요? 단순히 코드를 짜는 단계를 넘어, 이제는 전체적인 시스템을 설계하고 AI를 적재적소에 배치해 효율을 극대화하는 구현자(Implementer)의 시대가 왔음을 말씀드렸습니다.
 오늘은 그 철학을 실천에 옮긴 사례를 공유하려 합니다. 바로 저에게 할당된 십수 명의 언리얼 엔진 수강생을 위한 'AI 코드 리뷰 시스템' 구축기입니다. 여러 프로젝트를 동시에 코드 리뷰하는 물리적 한계를 어떻게 Cursor와 프롬프트 엔지니어링으로 개선했는지, 제가 정의한 5단계 워크플로우에 맞춰 설명해 보겠습니다.

1. 요구사항 분석 (Requirement Analysis)

"물리적 한계와 품질 사이의 갈등"
 십수 명의 학생이 제출하는 코드를 매주 혼자 리뷰하면서 일관된 품질을 유지하는 것은 현실적으로 고부하입니다. 하지만 교육자로서 '대충' 할 수는 없죠. 제가 정의한 핵심 요구사항은 다음과 같았습니다.

• 일관성: 리뷰어의 컨디션에 상관없이 동일한 기준(심각도, 컨벤션 등) 유지.
• 근거 중심: "이게 더 좋아요" 식의 추상적 조언이 아닌, 정확한 파일 위치와 라인을 명시할 것.
• 성장 가이드: 단순 오타 수정을 넘어 다음 제출물에서 개선해야 할 '학습 방향성' 제시.

2. 설계 (Design)

"멀티 스테이지 검증 시스템"
 AI의 가장 큰 적은 '할루시네이션(환각)'입니다. 할루시네이션 가능성을 낮추기 위해 단일 프롬프트가 아닌 [리뷰 생성 => 리뷰 검증]이라는 2단계 구조를 설계했습니다. 또한, 이전 버전의 코드와 현재 버전을 비교 분석할 수 있는 '비교 모드'를 도입해 실력 향상 폭을 측정하도록 기획했습니다.

3. 프롬프트 작성 (Prompt Engineering)

"룰은 강제하되, 관찰에 기반할 것"
 설계한 내용을 바탕으로 Cursor에서 사용할 두 가지 핵심 프롬프트를 작성했습니다.

코드 리뷰 프롬프트

 이 프롬프트는 리뷰의 '뇌' 역할을 합니다. 추측성 표현을 철저히 금지하고, 모든 지적에 대해 (파일경로:라인범위) 근거를 요구합니다. 특히 Blocking(필수 수정)과 Non-blocking(권장)을 명확히 구분해 학생이 우선순위를 파악할 수 있게 했습니다.

코드 리뷰 검증 프롬프트

  AI가 작성한 리뷰를 다시 AI가 검사하는 '감시자' 프롬프트입니다. 1차 리뷰는 생산성을 위해 생성하고, 2차 검증은 형식 / 근거 / 금지 표현 위반을 줄여 결과물 편차를 낮추기 위해 분리했습니다. 룰 누락은 없는지, 섹션이 붕괴되거나 표현이 일탈되는 등, 리뷰의 룰 위반을 줄여 일관성을 확보합니다. code-review-tutoring.md가 변경 및 확장될 때, 리뷰 결과물이 룰을 계속 준수하는지 점검하는 장치로 사용합니다.

4. 튜닝 및 검증 (룰 준수)

"AI가 놓친 것은 없는가?"
 실제 수강생의 코드를 넣어보며 프롬프트를 튜닝했습니다. 처음에는 AI가 지나치게 관대한 피드백을 남기는 경향이 있어, 문장 톤은 단정하게 유지하되, 지적은 구체적 근거와 영향 중심으로 나오도록 규칙을 강화했습니다. 그래서 개인 평가 / 감정 표현 금지 룰을 강화해 철저히 "사실 => 근거 => 영향"의 구조로 출력되도록 교정했습니다.
 verify 프롬프트는 단순한 검사를 넘어, 시스템의 확장성을 담보하는 장치가 되었습니다. '학습 방향성'이나 '코드 퀄리티 분석' 같은 새로운 평가 기준을 추가할 때마다, 이 감시 장치가 결과물의 형식이 무너지지 않도록 파수꾼 역할을 해주었기 때문입니다.

5. 사용 (Usage)

# path1에 있는 코드들에 대해 코드 리뷰를 진행
/code-review-tutoring @path1

# path1에 대한 코드 리뷰를 진행하고 path2(이전 버전)와 비교하여 코드 퀄리티 변화도 출력
/code-review-tutoring @path1 @path2

# 직전 리뷰 텍스트에 대해 룰 위반 여부만 분석
/verify-code-review-tutoring

 
"튜터의 역할: 최종 큐레이터"
 이제 저는 여러 프로젝트의 코드를 처음부터 끝까지 읽는 대신, AI가 정리해 준 [강점/약점/학습 방향성] 보고서를 먼저 검토합니다.

1. Cursor가 프롬프트에 따라 1차 리뷰 생성.
2. 검증 프롬프트로 룰 위반 여부를 체크.
3. 최종적으로 제가 내용을 분석하고 정제하여 학생에게 전달.

  Agent 사용 이전에는 한명의 코드 리뷰를 진행하는데에 30분에서 1시간 이상이 소모되었습니다. 시간이 부족하면 근거(파일 / 라인)까지 정교하게 남기기 어려웠습니다. 하지만 이러한 리뷰 시스템을 도입한 후에는 Cursor가 언급한 코드와 그 근처 코드들만 읽으면 되었고, 해당 코드가 왜 좋은 코드인지에 대한 리뷰 근거(파일:라인 / 함수 / 클래스)와 영향 설명을 함께 제공했습니다. 핵심 구간을 우선 확인할 수 있게 된 것입니다. 그래서 저는 더 짧은 시간에 근거 기반으로 코드 리뷰를 진행할 수 있었습니다. 그렇게 학생들은 훨씬 더 구체적이고 일관된 피드백을 받을 수 있게 되었습니다.

마치며: 구현자로서의 첫걸음

 이 시스템은 단순히 업무를 자동화한 것이 아닙니다. 튜터라는 역할을 수행함에 있어 나의 전문성이라는 엔진을 AI라는 부스터에 달아 효율을 극대화한 결과물입니다.
 수강생 십수 명에 대한 코드 리뷰가 소모만 되는 작업이 되지 않도록 반복되는 분석, 정리 파트를 자동화하고 저는 판단이 필요한 지점(설계 의도, 트레이드오프, 학습 방향성)에 시간을 더 배분할 수 있게 되었습니다. 오히려 더 깊이 있는 가이드에 집중할 여력이 생겼죠. 여러분도 본인의 업무에서 반복되는 '분석과 정리'의 패턴을 찾아보세요. 그것이 바로 여러분이 '구현자'로서 첫발을 내디딜 지점입니다.

긴 글을 마무리하며, 이 워크플로우가 어떤 분들에게 특히 필요했는지 궁금합니다.
아래 중 어디에 해당하시나요? 번호로 댓글만 남겨주시면 큰 힘이 됩니다.

1. 현업 개발자: PR/코드리뷰가 병목이고, 근거 기반 리뷰 표준화가 필요하다.
2. 팀 리더 / 테크리드: 리뷰 품질을 개인 역량이 아니라 팀 프로세스로 만들고 싶다.
3. 1인 / 프리랜서 / 창업 준비: 반복되는 분석·정리를 줄이고 납기/품질을 안정화하고 싶다.
4. 관심 독자: AI 워크플로우/프롬프트 설계 사례를 계속 보고 싶다.

현재 진행 중인 업무에 AI를 접목시킬 때, 어디를 자동화하고, 어디서 사람이 판단해야 하는지 설계가 고민이라면

방명록(또는 이메일)로 편하게 남겨주세요.

방명록 바로가기

이메일 주소 : chessire@naver.com

이전글