1 프롬프트 자동 완성기 (Prompt Auto-Completion)
1.1 사용자 문제 정의
프롬프트 자동 완성기는 사용자가 AI와 효과적으로 소통하지 못하는 근본적인 문제를 해결한다.
발견된 문제점
- 사용자의 프롬프트가 구체적이지 못하고 불완전하다
- 현재 사용자가 프롬프트를 잘 쓸 수 있도록 안내하거나 보조하는 제품 내 장치가 없다
문제의 본질
- 대부분의 사용자는 “개발자로 살아남으려면?”처럼 막연한 질문을 던진다.
- 이는 세 가지 정보가 부족하다.
- 현재 상황 (예: 비전공자인지, 주니어인지),
- 원하는 결과 (예: 취업, 이직, 기술 향상),
- 제약 조건 (예: 시간, 예산).
AI는 이런 불완전한 입력으로도 답변을 생성하지만, 품질이 낮고 사용자는 만족하지 못한다. 결과적으로 “AI가 별로다”라고 느끼고 떠난다.
귀납적 접근
만약 서비스 로그를 분석하면 사용자의 초기 질문 대부분이 10 단어 이하의 짧고 모호한 형태임을 확인할 수 있다라고 한다면 이는 사용자의 문제가 아니라 인터페이스 설계의 문제다. 사람들은 본능적으로 검색창에 짧은 키워드를 입력하도록 학습되어 있다.
사용자들이 짧은 키워드만 입력하는 이유:
- Google 검색창에 익숙함: “개발자 공부”, “다이어트 방법”
- 입력창이 단순함: 긴 문장을 입력하도록 유도하지 않음
- 안내가 없음: 어떻게 질문해야 하는지 모름
→ 이는 사용자 교육의 문제가 아니라, UI 설계가 사용자의 기존 학습된 행동(검색창 습관)을 고려하지 못한 문제
“프롬프트를 잘 쓰는 법”을 교육하는 것보다, 불완전한 입력을 자동으로 완성해주는 도구가 훨씬 실용적이다.
UX/UI 관점: 인터페이스 설계의 문제
- 입력창이 Google 검색창처럼 생김 (UI 형태)
- 사용자는 검색창에 키워드만 입력하도록 학습됨 (상호작용 패턴)
- 이 경계면 설계가 AI와의 효과적 소통을 방해함
→ “사용자 교육” 문제가 아니라 UI/UX 경계면 설계 문제
해결 방법
AI와의 대화를 원활하게 진행하고 사용가치와 효율성을 극대화할 수 있는 프롬프트 자동 완성기를 제작한다.
“자동 완성”의 두 가지 의미
여기서 자동 완성은 두 가지를 동시에 의미한다.
- 사용자의 짧은 입력을 구체적인 프롬프트로 확장한다.
- “개발자 공부”를 “비전공자가 6개월 안에 웹 개발자로 취업하기 위한 학습 로드맵을 단계별로 알려줘”로 변환하는 것이다.
- 사용자가 미처 생각하지 못한 맥락 정보를 추론해서 추가한다.
- 이는 Google 검색의 자동완성과는 차원이 다른 고급 기능이다.
1.2 전제 설정 및 논리적 추론
가정: 프롬프트 자동 완성기를 구현하면 사용자는 이런 행동을 할 것이다
- 사용자 만족도가 증가한다
- 사용자 리텐션이 올라간다
- AI 사용 효용을 느낀 사용자는 더 복잡하고 정교한 질문을 한다
- 서비스에 대한 의존도가 높아진다
논리적 추론의 구조
- 이 가정은 사용자 행동의 선순환 구조를 전제한다.
- 자동 완성기가 질 좋은 프롬프트를 생성 → AI가 더 나은 답변 제공 → 사용자가 “이 AI는 똑똑하다”고 인식 → 더 어려운 질문도 시도 → 서비스 가치 체감 증가 → 재방문.
- 이는 단순한 희망사항이 아니라, 실제로 검증 가능한 가설이다.
비즈니스 메트릭으로 전환
각 가정은 측정 가능한 지표와 연결된다.
- “사용자 만족도 증가”
- CSAT(Customer Satisfaction Score): 사용자에게 직접 만족도를 물어보는 방식
- 1점(매우 불만) ~ 5점(매우 만족)
- 계산식: (만족 응답 수 / 전체 응답 수) × 100
- 보통 4-5점을 “만족”으로 분류
- 예: 100명 중 80명이 4-5점 → CSAT 80%
- NPS(Net Promoter Score)
- “이 서비스를 친구에게 추천하시겠습니까?”
- 0점(절대 안 함) ~ 10점(매우 추천)
- “이 서비스를 친구에게 추천하시겠습니까?”
- CSAT(Customer Satisfaction Score): 사용자에게 직접 만족도를 물어보는 방식
- “리텐션 상승” → DAU/MAU, 7일 재방문율
- “복잡한 질문 증가” → 평균 프롬프트 길이, 멀티턴 대화 비율
- “의존도 증가” → 주간 평균 사용 횟수, 구독 전환율
이런 지표를 A/B 테스트로 검증하면 프롬프트 자동 완성기의 실제 효과를 측정할 수 있다.
역설적 발견
- 흥미로운 점은 “복잡한 질문을 한다”는 것이 목표라는 점이다.
- 일반적으로 서비스는 사용을 “쉽게” 만들려 하지만, 여기서는 오히려 사용자가 더 “정교하게” 사용하도록 유도한다.
- 왜냐하면 정교한 질문을 할 수 있다는 것은 AI의 능력을 신뢰한다는 의미이고, 이는 장기적 사용자 가치를 높이기 때문이다.
- 단순한 질문만 하는 사용자는 언젠가 “AI가 한계가 있다”고 느끼고 떠난다.
1.3 프롬프트 자동 완성기 설계 과정
Practice
- 사용자 문제 개선을 위한 프롬프트 자동 완성기를 제작하기 위한 아이디에이션 시도
- 프롬프트 초안을 작성
- LLM과 프롬프트 자동완성기의 작동 구조를 그림으로 그리기
- 왜 “그림으로 그려보라”고 하는가?
- 프롬프트 엔지니어링은 단순히 텍스트를 쓰는 작업이 아닌 시스템 설계다.
- 사용자 입력 → 자동완성기 → LLM → 출력이라는 데이터 흐름을 시각화하지 않으면, 어디서 병목이 생기는지, 어떤 정보가 손실되는지 파악할 수 없다.
- 그림을 그리는 과정에서 “자동완성기가 원본 프롬프트를 완전히 대체하는가, 아니면 보조 정보로 추가하는가?” 같은 근본적 설계 질문이 명확해진다.
- 왜 “그림으로 그려보라”고 하는가?
아키텍처 설계의 핵심 선택
프롬프트 자동완성기 설계에는 두 가지 차원의 선택이 필요하다.
차원 1: 프롬프트 처리 방식
방식 1-A: 대체형
사용자 입력 → 자동완성기가 완전히 새로운 프롬프트 생성 → LLM에 전달
장점: 일관된 품질
단점: 사용자 의도가 왜곡될 위험
방식 1-B: 보강형
사용자 입력 → 자동완성기가 맥락 정보 추가 → (원본 + 추가정보)를 LLM에 전달
장점: 사용자 의도 보존
단점: 프롬프트가 길어져 비용 증가
실무에서는 보통 방식 1-B를 선택한다. 사용자가 “내가 쓴 질문이 무시당했다”고 느끼면 신뢰가 깨지기 때문이다.
차원 2: 사용자 인터페이스 설계
방식 2-A: UI 노출 + 사용자 확인
사용자 입력 → 자동완성 LLM → [UI에 표시] → 사용자 확인/수정 → 메인 LLM → 답변장점: 투명성 높음, 사용자 통제감 제공, 잘못된 추론 방지
단점: 추가 클릭 필요, 응답 시간 증가
사용 케이스: 전문 도메인, 고위험 상황, 사용자가 정확성을 중시하는 경우
방식 2-B: 자동 전달 (파이프라인)
사용자 입력 → 자동완성 LLM → [바로 전달] → 메인 LLM → 답변장점: 빠른 응답, UX 매끄러움, 추가 인터랙션 불필요
단점: 블랙박스, 잘못된 추론 시 사용자 혼란
사용 케이스: 일상적 질문, 저위험 상황, 속도가 중요한 모바일 환경
실무 선택 기준
- 초기 런칭: 방식 2-A (UI 노출) 권장 → 사용자 피드백 수집
- 성숙 단계: A/B 테스트로 전환율 비교 후 방식 2-B 검토
- 하이브리드: 사용자가 설정에서 “자동완성 미리보기” ON/OFF 선택 가능하게 구현
1.4 프롬프트 자동 완성 툴 제작
System Prompt
As a highly professional psychologist,
your task is to enhance my prompt for more effective responses
by anticipating my intentions.
Role
Kindly edit {{$my prompt}} in greater detail,
constructing complete sentences.
Please respond in Korean.
Specification
Use informal speech form, -해체(hae che) in Korean.
Include a role, situation and task within the prompt
if it is possible to generate.
Response
The prompt you provide should be limited to 1 to 3 sentences.
Provide only your response.1.4.1 Role 설정: “highly professional psychologist”
왜 심리학자를 선택했는가? 엔지니어나 작가가 아니라 심리학자를 선택한 이유는 “사용자의 의도를 추론”하는 것이 핵심이기 때문이다. 심리학자는 표면적 언어 뒤의 숨겨진 동기, 감정, 맥락을 읽어내는 전문가다. “개발자 공부”라는 짧은 입력 뒤에 “취업 불안”, “커리어 전환 고민”, “시간 부족” 같은 심리적 맥락이 숨어있다는 가정이다.
“highly professional”이라는 수식어는 단순히 품질을 높이는 게 아니다. LLM에게 전문성을 부여하면 더 신중하고 구조화된 출력을 생성하는 경향이 있다. “친근한 심리학자”가 아니라 “전문적인 심리학자”로 설정하면, 캐주얼한 추측이 아니라 체계적인 분석을 수행한다.
1.4.2 Task: “enhance my prompt” + “anticipating my intentions”
“enhance”는 단순한 확장이 아니라 “품질 향상”을 의미한다. 더 길게 만드는 게 아니라 더 효과적으로 만드는 것이다. “anticipating my intentions”는 핵심이다. 사용자가 명시하지 않은 숨은 의도를 추론하라는 지시다. 이는 “You have a mind”와 같은 맥락의 고급 기법이다.
1.4.3 Specification 1: “edit {{$my prompt}} in greater detail, constructing complete sentences”
대부분의 사용자 입력은 파편적이다. “개발자 공부”, “다이어트 방법”, “파이썬 에러” 같은 키워드 나열이다. “constructing complete sentences”는 이를 문법적으로 완전한 문장으로 재구성하라는 의미다. 이는 LLM의 성능을 크게 향상시킨다. LLM은 완전한 문장 구조에서 훨씬 정확한 답변을 생성하기 때문이다.
1.4.4 Specification 2: “Use informal speech form, -해체(hae che) in Korean”
한국어의 해체는 “~해”, “~야” 같은 형태로, 존댓말도 반말도 아닌 중간 톤이다. 이는 매우 전략적 선택이다. 반말은 너무 캐주얼해서 전문성이 떨어지고, 존댓말은 너무 격식 있어서 거리감이 생긴다. 해체는 “친근하지만 진지한” 톤을 만든다. 사용자가 AI를 “똑똑한 친구”로 인식하게 하는 최적의 톤이다.
1.4.5 Specification 3: “Include a role, situation and task”
이것이 프롬프트 자동 완성의 핵심 알고리즘이다. 좋은 프롬프트는 항상 세 가지 요소를 포함한다.
- Role: “너는 10년 경력 개발자야”
- Situation: “비전공자가 개발자 취업을 준비하는 상황에서”
- Task: “6개월 학습 로드맵을 단계별로 만들어줘”
사용자가 “개발자 공부”라고만 입력하면, 자동완성기는 이를 추론해서 위 세 요소를 포함한 완전한 프롬프트로 변환한다. “if it is possible to generate”라는 조건은 중요하다. 때로는 사용자 입력이 너무 모호해서 Role/Situation/Task를 추론할 수 없다. 이 경우 억지로 만들지 말고 기본적인 확장만 하라는 안전장치다.
1.4.6 Response 제약: “1 to 3 sentences”
왜 1~3문장으로 제한하는가? 이 제약의 의미는 선택한 아키텍처에 따라 다르다.
방식 2-A (UI 노출): 사용자 확인 최적화
사용자가 자동완성된 프롬프트를 UI에서 확인하는 경우:
- 문제 1: 자동완성기가 너무 긴 프롬프트 생성 → 사용자가 “내 질문이 이렇게 바뀌었어?”라고 당황
- 문제 2: 긴 텍스트는 모바일에서 읽기 어려움 (스크롤 필요)
- 해결: 1~3문장은 사용자가 한눈에 확인할 수 있는 길이면서도, Role-Situation-Task를 모두 담을 수 있는 최적 범위
이 방식에서는 “사용자 확인 가능성”이 핵심이다.
방식 2-B (자동 전달): Token 비용 최적화
자동완성된 프롬프트를 바로 메인 LLM에 전달하는 경우:
- 문제: 프롬프트가 길어지면 LLM API 비용이 증가 (Input Token 증가)
- 해결: 1~3문장 제약으로 최소한의 맥락 추가로 효과 극대화
- 트레이드오프: 너무 짧으면 맥락 부족, 너무 길면 비용 증가
이 방식에서는 “비용 대비 효과”가 핵심이다.
공통: 메타 설명 제거
“Provide only your response”는 메타 설명 제거 지시다.
❌ 나쁜 출력: “제가 당신의 프롬프트를 다음과 같이 개선했습니다: ‘비전공자가…’”
✅ 좋은 출력: “비전공자가 6개월 안에 웹 개발자로 취업하기 위한 학습 로드맵을 단계별로 알려줘”
순수하게 개선된 프롬프트만 출력해야, UI에 표시하거나 메인 LLM에 전달할 때 깔끔하다.
1.5 모델별 테스트 결과
1.5.1 GPT-4o mini 테스트
Query 1: “climate change에 대한 에세이 영어로 200자”
이 입력의 문제점은 명확하다.
(1) “climate change”가 너무 광범위하다. 원인? 영향? 해결책?
(2) “에세이”의 목적이 불명확하다. 학술적? 설득적? 정보 전달?
(3) “200자”가 한글 기준인지 영문 기준인지 모호하다.
자동완성기는 아마도 이렇게 변환했을 것이다:
“기후 변화가 현대 사회에 미치는 영향에 대한 설득력 있는 영문 에세이를 200단어로 작성해줘. 구체적인 사례를 포함해.”
- Role: 설득력 있는 영문 에세이
- Situation: 기후 변화가 현대 사회에 미치는 영향
- Task: 200단어 에세이
Query 2: “탕후루 만드는 법”
이 입력은 상대적으로 명확하지만, 여전히 맥락이 부족하다. 초보자용? 전문가용? 어떤 과일로?
자동완성기는 이렇게 확장했을 것이다:
“집에서 처음 만들어보는 사람도 쉽게 따라할 수 있는 딸기 탕후루 만드는 법을 단계별로 알려줘.”
Role: 초보자 가이드
Situation: 집에서 처음 시도
Task: 단계별 레시피
Query 3: “이 텍스트는 사회 복지 정책 평가 결과야. 데이터를 분석해줘.”
이 입력은 비교적 완성도가 높다. 맥락(사회 복지 정책)과 자료 유형(평가 결과)이 명시되어 있다. 하지만 여전히 “분석”이 모호하다. 통계 분석? 트렌드 파악? 문제점 도출?
자동완성기는 이렇게 정교화했을 것이다:
“사회 복지 정책 평가 데이터의 주요 트렌드와 개선점을 파악해서, 정책 입안자가 이해하기 쉬운 요약 리포트를 만들어줘.”
Role: 정책 분석
Situation: 정책 입안자용 리포트
Task: 트렌드 파악 + 개선점 도출
1.5.2 Claude 3.5 Sonnet 테스트
Query 1: “끝말 잇기를 하자”
이 입력은 명확한 Task만 있고 Role/Situation이 없다. Claude는 맥락을 어떻게 추론할까?
자동완성 결과: “한국어 단어로 끝말잇기 게임을 하자. 너가 먼저 단어를 제시하면 내가 이어갈게.”
Role: 게임 상대
Situation: 한국어 단어
Task: 끝말잇기
“너가 먼저”라는 순서 설정도 중요하다. 이게 없으면 서로 누가 먼저 시작할지 모호하다.
Query 2: “남자 친구 심리를 잘 모르겠어. 내 이야기좀 들어볼래?”
이 입력은 감정적 맥락이 강하다. 단순한 정보 요청이 아니라 상담이 필요한 상황이다.
자동완성 결과: “연애 심리 상담가 역할로, 내 남자친구 행동을 분석하고 조언을 줘. 먼저 상황을 설명할게.”
Role: 연애 상담가
Situation: 남자친구 행동 분석
Task: 조언 제공
“먼저 상황을 설명할게”는 대화 흐름을 설정하는 중요한 추가다.
Query 3: “John Robert의 Damn Bean을 한국어로 번역해줘”
이 입력은 Task는 명확하지만 번역의 성격이 불분명하다. 직역? 의역? 문학적 번역?
자동완성 결과: “John Robert의 ‘Damn Bean’ 원문의 뉘앙스를 살려서 자연스러운 한국어로 번역해줘. 원작의 톤을 유지하면서.”
Role: 전문 번역가 Situation: 원작 톤 유지 Task: 자연스러운 한국어 번역
1.6 테스트 시 주의사항
GPT-4o mini의 과도한 확장 경향
GPT-4o mini는 때때로 사용자 입력을 지나치게 해석해서 원래 의도와 다른 방향으로 확장하는 경향이 있다. 예를 들어 “개발자 공부”를 “프론트엔드 개발자가 되기 위한 React 중심 학습”으로 과도하게 구체화할 수 있다. 사용자는 백엔드에 관심 있을 수도 있는데 말이다.
해결 방법: “if it is possible to generate” 조건을 더 강화하거나, Temperature를 낮춰서 보수적으로 확장하게 만든다.
Claude의 맥락 과잉 해석
Claude는 감정적 단서를 민감하게 포착한다. “잘 모르겠어”라는 표현에서 불안감을 읽고, 때로는 사용자가 원하지 않는 감정적 조언을 추가할 수 있다. 사용자는 단순히 정보를 원했는데, Claude가 “힘들겠지만 괜찮아질 거야” 같은 위로를 덧붙이는 식이다.
해결 방법: “focus on task enhancement, not emotional support unless explicitly needed” 같은 제약을 추가한다.
일관성 검증의 중요성
같은 입력을 여러 번 테스트해봐야 한다. Temperature가 0이 아닌 이상, 매번 다른 결과가 나올 수 있다. “개발자 공부”를 10번 입력했을 때, 10번 모두 합리적인 확장이 나오는지 확인해야 한다. 1~2번은 괜찮은데 나머지가 엉뚱하면 프로덕션에 사용할 수 없다.
사용자 확인 단계의 필요성
자동완성된 프롬프트를 바로 LLM에 전달하지 말고, 사용자에게 먼저 보여주고 확인받는 UI가 필요하다. “이렇게 이해했는데 맞아요?” 같은 확인 단계가 있으면 사용자 신뢰도가 올라간다. 물론 이는 추가 클릭이 필요하지만, 잘못된 해석으로 엉뚱한 답변을 받는 것보다 낫다.
1.7 프롬프트 자동 완성기의 한계와 개선 방향
현재 프롬프트의 한계
- 맥락 정보 부족: 사용자의 배경, 전문성 수준, 과거 대화 이력이 없으면 정확한 추론이 어렵다.
- 도메인 특수성: “의학 용어 번역”같이 전문 도메인은 일반적인 자동완성으로 처리하기 어렵다.
- 다국어 처리: 한국어 특유의 존댓말/반말 구분, 해체 같은 미묘한 톤 조절이 다른 언어로 확장하기 어렵다.
개선 방향
- 사용자 프로필 통합: “비전공자”, “5년 경력 개발자” 같은 프로필 정보를 자동완성에 활용
- 도메인별 템플릿: 코딩, 글쓰기, 번역 등 도메인별로 특화된 확장 규칙 적용
- 학습 루프: 사용자가 자동완성 결과를 수정한 패턴을 학습해서 점진적 개선
비즈니스 임팩트 측정
자동완성기 도입 전후로 다음 지표를 비교해야 한다:
- 평균 프롬프트 길이 (짧음 → 중간)
- 첫 응답 만족도 (낮음 → 높음)
- 재질문 비율 (높음 → 낮음)
- 멀티턴 대화 비율 (낮음 → 높음)
이 네 가지가 모두 개선되면 자동완성기가 성공한 것이다.