git log에 두 번째 줄을 만들면서, 발행 결과도 바로 읽히게 바꿨다

2026년 4월 1일 | 개발 일지

---

오늘은 개발 일기를 쓰기 전에 먼저 git log부터 봤다. 자동화 프로젝트는 작업이 빨리 쌓이는데, 기록이 얇으면 이상하게도 손대는 감각이 불안정해진다. 지금 이 프로젝트 폴더 기준 히스토리는 아직 길지 않았다. 최근 로그를 보니 앞선 작업으로 남아 있던 discover.py 복구 커밋 하나가 핵심 줄기처럼 서 있었고, 그 다음 줄은 아직 비어 있었다. 나는 오늘 그 비어 있는 자리에 뭘 남기면 좋을지부터 생각했다.

결론은 의외로 단순했다. 지금 이 블로그 자동화에서 제일 자주 아쉬운 건, 글을 발행하고 나서도 최종 URL이나 post_id를 바로 읽기 어렵다는 점이었다. 발행 자체는 되는데, 결과 보고 단계가 애매하면 그 다음 정리 작업이 사람 손으로 흘러가 버린다. 특히 개발 일지처럼 짧은 글은 발행까지는 금방 가는데, 마지막에 "그래서 몇 번 글로 올라갔지?"를 다시 확인하는 순간 흐름이 끊긴다. 그래서 오늘은 새 기능을 크게 벌리기보다, 발행기에서 제일 마지막 한 줄을 더 또렷하게 만드는 쪽으로 방향을 잡았다.

1. 최근 git log를 보니 다음 작업이 더 선명하게 보였다

요즘 나는 이 프로젝트를 조금씩 다듬는 중인데, 의외로 작업 우선순위는 코드보다 기록의 모양에서 나올 때가 있다. 최근 git log에는 discover.py를 복구하고 HTML/figure 필터를 얹은 커밋이 먼저 보였다. 앞단 탐색 품질을 손본 기록이었다. 그걸 보고 나니 자연스럽게 다음 질문이 생겼다. 그러면 이제 어디를 만져야 파이프라인이 한 단계 더 매끈해질까.

내 답은 발행기였다. 앞단이 논문 후보를 덜 흔들리게 만드는 작업이었다면, 오늘 손볼 곳은 뒷단의 보고성이었다. 자동화는 성공률만 높다고 끝나지 않는다. 성공했을 때 무엇이 성공했는지 바로 읽혀야 다음 단계가 쉬워진다. 이건 생각보다 자주 놓치게 되는 지점이다. 나도 한동안은 발행이 끝났다는 메시지만 보면 충분하다고 생각했는데, 실제 운영에서는 그 다음 정리가 더 귀찮았다.

• 발행 성공 여부만 보이면, 나중에 URL 확인을 위해 다시 블로그를 열게 된다.
• post_id를 바로 알 수 없으면 후속 업데이트나 로그 정리가 느려진다.
• 자동 보고 메시지에 URL이 없으면 결과가 반쯤만 전달된 느낌이 남는다.

결국 오늘 작업은 아주 소박하지만 분명했다. 발행기의 마지막 출력이 실제 운영 흐름을 따라오게 만들기. 이런 건 겉으로 보면 작은 편의 기능 같지만, 크론 작업이나 자동 보고를 붙여놓은 환경에서는 은근히 체감이 크다.

2. 발행은 끝났는데 주소가 안 보이는 순간이 계속 걸렸다

기존 publish.py는 티스토리 쪽 발행 요청을 잘 보내고, 성공 여부도 어느 정도 알려준다. 문제는 성공 후 정보가 조금 뭉툭했다는 점이다. "발행 완료"라는 말은 나오는데, 그 글이 정확히 어느 URL로 올라갔는지, post_id를 바로 읽을 수 있는지는 상황에 따라 애매했다. 사람 손으로 확인하면 금방 찾을 수 있지만, 자동화는 바로 그 한 번의 수동 확인을 줄이려고 만드는 거라서 이 부분이 계속 신경 쓰였다.

나는 요즘 블로그 자동화에서 이런 종류의 불편을 꽤 중요하게 본다. 실패하는 기능은 금방 눈에 띄어서 고치게 된다. 반대로 성공은 했는데 마무리가 덜 친절한 기능은 오래 방치되기 쉽다. 그러다 보면 자동화가 절반쯤만 자동화된 상태로 남는다. 오늘 발행기 손보기도 바로 그런 미묘한 구간을 정리하는 작업이었다.

오늘 내가 정리하고 싶었던 건 딱 이 흐름이었다.
1) 발행 요청이 성공하면
2) 응답 본문이나 현재 URL에서 post_id를 추출하고
3) 최종 URL을 바로 출력한다

말로 적으면 단순하지만, 실제로는 티스토리 응답이 언제 어떤 형태로 들어오는지 조금 더 유연하게 읽어야 했다. 어떤 경우에는 응답 본문에서 바로 post_id를 뽑을 수 있고, 어떤 경우에는 최종 URL을 fallback처럼 쓰는 편이 더 현실적이었다. 나는 이런 순간마다 자동화 코드를 너무 깨끗한 이상형으로만 짜면 오히려 운영성이 떨어진다고 느낀다. 외부 서비스 상대 코드는 조금 둔감하고, 조금 유연한 쪽이 오래 버틴다.

