채용 · July 21, 2026 · 9분 읽기

직무별 프롬프트 엔지니어링: 잘한다는 것의 기준

직무별 프롬프트 엔지니어링은 핵심 채용 역량이지만, '잘한다'는 기준은 엔지니어, 애널리스트, 고객 지원 담당자, SDR, PM, 채용 담당자마다 다릅니다. 직군별 허브 가이드입니다.

← 채용의 다섯 가지 기둥: 평가가 실제로 측정하는 것의 일부

1년 전만 해도 프롬프트 엔지니어링은 틈새 전문 분야처럼 들렸습니다. 이제는 키보드를 사용하는 거의 모든 직무의 기본 역량이 되었습니다 — 채용 담당자와 인재 리더에게는 측정할 수 있는 가장 중요한 신호 중 하나입니다. AI의 실수를 그대로 내보낼 것인지, 아니면 잡아낼 것인지를 예측하기 때문입니다. 하지만 대부분의 채용팀이 놓치는 것이 있습니다. 직무별 프롬프트 엔지니어링에서 '잘한다'는 기준은 직무마다 다릅니다. 강한 엔지니어를 구별하는 것과 강한 고객 지원 담당자를 구별하는 것은 다릅니다. 이 글은 우리의 직군별 클러스터를 위한 허브입니다 — 각 포지션에서 '잘한다'는 것이 실제로 무엇을 의미하는지, 그리고 채용하는 직무에 대해 더 깊이 알아볼 곳을 안내하는 실용적인 가이드입니다.

프롬프트 엔지니어링은 하나의 역량이 아닙니다 — 직무에 따라 형태가 다릅니다

기반이 되는 역량은 보편적입니다. 도구에 명확한 맥락과 제약 조건을 제공하고, 돌아온 결과를 검증하고 수정하는 것이죠. 이것은 AI Fluency의 일부이며, 가장 강력한 신호는 항상 동일합니다 — AI가 자신 있게 틀렸을 때를 포착하는 것입니다. 하지만 과제와 실패 방식은 직무마다 다릅니다. 그렇기 때문에 표현 기법은 거의 예측력이 없고, 실제 직무와 유사한 과제는 훨씬 높은 예측력을 가집니다. 아래는 우리가 평가하는 여섯 개 직군에서 이것이 어떻게 나타나는지, 그리고 각 직군별 심층 가이드 링크입니다.

프롬팅이 채용 신호가 된 이유

지난 10년 동안 대부분의 시간 동안, 후보자가 업무에서 사용하는 도구는 평가에서 보이지 않았습니다. 결과물을 측정하고 역량을 추론했습니다. AI 도구가 그 깔끔한 경계를 허물었습니다. 자신감 있어 보이는 결과물이 후보자 자신의 신중한 작업일 수도 있고, 미묘하고 비용이 큰 오류를 범한 모델에서 검토 없이 붙여넣은 것일 수도 있습니다. 이 두 결과의 차이가 정확히 프롬프트 엔지니어링이 측정하는 것입니다. 그럴듯한 답변을 생성할 수 있는지가 아니라, 좋은 답변과 그럴듯한 답변을 구별할 수 있는지입니다.

그렇기 때문에 프롬팅은 조용히 평가할 가치가 가장 높은 것 중 하나가 되었습니다. 모델을 무비판적으로 신뢰하는 사람을 채용하면 그 사람의 실수를 전달하는 채널을 채용한 것이고, 모든 결과물을 검증할 초안으로 취급하는 사람을 채용하면 배수기를 채용한 것입니다. 이 차이는 이력서에 드러나지 않고, AI 사용 방법에 대한 대화에서도 거의 드러나지 않습니다 — 사람들은 자신이 실제로 그런 것보다 훨씬 더 자주 신중하다고 설명합니다. 실제 과제에서 작업하는 것을 관찰할 때 드러납니다. 이것이 직접 평가해야 한다는 주장 전체입니다.

