AI에게 일을 시킬 때 처음 배우는 게 프롬프트 엔지니어링입니다. 저도 그렇게 시작했죠. 그런데 지금은 프롬프트를 잘 쓰는 데 시간을 거의 안 씁니다. 대신 규칙을 파일에 적습니다. 7일 사이에 무슨 일이 있었던 걸까요? 그 기록입니다.
먼저 용어부터. 프롬프트 엔지니어링은 AI에게 주는 지시문을 효과적으로 설계하는 일입니다. 구체적으로 말하기, 단계를 나눠 요청하기, 역할과 출력 형식을 지정하기 같은 원칙이 알려져 있고, 이건 지금도 유효합니다.
다만 한 번 묻고 한 번 답받는 상황을 전제한다는 한계가 있습니다. 클로드를 만든 앤트로픽은 컨텍스트 엔지니어링 문서에서 이 둘을 구분합니다. 프롬프트 엔지니어링은 “효과적인 지시문을 어떻게 쓸 것인가”에 초점이 있는 반면, AI가 여러 단계를 스스로 밟는 에이전트 방식에서는 시스템 지시문·도구·외부 데이터·대화 기록까지 전체를 관리해야 한다는 거죠. 지시문 한 줄을 다듬는 것보다, 매 단계에서 무엇을 읽히느냐가 결과를 좌우한다는 쪽에 가깝습니다.
저는 이 말을 읽고 이해한 게 아니라, 같은 설명을 매번 반복하다 지쳐서 알게 됐습니다.
프롬프트 엔지니어링을 매번 처음부터 다시 하고 있었습니다
세션이 바뀌면 앞의 대화가 사라집니다. 그래서 같은 설명을 계속 다시 했습니다.
예를 들어 네이버 검색광고 API를 쓰려면 고객 ID가 필요한데, 광고주센터에 크게 표시된 번호가 아니라 다른 메뉴에 있는 값을 써야 합니다. 틀리면 인증 실패만 뜨고 원인은 안 알려줍니다. 이걸 한 번 알아낸 뒤에도, 다음 작업에서 또 설명하고 있었습니다.
지시문을 아무리 정교하게 써도 그 문장은 그 자리에서만 삽니다. 이게 첫 번째 벽이었습니다.
두 번째 벽은 더 이상했습니다. 지시가 길고 그럴듯할수록 결과도 그럴듯해 보여서, 제가 검증을 덜 하게 됐습니다. 잘 쓴 프롬프트가 오히려 방심을 만든 셈이죠.
규칙을 파일 하나에 고정했더니
그래서 매번 말하는 대신, 프로젝트에 규칙 파일을 하나 두고 거기에 적기 시작했습니다. 작업할 때 항상 읽히는 파일입니다.
7일간 이 파일이 이렇게 자랐습니다.
| 날짜 | 줄 수 |
|---|---|
| 7월 15일 | 47 |
| 7월 19일 | 51 |
| 7월 20일 | 58 |
| 7월 21일 | 98 |
| 7월 22일 | 181 |
늘어난 내용의 대부분은 기능 설명이 아니라 이미 밟은 함정과 그렇게 정한 이유입니다. 앞서 말한 고객 ID 문제도 “이 값이 맞고 저 값은 아니다, 틀리면 이런 증상이 난다”로 적혀 있습니다. 이제 그 설명을 다시 하지 않습니다.
여기서 하나 배운 게 있습니다. 결론만 적으면 소용이 없습니다. “A로 하라”만 적어 두면 다음에 “B가 더 낫지 않나”라는 논의를 처음부터 다시 하게 됩니다. 그래서 판단 근거를 같이 적습니다. 문서가 길어지는 대신 같은 논쟁이 반복되지 않습니다.
반복 절차는 스킬로, 반복 실수는 메모리로
규칙 파일 하나로는 부족한 게 두 가지 있었습니다.
하나, 작업 절차입니다. 글감 고르기, 검수 돌리기, 마무리 점검처럼 순서가 정해진 일은 규칙에 섞어 두면 묻힙니다. 그래서 절차별로 따로 묶어 이름을 붙였습니다. 지금 다섯 개가 있고, 짧은 건 23줄 긴 건 90줄입니다. 필요할 때 이름으로 부르면 그 절차서가 읽힙니다.
둘, 반복한 실수입니다. 이건 프로젝트 밖에도 남아야 해서 별도로 기록합니다. 지금 여섯 개 중 두 개가 제가 같은 실수를 반복한 기록입니다. 하나는 2차 자료를 인용했다가 틀렸던 일, 다른 하나는 코드만 고치고 문서를 안 고쳐 안전장치가 꺼져 있던 일입니다.
정리하면 이렇게 나뉩니다.
- 항상 지켜야 할 것 → 규칙 파일
- 순서가 있는 작업 → 스킬
- 반복한 실수 → 메모리
다만 파일에 적어도 안 지켜지는 구간이 있었습니다
좋게만 끝나면 광고니까 실패도 적습니다.
규칙 파일에 분명히 적어 뒀는데도 지켜지지 않은 적이 있습니다. 규칙은 최신인데 그 규칙을 실행하는 절차서가 낡아 있었고, 그 틈에서 검사 하나가 통째로 비활성화됐습니다. 화면에는 계속 “통과”만 떴습니다.
원인은 단순했습니다. 규칙을 적어 두는 것과 그 규칙이 실제로 읽히는 자리에 있는 것은 다르죠. 지금은 작업을 마칠 때마다 규칙과 절차서가 서로 어긋나지 않았는지 확인하는 단계를 넣었습니다.
코드를 모르는 사람이 시작하는 순서
제가 겪은 것을 순서로 줄이면 이렇습니다. 도구가 무엇이든 같습니다.
- 같은 설명을 두 번 했다면 그때 파일로 옮기세요. 세 번째부터 시간이 남기 시작합니다.
- 결론이 아니라 이유를 적으세요. 이유가 없으면 다음에 같은 논의를 다시 합니다.
- 순서가 있는 작업은 따로 묶으세요. 규칙에 섞으면 묻힙니다.
- 적어 둔 게 실제로 읽히는지 가끔 확인하세요. 적어만 두고 안 읽히면 없는 것과 같습니다.
프롬프트를 잘 쓰는 기술이 쓸모없다는 얘기가 아닙니다. 한 번 물어보고 끝나는 일에는 여전히 그게 전부입니다. 다만 AI에게 계속되는 일을 맡기기 시작하면, 잘 쓴 문장 하나보다 어디에 무엇을 적어 두었는지가 결과를 더 크게 바꿉니다.
이 글에서 다룬 규칙 파일과 스킬은 하네스 엔지니어링이라 부르는 것의 일부입니다. 거기서는 같은 이야기를 “AI가 틀렸을 때 어디서 걸리는가” 쪽에서 다뤘습니다. 처음이시라면 AI 에이전트가 무엇인지부터 보시면 순서가 자연스럽고, 도구를 붙이는 방법은 MCP를 다룬 글에 적어 두었습니다.
