요즘IT » 기획 » 피드

구슬은 이미 많다, 비즈니스를 꿰는 기획자의 실전 로직

이커머스 기획은 왜 '화면'이 아니라 '정책'이어야 하는가?

이커머스 프로덕트를 만드는 서비스 기획자들에게 가장 위험한 함정은 "주문 버튼이 잘 작동하니 문제가 없다"라고 믿는 것입니다. 하지만 비즈니스 관점에서 이커머스는 단순한 쇼핑몰이 아니라 '돈과 데이터가 얽힌 정밀한 사슬'입니다. 이 사슬은 유저가 진입하는 순간부터 상품을 탐색하고, 결제 버튼을 눌러 물건을 손에 쥐고, 때로는 변심하여 환불을 요구하는 그 모든 여정을 관통합니다.

기획자가 설계하는 사슬 하나가 느슨해지면 마케팅 지표가 오염되고, 재무팀은 정산 사고를 수습하느라 밤을 지새우며, 고객의 신뢰는 라스트마일(Last-mile)에서 무너집니다. 이번 글을 통해 이제 막 커리어를 시작한 주니어 기획자에게는 실무의 '길잡이'가 되고, 운영 효율을 고민하는 의사결정권자에게는 '비즈니스 정합성'을 지키는 체크리스트가 될 이커머스 온보딩 시리즈를 시작합니다. 단순히 기능을 나열하는 매뉴얼이 아닌, 프로덕트의 지속 가능성을 위한 설계도를 함께 그려보겠습니다.

미리 요점만 콕 집어보면?

이커머스는 ‘돈과 데이터가 얽힌 정밀한 사슬’이며, 주문 버튼이 아니라 정책 설계가 비즈니스의 핵심입니다.
회원·상품·주문·배송·클레임 도메인은 각각 데이터 무결성, 수익 분석, 정합성, 물류 비용, 고객 유지에 직접 영향을 미칩니다.
기획자가 설계하는 정책 한 줄이 마케팅 지표와 현금 흐름, 데이터 신뢰도를 좌우하며 인과관계로 도메인을 꿰는 관점이 필요합니다.

비즈니스 가치를 결정짓는 5대 핵심 도메인과 정책

<출처: 작가, 제미나이로 생성 >

이커머스는 크게 다섯 가지의 핵심 도메인으로 나뉩니다. 각 영역은 독립적으로 존재하는 듯 보이지만, 기획자가 설계한 '정책'이라는 실로 꿰어져 하나의 보배(비즈니스)가 됩니다.

다섯 가지 도메인인 회원과 인증, 상품 관리, 주문과 결제, 배송 처리, 클레임과 환불을 중심으로 숙지해야 할 필수 개념(용어 및 정책) 과 비즈니스 임팩트를 서술해 보도록 하겠습니다. 비즈니스 포인트를 이해하는 것은 기획 단계의 정책 설계를 보다 정교히 할 수 있고, 추후 성과 측정을 위한 데이터 집계 / 트래킹 과정에서도 빛을 발합니다. 결국 용어와 개념을 많이 아는 것보다 그것이 불러일으킬 ‘비즈니스 임팩트(포인트)’ 를 아는 것이 기획자에게는 가장 중요합니다.

1. 회원과 인증: 고객 데이터의 무결성을 지키는 시작점

회원 도메인은 서비스의 첫인상이자 데이터의 뿌리입니다. 단순히 아이디와 비밀번호를 DB에 저장하는 기능을 넘어, 휴면 정책, 본인인증(Identity Verification) 수단, 그리고 중복 가입 방지 로직을 수립하는 단계입니다. 특히 최근에는 소셜 로그인(Social Login)의 비중이 높아지면서, 각 채널별로 들어오는 유저 데이터를 어떻게 하나의 식별자(Unique ID)로 통합할 것인가가 기획의 핵심입니다.

비즈니스 포인트: 체리 피커를 막는 비용 최적화

회원 정책이 부실하면 마케팅 예산은 허공으로 사라집니다. 예를 들어, 신규 고객 유치를 위해 '첫 구매 1만 원 할인 쿠폰'을 배포한다고 가정해 봅시다. 만약 본인인증 로직을 통한 1인 1계정 원칙이 강제되지 않는다면, 한 명의 유저가 가상 번호나 여러 계정을 동원해 쿠폰을 중복 수령하는 '체리 피킹(Cherry Picking)'을 막을 수 없습니다. 이는 유저당 평균 매출(ARPU) 지표를 왜곡할 뿐만 아니라, 실제 서비스 성장에 기여하지 않는 허수 고객에게 마케팅 비용이 투입되는 결과를 초래합니다. 기획자는 본인인증 단계를 설계할 때, 이 절차가 주는 '유저 경험의 허들'과 '데이터의 무결성' 사이의 황금비율을 찾아야 합니다.

2. 상품 관리: 수익 분석의 기초가 되는 데이터 계층

상품 도메인은 원본 상품 - 전시 상품 - 판매 옵션의 3단계 계층 구조를 가집니다. 원본 상품은 공급가와 원가 등 '비용' 정보를 가지고, 전시 상품은 마케팅을 위한 '얼굴' 역할을 하며, 판매 옵션은 물류의 최소 관리 단위인 SKU(Stock Keeping Unit)를 결정합니다.

비즈니스 포인트: 깜깜이 경영을 막는 ROI 설계

이 계층 구조가 무너지면 경영진은 "우리가 이번 달에 실제로 번 돈이 얼마인가?"라는 질문에 답할 수 없습니다. 원본 상품 테이블에 '매입 원가' 필드가 누락되어 있다면, 아무리 수천억의 매출이 발생해도 상품별 순이익(ROI) 분석은 불가능합니다. 또한 전시 카테고리와 내부 관리 카테고리를 분리하지 않으면, 마케팅 부서에서 광고비를 투입한 카테고리와 정산 부서에서 매출을 집계하는 카테고리가 엇갈리는 데이터 사일로(Silo) 현상이 발생합니다. 기획자가 설계하는 상품 데이터의 계보는 단순한 정보 관리를 넘어 기업의 예산 집행 우선순위를 결정하는 나침반이 됩니다.

3. 주문과 결제: 1원의 오차도 허용하지 않는 정합성

<출처: 작가, 제미나이로 생성>

결제(Payment) 버튼을 누르는 찰나의 순간, 시스템은 방대한 검증 로직을 수행합니다. ‘ 최종 결제 금액 = (상품가 ± 옵션가) - 할인 + 배송비’공식이 단 1원의 오차 없이 성립해야 합니다. 이때 주문 번호(Order No)와 품목별 주문 번호(SND No)를 분리하여 설계하는 것이 핵심입니다.

비즈니스 포인트: 정산 사고와 CS 비용의 상관관계

주문 데이터 설계가 미흡하면 재무팀은 매달 수천 건의 데이터를 수동으로 대조하는 지옥에 빠집니다. 특히 카드, 가상계좌, 에스크로(Escrow) 등 결제 수단별로 다른 취소 정책을 기획 단계에서 고려하지 않으면 결제 완료 후 취소 시 환불 금액이 꼬이는 사고가 발생합니다. 예를 들어, 가상계좌 결제 유저에게 환불 계좌 수집 프로세스를 누락한다면, 상담원이 일일이 전화를 걸어 계좌를 받아내야 하는 막대한 CS(고객 상담) 비용이 발생합니다. 기획자가 설계하는 식별자 체계와 결제 로직은 운영 리소스를 최소화하고 기업의 현금 흐름을 투명하게 만드는 가장 강력한 장치입니다.

4. 배송 처리: 고객 신뢰와 물류 비용의 최적화

결제 이후 데이터는 물류와 배송의 영역으로 흐릅니다. 묶음 배송과 개별 배송을 구분하는 로직, 그리고 우편번호(Zip-code) DB와 연동하여 제주 및 도서산간 지역의 추가 배송비를 자동으로 산출하는 정책이 이 단계에서 확정됩니다. 또한, 출고지 주소 데이터를 기반으로 최적의 택배사를 매칭하는 로직도 포함됩니다.

비즈니스 포인트: 누락된 배송비의 나비효과

배송 정책은 물류 원가와 직결됩니다. 만약 추가 배송비 로직이 자동화되어 있지 않다면, 판매자는 건당 수천 원의 손실을 고스란히 떠안게 됩니다. 반대로 결제 이후 고객에게 추가 입금을 요청하는 프로세스는 최악의 구매 경험을 제공하며 브랜드 이탈을 가속화합니다. 프로덕트 기획자는 단순히 '송장 번호'를 보여주는 기능을 넘어, 물류의 물리적인 흐름이 디지털 데이터와 실시간으로 동기화되어 고객에게 안심을 주는 라스트마일(Last-mile)의 흐름을 완성해야 합니다.

5. 클레임과 환불: 예외 상황을 고려한 방어적 기획

취소, 반품, 교환은 기획자가 가장 마주하기 싫지만 가장 꼼꼼해야 하는 구간입니다. 부분 취소 시 초기 무료 배송 조건이 깨졌을 때 배송비를 어떻게 차감할지, 결제 수단별로 환불 기한과 방식은 어떻게 다른지 정의해야 합니다. 또한 교환 시 재고를 선점하는 로직과 회수지 주소를 관리하는 정책이 수반됩니다.

비즈니스 포인트: 고객 유지(Retention)와 손실 방어의 저울질

클레임 정책은 브랜드 충성도를 결정합니다. 하지만 무조건적인 '묻지마 환불'은 악성 유저를 양산하고 물류 비용을 폭증시킵니다. '배송 준비 중' 단계에서는 직접 취소를 제한하고 판매자 승인을 거치게 하는 등의 제어 로직은 운영 효율과 유저 편의 사이의 균형점을 찾는 고도의 전략적 기획입니다.

결론: 구슬을 보배로 만드는 기획자의 관점

결국 이커머스 기획의 본질은 흩어진 도메인 지식이라는 구슬을 '인과관계'라는 실로 꿰어가는 과정입니다. 앞단에서의 사소한 정책적 선택이 뒷단에서는 거대한 지표의 오염이나 운영의 비효율로 돌아옵니다. 기획자가 설계하는 정책 한 줄이 비즈니스의 현금 흐름과 데이터의 신뢰도를 결정한다는 책임감이 필요합니다.

이번 첫 글을 시작으로, 이커머스의 각 도메인을 깊숙이 파고들며 [이커머스 온보딩 : 부사수 인계서] 시리즈를 연재하려 합니다. 각 회차마다 실무에서 즉시 적용 가능한 정책 로직은 물론, 그것이 실제 비즈니스 지표(KPI)와 어떻게 연결되는지, 그 이면의 이야기를 들려드리겠습니다. 튼튼한 로직 위에서 비로소 흔들리지 않는 이커머스 프로덕트가 완성됩니다. 그 여정에 함께해 주시기 바랍니다.

[사수의 인계 노트]

데이터 마인드: 지금 설계하는 필드가 3개월 뒤 어떤 매출 리포트에 찍힐지 상상해 보세요.
방어적 기획: 고객의 행복한 경로(Happy Path)뿐만 아니라, 모든 이탈과 변심의 순간을 정책에 담으세요.
비즈니스 커뮤니케이션: 개발자와는 기술 용어로, 재무팀과는 정산 로직으로 소통할 수 있는 언어의 유연성을 기르세요.

]]>

클로드 코드와 MCP 연결로 디자인 감도 높이는 법

바이브 코딩을 할 땐 어떤 도구를 사용하든 결과물이 묘하게 비슷비슷하게 느껴졌다. 특히 클로드 코드로 만든 결과물이 유독 평범하게 보였다. 그리고 클로드로는 주로 글 정리나 슬라이드를 만들 때만 사용하고 있어서 처음 클로드 코드를 설치한 후, 삭막한 까만 창을 보는 순간에는 그냥 익숙한 커서나 안티그래비티로 만들걸 그랬나? 라는 생각이 들기도 했었다.

설상가상으로 왼쪽에 폴더 트리가 없으니 클로드 코드와 슈퍼베이스(Supabase) MCP를 연결할 때 토큰을 입력할 설정 파일(.claude/settings.json)을 윈도우에서 찾느라 터미널과 한참을 씨름하기도 했다. 그렇지만 MCP(Model Context Protocol)를 사용하면서부터는 한결 편리해져서 클로드 코드를 메인으로 사용하고 있다.

그래서 이번 글에서는 클로드 데스크탑에서 블렌더(Blender), 스테이블리티 AI(Stability AI) MCP를 연결하고, 클로드 코드와 피그마(Figma), 스티치(Stitch) MCP를 연결하여 '평범한 앱'을 '감각적인 앱'으로 끌어올리는 과정을 공유하려 한다.

*참고: 최종 완성된 가족과 함께 남은 삶을 기록하는 웰다잉 앱

앱 디자인에 감각을 더해 완성하기

앞서 언급했듯이 다른 바이브 코딩 도구를 사용하다가 클로드 코드를 사용하게 된 전환점은 MCP를 사용하면서부터였다. 특히 스티치, 피그마와 직접 연결해서 사용하면 디자인 파일을 분석하고 수정 방향까지 제안받을 수 있다.

As-Is 앱 디자인: 스티치에서 만든 디자인 무엇이 문제였을까?

처음엔 스티치에서 UI 디자인을 만든 후 클로드 코드와 연결했다. 다음엔 클로드 코드에 현재 디자인 기반으로 앱을 만들어달라고 요청했더니 아래와 같은 결과물이 나왔다. 따뜻한 느낌의 앱을 원했지만, 결과는 우직한 블루톤 계열이라 차갑게 느껴졌고 UI 디자인에 적합한 스티치로는 키 비주얼을 잡는 데에는 한계가 있었다.

As-Is) 클로드 코드와 스티치 MCP를 연결해서 만든 앱 <출처: 작가>

To-Be 앱 디자인: 앱의 목적과 사용자 감정까지 고려한 디자인으로 수정

웰다잉 앱의 본질은 '죽음 준비'가 아니라 '삶의 기록’이어서 뭔가 따뜻한 느낌을 전달할 수 있는 메모리얼 오브제가 필요했다. 그래서 프롬프트에 메시지와 감정을 담아서 사용자가 기록을 채울수록 빛나는 오브제를 블렌더에서 만들었다.

다음으로 스테이블리티 AI로 배경, 포인트 컬러, 유리 질감 효과, 그리고 부드러운 애니메이션까지 포함된 디자인 방향을 잡았다. 이 스팩을 피그마에서 컴포넌트로 정리한 뒤, 클로드 코드에게 “현재 피그마 스펙에 맞춰 동기화하고, 전체 UI에 반영해 줘"라고 요청해서 최종 완성했다.

To-Be) 디자인 감도를 높여 본 앱 <출처: 작가>

이처럼 디자인 컨셉을 정할 땐 프롬프트에 전달할 메시지나 감정을 함께 정하면 결과물이 달라진다.추가로 MCP를 연결하면 디자인 방향을 수정하더라도일관된 컴포넌트를 전체 화면에 적용할 수 있다는 점이 좋았다. 자 지금부터 구체적으로 MCP와 어떻게 연결하고 프롬프트를 작성해서 완성했는지 살펴보자.

클로드 데스크탑에 블렌더, 스테이블 AI MCP 연결하기

따뜻한 디자인으로 변경하기 위해서 핵심 메시지와 감정을 시각화할 수 있는 오브제가 필요했다. 그래서 AI 에이전트에게 삶에 기록이 많아질수록 성장하는 시각적 보상 시스템이 될 만한 게 뭐가 있을까? 라고 질문하는 것부터 시작했다. 클로드는 '별빛 조약돌'이라는 키워드를 제안했다. "삶이 끝나는 것이 아니라, 별이 되어 빛난다"는 핵심 메시지와 함께 별처럼 골드 빛이 나는 조약돌을 만들기로 했다.

보통은 컨셉 이미지나 키 비주얼을 만들 땐 나노바나나(Nano Banana)와 미드저니(Midjourney)를 주로 이용하지만, 3D 이미지와 영상이 필요해서 블렌더를 사용했다. 이처럼 필요한 MCP가 있다면 스미더리, 컴포시오, mcp.so 원하는 기능을 검색한 다음 클로드 데스크탑에서 설치 명령어를 받고 연결해서 사용하면 된다.

1) 블렌더 MCP 연결로 대화하며 3D 이미지와 영상 제작하기

블렌더 MCP를 이용하면 3D 이미지나 영상을 간단한 대화만으로도 만들 수 있다. 블렌더는 연결 과정이 다소 복잡하고 서버 연결이 자주 끊기는 단점이 있지만, AI 에이전트가 알려주는 데로만 하면 되니 걱정하지 않아도 된다. 먼저 파이썬과 UV를 설치하고 MCP를 설정하는 절차와 동일하게 클로드→데스크톱→설정→개발자→설정 편집→ Claude_desktop_config.json 파일에 코드를 입력한다.

추가로 블렌더를 다운로드 받아 설치하고 블렌더 MCP 깃허브에서 설치 명령어를 복사한다. blender-mcp-main.zip 파일을 다운로드 받아 블렌더에서 실행하고 설정한다. 그러면 클로드 데스크탑에서 아래와 같이 프롬프트를 입력해서 블렌더에서 결과물을 만들 수 있다.

프롬프트 : 블렌더로 렌더링해 줘
오브제 형태
└─ Icosphere 기반의 납작한 조약돌 모양 (스케일 조정 + Subdivision + Displace로 자연스러운 굴곡)
└─ 크기가 다른 작은 조약돌 2~3개가 함께 배치된 구성
└─ 어두운 대리석 받침대
뼛가루 유리화 재질 (핵심)
└─ SSS(Subsurface Scattering): 빛이 내부를 투과하는 따뜻한 크림/오프화이트 빛
└─ Translucent BSDF 믹스: 은은하게 빛이 비치는 반투명 효과
└─ 노이즈 텍스처: 표면마다 자연스러운 색상 변화
└─ Bump: 미세한 표면 질감
조명 & 카메라
└─ 3점 조명 (메인 소프트박스 + 차가운 보조광 + 림라이트)
└─ 85mm 망원 느낌의 카메라 앵글

블렌더 MCP 연결하는 방법 및 3D 이미지와 영상 만들기 <출처: 작가>

다소 복잡해 보여도 세팅하고 나면 컨셉만 입력해도 클로드가 블렌더 안에서 직접 오브젝트를 배치하고, 재질을 입히고, 조명을 세팅하고, 렌더링해서 결과물을 만들어 준다. 3D 툴을 한 번도 써본 적 없었는데 '원하는 무드의 비주얼'을 대화로 만들 수 있다는 점에서 매우 만족스러웠다.

2) 스테이블리티 AI MCP 연결로 컨셉 이미지와 키 비쥬얼 만들기

앱 전체를 일관된 이미지로 만들 때 쓸만한 MCP가 뭐가 있을까 찾다가 스테이블리티는 AI를 발견했다. 스테이블리티 AI는 API 연결이 필요해서 대시보드에서 API 키를 받고, 해당 키와 함께 스테이블리티 MCP 깃허브에서 코드를 복사하여 연결하면 된다.

Settings→Security→Generate new token→토큰 복사 후 설정 파일(.claude/settings.json)에 저장한 후 클로드 데스크탑을 다시 실행한다. 이후에는 대화 창에서 원하는 이미지을 설명만하면 Claude가 직접 스테이블리티 AI의 모델을 호출해 결과물을 돌려준다.

스테이블리티 A를 활용하면 단순히 이미지를 하나 뽑는 게 아니라, '배경 제거 → 스타일 조정 → 업스케일'처럼 여러 내장 도구를 유기적으로 연결해 하나의 워크플로로 자동화할 수 있다. 이미지 생성 하나에도 '분석 → 생성 → 수정 → 검토'의 전체 사이클이 한 대화 안에서 이뤄져서 좋았다.

프롬프트 :/stability-ai 로 삶의 마지막을 가족과 함께 기록하는 웰다잉앱의 대표 화면을 만들어줘. 한국인의 정서에 맞는 따뜻하고 감동적인 앱의 화면의 컨셉을 디자인하려고 해. 짙은 네이비 배경, 그래디언트 포인트 컬러, 카드에 유리 질감을 주는 Glass morphism 효과, 그리고 데이터 따뜻한 불빛이 반짝이는 듯한 부드러운 애니메이션이 필요해.

스테이블리티 AI MCP연결 방법 및 컨셉 이미지 만들기 <출처: 작가>

클로드 코드에 스티치, 피그마 MCP 연동하기

앞서 살펴본 스테이블리티 AI와 블렌더로 '비주얼 소재'를 만들었다면, 이제는 클로드 코드에 피그마와 스티치를 MCP로 연결하여 앱 디자인 자체를 바꿔보자. 먼저 클로드 코드에 스티치와 피그마 MCP를 연결하는 방법은 간단한데, 연결하고 나면 클로드 코드가 피그마의 디자인 토큰을 읽어 스티치의 컴포넌트 스펙과 동기화하고, 그 결과를 코드에 반영하는 흐름이 하나의 대화 안에서 이뤄지므로 정말 편리하다.

1) 생각보다 간단한 클로드 코드와 스티치 MCP 연결하기

스티치에서 만든 디자인을 선택하고 오른쪽 상단에 Export→MCP→ Setup MCP→클라이언트에서 클로드 코드로 선택→API 키 복사 후 명령어 입력하면 된다.

프롬프트 :핵심 타겟 (Primary) 부모님과 자신의 노후를 걱정하기 시작한 5060세대가 이용하는 웰 다잉 앱을 만들려고 해 - 공동 작성 엔딩 노트: 가족과 공유하는 법적/정서적 기록, - 타임캡슐 메시지: 사후 지정된 날짜에 전송되는 영상/편지, - 간편 가이드: 상속, 장례, 기부 절차 템플릿

As-Is) 스티치에서 UI 디자인 후 클로드 코드에 MCP 연결하기 <출처: 작가>

2) 클로드코드와 피그마 MCP 연결로 일관된 디자인 적용하기

앞서 블렌더와 스테이블리티 AI로 만든 결과물을 피그마로 불러와서 컴포넌트를 정리했다. 그리고 클로드 코드와 연결하기 위해 Settings→Security→Generate new token→토큰 복사 후 설정 파일(.claude/settings.json)에 복사한 후 명령어 입력을 한다. 이후 클로드 코드에서 /mcp 를 입력하면 MCP 목록이 나타나는데 이때 피그마 항목을 선택하여 Authenticate을 새로운 브라우저 창에서 Allow Access를 클릭하면 연결된다.

프롬프트 :현재 Figma 스펙에 맞춰 동기화하고, 전체 UI에 반영해 주되 좀 더 따뜻한 별빛이 반짝이는 듯한 부드럽게 아름답게 전체 디자인을 단계별로 업그레이드해 줘

To-Be) 피그마 MCP 연결 방법 및 디자인 적용하기 <출처: 작가>

MCP를 통해 감성적인 연결까지 가능한 시대

솔직히 클로드 코드의 까만 창이 처음에는 무척 낯설었고 과연 명령어만으로 원하는 데로 디자인을 할 수 있을까? 라는 생각이 들기도 했다. 그런데, MCP를 사용하면서 그 안에서 피그마의 디자인 언어가, 스티치의 컴포넌트 스펙이, 스테이블리티 AI의 이미지가, 블렌더의 3D 비주얼이 하나로 연결되는 워크플로로 돌아가기 시작했다.

이렇게 여러 디자인 AI 도구를 연결해 이용하면서 같은 기능, 같은 목적의 앱이지만 디자인에 따라 사용자가 느끼는 감정은 달라질 질 수 있다는 점을 알게되었다. 물론 디자이너의 전문성까지는 아니어도 대화 한 번으로 단순히 "예쁘게"가 아니라 어떤 메시지를 전달할지, 어떤 감정을 주고 싶은지까지 설계할 수 있다는 점에서는 한 번쯤 이용해보길 추천한다.

끝으로 대화만으로 컨셉 이미지를 만들고, 3D 입체적인 질감을 구현하고, 앱 디자인을 만드는 전체를 다듬어가는 사이클 자체에서도 매 순간 새로운 영감이 계속 생겼다. 이처럼 누구나 바이브 코딩 시대에 창의적 활동도 함께 시작해 보자.

]]>

매일 쓸 것 같다던 그 기능, 왜 아무도 안 썼을까?

UX 리서치를 하다 보면 이상하게 자주 반복되는 장면이 있다. 사용자는 인터뷰에서 매일 쓸 것 같다고 말하고, 설문에서는 알림이 꼭 필요하다고 체크하고, 쇼핑 앱에서는 가격이 제일 중요하다고 단언한다. 그런데 출시 후 데이터를 보면 그 기능은 며칠 만에 잊히고, 알림은 대부분 꺼져 있고, 결제 단계에서 더 비싼 브랜드가 선택된다. 말이 틀렸고 행동이 맞다는 결론을 내리기엔 너무 단순하고, 반대로 행동이 우연이고 말이 진짜라는 쪽도 위험하다. 이 지점이 UX 리서치의 흥미로운 핵심이다. 말과 행동이 다르다는 사실 자체가 힌트고, 그 힌트를 증거로 바꾸는 과정이 바로 UX의 일이다.

UX/UI 디자이너에게 유저 리서치는 항상 딜레마를 준다. <출처: 작가, ChatGPT 제작>

약간의 도발성 표현이지만, 여기서 유저는 거짓말한다는 표현은 도덕적 비난과는 전혀 관련이 없다. 인간의 말은 늘 이상적인 자기 이미지와 사회적 기대를 섞어 만든 설명이고, 행동은 마찰과 환경에 반응한 결과다. 그래서 UX 리서치는 유저를 심판하는 일이 아니라, 말과 행동 사이의 간극을 구조적으로 해석하고, 계측과 실험으로 확인해 설계로 바꾸는 일이다. 이 글은 그 간극을 조금 더 테크니컬하게 다루는 방법을 정리한다.

왜 말과 행동은 어긋날까? 심리 + 시스템이 함께 만든다

다양한 심리적 요인이 말과 행동의 불일치를 만든다. <출처: 작가>

말과 행동의 불일치를 설명하는 심리적 요인은 이미 꽤 잘 알려져 있다. 첫째는 사회적 바람직성 편향이다. 사람은 좋은 사용자, 책임감 있는 사람처럼 보이고 싶어 한다. 그래서 알림이 필요하다고 말하지만 실제로는 알림이 귀찮고 피곤해서 꺼버린다. 둘째는 기억 오류다. 지난주에 썼던 것 같다고 말해도 로그에는 기록이 없다. 기억은 저장이 아니라 편집이고, 반복 행동일수록 더 쉽게 섞인다. 셋째는 자기 합리화다. 불편했는데도 괜찮았다고 말하는 경우가 있다. 인정하는 순간 내가 서툰 사용자처럼 보일까 봐, 혹은 내가 선택한 서비스를 깎아내리기 싫어서, 무의식적으로 설명을 예쁘게 만든다. 넷째는 미래 예측의 비현실성이다. 매일 쓸 것 같다는 말은 대부분 현재의 열정으로 미래의 시간을 과대평가한 결과다. 헬스장 등록이 늘 과잉 예약되는 것과 비슷하다.

하지만 여기서 한 번 더 나아가야 한다. 많은 불일치는 심리만이 아니라, 시스템이 만들어낸다. 알림이 중요하다는 사람이 알림을 안 켠다면, 그건 중요하지 않아서가 아니라 알림을 켜는 흐름이 부담스럽거나, 어떤 알림이 오는지 예측이 안 되거나, 해제와 조절이 불편하거나, 권한 요청 타이밍이 너무 이르거나, 알림 자체가 신뢰를 해치는 경험이었기 때문일 수 있다. 사용자는 의지로 움직이는 존재가 아니라 마찰과 기본값과 맥락에 반응하는 존재다. 그래서 유저의 말이 거짓이냐 진실이냐를 판단하기 전에, 제품이 어떤 행동을 쉽게 만들고 어떤 행동을 어렵게 만들었는지부터 확인해야 한다.

UX에서 자주 쓰는 행동과학 해석 도구: 말은 이상, 행동은 마찰의 결과다

여기서 말하는 해석 도구라는 건, 사용자의 발화나 로그를 볼 때 그냥 감으로 해석하지 않고, 어떤 원리로 보면 더 잘 설명되는지를 정해주는 일종의 관점이다. 같은 현상을 보더라도 어떤 관점으로 보느냐에 따라 원인이 달라지고, 원인이 달라지면 처방도 달라진다. 그래서 이 관점들은 디자이너 입장에서 문제를 더 빨리 분해하고, 더 정확하게 실험으로 연결하기 위한 도구로 쓰인다.

실무에서 말과 행동의 간극을 해석할 때 유용한 관점들이 있다. 이건 특정 교과서에 박힌 단일한 UX 원칙 세트라기보다, 인지심리학·행동경제학에서 검증된 개념을 UX에서 원칙처럼 활용하는 방식에 가깝다.

1) 최소 노력의 법칙

사용자는 가장 쉬운 경로로 흐른다. 의도와 결심보다 손이 덜 가는 선택이 이긴다. 예를 들어, 금융 앱에서 자동이체 등록 기능을 많이 원한다고 인터뷰에서 말했는데 실제 등록률이 낮다면, 그 기능이 필요 없어서가 아니라 등록 과정이 길어서일 수 있다. 계좌 선택, 인증, 약관 동의, 금액 입력, 시작일 선택이 한 화면에 몰려 있고, 중간에 인증이 끊기고, 다시 돌아오면 입력값이 날아가는 순간, 사용자는 말로는 필요하다고 해도 행동으로는 포기한다. 같은 기능이라도 시작 버튼을 홈에 두고, 기본값을 추천으로 채워주고, 다음에 이어하기를 제공하면 등록률이 튀는 경우가 있다. 이때 사용자는 갑자기 의지가 생긴 게 아니다. 덜 피곤해진 거다.

<출처: 작가>

2) 인지 부하 최소화

사용자는 화면을 읽고 판단하고 기억하고 비교하는 비용을 싫어한다. 알림을 예로 들면, 알림이 중요하다고 말한 사람이 실제로 알림을 꺼버리는 이유는 알림이 정보가 아니라 판단을 요구하는 업무처럼 느껴지기 때문이다. 입금 알림, 소비 리포트, 이벤트 혜택, 마케팅 소식이 뒤섞여 오고, 문구는 긴데 핵심이 안 보이고, 눌러도 어디로 가는지 예측이 안 되면, 알림은 계속 작은 판단을 요구한다. 결국 사용자는 알림을 꺼서 인지 부하를 줄인다. 그래서 알림을 살리려면 더 세게 보내는 게 아니라, 알림 자체를 더 단순하게 만들어야 한다. 어떤 알림인지, 왜 지금 왔는지, 누르면 뭐가 해결되는지, 그리고 조절은 어디서 하는지까지 한 번에 이해되게 하는 게 핵심이다.

<출처: 작가>

3) 기본값 효과

사람은 설정을 잘 바꾸지 않는다. 기본값은 제품이 사용자에게 강하게 주입하는 추천이다. 예를 들어, 뉴스레터 구독이나 푸시 알림이 기본값 켜짐으로 되어 있으면, 사용자는 적극적으로 동의해서 켠 게 아니라 그냥 흘러가다 보니 켜진다. 반대로 기본값이 꺼져 있고, 켤 기회를 한 번도 제대로 주지 않으면, 알림이 중요하다고 생각하는 사용자조차 그냥 계속 꺼진 상태로 남는다. 실무에서 자주 보는 패턴은, 알림을 켜게 만들고 싶어서 온보딩 첫 화면에 권한 요청을 띄우는데, 이때 사용자는 아직 이 앱이 나에게 어떤 가치를 주는지도 모르기 때문에 거절한다. 그리고 기본값은 그 거절 상태로 굳어버린다.

그래서 기본값 효과를 UX에서 제대로 쓰려면, 언제 기본값을 제안할지와 어떤 맥락에서 기본값이 납득되게 보일지를 같이 설계해야 한다. 가치를 경험한 직후, 그러니까 지금 이 기능을 계속 놓치지 않으려면 알림을 켜두는 게 좋겠다는 타이밍이 되었을 때 기본값 제안이 힘을 갖는다.

<출처: 작가>

4) 현재 편향과 지연된 보상

사람은 먼 미래의 이득보다 지금 당장의 귀찮음을 더 크게 느낀다. 매일 쓸 것 같다는 발화가 무너지는 이유는, 사용 가치가 늦게 도착할수록 현재의 마찰이 승리하기 때문이다. 예를 들어, 가계부 앱에서 사용자들이 예산 기능이 있으면 매일 쓸 것 같다고 말하지만 실제로는 며칠 만에 이탈하는 경우가 많다.

이유는 예산 기능이 나에게 도움이 되려면 먼저 카테고리를 설정하고, 월 예산을 입력하고, 결제 내역을 정리하고, 일주일 이상 써봐야 의미가 생기기 때문이다. 보상은 늦게 오는데, 입력은 지금 당장 해야 한다. 그래서 현재 편향이 작동하면 사용자는 단기 피로에 져서 떠난다. 이때 UX가 할 일은 사용자에게 더 성실해지라고 말하는 게 아니라, 첫 보상을 앞당기는 것이다. 예산을 직접 입력시키는 대신, 최근 지출을 기반으로 추천 예산을 만들어 주고, 오늘 한 번만 확인해도 바로 보이는 작은 인사이트를 주고, 입력을 미뤄도 괜찮게 만드는 흐름을 제공하면, 보상이 앞당겨지고 이탈이 줄어든다.

<출처: 작가>

5) 프레이밍과 손실회피

사람은 같은 사실이라도 표현 방식에 따라 다르게 판단하고, 이득보다 손실을 더 크게 느낀다. 쇼핑에서 가격이 중요하다고 말하면서도 더 비싼 브랜드를 선택하는 건 감성의 문제가 아니라, 실패할까 봐 두려워 손실을 피하려는 의사결정 구조일 수 있다. 예를 들어, 동일한 제품이라도 리뷰 수가 많고, 반품이 쉬워 보이고, 배송이 확실해 보이면 사용자는 더 비싼 선택을 한다. 그건 더 좋은 제품을 사고 싶어서라기보다, 잘못 사서 후회하고 시간과 돈을 잃는 상황을 피하고 싶어서다. 그래서 가격 비교 UX만 강화하면 해결되지 않는다.

오히려 손실회피가 강한 사용자에게는 환불 정책, 품질 보증, 실사용 후기, 비교 표 같은 정보가 결제 전 불안을 줄여준다. 여기서 프레이밍은 문구만의 문제가 아니다. 같은 정책이라도 무료 반품이라고 보여주는 것과 7일 이내 반품 가능이라고 보여주는 것은 사용자에게 전혀 다른 안정감을 준다. 사용자는 이득보다 손실을 먼저 본다. 그래서 결제 단계에서는 싸게 사세요보다 망할 확률을 줄여드릴게요가 더 강력하게 작동할 때가 많다.

이 관점들은 공통적으로 한 가지를 말한다. 사용자의 말은 사용자가 되고 싶은 이상을 담고, 사용자의 행동은 마찰과 위험과 기본값에 반응한 결과를 담는다. 그래서 UX 리서치의 목표는 유저의 발화를 믿거나 무시하는 게 아니라, 발화를 가설로 만들고 행동으로 검증하는 구조를 설계하는 데 있다.

<출처: 작가>

말과 행동을 연결하는 테크니컬 루틴: 가설화 → 계측 → 교차검증 → 실험

말과 행동이 다르다는 걸 안다고 해서 제품이 좋아지진 않는다. 실무에서 중요한 건 그 간극을 반복 가능하게 다루는 루틴이다. 이 루틴은 리서치라기보다 분석 설계와 실험 설계에 가깝다.

첫 단계는 발화를 가설 문장으로 번역하는 것이다.

<출처: 작가>

사용자의 말 자체는 요구사항이 아니라 의견이고, UX에서 의견은 검증 전까지는 가설이다. 예를 들면, 알림이 필요하다는 발화는 이렇게 바꿀 수 있다. 특정 이벤트가 발생했을 때 알림을 받으면 사용자는 더 빠르게 재방문하거나, 실수를 줄이거나, 중요한 행동을 완료할 확률이 높아질 수 있다. 여기서 핵심은 알림이라는 기능명이 아니라 이벤트, 맥락, 대상, 기대 효과를 넣는 것이다. 그래야 검증할 수 있다.

둘째 단계는 계측이다.

<출처: 작가>

행동 데이터는 자연 발생하지 않는다. 이벤트가 정의돼 있지 않으면 관찰할 수도 없다. 최소한 기능의 채택과 유지와 성과를 측정할 이벤트가 필요하다. 알림이라면 알림 켬/끔, 어떤 알림 유형을 선택했는지, 알림을 받은 뒤 어떤 화면으로 유입됐는지, 알림을 끄기까지 걸린 시간 같은 속성이 붙어야 한다. 검색이라면 검색 실행, 검색 결과 클릭, 결과 없음, 검색 후 구매/저장 같은 후속 행동이 이어져야 한다. 즐겨찾기라면 저장, 저장 목록 재방문, 저장 삭제가 이어져야 한다. 이 정도가 되어야 말과 행동을 같은 좌표 위에 올려놓을 수 있다.

셋째 단계는 교차검증이다.

<출처: 작가>

여기서 실무자가 자주 실수하는 지점이 하나 있다. 기능 사용률 하나만 보고 결론을 내리는 것이다. 하지만 말과 행동 불일치는 보통 한 지표로 설명되지 않는다. 그래서 채택률, 습관화, 임팩트로 분해해서 봐야 한다. 채택률은 한 번이라도 켰거나 써본 비율이고, 습관화는 반복 사용하거나 유지한 비율이고, 임팩트는 실제 목표 지표에 영향을 줬는지다. 알림을 켠 사람은 적지만 켠 사람의 유지율과 재방문이 높다면, 알림이 필요 없는 게 아니라 알림을 켜게 만드는 UX가 실패한 것이다. 반대로 채택은 높지만 해제도 빠르고 불만도 많다면, 알림 콘텐츠 품질과 빈도, 통제권 설계가 실패한 것이다. 같은 현상이라도 처방이 완전히 달라진다.

넷째 단계는 실험이다.

<출처: 작가>

관찰은 상관관계를 보여주고, 인터뷰는 해석을 제공한다. 인과가 필요하면 실험이 가장 빠르다. 실험은 꼭 거창할 필요가 없다. 권한 요청 타이밍을 첫 가치 경험 이후로 미루기, 기본값을 바꾸기, 알림 빈도 선택을 제공하기, 알림 유형을 좁히기 같은 작은 변화로도 충분하다. 중요한 건 무엇이 가치이고 무엇이 마찰인지 가설을 분리해 실험으로 확인하는 것이다. UX는 결국 기능을 늘리는 일이 아니라, 행동이 일어나는 조건을 설계하는 일이다.

사례를 다시 읽는 방식: 말이 아니라 구조를 본다

<출처: 작가>

사용자가 추천이 지겹다고 말하면서 익숙한 영상을 반복 클릭하는 사례는 흔하다. 이건 사용자가 모순적이라서라기보다 탐색과 안정 사이의 균형 문제다. 새로운 걸 보고 싶다는 말은 욕망이고, 실패 비용을 피하려는 행동은 손실 회피다. 그래서 추천 UX에서 중요한 건 새로움을 강요하는 게 아니라, 안전하게 탐색할 수 있게 만드는 장치다. 예를 들면, 새로움의 강도를 조절하거나, 익숙한 것과 새로운 것을 적절히 섞어 주거나, 새로움을 선택 가능한 옵션으로 제공하는 방식이 된다.

알림 사례도 마찬가지다. 알림이 필요하다는 응답이 높고 실제 설정은 낮다면, 이건 태도의 문제가 아니라 기본값과 마찰의 문제일 가능성이 크다. 어떤 알림이 오는지 불명확하면 사용자는 신뢰를 잃고, 통제권이 없으면 피로를 느끼고, 권한 요청이 너무 이르면 아직 가치도 모르는 데 부담만 느낀다. 알림은 기능이라기보다 관계 설계에 가깝다. 무엇을 언제 어떤 톤으로 어느 빈도로 보낼지, 그리고 사용자가 언제든 쉽게 조절할 수 있게 할지의 문제다.

검색이 편하다고 말하면서도 실제로는 즐겨찾기를 더 쓰는 패턴도 자주 나온다. 이때 검색이 나쁘다는 결론은 위험하다. 검색은 탐색이고, 즐겨찾기는 반복 사용을 위한 캐시다. 사람은 매번 질문하는 것보다 한 번 저장하고 다시 쓰는 걸 좋아한다. 그래서 UX는 검색을 더 빠르게 만드는 것만이 아니라 저장과 재방문을 자연스럽게 연결하는 흐름을 설계해야 한다. 말은 검색이 편하다고 하지만, 행동은 반복을 더 선호한다는 사실을 보여준다.

쇼핑에서 가격이 중요하다고 말하면서도 더 비싼 브랜드를 선택하는 건 합리 vs 감성 싸움이 아니다. 불확실성을 줄이는 신호가 더 강하게 작동한 결과일 수 있다. 리뷰 평점, 후기 사진, 브랜드 신뢰도, 반품 정책, 배송 안정성은 손실을 줄여주는 정보다. 그래서 가격 중심 UX로만 몰고 가면, 오히려 결제 단계에서 사용자의 진짜 불안을 놓치게 된다. 이 영역에서 UX가 해야 하는 일은 가격을 설득하는 게 아니라 실패할까 봐 두려운 마음을 줄이는 것이다.

사용자는 거짓말을 한다, 그래서 UX는 더 정교해질 수 있다

<출처: 작가>

사용자는 거짓말한다. 하지만 그건 악의가 아니라 인간의 기본값에 가깝다. 사람은 이상적인 자신을 말로 만들고, 현실의 자신을 행동으로 만든다. 그래서 리서치에서 중요한 건 유저가 틀렸다고 선언하는 게 아니라, 말과 행동 사이의 간극을 전제로 설계를 시작하는 것이다. 발화는 단서이고, 행동은 증거다. 단서를 가설로 만들고, 계측으로 관찰하고, 교차검증으로 해석하고, 실험으로 인과를 확인하는 과정이 쌓이면, 유저의 말은 더 이상 위험한 소음이 아니라 제품을 정교하게 만드는 힌트가 된다.

UX 리서치는 탐정의 일과 닮아 있다. 증언만 믿지 않고, CCTV만 맹신하지도 않는다. 증언과 CCTV를 같은 사건의 다른 시점으로 보고, 그 사이의 간극을 메우는 방식으로 진실에 가까워진다. 유저는 거짓말한다는 사실을 인정하는 순간, 디자이너는 유저와 싸우는 사람이 아니라, 인간의 본성을 전제로 더 안전하고 덜 피곤한 행동 경로를 만드는 사람이 된다. 그게 결국 더 좋은 디자인으로 가는 가장 현실적인 길이다.

]]>

PM은 이미 끝났다? 제품 관리의 현실

본문은 요즘 IT와 번역가 Yuna가 함께한 조 스마일리(Joe Smiley)의 글 <The Death of Product Management>를 번역한 글입니다. 필자는 25년 경력의 디자인 리더이자 다섯 차례의 창업 경험을 보유한 전략가입니다. Microsoft, Marriott 등 글로벌 기업에서 디자인 시스템과 조직을 이끌었으며, 디자인과 기술, 조직 운영에 대한 경험을 바탕으로 다양한 관점을 제시하고 있습니다.

이 글은 PM 역할이 왜 무너지는지를 조직 구조와 리더십 관점에서 살펴봅니다. 역할 모호성, 권한 없는 책임, 가짜 애자일 등 반복되는 문제를 짚으며, 많은 대기업에서 제품 관리가 이름만 남게 된 이유를 설명합니다. 동시에 제품 관리가 다시 제 역할을 하기 위해 조직이 바꿔야 할 지점도 함께 제시합니다.

필자에게 허락을 받고 번역했으며, 글에 포함된 링크는 원문에 따라 표시했습니다.

PM이라는 역할은 최근 몇 년 사이 확실히 주목받기 시작했습니다. 많은 기업들이 애자일 방식을 도입했고, 더 빠르게 혁신하고 높아진 고객 기대에 맞춰가려는 움직임이 이어졌기 때문입니다. 기술 변화의 속도까지 빨라지면서 제품 관리는 점점 복잡해졌는데요. 그럴수록 오히려 그 중요성은 더 커졌습니다. 이제 제품 관리는 제품의 성패를 좌우하는 핵심 역할로 자리 잡고 있죠.

그렇다면 정말 제품 관리는 사라지고 있는 걸까요? 아니면 조직들이 따라가지 못하는 사이, 역할의 형태만 바뀌고 있는 걸까요?

본격적으로 이 이야기를 꺼내기 전에, 먼저 왜 제품 관리가 그토록 중요한 기능으로 여겨지는지부터 짚어볼 필요가 있습니다.

PM은 어떤 역할을 하는가

PM의 역할과 책임은 회사마다 다르게 정의됩니다. 그럼에도 본질은 크게 다르지 않습니다. 제품 관리란 결국, 제품의 방향을 잡고 개발부터 출시, 성장까지 전 과정을 전략적으로 이끄는 일이기 때문입니다.

PM은 비즈니스, 기술, UX·디자인이 맞닿는 지점에서 일합니다. 그리고 제품과 관련해 이런 질문들에 끊임없이 답해야 하죠.

우리 고객이 이 기능이나 제품을 실제로 원하고 있는가?
이걸 우리가 제대로 만들어낼 수 있는가?
지금 우리의 비즈니스 목표를 봤을 때, 만드는 게 맞는 선택인가?

PM 조직이 제대로 돌아가면 혁신은 방향을 잃지 않습니다. 비즈니스 전략과 사용자 니즈 사이의 균형을 유지하면서, 제품이 장기적으로 살아남을 수 있도록 버팁니다. 하지만 현실에서는 여러 구조적인 문제들이 PM을 조금씩 갉아먹고 있습니다.

PM을 가로막는 6가지 문제

제품 관리는 분명 전략적으로 중요한 기능입니다. 그런데도 많은 조직에서 PM은 본래 역할을 충분히 발휘하지 못하는 상황에 놓이고는 합니다. 여러 조직을 보면서 반복적으로 마주쳤던 문제들인데요. 이 역할의 뿌리를 흔드는 대표적인 사례들이기도 합니다. 물론 각각의 대응 방향도 존재합니다.

1. 역할이 흐릿한 조직

특히 애자일을 막 도입한 조직일수록 PM이 실제로 어떤 일을 해야 하는지 명확히 이해하지 못하는 경우가 많습니다. 그러다 보니 제품 방향을 이끌어야 할 PM이 어느새 일정 관리나 진행 상황 보고에 집중하는 프로젝트 매니저처럼 쓰이기도 하죠.

이렇게 되면 PM 본래의 가치는 조금씩 희석됩니다. 결국 제품 전략은 흩어지고, 팀 간의 방향성도 조금씩 어긋나게 됩니다.

어떻게 해결할까

조직 차원에서 PM이 어떤 역할인지 명확하게 정의해야 합니다. 특히 프로젝트 매니저나 비즈니스 애널리스트와 무엇이 다른지 선을 그어야 하죠. 리더십은 PM이 제품 관련 결정을 실질적으로 이끌 수 있는 권한을 갖도록 보장하면서, 동시에 여러 팀과 원활히 협업할 수 있는 환경을 만들어줘야 합니다.

2. 너무 많은 역할을 떠넘기는 구조

PM이 자주 겪는 또 다른 문제는 역할 과부하입니다. 리소스 제약을 겪는 조직, 특히 규모가 큰 곳일수록 이런 현상이 두드러지는데요. PM에게 스크럼 마스터나 PO 역할까지 함께 맡기는 경우가 적지 않습니다. 단기적으로는 버틸 수도 있습니다. 다른 역할을 채용하는 동안 몇 번의 스프린트 정도는 병행할 수 있겠죠. 하지만 이 상태가 길어지면 문제가 깊어집니다.

여러 역할을 동시에 떠맡은 PM은 결국 번아웃이 옵니다. 고객 문제와 비즈니스 과제를 깊이 고민해야 할 리더가 사라진 자리에서, 팀 전체의 집중력과 방향성도 함께 흔들리게 됩니다.

어떻게 해결할까

PM이 자신의 본래 역할에 온전히 집중할 수 있도록 조직을 설계해야 합니다. PM의 주의를 분산시키는 요소를 줄이는 것, 이것이 결국 PM이 만들어낼 수 있는 가치와 성과를 끌어올리는 가장 현실적인 방법입니다.

3. 책임은 산만큼, 권한은 손톱만큼

많은 조직에서 PM은 제품 성공에 대한 막중한 책임을 지면서도, 정작 중요한 결정을 내릴 권한은 충분히 갖지 못하는 경우가 많습니다. 매트릭스 구조의 조직에서는 더욱 그렇습니다. 여러 기능 조직의 구성원들이 서로 다른 리더에게 보고하는 환경에서는, 이 모순이 훨씬 선명하게 드러나죠.

실제로 경영진이 데이터가 아닌 단편적인 인상이나 직감을 근거로 우선순위를 뒤집거나, 특정 이벤트나 대형 출시를 앞두고 세부 실행까지 직접 챙기려 드는 경우가 있죠. 팀을 돕겠다는 의도일 수 있지만, 결과적으로는 의사결정 구조를 흔들고 PM의 설 자리를 좁히는 방향으로 작용합니다.

속도를 높이겠다며 검증되지 않은 인력을 팀에 갑자기 추가하는 경우도 있습니다. 애자일 경험이 부족하거나 제품과 사용자에 대한 이해가 얕은 사람이 합류하면, PM 입장에서는 오히려 이들을 팀에 녹여내는 데 더 많은 에너지를 써야 합니다. 마이크로매니징이 반복될수록 팀의 사기는 떨어지고, PM 스스로도 판단하고 방향을 잡기보다 리더십의 눈치를 보는 데 익숙해집니다.

어떻게 해결할까

PM이 제품 팀 안에서 충분한 결정권을 가질 수 있어야 합니다. 리더십은 PM이 팀을 이끌고 방향을 잡는 역할을 신뢰해야 하고, 즉흥적인 지시나 과도한 개입으로 그 역할을 흔들어서는 안 됩니다. 리더는 지금 팀이 하는 일에 깊이 끼어들기보다, 최소 한 분기 앞을 내다보는 비즈니스 전략과 제품 방향을 준비하는 데 더 많은 시간을 쓰는 것이 바람직합니다.

4. 경영진이 애자일을 껍데기로만 받아들일 때

애자일 전환을 거치고도 여전히 예전 방식대로 생각하는 경영진을 자주 마주칩니다. 제품 전략 없이 결정을 내리고, 경직된 프로젝트 계획을 고집하고요.사용자 리서치 없이 우선순위를 일방적으로 정하거나, 스프린트 도중 갑자기 방향을 틀어버리는 일도 반복됩니다.

이런 환경에서는 이름만 애자일인, 이른바 '가짜 애자일' 이 자라납니다.

경영진이 애자일을 단순한 체크리스트 정도로 받아들이는 경우가 많습니다. 방법론은 도입하되, 그 안에 담긴 문화적 변화는 외면하는 거죠. 그 결과 협업과 유연함이라는 애자일의 본질은 사라지고, 형식만 남은 껍데기 애자일이 자리를 잡습니다.

이렇게 되면 PM과 팀원들의 피로와 불만은 쌓여가고, 애자일이 줄 수 있는 진짜 가치는 끝내 손에 닿지 못합니다.

어떻게 해결할까

가짜 애자일의 가장 큰 문제는 가치관의 불일치에서 시작됩니다. PM과 애자일 코치가 이 간극을 줄이기 위해 보다 적극적으로 나서야 합니다.

경영진을 대상으로 리더십 중심의 애자일 교육을 제공해야 합니다. 제품 팀이 자율성과 신뢰를 바탕으로 스스로 좋은 결정을 내릴 수 있다는 것, 그리고 그것이 비즈니스 목표와 어떻게 연결되는지를 이해시켜야 합니다.
경영진이 제품 팀 및 고객 피드백과 지속적으로 접점을 가질 수 있도록 유도해야 합니다.
조금씩 고쳐가며 만드는 방식이 실제로 더 나은 결과로 이어진다는 점을 데이터로 직접 보여주는 노력도 필요합니다.

5. 기술 스펙에 집착할 때 놓치는 것들

많은 조직에서 아직도 PM은 기술적으로 뛰어나야 한다는 인식이 강합니다. 물론 산업이나 환경에 따라 기술 이해도가 중요한 경우도 있습니다. 하지만 기술 역량만 지나치게 강조하다 보면, 훌륭한 제품을 만드는 데 정작 필요한 것들이 뒷전으로 밀립니다. 창의성, 비즈니스 감각, 사용자 리서치가 바로 그것들입니다.

물론 PM이 기술을 전혀 몰라도 된다는 뜻은 아닙니다. 회사나 산업에 따라서는 기술에 능한 PM이 성공의 핵심이 되기도 하는데요, 특히 복잡한 엔지니어링 문제를 다뤄야 하는 환경에서는 더욱 그렇습니다.

어떻게 해결할까

제품의 성격에 맞게 PM에게 필요한 역량을 다르게 정의하는 것입니다. 모든 PM을 하나의 틀에 끼워 맞추기보다, 제품마다 요구되는 것이 다르다는 걸 조직이 먼저 인정해야 합니다.

어떤 제품은 깊은 기술 이해도가 필수적입니다. (예: AI, 클라우드 인프라 등)
반대로 다른 제품은 UX 감각, 창의성, 시장 이해도가 더 강력한 무기가 됩니다. (예: 소비자 서비스, 미디어 플랫폼 등)
어떤 제품이든, 사용자 리서치·전략적 사고·비즈니스 인사이트를 아우르는 균형 잡힌 역량이 장기적인 성패를 가릅니다.

6. 다른 조직이 제품 방향을 좌우할 때

이상적인 구조에서 PM은 고객 니즈, 비즈니스 목표, 시장 맥락을 기반으로 제품 로드맵을 이끌어야 합니다. 하지만 일부 조직에서는 세일즈, 마케팅 등 다른 이해관계자들이 핵심 제품 의사결정을 사실상 주도하는 상황이 발생합니다. 문제는 이런 결정들이 충분한 사용자 리서치나 전략적 판단 없이 이루어지는 경우가 많다는 점입니다.

이렇게 되면 우선순위 충돌은 자연스럽게 나타납니다. 단기적인 매출 목표가 제품의 장기적인 방향성을 압도하거나, 사용자 가치보다는 기술적 제약이 로드맵을 좌우하는 구조가 만들어지기도 합니다.

어떻게 해결할까

제품에 대한 전략적 리더로서 PM의 역할을 조직이 확실하게 뒷받침하는 것입니다.

직무 간 협업은 장려하되, PM의 오너십이 침해받지 않는 환경이 함께 갖춰져야 합니다.
주요 제품 결정은 반드시 고객 데이터, 사용성 검증, 비즈니스 전략을 토대로 이루어져야 합니다.
고객 가치와 충돌하는 결정에 대해서는 PM이 근거를 갖고 이견을 낼 수 있는 권한과 분위기가 보장되어야 합니다.

그래서 제품 관리는 이미 끝난 걸까요?

안타깝지만, 솔직히 말하면 그렇습니다. 많은 대기업에서 제품 관리는 이미 오래전에 사실상 죽었습니다.

그 원인은 복잡하지 않습니다. 앞에서 짚은 문제들을 리더십이 제때 알아채지 못했거나, 알면서도 외면했기 때문입니다. 더 씁쓸한 건, 상당수 조직이 애초에 문제 자체를 감지하지 못하고 있다는 점입니다.

오랜 시간 쌓아온 고객 기반과 브랜드 충성도가 방파제 역할을 해줬기 때문입니다. 제품 완성도가 다소 떨어져도 고객이 계속 돌아오는 구조가 만들어진 거죠. 하지만 긍정적인 움직임도 분명히 있습니다. 많은 스타트업들은 제품 관리를 훨씬 건강하게 받아들이고 있습니다. 애자일, 린 방법론과 함께 제품 중심의 사고방식을 실제로 살아내고 있죠. 이런 조직들이 지금 기술 산업 전반의 혁신을 가장 많이 만들어내고 있습니다.

마치며

대기업의 제품 리더들에게 꼭 하고 싶은 말이 있습니다. 지금이 바로 제품을 만드는 방식을 다시 들여다봐야 할 시점입니다. PM을 조직의 변두리로 밀어내는 선택은 단순히 인재를 낭비하는 문제가 아닙니다. 혁신의 싹을 자르고, 제품을 그저 그런 수준에 머물게 만드는 일입니다.

대규모 조직에서 제품 관리가 다시 살아나려면 아래 조건들이 필요합니다.

PM의 역할을 명확히 정의하고, 프로젝트·프로그램 관리와 선을 긋는다.
PM이 본래 역할에 집중할 수 있도록 보장해야 하며, 역할 분산은 최소화한다.
팀을 제대로 이끌 수 있는 실질적인 결정권을 준다.
경영진의 사고방식을 애자일에 맞게 바꿔나가야 합니다.
제품 특성에 맞게 기술·창의성·비즈니스 역량의 균형을 고려한다.
제품 전략의 중심에는 언제나 PM이 있어야 한다.

이 조건들이 갖춰질 때, 제품 관리는 다시 혁신과 성과를 이끄는 기능으로 작동할 수 있습니다. 개인적으로는 리더십에게 ‘20가지 제품 모델 원칙’을 자주 권합니다. PM 역할을 설계하고 발전시키는 데 유용한 기준점이 되기 때문입니다. 이를 제대로 이해하고 적용하는 조직은 단순히 생존하는 수준을 넘어, 더 나은 제품과 더 강한 고객 관계로 경쟁 우위를 확보하게 됩니다.

마지막으로, 현실의 제약 속에서 일하고 있는 PM들에게 전하고 싶은 메시지가 있습니다. 자신의 역할에 대한 명확성을 끊임없이 요구하세요. 전략적 제품 관리가 왜 중요한지 주변에 설명하고, 데이터를 근거로 결정에 영향력을 행사하세요.

개인적으로 저는 제품 관리의 미래가 스타트업에 있다고 믿습니다. 스타트업들은 이미 판을 뒤집고 있습니다. AI라는 무한한 가능성 위에서, 거침없는 PM들이 자율성을 무기로 자신만의 세계를 만들어가고 있죠.

제품 혁명은 이미 시작됐습니다. 지금 당신의 조직은 PM이 앞장설 수 있도록 힘을 실어주고 있나요, 아니면 조용히 무덤을 파고 있나요?

]]>

기획자가 직접 99개의 서비스를 만들며 배운 것들

기획자가 개발자 없이 직접 99개의 서비스를 만들며 배운 인사이트

기획안으로 설득하는 데 2주가 걸리고, 수십 번 임원 리뷰를 받았던 일이 동작하는 결과물을 보여주자 30분 만에 끝났다. AI 코딩 시대에 기획자의 무기는 문서가 아니라 실행이다. 지난 4개월간 99개의 서비스를 만들며 깨달은 '검증의 기술'을 공유하고자 한다.

나는 사실 코딩 공포증이 있었다. 학교 다닐 때 c언어 과목 학점은 늘 C였다. 코딩을 싫어하고 재미도 못 느꼈다. 학교 다닐 때 코딩 중간고사는 구구단을 짜봐라 이런 내용으로 어렴풋이 기억난다. 그럼 난 코드를 이해하는 대신 암기를 하며 또각또각 글자를 쓰곤 했다. 그렇지만 언제나 학점은 c였고 나는 코딩과 정말 안 맞는 사람이라고 스스로를 단정했다.

그러던 세상이 천지개벽했다. 말만 하면 알아서 코딩을 해주는 시대로 접어들고 있다. 기획자인 나는 AI를 통해 바이브 코딩을 접하고 나니 내 생각들이 실현되는 과정이 너무 재미있다. 좋은 점은 점점 코딩 공포증이 사라지고 있다는 점이다. 나의 두려움 대상이 아니라 내 생각을 실현해 줄 또 다른 도구로서 코딩을 바라보는 중이다.

바이브 코딩 시작은 주로 제미나이 빌더로 시작한다. <출처: 작가>

이 변화가 업무에 적용된 건 4개월 전이었다. 작년 11월 회사 업무로 챗봇 서비스를 만들어야 했다. 이미 개발팀에서 작업을 다 마친 뒤 임원 보고를 했지만 가시성이 떨어지고 강조할 부분이 잘 안 보이는 문제가 있었다. 곧 이미 개발된 작업물을 다시 나에게 수정하라는 지시사항이 내려왔고 기획자로서 고민이 되었다. 그냥 이미지로 수정해서 보여주느니 동작되는 걸 직접 보여줘야겠다고 생각했다. 그래서 뚝딱뚝딱 바이브 코딩을 배우게 되었고 직접 수정해 가져갔다.

반응은 솔직히 좀 놀랬다. "이렇게 바꿔보는 게 어떨까요?"라는 말이나 문서보다 "이렇게 동작해요."라고 보여주니 설득의 시간이 획기적으로 단축되었다. 서로 다른 상상을 하며 소모되던 논쟁이 사라졌다. 눈앞의 결과물을 보며 이야기하니 "왜 진작 처음부터 기획자를 안 붙였냐. 역시."라는 말이 나왔다. 그 경험 이후 나는 아이디어가 떠오를 때마다 반복해서 실현했고 지난 1월 말까지 총 99개의 서비스를 배포했다.

물론 99개가 거창한 사업 아이템은 아니다. 90%는 하루 만에 버려진 '일회용 검증 도구'였고 나머지는 나와 동료의 시간을 아껴주는 '마이크로 서비스'였다. 하지만 이 과정에서 얻은 것은 명확하다. 의사결정 비용이 '0'에 수렴한다는 것이다. 단 한 사람의 개발자 없이 복잡한 코드는 AI에게 맡기고, 오직 문제 해결에만 집중해 본 99번의 실험 기록을 남긴다.

욕심을 줄이면 핵심이 보인다

바이브 코딩을 처음 접했을 때 가장 많이 빠졌던 함정이 '기능 과잉'이었다. 개발 비용이 들지 않으니 머릿속에 생각나는 모든 것들을 다 넣고 싶어졌다. 나의 야심작 드림보드가 대표적인 실패 사례다. 나는 AI에게 작업 지시서를 내리듯 아주 구체적인 프롬프트를 입력했다.

[실제 입력한 프롬프트]
Role: 너는 세계적인 수준의 UX/UI 디자이너이자 프런트엔드 개발자야.
Goal: 나의 꿈과 목표를 시각적으로 관리하는 '드림보드' 웹서비스를 만들어줘.
Design Style: 노션처럼 깔끔하고 여백이 세련된 느낌. 딱딱한 표 대신 핀터레스트처럼 벽돌 쌓기 형태의 'Masonry Layout'을 사용해 줘.
Core Features: 우측 하단 '+' 플로팅 버튼으로 빠른 추가. 진행률이 100%가 되면 'Framer Motion'을 활용해 축하 폭죽 효과를 터뜨려줘. (이게 핵심이야, 도파민 트리거가 필요해!)
Tech Stack: React, Tailwind CSS, Supabase

<출처: 작가>

결과는 놀라웠다. 엔터를 누르고 얼마 지나지 않아 내 머릿속의 막연한 드림보드가 모니터 위에 짜잔하고 나타났다. 미니멀한 드림보드라니. 폭죽이 터지는 애니메이션까지 구현되었다. 문제는 그다음이었다. "어? 이걸 매일 쓰도록 하려면.... 감사 일기 같은 것도 넣어볼까?" 나는 즉시 감사 일기 탭을 추가하고 기능을 덧붙였다. 서비스는 금방 누더기가 되었다. 미니멀은 온데간데 사라지고 정보 구조는 꼬여버렸다. 무엇보다 서비스의 정체성이 흐려졌다. 화면을 보면서 느낀 점은 코딩 비용이 0이라고 해서 사용자가 겪어야 할 복잡함의 비용까지 0이 되는 건 아니구나라는 점이었다.

그 이후 방식을 아예 바꿨다. 아이디어가 생기면 기능을 덧붙이는 대신 새 서비스를 만드는 방향을 택했다. 그게 99개 다작의 비결이자 실패를 최소 비용으로 소화하는 방식이 되었다. 이후 바이브 코딩으로 만든 서비스는 '육아 검진 알리미'였다. 동료와 대화하며 우연히 포착한 불편함이었다.

<출처: 작가, https://mysuksuk.com/>

"또 놓쳤어요. 일일이 육아 건강검진 챙기기 너무 힘들지 않아요?"

엄마 기획자로서의 공감이 시작이었다. 육아 건강검진 서비스는 간단했다. 아기의 생년월일을 입력하면 자동으로 건강검진 날짜를 계산해 주는 것이다. 1차부터 9차 건강검진까지 자동으로 계산되면서 각 차수에 맞춰, 발달 정도를 스스로 체크할 수 있는 서비스였다. 욕심을 부리지 않고 딱 필요한 기능만 프롬프트로 입력하니 1시간도 안 돼서 서비스가 뚝딱 만들어졌다. 내친김에 배포까지 해서 남편에게 공유했다.

기존 프로세스였다면 기획안 쓰고, 디자인하고, 개발 일정 잡느라 며칠이 걸렸을 일이다. 하지만 '구현의 비용'이 0에 수렴하자 나는 '기능의 화려함'보다 '고객(나와 동료)의 결핍'을 해결하는 데에만 온전히 집중할 수 있었다. 실패해도 1시간만 버리면 된다는 가벼움이 오히려 실행력을 극대화했다.

기술이 막힐 때, 기획자는 '우회로'를 뚫는다

남편이 배포한 서비스를 이용하면서 '공유' 기능이 있으면 좋겠다는 피드백을 줬다. 내친김에 카카오톡 연동을 해보려고 했다. 하지만 외부 서비스 연동부터 쉽지 않았다. 카카오톡 연동을 위해서는 API 키를 받아야 하는데, 일단 키를 아무리 발급받아도 연동 테스트는 계속 오류가 발생했다. 비개발자인 내가 해결하기엔 기술적 장벽이 높았다. 복잡한 DB 설계나 대규모 트래픽 처리와 같은 기능 역시 바이브 코딩으로 한계가 있었다.

여기서 기획자의 판단이 중요했다. 이 서비스의 목적을 다시 한번 생각해 보았다. 남편이 원한 건 '카카오톡' 자체가 아니라 '알림을 받는 것'이었다. 나는 과감히 카카오톡을 포기하고 이메일 알림으로 우회했다.

전문 개발자였다면 어떻게든 API 키를 연동해 기술적인 문제점을 찾아냈을 것이다. 그건 개발자만이 할 수 있는 전문적인 능력이다. 하지만 비개발자인 나는 그럴 능력이 부족했다. 대신 '목적'을 다시 생각했다. 남편에게 중요한 건 '카카오톡'이 아니라 '알림' 그 자체였으니까. 나는 빠르게 기술적 씨름을 멈추고 구현이 쉬운 이메일 알림으로 경로를 틀었다. 이것이 내가 깨달은 AI 시대의 기획력이다. 코딩 실력이 부족했기에 역설적으로 기술에 매몰되지 않을 수 있었다. 기술적 장벽 앞에서 '어떻게 뚫을까'를 고민하는 대신, '이게 정말 필요한가?'를 질문하며 문제 자체를 재정의했기 때문이다. '카카오톡'이라는 도구에 얽매이지 않고 목적을 향한 가장 빠른 우회로를 찾아내는 감각이 점점 내가 키워야 할 무기이지 않을까라는 생각을 해보았다.

만드는 것은 쉽다, '누가 쓰는가'가 진짜 문제다

<출처: 작가, https://mysuksuk.info/>

바이브 코딩은 빠르게 테스트하기 위한 용도로 활용하면 매우 좋다. 나는 최근에 습관 트래커를 구현했다. 어렸을 때 잘하면 칭찬 스티커를 받아서 유지하듯 나 스스로 어떤 일을 하면 스티커를 모아가는 프로젝트로 기획했다. 바이브 코딩으로 서비스 배포까지는 수월했다.

무엇보다 나에게 매우 유용한 서비스였다. 회사에서 하는 대부분의 서비스가 최종 고객의 반응까지 알아보기가 어려운 구조였다. 하지만 바이브 코딩으로 만든 서비스들은 그냥 내가 만들고 배포하면 끝이라서 반응도 빨랐다. 문제는 서비스 자체는 적어도 나에게만큼은 유용했지만, 문제는 나만 쓰는 게 문제였다. 즉 알릴 길이 없었다. 내가 지인에게 배포해도 한계가 있었다.

나는 다시 기획을 수정했다. 단순히 습관을 기록하는 게 아니라 '글 쓰는 사람을 위한 습관 트래커'로 타깃을 좁히고 기능을 변경했다. 글 쓰는 사람에게 필요한 건 체크박스가 아니라 한 줄을 쓰게 만드는 동료 같은 반응이라고 봤다. 그래서 AI에게 페르소나를 부여했다.

[변경 프롬프트]
타깃은 글감이 안 떠올라 괴로운 작가야. 사용자가 한 줄을 쓰고 저장을 누르면 너는 그 문맥을 읽고 동기부여를 해줘. 때로는 진지하게 때로는 아재 개그를 섞어서 웃게 만들어줘.

그 순간 서비스가 달라졌다. 단순한 텍스트 생성기가 아니라 썰렁한 농담으로 긴장을 풀어주는 '동료'가 생긴 것이다. 습관 생성기에 대한 기능은 AI가 만들지만, 서비스의 톤과 성격은 기획자가 잡아줘야 한다는 생각을 했다. 삭막한 습관 트래커에 '장난기 넘치는 페르소나'를 입히자, 비로소 코드는 단순한 프로그램을 넘어 사용자와 관계를 맺는 대상이 되었다. 사용자를 머물게 하는 건 뛰어난 기능이 아니라 바로 그 관계의 힘이었다.

실패 비용이 0이 될 때 얻을 수 있는 것

만약 내가 만든 여러 가지 서비스를 3개월 동안 거창하게 만들었다면? 아까워서라도 방향성을 우회하지 못했을 것이다. 하지만 바이브 코딩은 '실패 비용'을 확연히 낮춰주었다. 덕분에 나는 '만드는 방법'을 고민하는 대신, '누가 왜 써야 하는가'라는 기획의 본질적인 질문에 더 깊이 파고들게 되었다.

질문의 무게를 견디는 기획자 99개의 서비스를 만들며 배운 것은 코딩 기술이 아니었다. 기술 장벽이 사라진 시대, 기획자가 집중해야 할 것은 '구현 가능성'이 아니라 '해결해야 할 문제의 정의'라는 점이다. 문서로 설득하는 대신 결과물로 증명하고, 거창한 계획 대신 빠른 실패를 통해 정답을 찾아가는 과정. AI 시대의 기획자는 책상 위가 아니라, 동작하는 서비스 위에서 답을 찾아야 한다. 우리가 던지는 질문의 깊이가 곧 서비스의 깊이가 될 테니까.

C언어 중간고사 시험을 볼 때면 하얀 종이 한편에 코드 대신 편지를 썼다. '공부를 소홀히 해서 죄송합니다 교수님...'이라며 멘트를 썼던 기억이 난다. C언어 학점이 C가 되어 집으로 돌아오면 아빠는 나를 불러 "장학생은 기대도 안 하는데 C는 너무하지 않냐?"라며 하셨던 말씀도 생각난다. 내가 그 시기 힘든 점은 단순히 C 학점이 아니라, 동기들은 재미있는 뭔가를 다 구현하는데 나 혼자 아무것도 하지 못하는 무력감이었다.

세월이 흘러 바이브 코딩이 되면서 C언어를 못 하던 나도 뭔가를 실현할 수 있게 되었다. 그것도 마음껏 원하는 대로 실현할 수 있다는 감각이 생겼다. 누군가는 묻는다. AI가 코드도 짜고 아이디어도 내는데, 이제 기획자는 필요 없는 거 아니냐고. 냉소적인 질문 앞에서 나는 99번 바이브 코딩을 통해 서비스를 구현한 경험을 담아 단호하게 '아니요'라고 답하고 싶다.

AI는 효율적인 코드를 짤 수는 있어도 카카오톡 연동을 과감히 빼거나, 아재개그 같은 피드백을 넣어 서비스의 온도를 조정하는 결정을 하진 못했을 거다. 기술적 논리로는 설명되지 않는 판단과 온기는 여전히 기획자만이 불어넣을 수 있는 영혼이다.

모든 것이 빠르고 실현 가능한 시대다. 마음껏 실현하는 시대일수록 흔들리지 않는 중심을 가진 기획자가 더 특별해진다. 기술의 파도에 휩쓸리지 않고 깊은 생각으로 서비스의 가장 중요한 핵심을 끝까지 밀어붙이는 힘이 중요해진다. 나는 여전히 흔들리지 않는 기획자가 되기 위해 답을 찾아 나가는 중이다. 이때 무기는 코드 몇 줄이 아니라 생각의 깊이면 좋겠다. 그 무기를 갈고 닦는 나의 여정은 99개의 서비스를 지나 이제 막 시작되었다.

]]>

기획자, Supabase로 백엔드 구현까지 해봤습니다

지난 글 “기획자, 안티그래비티(Antigravity) 이렇게 써봤습니다“에서는 안티그래비티를 이용해 인플루언서 검색 앱을 만드는 경험을 공유했다. 해당 앱은 CSV 정적파일을 기반으로 만들었기에 한계점이 분명히 존재했는데, 사용자가 직접 글을 쓰고 서로 ‘좋아요’를 누르는 상호작용을 하려면 살아있는 동적 DB가 필요했다.

그래서 이번에는 대표적인 바이브 코딩 툴인 커서 AI와 슈퍼베이스를 연결해 커뮤니티 앱을 만들어 보았다. 슈퍼베이스(Supabase)는 DB를 직접 구축하지 않고도, 간단한 키 연결만으로 사용할 수 있는 BaaS(Backend as a Service) 형태의 서비스다. 엑셀처럼 쉬운 DB 관리와 회원가입/로그인 기능을 설정 하나만으로 구현할 수 있어서 개인적으로 매우 만족스러웠다.

이번 글에서는 기획자가 바이브 코딩과 슈퍼베이스로 관계형 데이터베이스(RDBMS) 구조를 적용해 만든 인플루언서 커뮤니티 앱 ‘공구 블라인드’의 구현 과정을 함께 살펴보고자 한다.

<출처: 작가>

커서로 인플루언서 커뮤니티 앱 설계하기

우선 이 앱을 만들게 된 계기에 대해 간단히 설명하고자 한다. 현재 인스타그램 공구 시장은 복불복이다. 기대와 다르게 성과가 나기도 하고, 때로는 기대에 미치지 못하기도 한다. 이러한 시장에 인플루언서들이 솔직하게 정보를 나눌 수 있는 커뮤니티가 있다면, 공동구매 진행 정보와 함께 최적의 벤더 및 상품을 매칭할 수 있는 서비스를 만들 수 있지 않을까?라는 생각이 들었다.

그래서 MVP를 ‘공구 블라인드’로 정하고, 빠르게 시장 반응을 살펴보기로 했다. 이를 구현하기 위해 복잡한 설정 없이도 하루 만에 웹 서비스를 구현할 수 있는 스벨트(Svelte)를 만들고, PRD 및 기술 스택을 작성했다.

1) 커서에 스벨트 프로젝트 생성

우선 커서를 다운로드 후 로그인 및 node.js, git 설치까지 완료한다. 그다음 효율적인 프로젝트 초기 설정을 위해 스벨트 프로젝트를 만든다. 공구 블라인드의 경우 가볍고 빠른 웹 서비스이기에 스벨트를 선택했으나, 모바일 앱을 구축할 때는 플러터(Flutter)를 이용하는 것을 권장한다. 이처럼 프로젝트 목적에 따라 선택 사용하면 된다.

스벨트 프로젝트 생성을 위해 Git bash 터미널 창에 아래와 같이 입력 및 선택하여 진행했다.

npx sv create 
└─ Project name: Gonggu Blind 
└─ Template: SvelteKit minimal
└─ Add type checking: Yes, using TypeScript syntax 
└─ What would you like to add?: Tailwind CSS, ESLint, Prettier, Vitest, Sveltekt-Adapter 
└─ Which package manager?: npm

스벨트 프로젝트를 생성되면 Open Project를 열어 프로젝트(예: Gonggu Blind) 폴더를 선택한다. 그리고 Git bash 터미널 창에 npm run dev를 입력한 후 Local host 주소를 선택하면 브라우저가 뜬다.

2) PRD 및 기술 스택 작성으로 오류 최소화

여러 번 테스트해 본 결과 확실히 명확한 작업 지시서가 있으면 오류가 덜 발생한다. 따라서 기획, PRD, 기술 스택 작성은 제미나이로 만든 후, 커서에 *.md 파일을 저장해 놓는다. 그다음 에이전트에게 인플루언서 익명 커뮤니티인 ‘공구 블라인드’ 앱을 PRD와 기술 스택을 참고해서 만들어 달라고 했다.

PRD와 기술 스텍 작성 후 *md 파일로 저장 <출처: 작가>

3) 프롬프트로 공구 블라인드 앱 만들기

공구 블라인드의 주요 기능인 리얼톡과 AI 데이터 소싱 공구 인사이트를 구현하기 위해 프롬프트를 단계별로 입력했다. 바이브 코딩에서는 의도한 결과가 나올 때까지 프롬프트로 여러 번 구체적으로 지시하는 과정이 필요하다.

커서를 이용하면서 좋았던 점은 “필터 클릭 시 실제로 리스트가 필터링되도록 동작까지 붙일까?”와 같이 관련 기능을 추가로 제안해 준다는 것이었다. 그리고 맘에 들지 않을 때는 언제든지 쉽게 원복이 가능하다는 점에서도 편리했다. 다만 바이브 코딩할 땐 상식적으로 구현되어야 하는 동작 하나까지도 아래와 같이 일일이 프롬프트를 작성해야 해서 번거롭긴 했다.

프롬프트: AI 분석기 메뉴에 커서가 갔을 때 클릭커블한 어포던스를 줄 수 있도록 손가락 모양으로 변경해 주고, 검색창에 브랜드 또는 상품명을 입력하지 않고 해당 버튼을 선택하면 입력 안내 창을 띄워줘.

커서에서 프롬프트로 앱을 구현 <출처: 작가>

Supabase로 DB 연동하기

슈퍼베이스 연동 전 필수는 Github 원격 저장소에 커서로 작성한 코드를 안전하게 저장하는 것이다. 내 컴퓨터에 있는 코드를 Github에 옮겨서 사용하면, 러버블처럼 다른 바이브코딩 툴로 작업한 것도 커서에서 불러와 추가 작업을 할 수 있다. 슈퍼베이스는 프로젝트 두 개까지는 무료여서 MVP를 만드는 데는 충분했고, 커서에서 DB 스키마를 만든 후 슈퍼베이스의 SQL 에디터를 활용해 DB 테이블을 완성했다.

1) Github에 에러 없이 한 번에 연결한 후 슈퍼베이스 연동 설정

커서에서 배포하기 위해 준비하고 URL을 알려달라고 하면, 알아서 Github에 업데이트하고 Vercel에 배포해 준다. 물론 초기 세팅은 필요했지만, 기획자 입장에서는 매번 수정된 코드를 Github에 업데이트할 때마다 명령문을 굳이 기억하지도, 입력하지도 않아도 된다는 점이 편리했다.

먼저 Github가입 로그인 후 신규 레퍼지토리를 생성한 후에 SSH 주소를 복사한다. 그리고 커서 커맨드 라인에 아래 순서대로 입력하여 저장소를 초기화하고, 원격 저장소에 저장한다.

git init: 내 컴퓨터에 깃 저장소 만들기 위한 초기화 작업
git remote add origin <git hub에서 복사한 SSH 주소 붙여넣기>: SSH 깃허브 주소 등록 또는
git remote set-url origin <git hub에서 복사한 HTTPS 주소 붙여넣기>: HTTPS 깃허브 주소 등록
git add: 변경된 모든 파일을 스테이징 하기
git commit -m "Init: 처음 커밋(확정) 할 땐 사용자 이름과 이름 설정 필요
git push -u origin main: 깃허브로 쏘아 올려 저장하기

이때 열쇠가 없으면 깃허브 문이 열리지 않아서 오류가 생길 수 있다. 방법은 HTTPS 주소를 이용하거나 Github와 SSH keys 연결 방식을 이용하는 것이다. 보안에 신경이 쓰인다면 SSH 키값을 복사한 후 연결해서 사용하는 방법을 권장한다. ssh-keygen을 커맨드 라인에 입력한 후 승인 권한을 위한 공개키를 생성한다. 그다음 cat <퍼블릭 키를 복사 붙여넣기>를 해서 ssh 키값 복사한 후, Github에 저장하여 연결하면 된다.

Github 연결 방법은 복사한 ssh 키값을 git hub → 사용자 프로필 → Settings → SSG and GOG keys → New SSH key → 컴퓨터 이름 입력과 복사한 키를 붙여넣기 → Add SSH key 저장하면 깃허브와 연결하면 된다.

그리고 슈퍼베이스 연동 설정을 위해서는슈퍼베이스 가입과 로그인을 한 후 DB 연동을 위해 접근할 수 있도록 Supabase 만든 주소와 키값을 복사하여 커서에서 환경변수에 저장하여 연결한다.

Project Settings → Data API 있는 URL과 → API Keys에 PUBLIC_Key를 복사한다. 복사한 두 개의 키값은 커서의 .env 환경 변수 파일에 입력한다.
SUPABASE_DB_URL = 복사한 URL 값
SUPABASE_DB_PUBLIC_Key = 복사한 키값

2) 회원 가입 및 로그인 기능 구현

보통 로그인 기능을 직접 구현하려면 보안, DB 설계, 세션 관리 등 챙겨야 할 게 많다. 하지만 슈퍼베이스에서는 회원 가입과 로그인 기능을 제공해서 쉽게 구현할 수 있었다. 슈퍼베이스에서 설정 버튼 하나와 커서의 프롬프트 한 줄로 회원 가입과 로그인 기능을 붙일 수 있었다.

먼저 슈퍼 페이스 대시보드에서 Authentication → Sign In / Providers 이동하면 Auth Providers에서 카카오톡, 구글, 디스코드 등 생각했던 것보다 다양한 인증을 제공한다. 원하는 소셜 로그인을 토글스위치 하나로 구현할 수 있다는 점에서 편리했다.

다음으로는 커서에서 회원 가입과 로그인 기능에 대한 고객 경험을 최대한 디테일하게 반영해서 구현해 달라고 했다. 만약 에러가 발생한다면 어떤 오류인지 확인한 후 에러를 수정해 달라고 하면 된다. 구현 과정은 아래 영상에서 볼 수 있다.

슈퍼베이스 회원 가입/로그인 기능 구현 및 커서에서 에러 수정 <출처: 작가>

추가로 로컬 호스트에서는 분명 문제없이 작동했는데, 배포한 후에 회원가입과 로그인이 안 되어서 확인해 보니 배포된 URL로 슈퍼베이스에서 Redirect URLs와 Emails STEMP 설정을 해야 했다. 에이전트가 안내하는 대로 세팅하고, STEMP는Brevo를 추천해 줘서 사용했다.

3) SQL 연동으로 게시글 작성 기능 구현

커서에서 슈퍼베이스 SQL 작성과 마이그레이션을 해주면 해당 코드를 복사한 후 슈퍼베이스 SQL Editor에 붙여 넣고 Run CTRL 버튼을 눌러 실행하면 된다. 커서에서 코드를 복사해서 슈퍼베이스에 옮겨놓는게 귀찮다면 커서의 Tools & Integrations 안에 New MCP Sever로 연결하면 테이블 생성이나 데이터 마이그레이션까지 자동으로 알아서 해준다.

특히 기획자 입장에서 간편하게 생성된 DB를 Database → Schema Visualizer에서 한눈에 파악할 수 있어서 좋았다. 각각의 UI 구성 요소들이 데이터 테이블과 어떻게 연결되는지 구조를 이해할 수 있어, 백엔드를 모르는 나에게는 큰 도움이 되었다.

사용자가 공구 블라인드에서 리얼 톡 내용을 작성하면 Supabase 대시보드 → Table Editor → real_talk_posts의 테이블에 새 행이 생긴다. 이렇게 사용자가 작성한 데이터가 실제로 채워지는 것을 실시간으로 보게 되는 순간이 가장 뿌듯했다.

인플루언서 검색 앱 테스트 및 리뷰 <출처: 작가>

마치며: HOW가 쉬워지면 WHY가 보인다

비즈니스의 진정한 가치는 단순한 기능의 나열이 아닌, 전반적인 고객 경험과 데이터가 유기적으로 결합할 때 비로소 빛을 발한다. 그동안 보안, 서버, SQL과 같은 백엔드 기술은 기획자에게는 넘지 못할 장벽과도 같았다. 이러한 관점에서 슈퍼베이스를 써보면서 느낀 점은 이제 백엔드의 장벽도 허물 수 있다는 것이다. 그동안은 머릿속으로만 상상했던 서비스를 쉽게 손에 잡히는 실체로 만들 수 있다. 또 다양한 AI 툴을 이용해 복잡한 데이터 구조를 이해하고 제어할 수 있게 되면서, 단순한 화면 설계서와 정책 정의서를 작성하는 차원을 넘어섰다. 앞으로 기획자는 정적인 아이디어를 동적인 프로덕트로 변화시키는 메이커로서 점점 더 진화할 것이다.

끝으로 기술 구현이 간편해진 지금, 여러 바이브 코딩 툴을 직접 사용해 보니 서비스의 본질에 더 깊이 집중할 수 있는 계기가 됐다. 앞으로도 AI 툴은 기획자 스스로가 '이 서비스가 왜 존재해야 하는지'를 증명하는 데 강력한 무기가 될 것이라 생각한다.

]]>

기획자, 안티그래비티(Antigravity) 이렇게 써봤습니다

요즘 실무에서 발생하는 대부분의 문제는 커뮤니케이션에서 비롯된다. 기획서가 디자인 시안으로, 개발자의 코드로 변환되는 과정에서 설득과 설명만으로는 100% 기획자의 의도를 전달하기 어렵기 때문이다.

그래서 최근 주목받고 있는 바이브 코딩(Vibe Coding) 툴을 이용해 아이디어를 현실화한다면 어떨까? 커뮤니케이션 생산성을 높이는 데 도움이 되지 않을까 생각했다. 커서(Cursor), 클로드 코드(Claude Code) 같은 도구들이 있지만, 이번 글에서는 구글 안티그래비티(Antigravity)를 활용해 직접 ‘인플루언서 검색 앱’을 만들어본 경험을 나눠보고자 한다.

물론 기획자가 바이브 코딩으로 만든 서비스가 전문 개발자의 아키텍처를 기반으로 한 결과물을 대체할 수는 없다고 생각한다. 대고객 서비스를 위해서는 여전히 엔지니어링의 정수가 필요하기 때문이다. 하지만 아이디어를 MVP(최소 기능 제품) 수준의 동작하는 프로토타입으로 증명해 내는 과정에서, 안티그래비티가 기획자에게 어떤 강력한 툴이 될 수 있는지에 대한 가능성은 분명하다. 오늘은 이에 관해 이야기해 보려 한다.

인플루언서 파인더 <출처: 작가>

미리 요점만 콕 집어보면?
기획자로서 구글 안티그래비티(Antigravity)라는 바이브 코딩 툴을 활용하여 '인플루언서 검색 앱'의 MVP를 직접 제작하고, 배포하는 데 성공했습니다.
AI 에이전트의 효율적인 작업을 위해 Node.js, Python 설치, Antigravity 권한 설정 등의 기초 환경 구축과 Planning, Fast 모드를 활용한 체계적인 설계 및 명확한 지시가 중요했습니다.
이 경험을 통해 기획자는 아이디어를 작동하는 프로토타입으로 증명하고, 구조화된 설계와 명확한 지시로 AI를 조율하는 '새로운 근육'을 얻어 기획의 언어가 바뀌어야 함을 강조합니다.

AI 에이전트와 협업하기 위한 기초 세팅

처음 MVP는 인플루언서 검색으로 시작했다. 목표는 공동구매 할 상품만 입력하면 알아서 잘 팔 수 있을 만한 적합한 인플루언서를 찾고, 자동으로 문구까지 작성해 DM 발송까지 가능하도록 만들고 싶었다.

MVP를 인플루언서 검색으로 정한 이유는 명확하다. 기존 인스타그램에서 검색만으로는 공동구매에 최적화된, 즉 상품을 잘 팔아줄 인플루언서를 찾기 어려웠기 때문이다. 그래서 가격대와 카테고리 상품 핏이 맞으면서도 콘텐츠가 활성화되어 있는 인플루언서를 쉽게 찾을 수 있게 직접 만들게 된 것이다.

처음엔 단순히 안티그래비티 채팅장에 “인플루언서를 검색하는 앱을 만들어줘”라고 한 줄만 입력하면, 뚝딱하고 앱이 만들어질 것이라 생각했다. 하지만 인스타그램을 크롤링하기 위해 Node.js와 Python 같은 추가 기능이 필요하다는 사실과 중간에 터미널 창까지 뜨는 바람에 조금 당황스러웠다.

그래서 기획자인 나에게 맞게 다시 설명을 요청하거나, 오류 메시지를 캡처해서 익숙한 제미나이, 챗GPT에 다시 물어보았다. 답변은 개발을 위한 실행 환경구축과 안티그래비티 초기 세팅이 필요하다는 것이었다. 대부분 기획자의 로컬 PC 환경은 문서를 작성하고, 디자이너와 개발자와 소통하는 데 최적화되어 있다. AI 에이전트가 실제 코드를 작성하고 수십 개의 파일을 넘나들며, 애플리케이션을 직접 구동할 수 있게끔 권한과 도구를 세팅하는 것이 우선이었다.

1) 안티그래비티 다운로드 및 설정

우선 안티그래비티를 설치 후 프로젝트 폴더를 생성한다. 그리고 워크스페이스를 설정해, 안티그래비티와 연결하여 AI 에이전트가 작업할 영역에 대해 지정한다.

추가로 오른쪽 상단에 있는 설정 아이콘 ⚙ Editor-Specific-Settings → Open antigravity user settings → Agent에 ARTIFACT 항목을 Agent Decides로 설정한다. 그리고 아래에FILE ACCESS 부분도 모두 활성화한다. 이는 코딩을 모르는 기획자의 경우엔 권한을 에이전트에게 주어, 마치 AI 에이전트가 스스로 알아서 일할 수 있도록 ‘책상’을 놔주는 것과 같은 효과를 발휘한다.

2) 실행 환경 구축(Runtime & 도구)

AI 에이전트가 웹 애플리케이션을 실행하거나, 데이터 분석 로직을 수행할 땐 알아서 일꾼처럼 일할 수 있는 Node.js와 Python이 필요하다. 그뿐만 아니라 인스타그램을 크롤링하기 위해서는 'pandas instaloader' 라이브러리 설치가 필요하다. 이때 만들고자 하는 서비스에 따라 필요한 라이브러리는 AI 에이전트가 자동으로 설치 또는 안내해 주므로, 너무 걱정하지 않아도 된다. 그리고 만들어진 서비스를 구현하고 검증하기 위해, Chrome 브라우저를 조작하여 영상을 제공할 수 있도록 확장 프로그램을 설치한다.

Node.js설치: 설치 중에 팝업 화면에서는 NEXT로 넘어가면 되는데, 중간에 Automatically install체크박스를 꼭 체크하고 설치해야 한다.
Python설치: Python 3.14.2 다운로드 후 설치 파일을 실행해 설치할 때 뜨는 창의 맨 밑에 Add python.exe to PATH체크박스를 꼭 체크하자.

3) DB 연동

앞서 설치한 프로그램들이 인스타그램에서 데이터를 찾아오는 역할을 했다면, 해당 데이터를 쌓아두는 저장소가 필요하다. 데이터 저장소는 MySQL, MongoDB 등으로 구현할 수 있는데, 로컬 또는 클라우드 서비스를 통해 이용할 수 있다.

DB 부분은 다뤄야 할 내용이 워낙 많아서, 이번 글에서는 복잡한 DB 구축 대신 기획자가 데이터를 파악하기 쉬운 CSV 파일로 만들어서 간단하게 사용했다. CSV 파일은 AI 에이전트가 자동으로 필요한 데이터를 수집해서 같은 파일에 차곡차곡 계속 데이터를 쌓아 주었다.

기획→준비→구현→검증까지 한 번에 구현

개발을 잘 모르는 상태에서 앱을 만들다 보면 중간에 예기치 못한 상황에 부딪혔을 때 매우 당황스럽다. 예를 들어, 인스타그램을 크롤링할 땐 연속으로 데이터를 요청하면 봇으로 간주해서 차단(Soft Ban)하는 현상이 생겼다. 보통 시간당 20~30건 정도 크롤링한 후 멈췄다. 그래서 공구에 최적화된 기준을 만들고 해당 기준에 충족하는 1,000건 정도만 시간차를 두고 내려받아 data.csv 데이터 파일을 만들어서 사용했다. 이처럼 문제가 생겼을 땐 해결 방법에 대해서도 물어보면서 진행하면 된다.

안티그래비티는 해당 기능을 구현하면서도 다른 기능을 따로 구현할 수 있는 에이전트 매니저가 있어서 여러 개의 기능과 앱을 동시에 만들 수 있다는 점이 편리했다. 즉 크롤링 기능과 검색 기능을 따로 만들 수 있다. 그리고 각각 히스토리 관리가 가능하여 에이전트 간 조율이 가능하다는 점에서 기획자가 마치 코딩이 아니라 PM 역할을 하는 것처럼 느껴졌다.

1) Planning 모드에서 기초 설계

안티그래비티에서는 특히 Planning과 Fast 모드가 구분되어 있어, Planning 모드에서 큰 그림을 설계하고 Fast 모드에서 디테일로 수정할 수 있는 부분이 좋았다.

프롬프트: 인플루언서 찾는 앱을 만들되 이름, 아이디, 카테고리, 팔로워 수로 검색/정렬할 수 있게 해줘.

인플루언서 검색 개발 계획 <출처: 작가>

2) Fast 모드에서 만들고 수정하기

Fast 모드에서는 개발 계획서대로 만들어 달라고 하면 된다. 그리고 결과물을 보면서 여러 차례에 걸쳐 수정을 해가면서 완성도를 높여갔다. 기획자인 내가 코드 한 줄 작성하지 않고도, 명령어 한 줄로 원하는 결과가 나올 때까지 여러 번 수정하면서 점차 변화되어 가는 걸 보면서 그저 놀라울 따름이었다.

프롬프트: 아이디 영역을 선택하면 인스타그램을 연결해 주고 체크박스 영역을 선택하면 DM을 발송하는 형태로 만들어서 git 허브에 배포할 수 있는 URL을 알려줘.

처음으로 만든 앱

처음 만든 앱에서 공동구매에 적합한 인플루언서를 일상, 식품, 육아, 리빙, 패션, 다이어트, 뷰티, 여행, 피트니스, 교육 등등의 카테고리를 상단에 추가하고 이름으로도 검색할 수 있는 기능을 추가하고 크롤링 부분을 보완하여 완성했다.

인플루언서 검색 앱 개발 및 수정 <출처: 작가>

3) 자동화 테스트 및 아티팩트 리뷰

다른 툴을 사용할 때는 코딩을 몰라서 내가 말한 대로 구현이 되지 않으면 난감했었는데, 코드를 읽지 못해도 아티팩트 시스템을 통해 대략적인 개발 흐름을 파악할 수 있어서 좋았다.

앱이 제대로 작동하는지 확인하는 과정에서는 23줄 삭제, 26줄 추가처럼 알아서 자동으로 테스 해 주면서 코드 수정과 검증을 시작한다. 그리고 앞서 겪었던 인스타그램 크롤링 차단 문제와 같은 예외 상황에서는 “한 명 성공할 때마다 무조건 data.csv 파일에 저장하고 시간당 20개 수집하고 → 1시간 쉰 후 → 다시 20개 수집”처럼 해결책까지 주어서 안심이 되었다.

최종 검토는 아래 그림처럼 자동으로 크롬 브라우저를 열어서 미리 앱의 구현 모습을 즉각적으로 녹화 영상을 보여주므로 쉽게 확인할 수 있었다.

인플루언서 검색 앱 테스트 및 리뷰 <출처: 작가>

배포 채널 선택 후 배포하기

앱을 만들었다면 GIT, Vercel, Railways 등에 배포할 수 있다. 개인적으로 GIT을 선택한 이유는 소스 코드 변경 내용을 기록하여 체계적으로 관리할 수 있기 때문이다. 아래처럼 Vercel이나 Railways 같은 배포 서비스들이 대부분 GitHub 와 연동되어 작동한다.

1) GIT및 GitHub 연동하기

Git은 앱을 효율적으로 관리하고 배포할 수 있다는 장점이 있지만, 다운로드 설치 후 Git Bash라는 터미널 창을 이용해야 해서 기획자 입장에서는 다소 겁이 날 수도 있다. 나 역시 처음엔 GIT과 GitHub 개념이 익숙지 않아, 제대로 배포가 되지 않았다. 그래서 몇 번이고 안티그래비티에 물어보면서 진행했다.

git: 다운로드 설치 후 원격 저장소인 GitHub 회원가입하여 코드를 온라인에 저장하고, 배포 채널에 연결한다.

2) git과 Vercel에 배포하기

배포하기 위해서는 먼저 코드를 GitHub에 배포하기 위해 준비를 하는 것이 필요하다. 그래서 안티그래비티에 GitHub에 배포할 수 있도록 준비한 후 배포 URL을 알려달라고 하면 방법을 알려준다.

GitHub에 배포할 수 있는 URL을 생성하기 위해 새로운 리포지토리(Repository)를 생성해 주고, Git Bash 창에 아래 명령어들을 순서대로 입력하여 배포를 진행한다. Origin 부분에는 생성한 리포지토리 URL을 적어준다.

GitHub → ⚙️Settings → Pages (Code and automation 섹션) → Build and deployment 항목에서 다음과 같이 설정하고 저장하면 URL이 생성된다.

- Source: Deploy from a branch

- Branch: main (또는 master) / /(root)

마지막으로 Vercel에 회원가입 후Complete with GitHub → Vercel과 GitHub 계정 연결 → Import로 프로젝트 가져오기 → Deploy 버튼을 선택하여 최종 배포하면 되는데, 이 과정은 아래 영상을 통해 확인하면 더 이해하기 쉬울 것이다.

앱 배포하는 과정 <출처: 작가>

마치며: 기획의 언어는 바뀌어야 한다

바이브 코딩으로 상상했던 것을 만들어보니, 생각했던 것 이상으로 재미있고 뿌듯했다. 여러 시행착오 끝에 확실한 깨달음은 어떤 업무를 하게 되든 간에 단순 반복적인 업무는 자동화할 수 있다는 가능성과 아무리 뛰어난 AI라도 구조화된 설계 없이는 엉뚱한 결과물을 내놓는다는 점이다. 그래서 현재 하는 업무에서 AI로 효율을 높일 수 있는 부분을 찾고, 기술 설계서를 검토하는 것부터 시작해 보면 좋다.

이제는 기획 문서를 넘어 작동되는 서비스로 증명하는 시대다. 일단 커서, 클로드 코드, 안티그래비티 뭐든 좋으니 AI 코딩 툴에 말을 걸어보는 것에서부터 시작해 보자. 실제 작동하는 프로토타입을 만들어본다는 것은 단순히 코드를 자동으로 작성한다는 것을 넘어, 데이터의 구조를 이해하고 정확한 지시를 내리며, 다양한 AI 에이전트를 조율해 그 결과물들이 기획 의도에 맞는지 검증해 내는 것을 의미한다.

이렇게 바이브 코딩으로 대화를 거듭하다 보면, 어느새 더 명확하게 지시하고 검증하는 기획자의 ‘새로운 근육’이 붙은 자신을 발견할 수 있을 것이다.

<참고>

인플루언서 파인더(AI 공구 소싱 달력 서비스를 통해 요즘엔 어떤 공동구매를 진행하는지도 참고해 볼 수 있다.)

]]>

지금, 프로젝트 관리에 Jira 대안이 필요한 이유

이 글은 스위그와 함께 요즘IT 브랜디드 콘텐츠로 제작했습니다.

“AI 덕분에 개발 속도는 몇 배나 빨라졌는데, 왜 제품 출시는 오히려 늦어질까요?”

요즘 Claude Code와 Cursor로 무장한 개발자들이 하루에 완성할 수 있는 기능의 양은 과거와 비교하기 어렵습니다. 그뿐만이 아닙니다. 기획자, 디자이너, 개발자가 팀을 이뤄 몇 달을 매달려야 모습이 보일까말까 하던 서비스가, 이제는 능력 있는 개인이나 소규모 팀에 의해 몇 주 만에 나타나기도 합니다.

몇 년 전 유행하던 사이드 프로젝트와는 질적으로 달라 보입니다. 비즈니스 로직은 정교해졌고, 프로젝트의 규모와 복잡도는 기하급수적으로 커졌습니다. 혼자서 3~4개의 프로덕트를 동시에 돌리는 메이커 역시 더는 낯설지 않은 풍경이죠. ‘만드는 것’의 장벽이 역사상 가장 낮은 시대가 아닐까 생각합니다.

그런데 이상합니다. 제가 만난 분들은 여전히 제품의 배포 일정이 미뤄지고 스프린트마다 ‘못다 한 일’이 쌓여간다고 합니다. 이야기를 듣다 보면 그 이유는 비슷했습니다. 지금의 관리 방식과 도구가 기술의 발전 속도를 따라가지 못했기 때문입니다.

그래서 글을 썼습니다. 우리는 언제까지 ‘진짜 일’이 아니라 ‘티켓’에 시간을 쏟아야 할까요? 지금 AI 시대에 걸맞은, 새로운 프로젝트 관리의 철학이 필요한 시점입니다.

<출처: 요즘IT>

생산성 폭발을 가로막는 숨겨진 병목

문제는 협업이 시작되는 순간부터 나타납니다. 혼자서 일을 정리할 때는 노션 한 페이지면 충분합니다. 하지만 팀이 커지고 다루는 프로젝트가 많아지면 사람들은 불안함을 느낍니다. 그래서 습관적으로 ‘업계 표준’이라 불리는 무거운 프로젝트 관리 툴들을 도입하기 시작합니다. Jira, Asana, Trello 같은 것들이죠.

여기서 모순이 생깁니다. 일할 때는 AI를 써서 광속으로 코드를 짜고 디자인을 뽑아내는데 정작 그 결과물을 관리하기 위해 과거의 행정 업무를 답습하고 있는 것입니다. 결과물에 대한 의견을 조율하고, 핵심 비즈니스를 검토하며, 고객을 만나기도 부족한 시간은 정작 이런 질문에 답하는 데 쓰입니다.

“Jira 티켓 생성하셨나요?”
“워크플로우 상태값 업데이트 안 되어 있네요.”
“이 필드는 필수 입력 사항입니다.”

혁신적인 서비스를 만들기 위해 모인 인재들이 하루 업무 시간의 상당 부분을 툴을 관리하고, 데이터를 입력하고, 현황판을 꾸미는 데 쓰고 있습니다. 화려한 칸반 보드와 보기 좋은 타임라인에 잘 정리된 차트는 남지만, 실행 속도는 느려질뿐더러 데이터에 대한 신뢰 역시 낮아집니다.

어느새 실행(Shipping)을 위해 존재하던 도구들이 지금은 움직임을 가로막는 가장 큰 병목(Bottleneck)이 되어버린 것입니다. 그래서 우리는 다시 질문하게 됩니다.

우리는 더 나은 제품을 만들기 위해 모였는가,

아니면 티켓과 상태값을 관리하기 위해 모였는가.

<출처: 요즘IT>

과거의 프로젝트 관리 도구와 3가지 한계

우리가 도입해 온 기존의 프로젝트 관리 도구들은 대부분 AI 시대 이전에 설계된 유물입니다. 이들은 생산성의 폭발이 필요한 지금, 실무자에게 ‘입력’이라는 제2의 노동을 강요하는 존재로 바뀌었습니다.

1. 모든 SaaS는 당신의 시간을 원한다

IT 업계에는 이미 수많은 SaaS 도구가 자리 잡고 있습니다. Slack과 같은 메신저, GitHub를 비롯한 코드 저장소, Figma 등 디자인 툴, Notion으로 대표되는 문서 도구까지. 각 도구는 자신이 맡은 역할에 최적화되어 있으며 분명히 높은 생산성을 만들어내고는 합니다.

이러한 SaaS는 모두 실제 작업이 이뤄지는 공간입니다. 따라서 사용자가 오래 머무르며 작업 의존도를 높이는 것 자체가 도구의 유용성을 입증하는 지표입니다. 그렇게 주요 SaaS 기업이 체류 시간과 리텐션을 핵심 지표로 삼아 성장해 온 것은 충분히 합리적인 전략이었습니다.

문제는 이 전략이 모든 종류의 SaaS에 그대로 적용되면서 발생합니다. 관리를 위한 도구마저 사용자의 시간을 뺏고자 ‘체류 시간’을 핵심 지표로 삼은 것입니다. 이제 사람들은 SaaS가 유도한 대로 같은 작업을 여러 번 기록하고 설명해야 하는 상황에 놓입니다. 코드는 코드대로, 디자인은 디자인대로, 논의는 메신저대로 진행되지만, 그 결과를 다시 정리해 입력하는 데 시간을 쓰는 것이 당연한 절차처럼 굳어졌습니다.

2. 관리를 위한 ‘입력’의 이상과 현실

그렇게 도구들이 쌓이고 나면 실무자는 이제 모든 과정에서 일을 위한 일을 해야 합니다. 티켓을 만들고, 매번 상태를 바꾸고, 끝난 뒤에는 다시 정리된 결과를 입력합니다.

이를 위한 촘촘한 필드와 규칙은 ‘체계적인 관리’의 상징처럼 여겨집니다. 하지만 이 구조는 중요한 3가지 전제를 깔고 있습니다. 실무자는 언제나 입력할 여유가 있고, 이 정보는 항상 정확하며, 조금도 지연되지 않는다는 전제입니다.

현실은 다릅니다. 실무자들은 보통 실행에 몰입할수록 입력을 뒤로 미룹니다. 가장 바쁘기에 관리가 중요한 시점일수록 도구의 데이터는 가장 비어 있습니다. 의무감에 기껏 입력한 정보 역시 주관적이라 확실치 않습니다.

이는 마치 택시 기사에게 운전 중에 수기로 운행 일지를 작성하라고 요구하는 것과 비슷합니다. 목적지는 분명한데 택시 기사가 기록을 남기느라 운전에 집중하지 못하면 어떨까요? 결국 도착 시간은 늦어지고 사고의 위험은 커집니다. 기록은 남았을지 몰라도, 그 기록이 만들어진 과정은 결코 효율적이지 않은 겁니다.

3. “그래서, 그 기능 언제 배포되나요?”

이런 흐름의 한가운데 놓인 프로젝트 관리 도구는 또 다른 특징을 가집니다. CRM이나 HR, 회계 시스템은 특정 역할의 사람들이 주로 사용하는 도구입니다. 반면, 프로젝트 관리 도구는 다릅니다. 개발자, 디자이너, 기획자뿐 아니라 영업과 마케팅, 관리자와 경영진까지 모두가 각자의 목적을 가지고 들여다보는 공간으로 쓰입니다.

문제는 이들이 사용하는 언어와 관심사가 모두 다르다는 점입니다. 개발자는 코드와 이슈를 보고 싶어 하고, 디자이너는 산출물과 흐름을 중시합니다. PM은 일정과 우선순위를, 비즈니스팀은 고객 가치와 마감일을, 관리자는 전체 진행 상황과 리스크를 확인하려 합니다. 이 서로 다른 요구를 하나의 도구 안에서 모두 만족시키려다 보니, 프로젝트 관리 도구는 점점 더 많은 필드와 상태값, 복잡한 워크플로우를 가져야 했습니다.

결국 이 복잡성을 담기 위해 이들 도구는 가장 기능적인 언어, 즉 ‘개발자의 언어’를 택합니다. 복잡한 상태 관리, 쿼리로만 움직이는 데이터, 어려운 로직과 자동화가 기본이 된 거죠. 결국 비개발 직군에게 이들 도구는 접근하기 힘든 암호문이 되어버립니다. 어느 순간부터 그들은 Slack으로 돌아와 묻습니다.

"그래서 그 기능, 언제 배포되나요?"

비싼 돈을 내고 툴을 들여와도 소통 비용은 줄어들지 않는 아이러니입니다.

<출처: 요즘IT>

티켓 너머 ‘진짜 일’이 존재하는 공간

그렇다면 진짜 일은 어디에 존재할까요? 본질로 돌아가 봅시다.

1. 실무자의 역할은 ‘입력’이 아닌 ‘실행’

앞서 말한 택시 기사의 예시를 다시 보겠습니다. 오늘날 택시 기사들은 손으로 기록하지 않고도 운전에만 집중할 수 있습니다. ‘미터기’와 ‘GPS’가 있기 때문입니다. 그들이 핸들을 꺾고 엑셀을 밟는 순간, 기계는 자동으로 이동 거리와 요금을 계산하고 주행 경로를 서버에 기록합니다. 모두 운전에 집중할 뿐 그 어떤 관리 행위도 하지 않습니다.

기사의 역할은 사고 없이 운전하는 것이고, 관리 도구의 역할은 그 운전의 결과를 정확히 읽어내는 것입니다. 만약 기사에게 운전 중에 일지를 쓰게 한다면 운전의 질도, 기록의 정확성도 동시에 떨어질 수밖에 없습니다.

프로젝트도 크게 다르지 않습니다. 이 작업의 경로에서 실무자가 해야 할 역할은 ‘입력’이 아니라 ‘실행’입니다. 그리고 그 실행은 이미 각자의 작업 공간에서 실시간으로 흔적을 남기고 있습니다.

2. 진짜 일이 있는 현장

우리는 흔히 Jira 티켓이나 간트 차트가 프로젝트의 현황이라고 착각합니다. 하지만 그것은 누군가에 의해 가공된 2차 정보일 뿐입니다. 프로젝트의 관리 대상들은 ‘실제로 일하는 공간’에 있습니다.

개발자의 진척도는 티켓의 상태값이 아니라, Git에 올라가는 코드(Commit, PR)에 있습니다.
디자이너가 만든 버전들은 작업 로그가 아니라, Figma의 수정 내역(History)에 담겨 있습니다.
팀의 의사결정은 회의록 문서가 아니라, Slack의 대화 스레드 속에 살아 있습니다.

지금 대부분의 팀에서 실무자가 사용하는 도구는 정해져 있습니다. 개발자는 코드 저장소에서 일하고, 디자이너는 디자인 툴에서 사고하며, 팀의 논의는 메신저와 문서 위에서 이루어집니다. 이 흐름을 바꾸는 것은 쉽지 않을뿐더러 바꿀 필요도 없습니다. 이처럼 진실의 원천(Source of Truth)은 실무자들이 일하는 공간에 실시간으로 쌓이고 있습니다.

그럼에도 우리는 진짜 흐름이 쌓이는 현장을 외면한 채, 실무자를 관리 도구에 ‘적응시키는 것’이 문제의 해답이라고 믿어왔습니다. 실무자의 상황을 어떻게 관리 도구 안으로 끌고 올지만 고민해 온 것입니다.

‘입력’시키지 않아도 ‘흐름’을 알 수 있는 관리

관리 도구가 실무자의 일하는 방식을 대체하려는 순간, 그 도구는 관리 도구로서 실패합니다. 관리의 역할은 일을 ‘시키는 것’이 아니라, 이미 일어나고 있는 실행을 읽고, 연결하고, 판단할 수 있는 상태로 만드는 것입니다. 그래서 관리의 출발점은 언제나 계획이 아니라 실행이어야 합니다. 계획은 실행으로 이어질 때 의미가 있고, 실행의 흔적은 이미 현장에 남아 있기 때문입니다.

1. 사람들이 툴이 쓰지 않는 진짜 이유: ‘입력’과 ’방해’

저희 팀은 ‘뤼이도’라는 프로젝트 관리 툴을 만들고 있습니다. 뤼이도와 함께 현장에서 관리에 발목 잡혀 대안을 고민하는 팀을 만나보면 상황은 비슷했습니다. 관리자들은 “Jira를 도입했는데 아무도 안 써요.”라고 말하고, 실무자들은 “실제 일하는 시간보다, 관리하는 일이 더 많아요.”라고 말했습니다.

처음에는 기존 도구의 고질적인 문제 몇 가지만 바꿔보겠다고 생각했습니다. Jira와 같은 기존의 프로젝트 관리 툴은 분명 현장의 체계를 바꾸었다고 믿었기 때문입니다. IT라는 영역의 애매모호한 업무 태스크를 일관성 있게 통제할 표준을 만들어 주었죠. 무엇보다 갈수록 복잡해지는 기술 프로젝트에 관리라는 행위가 없으면 일은 산으로 갈 것입니다.

그래서 뤼이도 역시 기존의 성공 공식을 따랐습니다. 관리 화면을 더 보기 좋고 쓰기 좋게 만드는 데 집중한 것입니다. 초기에는 반응도 괜찮았습니다. 사용자의 리텐션과 체류 시간이 높은 것을 보며 환호했죠. 그렇게 “사용자들이 우리 툴을 자주 쓰는구나, 우리가 잘하고 있구나”라고 생각했습니다.

뤼이도 초기 제품 화면 이미지 <출처: 스위그>

하지만 현장의 목소리를 듣고 나서야 그것이 오만한 착각이었음을 깨달았습니다. 실무자들에게 잦은 접속은 생산성이 아니라 방해(Interruption)였습니다. 코딩하다가 들어와서 티켓 옮기고, 디자인하다가 들어와서 댓글 달고…. 레거시 툴의 문제를 해결하겠다고 나섰지만, 결국 똑같이 실무자의 발목을 잡고 있었던 것입니다.

여기서 깊이 깨달은 것이 있습니다. 기존 도구의 ‘입력 기반 관리’ 구조는 필연적으로 놓치는 것들이 존재한다는 것입니다. 입력에 의존하면 정보는 언제나 한 박자 늦어집니다. 서로 일을 확인하느라 다시 묻고 정리하다 보면, 흐름이 끊기고 결정이 늦어지다 출시가 미뤄집니다.

더 큰 문제는 이러한 입력의 시간이 몰입을 깬다는 데 있습니다. 상태를 입력하기 위해 일을 잠시 멈추면 사람들은 다시 몰입 상태로 돌아오기까지 더 많은 시간이 필요합니다. 결국 사람들이 도구를 쓰지 않는 이유는 관리가 싫어서가 아니라, 입력으로 흐름이 끊기는 경험이 싫기 때문입니다.

2. 도구에 들어오지 못하게 했더니, 더 깊게 머문다

그래서 방향을 완전히 틀었습니다. 목적은 하나였습니다. “실무자가 우리 툴에 들어오지 않게 만들자.”

GitHub, Figma, Slack과 연결되는 뤼이도 <출처: 스위그>

GitHub, Figma, Slack처럼 그들이 이미 머무르고 있는 도구에 우리가 찾아가기로 했습니다. 그들이 뤼이도를 의식하지 않고 일해도, 뤼이도의 프로젝트 관리 화면에 업무 데이터가 쌓이게 했습니다.

아이러니하게도 접속에 대한 강요를 없애자, 제품 내에 체류하는 시간이 비약적으로 늘어났습니다. 과거에는 입력을 위해 5분씩 10번 들어왔다면, 이제 입력은 시스템에 맡기고 분석과 의사결정을 위해 하루 3~4시간씩 깊게 머물기 시작한 것입니다. 신뢰할 수 있는 데이터가 자동으로 쌓이니 사람들은 ‘히스토리 탐색’과 ‘다음 전략 수립’이라는 진짜 관리 업무를 하러 들어오게 되었습니다.

뤼이도의 프로젝트 관리 화면 <출처: 스위그>

이것이 우리가 발견한 좋은 관리의 본질이었습니다. 입력을 강요해 만든 데이터는 쓰레기가 되지만, 입력을 없앤 데이터는 자산이 됩니다.

3. 지금, Jira의 대안이 필요한 이유

저희 팀이 현장에서 발견한 진짜 해결책은 더 많은 필드도, 더 정교한 워크플로우도 아니었습니다.

실행과 관리가 분리되지 않은 프로젝트 관리의 새로운 구조였습니다. 더는 입력 기반 관리가 폭발하는 생산성을 가로막아서는 안 된다는 철학이었습니다. 이제는 관점을 바꿔야 합니다.

뤼이도 프로젝트 관리 화면 <출처: 스위그>

좋은 프로젝트 관리란 입력이 없어도 흐름이 보이는 데 있습니다. 그저 예쁜 칸반이 아닌 실제 현장의 데이터, 멈춰서서 입력하지 않아도 알아서 모이는 구성이 필요합니다. 새로운 시대의 프로젝트 관리 도구는 그 흐름을 쉽게 파악하고 관여하는 일에만 집중해야 합니다.

사람이 도구에 맞추는 시대에서, 도구가 사람의 행동을 이해하는 시대로의 이동이 필요합니다.

마치며

우리는 종종 착각에 빠집니다. 밀린 Jira 티켓을 정리하고, 회의록을 깔끔하게 다듬고 나면 묘한 뿌듯함이 밀려옵니다. “오늘 하루, 참 열심히 살았다” 싶은 안도감도 함께 옵니다. 대시보드가 비워지는 것만으로 우리는 무언가를 해냈다는 느낌을 받습니다.

하지만 한 번쯤은 냉정하게 물어야 합니다. 그것이 정말 ‘일’이었을까요? 티켓 상태를 완료로 바꾸는 행위가 고객에게 어떤 가치를 주었나요? 회의록 정리 자체가 제품의 버그를 고쳤을까요?

실무자는 본질적으로 실행하는 사람입니다. 코드를 쓰고, 디자인을 만들고, 문제를 해결해야 합니다. 특히 AI로 1인당 생산성이 비약적으로 높아진 지금, 사람이 써야 할 시간은 더욱더 ‘본질적인 일’에 가까워져야 합니다. 일을 위한 일(Work about Work)이 주는 가짜 성취감을 경계해야 합니다. 그것만으로는 제품은 단 1mm도 전진하지 않습니다.

그래서 지금 필요한 변화는 ‘일의 관리’를 바라보는 관점의 변화입니다. 관리가 많아질수록 일이 잘된다고 믿는 대신 관리할 필요가 줄어드는 구조를 만들고 있는지를 물어야 합니다. 좋은 팀은 관리하지 않는 팀이 아니라, 관리 때문에 흐름이 끊기지 않는 팀입니다. 비효율을 걷어내 본질에 집중하려는 팀에게 필요한 건 오직 이 질문뿐입니다.

우리는 일을 관리하고 있는가,

아니면 그저 관리한다는 착각 속에 있는가.

]]>

AI 시대를 사는 디자이너의 무기, UX 심리학

AI로 1분 만에 만든 프로토타입 <출처: 작가, Stitch AI로 제작>

이미지는 프로토타이핑 AI인 스티치 AI(Stitch AI)로 단 1분 만에 생성한 결과물이다. “넷플릭스 모바일 앱에 플레이리스트 생성 기능을 추가해달라”는 한 줄짜리 프롬프트를 입력하고 조금만 기다리면, 이렇게 메인 화면을 시작으로 플레이리스트 생성 버튼과 입력 창, 결과 화면까지 포함한 시안이 뚝딱 만들어진다.

저충실도(low-fidelity) 프로토타입도 겨우 만들어내던 2년 전과는 달리, 이제 AI 디자인 도구는 몇 가지 키워드만으로도 고충실도(high-fidelity) 결과물을 빠르게 만든다. 이토록 프로토타이핑이 쉬워진 지금 같은 시대에는 ‘사용자 경험’을 고민하는 일명 UXer*의 역할이 더 많은 화면 시안을 만드는 데 있지 않다.

*UXer: 주로 UX 디자이너를 일컫는 용어로 쓰이지만, 이 글에서는 제품 개발/설계/UX 개선에 관여하는 IT 직군(기획자, 디자이너, 엔지니어, 리서처 등) 모두를 지칭했다.

이들에게 더 중요한 일은 이 디자인이 왜 필요한지, 사용자가 이 화면을 마주했을 때 어떤 감정을 느끼고 왜 그런 행동을 하는지 이해하는 일이다. 결국 인간 심리를 이해하는 것이야말로 제품 설계의 본질이라는 것이다.

“인간 심리학을 이해하지 못하는 디자이너는 물리학을 이해하지 못하는 건축가보다 성공할 수 없다.”
A designer who doesn’t understand human psychologies is going to be no more successful than an architect who doesn’t understand physics

조 리치(Joe Leech), “디자이너를 위한 심리학(Psychology for designers)” 중에서

UX 심리학이란?

UX 심리학은 사용자 경험과 인지 심리학이 합쳐진 용어다. 다만, 이 글에서 다루는 ‘UX 심리학’은 엄밀하게 심리학의 한 영역으로만 국한되지 않는다. 행동경제학, 인지 심리학, HCI(인간-컴퓨터 상호작용) 등에서 사용자의 인지와 행동을 이해하기 위해 다뤄지는 주요 개념을 UX 설계 관점에서 실용적으로 풀어낸 모든 이론을 폭넓게 포괄한다. 각 용어의 뜻을 더 자세히 짚어보겠다.

먼저, 사용자 경험(UX, User eXperience)은 모바일 앱이나 웹사이트처럼 디지털 환경에서의 경험뿐 아니라 우리가 일상에서 접하는 모든 제품과 서비스에 대한 경험 전반을 포함하는 개념이다.

주름이 잡힌 빨대 <출처: freepik>

빨대에 있는 주름을 한 번 떠올려보자. 주름이 생기기 전에는 빨대로 음료를 마시려면 고개를 앞으로 숙여야 했다. 하지만 주름이 생기며 빨대는 유연하게 구부러졌고, 사용자는 훨씬 편한 자세로 음료를 마실 수 있게 됐다. 이러한 주름 디자인 역시 사용자 경험을 개선한 UX 설계의 한 예라고 할 수 있다.

인지 심리학(Cognitive Psychology)은 우리가 세상에 존재하는 정보를 어떻게 받아들이고, 또 어떻게 해석하는지를 다루는 분야다. 교육, 법학, 헬스케어, 건축 등 다양한 영역에서 쓰이며, 이를테면 더 쉽게 새로운 내용을 전달하는 방법을 고민하거나(교육), 범죄 의도나 법적 행동을 이해하는 데(법학) 적용된다.

UX 디자인도 마찬가지다. 이 영역은 단순히 예쁜 화면을 만드는 일이 아니라, 사용자가 서비스를 어떻게 인식하고 어떤 흐름으로 조작하며, 결과적으로 어떤 경험을 얻는지 고려하고 설계하는 과정이다. 이 과정에서 심리학은 본질을 탐구하는 역할을 할 수밖에 없다.

UX 심리학의 예: ‘흑백요리사’는 왜 멈출 수 없을까?

예를 들면 이런 것이다. 최근 흑백요리사 시즌 2가 넷플릭스에 공개됐는데, 매번 가장 궁금한 결과를 앞두고 에피소드가 끝나버린다. 처음에 ‘하나만 봐야지’라는 마음으로 재생한 우리는 결국 ‘다음 화 자동 재생’을 멈추지 못한 채 밤을 새운다. 다른 오디션 프로그램에서도 마지막 참가자의 결과 발표 직전이면 꼭 광고가 등장한다. 시청자 입장에서야 답답하고 애가 타지만 기다리는 것 말고는 별다른 도리가 없다.

1. 자이가르닉 효과

이는 자이가르닉 효과(Zeigarnik Effect)의 대표적인 사례다. 자이가르닉 효과는 완료된 일보다 미완성된 일을 더 오래 기억하는 경향을 설명하며, 미완성 효과라고도 불린다. 이를 UX 설계에 적용하면 사용자가 특정 작업(결과 보기)를 끝내지 못한 상태에서 느끼는 불편함과 찝찝함을 자극해 다음 행동(지속 시청)을 자연스럽게 유도할 수 있다.

이러한 전략은 디지털 서비스에서도 어렵지 않게 찾아진다. 캔디 크러쉬나 피쉬돔 같은 게임을 하다 보면 생명, 즉 게임 가능 횟수를 모두 소진했을 때 하트를 구매하라는 메시지가 등장한다. 조금만 더 하면 스테이지를 깰 수 있을 것 같다고 느끼는 사용자에게 ‘결제’라는 행동을 유도하는 방식이다.

캔디 크러쉬 시리즈 <출처: 구글 플레이>

콘텐츠 플랫폼에서도 이 전략은 자주 쓰인다. 한창 재미있어지는 지점에서 글이나 영상이 끊기면, 더 많은 내용을 볼 수 있는 구독이나 결제 버튼으로 이어지는 것이다. 네이버 웹툰의 쿠키나 롱블랙의 구독 서비스가 대표적인 예다.

2. 사용자의 행동을 유도하는 애플의 UX 심리학

애플 워치의 활동 링 디자인 역시 자이가르닉 효과를 잘 활용한 사례다. 애플 워치는 하루에 채워야 할 일정량을 채우지 못하면 꾸준히 알림을 보내며 사용자가 ‘미완성’ 상태임을 인식하게 만든다. 이를 불편하게 느낀 사용자는 워치가 제안하는 행동인 걷기나 일어서기로 링을 완성할 가능성이 높아진다.

애플 워치의 활동 링 <출처 : 애플>

이러한 활동 링 디자인에는 사용자의 행동을 유도하는 또 다른 심리 효과 3가지가 숨어있다.

부여된 진행 효과

부여된 진행 효과 <출처: 작가>

우리는 완전히 0에서 시작하는 것보다, 이미 일부를 완료한 상태에서 다음 행동을 훨씬 쉽게 이어간다. 애플 워치를 차고 있으면 잠깐 자리에서 일어나거나 가볍게 움직이기만 해도 활동 링이 채워지기 시작한다. 이를 본 순간부터 사용자는 나머지 활동량을 채울 가능성이 조금 더 높아진다. 이러한 현상을 설명하는 개념이 바로 ‘부여된 진행 효과’다. 온라인 강의를 수강할 때, 사전 설문조사에만 참여해도 진도율이 일부 올라가는 것 역시 이 효과를 적용한 디자인 사례다.

목표 가속화 효과

목표 가속화 효과 <출처: 작가>

활동 링을 조금씩 채우다 보면 사용자는 점점 목표에 가까워진다. 그럴수록 더 속도를 내서 끝내고 싶어진다. 이렇게 목표에 근접할수록 목표를 이루고자 하는 동기가 더 커지는 현상을 ‘목표 가속화 효과’라고 한다. 애플워치는 목표 달성이 가까워지면 ‘움직이기 링을 거의 완성했어요. 조금만 더, 12분 동안 빠르게 걸어주세요.’와 같은 메시지를 보내며 효과를 더 극대화한다.

목표 시각화 효과

목표 시각화 효과 <출처: 작가>

지금까지 얼마나 진도가 나갔는지, 그리고 목표까지 얼마나 남았는지를 눈에 보이게 표현하는 것 역시 강력한 동기부여 요소다. 만약 활동 링이 시각적으로 보이지 않는다면, 목표까지 얼마 남지 않았다고 아무리 말해도 사용자에게는 와닿지 않는다. 이처럼 목표와 진행 과정을 시각화했을 때, 목표를 끝까지 추구하려는 동기가 더 커지는 현상을 ‘목표 시각화 효과’라고 한다.

UX 심리학으로 알아보는 불쾌한 경험들

반면 UX 심리학을 충분히 고려하지 않았을 때는, 사용자의 행동을 유도하기는커녕 오히려 이탈을 부르는 불쾌한 경험이 만들어지기도 한다.

부메랑 효과

외국어 학습 서비스인 듀오링고의 마스코트이자 앱 아이콘은 연두색 부엉이 캐릭터다. 한 번은 이 부엉이 캐릭터가 마치 괴상하게 녹아내리는 듯한 모습으로 바뀐 적이 있었다.

듀오링고 앱 구글링 결과 <출처: 작가>

이는 앱을 다운로드만 해두고 잘 사용하지 않는 사용자의 시선을 끌어 다시 접속하게 만들기 위한 일종의 심리적 장치였다. 하지만 실제로는 SNS를 중심으로 불쾌감을 표현하는 반응이 많았고, 나 역시 징그러운 부엉이가 자꾸 푸시 알림을 보내는 것이 불편해 결국 앱을 삭제하기까지 했다. 이처럼 누군가를 설득하려는 시도가 오히려 반대의 결과로 이어지는 현상을 ‘부메랑 효과(Boomerang effect)’라고 한다.

다크 패턴

그뿐만 아니라 의도적으로 사용자를 속여 특정 행동을 유도하는 디자인도 있다. 이를 다크 패턴(Dark Pattern)이라고 한다. 갑자기 카드 결제가 이뤄져 확인해 보니 원하지 않았던 구독 서비스가 연장된 상황이나, 이를 해지하려 해도 환불을 받을 수 없거나 심지어 추가 수수료까지 요구받았던 경험이 이에 해당한다. 이런 것들은 모두 다크 패턴의 모습이다.

물론 이 방식은 단기적으로 수익을 올리는 데는 효과적일 수 있다. 하지만 브랜드와 서비스 전체에 대한 인식에 악영향을 미친다는 점에서 매우 위험한 전략이라고 할 수 있다.

피크엔드 법칙과 부정 편향

이러한 일의 위험성은 피크엔드 법칙(Peak-End Rule)으로 더 잘 설명할 수 있다. 이 법칙에 따르면 사용자는 전체 경험을 평균적으로 기억하지 않는다. 대신 가장 강렬했던 순간(피크)과 경험이 끝나는 시점(엔드)을 중심으로 그 경험을 평가한다.

서비스 해지 과정에서 겪는 부정적인 감정은 기억에 강하게 남고, 결국 서비스 전체에 대한 부정적인 인식을 형성한다. 여기에 더해 긍정적인 경험보다 부정적인 경험을 더 강하게 기억하는 경향인 부정 편향(Negativity Bias)까지 작용하면 브랜드에 대한 신뢰와 충성도는 빠르게 하락할 수 있다.

UX 심리학 시작하기

이번 글에서는 자이가르닉 효과, 부메랑 효과 등 몇 가지 이론을 예시로 소개했다. 각 이론을 서비스 설계에 어떻게 적용할 수 있을지에 대한 정보는 온라인상에 파편화되어 흩어져 있는 경우가 많다. 그래서 케이스 스터디를 하듯이, 직접 이론과 사례를 연결해 탐구하는 방식으로 학습해보길 추천하고 싶다. 그 출발점이 될 수 있도록, 요즘IT에 올렸던 사용자 심리 분석 케이스 스터디 글을 몇 가지 소개한다.

UX 심리학 분석 케이스 스터디

바이오필릭 디자인: 부장님이 주말마다 등산 가자는 이유
다크패턴, 프레이밍 효과, 후광 효과: 나도 모르는 사이, 내 일상이 생중계 된다면
몰입 차트, 고정 행동 보상, 무작위 보상, 저장된 가치, 매몰비용 감옥: 사용자를 중독시키는 UX 전략
다크패턴, 후회 회피 편향, 인지 부조화: 테무의 구매 유도 다크패턴 4종 세트
프레이밍 효과, 가변 보상, 밴드웨건 효과, 새출발 효과: “지난 1년, 당신은?” 사용자 사로잡는 데이터 결산 UX에 숨은 심리학
호손 효과: 타인의 눈을 의식하는 ‘호손효과’
스토리텔링 효과, 권위 편향, 확증 편향, 후광 효과: 스탠리 텀블러 역주행에 숨은 UX심리학

주제별 이론과 사례를 살펴보다 보면 특히 흥미롭거나 공감되는 지점이 생길 수 있다. 그 지점에서 출발해 추가 사례를 찾아보거나, 해당 이론과 연결되는 또 다른 원리를 조사하는 방식으로 사용자 심리에 대한 이해를 넓혀나갈 수 있을 것이다. 특정 이론을 기반으로 기존 서비스의 리디자인 전략을 구상해 보는 것도 좋은 케이스 스터디가 된다.

이론을 검색할 때는 영어 원문으로 구글링하는 편이 더 정확하고 풍부한 정보를 얻는 데 도움이 되고, 검색 결과로 나오는 다양한 해외 아티클을 참고해 보는 것도 좋다. 이처럼 하나의 이론에서 출발해 직접 탐구하고 적용하는 과정을 반복하다 보면, 심리학 이론은 단순한 지식을 넘어 서비스 설계에 활용할 수 있는 사고의 틀이자 실용적인 도구가 될 수 있을 것이다.

마치며

피그마 메이크(Figma Make), 구글 AI 스튜디오(Google AI Studio), 스티치 AI처럼 UI 시안을 생성해 주는 AI 도구는 많다. 잠깐 프롬프트를 입력할 시간만 있으면, 순식간에 수십 개의 화면을 만들어낼 수도 있다. 결과물만 놓고 보면, 마치 AI가 모든 일을 대신해 주는 것만 같다.

하지만 실제 AI와의 협업 과정을 들여다보면 이야기는 다르다.

UX 디자이너와 AI의 협업 과정 <출처: 작가>

먼저 어떤 결과를 원하는지 인간이 정확한 명령어를 입력해야 하고, AI가 만들어낸 수많은 출력물 가운데 무엇을 선택할지, 또 어떻게 다듬을지를 의사결정하는 과정 역시 인간의 몫이다. 이 지점에서 여러 가지 인지 심리학 이론은 논리적인 근거로 작동하며 중요한 역할을 할 수 있다.

언제나 무엇이 더 설득력 있는 문구인지, 어떤 흐름이 더 사용자의 이해를 높이는지, 또 어떤 요소가 시각적으로 더 잘 받아들여지는지에 대한 판단은 사용자에 대한 이해에서 비롯된다.

]]>

프로젝트 매니저가 n8n으로 개발 문해력 높이는 방법

노코드 자동화 툴 n8n, 들어보셨나요?

n8n은 오픈 소스 기반의 로우코드(Low-Code)를 지향하는 워크플로 자동화 도구로, 약 350개 이상의 온라인 서비스 연결을 지원하며 다양한 업무 프로세스를 자동화할 수 있도록 돕는 플랫폼입니다. 유사한 기능을 제공하는 SaaS 기반의 Zapier나 Make와 같은 노코드 자동화 도구도 있지만, n8n은 셀프 호스팅을 제공하고 코드(자바스크립트)를 삽입할 수 있어 보다 사용자 친화적인 환경을 제공합니다.

n8n 워크플로 자동화 <출처: n8n>

아마 저와 같은 비개발자일수록 이러한 노코드 기반 도구에 관심이 많을 거로 생각합니다. 다만 n8n은 Zapier나 Make와 같은 툴과 달리 약간의 기술적 이해가 필요해 처음 사용하는 분들에게는 조금 어렵게 느껴질 수 있습니다.

하지만 최근 n8n의 클라우드 환경에 AI 워크플로 빌더(AI Workflow Builder) 기능이 추가되면서, 간단한 자연어 기반 채팅만으로도 워크플로를 구성할 수 있게 되었습니다. 이러한 기능이 사용의 진입 장벽을 낮추고 아이디어를 빠르게 프로토타입으로 전환하는 데 도움을 주며, 그 결과 다른 도구들에 비해 더 많은 비개발자들이 n8n을 선택하게 될 것으로 보입니다.

프로젝트 매니저인 내가 n8n의 매력에 빠진 이유

저는 그전부터 n8n 사용에 많은 관심을 가져왔습니다. 프로젝트 매니저로서, 프로젝트를 관리하며 그동안 슬랙, 지라, 서비스 나우, MS Office 등 다양한 도구의 자동화 기능을 사용해 보았지만, 이들 툴 내 자체 자동화 플로우만로는 연속적인 워크플로를 만들기에 부족했습니다. 특히 사용하는 프로젝트 도구가 다른 서비스와의 연동을 지원하지 않거나, 인터페이스 구현을 위해 추가 인증이나 개발이 필요한 경우가 많아 항상 ‘반쪽짜리’ 자동화를 사용한다고 느꼈습니다.

약 350개 이상, n8n과 통합할 수 있는 서비스들 <출처: n8n>

그런 맥락에서 n8n은 달랐습니다. 별도의 개발 없이도 워크플로 자동화를 위해 다양한 서비스를 쉽게 통합할 수 있었고, 시각적으로 데이터 흐름을 보여준다는 점도 인상적이었습니다. 최근에는 다양한 AI 모델을 연결해 RAG를 구성하거나, 여러 AI 서비스를 비교적 쉽게 구축할 수 있다는 점까지 더해져 마치 마법과 같다고 생각했습니다.

n8n은 동작하는 HLD

n8n을 본격적으로 공부하기 전, 이 도구가 제 업무에 어떤 의미를 가져다줄지 먼저 생각해 보았습니다. 특히 프로젝트를 관리하는 사람이 어떤 목적에서 n8n을 공부해야 하고, 실제 업무에 어떻게 활용할지 말이죠.

그렇게 n8n의 전체 플로우를 살피다 보니, 최근 진행한 여러 시스템을 통합해 데이터 플로우를 구축해야 하는 프로젝트가 떠올랐습니다. 파트너 시스템부터 자사 내 마지막 ERP 시스템까지, 10개가 넘는 프로덕트 팀과의 통합 작업이 필요했습니다. 그만큼 이해관계자가 많아, 상당한 커뮤니케이션 비용이 투입될 수밖에 없었습니다. 이로 인해 대부분의 미팅은 각기 다른 목적과 스펙을 가진 시스템을 어떻게 연동할지에 대한 논의로 채워졌습니다. 그 과정에서 일정 지연과 범위 변경에 대해, 현업에 있는 비즈니스팀을 설득하기 위한 추가적인 커뮤니케이션도 필요했습니다.

결국 이 프로젝트의 본질은 새로운 데이터 플로우를 구축하는 일이었습니다. 그러나 목표를 달성하기 위해 가장 많은 시간을 들인 부분은 다양한 프로덕트 담당자들이 데이터 흐름을 이해하고 시스템 간 통합을 위해 소통하고 협의하는 과정이었습니다.

이때 효과적이고 생산적인 커뮤니케이션을 위한 여러 전략 중 하나로, 많은 프로젝트 매니저는 프로젝트를 한눈에 볼 수 있는 문서를 작성해 활용합니다. 저 역시 프로젝트 당시 잘 정리된 하나의 HLD(High Level Diagram)를 만들어, 전체 아키텍처부터 데이터 플로우까지 쉽게 설명할 수 있었습니다. 이 문서는 커뮤니케이션 비용을 줄이는 매우 전략적인 무기로 활용되었습니다.

제가 파악한 n8n은 마치 동작하는 HLD와 같았습니다.

작동하는 n8n 워크플로 <출처: Artificial Engineering>

정적인 2차원의 HLD에서 한 뎁스 더 들어가, 이것저것 설정하면 HLD가 실제로 동작하며 인풋과 아웃풋까지 보여주는 경험을 할 수 있어 보였습니다. 또, n8n을 공부하며 자동화 워크플로를 만들어가는 과정은, 다양한 서비스를 통합하는 방법은 물론 데이터 플로우 구성에 필요한 여러 지식을 습득할 기회가 될 것이라 느꼈습니다.

그래서 n8n이라는 도구를 직접 경험해 보기로 했습니다. 표면적인 HLD 이면에 존재하는 조금 더 기술적이고 상세한 HLD의 단계들, 예를 들어 시스템의 데이터를 보내기 위한 인증, 데이터 포맷, 트랜스포메이션, 전송 방식과 그 결과 등 여러 단계를 직관적으로 파악해 더 넓은 인사이트를 얻고 싶었습니다. 또한 서로 다른 수준의 기술적 지식과 업무를 가진 이해관계자들 역시, 하나의 시각적인 HLD로 더 잘 커뮤니케이션하며, 프로젝트의 목표를 보다 효과적으로 달성하고자 했습니다.

n8n으로 개발 문해력을 높인 5단계 활용법

n8n을 사용해 보겠다고 결심한 순간, 곧바로 n8n 사이트에 접속해 가입하고 트라이얼(Trial)로 사용을 시작했습니다. 자동화하고 싶은 다양한 업무 아이디어를 적용해 보고 싶었지만, 회사의 보안 정책으로 인해 당장 업무 관련 도구를 연동할 수는 없었습니다. 이후에는 n8n 사이트 접근 자체도 제한되었습니다.

결국 ‘내 PC에서 개인적인 서비스를 만들어 보자’고 생각하게 되었고, 세 줄 일기를 입력하면 AI가 아이들이 읽을 수 있는 동화책을 생성해 주는 서비스를 만들어 보기로 결정했습니다.

첫 번째 단계. 워크플로 디자인해 보기

먼저 AI로 동화책을 생성하기 위해 어떤 워크플로가 필요한지 고민했습니다. 그 결과, 크게 세 가지 주요 이벤트를 정리할 수 있었습니다.

첫 번째는 AI가 동화책을 만들 수 있도록 정보를 제공하는 입력 단계로, 사용자가 세 줄 일기와 관련 이미지를 입력할 수 있어야 했습니다. 두 번째 이벤트에서는 입력된 정보를 가져와 프롬프트와 함께 AI가 동화를 생성하는 작업이 필요했습니다. 마지막으로 생성된 동화 내용을 결과로 받아 사용자에게 전달하는 단계가 있어야 했습니다. 그에 맞춰 입력은 구글 폼으로 받고, AI 모델로는 구글 제미나이를 사용하며, 동화책을 생성한 다음 그 결과는 지메일로 전달하도록 구성했습니다.

이를 위해 n8n에서 관련 서비스들을 하나씩 찾아 생성해 보았는데요. 서비스 자체를 추가하는 과정까지는 큰 문제가 없었지만, 각 서비스를 연결하는 단계에서 어려움에 부딪혔습니다. 노드(Node)마다 크리덴셜(Credential)을 연결하고, 익스프레션(Expression) 등 다양한 설정값을 입력하라는 안내가 나왔지만, 서비스들을 어떤 방식으로 써야 할지 감이 잡히지 않았습니다.

결국 Claude를 실행해 도움받기 시작했습니다.

두 번째 단계. AI 어시스턴트로 n8n 이해하기

물론 Claude가 직접 n8n의 워크플로에 접근해 확인하고 답변해 줄 수는 없습니다. 그래서 화면을 캡처해 공유하고 원하는 프롬프트를 입력하며 스무고개처럼 가이드를 받아야 하는 불편함은 있었습니다.

그럼에도 Claude와 대화를 이어가며 각 서비스를 어떻게 연결해야 하는지를 점차 이해할 수 있었습니다. 특히 이 대화로, n8n으로 자동화 플로우를 만들기 위해서는 크게 아래 세 가지 주요 관점에 대한 이해가 필요하다는 점을 알았습니다.

뭘로 만들지?
어떻게 연결하지?
언제 실행시키지?

1. 뭘로 만들지?

이 영역에서는 노드(Node)와 커넥션(Connection)이라는 n8n의 두 가지 용어를 이해해야 합니다.

노드: 워크플로를 구성하는 각각의 단계로, 특정 기능이나 작업을 수행하는 모듈입니다. AI 모델에 프롬프트를 입력하거나, 메일을 보내고, 데이터를 처리하는 등 기능을 수행하거나 트리거를 발생시킬 수 있습니다.
커넥션: 워크플로 안에서 노드들을 서로 연결하는 선을 의미하며, 이 선을 따라 데이터가 흐르면서 플로우를 분기하거나 결합할 수 있습니다.

즉, 다양한 노드를 각각 ‘무엇으로 만들지’가 정해지면, 커넥션으로 노드들을 연결하게 되고, 이렇게 구성된 전체 프로세스를 워크플로(Workflow)라고 부릅니다.

2. 어떻게 연결하지?

여기서는 각 노드를 연결하는 크리덴셜(Credentials)에 대한 이해가 필요합니다.

n8n은 크리덴셜이라는 인증 방식을 통해 외부의 다양한 서비스(Google, Notion, Slack 등)와 연결할 수 있도록 관리합니다. 각 플랫폼에서 제공하는 API 키라든지 인증에 필요한 정보를 생성한 다음, 이를 n8n 크리덴셜에서 등록하고 관리하는 구조입니다. 워낙 다양한 서비스와의 통합을 지원하다 보니, 크리덴셜을 별도로 관리하는 화면도 줍니다.

n8n 크리덴셜 페이지 <출처: 작가>

3. 언제 실행시키지?

마지막으로 알아야 할 개념은 실행(Execution)입니다. 노드 단위로도 실행할 수 있고, 전체 워크플로를 대상으로 한 엔드 투 엔드(E2E) 실행도 가능합니다.

노드 실행으로는 실제 인풋과 아웃풋 데이터를 확인할 수 있으며, 전체 실행을 통해서는 성공인지 실패인지, 데이터는 무엇이 오갔는지에 대한 상세 로그를 확인할 수 있습니다. 이를 바탕으로 디버깅이 가능하고, 그렇게 만든 워크플로는 활성화를 통해 운영 모드로 전환할 수 있습니다.

이처럼 저는 새로운 툴을 접할때 별도 튜토리얼이나 가이드를 보지 않고 바로 실행하며 개념을 어렵게 익히지만, 독자분들은 저처럼 시간을 낭비하지 않기 위해서도 이러한 기본 개념들은 미리 확인하면 좋을 것 같습니다.

n8n Cheat Sheet <출처: n8n Community>

세 번째 단계. AI와 함께 하나씩 연결해 보기

1. 구글 폼(앱 스크립트) > n8n 웹훅(Webhook) 노드

동화책 생성 n8n 워크플로 1. 구글 폼 데이터 전달 <출처: 작가>

n8n은 앱이나 웹과 같은 UI를 퍼블릭에 배포할 수 없다는 한계가 있습니다. 이 때문에 많은 사람이 쉽게 세 줄 일기를 입력할 수 있도록, 입력 수단으로 구글 폼을 사용하기로 했습니다.

이처럼 사용자가 구글 폼에 입력한 데이터를 n8n으로 전달하기 위해서는 웹훅 노드를 활용해야 했습니다. n8n 웹훅으로 데이터를 받으려면, 구글 폼에서 데이터를 전달할 수 있는 이벤트를 만들어야 합니다. 이를 위해 구글 앱 스크립트를 활용해 간단한 함수를 작성하고, n8n에서 제공하는 웹훅 URL과 연결해 데이터를 전달하도록 했습니다.

특히, 웹훅이라는 용어는 들어보기만 했지 실제로 연동해 본 것은 이번이 처음이었습니다. 이 과정을 통해 이벤트가 발생했을 때 지정된 URL로 HTTP POST 요청을 보내, 데이터를 실시간으로 전달하는 웹훅의 기술적 동작을 이해할 수 있었습니다.

구글 폼 입력 앱스크립트 <출처: 작가>

2. 웹훅 노드 > AI 노드(feat. 구글 제미나이)

동화책 생성 n8n 워크플로 2. 스토리 생성 <출처: 작가>

다음 단계에서는 구글 폼으로부터 입력받은 데이터를 구글 제미나이(Gemini)로 보내 동화책을 만들어 달라고 프롬프트로 요청하는 노드를 구성했습니다. 이때 구글 제미나이에 프롬프트를 전달하기 위해서는 API 기반의 크리덴셜 설정이 필요했습니다. 쉽게 말해 인증 절차를 구성하는 과정인데요. Google AI Studio에서 API 키를 발급받아 인증을 설정할 수 있었습니다.

인증이 완료되면 해당 노드에 필요한 프롬프트를 입력하고, API 폴링(polling)을 통해 실행 결과를 받아올 수 있습니다. 이 과정을 거치며 API 인증 방식 중 하나인 키(Key) 기반 인증 단계를 이해할 수 있었습니다. 특히 서버 간 단순 API 호출에서는 API 키를 활용해 요청을 처리한다는 점, 또한 API 콜로 요청이 발생할 때마다 실행되는 구조를 더 구체적으로 이해하게 되었습니다.

3. AI 노드 > Code 노드 > Gdrive 노드 > HTTP Request (feat. Hugggingface)

동화책 생성 n8n 워크플로 3. 이미지 생성 <출처: 작가>

AI로 생성된 동화 내용뿐 아니라, 구글 폼으로 전달받은 이미지를 또 다른 이미지 생성 모델에 전달하는 작업도 준비했습니다. 이를 위해 자바스크립트 기반으로 아웃풋 데이터를 분기하는 로직을 추가했습니다.

이는 Claude가 제안한 대로 별도 데이터베이스를 만드는 대신, Gdrive에 이미지를 저장한 다음 이를 다시 꺼내 이미지 모델 API로 전달하는 방식을 따랐습니다. 이때 노드의 커넥션을 복잡하게 분기하기보다는, 로직으로 데이터를 분기하고 단방향으로 전달하는 게 더 효과적이라고 판단했습니다. 다만 그렇게 노드와 커넥션을 만들고 나니, 후속 데이터 처리를 위해 추가적인 Code 노드를 생성해야 했습니다.

나중에 돌아보며 굉장히 비효율적인 구조라는 것을 깨달았지만, Code 노드를 통해 약간의 자바스크립트 지식만으로도 데이터를 다양한 방식으로 변형하고 전달할 수 있다는 점을 알게 되었습니다.

한편, 무료로 이미지를 생성할 수 있는 AI 모델을 찾던 중 오픈 소스 모델을 제공하는 Hugging Face를 알게 되었습니다. 구글 제미나이와 마찬가지로 Hugging Face 사이트에서 API 키를 발급받아 크리덴셜 설정을 진행했습니다. 안타깝게도 n8n에서는 Hugging Face 전용 API 노드를 제공하지 않기 때문에, HTTP Request 노드를 사용해 Body에 JSON 형식으로 이미지와 프롬프트를 전달하도록 설정해야 했습니다.

4. HTTP Request(API) > Code 노드 > Gmail

동화책 생성 n8n workflow 4. 이메일 전달 <출처: 작가>

마지막으로 Hugging Face API로 받은 동화 이미지를 기존의 동화 내용과 병합(Merge)하고, 이메일 발송을 위한 HTML 포맷까지 더한 Code 노드를 만들었습니다. 이후 Send an email 노드를 통해 최종 결과를 이메일로 전달하도록 설정했습니다. 역시 Gmail 크리덴셜 연결이 필요합니다.

n8n으로 생성한 동화책 이미지와 내용 <출처: 작가>

이처럼 여러 시행착오를 거치며, AI가 세 줄 일기로 동화책을 만들어 주는 하나의 워크플로를 완성할 수 있었습니다. 이제는 구글 폼에 정보를 입력하고 제출하기만 하면, AI가 자동으로 동화책을 생성해 제 이메일로 전달해 줍니다. 겉보기에는 간단해 보이는 서비스였지만, 이 워크플로를 만들기 위해 총 9개의 노드와 서비스 연동, 인증 설정, 코드 작성 과정을 거쳐야 했습니다. 생각했던 것보다 작업에 꽤 많은 시간이 들었지만, 그만큼 짧은 시간 안에 시스템 통합과 데이터 전달에 대한 기술적인 지식을 효과적으로 이해할 수 있었습니다.

무엇보다 2차원적으로만 바라보던 제 HLD 분석 능력이 각 단계의 기술적 내용을 이해하고 나니 발전해, HLD 뒤에 숨어 있던 연결고리까지 조금씩 눈에 보이기 시작한 것 같았습니다.

네 번째 단계. n8n 클라우드 AI 워크플로 빌더 활용해 보기

사실 Claude를 활용해 며칠간 동화책을 열심히 만들고 있다 보니, n8n에 AI 워크플로 빌더라는 기능이 출시되었습니다. 다른 AI 어시스턴트와 유사하게, n8n의 워크플로 화면을 IDE처럼 활용해 대화하며 원하는 프로토타입을 빠르게 구축할 수 있는 기능이었습니다.

AI 빌더를 직접 실험해 보려고, 등록해 둔 RSS 사이트를 정리해 매일 아침 9시에 메일로 보내는 기본 자동화를 만들어 달라고 요청했는데요. 이런 수준의 간단한 워크플로는 다른 AI 챗봇처럼 정말 뚝딱 생성해 주었습니다. 물론 필요한 크리덴셜과 같은 부분은 여전히 직접 설정(setup)해야 했지만, 어떤 절차로 해야 하는지 아주 상세하게 가이드해 주기 때문에 더 쉽고 빨랐습니다. 저처럼 다른 AI 어시스턴트의 도움을 받지 않아도, n8n 안에서 바로 실행할 수 있다는 점에서 더욱 효과적으로 느껴졌습니다.

그래서 이 AI 빌더로 앞서 제가 만들어 둔 워크플로를 개선해 보고자 했습니다. 기존 워크플로를 가져와 임포트(import)하고, 동화 생성 영역과 이미지 생성 영역을 나눠 개선해 달라고 요청했습니다. 그러자 정말 몇 초 만에, 더 나은 워크플로를 생성해 주길래, 그동안의 고생이 조금은 허무하게 느껴지기도 했습니다.

AI 빌더를 사용한 동화책 생성 n8n 워크플로 개선 <출처: 작가>

마지막 단계. n8n 셀프 호스팅으로 클라우드(Cloud) 운영해 보기

n8n을 알아가다 보니 클라우드 서비스를 비용을 지불하지 않고 셀프 호스팅(Self-Hosting) 방식으로 사용할 수 있다는 점을 알게 되었습니다. n8n의 여러 버전 중 커뮤니티 에디션을 사용하면, 월 사용료를 내지 않고도 직접 자신의 클라우드 환경에서 운영할 수 있습니다. 일석이조의 기회라 생각하며 호기롭게 시작해 보았습니다.

셀프 호스팅 방법은 n8n사이트 공식 문서에 상세히 작성되어 있으며 NPM, Docker으로 설치할 수 있습니다.

GCP(Google Cloud Platform) n8n Project <출처: 작가>

1. 개인 PC에 셀프 호스팅하기

일단 n8n에서 추천하는 Docker 기반 설치 방식을 선택했습니다. 저는 클라우드 서비스에 대한 기초적인 지식만 있을 뿐, Docker나 컨테이너는 한 번도 써보지 않았지만, 일단 무지성 시작해 보기로 했습니다.

클라우드 환경은 GCP(Google Cloud Platform)였고, AI 에이전트의 도움을 받아 가며 한 땀 한 땀 Docker와 컨테이너 환경을 구성해 n8n을 설치해 나갔습니다. 처음으로 SSH(셸 스크립트) 명령어를 직접 입력하는 등 우여곡절이 많았습니다. 특히 명령어 기반 CLI 환경이 처음이다 보니, 명령 순서를 잘못 입력하거나 예기치 못한 에러가 발생했을 때 어디서 문제가 생겼는지 추척하지 못해 시간을 많이 소요하기도 했습니다. 그럼에도 여러 시행착오를 거친 끝에, 로컬 호스트에서 n8n을 실행하는 데까지 도달할 수 있었습니다. (아마 Docker와 클라우드 서비스에 익숙한 분들이라면 몇 시간이면 충분히 끝낼 수 있는 작업일지도 모르겠습니다.)

2. 서비스 형태로 제공하기

이처럼 어렵게 셀프 호스팅에 성공하고 나니 자연스럽게 욕심이 더 생겼습니다. 단순히 내 PC에서만 사용하는 수준을 넘어, 웹사이트 형태로 만들어 어디서든 서비스에 접속하도록 만들고 싶어졌습니다. 그래서 Cloudflare에 n8n 서비스를 위한 도메인을 만들고, 인터넷만 있으면 언제든 접근할 수 있도록 구성했습니다.

도메인 기반으로 사이트를 운영하면서 예상치 못한 일들이 많았는데요. 저만 사용하는 사이트였기 때문에 CPU나 API 사용량이 많지 않아야 했는데, 간혹 사용량이 최대치(max)에 가까워지며 사이트 접속이 불가능해지고, 예상보다 비용이 더 발생하는 일들이 생겼습니다. GCP 콘솔에서 트렌드와 로그를 모니터링하니, 해외 봇이 사이트를 공격하고 있다는 것도 알게 되었습니다.

이를 막기 위해 보안 설정을 강화하고 알람을 추가로 설정하는 과정까지 경험하니 인프라를 직접 운영하는 데 따른 고충(?)을 이해할 수 있었습니다. 그동안 팀 내 솔루션 아키텍트가 이야기하던 효율화 방안이나 개선 제안들에 대해 이전보다 훨씬 깊이 공감하게 된 계기이기도 했습니다.

이런 노력에도 결과적으로 제가 만든 도메인은 회사 방화벽에 막혀 집에서만 사용하게 되었지만, 그 과정 자체만으로도 충분히 값진 경험이었다고 생각하며 긍정 회로를 돌리고 있습니다.

마치며

비개발자로서 언젠가는 개발을 더 깊이 이해하고, 스스로 동작하는 기능을 만들어 보고 싶다는 막연한 생각만 해왔습니다. 이번에 n8n을 통해 기술 지식을 비교적 쉽게 이해하고, 나만의 워크플로를 직접 자동화해 볼 수 있었던 경험은 생각보다 큰 도움이 되었습니다. 특히 이번 과정은 결과물 그 자체보다도, 시스템 간 연동 방식과 내부 동작 구조를 하나하나 직접 연결하고 이해하는 과정에서 더 많은 배움을 얻을 수 있었습니다.

요즘은 n8n뿐만 아니라 다양한 AI 어시스턴트로 코딩에 대한 진입 장벽이 빠르게 낮아지고 있다고 느낍니다. 이러한 환경 속에서 저와 같은 비개발자들도 직접 경험하고 시도해 볼 수 있는 기회를 가져보셨으면 합니다. 제 글이 그런 시도의 시작이 되기를 바랍니다.

]]>

1년 만에 전략 바꾼 네이버: 기획자에게 던지는 메시지는?

1년 만에 네이버의 전략이 대폭 수정되었다. 네이버는 매년 열리는 DAN을 통해 다음 해의 핵심 방향을 공식적으로 발표한다. 2024년 DAN의 주요 내용을 살펴보면 검색, 쇼핑, 지도 등 개별 서비스에 AI를 적용해 좀 더 스마트한 편의를 제공하겠다는 것이 주요 내용이었다. 그리고 2025년, 올해 DAN의 핵심 키워드는 'Agent N'이다. 네이버의 검색, 쇼핑, 예약 등 모든 서비스를 유기적으로 연결해 사용자의 의도를 파악해 제안하고, 실행, 대행하는 통합 AI 비서로 진화하겠다는 내용이다. 왜 1년 만에 전략이 이렇게 달라진 걸까?

<출처: 팀네이버 컨퍼런스 DAN25>

네이버의 달라진 전략은 기술적 자신감을 보여줬다기보단 '각개전투'로는 더 이상 시장에서 살아남기 힘들다는 절박함의 메시지로 읽힌다. 네이버는 단순 정보 중개자에서 문제 해결자로서 실행하겠다는 의지를 반영한 목소리기도 하다. 사용자는 더 이상 10개의 탭을 씌우면서 검색하길 원치 않는다. “2살 아기가 체험하기 좋은 장소를 예약해 줘”라는 한마디로 모든 과정이 다 완결되길 원한다. 네이버는 완결형 에이전트로서 사용자의 의도를 처음부터 끝까지 책임지는 방향으로 전략을 세우고 있다.

그러나 완결형 에이전트가 작동하기 위해서는 필수 조건이 있다. 바로 내부와 외부의 연결이다. 검색부터 쇼핑, 예약, 결제까지의 경험이 끊김 없이 이어져야 하고, 외부 전문 서비스와의 유기적 연결도 필요하다. 내부가 유기적으로 연결되지 않으면 뛰어난 에이전트가 있어도 서비스별로 흩어져 작동할 수밖에 없다. 이 지점에서 우리는 질문을 다시 던질 수밖에 없다. Agent N 같은 ‘완결형 실행’ 시대에 우리는 무엇을 고민해야 할까?

‘완결형 실행’ 에이전트의 등장, 우리는 무엇을 고민해야 할까?

[팀네이버 컨퍼런스 DAN25] Keynote 01: 검색을 넘어 실행까지: 사용자 경험의 진화 <출처: 작가 캡처>

1) 사용자 경험은 탐색 중심에서 목표 중심으로 이동하고 있다

과거의 검색은 일종의 놀이이자 호기심의 영역이었다. 맛집을 찾기 위해 블로그를 뒤지고, 지도를 살펴보고, 리뷰를 비교하는 과정은 번거롭더라도 발견의 즐거움이 있었다. 사용자는 불확실성을 줄이기 위해 여러 탭을 열어두고 정보를 비교하는 수고를 기꺼이 감수했다. 탐색 그 자체가 경험의 일부였기 때문이다. 그러나 에이전트 시대가 열리면서 사용자의 인식은 근본적으로 달라졌다.

이제 사용자는 검색창 앞에 앉아 있는 시간을 비용으로 인식한다. '내가 이만큼 검색했으면 반드시 최적의 답이 나와야 해.' 이런 심리는 손실 회피와 맞물려 더욱 강력해졌다. 사용자의 시간, 노력, 인지적 에너지는 모두 투자 자원이며 그에 걸맞은 확실한 결과가 나오지 않으면 실패로 인식된다. 그래서 사용자가 "마곡역 조용한 카페 찾아 줘"라고 말할 때 원하는 것은 카페 리스트 10개가 아니다. 그중에서 실패하지 않을 단 하나의 확신 있는 선택이며 가능하다면 예약까지 끝난 상태다. 과업의 완수가 최종 목표가 된 것이다.

사용자를 오랫동안 머무르게 하는 대신 사용자가 투입한 최소한의 질문에 대해 가장 정확하고 실행 가능한 결과물을 즉시 제시함으로써 사용자의 자원 대비 효율을 극대화하는 것이다. 플랫폼의 경쟁력도 자연스럽게 바뀐다. "얼마나 많은 정보를 나열하느냐."가 아니라 "사용자의 목표 달성 확률을 얼마나 높여주는가"가 핵심이 되고 있다.

[팀네이버 컨퍼런스 DAN25] Keynote 01: 검색을 넘어 실행까지: 사용자 경험의 진화 <출처: 작가 캡처>

2) KPI는 완결률과 전환 연결성이 된다

통합 에이전트의 성공을 측정하기 위해서는 핵심 성과가 완전히 새로운 지표로서 필요하다. 기존 개별 에이전트 서비스를 기획했을 때는 체류시간이나 PV(Page View)와 같은 KPI를 중요하게 생각했다면 보다 다양한 에이전트 간 연결이 중요해진 시점에선 다른 형태의 KPI가 필요하다. 구체적으로는 한 서비스에서 다른 서비스로 전환했을 때의 성공률이나 세션당 과업 완결률, 전환 시도 같은 것들이 새로운 지표로 부상할 필요가 있다. 사용자를 한 서비스 안에 가둬두는 지표 대신 얼마나 타 에이전트 간 연결을 성공시켰는지, 처음부터 끝까지 과업 완결률이 얼마나 되는지를 주목해서 바라볼 필요가 있다.

3) 연동만 하는 서비스는 생존할 수 없다

사용자의 의도와 데이터를 쥐지 못한 채 그저 연결만 하는 방식은 현실적으로 냉정하게 조직의 존폐 위기를 걱정해야 할 수도 있다. 존재가 없어질 수도 있고, 뺏길 수도 있기 때문이다. 플랫폼의 근간은 결국 '트래픽을 붙잡아두는 것'이 아니라, 사용자가 왜 움직이는지를 파악하고 그 의도를 기반으로 여정을 설계하는 능력이다. 의도를 쥐지 못한 채 트래픽만 외부로 흘려보내는 순간, 돈보다 중요한 고객 경험의 소유권이 함께 넘어갈 위험이 커진다. 이 접점을 잃는다면 조직의 미래도 흔들릴 수밖에 없다.

네이버가 Agent N 전략으로 전환한 이유 중 하나는 그동안의 “단순 연동” 방식이 이미 한계에 다다랐기 때문이다. 외부 서비스와 기능을 가져다 붙이기만 하면, 표면적으로는 연결된 것처럼 보인다. 그러나 정작 중요한 사용자의 의도와 행동 데이터 흐름을 통제하지 못한다. 트래픽을 외부로 보낸다는 행위 자체가 아니다. 문제는 왜 보내는지, 어떤 목적의 여정인지 그 뒤에 어떤 실행이 이어지는지 플랫폼이 파악하지 못한 채 사용자를 흘려보내는 방식에 있다.

이렇게 ‘맥락 없는 연결’이 반복되면 플랫폼은 단순히 입구 역할만 하는 존재로 전락한다. 트래픽뿐 아니라, 고객 경험의 주도권까지 함께 넘어가며 결국 “대체 가능한 서비스”가 되고 만다. 플랫폼의 위험은 바로 여기서 시작된다. 반면, 사용자의 의도와 여정을 정확히 읽어내고 그 흐름을 기반으로 가이드-추천-예약-결제까지 완결형 실행을 책임지는 방향은 전혀 다른 차원의 경쟁력이다. Agent N이 단순 연동을 넘어 실행형 에이전트로 전략을 바꾼 이유도 바로 이런 ‘연결의 주도권’을 회복하기 위함이다.

하지만 실행만으로 주도권이 확보되는 것은 아니다. 주도권의 실질적 기반은 결국 '깊이 있는 데이터'에 있다. 이것은 단순히 데이터가 많은 상태가 아니라, 남들이 돈을 주고서라도 사고 싶어 하는 상품 그 자체로서의 데이터다. 이런 데이터는 희소성과 시의성이 있고, 독자적 가치가 있는 데이터다. 플랫폼이 생존하려면 결국 '누군가 살만한 데이터'를 만들어내야 한다. 현재 우리 조직이 만들고 있는 데이터와 서비스는 정말 사람들이 돈을 내서라도 선택할 만큼의 경쟁력을 갖추었는지 냉정하게 되돌아볼 필요가 있다.

[팀네이버 컨퍼런스 DAN25] Keynote 01: 검색을 넘어 실행까지: 사용자 경험의 진화 <출처: 작가 캡처>

4) 플랫폼의 최종 경쟁력은 ‘전문성’이 아니라 ‘연결력’이다

네이버는 모든 것을 적당히 잘하는 통합형 앱이고 쿠팡이나 오늘의 집 같은 곳은 하나의 영역을 깊게 파고드는 전문 서비스이다. 네이버가 이들과 전문성 대결을 벌이는 것은 필패 전략이다. 그러나 탐색의 시작 지점에서는 네이버가 강력한 우위를 가진다. 네이버는 탐색의 거대한 좌판이기 때문이다.

거대한 탐색의 좌판이 열려 있고, 사용자는 네이버라는 좌판에서 출발해 전문 서비스로 이동한다. 네이버 Agent N의 전략은 '전문 서비스 대체'가 아니라, '전문 서비스와의 연결'이다. 네이버의 역할은 실행이 아니라 발견과 탐색의 초입이며, 사용자의 여정은 ‘처음(발견/탐색) → 네이버 중간(의도 파악과 조율) → 전문 서비스의 실행/관리 → 다시 네이버에서의 통합’이라는 순환 구조를 띠게 된다.

결국 Agent N의 성패는 얼마나 많은 기능을 AI로 대체하느냐가 아니라, 얼마나 많은 파트너를 생태계 안으로 끌어들이고, 이 여정을 하나의 흐름으로 연결할 수 있느냐에 달려 있다. 네이버가 전문성의 깊이를 전부 확보할 수 없다면, 차라리 그 깊이를 가진 파트너와 협력해 탐색–조율–실행–관리라는 전체 경험을 하나의 내러티브로 묶어내는 것이 더 현실적이고 강력한 전략이다.

이런 흐름 속에서 기획자와 디자이너가 가져야 할 역량도 달라지고 있다. 화면 자체의 완성도를 높이는 것보다 서비스와 서비스 사이를 어떻게 이어 줄 것인지, 사용자의 맥락과 의도를 어떻게 유지한 채 이동시키는지가 더 중요한 능력이 되고 있다. 사용자를 플랫폼 내부에 붙잡아두는 것이 아니라 필요한 전문 서비스로 자연스럽게 보내고, 다시 네이버가 통합 관리의 허브가 되는 구조를 설계하는 '연결 UX’가 새로운 표준이 되고 있다.

네이버가 A부터 Z까지 모든 서비스를 깊이 있게 키우는 것은 사실상 불가능하다. 각 영역의 전문 플랫폼들은 이미 자신들만의 압도적인 데이터와 경험의 깊이를 확보하고 있고, 사용자는 이제 단순한 탐색이 아니라 맥락에 맞춘 정보와 실행까지 한 번에 이어지는 경험을 기대한다.

이 변화 속에서 가장 먼저 바뀌어야 하는 것은 조직의 태도이다. 부서마다 따로 움직이는 사일로 구조로는 연결 중심 생태계를 구현하기 어렵다. 내부 성과 지표에 머물러서는 사용자의 전체 여정을 설계할 수 없다. “우리는 언제든 대체될 수 있다”라는 현실적 긴장감을 바탕으로 연결과 속도, 실행 중심의 사고방식으로 전환해야 한다.

<출처: Unsplash, Hal Gatewood>

마치며

이제 플랫폼의 가치는 전문성을 독식하는 데서 나오지 않는다. 생태계를 지휘하고 사용자의 여정을 매끄럽게 이어주는 연결의 힘에서 나온다. Agent N은 이러한 전략적 전환의 신호탄이며, 앞으로 플랫폼의 경쟁력은 “얼마나 많은 기능을 갖고 있는가”가 아니라, “얼마나 자연스럽게 연결을 만들어 완수할 수 있는가”에서 결정될 것이다.

<참고>

https://dan.naver.com/25/about

]]>

AI 시대를 위한 바이브 기획은 어떤 모습이어야 하는가?

이 글은 ‘리오랩(매니패스트)’이 제작하고, 요즘IT가 기업 제휴 콘텐츠로 소개합니다.

지난 1편과 2편에서는 AI 시대에 우리가 왜 여전히 재작업 지옥에 사는지에 대해 이야기했습니다. 간단히 요약하자면, 1편에서는 아무리 AI 코딩 툴이 발전해도, 기획서 자체가 모호하면 쓰레기가 들어갔을 때 쓰레기가 나오는 GIGO(Garbage In, Garbage Out) 문제를 피할 수 없다는 것을 확인했습니다. 또한 2편에서는, 이 모호한 기획이 만들어낼 수 있는 문제는 단순히 개발 효율을 떨어뜨리는 것을 넘어, 프리랜서와 SI 기업의 비청구시간(Non-billable Hours)을 늘리고 수주율을 떨어뜨리는, 즉 우리의 돈 문제와 직결되어 있음을 다루었습니다.

그렇다면 이런 고질적인 문제를 해결하기 위해, AI 시대의 기획은 과연 어떤 모습이 되어야 할까요?

1, 2편에서 그토록 강조했던 기획력을 실제로 향상시키기 위해, 우리는 무엇을 해야 할까요? 오늘 3편에서는 기존의 방식이 아닌, AI 시대에 걸맞은 새로운 기획의 모습인 바이브 기획(Vibe Planning)이 어떤 모습이어야 하는지, 그 구체적인 원칙과 방법론을 제시하고자 합니다. 이를 통해 저희 매니패스트가 바라보고 있는 방향을 설명하고, 매니패스트가 어떤 기획용 AI 도구로 여러분들에게 다가갈 것인지 말씀드리고자 합니다.

1. 죽은 기획서의 3가지 한계

우리는 왜 AI라는 강력한 무기를 손에 쥐고도 여전히 재작업과 소통 비용에 시달릴까요?

문제는 우리의 기획 도구가 20년 전과 본질적으로 달라지지 않았기 때문입니다. 우리는 여전히 파워포인트(PPT), 엑셀, 워드를 사용합니다. 물론 최근에는 노션과 피그마같이 더 나은 도구들이 기획 작업에 추가되기도 했습니다. 하지만 이 발전된 도구들로 우리가 예전보다 더 잘하게 된 것은, 그저 더 깔끔하고 예쁜 그림과 도형을 그리는 능력뿐입니다.

AI가 코드를 짜주는 시대에도, 이 죽은 기획서들은 다음과 같은 3가지 명확한 한계를 가지며, 저희는 이것을 IT 프로젝트에서의 대부분의 재작업 지옥의 근본 원인이라고 판단하고 있습니다.

한계 1: 파편화(Fragmentation)

우리 IT 프로젝트의 현실을 들여다봅시다. 정보구조도(IA)는 엑셀에, 서비스 정책은 컨플루언스 (Confluence)에, 화면 플로우차트(Flowchart)는 PPT나 FigJam에, 상세 화면정의서는 노션이나 PPT에, 그리고 개발 태스크는 Jira에 흩어져 있습니다. 각각의 도구들은 정말 유용하고 강력합니다. 하지만 이 도구들이 모두 파편화되어 있다는 사실이 우리의 기획 작업에 거슬리는 장애물이 된다는 것이 문제입니다.

모든 기획의 핵심 산출물이 서로 다른 파일과 시스템에 파편화되어 흩어져 있는 것, 이것이 모든 비극의 시작입니다. 기획 핵심 산출물이 파편화되면 될수록, 우리 프로젝트의 집중력도 파편화될 수밖에 없거든요.

온갖 툴을 가지고 곡예를 부리다 보면, 가끔은 사고가 날 수밖에 없다. <출처: 작가, ChatGPT 생성>

한계 2: 수동 동기화(Manual Synchronization)

프로젝트 도중 갑작스럽게 ‘추천인 코드’ 기능이 추가되었다고 가정해 봅시다. PM은 이제 이 하나의 변경 사항을 반영하기 위해, 엑셀로 만든 IA 문서를 열어 수정하고, PPT로 만든 플로우차트를 찾아 수정하고, 노션에 작성 중인 화면정의서를 다시 고쳐야 합니다.

만약 이 과정에서 단 하나라도 빠뜨리면 어떻게 될까요? 예를 들어, PM이 바쁜 나머지 PPT 플로우차트는 수정했지만 엑셀 IA 시트는 깜빡하고 수정하지 않았다고 해봅시다. (추후에 받게 될 온갖 질책과 한숨은 일단 모르는 척 넘어가겠습니다.)

개발자는 파편화된 문서들 간의 불일치를 해독하느라 시간을 낭비합니다. 혹은 더 나쁘게도, 잘못된 버전의 기획서를 바탕으로 개발을 진행하다가 추후에 그 사실을 알게 됩니다. 몇 번 잘못된 버전의 기획서로 개발하는 실수를 저지르고 나면, 기획자와 기획서에 대한 불신을 키우게 되겠죠. 이 불신은 결국 프로젝트 전체의 소통 비용을 기하급수적으로 증가시킵니다.

한계 3: 비구조화(Unstructured)

가장 치명적인 한계입니다. GitHub Copilot 같은 AI 코딩 툴은 PPT 장표나 엑셀 시트에 담긴 논리 구조를 이해할 수 없습니다. AI에게 이것은 그저 예쁜 그림이나 의미 없는 텍스트 덩어리일 뿐입니다.

LLM이 아무리 발전했다고 하더라도, AI는 여전히 명확하게 구조화된 데이터를 다룰 때 그 진가를 발휘합니다. 현재 우리의 기획서는 AI가 읽고 이해할 수 있는 데이터라기 보다는, 사람이 눈으로 봐야만 하는 문서에 가깝습니다. 그러니 결국 기획자가 작성한 기획서를 개발자들은 다시 기계가 읽을 수 있는 구조화된 데이터로 변환하는 과정을 거쳐야 하지요.

그러니까 내 말을 이해한다는 게 무슨 말인지 이해해? <출처: 작가, ChatGPT 생성>

2. 살아있는 기획서: 바이브 기획의 5가지 원칙

저희는 이 죽은 기획서의 문제를 근본적으로 해결하고, AI가 IT 프로젝트 전체에 깊숙이 관여하는 현재 시대에 어울리는 기획을 바로 바이브 기획이 향해야 할 방향이라고 생각하고 있습니다. 또한 바이브 기획이 기획서를 문서가 아닌 살아있는 시스템으로 바라보게 만드는 접근 방식이며, 다음과 같은 5가지 원칙을 가져야 한다고 생각합니다. 이 5가지 원칙은 앞으로 저희가 계속해서 고도화시켜 나갈 방향이자 목표 그 자체입니다.

원칙 1: 통합(Integrated)

IA, 플로우, 화면, 명세서는 처음부터 끝까지 하나의 시스템 안에서 유기적으로 관리되어야 합니다.

예를 들어, IA에서 ‘회원가입’ 화면의 이름을 ‘유저 등록’으로 바꾸는 순간, Flowchart와 화면정의서에 포함된 모든 ‘회원가입’이라는 이름이 실시간으로 ‘유저 등록’으로 바뀌어야 합니다. 이것이 바로 수동 동기화의 지옥에서 탈출하는 첫걸음입니다. 앞으로 나올 바이브 기획 도구가 우리에게 쓸모가 있으려면, 우선적으로 이 통합의 원칙을 충족해야 할 것입니다.

“어? IA랑 화면설계랑 메뉴 이름이 다르네요?” “네?” <출처: 작가, ChatGPT 생성>

원칙 2: 구조화(Structured)

기획서는 단순한 문서가 아니라 데이터베이스여야 합니다. 기획서에서 ‘회원가입’은 단순한 문자여서는 안 됩니다. 개발자들과 디자이너에게, 그리고 그들이 프로젝트에 활용하는 AI 도구들에 익숙한 데이터베이스여야 합니다. 다시 말해, 기획서에서 ‘회원가입’은 [화면 ID: SCR-001], [연결 기능: F-001, F-002], [정책: P-001] 등의 명확한 속성을 가진 하나의 객체(Object)여야 합니다.

또한 사람의 창의적이고 비정형적인 아이디어를 기획서로 옮기는 과정에서, 필연적으로 일정 부분 비정형적인 부분이 기획서에 남을 수밖에 없습니다. 분명 깔끔하게 썼다고 생각한 기획서인데, 개발자들이 기획서를 이해하지 못하고 수도 없이 질문하는 경우를 많이 보셨을 겁니다. 바로 기획서가 본질적으로 어느 정도 주관적일 수밖에 없기 때문이죠. 다른 사람도 정확히 이해하기 힘든 것이 기획서인데, 하물며 기계는 어떨까요?

이제 기획을 글쓰기의 영역이 아닌 데이터 설계의 영역으로 가져온다면, AI의 도움으로 기획서를 완전히 정형적으로 쓸 수 있게 된다면 사람이 해독해야 하는 기획서가 아닌 기계가 이해할 수 있는 기획서를 쓰는 시대가 시작될 것입니다.

기획서는 객관적으로 구조화되어야 한다. 무엇보다도 더. <출처: 작가, 매니패스트 화면에서 캡쳐>

원칙 3: 기계 가독성(Machine-Readable)

기획이 객체로 구조화된다면(원칙 2), AI 툴도 드디어 기획서를 이해할 수 있게 될 것입니다. 아주 단순하게 말한다면, 우리는 AI에게 "SCR-001(회원가입) 화면에 필요한 API 엔드포인트 초안을 짜줘" 또는 "F-001(이메일 중복 확인) 기능의 테스트 케이스를 10개 만들어줘"라고 할 수 있어야 한다고 생각합니다.

물론 실제 프로젝트에서는 이것보다 훨씬 복잡한 명령을 내리고, 수행해야 할 것입니다. 하지만 그렇게 복잡한 명령을 내리고 수행하려면, 애초에 기획 단계에서부터 기계가 이해할 수 있는 언어로 기획되어야 할 것입니다. 자연어로 코딩을 하는 AI 바이브 코딩 시대라고는 하지만, 바이브 코딩을 해보신 분들은 모두 아실 겁니다. 기계에게 프로젝트의 맥락을 이해시키기 위해 프롬프팅을 수도 없이 하다 보면, 이게 내가 직접 코딩을 하는 것보다 빠르긴 한 건가 하는 생각이 드는 순간을요.

기계가 읽을 수 있는 기획서를 만들어내는 바이브 기획의 시대가 도래한다면, AI가 그저 텍스트 뭉치를 읽고 추론하는 것이 아니라, 구조화된 데이터를 읽고 논리적인 코드를 생성할 수 있을 것입니다. 우리가 꿈꾸는 진정한 바이브 코딩은 아마도 이러한 바이브 기획과 함께 도래하지 않을까요?

매니패스트에서 작성한 기획서는 MCP를 활용해 Lovable 등으로 옮길 수 있습니다! <출처: 작가, 매니패스트>

원칙 4: 버전 관리(Version-Controlled)

기획서_v1_final_진짜최종.pptx 같은 파일명은 이제 정말로 그만둘 때가 온 것 같습니다.

왜 개발자들은 모두 버전 관리를 자연스럽게 받아들이고 있는데, 기획자들은 항상 final과 진짜 최종과 찐찐최종을 만들어야 할까요? 앞으로는 모든 기획서 역시 변경 이력은 Git 커밋처럼 자동으로 추적되고 관리될 필요가 있습니다. 개발자가 "어제 기획서랑 오늘 뭐가 바뀐 거죠?"라고 PM에게 물어보거나, 기획서를 두 장 열고 변화된 부분을 확인하거나, 기획자가 변경된 부분마다 파란색으로 색칠하는 시대는 이제 끝나야 합니다. 그저 시스템에 접속해 어제와 오늘의 변경분(Diff)만 확인하고 즉시 작업에 반영할 수 있어야 합니다.

원칙 5: 검증(Validated)

마지막으로, 저희는 코딩을 하기 전에 기획 단계에서 컴파일할 수 있어야 한다고 생각합니다.

기획이 하나의 시스템으로 통합되고 구조화된다면, 시스템이 기획의 논리적 오류를 자동으로 검증할 수 있을 것입니다. 예를 들어, "‘로그아웃’ 버튼에서 ‘로그인’ 화면으로 가는 플로우가 빠졌네요" 또는 "결제 플로우에 죽은 링크가 존재합니다" 같은 오류를 코딩이 시작되기 전에 시스템이 자동으로 경고해 줄 수 있어야 합니다. 저희가 생각하는 바이브 기획의 최종 단계에서는, AI를 활용하여 IT 프로젝트에 기획과 개발과 디자인 사이의 벽을 허물어 버릴 수 있을 것입니다.

3. 실전 비교: ‘추천인 코드’ 재작업 지옥 탈출기

이제 1편에서 언급했던 ‘추천인 코드’ 추가 시나리오가, 이 두 가지 다른 기획 방식 하에서 어떻게 전개되는지 구체적으로 비교해 보겠습니다. 1편을 안 보셨더라도 걱정하지 마세요. 우리에게 아주 익숙한 시나리오입니다. 처음에는 구글/네이버/카카오 로그인만 가능하면 된다고 했던 클라이언트가, 개발 도중에 갑자기 회원가입 시 추천인 코드 입력 기능도 넣어주실 수 있냐고 물어보는 상황이거든요.

Before: 죽은 기획서 (PPT/엑셀)

고객이 슬랙으로 PM에게 "회원가입 시 추천인 코드 입력 기능을 넣어주세요"라고 요청합니다.
PM은 알겠다고 답한 뒤, 엑셀(IA), PPT(플로우), 노션(정의서) 3개의 파일을 엽니다.
3개의 문서를 각각 수정하며 수동으로 동기화 작업을 시작합니다.
그러다 중간에 다른 급한 업무가 끼어들어, PPT(플로우) 수정을 빠뜨리고 맙니다.
PM은 팀원들에게 "추천인 코드 기능 추가됐습니다. 도저히 방어할 수 없었습니다. 죄송합니다. 노션 참고해 주세요"라고 공지합니다.
개발자는 노션(정의서)만 보고 DB 스키마를 고치고 API를 개발합니다.
하지만 개인적인 사정으로 PM과의 회의에서 약간 집중력이 부족했던 디자이너는, 엑셀(IA)만 보고 옛날 플로우가 반영된 디자인 시안을 전달합니다.
개발이 끝난 뒤 디자인을 입히는 과정에서야 플로우가 꼬인 것을 발견하고, 대참사가 벌어집니다. 재작업이 발생합니다.

기획서에 무언가가 누락된 것을 나중에 발견하게 되는 것만큼 소름끼치는 일이 없다. <출처: 작가, ChatGPT 생성>

After: 바이브 기획(5가지 원칙)

고객이 PM에게 동일한 요청을 합니다.
PM은 통합 기획 시스템에 접속합니다.
'추천인 코드 입력'이라는 화면 객체(Object)를 새로 만듭니다. (원칙 2: 구조화)
'회원가입 플로우'에 '추천인 코드 입력' 객체를 드래그하여 연결합니다.
이 작업 즉시, IA와 플로우차트, 화면 목록이 자동으로 변경됩니다. (원칙 1: 통합)
이때 시스템이 PM에게 경고를 보냅니다. "경고: '추천인 코드' 기능에 대한 '유효성 검증' 정책이 정의되지 않았습니다." (원칙 5: 검증)
PM은 경고를 확인하고, '추천인 코드 유효성 검증' 정책을 상세히 정의한 뒤 'v1.2'로 커밋합니다. (원칙 4: 버전 관리)
개발자와 디자이너는 "v1.2 변경 내역" 알림을 받습니다. 두 사람 모두 '추천인 코드'가 추가된 동일한 버전의 기획서를 시스템에서 확인하고 동시에 작업을 시작합니다.
재작업은 발생하지 않습니다.

우리가 실수로 누락한 것을 발견하는 것보다 AI가 잘하는 것이 있을까? <출처: 작가, ChatGPT 생성>

4. 결론: 곧 바이브 기획이 우리에게 찾아올 겁니다

AI 시대의 기획 작업은 더 이상 ChatGPT에게 "기획서 초안 좀 써줘"라고 부탁하는 수준에 머물러서는 안 됩니다. AI를 기획에 더 적극적으로 활용해야 하는 것은 맞지만, 그것은 정확히 기획만을 위해 개발된 기획 시스템 위에서 이루어져야 합니다. AI가 우리의 기획을 더 효과적으로 돕게 하려면, AI가 이해할 수 있는 명료하고 구조화된 기획서를 만드는 것이 선행되어야 합니다. 그리고 이 구조화된 기획서를 만드는 속도는, 바이브 기획 시스템의 도움을 받을 때 훨씬 더 빨라질 것입니다.

이러한 바이브 기획의 도입은 단순히 기획자 한 명의 생산성을 높이는 것을 넘어, IT 프로젝트 전체의 생산성을 폭발적으로 향상시키는 핵심 열쇠가 될 것입니다.

<참고>

manyfast.io/blog

]]>

카피일까, 벤치마킹일까? 베끼지 않고 재해석하는 법

혹시 이런 고민 해보셨나요?

새로운 서비스를 기획할 때마다, 경쟁사의 성공 사례를 어디까지 참고해야 할지 헷갈린다.
“이건 카피일까, 벤치마킹일까?” 사이에서 균형을 잡기 어렵다.
벤치마킹 보고서는 많지만, 정작 우리 팀만의 방식으로 재해석하는 힘이 부족하다.
매번 “잘 만든 걸 참고했다”는 말로 시작하지만, 돌아보면 남의 성공을 그대로 복제한 건 아닐까 하는 불안이 남는다.

이번 글에서는 이러한 고민을 해본 기획자, PM, 전략 담당자들을 위해, ‘성공을 복제하지 않고 재해석하는 법’, 즉, 벤치마킹을 진짜 학습으로 바꾼 사례를 살펴보고자 한다.

‘망고노트’ 사태가 남긴 질문

<출처: 망고노트 링크드인>

2025년 9월, AI 회의록 서비스 ‘망고노트’가 사업 종료를 발표했다. 한때 엔비디아 인셉션 프로그램에 선정되며 기술력을 인정받았던 팀이었지만, 영국 스타트업 ‘그래놀라(Granola)’의 디자인과 코드를 그대로 가져왔다는 논란이 불거지며 결국 서비스를 내렸다.

망고노트 팀은 사과문에서 “처음엔 내부 학습용으로 만든 사이드 프로젝트였다”고 고백했다. 본업이 있는 개발자 몇 명이 모여 연습 삼아 시작한 프로젝트가 예상보다 빠르게 주목받았고, 그 과정에서 디자인 변경을 미루다 외부 공개까지 이어졌다는 것이다. 결과적으로 “시작부터 복제의 흔적이 있었던 서비스”로 남았다. 이 일은 스타트업 업계에서 가볍게 넘길 일이 아니었다. 요즘 대부분의 기업은 다른 서비스와 성공 사례를 참고한다. 그런데 어떤 팀은 그 과정을 통해 혁신을 만들고, 어떤 팀은 ‘베끼는 기업’이라는 낙인이 남는다.

그 차이는 어디서 생길까? 겉모습을 가져오는 것과, 성공의 이유를 이해하는 것은 전혀 다른 일이다. 겉모습을 따라 하는 건 쉽지만, 속을 이해하는 건 어렵다. 결국 중요한 건 ‘얼마나 빨리 베꼈는가’가 아니라 ‘얼마나 깊이 이해했는가’다. 망고노트 사태는 이 차이를 선명히 보여준 사건이었다. AI 스타트업들이 직면한 현실, ‘빨리 만들어야 살아남는다’라는 압박과, ‘차별화하지 않으면 존재 이유가 없다’라는 모순이 정면으로 부딪친 것이다.

이번 글은 바로 그 지점에서 출발한다. ‘우리는 어디까지 참고하고, 어디서부터 새로 만들어야 하는가?’ 이 질문에 답하기 위해, 우리는 ‘벤치마킹의 진화 4단계(The 4 Stages of Benchmark Evolution)’ 프레임워크를 통해 모방이 어떻게 학습으로, 학습이 어떻게 창조로 바뀌는지를 살펴볼 것이다.

<출처: 작가, GPT Image>

결국 혁신은 남의 아이디어에서 시작할 수 있지만, 그 아이디어를 자신의 언어로 다시 쓰는 순간 비로소 의미를 생긴다. 망고노트의 사례는 우리에게 묻는다. 지금 우리는 ‘따라 하는 팀’인가, ‘배워서 새로 만드는 팀’일까?

Copy vs Benchmark, 이름은 비슷하지만 길은 다르다

누구나 한 번쯤은 이렇게 말한다. “저 서비스처럼 만들면 잘 될 것 같아요.” 하지만 이 말 속에는 두 가지 길이 숨어 있다. ‘그대로 베끼는 길’과 ‘이유를 분석하는 길’이다.

<출처: 작가, GPT Image>

‘카피(Copy)’는 눈에 보이는 결과를 그대로 가져오는 것이다. 빠르게 비슷한 제품을 만들고, 시장 반응을 확인하며, 단기 성과를 얻는다. 겉으로는 효율적이고 영리해 보인다. 하지만 한 발만 더 들어가 보면, 그 기반엔 이해보다 속도가 앞선 선택이 있다. 결국 뿌리가 얕은 복제는 작은 변수에도 흔들리기 쉽다.

반면, ‘벤치마킹(Benchmarking)’은 다르다. 겉모습을 흉내 내는 대신, 그들이 왜 성공했는지를 분석한다. 디자인을 보기 전에 그 디자인이 만들어진 이유를, 기능을 보기 전에 그 기능이 등장한 맥락을 살핀다. 즉, 결과가 아니라 원리를 가져오는 일이다.

예를 들어보자. 스타트업이 경쟁사의 앱을 따라 만든다면 그것은 카피다. 하지만 그 경쟁사가 고객을 유지하는 이유, UI 배치가 전환율에 미치는 영향을 분석하고 이를 자사 환경에 맞게 바꾼다면, 그건 벤치마킹이다. 두 행동은 비슷해 보이지만, 출발점이 다르다.

<출처: 작가, GPT Image>

카피는 손이 먼저 움직인다. 벤치마킹은 머리가 먼저 움직인다. 전자는 결과를 재현하고, 후자는 과정을 이해한다. 결과적으로 하나는 ‘비슷한 무언가’를 만들고, 다른 하나는 ‘새로운 무언가’를 만든다. 하지만 실제 현장에서는 이 둘의 경계가 자주 흐려진다. 특히 스타트업 세계에서 “참고했다”는 말은 “베꼈다”와 “배웠다” 사이의 회색지대에 놓여 있다. 한쪽에서는 속도를 위해, 다른 한쪽에서는 생존을 위해 ‘영감’이라는 이름으로 모방이 반복된다.

문제는 복제가 아니라, 복제에 머무는 태도다. 카피는 출발점일 수 있다. 하지만 거기서 멈추면, 결국 다른 누군가의 길을 대신 걸을 뿐이다. 벤치마킹은 그 길을 참고하되, 자신의 방향을 새로 그린다. 결국 두 단어의 차이는 기술이 아니라 사고의 깊이에 있다. 카피는 눈앞의 형태를 가져오고, 벤치마킹은 그 형태를 만든 이유와 맥락을 가져온다. 그래서 한쪽은 빠르지만 금세 잊히고, 다른 한쪽은 느리지만 오래 남는다.

다음 장에서는 이 차이가 실제로 어떻게 드러나는지를 ‘벤치마킹의 진화 4단계(The 4 Stages of Benchmark Evolution)’를 통해 구체적으로 살펴보자. 그 단계 속에는 우리가 흔히 놓치는 질문이 숨어 있다.

“지금 우리는 남의 것을 흉내 내고 있는가, 아니면 배워서 새로 만들고 있는가?”

벤치마킹의 진화 4단계

누군가는 결과를 복제하고, 누군가는 원리를 이해해 새롭게 만든다. 이 차이를 구체적으로 나누면 ‘벤치마킹의 깊이’로 설명할 수 있다. 벤치마킹은 한 가지 행동이 아니다. 그 깊이에 따라 네 단계로 진화한다. 표면을 베끼는 단계에서 출발해, 원리를 재해석하고 새로운 시장을 만드는 단계로 나아간다.

이 프레임워크는 단순한 구분표가 아니라, 기업이 지금 어디에 서 있는지 돌아보게 하는 거울이다.

<출처: 작가>

① 복제형(Copy)

<출처: 망고노트, 그래놀라 공식 홈페이지>

복제형은 가장 빠르지만 가장 짧게 끝나는 단계다. 망고노트처럼 눈에 보이는 디자인과 코드를 그대로 가져와 서비스를 만드는 방식이다. 초기 반응은 빠를 수 있다. 하지만 결국 신뢰를 잃고 시장에서 사라진다. 결과를 가져오는 것에 그쳤기 때문이다. 복제형의 문제는 ‘무엇을 만들었는가’보다 ‘왜 만들었는가’를 모른다는 점이다.

② 응용형(Adaptive)

<출처: 카카오페이손해보험 링크드인>

응용형은 단순 복제를 벗어나, 성공 모델을 살짝 변형하는 단계다. 예컨대, 카카오페이손해보험의 UX를 경쟁사가 유사하게 구현하면서 논란이 됐던 사례가 있다. 응용형은 시장 반응을 빠르게 얻을 수 있지만, 차별화가 약하다. 결국 남의 설계를 조금 바꾼 결과물에 머물 가능성이 높다. 하지만 이 단계는 중요한 의미가 있다. 복제의 한계를 깨닫고 “우리 방식은 무엇인가”를 고민하기 시작하는 지점이기 때문이다.

③ 학습형(Learning)

<출처: 현대자동차그룹 스토리>

학습형은 단순 변형을 넘어 성공의 원리를 내재화하는 단계다. 1970~1990년대 현대자동차와 미쓰비시의 관계가 그 전형적인 사례다. 현대차는 처음엔 미쓰비시로부터 엔진과 변속기 등 핵심 기술을 배웠다. ‘포니’ 개발 당시에는 부품을 들여와 조립하는 수준이었지만, 그 과정에서 생산관리·품질관리·대량생산의 시스템적 원리를 학습했다.

1980년대에는 단순 도입에서 벗어나 활용과 공동개발로 진화했다. 미쓰비시 기술을 그대로 쓰지 않고, 현대차의 환경에 맞게 조정하며 점차 자립도를 높였다. 결정적 변화는 1990년대 초반, 현대차가 엔진 국산화에 성공하며 미쓰비시 의존에서 벗어난 것이다. 이 시점부터는 일본식 생산방식을 그대로 따르지 않고, 노사 구조에 맞는 ‘모듈화·자동화 중심의 자체 생산방식’을 확립했다. 즉, 현대차는 배운 것을 그대로 옮긴 것이 아니라, 이해하고 소화해 자기 언어로 바꾼 기업이었다.

④ 창조형(Creative)

<출처: 네스프레소 공식 홈페이지>

창조형은 완전히 새로운 시장을 여는 단계다. 네스프레소는 커피 브랜드였지만, 아이디어의 출발점은 화장품 매장이었다. “제품이 아니라 경험을 판다.” 이 한 문장이 커피 문화를 바꿨다. 커피머신 기능보다 고객의 체험에 집중하면서, 커피를 파는 브랜드에서 경험을 디자인하는 브랜드로 진화했다. 창조형 벤치마킹은 타 산업의 원리를 가져오되, 그대로 쓰지 않는다. 남의 방식을 흡수해 자신만의 시장 논리로 바꾸는 과정이다. 이 단계에 도달한 기업은 더 이상 ‘누구처럼’이라는 말로 설명되지 않는다. 새로운 기준을 만드는 팀이 된다.

결국 이 네 단계는 시간의 순서가 아니라 사고의 깊이를 보여준다. 복제형에서 창조형으로 갈수록, 중요한 건 기술이 아니라 ‘이해의 밀도’다. 많은 기업이 복제형과 응용형 사이에서 멈춘다. 그러나 진짜 경쟁력은 학습형과 창조형에서 만들어진다. 남의 성공을 흉내 내는 데서 멈추지 않고, 그 원리를 자기 언어로 해석해 내는 기업만이 오래 살아남는다.

다음 장에서는 이 네 단계가 실제로 어떻게 나타나는지를 각 사례를 중심으로 구체적으로 살펴본다. 그 과정에서 우리는 한 가지 질문에 다시 마주하게 된다.

“지금 우리 팀은 어느 단계에 머물러 있는가?”

경계가 흐려지는 이유: 왜 우리는 자꾸 카피를 정당화할까?

복제와 벤치마킹의 차이는 머리로는 알지만, 현실에선 자주 뒤섞인다. 특히 빠르게 움직여야 하는 산업일수록 그 경계는 더 흐려진다. “참고했다”는 말은 어느새 “조금 베꼈다”와 같은 뜻이 되고, “영감을 받았다”라는 말은 “거의 그대로 가져왔다”라는 핑계가 된다. 그 이유는 단순하지 않다.

<출처: 작가>

첫째, 속도의 압박 때문이다.
스타트업에게 시간은 생명이다. 남보다 늦게 출시하면 기회가 사라지기에, 검증된 모델을 빠르게 복제하는 유혹이 커진다. 하지만 속도를 이유로 본질을 건너뛰면, 결국 시장에 똑같은 제품만 남는다.

둘째, 문화적 습관의 영향이다.
한국 기업들은 오랫동안 ‘벤치마킹의 나라’로 불려 왔다. 배우고 따라잡는 능력은 세계 최고지만, 그 과정에서 ‘창조의 단계’로 넘어가는 시도를 종종 잊는다. “빨리 배우는 게 잘하는 것”이라는 인식이 “빨리 베끼는 것도 괜찮다”로 변질되기 쉽다.

셋째, 법과 제도의 한계다.
UI, UX, 비즈니스 모델은 법적으로 보호받기 어렵다. 그래서 “법 위반은 아니다”라는 말로 도덕적 논란을 덮는 경우가 많다. 하지만 시장은 법보다 냉정하다. 고객은 결국 ‘비슷한 것’이 아닌 ‘진짜 다른 것’을 선택한다.

마지막으로, 힘의 비대칭이 존재한다.
자본과 인력이 풍부한 대기업은 신생 기업의 아이디어를 복제해도 법적·경제적 부담이 적다. 이 불균형이 반복되면, “카피도 전략이다”라는 잘못된 학습이 업계 전반에 퍼진다.

결국 우리는 이렇게 자꾸 경계를 흐리며 스스로를 설득한다. “이건 베낀 게 아니라 효율이야.”, “시장 진입을 위한 전략일 뿐이야.”라고 말이다. 하지만 진짜 문제는 모방 자체가 아니라, 거기서 멈추는 태도다. 속도를 이유로 원리를 생략하는 순간, 기업은 성장 대신 반복에 갇힌다. 혁신은 모방에서 시작할 수 있지만, 그다음 단계로 나아가려는 의지가 없으면 아무 의미가 없다.

카피하지 않으려면 무엇을 해야 할까?

비슷한 시장, 비슷한 고객, 비슷한 기술 속에서도 어떤 팀은 유사해 보이고, 어떤 팀은 전혀 다르게 보인다. 그 차이는 속도가 아니라 질문의 깊이에서 생긴다. 아이디어는 누구나 낼 수 있지만, 그 아이디어가 진짜 ‘우리의 것’이 되려면 묻고, 검증하고, 다듬는 과정이 필요하다.

다음 다섯 가지 질문은 현업에서 ‘이건 카피일까, 벤치마킹일까?’를 스스로 점검할 수 있는 체크리스트이다.

<출처: 작가>

① 이 아이디어는 우리 고객의 문제를 해결하는가?

성공 사례를 참고할 때 가장 흔한 실수는 ‘고객’이 아니라 ‘사례’를 중심에 두는 것이다. 남의 성공은 그들의 고객을 위한 것이지, 우리의 고객을 위한 것은 아니다. 벤치마킹의 시작은 ‘어떤 서비스가 잘됐는가’가 아니라, ‘우리 고객이 이 서비스가 필요한 이유가 무엇인가’여야 한다.

② 참고한 대상의 핵심 원리를 이해했는가?

표면만 보고 따라 하면 모양은 달라도 결과는 같다. 벤치마킹의 목적은 복제가 아니라 작동 원리의 이해다. 그 기능이 왜 존재하는지, 어떤 문제를 해결하는지, 그 맥락을 이해하지 못한 채 구현하면 결국 다른 문제를 낳는다.

③ 우리가 추가한 차별화 포인트는 무엇인가?

차별화 포인트는 거창한 혁신이 아닐 수도 있다. 하나의 워딩, 하나의 기능 구조, 하나의 사용자 흐름이라도 “이건 우리 팀만의 선택이다”라고 설명할 수 있다면 충분하다. 그 작은 차이가 복제와 재해석을 가르는 결정적 기준이 된다.

④ 설명이 필요한가, 변명이 필요한가?

아이디어를 제안하거나 결과물을 리뷰할 때, “이건 어디서 본 것 같다”는 피드백이 나올 수 있다. 그때 우리는 설득하고 있는가, 아니면 해명하고 있는가? 설명은 방향을 공유하는 것이고, 변명은 흔적을 감추는 것이다. 만약 해명에 가깝다면, 이미 벤치마킹이 아닌 카피로 가고 있는 상태다.

⑤ 이 결과물을 처음 보는 사람이 ‘우리답다’고 말할 수 있는가?

브랜드는 결국 ‘다름의 언어’다. 아무리 완성도가 높아도, 우리만의 철학이나 톤이 느껴지지 않으면 그건 그냥 또 하나의 복제품일 뿐이다. 처음 보는 사람이 “이건 그 회사 스타일이네”라고 말할 수 있다면, 그건 이미 카피가 아닌 해석된 결과물이다.

이 다섯 가지 질문은 개인의 감각이 아니라 팀의 의사결정 기준으로 자리 잡을 때 더 큰 힘을 가진다. 아이디어 회의나 벤치마킹 리뷰 때, 다음과 같은 루틴을 만들어보자.

회의 안건에는 ‘무엇을 참고할까’가 아니라, ‘왜 참고해야 하는가’를 함께 기록한다.
기획 문서에는 반드시 ‘참고 대상’과 ‘차별 포인트’를 함께 기록한다.
유사 서비스 비교표에는 ‘복제 위험도’ 항목을 추가한다.
프로젝트 리뷰 시, “이 부분이 남의 것처럼 보이지 않게 하려면?”을 질문으로 남긴다.

복제를 피하려면 남의 답을 가져올 게 아니라, 우리 팀만의 질문을 세워야 한다. 같은 시장과 기술 속에서도 다른 결과가 나오는 이유는 프로덕트 기획에 쓰이는 생각의 깊이에 있다. 결국 차별화는 선택의 문제가 아니라, 이해의 결과다.

마치며

모든 혁신은 모방에서 출발할 수 있다. 하지만 거기서 멈추면, 남의 궤적을 되풀이할 뿐이다. 카피는 손으로 할 수 있지만, 벤치마킹은 마음가짐으로만 가능하다. 망고노트의 사례는 그 경계를 분명히 보여줬다. ‘빠르게 만들자’는 의지는 있었지만, ‘왜 만들까’라는 질문은 부족했다. 그 결과, 기술은 있었지만 이유는 없었다. 그들의 실패는 단순히 법이나 윤리의 문제가 아니라, 방향성 없는 속도가 만들어낸 구조적 한계였다.

반대로, 현대자동차와 네스프레소는 망고노트와는 다른 길을 걸었다. 그들은 남의 방식을 가져오되, 그 속에서 자신만의 원리를 찾아냈다. 즉, 배운 것을 자신들의 고객에 최적화한 기업이었다. 그 차이가 바로 카피와 벤치마킹의 경계다. 지금 기업들에게 필요한 건 ‘더 빨리 베끼는 법’이 아니라, ‘고객을 더 깊이 이해하는 법’이다. 누구보다 빠르게 만들어도, 남과 다르게 생각하지 않으면 결국 같은 곳에 멈춘다. 속도보다 중요한 건 방향이고, 기술보다 중요한 건 이유다.

이번 글에서 살펴본 ‘벤치마킹의 진화 4단계’는 지금 우리가 어느 단계에 서 있는지를 묻고, 다음 단계로 넘어가기 위해 무엇을 버리고, 무엇을 새로 만들어야 할지를 생각할 수 있게 돕는다. 결국 혁신은 남의 아이디어에서 시작할 수 있지만, 그 아이디어를 자신의 언어로 다시 쓸 때 비로소 의미가 생긴다. 창조는 거창한 발명보다, 이해를 자기 것으로 바꾸려는 태도에서 비롯된다.

<참고>

체어퍼슨노트, 2013.02.18, 현대경제연구원
망고노트 공식 링크드인
Granola 공식 홈페이지
“완전히 똑같네”…삼성화재, 카카오페이손보 여행자 보험 ‘표절’ 의혹, 2024.06.21, 동아일보
포스트 '수출규제' 시대의 한일 경제관계, 2021.02.15, 학술지(일본비평)

]]>

프리랜서 하시게요? 그럼 기획을 잘 하셔야겠네요?

이 글은 ‘리오랩(매니패스트)’이 제작하고, 요즘IT가 기업 제휴 콘텐츠로 소개합니다.

혹시 프리랜서 개발자로 일하고 계신가요? 혹은, SI를 운영하고 계신가요? 그렇다면 혹시, 이번 달 돈을 받지 못한 공짜 노동은 몇 시간 정도 하셨는지 계산해 보셨나요?

저는 가끔 프리랜서 일을 하는 부업으로 친구들을 만나는데, 친구들이 이런 말을 할 때가 있습니다. “저번 주말에 한 5시간 투자해서 거의 오십만 원 받았잖아. 요즘 외주 일 꽤 쏠쏠해.” 프리랜서로 부수적인 수입을 얻는다는 것은 직장인들에게는 아주 멋진 일입니다. 단 몇십, 몇백만 원에 불과하더라도 그런 부수입은 우리들을 아주 행복하게 만들죠. 하지만 본격적으로 외주 일을 하든, 부업으로 외주 일을 하든 외주 업무의 현실은 비청구시간 (Non-Billable Hours)과의 끝없는 싸움입니다.

나도 모르게 하고 있는 공짜 노동들

외주 업무를 할 때 가장 고통스러운 시나리오를 복기해 봅시다. 열심히 클라이언트를 찾아다니고, 운 좋게 구한 예비 클라이언트와의 미팅이 성사됩니다! 두 시간 동안 열정적으로 미팅하며 클라이언트의 요구사항을 듣습니다. 집에 돌아와 세 시간을 들여 미팅 내용을 정리하고, 클라이언트의 요구사항을 분석하여 제품의 핵심 기능을 도출합니다. 이 기능은 어떻게 구현하고, 저 기능은 어떤 리스크가 있는지 혼자만의 회의를 거칩니다. 다시 한 시간을 들여 꼼꼼하게 견적서를 작성해 발송합니다. 이 정도면 클라이언트가 받아들일까? 이 정도면 내가 (혹은 우리 팀원들이) 일했을 때 손해는 아닐까? 여기까지 총 6시간. 나의 시급을 5만 원으로만 계산해도 30만 원어치의 노동입니다.

그리고 며칠 뒤, "검토 후 연락드리겠습니다."라는 정중한 메일을 받습니다. 그리고 그 클라이언트는 다시는 연락이 오지 않습니다.

결국 이 6시간의 노동은 비청구시간, 즉 순손실로 잡힙니다. 혹시 클라이언트와 계약하게 되더라도, 5시간 만에 번 줄 알았던 내 수입은 사실 11시간이 투입된 수입이었습니다. 우리가 아무리 최신 기술 스택을 마스터하고 AI로 코딩 시간을 50% 단축해도, 그것만으로는 영업 단계의 이 비청구시간을 줄이는 데는 큰 도움이 되지 않습니다.

실제로 해외 프리랜서 전문 매체 프리랜서 인포머(Freelance Informer)의 분석에 따르면, 많은 프리랜서가 업무 시간의 약 30%를 고객 확보, 행정, 제안서 작성 등 청구 불가능한 활동에 쏟고 있습니다. 이는 프리랜서가 실제로 생각하는 것보다 약 30%가량 적은 수입을 얻고 있을 수 있음을 시사합니다.

프리랜서들은 아마 그들이 생각하는 것보다 30%는 더 적게 벌고 있을 수도 있다. <출처: 프리랜서 인포머>

이 글에서는 이 고질적인 공짜 노동 시간을 유료 계약으로 바꾸는 가장 현실적이고 강력한 무기, 바로 명료한 기획력에 대해 이야기해보고자 합니다. 만일 외주 업무를 하시는 분이라면, 혹은 부업으로 외주 업무를 시도하려고 생각하셨던 분에게 좋은 아이디어가 되기를 바랍니다.

수주의 근본적인 실패 원인: 고객의 불안감

우리는 왜 수주에 실패할까요? 수많은 클라이언트 미팅이 왜 계약으로 이어지는 데 실패하는 걸까요? 우리는 클라이언트의 마음속으로 들어가 볼 필요가 있습니다.

많은 클라이언트는 IT 전문가가 아닙니다. 그들은 보통 특정 제품에 대한 아이디어와, 그 제품이 어떤 방식으로 기능할 것이라는 느낌만 가지고 있습니다. 그리고 동시에, "이 개발자가 제대로 만들어오지 않으면 어쩌지?", "내가 생각한 것과 완전히 다른 결과물이 나오면 어쩌지?" 하는 거대한 불안감을 안고 있습니다.

이 불안감을 해소하지 못하면 계약은 성사되지 않습니다. 저희는 SI를 운영하고 많은 프리랜서들을 고용하기도 하면서, 클라이언트와 미팅하는 개발자/PM들에게서 세 가지 유형을 관찰했습니다.

클라이언트의 거친 생각과 불안한 눈빛을 마주한다면… <출처: 작가, ChatGPT 생성>

유형 1: 코더(The Coder)

클라이언트: "인스타그램 같은 앱을 만들고 싶어요. 그런데 이제 특정 직업인들만 쓰는 거죠."
개발자: "아, 네. 가능합니다. 프론트엔드는 React Native로 하고, 백엔드는 Node.js와 Express, DB는 MySQL 할거구요... 예상 비용은..." (기술 설명)
클라이언트 속마음: "무슨 말이지? 이게 내가 원하는 결과를 만드는 가장 효율적인 방법이 맞긴 맞나? 이렇게 하면 내가 원하는 결과가 나오기는 하나?" (불안감 상승) → 계약 포기.

코더 유형은 기술로만 소통합니다. 고객이 원하는 것은 기술이 아니라 결과인데도 말입니다.

유형 2: 영업사원(The Salesman)

클라이언트: "인스타그램 같은 앱을 만들고 싶어요. 그런데 이제 특정 직업인들만 쓰는 거죠."
PM: "물론 가능합니다! 릴스 기능은 기본으로 넣을 수 있고, DM 기능에 AI 챗봇까지 넣을 수 있습니다. 과업 기간은 이 정도로 산정할 거구요." (과잉 약속)
클라이언트 속마음: "말은 청산유수인데... 저걸 다 하는데 이 견적이 맞나?" (의심 상승) → 계약 포기.

영업사원 유형은 언제나 예스를 남발합니다. 하지만 구체적인 실현 방안이 빠져있는 예스는 오히려 고객의 의심만 살 뿐입니다.

유형 3: 파트너(The Partner)

클라이언트: "인스타그램 같은 앱을 만들고 싶어요. 그런데 이제 특정 직업인들만 쓰는 거죠."
개발자/PM: "네, 알겠습니다. 인스타그램은 기능이 정말 많은데요. 혹시 대표님이 가장 구현하고 싶은 핵심 기능, 딱 하나만 꼽자면 무엇일까요? 1) 사진 공유 피드, 2) 릴스 같은 숏폼, 3) DM 기능 중 어떤 것인가요?" (기획 질문)
클라이언트 속마음: "아, 이 사람은 내 아이디어를 구체화하려고 노력하네." (1차 신뢰)
개발자/PM: "만약 사진 공유 피드가 핵심이라면, 유저는 가입하자마자 어떤 화면을 보게 될까요? 다른 사람의 사진일까요, 아니면 사진을 올리는 버튼일까요? 혹시 생각해 두신 게 없다면, 제 생각에는 다른 사람의 사진부터 올리고 그 다음 화면을 업로드 버튼으로 만드는 게 좋을 것 같습니다. 왜냐하면~" (심층 질문 및 전문적 견해 피력)
클라이언트 속마음: "아, 내 아이디어가 아직 모호했었구나. 이런 게 다 필요한 거였네. 이 사람이랑 일하면 되겠다." (신뢰감 상승) → 계약.

고객은 기술을 사는 것이 아니라 내 문제의 해결책을 삽니다. 그리고 그 해결책을 함께 만들어갈 신뢰할 수 있는 파트너를 삽니다. 기획 역량은 이 단계에서 고객의 불안감을 해소하고 신뢰를 심어주는 가장 강력한 영업 역량입니다.

클라이언트와의 계약 수주를 성공시키기 위하여 우리는 어떻게 해야 할까? <출처: 작가, ChatGPT 생성>

공짜 노동을 유료 계약으로 바꾸는 간단한 기획서

저희가 제안하는, 파트너형 개발자가 되어 고객 수주율을 높일 수 있는 핵심 도구는 바로 간단한 기획서입니다. 상담 단계는 개발 단계가 아니라 영업 단계입니다. 이 단계에서 고객의 불안감을 해소하고 신뢰를 주기 위해서는, 견적서 외에도 추가적인 분명한 결과물을 제시해야 합니다. 저희는 이 결과물을 보통 간단한 기획서를 클라이언트에게 제공하고 있습니다.

여기서 말하는 간단한 기획서란, 당연히 모든 화면을 정의하고 상세 정책을 설명하는 80페이지짜리 두꺼운 기획서가 아닙니다. 미팅 내용을 바탕으로 개발자가 클라이언트의 아이디어를 어떻게 이해하고 구체화했는지 보여주는 핵심 요약본입니다. 이 문서는 빠르면 미팅 후 24시간 이내, 늦어도 48시간 이내에 보내는 것이 좋습니다.

간단한 기획서의 4가지 핵심 구성

말씀드렸듯이, 간단한 기획서에는 진짜 기획서처럼 모든 내용이 다 들어갈 필요는 없습니다. 저희는 계약 성사 전에 제출하는 기획서에는 다음과 같은 핵심 내용만을 포함하여 작성합니다.

1. 프로젝트 정의 (PRD): 우리가 만들 것은 무엇인가?

이것은 프로젝트의 북극성입니다. "인스타그램 같은 앱"이 아니라, "모바일 환경에 익숙한 20대에서 40대 부동산 중개인들을 타겟으로, 사진을 바탕으로 동네 소식을 공유하고 소통하는 커뮤니티"처럼 명확하게 하는 거죠. 클라이언트의 요구사항을 이렇게 명확하게 정리함으로써 클라이언트의 신뢰를 얻을 수 있습니다.

2. 핵심 기능 명세서 (MVP): 무엇이 들어가야 하는가?

최종 제품에 포함될 모든 기능을 나열하는 것이 아닙니다. 최소한 고객과의 미팅에서 고객이 언급한 핵심 기능들과, 그리고 몇 가지 제안들을 포함하면 좋습니다. 저희는 보통 이 단계에서 MoSCoW 기법을 참고합니다.

Must-Have(필수): (예: 소셜 로그인, 사진 피드, 댓글/좋아요) - 이것 없이는 서비스가 성립하지 않음.
Should-Have(권장): (예: 마이페이지, 해시태그 검색) - 중요하지만, 1차 오픈에서 빠져도 됨.
Could-Have(고려): (예: DM 기능, 릴스) - 2차 고도화 대상.

이 분류만으로도 고객은 자신의 아이디어가 정리되는 느낌을 받습니다.

3. 정보 구조도 (IA): 어떻게 작동하는가?

메뉴들의 구조를 한눈에 보이도록 표현한 정보 구조도 <출처: 작가, 매니패스트로 제작>

Figma나 Sketch로 거창한 와이어 프레임을 그릴 필요 없습니다. 고객은 그 화면이 예쁜지 아닌지에만 집중하게 되어 본질을 놓칠 수 있습니다. 대신, 간단한 텍스트를 이용해 메뉴 구조와 사용자의 핵심 동선을 보여줍니다.

1. 홈 (피드 목록)

1-1. 피드 상세 (댓글)

2. 업로드

3. 검색(해시태그)

4. 마이페이지

4-1. 내가 쓴 글

4-2. 설정

이것만으로도 클라이언트는 자신이 의뢰한 프로젝트가 성공했을 때 받게 될 결과를 훨씬 구체적으로 상상할 수 있게 되었습니다. 고객이 그 결과를 상상하게 했다면, 계약은 한 걸음 더 다가왔습니다.

4. 기능 기반 개략 견적(The How Much): 그래서 얼마인가?

이것이 핵심입니다. "총 2,000만 원"이라는 총액 견적(Lump Sum)은 고객에게 블랙박스처럼 느껴집니다. 대신, 2번에서 정의한 핵심 기능을 기반으로 견적을 제시합니다.

소셜 로그인: 100만 원
사진 피드 (읽기/쓰기): 300만 원
댓글/좋아요: 200만 원
마이페이지: 100만 원

총계: 700만 원

이 1페이지 기획서를 견적서와 함께 보내야 합니다. 이 문서는 클라이언트에게 "나는 당신의 아이디어를 이만큼 구체화했다"는 강력한 증거이자, 당신이 코더가 아닌 파트너라는 증명입니다. 이 문서를 얼마나 빠르고 정확하게 만들 수 있는지가, 프리랜서 개발자의 비청구시간을 줄이고 수주율을 높이는 핵심 역량입니다.

명료한 기획력이 가져오는 3가지 금전적 이득

이렇게 명료한 기획서를 빠르게 작성할 수 있는 기획력은 단지 수주율만 높이는 데 그치지 않습니다. 실제 프로젝트가 시작된 후에도 개발자의 수익성을 극대화하는 3가지 강력한 이득을 가져다줍니다.

이득 1: 가격 흥정이 기능 협상이 됩니다(수주율 증가)

Before(기획서 없음): "총 2,000만 원입니다." → (클라이언트) "너무 비싸네요. 1,800에 맞춰주세요." → "아... 그러면 이번에는 1,800으로 맞춰드릴게요." (출혈 경쟁 시작)
After(기획서 있음): "총 2,000만 원입니다. 세부 사항은 기획서를 참고해 주세요." → (클라이언트) "너무 비싼데, 1,800은 안되나요?” -> “아, 그러면 댓글/좋아요 기능 구현이 200만 원인데, 일단 이걸 빼고 1차 오픈하고 반응을 보고 추가하면 어떨까요?" (구체적이고 건강한 협상 시작)

기획서는 견적의 근거가 되어 신뢰를 줍니다. 클라이언트는 더 이상 뜬구름 잡는 비용이 아니라, 기능 단위로 명확하게 예산을 조율할 수 있게 됩니다. 이는 개발자의 전문성을 높이고 불필요한 가격 할인을 막아줍니다.

이득 2: 재작업이 추가 계약이 됩니다(수익률 증가)

프로젝트 관리의 가장 큰 재앙은 스코프 크립(Scope Creep), 즉 정해진 범위를 넘어서는 추가 요구사항입니다. 프로젝트 관리 협회(PMI)의 2021년 보고서(Pulse of the Profession)에 따르면, 프로젝트의 34%가 스코프 크립을 경험했다고 합니다. SI에서 일해보시거나 프리랜서로 일해보신 분이라면 다들 경험해 보셨을 겁니다. 물론 어느 정도는 당연히 감수해야 할 부분이지만, 마주할 때마다 스트레스를 만드는 일이죠.

프로젝트의 34%는 스코프 크립을 겪는다. <출처: PMI 보고서>

가장 간단한 예시로, 이런 상황을 생각해 볼 수 있습니다. 프로젝트가 한창 진행 중일 때, 클라이언트의 슬랙이 오는 거죠. "아, K님. 저희 내부에서 논의하다가 결정된 건데, 제품 마케팅 방안으로 추천인 제도가 결정됐거든요. 혹시 회원가입할 때 추천인 코드도 입력하게 해주실 수 있나요? 간단한 수정 같은데."

Before (기획서 없음): "아... 네. 그런데 그 기능까지 구현하려면 일정이 조금 밀릴 수 있는데요..." (간단하지 않은 공짜 재작업 시작, 수익률 하락, 스트레스 증가)
After (기획서 있음): "네, 좋은 기능이네요. 다만 미팅 때 합의했던 기획서를 기준으로 보면, 추천인 코드는 견적 외 추가 작업 항목입니다. 해당 기능이 들어가려면 개발 공수 3일, 추가 견적 200만 원이 발생합니다. 계약서 추가로 진행해 드릴까요?" (유료 추가 계약, 수익률 방어)

이렇듯 업무의 시작부터 명료하게 작성한 기획서는 프로젝트의 범위를 지키는 명확한 스코프 쉴드(Scope Shield)이자 프로젝트의 기준이 됩니다. 감정적인 거절이 아닌, 객관적인 자료에 기반한 비즈니스 협의가 가능해집니다.

이득 3: 고객이 팬이 됩니다(LTV 증가)

명료한 기획으로 소통하고 약속한 범위 내에서 퀄리티를 지키는 개발자는 단순 용역이 아니라 신뢰할 수 있는 파트너로 격상됩니다. 클라이언트는 "이 사람과는 말이 통한다", "이 사람은 내 비즈니스를 함께 고민해 준다"고 느끼게 됩니다.

이런 개발자는 자연스럽게 이 고객으로부터 다음 프로젝트를 맡게 되거나, 유지보수 및 추가 작업 계약을 통해 안정적인 고정 수익을 확보하게 됩니다. 이는 프리랜서의 가장 큰 고민인 수입의 불안정성을 해소하는 핵심 열쇠입니다. 고객 한 명의 생애 가치(LTV)가 극대화되는 것입니다.

수익률 증가, 모든 SI와 프리랜서의 꿈이자 목표이다. <출처: 작가, ChatGPT 생성>

결론: 코딩 속도가 아닌 기획력이 몸값을 결정한다

GitHub Copilot, Claude 같은 AI 코딩 툴이 코딩 자체의 장벽을 크게 낮추었다는 것은 이제 주지의 사실입니다.McKinsey의 2024년 연구에 따르면, 생성형 AI는 소프트웨어 엔지니어링의 생산성을 과거의 어떤 발전보다 크게 향상시켜, 개발자 생산성을 35%에서 45%까지 높일 수 있다고 추정합니다. 이는 코딩 속도만으로는 더 이상 차별화하기 어려운 시대가 오고 있음을 의미합니다. AI는 매우 빠르고 유능하지만, 무엇을 만들어야 하는지는 스스로 결정하지 못하는 유능한 인턴과 같습니다.

미래의 프리랜서 개발자, 혹은 외주사의 몸값(시급)은 얼마나 빨리 만드느냐가 아니라, "얼마나 정확하게 문제를 정의하고 기획하느냐"가 결정하게 될 것입니다. 당신의 기획력이 AI에게 줄 수 있는 프롬프트의 질을 결정하기 때문입니다.

당신의 7시간짜리 공짜 노동을 700만 원짜리 유료 계약으로 바꾸는 힘은, 화려한 코딩 스킬이 아닌 명료한 기획서를 작성할 수 있는 능력에서 나옵니다. 프리랜서로 일하고 계시거나 SI를 운영하고 계시다면, 혹은 부업으로 외주 일을 맡아볼까 생각하고 계시다면, 어떻게 나의 기획 역량을 끌어올릴 수 있을지 생각해 보시는 건 어떨까요?

<참고>

manyfast.io/blog

]]>

AI 주도 개발 시대, “기획”에 주목해야 하는 이유

이 글은 ‘리오랩(매니패스트)’이 제작하고, 요즘IT가 기업 제휴 콘텐츠로 소개합니다.

주식 시장에서는 연일 AI 산업을 주도하는 엔비디아의 시가총액이 최고점을 경신하고, 정부는 AI 산업 양성에 국운을 걸겠다고 선언하며, AI가 우리 일터(특히, IT 업계)에 깊숙하게 침투한 지 너무 오래전이라 이미 왠지 AI가 내 사무실 옆자리에 함께하는 것같이 느껴지는 시대입니다.

우리 모두가 AI를 활용하여 생산성을 끌어올리는 것이 지상최대의 과제인 것처럼 말하는 시대, 여러분들의 프로젝트도 폭발적인 속도로 달려가고 있나요? 혹시 AI를 활용하여 개발의 속도가 빨라졌다는 뉴스에도 불구하고 프로젝트가 진행되는 속도가 예전 그대로인가요?

이 글은 바로 이 지점에서 출발합니다. AI가 코드를 생성하는 속도는 비약적으로 빨라졌다는데, 프로젝트 전체의 속도는 왜 제자리걸음인지, 그리고 이 문제를 해결하기 위해 우리가 왜 개발이 아닌 기획에 주목해야 하는지 심층적으로 분석하고자 합니다.

AI 개발의 시대, 지금도 충분한가요?

1) 이미 AI 개발의 시대

요즘 IT 업계는 'AI 개발'의 시대로 완전히 접어들었습니다. Cursor, GitHub Copilot 같은 AI 코딩 도구는 이제 선택이 아닌 필수가 되어가고 있습니다. 스택 오버플로우(Stack Overflow)의 최신 2025 개발자 설문조사에 따르면, 이미 개발자의 80% 이상이 AI 도구를 사용하고 있거나, 사용할 계획이라고 답했습니다.

개발자 대상 AI 도구 채택률 조사 <출처: AI | 2025 Stack Overflow Developer Survey>

계속해서 빅테크들은 "AI가 개발자를 대체할 것"이라고 말하며 인력을 감축한다는 자극적인 헤드라인이 연일 쏟아지고 있으며, 실제로 많은 개발자가 현업에서 AI 도구를 도입해 놀라운 생산성 향상을 경험하고 있다고 합니다. GitHub의 자체 연구에 따르면, AI 코딩 어시스턴트인 Copilot을 사용한 개발자 그룹은 그렇지 않은 그룹에 비해 특정 과업을 2배 이상 더 빠르게 완료했습니다. AI를 통한 개발 생산성 증가는 이제 분명한 현실입니다. 우리 모두가 이를 알고 있죠.

Github 자체 조사이긴 하지만, AI 코딩 도구가 유용하게 사용된다는 것은 주지의 사실이다. <출처: Github 블로그>

과거 며칠씩 밤을 새워가며 만들던 보일러플레이트 코드, 복잡한 유틸리티 함수, 테스트가 포함된 API 엔드포인트를 이제는 단 몇 분 만에 완성합니다. 심지어 기획자나 마케터 같은 비개발자도 간단한 프롬프트로 랜딩 페이지나 데이터 분석 스크립트를 뚝딱 만들어내는 시대가 되었습니다. 최근 요즘IT에는 비개발자 출신이 바이브 코딩을 배워 프리랜서 개발자라는 부업을 가지게 된 경험을 나누는 글이 올라와 화제였죠. 개발의 장벽은 극적으로 낮아졌고, '개발'이라는 행위 자체의 생산성은 극도로 높아졌습니다.

2) 개발이 빨라지면, 프로젝트도 빨라지나?

하지만, 여기서 우리는 현업 종사자로서 근본적인 질문을 던져봐야 합니다.

"코드를 짜는 속도가 빨라진 만큼, 우리 프로젝트도 빨라졌습니까?"

아마 현업에 계신 많은 개발자, PM, 디자이너는 이 질문에 선뜻 "그렇다"라고 답하기 어려울 것입니다. AI와 함께함으로써 코드를 아무리 쉽고 빠르게 짤 수 있다해도, 여전히 프로젝트는 일정에 쫓기고, 예상치 못한 재작업은 반복되며, 클라이언트(혹은 내부 기획자)와의 지루한 줄다리기는 끝나지 않습니다.

프로젝트를 지연시키는 요인에는 한정된 인력에서 오는 개발 작업 속도의 한계만 있는 것이 아니기 때문입니다. 연락도 잘 닿지 않다가 프로젝트 일정 후반부에 갑자기 나타나 상세한 수정사항을 쏟아내는 클라이언트도 있고, 한창 개발과 디자인을 하고 있을 때 갑자기 웃으면서 나타나 기획안 변경사항을 들이미는 기획자도 있습니다. 갑작스러운 변덕을 부리거나, 막상 프로젝트가 진행되고 나니 자기가 원했던 건 이런 게 아니었던 것 같다며 완전히 다른 방향을 요구하는 대표님이나 이사님들도 있죠. 이런 일들은 그 어떤 AI 도구도 해결해 주지 않습니다.

쉬운 선택지가 무엇인지는 분명하지만… AI는 이것을 도와주지 않는다. <출처: 작가, Chat-GPT 생성>

혹시 여러분들은 AI가 짜준 코드를 통째로 git reset --hard 해본 경험은 없으신가요? 왜 AI가 도입되어 코드를 생산하는 속도는 10배 빨라졌다는데, 우리의 퇴근 시간과 프로젝트 마감일은 그대로일까요?

AI 시대, 더 강력해진 GIGO(Garbage In, Garbage Out) 법칙

1) AI는 코드의 품질을 결정하지 않는다

문제의 핵심은 AI 도구가 아니라, 그 도구에 우리가 무엇을 넣고 있는지에 있습니다. 컴퓨터 공학의 고전적인 격언인 GIGO(Garbage In, Garbage Out), 즉 '쓰레기를 넣으면 쓰레기가 나온다'는 법칙이 AI 시대에 와서 훨씬 더 강력하고 치명적인 모습으로 우리를 괴롭히고 있습니다.

여기서 개발자가 AI 도구에 넣게 되는 ‘'쓰레기(Garbage)'란 바로 '제대로 구조화되지 않은, 파편적이고 불분명한 기획'입니다.

최선을 다하더라도, 쓰레기는 쓰레기다. <출처: 작가, Chat-GPT 생성>

개발자라면 누구나 전체 플로우가 확정되지 않은 파편적인 기획, 그리고 개발 지시가 결국엔 얼마나 큰 재앙으로 돌아오는지 잘 알고 계실 겁니다. 개발자치고 기획자들에 대해서 분노의 감정을 느껴보지 않은 사람이 얼마나 될까요. 코드를 생산하다 말고 “아, 이거 어차피 또 바뀔 텐데”라는 생각에 갑자기 현타를 느껴본 경험은 개발자라면 누구나 있을 겁니다. 기획자들의 “이거 사소한 변경인데”, “쉽게 되는 거 아니에요?”, “이번 한 번만 해주세요”에 울컥해 본 경험도요.

또한 AI 코딩 도구의 등장은 이러한 문제를 더더욱 악화시킬 수 있습니다. 과거에는 불분명한 기획에 대해 개발자가 질문하고, 대안을 모색하며, 잠재적 문제를 예측하는 생산적 마찰의 과정이 존재했습니다. 이 마찰은 초기 개발 속도를 늦추지만, 장기적으로는 거대한 재작업을 막는 안전장치 역할을 했습니다. 하지만 AI 코딩 어시스턴트는 주어진 프롬프트를 문자 그대로 해석하여 가장 최적화된 코드를 즉시 생성함으로써, 모호한 요구사항에 내재된 위험을 성찰하는 과정을 건너뛰게 만들 수 있습니다. 그 결과, AI는 모호함이 낳는 재앙적인 결과를 증폭시키는 GIGO 증폭기로 작동하게 됩니다.

2) AI가 쓰레기를 뱉게 되는 과정

우리에게 친숙한 예시를 활용하여 왜 AI 코딩 도구의 코딩 생산성이 쓰레기를 만들게 되는지 설명해 보겠습니다. 프리랜서 개발자 K씨의 평화롭던 화요일 오전을 상상해 봅시다. 클라이언트로부터 메시지가 도착합니다.

클라이언트: "K 님, 저희 일단 MVP니까, 로그인할 때는 구글 소셜 로그인만 넣어서 빠르게 만들어주세요."

K씨는 간단한 작업이라고 생각합니다. 그는 곧바로 자신이 즐겨 사용하는 AI 코딩 도구에 프롬프트를 입력합니다. 몇 번의 대화 만에 구글 로그인을 위한 OAuth 2.0 로직, 콜백 처리, JWT 토큰 발급까지 포함된 코드가 3시간 만에 완성됩니다. npm run test는 깔끔하게 통과합니다. 완벽합니다. 이 과정에서 AI는 개발자의 인지적 부담을 매우 줄여줬죠. AI를 사용한 개발의 시대가 매우 아름답게 느껴집니다.

하지만 일주일 뒤, '그 메시지'가 도착합니다.

클라이언트: "아, K 님. 저희가 내부 논의를 해봤는데, 서비스 핵심이 바이럴이라서요. 이거 사소한 변경인데, 회원 가입할 때 추천인 코드만 넣을 수 있게 해주세요."

저도 딱 고만큼만 하고 싶습니다. <출처: 작가, Chat-GPT 생성>

이 사소한 변경에, K씨가 전에 만든 코드는 사실상 무용지물이 될 가능성이 커졌습니다. AI 코딩 도구는 "소셜 로그인만"이라는 첫 번째 지시에는 완벽히 부합하는 코드를 아주 쉽게 생성해 줬습니다. 하지만 그 코드는 추천인 제도를 통한 바이럴이라는 전체 제품 맥락을 고려할 수 없었기 때문에, 클라이언트의 요청은 절대 사소한 변경이 아니게 됩니다.

AI는 전체 제품 기획의 맥락을 파악하는 것이 아니라 사용자의 지시를 이행할 뿐입니다. 사용자의 지시가 명확하고 구조화되어 있지 않은 이런 상황에서 AI 도구의 막강한 생산성은, 빠르게 성공하게 해주는 것이 아니라 더 복잡하고 정교하게 실패하게 해주는 도구가 될 뿐입니다.

기획의 병목은 더 좁아지고 있다

1) 기획 병목은 언제나 있어왔다

사실 기획 병목이 어제오늘의 이야기인 것은 아닙니다. 기획 병목은 IT 업계의 오래된 숙제였습니다. 프로젝트 관리 협회(PMI)가 발간하는 보고서는 매년 프로젝트 실패의 큰 원인 중의 하나로 불분명한 요구사항 관리를 꼽아왔습니다. 예를 들어, PMI의 2014 보고서는 실패한 프로젝트의 무려 47%가 불분명한 요구사항 때문에 실패했다고 보고합니다. 제품 요구사항과 관련하여 클라이언트, 혹은 내부 기획자와의 의사소통 문제 때문에 실패한 프로젝트는 AI 코딩 도구가 등장하기 전에도 많았습니다.

예전에도 불명확한 요구사항을 정확히 관리하지 못해 프로젝트가 실패하는 일은 빈번했다. <출처: PMI Pulse of the Profession 보고서>

기획 단계에서의 문제가 프로젝트 실패라는 가장 끔찍한 결과로 이어지지 않더라도, 여전히 기획 병목 문제는 실제 프로젝트에 영향을 끼칠 수 있습니다. 바로 기획 단계에서 제대로 명확하게 처리하지 못한 대가를 개발 단계, 제품 운영 단계에서 아주 비싼 값으로 치러야 한다는 문제죠.

기획 단계에서 문제를 제대로 잡아내지 못하고 그 문제를 개발 단계에서 발견하게 된다면, 혹은 제품 완성 이후에 발견하게 된다면 수십, 수백 배의 대가를 치러야 한다는 것은 모두가 아는 사실입니다. 소프트웨어 공학 분야의 권위자인 배리 뵘의 그 유명한 법칙이 바로 그러한 내용을 담고 있죠. 소프트웨어 프로젝트 중에 버그를 찾아 수정하는 비용은, 프로젝트가 진행될수록 기하급수적으로 증가한다는 내용입니다.

문제를 해결하는 데 사용되는 비용은, 뒤로 갈수록 기하급수적으로 증가한다는 뵘의 법칙 <출처: Ten10 블로그, How much are software bugs costing you? | Ten10>

2) AI 시대, 그 병목은 더 좁아지고 있다

문제는, AI의 도움으로 개발의 생산성이 폭발적으로 향상된 지금, 이 병목이 더 좁아지고 있다는 점입니다. AI는 뵘의 법칙을 무효화해주지 못했고, 오히려 그 법칙의 시간 축을 압축시켜 버립니다. 기획 단계에서 제품 요구사항을 정확하게 확정 짓지 못하고, 정교하게 구조화하지 못한 채 빨라진 코딩 속도에만 의지해 개발을 시작하면, 그 아낀 시간을 결국 재작업으로 고스란히, 아니 그 이상으로 소모하게 됩니다.

아까 추천인 코드 예시로 돌아가 보겠습니다. 이 "사소한 변경”을 처리하기 위해 개발자 K씨는 이런 일들을 해야 합니다.

DB 스키마 변경: User 테이블에 referral_code (nullable, unique), recommended_by_user_id (foreign key) 등을 추가해야 합니다.
DB 마이그레이션: 기존 소셜 로그인 유저들에게도 이 스키마를 적용할 마이그레이션 스크립트를 작성하고 실행해야 합니다.
DTO 및 유효성 검사 로직 수정: RegisterUserDto 같은 데이터 전송 객체와 백엔드 유효성 검사 로직을 전면 수정해야 합니다.
핵심 비즈니스 로직 수정: AuthService의 회원가입 로직을 "1. 소셜 로그인 -> 2. (선택적) 추천인 코드 입력 -> 3. 가입 완료"라는 새로운 플로우로 변경하고, 추천인 코드 유효성 검사, 포인트 적립(만약 있다면), 추천인-피추천인 관계 설정 로직을 모두 추가해야 합니다.
API 엔드포인트 수정: /auth/register와 같은 엔드포인트의 요청/응답 본문(Request/Response body)이 변경됩니다.
프론트엔드 수정: 회원가입 UI에 "추천인 코드 (선택)" 입력 필드를 추가하고, 관련 상태 관리 로직(React Query, SWR 등)을 수정해야 합니다.
테스트 코드 수정: 기존 AuthService 테스트 코드가 모두 깨지므로 수정하고, 신규 로직을 위한 테스트 코드를 작성해야 합니다.

결국 AI가 코딩 시간을 아껴준다고 하더라도, 예정에 없던 기획이 추가된 시점에서 프로젝트는 사실상 원점으로 돌아간 것이나 다름없습니다. 처음부터 기획이 정교하게 구조화되지 않는다면, 개발자들이 아무리 빠르게 일한다고 하더라도 결국 재작업 비율만 높아지고 그에 따른 개발자들의 허탈감과 피로감만 높아질 뿐, 전체 프로젝트에 사용되는 시간이 단축되지 않는 것입니다. AI를 통한 개발의 속도가 빨라질수록, 기획이라는 첫 단추를 잘못 끼웠을 때의 대가가 상대적으로 훨씬 더 고통스러워진 것입니다.

AI 시대, 핵심은 기획의 정확도

1) 기획은 더 정확하고 빠르게 구조화되어야 한다

결론적으로, 개발 영역에서 아무리 생산성이 증가했고 앞으로 더욱 더 멋진 코딩 도구가 등장하더라도, 기획이 그만큼 빠르고 정확하게 이루어지지 않으면 프로젝트 전체가 무의미하게 지연되고 불필요한 재작업 비용이 생성되는 핵심 문제는 해결되지 않습니다. 개발은 시속 100km로 질주하는데, 기획은 시속 10km로 걸어가고 있다면 프로젝트가 어떤 속도로 진행될까요? 그 과정에서 기획에 대한 불신만 뭉게뭉게 매연처럼 피어오를 뿐입니다.

지금까지 우리가 "어떻게 하면 AI를 활용하여 코드를 더 정확하고 빠르게 생산할 수 있는가?"에 몰두해 왔다면, 이제는 고민의 축을 이동해야 할 때입니다.

"어떻게 하면 AI를 활용하여 '기획'을 더 빠르고 정확하게 '구조화'할 수 있는가?"

기획을 빠르게 구조화하는 것, 그것이 우리의 목표이다. <출처: 작가, Gemini 생성>

여기서 핵심은 구조화입니다. 단순히 기존에 만들던 피피티(PPT)나 노션(Notion) 기획서를 지피티의 도움을 받아 더 빨리 쓰는 차원의 이야기가 아닙니다. AI 시대에 진정으로 필요한 기획이란, 클라이언트나 제품 책임자의 모호한 요구사항을 명확하게 확정 짓고, 개발자가 즉시 개발에 착수할 수 있는 구조화된 명세서를 산출하는 과정 자체의 혁신을 의미합니다.

흥미롭게도, 개발자들은 이미 이러한 변화의 필요성을 본능적으로 인지하고 있습니다. GitHub의 한 설문조사에 따르면, AI 코딩 도구를 통해 시간을 절약한 개발자들 중 40-47%는 그 시간을 시스템 설계 및 기획에 더 많이 투자한다고 답했습니다. 이는 개발자들이 코딩 자동화로 확보된 인지적 자원을 자연스럽게 더 상위의 문제, 즉 더 나은 기획과 아키텍처 설계에 재투자하고 있음을 보여줍니다. 개발 현장이야말로 기획의 중요성을 가장 절실히 느끼고 있는 곳입니다.

AI 코딩 도구로 생산성 향상을 경험한 사람들은, 자연스럽게 기획에 신경쓰고 있다. <출처: How developers spend the time they save thanks to AI coding tools - The GitHub Blog 및 이미지 Chat-GPT 생성>

개발자가 AI 코딩 도구에 공급해야 할 진짜 ‘연료’는 다음과 같은 구조화된 산출물입니다.

정보 구조도: 어떤 메뉴들이 존재하고, 그 메뉴 간의 상하 관계(Depth)가 어떻게 되는가?
기능 명세서: 제품에는 어떤 기능들이 들어가야 하고, 각 기능에 세부 정책은 어떻게 되어 있는가?
유저 흐름도: 유저는 어떤 순서와 분기에 따라 이 기능을 경험하는가?

이것은 단순히 기획 문서를 쓰는 일이 아니라, 개발 이전에 시스템의 청사진을 그리는 요구사항을 엔지니어링하는 일입니다. AI를 활용하여 이러한 체계적인 문서의 형태로 기획 내용을 구조화할 수 있을 때, 우리는 AI 시대에 우리가 충분히 기획을 주목했다고 할 수 있을 것입니다.

마치며: AI 시대, 우리는 기획에 주목해야 한다

AI 코딩 도구이 강력해질수록, 그 도구가 태우는 연료인 기획의 중요성은 더더욱 커질 것입니다. AI 코딩 도구는는 강력한 F1 머신 엔진과 같고, 앞으로도 계속해서 강력해질 것입니다. 하지만 기획이라는 명확하고 구조화된 내비게이션이 없다면, 그 엔진은 엉뚱한 곳으로 빨리 질주하는 고철 덩어리에 불과합니다.

'바이브 코딩(Vibe Coding)'의 시대는 이미 펼쳐졌습니다. 우리는 바이브 코딩이라는 것을 매우 친숙하게 받아들이고 있죠. 최근 Figma는 컨퍼런스에서 '바이브 디자인(Vibe Design)'을 선언하며 디자인 영역의 AI 혁신을 예고했습니다.

우리는 IT 산업에 또 한 번의 거대한 생산성 혁신을 가져올 다음 단계, 즉 AI를 활용한 바이브 기획(Vibe Planning)에 주목해야 합니다. 여기서 바이브 기획이란, 비즈니스의 목표와 제품 사용자의 바이브(Vibe)를 포착하여, 디자이너 및 개발자들이 즉시 이해하고 실행할 수 있는 구조화된 명세로 전환하는 새로운 차원의 기획을 의미합니다. 개발자가 지긋지긋한 재작업과 소모적인 커뮤니케이션에서 벗어나, 진짜 개발의 즐거움에만 집중할 수 있는지는, 바로 이 기획에 얼마나 주목하느냐에 달려있습니다.

<참고>

manyfast.io/blog

]]>

기획부터 편집까지, AI로 뚝딱 만드는 영상 제작 가이드

오픈AI가 공개한 ‘Sora 2’는 텍스트나 이미지만으로 사실적인 영상을 생성하는 생성형 AI 모델이며, 구글의 ‘Veo 3.1’은 장면 전환과 오디오까지 정교하게 구현하는 차세대 영상 생성 툴이다. 이처럼 다양한 AI 기반 영상 제작 툴들이 발전하면서, 이제는 전문 지식이 없어도 누구나 영상을 손쉽게 제작할 수 있는 시대가 되었다.

기획자인 나 역시 AI 영상 툴을 활용해 기획부터 제작, 편집까지 직접 진행할 수 있게 되었다. 결과를 보니, 텍스트나 이미지로 생성되는 Sora 2의 영상 퀄리티에 깜짝 놀랐다. 특히 시나리오를 기획할 때 제미나이 스토리북(Gemini Story Book)이나 ChatGPT를 이용하면, 핵심 이미지 콘티를 자동으로 생성해 영상 제작의 기반도 쉽게 마련할 수 있었다. 만약 영상 제작 전문가라면 AI로 생성된 영상 클립을 추가 자료로 활용할 수도 있다. 이를 기반으로 최종 영상을 보정해 고품질로 완성도를 높인다면, 본연의 업무에 더욱 집중할 수 있을 것이다.

이번 글에서는 AI 기반 영상 제작 툴을 활용해, 홍보나 상품 소개용으로 20초 이상의 고품질 영상을 제작할 수 있는 실용적인 팁을 알아보고자 한다.

제미나이 스토리북을 활용한 스토리라인 작성

영상 제작의 기반은 견고한 스토리라인 기획에서 출발한다. 아이디어를 시각적인 시퀀스로 전환하는 과정에서 제미나이 스토리북을 사용하면, 스토리보드의 뼈대를 쉽고 빠르게 세울 수 있다. 또는 제미나이 스토리북처럼 시나리오 전용 젬스(Gems)를 만들어 사용하면, 영상의 각 장면(Scene)을 세부적으로 분할할 수 있다. 이를 통해 시퀀스 기반의 설계를 적용하면, 영상의 전체 구조를 더욱 체계적으로 구축할 수 있다. 혹은 아래 예시처럼, 생성형 AI 대화창에 간단히 프롬프트를 입력하는 방법도 있다.

제미나이 스토리북 프롬프트 예시:
“<고요 속의 달콤함>이라는 주제로 복잡한 도시 생활에서 지친 상태를 표현하되, 아래 3가지 흐름을 고려해서 시나리오를 작성해줘”

1. 도심 속 복잡한 생활에서 무표정으로 있는 장면
2. 혼자만의 장소로 가는 장면
3. 좋아하는 초콜릿을 한 조각 입안에 넣고 행복해하는 장면
4. 마지막엔 자신을 위한 시간이 필요하다는 메시지

결과 확인하기

챗GPT 프롬프트 예시:
“<고요 속의 달콤함>이라는 주제로 복잡한 도시 생활에서 지친 상태를 표현하되, 도심 속 복잡한 생활에서 무표정으로 있다가 좋아하는 초콜릿을 한 조각 입안에 넣고 행복해하는 스토리의 흐름을 흰색과 검은색 선만으로 8컷 스토리보드 콘티 이미지를 만들어줘”

결과 확인하기

또한 결과에서 나온 콘티 이미지를 프롬프트 없이 그대로 소라 2에 올리기만 해도, 자동으로 영상을 만들어 준다. 만약 상업용 광고 영상을 제작한다면, 상품 상세 정보나 리뷰 자료를 참고하는 것도 큰 도움이 된다. 또한 제미나이의 나노 바나나(Nano Banana) 기능으로 필요한 장면을 세밀하게 수정하여, 각 장면을 체계적으로 준비할 수 있다.

실전 영상 소스 제작, 편집하기

이제 앞서 준비한 이미지를 바탕으로, 영상에 생동감을 불어넣을 소스를 만들어 볼 차례다. 현재 Sora 2,Veo 3.1, Flow, Pixverse, Kling, Hailuo, Deevid, Hygen, OpenMagic, Topview 등 다양한 툴이 있지만, 지금도 새로운 툴이 계속 출시되고 있다. 이 수많은 툴 중에서 목적에 맞는 툴을 선택해 활용하는 것이 중요하다. 예를 들어, 탑뷰(TopView)는 구매 전환율이 높은 상품 소개 영상을 제작하는 데 최적화되어 있고, 브랜딩 영상은 픽스버스(Pixverse)가 더욱 적합하다.

이번 글에서는 Sora 2, Veo 3.1, 클링(Kling), 헤일루(Hailuo), 캔바(Canva)를 중심으로 살펴보고자 한다.

1) Sora 2로 영상 만들기

Sora 2는 간단한 텍스트를 입력하거나, 이미지를 올리면 자연스러운 영상을 만들어 준다. 특히 장면 전환이 부드럽고, 자막과 한국어 립싱크가 자연스럽다. 또한 영상 분위기에 어울리는 음악까지 자동으로 구성해 주기 때문에, 이전 버전에 비해 훨씬 높은 퀄리티의 결과물을 얻을 수 있다.

또한 이전에는 없던 나만의 아바타나 유사한 카메오를 직접 생성할 수도 있다. 다만 이 기능을 사용할 경우에는 영상을 다운로드할 수 없으며, 사실적인 인물 이미지를 업로드하면 영상 제작 기능이 제한된다. 이는 딥페이크(Deepfake) 관련 이슈를 관리하기 위한 내부 규정과 가이드라인을 잡아가는 과정으로 보인다.

Sora 2 AI 이미지로 비디오 생성하기 화면 <출처: 작가 캡처>

<출처: Sora 2 AI 이미지로 영상 생성 결과>

<출처: Sora 2 AI 콘티 이미지로 AI 영상 생성 결과>

그리고 Sora 2는 위 예시와 같이 약 10초 분량의 영상 제작을 지원한다. 따라서 여러 영상을 연결해 사용할 경우에는, 시작과 끝 프레임을 정교하게 조정할 수 있는 도구가 필요하다. 이와 관련해 어떤 툴들이 이러한 역할을 수행할 수 있는지도 이후에 자세히 소개할 예정이다.

2) 구글의 Veo 3.1로 영상 만들기

구글의 Veo 3.1은 전반적인 영상 퀄리티 개선뿐만 아니라, 시작과 끝 프레임을 선택해 영상 생성이 가능하다는 점이 돋보인다. 또한 마지막 1초를 기준으로 새로운 영상을 자동으로 이어 붙이는 기능을 지원해, 최대 1분 이상의 영상을 제작할 수 있다는 점에서 Sora 2와 차별화된다.

특히 사람, 물건, 장면 등 참고 이미지를 기반으로 영상을 생성한다는 점이 인상적이다. 아래와 같이 세 가지 이미지를 올리고 프롬프트를 입력하면, 이에 맞는 영상을 만들어 준다. 참고로 Veo 3.1 사용은 플로우를 이용했다.

Veo 3.1에서 사람, 물건, 장면 이미지로 비디오 생성(상), 영상을 이어서 확장하는 화면(하) <출처: 작가 캡처>

실제로 두 툴을 모두 사용해 본 결과, Veo 3.1, Sora 2 모두 상품의 로고나 실제 크기 등이 일부 변형되어, 완성된 결과물을 그대로 활용하기에는 추가 편집이 필요했다. 다만 두 툴 중에서는 Sora 2의 영상 퀄리티가 좀 더 자연스러웠다.

3) 클링 AI로 영상 만들기

클링(Kling) AI는 이미지 기반으로 비디오 생성 시, 시작과 끝 이미지를 선택하고 프롬프트를 입력하면 약 5초 정도의 클립을 제작할 수 있는 툴이다. 클링 AI의 가장 큰 장점은 멀티모달 편집, 립싱크, 사운드 추가 등 다양한 기능을 함께 사용할 수 있다는 점이다. 또한 프롬프트를 작성하지 않아도 영상을 생성할 수 있으며, 원하는 동작이나 움직임을 입력하면 의도한 결과물에 더욱 가깝게 제작할 수 있다.

클링 AI 이미지로 비디오 생성하기 <출처: 작가 캡처>

<출처: 클링 AI 이미지로 비디오를 생성한 결과>

4) 헤일루 AI로 영상 만들기

헤일루 AI(Hailuo AI) 역시 시작 이미지와 끝 이미지를 기반으로 영상을 제작할 수 있다. 다만 사운드 효과가 기본적으로 포함되지 않는 점은 다소 아쉬웠다. 또한 프롬프트(prompt)를 작성할 때는 원하는 동작을 최대한 단순하고 명확하게 표현해야, 의도한 결과물을 얻을 수 있다.

예를 들어, 시작 이미지에는 스마트폰이 없지만 끝 이미지에는 스마트폰이 있다면, ‘들고 있는 스마트폰을 내려놓고 창가로 간다’와 같이 구체적인 동작 프롬프트를 반드시 입력해야 한다. 그렇지 않으면 디퓨전(diffusion) 방식의 특성상, 손 모양을 임의로 바꾸어 스마트폰을 새로 만들어내는 현상이 발생할 수 있다.

헤일루 AI 이미지로 비디오 생성하기 <출처: 작가 캡처>

<출처: 헤일루 AI 이미지로 비디오를 생성한 결과>

5) 캔바를 활용한 최종 편집 및 오디오 추가

캔바(Canva)는 주로 프레젠테이션(PPT) 제작 도구로 잘 알려져 있지만, 최근에는 AI 영상 제작 기능도 지원하고 있다. 사용 방법은 간단하다. 먼저 프로필 > 설정에서 언어를 영어로 변경한 뒤, 홈 화면에서 ‘Canva AI’를 선택하면, Veo 3 기반의 동영상 생성 기능을 활용할 수 있다.

캔바 AI 이미지로 비디오 생성하기 <출처: 작가 캡처>

또한 캔바 AI로 생성한 이미지나 영상 클립뿐만 아니라, 앞서 제작한 영상 클립들을 캔바에 업로드해 하나의 스토리로 연결하고, 오디오를 추가하면 영상의 완성도를 더욱 높일 수 있다. 내가 캔바를 선택한 이유는, 영상 편집 시 시작과 끝 장면을 자연스럽게 이어 붙일 수 있다는 점과 다양한 출력 포맷을 지원한다는 점 때문이다. 무엇보다 사용자 경험에서도 인터페이스가 직관적이라 사용하기도 쉽다.

캔바 동영상 편집 화면 <출처:작가 캡처>

<출처: 캔바 동영상으로 편집한 결과>

AI와 함께 확장되는 창의의 영역

구글의 Veo 3.1과 OpenAI의 Sora 2를 비롯해 다양한 AI 영상 제작 툴을 직접 사용해 본 결과, 기획력을 바탕으로 탄탄한 스토리라인만 세울 수 있다면, 누구나 손쉽게 영상을 제작할 수 있는 시대가 열렸음을 실감했다. 앞으로는 AI가 만드는 영상이 더 현실적이고 의미 있는 콘텐츠 수준으로 발전할 것으로 보인다.

실제로 AI 영상 제작 시장은 2032년 약 25억 달러 규모로 성장할 전망이며, 이는 폭발적으로 늘어나는 숏폼 콘텐츠 수요와 함께 더욱 가속화될 것이다. MAKEBOT AI 조사에 따르면, 제작 비용은 약 60% 절감, 제작 시간은 80% 단축이 가능하며, 1~2시간이면 완성된 결과물을 얻을 수 있다고 한다.

AI 영상 제작 툴을 직접 사용하며 느낀 가치는 단순한 제작 효율성이 아니라, 창의적 발상을 증폭시킨다는 점이었다. AI는 내가 생각하지 못한 새로운 모션과 시퀀스를 제안하며, 아이디어 발상에서 파트너 역할을 충실히 해냈다. 또한 최근 출시된 구글 Veo 3.1과 OpenAI Sora 2는 영상과 오디오를 동시에 생성하면서, 물리 법칙까지 정교하게 반영하고 있다. 이러한 기술은 AI 영상 제작 흐름을 한 단계 더 끌어올릴 전환점이 될 것이다.

끝으로 나는 AI가 제작자를 대체하는 존재가 아니라, 제작자가 더욱 본질적인 업무에 집중할 수 있도록 돕는 파트너가 될 것이라 생각한다. 섬세한 퀄리티와 복잡한 내러티브 구현에는 여전히 전문가의 손길이 필요하기 때문이다. 스토리의 일관성, 감정의 흐름, 브랜드 정체성 구현 또한 인간의 감각과 판단력이 뒷받침되어야 완성될 수 있다.

그렇다면 우리는 AI가 만든 영상 속에서, 인간만의 감성을 어떻게 이어갈 수 있을까? 이제 그 지점을 고민해 볼 차례다.

]]>

AI 시대에도 개발 스프린트는 2주가 ‘국룰’일까?

AI 쓰면 더 빨리 개발할 수 있겠네요!

최근 비즈니스팀과 개발팀이 함께한 요구사항 정리 미팅에서 개발팀의 AI 활용에 대한 질문이 나왔습니다. 개발팀이 사용하는 AI 기술과 도구들이 구체적으로 실제 개발 업무에 얼마나 도움을 주고 있는지, 그리고 그 효과가 어느 정도인지 묻는 질문이었죠.

요즘 저는 회사 내 다른 팀들로부터 비슷한 질문을 자주 받아왔습니다. 하지만 스쿼드 팀을 운영하는 입장에서, AI 도구가 실제 개발에 어느 정도 도움을 주는지 구체적으로 설명하기는 쉽지 않았습니다. 그런데 이번 미팅에서 직접 질문을 받은 개발자들의 답은 조금 달랐습니다. 그들은 “코드 작성과 테스트 과정에서 AI 어시스턴트를 적극적으로 활용하고 있으며, 더 나은 품질의 코드를 더 빠르게 작성할 수 있게 되었다”고 자신감 있는 목소리로 설명했습니다.

그 말을 듣던 비즈니스팀의 한 분이 “그럼 이제 저희 요구사항들이 더 빨리 개발될 수 있겠네요!”라며 기대 섞인 반응을 보였습니다. 열심히 설명하던 개발자들은 그 말에는 그저 웃음으로만 답하고 말을 멈췄습니다. 그렇게 미팅은 다소 어색한 분위기 속에서 마무리되었습니다.

AI를 쓰는 개발자들이 듣기 싫어하는 말들 <출처: 작가>

제 관점에서 보자면, AI 기술의 발전으로 코드 자동 생성과 수정이 가능해지면서 개발자의 생산성이 올라간 것은 분명해 보입니다. 실제 스프린트에서 일부 개발자의 개발 시간이 단축된 것도 정량적으로 확인할 수 있었고요. 반면 AI 활용 능력과 학습 속도에 따라 개발자 간 생산성 격차가 점점 커지고 있다는 것도 느껴집니다. 그렇게 시간이 지날수록 AI 활용은 점점 보편화될 것이며, 개발 생산성은 이전과는 비교할 수 없을 만큼 획기적으로 향상될 것은 분명해 보입니다.

그래서 문득 궁금해졌습니다. 앞으로 AI는 실제로 얼마나 개발 속도를 단축시킬 수 있을까요? 그리고 그 변화는 개발 프로세스에 어떤 영향을 미치게 될까요?

AI는 개발 속도를 얼마나 향상시켰을까?

개발자 여러분에게 묻고 싶습니다.

AI가 실제 개발 업무에 얼마나 많은 도움을 주고 있나요?

체감상, 얼마나 빠르게 개발할 수 있도록 도와주는 것 같나요?

최근 여러 연구와 기업 사례, 그리고 설문 조사 결과를 종합해 보면, 2025년 기준 개발자의 AI 도구 사용률은 82%에 달하며, 평균적으로 개발 생산성은 15~20% 향상된 것으로 나타났습니다.

특히 깃헙 코파일럿(GitHub Copilot) 관련 연구는 더 많은 개발 작업 완료, 코드 커밋 증가, 컴파일 빈도 상승과 같은 긍정적인 변화를 보고했습니다. 이 외에도 다양한 AI 플랫폼 기업들이 개발 생산성 향상과 관련된 수치를 지속적으로 공개하고 있습니다.

개발자 대상 코파일럿의 유용성에 대한 조사 결과 <출처:GitHub Blog>

저희 개발팀 역시 코파일럿을 적극적으로 활용하고 있습니다. 코드 생성, 디버깅, 테스트 케이스 작성 등 다양한 영역에서 AI를 사용하고 있으며, 일부 개발자들은 “이제 코파일럿없이 개발을 시작할 수 없다”고 합니다. 그들은 체감상 개발 속도가 약 50% 정도는 빨라졌다고 말하기도 합니다.

개발 프로세스도 이제 변화가 필요할까?

이처럼 개발 업무에서 AI 도구를 활용하지 않는 개발자를 찾기 어려운 시대입니다. 물론 개인마다 활용도와 생산성의 차이는 있지만, AI를 활용한 코드 작성과 리뷰는 더 이상 선택이 아닌 필수 요소로 자리 잡고 있습니다.

스크럼(Scrum)을 운영하는 입장에서 제가 가장 크게 느끼는 변화는, 개발 백로그(Backlog) 안에 AI 관련 컨텍스트가 점점 더 많이 포함되고 있다는 점입니다. 과거에는 회의 시간에만 등장하던 AI 활용 사례들이 이제는 백로그 항목에 구체적으로 기술되기 시작했고, 다양한 필드에 AI 관련 내용이 추가되고 있기 때문입니다.

예를 들어, 어떤 개발자는 AI 도구를 활용한 테스트 작성을 체크리스트 항목으로 관리하고, 또 다른 개발자는 코드 리뷰 단계에서 AI 기반 리뷰 절차를 필수로 진행하고 있습니다. 한편 일부 백로그 항목에서는 AI가 코드 생성부터 리뷰까지 대부분의 작업을 함께 수행하는 형태로 기술되기도 합니다.

이러한 흐름을 보면, 이제 AI 도구 사용은 개발 프로세스에서 관리되어야 하는 하나의 요소라는 생각이 들기도 합니다. 그래서 자연스럽게 개발자들의 AI 활용을 어떻게 표준화하고, 이를 스크럼 운영에 효과적으로 녹여낼 수 있을지, 이런 고민을 시작했습니다. 그러자 곧 이런 질문들이 떠올랐습니다.

우리 스쿼드의 모든 개발자가 AI를 활용해 코드 작성과 리뷰를 할 수 있도록, 공통 AI 도구와 프롬프트 사용 체크리스트를 추가해야 할까?
AI 도구도 스쿼드의 일원처럼 특정 태스크(Task)를 할당하고 관리해야 할까?
AI 기반 개발의 경우, 스토리 포인트(Story Point) 산정 기준은 어떻게 달라져야 할까?
스프린트 회고 단계에서, AI 도구를 활용한 코드 리뷰와 피드백을 별도로 정리해야 할까?

그 질문들 끝에, 개인적으로 가장 크게 다가온 질문은 이것이었습니다.

“AI 시대에도 2주 스프린트는 여전히 유효한 타임박스인가?”

AI 활용 능력에 따라 개발자들의 퍼포먼스 차이가 점점 커지고 있습니다. 일부 개발자들은 2주라는 타임박스가 무의미할 정도로 빠르게 작업을 완료하고 있죠. 그렇기에 저는 AI를 적극적으로 활용하는 개발자에게는 더 짧은 타임박스가 적합하지는 않을지, 혹은 AI 활용 수준에 따라 스프린트 구조 자체를 유연하게 조정해야 하는 것은 아닐지, 그렇게 결국 ‘스프린트’의 의미 자체를 다시 정의해야 할 시점이 온 것은 아닐까 하는 생각이 들었습니다.

RIP 애자일. 성공한 빅테크 엔지니어들은 스크럼을 사용하지 않는다?

최근 다양한 매체에서 스크럼(Scrum) 에 대한 회의적인 시각을 자주 접하고는 합니다. 특히 빅테크 기업들을 중심으로, 스크럼 기반의 개발 프로세스가 더는 높은 가치를 제공하지 못한다는 의견이 제기되고 있죠. 그에 따라 AI 시대의 흐름에 맞춘 개발 방식의 변화가 필요하다는 주장도 점점 힘을 얻고 있습니다.

이런 흐름 속에서 실제로 최근 1~2년 사이, 스크럼 마스터(Scrum Master)나 애자일 코치(Agile Coach)의 역할이 줄어들거나 전환되는 사례가 늘어나고 있습니다. 특히, 성공한 빅테크 기업의 엔지니어들 중 상당수는 이제 스크럼을 사용하지 않는다고도 말합니다. 2주 단위 스프린트를 추종하지 않으며, 데일리 스탠드업도 하지 않고, 스토리 포인트 추정조차 하지 않는다는 것이죠. 그 대신 “정해진 목적을 달성하기 위해 일한다”고 말합니다.

이는 단순한 무질서의 결과는 아닙니다. 그들은 이미 애자일(Agile)의 가치와 일하는 문화가 조직 내부에 충분히 내재화된 상태에서, 각 개인과 팀이 목표 달성에 최적화된 자신만의 방식으로 일하는 ‘개인 맞춤형 개발 프로세스’를 추구하고 있는 것입니다.

결과적으로 이러한 사례들은 기존 스크럼 프레임워크를 약화시키거나, 혹은 더욱 유연한 형태로 진화시키는 흐름을 만들고 있습니다. 특히 AI 도구의 도입과 함께, 기존 스프린트를 대체할 새로운 개발 프로세스의 청사진도 그려볼 수 있는 수준이 왔습니다.

마이크로 스프린트가 온다

그 흐름 아래, 최근 ‘마이크로 스프린트(Micro Sprint)’라는 흥미로운 용어를 접했습니다. 이 개념은 앞서 언급한 빅테크 기업들을 중심으로 확산되고 있으며, 기존처럼 2주 단위의 개발 타임박스(Timebox)에 집착하지 않고 자율적이고 목표 중심적인 경량 개발 프로세스를 지향하는 흐름을 반영합니다.

마이크로 스프린트는 기존 스프린트보다 훨씬 짧은 주기의 타임박스를 기반으로 하며, 정해진 목표를 빠르게 달성하는 데 집중하는 방식입니다. 이 방식은 주로 팀 단위보다는 숙련된 개별 엔지니어 중심으로 운영되고 있으며, 각자의 역량과 목표에 따라 유연하게 적용됩니다.

이러한 변화는 기존의 팀 중심 개발 프로세스를 개인 OKR 수준으로 세분화하여, 보다 목표 지향적인 개발 방식으로 전환하고 있다는 점에서 큰 의미를 가집니다.

결국 기존 스크럼 프레임워크와는 전혀 다른 관점에서, 더 유연하고 개인화된 개발 프로세스로의 진화가 지금 시대의 논점으로 보입니다.

스크럼에서 개발 속도 보다 중요한 것

여기까지, 빅테크 기업들의 목표 지향적인 개발 프로세스와 마이크로 스프린트 사례로 스크럼 프레임워크에서 제안한 2주라는 타임박스가 가진 진짜 의미를 다시 한번 생각해 보았습니다. 이렇게 보면 2주라는 시간이 이제는 바뀌어야 하지 않을까? 라는 생각이 들기도 합니다.

하지만, 스크럼(Scrum)의 ‘2주 스프린트’가 어떤 철학과 의도를 바탕으로 제안된 것인지를 짚어봐야 합니다. 사람들은 그저 스프린트 주기의 목적을 구체적인 마감일을 정해 완료하기 위한 장치나, 개발자의 퍼포먼스를 정량적으로 측정하고 지표를 만들기 위한 수단으로 받아들이곤 합니다. 그러나 이것이 전부는 아닙니다.

스크럼의 핵심 원칙, 경험주의(Empiricism) <출처: Scrum.org>

사실, 스크럼의 스프린트 타임박스는 애자일의 핵심 철학 중 하나인 경험주의(Empiricism)를 반영하기 위한 아이디어에서 출발했습니다. 즉, 스프린트의 본질이 속도나 일정 관리가 아닌, 개발 과정에서 팀이 경험을 통해 배우고 반복해 개선하는 프로세스를 만드는 데 있다는 것입니다. 정해진 기간 안에서 가치를 꾸준히 전달하고, 그 과정에서 얻은 인사이트를 토대로 점진적인 개선을 이뤄나가는 것이야말로 스프린트의 핵심이죠.

이 관점에서 보면, 마이크로 스프린트 역시 경험주의 철학을 기반으로 2주 단위 스프린트와 같은 방향을 지향하고 있다고 할 수 있습니다. 단지 팀 단위가 아닌 개인 OKR 수준으로 세분화된 목표 중심의 개발 방식을 추구하며, 더 짧고 유연한 타임박스로 개인의 퍼포먼스를 극대화하는 데 초점을 두고 있을 뿐입니다.

결국 이 역시 꾸준한 개선을 위한 경험의 반복이라는 형식과 철학은 유지하되, 시대와 기술 변화에 따라 더 유연하고 개인화된 방식으로 진화하고 있는 것입니다.

그럼 지금껏 우린 왜 2주 스프린트만을 ‘국룰’이라고 믿었나?

4주는 긴 것 같고 1주는 짧은 것 같은 스프린트 <출처: 무한도전, 작가 편집>

그럼 왜 2주라는 기간이 스크럼의 ‘국룰’이 되었을까요? 이를 설명하려면 ‘골디락스 원리(Goldilocks Principle)’라는 용어를 알면 좋습니다. 이 개념은 주로 경제학에서 쓰는 용어인데, 다양한 경험으로 자신에게 가장 이상적인 상태를 찾아 유지하는 것을 의미합니다.

1995년, 스크럼이 처음 공식 발표되었을 당시에는 약 30일(한 달) 단위의 개발 주기가 제안되었습니다. 하지만 2000년대 초반, 애자일이 여러 산업으로 퍼지며 1~4주 사이의 다양한 스프린트 주기 실험이 이어졌습니다. 그 결과, 2주 이내에 개발 결과를 확인하는 것이 가장 민첩하고 효과적이라는 인식이 자리 잡게 되었죠.

이러한 실무적 경험을 바탕으로, 오늘날 대부분의 개발 조직은 2주 스프린트를 가장 일반적인 주기로 받아들이고 있습니다. 결국 이 2주라는 주기는 단순한 관행이 아니라, 골디락스 원리처럼 애자일의 경험주의에 기반한 수많은 실험과 경험으로 도출된 결과물이라는 뜻입니다.

즉, ‘가장 이상적이며 유지하고 싶은 적정한 타임박스(Timebox)’가 2주였고, 이를 많은 개발팀이 받아들인 것입니다.

개인도 팀도, 스프린트는 2주가 딱이야

평화로운 2주 스프린트 <출처: 사운드 오브 뮤직, 작가 편집>

그렇게 2주 스프린트가 ‘국룰’로 자리 잡은 이유를 더 들여다 보겠습니다. 가장 큰 이유는, 이 기간이 개발자들에게 지속 가능한 리듬으로 동기부여를 제공한다는 점입니다.

2주 단위 스프린트를 운영하면 연간 최대 26회의 리뷰와 회고 기회를 가질 수 있는데요. 이는 한 달 스프린트(연 12회)와 비교했을 때 2배 이상의 피드백 루프를 제공합니다. 한편, 이 기회를 더 많이 제공하는 1주 스프린트는 지나치게 촉박해 번아웃을 유발할 수 있습니다. 또, 3~4주 스프린트는 긴장감이 느슨해져 몰입도가 떨어진다고 합니다.

그래서 2주는 ‘달성 가능하면서도 도전적인’ 기간으로 인식되며, 적절한 마감 압박과 품질 유지 사이에서 팀의 몰입도와 동기부여를 높이는 데 효과적이라는 의견이 나온 것입니다.

실제로 제가 일하는 회사의 글로벌 PMO 조직에서는 매년 전사적으로 활용하는 연간 스프린트 캘린더(Sprint Calendar)를 생성하고, 모든 스쿼드가 이 일정에 맞춰 협업할 수 있도록 가이드하고 있습니다.

처음에는 모든 개발 조직이 같은 날짜에 시작과 종료를 맞춘다는 것이 다소 관료적이고 비효율적으로 느껴졌습니다. 하지만 적용하다 보니 2주라는 고정된 리듬이 개발자들에게 심리적 안정감을 제공하고, 이해관계자들과의 예측 가능한 커뮤니케이션을 만들어 준다는 장점을 만났습니다.

물론 조직의 규모나 프로젝트 복잡도에 따라 최적의 스프린트 주기는 달라질 수 있습니다. 그러나 적어도 글로벌 제품을 관리하며 여러 개발팀이 협업하는 환경에서는, 2주라는 공통의 타임박스가 심리적 안정감과 협업 효율성이라는 가치를 제공한다는 점에서 여전히 유효한 선택이라 생각합니다.

마치며

지난 30여 년간, 2주 스프린트는 수많은 개발팀이 실험과 경험을 거쳐 만들어낸 ‘골디락스(Goldilocks)’적 개발 리듬으로 자리 잡아 왔습니다.

하지만 AI 시대의 개발 스프린트에서 결국 중요한 것은 2주라는 형식적인 주기가 아닙니다. 핵심은 AI 도구 활용 경험이 개인과 팀의 학습과 개선으로 이어져 지속적으로 가치를 전달하고, 얻은 인사이트를 바탕으로 개발 프로세스를 끊임없이 발전시켜 나가는 것이죠.

AI의 도입으로 개발 방식은 그 어느 때보다 다양해지고 있습니다. 그래서 개인의 역량과 목표에 따라 더 짧고 유연한 타임박스가 필요해지는 흐름도 분명히 존재합니다. 그런 만큼 앞으로의 개발 프로세스는 고정된 형식에 얽매이기보다, 경험으로 배우고 개선하는 애자일의 본질을 유지해야 합니다. 각 팀과 개인에게 가장 적합한 리듬을 찾아가는 방향으로 진화하는 방향은 어디에 있을지 고민해 봅니다.

]]>

서비스 기획자가 꼭 알아야 할 ‘핵심 지표’ 가이드

데이터는 크게 두 가지로 분류됩니다. 숫자로 표현할 수 있는 경우와 그렇지 않은 경우입니다. 숫자로 구분되는 것은 정량적 데이터고, 그렇지 않은 것은 정성적 데이터입니다. 데이터 분석이나 현황을 이해하는데 두 가지 정보가 모두 중요합니다만, 정량적 데이터가 선호됩니다.

정량적 데이터는 측정이 가능하기 때문입니다. 측정할 수 있기에 비교할 수 있고, 다양한 관점으로 분석할 수 있습니다. 예를 들어, 누군가가 너무 사랑한다고 말할 때, 그 깊이를 가늠하는 것은 참 어려운 일입니다. 그럴 때 ‘3,000만큼 사랑한다’라는 정량적인 데이터를 넣어주면, 그 깊이를 가늠할 수 있죠. 이러한 이유로, '빅데이터', '데이터 분석' 등의 '데이터'는 굳이 짚어 말하지 않았지만, 정량적 데이터를 의미합니다. 그리고 이 정량적 데이터는 구체적으로 수치화된 지표(Metric)들입니다. 지표의 예시는 '조회 수', '인구수' 등이 해당되죠.

어떤 지표는 이름이 조금 어렵습니다. MAU, CPC, CVR처럼 의미를 알 수 없는 영어 단어들도 있고요. Retention, Stickiness처럼 해석이 가능해도 도무지 이해하기 어려운 단어들도 있습니다. 이들은 모두 제품 운영을 위해 필요한 지표들입니다.

이번 글에서는 마케팅부터 고객 Lock-in까지, 제품 운영을 위해 꼭 알아야 할 모든 지표에 대해 알아보려고 합니다. 아직 운영 경험이 적거나, 마케터와의 협업 경험이 없는 서비스 기획자, 제품 지표를 이해하고 싶은 마케터는 물론, 제품과 관련된 모든 직군에게 도움이 되었으면 합니다.

미리 알아둘 것

모든 제품(서비스)에는 고객이 있습니다. 이 글을 작성하는 저 또한 고객이며, 이 글을 읽고 있는 여러분도 아마 다양한 제품의 고객이 아닐까 싶습니다. 그리고 모든 고객은 자신의 흔적을 남깁니다. 가끔 저는 디지털 서비스를 이용하는 우리의 모습이 꼭 과자를 흘리고 다니는 헨젤과 그레텔 같다는 귀여운 상상을 하곤 합니다.

고객이 이렇게 과자를 흘리고 다니는 덕분에 우리는 퍼포먼스 마케팅을 할 수 있고, 제품을 운영하고, 나아가 제품을 성장시킬 수 있습니다.

제품 운영에 사용되는 모든 지표는 고객에 의해 만들어집니다. 고객은 그들만의 여행을 합니다. 출발지와 도착지가 정해져 있죠. 우리는 광범위하게 이를 '고객 여정'이라고 부릅니다. 고객의 여정 속에서 모든 지표는 단계적으로 생성되고 서로 연결됩니다. 그러니 이러한 지표를 제대로 이해하는 것만으로도, 제품을 넘어 고객을 중심으로 한 비즈니스의 큰 흐름을 알 수 있게 됩니다.

본격적인 이야기를 시작하기 전에 몇 가지 내용을 먼저 이해해 보면 좋을 것 같습니다.

모든 고객을 확보하는 데에는 비용이 소요됩니다. 이를 고객 획득 비용(CAC, Customer Acquisition Cost)이라고 합니다.

마찬가지로 모든 고객을 확보하면 그만한 가치를 얻을 수 있습니다. 이를 고객 생애 가치(LTV, Life Time Value)라고 합니다.

모든 단계는 넓게 시작하여 좁게 끝납니다. 단계의 끝으로 갈수록 적은 고객이 남는다는 의미입니다. 사람들은 이 모습이 깔때기를 닮았다고 하여 퍼널(Funnel)로 비유합니다.

이 글은 퍼널을 다음과 같이 정의하며, 단계를 따라 설명할 예정입니다.
상단 퍼널: 인지도 확보와 고객 유입을 위한 마케팅 영역
중간 퍼널: 고객 활성화를 위한 서비스 영역
하위 퍼널: 고객 인게이지먼트 확보를 위한 집중 고객관리 및 CRM 영역

고객 활성화는 고객의 전환과 같이 최초의 고객 획득을 의미합니다. 인게이지먼트는 조금 다릅니다. 고객이 우리 서비스의 '팬'이 되는 것을 의미합니다. 이 이야기는 뒤에서 좀 더 자세히 다뤄보겠습니다.

사실 퍼널은 정의하기 나름이라 다양한 정의가 있지만, 이번 글에서 상단 퍼널은 마케팅을 위한 영역을 의미합니다. 상단 퍼널에서는 다음과 같은 지표들이 사용됩니다.

1. 상단 퍼널

■ 비용(Cost)

광고를 집행하는 데 필요한 비용입니다.

■ 노출(Impressions)

노출은 광고가 노출된 횟수를 의미합니다. 노출량이 높다면, 그만큼 많은 고객이 우리의 광고를 봤음을 의미합니다.

■ 도달(Reach)

도달은 광고를 본 사람의 수를 의미합니다. 노출과 유사해 보이지만 사람에 할당된 개념입니다. 철수 씨가 혼자서 같은 광고를 3번 봤다면, 이 광고의 도달은 '1'이고 노출은 '3'입니다.

■ 클릭(Click)

말 그대로 광고가 클릭된 횟수를 의미합니다. 광고를 클릭하는 즉시 실제 사이트로 유입되는 경우, 클릭은 '유입수'와 동일하게 볼 수도 있습니다. 이에 대해서는 중간 퍼널을 설명할 때 조금 더 자세히 다뤄보겠습니다.

상단 퍼널은 오로지 돈을 들여, 보이고, 눌려지는 것만으로 모든 것을 설명할 수 있습니다. 그러나 마케팅을 경험해 보신 분들은 "왜 전환이 빠져있느냐"라고 물을 것입니다. 이는 중간 퍼널에서 다시 다뤄보겠습니다.

하지만 끝이 아닙니다. 이 4개뿐인 지표를 가지고도 들여다봐야 하는 정보는 차고 넘치기 때문입니다.

■ CPM(Cost Per Mille)

광고가 1,000회 노출될 때마다 지불되는 비용을 의미합니다. 이는 광고가 송출되는 매체에 따라 미리 정의되곤 합니다.

■ CPP(Cost Per Period)

일정 기간 동안 광고가 노출되는 것을 약속하고 지불하는 비용을 의미합니다. 일주일간 1,000원과 같은 형태입니다.

■ CPC(Cost Per Click)

클릭 1회당 발생하는 비용을 의미합니다. "전체 비용 / 클릭 수 = CPC"와 같은 형태로 계산합니다.

'C'가 많이 들어간 '비용 효율 지표'들입니다. 'C'는 정말 다양하게 사용되는데요. 'Cost', 'Customer', 'Conversion', 'Click' 등 다양한 단어를 의미할 수 있지만 비용 효율 지표에서는 'Cost' 즉, 비용을 의미합니다.

상단 퍼널은 마케팅 영역이라고 했습니다. 공짜 마케팅은 없습니다. 비용을 들여야 고객이 반응하지요. (제품을 알리기 위해 뭔가를 시도하는 사람의 노력 또한 비용입니다.)그래서 효율이 중요합니다. '가성비'는 우리가 흔히 사용하는 단어입니다. 다만, 가격 대비 성능이 좋다는 뜻이지요. 하지만 "가성비가 좋다"라고 할 때, 얼마큼 좋은지는 잘 이야기하지 않습니다. 여기 C로 시작하는 지표들은 가성비가 얼마나 좋은지 설명해 주는 지표입니다.

이 지표들은 낮을수록 효율이 좋습니다. 적은 비용으로 더 많은 노출과 클릭 효과를 얻은 것이니까요. 그러나 비용 효율 지표들은 서비스의 특성이나 비즈니스 성숙도에 따라 상이합니다. 예를 들어, 따끈따끈 갓 출시한 게임 광고의 CPC는 50원이 채 안 될 수도 있지만, 생명보험 광고는 50,000원이 넘을 수도 있습니다. 무려 1,000배나 차이 나는 이 둘을 동일한 선상에서 비교하려면, 제품의 가격 같은 정보가 필요하겠죠. 이는 중간 퍼널에서 살펴보겠습니다.

■ CTR(Click-Through Rate)

클릭률입니다. 주로 도달보다는 노출 대비 클릭된 비율을 의미합니다. CTR을 구하는 공식은 "(클릭/노출)*100"입니다.

클릭률이 높은 광고는 그만큼 주목도가 높을 것입니다. 이 경우 대체로 비용 효율 지표인 CPC도 함께 낮아집니다. 이렇게 비율을 나타내는 지표까지 확인하고 나면 상단 퍼널은 끝이 납니다. 간단하죠? 이미지로 요약하면 다음과 같습니다.

<출처: 작가>

클릭률을 계산할 땐 도달이 아니라 노출이 사용되는데요. '도달'의 주체는 '유저'이고, '노출'의 주체는 '광고'이기 때문입니다. 만약 도달을 사용하려면, 이에 대응하는 '유저당 클릭 수'라는 새로운 지표가 필요할 것입니다.

2. 중간 퍼널

중간 퍼널에는 상단 퍼널에 이어서 마케팅 성과를 나타내는 지표와, 서비스 운영을 위해 사용되는 지표가 혼재합니다. 마케팅이나 제품 운영에 치우치지 않고, 이 영역 전체를 고르게 이해해야 합니다.

그 시작은 방문입니다.

■ 방문(Visit, Traffic)

사이트에 고객이 방문한 횟수입니다. 흔히 '트래픽'이라고 합니다.

■ 신규 유저

처음으로 방문한 고객을 의미합니다. New User, User Acquisition 등, 제품의 형태에 따라 다양한 이름으로 부릅니다.

■ 재방문 유저

사이트를 여러 번 방문한 횟수를 의미합니다.

■ 일일/주/월간 방문자 수(DAU, WAU, MAU)

각각 하루, 한 주, 한 달 치를 묶어 방문자 수를 합산한 값입니다.

제품 단위에서 재방문을 측정하면 그냥 방문 수가 될 뿐입니다. 신규유저의 방문 유저수 정도가 유의미하죠. 그런데 재방문은 너무나도 중요한 지표이기 때문에 어떻게든 파악하고 관리해야 합니다. 여기에 MAU 같은 지표가 사용되는데요. 그 이야기는 하단 퍼널에서 좀 더 다뤄보겠습니다. 지금은 방문 이상으로 중요한 지표인 "전환"에 대해서 좀 더 이야기해 볼까요?

■ 전환(Conversion)

서비스가 고객에게 제공하는 다양한 이벤트 중에서, 가장 유의미한 이벤트를 의미합니다. 대체로 서비스의 성장이나 매출에 유의미한 이벤트들인데요. 좀 더 자세히 알아보겠습니다.

구매: 전자상거래 서비스에서 가장 많이 사용되는 전환으로, 매출과 직결됩니다.
장바구니 : 대체로 장바구니에 물건을 담은 고객은 구매할 확률도 높습니다. 중간 지표로 많이 사용됩니다.
설치: 앱을 광고할 때 가장 많이 사용되는 전환입니다. 스토어 경쟁력, 제품의 잠재력 등에 영향을 줍니다.
회원가입: 골고루 많이 사용되는 전환입니다. 유지율이 높은 서비스, 회원 수 상승이 매출에 영향을 크게 주는 서비스에서 사용됩니다. 그게 아니더라도 서비스 운영에서는 매우 중요한 지표입니다.
정보 제출: 병원, 부동산, 차량 등 고관여 도메인에서 주로 사용됩니다. 정보가 수집되면 이후에 ARS를 통해 고객에게 연락을 하게 되는데, 이 경우 "예약 완료"와 같은 최종 전환 지표가 사용될 수 있습니다.
유입: 유입 자체가 전환인 경우도 있습니다. 사람들이 많이 봐야 하는 이벤트, 신제품이나 브랜드 론칭을 알려야 하는 상황입니다. 이 경우 상단 퍼널에서 '클릭'을 극단적으로 높이기 위한 전략이 사용될 수 있습니다.

'전환'으로 퉁치는 것보다 위와 같이 구체적인 이벤트명들을 나열하는 게 알아보기 좋습니다. 왜냐하면 다양한 전환 지표들이 동시에 사용되는 경우도 많기 때문입니다. 특히 "장바구니 > 구매", "설치 > 회원가입", "정보제출 > 예약완료"는 모두 전환 이벤트인데요. 각각의 전환을 정류장이라고 생각하면, 고객의 여정도 함께 이해할 수 있습니다. 전환이 있다면 전환율도 빠질 수 없겠죠

■ CVR(Conversion Rate)

전환율은 보편적으로, 전체 노출 수 대비 전환율을 이야기합니다. 그러니 자연스럽게 상단 퍼널과 함께 보는 경우가 많습니다. 그런데 고객 여정 사이에 발생하는 전환도 모두 전환율로 표현할 수 있습니다.

■ 이탈률(Bounce Rate)

사실 이때는 전환율보다 이탈률을 더 많이 사용합니다. 장바구니에 물건을 담은 고객이 100명이고, 결제까지 진행하지 않은 고객이 80명이라면 이탈률은 80%인 형태입니다.

광고의 노출로부터 클릭 그리고 회원가입과 장바구니, 구매까지 모든 지표를 이어 붙이면 더욱 커다란 그림이 그려집니다. 위와 같이 중간 퍼널에서 가장 중요한 것은 "전환"입니다. 상단 퍼널에서 어렵게 고객을 모셔 왔으니, 어떻게든 전환까지 안전하게 에스코트해야겠죠. 그러려면 고객을 잘 이해해야 합니다. 어떤 고객이 "전환"을 일으킬까요?

■ 페이지 조회(Page View)

어떤 페이지는 굉장히 중요합니다. "상품 상세 페이지"가 대표적입니다. SaaS 서비스의 경우 가격 'Price' 페이지가 매우 중요합니다. 좀 더 특별하게 고객 한 명의 고유한 조회수는 'Unique page view'라고 합니다.

■ 세션(Session)

세션은 조금 더 광범위합니다. 사용자가 제품에 랜딩 된 순간 카운트되며, 활동이 중단된 뒤 30분(GA 기준) 후에는 세션이 만료됩니다. 그리고 다시 접속하면 세션이 추가되는 식입니다.

세션은 제품 자체에 대한 고객의 참여도를 판단하는 데 사용됩니다. 세션이 상대적으로 높은 제품은 고객의 참여도가 높은 제품이겠지요. 커머스보다는 SNS, 게임, 웹툰, 소설 플랫폼 등의 콘텐츠 서비스에서 그 가치를 발휘합니다.

■ 유지 기간(Duration)

고객이 사이트에 머무는 시간을 의미합니다.

서비스 분야를 가리지 않고 중요한 지표입니다만, 유지 기간이 길다고, 무조건 좋다고 보거나, 짧다고 나쁘다고 볼 수 있는 지표는 아닙니다.

■ 이벤트(Event)

서비스가 고객에게 제공하는 다양한 이벤트 중에서, 가장 유의미한 이벤트를 의미합니다.

제품 내에서 고객이 할 수 있는 행동은 생각보다 제한적입니다. 그리고 고객이 하는 모든 행동은 이벤트입니다. 페이지를 보는 것, 버튼을 클릭하는 것, 스크롤을 내리는 것, 모두 이벤트입니다. 여기서 좀 더 유의미한 이벤트는 대표적으로 보는 것과 클릭하는 것이죠.

전자상거래 서비스에서 구매하기만큼 중요한 이벤트가 뭐가 있을까요? 바로 '리뷰 작성'입니다. 마찬가지로 '리뷰 자세히 보기' 또한 굉장히 중요한 이벤트입니다. SNS라면 '친구 추가'가 매우 중요한 이벤트겠죠. '정보 제출'같이 전환 여정이 긴 이벤트의 경우 단계가 구분될 텐데요. 이때는 '2단계로 이동'과 같은 버튼은 아주 중요한 이벤트가 될 수 있습니다.

고객을 이해하는 것은 시장을 이해하는 것과도 같습니다. 제품의 가치를 증명해야 한다면, 그 시작과 끝에는 고객이 있습니다. 위 지표들은 정말 기본적인 지표입니다. 그러나 직접 다양한 사례를 경험해야 체감되기 시작할 것입니다. 마지막에 다룰 하단 퍼널에 대해 스포일러하면, 전부 다 "고객 이해"에 대한 이야기뿐입니다.

■ CPA(Cost Per Action)

한 명의 고객에게 어떤 행동을 하게 만들기 위해 지불하는 비용입니다. 전환 단가라고 하며 공식은 광고 비용/액션 수입니다.

중간 퍼널에도 비용 효율 지표는 빠질 수 없겠습니다. 흔히들 CPA라고 이야기해서 하나의 지표처럼 적어두었는데요. CPI(Install), CPS(Sales), CPL(lead)와 같이 구체적인 전환 지표명을 명시하는 경우가 더 많습니다.

■ 매출 (Revenue)

전환을 통해 얻는 이익입니다. 그래서 상품의 판매를 통해 수익을 얻지 않을 경우 'Conversion Value'라고 표현할 수도 있습니다.

<출처: 작가>

비용과 비용 효율 지표에 대한 이야기까지 마쳤으니, 중간 퍼널을 슬슬 마무리해야겠네요. 중간 퍼널의 지표를 이해할 때는 조심해야 할 행동이 있습니다.바로 "오로지 숫자만 믿는 행동"을 피해야 합니다.

고객이 화면의 어떤 지점에 머물까요?
고객이 어떻게 생긴 버튼을 클릭할까요?

정량화된 숫자만으로는 결코 알 수 없습니다. 'A 버튼의 클릭 수'나, '10번 상품의 상세 페이지의 25% 부분에서 머문 시간" 같은 것은 숫자만으로 유의미하지 않다는 의미입니다.

중요한 버튼인데 잘 눈에 띄지 않아 엉뚱한 화면에서 클릭됐을 수 있습니다. 또 대부분의 고객이 상품 상세 페이지의 25% 부분에서 오래 머물고 있다면, 25% 부분에는 도대체 어떤 콘텐츠가 있는지 유심히 살펴볼 필요가 있습니다. 조그만 글씨가 빼곡히 들어차 있나요? 그렇다면 불친절한 우리의 서비스를 이해해 줄 만큼 고객의 아량이 넓다는 것입니다.

<출처: Freepik>

여러 고객의 방문이 만들어 낸 단 한 번의 전환은 앞으로의 수많은 가능성을 만들어냅니다. "User Activation" 이제 우리의 고객은 활성화되었습니다.고객 입장에서 좋은 비유는 아닙니다만, 저는 이 여정이 마치 "테라리움"을 꾸미고 생물을 키워나가는 과정처럼 느껴집니다. 인공적으로 생물이 살기 좋은 환경을 조성하고, 이들이 잘 살아갈 수 있도록 하는 과정이요. 그런데 조금이라도 관심을 끈 순간, 생물은 모두 죽어버릴 것입니다.

3. 하단 퍼널

깔때기의 끝부분, 하단 퍼널은 생물이 테라리움에서 지속적으로 살 수 있도록 하는 역할입니다. 고객이 우리 제품을 꾸준히 이용할 수 있도록 하는 것, 바로 "User Engagement"가 여기서 일어납니다. 한국어로는 뭐라 정의하기 힘든데요. 고객이 최초의 활성화를 넘어, 서비스에 깊이 빠져든 순간을 의미합니다.

시작부터 너무 어렵게 생각할 필요는 없습니다. 그냥 전자상거래 서비스라면 재구매 1번, 혹은 2번 정도를 인게이지먼트로 정의해도 되고, 30만 원 이상 구매와 같은 구체적인 수치를 정의해도 좋습니다. 그러나 여기에는 기간이 따라붙어야 더욱 유의미해집니다. "1년간 30만 원 구매"와 같은 형태로요.

상단과 중간 퍼널은 마치 게임 스테이지를 클리어하듯 각각의 단계를 밟고 지나간 느낌이라면, 하단 퍼널은 조금 다릅니다. 하단 퍼널의 지표들은 모두 고객의 생명력을 의미합니다. 모든 생명은 짧거나, 길거나 그 끝이 있습니다. 생명력 같은 조금 무거운 비유를 사용했습니다만, 제품을 운영하는 입장에서 고객의 가치는 그만큼 무겁습니다.

그렇다면, 본격적으로 하단 퍼널에서 사용될 지표들을 알아볼까요?

■ 유지율(Retention)

유지율은 전체 고객 대비 일부 고객이 서비스에 유입된 n일 후 여전히 서비스를 이용할 비율입니다.

쉽게 생각하면 다음과 같습니다. 오늘 방문한 고객 100명이 다음 주에는 7명 방문한다면? 그렇다면 7일 유지율은 7%인 것입니다. "기간"을 빼놓을 수 없습니다.

■ 고착도(Stickiness)

유지율에 대해 추가로 설명하겠지만 유지율은 생각보다 직관적이지 않습니다. 그래서 이를 대체해서 좀 더 직관적으로 '고착도'를 사용합니다. 어렵게 생각할 것 없고, "DAU/MAU*100" 혹은 "DAU/WAU*100" 같은 식으로 계산합니다. 즉, "월간 혹은 주간 방문자 대비 일간 방문자가 몇 명인가?"를 백분율로 표시한 값이지요. 역시 "기간"을 빼놓을 수 없습니다.

그런데 전자상거래 서비스라면 반복 횟수가 많다고, 건전한 운영이 이뤄지긴 어렵습니다. 그런 경우에는 재구매율이 더욱 중요하겠죠.

■ 재구매율

말 그대로 유저가 다시 구매할 확률이며, "기간"을 기준으로 사용하는 경우가 대부분이며, 아래에서 설명할 "고객 분류"별로 세분화해서 보는 경우가 많습니다.

■ 이탈률(Churn rate)

'Bounce rate'와는 다릅니다. 'Churn rate'는 일반적으로 활성화(Activate)된 유저가 이탈하는 비율을 의미합니다. 이를테면 서비스의 구독 취소나 장기간 미접속 등이 해당됩니다. 공식은 "고객 이탈률 = (이탈 고객 수 / 기존 고객 수) * 100"이지만, 여기에 특정 기간을 대입해야 더욱 효과적으로 관리할 수 있습니다.

한 번 Churn 된 고객을 다시 데려오는 건 정말 어려운 일입니다. 그런데 왜 유지율은 고착도 대비 직관적이지 않을까요? "동질 집단"때문입니다.

■ 동질 집단(Cohort)

유사한 성질을 공유하는 고객 집단입니다. 주로 고객이 유입된 시기, 영향을 준 이벤트 등을 바탕으로 지속적인 추적에 사용됩니다.

예를 들어, 회원가입 이벤트로 유입된 고객은 7일간 유지율이 1%지만, 구매 리워드 이벤트로 유입된 고객의 유지율은 4%가 넘습니다. 이들은 각각 7월과 8월에 처음 서비스를 이용하기 시작했습니다. 유지율이 "4%"라고 하는 건, 어떤 동질 집단에 대한 유지율인지 따로 설명하지 않으면 단번에 파악하기 어렵습니다.

그러나 고착도는 최근 날짜를 기준으로 대충 보기 쉽게 가공한 값입니다. 이해하기 쉽고 직관적이죠. "최근 한 달간 접속한 유저수 대비 오늘 접속한 유저수"별로 헷갈릴 일이 없습니다.

당연히 고착도가 무작정 옳은 것은 아닙니다. 제품을 운영하는 사람이라면 다양한 동질 집단을 바탕으로, 유지율을 꼼꼼히 들여다봐야 합니다. 고착도는 요약하거나, 간단한 공유 시에 사용하기 좋습니다. 뒤에서 설명할 LTV랑도 비슷합니다.

일정 수준의 유지율을 가진 집단은 그들만의 특징을 갖곤 합니다. 기간을 바탕으로 동질 집단을 분류하는 게 아닌, 특정한 조건을 성립시킨 고객을 분류하는 것입니다. 이건 "고객 분류"라고 부릅니다.

■ 고객 분류(User Segmentation)

고객을 분류하는 공식은 없지만 기준은 있습니다. 크게는 회원과 비회원 좁게는 '일주일간 3일 이상 접속한 유저', '친구에게 우리 제품을 소개한 유저' 등, 다양한 기준이 존재합니다.

코호트와 세그먼트는 정말 유사합니다. 둘 다 어떤 특징을 공유하는 동일한 집단을 의미합니다. 그러나 코호트 분석은 아래의 표와 같이 특정 시점으로부터의 유지율을 중심으로 하는 분석이 대부분입니다. 고객 분류를 활용한 분석은 조금 더 다양한 형태로 활용됩니다. 제 개인적으로는 코호트 분석은 세그멘테이션 분석의 하위 요소라고 정의하고 있습니다.

<출처: 작가>

고객을 분류하는 일은 매우 중요합니다. "우리의 열성 고객은 어쩌다 우리 제품을 사랑하게 되었을까?" 이를 위한 기준을 정하고, 기준을 충족한 고객을 찾아 나서는 과정을 정말 즐거우면서도 고단합니다. 그러나 마침내 "가입 후 10일 내에 7명 이상의 친구를 만든 고객"이 열성 고객이 된다는 결론에 도달했을 때, 페이스북의 '아하 모먼트'와 같은 그로스 해킹 사례가 만들어지는 것입니다. 아하 모먼트 역시 참 중요한데, 이는 나중에 다뤄보겠습니다.

<출처: 작가>

고객을 분류하는 방식은 정말 다양합니다. Recent(최근)에 Frequency(어떤 빈도)로 Monetization(돈 쓴) 고객을 나누는 방식도 있습니다. RF 분석이라고 하죠. 이렇게 나눠진 고객은 CRM에 적극적으로 활용됩니다. 당연히 잦은 빈도로 많은 돈을 쓰는 고객은 VIP가 됩니다.

자, 이제 슬슬 마무리할 때가 된 것 같은데요. 대부분의 제품에서 가장 중요한 것은 매출입니다. 광고비용을 지출하는 것도 결국은 매출을 내기 위함이니까요. 이러한 지출과 매출 관점에서 본다면, 1조 원을 쓰고, 10조를 벌었다면 대단히 성공한 서비스입니다. 반대로 100원을 써도 99원을 벌었다면 실패한 서비스고요.

■ CAC(Customer Acquisition Cost)

'고객 획득 비용'이라고 합니다. 한 명의 고객을 데려오기 위해 우리가 써야 하는 돈입니다. 작게는 광고비용부터 크게는 제품을 개발하기 위해 사용한 비용도 포함됩니다.

돈을 썼다면 벌기도 해야겠죠? 다음은 매출 지표입니다.

■ ARPU(Average Revenue Per Use)

고객 한 명당 제품에 지출한 평균 비용입니다. 전자상거래 서비스에서는 객단가라고 흔히 부릅니다.

■ ARPPU(Average Revenue Per Paying User)

제품 내에서 결제한 고객 한 명당 지출한 평균 비용입니다. 전자상거래 서비스에서는 구매 객단가라고 합니다.

이 두 지표 모두 "기간"과 함께 사용됩니다. 예를 들면, "1년간 ARPU가 30,000원!" 이런 식입니다. 여기에도 고착도처럼 조금 직관적인 지표가 있습니다.

■ ROAS(Return on Ad Spend)

광고비 대비 매출을 나타내는 지표이며 공식은 "(매출/비용)*100"입니다. 높을수록 들인 비용 대비 매출이 크다. 즉, 효율이 좋았음을 의미합니다.

비용과 매출을 섞어서 ROAS로 볼 수도 있습니다. 단, ROAS 는 광고비 대비 수익률임에 유의해야 합니다. 만약 인건비 등 모든 비용 대비 수익률을 보려면, ROI와 같은 지표를 사용해야 하는데요. 그러면 글이 더 길어질 테니 이번엔 ROAS 까지만 이야기하겠습니다.

ROAS는 즉각적인 광고 대비 성과를 나타내지만, 좀 더 장기적으로 성과를 나타내는 지표도 있습니다.

■ LTV(Life Time Value)

'고객생애가치'라고 합니다. 한 명의 고객이 우리의 제품에 평생 지출할 금액을 의미합니다.

그러니까 LTV가 CAC보다 높다면 성공한 서비스겠군요. 그런데 고착도의 사례를 떠올린다면, LTV도 좀 더 정확하게 파악하는 방법이 있겠죠? 제품 운영자를 위한 고객생애가치 지표가 따로 존재합니다. 바로 CLV입니다.

■ CLV(Customer Lifetime Value)

RFM 분석에서 한발 더 나아간 지표입니다. CLV는 이렇게 분류된 집단이 확률적으로 특정 기간 동안 얼만큼 비용을 소비할지 예측한 값입니다.

LTV와 CLV는 모두 선행지표의 성격을 가지고 있습니다. 예측과 목표에 가깝다는 의미죠. 그런데 예측하고 목표로 삼으려면, 좀 더 명확해야 합니다. 과거엔 미사일이 표적을 정확히 맞출 확률이 매우 낮았다고 합니다. 지금은 정말 정밀한 타깃도 명중할 수 있다고 하는데요. 과거보다 더 많은 요인들을 분석하고 이를 바탕으로 결괏값을 예측하기 때문입니다.

CLV는 다양한 고객 분류별로 생애 가치를 측정합니다. 'A그룹 고객은 40,000원, B그룹 고객은 35,000원'과 같은 식으로요. 그리고 B그룹 고객의 특성을 파악하고, A그룹으로 전이시키기 위한 단서도 제공합니다. CLV 덕분에 운영자들의 할 일이 더 늘어나는 것이죠. (참고)

<출처: 작가>

위 그림은 모든 퍼널의 지표를 한 장으로 요약한 그림입니다. 여정으로 시작해서 분류로 끝납니다. 비용을 투입하다가 매출로 끝납니다. 물론 끝이 아니라 순환이지만요. 이 그림 속에서 모든 지표들은 서로 관계를 맺고 있습니다. 한정된 클릭 안에서 더 많은 전환이 일어난다면, CPA는 개선되고, CAC도 낮아지고, 나아가 ROAS도 개선되는 형태로 말이죠. 구매한 고객의 유지율을 잘 지켜낸다면, LTV도 조금씩 나아질 겁니다.

물론 퍼널을 나누는 방식은 제품이나 팀마다 조금씩 다를 수 있습니다. 그러나 지표가 서로 어떻게 영향을 주는지 그 방식을 명확히 이해한다면, 얼마든지 다양한 형태로 그림을 그려나갈 수 있겠죠?

마치며

쓰다 보니 글이 길어졌는데, 제품 운영을 위한 전체 퍼널을 쉽고 빠르게 이해할 수 있는 가이드 글을 만들고 싶었습니다. 업계에서는 이러한 퍼널을 각자의 역할로 분리해서 생각하는 경우가 많은데요. 그도 그럴 것이 부서별로 신경 써야 하는 지표가 다르기 때문입니다. 이번 글을 통해 지표를 이해하는 것도 중요하지만, ‘진정한 성장은 한두 개의 지표를 바라거나, 핵심 KPI만 신경 쓰는 것만으로는 이뤄질 수 없다’라는 점도 꼭 기억해 두시면 좋겠습니다.

<원문>

서비스를 운영하는 모든 기획자를 위한 지표 안내서

]]>

AI로 더 똑똑하게 페르소나와 저니맵 만드는 법

본문은 요즘 IT와 번역가 Yuna가 함께한 카일 수시(Kyle Soucy)의 글 <How I’m using AI to streamline persona and journey map creation>을 번역한 글입니다. 필자는 25년 경력의 UX 리서치 전문가로, 다양한 업계를 대상으로, 사용성 테스트와 정성적 사용자 연구를 수행하는 컨설팅 회사 ‘Usable Interface’의 설립자입니다. 이 글은 UX 실무자들이 AI의 힘을 빌려 더 빠르고 깊이 있게 페르소나와 저니맵을 설계할 수 있도록 돕습니다.

필자에게 허락을 받고 번역했으며, 글에 포함된 링크는 원문에 따라 표시했습니다.

필자카일 수시의 페르소나와 저니 맵 예시

AI는 우리의 업무를 더 효율적으로 만들어 주지만, 실제 UX 리서치와 분석을 통해 얻는 핵심 인사이트를 완전히 대체할 수는 없습니다.

일을 더 잘하게 해주는 AI, 하지만 사람을 대신하진 못합니다.

저는 UX 리서치 분야에서 20년 넘게 일해왔는데요, 처음에는 AI를 리서치 실무에 접목하는 것에 대해 다소 회의적이었습니다. 하지만 실제로 ChatGPT, Google Gemini, Microsoft Copilot, Claude.ai 같은 생성형 AI(GenAI) 도구들을 사용해 보니, 그 유용성은 기대 이상이었죠. 이 도구들은 단순히 데이터를 분석하는 데 그치지 않고, 도출한 인사이트를 UX 페르소나나 여정 지도 같은 핵심 산출물로 구체화하는 데에도 큰 도움이 되었습니다.

AI 프롬프트를 활용해 UX 페르소나나 저니맵을 만드는 방법은 이미 다양하게 소개되어 있습니다. “AI로 UX 페르소나 만드는 법”을 검색만 해도 수많은 자료를 찾을 수 있는데요. 저도 그중 일부는 참고해서 본문 말미에 출처로 정리해 두었습니다. 그런데도 제가 이 글을 쓰게 된 이유는, 지난 1년간 다양한 프롬프트 조합을 실험해 보면서 기존 자료에서는 잘 다루지 않았던 표현 방식과 구성의 차이를 활용해, 꽤 효과적인 접근법을 발견했기 때문입니다.

이 과정을 통해 얻은 인사이트가 다른 UX 리서처 분들께도 도움이 될 수 있지 않을까 하는 생각에 이렇게 공유하게 되었어요. AI를 UX에 적용하는 방법은 앞으로도 계속 진화하겠지만, 그 과정에서 서로의 경험을 나누고 함께 고민하는 것이 무엇보다 중요하다고 생각합니다. 혹시 이 글에서 소개한 프롬프트를 사용해 보셨거나, 또 다른 방식으로 좋은 결과를 얻으신 적이 있다면 댓글로 경험을 공유해 주세요.

페르소나 만들기

필자가 Canva.com으로 제작한 페르소나 예시

UX 페르소나는 크게 두 가지로 나눌 수 있습니다. 바로 실제 사용자 리서치에 기반한 페르소나와, 가정에 기반한 페르소나인데요. 데이터 기반으로 만든 페르소나든, 가설 페르소나(proto-persona), 임시 페르소나(ad-hoc persona), 합의 페르소나(alignment persona)처럼 가정에 기반한 페르소나든, GenAI가 이런 작업에 특히 효과적입니다.

가설 페르소나에 대해서는 아래 내용을 참고하세요.

제 경험상, 제품 팀 외의 분들은 페르소나와 가설 페르소나의 차이를 명확히 구분하지 못하는 경우가 많았습니다. 그래서 저는 가설 페르소나를 만들 때 ‘가정 기반 페르소나’라는 표현을 의도적으로 사용합니다. 이 표현을 쓰면 아직 실제 사용자 리서치가 이뤄지지 않았다는 점을 명확히 전달할 수 있기 때문인데요. 리서치 없이도 페르소나를 만들었다고 착각하게 만드는 상황만큼 곤란한 일도 없습니다. 예를 들어, 가설 페르소나를 보여줬더니 ‘이걸로 페르소나는 끝났네’ 하며 바로 다음 단계로 넘어가려는 경우가 대표적이죠.
가설 페르소나 작성법이 궁금하시다면, 타마라 애들린의 얼라인먼트 페르소나 자료를 참고하세요.

사용자 리서치를 기반으로 만든 페르소나라 하더라도, 그 안에 담긴 정보는 종종 허구적인 형식으로 표현되곤 합니다. 물론 제품의 평균적인 사용자를 정확히 반영하고 있지만, 이름이나 배경 이야기, 짧은 소개 문구 같은 창작 요소들은 페르소나에 생명력을 불어넣고, 더 현실감 있게 다가오도록 도와주죠. 이런 부분이 페르소나를 더 기억에 남게 만들고, 실제 사용자와 잘 연결되도록 해주는 역할을 합니다. 그런데 솔직히 말해, 저는 이런 허구적인 디테일을 쓰는 게 가장 어렵습니다. 그래서 이 부분에서 GenAI의 도움을 가장 많이 받게 되죠.

리서치와 분석을 통해 어떤 데이터를 넣고, 어떻게 나눠야 할지는 저도 잘 알고 있습니다. 하지만 그 내용을 어떻게 자연스럽고 설득력 있게 풀어낼지에서는 늘 고민이 생깁니다. 어떤 분들에겐 이 과정이 페르소나 만들기의 가장 재미있는 부분일 수 있지만, 저는 짧은 한 줄짜리 소개 문구 하나를 놓고도 몇 시간을 고민하는 경우가 많거든요.

저는 데이터를 분석하고 정성적 인사이트를 뽑아내는 걸 좋아하지만, 창의적인 글쓰기를 잘하는 사람은 아니라고 생각합니다. 그런데 바로 이런 부분이 페르소나를 더 입체적이고 공감 가는 존재로 만드는 데 핵심이 되기도 하죠. 물론 혼자서도 결국은 해낼 수 있겠지만, 시간과 에너지가 훨씬 더 많이 들기 때문에 이럴 땐 AI의 도움을 받는 편이 훨씬 효율적입니다.

최근에는 HeyMarvin, ChatGPT Team 같은 GenAI 도구들을 활용해서 이처럼 창의적인 서술이 필요한 부분들을 보완하는 실험을 해보고 있는데요. 이런 방식으로 AI를 잘 활용하려면, 핵심적인 작업은 먼저 사람이 정리해 놓은 상태에서 시작하는 게 가장 효과적이라는 걸 느꼈습니다.

1단계: 리서치 데이터와 인사이트를 모두 모으세요

사용자 리서치를 진행했다면, 인터뷰 녹취록이나 리서치 보고서 등 모든 자료를 빠짐없이 정리해 두세요. 만약 가설 페르소나를 만드는 단계라면, 브랜드 전략 보고서나 업계 분석 자료, 연말 결산 보고서, 이전 설문조사 결과, 시장 조사, 고객센터 데이터 등과 같은 2차 리서치 자료를 최대한 모아 분석하는 것이 중요합니다. 또는 우리 팀이 타겟 유저에 대해 가지고 있는 가정이나 추측이 담긴 문서라도 괜찮습니다. 어떤 형태든, 출발점이 되는 정보가 필요합니다.

2단계: 어떤 항목과 질문을 할지 결정하세요

페르소나는 모두 똑같이 만들 필요는 없습니다. 리서치 목적에 맞게 어떤 항목을 포함할지 결정하는 것이 핵심인데요. Steve Mulder의 “사용자가 언제나 옳다”에서 언급했듯, 페르소나의 모든 요소는 반드시 목적이 있어야 합니다. 각 항목은 팀이 사용자 집단을 더 잘 이해하고 공감하는 데 도움이 되어야 하죠. 특히 배경 정보는 제품이나 서비스와의 맥락 안에서 의미 있는 것이 중요합니다. 제품 사용과 관련 없는 사적인 정보는 과감히 생략해도 괜찮습니다. 오히려 그런 정보는 페르소나의 전달력을 흐릴 수 있어요.

3단계: GenAI 툴에 문서를 업로드하세요(데이터셋 만들기)

사용하는 툴에 따라 업로드할 수 있는 파일 형식은 다를 수 있습니다. 현재 ChatGPT Plus나 Team 버전에서는 PDF, TXT, JPEG, PNG, DOCX, CSV, XLS 형식의 파일을 업로드할 수 있습니다.

업로드 전에 데이터 보안 관련 주의사항을 확인하세요.

ChatGPT Plus에 업로드된 파일은 서비스 내에 무기한 보관될 수 있으며, 해당 파일이 OpenAI 모델 학습에 사용될 수도 있습니다. 따라서 중요한 개인정보나 민감한 데이터를 포함한 파일은 업로드하지 않는 것이 좋습니다. 보다 안전한 환경이 필요하다면, 대화 내용이 학습에 사용되지 않고 데이터가 암호화되는 ChatGPT Team 계정을 사용하거나, HeyMarvin, Dovetail과 같은 전문 UX 리서치 분석 툴이 좋습니다.
추가로 현재 ChatGPT Team에는 워크스페이스에 누구든지 새 멤버를 초대할 수 있는 보안상의 허점이 존재합니다. 따라서 멤버 관리 페이지를 정기적으로 확인하시는 걸 권장드립니다. ChatGPT Enterprise는 이와 같은 보안 문제가 없습니다. 고객 데이터나 사내 데이터를 다룰 경우, 도입 전에 반드시 IT팀과 협의하여 해당 툴이 회사의 데이터 보안 정책에 부합하는지 확인하시기 바랍니다.

4단계: AI 프롬프트 입력하세요

아래 프롬프트는 상황에 맞게 조정하여 사용하시면 됩니다.

AI 프롬프트:

[회사명]은 자사의 [제품명]을 리디자인하여 타겟 사용자에게 더 효과적으로 다가가고자 합니다. 이 [제품명]의 주요 타겟은 [X] 입니다. 마케팅팀에 따르면, 이 타겟은 [간단한 정의]로 설명됩니다. 이 주요 타겟은 [제품명]을 통해 [사용자 목표]를 달성하고자 합니다.

제공된 타겟 정의, 배경 자료, 리서치 인터뷰 내용을 바탕으로 이 [주요 타겟 사용자]에 대한 페르소나를 작성해 주세요. 페르소나에는 다음 항목들이 포함되어야 합니다: 가치관, 동기, 선호 브랜드 및 연관 대상(비슷한 타겟이나 공통의 관심사/가치를 가진 브랜드나 조직 등), 목표, 도전 과제, 필요사항, 인구통계 정보, 행동 특성, 회사와의 접점 (온라인 및 오프라인 포함).

5단계: 결과 검토 및 다듬기

처음 받은 결과가 기대한 바가 아니거나, 특정 정보를 더 포함하고 싶을 때는 GenAI에게 여러 방식으로 내용을 수정해달라고 요청할 수 있습니다. 저는 특히 행동 유도 질문을 활용해 페르소나의 특정 항목을 더 풍부하게 만드는 방식을 자주 사용하는데요. 예를 들어 아래 프롬프트처럼, GenAI에게 동기부여나 선호도에 대한 항목을 다시 작성해달라고 요청할 수 있습니다. 참고로 이 질문들은 제가 페르소나 워크숍을 진행하면서 다양한 팀들과 함께 가설 페르소나를 만들 때 실제로 사용하는 질문이기도 합니다.

AI 후속 프롬프트:

아래와 같이 행동과 관련된 이 페르소나의 동기와 선호도 항목을 다시 작성해 주세요.

동기

1. 개인 목표

이 페르소나의 단기적/장기적 개인 목표는 무엇인가요?
이러한 목표를 이루기 위해 어떤 동기가 작용하나요?

2. 직무적인 포부

이 페르소나가 추구하는 커리어 목표나 야망은 무엇인가요?
어떤 요소가 직업적으로 성공하고자 하는 동력이 되나요?

3. 인센티브와 보상

어떤 유형의 보상이나 인센티브(예: 금전적, 인정, 성장)가 이 페르소나에게 가장 매력적인가요?
내적 동기와 외적 동기 중 어떤 방식을 선호하나요?

선호도

1. 라이프스타일

이 페르소나는 어떤 라이프스타일을 추구하며, 이는 어떤 선호도(예: 친환경 제품 선택, 지역 상점 이용)와 연결되나요?
이러한 라이프스타일은 어떤 가치관과 일치하나요?

2. 관심사와 취향

이 페르소나가 즐기는 취미나 관심사는 무엇인가요 (예: 등산, 독서, 문화 행사 참여)?
이런 관심사가 일상생활이나 사회적 활동에 어떤 영향을 미치고 있나요?

3. 사회적 행동 특성

이 페르소나는 사회적 상황에서 어떻게 사람들과 상호작용하나요? 내향적인가요, 외향적인가요?
어떤 형태의 사회 활동(예: 그룹 활동, 1:1 대화)을 선호하나요?

4. 환경 인식

환경 지속 가능성은 이 페르소나에게 얼마나 중요한 가치인가요? 이를 위해 어떤 실천을 하고 있나요?
선호하는 친환경 제품이나 소비 습관은 어떤 것이 있나요?

5. 브랜드 충성도

이 페르소나가 강한 애착을 느끼는 브랜드는 무엇이며, 그 이유는 무엇인가요?
이 페르소나의 가치관과 선호도는 브랜드 선택에 어떤 영향을 미치나요?

6. 의사결정 방식

이 페르소나는 의사결정을 어떻게 내리나요? 분석적인가요, 직관적인가요?
결정할 때 가장 중요하게 고려하는 요소는 무엇인가요 (예: 데이터, 추천, 개인적 감정)?

이런 프롬프트로 후속 작업을 하면 페르소나 결과가 더욱 풍부해지는 경우가 많습니다. 물론 처음부터 이런 행동 유도 질문을 프롬프트에 포함시킬 수도 있지만, 데이터를 한 번에 너무 많이 주기보다는, 단계별로 조금씩 제공하면서 점진적으로 수정 요청을 하는 방식이 더 효과적이라는 걸 알게 되었습니다. 요구사항을 한꺼번에 넣으면 AI 모델이 혼란스러워할 수 있기 때문이죠.

패트릭 니먼의 UX 디자이너와 프로덕트 매니저를 위한 AI 어시스턴트 마스터링 가이드도 프롬프트에 사용자 리서치 질문을 포함시키면, 실제 사용자에 더 잘 부합하는 페르소나를 만들 수 있다고 조언합니다. 예를 들어, “이 페르소나가 실제 사용자와 부합하는지 검증할 수 있도록, 사용자 리서치 질문을 생성해 주세요.”와 같은 문장을 포함하라고 제안합니다.

또한 대규모 언어 모델(LLM)을 활용하면 사용자 기반을 행동 패턴, 선호도, 인구통계 정보 등에 따라 서로 다른 페르소나로 나눌 수 있어 실무에서 유용하게 쓸 수 있습니다. 다만, 한 가지 꼭 유의해야 할 점이 있습니다. 데이터 자체가 어느 한쪽으로 치우쳐 있다면, AI는 그 관점을 그대로 따라 하거나, 오히려 더 강화할 수도 있다는 점입니다.

정확성을 유지하고 싶다면 참고하세요.

모든 GenAI 도구는 완벽하지 않고, 틀린 정보를 제공할 수 있다는 점을 항상 유념해야 합니다. 최종적으로 제공된 결과가 실제 수집한 데이터와 부합하는지를 직접 검토하고 확인해야 합니다. 만약 사용하는 데이터셋에 성별, 인종, 사회경제적 배경 등에 대한 편향이 존재한다면, 생성된 결과에도 그러한 편향이 반영될 수밖에 없습니다.

AI 기반 리서치로 페르소나 만들기 – 단계별 가이드라는 글에서 빌 벌먼은 흥미로운 팁 하나를 소개합니다. 페르소나의 하루를 이야기 형식으로 받아보고 싶다면, 프롬프트에 “사용자 인터뷰 데이터를 바탕으로 이 페르소나의 하루를 스토리 형식으로 작성해 줘.”라고 입력해 보세요.

데이터 기반이든, 가정 기반이든 UX 페르소나를 만드는 작업은 생각보다 섬세한 과정입니다. 그리고 이 과정을 GenAI의 도움을 받을 수 있어요. 특히 창의적인 글쓰기가 익숙하지 않은 분들에게는, 페르소나를 보다 생동감 있고 공감 가는 방식으로 완성하는 데 큰 도움이 될 수 있죠. 사용자 데이터를 면밀히 수집·분석하고, 진짜 사용자 니즈를 반영한 페르소나 요소를 정의한 다음, AI를 전략적으로 활용해 창의적인 표현을 보완해 나간다면, 더 정확하고 매력적인 UX 페르소나를 만들 수 있습니다.

사용자 저니맵 만들기

nulivo.com의 무료 저니맵 템플릿 예시

저니맵을 만들 때도 페르소나 제작과 동일한 절차를 따라 진행하시면 되는데요. 2단계와 4단계에서는 몇 가지 차이점이 있습니다.

2단계에서는 저니맵에 어떤 요소를 포함할지 결정하는 데 충분한 시간을 들이는 것이 중요합니다. 특히, 여정을 구성하는 단계들을 어떻게 나눌지, 각 단계에서 행동, 생각, 해야 할 일과 같은 어떤 사용자 데이터를 보여줄지 명확히 정의해야 하죠. 이 부분은 GenAI에게 맡기기보다는 직접 고민하고 정리하는 것이 좋습니다. 이렇게 정리한 내용은 이후 프롬프트에 포함해 주시면 됩니다. 즉, 3단계에서 업로드했던 문서들과 함께, 최종 정리된 페르소나와 저니맵 요소 정의 내용까지 포함해서 AI에게 전달하는 방식입니다.

4단계에서 사용할 프롬프트는 다음 네 가지 정보를 포함하면 좋습니다.

누가 여정을 경험하는지 (즉, 해당 페르소나)
어떤 여정을 겪고 있는지
그 여정이 어떤 단계들로 나뉘는지
각 단계에서 어떤 정보를 보여줄 것인지 (행동, 생각, 해야 할 일 등)

AI 프롬프트 (일반 예시):

[x] 페르소나의 저니맵을 작성해 주세요. 이번 맵은 [x]의 여정에 초점을 맞춥니다. 단계는 1) [x], 2) [x], 3) [x], 4) [x], 5) [x] 입니다.

각 단계마다 다음 정보를 포함해 주세요.

해야 할 일 – 고객이 달성하려는 목표는 무엇인가요?
행동 – 고객은 무엇을 하나요? 어떤 정보를 찾고, 어떤 상황에 있나요?
어려움이나 도전과제 – 고객이 이루거나 피하고자 하는 것은 무엇인가요?
온라인 접점 – 서비스의 어떤 온라인 요소와 상호작용하나요?
오프라인 접점 – 오프라인에서 어떤 요소와 상호작용하나요?
결정적 순간 – 브랜드, 제품, 서비스 구매 결정에 긍정 또는 부정적인 영향을 줄 수 있는 것은 무엇인가요?

예를 들어, 앱으로 음식을 주문하는 저니맵을 만든다면 저는 프롬프트를 다음과 같이 작성할 거예요.

AI 프롬프트 (앱으로 음식 주문하는 구체적 예시):

상세 페르소나, 사용자 리서치 보고서, 설문 결과, 시장 조사 보고서, 고객 서비스 기록 등 제공된 데이터셋을 활용해, 음식 배달 앱에 대한 사용 저니맵을 작성해 주세요. 이 저니맵의 페르소나는 ‘크리스’입니다. 그는 다양한 음식을 즐기는 바쁜 소프트웨어 개발자입니다. 각 단계마다 데이터 기반 인사이트를 반영해 크리스의 경험을 정확히 보여 주세요.

단계

인지: 크리스가 광고, SNS, 지인의 추천 등을 통해 앱을 처음 알게 되는 단계
고려: 앱의 기능, 혜택, 사용자 리뷰 등을 비교하고 평가하는 단계
가입 및 온보딩: 앱을 다운로드하고, 회원가입을 거쳐 사용법을 익히는 단계
탐색: 다양한 레스토랑과 메뉴를 둘러보며 옵션을 탐색하는 단계
결정: 원하는 레스토랑과 메뉴를 선택하고, 필요에 따라 커스터마이징하는 단계
결제: 주문을 확정하고 결제 및 배달 정보를 입력하는 단계
이행: 주문 상태를 실시간으로 확인하고, 배달 완료까지 진행 상황을 모니터링하는 단계
주문 후 활동: 음식을 받은 후 식사하고, 문제가 있다면 해결하며, 리뷰를 남기는 단계

각 단계에는 다음 정보를 포함해 주세요.

행동: 크리스가 앱에서 수행하는 구체적 행동
생각: 각 단계에서 크리스가 무슨 생각을 하는지
감정: 여정의 핵심 순간마다 크리스의 감정 상태
접점: 앱 및 기타 서비스 요소와의 상호작용 지점
어려움: 크리스가 겪는 불편·과제
해야 할 일: 각 단계에서 크리스가 충족하려는 근본적 필요·업무

저니맵이 시각적으로 구조화되도록 작성하고, 각 요소를 구분해 전체 사용자 경험이 한눈에 보이게 해 주세요.

결과를 검토할 때 저니맵이 데이터와 다르다면, GenAI가 빈 부분을 스스로 추론했을 가능성이 있습니다! 대규모 언어 모델(LLM)은 사용자 행동을 예측하거나 추정하는 데 능하지만, 별도로 지시하지 않으면 이런 추론이 결과에 표시되지 않습니다. 그래서 저는 프롬프트를 좀 더 정교하게 다듬어, 어떤 부분에서 데이터가 부족한지 파악할 수 있도록 요청합니다.

AI 프롬프트 (추론 내용이 명확히 표시되도록 다듬은 예시):

사용자 리서치 보고서, 설문 결과, 고객 피드백 등 제공된 데이터셋을 활용하여, 음식 배달 앱에 대한 UX 저니맵을 업데이트해 주세요. 만약 전체 사용자 여정을 완전하게 이해하기에 데이터가 불충분하거나 구체적인 정보가 없는 경우, 논리적인 추론을 통해 내용을 보완해도 됩니다. 다만, 이러한 추론은 반드시 명확히 표시해 주세요. 데이터 기반 인사이트와의 구분이 확실해야 합니다.

구체적 지시 사항

통합 데이터: 각 여정 단계마다 데이터셋에서 직접 도출한 인사이트를 활용해 주세요. 해당 인사이트가 어떤 자료에서 나온 것인지 (특정 설문 항목, 리서치 보고서 페이지 등)도 명확히 표기해 주세요.
추론 구분하기: 데이터셋에 정보가 부족한 경우, AI의 추론을 허용하되, 해당 내용은 반드시 표시해 주세요. 그리고 왜 그런 추론을 했는지, 데이터 문맥에 기반한 근거도 간단히 함께 작성해 주세요.
추론 표시 방식: ‘추론’’이라는 단어나 기호를 사용해, 데이터에 근거하지 않고 AI가 추측한 내용임을 시각적으로 구분해 주세요.
추론 설명 덧붙이기: 각 추론 항목에는 해당 내용이 왜 필요한지, 그리고 데이터 흐름 속에서 어떤 맥락으로 판단된 것인지 간단한 설명을 함께 작성해 주세요.
세부 사항과 정확성: 저니맵의 각 단계마다 구체적인 설명과 시각적으로 구성해 주세요. 데이터 기반 인사이트와 추론된 내용이 명확히 구분되도록 작성해야 합니다. 이렇게 저니맵의 명확성, 실용성, 전략적 활용도를 높일 수 있습니다.

예상 결과:

이 저니맵은 사실 기반 데이터와 필요한 추론을 유기적으로 통합한 결과물이 되어야 합니다. 각 추론은 명확히 구분되고 정당화되어야 하며, 이를 통해 이해관계자들이 인사이트의 기반을 명확히 파악하고 전략에 반영할 수 있도록 도와야 합니다. 결과적으로, 데이터에 기반하되 불확실성에도 유연하게 대응할 수 있는 사용자 저니맵이 완성되어야 합니다.

네이트 존슨이 프롬프트 엔지니어링 포켓 가이드: AI 모델을 최대한 활용하는 법에서 언급한 것처럼, AI가 특정 형식으로 답변을 하길 원한다면, 그 형식을 프롬프트에 명확히 지정해 주는 것이 중요합니다. 예를 들어, “표 형식으로 작성해.”라고 입력해야 하죠.

이를 위해서는 기회와 해결책 항목을 포함해야 합니다.

저는 보통 저니맵의 각 단계에 기회와 해결책이라는 추가 항목을 한 줄씩 더 넣는 편인데요. 기회는 각 단계에서 나타난 접점, 감정, 좌절을 바탕으로 개선 아이디어를 제시하는 항목이고, 해결책은 그에 따라 UX를 개선할 수 있는 기능이나 디자인 방향을 제안하는 영역입니다. 이 두 항목은 저니맵 속 리서치 데이터를 실제 실행 가능한 전략으로 연결해 주는 핵심 포인트라고 생각합니다. 다만, 이 부분은 GenAI에게 맡기지 않는 것이 좋아요. 일반적으로 데이터셋에는 팀 전체가 가지고 있는 문제 해결 경험과 맥락이 포함되어 있지 않기 때문이죠.

AI를 활용해 저니맵을 작성해 보니, 복잡한 데이터셋을 사용자 여정에 통합하는 과정이 훨씬 빠르고 효율적으로 진행되었고, 각 단계에서의 행동, 생각, 과제, 상호작용이 보다 명확하게 정리되는 경험을 할 수 있었습니다. 또한, AI는 사용자 행동을 예측하고 시각적으로 정리하는 데에도 강점을 보여주었기 때문에 저니맵의 전달력과 활용 가능성 역시 높아졌습니다.

다만, 중요한 점은 AI가 생성한 결과를 반드시 사람이 직접 검토하고 조정해야 한다는 것입니다. 현실 사용자 경험에 맞게 조율하고, 사람만이 제공할 수 있는 인사이트를 반영해야 실질적인 사용자 여정이 완성되기 때문이죠. AI는 사용자 행동을 예측하고 정리하는 데 큰 도움이 되지만, 궁극적으로는 사람의 인사이트가 더해져야 진짜 의미 있는 저니맵이 만들어집니다.

AI는 빠르게 사람은 깊게, 그 사이에서 균형 잡기

UX 디자인 프로세스에 GenAI를 통합해 나가면서, AI의 계산 능력과 인간만이 줄 수 있는 직관과 공감의 균형을 찾는 일이 무엇보다 중요해졌습니다. 진정성 있고 임팩트 있는 페르소나와 저니맵을 만들기 위해서는, AI의 효율성과 우리의 전문성·창의성을 결합하는 방식이 필요하죠. 이러한 조화를 통해, 실제 사용자 경험에 깊이 공감할 수 있는 결과물을 더 빠르고 효과적으로 만들 수 있습니다. 저는 많은 UX 동료 분들이 이 도구들을 직접 실험해 보고 경험을 나누며, 이 흥미로운 기술과 디자인의 교차점에서 함께 새로운 가능성을 열어가시길 응원합니다.

<원문>

How I’m using AI to streamline persona and journey map creation

<참고 자료>

패트릭 니먼의 ‘UX 디자이너와 프로덕트 매니저를 위한 AI 어시스턴트 마스터링 가이드’ - GPT Prompt Guides에서 보기
넬슨 아길라의 ‘ChatGPT에 파일을 업로드하는 방법과 그 이유’ - CNET 기사 보기
네이트 존스의 ‘프롬프트 엔지니어링 포켓 가이드: AI 모델을 최대한 활용하는 법’ - Nate’s Newsletter에서 보기
빌 벌먼의 ‘AI 기반 리서치로 페르소나 만들기 – 단계별 가이드’ - LinkedIn에서 보기
딜런 모리슨의 ‘UX와 AI: ChatGPT로 사용자 페르소나 만들기’ - Medium에서 보기
오로라 할리의 ‘페르소나는 사용자에 대한 기억을 팀에 남긴다’- Nielsen Norman Group에서 보기
타마라 애들린의 ‘Alignment Persona 프레임워크 소개’- Adlin Inc 공식 사이트
스티브 멀더의 ‘사용자가 언제나 옳다: 웹을 위한 실용적인 페르소나 가이드’- Amazon에서 도서 정보 보기
카일 수시의 ‘UX 페르소나를 만드는 법과 활용하는 방법’ - YouTube에서 보기

]]>

AI 시대 기획자가 GPT로 타깃 고객 분석하는 법

AI를 업무에 능숙하게 쓴다고 해서 항상 높은 효율이 보장되는 것은 아니다. 때로는 기획자의 직관력이나 빠른 대응력이 업무에 더 큰 도움을 줄 때도 있다. 그래서 어떤 업무를 할 때, 어떻게 AI와 협력해야 더 만족스러운 결과를 얻을 수 있을지는 기획자로서 늘 고민되는 지점이다. 이번 글에서는 범용적이면서도 무료로 사용할 수 있는 ChatGPT, Grok, Perplexity를 이용해, 타깃 고객 세그먼트를 분석할 때 어떻게 사용하면 좋을지 살펴보았다.

타깃 고객 정의하기

일반적으로 마케팅 활동은 구매 가능성이 높은 고객을 중심으로 이뤄진다. 그래서 우리 고객이 누구인지, 혹은 앞으로 누구를 새롭게 유치할 것인지에 대한 ‘타깃 고객 정의’가 무엇보다 중요하다. 그래서 ChatGPT에게 이커머스에서 구매력이 높고 유망한 타깃 고객을 구체적인 세그먼트로 제안해 달라고 요청했다. 그러자 ChatGPT는 ‘30대 워킹맘이면서 홈 웰니스 루틴족’이라는 흥미로운 답변을 주었다.

이에 ‘ChatGPT’, ‘Grok’, ‘Perplexity’를 활용해 ‘홈 웰니스 루틴족’에 관한 본격적인 리서치와 분석을 진행해 보았다.

1) 타깃의 라이프 스타일과 주요 가치

먼저 홈 웰니스 루틴족이 추구하는 가치와 특징은 무엇이며, 이들의 일상에서 챙기는 웰니스 활동 등 라이프 스타일을 파악하기 위해 질문해 보았다.

질문: 이커머스 신규고객을 확보하기 위해 타깃을 30대 워킹맘이면서도 홈 웰니스 루틴족으로 정했어. 이를 뒷받침할 수 있는 라이프스타일 분석 데이터와 함께 이들의 주요 가치와 특징 그리고 일상에서 겪는 문제와 이를 해결하기 위한 활동들을 뒷받침할 수 있는 관련 데이터를 포함해서 알려줘
답변 1: Perplexity는 타깃의 주요 문제와 해결 방안을 표로 요약해서 정리했고, 관련 데이터를 그래프로 그려달라고 요청했더니 아래와 같이 제시해 주었다.

<출처: Perplexity 답변 일부>

답변 2: Grok은 정보를 우선순위에 맞게 정리한 후, 전략과 요약으로 마무리까지 해주었다.

<출처: Grok 답변 일부>

2) 주요 채널과 구매 결정 영향 요소 파악

다음으로 홈 웰니스 루틴족을 대상으로 한 서비스나 캠페인을 만들기 위한 질문을 해보았다. 타깃 고객에 대한 구체적이면서도 다각적으로 데이터를 수집하고 분석하는 것이 필요하므로 이들이 자주 사용하는 온라인 채널과 정보 탐색 형태에 대해 물어보았다.

질문: 홈 웰니스 루틴족에 적합한 마케팅 채널이 무엇인지 알려줘. 채널 예시는 앱푸시, 문자, 가격 비교, 바이럴, SNS, 인스타그램, 유투브, 인플루언서 등이 있는데, 이 중에 적합한 채널과 이들이 즐겨 이용하는 커뮤니티가 어떤 곳인지, 대표적인 인플루언서는 누구인지, 좋아할 만한 요즘 뜨는 브랜드는 무엇인지, 가장 많이 검색하는 것은 무엇인지 알려줘.
답변: 가장 효과적인 채널로는 모두 공통으로 SNS를 꼽았으며, 50% 이상이 숏폼 광고에 주목하며, 27%가 이를 보고 구매한 경험이 있다는 구체적인 데이터를 제안했다. 특히 Grok의 경우엔 아래 그림과 같이 일목요연하게 결론을 요약해 주는 점이 좋았다.

<출처: Grok 답변 일부>

이처럼 리서치를 하거나 아이디어를 얻을 때 AI는 분명 도움이 된다. 그러나 AI가 준 답변을 그대로 받아들이기보다는, 반드시 추가적인 후속 작업이 필요하다. 예를 들어, AI가 언급한 타깃 고객이 주로 사용하는 미디어 채널과 그곳에서 소비하는 콘텐츠의 활동성 지수(조회수, 댓글, 공유, 좋아요 등)를 실제 데이터로 수집하고 분석해야 한다. 이런 방식으로 검증과 정교화 과정을 거쳐야, 더욱 정확한 타깃 고객 분석이 완성될 수 있다.

타깃 고객 분석하기

이커머스에서는 주로 UV(순방문자 수, Unique Visitor)와 PV(페이지 뷰, Page View)를 토대로, 고객 여정 단계별 전환율을 최적화하는 퍼널 분석을 진행한다. 또한 고객 수가 감소하는 시점을 파악하기 위해 코호트 분석도 수행한다. 이번에도 이러한 분석 방식을 통해 타깃 고객이 선호하는 채널의 퍼널 단계별로 반응을 높이는 방안을 알아보았다.

1) 퍼널과 코호트 분석

먼저 신규 타깃 고객을 유입시킨 후, 그들이 이탈하지 않도록 관리하는 것이 중요하다. 그래서 고객이 주로 이탈하는 시점이 언제인지 파악하고, 해당 시점에서 이탈한 고객을 다시 유입시키기 위한 구체적인 방안이 무엇인지 살펴보았다.

질문: 홈 웰니스 루틴족이 반응할 만한 선호하는 유입 채널 한 가지를 정하고, 해당 채널의 퍼널에서 가장 큰 이탈 지점은 어디이며, 단계별 전환율을 높이고 이탈률을 최소화하기 위한 구체적인 개선 방안을 알려줘.
답변: 퍼널, 코호트 분석과 관련된 그래프를 요청했을 땐, 아래 그림에서 볼 수 있듯이 내용은 Perplexity가 정확했고, 그래프의 형식은 ChatGPT가 퍼널과 코호트 차트까지 그려냈다.

<출처: Perplexity 퍼널 관련 답변 일부>

<출처: ChatGPT 퍼널 관련 답변 일부>

그리고 AI의 답변이 원하는 형태로 나오지 않을 때는, 참고할 만한 이미지를 함께 첨부해서 질문하면 비슷한 형태로 다시 그려준다. 아래 그림은 왼쪽부터 순서대로 ‘처음 답변 → 수정 요청 → 두 번째 답변’의 예시다.

<출처: ChatGPT 코호트 관련 답변 일부>

ChatGPT는 고객이 관심/고려 단계에서 구매 단계로 넘어갈 때, 특히 많은 이탈이 발생한다고 했다. 그래서 인스타그램 릴스(Reels)를 활용해 TOFU(Top of Funnel-인지), MOFU(Middle of Funnel-관심/고려), BOFU(Bottom of Funnel-구매)의 각 퍼널 단계별로 고객 반응을 높일 수 있는 방안을 그림으로 표현해 보았다.

<출처: ChatGPT 퍼널 관련 개선 방안 답변 일부>

2) 타깃 관련 그래프 해석하기

이번엔 Perplexity에서 제시한 채널별 활용 전략 데이터를 ChatGPT에 올리고, 해석해 달라고 요청했고, 다음과 같이 답변했다. 이처럼 여러 AI를 함께 사용하면 더욱 효과적인 결과물을 도출할 수 있다.

질문:

답변:

<출처: ChatGPT 답변 일부>

3) 데이터 기반 아이디어 요청하기

다음으로 데이터 기반에 홈 웰니스 루틴족을 대상으로 그들의 반응을 이끌기 위한 상품과 콘텐츠 제작을 위해 아래와 같이 질문해 보았다. 구체적인 상품으로는 첫 구매 허들 장벽이 낮은 1.8~3.5만 원 정도의 FMCG(빠르게 소비되는 상품, 즉 일용 소비재) 상품, 5분~15분 조리 가능한 밀키트, 즉각 효과를 주는 마스크팩, 수면을 돕는 아로마 오일 등을 제시했다.

질문: 홈 웰니스 루틴족을 대상으로 첫 구매 상품을 만든 후 SNS 리뷰 유도하는 것이 도움이 될 것 같은데, 데이터 기반에 첫 구매 상품 추천과 이와 관련해서 인스타그램 릴스 콘텐츠 제작에 필요한 구체적인 실행방안과 아이디어를 알려줘.
답변: Perplexity는 실제 구매 데이터를 바탕으로 첫 구매에 적합한 상품을 제안해 주었고, 하단의 <관련> 질문을 통해 좀 더 자세히 알고 싶은 추가 정보들도 함께 제공하고 있다.

<출처: Perplexity 답변 일부>

앞서 살펴본 바와 같이, ‘ChatGPT’, ‘Grok’, ‘Perplexity’는 각자 특징과 장점이 다르다. 따라서 하나의 AI만 쓰기보다는 목적에 따라 적절한 도구를 함께 활용해야 원하는 결과물에 가까워질 수 있다. 물론 데이터 해석이나, 다양한 관점에서 아이디어를 얻기엔 AI가 도움이 됐지만, 아직 정교한 분석은 ‘태블로(Tableau)’, ‘GA(Google Analytics)’ 등 다양한 비즈니스 분석 툴을 활용해야 했다.

AI에 능숙한 기획자의 자세

지금까지 AI를 활용해 타깃 고객을 정의하고 분석하는 방법을 살펴보았다. AI를 잘 활용하면 업무의 효율성을 높일 수는 있지만, 현실적으로 모든 업무를 AI로 대체하기는 어렵다. 따라서 AI와 협업하면서 고객과 상품을 명확히 이해하고, 이들을 효과적으로 유입하기 위한 전략을 세우는 것이 필요하다.

더 나아가 실질적인 신규 고객 유입과 재방문율을 높이려면, AI 활용뿐 아니라 실제 매출과 트래픽, 그리고 타깃 고객에 대한 정교한 데이터 분석을 함께 병행할 때 의미 있는 결과를 얻을 수 있었다.

특히 요즘은 이커머스 플랫폼에서 단순히 효율성을 높이는 데만 AI를 활용하는 것이 아니라, 최적의 핫딜 상품을 찾아주는 ‘다사자’, ‘사자’, ‘사공사’와 같은 AI 솔루션을 결합한 딜커머스 관련 신규 서비스들도 생겨나고 있다. 따라서 신규 고객을 유입하는 과정에서도 AI를 활용해 더 다양한 다면적 접점을 고려할 수 있을 것이다. 여기에 더해 각 채널에서 실시간으로 고객이 즉각 반응할 만한 상품을 찾아내고, 이를 통해 전환율을 빠르게 높이는 데에도 AI가 도움을 줄 수 있다.

앞으로 AI를 활용해 업무 효율을 높이는 진정한 기획자의 역량이란, 결국 얼마나 의미 있는 인사이트를 발견하고 차별화된 비즈니스를 만들어 내는가에 달려 있다고 생각한다. 각자의 자리에서 AI를 통해 고객과 상품, 채널과 데이터를 유기적으로 연결하고, 이를 토대로 새롭고 창의적인 비즈니스까지 만들어 낼 수 있다면 분명 큰 경쟁력이 될 것이다.

]]>

PRD 중심으로 AI 에이전트와 제품 개발하기

1년 전, ‘생성형 AI의 시대에 PM이라는 직군/역할은 사라지는 것이 아닌가’ 하는 우려가 팽배했습니다. 그때 당시 PM은 사라지지 않는다는 얘기를 열심히 설명하고 다녔던 기억이 생생합니다.

<출처: 작가>

하지만 이제 AI는 더욱 발전해, 아래 포스팅처럼 PRD만 정확하게 써 내려갈 수 있다면 제품을 개발할 수 있는 시대에 도착해 버렸습니다. (참고로 포스팅을 남긴 분은 현재 빅테크 기업에서 AI 에이전트로 제품을 개발하는 것을 업으로 하는 분인데, 개발 과정에서 여러 차례 재설계와 재개발로 인한 고통을 받고 있다 하시더군요.)

PRD 설계를 잘하는 것이 제일 싸다 <출처: 작가 SNS>

물론 “생성형 AI 시대에 PRD도 AI에 맡기면 되는 게 아니냐?”라는 질문이 나올 수도 있고, 또 여러 사람이 실제 PRD를 작성하는 프롬프팅을 공개하고 있기도 합니다.

하지만 저는 PRD 작성을 AI에게 맡기지는 않습니다. 물론 어느 파트의 유즈 케이스(Use Case)나 예외 케이스(Exceptional Case)를 잡을 때는 사용하고 있지만, 본론을 작성하는 데에는 AI를 필요로 하지 않습니다. 제게는 이 ‘필요로 하지 않는다’는 것이 AI의 쓸모를 말할 가장 정확한 표현입니다. 왜 그렇게 표현할 수 있을까요?

이번 글에서는 AI 시대에 PRD를 작성한다는 것은 어떤 의미인가, 그리고 그렇게 작성한 PRD를 중심으로 AI 에이전트를 활용해 개발하며 겪은 일을 말해 보겠습니다.

PRD는 무엇인가? 설계도인가?

PRD를 작성한다는 것은 한 마디로 ‘내가 무엇을 만들지 잘 알고 있다’는 의미입니다. 내가 무엇을 만들지 잘 알고 있기에 그것을 사용자 시나리오로 작성할 수 있다는 것, 그리고 사용자가 시나리오에서 행위해야 하는 일들을 유즈 케이스로 기술할 수 있다는 의미입니다. 참고로 이는 모든 것을 아주 구체적으로, 매우 디테일하고 정확하게 알고 있다는 것을 포함하지는 않습니다.

PRD에는 어떤 내용이 들어가야 할까요? PRD 또는 제품 스펙(Product Spec) 등으로 검색해 보면 다양한 목차를 만날 수 있습니다. 그리고 그 목차들 모두 정답 카테고리에 포함되어 있습니다. 그런 내용 모두 다 알면 좋겠지요.

하지만 지금 PM으로 일하는 여러분이 회사에서 디자인팀 혹은 개발팀과 함께하는 과정은 어떠한가요? 모두가 그런 내용을 다 알고 있나요? 지금은 그런 세세한 것들을 몰라도 개발할 수 있는데, PRD 중심 개발은 그런 것까지 다 알아야 한다면 훨씬 더 어렵고 험난한 방법론이 아닐까요? 굳이 지금도 AI로 힘들고 불안한 내가 이런 험난한 방법론을 시도해야만 할까요?

저는 PRD 중심 개발 방법론을 꾸준히 강의하며 코칭해오고 있습니다. 아직은 제 강의 실력이나 유명세가 보잘것없다 보니 아주 많은 케이스를 만들고 있지는 않습니다만, 그래도 꾸준히 한두 개 스타트업에 방법론을 강의하고 코칭하며 적용해 보고 있습니다.

마침, 지금 코칭을 진행하고 있는 스타트업에서 기초 강의에 대한 피드백이 굉장히 좋아 많이 들떠있기도 한데요. 물론 이런 피드백은 기본적으로 칭찬일 수밖에 없으므로, 미사여구는 배제하고 주로 어떤 항목과 어떤 내용에서 반응이 나오는지 살펴보세요. 어쩌면 여러분의 회사나 팀에 도움이 될 수도 있을 것입니다.

<출처: 작가>

돌아가 PRD 중심으로 개발하든, PRD 없이 개발 요건을 담은 AC 문서를 기반으로 하든, 혹은 화면정의서나 피그마에 작성한 스크린플로우를 가지고 제품 개발을 하든, 제가 PRD 중심 개발에서 강조하는 핵심은 모두 동일합니다. 다음 한 문장으로 정리해 볼 수 있습니다. (편의상 이 문장을 ‘가치 정의 문장’이라고 칭하겠습니다)

가치 정의 문장: “누가” “왜” 우리 제품을 “어떻게” 사용해 “어떤 가치”를 가져갈 것인가

이것이 우리가 회사에서 제품을 개발하고 산출하고 배포하고 운영하는 이유이자 목적입니다.

그러면 다시, 여러분은 회사에서 AC 문서나 디자인 문서, 스크린플로우를 바탕으로 개발팀과 디자인팀에 리뷰하고 제품을 개발한다고 했을 때, 저 규정한 가치대로 잘 개발해 나가고 있나요? 제가 경험한 바에 따르면 그런 개발 방식에서는 그렇게 아름다운 답변이 나올 일이 없었습니다. 그런 압축된 문서(예를 들어, 화면정의서)들은 가치 정의 문장에서 요구하는 것들을 제대로 전달해 내지 못하기 때문입니다. 그리고 그것이 제가 PRD 중심 개발을 강조하는 이유이기도 합니다.

기업에서 제품을 개발해 온 과정

아니라고요? 많은 기업에서 제품을 개발해 온 과정을 한번 복기해 보겠습니다.

어떤 계기로 아이디어 생성(Idea Generation)이 일어납니다. 곧 초안 버전 상태에서라도 비즈니스 구조 설계(Business Structuring)를 해나갈 것입니다. 그다음 제품팀, 혹은 개발팀을 대상으로 이게 무엇인지 설명하고 전달하겠죠. 화이트보드나 A4 이면지에 자신 있게 북북 그어나가는 선들을 보고 있노라면 당장에라도 제품이 튀어나올 것만 같습니다. 이어 다양한 형태의 구두(verbal) 커뮤니케이션이 따라옵니다. 이런 설명을 듣다 보면 모두가 이미 모든 것을 알고 있으며 그 형태는 동일한 상태로 공유하고 있다고 착각하게 됩니다. 이제 “개발을 시작해 보자!”라는 선언이 나오죠. 그다음, 우리는 무엇을 하고 있을까요?

지금 이 상황을 규정해 봅시다. 발화자(Idea owner)의 머릿속은 온통 아름다운 에덴동산으로, 장엄한 유니콘이 뛰어놀고 있습니다. 그리고 그 설명을 청취한 제품팀 멤버들 모두의 머릿속에는 평행우주처럼 각자의 에덴동산과 유니콘이 태어날지도 모릅니다. 분명히 아름답고 참 좋은데, 설명을 할 수 없는 그런 느낌이랄까요. 확실한 것 한 가지는 어느 우주를 선택하더라도 그리 충분한 형상화가 일어나지 않았다는 것입니다. 심지어 발화자의 우주에서도 형상화가 충분하지 않다는 것은 확실합니다.

그럼에도 불구하고 우리 모두는 각자 이 제품을 “알고” 있습니다. 그리고 그것을 모두 “공유”해 “동기화(Sync)”되어 있다고 생각합니다. 그리고 여기부터 보통 스크린을 그려나가기 시작합니다. 우리 모두는 개발자(Maker)로서의 자아도 가지고 있지만, 동시에 소비자로서의 자아도 가지고 있습니다. 그러니 스크린이 어떤 자아를 기반으로 작성되는지, 그 스크린을 보고 해석하는 사람들은 어떤 종류의 자아로 이를 해석하고 있는지 자신할 수 없습니다. 그렇게 모두 같은 것을 “공유”하고 있다는 믿음 아래 각자 다른 것을 “상상하면서 만들기 시작”합니다.

제가 강조하는 PRD는 여러 목차를 보유하고 있습니다만, 그중에서 핵심 요체가 되는 것들은 퍼소나(Persona), 그리고 메인 시나리오(Main Scenario) 이렇게 두 가지입니다. 그 외에 기본이 되는 것으로 배경(Background), 맥락(Context) 등을 추가할 수 있고, 심화 과정으로 들어가면서는 유즈 케이스(Use Case)를 채워 넣습니다. 이러한 구성으로 PRD를 정리해 나갈 때야 앞서 규정한 가치 정의를 가장 정확하게 수행할 수 있다고 저는 생각합니다.

글의 주제로 돌아가겠습니다. 이처럼 사람 동료에게도 제대로 전달하지 못하는 가치 정의를 과연 AI 에이전트에게 제대로 전달할 수 있을까요? 어쩌면 AI 에이전트는 사람 동료보다도 당신을 훨씬 더 잘 이해하고 개발해 줄지도 모릅니다. 최소한 당신을 비난하지는 않을 테니까요. 하지만 과연 그렇게 만들어진 제품이 정말 원했던 무언가, 그 가치를 정확하게 구현하고 실현한 제품일까요?

PRD 중심으로 AI 에이전트와 개발하는 과정

올해 초, 아름답지 않은 이유로 제가 설계하고 목표했던 제품을 드롭하게 되었습니다. 아쉬움이 남아 이 제품을 ‘PRD 중심으로 AI 에이전트와 개발하기’의 소재로 사용해 보기로 했습니다.

우선 내가 무엇을, 왜, 개발하고 싶어하는지 더욱 명확하게 정리하고, 또 그중 가장 핵심이 무엇인지 선별해 PRD를 작성하기 시작합니다. 이 첫 단계에서 제가 강조하는 두 가지가 있습니다.

a. 반드시 문서로, 텍스트로 작성할 것. 어설프게 그림을 그리지 말 것

b. 모든 문장은 서술형으로 작성할 것. 권장하는 문장 구조는 사용자는 OOO를 할 수 있다. (User be able to have an option)

많은 분이 텍스트로 문서를 작성하는 것을 매우 어려워합니다. 아닐 것 같지만, 사실입니다. 누군가는 스티브 잡스가 아이콘 하나 띄워 두고 삼십 분씩 발표하는 것을 대단한 능력이라고 생각할 수도 있을 텐데, 비슷한 것을 많이 해본 분이라면 알겠지만, 말로 하는 것이 세상에서 제일 쉽습니다. 이유는 단순합니다. 내가 상상한 것을 말로만 전달하면 에덴동산도 유니콘도 마음껏 만들 수 있는데, 글로 써 보고 나면 머릿속에 있던 에덴동산도, 유니콘도 온데간데 없어지기 때문입니다.

남은 것은 (제가 가장 좋아하는 비유입니다만) ‘2주 전에 써놓은 연애편지처럼’ 촌스럽고 초라하며 볼품없는, 게다가 말도 안 되고 내용도 개발괴발인 글 덩어리일 뿐입니다. 그래서 많은 분이 제품에 대한 이야기를 말로만 하려고 합니다. (저는 신뢰하지 않지만, 바이브 코딩(Vibe Coding)이 이런 분들에게 희망이 될까요?)

텍스트 문서와 서술형 문장, 두 가지를 강조한 것은 이 때문입니다. 텍스트 기반 문서는 그 허황되고 말도 안 되는 에덴동산을 제거하기 위함이고, 서술형 문장은 그 연애편지를 조금 덜 촌스럽고, 더 구조화된 상태로 만들기 위함입니다. 같은 이유로 노션에 개조식 To-Do 리스트를 작성하는 방식은 매우 매우 반대합니다. To-Do는 To-Do로만 사용해 주세요.

AI 에이전트에 제품 개발 요청하기

PRD를 갖추었다면 이제 우리는 프론트엔드(Front-End)를 개발할 수 있습니다. 사용자의 메인 시나리오부터 하나씩 하나씩 상상하는 대로 넣어가면 됩니다.

저는 AI 코딩 도구로 러버블(Lovable)을 이용하고 있습니다. 꽤나 말귀를 잘 알아들어 유용하게 쓰고 있습니다. 대신 고집이 대단해 또 어떤 것은 결코 양보해 주지 않더군요. 그래도 시나리오를 넣은 다음 유즈 케이스를 하나씩 추가하는 데에는 아주 안성맞춤입니다.

아래 두 가지 프롬프트 예시가 있습니다. 전자는 일단 아무렇게나 에덴동산을 만들고 싶은 경우이고, 후자는 그래도 에덴동산에 언덕과 골짜기가 몇개인지 구체적으로 그려본 경우라고 비유할 수 있겠네요.

<출처: 작가>

이제 에덴동산을 보다 구체적으로 조정하는 일이 남았습니다.

<출처: 작가>

우리는 시장을 모른다

PRD를 전부 쓰고 한 번에 넣어, 바로 완제품을 만들어 달라고 하면 안 될까요? 네, 안 됩니다.

AI 에이전트의 성능이나 요금제 때문만은 아닙니다. 앞선 문단에서 말했듯, 사실 제품을 만드는 본인도 스스로 개발할 것이 무엇인지는 정확하게 잘 모릅니다. 그리고 그것이 정상입니다. 지금 단계에서 알 수 있는 것은 ‘누가, 왜, 어떻게 제품을 사용해 무슨 가치를 획득해 갈 것이다’라는 사실뿐이니까요.

애자일을 설명할 때 항상 강조하는 문장은, “우리는 시장을 모른다”입니다. 저는 이 말이 애자일 철학의 가장 근원적인 질문을 만들어 낸다고 생각합니다. 우리가 만들어 갈 제품을 우리는 사실 잘 모릅니다. 그저 조금 더 형상화된 문장, 시각화(Visualized)된 상상을 가지고 있을 뿐입니다. 그렇게 시나리오와 사용자 케이스를 하나씩 넣어가며 그때마다 조금 더 정확하게 알아가고는 합니다. 그렇게 하나의 시나리오를 알고 규정할 수 있게 되면, 여러 유즈 케이스를 규정할 수 있으며, 인접한 다른 시나리오를 형상화할 수 있습니다.

형상화의 단계 <출처: BaseCamp: Shape-up>

이 프로젝트를 제가 혼자 진행한 것은 아닙니다. 채널 개발 쪽은 제가 정한 정책과 PRD를 바탕으로 다른 분이 맡았고, 그는 커서 AI(Cursor AI)를 이용했습니다. 그렇게 둘이서 1주일에 하루 2~3시간을 들여 공동 작업을 했고, 1주일에 반나절 정도는 각자 개인 작업을 진행하며, 4주 동안 개발을 마쳤습니다. 이 글을 쓰는 지금 그 제품은 Email for Weeks라는 이름으로 크롬 익스텐션 스토어에 올라가 있으며, 업데이트 대기 중인 상태입니다.

QA와 QC

제품 개발의 마지막 단계는 QA입니다. 회사에 QA 팀이 있다면 이들은 수백 줄로 이루어진 TC 시트를 가지고 있을 것입니다. 그리고 주기적으로 전체 테스트(Full Test)를 하면서 TC 시트에 새로운 줄을 추가해 나가고 있을 것입니다.

PRD 중심 개발의 QA는 그와는 좀 다릅니다. TC로 모든 경우를 검증하는 것이 QA(Quality Assurance)라면 PRD 중심에서는 QC(Quality Control)를 한다고 설명해 보고 싶습니다.

여기서는 PRD에서 작성한 시나리오대로, 그리고 유즈 케이스(UseCase)대로 우리 제품이 제대로 작동해 주는지 테스트합니다. 이 방식의 장점은 메인 시나리오에 대해 확실한 점검을 할 수 있다는 것이고, 단점은 생각하지 못한 예외 케이스를 필터링하지 못할 위험성이 상대적으로 높다는 점입니다.

그럼에도 제가 이 방식을 선호하는 이유는 반드시 가치를 지켜내야 하는 메인 시나리오와 의도치 않게 발생하는 예외 케이스를 명확하게 구분해 낼 수 있기 때문입니다. 그래서 예외 케이스를 보정하기 위해 메인 시나리오의 가치가 훼손되는 것을 막을 수 있게 됩니다. 모든 앱 기동에 대해 MECE로 테스트를 하기 시작하면 무한정으로 펼쳐져 가는 사용자 행동 시나리오를 만나게 될 수도 있습니다. 또, 그런 것들을 정리하다 보면 메인 시나리오의 가치가 훼손되는 상황을 만나기도 합니다.

PRD에서 직접 QC 테스트 케이스를 작성하고 확인하는 화면 <출처: 작가>

제가 삼성페이를 개발할 때의 일화입니다. 어떤 예외 케이스를 발견했는데, 그 케이스를 적절하게 수용하려면 메인 시나리오를 손대야만 할 상황에 도착했습니다. 예외 케이스를 EP(Entry Point)에서부터 막아버리려는 저와 삼성 모바일의 UX 정책상 그렇게 해서는 안 된다는 UX 담당자의 의견이 대립했습니다. 당시 저는 그 예외 케이스에 들어갈 사용자가 많아 봐야 1%도 안 될 거라고 짐작했습니다.

이에 대한 UX 담당자의 답변은 무엇이었을까요? “과장님, 갤럭시 사용자의 1%가 몇 명인 줄 아십니까?”
(그립네요. 박 책임님, 이 글을 혹시 보면 연락 한 번 주세요)

그때 어떤 결정이 이뤄졌는지는 사실 잘 기억나지 않습니다. 그저 당시 QC 과정에서는 PM과 UX 사이 이런 치열한 대립이 수도 없이 많았고 제 승률은 3할 정도 수준이었다고만 기억합니다. 그러나 이런 과정 덕분에 삼성페이는 “삼성스럽지 않게” 잘 나온 제품이라 자부하고 있습니다. 또, 이런 과정에도 불구하고 삼성페이의 버전 출시는 일정 지연이 거의 없는 상태로 배포해 내기도 했습니다.

PRD는 언제 완성되는 것인가?

PRD 중심으로 개발하자고 강의할 때, 가장 많이 듣는 질문 또는 컴플레인은 “PRD를 쓰느라 너무 많은 시간을 허비해야 한다”는 것입니다.

디자인 문서나 화면정의서, AC 문서 등은 1차로 완성한 다음 개발팀과 리뷰를 진행합니다. 하지만, PRD라는 문서를 쓰는 데는 AC 문서보다 훨씬 더 많은 시간이 들어갈 테고, 그만큼 제품 개발이 더 지연된다는 불만입니다. 이런 불만이 나오면 저는 제가 강의를 잘 해내지 못했다는 사실을 깨닫게 됩니다.

PRD는 100점짜리 문서를 쓰는 작업이 아니라고 아무리 설명해도 이미 가지고 있는 인식을 뛰어 넘기는 정말 쉽지 않습니다. 그럼 PRD를 리뷰하려면 어느 정도 완성도가 있어야 할까요? ‘100점 만점에 30점’이라고 저는 설명합니다. 70점이 아닌, 30점입니다.

그 정도면 가치 정의 수준을 완성하고 퍼소나(Persona)와 메인 시나리오(Main Scenario) 정도만 쓰여 있습니다. 얼추 배경(Background)과 맥락(Context) 정도를 추가해도 충분합니다. 때로 조금 더 해서 중요한 유즈 케이스(UseCase)를 작성하고 사용자 여정(User Journey) 또는 사용자 흐름(User flow)이라고 부르는 일방향(One way) 흐름도까지 쓰고 나면 40~50점은 됩니다. 이 정도를 작성하는 데에는 PM의 고민이 충분하거나 혹은 경영진이나 전략 부서와 작성한 MRD(Market Requirement Document)가 있다면 반나절, 길어도 하루 정도면 충분한 작업입니다.

그러면 이 PRD는 언제 100점에 도달할까요? 답은 ‘제품이 배포될 때’입니다. 그 잠깐의 시점을 지나고 나면, PRD의 점수는 다시 70점으로 돌아와 다음 배포를 기다리는 상태가 되어 있겠죠. 제가 AI 에이전트와 개발한 제품의 PRD도 이런 과정으로 쓰였고, 제품을 배포하기 직전까지도 100점에 다다르지 못했습니다. 그러나 일단 배포를 했으니 다시 70점이 되었고, 그렇게 배포한 제품을 기반으로 유즈 케이스(UseCase)를 다시 정렬하고, 후속으로 배포할 기능에 대한 시나리오를 추가해야겠죠. 채널 쪽 동작의 로직도 좀 더 수정할 필요가 있어 보입니다.

이 제품을 개발하는 과정에서 나온 다양한 케이스도 논의를 거쳐 일부는 수용했지만, 또 대부분은 EP(Entry Point)에서 막아버렸습니다. 제가 설정한 퍼소나(Persona)는 꽤나 분명하고 정형화된 형상을 가지고 있기 때문에, 일어날 것 같지 않은 상황들에 대해서는 제품 개발을 하지 않기로 했습니다. 이 과정 모두 PRD 기반 QC를 하면서 확인했습니다.

마치며

제품을 설계하고 PRD를 쓰며, 또 배포하는 과정은 도파민이 터지는 정말 즐거운 일입니다. 저는 연차 많은 시니어 PM이지만, 이번 제품을 만드는 과정에서 또 한 번 스스로 성장했다고 여기고 있습니다. PM은 제품을 배포하는 행위를 통해서만 성장하는 것이니까요.

그리고 저는 이러한 성장 과정을 전파하고 있습니다. 누군가 저를 가리켜 “어디에서나 PRD를 외치는 사람”이라고 지칭할 정도로요. 그렇게 많은 스타트업들이 PRD 중심 개발을 꼭 시도해 보기를 바랍니다. 제품을 더 정확하게, 원하는 대로 배포할 방법이자, 동시에 PM이 성장해 나가는 과정이 될 것이라고 믿기 때문입니다.

이 글에서 예를 든 사건들 외에도 수많은 상황을 누군가는 마주하고 또 경험하고 있을 것이고, 이렇게 해주었으면 저렇게 할 수 있다면 하는 많은 방법론들을 생각해 낼 수 있을 것입니다. 이 글을 읽는 독자분들 중에 이런 사항을 경험하시고 공감하는 분이 계신다면 댓글로 생각을 남겨주세요.

제품 개발 과정(Agile Product Development Process, APDP)에 대해, 특히 PRD에 대해 궁금한 분들을 위해 커피챗 신청 창구를 만들었습니다. 링크를 참고해 주세요. 이러한 과정에 관심 있는 스타트업도 좋습니다. 댓글 또는 이메일이나 링크드인으로 연락 주셔도 됩니다.

]]>

‘큐레이션’ 하나로 고객 경험을 바꿀 수 있을까?

이커머스는 판매와 소비라는 두 가지 측면에서 시대감각과 밀접하게 닿아있다. 특히 트렌드와 높은 감도에 익숙한 고객에게 매끄럽고 세련된 경험을 제공하지 못한다면 실망감만 안겨줄 뿐이다. 여기에 프로젝트를 진행하면서 맞닿는 다양한 이슈와 수많은 이해관계자와 얽히고설켜 나온 결과물이 고객 맥락이나, 이용 행태를 제대로 반영하지 못한다면 더욱 외면받게 될 것이다.

이러한 이유로 이커머스에서는 고객을 온전히 이해하고 그들의 경험을 지지하도록 유도하는 큐레이션이 더욱 중요해졌다. 이번 글에서는 크고 작은 이커머스에 신규서비스를 기획하면서 도움이 된 ‘큐레이션으로 고객 만족도를 높일 수 있는 기획 방법과 사례’에 대해 살펴보고자 한다.

왜 큐레이션이 중요할까?

쿠팡, 네이버를 비롯한 이커머스에서 AI 기술을 활용한 개인화 추천 경험은 선택이 아닌 필수가 되었다. AI 추천으로 쉽고 빠른 상품 탐색과 검색으로 편의성을 높일 수는 있지만, 서비스의 뚜렷한 정체성이나 차별화된 경쟁 우위를 가지는 데 한계가 있다.

예를 들어, 쿠팡 하면 제일 먼저 떠오르는 것은 AI 추천이 아닌 로켓배송이다. 그리고 무신사 역시 AI 스타일리스트가 아닌 무신사 스탠다드가 떠오를 것이다. 이처럼 AI는 좋은 경험을 만드는 수단은 될 수는 있으나, 독보적인 서비스나 단독상품 없이 AI만으로는 쇼핑몰을 방문할 만한 이유를 만들기는 쉽지 않다.

그렇다면 또 다른 관점에서 차별화된 고객 경험을 잘 담아서 전달할 수 있는 그릇은 무엇이 있을까? 바로 큐레이션이라고 생각한다. 큐레이션은 필요한 상품을 빠르게 구매할 수 있도록 제안하면서도 사업자가 추구하는 전략 방향이나, 브랜드 정체성을 담을 수 있는 요소로 활용할 수 있다. 이유는 오프라인에서 쇼핑할 땐 오직 상품만을 탐색하지는 않으며, 매장의 분위기나 매장을 방문한 다른 사람을 보는 것도 일종의 쇼핑 경험이기 때문이다.

같은 선상에서 온라인에서는 브랜드 철학과 고객 맥락을 반영한 큐레이션으로 다른 곳과 차별화된 쇼핑몰의 분위기나 브랜드다움을 추구할 수 있다. 그래서 무신사의 코디노트, 컬리추천, 올리브영의 발견에 녹여 넣어 새로운 발견이 구매로 이어지도록 제공하고 있다.

큐레이션은 어떻게 고객 경험과 연결될까?

큐레이션 기획은 한 축으로는 사업 핵심 가치를, 또 다른 축으로는 타깃 고객을 분석해서 그들의 요구사항을 정의하는 것으로 시작한다. 결국 재방문 및 전환율을 높이면서도 매출 증대로 이어지게 하려면 타깃 고객이 원하는 것을 정확히 파악해서 제안할 수 있어야 한다.

그래서 우선 핵심 타깃 고객에게 전달할 컨셉과 메시지를 정하고, 큐레이션 된 형식으로 왜 이런 상품을 지금 이런 테마로 제안하는지 고객 입장에서 느낄 수 있도록 하는 기획력이 뒷받침되어야 한다. 이번 파트에서는 더 나은 쇼핑 경험을 성공적으로 제공하기 위한 큐레이션 방법 3가지를 소개한다.

1) 고객의 핵심 문제 파악하기

차별적인 고객 경험을 만들 때 가장 중요한 질문은 타깃 고객의 문제들 중에 최우선으로 해결해야 할 문제는 무엇인가?이다. 예를 들어, 시니어, 직장인, 수험생 등 고객에게 딱 맞는 식단을 제안하거나, 고객마다 다른 피부 상태와 트러블에 맞는 화장품을 제안하는 방법이 있다.

대표 사례로는 현대그린푸드 그리팅과 풀무원의 디자인밀이 있다. 그리팅은 건강한 식단을 단백질, 칼로리, 저당을 고려하여 제공하면서 특정 타깃인 시니어 식단을 제공한다. 디자인밀 역시 AI 영양진단 서비스로 맞춤 영양 관리 가이드를 제공하면서 타깃인 직장인의 든든한 점심 식단을 제공하고 있다.

(왼) 현대그린푸드 그리팅, (오) 풀무원의 디자인밀 <출처: 각 사, 작가 편집>

2) 컨셉과 정체성 반영하기

컨셉과 정체성을 잘 나타내는 방법으로는 타깃 고객이 다른 사람에게 추천할 때 어떻게 말하기를 원하는지 생각해 보면 쉽다. 예를 들어, ‘뭐 입을지 고민되면 무신사 가봐’라든지, ‘요즘 핫한 먹을 것을 찾는다면 컬리에 가봐’라고 어떻게 말하는지 생각해 보면 도움이 된다.

특히 프리미엄 식재료라면 가장 먼저 떠오르는 컬리가 “더퍼플셀렉션”으로 핵심 가치를 반영한 테마를 제안하는 데에는 이유가 있다. 이처럼 정체성을 더욱 뚜렷하게 큐레이션에 반영한다면, 더욱 쉽게 기억할 수 있다.

컬리의 더퍼플셀렉션 <출처: 컬리, 작가 편집>

또 다른 사례로는 롯데온의 딜크릿과 네이버의 ‘원쁠딜’이 있다. 롯데온의 딜크릿은 타깃과 상품의 특징을 고려하여 매일 바뀌는 비밀 특가를 테마별로 제안하며, 고객별로 다르게 추천받은 상품을 보여주는 방식을 택했다. 네이버 원쁠딜에서는 1+1 행사 아이템을 모아서 보여준다.

롯데온 딜크릿과 네이버의 원쁠딜 <출처: 각 사, 작가 편집>

3) 고객 참여 이끌어내기

퀴즈나 100원 응모 등으로 고객 참여를 이끌어내는 곳은 단연 ‘토스 쇼핑’을 따라갈 곳이 없다. 결국엔 고객이 선택한 상품을 자연스럽게 할인 혜택으로 구매하도록 유도하는데, 요즘엔 무신사나 에이블리에서도 같은 방법으로 혜택을 제공하고 있다.

(왼) 무신사, (오) 토스쇼핑 <출처: 각 사, 작가 편집>

특히 토스쇼핑은 고객의 재방문을 유도하기 위해서 고객이 참여하고, 보상받을 수 있는 구조를 잘 설계했다. 큐레이션 된 상품을 다른 사람에게 공유했을 때 포인트를 적립하거나, 퀴즈를 통해 개인화된 혜택을 제공하여 고객과 강한 연대감이나 결속력을 만드는 데 적극 활용하는 식이다.

고객 만족도를 높이는 가이드 팁

앞서 살펴본 바와 같이 고객이 지속해서 찾아올 만한 이유를 만들기 위해서는 핵심 가치와 연결된 고객 맞춤 제안이 중요하다. 그리고 무질서하게 나열된 UX/UI 구성 요소로 인해 상품을 탐색하는 데 방해가 되지 않아야 한다.

그래서 이번 파트에서는 사업 핵심 가치와 연결되는 기획 관점, 그리고 고객 경험으로 나타나는 UX/UI로 살펴보고자 한다.

1) 큐레이션 기획 가이드

큐레이션을 기획할 때는 명확한 사업 전략, 효율적인 운영 방안, 적합한 채널 연계까지 되어야, 비로소 고객 만족도를 높일 수 있다. 즉, 사업 핵심 가치뿐만 아니라, 적합한 운영 방법과 프로세스에 대한 고민이 필요하다.주기 별로 행사 상품을 취합하면서도 상품의 재고, 품절, 결품 등의 상품 상태와 전시 여부를 확인하는 효율적인 운영 측면도 고려해야 한다.

그리고 지속 유입을 유도하기 위해 타깃 고객에게 적합한 채널(바이럴, SNS, 앱푸시 등등)로 메시지를 전달하는 것까지 생각할 수 있어야 한다.

<출처: 작가>

2) 큐레이션 UX/UI 가이드

또한 아무리 잘 기획된 큐레이션이라도 고객이 복잡하고 난해하다고 느낀다면 제대로 전달되기 어렵다. 따라서 직관적이면서도 명료하게 전달할 수 있는 UX/UI 가이드가필요하다.

팀에 UX 전문가가 있다면 고객이 쉽게 사용할 수 있도록 간결하게 정리해 두는 게 좋으며, UX/UI 가이드라인을 따로 만들어보는 것도 방법이다. 요즘은 디지털 정부서비스 UX/UI 가이드라인의 자체 검증 체크리스트(2024년 12월)처럼 널리 참고할 수 있는 자료들도 많아, 고객 경험을 높이는 데 도움이 된다.

또 하나 중요한 점은 ‘사용이 편리하다’라는 것과 ‘편안하다’라는 개념은 다르다는 점이다. ‘편안함’은 감정과 연결되는 영역이다. 예를 들어, 로딩 속도나, 고객 여정 중 특정 행동을 했을 때 나오는 마이크로 인터랙션처럼, 사용자가 의식하지 못하는 미세한 디테일까지 챙겨야 진짜 좋은 경험을 줄 수 있다.

<출처: 작가>

큐레이션 만족도를 높이려면 본질에 집중할 것

일부러 불편한 서비스를 만들어 나쁜 경험을 주고 싶어 하는 기획자는 없을 것이다. 다만 켜켜이 쌓인 이슈와 문제를 하나씩 해결하다 보면, 간혹 본질을 놓치게 된다. 그래서 늘 고객 중심에서 벗어나지 않도록 잡아주는 전문성과, 방향을 잡아줄 수 있는 가이드가 필요하다.

이커머스에서 상품의 다양성이나 배송 속도 면에서는 쿠팡을 따라잡기 어렵다. 그래서 차별화된 경쟁력을 만들기 위해서는 새로운 ‘감도’가 필요하다. 여기서 말하는 감도는 꼭 컬리의 ‘더퍼플셀렉션’처럼 프리미엄 식품만을 의미하는 건 아니다. 본질에 잘 맞는 컨셉이라면, ‘한여름 바닷가 모래 위, 색이 바랜 아이스박스 속에서 꺼내 마시는 시원한 칠성사이다’도 충분히 감도 있는 경험이 될 수 있다.

현재 쿠팡과 네이버가 이커머스를 주도하고 있지만, 실제로 고객은 그 외에도 다양한 채널을 통해 쇼핑하고 있다. 예를 들어, 주부라면 아이를 돌보면서 맘카페에서 정보를 찾아보는 중에 자연스럽게 쇼핑을 하기도 하고, 대학생은 등굣길이나 잠들기 전 인스타그램, X(트위터), 틱톡, 유튜브 같은 플랫폼을 보다가 마음에 드는 상품을 구매하기도 한다.

이처럼 고객은 특정 플랫폼에만 머무르지 않고 다양한 채널에서 콘텐츠를 소비하고, 그 과정에서 쇼핑을 즐긴다. 그렇기 때문에 자사 쇼핑몰에 꼭 와야만 하는 이유를 만들어주는 게 중요하다.

끝으로, 지금 이 순간에도 테마를 고민하고 있을 큐레이션 기획자라면 시즌 행사에만 몰두하지 말고, 고객의 맥락과 특성을 먼저 파악하길 바란다. 그래야 본질을 담을 수 있다. 또 고객 만족도를 높이기 위해서는, 해당 고객에게 진짜 잘 어필할 수 있는 방법이 무엇인지 치열하게 고민해야 한다. 같은 상품이라도 어떤 주제로, 어떤 방식으로 보여주느냐에 따라 고객이 느끼는 감도는 완전히 달라질 수 있으니 말이다.

]]>

카카오 T에서 ‘심야주차권’을 3분 빨리 쓰면 벌어지는 일에 대하여

제품 개발에서 유즈케이스(USECASE)를 설정해야 하는 이유

카카오 T 주차 서비스를 이용하다 만난 제품 이야기를 준비했습니다. 제품 개발 과정에서 유즈케이스(USECASE)를 제대로 설정하지 않으면 무슨 문제가 생기는지, 또 그것이 고객에게 어떤 불편함을 주는지에 대한 이야기입니다.

주차 상품 심야권(17:00~07:00)을 구입했습니다

오랜만에 제가 주로 서식하는 경기 남부와는 정말 먼 지역인 합정역 인근에서 미팅을 잡았습니다. 멀리 나가다 보니 미팅 한 건만 하고 돌아오는 것은 여러 가지로 아까웠기 때문에, 그 김에 미팅도 하고 저녁 약속도 정하고 또 오랜만에 여러 사람을 만날 즐거운 번개 모임도 잡았습니다.

저는 전기차를 타기 때문에 공영 주차장 50% 할인 혜택을 받을 수 있고 이를 정말 잘 이용하고 있습니다. 다만 이번에는 여러 건의 일정을 잡았기 때문에 전체 시간도 길었고, 제가 애용하는 양화진 공영주차장과 미팅 장소가 멀기도 해서 망설여지더군요. 그래서 카카오 T 주차 서비스를 이용하기로 했습니다.

저는 카카오 T 주차 서비스를 참 좋아합니다. 특히 카카오 T가 주차 서비스 파크히어를 인수한 이후 보여준 표준화와 스케일업 전략은 정말 탁월한 선택으로, 교과서적인 성공 사례라고 생각하고 있습니다. 가장 흥미로운 지점은 카카오 T가 기존 파크히어 시절보다 나은 방향성을 수립하고 성공시켰다는 점입니다.

과거에는 최대한 많은 주차 면수를 확보하는 것이 경쟁의 핵심이었습니다. 그 때문에 표준화되지 않은 - 사람 관리인이 처리하거나, 주차면이 비정형인 - 주차장을 포함해 최대 면수를 갖기 위해 무한한 경쟁을 했습니다. 그러나 카카오 T는 파크히어를 인수한 이후 전략을 바꿨습니다. 표준화할 수 있는 우수한 품질의 주차장만을 남기고 나머지는 모두 디마케팅해버린 것입니다. 초기에는 주차할 곳이 없다는 소비자 불만도 많았지만, 결국 표준화를 먼저 이루고 나서 표준과 자동화를 지킨 상품을 기준으로 스케일업을 해내며 지금의 위상을 가지게 되었습니다. 그렇게 지금의 카카오 T 주차는 다른 경쟁자들을 모두 따돌리고 주차 분야에서는 독보적인 선두에 올라섰습니다.

과거 파크히어 서비스 <출처: TIPS>

이렇게 대단하고 훌륭한 기업이지만, 이들 역시 제품을 만들고 관리하는 과정에서는 일부 아쉬운 지점들도 당연히 안고 있을 것입니다. 제가 경험한 이 사건 또한 그러한 이유로 발생했을 것이라는 생각이 들었습니다.

전체적으로 글이 진행되는 과정은 제가 과거 세탁 서비스를 사용하면서 느꼈던 지점들과 유사할 것이라 생각합니다. 세탁 서비스에서 유즈케이스가 부재한 케이스가 궁금한 분들은 이 글(CS가 탁월하면 프로덕트가 무능해진다)을 먼저 읽어보기를 권해드립니다.

“9시 1분은 9시가 아닙니다” vs. “4시 57분은 5시입니까?”

<출처: 브런치 ‘건조한 글쓰기’>

아무래도 운전을 하면서 먼 길을 가다 보면, 길이 막힐 것이 우려되기도 하고 여러 변수가 있으니 조금 여유를 두고 움직이는 편입니다. 여유롭게 출발하면 도착해 너무 오래 기다려야 하는 상황을 만나기도 하지만요. 이날도 저는 조금 여유롭게 출발했고, 무척 여유롭게 도착하게 되었습니다.

구매했던 카카오T 주차 상품 심야권. 모든 요일 17:00~07:00 이용 <출처: 작가, 카카오 T 주차 캡처>

당시 저렴한 가격으로 예약한 심야권은 17시부터 이용할 수 있는 상품이었고, 40분가량 시간이 남아버린 저는 가까운 교보문고에 주차하고 책을 한 권 구매해 읽으면서 시간이 되기를 기다렸습니다.

참고로 이날 구매한 책은 “실리콘밸리 프로세스의 힘”입니다. 제목은 마치 “실리콘밸리의 팀장들”처럼 뭔가 신뢰가 가지 않는 느낌이지만, 평소 프로세스쟁이를 자처하는 제게는 필독해야 할 책이라는 생각이 들 정도로 좋았습니다. 특히, 문제를 해결하지 않고 없애버리라는 서평은 정말 매력적이었습니다. 참고로 “실리콘밸리의 팀장들(원제/ Radical Candor)”도 제목만 빼고 보면 참 좋은 내용입니다.

그렇게 시간을 보내다 17시가 다 되어가는 것을 확인하고는 차량을 이동해 예약한 주차장으로 향했습니다. 제가 주차권을 예약한 곳은 교보문고 바로 옆에 붙어있는 건물이지만, 그래도 출차하고 이동하고 다시 입차하는 과정이 5분은 넘을 거라고 생각했는데, 너무 효율적으로 이동한 탓에 2~3분 만에 다음 건물에 들어서 버리게 되었습니다. 어쩐지 이날은 엘리베이터도 한번 기다리지 않고 바로 탈 수 있더라고요.

그렇게 문제의 사건이 일어나버렸습니다. 17시부터 이용할 수 있는 심야 주차권으로 16시 57분(16시 47분 30초 정도)에 입차했고, ‘뭐 2~3분 정도야 버퍼로 처리되겠지’ 안일하게 생각했던 저의 예상을 비웃듯 아무런 알림이나 통보 없이 상품이 강제 취소되어 버린 것입니다.

<출처: 작가, 카카오 T 고객센터 채팅 상담 화면 캡처>

나는 지금 어디에 있는 것일까? 제품의 여정 속에서 길을 잃다

주차를 하는 과정에서 생각보다 빠른 전개 - 5분은 걸려야 하는데 2.5분 만에 이동해 버린 그 전개 - 에 저도 잠시 머뭇거린 순간이 있었음을 고백합니다. ‘들어가지 말고 한 바퀴를 돌아와야 할까’하고요. 하지만 이미 막히기 시작한 도로를, 그리고 다가오는 미팅 시간을 보며 저는 용감하게 주차장으로 진입했습니다.

사실 믿는 구석도 있었거든요. 카카오T 주차를 꽤 자주 이용하다 보니 어느 날은 몇 분 빨리 들어가도 문제가 없었던 경험도 있었고, 심지어 다른 케이스에서 상담원에게 이런 상황을 물어보고 ‘연동 주차장의 경우 5분 정도 여유는 두고 있습니다’는 답을 들은 적도 있었죠.

<출처: 작가, 카카오 T 채팅 상담 화면 캡처>

어떠한 경우든 시간제 제품을 개발하다 보면 약간은 버퍼를 유지하게 됩니다. 물론 절대 시간은 하나이지만, 그 시간을 바라보는 시계는 아주 다양하고, 그 사이에는 약간씩 오차가 있어 작게는 몇 초에서 십여 초, 많게는 일이 분까지도 존재하기 때문이죠.

이를테면 남산터널 혼잡통행료는 정확하게 21시 정각부터 면제하지만, 경부고속도로 버스전용차로의 일반 승용차 이용은 정규 시각인 22시보다 2~3분 정도 빨라도 단속받지 않습니다. 남산터널 혼잡통행료 징수를 위해서는 톨게이트에 커다란 시계를 두고 면제 여부를 정확하게 표시(Indicate)하고 있지만, 버스전용차로는 그렇게 할 수 없어 개인 시계(보통은 차량이나 내비게이션의 시계)에 의존하기 때문이죠.

지난해 12월 서울 중구 남산 1호 터널 톨게이트 <출처: 경향신문>

그렇게 주차하고 미팅을 마치고 다음 장소로 이동하려던 저는 평소와는 무언가 다르다는 것을 인지했습니다. 주차를 이용하고 있다는 표시가 앱에서 보이지 않는 겁니다.

카카오 T 주차는 상품을 예약했을 때는 ‘이용중:주차권 예약’이, 상품을 이용하는 동안에는 ‘이용중:주차중’이라는 상태가 표시됩니다. 물론 이런 정보들은 반드시 실시간으로 표시되기보다는 주차장 시스템과 배치 시스템이 돌아가는 주기에 따라 30분에서 한 시간 정도 늦게 표시되는 일도 자주 있습니다. 그에 ‘주차권 예약’이 ‘주차중’으로 바뀌지 않는 것은 늘상 있는 일이지만, 이렇게 아무것도 뜨지 않는 것은 처음 경험해 보는 일이었거든요. 앞서 찜찜함도 있었던 저는 상담을 시도하기로 합니다.

다른 날의 카카오 T 주차 상태 화면과 당일의 채팅 상담 <출처: 작가, 앱 캡처>

채팅 상담은 말이 안 통하는 참 어려운 물건입니다. 안내하기에는 아주 편리하지만, 제대로 된 상담은 사실상 불가능한 것이 아닌가 싶기도 합니다. 특히 전문적인 상담이 필요한 저 같은 프로불편러에게는 갑갑하기 짝이 없습니다.

제품쟁이의 직업병: 없는 유즈케이스를 추정해 보기

*짐작한 것을 기반으로 글을 쓰다 보니, 실제와 다소 다른 부분이 포함되어 있을 수 있습니다. 그러한 부분이 있다면 관계자분들이 불편하게 여길 수 있을 것입니다. 이점 미리 양해를 구하고 사과드립니다.

서론이 너무 길었습니다. 여러분이라면 이런 상황에서 어떻게 대응하시겠습니까? 사람마다 성향이 다르니 대응도 다 다르겠습니다. 하지만 저를 포함한 프로덕트 매니저(Product Manager), 그러니까 제품쟁이들이라면 왜 이 제품은 이런 상황에서 이렇게 작동하게 되었는가를 생각해 보게 됩니다. 한번 돌이켜 볼까요.

이는 사용자가 진입을 했는데 시간 조건이 ‘Fail’한 상황입니다. 그래서 그 상품을 “이용” 혹은 “결제”할 수 없게 되었습니다. 결제에 필요한 조건 파라미터 중 하나가 실패했기 때문이죠. 그렇게 시스템상 불가피하게 제품 이용이 강제로 취소되어 버린 것입니다.

참고로 카카오 T 주차 상품 중 시간제 이용 상품(3시간권 등)은 초과 이용을 해도 강제로 취소되지 않습니다. 3시간 초과 이용분은 주차장 일반 요금에 맞게 추가 요금을 카카오 T에서 자동으로 청구합니다.*

*물론 이 정책도 올해 2월, 제 차가 출차되지 않은 것으로 처리되어 하루 최대 요금이 부과된 적이 있었습니다. 그때도 CS에서 탁월하게 처리해 주셔서 요금을 강제로 조정한 적이 있습니다. 하지만 그 이후로는 아주 매끄럽게 잘 작동하고 있습니다. 아마도 뭔가 엣지 케이스 오류가 있었고, 이 부분을 잘 패치한 것 같습니다.

패치 이전, 5시간 넘는 주차로 인식되어 최대 요금이 부과되었다가 CS에서 조정해 준 케이스 <출처: 작가, 앱 캡처>

물론 “법적으로 사용자 과실이니까 사용자 책임이야”라고 할 수도 있을 것입니다. 단순하게 “규정 시간보다 일찍 입차했기 때문에 앞서 ‘3분’에 대해서는 그 상품을 이용할 수 없다”라고 한다면 이 부분은 저와 같은 프로불편러들도 받아들여야만 하는 상황입니다.

다만, 그로 인해 예약했으나 이용하지 않은 ‘주차 심야권’이 강제로 취소되는 것은 어떻게 받아들여야 할까요? 그리고 만약 취소를 했다면, “예약한 주차권 상품이 취소되었습니다”라는 안내가 도착하지 않은 것은 왜일까요?

(제 생각으로는) 이 상황은 제품 정책에서 예상하고 규정한 “취소”가 아니기 때문입니다. 즉, 사용자가 이용하는 유즈케이스를 설정하고 그 예외를 미리 처리하지 않았기 때문에 설정된 ‘취소 API’를 객체로서 호출하여 처리하지 않은 거죠. 또 그에 따라 ‘취소 API’에 연동되어 있는 자동알림기능이 작동하지 않았습니다.

그저 입차에 따라 차량 번호를 기반으로 배치를 돌렸고, “사용중 처리” 과정에서 파라미터 값 검증이 Fail하며 프로세스가 실패한 것입니다. (시스템에서는 에러코드와 로그가 남았겠지만) 사용자에게는 아무런 정보 제공과 알림 없이 그냥 해당 요청(request)을 “죽여”버렸거나 스스로 “죽어”버린 것이라고 짐작됩니다.

많은 기업에서 제품을 개발하고 기능을 구현하며 해당 기능에 대한 유즈케이스를 수립하지 않고 그냥 개발 요건만 가지고 개발을 진행합니다. 해당 주차장을 운용하는 회사는 “아마노코리아”라는 큰 주차장 운영 기업이고, 그 기업에서는 아마도 SI를 이용해 외부에서 운용할 API와 배치 시스템을 구성했을 것입니다. 그 API를 받아 우리 쪽에서 요건에 맞게 호출하고 처리할 때, 정산 부분을 제외하면 저 개발 요건에 따라 개발하고 구성하는 것은 어려운 일이 아닙니다.

하지만 아마노코리아는 카카오 T 주차의 사용자와 유즈케이스, 예외 케이스를 스스로 고려하고 준비해야 할 기업은 아닙니다. 그래서 카카오 T 주차에서 단순히 API 제공자(provider)의 가이드라인만 보고 요건에 맞춰 개발을 한다면 사용자의 유즈케이스를 모두 충족시켜 나갈 수는 없습니다.

개발 요건 중심

입차 시간 안내 > 입차 시간 확인 > 입차 처리(이때, 입차 시간 파라미터가 Fail) > 주차권 사용 처리 실패

<출처: 작가>

유즈케이스(USECASE) 중심

사용자가 입차할 수 있어야 한다 > 입차하면, 시간 정보를 확인하고 정상 입차 여부를 노출해야 한다 > 비정상 입차가 되었을 경우 » 시간 차이가 n분 이내라면, 사용자의 오사용 가능성을 고려하여 재입차 안내를 실시한다 » 시간 차이가 n분 이상이라면, 사용자의 이용 의사가 없는 것으로 판단하여 주차권을 취소하지 않고 유지하되, 사용자에게 리마인더 알림을 전송한다.

<출처: 작가>

‘고객 중심’이라는 건 CS보다 제품이 하는 것

우리 서비스를 이용하는 우리 고객은 ‘사람’입니다. 사람은 요건대로 움직여주지 않습니다. 그래서 아주 많은 예외를 만들어 내고, 그렇기에 예외를 모두 미리 준비하는 것은 당연히 불가능합니다. 하지만 그 예외를 합리적으로 추정하고 대응하며 보완하는 것은 가능합니다.

사용자를 가정하고(페르소나), 사용자의 행위를 가정하고(메인 시나리오), 그리고 그 가정된 행위에서 세부 시퀀스를 분리해 유즈케이스를 구성하면, 그 유즈케이스에서 발생하는 예외 상황이라거나 오류 상황, 혹은 진입이나 작동을 막아야 하는 지점을 찾아 문제를 예방할 수 있습니다. 또는 아예 사용자의 진입점(Entry Point)을 설계하여 예외가 발생할 수 있는 경로를 차단해버릴 수도 있습니다.

그래서 제가 주장하는 제품 개발 프로세스에서는 “사용자의 형상화”가 아주 큰 부분을 차지합니다. 사용자를 구체적으로 형상화하면 그 사용자가 살아 움직이며 동선과 행위를 상상하고 사용자의 유즈케이스를 설계하는 것이 가능해집니다.

하지만 사용자가 배제된 API 문서(Document)만 가지고 얼기설기 순서를 배치하고, 요구하는 대로 파라미터를 붙여 Json을 발행해 버리면 그곳에는 사용자의 행동이나 동선(흔히들 말하는 유저 저니(User Journey)), 그리고 사용자에게 발생하는 예외가 존재하지 않기 일쑤입니다.

제가 경험한 케이스에서 사용자의 동선과 상황을 약간 틀어, 이렇게 설계해 보면 어떨까요?

사용자 김민석(가명) 씨는 17시부터 사용할 수 있는 심야 주차권을 예약했습니다. 같은 건물에 위치한 교보문고에서 1시간 주차권을 받을 수 있었기 때문에, 김민석 씨는 16시 30분에 주차장에 진입했고, 교보문고에서 주차권을 받아서 17시 20분에 출차한 다음, 미리 예약했던 심야권을 이용하기 위해 17시 22분에 같은 주차장에 다시 입차하였습니다.

김민석 씨는 예약한 주차권을 무사히 잘 이용할 수 있었을까요? 혹시 궁금한 분이 있다면 위와 같은 상황을 한 번 재현해 보는 것도 좋겠습니다. 현실 세계에서의 ‘개밥먹기(Dog Fooding)’ 같은 QA가 될 것 같아 흥미진진하네요.

참고로 소프트웨어의 QA를 수행할 때에도 유즈케이스가 수립되어 있으면 정말 편리합니다. 그 유즈케이스를 그대로 따라해보면서 Pass or Fail을 확인하면 되니까요. API 문서를 들고 API의 배치 순서대로 작동하는지만 QA하는 것은 그다지 서비스의 퀄리티를 보장할 수 있는 방법은 못 됩니다.

또 하나의 ‘운수좋은날’ 같은 하루

사건이 벌어졌던 당일에는 피곤하고 짜증이 나기도 해 스트레스를 받았습니다. 저는 계획을 많이 세우는 편이 아니지만, 일단 세운 계획은 그대로 이루어지지 않으면 극심하게 스트레스를 받기도 하거든요. 그날은 그렇게 스트레스를 받기도 하고, 채팅 상담 과정에서 아주 피곤하기도 했고, 비싼 주차비를 피하기 위해 차량을 이동하면서 약속 시간에 조금 늦기도 하는 등 아주 재수 없고 거지 같은 날이라고 생각했습니다.

하지만 어쨌든 저는 또 미팅도 잘했고, 저녁 약속도 잘했고, 이후 모임에서도 즐거운 시간을 보낼 수 있었습니다. 게다가 이렇게 글 한 편을 쓸 수 있는 소재를 얻은 날이기도 했죠. 마치 현진건의 소설 ‘운수좋은날’에서의 역설처럼, (소설과는 정반대로) 어떻게 보면 참 재수없는 날이었을 수도 있겠지만, 덕분에 이렇게 또 글 한 편을 내었으니 제게는 고맙고 감사한 날이었다는 생각이 듭니다.

<출처: 카카오페이지>

무엇보다 PM으로서 다시 한번 유즈케이스에 대해 돌아볼 수 있는 날이기도 했고요. 그렇게 다른 분들도 이 이야기를 제품을 개발하는 과정에서 유즈케이스를 고려하는 계기로 삼아주면 좋겠습니다. 저 역시 앞으로는 4시 57분에 입차하지 않도록 동선을 잘 설정하겠습니다.

**카카오 T 주차의 CS팀은 정말 탁월한 역량을 보여주었습니다. 채팅 상담은 너무 불편했지만, 다음날 CS팀에서 상황을 리뷰한 이후 전화 상담을 먼저 걸어주셨고, 주차장 공급사마다 버퍼 정책이 상이할 수 밖에 없다는 말도 해주었습니다. 또, 제가 본 금전적 손해에 대한 보상과 제품팀으로 문제를 리포트해 개선하겠다는 다짐도 밝혀주셨죠. 이 자리를 빌어 카카오 T 주차 상담 팀장님께 감사를 전하며, 프로불편러를 상대해야만 했던 상담원분께도 불편을 드려 죄송하다는 말씀을 남깁니다. 그분들이 이 글을 봐주신다면 좋겠네요.

<출처: 작가>

이 글에서 간단하게 예를 든 사건 외에도 수많은 상황을 누군가는 마주하고 또 경험하고 있을 것이고, 이렇게 해주었으면 저렇게 할 수 있다면 하는 많은 방법론들을 생각해 낼 수 있을 것입니다. 이 글을 읽는 독자분들 중에 이런 사항을 경험하고 공감하는 분이 있다면 댓글로 생각을 남겨주세요.

또한, 제품 개발 과정(Agile Product Development Process, APDP)에 대해, 특히 PRD에 대해 궁금한 분들을 위해 커피챗 신청 창구를 만들었습니다. 링크를 참고해 주세요.

]]>

구글 직원은 왜 ‘구글러’일까? 커뮤니케이션 브랜딩의 힘

글을 시작하기 전에 개인적인 이야기를 하나 꺼내볼까 합니다. 저는 대학 시절 광고 회사 입사를 간절히 꿈꿨습니다. 물론 지금 광고 회사에서 근무하지는 않지만 그래도 비교적 유사한 영역에 맞닿아있는 업무들을 하고 있으니 대략 80% 정도의 꿈은 이뤘다고 봐도 되겠죠.

그러다 문득 “나는 왜 그 시절 그렇게 광고 회사에 들어가고 싶었을까?”하는 생각을 해보곤 합니다. 크리에이티브를 다루는 곳에서 일하고 싶다는 이유도 있었고 멋진 광고나 캠페인으로 대중들에게 좋은 영향력을 주는 사람이 되고 싶다는 이유도 한몫했다는 걸 깨달을 즈음 그동안 잊고 있던 사실 하나가 떠올랐습니다.

그때 저는 유난히 ’경쟁 PT(프레젠테이션)’라는 단어에 막연한 선망이 있었거든요. (그게 얼마나 가혹한 것인지도 잘 모른 채로 말이죠.) 고객이나 소비자에게 닿기 전 클라이언트를 대상으로 먼저 설득의 힘을 발휘하는 그 과정이 왠지 모르게 참 멋있다는 생각이 들었고, 광고 회사에 다니는 것은 마치 경쟁 PT에 참여할 수 있는 특별한 권한을 얻는 것이라 생각한 셈이죠.

아주 어린 올챙이 시절의 생각이긴 합니다만, 이렇게 단어가 주는 인식과 경험은 의외로 많은 곳에서 그 힘을 발휘합니다. 회사에 다니다 보면 생각보다 자주 듣는 이야기 중 하나가 바로 조직의 이름에 관한 것인데요, ‘새로 바뀐 팀 이름이 정말 별로예요. 예전 이름이 훨씬 멋지고 좋았는데 말이죠.’라는 식의 반응과 적잖이 마주하게 되기 때문이죠. 참 신기한 일입니다. 내가 하는 업무가 달라지는 것도 아니고 나와 함께 일하는 동료도 그대로인데 그저 팀 이름 하나 바뀐 것이 우리에게 은근히 큰 영향을 준다는 사실이요.

하지만 이 부분이야말로 우리가 지금부터 이야기할 ‘커뮤니케이션 브랜딩’의 효과를 가장 잘 보여주는 지점이라고 할 수 있습니다. 커뮤니케이션 브랜딩이란 우리 조직을 구성하는 구성원들 혹은 우리 사용자나 소비자들이 브랜드의 접점에서 느끼게 될 주요한 단어들을 브랜딩 하는 일이거든요. 쉽게 말해 자칫 남들과 똑같아질 수 있는 포인트를 어떻게 하면 우리만의 정체성과 경험으로 가져올 것인가에 대한 문제죠.

‘때로는 단어 하나가 새로운 문화를 만든다’라는 영국의 유명 인류학자 케이트 폭스(Kate Fox)의 말처럼 좋은 브랜드를 오래 유지하기 위해서는 이 브랜드의 구석구석을 잘 조여주는 볼트와 너트 같은 언어들이 필요한 법이니까요. 어쩌면 커뮤니케이션 브랜딩은 디테일을 다루는 영역이라고도 볼 수 있습니다.

간단해 보이지만 결코 만만치 않은 ‘커뮤니케이션 브랜딩’

명실상부 세계 최고의 IT 기업인 구글은 자신들의 직원을 구글러(Googler)라고 칭합니다. 그리고 구글러로서 익히고 발전시켜야 하는 가치이자, ‘구글다움’의 뜻을 가진 ‘Googleyness’라는 단어도 회사 내부에 아주 널리 퍼져있죠. 수많은 영역에서 무궁무진한 서비스를 다뤄야 하는 사업 특성상 ‘우리는 누구이며, 어떻게 일하는 사람들인가’에 대한 업무 철학을 직원들에게 보다 선명히 전달하려 힘 쏟고 있는 겁니다.

<출처: unsplash>

반면, 애플은 본인들의 제품을 판매하는 오프라인 매장인 애플 스토어의 직원들을 '지니어스(Genius)'라고 부릅니다. 또한 스토어 안에서 A/S를 비롯한 고객 응대가 이뤄지는 장소를 '지니어스 바(Genius Bar)'라고 부르죠. 애플 제품과 관련한 어떤 질문에도 답할 수 있고 동시에 해결책을 찾도록 도와주겠다는 의미에서 단순한 스태프가 아닌 ‘지니어스’라는 단어를 사용하고, 딱딱한 격식이 느껴지는 센터나 카운터 대신 대화에 초점을 맞춘 ’바(Bar)’를 강조했다는 데서 애플이 고객을 대하는 관점을 잘 느낄 수 있습니다.

<출처: unsplash>

이런 사례들을 소개하고 나면 커뮤니케이션 브랜딩이 그저 평범한 단어를 멋지게 포장하는 일일 거라고 예상하는 분들이 많습니다. 하지만 그렇게 간단한 문제라면 모든 기업과 브랜드가 이 커뮤니케이션 브랜딩에 성공하고도 남았겠죠. 오랫동안 좋은 커뮤니케이션을 이어가는 브랜드가 생각보다 드물다는 점, 독특한 단어를 지속적으로 생산하지만, 사람들의 뇌리에 기억되는 사례는 의외로 많지 않다는 점에 주목하면 커뮤니케이션 브랜딩은 결코 만만치 않은 대상임이 분명합니다.

커뮤니케이션의 목표부터 정하자

커뮤니케이션 브랜딩에 성공하기 위해선 “우리는 무엇을 목표로 커뮤니케이션하는가”라는 가장 기본적인 질문에 대해 고민해야 합니다. 그저 ‘브랜딩 효과’라는 추상적인 말로 목표를 정하는 것보다, 우리가 추구하는 커뮤니케이션이 뿌리내리고 나면, 우리는 어떻게 변화할 수 있는지 생생하게 상상되는 구체적인 목적을 마련하라는 의미죠.

이를 위해서는 우리 브랜드가 가진 핵심적인 키워드와 페르소나를 바탕으로 현재의 우리를 돌아볼 수 있어야 합니다. 지금, 무엇을, 어떻게 해야 우리가 설정한 브랜드 키워드와 페르소나를 더욱 또렷하게 만들 수 있는지 그 결핍의 포인트를 짚어보는 것이 중요하니까요.

제 지인 중 한 분은 IT 스타트업에서 브랜드 마케팅을 총괄하고 있습니다. 팀원 여섯 명으로 시작할 때부터 합류한 분인데, 이제는 직원 수만 300명이 넘는 큰 규모의 회사로 발전시켜 활발한 브랜딩 활동을 펼치고 있죠. 그분은 창업 초기부터 유독 인터널 브랜딩에 대한 욕심이 컸고, 무엇보다 이 커뮤니케이션 브랜딩에 많은 노력을 기울였습니다. 그리고 제품과 서비스가 시장에 첫선을 보일 때쯤 본인들을 위한 커뮤니케이션 목표를 정확하게 설정했죠.

한 번 듣고도 그 뜻을 명확히 유추할 수 있는 단어들로 소통한다.
수명이 짧은 유행어 위주의 커뮤니케이션은 최대한 지양한다.
고객을 위한 언어를 따로 만들기보다 고객이 쓸만한 언어를 우리가 먼저 사용해 본다.
새로운 제품명, 마케팅 문구 등을 제작하면 모든 직원에게 알린다.
사람들이 잘 사용하지 않는 단어는 과감히 정리하며, 그 사실을 꼭 공지한다.

한 문단도 채 되지 않는 분량이지만, 이들이 어떤 커뮤니케이션을 목표로 하고 있는가는 어렵지 않게 짐작할 수 있습니다. 남들의 언어를 무작정 따라 쓰지 않으면서도, 명확하게 소통할 수 있는 언어를 지향합니다. 또 어떤 단어 하나가 탄생할 때나 소멸할 때도 이를 당연하게 여기기보다는 모두가 인지할 수 있도록 하자는 게 그들의 방향성일 테니까요. 갓 입사해 팀에 합류한 사람이라고 하더라도, 우리 회사와 우리 브랜드는 어떻게 커뮤니케이션하는 것을 선호하는가에 대한 감을 아주 빨리 캐치할 수 있는 것이죠.

한꺼번에 너무 많은 단어를 만들지 말자

좋은 목표를 정하고 나면 누구나 마음이 두근거립니다. 지금 당장이라도 실천해 보고 싶은 것들이 한 트럭쯤 생겨나니 말이죠. 하지만 의욕이 너무 앞선 나머지 무분별하게 커뮤니케이션을 남발하면 이 역시 역효과를 불러오고 맙니다. 소통의 필요성이야 더 말할 것 없이 중요하지만, 사람들이 수용하고 흡수할 수 있는 수준 이상의 소통은 그 효과가 급격하게 떨어지고 말거든요.

만약 여러분이 평소 잘 사용 중이던 스마트폰이나, 노트북 혹은 가전제품들 중 하나가 고장 나 다른 제조사의 제품으로 바꿨다고 가정해 보죠. 이럴 때 우리를 당황시키는 건 낯선 UI나 사용자 경험이기도 하지만, 예전과 동일한 기능임에도 불구하고 전혀 다른 명칭으로 불리는 용어들이기도 합니다. 설상가상으로 그런 용어가 한두 가지가 아니라 수십 개에 달한다면, 우리는 모든 단어를 다 이해하지 못할 뿐 아니라 그 단어들이 전달하는 총체적인 경험도 받아들이기 힘들 겁니다. 이른바 오버 커뮤니케이션 현상이 일어나기 때문입니다.

<출처: unsplash>

따라서 커뮤니케이션 브랜딩을 할 때도 무작정 좋은 용어들을 만들어 널리 퍼뜨리겠다는 생각보다는 우리가 정한 커뮤니케이션 목표를 이루기 위해서 무엇부터 시작해 볼 것인지 우선순위를 정하는 것이 옳은 방향입니다.

혹시 순위를 매기기가 애매하다면 우리 조직이나, 브랜드가 가진 가장 큰 결핍이 무엇인지를 들여다보는 것도 좋습니다. 스스로 보기에도 가장 약점이라 생각되는 부분을 중심으로 어떤 커뮤니케이션을 시도해 볼 수 있는지 확인하는 것이죠. 괜히 긁어 부스럼 내는 것 아닐까 하는 생각이 들 수도 있지만, 의외로 이런 취약점에서 출발하는 커뮤니케이션 브랜딩이 그 파급력은 훨씬 큽니다. 그러니 과감하게 시도해 볼 가치가 충분한 영역인 셈이죠.

잘 만든 만큼 잘 ‘공유’하자

그럼 이제 가장 중요한 단계로 접어들 때입니다. 바로 사람들에게 어떻게 이 언어들을 사용하게 할 것인가, 다시 말해 어떤 방식으로 커뮤니케이션 브랜딩을 퍼뜨릴 것인가 하는 문제가 남은 거죠. 언뜻 봐서는 그리 어려운 것이 없어 보이지만 이미 사람들이 익숙하게 사용하고 있든, 단어를 바꾸거나 없던 개념을 새롭게 제시하는 일만큼 동기부여가 어려운 대상도 없습니다. 열에 아홉은 이미 편하게 잘 쓰고 있는데, 굳이 어색하게 새로운 이름이 필요할까라는 의구심을 가질 수 있으니까요.

이럴 때 쓸 수 있는 현실적인 팁이 몇 가지 있습니다.

첫째는 일단 테스트 삼아 일부 조직에서만 먼저 그 단어를 사용해 보는 것이죠. 커뮤니케이션 브랜딩을 전 단위로 뿌리기 전에 베타 테스트를 해보는 거라고 생각해 주시면 될 것 같네요.

이렇게 몇몇 사람들끼리 규칙을 정하고 먼저 특정한 단어를 사용하다 보면 잘못 사용될 소지가 있는 포인트를 발견하기도 쉽고 더불어 어떤 경우에 더 효과적으로, 적극적으로 활용할 수 있을지 가늠할 수도 있습니다. 무엇보다 실제 사용하면서 느껴지는 뉘앙스를 통해 여러분이 시도하고자 하는 커뮤니케이션 브랜딩이 어떤 효과를 가져올지 예측해 볼 수 있죠.

두 번째는 상세한 사용법을 함께 제시해 주는 것입니다. 커뮤니케이션 브랜딩을 공유하는 과정에서 단순히 “앞으로 우리는 A를 B라고 부르기로 했습니다”라는 식으로 공표해버리면 언어가 가진 에너지가 절반 이하로 뚝 떨어지고 맙니다. 그래서 되도록 타운홀 미팅과 같이 모두가 모인 자리에서 실제 발음과 텍스트를 함께 느낄 수 있도록 담당자가 직접 소개하는 것이 좋습니다. 만약 여건이 허락된다면 앞으로 어떤 상황에서 어떻게 사용할지, 또 이를 통해 어떤 목표를 이루고자 하는지 그 배경을 설명해 주는 것이 좋습니다.

누군가에게 선물할 때도 그냥 건네기보다 왜 이 선물을 골랐고, 받는 사람에겐 어떤 의미가 있으며, 어떻게 쓰길 바라는지를 간단히라도 설명해 주면 그 가치는 배가 될 겁니다. 그러니 새로운 용어 하나를 소개할 때도 우리 조직, 우리 고객들에게 작은 선물을 한다는 마음을 가져보는 건 어떨까 싶습니다.

<출처: unsplash>

마지막으로는 지속적으로 피드백을 받아 계속 개선해 나가는 겁니다. 말과 글이라는 것은 생명력을 지니고 있기 때문에 사람들에게 한 번 퍼져나가기 시작하면 이를 회수하고 새로 나눠주기가 거의 불가능합니다. 따라서 내부에 특정한 워딩이나 용어를 공유했다면 한동안은 그 말과 글을 사람들이 실제로 잘 쓰고 있는지, 얼마만큼 사용하고 있는지, 또 특별한 불만이나 오남용되는 사례는 없는지 등을 체크하며 관리하는 것이 좋습니다.

일정 기간이 지난 다음 해당 용어에 대한 느낌을 간단한 설문 형태로 받아봐도 좋고, 혹시 부정적인 반응이 크다면 대체어에 대한 아이디어를 역으로 제시받는 것도 큰 도움이 됩니다. 의외로 사람들은 본인들이 부르고 사용할 언어에 대한 욕심이 많기 때문에, 여러분이 우려하는 것보다 적극적으로 참여해 줄 가능성이 큽니다.

더불어 이런 활동들을 통해 구성원 모두가 커뮤니케이션에 대한 책임과 사명감을 갖게 하는 데도 긍정적으로 작용하죠. 그러니 담당자 한두 명의 노력만으로 뭔가를 일궈 내려 하기보다, 소통의 대상이 되는 많은 사람들을 모니터링 요원으로 참여시키는 것이 더 현명한 전략이 될 수 있습니다. 좋은 커뮤니케이션은 진화를 거듭하며 더 좋은 문화를 뿌리내리는 법이니 말이죠.

우리의 현재와 미래를 규정하는 일

백문이 불여일견인 만큼 커뮤니케이션 브랜딩에 성공한 사례 하나를 여러분들께 소개해 보고자 합니다. 이 회사는 푸드테크 서비스에 기반을 두고 현재는 오프라인 공간 대여 서비스까지 그 영역을 확장하고 있는 기업인데요. 업계 특성상 다양한 파트너와 마주해야 하고, 성수기나 크리스마스 시즌에는 직원들이 직접 현장에 머물며, 배달이나 유통까지 담당해야 하기 때문에 업계에선 꽤 터프한 직무로 인식된다고 합니다.

따라서 자칫 직원들이 ‘내가 이런 일까지 해야 하나?’라는 부정적 인식을 가지지는 않을까 하는 우려가 사업 초창기부터 컸다고 하죠. 이에 담당자들은 우선 커뮤니케이션 브랜딩의 목표를 ‘우리는 사업자를 돕기 위해 A부터 Z까지 모두 실행한다. 그 과정에서 새로운 기회와 가치를 발견하고 이를 다시 미래로 연결한다’라고 정했다고 합니다. 정말 멋진 목표가 아닐 수 없죠. 현실에 초점을 두면서도 우리가 왜 이 일을 하고 있는지에 대한 목적의식을 정확히 심어주는 것이니까요.

그리고 다시 담당자들이 모여 이 가치관에 부합하는 커뮤니케이션 컨셉을 고민하다가 ‘항해’에서 그 해답을 찾았다고 합니다. 다소 거친 영역을 다루고는 있지만 명확하고 도전적인 목표가 있다는 점과 실제로 수많은 요리 재료와 보관법, 제조법 등이 대항해시대에 개발되었다는 점에 착안해 본인들이 다루는 업의 특성을 잘 녹여낼 수 있는 대상과 연결 지은 것이죠.

먼저 이 브랜드는 초기 17명 남짓한 직원들을 승무원, 혹은 선원의 뜻을 가진 ‘크루(crew)’로 부르는 것에서부터 커뮤니케이션 브랜딩을 시작했습니다. 한배를 탄 동료이자, 각각의 임무와 역할이 사업의 운명을 결정할 만큼 중요하다 뜻에서 스스로를 이렇게 부르기로 한 것이죠.

또 새로운 프로젝트 하나를 런칭하는 것은 돛을 펴고 출항하는 행위에 빗대 ‘세일링(sailing)’이라고 부른다고 합니다. 그러니 “이 프로젝트는 언제 시작해요?”가 아니라 “이번 세일링은 언제 시작하죠? 어떤 분들이 세일링 멤버로 참여하나요?”로 소통한다고 해요.

그 외에도 내부적으로 데이터를 집계하고 관리하는 대시보드 프로그램 이름은 나침반에서 따온 컴퍼스(compass)로, 야간에 모니터링을 담당하는 직원들은 항해할 때 주요한 지표가 되는 북극성에서 착안해 폴라(polar)로 부른다고 합니다. 조금은 딱딱할 수 있었던 내부 용어들을 말랑말랑하게 바꿔준 것은 물론이고, 이들이 가고자 하는 목표와 하나 된 팀워크까지 잘 녹여낸 커뮤니케이션 브랜딩을 완성할 수 있었죠. 사실상 거의 비용을 들이지 않고도 아주 멋지고 훌륭한 문화를 만들어낸 겁니다.

<출처: unsplash>

단어 하나가 불러오는 ‘나비효과’

지금까지 브랜드 사례와 제 나름의 방법들을 소개했지만, 사실 커뮤니케이션 브랜딩에 있어 가장 필요한 것은 ‘용기’라고 생각합니다. 갑자기 용기를 꺼낸 게 의아해하실 수도 있지만, 겉으로 보기엔 굳이 시도하지 않아도 큰 지장이 없어 보이는 게 바로 ‘커뮤니케이션 브랜딩’일 수 있거든요.

그럼에도 불구하고 ‘우리도 좋은 커뮤니케이션 브랜딩을 해봐야지’라고 마음을 먹었다는 건 사소한 문제도 모른척하지 않는 용기, 더 나은 방향으로 모두를 설득해 보고자 하는 그 용기가 작동한 거라고 봅니다. 그래서 저는 커뮤니케이션 브랜딩을 담당하는 분들을 보면, ‘인식과 문화를 만든다는 일이 저분들의 손끝에서부터 출발하는구나’ 하는 생각이 들어 존경심이 생기곤 합니다.

그러니 여러분도 너무 오래 머뭇거릴 필요 없이 각자의 주변에서 이뤄지고 있는 커뮤니케이션을 한 번 주의 깊게 살펴보면 어떨까요? “우리 팀에서 무심코 사용하고 있는 내부 용어들에는 뭐가 있을까?”, “우리 브랜드가 고객이나 사용자와 더 원활한 커뮤니케이션을 하기 위해서는 어떤 목표부터 세워봐야 할까?” 같은 질문을 스스로에게 던져본 다음, 내 손으로 바꿔볼 수 있는 것들을 하나하나 주워 모으는 방식으로요.

저 역시 처음에는 ‘이거 하나 바꾼다고 누가 알아주기나 할까?’라는 의구심이 컸지만, 지금은 제가 만든 용어들이 널리 널리 퍼져나가고 있는 걸 볼 때마다 그때 용기를 내지 않았으면 어쩔 뻔했나 싶어 가슴이 서늘해집니다. 그만큼 여러분도 자신의 역량을 믿고, 작은 것에서부터 출발해 보시면 좋겠습니다. 훗날 엄청나게 큰 나비효과가 되어, 여러분의 조직과 브랜드를 굳건히 지탱해 줄지도 모르니 말이죠.

]]>

AI로 묻고 답하는 설문조사 툴 ‘Theysaid’

제가 PM으로 일하면서 주기적으로 진행하는 업무 중 하나는 유저 리서치입니다. 그중에서도 설문조사는 정량 조사의 방법으로 다양한 목적에 따라 자주 활용하고 있는데요. 최근에는 인공지능(AI)의 도움으로 설계에 드는 시간이 어느 정도 줄어들긴 했습니다. 하지만 여전히 처음에 어떤 방향으로 질문을 구성할지, 또 질문의 의도에 맞춰 어떤 응답 유형을 선택해야 좋을지 고민이 많습니다. 게다가 설문조사만으로는 응답자의 정확한 의도를 파악하기 어려운 경우가 많아, 대부분 후속 작업을 추가로 고민하게 됩니다.

그래서 오늘은 이러한 상황에서 도움이 될 만한 서비스를 소개하고자 합니다. 설문 제작부터 응답과 분석 과정 전반에 걸쳐 인공지능을 적극적으로 활용할 수 있는 ‘Theysaid’입니다.

‘Theysaid’의 주요 기능은 다음과 같습니다.

AI 기반 설문조사 생성: 사용자가 알고 싶은 내용을 짧게 입력하면, AI가 적합한 설문 질문 생성
설문 참여 시 개입: 설문 응답자가 AI와 대화하면서 답변을 제공하기 때문에, 보다 다양한 인사이트를 확인 가능
다양한 설문 유형: 여러 형식의 설문 유형을 지원하며, 그에 따른 템플릿과 샘플을 제공해 빠른 설계 가능

사실 이 서비스가 단순히 설문 항목 생성만 지원했다면 굳이 소개하지 않았을지도 모릅니다. 그러나 ‘Theysaid’는 기존의 딱딱한 방식에서 벗어나, 참여자가 더 진솔한 피드백을 제공하도록 유도한다는 점에서 더 큰 활용 가치를 느꼈습니다. 응답자는 설문을 진행할 때 AI와 자연스럽게 대화하며, 마치 인터뷰를 하는 것처럼 편안하게 의견을 표현할 수 있어, 기존 방식보다 훨씬 더 의미 있는 정보를 얻을 수 있습니다.

설문 목적만 입력해도 기본 질문을 생성

<출처: Theysaid, 작가 캡처>

가입 후, 우리가 가장 먼저 선택할 수 있는 건 구성 방식입니다. 크게 세 가지로 나뉘며, 1) 하나의 질문으로 인터뷰하듯 사용자의 의견을 받는 방법 2) 기존 설문과 같이 질문을 여러 개 구성하고 의견을 받는 방법 3) 아직 공개 전이지만, 1:1 인터뷰를 전문적으로 진행하는 방법입니다. 각 선택지에 대한 설명을 함께 제공하고 있어, 처음이라도 어렵지 않게 원하는 조건을 빠르게 훑고 다음 단계로 이동할 수 있습니다.

<출처: Theysaid, 작가 캡처>

저는 두 번째 방법인 여러 개의 질문을 활용하는 방식을 선택하고, ‘뉴스레터 신규 멤버십에 대한 설문’이라는 내용을 입력했습니다. 그리고 만나게 되는 화면은 설문에 포함할 질문과 타입, 타입별 항목을 입력하는 단계입니다. 눈에 띄는 건 이미 다섯 개의 질문과 질문의 성격에 따라 5점 척도, 서술형 등의 타입은 물론 필요한 경우, 보기까지 입력되어 있다는 점입니다.

<출처: Theysaid, 작가 캡처>

한 가지 유의할 점은 서비스 자체의 언어가 영어라서, 질문을 한글로 변경하기 위해서는 약간의 작업이 필요합니다. 질문은 세 가지 방법으로 수정할 수 있는데요. 1) 생성된 질문을 개선 2) 생성된 질문을 수정 3) 직접 입력입니다. 1번의 경우 별다른 요청 사항을 입력할 수 없지만 버튼 클릭으로 가능하고, 2번의 경우 요청 사항을 입력해 구체적인 작업이 가능합니다. 예를 들어, ‘멤버십 결제 방식 선호도에 관한 질문을 한글로 작성해 줘’와 같은 방법입니다. 언어도 이때 변경할 수 있습니다.

<출처: Theysaid, 작가 캡처>

생성된 질문은 응답 유형을 확인하고 수정할 수 있는데요. 현재 적용된 건 서술식, 객관식, 5점 척도, 랭킹, 이미지 선택 등 다섯 가지입니다. 서비스가 초기 버전이다 보니, 아직 선택지가 많지는 않지만 계속 업데이트될 예정이라고 합니다. 또한 필수 응답 여부나 기타 옵션 추가, 이미지나 영상 추가, AI 활용 등의 옵션을 토글 형태로 선택할 수 있습니다.

<출처: Theysaid, 작가 캡처>

질문을 모두 생성하면, 설정 단계로 넘어갈 수 있습니다. 이 단계에서는 설문의 목적을 다시 확인할 수 있고, 응답 시 이메일 주소 입력 여부나 설문 시작 시 안내할 메시지 입력과 완료 후 내보낼 메시지를 작성할 수 있습니다. 또 설문이 끝난 뒤 참여자를 어떤 페이지로 보낼지(리다이렉트)도 설정할 수 있는 모습입니다. 인사, 감사 메시지 등을 더 정교하게 입력하지 못하는 건 아쉽지만, 리다이렉트 URL을 설정할 수 있다는 점은 유용합니다.

<출처: Theysaid, 작가 캡처>

마지막 단계는 발행입니다. 이메일이나 웹사이트에 임베드하거나, 링크 또는 QR을 생성해 설문을 내보낼 수 있습니다. 여기서 흥미로웠던 건, 실제 참여자가 설문에 참여하는 방식 그대로 미리 체험을 해볼 수 있다는 점이었는데요. 아무래도 우리가 자주 쓰는 tally나 구글 폼과 같이 일방적인 답변 등록이 아니라, 등록한 답변이나 선택지에 따라 인공지능이 추가 질문 등을 진행하기에 미리 체험해 보지 않으면, 오히려 설문 설계 방법에 따라 이탈이 높아질 수 있기 때문입니다.

<출처: Theysaid, 작가 캡처>

그렇게 참여자가 되어 실제 설문을 진행해 봤습니다. 페이지 단위나 질문을 쭉 나열하는 방식이 아니라 채팅과 같이 질문하나를 먼저 보여주고, 해당 질문에 대한 응답을 입력하면 인공지능이 등장해 자연스럽게 연관된 질문을 던지는 방식입니다.

예를 들어, ‘신규 멤버십 구독 가능성’을 4점으로 평가했는데, 높게 평가한 이유가 뭔지를 묻는 방법입니다. 보통 NPS를 진행할 때, 선택한 점수에 따라 추가 질문을 활용하거나, 인터뷰 참여 여부를 이어가는 경우가 많은데요. 이건 설문 흐름 자체에 비슷한 방법을 활용할 수 있어 보다 깊이 있는 의견을 확인할 수 있을 것 같습니다.

액션 아이템까지 포함된 분석 제공

<출처: Theysaid, 작가 캡처>

앞서 제가 이 서비스는 설문 설계는 물론 응답과 분석 과정에도 AI가 적극적으로 활용된다고 했는데요. 저는 설문을 지인 3명에게 전달한 뒤 답변을 받았고, 가장 먼저 확인할 수 있었던 건 기본적인 분석 내용이었습니다. 여기까지는 일반적인 설문 관련 서비스에서도 확인할 수 있는 수준인데요.

<출처: Theysaid, 작가 캡처>

차별점은 기본 분석 외에도 인사이트나 액션 아이템도 함께 확인할 수 있다는 점입니다. 위 이미지는 참여자의 응답 내용을 바탕으로 인사이트를 정리해 준 모습입니다. 우측 상단, 종합 평가를 확인할 수 있는데, “사용자들은 새로운 콘텐츠와 프로그램에 긍정적인 관심을 보이며, 뉴스레터 기반 멤버십 프로그램의 비용 대비 가치에 대해 호의적으로 인식하고 있는 것으로 나타났습니다.”와 같은 내용이 담겼습니다. 왼쪽으로는 각 응답에서 꼭 확인해야 할 내용들을 선별해 보여주고, 이는 액션 아이템과도 연결됩니다.

<출처: Theysaid, 작가 캡처>

마지막으로 정리된 액션 아이템의 모습입니다. 분석 - 인사이트를 바탕으로 우리가 무엇을 먼저 실행해야 하는지에 대한 내용이 담겨있습니다. 예를 들어, ‘응답 중 멤버십에 대한 소개가 부실하다’라는 내용이 있었고, 이는 부정적인 응답으로 인사이트에 포함되어 있었는데요. 이를 해결하기 위해 보다 자세한 내용을 추가해야 한다는 액션 아이템이 생성되어 있습니다. 액션 아이템은 체크리스트로 구성되어, 작은 프로젝트라면 이곳에서 진행 여부도 쉽게 관리할 수 있습니다.

한 번은 꼭 써봐야 하는 이유

<출처: Theysaid, 작가 캡처>

‘Theysaid’는 만족도 조사나 시장 핏에 최적화된 템플릿을 별도로 제공합니다. 또한 인공지능을 활용한 설문 제작이 가능한 환경이지만, 목적에 따라 출발점이 다를 수 있다는 점을 고려, 템플릿을 활용해 보다 빠른 작업이 가능하게 도와줍니다. 덕분에 “목적에 따라 어떤 설문을 진행해야 하지?” 같은 고민을 줄일 수 있습니다. 무엇보다 리서치의 전 과정에 인공지능을 적절히 활용할 수 있다는 점에서 작업 효율에 많은 도움을 받을 수 있었습니다.

<출처: Theysaid, 작가 캡처>

물론 아쉬운 점도 있습니다. 인공지능이 전체 질문 흐름을 종종 놓쳐 추가 질문에 대해 답한 내용을 다음 질문으로 제공하는 경우도 있고, 서비스의 언어 자체를 바꾸진 못해 한글로 바꾸는 작업을 계속 요청해야 하기 때문입니다. 그럼에도 무료로 1개의 설문 기준, 기본 기능을 모두 활용할 수 있고, 50개까지의 답변을 받을 수 있어 충분한 환경을 제공합니다. 설문 제작, 응답, 분석 과정에서 한 번쯤 활용해 보셔도 좋겠습니다.

<참고>

https://ai.theysaid.io/

]]>

생각만으로 글 쓰는 시대 올까? 뇌-컴퓨터 인터페이스 혁명

뇌-컴퓨터 인터페이스(BCI) 분야 최신 연구와 미래 전망

개발자 그리고 작가의 삶을 살아가면서 매일 밤 서재에서 이런 상상을 합니다. ‘머릿속 생각만으로 글을 쓸 수 있으면 얼마나 좋을까?’ 그런데 이 단순한 상상이 사실은 인류가 오랫동안 꿈꿔온 기술적 도전이었죠. 더 놀라운건 공상영화에서만 가능했던 그 기술이 이제는 현실이 되어가고 있다는 점입니다.

과학기술의 역사는 언제나 인간의 한계를 뛰어넘는 도구를 만들어 온 여정이었습니다. 바퀴는 우리의 이동 능력을, 망원경은 시력을, 컴퓨터는 계산 능력을 확장했어요. 그리고 지금, 우리는 또 다른 경계 위에 서 있습니다. 바로 ‘생각’이라는 가장 사적인 영역과 디지털 세계를 직접 연결하는 기술이 등장한 것이죠!

"상상만 하면 현실이 된다면 어떨까요?”

영화 '월터의 상상은 현실이 된다'에서 주인공 월터 미티는 지루한 일상에서 벗어나 풍부한 상상의 나래를 펼치며 관객들의 마음을 사로잡았습니다. 히말라야의 설산을 정복하기도 하고, 깊은 바닷속을 탐험하기도 하면서 단지 ‘생각’만으로 평범한 현실을 놀라운 모험으로 변화시킨 멋진 영화죠.

<출처: 영화 월터의 상상은 현실이 된다, 2013년>

그런데 영화 속 그 상상의 영역이 이제는 SF 영화의 스크린을 넘어 우리 곁으로 성큼성큼 다가오고 있습니다. 생각만으로 타이핑을 하고, 머릿속에 담긴 아이디어를 곧장 디지털 캔버스 위에 그리며, 말을 하지 않아도 컴퓨터에 명령을 내리는 기술이 현실로 이루어지고 있기 때문이죠. 과학자들이 수십 년간 꿈꿔온 인간의 두뇌와 기계 사이의 직접적인 소통 기술, 이른바 ‘뇌-컴퓨터 인터페이스’(Brain-Computer Interface, 이하 BCI)가 마침내 실험실을 벗어나 우리의 일상을 야금야금 침범해오고 있다고 합니다.

복잡한 뇌 신호에서 의미를 추출해내는 이 기술은 말 그대로 ‘생각만으로 타이핑하는 것’을 가능하게 합니다. 영화 속 주인공 ‘월터 미티’가 상상 속에서 경험했던 것처럼, 우리 역시 곧 생각만으로 디지털 세계와 소통하고 아이디어를 실현하게 될지도 몰라요. 정말 키보드 없이 컴퓨터를 사용하고, 마우스 없이 인터넷 쇼핑을 할 수 있는 날이 오게 될지도 모르죠. 그렇게 된다면 미래의 여러분은 컴퓨터 앞에서 씨름하는 대신 SF 영화 속 등장인물들처럼 인공지능과 함께 무엇이든 자유롭게 해낼 수 있을 거예요. 회의시간에도 생각만으로 회의록을 작성하고, 수업시간에도 필기구 하나 없이 듣는 내용을 생각만으로 정리해 온라인 노트에 전송할 수 있다면, 지금보다 훨씬 뛰어난 생산성을 갖게 될 겁니다.

이 놀라운 상상이 현실이 되는 이야기 속으로 함께 떠나볼까요?

연구1. 머릿속 ‘칩’ 없이, 뇌파에서 문장을 읽다

메타(Meta) 연구팀은 스페인의 바스크 인지·뇌·언어 센터(Basque Center on Cognition, Brain and Language)와 협력하여 MEG(자기뇌파검사)와 EEG(뇌전도검사)를 활용해 35명의 건강한 자원자들의 뇌 활동을 기록했어요. 참가자들이 문장을 타이핑하는 동안 나타나는 뇌 신호를 인공지능 모델이 분석했고, 이를 통해 최대 80%의 정확도로 원본 문자를 재구성하는 데 성공했죠. 연구진에 따르면, 이는 기존 EEG 시스템과 비교해 최소 2배 이상 향상된 성능이라고 합니다.

이 연구의 핵심은 ‘비침습적 방법’을 사용했다는 점이에요. 비침습적 방법이란, 쉽게 말해 머리에 칩을 삽입하기 위해 구멍을 뚫지 않아도 된다는 뜻입니다. MEG와 EEG는 모두 두피 표면이나 그 주변에서 뇌 활동을 측정하는 기술이에요. EEG는 두피에 전극이 부착된 캡(cap)을 쓰는 방식이고, MEG는 머리 주변에 특수 센서가 장착된 헬멧 형태의 장비를 사용한다고 해요. 두 방법 모두 일상적인 헤드셋처럼 착용했다가 필요 없으면 바로 제거할 수 있어서, 굳이 생각을 읽기 위해 신체를 손상할 필요가 없다는 점이 매력적이죠.

기존의 연구는 주로 뇌에 전극을 직접 삽입하는 침습적 방법에 의존했다고 해요. 이 방식은 정확도는 높지만 신경외과적 시술이 필수적이고 감염 위험이 있으며, 대규모로 활용하기 어렵다는 한계가 있었죠. 단지 생각 하나 읽으려고 머리에 구멍을 낸다니, 상상조차 하기 어려운 일이잖아요?

반면, MEG와 EEG는 두피 외부에서 뇌의 활동을 측정하는 방식이라 신호에 노이즈(noise)가 많고 매우 복잡해서, 지금까지는 높은 정확도를 얻기가 어려웠어요. 하지만 메타 연구팀은 최신 인공지능 기술을 활용해 이러한 한계를 극복했고, 그 결과 비침습적 방법을 통해서도 정확한 텍스트 디코딩(decoding)이 가능하다는 점을 입증했습니다.

말하지 않고 생각을 전할 수 있다면?

이 기술이 완성되면 뇌 손상으로 의사소통 능력을 잃은 수백만 명에게 새로운 소통 수단이 제공될 수 있어요. 뇌졸중, 루게릭병(ALS), 다발성 경화증, 외상성 뇌 손상 등으로 말하거나 움직이는 것이 불가능한 환자들이, 자신의 생각을 직접 텍스트로 표현할 수 있게 되는 거죠.

현재 이러한 환자들을 위한 보조 의사소통 장치는 대부분 눈의 움직임이나 근육의 신호를 이용하지만, 이마저도 불가능한 환자들이 많아요. 스티븐 호킹 박사의 경우처럼 안면 근육의 미세한 움직임으로 컴퓨터를 조작할 수 있는 사람은 그야말로 소수에 불과했답니다.

영화 <잠수종과 나비> 에서 감금증후군(locked-in syndrome)에 걸린 주인공 ‘장 도미니크 보비’는 뇌졸중 이후 왼쪽 눈꺼풀만 깜빡일 수 있는 상태가 되었어요. 그는 간병인이 알파벳을 하나씩 읽어줄 때 자신이 원하는 글자가 나오면 눈을 깜빡여 단어를 만들어 내는 방식으로 한 권의 책을 집필했습니다.

<출처: 영화 잠수종과 나비, 2007년>

만약 비침습적 뇌-컴퓨터 인터페이스가 있었다면, 단지 말하고 싶은 내용을 머릿속으로 생각하는 것만으로도 텍스트를 생성할 수 있었겠죠. 이는 단순한 편의성의 향상이 아니라, 많은 환자들에게 잃어버린 목소리를 되찾아주는 근본적인 변화를 의미한답니다.

연구2. 생각에서 단어로, ‘뇌’의 움직임을 읽다

메타 연구팀의 두 번째 연구는 더욱 흥미진진해요. 그들은 AI(인공지능)를 활용하여 인간의 뇌가 생각을 언어로, 그리고 타이핑이라는 행동으로 변환하는 과정을 밝혀냈어요. 초당 1,000개의 뇌 스냅샷(snapshot)을 촬영함으로써, 생각이 단어나 음절, 개별 글자로 전환되는 정확한 순간을 포착할 수 있게 되었죠.

이 연구는 뇌가 먼저 문장의 의미와 같은 가장 추상적인 수준에서 시작하여, 점진적으로 실제 타이핑 동작으로 변환하는 일련의 표현을 생성한다는 것을 보여줍니다. 또한 뇌가 ‘동적 신경 코드(dynamic neural code)’라는 특별한 메커니즘을 사용해 연속적인 표현들을 서로 연결하면서도 각각을 장기간 유지한다는 사실도 밝혀냈어요.

이 발견은 단순히 기술적인 돌파구를 넘어, 인간 언어와 사고의 본질에 대한 깊은 통찰을 제공합니다. 우리가 어떻게 추상적인 생각을 구체적인 단어와 문장으로 바꾸는지, 또 이 과정이 어떻게 두뇌의 다양한 영역 간 조율을 통해 이루어지는지를 이해하는 데 크게 기여하죠.

연구팀은 이렇게 설명합니다.

“사람이 말을 할 때 뇌가 어떻게 작동하는지를 연구하는 건 신경과학에서 늘 어려운 과제였어요. 입이나 혀를 움직이는 과정이 뇌 영상 신호를 많이 방해하기 때문이죠. 그래서 이번 연구에선 말 대신 타이핑을 하게 해서, 이런 기술적인 문제를 피하고 언어를 만들어내는 뇌의 작동 방식을 더 잘 들여다볼 수 있었습니다.”

실용화를 위한 도전 과제

이 혁신적인 기술에도 불구하고, 실제 임상 환경에서 적용되기까지는 아직 여러 도전 과제가 남아 있어요.

1. 정확도와 성능의 한계

현재 문자 정확도가 80%라는 큰 발전을 이루었지만, 실용적으로 원활히 소통하기에는 충분하지 않을 수 있습니다. 특히 중요한 의학적 결정을 내리거나 복잡한 대화를 나눌 때는 훨씬 더 높은 정확도가 요구되죠. 예를 들어 친구와 대화할 때 80%만 알아듣는다면 많이 답답할 수밖에 없겠죠. 그래서 연구팀은 더 큰 데이터셋(dataset)과 개선된 AI 모델을 구축하여 이 정확도를 더욱 높이는 방법을 연구 중이라고 합니다.

<출처: ChatGPT, 요즘IT 제작>

2. 기술적 제약사항

MEG는 자기적으로 차폐된 특수한 방에서 참가자가 거의 움직이지 않은 상태로 측정해야 하는 제약이 있어요. 이는 실용성과 편의성에 큰 제한을 가져옵니다. 우리가 마치 블루투스 키보드를 사용하듯 편리하게 이용할 수 있다면 좋겠지만, 아직은 특별한 장치 안에서 측정해야 하기 때문에 일상적인 활용은 사실상 불가능한 상황이죠. 그래서 연구팀은 보다 휴대가 가능하고 일상 환경에서도 쓸 수 있는 뇌 활동 측정 장치 개발을 목표로 하고 있다고 합니다.

3. 개인별 차이와 적응성

뇌의 신경 패턴은 사람마다 큰 차이가 있다고 합니다. 현재의 연구는 각 참가자별로 모델을 개별적으로 훈련시켜 사용했지만, 실제로 실용화하려면 보다 일반화할 수 있는 모델이나 짧은 보정 과정만으로도 개인에게 빠르게 적응 가능한 시스템이 필요하죠. 저처럼 평소 생각이 많은 사람이 사용하려면, 이런 부분의 발전이 조금 더 필요할 것으로 보이네요.

4. 임상 환경으로의 전환

현재 연구는 건강한 자원자들과 함께 진행되었지만, 실제 신경학적 손상이 있는 환자들에게 적용하기 위해서는 추가적인 연구가 필요하다고 해요. 뇌 손상은 신경 활동 패턴을 변화시킬 수 있으며, 이는 디코딩 알고리즘의 효과에 영향을 미칠 수 있다고 해요. 앞서 말한 ‘장도미니크 보비’외에도 뇌가 손상된 분들을 위해서는 좀 더 연구가 필요로 할 거 같아요.

5. 윤리적 고려사항

생각을 읽는 기술은 프라이버시와 인지적 자유에 관한 중요한 윤리적 질문을 제기해요. 영화에서처럼 만약 누군가를 납치하고 이 장치를 씌운다면, 그 사람의 모든 비밀을 쉽게 알아낼 수도 있겠죠? 이처럼 기술이 악용될 우려가 있기 때문에, 연구팀은 이 기술을 반드시 사용자의 명시적 동의와 통제 아래에서만 사용할 수 있도록 해야 한다고 강조해요. 또한 개인의 사고 프라이버시를 철저히 보호하기 위한 강력한 안전장치를 개발하는 데도 주력하고 있다고 합니다.

뇌-컴퓨터 인터페이스의 미래 전망

이러한 도전 과제에도 불구하고, 뇌-컴퓨터 인터페이스 기술은 빠르게 발전하고 있으며, 미래에는 다양한 분야에서 혁명적인 변화를 가져올 것으로 예상돼요.

1. 의학적 응용

가장 직접적으로 활용 가능한 분야는 의사소통 장애를 가진 환자들을 위한 보조 기술이에요. 그뿐 아니라 뇌-컴퓨터 인터페이스는 신경 재활, 의수와 의족의 제어, 심지어 뇌 손상 이후 손실되었던 인지 기능의 복원에도 활용될 수 있어요.

2. 인간과 컴퓨터 상호작용의 새 패러다임

더 먼 미래에는 이 기술이 일반 사용자를 위한 새로운 인터페이스 방식으로 발전할 수도 있어요. 키보드나 마우스, 심지어 음성 명령보다 더 직관적이고 빠른 방식으로, 단순히 생각만으로 디지털 환경과 소통할 수 있을 거란 기대가 있습니다.

3. 온라인

더 나아가, 이 방식은 인간의 인지 능력 자체를 확장하는 도구로 발전할 수도 있어요. 모든 사람의 생각과 생각이 연결되는 거대한 온라인 체계가 구축될 수 있다는 가능성도 있죠. 이렇게 되면 다른 사람의 생각에 직접 접근하는 형태의 통신이 가능해질 수 있고, 이는 엄청난 혁신으로 이어질 수 있겠죠.

4. 새로운 창작과 표현의 형태

예술과 창작 분야에서도 이 기술은 흥미로운 가능성을 제시해요. 음악가, 아티스트, 작가들이 자신의 창의적인 생각을 중간 매체 없이 곧바로 디지털 형태로 표현할 수 있게 되는 거죠. 머릿속에 떠올린 이미지가 즉시 캔버스에 나타나거나, 상상 속 멜로디가 즉각 음악으로 변환되는 세상이라니, 이렇게 되면 정말 ‘영감’이 그 어느 때보다 중요한 시대가 될 것 같아요.

BCI 분야 글로벌 선두주자들

메타의 뇌 신호 디코딩 연구 말고도, 지금 전 세계 여러 연구팀들이 뇌-컴퓨터 인터페이스 분야에서 정말 혁신적인 기술들을 만들어내고 있어요. 이 기술들은 서로 접근 방식이나 세부 목표는 조금씩 다르지만, 모두 우리 머릿속 생각과 디지털 세계를 직접 이어주는 다리를 놓으려는 꿈을 함께 꾸고 있죠.

1. 뉴럴링크(Neuralink)의 침습적 BCI

일론 머스크가 설립한 뉴럴링크(Neuralink)는 현재 가장 야심찬 뇌-컴퓨터 인터페이스 프로젝트 중 하나예요. 이 회사는 2023년 5월 미국 식품의약국(FDA)으로부터 인간에게 임상실험을 할 수 있도록 승인을 받았으며, 2024년 초 최초의 인간 대상 임상 시험을 시작했어요. 다만 뉴럴링크의 접근 방식은 수천 개의 미세한 전극 실(thread)이 장착된 동전 크기의 임플란트를 뇌에 직접 삽입하는 침습적 방식을 사용해요.

<출처: 뉴럴링크 홈페이지>

뉴럴링크의 초기 목표는 사지마비 환자들이 생각만으로 컴퓨터를 제어할 수 있도록 돕는 것이에요. 하지만 장기적인 관점에서는 인간 뇌와 인공지능의 ‘공생(symbiosis)’을 촉진하는 것을 목표로 하고 있다고 합니다.

2. DARPA의 N3 프로그램

미 국방고등연구계획국(DARPA)의 비침습적 비외과적 신경기술(Non-surgical Neurotechnology, N3) 프로그램은 수술하지 않고도 고정밀 뇌-컴퓨터 인터페이스를 구현할 수 있는 기술 개발을 목표로 하고 있어요. 이 프로그램은 초음파, 광학, 전자기적 방법 등을 활용하여 뇌의 개별 뉴런(neuron) 수준에서 신호를 읽고 쓰는 기술을 연구하고 있습니다.

DARPA의 접근 방식은 비침습적이면서도 높은 시공간적 해상도를 달성하는 게 핵심 목표예요. 만약 이 프로그램이 성공한다면 군사적 활용 외에도 민간 의료와 소비자 기술 분야에 혁신적인 영향을 미칠 것으로 기대돼요.

3. 브라운 대학의 브레인게이트(BrainGate)

브레인게이트(BrainGate)는 브라운 대학교를 중심으로 매사추세츠 종합병원(MGH), 하버드 의대, 스탠퍼드 대학교, Providence VA 등이 참여하는 연구 컨소시엄으로, 침습형 뇌-컴퓨터 인터페이스(BCI)를 통해 마비 환자들이 생각만으로 로봇 팔을 제어하거나 컴퓨터 커서 등을 조작할 수 있는 기술을 개발하고 있어요.

2021년에는 연구팀이 사지 마비 환자가 무선 BCI를 통해 태블릿을 제어하고 분당 약 90자의 텍스트를 입력할 수 있는 시스템을 시연하기도 했답니다.

4. MIT 미디어 랩의 알터에고(AlterEgo) 프로젝트

비록 직접적인 뇌-컴퓨터 인터페이스는 아니지만, MIT 미디어 랩(MIT Media Lab)의 알터에고(AlterEgo) 프로젝트는 사용자가 소리를 내지 않고도 말하려는 단어를 인식할 수 있는 기술을 개발했어요. 이 기술은 턱과 얼굴에 부착된 센서를 통해 내부 발화(internal vocalization) 시 일어나는 미세한 근육 움직임을 감지하는 방식이랍니다.

이러한 기술은 시끄러운 환경에서의 통신이나 개인 정보 보호가 필요한 상황에서의 의사소통, 그리고 음성 장애가 있는 사람들을 위한 보조 도구로도 활용될 수 있을 것으로 기대돼요.

생각의 힘을 해방하다

생각만으로 디지털 세계와 상호작용할 수 있는 미래는 이제 공상과학 영화의 영역을 넘어 현실로 성큼 다가오고 있어요. 메타의 최신 연구는 바로 그 여정에서 중요한 이정표를 세웠으며, 앞으로 수년 내에 더 많은 발전이 이루어질 것으로 기대를 모으고 있습니다.

비침습적 뇌-컴퓨터 인터페이스의 발전은 단순한 기술적 성취를 넘어, 인간 경험의 본질 자체를 변화시킬 놀라운 잠재력을 지니고 있어요. 의사소통의 장벽을 무너뜨리고, 인간의 창의성과 표현력을 확장하며, 나아가 인간 의식과 자아에 대한 우리의 이해를 근본적으로 재정의할 수 있을지도 모르죠.

<출처: 픽사베이>

물론 이러한 변화는 신중하게 탐색해야 할 윤리적, 사회적 도전을 수반합니다. 그러나 책임감을 가지고 개발하고 적절히 활용한다면, 이 기술은 인류에게 전례 없는 기회와 가능성의 문을 활짝 열어줄 거라 기대됩니다.

생각의 힘을 해방시키는 이 여정은 이제 막 시작되었어요. 우리가 이 기술을 어떻게 발전시키고 활용할지는 앞으로 미래에 큰 영향을 미칠 매우 중요한 질문이죠. 저는 특히 이 기술이 의료 분야에서 가져올 변화에 큰 기대를 걸고 있습니다. 의사소통 장애를 가진 사람들에게 자신의 목소리를 돌려줄 수 있다면, 그것만으로도 이 기술의 가치는 이미 충분하니까요. 나아가 이 기술이 우리 모두의 창의성과 표현력을 확장하는 도구로 발전한다면, 인류의 문화적, 지적 발전에도 크게 기여할 수 있으리라 생각합니다.

<출처>

[meta] Using AI to decode language from the brain and advance our understanding of human communication
[thieme-connect] Neuralink and Brain–Computer Interface—Exciting Times for Artificial Intelligence
[battelle] Battelle Neuro Team Advances to Phase II of DARPA N3 Program
[stanford] Stanford joins BrainGate team developing brain-computer interface to aid people with paralysis
[tistory] MIT가 만든 생각읽는 웨어러블 장치 알터에고(Alterego)
[dongascience] BCI 기술의네 가지 미래
[tistory] 뇌-컴퓨터 인터페이스의 응용분야(applications in Brain-Computer Interfaces)
[tistory] 뇌-컴퓨터 인터페이스(BCI) 기술의 발전과 미래
[scienceon]“AI 뇌해독기로 생각읽는다”…美연구팀, fMRI로 생각읽기 성공
[National Library of medicine] ]Home Use of a Percutaneous Wireless Intracortical Brain-Computer Interface by Individuals With Tetraplegia

]]>

프로젝트보다 ‘프로덕트’ 중심 마인드셋이 중요한 이유

본문은 요즘 IT와 번역가 Yuna가 함께한 캐스퍼 마호니(Caspar Mahoney)의 글 <Moving From a Project to a Product Mindset>을 번역한 글입니다. 필자는 14년 이상 코칭과 멘토링을 통해 사람들의 성장과 변화를 지원해 왔습니다. 그는 고객들이 명확한 방향성을 찾고, 진정한 자신으로서 원하는 삶을 살 수 있도록 돕고 있으며, 이 글에서는 프로젝트 중심 사고방식에서 벗어나 ‘프로덕트 중심 사고방식’을 갖추는 방법과 그 중요성에 대해 설명합니다.

필자에게 허락을 받고 번역했으며, 글에 포함된 링크는 원문에 따라 표시했습니다.

우선 ‘아이언 트라이앵글’에 대해 얘기하겠습니다. 이 개념은 1950년대에 탄생했습니다. 그 긴 역사와 다양한 발전 과정을 모두 설명하진 않겠지만, 전 세계의 프로젝트 관계자들에게는 너무나도 잘 알려져 있고, 그들의 일상에 깊이 스며들어 있는 개념이라고 할 수 있죠. 주로 이해관계자 회의에서 일정 연장을 정당화하거나, 추가 예산을 요청하거나, 범위를 축소해야 할 때 자주 사용됩니다.

시간이 지나면서 이 삼각형에 “품질”이라는 중심점을 추가하는 변형도 생겨났는데요. 이로써 시간, 범위, 비용/예산과 함께 중요한 요소로 자리 잡게 되었습니다.

<출처: Peter Morville>

품질을 추가하는 것은 혁신적인 변화였지만, 이러한 요소 중 어느 것도 우리가 애초에 프로젝트를 진행하는 근본적인 이유를 다루지 않았습니다. 그렇다면, 우리는 왜 프로젝트를 진행할까요?

결국 중요한 건 가치와 혜택

제품의 세계에서는 이것이 단순히 가치로 표현되며, 이는 투자 대비 수익, 매출, 이익, 절감 혹은 이와 유사한 지표로 측정될 수 있습니다. 그래서 저에게는 모든 프로젝트나, 제품 전달의 핵심은 그것을 수행함으로써 얻을 수 있는 가치라고 할 수 있습니다.

현재 전 세계 대부분의 프로젝트 매니저들, 특히 5~10년 전에 교육받은 사람들(즉, 전 세계 대기업에서 일하는 수천 명)은 여전히 그 아이언 트라이앵글의 관점에서 세상을 보고 있습니다. 그렇다면 이것이 실제로 무엇을 의미할까요? 제품 환경일 때 주로 걱정하는 것은 다음과 같습니다.

a) 주어진 시간 내에 일을 완료할 수 있을지

b) 충분한 자원(예산)이 있는지

c) (a)와 (b)에 맞춰 범위가 설정되어 있는지 확인합니다. 범위가 너무 작어서 고민하는 경우는 없을 겁니다. 오히려 범위가 과도한 경우가 더 흔하죠. 물론 이론적으로는 범위가 너무 작을 순 있습니다.

자, 여기서 바로 아이언 트라이앵글이 등장합니다. 프로젝트 매니저들은 이 삼각형이 작동하게 하려고 공식적인 의사결정(스티어링)을 활용해 각 요소의 위치를 조정합니다. 시간이 부족하면 예산을 늘리거나 범위를 줄이거나, 혹은 둘 다 조정합니다. 예산이 부족하면 시간을 늘리거나 범위를 줄이거나, 마찬가지로 둘 다 조정할 수 있습니다.

하지만 이러한 사고방식은 현대적인 제품 개발에서는 문제가 됩니다. 왜냐하면 각 요소를 크게 조정하더라도 가치 또는 혜택을 달성하지 못할 가능성이 매우 크기 때문입니다.

사실 문제는 그보다 더 심각합니다. 이런 방식에서는 실패할 가능성이 매우 높습니다. 주요 이해관계자와 개발팀이 시간, 범위, 예산이라는 제약에 초점을 맞추도록 유도되면, 정작 가장 중요한 요소인 가치 또는 혜택이 우선순위에서 밀려나기 때문입니다.

애자일 이전 시대를 떠올려보세요. 이 문제는 훨씬 더 심각했습니다. IT 프로젝트의 실패율은 매우 높았고, 그 역사는 끔찍할 정도였죠. (자세한 내용은 여기에서 확인할 수 있습니다.) 반면, 혜택(가치)은 제품 방법론의 핵심입니다. 제품 매니저들은 무엇보다도 가치를 발견하고, 이를 전달할 전략을 설계하는 데 가장 많은 시간을 투자합니다.

오해하지 마세요. 제품 담당자들도 리스크, 일정, 범위, 예산을 고려합니다. 하지만 이 모든 요소는 가치에 비하면 부차적인 것들입니다.

예를 들어, 대기업에서 내부 제품 관리를 담당하고 있다고 가정해 봅시다. 주요 고객팀에서 간단한 대화를 빠르게 텍스트로 기록하는 데 문제가 있다며, 이를 해결할 수 있게 도와달라는 요청이 왔습니다. 고객팀은 자신들이 요청한 이 기능이 현재 여러분이 개발 중인 제품에 추가되는 게 가장 적절하다고 생각합니다.

기존의 프로젝트 사고방식에서는 이렇게 접근할 수도 있습니다.

“좋아요, 이 프로젝트는 이미 진행 중이고 1년 동안 운영될 예정이라 예산이 확보되어 있습니다. 지금 우리가 개발 중인 기능에 추가될 새로운 요구사항이군요. 현재 구축 중인 기능들과 연관성이 있어 보이니, 일정 내에 마무리하면서 이 범위를 포함할 수 있을 것 같습니다.”

눈치 빠른 사람들은 이 사고방식이 범위, 시간, 예산이라는 기존의 규칙을 그대로 따르고 있음을 알아챌 겁니다. 이 기준만 충족한다면, 프로젝트 매니저는 이 요청을 승인할 가능성이 높습니다. 만약 백로그 관리 프로세스를 운영하고 있다면, 이 요구사항을 백로그에 추가한 뒤, 기본적으로 이 기능이 최종적으로 개발될 것이라는 가정하에 사양을 작성하기 시작할 것입니다.

반면, 제품 사고방식에서는 이렇게 접근해야 합니다.

이 기능 아이디어가 해결하려는 문제는 무엇인가?
그 문제가 지금 개발 중인 제품과 실제로 연관이 있는가?
더 빠르거나 더 효율적인 해결 방법은 없는가?
지금 당장 해결해야 할 가장 가치 있는 문제인가?
이 문제의 해결이 현재 또는 미래 전략과 일치하는가? 만약 그렇지 않다면, 전략을 수정하거나 업데이트해야 하는가?

위 질문에 대한 답이 명확해지기 전까지는, 제품 사고방식에서는 세부 사항(일정, 리소스/비용, 기술적 타당성, 기능 구현 방식 등) 논의로 넘어가지 않습니다. 하지만 이것도 사실 지나치게 단순화된 설명입니다. 그 이유는 다음에서 살펴보겠습니다.

발견 과정의 리더십

<출처: Unsplash, NEW DATA SERVICES>

프로젝트 매니저는 아이디어의 조율자입니다. 보통 그들이 아이디어 영역에서 담당하는 역할은 여기까지입니다. 전통적인 프로젝트 전달 방식에서는 비즈니스 요구사항 수집을 통해 이를 수행하며, 이 과정에서 대규모의 사전 문서화가 이루어집니다.

반면, 현대적인 프로젝트 전달 방식에서는 애자일 방법론을 적용하여 요구사항을 반복적으로 분석하고, 더 자주 검토합니다. 그러나 프로젝트 매니저가 활동하는 모든 방식(워터폴이든 애자일이든)에서 변하지 않는 핵심은 그들이 우선적으로 조율자이며 플래너라는 점입니다. 따라서 프로젝트 매니저가 해당 도메인에 대한 깊은 전문 지식을 갖추어야 한다는 기대는 상대적으로 낮습니다.

여기서 말하는 도메인이란, 반드시 기술적인 것을 의미하는 것은 아닙니다. 대부분의 경우 비즈니스 도메인을 의미합니다. (다만, 일부 상황에서는 기술 도메인과 비즈니스 도메인이 모두 중요한 경우도 있습니다.)

반면, 제품 관리에서 제품 매니저(PM)는 도메인 전문가입니다. 만약 신입이거나 훈련 중인 경우라면, 도메인 전문가가 되기 위한 과정을 거치고 있을 것입니다. 따라서 제품 매니저는 발견 과정에서 리더십을 발휘합니다. 그리고 제품 매니저가 주도하는 발견은 단순한 요구사항 수집과는 완전히 다른 차원의 작업입니다. 요구사항 수집이란, 보통 비즈니스 분석가가 이해관계자들과 대화를 나누며 어떤 기능이 필요한지 묻고, 이를 문서화하는 과정입니다.

요구사항이 정리되면, 프로젝트 매니저는 머릿속에서 아이언 트라이앵글을 떠올리며 무엇을 포함할 수 있고, 무엇을 제외해야 하는지 계산합니다. 그리고 이를 경영진에게 업데이트로 보고합니다.

그렇다면, 만약 프로젝트 매니저가 요구사항을 명확하게 파악하지 못하거나, 요구사항과 프로젝트 범위가 충돌하는 상황이 발생하면 어떻게 할까요? 그들은 경영진에 상황을 보고하며, 비즈니스 SME(특정 분야 전문가)나 비즈니스 리더의 지원이 필요하다고 보고합니다. 또는 해당 전문가들이 프로젝트에 더 많은 시간을 할애해야 한다고 요청하겠죠.

그러나 제품 관리에서 진행되는 발견 과정은 이와는 완전히 다른 사고방식을 필요로 합니다. 이 과정에서는 제품 매니저의 도메인 지식이 핵심 역할을 합니다. 그렇다면 제품 매니저는 요구사항이 명확하지 않을 때 어떻게 대응할까요? 제품 매니저는 자신의 기술, 역량, 그리고 도구를 활용해 이러한 상황을 해결합니다. 때로는 자신의 지식을 바탕으로 모호한 부분을 메우기도 하지만, 그와 동시에 이러한 가정을 엄격히 검증하는 과정을 거칩니다.

제품 매니저는 문제의 본질을 파악하기 위해 정성적 또는 정량적 연구를 포함한 1차 연구를 직접 수행할 수도 있습니다. 또한 UX 디자이너와 엔지니어와 함께 화이트보드 앞에서 브레인스토밍 세션을 진행하며 새로운 아이디어를 도출한 뒤, 가정이나 가설을 테스트하며 이를 검증하기도 합니다.

그렇다면 제품 매니저가 명확하지 않은 요구사항을 가지고 경영진이나 상위 리더들에게 보고할까요? 그렇지 않습니다. 제품 매니저는 이러한 문제를 해결하는 방법을 알고 있으며, 독립적으로 이를 해결하는 역할을 합니다. 하지만 명확하지 않은 전략이나 불확실한 결과에 대해서는 상위 리더들과 논의합니다. 이 과정에서 개방적인 토론과 소프트 스킬을 활용하며, 철저한 데이터를 바탕으로 설득력을 높입니다. 그러나 요구사항과 같은 세부적인 사항들은 자주 보고하지 않습니다. 제품 매니저는 상위 리더의 개입 없이도 이러한 문제를 자체적으로 해결할 역량을 갖추고 있기 때문입니다.

발견은 완전히 창의적이고 혁신적인 과정입니다. 이는 새로운 환경에서의 탐구와 연구 중심의 접근 방식을 포함하며, 고차원적인 이해관계자 관리 역량, 사용자 조사, UX에 대한 깊은 이해가 요구됩니다.

제품 매니저는 발견 과정에 단순히 참여하거나, 이를 조율하는 역할에 그치지 않습니다. 그들은 이 과정을 주도하며, 발견을 이끄는 핵심 리더입니다. 제품 매니저는 고객이나 사용자와의 직접적인 소통을 비즈니스 분석가에게 전적으로 맡기지 않습니다. 비즈니스 분석가는 일부 지원할 수 있지만, 주로 행정적인 보조 역할에 가깝습니다.

사실 많은 제품 조직에서는 비즈니스 분석가를 활용하는 것이 바람직하지 않다고 여깁니다. 대신 제품 매니저, UX 디자이너, 엔지니어가 직접 최종 사용자와 소통하며, 비즈니스 분석가가 제공할 수 있는 정보를 대체하는 방식으로 접근합니다. 이처럼 제품 매니저에게 기대되는 리더십은 단순한 조율을 넘어섭니다. 제품 전문가는 다양한 역량을 갖추어야 하며, 사용자 참여, 연구, 아이디어 도출, 문제 분석에서 독립적으로 행동할 자신감을 보여주어야 합니다.

받아들이는 자세에서 만들어내는 자세로

<출처: Unsplash, Yannik Mika>

제품 관리에 처음 입문한 사람들과 프로젝트 배경이 있는 사람들은 큰 그림을 보기보다는 세부 사항에 더 집중하는 경향이 있습니다. 또한 프로젝트 중심의 사람들은 전략을 화이트보드에 그리거나, 비전을 구체적으로 설명하는 것보다 엑셀 스프레드시트를 다루는 데 더 익숙하죠.

이러한 경향은 그들이 상사나 고위 이해관계자들에게 “우리가 무엇을 해야 할까요?”와 같은 형태의 질문을 자주 하는 모습으로 나타납니다. 그리고 그 답을 얻으면, 이를 Jira, Excel, Confluence 같은 도구를 사용해 세부 계획으로 전환합니다. 사실 이들은 계획을 최대한 빨리 작성하고 싶어 합니다. 왜냐하면 계획이 세워지면 무엇이 진행 중인지, 누가 무엇을 해야 하는지 명확해져 불확실성이 줄어들고, 그만큼 자신감이 생기기 때문이죠.

하지만 능숙한 제품 매니저는 “우리가 무엇을 해야 할까요?”라는 질문을 주로 하지 않습니다. 대신 그들은 고위 이해관계자들에게 “우리는 이걸 해야 합니다”, 또는 최소한 “다음과 같은 옵션들이 있습니다”라고 말하죠. 그리고 이러한 결론을 내리기 전에 반드시 질문과 연구를 통해 세 가지를 먼저 이해합니다.

이 제품이 어떤 가치를 더할 수 있는가?
이 제품이 해결하는 문제는 무엇인가?
이 제품이 바꾸는 사용자의 행동은 무엇인가?

따라서 제품 관리 분야로 전환하기 위해서는 시야를 넓히고, 아이디어를 발견하며, 통찰력 있는 정보를 찾아 이를 실질적인 실행 계획으로 만들어낼 수 있는 자신감이 필요합니다. 다시 말해, ROI를 정의하고 비즈니스 케이스를 만드는 것이 일상적인 업무가 되어, 더 이상 ‘비즈니스 케이스’라는 별도의 문서를 작성할 필요 없이 지표와 데이터, 인사이트를 통해 자연스럽게 업무에 녹여낼 수 있어야 합니다. 제품 관리자가 되려면, 모든 것이 준비되어 있을 거라는 기대는 버려야 합니다.

차려진 상은 없습니다. 여러분이 직접 상을 차리고, 그 위에 다른 사람들이 활용할 수 있는 것들을 올려놓아야 합니다.

요약하자면, 뛰어난 제품 관리자가 되기 위해서는 다음 세 가지 핵심적인 사고방식의 전환이 필요합니다.

가치를 최우선으로 생각해야 합니다. 시간, 예산, 범위는 그다음이죠. 가치를 이해하는 게 먼저입니다.
도메인에 대한 자신감을 가지고 탐색합니다. 조율도 하지만, 그것만 하는 데 그치지 않습니다. 도메인 전문성을 제한받는다면 답답할 정도로 전문가가 되어야 합니다.
아이디어와 전략, 비전을 만들어 냅니다. 다른 사람의 의견을 듣고 정리만 하는 게 아닙니다. 웨이터처럼 주문을 받거나, 아이디어를 담는 우편함이 되어선 안 됩니다. 대신 모호하게 표현되거나, 정리되지 않은 것들을 구체적인 형태로 만들어내는 능력이 탁월해야 합니다.

이번 글을 통해 프로젝트 중심 사고에서 벗어나, 가치 중심의 제품 마인드셋으로 전환하는 것에 대해 고려해 볼 수 있길 바랍니다.

<원문>

Moving From a Project to a Product Mindset

]]>

왜 잘나가는 기업은 ‘인터널 브랜딩’부터 챙길까?

혹시 온라인에 돌아다니던 이 사진 본 적 있으신가요?

<출처: 배달의민족 공식 페이스북>

바로 ‘배달의민족’을 운영하는 ‘우아한형제들’의 첫 사옥에 붙어있던 포스터입니다. 지금이야 엄청난 규모의 기업으로 성장했지만, 저 포스터가 화제가 될 당시(약 10년 전)만 해도 우아한형제들은 사내에서 다양한 제도와 문화가 활발히 실험되고 있던 시기였죠. 그리고 조직관리 분야에선 이를 ‘인큐베이팅(incubating)’ 기간이라고 부릅니다.

잘 아시다시피 우아한형제들은 자유분방함과 키치함을 떠올리게 하는 브랜딩, 마케팅으로 오늘날에 이르게 되었다고 해도 과언이 아닙니다. 포스터 내용을 하나하나 살펴보면, 회사와 구성원 간의 중요한 약속들마저도 정말 우아한형제들답게 전달하고 있다는 것을 알 수 있습니다. 돌려 말하지 않는 직설적인 화법, Key Message만을 남기는 간결한 문장, 그 안에서도 적절한 유머를 잊지 않는 유쾌함까지. 누가 봐도 우아한형제들의 화법과 언어라는 것을 확인할 수 있으니 말이죠.

진짜 브랜딩은 우리 안에서부터

그런데 이 메시지가 외부 고객들을 위한 것이 아니라, 회사 내부의 구성원들을 위한 것이라는데 주목할 필요가 있습니다. 모름지기 브랜딩이란 우리 브랜드를 알리고, 많은 사람들을 우리 브랜드의 팬으로 만들기 위한 활동인데, 그 화살표가 내부를 향하고 있다는 게 다소 낯선 지점이기도 하죠.

이렇게 회사 조직의 문화, 제도, 인재상과 경영방식에 이르기까지 회사 내부를 브랜딩하는 일련의 행동을 바로 ‘인터널 브랜딩(internal branding)’이라고 부릅니다. 좋은 브랜딩 활동을 위해 혹은 기업의 문화나 제도 자체를 더 나은 방향으로 설계하기 위해, 회사 내부에서부터 명확한 브랜드 DNA를 갖도록 하는 것이 바로 인터널 브랜딩이죠.

하지만 브랜딩에 관심이 많은 분들이라도 이 인터널 브랜딩에 대해서는 조금 생소하거나, 혹은 대략적인 느낌만 아는 분이 많으실 겁니다. 꽤 큰 규모를 갖추고 있음에도 인터널 브랜딩 자체를 하지 않는 기업이나 조직이 여전히 많고, 설사 인터널 브랜딩을 한다고 하더라도 그 개념과 목표를 제대로 정립하고 실행하는 곳을 찾기가 쉽지 않기 때문입니다.

하지만 브랜딩의 출발점은 언제나 브랜드를 만들어가는 사람들로부터 시작되는 만큼, 이 인터널 브랜딩의 중요성은 나날이 커지고 있습니다. 미국 온라인 매체 애드위크(Adweek)의 조사에 따르면, 미국 500대 기업 안에서 사용되는 인터널 브랜딩 관련 예산이 10년 전보다 약 38%가 증가했고, 20년 전에 비해 무려 85%가 증가했다고 합니다.

이번 글에서는 앞으로 더욱 중요해질 것으로 보이는 ‘인터널 브랜딩’에 대해 알아보고, 이를 둘러싼 몇 가지 오해들도 해소해 보고자 합니다. 더욱 생생하고 진솔한 이야기를 위해 스스로 묻고 답하는 Q&A 방식으로 글을 풀어나가 보겠습니다.

Q. 인터널 브랜딩은 담당자가 따로 있나요?

인터널 브랜딩에 대해 소개하고 나면, 곧장 돌아오는 질문이 “인터널 브랜딩은 담당자가 따로 있나요? 또는 별도로 전담하는 조직이 있나요?”라는 질문입니다. 브랜딩 분야도 점점 그 역할에 따라 조직과 직무가 세분화되는 만큼, 인터널 브랜딩에도 스페셜리티를 가진 전문가, 전문 조직이 있는지부터 궁금해지는 것이죠.

속 시원한 대답은 아니겠지만, 이건 조직의 규모와 상황에 따라 형태가 다양하게 구분됩니다. 규모가 큰 대기업은 HR 조직에서 직접 인터널 브랜딩까지 챙기는 케이스가 많지만, 또 일부는 회사 내부의 마케팅 조직에서 그 역할을 함께 수행하기도 합니다. 이는 인터널 브랜딩을 조직 문화 차원에서 볼 것인지, 브랜딩(혹은 마케팅) DNA의 강화 차원에서 볼 것인지에 따라 무게 중심이 이동하기 때문입니다.

<출처: unsplash>

다만 적어도 후자의 입장으로 접근한다면 가급적 사내에서 브랜딩을 담당하는 조직이 이 인터널 브랜딩의 역할까지 품는 것이 가장 이상적입니다. 사실 제품이나 서비스라는 게 결국은 그걸 만드는 사람들을 투영한 결과물임을 여러분도 알고 계실 텐데요. 그렇다 보니 그 브랜드의 핵심 가치와 페르소나를 제일 잘 이해하고 있는 브랜드 담당자가 내부의 브랜딩 DNA도 가장 잘 설계할 수 있는 거죠. 또한 내부를 위한 인터널(internal) 브랜딩과 외부를 위한 익스터널(external) 브랜딩이 한곳에서 이뤄지면, 브랜딩 활동을 위한 자산들도 훨씬 효율적으로 관리할 수 있습니다.

혹시 “저는 제품 브랜딩만 담당해도 너무 벅차서 내부 브랜딩까지 신경 쓰긴 힘들어요.”라고 하는 분들은 HR이나 마케팅 조직의 도움을 얻어, 각자가 할 수 있는 역할을 분리하는 것도 대안이 될 수 있습니다. 다만 인터널 브랜딩의 상위 컨셉 만큼은 꼭 내부 브랜딩 담당자의 손을 거치는 것이 좋습니다. ‘우리 브랜드가 좋은 브랜드가 되기 위해서는 우리가 어떤 사람들이 되어야 하는가?’에 대한 고민을 가장 본질적으로 할 수 있는 사람들이니까요.

Q. 그런데 인터널 브랜딩은 언제 하는 건가요?

자주 받는 질문 중 또 다른 하나가 바로 이겁니다. “그럼 인터널 브랜딩은 언제 하는 건가요? 브랜드가 만들어지는 과정에서 해야 하나요? 아니면 브랜드가 론칭된 후에 하는 건가요?”라는 질문입니다. 이 질문엔 비교적 명확한 답을 해드릴 수 있을 것 같네요. 바로 “인터널 브랜딩은 항상 진행되고 있어야 한다”라고 말입니다.

사실 인터널 브랜딩은 결과에 따라 대처하듯이 하려면 이미 그 타이밍을 놓치는 경우가 많습니다. 따라서 담당자가 먼저 니즈를 파악하고, 선제적으로 진행하는 것이 좋습니다. 브랜딩이라는 게 인식을 선점하는 게임이란 걸 떠올려본다면, 인터널 브랜딩 역시 다를 바가 없는 것이죠.

회사에 다니다 보면 주변 동료들과 이런 이야기를 주고받았던 기억이 한 번쯤은 있을 겁니다. “작년까지만 해도 회사 분위기가 이렇진 않았는데, 올해는 정말 별로인 것 같아”라거나, “그 사람이 담당자로 있을 때는 이런 경우가 없었는데 요즘은 일이 이상하게 진행되는 것 같아”라는 말들이요. 그런데 실제로 회사 분위기가 부정적으로 흘러가는 요인을 파악하면, 그 요인을 꼭 한 가지로 규정할 수 없는 경우가 굉장히 많습니다. 다시 말해 회사 내부의 여러 상황이 맞물려 일어나는 일임에도, 사람들은 그 이유를 하나의 요소나 특정인으로부터 찾는 사태가 벌어지는 것이죠.

그 때문에 뭔가 상황이 벌어지고, 그 요인이 이미 엉뚱한 곳을 향하고 있을 때 이를 바로잡으려고 부랴부랴 인터널 브랜딩을 해보려고 하면, 효과가 현저히 떨어질 수밖에 없습니다. 오히려 우리 조직, 우리 회사가 가고자 하는 방향이 무엇이고, 현재 우리는 그 방향으로 잘 걸어가고 있는지를 체크한 다음 이에 필요한 활동들을 먼저 제안하는 것이 훨씬 유리하죠.

따라서 인터널 브랜딩에 관여하고 있는 사람이라면, “나는 좋은 가치를 끊임없이 먼저 선보이는 사람이다”라는 생각으로 늘 레이더를 켜두는 것이 좋습니다. 인터널 브랜딩이 ‘올 타임(all-time) 브랜딩’이란 별명을 가진 것도 바로 이 이유 때문이니까요.

Q. 인터널 브랜딩을 꼭 해야만 할까요? 다른 중요한 것들이 차고 넘치는데도요?

앞서 한 이야기의 연장선에서 한번 생각해 보죠. 우아한형제들은 왜 그렇게 인터널 브랜딩을 중요하게 생각했을까요? 분명 그때는 자금도 넉넉지 않은 작은 스타트업이었고, 하루가 다르게 쏟아지는 경쟁자들 속에서 자기방어를 하는데 더 열을 올려도 시원찮았을 텐데 말이죠.

그건 바로 내부에서부터 시작된 브랜딩이 자신들의 상품, 서비스, 고객 커뮤니케이션뿐 아니라 크게는 브랜드 세계관에도 영향을 미친다는 사실을 누구보다 잘 알고 있었기 때문입니다. 이는 바꿔 말하면 회사 구성원 모두를 브랜드에 관여하는 사람들로 만들고자 하는 노력이기도 한 것이죠.

책 ⟪브랜드는 어떻게 아이콘이 되는가⟫의 저자이자 코카콜라, 마이크로소프트, 벤앤제리스 등의 수석 컨설턴트이기도 한 더글라스 홀트(Douglas B. Holt) 교수는 인터널 브랜딩과 관련해 이런 말을 남겼습니다.

“만약 내가 10만 달러의 예산을 가진 어느 스타트업의 브랜드 담당자라면, 나는 그 돈 전부를 인터널 브랜딩에 쓰겠습니다. 그렇게 뿌리내린 브랜딩 문화는 결국 시간이 지나 1억 달러의 가치를 지닌 브랜드를 탄생시킬 테니 말입니다.”

이런 말이 과장이 아닌 이유는 좋은 브랜드를 만드는 곳에는 언제나 본인과 그 브랜드를 동일시하는 사람들이 있기 때문입니다. 그런 사람들이 많으면 많을수록, 브랜드는 훨씬 단단하고 매력적인 브랜딩 활동들을 펼칠 수 있죠. 그들은 스스로 브랜드가 되기로 결심한 사람들인 만큼, 그 어떤 브랜드 자산보다 강력한 힘을 발휘하니까요.

더불어 인터널 브랜딩이 잘 이뤄지는 회사는 유능한 인재를 영입하는데도 매우 유리합니다. 요즘은 각종 커뮤니티, SNS를 통해서 내부 브랜딩 활동들이 외부로 바이럴 되는 경우를 어렵지 않게 볼 수 있는데요. 물론 이런 노력들이 일하는 방식이나, 조직 문화에 대한 홍보 효과를 발생시키는 것도 맞지만 사실 진짜 장점은 따로 있습니다. 바로 인터널 브랜딩을 통해 우리 회사, 우리 브랜드의 인재상이 자연스럽게 구축된다는 사실이죠.

내부적으로 브랜딩 활동이 활발하게 이뤄지는 조직은 채용담당자는 물론이고, 회사의 각 구성원들이 ‘아, 저 사람은 우리 회사와 잘 맞겠다’, ‘저 사람은 우리 브랜드를 만들어가는 데는 어울리지 않는 캐릭터겠다’라는 것을 미리 가늠하고, 판단할 수 있는 공통된 기준을 가질 수 있습니다.

이미 인터널 브랜딩을 통해서 우리가 누구인지, 무엇을 하는 사람들인지에 대한 이유와 기준이 명확한 상태기 때문이죠. 이를 바탕으로 새로운 사람이 우리에게 어떤 영향을 줄 수 있는지 역시 판단하기 쉬워집니다. 그러니 인터널 브랜딩은 그 영향력이 무궁무진하다고 해도 결코 과언이 아닙니다.

<출처: unsplash>

Q. 인터널 브랜딩, 어떻게 시작해야 할까요?

우리가 일을 할 때 제일 많은 시간과 에너지를 할애하는 부분이 어디일까요? 직군에 따라 차이는 있겠지만, 대다수가 아마도 ‘커뮤니케이션’을 꼽을 겁니다. 조금 과장해서 이야기해 보면 우리는 커뮤니케이션을 위해 출근한다고 해도 무방할 정도죠. 그리고 이 커뮤니케이션에는 각자에게 맞는 여러 도구가 있지만, 그중에서도 말과 글이 핵심이 되는 것은 누구도 부정할 수 없습니다.

인터널 브랜딩은 다른 무엇보다 업무의 상당 부분을 차지하는 커뮤니케이션 문화를 브랜딩하는 역할이 큽니다. 즉, 우리가 좋은 브랜드, 좋은 조직, 좋은 회사를 만들기 위해 어떻게 쓰고 말할 것인가를 구체화해 가는 역할이라고 볼 수 있죠. 여러분 역시 누군가와 친해지면 그 사람과의 커뮤니케이션 방식에 큰 영향을 받을 겁니다. 그렇게 여러 사람이 모이면 작게나마 하나의 문화가 만들어지고, 어떤 형태로든 힘을 갖고 또 다른 누군가에게 영향을 줄 수밖에 없죠.

따라서 인터널 브랜딩은 거창하게 생각하기보다, 신속하고 가벼운 것들부터 시작해 보는 게 좋습니다. 한 줄 문구를 프린트해서 사람들이 오가는 복도 한 벽면에 붙일 수도 있고, 사내에서 쓰는 업무 툴에 올리는 공지문 혹은 올핸즈 미팅이나 타운홀 미팅 같은 전체 회의 때 전달되는 발표 포맷부터 고쳐볼 수도 있는 거죠.

심지어 식당이나 휴게공간 등에 놓이는 간단한 안내문부터, 우리만의 정서를 담은 커뮤니케이션을 시도할 수 있다는 게 인터널 브랜딩의 가장 큰 장점이자 매력이니까요.

독서 모임이라는 아주 오래된 활동을 브랜드 차원으로 끌어올린 ‘트레바리’는 이 지점을 잘 활용할 줄 아는 서비스입니다. 트레바리가 운영하는 모임 공간인 ‘아지트’를 방문해 보면, 공간 곳곳에 그들의 문화이자 커뮤니케이션 방식을 소개하는 글귀가 붙어있습니다.

“우리는 독백이 아닌 대화를 위해 이 자리에 모였습니다.”
“좋은 대화는 잘 설득하는 사람이 아닌 잘 설득당하는 사람이 만듭니다.”
“우리는 무엇이든 말할 수 있지만, 아무렇게나 말할 수는 없습니다.”

<출처: 트레바리 공식 홈페이지>

이렇게 간단한 텍스트만으로도 본인들이 추구하는 독서토론 방식과 커뮤니케이션 문화를 전달할 수 있습니다. 이를 통해 내부 직원부터 그 공간을 이용하는 사람들까지, 어떤 태도로 소통해야 하는지 다시 생각해 보게 만드는 효과가 있습니다.

한편으로는 매달 발송되는 안내 메일처럼 직원, 관계자들이 정기적 또는 의무적으로 봐야 하는 콘텐츠에 좋은 인식을 유도하는 문구를 삽입하는 방법도 있습니다. 이미지나 영상이 주는 파급력도 있지만, 적절하게 잘 쓰인 말과 글 한 줄이 긍정적인 결과를 가져오기도 하는 법이니까요. 여러분의 브랜드와 조직에 맞는 방법을 잘 고민해 본다면, 분명히 금쪽같은 기회를 발견할 거라고 믿습니다.

좋은 영향을 만들어낼 수 있다는 믿음

살다 보면 의외로 가장 가까운 사람들, 가장 오래된 사람들을 설득하는 게 더 어려운 일이라는 것을 깨닫게 됩니다. 친하면 친할수록, 잘 알면 알수록 새로운 생각과 관점을 심어주는 게 쉽지 않기 때문이죠. 그럼에도 불구하고 내 주변부터 잘 설득하고 이해시킬 수 있으면, 그들로부터 얻는 힘은 우리가 예상하는 것보다 훨씬 큽니다. 외부에 존재하는 다른 대상들만 부러워할 게 아니라, 우선 내부적으로부터 해볼 수 있는 것들을 챙겨야 하는 이유 역시 바로 여기에 있죠.

그러니 인터널 브랜딩을 진짜 제대로 정착시키기 위해서는 어느 정도의 믿음이 필요합니다. ‘우리 회사는 당장 저런 걸 적용하기가 어려울 것 같은데…’라거나, ‘이렇게 하자고 해도 위에서 절대 허락 안 해줄 것 같은데’라는 부정적인 생각은 잠시 접어두세요. 우선 여러분이 회사의 총책임자라는 생각으로, 큰 시야를 가질수록 좋습니다.

그런 다음 실제로 바꿔 갈 수 있는 부분, 빠르게 적용해 볼 수 있는 부분들을 훑어나가면 그 해결책이 생각보다 쉽게 발견되기도 하거든요. 우리의 방향과 노력을 지지하는 아군들도 점차 늘어나기 마련이고요. 어쩌면 인터널 브랜딩에 관한 오해 중 가장 큰 오해는 ‘나 아닌 누군가가 하겠지’, ‘지금 아니어도 언젠가 할 기회가 있겠지’, ‘이런 작은 것은 큰 도움이 되지 않겠지’와 같은 단념일지도 모릅니다.

이런 부정적인 생각에서 벗어나, 당장 실천해 볼 수 있는 것들을 빠르게 찾아보는 그 순간부터 인터널 브랜딩의 역사가 시작되는 것일 테니 말입니다.

]]>

초개인화 승부수 띄운 ‘네이버플러스 스토어’ 전략 통할까?

지난 3월 12일, 네이버는 ‘네이버플러스 스토어’(이하 네이버+ 스토어)를 새롭게 출시했다. “초개인화 쇼핑 경험”이라는 슬로건에서 알 수 있듯, 기존과 다른 AI 기반의 차세대 쇼핑을 지향하고 있다. 가장 큰 특징은 목적형 쇼핑을 중심으로 검색 비중이 높은 쿠팡과 달리, 네이버는 ‘추천’ 영역을 대폭 확대하고 ‘발견’이라는 새로운 코너를 신설하여, 자연스럽게 상품을 탐색하는 경험을 강화했다는 점이다.

이번 글에서는 새롭게 선보인 네이버+ 스토어를 직접 이용해 보며, 서비스의 주요 특징과 개선점 등을 살펴보고자 한다.

<출처: 네이버플러스 스토어, 작가 캡처>

달라진 쇼핑 경험, 네이버+ 스토어의 특징

기존의 쇼핑 앱은 대부분 검색창을 헤더 영역에 크게 배치하고, 광고 키워드를 노출해 브랜드나 상품을 홍보하는 방식을 사용해왔다. 그러나 ‘네이버+ 스토어’는 과감히 검색창을 아이콘으로 축소해, 개인화 추천과 발견 중심의 쇼핑 경험을 강조하고 있다. 검색에 대한 부분은 이후 방향을 정하면서 차츰 보강해 나갈 것으로 예상된다.

또한 UX/UI 측면에서도 “초개인화”를 바탕으로 사용자가 더 오랜 시간 머물며 탐색할 수 있도록 했다. 이제 구체적으로 어떤 점이 달라졌는지 살펴보자.

1) 쇼핑에 최적화된 알림과 혜택

언뜻 보면 기존과 유사해 보이지만 네이버와 분리됨으로써 쇼핑에 최적화하려는 노력이 보인다. 헤더 부분에는 쇼핑 전용 알림 아이콘이 놓였고, 이슈 키워드(구, 인기 키워드) 대신 단골 스토어 쿠폰을 눈에 띄게 하여, 맞춤 혜택을 강화한 것을 알 수 있다.

네이버+ 스토어 전과 후 메인 <출처: 작가 편집>

2) 숏폼으로 발견형 쇼핑 경험 강화

발견 코너로 큐레이션 된 숏폼 콘텐츠를 제공한다. 고객 행동 기반 알고리즘에 맞춰, 구매 욕구를 자극하는 상품을 자연스럽게 탐색하도록 구성했다. 네이버만의 장점인 콘텐츠를 연계하여 브랜드와 상품을 소개하고 있다.

네이버+ 스토어 발견 메뉴 <출처: 작가 편집>

3) AI 맞춤 추천 알고리즘 고도화

추천 영역을 홈, 오늘행사, FOUR YOU, 베스트, N 배송 주요 탭을 살펴보았을 때 신규 모듈은 딱히 없었다. 기존에 있던 추천 모듈인 고객행동 기반 추천, CLOVA MD, AiTEMS 등을 활용해서 내부 로직을 탄탄히 하고 콘텐츠를 더욱 다양하게 고객에게 보여주고 있다.

새로워진 곳은 아래 그림에서 볼 수 있듯이, 마이 쇼핑에 맞춤 정보 등록하는 부분이 매우 섬세해진 것을 알 수 있다.

네이버+ 스토어 추천 관련 화면 <출처: 작가 편집>

그리고 카테고리 탐색 부분에서는 ‘관심있는’ 카테고리를 제안한다.

네이버+ 스토어 카테고리 부분 전과 후 <출처: 작가 편집>

추천 영역에서 아쉬운 점은 로딩 속도가 느린 부분이다. 또한 알고리즘 정확도는 개선이 필요해 보인다. 아래 그림에서 볼 수 있듯이 카테고리 선택 시 클릭한, 구매한, 장바구니 담은, 찜한 부분의 로딩 속도가 느렸고, 평소 술을 마시지 않는데 안주를 추천했다.

네이버+ 스토어 추천 영역 <출처: 작가 편집>

4) N 배송 강조

또한 배송을 강화하고자 도착 보장은 ‘N 배송’으로 네이밍을 변경했다. 그리고 멤버십 10% 슈퍼 적립 회원 전용 할인 및 만 원 이상 구매 시 무료배송 반품 N 배송 혜택을 제공하고 있다. 3월 17일~30일까지 진행하는 오픈위크에는 앱 설치를 유도하는 앱 전용 혜택과 함께 N 배송 전 상품 무료 배송, 무료 반품 혜택을 제공하고 있다.

N 배송 강조 <출처: 작가 편집>

앞으로 더 개선해야 할 부분은?

‘네이버+ 스토어’를 이용해 보면서 느낀 점은 네이버가 가진 다양한 서비스와의 연계가 아쉬웠다. 일단은 쇼핑하는 데 있어 불편함이 없는 기본 기능에 충실한 것 같다. 앞으로도 개선되었으면 하는 포인트를 함께 짚어 보자.

1) 장보기 UX/UI 개선

장보기는 메인과 카테고리 영역 퀵 메뉴 2번째로 우선순위를 변경했다. 장보기에 우선순위를 부여했다면, 이와 함께 장보기에 최적화된 UX/UI 개선 역시 필요해 보인다. 장보기는 패션, 뷰티와 다르게 검색 비중이 특히 높다. 잘 생각해 보면 고객이 즐겨 먹는 음식에는 일정한 패턴이 있기 때문이다.

그리고 목적성이 강한 장보기는 현란한 빌보드와 띠 배너 광고로 고객의 시선을 사로잡는 것보다, 정확하게 상품 정보를 전달하는 것이 우선시되어야 한다. 특히 페이지별 목적에 맞게 상품 유닛 구성 요소를 정돈하는 것이 필요하다.

예를 들어, 상품 목록에서 사용되는 유닛은 고객이 여러 상품을 둘러보고 쉽게 선택할 수 있게끔 상품 정보를 정확하게 전달한다. 그리고 상품을 선택하는 기준인 가격, 원산지 표기, 냉장/냉동, 소비기한 등 정보를 밝히고, 바로 장바구니에 추가할 수 있는 퀵버튼을 노출하는 것이 도움이 될 것이다.

물론 추천 알고리즘을 고도화하기 위해 ‘찜’을 강조해야 할 필요성도 있지만, 빼빼로를 꼭 찜해야 하거나, 상세를 봐야 정보를 아는 것은 아니다. 누구나 아는 상품이라면, 바로 담을 수 있는 것이 더 편리하다.

(왼) 네이버+ 스토어 장보기 영역 상품 유닛과 (오) 쿠팡 예시 <출처: 작가 편집>

2) 고객 행동 트리거 기반 추천 UX 라이팅

네이버+ 스토어 추천 영역의 타이틀의 경우, 더 친근하면서도 혜택을 제안하는 형태로 구성하면 좋을 것 같다. 현재 장바구니에 상품을 담으면, “함께 구매하기 좋아요”, 주문 완료 시에는 “000과 함께 구매하는 000은 어떠세요?”로 안내하고 있다.

고객이 결제하기 전, 장바구니를 한 번 더 살펴보거나 관심 있을 상품을 마지막에 체크할 수 있도록 UX 라이팅을 고민하면 좋겠다. 정답은 아니지만 쿠팡의 경우, 고객이 장바구니에 담았을 때, 주문 완료 시에 상품을 제시하는 것뿐 아니라, 결제 전에 한 번 더 놓치면 안 될 상품을 제안한다. 이때 자칫 상품 구매를 강요하는 것처럼 보이지 않아야 한다. 그래서 장바구니에 담을 상품을 최종 검토하고, 결제 단계로 진행을 돕는 세심함이 필요하다.

(왼) 네이버+ 스토어 추천 영역 UX 라이팅과 (오) 쿠팡 예시 <출처: 작가 편집>

3) 네이버 커뮤니티와 연계한 쇼핑 알림

현재는 쇼핑 알림에서 알림 받기를 동의한 스토어와 브랜드의 혜택 내용이 전달된다. 앱 푸시는 CRM의 중요한 도구로 결제 전환의 중요한 전략으로 사용할 수 있다. 그래서 단순히 혜택 알림을 넘어, 커뮤니티를 연계하는 방안도 생각해 볼 수 있다.

예를 들어, 토스는 금융 커뮤니티를 연계하여 상품을 공유하거나, 받을 때 포인트를 제공했다. 이처럼 고객 간 공유 및 피드백 루프 경험으로 쇼핑 알림을 보완하면, 고객 충성도가 더욱 높아질 수 있다.

(왼) 네이버+ 스토어 앱 알림 (오) 토스 예시 <출처: 작가 편집>

4) AI 쇼핑 어시스턴트 검색

검색 부분에서는 최근 검색어조차 연동되지 않았던 점이 다소 아쉬웠다. 또한 국내에서도 생성형 AI 기반의 대화형 검색이 쇼핑과 접목될 시점이라 기대했지만, 쇼핑 렌즈와 네이버 CUE 대화형 검색 같은 최신 기술은 반영되지 않았다.

앞으로는 생성형 AI를 활용한 대화형 검색 등 AI 쇼핑 어시스턴트 방식으로 발전하면 더욱 좋을 것 같다. 사용자가 원하는 상품을 자연스럽게 찾고 추천받는 초개인화 경험이 한층 더 강화될 수 있을 것이다.

네이버+ 스토어 검색 <출처: 작가 편집>

네이버+ 스토어가 지향하는 AI 쇼핑이란?

지금까지 달라진 네이버+ 스토어의 특징과 개선점을 살펴보았다. 네이버+ 스토어가 지향하는 초개인화 쇼핑은 결국 사용자가 플랫폼을 자주 이용하면서 데이터가 쌓여야만 정확도가 높아진다. 이를 위해서는 고객의 구체적인 요구사항과 관심사를 파악할 수 있는 장치가 서비스 곳곳에 마련되어야 하는데, 아직은 다소 부족한 느낌을 받았다.

예를 들어, 토스 쇼핑은 표면적으로 포인트 적립과 쇼핑을 연결해 선순환 구조를 탄탄히 구축하면서도, 궁극적으로는 사용자의 자산 현황과 결제 등 금융 데이터를 기반으로 개인화된 추천을 지향한다. 네이버+ 스토어 역시 네이버가 보유한 고유의 데이터와 플랫폼 강점을 적극 활용하여, 고객의 라이프스타일에 밀착한 1:1 맞춤형 상품과 서비스 혜택을 제공하는 플랫폼으로 발전하기를 기대해 본다.

끝으로 이 글을 쓰는 시점에 네이버+ 스토어 앱은 아직 안드로이드 버전만 출시된 상태다. 곧 iOS 버전도 추가될 예정이라고 하니 참고하면 좋겠다. 또한 여러분이 이커머스 기획자라면, 직접 상품을 살펴보고 장바구니에 담거나 찜하고 구매도 해보면서, 사용자의 행동에 따라 실시간 추천 영역이 어떻게 변화하는지 직접 경험해 보면 좋을 것이다.

]]>

더 성장하고 싶은 IT인을 위한 추천 도서 11권

저는 17년 차 PM으로 책을 다독하기보다는 정독하는 편입니다. 그리고 주요 내용을 마인드맵으로 정리한 후, 저만의 관점과 생각을 담아 다시 한번 내용을 정리하는 독서법을 선호합니다. 완독까지는 시간이 꽤 오래 걸리지만, 이렇게 정리한 책은 장기기억으로 잘 안착하며, 이전에 기록했던 노트들과 맥락이 연결될 때는 짜릿한 즐거움도 느낍니다. 좋은 책은 여러 번 반복해 읽기도 하죠.

이번 글에서는 제가 작년에 읽고 정리했던 11권의 책을 소개하고자 합니다. 일을 더 잘하고 싶은, 성장을 꿈꾸는 IT업계 기획자, 실무자들에게 도움이 되길 바랍니다.

“지금 B2C 제품을 만들고 있다면”

제품을 만들 때 B2C 제품과 B2B 제품에서 고민하는 포인트는 크게 다릅니다. B2C 제품의 성패는 고객이 계속해서 찾아오도록 다양한 트리거를 만들어 습관으로 연결시키고, 자연적 바이럴 루프를 만들어 내었을 때 큰 성장으로 이어질 수 있는데 이러한 주요 포인트를 가장 잘 설명한 책이 아래 2권입니다.

훅, 일상을 사로잡는 제품의 비밀(저자: 니르 이얄)

<출처: 작가 편집>

사용자 습관을 형성하는 일에 성공한 기업들은 많은 비용이 드는 마케팅 활동에 의존하지 않는다.

대신 자신들의 제품이나 서비스를 사용자의 일상적인 행동이나 감정과 잘 연결시킨다. 우리가 조금만 심심하면 곧바로 SNS에 접속하는 것도 습관의 위력 때문이라 볼 수 있다. 외롭다고 느끼면 어떤 이성적인 사고가 일어나기도 전에 어느새 SNS에 올라온 새 글 목록을 읽고 있다.

또 한 가지 의문점이 생기면 그것에 대해 생각해 보기도 전에 곧바로 구글 검색창에 입력하기 시작한다. 이렇게 머릿속에 가장 먼저 떠오르는 것이 우리의 일상 행동을 지배하고 있다.

사용자 습관을 바꾸려면 기성 서비스보다 9배 높은 가치를 제공해야 한다. 그래야 습관을 바꾸는 고통을 감수하고서라도 바꾼다. 습관을 가지기 위해서는 '빈도'를 높이거나 확실한 '유용성'을 제공해야 한다.

- 훅, 일상을 사로잡는 제품의 비밀 中

이 책에서는 고객이 우리 제품을 습관적으로 사용하도록 만드는 방법을 4가지 단계로 정리한 ‘훅 모델’을 소개합니다.

콜드 스타트(저자: 앤드루 첸)

<출처: 작가 편집>

<출처: Excalidraw, 작가 편집>

제품이 급속 성장하기 위해서는 고객이 새로운 고객을 불러오는 바이럴 루프가 돌아야 합니다. 이 책은 네트워크 효과에 대해 집중적으로 소개하는데요. 하나의 집단에서 자연적으로 성장하는 성공 방적식을 발견하고, 이러한 성공 방정식을 복사+붙여넣기로 여러 집단으로 확장하며 빠르게 성장하는 과정을 소개합니다.

네트워크 효과로 빠르게 성장한 국내 플랫폼의 긍정적인 사례는 <지역 기반으로 확장한 당근>, <캠퍼스 기반으로 확장한 에브리타임>, <직장인 기반으로 확장한 블라인드>를 생각해 볼 수 있었습니다. 제품 성장이 정체되어 있는 시기에 그로스를 고민하고 있다면 꼭 한 번 읽어봐야 할 책입니다.

“리더십 관점에서 협업과 코칭을 어떻게 잘할 수 있을까 고민할 때”

일의 99%는 피드백이다(저자: 더글러스 스톤, 쉴라 힌)

<출처: 작가 편집>

<출처: Excalidraw, 작가 편집>

피드백은 잘 주는 것도, 잘 받는 것도 어렵습니다. 결국 피드백을 잘하기 위해서는 개개인의 성향과 환경을 이해하고 맞춤형 피드백을 제공할 수 있어야 합니다. 피드백을 어떻게 하면 보다 잘 전달할 수 있을까에 대한 고민이 크다면 이 책을 추천합니다. 책의 분량은 많지만, 일상에서도 조직에서도 생각해 볼 내용들이 가득 담겨있습니다.

이 책과 함께 읽으면 좋은 책들

함께 자라기 - 애자일로 가는 길(저자: 김창준)

<출처: 작가 편집>

<출처: Excalidraw, 작가 편집>

기업에 애자일 조직문화가 필요한 이유와 애자일 조직에서 어떻게 협업을 이끌어낼 수 있을지에 대해 다룬 책입니다. 개발자 사례들이 많지만, 개발자가 아니어도 공감할 수 있는 내용이 많고 쉽게 읽을 수 있는 책입니다. 저는 사내 스터디로 진행했었는데 개발자들과 함께 공부하고 이야기 나누기 좋습니다.

“제품 리더십과 전략적 인사이트가 고민될 때”

어도비 CPO의 혁신전략(저자: 스콧 벨스키)

<출처: 작가 편집>

2006년 디자이너를 위한 포트폴리오 플랫폼 ‘비핸스’를 창업하고 2012년에 어도비에 엑시트, 이후 다른 활동을 하다가 2017년에 어도비 CPO로 합류해 기존의 설치형 제품을 클라우드형 제품으로 전환시키며, 규모가 큰 대기업에서도 성장을 이끌어낸 스콧 벨스키의 책입니다.

이 책에선 스타트업을 경영하며 출구가 보이지 않는 불확실한 감정이 드는 길고 긴 중간 단계를 ‘메시 미들(messy middle)’이라고 정의합니다. 그 과정에서 경영자로서 어떠한 생각들을 마주하게 되는지, 어떻게 대응해야 할지에 대해 꽤 세세하게 기록하고 있습니다. 모든 일의 시작과 끝으로 가는 여정에는 메시 미들이 존재하며 이 과정에서 희망과 좌절이 끊임없이 반복됩니다. 지금 스타트업을 경영하며 피로가 쌓이고 무기력해지고, 판단에 확신이 서지 않는 시기를 보내는 경영자라면 한 번쯤 읽어보기 좋은 책입니다.

Thick data, 빅 데이터도 모르는 인간의 숨은 욕망(저자: 백영재)

<출처: 작가 편집>

<출처: Excalidraw, 작가 편집>

측정할 수 있는 것이 항상 가치 있는 것은 아니다.
소비자는 언제나 진실을 말하지 않는다. 소비자의 말과 행동이 아닌, 수면에 잠긴 맥락을 세밀하게 살펴야 한다.
아직 적히지 않은 페이지를 읽어내는 것이 우리의 일이다. (통찰의 영역)
고객 불만이 없다고 해서 제품이 완벽한 것은 아니다.

좋은 아이디어는 100원에 몇 개라도 살 수 있지만, 이를 실행에 옮기는 사람의 가치는 값을 매길 수 없다.
데이터 분석의 객관성을 담보하는 것은 샘플의 크기가 아니라 그 해석과 인사이트의 깊이다!

- Thick data, 빅 데이터도 모르는 인간의 숨은 욕망 中

데이터 만능주의 시대에서 인류학적 통찰의 중요성을 강조하는 책입니다. 결국 big data와 인간의 본성을 이해하는 thick data가 결합되어야만, smart data 관점에서 올바른 의사결정을 할 수 있다는 핵심 메시지와 인류학적 접근의 중요성을 다양한 사례로 소개합니다.

인스파이어드(저자: 마티 케이건)

<출처: 작가 편집>

우리가 원하는 것은 용병팀이 아닌 미션팀이다.

용병팀은 지시한 것만을 만든다. 미션팀은 진심으로 비전을 믿고 그들의 고객 문제 해결을 위해 최선을 다한다. 제품 전담팀은 마치 사내 스타트업처럼 행동하고 느낀다. 그것이 제품팀에 바라는 모습이다.

충분한 권한을 가졌다고 느끼면서 고객 문제를 해결하기 위한 열정으로 뭉친 팀을 원한다면 그들에게 높은 수준의 자율성을 제공해야 한다. 딴짓을 할 수 있다거나 재미있어 보이는 일만 한다는 뜻이 아니다. 팀이 판단하기에 주어진 문제를 해결하는 데 가장 적절하다고 발견한 최고의 방법을 시도해 볼 수 있다는 의미다.

정말 솔직한 이야기로, 회사에서 가장 뛰어난 사람이 제품 관리자가 되어야 한다. 제품 관리자가 기술에 대한 기본적인 소양이 없고, 사업에 대한 지식도 없고, 핵심 임원들로부터 신뢰받지 못하며, 제품에 대한 열정이 없고, 제품팀으로부터 존중받지 못한다면 분명히 실패하고 만다.

- 인스파이어드 中

예전에 읽었던 책이지만 ‘피기팟 PM 스터디’에서 다시 읽은 책입니다. 시장에서 원하는 제품 관리자(PO, PM)의 자질과 기준을 명확하게 알 수 있습니다.

제로 투 원(저자: 피터 틸, 블레이크 매스터스)

<출처: 작가 편집>

비즈니스의 세계에서 모는 순간은 단 한 번밖에 일어나지 않는다. 앞으로 그 누구도 컴퓨터 운영체제를 만들어서 제2의 빌 게이츠가 될 수는 없다. 검색엔진을 만들어서 제2의 래리 페이지나 세르게이 브린이 될 수도 없으며, 또다시 소셜 네트워크를 만들어 제2의 마크 저커버그가 될 수도 없다. 이들을 그대로 베끼려는 사람이 있다면 정작 이들로부터 아무것도 배우지 못한 것이다.

물론 새로운 것을 만드는 것보다는 기존의 모형을 모방하는 게 더 쉽다. 하지만 어떻게 하면 되는지 사람들이 이미 알고 있는 일을 다시 해봤자 세상은 1에서 n이 될 뿐이다. 익숙한 것이 하나 더 늘어날 뿐이라는 말이다. 그러나 뭔가 새로운 것을 창조하면 세상은 0에서 1이 된다. 창조라는 행위는 단 한 번뿐이며, 창조의 순간도 단 한 번뿐이다.

- 제로 투 원 中

스타트업 씬에 있다면 누구나 들어보고 읽어봤을 스테디셀러입니다. 저도 다시 읽고 싶어서 또 한 번 읽어봤는데요. 유에서 유를 창조하는 1에서 n이 아닌, 0에서 1을 창조하는 제로 투 원의 가치에 대해 설명합니다. 현재는 생성형 AI가 새로운 시대의 넥스트 제로 투 원이겠네요.

“개인의 성장에 관심이 많다면”

그릿(저자: 앤절라 더크워스)

<출처: 작가 편집>

아웃라이어에게는 세 가지 두드러진 특성이 있다. 그들은 비범한 재능과 함께 남다른 열의와 열심히 일할 능력(노력)을 지니고 있다.
성취 = 재능*노력2

내가 제대로 계산했다면 재능은 두 배로 갖고 있지만 노력은 절반만 하는 사람은 보통 사람과 같은 기술 수준에 도달할 것이다. 그리고 시간이 지나면서 내놓는 결과물은 훨씬 작을 것이다.

의식적인 연습을 하지 않기 때문에 발전이 없는 거예요.
의식적인 연습을 100퍼센트 활용하는 법

명료하게 진술된 도전적 목표 → 완벽한 집중과 노력 → 즉각적이고 유용한 피드백 → 반성과 개선을 동반한 끊임없는 반복

- 그릿 中

두고두고 꺼내 읽는 책으로 작년에 또 한 번 읽은 책입니다. 우리는 일상에서 가끔 천재들을 마주하지만, 1) 올바른 방향으로 2) 의식적인 노력을 꾸준히 이어간다면 어느 순간 재능충인 그들을 뛰어넘을 수 있습니다.

세컨드 브레인(저자: 티아고 포르테)

<출처: 작가 편집>

<출처: Excalidraw, 작가 편집>

저는 생산성을 높이는데 아주 관심이 많습니다. 그래서 생산성 향상을 목적으로 그동안 시중에 출시된 대부분의 노트 앱을 최소 1년 이상 사용해 왔고, 각 노트 앱의 모든 기능을 활용하는 하드코어 유저이기도 합니다. 그러던 중 제텔카스텐 기반의 노트 관리법에 관심이 생겼고, 이후 사용하는 노트 툴과 관리 방법을 완전히 바꿨습니다. 그 과정에서 롬리서치를 3년, 옵시디언을 2년간 써오고 있는데 이 책에서는 생산성 향상을 위해 노트를 어떻게 관리해야 하는지에 대한 개념을 잡아줍니다.

저는 이 책에서 소개하는 PARA 방법론으로 노트를 관리하지는 않지만, 생산성에 관심 있는 분이라면 꼭 한 번 읽어보길 추천하는 책입니다.

“CRM 마케팅에 관심이 있다면”

모던 그로스 마케팅(저자: 최지연, 조은태)

<출처: 작가 편집>

<출처: Excalidraw, 작가 편집>

저는 이 책을 출간하신 두 분을 사석에서 만나 뵙고 이야기를 나눈 적이 있는데, 전통적인 마케터들과는 접근 방법부터 다르다는 인상을 받았습니다. 그리고 2024년 3월에 책 출간 소식을 듣게 되었는데요. 이 책은 기존에 출시된 퍼포먼스 마케팅 관점이 아닌 CRM 마케팅 관점에서 어떻게 실험을 해야 하는지, 진짜 성과를 높이기 위해서는 어떠한 관점을 가져야 하는지, 저자 두 분이 각자의 기업에서 경험한 실무 노하우가 고스란히 담겨있습니다.

신규 고객을 획득하는 것은 기존 고객을 유지하는 것보다 25배 이상의 비용이 든다고 합니다. 이제는 우리 서비스에 한 번 가입한 고객을 계속해서 재방문시키고, 전환을 만들어내는 CRM 마케팅이 주목받는 시기입니다. 위에서 소개한 ‘훅’, ‘콜드 스타트’와 함께 읽어보시면 좋습니다.

마치며

좋은 책을 만나는 것도 중요하지만, 책에서 얻은 지식을 내 것으로 만드는 과정 또한 의미 있다고 생각합니다. 저는 책을 읽으며 마인드맵으로 주요 내용을 정리하는데요. 이 방법은 독서한 내용을 체계적으로 정리하고, 기억에 오래 남아 추천드리고 싶습니다. 이번 글에서 소개한 책을 통해 여러분의 인사이트가 더 깊고 풍성해지길 바랍니다.

<원문>

작년부터 올해까지 다시 읽었거나 읽고 있는 책들

]]>