보편적 역량, 그 다음 직무별 차이

모든 강한 프롬프트는 아래에 동일한 형태를 가지고 있습니다. 후보자는 모델이 추측할 수 없었을 맥락을 제공하고, 중요한 제약 조건을 명시하고 — 결정적으로 — 안도감이 아닌 의심으로 결과를 읽습니다. 직무별로 차이가 나는 지점은 '틀렸다'는 것이 어떻게 보이는지, 그리고 놓쳤을 때 얼마나 비용이 큰지입니다. 엔지니어의 실수는 컴파일되어 버그로 출시됩니다. 애널리스트의 실수는 이사회 자료의 숫자가 됩니다. 고객 지원 담당자의 실수는 이미 좌절한 고객에게 전달됩니다. 검증 능력은 보편적이지만, 후보자가 그 능력을 갖추고 있는지는 실제 직무에서 나오는 실패 방식을 포착하게 해야만 알 수 있습니다.

소프트웨어 엔지니어

재시도 로직이 포함된 비동기 API 클라이언트를 작성해달라고 AI에게 요청해보세요. 강한 후보자는 제약 조건을 미리 명시합니다 — 최신 비동기 패턴, 올바른 예외에 대한 명시적 오류 처리 — 생성된 코드를 읽고, 미묘한 문제를 포착합니다. 더 이상 사용되지 않는 호출, 잘못된 오류를 삼키는 재시도 로직, 누락된 엣지 케이스. 그런 다음 수정하고 테스트합니다. 여기서 좋은 프롬팅은 코드 리뷰와 분리할 수 없습니다. 소프트웨어 엔지니어 평가에서 테스트할 내용을 더 확인하세요.

• 강함: 요청에 제약 조건을 설정하고, 결과물을 읽고, 더 이상 사용되지 않거나 안전하지 않은 코드를 포착하고, 빠른 테스트로 검증합니다.
• 약함: 생성된 함수를 그대로 붙여넣고, 처리되지 않은 엣지 케이스 전체와 함께 내보냅니다.

데이터 애널리스트

SQL 쿼리를 요청해보세요 — 예를 들어, 내부 테스트 계정을 제외한 월별 순매출 — 또는 결과 해석을 요청해보세요. 강한 후보자는 프롬프트에 지표와 제외 조건을 정의하고, 이미 알고 있는 내용과 대조해 수치를 점검하고, 자신 있지만 오해를 불러일으키는 집계에 의문을 제기합니다 — 보고서에 그대로 붙여넣지 않습니다. 프롬팅 역량과 분석 판단력은 동일한 근육입니다. 더 많은 내용은 데이터 애널리스트 평가에서 확인하세요.

• 강함: 지표와 제외 조건을 명시하고, 결과물을 점검하고, 데이터가 뒷받침하지 않는 수치를 불신합니다.
• 약함: 그럴듯한 쿼리를 받아들이고, 조용히 맞지 않는 수치를 보고합니다.

고객 지원

불만을 가진 고객에게 보낼 답장을 AI에게 초안 작성하도록 요청해보세요. 강한 후보자는 관련 정책과 원하는 어조를 제공하고, 정확성을 확인하고, 로봇적이거나 무시하는 느낌의 표현을 부드럽게 하고, 모델이 슬쩍 넣은 과도한 약속을 제거합니다. 고객 지원에서 프롬프트는 업무의 절반에 불과합니다 — 편집에서 판단력이 드러납니다. 고객 지원 평가를 확인하세요.

• 강함: 정책과 어조를 제공하고, 정확성을 검증하고, 진정한 공감으로 조정하고, 과도한 약속을 제거합니다.
• 약함: 정책상 틀리거나 어조가 어긋난 일반적인 AI 답변을 그대로 보냅니다.

영업 개발 담당자 (SDR)

