GPTs로 나만의 기획 보조 도구 만들어본 기록

 

2023년 11월에 GPTs라는 기능이 공개됐어요.
코드를 쓰지 않고도 나만의 맞춤형 챗봇을 만들 수 있다는 소개였습니다.

처음에는 솔직히 "결국 프롬프트를 저장해두는 기능 아닌가" 하고 가볍게 생각했어요.
그런데 예약 서비스 기획을 하면서 비슷한 요청을 ChatGPT에 반복해서 붙여 넣고 있다는 걸 깨달았습니다.
매번 "너는 꼼꼼한 기획 리뷰어야, 아래 문서를 읽고..." 하고 같은 문장을 복사하고 있었거든요.

그 반복을 줄여보고 싶어서 몇 주 동안 이것저것 만들어봤습니다.
이 글은 그 기록입니다.
제품의 세부 사양을 정리하는 글은 아니고, 만들어보며 느낀 개념과 경험 위주로 적어봤어요.
화면 구성이나 제한 사항은 계속 바뀌는 것 같아서, 정확한 내용은 공식 안내를 보시는 게 맞습니다.

 

제가 이해한 GPTs의 핵심은 "대화를 시작하기 전에 깔아두는 기본 약속"을 만드는 것이었어요.
그 약속을 적는 곳이 지침(instructions)입니다.
같은 모델이라도 지침에 무엇을 적느냐에 따라 전혀 다른 도구처럼 행동했어요.

처음에 쓴 지침은 이런 식이었습니다.
"너는 기획서를 검토하는 도우미야. 문서를 읽고 부족한 점을 알려줘."
결과는 뻔했어요.
"전반적으로 잘 작성되었습니다. 다만 세부 내용을 보완하면 좋겠습니다" 같은 밋밋한 답이 나왔습니다.

몇 번 고쳐 쓰면서 정리한 저만의 틀은 네 가지입니다.

첫째는 역할과 목적을 구체적으로 적는 거예요.
"예약 서비스 기획서를 읽는 개발자의 입장에서, 구현하다 막힐 만한 지점을 찾는다"처럼 누구의 눈으로 보는지를 정해줍니다.

둘째는 하지 말아야 할 것을 적는 거예요.
"칭찬은 하지 않는다", "문서에 없는 내용을 추측해서 채우지 않는다" 같은 문장이 의외로 효과가 컸어요.

셋째는 출력 형식을 고정하는 거예요.
"질문은 최대 7개, 각 질문 뒤에 왜 이 질문이 필요한지 한 줄로 적는다"처럼 틀을 주면 결과를 훑어보기 편했습니다.

넷째는 예시를 한두 개 넣는 거예요.
좋은 질문과 나쁜 질문을 하나씩 보여주면 말로 설명하는 것보다 훨씬 잘 따라오더라고요.

이 네 가지는 결국 프롬프트 공부 때 정리했던 내용과 같았어요.
GPTs가 새로운 기술이라기보다는, 잘 쓴 프롬프트를 한곳에 고정해두는 방법이라는 생각이 들었습니다.

 

GPTs에는 참고 자료로 파일을 함께 올려둘 수 있었어요.
저는 이 기능으로 "내 기획 문서의 기준"을 넣어보고 싶었습니다.

예를 들어 이런 파일들을 만들어서 올렸어요.
업장, 서비스, 자원, 슬롯 같은 단어의 뜻을 적은 용어 사전이 하나였고,
자주 놓치는 예외 케이스 체크리스트가 또 하나였습니다.

용어 사전을 넣어둔 효과는 확실히 있었어요.
"슬롯"이라는 단어를 제가 의도한 뜻으로 이해하고 대답해주니까, 용어를 매번 설명하는 수고가 줄었습니다.

다만 파일을 넣었다고 해서 그 내용을 항상 정확히 찾아 쓰는 건 아니었어요.
이 부분은 아래 한계에서 다시 이야기할게요.

 

실제로 가장 자주 쓰게 된 건 두 가지였습니다.

하나는 "기획서 검토 질문 도우미"예요.
기획서의 한 부분을 붙여 넣으면, 읽는 사람이 물어볼 만한 질문을 뽑아줍니다.

가정 예시를 들어볼게요.
"예약 취소는 이용 시작 24시간 전까지 가능합니다"라는 문장을 넣었다고 해보겠습니다.
도우미는 이런 질문을 돌려줘요.
24시간의 기준은 예약 시작 시각인가요, 서비스가 실제로 시작되는 시각인가요?
영업일이 아닌 날이 끼어 있으면 24시간을 어떻게 세나요?
취소 마감이 지난 뒤 운영자가 직접 취소해주는 경우는 정책 안인가요, 밖인가요?

이런 질문은 제가 혼자 읽어서는 잘 안 보이던 것들이에요.
내가 쓴 문장은 머릿속 맥락으로 채워서 읽게 되기 때문에, 빈틈이 있어도 빈틈으로 안 보이거든요.
도우미가 던진 질문 중 절반쯤은 이미 생각해둔 것이었고, 나머지 절반 중 한두 개가 "아, 이건 정말 안 정했네" 싶은 것이었어요.
그 한두 개를 건지는 것만으로도 충분히 쓸모가 있었습니다.

