Claude나 Codex에 버튼 하나, API 하나를 만들어 달라고 하는 것과 서비스 하나를 맡기는 것은 다릅니다. 작은 요청은 구현할 내용을 프롬프트에 자세히 적을 수 있습니다. 서비스를 구현하려면 데이터 구조, 화면, API, 권한, 테스트와 배포를 함께 다뤄야 하므로 시작할 때 알 수 없던 선택이 계속 생깁니다.

이 글에서 위임하려는 단위는 Initiative입니다. 화면 하나를 만들거나 테스트 하나를 추가하는 일은 Task이고, 고객이 지원 요청을 등록하거나 처리 상태를 확인하게 만드는 것은 Feature입니다. 여러 Feature와 Task를 묶어 ‘고객지원 운영 서비스 v1을 구현해 배포 가능한 상태로 만든다’는 범위가 Initiative입니다.

AI 코딩 에이전트에게 Initiative를 맡기면 에이전트는 주어진 Task 목록만 실행하지 않습니다. 구현 중 드러난 문제에 맞춰 스스로 Task를 추가하거나 순서를 바꾸고, 여러 방법 중 서비스 목적에 맞는 방식을 고릅니다.

이 정도의 판단을 맡기려면 세 가지 기준을 미리 정해야 합니다. 계속 지킬 방향인 North Star, 이번 Initiative의 완료 기준인 Acceptance Criteria, 구현 중 넘지 말아야 할 선인 Guardrail입니다.

Initiative는 Task나 Feature보다 큽니다

하나의 서비스 구현 Initiative에는 여러 Feature와 Task가 들어갑니다.

구분범위예시
Task하나의 구현 행동지원 요청 API 추가, 권한 테스트 작성
Feature사용자가 이용할 수 있는 하나의 기능지원 요청 등록, 상담원 배정, 상태 알림
Initiative여러 Feature와 Task를 묶어 서비스 하나를 구현하는 범위고객지원 운영 서비스 v1 구현
North Star여러 Initiative가 함께 향하는 장기적인 사용자 가치고객이 접수부터 해결까지 현재 상태와 다음 단계를 알 수 있음

Feature와 Task 목록은 구현 계획이므로 바뀔 수 있습니다. 라이브러리가 예상과 다르거나 기존 구조와 충돌하면 에이전트가 Task를 다시 나누거나 Feature의 구현 순서를 바꿀 수 있습니다. 하지만 Initiative가 만들어야 할 서비스 결과와 North Star는 사람의 승인 없이 바꾸지 않습니다.

Task 몇 개나 Feature 하나가 끝났다고 Initiative가 끝나는 것도 아닙니다. 요청 화면과 API를 만들었더라도 상담원이 요청을 배정하지 못하거나 고객이 처리 상태를 확인할 수 없으면 서비스는 완성되지 않았습니다. 완료 여부는 서비스 전체의 Acceptance Criteria로 판정해야 합니다.

서비스 전체를 맡기면 프롬프트 밖의 선택이 생깁니다

AGENTS.md나 CLAUDE.md는 저장소에서 지킬 규칙을 알려 줍니다. SPEC이나 PRD는 구현할 서비스와 요구사항을 설명합니다. 하지만 구현을 시작한 뒤 만나는 모든 선택까지 미리 적을 수는 없습니다.

  • 지원 요청의 상태를 몇 단계로 나눌까요?
  • 상담원 배정과 알림을 하나의 흐름으로 처리할까요, 별도 대기열로 나눌까요?
  • 빠른 구현과 역할별 권한 통제가 충돌하면 무엇을 먼저 지킬까요?
  • 일부 Task의 테스트는 통과했지만 상담원이 요청을 처리하는 단계가 늘었다면 Initiative를 완료해도 될까요?

이 선택을 만날 때마다 사람에게 물으면 서비스 전체를 위임한 것이 아닙니다. 반대로 아무 기준 없이 에이전트에게 결정을 맡기면 개별 Feature는 만들어져도 전체 서비스의 흐름은 더 복잡해질 수 있습니다.

