📘 1부: 프롬프트는 질문, 엔지니어링은 설계입니다

 

부제: 더 좋은 응답을 쉽게 얻는 법


LLM을 쓰다 보면 누구나 한 번쯤 이런 경험을 합니다.

  • “어제는 잘하더니 오늘은 왜 이렇게 엉뚱하게 답하지?”
  • “GPT가 작업 중간에 뭔가 잃어버린 것 같은데?”
  • “이렇게 스펙을 정리했는데 왜 다른 걸 이해하지…?”

이 차이를 만드는 핵심 원인은 프롬프트를 어떻게 입력 혹은 설계했느냐입니다.
같은 모델에게 요청해도 결과가 다르게 나오는 이유죠.

이 글에서는 ‘프롬프트 vs 프롬프트 엔지니어링’의 차이
가장 쉽고 실용적인 관점에서 정리해보겠습니다.


🧩 1. 프롬프트란 무엇일까요?

프롬프트는 AI에게 주는 요청(Instruction)입니다.
즉, “이걸 해달라”고 전달하는 단순 명령입니다.

예를 들면:

  • “이 문서를 요약해 주세요.”
  • “서비스 기획서를 작성해 주세요.”
  • “아이온2 전투 시스템을 설명해 주세요.”

이렇게 단순하게 입력해도 모델은 꽤 많은 일을 해냅니다.
하지만 문제는 결과가 일정하지 않다는 점입니다.
바로 이 지점에서 엔지니어링이 필요해집니다.


🏗️ 2. 프롬프트 엔지니어링이란?

프롬프트 엔지니어링은
AI가 더 좋은 결과를 안정적으로 내도록 입력을 설계하는 기술입니다.

단순히 길게 쓰거나 어렵게 쓰는 게 아니라,

  • 목적
  • 구조
  • 맥락
  • 데이터
  • 출력 형식

등을 명확하게 설계해 모델이 헤매지 않도록 안내하는 작업입니다.

그리고 중요한 사실이 있습니다.

프롬프트 엔지니어링은 개발자 기술이 아닙니다.
언어로 ‘설계’를 하는 모든 사람에게 필요한 스킬입니다.

PM·마케터·기획자·에디터·컨설턴트…
LLM을 쓰는 누구나 매일 부딪히는 실용 기술입니다.


🎯 3. 왜 굳이 프롬프트 엔지니어링을 해야 할까요?

저도 초기에는 이렇게 생각했습니다.

“GPT가 똑똑한데 굳이 복잡하게 설계할 필요가 있나?”

하지만 실제 업무에서 깊게 활용해보니 명확한 이유가 있습니다.

✔ 결과 품질이 매번 다르다

작은 표현·순서 차이만으로도 큰 품질 차이가 납니다.

✔ 모델은 부정문·복잡한 문장·중간부 누락에 취약

Lost in the Middle(중간 내용 삭제)은 LLM의 고질적 문제입니다.

✔ 엔지니어링을 하면

  • 더 정확하고
  • 더 빠르고
  • 더 저렴하고
  • 재사용 가능한 자동화 도구가 됩니다.

결국 목적은 하나입니다.

더 좋은 결과를 얻기 위해서.
더 쉽게, 더 안정적으로.


🧱 4. 프롬프트 엔지니어링의 핵심 4요소

이 4요소는 Anthropic Claude Prompt Engineering Guide,
OpenAI Prompting Overview,
Google Cloud Prompt Engineering Guide
에서 공통적으로 사용하는 구조입니다.

각 요소의 의미를 1줄로 정리하면 다음과 같습니다.


① Instructions (지시)

모델에게 “무슨 작업을 해야 하는지” 명확히 전달하는 부분.

예)

  • “아래 문서를 3줄로 요약해 주세요.”

② Input Data (데이터)

모델이 실제로 처리해야 하는 텍스트·표·코드 등 입력 데이터.

예)

  • 분석할 문서 본문
  • 사용자 로그
  • 텍스트 조각

