KIMKYUTAE.COM · ©
내 블로그를 만드는 중입니다 #3
처음 글: 내 블로그를 만드는 중입니다 #1
이전 글: 내 블로그를 만드는 중입니다 #2
10. AI가 내 블로그에 직접 글을 쓸 수 있을까
AI와 함께 글을 쓰는 일이 익숙해지자 자연스럽게 다음 생각이 들었다.
초안을 만들고 복사해서 블로그 글로 등록하는 과정을 생략할 수 없을까.
글 제목, 본문, 카테고리, 태그, SEO 정보, 대표이미지까지 이미 AI와 함께 만들고 있었다. 그렇다면 마지막 단계인 블로그 글 등록까지 연결하면 작업 흐름이 훨씬 짧아질 것 같았다.
이때부터 여러 연결 방법을 알아보기 시작했다.
WordPress.com 계정과 Jetpack을 통한 연결도 보고, WordPress의 AI 관련 기능도 확인했다. Easy MCP AI 같은 플러그인과 외부 AI를 연결하는 방법도 시도했다.
처음에는 단순히 플러그인 하나 설치하면 될 줄 알았다. 실제로는 인증 방식, 권한, WordPress.com과 독립형 WordPress의 차이, Jetpack 사용 여부 같은 요소가 얽혀 있었다.
내 블로그는 Cafe24에 설치한 독립형 WordPress였다.
WordPress라는 이름은 같아도 WordPress.com에서 제공하는 서비스와 내가 직접 호스팅하는 WordPress는 구조가 다르다. 이 차이를 제대로 알지 못해 연결 과정에서 여러 번 실패를 경험했다.
하지만 과정 자체는 의미가 있었다.
‘AI가 글 작성을 도와준다’는 단계에서 ‘AI가 내 콘텐츠 시스템에 직접 개입할 수 있다’는 단계로 넘어갈 때 무엇이 달라지는지를 직접 느낄 수 있었기 때문이다.
가장 크게 달라지는 것은 권한이었다.
글 초안을 AI 채팅창에서 받는 것은 비교적 단순하다. 하지만 AI가 WordPress에 직접 글을 만들거나 수정하려면 블로그에 쓰기 권한을 줘야 한다. 잘못된 요청이나 예상하지 못한 동작이 실제 블로그에 영향을 줄 수도 있다.
그래서 가능하면 글을 바로 공개하는 것보다 임시글로 만드는 방식이 마음에 들었다.
AI와 논의하여 작성한 초안을 임시글로 올리고, 내가 관리자 화면에서 확인하고, 필요한 부분을 수정한 뒤 직접 발행하는 흐름이다.
자동화의 속도와 사람의 최종 검토를 적당히 나눌 수 있었다.
이 방식은 IT 업무에서 변경 작업을 다루는 방식과도 비슷하다. 자동화가 가능하더라도 운영 환경에 바로 반영하기보다는 검토 단계와 승인 단계를 두는 편이 안전하다는 것이다.
블로그라고 해서 크게 다르지 않았다.
실제로 AI가 대표이미지와 삽화를 만들고, 본문을 작성하고, WordPress 임시글까지 구성할 수 있게 되면 글 한 편을 만드는 시간이 상당히 줄어든다.
대신 그만큼 검수의 중요성은 더 커진다.
- 카테고리가 맞는지,
- 태그가 지나치게 많지 않은지,
- 이미지가 엉뚱한 위치에 들어가지 않았는지,
- 기술 내용이 정확한지,
- 내가 쓰지 않을 표현이 들어가지는 않았는지 확인해야 한다.
자동화는 사람을 없애는 작업이 아니라, 사람이 해야 할 일을 다른 일로 전환하는 작업이었다.
예전에는 본문을 처음부터 직접 입력하는 데 시간을 썼다면, 이제는 초안을 검토하고 선택을 내리는 데 더 많은 시간을 쓰게 됐다.
결국 내가 원했던 것은 ‘AI가 알아서 운영하는 블로그’가 아니었다.
내가 결정한 방향을 더 빠르게 구현해 주는 블로그였던 것 같다.
11. 쓰다 보니 불편한 것들이 보이기 시작했다
블로그를 어느 정도 만들어 놓고 실제로 자주 사용하기 시작하면 관리자 화면보다 방문자 화면을 더 많이 보게 된다.
새 글이 잘 올라갔는지 확인하려고 첫 화면을 열어 보고, 예전에 쓴 글을 찾고, 모바일에서 어떻게 보이는지 확인했다. 그러다 보니 만들 때는 잘 보이지 않던 불편함이 하나씩 눈에 들어왔다.
대표적인 것이 무한 스크롤이었다.
처음에는 편해 보였다. 페이지 번호를 누르지 않아도 아래로 내리기만 하면 다음 글이 계속 나타난다. 특히 모바일에서는 자연스러운 방식처럼 느껴졌다.
하지만 실제로 사용해 보니 문제가 있었다.
아래로 한참 내려간 뒤 글 하나를 열어 보고, 다시 뒤로가기를 눌렀을 때 이전 위치로 자연스럽게 돌아가지 않는 경우가 있었다. 글 목록을 훑어 내려가던 흐름이 끊긴 것이다.
화면이 매끈하고 그럴싸하게 움직이는 것보다 내가 실제로 글을 찾고 읽는 과정이 편한 것이 더 중요했다.
그래서 결국 기본 설정인 이전/다음 페이지네이션으로 돌아갔다. 오래된 방식처럼 보일 수 있지만 현재 내가 원하는 사용 방식에는 더 잘 맞았기 때문이다.
그런데 하나를 바꾸자 다른 문제가 생겼다.
첫 페이지에는 고정글이 있었다.
히말라야 뉴트에 대한 정보를 정리한 글을 고정해 두었는데, 첫 페이지에서는 고정글 하나와 최신 글들이 함께 보이고 2페이지부터는 고정글이 사라졌다.
카드형 레이아웃에서 한 페이지의 글 개수가 달라지니 어느 페이지는 카드 하나가 비어 보이는 문제도 생겼다.
이때부터 ‘기능적으로 맞다’와 ‘화면이 자연스럽다’는 서로 다를 수 있다는 점을 계속 경험했다. 글 목록도 2열과 3열이 섞인 형태였고, 게시물 개수를 바꾸면 첫 페이지와 다음 페이지의 균형이 달라졌다.
정답이 있는 문제가 아니었다.
고정글을 유지할 가치가 있는지 다시 고민했고, 한 페이지의 게시물 수도 바꿔 보면서 실제 화면을 확인했다.
페이지네이션과 본문 사이의 간격도 마찬가지였다.
처음 설정한 값이 너무 붙어 보이면 조금 띄우고, 너무 멀어 보이면 다시 줄였다. 숫자 하나만 바뀌지만 화면 전체 인상은 달라졌다.
이런 작업을 하다 보니 CSS를 사용하는 경우도 늘어났다. 테마에서 제공하는 옵션만으로 해결되면 가장 좋지만, 원하는 간격이나 정렬이 정확히 나오지 않을 때는 AI와 대화해 만든 CSS를 추가했다.
여기서도 원칙은 비슷했다.
가능하면 테마 기본 기능을 먼저 사용하고, CSS는 필요한 부분만 최소한으로 적용했다. 나중에 테마가 업데이트되거나 구조가 바뀌었을 때 수정할 코드가 너무 많으면 관리가 어려워지기 때문이다.
블로그 초기에는 새로운 기능을 추가할 때마다 완성도가 높아지는 것처럼 느껴졌다. 그런데 실제 운영 단계에서는 반대인 경우도 많았다.
기능을 줄였더니 더 편해졌고, 화면 효과를 없앴더니 더 안정적이었고, 복잡한 레이아웃을 단순화했더니 글이 더 잘 보였다.
내가 매일 사용하는 블로그였기 때문에 이런 불편함을 빨리 발견할 수 있었다.
운영자가 자신의 블로그를 자주 보는 것은 생각보다 중요했다. 방문 통계만 보는 것이 아니라 직접 첫 화면을 열고, 글을 읽고, 검색하고, 뒤로가기를 눌러 보는 것이다.
사소한 불편함은 그렇게 발견됐다.
그리고 그 사소한 불편함을 계속 없애는 과정이 결국 블로그의 완성도를 높여가고 있다고 생각한다.
12. 추천글과 관련글을 다시 생각하다
글이 어느 정도 쌓이자 새로운 문제가 생겼다.
“예전 글을 어떻게 다시 보여줄 것인가.”
블로그는 기본적으로 최신 글이 위에 올라온다. 새로운 글을 계속 쓰면 예전에 공들여 작성한 글은 자연스럽게 뒤로 밀린다. 검색을 통해 들어오는 경우가 아니라면 첫 화면에서 발견하기 어려워진다.
그래서 추천글 기능을 넣고 싶었다.
처음에는 별도 플러그인을 찾아야 하나 생각했는데, 사용 중인 플러그인에 그 기능이 있다는 것을 알게 됐다.
꼭 조회수가 높은 글만 보여주고 싶었던 것은 아니었다. 처음 방문한 사람이 보면 좋은 글이나, 최근 글과 함께 다시 보여주고 싶은 글을 배치하는 공간에 가까웠다.
모바일에서는 결과가 괜찮았다. 한 줄에 하나씩 표시되어 자연스럽게 내려가며 볼 수 있었다.
문제는 PC 화면이었다. 넓은 화면에서 글들이 원하는 위치에 정렬되지 않았고, 개수에 따라 모양도 어색해졌다.
AI와 대화하며 CSS를 수차례 수정하고 나서야 정렬이 원하는 대로 됐다.
그다음에는 게시물 개수가 문제였다.
추천글이 두 개라면 화면을 반씩 나누면 자연스럽다. 세 개라면 3등분하면 된다.
그런데 네 개까지 고려해 자동 배치를 만들려다 보니 오히려 복잡해졌다.
고민 끝에 추천글은 최대 세 개만 보여주기로 정했다.
이 결정이 마음에 들었다.
모든 경우를 코드로 완벽하게 해결하려고 하지 않고 콘텐츠 운영 규칙을 단순하게 만드는 방식이었다.
블로그를 다듬으면서 이런 선택을 여러 번 했다. 기술적으로 가능하다고 해서 반드시 구현할 필요는 없었다.
추천글 아래에는 관련글도 있었다. 두 기능은 비슷해 보이지만 역할이 달랐다.
추천글은 내가 보여주고 싶은 콘텐츠에 가깝고, 관련글은 방문자가 방금 읽은 글과 연결되는 다음 콘텐츠를 자동으로 제안하는 기능이다.
두 영역이 너무 붙어 있으면 같은 기능처럼 보였다. 그래서 간격을 조정하고 노출 개수도 다시 봤다.
관련글의 기준을 무엇으로 할지도 고민했다. 기본값인 카테고리는 비교적 큰 범위다.
Cloud Security라는 같은 카테고리에 있어도 Firewall 글과 OSCP 글은 직접적인 관련성이 낮을 수 있다.
반면 태그는 글의 세부 주제를 표현할 수 있다.
예를 들어 AWS, Security Group, Network Security 같은 태그를 공유하는 글이라면 서로 연결할 이유가 더 분명하다.
그래서 관련글의 기준을 태그로 두는 쪽으로 결정했다.
이 선택은 생각보다 큰 영향을 줬다.
그동안 태그를 단순히 게시물 하단에 보여주는 키워드 정도로 생각했는데 이제는 관련글의 품질을 결정하는 데이터가 됐다.
태그를 대충 붙일 수 없게 된 것이다.
추천글 하나를 추가하려고 시작한 작업이 결국 블로그 전체의 콘텐츠 구조를 다시 보게 만들었다.
방문자가 다음에 어떤 글을 읽을지 생각하는 일은 단순한 화면 배치가 아니었다.
콘텐츠 사이에 길을 만드는 일이었다.
13. 태그를 처음부터 제대로 만들 걸 그랬다
태그는 블로그를 시작할 때 가장 쉽게 남발할 수 있는 기능 중 하나다. 글에 관련된 단어를 떠오르는 대로 몇 개 입력하면 된다.
처음에는 나도 크게 신경 쓰지 않았다.
오히려 게시물 하단에 태그가 너무 많이 보이면 지저분해 보여서 적게 넣는 편이 낫다고 생각했다.
문제는 관련글의 기준을 태그로 바꾸면서 시작됐다.
태그가 같아야 관련글로 연결된다면 이제 태그는 화면에 보이는 장식이 아니었다.
콘텐츠 사이의 관계를 표현하는 데이터였다.
기존 태그를 다시 보니 문제가 보였다. 같은 의미인데 표기가 다른 경우가 있었다.
영문 대소문자가 제각각일 수도 있고, 어떤 글에서는 약어를 사용하고 다른 글에서는 전체 이름을 사용할 수도 있었다.
너무 구체적인 태그는 글 하나에만 사용되고, 너무 넓은 태그는 관련 없는 글까지 묶어버린다.
태그를 많이 만들수록 분류가 정교해지는 것이 아니었다. 오히려 기준이 없으면 검색과 관련글 품질이 더 나빠질 수 있었다.
그래서 전체를 정리하기로 했다. 기존 태그를 검토하고 표준 이름을 정한 뒤 다시 적용하는 방식이었다.
여기서 카테고리와 태그의 역할도 다시 나눴다.
카테고리는 글이 속한 큰 서랍이다.
태그는 서로 다른 서랍에 있는 글도 연결할 수 있는 공통 속성이다.
예를 들어 OSCP 글은 Cloud Security 카테고리에 들어갈 수 있지만 Linux, Privilege Escalation, Nmap 같은 태그를 통해 다른 실습 글과 연결될 수 있다.
어항 글도 마찬가지다.
Aquarium이라는 큰 카테고리 안에서도 Betta, Himalayan Newt, Corydoras, Feeding 같은 태그를 사용하면 관련된 글을 묶을 수 있다.
표준화를 할 때는 영문 대소문자도 통일하려고 했다. 제품명이나 고유명사는 공식 표기를 따르고, 일반적인 기술 용어는 블로그 전체에서 같은 형태를 사용한다.
AWS라고 썼다가 Aws라고 쓰지 않고, 개인 블로그라고 썼다가 개인블로그로 바꾸지 않는 식이다.
작아 보이지만 글이 많아질수록 이런 일관성이 중요해진다.
태그를 화면에서 꼭 모두 보여줄 필요는 없다는 것도 알게 됐다. 방문자에게 태그 목록이 길게 보이는 것은 부담스러울 수 있다.
하지만 내부적으로는 관련글과 콘텐츠 구조를 위해 충분히 세분화해서 사용할 수 있다.
표시 방식과 데이터 구조를 별개의 문제로 볼 수 있게 된 것이다.
이 관점은 블로그를 관리하는 방법을 많이 바꿨다.
겉으로 단순해 보인다고 내부 구조까지 단순할 필요는 없다.
반대로 내부에 많은 데이터가 있다고 그것을 전부 화면에 노출할 필요도 없다.
이 원칙은 IT 시스템을 설계할 때도 익숙한 생각이었다.
사용자에게 필요한 인터페이스와 시스템 내부의 관리 정보는 목적이 다르다.
태그 정리는 화려한 작업은 아니었다. 대표이미지를 새로 만드는 것처럼 눈에 확 띄지도 않는다.
하지만 앞으로 글이 몇십 개, 몇백 개로 늘어난다고 생각하면 지금 해둘 가치가 있었다.
운영이 오래될수록 처음 만든 작은 규칙이 큰 차이를 만든다.
그리고 솔직히 이 작업을 하면서 생각했다.
처음부터 제대로 만들 걸 그랬다.
물론 처음에는 어떤 태그가 필요한지 알 수 없었으니 현실적으로 불가능했을지도 모른다. 결국 태그 체계도 글이 쌓인 뒤에야 제대로 만들 수 있었다.
이것 역시 블로그를 운영하면서 배우게 된 것 중 하나였다.
처음 설계보다 운영하면서 발견한 구조가 더 현실적일 수 있다.
14. 결국 중요한 것은 계속 고칠 수 있는가였다
블로그를 만들기 시작한 뒤 한 달 동안 생각보다 많은 것을 바꿨다.
- 메뉴와 카테고리를 정리했고, 검색엔진에 블로그를 등록했고, 대표이미지 규칙을 만들었고, 본문 삽화 스타일을 맞췄다.
- 동영상을 올리는 방식을 고민했고, 플러그인을 설치했다가 지웠고, AI와 블로그를 연결하려고 여러 방법을 시도했다.
- 무한 스크롤을 페이지네이션으로 바꾸고, 추천글의 정렬을 CSS로 수정하고, 관련글 기준을 태그로 바꾼 뒤 태그 전체를 다시 정리했다.
처음 블로그를 만들 때 이 모든 작업을 미리 계획할 수 있었을까.
아마 불가능했을 것이다.
실제로 글을 써보고 직접 블로그를 사용하지 않았다면 어떤 문제가 생기는지 알 수 없었기 때문이다.
그래서 지금 다시 블로그를 처음 만든다면 예전보다 훨씬 빠르게 만들 수는 있겠지만 모든 것을 완벽하게 설계하려고 하지는 않을 것 같다. 기본 구조만 먼저 만들고 글을 쓰기 시작할 것이다. 그리고 문제가 생길 때 하나씩 고칠 것이다.
그동안의 경험을 떠올려보면, 블로그에서 가장 중요한 것은 테마도, 플러그인도, SEO 점수도 아니었다.
‘글을 계속 쓸 수 있는 환경인가’가 가장 중요했다.
아무리 예쁜 블로그라도 글을 올리는 과정이 번거로우면 오래가기 어렵다.
반대로 조금 부족한 화면이라도 글을 쓰고 고치는 과정이 편하면 시간이 지나면서 자연스럽게 좋아질 수 있다.
그래서 블로그를 다듬을 때 내가 가장 중요하게 보게 된 기준은 ‘지속적으로 운영 가능한가’였다.
- 대표이미지를 만드는 규칙도 새 글마다 고민하는 시간을 줄이기 위해 만들었다.
- 태그 표준화도 다음 글에서 같은 고민을 반복하지 않기 위해 했다.
- AI를 사용하는 것도 결국 글 작성 과정에서 반복되는 작업을 줄이기 위해서였다.
- 플러그인을 정리한 이유 역시 유지해야 할 대상을 줄이기 위해서였다.
겉으로는 서로 다른 작업이었지만 목적은 같았다.
계속 운영하기 쉽게 만드는 것.
IT 인프라를 운영하는 것과도 묘하게 닮아 있었다.
- 처음 구축하는 것보다 운영이 더 길다.
- 구축 당시에는 문제가 없어 보이던 설계도 실제 트래픽과 사용 패턴을 만나면 바뀐다.
- 불필요한 구성은 줄이고, 반복 작업은 자동화하고, 문제가 생기면 원인을 확인해서 수정한다.
- 변경한 내용은 기록해 둔다.
개인 블로그라고 해서 크게 다르지 않았다.
물론 블로그에는 장애 대응이나 서비스 수준 같은 부담은 없다. 실패해도 다시 하면 된다.
그래서 오히려 새로운 것을 시험해 보기에 좋은 공간이었다.
CSS를 수정해 보고, 새 기능을 켜보고, 마음에 들지 않으면 다시 되돌린다. AI 연결도 해보고, 영상 서비스도 붙여본다.
그 과정이 그대로 글감이 되기도 한다.
지금의 kimkyutae.com은 완성된 블로그가 아니다.
앞으로 글이 더 많아지면 또 구조를 바꾸게 될 거라 생각한다.
지금은 만족하는 추천글 배치가 몇 달 뒤에는 불편해질 수도 있고, 새로운 WordPress 기능이 나오면 플러그인을 하나 더 줄일 수도 늘릴 수도 있다.
그렇게 바뀌는 것이 자연스럽다고 생각한다.
‘내가 만든 블로그’의 좋은 점은 누군가 정한 제품 로드맵을 기다릴 필요가 없다는 것이다.
내가 불편하면 바꾸면 된다.
그리고 내가 좋아하는 방식으로 조금씩 만들어 갈 수 있다.
처음에는 얼른 블로그를 완성하고 글을 쓰려고 했다.
지금은 생각이 달라졌다.
글을 쓰면서 블로그를 계속 만들어 간다.
아마 완성이라는 시점은 오지 않을 것이다.
그래도 괜찮다.
계속 고칠 수 있다는 것 자체가 글을 쓸 수 있다는 것처럼 내가 블로그를 운영하는 이유 중 하나일 것이기 때문이다.
나는 내 블로그를 만드는 중입니다.
