
iOS 기기에서의 독립적 AI 실행: MLX 기반 온디바이스 모델
인터넷 없이도 똑똑한 iOS 앱, MLX로 만들기이번 포스팅에서는 iOS 개발 환경에서 주목받고 있는 온디바이스(On-device) AI 모델 실행 방식과,Apple Silicon에 최적화된 머신러닝 프레임워크 MLX에 대해 소개합니다.기술적 배경이 없는 비개발자부터 전문 개발자까지 모두 쉽게 이해할 수 있도록 구성했습니다.온디바이스 AI는 인터넷 연결 없이 스마트폰이나 태블릿과 같은 기기에서직접 인공지능(AI) 모델을 실행하여 데이터를 처리하는 기술입니다.데이터를 외부로 전송하지 않기 때문에 보안 측면에서 우수하며, 빠르고 안정적인 사용자 경험을 제공합니다.온디바이스 AI의 주요 장점데이터가 기기 외부로 전송되지 않기 때문에 개인정보 유출 위험이 낮습니다.네트워크 상태와 무관하게 빠른 응답을 제공할 수 있습니다.오프라인 환경에서도 AI 기능을 사용할 수 있어 활용 범위가 넓습니다.MLX는 Apple Silicon 기반의 기기에서 머신러닝 모델을 효과적으로 실행하기 위해 설계된PyTorch, TensorFlow처럼 배열 기반 연산을 지원하며,특히 Apple 하드웨어(iOS 및 macOS)에서 최적화된 성능을 제공합니다.iPhone, iPad, Mac 등에서 높은 성능과 전력 효율을 제공합니다.모델을 학습하거나 추론하는 작업을 모두 기기 내에서 수행할 수 있습니다.Swift와의 뛰어난 호환성Swift, SwiftUI와 쉽게 통합되어 앱 개발 생산성이 높아집니다.현재 MLX는 다음과 같은 다양한 LLM을 지원하고 있습니다:자세한 지원 모델은 Hugging Face MLX 문서에서 확인할 수 있습니다.SPM을 통해 MLX 라이브러리 추가온디바이스 AI는 성능과 효율 모두 중요합니다. MLX를 활용해 개발할 때 다음 사항을 고려해보세요.• None 모델이 너무 크면 앱 성능이 저하되거나 충돌이 발생할 수 있습니다.• None 가능한 한 경량화된 모델을 선택하고, 양자화(quantization) 또는 프루닝(pruning) 기법을 통해 최적화하세요.• None 경우에 따라 사전 학습 모델을 파인튜닝(fine-tuning) 해 실제 사용 시 연산량을 줄일 수 있습니다.• None 실시간 입력 처리(예: 음성 스트리밍)에서는 버퍼 관리가 핵심입니다.• None 입력/출력 데이터는 정제된 형태로 전달하고, 불필요한 중간 캐시는 즉시 해제하세요.• None 모델을 여러 번 호출하는 구조라면, 인스턴스를 재사용하거나 컨텍스트를 관리하는 방식도 고려할 수 있습니다.궁극적으로 MLX는 Apple 생태계에서의 온디바이스 AI 구현을 훨씬 더 실용적으로 만들어주는 도구입니다.개발자에게는 성능과 프라이버시를 모두 챙길 수 있는 좋은 선택지가 될 수 있습니다.iOS 기반 앱에 AI 기능을 통합하고자 한다면 MLX는 반드시 눈여겨볼 만한 프레임워크입니다.
6/3/2025

iOS 기기에서의 독립적 AI 실행: MLX 기반 온디바이스 모델
인터넷 없이도 똑똑한 iOS 앱, MLX로 만들기이번 포스팅에서는 iOS 개발 환경에서 주목받고 있는 온디바이스(On-device) AI 모델 실행 방식과,Apple Silicon에 최적화된 머신러닝 프레임워크 MLX에 대해 소개합니다.기술적 배경이 없는 비개발자부터 전문 개발자까지 모두 쉽게 이해할 수 있도록 구성했습니다.온디바이스 AI는 인터넷 연결 없이 스마트폰이나 태블릿과 같은 기기에서직접 인공지능(AI) 모델을 실행하여 데이터를 처리하는 기술입니다.데이터를 외부로 전송하지 않기 때문에 보안 측면에서 우수하며, 빠르고 안정적인 사용자 경험을 제공합니다.온디바이스 AI의 주요 장점데이터가 기기 외부로 전송되지 않기 때문에 개인정보 유출 위험이 낮습니다.네트워크 상태와 무관하게 빠른 응답을 제공할 수 있습니다.오프라인 환경에서도 AI 기능을 사용할 수 있어 활용 범위가 넓습니다.MLX는 Apple Silicon 기반의 기기에서 머신러닝 모델을 효과적으로 실행하기 위해 설계된PyTorch, TensorFlow처럼 배열 기반 연산을 지원하며,특히 Apple 하드웨어(iOS 및 macOS)에서 최적화된 성능을 제공합니다.iPhone, iPad, Mac 등에서 높은 성능과 전력 효율을 제공합니다.모델을 학습하거나 추론하는 작업을 모두 기기 내에서 수행할 수 있습니다.Swift와의 뛰어난 호환성Swift, SwiftUI와 쉽게 통합되어 앱 개발 생산성이 높아집니다.현재 MLX는 다음과 같은 다양한 LLM을 지원하고 있습니다:자세한 지원 모델은 Hugging Face MLX 문서에서 확인할 수 있습니다.SPM을 통해 MLX 라이브러리 추가온디바이스 AI는 성능과 효율 모두 중요합니다. MLX를 활용해 개발할 때 다음 사항을 고려해보세요.• None 모델이 너무 크면 앱 성능이 저하되거나 충돌이 발생할 수 있습니다.• None 가능한 한 경량화된 모델을 선택하고, 양자화(quantization) 또는 프루닝(pruning) 기법을 통해 최적화하세요.• None 경우에 따라 사전 학습 모델을 파인튜닝(fine-tuning) 해 실제 사용 시 연산량을 줄일 수 있습니다.• None 실시간 입력 처리(예: 음성 스트리밍)에서는 버퍼 관리가 핵심입니다.• None 입력/출력 데이터는 정제된 형태로 전달하고, 불필요한 중간 캐시는 즉시 해제하세요.• None 모델을 여러 번 호출하는 구조라면, 인스턴스를 재사용하거나 컨텍스트를 관리하는 방식도 고려할 수 있습니다.궁극적으로 MLX는 Apple 생태계에서의 온디바이스 AI 구현을 훨씬 더 실용적으로 만들어주는 도구입니다.개발자에게는 성능과 프라이버시를 모두 챙길 수 있는 좋은 선택지가 될 수 있습니다.iOS 기반 앱에 AI 기능을 통합하고자 한다면 MLX는 반드시 눈여겨볼 만한 프레임워크입니다.
2025.06.03

좋아요

별로에요

수이 기반 탈중앙화 거래소 세투스 해킹으로... 이해하는 web3 용어
Cetus의 해킹으로 한번 떠들썩 했는데요이번 해커 (공격자는) overflow 체크 취약점을 이용했습니다.전반적으로 관련된 용어를 설명하면서 그 내용도 같이 알아보겠습니다.해커들은 세투스의 자동화된 시장 조성자(AMM) 프로토콜에서 유동성 매개변수의 가장 중요한 비트(MSB) 검증에 존재하는 취약점을 악용했습니다. 이로 인해 단 한 번의 키 입력으로 대규모 유동성 포지션을 형성하고, 이를 통해 수백만 달러 상당의 자산을 탈취할 수 있었습니다. 총 2억 2,300만 달러 상당의 자산이 탈취되었으며, 이 중 약 1억 6,300만 달러는 수이 네트워크의 검증자들에 의해 동결되었습니다. 일부 커뮤니티 구성원들은 검증자들의 자산 동결 조치가 탈중앙화 원칙을 훼손한다고 비판했습니다. 이는 블록체인의 검열 저항성과 관련된 논쟁을 촉발시켰습니다.세투스는 Sui와 Aptos 블록체인 기반의 탈중앙화 거래소 (DEX) 입니다.세투스는 CLMM( Concentrated Liquidity Market Maker : 집중 유동성 시장 조성자) 모델을 도입했습니다.기존의 AMM ( Automated Market Maker) 모델은 일반적으로 Constant Product Formula ( x * y = k ) 를 사용합니다.AMM 최초에 공급자가 예치하는 토큰을 기준으로 x * y = k 를 결정합니다.A라는 유동성 공급자가 이더 2 개와 USDC 1,500 개를 예치하고 유동성 pool을 생성을 하면이더리움과 USDC는 2 * 1500 = 3000 의 공식이 성립하게 되고, 3000 이라는 숫자는 바꾸지 않게 됩니다.이때 1 이더의 가치는 750 USDC로 볼 수 있습니다. 최초에는 가격차이가 날 수 있지만,거래 차익을 얻기 위한 노력으로 시장 평균으로 수렴하게 됩니다.단 B라는 사람이 1개의 이더를 거래하기 위해서 USDC 750개를 넣었다고 하면Constant Product Formula ( x * y = k ) 에 의해서 0.6666..7 개의 이더만 확보하게 됩니다. (거래순간 이더의 가치가 올라가 버립니다)초기 가치와 비교해서 0.33333개 를 확보하지 못하게 되는데이때 이 0.33333 개에 해당하는 가치에 대해서 슬리피지가 발생했다 합니다.이 AMM 모델은 0 부터 무한대까지 모든 가격범위에 걸쳐 균등하게 분포 되지만, 유동성 pool이 작을때는위에서 처럼 슬리피지가 발생합니다. 하지만 토큰의 가치가 급변하기 보다는 특정 가격 범위에서 주로 거래가 됩니다.하지만 전체 가격범위에 토큰의 유동성이 공급되다 보니, 실제 거래가 자주 발생하는 범위에서는 유동성이 부족해 지게 되는 현상이 발생합니다.CLMM은 특정 범위를 정해 놓고, 해당 범위에 대해서만 유동성을 공급하게 됨으로낮은 슬리피지와 거래가 활성화 되고, 거래 수수료를 더 많이 받을 수 있는 장점이 있습니다.세투스는 CLMM 모델을 통해 유동성 공급자들이 특정 가격 범위 내에서 자산을 제공함으로써 자본 효율성을 극대화하고, 거래자들에게는 낮은 슬리피지와 빠른 거래를 제공합니다.CLMM에서는 유동성 공급자가 특정 가격 범위에 자산을 공급합니다.그 범위 안에서는 항상 두 가지 자산이 일정한 비율로 교환 가능해야 하죠.이걸 가능하게 하려면 유동성이 일정해야 하고, 이 유동성은 가격 범위 내에서 루트 가격 기반의 계산으로 정해집니다.유동성을 구하는 공식은즉 루트 가격 범위의 차이가 작을수록, 동일한 토큰 양으로 더 큰 liquidity 값이 계산됩니다.이해를 돕기위해서 가상의 예를 든다면 1개의 이더를 1000원 ~ 10000원 사이에 공급하기로 했다고 하면 1/ (10-1) 로 유동성이 계산되는 방식입니다.실제로는 금액이 아니라 Tick이라는 단위로 계산이 되어집니다.공격자(해커)는 매우 좁은 가격 범위(예: [300000, 300200])를 설정하여 유동성을 추가했습니다.이러한 좁은 범위는 sqrt_price_diff 값을 작게 만들어, 이후 계산의 결과가 오버플로우를 발생은 하지만 임계값을 넘지 않도록 만들었습니다.Cetus의 스마트 계약에서는 checked_shlw 함수를 사용하여 오버플로우를 검사합니다.그러나 이 함수의 구현에서 사용된 마스크 값이 잘못되어, 실제로 오버플로우가 발생해도 이를 감지하지 못했습니다.공격자는 이 취약점을 이용하여, 오버플로우를 유도하면서도 검사에는 통과하는 값을 입력할 수 있었습니다.이런 방식으로 실제 1Token 만 공급하였지만, 오버플로우로 인해서 대용량의 유동성을 공급 받습니다.큰 유동성을 제공한 것으로 인정받아, LP토큰을 받게 됩니다. LP토큰은 유동성 Pool 내의 지분을 의미합니다.이렇게 1 토큰으로 LP토큰을 받은 뒤에 다시 자산을 회수하는 방식으로 2억 2,300만 달러의 자산을 탈취했습니다.자산 동결이 가능한 이유Sui 블록체인은 Move 언어를 기반이며 자산의 이동이 검증자의 승인을 필요로 하는 구조입니다.즉, 자산의 소유자가 트랜잭션을 생성하더라도, 검증자들이 이를 승인하지 않으면 해당 자산은 이동할 수 없습니다.검증자들이 협력하여 해커의 주소에서 발생하는 트랜잭션을 처리하지 않음으로써, 해당 자산을 사실상 동결할 수 있습니다.이번 사태가 발생한 후에 보안 전문가들과 Sui커뮤니티에서 해커 주소 식별 → 검증자 설정 변경 → 협력적 실행 을 통해서 자산을 동결했습니다.나머지 약 6,000만 달러는 해커가 Sui 네트워크를 벗어나 이더리움 체인으로 브리지로 이전하여 동결이 어려웠습니다.검증자들의 협력은 사용자 자산 보호라는 측면에서 긍정적으로 평가되지만,동시에 블록체인의 탈중앙화 원칙에 대한 우려가 있습니다.일부 커뮤니티 구성원들은 검증자들이 특정 주소의 트랜잭션을 임의로 차단할 수 있는 권한을 가지는 것이검열의 위험성을 내포한다고 말합니다Sui 재단은 이러한 우려를 인식하고, 동결된 자산의 반환 여부를 커뮤니티의 거버넌스 투표를 통해 결정하도록 제안했습니다.
6/2/2025

