놀라운 GPTs를 만들기 위해 고려해야 할 3가지 정체성

올해 하고 싶은 일이 굉장히 많아서 그 어느 해보다 내 시간을 생산적으로 쓰는 게 중요해졌다. 나의 생산성 향상을 돕는 도구가 여럿 있는데, 그 중 현재 가장 신경쓰고 있는 건 역시 GPTs다. 기본적으로는 나를 돕기 위해 만든 GPTs지만 회사 구성원 분들도 잘 사용하고 있는 걸 보면 뿌듯하다. 내 동료들의 생산성이 올라가면 내 생산성도 올라가는 거니까.

이렇게 GPTs를 꾸준히 만지다 보니, GPTs가 단순히 쓸만한 수준을 넘어 놀라울 정도로 유용하게 만들려면 몇 가지 정체성을 고려하는 게 좋다는 걸 느꼈다.

내가 생각하는 GPTs의 3가지 주요 정체성은 다음과 같다.

• GPTs는 (타겟 사용자와 기대 결과가 있는) 제품이다.
• GPTs는 (거의 모든 분야에 대한 전문가 집단에게 보내는) 위임장이다.
• GPTs는 (동작 원리를 정확히 알 수 없는) 블랙박스다.

달리 말하면 내가 GPTs를 만들 때 취하는 멘탈 모델, 또는 설계 방법론이라고 볼 수 있겠다. 아직 항목 하나하나를 자세하게 쓸 내공은 안되니 간단하게만 짚어보자. (이하 pet theory 주의. 반박 또는 보강 진심으로 환영합니다)

GPTs는 제품이다 → 설계

GPTs는 제품이며, 제품을 만들 때 필수적으로 거쳐야 하는 단계는 설계 - 구현 - 테스트다.

설계의 시작은 가치 제안부터다

제품 설계의 시작은 가치 제안(Value Proposition)이다. GPTs도 마찬가지. 내 GPTs로 ‘어떤 사용자의 어떤 문제를 해결할 것인가?’를 가장 먼저 생각해야 한다. 스타트업의 제품들과 마찬가지로 ‘개밥먹기’가 가능하다면 훨씬 유리하다. 즉 사용자 안에 나 자신이 속해 있고, 나의 중요한 문제를 푸는 데 도움을 얻고자 만든 GPTs라면 일단 반은 먹고 들어간다. 내가 며칠 전에 만들어서 스토어에 올려둔 STICC 봇은 그 누구보다도 나를 위해 만든 것이었고, 다음 3가지 목적을 염두에 두었다. 그리고 이것들을 Instructions 의 가장 앞부분에 (영어로) 넣어두었다.

1. 사용자 자신이 그의 문제 또는 작업을 깊이 이해하고 명료하게 만드는 걸 돕는다.
2. 명료하게 된 작업의 행동 계획을 실행 가능하도록 짜는 걸 돕는다.
3. 사용자가 기지의 미지(known unknowns)와 미지의 미지(unknown unknowns)를 인식하도록 돕고, 궁극적으로 1과 2를 스스로 할 수 있을 만큼 충분히 똑똑해지도록 돕는다.

만약 여기서 한 단계 더 나아간다면, ‘무엇은 이 봇의 역할이 아니다’ 같은 걸 추가할 수 있다. 예를 들어 일일 회고를 도와주는 봇인데, 나를 위로해주는 건 굳이 원하지 않는다면 ‘감정적인 위로는 필요하지 않다’고 Instructions에 명시하는 것이다. 이렇게 하면 해결하고자 하는 문제가 더 뾰죡해지는 장점이 있고, 대신 봇의 창발성은 좀 떨어질 수 있겠다.

봇의 5가지 정보를 이용해 온보딩하라

다음은 인터랙션 디자인이다. 이 목적을 위해 제품과 사용자가 어떻게 인터랙션하길 기대하는가? 그 인터랙션을 어떻게 설계할 것인가?