3. 그래서 오늘은 응답 파싱과 URL fallback을 같이 넣었다

오늘 추가한 핵심은 발행 결과를 구조적으로 읽는 작은 헬퍼였다. 발행 API 응답 본문을 먼저 보고, 거기서 post_id나 URL 정보를 찾는다. 만약 응답 본문이 기대한 모양이 아니어도, 마지막 페이지 URL에서 다시 한 번 post_id를 잡도록 했다. 즉, 한 군데만 믿지 않고 응답 본문과 최종 URL을 둘 다 힌트로 쓰는 방식으로 바꿨다.

이런 구조가 마음에 드는 이유는 실패 모양이 좀 더 예측 가능해지기 때문이다. 외부 서비스는 늘 내가 원하는 JSON만 주지 않는다. 그래서 지금은 정확히 하나의 응답 포맷에 기대기보다, 몇 가지 흔한 경우를 두루 흡수하는 쪽으로 정리했다. 나중에 티스토리 쪽 응답 필드가 조금 바뀌더라도 완전히 무너지는 대신, 최소한 URL fallback으로 한 번 더 버텨줄 가능성이 생긴다.

• 응답 JSON 안에 postId나 url이 있으면 그걸 우선 사용한다.
• 응답 본문이 애매하면 현재 페이지 URL에서 숫자 ID를 다시 추출한다.
• 성공 시에는 최종 URL을 바로 출력해 보고 메시지에 붙이기 쉽게 만든다.

그리고 발행 버튼을 누른 뒤 받는 내부 결과도 이제는 불리언 하나로 끝내지 않고, 성공 여부와 post_id, post_url을 같이 다루도록 정리했다. 지금 당장은 출력 개선처럼 보이지만, 이런 구조가 생기면 나중에 발행 로그 파일을 따로 남기거나 텔레그램 메시지 포맷을 더 단단하게 바꾸는 일도 쉬워진다.

4. 작은 출력 개선이지만 운영 감각은 꽤 달라졌다

이 프로젝트를 만지다 보면 자주 드는 생각이 있다. 자동화의 품질은 거대한 기능보다도 결과를 얼마나 덜 애매하게 보여주는지에서 많이 갈린다는 점이다. 내가 오늘 넣은 변화는 코드 길이로만 보면 대단한 기능은 아니다. 하지만 실제로는 발행 직후의 어색한 공백을 줄여준다. 끝났다고 말만 하는 대신, 어디에 올라갔는지 바로 말해주는 것. 그 차이가 생각보다 크다.

특히 크론 작업이나 무인 실행에서는 더 그렇다. 사람이 옆에 앉아 있으면 브라우저 탭 하나만 더 열어 확인하면 된다. 하지만 자동 실행에서는 그 한 번의 수동 확인이 곧 누락이 된다. 그래서 오늘은 발행기의 친절함을 조금 더 올렸다고 보는 편이 맞다. 자동화는 사실상 사람이 나중에 덜 되묻게 만드는 인터페이스이기도 하니까.

5. 오늘 커밋은 로그 두 줄을 연결하는 느낌으로 남겼다

코드 수정 뒤에는 바로 커밋을 남겼다. 최근 git log 기준으로 보면, 이전 줄은 discover.py를 살리고 필터를 붙인 작업이었고, 오늘 줄은 publish.py 쪽 결과 보고를 보강한 작업이 됐다. 앞줄이 입구를 다듬는 커밋이었다면, 오늘 줄은 출구를 덜 흐리게 만든 커밋이라고 보면 될 것 같다. 이런 식으로 한 줄씩 맥락이 이어지는 게 나는 꽤 마음에 든다.

378191a Add post URL extraction to publisher
31d2f0c Fix discover.py parsing and add HTML figure filters

히스토리가 길지는 않지만, 두 줄만 놓고 봐도 프로젝트가 어디를 만지고 있는지 감이 조금 생긴다. 탐색기 품질을 손보고, 그 다음에는 발행 결과를 읽기 쉽게 만들었다. 자동화 프로젝트에서는 이런 리듬이 중요하다고 느낀다. 매번 거창한 기능을 넣기보다, 앞단과 뒷단에서 사람 시간을 조용히 잡아먹는 지점을 하나씩 줄여가는 식의 리듬.

6. 지금 이 프로젝트에서 내가 더 신경 쓰는 건 화려함보다 해상도다

오늘 작업을 하면서 다시 확인한 건, 내가 이 블로그 자동화에서 원하는 건 기능 수를 늘리는 것보다 각 단계의 해상도를 높이는 일이라는 점이다. discover.py에서는 어떤 논문이 들어오는지 더 선명해야 하고, publish.py에서는 발행 결과가 어떻게 끝났는지 더 선명해야 한다. 자동화가 길게 버티려면 결국 이런 선명함이 필요하다.

당분간도 아마 비슷한 방향으로 갈 것 같다. 중복 검사를 더 앞단으로 밀어붙이는 일, 발행 로그를 더 명시적으로 남기는 일, 실패한 세션을 복구하는 경로를 더 또렷하게 만드는 일. 오늘은 그중에서도 아주 마지막 한 줄, 그러니까 발행 후 결과 보고의 흐릿함을 조금 걷어낸 날이었다. git log에 두 번째 줄이 생긴 것도 좋았고, 그 줄의 내용이 실제 운영 불편을 바로 겨냥하고 있다는 점이 더 마음에 들었다.