목차
- 블로그스팟으로 시작한 이유
- 네이버로 확장하려다 마주친 벽
- 색인이 사라지면서 워드프레스로 옮긴 이유
- 워드프레스 이후: 자동 게시와 Threads 병행
- 자동화 구성에서 확인한 것들
- 컨테이너 구성과 발행 확인 순서
- 배포 환경에서 생긴 차이
- 결론
블로그스팟으로 시작한 이유
처음 블로그 자동 발행을 만들 때는 블로그스팟부터 시작했습니다. 글 생성과 발행 준비까지는 자동화하되, 최종 검토와 게시 버튼은 직접 눌렀습니다. 플랫폼 API가 익숙하지 않은 상태에서 여러 채널을 한꺼번에 자동화하면 문제가 생겼을 때 어디서 잘못됐는지 찾기 어려울 것 같았고, 실제로 이 판단은 맞았습니다.
네이버로 확장하려다 마주친 벽
블로그스팟이 어느 정도 자리를 잡은 뒤 네이버로 범위를 넓히려 했습니다. 확인해 보니 당시 네이버에서 사용할 수 있는 공식 API 범위로는 원하는 형태의 완전 자동 게시를 구현하기 어려웠습니다. 결국 이 프로젝트에서는 결과물을 만들어 사람이 직접 붙여넣는 반자동 방식으로 결정했습니다. 자동화를 만들다 보면 “자동화할 수 없는 부분”을 인정하는 것도 필요하다는 걸 이때 체감했습니다. 네이버는 이후로도 계속 사람이 붙여넣는 채널로 남겨뒀습니다.
색인이 사라지면서 워드프레스로 옮긴 이유
네이버 쪽 확장이 막힌 사이, 블로그스팟 쪽에서 더 근본적인 문제가 나타났습니다. 자동화 파이프라인 자체는 문제없이 돌아가고 있었는데, 정작 결과물이 검색에 노출되지 않는 상황이 된 겁니다.
이 무렵 색인 상태가 크게 달라지면서 플랫폼을 워드프레스로 옮겼습니다. 당시 수치와 원인 분석은 Blogger에서 WordPress로 이전한 과정과 색인 변화에 별도로 정리했습니다.
워드프레스 이후: 자동 게시와 Threads 병행
워드프레스로 옮긴 뒤에는 API를 이용해 인증과 발행 과정을 직접 제어할 수 있었고, 발행 결과를 검증하는 구조를 갖춘 뒤 검토 없이 자동 게시하는 방식으로 전환했습니다. 동시에 Threads 게시도 붙여서 병행하기 시작했습니다. 블로그스팟·네이버 단계에서 겪은 시행착오 덕분에, 이번에는 플랫폼별 모듈을 처음부터 분리해서 붙였습니다. 한 채널의 인증 오류가 다른 채널까지 멈추게 하고 싶지 않았기 때문입니다.
자동화 구성에서 확인한 것들
Docker Compose 환경에서 서비스를 올릴 때는 실행 전에 설정 파일과 경로부터 확인하는 습관을 들였습니다.
이 절은 당시 운영 환경에서 직접 확인한 범위만 적었으며, 다른 배포판·호스팅 환경에서의 동작까지는 확인하지 못했습니다.
docker compose config
docker compose up -d
docker compose ps
config 명령이 오류 없이 끝나고 ps에서 관련 컨테이너가 실행 중으로 표시되면 기본 구동 상태는 확인된 겁니다. 이후에는 애플리케이션 로그에서 채널별로 인증 성공, 발행 요청, 응답 코드를 순서대로 확인했습니다. 워드프레스와 Threads처럼 자동 게시가 적용된 채널은 로그만 믿지 않고 실제 공개된 글의 제목과 링크를 직접 열어 대조했습니다. 네이버는 사람이 붙여넣는 채널이라 이 확인 대상에서는 제외했습니다.
컨테이너 구성과 발행 확인 순서
앞서 설명한 당시 운영 확인 과정을 순서로 정리하면 다음과 같습니다. 네이버는 사람이 붙여넣는 채널이므로 공개 확인 대상에서 제외했습니다.
- 설정 확인: Compose 설정 파일과 경로를 확인합니다.
- 서비스 실행: Compose로 관련 서비스를 시작합니다.
- 상태 확인: 컨테이너 상태와 채널별 로그를 확인합니다.
- 공개 확인: 자동 게시된 글의 제목과 링크를 대조합니다.
2026년 10월 18일에는 Docker Engine 29.6.2와 Compose v5.1.3에서 네트워크를 사용하지 않는 별도 임시 프로젝트로 위 절차를 확인했습니다. docker compose config -q가 성공했고 up -d 후 ps는 컨테이너를 running으로 표시했으며 로그에 compose-check-ok가 출력됐습니다. 이 확인은 임시 컨테이너의 구동만 검증한 것이며 실제 블로그 발행 성공을 뜻하지 않습니다.
배포 환경에서 생긴 차이
같은 설정이라도 서버마다 미묘하게 달랐습니다. 배포판에 따라 Docker 설치 명령과 서비스 관리 방식이 다르고, Docker Compose가 docker compose가 아닌 별도 명령으로 제공되는 경우도 있었습니다. 실행 파일 위치, 프로젝트 경로, 환경 변수 파일 이름도 서버마다 달라서, 명령을 실행하기 전에 pwd, ls, docker compose version으로 현재 위치와 설치 상태부터 확인하는 게 습관이 됐습니다.
격리된 예시 Compose 파일에 가상의 값 example-not-secret을 넣어 확인했을 때 docker compose config 결과의 환경변수에 그 값이 표시됐습니다. 실제 비밀값이 보간되는 설정이라면 출력에도 비밀값이 나타날 수 있으므로 로그나 화면 공유에 그대로 올리지 마세요. 출력 없이 설정의 유효성만 확인하려면 docker compose config -q를 사용할 수 있습니다. 이는 설정 검증이며 서비스 실행 성공을 뜻하지 않습니다. 자세한 내용은 Docker의 보간 안내를 참고하세요.
경로가 틀리면 설정 파일을 찾지 못하거나 엉뚱한 프로젝트가 실행됐고, 환경 변수가 누락되면 API 인증 실패로 이어졌습니다. no configuration file, unauthorized, 빈 게시 결과 같은 메시지가 보이면 실행 위치, .env 파일 경로, 키 이름을 순서대로 점검했습니다. 이 과정에서 로그에 비밀 키를 그대로 출력하지 않도록 주의하는 것도 함께 배웠습니다.
결론
블로그스팟 반자동으로 시작해서, 네이버 API 제약으로 반자동에 머물렀고, 색인 취소를 계기로 워드프레스로 옮긴 뒤 자동 게시와 Threads 게시를 병행하게 됐습니다. 처음부터 완성된 그림을 그리고 시작한 게 아니라, 막히는 지점마다 범위를 조정하면서 지금 구조에 도달한 과정이었습니다.