제품의 진입점을 사용자가 잘 찾는지 알고 싶을 때, 어떻게 하시나요?토스는 자체 리서치 도구로 알아봐요. 사용자가 원하는 기능을 얼마나 잘 찾아가는지를 수치로 측정하는 툴로, 이름은 TNS(Toss Navigation Score)예요.“토스에 있는 모든 서비스를 보려면 어디를 눌러보시겠어요?”라는 질문을 주면, 사용자는 실제 앱 화면 위에서 직접 그 기능을 찾아가요. 이때 사용자가 얼마나 헤매지 않고 빠르게 도달했는지를 점수로 계산해요. 내비게이션이 잘 설계돼 있을수록 점수가 높아지는 거죠.사실 이런 정성적인 경험을 수치화해서 제품 개선에 활용하는 리서치 툴은 리서치 업계에서도 쉽게 보기 힘든 방식이라, 특허까지 출원했어요.이렇게 생소한 개념의 툴을 어떻게 처음부터 만들어낼 수 있었을까요? 레퍼런스 하나 없는 상태에서 처음 길을 만들어간 TNS 길드 팀원을 만나 이야기를 들어봤어요.TNS는 "사용자가 어떤 경로를 거쳐 기능에 도달하는지"를 실제 라이브 앱에서 추적하기 위해 만들어졌어요. 기존에 쓰던 EVR(Entrance conVersion Rate) 이라는 툴을 쓰고 있었는데요. 화면 단위로 사용자의 클릭을 측정할 수는 있었지만, 사용자가 여러 화면을 거치는 실제 여정을 담기엔 한계가 있었어요.예를 들어, EVR은 캡처된 특정 화면을 보여준 뒤 사용자가 어디를 클릭했는지를 확인하는 방식이에요. 정답을 클릭한 비율로 점수를 매기는 일종의 무인 사용자 테스트인 셈이죠.하지만 이 방식은 A → B → C 같은 실제 사용자의 탐색 경로를 파악할 수 없고, 정해진 화면 내에서만 행동을 측정해야 해요. 그러다 보니 복잡한 내비게이션 이슈, 즉 사용자가 어떤 경로를 헤매다 기능에 도달하는가를 이해하기 어려웠죠.실제 앱 안에서 사용자가 어떤 경로를 통해 목표에 도달했는지를 추적할 수 있는 새로운 툴이 필요하다고 생각했고, 그게 TNS예요.라이브 앱에서 테스트하는 방법을 찾다처음에는 이게 되겠어? 싶은 마음이 컸어요. 기존처럼 캡처 화면으로만 실험하던 방식이 아니라, 실제 앱 환경에서 사용자가 자유롭게 탐색하는 걸 측정해야 하니까요. 이걸 하려면 앱을 아예 복제해서 별도 환경을 만들어야 하는 건가 고민도 했었고요.맞아요. 저도 두세 달 동안 엔지니어분들한테 하나하나 찾아다니면서 이걸 어떻게 구현할 수 있을지 방법을 찾아다녔거든요. 그런데 대부분 "그건 안 되지 않나요"라는 답을 들었어요. 토스에 와서 이렇게 많이 안 된다는 말을 들어본 건 처음이었어요.그런데 어느 날 서진님이 아이디어를 주셨어요. TNS 설문에 참여 중인 사용자를 로그 상에서 별도로 식별할 수 있게 하자. 앱 로그에 TNS ID를 심어서, 이 사용자가 어떤 경로를 탐색했는지 일반 사용자의 로그와 분리해서 기록하는 방식이었어요. 이걸로 결국 라이브 앱 환경을 그대로 쓰면서도 실험 사용자의 행동만 따로 추적할 수 있게 됐어요.이게 돌파구였어요. 이걸 계기로 프로젝트가 본격적으로 시작될 수 있었죠.사실 TNS는 구현 자체가 엄청 복잡하진 않았어요. 그런데 이게 앱 전체에 적용되는 시스템이다

