Divii

Category: AI 개발

  • AI 기능을 붙였는데 왜 경쟁력이 생기지 않을까

    AI 기능을 붙였는데 왜 경쟁력이 생기지 않을까

    많은 한국 기업이 AI 도입을 선언하고 있습니다. 그런데 왜 사업 구조는 바뀌지 않는가 — AI 전환 전략의 문제

    지금 일어나고 있는 일

    나이키의 전 마케팅 데이터 부사장은 AI 프로젝트 실패의 원인을 명확하게 지목했습니다. 자동화에만 집중했기 때문입니다.

    AI 자동화는 기존에 하던 일을 더 빠르게, 더 저렴하게 만드는 것입니다. 마케팅 문구를 AI로 생성하거나, 고객 데이터를 AI로 분류하는 방식입니다. 단기적으로 효율은 올라갑니다. 그러나 경쟁사도 동일한 방식을 6개월 안에 따라 할 수 있습니다.

    자동화는 결국 모든 기업이 갖춰야 할 기본 조건이 됩니다. 기본 조건은 경쟁 우위가 아닙니다.

    과거 방식의 한계

    과거에는 디지털 플랫폼을 구축하는 것 자체가 차별화였습니다. 앱을 만들고, 결제 시스템을 붙이고, 사용자 데이터를 쌓는 것만으로도 선발 우위가 생겼습니다.

    지금은 다릅니다. 플랫폼은 누구나 만들 수 있습니다. 앱 출시는 진입장벽이 아닙니다. 기능의 유무보다 플랫폼이 어떤 구조로 설계됐는가가 중요해졌습니다.

    그런데 대부분의 기업은 여전히 과거 방식의 질문을 던지고 있습니다. “어떤 기능을 추가할까?”

    변화의 흐름

    나이키는 스니커즈 앱을 구축하면서 한정판 구매 방식을 오프라인 줄 서기에서 디지털 추첨으로 전환했습니다. 문제는 그 다음이었습니다. 앱으로 전환하자 수요 예측 오차가 급격히 커졌고, 공정성에 대한 불만이 쌓였습니다.

    나이키는 이 문제를 해결하기 위해 앱 안에서 사용자 취향 데이터를 직접 수집하는 구조를 만들었습니다. 게임, 설문, 참여 행동을 통해 개인화 데이터를 누적했고, 수요 예측 오차를 1년 만에 44% 줄였습니다. 공정성 점수와 참여도 점수를 기반으로 당첨 확률을 설계함으로써 만족도가 높아진 고객이 전체 매출에 기여하는 구조를 만들었습니다.

    핵심은 AI 기능 자체가 아닙니다. 데이터를 수집할 수 있는 플랫폼 구조를 먼저 설계했다는 것입니다.

    구조적 해석: 진짜 질문은 무엇인가

    한국 IT 스타트업 기획 회의실에서 화이트보드에 플랫폼 데이터 흐름을 설계하는 장면, PM과 기획자가 데이터 수집 구조를 논의 중
    어떤 데이터를 어디서 수집할 것인지는 개발이 아니라 기획의 문제입니다. 이 결정이 플랫폼의 AI 전환 가능성을 좌우합니다.

    AI 자동화와 AI 전환은 근본적으로 다른 질문에서 출발합니다.

    자동화는 “이 일을 어떻게 더 빠르게 할 수 있을까?”를 묻습니다. 전환은 “이 비즈니스를 아예 다른 방식으로 작동시킬 수 있을까?”를 묻습니다.

    유통 플랫폼을 예로 들면, 단순히 견적서 작성을 자동화하는 것은 자동화입니다. 반면 누가 어떤 거래에 반복적으로 참여하는지, 어느 카테고리에서 성사율이 높은지, 어떤 조건이 갖춰졌을 때 거래가 완결되는지를 플랫폼이 학습하도록 설계하는 것은 전환입니다.

    이 두 접근은 초기 기획 단계에서 갈립니다. 데이터 구조, 사용자 행동 설계, 관리자단 설계 방식이 처음부터 달라집니다.

    실행 관점에서의 의미

    AI 전환을 가능하게 하려면 플랫폼이 처음부터 학습 가능한 구조로 만들어져야 합니다.

    구체적으로는 다음과 같은 설계 판단이 필요합니다. 사용자 행동 로그를 어떻게 수집하고 어디에 적재할 것인가. 어떤 사용자 인터랙션이 핵심 데이터가 되는가. 관리자단은 단순 운영 도구인가, 아니면 데이터 기반 의사결정 도구인가.

    이런 질문은 기획 단계의 질문입니다. 개발이 완료된 이후에 AI를 추가하는 방식은 구조적 한계에 부딪힙니다.

    나이키의 사례가 보여주는 것도 이것입니다. 나이키가 데이터 제휴를 통해 구매 패턴을 연결하고 개인화 마케팅을 가능하게 한 것은 플랫폼 기획 단계에서 데이터 흐름을 설계했기 때문입니다. AI는 그 구조 위에 얹힌 것입니다.

    디비컨설팅의 관점

    디비컨설팅은 100개 이상의 IT 프로젝트를 수행하면서 플랫폼 기획과 개발을 동시에 진행하는 구조를 유지하고 있습니다. 한국 PM팀이 기획을 주도하고, 인도 개발팀이 R&D를 병행합니다. 이 구조는 단순히 속도를 높이기 위한 것이 아닙니다.

    기획과 개발이 분리되면 데이터 수집 구조, 사용자 행동 추적, 확장성을 고려한 아키텍처 설계가 후순위로 밀립니다. 기획자는 기능 목록을 만들고, 개발자는 그것을 구현하는 방식으로는 AI 전환을 위한 플랫폼을 만들 수 없습니다.

    Stylemate(인플루언서 협찬 플랫폼)에서 소셜미디어 API를 연동해 협찬 완료 데이터를 플랫폼에 자동 연결하는 구조를 설계한 것, 패밀리(식품 성분 분석 플랫폼)에서 사용자의 식습관과 관심 식단 데이터를 수집하는 개인화 시스템을 기획 단계에서 설계한 것이 그 실제 사례입니다. 이런 플랫폼은 추후 AI 기능을 붙일 때 구조적 기반이 이미 갖춰져 있습니다.

    결론: 플랫폼을 짓기 전에 먼저 이 질문을 해야 합니다

    “이 플랫폼이 시간이 지날수록 더 똑똑해질 수 있는 구조인가?”

    AI 기능 추가는 나중의 문제입니다. 데이터를 쌓을 수 있는 구조, 사용자 행동이 의미 있는 신호가 되는 설계, 학습이 가능한 관리자단이 먼저입니다.

    자동화로는 현재의 비용을 줄일 수 있습니다. 전환은 미래의 경쟁 구조를 바꿉니다. 그 차이는 기획 단계에서 이미 결정됩니다.

  • AI 기능을 앱에 붙이면 생기는 일 | 실전 사례 5가지

    AI 기능을 앱에 붙이면 생기는 일 | 실전 사례 5가지

    “AI 기능 하나 추가해주세요” — 요즘 가장 많이 받는 요청입니다. AI를 앱에 붙이면 어떤 일이 생기는지, 실제 프로젝트 5가지 사례로 정리합니다.

    사례 1 — 시원스쿨 AI 선생님 (ChatGPT 기반 튜터봇)

    시원스쿨 태블릿 앱에 ChatGPT 기반 AI 선생님을 구현했습니다. 학습 중 궁금한 것을 실시간으로 물어볼 수 있습니다.

    실제로 어떻게 구현했나: OpenAI API를 연동하고, 시스템 프롬프트를 “시원스쿨 영어 강사” 역할로 설정했습니다. 사용자 질문이 들어오면 API를 호출하고 응답을 스트리밍으로 표시합니다.

    붙이면서 생긴 일:

    • API 비용 관리가 필요해졌습니다. 사용자가 많아지면 API 비용이 선형으로 증가합니다. 답변 길이 제한, 하루 질문 횟수 제한 등의 정책이 필요합니다.
    • 잘못된 답변 처리 문제. AI가 항상 정확하지 않습니다. “틀릴 수 있습니다”는 면책 조항만으로 충분한지 법적 검토가 필요했습니다.
    • 응답 속도. GPT-4는 느립니다. 스트리밍으로 답변이 실시간 타이핑되는 것처럼 보여주는 UX로 체감 속도를 개선했습니다.

    사례 2 — AR Cosmetics AI 피부 분석

    디바이스 카메라로 얼굴을 촬영하면 잡티, 주름, 유분 지수 등 9가지 지표를 분석합니다.

    실제로 어떻게 구현했나: 자체 AI 모델을 만들지 않고 피부 분석 전문 API를 연동했습니다. 이미지를 API에 전송하면 분석 결과 JSON이 돌아오는 구조입니다.

    붙이면서 생긴 일:

    • 서드파티 AI API 의존도. 해당 업체가 서비스를 중단하거나 가격을 올리면 직접 영향을 받습니다. 벤더 종속(vendor lock-in) 리스크를 처음부터 고려해야 합니다.
    • 얼굴 데이터 민감성. 얼굴 이미지를 외부 API에 전송한다는 사실을 사용자에게 명확히 알려야 합니다. 개인정보처리방침에 명시 필수.
    • 조명, 각도에 따른 분석 편차. 사용자 가이드(촬영 방법 안내)가 UX의 핵심이 되었습니다.

    사례 3 — AI 봇아미 튜터링 딥러닝 채점

    학습자가 교재 문제를 풀면 카메라로 촬영해서 AI가 채점합니다. 제스처 인식으로 페이지 넘기기도 구현했습니다.

    실제로 어떻게 구현했나: 문항 이미지를 인식하는 딥러닝 모델과 정답 패턴을 학습한 채점 모델을 별도로 구축했습니다.

    붙이면서 생긴 일:

    • 학습 데이터가 필수. 모델 정확도는 학습 데이터 품질에 달려있습니다. 다양한 필체, 다양한 조명 조건의 이미지를 충분히 수집해야 했습니다.
    • 오답 처리의 민감성. 정답인데 오답으로 채점되면 학습자 불만이 큽니다. 신뢰 구간이 낮은 경우 수동 검토로 넘기는 fallback 로직이 필요했습니다.
    • 온디바이스 vs 클라우드. 네트워크 없는 환경에서도 채점이 되어야 해서 경량화 모델을 디바이스에 올리는 방식을 선택했습니다.

    사례 4 — Xanacloud 의료 AI 데이터 어노테이션

    AI 의료 진단 모델 학습을 위해 의료진이 초음파 영상에 직접 레이블을 붙이는 플랫폼입니다.

    실제로 어떻게 구현했나: AI가 직접 진단하는 게 아니라, AI 학습을 위한 “정답 데이터”를 사람이 만드는 도구를 개발했습니다.

    붙이면서 생긴 일:

    • 어노테이션 품질 관리. 같은 영상을 여러 의료진이 레이블링하면 결과가 다를 수 있습니다. 의견 불일치 처리 로직과 품질 검수 시스템이 필요했습니다.
    • 대용량 의료 영상 처리. DICOM 같은 의료 영상 포맷은 일반 이미지와 다릅니다. 웹에서 이를 빠르게 렌더링하는 것이 기술적 핵심이었습니다.

    사례 5 — Wegofair AI 위조상품 모니터링

    온라인에서 판매되는 상품 중 위조품을 AI가 탐지해 소비자를 보호합니다.

    실제로 어떻게 구현했나: 웹 데이터 크롤링으로 상품 이미지와 정보를 수집하고, AI가 진품과 비교 분석합니다. 결과는 웹 테이블로 시각화합니다.

    붙이면서 생긴 일:

    • 크롤링 허용 여부. 상품 플랫폼마다 크롤링 정책이 다릅니다. 법적·기술적으로 허용된 범위를 먼저 확인해야 합니다.
    • 모델 업데이트 주기. 위조업자들도 진화합니다. AI 모델을 주기적으로 재학습해야 탐지 정확도를 유지할 수 있습니다.

    AI를 앱에 붙이기 전에 확인할 것들

    1. 자체 모델 vs API 연동: 자체 모델은 비용이 많이 들지만 완전한 통제권이 있습니다. API 연동은 빠르지만 벤더 의존성이 생깁니다. 서비스 성격에 따라 선택해야 합니다.

    2. 데이터 확보 계획: AI의 품질은 학습 데이터에 달려있습니다. 충분한 데이터를 어떻게 확보할지 먼저 계획이 있어야 합니다.

    3. 비용 구조: API 기반 AI는 사용량에 따라 비용이 증가합니다. DAU, 기능 사용 빈도를 예측해 비용 시뮬레이션을 먼저 해보세요.

    4. 오답/오류 시 처리: AI는 틀립니다. 틀렸을 때 어떻게 할 것인지 — 사용자 신고 기능, 수동 검토 프로세스, 면책 고지 — 를 미리 설계해야 합니다.

    5. 법적 검토: 의료, 금융, 교육 분야에서 AI 판단이 실제 의사결정에 영향을 주는 경우 규제 이슈가 생길 수 있습니다.

    마치며

    AI를 붙이면 서비스가 자동으로 좋아지지 않습니다. AI는 도구입니다. 어떤 문제를 해결하기 위해, 어떤 방식으로 사용할 것인지가 먼저 명확해야 합니다. “AI 넣어주세요”가 아니라 “이 문제를 AI로 해결하고 싶습니다”가 올바른 출발점입니다.