특정 페르소나를 대상으로 한 콜드 이메일을 요청해보세요. 강한 후보자는 실제 맥락을 도구에 제공합니다 — 구매자가 누구인지, 가치 제안, 명확한 요청 하나 — 결과물을 개인화하고, 바쁜 VP가 실제로 읽을 만한 길이로 다듬고, 나가기 전에 예비 고객에 관한 허구의 '사실'을 잡아냅니다. 프롬프트가 준비를 하고, 판단력이 신뢰성을 유지합니다. 더 많은 내용은 영업 개발 평가에서 확인하세요.

• 강함: 맥락을 제공하고, 개인화하고, 명확한 요청으로 다듬고, 조작된 세부 사항을 포착합니다.
• 약함: 때로는 조작된 사실이 포함된 일반적인 템플릿 대량 발송을 합니다.

프로덕트 매니저 (PM)

스펙 초안이나 우선순위 결정을 요청해보세요. 강한 PM은 문제와 제약 조건을 명확히 구성하고, AI를 활용해 빠른 출발점을 얻고, 그런 다음 실제 제품 판단력을 적용합니다 — 결함 있는 가정을 포착하고, 모델이 과도하게 추가한 범위를 줄이고, 초안을 그대로 내보내는 것이 아니라 사용자와 지표에 근거를 두는 것이죠. 프로덕트 매니저 평가를 확인하세요.

• 강함: 문제를 구성하고, AI를 초안 작성에 활용하고, 판단력을 적용합니다 — 잘못된 가정을 포착하고, 실제 목표와 연결합니다.
• 약함: 제품적 사고 없이 AI 생성 스펙을 그대로 내보냅니다.

채용 담당자

AI에게 아웃리치 메시지나 스크리닝 루브릭 초안을 작성하도록 요청해보세요. 강한 채용 담당자는 직무 맥락과 필수 신호를 제공하고, 결과물의 편향, 일반적인 채우기 문구, 실제로 사실이 아닌 직무 관련 주장을 확인하고 — 후보자가 신뢰할 수 있는 내용으로 다시 씁니다. 여기서 잘 프롬팅하는 것은 또 다른 형태의 인재 판단력입니다. 모델이 추측하기 전에 좋은 것이 무엇인지 아는 것이죠. 채용 담당자 채용 방법에서 채용 측면에 대해 더 알아보세요.

• 강함: 직무 맥락과 신호를 제공하고, 편향과 채우기 문구를 걸러내고, 모든 주장을 사실로 유지합니다.
• 약함: 직무를 과장하고 스팸처럼 읽히는 일반적인 AI 작성 대량 메시지를 보냅니다.

더 깊이 알아보기: 직무별 완전 가이드

각 직군은 자체적인 심층 가이드를 갖습니다 — 모범 사례, 실제 작성된 프롬프트 예시, 강함과 약함의 신호, 그리고 평가 방법:

• 소프트웨어 엔지니어를 위한 프롬프트 엔지니어링 — 역순 코드 리뷰로서의 프롬팅.
• 데이터 애널리스트를 위한 프롬프트 엔지니어링 — 정밀한 정의, 그 다음 수치 불신.
• 고객 지원을 위한 프롬프트 엔지니어링 — 초안은 쉽고, 편집이 핵심 업무.
• 영업 개발을 위한 프롬프트 엔지니어링 — 맥락을 넣고, 신뢰성을 뽑아내라.
• 프로덕트 매니저를 위한 프롬프트 엔지니어링 — AI가 초안을 쓰고, 판단력이 결정한다.
• 채용 담당자를 위한 프롬프트 엔지니어링 — 인재 판단력, 모델에 적용.

팀이 평가에서 흔히 범하는 두 가지 실수

