KIMKYUTAE.COM · ©
내 블로그를 만드는 중입니다 #2
이전글: 내 블로그를 만드는 중입니다 #1
6. AI와 “함께” 블로그 글을 쓰기 시작했다
처음 AI를 블로그에 사용한 이유는 단순했다.
글을 조금 더 완벽하게 작성하고 싶었다.
내가 작성한 초안에서 맞춤법이 틀린 부분이 있는지, 사실관계가 틀린 내용이 있는지 등을 확인하기 위해 AI를 사용하기 시작했다. 그러다 점차 제목 후보, 목차, SEO 설명, 태그, 대표이미지 문구까지 맡기는 범위가 늘어났다.
중요했던 것은 AI가 글의 주인이 되지 않도록 하는 것이었다.
최후의 자존심이랄까, 내 블로그이지 AI의 블로그가 아니라는 자존심 말이다.
하지만 AI에게 “좋은 글로 써줘”라고만 하면 대체로 무난하고 그럴듯한 글이 나온다고 한다. 문제는 내 자존심이 상한다는 것이다.
내가 실제로 무엇을 하고 무엇을 생각했는지, 어디에서 불편했는지, 왜 다른 방법 대신 이 방법을 골랐는지가 빠지기 쉽다.
그래서 요청 방식을 고민했고, 단순히 주제를 주는 대신 내가 겪은 상황을 최대한 구체적으로 넣었다.
“처음에는 이 설정을 썼는데 실제로 써보니 이런 문제가 있었다.” / “이 제품은 가격보다 이 부분이 마음에 들었다.” / “회사 보고서처럼 쓰지 말고 평소 사용하는 말투로 써라.”
이런 정보가 들어가면 결과도 훨씬 내 글에 가까워졌다.
AI와 대화하면서 글을 만드는 과정은 비서와 같이 일하는 느낌에 가까웠다. 마치 회사 중역이 비서를 두고 일하는 기분이 들었다.
AI가 초안을 작성하면 나는 검토를 시작한다. 완성된 문장을 한 번에 받는 것보다 이 과정이 더 중요했다.
기술 글에서는 사실 확인 역할도 컸다.
특히 서비스 정책, 지원 기간, 제품 사양처럼 바뀔 수 있는 내용은 최신 자료를 확인하게 하고 출처를 비교했다. 내가 잘못 알고 있던 전제가 있으면 바로잡는 용도로도 사용했다.
반대로 AI가 확신 있게 말하더라도 내가 이상하다고 느끼면 그대로 사용하지 않았다.
AI의 강점은 속도고, 인간의 강점은 맥락이다.
내 블로그에서 어떤 표현을 자주 쓰는지, 어떤 주제는 너무 깊게 다루지 않는 것이 좋은지, 실제로 내가 해 본 일인지 아닌지는 결국 내가 가장 잘 안다.
그러다 보니 블로그를 운영하면서 AI에 대한 기대도 조금 현실적으로 바뀌었다.
처음에는 글을 대신 써줄 수 있는 도구라고 생각했다. 하지만 지금은 자료를 정리하고, 다른 관점을 제안하고, 내가 놓친 부분을 찾아주는 도구에 더 가까워졌다.
특히 긴 기술 글을 쓸 때는 내가 핵심 내용을 정하고 AI가 구조를 만드는 방식이 잘 맞았다.
반대로 짧은 일상 글이나 어항 영상 글은 굳이 AI의 도움을 많이 받을 필요가 없었다. 영상 하나에 짧은 문장 몇 개면 충분한 글도 있었다.
AI를 사용한다고 모든 글을 길게 만들 필요도 없었다. 오히려 AI는 요청하면 얼마든지 내용을 늘릴 수 있기 때문에 ‘여기까지만 쓰는 것’도 사람이 해야 할 결정이었다.
이 원칙은 대표이미지와 삽화를 만들 때도 그대로 이어졌다.
7. 그림을 AI로 그리기 시작했다
글을 AI와 함께 쓰기 시작한 뒤 자연스럽게 이미지도 함께 만들게 됐다.
처음에는 글 대표이미지 정도로 시작했지만 기술 글은 직접 찍을 사진이 없는 경우가 많아 자연스럽게 AI를 활용하게 되었다.
무료 이미지 사이트에서 관련 그림을 찾을 수도 있지만, 기술 글의 특정 내용을 정확하게 보여주는 그림은 많지 않았다.
서버실이나 자물쇠 사진 같은 수십 년간 사용된 그림을 쓰는 것도 마음에 들지 않았다.
AI 이미지 도구는 이런 부분에서 유용했다. 글의 주제에 맞는 이미지 하나를 바로 만들 수 있었기 때문이다.
하지만 처음 생성한 이미지들은 통일감이 부족했다. 심지어 같은 글 안에서도 제각각인 상황이 벌어졌다.
어떤 이미지는 실사였고, 어떤 것은 3D였으며, 어떤 것은 복잡한 인포그래픽이었다. 각각만 보면 괜찮았지만 글 하나를 읽는데도 서로 다른 사이트의 이미지처럼 보였다.
그래서 대표이미지에 규칙을 만들었다.
- 기본 비율은 16:9.
- 이미지 안의 글자는 최소화.
- 제목을 넣더라도 크게 한두 줄 정도.
- 최종 파일 용량은 너무 커지지 않도록 조정.
- 클라우드·보안 공부 글에는 밝은 배경과 정돈된 도식 느낌을 사용
- 실제 제품 리뷰나 어항 글은 실제 찍은 사진을 업로드하여 AI 그림 제작 시 활용
본문 삽화는 조금 다른 규칙을 적용했다. 본문에서 필요한 것은 장식보다 설명이었다.
예를 들어 기술을 설명한다면 화려한 그림보다 박스 몇 개와 화살표가 정확하게 연결된 도식이 낫다. 그래서 밝은 흰색 또는 아주 연한 배경, 파스텔 계열의 블루·민트·옐로·퍼플, 둥근 박스, 단순한 아이콘을 사용하는 형태로 스타일을 맞췄다.
여백도 중요한 기준이었다.
처음 AI가 만든 인포그래픽은 내용에 비해 캔버스가 너무 넓거나 장식적인 공간이 많았다. 블로그 본문에 넣으면 실제 정보가 작게 보였다.
그래서 “여백을 줄이고 정보 영역을 크게”라는 요구를 자주 하게 됐다.
이미지 안에 한글을 넣을 때는 더 조심해야 했다. 생성형 이미지가 글자를 틀리게 만들거나 이상한 표현을 넣는 경우가 있기 때문이다. 가능하면 긴 설명을 이미지에 넣지 않고 제목이나 아주 짧은 라벨만 사용했다.
복잡한 내용은 본문에서 설명하는 편이 낫다.
이 작업을 반복하면서 대표이미지와 본문 삽화의 목적이 확실히 분리됐다.
대표이미지는 클릭하기 전에 글의 주제를 알려준다. 본문 삽화는 읽고 있는 내용을 더 빨리 이해하게 한다.
두 이미지를 같은 기준으로 만들 필요는 없었다.
또 하나 생긴 습관은 생성된 이미지를 그대로 끝으로 보지 않고 세세히 검토하는 것이다.
파일 크기를 확인하고, 필요하면 해상도를 줄이고, 글자 오류가 없는지 보고, 실제 글에 넣었을 때 너무 크거나 작지 않은지 확인했다.
AI가 이미지를 만들어 주는 시간은 매우 짧아졌지만, 어떤 이미지를 사용할지 고르는 기준은 오히려 더 중요해졌다.
이미지를 무한히 만들 수 있다는 것은 좋은 이미지가 자동으로 선택된다는 뜻이 아니었다.
블로그 전체에서 어떤 분위기를 유지할 것인지 결정하는 일은 여전히 나의 몫이었다.
이 과정을 거치고 나니 글 하나를 만드는 방식도 달라졌다.
본문을 먼저 쓰고 마지막에 이미지를 억지로 넣는 것이 아니라, 글을 구성할 때 어느 부분은 텍스트로 설명하고 어느 부분은 그림으로 보여줄지 같이 생각하게 됐다.
특히 기술 글에서는 이 방식이 효과가 좋았다.
긴 문단 세 개를 쓰는 것보다 구조도 하나와 설명 두 문단이 더 이해하기 쉬운 경우가 많았다.
이미지가 글의 장식에서 글의 일부가 된 셈이었다.
8. 블로그에 동영상을 올리고 싶었다
어항을 기록하다 보면 사진만으로는 아쉬운 순간이 많다.
베타가 수조 전체를 돌아다니는 모습이나, 물고기들이 먹이를 먹는 장면, 히말라야뉴트가 지렁이를 먹는 모습은 영상으로 보는 편이 훨씬 자연스럽다.
처음 떠오른 방법은 YouTube였다.
영상을 올리고 링크를 블로그에 삽입하면 가장 간단하다. 서비스 안정성도 좋고 별도의 스트리밍 환경을 고민할 필요도 없다.
그런데 개인 블로그 안에서 영상을 보여주는 경험을 조금 더 직접 관리해 보고 싶었다. 광고도 보여주고 싶지 않았다.
그래서 AI에게 무료거나 저렴한 동영상 스트리밍 호스팅 서비스를 추천해 달라 하였고, Bunny.net의 Stream 서비스를 추천받아 사용하게 되었다.
동영상 파일을 웹 호스팅 서버에 직접 올리는 방식은 피하고 싶었다. 영상은 이미지보다 파일 용량이 훨씬 크고, 방문자가 재생할 때 서버 트래픽도 크게 발생한다. 이는 호스팅 비용의 큰 상승을 불러오기 때문이다.
웹 호스팅은 글과 이미지에 집중하고 동영상은 전문 스트리밍 서비스를 사용하는 편이 구조적으로 더 깔끔했다.
Bunny Stream을 사용하면서 내가 원했던 것도 복잡한 기능은 아니었다. 영상을 업로드하고, 웹에서 안정적으로 재생하고, WordPress 글 안에 쉽게 삽입할 수 있으면 됐다.
동영상은 블로그의 성격에도 영향을 줬다. 어항 글은 긴 설명보다 영상 하나와 짧은 기록만으로 충분할 때가 있었다.
‘베타 물멍’, ‘4자 어항 먹이주기’ 같은 글은 정보를 검색해 들어오는 독자도 있지만 실제 수조 모습을 편하게 보고 싶은 사람도 있다.
모든 게시물이 검색용 장문 콘텐츠일 필요는 없었다. 이런 글이 섞이면서 블로그가 조금 더 개인적인 공간처럼 느껴졌다.
동영상을 블로그에 넣으면서 콘텐츠 형식에 대한 생각도 조금 바뀌었다.
글을 잘 쓰는 것만이 블로그 운영은 아니었다.
사진 한 장, 8분짜리 물멍 영상, 짧은 사용 후기, 긴 기술 분석 글.
이런 것들이 같이 어우러진 것이 진짜 “개인” 블로그였다.
9. 플러그인은 많다고 좋은 것이 아니었다
워드프레스를 사용하다 보면 원하는 기능 대부분을 플러그인으로 해결할 수 있다.
검색 최적화가 필요하면 SEO 플러그인을 설치하고, 통계가 필요하면 통계 플러그인을 설치하고, AI 기능이 궁금하면 AI 플러그인을 설치한다.
처음에는 이것이 워드프레스의 가장 큰 장점처럼 보였다. 실제로 장점이기도 하다.
문제는 설치가 너무 쉽다는 것이다.
필요할 것 같은 기능을 하나씩 추가하다 보면 어느 순간 관리자 화면에 플러그인 목록이 길어진다. 어떤 플러그인은 정확히 왜 설치했는지 기억이 흐릿해지고, 기능이 겹치는 것도 생긴다.
나 역시 블로그를 다듬는 동안 Jetpack을 포함해 여러 플러그인을 설치하고 설정을 바꿨다.
AI 연동을 해보기 위해 관련 플러그인을 추가하기도 했고, WordPress와 외부 서비스를 연결하려고 다른 방법을 시도하기도 했다.
그러다 블로그 속도와 관리 편의성을 보면서 하나씩 다시 확인하기 시작했다.
- 이 플러그인이 없으면 실제로 어떤 기능이 사라지는가.
- 현재 사용하고 있는가.
- 워드프레스나 테마 기본 기능으로 대신할 수 없는가.
- 기능이 겹치지는 않는가.
이 질문에 명확하게 답하기 어려운 플러그인은 일단 비활성화했다.
바로 삭제하기보다 비활성화한 상태로 블로그에 문제가 없는지 확인하는 방법을 자주 사용했다. 문제가 없으면 그다음에 삭제했다.
이 과정에서 Jetpack의 일부 기능도 다시 봤다.
Jetpack은 한 플러그인 안에 많은 기능이 들어 있기 때문에 편리하지만, 내가 실제로 필요한 기능과 그렇지 않은 기능을 구분할 필요가 있었다. 캐시 관련 설정처럼 켰을 때보다 껐을 때 블로그가 체감상 더 빠른 경우도 있었다.
이렇듯 이론적으로 좋아 보이는 기능보다 실제 블로그에서 어떻게 동작하는지를 우선했다.
블로그에 자주 접속해 보는 것도 일종의 모니터링이었다. 첫 화면이 느린지, 게시물로 들어갈 때 지연이 있는지, 이미지가 늦게 뜨는지, 모바일에서 이상한 동작이 있는지를 직접 확인했다.
웹 성능 측정 도구의 숫자도 의미가 있지만 개인 블로그에서는 내가 매일 느끼는 속도도 무시할 수 없었다.
보안 관점에서도 플러그인이 적은 편이 관리하기 쉽다.
플러그인은 워드프레스에 코드를 추가하는 것이다. 사용하지 않는 플러그인을 계속 유지하면 업데이트해야 할 대상도 늘어나고 취약점 관리 범위도 넓어진다.
그렇다고 ‘플러그인은 무조건 적을수록 좋다’는 식으로 생각하지는 않았다.
Bunny Stream처럼 실제 작성 과정을 편하게 해주는 플러그인은 남길 이유가 있었다. Blocksy Companion처럼 테마와 잘 통합되어 추천글 기능을 제공하는 플러그인도 마찬가지였다.
결국 기준은 개수가 아니었다. 역할이 분명한가가 중요했다.
플러그인을 정리하면서 WordPress 타임존, RSS, XML-RPC 같은 기본 설정도 같이 다시 봤다. 처음 설치할 때 지나쳤던 설정을 실제 운영 단계에서 다시 확인한 것이다.
블로그를 만들 때는 기능을 추가하는 데 재미가 있다. 하지만 어느 정도 완성되고 나면 오히려 빼는 작업이 더 중요해진다.
사용하지 않는 기능을 끄고, 겹치는 기능을 없애고, 내가 관리할 수 있는 수준으로 단순하게 만드는 것.
이때부터 내 블로그가 조금 더 안정된 느낌이 들었다.
다음 글: 내 블로그를 만드는 중입니다 #3
