삼성·네이버·현대차의 LLM 전략 비교

 

— 생성형 AI 시대, 세 기업은 어디로 가고 있을까


서론

2025년 현재, 생성형 AI는 더 이상 기술 부서의 실험이 아니라 기업 전략의 핵심 축이 되었습니다.
특히 국내 각 분야의 대표 기업인 삼성전자·네이버·현대자동차그룹은 각자의 산업 영역과 강점을 바탕으로 서로 다른 LLM 전략을 펼치고 있죠.

이번 글은 실제 AI 리서치 워크플로우(Perplexity → Notebook LM → ChatGPT) 를 통해 세 기업의 접근법을 조사하고 정리한 결과입니다.
요즘 저도 기업별 LLM 활용 구조를 유심히 보고 있는데, 같은 ‘AI 전략’이라도 산업별로 이렇게 다르다는 게 꽤 흥미롭더군요.
정보의 최신성(Perplexity) + 정밀한 요약(Notebook LM) + 스토리텔링(ChatGPT)을 결합해, AI PM 시점에서 본 전략적 차이와 시사점을 정리했습니다.
국내 대표 기업들이 생성형 AI를 어떻게 바라보는지 궁금했고, 앞으로 각 기업의 전략과 방향성도 함께 확인해보고자 합니다.


본론

🧠 삼성전자 — “온디바이스 AI로 내부 효율 최적화”

삼성의 Gauss AI 전략은 내부 생산성 혁신과 온디바이스 통합에 초점이 맞춰져 있습니다.

  • 핵심 방향: 문서 요약·메일 작성·번역 등 반복 업무 자동화 및 사내 의사결정 지원.
  • 기술 구조: 자체 파운데이션 모델 ‘Gauss 2’ 개발 → 스마트폰, 가전, TV 등 모든 제품에 탑재.
  • 보안 전략: 외부 모델(GPT 등) 사용을 제한하고 내부 모델 로컬 운용으로 보안 강화.

요약 인사이트:
삼성은 AI를 ‘클라우드 기능’이 아닌 ‘제품 기능’으로 내재화한다.
하드웨어 중심 기업으로서 AI를 제품 경쟁력의 핵심 요소로 삼는 전략이다.
결국 AI를 ‘제품 속에서 작동하게 만드는’ 데 초점을 맞춘 점이 가장 인상적이다.


🌐 네이버 — “초거대 모델 기반 서비스 플랫폼 확장”

네이버는 LLM을 플랫폼 전체의 엔진으로 활용합니다.

  • 핵심 방향: 검색·쇼핑·콘텐츠 등 모든 서비스에 ‘HyperCLOVA X’ 적용.
  • 기술 전략: 초거대 자체 모델 기반 + 오픈소스화(SEED) → 개발자 생태계 확장.
  • 비즈니스 확장: 클라우드 기반 B2B 챗봇·AI 솔루션 사업 확대.

요약 인사이트:
네이버는 AI를 ‘하나의 서비스’가 아닌 ‘플랫폼 전반의 연결 조직’으로 활용한다.
자사 생태계를 넓히는 국산 파운데이션 모델 플랫폼 전략이며,
결국 모델을 비즈니스 인프라로 전환하는 방향을 가장 명확하게 보여준다.


🚘 현대자동차그룹 — “모빌리티 전환을 이끄는 하이브리드 AI”

현대차는 LLM을 SDV(소프트웨어 기반 차) 전략의 핵심으로 위치시켰습니다.

  • 핵심 방향: 차량 내 인포테인먼트·디지털 어시스턴트 등 모빌리티 AI 기능 강화.
  • 기술 전략: 자체 모델 ‘글레오’ + 네이버 ‘HyperCLOVA X’ 협업 → 하이브리드 접근.
  • 인프라 기반: 엔비디아 블랙웰 칩을 활용한 AI 팩토리 구축 및 보안 강화.

요약 인사이트:
현대차는 AI를 ‘서비스’가 아닌 ‘제품 진화의 동력’으로 활용한다.
완성차 기업의 한계를 넘어 소프트웨어 기업으로 전환하려는 명확한 의지다.
실제로 네이버·엔비디아와의 협업 구조를 보면, 가장 유연하면서도 실행 속도가 빠른 형태다.


