'프롬프트 엔지니어' 안에 숨은 두 개의 새 직무, 기억하는 에이전트를 만드는 건 하나뿐

"프롬프트 엔지니어"는 애초에 정확한 직함이었던 적이 없지만, 한동안은 그럴 필요도 없었다. 단일 추론 호출에서 하나의 괜찮은 응답을 얻어내는 것이 업무의 전부였다면, 하나의 스킬셋으로 충분했다. 지시문을 잘 다듬고, 예시를 두어 개 넣고, 어쩌면 검색해온 텍스트를 좀 추가하면 끝이었다. 그 스킬셋은 여전히 중요하다. 하지만 2026년 중반 기준 "에이전트를 만든다"는 것이 의미하는 바를 더 이상 다 담아내지 못하며, 그 간극은 특정하고 알아보기 쉬운 실패 양상으로 드러나고 있다. 데모에서는 훌륭하게 작동하다가 조용히 성능이 떨어지고, 스스로 모순되는 말을 하고, 사용자가 두 세션 전에 알려준 것을 잊어버리는 에이전트들 말이다.

Machine Learning Mastery의 최근 글은 이 간극을 정면으로 짚어내는데, 실제로 채용될 수 있는 두 가지 다른 직무와 깔끔하게 대응된다는 점에서 곱씹어볼 가치가 있다. 컨텍스트 엔지니어링은 하나의 추론 호출 안에서 일어나는 일이다. 즉 컨텍스트 윈도우에 무엇을 넣을지, 구조적으로 어디에 배치할지, 모델이 무관한 토큰에 파묻히지 않도록 무엇을 압축하거나 버릴지를 결정하는 작업이다. 메모리 엔지니어링은 여러 호출에 걸쳐서만 존재하는 다른 문제다. 세션이 끝난 후 무엇을 기록해둘지, 어디에 저장할지, 다음번에 어떻게 불러올지, 그리고 (업데이트, 중복 제거, 만료 처리 등) 어떻게 유지 관리해서 부패하지 않게 할지를 다룬다. 그 글에 따르면, 길고 여러 세션에 걸친 에이전트 워크플로우에서 나타나는 실패는 대부분 이 두 가지 작업을 뒤섞거나 둘 중 하나를 건너뛰는 데서 비롯된다. 특히 이들이 "검색 경계(retrieval boundary)"라고 부르는 지점, 즉 에이전트가 필요한 정보가 눈앞에 있는지 아니면 저장소에서 가져와야 하는지를 판단해야 하는 순간에서 그렇다.

둘을 뒤섞는 것이 사소한 문제가 아니라 진짜 버그인 이유

각 분야가 무엇을 최적화하고 있는지 생각해보자. 컨텍스트 엔지니어링은 단일하고, 경계가 정해져 있으며, 일회성인 윈도우를 최적화한다. 지금, 이 한 번의 대화를 위해 올바른 정보 조각을 모델 앞에 가져다 놓고, 나머지는 버리는 것이다. 메모리 엔지니어링은 세션을 넘어 지속되어야 하고, 새로운 정보가 들어올 때마다 일관성을 유지해야 하며, 훨씬 더 어려운 질문에 답해야 하는 영속적인 저장소를 최적화한다. "이 프롬프트와 무엇이 관련 있는가"가 아니라 "애초에 무엇을 남겨둘 가치가 있고, 얼마나 오래 남겨둘 것인가"라는 질문 말이다.

이것들은 실패 양상이 다른, 서로 다른 설계 문제다. 컨텍스트 엔지니어링의 실수는 하나의 응답을 나쁘게 만든다. 메모리 엔지니어링의 실수는 누적된다. 잘못된 기록이 쌓이고, 낡은 사실이 마치 현재인 양 불려오며, 에이전트가 세 세션 전에 이미 정정된 내용을 자신 있게 반복할 때까지 아무도 눈치채지 못한다. 한 사람(또는 하나의 프롬프트 템플릿)이 이 두 가지 작업을 구분 없이 조용히 동시에 수행하고 있다면, 메모리 계층은 그래서는 안 될 컨텍스트 엔지니어링의 습관을 물려받는 경향이 있다. 윈도우를 과도하게 채우듯 저장소를 과도하게 채우거나, 사실은 큐레이션과 유지 관리의 문제인 것을 관련성 순위 매기기 문제로 취급하는 식이다. 바로 이것이 그 리서치 다이제스트가 지적하는 혼동이며, 실무자들이 이미 일화 삼아 이야기하는 것과도 일치한다. 한 세션에서는 인상적이지만 다섯 번째 세션쯤 되면 믿을 수 없어지는 에이전트들 말이다.

각 직무가 실제 일상에서 어떤 모습인가

지금 자신이 이 둘 중 어느 쪽을 이미 하고 있는지, 혹은 어느 쪽을 목표로 나아가고 싶은지 가늠해보려 한다면, 두 업무의 일상적인 모습은 충분히 다르게 구별된다.

컨텍스트 엔지니어링을 실제로 해보면: 이용 가능한 정보(문서, 툴 출력, 이전 턴) 중 어떤 부분집합이 실제로 이번 호출에 속하는지를 정하는 일, 프롬프트 내 위치가 모델이 정보에 부여하는 가중치에 영향을 주기 때문에 그것을 어디에 배치할지 고르는 일, 긴 툴 실행 기록이 예산을 통째로 먹어치우지 않도록 압축이나 요약 단계를 작성하는 일, 그리고 디버깅 에이전트와 글쓰기 에이전트는 동일한 기반 모델을 쓰더라도 서로 다른 컨텍스트 형태를 원하기 때문에 작업별로 이를 조정하는 일이다.