문제는 GPTs 스토어에서 사용자가 봇을 선택하는 데 도움이 되는 정보가 그리 많지 않다는 점이다. 정확히는 딱 다섯 가지다. SITCC 봇을 예로 들면:

• 아이콘: STICC에서 따와서 Stick → 지팡이 → 마술사 를 떠올려 넣은 이미지
• 이름: STICC: Effectively Define Complicated Tasks
• 설명: I’m an expert coach who helps building an executive intent of a task to have an impact, and create doable action plans based on the task. What do you want to clarify with me? Describe your problem or task in detail.
• 제작자: stdy.blog (이 블로그)
• 대화 시작 추천 프롬프트(Conversation Starters): What is STICC?, I have a problem that I need help with.

이 다섯 가지를 최대한 이용해 봇이 어떤 문제를 해결하는지 전달하여 사용자의 첫 행동, 즉 프롬프트 입력을 유도해야 한다. 그중에서도 Conversation Starters를 어떻게 둘지, 거기에 대해 봇이 어떻게 응답해야 할지 디자인하는 게 굉장히 중요하다고 본다. 이게 곧 제품의 온보딩 프로세스니까.

이렇듯 나는 제품으로서의 정체성이 GPTs에게 가장 핵심적인 정체성이며, 다른 제품들처럼 GPTs도 설계에 충분한 노력을 들여야 이후가 편해진다고 생각한다.

여담이지만, STICC 봇을 사용하시는 다른 분들께 처음에 어떻게 대화를 시작해야 할지 잘 모르겠다는 피드백을 몇 번 들었다. 온보딩이 그리 잘 되지 않은 셈이다. 그래서 STICC 소개글을 봇 사용 예시와 함께 영어로 올려서 이 블로그에 올리고, What is STICC? 질문에 대답할 때 그 글의 링크를 포함해서 대답하게 하려고 한다.

GPTs는 위임장이다 → 구현

GPTs의 뒤에 있는 GPT-4는, 비유하자면 웹상에 잘 알려진 거의 모든 분야에 대한 전문가 집단이다. 그러나 이 집단이 너무 많은 내용을 알다 보니 내가 원하는 전문성을 가진 전문가를 소환하려면 열심히 노력해야 한다. 그리고 그 전문가가 본인의 전문성을 발휘했던 기억을 떠올리도록 도와줘야 한다. 특히 ‘해결사’로서의 전문가보다는 내 사고의 확장을 돕는 ‘코치’로서의 전문가가 내게 훨씬 유용하다.

구현은 명료하고 구조적인 글쓰기가 기본이다

내가 원하는 이러한 전문가를 고용하기 위해 “이런 문제를 가진 사람을 나 대신 도와줄, 이런 경험을 가진 전문가를 보내줘. 그 전문가는 이렇게 사람을 도와줘야 해” 라는 위임 의뢰서를 쓰는 게 제품으로서의 GPTs에서 ‘구현’ 파트다. GPTs Configure 에서 Instructions와 Knowledge가 여기에 해당한다.

위임장은 기본적으로 ‘글’이다. 모국어가 영어인 이 전문가가 이해하기 쉬운 형태로 위임장을 잘 써야 응답도 잘 나온다. 영어로 쓰고, 소제목을 넣고, 뚜렷한 목적을 드러내고, 중언부언하지 않고, 중요한 부분은 더 강조하고, 오타 피하고. 개떡같이 말해도 찰떡같이 알아듣는 게 GPT의 장점이라지만 굳이 쓸데없는 곳에 힘을 들이게 할 필요는 없다.

인지적 프롬프팅을 이용해 Instructions를 작성하되 인터랙션을 잊지 말라

글 잘 쓰는 걸 넘어서 구현을 잘 하는 방법은 기존의 ChatGPT를 잘 다루는 법과 크게 다르진 않다. AC2 김창준님의 인지적 프롬프팅 기법을 배운 게 내게 큰 도움이 됐다. 우리가 웹에 질문을 올릴 때, 풍부한 맥락과 정보를 담아 정중한 어조로 질문해야 양질의 답변이 많이 달리지 않던가? 우리가 GPT-4에게 떠올리도록 도와야 하는 게 바로 그런 기억이다. 내가 맥락과 정보를 많이 제공하여 위임장을 쓰면 GPTs가 전문가로서 사용자를, 즉 나를 돕기 수월해진다.

