Skip to content

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의 가장 중요한 특징은 무엇일까요? 그것은 절대로 코드를 작성하지 않는다는 것입니다.

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

이것이 왜 중요한가?

  • 기획자 ≠ 실행자: 마치 제품 매니저가 코드를 작성하지 않는 것처럼, 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 검증, 단일 계획 원칙

전형적인 워크플로우:

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

베스트 프랙티스:

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

다음 강의 예고 ​

다음 강의에서는 **백그라운드 병렬 작업: 팀처럼 일하기**를 학습합니다.

배울 내용:

  • 여러 에이전트가 병렬로 작업하여 효율성을 크게 높이는 방법
  • 동시성 제한 구성, API 속도 제한 방지
  • 백그라운드 작업 관리, 결과 가져오기 및 작업 취소
  • "실제 팀"처럼 여러 전문 에이전트 조정

부록: 소스 코드 참고 ​

소스 코드 위치 보기

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

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

핵심 상수:

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

핵심 함수/도구:

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

비즈니스 규칙:

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