수이 기반 탈중앙화 거래소 세투스 해킹으로... 이해하는 web3 용어
Cetus의 해킹으로 한번 떠들썩 했는데요이번 해커 (공격자는) overflow 체크 취약점을 이용했습니다.전반적으로 관련된 용어를 설명하면서 그 내용도 같이 알아보겠습니다.해커들은 세투스의 자동화된 시장 조성자(AMM) 프로토콜에서 유동성 매개변수의 가장 중요한 비트(MSB) 검증에 존재하는 취약점을 악용했습니다. 이로 인해 단 한 번의 키 입력으로 대규모 유동성 포지션을 형성하고, 이를 통해 수백만 달러 상당의 자산을 탈취할 수 있었습니다. 총 2억 2,300만 달러 상당의 자산이 탈취되었으며, 이 중 약 1억 6,300만 달러는 수이 네트워크의 검증자들에 의해 동결되었습니다. 일부 커뮤니티 구성원들은 검증자들의 자산 동결 조치가 탈중앙화 원칙을 훼손한다고 비판했습니다. 이는 블록체인의 검열 저항성과 관련된 논쟁을 촉발시켰습니다.세투스는 Sui와 Aptos 블록체인 기반의 탈중앙화 거래소 (DEX) 입니다.세투스는 CLMM( Concentrated Liquidity Market Maker : 집중 유동성 시장 조성자) 모델을 도입했습니다.기존의 AMM ( Automated Market Maker) 모델은 일반적으로 Constant Product Formula ( x * y = k ) 를 사용합니다.AMM 최초에 공급자가 예치하는 토큰을 기준으로 x * y = k 를 결정합니다.A라는 유동성 공급자가 이더 2 개와 USDC 1,500 개를 예치하고 유동성 pool을 생성을 하면이더리움과 USDC는 2 * 1500 = 3000 의 공식이 성립하게 되고, 3000 이라는 숫자는 바꾸지 않게 됩니다.이때 1 이더의 가치는 750 USDC로 볼 수 있습니다. 최초에는 가격차이가 날 수 있지만,거래 차익을 얻기 위한 노력으로 시장 평균으로 수렴하게 됩니다.단 B라는 사람이 1개의 이더를 거래하기 위해서 USDC 750개를 넣었다고 하면Constant Product Formula ( x * y = k ) 에 의해서 0.6666..7 개의 이더만 확보하게 됩니다. (거래순간 이더의 가치가 올라가 버립니다)초기 가치와 비교해서 0.33333개 를 확보하지 못하게 되는데이때 이 0.33333 개에 해당하는 가치에 대해서 슬리피지가 발생했다 합니다.이 AMM 모델은 0 부터 무한대까지 모든 가격범위에 걸쳐 균등하게 분포 되지만, 유동성 pool이 작을때는위에서 처럼 슬리피지가 발생합니다. 하지만 토큰의 가치가 급변하기 보다는 특정 가격 범위에서 주로 거래가 됩니다.하지만 전체 가격범위에 토큰의 유동성이 공급되다 보니, 실제 거래가 자주 발생하는 범위에서는 유동성이 부족해 지게 되는 현상이 발생합니다.CLMM은 특정 범위를 정해 놓고, 해당 범위에 대해서만 유동성을 공급하게 됨으로낮은 슬리피지와 거래가 활성화 되고, 거래 수수료를 더 많이 받을 수 있는 장점이 있습니다.세투스는 CLMM 모델을 통해 유동성 공급자들이 특정 가격 범위 내에서 자산을 제공함으로써 자본 효율성을 극대화하고, 거래자들에게는 낮은 슬리피지와 빠른 거래를 제공합니다.CLMM에서는 유동성 공급자가 특정 가격 범위에 자산을 공급합니다.그 범위 안에서는 항상 두 가지 자산이 일정한 비율로 교환 가능해야 하죠.이걸 가능하게 하려면 유동성이 일정해야 하고, 이 유동성은 가격 범위 내에서 루트 가격 기반의 계산으로 정해집니다.유동성을 구하는 공식은즉 루트 가격 범위의 차이가 작을수록, 동일한 토큰 양으로 더 큰 liquidity 값이 계산됩니다.이해를 돕기위해서 가상의 예를 든다면 1개의 이더를 1000원 ~ 10000원 사이에 공급하기로 했다고 하면 1/ (10-1) 로 유동성이 계산되는 방식입니다.실제로는 금액이 아니라 Tick이라는 단위로 계산이 되어집니다.공격자(해커)는 매우 좁은 가격 범위(예: [300000, 300200])를 설정하여 유동성을 추가했습니다.이러한 좁은 범위는 sqrt_price_diff 값을 작게 만들어, 이후 계산의 결과가 오버플로우를 발생은 하지만 임계값을 넘지 않도록 만들었습니다.Cetus의 스마트 계약에서는 checked_shlw 함수를 사용하여 오버플로우를 검사합니다.그러나 이 함수의 구현에서 사용된 마스크 값이 잘못되어, 실제로 오버플로우가 발생해도 이를 감지하지 못했습니다.공격자는 이 취약점을 이용하여, 오버플로우를 유도하면서도 검사에는 통과하는 값을 입력할 수 있었습니다.이런 방식으로 실제 1Token 만 공급하였지만, 오버플로우로 인해서 대용량의 유동성을 공급 받습니다.큰 유동성을 제공한 것으로 인정받아, LP토큰을 받게 됩니다. LP토큰은 유동성 Pool 내의 지분을 의미합니다.이렇게 1 토큰으로 LP토큰을 받은 뒤에 다시 자산을 회수하는 방식으로 2억 2,300만 달러의 자산을 탈취했습니다.자산 동결이 가능한 이유Sui 블록체인은 Move 언어를 기반이며 자산의 이동이 검증자의 승인을 필요로 하는 구조입니다.즉, 자산의 소유자가 트랜잭션을 생성하더라도, 검증자들이 이를 승인하지 않으면 해당 자산은 이동할 수 없습니다.검증자들이 협력하여 해커의 주소에서 발생하는 트랜잭션을 처리하지 않음으로써, 해당 자산을 사실상 동결할 수 있습니다.이번 사태가 발생한 후에 보안 전문가들과 Sui커뮤니티에서 해커 주소 식별 → 검증자 설정 변경 → 협력적 실행 을 통해서 자산을 동결했습니다.나머지 약 6,000만 달러는 해커가 Sui 네트워크를 벗어나 이더리움 체인으로 브리지로 이전하여 동결이 어려웠습니다.검증자들의 협력은 사용자 자산 보호라는 측면에서 긍정적으로 평가되지만,동시에 블록체인의 탈중앙화 원칙에 대한 우려가 있습니다.일부 커뮤니티 구성원들은 검증자들이 특정 주소의 트랜잭션을 임의로 차단할 수 있는 권한을 가지는 것이검열의 위험성을 내포한다고 말합니다Sui 재단은 이러한 우려를 인식하고, 동결된 자산의 반환 여부를 커뮤니티의 거버넌스 투표를 통해 결정하도록 제안했습니다.
2025.06.02

좋아요

별로에요