(인지적 프롬프팅에 대한 더 자세한 내용은 원지랩스 곽근봉님이 훌륭하게 정리해두신 슬라이드가 있으니 참고하시길)

하지만 ChatGPT와 GPTs가 다른 부분도 당연히 있다. 인터랙션 디자인이다. 나야 인지적 프롬프팅을 써서 GPTs에게 좋은 프롬프트를 던질 수 있지만 일반 사용자들도 그렇게 하리라는 기대를 할 수는 없다.

그러니 “사용자가 정보가 불충분한 질문을 했을 때 그냥 적당한 답을 생성하는 대신, 사용자가 두뇌를 써서 정보를 더 제공하게 유도해달라”고 위임장에 써둔다. 그러면 이후 그 정보를 이용해 GPTs가 더 유용한 응답을 할 수 있을 것이다. STICC 봇도 그런 형태로 제작했다.

GPTs는 블랙박스다 → 테스트

GPT-4는 동작 원리를 내가 정확히 알 수 없는 블랙박스다. 따라서 내가 통제하며 확인할 수 있는 것은 입력과 출력뿐이다. 즉, 내가 어떤 식으로 입력하면 어떤 식으로 대답해야 하는지에 대한 그림이 내 머릿속에 분명히 있어야 좋은 GPTs가 나온다.

신뢰성을 테스트하기 위한 테스트 케이스 세트를 만들어라

나는 GPTs를 만들 때 항상 두 가지를 확인한다.

• 유용성: 봇을 통해 사용자가 충분한 도움을 얻었는가? 달리 말하면, 이 코치가 좋은 질문과 제안을 던짐으로써 내 특정 문제를 해결하고 사고를 확장하는 데 도움을 주나?
• 신뢰성: 내가 위임장에 부탁한 세부사항들 - 어떤 언어를 써야 한다, 어떤 역할은 할 필요 없다, 어떤 포맷으로 응답해야 한다, Knowledge를 어떻게 활용해야 한다, 어떤 질문에는 대답해서는 안 된다, … - 을 잘 기억하고 그에 맞게 응답하는가?

여기서 전자는 비교적 테스트하기 쉽다. GPT-4가 워낙 똑똑해서 사실 내가 코치 역할을 부여하고, 적당한 정보만 준다면 대개 유용한 응답을 준다. 하지만 후자는 반드시 테스트를 거쳐야 한다.

테스트를 해보면 처음에는 제대로 응답하는 것 같더라도, GPT-4는 같은 입력에 대해 같은 출력을 보장하지 않기 때문에 최소 3번은 테스트를 해봐야 한다. 또한 인간도 글이 길어지면 중간 내용을 까먹는 것처럼, Instructions 와 Knowledge 를 변경하면 앞에서 제대로 응답했던 걸 이번에는 제대로 응답하지 않을 수도 있다. 따라서 정말 신뢰도 높게 응답해야 할 세부사항이 있다면 구현부가 바뀔 때마다 다시 테스트를 하는 게 좋다.

테스트 케이스 세트를 설계에 활용하라

그런데 테스트 케이스들을 만들다 보니 이게 곧 설계에 그대로 활용될 수 있겠다는 판단이 섰다.

• given: 어떤 상황에서
• when: 사용자가 어떤 입력을 하면
• then: 봇이 어떻게 답해야 한다

이걸 여러 개 생각해보는 것만으로 내 GPTs의 설계 디테일이 엄청나게 채워진다. 어떻게 보면 TDD(Test-Driven Development)와 같다. 테스트를 먼저 만들면서 인터페이스를 설계하고, 그 다음 구현에 들어가는 것이다.

