ChatGPT API가 열렸다, 간단한 호출 직접 해보기

 

3월 초에 ChatGPT를 만든 곳에서 API를 공개했다는 소식을 봤습니다.
지금까지는 대화창에서 쓰는 도구였다면, 이제는 내가 만드는 프로그램 안에서 같은 계열의 모델을 불러 쓸 수 있게 된 거예요.
저는 개발자가 아니라서 망설였지만, "기획자가 한 번쯤 직접 해보면 감이 달라진다"는 말에 용기를 내서 간단한 호출을 해봤습니다.
이 글은 그 기록이에요.
코드는 최소한만 넣고, 개념과 흐름 위주로 정리하겠습니다.

대화창에서 쓸 때는 모델이 어떻게 동작하는지 상상만 할 수 있었습니다.
그런데 서비스 안에 AI를 붙이는 기획을 하려면, 입력이 어떤 모양으로 들어가고 결과가 어떤 모양으로 나오는지 알아야 해요.
이를테면 "예약 문의에 자동 답변 초안을 만들어주자"는 아이디어가 나왔을 때, 그게 어떤 데이터를 모델에 보내야 하고 얼마나 걸리고 비용은 어떻게 되는지 감이 없으면 말만 하게 됩니다.
직접 한 번 호출해보면 최소한 질문을 구체적으로 할 수 있게 돼요.

 

필요한 건 계정과 API 키입니다.
API 키는 "이 요청을 보낸 사람이 누구인지" 알려주는 비밀번호 같은 문자열이에요.
이게 새어나가면 다른 사람이 제 비용으로 모델을 쓸 수 있으니, 화면 공유나 글에 절대 노출하지 않고, 코드 파일에 직접 적지 않고 환경 변수에 넣어 쓰는 편이 안전합니다.
저는 처음에 이 부분을 가볍게 봤다가, 안내 문서를 읽고 나서야 조심하기 시작했어요.

 

호출의 핵심은 "메시지 목록"을 보내는 겁니다.
각 메시지에는 역할이 붙어요.

system은 모델에게 주는 기본 지시입니다.
"너는 미용실 예약 안내를 돕는 도우미야. 모르는 건 모른다고 답해" 같은 문장이에요.
대화 내내 유지되는 성격과 규칙을 정해두는 곳입니다.

user는 사용자가 한 말입니다.
"토요일 오후에 커트 예약할 수 있나요?" 같은 질문이죠.

assistant는 모델이 이전에 한 답변입니다.
대화를 이어갈 때 앞선 답을 이 역할로 다시 넣어주면, 모델이 앞의 흐름을 참고해서 답해요.
모델이 스스로 기억하는 게 아니라, 매번 지금까지의 대화를 같이 보내야 한다는 점이 처음엔 신기했습니다.

 

흐름은 이렇습니다.
메시지 목록을 만들고, 사용할 모델 이름과 함께 API에 요청을 보내고, 돌려받은 응답에서 답변 문장을 꺼내 씁니다.
공개 당시 안내된 모델 이름은 gpt-3.5-turbo였고, 요청의 모양은 대략 이렇게 생겼어요.

model: gpt-3.5-turbo
messages:
  - role: system, content: "너는 예약 안내 도우미야."
  - role: user, content: "토요일 오후에 커트 예약할 수 있나요?"

 

응답에는 assistant 역할의 메시지가 들어 있고, 그 안의 내용이 우리가 보게 될 답변입니다.
코드로 하면 몇 줄이면 되고, 저도 공식 안내의 예제를 거의 그대로 따라 했어요.
처음 답이 화면에 찍혔을 때는 "정말 되네" 하는 기분이 들었습니다.

여기서 중요한 한 가지.
이 모델은 제가 기획하는 예약 시스템의 실제 빈 시간을 모릅니다.
"토요일 오후에 가능해요"라고 답하더라도 그건 그럴듯한 문장일 뿐, 실제 가능 여부를 확인한 게 아니에요.
그래서 예약 가능 여부 같은 사실은 시스템에서 가져와서 모델에게 알려주거나, 아예 시스템이 답하고 모델은 문장만 다듬게 해야 한다는 걸 이 호출 하나로 선명하게 알게 됐습니다.

