GPT 활용법, 결국 프롬프트가 아니었다 — 전문가 사례에서 본 차이

ChatGPT 활용 사례, 레이서·유전학자·래퍼는 AI에 무엇을 물을까?

남들의 대화를 보니, GPT가 가려는 방향도 조금 보였다

요즘 AI 소식을 보면 주로 이런 이야기가 눈에 들어옵니다.

어느 모델이 더 똑똑한지, 토큰 가격이 얼마나 내려갔는지, 사용량은 언제 초기화되는지.

저도 그렇습니다. 모델 선택창과 사용량 화면을 꽤 열심히 들여다봤습니다.

그런데 이번에는 조금 다른 안내를 봤습니다.

“승려, 유전학자, 자동차 경주 선수가 자신의 대화를 공유합니다.”

조합부터 독특합니다.

레이서와 유전학자와 스님이 같은 서비스를 사용한다니, GPT는 도대체 직업이 몇 개인 걸까요.

이 내용은 OpenAI 커뮤니티팀이 발행하는 ChatGPT for Pros의 전문가 활용 사례입니다. 실제 이용자들이 업무에서 어떤 질문을 하는지 소개하는 시리즈입니다.

처음에는 흔한 사용 후기 모음이라고 생각했습니다.

그런데 읽다 보니 모델 성능표보다 더 재미있는 부분이 있었습니다.

같은 ChatGPT를 쓰는데, 사람마다 맡기는 일이 정말 다르다는 것.

그리고 이 사례들을 굳이 모아서 보여주는 OpenAI의 방향도 조금 보였습니다.

반응형

레이서는 “운전을 잘하는 법”보다 달라진 조건을 물었다

프로 자동차 경주 선수 Sara Choi의 사례입니다.

그녀는 익숙한 후륜구동 드리프트 차량과 다른 사륜구동 차량으로 빙판 경주를 준비하면서, 기존 경험과 새 환경의 차이를 ChatGPT에 물었습니다. 별도 인터뷰에는 후원 제안서 구성과 자동차 콘텐츠 기획에 활용한 사례도 소개돼 있습니다.

제가 흥미롭게 본 것은 질문의 출발점입니다.

막연히 “운전 잘하는 법을 알려줘”가 아닙니다.

이미 아는 조건과 앞으로 마주할 조건을 비교해달라는 요청입니다.

이 방식은 개발자인 저에게도 익숙합니다.

새 서버로 옮기거나 다른 프레임워크를 사용할 때, 모든 것을 처음부터 배워야 하는 것은 아닙니다. 기존에 알던 것 중 무엇이 그대로 통하고, 무엇을 다르게 생각해야 하는지가 궁금합니다.

레이서에게는 차량과 노면의 차이였고, 저에게는 운영체제와 실행환경의 차이일 수 있습니다.

이 사례를 제 업무로 바꿔보면 이런 질문이 됩니다.

“기존 환경에서는 이렇게 운영했어. 새 환경에서는 무엇이 달라지고, 예전 방식을 그대로 가져가면 어디에서 문제가 생길까?”

GPT가 핸들을 대신 잡는 이야기는 아닙니다.

새로운 조건을 만나기 전에, 머릿속 지도를 정리하는 용도에 더 가깝습니다.

철거 전문가는 건물보다 서류부터 정리했다

철거 전문가 James Costello는 도면을 첨부하고 철거 범위와 폐기물의 대략적인 물량을 정리해달라고 요청했습니다.

콘크리트와 포장재, 석재를 구분하고 계산에 사용할 가정도 제시합니다. 사례에 등장하는 30%는 철거 후 부피 증가를 반영하기 위한 가정이지, 모든 견적에 일괄적으로 붙이라는 이익률이 아닙니다.

여기서 인상적인 것은 전문가가 계산 기준을 제공한다는 점입니다.

“이 공사 견적 알아서 내줘”로 끝내지 않습니다.

무엇을 나눠 계산할지, 어떤 가정을 적용할지 알고 있는 사람이 AI에 정리를 맡깁니다.

그의 다른 활용 사례에는 작업 지침과 현장 설명 자료, 비용 정리도 있습니다. 전문 업무 자체뿐 아니라 그 주변에 붙는 문서 작업을 줄이는 방식입니다.

이 대목은 꽤 공감됐습니다.

개발자의 업무도 코드 작성만 있는 것은 아닙니다.

요구사항을 정리하고, 작업 내용을 설명하고, 변경점을 문서로 남기고, 다른 사람에게 인수인계해야 합니다.

정작 하고 싶은 일은 따로 있는데, 그 일을 설명하는 문서가 하루를 채울 때도 있습니다.

그런 의미에서 이 사례를 제 식으로 요약하면 이렇습니다.