단, 앞서 말했듯 GPTs는 블랙박스라서 “사용자가 정확히 이렇게 말하면 정확히 이렇게 답해야 한다”를 텍스트 매칭하듯 확인하는 건 적합하지 않게 느껴진다. 그래서 구조를 좀 바꿔봤다.

• given: 어떤 상황에서
• when: 사용자가 이러한 패턴으로 입력하면
• then: 봇은 이런 패턴으로 답해야 한다
• intent: 이는 [유용성]과 [신뢰성]을 확인하기 위한 테스트다
• examples: 실제 문답

예를 들면 이런 식이다. 만들려는 GPTs의 목적이 “타겟 청중과 해결하고자 하는 문제가 뚜렷한 발표 스크립트 쓰기”를 도와주는 것이라고 할 때,

• given: 사용자가 첫 프롬프트를 넣은 상황
• when: 사용자가 발표 주제를 결정했지만 타겟 청중은 언급하지 않았음
• then: 사용자가 타겟 청중을 정의하도록 돕는 질문을 해야 함
• intent: 타겟 청중을 봇이 제안하는 게 아니라, 스스로 생각할 수 있게 도와주는지 확인하기 위한 테스트.
• examples:
  • 사용자: "나는 기술의 발전이 인간에게 미치는 영향에 대해 발표하고 싶어.”
  • 응답: “기술의 발전이 인간에게 미치는 영향은 다양하고 광범위한 주제입니다. 어떤 종류의 사람들에게 이 주제에 대해 들려주고 싶으신가요?”

그리고 이러한 테스트 케이스를 설계하면서 테스트 하나당 examples를 5개 정도씩 만들었다고 치면, 그중 3개는 Instructions나 Knowledge로 집어넣는다. 사람도 예시를 들면 훨씬 잘 이해하듯, 100번 설명 고치는 것보다 예시 하나 집어넣는 게 훨씬 내 의도대로 행동할 확률이 높다. 이 때 5개 중 3개만 넣는 이유는 오버피팅을 피하고, 단순히 내 말대로 행동하는 앵무새가 아니라 코치로서 내 의도를 이해했는지 확인하기 위해서다.

물론 이렇게 예시를 넣으면, “무엇은 하지 말라”고 명시하는 것과 유사하게 창발성이 떨어질 수 있으니 주의할 필요는 있다. 아무튼 나에게는 이렇게 테스트 케이스를 이용하는 게 유용한 GPTs를 만드는 데 굉장히 유효한 전략이었다. 그래서 “TDD로 GPTs 설계를 돕는 봇”을 TDD로 만들어보고 있다.

결론

쓸만한 GPTs를 넘어 놀라운 GPTs를 만들기 위한 나의 멘탈 모델은 이러하다.

• GPTs를 설계할 때는 이게 사용자의 문제를 해결하는 제품이라는 걸 잊지 않는다. 사용자가 누구고, 어떤 문제를 도울지부터 생각하자.
• GPTs를 구현할 때는 이게 전문가에게 보내는 위임장이라는 걸 잊지 않는다. 어떤 전문가를 모셔올지, 그가 사용자를 어떻게 대하길 원하는지 정중하게 작성하자.
• GPTs를 테스트할 때는 이게 어떻게 동작할지 예측되지 않는 블랙박스라는 걸 잊지 않는다. 신뢰성을 확인할 입력-출력 세트를 만들어 여러 번 테스트하고, 그걸 설계에 활용하자.

이 글에서 예시로 든 STICC 봇은 나의 첫 퍼블릭 봇이고 부족한 점도 아주 많다. 하지만 무엇보다도 나에게는 현재 상태에서도 충분히 유용하기 때문에, 이 봇을 계속 개선하기보다는 배운 점을 가지고 다른 봇을 더 잘 만드는 데 더 시간을 쓰고 있다.

STICC 봇의 어설픔에서 이미 드러났겠지만, 제법 거창하게 글을 썼으나 사실 나도 아직 GPTs의 맛만 본 상태다(Actions는 아직 한번도 안 써봤다). 그래서 이번주에 시작할 김창준, 곽근봉님의 인지적 접근으로 GPTs 만들기 교육이 아주 기대된다. 분명 내가 생각지도 못한 놀라운 것들을 배우게 될 것이다.