같은 요청을 두 번 보내보면 답이 조금씩 다르게 나온다는 것도 확인했습니다.
모델이 매번 가장 그럴듯한 단어를 확률적으로 고르기 때문이고, 이 무작위성의 정도를 조절하는 설정이 있다는 안내도 읽었어요.
예약 안내처럼 일관성이 중요한 문장은 이 값을 낮게 두는 쪽이 낫겠다는 생각이 들었습니다.
반대로 안내 문구 후보를 여러 개 뽑고 싶을 때는 어느 정도 다양성이 오히려 도움이 되겠죠.
이런 설정 하나가 서비스의 성격을 바꾸니까, 기획서에도 "이 기능의 답변은 얼마나 일정해야 하는가"를 적어야 하나 싶습니다.

 

비용은 토큰 단위로 계산됩니다.
토큰은 글자와 완전히 같지는 않지만, 대략 글을 잘게 나눈 조각이라고 생각하면 돼요.
입력으로 보낸 토큰과 출력으로 받은 토큰을 합쳐서 비용이 정해지는 구조였고, 한국어는 같은 의미라도 영어보다 토큰을 더 쓰는 경향이 있다고 알려져 있습니다.
정확한 단가는 바뀔 수 있으니 공식 가격 안내를 확인하는 게 맞아요.

감각을 잡는 방법은 간단합니다.
예를 들어 가정해볼게요.
하루에 문의가 100건 들어오고, 건당 질문과 답변을 합쳐 500토큰 정도가 쓰인다면 하루에 5만 토큰입니다.
여기에 단가를 곱해보면 한 달에 얼마가 나올지 대략 어림할 수 있어요.
그리고 대화가 길어질수록 앞선 대화를 계속 다시 보내야 해서 입력 토큰이 점점 늘어난다는 점도 놓치기 쉽습니다.

 

몇 번 호출해보고 얻은 이득은 세 가지입니다.

하나는 말투와 형식이 지시에 따라 크게 바뀐다는 걸 눈으로 확인한 것입니다.
system 문장을 한 줄 바꾸는 것만으로 답이 확 달라져서, 프롬프트가 기획 문서의 일부가 될 수 있겠다는 생각이 들었어요.

다른 하나는 모델이 알려진 사실을 늘 정확히 답하지 않는다는 걸 직접 겪은 것입니다.
기획 회의에서 "AI가 알아서 해줄 거예요"라는 말이 나오면 이제는 "무엇을 근거로, 어디까지 맡길까요"를 물을 수 있어요.

마지막은 개발자와의 대화가 쉬워진 점입니다.
"응답이 몇 초 걸려요", "대화 길이가 늘면 비용이 올라요" 같은 이야기를 전보다 편하게 알아듣게 됐습니다.

호출을 하다 보면 오류도 만납니다.
키를 잘못 넣었거나, 짧은 시간에 요청을 너무 많이 보냈거나, 서버가 바쁠 때 실패하는 경우가 있다고 해요.
저는 일부러 키를 틀리게 넣어서 어떤 응답이 오는지도 확인해봤습니다.
서비스에 붙인다면 이런 실패 상황에서 고객에게 무엇을 보여줄지도 기획의 몫이라는 점이 눈에 들어왔어요.
"잠시 후 다시 시도해주세요"로 끝낼지, 사람이 직접 안내하는 연결로 넘길지는 코드가 아니라 정책으로 정해야 합니다.

 

이번 호출은 정말 작은 실험이었습니다.
그래도 대화창 너머에 어떤 구조가 있는지 한 겹 들여다본 느낌이에요.
다음으로는 시스템 지시와 예시를 바꿔가며 응답이 어떻게 달라지는지 정리해보고 싶습니다.

예약 서비스의 FAQ를 바탕으로 답하게 하려면 모델이 모르는 내 문서를 어떻게 넘겨줘야 하는지도 궁금하고요.
그건 아마 다음 AI 학습 글의 주제가 될 것 같습니다.