에이전트한테 일을 시키려면 LLM이 뭘 잘하고 뭘 못하는지부터 알아야 한다. 이걸 모르고 쓰면 되는 일을 안 된다고 포기하거나, 안 되는 일을 될 때까지 밀어붙이게 된다. LLM은 말(자연어)로 지시를 받고, 그 말이 구체적인 만큼만 정확하게 움직인다. 여기에 “엔지니어링”이라는 이름이 붙는 이유가 있다. 그냥 대화가 아니라, 원하는 결과가 나오도록 지시를 설계하는 기술이라서다. 그중 제일 앞에 오는 게 프롬프트 엔지니어링이다.
“지시는 구체적일수록 좋다.” 어디서 한 번쯤은 들어봤을 말이다. 그런데 에이전트를 직접 굴려보기 전까지는 이게 왜 진짜인지 잘 모른다.
모호하게 말하면 당장은 편하다. “이거 좀 고쳐줘.” 세 마디면 끝나니까. 반대로 구체적으로 쓰는 건 귀찮다. 파일 경로 찾아야 하고, 바꿀 값도 미리 확인해야 하고, 지시문이 세 줄씩 길어진다. 문제는 그 귀찮음을 건너뛴 다음이다. 에이전트가 뭘 고칠지 잘못 짚으면 결과를 보고 다시 설명해야 하고, 다시 기다려야 하고, 또 어긋나면 또 설명해야 한다. 짧게 말해서 아낀 시간이 재작업으로 몇 배가 되어 돌아온다. 모호한 한마디가 제일 비싼 지시다 — 말하는 순간의 시간이 아니라 나중에 되돌아오는 비용을 보면 그렇다.
예를 들어 “이 프로젝트 설정 파일 좀 고쳐줘”라고 하면, 에이전트는 프로젝트 안의 설정 파일 후보를 몇 개나 뒤져야 할지 모른다. package.json인지 .claude/settings.json인지 tsconfig.json인지부터 다시 물어야 하고, 잘못 짚으면 엉뚱한 파일을 고쳐놓는다. 대신 “@.claude/settings.json의 PreToolUse 훅 timeout을 20초에서 30초로 올려줘”라고 하면 파일도, 위치도, 바꿀 값도 이미 다 정해져 있다. 되물을 것도, 잘못 짚을 것도 없다.
구체적으로 지시하는 데는 손에 잡히는 방법이 몇 가지 있다.
파일을 말로 설명하지 않고 @로 직접 선택한다. “그 설정 파일 있잖아”가 아니라 @src/config.ts. 폴더 단위 작업이면 @로 폴더를 지정한다. 에이전트가 어디서부터 뒤져야 할지 헤매는 시간이 줄어든다. 기준이 있으면 기준을 말로 풀지 말고 그대로 준다. “적당히 정리해줘”가 아니라 실제 정책이나 숫자나 조건.
에러도 같은 결이다. “실행하니까 에러 나던데”라고 말로 설명하지 않고 에러 메시지를 통째로 붙여넣는다. 내가 요약하는 순간 정보가 깎인다. 원문이 제일 정확하다.
큰 작업은 바로 시키지 않는다. “어떻게 할 건지 계획부터 보여줘”라고 하면 방향이 어긋나기 전에 잡을 수 있다. 파일 열 개 고쳐놓은 다음에 “그게 아닌데”라고 하는 것보다, 계획 단계에서 한 줄 고치는 게 훨씬 싸다.
마지막으로 완료 기준. “뭘 보면 끝난 건지”를 지시에 같이 넣는다. “고치고 나서 테스트 돌려서 통과하면 완료” 같은 식으로. 이게 있으면 에이전트가 자기 결과물을 스스로 검증하고 끝낸다. 물론 그래도 최종 확인은 내 몫이다. 다만 최소한의 검증은 이미 끝난 상태로 받으니, 열자마자 에러 화면부터 보고 다시 지시하는 일이 줄어든다.
결국 구체적인 지시는 귀찮음을 미리 지불하는 일이다. 말할 때 조금 더 쓰고, 어긋난 결과를 보고 다시 설명하는 시간을 없앤다. 프롬프트 엔지니어링이라고 이름은 거창하지만, 시작은 이게 전부다.