현대 AI 애플리케이션의 중심에는 여전히 모델이 있지만, 영향력은 외부로 확장되었습니다. 한때 프롬프트를 조정하던 팀들은 이제 모델을 둘러싼 시스템을 설계합니다: 모델이 보는 것을 선별하고, 실행 방식을 관리하며, ‘좋음’을 정의하는 검증자를 추가하고, 필요할 때 여러 전문가를 조율된 워크플로우에 연결합니다. 이 계층적 변화는 과장이 아니라, 대규모에서 실패와 비용이 실제로 발생하는 지점을 반영합니다. 완벽한 문구가 부족한 사실을 채워주지 못하며, 완벽한 입력도 긴 실행 동안에는 흔들립니다; 검증되지 않은 루프는 밤새 쓸데없는 결과를 출력할 수 있습니다. 비용은 증가하는데 결과는 정체된다면, 병목은 한 단계 바깥에 있을 가능성이 큽니다.

다섯 단계로 생각하세요. 프롬프트 엔지니어링은 단일 요청을 구성합니다. 컨텍스트 엔지니어링은 모델이 보는 것을 결정합니다—검색, 순위 매기기, 요약, 편집적 수정 등이 포함됩니다. 하니스 엔지니어링은 전체 실행을 제어합니다: 도구, 상태 유지, 오케스트레이션, 평가, 복구가 여기에 속합니다. 루프 엔지니어링은 목표, 검증자, 중지 조건을 정의하여 사용자를 트리거에서 분리합니다. 그래프 엔지니어링은 여러 전문 에이전트를 엣지, 조건부 라우팅, 병렬 처리, 공유 상태로 조율합니다. 각 단계는 이전 단계를 감싸며, 어떤 것도 쓸모없어지지 않습니다. 희소한 기술은 점점 외부로 이동합니다: 문구 작성에서 정보 아키텍처, 제어 설계, 검증 설계, 그래프 내 분해 및 라우팅으로 말이죠.

증상을 활용해 다음 투자를 결정하세요. 모델이 요청을 잘못 해석한다면 프롬프트 계약을 강화하세요. 답변에 사실이 부족하거나 주제에서 벗어난다면 검색과 컨텍스트 압축을 개선하세요. 긴 워크플로우가 불안정하거나 조용히 실패한다면 하니스 강화와 평가자 추가가 필요합니다. 여전히 사람이 스케줄러라면 루프 트리거와 검증자를 명확히 하세요. 한 에이전트가 연구, 작성, 비평 등 서로 다른 작업을 혼합한다면 작업을 노드로 분할하고, 공유 상태 객체를 정의하며, 명확한 조건에 따라 라우팅하세요. 각 단계는 측정 가능한 KPI로 고정됩니다: 답변 가능성, 도구 성공률, 실행 완료 및 복구, 루프 정밀도/재현율, 그래프 수준 처리량 및 수락된 산출물당 비용 등입니다.

도입은 점진적으로 이루어져야 합니다. 출력 계약을 명문화하고 가벼운 평가자를 하니스에 추가하는 것부터 시작하세요. 평가자가 인간보다 더 많은 결함을 잡아내면 루프 엔지니어링으로 진급하세요. 전문화와 라우팅이 단일 검증 루프보다 품질, 속도, 단위 경제성에서 우수할 때만 그래프 엔지니어링으로 이동하세요. 작고 테스트 가능한 제어 그래프, 명확한 상태 스키마, 샌드박스 도구를 선호하세요. 검증자는 코드의 일급 시민으로 다루며, 커버리지, 드리프트 검사, 예산 한도를 적용하세요. 이 경로는 모델 비용을 예측 가능하게 유지하고, 결함률을 관찰 가능하게 하며, 에이전트 군단이 토큰 소모가 아닌 비즈니스 결과에 맞춰 정렬되도록 합니다.