프롬프트 엔지니어링 (Prompt engineering) → 컨텍스트 엔지니어링 (Context engineering) → 하네스 엔지니어링 (Harness engineering) → 루프 엔지니어링 (Loop engineering) → 그래프 엔지니어링 (Graph engineering):

목록은 계속 늘어나고 있으며, 각각의 새로운 용어는 마치 이전 용어를 대체하는 것처럼 다뤄지곤 합니다.

하지만 현실은 다릅니다. 각 계층은 이전 계층을 감싸고 있습니다. 이들을 구분하는 가장 간단한 방법은 각각의 작업 단위 (unit of work)가 무엇인지 질문하는 것입니다.

프롬프트 엔지니어링 (Prompt engineering)은 메시지입니다.

모델은 해당 호출 이전의 어떤 것도 기억하지 못하므로, 프롬프트에는 역할 (role), 컨텍스트 (context), 지침 (instructions), 몇 가지 예시 (examples), 그리고 출력 형식 (output format) 등 필요한 모든 것이 포함되어야 합니다.

만약 결과가 기대와 다르다면, 핵심은 프롬프트 전체를 계속해서 다시 쓰는 것이 아니라 어떤 요소가 누락되었거나 잘못되었는지 찾아내는 데 있습니다.

작업 단위는 단일 입력 (single input)입니다.

컨텍스트 엔지니어링 (Context engineering)은 메모리입니다.

여러 단계에 걸쳐 컨텍스트 창 (context window)은 제한적이지만, 사용 가능한 정보는 제한적이지 않습니다. 그렇기 때문에 선택 과정이 필요합니다.

이 과정은 중요한 것을 보존하고, 유용하지만 부피가 큰 것은 요약하며, 나머지는 버리는 것으로 구성됩니다.

좋은 컨텍스트란 더 많은 정보를 집어넣는 것이 아니라, 무엇을 제거해야 할지 아는 것입니다.

작업 단위는 컨텍스트 창 내에 남아 있는 것입니다.

하네스 엔지니어링 (Harness engineering)은 기계입니다.

모델 자체는 텍스트만을 생성할 뿐입니다.

하네스 (Harness)는 필요한 정보를 수집하고, 모델을 실행하며, 도구 (tools)나 하위 에이전트 (sub-agents)를 호출하고, 테스트나 평가자 (evaluator)를 통해 결과를 검증하는 역할을 담당합니다.

이 검증 단계가 단순한 API 호출과 AI 에이전트 (AI agent)를 구분 짓는 결정적인 차이입니다.

작업 단위는 기계의 전체 실행 (complete execution)입니다.

루프 엔지니어링 (Loop engineering)은 반복 실행입니다.

단 한 번의 실행으로 모든 문제가 해결되는 경우는 드뭅니다.

기계가 다시 실행되어야 하는지를 결정하는 메커니즘이 필요합니다. 이를 위해서는 처음부터 정의된 목표, 최대 반복 횟수나 비용 예산과 같은 제한 사항, 그리고 작업이 실제로 종료되었는지를 결정하는 자동화된 기준이 필요합니다.

에이전트가 도구(tools) 요청을 중단했다고 해서 작업이 완료되었다는 의미는 아닙니다. 그것은 단지 해당 턴(turn)이 종료되었음을 의미할 뿐입니다.

작업 단위(unit of work)는 사이클의 전체 실행입니다.

그래프 엔지니어링 (Graph engineering)은 조정(coordination)입니다.

여러 루프(loops)가 함께 작동해야 할 때, 무엇을 실행할지, 언제 실행할지, 무엇을 병렬로 처리할 수 있는지, 그리고 어떤 컴포넌트가 다른 컴포넌트를 감독할지를 정의해야 합니다.

노드(nodes)는 작업을 수행하고, 연결(edges)은 다음에 무엇이 일어날지를 결정하며, 공유 상태(shared state)가 그 사이를 흐릅니다.

사실, 단일 루프도 자기 자신을 가리키는 연결이 있는 단일 노드 그래프에 불과합니다. 그렇기에 그래프는 루프를 대체하는 것이 아니라 루프를 조직화합니다.

작업 단위는 전체 프로세스입니다.

이 모든 계층 간의 관계는 간단합니다:

프롬프트 (prompt)와 컨텍스트 (context)는 하네스 (harness)의 수집 단계 내에 존재합니다.

하네스 (harness)는 전체 패스 (pass)를 실행합니다.

루프 (loop)는 해당 패스를 반복해야 하는지 결정합니다.

그래프 (graph)는 어떤 루프가 실행될지, 그리고 루프들이 서로 어떻게 조정될지를 결정합니다.

관점을 넓힐수록 작업 단위는 커집니다.

더 깊이 파고들수록 다시 프롬프트 (prompt)로 돌아가게 됩니다.

이는 또한 문제를 어디에서 디버깅해야 하는지를 나타냅니다. 작업 단위에 따라 어떤 계층이 실패했는지 식별하고 해당 계층을 수정하십시오.

프롬프트 (prompt)는 수정하기 가장 쉬운 부분이기 때문에, 실제로는 세 단계 위에서 발생한 오류의 원인이 프롬프트에 있는 것으로 오해받는 경우가 많습니다.

아래 기사에서는 그래프 엔지니어링 (graph engineering)이 무엇인지 설명하며, 핵심 아이디어, 시작하는 방법, 공유 상태 관리 방법, 신뢰할 수 있는 라우팅 (routing) 생성 방법, 그리고 언제 실제로 그래프를 사용하는 것이 가치가 있는지를 설명합니다.

최신 정보를 계속 접하고 싶다면, 아래에서 읽어보세요👇