데이터 문제 해결에 2시간이면 될 걸 프롬프트로 3주 동안 땜질한 개발자
the developer who spent three weeks making prompts work around a data problem that took two hours to fix
핵심 요약
프롬프트 엔지니어링으로 근본적인 데이터 문제를 덮으려다 시간만 낭비한 사례를 통해, 문제의 근원을 파악하는 중요성을 강조함.
- 프롬프트 맹신 — 근본적인 데이터 구조 문제를 해결하지 않고 프롬프트로 땜질하려 함.
- 기술 부채 — 프롬프트로 문제를 숨기면 시스템이 더 취약해지고 기술 부채가 쌓임.
- 문제 정의 — 제대로 정의된 문제는 절반은 해결된 것이나 다름없음.
- 업스트림 해결 — 프롬프트 수정 전 데이터 레이어에서 해결할 수 있는 문제인지 확인해야 함.
met a developer about three months ago — working on a customer-facing AI feature at a mid-size company.
his prompts were genuinely good. careful role framing, layered context injection, a retry loop that sampled multiple outputs and selected for coherent ones. i've seen a lot of prompt work. his was among the more thoughtful.
the underlying problem was that customer records had inconsistent field naming. some had `customer_name`. some had `customerName`. some had just `name`. a few had nothing.
he'd been running the feature for three weeks. most of that time was spent improving prompts to handle all four cases gracefully. special-case logic inside the instructions. fallback phrasing for when the field wasn't there.
i asked if he'd considered normalizing the field names at the data layer instead.
there was a pause. the kind of pause that happens when you've been living inside a solution so long you stopped questioning whether the problem was where you thought it was.
two hours later, the data was normalized. he deleted 60% of the prompt.
i think about this interaction more than i'd expect. prompt engineering is legitimately useful. it's also a very good tool for making bad data inputs tolerable, for papering over schema inconsistencies, for making LLMs absorb organizational dysfunction rather than fixing it.
the better you get at it, the better you get at tolerating problems that could be fixed upstream. that's not a bug in the skill. it's just a thing to watch for.
the question i now ask before touching a prompt: is this a prompt problem, or is the prompt compensating for something else?