⚖️ 비교 요약 표

구분삼성전자 (Gauss AI)네이버 (HyperCLOVA X)현대차 그룹 (HMG AI)
전략 목표내부 효율 + 제품 AI 통합플랫폼 혁신 + B2B 생태계 확장SDV + 모빌리티 혁신
기술 구조자체 파운데이션 모델, 온디바이스 중심자체 초거대 모델 + 오픈소스 생태계하이브리드(자체 + 협업) 구조
강점하드웨어 연동, 보안 통제데이터 풍부, 개방적 생태계명확한 시장 집중 및 유연성
약점외부 연동 제약, 플랫폼 한계하드웨어 접점 부족전환 속도·내부 조직 부담

결론

🔍 핵심 차이와 공통 패턴

  • 차이점: 삼성은 하드웨어, 네이버는 플랫폼, 현대차는 모빌리티 중심.
    즉, 각자의 기존 강점을 더 강화하는 방향으로 전략을 설계하고 있습니다.
  • 공통점: 세 기업 모두 ① 내부 업무 자동화, ② 고객 응대 AI, ③ AI 조직 강화 를 핵심 축으로 삼고 있음.
    즉, “AI 내재화 → 운영 효율화 → 서비스 고도화” 단계를 공통적으로 밟는 중입니다.

🔍 인사이트

차이점과 공통점에서 볼 수 있듯이,
AI를 통한 업무 효율화 및 개선은 모든 산업에서 공통적인 필수 영역이며,
각 회사마다의 핵심 강점을 더욱 차별화하고 강화하는 방향으로 작동해야 합니다.
결국 기업의 LLM 전략은 “AI를 어디에, 얼마나 깊이 통합하느냐”로 요약될 수 있습니다.


💬 AI PM 입장에서 본 시사점

  1. AI는 이제 ‘기능’이 아니라 전략 레이어다.
    세 기업 모두 AI를 제품·서비스·조직 전반에 녹이는 방식을 택했습니다.
    PM에게 요구되는 역량은 ‘AI 기획 능력’ 그 자체보다 AI를 통한 서비스 재설계 감각입니다.
  2. AI 도구 활용이 사고 방식을 바꾼다.
    예컨대, Perplexity → Notebook LM → ChatGPT 의 조합은
    단순 검색·요약이 아니라 ‘문제를 정의하고 스토리를 조립하는 사고 루틴’을 만듭니다.
    이것이 곧 AI 시대의 기획자 및 PM의 새로운 리서치 프레임워크입니다.
  3. 앞으로의 기획자는 ‘AI 생태계 조율자’가 된다.
    모델·데이터·UX·윤리까지 모두 교차하는 지점을 연결해야 합니다.
    즉, 기획은 더 이상 문서를 작성하는 일이 아니라 AI와 함께 사고 구조와 전략을 설계하는 일이 됩니다.

✍️ 이 글은 Perplexity로 자료를 수집하고, Notebook LM으로 분석한 뒤, ChatGPT로 정리했습니다.
세 도구를 하나의 워크플로우로 활용하면, 단순한 정보 요약이 아닌 ‘AI 리서치 루틴’을 구현할 수 있습니다.
결국 중요한 건 도구가 아니라, 그걸 통해 어떻게 사고하느냐겠죠.
다음 글에서는 이 루틴을 ‘AI PM의 업무 변화’ 관점에서 확장해보겠습니다.

🚗 현대차 LLM 챗봇 데모 (Hybrid: Rule + RAG)

추석 연휴 ,
개인 프로젝트로 진행한 하이브리드 챗봇 데모를 공개합니다.

Rule의 안정성과 LLM의 확장성을 결합하여,
연휴 기간 동안 바이브코딩 방식으로 직접 구축하고 다듬어 보았습니다.
(※ 현대자동차 공식 챗봇과 무관합니다.)


🎬 Hook: 1 데모 + 최종 평가

👉 Demo: hyundai-chatbot-demo.vercel.app