당신이 보는 첫 화면은 어떻게 정해질까? 무신사 홈 배너 개인화 추천 이야기
안녕하세요, 무신사 타겟팅ML팀의 방효석, 조준형입니다. 저희 팀은 다양한 AI/ML 기술을 활용해 무신사의 모든 상품과 비즈니스 접점에서 개인화된 고객 경험을 제공하는 것을 목표로 하고 있습니다. 지난 1분기 동안 디스플레이 지면의 CTR(Click-trhough Rate; 클릭률)을 더욱 개선하기 위해, 무신사 및 6개 전문관 스토어 홈 지면의 개인화된 배너 노출 로직을 개발하는 프로젝트를 진행했습니다. 이번 글에서는 프로젝트를 수행하며 마주했던 여러 가지 문제들을 어떻게 해결했는지, 그리고 그 과정에서 얻은 인사이트들을 함께 공유하고자 합니다.고객 맞춤 빅배너로 더 나은 경험 만들기무신사를 이용하는 고객들의 취향과 니즈는 과거보다 훨씬 다양해졌으며, 노출 가능한 콘텐츠 수도 꾸준히 늘고 있습니다. 하지만 이러한 복잡한 상황과 세분화된 니즈를 충분히 반영하지 못한 채 일괄적으로 노출되는 배너는 고객 경험을 저해할 수 있다는 문제 제기가 있었습니다. 이에 분명한 개선의 여지가 있다고 판단했고, 디스플레이 최적화 라는 이름으로 각 스토어 홈 상단 빅배너의 노출 방식을 개인화하여 CTR을 극대화하는 프로젝트를 진행하게 되었습니다.무신사 서비스 첫인상, 스토어 홈 배너 소개<그림 1. 무신사 홈 배너: 앱(좌측), 웹(우측)>스토어 홈 빅배너는 무신사 앱과 웹을 열었을 때 가장 먼저 마주치는 화면 맨 위 배너입니다. 웹사이트의 간판 같은 존재라 무신사가 전하고 싶은 브랜드 감성과 콘텐츠를 첫눈에 보여 주죠. 슬라이드 형식으로 총 35장이 돌아가며 노출되고, 앱에서는 한 번에 1장, 웹에서는 3장이 함께 보입니다.무신사에 접속한 고객 가운데 약 97 %는 메인 화면에 도착하자마자 홈 배너를 가장 먼저 만납니다. 이 배너는 무신사 스토어뿐 아니라 뷰티·플레이어 등 6개 전문관 홈에도 같은 자리에 노출되며, 무신사 서비스의 첫인상을 책임지고 있습니다.홈 배너 최적화가 필요한 이유무신사에는 여러 전시 지면이 있지만, 홈 배너를 먼저 최적화하기로 한 이유는 분명합니다. 홈 배너는 고객이 무신사에 접속해 가장 먼저 마주치는 서비스의 얼굴 로, 하루 수십만 명에게 노출되기 때문입니다. 또한 메인 화면에 위치한 여러 디스플레이 영역 중에서도 홈 배너는 특히 고객의 관심도가 높습니다. 실제로 전체 클릭 수의 약 35%, 클릭이 발생한 세션의 약 37%가 홈 배너에서 발생하고 있습니다. 이러한 지표를 근거로, 전환 효과가 가장 큰 홈 배너부터 개선을 시작하기로 결정했습니다.홈 배너 추천, 왜 더 똑똑한 방법이 필요했을까?기존에도 홈 배너의 노출 순서는 모델 기반으로 최적화되고 있었지만, 완전한 수준의 초개인화 추천 시스템은 아니었습니다. 과거에는 MAB(Multi-Armed Bandit) 알고리즘을 활용해 배너 추천을 진행해 왔습니다.MAB 알고리즘은 제한된 시도 안에서 여러 선택지(배너) 중 가장 높은 보상(클릭률)을 얻기 위해, 탐험(Exploration) 과 활용(Exploitation) 사이의 균형을 조절하는 전략입니다. 여기서 탐험 은 새로운 배너의 가능성을 시험하는 과정이고, 활용 은 성과가 입증된 배너에 집중하는 것을 의미합니다. MAB는 이 두 과정을 조율하며, 시간이 지남에 따라 성과가 좋은 배너를 더 자주 노출하는 방식으로 학습합니다.하지만 이 방식에는 세 가지 뚜렷한 한계가 있었습니다.단일 지표 의존 클릭률 하나만 바라보니 고객 취향, 선호, 배너 자체의 특성 같은 다층적 요인이 반영되지 않았습니다.연관성 미반영 MAB가 각 배너를 서로 독립적으로 간주해, 사용자가 예전에 관심을 보인 배너와의 유사성을 고려하지 못했습니다.콜드 스타트(Cold Start) 문제 새 배너가 투입되면 클릭 데이터가 쌓일 때까지 성능이 저조했습니다. 결국 고객 경험이 크게 좌우되는 홈 배너 영역에서 클릭률만으로는 섬세한 니즈를 채우기 어렵고, 빠르게 변하는 환경에도 기민하게 대응하기 힘들었습니다.이러한 문제들을 해결하고 사용자에게 더 정교한 개인화 추천을 제공하기 위해서는 기존과 다른 새로운 접근 방식이 필요했습니다. 다음 장에서는 이러한 고민을 바탕으로 새롭게 설계한 추천 시스템의 전체 파이프라인 구조에 대해 자세히 소개드리겠습니다.스토어 홈 빅배너 추천 시스템 구조<그림 2. 무신사 홈 배너 추천 시스템 아키텍쳐>무신사 홈 배너 추천 시스템은 여러 단계로 이루어진 정교한 파이프라인을 통해 각 사용자에게 가장 알맞은 배너를 실시간으로 보여 줍니다. 그림 2는 이러한 배너 추천 시스템의 전체적인 구조를 설명하고 있습니다. 각 주요 단계 별 구체적인 내용은 아래와 같습니다.1. 추천할 배너를 더 잘 이해하기 GIGO(Garbage In, Garbage Out) 라는 말처럼, 좋은 모델을 학습하기 위해서는 양질의 표현(Representation)을 추출하는 것이 매우 중요합니다. 기존에도 배너 타이틀, 연관 카테고리, 브랜드, 라벨 등 다양한 메타 데이터가 DB에 저장되어 있으나, 이 정보들은 운영 목적에 따라 적재된 데이터이기 때문에, 추천 모델 관점에서 일관된 기준을 유지하기 어렵다는 한계가 있었습니다.이러한 문제를 극복하기 위해, 저희는 사용자 행동 로그를 활용한 표현(Representation) 학습 방식으로 접근했습니다. 일정 기간 동안 수집된 유저의 배너 및 상품 클릭 이력을 기반으로 이종 그래프(Heterogeneous Graph)를 구성하고, 이를 GraphSAGE 알고리즘에 적용했습니다. 이 과정을 통해 사용자 탐색 패턴을 반영한 배너 및 상품 임베딩(Embedding)을 생성할 수 있었으며, 이렇게 추출된 임베딩은 모든 노출 가능 배너 후보군에 대해 계산되어 이후 모델 학습의 입력 피처(Input Feature)로 활용됩니다.2. 클릭 확률을 계산하기 위한 모델 학습하기배너 추천 시스템의 핵심은 각 사용자에게 적합한 배너를 찾아주는 것 입니다. 저희는 이 문제를 많은 추천 시스템에서 채택하는 방식처럼 CTR(Click-Through Rate) 예측 문제로 정의했고, 이를 해결하기 위해 DeepFM과 Two-Tower 모델을 활용했습니다.앞선 단계에서 HGNN을 통해 학습된 고품
6/1/2025

당신이 보는 첫 화면은 어떻게 정해질까? 무신사 홈 배너 개인화 추천 이야기
안녕하세요, 무신사 타겟팅ML팀의 방효석, 조준형입니다. 저희 팀은 다양한 AI/ML 기술을 활용해 무신사의 모든 상품과 비즈니스 접점에서 개인화된 고객 경험을 제공하는 것을 목표로 하고 있습니다. 지난 1분기 동안 디스플레이 지면의 CTR(Click-trhough Rate; 클릭률)을 더욱 개선하기 위해, 무신사 및 6개 전문관 스토어 홈 지면의 개인화된 배너 노출 로직을 개발하는 프로젝트를 진행했습니다. 이번 글에서는 프로젝트를 수행하며 마주했던 여러 가지 문제들을 어떻게 해결했는지, 그리고 그 과정에서 얻은 인사이트들을 함께 공유하고자 합니다.고객 맞춤 빅배너로 더 나은 경험 만들기무신사를 이용하는 고객들의 취향과 니즈는 과거보다 훨씬 다양해졌으며, 노출 가능한 콘텐츠 수도 꾸준히 늘고 있습니다. 하지만 이러한 복잡한 상황과 세분화된 니즈를 충분히 반영하지 못한 채 일괄적으로 노출되는 배너는 고객 경험을 저해할 수 있다는 문제 제기가 있었습니다. 이에 분명한 개선의 여지가 있다고 판단했고, 디스플레이 최적화 라는 이름으로 각 스토어 홈 상단 빅배너의 노출 방식을 개인화하여 CTR을 극대화하는 프로젝트를 진행하게 되었습니다.무신사 서비스 첫인상, 스토어 홈 배너 소개<그림 1. 무신사 홈 배너: 앱(좌측), 웹(우측)>스토어 홈 빅배너는 무신사 앱과 웹을 열었을 때 가장 먼저 마주치는 화면 맨 위 배너입니다. 웹사이트의 간판 같은 존재라 무신사가 전하고 싶은 브랜드 감성과 콘텐츠를 첫눈에 보여 주죠. 슬라이드 형식으로 총 35장이 돌아가며 노출되고, 앱에서는 한 번에 1장, 웹에서는 3장이 함께 보입니다.무신사에 접속한 고객 가운데 약 97 %는 메인 화면에 도착하자마자 홈 배너를 가장 먼저 만납니다. 이 배너는 무신사 스토어뿐 아니라 뷰티·플레이어 등 6개 전문관 홈에도 같은 자리에 노출되며, 무신사 서비스의 첫인상을 책임지고 있습니다.홈 배너 최적화가 필요한 이유무신사에는 여러 전시 지면이 있지만, 홈 배너를 먼저 최적화하기로 한 이유는 분명합니다. 홈 배너는 고객이 무신사에 접속해 가장 먼저 마주치는 서비스의 얼굴 로, 하루 수십만 명에게 노출되기 때문입니다. 또한 메인 화면에 위치한 여러 디스플레이 영역 중에서도 홈 배너는 특히 고객의 관심도가 높습니다. 실제로 전체 클릭 수의 약 35%, 클릭이 발생한 세션의 약 37%가 홈 배너에서 발생하고 있습니다. 이러한 지표를 근거로, 전환 효과가 가장 큰 홈 배너부터 개선을 시작하기로 결정했습니다.홈 배너 추천, 왜 더 똑똑한 방법이 필요했을까?기존에도 홈 배너의 노출 순서는 모델 기반으로 최적화되고 있었지만, 완전한 수준의 초개인화 추천 시스템은 아니었습니다. 과거에는 MAB(Multi-Armed Bandit) 알고리즘을 활용해 배너 추천을 진행해 왔습니다.MAB 알고리즘은 제한된 시도 안에서 여러 선택지(배너) 중 가장 높은 보상(클릭률)을 얻기 위해, 탐험(Exploration) 과 활용(Exploitation) 사이의 균형을 조절하는 전략입니다. 여기서 탐험 은 새로운 배너의 가능성을 시험하는 과정이고, 활용 은 성과가 입증된 배너에 집중하는 것을 의미합니다. MAB는 이 두 과정을 조율하며, 시간이 지남에 따라 성과가 좋은 배너를 더 자주 노출하는 방식으로 학습합니다.하지만 이 방식에는 세 가지 뚜렷한 한계가 있었습니다.단일 지표 의존 클릭률 하나만 바라보니 고객 취향, 선호, 배너 자체의 특성 같은 다층적 요인이 반영되지 않았습니다.연관성 미반영 MAB가 각 배너를 서로 독립적으로 간주해, 사용자가 예전에 관심을 보인 배너와의 유사성을 고려하지 못했습니다.콜드 스타트(Cold Start) 문제 새 배너가 투입되면 클릭 데이터가 쌓일 때까지 성능이 저조했습니다. 결국 고객 경험이 크게 좌우되는 홈 배너 영역에서 클릭률만으로는 섬세한 니즈를 채우기 어렵고, 빠르게 변하는 환경에도 기민하게 대응하기 힘들었습니다.이러한 문제들을 해결하고 사용자에게 더 정교한 개인화 추천을 제공하기 위해서는 기존과 다른 새로운 접근 방식이 필요했습니다. 다음 장에서는 이러한 고민을 바탕으로 새롭게 설계한 추천 시스템의 전체 파이프라인 구조에 대해 자세히 소개드리겠습니다.스토어 홈 빅배너 추천 시스템 구조<그림 2. 무신사 홈 배너 추천 시스템 아키텍쳐>무신사 홈 배너 추천 시스템은 여러 단계로 이루어진 정교한 파이프라인을 통해 각 사용자에게 가장 알맞은 배너를 실시간으로 보여 줍니다. 그림 2는 이러한 배너 추천 시스템의 전체적인 구조를 설명하고 있습니다. 각 주요 단계 별 구체적인 내용은 아래와 같습니다.1. 추천할 배너를 더 잘 이해하기 GIGO(Garbage In, Garbage Out) 라는 말처럼, 좋은 모델을 학습하기 위해서는 양질의 표현(Representation)을 추출하는 것이 매우 중요합니다. 기존에도 배너 타이틀, 연관 카테고리, 브랜드, 라벨 등 다양한 메타 데이터가 DB에 저장되어 있으나, 이 정보들은 운영 목적에 따라 적재된 데이터이기 때문에, 추천 모델 관점에서 일관된 기준을 유지하기 어렵다는 한계가 있었습니다.이러한 문제를 극복하기 위해, 저희는 사용자 행동 로그를 활용한 표현(Representation) 학습 방식으로 접근했습니다. 일정 기간 동안 수집된 유저의 배너 및 상품 클릭 이력을 기반으로 이종 그래프(Heterogeneous Graph)를 구성하고, 이를 GraphSAGE 알고리즘에 적용했습니다. 이 과정을 통해 사용자 탐색 패턴을 반영한 배너 및 상품 임베딩(Embedding)을 생성할 수 있었으며, 이렇게 추출된 임베딩은 모든 노출 가능 배너 후보군에 대해 계산되어 이후 모델 학습의 입력 피처(Input Feature)로 활용됩니다.2. 클릭 확률을 계산하기 위한 모델 학습하기배너 추천 시스템의 핵심은 각 사용자에게 적합한 배너를 찾아주는 것 입니다. 저희는 이 문제를 많은 추천 시스템에서 채택하는 방식처럼 CTR(Click-Through Rate) 예측 문제로 정의했고, 이를 해결하기 위해 DeepFM과 Two-Tower 모델을 활용했습니다.앞선 단계에서 HGNN을 통해 학습된 고품
2025.06.01

좋아요

별로에요

팀 무신사 테크 블로그에 29CM가 함께합니다!
안녕하세요.2025년 6월 2일부터 29CM의 새로운 소식이 팀 무신사 테크 블로그에서 발행됩니다. 기존 글은 29CM 테크 블로그에서 볼 수 있습니다.무신사와 29CM가 함께 만들어가는 기술과 문화에 많은 관심 부탁드립니다.감사합니다.팀 무신사 테크 블로그에 29CM가 함께합니다! was originally published in MUSINSA tech on Medium, where people are continuing the conversation by highlighting and responding to this story.
6/1/2025

팀 무신사 테크 블로그에 29CM가 함께합니다!
안녕하세요.2025년 6월 2일부터 29CM의 새로운 소식이 팀 무신사 테크 블로그에서 발행됩니다. 기존 글은 29CM 테크 블로그에서 볼 수 있습니다.무신사와 29CM가 함께 만들어가는 기술과 문화에 많은 관심 부탁드립니다.감사합니다.팀 무신사 테크 블로그에 29CM가 함께합니다! was originally published in MUSINSA tech on Medium, where people are continuing the conversation by highlighting and responding to this story.
2025.06.01

