프롬프트 엔지니어링은 당신의 아키텍처를 고쳐주지 않는다
Source: Dev.to
몇 년마다 우리 업계는 오래된 진리를 다시 발견하고 그것을 새것처럼 가장한다.
- 깨끗한 코드.
- 마이크로서비스.
- DevOps.
- 이제: 프롬프트 엔지니어링.
갑자기 2019년에 단일 CRUD 앱을 배포한 사람들이 다음과 같은 트윗을 한다:
“The problem isn’t your system. It’s your prompts.”아니요. 문제는 여전히 여러분의 시스템입니다. 프롬프트 엔지니어링은 은탄환이 아니며, 이미 감염된 아키텍처 상처에 적용되는 매우 비싼 임시방편입니다.
판타지
환상은 다음과 같습니다:
- 뒤죽박죽인 백엔드
- 일관성 없는 API
- 명확한 도메인 경계가 없음
- 비즈니스 로직이 컨트롤러, 크론 잡, Slack 메시지에 흩어져 있음
하지만…
✨ AI를 추가합니다 ✨
✨ 프롬프트를 다듬습니다 ✨
✨ 맨 위에 “당신은 시니어 엔지니어입니다” 라고 적습니다 ✨
…그리고 마법처럼 지능이 전기처럼 시스템을 관통합니다.
하지만 소프트웨어는 그렇게 동작하지 않습니다. 어떤 것이든 그렇게 동작하지 않습니다.
Reality Check: AI Enters Your System
An LLM doesn’t see your product. It sees:
- Whatever JSON you remembered to pass
- Whatever context fits into a token window
- Whatever half‑written schema someone added at 2 am
So when your AI “makes a bad decision,” it’s usually doing exactly what you asked — inside a broken abstraction.
프롬프트 엔지니어링 vs. 구조적 문제
프롬프트가 숨기고 있는 것을 솔직히 말해보자:
- ❌ 도메인 경계 누락 – “사용자의 의도를 신중히 추론해 주세요.”
- ❌ 일관성 없는 데이터 모델 – “필드가 누락된 경우 최선의 판단을 사용하세요.”
- ❌ 진실의 출처 없음 – “여러 값이 충돌하면 가장 합리적인 것을 선택하세요.”
- ❌ 다섯 군데에 흩어진 비즈니스 로직 – “아래 800 토큰에 설명된 회사 정책을 따르세요.”
이것은 AI 지능이 아니다. 자동완성에 건축적 결정을 외주하는 것이다.
분산 시스템 농담 (농담이 아닌 경우)
When you build AI agents, you quickly learn something uncomfortable:
AI agents are just distributed systems that can talk back.They have:
- State (that you pretend is stateless)
- Latency (that you ignore)
- Failure modes (that logs can’t explain)
- Side effects (that happen twice)
So when your agent:
- double‑charges a user
- retries an action incorrectly
- or confidently does the wrong thing
That’s not “AI being unpredictable.” It’s classic distributed‑systems behavior, now narrated in natural language.
“하지만 우리는 가드레일이 있다”
모두가 이렇게 말합니다. 가드레일은 훌륭합니다. 안전벨트도 마찬가지죠. 하지만 안전벨리는 다음을 해결하지 못합니다:
- 스티어링 휠이 없는 경우
- YAML로 엮인 엔진
- 분위기로 결정된 로드맵
오늘날 대부분의 가드레일은 단지:
- 더 많은 프롬프트
- 더 많은 조건문
- “확신이 서지 않으면 사용자에게 물어보라”는 것
어느 순간, 여러분은 시스템을 구축하는 것이 아니라 그것과 협상하고 있는 겁니다.
인기 없는 진실
AI는 건축을 대체하지 않는다. 오히려 증폭시킨다.
좋은 건축은 AI를 지루하고, 예측 가능하며, 신뢰할 수 있게 만든다.
나쁜 건축은 AI를 마법처럼 보이게 만든다—생산 단계에 들어가기 전까지, 규모가 커지기 전까지, 비용이 발생하기 전까지, 사용자가 실제로 무언가를 할 때까지.
그래서 AI 데모는 놀라워 보이지만 AI 제품은 … 취약하게 느껴진다.
왜 이런 일이 계속 일어나는가
Because prompt engineering is:
- 빠른
- 눈에 보이는
- 트윗하기 쉬운
Architecture is:
- 느린
- 보이지 않는
- 실패했을 때만 눈에 띄는
So we optimize for prompts. We ignore boundaries. We ship “intelligence” on top of entropy. And then we blame the model.
시니어 개발자의 시각
만약 여러분의 AI 시스템이 다음과 같은 요구를 한다면:
- 비즈니스 규칙을 설명하기 위해 2,000 토큰짜리 프롬프트가 필요함
- “정확히 맞추기” 위해 지속적인 재시도가 필요함
- 중요한 결정마다 인간 검토가 필요함
여러분에게는 AI 문제가 아니라, 이제 영어로 말하는 아키텍처 문제가 있습니다.
최종 생각
프롬프트 엔지니어링은 여러분의 아키텍처를 고치지는 못합니다. 하지만 그것은 여러분의 아키텍처를—생산 환경에서 자신 있게, 크게—드러내게 합니다. 솔직히 말해서? 그것이 지금까지 AI가 우리에게 해준 가장 유용한 일일지도 모릅니다.