※ 참고: Vercel 빌드 환경에서는 일부 RAG 질의(띄어쓰기·유사명칭·오탈자 등)의 인식률이 Stackblitz 실험 환경보다 낮게 나타날 수 있습니다.
본 영상은 Stackblitz 기준으로 촬영되었으며, 동일 코드 기반으로 Vercel에서도 대부분 정상적으로 작동합니다.


1️⃣ 만들었나 (Why)

이번 데모는 바이브코딩을 통한 챗봇 구현 프로젝트의 일환으로, 차량 구매 목적의 실제 사용자 시나리오에서 출발했습니다.

기존 챗봇의 경우 기본 정보 제공은 충분했지만, 구매·시승·상담 다음 행동으로 자연스럽게 이어지는 흐름은 더 보완될 여지가 있었습니다.

목표는 기존 시스템을 비판하는 것이 아닌, 정보 전달행동 전환간격을 줄이는 플로우 설계였습니다.

  • 구매 목적 사용자 시나리오의 개선 포인트
    • 견적/시승 문의까지 이동 단계가 비교적 길어지는 구간
    • 외부 페이지 이동 시 대화 맥락이 단절되는 지점
    • 동일 메뉴/버튼 반복 노출로 인한 탐색 피로

이에 따라 데모는 “FAQ 요약 + 공식 링크(CTA) + 최소 단계 전환을 원칙으로, 사용자가 질문하면 필요 행동까지 즉시 연결되고 순환되는 경험을 지향했습니다.


2️⃣ 어떻게 만들었나 (How)

Part 1. 분석 & 전략

  • 가설
    1. 목표 행동(구매·시승·AS)까지 경로 단축링크/CTA 무결성이 사용자 만족도와 목표(KPI) 전환에 결정적이라고 가정
    2. 또한 LLM 측면에서 유사 발화 대응력(띄어쓰기·별칭·오탈자)이 실사용성에 큰 영향을 준다고 가정
  • 분석
    1. 실제 공식 사이트 캡처·메뉴 트리 분석
    2. Top FAQ 및 유사 발화 수집&정규화
    3. 링크 유효성 및 도메인 점검
  • 전략
    1. 플로우 단순화(Simplify Flow) → 메뉴 통합, CTA 중심 설계, 1~2단계 내 해결
    2. 지속적인 연결(Connect Experience) → 핵심 정보는 대화 내 제공, 필요 시에만 외부 링크
    3. 데이터 최신화(Keep Data Fresh) 공식 FAQ 247 + 추가 Top 50 정비하여 반영 ( 지식 강화로 RAG 품질 안정화/고도화에 기여)

Part 2. 설계 & 개발

  • 아키텍처(Front-only Hybrid)
    • Rule Layer: 가격·보증·리콜·EV 추천 등 고정 의도 우선 처리
    • RAG Layer: faq.json + BM25 검색 → LLM 요약
    • UX Layer: 칩(Chips), 바텀시트, Sticky CTA(공식 링크/전화)

  • R1 → R2 → R3 개선 사이클
    • R1 (Prototype): Rule 70~80% + RAG 기본(가능성/흐름 우선)
    • R2 (Tuning): Rule 100% + 현대차 공식 FAQ 크롤링 반영 + BM25 교체, 유사 발화 정규화, 자동 테스트 루틴 구축
    • R3 (QA/Deploy): 자동/수동 라벨 교차검증, CTA·Fallback 보강 → 최종 평가 기준 항목 Pass

Part 3. 자동 테스트 & QA

  • 테스트 루틴
    • 콘솔 기반 runBatch() 자동 테스트 → 수동 라벨링으로 최종 판정
  • 라벨 분포 보정(R1 예시)
    • 자동: Good 40 / Fair 120 / Bad 136
    • 수동(최종): Good 183 / Fair 2 / Bad 111
    • “자동–수동 일치율: 45.6%”임계값·가중치 보정 상향
  • 보정 정책(R3 반영)
    • Retrieval TopScore 임계값 조정(예: ≥20=Good 후보)
    • Retrieval 성공 시 CTA 필수 부착, Fallback에도 고객센터 CTA 제공
    • 부분매칭 Good는 Gold 데이터 보강하여 업데이트
      → 위 보정 이후, 본문 상단 최종 평가 의 기준으로 품질을 점검·정리했습니다.

