research

Human as Bottleneck — 병목의 성격을 바꾼다

Human as Bottleneck — 병목의 성격을 바꾼다

문제 설정

"내가 설계하고 agent가 구현"하는 모델에서, 규모가 커지면 설계 자체가 병목이 된다. Harness Engineering이 이걸 어떻게 다루는가?

병목의 두 종류

| 종류 | 정의 | 현재 상태 | |---|---|---| | 구현 병목 | 코드를 못 따라가서 느리다 | Claude Code가 거의 해결 | | 설계 병목 | 결정을 내려야 agent가 움직인다 | Harness Engineering이 다루는 핵심 |

핵심 전환: 결정을 인코딩한다

기존 모델:

인간 → (매번 설계 결정) → agent → 코드
         ↑ 매번 여기가 병목

Harness 모델:

인간 → (설계 결정) → repo에 인코딩 → agent가 자율적으로 참조
                          ↑ 한 번만 하면 됨

설계 결정을 반복적으로 내리는 게 아니라, 결정의 결과를 시스템 안에 녹여둔다. 레이어 의존성 규칙, 네이밍 컨벤션, 아키텍처 경계 등. 한 번 정의하면 agent가 알아서 지키고, 위반하면 CI가 막는다.

그래도 남는 병목 — 그리고 AI가 대체할 수 있는가?

새로운 도메인 판단

AI가 판단 자체는 이미 어느 정도 할 수 있다. 한계는 검증 기준이 없을 때다. 새로운 도메인 = 정답이 없는 상태. AI가 판단을 내려도 그게 맞는지 틀린지를 판단할 기준이 없다. → 인간이 해야 하는 건 판단 자체가 아니라 판단의 기준을 정의하는 것으로 이동 중.

Harness 자체의 설계

OpenAI는 이미 이렇게 했다: harness 개선을 Codex가 직접 하게 만들었다. "agent가 막히면 무엇이 빠졌는지 파악 → Codex가 직접 repo 수정." → Harness의 점진적 개선은 AI가 한다. 초기 방향 설정과 구조 설계는 아직 인간.

예외 처리

Agent가 막히는 것 = "컨텍스트에 없는 무언가"를 만난 것. 컨텍스트에 없으면 AI도 모른다. 하지만 Multi-agent 구조로 가면 달라진다: 막힌 agent 위에서 감독하는 agent가 "뭐가 빠진 거지?"를 판단하는 식으로 해결 가능. → 단일 agent 한계이지, AI 자체의 한계는 아니다.

방향: 병목은 사라지는 게 아니라 얇아진다

세 병목 모두 AI가 처리하는 비율이 계속 올라가고 있다. 결국 남는 건 하나:

"이게 내가 원하는 방향인가?" — 가치 판단

이것도 AI가 "당신의 과거 결정 패턴으로 보면 이 방향이 맞지 않나요?"라고 제안하는 식으로 점점 얇아지겠지만, 지금으로선 인간 고유 영역.

Harness Engineering은 단순히 "AI가 코드 짜는 방법"이 아니다. 인간이 개입해야 하는 레이어를 의도적으로 설계하는 학문. 어디까지 자동화하고, 어디에 인간을 남겨둘 건지.

핵심 철학

병목을 없애는 게 아니라, 병목의 밀도를 줄인다.

잘 갖춰진 harness에서 인간은:

  • 매 PR마다 개입 → 예외적 상황에만 개입
  • 결정을 반복 → 결정의 틀을 한 번 설계
  • 코드 리뷰 → 시스템이 올바른지 리뷰

인간 역할의 진화

레벨 1: 코드 작성자
레벨 2: 설계자 + agent 구현 (현재 일반적인 위치)
레벨 3: 환경 설계자 — harness를 설계하고 agent 플릿을 조율
레벨 4: 방향 설정자 — "무엇을 원하는가"만 정의, 나머지는 시스템이

관련 개념

← research 목록으로홈으로