개발과 일상

서버 to 서버로 데이터를 전송할 일이 생겼는데.... 문제가 생겼다. 문제 상황은 다음과 같다. 1. A 서버에서 B서버로 요청을 보낼 계획2. A 서버는 S3에서 파일정보를 가져와서 ByteArray 형태로 들고 있음3. B 서버에는 MultipartFile을 파라미터로 받는 API(ex. /api/file)가 존재함 - 수정 불가(FE에서 사용 중)  4. A 서버에서 B 서버로 /api/file을 요청해야 함 - 데이터만 삽입하고 끝내기엔 이력이나 업데이트해야할 정보가 많음5. A 서버에서는 FeginClient를 사용 중(HTTP 통신을 위해서 사용 중, 굳이 고집하지 않아도 됨) 요약하면, 요청을 보내기 위해서 스프링부트 서버에서 MultipartFile을 어떻게 만들 것인가? 와  Feign..

서비스의 규모가 커짐에 따라 수정 사항도 늘어나고, 서로 간의 의존성도 커지면서 다른 한쪽의 문제를 예상하지 못하고 수정해버려서 발생하는 이슈가 늘어났다. 그래서 개발을 할 때나 수정할 때 점점 부담이 많이 생기게 되서, 제대로된 테스트의 도입 방식을 검토했다. 이전에 강의를 하나보고 여기에 감명을 받았다. 2024.04.15 - [일상] - [인프런 강의] Java/Spring 테스트를 추가하고 싶은 개발자들의 오답노트를 듣고위 그래프처럼 개발 양은 많아지는데, 이게 잘 동작할까? 에 대한 부담감이 점점 커지는 상황이라 조치가 필요해졌다. 그러나 테스트 도입에는 정말 많은 애로 사항들이 있었는데... 다음과 같은 의사결정이 필요했다. 1. 테스트의 종류 선정: 몇 종류의 테스트를 실행할 것인가?2. 어..

갑작스럽게 떨어진 오더(C레벨에서부터 내려온)로 인해 월드 ID를 이용한 인증 시스템 개발 업무가 추가됐다. 왜 이런 오더가 떨어졌냐를 생각하기전에 월드 ID가 뭐인지부터 알아보자. 월드 ID란? World ID는 영지식 증명과 고급 개인 정보 보호 암호화를 통해 사용자가 익명으로 자신의 고유성과 인간성을 증명할 수 있는 디지털 신원 솔루션입니다. World ID는 클라우드 및 온체인 앱 모두에 쉽게 통합할 수 있습니다. 유효한 월드 ID를 가진 사용자는 월드 앱과 같은 월드 ID 호환 지갑을 통해 익명으로 자신이 고유한 인간임을 몇 초 만에 확인할 수 있습니다. https://docs.worldcoin.org/world-id 굳이 인증 과정을 기존 방식이 아닌 다른 컨셉으로 해야하나?란 생각이 들지만 ..

온라인에서 문서를 PDF로 변환하는 프로젝트를 진행 중이다. 가장 큰 걸림돌이라 예상됐던, PDF 변환 솔루션은 다행히도 잘 동작하고 있다. (몇몇 확장자는 지원한다더니 안되지만 말이다) 문제는 사용자에게 파일 크기가 큰 파일을 어떻게 사용자에게 전달할 것인가? 였다. 가장 먼저 떠오르는 방식은 Base64나 ByteArray로 변환하고 FE에서 파일로 변환하는 거였지만, 사용자가 요청하는 파일 크기가 커진다면 응답의 크기가 얼마나 커질지 알 수가 없다. 이런저런 방법을 알아보다가 퍼블릭한 S3를 만들어서 S3 경로를 던져주고 PDF 뷰어는 브라우저에게 맡기는게 가장 손이 덜 가는 방법이라는 결론을 짓게 됐다. 퍼블릭한 S3 버킷를 만드는건 어렵지 않을거라 생각했다. 왜냐면 생성할 때 주는 옵션이 있기 ..

번역 API에 대한 기술 검토 중에 문서 번역에 대한 요청을 받게 됐다. 이런 저런 방법에 대한 고민을 해보다가 직접하는 것보단 통합으로 제공하는 곳이 없을까 찾아봤다. 그리고, GCP에서 제공하는 Document Translation API를 알게 됐다. Document Translation API는 Cloud Translation API 일부인데, 말 그대로 구글에서 제공하는 번역 API 에서 제공하는 세부 기능 중 하나다. API를 자유롭게 사용할 수 있으면 좋겠지만, 유료 결제를 등록한 계정만 사용할 수 있다. 카드 등록도 해야 쓸 수 있다. 일단은 무료 크레딧으로 사용해보기로 하고, 하나씩 시작해보자. 1. 서비스 계정 만들고 키 발급 받기 처음 시작은 indexing API와 크게 다르지않다...

작년 입사 후 얼마 지나지 않아서 로그 파이프라인을 구성했었다. 2023.05.28 - [개발/SPRING] - 스프링부트 서비스에 LOG 남기기 (with. Logback) 당시에는 요청에 대한 로그가 없어서 급하게 구축하게 됐는데, 지금 생각해보면 입사한지 한달도 되지 않은 개발자가 로그 파이프라인을 구성한다는 자체가 말이 좀 안되는 일이긴했다. 그래서 로그 파이프라인에 구멍이 조금씩 있었는데, 최근에 가장 큰 구멍을 알게되서 개선이 필요했다. 바로 Multipart/form-data 형식에서 MultipartFile에 대한 처리가 없어서, 어떤 파일이 업로드가 되었는지 알 수 없었다. 그런데, 현재 담당하고 있는 서비스가 파일 업로드를 지원하기 때문에 로그의 개선을 필요로 했다. 로그를 몇 번 개선..

이전 글에서 SEO 노출도를 올리기 위한 indexing API 작업을 했다. 그런데 문제가 있는게 indexing API는 하루에 200회의 제한이 있다. https://developers.google.com/search/apis/indexing-api/v3/quota-pricing?hl=ko 제한 횟수를 늘려달라고 요청할 수 있는데, 구글 친구들은 늘 그렇듯이 언제 해줄 수 있다고 알려주지 않는다. 그렇다고 한 개씩 등록하면(요청하면) HTTP 연결풀을 순간적으로 많이 잡아먹으니까 한번에 보낼 수 있는 방법을 만들어 뒀다. 일괄 색인 생성 요청 보내기라는 섹션을 만들어 둘 정도로 써달라고 만들어뒀는데... 이게 일단 예시를 바로 가져다 쓸 수 있게 생기질 않았다. https://googleapis.g..

나는 구글 API에 대해 좋은 기억이 별로 없다. 예~전에 스프레드시트와 워드에 자동 저장하기 위해 사용했을 때도, 정말 힘들었던 기억이 있다. 왜냐하면 최신화를 안해놓기도 했고, 빠른 버전업의 영향인지 정리해 놓은 곳 마다 사용법이 다 다르기 때문이다. 인간적으로 공식 가이드 문서는 엔드투엔드로 잘 써줘야하지 않나 싶다. GPT도 영 시원찮아서, 블로그랑 스택오버플로우 이곳 저곳 뒤적이면서 어떻게 사용할 수 있게 만들어 두긴 했다. 일단 Google Indexing API를 사용하게 된 취지는 명확하다. 현재 개발하고 있는 서비스가 대부분 SEO로 active user를 충당하고 있다. 생성된 게시물을 sitemap으로 관리하고 있는데, 구글 서치 콘솔에서 확인해보면 아직 색인되지 않은 페이지가 너무 ..