AI가 건물을 대신 철거한 것이 아니라, 전문가 앞에 쌓인 서류더미부터 줄여주는 것.

생각보다 현실적인 생산성 이야기입니다.

유전학자는 자기 분야에 다른 도구를 연결했다

유전학자 Katsuhiko Hayashi가 공유한 질문은 상미분방정식, ODE 모델을 난소의 난모세포 소모 예측에 어떻게 활용할 수 있는지에 관한 것이었습니다.

이것은 AI가 연구 결과를 대신 확정했다는 사례가 아닙니다.

자신의 연구 문제를 다른 분야의 수학적 도구로 바라보려는 질문입니다.

저는 여기에서 AI 활용의 또 다른 면을 봤습니다.

우리는 자기 분야의 문제는 잘 알아도, 그 문제를 풀 때 사용할 수 있는 모든 방법을 알지는 못합니다.

개발 중 만난 문제가 통계로 풀릴 수도 있고, 운영상 반복되는 일이 데이터 분석 과제가 될 수도 있습니다.

그럴 때 AI에 기대할 수 있는 것은 정답 하나뿐만이 아닐 것 같습니다.

“이 문제를 어떤 틀로 바라볼 수 있을까?”

“내가 놓치고 있는 접근 방법은 무엇일까?”

전문지식을 대체하기보다 다른 분야로 넘어갈 때 질문을 정리하는 연결고리로 쓰는 방식입니다.

래퍼는 가사보다 티켓 판매 데이터를 가져왔다

래퍼 OZworld의 사례에서는 투어 자료를 첨부하고, 티켓 판매가 부진한 이유에 대한 가설과 대응 계획을 요청합니다.

즉시 실행할 일, 2주 안에 할 일, 2개월 단위로 볼 일을 나누고, 개선 여부를 판단할 지표와 위험요소까지 정리하도록 했습니다.

래퍼가 AI를 쓴다고 하면 가사나 라임부터 떠올리기 쉽습니다.

그런데 이번에는 공연 운영입니다.

무대 위에서는 라임을 맞추고, 무대 뒤에서는 판매 지표를 맞추는 겁니다.

이 사례에서 특히 마음에 든 것은 ‘원인’을 확정하라고 하지 않고 ‘가설’을 제시하라고 요청한 부분입니다.

판매가 부진한 이유를 자료 몇 개만 보고 단정하기는 어렵습니다. 먼저 가능한 설명을 나누고, 무엇부터 시험하며, 결과를 어떻게 확인할지 정하는 편이 더 현실적입니다.

블로그에도 그대로 응용해볼 수 있겠습니다.

“조회수 올리는 법 알려줘”보다, 제가 가진 방문·유입 자료를 바탕으로 어떤 문제가 있을지 가설을 나누고 작은 실험을 정하는 방식입니다.

다만 이 사례가 곧바로 티켓 판매 증가를 증명하는 것은 아닙니다.

여기서 확인할 수 있는 것은 문제를 어떤 구조로 분석하도록 요청했는지입니다.

성공 비법보다 참고하기 좋은 질문법에 가깝습니다.

스님은 오히려 “아직 번역하지 말라”고 했다

안내 제목에 등장한 승려의 사례도 원문에서 확인할 수 있었습니다.

Shoukei Matsumoto는 불교 개념을 일본어에서 영어로 옮길 때, 먼저 의미가 사라지거나 왜곡될 부분을 찾아 자신에게 질문하도록 요청했습니다. 곧바로 번역하지 말라는 조건이 붙어 있습니다.

이 질문은 짧지만 꽤 인상적입니다.

AI를 잘 쓰는 것이 반드시 더 빨리 결과물을 뽑아내는 일만은 아니라는 생각이 들었습니다.

오히려 이런 부탁도 가능하니까요.

“일단 만들지 말고, 우리가 잘못 이해할 부분부터 확인하자.”

개발에서도 필요한 말입니다.

요구사항이 불분명한데 구현부터 시작하면, 빠르게 만들어낸 결과물을 다시 빠르게 뜯어고치게 될 수 있습니다.

가끔은 AI에게 가속페달이 아니라 브레이크 역할을 부탁하는 편이 낫겠습니다.

스님 사례에서 얻은 팁이 “일단 멈추고 의미부터 확인하자”라니, 묘하게 잘 어울립니다.

728x90

공통점은 화려한 프롬프트가 아니었다

직업은 제각각이지만, 제가 읽은 질문들의 구조는 비슷했습니다.

내 상황을 설명하고, 가진 자료를 주고, 필요한 결과의 형태를 정합니다.

레이서는 자신이 익숙한 조건과 새 조건을 구분했습니다.

