제미나이와 챗GPT 중 뭐가 돈 될까? 수익 모델 비교 분석표

ChatGPT에 같은 질문을 해도 누군가는 보고서급 답변을 받고, 누군가는 교과서 복붙 수준을 받는 이유가 뭘까요? 3개월간 프롬프트만 파고든 끝에 알게 된 건, 질문의 구조가 답변의 질을 결정한다는 사실이었어요.

솔직히 처음엔 저도 “블로그 글 써줘”라고만 던졌거든요. 당연히 돌아오는 건 어디서 본 듯한 뻔한 문장의 나열이었죠. 그래서 프롬프트 엔지니어링이라는 걸 제대로 파보기로 했어요. 해외 논문도 찾아보고, Anthropic이나 OpenAI 공식 가이드도 뜯어봤는데요. 결론적으로 말씀드리면, 기법 자체는 어렵지 않아요. 근데 대부분이 “조합”을 모르더라고요.

누가 알려주지 않으면 영원히 모를 뻔했던 것들, 오늘 한 번에 풀어볼게요. 특히 역할 부여, 구조화 기법, Chain of Thought 같은 핵심 기법을 실제로 어떻게 조합하는지까지 다뤄봅니다.

같은 AI인데 왜 내 답변만 허접할까

AI한테 “마케팅 전략 알려줘”라고 물어보면 뭐가 나올까요. 교과서에서 튀어나온 듯한 4P 전략 설명이 나오거든요. 근데 “너는 10년 경력의 B2B SaaS 마케터야. 연매출 50억 규모의 스타트업이 시리즈 A 이후 고객 확보 비용을 30% 줄이려고 해. 현실적인 전략 3가지를 우선순위와 함께 제안해줘”라고 물으면? 완전히 다른 차원의 답이 나와요.

이게 바로 프롬프트 엔지니어링의 핵심이에요. AI는 질문이 모호하면 가장 일반적이고 안전한 답을 내놓도록 설계되어 있거든요. Google Cloud의 프롬프트 엔지니어링 가이드에서도 강조하는 부분인데, LLM은 입력의 구체성에 비례해서 출력의 품질이 올라간다는 거예요.

저도 처음 3주 정도는 “왜 남들은 잘 쓰는데 나만 안 되지?” 하면서 AI 모델 탓만 했어요. GPT-4로 바꿔볼까, Claude로 갈아탈까 고민했는데, 모델을 바꿔봤자 프롬프트가 구린 건 마찬가지더라고요.

진짜 전환점은 하나였어요. 내가 AI한테 뭘 원하는지 나 자신도 정확히 모르고 있었다는 사실을 깨달은 거죠. 프롬프트를 잘 쓴다는 건 결국 내 요구사항을 명확하게 정리하는 능력이에요. AI가 멍청한 게 아니라, 내 질문이 흐릿했던 겁니다.

역할 부여 하나로 답변 수준이 바뀐다

프롬프트 엔지니어링에서 가장 먼저 배우는 게 페르소나 기법, 흔히 “역할 부여”라고 하는 거예요. “너는 ~전문가야”라고 앞에 한 줄 붙이는 것만으로 답변의 깊이가 확 달라지거든요. 근데 여기서 많이들 실수하는 게, 역할을 너무 뭉뚱그려서 준다는 거예요.

“마케팅 전문가”보다 “B2B SaaS 분야에서 10년 경력의 그로스 마케터”가 훨씬 낫고, 여기에 “스타트업 환경에서 제한된 예산으로 성과를 만들어본 경험이 있는”까지 붙이면 더 좋아요. 구글의 프롬프트 엔지니어링 백서에서도 역할 지정의 구체성이 출력 품질과 직접 연결된다고 명시하고 있고요.

재밌는 건 역할 부여가 단순 포맷 변경이 아니라 AI의 “사고 프레임” 자체를 바꾼다는 점이에요. “의사”라고 역할을 주면 증상 기반으로 체계적으로 접근하고, “환자 경험을 많이 들어본 약사”라고 주면 실생활 중심의 조언이 나오거든요. 같은 건강 질문인데 관점이 완전히 달라져요.

한 가지 더, Reddit의 프롬프트 엔지니어링 커뮤니티에서 흥미로운 논의를 봤는데요. 지나치게 유명한 인물의 이름을 역할로 부여하면 오히려 성능이 떨어질 수 있다는 거예요. “일론 머스크처럼 생각해”보다는 구체적인 역량과 경험을 묘사하는 게 더 낫다는 결론이었죠. AI가 특정 인물의 공개 발언 패턴에 갇혀버리는 현상이 생기거든요.