좋아요

별로에요

AI로 만드는 여행 테마: 하루 만에 1353개 자동 생성
“하나의 테마에 20–30분…” 수작업의 한계에 부딪힌 여행 콘텐츠여행 상품을 어떻게 하면 더 효과적으로 사용자에게 소개할 수 있을까요? 이 고민에서 시작된 ‘테마’ 시스템은 상품을 다양한 관점으로 그룹화하여 사용자에게 맞춤형 경험을 제공하는 중요한 방법입니다.“테마는 상품을 그룹핑하는 묶음 단위입니다. 카테고리는 한 개의 상품에 한 개의 카테고리가 들어가는 구조였다면, 테마는 한 상품이 카테고리에 관계없이 여러 테마에 맵핑이 되는 그룹핑 단위입니다.”이런 테마는 앱에서 이미지와 함께 상품을 설명하는 타이틀과 서브 타이틀로 구성되어 사용자들에게 상품을 소개하는 데 활용됩니다. 그러나 이 중요한 테마 생성 과정에 큰 문제가 있었어요.테마 카드 예“이런 테마들은 다 사람이 수동으로 만들어야 했어요. 인기 도시에 집중되어 있는 문제도 있었고, 비인기 도시는 테마가 존재하지 않은 경우도 많았어요. 하나의 테마를 만드는데 20–30분 정도 소요됩니다.”이러한 수동 작업의 한계로 인해 비인기 도시에는 테마가 거의 존재하지 않았습니다. 많은 시간이 소요되는 작업이다 보니 자연스럽게 인기 있는 도시의 테마 제작에 자원이 집중될 수밖에 없었죠.테마가가 거의 없는 도시들AI에게 테마를 맡기다: 자동화의 첫걸음FTN팀 백엔드 엔지니어인 백승빈님은 사업실의 이런 어려움을 듣고 AI 를 활용해서 문제를 해결해 보기로 했어요. 곧 AI를 활용한 테마 생성 자동화를 시도한 거죠. 일단 테마를 만들기 위해서는 두 가지 핵심 요소가 필요했어요.“테마를 만들기 위해서는 한 테마로 묶을 상품들의 조건(어떤 상품들을 대상으로 할지)과 테마명(어떤 설명으로 소구할지) 이 두 가지가 필요했습니다.”조건은 앱 메인 화면의 3x3 그리드에 나타나는 상품들을 활용했고, 테마명은 AI를 통해 작성했습니다. AI에게 어떻게 테마명을 요청했을까요?초기 결과는 괜찮은듯 했으나, 곧 한 가지 문제점이 발견됐습니다. AI가 생성한 테마명들이 너무 비슷한 패턴을 보이면서 각 테마의 특색이 드러나지 않았어요. 특히 대부분의 테마가 도시 이름으로 시작하는 획일적인 형태를 보였죠.“그라나다 지역의 테마들의 타이틀은 모두 ‘그라나다’로 시작하거나 발리의 테마들도 모두 ‘발리’ 가 들어갔어요. 그러니 각 테마의 특성이 살지 않고 너무 획일적인 느낌이 들었죠.”이 문제를 해결하기 위해 프롬프트를 개선했습니다. 기존의 입력에 두 가지 중요한 조건을 추가했어요. 기존에 만들어진 테마명을 맥락으로 전달하면서, 기존 테마명과 다르게 생성해달라고 시스템 프롬프트를 추가한거죠.하루 만에 1353개 테마: 450시간의 작업을 단축한 AI의 힘프롬프트 개선 후, AI는 훨씬 더 다양하고 특색 있는 테마명을 생성하기 시작했습니다. 단순히 프롬프트 몇 줄을 추가했을 뿐인데, 결과물의 품질이 크게 향상된 것이죠.시스템 프롬프트 개선 전과 후의 차이점“변경 전과 변경 후를 비교해보면 왼쪽은 다 발리로 시작하고 비슷해 보이지만 오른쪽은 특색 있게 바뀌어 상품들을 소개하는 데 더 적합합니다.”AI 호출 결과“387개의 도시에서
6/1/2025

AI로 만드는 여행 테마: 하루 만에 1353개 자동 생성
“하나의 테마에 20–30분…” 수작업의 한계에 부딪힌 여행 콘텐츠여행 상품을 어떻게 하면 더 효과적으로 사용자에게 소개할 수 있을까요? 이 고민에서 시작된 ‘테마’ 시스템은 상품을 다양한 관점으로 그룹화하여 사용자에게 맞춤형 경험을 제공하는 중요한 방법입니다.“테마는 상품을 그룹핑하는 묶음 단위입니다. 카테고리는 한 개의 상품에 한 개의 카테고리가 들어가는 구조였다면, 테마는 한 상품이 카테고리에 관계없이 여러 테마에 맵핑이 되는 그룹핑 단위입니다.”이런 테마는 앱에서 이미지와 함께 상품을 설명하는 타이틀과 서브 타이틀로 구성되어 사용자들에게 상품을 소개하는 데 활용됩니다. 그러나 이 중요한 테마 생성 과정에 큰 문제가 있었어요.테마 카드 예“이런 테마들은 다 사람이 수동으로 만들어야 했어요. 인기 도시에 집중되어 있는 문제도 있었고, 비인기 도시는 테마가 존재하지 않은 경우도 많았어요. 하나의 테마를 만드는데 20–30분 정도 소요됩니다.”이러한 수동 작업의 한계로 인해 비인기 도시에는 테마가 거의 존재하지 않았습니다. 많은 시간이 소요되는 작업이다 보니 자연스럽게 인기 있는 도시의 테마 제작에 자원이 집중될 수밖에 없었죠.테마가가 거의 없는 도시들AI에게 테마를 맡기다: 자동화의 첫걸음FTN팀 백엔드 엔지니어인 백승빈님은 사업실의 이런 어려움을 듣고 AI 를 활용해서 문제를 해결해 보기로 했어요. 곧 AI를 활용한 테마 생성 자동화를 시도한 거죠. 일단 테마를 만들기 위해서는 두 가지 핵심 요소가 필요했어요.“테마를 만들기 위해서는 한 테마로 묶을 상품들의 조건(어떤 상품들을 대상으로 할지)과 테마명(어떤 설명으로 소구할지) 이 두 가지가 필요했습니다.”조건은 앱 메인 화면의 3x3 그리드에 나타나는 상품들을 활용했고, 테마명은 AI를 통해 작성했습니다. AI에게 어떻게 테마명을 요청했을까요?초기 결과는 괜찮은듯 했으나, 곧 한 가지 문제점이 발견됐습니다. AI가 생성한 테마명들이 너무 비슷한 패턴을 보이면서 각 테마의 특색이 드러나지 않았어요. 특히 대부분의 테마가 도시 이름으로 시작하는 획일적인 형태를 보였죠.“그라나다 지역의 테마들의 타이틀은 모두 ‘그라나다’로 시작하거나 발리의 테마들도 모두 ‘발리’ 가 들어갔어요. 그러니 각 테마의 특성이 살지 않고 너무 획일적인 느낌이 들었죠.”이 문제를 해결하기 위해 프롬프트를 개선했습니다. 기존의 입력에 두 가지 중요한 조건을 추가했어요. 기존에 만들어진 테마명을 맥락으로 전달하면서, 기존 테마명과 다르게 생성해달라고 시스템 프롬프트를 추가한거죠.하루 만에 1353개 테마: 450시간의 작업을 단축한 AI의 힘프롬프트 개선 후, AI는 훨씬 더 다양하고 특색 있는 테마명을 생성하기 시작했습니다. 단순히 프롬프트 몇 줄을 추가했을 뿐인데, 결과물의 품질이 크게 향상된 것이죠.시스템 프롬프트 개선 전과 후의 차이점“변경 전과 변경 후를 비교해보면 왼쪽은 다 발리로 시작하고 비슷해 보이지만 오른쪽은 특색 있게 바뀌어 상품들을 소개하는 데 더 적합합니다.”AI 호출 결과“387개의 도시에서
2025.06.01

좋아요

별로에요

OpenSearch의 하이브리드 검색 소개
에이닷 오토는 RAG(Retrieval-Augmented Generation) 기반 서비스를 통해 고객에게 더 정확하고 상황 인지형 답변을 제공할 예정입니다.RAG 시스템의 핵심은 사용자 질문의 의도를 정확히 이해하고, 이에 맞는 컨텍스트를 신속하게 검색하는 데 있습니다.하지만 초기 테스트에서 키워드 검색만으로는 “ELF-7W30” 같은 전문 용어 외에 “겨울용 오일” 같은 일상적 표현을 포착하지 못하는 한계가 있었고,의미 기반 검색은 “TPMS 경고등” 같은 정형화된 키워드 매칭에서 누락을 일으켰습니다.자동차 정비라는 도메인의 특수성상, 두 검색 방식을 유기적으로 결합한 전략이 필수적이었습니다.이러한 요구사항을 해결하기 위해 OpenSearch의 하이브리드 검색을 도입했습니다. 하이브리드 검색은 키워드 검색의 정밀도와 의미 검색의 맥락 이해력을 하나의 파이프라인에서 통합합니다.예를 들어 “배터리 수명”이라는 질문에는 정확한 매뉴얼 항목을, “차에서 끼릭거리는 소리가 나요”에는 구동축 베어링 마모 관련 진단 가이드를 동시에 추출합니다.이는 단일 검색 방식으로는 달성하기 어려운 수준의 종합적 결과입니다.OpenSearch는 이러한 하이브리드 검색을 구현하기에 가장 적합한 솔루션으로, 신경망 기반 의미 분석과 BM25 알고리즘을 실시간으로 병행 실행합니다.점수 정규화 기술을 통해 서로 다른 검색 결과의 신뢰도를 공정하게 평가하고, 자동차 정비 매뉴얼, 부품 코드, 고객 문의 기록 등 반정형 데이터를 JSON 기반으로 유연하게 관리할 수 있습니다.Amazon이 주도하는 오픈소스 프로젝트인 점도 중요한 선택 이유였는데,Apache 2.0 라이선스로 상용 제약 없이 AWS 인프라와의 긴밀한 연동이 가능했으며, RBAC 기반 보안과 Dashboards 모니터링으로 안정성을 확보할 수 있었습니다.이제 본론에서는 OpenSearch 환경에서 키워드, 시맨틱, 하이브리드 검색을 실제로 구현하고 성능을 비교 평가했던 구체적인 과정을 단계별로 설명드리겠습니다.OpenSearch는 Splunk, Elasticsearch, Graylog 등과 같은 대표적인 로그 모니터링 및 검색 솔루션들과 다음과 같은 차별점을 보입니다.• None 오픈소스와 비용: OpenSearch는 완전 오픈소스이며, 커뮤니티 주도로 발전하고 있어 라이선스 비용 부담이 없습니다. Splunk는 상용 제품으로, 데이터 볼륨에 따라 비용이 크게 증가할 수 있습니다.• None 검색 방식의 다양성: OpenSearch는 키워드(BM25), 시맨틱(벡터), 하이브리드 검색을 모두 지원합니다. 특히 시맨틱·하이브리드 검색은 최근 AI 기반 검색 수요에 부합하는 강점입니다.• None 운영의 유연성: 자체 구축, 클라우드, AWS 관리형 서비스 등 다양한 운영 방식을 지원합니다.• None 보안 및 확장성: RBAC, 암호화, 감사 로그 등 엔터프라이즈급 보안 기능을 기본 제공하며, 다양한 플러그인으로 확장성이 높습니다.OpenSearch의 검색 방식인 키워드, 시맨틱, 하이브리드 검색에 대해 간단히 설명 드리겠습니다.• None 키워드 검색: BM25 알고리즘 기반으로, 입력된 키워드와 문서 내 용어 빈도 및 길이 등을 고려해 연관성 점수를 산출합니다. 전통적인 로그 검색, 모니터링에 적합합니다.• None 시맨틱(의미 기반) 검색: 텍스트 임베딩 모델(딥러닝 기반)을 활용해 쿼리와 문서를 벡터로 변환, 의미적 유사성을 기준으로 검색합니다. 자연어 질의, 유사 문서 추천 등에서 뛰어난 성능을 보입니다.• None 하이브리드 검색: 키워드와 시맨틱 검색 결과를 결합해 검색 정확도와 관련성을 더욱 높입니다. 예를 들어, BM25 점수와 벡터 유사도 점수를 정규화·가중평균하여 최종 결과를 산출합니다.SIEM·IT 운영 등 특화된 엔터프라이즈 기능이 필요하다면 Splunk와 ElasticSearch 같은 상용 솔루션이 적합할 수 있습니다.하지만 OpenSearch는 오픈소스 기반의 강력한 검색 및 로그 분석 솔루션으로, 키워드, 시맨틱, 하이브리드 등 다양한 검색 방식을 지원하며,AWS 관리형 서비스와의 연계, 높은 확장성, 엔터프라이즈급 보안 기능 등에서 차별화된 강점을 갖고 있습니다.따라서 비용 효율성과 최신 AI 검색, 커스터마이징이 중요하다면 OpenSearch가 매우 매력적인 선택이 될 수 있습니다.위 사이트에서는 간단하게 OpenSearch를 시작할 수 있도록 docker-compose 파일을 제공하고 있습니다.로컬에서 OpenSearch를 사용하기 위해서는 몇가지 수정사항이 있습니다.• None OpenSearch 설치 버전을 환경변수값으로 설정할수 있도록 수정합니다. image: opensearchproject/opensearch:latest # 이 값을 image: opensearchproject/opensearch:${OPENSEARCH_VERSION} # 이 값으로 수정 image: opensearchproject/opensearch-dashboards:latest # 이 값을 image: opensearchproject/opensearch-dashboards:${OPENSEARCH_VERSION} # 이 값으로 수정• None Local 환경에서는 OpenSearch API 등록시 Https 통신이 지원되지 않을 수 있기 때문에 아래 환경 변수들을 추가해 줍니다. environment: # OPENSEARCH_HOSTS들을 https에서 http로 수정 OPENSEARCH_HOSTS: '["http://opensearch-node1:9200","http://opensearch-node2:9200"]' DISABLE_SECURITY_DASHBOARDS_PLUGIN: true # 추가• None 이제 해당 docker-compose.yml파일과 동일 디렉토리 내에 .env 파일을 생성해서 아래와 같이 변수를 정의합니다. 여기에서 비밀번호를 충분히 복잡하게 정의해주지 않으면 "[ConnectionError]: getaddrinfo ENOTFOUND opensearch-node1" 에러가 발생할 수 있으니 주의합니다.•
docker
python
5/30/2025

