TPublisher 개발은 AI가 생성한 HTML 콘텐츠를 Tistory에 발행하는 과정에서 발생하는 불편함을 해결하기 위해 시작했다. 처음 목표는 이미지가 포함된 HTML 콘텐츠를 Clipboard로 전달할 때 발생하는 느린 처리 시간을 개선하는 것이었다.
처음에는 TPublisher가 생성하는 Clipboard 데이터가 너무 크고, Base64 이미지가 포함된 HTML 구조 때문에 성능 문제가 발생한다고 판단했다.
첫 번째 가설 - TPublisher 내부 Clipboard 문제
이미지가 Base64 형태로 포함되고 HTML 데이터 크기가 증가하는 구조였기 때문에 이미지 변환 과정과 Clipboard 생성 과정을 먼저 의심했다.
AI와 함께 가설을 검증하다
ChatGPT와 함께 문제 범위를 나누어 분석했다. 단순히 Clipboard 코드를 수정하는 것이 아니라 실제 병목 위치를 확인하기 위해 Base64 이미지 변환 과정, HTML 생성 구조, Clipboard 전달 방식을 단계별로 확인했다.
처음 세운 가설을 바로 구현으로 옮기지 않고, AI와 함께 검증 가능한 형태로 문제를 나누고 측정 결과를 기준으로 다음 방향을 결정하는 방식으로 접근했다.
검증 결과 - Clipboard가 문제가 아니었다
검증 결과 Clipboard 생성 자체는 문제가 아니었다. 실제 지연은 Tistory Editor가 Base64 이미지가 포함된 HTML을 처리하는 과정에서 발생했고 Paste 시간은 약 27초까지 증가했다. 문제의 위치는 TPublisher 내부 Clipboard가 아니라 외부 Editor Pipeline이었다.
AI와 함께 문제를 다시 정의하다
처음 질문은 "Clipboard를 어떻게 빠르게 만들 것인가"였다. 하지만 검증 이후 질문은 "외부 Editor가 정상 처리할 수 있는 발행 Workflow를 어떻게 설계할 것인가"로 변경되었다.
이번 과정에서 AI의 역할은 코드를 대신 생성하는 것이 아니었다. 문제를 정의하고, 가설을 검토하고, 검증 결과에 따라 기존 판단을 변경하는 협업 과정이었다.
시행착오 - 자동화 방향과 WebEngine 검토
Clipboard 문제를 확인한 이후에는 발행 과정 자체를 자동화하는 방향도 검토했다. OAuth 기반 자동 발행, 블로그 플랫폼 변경, ChatGPT 공유 링크 활용, WebEngine 기반 접근까지 여러 가능성을 확인했다.
하지만 WebEngine은 브라우저 환경을 제공하는 기술이지 Tistory Editor 내부 Upload Pipeline 문제를 해결하는 방법은 아니었다. 검증 결과 유지보수와 배포 부담을 고려해 해당 방향은 폐기했다.
최종 판단 - Publishing Workflow Tool
완전 자동화보다 사용자가 안정적으로 발행할 수 있는 Workflow를 지원하는 방향이 적합하다고 판단했다. Tistory Editor의 정상 Upload Pipeline을 활용하기 위해 QDrag 기반 이미지 전달 방식으로 방향을 변경했고, TPublisher는 Clipboard 중심 도구에서 Publishing Workflow Tool로 변화했다.
TPublisher v0.1.0 → v0.1.1
0.1.0은 Preview와 Clipboard Copy 중심의 도구였다.
0.1.1은 Tistory Preview, Image Asset 관리, Thumbnail Drag를 포함하는 발행 Workflow 구조로 확장되었다.
개발 과정에서 얻은 판단
이번 개발에서 가장 중요한 결과는 Clipboard 성능 개선 자체가 아니었다. 처음 세운 가설을 AI와 함께 검증하고 실제 원인을 확인한 뒤 문제 정의를 변경한 과정이 제품 방향을 결정했다. 결과적으로 TPublisher의 개선 방향은 Clipboard 최적화가 아니라, 외부 서비스의 제약을 고려한 Publishing Workflow 설계로 변경되었다.
AI와 함께 개발한다는 것은 코드를 생성하는 과정만을 의미하지 않는다. 문제를 정의하고, 가설을 세우고, 검증하고, 실패한 방향을 버리고, 새로운 해결 방향을 선택하는 협업 과정이다.