철거 전문가는 계산에 사용할 가정을 제시했습니다.

래퍼는 자료와 시간 범위, 확인할 지표를 지정했습니다.

이 사례들이 제게 주는 힌트는 “비밀 프롬프트를 외우자”가 아닙니다.

내 일을 조금 더 구체적으로 설명해보자는 쪽입니다.

예를 들어 아래 두 질문은 원하는 결과가 다르게 보입니다. 제가 블로그 작업을 위해 새로 구성해본 예시입니다.

“블로그 잘하는 방법 알려줘.”

그리고:

“최근 글들의 유입 자료를 정리했어.
검색으로 들어오는 글과 그렇지 않은 글을 비교해줘.
원인은 단정하지 말고 가설로 구분하고, 이번 주에 수정해볼 글 세 개와 확인할 지표를 제안해줘.”

두 번째는 길지만, 제가 무엇을 하려는지 훨씬 분명합니다.

다만 구체적으로 묻는다고 틀리지 않는 것은 아닙니다. OpenAI도 파일 분석 결과를 사용할 때 생성된 계산, 출력과 가정을 확인하라고 안내합니다.

좋은 질문은 검토를 없애주는 주문이 아니라, 검토할 만한 결과에 가까워지는 출발점이라고 생각합니다.

OpenAI가 이런 사례를 모으는 이유도 조금 보인다

여기부터는 사례를 보고 제가 읽은 방향입니다.

OpenAI가 전달하고 싶은 메시지는 단순히 “우리 모델이 똑똑합니다”에 그치지 않는 것 같습니다.

“당신이 이미 하고 있는 일에도 이 도구가 들어갈 자리가 있습니다.”

레이서, 철거 전문가, 연구자, 음악가를 나란히 보여주는 이유도 여기에 있다고 봅니다.

독자가 자기 직업과 똑같은 사례를 찾지 못하더라도, 질문하는 방식을 가져갈 수 있습니다.

공연 티켓 분석은 블로그 유입 분석으로 바뀔 수 있습니다.

도면에서 물량을 정리하는 일은 개발 요구사항에서 작업 범위를 나누는 일로 바뀔 수 있습니다.

번역 전에 의미 손실을 확인하는 일은 구현 전에 요구사항의 모호함을 확인하는 일로 바뀔 수 있습니다.

실제로 OpenAI의 사례 모집 페이지는 사용자에게 처음 어떤 질문을 했는지뿐 아니라, 그 대화가 무엇을 성취하거나 이해하는 데 도움이 됐는지를 함께 묻습니다. 제출 자료의 교육·마케팅 활용에 대한 동의도 받습니다.

결과 화면만 보여주는 광고와는 조금 다른 접근입니다.

물론 이것도 제품 홍보입니다. 다만 제가 보기에는 “이 기능이 있습니다”보다 “이런 상황에서 쓸 수 있습니다”가 훨씬 와닿습니다.

메뉴판을 보여주는 것과, 누가 무엇을 맛있게 먹었는지 들려주는 것의 차이랄까요.

GPT의 방향은 ‘답변’에서 ‘업무 결과물’ 쪽으로 보인다

이 사례 모음만으로 OpenAI의 모든 전략을 설명할 수는 없습니다.

하지만 공식 제품 발표와 함께 보면 방향은 비교적 일관돼 보입니다.

OpenAI는 ChatGPT Work를 소개하면서 앱과 파일의 정보를 모아 문서, 표, 발표자료 같은 결과물을 만들고, 여러 단계의 작업을 이어가는 도구로 설명했습니다. 중요한 행동의 승인과 진행 방향 조정은 사용자가 할 수 있도록 한다는 설명도 함께 제시했습니다.

제가 읽은 변화는 이렇습니다.

무엇을 아는지 답하는 AI에서, 내가 가진 자료로 무엇을 만들어낼지 함께 진행하는 AI로.

“마케팅이 뭐야?”에 답하는 데서 멈추지 않고, 내 자료를 바탕으로 실행안을 정리합니다.

“이 개념을 설명해줘”에서 더 나아가, 내 문제에 적용할 때 필요한 조건을 살펴봅니다.

단순히 말을 잘하는 것보다 업무의 다음 단계로 연결되는 결과를 만드는 것이 중요해지는 느낌입니다.

이 변화가 반가우면서도, 동시에 사용자의 역할도 더 분명해집니다.

어떤 자료를 줄지, 어디까지 맡길지, 무엇을 결과로 받을지, 어떤 부분을 직접 확인할지 정해야 합니다.

AI가 할 수 있는 일이 많아질수록, 사용자가 해야 하는 결정까지 전부 사라지는 것은 아닌 셈입니다.

그렇다고 Pro를 결제하면 전문가가 되는 것은 아니다

