프롬프트 엔지니어링만으로는
부족했다 — 실무자의 기록

프롬프트 '장인'이 되어가던 시절

고백부터 하자면, 저는 프롬프트를 꽤 정성 들여 쓰는 편이었어요. 데이터 조직에서 분석과 제안 업무를 하다 보니 AI에게 시키는 일이 많았고, 시키는 만큼 프롬프트도 늘었거든요.

매번 이런 식이었어요. "너는 10년 차 데이터 분석 전문가야. 결과는 표로 정리하고, 수치엔 근거를 달아. 우리 조직은 이런 상황이고, 클라이언트는 이런 걸 싫어해…" 역할을 부여하고, 좋은 예시를 붙이고, 출력 형식을 지정하고. 이른바 프롬프트 엔지니어링의 정석대로요.

그리고 이건 실제로 통했어요. 대충 시키면 대충 나오고, 정성 들여 시키면 정성스러운 결과가 나왔어요. 프롬프트가 좋아질수록 결과가 좋아지는 걸 체감하니까, 저는 점점 더 긴 프롬프트를 쓰는 사람이 됐어요. 잘 먹힌 프롬프트는 메모장에 모아뒀다가 복사해 붙여넣고요. 여기까지는 아마 AI로 일하는 분이라면 다들 비슷한 경로였을 거예요.

균열 — 나는 매일 같은 걸 다시 설명하고 있었다

균열은 사소한 데서 왔어요. 어느 날 아침, 어제 하던 분석을 이어서 하려고 새 대화를 열었는데 — 손이 자동으로 어제 쓴 프롬프트를 다시 타이핑하고 있더라고요. 역할 부여부터, 조직 상황 설명, 출력 형식까지 전부요.

AI는 어제 저와 합의한 규칙을 몰라요. 지난주에 끝낸 프로젝트도, "그 표현은 쓰지 말자"고 정한 것도 몰라요. 세션이 끝나면 모든 게 증발하니까요. 그러니 제 프롬프트 실력이 늘수록, 매일 다시 타이핑해야 하는 분량도 같이 늘어난 거예요. 잘하게 될수록 더 피곤해지는 이상한 구조였죠.

시간이 새던 다섯 군데

그 무렵의 제 작업 방식을 돌아보면, 시간이 새는 구멍이 다섯 개 있었어요. 하나하나는 사소해 보이는데, 매일 반복되니 합치면 꽤 컸어요.

주목할 점은, 이 다섯 개 중 프롬프트를 더 잘 써서 해결되는 건 하나도 없다는 거예요. 구멍 2는 얼핏 프롬프트 문제 같지만, 아니에요. 규칙을 완벽하게 써도 다음 세션에서 그걸 다시 붙여넣는 걸 깜빡하면 끝이니까, 결국 같은 휘발성 문제예요.

진단 — 문제는 품질이 아니라 '형식'이었다

여기서 내린 진단이 이 시리즈의 첫 번째 결론이에요. 문제는 프롬프트의 품질이 아니라 프롬프트라는 형식 자체였어요.

프롬프트는 본질적으로 1회용이에요. 그 안에 담은 역할, 규칙, 맥락은 대화가 끝나는 순간 사라져요. 그러니 프롬프트 엔지니어링이 아무리 발전해도 그 상한선은 '매번 잘 부탁하는 기술'이에요. 부탁을 잘하는 법을 연마하는 게 아니라, 부탁 자체가 필요 없는 환경을 만들어야 했던 거죠.

오해는 말아주세요. 프롬프트 엔지니어링이 쓸모없다는 얘기가 아니에요. 명확하게 지시하고, 좋은 예시를 주고, 출력 형식을 정하는 감각은 지금도 매일 써요. 다만 그건 기본기이지 시스템이 아니에요. 기본기 위에 뭘 쌓느냐가 다음 단계였어요.

다음 편 예고 — 프롬프트를 '상주'시키다

그래서 방향을 바꿨어요. 프롬프트를 매번 쓰는 대신, AI가 일하는 공간에 파일로 심어두는 것. 매 세션 자동으로 읽히는 정체성 파일, 어제 작업을 기록해두는 인계 파일, 반복되는 결정을 쌓는 기억 파일. 업계에서 '컨텍스트 엔지니어링'이라고 부르게 된 바로 그 방식이에요.

2편에서는 그 전환으로 뭐가 좋아졌는지, 그리고 — 이게 더 중요한데 — 그다음에 뭐가 부러졌는지를 실제 사고 기록과 함께 다뤄요.

자주 묻는 것