개발과 일상

티스토리를 시작하기 전, 23년 목표를 세웠었다. 어느정도까지 이뤘는지 정리해보고 후기를 정리해보려고 한다. 23년 목표 몸무게 65kg & 체지방 15% -> 감량이 불가능하면 체지방만 고려 블로그 꾸준히 해서 글 100개 이상 쓰기 & 에드 센스 출금 할 정도로 키워보기 코딩 테스트 문제 일주일에 세 문제 이상 풀기 GO 언어로 백엔드 구현 해보기 MSA / k8s / redis / elk stack 익히기 피부 관리하는법 배우기 클라이밍 배우기 한 달에 책 한권 읽기 해외 여행 가기(일본 default) 솔로 탈출(...) 이직 - 매달 세 곳 이상 지원하기 23년 목표 결산 1. 몸무게 65kg & 체지방 15% 실패 지금 생각해보니 생각보다 사실상 불가능한 목표였다. 23년 목표를 세울 때 당시..

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

이전 프로젝트는 현재 담당하고 있는 것 보다 규모가 훨씬 커서 테이블의 종류가 많았다. 그래서 다양한 테이블에 insert하는 매서드의 경우 중간에 오류가 발생하는 경우를 대비해 별도의 Exception을 정의하고 데이터 무결성을 위해서 rollback 처리를 반드시 해줬어야 했다. 그런데 현재 프로젝트로 넘어와서 코드를 확인해보니, @Transational 어노테이션만 붙이고, rollback은 따로 처리하지 않고 있었다. 지금 생각해보면 이유라기보다는 개발자의 미숙에 가까운게, 해당 프로젝트는 단 하나의 CustomException이 없었다. Checked Exception이 없기 때문에 굳이 rollbackfor를 정의할 필요가 없다는 생각이었을까? 정말 안전할지 알아보자. Transcational..

문제 상황은 다음과 같다. 단건 저장 위해서 아래와 같은 요청 객체를 만들었다. data class QuizRequestDto( val question: String, val answer: String, val hint: String? val order: Int, val visible: String ) 그리고 정상적으로 동작하는 것을 확인하고, Bulk 수행을 위해서 다음과 같은 요청 객체를 만들었다. data class QuizListRequestDto( val quizList: List ) 테스트 요청을 날려보니 아래와 같은 에러를 뱉는다. 11:36:51.103 [http-nio-8080-exec-4] ERROR o.a.c.c.C.[.[.[.[dispatcherServlet] - Servlet.se..

이전 글에는 문제가 있다. 현재 DDB Table에는 이미 3천개 이상의 데이터가 쌓여있고, 앞으로 꾸준히 데이터가 쌓일 예정이다. 그런데 조회 쿼리 ScanCommand를 사용했다. 이 조회 방식은 언젠가 문제를 일으킬 것이다. 어떤 문제인지는, AWS의 DDB 스캔 사용 모범사례를 보면 알 수 있다. 일반적으로 Scan 작업은 DynamoDB의 다른 작업보다 비효율적입니다. Scan 작업은 항상 전체 테이블이나 보조 인덱스를 스캔합니다. 그런 후 값을 필터링하여 원하는 결과를 얻기 때문에 결과 세트에서 데이터를 제거해야 하는 단계가 추가됩니다. 가능한 경우, 대용량 테이블 또는 인덱스에서 필터를 사용해 다수의 결과를 제거해야 하는 경우에는 Scan 작업을 최대한 피하는 것이 좋습니다. 여기에 테이블이..

상용 배포를 앞두고, dev 서버에서 잘 동작하던 Lambda에서 문제가 발생했다. Dynamo DB(이하 DDB) 조회해서 데이터의 존재여부를 검증하는데, 분명 조회 데이터가 존재하는데도 Count가 계속 0으로 찍히는 문제였다. dev에선 분명히 잘 동작했고 prod에서도 에러가 나지 않았기 때문에, 오류를 찾기가 너무 힘들었다. 커넥션이 올바르게 되고 있는지부터 쿼리가 올바른지, 로직에 문제가 없는지 다 검증해봤는데, 의외의 곳에서 실마리를 얻었다. prd DDB에 저장된 데이터는 3000개 이상이었는데, 위 조회 방법으로 조회하니 ScannedCount가 709개로 나왔다. 여기서부터 문제가 있음을 인지하게 되었다. 조회 쿼리를 날렸을 때 결과물이 아래와 같이 나왔다. { '$metadata': ..

이전 글에서 Open AI의 Assistant API를 사용해봤다. 이전 글에서의 사용법대로 차례대로 포스트맨 요청으로 사용하면 타이밍만 잘 맞추면, 큰 문제가 발생하지 않는다.(그래도 간간히 빈 문자열이 날아오는 경우가 생긴다.) 만약 실사용하게 된다면 아래와 같이 구성되게 될 것이다.// 쓰레드 생성val threads = assistantsClient.createThreads()// 메시지 생성assistantsClient.createMessages(threads.id, MessagesRequestDto("user", "PREP이 뭐야"))// run 생성val run = assistantsClient.createRuns(threads.id, RunsRequestDto(assistantId))// ..

이전에 GPT 웹사이트에서 Assistants(챗봇)를 구축하는 방식에 대해 알아봤었다. 이게... 당시에는 API가 없다고 했는데, Beta로 나와 있었다. (API reference는 주기적으로 열어보는데, Document와 Beta에 있어서 못찾았다) 근데... 이게 뭐가 하고싶은지는 알겠는데 구조가 조금 복잡하다. 각각의 구성요소에 대해서는 나중에 소개하겠지만, 일단 OpenAI 쪽에서 하고 싶은건 Thread라는 저장소를 사용자별로 만들어 주고 싶었던 것 같다. 그래서 그런지 Assistant 밑에 Thread들이 있지 않다. 구조가 그림만봐도 어려운데, 일단은 세부요소 소개와 구현을 해볼 생각이다. Assistants API란? 어시스턴트 API를 사용하면 자체 애플리케이션 내에서 AI 어시스..