CLAB 인사이트 분석: 자동화는 스크립트가 맡고, LLM은 애매함을 줄인다

NAVER D2의 **「AI와 함께하는 프로젝트 자동화: 더 빠르고, 더 스마트하게」**는 CLAB 하네스를 만들 때 꽤 실용적인 힌트를 줬다. 이 자료의 핵심은 “모든 것을 LLM에게 맡기자”가 아니었다. 오히려 반대에 가깝다.

반복되는 작업은 자동화한다. 그런데 자동화 사이에 생기는 애매함, 의도 해석, 요약, 판단은 LLM이 맡는다. 이 경계가 분명해야 AI 자동화가 장난감이 아니라 작업 시스템이 된다.

LLM을 자동화의 중심에 두면 흔들린다

CLAB 하네스에서도 가장 위험한 설계는 이런 식이다.

요청을 받는다
→ LLM이 알아서 파일을 찾는다
→ LLM이 알아서 규칙을 고른다
→ LLM이 알아서 수정한다
→ LLM이 알아서 검증했다고 말한다

겉으로는 에이전트답지만, 실제로는 재현성이 낮다. 같은 요청을 해도 매번 다른 파일을 보고, 다른 기준을 적용하고, 다른 검증을 생략할 수 있다.

NAVER D2의 프로젝트 자동화 사례는 이 지점에서 유용했다. MCP agent, 로컬 모델, 외부 API 모델 같은 조합보다 더 중요한 것은 역할 분리였다. deterministic script가 할 수 있는 일은 script가 하고, LLM은 script가 다루기 어려운 부분에만 들어가야 한다.

CLAB 하네스의 경계

CLAB Agent Harness에 적용하면 경계는 이렇게 잡힌다.

스크립트가 맡을 일
- repo 구조 수집
- 변경 파일 목록 정리
- lint/build/test 실행
- diff hygiene 확인
- PR draft에 들어갈 기본 evidence 생성

LLM이 맡을 일
- 사용자의 자연어 요청을 task card로 좁히기
- 이번 변경의 책임 영역 판별하기
- 어떤 convention이 왜 적용되는지 설명하기
- 검증 결과를 사람이 읽을 수 있게 요약하기
- 팀 규칙으로 승격할 만한 반복 패턴 제안하기

이 경계가 없으면 하네스는 그냥 “프롬프트가 긴 AI 사용법”이 된다. 반대로 이 경계가 있으면 하네스는 팀의 작업 방식을 일정하게 만드는 실행 환경이 된다.

MCP보다 중요한 질문

자료에서는 MCP agent와 로컬 LLM, 외부 모델을 연결하는 구조가 나온다. 이 부분도 흥미롭지만 CLAB에 바로 가져올 핵심은 기술 이름 자체가 아니다. 더 중요한 질문은 이것이다.

AI가 어떤 도구를 쓸 수 있는가?
그 도구의 결과를 어떤 계약으로 해석할 것인가?
도구 실행 실패를 작업 실패로 볼 것인가, 보류로 볼 것인가?

예를 들어 CLAB 하네스에서 collect-context, check-diff-hygiene, clab-test 같은 script를 만든다면, LLM은 그 출력을 “참고 자료”로만 읽으면 안 된다. 어떤 출력은 작업을 막는 blocker가 되어야 하고, 어떤 출력은 PR 설명에 들어갈 evidence가 되어야 한다.