Part 4. RAG + Rule 하이브리드

  • 현업에서는 Rule-first를 반영했으나, 본 프로젝트에서는 RAG-first를 도입하여 실험
  • Retrieval 신뢰도(TopScore/Threshold)에 따라 FAQ → OpenDomain → Fallback으로 분기 처리
  • 역할 분리: “Rule = 안정성, “RAG = 커버리지·설명력
    ※ Vercel 배포 환경에서는 런타임(Edge vs Node) 및 경로 처리 차이로 인해 일부 질의(띄어쓰기, 유사명칭 등)의 검색 인식률이 Stackblitz 실험 환경 대비 다소 낮게 나타났습니다. 코드 구조와 데이터는 동일하며, 이는 환경 특성에서 비롯된 결과로 판단됩니다.

Part 5. 배포 트러블슈팅

  • Vercel 환경: OpenAI 직접 호출 지양 → /api/chat.ts 에지 프록시
  • 인덱싱 race 방지: ensureRagReady() 싱글톤 초기화 + 임베디드 코퍼스
  • dev/prod 코퍼스 동기화: assets 임베드 + 런타임 /faq.json 덮어쓰기
  • 재할당 경고 해결: const → let
  • 공식 FAQ URL 변경: 리다이렉트 미지원 건은 외부 이슈로 Skip

3️⃣ 결과 & 배운 (What / Lessons)

🎯 핵심 성과

  • 최상단 최종 평가 표 기준으로 정확도·라우팅/폴백·링크/CTA·성능·스타일/안전·UI/UX 항목 Pass 달성했습니다.
  • Rule + RAG 결합 구조를 구축하고, 자동 QA 루틴(runBatch)을 적용했습니다.
  • R1→R2→R3 개선 사이클을 통해 품질을 확보하고 프로덕션 레디 수준으로 정비하였습니다.

🧩 진행 어려움

  • 마지막 5% 완성 구간에서 시간 소요가 집중되었습니다. (체감상 전체 소요 시간의 20% 이상)
  • 공식 사이트 URL 변경(리다이렉트 미지원)로 일부 항목은 Skip 처리했습니다.
  • 바이브 코딩 시, 프롬프트 반복 입력 시 맥락을 벗어나 필요 이상으로 수정 발생하는 케이스가 많았습니다.
  • 배포 환경(Vercel)에서 RAG 검색 성능이 Stackblitz 대비 약하게 나타났습니다. 이는 런타임 및 빌드 환경 차이로 인한 현상으로, 실 서비스 영향 범위는 RAG 한정으로 나타났습니다.

💡 교훈

  1. 작업 단위는 최대한 작게 쪼개고, 문맥은 명확하게 가져가야 합니다. (챗방 최대한 쪼개기 + 상세한 프롬프트 필요)
  2. 제안 코드는 그대로 적용하기보다 구조를 확인하고 최소 수정으로 해결해야 합니다.
  3. 바이브 코딩은 개발 도구에 가깝습니다(기본 문법·구조 이해가 효율을 좌우).
  4. Agent 자동 검수 + 수동 QA 조합으로 효율적으로 시간을 아끼고 품질을 높여줍니다.
  5. 초기 목표는 50% 범위로 설정해야 합니다. 최초 예상보다 2~3배의 시간과 노력이 소요되기 쉬워, 단계별 확장이 현명합니다.
  6. RAG 보정은 생각보다 어렵습니다. (예: 유사 발화·띄어쓰기·별칭 대응 등)

 

P.S. 추석 연휴 내내 작업하여 마지막 보정 작업과 글 작업을 진행하니 어느덧 1주일이 금방이네요. 처음 해보는 바이브코딩은 생각보다 어렵고 힘들었지만, 생각보다 재미있고 많은 걸 배울 수 있었습니다. 더 재미나고 쉬운 바이브코딩 2탄으로 찾아오겠습니다 😊🤩

 