OpenSearch의 하이브리드 검색 소개
에이닷 오토는 RAG(Retrieval-Augmented Generation) 기반 서비스를 통해 고객에게 더 정확하고 상황 인지형 답변을 제공할 예정입니다.RAG 시스템의 핵심은 사용자 질문의 의도를 정확히 이해하고, 이에 맞는 컨텍스트를 신속하게 검색하는 데 있습니다.하지만 초기 테스트에서 키워드 검색만으로는 “ELF-7W30” 같은 전문 용어 외에 “겨울용 오일” 같은 일상적 표현을 포착하지 못하는 한계가 있었고,의미 기반 검색은 “TPMS 경고등” 같은 정형화된 키워드 매칭에서 누락을 일으켰습니다.자동차 정비라는 도메인의 특수성상, 두 검색 방식을 유기적으로 결합한 전략이 필수적이었습니다.이러한 요구사항을 해결하기 위해 OpenSearch의 하이브리드 검색을 도입했습니다. 하이브리드 검색은 키워드 검색의 정밀도와 의미 검색의 맥락 이해력을 하나의 파이프라인에서 통합합니다.예를 들어 “배터리 수명”이라는 질문에는 정확한 매뉴얼 항목을, “차에서 끼릭거리는 소리가 나요”에는 구동축 베어링 마모 관련 진단 가이드를 동시에 추출합니다.이는 단일 검색 방식으로는 달성하기 어려운 수준의 종합적 결과입니다.OpenSearch는 이러한 하이브리드 검색을 구현하기에 가장 적합한 솔루션으로, 신경망 기반 의미 분석과 BM25 알고리즘을 실시간으로 병행 실행합니다.점수 정규화 기술을 통해 서로 다른 검색 결과의 신뢰도를 공정하게 평가하고, 자동차 정비 매뉴얼, 부품 코드, 고객 문의 기록 등 반정형 데이터를 JSON 기반으로 유연하게 관리할 수 있습니다.Amazon이 주도하는 오픈소스 프로젝트인 점도 중요한 선택 이유였는데,Apache 2.0 라이선스로 상용 제약 없이 AWS 인프라와의 긴밀한 연동이 가능했으며, RBAC 기반 보안과 Dashboards 모니터링으로 안정성을 확보할 수 있었습니다.이제 본론에서는 OpenSearch 환경에서 키워드, 시맨틱, 하이브리드 검색을 실제로 구현하고 성능을 비교 평가했던 구체적인 과정을 단계별로 설명드리겠습니다.OpenSearch는 Splunk, Elasticsearch, Graylog 등과 같은 대표적인 로그 모니터링 및 검색 솔루션들과 다음과 같은 차별점을 보입니다.• None 오픈소스와 비용: OpenSearch는 완전 오픈소스이며, 커뮤니티 주도로 발전하고 있어 라이선스 비용 부담이 없습니다. Splunk는 상용 제품으로, 데이터 볼륨에 따라 비용이 크게 증가할 수 있습니다.• None 검색 방식의 다양성: OpenSearch는 키워드(BM25), 시맨틱(벡터), 하이브리드 검색을 모두 지원합니다. 특히 시맨틱·하이브리드 검색은 최근 AI 기반 검색 수요에 부합하는 강점입니다.• None 운영의 유연성: 자체 구축, 클라우드, AWS 관리형 서비스 등 다양한 운영 방식을 지원합니다.• None 보안 및 확장성: RBAC, 암호화, 감사 로그 등 엔터프라이즈급 보안 기능을 기본 제공하며, 다양한 플러그인으로 확장성이 높습니다.OpenSearch의 검색 방식인 키워드, 시맨틱, 하이브리드 검색에 대해 간단히 설명 드리겠습니다.• None 키워드 검색: BM25 알고리즘 기반으로, 입력된 키워드와 문서 내 용어 빈도 및 길이 등을 고려해 연관성 점수를 산출합니다. 전통적인 로그 검색, 모니터링에 적합합니다.• None 시맨틱(의미 기반) 검색: 텍스트 임베딩 모델(딥러닝 기반)을 활용해 쿼리와 문서를 벡터로 변환, 의미적 유사성을 기준으로 검색합니다. 자연어 질의, 유사 문서 추천 등에서 뛰어난 성능을 보입니다.• None 하이브리드 검색: 키워드와 시맨틱 검색 결과를 결합해 검색 정확도와 관련성을 더욱 높입니다. 예를 들어, BM25 점수와 벡터 유사도 점수를 정규화·가중평균하여 최종 결과를 산출합니다.SIEM·IT 운영 등 특화된 엔터프라이즈 기능이 필요하다면 Splunk와 ElasticSearch 같은 상용 솔루션이 적합할 수 있습니다.하지만 OpenSearch는 오픈소스 기반의 강력한 검색 및 로그 분석 솔루션으로, 키워드, 시맨틱, 하이브리드 등 다양한 검색 방식을 지원하며,AWS 관리형 서비스와의 연계, 높은 확장성, 엔터프라이즈급 보안 기능 등에서 차별화된 강점을 갖고 있습니다.따라서 비용 효율성과 최신 AI 검색, 커스터마이징이 중요하다면 OpenSearch가 매우 매력적인 선택이 될 수 있습니다.위 사이트에서는 간단하게 OpenSearch를 시작할 수 있도록 docker-compose 파일을 제공하고 있습니다.로컬에서 OpenSearch를 사용하기 위해서는 몇가지 수정사항이 있습니다.• None OpenSearch 설치 버전을 환경변수값으로 설정할수 있도록 수정합니다. image: opensearchproject/opensearch:latest # 이 값을 image: opensearchproject/opensearch:${OPENSEARCH_VERSION} # 이 값으로 수정 image: opensearchproject/opensearch-dashboards:latest # 이 값을 image: opensearchproject/opensearch-dashboards:${OPENSEARCH_VERSION} # 이 값으로 수정• None Local 환경에서는 OpenSearch API 등록시 Https 통신이 지원되지 않을 수 있기 때문에 아래 환경 변수들을 추가해 줍니다. environment: # OPENSEARCH_HOSTS들을 https에서 http로 수정 OPENSEARCH_HOSTS: '["http://opensearch-node1:9200","http://opensearch-node2:9200"]' DISABLE_SECURITY_DASHBOARDS_PLUGIN: true # 추가• None 이제 해당 docker-compose.yml파일과 동일 디렉토리 내에 .env 파일을 생성해서 아래와 같이 변수를 정의합니다. 여기에서 비밀번호를 충분히 복잡하게 정의해주지 않으면 "[ConnectionError]: getaddrinfo ENOTFOUND opensearch-node1" 에러가 발생할 수 있으니 주의합니다.•
2025.05.30
docker
python

좋아요

별로에요