여기서는 살짝 브레이크를 걸고 싶습니다.

이번 자료는 전문가들의 활용 사례입니다. 하지만 이런 사례를 봤다고 같은 플랜을 결제하면 같은 수준의 결과가 따라오는 것은 아닙니다.

레이서는 차량과 경기를 알고 있습니다.

철거 전문가는 어떤 계산 가정이 필요한지 알고 있습니다.

연구자는 자신이 검토할 문제를 알고, 공연을 준비하는 사람은 일정과 예산을 알고 있습니다.

AI에게 전달되는 자료 안에 이미 사람의 경험이 들어 있습니다.

저는 이 지점이 중요하다고 생각합니다.

좋은 모델을 쓰는 것도 도움이 되겠지만, 내가 무엇을 알고 무엇을 모르는지 정리하는 일도 필요합니다.

또 소개된 사례를 ‘모든 질문이 정확했고, 실제 성과까지 검증됐다’는 뜻으로 읽어서는 안 됩니다.

현장 안전이나 연구처럼 판단의 무게가 큰 영역은 전문가의 검토와 실제 자료 확인이 필요합니다. 표가 그럴듯하다고 계산 가정까지 맞는 것은 아닙니다.

OpenAI 도움말도 스캔 자료나 복잡한 이미지 속 숫자는 정확히 읽지 못할 수 있다며, 정확한 수치가 중요하면 구조화된 표나 텍스트 자료를 사용하고 결과를 검토하도록 안내합니다.

AI가 도면을 읽어줬다고, 제가 갑자기 철거 견적의 최종 책임자가 될 수는 없습니다.

그럴듯한 답변과 믿고 실행할 수 있는 판단 사이에는 여전히 확인할 일이 남습니다.

내 업무에도 한 가지씩 가져와보면 되겠다

이번 사례를 보면서 또 새로운 도구를 결제해야겠다는 생각보다는, 지금 쓰는 도구에 질문을 조금 다르게 해봐야겠다는 생각이 들었습니다.

개발자라면 코드 생성만이 아닙니다.

배포 전 확인할 항목을 정리하거나, 장애 로그에서 원인과 추정을 구분하거나, 인수인계 문서에서 빠진 설명을 찾는 데 써볼 수 있겠습니다.

블로그를 쓴다면 제목을 만드는 것에서 끝내지 않고, 독자가 헷갈릴 부분이나 자료가 부족한 주장을 먼저 찾아달라고 할 수도 있습니다.

처음부터 대단한 자동화를 만들 필요는 없을 것 같습니다.

저라면 이렇게 시작하겠습니다.

“내가 반복해서 하는 작업이 하나 있어.
목표와 자료, 지금 쓰는 방식을 설명할 테니 AI가 도울 부분과 내가 직접 판단할 부분을 나눠줘.
부족한 정보는 추측하지 말고 먼저 물어봐줘.”

다른 사람의 직업을 따라 할 필요는 없습니다.

그 사람이 자기 일을 질문으로 바꾸는 방식을 가져오면 됩니다.

결국 남들의 대화가 모델 성능표보다 도움이 될 때가 있다

레이서는 달라진 주행 조건을 물었습니다.

철거 전문가는 도면과 물량을 정리했고, 연구자는 다른 분야의 도구를 연결해봤습니다. 래퍼는 공연 판매 계획을, 스님은 번역하기 전에 확인할 의미를 물었습니다.

다들 같은 대화창을 열었지만, 맡긴 일은 달랐습니다.

이 사례들을 보고 제가 느낀 GPT의 방향은 모두를 같은 방식으로 일하게 만드는 것보다, 각자가 하는 일의 옆에 들어가려는 것에 가깝습니다.

그래서 사용자인 저도 질문을 조금 바꿔보려고 합니다.

“GPT로 뭘 만들 수 있지?”도 좋지만,

“내가 이미 하는 일에서, 어디를 함께 정리하면 편해질까?”

그쪽이 더 작고 현실적인 출발점일 수 있겠습니다.

남들이 AI로 대단한 일을 한다고 조급해할 필요는 없습니다.

레이서는 경주를 준비하고, 연구자는 연구를 하고, 저는 제가 만들던 프로그램과 쓰던 글을 조금 더 잘 마무리하면 됩니다.

모델 이름과 사용량을 확인하는 것도 중요합니다.

그런데 이번에는 게이지를 보기 전에, 실제로 덜어내고 싶은 일 하나부터 찾아보려고 합니다.

GPT의 직업을 하나 더 늘리는 셈입니다.

이번 직함은 거창할 필요 없습니다.

‘내가 미뤄둔 일 같이 정리하는 사람’ 정도면 충분하겠습니다.