하네스(The Harness)가 이제는 제품 그 자체가 되었습니다

AI 엔지니어링이 방금 (또 다시) 변했나요?

지난 1년 동안, AI로 무언가를 구축해 온 우리 대부분은 한 가지에 집중해 왔습니다. 바로 모델로부터 더 나은 출력값(outputs)을 얻어내는 것이었습니다.

우리는 프롬프트(prompts)를 미세 조정했습니다.
우리는 온도(temperature) 설정을 실험했습니다.
우리는 예시, 지침, 포맷팅 기술들을 추가했습니다. 제 말은, 살면서 이렇게 많은 복사/붙여넣기식 프롬프팅(prompting) 기사들을 본 적은 처음이라는 겁니다.

그리고 한동안은 그것이 효과가 있었습니다. 하지만 최근 무언가 변화가 생겼습니다. LangChain, Anthropic, Cognition, Arena, Hugging Face와 같이 매우 서로 다른 기업들 사이에서 동일한 패턴이 나타나고 있습니다. 실제 엔지니어링 작업은 더 이상 프롬프트에 있지 않습니다. 그것은 스택(stack)의 상위 단계인 모델을 둘러싸고 있는 영역으로 이동했습니다. 많은 이들이 현재 '하네스(the harness)'라고 부르는 바로 그 "무언가"가 그것입니다. 이름에도 불구하고, 이것은 영화 '서브스턴스(The Substance)'의 속편은 아닙... (아니면 영화광들에게는 이것이 일종의 조기 경보 신호일까요?).

하네스의 실제 정체
핵심적으로, 하네스는 라이브러리(library)나 프레임워크(framework)가 아닙니다. 그것은 제어 루프(control loop)입니다. 모델을 단발성 함수(one-shot function)로 취급하는 대신, 하네스는 모델의 동작을 지속적으로 관리하는 시스템으로 모델을 감쌉니다. 전형적인 하네스에는 다음이 포함됩니다:

태스크 플래닝 (Task planning) (우리가 무엇을 하려고 하는가?)
컨텍스트 조립 (Context assembly) (모델이 무엇을 알아야 하는가?)
실행 (Execution) (모델 또는 도구 호출)
평가 (Evaluation) (결과가 충분히 좋았는가?)
안전 및 검증 (Safety and validation) (허용 가능하며 정확한가?)
관찰 가능성 (Observability) (단계별로 어떤 일이 일어났는가?)

이것이 핵심적인 차이점입니다. 출력값은 더 이상 단순한 텍스트가 아닙니다. 그것은 트레이스(traces), 메트릭(metrics), 그리고 결과(outcomes)이기도 합니다. 시스템은 단순히 답변을 생성하는 데 그치지 않습니다. 그 답변이 수용 가능한지, 그리고 수용 불가능했다면 무엇을 해야 하는지를 학습합니다.

이것이 우리가 구축하는 방식을 바꾸는 이유

여기서 일어나고 있는 일은 미묘하지만 중요합니다.
우리는 더 이상 AI 기능(features)을 만드는 것이 아닙니다. 우리는 불확실성(uncertainty)을 관리하는 AI 시스템을 구축하고 있습니다. 그리고 그것은 다른 사고방식을 요구합니다. 전통적인 소프트웨어에서 우리는 결정론(determinism)을 가정합니다. 코드가 정확하다면, 일관되게 동작합니다.

LLM(Large Language Models)과 함께라면 그 가정은 깨집니다. 동일한 입력이라도 서로 다른 출력을 생성할 수 있습니다. 모델은 환각 (hallucination)을 일으킬 수 있습니다. 작업을 부분적으로만 완료할 수도 있습니다. 그럴듯해 보이는 방식으로 실패할 수도 있습니다. 하네스 (harness)는 바로 그러한 현실에 대처하기 위해 존재합니다. 하네스는 모델을 완벽하게 만들려고 시도하지 않습니다. 대신 불완전한 구성 요소들을 신뢰할 수 있게 만드는 시스템을 구축합니다.

이러한 변화를 이해하는 가장 명확한 방법은 우리가 답변을 생성하는 단계에서 결과(outcomes)를 제어하는 단계로 이동하고 있다는 점을 인식하는 것입니다.

프롬프트 (prompt) 시대의 성공은 “이번에 모델이 좋은 답변을 내놓았는가?”를 의미했습니다.

하네스 시대의 성공은 “이 시스템이 수많은 사례에 걸쳐 일관되게 좋은 답변을 생성하는가?”를 의미합니다.

이는 근본적으로 다른 문제입니다. 그리고 이는 소프트웨어 엔지니어들이 이미 다른 도메인에서 매우 잘 해결하고 있는 문제이기도 합니다.

엔지니어들이 다르게 해야 할 것들
하네스로의 전환은 새로운 기술을 배우는 것에 관한 것이 아닙니다. 이는 익숙한 엔지니어링 규율 (engineering discipline)을 새로운 종류의 시스템에 적용하는 것에 관한 것입니다.