복잡한 회원 인증 프로세스, 기본 원칙만 알면 쉽습니다
'인증'이란 단어는 듣기만 해도 복잡해 보이고, 완벽해야만 할 것 같아 무섭게 느껴지곤 하죠.네. 실제로도 그렇습니다. 인증 시스템이 허술하면 전체 프로덕트의 신뢰가 무너지고, 부정 사용자가 급증해 운영이 엉망진창이 되어버리니까요.하지만 이런 복잡해 보이는 인증도 기본 원칙만 잘 알고 있다면 전혀 두려울 게 없습니다.소개가 늦었습니다. 안녕하세요. 저는 ABC Studio에서 기획을 담당하고 있는 천재연입니다. 현재 일본 최대 규모의 배달 서비스인 데마에칸(Demaecan, 出前館)에서 기획 업무를 담당하고 있습니다. 지금까지 여러 프로덕트의 회원 인증 프로세스 구축과 KYC(Know Your Customer의 약자로 금융 기관의 고객 확인 제도를 의미) 전반에 대한 작업을 담당해 왔습니다.통상 회원 인증은 서비스에 접근하려는 사용자의 신원을 확인하는 모든 과정을 일컫는데요. 이번 글에서는 단순 ID/PW를 이용한 지식 기반 인증 이외에 회원의 유효성을 확인할 수 있는 식별 장치 위주로 서술해 보고자 합니다.너무 뻔한 이야기지만, 그만큼 중요하기 때문에 한 번 짚고 넘어가겠습니다. 어떤 서비스를 만들던 회원 가입과 인증 시스템은 항상 필요합니다(그만큼 한 번 개념을 잘 잡아두면 계속 써먹기 좋다는 의미겠죠?).너무나도 기본적인 요소이기에 별달리 특별할 것도 없어 보이지만, 그 어떤 것보다 신중하게 접근하고 설계해야 하는 영역이라고 생각합니다. 가입 및 인증의 영역은 서비스를 처음 시작할 때부터 적용할 수밖에 없고, 누적된 사용자가 많아질수록 잘못된 것을 바로잡기 어려워지기 때문입니다.신규 프로젝트에서 본격적인 인증 시스템을 도입하기가 부담스러워 일단 건너뛰었다가 뒤늦게 도입하는 과정에서 머리 아파하는 사례를 종종 보곤 합니다. 이런 경우 필연적으로 아래와 같은 케이스 때문에 머리가 아파집니다.• 케이스 1: 이미 등록된 회원의 정보가 실제 존재하지 않는 정보이다.• 예를 들어, 휴대폰 번호 '010-1234-5678'와 같은 경우가 여기에 해당합니다. 유령 회원인 경우가 많으며, 회사에서 연락을 취하고 싶어도 취할 수가 없습니다. 즉, 회원 정보를 임의로 변경할 수 없는 환경에서는 이런 회원은 영영 골치 아픈 엣지 케이스로 남게 됩니다.• 케이스 2: 입력한 정보가 타인의 정보라서 신규 사용자의 가입에 방해가 된다.• 이 경우 신규 사용자가 해당 정보가 본인의 정보임을 증명하는 과정이 길어지면서 중간에 이탈할 가능성이 높아질 수밖에 없습니다.• 케이스 3 : 회원 식별이 필요한 순간에 활용할 수 있는 인증 정보가 전혀 없다.• 쿠폰 이벤트와 같은 마케팅을 진행할 때 부정 사용자를 방지하기 위한 회원 식별은 필수입니다. 이때 활용할 수 있는 정보가 없다면 사용자가 제출한 정보가 사실인지 비교할 수 없으며, 이로 인해 인증 정보를 추가로 받아야 하는 부담이 커집니다.따라서 신규 프로젝트를 담당하는 기획자라면 본인의 서비스가 어느 정도 수준의 인증이 필요할지 설계 단계에서부터 충분히 논의하고 고민해야 합니다.국내와 해외의 회원 인증 방식은 어떻게 다를까?최근에는 프로젝트 규모를 키우고자 해외 서비스로 확장하거나 또는 애초에 해외에서 첫 서비스 오픈을 시도하는 서비스들이 자주 보이고 있습니다. 저도 데마에칸을 담당하면서 처음으로 해외 서비스 기획을 경험해 봤는데요. 회원 인증 방식에서 국내 서비스와 확실히 차이가 있다는 것을 알 수 있었습니다. 제 경험을 바탕으로 국내 서비스와 해외 서비스의 인증 방식이 어떻게 다른지 소개하겠습니다.국내 프로덕트에 적용되는 인증은 크게 다음 세 가지로 구분할 수 있습니다. 각각을 대표적인 예시와 함께 살펴보겠습니다.• 점유 인증: 해당 정보를 실제로 소유하고 있는지 확인하는 방식의 인증입니다.• 이메일 인증: 대표적으로 널리 쓰이는 점유 인증 중 하나로, 인증 번호를 메일로 받아 입력합니다. 이를 통해 이 메일은 내가 점유(소유)하고 있다는 것을 인증할 수 있습니다.• 실명 인증: 이름과 주민등록번호(또는 그에 준하는 개인 식별 정보)를 이용해 개인이 실제로 존재하는지 확인하는 방식의 인증입니다.• 국가 시스템: 사용자가 특정 복지 혜택의 대상자인지 조회할 때 사용되는 것을 본 적이 있습니다. 단순히 이름과 주민등록번호를 입력해 인증하며, 별도로 인증 번호를 받아 증명하는 과정은 없습니다.• 본인 인증: 점유 인증과 실명 인증을 합쳐둔 것이라고 이해하면 쉽습니다. 굉장히 많은 방식이 있으며, 계속 다양해지고 있습니다. 각 인증별로 커버할 수 있는 범위가 다르다 보니 여러 인증을 함께 진행하는 경우가 꽤 있습니다.• 휴대폰 본인 인증: 가장 대표적인 방식으로, 통신사의 고객 정보에 기대서 인증을 하는 방식입니다(예를 들어 PASS 앱). 사용자가 입력한 성명, 전화번호, 주민등록번호가 통신사의 고객 정보와 모두 일치해야 인증이 진행될 수 있습니다.• 1원 인증: 금융 기관에서 본인 계좌를 인증하는 용도로 사용됩니다. 본인 계좌 번호를 입력하는 과정을 통해 실명 인증이 진행되고, 1원을 받아서 인증 코드를 입력하는 과정을 통해 점유 인증이 진행됩니다.• 안면 인증: 실물 신분증 촬영 후 사용자의 얼굴을 촬영합니다. 두 얼굴이 일치한다면 본인으로 판정하는 방식입니다.• SNS 인증: 많이들 사용하시는 네이버 인증이 여기에 속합니다. 위에 서술한 여러 방법으로 이미 본인 인증을 마친 계정에 기대어 간단한 인증 번호 입력만으로도 본인 인증을 할 수 있는 간편한 방법입니다.여기서 사용된 인증은 어떤 인증일까요?정답은 점유 인증입니다. 휴대폰을 활용했기 때문에 본인 인증으로 헷갈릴 수 있지만, 주민등록번호와 같은 개인 식별 정보를 활용하지 않았기 때문에 점유 인증에 해당됩니다. 이와 같이 인증에는 방식이 유사한 것들이 굉장히 많기 때문에 항상 인증의 원리를 이해해 어떤 방식의 인증인지 파악해야 합니다.이렇게 다양한 인증의 특성을 파악하며 어느 것을 도입할지 고려할 때 반드시 함께 챙겨 주셔야 할 한 가지가 있습니다. 바로 인증 정보의 만료 기한입니다.금융 앱을 사용하다 보면 이따금씩 '고객 정보 재확인'이란 문구를 보신 적이 있으실 겁니다. 높은 보안 수
5/30/2025

복잡한 회원 인증 프로세스, 기본 원칙만 알면 쉽습니다
'인증'이란 단어는 듣기만 해도 복잡해 보이고, 완벽해야만 할 것 같아 무섭게 느껴지곤 하죠.네. 실제로도 그렇습니다. 인증 시스템이 허술하면 전체 프로덕트의 신뢰가 무너지고, 부정 사용자가 급증해 운영이 엉망진창이 되어버리니까요.하지만 이런 복잡해 보이는 인증도 기본 원칙만 잘 알고 있다면 전혀 두려울 게 없습니다.소개가 늦었습니다. 안녕하세요. 저는 ABC Studio에서 기획을 담당하고 있는 천재연입니다. 현재 일본 최대 규모의 배달 서비스인 데마에칸(Demaecan, 出前館)에서 기획 업무를 담당하고 있습니다. 지금까지 여러 프로덕트의 회원 인증 프로세스 구축과 KYC(Know Your Customer의 약자로 금융 기관의 고객 확인 제도를 의미) 전반에 대한 작업을 담당해 왔습니다.통상 회원 인증은 서비스에 접근하려는 사용자의 신원을 확인하는 모든 과정을 일컫는데요. 이번 글에서는 단순 ID/PW를 이용한 지식 기반 인증 이외에 회원의 유효성을 확인할 수 있는 식별 장치 위주로 서술해 보고자 합니다.너무 뻔한 이야기지만, 그만큼 중요하기 때문에 한 번 짚고 넘어가겠습니다. 어떤 서비스를 만들던 회원 가입과 인증 시스템은 항상 필요합니다(그만큼 한 번 개념을 잘 잡아두면 계속 써먹기 좋다는 의미겠죠?).너무나도 기본적인 요소이기에 별달리 특별할 것도 없어 보이지만, 그 어떤 것보다 신중하게 접근하고 설계해야 하는 영역이라고 생각합니다. 가입 및 인증의 영역은 서비스를 처음 시작할 때부터 적용할 수밖에 없고, 누적된 사용자가 많아질수록 잘못된 것을 바로잡기 어려워지기 때문입니다.신규 프로젝트에서 본격적인 인증 시스템을 도입하기가 부담스러워 일단 건너뛰었다가 뒤늦게 도입하는 과정에서 머리 아파하는 사례를 종종 보곤 합니다. 이런 경우 필연적으로 아래와 같은 케이스 때문에 머리가 아파집니다.• 케이스 1: 이미 등록된 회원의 정보가 실제 존재하지 않는 정보이다.• 예를 들어, 휴대폰 번호 '010-1234-5678'와 같은 경우가 여기에 해당합니다. 유령 회원인 경우가 많으며, 회사에서 연락을 취하고 싶어도 취할 수가 없습니다. 즉, 회원 정보를 임의로 변경할 수 없는 환경에서는 이런 회원은 영영 골치 아픈 엣지 케이스로 남게 됩니다.• 케이스 2: 입력한 정보가 타인의 정보라서 신규 사용자의 가입에 방해가 된다.• 이 경우 신규 사용자가 해당 정보가 본인의 정보임을 증명하는 과정이 길어지면서 중간에 이탈할 가능성이 높아질 수밖에 없습니다.• 케이스 3 : 회원 식별이 필요한 순간에 활용할 수 있는 인증 정보가 전혀 없다.• 쿠폰 이벤트와 같은 마케팅을 진행할 때 부정 사용자를 방지하기 위한 회원 식별은 필수입니다. 이때 활용할 수 있는 정보가 없다면 사용자가 제출한 정보가 사실인지 비교할 수 없으며, 이로 인해 인증 정보를 추가로 받아야 하는 부담이 커집니다.따라서 신규 프로젝트를 담당하는 기획자라면 본인의 서비스가 어느 정도 수준의 인증이 필요할지 설계 단계에서부터 충분히 논의하고 고민해야 합니다.국내와 해외의 회원 인증 방식은 어떻게 다를까?최근에는 프로젝트 규모를 키우고자 해외 서비스로 확장하거나 또는 애초에 해외에서 첫 서비스 오픈을 시도하는 서비스들이 자주 보이고 있습니다. 저도 데마에칸을 담당하면서 처음으로 해외 서비스 기획을 경험해 봤는데요. 회원 인증 방식에서 국내 서비스와 확실히 차이가 있다는 것을 알 수 있었습니다. 제 경험을 바탕으로 국내 서비스와 해외 서비스의 인증 방식이 어떻게 다른지 소개하겠습니다.국내 프로덕트에 적용되는 인증은 크게 다음 세 가지로 구분할 수 있습니다. 각각을 대표적인 예시와 함께 살펴보겠습니다.• 점유 인증: 해당 정보를 실제로 소유하고 있는지 확인하는 방식의 인증입니다.• 이메일 인증: 대표적으로 널리 쓰이는 점유 인증 중 하나로, 인증 번호를 메일로 받아 입력합니다. 이를 통해 이 메일은 내가 점유(소유)하고 있다는 것을 인증할 수 있습니다.• 실명 인증: 이름과 주민등록번호(또는 그에 준하는 개인 식별 정보)를 이용해 개인이 실제로 존재하는지 확인하는 방식의 인증입니다.• 국가 시스템: 사용자가 특정 복지 혜택의 대상자인지 조회할 때 사용되는 것을 본 적이 있습니다. 단순히 이름과 주민등록번호를 입력해 인증하며, 별도로 인증 번호를 받아 증명하는 과정은 없습니다.• 본인 인증: 점유 인증과 실명 인증을 합쳐둔 것이라고 이해하면 쉽습니다. 굉장히 많은 방식이 있으며, 계속 다양해지고 있습니다. 각 인증별로 커버할 수 있는 범위가 다르다 보니 여러 인증을 함께 진행하는 경우가 꽤 있습니다.• 휴대폰 본인 인증: 가장 대표적인 방식으로, 통신사의 고객 정보에 기대서 인증을 하는 방식입니다(예를 들어 PASS 앱). 사용자가 입력한 성명, 전화번호, 주민등록번호가 통신사의 고객 정보와 모두 일치해야 인증이 진행될 수 있습니다.• 1원 인증: 금융 기관에서 본인 계좌를 인증하는 용도로 사용됩니다. 본인 계좌 번호를 입력하는 과정을 통해 실명 인증이 진행되고, 1원을 받아서 인증 코드를 입력하는 과정을 통해 점유 인증이 진행됩니다.• 안면 인증: 실물 신분증 촬영 후 사용자의 얼굴을 촬영합니다. 두 얼굴이 일치한다면 본인으로 판정하는 방식입니다.• SNS 인증: 많이들 사용하시는 네이버 인증이 여기에 속합니다. 위에 서술한 여러 방법으로 이미 본인 인증을 마친 계정에 기대어 간단한 인증 번호 입력만으로도 본인 인증을 할 수 있는 간편한 방법입니다.여기서 사용된 인증은 어떤 인증일까요?정답은 점유 인증입니다. 휴대폰을 활용했기 때문에 본인 인증으로 헷갈릴 수 있지만, 주민등록번호와 같은 개인 식별 정보를 활용하지 않았기 때문에 점유 인증에 해당됩니다. 이와 같이 인증에는 방식이 유사한 것들이 굉장히 많기 때문에 항상 인증의 원리를 이해해 어떤 방식의 인증인지 파악해야 합니다.이렇게 다양한 인증의 특성을 파악하며 어느 것을 도입할지 고려할 때 반드시 함께 챙겨 주셔야 할 한 가지가 있습니다. 바로 인증 정보의 만료 기한입니다.금융 앱을 사용하다 보면 이따금씩 '고객 정보 재확인'이란 문구를 보신 적이 있으실 겁니다. 높은 보안 수
2025.05.30

