The 'Prompt' Is Not a Skill — And We Need to Stop Pretending
Writing a prompt isn't engineering. It's typing. You type what you want. The AI figures out the rest...
프롬프트(AI에게 보내는 입력 지시문)를 작성하는 것은 엔지니어링이 아니다. 그냥 타이핑이다.
원하는 것을 입력하면 AI가 나머지를 처리한다. 그건 기술이 아니다. 불확실성을 절대 인정하지 않는, 매우 빠르고 매우 자신감 넘치는 인턴과 대화하는 것에 불과하다.
그런데도 우리는 스스로를 프롬프트 엔지니어라고 부르기 시작했다. LinkedIn에 올리고, 질문하는 방법을 아는 것이 만드는 방법을 아는 것과 같다고 행동하기 시작했다. 그렇지 않다.
진짜 기술은 — 언제나 중요했고, 언제나 존재했으며, 변하지 않은 — 무엇을 요청해야 하는지 아는 것이다. 답이 옳은지 아는 것이다. AI가 무엇을 가정하고, 무엇을 놓치고, 무엇을 조용히 망가뜨렸는지 아는 것이다.
프롬프트가 기술이 아니다. 판단력이 기술이다.
우리가 실제로 하는 일 #
실제 프롬프팅이 어떤 모습인지 솔직하게 보자.
채팅 창을 열고, 원하는 것을 설명하는 문장을 입력한다. AI가 코드를 작성한다. 잘못되거나 불완전하면, 수정하는 문장을 하나 더 입력한다. AI가 다시 시도한다. 작동하거나 포기하고 직접 작성할 때까지 반복한다.
그건 엔지니어링이 아니다. 그건 대화다.
엔지니어링에는 트레이드오프 이해가 필요하다. 특정 맥락에서 한 솔루션이 왜 다른 것보다 나은지 알아야 한다. 장애 모드를 예측하고, 변화를 위해 설계하고, 요구사항이 6개월 후에 바뀌어도 다른 사람이 유지보수할 수 있는 결정을 내려야 한다.
프롬프팅은 그 중 아무것도 필요하지 않다.
Photo by Markus Winkler on Pexels
우리가 스스로에게 하는 거짓말 #
거짓말을 솔직하게 말하자면: "나는 프롬프트 엔지니어다. 새로운 전문 기술을 개발했다."
그렇지 않다. 누구나 자연어로 사용할 수 있도록 엄청난 비용을 들여 설계된 기계와 대화하는 법을 배운 것뿐이다. 이 모델들의 핵심은 사용하는 데 특별한 지식이 필요 없다는 것이다.
AI에게 필요한 것은 프롬프트 엔지니어링 기술이 아니다. 판단력이다. AI가 작성한 코드가 실제로 옳은지 알아야 한다 — 문법적으로 유효한 것뿐만 아니라, 당신의 유스케이스, 제약 조건, 엣지 케이스에 맞는지. AI가 말하지 않고 만든 가정을 잡아내야 한다. "이 리스트가 비어있으면 어떻게 되지?"라고 물어야 한다. AI는 그 질문을 하지 않는다. 그냥 리스트에 항상 항목이 있다고 가정하고, 그 가정을 기반으로 코드를 작성하고, 빈 리스트를 가진 사용자가 엔드포인트를 건드릴 때까지 완전히 합리적으로 보이는 출력을 반환한다.
개발자와 코드 한 줄도 작성해본 적 없는 사람을 구분하는 것은 프롬프트가 아니다. 답으로 무엇을 할지 아는 것이다. 언제 답이 틀렸는지 아는 것이다. AI 출력의 어느 부분을 신뢰하고 어느 부분을 독립적으로 검증해야 하는지 아는 것이다.
그건 프롬프트 기술이 아니다. 개발 기술이다. 그리고 우리는 그것을 줄곧 가지고 있었다.
불편했던 그 순간 #
지난달 지인이 자리에서 이런 말을 했다. AI 도구를 몇 주 동안 써보고 흥분한 상태였다. "그러면 그냥 원하는 걸 입력하면 AI가 코드를 작성해준다는 거야?" 그렇다고 했다.
그 순간 예상치 못한 감정을 느꼈다. 당혹감이었다.
왜냐하면 그게 바로 내가 하는 일이기 때문이다. 원하는 것을 입력하고, 답을 검토하고, 관련 부분을 복사하고, 배포한다. 그 순간 깨달았다. 스택 트레이스가 뭔지도 모르고, 아무것도 디버깅해본 적 없고, "배포"가 파일을 이메일로 보내는 거라고 생각하는 그 지인도 같은 도구로 같은 순서의 단계를 따를 수 있다는 것을.
그래서 불편한 질문을 스스로에게 던졌다. 배경이 없는 사람이 같은 워크플로우를 따를 수 있다면, 나에게 실제로 가치 있는 것은 무엇인가?
솔직하게 앉아서 생각한 답: AI가 틀렸을 때를 안다. 다음에 물어야 할 질문을 안다. AI가 무엇을 가정했고 그 가정이 맞는지 안다. 어떤 솔루션이 부하 상황에서 문제를 일으키거나, 엣지 케이스에서 실패하거나, 유지보수가 악몽이 될지 안다.
그것들은 프롬프트 기술이 아니다. 엔지니어링 기술이다. 수년간의 좌절과 실패를 통해 쌓인 것들이다. 그리고 프롬프트 자체에서는 전혀 보이지 않는다.
진짜 기술이 무엇인지 #
프롬프팅은 입력 방법이다. 기술은 그것을 둘러싼 모든 것이다.
실제로 무엇을 요청해야 하는지 아는 것. "X를 하는 함수를 작성해줘"는 쉽다. 누구나 할 수 있다. "빈 입력, null 값, 형식이 잘못된 데이터를 처리하는 함수를 작성하고 어떤 가정을 하고 있는지 알려줘"는 무엇이 잘못될 수 있는지 알아야 한다. 그건 경험이 필요하다.
답이 옳은지 아는 것. AI는 항상 자신감이 있다. 자신감은 정확성과 상관관계가 없다. 자신감이 거짓말을 할 때를 알아야 한다 — 코드가 맞아 보이지만 미묘한 결함이 있을 때, 설명이 그럴듯하지만 틀렸을 때, 솔루션이 예제에서는 작동하지만 일반적인 경우에서는 실패할 때.
AI가 무엇을 가정했는지 아는 것. 이것이 가장 자주 발목을 잡는 부분이다. AI는 가정을 말해주지 않는다 — 그냥 만들고 넘어간다. 빈 리스트. null이 아닌 포인터. 항상 UTC인 타임존. 항상 이름이 있는 사용자. 그 가정들이 프로덕션에 도달하기 전에 잡아내는 것은 엔지니어링 기술이다.
AI를 완전히 무시할 때를 아는 것. 때로 AI는 기술적으로는 작동하지만 맥락상 틀린 솔루션을 제시한다 — 잘못된 아키텍처, 잘못된 추상화 수준, 특정 제약 조건에 맞지 않는 트레이드오프. 그것을 알아채려면 제안을 수용하는 것이 아니라 평가할 수 있을 만큼 시스템을 깊이 이해해야 한다.
이것들은 프롬프트 기술이 아니다. 개발자가 항상 필요로 해온 바로 그 기술들이다. 입력 방법이 바뀌었다. 필요한 판단력은 바뀌지 않았다.
프롬프팅은 쉽다. 판단력은 어렵다. 둘을 혼동하는 것을 멈춰야 한다.
Photo by Anna Tarazevich on Pexels
이게 단순한 말장난이 아닌 이유 #
프롬프팅을 기술이라고 부르는 것은 무해한 리브랜딩이 아니다. 실제 결과가 있다.
주니어 개발자들은 프롬프트 엔지니어링을 기반 기술처럼 배우라는 말을 듣는다 — 마치 자료구조, 디버깅, 시스템 설계, 사물이 어떻게 실패하는지 이해하는 것을 대체하는 것처럼. 그렇지 않다. 그럴 수 없다. 프롬프팅은 할 수 있지만 코드에 대해 추론할 수 없는 주니어는 출력을 빠르게 생성하고 문제를 느리게 잡는 주니어다.
회사들은 프롬프트 엔지니어를 채용하고 있다 — 판단력보다 입력 방법을 최적화하는 역할로. 기술이 아니라 도구를 중심으로 팀을 구성하고 있다.
그리고 개발자들은 인상적으로 들리지만 인터넷 접속이 가능한 누구나 할 수 있는 것을 전문 기술처럼 LinkedIn 프로필에 올리고 있다.
결과: 생성할 수 있지만 평가할 수 없는 업계 계층. 빠르게 배포할 수 있지만 망가졌을 때 디버깅할 수 없는. 어떤 프롬프팅 기법이 가장 잘 작동하는지에 대한 강한 의견과 코드가 실제로 왜 틀렸는지에 대한 취약한 직관을 가진.
빈 리스트 가정이 새벽 2시에 프로덕션을 다운시킬 때, 프롬프트는 구해주지 않는다. 디버깅 기술이 구해준다. 아키텍처적 직관이 구해준다. 이전에 데인 경험이 구해준다.
우리는 프롬프트 엔지니어가 아니다. AI를 도구로 사용하는 개발자다. 그 두 설명 사이의 거리는 보이는 것보다 훨씬 중요하다.
대신 하고 있는 것 #
AI를 그만두는 게 아니다. 모든 것을 처음부터 직접 작성하는 것으로 돌아가는 게 아니다. 그것도 또 다른 종류의 자기기만이 될 것이다.
하지만 프롬프팅을 의미 있는 기술이라고 부르는 것은 멈췄다. 타이핑이나 터미널 사용처럼 입력 방법으로 취급한다. 내가 개발한 역량이 아니라 도구와 대화하는 방법이다.
실제 판단이 필요한 것들에 집중한다: 아키텍처, 엣지 케이스, 장애 모드, 트레이드오프, 올바르게 보이는 출력에 숨겨진 가정들. 배포하기 전에 "AI가 무엇을 가정했는가?"를 묻는다. 자신감 있는 AI 출력을 아직 프로덕션에서 일해보지 않은 자신감 있는 주니어에게 주는 것과 같은 회의적 시선으로 대한다.
스스로에게 되새긴다: 타이핑은 엔지니어링이 아니다. 생각하는 것이다. 그리고 이력서에 프롬프트 엔지니어링을 올리지 않는다.
한 가지 질문 #
당신은 프롬프트 엔지니어인가?
아니면 개발자인가 — 진짜 기술, 진짜 판단력, 진짜 경험을 가진, 우연히 AI를 도구로 사용하는?
그 질문에 어떻게 답할지 나는 선택했다.
당신의 선택은?
이 글은 위 출처의 내용을 바탕으로 작성된 초안입니다. 원문의 의견과 정보를 그대로 전달하며, 별도의 견해를 포함하지 않습니다.