여기어때

RSS

게시글: 295
등록: 2026년부터

All Frontend Backend AI DevOps Architecture Etc

Backend
Elasticsearch 거리 기반 가중치로 검색 랭킹 최적화하기
여기어때 랭킹추천팀에서 Elasticsearch를 활용하여 검색 랭킹을 최적화한 경험을 공유하는 글입니다. 기존 검색 결과의 문제점을 분석하고, 사용자의 위치 정보를 활용한 거리 기반 가중치 적용을 통해 검색 랭킹을 개선하는 방법을 상세히 설명합니다. 특히, Elasticsearch의 `function_score` 쿼리를 사용하여 다양한 가중치 요소를 조합하고, 거리 계산 로직을 구현하여 실제 서비스에 적용한 사례를 다룹니다. 이를 통해 사용자의 만족도를 높이고 더 나은 검색 경험을 제공하는 데 기여했습니다.
Elasticsearch검색 랭킹가중치
여기어때·2026년 1월 28일
Backend
Coroutine Async 로 지도보기 API 성능 개선하기
이 글은 여기어때 전시개발팀 백엔드 개발자가 지도보기 API의 성능 문제를 해결한 경험을 공유합니다. 기존 시스템 아키텍처에서 Web API는 BFF 역할을 수행하며, 표준 상품 API를 호출하여 지도에 표시할 제휴점의 최저가 정보를 가져옵니다. 문제 상황은 지도보기 기능이 8초나 소요되는 심각한 성능 저하를 겪고 있다는 것입니다. 기존 구현은 동기 방식으로 API를 호출하여 병목 현상이 발생했습니다. 이를 해결하기 위해 Coroutine Async를 도입하여 비동기적으로 API를 호출함으로써 응답 시간을 크게 단축시키는 방안을 제시합니다. 이를 통해 사용자 경험을 개선하고 시스템 효율성을 높이는 것을 목표로 합니다.
CoroutineAsync성능 개선
여기어때·2025년 12월 22일
Backend
전시 도메인에 Kotlin DSL적용하기
이 글은 여기어때 전시개발팀 백엔드 개발자가 복잡한 숙박 상품 전시 로직을 명확하게 표현하기 위해 Kotlin DSL을 적용한 경험을 공유합니다. DSL(Domain-Specific Language)은 특정 도메인에 특화된 언어로, SQL이 대표적인 예시입니다. Kotlin은 자체 기능을 활용하여 내부 DSL을 만들 수 있습니다. 숙박 상품 전시 도메인은 카테고리, 회원 등급 등 다양한 정책에 따라 노출 정보가 달라져 복잡한데, DSL을 통해 이러한 복잡한 정책을 녹여낸 코드를 더 쉽게 이해할 수 있도록 개선하고자 했습니다. 특히 모텔 카테고리의 대실, 숙박 상품 타입별 가격 정책, 재고 상태, 쿠폰 적용 등을 Kotlin DSL로 어떻게 표현했는지 구체적인 사례를 통해 설명합니다.
KotlinDSLDomain-Specific Language
여기어때·2025년 12월 22일
Backend
공통 Kafka 전환기 [Part 2. 공통 Kafka 전환 여정]
여기어때컴퍼니 공통플랫폼개발팀에서 1년여간 진행된 공통 Kafka 전환 프로젝트의 Part 2 내용을 다룹니다. Part 1에서 공유된 배경 및 전략에 이어, 본 글에서는 실제 전환 과정에서 마주했던 고민과 구체적인 전환 방식, 그리고 그 결과를 공유합니다. 각 도메인별로 상이한 운영 방식, 클러스터 규모, 트래픽 수준, 인증 방식 등을 고려하여 개별 클러스터에 최적화된 전환 전략을 수립하는 것이 중요했습니다. 특히, 서비스 영향 최소화를 최우선 과제로 삼아, 소규모 클러스터와 대규모 클러스터에 따라 다른 전환 방식을 적용했습니다. 대규모 환경에서는 단순 엔드포인트 변경 시 발생할 수 있는 중복 소비, 누락, 메시지 순서 변경 등의 위험을 방지하기 위한 방안을 모색했습니다. 최종적으로 8개의 도메인 Kafka 클러스터를 전사 공통 Kafka로 성공적으로 전환 완료했습니다.
Kafka메시지 큐전환
여기어때·2025년 12월 22일
Backend
PLP 최저가 계산 최적화: 정말 모든 객실을 계산해야 할까?
여기어때 전시개발팀에서 PLP(Product List Page)의 최저가 계산 로직을 최적화한 경험을 공유합니다. 기존 로직은 각 날짜/박수 조합마다 모든 객실의 가격을 계산하고 정렬하여 최저가 하나만 선택하는 방식이었습니다. 이는 요청 일수와 객실 수가 늘어날수록 계산량이 기하급수적으로 증가하는 비효율성을 야기했습니다. "정말 모든 객실을 계산해야 하는가?"라는 의문에서 출발하여, 최저가가 될 수 없는 객실은 미리 계산에서 제외하는 Pruning 알고리즘을 도입했습니다. 이 최적화를 통해 불필요한 계산을 줄이고 성능을 개선하는 방법을 제시합니다.
PLP최저가 계산최적화
여기어때·2025년 12월 22일
Backend
하나의 데이터, 멀티 엔진: Apache Iceberg로 구축하는 데이터레이크
여기어때의 데이터 엔지니어 지키님이 Apache Iceberg 테이블 포맷을 도입하고 컴퓨팅과 스토리지가 분리된 데이터 레이크 아키텍처를 구축한 경험을 공유합니다. 기존 Amazon Redshift 기반 데이터 웨어하우스는 데이터 증가에 따른 적재 비효율, 단일 클러스터의 리소스 경합, 급증하는 비용 문제에 직면했습니다. 특히 대용량 테이블의 비효율적인 재적재, 분석 쿼리와 대시보드 간의 성능 경합, 클러스터 확장으로 인한 비용 증가가 주요 문제였습니다. 이러한 문제를 해결하고 미래의 기술 변화에 유연하게 대응하기 위해 벤더 종속성에서 벗어나고 다양한 컴퓨팅 엔진을 활용할 수 있는 Apache Iceberg 기반의 데이터 레이크 아키텍처를 선택하게 된 배경과 과정을 설명합니다.
Apache Iceberg데이터 레이크데이터 웨어하우스
여기어때·2025년 12월 16일
Backend
여기어때 검색서비스 ‘키워드 통합 시스템’ 구축사례
여기어때 검색플랫폼개발팀은 분산된 데이터 소스로 인해 발생하는 비일관성과 복잡한 데이터 흐름 문제를 해결하기 위해 '키워드 통합 시스템' 구축 프로젝트를 추진했습니다. 이 프로젝트는 MongoDB를 기반으로 단일 데이터 허브를 마련하고, 기존 다중 소스 기반 자동완성 구조를 단순화하여 확장성을 확보하는 것을 목표로 합니다. 기존 구조의 빠른 대응력과 안정적인 품질이라는 장점은 유지하면서, 데이터 구조를 단일화하여 관리의 일관성과 운영 효율성을 극대화했습니다. 핵심 설계로는 각 데이터 출처의 특성을 반영하면서도 공통 속성을 중심으로 하나의 통합 스키마를 정의하여 MongoDB에 저장하는 방식을 채택했습니다.
MongoDB데이터 통합검색 시스템
여기어때·2025년 11월 11일
Backend
여기어때 검색 광고: 랭킹 부스팅 구축기
여기어때 랭킹추천개발팀에서 검색 광고를 위한 랭킹 부스팅 기능을 구축한 경험을 공유하는 글입니다. 기존 검색 랭킹 시스템에 광고 상품 구매 시 더 높은 검색 순위를 제공하는 기능을 추가하는 과정에서 겪은 기술적 고민과 해결 과정을 다룹니다. 초기에는 '광고 상품 구매 시 N%의 랭킹 부스트가 M%의 노출 수 상승을 보장해야 한다'는 가설을 세우고, 목표 노출 수 달성을 위한 필요 랭킹 스코어를 역산하는 모델을 수립했습니다. 이를 위해 제휴점별 노출 수와 랭킹 스코어 데이터를 수집하여 선형 회귀 모델을 적용, 노출 횟수로 랭킹 스코어를 예측하는 함수를 도출하는 과정을 상세히 설명합니다. 이 과정에서 검색 품질, 사용자 신뢰, 광고 효율 간의 균형을 맞추는 것이 중요함을 강조합니다.
검색 광고랭킹 부스팅여기어때
여기어때·2025년 11월 7일
Backend
올해에는 DTO에 @Jacksonized 하나 놓아 드려야겠어요
외부 API 연동 시 Lombok의 @Builder와 Jackson 역직렬화를 함께 사용할 때, 필드가 하나뿐인 DTO에서 발생하는 역직렬화 에러의 원인을 분석하고 해결 방법을 제시합니다. Jackson은 JSON을 Java 객체로 변환할 때 특정 생성자나 프로퍼티를 우선적으로 찾는데, Lombok @Builder는 package-private all-args 생성자를 생성하여 이 과정에서 충돌이 발생할 수 있습니다. 이 문제를 해결하기 위해 `@Jacksonized` 어노테이션을 DTO에 추가하는 간단한 방법을 소개하며, 이를 통해 DTO의 빌더 패턴 사용과 Jackson 역직렬화 호환성을 높일 수 있습니다.
DTOJacksonLombok
여기어때·2025년 8월 7일
Backend
밑바닥부터 시작하는 실시간 데이터 파이프라인 : Debezium 톺아보기
이 글은 여기어때컴퍼니 공통플랫폼개발팀에서 실시간 데이터 반영의 필요성을 느껴 CDC(Change Data Capture)를 도입하고, 이를 위해 Debezium을 활용하여 실시간 데이터 파이프라인을 구축한 경험을 공유합니다. Debezium은 MySQL, PostgreSQL 등 다양한 데이터베이스의 트랜잭션 로그를 기반으로 변경 사항을 감지하여 Kafka로 스트리밍하는 오픈소스 플랫폼입니다. 글에서는 Debezium을 이용한 로그 기반 CDC 구현 방법, Kafka Connect와의 연동, 그리고 실제 적용 사례를 상세히 다룹니다. 특히, 트랜잭션 로그를 활용하는 방식이 원본 데이터베이스에 부하를 적게 주면서도 데이터의 최신 상태를 일관성 있게 유지할 수 있다는 장점을 강조합니다. 이를 통해 데이터 웨어하우스뿐만 아니라 다양한 분석 및 서비스 운영에 필요한 실시간 데이터 동기화를 가능하게 합니다.
DebeziumCDCKafka Connect
여기어때·2025년 6월 26일
Backend
BFF(Backend for Frontend) 가 여기어때에서 하는 일
이 글은 여기어때에서 BFF(Backend for Frontend) 개발팀이 수행하는 역할과 그 필요성에 대해 설명합니다. BFF는 각 프론트엔드 클라이언트(웹, 앱 등)의 요구사항에 맞춰 최적화된 API를 제공하는 백엔드 서비스입니다. 이를 통해 프론트엔드 개발팀은 백엔드 팀과의 복잡한 협업 없이도 필요한 데이터를 효율적으로 가져올 수 있습니다. 글에서는 BFF 도입을 통해 얻을 수 있는 장점, 즉 프론트엔드 개발 생산성 향상과 백엔드 시스템의 복잡성 감소를 강조하며, 여기어때의 실제 적용 사례를 통해 그 효과를 보여줍니다. BFF는 마이크로서비스 아키텍처 환경에서 프론트엔드와 백엔드 간의 간극을 메우는 중요한 역할을 수행합니다.
BFFBackend for FrontendAPI Gateway
여기어때·2025년 6월 19일
Backend
Elasticsearch 성능 비교: Box vs Polygon, 어떤 방식이 더 빠를까?
이 글은 Elasticsearch에서 사각형 영역 검색 시 Box 방식과 Polygon 방식의 성능을 비교 분석합니다. 위치 기반 서비스 구현에 필수적인 공간 검색 기능에서 두 방식의 효율성을 평가하기 위해 10만 개의 좌표 데이터를 대상으로 테스트를 진행했습니다. 테스트 환경은 Elasticsearch이며, `geo_point` 색인 방식을 사용했습니다. 검색 쿼리 방식으로는 2개 좌표를 사용하는 `GeoBoundingBoxQuery`와 4개 좌표를 사용하는 `GeoPolygonQuery`를 비교했습니다. 주요 측정 항목은 평균 응답 시간(MTT), 초당 처리 건수(TPS), 평균 응답 데이터 크기입니다. 테스트 결과, 두 방식 모두 평균 응답 시간에서 큰 차이를 보이지 않았지만, 특정 상황에서는 Polygon 방식이 더 나은 성능을 보일 수 있음을 시사합니다.
Elasticsearch성능 비교Box vs Polygon
여기어때·2025년 3월 28일
Backend
Kafka Message Conversion (Serial/Deserializing)
이 글은 여기어때컴퍼니 주문결제개발팀의 애쉬님이 Kafka 메시지 컨버전, 특히 직렬화(Serialization) 및 역직렬화(Deserialization) 과정에서 겪었던 문제와 해결 과정을 공유합니다. 기존 서비스에서는 Kafka 메시지의 Value를 String으로 받아 ObjectMapper를 이용해 파싱하는 방식을 사용했으나, 이 과정에서 비효율성과 잠재적인 문제를 발견했습니다. 글에서는 Java OpenJDK 17, Spring Boot 2.7.18, Apache Kafka 3.1.2, Spring Kafka 2.8.11 환경에서의 Kafka 메시지 직렬화 및 역직렬화 설정과 ConsumerRecord를 활용한 메시지 소비 방식을 상세히 설명합니다. 특히, Producer가 JSON 문자열로 모델을 변환하여 보내는 상황을 가정하고, 이를 Consumer에서 효율적으로 처리하기 위한 방법을 탐구합니다. 이를 통해 Kafka 메시지 처리의 안정성과 성능을 향상시키는 방안을 제시합니다.
KafkaMessage ConversionSerialization
여기어때·2025년 2월 24일
Backend
Aurora Serverless 알아보기
이 글은 AWS의 Aurora Serverless v2에 대해 소개하고, 기존 Aurora MySQL과의 차이점을 성능 중심으로 비교 분석합니다. Aurora Serverless는 온디맨드 방식으로 자동 크기 조절이 가능하여 예측 불가능한 트래픽 상황에 유연하게 대처할 수 있으며, 사용하지 않는 리소스에 대한 비용을 절감하면서도 Aurora의 고가용성 및 확장성을 활용할 수 있다는 장점을 가집니다. 특히 v2 버전은 Aurora MySQL 호환 버전 및 PostgreSQL 호환 버전 모두에서 사용할 수 있으며, 성능 측면에서의 이점을 중점적으로 다룹니다. DBA로서 Aurora Serverless의 개요와 주요 특징을 설명하며, 트래픽 예측이 어려운 환경에서 효율적인 데이터베이스 관리 방안을 제시합니다.
Aurora ServerlessAWS데이터베이스
여기어때·2025년 1월 6일
Backend
검색운영에 반드시 필요한 검색 키워드 관리 이야기
이 글은 검색 시스템 운영에 필수적인 검색 키워드 관리의 중요성을 강조합니다. 랭킹추천개발팀의 웨일님이 작성했으며, 검색 시스템이 형태소 분석과 사전 기반으로 동작함을 설명합니다. 효과적인 검색 결과를 제공하기 위해서는 사용자 의도를 파악하고, 이를 바탕으로 키워드를 체계적으로 관리하는 것이 중요하다고 말합니다. 특히, 검색어의 빈도, 클릭률, 전환율 등을 분석하여 키워드 우선순위를 조정하고, 신규 키워드 발굴 및 불필요한 키워드 제거 등의 운영 전략을 제시합니다. 이를 통해 검색 품질을 향상시키고 사용자 만족도를 높일 수 있음을 보여줍니다.
검색키워드 관리검색 운영
여기어때·2024년 12월 31일
Backend
여기어때의 검색 결과 없음(NR)에 대한 이야기
여기어때 기술 블로그는 검색 결과가 없을 때(NR, No Result) 발생하는 문제와 이를 해결하기 위한 과정을 공유합니다. 사용자가 원하는 정보를 찾지 못하는 상황은 비즈니스 손실로 이어지기 때문에, 검색 결과 없음은 심각하게 다루어져야 할 문제입니다. 이 글에서는 검색 결과 없음 현상의 원인을 분석하고, Elasticsearch 기반의 검색 시스템에서 발생할 수 있는 다양한 문제점들을 진단합니다. 특히, 데이터 정합성, 쿼리 최적화, 인덱싱 전략 등을 점검하며 성능 개선 방안을 모색합니다. 궁극적으로는 사용자 경험을 향상시키고 비즈니스 목표 달성에 기여하는 효과적인 검색 시스템 구축을 목표로 합니다.
검색 결과 없음NR검색 엔진
여기어때·2024년 12월 31일
Backend
리팩토링 여정, 더 나은 코드로의 항해 part 1. 리팩토링 계기와 문제 진단
숙박전시개발팀에서 진행한 리팩토링 여정의 첫 번째 이야기입니다. 이 글은 여기어때의 전시 파트에서 A/B 테스트를 활발히 진행하면서 발생한 구조적 문제점과 그 원인을 진단하는 데 초점을 맞춥니다. 특히, API 응답 지연으로 인한 사용자 불편을 개선하기 위한 카테고리 홈 개편 실험 사례를 소개하며, 기존의 상속 구조와 히스토리 부재가 전시 파트의 어려움을 가중시켰음을 설명합니다. 리팩토링의 계기와 문제점을 명확히 진단하여 향후 개선 방향을 모색하는 데 중요한 발판을 마련합니다.
리팩토링A/B 테스팅API
여기어때·2024년 12월 30일
Backend
지도 서비스(Reverse Geocoding)내재화 이야기
이 글은 여기어때 검색추천개발실에서 진행한 Reverse Geocoding API 내재화 프로젝트에 대한 경험을 공유합니다. 기존 외부 API 사용 시 발생했던 비용 문제와 성능 제약으로 인해 자체적으로 Reverse Geocoding 시스템을 구축하게 된 배경을 설명합니다. 프로젝트를 통해 데이터베이스 설계, 캐시 전략, 성능 최적화 등 다양한 기술적 과제를 해결했으며, 이를 통해 비용 절감과 응답 속도 개선이라는 성과를 달성했습니다. 특히, 대규모 트래픽을 안정적으로 처리하기 위한 시스템 설계 및 운영 노하우를 상세히 다루고 있어, 유사한 시스템 구축을 고려하는 개발자들에게 유용한 정보를 제공합니다.
Reverse GeocodingAPI시스템 내재화
여기어때·2024년 12월 10일
Backend
해외파트너센터 개발 오픈기 — 2. 이메일 인증 공통 서비스 개발 이야기
해외 파트너 센터 개발 과정에서 이메일 인증 공통 서비스 개발 경험을 공유합니다. 기존 국내 파트너 센터는 휴대폰 본인 인증을 사용했으나, 해외 휴대폰 번호 인증 미지원 문제와 SSR 환경에서의 국가 정보 실시간 파악의 어려움으로 인해 이메일 인증 방식이 채택되었습니다. 계정 관리가 국가별로 분리되어 로그인 시점부터 해외 파트너임을 명확히 구분해야 했으며, 이를 위해 별도 도메인 설정 및 로그인 페이지 분리가 이루어졌습니다. 유저혜택개발팀에서 개발한 이메일 인증 공통 서비스는 다양한 도메인에서 활용 가능하며, 이메일 인증 요청 시 `emailType` 값을 통해 다양한 이메일 타입에 따른 인증 메일 발송 및 인증 키 처리를 담당합니다. 이 경험은 글로벌 서비스 확장을 위한 인증 방식 설계의 중요성을 보여줍니다.
이메일 인증공통 서비스로그인
여기어때·2024년 12월 5일
Backend
여기어때 신입 개발자의 암호화 서비스 개선기
여기어때컴퍼니 공통플랫폼개발팀의 신입 백엔드 개발자가 첫 프로젝트로 진행한 암호화 서비스 개선 경험을 공유합니다. 글에서는 민감한 데이터를 안전하게 보호하기 위한 암호화의 중요성과 더불어, 암호화 키 관리의 핵심적인 역할을 강조합니다. 암호화 키가 노출될 경우 데이터 보안이 무력화될 수 있기에, 키의 생성부터 삭제까지 전 생명주기에 걸친 철저한 보안 관리가 필수적임을 설명합니다. 이를 위해 AWS KMS, Google Cloud KMS, Azure Key Vault 등 다양한 클라우드 기반 키 관리 서비스(KMS) 활용 방안을 소개하며, 이러한 서비스들이 어떻게 암호화 키를 효율적이고 안전하게 관리하는 데 도움을 주는지 설명합니다. 궁극적으로 안전한 데이터 관리를 위한 키 관리 서비스 도입의 필요성을 역설합니다.
암호화키 관리KMS
여기어때·2024년 11월 5일