첫째, 단일 프롬프트 단위로 생각하는 것을 멈추고 루프 (loops) 단위로 생각하기 시작해야 합니다. 한 번 질문하고 돌아오는 결과 무엇이든 받아들이는 대신, 시스템이 자신의 출력을 스스로 평가하고 필요에 따라 다시 시도할 수 있는 흐름 (flows)을 설계해야 합니다. “생성, 비판, 개선 (generate, critique, refine)” 또는 “계획, 실행, 평가 (plan, execute, evaluate)”와 같은 패턴이 표준이 됩니다.

둘째, 평가 (evaluation)가 일급 시민 (first-class concern)이 됩니다. 전통적인 시스템에서 테스트는 동작을 검증합니다. AI 시스템에서 평가는 동작을 정의합니다. 출력 품질을 측정할 방법이 없다면, 여러분의 시스템이 실제로 무엇을 하고 있는지 알 수 없습니다. 이는 데이터셋을 구축하고, 점수 산정 규칙을 정의하며, 지속적인 점검을 수행하는 것을 의미합니다. 이는 사후 고려 사항이 아니라 핵심 시스템의 일부로서 이루어져야 합니다.

셋째, 관찰 가능성 (observability)이 필수적이 됩니다. 무언가 잘못되었을 때, 여러분은 다음 사항들을 확인해야 합니다:

• 모델에 무엇이 주어졌는지
• 모델이 무엇을 생성했는지
• 시스템이 어떤 결정을 내렸는지

AI 시스템에서의 실행 추적 (execution traces)은 분산 시스템 (distributed systems)에서 로그 (logs)와 스택 트레이스 (stack traces)가 수행하는 것과 동일한 역할을 합니다. 이것이 없다면 디버깅 (debugging)은 추측에 의존할 수밖에 없습니다.

넷째, 우리는 비결정론 (non-determinism)과 싸우는 대신 이를 수용해야 합니다.
단일 출력에 의존하는 대신, 하네스 (harness) 기반 시스템은 종종 여러 개의 후보를 생성한 다음 점수 산정 (scoring), 휴리스틱 (heuristics), 또는 또 다른 모델을 사용하여 최적의 것을 선택합니다. 이는 함수를 호출하는 것보다는 작은 실험을 수행하고 최선의 결과를 선택하는 것에 더 가깝습니다.

마지막으로, 우리는 처음부터 실패를 고려하여 설계합니다. 우리는 출력이 틀릴 수 있고, 도구 (tools)가 오용될 수 있으며, 단계가 불완전할 수 있다고 가정합니다. 따라서 검증 (validation), 폴백 (fallbacks), 재시도 (retries), 그리고 때로는 인간의 개입 (human intervention)을 추가합니다.

변장한 익숙한 패턴... 이 모든 것이 익숙하게 느껴진다면, 당연한 결과입니다. 우리가 지금 구축하고 있는 것은 재시도 (retries)와 서킷 브레이커 (circuit breakers)가 있는 분산 시스템 (distributed systems), 검증 (validation)과 모니터링 (monitoring)이 있는 데이터 파이프라인 (data pipelines), 그리고 랭킹 (ranking)과 평가 (evaluation)가 있는 검색 시스템 (search systems)과 매우 닮아 있습니다.

차이점은 핵심 연산인 모델이 확률적 (probabilistic)이라는 점입니다. 하네스는 이를 공학적으로 설계된 신뢰성 (engineered reliability)의 세계로 다시 가져옵니다.

많은 기업이 독립적으로 동일한 아이디어에 도달하는 이유는 결국 모두가 동일한 한계에 부딪히기 때문이라고 생각합니다. 프롬프트 (prompts)는 확장이 멈춥니다. 복잡한 파이프라인은 취약해지며, 신뢰할 수 없음으로 인한 비용이 실질적으로 발생합니다. 하네스는 이러한 제약에 대한 자연스러운 대응입니다. 왜냐하면 하네스는 피드백 루프 (feedback loops), 측정 가능한 품질, 그리고 (그들이 희망하기를) 제어 가능한 동작을 제공하기 때문입니다.

다시 말해, 하네스는 여러분이 신뢰할 수 있는 무언가를 구축할 수 있게 해줍니다.

만약 붙잡아야 할 단 하나의 아이디어가 있다면, 모델은 여러분의 제품이 아니라는 점입니다.
모델 주변의 시스템이 바로 여러분의 제품입니다. 그리고 전통적인 컴퓨팅과 마찬가지로, 진정한 혁신과 진정한 차별화는 바로 그 상위 계층에서 일어납니다.

저는 우리가 AI가 마법처럼 느껴지던 단계에서 벗어나, 다시 엔지니어링 (Engineering)처럼 느껴지기 시작하는 단계로 마침내 진입하고 있다는 점이 꽤 마음에 듭니다. 성공하는 팀은 가장 영리한 프롬프트 (Prompt)를 가진 팀이 아닐 것입니다. 그들은 강력한 피드백 루프 (Feedback loops), 신뢰할 수 있는 평가 시스템 (Evaluation systems), 관찰 가능한 파이프라인 (Observable pipelines), 그리고 견고한 하네스 (Harnesses)를 구축하는 팀이 될 것입니다.결국, 사용자는 단일 응답이 얼마나 인상적인지에는 관심이 없기 때문입니다.

그들은 시스템이 제대로 작동하는지에 관심을 가집니다.