좋아요

별로에요

맥주 한잔하면서 이야기하실래요?
여기어때 컬처 라운지 ep. 7“소통 맥주 하러 갈까요?”여기어때 사무실에서 자주 들을 수 있는 이 말, 과연 무슨 뜻일까요?정답 : “지하 라운지에서 스낵과 맥주 한잔 하면서 편하게 이야기 나누실래요?” 입니다. 😊설레는 금요일 오후, 여러분은 어떤 모습으로 한 주를 마무리 하시나요?여기어때에서는 매주 금요일 오후 4시만 되면 지하 1층 라운지가 평소보다 더욱 활기찬 에너지로 가득 차기 시작해요. 바로 여기어때만의 특별한 소통 문화, ‘소통 맥주’ 시간이 찾아오기 때문인데요. 오늘은 여기어때의 즐거운 소통 프로그램, ‘소통 맥주’와 월말 특별한 ‘피맥데이’ 이야기를 들려드릴게요!💬 소통, 가장 중요한 ‘일’ 중 하나라고 믿기에정해진 업무와 회의를 통한 협업도 물론 중요하지만, 때로는 업무 공간을 벗어나 편안한 분위기에서 나누는 소소한 대화가 예상치 못한 시너지를 만들기도 합니다. 시원한 맥주와 간식을 함께 먹으며 한 주를 마무리하고, 일상을 공유하는 시간. 이런 자연스러운 교류 속에서 서로에 대한 이해는 깊어지고, 또 미처 발견하지 못했던 새로운 협업 시너지를 발견하기도 한답니다.여기어때의 ‘소통맥주’는 바로 이러한 믿음에서 출발했어요. 우리 팀 동료들뿐만 아니라, 평소 마주칠 기회가 적었던 다른 팀의 동료들, 혹은 같은 날 입사한 동기들과도 자유롭게 어울려 이야기를 나눌 수 있도록 매주 금요일 오후 4시부터 7시까지를 ‘소통맥주’ 시간으로 운영하고 있습니다. 이름에서도 알 수 있듯이, ‘소통맥주’는 단순히 맥주를 마시는 시간을 넘어, 동료들과 소통하며 즐기는 소중한 시간인거죠!🍻 소통맥주 즐기는 법소통맥주는 매주 금요일마다 여기어때 지하 1층 라운지에서 진행해요. 오후 4시부터 7시까지 자율적으로 운영하고 있어, 언제든 원할 때 내려와 즐길 수 있답니다.언제, 어디서 하나요? 매주 금요일 오후 4시부터 7시까지, 지하 1층 라운지에서무엇이 제공되나요? 시원한 맥주와 와인, 취향 따라 골라 먹는 다양한 스낵이 준비되어 있어요. (매월 마지막 주는 피자도 함께랍니다🍕😋)누구와, 어떻게 즐기나요? 팀 동료들과, 혹은 평소에 마주치기 어려웠던 다른 팀 동료들, 원하는 누구든 자유롭게 어울려 이야기를 나눌 수 있습니다.이처럼 자유롭고 즐거운 소통맥주가 오랫동안 사랑받는 프로그램으로 자리 잡을 수 있었던 데에는 보이지 않는 노력과 배려가 숨어있답니다. 모두가 함께 편안하고 즐거운 시간을 보낼 수 있도록, 몇 가지 약속을 함께 만들어가고 있습니다.첫째, 뒷정리는 깔끔하게! 사용한 테이블은 다음 동료를 위해 깨끗하게 정돈하고, 쓰레기는 꼼꼼히 분리수거합니다.둘째, 음식은 라운지에서만! 맛있는 맥주와 스낵은 소통맥주가 진행되는 라운지 안에서 충분히 즐기고, 업무 공간으로는 가져가지 않는 센스를 발휘합니다.셋째, 대화는 유쾌하게, 음주는 가볍게! 무엇보다 서로의 이야기에 귀 기울이며 즐겁게 대화하는 것이 중요하기에, 과음보다는 가볍게 즐기는 건강한 문화를 함께 만들어가고 있습니다.이러한 작은 약속들이 모여 여기어때만의 건강하고 즐거운 소통맥주 문화를
5/30/2025

맥주 한잔하면서 이야기하실래요?
여기어때 컬처 라운지 ep. 7“소통 맥주 하러 갈까요?”여기어때 사무실에서 자주 들을 수 있는 이 말, 과연 무슨 뜻일까요?정답 : “지하 라운지에서 스낵과 맥주 한잔 하면서 편하게 이야기 나누실래요?” 입니다. 😊설레는 금요일 오후, 여러분은 어떤 모습으로 한 주를 마무리 하시나요?여기어때에서는 매주 금요일 오후 4시만 되면 지하 1층 라운지가 평소보다 더욱 활기찬 에너지로 가득 차기 시작해요. 바로 여기어때만의 특별한 소통 문화, ‘소통 맥주’ 시간이 찾아오기 때문인데요. 오늘은 여기어때의 즐거운 소통 프로그램, ‘소통 맥주’와 월말 특별한 ‘피맥데이’ 이야기를 들려드릴게요!💬 소통, 가장 중요한 ‘일’ 중 하나라고 믿기에정해진 업무와 회의를 통한 협업도 물론 중요하지만, 때로는 업무 공간을 벗어나 편안한 분위기에서 나누는 소소한 대화가 예상치 못한 시너지를 만들기도 합니다. 시원한 맥주와 간식을 함께 먹으며 한 주를 마무리하고, 일상을 공유하는 시간. 이런 자연스러운 교류 속에서 서로에 대한 이해는 깊어지고, 또 미처 발견하지 못했던 새로운 협업 시너지를 발견하기도 한답니다.여기어때의 ‘소통맥주’는 바로 이러한 믿음에서 출발했어요. 우리 팀 동료들뿐만 아니라, 평소 마주칠 기회가 적었던 다른 팀의 동료들, 혹은 같은 날 입사한 동기들과도 자유롭게 어울려 이야기를 나눌 수 있도록 매주 금요일 오후 4시부터 7시까지를 ‘소통맥주’ 시간으로 운영하고 있습니다. 이름에서도 알 수 있듯이, ‘소통맥주’는 단순히 맥주를 마시는 시간을 넘어, 동료들과 소통하며 즐기는 소중한 시간인거죠!🍻 소통맥주 즐기는 법소통맥주는 매주 금요일마다 여기어때 지하 1층 라운지에서 진행해요. 오후 4시부터 7시까지 자율적으로 운영하고 있어, 언제든 원할 때 내려와 즐길 수 있답니다.언제, 어디서 하나요? 매주 금요일 오후 4시부터 7시까지, 지하 1층 라운지에서무엇이 제공되나요? 시원한 맥주와 와인, 취향 따라 골라 먹는 다양한 스낵이 준비되어 있어요. (매월 마지막 주는 피자도 함께랍니다🍕😋)누구와, 어떻게 즐기나요? 팀 동료들과, 혹은 평소에 마주치기 어려웠던 다른 팀 동료들, 원하는 누구든 자유롭게 어울려 이야기를 나눌 수 있습니다.이처럼 자유롭고 즐거운 소통맥주가 오랫동안 사랑받는 프로그램으로 자리 잡을 수 있었던 데에는 보이지 않는 노력과 배려가 숨어있답니다. 모두가 함께 편안하고 즐거운 시간을 보낼 수 있도록, 몇 가지 약속을 함께 만들어가고 있습니다.첫째, 뒷정리는 깔끔하게! 사용한 테이블은 다음 동료를 위해 깨끗하게 정돈하고, 쓰레기는 꼼꼼히 분리수거합니다.둘째, 음식은 라운지에서만! 맛있는 맥주와 스낵은 소통맥주가 진행되는 라운지 안에서 충분히 즐기고, 업무 공간으로는 가져가지 않는 센스를 발휘합니다.셋째, 대화는 유쾌하게, 음주는 가볍게! 무엇보다 서로의 이야기에 귀 기울이며 즐겁게 대화하는 것이 중요하기에, 과음보다는 가볍게 즐기는 건강한 문화를 함께 만들어가고 있습니다.이러한 작은 약속들이 모여 여기어때만의 건강하고 즐거운 소통맥주 문화를
2025.05.30

좋아요

별로에요

몰입의 시작을 만드는 그래픽 | Simplicity 4 제작기 #4
안녕하세요, Simplicity 4에서 그래픽 디자인을 맡은 Graphic Designer 김경태, 김영하입니다.이번 심플리시티 시즌4의 그래픽 제작을 진행하면서 느낀 고민과 경험들을 제작기를 통해 공유하고자 해요.여러분은 유튜브에서 영상을 볼 때 어떤 기준으로 선택하시나요? 아마 많은 분들이 썸네일을 보고 ‘볼지 말지’를 결정하실 거예요.Simplicity도 마찬가지였어요. 영상으로 진행되는 온라인 컨퍼런스인 만큼, 그래픽 썸네일은 세션의 첫인상이자 몰입의 출발점이라고 생각했어요.사람들이 콘텐츠에 몰입하려면, 그 몰입은 영상이 시작되기 전 가장 먼저 마주하게 되는 썸네일에서부터 시작된다고 생각하는데요. 그래서 그래픽 썸네일은 세션 내용만큼이나 중요한 요소였어요.하나의 키비주얼이 아닌, 14개의 메타포이번 시즌에는 ‘세션마다 전혀 다른 느낌의 썸네일을 만들자’는 방향으로 접근했어요. 기존 시즌에는 하나의 키비주얼을 바리에이션 했는데요. 통일성 있는 그래픽이라는 장점은 있었지만, 반대로 "모든 세션이 비슷해 구분하기 어렵다"는 피드백도 있었거든요.그래서 이번에는 각 세션마다 완전히 다른 시각 언어와 메타포를 사용했어요. 이때 두 가지를 특히 신경썼어요.단순히 아름다운 그래픽을 넘어서, 세션의 핵심 메시지를 시각적으로 풀어내고, 시청자가 다시 기억해낼 때도 내용과 함께 이미지가 함께 떠오를 수 있기를 바랐어요. 사람은 텍스트보다 시각 정보를 더 빠르게 인지하기도 하고, 이미지와 언어가 함께 주어질 때 기억에 더 오래 남고 이해도도 높아지는 경향이 있거든요. 그래서 이번 시즌에는 세션 하나하나에 기억될 수 있는 대표 이미지를 만들어주고 싶었죠.너무 직설적이지는 않되, 주제와 자연스럽게 연결될 수 있는 시각 언어를 찾는 게 중요했어요. 그리고 그 메타포를 어떤 질감, 구조, 방식으로 표현할지까지 함께 고민하면서 내용과 분위기를 함께 담아낼 수 있을지 고민했어요.그 중 특히 기억에 남는 두 가지 사례를 소개할게요.[모두가 유저를 만나는 순간까지]이 세션은 점심시간을 활용해 사용자와 인터뷰할 수 있는 무물런치 프로그램(무엇이든 물어보세요)의 내용을 다루고 있어요. 그래서 '점심 식사'를 메타포로 접근해보았는데요.친근하고 여유로운 심상을 담기위해 손그림 스타일로 시도해보기도 하고보다 밀도감있는 일러스트 스타일로 시도해보았지만, ‘식사’나 ‘음식’이라는 메타포는 세션의 핵심을 충분히 전달하지 못했어요.그래서 메타포를 재고하기로 하고 잠시 고민하다, 음식과 식사가 아닌 ‘점심 시간’을 활용한 사용자 인터뷰라는 본질에 더 주목하면 좋겠다는 생각이 들었어요.그래서 ‘무물런치’ 일정이 실제 캘린더 상에 표기된 모습을 메타포로 설정하고 캘린더 ui를 활용해 시안을 제작했어요.그리고 캘린더의 구조를 포크나 햄버거같은 모양으로 만들어보면서 점심 ‘식사’의 심상을 더해보기도 하면서 시안을 디벨롭했어요.최종적으로 캘린더와 포크를 형상화한 시안으로 완성되었고 하나의 메타포 안에서 ‘식사’와 ‘대화'의 개념을 동시에 표현해낼 수 있었어요.이 세션은 디자인 조직 안에서 아
5/29/2025