North Star는 이런 갈림길에서 어떤 선택이 우리가 계속 만들려는 사용자 가치에 더 가까운지 판단하는 기준입니다. 프롬프트가 다음 행동을 지시한다면, North Star는 프롬프트에 없는 선택의 방향을 정합니다.

방향, 완료와 경계는 서로 다른 기준입니다

세 기준은 같은 목표를 다른 말로 표현한 것이 아닙니다.

기준답해야 하는 질문유지되는 기간
North Star어떤 선택이 장기적인 사용자 가치를 더 좋게 만드는가?여러 Initiative 동안 유지
Acceptance Criteria이번 Initiative가 사용 가능한 결과를 만들었는가?Initiative가 끝날 때까지 유지
Guardrail이 선택을 해도 되는가, 사람의 승인이 필요한가?구현과 운영 중 계속 유지

North Star는 계속 만들고 싶은 사용자 가치입니다. NSM은 그 가치가 실제로 커지는지 확인할 대표 지표입니다. 예를 들어 North Star가 ‘고객이 접수부터 해결까지 현재 상태와 다음 단계를 알 수 있게 한다’라면, NSM은 ‘목표 시간 안에 해결된 지원 요청 비율’로 정의할 수 있습니다.

NSM의 현재 값과 다음 목표치는 바뀔 수 있습니다. 하지만 무엇을 재는지는 Initiative가 끝날 때마다 바꾸지 않습니다. 하나의 Initiative가 완료됐다는 말은 North Star에 도착했다는 뜻이 아니라, 그 방향으로 가는 한 구간을 끝냈다는 뜻입니다.

고객지원 운영 서비스를 맡겨 보겠습니다

AI 코딩 에이전트에게 다음 Initiative를 위임한다고 가정하겠습니다.

고객이 지원 요청을 등록하고 처리 상태를 확인하며, 상담원이 요청을 배정받아 답변할 수 있는 고객지원 운영 서비스 v1을 구현합니다.

이 Initiative는 화면 하나나 Feature 하나를 만드는 요청이 아닙니다. 서비스 전체를 구성하는 다음 범위를 포함합니다.

  • 고객과 상담원 계정, 역할별 권한 구현
  • 지원 요청 등록, 조회와 첨부 파일 처리
  • 상담원 배정, 우선순위와 상태 변경
  • 고객과 상담원의 답변 이력과 알림 연결
  • 권한, 상태 변경과 실패 복구 자동 테스트
  • 고객·상담원 브라우저 시나리오, 배포 설정과 배포 전 점검

에이전트는 구현 과정에서 Feature와 Task를 더 나누거나 순서를 바꿀 수 있습니다. 아래 기준은 바꾸지 않습니다.

항목위임 계약
North Star고객이 지원 요청을 접수한 뒤 해결될 때까지 현재 상태와 다음 단계를 알 수 있게 함
NSM목표 시간 안에 해결된 지원 요청 비율
Initiative고객지원 운영 서비스 v1을 구현해 배포 가능한 상태로 만듦
Acceptance Criteria고객의 요청 등록·조회, 상담원의 배정·답변, 역할별 권한, 상태 알림, 실패 복구와 브라우저 검증을 모두 통과함
Guardrail고객별 데이터와 권한을 분리하고, 개인정보를 로그에 남기지 않으며, 비밀 값을 저장소에 넣지 않음
에이전트의 자율 범위파일 구조, 라이브러리, 구현 방법과 Feature·Task 순서 선택
사람의 승인 필요인증 방식, 데이터 보관 정책, 외부 알림 서비스, 운영 자격 증명이나 실제 배포 변경
완료 증거자동 테스트, 고객·상담원 화면, 권한 시나리오, 배포 전 점검 결과와 알려진 제한

Finish Line은 새로운 완료 체계가 아닙니다. Initiative에 정한 Acceptance Criteria를 모두 검증한 지점을 이 글에서 Finish Line이라고 부릅니다. Anthropic의 장기 실행 에이전트 실험에서도 에이전트가 정해 둔 기능 목록을 실제로 검증하지 않고 너무 일찍 완료 처리하는 문제가 반복됐습니다. 따라서 기준을 직접 검증한 뒤에만 완료로 처리해야 합니다.

