hye2story 님의 블로그

ai 에이전트로 병목 해결하기 (1)

hye2 이야기 — Tue, 3 Mar 2026 02:24:11 +0900

요즘 인스타그램 계정을 운영하면서 가장 크게 부딪힌 병목이 두개 있었다.

나는 그동안.... 여러 이론(만)을 학습해온 경험이 있으니 실전으로 자동화를 도입해보고자 한다.

1. 문제상황 인지

(1) 여러 플랫폼에 올려야 하는 문제

우리는 인스타와 틱톡, 핀터레스트를 연동하여 계정을 운영하고 있었는데

계정을 바로 연동하여 인스타그램에 업로드하면 바로 자동업로드가 되는 핀터레스트와 달리

틱톡과 인스타는 각각 올려야 하는 문제가 있었다.

하지만 우리의 시스템 상

피그마에 export 하며 다운받기 > 전체 단톡에 올려 한번 컨펌 받기 > 인스타그램 올리기 > 틱톡 올리기

이렇게 허들이 많아 틱톡 올리는 걸 빼놓기 일쑤였고 이것은 매우 큰 병목으로 다가왔다......ㅠㅠ

(2) 콘텐츠 고갈 문제

아무래도 발빠르게 흘러가는 트렌드를 알고, 트렌드에 맞추어 게시글을 업로드 해야하다보니,

콘텐츠를 체크하는 것이 또다른 허들이었다.

당연히 계속해서 다른 게시글을 체크하고, 실시간으로 짬짬히 기사를 보는 것도 도움이 되었지만

다른 본업이 있는 이상...이게 잘 안됐다.

그러다보니 아무래도 우리가 업로드를 하면

이미 트렌드가 지나있거나,

이미 다른 곳에서 더 질좋은 콘텐츠로 업로드를 더 빠르게 했거나

놓치는 트렌드도 많았다.

그래서 나는..콘텐츠를 빠르게 알아내

이 콘텐츠 내에서 우리가 만들만한 트렌드한 콘텐츠를 찾고자 했다.

2. 뭘 만들어볼까?

그러니까! 나는 두개의 에이전트가 필요했다.

(1) 인스타그램과 틱톡, 그리고 더 나아가 다른 플랫폼까지 자동으로 업로드 해줄 수 있는 에이전트

(2) 트렌드를 발빠르게 가져오는 마케팅 에이전트

어떻게 해보면 좋을까?

인스타그램과 틱톡은 은근히...같으면서도 다르다.

우리는 인스타그램 게시글을 올릴 때

캡션에 제목과 내용을 다 포함하여 캡션 하나로만 올리고

(왼) 인스타그램 게시글 업로드 (오) 틱톡 게시글 업로드

틱톡을 올릴 때는

제목과 내용을 분리하여 올리게 된다.

인스타그램은 계정들을 태그해야할 때가 많고, 틱톡은 계정을 태그하지 않는다.

그리고 두 계정의 공통점은 음악을 추가한다는 것이다.

정리를 해보면

	인스타그램	틱톡
음악 여부	O	O
제목 여부	X	O
내용 여부	O (내용에 제목 포함)	O (제목과 분리)
계정 태그	O	X
예약 업로드	X	X

이런 내용들이 있다.

즉 우리의 자동 업로드 에이전트는
플랫폼별 특성을 잘 알고, 콘텐츠를 플랫폼 별 특성에 맞게 업로드 해줘야 한다.

두번째로 가장 큰 핵심은
마케팅 에이전트는 가장 빠르게!! 우리의 계정에 맞게 제공해줘야 한다.

사실 뉴스 자동화나 콘텐츠 자동화 기능은 참고할만한 내용들이 많다.

특히 내가 좋아하는 지피터스에..

뉴스레터 자동화와 매일 아침 뉴스 받기 자동화

소개 클로드 자동화를 통한 뉴스레터 만들기를 시도해 보았습니다. 그리고 n8n을 이용해서 슬랙으로 뉴스 정리해서 보내주기를 시도해 보았습니다. 진행 방법 클로드와 노션을 이용해서 뉴스레

www.gpters.org

그렇다면 기능은 대~충 어떻게 해야할지 알겠다.

요거를 만드려면 두가지를 따져야 했다.

첫째!!!! 어떤 내용을 받을것인가?

(1) X, 인스타그램, 유튜브 등의 소셜 계정에서 자주 언급되는 밈이나

(2) 뷰티, 패션 쪽의 소식이나

(3) 인스타그램에서 '조회수나 좋아요가 많은' 게시글

이 기준으로 제공받아야 했다.

둘째!!! 어떤 매체로 내용을 받을 것인가?

자동화한 사례들을 참고해보면,

자동화한 콘텐츠를 뉴스레터로 받거나,

커서로 뉴스레터 처음 만들어보고, 이메일 발송까지

지난 일요일 실습 시간에 배웠던 내용을 복기해보고자, 직접 뉴스레터를 기획하고 작성해보았습니다. 커서(Cursor)를 활용해 뉴스레터를 디자인하고, React 기반 이메일로 발송하는 전 과정을 다시

www.gpters.org

슬랙으로 받거나

(2편) 슬랙에서 뉴스도 대화도! 세 가지 AI Agent로 만들어 본 작은 자동화 실험 ⚙️

소개 이 글은 (1편) 반복 업무 탈출! n8n + AI로 만드는 뉴스 자동화 시스템에 이어지는 두 번째 이야기입니다. 1편에서는 Slack 메시지를 트리거로 받아 단일 AI Agent와 코드 노드를 통해 관련 뉴스를

www.gpters.org

하여튼 다양한 플랫폼을 활용할 수 있었다

그렇담 나는 어디를 할것인가......

바로바로

우리의 회의록과 여러 내용들이 오고가는

>노션<!

3. 노션을 연결하여 자동화 에이전트를 구축해보자

노션 MCP 에는 다양한 AI 도구를 연결할 수 있게끔 되어있다.

(실제로 나도 회사에서는 클코를 연결하여 엄청 수월하게 문서를 작업하고 있다.)

나는 클코와 Zapier를 연결하여 자동화를 시도해보려고 한다.

앞으로 요 자동화 프로세스에 관해서 다양한 시행착오(~~와성공사례...)를~~ 공유해보겠다......!!!!!

[인사이트] AI 시대의 리텐션, 첫 유저가 가장 핵심 유저다

hye2 이야기 — Wed, 14 Jan 2026 20:15:24 +0900

AI 시대의 리텐션, 첫 유저가 가장 핵심 유저다

AI 세계에서 마법 같은 일이 벌어지고 있다. 초기 리텐션이 낮은 게 당연하던 게 아니라 일부 AI 제품들이 첫 유저 코호트부터 놀라울 정도로 높은 리텐션을 달성하고 있다.

blogbyash.com

▶︎ 해당 아티클에서 발췌한 내용입니다!

일부 AI 제품들은 첫 유저 코호트부터 놀라울 정도로 높은 리텐션을 달성하고 있다.

기존의 서비스들은 초기 리텐션은 고된 여정으로 보았다.

흔한 전략은 기능이 빈약한 MVP를 먼저 출시하고 유저들이 붙잡아 주길 바라면서 이를 보강하느라 정신없는 작업을 한다.

초기에는 반복적인 개선을 당연히 예상하고 있는 것이다. 창업자들은 반복 개선이 탈주한 유저들을 되돌리기 위해 엄청나게 노력을 하는 것이다. 가진 걸로 출시하고, 초기 채택자들이 떠나는 것을 지켜보며(-어쩌면 당연하게 여기는), 리텐션을 높이기 위해 필사적으로 반복 작업을 한다. 훌륭한 리텐션은 금덩이지만, 출시 직후부터 달성하기는 악명 높을 정도로 어렵다.

이전, BK가 지적했듯이,

“리텐션은 앱의 생명혈이며 움직이기 가장 힘든 지표”다

우리는 이것을 당연하게 여겨왔다 !

하지만 옛날 전략들이 뒤집히고 있다.

일부 AI 제품들은 첫 유저 코호트부터 놀라울 정도로 높은 리텐션을 달성하고 있다.

마치 그 유저들이 정확히 원하던 걸 찾아서 절대 떠나지 않는 것처럼!!!

새로운 AI 전략: 구두가 딱 맞으면, 유저들은 자리를 지킨다.

이미지 출처: https://m.fashionn.com/board/read.php?table=style&number=10581

어떤 AI 제품들이 전형적인 MVP-이탈 패턴을 거스르는 이유는 뭘까?

그 답은 우리가 신데렐라 유리구두 효과라고 이름 붙인 가설에 있다고 한다.

신데렐라 본인(=잠재 고객들) 이 해결책을 이
모델을 이것저것 계속 시도하며 완벽한 맞춤을 찾는다고 상상해 보자.

대부분의 제안들은 너무 헐거웠다거나, 너무 꽉 끼거나, 너무 해야 할 일에 딱 맞지 않는 경우가 대부분이다.
이러한 고가치 문제들을 미해결 워크로드(unsolved workloads)라고 불러보자.

이러한 미해결 워크로드는 신데렐라의 발처럼
딱!맞는 유리구두를 기다리게 된다.

오늘날의 혼란스러운 AI 환경에서 개발자들은 어지러울 정도로 다양한 모델들을 실험하고 있다.

실제로
OpenRouter의 사용량이 1년 만에 10조 토큰에서 100조 토큰 이상으로 10배 폭증했다.
매일 새로운 엔드포인트가 추가되고 있다.
AI 실험이 아주 아주 폭주하고 있다는 얘기다!

각 릴리스마다 팀들은 재빨리 테스트하고 있다.

Q. 이 새로운 모델이 내 문제를 더 잘 풀어주나??

대부분의 경우 답은 “그냥 그렇다”인데,

그래서 이탈(churn)한다.

한 번 써보고 떠나는 AI “관광객”이 된다.

그렇지만, 신데렐라 구두를 완벽하게 찾는다면?

고집 센 고가치 문제를 놀라울 정도로 정밀하게 푸는 최첨단 모델이 등장했다.

그렇다면 신데렐라 구두를 완벽하게 찾은 것이다.

그들이 절실히 필요로 했던 것과 AI가 제공하는 게 완벽하게 맞아떨어지는 것이다.

이 유저들은 전형적인 초기 채택자처럼 이탈하지 않는다.

대신 발을 깊이 박고 버틴다.

모델을 제품이나 워크플로에 깊숙이 통합하고, 그 주위에 상당한 엔지니어링 노력을 투자하며, 사실상 락인된다.

우리는 이런 초기 끈끈한 유저들을 기초 코호트 라고 부른다.

이들은 종종 출시 직후, 모델이 최첨단으로 처음 칭송받을 때 나타난다.

근본적으로 새로운 무언가의 약속에 이끌려 오고, 그 약속이 실현되면 리텐션이 놀라울 정도다.

마치 제품이 그냥 유저 베이스를 찾은 게 아니라, 이상적인 유저 베이스를 첫날부터 바로 찾은 것 같다.

이건 전형적인 MVP 스토리와 완전히 반대다.

AI 시대의 서비스에서는 초기 코호트가 나중에 오는 코호트보다

더 나은 장기 리텐션을 보일 수 있다.

AI에서는 초기 코호트가 나중에 오는 코호트보다 더 나은 장기 리텐션을 보일 수 있다.

왜 후발 유저들이 덜 충성스러운가?

“유리구두” 코호트가 맞는 걸 찾은 뒤에는, 후속 유저들은 대개 더 캐주얼하게 실험하거나 이미 다른 데서 필요를 채우고 있기 때문이다.

모델은 더 이상 반짝이는 새로운 최첨단이 아니다.

이제 수많은 도구 중 하나일 뿐이고, 충족되지 않은 니즈가 있으면 이들은 다음 유행 모델로 뛰어든다.

반대로 기초 코호트는 완벽한 짝을 찾았기 때문에 확고하게 자리 잡고 있다.

초기 코호트가 중요해진 이유

Product-Market Fit(=Worklad-Model Fit)

AI에서 product-market fit을 달성한다는 건 말 그대로 한 고가치 워크로드를 누구보다 잘 푸는 걸 의미할 수 있다.

광범위한 기능 세트가 아니라 핵심 영역에서의 깊이가 더 중요하다.

그 완벽한 타점을 찌르면 리텐션이 자연스럽게 따라온다!

저들이 오랫동안 갈망하던 걸 마침내 얻기 때문이다.

선도자 우위, 재정의

시장에 먼저 나오는 게 항상 성공 보장은 아니다

다만 먼저 나오는 게 급한 문제를 최상으로 푸는 걸 의미할 때 말이다.

유리 구두 효과는 새로운 능력 수준을 먼저 달성한 모델이 그 능력에 대한 충성 유저의 사자 지분을 락인한다는 걸 시사한다.

그 유저들은 나중에 빼내기 매우 비용이 많이 든다. 이제 모델 주위에 워크플로, 비즈니스, 심지어 사고 습관까지 구축했기 때문이다.

경쟁 모델로 바꾸려면 재훈련 비용, 품질 리스크, 엔지니어링 작업이 들고...원래 쌍을 묶어두는 높은 마찰이다.

비즈니스 용어로 이건 높은 전환 비용으로 인한 전형적인 락인이다.

리텐션, 북극성 지표로 삼기

새로운 AI 도구들의 골드러시에서 성장(가입, 채택)이 전부라고 생각할 수 있다.

하지만 똑똑한 창업자들은 리텐션 곡선에 똑같이 신경 쓸 거다.

기초 코호트가 형성되는 조짐이 있는가?

적어도 한 유저 세그먼트가 당신의 서비스를 필수로 여기는가?

모든 코호트가 빠른 드롭오프로 똑같이 행동한다면 레드 플래그다

차별화에 더 힘을 쓰거나 더 구체적인 pain point를 노려야 할 수 있다.

반대로 한 코호트가 나머지보다 훨씬 잘 붙잡힌다면 그들을 연구하자!

그들은 네 유리구두 착용자들이고, 제품이 왜 그들의 니즈에 맞았는지 이해하면 로드맵을 안내할 수 있다.

최첨단 창은 좁다

데이터는 “최첨단 모델”의 시장 왕관이 일시적이라는 걸 보여준다.

각 새 모델은 다음 경쟁자가 올 때까지 짧은 창동안만 최첨단으로 여겨진다.

이는 AI 회사들이 그 희귀한 기초 유저들을 잡을 짧은 기간이 있다는 뜻이다.

가장 사로잡기 힘든 유저들(=미충족 니즈를 가진 이들) 을 감동시킬 일회성 기회다.

그 창을 놓치면 점진적 개선의 참호전에서 싸워야 한다.

AI 스타트업에겐 론칭 압박을 높인다: 거의 올인 아니면 아웃에 가깝다.

제대로 맞히면 업사이드가 크다(굳건한 유저들, 어쩌면 니치에서 준 독점).

중간 론칭의 다운사이드는 가파른 이탈과 나중 차별화의 오르막길이다.

결론: 유리 구두 순간을 위해 구축하기

신데렐라 유리 구두 효과는 화려한 비유 이상이다.

AI가 제품 채택과 리텐션 규칙을 다시 쓰는 방식을 반영한 것이다.

새로운 서비스들이 끊임없이 나오고 개발자들이 간단한 API호출이나 기술로 갈아탈 수 있는 세상에서

유저 충성심은 순간적인 것처럼 보일 수 있다.

하지만, AI제품이 깊은 니즈를 진짜로!!! 충족시키면

관광객이 아니라 팬들 만든다.

그 초기 팬들은 풍파를 견디며 남아,

전체 비즈니스를 세울 수 있는 기반을 제공하게 된다.

AI 창업자와 빌더들에게 명확한 지침이 있다

시장의 미해결 고가치 문제들을 파악하라.
군중 속에서 '그럭저럭' 인 반쪽짜리 범용 모델을 만드는 대신,
좁더라도 그 중 하나를 완벽히 푸는 첫 번째가 되도록 목표를 세워라.

진열대 위 또 다른 구두가 되는 것과,

그것을 찾던 발에 딱 맞는 유리 구두가 되는 차이다.

