GPTs로 블로그 글의 최소 품질을 관리해보자

요약#

GPTs를 블로그 글 검사 도구처럼 활용해 글을 쉽게 발행하지 않기 위한 기준을 구조로 만들어 보았습니다.

평가 리라이팅 출력 단계를 각각 분리해 글을 쓰는 과정 안에 한 번 더 멈춰 보는 절차를 추가했습니다.

그 결과 글의 완성도를 인위적으로 높이기보다 발행 전 판단을 다시 점검하게 만드는 흐름이 자연스럽게 자리 잡았습니다.

왜 GPTs를 적용하게 되었는가#

글을 꾸준히 쓰다 보면 어느 순간부터 블로그의 성격이 조금씩 흐려집니다.

당장은 도움이 될 것 같은 메모나 코드 조각이 쌓이기 시작하고 그 기록들이 정말 발행할 만한 글이었는지는 나중에 돌아보게 됩니다.

이 문제를 해결하려면 결국 매번 이 글을 지금 발행해도 되는가를 판단해야 했습니다. 그러나 그 판단을 항상 스스로에게 맡기는 방식에는 분명한 한계가 있었습니다.

바쁠 때는 기준을 느슨하게 적용하게 되고 글쓰기가 습관이 되지 않으면 판단 자체를 생략하게 되었습니다.

처음에는 체크리스트나 템플릿 같은 정적인 도구를 떠올렸습니다. 그러나 글의 길이와 맥락이 달라질수록 이런 방식은 쉽게 형식적인 절차로 변했습니다.

문장을 실제로 읽고 맥락을 따라가며 일정한 관점에서 판단해 줄 무언가가 필요했습니다.

그때 눈에 들어온 것이 GPTs였습니다.

GPTs는 미리 정해 둔 지침과 맥락 안에서 판단하고 반응하도록 설계할 수 있는 구조였고 매번 프롬프트를 다시 작성하지 않아도 되는 점이 특히 인상적이었습니다.

이 방식은 발행 전 단계에서 한 번 더 검토하고 항상 같은 기준으로 글을 다시 바라볼 수 있게 돕는 구조를 만들기 위한 선택이 되었습니다.

GPTs를 페르소나 템플릿으로 생각하다#

처음 GPTs(커스텀 GPT) 기능을 알게 되었을 때는 매번 페르소나 프롬프트(Persona Prompt)를 다시 작성하지 않아도 되는 편의성 기능 정도로만 생각했습니다.

커스텀 GPT를 하나 만들어 두면 자주 쓰는 설명을 반복하지 않아도 되니 조금은 편하겠다는 정도였고 굳이 그렇게까지 할 필요가 있을까라는 생각도 있었습니다.

그런데 몇 번 직접 사용해 보니 이 기능을 단순한 프롬프트 저장소로만 보기에는 조금 다른 쓰임이 보이기 시작했습니다.

GPTs의 기능을 조금 더 들여다보다#

LLM을 활용하는 다양한 사례를 접하면서 GPTs의 구성 요소를 다시 차분히 살펴보았습니다.

지침, 대화 스타터, 지식 파일 업로드, 권장 모델 선택, 기능 설정, 작업 구성까지 GPTs는 단순한 프롬프트 래퍼라기보다는 작은 실행 환경에 더 가까워 보였습니다.

특히 눈에 들어왔던 것은 지식 기능이었습니다.

필요한 매뉴얼이나 내부 문서를 미리 정리해 두고 그 범위 안에서만 질문을 받도록 구성하는 방식이 생각보다 폭넓게 활용되고 있었습니다.

이걸 보면서 GPTs를 단순한 인터페이스가 아니라 특정 맥락을 강하게 씌운 도구로 다뤄볼 수도 있겠다는 생각을 하게 되었습니다.

별도의 파인튜닝 없이도 지침과 지식만으로 어디까지 알고 있어야 하는지를 명확히 제한할 수 있다는 점이 특히 인상적이었습니다.

블로그 검사 도구 만들기#

이 지점에서 GPTs를 블로그 글을 점검하는 장치로 활용해 보기로 했습니다.

단순히 링크를 모으거나 자주 사용하는 코드 조각을 저장하는 목적이라면 블로그보다는 북마크나 스니펫 도구가 더 잘 어울렸습니다.

그런 기록까지 모두 블로그에 포함하기 시작하면 어느 순간부터 글을 통해 남기고 싶었던 기준이 조금씩 흐려진다는 느낌이 들었습니다.

그래서 이번에는 블로그에 담을 대상을 좀 더 선별적으로 다뤄보기로 했습니다.

다만 그 기준을 혼자서 꾸준히 유지하는 일은 생각보다 쉽지 않았습니다.