(24.01.23 Update) GPTs는 사용자의 상태를 A에서 B로 전이하기 위해 존재한다

나는 GPTs가 코치로서 사용자를 제대로 도우려면 언제나 사용자의 상태를 이해하고, 그에 맞는 질문을 던져야 한다고 생각한다. 이 관점을 테스트 케이스와 결합하면, 사용자의 상태를 일종의 '단계(Phase)'로 보고, "사용자가 특정 단계에서 특정 입력을 하면 특정 출력을 해야 한다"라는 설계를 만들어낼 수 있다.

여기까지 생각하고 나니, GPTs와 사용자의 인터랙션을 state transition으로 나타낼 수 있겠다는 통찰이 생겼다. 즉 "GPTs는 사용자의 상태를 A에서 B로 전이하기 위해 존재한다"는 깨달음이다. 따라서 모든 테스트 케이스를 이런 식으로 작성할 수 있다.

• given: 사용자는 어떤 상태(A)에 있다. 이건 어떤 단계에 해당한다.
• intent: 이 단계의 목표는 사용자를 다음 단계(상태 B로 시작하는)로 만드는 것이다.
  • 코치형 봇의 목적은 사용자의 뇌에 땀이 나게 만들고, 더 똑똑하게 만드는 것임을 염두에 두고 목표 상태를 설계한다.
• when: 사용자가 이런 패턴으로 입력하면
• then: 봇은 평가 기준을 참고하여 사용자의 상태에 대한 평가를 업데이트해야 한다.
  • if: 목표 상태(B)에 도달하지 못했다면, 도달시키기 위한(사용자를 똑똑하게 만드는) 질문을 포함해 응답해야 한다.
  • else: 목표 상태(B)에 도달했다면 사용자에게 단계를 넘어갈지 말지 확인 후 다음 단계로 나아가야 한다.
  • exception: 최초 단계 진입시 사용자가 이미 목표 상태(B)에 도달했다면 다음 단계로 바로 넘어간다.
• examples: 봇이 평가와 질문할 때 참고할 예시를 준다. 단, 긍정적 창발성을 유지하기 위해 예시를 그대로 쓰는 게 아니라 참고만 하라고 명시한다.
  • for evaluation: 사용자가 이런 발화를 했다면 이런 단계로/이런 상태로 판단한다.
  • for question: 사용자가 이런 상태일 때는 이런 질문을 해야 한다.

이런 테스트 케이스들을 조금만 구조화하면 Instructions에 바로 집어넣을 수 있다. 사실 STICC 봇을 만들 때는 이정도로 테스트에 대한 생각이 구체화되지 않았었는데, '상태 전이'와 '단계'에 대한 구상은 있었기 때문에 실제로 Instructions는 이것과 굉장히 유사하게 만들어졌다. (STICC 봇의 구체적 설계 방식에 대해서는 별도의 글로 풀어보겠다)

물론 내가 이렇게 입력해둔다고 해서 그대로 행동하리라는 보장은 없다. 이건 구현(인지적 프롬프팅)의 영역이며, 신뢰성 테스트의 대상이 된다. 테스트를 이용해 설계하고, 설계한 대로 구현하고, 구현을 테스트하고. 좋은 GPTs를 만드려면 설계와 구현과 테스트는 하나씩 거치는 게 아니라 계속 왔다갔다 할 수밖에 없다.

(24.01.24 Update) 상태 전이와 TDD 개념을 이용해 GPTs 설계를 돕는 GPTs

위의 아이디어를 더 발전시켜, GPTs 설계를 돕는 GPTs를 만들었다. 일반화된 챗봇에도 적용할 수 있을 거라고 봤기 때문에 이름은 ChatBot StateFlow Strategist. 조만간 제작 과정을 소개하는 글을 쓰려고 한다.