기술 · July 21, 2026 · 8분 읽기

소프트웨어 엔지니어를 위한 프롬프트 엔지니어링: 거꾸로 하는 코드 리뷰로서의 프롬프팅

엔지니어에게 프롬프팅은 표현 요령이 아니라 시스템 설계이자 코드 리뷰입니다. 제약을 명시하고, 테스트를 포함하고, 출력을 읽고, 폐기된(deprecated) 호출을 잡아내세요. 실제 예제와 평가 방식을 담은 실용 가이드입니다.

엔지니어는 매 근무일마다 AI 어시스턴트와 함께 일한 최초의 전문가 집단이었으므로, 이 역량을 정확하게 짚어볼 가치가 있습니다. 그것은 영리한 프롬프트를 입력하고 요행을 바라는 일이 아닙니다. AI에서 진정한 지렛대 효과를 얻는 엔지니어는 프롬프팅을 여느 인터페이스처럼 다룹니다. 즉, 계약과 제약, 실패 모드를 정의한 다음 돌아온 결과를 검증합니다. 이 글은 역할별 프롬프트 엔지니어링 시리즈의 소프트웨어 엔지니어링 편이며, AI Sandbox가 드러내는 가장 명확한 것 중 하나입니다.

프롬프팅은 거꾸로 하는 코드 리뷰다

최근의 모든 연구에서 일관되게 유효한 모범 사례는 표면적으로는 지루합니다. 요청하기 전에 성공 기준과 제약을 명시하고, 모델에 구조화된 입력을 제공하며, 원하는 정확한 출력을 지정하는 것입니다. 프롬프트 엔지니어링은 '더 긴 프롬프트를 쓰는 것'이 아니라 '더 명확한 명세를 쓰는 것'이 되었습니다. 그래서 이는 엔지니어가 시스템 엔지니어처럼 사고하도록 강제합니다. 하지만 강한 사람과 약한 사람을 실제로 갈라놓는 부분은 코드가 나온 뒤에 일어납니다. 즉, 코드를 비판적으로 읽고 미묘한 문제를 잡아내는 것입니다 — 폐기된(deprecated) 호출, 드러냈어야 할 4xx를 삼켜버리는 재시도, 처리되지 않은 엣지 케이스 같은 것들이죠. 그것이 바로 코드에 적용된 AI 유창성입니다.

실제 예제

재시도 로직이 포함된 비동기 API 클라이언트를 어시스턴트에게 요청해 보세요. 약한 프롬프트는 '재시도로 사용자를 가져오는 함수를 작성해줘'입니다. 강한 프롬프트는 계약, 제약, 그리고 — 결정적으로 — 코드가 통과해야 하는 테스트를 못박습니다. 그런 다음 엔지니어는 결과를 읽고, 생성된 재시도 루프가 마땅히 예외를 던졌어야 할 404에서 백오프하고 있다는 것을 발견해 수정한 뒤, 테스트를 돌려 확인합니다.

## TASK
Write an async fetchUser(id) client method in TypeScript.

## CONSTRAINTS
- Modern async/await fetch — no deprecated request libraries
- Retry on 5xx and network errors only, never on 4xx
- Exponential backoff with jitter, max 3 attempts, 5s per-attempt timeout

## TESTS IT MUST PASS
- Returns parsed JSON on 200
- Throws immediately on 404 (no retry)
- Gives up after 3 failed attempts

## OUTPUT
Code first, then one line on any assumption you made.

• 좋은 방식: 요청을 제약하고, 모델에 테스트를 건네주고, 출력을 읽고, 폐기되었거나 안전하지 않은 코드를 잡아내고, 빠른 실행으로 검증한다.
• 약한 방식: '재시도가 있는 fetch를 작성해줘'를 붙여넣고, 처음 나온 그럴듯한 함수를 받아들여, 4xx 버그를 그대로 둔 채 배포한다.

실제로 판도를 바꾸는 모범 사례

• 길이보다 구조. 요청을 하나의 긴 문단으로 쓰는 대신 섹션 — 과제, 입력, 제약, 출력 형식 — 으로 나누세요. 추론 품질은 공간이 다하기 훨씬 전에 저하되는 경향이 있으므로, 방대한 것보다 간결하고 명확한 것이 낫습니다.
• 모델에 당신의 테스트를 건네세요. 요구사항만이 아니라 코드가 통과해야 하는 케이스를 포함하세요. 그러면 모델은 일반적인 기준이 아니라 당신의 기준에 맞춰 작성합니다.
• 코드보다 먼저 추론을 보여주게 하세요. 그러면 잘못된 가정이, 그 위에 세워진 구현을 다 읽어 내려가기 전에 눈에 보입니다.
• 테스트 스위트를 평가(eval)로 취급하세요. 출력은 그럴듯해 보인다고 끝난 것이 아니라, 통과했을 때 끝난 것입니다.

흔한 실패 모드

• 붙여넣고 배포하기: 읽어보지도 않고 자신만만해 보이는 코드를 신뢰하는 것.
• 모호한 요청: 제약도 없고 출력 형식도 없어서 모델이 추측하게 되고 — 그것도 일반적으로 추측하게 되는 것.
• 검증 단계 없음: 코드가 컴파일되니까 맞을 것이다 (안정적으로 맞지는 않습니다).

우리가 평가하는 방법

이 중 어느 것도 프롬프트 문법에 관한 퀴즈로는 측정할 수 없으며, 면접에서 AI를 금지해서는 아무것도 배우지 못합니다. 후보자를 그들이 실제로 사용할 도구가 갖춰진 현실적인 엔지니어링 과제에 앉히고, 그가 어떻게 지시하고, 읽고, 교정하는지 지켜봐야 합니다 — 이것이 바로 AI Sandbox 평가가 하는 일이며, AI 유창성을 하나의 축으로 채점하는 방식입니다. 강력한 소프트웨어 엔지니어 평가가 그 밖에 무엇을 다루는지, 왜 이것이 AI 네이티브 채용에서 직무를 정직하게 검증하는 방법인지 확인하거나, 역할에 맞춰 조율된 평가가 구성되는 과정을 지켜보세요.

가장 강한 엔지니어는 코드를 얻으려고 프롬프트하지 않습니다. 그들은 초안을 얻으려고 프롬프트한 다음, 여느 풀 리퀘스트에 가져갈 것과 똑같은 회의(懷疑)를 거기에 가져갑니다 — 그리고 바로 그 회의야말로 채용할 가치가 있는 것입니다.