하네스 엔지니어링이란, 사람이 조향하고 에이전트가 실행하는 개발 방식

과거의 엔지니어링에서 가장 귀한 것은 개발자의 시간이었습니다. 그래서 성과도 코드 라인 수처럼 얼마나 만들었는지로 셌고, 병목은 기능을 구현하는 일이었습니다.

에이전트가 코드를 쏟아내는 환경에서는 이 세 가지가 모두 뒤집힙니다. 희소한 자원은 GPU 용량과 토큰 예산이 되고, 핵심 산출물은 프롬프트와 가드레일이 되며, 병목은 시스템 설계와 컨텍스트가 됩니다. 코드는 더 이상 희소하지 않고 사실상 공짜에 가깝다는 것이 출발점입니다.

코드 생성, 무한에 가까운 병렬 실행, 대규모 리팩토링, 우선순위가 낮은 P3 작업의 즉각 처리는 이제 풍부한 자원입니다. 반대로 사람의 집중력과 시간, 모델의 컨텍스트 윈도우, 제품을 높은 수준에서 그리는 비전은 절대적으로 부족한 자원입니다.

그래서 엔지니어의 역할도 올라갑니다. 직접 구현하는 일은 내려가고, 코드 리뷰와 디버깅, 시스템 설계와 아키텍처를 거쳐 맨 위에는 위임과 오케스트레이션이 옵니다. 모든 엔지니어가 수십에서 수천 명 규모의 에이전트를 관리하는 스태프 엔지니어가 된다는 것이 이 관점의 표현입니다.

하네스는 에이전트가 실패하지 않도록 설계해 둔 운영 환경입니다. 컨텍스트, 도구, 가드레일 세 가지로 이루어집니다. 사람은 티켓을 쓰고 비전을 제시하고, 그 사이의 하네스 영역에서 에이전트가 도구를 쓰며 코드를 만들고, 결과가 코드베이스에 반영됩니다.

하네스는 단순한 IDE가 아닙니다. 모델이 작업을 끝까지 해내도록, 정확한 타이밍에 알맞은 제약 조건과 지침을 먹여 주는 자동화된 환경입니다.

처음부터 모든 정보를 에이전트에게 주면 오히려 압도당합니다. 핵심은 점진적으로, 필요한 시점에 필요한 정보만 주는 것입니다.

시작점인 티켓 단계에서는 비즈니스 로직과 핵심 목표를 넣습니다. 구현 중에는 린트를 통해 코드 표준과 컨벤션을 알려 줍니다. 검증 단계의 테스트에서는 아키텍처 제약을 걸어 두는데, 슬라이드가 든 예는 파일 길이를 350줄 이하로 제한하는 규칙입니다. 마지막 리뷰 에이전트 단계에서는 보안과 신뢰성 같은 비기능 요구사항을 확인시킵니다.

에이전트에게 지침이 되는 것은 프롬프트 창만이 아닙니다. 저장소의 폴더 자체가 프롬프트 역할을 합니다.

tests/ 폴더는 컨텍스트의 한계를 강제하는 프롬프트입니다. eslint/custom-rules/는 에이전트가 스스로 코드를 고치도록 구체적인 해결책을 알려 주는 프롬프트입니다. docs/ADR/(설계 결정 기록)은 에이전트와 리뷰 봇에게 좋은 코드의 기준을 정의해 줍니다. 코드를 둘러싼 환경이 에이전트를 계속 이끄는 가장 강력한 프롬프트라는 것이 이 단계의 요점입니다.

src/
  components/
  tests/ # 컨텍스트의 한계를 강제
  eslint/custom-rules/ # 스스로 고치게 하는 해결책
  docs/ADR/ # 좋은 코드의 기준

에이전트가 엉뚱한 코드 패턴을 만들었다면 그 실패를 그냥 고치고 끝내지 않습니다. 사람이 근본 원인을 찾고, 그 지식을 문서와 맞춤형 테스트, 린트 규칙으로 남깁니다. 그다음에는 리뷰 에이전트가 CI에서 그 규칙을 영구적으로 강제합니다.

이렇게 돌리면 사람의 피드백이 시스템의 영구적인 지능으로 바뀌고, 같은 오류를 두 번 다시 확인할 필요가 없어집니다.

코드베이스의 물리적 구조가 에이전트의 성공률을 좌우합니다. 얽힌 거대한 모놀리스에서는 컨텍스트가 넘치고 부작용을 예측하기 어려우며 에이전트가 환각을 일으키기 쉽습니다.

반대로 도메인별로 완전히 격리된 모듈형 패키지로 나누면 결과가 다릅니다. 슬라이드는 잘게 쪼갠 750개 패키지 사례를 예로 듭니다. 일관된 규칙과 작은 컨텍스트 범위가 곧 에이전트의 신뢰성으로 이어진다는 설명입니다.

이 관점에서 LLM은 퍼지 컴파일러입니다. 사람의 의도를 코드로 바꿔 주지만 결과가 정확히 고정되지는 않습니다. 그래서 코드는 쓰고 버리는 빌드 결과물에 가깝고, 사람의 진짜 역할은 타이핑이 아니라 의도를 안전하게 현실로 옮길 수 있는 제약 조건과 하네스를 설계하는 일이라고 정리합니다.

에이전트 시대의 개발은 코드를 얼마나 많이 만드느냐가 아니라, 에이전트가 실패하지 않는 환경을 얼마나 잘 설계하느냐의 싸움입니다. 컨텍스트는 필요한 순간에 나눠 주고, 저장소를 프롬프트로 다루고, 실패는 규칙으로 남기고, 구조는 잘게 쪼개 보세요.