구조화 기법, 구분자와 마크다운의 힘

프롬프트가 길어지면 AI가 헷갈리기 시작해요. “이게 지시사항이야, 아니면 참고 자료야?” 구분이 안 되는 거죠. 이걸 해결하는 게 바로 구분자(Delimiter)예요.

마크다운의 ###이나 —를 써서 섹션을 나누거나, XML 태그로 각 영역을 감싸는 방법이 있어요. 특히 Anthropic은 공식적으로 XML 구조 프롬프트를 핵심 전략으로 권장하고 있거든요. Claude 사용자라면 꼭 알아둬야 할 부분이에요.

예를 들어볼게요. 그냥 “아래 텍스트를 요약하고 핵심 키워드를 뽑아줘. 텍스트는 이거야…”라고 쓰는 것과, 이렇게 쓰는 것의 차이가 꽤 커요.

구조화된 프롬프트 예시를 보면, 먼저 task 태그 안에 수행할 작업을 넣고, input 태그 안에 분석할 텍스트를 넣고, output_format 태그 안에 원하는 출력 형태를 지정하는 식이에요. 이렇게 하면 AI가 “아, 작업은 이거고, 재료는 이거고, 결과물은 이 형태로 내면 되는구나” 하고 한 번에 파악하거든요.

IBM의 프롬프트 엔지니어링 가이드에서도 구조화된 입력이 모델의 지시사항 이해도를 높인다고 강조하고 있어요. 특히 복잡한 작업일수록 효과가 극대화된다고요. 제가 직접 비교해봤을 때, 1,000자 이상의 텍스트를 분석시키는 경우 구조화 여부에 따라 핵심 포인트 추출 정확도가 체감상 2배 이상 차이났어요.

Chain of Thought와 Few-shot, 진짜 차이 나는 기법 둘

프롬프트 고급 기법 하면 항상 나오는 두 가지가 있어요. Chain of Thought(CoT)와 Few-shot 프롬프팅. 이 두 개만 제대로 써도 AI 활용 수준이 확 올라가거든요.

CoT는 “단계별로 생각해봐”라는 한마디를 추가하는 거예요. 이게 별거 아닌 것 같은데, 수학 문제나 논리 추론에서 정확도가 급상승해요. IBM의 CoT 가이드에 따르면, 복잡한 추론 문제에서 CoT를 적용하면 AI가 중간 사고 과정을 명시적으로 보여주면서 오류를 스스로 잡아내는 효과가 있다고 해요.

Few-shot은 원하는 답변의 예시를 2~3개 먼저 보여주는 거예요. “이런 식으로 답해줘”라고 패턴을 학습시키는 거죠. 회의록 요약을 시킬 때 “좋은 요약 예시”를 2개 먼저 보여주면, 그 포맷과 깊이를 그대로 따라오거든요.

구분	Chain of Thought	Few-shot
핵심 원리	단계별 추론 유도	예시 기반 패턴 학습
효과적인 상황	수학, 논리, 분석 작업	글쓰기, 분류, 포맷 지정
난이도	한 줄 추가로 즉시 적용	좋은 예시 준비 필요
주의점	단순 작업에선 오히려 비효율	편향된 예시가 결과를 왜곡

근데 여기서 많이 놓치는 게 있어요. 이 둘은 배타적이지 않다는 거예요. CoT 예시를 Few-shot으로 보여주는 조합이 단독 사용보다 훨씬 강력하거든요. “이 문제를 이렇게 단계적으로 풀었어(예시). 이제 비슷한 문제를 같은 방식으로 풀어봐”라고 하면, AI가 추론 방식 자체를 학습해요.

제가 재무 데이터를 분석시킬 때 이 조합을 처음 써봤는데, 단순 CoT만 썼을 때는 중간에 계산 실수가 종종 있었거든요. 근데 “올바른 분석 과정 예시” 하나를 앞에 붙이니까 같은 유형의 실수가 거의 사라졌어요. 이게 한 달 정도 반복해보니까 확실히 체감되는 차이였습니다.

초보가 반복하는 프롬프트 실수 5가지

