본문 바로가기

전체 글

 (391)
REST API 가 뭘까? 들어가기 전면접을 준비하면서 REST API가 무엇인지 이론적으로 수없이 접하고 글로 정리해 보기도 했습니다. 당시에는 단순히 '형식을 맞추는 것'이라 생각했지만, 실제 프로젝트를 진행하며 수백 개의 기술 포스팅을 남기다 보니 깨달은 점이 있습니다. 결국 REST API는 단순한 규칙을 넘어, '누가 봐도 이해하기 쉽고 관리하기 쉬운 코드'를 만들기 위한 개발자 사이의 가장 강력한 약속이라는 점입니다. 그래서 오늘은 모든 데이터 통신의 뿌리가 되는 API의 기본 개념부터 시작해, REST API의 철학까지 하나씩 짚어보며 정리해 보려 합니다. 그래서 API 가 뭔데 ?API는 서로 다른 운영체제나 언어로 작성된 프로그램들이 데이터를 주고받을 수 있도록 표준화된 엔드포인트(Endpoint)를 제공합니다. ..
지오해시(GeoHash)란? 지오해시(GeoHash)지오해시는 위도(Latitude)와 경도(Longitude)라는 2차원의 좌표 데이터를 1차원의 문자열(또는 숫자)로 변환하는 기술입니다.전 세계 지도를 격자(Grid)로 나눕니다. 그리고 그 격자에 고유한 이름을 붙이는 방식입니다. 특징문자열의 길이가 길수록 더 좁은 범위를 나타냅니다(더 정밀함).앞부분이 같은 문자열로 시작하면, 지리적으로 서로 가까운 위치에 있을 확률이 높습니다.DB 인덱스 스캔에 최적화된 이유입니다.🤔 그렇다면 지오해시는 어떻게 만들어질까요?지오해시는 Z-Order Curve(Morton Order) 알고리즘을 기반으로 합니다. 과정을 설명하면 다음과 같습니다. 1. 범위 나누기 경도(-180° ~ 180°)를 절반으로 나눕니다. 위치가 왼쪽(-180° ~..
[DB] 인덱스 느린 검색의 원인 - 풀 테이블 스캔 (Full Table Scan)인덱스가 없는 테이블에서 특정 데이터를 찾는 과정은, 비유하자면 100만 페이지짜리 거대한 책에서 특정 단어 하나를 찾기 위해, 책의 첫 페이지부터 마지막 페이지까지 한 장 한 장 넘겨보는 것과 같습니다. 예를 들어, 인프런의 데이터베이스에는 '강의 목록 ' 컬럼이 존재하고 이 컬럼에 '김영한의 실전 데이터베이스 강의 ' 이라는 값이 어디에 있는지 알 수 있는 아무런 힌트가 없습니다. 그래서 데이터베이스는 가장 무식하고 정직한 방법을 선택한다고 합니다. 그것은 바로 테이블 전체를 디스크에서 메모리로 읽어들인 후, 첫 번째 행부터 마지막 100만 번째 행까지 하나씩 차례대로 '강의 목록 ' 컬럼의 값을 비교하는 것 입니다. 이러한 작업..
[프로젝트 이슈] API 호출량 제한 들어가기 전이번 프로젝트에서는 사용자의 위치를 기반으로 주변 스터디룸을 탐색하는 기능을 제공했습니다. 처음에는 사용자가 조회할 때마다 외부 API를 호출하여 실시간 데이터를 가져오는 방식으로 구현했지만, 곧 예상되는 문제가 존재했습니다. 사용자가 늘어날수록 API 호출 횟수가 기하급수적으로 증가하면서 비용이 커질 것이고, 특히 카카오 API의 호출 제한 때문에 안정적으로 데이터를 가져오기 어려운 상황도 발생할 수 있다고 생각했습니다. 이를 해결하기 위해 지난 번 지오해시(GeoHash)를 활용한 캐싱 전략을 도입했었습니다. 각 스터디룸 데이터에 지오해시 값을 포함해 저장하고, 사용자가 특정 위치를 조회할 때는 해당 지점이 속한 격자와 인근 8개 격자를 함께 조회하도록 설계했습니다. 이후, 매번 외부 AP..
[프로젝트 이슈] 지오해시 기반 위치 검색 최적화 들어가기 전스터디 매칭 서비스를 만들면서 가장 먼저 부딪힌 문제는 데이터 확보였습니다. 오프라인 스터디를 매칭한 사용자들이 스터디룸이나 카페를 선택할 수 있으려면, 위치 기반으로 주변 공간을 조회할 수 있어야 하는 요구사항이 있었습니다. 이를 위해 카카오 로컬 API를 활용하기로 했습니다. 카카오 로컬 API는 장소 데이터를 제공하지만, 실제 서비스에서 사용하려 하니 몇 가지 제약이 있었습니다. 대표적으로 API 호출 제한(쿼터) 문제였습니다. 특히 카카오 로컬 API는 일간/월간 호출 제한이 존재하여 외부 API는 무제한으로 호출할 수 없었습니다. 🚨 카카오 API 제약사항앱 단위로 월 300만 건 무료 호출 제공API별로 일간/월간 제한이 있으며, 초과 시 HTTP 429 에러 발생처음 구현에서는..
[프로젝트 이슈] 무중단 배포 자동화 들어가기 전지난번 배포 과정에서는 GitHub Actions와 CodeDeploy를 활용해 빌드와 서버 배포를 대부분 자동화했기 때문에, 사람이 직접 파일을 복사하고 서버를 재시작하며 발생할 수 있는 오류는 크게 줄일 수 있었습니다. 또한 배포 실패 시 CodeDeploy의 롤백 기능을 통해 이전 버전으로 빠르게 되돌릴 수 있어, 서비스가 완전히 중단되는 상황은 최소화할 수 있었습니다. 하지만 단일 EC2 인스턴스 환경에서는 배포 중 잠시 서비스가 끊길 가능성을 완전히 제거할 수 없었고, 진정한 의미의 무중단 배포까지 구현한 것은 아니었습니다. 이 한계를 보완하고자, 배포 과정에서 서비스 중단을 최소화할 수 있는 전략을 찾아보았습니다.롤링(Rolling) 배포 방식카나리 (Canary) 배포 방식블루/그..
[프로젝트 이슈] CI/CD 구축기 들어가기 전코드를 완성하고 나면, 그다음 단계는 바로 배포입니다. 처음에는 단순하다고 생각했습니다. 로컬에서 빌드한 JAR 파일을 서버에 올리고, SSH로 접속해서 실행하면 끝났죠. 한두 번 정도는 금방 끝나는 일이었고, 이 정도면 충분하다라고 생각하기도 했습니다. 제가 처음 배포를 시작했을 때는, 로컬에서 서버로 JAR 파일을 옮기는 과정도 직접 실행하여야 했습니다. 일반적으로는 SCP나 SFTP를 이용해서 파일을 서버에 업로드했습니다. 예를 들어, 터미널에서 다음과 같이 명령어를 입력하면 됩니다.scp build/libs/app.jar ubuntu@서버IP:/home/ubuntu/app/ 이 한 줄로 로컬에서 빌드한 JAR 파일이 원격 서버의 지정 디렉토리로 복사됩니다. 처음에는 단순히 파일을 복사하..
[프로젝트 이슈] 사용자 로그인 처리(인증, 인가) 0. 들어가며API 서버를 설계하면서 가장 먼저 고민한 부분 중 하나는 사용자의 로그인 상태를 어떻게 관리할 것인가? 였습니다. 대표적인 방식으로는 세션 방식과 토큰방식이 있으며 관련 레퍼런스를 살펴보니 각각의 방식은 장단점이 존재했습니다. 세션 방식은 서버가 로그인한 사용자 정보를 서버 측 세션 저장소에 유지하고, 클라이언트는 세션 ID를 쿠키에 담아 요청마다 전달하는 구조입니다. 이 방식은 비교적 구현이 간단하지만, 서버가 상태를 유지(stateful)해야 하므로 확장성과 유연성에 제약이 있었습니다. 특히 서버가 여러 대로 구성되는 분산 환경에서는 세션 동기화 또는 공유 저장소를 구성해야 하므로 복잡도가 증가하는 문제점이 있었습니다. 반면, 토큰 기반 인증은 서버가 사용자 정보를 상태로 관리하지 않고..

티스토리툴바