AI 챗봇 프로젝트에서 배운 배포 환경의 중요성

1. 들어가며

앞선 글에서는 “컨텍스트를 어떻게 설계했는가”를 다뤘습니다.
하지만 프로젝트를 진행하며 다시 깨달은 건, 아무리 컨텍스트를 잘 짜도 배포 환경이 받쳐주지 않으면 안 된다는 사실이었습니다.

실제 경험을 예로 들어보겠습니다.
2차 테스트에서 정확도가 79%까지 수직 상승하며 “드디어 안정권이다”라고 안심했습니다. 그런데 3차 테스트에서는 빌드와 데이터가 동일했음에도 불구하고, 정확도가 67%로 급락했습니다. 당시 팀 분위기는 충격 그 자체였습니다.


2. 문제 발견

처음엔 모델의 성능 저하나 데이터 이슈를 의심했지만, 실제 원인은 전혀 다른 곳에 있었습니다. 바로 빠르게 진행된 배포 과정에서 발생한 관리 부재였습니다.

  • 캐시 갱신 실패: 빌드는 동일했지만, 하루치 캐시가 남아 있어 새 지식이 반영되지 않음
  • 빌더/운영 환경 불일치: RC와 Live 빌더에 각각 지식을 삽입했는데, 환경 간 불일치로 답변 공백 발생
  • 지식 삭제 문제: 일부 항목(예: 프레임 관련)이 잘못 제거되며 답변 불가 상태 노출

즉, 모델 개선 문제가 아니라 운영 환경 관리의 허점이 서비스 품질을 무너뜨린 것이었습니다.


3. 해결 과정

론칭을 불과 며칠 앞둔 상황이라, 개발/운영/PM/기획이 모두 모여 긴급 논의를 진행했습니다. 그리고 두 개의 트랙으로 문제를 정리했습니다.

Track 1. 론칭 대응

  • 컨텍스트 엔지니어링 기반으로 챗봇 응답 정확도 최대한 끌어올리기
  • 문제된 세 가지 이슈(캐시·환경 불일치·지식 삭제) 즉시 보완 후 QA 진행
  • 원칙: 론칭 후 버전 업데이트 시 임의 수정 금지 (롤백 기능 부재로 동일 리스크 재현 우려)

Track 2. 사후 대응

  1. 캐시 갱신 기능 – 자동·수동 병행 도입
  2. 빌더 버전 관리 – 빌드 버전별 프리징 및 배포 이력 관리
  3. 지식 기반(KB) 관리 – KB 등록/삭제 이력, RAG 활용 여부, 연결된 답변 예시까지 투명하게 관리

4. 성과

이 과정을 통해, 배포 관리의 중요성을 시스템 차원에서 각인할 수 있었습니다.
결과적으로 정확도는 다시 끌어올려, 안정적으로 마무리할 수 있었습니다.

  • 정확도: 3차 67% → 최종 89%
  • 운영 환경 안정화: 캐시·빌더·KB 관리 프로세스 확립
  • 팀워크 개선: 배포와 운영까지 “하나의 제품 경험”이라는 인식이 공유됨

5. 교훈

이 경험에서 얻은 인사이트는 분명했습니다.

  • 좋은 모델도 운영 환경에서 무너지면 끝이다.
  • 배포 환경과 운영 설계는 단순 지원이 아니라, 사용자 경험을 결정짓는 핵심이다.
  • PM과 기획자는 모델과 컨텍스트뿐 아니라 운영 환경까지 미리 챙겨야 한다.

1편에서 다룬 컨텍스트 설계가 챗봇의 ‘두뇌’를 만드는 과정이었다면,
이번 2편에서 다룬 배포 환경/운영 설계는 그 두뇌가 현실에서 제대로 작동하도록 하는 ‘신경망’을 세우는 과정이었습니다.

결국 챗봇은 모델-컨텍스트-운영 환경 이 세 박자가 맞아야만 제대로 작동합니다.
만약 본인이 PM 혹은 기획자라면, 놓치기 쉬운 배포와 운영 환경까지 반드시 점검하시길 권합니다.