Prometheus 기획: 인터뷰식 요구사항 수집과 작업 계획 생성

학습 후 할 수 있는 것

Prometheus 기획 세션을 시작하여, 인터뷰 모드를 통해 프로젝트 요구사항을 명확히 파악
Prometheus의 "기획만 하고 구현하지 않는다"는 핵심 원칙 이해
Metis와 Momus를 활용하여 고품질, 누락 없는 작업 계획 생성
/start-work 명령어를 사용하여 계획을 Atlas에 위임하여 실행

현재의 어려움

상상해보세요, AI에게 복잡한 작업을 지시합니다: "인증 시스템을 리팩토링해줘".

5분 후, AI는 코드 작성을 시작합니다. 당신은 기뻐하며 시간을 절약했다고 생각합니다.

30분 후, 당신은 깨닫습니다:

AI는 어떤 인증 라이브러리를 사용할지 묻지 않았습니다 (JWT? NextAuth? Session?)
AI는 많은 요구사항을 추측했습니다 (예: "OAuth는 필수"라고 가정했지만, 실제로는 필요 없음)
코드가 반쯤 작성되었는데 방향이 틀려서, 전부 다시 해야 합니다
테스트 시 핵심 로직이 기존 시스템과 호환되지 않는 것을 발견

이것은 전형적인 "기획과 실행의 혼합" 문제입니다: AI는 요구사항이 명확하지 않을 때 일을 시작하여, 많은 재작업을 초래합니다.

언제 Prometheus를 사용할까

사용 시점

Prometheus에 적합한 장면:

복잡한 기능 개발 (예: "사용자 인증 시스템 추가")
대규모 리팩토링 (예: "전체 데이터 접근 계층 리팩토링")
아키텍처 설계 (예: "마이크로서비스 아키텍처 설계")
엄격한 품질 보증이 필요한 작업

Sisyphus에게 바로 실행을 위임하는 장면:

간단한 버그 수정 (예: "로그인 버튼 철자 오류 수정")
명확한 소규모 기능 (예: "3개의 입력 필드가 있는 폼 추가")

🎒 시작 전 준비

다음 설정이 완료되었는지 확인하세요:

[ ] Prometheus 에이전트가 활성화되어 있음 (기본 활성화)
[ ] 최소 하나의 AI Provider가 설정되어 있음 (Anthropic, OpenAI 등)
[ ] 기본 에이전트 개념을 이해하고 있음 (「AI 에이전트 팀: 10명의 전문가 소개」를 완료)

Prometheus 사용 가능 여부 확인:

bash

# OpenCode 채팅창에 입력
@prometheus

# 다음 Prometheus 프롬프트가 표시되어야 합니다:
# "안녕하세요, 저는 Prometheus - 전략 기획 컨설턴트입니다..."

핵심 개념

Prometheus의 핵심 신분 제약

Prometheus의 가장 중요한 특징은 무엇일까요? 그것은 절대로 코드를 작성하지 않는다는 것입니다.

기능	Prometheus	Sisyphus	Atlas
요구사항 수집	✅	❌	❌
작업 계획 생성	✅	❌	❌
코드 구현	❌	✅	✅ (위임)
작업 실행	❌	✅	✅ (위임)

이것이 왜 중요한가?

기획자 ≠ 실행자: 마치 제품 매니저가 코드를 작성하지 않는 것처럼, Prometheus의 책임은 "어떻게"가 아닌 "무엇을"
가정 방지: Prometheus가 코드를 직접 작성할 수 있다면, 요구사항이 명확하지 않을 때 "추측해서 하기"를 할 수 있습니다
강제적 사고: 코드 작성이 금지되면, Prometheus는 모든 세부사항을 명확히 질문해야 합니다

3단계 워크플로우

mermaid

