요청은 헤더와 바디로 나뉜다
인증은 Authorization 헤더가 맡고, 내용은 바디의 모델명·메시지·파라미터가 정한다.
호출 대상은 OpenAI 규격의 chat/completions 엔드포인트다. 요청에서 가장 중요한 것은 Authorization 헤더에 인증 토큰을 넣는 일이다. 보통 Authorization: Bearer <토큰> 형식이다. 이 헤더가 빠지면 요청이 처리되지 않는다. 바디에는 모델명, 메시지 배열, 각종 파라미터를 담아 보낸다.
모델명만 바꾸면 같은 코드로 다른 모델을 호출할 수 있다. 응답에는 모델 정보, 메시지 내용, 종료 사유(finish_reason), 토큰 사용량(usage)이 들어온다. finish_reason이 stop이면 모델이 스스로 생성을 마친 것이고, length면 Max Token 제한으로 잘린 것이다. usage는 비용을 계산하는 근거가 된다.
- Authorization 헤더
- 인증 토큰을 담는 위치다. 요청의 첫 관문이며 여기가 틀리면 나머지는 의미가 없다.
- 요청 바디
- 모델명, 메시지 배열, 파라미터를 담는다. 호출 내용을 결정하는 부분이다.
- finish_reason
- 생성이 끝난 이유다. stop은 정상 완료, length는 토큰 제한으로 인한 잘림이다.
- usage
- 토큰 사용량이다. 비용 계산과 대화 길이 관리의 기준이 된다.
키는 브라우저가 아니라 Edge Function의 환경변수에 두고, 응답의 usage로 비용을 확인한다.
기억은 모델이 아니라 배열에 있다
System은 규칙, User는 질문, Assistant는 지난 답이다. 셋을 쌓아야 문맥이 생긴다.
메시지는 역할(Role)로 구분한다. System은 정체성·규칙·제약을 정의하며, 말투나 동작을 강하게 제어하려면 이 레벨에 설계를 둔다. User는 질문이고 Assistant는 AI의 응답이다.
LLM API는 Stateless라서 이전 턴을 기억하지 않는다. 그래서 대화를 이어가려면 이전 메시지 배열을 모두 누적해 다시 보내되, Assistant의 응답도 반드시 포함해야 문맥이 유지된다. 대화가 길어지면 프롬프트 토큰이 계속 늘어나므로 최근 몇 개만 보내거나 압축하는 관리가 필요하다. 또한 API가 상태를 저장하지 않으므로 대화 기록은 별도 DB에 저장해야 한다.
- System
- 모델의 정체성·규칙·제약을 정의하는 역할이다. 말투와 동작 제어의 핵심이다.
- User
- 사용자가 입력한 질문이다. 매 턴 배열에 추가된다.
- Assistant
- AI가 생성한 응답이다. 누적 배열에 포함해야 문맥이 이어진다.
- Stateless와 누적
- API가 상태를 기억하지 않아 이전 메시지를 매번 다시 보내는 구조다.
- 대화 기록 저장
- Stateless API에서는 대화 기록을 별도 DB에 저장하는 것이 필수다. 저장된 기록이 다음 요청의 메시지 배열이 된다.
| 역할 | 내용 | 포인트 |
|---|---|---|
| System | 정체성·규칙·제약 | 말투·동작 제어의 핵심 |
| User | 사용자 질문 | 매 턴 추가된다 |
| Assistant | AI 응답 | 누적에 반드시 포함한다 |
무작위성과 길이를 조절한다
Temperature와 Top_p는 확률 분포를, Max Tokens는 출력 길이를 통제한다.
두 파라미터 모두 다음 토큰을 고르는 확률 분포를 바꾼다. Temperature가 0에 가까우면 확률이 가장 높은 토큰만 선택해 결과가 일관적이고, 높이면 예측 불가능한 답변이 나온다. Top_p는 누적 확률이 특정 값(p)에 도달할 때까지의 상위 후보군 안에서 샘플링한다.
Max Tokens는 출력 토큰의 상한선이다. 비용과 생성 시간을 통제하지만, 너무 낮게 설정하면 답변이 중간에 잘린다. 잘림을 막으려면 Max Tokens를 적절히 조절하거나 시스템 프롬프트로 길이를 지시한다.
- Temperature
- 확률 분포의 무작위성을 조절한다. 0에 가까울수록 일관적이고 높을수록 예측 불가능하다.
- Top_p
- 누적 확률 p까지의 상위 후보군에서 샘플링한다. 후보 범위를 제한한다.
- Max Tokens(max_tokens)
- 출력 토큰의 상한이다. 비용과 시간을 줄이지만 낮으면 답이 잘린다.
Temperature
- 0에 가까우면 일관적
- 높으면 예측 불가능
- 확률값 자체를 조정
Top_p
- 누적 확률 p까지 후보 유지
- 후보군 범위를 자름
- 샘플링 대상이 달라짐
둘 다 다음 토큰의 확률 분포를 조절해 답의 일관성과 다양성을 바꾼다.
프롬프트는 코드처럼 관리한다
역할·규칙·제약·형식을 시스템 프롬프트에 고정하면 출력이 안정된다.
시스템 프롬프트에는 역할(Role), 규칙(Rule), 제약(Constraint), 형식(Format)을 명확히 적는다. 이 네 가지가 흔들리면 같은 서비스에서도 답이 달라지므로, 프롬프트는 코드처럼 관리해야 하는 핵심 영역이다. 구분자를 쓰면 지시 사항과 사용자 데이터를 분리할 수 있다. 이 분리가 프롬프트 인젝션 방어의 기본이 된다.
예시 제공(Few-shot)은 원하는 입출력 예시를 보여주는 기법이고, 복잡한 작업은 단계별로 검토한 뒤 결론을 내라고 지시한다. 프롬프트 인젝션은 사용자 입력이 시스템 프롬프트를 압도해 의도치 않은 동작을 하게 만드는 현상이다. 비밀번호나 토큰이 유출될 수 있다.
- 역할·규칙·제약·형식
- 시스템 프롬프트에 명시할 네 요소다. 모델의 일관된 성능을 확보한다.
- 구분자
- 지시 사항과 데이터를 분리하는 표시다. 프롬프트 인젝션 방어에 쓰인다.
- Few-shot
- 원하는 입출력 예시를 함께 보여주는 기법이다. 정확도를 높인다.
- 단계별 추론 유도
- 복잡한 작업을 단계별로 검토한 뒤 결론을 내도록 지시하는 기법이다.
- 프롬프트 인젝션
- 사용자 입력이 시스템 프롬프트를 압도해 의도치 않은 동작을 유발하는 공격이다.
브라우저에서만 실패하면 CORS를 본다
Supabase Edge Function은 Deno에서 돌고, CORS·JWT·환경변수·재시도가 안정성을 만든다.
Supabase Edge Function은 Deno 런타임에서 동작한다. API 키처럼 노출되면 안 되는 값은 함수 안의 환경변수에 둔다. 브라우저는 본 요청 전에 OPTIONS 메서드로 사전 요청을 보내고, 서버가 CORS 허용 헤더로 응답하지 않으면 요청을 막는다. 브라우저에서만 에러가 난다면 CORS 설정을 가장 먼저 확인한다.
JWT를 통해 권한이 있는 요청만 처리하도록 설계한다. 인증 없이 함수가 열려 있으면 누구나 모델을 호출해 비용을 발생시킬 수 있다. 외부 API는 실패할 수 있다는 전제로 설계해야 한다. 재시도 간격을 지수적으로 늘려가는 지수 백오프(Exponential Backoff)를 적용하면 일시적 장애를 견딘다.
- Deno 런타임
- Supabase Edge Function이 실행되는 환경이다. 서버리스로 동작한다.
- CORS와 OPTIONS
- 브라우저의 사전 요청에 허용 헤더로 응답해야 본 요청이 진행된다.
- JWT
- 권한이 있는 요청만 처리하도록 인증하는 수단이다.
- 환경변수
- API 키를 코드 밖에 두어 유출을 막는다. 클라이언트 코드에 두면 안 된다.
- 지수 백오프
- 재시도 간격을 지수적으로 늘리는 전략이다. 외부 API 실패에 대비한다.
시험 직전 체크
EXAM POINTS- 요청은 Authorization 헤더에 인증 토큰을 넣고, 바디에 모델명·메시지 배열·파라미터를 담는다.
- 응답의 finish_reason은 stop이면 정상 완료, length면 Max Token으로 잘린 것이고 usage는 토큰 사용량이다.
- System은 규칙, User는 질문, Assistant는 응답이며, Stateless이므로 Assistant까지 누적해 보내고 기록은 DB에 저장한다.
- Temperature와 Top_p는 확률 분포를, Max Tokens는 출력 길이를 조절한다.
- 시스템 프롬프트의 역할·규칙·제약·형식, 구분자·Few-shot·단계별 추론, 프롬프트 인젝션을 함께 설명한다.
- Edge Function은 Deno에서 돌며 CORS·JWT·환경변수·지수 백오프로 안정성과 보안을 확보한다.
헷갈리는 것만
COMMON TRAPS아니다. 누적 배열에 Assistant 응답을 포함해야 문맥이 유지된다.
아니다. 모델이 스스로 생성을 마쳤다는 뜻이다. length는 토큰 제한으로 잘린 경우다.
아니다. 무작위성이 커져 답이 덜 일관적이 된다. 0에 가까울수록 일관적이다.
아니다. OPTIONS 사전 요청에 허용 헤더로 응답하지 않아 생기는 통신 설정 문제다.
반대다. 저장하지 않으므로 개발자가 DB에 저장하고 매 요청에 다시 담아야 한다.
KEYWORDS
- Chat Completion
- Authorization
- finish_reason
- Stateless
- Temperature
- Top_p
- Max Tokens
- 프롬프트 인젝션
- CORS
- 지수 백오프
연결해서 기억하기
- 1주차의 Stateless·컨텍스트 윈도우가 2주차 메시지 누적과 토큰 관리의 근거다.
- 1주차의 시스템 프롬프트 개념이 2주차에서 역할·규칙·제약·형식으로 구체화된다.
- 1주차의 Edge Function이 2주차에서 CORS·JWT·환경변수 구현으로 이어진다.