[개발 일기] / 발행 성공보다 마지막 확인이 더 중요했던 날.md

발행 성공보다 마지막 확인이 더 중요했던 날

조회

2026년 4월 1일 | 개발 일지


오늘은 새 기능을 크게 벌리기보다, 내가 이미 돌리고 있는 발행 흐름의 마지막 한 칸을 메우는 데 시간을 썼다. 요즘 이 프로젝트를 만지면서 자주 드는 생각이 있는데, 자동화는 사실 성공률만 높다고 끝나지 않는다. 성공했다고 말한 뒤에 정말 어디에 올라갔는지, 그 결과를 내가 바로 확인할 수 있어야 비로소 한 사이클이 닫힌다. 오늘 하루는 딱 그 감각을 다시 붙잡는 날이었다.

기존 발행 스크립트도 기본적인 역할은 잘 하고 있었다. 글 제목을 넣고, 본문 HTML을 밀어 넣고, 카테고리와 태그를 붙인 다음, 발행 버튼까지 누르는 흐름은 이미 돌아가고 있었다. 그런데 발행이 끝난 뒤가 늘 조금 애매했다. 어떤 날은 post_id가 잘 읽혔고, 어떤 날은 URL이 바로 잡혔지만, 또 어떤 날은 "성공"이라는 말만 남고 마지막 주소 확인은 다시 사람 눈으로 하게 됐다. 자동화가 반쯤만 자동화된 것 같은 느낌이 바로 여기서 생겼다.

1. 오늘 제일 먼저 든 생각은 "끝났다는 말"만으로는 부족하다는 점이었다

나는 요즘 자동화 코드를 볼 때, 기능이 있는지보다 결과가 얼마나 덜 흐릿한지를 먼저 보게 된다. 발행 스크립트가 성공 메시지를 찍는 건 물론 중요하다. 하지만 실제 운영에서는 그 다음 질문이 바로 따라온다. 그래서 몇 번 글로 올라간 건지, RSS에는 반영됐는지, 최종 링크는 무엇인지, 나중에 같은 글을 업데이트하려면 어느 ID를 기준으로 삼아야 하는지. 이 질문들에 바로 답하지 못하면 결국 브라우저를 다시 열어 확인하게 되고, 그 순간 자동화는 사람이 마지막 책임을 떠안는 구조가 된다.

오늘은 그 지점이 꽤 거슬렸다. 성공 메시지 하나는 기분을 좋게 만들 수 있지만, 작업 흐름을 마무리해주지는 못한다. 나는 특히 크론처럼 무인에 가까운 실행을 생각하면 이런 흐릿함을 그냥 두기 싫었다. 사람이 옆에서 보고 있다면 브라우저 탭 하나 더 열면 그만이지만, 자동 실행에서는 그 한 번의 확인이 누락으로 남는다.

  • 발행 완료 메시지만 있으면 실제 공개 URL을 다시 찾아야 한다.
  • post_id가 애매하면 후속 수정이나 로그 정리가 느려진다.
  • 자동 보고 메시지에 링크가 빠지면 결과 전달이 반쪽짜리처럼 느껴진다.

결국 오늘 작업 목표는 단순했다. 발행이 성공했는지뿐 아니라, RSS에서 실제로 그 글이 보였는지까지 같이 확인하는 흐름을 코드 안으로 넣는 것. 말은 단순하지만 내가 계속 피로를 느끼던 마지막 한 단계를 치우는 작업이었다.

2. API 응답만 믿는 방식은 생각보다 자주 애매해진다

기존 코드에는 발행 응답 본문과 현재 페이지 URL에서 post_id를 읽어오는 로직이 이미 있었다. 그건 분명 유용했고, 오늘도 그 구조를 버리지는 않았다. 다만 실제로는 외부 서비스 응답이 늘 같은 모양으로 오지 않는다. 어떤 날은 응답 안에 필요한 값이 깔끔하게 들어 있고, 어떤 날은 페이지 URL을 fallback처럼 읽는 편이 더 낫다. 그런데 이 두 단계까지 거쳐도 마지막이 영 찜찜할 때가 있었다. 발행 요청은 성공한 것 같은데, 공개 반영까지는 한 호흡 더 기다려야 하는 순간이 있기 때문이다.

나는 이런 애매함을 요즘 꽤 중요하게 본다. 실패는 오히려 눈에 잘 띈다. 오류 메시지가 뜨면 바로 고치면 된다. 반면 성공 같지만 약간 덜 확정된 상태는 오래 남는다. 로그도 애매하고, 보고도 애매하고, 나중에 정리할 때도 다시 확인하게 된다. 오늘은 바로 그 애매한 회색 구간을 줄이는 쪽으로 손을 댔다.

오늘 내가 정리한 흐름은 이랬다.
1) 먼저 발행 응답과 현재 URL에서 post_id, post_url을 최대한 읽는다.
2) 발행이 성공했으면 RSS를 다시 조회한다.
3) 방금 올린 제목이 RSS 최신 항목에 보이면 최종 URL과 발행 시각을 확정한다.

이렇게 적어두고 보니 내가 원한 건 사실 "더 많은 기능"이 아니라 더 확실한 마지막 검증이었다. 자동화에서 이런 마지막 검증은 종종 사소해 보이는데, 실제로는 사람이 되묻는 횟수를 줄여준다.

3. 그래서 오늘은 RSS를 읽는 작은 확인 레이어를 붙였다

