Blog Home

프롬프트, 컨텍스트, 하네스, 그리고 그다음

부제
AI를 개선하는 모든 일은 어디까지 AI에게 넘어가는가
URL
작성일
2026/09/07

본문

프롬프트를 고치고, 컨텍스트를 채우고, 하네스를 짠다. 이름은 달라도 모두 AI를 더 잘하게 만들려는 시도다. 그런데 이제는 그 시도 자체도 AI에게 시킬 수 있다. 지시문을 다듬어 달라고 하고, 필요한 정보를 찾아 정리하게 하고, 일을 오래 이어가기 위한 실행 구조까지 만들게 한다.
그러다 보면 이런 생각이 든다. 어쩌면 사람들이 AGI를 체감하는 순간은 AI가 특정 시험에서 몇 점을 받는 날보다, 내가 조금 손봐서 더 잘하게 만들 여지가 잘 보이지 않는 날에 가까울지도 모른다. 예전에는 내가 한 줄을 보태면 결과가 달라졌는데, 이제는 무엇을 보탤지 찾는 일부터 AI에게 맡기는 편이 나아지는 것이다.
물론 내가 고칠 수 없다는 사실만으로 AGI가 되지는 않는다. 내가 잘 모르는 소프트웨어도 이미 많다. 그래도 이 감각은 질문의 출발점이 될 수 있다. AI가 사람의 일을 하나씩 가져가는 동안, AI를 개선하는 일은 어디까지 사람의 몫으로 남아 있을까.

무엇을 바꾸고 있는가

먼저 이름을 정리해 보자. 프롬프트, 컨텍스트, 하네스는 서로 완전히 분리된 기술이 아니다. 겹치는 부분이 있고, 실제 제품에서는 한꺼번에 쓰인다. 그래도 무엇을 바꾸는지에 초점을 맞추면 구분할 수 있다.
프롬프트 엔지니어링은 모델에게 주는 지시와 예시, 출력 조건을 다듬는 일이다. 같은 질문도 어떤 역할을 부여하고 어떤 기준을 알려 주느냐에 따라 답이 달라진다. 사람이 모델과 대화하면서 가장 먼저 만지는 부분이다.
컨텍스트 엔지니어링은 모델이 이번 추론에서 보게 될 정보를 구성하는 일이다. 지시문뿐 아니라 대화 기록, 검색한 문서, 도구 실행 결과, 기억까지 포함한다. 자료를 많이 넣는 것만으로 충분하지 않다. 무엇을 찾고, 남기고, 압축하고, 버릴지를 결정해야 한다. Anthropic도 프롬프트 작성에서 나아가 컨텍스트 전체를 관리하는 문제로 이 용어를 설명한다. 컨텍스트 엔지니어링
하네스 엔지니어링은 모델이 도구와 환경 안에서 계속 일하도록 실행 구조를 만드는 일이다. 도구 연결, 작업 분해, 상태 저장, 재시도, 검증, 다음 세션으로의 인계 같은 것들이 들어간다. 컨텍스트가 이번에 무엇을 보여 줄지의 문제라면, 하네스에는 다음 호출을 언제 하고 그 결과로 무엇을 할지의 문제도 있다.
이 글에서 따라갈 순서는 이렇다.
프롬프트 → 컨텍스트 → 하네스 → anything else → 학습을 통한 자기개선
이것은 발명 연대기가 아니다. 모델 학습은 당연히 프롬프트 엔지니어링 유행보다 오래됐다. 익숙한 사용법에서 출발해 개선 대상의 범위를 넓히고, 마지막에는 학습된 모델 자체에 도달하는 순서다.

사람이 계속 보고 있지 않아도 일하게 만들기

최근 하네스 논의에서 눈에 띄는 것은 자율적으로 오래 일하기다. 한 번의 대화가 끝나도 작업을 이어가고, 실패하면 복구하고, 여러 세션에 걸쳐 목표를 유지하게 만드는 것이다.
Anthropic의 장기 작업 사례에서는 초기 환경을 준비하는 에이전트와 실제 기능을 구현하는 에이전트를 나누고, 진행 기록과 기능 목록, 테스트를 통해 다음 세션이 일을 이어받게 했다. 모델이 모든 것을 기억해 주기를 기대하는 대신, 작업 상태를 환경에 남겨 두는 구조다. 장기 작업을 위한 하네스
이때 사람의 역할도 달라진다. 매 순간 다음 행동을 지시하는 대신, 한동안 맡겨 두었다가 결과와 중요한 판단 지점을 확인한다. 일은 이미 사람의 실시간 주의 바깥에서 진행된다. 여기서 ‘인지 밖’이라는 말은 사람이 원리적으로 이해할 수 없다는 뜻보다, 모든 중간 단계를 머릿속에 올려 두고 따라가지 않는다는 뜻에 가깝다.
하네스는 그렇게 사람의 계속된 개입을 줄이는 장치였다. 그런데 하네스 역시 코드와 규칙으로 만들어진다. 코드를 쓰고 문제를 분석하는 에이전트에게는 이것도 작업 대상이 될 수 있다. 일을 맡기기 위해 만든 구조를, 그 안에서 일하는 AI에게 다시 고치게 하는 것이다.