결국 AI의 다음 국면 이야기는 누가 더 크거나 빠른 모델을 가졌는지에 그치지 않을 수 있다.

“우리가 딱 필요로 하던 유저들을 찾았고, 4개월이 지나도 여전히 함께다”라고 말할 수 있는 이들이 써낼 거다.

그게 완벽한 맞춤의 마법이다

참고

https://blogbyash.com/translation/cinderella-glass-slipper-effect/

https://oswarld.com/kor/insight/251208_glass-slipper-retention

[AI] 2026 AI 트렌드는 어떻게 될까?

hye2 이야기 — Mon, 12 Jan 2026 01:43:52 +0900

[NIA 한국지능정보사회진흥원]

우리는 디지털로 사회 현안을 해결하고, 국가 미래를 열어가는 국가 디지털 대전환 선도기관 NIA한국지능정보사회진흥원입니다.

www.nia.or.kr

한국지능정보사회진흥원(NIA) 에서 올려주는 자료들이 유익한 자료가 굉장히 많은데

요번에 올라온 'AI 주요 트렌드 및 2026 전망' 레포트가 굉장히 유익해서 읽으면서 포스팅을 해봐야겠다!

산업, 기술, 정책이 서로 다른 변화 축을 보이고 있으나,
2026년에는 세 변화가 동시에 심화되며 AI 생태계 구조 재편이 가속화될 가능성이 있다!

산업 측면에서는 도입 확대,
기술 측면에서는 기능 고도화,
정책 측면에서는 책임, 안전 중심의 제도화가 각각 진전될 것으로 예상되며, 이러한 흐름은 AI 활용의 범위, 속도, 규율 체계에 모두 영향을 미칠 예정이다.

1. 분석 배경

2025년의 생성형 AI는 2024년도의 실험적 활용을 넘어 기업 운영 전반으로 빠르게 확산되어, AI가 산업의 핵심 인프라로 자리 잡는 도입 단계가 본격화되고 있는 단계이다.

(1) 투자 규모 확장

✔️ 글로벌 AI 투자 규모가 연간 50% 이상 성장하고 있으며, 기업들의 생성형 AI 도입 시도가 금융, 제조, 서비스 등 전 산업군으로 확산되며 비즈니스 프로세스의 자동화가 본격화되고 있다.

(2) 활용 영역 확장

✔️ 상담, 요약을 넘어 기획, 분석 등 고부가가치 업무로 확장되며, 기업 운영 방식 자체를 재정의하는 수준의 변화를 촉발하고 있다.

AI가 산업, 사회 전반으로 확산되며 이를 둘러싼 산업의 수요, 기술의 혁신, 정책의 대응이 상호 연계되는 복합적 변화를 맞이하고 있다.

✔️ AI기술은 모델, 데이터 규모 경쟁을 넘어 합성데이터, 멀티모달, 에이전트형 AI 중심으로 지능 구조 자체의 고도화가 진행되는 단계에 진입하여 있다.

(3) 한계 경계

✔️ 물론 어려운 점도 있다. OECD AI Incidents Monitor 에 따르면, 2010년대 후반 이후 AI 관련 사고, 위험 보고 건수가 지속적으로 증가하고 있으며, 2023-2024년 이후 특히 가파른 상승 추세를 보이고 있다.

✔️ 또한 산업, 기술 정책 간 변화 속도의 비대칭성으로 속도 격차 및 규제 지연이 확대되며, AI 확산이 성장과 리스크를 동시에 심화시키는 이중적 상황이 전개되고 있다.

따라서, AI 확산에 따른 구조적 리스크 대응 필요성이 크게 증가하고 있다.

2. 분석 과정

해당 레포트는 요 과정을 거쳐 데이터가 수집이 되었고, 해당 데이터에 따른 내용임을 밝힌다!

이미지 출처: '토픽 분석을 통한 AI 주요 트렌드 및 2026 전망' 레포트

연구 기간	2025년 1월~11월까지 매주
데이터 수집 방법	산업, 기술, 정책 세 분야별로 국내 매체, 해외 매체 1건씩 총 6건을 선정하여 정기적인 기사 및 보고서 스크랩을 통해 데이터셋을 누적하여 확보

✅이때 산업, 기술, 정책 분야 모두에서 상위 단어가 6~8개 주제 축으로 수렴하는 패턴을 보여 7개 키워드를 채택하여 포괄성과 해석성을 확보했다고 하였다.
그리하여, 분야 간 키워드 수를 동일하게 맞춤으로써 비교 과정에서 기준 차이에 따른 왜곡을 최소화하였고,
반복 등장한 핵심 상위 빈도 핵심어 중 대표성이 가장 높은 단어를 기반으로 선정하게 되었다고 한다.

3. 2026의 AI 시장의 전망은? ✍

✅⭐️ 선도 기업을 중심으로 내재화가 빠르게 진행되며 시장 규모가 지속 확대될 전망

(1) 기업 운영 인프라로 자리 잡아갈 예정

✔️ AI 활용이 여러 산업군에서 실험 단계를 넘어 일부 핵심 공정과 서비스 운영에 본격 도입되기 시작하면서

AI가 기업 운영 인프라로 자리 잡아가는 흐름이 확산될 가능성이 높다.

(2) 고부가 서비스 단에서 AI 활용 커질 예정

✔️의사결정, 운영, 고객 대응 등 주요 영역에 AI 가 통합되며

핵심, 공정 고부가 서비스단에서 데이터, AI 중심 구조로 이동하는 압력이 강화될 것으로 전망된다.

(3) 기업 간 시스템 연동 자동화 사례가 등장할 예정!

✔️ 기업 간(B2B) 시스템 연동을 통해 제한된 범위에서 AI간 협업 형태의 자동화 사례도 등장할 것으로 예상되지만,

26년에는 초기 단계에 머물 것으로 예상된다.

(4) ⭐️⭐️ 도메인 특화 데이터의 중요성 높아지고 있다! ⭐️⭐️

✔️ AI 활용이 확산되면서 고품질, 도메인 특화 데이터(버티컬 데이터)의 중요성이 크게 높아지고 있으며

데이터 확보, 관리, 유통을 둘러싼 생태계가 빠르게 성장하고 있다.

▶︎ 요 내용 관련해서 이전에 봤던 기사가 생각나서 첨부한다.

버티컬 AI관련한 내용!

챗GPT보다 강한 '팬덤' 잡았다…버티컬 AI 3사 성공 비결 | 혁신의숲(InnoForest)

[라이징딥테크] 챗GPT보다 강한 '팬덤' 잡았다…버티컬 AI 3사 성공 비결 디지털데일리와 마크앤컴퍼니의 스타트업 성장분석 플랫폼 ‘혁신의숲’이 인공지능(AI) 중심의 딥테크 시장 분석과 성장

www.innoforest.co.kr

요즘 AI 업계에서 ‘선택과 집중’은 생존과 직결되는 키워드로 꼽히고 있다.
지금이 ‘AI 대전환’ 시대라고 하지만, 초창기 우리가 흔히 상상했던 범용 AI 서비스 시장의 패권은 이미 오픈AI(챗GPT)와 구글(제미나이), 앤트로픽(클로드) 같은 소수의 글로벌 빅테크 기업에게 넘어갔다는 평이 지배적이다.

이런 상황에서 후발주자들의 뒤늦은 추격은 무의미해 보이고, 어려움이 커보인다. 글로벌 대규모 시장도 손익분기점을 넘지 못하는 가운데 자금, 시장 규모마저 열세인 한국의 기업들이 직접 경쟁에 나서 유의미한 성과를 내기는 어려워 보인다.

이에 최근 AI 산업에 정통한 전문가들은 ‘한국이 우선 AI 서비스 시장부터 공략하는 것이 현실적’이라고 입을 모아 조언하였다.
바로 ‘버티컬 인공지능(Vertical AI)’ 전략.

버티컬 AI란 ‘특정 분야, 타깃 고객 수요에 특화된 AI 기술 및 서비스’를 총칭한다.
응용 분야는 무한대에 가깝다. 금융, 법률, 의료, 제조 등 대단위 산업부터 작문, 검색, 요약, 이미지 등 한층 세분화된 소비자 수요에 대응하는 AI까지 포함될 수 있기 때문이다!

다만 모든 버티컬 AI 서비스에 요구되는 생존 조건은 동일하다.
그들의 목표로 설정한 영역만큼은 반드시 ‘범용 AI보다 나은 성능과 사용자 만족’을 달성하는 것이다.
나아가 대형 경쟁사들을 제치고 소비자의 지갑까지 열어야 하여 결코 쉬운 주제가 아니다. 일례로 그 유명한 오픈AI조차 올해 8월 기준, 챗GPT의 주간 사용자는 무려 7억명을 돌파했지만 유료 사용자는 500만명(0.7%)에 그친 것으로 알려져 있기 때문이다.

-챗GPT보다 강한 '팬덤' 잡았다…버티컬 AI 3사 성공 비결 아티클 발췌 [디지털데일리]

(5) 모델 내부 구조의 질적 개선 흐름 양상

✔️ 지능 구조 고도화와 데이터 한계 보완을 중심으로 진화할 것이며

학습 효율 향상, 복합 정보 처리, 설명 가능성 강화 등 모델 내부 구조의 질적 개선 흐름이 이어질 것으로 예상된다.

(6) 모델 신뢰성 기준 구축

✔️ 데이터 품질 표준화와 모델 신뢰성 평가 기준 구축이

기능 고도화 기술의 산업 적용 확산을 뒷받침할 핵심 인프라로 요구된다.

(7) AI 기본법 시행령, 가이드라인 구체화

✔️ EU AI Act 등 글로벌 규제와의 정합성을 높이기 위해 국내 AI 기본법의 시행령·가이드라인이 구체화되고,

수출 기업을 위한 규제 대응·인증 지원이 확대될 전망이다.

(8) AI 안전성 검증, 제3자 인증 필수화 예정

✔️ 의료·채용 등 고위험 AI의 안전성 검증과 제3자 인증이 필수화되고,

생성형 AI 부작용 대응을 위한 워터마크·딥페이크 탐지 기술이 법제화될 것으로 예상된다.

AI 관련한 전망들을 유심히 봤다.

AI 기술이 빠르게 발전하고 있는 요즘, 2026년엔 또 어떤 기술들이 빠르게 나올지 기대도 되고 궁금해진다!!

참고

[데이터분석] SQL 실무 예제로 공부하기-기획자의 SQL 책 리뷰

hye2 이야기 — Fri, 9 Jan 2026 16:00:58 +0900

SQLD 도 땄었고 SQL 문제도 자주 풀긴 했지만 실무 문제들은 풀 때마다 언제나 헷갈리는 것 같다.ㅠㅠ

또한 기획자들의 데이터분석은 또 그 요구조건이 다르기 때문에 고민하다가 이 책을 발견하게 되었다!

좋은 내용이 많아서 리뷰하며 정리한다!

기획자의 SQL | 조은성 - 교보문고

기획자의 SQL | 기획자에게 필요한 SQL은 따로 있다기획자는 데이터를 보는 관점이 개발자와 다르다. 기획자나 마케터, 일반 사무직에 이르기까지 많은 직장인이 데이터를 본다. 개발자와 달리 그

product.kyobobook.co.kr

0. SQL 의 종류 -까먹지 말기!

구분	명령어	실행
DML (Data Manipulation Language)	SELECT INSERT UPDATE DELETE	-데이터베이스에서 데이터를 검색 (SELECT) -테이블에서 새로운 행 삽입 (INSERT) -기존의 행 수정(UPDATE) -기존의 행 삭제(DELETE)
DDL (Data Definition Language)	CREATE DROP TRUNCATE	-테이블의 데이터를 정의하고 -구조를 생성하거나 -구조를 수정 또는 제거
DCL (Data Control Language)	GRANT REVOKE	-데이터베이스에 대해 접근 권한을 부여하거나 제거
TCL (Transaction Control Language)	COMMIT ROLLBACK SAVEPOINT	DML로 실행한 변경사항을 저장 관리

1. 컴퓨터에게 어떻게 명령어를 입력해야 할까?

SQL은 데이터를 가져올 때 사용하느 컴퓨터가 이해할 수 있는 언어이기 때문에

컴퓨터가 이해하기 쉽도록 명령해야 나의 요구 조건을 이해하고 실행할 수 있다.

우리가 무언가를 가져오도록 시킬 때

'무엇'을 가져와야 하는지
'어디에서' 가져와야 하는지

가 주요 포인트이다. 즉 데이터도 마찬가지다!

데이터 가져다 줘 전부 다
저장소 위치가 어디냐면 여기야
명령 끝!

요거를 SQL 명령어로 바꾸면

SELECT *
FROM [테이블명]
;

2. 조건 걸기 - WHERE

AND: 두 조건을 연결하며, 둘 다 참인 데이터를 조회한다.
BETWEEN: 시작 값과 종료 값을 포함하는 범위 내의 데이터 조회하며 시작 날짜와 종료 날짜를 포함한 값을 반환한다.
OR: 둘 중 하나라도 참이면 조건을 만족한다 / AND 와 OR 연산자 중 우선순위는 AND가 더 높다.
IN: 조건 값 중 하나라도 해당 컬럼의 값과 일치하면 해당 행의 데이터를 조회한다.
LIKE: 패턴 매칭 필터링을 가능하게 해준다. [컬럼명] LIKE [와일드카드] 형태로 작성한다.
- % 는 0개 이상의 임의의 문자열 패턴을 의미하는 메타 문자
- _는 임의의 문자 한 개를 의미하는 메타 문자
- []는 문자 집합을 의미하는 메타 문자
- NOT LIKE = 다음과 일치하지 않는
IS: null 값을 필터링할 때 사용
- ⭐️이 때, NOT을 추가할 때는 LIKE와 다르게 IS 뒤에 NOT을 붙인다.

WHERE은 여러 조건을 동시에 적용할 수 있으며, 조건의 개수에는 제한이 없다.
두 조건을 연결하여 둘 다 참인 데이터를 조회한다.

Q. 회원 정보 테이블 users에서
가입 일시(created_at)가 2010-12-01부터 2011-01-01까지인 회원 정보를 출력해보자

SELECT *
	FROM users
    WHERE created_at BETWEEN "2010-12-01" AND "2011-01-01"
    ;

Q. 회원 정보 테이블 users에서 거주 국가(country)가 이름이
s로 시작하지 않는 회원 정보만 추출해 보자

SELECT *	
	FROM users
    WHERE country NOT LIKE "S%"
    ;

Q. 회원 정보 테이블 users에서
가입 일시created_at) 컬럼 값이 null 이 아닌 결과만 출력해 보자

SELECT *
	FROM users
    WHERE created_at IS NOT null
    ;

Q. 주문 정보 테이블 orders에서
주문 일자(order_date)가 2015-07-01부터 2015-10-31까지가 아닌 정보만 추출하자

SELECT *
	FROM orders
    WHERE order_date NOT BETWEEN "2015-07-01" AND "2015-10-31"
    ;

3. 어떤 순서로 볼까? -ORDER BY

기본적으로 오름차순 정렬
컬럼을 기준으로 행 데이터를 오름차순, 내림차순 정렬
ORDER BY [기준 컬럼] [ASC/ DESC] 형태로 정리

Q. 회원 정보 테이블 users에서 가입 일시(created_at) 기준으로 내림차순 정렬하여 출력해 보자

SELECT *
	FROM users
    ORDER BY created_at DESC
    ;

Q. 주문 상세 정보 테이블 orderdetails에서 먼저 제품 아이디(product_id)를 기준으로 내림차순 정렬하고,
같은 제품 아이디 내에서는 판매 수량(quantity)값을 기준으로 오름차순 정렬하여 모든 칼럼 출력하라

SELECT *
	FROM orderdetails
    ORDER BY product_id DESC, quantity ASC
    ;

실무 적용!
Q. 최근 한 달 이내에 도서 구독 멤버십에 가입한 회원만 추출해 보자

