KIMKYUTAE.COM · ©
내 블로그를 만드는 중입니다
“워드프레스 블로그 만들려고 하는데”
2026년 8월 14일, ChatGPT에 별생각 없이 한마디를 입력했다.
“워드프레스 블로그 만들려고 하는데.”
지금 돌아보면 이 한 문장이 시작이었다. 그때는 한 달 뒤 내가 페이지네이션의 간격을 조정하고, 관련글 기준과 태그 체계를 고민하고, AI가 워드프레스 임시글까지 작성하게 만들고 있을 것이라고는 생각하지 못했다. 그냥 다시 블로그를 하나 만들어 보자는 정도였다.
내 블로그를 처음 만든 것은 아니다. 예전에도 도메인을 사고 서버를 연결하고 게시판과 스킨을 꾸민 적이 여러 번 있었다. 처음 며칠은 자주 들어갔지만 시간이 지나면 글을 쓰는 횟수가 줄었고, 어느 순간 관리가 끊기곤 했다. 만드는 과정은 재미있었지만 계속 운영하는 일은 생각보다 어려웠다.
그런 경험이 있으면서도 다시 개인 블로그를 만들고 싶었던 이유는 기록할 것이 생겼기 때문이다. 회사에서 하는 클라우드·보안 업무와 관련해 공부한 내용을 정리할 곳이 필요했다. 집에서는 어항과 생물 이야기를 남기고 싶었고, 컴퓨터와 각종 기기를 사용하면서 알게 된 내용도 나중에 다시 찾아보고 싶었다.
SNS에 올리는 방법도 있었지만 나에게는 잘 맞지 않았다. 계정을 만들면 바로 글을 쓸 수 있고 사람들과 연결되기 쉽다는 장점이 있지만, 소통해야 한다는 의무감이 생길 때가 있었다. 무엇보다 내가 쓴 글과 이미지, 메뉴와 글 목록의 모양까지 가능한 한 내가 원하는 방식으로 관리하고 싶었다.
그래서 다시 워드프레스를 골랐다. 도메인은 가지고 있던 kimkyutae.com을 사용했고, 당시 호스팅은 Cafe24, 도메인 관리는 가비아를 이용했다. 처음부터 거창한 구조를 설계하지는 않았다. 블로그 제목과 소개 문구를 정하고 Aquarium, Cloud Security, Tech, Diary처럼 큰 주제만 나눴다. 어떤 카테고리와 태그가 필요한지는 글을 실제로 써본 뒤 정해도 늦지 않다고 생각했다.
워드프레스를 설치한 직후의 화면은 의외로 허전했다. 관리자 화면도 있고 글도 쓸 수 있었지만 아직 ‘내 블로그’라는 느낌은 잘 들지 않았다. 빈 사무실에 책상만 하나 놓인 것과 비슷했다. Blocksy 테마를 적용하고 헤더와 메뉴를 정리하고 로고와 파비콘을 넣었다. 빈 블로그에 첫 글이 올라가고 메뉴를 눌렀을 때 내가 정한 카테고리로 이동했다.
다른 서비스에 계정 하나를 만든 것과는 느낌이 달랐다. 내 이름으로 된 주소로 접속하는 내 공간이 생겼다. 화면을 몇 번이나 새로 열어보는 것만으로도 재미있었다.
블로그 화면이 생기자 바로 다음 궁금증이 생겼다. 주소를 직접 입력하는 나 말고, 다른 사람도 이 블로그를 찾을 수 있을까.
블로그가 생기니 다음 문제가 보였다
글을 몇 개 올린 뒤 구글과 네이버에서 내 글 제목을 검색해 봤다. 블로그 주소를 직접 입력하면 잘 열리는데 검색 결과에서는 좀처럼 보이지 않았다. 지금 생각하면 당연한 일이었다. 내가 블로그를 만들었다고 해서 검색엔진이 바로 모든 페이지를 알고 있는 것은 아니었다.
Google Search Console과 네이버 서치어드바이저에 블로그를 등록하고 사이트맵을 제출했다. 검색엔진이 사이트를 발견하고, 페이지를 수집하고, 무슨 내용인지 판단하는 과정이 필요했다. robots.txt, canonical, 색인 같은 낯선 단어도 그때부터 하나씩 눈에 들어왔다.
처음에는 모든 설정을 완벽하게 이해해야 할 것처럼 느껴졌다. 하지만 실제로는 블로그가 정상적으로 열리고 사이트맵을 읽을 수 있으며 페이지 수집을 막고 있지 않은지부터 확인하면 됐다. 검색 노출을 빨리 만들겠다고 설정을 자주 바꾸는 것보다 정상적인 구조를 유지하면서 글을 쌓는 편이 나았다.
검색을 신경 쓰기 시작하니 글 제목을 보는 기준도 달라졌다. 내가 보기 좋은 제목과 검색하는 사람이 입력할 제목이 항상 같지는 않았다. 기술 글은 핵심 용어가 제목에 드러나야 무슨 내용인지 바로 알 수 있었다. 그렇다고 제목을 키워드로 길게 채우고 싶지는 않았다. 짧지만 내용을 정확히 설명하는 제목이 나에게는 더 잘 맞았다.
SEO 플러그인의 점수는 빠진 항목을 확인하는 데 도움이 됐지만 높은 점수 자체가 목적은 아니었다. 검색엔진보다 글을 읽는 사람을 먼저 생각해야 했다. 결국 검색 최적화는 검색엔진을 속이는 기술이 아니라 내가 만든 콘텐츠의 구조를 조금 더 명확하게 만드는 작업에 가까웠다.
검색 결과에서 제목과 설명이 어떻게 보일지 확인하다 보니 공유할 때 나타나는 썸네일도 눈에 들어왔다. 모바일에서 글 목록을 보니 대표이미지 안의 긴 문구는 너무 작게 보였다. 검색을 해결하려고 시작한 일이 자연스럽게 이미지 관리 문제로 이어졌다.
이미지 하나에도 기준이 필요했다
블로그를 깊이 만들기 전에는 이미지는 글에 넣기만 하면 끝이라고 생각했다. 사진 한두 장일 때는 문제가 없었지만 글이 늘어나고 대표이미지와 본문 삽화까지 쌓이기 시작하자 미디어 라이브러리가 금방 복잡해졌다.
파일명, 이미지 크기, 용량, 대체 텍스트, 대표이미지와 OG 이미지가 서로 다른 문제라는 것도 알게 됐다. 관리자 화면에서 대체 텍스트를 저장했다고 생각했는데 최종 HTML을 확인하면 기대한 위치에 반영되지 않은 경우도 있었다. 본문의 alt와 소셜 공유에 사용하는 og:image:alt는 비슷해 보여도 역할이 달랐다.
보안 업무에서도 설정 화면에 입력된 값보다 실제로 어떻게 동작하는지를 확인하는 것이 중요하다. 블로그도 크게 다르지 않았다. 관리자 화면에서 저장 버튼을 눌렀다고 끝내지 않고 실제 페이지와 HTML을 확인하는 습관이 생겼다.
이미지 크기와 용량에는 기본 규칙을 만들었다. 본문 삽화는 폭 800픽셀 이하, 1MB 이내로 정했다. 대표이미지는 960×540픽셀의 16:9 비율과 WebP 형식을 사용하고 70~150KB를 목표로 하되 200KB를 넘기지 않도록 했다. 목표보다 작아도 실제 화면에서 품질 저하가 보이지 않으면 그대로 사용했다.
이미지 안에 글자를 많이 넣는 것도 줄였다. PC에서는 잘 보이던 문구가 휴대폰과 글 목록에서는 작아졌다. 대표이미지에는 제목 정도만 크게 넣거나 글자를 아예 최소화했다. 대신 본문 삽화는 화려함보다 구조와 흐름을 한눈에 보여주는 데 집중했다.
어항 글에는 다른 기준을 적용했다. 베타나 히말라야뉴트의 실제 모습이 중요한 글에 굳이 인포그래픽을 넣을 이유는 없었다. 직접 찍은 사진과 영상을 중심으로 사용하고 대표이미지만 정돈했다. 반면 클라우드·보안 글에서는 직접 찍을 사진이 거의 없었기 때문에 설명용 그림이 필요했다.
처음에는 무료 이미지 사이트에서 서버실이나 자물쇠 사진을 찾았다. 하지만 특정 기술의 흐름을 설명하기에는 한계가 있었다. 이때부터 AI로 대표이미지와 삽화를 만들기 시작했다. 글을 다듬는 데 사용하던 AI가 이미지 제작까지 들어오면서 블로그를 만드는 방식도 조금씩 달라졌다.
AI가 글쓰기 안으로 들어왔다
처음 AI를 블로그에 사용한 이유는 단순했다. 내가 쓴 초안에 맞춤법이 틀린 부분이 있는지, 사실관계가 잘못된 내용은 없는지 확인하고 싶었다. 그러다 제목 후보와 목차, SEO 설명, 태그를 제안받기 시작했고 어느새 글의 초안을 함께 만드는 단계까지 왔다.
직접 경험한 글은 비교적 쓰기 쉬웠다. 어항 물을 갈면서 느낀 점이나 새 조명을 사용한 후기, Mac에서 한영키를 설정한 방법은 기억을 따라가며 적을 수 있었다. 반면 클라우드 보안과 네트워크 글은 알고 있다고 생각하는 내용도 정확한 용어와 최신 정책을 다시 확인해야 했다.
그래서 기술 글을 쓸 때는 먼저 내가 경험하거나 알고 있는 내용을 적고, 공식 문서와 신뢰할 수 있는 자료로 변할 수 있는 부분을 확인했다. 그다음 실제 운영 환경에서 무엇을 확인해야 하는지를 추가했다. 기능 차이를 표로 정리하는 데서 끝내지 않고 공격자가 어떤 설정 오류를 이용할 수 있는지, 방어자는 어떤 로그를 봐야 하는지, 사고의 영향 범위를 어떻게 줄일지까지 생각했다.
어항 글에서는 반대로 지나치게 기술 보고서처럼 쓰지 않으려고 했다. 수온이나 EC를 기록하더라도 중요한 것은 내가 왜 그렇게 관리했는지였다. 베타가 어떻게 움직였는지, 뉴트가 어떤 먹이에 반응했는지처럼 직접 관찰한 내용이 중심이 되어야 했다.
AI에게 “좋은 글로 써줘”라고만 해도 무난하고 반듯한 글은 나온다. 문제는 내가 실제로 무엇을 했고 어디에서 불편했으며 왜 그 방법을 선택했는지가 빠지기 쉽다는 것이다. 읽기에는 그럴듯하지만 정작 내 글처럼 느껴지지 않았다.
그래서 요청하는 방식도 바뀌었다. “처음에는 이 설정을 썼는데 실제로는 이런 문제가 있었다.” “회사 보고서처럼 쓰지 말고 평소 사용하는 말투로 써라.” “확실하지 않은 내용은 추정이라고 표시해라.” 같은 정보를 함께 전달했다. 이런 맥락이 들어가야 결과가 내 경험에 가까워졌다.
AI가 만든 문장을 그대로 게시하지는 않았다. 과장된 표현과 지나치게 반듯한 문장을 덜어냈고, 내가 직접 하지 않은 일을 한 것처럼 쓴 부분은 지웠다. AI의 강점은 자료를 정리하고 초안을 빠르게 만드는 것이지만, 무엇을 남기고 어디까지 말할지는 결국 내가 결정해야 했다.
이미지 제작도 마찬가지였다. 처음 생성한 그림은 같은 글 안에서도 실사, 3D, 인포그래픽이 제각각이었다. 그래서 밝은 배경과 파스텔 색, 둥근 형태처럼 기본 스타일을 정했다. 한글이 틀리지 않았는지, 화살표의 방향이 맞는지, 본문에서 실제 정보가 너무 작게 보이지 않는지도 확인했다.
글과 이미지를 만드는 속도가 빨라지자 기록하고 싶은 것도 많아졌다. 특히 어항은 사진보다 영상이 더 잘 어울리는 순간이 많았다. 콘텐츠를 만드는 방법이 넓어지면서 블로그에 붙는 기능도 하나씩 늘어나기 시작했다.
하고 싶은 것은 늘고 플러그인은 쌓였다
베타가 수조 전체를 돌아다니는 모습이나 히말라야뉴트가 지렁이를 먹는 장면은 사진보다 영상으로 보는 편이 자연스럽다. 가장 간단한 방법은 YouTube에 올리고 링크를 넣는 것이었다. 하지만 개인 블로그 안에서 영상을 보여주는 경험을 조금 더 직접 관리하고 싶었고 광고도 보여주고 싶지 않았다.
여러 서비스를 찾아보다 Bunny.net의 Stream을 사용하기로 했다. 영상 파일을 웹 호스팅 서버에 직접 올리면 저장공간과 트래픽 부담이 커질 수 있다. 웹 호스팅은 글과 이미지에 집중하고 동영상은 전문 스트리밍 서비스에 맡기는 편이 구조적으로 깔끔했다.
영상을 넣을 수 있게 되자 모든 게시물이 긴 글일 필요는 없다는 생각도 들었다. ‘베타 물멍’처럼 영상 하나와 짧은 기록이면 충분한 글이 있었다. 기술 분석 글과 어항 영상, 짧은 사용 후기가 함께 있는 모습이 오히려 내가 원했던 개인 블로그에 가까웠다.
문제는 하고 싶은 일을 하나씩 추가할 때마다 플러그인도 늘어난다는 점이었다. SEO, 통계, 캐시, 영상, AI 연결처럼 필요해 보이는 기능마다 플러그인을 설치할 수 있었다. 처음에는 워드프레스의 가장 큰 장점처럼 보였고 실제로도 편리했다. 하지만 설치가 너무 쉬웠다.
어느 순간 관리자 화면의 플러그인 목록이 길어졌다. 정확히 왜 설치했는지 기억이 흐릿한 것도 있었고 서로 기능이 겹치는 경우도 있었다. 블로그와 관리자 화면이 느려지는 일이 반복되면서 이 플러그인이 없으면 무엇이 사라지는지 하나씩 확인하기 시작했다.
현재 사용하는가, 워드프레스나 테마의 기본 기능으로 대체할 수 있는가, 다른 플러그인과 역할이 겹치지 않는가를 봤다. 역할이 불분명한 플러그인은 먼저 비활성화하고 문제가 없는지 확인한 뒤 삭제했다. 켰을 때보다 껐을 때 블로그가 더 빠르게 느껴지는 기능도 있었다.
플러그인이 적으면 무조건 좋은 것은 아니다. Bunny Stream처럼 실제 작성 과정을 편하게 해주는 기능은 남길 이유가 있었다. 중요한 것은 개수가 아니라 역할이 분명한지였다. 사용하지 않는 플러그인을 줄이면 업데이트할 대상과 취약점 관리 범위도 함께 줄어든다.
성능 문제를 확인하는 과정에서 호스팅 환경도 다시 보게 됐다. Cafe24에서 겪은 느린 응답과 관리 제약을 계기로 결국 AWS Lightsail로 블로그를 옮겼다. 데이터만 복사한다고 이전이 끝나는 것은 아니었다. 도메인과 DNS, 인증서, 워드프레스 주소, 플러그인과 캐시까지 함께 확인해야 했다.
하나를 추가하고 문제가 생기면 다시 줄이고, 필요하면 기반 환경까지 바꾸는 과정이 이어졌다. 그런데 기능을 정리하는 와중에도 포기하지 못한 시도가 하나 있었다. AI가 초안을 만드는 데서 끝나지 않고 내 블로그에 직접 글을 등록하게 만드는 일이었다.
AI가 내 블로그에 직접 글을 쓰기까지
AI와 함께 글을 만드는 일이 익숙해지자 마지막 과정이 번거롭게 느껴졌다. 제목과 본문, 카테고리, 태그, SEO 정보와 이미지까지 이미 함께 만들고 있는데, 그것을 다시 복사해 워드프레스 편집기에 옮기고 있었다. 그렇다면 글 등록까지 연결할 수 있지 않을까.
처음에는 플러그인 하나만 설치하면 될 줄 알았다. 실제로는 WordPress.com과 직접 호스팅하는 WordPress의 차이, Jetpack 연결, 인증 방식과 권한을 이해해야 했다. 같은 WordPress라는 이름을 사용해도 서비스의 구조와 연결 방법은 달랐다.
몇 번의 연결 시도는 실패했다. 어느 계정으로 인증해야 하는지, 독립형 사이트에 쓰기 권한이 제대로 전달되는지, 플러그인이 필요한지부터 다시 확인해야 했다. 과정은 번거로웠지만 AI가 채팅창에서 초안을 보여주는 것과 실제 콘텐츠 시스템을 수정하는 것이 전혀 다른 문제라는 점을 직접 느낄 수 있었다.
가장 크게 달라지는 것은 권한이었다. AI가 워드프레스에 글을 만들거나 수정하려면 실제 쓰기 권한이 필요하다. 잘못된 요청이나 예상하지 못한 동작이 공개된 글에 영향을 줄 수도 있다. 편리함만 보고 바로 공개 권한을 맡기는 것은 마음에 들지 않았다.
그래서 기본 흐름을 정했다. AI가 글과 이미지를 만들고 워드프레스에는 임시글로 저장한다. 그다음 내가 관리자 화면에서 카테고리와 태그, 이미지 위치, 기술 내용과 말투를 확인한다. 마지막 공개는 내가 결정한다.
AI로 작성한 임시글을 검토한 뒤 공개하는 과정.
자동화가 사람을 없앤 것은 아니었다. 예전에는 본문을 처음부터 입력하는 데 시간을 썼다면 이제는 초안을 검토하고 선택하는 데 더 많은 시간을 쓴다. IT 업무에서 변경 작업에 검토와 승인 단계를 두는 것처럼 개인 블로그에서도 자동화의 속도와 사람의 최종 판단을 나누는 편이 안전했다.
내가 원했던 것은 AI가 알아서 운영하는 블로그가 아니었다. 내가 정한 방향을 더 빠르게 구현해 주는 블로그였다. 실제로 이 방식으로 글을 만들기 시작하자 작성 과정은 짧아졌지만, 블로그를 직접 사용하면서 발견하는 불편함까지 AI가 대신 알아줄 수는 없었다.
아직도 만드는 중이다
블로그를 어느 정도 만들어 놓고 실제로 자주 사용하기 시작하자 관리자 화면에서는 보이지 않던 문제가 하나씩 드러났다. 대표적인 것이 무한 스크롤이었다.
처음에는 페이지 번호를 누르지 않아도 다음 글이 나타나니 편해 보였다. 하지만 아래로 한참 내려가 글 하나를 읽은 뒤 뒤로가기를 눌렀을 때 이전 위치로 자연스럽게 돌아가지 않는 경우가 있었다. 화면이 매끄럽게 움직이는 것보다 글을 찾고 읽는 과정이 편한 것이 중요했다. 결국 이전·다음 버튼을 사용하는 페이지네이션으로 돌아갔다.
페이지네이션을 적용하자 고정글 때문에 첫 페이지의 카드 개수가 어색해 보였다. 그것을 고치고 나니 추천글의 정렬이 눈에 들어왔다. 추천글을 정리하자 바로 아래 관련글과 역할이 겹쳐 보였다. 하나를 고치면 그 뒤에 가려져 있던 다음 문제가 나타났다.
모든 경우를 CSS로 완벽하게 해결하려고 하면 코드는 계속 복잡해졌다. 그래서 추천글은 최대 세 개만 보여주기로 정했다. 기술적으로 네 개 이상을 자동 배치할 수도 있었지만 콘텐츠 운영 규칙을 단순하게 만드는 편이 유지하기 쉬웠다.
관련글의 기준을 카테고리에서 태그로 바꾸면서는 더 큰 일이 생겼다. 태그가 같아야 관련된 글로 연결된다면 더 이상 게시물 아래에 보이는 장식이 아니었다. 같은 뜻인데 영문 대소문자나 표기가 다른 태그를 정리하고, 제품명과 기술 용어는 블로그 전체에서 같은 이름을 사용하기로 했다.
추천글의 위치 하나를 고치려고 시작한 일이 결국 콘텐츠 전체의 구조를 다시 보게 만들었다. 방문자가 다음에 어떤 글을 읽을지 생각하는 것은 단순한 화면 배치가 아니라 콘텐츠 사이에 길을 만드는 일이었다.
이런 변화는 처음부터 계획할 수 없었다. 실제로 글을 쓰고 내가 직접 블로그를 사용했기 때문에 불편함이 보였다. 기능을 줄였더니 더 편해졌고, 복잡한 화면을 단순하게 만들었더니 글이 더 잘 보였다. 반대로 필요하다고 판단한 기능은 호스팅 환경까지 바꾸면서 남겼다.
한 달 동안 메뉴와 카테고리를 정리하고 검색엔진에 블로그를 등록했다. 이미지 규칙을 만들고 영상 서비스를 붙였으며, 플러그인을 설치했다가 지웠다. AI와 블로그를 연결했고 페이지네이션과 추천글, 관련글과 태그 체계도 계속 바꿨다.
처음 블로그를 만들 때 이 모든 작업을 계획하는 것은 불가능했을 것이다. 지금 다시 시작한다면 더 빠르게 만들 수는 있겠지만 모든 것을 완벽하게 설계하려고 하지는 않을 것 같다. 기본 구조를 만든 뒤 글을 쓰고, 실제로 불편한 부분을 하나씩 고칠 것이다.
그동안의 경험을 돌아보니 블로그에서 가장 중요한 것은 테마도, 플러그인도, SEO 점수도 아니었다.
글을 계속 쓸 수 있는 환경인가?
대표이미지 규칙과 태그 표준화는 새 글마다 같은 고민을 반복하지 않기 위해 만들었다. AI도 반복 작업을 줄이기 위해 사용했고, 플러그인은 유지해야 할 대상을 줄이기 위해 정리했다. 서로 다른 작업처럼 보였지만 목적은 같았다.
계속 운영하기 쉽게 만드는 것.
이 과정은 IT 인프라를 운영하는 일과 묘하게 닮아 있었다. 처음 구축하는 것보다 운영하는 시간이 길고, 구축 당시에는 문제가 없어 보이던 설계도 실제 트래픽과 사용 패턴을 만나면 달라진다. 불필요한 구성은 줄이고 반복 작업은 자동화하며 변경한 내용은 기록한다.
개인 블로그는 실패해도 다시 시도할 수 있다는 점이 다르다. CSS를 바꾸고 새 기능을 켜보고 마음에 들지 않으면 되돌릴 수 있다. 그렇게 시험한 과정 자체가 다음 글의 소재가 되기도 한다.
지금의 kimkyutae.com도 완성된 블로그는 아니다. 글이 더 많아지면 구조를 또 바꾸게 될 것이고, 새로운 기능이 나오면 플러그인을 줄이거나 늘릴 수도 있다. 누군가 정한 제품 로드맵을 기다릴 필요 없이 내가 불편하면 바꾸면 된다.
처음에는 얼른 블로그를 완성하고 글을 쓰려고 했다. 지금은 생각이 달라졌다. 글을 쓰면서 블로그를 계속 만들어 간다. 아마 완성이라는 시점은 오지 않을 것이다.
나는 내 블로그를 만드는 중입니다.