하네스를 만드는 일도 넘어간다면

자동 에이전트 설계 연구는 이 가능성을 구체적인 실험으로 다룬다. ADAS의 Meta Agent Search는 에이전트 구성을 코드로 만들고 평가하면서 더 나은 설계를 탐색한다. DGM, Darwin Gödel Machine은 코딩 에이전트가 자기 코드를 수정하고, 과제 수행을 평가받고, 그렇게 생긴 여러 에이전트를 축적하며 탐색하는 방식을 제안했다. ADAS, DGM
그림: Jenny Zhang, Shengran Hu, Cong Lu, Robert Lange, Jeff Clune, 「Darwin Gödel Machine」 Figure 1. 원문, CC BY 4.0. 내용 변경 없이 사용.
여기서 바뀌는 것은 기반 모델의 가중치가 아니다. DGM의 해당 실험은 사전학습된 모델을 고정하고 도구 사용과 작업 흐름을 포함한 에이전트 코드를 바꾼다. 에이전트 선택과 축적을 관리하는 바깥 탐색 절차도 고정되어 있다. 따라서 모델이 자기 학습부터 운영까지 모든 것을 스스로 개선했다고 읽으면 범위가 커진다.
그럼에도 이 사례는 중요한 이동을 보여 준다. 사람이 설계한 하네스 안에서 과제를 수행하던 AI가, 하네스의 일부를 설계하는 과제까지 수행한다. 하네스가 사라지는 것이 아니라 설계자가 달라질 수 있는 것이다.
이 의미에서 LLM이 프롬프트와 컨텍스트와 하네스를 ‘삼킨다’고 말할 수 있을 것 같다. 반드시 모든 기능이 모델 가중치 안으로 들어간다는 뜻은 아니다. 바깥에 코드와 저장소가 남아 있어도, 그것을 어떻게 구성할지 생각하고 고치는 일이 AI에게 넘어갈 수 있다.

하네스 다음의 이름을 미리 정할 필요는 없다

그러면 하네스 다음에는 무엇이 올까. 더 좋은 도구, 더 나은 실험 환경, 추론에 쓸 계산량의 배분, 여러 모델의 조합, 결과를 평가하는 방법 같은 것들을 생각할 수 있다. 어떤 것은 하네스에 들어가고 어떤 것은 학습과 연결된다. 다음 유행어가 이 중 하나를 따로 떼어 부를 수도 있다.
그래서 여기에는 일단 anything else라는 자리를 남겨 두고 싶다. 합의된 네 번째 공학 분야의 이름이 아니라, 지금 알고 있는 분류로 미래의 개선 방법을 닫아 버리지 않기 위한 자리다.
핵심은 다음 기법의 이름을 맞히는 데 있지 않다. 새 방법이 나올 때마다 같은 질문을 할 수 있다는 데 있다. 그 방법을 발견하고, 구현하고, 비교하고, 개선하는 일은 누가 하는가. 알려진 방법을 AI에게 실행시키는 데서 더 나아가, 무엇을 바꿔 볼지 찾는 연구 자체도 맡길 수 있지 않을까.
이 생각은 새롭지 않다. Jeff Clune의 AI-generating algorithms 논의는 2019년에 이미 아키텍처, 학습 알고리즘, 학습 환경을 자동으로 만들어 가는 방향을 다뤘다. 이 글에서 해 보고 싶은 일은 자기개선을 처음 예측하는 것이 아니라, 우리가 AI에게 넘긴다고 말하는 ‘모든 것’을 펼쳐 보는 일이다. 여기서 ‘모든 것’은 AI의 능력과 시스템 성과를 높이는 기술적 시도 전체를 가리킨다. AI-generating algorithms

마지막에는 학습으로 모델 자체를 바꾼다