프롬프트 엔지니어링을 공부하면서 커뮤니티 글을 수백 개 읽었는데요. 초보자들이 공통적으로 빠지는 함정이 있더라고요. 저도 전부 겪어본 것들이라 정리해봤어요.

첫 번째, 질문이 너무 모호한 경우예요. “좋은 글 써줘”는 AI 입장에서 뭘 원하는 건지 알 수가 없어요. 주제, 톤, 길이, 타겟 독자, 목적까지 명시해야 해요. LinkedIn의 한 프롬프트 전문가는 “모호한 질문은 모호한 답변을 만든다”고 딱 잘라 말하더군요.

두 번째는 한 번에 너무 많은 걸 요구하는 거예요. “시장 조사하고, 경쟁사 분석하고, 마케팅 전략까지 세워줘”를 한 프롬프트에 넣으면 각각의 품질이 다 떨어져요. 차라리 나눠서 물어보는 게 훨씬 낫거든요.

세 번째가 의외로 많은데, 원하지 않는 걸 말하지 않는 실수예요. “설명해줘, 근데 전문 용어는 쓰지 마”처럼 제외 조건을 명시하면 원치 않는 결과를 미리 차단할 수 있어요. Negative prompting이라고도 하는데, 이걸 모르면 매번 수정 요청을 반복하게 돼요.

네 번째, 맥락(Context) 제공을 빠뜨리는 거예요. AI는 여러분의 상황을 모르잖아요. “우리 회사”라고만 쓰면 AI가 알 수 없어요. 업종, 규모, 현재 상황을 간단히라도 알려줘야 해요. Cisco의 프롬프트 가이드에서 강조하는 “Contextual Priming”이 바로 이거예요.

다섯 번째, 출력 형식을 지정하지 않는 거예요. 표로 받을지, 글로 받을지, 불릿 포인트로 받을지를 미리 말해야 해요. 안 그러면 AI가 매번 다른 형태로 결과를 내놓아서 후처리에 시간이 더 들어요.

고급 기법 조합, 실전에서 이렇게 씁니다

기법 하나하나를 아는 것과 실제로 조합해서 쓰는 건 완전히 다른 얘기예요. 고수들의 프롬프트를 뜯어보면 대부분 3~4가지 기법이 자연스럽게 섞여 있거든요.

제가 실제로 자주 쓰는 조합을 공개해볼게요. 첫 번째 단계로 역할을 부여하고, 두 번째로 XML이나 마크다운으로 구조를 잡고, 세 번째로 출력 형식을 지정하고, 네 번째로 제약 조건과 제외 조건을 넣어요. 마지막으로 필요하면 CoT나 Few-shot을 추가하는 식이에요.

이걸 “메가 프롬프트”라고 부르는 사람도 있는데요. 핵심은 순서예요. 역할이 가장 먼저 와야 하고, 그다음에 맥락, 그리고 구체적 지시, 마지막에 형식 지정. 이 순서가 뒤바뀌면 AI가 혼란스러워하는 경우가 있어요.

그리고 최근에는 “Self-Consistency”라는 기법도 알아두면 좋아요. 같은 질문에 대해 여러 답변을 생성하게 한 뒤 가장 일관된 답을 고르는 방식인데, 중요한 의사결정에 AI를 활용할 때 특히 유용해요. Cisco의 고급 프롬프트 가이드에서도 “정확도가 중요한 작업에서 신뢰도를 높이는 핵심 기법”으로 소개하고 있고요.

또 하나 팁을 드리자면, “반복적 프롬프팅(Iterative Prompting)”을 적극적으로 활용하세요. 한 번에 완벽한 결과를 뽑으려는 욕심을 버리는 거예요. 첫 답변을 받고 “여기서 두 번째 항목을 더 구체적으로 풀어줘” 식으로 점진적으로 다듬는 게 실제로는 훨씬 빠르고 결과물 품질도 좋아요.

한 가지 반전인데요, 저도 처음엔 “프롬프트를 길게 쓸수록 좋은 거 아닌가?” 싶었거든요. 근데 3개월 써보니까 꼭 그렇지 않더라고요. 핵심은 길이가 아니라 필요한 정보가 빠짐없이, 명확한 구조로 들어갔느냐예요. 불필요하게 긴 프롬프트는 오히려 AI를 혼란스럽게 만들어요. 이게 초반 한 달간의 가장 큰 깨달음이었습니다.

자주 묻는 질문