③ Context (맥락)

작업이 수행되는 배경·조건·관점을 설명하는 부분.

예)

  • “PM 관점에서 설명해 주세요.”
  • “전문가 톤을 유지해주세요.”

④ Output Indicator (출력 지시문)

모델이 어떤 형태로 결과를 내야 하는지 구조·형식을 명시.

예)

  • “표 형식으로 작성해 주세요.”
  • “JSON으로 출력해 주세요.”
  • “한 줄당 20자 이하로 써 주세요.”

이 네 가지를 포함해 프롬프트를 작성하면 품질과 재현성이 크게 향상됩니다.


✏️ 5. 엔지니어링 팁 — 이것만 기억해도 반은 성공합니다

(각 항목에 좋은 예시(O) / 나쁜 예시(X) 포함)


✅ 1) 부정문 최소화

LLM은 부정문을 자주 오해합니다.

(X) 나쁜 예시

“문체는 절대 변형하지 말고 요약해 주세요.”
‘변형하지 말고’를 무시하거나 반대로 이해할 위험↑

(O) 좋은 예시

“문체는 그대로 유지하고, 핵심 내용만 요약해 주세요.”
긍정문 기반 → 오해 없음


✅ 2) 구조화된 프롬프트 사용

모델은 구조를 좋아합니다.

(X) 나쁜 예시

“전투, 경제, 보상을 포함해서 게임 시스템을 자세히 설명해 주세요.”
누락 or 순서 혼란 가능

(O) 좋은 예시

출력 구조:

  1. 전투 시스템(3줄)
  2. 경제 구조(표)
  3. 보상 구조(장점/리스크 2줄씩)
    → 모델이 “틀”대로 작성 → 안정적 출력

✅ 3) 출력 형식을 먼저 정하기

(X) 나쁜 예시

“이 글의 핵심 내용을 알려주세요.”
→ 모델이 임의 판단 → 길이·형식·순서 불안정

(O) 좋은 예시

“아래 문서를

  • 3줄 요약
  • 불렛 포인트
  • 한 문장 20자 이하
    형식으로 정리해 주세요.”
    → 품질·일관성 급상승

✅ 4) 짧고 명확하게

긴 설명은 사람도 AI도 이해하기 어렵습니다.

(X) 나쁜 예시

“배경이 이런데, 그래서 제가 원하는 건 이런 거고… 아무튼 잘 정리해 주세요.”

(O) 좋은 예시

“아래 기사를 PM 관점에서 3줄로 요약해 주세요.”
→ 명확·간결·정확


🔮 6. 앞으로는 GPT에게 ‘설계’까지 맡기는 시대

프롬프트 엔지니어링의 최신 방향은
“프롬프트를 사람이 직접 설계하는 시대가 끝나가고 있다”입니다.

이제는 이렇게 요청하는 것이 더 효율적입니다.

“GPT, 이 작업을 위한 최적의 프롬프트를 먼저 설계해 주세요.”

사람은 요구사항만 제시하고,
프롬프트의 구조·형식·샘플·맥락은 모델이 설계하는 시대입니다.


🧭 7. 마무리

프롬프트 엔지니어링은 어렵지 않습니다.
본질은 “좋은 질문을 구조적으로 만드는 기술”이며,
이를 통해 더 좋은 응답을 쉽게 얻을 수 있습니다.

이번 1부에서는 개념을 정리했습니다.
2부에서는 실전 Before/After 비교를 공개하겠습니다.


📘 다음 글 예고

2부: 프롬프트 엔지니어링은 GPT에게 맡기세요 — 실전 Before/After 3선

내용 구성:

  • AI/RAG 평가 기준 자동 생성
  • 데이터 정제 + 시각화 레포트 생성
  • 서비스 기획 문서 자동 생성
    세 가지 실무 예제를 통해 프롬프트 엔지니어링의 효과를 보여드립니다.

 

삼성·네이버·현대차의 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탄으로 찾아오겠습니다 😊🤩