메모리 엔지니어링을 실제로 해보면: 쓰기 정책을 정의하는 일(세션이 끝난 뒤 무엇을 남길 가치가 있는지, 모든 것이 그런 것은 아니다), 저장 계층을 선택하는 일(벡터 스토어, 구조화된 데이터베이스, 일반 파일, 혹은 어떤 하이브리드 방식일 수도 있으며, 각각의 장단점을 솔직하게 따져보는 일), 무엇이 언제 다시 불려나올지를 결정하는 검색 전략을 구축하는 일, 그리고 지속적인 유지 관리를 하는 일이다. 즉 가지치기하고, 중복된 사실을 병합하고, 사용자가 마음을 바꿨을 때 모순을 처리하는 일이다. 마지막 부분인 유지 관리는 사람들이 가장 자주 건너뛰는 부분인데, 에이전트가 몇 주간 돌아가기 전까지는 눈에 보이지 않기 때문이다.

업계가 이러한 관심사들을 개념적으로뿐 아니라 구조적으로도 분리하기 시작하는 모습을 볼 수 있다. Lenny's Newsletter가 Claude Agent SDK 위에서 디버깅 하네스를 구축하는 과정을 설명한 글은 권한, 툴 어댑터, 그리고 이를 둘러싼 "하네스" 자체를 그 안의 프롬프팅과는 별개의 엔지니어링 영역으로 다룬다. 같은 직감을 다른 이음매에 적용한 것이다. 그리고 구글의 새로운 Gemini API "관리형 에이전트(Managed Agents)" 기능들, 즉 백그라운드 실행, 상호작용 간 자격 증명 갱신 등은 사실상 플랫폼 벤더가 세션에 걸쳐 지속되는 상태가 이제는 충분히 긴 컨텍스트 윈도우의 부산물이 아니라 설계되어야 하는 인프라라는 것을 인정하는 셈이다. 누군가는 그 설계를 책임져야 한다. 지금 많은 팀에서는 그 누구도 명시적으로 그 일을 맡고 있지 않다.

이것이 당신의 코드뿐 아니라 직함에도 중요한 이유

경력 초중반이고 이력서에 "프롬프트 엔지니어"나 "AI 엔지니어"라고 적혀 있다면, 이 두 직무 중 실제로 자신이 해왔다고 증거를 댈 수 있는 쪽이 어느 것인지 물어볼 가치가 있다. 왜냐하면 범용 AI 에이전트 직무가 점점 더 구체적인 직무들로 쪼개지기 시작하고 있기 때문이다. 마치 "웹마스터"가 결국 프런트엔드, 백엔드, 데브옵스로 나뉘었던 것처럼 말이다. 이것은 확정적인 헤드라인이 아니라 하나의 헤지다. 필자는 "메모리 엔지니어"가 독립된 직함으로 자리 잡았다는 것을 확증할 만한 확실한 채용 데이터를 아직 본 적이 없으므로, 이를 채용 공고가 이미 이런 식으로 정리되어 있다는 주장이 아니라 업무가 향하고 있는 방향에 대한 하나의 해석으로 받아들여야 한다. 하지만 그 저변의 압력은 실재하며, 앞서 언급한 다이제스트로 거슬러 올라갈 수 있다. 에이전트 팀들은 특정하고 이름 붙일 수 있는 실패(다중 세션에서의 성능 저하)를 겪고 있고, 그 실패에는 특정하고 이름 붙일 수 있는 원인(두 분야를 뒤섞는 것)이 있다. 그리고 이런 조합은 대체로 흐릿했던 하나의 역할을 뚜렷한 두 개로 갈라놓곤 한다.

실용적인 대응은 스스로 직함을 지어내는 것이 아니다. 자신이 실제로 어떤 문제를 풀었는지 구체적으로 답할 수 있는 것이다. 에이전트가 무엇을 메모리에 커밋하고 무엇을 버릴지에 대한 규칙, 즉 쓰기 정책을 설계해본 결과물을 내놓은 적이 있는가? 에이전트가 저장소에서 무언가를 가져와야 했는데 가져오지 못했거나 잘못된 버전을 가져온, 검색 경계 실패를 디버깅해본 적이 있는가? 이런 것들은 면접에서 저장소나 사후 분석 보고서로 뒷받침하며 내세울 수 있는, 확인 가능한 주장들이다. 그리고 이것들은 일반적인 "저는 프롬프트를 잘 씁니다"라는 말이 전달하지 못하는 것을 말해준다. 하나의 답을 더 낫게 만드는 것과 에이전트를 시간이 지나도 신뢰할 수 있게 만드는 것의 차이를 이해하고 있다는 사실 말이다.

주의할 점

프로젝트에 벡터 데이터베이스를 한 번 추가해봤다는 이유만으로 스스로를 "메모리 엔지니어"라고 다시 이름 붙이지 말라. 이 리서치가 가리키는 분야에는 화려하지 않은 절반, 즉 유지 관리, 만료 처리, 모순 처리가 포함되어 있으며, 바로 그 절반이 앞서 설명한 실패 양상을 실제로 막아주는 부분이다. 자신의 포트폴리오 작품이 메모리에 기록은 하지만 아무것도 가지치기되거나 정정되지 않는 시스템이라면, 메모리 엔지니어가 할 일의 절반만 만든 셈이고, 세 번째 세션 이후에 무너지는 문제는 여전히 남은 절반에서 당신을 기다리고 있다.