개발과 일상

상태 검사(health check)란? 상태 확인(상태 검사)은 특정 서버의 서비스에 작업을 성공적으로 수행할 수 있는지 여부를 물어보는 방식입니다. 로드 밸런서는 각 서버에 이 질문을 정기적으로 물어보며 트래픽을 라우팅하는 데 안전한 서버를 확인합니다. 대기열에서 메시지를 폴링하는 서비스는 대기열에서 더 많은 작업을 폴링하도록 결정하기 전에 정상 상태인지를 물어볼 수 있습니다. 외부 모니터링 플릿이나 각 서버에서 실행되는 모니터링 에이전트는 경보를 알리거나 장애가 발생한 서버를 자동으로 처리할 수 있도록 정상 상태인지 여부를 서버에 물어볼 수 있습니다. https://aws.amazon.com/ko/builders-library/implementing-health-checks/ 쿠버네티스를 사용하거나 ..

이번 프로젝트를 진행하면서, 스프링 시큐리티를 도입하기로 했다. 현재 서비스는 그래도 제법 덩치가 있어서 바로 도입이 어렵기 때문에, 작은 서비스에 먼저 적용해보자는 취지였다. 결론부터 이야기하면, 현재 서비스 구조는 스프링 시큐리티에 필요한 데이터 구조를 가지고 있지 않았다. 이 과정에서 겪은 일들과 필터체인에 JWT를 엮는 일까지가 이번 포스팅이 될 것 같다. 우선 스프링 시큐리티가 뭔지부터 정리해보자. 스프링 시큐리티란? 스프링 시큐리티 공식 사이트에선 아래와 같이 스프링 시큐리티를 소개하고 있다. Spring Security는 강력하고 사용자 정의가 가능한 인증 및 액세스 제어 프레임워크입니다. 이는 Spring 기반 애플리케이션 보안을 위한 사실상의 표준입니다. Spring Security는 J..

이전에 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...