SELECT *
	FROM 회원정보
    WHERE 가입일자 >= (오늘일자-1달)
    	AND 멤버십 가입여부 = 1;

Q. 2023-08-01에 주문한 내역 중
쿠폰 할인이 적용된 내역만 추출한다

SELECT *
	FROM 주문정보
    WHERE 주문일자="2023-08-01"
    	AND 쿠폰할인금액 >0;

4. 데이터를 그룹으로 묶어서 계산하자!

엑셀의 함수처럼, 데이터를 원하는 형태로 적절히 가공해서 사용할 때 사용한다!

(1) COUNT

지정된 컬럼의 null 을 제외한 행 수를 반환하는데, 이때 중보 값은 제거하지 않고 센다
DISTINCT와 함께 쓰면 중복을 제외할 수 있다.

Q. 제품 정보 테이블 products에서 최저가를 구해 보자

SELECT MIN(price)
	FROM products
    ;

(2) SUBSTR

문자열을 지정된 시작 위치부터 지정된 길이만큼 자른 결과 반환
입력 값으로 세 개의 값을 넣어야 하는데, 각각 '대상 컬럼', '시작 위치', '추출할 문자 개수'를 넣어야 한다.

실무 적용!
Q. 회원 정보 테이블 users에서 회원의 가입일자(day), 가입년월(month), 가입일시(created_at)을 출력해 보자

SELECT SUBSTR(ceated_at,1,10) AS day
	, SUBSTR(created_at,1,7) AS month
    , created_at
    FROM users
    ;

(3) 일반 함수(데이터 가공 혹은 변환)

함수명	의미	사용방법
ROUND	소수점 자리를 지정한 자릿수까지 반올림하여 반환	ROUND ([칼럼명] , [표시할 소수점 자릿수])
SUBSTR	문자열을 지정한 시작 위치로부터 지정한 문자 개수만큼 가져와 반환	SUBSTR ([칼럼명], [시작 위치], [가져올 문자 개수])
LENGTH	문자열의 길이 변환	LENGTH ([칼럼명])
UPPER	알파벳 문자열을 대문자로 변경	UPPER ([칼럼명])
LOWER	알파벳 문자열을 소문자로 변경	LOWER ([칼럼명])

Q. 회원 정보 테이블 Users에서
이메일(username)의 길이가 17자리 이하인 회원 수를 중복 없이 센 값을 출력하자

SELECT COUNT(DISTINCT id) AS userCNT
	FROM users
    WHERE LENGTH(username) <= 17
    ;

(4) GROUP BY

집계 함수는 특정 컬럼을 기준으로, 데이터를 그룹화한 후, 그룹별로 집계 함수를 적용하는 방식으로 동작한다.
GROUP BY 는 집계 함수와 함께 사용되며, GROUP BY의 기준 컬럼은 SELECT에서 집계 함수를 사용할 때 묶어서 계산을 수행하는 기준이다.
GROUP BY에 두 개 이상의 기준 컬럼을 추가하면 데이터가 여러 그룹으로 나뉘고, 지정된 컬럼의 순서에 따라 결과가 달라진다. 따라서 중요한 기준을 앞에 배치해서 그룹화를 먼저 수행해야 한다.

Q. 회원 정보 테이블 users에서
국가(country)별 회원 수를 구해 보자

SELECT country, COUNT(DISTINCT id) AS uniqueUserCnt
	FROM users
    GROUP BY country
    ;

실무 적용!
Q. 회원 정보 테이블 Users에서 거주 국가(country)가 한국(Korea)인 회원 중
마케팅 수신에 동의한 회원 수를 구해보자.
(동의:1, 비동의:0)

SELECT COUNT(DISTINCT id) AS uniqueUserCnt
	FROM users
    WHERE country='KOREA' AND is_marketing_agree=1
    ;

실무 적용!
Q. 회원 정보 테이블 users에서 월별 가입 회원 수를 구해 보자 가입 일시(created_at) 컬럼을 활용하고, 최신 순으로 정렬

SELECT SUBSTR(created_at,1,7) AS month, COUNT(DISTINCT id) AS
# 가입 일시를 정제해주기 위해 앞의 7의자리까지만 필요하다. 따라서 1번째부터 7번째자리까지 원하는만큼 잘라서 보여준다
uniqueUserCnt
	FROM users
    GROUP BY SUBSTR(created_at,1,7)
    ORDER BY month DESC
    ;

실무 적용!
Q. 주문 정보 테이블 orders에서 직언 아이디(staff_id)별, 회원 아이디(user_id)별로 주문 건수를 출력하라
(단, 직원 아이디 기준 오름차순으로 먼저 정렬한 뒤 주문 건수 기준 내림차순으로 정렬)

SELECT staff_id, user_id, COUNT (*) AS cnt
	FROM orders
    GROUP BY staff_id, user_id
    ORDER BY staff_id, cnt DESC
    ;

실무 적용!
Q. 주문 정보 orders테이블에서 월별로 주문한 회원 수 출력
(주문 일자(order_date)컬럼 활용하고, 최신 순 정렬)

SELECT SUBSTR(order_date,1,7) AS month, COUNT(DISTINCT user_id)
AS CntUser
	FROM orders
    GROUP BY month
    ORDER BY month DESC
    l

(4) HAVING

GROUP BY가 실행된 이후의 집계 함수 값을 필터링한다.
GROUP BY 가 SELECt문에 없다면 사용할 수도 없을 뿐더러 사용할 필요도 없다.
HAVING은 WHERE같이 조건 연산자로 여러 조건문을 연결할 수 있고, 연산이 적용되지 않은 기본 컬럼은 HAGING조건문에서 사용할 수 없다.

실무 적용!
Q. 주문 정보 테이블 orders에서 회원별 주문 건수 출력

