Cursor가 /goal 기능을 공개했다. "모든 불안정한 테스트를 수정하고 CI를 통과시켜"라고 입력하면, 에이전트는 목표가 달성될 때까지 PR을 모니터링하고, CI 오류를 감지하고, 수정 사항을 반영하고, 다시 작업을 이어간다. Slack 이벤트도 구독하고, 하위 에이전트를 독립된 VM에 띄워 병렬로 버그를 잡는다. 커서가 이를 "long-lived objective"라고 부른 건 단순한 마케팅 언어가 아니다. 코딩 에이전트가 드디어 루프를 닫기 시작했다는 신호다.
그런데 이 뉴스를 접하고 느낀 첫 번째 감정이 설렘이 아닌 약간의 긴장감이었다면, 그건 꽤 정직한 반응이다. 에이전트가 목표를 스스로 유지하고, 이벤트에 반응하며, 루프를 돌린다는 건—그 루프 안에서 무슨 일이 일어나는지 개발자가 더 이상 자연스럽게 관찰할 수 없다는 뜻이기도 하다. 자율성이 높아질수록 "언제, 어디서, 어떻게 개입할 것인가"를 의식적으로 설계하지 않으면, 개발자는 결과만 보는 구경꾼이 된다.
이 긴장감을 가장 구체적으로 해소한 사례가 dev.to에 공개된 Claude Code 멀티 에이전트 워크플로우 설계다. 이 접근법의 핵심은 단순하다. Author 에이전트가 구현하고, Reviewer 에이전트가 독립적으로 검증하고, 사람이 최종 머지를 결정한다. 세 역할이 명확하게 분리되고, 각 경계에서 무엇이 넘어가고 무엇이 넘어가지 않는지가 엄격하게 정의된다.
이 워크플로우가 흥미로운 건 기술적인 정교함보다 그 철학 때문이다. Author와 Reviewer를 같은 대화 스레드 안에 두지 않는다. 같은 워킹 디렉토리에서 실행하지 않는다. 각 에이전트는 git worktree로 분리된 환경에서 커밋된 diff만 본다. 이유는 명확하다. 같은 프롬프트 기반 위에서 작동하는 두 에이전트는 서로의 오류를 상호 검증하는 척하면서 실제로는 같은 방향으로 확증 편향을 만든다. 에이전트끼리의 합의는 정답이 아니라 공명(共鳴)일 수 있다.
Handoff Card 개념도 주목할 만하다. Author 에이전트가 작업을 완료하면 구조화된 인수인계 문서를 생성한다. 변경된 파일, 실행한 테스트 커맨드와 결과, 남아 있는 리스크와 블로커. 날것의 채팅 로그도, 검증되지 않은 가정도 포함하지 않는다. 이 카드가 Reviewer 에이전트로 넘어가고, 검증 결과 요약이 사람에게 전달된다. 머지는 사람이 직접 git merge feat/payment-retry를 실행한다. 자동화는 최대한 밀어붙이되, 최종 게이트는 사람이 쥔다.
이 구조를 더 큰 맥락으로 확장한 게 H.I. First 관점이다. dev.to의 Masum Billah는 이렇게 표현한다. "LLM의 원시 출력은 인터넷의 통계적 평균이다." 빠르고, 그럴듯하고, 대부분의 경우 작동한다. 하지만 그 평균이 당신의 레거시 인프라 제약을 알지 못하고, 팀의 기술 부채 지형을 알지 못하고, 이번 분기 비즈니스 우선순위를 알지 못한다. 에이전트가 목표를 자율적으로 추구할수록, 그 목표를 정확하게 정의하고 맥락을 주입하는 행위는 더 높은 레버리지를 갖는다.
그렇다면 자율 에이전트 시대에 개발자가 설계해야 할 개입 지점은 어디인가. 세 소스를 겹쳐보면 윤곽이 나온다.
첫 번째, 목표 정의 지점. Cursor의 /goal이 강력한 건 에이전트가 루프를 돌기 때문이 아니라, 개발자가 "무엇이 완료 상태인가"를 명확히 선언해야 하기 때문이다. 막연한 목표를 넣으면 에이전트는 막연하게 루프를 돈다. "CI를 통과시켜"는 구체적이다. "코드를 더 좋게 만들어"는 에이전트가 루프를 끝낼 수 없다. 목표 정의는 에이전트를 시작시키기 전 사람이 반드시 해야 할 설계 작업이다.
두 번째, 역할 경계 지점. Author와 Reviewer를 분리하듯, 어떤 에이전트가 어떤 범위에서만 작동하는지를 명시적으로 제한해야 한다. Cursor의 Custom Mode와 하위 에이전트 격리가 그 도구다. 에이전트가 "무엇이든 할 수 있는" 상태는 편리해 보이지만, 실제로는 책임 경계가 사라진 상태다. 개발자가 역할 경계를 설계하지 않으면, 에이전트가 암묵적으로 그 경계를 그어버린다.
세 번째, Human Sign-off 지점. Claude Code 워크플로우가 자동 머지를 하지 않는 이유는 기술적 한계가 아니다. 아키텍처 결정, 보안 판단, 비즈니스 트레이드오프는 알고리즘이 온콜 로테이션을 돌지 않는다는 사실과 연결된다. 결과에 책임지는 사람이 있어야 하는 지점에는 반드시 Human Sign-off가 있어야 한다. 자동화 비율이 높아질수록 이 지점을 어디에 놓을지가 더 중요해진다.
흥미로운 건 Cursor가 이미 이 긴장을 의식하고 있다는 점이다. 에이전트가 작업 중일 때 후속 메시지를 보내도 진행 중인 도구 호출을 즉시 중단하지 않고, 다음 도구 호출 시점에 새로운 지시를 반영하도록 바꿨다. 이 작은 변화는 "자율성과 개입 가능성이 공존할 수 있다"는 설계 원칙의 표현이다. 에이전트를 멈추지 않아도 방향을 바꿀 수 있는 핸들, 그것 자체가 하나의 개입 지점 설계다.
결국 질문은 이것이다. 에이전트가 더 오래, 더 자율적으로 작동하는 세계에서 개발자의 역할은 줄어드는가. 그렇지 않다. 역할의 종류가 바뀐다. 코드를 한 줄씩 검토하는 시간이 줄어드는 대신, 목표를 설계하고, 경계를 정의하고, 신뢰할 수 있는 검증 구조를 만들고, 최종 판단을 내리는 일이 개발자의 핵심 레버리지가 된다. H.I. First가 말하는 20%의 거버넌스 레이어가 바로 그것이다. AI가 80%의 실행을 가져갈수록, 그 20%의 밀도가 제품의 품질과 안전성을 결정한다.