flowchart LR
    A[사용자 입력 요구사항] --> B[Phase 1: 인터뷰 모드]
    B -->|요구사항 명확?| C[Phase 2: 계획 생성]
    C --> D[Metis 컨설팅]
    D -->|고정밀도 필요?| E[Momus 순환 검증]
    E -->|계획 완성| F[.sisyphus/plans/*.md 생성]
    C -->|고정밀도 불필요| F
    F --> G[/start-work 실행]

각 단계별 책임:

Phase 1 - 인터뷰 모드: 요구사항 수집, 코드베이스 연구, 지속적인 초안 업데이트
Phase 2 - 계획 생성: Metis에 컨설팅, 완전한 계획 생성, 요약 제시
Phase 3 - 실행: /start-work를 통해 Atlas에 위임

따라하기

Step 1: Prometheus 기획 세션 시작

이유 키워드 또는 명령어로 Prometheus를 트리거하여 인터뷰 모드로 진입합니다.

작업

OpenCode 채팅창에 입력하세요:

@prometheus 사용자 인증 시스템을 기획해줘

보게 될 것:

Prometheus가 인터뷰 모드 진입 확인
첫 번째 질문 제시 (예: "당신의 앱은 어떤 기술 스택인가요?")
초안 파일 .sisyphus/drafts/user-auth.md 생성

핵심 기능: 초안 파일

Prometheus는 지속적으로 업데이트합니다 .sisyphus/drafts/ 아래의 파일을. 이것이 그것의 "외부 메모리"입니다:

각 논의의 결정 기록
연구에서 발견한 코드 패턴 저장
명확한 경계 표시 (IN/OUT)

당신은 언제든지 초안을 확인하여 Prometheus의 이해가 올바른지 검증할 수 있습니다.

Step 2: 질문에 답하고, Prometheus가 컨텍스트를 수집하도록

이유 Prometheus는 실행 가능한 계획을 생성하기 위해 당신의 프로젝트를 "이해"해야 합니다. 그것은 추측하지 않고, 코드베이스 연구와 베스트 프랙티스 연구를 통해 근거를 얻습니다.

작업

Prometheus의 질문에 답하세요, 예를 들어:

사용자 입력:
내 앱은 Next.js 14, App Router이고, 현재 인증이 없습니다.
이메일 비밀번호 로그인과 GitHub OAuth를 지원하고 싶습니다.

Prometheus가 할 일:

explore 에이전트를 사용하여 기존 코드 구조 분석
librarian 에이전트를 사용하여 인증 베스트 프랙티스 조회
초안 파일의 "Requirements" 및 "Technical Decisions" 섹션 업데이트

보게 될 것:

프로젝트 구조를 분석하기 위해 탐색 에이전트를 시작했습니다...

1. explore: 기존 세션 패턴 조회
2. librarian: NextAuth 베스트 프랙티스 조회

결과가 반환되면 계속 질문하겠습니다.

Step 3: 초안 파일 확인 (선택사항)

이유 초안은 Prometheus의 "외부 메모리"이며, 당신은 언제든지 그것이 올바르게 이해하고 있는지 검증할 수 있습니다.

작업

bash

# 터미널에서 초안 내용 확인
cat .sisyphus/drafts/user-auth.md

보게 될 것 (유사한 내용):

markdown

# Draft: user-auth

## Requirements (confirmed)
- 기술 스택: Next.js 14, App Router
- 인증 방식: 이메일 비밀번호 + GitHub OAuth
- 현재 상태: 인증 구현 없음

## Technical Decisions
- 결정 없음

## Research Findings
- 탐색 에이전트 실행 중...

Step 4: 계속 답변하여 요구사항이 명확해질 때까지

이유 Prometheus는 "Clearance Checklist"를 가지고 있으며, 모두 체크된 후에야 자동으로 계획 생성으로 전환됩니다.

Prometheus의 판단 기준:

CLEARANCE CHECKLIST (ALL must be YES to auto-transition):
□ 핵심 목표가 명확한가?
□ 범위 경계가 명확한가 (IN/OUT)?
□ 남아있는 핵심 모호성이 없는가?
□ 기술 방안이 확정되었는가?
□ 테스트 전략이 확인되었는가 (TDD/수동)?
□ 차단 문제가 없는가?

작업

Prometheus의 질문에 계속 답하여 다음과 같이 말할 때까지:

모든 요구사항이 명확해졌습니다. Metis에 컨설팅하고 계획을 생성 중입니다...

보게 될 것:

Prometheus가 Metis 에이전트 호출
Metis가 누락될 수 있는 문제 분석
Prometheus가 Metis의 피드백에 따라 이해 조정

Step 5: 생성된 계획 확인

이유 계획 파일은 Prometheus의 최종 출력물이며, 모든 작업, 의존성, 수락 기준을 포함합니다.

작업

bash

# 생성된 계획 확인
cat .sisyphus/plans/user-auth.md

보게 될 것 (완전한 구조):

markdown

# User Authentication System

## Context
[원래 요구사항 설명]
[인터뷰 요약]
[Metis 분석 결과]

## Work Objectives
- 핵심 목표: 이메일 비밀번호 로그인과 GitHub OAuth 구현
- 구체적 산출물: 로그인 페이지, API 엔드포인트, 세션 관리
- 완료 정의: 사용자가 로그인하고 보호된 라우트에 접근할 수 있음

## Verification Strategy
- 인프라 존재: YES
- 사용자가 테스트 원함: TDD
- 프레임워크: vitest

## TODOs
- [ ] 1. NextAuth.js 설치 및 설정
  - References:
    - https://next-auth.js.org/getting-started/installation
  - Acceptance Criteria:
    - [ ] npm run test → PASS (1 test)

- [ ] 2. API 라우트 [...nextauth]/route.ts 생성
  - References:
    - src/lib/session.ts:10-45 - 기존 세션 패턴
  - Acceptance Criteria:
    - [ ] curl http://localhost:3000/api/auth/... → 200

- [ ] 3. 로그인 페이지 UI 구현
  - References:
    - src/app/login/page.tsx - 기존 로그인 페이지 구조
  - Acceptance Criteria:
    - [ ] Playwright 검증: 로그인 폼 표시
    - [ ] 스크린샷 .sisyphus/evidence/에 저장

...

Step 6: 실행 방식 선택

이유 Prometheus는 두 가지 선택을 줄 것입니다: 빠른 시작 또는 고정밀도 검증.

Prometheus의 제시 (Question 도구 사용):

## Plan Generated: user-auth

**Key Decisions Made:**
- NextAuth.js 사용 (Next.js App Router와 통합 우수)
- GitHub OAuth 제공자 + 이메일 비밀번호

**Scope:**
- IN: 로그인 기능, 세션 관리, 라우트 보호
- OUT: 회원가입 기능, 비밀번호 재설정, 사용자 프로필 편집

**Guardrails Applied:**
- 기존 세션 패턴을 따라야 함
- 핵심 비즈니스 로직 수정 금지

Plan saved to: `.sisyphus/plans/user-auth.md`

---

**Next Step**

어떻게 계속할까요?

1. **Start Work**: /start-work 실행. 계획이 안정적으로 보입니다.
2. **High Accuracy Review**: Momus가 모든 세부사항을 엄격하게 검증하도록 합니다. 검증 루프가 증가하지만 정밀도를 보장합니다.

작업

옵션 중 하나를 선택하세요 (OpenCode에서 버튼을 클릭하거나 옵션을 입력).

"Start Work"를 선택한 경우:

Prometheus가 초안 파일 삭제
/start-work 실행을 안내

"High Accuracy Review"를 선택한 경우:

Prometheus가 Momus 루프에 진입
Momus가 "OKAY"라고 할 때까지 지속적으로 피드백 수정
그 후 /start-work 실행을 안내

Step 7: 계획 실행

이유 계획은 Prometheus의 출력물이며, 실행은 Atlas의 책임입니다.

작업

bash

# OpenCode에 입력
/start-work

보게 될 것:

Atlas가 .sisyphus/plans/user-auth.md 읽기
boulder.json 상태 파일 생성
순서대로 각 TODO 실행
전문 에이전트에 작업 위임 (예: UI 작업은 Frontend에 위임)

체크포인트 ✅

boulder.json 파일이 생성됨
Atlas가 작업 1 실행 시작
각 작업 완료 후, 상태 업데이트

함정 주의사항

함정 1: 요구사항을 절반만 말하고 급하게 계획을 요구

문제:

사용자: @prometheus 사용자 인증을 만들어줘
사용자: 너무 많이 묻지 말고, 바로 계획을 생성해줘

결과: 계획에 가정이 가득 차 있어, 실행할 때 반복적으로 수정해야 합니다.

올바른 방법:

사용자: @prometheus 사용자 인증을 만들어줘
Prometheus: 당신의 앱은 어떤 기술 스택인가요? 현재 인증이 있나요?
사용자: Next.js 14, App Router이고, 인증이 없습니다
Prometheus: 어떤 로그인 방식을 지원해야 하나요?
사용자: 이메일 비밀번호 + GitHub OAuth
...
(계속 답변하여 Prometheus가 자동 전환될 때까지)

이 원칙을 기억하세요

기획 시간 ≠ 시간 낭비

5분을 들여 요구사항을 명확히 하면, 2시간의 재작업을 절약할 수 있습니다
Prometheus의 인터뷰 모드는 미래의 당신을 위해 "비용을 절감"하는 것입니다

함정 2: 초안 파일을 보지 않음

문제: Prometheus는 초안에 많은 결정과 경계를 기록하지만, 당신은 보지 않고 바로 계획 생성을 요구합니다.

결과:

계획에 잘못된 이해가 포함됩니다
실행할 때 "내가 이걸 요구한 적이 없는데?"라는 생각이 듭니다

올바른 방법:

1. 기획을 시작한 후, .sisyphus/drafts/ 파일을 계속 주시하세요
2. 오해를 발견하면 즉시 수정: "아니야, OAuth가 아니라 간단한 JWT야"
3. 수정한 후 계속 진행하세요

함정 3: 계획을 여러 번에 걸쳐 생성

문제:

사용자: 이 프로젝트가 너무 크니까, 먼저 1단계 계획만 하자

결과:

1단계와 2단계의 컨텍스트가 끊어집니다
아키텍처 결정이 일관되지 않습니다
여러 세션에서 요구사항이 누락됩니다

올바른 방법:

✅ 단일 계획 원칙: 아무리 크더라도, 모든 TODO는 하나의 .sisyphus/plans/{name}.md에 있어야 합니다

왜?

Prometheus와 Atlas는 모두 대형 계획을 처리할 수 있습니다
단일 계획은 아키텍처 일관성을 보장합니다
컨텍스트 단편화를 방지합니다

함정 4: Metis의 역할을 잊음

문제:

사용자: 요구사항을 다 말했어, 빨리 계획을 생성해줘
Prometheus: (Metis를 건너뛰고 바로 생성)

결과:

계획에 핵심 경계가 누락될 수 있습니다
"Must NOT Have"가 명확하게 제외된 범위가 없습니다
실행 시 AI slop(과도한 설계)이 발생합니다

올바른 방법:

✅ Metis 컨설팅은 필수입니다, 당신이 재촉할 필요가 없습니다

Metis가 할 일:

Prometheus가 물어야 했지만 묻지 않은 문제를 식별
명확히 해야 할 경계를 제안
AI의 과도한 엔지니어링 방지

함정 5: 테스트 전략 결정을 무시

문제: Prometheus가 "테스트가 필요한가요?"라고 물을 때, 당신이 "상관없어"라고 하거나 건너뜁니다.

결과:

테스트 인프라가 있는데도 TDD를 활용하지 못하면 기회를 놓칩니다
테스트가 없고 상세한 수동 검증 단계도 없으면, 실행 실패율이 높습니다

올바른 방법:

Prometheus: vitest 테스트 프레임워크가 보입니다. 작업에 테스트가 포함되어야 하나요?
사용자: YES (TDD)

영향:

Prometheus는 각 작업을 다음과 같이 구조화합니다: RED → GREEN → REFACTOR
TODO의 Acceptance Criteria에 테스트 명령이 명확히 포함됩니다
Atlas는 실행 시 TDD 워크플로우를 따릅니다

본 강의 요약

Prometheus 핵심 가치:

기획과 실행의 분리: "코드를 작성하지 않는다"는 강제적 제약을 통해 요구사항 명확화
인터뷰 모드: 지속적인 질문, 코드베이스 연구, 초안 업데이트
품질 보증: Metis 컨설팅, Momus 검증, 단일 계획 원칙

전형적인 워크플로우:

@prometheus [요구사항] 입력으로 기획 시작
질문에 답하고, .sisyphus/drafts/ 초안 확인
Prometheus가 자동 전환될 때까지 대기 (Clearance Checklist 모두 체크)
생성된 .sisyphus/plans/{name}.md 확인
"Start Work" 또는 "High Accuracy Review" 선택
/start-work 실행하여 Atlas에 위임

베스트 프랙티스:

계획을 급하게 요구하지 말고, 시간을 들여 요구사항을 이해하세요
초안 파일을 지속적으로 확인하고, 오해를 즉시 수정하세요
단일 계획 원칙을 따르고, 대형 작업을 분할하지 마세요
테스트 전략을 명확히 하여, 전체 계획 구조에 영향을 미치세요

다음 강의 예고

다음 강의에서는 **백그라운드 병렬 작업: 팀처럼 일하기**를 학습합니다.
배울 내용:
여러 에이전트가 병렬로 작업하여 효율성을 크게 높이는 방법
동시성 제한 구성, API 속도 제한 방지
백그라운드 작업 관리, 결과 가져오기 및 작업 취소
"실제 팀"처럼 여러 전문 에이전트 조정

부록: 소스 코드 참고

소스 코드 위치 보기

업데이트 시간: 2026-01-26

기능	파일 경로	라인 번호
Prometheus 시스템 프롬프트	`src/agents/prometheus-prompt.ts`	19-1184
Prometheus 권한 설정	`src/agents/prometheus-prompt.ts`	1187-1197
Metis 에이전트	`src/agents/metis.ts`	-
Momus 에이전트	`src/agents/momus.ts`	-
오케스트레이션 가이드 문서	`docs/orchestration-guide.md`	67-90

핵심 상수:

PROMETHEUS_SYSTEM_PROMPT: Prometheus의 신분, 워크플로우, 제약을 정의하는 완전한 시스템 프롬프트

핵심 함수/도구:

PROMETHEUS_PERMISSION: Prometheus의 도구 권한 정의 (.md 파일 편집만 허용)

비즈니스 규칙:

Prometheus 기본 모드: INTERVIEW MODE (인터뷰 모드)
자동 전환 조건: Clearance Checklist가 모두 YES
Metis 컨설팅: 필수, 계획 생성 전 실행
Momus 루프: 선택적 고정밀도 모드, "OKAY"까지 루프
단일 계획 원칙: 아무리 큰 작업이라도 모든 TODO는 하나의 .md 파일에
초안 관리: 지속적으로 .sisyphus/drafts/{name}.md 업데이트, 계획 완료 후 삭제

Prometheus 기획: 인터뷰식 요구사항 수집과 작업 계획 생성 ​

학습 후 할 수 있는 것 ​

현재의 어려움 ​

언제 Prometheus를 사용할까 ​

🎒 시작 전 준비 ​

핵심 개념 ​

Prometheus의 핵심 신분 제약 ​

3단계 워크플로우 ​

따라하기 ​

Step 1: Prometheus 기획 세션 시작 ​

Step 2: 질문에 답하고, Prometheus가 컨텍스트를 수집하도록 ​

Step 3: 초안 파일 확인 (선택사항) ​

Step 4: 계속 답변하여 요구사항이 명확해질 때까지 ​

Step 5: 생성된 계획 확인 ​

Step 6: 실행 방식 선택 ​

Step 7: 계획 실행 ​

함정 주의사항 ​

함정 1: 요구사항을 절반만 말하고 급하게 계획을 요구 ​

함정 2: 초안 파일을 보지 않음 ​

함정 3: 계획을 여러 번에 걸쳐 생성 ​

함정 4: Metis의 역할을 잊음 ​

함정 5: 테스트 전략 결정을 무시 ​

본 강의 요약 ​

다음 강의 예고 ​

부록: 소스 코드 참고 ​

Prometheus 기획: 인터뷰식 요구사항 수집과 작업 계획 생성

학습 후 할 수 있는 것

현재의 어려움

언제 Prometheus를 사용할까

🎒 시작 전 준비

핵심 개념

Prometheus의 핵심 신분 제약

3단계 워크플로우

따라하기

Step 1: Prometheus 기획 세션 시작

Step 2: 질문에 답하고, Prometheus가 컨텍스트를 수집하도록

Step 3: 초안 파일 확인 (선택사항)

Step 4: 계속 답변하여 요구사항이 명확해질 때까지

Step 5: 생성된 계획 확인

Step 6: 실행 방식 선택

Step 7: 계획 실행

함정 주의사항

함정 1: 요구사항을 절반만 말하고 급하게 계획을 요구

함정 2: 초안 파일을 보지 않음

함정 3: 계획을 여러 번에 걸쳐 생성

함정 4: Metis의 역할을 잊음

함정 5: 테스트 전략 결정을 무시

본 강의 요약

다음 강의 예고

부록: 소스 코드 참고