AI 에이전트에게 일을 잘 시키려면 '공정'을 먼저 설계해야 한다

한줄 요약

AI 에이전트가 커진 코드베이스에서 실수를 반복하는 이유는 도구 탓이 아니라 공정 부재 탓이다.

AI 코딩 도구를 도입한 개발팀이 공통적으로 겪는 전환점이 있다. 초반에는 빠르게 결과가 나온다. 그런데 프로젝트 규모가 커지고 코드가 쌓이면서 어느 순간부터 AI가 계획을 제대로 따르지 않거나, 엉뚱한 방향으로 구현하거나, 중요한 맥락을 놓치는 일이 잦아진다. 결국 사람이 다시 일일이 검토하고 수정하는 시간이 늘어난다.

이건 도구의 한계가 아니다. 공정이 없기 때문이다.

AI가 커진 프로젝트에서 흔들리는 이유

AI 에이전트는 주어진 컨텍스트 안에서만 판단한다. 프로젝트 초기에는 코드와 맥락의 양이 적어서 AI가 전체 그림을 잡을 수 있다. 하지만 기능이 늘고 파일이 쌓이면 컨텍스트 윈도우 한계에 부딪힌다. AI는 전체를 보지 못한 채 부분적으로 판단하기 시작하고, 그 결과물은 사람이 기대한 것과 달라진다.

외주 개발 프로젝트에서도 같은 구조의 문제가 생긴다. 작은 MVP는 빠르게 나오는데, 유지보수와 기능 추가가 반복될수록 일정이 늘어지고 품질이 흔들린다. AI 도구를 쓰든 사람이 하든, 공정 없이 규모가 커지면 결과는 비슷하게 흔들린다.

공정 설계란 무엇인가 — 하네스 엔지니어링의 개념

하네스 엔지니어링(Harness Engineering)은 AI 에이전트가 실수 없이 일관되게 작동하도록 작업 흐름 자체를 설계하는 방식이다. 단순히 프롬프트를 잘 쓰는 것과 다르다. 계획, 구현, 검증, 배포 준비 각 단계를 명확히 분리하고, 각 단계에서 AI가 해야 할 일과 사람이 확인해야 할 기준을 정의하는 구조적 접근이다.

핵심 원리는 두 가지다.

첫째, 메인 에이전트의 컨텍스트를 아껴야 한다. 모든 작업을 하나의 에이전트에게 몰아주면 컨텍스트가 빠르게 소진되고, 그 순간부터 AI의 판단력이 저하된다. 역할을 나눠 서브에이전트들이 각 단계를 처리하고 결과만 메인에 전달하면, 메인 에이전트는 전체 흐름을 훨씬 안정적으로 관리할 수 있다.

둘째, 사람이 결정해야 할 것과 AI에게 맡겨도 되는 것을 명확히 분리해야 한다. 스펙 하나라도 AI가 임의로 결정한 채 구현으로 넘어가면, 그 결정은 나중에 반드시 부채가 된다. "왜 이렇게 만들어졌지?"라는 질문이 생기는 시점이 바로 이 분리가 실패한 지점이다.

단계별로 무엇을 설계해야 하는가

계획 단계에서 가장 중요한 건 스펙의 소유권이다. 어떤 기능을 어떻게 만들지, 어떤 예외 케이스를 처리할지—이 결정들이 사람에게서 나왔는지 AI에서 나왔는지를 추적하는 구조를 만들어야 한다. AI가 결정한 스펙이 하나라도 있다면, 구현 전에 사람이 다시 검토하는 루프를 의도적으로 넣어야 한다.

구현 단계에서는 병렬 처리와 반복 리뷰가 핵심이다. 백엔드, 프론트엔드, 인프라 등 영역별로 서브에이전트를 나눠 동시에 작업시키고, 각 결과물이 초기 계획과 일치하는지 자동으로 검토하는 루프를 설계한다. 한 번에 통과하는 경우는 드물다. 두세 번 수정-리뷰를 반복하는 게 정상적인 흐름이라고 보고 설계해야 한다.

검증 단계는 '배포해도 된다'는 확신을 만드는 단계다. 정상 시나리오뿐 아니라 회귀 테스트, 엣지 케이스, 핵심 기능 보호 케이스를 나눠 체계적으로 테스트 케이스를 작성하면, AI가 구현한 결과물을 사람이 일일이 확인하지 않고도 신뢰할 수 있는 기반이 생긴다. 이 단계에 투자하는 시간이 많을수록 이후 유지보수 비용이 줄어든다.

PR 및 배포 준비 단계에서는 회고가 빠지면 안 된다. 이번 구현 과정에서 AI가 어떤 실수를 했고, 어떤 부분에서 계획과 어긋났는지를 문서로 남겨 다음 사이클에 반영한다. 이 반복이 쌓이면 팀의 개발 공정 자체가 고도화된다.

외주 개발사가 이 구조에서 얻을 수 있는 것

외주 개발 업체 입장에서 하네스 엔지니어링은 단순한 생산성 도구가 아니다. 팀 전체의 개발 품질을 일관되게 유지하는 인프라다.

시니어 개발자의 판단과 노하우를 공정 안에 녹여두면, 주니어 개발자도 같은 기준으로 작업하게 된다. 담당자가 바뀌어도 품질이 흔들리지 않는다. 클라이언트 입장에서는 개발사 내부 인력 변동이 결과물 품질에 영향을 미치지 않는다는 신뢰를 갖게 된다.

또한 모든 결정과 구현 과정이 문서로 남기 때문에 프로젝트 이후 유지보수 단계에서도 맥락을 다시 파악하는 비용이 크게 줄어든다. 개발 지식이 특정 개인에게 묶이지 않고 팀 자산으로 축적된다.

처음 공정을 설계하는 데는 시간이 든다. 아키텍처 기준, 코드 컨벤션, DB 설계 원칙 같은 것들은 AI가 대신 결정해 줄 수 없는 영역이고, 사람의 시간이 고스란히 투입되어야 한다. 하지만 한 번 제대로 설계된 공정은 이후 모든 프로젝트에서 복리로 돌아온다.