프롬프트 엔지니어링이라는 말이 나온 지 얼마 안 된 것 같은데, 그새 컨텍스트 엔지니어링이 나왔고, 하네스 엔지니어링, 루프 엔지니어링, 그래프 엔지니어링까지 붙었다. 타임라인에는 매주 새 "엔지니어링"이 하나씩 등장하고, 그때마다 "이제 프롬프트는 죽었다"류의 문장이 따라온다. 이 글은 그 용어들을 정리하는 데서 시작하지만, 정리가 목적은 아니다. 용어를 다 걷어내면 무엇이 남는지, 그리고 그 위에서 다음에 뭐가 나올지를 보려는 글이다.
프롬프트에서 그래프까지
1프롬프트 엔지니어링
모델에게 건네는 텍스트 자체를 다듬는 일이다. 역할을 부여하고, 출력 형식을 지정하고, 예시를 몇 개 넣고, 단계적으로 생각하라고 지시한다. 대상은 한 번의 요청에 들어가는 문장들이고, 단위는 문장과 문단이다. 2023년까지 대부분의 노하우가 여기 있었고, "템플릿을 잘 짜면 결과가 달라진다"가 이 시기의 명제였다.
2컨텍스트 엔지니어링
단위가 문장에서 컨텍스트 창 전체로 올라간다. 시스템 프롬프트만이 아니라 대화 기록, 검색해온 문서, 도구 호출 결과, 장기 메모리, 사용자 프로필까지, 창 안에 들어가는 모든 것을 무엇을 넣고 무엇을 빼고 어떤 순서로 배치할지 설계한다. 프롬프트 엔지니어링과 가르는 기준은 하나다. 사람이 손으로 쓴 텍스트를 다루면 프롬프트고, 시스템이 동적으로 조립하는 창 전체를 다루면 컨텍스트다. 검색 증강, 컨텍스트 압축, 메모리 주입이 이 층에 속한다. 창은 유한하고 창 안의 위치가 결과에 영향을 주기 때문에 정보 설계 문제에 가깝다.
3하네스 엔지니어링
모델이 텍스트를 뱉는 것 이상을 하게 됐을 때 생긴 층이다. 창 안이 아니라 창 바깥, 즉 모델을 감싸는 실행 환경을 다룬다. 어떤 도구를 호출할 수 있는지, 어떤 파일을 읽고 쓸 수 있는지, 어느 디렉토리까지 권한이 있는지, 코드는 어디서 실행되는지, 테스트는 자동으로 도는지, 사람이 승인해야 하는 지점은 어디인지. 컨텍스트 엔지니어링과 가르는 기준은 "모델이 보는 것"이냐 "모델이 할 수 있는 것"이냐다. 코딩 에이전트에서 이 층이 특히 두드러진다. 같은 모델이라도 샌드박스와 테스트 러너와 린터를 붙여주느냐 아니냐에 따라 결과가 크게 갈린다.
4루프 엔지니어링
시간 축이 들어온다. 모델을 한 번 호출하고 끝나는 게 아니라, 결과를 다시 보여주고, 검증하고, 다시 시도하게 하는 반복 구조를 설계한다. 몇 번까지 돌릴지, 종료 조건은 무엇인지, 반복할 때 이전 시도의 어디까지를 다시 보여줄지, 사람이 개입하는 지점은 어디인지. 하네스가 한 번의 실행 환경이라면 루프는 그 실행을 여러 번 엮는 규칙이다. 에이전트가 길게 돌기 시작하면서 필요해졌다.
5그래프 엔지니어링
반복이 아니라 분기와 위상을 다룬다. 여러 모델 호출이나 여러 에이전트를 노드로 놓고, 어떤 순서로 실행할지, 어디서 갈라지고 어디서 합쳐질지, 한 노드의 실패가 다른 노드로 번지지 않게 어떻게 격리할지를 그린다. 루프가 하나의 흐름을 여러 번 도는 것이라면 그래프는 여러 흐름의 관계를 정하는 것이다. 워크플로우 오케스트레이션, 멀티 에이전트 구조가 여기 속한다.
정리하면 다섯 개는 대상의 범위가 다르다. 프롬프트는 문장, 컨텍스트는 창, 하네스는 창 바깥의 환경, 루프는 시간, 그래프는 위상. 안에서 밖으로, 한 번에서 여러 번으로, 하나에서 여럿으로 확장돼온 순서다.
세 개의 질문
층은 다섯이지만, 저 다섯 개가 답하려는 질문은 셋이다.
무엇을 보여줄 것인가.모델은 컨텍스트 창 안에 있는 것만 볼 수 있고, 거기 없는 것은 없는 것이다. 프롬프트도 컨텍스트도 검색 증강도 메모리도 전부 이 질문에 대한 답이다. 좋은 프롬프트란 결국 이 순간 모델이 봐야 할 것을 정확히 그 순간에 보이게 하는 것이고, 컨텍스트 엔지니어링은 그 범위를 문장에서 문서·기록·검색 결과로 넓혔을 뿐이다.
뭘 하게 할 것인가.텍스트를 뱉는 것 이상을 시키려면 행동의 공간을 설계해야 한다. 어떤 도구를 쥐여줄지, 어떤 파일을 읽고 쓸 수 있게 할지. 이 공간의 모양이 결과의 모양을 정한다.
틀리면 어디서 잡을 것인가.모델은 틀린다. 문제는 틀리는지 여부가 아니라 틀렸을 때 그것이 어디까지 번지느냐, 어느 지점에서 되돌릴 수 있느냐다. 권한의 경계, 샌드박스, 테스트, 재시도, 실패한 단계의 격리가 전부 여기 속한다.
앞의 둘은 지각과 행동의 문제고, 셋째는 제어의 문제다. 그리고 셋째 질문은 하네스에서 이미 시작됐다. 모델에게 쓰기 권한을 주되 특정 디렉토리에만 준다는 결정은 행동 공간을 정의하는 동시에 실패의 반경을 정하는 결정이고, 샌드박스는 실행 환경이면서 봉쇄 장치다. 하네스 설계에서 실제로 시간을 잡아먹는 것도 뭘 할 수 있게 할지보다 뭘 못 하게 할지, 잘못했을 때 어디서 멈추게 할지다. 루프와 그래프는 그 셋째 질문을 시간과 위상으로 확장한 것이다. 한 번 더 보게 해서 스스로 고치게 하고, 실패한 노드가 다른 노드를 오염시키지 않게 격리한다. 새 질문이 아니라 같은 질문에 대한 더 세밀한 답이다.
그러니 용어를 외우면 다섯 개를 외워야 하지만 질문을 알면 셋이면 된다.
왜 말이 계속 만들어지는가
새 용어가 매달 나오는 데는 두 가지 다른 이유가 겹쳐 있다.
하나는 진짜 이유다. 모델이 할 수 있는 일의 범위가 넓어질 때마다 설계해야 할 층이 하나씩 늘어난다. 텍스트만 뱉을 때는 프롬프트면 됐고, 긴 문서를 다루기 시작하니 컨텍스트가 문제가 됐고, 도구를 쥐여주니 하네스가 필요해졌고, 길게 돌리니 루프와 그래프가 필요해졌다. 층이 늘어나는 건 사실이고 거기 이름이 붙는 것도 자연스럽다.
다른 하나는 시장의 이유다. 컨설팅 회사와 툴 벤더는 자기가 파는 층에 이름을 붙여야 한다. "우리는 프롬프트를 잘 씁니다"로는 차별화가 안 되니 "컨텍스트 엔지니어링을 합니다"가 되고, 그다음엔 "하네스"가 된다. 이름이 곧 포지셔닝이다. 그래서 같은 일에 이름이 세 개씩 붙고, 조금 다른 일에 완전히 다른 이름이 붙는다.
이 둘을 구분하면 뭐가 남는지 보인다. 첫 번째 이유로 늘어난 것은 층이지 질문이 아니다. 두 번째 이유로 늘어난 것은 이름이지 내용이 아니다.
그 다음은 무엇일까
확장의 방향이 문장→창→환경→시간→위상이었다면, 다음 이름이 어디서 나올지도 어느 정도 그려볼 수 있다. 개발자가 다음에 부딪힐 벽과 모델이 다음에 흡수할 능력, 두 방향에서 보면 후보가 몇 개로 좁혀진다.
세션을 넘어가는 시간. 루프가 다룬 시간은 한 작업 안의 시간이었다. 에이전트가 며칠, 몇 주 단위로 같은 프로젝트를 다루기 시작하면 세션 사이에 무엇을 남기고 무엇을 잊게 할지가 문제가 된다. 지금 "메모리 엔지니어링"이라는 이름으로 이미 올라오고 있고, 이건 첫째 질문(무엇을 보여줄 것인가)이 긴 시간축으로 늘어난 것이다.
관측과 평가. 그래프가 복잡해질수록 어디서 틀렸는지 사후에 추적하는 일이 어려워진다. 트레이스, 평가 세트, 회귀 테스트를 에이전트에 붙이는 층에 이름이 붙을 것이고, 이건 셋째 질문(틀리면 어디서 잡을 것인가)이 실행 중에서 실행 후로 옮겨간 것이다. "이밸 엔지니어링" 같은 말이 그 자리를 노리고 있다.
위임과 책임의 경계. 지금까지의 다섯 층은 모두 사람이 설계하고 모델이 그 안에서 움직인다는 전제 위에 있다. 그런데 모델이 자기 컨텍스트를 스스로 관리하고, 필요한 도구를 스스로 붙이고, 하위 에이전트를 스스로 띄우기 시작하면 이 전제가 흔들린다. 프롬프트 엔지니어링의 상당 부분이 모델이 좋아지면서 모델 안으로 흡수됐듯, 컨텍스트 관리와 하네스 구성도 점점 모델 쪽으로 넘어갈 것이다. 그러면 사람 손에 남는 것은 "이 에이전트에게 무엇을 어디까지 맡길 것인가, 잘못되면 누가 책임지는가"라는 질문이고, 이건 셋 중 어디에도 깔끔하게 안 들어간다. 지금 "거버넌스"나 "권한 위임"이라는 흐릿한 말로 불리는 이 자리가 진짜 새 질문이 생길 자리라고 본다.
앞의 둘은 기존 질문의 확장이라 이름이 붙어도 놀랄 일이 아니다. 셋째는 다르다. 층이 밖으로 확장되던 흐름이 안으로 흡수되는 쪽으로 방향을 바꾸는 지점이고, 그때 남는 것은 기술 설계가 아니라 판단의 문제다.
다음 달에 새 이름이 나오면
물어볼 것은 하나다. 이게 세 질문 중 어디에 대한 답인가. 대부분은 셋 중 하나에 들어가고, 들어가면 이미 알고 있는 것의 변주다. 셋 중 어디에도 안 들어가는 것이 나오면 그때 진짜 새로운 것이 나온 거고, 그건 배울 가치가 있다. 지금까지 그런 순간은 두세 번 있었다. 도구를 쥐여주면서 둘째 질문이 열렸을 때, 길게 돌리기 시작하면서 셋째 질문이 무거워졌을 때. 그 사이의 수많은 이름은 대체로 재포장이었다.
용어를 몰라도 질문을 알면 된다. 반대로 용어를 다 알아도 질문을 모르면 새 용어가 나올 때마다 처음부터 다시 배우는 기분이 든다. 뒤처진 기분은 대개 후자에서 온다. 방법론이 바뀌어서가 아니라 방법론을 이름으로 기억하고 있어서다.