Finish Line을 통과하면 고객지원 운영 서비스 v1이라는 Initiative는 닫힙니다. North Star와 NSM의 정의는 다음 Initiative에서도 유지되고, 고객 데이터와 권한에 관한 Guardrail은 서비스 운영 중에도 지켜야 합니다.

North Star는 구현 방법을 고를 기준입니다

에이전트가 구현 방법을 선택할 때는 다음 세 가지를 확인합니다.

  1. 이 선택은 North Star의 사용자 가치를 더 좋게 만드나요?
  2. 이번 Initiative의 Acceptance Criteria를 충족하는 데 필요한가요?
  3. 정한 범위와 Guardrail 안에서 실행할 수 있나요?

세 질문에 답할 수 있으면 에이전트는 라이브러리, 파일 구조, 구현 순서와 Feature·Task 구성을 스스로 선택할 수 있습니다. North Star와 연결되지 않는 변경을 더하거나 Initiative의 범위를 넓히는 행동은 멈춥니다. 권한 확대, 데이터 수집 변경이나 실제 운영 배포처럼 Guardrail을 건드리는 결정은 사람에게 돌려줍니다.

에이전트에게 Initiative 전체를 위임할 수 있는 것은 프로젝트의 모든 맥락을 완벽히 이해해서가 아닙니다. 기준 안의 구현 판단은 에이전트가 맡고, 기준 자체를 바꾸는 판단은 사람이 맡기 때문입니다.

North Star는 실행 매뉴얼이 아닙니다

North Star만 적는다고 에이전트가 서비스를 끝까지 구현할 수 있는 것은 아닙니다. 각 기준과 문서는 서로 다른 역할을 맡습니다.

  • SPEC 또는 PRD: 어떤 서비스를 만들지 설명합니다.
  • AGENTS.md 또는 CLAUDE.md: 저장소에서 지킬 규칙을 정합니다.
  • North Star: 구현 중 선택의 방향을 정합니다.
  • Acceptance Criteria: Initiative의 완료 여부를 판정합니다.
  • Guardrail: 에이전트가 멈추고 사람에게 물어야 할 경계를 정합니다.
  • Eval과 테스트: 기준을 충족했다는 증거를 만듭니다.

구체적인 저장소 지침은 효과적인 CLAUDE.md와 AGENTS.md 작성법, 평가 방법은 AI Agent를 평가하는 방법, 권한과 인계 구조는 AI에게 안심하고 일을 맡기기 위한 점검에서 이어서 볼 수 있습니다.

퇴근 전, 위임 계약을 확인합니다

서비스 구현 Initiative를 시작하기 전에 아래 항목을 한곳에 적습니다.

# 계속 지킬 방향
North Star:
NSM Definition:
Current Value / 다음 Target:

# 이번에 끝낼 Initiative
Initiative가 제공할 서비스 결과:
Acceptance Criteria (Finish Line):
Guardrail:

# 실행과 인계
초기 Feature·Task 목록과 변경 가능한 범위:
에이전트가 스스로 결정할 수 있는 범위:
사람의 승인이 필요한 행동:
검증 명령과 합격 기준:
중단·격상 조건:
상태와 결정 기록 위치:

Feature와 Task 목록은 구현하면서 달라질 수 있습니다. 대신 Initiative의 결과, Acceptance Criteria와 Guardrail은 에이전트가 임의로 바꾸지 않습니다. 이처럼 바꿀 수 있는 Feature·Task 계획과 에이전트가 바꿀 수 없는 Initiative의 결과·기준을 구분해야 사람은 세부 구현을 일일이 승인하지 않고도 서비스 구현 전체를 맡길 수 있습니다.

AI 코딩을 오토로 돌린다는 것은 사람을 모든 과정에서 빼는 일이 아닙니다. 사람은 서비스가 향할 방향과 책임 경계를 정하고, 에이전트는 그 안에서 계획을 고쳐 가며 구현합니다.

오토의 수준은 에이전트가 얼마나 오래 실행되는지가 아니라, 서비스를 왜 이렇게 만들었고 어떤 기준으로 완료했는지 설명할 수 있는가에서 드러납니다.

참고한 자료