KIMKYUTAE.COM · ©
내 블로그를 만드는 중입니다 #1
블로그 만들기 한 달 된 시점, 그동안의 경험을 글로 정리한다.
0. 다시 내 블로그를 만들기로 했다
내 블로그를 처음 만든 것은 아니다.
인터넷을 오래 쓰다 보면 한 번쯤은 자기 이름이나 닉네임을 달고 홈페이지를 만들어 보고 싶어진다. 나도 그랬다. 도메인 주소를 사고, 서버를 연결하고, 게시판을 붙이고, 마음에 드는 스킨을 찾았다. 처음 며칠은 자주 들어가지만 시간이 지나면 글을 쓰는 횟수가 줄고, 어느 순간 관리가 끊긴다. 그렇게 만들어 놓고 방치한 경험이 여러 번 있었다.
그래서 이번에도 처음에는 거창하게 생각하지 않았다.
그냥 다시 블로그를 만들어 보자는 정도였다.
회사에서 하는 클라우드와 보안 업무 관련하여 공부한 내용을 정리할 곳이 필요했고, 집에서는 어항 같은 취미 이야기를 기록하고 싶었다. 그 외 나중에 다시 찾아볼 만한 내용도 남겨두고 싶었다. 검색해서 찾은 정보를 소비하기만 하지 말고, 내가 직접 겪은 내용도 인터넷 어딘가에 남겨두면 좋겠다는 생각이 컸다.
처음에는 글만 지속적으로 잘 쓰면 된다고 생각했다.
하지만 실제로 블로그를 운영해 보니 글 바깥에 있는 것들이 계속 눈에 들어왔다. 검색엔진은 내 블로를 제대로 알고 있는지, 각 글의 대표이미지는 너무 크지 않은지, 모바일에서는 글이 읽기 편한지, 추천글은 어디에 보여주는 것이 좋은지, 플러그인은 왜 이렇게 많아지는지 같은 문제였다.
특히 재미있었던 점은 하나를 고치면 다른 것이 보인다는 것이었다.
첫 화면에서 무한 스크롤 기능은 뒤로가기가 불편해서 이전/다음 버튼을 사용하는 페이지네이션으로 바꾸었다. 페이지네이션을 적용하고 나니 내가 지정해 둔 고정글 때문에 글 카드 개수가 어색해 보였다. 추천글을 넣고 나니 PC 화면에서의 정렬이 마음에 들지 않았다. 관련글을 태그 기준으로 바꾸고 나니 이제는 태그 체계가 엉성한 것이 보였다.
블로그를 만드는 일은 누군가 잘 만들어 놓은 테마를 적용하면 끝나는 일이 아니었다.
사용하는 과정에서 불편한 부분을 계속 발견하고, 조금 더 나은 방법으로 고치고, 필요 없는 것은 걷어내는 일이었다.
AI가 자연스레 이 과정에 깊이 들어왔다.
처음에는 문장을 다듬거나 정보를 정리하는 데 사용했다. 이후에는 대표이미지를 만들고, 삽화를 만들고, 검색엔진을 위한 SEO를 점검하고, 결국에는 WordPress에 직접 글 초안을 올릴 수 있는지까지 시도했다.
AI가 많은 일을 대신해 줄 수 있었지만 모든 선택을 대신해 주지는 못했다.
추천글을 세 개만 보여줄지 네 개를 보여줄지, 페이지네이션의 간격을 15픽셀로 할지 30픽셀로 할지, 태그를 화면에 많이 노출할지 감출지 같은 결정은 결국 내가 직접 블로그를 보면서 내려야 했다.
블로그 하나를 실제로 만들고 운영하면서 어떤 문제를 만났고, 무엇을 시도했으며, 어떤 것은 남기고 어떤 것은 버렸는지를 기록한다.
1. 워드프레스 블로그를 만들기로 했다
2026년 8월 14일, ChatGPT에 별생각 없이 한마디를 입력했다.
“워드프레스 블로그 만들려고 하는데.”
지금 돌아보면 이 한 문장이 시작이었다. 그때는 한 달 뒤 내가 페이지네이션의 간격을 조정하고, 관련글의 기준을 태그로 할지 카테고리로 할지 고민하고, 추천글이 두 개일 때와 세 개일 때 PC 화면에서 어떻게 보여야 하는지를 따지고 있을 거라고는 생각하지 못했다.
처음부터 거창한 계획이 있었던 것은 아니다. 사용할 도메인 주소는 이미 가지고 있었고, 예전부터 개인 홈페이지와 블로그를 여러 번 만들었다가 방치한 경험도 있었다. 이번에는 오래 운영할 수 있는 공간을 하나 제대로 만들어 보고 싶었다.
SNS는 편하다. 계정을 만들면 바로 글을 쓸 수 있고, 별다른 설정을 하지 않아도 모바일에서 잘 보인다. 반면 개인 블로그는 시작부터 선택할 것이 많다. 도메인 주소를 어디에서 관리할지, 호스팅은 어디를 쓸지, 테마는 무엇으로 할지부터 정해야 한다.
그럼에도 SNS 대신 다시 워드프레스를 선택한 이유는 간단했다.
SNS의 소통 의무감에 지치기도 했거니와, 내가 쓴 글과 이미지, 블로그의 구조를 가능한 한 내가 원하는 방식으로 관리하고 싶었기 때문이다.
개인 블로그에 필요한 것은 생각보다 단순했다.
- 글을 쓸 수 있어야 하고,
- 사진과 영상을 올릴 수 있어야 하고,
- 검색엔진에서 찾을 수 있어야 하고,
- PC와 모바일에서 모두 보기 편해야 했다.
그리고 무엇보다 내가 계속 손을 대고 고칠 수 있어야 했다.
이 조건만 놓고 보면 워드프레스는 여전히 매력적이었다. 대신 자유도가 높은 만큼 직접 결정해야 할 것도 많았다.
도메인 주소는 가지고 있던 kimkyutae.com을 그대로 사용하기로 했다. 호스팅은 Cafe24, 도메인 관리는 가비아를 사용하는 형태였다. 아주 특별한 구성이 아니라 오히려 국내에서 개인이 워드프레스를 시작할 때 흔히 접할 수 있는 조합이었다.
처음에는 블로그를 빠르게 만들어 놓는 것이 중요하다고 생각했다. 그래서 완벽한 디자인을 먼저 만들기보다 기본 구조부터 잡았다. 블로그 제목을 정하고, 메뉴를 만들고, 글의 주제를 나눴다.
내 블로그에서 다루고 싶었던 것은 크게 네 가지였다.
- 회사에서 하는 일과 연결되는 클라우드 보안,
- 오랫동안 취미로 해 온 어항과 생물 이야기,
- 컴퓨터와 각종 기기를 만지며 알게 된 것들,
- 그리고 어디에도 딱 들어가지 않는 일상 기록이었다.
나중에는 카테고리를 Aquarium, Cloud Security, Tech, Diary처럼 조금 더 세분화했지만, 처음부터 체계가 완성되어 있었던 것은 아니다. 글을 실제로 쓰면서 비슷한 글이 쌓이고 나서야 어떤 분류가 필요한지 보이기 시작했다.
이 과정에서 한 가지 원칙이 생겼다.
처음부터 완벽한 구조를 만들려고 하지 말자.
블로그는 글이 쌓이기 전에는 어떤 구조가 좋은지 알기 어렵다. 카테고리 하나를 추가하는 것도 실제 글이 몇 개 생긴 뒤에 판단하는 편이 낫다. 메뉴 위치나 글 목록 모양도 마찬가지였다.
처음 화면을 만들 때는 눈에 보이는 부분에 신경을 많이 썼다. 로고, 파비콘, 대표이미지, 폰트, 카드 모양, 여백 같은 것들이다. 하나씩 손을 대면 분명 더 나아지는 것 같았지만, 어느 순간부터 디자인보다 운영이 더 중요하다는 사실을 알게 됐다.
예를 들어 첫 화면에서 글 목록이 예쁘게 보이는 것보다 중요한 것은, 글 하나를 읽고 뒤로가기 버튼을 눌렀을 때 자연스럽게 원래 위치로 돌아오는 것이었다. 각 글의 대표이미지의 색을 맞추는 것보다 중요한 것은 수십 장의 이미지가 쌓였을 때 파일과 ALT(그림 설명)을 관리할 수 있는 것이었다. 워드프레스 플러그인 하나로 원하는 기능을 추가하는 것보다 중요한 것은 그 플러그인을 몇 달 뒤에도 계속 유지할 이유가 있는지였다.
하지만 이런 것들은 처음 블로그를 만들던 날에는 알 수 없었다.
처음에는 그저 블로그 화면이 하나 생긴 것이 재미있었다.
빈 블로그에 첫 글이 올라가고, 로고가 생기고, 메뉴를 눌렀을 때 내가 정한 카테고리로 이동했다. 다른 사람이 만들어 놓은 서비스에 계정 하나를 만든 것과는 느낌이 달랐다.
내 이름으로 된 주소로 접속하는 내 공간이었다.
그렇게 내 블로그가 만들어졌다.
물론 진짜 시작은 그다음부터였다.
블로그를 만들었으니 이제 사람들이 검색해서 들어올 수 있어야 했다. 검색엔진에 블로그를 알려야 했고, 사이트맵이라는 것도 신경 써야 했다. 글에 사진을 넣다 보니 이미지 파일명과 ALT가 눈에 들어오기 시작했고, 공유했을 때 나오는 썸네일도 마음에 걸렸다.
하나를 해결하면 그 뒤에 있던 문제가 보였다. 그리고 나는 거의 매일 하나씩 고치기 시작했다.
돌이켜보면 지금의 블로그는 8월 14일에 만든 것이 아니다. 8월 14일부터 매일 조금씩 고친 결과에 더 가깝다.
그래서 이 글에서도 ‘워드프레스를 이렇게 설치하면 된다’는 식으로만 이야기하고 싶지는 않다. 실제로 블로그를 운영하면서 어떤 부분이 불편했고, 왜 설정을 바꿨고, 결국 어떤 선택을 남겼는지를 순서대로 기록하려고 한다.
초기 설치 자체는 몇 시간이면 끝날 수 있다. 하지만 내 블로그가 되는 데에는 시간이 조금 더 필요했다.
2. 일단 블로그처럼 보이게 만들기
처음 워드프레스를 설치하고 나면 의외로 허전하다.
관리자 화면은 분명 존재하고 글도 쓸 수 있는데, 아직 ‘내 블로그’라는 느낌은 잘 들지 않는다. 기본 테마와 기본 메뉴, 아무 설명도 없는 카테고리만 놓고 보면 빈 사무실에 책상만 들여놓은 것과 비슷하다.
그래서 가장 먼저 한 일은 블로그의 성격을 정하는 것이었다.
내 블로그에서 다루고 싶은 주제는 한 가지가 아니었다. 회사 업무를 위한 클라우드 보안 관련 공부 이야기가 있었고, 집에서 하는 어항과 생물 이야기가 있었으며, 컴퓨터와 각종 기기를 사용하면서 알게 된 내용도 있었다. 가끔은 여행이나 일상도 기록하고 싶었다.
처음부터 카테고리를 세밀하게 나누기보다는 실제로 글을 쓰면서 필요한 분류를 만들었다. Aquarium, Cloud Security, Tech, Diary 같은 구조도 처음부터 완성된 설계도가 있었던 것은 아니다. 비슷한 글이 몇 개 쌓이면서 자연스럽게 구분이 필요해졌다.
여기서 처음 배운 것은 메뉴와 카테고리는 보기 좋게 만드는 장식이 아니라는 점이었다.
방문자는 메뉴를 보고 이 블로그가 무엇을 다루는 곳인지 짐작한다. 나 역시 글을 쓸 때 어디에 넣을지 고민하면서 블로그의 범위를 다시 확인하게 된다. 카테고리가 너무 많으면 오히려 블로그의 성격이 흐려지고, 너무 적으면 서로 다른 글이 한곳에 섞인다.
블로그 소개 문구도 비슷했다.
결국 “클라우드와 보안, 어항과 일상을 기록합니다.”라는 식으로 정리했다. 아주 멋있는 문장은 아니지만 지금 블로그에서 무엇을 볼 수 있는지를 한 줄로 설명해 준다. 개인 블로그의 소개 문구는 광고 문구처럼 거창할 필요가 없다고 생각했다.
디자인에서는 극단적으로 심플한 Blocksy 테마를 중심으로 하나씩 조정했다.
처음에는 테마 설정에서 바꿀 수 있는 것이 너무 많아 보였다. 헤더 높이, 콘텐츠 폭, 카드 모양, 폰트, 사이드바, 푸터, 모바일 메뉴까지 손댈 수 있었다. 조금만 만져도 화면이 달라지니 재미있었지만, 동시에 끝이 없었다.
그래서 어느 순간 기준을 바꿨다.
‘더 예쁜가?’보다 ‘계속 글을 읽기 편한가?’를 먼저 보기로 했다.
본문 폰트는 깔끔한 Pretendard를 사용하고, 글자 크기와 줄 간격을 읽기 편한 쪽으로 맞췄다. PC에서만 보기 좋은 화면보다 휴대폰에서도 답답하지 않은 구성을 우선했다. 눈에 띄는 효과나 애니메이션보다는 여백과 정렬이 더 중요했다.
로고, 파비콘, OG 이미지도 차례로 손봤다.
이 작업들은 하나하나 보면 작은 설정이지만 블로그 전체 인상을 만드는 요소였다. 브라우저 탭에 파비콘이 보이고, 링크를 공유했을 때 대표이미지가 제대로 나오기 시작하니 그제야 조금씩 “블로그”처럼 느껴졌다.
대표이미지를 만들면서도 시행착오가 있었다.
글마다 다른 분위기로 이미지를 만들면 처음에는 재미있지만 목록에서 여러 장을 한꺼번에 보면 블로그가 산만해 보였다. 그래서 이미지 비율을 특정 비율로 맞추고, 제목을 너무 길게 넣지 않고, 전체적인 색감과 구성을 어느 정도 통일하기 시작했다.
그렇다고 모든 이미지를 똑같이 만들지는 않았다.
어항 글은 실제 생물과 수조 사진이 중심이어야 했고, 클라우드 보안 공부 글은 내용을 한눈에 이해할 수 있는 간단한 도식이 더 어울렸다. 통일감은 필요하지만 콘텐츠의 성격까지 지워버리면 재미가 없었다.
블로그를 ‘블로그처럼 보이게’ 만드는 데에는 사실 멋진 기능이 많이 필요하지 않았다.
일관된 글 목록, 읽기 편한 본문, 알아보기 쉬운 메뉴, 비슷한 규칙으로 만든 대표이미지. 이 정도가 잡히자 화면이 훨씬 안정적으로 보였다.
그리고 여기서부터 다음 문제가 생겼다.
보기 좋게 만들었으니 이제 누군가 검색해서 들어올 수 있어야 했다.
3. 검색되는 블로그를 만들고 싶어졌다
블로그가 생기고 글을 몇 개 올린 뒤에는 자연스럽게 검색창에서 내 글을 찾아봤다.
주소를 직접 입력하면 잘 열리는데 검색에서는 잘 보이지 않았다.
생각해 보면 당연했다. 내가 블로그를 만들었다고 해서 구글이나 네이버가 바로 모든 페이지를 알고 있는 것은 아니다. 검색엔진이 블로그를 발견하고, 페이지를 수집하고, 어떤 내용인지 판단할 시간이 필요하다.
그래서 Google Search Console과 네이버 서치어드바이저를 설정했다.
처음에는 단순히 블로그 주소만 등록하면 끝나는 줄 알았다. 옛날 옛적에는 그랬는데…
실제로는 블로그 소유권을 확인하고, 사이트맵을 제출하고, RSS도 확인했다. 검색엔진에 내 블로그의 구조를 알려주는 과정이 필요했다.
사이트맵은 특히 처음 접하면 조금 과장돼 보이는 용어다.
하지만 역할은 단순했다. 내 블로그에 어떤 페이지들이 있는지를 검색엔진이 효율적으로 찾을 수 있도록 목록을 제공하는 것이다. 워드프레스에서는 관련 기능을 직접 만들 필요 없이 기본 기능이나 SEO 플러그인이 처리해 주기 때문에 사용자는 주소가 정상적으로 열리는지 확인하고 제출하는 정도면 충분했다.
검색 등록을 하면서 robots.txt, 색인 상태, canonical 같은 단어도 자연스럽게 접했다.
처음에는 모든 항목을 완벽하게 이해해야 할 것처럼 느껴졌다. 하지만 실제 운영에서는 문제가 생겼을 때 필요한 항목부터 확인하는 편이 낫다는 생각이 들었다.
예를 들어 내 블로그가 정상적으로 열리고 사이트맵이 제출되어 있으며 검색엔진이 페이지를 수집할 수 있다면, 당장 모든 SEO 옵션을 건드릴 필요는 없다.
검색 노출을 빨리 만들겠다고 설정을 계속 바꾸는 것도 오히려 좋지 않았다. 검색엔진은 시간이 필요했다.
내가 할 수 있는 일은 페이지 구조를 이상하게 만들지 않고, 제목을 명확하게 쓰고, 실제로 도움이 되는 글을 계속 올리는 것이었다.
이때부터 글 제목을 조금 다르게 보기 시작했다. 내가 보기 좋은 제목과 검색하는 사람이 입력할 제목이 항상 같지는 않았다.
예를 들어 기술 글에서 지나치게 추상적인 제목을 쓰면 멋있어 보일 수는 있지만 무슨 내용인지 바로 알기 어렵다. 그래서 ‘Cloud Firewall과 Security Group 비교’, ‘VLAN Hopping이란 무엇인가’처럼 핵심 용어가 제목에 드러나는 방식을 선호하게 됐다.
어항 글도 비슷했다.
영상 하나를 올리더라도 제목에 베타인지 히말라야뉴트인지, 물멍인지 피딩인지 알 수 있도록 했다. 검색을 의식한다고 해서 제목을 부자연스럽게 키워드로 채우는 것이 아니라, 내용을 정확히 설명하는 제목을 쓰는 쪽이었다.
SEO를 공부하면서 가장 경계하게 된 것은 점수였다.
SEO 플러그인에는 제목 길이, 설명 길이, 키워드 사용 여부 등을 평가하는 기능이 있다. 이런 도구는 빠진 항목을 확인하는 데에는 도움이 되지만 높은 점수를 받는 것이 좋은 글의 목적은 아니다.
검색엔진보다 내 글을 읽는 사람을 먼저 생각해야 한다.
메타 설명도 마찬가지였다. 검색 결과에서 보일 수 있는 짧은 소개문이기 때문에 글 내용을 과장하지 않고, 무엇을 다루는지 간단하게 설명하는 정도로 작성했다.
검색 등록을 마치고 바로 방문자가 몰려온 것은 당연히 아니다. 그 대신 한 가지 변화가 생겼다.
이제 글을 올릴 때 블로그 안에서만 보이는 글이 아니라 인터넷 전체에서 발견될 수 있는 글이라는 생각을 하게 됐다.
제목, URL, 이미지, 카테고리, 태그를 조금 더 신경 쓰게 된 것도 그때부터였다.
결국 검색 최적화는 검색엔진을 속이는 기술이 아니라 내가 만든 콘텐츠의 구조를 조금 더 명확하게 만드는 작업에 가까웠다.
그리고 그 과정에서 가장 먼저 눈에 들어온 것이 이미지였다.
4. 이미지 하나에도 신경 쓸 것이 많았다
블로그를 깊이 만들기 전에는 이미지는 그냥 글에 넣으면 끝이라고 생각했다.
워드프레스 미디어 라이브러리를 사용하다 보니 생각보다 신경 쓸 것이 많았다. 파일명, 이미지 크기, 용량, ALT 텍스트, 제목, 대표이미지, OG 이미지까지 하나씩 눈에 들어왔다.
처음에는 사진 한두 장이라 크게 문제가 되지 않았다. 하지만 글이 늘어나고 AI로 만든 대표이미지와 삽화까지 쌓이기 시작하자 관리 기준이 필요했다.
가장 먼저 정한 것은 이미지 크기와 용량이었다.
웹페이지에서 필요 이상으로 큰 원본 이미지를 그대로 사용하는 것은 의미가 없었다. 화면에는 800픽셀 정도로 보이는데 몇 천 픽셀짜리 이미지를 올리면 저장 공간과 전송량만 늘어난다. 다시 말해 호스팅 비용이 상승한다.
그래서 블로그 삽화는 폭을 800픽셀 이하로 줄이고, 최종 파일은 1MB를 넘기지 않는 식으로 기준을 만들었다. 대표이미지도 16:9 비율로 통일했다. 이 기준은 디자인 규칙이기도 했지만 성능 규칙이기도 했다.
이미지 품질을 무조건 낮추는 것은 원하지 않았다. 대신 실제 화면에서 차이가 거의 보이지 않는 범위에서 용량을 줄이는 것이 목표였다.
ALT 텍스트도 처음에는 SEO 항목 중 하나 정도로 생각했다.
하지만 내용을 확인해 보면서 이미지 ALT는 검색엔진만을 위한 것이 아니라 이미지가 보이지 않거나 스크린리더를 사용하는 경우에도 의미를 전달하는 텍스트라는 점을 다시 보게 됐다.
그래서 ‘image123’ 같은 값 대신 실제 이미지가 무엇을 보여주는지 자연스럽게 적으려고 했다.
여기서 재미있는 문제도 만났다.
워드프레스 관리자에서 이미지 ALT를 수정했다고 생각했는데 HTML 소스를 확인해 보면 내가 기대한 위치에 반영되지 않는 경우가 있었다. 본문의 img 태그에 들어가는 alt와 소셜 공유에 사용되는 og:image:alt는 역할이 달랐다.
이 차이를 직접 확인하면서 ‘관리자 화면에서 저장했으니 됐겠지’라고 생각하는 것보다 최종 페이지 결과를 보는 습관이 생겼다.
보안 업무에서도 설정값보다 실제 동작을 확인하는 것이 중요하다. 블로그도 크게 다르지 않았다.
대표이미지는 콘텐츠의 첫인상이어서 조금 더 규칙을 만들었다.
처음에는 이미지 안에 설명을 많이 넣기도 했다. 그런데 모바일에서 보면 글자가 작아지고, 글 목록에서도 복잡해 보였다. 이후에는 대표이미지에는 제목 정도만 넣거나 아예 최소한의 텍스트만 사용하는 방향으로 바꿨다.
반대로 본문 삽화는 설명을 위해 존재하기 때문에 구조가 한눈에 보여야 했다.
클라우드 보안 공부 글에서는 밝은 배경, 단순한 아이콘, 몇 가지 파스텔 계열 색을 사용한 도식 스타일을 정했다. 글마다 그림체가 달라지지 않도록 어느 정도 동일한 규칙을 적용했다.
어항 글은 다르게 접근했다.
실제 베타나 뉴트의 모습이 가장 중요한 글에 굳이 인포그래픽 스타일 이미지를 넣을 이유는 없었다. 직접 찍은 사진이나 영상을 중심으로 사용하고 대표이미지만 정돈했다.
이렇게 이미지 유형별로 역할을 나누자 작업이 쉬워졌다.
대표이미지는 글의 얼굴, 본문 사진은 실제 경험의 기록, 삽화는 복잡한 내용을 설명하는 도구.
미디어 라이브러리를 정리할 때는 사용되지 않는 이미지를 찾고 제목 앞에 “검토필요” 표시를 붙이는 방식도 사용했다. 파일이 계속 쌓이면 어떤 이미지가 실제 글에서 사용되고 있는지 구분하기 어려워지기 때문이다.
블로그를 오래 운영하려면 작성할 때의 편리함만큼 나중에 정리하기 쉬운 구조도 중요했다.
이 작업을 하면서 한 가지 사실을 확실히 알게 됐다.
이미지는 글에 붙이는 부속물이 아니었다. 속도, 검색, 디자인, 접근성에 모두 영향을 주는 콘텐츠의 일부였다.
5. 글을 쓰는 방식도 바뀌었다
블로그를 다시 시작했을 때 가장 쉬운 주제는 내가 이미 알고 있는 내용을 적는 것이었다.
어항 물을 갈면서 느낀 점, 새로 산 조명을 사용한 후기, Mac에서 한영키를 설정했던 방법처럼 직접 경험한 내용은 비교적 쉽게 쓸 수 있었다.
문제는 기술 글이었다.
클라우드 보안이나 네트워크 같은 주제를 다루면 사실관계가 중요하다. 내가 알고 있다고 생각하는 내용도 정확한 용어나 최신 정책을 확인할 필요가 있었다.
그래서 글 쓰는 방식이 점차 세 단계로 정리됐다.
- 먼저 내가 경험하거나 알고 있는 내용을 적는다.
- 그다음 공식 문서나 신뢰할 수 있는 자료로 변할 수 있는 부분을 확인한다.
- 마지막으로 실제 운영 환경에서 무엇을 봐야 하는지를 추가한다.
예를 들어 Cloud Firewall과 Security Group을 비교하는 글을 쓴다면 단순히 기능 차이만 표로 정리하는 것으로 끝내지 않았다. 어느 계층에서 동작하는지, 중앙 통제가 필요한 경우 어떤 방식이 유리한지, 관리 포인트가 분산되었을 때 어떤 문제가 생길 수 있는지까지 생각했다.
내가 보안 업무를 하다 보니 자연스럽게 공격자 관점과 방어자 관점을 같이 보게 됐다.
- 공격자는 어떤 설정 오류를 이용할 수 있는가.
- 방어자는 무엇을 로그로 확인해야 하는가.
- 사고가 났을 때 영향 범위를 어떻게 줄일 수 있는가.
이런 질문이 글에 들어가면 단순한 기능 설명보다 실제 운영에 가까워졌다.
반면 어항 글에서는 지나치게 기술 보고서처럼 쓰지 않으려고 했다.
수온이나 EC 같은 수치를 기록할 때도 있었지만 중요한 것은 내가 왜 그렇게 관리했는지였다. 베타가 어떻게 움직였는지, 뉴트가 어떤 먹이에 반응했는지처럼 개인적인 관찰이 글의 중심이 되어야 했다.
기술 글과 취미 글의 문체가 완전히 같을 필요는 없었다.
다만 두 종류 모두 공통적으로 피하려고 한 것이 있었다. 확실하지 않은 내용을 아는 것처럼 쓰지 않는 것이다.
어항에서도 생물의 행동 원인을 단정하기 어려운 경우가 많고, 클라우드 서비스 역시 정책과 기능이 계속 바뀐다. 이럴 때는 추정이라고 표시하거나 최신 문서를 다시 확인하는 편이 낫다.
AI를 사용하면서 이 원칙은 더 중요해졌다.
AI는 문장을 자연스럽게 만들어 주기 때문에 잘못된 내용도 그럴듯하게 보일 수 있다. 그래서 결과물을 그대로 게시하는 방식보다 내가 내용을 읽고 수정하는 과정이 반드시 필요했다.
실제로 블로그 글을 만들 때 AI에 맡기는 부분과 내가 직접 결정하는 부분이 조금씩 구분되기 시작했다.
자료를 구조화하고 초안을 만드는 것은 AI가 빠르다. 하지만 내가 실제로 사용해 본 제품의 느낌, 특정 설정을 왜 선택했는지, 글에서 어느 부분을 강조할지는 내가 더 잘 안다.
그래서 AI가 작성한 문장에서 과장된 표현이나 보고서 같은 문체가 보이면 많이 덜어냈다.
‘혁신적이다’, ‘최적의 솔루션이다’ 같은 표현은 개인 블로그에는 잘 어울리지 않았다. 내가 원하는 글은 조금 더 담백했다.
“써보니 이 부분이 편했다.” / “이 설정은 결국 끄기로 했다.” / “처음에는 이렇게 생각했는데 실제로는 달랐다.”
이런 문장이 많을수록 오히려 내 글처럼 느껴졌다.
글이 늘어나면서 블로그의 역할도 조금 달라졌다.
처음에는 다른 사람이 읽는 글을 쓴다고 생각했지만, 시간이 지나자 미래의 내가 다시 찾아보는 노트이기도 했다.
OSCP 공부를 하며 정리한 명령어, Mac 설정 방법, WordPress에 적용한 CSS, 어항 여과재 구성처럼 몇 달 뒤에는 기억나지 않을 수 있는 내용들을 검색해서 다시 볼 수 있었다.
좋은 개인 블로그는 남에게 보여주는 공간이면서 동시에 나를 위한 검색 가능한 기록일지도 모른다.
그리고 기록을 더 빠르고 보기 좋게 만드는 데 AI가 본격적으로 들어오기 시작했다.
다음 글: 내 블로그를 만드는 중입니다 #2
