프롬프트 엔지니어링은 증상이다 (괜찮다)

Source: Dev.to

Overview

Or: what this book actually teaches if you read it like an engineer, not a magician.

지난 포스트 이후 몇몇 사람들이 다음과 같은 변형을 달았습니다:

“똑똑한 사람, 하지만 프롬프트 엔지니어링은 실제 기술이야.”

맞아요.

그리고 나쁜 스키마를 보완하기 위해 SQL을 짜는 것도 마찬가지죠.

그렇다고 해서 그걸 커리어로 삼아야 한다는 뜻은 아닙니다.

최근에 Prompt Engineering (Lee Boonstra, Feb 2025)을 읽었는데—Chain of Thought, Tree of Thoughts, ReAct, temperature knobs, 그리고 아무것도 배포하지 않아도 생산성을 느끼게 하는 다이어그램이 가득한 책이었습니다.

이 글은 책을 깎아내리는 것이 아닙니다.
생산 현장에서 상처받은 사람들을 위한 읽기 가이드입니다.

What the Book Gets Right (Surprisingly Well)

이 책은 대부분의 AI 과대광고가 무시하는 사실을 솔직히 말합니다:

LLM은 예측 엔진이지, 사고를 하는 존재가 아니다.
토큰을 다음에 무엇이 올지 계속해서 추측한다. 정중하게.

그 외의 “추론”, “생각”, “결정” 등은 우리가 위에 얹는 스캐폴딩에 불과합니다.

그리고 책에서 다루는 기법들은?

• Chain of Thought
• Step‑back prompting
• Self‑consistency
• ReAct
• JSON schemas
• Output constraints

이것들은 “AI 마법 트릭”이 아니라 제어 시스템입니다.

만약 당신이 다음을 해본 적이 있다면:

• 불안정한 API를 재시도 로직으로 감쌌다
• 멱등성 키를 추가했다
• 나중에 폭발하지 않도록 응답을 스키마에 강제했다

축하합니다. 이미 프롬프트 엔지니어링을 이해하고 있는 겁니다. 그냥 다른 이름으로 부른 것뿐이죠.

Prompt Engineering Is Middleware With Vibes

책이 내게 와닿게 만든 재구성은 다음과 같습니다:

Prompt engineering is middleware for probabilistic systems.

그게 전부입니다. 그게 트윗이죠.

책에 나오는 모든 기법은 다음 문제들을 해결하기 위해 존재합니다:

• 비결정성
• 구조 부족
• 계약 부재
• 예측 불가능한 재시도
• 원하지 않은 부작용

다시 말해: 분산 시스템 문제.
하지만 로그 대신 문단을, 스택 트레이스 대신 신뢰도를 얻게 됩니다.

Why Prompt Engineering Feels So Powerful

많은 팀이 처음으로 자신의 모호함과 마주하게 되기 때문입니다.

예를 들어 이렇게 쓸 때:

“If values conflict, choose the most reasonable one”

모델이 똑똑해지는 것이 아니라, 그 충돌이 왜 발생했는지를 당신에게 묻는 것입니다.

책은 수백 페이지에 걸쳐 모호함에 대처하는 방법을 보여줍니다. 모호함을 없애려는 주장은 하지 않죠. 이것은 결함이 아니라 우연히 드러난 진실입니다.

The Hidden Lesson in the Book (Nobody Tweets This Part)

책에 나오는 최고의 프롬프트들은 공통점이 있습니다:

• 명확한 입력 형식
• 명시적인 스키마
• 좁은 책임 범위
• 결정론적 기대값
• 지루한 출력

즉, 진짜 교훈은:

“프롬프트 마법사가 되라”

가 아니라:

“당신의 시스템에 마침내 경계가 필요하고, AI는 더 이상 그것을 위조하게 두지 않는다.”

프롬프트 엔지니어링은 아키텍처를 대체하지 않습니다. 오히려 당신에게 설계를 강요합니다. 원하든 원하지 않든 말이죠.

When Prompt Engineering Actually Is the Right Tool

프롬프트 엔지니어링이 빛을 발하는 경우:

• 작업 자체가 애매모호할 때 (언어, 요약, 분류)
• 틀릴 비용이 낮을 때
• 출력이 권고성이고 권위적이지 않을 때
• 안전하게 재시도할 수 있을 때
• 결정론적이라고 가장하지 않을 때

반대로 다음 용도로 사용한다면:

• 비즈니스 규칙 강제
• 재무 의사결정
• 프로덕션 상태 변형
• 도메인 로직 대체

당신은 지능을 발견한 것이 아니라, 말을 할 수 있는 기술 부채를 발견한 것입니다.

The Takeaway

책을 읽으세요.

• 마법서처럼
• 지름길처럼
• 커리어 정체성처럼

읽지 말고, 새로운 실패 모드가 탄생하는 것을 지켜보는 시스템 엔지니어처럼 읽으세요.

프롬프트 엔지니어링이 당신의 아키텍처를 구원하지는 않지만, 더 나은 일을 합니다: 당신이 그것을 무시하는 것을 멈추게 합니다.

솔직히? 그래서 더 강력하게 느껴지는 걸 겁니다. 😎