첫 번째 실수는 프롬프트 퀴즈입니다 — 후보자에게 요청을 어떻게 표현할지 설명하게 하거나, 프롬팅 기법에 대한 지식으로 점수를 매기는 것입니다. 이는 어휘력을 측정하는 것이지 판단력을 측정하는 것이 아니며, 이 주제에 대한 글을 몇 편 읽은 사람이라면 누구든 쉽게 속일 수 있습니다. 두 번째 실수는 반대 방향의 과잉 수정입니다. 부정행위가 걱정되어 평가에서 AI를 완전히 금지하는 것이죠. 이는 오늘날의 방식이 아닌 2년 전 직무를 테스트하는 것이며, 잘못된 후보자를 걸러냅니다 — 다른 모든 사람이 이미 사용하는 도구를 활용하지 못하는 사람들을요.

두 실수 모두 공통 원인을 가지고 있습니다. 프롬팅을 아는 것이 아닌 하는 것으로 취급하지 않는 것입니다. 해결책은 AI에 관한 지식 테스트를 그만하고, 실제 직무의 실패 방식을 담은 과제에서 AI와의 협업을 관찰하기 시작하는 것입니다. 이 재정의는 무결성에 대한 걱정도 해소해줍니다. AI 사용이 예상되고 과제가 직무별 생성으로 만들어지면, 좋은 결과에 이르는 가장 빠른 경로는 진정한 역량이기 때문입니다 — AI 생성 평가에서 부정행위를 방지하는 우리 접근 방식의 논리와 같습니다.

평가 방법

프롬프트에 관한 퀴즈로는 이 중 어떤 것도 측정할 수 없고, AI를 금지해서는 분명히 측정할 수 없습니다. AI 도구가 제공된 환경에서 후보자에게 실제 직무와 유사한 과제를 주고, 어떻게 작업하는지 관찰해야 합니다 — 이것이 정확히 AI Sandbox 평가가 하는 일이며, AI Fluency가 하나의 기둥으로 측정되는 방식입니다. 실제로 수행되는 직무를 테스트하는 정직한 방법 — AI 네이티브 채용의 핵심 아이디어입니다. 또한 더 넓은 그림 안에 위치합니다. 프롬팅은 독립적인 기법이 아니라 후보자 평가의 다섯 기둥 중 하나입니다.

AI Sandbox는 직무 맞춤형 과제에서 실제 협업을 관찰하기 때문에, 동일한 기반 신호 — 이 사람이 모델이 자신 있게 틀렸을 때 알아채는가 — 가 채용하는 모든 포지션에서 드러납니다. 직무별로 프롬팅이 어떻게 맞는지 보여주는 직무 맞춤형 평가가 구성되는 과정을 관찰할 수 있고, 더 넓은 프레임워크를 먼저 원한다면 AI Fluency 채용 가이드에서 시작할 수 있습니다.

평가를 구축할 때 실용적인 주의사항이 있습니다. 과제를 지나치게 구조화하고 싶은 충동을 참으세요. 후보자가 수행해야 할 모든 제약 조건과 모든 확인 사항을 명시하면, 그들을 대신해 프롬팅을 해준 것이며 아무것도 배우지 못합니다. 신호는 과제 설명이 현실적으로 느슨할 때 그들이 무엇을 추가하고 무엇에 의문을 제기하는지에 있습니다 — 실제 업무에서 직면하는 것과 동일한 모호함입니다. 좋은 프롬프트 엔지니어링 과제는 테스트처럼 보이지 않고 화요일 오전처럼 보입니다. 실제 문제, 모두가 실제로 사용하는 도구, 그들이 도구를 주도하는지 아니면 도구가 그들을 주도하는지 드러낼 충분한 공간.

이 방식으로 평가하면, 프롬프트 엔지니어링은 유행어가 아니라 업무 결과물에 대한 가장 정직한 예측 지표 중 하나가 됩니다. 위의 클러스터에서 채용 중인 직무를 선택하고, 심층 가이드를 읽으면, 첫 번째 후보자가 앉기 전에 '잘한다'는 것이 무엇을 의미하는지 정확히 알게 됩니다.

프롬프트 엔지니어링은 채용하는 표현 기법이 아닙니다. AI가 자신 있게 틀린 상황에서의 판단력이며 — 테이블에 앉은 모든 포지션에서 다르게 보입니다.