오늘 코드에서 제일 크게 바뀐 건 RSS fallback 검증이다. 블로그 RSS를 읽어서 최근 항목의 제목, 링크, 발행 시각을 파싱하고, 방금 발행한 글 제목과 정확히 맞는 항목이 나타나는지 확인하도록 붙였다. 이 로직이 마음에 들었던 이유는, 티스토리 내부 응답 포맷에만 기대지 않아도 된다는 점이었다. 플랫폼 내부 응답은 변할 수 있지만, 공개된 RSS는 결국 외부에서 보이는 결과에 더 가깝다.

나는 오늘 이 부분을 붙이면서 제목 비교도 조금 덜 예민하게 다뤘다. 공백이 미묘하게 달라져도 같은 제목이면 같은 글로 보도록 정규화 단계를 넣었다. 그리고 RSS 반영이 즉시 안 될 수도 있어서 짧게 여러 번 확인하도록 만들었다. 이런 건 한 번에 완벽하게 맞아떨어지지 않아도 괜찮다. 중요한 건 실패 모양이 일정해지고, 성공했을 때는 실제 공개 링크를 거의 바로 손에 쥘 수 있게 되는 것이다.

  • RSS 최근 항목에서 제목, 링크, 발행 시각을 읽는다.
  • 방금 발행한 제목과 일치하면 post_id와 최종 URL을 보강한다.
  • CLI 출력에도 최종 URL과 RSS 기준 발행 시각을 남긴다.

코드 길이로 보면 거창한 변화는 아니다. 그런데 실제 운영 감각은 꽤 달라졌다. 이전에는 발행 후 결과를 사람이 다시 해석해야 했다면, 지금은 스크립트가 스스로 한 번 더 확인하고 답을 준다. 나는 이런 변화를 좋아한다. 자동화가 더 똑똑해졌다기보다, 나중에 덜 헷갈리게 됐다는 쪽에 가깝기 때문이다.

4. 오늘 작업은 디버깅보다 정리의 성격이 더 강했다

재미있는 건, 오늘 한 일이 전형적인 버그 수정이라기보다 운영 감각을 정리하는 쪽에 더 가까웠다는 점이다. 코드가 아예 터지는 문제가 있었던 건 아니다. 오히려 "대체로 되는데, 끝이 덜 선명하다"는 상태였다. 이런 상태는 급하지 않아서 계속 미루기 쉽다. 그런데 프로젝트가 점점 길어질수록 이런 모호함이 더 피곤해진다.

나는 요즘 이런 작업을 조금 더 의식적으로 하고 있다. 앞단에서 후보 논문을 고르는 기준을 정리하는 일도 그렇고, 뒷단에서 발행 결과를 읽기 쉽게 만드는 일도 그렇다. 겉으로 화려한 기능보다도, 각 단계가 어느 정도로 명료하게 닫히는지가 프로젝트 체력을 만든다고 느낀다. 오늘은 그중에서도 출구 쪽, 그러니까 발행 이후의 해상도를 높인 날이라고 보면 맞다.

특히 내가 마음에 들었던 건, RSS를 단순한 구독 포맷이 아니라 검증 수단으로 다시 썼다는 점이다. 공개 페이지에 실제로 반영됐는지를 보는 데는 내부 상태보다 외부 신호가 더 낫다. 오늘은 이 당연한 사실을 코드로 다시 옮긴 셈이다.

5. 커밋 한 줄이지만, 오늘의 고민이 꽤 그대로 남았다

코드 수정 후에는 바로 커밋도 남겼다. 나는 요즘 개발 일지를 쓰기 전에 가능하면 먼저 커밋을 남기는 편을 선호한다. 그래야 글이 "오늘 뭘 한 것 같은 기분"에서 끝나지 않고, 실제 변경과 연결된다. 오늘 메시지도 딱 오늘 고민을 그대로 담는 쪽으로 남겼다. 발행 결과를 RSS fallback으로 검증한다는 내용이었다.

49f8f43 Verify published posts via RSS fallback

짧은 한 줄이지만 나중에 다시 보면 오늘 왜 이걸 손댔는지 바로 떠올릴 수 있을 것 같다. 이전 커밋들이 탐색기 쪽 품질이나 발행 결과 URL 추출 쪽을 다뤘다면, 오늘은 그 다음 단계인 실제 공개 반영 검증까지 한 칸 더 밀어 넣은 셈이다. 이렇게 보면 최근 작업들이 제법 한 줄로 이어진다. 입구를 다듬고, 출구 메시지를 선명하게 만들고, 이제는 공개 확인까지 붙였다.

6. 오늘 하루를 돌아보면, 내가 원하는 자동화는 화려함보다 신뢰감에 가깝다

오늘 작업을 마치고 나서 다시 느낀 건, 내가 이 프로젝트에서 정말 원하는 건 엄청난 기능 확장이 아니라는 점이다. 오히려 각 단계가 덜 불안하고, 덜 애매하고, 결과가 더 바로 읽히는 상태를 원한다. 논문을 고르는 단계도 그렇고, 글을 발행하는 단계도 그렇고, 결국 중요한 건 내가 나중에 다시 봤을 때 "이건 이렇게 끝났구나"를 곧바로 이해할 수 있는 구조다.

개발 일지를 쓰는 입장에서도 오늘 같은 날이 더 마음에 든다. 엄청난 기능이 들어간 날은 아니지만, 실제로 불편했던 지점을 하나 줄였고, 그 변화가 커밋으로 남았고, 지금 이 글도 그 흐름 위에 있다. 이런 날들이 쌓여야 프로젝트가 덜 피곤해진다. 오늘 하루는 딱 그 방향으로 조금 더 움직인 날이었다. 발행 성공이라는 한 줄보다, 마지막 확인까지 자동화하려고 했던 집착이 더 또렷하게 남는 하루였다.

댓글

홈으로 돌아가기

검색 결과

"" 검색 결과입니다.