랭턴의 개미(Langton's Ant) 는 매우 단순한 규칙을 따르는 2차원 격자 위의 개미입니다.해당 개미는 흰색 칸에서는 시계방향으로 90도 회전하고, 칸 색을 반전(흰색->검은색, 검은색->흰색)한 뒤 한 칸 전진하며,검은색 칸에서는 반시계방향으로 90도 회전하고, 칸 색을 반전하고 한 칸을 전진하는데요,이 단순한 규칙만으로도 격자 위에 신기한 패턴을 그리게 됩니다.아래는 초기 - 중기 - 후기로 나누어 랭턴의 개미의 행동 과정을 설명한 내용입니다.처음에는 모든 격자가 흰색이고, 개미가 가운데에 위치합니다.개미는 규칙에 따라 움직이지만 초기에는 격자 위에 남기는 패턴이 매우 단순하거나 대칭적입니다.몇 백 번 움직인 후에는 격자 위에 무질서한 흑백 무늬가 형성되기 시작합니다.수천 번의 이동 후, 개미는 격자 위를 마치 무작위처럼 움직이며 불규칙하고 복잡한 패턴을 만듭니다.이 단계에서는 격자 위에 남겨지는 흑백 무늬가 매우 혼란스럽고, 어떤 규칙성도 보이지 않습니다.후기 : 질서가 생기고, 반복되는 패턴으로 안정화약 만 번의 이동 이후, 개미는 갑자기 반복적인 고속도로 패턴을 만들기 시작합니다.이 패턴은 104번 이동마다 반복되며, 개미는 이 패턴을 계속해서 따라가면서 격자 한쪽으로 빠져나갑니다.이처럼 단순한 규칙이 반복될 때 예측할 수 없는 복잡한 패턴이 나타나고, 결국에는 안정적인 반복 구조로 수렴하는 것이 랭턴의 개미의 특징입니다.랭턴의 개미와 마케팅 시뮬레이션• None 마케팅 시뮬레이션도 랭턴의 개미와 유사하게, 단순한 규칙 (ex - 고객 이동, 채널 전환 등)이 반복되면 예측 불가능한 변화와 복잡한 결과가 나타날 수 있습니다.• None 단기적으로는 변화가 불규칙하지만, 장기적으로는 랭턴의 개미처럼 안정적인 정상 상태로 수렴하는 경향이 있습니다.2. 고객 접점 점유율과 시뮬레이션• None 새로운 사업이나 서비스를 시작할 때, 고객이 어떤 채널을 주로 이용하는지, 그리고 시간이 지남에 따라 그 점유율이 어떻게 변화하는지 예측하는 것은 매우 중요합니다.• None 마르코프 체인을 활용하면 랭턴의 개미처럼 각 채널의 점유율이 '정상 상태'로 어떻게 수렴하는지 시뮬레이션할 수 있습니다.• None 기본적으로 고객들이 아래와 같은 확률로 채널 간 전이를 한다고 가정합니다.• None 상담센터 50%, 오프라인 매장 30%, 온라인 앱 15%, 웹/이메일 등 기타 5%• None 그리고 기본적으로 랭턴의 개미처럼, 고객들은 현재 채널에 대해 20%정도의 추가적인 매력도를 느낀다고 가정합니다.각 채널 별 점유율은 아래와 같은 루트를 통해 수렴하게 됩니다.초기 상태와는 달리, 50%였던 상담센터는 54% 가량으로, 30%의 오프라인 매장은 26%로, 15%였던 앱은 16%로, 5%였던 웹/이메일은 약 3% 가량으로 변경되게 됩니다.4) 현재 채널에 대해 더 큰 추가 가중치 적용만약 고객들이 경험한 채널에 대해 좀 더 애착을 가지고 자주 사용한다고 가정하고, 해당 채널에 1.4배의 가중치를 추가적으로 더 주게 되면 어떻게 바뀔까요?이 때는 초기에 큰 비중을 가지고 있던 상담센터의 비율이 매우 높아지고, 앱은 잠시 비중이 높아지다가 다시 수렴하며, 나머지 채널들은 각각 감소하는 방향으로 바뀌게 됩니다.5) 시뮬레이션 적용 - 온라인 채널의 활성화 (1단계)디지털 전환과 리소스 효율화로 인해, 온라인 채널을 활성화하려고 합니다.온라인 앱이나 웹에 추가적인 쿠폰을 주거나, 무료 배송 등의 프로모션을 진행해, 상담센터와 오프라인 매장 방문 비중을 줄이고 (-10%), 앱과 웹/이메일의 비중을 높이려고 합니다. (+20%)프로모션을 통해 고객 분들이 현재 경험한 채널에서 벗어나 좀 더 다양한 채널을 경험할 수 있게 유도하였습니다. (+40% -> -40%)하지만 오프라인 매장의 경우에는 유의미한 수치로 줄어들었지만, 상담센터의 비중은 여전히 높고, 웹/이메일의 경우 거의 비중이 변하지 않았습니다.그렇다면 좀 더 강한 프로모션을 진행해본다면 어떨까요? 기존 채널에서 벗어나진 않고는 못 버틸 정도로 매력적인 프로모션을 제공하겠습니다.6) 시뮬레이션 적용 - 온라인 채널의 활성화 (2단계)더 강력한 프로모션을 진행해, 상담센터와 오프라인 매장 방문 비중을 줄이고 (-30%), 앱과 웹/이메일의 비중을 높이려고 합니다. (+50%)강력한 프로모션을 통해 고객 분들이 현재 경험한 채널에서 벗어나 좀 더 다양한 채널을 경험할 수 있게 유도하였습니다. (-40% -> -80%)상담센터와 오프라인 매장 방문이 유의미하게 줄어들고, 앱 방문률은 큰 폭으로 늘어나 상담센터를 이은 2위로 올라갔습니다.하지만 웹/이메일의 경우 파격적인 프로모션에도 불구하고, 조금 늘어나긴 했지만 엇비슷한 값으로 수렴하게 되었습니다.실질적으로 웹/이메일의 점유율을 올리려면 전이행렬의 기본값 자체를 높이는 구조적 변화가 필요합니다.랭턴의 개미와 마르코프 체인을 활용한 시뮬레이션을 통해, 단순한 규칙이 반복될 때 초기에는 예측할 수 없는 복잡한 변화가 나타나지만,시간이 지나면 결국 안정적인 상태로 수렴한다는 사실을 확인할 수 있었습니다.채널 점유율 역시 단기적으로는 다양한 변동 요인에 따라 불규칙하게 움직이지만, 장기적으로는 각 채널의 고유한 전이 확률에 따라 정상 상태로 수렴합니다.특히, 단순한 채널 이동 확률 상승이나 강화만으로는 웹/이메일의 점유율을 크게 높이기 어렵다는 점이 시뮬레이션 결과에서 드러났습니다.웹/이메일 채널의 점유율을 높이려면 기본값 자체를 구조적으로 변경하는 마케팅 전략이 필요하다는 사실을 알 수 있었습니다.이번 시뮬레이션은 단순한 초기 상태와 확률을 통한 간단한 시뮬레이션이지만, 고객의 채널 경험을 유도하거나 점유율을 예측하는 작업이 얼마나 복잡하고 어려운지,그리고 데이터 기반의 구조적 접근이 얼마나 중요한지 실감할 수 있었습니다.아래는 랭턴의 개미 시뮬레이션을 파이썬으로 구현한 예시입니다. 이 코드를 통해 랭턴의 개미를 각 단계별로 시뮬레이션 해보실 수 있습니다.

안녕하세요. SK Hynix의 AI Transformation 팀 김지수입니다.이번에 업무를 진행하면서 redis sub / pub 구조를 고민하게 된 과정 대해 공유 차 작성하게 되었습니다.비슷한 고민이 있으시다면 함께 나눠보면 좋을 것 같네요.우선 서버-인스턴스 간 통신을 통해 특정 작업을 진행하는 과정이 있습니다.기존엔 SSH를 통해 인스턴스에서 작업을 지시하는 방식으로 구현되었으나 대량의 작업이 필요할 경우,서비스의 고도화를 위해 다수의 클라이언트 서버와 통신해야 하는 과정에서 병목이 발생하였습니다.이해를 돕기 위해 간단하게 도식화 해보면 다음과 같습니다.자 그럼 이 문제를 해결하기 위해 어떤 고려 사항이 있을지 정리해보면..• None client, worker, pod의 개수가 가변적정도가 있겠네요다음으로는 병목의 주 원인이었던 SSH 구조를 대체할 만한 프레임워크를 프롬프트를 통해 정리해 보았습니다.저희는 Latency가 크게 중요하지 않으며 구성 서버들이 가변적이므로 비동기 방식을 항상 channel을 subscribe 하는 worker를 둔다면 로깅 문제도 해결할 수 있겠네요.표로 보았을 때, redis Pub/Sub 구조가 가장 적당해 보입니다.그럼 pub / sub 구조로 구현하는 것으로 하고 한 번 자세한 개념을 알아보죠.Redis Pub/Sub은 Redis의 기능을 활용한 메시지 브로커 시스템의 일종입니다.이 시스템은 데이터를 '발행자'(publisher)가 특정 '채널' 또는 '주제'(topic)에 메시지를 보내면,이 채널을 구독하고 있는 '구독자'(subscriber)들이 메시지를 받아 처리할 수 있도록 해주는 통신 방식입니다.유튜브 채널 구독과 비슷하게, 크리에이터가 새 글을 발행하면 구독자에게 알림이 오는 원리와 유사하다고 설명될 수 있습니다.아하~ 위 예를 보면 인스턴스(publisher)가 무수히 많이 늘어나더라도 간단하게 서버와 인스턴스 간 Pub / Sub 으로 비동기 통신을 구현할 수 있겠네요. 아래 그림처럼 말이죠.cursor로 Mockup code도 요청해 보았습니다.실제 구현은 좀 다르게 되겠지만 의도대로 동작하는 코드가 만들어졌습니다.

해당 이미지는 OpenAI의 이미지 생성 모델 DALL·E를 활용하여 GPT-4o에서 생성한 이미지입니다.안녕하세요! 당근 채팅팀에서 백엔드 엔지니어 인턴으로 일하고 있는 카펠이에요. 이 글에서는 연간 LLM 호출 비용을 약 25%, 연간 2.1억 원가량 절감한 프로젝트를 소개해보려고 해요.당근에서는 AI를 다양한 프로덕트에 적극적으로 활용하고 있는데요. 그중 하나가 채팅창에서 대화 흐름에 맞춰 다음 문장을 자동으로 추천해 주는 AI 메시지 추천 기능이에요. 이 기능은 사용자들의 채팅 경험을 더욱 편리하게 개선했지만, LLM 호출 비용이 과도하게 높다는 문제가 있었어요. AI를 잘 활용하면서도 비용을 효율적으로 관리하는 게 중요한 과제였던 거죠.저는 시맨틱 캐싱(Semantic Caching)이라는 기술을 실제 프로덕션 환경에 적용해 비용을 크게 절감해 냈어요. 시맨틱 캐싱은 기존 캐싱 기법과는 달리 문장 간 의미 유사도를 고려해, 표현은 달라도 의미가 비슷한 요청에 캐싱이 동작하도록 하는 기법이에요.이 프로젝트는 제가 인턴 생활 중에 직접 문제를 발견하고 아이디어를 제안해 주도적으로 진행했던 경험이기도 해요. 기술적으로도, 개인적으로도 큰 의미가 있었던 여정을 공유해 볼게요.과제 정의 및 해결 아이디어 도출1. 채팅 추천 기능의 도입, 그리고 LLM 호출 비용 문제당근에서 중고거래 채팅, 다들 한 번쯤 해보신 적 있으시죠? 이때 거래 시간을 정하거나 또 가격을 조율할 때 자주 쓰게 되는 말들이 있어요. 그런데 이런 문장들을 매번 키보드로 일일이 입력하려니 은근 번거로울 때가 있어요. 이런 불편함에 주목한 당근 채팅팀은, 사용자가 더 간편하게 대화하고 빠르게 거래할 수 있도록, LLM이 상황에 맞는 문장을 똑똑하게 추천해 주는 AI 추천 메시지 기능을 만들게 되었어요.AI 추천 메시지 기능은 LLM이 대화의 흐름을 실시간으로 파악해, 다음에 이어질 만한 적절한 문장을 2개 이상 추천해 주는 기능이에요. 이 기능 덕분에 사용자는 텍스트를 키보드로 직접 입력하지 않고도, 추천된 문장을 탭 한 번으로 보내며 더욱 빠르고 간편하게 중고거래를 이어갈 수 있어요. 실제로 이 기능은 사용자들로부터 많은 관심과 호응을 받고 있어요.그런데 여기에는 LLM 호출 비용이라는 현실적인 큰 장애물이 있었어요. 당근에서는 하루에 오가는 메시지만 해도 1,000만 건이 넘기 때문에, 이 기능을 모든 사용자에게 제공하려면 그 트래픽만큼이나 빈번하게 LLM을 호출해야 했거든요. 내부 추산에 따르면 연간 비용이 약 8~9억 원에 이르는 수준이었어요. 이처럼 막대한 비용은 기능 확장에 중요한 제약으로 작용했고, 당근 채팅팀은 이를 해결하기 위한 다양한 방법을 고민하게 되었어요.2. 캐싱 기반의 해결 아이디어 제안가장 먼저 떠올린 방법은 캐싱 기법이었어요. 캐싱은 자주 바뀌지 않는 데이터를 미리 저장해 두고, 동일한 요청이 들어왔을 때 DB 조회나 API 호출 없이 바로 저장된 데이터를 반환하는 방식이에요.하지만 이 방식은 요청 문장이 미리 저장된 문장과 완전히 동일할 때만 캐시 HIT이 발생해요. 예를 들어 안녕하세요! 라는 문장을 캐싱해 두었다면, 정확히 똑같은 문장 안녕하세요! 가 다시 들어와야만 캐싱이 동작해요.그런데 이 부분을 단순한 문자열 일치가 아니라, 의미 기반의 유사도를 활용한다면 어떨까 하는 아이디어가 떠올랐어요. 코사인 유사도와 같은 거리 기반 유사도 계산을 활용해서 문장 간 의미가 얼마나 가까운지를 측정하고, 그 거리가 일정 임계값 이상이라면 같은 의미라고 판단해 캐시 HIT를 적용하는 방식이에요.이렇게 동작하는 것이 바로 시맨틱 캐싱이에요. 예를 들어 안녕하세요! 라는 문장에 대해 시맨틱 캐싱이 되어 있다면, 안녕하셨어요! 나 안녕하신가요? 처럼 형태는 다르지만 의미가 유사한 문장도 캐시 HIT으로 처리할 수 있어요.3. 시맨틱 캐싱 도입 시 비용 절감 예상 효과우선 LLM을 직접 호출해 응답을 생성하는 기존 방식의 비용부터 계산해 볼게요. 이 경우 연간 약 9억 원의 비용이 발생할 수 있는데, 이를 하루 단위로 환산하면 다음과 같아요:다음으로는 시맨틱 캐싱을 적용했을 때의 비용을 계산해 볼게요. 예를 들어 OpenAI의 text-embedding-3-small 모델을 사용할 경우, 100만(1M) 토큰당 $0.02의 비용이 발생해요.이때 계산을 단순화하기 위해 하루 1,000만 건의 채팅 요청 중 100% 모두가 캐시 HIT된다고 가정해 볼게요. 또 문장 하나당 평균적으로 5~7 단어, 약 5토큰이라고 본다면, 시맨틱 캐싱을 위한 하루 임베딩 비용은 다음과 같은 방식으로 계산할 수 있어요:즉, 하루 약 247만 원에 달하는 LLM 호출 비용과 비교해 보면, 시맨틱 캐싱은 하루 1,400원(약 1달러) 수준으로 운영할 수 있어요. 이는 무려 1,760배나 저렴하기 때문에, 비용 측면에서 매우 큰 이점을 확인할 수 있었어요.물론 현실적으로 캐시 HIT이 100% 발생하는 경우는 거의 없어요. 따라서 실제 절감 효과는 시맨틱 캐싱의 HIT 비율에 따라 달라지게 되어요. 다시 말해, HIT 비율이 높아질수록 LLM 호출 횟수가 감소하고, 그만큼 API 비용도 더 크게 절감할 수 있어요.현재 진행 중인 Phase 1에서는 약 25% 수준의 캐시 HIT 비율을 목표로 하고 있어요. 이 경우, 전체 LLM 호출 비용의 약 24%에 해당하는 연간 2.16억 원의 비용을 절감할 수 있어요. 더 나아가, 궁극적으로는 HIT 비율을 50% 이상으로 끌어올리는 것을 목표로 하고 있어요. 아래에 캐시 HIT 비율에 따른 예상 비용 절감 효과를 정리한 표를 함께 보여드릴게요:시맨틱 캐싱 아키텍처 설계 및 구현1. 시맨틱 캐싱 서버 구현과 성능 최적화 전략시맨틱 캐싱을 처리하는 서버는 메인 서버와 분리된 add-on 형태로 구성했으며, 서로 간의 통신은 gRPC 프로토콜을 통해 이루어지고 있어요. 이처럼 분리형 구조를 채택한 이유는, 기존 서비스 로직에 영향을 주지 않으면서도 시맨틱 캐싱 기능을 독립적으로 운영하고 유연하게 확장할 수 있도록 하기 위함이었어요.또한, 유사도가 임계값을 넘지 못해 캐시 미스가

안녕하세요. 카카오에서 AI를 연구개발하는 카나나(Kanana) - Visual Content Generative AI팀의 Orca입니다. 저희 팀에서는 고품질의 이미지와 동영상 등 시각 콘텐츠를 생성하는 비주얼 생성 모델을 연구하고 있습니다. 지난 if(kakaoAI) 2024에서 나만의 프로필 이미지 생성 모델 개발기 발표를 통해서도 저희 팀의 연구 성과를 공유드린 바 있는데요.이번에는 저희 연구가 ‘CVPR(Computer Vision Pattern Recognition) 2025’에 하이라이트 논문(Highlight paper)으로 선정되어, 지난 6월 11일부터 15일까지 미국 테네시주 내슈빌에서 열린 ‘CVPR(Computer Vision Pattern Recognition) 2025’ 학회에 직접 다녀올 수 있었습니다. CVPR은 컴퓨터 비전 분야에서 세계 최고 권위를 지닌 국제 학술대회로, 매년 전 세계의 최신 연구 성과와 기술 트렌드가 공유되는 자리입니다.이번 글에서는 현장에서 확인한 생성 모델의 연구 동향과 저희가 발표한 인물 이미지 생성 기술 관련 “Boost Your Human Image Generation Model via Direct Preference Optimization” 논문에 대해서도 간략히 소개해 드리고자 합니다.생성 모델은 현재 가장 활발히 연구되고 있는 분야 중 하나로, 이번 CVPR에서도 굉장히 많은 생성 모델 연구를 확인할 수 있었습니다. 우선 Diffusion model을 이용한 이미지 생성 모델 연구가 가장 활발한 분야 중 하나였습니다. 이러한 Diffusion model 기반의 이미지 생성 모델을 이용한 Personalized text-to-image와 같은 응용 연구도 활발히 이루어지고 있었고, 이미지 생성을 넘어서 Diffusion model을 이용한 비디오 생성 모델 연구도 굉장히 활발하게 이루어지고 있었습니다.실사에 가까운 고품질 이미지 생성하기이어 저희 발표 논문 “Boost Your Human Image Generation Model via Direct Preference Optimization”을 소개해보겠습니다. 저희 논문은 앞서 소개한 Diffusion model을 기반으로 한 인물 이미지 생성 관련 연구입니다. 전체 발표 논문 중 13.5%에 해당되는 하이트라이트 논문(Highlight paper)에 선정되며 그 기술력을 인정받았습니다.저희가 진행한 연구는 고품질 인물 이미지를 생성하는 것을 목표로 합니다. 인물 이미지 생성은 인체 구조나 포즈가 조금만 어색해도 품질이 저하되기 때문에 난이도가 어려운 과제입니다. 아래 이미지에서도 볼 수 있듯이, 고품질 인물 이미지 데이터셋으로 Fine-tuning된 Base model마저도 만족스러운 품질의 인물 이미지를 생성하지 못하는 문제가 있었습니다. 저희가 제안하는 HG-DPO 방식을 이용하면, Base model을 개선시켜 효과적으로 고품질 인물 이미지를 생성할 수 있습니다.Base model과 성능을 개선시킨 HG-DPO 모델의 생성 이미지 비교저희는 이를 위해 기존 LLM Alignment 분야에서 사용되던 Direct Preference Optimization(DPO) 기법을 Diffusion 기반 이미지 생성 모델에 접목했습니다. DPO는 하나의 Input에 대해 인물이 더 선호하는(Winning) 결과와 덜 선호하는(Losing) 결과 쌍을 학습 데이터로 모델에 제공해, 사람들이 더 선호하는 결과를 생성하도록 모델을 학습시키는 방법입니다. HG-DPO의 목적은 DPO를 이용하여 Base model을 한 번 더 Fine-tuning 시킴으로써 인물 이미지 생성 성능을 극대화시키는 것입니다. 이를 통해 실사에 가까운 고품질의 자연스러운 이미지를 생성할 수 있습니다.기존 방식들의 한계와 HG-DPO의 전략DPO는 최근 LLM Alignment를 넘어 이미지 생성 분야로도 확장되어 Diffusion-DPO와 같은 방법들이 등장했습니다. 하지만, 인물 이미지는 굉장히 높은 사실성을 필요로 하기 때문에, 이러한 기존 방법들을 그대로 적용하기에는 한계가 존재합니다. 그것은 기존의 방법들이 생성 이미지들만을 이용하여 Winning과 Losing 이미지 쌍을 구성하여 학습하기 때문에 학습 가능한 이미지 품질의 상한선이 낮다는 것입니다. 생성된 이미지는 그 품질이 아무리 좋더라도, 실사의 품질에는 미치기 어려운데요. 그 결과, 인물의 디테일이나 모델이 학습할 수 있는 표현력에 한계가 생기게 됩니다.전략 1: 학습 데이터에 실사 도입이러한 한계를 뛰어넘기 위해, HG-DPO는 첫 번째 전략으로 기존 DPO 방식들과 다르게 실사를 Winning 이미지로, 생성 이미지를 Losing 이미지로 삼는 새로운 DPO 학습 방식을 사용합니다. 이를 통해 모델이 단순히 생성 이미지 중 상대적으로 나은 수준의 품질을 추구하는 것을 넘어, 실사 수준의 품질을 추구하도록 유도할 수 있습니다.전략 2: 안정적인 학습을 위한 Curriculum learning 기반의 3단계 학습 방식 도입하지만, 위의 전략을 기반으로 한 단순 Single stage 학습은 좋은 결과로 이어지지 못했습니다. 이러한 문제에 대해 저희는 저희의 전략을 Single stage로 수행하는 것이 너무 어렵다고 가정하고, 두 번째 전략으로 여러 Stage로 이루어진 Curriculum learning 방식을 도입했습니다.Curriculum learning은 모델을 쉬운 방법으로 먼저 학습시키고, 점진적으로 어려운 방법으로 학습시키는 방식으로 모델을 더욱 안정적으로 학습시킬 수 있습니다. HG-DPO의 Curriculum learning은 아래 이미지와 같이 Easy, Normal, 그리고 Hard stages를 통해 수행됩니다. 각 Stage마다 학습 난이도를 점차 높이며, 모델은 실사와 비슷한 이미지를 생성할 수 있도록 학습됩니다.Easy stage에서는 실사의 품질을 추구하기 전에, 기본적으로 사람들에게 선호되는 이미지를 생성하는 방법을 학습합니다. 이 Stage에서는 실사를 사용하지 않고, 생성된 이미지만을 사용합

안녕하세요. SK텔레콤의 정지헌입니다.Language model의 새로운 패러다임 Large Language Diffusion Model, 일명 LLaDA라고 불리는 논문을 소개하려고 합니다.개인적으로 Diffusion model에 관심이 있고 Language model에 사용한 것이 재밌어서 유심히 읽어보게 되었고 여러 가지 활용 방법들을 구상 중에 있습니다.우선 왜 Vision쪽에서 활용되던 Diffusion model이 Language에 사용되고, 적용되고 있는 지 알아보고자 합니다.지금의 대형 언어모델의 성능에서는 너무 뛰어나지만, 대부분 Autoregressive(AR) 방식 (Left-to-Right)으로 학습 및 생성합니다.약점이 전혀 없을 것 같지만 이 구조에는 세 가지 고질적 약점이 있습니다.• None Exposure bias: 추론 때 모델이 스스로 낸 오류를 계속 입력으로 받아 악순환이 벌어집니다.• None 길이 편향: 로그확률 합을 극대화하려다 보니 응답을 지나치게 짧게 끝내거나 불필요하게 길게 늘어뜨리곤 합니다.• None 장기 의존 실패: 순차 생성 특성상 먼 거리 토큰 간 일관성을 유지하기가 어렵습니다.이를 고치려고 scheduled sampling, Prefix LM, 고급 디코딩 기법 등을 시도했지만, 모두 AR 틀 안에서 부분 수정을 가한 정도에 머물렀습니다.하이퍼파라미터가 민감하거나, 짧은 문장엔 효과가 있어도 길고 복잡한 context에서는 오류 누적을 막지 못합니다.Diffusion 이 무엇인가요?이미지 생성 분야에서 두각을 나타낸 Diffusion(확산) 모델은 무작위 노이즈를 넣었다가 조금씩 걷어 내어 데이터를 복원하는 방식을 자연어 영역으로 확장했습니다.이미지에서 성공한 Diffusion기법 즉, 노이즈를 넣고 단계별로 걷어내며 복원 하는 방식을 그대로 자연어에 적용한 것이 Diffusion LM입니다.AR 모델은 토큰을 왼쪽에서 오른쪽으로 하나씩 예측하기 때문에, 앞서 틀린 토큰이 계속 영향을 미치는 exposure bias와 긴 문장에서 뒤쪽 품질이 떨어지는 길이 편향 문제가 있었습니다.반면에, Diffusion LM은 문장 전체(또는 넓은 블록)를 여러 단계에 걸쳐 반복 정제합니다.한 단계에서 잘못 생성된 토큰도 다음 단계에서 다시 고칠 수 있으므로 exposure bias가 줄어들고, 주어진 컨텍스트 윈도 안에서 전역적 일관성을 확보하기 쉽다고 합니다.훈련(Forward) 단계에서는 일정 비율의 토큰을 로 가려 노이즈를 만듭니다.그 이후 추론(Reverse) 단계에서는 모든 토큰이 상태에서 시작해 마스크를 단계적으로 지우며 디노이징을 수행합니다.일부 구현에서는 중간에 다시 re-masking을 넣어 세밀하게 수정하는 과정을 반복해 “한꺼번에 문장을 그려 넣는다”는 이상적인 생성 방식으로 문장을 생성하게 됩니다.즉, AR은 한 단계에서 틀린 토큰을 다음 단계에서 되돌릴 수 없지만, Diffusion LM은 문장 전체를 반복 정제하기 때문에,exposure bias가 줄어들고, context window 내에서 일관성을 확보하기 쉽습니다.위 내용을 그림으로 좀 더 직관적으로 살펴보겠습니다.LM에서의 Diffusion생성 모델에서의 확산 모델은 데이터를 점진적으로 노이즈화한 뒤, 역방향으로 노이즈를 제거하면서 원본을 복원하도록 학습되는 모델입니다.노이즈 혹은 어떠한 방법으로 원본 데이터를 훼손을 시키고, 다시 훼손시키는 것을 복구하는 방법을 학습해 완전 노이즈인 상태에서 부터 생성을 시작하는 아이디어를 갖고 있고,두 가지 주요 process가 존재합니다.• None 이미지 같은 연속 데이터에서는 단계 t마다 가우시안 노이즈를 더합니다.• None 텍스트처럼 이산 토큰으로 이루어진 데이터에서는 단계마다 일부 토큰을 로 바꿔 노이즈를 만들어줍니다.• None 이 process에서 노이즈를 어떻게 복원시킬 것인가를 학습하게 됩니다. 연속형 데이터의 경우 epsilon을 학습하거나 (stein) score 를 학습합니다. 사실 epsilon과 score는 수식적으로 큰 차이는 없습니다. 이산 토큰에서는 을 다시 어떤 Token으로 예측할 지 학습하게 됩니다.• None 학습된 모델이 가장 강한 노이즈 상태에서 출발해 단계 번호를 하나씩 줄여 가며 노이즈를 걷어 냈습니다.• None 연속 도메인에서는 스코어 매칭을 통해 노이즈 자체를 예측했고, 이산 도메인에서는 Masked-LM 손실이나 Rao-Blackwellized Cross-Entropy(RB-CE) 손실을 이용해 위치의 정답 토큰 분포를 맞히도록 학습했습니다.텍스트 Diffusion LM의 학습에서는 토큰이 한 번 마스크되면 다시 원본으로 돌아가지 않는 흡수 상태가 됩니다. 이렇게 두 가지 상태(마스크 / 비-마스크)만 고려하면, 원래 Diffusion ELBO에서 요구하던 복잡한 KL 계산 대신 마스크 위치에서 올바른 토큰을 맞히도록 하는 가중 Cross-Entropy 하나로 목적 함수를 단순화할 수 있었습니다. 에서 실제 데이터 분포 q를 살펴보면 Mask/Non-mask로 구분될 수 있습니다. 따라서, 으로 정의될 수 있고, 부분에서는 t번째 z가 원본 토큰이라면, posterior가 Dirac-delta로 deterministic하게 됩니다. Rao-Blackwellization 후에는 “현재 토큰이 [MASK]일 때만 1, 아닐 때는 0”인 indicator가 KL 앞 가중치에 곱해지기 때문에, 자리의 KL 기여도는 실제로 0이 됩니다. 그러므로 부분만 고려하게 된다면, Rao-Blackwellized CE으로 변경될 수 있고, 이 손실 함수를 쓰면• None Monte-Carlo 샘플링이 줄어들어 분산이 낮아졌고, (Rao-Blackwell theorem)• None 기존 Masked-LM 코드베이스를 거의 그대로 활용할 수 있고,• None 다양한 노이즈 수준을 고려해 학습했기 때문에 다양하고 일관된 문장을 생성할 수 있습니다.autoregressive모델이 next token을 예측하는 것이라면, diffusion 모델은 쉽게 말해서 Mask token pr

디지털 마케팅의 업무 생태계, 이젠 ‘완전 자동화’ 가능1. 디지털 마케팅은 보통 다음과 같은 단계로 구성됩니다:이 중 하나만 자동화되어도 마케터의 업무는 크게 줄어드는데, 최근의 AI 기술 발전은 이 전 단계를 통합적으로 자동화할 수 있는 가능성을 열고 있습니다.특히 최근에는 Meta, Google, 틱톡에서 광고 완전 자동화 관련 기사화도 되었죠.빅테크 기업들은 각자의 생성형 모델을 통해 프로세스의 완전 자동화에 도전하고 있죠.2. 광고에서의 ‘생성’은 무엇이 다른가?많은 이들이 오해하는 부분이 하나 있습니다."AI 이미지 생성은 Midjourney처럼 뚝딱 만들어내면 되는 거 아닌가요?"Midjourney, DALL·E, Stable Diffusion과 같은 이미지 생성 모델은 새로운 이미지를 만들어내는 데 탁월하지만, 광고 소재 생성은 그와는 완전히 다른 맥락에서 접근해야 합니다.왜냐하면 광고는 다음과 같은 고정 요소가 있기 때문입니다:여기서 필요한 건 ‘창작’이 아닌어떻게 이 구성 요소를 ‘레이아웃’하여 자연스럽고 주목도 높은 이미지를 만들 것인가?입니다.핵심은 ‘레이아웃 최적화’와 ‘배경 생성’사용자 클릭을 유도할 수 있는 요소 배치를 실험하고 학습하는 알고리즘이 필요합니다.실제로 일부 플랫폼은 A/B 테스트를 수백 개 자동으로 생성해 최적 레이아웃을 찾습니다.제품 외의 이미지가 없을 때, 제품을 강조하기 위한 상황 컨텍스트 생성이 중요합니다.예: 카페용 제품이라면 "따뜻한 아침 햇살이 비치는 테이블 위"를 AI가 자동 생성.3. 기술적으로는 어떻게 작동할까?DALL·E 3, Stability AI, Runway 등에서 사용하는 기술.상품 이미지(예: 투명 PNG)를 넣고 그 주변을 자동으로 "상황"으로 채웁니다.(2) 멀티모달 모델을 활용한 광고 문구 + 이미지 생성 연동문장과 이미지 사이의 연관성을 학습한 CLIP 기반 모델을 활용해문구가 강조되는 위치를 중심으로 이미지 구성을 조정합니다.(3) 디자인 룰을 학습한 레이아웃 최적화 AIFigma, Canva 등에서 API 레벨로 실험 중.CTA 버튼, 제목, 제품 위치 등을 시선 분포와 클릭 데이터를 기반으로 자동 배치합니다.4. 레이아웃모델을 활용하여 샘플로 광고용 이미지를 만들어보겠습니다.실제 사례: 우리가 개발한 광고 소재 자동 생성 파이프라인• None Step 2. 레이아웃 생성 (로고/텍스트/버튼 자동 배치)다음 파트에서는 이 핵심 기술인 레이아웃 생성 모델을 전격 분석합니다.

네이버 사내 기술 교류 행사인 NAVER ENGINEERING DAY 2025(5월)에서 발표되었던 세션을 공개합니다.이 세션에서는 서비스를 운영하는 운영 담당자들이 AI를 활용하여, 운영 피로도를 낮추면서 운영 품질을 향상시키기 위한 방법을 소개합니다. 너무 많은 알림을 받고 있으나, 실제로 장애로 연결되지 않는 Noise 알림때문에 운영 리소스가 낭비되고 있는 상황을 개선하는 방법을 소개합니다. 항상 똑같은 대응을 반복하는 (로그 분석, 원인파악, 장애공유, 대응책 수립, 복구 수행) 운영담당자분들이 AI를 활용해서 더 빠르고 신속하게 장애를 대응할 수 있도록 합니다.• 데이터 파이프라인을 개발 및 운영하는 운영 담당자분들• AI를 서비스 운영에 활용하는데 관심이 있는분들NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 매회 평균 70개 이상의 발표가 이루어지는 NAVER ENGINEERING DAY를 빼놓을 수 없는데요. 2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다. 올해 진행된 NAVER ENGINEERING DAY의 일부 세션을 공개합니다.

안녕하세요. 무신사에서 이벤트, 전시 개발을 리딩하고 있는 장진달입니다. 매년 여름과 겨울, 저희는 무진장 이라는 이름의 대규모 할인 이벤트를 진행합니다. 이는 단순한 세일 행사가 아니라, 저희 기술 조직에게는 한바탕 치러야 할 거대한 전쟁과도 같습니다. 고객과 입점 브랜드 모두에게 최고의 경험을 선사해야 한다는 무신사의 철학은, 이 기간 동안 시스템의 안정성이라는 이름으로 시험대에 오릅니다.2025년 여름 무진장 이벤트를 앞두고, 저희에게 주어진 목표는 명확했습니다. 이벤트 피크 타임의 분당 매출 1억 원, 분당 주문 약 1만 건을 안정적으로 처리하는 것입니다. 이 숫자를 기술적인 언어로 번역하면 심장이 멎을 듯한 수치가 나옵니다. 이벤트 전시 페이지에만 분당 약 400만 건의 요청(RPM, Requests Per Minute) 초로 환산하면 대략 약 6만 7천 건의 요청(RPS, Requests Per Second) 즉, 폭풍처럼 몰아치는 상황을 버텨내야 한다는 의미입니다.이 글에서는 거대한 트래픽 쓰나미 앞에서 무너지지 않기 위해 어떤 기술적 고민을 했고, 어떤 아키텍처를 구축했으며, 어떤 시행착오를 겪었는지에 대한 솔직한 기록입니다. 이 전쟁을 성공적으로 치르기 위해 저희가 구축한 세 가지 핵심 방어선을 소개하고자 합니다.수백만 사용자의 동시 접속을 막아내는 이벤트 전시 시스템폭주하는 주문을 완벽하게 처리하는 주문/재고/쿠폰 시스템단 한순간의 장애도 용납하지 않는 안정적인 운영 시스템입니다.1부: 초당 6만 6천 요청, 트래픽의 최전선을 사수하라_이벤트 전시 페이지 시스템 구축이벤트가 시작되는 순간, 트래픽의 최전선은 바로 고객이 상품을 탐색하는 전시 페이지 입니다. 이곳이 무너지면 고객은 상품을 보지도, 구매하지도 못하기 때문입니다.분당 400만 건에 달하는 요청은 대부분이 상품 정보를 조회하는 읽기(Read) 작업에 해당합니다. 따라서 이 막대한 읽기(Read) 트래픽을 효율적이고 안정적으로 처리하면서, 핵심적인 쓰기(Write) 작업인 주문 시스템을 보호하는 것이 저희의 첫 번째 과제였습니다.1 1. 읽기(Read)와 쓰기(Write)의 분리, CQRS 아키텍처 도입과거 모놀리식 아키텍처(Monolithic Architecture) 시절, 저희는 뼈아픈 경험을 했습니다. 상품을 조회하는 요청과 주문을 생성하는 요청이 모두 동일한 데이터베이스를 바라보는 구조였습니다. 이로 인해 이벤트가 시작되자 읽기 요청이 폭주해 데이터베이스 커넥션 풀(Database Connection Pool)이 소진되면서 정작 돈이 되는 주문 처리(쓰기)가 불가능해지며 전체 서비스가 마비되는 상황이 반복되었습니다.이 문제를 근본적으로 해결하기 위해 저희는 CQRS(Command Query Responsibility Segregation, 명령과 조회의 책임 분리) 패턴을 전시 시스템의 핵심 아키텍처로 도입했습니다. 개념은 간단합니다. 사용자의 행위를 상태를 변경하는 명령(Command) 과 상태를 조회하는 쿼리(Query) 로 명확히 분리하고, 각각에 최적화된 시스템을 구축하는 것입니다.Command(명령) 모델: 주문 생성, 재고 차감 등 데이터의 일관성이 중요한 쓰기 작업은 기존처럼 안정적인 트랜잭션 데이터베이스(AWS Aurora)에서 처리합니다.Query(조회) 모델: 상품 목록, 상세 정보 조회 등 빠르고 대규모 처리가 필요한 읽기 작업은 별도의 조회 전용 데이터 저장소를 사용합니다.저희의 선택은 Redis였습니다. 이벤트에 필요한 모든 상품 데이터(상품명, 가격, 할인가, 이미지 URL 등)를 사전에 가공하여 머티리얼라이즈드 뷰(Materialized View) 형태로 Redis에 저장하는 방식입니다.그 결과, 분당 400만 건의 전시 페이지 요청은 데이터베이스에 전혀 도달하지 않고, 전부 Redis의 인메모리 캐시에서 초고속으로 처리됩니다. Redis는 밀리초 미만의 응답 속도를 제공하며, 트랜잭션 데이터베이스와 독립적으로 확장할 수 있어 읽기 트래픽을 효과적으로 격리하고 흡수하는 방파제 역할을 완벽하게 수행합니다.물론 CQRS에는 최종적 일관성(Eventual Consistency)이라는 과제가 따릅니다. 쓰기 데이터베이스의 데이터 변경이 조회용 Redis에 반영되기까지 약간의 시간차가 존재하기 때문입니다.저희는 이 데이터 동기화 문제를 해결하기 위해 CDC(Change Data Capture) 파이프라인을 구축했습니다. 이는 AWS DMS나 Kafka 같은 이벤트 스트리밍 기술을 활용하여, 쓰기 데이터베이스의 변경 로그를 실시간으로 감지하고 조회용 Redis에 반영하는 방식입니다. 이로 인해 발생하는 몇 초간의 데이터 지연은, 서비스 전체가 마비될 수 있는 위험을 감수하는 것보다 훨씬 합리적인 비즈니스 트레이드오프(Trade-off)였습니다.이 아키텍처적 분리는 단순히 성능 최적화를 넘어, 전시 시스템과 주문 시스템 간의 의존성을 끊어내는 강력한 장애 격리 수단이 되었습니다. 만약 주문 데이터베이스에 문제가 발생하더라도, 고객들은 Redis에 캐시된 데이터를 통해 끊김 없이 상품을 둘러볼 수 있습니다.1 2. 1바이트의 전쟁: Redis 데이터 압축 최적화CQRS와 Redis 도입으로 데이터베이스 병목은 해결했지만, 새로운 병목이 고개를 들었습니다. 바로 네트워크 대역폭과 Redis 메모리 사용량이었습니다. 분당 400만 요청을 처리한다는 것은 Redis와 저희 애플리케이션 서버 간에 엄청난 양의 데이터가 오간다는 뜻입니다. 특히 복잡한 상품 정보를 JSON 형태로 직렬화(Serialization)하면 데이터 크기가 수십 킬로바이트(KB)에 달할 수 있습니다. 이 거대한 데이터 덩어리들이 네트워크를 가득 채우면, 피크 타임에 응답 시간의 p99(99th percentile) 값이 급격히 치솟는 원인이 됩니다. 또한, 수백만 개의 상품 데이터를 압축 없이 저장하는 것은 막대한 메모리 비용을 초래했습니다.이 두 가지 문제를 동시에 해결하기 위해 저희는 데이터 압축을 도입하기로 했습니다. 하지만 압축 알고리즘 선택에는 신중한 접근이 필요했습니다. 단순히 압축률이 높은 것만이

No-Code 자동화 툴인 n8n과 Open WebUI를 활용하여 간단한 예제를 만들어보고자 합니다.n8n의 Docs를 확인해보면, API가 있는 다양한 서비스들을 연결하거나 No-Code 또는 Low-Code로 데이터를 조작할 수 있도록 도와주는 자동화된 워크플로우 툴입니다.• None 커스터마이징 가능: 고도로 유연한 워크플로우와 커스텀 노드를 구축할 수 있음• None 편리함: n8n을 npm이나 Docker로 사용할 수 있고(Self-Hosted) 클라우드로도 사용 가능n8n Self-hosted 방식은 Docker 혹은 npm으로 설치할 수 있습니다. 사내 개발환경에서 docker 사용이 불가하기 때문에ㅠㅠ npm으로 설치하였습니다.npm 사용시 node 버전은 18 버전 이상이여야 합니다. 명령어로 글로벌하게 다운받아 사용해주시면 됩니다.Open WebUI와 LLM 워크플로우는 챗봇 중심의 간단한 답변 시스템을 만들 수 있습니다.하지만 n8n을 활용하면 다양한 역할을 하는 노드들을 엮어 AI 에이전트의 서버를 개발할 수 있다는 점입니다.또한, 저처럼 백엔드 개발하시는 분들은 불필요하게 프론트엔드 작업을 할 수고가 적어지는 것 같습니다.이 예제에서 만들어 볼 간단한 workflow를 구성해 볼 것입니다.외부의 request를 트리거로 작성된 workflow를 시작하게 하는 노드입니다. 즉, 특정 이벤트 발생시 workflow를 실행하는 노드입니다.Webhook 설정에서 HTTP Method(DELETE, GET, POST, PATCH, HEAD, PUT)을 선택할 수 있으며, Path, Authentication, Respond 등 선택하여 이벤트를 받아올 수 있습니다.• None• None Immediately: 요청 받자마자 즉시 응답, 워크플로우가 끝나는 것을 기다리지 않고 바로 응답을 돌려줌, 즉, 워크플로우의 실행 결과와 응답 내용이 아무런 관계가 없을 때 “받았습니다”만 빨리 알려주고 싶은 경우에 사용• None When last node finishes: 워크플로우의 마지막 노드까지 실행이 끝나고 나서 응답을 돌려줌, 예를 들어서 외부 서비스인 Slack의 응답값을 이용하고 워크플로우 실행의 결과를 응답으로 보내야할 때 사용함, 워크플로우를 어떻게 구성했느냐에 따라 시간이 초과되어 외부서비스가 timeout 날 가능성이 있음• None Using ‘Respond to Webhook’ Node: Webhook 노드 에서는 요청을 받아만두고 워크플로우 안에서 를 이용하여 내가 원하는 시점에 응답하도록 함, 즉, 조건에 따라 다른 응답 시점과 내용도 자유롭게 커스터마이징해서 사용이 예제에서는• None 으로 설정하고 진행하겠습니다.Webhook과 바로 연결된 AI Agent node를 생성하여 연결해보도록 하겠습니다.• None• None webhook에서 입력한 json.body.chatInput을 참조하게 됨(open WebUI에서 Function 입력 기본값, 변경가능)• None Language Model: OpenAI Chat Model (다른 모델도 사용가능)Webhook 노드를 Using 'Respond to Webhook' node 로 설정했기 때문에, Respond to Webhook 노드 설정이 필요합니다.• None Respond With: 외부 요청에 응답할 데이터를 어디서 가져올지 정함• None All Incoming Items: 들어온 모든 데이터를 JSON 배열로 응답• None Binary File: 워크플로우 중간에 처리된 파일을 응답으로 직접 전송, HTTP Header에 Content-Type도 파일 확장자에 맞게 자동 설정됨• None JSON: JSON 에디터에 직접 json 응답을 작성하여 지정하여 이 값이 그대로 나감• None JWT Token: JWT 토큰 형식으로 응답 전송, Secret로 설정• None No Data: 204 No Content 같은걸 나타낼때 사용, 받기는 했으나 응답할 내용이 없을 때• None Redirect: 브라우저나 클라이언트를 다른 주소로 보냄, Location Header 자동 설정됨Save하여 진행상황을 저장하고, Inactive를 Active로 전환하여 플로우를 실행할 수 있도록 변경하면 됩니다.Execute workflow 버튼을 눌러 지금까지 구성한 Workflow를 확인해보겠습니다.저는 Postman을 이용하여 n8n webhook에 트리거를 주었습니다.200 OK status code와 함께 model이 생성한 output을 응답으로 받은 것을 확인할 수 있습니다.그렇다면, n8n으로 만든 workflow와 Open WebUI를 연결해보도록 하겠습니다.Open WebUI는 로컬 환경에서 LLM 모델을 적용하고 웹 인터페이스로 다양한 상호작용을 할 수 있는 환경을 제공합니다.간단하게 설치과정을 요약하자면, docker, pip 등 방식이 있는데 마찬가지로 사내환경에서 docker가 안되기 때문에… pip로 설치하였습니다.저는 파이썬 개발은 PyCharm을 이용하고 있어서, Python Packages에 open-webui를 검색하여 설치하였습니다.Open WebUI 서비스 구동은 open-webui serve 로 실행시키면 됩니다.Open WebUI를 실행시키고 로그인을 진행한 후,• None 새로운 창에서 Functions - N8N Pipe 검색• None 목록에서 N8N Pipe 클릭, open webui 주소를 localhost:8080 설정하고 Import to WebUI• None N8N Pipe Function 옆에 톱니바퀴를 눌러서 N8N Url(http://localhost:5678/webhook-test/n8n)으로 수정 및 실행• None 메인에서 N8N Pipe로 설정 후, 채팅창에 원하는 말을 입력(chatInput)마지막으로, chatInput을 아무거나 입력해서 보내면 성공적으로 n8n으로부터 응답이 오는 것을 알 수 있습니다.앞으로 적용해보고 싶은 것들?RAG와 MCP server를 추가해서, 더 다양한 데이터를 기반으로 업무와 관련된