컴파일러가 타입 오류를 잡아내고 린트가 코드 스타일을 강제하듯 블로그 글에도 일정한 기준을 점검해 주는 구조가 필요하다고 느꼈습니다.

이런 과정을 거친 뒤에야 비로소 이 글을 발행해도 좋다는 판단을 내릴 수 있었습니다.

글쓰기가 습관이 되지 않으면 결국 스스로와 타협하게 된다는 점도 이 과정에서 분명해졌습니다.

그래서 글을 발행하기 전에 AI 리뷰어를 두고 평가 점수를 확인하는 단계를 추가했습니다.

프롬프트를 나누게 된 이유#

GPT와 함께 GPTs의 지침과 지식 파일을 작성해 나가면서 모든 내용을 하나의 지침에 담기보다는 역할에 따라 나누는 쪽이 낫겠다고 판단했습니다.

프롬프트를 나눈 이유는 GPT를 더 똑똑하게 만들기 위해서라기보다 긴 블로그 글에서도 판단 기준이 흐려지지 않게 하기 위함이었습니다.

고민의 출발점은 평가를 한다는 행위 자체보다 긴 본문을 다루는 과정에서 GPT가 맥락을 끝까지 유지할 수 있을지에 대한 의문이었습니다.

본문 텍스트만으로도 컨텍스트를 상당 부분 사용하는 상황에서 평가 기준과 출력 규칙까지 하나의 프롬프트에 모두 얹다 보면 무엇을 우선해야 하는지 쉽게 흐려질 수 있겠다고 생각했습니다.

그래서 GPTs에는 공통 지침만 두고 역할에 따라 해야 할 일만 나눈 뒤 각 모드에서 필요한 정보만 읽도록 구성했습니다.

평가용, 리라이팅용, 최종 출력용처럼 역할이 분명한 작업들은 각각의 md 파일로 분리했고 한 모드의 규칙이 다른 모드로 흘러가지 않도록 의도적으로 구분했습니다.

이 과정은 단순한 분리가 아니라 실제 작성 프로세스를 단계별로 진행하는 구조에 가깝습니다.
즉 평가, 리라이팅, 최종 출력 순서로 자연스럽게 이어지는 하나의 작성 흐름이 되었습니다.

각 단계는 GPTs 내부에서 다음과 같이 참조됩니다.

• manuscript-evaluation-spec.md → 글의 평가 기준과 감점 항목 정의
• blog-rewriting-spec.md → 리라이팅 과정에서 따라야 하는 표현 및 생성 제한 규칙 정의
• blog-markdown-output-spec.md → 최종 출력 시 마크다운 구조 및 FrontMatter 규칙

각 모드는 서로의 파일을 직접 읽지 않으며 GPTs가 지정된 파일만 참조하도록 설정했습니다.
이 방식 덕분에 한 모드에서 수정한 규칙이 다른 모드로 누출되지 않고 각 단계의 판단 기준이 명확히 분리된 상태로 유지되었습니다.

글의 품질을 다시 보게 되다#

이 구조를 적용한 뒤 글을 쓰는 속도 자체가 달라졌다고 말하기는 어렵습니다.

하지만 글을 마무리한 직후 바로 발행하기보다는 한 번 더 멈춰서 본문을 다시 읽어보는 일이 확실히 늘었습니다.

AI 리뷰어를 적용하기 전에는 일단 기록해 두자는 판단으로 글을 정리하는 경우가 많았습니다.

문맥이 조금 느슨하거나 결론이 정리되지 않아도 지금 아니면 못 쓸 것 같다는 이유로 그대로 발행하곤 했습니다.

평가 단계를 거치기 시작한 이후에는 글을 발행하기 직전에 자연스럽게 몇 가지를 다시 점검하게 되었습니다.

이 글에서 다루고자 한 경험이 처음부터 끝까지 유지되고 있는가, 설명을 위해 필요한 맥락이 충분히 드러나 있는가, 지금 이 상태가 기록으로 남겨도 괜찮다고 느껴지는가 같은 질문들이 생겼습니다.

점수가 낮게 나온 글은 바로 발행하기보다 잠시 보류하거나 다른 글의 일부로 흡수하는 경우가 많아졌습니다.

이전 같으면 그대로 공개했을 글이 이제는 다시 손을 보게 되었습니다.

이 과정을 거치며 느낀 점은 AI 리뷰어가 글의 품질을 직접 바꾸는 존재라기보다 글을 대하는 태도를 다르게 만드는 장치에 가깝다는 것이었습니다.

결국 이 구조는 글을 수정하기보다 판단을 멈추게 만드는 시간을 만들어 주었습니다.

참고자료#

• https://openai.com/index/introducing-gpts/