은퇴 후 블로그를 시작했다.
처음엔 하루 한 편씩 직접 썼다. 주제를 찾고, 글을 쓰고, 네이버 에디터를 열고, 복사·붙여넣기하고, 발행 버튼을 누르는 과정을 매일 반복했다.
한 달쯤 지나자 깨달았다. 이건 사람이 할 일이 아니다.
마침 n8n이라는 자동화 도구를 알게 됐다. 코딩을 몰라도 블록을 연결하듯 워크플로우를 만들 수 있다고 했다. 반신반의하며 시작했다.
지금 내 네이버 자동화 시스템은 이렇게 생겼다.
1
2
3
4
5
6
7
8
9
10
11
12
13
구글 시트 (콘텐츠 큐 + 프롬프트)
↓
n8n 워크플로우
↓
Claude API (글 자동 생성)
↓
naver_poster.py (Flask 서버 port:5001)
↓
🍪 쿠키 확인
├─ 쿠키 유효 → 바로 포스팅
└─ 쿠키 만료 → 재로그인 → 포스팅
↓
네이버 블로그 발행 완료
처음엔 이 구조가 머릿속에 없었다. 하나씩 막히고, 하나씩 해결하다 보니 어느새 이렇게 되어 있었다.
자동화의 출발점은 구글 시트다.
여기에는 세 가지가 들어있다.
첫째, 프롬프트. Claude에게 어떤 글을 써달라고 지시하는 문장이다. “세무조사에 대비하는 방법을 블로그 형식으로 써줘” 같은 식이다. 이걸 시트에 미리 써두면 n8n이 꺼내서 Claude에게 전달한다.
둘째, 포스팅 대기열. 오늘 올릴 글, 내일 올릴 글을 줄 세워두는 곳이다. n8n이 순서대로 꺼내서 처리한다.
셋째, 발행 현황. 어떤 글이 언제 올라갔는지 기록된다. 나중에 확인할 때 유용하다.
구글 시트 하나가 편집장 역할을 하는 셈이다.
n8n이 글을 만들어도, 네이버에 올리는 건 별개 문제였다.
네이버는 공식 API가 없다. 블로그 자동 포스팅을 공식적으로 지원하지 않는다는 뜻이다. 그래서 Playwright라는 도구를 썼다. 실제 사람이 브라우저를 여는 것처럼 자동으로 로그인하고, 에디터를 열고, 글을 붙여넣고, 발행 버튼을 누르는 방식이다.
이걸 Flask라는 가벼운 웹 서버로 감쌌다. 이름이 naver_poster.py다.
실행하면 이렇게 뜬다:
1
2
3
네이버 블로그 포스팅 API 서버 / 포트: 5001
서버 시작...
Running on http://127.0.0.1:5001
n8n이 글을 완성하면 이 서버에 “올려줘” 하고 신호를 보낸다. 서버가 받아서 네이버에 자동으로 올린다.
자동화에서 가장 많이 막힌 곳이 바로 로그인이었다.
처음엔 단순했다. 프로그램이 실행될 때마다 아이디·비밀번호를 입력해서 로그인했다. 그런데 문제가 생겼다.
네이버가 의심하기 시작했다.
“새로운 환경에서 로그인이 감지됐습니다.” 보안 문자가 뜨거나, 문자 인증을 요구했다. 자동화가 자꾸 중간에 멈췄다.
해결책은 쿠키 저장이었다.
쿠키란 “이 사람은 아까 로그인했으니 다시 안 해도 된다”는 일종의 통행증이다. 한 번 로그인하면 그 쿠키를 파일로 저장해두고, 다음번엔 쿠키만 불러다 쓰는 방식이다.
덕분에 매번 로그인하지 않아도 됐다.
그런데 또 문제가 생겼다.
쿠키는 만료된다.
일정 시간이 지나면 쿠키가 무효화되고 다시 로그인이 필요해진다. 이걸 모르고 있으면 자동화가 조용히 실패한다. 글이 안 올라가는데 이유를 모르는 상황이 생긴다.
그래서 프로그램 안에 감지 로직을 넣었다. 쿠키가 만료됐으면 자동으로 재로그인하고, 새 쿠키를 다시 저장한다. 터미널 로그에 이렇게 찍힌다:
1
2
3
기존 세션 쿠키 로드
로그인 필요
POST /post 200 ← 성공
실패와 해결의 반복이었다.
| 상황 | 문제 | 해결 |
|---|---|---|
| 첫 실행 | 로그인 필요 | 자동 로그인 구현 |
| 재실행 | 매번 로그인 반복 | 쿠키 저장 |
| 시간 경과 | 쿠키 만료 | 만료 감지 후 재로그인 |
| 네이버 보안 | 자동화 차단 시도 | Playwright로 우회 |
나는 코딩을 모른다.
Python이 뭔지, Flask가 뭔지, Playwright가 뭔지 1년 전만 해도 몰랐다. 지금도 완전히 안다고 할 수 없다.
그런데 지금 내 컴퓨터에서 매일 자동으로 네이버 블로그에 글이 올라간다.
어떻게 가능했을까.
막히면 물어봤다. Claude에게, 구글에게, 에러 메시지에게. 이해가 안 되면 이해될 때까지 다시 물었다. 그렇게 하나씩 쌓았다.
가난은 태도다. 라는 말이 있다.
디지털 문맹도 마찬가지다. 모른다는 게 문제가 아니라, 배우지 않겠다는 태도가 문제다.
67세에 시작했다. 늦지 않았다.
다음 편: n8n 워크플로우 전체 구조 공개
]]>2024년 초, 서른여섯 해를 근무했던 대학을 떠났습니다. 정년퇴직이라는 낭만적인 단어와는 달리, 현실은 가슴이 철렁했습니다. 매일의 강의와 회의가 없어지니 시간은 무한했고, 마음은 허했거든요. 그러던 중 아들이 “아빠, 블로그 시작해보세요”라고 제안했습니다. 평생을 학문으로 살아온 나이에 블로그라니요. 하지만 한번 시작한 일은 끝을 봐야 하는 성격, 저는 그렇게 디지털 세계의 초보자가 되었습니다.
블로그를 개설한 지 3개월, 어느 정도 글이 모였다고 생각했을 때 애드센스 신청을 했습니다. 교육학 논문을 쓰던 경험이 있으니 글 정도는 쓸 수 있을 거라 자신했습니다. 결과는 ‘불승인’이었습니다. 이유는 “콘텐츠 정책 위반”이라는 모호한 문구였습니다.
당시 블로그를 다시 살펴보니 문제가 보였습니다. 교수 시절 쓰던 학술적 톤이 너무 딱딱했고, 몇몇 글에서는 특정 상품을 직접 비판하는 내용이 있었습니다. 아마도 이것이 구글의 ‘승인 자동 거부 정책’에 걸렸던 것 같습니다. 처음 거부 통지를 받았을 때는 한글로 된 설명 자료를 찾느라 혼신을 다했습니다. 영어로 된 구글 헬프 페이지를 번역기에 넣고 읽어내려 가던 밤이 아직도 기억납니다.
첫 번째 거부 후, 저는 모든 글을 다시 검토했습니다. 비판적인 문구들을 순화했고, 톤을 다시 잡았습니다. 3주를 다시 기다렸고, 두 번째 신청을 했습니다. 이번에는 다른 이유였습니다: “트래픽 부족”. 월 방문자가 500명도 채 안 된다는 것이었습니다.
이제 깨달았습니다. 애드센스는 단순히 ‘좋은 글’만으로는 안 된다는 걸요. 어떻게 사람들을 불러모을 것인가, 이것이 중요했습니다. 저는 SEO라는 낯선 개념을 배우기 시작했습니다. 키워드 분석 도구(무료 버전)를 사용했고, 제목을 다시 썼으며, 내부 링크를 추가했습니다. 타 블로그도 다니며 어떤 글이 인기 있는지 분석했습니다. 65세에 “롱테일 키워드”라는 용어를 배우다니요.
여섯 달이 지났을 때, 월 방문자는 2,500명까지 늘었습니다. 세 번째 신청 결과는 또 다른 이유였습니다: “부정적인 콘텐츠”라는 모호한 지적이었습니다. 마지막 거부 통지를 받았을 때, 저는 포기하고 싶었습니다. 너무 낡았고, 너무 힘들었습니다.
하지만 며칠의 자조감을 뒤로하고, 저는 실행에 옮겼습니다. 모든 글을 다시 읽으며 부정적으로 들릴 수 있는 표현들을 찾아냈습니다. 특정 제품 비판보다는 ‘선택의 기준’으로 표현을 바꿨고, 조언 톤으로 재작성했습니다. 또한 구글 서치 콘솔을 정기적으로 확인하며 어떤 키워드로 유입되는지를 분석했습니다.
아홉 달째, 네 번째 신청은 ‘승인’이었습니다. 화면에 ‘Congratulations!’라는 글자가 떴을 때, 저는 눈물이 났습니다. 첫 광고 수익이 $1.23일 때도 감격했습니다.
애드센스 승인 과정에서 배운 것들을 정리하면 이렇습니다. 첫째, 블로그는 ‘글의 질’뿐 아니라 ‘사용자 경험’을 보여줘야 합니다. 모바일 최적화, 빠른 로딩 속도, 명확한 네비게이션이 중요합니다. 둘째, 일관된 주제 영역의 글을 작성해야 합니다. 저는 애초에 교육 시니어IT, 블로그 운영 등 여러 주제로 섞어 썼는데, 이것도 거부 이유 중 하나였을 겁니다. 셋째, 정기적인 포스팅 빈도입니다. 일주일에 1~2편 정도의 꾸준한 업로드가 신뢰도를 높입니다.
현재 저의 블로그 월 수익은 평균 $80~120 정도입니다. 큰 돈은 아니지만, 은퇴자의 용돈으로는 충분하고, 무엇보다 여전히 배우고 있다는 실감이 좋습니다. 애드센스 외에도 이제는 다른 애피리에이트 프로그램도 연결했습니다.
60대의 손으로 쓴 블로그가 돈을 벌다니요. 이것이 현대의 은퇴자의 특권이라고 생각합니다. 애드센스 승인은 최종 목표가 아니라 시작일 뿐입니다. 당신도 비슷한 거부 통지를 받았다면, 절망하지 마세요. 대신 그것을 배움의 신호로 삼으세요. 한 번의 거부는 개선의 기회이고, 세 번의 거부도 결국 성공으로 향하는 길일 수 있습니다.
당신의 블로그는 어떤 모습인가요? 혹시 애드센스 승인을 준비 중이라면, 댓글로 현재 상황을 공유해 주세요. 같은 길을 걸었던 사람으로서 작은 조언이라도 해드리고 싶습니다.
]]>저는 대학에서 30년을 가르친 후 작년에 은퇴했습니다. 평생 강의노트와 논문으로만 살다가 이제는 그동안 쌓인 경험과 지식을 블로그에 정리하고 싶었습니다. GitHub Pages와 Jekyll을 선택한 것은 무료이면서도 전문적이라고 생각했기 때문입니다. 그런데 로컬에서는 완벽하게 보이던 블로그가 배포 후에는 엉망이었습니다. 스타일시트가 적용되지 않아 흰 배경에 검은 글자만 남았습니다. 처음에는 터미널 명령어를 잘못 입력한 줄 알고 몇 번을 반복했습니다. 하지만 문제는 다른 곳에 있었습니다.
문제의 원인은 _config.yml 파일의 baseurl 설정이었습니다. 제 리포지토리 이름이 my-blog였는데, GitHub Pages는 사용자 페이지가 아닌 프로젝트 페이지로 배포되었습니다. 사용자 페이지(username.github.io)가 아니면 URL이 username.github.io/my-blog/ 형식이 되는데, Jekyll은 이 경로 구조를 모르고 있었던 것입니다. 로컬에서는 http://localhost:4000에서 실행되므로 상관없지만, 실제 배포 환경에서는 모든 리소스 경로가 잘못되었습니다.
해결책은 간단했습니다. _config.yml에 baseurl: /my-blog를 명시하면 Jekyll은 모든 CSS, JavaScript, 이미지 파일의 경로 앞에 자동으로 /my-blog를 붙여줍니다. CSS 링크가 <link href="/css/style.css">에서 <link href="/my-blog/css/style.css">로 변경되는 것입니다. 이후 배포하니 모든 스타일이 정상 작동했습니다.
은퇴 후 프로그래밍을 배운 입장에서 깨달은 중요한 교훈이 있습니다. 개발 환경과 배포 환경은 완전히 다릅니다. 로컬에서 jekyll serve로 실행할 때는 localhost:4000이 루트가 되지만, GitHub Pages에서는 서브디렉토리가 루트가 될 수 있다는 점입니다. 특히 사용자 이름 대신 프로젝트 이름으로 리포지토리를 만들었다면 더욱 주의해야 합니다.
또한 로컬에서 테스트할 때도 정확하게 해야 합니다. 단순히 jekyll serve만으로는 부족하고, baseurl을 포함하여 테스트해야 실제 배포 환경과 동일합니다. 저는 이후로 jekyll serve --baseurl=/my-blog 명령어로 로컬 테스트를 반복했습니다. 이렇게 하면 배포 후 놀라는 일을 피할 수 있습니다.
처음에는 로컬에서 빌드한 후 _site 폴더를 푸시하려 했습니다. 그러나 깃허브 문서를 읽다 보니 이것은 권장되지 않습니다. 대신 GitHub Actions를 설정하여 푸시할 때마다 자동으로 빌드하고 배포하는 것이 표준입니다. 이렇게 하려면 저장소 설정에서 GitHub Pages 소스를 “GitHub Actions”로 선택해야 합니다. 이 과정에서 제 실수가 반복되었지만, Chirpy 테마의 .github/workflows/pages-deploy.yml 파일을 살펴보니 모든 설정이 자동으로 처리되었습니다.
Jekyll은 정적 사이트 생성기이기에 보안 문제도 없고, 속도도 빠릅니다. 개인 블로그부터 소규모 프로젝트 문서까지 활용 범위가 넓습니다. 저도 이제는 블로그를 통해 지난 30년의 강의 경험을 정리하고 있습니다. 여러분도 이러한 배포 환경의 차이를 먼저 이해한다면 시행착오를 줄일 수 있을 것입니다. 이번 포스팅이 도움이 되길 바라며, 댓글로 여러분의 경험담도 나눠주시기를 권장합니다.
]]>GitHub Pages에 푸시하기 전에 자신의 컴퓨터에서 정확히 어떻게 보일지 미리 확인하는 과정이 얼마나 중요한지는 몸으로 느껴봐야 알 수 있습니다. GitHub Pages의 빌드 시스템과 로컬 환경이 100% 동일하지 않을 수 있기 때문입니다. 제 경우 Chirpy 테마를 적용한 후 로컬에서는 완벽하게 보이는 포스트가 배포되면 이미지가 안 나타나는 현상이 발생했습니다. 한참을 헤매다가 결국 URL 경로 설정의 차이 때문이었음을 알게 되었습니다.
특히 강의 자료를 정리하던 당시에는 수식, 코드 블록, 테이블 등 복잡한 마크다운 요소들이 많았는데, 로컬 빌드 없이 직접 푸시했다가는 그야말로 재앙이었을 것 같습니다. 로컬 환경에서 먼저 테스트한다는 것은 단순히 시간을 아끼는 것을 넘어, 블로그의 신뢰성과 전문성을 지키는 필수 과정이라고 확신합니다.
처음 Jekyll을 설치하려고 했을 때 가장 힘들었던 부분이 바로 Ruby 환경 구성입니다. 저는 처음엔 아무 생각 없이 Ruby를 설치했다가, Gem 의존성 문제로 한 시간을 낭비했습니다. 지금이라면 다음 순서대로 진행할 것 같습니다.
먼저 Ruby 3.1 이상을 설치하되, 각 운영체제별로 조금씩 다릅니다. Windows 사용자라면 RubyInstaller를 통해 설치하고, Mac 사용자라면 Homebrew로 brew install ruby를 실행하면 됩니다. Linux 사용자는 패키지 매니저를 통해 설치하되, 버전 관리를 위해 rbenv나 asdf 같은 도구를 함께 사용하는 것을 추천합니다. 저는 이 과정에서 여러 버전의 Ruby가 꼬이는 바람에 which ruby로 경로를 확인하고 수동으로 정리해야 했던 쓸쓸한 경험이 있습니다.
Ruby가 설치되면 gem install bundler jekyll로 Jekyll을 설치합니다. 그 다음 프로젝트 폴더에 들어가서 bundle install을 실행하면 Gemfile에 정의된 모든 의존성이 설치됩니다. Chirpy 테마를 사용한다면 별도의 Gemfile이 이미 있으므로, 그냥 이 명령어 하나로 모든 게 준비됩니다. 이 부분을 처음엔 제대로 이해하지 못해서 매번 의존성 충돌 에러를 만났었는데, 지금은 이게 얼마나 우아한 방식인지 알게 됩니다.
모든 환경 설정이 끝났다면 bundle exec jekyll serve 또는 간단히 jekyll serve 명령어로 로컬 서버를 띄울 수 있습니다. 이 명령어는 기본적으로 http://localhost:4000에서 블로그를 실시간으로 볼 수 있게 해줍니다. 저는 이 순간을 처음 경험했을 때 정말 감동했던 기억이 납니다. 마치 자신이 만드는 블로그를 실시간으로 보는 느낌이었거든요.
더욱 훌륭한 점은 --livereload 옵션을 추가하면 파일을 수정한 즉시 브라우저가 자동으로 새로고침 된다는 것입니다. bundle exec jekyll serve --livereload 명령어를 실행하면, 마크다운 파일이나 CSS, 레이아웃 파일을 수정했을 때 저장하는 순간 화면에 반영됩니다. 강의 자료를 정리하던 당시 이 기능이 없었다면 얼마나 비효율적이었을까 상상하니 끔찍합니다.
로컬 서버에서는 수식, 코드 블록, 이미지 경로, 카테고리 분류, 태그 클라우드 같은 모든 요소가 실제 배포된 모습과 동일하게 표시됩니다. 특히 responsive 디자인이 제대로 작동하는지 확인하려면 브라우저의 개발자 도구에서 모바일 뷰로 전환해볼 수 있습니다. 저는 이 방식으로 태블릿과 스마트폰에서 어떻게 보일지 미리 점검하고 배포했기에, GitHub Pages 배포 후 별다른 문제가 없었던 것 같습니다.
로컬 빌드 중 에러가 발생하면 터미널에 상세한 로그가 출력됩니다. 처음엔 이 로그가 여간 복잡해 보이지 않습니다. 하지만 차분히 읽다 보면 어느 파일의 몇 번째 줄에서 문제가 생겼는지 명확하게 드러나 있습니다. 예를 들어 마크다운 파일의 Front Matter 형식이 잘못되었다면 “Liquid Exception”이라는 에러가 뜨고, 플러그인이 호환되지 않으면 “Plugin not found” 에러가 나타납니다.
저는 초반에 YAML 들여쓰기를 탭으로 했다가 에러를 만났고, 플러그인 버전 충돌로도 고생했습니다. 하지만 매번 로컬에서 빌드를 시도했기에 그 자리에서 바로 수정할 수 있었습니다. 만약 로컬 테스트 없이 GitHub에 푸시했다면, GitHub Actions 로그를 찾아서 분석하고, 다시 수정하고, 푸시하는 악순환에 빠졌을 것입니다.
특히 Chirpy 테마의 경우 특정 플러그인이 필수인데, 로컬 환경이 제대로 설정되지 않으면 이런 의존성 문제를 미리 캐치할 수 있습니다. bundle exec jekyll build 명령어로 실제 빌드 과정을 실행해보면, 배포 전에 모든 문제를 발견하고 해결할 수 있습니다.
지금 당신이 Jekyll과 GitHub Pages로 블로그를 운영하고 있거나 시작하려고 계획 중이라면, 오늘부터라도 로컬 빌드 환경을 제대로 구성하고 매 포스트마다 로컬에서 먼저 확인한 후 배포하는 습관을 들여보세요. 이것이 블로그의 품질을 높이는 가장 확실한 방법입니다.
]]>은퇴 후 블로그를 시작했다.
처음엔 하루 한 편씩 직접 썼다. 주제를 찾고, 글을 쓰고, 네이버 에디터를 열고, 복사·붙여넣기하고, 발행 버튼을 누르는 과정을 매일 반복했다.
한 달쯤 지나자 깨달았다. 이건 사람이 할 일이 아니다.
마침 n8n이라는 자동화 도구를 알게 됐다. 코딩을 몰라도 블록을 연결하듯 워크플로우를 만들 수 있다고 했다. 반신반의하며 시작했다.
지금 내 네이버 자동화 시스템은 이렇게 생겼다.
1
2
3
4
5
6
7
8
9
10
11
12
13
구글 시트 (콘텐츠 큐 + 프롬프트)
↓
n8n 워크플로우
↓
Claude API (글 자동 생성)
↓
naver_poster.py (Flask 서버 port:5001)
↓
🍪 쿠키 확인
├─ 쿠키 유효 → 바로 포스팅
└─ 쿠키 만료 → 재로그인 → 포스팅
↓
네이버 블로그 발행 완료
처음엔 이 구조가 머릿속에 없었다. 하나씩 막히고, 하나씩 해결하다 보니 어느새 이렇게 되어 있었다.
자동화의 출발점은 구글 시트다.
여기에는 세 가지가 들어있다.
첫째, 프롬프트. Claude에게 어떤 글을 써달라고 지시하는 문장이다. “세무조사에 대비하는 방법을 블로그 형식으로 써줘” 같은 식이다. 이걸 시트에 미리 써두면 n8n이 꺼내서 Claude에게 전달한다.
둘째, 포스팅 대기열. 오늘 올릴 글, 내일 올릴 글을 줄 세워두는 곳이다. n8n이 순서대로 꺼내서 처리한다.
셋째, 발행 현황. 어떤 글이 언제 올라갔는지 기록된다. 나중에 확인할 때 유용하다.
구글 시트 하나가 편집장 역할을 하는 셈이다.
n8n이 글을 만들어도, 네이버에 올리는 건 별개 문제였다.
네이버는 공식 API가 없다. 블로그 자동 포스팅을 공식적으로 지원하지 않는다는 뜻이다. 그래서 Playwright라는 도구를 썼다. 실제 사람이 브라우저를 여는 것처럼 자동으로 로그인하고, 에디터를 열고, 글을 붙여넣고, 발행 버튼을 누르는 방식이다.
이걸 Flask라는 가벼운 웹 서버로 감쌌다. 이름이 naver_poster.py다.
실행하면 이렇게 뜬다:
1
2
3
네이버 블로그 포스팅 API 서버 / 포트: 5001
서버 시작...
Running on http://127.0.0.1:5001
n8n이 글을 완성하면 이 서버에 “올려줘” 하고 신호를 보낸다. 서버가 받아서 네이버에 자동으로 올린다.
자동화에서 가장 많이 막힌 곳이 바로 로그인이었다.
처음엔 단순했다. 프로그램이 실행될 때마다 아이디·비밀번호를 입력해서 로그인했다. 그런데 문제가 생겼다.
네이버가 의심하기 시작했다.
“새로운 환경에서 로그인이 감지됐습니다.” 보안 문자가 뜨거나, 문자 인증을 요구했다. 자동화가 자꾸 중간에 멈췄다.
해결책은 쿠키 저장이었다.
쿠키란 “이 사람은 아까 로그인했으니 다시 안 해도 된다”는 일종의 통행증이다. 한 번 로그인하면 그 쿠키를 파일로 저장해두고, 다음번엔 쿠키만 불러다 쓰는 방식이다.
덕분에 매번 로그인하지 않아도 됐다.
그런데 또 문제가 생겼다.
쿠키는 만료된다.
일정 시간이 지나면 쿠키가 무효화되고 다시 로그인이 필요해진다. 이걸 모르고 있으면 자동화가 조용히 실패한다. 글이 안 올라가는데 이유를 모르는 상황이 생긴다.
그래서 프로그램 안에 감지 로직을 넣었다. 쿠키가 만료됐으면 자동으로 재로그인하고, 새 쿠키를 다시 저장한다. 터미널 로그에 이렇게 찍힌다:
1
2
3
기존 세션 쿠키 로드
로그인 필요
POST /post 200 ← 성공
실패와 해결의 반복이었다.
| 상황 | 문제 | 해결 |
|---|---|---|
| 첫 실행 | 로그인 필요 | 자동 로그인 구현 |
| 재실행 | 매번 로그인 반복 | 쿠키 저장 |
| 시간 경과 | 쿠키 만료 | 만료 감지 후 재로그인 |
| 네이버 보안 | 자동화 차단 시도 | Playwright로 우회 |
나는 코딩을 모른다.
Python이 뭔지, Flask가 뭔지, Playwright가 뭔지 1년 전만 해도 몰랐다. 지금도 완전히 안다고 할 수 없다.
그런데 지금 내 컴퓨터에서 매일 자동으로 네이버 블로그에 글이 올라간다.
어떻게 가능했을까.
막히면 물어봤다. Claude에게, 구글에게, 에러 메시지에게. 이해가 안 되면 이해될 때까지 다시 물었다. 그렇게 하나씩 쌓았다.
가난은 태도다. 라는 말이 있다.
디지털 문맹도 마찬가지다. 모른다는 게 문제가 아니라, 배우지 않겠다는 태도가 문제다.
67세에 시작했다. 늦지 않았다.
다음 편: n8n 워크플로우 전체 구조 공개
]]>올해 67세, 서울의 한 대학에서 30년간 물리학을 가르친 후 3년 전 정년퇴직했습니다. 퇴직금도 많지 않았고, 연금만으로는 취미생활과 손주들을 위한 용돈이 부족했습니다. 제 아들이 “아버지, 블로그 시작해보세요. 애드센스로 용돈도 벌고”라고 제안했을 때, 제 반응은 “이게 뭐하는 짓이야?”였습니다.
저는 대학에서 강의자료를 파워포인트로 만드는 것도 어려워하던 사람입니다. 휴대폰으로 문자메시지를 보내는 것만 해도 안경을 세 번은 고쳐 써야 했습니다. 하지만 폐지를 주울 수는 없는 노인의 자존심으로, 그 도전을 받아들이기로 결심했습니다.
2024년 1월, 아들의 도움으로 Jekyll Chirpy 테마로 블로그를 개설했습니다. 구글 애드센스 승인을 받는 데만 2개월이 걸렸습니다. 제 첫 포스트는 “은퇴 후 인생의 의미 찾기”라는 철학적인 주제였습니다. 조회수는 월 30회, 애드센스 수익은 거의 0원에 가까웠습니다.
6개월 동안 저는 교수 시절처럼 글을 썼습니다. 깊이 있고, 길고, 누군가는 흥미로워할 만한 내용들이었습니다. 그러나 구글 검색에는 한 번도 걸리지 않았습니다. 아들은 저에게 “아버지, SEO라는 게 있어요”라고 말했고, 저는 또 다른 낯선 용어를 배워야 했습니다.
그 시기가 가장 힘들었습니다. 매달 500~3,000원의 수익을 보며, 이 모든 것이 무의미하다고 생각했습니다. 인터넷에는 20대 블로거들이 월 1,000만원을 번다는 글들이 넘쳐났고, 저는 정말 미천한 존재처럼 느껴졌습니다.
전기가 바뀐 것은 아들이 제게 키워드 리서치 도구를 보여줬을 때입니다. 네이버 검색창, 구글 자동완성, “사람들이 실제로 뭘 찾는가”를 보기 시작했습니다.
저는 당뇨병 초기 증상, 혈압약 부작용, 은퇴자 용돈 관리법 등 같은 또래 시니어들이 실제로 검색하는 주제들을 발견했습니다. 그리고 역설적으로, 이러한 주제들에서 저는 교수 경력보다 더 큰 강점이 있었습니다. 바로 “같은 나이, 같은 경험”이었습니다.
2024년 8월부터 저는 “65세 이상이 꼭 알아야 할 스마트폰 사용법”, “은퇴자를 위한 간단한 엑셀 재무관리”, “시니어도 배울 수 있는 블로그 시작 가이드” 같은 포스트를 쓰기 시작했습니다. 이들 글이 처음으로 구글 1페이지에 등장했습니다.
2026년 현재, 제 블로그는 월 15,000~20,000명의 방문자를 받고 있으며, 애드센스 수익은 월 100~120만원대입니다. 완전히 억만장자는 아니지만, 손주들과 영화 보러 가고, 취미 활동을 할 수 있는 충분한 용돈입니다.
제가 배운 것은 이것입니다. 나이가 들었다는 것은 약점이 아니라 강점입니다. 당신이 풀 수 있는 문제는, 당신과 같은 세대의 누군가도 풀고 싶어 하는 문제일 가능성이 높습니다. 검색 엔진을 위해 쓰되, 독자의 얼굴을 보고 쓰면 됩니다.
앞으로 저는 50~70대 시니어들을 위한 IT 가이드 블로그를 더 체계적으로 운영할 계획입니다. 지금 당신이 도전하려 하는 블로그, 정말로 시작할 가치가 있습니다. 혹시 같은 길을 걷고 있다면, 댓글로 공유해보세요. 저도 당신을 응원할 테니까요.
]]>2024년 10월, 35년간 대학에서 학생들을 가르치던 내 교단 생활이 끝났다. 금시초문이던 ‘디지털 세상’에 나는 상당히 낯설었다. 스마트폰은 전화와 카톡만 했고, 컴퓨터는 논문 작성 정도에만 사용했다. 아내는 “이제 뭘 하실 건데?”라고 물었다.
그때 막내딸이 제안했다. “아버지, 블로그 해보세요. 교수님처럼 글 잘 쓰는 분이면 수익까지 될 수 있어요.” 처음엔 거절했다. 돈이 필요한 게 아니었기 때문이다. 하지만 호기심이 생겼다. ‘디지털 시대에 적응하는 것도 뇌 건강에 좋을 거 아닌가’ 하는 생각이 들었다.
블로그를 시작한 첫 3개월은 진짜 힘들었다. Jekyll Chirpy 테마를 설정하는 것부터 막혔다. GitHub가 뭔지도 몰랐다. 유튜브 영상을 다섯 번은 돌려 봤던 것 같다. 아내는 “그냥 네이버 블로그 하지”라고 했지만, 나는 고집을 피웠다. 진짜 공부하려면 어려운 길을 가야 한다고 생각했다.
처음 포스팅한 글은 ‘대학 교수가 바라본 한국 교육의 미래’였다. 꽤 자신 있게 썼다. 하지만 1주일이 지나도 조회수는 0이었다. 3개월 후에도 월 방문자는 겨우 12명이었다. 모두 내가 공유한 링크를 클릭한 가족과 제자들이었다.
이 시기에 중요한 것을 배웠다. 바로 ‘검색 엔진 최적화’의 개념이었다. 제목에 키워드를 넣어야 하고, 메타 설명을 작성해야 하며, 내부 링크를 연결해야 한다는 사실 말이다. 젊은 시절 논문 쓸 때와는 완전히 다른 세계였다.
4개월차부터 본격적으로 키워드 리서치를 시작했다. 구글 서치 콘솔과 애널리틱스에 블로그를 등록하고, 매주 어떤 검색어로 사람들이 내 글을 찾는지 분석했다. 처음엔 아무도 검색하지 않는 키워드로 글을 쓰고 있었다는 걸 알게 됐다.
그 다음부터 전략을 바꿨다. 내가 잘 아는 ‘교육학’, ‘대학 입시’, ‘시니어 IT 도전기’ 같은 주제에서 실제로 사람들이 검색하는 질문에 답하는 글들을 썼다. 예를 들어 ‘은퇴 후 뭘 하지?’, ‘60대가 블로그로 돈 버는 법’, ‘노인도 쉽게 배우는 프로그래밍’ 같은 제목들이었다.
6개월차에 드디어 월 방문자 수가 500명을 넘었다. 그리고 바로 그 다음 달, 애드센스 승인 신청을 했다. 처음에는 떨어졌다. ‘광고 정책을 위반했다’는 이유였다. 무엇이 문제인지 몰라 하루 종일 애드센스 정책 문서를 읽었다. 이미지 라이센스 문제였다. 모든 이미지를 교체하고 다시 신청했다. 이번에는 통과됐다.
애드센스가 승인된 날은 정말 기뻤다. 마치 학위 논문이 게재됐을 때 그 느낌이었다. 하지만 현실은 달랐다. 첫 달 수익은 $0.47, 즉 600원 정도였다. 광고가 클릭되기는 했지만, 수익이라고 부르기 민망할 정도였다.
그해 9월부터 10월, 내가 집중한 것은 방문자 수 증대였다. 한 가지 핵심을 깨달았다. 애드센스 수익은 ‘트래픽 × CPM × CTR’의 공식으로 결정된다는 것이었다. 내 경우 CPM이 높지 않았다. 광고주들이 한국 시니어 층에 대한 관심이 낮기 때문이었다. 그렇다면 CTR(클릭율)을 높이고 무엇보다 트래픽을 늘려야 했다.
본격적으로 매달 5~7개의 포스팅을 목표로 삼았다. 제자 중 마케팅을 전공한 친구에게 조언을 구했고, 그 친구는 “꾸준함만이 유일한 전략”이라고 말했다. SEO는 3~6개월이 필요하다는 뜻이었다.
2025년 3월, 월 방문자가 5,000명을 넘었다. 4월에는 8,000명, 5월에는 12,000명이 됐다. 애드센스 수익도 따라올랐다. 3월 $4.20, 4월 $12.50, 5월에는 $35.60이 됐다.
그리고 이제, 2026년 5월 현재, 월 수익은 안정적으로 $60~70, 즉 월 8만 원에서 9만 원 정도가 되었다. 목표인 월 50만 원은 아직이지만, 6개월 전과 비교하면 10배 성장한 것이다. 중요한 것은 이 수익이 계속 증가 추세라는 점이다.
내가 배운 가장 큰 교훈은 ‘나이는 디지털 성공의 장애물이 아니라, 오히려 강점’이라는 것이다. 나는 깊이 있는 글을 쓸 수 있고, 논리적 구성을 할 수 있으며, 인내심이 있다. 젊은이들이 3개월에 포기할 일을 나는 1년을 견디는 것이 장점이었다.
지금 당신도 정년을 앞두고 있다면, 혹은 이미 정년을 맞이했다면, 블로그는 훌륭한 도전이 될 수 있습니다. 당장 Jekyll Chirpy로 블로그를 시작해보세요. 당신의 인생 경험이 누군가의 길잡이가 되고, 그것이 수익으로 돌아올 수 있습니다.
]]>솔직히 고백하겠습니다. 저는 오랫동안 비트코인을 진지하게 생각하지 않았습니다. 30년 넘게 경제학을 공부하고 가르쳐온 사람으로서, “아무런 실물 가치가 없는 디지털 숫자”라는 표현이 입에 붙어 있었습니다. 그런데 몇 해 전, 한 젊은 제자가 조용히 말했습니다. “교수님, 화폐가 원래 뭔지 다시 생각해보신 적 있으세요?” 그 말이 묘하게 마음에 걸렸습니다.
한양대학교에서 비트코인 화폐철학을 가르치는 오태민 교수의 강의를 처음 접한 것도 그 무렵이었습니다. 오 교수는 비트코인을 단순한 투기 자산으로 보지 않습니다. 그는 비트코인을 “국가가 통제할 수 없는 희소성을 가진 새로운 형태의 화폐”로 정의합니다. 이 개념이 처음에는 낯설었지만, 듣다 보니 우리가 당연하게 여기는 원화나 달러도 사실은 정부의 신뢰 위에 세워진 약속에 불과하다는 것을 새삼 깨달았습니다.
50~60대 우리 세대는 IMF 외환위기, 2008년 금융위기, 코로나 팬데믹을 모두 몸으로 겪었습니다. 통장 잔고가 한순간에 흔들리는 경험을 해봤기에, “내 돈을 지킨다”는 문제에 누구보다 민감합니다. 그 감각으로 오태민 교수의 말을 다시 들으면, 단순한 투자 강의가 아니라 화폐에 대한 철학적 경고로 들립니다.
오태민 교수가 말하는 핵심은 간단합니다. 비트코인에는 4년 주기가 있습니다. ‘반감기’라고 불리는 이 사건은, 새로 채굴되는 비트코인의 양이 절반으로 줄어드는 시점을 말합니다. 공급이 줄면 희소성이 높아지고, 수요가 유지되면 가격이 오르는 건 기본 경제 원리입니다.
2024년 4월에 네 번째 반감기가 있었고, 역사적 패턴을 보면 반감기 이후 12~18개월 사이에 가격이 크게 오르는 흐름이 반복되어 왔습니다. 물론 과거가 미래를 보장하지는 않습니다. 하지만 오 교수는 “패턴 자체보다 중요한 것은, 하락하는 구간에서 공포를 이기고 분할 매수할 수 있느냐”라고 강조합니다.
여기서 ‘이 가격’의 의미가 분명해집니다. 특정 숫자를 콕 집어 말하는 것이 아닙니다. “시장이 흔들리고, 언론이 비트코인의 죽음을 선언하고, 주변 사람들이 손을 떼는 바로 그 시점”이 오히려 매수를 고려할 시점이라는 역발상입니다. 우리 세대에게 익숙한 말로 바꾸면, “남들이 팔 때 사라”는 워런 버핏의 격언과 본질이 같습니다.
처음 접하는 분들이 가장 많이 하는 실수가 있습니다. 저도 피해가지 못했던 것들입니다.
첫째, ‘전부 아니면 전무’ 식의 접근입니다. 비트코인이 좋다는 말을 듣고 퇴직금 전액을 넣는 분들이 있습니다. 이것은 어떤 자산이든 해서는 안 될 행동입니다. 오태민 교수 본인도 강조합니다. 전체 자산의 5~10% 이내에서 시작하는 것이 현명합니다. 잃어도 일상이 흔들리지 않는 금액, 그게 시작점입니다.
둘째, 거래소에 보관하는 것에 안심하는 것입니다. 은행과 달리 암호화폐 거래소는 예금자 보호가 되지 않습니다. 해킹이나 거래소 파산 사례가 실제로 있었습니다. 어느 정도 규모가 되면 하드웨어 지갑이라는 별도 저장 장치에 옮겨두는 것이 안전합니다. 처음엔 낯설지만, 배우면 어렵지 않습니다.
셋째, 가격을 매일 확인하는 습관입니다. 비트코인은 하루에 10% 이상 오르내리는 자산입니다. 매일 들여다보면 감정적 판단을 하게 됩니다. 오 교수는 “비트코인을 매수한 뒤 1~2년 동안 잊고 살 수 있는 사람이 결국 이긴다”고 말합니다. 우리 세대가 수십 년을 기다리며 부동산을 보유해온 인내심, 바로 그 인내심이 이 자산에서도 통합니다.
오태민 교수의 강의에서 가장 인상 깊었던 대목은 이것이었습니다. “비트코인은 미래 세대에게 인플레이션의 피해를 떠넘기지 않겠다는 약속입니다.” 우리나라의 통화량은 지난 10년 동안 두 배 이상 늘었습니다. 그 말은 곧, 지금 통장에 가만히 놔둔 돈의 실질 가치가 서서히 줄어들고 있다는 뜻입니다. 은행 이자가 물가 상승률을 따라잡지 못하는 시대, 우리는 이미 그 안에서 살고 있습니다.
비트코인의 총 발행량은 2,100만 개로 영원히 고정되어 있습니다. 중앙은행이 마음대로 찍어낼 수 없는 구조입니다. 이것이 오 교수가 말하는 ‘화폐 철학’의 핵심입니다. 투기의 도구가 아니라, 가치를 저장하는 새로운 수단으로 바라보는 시각 말입니다.
물론 비트코인이 모든 문제의 해답은 아닙니다. 변동성은 여전히 크고, 규제 리스크도 존재합니다. 하지만 “이게 뭔지 알고 판단하는 것”과 “무섭다고 외면하는 것”은 다릅니다. 공부하지 않은 채로 투자하는 것이 위험한 것이지, 공부한 뒤에 소액으로 경험해보는 것은 지금 이 시대의 합리적 선택일 수 있습니다.
지금 바로 거래소 앱을 열 필요는 없습니다. 다만, 오늘 이 글을 읽으신 김에 오태민 교수의 강의를 한 편만 찾아서 들어보시길 권합니다. 30분이면 충분합니다. 듣고 나서 “역시 내 얘기가 아니야”라고 느끼셔도 좋습니다. 그것 자체가 이미 informed decision, 즉 알고 내린 결정이니까요. 모르는 채로 외면하는 것과는 전혀 다른 차원입니다.
]]>솔직히 말씀드리면, 저는 오랫동안 비트코인을 “젊은 사람들 도박판”이라고 생각했습니다. 30년 넘게 강단에 서면서 화폐와 금융을 가르쳤는데도, 비트코인만큼은 선뜻 손이 가지 않았습니다. 그런데 한양대학교 오태민 교수의 강연을 접하고 나서 생각이 조금 달라졌습니다.
오태민 교수는 비트코인을 단순한 투기 자산이 아니라 화폐 철학의 관점에서 바라봅니다. 그가 말하는 핵심은 이렇습니다. 비트코인은 “디지털 금”이며, 기존 화폐 시스템이 구조적으로 안고 있는 인플레이션 문제에 대한 대안으로 설계되었다는 것입니다. 50~60대 우리 세대가 젊었을 때와 지금을 비교해 보면 압니다. 같은 돈으로 살 수 있는 것이 얼마나 줄어들었는지를요. 그 맥락에서 비트코인의 논리가 갑자기 낯설지 않게 느껴졌습니다.
그렇다면 문제는 하나입니다. 언제, 얼마에 사야 하는가.
오태민 교수는 비트코인의 가격이 특정 구간에 들어올 때를 “기회의 창”이라고 표현합니다. 그 구간이 어디냐고요? 교수의 논리를 요약하면, 비트코인은 반감기(Halving) 사이클을 기준으로 움직이는 경향이 있습니다. 반감기란 약 4년마다 비트코인 채굴 보상이 절반으로 줄어드는 이벤트인데, 역사적으로 반감기 이후 1~1.5년 안에 큰 상승이 나타났습니다.
2024년 4월에 반감기가 있었으니, 이 사이클 논리대로라면 2025년 말~2026년 상반기가 하나의 고점 구간이 될 수 있습니다. 그리고 그 이후 조정 구간, 즉 가격이 충분히 눌릴 때가 바로 “담을 준비”를 해야 할 시점이라는 것입니다.
물론 정확한 바닥을 아무도 모릅니다. 교수 본인도 그 점을 분명히 합니다. 그래서 그가 권하는 방식은 분할 매수입니다. 예컨대 목표 금액의 30%는 가격이 일정 수준 이하로 내려올 때 먼저 사고, 추가 하락이 오면 다시 30%, 그리고 나머지 40%는 반등 신호를 보고 매수하는 식입니다.
이 방식은 사실 주식 장기 투자에서도 많이 쓰는 방법입니다. 우리 세대에게 낯설지 않습니다. 삼성전자 주식을 오랫동안 모아온 분들이라면 이 논리가 금방 이해될 것입니다.
저는 강단에서 늘 학생들에게 말했습니다. “원칙 없는 투자는 도박이다.” 비트코인도 다르지 않습니다. 특히 50~60대라면 아래 세 가지 원칙을 반드시 지켜야 한다고 생각합니다.
첫째, 전체 자산의 5% 이내로 시작하십시오. 은퇴 자금은 회복 기회가 젊은 세대보다 적습니다. 비트코인은 1년 안에 반 토막 날 수도 있는 자산입니다. 잃어도 생활에 지장이 없는 금액만 넣으십시오. 오태민 교수도 이 점에서는 보수적인 입장입니다.
둘째, 거래소가 아니라 ‘보관’을 먼저 공부하십시오. 비트코인은 은행에 맡기는 게 아닙니다. 거래소에 두면 해킹이나 거래소 파산 위험이 있습니다. 하드웨어 지갑이라는 물리적 저장 장치를 통해 스스로 보관하는 방법을 익혀두면 훨씬 안전합니다. 처음에는 복잡해 보이지만, 배우고 나면 그리 어렵지 않습니다.
셋째, 단기 시세에 흔들리지 마십시오. 이것이 가장 어렵습니다. 비트코인은 하루에 10% 이상 오르내리는 일이 흔합니다. 뉴스에 반응해 팔고 사는 순간, 수익보다 손실이 커집니다. 오태민 교수가 강조하는 “담는다”는 표현 자체가 이미 장기 보유를 전제로 합니다. 최소 3~5년을 바라보는 시각이 필요합니다.
비트코인에 대해 잘 모른다고 해서 지레 포기하지 마십시오. 저도 처음에는 그랬습니다. 하지만 화폐의 역사를 공부한 사람으로서, 지금 세계가 경험하고 있는 통화 팽창의 시대에 자산의 일부를 인플레이션에 강한 형태로 바꿔두는 것은 충분히 합리적인 선택이 될 수 있습니다.
오늘 당장 매수하라는 말이 아닙니다. 오태민 교수의 말처럼, ‘이 가격’이 왔을 때 흔들리지 않으려면 미리 공부해두어야 합니다. 준비되지 않은 사람은 기회가 와도 두려워서 손을 못 뻗습니다.
지금 당장 비트코인 반감기 사이클을 검색해보고, 현재 가격이 역사적으로 어떤 위치에 있는지 확인해보십시오. 그것이 첫걸음입니다. 공부한 만큼 보입니다. 그리고 보이는 만큼 결정할 수 있습니다.
]]>은퇴 후 관심사가 늘어났다. 아침에 읽은 뉴스 기사, SNS에서 본 흥미로운 아이디어, 손주들과 나눈 대화까지 모두 Notion에 기록하기 시작했다. 하지만 몇 주가 지나니 문제가 생겼다. Notion 데이터베이스에는 벌써 수백 개의 아이디어가 쌓여 있었고, 이들을 카테고리별로 분류하는 작업에만 매주 몇 시간을 소비해야 했다.
“이 일을 자동화할 수는 없을까?”라는 생각이 들었다. 대학에서 30년간 공학을 가르친 경험이 있는 나는, 문제를 마주하면 자동화로 해결하려는 습관이 배어 있었다. 그렇게 n8n, Claude AI, Notion API의 조합을 시작하게 된 것이다.
n8n은 코딩 없이 자동화 워크플로우를 만들 수 있는 플랫폼이다. 나는 먼저 Notion에서 “상태”가 “신규”인 항목들을 자동으로 찾도록 설정했다. 매일 오전 8시에 트리거가 실행되도록 했고, 새로운 항목이 생기면 즉시 감지하는 방식으로 구성했다.
Notion의 API 연결은 생각보다 간단했다. Notion 통합(Integration)을 생성하고, 내 데이터베이스에 접근 권한을 부여한 후 n8n에 API 키를 입력하면 된다. 처음엔 실패도 많았다. 데이터베이스 ID를 잘못 입력해서 아무것도 불러와지지 않거나, 프로퍼티 필드명을 잘못 매핑해서 오류가 나기도 했다. 하지만 n8n의 커뮤니티 포럼과 공식 문서가 상당히 친절해서 문제를 빠르게 해결할 수 있었다.
워크플로우의 핵심은 Claude AI와의 연결이다. n8n에서 Notion에서 불러온 텍스트를 Claude API로 전송하면, Claude가 아이디어의 카테고리를 판단하고 한 문장으로 요약해준다.
예를 들어 내가 Notion에 “아침에 읽은 기사: 노년층의 디지털 리터러시 향상이 인지능력 저하를 방지한다는 새로운 연구 결과가 나왔다. 이것은 나도 새로운 기술을 배워야 하는 이유를 증명해준다”라고 기록했다면, Claude는 이것을 “교육/과학” 카테고리로 분류하고 “노년층의 기술 학습이 인지능력 유지에 도움이 된다는 연구”로 요약해준다.
Claude의 프롬프트는 이렇게 작성했다:
1
2
3
4
다음 텍스트를 읽고:
1) 가장 적절한 카테고리를 선택하세요 (기술/교육/건강/취미/관계/기타 중 선택)
2) 핵심 내용을 한 문장으로 요약하세요
3) JSON 형식으로 반환하세요: {"category": "", "summary": ""}
Claude의 응답은 매우 정확했다. 내가 일일이 판단하던 것보다 훨씬 일관성 있게 분류되었다.
모든 단계를 연결한 후, n8n 워크플로우는 다음과 같이 작동한다:
이제 나는 아침 10분이면 하루에 쌓인 모든 아이디어를 정리된 상태로 볼 수 있다. 이전에는 같은 작업에 2~3시간이 걸렸다. n8n의 모니터링 대시보드에서 자동화가 제대로 작동하는지 확인하는 것도 간단하다. 실패 로그가 뜨면 원인을 찾아 빠르게 수정할 수 있다.
가장 놀라운 부분은 이 시스템이 한 번 구축되면 거의 신경 쓸 필요가 없다는 것이다. 은퇴한 몸이지만 기술의 힘으로 내 시간을 되찾을 수 있었다. 처음엔 어렵게 느껴지겠지만, n8n 인터페이스는 직관적이고 Claude API의 문서도 명확하다.
지금 당신의 Notion에도 정리되지 않은 데이터가 쌓여 있지 않은가? 이 자동화 시스템을 직접 구축해보고, 얼마나 많은 시간을 절약할 수 있는지 경험해보길 권한다.
]]>