다른 하나는 "예외 케이스 찾아주는 도우미"예요.
영업시간, 브레이크타임, 서비스 소요시간 같은 조건을 붙여 넣으면 어긋날 수 있는 상황을 나열해줍니다.

예를 들어 "영업시간은 오전 10시부터 오후 8시, 서비스 소요시간은 90분"이라고 넣으면 이런 식이에요.
마지막 예약 가능 시각은 오후 6시 30분인가, 아니면 시작 시각만 8시 전이면 되는가?
임시 휴무를 지정했는데 그날 이미 들어온 예약은 어떻게 하나?
서비스 소요시간을 운영 중에 바꾸면 이미 잡힌 예약도 같이 바뀌나?

이 도우미에는 지침에 "기획자가 결정해야 할 항목과 개발자가 확인해야 할 항목을 나눠서 적는다"는 문장을 넣었어요.
덕분에 결과를 받아서 바로 "내가 정할 것"과 "물어볼 것"으로 나눌 수 있었습니다.

 

좋은 점만 있었던 건 아니에요.
몇 가지 아쉬움이 분명했습니다.

가장 큰 건 일관성이에요.
같은 입력인데도 어떤 날은 질문이 날카롭고, 어떤 날은 평범한 이야기만 늘어놓았어요.
지침에 형식을 아무리 고정해도 내용의 깊이까지 고정되지는 않더라고요.
그래서 결과를 그대로 믿기보다 "질문 후보를 늘려주는 도구"로 쓰는 쪽으로 기대를 낮췄습니다.

파일 활용도 기대만큼은 아니었어요.
체크리스트 파일에 분명히 있는 항목인데 답변에서 빠지거나, 반대로 파일에 없는 내용을 있는 것처럼 말하는 경우가 있었습니다.
파일이 길어질수록 이런 일이 잦다는 인상을 받았어요.
그래서 파일은 짧고 분명하게 쪼개서 올리는 편이 낫다고 느꼈습니다.
이건 제 경험일 뿐이라 상황에 따라 다를 수 있어요.

붙여 넣은 한 단락만 보고 질문하니까, 다른 장에 이미 정의해둔 내용을 다시 묻는 일도 있었어요.

결국 이 도구들은 판단을 대신해주지 않아요.
빈틈의 후보를 던져줄 뿐이고, 무엇이 진짜 빈틈인지는 여전히 제가 정해야 했습니다.

 

만들면서 가장 신경 쓴 건 무엇을 넣지 않을지였어요.

지침과 업로드한 파일은 챗봇이 대화할 때마다 참고하는 자료예요.
그래서 민감한 정보를 한번 넣으면 계속 거기 남아 있다고 생각하고 다루는 게 안전하다고 봤습니다.

제가 정한 규칙은 간단해요.
고객 이름, 연락처, 예약 내역 같은 개인정보는 넣지 않는다.
계약서나 내부 자료처럼 공개되면 곤란한 문서는 붙여 넣지 않는다.
실제 서비스의 키나 비밀번호 같은 값은 당연히 넣지 않는다.
예시가 필요할 때는 "미용실 A, 고객 B"처럼 지어낸 가짜 데이터를 쓴다.

또 하나, 만든 도구를 다른 사람에게 공유할 수 있는 옵션이 있었는데요.
공유 범위를 정하기 전에 지침과 파일에 들어 있는 내용이 그대로 노출될 수 있다는 점을 먼저 생각해보는 게 좋을 것 같았어요.
저는 지금까지는 혼자만 쓰고 있고, 공유할 일이 생기면 그때 다시 한번 내용을 훑어볼 생각입니다.
데이터가 어떻게 처리되는지에 대한 정책도 서비스마다, 시기마다 달라질 수 있어서 공식 안내를 확인하는 습관이 필요하다고 느꼈어요.

 

GPTs를 몇 주 써본 지금의 생각은 이렇습니다.
대단한 자동화 도구라기보다는, 내가 자주 하는 생각의 습관을 밖으로 꺼내 고정해두는 도구에 가깝다는 거예요.
도구를 만들려면 내가 어떤 기준으로 기획서를 읽는지를 먼저 말로 적어야 하는데, 그 과정 자체가 공부가 됐습니다.

지침을 쓰다 보면 "나는 이런 걸 중요하게 보는구나", "이건 내가 늘 놓치는구나" 하는 것이 드러나요.
도구보다 그 과정에서 얻은 게 더 컸을지도 모르겠어요.

남은 질문도 있어요.
결과의 일관성을 어떻게 높일 수 있을지,
문서 전체를 넣었을 때 맥락을 제대로 쓰게 하려면 어떻게 해야 할지,
그리고 여러 사람이 함께 쓰게 되면 지침과 파일은 누가 어떻게 관리해야 할지 같은 것들이에요.

이 부분은 RAG나 도구 호출 같은 개념을 더 공부하면 감이 올 것 같아서, 다음에 정리해볼 예정입니다.