몰입의 시작을 만드는 그래픽 | Simplicity 4 제작기 #4
안녕하세요, Simplicity 4에서 그래픽 디자인을 맡은 Graphic Designer 김경태, 김영하입니다.이번 심플리시티 시즌4의 그래픽 제작을 진행하면서 느낀 고민과 경험들을 제작기를 통해 공유하고자 해요.여러분은 유튜브에서 영상을 볼 때 어떤 기준으로 선택하시나요? 아마 많은 분들이 썸네일을 보고 ‘볼지 말지’를 결정하실 거예요.Simplicity도 마찬가지였어요. 영상으로 진행되는 온라인 컨퍼런스인 만큼, 그래픽 썸네일은 세션의 첫인상이자 몰입의 출발점이라고 생각했어요.사람들이 콘텐츠에 몰입하려면, 그 몰입은 영상이 시작되기 전 가장 먼저 마주하게 되는 썸네일에서부터 시작된다고 생각하는데요. 그래서 그래픽 썸네일은 세션 내용만큼이나 중요한 요소였어요.하나의 키비주얼이 아닌, 14개의 메타포이번 시즌에는 ‘세션마다 전혀 다른 느낌의 썸네일을 만들자’는 방향으로 접근했어요. 기존 시즌에는 하나의 키비주얼을 바리에이션 했는데요. 통일성 있는 그래픽이라는 장점은 있었지만, 반대로 "모든 세션이 비슷해 구분하기 어렵다"는 피드백도 있었거든요.그래서 이번에는 각 세션마다 완전히 다른 시각 언어와 메타포를 사용했어요. 이때 두 가지를 특히 신경썼어요.단순히 아름다운 그래픽을 넘어서, 세션의 핵심 메시지를 시각적으로 풀어내고, 시청자가 다시 기억해낼 때도 내용과 함께 이미지가 함께 떠오를 수 있기를 바랐어요. 사람은 텍스트보다 시각 정보를 더 빠르게 인지하기도 하고, 이미지와 언어가 함께 주어질 때 기억에 더 오래 남고 이해도도 높아지는 경향이 있거든요. 그래서 이번 시즌에는 세션 하나하나에 기억될 수 있는 대표 이미지를 만들어주고 싶었죠.너무 직설적이지는 않되, 주제와 자연스럽게 연결될 수 있는 시각 언어를 찾는 게 중요했어요. 그리고 그 메타포를 어떤 질감, 구조, 방식으로 표현할지까지 함께 고민하면서 내용과 분위기를 함께 담아낼 수 있을지 고민했어요.그 중 특히 기억에 남는 두 가지 사례를 소개할게요.[모두가 유저를 만나는 순간까지]이 세션은 점심시간을 활용해 사용자와 인터뷰할 수 있는 무물런치 프로그램(무엇이든 물어보세요)의 내용을 다루고 있어요. 그래서 '점심 식사'를 메타포로 접근해보았는데요.친근하고 여유로운 심상을 담기위해 손그림 스타일로 시도해보기도 하고보다 밀도감있는 일러스트 스타일로 시도해보았지만, ‘식사’나 ‘음식’이라는 메타포는 세션의 핵심을 충분히 전달하지 못했어요.그래서 메타포를 재고하기로 하고 잠시 고민하다, 음식과 식사가 아닌 ‘점심 시간’을 활용한 사용자 인터뷰라는 본질에 더 주목하면 좋겠다는 생각이 들었어요.그래서 ‘무물런치’ 일정이 실제 캘린더 상에 표기된 모습을 메타포로 설정하고 캘린더 ui를 활용해 시안을 제작했어요.그리고 캘린더의 구조를 포크나 햄버거같은 모양으로 만들어보면서 점심 ‘식사’의 심상을 더해보기도 하면서 시안을 디벨롭했어요.최종적으로 캘린더와 포크를 형상화한 시안으로 완성되었고 하나의 메타포 안에서 ‘식사’와 ‘대화'의 개념을 동시에 표현해낼 수 있었어요.이 세션은 디자인 조직 안에서 아
2025.05.29

좋아요

별로에요

여행 콘텐츠에서 ‘신뢰‘와 ‘경험’을 설계한다는 것
여기어때 블랙의 콘텐츠 고도화 스토리‘여기어때 블랙’ 인스타그램 계정이 최근 새로운 콘텐츠 방향성과 함께 더욱 고도화되었다는 사실, 알고 계셨나요?서비스 방향그동안 여기어때 블랙은 “숙소 전문가가 직접 경험하고 선별한 프리미엄 숙소 큐레이션 서비스”라는 슬로건 아래, 감각적인 사진 이미지 중심의 숙소 소개 콘텐츠와 이벤트성 콘텐츠를 운영해왔습니다. 숙소에 대한 신뢰도 높은 정보를 전하는 데 집중해왔죠.하지만 여행을 대하는 사람들의 니즈는 점점 더 세분화되고 있습니다. 단순히 좋은 숙소를 찾는 것을 넘어, 더 특별한 ‘경험’과 자신에게 꼭 맞는 ‘선택’을 원하게 된 것인데요. 이런 변화에 발맞춰, “블랙만의 콘텐츠는 어떤 방향으로 진화해야 할까?”를 고민하게 되었습니다.기존 : 프리미엄 숙소 큐레이션 서비스신규 : 전문가의 숙소 경험 큐레이션 서비스블랙의 슬로건을 ‘전문가의 숙소 경험 큐레이션 서비스’로 새롭게 정의하게 되었고, 최고의 선택을 돕는 경험 큐레이션 채널로 리부스팅 하게 되었습니다. 좋은 숙소를 단순히 소개하는 것을 넘어, 전문가의 실제 경험을 바탕으로 ‘왜 이 숙소인가’에 대한 이유와 가치까지 함께 큐레이션 하는 것이죠.이에 따라 큐레이션 인지도와 신뢰도를 높이기 위한 콘텐츠들을 신규 개발하고, 디자인 또한 재정의 된 메세지와 함께 계정 내 콘텐츠를 담아낼 디자인 언어도 자연스럽게 정리하게 되었습니다. 전문가의 경험이 주는 신뢰감, 숙소 경험의 진정성, 그리고 선택을 돕는 큐레이션의 명료함을 시각적으로 표현한 디자인으로 블랙의 콘텐츠가 한층 더 정제되고 일관된 방향으로 나아갈 수 있도록 말이죠.서비스 방향이 정리되자, 디자인 방향도 자연스럽게 잡히기 시작했어요.우리가 중점을 둔 건, ‘여기어때’라는 브랜드와의 연결성을 유지하면서도 블랙만의 감성과 콘텐츠 성격이 분명히 드러날 수 있도록 하는 것이었어요.그래서 디자인 방향을 잡을 때 전문성이 강조되면서도 너무 진지하지는 않고, 여행의 설렘을 담으면서도 가볍지 않도록 균형점을 잡으려 했습니다.이러한 방향성을 시각적으로 풀어내기 위해, 블랙만의 무드를 세 가지 핵심 키워드로 정의하고 이를 디자인과 콘텐츠 전반에 녹여냈습니다.Bold : 신뢰감을 주는 단단한 메세지,Brilliant : 멋지고 훌륭한 숙소를 시각적으로 전달하는 무드,Lively : 생동감 넘치는 소통이 느껴지는 분위기에요.이 키워드들을 각 콘텐츠별 유형에 맞게 조합하고, 콘텐츠 성격에 따라 톤 앤 매너를 조정했어요. 각 콘텐츠 별 성향에 따른 키워드를 도출했으니, 새로운 콘텐츠를 하나씩 살펴볼까요?이번 고도화에서 가장 눈에 띄는 변화 중 하나는 릴스 콘텐츠의 도입이에요.총 4종의 신규 릴스 콘텐츠를 통해, 단순한 숙소 소개를 넘어 더 세분화된 큐레이션 방식으로 정보를 전달하고자 했습니다.릴스 콘텐츠 4종은 각기 다른 방식으로 ‘숙소 경험과 정보’를 전달하지만, 공통적으로 블랙이 전하고자 하는 메시지는 분명합니다.“믿을 수 있는 전문가의 숙소 큐레이션”, 그리고 “선택을 돕는 경험 중심 콘텐츠”라는 점인데요. 앞서 정
5/29/2025

여행 콘텐츠에서 ‘신뢰‘와 ‘경험’을 설계한다는 것
여기어때 블랙의 콘텐츠 고도화 스토리‘여기어때 블랙’ 인스타그램 계정이 최근 새로운 콘텐츠 방향성과 함께 더욱 고도화되었다는 사실, 알고 계셨나요?서비스 방향그동안 여기어때 블랙은 “숙소 전문가가 직접 경험하고 선별한 프리미엄 숙소 큐레이션 서비스”라는 슬로건 아래, 감각적인 사진 이미지 중심의 숙소 소개 콘텐츠와 이벤트성 콘텐츠를 운영해왔습니다. 숙소에 대한 신뢰도 높은 정보를 전하는 데 집중해왔죠.하지만 여행을 대하는 사람들의 니즈는 점점 더 세분화되고 있습니다. 단순히 좋은 숙소를 찾는 것을 넘어, 더 특별한 ‘경험’과 자신에게 꼭 맞는 ‘선택’을 원하게 된 것인데요. 이런 변화에 발맞춰, “블랙만의 콘텐츠는 어떤 방향으로 진화해야 할까?”를 고민하게 되었습니다.기존 : 프리미엄 숙소 큐레이션 서비스신규 : 전문가의 숙소 경험 큐레이션 서비스블랙의 슬로건을 ‘전문가의 숙소 경험 큐레이션 서비스’로 새롭게 정의하게 되었고, 최고의 선택을 돕는 경험 큐레이션 채널로 리부스팅 하게 되었습니다. 좋은 숙소를 단순히 소개하는 것을 넘어, 전문가의 실제 경험을 바탕으로 ‘왜 이 숙소인가’에 대한 이유와 가치까지 함께 큐레이션 하는 것이죠.이에 따라 큐레이션 인지도와 신뢰도를 높이기 위한 콘텐츠들을 신규 개발하고, 디자인 또한 재정의 된 메세지와 함께 계정 내 콘텐츠를 담아낼 디자인 언어도 자연스럽게 정리하게 되었습니다. 전문가의 경험이 주는 신뢰감, 숙소 경험의 진정성, 그리고 선택을 돕는 큐레이션의 명료함을 시각적으로 표현한 디자인으로 블랙의 콘텐츠가 한층 더 정제되고 일관된 방향으로 나아갈 수 있도록 말이죠.서비스 방향이 정리되자, 디자인 방향도 자연스럽게 잡히기 시작했어요.우리가 중점을 둔 건, ‘여기어때’라는 브랜드와의 연결성을 유지하면서도 블랙만의 감성과 콘텐츠 성격이 분명히 드러날 수 있도록 하는 것이었어요.그래서 디자인 방향을 잡을 때 전문성이 강조되면서도 너무 진지하지는 않고, 여행의 설렘을 담으면서도 가볍지 않도록 균형점을 잡으려 했습니다.이러한 방향성을 시각적으로 풀어내기 위해, 블랙만의 무드를 세 가지 핵심 키워드로 정의하고 이를 디자인과 콘텐츠 전반에 녹여냈습니다.Bold : 신뢰감을 주는 단단한 메세지,Brilliant : 멋지고 훌륭한 숙소를 시각적으로 전달하는 무드,Lively : 생동감 넘치는 소통이 느껴지는 분위기에요.이 키워드들을 각 콘텐츠별 유형에 맞게 조합하고, 콘텐츠 성격에 따라 톤 앤 매너를 조정했어요. 각 콘텐츠 별 성향에 따른 키워드를 도출했으니, 새로운 콘텐츠를 하나씩 살펴볼까요?이번 고도화에서 가장 눈에 띄는 변화 중 하나는 릴스 콘텐츠의 도입이에요.총 4종의 신규 릴스 콘텐츠를 통해, 단순한 숙소 소개를 넘어 더 세분화된 큐레이션 방식으로 정보를 전달하고자 했습니다.릴스 콘텐츠 4종은 각기 다른 방식으로 ‘숙소 경험과 정보’를 전달하지만, 공통적으로 블랙이 전하고자 하는 메시지는 분명합니다.“믿을 수 있는 전문가의 숙소 큐레이션”, 그리고 “선택을 돕는 경험 중심 콘텐츠”라는 점인데요. 앞서 정
2025.05.29

좋아요

별로에요