이전에 GPT 웹사이트에서 Assistants(챗봇)를 구축하는 방식에 대해 알아봤었다. 이게... 당시에는 API가 없다고 했는데, Beta로 나와 있었다. (API reference는 주기적으로 열어보는데, Document와 Beta에 있어서 못찾았다) 근데... 이게 뭐가 하고싶은지는 알겠는데 구조가 조금 복잡하다. 각각의 구성요소에 대해서는 나중에 소개하겠지만, 일단 OpenAI 쪽에서 하고 싶은건 Thread라는 저장소를 사용자별로 만들어 주고 싶었던 것 같다. 그래서 그런지 Assistant 밑에 Thread들이 있지 않다. 구조가 그림만봐도 어려운데, 일단은 세부요소 소개와 구현을 해볼 생각이다. Assistants API란? 어시스턴트 API를 사용하면 자체 애플리케이션 내에서 AI 어시스..
키나 환경변수를 관리하는 툴은 정말 많다. AWS에서 자체적으로 제공하는 경우도 있고, GitHub에서 심어줄 수도 있고 다양한 방법이 있다. 가장 최악의 경우는 Application.yaml 파일에 실수로 그냥 실어버리고 GitHub에 배포하는 경우다. (OpenAI의 경우, 이 부분을 어떻게 캐치해서 강제로 키를 새로 발급해버린다.) 개인적으로 이것저것 써봤을 때, 가장 맘에 들었던게 DotEnv다. 간단하게 사용법을 안내하자면, src아래에 .env 파일에 키를 저장해놓고, 쓰면 되고 .gitignore에 등록해놓고 쓰면 된다. 파일을 만들어놓고 gitignore에 설정해놓으면, 다시 볼일이 없어서 관리하기 편했기 때문에 사용하기 편했다. 이제 설정하는 법을 알아보자. build.gradle.kts..
들어가기 앞서 아직 이 기능은 GPT 홈페이지에서는 제공하지 않는다. 아직은 API로만 사용 가능한 것으로 확인된다.(GPT-Turbo를 개발자에게 우선 제공한다고 하긴 했다) 11월 6일부터 GPT-4 Turbo를 사용할 수 있게 되었다. 가장 눈에 띄는건 토큰 수가 12만 8천개 까지 증가했다는 것이다. 11월 6일 샘 알트먼의 발표에 따르면, 토큰 활용 개수를 증가시키고 가격도 인하했다고 한다. 또한, 23년 4월까지 학습시킨 데이터를 기반으로 응답을 주기 때문에 기존 22년 1월까지의 데이터에 비해 비교적 최신 데이터로 갱신 되었다고 한다. 그리고 몇 가지 기능이 추가 되었는데, 그 중 하나가 모델들을 살펴보면, gpt-4-vision-preview가 추가 되었는데 이 모델을 통해 이미지 인..
서비스 기획 중 하나가 카카오톡을 기반으로 서비스 예정이라, 이에 관한 마케팅을 진행한다고 한다. 그런데 현재 서비스가 카카오 로그인을 지원하지 않고 있었다. (사용자의 유입을 늘려야하는데!) 바로 구현에 들어가기로 했고, 카카오 Rest API 문서를 보면 Oauth 2.0 기반으로 회원가입/로그인을 지원한다고 한다. 그리고 아래와 같은 스퀀스 다이어그램을 하나 제공하는데... 이게 좀 문제가 있는게 SSR(서버 사이드 랜더링)을 위한 구조도이다. 그래서 CSR에서는 적합하지가 않다. 왜냐면 로그인 요청을 받은 서버에서 해당 사용자의 회원가입 여부를 확인해야하기 때문이다. 그리고 callback 페이지의 redirection도 해야하는데 서버에서는 적절하게 이를 제어할 수 없다. 때문에 FE 서버에서 ..
현재 개발 중인 서비스에서 본인 인증 기능이 필요해졌다. 한번쯤 써봤을 PASS 본인인증 같은 기능이다. 내가 인증 대상이 될 때는 몰랐는데, 본인 인증 기능을 개발하려니 업체 선정에서부터 어려운 점이 생겼다. 결국은 요금이 가장 큰 걸림돌되었고,(현재 서비스는 사용량이 썩 많지 않다.) 우선 대표적인 국내 업체 두 곳을 비교했다. 구글링을 하면 가장 먼저 나오는 곳은 PASS와 드림시큐리티였다. 하지만 두 업체는 가장 먼저 후보군에서 제외 됐다. 두 곳 모두, 기본료가 청구된다는 것이다. 서비스 이용자가 많지 않아서 기본료가 청구되는 상황은 배보다 배꼽이 크다 판단했다. 또 SDK에 대한 정보가 하나도 없어서 구현 난이도나 주고 받는 정보가 우리 서비스에 맞을지 가늠이 잘 안됐다. (인증 UI까지 제공..
이번 주에 발생했던 따끈따끈한 문제 문제 상황은 이렇다. 1. 비로그인 사용자를 구분하기 위한 id를 부여하고 싶다. 2. id를 어디서 부여하고 저장할까? - 보안상의 이유로 단순 로컬스토리지보다는 쿠키에 저장하는 게 좋을 것 같다. 3. 누가 쿠키를 발행할 것인가? fe가 가능할 것 같다고해서 별 생각 없이 ok 4. fe 서버에서 쿠키에 강제로 domain을 부여하니까 localhost에서 쿠키를 사용할 수 없는 문제 발생 5. 결국 서버에서 쿠키를 만들기로 하는데.... 결론부터 이야기하자면 모두가 쿠키에 대한 제대로된 지식이 없어서 발생한 문제였다. 정확히는 Thirdparty cookie와 cookie의 도메인에 대한 지식이 부족했다. 어떤 문제가 발생했는지 차근 차근 밟아나가보자. 이슈 1...
이전 글에선 JWT 검증 코드를 인터셉터에 적용해봤다. 이번 글에선 Filter에 적용해보자. 먼저 가볍게 Filter에 대해 짚고 넘어가보자. Filter는 Interceptor와 다르게 Dispatcher Servlet이 동작하기 이전에 위치한다. 그리고 별도의 필터에 대한 설정이 없으면 모든 요청에 대해서 반드시 한번 실행이 된다. 때문에 인터셉터보다는 더 범용적이고, 한번은 무조건 타야하는 보안, 인증/인가 작업이 주로 Filter에서 이뤄지게 된다. 흔히 알고 있는 스프링 시큐리티의 필터 체인들이 여기서 수행된다. Filter는 별도의 설정없이 Filter 인터페이스만 implements해도 요청이 들어올 때마다 실행되기 때문에 구현은 비교적 간단하다. 구현 여기서부터 등장할 jwt 관련 코드는..
이전 글에서 JWT가 무엇이고 어떤 데이터를 실어서 보낼 수 있나를 알아봤다. 그럼 이번 글부터는 어떻게 적용하면 될지 알아보자. 이번 글에서 소개할 방식은 interceptor에 적용하는 방식이다. interceptor는 스프링에서 제공하는 컨트롤러 이전에 위치하는 공통처리부 중 하나이다. 아래 그림을 확인하면 편하다. 공통처리부에 관한 글을 예전에 썼었는데, 이 때는 스프링 MVC를 쓰던 시절이라 필터와 인터셉터를 xml에서 제어를 하도록 구성되어 있었다. (왜 썼는지, 어떤 역할을 하는지 보다 이런게 있다라고 정리한 글이었다) 여기서 추가적으로 간단하게 짚고 넘어가면, Interceptor는 스프링 내부에서 Dispatcher Servlet 이후에 동작한다. 컨트롤러 앞단에 위치해 요청과 응답을 간..
- Total
- Today
- Yesterday
- lambda
- awskrug
- Kotlin
- Elastic cloud
- EKS
- S3
- GIT
- 코딩테스트
- JWT
- java
- springboot
- Spring
- jenkins
- MySQL
- AWS EC2
- chat GPT
- elasticsearch
- cache
- CloudFront
- terraform
- AWS
- ChatGPT
- docker
- openAI API
- AOP
- serverless
- Log
- 람다
- 스프링부트
- OpenAI
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 | 31 |