(단, 주문 건수가 7건 이상인 회원의 정보만 추출하고 주문 건수 기준으로 내림차순 정렬하라 회원 아이디(user_id)와 주문 아이디(id)컬럼 활용

SELECT user_id, COUNT(DISTINC id) AS ordCNT
	FROM orders
    GROUP BY user_id
    HAVING ordCNT >=7
    ORDER BY ordCNT DESC
    ;

실무 적용!
Q. 2023-08에 음식 분류별 주문 건수 집계한다

SELECT 음식분류, COUNT(DISTINCT 주문아이디) AS 주문건수
	FROM 주문정보
    WHERE 주문시간(월) = '2023-08'
    GROUP BY 음식분류
    ORDER BY 주문건수 DESC
    ;

5. 데이터를 내가 원하는 대로 합쳐보자!

✔️ 두 테이블을 하나로 묶으려면 두 테이블에 공통된 key가 존재해야 한다.
✔️ FROM에 JOIN이 적용된 후에도 단일 테이블에 명령을 내리는 것처럼 쿼리를 작성하면 된다.
✔️ 두 컬럼 값이 일치하는 데이터만 가져오도록 비교 기준을 설정하는 것이 ON

(1) INNER JOIN

두 테이블의 키 값이 일치하는 행의 정보만 가져오는 것
교집합에 해당하는 정보만 가져온다
FROM [테이블1] a INNER JOIN [테이블2] b ON a. [테이블1의 Key 칼럼] = b. [테이블2의 key칼럼]
조건으로 제시된 키 값이 일치하는 행의 정보만 표시하며, 일치하는 값이없는 행은 결과에서 제외한다 -> 교집합!

(2) LEFT JOIN (LEFT OUTER JOIN)

두 테이블의 교집합과 교집합에 속하지 않는 왼쪽 차집합을 불러온다.
즉, 왼쪽에 있는 테이블 값을 모두 가져오기 때문에 LEFT OUTER JOIN이라고 한다.
한쪽 테이블의 값을 보전해야 할 때가 많아서 실무에서 자주 사용이 된다.
두 테이블을 결합하되, ON의 조건에 만족하지 않는 데이터도 모두 출력한다는 점에서 INNER JOIN과 다르다

Q. 회원 정보 테이블 users와 주문 정보 테이블 orders를 하나로 결합하여 출력해 보자
(단, 주문 정보가 없는 회원의 정보만 출력하자)

SELECT *
	FROM users u LEFT_JOIN orders o ON u.id=o.user_id
    WHERE o.id IS null
    ;

(3) CROSS JOIN

두 테이블 간의 모든 가능한 조합을 생성하는 데 사용된다.
ON 조건 없이 행의 모든 조합을 생성한다.
실제 운영 환경에서는 CROSS JOIN을 제한하는 편이다. 컴퓨터에 가장 많은 연산을 요구하기 때문이다!

(4) UNION

컬럼의 형식과 개수가 같은 두 데이터 결과 집합을 하나로 결합하는 기능
여러 가지 조건을 설정해야 하는 JOIN과 달리 UNION에서는 컬럼의 형식과 개수만 동일하면 결합이 가능하다.
결합하는 두 결과 집합에 대해 중복 제거 기능이 포함되어 있어서 컬럼 값이모두 같다면 중복을 제외한 결과를 출력한다.
UNION ALL 은 중복 제거 로직 없이 결합된 결과 값을 모두 출력하기 때문에 반복된 행을 확인할 수 있다.
UNION과 UNION ALL 사용할 때 두 대상의 컬럼 형식이 일치하는지 반드시 확인해야 한다. 컬럼 순서, 컬럼명, 컬럼 값의 데이터 타입이 모두 같아야 정상적으로 동작하기 때문이다!
개별 대상에 WHERE을 사용한 이후 결합하는 것이 더 좋다

(5) 서브쿼리 (sub query)

쿼리 결괏값을 메인 쿼리에서 값이나 조건으로 사용하고 싶을 때 쓴다
쿼리를 괄호로 감싸서 해당 쿼리의 결괏값을 메인 쿼리에서 활용할 수 있다.
SELECT에서는 단일 집계 값을 신규 컬럼으로 추가하기 위해 서브 쿼리를 사용한다. 여러 개의 컬럼을 추가하고 싶을 때 서브 쿼리를 여러 개 작성하면 된다. 메인쿼리의 FROM에서 사요오딘 테이블이 아닌 테이블에서도 사용이 가능하기 때문에 불필요한 조인 수행을 줄일 수 있다.

실무에서 놓치기 쉽지만 알아두면 써먹을 좋을 팁들!

✔️ 어떤 테이블의 모든 정보를 스캔하는 '풀 스캔'은 특별한 상황이 아니라면 피해야 한다.

해당 테이블에 데이터가 많이 저장되어 있으면 과부하가 걸려 제때 처리하지 못하기 때문이다! 단순히 데이터를 파악하고 싶을 뿐이라면 쿼리의 마지막 줄에 LIMIT 을 추가하여 일부 데이터만 가져와서 확인하는 습관을 가지자

✔️ 가능 여부를 나타내는 컬럼에서 주로 1은 TRUE, 0은 FALSE를 의미한다.

✔️ 실무에서는, UNION보다 UNION ALL 이 더 권장된다.

UNION을 사용하면 대량의 데이터를 대상으로 중복 항목을 제거할 때 컴퓨터에 무리한 연산 부하를 줄 수 있기 때문이다.

✔️ SQL 패턴 가이드!

⭐️ 기준별로 연산된 값을 보고 싶을 땐??

▶︎ 데이터 그룹화하기 : GROUP BY + 집계 함수

⭐️ 원본 테이블이 아닌, 쿼리를 실행한 결과 집합끼리 조합하고 싶을 땐?

▶︎ 데이터 결과 집합 결합하기 : JOIN + SUB QUERY

⭐️ 그룹화 기준 컬럼과 집계 연산을 수행할 컬럼이 서로 다른 테이블에 있을 경우엔?

▶︎ 테이블 결합 후 그룹화하기 : JOIN + GROUP BY

⭐️ 쿼리 결괏값을 다시 필터링 하고 싶거나, 쿼리 결괏값을 기반으로 동적 필터링을 하고 싶을 경우엔?

▶︎ 서브 쿼리로 필터링하기 : WHERE + SUB QUERY

⭐️ 같은 행동을 반복한 대상을 추출하고 싶을 경우엔?

▶︎ 리텐션 추출하기 : LEFT JOIN

실무 적용!
Q. 주문 정보 테이블 Orders에서 2015-12에 주문한 회원 중 2016-01에도 주문한 회원의 비율을 출력해보자.
(회원 아이디(user_id), 주문일자(order_date)컬럼을 활용해보자)

SELECT ROUND(COUNT(DISTINCT re.user_id) / COUNT(DISTINCT fst.user_id),
	AS retentionRatio
    FROM (
    	SELECT user_id
        	FROM orders
            WHERE order_date BETWEEN '2015-12-01' AND '2015-12-31' 
          ) fst
     LEFT JOIN
     (
     	SELECT user_id
        	FROM orders
            WHERE order_date BEWEEN '2016-01-01' AND '2016-01-31'
      ) re
      ON fst.user_id = re.user_id
      ;

실무 적용!
Q. 피자와 초밥 메뉴의 주문 건수와 매출액을 구해 하나의 테이블로 추출한다.

SELECT '피자' AS 메뉴, COUNT (*) AS 주문건수, SUM(가격) AS 매출
	FROM 주문정보 WHERE 메뉴아이디 = 1
UNION ALL
SELECT '초밥' AS 메뉴, COUNT (*) AS 주문건수, SUM(가격) AS 매출
	FROM 주문정보 WHERE 메뉴아이디 = 2;

책 총평!

✨✍ 서비스기획/ PM을 준비하고 있는 사람이라면 한번씩 봐두면 좋을 책!

기초부터 알려주는 이론 내용과 실무에서 직접 쓰일 법한 예제 문제들을 잘 다루고 있어 기획자들이라면 한번씩 보고가도 좋을 듯하다!

특히 책이 굉장히 꼼꼼하게 되어있어서 다양한 예제들과 패턴, 실무 학습법을 알려주고 있다.

내가 리뷰한 내용들 뿐만 아니라 굉장히 다양한 예제들이 많아 직접 읽어보면 좋을듯하다!~~

[UI/UX] 퍼널은 줄일수록 좋은걸까?

hye2 이야기 — Wed, 17 Dec 2025 19:04:20 +0900

1. 퍼널(Funnel) 분석 이란?

퍼널 분석이란, 전환 지점에 이르기까지의 일련의 이벤트를 분석하는 방법을 말한다.

제품, 웹사이트, 이메일 등 모든 종류의 디지털 접점에서 퍼널 분석을 할 수 있다.

퍼널 분석의 목적은 고객여정에서 중요한 이벤트를 정확히 파악하여, 테스트를 수행하고 사용자 경험을 개선하며 전환율을 높이는 것이다.

출처: https://po-sky.tistory.com/entry/퍼널-분석

각 퍼널을 정리해두면 얼마나 많은 사람이 최종에 도달하는지,

어디서 이탈을 하게 되는지 한눈에 파악할 수 있다.

각 단계를 통과할 때마다 사용자 수가 줄어들게 되는데 이 형태가 깔때기(Funnel) 모양이라 퍼널 분석이라고 말한다.

각각의 단계를 넘어가는 것을 전환(Conversion)이라고 부르고 이 비율을 전환율이라고 부르게 되는 것이다.

✍ 그 전에 잠깐! 사용자 행동 데이터에는 어떤 것들이 있을까?

(1) 서비스 데이터

서비스 운영을 위해서 반드시 필요한 데이터를 말한다. (가입, 결제, 회원가입 정보, 사용자들의 결제 내역 등)

예시를 들어보자! 온라인 쇼핑몰인데 회원 주소 정보가 없으면 물건을 사도 배송해주지 않을 것이다.

즉, 서비스 데이터는 별도로 저장해놓지 않으면 서비스를 운영할 수 없어서 저장을 꼭 해야하는 데이터이다.

이미지 출처 : https://datarian.io/blog/why-is-user-activity-log-analysis-important

(2) 사용자 행동 데이터

사용자들의 행동 패턴을 확인하기 위해서 별도로 저장하는 데이터이다.

웹 로그 데이터, 앱 로그 데이터, 이벤트 데이터 등 여러 이름으로 부르는데, 비교적 규모가 크고, 데이터 신뢰도는 서비스 데이터보다 낮다는 점이 있다. 당연히 언제든지 누락될수도, 중복 집계될 가능성이 있는 데이터이다.

웹사이트 페이지뷰, 스크롤, 클릭 등을 예시로 들 수 있다.

페이지뷰는 사용자들이 어느 페이지를 열람했는지를 확인할 수 있는 방문 기록에 대한 데이터, 스크롤은 어디까지 스크롤했는지, 클릭은 어떤 요소를 클릭했는지를 기록하는 데이터이다.

당연히 이 데이터는 없어도 서비스 운영 자체를 하는데에는 문제가 없어서 사용자 행동 데이터를 따로 심어서 봐야한다는 점이 있다.

이미지 출처 : https://datarian.io/blog/why-is-user-activity-log-analysis-important

2. 퍼널을 제대로 기획하면, 측정이 어려운 성과도 측정 가능해진다! -배민 사례로 알아보기

퍼널을 제대로 기획하면,

우리의 목표에 맞게 성과를 제대로 측정할 수 있는 방법이 되기도 한다.

해당 아티클에 인상적인 내용이 많아 내가 정리해봤다!

이 과제의 성과는 뭔가요? 지표 중심 커뮤니케이션이 불러온 변화 | 우아한형제들 기술블로그

배민앱에는 동네 사람들이 직접 추천하는 오프라인 가게와, 단골들이 남긴 후기를 주제별로 모아 볼 수 있는 서비스가 있습니다. 바로 "우리동네" 서비스인데요. 현재 송파구와 광진구에서 시범

techblog.woowahan.com

단순히 배고플 때 빠르게 주문하고 배달받는 배민앱의 목표와 달리, 배민우리동네 서비스의 경우,

유저가 동네의 콘텐츠를 소비하고, 새로운 콘텐츠를 생성하도록 하여 탐색을 활성화한다.

이를 통해 서비스에 깊이 관여하는 사용자를 늘리고, 서비스의 가치를 높인다.

가 목표였다.

따라서 단순히 결제 내역만으로 성과지표를 보는 것이 아니라 조금 더 정량적이고 구체적인 데이터가 필요했다.

이러한 각 과제의 성과를 제대로 파악하려면 ‘그래서 A와 비교했을 때 상대적으로 얼마나 좋아졌는가?’를 평가할 수 있어야 하는데
배민우리동네 서비스에서는 매번 새로운 콘셉트의 기능을 출시하고 있고

배달서비스에는 없는 UI/UX가 많아서 비교할 대상을 찾는 것이 쉽지 않았다.

그래서 특정 기능의 배포 전과 후 지표가 어떻게 바뀌었는지를 먼저 확인했는데요. 기존까지 인지하지 못했던, 분석 커뮤니케이션 오류를 발견했던 사건이 있었다.

바로 신규 서비스를 개설하고 CTR비교하여 팀에 공유하였더니 오픈 전과 후에 191% 증가했다는 성과가 발표되었다고 한다.
191%????

아무리 봐도 오버측정된 지표같은데... 당연히 배민팀에서는 이를 커뮤니케이션의 오류로 인식하고 문제를 해결하기 위한 퍼널전략을 세웠다.

사용자 행동 목표를 가지고 사용자 행동 기반의 퍼널 만들기

기존 배달앱이 ‘홈 – 가게목록 – 가게상세 – 장바구니 – 주문완료’와 같이 주문 단계에 따라 퍼널을 정의했다면
배민우리동네는 콘텐츠 관여 정도에 따라 사용자를 5개의 그룹으로 나누었다.

Visitor: 서비스를 처음 방문한 사용자
Browser: 콘텐츠를 둘러보기 시작한 사용자
Reader: 콘텐츠를 클릭해 읽기 시작한 사용자
Heavy Reader: 여러 콘텐츠를 깊이 탐색한 사용자
Liker: 콘텐츠에 좋아요, 팔로잉 등 리액션을 한 사용자
Content Creator: 직접 콘텐츠를 생성하는 사용자

이 지표는 ‘프로덕트로 어떤 사용자 행동을 만들어 낼 것인가?’에 대한 기준이 되면서 많은 영향을 끼쳤다고 한다.

위에서 개념을 정리할 때,

다음 단계의 퍼널로 넘어가는 것이 '전환'이라고 적었었다.

마찬가지로 퍼널을 명확히 정의한 배민은 24년 ‘Visitor → ‘Browser로 전환을 높이는 것을 목표로 홈 화면을 개선했다.

리뷰를 큐레이션 형태로 탐색할 수 있는 영역을 추가하였던 것이다.

배포 이후 Browser그룹의 비중이 크게 늘어난 것을 통해

배포 전에는 사람들이 방문했다가 이탈되는 비율이 높았다면, 이제는 들어와서 콘텐츠를 조금이라도 탐색하는 비율이 늘어난 것을 확인할 수 있었다.

즉, 퍼널을 도입하기 전에는 콘텐츠를 탐색하는 비중을 성과로 알 방법이 없었다면, 퍼널을 명확하게 측정해두었기 때문에 명확한 성과로 측정이 가능해진 것이다.

3. 이탈이 많다면, 퍼널은 줄이는게 좋은걸까? -알라미 사례로 알아보기!

화면을 기획하다 보면 흔히 마주하게 되는 고민이 있다.

화면 내에서 전달하고자 하는 내용이 많으면
'하나의 화면에 다 전달하여 뎁스를 줄이는게 좋을까' 아니면
'뎁스를 하나 더 두어 두개의 화면'으로 구성할까?

물론 정보 구조 측면에서는 한 화면에 너무 많은 내용이 담기는 것이 좋지는 않지만, 전환 이벤트를 발생시키는 것을 목표로 하는 것이라면 오히려 덥스를 추가하는 것이 좋지 않게 느껴진다.

왜냐면.. 뎁스가 추가되는 순간 해당 퍼널 내에서의 (이탈률이 0%가 아니고서야) 유저 이탈이 발생할 것이 뻔하고 전환률 하락으로 이어질 것이 뻔하기 때문이다.

문제정의!

기존 알라미에서는 제품 내 프리미엄 기능과 관련된 퍼널 중 구매화면 노출 직전에 바텀시트가 노출되는 곳이 있다.

바텀시트를 통해 해당 기능이 프리미엄 기능임을 먼저 인지시키고 그 이후에 구매화면을 노출시키는 여정이다.

프리미엄 기능임을 인지시키는 것은 사실 구매화면 내에서도 가능한데

보다 뾰족하게 메세지를 전하고자 정보 구조를 한 단계 더 추가하여 바텀시트로 구현했던 것이다.

염려했던 대로 바텀시트에서 구매화면으로 넘어가는 과정에서 이탈률이 80% ~ 90%에 달했다.

따라서 ‘바텀시트 내 메세지 고도화 실험’과 ‘퍼널 간소화 실험’을 각각 진행해 보고 결과를 보고자 했다.

두 실험 모두 목표는 구독 전환율 증진이었다.

바텀시트 내 메시지 고도화 실험해보기

첫번재 가설은, 바텀시트 내에서 전달하고 있는 메시지가 너무 매력이 없었던 것은 아닐까?

바텀시트 내 메세지를 더 매력있게 바꿔보았다.

단순히 메세지만 바꾸는 거라 이탈율 & 전환율에 그닥 큰 영향을 끼치진 못할 거라고 생각했는데 결과는 그렇지 않았다.

실험 결과 미국에서는 1.6배, 중국에서는 1.5배, 일본에서는 2배 가량의 구독 전환율이 실험군에서 보였고,

특히 한국의 경우 실험군4를 제외한 나머지 실험군에서 2배 이상 큰 구독 전환율을 보였으며 대조군 대비 2.6배까지 차이가 나는 경우도 있었다.
(물론 국가마다 결과가 상이한 부분은 '메시지'가 변수였던 만큼 번역이 얼마나 잘 되었는지가 관건일 수도 있고, 바텀시트의 사용성이 국가마다 조금씩 다를 수는 있다.)

메시지 하나로 전환율을 2배 이상 늘린 것이 인상깊었다!!!

이번엔 퍼널을 간소화해보자.

두번째 가설인 퍼널을 간소화 해보는 것이다.

이번엔 '바텀시트를 띄우지 않아' 뎁스를 간소화하고 곧바로 구매화면을 띄워보았다.

뎁스가 줄어들었으니 무조건 실험군이 이길거라는 확신이 있었다.

하지만 결과는!!!

곧바로 구매화면을 띄워 간소화했음에도,

그래서 대조군보다 '구매화면 진입률'은 45~50배 개선되었음에도, 정작 구독 전환율 증진은 유의미하게 되지 못한 실험군이 더러 있었다.

이탈률이 심각했던 퍼널을 하나 줄였는데도 전환율 증진이 되지 않았다는 것이..!!!!

즉!! 퍼널을 간소화하는 것만이 답이 아닐 수 있다는 것이다!

다시 정리해보자.

위 실험을 통해 세부적으로도 여러 레슨들을 얻었지만 이 글에서 이야기하고자 하는 내용은 요컨대 아래와 같다.

정보 구조화를 위해 뎁스를 추가할 때에는 메세지가 보다 뾰족하게 소구되는 만큼 어떤 메세지를 소구할 것이냐가 굉장히 중요하다.
이는 실제로 최종적인 전환율까지 유의미하게 영향을 줄 수 있다. 다만 ‘메세지’가 변수인 만큼 현지화를 잘 고려해야 한다.
최종 전환율을 높이기 위해서는 뎁스를 추가하지 않고 퍼널을 간소화 하는 편이 유리하다.
하지만 퍼널을 간소화 하는 것이 반드시 높은 전환율로 이어지는 것은 아니다. 여러 정보를 하나의 화면 내에서 소구하게 되는 만큼,
해당 화면을 어떻게 구성하느냐에 따라 최종 전환율 편차는 크게 나타나며 오히려 뎁스를 하나 더 두는 편이 전환율 측면에서 낫다는 결론에 이를 수도 있으니 주의해야 한다.

참고로...!!! 해당 아티클에서 내린 결론은 다음과 같다.

Q. 만약 시간과 리소스가 없다면 당신은 뎁스를 추가하고 메시지를 고도화 하시겠나요? 아니면 뎁스를 간소화하고 합쳐진 화면 내 구성을 신경 쓰시겠나요?

A. 저는 후자를 택하겠지만, 전자에 미련이 계속 남을 것 같아요. 하여 일단 후자로 적용하고 훗날 시간과 리소스가 생기면 이를 대조군 삼아 전자에 대한 실험을 꼭 한번 해볼 것 같습니다!

참고

https://medium.com/delightroom/%ED%8D%BC%EB%84%90%EC%9D%80-%EC%A4%84%EC%9D%BC%EC%88%98%EB%A1%9D-%EC%A2%8B%EC%9D%80%EA%B1%B8%EA%B9%8C-652280c76e2d

https://po-sky.tistory.com/entry/%ED%8D%BC%EB%84%90-%EB%B6%84%EC%84%9D

https://datarian.io/blog/why-is-user-activity-log-analysis-important

https://techblog.woowahan.com/20386/

[AI] 오늘의 집 사례로 알아보는 RAG 서비스

hye2 이야기 — Sun, 14 Dec 2025 02:31:34 +0900

*사내의 서비스를 자동화 한 오늘의 집의 오리(ORI) 서비스의 아티클을 보면서 인상깊어 정리해야겠다고 생각했다!

오늘의집 전사 지식 탐색 시스템 ‘ORI(오리)’ 개발기 - 오늘의집 블로그

흩어진 사내 지식을 하나로 연결하다

www.bucketplace.com

✍ 핵심질문은, 어떻게 하면 AI가 맥락을 검색하게끔 만들까?

이 프로젝트는 단순히 챗봇 답변을 조금 더 똑똑하게 만드는 수준을 목표로 하지 않습니다.
중요한 것은, 사내 의사결정의 맥락을 결정하게 만드는 것이었습니다.
-오늘의 집 아티클 中

(1) '오늘의집'의 문제정의

이미지 출처 : 오늘의집 아티클

해당 아티클을 읽어보면,

기존의 문제를 이렇게 정의내릴 수 있다.

질문의 형태가 반복적이고,

정보의 위치가 제각각이며,

정보의 공유가 정형화되어 있지 않고 예외로 처리되는 건들이 있었다는 점들.

사내에서 사용하고 있는 슬랙은 각각 다른 전사 Q&A 채널들이 존재하고,
이 채널들에는 비슷한 유형의 질문이 반복적으로 올라오게 된다. (사실 이건 모든 회사가 동일하지 않을까?)

답변하는 쪽에서는 이미 한 번 설명했던 내용을 다시 정리해 붙여 넣거나,
예전에 있었던 유사 이슈의 링크를 찾아와 공유하는 방식으로 대응하고 있었으며, 이 과정은 하루 수 시간 단위로 누적되는 경우도 적지 않았습니다. 한마디로, ‘아는 사람이 계속 직접 답해줘야만 굴러가는 구조’가 기본 상태가 된다.

이 문제의 원인은 정보의 위치가 제각각이라는 점이다.
어떤 요청이 승인 가능한지에 대한 공식 기준은 Notion에 문서화되어 있지만, 실제로 비슷한 요청이 과거에 어떤 조건으로 허용되었는지는 Slack 스레드에만 남아 있는 경우가 많았다.

반대로, Notion에는 절차가 적혀 있지 않은데 Slack 대화에는 “이 경우에는 예외로 처리해도 된다”는 사실상의 합의가 남아 있는 경우도 있다.
심지어 중요한 결정이 공개 채널이 아닌 개인 DM이나 소규모 스레드에서 내려진 뒤,그 맥락이 이후에 공유되지 않는 일도 있었다.
회사 입장에서는 분명히 ‘답’이 존재하지만, 그 답이 여러 소스에 나뉘어 저장되고
서로 연결되지 않아 한 번에 검색해서 맥락까지 따라가기 어렵다는 것이 반복 문의의 구조적 원인이다

(2) 챗봇이랑은 다른 서비스!

챗봇은 결국 정해진 답변을 응답하는 대화형태라,

오늘의 집에서 만든 ORI의 서비스를 챗봇 서비스라고 볼 수는 없다.

그 이유가 해당 글에 자세히 적혀 있는데

단순함 매뉴얼만 필요한 것이 아니라,
슬랙과 노션 등 사내 지식 소스에서 자동으로 수집, 연결해 각 조직이 이미 가지고 있는 경험과 기준을
다른 사람도 재사용할 수 있도록 전사 지식 인프라를 지향한다.
즉, 이 프로젝트는 단순히 챗봇 답변을 조금 더 똑똑하게 만드는 수준을 목표로 하는 것이 아니라, 중요한 목적은 사내 의사결정의 맥락을 검색 가능하게 만드는 것이다!

✍ 문제 정의 : 사내 Q&A의 반복과 정보 접근의 비효율

사내에서 나오는 질문들에는 결국 매뉴얼 뿐만 아니라 '실제 맥락'이 필요하다.

'지난달에는 어떻게 처리되었는지', '누가 최종 승인자였는지', '예외가 허용되었던적이 있는지'와 같은 실제 맥락이 필요하다.

결국 특정 팀만 알고 있던 운영 지식을 회사 전체가 필요할 때 찾아볼 수 있도록 해야하기 때문에,

Slack 과 Notion을 중심으로 사내 지식을 수집하고, 정규화하고 RAG 기반 아키텍쳐를 통해 기술적 선택을 하게 된 과정이 나와있다.

기존 사내챗봇과 각 조직의 Q&A채널에서 연결하여 전사적 인프라를 구축한 아티클이다.

참고로, 기존에도 비슷한 문제를 제기하여 문제를 해결하려던 과정이 있었다.
다만, 한계가 있었다!
(1) FAQ는 시간이 지나면 바로 낡아졌고, 실제 운영 맥락까지 반영하지는 못한다.
(2) 수동 검색은 결국 특정 사람의 기억력과 판단력에 의존하기 때문에, 담당자가 자리를 비우면 지식 자체가 멈춰 공유가 어렵다.
(3) 그럴듯하지만 실제로는 맞지 않는 답을 주는 경우가 반복적으로 생긴다.

즉, 기존 방식은 문서를 보여줄 수는 있지만, 실제로 회사 내부에서 어떤 식으로 결정하고 처리하는지에 대한 맥락까지는 전달하지 못하여, 한 번 질문하면 회사 안에서 이미 존재하는 모든 맥락을 가져올 수 있도록 하자.
따라서, 결정 사례, 최근 처리 이력, 공식 정책, 담당 범위, 후속 액션까지 연결하여 즉시 보여주자.

‍ ️✏️ 어떤 방법으로 했을까?

→ RAG 기반 시스템으로의 전환

정책은 노션 문서 안에, 실제 사례와 예시는 슬랙 스레드 안에 존재하기 때문에 서로 다른 형태의 데이터가 혼재된 환경에서는 단순한 키워드 검색만으로는 충분하지 않다.

즉, 단순히 검색된 결과를 보여주는 것이 아니라, 관련 맥락을 불러와 의미 단위로 응답을 구성할 수 있게 해야한다.

RAG는 두 데이터 소스 간의 비정형성과 시차 문제를 흡수하여, 슬랙과 노션의 맥락을 하나의 응답 내에서 자연스럽게 엮을 수 있는 구조이다.

파이프라인 구성

(1) 데이터 수집
(2) 전처리 및 마크다운 변환
(3) 메타데이터 부착
(4) AWS Bedrock Knowledge Base 인덱싱으로 데이터 등록
(5) Hybrid Search Reranking 과정을 통해 검색 품질을 향상
(6) Langraph 가 검색 결과를 조합해 답변 생성
(7) Langfuse가 이를 로깅, 평가하여 피드백 루프를 구성

이 과정에서 비정형 문서는 모두 마크다운으로 변환되어 일관된 형태로 처리되어,
전체 데이터 흐름이 단순하고 추적 가능한 형태로 유지된다.

결국 다른 문서이기 때문에 명확히 표준화하는 것이 중요하다고 생각했는데

역시 문서 포맷을 표준화하는 것을 알 수 있었다.

모든 문서는 마크다운(.md) 형태로 변환해 저장하며, 텍스트 기반 표현으로 통일했다고 한다.

노션에서 생성된 표는 구조를 유지한 채 마크다운 테이블 형태로 변환해 저장하도록 하고,

이러한 설계는 “모든 문서는 문자열로 표현될 수 있다”는 전제에 기반하며,

다양한 출처의 데이터를 하나의 검색 파이프라인으로 통합하기 위한 기초가 된다.

여기서 잠깐! RAG가 뭐지?

RAG는 Retrieval-Augmented Generation의 줄임말로,
검색 증강 생성 이라고 번역할 수 있다.

기존의 언어 모델에서 외부 지식을 결합하여 더욱 정확하고 최신의 정보를 제공하는 혁신적인 접근 방식이다.
RAG는 자연어 이해와 생성 분야에서 획기적인 성능을 보여주고 있으며,
다양한 응용 가능성으로 인해 많은 관심을 받고 있다.

이미지 출처 : https://brunch.co.kr/@ywkim36/146 / https://aws.amazon.com/ko/what-is/retrieval-augmented-generation/

RAG은 검색 증강 생성(Retrieval-Augmented Generation)의 약자로, 검색 증강 생성(RAG) 은 대규모 언어 모델의 출력을 최적화하여 응답을 생성하기 전에 훈련 데이터 소스 외부의 신뢰할 수 있는 기술 자료를 참조하도록 하는 프로세스이다. 쉽게 말해서 단순히 미리 학습된 데이터에 의존해 답변을 생성하는 것이 아니라, 외부 데이터베이스나 문서에서 관련 정보를 검색한 후, 이를 활용하여 답변을 생성하는 기법이다.

이미지 출처 : https://thebook.io/080464/0005/

그러니까, 기존의 LLM은 방대한 양의 이미 학습된 데이터를 기반으로 하기 때문에,

최신의 기술이 업데이트 되기가 어렵다.

만약 이렇게 하려면 LLM 모델 자체를 최신 데이터로 재학습시켜야 하지만, 쉽지 않기 때문에 RAG를 사용하여 최신 문서나 데이터베이스에서 검색한 후, 최신 정보가 포함된 상태로 답변을 생성해야 한다

왜냐면! LLM은 결국 특정 데이터셋으로 학습을 하는 것이기 때문에, 특정 데이터셋으로 계속해서 재학습시켜주어야 하는데

RAG를 활용하면 LLM을 수정하지 않고도 활용할 수 있다.

즉, 외부 검색 시스템과 결합하여 필요한 정보를 즉시 반영할 수 있어서, 재학습보다는 RAG를 사용하여 검색한 정보를 기반으로 즉시 답변을 생성하는 것이 효율적인 것이다.

다시 돌아와서, RAG를 활용한 파이프라인을 살펴보자.

각 문서에는 별도의 메타데이터 파일(.metadata.json)이 자동으로 생성되어 S3 내 동일 경로에 저장된다.

Bedrock KnowledgeBase는 이 파일을 자동으로 인식하고, 추가적인 필드 정보를 인덱싱 시 함께 수집한다.

별도의 커스텀 인덱싱 로직을 구현하지 않아도 되기 때문에, 구현 복잡도를 크게 줄일 수 있었다.

즉, 메타데이터를 정리하기 때문에,

fanout_urls 는 문서 간 참조 관계를 나타내고, domain_id는 Slack·Notion 등 데이터 출처를 명시한다.

이러한 구조는 향후 연관 문서 탐색이나 프로젝트 단위의 관계 기반 검색으로 확장할 수 있는 기반이 된다.

예를 들어 특정 주제의 Notion 문서에서 fanout_urls를 통해 Slack 대화 기록으로 연결되면,

단일 문서 중심의 검색을 넘어 ‘맥락적 탐색’이 가능해진다.

이미지 출처 : 오늘의 집 아티클

RAG를 차근차근 도입하여 구조를 잡아보자.

다시 정의를 들여다보자.

Retrieval(검색) - Augmented(증강) - Generation(생성)

즉,
Retrieval : 어딘가에 가서 요청된 무엇인가를 집어와서 가져오는 것
Augmented : 원래 것에 뭔가 덧붙이거나 보태는 것
Generation : 만들어내는 것. 프롬프트라고 하는 사용자 질문, 질의에 대한 응답을 텍스트로 생성하는 것

그렇다면 ORI를 개발하기 위해서도 이러한 방식을 고수하여 기술을 도입했다.

먼저, Retrieval은 문서에서 가져오는 것이기 때문에 '문서 탐색 정확도를 높이기' 위한 방식인 Hybrid Search 를 활용하였다.

짧은 검색어는 키워드 검색어, 장황한 질의는 벡터 검색이 강점을 가지는 경향이 있는데

키워드 기반 검색과 벡터 기반 검색을 결합하면 짧고 명확한 요청과 길고 복합적인 질문 모두에 안정적인 결과를 가질 수 있다.

아티클을 읽어보면, 초기에는

BM25 검색 결과
   +  
벡터 검색 결과
   ↓
RRF로 합쳐서 하나의 후보 리스트 만들기

를 유지했었는데 이때 문제는

VPN 같은 짧은 검색어에서 오탐(틀린 문서가 높은 순위) 이 자주 나왔고
정답 문서가 있어도 순위가 너무 낮아 최종 출력에서 제외됨
(예: 상위 n개 문서만 가져오는데 정답이 8등 → 잘림)

따라서, 개선한 구조가

[B0] BM25 검색
[B1] 벡터 검색
   ↓
Hybrid Search (RRF로 결합)
   ↓
LLM Reranker (Cohere rerank-3.5)
   ↓
최종 정렬된 문서 리스트 → RAG 생성에 전달

즉, Hybrid Search(=BM25+벡터+RRF)의 결과가 나온 다음에

그 리스트를 다시 LLM이 판단해서 재정렬 하는 구조가 추가된 것이다.

Hybrid Search 로 1차 필터링을 하고, Reranker로 2차 정교 정렬이 이루어진다.

따라서, Reranker를 통해 초기 검색 결과의 순위를 재정렬하여 보다 관련성이 높은 정보를 상위에 배치한다.

이는 일반적인 검색 엔진이나 AI 기반 질의 응답 시스템에서 사용된다.

즉, Reranker는 문서와 쿼리 간의 유사도를 더욱 정확하게 측정하여 최적의 답변을 제공할 수 있도록 돕게 된다.

이를 통해 사용자는 보다 정확하고 유용한 정보를 빠르게 얻을 수 있어 초기 검색에서 놓쳤을 수 있는 문맥이나 의미적 관련성을 재확인해 정보 손실을 줄이고 보다 신뢰할 수 있는 결과를 제공한다.

Slack 데이터는 어떻게 수집할까? Batch 에서 Event 기반으로

초기에는

슬랙 메시지를 5분마다 흝어서 가져오는 batch 방식

문제!
- 실시간 반영이 안된다
- 메시지가 너무 많아지면 다 가져오지 못한다.
- Slack Api가 제한을 걸어버린다.

따라서 나중에는,

슬랙이 '메시지 생겼어!' 라고 먼저 알려주는 Event Subscription 방식

어떻게 적용되지?
- 서버가 필요 없이 Socket Mode로 실시간으로 안전하게 메시지를 받게 해준다.
- 이 메시지를 곧바로 S3 -> Lambda -> Bedrock 으로 홀려보낸다.

따라서! 완전한 실시간 슬랙이 RAG 자동화로 사용할 수 있게 된다.

(으아 사실 여기서 너무 어려워서 중간에 하차할 뻔했다 ㅎㅎ..)

다시 중간부터 읽어봤다.

1️⃣ Batch 방식이 무엇일까!

이미지 출처 : https://ssoontory.tistory.com/entry/%EB%B0%B0%EC%B9%98-%EC%9E%91%EC%97%85batch-job%EC%9D%B4%EB%9E%80

배치 처리는 컴퓨터가 주기적으로 대량의 반복적인 데이터 작업을 완료하기 위해 사용하는 방식이다.

즉, 한 번에 여러 작업을 처리하거나 여러 데이터 항목을 처리하기 위해 실행된다.

일정 주기나 특정한 일정에 따라 실행되는데, 예를 들어, 매일 밤에 특정 시간에 주문 데이터를 처리하거나, 매주 월요일에 주간 보고서를 생성하는 등의 작업이 포함된다.

하루 종일 주문을 수신하는 전자 상거래 시스템을 예로 들면, 시스템에서 주문을 그때그때 처리하는 대신

하루가 끝날 때 모든 주문을 수집하고 주문 처리 팀과 하나의 배치로 공유할 수 있다.

다만, 슬랙에서는

실시간으로 올라오는 메시지를 처리하기 어렵고, 슬랙의 메시지가 자주, 혹은 많이 늘어날수록 배치의 한계가 명확해진다.

2️⃣ 그래서 Event Subscription 방식은 무엇일까!

이미지 출처 : https://www.akamai.com/ko/glossary/what-is-an-event-subscriber

이벤트 기반 아키텍처에서 이벤트 구독자는 특정 이벤트 주제, 영역 또는 메시지와 관련된 변경 사항을 '수신'하고 지속적으로 푸시해서, 이벤트에 대한 메시지를 수신한다.

즉, 이벤트 구독자가 이벤트에 대한 정보를 수신하면 데이터베이스 업데이트, 이메일 전송, 스토리지 버킷에 오브젝트 추가, 워크플로우 요청 등 다양한 방법으로 정보를 처리하고 응답할 수 있다.

이벤트 기반 아키텍처에서 이벤트 구독자는 이벤트가 발생하는 순간 이벤트에 대해 파악할 수 있으므로

앱, 시스템, 사람, 기업이 실시간으로 대응할 수 있다.

즉, Slack Event Api 는 이런 이벤트를 바로 알려줄 수 있다.

누가 메시지 올렸다든지,
누가 댓글을 썼다든지,
파일을 업로드했다든지,
멘션이 들어왔다든지 등

슬랙이 먼저 알려줌으로써 실시간이 가능해지는 것이다.

3️⃣ 이번엔 Socket Mode가 무엇일까?

기본적으로 Slack 이벤트를 받으려면,

서버 URL을 슬랙이 호출하는 Webhook 구조이다.

그렇지만 기업 내부 환경에서는 외부에서 접근 가능한 서버 URL을 만들기 어렵고, 보안상 내부망만 허용되는 경우가 많다.

하지만 Socket Mode는 슬랙이 Websocket의 연결을 유지해서 이벤트를 푸시해주는 방식이기 때문에

서버가 필요하지 않고, 외부 인터넷에 대한 노출이 없이 내부에서 안전하게 이벤트 수신을 할 수 있게 되는 것이다.

즉 정리를 하자면!

슬랙 이벤트를 정확히 통신하기 위해

배치 방식이 아니라 이벤트 구독 기반으로 데이터를 수집하고,

서버와는 Web socket mode로 통신하게 되는 것이다.

노션 데이터는 어떻게 수집할까? 너~무 많은 문서를 안정적으로 수집해야한다!

슬랙이 실시간성에 초점을 두었다면,

노션은 '방대한 양의 데이터'를 가져오는 것이 넘넘 중요했다.

노션은 많은 양의 데이터들을 쉽게 정리할 수 있고, 동시성을 가질 수 있어 사내에서 당연히 잘 사용하는 툴이지만,

이를 찾는데에는 꽤나 복잡한 구조를 가지고 있는 것이 사실이다.

따라서 오늘의 집도 비슷한 문제를 겪었고 문제를 해결하는 과정이 인상깊었다.

1️⃣ 전체 문서 탐색 크롤링을 하자! -Teamspaces 기반으로 계층적 크롤링을 활용해서!

노션은 그냥 크롤링을 하게 되면 페이지-페이지-페이지...로 이루어져있기 때문에 쉽게 크롤링이 되지 않는다.

또한 노션api에는 모든 문서를 조회할 수 있는 엔드포인트가 없다!

따라서, Teamspaces의 가장 최상위 페이지에서 시작해 하위 참고 (child pages) 를 재귀적으로 탐색하는 너비 우선 탐색 방식을 채택한다.

이렇게 층별로 쫙 흝는 BFS 방식으로 찾아, 이 방식은 추출 대상으로 포함될 필요가 없는 문서들은 걸러줄 수 있고, 최종적으로 Teamspaces에서부터, 생성된 약 40만 개 문서를 찾을 수 있었다.

이미지 출처 : https://loosie.tistory.com/151

BFS 방식은 가까운 인접 노드부터 탐색하는 방식으로 재귀함수가 쓰이지않고
queue를 사용해서 현재 노드에서 인접해 있는 노드를 queue에 넣는 방식으로 작동한다.
(해당 내용은 알고리즘에 가까워서.. 개념만 대충 이해하고 넘어갔다 ㅎㅎ)

2️⃣ 무한루프의 문제가 발생한다! -Redis 기반으로 중복 제거

결국 Notion문서들은 서로를 자유롭게 참고할 수 있었기 때문에

“문서 A → 문서 B → 문서 A”와 같은 순환 참조가 빈번했다고 한다.

또한 초기에느 BFS큐에 문서 reference를 단순 추가하였기 때문에 문제가 생겨도 크롤러가 종료되지 않았다고 한다.

따라서 Redis의 Set자료구조를 활용하여 각 문서의 처리상태 (성공, 실패 진행 중)을 기록했고 이미 처리된 것은 스킵하도록 하여

처음 본 문서만 처리하고, 이미 본 문서는 건너뛰게 하여 무한 루프 없이 효율적으로 탐색이 가능하도록 했다.

3️⃣ 데이터 구조 다양성과 API 구조의 불안정성 해결하기

노션의 문서 구조가 너무너무 제각각이기 때문에, (예를 들어 어떤 문서는 표만 있고, 글만 있거나, 혹은 어떤 방은 블록이 300개 들어있고 어떤 방은 또 다른 방으로 연결이 되어있거나...) 각 타입의 구조가 제각각이라 모든 경우를 일관되게 처리하기가 어렵다.

따라서 이를 해결하기 위해 Notion Parser를 구축하여 해결했다고 한다.

문서의 id를 기반으로 metadata를 조회하고

문서인지, 데이터 베이스인지 판단하고, 하위 페이지가 있는지 확인하고, 표인지 텍스트인지 이미지인지 분류하여 파싱 로직을 분기 처리하도록 설계했다고 한다.

하지만, API 가 불안정하기 때문에 특정 하위 콘텐츠를 가져오지 못하는 경우에는,

Fallback 로직을 추가하여 노션의 파일 다운로드 기능을 직접 호출하여 원문을 복원한다.

즉, api 가 실패하면, 노션의 문서 내보내기(Export) 기능을 대신 호출하여,

파일을 직접 다운로드 하여 원문을 복구하고 다시 문서 구조를 재조립하여 누락된 데이터까지 복원하는 구조이다.

4️⃣ 문서가 많아도 너~무 많아서 오래 걸린다!

아무리 그래도 많아도 너~무 많으니, 문서 1건을 처리하는 데에 평균 3.6초가 걸린다고 하였다.

단순하게 계산하면 약 40만 건을 처리하기 위해 약 400시간이 필요한 셈이니, 이 문제를 해소하기 위해 다중 APi Key를 병렬로 처리하는 구조를 설계했다고 한다.

즉, API Key를 여러 개 동시에 사용하여 속도를 증가하였으나, 매일 새로 생성되거나 수정되는 것까지 반영하기는 어려워서

Notion Search API의 최신순 정렬 기능을 활용하여 매일 생성, 수정된 문서를 수집하는 일 배치 작업을 추가 구축하여

문서 최신성이 하루 단위로 개선이 될 수 있도록 하였다.

따라서 전체 동기화는 주말 한 번,

평일에는 '오늘 수정된 문서'만 가져오게 하여 문서 최신성을 유지할 수 있었다.

[인사이트] 올해의 앱 수상작을 보면서 인사이트 얻기!

hye2 이야기 — Tue, 9 Dec 2025 20:07:28 +0900

App Store Awards 2025 - Apple Developer

For over a decade, we’ve taken a moment at the end of the year to celebrate the very best and most impactful apps and games on the App Store — and the developers behind them.

developer.apple.com

연말... 여러 앱이 많이 출시되었고

올해 얼마나 많은 앱들이 사용되었을까!

올해의 앱에 선정된 앱들을 보면서 인사이트를 얻어보고자 했다.

애플 <앱스토어 어워드 2025> 와

구글플레이 <올해를 빛난 수상작 2025> 를 통해 알아보았다.

구글플레이 '올해를 빛낸 수상작 2025' 란?

매년 말 발표되는 이 리스트는 다운로드 수, 사용자 평점 등 다양한 요소를 종합적으로 고려하여 선정되며,

한 해의 모바일 트렌드를 파악할 수 있는 중요한 지표가 된다.

2025년 영예의 ‘올해의 베스트 앱’은 <네이버플러스 스토어>가, ‘올해의 베스트 게임’은 넷마블의 <세븐나이츠 리버스>가 차지했다.

구글의 올해의 키워드

2025년 앱 트렌드의 핵심은
'능동형 AI', '몰입형 경험' 그리고 '경계 없는 생산성' 이다.

(1) 능동적으로 돕는 ‘에이전트 AI’의 보편화,
사용자의 명령을 기다리지 않고 먼저 필요한 정보와 작업을 제안하는 ‘에이전트 AI’가 일상 깊숙이 자리 잡았다.
카카오가 개발한 온디바이스 AI 기반의 일상 AI 비서 서비스 <카나나>(올해를 빛낸 일상생활 앱)와 AI가 하루의 기록과 관심 뉴스를 요약해 주는 <디로그>(올해를 빛낸 자기계발 앱)가 대표적이라고 볼 수 있다.

(2) 안드로이드 XR로 열린 새로운 몰입 경험
올해는 안드로이드 XR 플랫폼이 본격적으로 출범하며 모바일 경험이 현실 세계로 확장된 해이기도 하다.
<치지직 XR>(올해를 빛낸 XR 앱)은 갤럭시 XR 등 새로운 VR 헤드셋 기기 환경에 최적화된 몰입형 스트리밍 경험을 선보이며 XR 시대의 본격적인 개막을 알렸다.

(3) 기기를 넘나드는 끊김 없는 생산성
OS의 제약 없이 다양한 기기를 오가며 작업 효율을 높여주는 앱들도 강세를 보였다.
매끄러운 연동성을 자랑하는 <Goodnotes>(올해를 빛낸 대화면 앱)와 <Luminar>(올해를 빛낸 멀티 디바이스 앱)는 창작과 생산성 분야에서 높은 평가를 받았다.

-출처: 구글코리아 블로그

(1) 구글의 올해의 베스트앱-네이버플러스 스토어

‘올해의 베스트 앱’으로 선정된 <네이버플러스 스토어>는

기존 네이버 앱에서 쇼핑 기능을 특화해 분리한 앱으로,

개인화된 AI 쇼핑 경험과 통합적인 구독·구매 관리 편의성을 제공하며 출시와 동시에 큰 호응을 얻었다.

(2) 구글의 올해의 베스트 일상 앱-카나나

카나나는 '가장 나다운 AI' 라는 의미로, 카카오, 네이티브(Native), 내츄럴(Natural) 의 단어를 조합해 만들었다.

카나나 서비스 속 AI 메이트는 개인메이트인 '나나(nana)' 와 그룹메이트 카나(kana)'로 구현되며,
나나는 이용자와의 일대일 대화와 그룹대화에서의 대화를 기억해 최적화된 개인화 경험을 제공하고,
카나는 상주하는 그룹대화 안에서의 대화 내용만 기억하여 이용자들을 돕는 식의 특징이다.

예를들어 나나를 통해, 그룹대화에서 나눈 컨퍼런스 참석 일정과 준비물 등을 기억해 메시지로 알려 주거나,
카나를 통해 스터디 그룹대화에서 함께 읽은 논문 관련 퀴즈를 내주고 채점 및 부연 설명을 해주거나,
연인 간의 대화방에서 귓속말 기능을 통해 데이트 일정이나 장소를 제안해 주는 방식으로 제공해준다.

카나나는 카카오가 모든 AI 기술을 테스트 해보는 서비스라고 느껴질만큼
기술이 집약되어 있는 서비스이다. 여러 개인화된 서비스를 만날수도 있고 사주도 볼 수 있다.
카카오의 기술력과 AI 를 활용하여 쌓인 데이터들을 활용해서 앞으로 더 많은 다각화된 서비스들을 만나보면 재밌을 것 같다.

(3) 구글의 올해의 베스트 자기계발 앱-디로그

디로그는 사진 한 장으로 시작하여 시간, 위치, 날씨 등을 자동으로 기록하고 감정 이모티콘과 태그를 활용해 일상을 정리하는 AI 기반의 타임라인 기반 다이어리 앱이다.

자동 기록: 사진과 함께 시간, 위치, 날씨 정보가 자동으로 기록된다.
스마트한 편집: 감정 이모티콘과 태그 기능을 활용하여 일상을 쉽게 정리할 수 있다.
타임라인 UI: 하루의 기록을 하나의 이야기처럼 시간 순서로 구성하여 보여준다.
다양한 기록: 사진 한 장으로 시작하여 순간을 기록하는 등 다양한 방식의 기록이 가능하다.
기기 간 연동: Android, iOS, Mac 등 여러 기기에서 기록을 동기화하여 사용할 수 있다.

사진을 손쉽게 기록할 수 있게 된다는 것이 인상깊었고, 특히 사진을 그냥 올리면
바로 앱 내에서 시간 순으로 정렬할 수 있다는 점이 손쉽게 사용할 수 있어 유저 편의성을 많이 생각한 것 같다.
또한 친구한테 공유를 하더라도, 친구는 앱을 사용하지 않아도 된다는 점에서 단순히 공유 기능을 유저를 늘리려고 하는게 아니라
정말 유저 편의성 측면에서 많은 고민했다는 점이 인상깊었다.

(4) 구글의 올해의 급상승 커머스 앱-차란

차란은 사용자가 옷장 정리를 신청하면

대신 의류를 수거하고, 새 상품으로 만들어 다른 이들이 구매할 수 있게 해주는 서비스이다.

위탁 판매와 중고 의류 패션앱 서비스를 겸하고 있다는 것이다!

옷장 정리를 신청하고, 옷을 내놓으면

차란이 가져가서 정품인지를 검수하고 판매를 하기 때문에 사용자들은 정품인지 의심할 필요가 없고

명품부터 SPA까지 전부 취급하기 때문에 부담없이 판매가 많이 이루어질 수 있다.

위탁판매와 중고거래... 정말 익숙한 키워드이다!
무신사가 새로하는 USED 서비스와 롯데백화점 '그린 리워드' 서비스, 현대백화점 바이백 서비스 들과 비슷하다.
중고거래와 위탁이 함께 이루어지는 서비스를 많이 봤었는데
차란의 큰 차별점은 어떤 것일지 궁금해졌다. 중고거래가 많아지는 요즘, 각 서비들이 차별점을 가지는 것이 매우 중요해지는 것 같다.

(5) 구글의 숨은 보석 앱-숏차

숏차는 국내 OTT서비스인 왓챠에서 별도로 출시한 숏폼 드라마 전용 플랫폼 앱이다.

편당 1~2분 내외의 세로형 숏폼 드라마 콘텐츠를 모바일 환경에 최적화하여 제공하고 있다.

콘텐츠 길이 및 형식: 각 에피소드가 1~2분 정도로 매우 짧고, 스마트폰에 적합한 세로 형태 제작
다국적 콘텐츠: 한국, 중국, 일본, 미국 등 다양한 국가의 숏폼 드라마를 제공하며, 여러 장르를 포함한다.
이용 방식: 일부 회차는 무료로 감상할 수 있으며, 이후 회차는 유료 결제 또는 광고 시청을 통해 감상할 수 있다.

OTT 의 확장이 틱톡화가 된 느낌이다.
숏폼시대라고 불릴만큼, 릴스 및 틱톡이 강세를 잡고 있는데 왓챠의 서비스 방향에서 확장되어 접목한 것이 재미있다고 느껴졌다.
'짧은 드라마'라는 것이 처음엔 상상이 되지 않았지만, 짧게 즐길 수 있는 시대에서 드라마를 짧게 본다는 것이 인상깊었다.
다양하고 많은 콘텐츠들이 업로드 된다면 앞으로 더욱 성장할 수 있는 서비스가 될 것 같다.
또한 네이버웹툰에서 제공하고 있는 '컷츠' 서비스와 어느정도 닮아있는 모습이 많은 것 같아 서로 윈윈하면 좋을 것 같다.
(제휴를 맺어도 괜찮을 것 같고.. )

(6) 구글의 인기 급상승 엔터테이먼트 앱-FlickReels

FlickReels는 5분 이내의 짧은 에피소드로 구성된 숏폼 드라마를 제공하는 모바일 앱이다.

여러 다양한 중독성 강한 콘텐츠를 즐길 수 있다.

짧은 형식: 각 에피소드가 5분 내외로 구성되어 있어 이동 중이나 짧은 휴식 시간에 시청하기 적합하다

위의 숏차와 매우 비슷한 서비스이다.
(역시나 숏폼이 강자인 시대가 맞군!)
한때 넷플릭스, 티빙, 디즈니플러스, 쿠팡플레이, 왓챠 등 OTT 서비스들이 많이 출시되면서, OTT 전쟁이 한때 불었었는데
이제는 숏폼으로 옮겨갈게 아닐까 라고 생각했다.

(7) 구글의 인기 급상승 커머스 앱-Grip

유튜브나 스마트스토어에서 live로 물건을 파는걸 본적이 있었는데
아예 새로운 앱으로 나왔구나!
요즘엔 정말 숏폼이 대세라는 생각이 들었고, 커머스를 접목시키는 서비스들이 많다는 생각이 들었다.
유저들이 '실제로 내가 옷이 잘 어울릴까?' 라는 pain point로 후기 서비스가 발달하고, 숏폼으로 발달하는 과정들을 보면서
커머스의 발전이 기대된다.

애플 앱스토어 어워드란?

애플의 앱 스토어 어워드는 매년 전 세계 개발자들의 기술적 성취와 사용자 경험 개선 사례를 조명하는 행사로

매년 애플이 올해의 앱과 게임을 뽑아서 상을 주는, 일종의 공식 시상식이다!

매년 공통적으로, 해당 기준들을 보고 앱을 선정한다.

혁신성-새롭고 독창적인 기능 및 아이디어인지?
사용자 경험-쓰기 편하고 직관적인지
디자인-비주얼, 인터랙션 완성도가 높은지
사회 문화적 영향력-접근성, 포용성, 사회에 주는 메시지가 가치가 있는지 등

해당 어워드가 공개됐다고 하는데,

보면서 여러 인사이트를 얻고자 정리해보았다!

(1) ADHD와 자폐에 친화적인 AI 플래너-TIMO

너의 흐름에 가볍게 맞춰주는 플래너.
Tiimo는 당신의 할 일을 눈에 보이는 계획으로 바꿔줍니다. 시각적 타임라인, AI 기반 작업 분해, 그리고 복잡함을 줄여주는 도구들이 함께합니다.

메인 기능

기능	상세 설명
시각적 타임라인	직관적인 색상 코딩 타임라인을 설계하여 하루 일정을 한눈에 보여줘 시간 무감각을 극복하고 일정 관리를 쉽게 할 수 있도록 돕는다.
웰빙 중심 기능	기분 추적 기능을 통해 감정 상태를 기록하고, 일상적인 할일과 함께 감정 변화를 관리할 수 있다.
다중 기기 연동	데스크톱, 모바일, 스마트워치, 태블릿에서 계획을 원활하게 동기화하여 언제 어디서나 일정을 유지할 수 있다.
지원 언어	영어, 독일어, 프랑스어, 스페인어, 포르투갈어, 한국어, 일본어 등
추천 대상	직관적이고 유연한 일정 관리 도구가 필요하며, 일정 구조화 뿐만 아니라 감정과 웰빙을 함께 고려하는 사람들에게 적합하다.

UI가 예뻐서 서비스를 들여다보게 됐다.
특히 타임라인과 대시보드가 특히 예뻐서 대시보드라는 느낌이 들지 않고, ADHD 를 타겟하여 일정 관리를 쉽게한다는 점에서
여러 유저들을 타겟한다는 느낌이 들었다.
특히 시간관리, 일정관리, 감정기록 <- 이 기획들은 여러 서비스들이 떠오를만큼 어렵지 않은 기획인데
이를 직관적인 UI로 구성하여 사람들이 쉽게 볼 수 있게 한다는 점에서 인상깊었다.

(2) BandLab

실제 후기를 찾아보면, 여러 악기와 음악 기술이 가능하여 음악을 만들기 쉽다고 쓰여져있었다.
60초만에 만들었다는 후기도 봤다 ㄷㄷ..
AI가 서비스를 지원해주어 AI로 작곡도 가능한 시대가 되었다. (신기해)
실제로 사용해보면 좋을 것 같다.

참고

https://blog.google/intl/ko-kr/products/android-play-hardware/googleplay-best-of-2025/

https://developer.apple.com/app-store/app-store-awards-2025/

[서비스기획] 핵심성과지표는 어떻게 측정할까?

hye2 이야기 — Wed, 3 Dec 2025 22:09:03 +0900

어제 좋은 기회가 있어서, 기획자분들과 얘기하는 시간을 가졌는데

'성과 지표' 에 대한 이야기가 나왔다.

보통 회사는 서비스에 대한 성과를 매번 측정하여 서비스의 방향을 결정한다.

매출이나 다양한 방식으로 성과를 측정할 수 있는 기준이 있는데,

기획자들은 어떻게 문제를 해결하고, 프로덕트의 성과 지표를 측정할 수 있을까?

목차
1️⃣ 프로덕트들의 공통적인 수치 지표
2️⃣ 각 프로젝트를 수행할 때 프로젝트에 맞는 성과 지표는 어떻게 측정할까?

1. 프로덕트들의 공통적인 수치 지표

프로덕트 자체가 현재 순항을 달리고 있는지 측정하는 공통적으로 사용하는 지표를 알아보자!

1-1. DAU (Daily Active Users)

DAU(Daily Active Users)는 일일 활성 사용자 수를 의미하는 성과 지표이다.

이 지표는 서비스의 일일 사용량, 즉 특정 날짜에 서비스를 이용한 사용자의 수를 나타낸다. DAU를 분석하게 되면 서비스의 활동성과 인기도를 판단할 수 있다.

이 성과 지표를 분석하면 활성 사용자 이탈의 원인을 파악하고, 새로운 기능이나 콘텐츠를 추가하거나 마케팅 활동을 추가하여 DAU를 높일 수 있도록 조치를 할 수 있다.

1-2. MAU (Monthly Active Users)

MAU(Monthly Active Users)는 월간 활성 사용자 수를 의미하는 성과 지표이다.

이 지표는 서비스의 월간 사용량을 측정하며, DAU에 비해 장기적인 사용 패턴을 파악할 수 있다.

월간 활성 사용자가 얼마나 있는지, 그들이 서비스를 얼마나 자주 이용하는 지 그 패턴을 확인할 수 있는 성과 지표이므로

이를 통한 마케팅 전략 수립이나 서비스 기획 개선 의견을 도출할 수 있다.

1-3. Retention

Retention는 사용자의 재방문율을 의미하기 때문에 결국, 유지율을 의미한다.

이 지표는 사용자가 서비스를 계속 사용하고 있는지, 아니면 이탈하고 있는 지를 판단할 수 있다. 사용자 유지율은 신규 고객이 서비스가 출시된 후 일정 기간 동안 서비스를 계속해서 사용하는지, 얼마 후에 이탈을 하는 지 등을 분석할 수 있다. 사용자 유지율이 높다는 것은 사용자가 해당 서비스에 만족하면서 지속적으로 사용하고 있다는 것을 의미하므로 서비스가 사용자의 요구를 잘 충족하고 있다는 증거로 활용할 수 있다.

1-4. Stickiness

Stickiness는 DAU(Daily Active Users)를 MAU(Monthly Active Users)로 나눈 값을 통해 계산되는 성과 지표다.

Stickiness가 높다는 것은 사용자들이 자주 서비스에 접속한다는 것을 의미하며 이 서비스가 사용자에게 중독성이 있고 자주 들어오게 한다는 것을 나타낸다. 또한 사용자 유지율이 높으므로 고객이 받아들이는 서비스 품질이 높다는 것으로 해석할 수 있다.

이 성과 지표로 IT 서비스 기획자는 서비스의 강점과 약점을 파악하여 사용자의 경험을 개선할 수 있다.

1-5. Retention vs Stickiness 차이점?

Day N Retention = (Day N 사용자 수 / Day 0 사용자 수) × 100%
Stickiness = (DAU / MAU) × 100%

retention과 Stickiness를 알아보다가 문득, 둘의 명확한 차이점을 알고싶어졌다.

물론, 일반적으로 Stickiness가 높은 앱은 Retention도 강한 편이고, 둘 다 사용자 충성도를 나타내는 지표는 맞지만,

서로 독립적인 지표이다.

하지만, 의미와 측정 방식에 차이가 있다.

Stickiness는 사용자가 얼마나 자주 앱을 사용하는 지를 볼 수 있다.

즉, 사용자가 앱에 얼마나 '고착'되어 있는지를 나타낸다.

Retention은 사용자가 얼마나 다시 돌아오는지? 지속적으로 앱을 사용하는 지를 볼 수 있다.

사용자가 앱을 계속해서 '유지'하고 있는지를 나타낸다.

일정기간(1일, 7일, 30일 등)동안 앱을 사용하는 사용자의 비율을 측정한다.

Stickiness는 유저가 정~말 자발적으로 서비스를 이용하는 '자발적 요인' 을 나타내고

Retention은 자발적 서비스 이용 및 푸시 알림, 이메일 등 외부요인도 포함된다는 의견도 있다.

그래서 왜 두 지표를 각각 봐야하는데?

리텐션은 프로덕트의 첫 사용 이후, 일정 기간이 지난 시점에 다시 사용하는 사용자의 비율이다.

이 의미를 다시 뜯어보면 모호한 부분들이 있다.

첫 사용 이후 '얼마나 지난 이후를 측정하는가' '다시 사용'한다는게 무슨 의미일까?

우리 서비스가 어떤 서비스냐에 따라 목적에 맞는 사용을 할 수도 있지만 전혀 다른 용도로 서비스를 사용하더라도 '다시 사용' 했다고 정의할 수 있을까?

따라서 이렇게 생각해보자!

(1) 기준 시점에 대한 정의가 필요하다.

(2) 기준 행동의 정의가 필요하다. > (단순 '방문' 만이 아니라, 로그인, 결제, 콘텐츠 시청 등 어떤 행동을 '사용' 으로 볼 것인지 정의하자.

(3) 기간 정의가 필요하다. > 서비스 특성에 따라 D1, D7, D30 등 '언제 다시 왔는지' 를 임의로 정하자!

해당 정의들을 지피티의 도움을 받아 새로운 예시를 만들었다.

<식단 관리 앱 '다이어트M' 의 리텐션을 측정한다고 생각해보자.

- 1월 1일, 앱을 처음 설치하고 식단을 한 번이라도 기록한 신규 유저 : 2,000명 (Day0)
- 1월 2일, 다시 식단을 기록한 사람 : 1,000명 (D1 Retention = 1, 000/2,000 = 50%)
- 1월 8일, 다시 식단을 기록한 사람 : 600명 (D7 Retention = 600/2,000 = 30%)

우리가 생각해야 한 것은 이런 것이다.
✔️ 다이어트M은 첫날 설치한 사람 중, 절반이 다음 날에도 다시 기록이 되었다. (초반 온보딩과 첫인상 등이 인상깊었을 수 있다.)
✔️ 하지만 7일치에는 30%만 남았다. > 일주일 안에 습관화 되지 못한 사람들이 꽤 많이 이탈했다고 측정할 수 있다.

물론 중요한 점은, D7에 식단을 기록한 사람이, D1에서 D6동안 단 한번도 기록하지 않은 사람일수도 있다.
따라서 우리는 단순히 '재방문율'로만 통계를 잡을 수 없다. 그래서 우리는 “단순 재방문(retention)”만 보지 않고,
> 7일 안에 3번 이상 기록한 유저의 비율
> 7일 안에 목표 칼로리 설정까지 끝낸 유저 비율

처럼, 구체적인 행동을 기준으로 리텐션을 다시 정의하는 경우가 많게 된다.

즉, 리텐션은, 특정 코호트 (같은날, 같은 주에 유입된 사용자) 가 시간이 지나도 얼마나 살아남았는지를 보는 '생존 곡선' 에 가까운 지표이고, 고착도는 이 달에 한 번이라도 쓴 사람들 중 하루 기준으로 보면 몇 %가 매일같이 써주고 있는지를 보는 지표이다.

Retention	그때 처음 썼던 사람들 중 N일 뒤에도 남아 있는 사람은 몇 %인가?	가입/첫 사용 이후 경과 시간
Stickiness	이번 달에 한 번이라도 쓴 사람 중, 매일 돌아오는 사람은 몇 %인가	최근 한 달’이라는 고정된 기간 안에서 ‘사용 빈도’

인스타그램 같은 SNS은 자주 열고, 오래 머물수록 유리하기 때문에 고착도가 매우 중요한 서비스의 예시로 들 수 있다.
반대로 사용 주기가 긴 상품의 쇼핑몰은 매일 '들어오는 것 자체는' 딱히 중요하지 않기 때문에 고착도가 상대적으로 덜 중요하다.

2. 각 프로젝트를 수행할 때 프로젝트에 맞는 성과 지표는 어떻게 측정할까?

과제를 수행하다보면, 혹은 회사에서도 어떤 업무를 받았을 때,

해당 프로젝트마다 맞는 성과 지표는 어떻게 정의하고, 측정할 수 있을까?

물론 통용적인 수치만으로도 측정이 되는 과제들이 있을 수 있지만, 매 과제는 성격이 다르고 수행해야 하는 목적이 다르기 때문에 각각에 맞는 성과지표를 설계하여 보는 것이 유의미한 인사이트를 얻을 수 있다.

✔️ 우리가 왜 이 프로젝트를 하는가 (목적 정의)
✔️ 우리가 어떤 환경, 산업에서 (도메인)
✔️ 누구에게 (유저/ Target)
✔️ 무엇을 제공하는가 (Product/ Service)
✔️ 기대효과는 무엇인가 (KPI 설계하기)

✍ 목적 정의하기-우리가 왜 이 프로젝트를 해야 하는가?

목적 달성을 위한 목표를 설정하고/ 그 목표가 유의미한지 검증한다.

현상 > 해석 > 문제 정의 > 검증
그리고 우리가 정말 이게 문제가 맞는지! 를 검증해야 하는 과정을 거쳐야 한다.
실제로 목소리를 듣고 VoC를 분석하는 방법이 있고 여러 내부 자료를 얻어서 분석할 수 있다.

우리의 이 프로젝트를 실행해야하는 이유가 무엇일까? 이 프로젝트를 하게 되는 이유가 무엇일지에 대한 목적을 먼저 정의해야한다.

우리가 왜 이것을 실행해야하는지에 따른 목적을 명확히 설계한다면, 데이터를 어떻게 만드는지 그려지고, 성과 지표를 명확하게 설계할 수 있다.

✍ KPI 설계하기-기대효과는 무엇인지 어떻게 설정할까?

성과지표(KPI), 이렇게 설정하고 관리합니다 (인터뷰 전문)

진짜 의미있는 성과 지표를 세우는 방법

maily.so

> 해당 글을 참고하여 글을 작성하였습니다!

성과지표(KPI)는 팀과 조직이 어떤 방향으로 나아가고 있는지를 보여준다.

명확한 KPI가 있어야 구성원 모두가 동일한 목표를 향해 움직일 수 있고, 결과를 정량적으로 검사하며 팀의 방향을 설정한다.
KPI를 명확하게 설계하면 서비스가 고객에게 어떤 가치를 제공하고 있는지를 측정할 수 있다.

✍ OKR 설계하기

Objective는 조직이 도달하고자 하는 ‘목적지’를 의미한다. 즉, 되고자 하는 모습이나 고객에게 주고자 하는 가치를 나타낸다. 그래서 구성원에게 동기 부여할 수 있는 정성적인 문장 형태를 띠어야 한다.

Objective 가 어떤 뜻인지 설명하고, 그 목적지에 가까워졌는지를 측정할 수 있는 기준이 Key Result이다.

Key Result A, B, C 가 달성되면 Objective 가 달성된 것으로 팀이 합의하는 것이다.

참고! OKR과 KPI는 어떻게 다를까?

Objective(목표)와 Key result(목표 달성을 뒷받침하는 하위 목표의 결과값)로 구성된
OKR은 대담하고, 측정 가능하며, 시간에 따라 한정된 목표를 설정하고 추적하는 데 도움을 준다. 목표는 조직의 비전을 달성하기 위한 대한 짧고 함축적인 ‘선언’이라고 말할 수 있다!

OKR은 협업 조율, 대담한 목표 설정, 팀 및 구성원의 참여와 업무 진척의 투명성을 높이는 반면,
KPI의 주요 목표는 비즈니스 전반 또는 활동(예: 프로젝트, 프로그램, 제품)의 성공을 측정하고 관리한다.

따라서~~~
OKR은 목표 달성을 위해 다각적인 접근(일종의 관리 방법론)을 하기 때문에 KPI보다 시도할 수 있는 실행 범위가 넓고,
따라서 KPI는 OKR을 달성하기 위한 하위 목표나 달성해야 할 지표 중 일부로 사용되기도 한다.

용어를 좀 정리해보면,

KPI는 목표에 대해 진행상황을 추적할 수 있는 지표,

SMART는 목표를 설정하는 데 있어서 목표를 잘 설정할 수 있는 기준,

OKR은 조직이 되고자 하는 모습이나 고객에게 주고자 하는 가치이기 때문에 정성적인 문장 형태를 의미한다.

‍ SMART 원칙 적용하기
효과적인 KPI를 도출하기 위해서 SMART 원칙을 적용할 수 있다.
SMART 원칙은 KPI를 잘 '설계하기 위한 기준' 이다!

- Specific (구체적인) : 모호하지 않고 명확해야 한다.
- Measurable (측정 가능한) : 수치나 데이터 기반으로 성과를 파악할 수 있어야 한다.
- Achievable (달성 가능한) : 너무 무리한 목표는 동기를 떨어뜨릴 수 있다.
- Relevant (관련성) : 회사나 팀의 전략, 목표와 직접 관련있어야 한다.
- Time- bound (시간 제한) : 언제까지 달성해야 할지 기한 설정이 중요하다.

핵심 업무(Key Task)·CSF 파악하기

우리는 정량적, 정성적, 준정량적 지표를 적절히 조합하여 KPI를 설정한다.

핵심 업무 (*Key Task)와 핵심성공요인 (*CSF) 를 분석하여, 실제 조직 성과와 직결되는 직표를 뽑아내게 된다.

핵심성공요인 = Critical Success Factor (CSF)

✏️ KPI와 CSF는 어떤 것이 다를까?

- 목적(Objective) : 목적은 구체적으로 달성할 표적에 대해 언급하지 않고 기업이 가고자 하는 방향에 대해 개괄적으로 서술한 것
- 목표(Goal) : 목표는 달성하고자 의도된 구체적인 표적이다. 따라서 목표는 하나 또는 둘 이상의 목표를 조직적으로 변형한 것
- 핵심성공요인(CSF) : 개인이나 부서, 조직 등이 경쟁적 성과를 확보할 수 있는 소수의 영역, CSF는 기업이 번창하고 경영자의 목표를 달성하기 위해 바로 서야 하는 몇가지의 핵심영역.
즉, 목표를 달성하기 위해 현재의 운영과 수행활동과 연관이 깊다.
경영의 목적(Goal) 혹은 경영 목표(Objective)를 성취하는데 있어 중요한 내부 항목으로 목적 달성의 수단 역할을 하며, 핵심적인 세부 요소다.

CSF는 비즈니스 목표 달성을 위해 반드시 이루어져야 하는 필수 요소를 나타내며

KPI는 이러한 목표를 향한 진행 상황을 측정하고 추적하기 위한 지표를 제공한다.

예를 들어, 새로운 제품 출시의 CSF가 '시장 점유율 확대'라면 이는 제품의 성공을 결정짓는 핵심 요소로서 모든 전략적 의사결정의 기준이 된다.

이처럼 CSF는 조직의 방향성을 명확히 하고 자원 배분의 우선순위를 결정하는데 중요한 역할을 하게 된다.

반면 KPI는 CSF달성 정도를 '객관적으로 측정할 수 있는 구체적인 정량적 지표이다.

앞서 언급한 시장 점유율 확대라는 CSF를 KPI로 보면 '6개월 동안 시장 점유율 15% 향상' 이라는 구체적인 정량적 측정 지표로 제시할 수 있다는 것이다. 따라서 KPI를 통한 장기적인 측정이 CSF달성을 위한 노력이 될 수 있다.

참고

https://flex.team/blog/2024/02/16/okr-vs-kpi-difference/

https://www.linkedin.com/pulse/%EC%84%9C%EB%B9%84%EC%8A%A4-%EA%B8%B0%ED%9A%8D%EC%9E%90%EB%9D%BC%EB%A9%B4-%EC%95%8C%EC%95%84%EC%95%BC-%ED%95%98%EB%8A%94-%ED%95%84%EC%88%98-%EC%A7%80%ED%91%9C-4%EA%B0%80%EC%A7%80-sungho-kim-qijfc/

[AI] 나노바나나, 나도 써봤다!

hye2 이야기 — Wed, 3 Dec 2025 22:08:05 +0900

✍ 나노바나나란?

나노 바나나는 사실 코드명이고, 정식적으로는 구글이 제공하는 '생성형 이미지 모델' 라인업의 이름이다. 정확한 명칭은 Gemini 2.5 Flash Image 모델이라고 볼 수 있다.

이 모델의 핵심은 단순히 이미지를 생성하는 것을 넘어서 네이티브 멀티모달 아키텍처를 가지고 있다는 점이다.

텍스트와 이미지를 하나의 통합된 단계에서 처리하도록 처음부터 훈련되어있다.

‍ 원리를 조오금 뜯어보자

✔️✍ 기존에는 텍스트와 이미지, 참고 이미지를 각각 따로 이해해서 맨 마지막에만 대충 섞는 Late fusion 구조였기 때문에
'이 사람을 이 배경에 자연스럽게 넣어줘' 라는 복잡한 요구를 토큰 단위에서 충분하게 이해하기 어려웠으나,

나노바나나는 텍스트와 여러 장의 이미지를 처음부터 하나의 토큰 시퀀스로 만들어 한 Transformer 안에서 끝까지 같이 돌리는 early fusion 네이티브 멀티모달 아키텍쳐를 사용하기 때문에 그럴듯한 편집을 '한번에' 할 수 있게 되었다!!!

즉 조금 더 쉽게 말하면
기존에는 이미지를 잘~ 생성하는 모델과 이미지를 편집!하는 모델이 따로 있었으나,
생성하는 모델은 예쁜 이미지를 만들 수는 있었으나 실제로 활용하기는 어려웠고, 편집 모델은 이미지를 수정할 수는 있었으나 제한적이었다. 하지만 나노바나나는 이 두가지 기능을 융합했고 제미나이 모델의 기본 지능까지 결합했기 때문에
더욱 완벽한 이미지 생성 및 편집이 가능한 것!

기존 이미지 생성/편집 모델 (예: 초기 Imagen 계열, Stable Diffusion 기반 편집기 등)은 대체로 late fusion 계열로 구분한다.

텍스트 인코더와 이미지 인코더를 통해,

텍스트는 텍스트대로, 이미지는 이미지대로 몇 층을 타며 고차원 feature로 변환되고,

마지막에 diffusion UNet안에서 벡터로 합치거나 두 이미지의 최종 latent를 섞어버리는 식이었다.

이 설계의 문제점은 각 모달리티가 따로 놀다가 거의 끝에서만 만나기 때문에

“1번 사진의 인물을 2번 사진 거실에 앉히고, 조명은 2번 사진 기준으로 맞추고, 얼굴은 1번 사진이랑 완전히 동일하게” 같은 복잡한 요구를 이해해도,
실제 네트워크 안에서는 “누가 누구인지, 조명과 구도가 각 이미지 안에서 어떻게 배치돼 있는지”를
토큰 수준에서 서로 맞물리게 학습할 기회가 적게 된다!!!

결과적으로......

캐릭터 일관성 유지 실패
“첫 번째 사진의 조명 스타일을 유지한 채 두 번째 사진의 구도에 맞춰줘” 같은 미묘한 컨텍스트 이해 미흡
여러 장의 이미지를 섞을수록 이상한 콜라주 느낌, 어색한 경계, 그림자/원근 오류

같은 한계를 많이 보였고,

실제로 나노바나나 개발자도 “이전에는 생성 모델과 편집 모델이 따로라 실사용하기 애매했다”고 말했다!

✏️ 그렇다면....나노바나나는?

토큰 단계에서부터 한 세계로 만들게 된다.

나노바나나가 하는 건 한 줄로 요약하면 “텍스트와 여러 장의 이미지를 전부 같은 토큰 시퀀스로 만든 뒤,

하나의 거대한 Transformer 안에서 처음부터 끝까지 같이 돌린다”

모든 텍스트 입력을 토큰으로 쪼갠 뒤,

각 이미지는 Vision Transformer 스타일로 패치 단위(예: 16×16 픽셀)로 나눠서

discrete image token 혹은 patch embedding으로 바꾼다

(복잡한 말이지만 쉽게 말하면!)

여러 이미지를 넣으면 [이미지1 패치들] [이미지2 패치들] … [텍스트 토큰들] 같이 하나의 긴 시퀀스로 이어붙이게 되어

Transformer가 토큰 간의 관계를 구분할 수 있게 된다.

즉 하나의 Transformerrk 가 통과시키기 때문에

정보를 한꺼번에 정렬시키게 된다.

이때 각 층의 attention head는
“2번 이미지의 소파 패치”가
“1번 이미지의 사람 실루엣 패치”,
“텍스트 ‘노란 니트’, ‘오른쪽 끝 소파’ 토큰”
을 동시에 바라보면서,

하나의 멀티모달 latent가 생기고 한꺼번에 공간적으로 풀어내게 된다.

즉, 텍스트는 텍스트대로, 이미지는 이미지대로 자기 네트워크를 끝까지 타고 올라가고,

거의 맨 마지막 층에서야 “아 맞다 우리 멀티모달이었지?” 하면서 둘을 을 합치는 구조가 late fusion,

나노바나나는 텍스트와 이미지를 하나의 통합된 단계에서 처리하는 네이티브 멀티모달 아키텍처라고 이해할 수 있다.

즉 late fusion은 각 이미지가 독립 인코더를 타고 들어가 버려서, “이 토큰이 어제 그렸던 그 사람과 같은 사람이다”
라는 연결고리가 약하다 ㅠㅠ.
하지만! early fusion에서는 같은 사람의 얼굴 패치들이 계속 한 시퀀스 안에 등장하니까, Transformer가“이 눈썹 모양 + 코 각도 + 턱선 패턴 = 같은 identity”를 반복해서 학습할 수 있고,
새로운 장면을 생성할 때도 동일한 identity 벡터를 참조하게 되는 것이다.

GPT
- 중심은 텍스트 이해·생성·추론.
- 이메일, 기획서, 코드, 스크립트, 전략 문서, 분석 리포트, 프롬프트 설계 등 “언어”가 중심인 일에 강하다.
- 이미지도 만들 수 있지만(예: DALL·E 연동), 주력은 여전히 언어 쪽!!!.
나노바나나
- 중심은 이미지 생성·편집
- 텍스트를 잘 이해하는 건 “이미지를 잘 만들기 위한 수단”이고,
- 궁극적인 아웃풋은 항상 시각(이미지)라고 이해할 수 있다.

✏️ 특징은???

그래서 정확히 어떤 특징들을 가지고 잇냐면!

텍스트+이미지 기반 생성·편집 모델
캐릭터·브랜드 일관성에 특화
텍스트 렌더링이 강함
에코시스템 통합

한입 AI 레시피: Gemini로 디지털 광고 시안 만들기 (a.k.a 나노 바나나)

Gemini 2.5 Flash Image로 1분 만에 광고 시안을 만드는 방법을 소개합니다

modulabs.co.kr

요 링크에서는 디지털 광고 시안을 만드는 방법을 작성해주고 있으니

참고해도 좋을 듯하다!

프롬프트 설명 :
도심 버스 정류장 광고판에 사용할 소형 여행 카메라 광고를 제작하세요.
장면: 실제 도시 거리의 버스 정류장, 실제 광고 프레임이 설치된 모습.
환경: 가로등이 켜진 저녁 분위기, 도시 건물과 자연스러운 야외 환경. 가시성: 야외 시청 조건에 최적화된 고대비 디자인.
광고 디자인:
- 배경: 밝은 파란색에서 짙은 파란색으로 이어지는
그라데이션 - 중앙 비주얼: 첨부된 둥근 파란색 캐릭터와 카메라 이미지를 그대로 사용하세요.
캐릭터나 카메라를 재디자인하지 마세요.
- 텍스트 배치: 상단 중앙에 헤드라인을 두 줄로 배치하세요.

1줄: "TRAVEL LIGHT,"
2줄: "FEEL BRIGHT."
그 아래에 `"Your Journey, Simplified."` (중간 크기의 흰색 텍스트)를 배치하세요.
- 물결 패턴: 캐릭터 뒤쪽에서 오른쪽 위로 흐르며 헤드라인 텍스트와 겹치지 않도록 배치하세요.
스타일: 깔끔하고 미니멀하며 프리미엄한 느낌.
실제 도심 버스 정류장에 전문적으로 설치된 광고처럼 보이고, 자연스러운 도시 조명과 사실적인 원근감을 반영하세요.

프롬프트는 어떤 식으로 작성할까?

나노바나나는 “키워드 나열”보다 짧은 문장으로 장면을 설명해주면 성능이 더 잘 나온다는 팁이 한국 블로그·강의에서 공통적으로 등장하고 있다.

프롬프트를 쓸 때는:

누가(Who) – 인물의 나이, 성별, 스타일
어디서(Where) – 배경(실내/실외/도시/자연/매장 등)
무엇을(What) – 어떤 행동/제품/상황
어떤 느낌으로(Style) – 사진/일러스트/수채화/3D/레트로/키치 등
어디에 텍스트를(Design) – “상단 중앙에 ‘OOO’ 문구”, “우측에 제품 설명 박스” 등
비율·용도 – “9:16, 인스타 릴 썸네일용”, “16:9, 유튜브 썸네일용” 등

예를 들어 비타민 광고라면:

“30대 초반 한국인 여성 모델, 흰 셔츠와 재킷을 입고 밝게 웃으며 책상 위 비타민 병을 들어 보이는 장면. 배경은 밝은 병원 진료실 느낌. 상단에는 ‘하루의 시작, OOO 비타민’이라는 한글 텍스트를 굵고 깔끔한 폰트로 넣어줘. 4:5 비율 인스타 피드 광고용, 사진 스타일로.”

요즘 현업에서는

GPT로 콘셉트·카피·프롬프트 → 나노바나나로 이미지 → 다시 GPT로 성과 분석/테스트 아이디어

이런 식으로 활용하는 것이 많이 쓰이고 있다고 한다.

‍ 흠... 나노바나나를 활용해서 직접 만들어보자!

지피티 를 통해 이미지를 생성한 모습 (유료)

..더 흔들라고 했더니

그냥 눈을 감아버려서 아쉬웠다.

제미나이를 통해 생성한 모습 (나노바나나 모델)

골반통신 자체를 좀 이상하게 이해한 것 같기는 하지만....

일관성 있게 <더 흔드는 것 같은> 모습을 보여주는 것 같아 신기했다.

지피티가 생성해준 지피티는 이미지 자체는 고퀄리티였으나

<더 흔들어줘> 라는 문구를 한번 더 요구하니까 배경도 달라지고 더 흔드는 것 같은 느낌도 안났는데

재미나이가 만들어준 이미지는 확실히 기존 이미지에서 더 개선된 것 같은 이미지가 완성되어 신기했다.

다음번엔 직접!! 내 서비스에 나노바나나를 사용해봐야겠다. ......!!!!!

[서비스기획] 지그재그에서 사주를 봤다

hye2 이야기 — Sat, 29 Nov 2025 08:24:03 +0900

지그재그에서 사주 광고를 받았다.

아침에 출근하면서, 지그재그에서 이런 광고 문자가 왔다.

사실 내가 요즘 기업들이나 서비스 내에서 만드는 사주 서비스에 관심이 많았어서

유심히 봤다! ‍

✏️ 지그재그에서 출시한 사주 서비스를 뜯어보자!

해당 CRM 광고가 인상깊었던 이유가,
광고 자체에서 생년월일을 바로 입력할 수 있는 text field 라고 느껴지게 하여

입력하기 위해서 해당 광고를 눌러보고 싶게 만든다.

(사실 내가 속았다!)

앱으로 이동하면 이렇게

생년월일과 생일정보 수집에 관한 정보 항목이 나온다.

아마도! 지그재그에서 사주 서비스를 시작한 건,
생일 정보에 대해서 수집하고
생일에 맞춰 개인화된 쿠폰을 제공하는 것이 목적임이 아닐까!

첫 화면에 들어가면

보통 '연애운', '재물운' 등 카테고리가 나뉘어져 있는데 각 카테고리를 카드 ui로 만들어두어서

각각을 누르고 싶게 만든다.

그리고 후킹 멘트를 통해 해결하고 싶은 문제라는 인식이 든다!

지그재그에서 해결방법을 알려줄게!

사주 결과 화면을 보니,

결국 지그재그에서 추가로 의도하고자 하는 것은

사주로 문제를 알려주고 > 해결책까지 제시해준다!

어떻게?

지그재그에 있는 물건을 통해!

내가 ~~가 부족한데, 그렇게 하기 위해서는 ~~를 채워야 하는데 지그재그가 추천해줄게~

이렇게 흐름이 설계가 되어있다.

논리적으로 엄청 말이 된다기 보다, 결과지를 보기 위해 스크롤 하면서 지그재그의 상품들을 보게 되어

충분히 좋은 기획이라는 생각이 든다.

처음 사주 서비스는
단순히 사용자의 리텐션을 높이는 용도라고만 생각했는데 이렇게 커머스랑도 엮으니
충분히 매력적인 서비스가 된다는 것을 다시금 느낄 수 있었다!!

다른 앱들은 어떨까?

사주서비스를 활용하고 있는 다른 앱들을 함께 뜯어봤다.

(1) 운세 진입

먼저, CRM 으로 와서 접근할 수 있는 것들을 제외하고,

앱에 들어가서 타로 서비스를 접근할 수 있는 방법을 모색해보았다.

블라인드는 마이페이지 > 타로보기 로 비교적 간단한 허들이,

에이블리는 마이페이지가 아니라, 콘텐츠 > 운세 탭에서 쉽게 찾을 수 있었다.

지그재그는 마이페이지 > 오늘의 혜택 > 타로 단계로 많이.. 찾기가 어려웠다 ㅠㅠ.ㅠ...

만약 나처럼 CRM을 받지 않는 사람이라면 아마 해당 서비스를 찾기 어렵지 않았을까?

(2) 사주 카테고리 리스트 형태

블라인드는 리스트 형태의 ui를,

지그재그는 카드 ui를,

에이블리도 리스트 형태를 띄고 있었다는 것을 알 수 있었다.

(3) 알림 허용 유도

지그재그는 운세결과까지 다 보고 나면 '운세를 볼 수 있도록 알림 허용 하시겠습니까? 라는 모달이,

에이블리는 생년월일을 다 입력하고 운세 결과를 보기 직전에 무조건 알림을 받게끔 해야 결과를 보여주게끔 설계가 되어있다.

(4) 운세 더보기

블라인드랑, 에이블리는 한번 보고나서 추가로 운세를 보려면

B머니, 에이블리에서 사용하는 '베리'라는 것을 추가로 지불하게끔 한다.

지그재그는 '광고보고 운세보기' / '상품 구경하고 운세보기' 등

광고와 옷 구경하기라는 키워드를 바로 내세워 운세보기의 허들을 낮추고 있다.

개인적으로 나는 블라인드와 에이블리는 뭔가를 또 지불해야 하는 것 같아

아무것도 하지 않았지만 지그재그는 비교적 쉬운 미션이라 광고 한번 보지 뭐~ 이런 생각이 들었다.

지그재그를 조금만 더 뜯어보면,

광고를 보면 미리 알 수 있어요/ 상품을 구성하여 타로의 미리 볼 수 있게끔 하였고

상품 구경 또한 '45초' 라는 시간을 명시하여 사용자의 허들을 낮추는 것을 알 수 있었다.

총평!

요즘 자주 볼 수 있는 사주 서비스를 잘 활용하고 있는 서비스 3개를 뜯어보았다!
가장 인상깊었던 건 커머스와 사주를 잘 엮은 지그재그의 서비스였는데
블라인드와 에이블리에서도 고객 경험을 설계한 기획이었던 것 같아 재미있게 뜯어보았다.

모두가 도입하는 유행하는 기획을,내 서비스에서 잘 녹여내기 위해 어떤 목적을 가지고 이러한 서비스를 도입하게 됐는지 기획하다보면 더욱 차별화있고 재미있는 기획이 될 것 같다