프롬프트와 컨텍스트와 하네스는 기반 모델의 가중치를 그대로 둔 채 바꿀 수 있다. 학습에 이르면 경험과 데이터가 모델의 파라미터 변화로 반영된다. 같은 모델을 더 잘 쓰는 방법을 찾다가, 더 나은 모델을 만드는 방법으로 범위가 넓어진다.
이 영역에도 이미 오래된 발판이 있다. 2022년 STaR는 모델이 생성한 추론 설명을 정답 여부에 기반해 선별하거나 다시 생성하고, 그 자료로 모델을 미세조정하는 과정을 반복했다. 2024년 Self-Rewarding Language Models는 모델이 평가자로서 보상 신호를 제공하고 이를 반복적인 학습에 사용하는 방식을 연구했다. STaR, Self-Rewarding Language Models
더 넓게 보면 데이터 수집과 생성, 학습 과제와 보상 설계, 학습 알고리즘과 모델 구조의 탐색, 실험 실행과 결과 판정까지 이어진다. 다음 세대 모델을 만드는 연구 과정 전체가 개선의 대상이다.
여기서 AI가 다른 모델의 개발을 돕는 것까지는 AI에 의한 연구개발이라고 부를 수 있다. 그 결과가 해당 AI 시스템의 다음 실행이나 후속 모델로 돌아오면, 이 글에서 말하는 자기개선의 고리가 생긴다. 실행 중인 한 인스턴스가 자기 가중치를 직접 덮어써야만 하는 것은 아니다. 개선된 시스템이 다음 개선을 더 잘 수행한다면 재귀적 자기개선의 논점으로 연결된다.
다만 고리가 생겼다고 개선이 계속 가속된다는 뜻은 아니다. 모델이 스스로 높은 점수를 주는 것과 실제로 나아지는 것도 다르다. 바깥 과제에서 성과가 확인되고, 그 성과를 얻는 비용까지 감당할 수 있어야 한다. ‘개선을 시도하는 일’과 ‘개선에 성공하는 일’ 사이에는 여전히 실험이 필요하다.

우리가 더할 수 있는 것이 줄어드는 순간

지금까지의 구분에는 두 축이 있다. 하나는 무엇을 바꾸는가다. 지시, 정보, 실행 구조, 아직 이름 붙이지 못한 방법, 학습된 모델이 여기에 놓인다. 다른 하나는 누가 개선 방법을 발견하고 설계하고 검증하는가다. 모든 영역에서 사람이 할 수도, AI의 도움을 받을 수도, 탐색 과정 자체를 AI에게 맡길 수도 있다.
이 둘을 나눠 보면 처음에 말한, 조금 손봐서 성능을 높이는 감각도 더 정확해진다. 일반 사용자가 짧은 조정으로 성능을 높이기 어려워지는 것과, 전문 연구자가 다음 세대 모델에 보탤 것이 줄어드는 것은 서로 다른 높이의 문턱이다. 앞의 문턱을 넘었다고 뒤의 문턱까지 넘은 것은 아니다. 하지만 질문의 방향은 같다. 내가 하던 개선 시도를 AI에게 맡기는 편이 더 나아지는 범위가 어디까지 넓어지는가.
그것만으로 AGI를 정의하기는 어렵다. AGI를 능력의 깊이와 범용성으로 나누고 자율성은 별도로 다루는 연구도 있다. 자기개선 하나만으로 그 모든 조건이 채워지지는 않는다. Levels of AGI
그래도 AGI를 체감하는 경계에 대한 가설로는 남겨 둘 수 있겠다. AI가 주어진 문제를 풀 뿐 아니라, 자신이 그 문제를 더 잘 풀게 할 다음 방법까지 찾아내기 시작할 때. 그 범위가 내 지시문을 넘어 실행 구조와 새로운 연구 방법, 다음 세대 모델의 학습까지 넓어질 때. 우리는 결과의 지능뿐 아니라 개선을 주도하는 지능을 보고 있는 셈이다.
프롬프트를 고치는 일에서 컨텍스트를 구성하는 일로, 하네스를 설계하는 일에서 아직 이름 붙이지 못한 개선 방법을 찾는 일로, 그리고 학습을 통해 모델 자체를 바꾸는 일까지. AI에게 넘어갈 수 있는 것은 개별 작업뿐 아니라, AI를 더 잘하게 만들려는 시도 전체다.
어쩌면 우리가 AGI를 체감하는 순간은, 하네스를 포함해 다음 세대 모델을 더 낫게 만들려는 모든 시도의 발견과 검증까지 AI에게 맡기게 되는 순간일지도 모른다.