Project Lifecycle Agent
제안요청서와 예전 제안서·발표자료를 전달하면, Codex와 Claude Code가 제안 작성부터 프로젝트 운영까지 돕는 오픈소스 플러그인입니다. 외주/SI와 자체 서비스 프로젝트에 사용할 수 있습니다.
사용자는 업무 자료·목표·사업 결정을 전달합니다. 에이전트는 폴더 생성, 원본 등록, 분석, 산출물 제작, 검수와 진행 기록을 처리합니다. 일상적으로 PowerShell 명령을 입력하거나 JSON·CSV를 편집할 필요는 없습니다.
현재 코드 버전: 0.5.1 · 라이선스: MIT · GitHub 저장소
처음 사용한다면 이 순서로 진행하세요
- 사용하는 AI에 플러그인을 한 번 설치합니다.
- 고객 자료를 보관할 자기 작업 폴더를 AI에서 엽니다.
- RFP 또는 사업 아이디어로 새 프로젝트를 시작해 달라고 요청합니다.
- 준비된 폴더에 예전 정성제안서·발표자료를 넣고 분석을 요청합니다.
- 제안서·발표자료를 제작하고, 수주 후 같은 프로젝트에서 개발과 운영을 이어갑니다.
아래의 A사 고객 포털 사례를 자기 사업명과 파일 경로로 바꿔 사용하면 됩니다. 참고 템플릿이 없어도 RFP 분석과 초안 작성부터 시작할 수 있습니다.
1. 플러그인 설치 — 처음 한 번
Codex와 Claude Code 중 사용하는 제품에 설치합니다. 두 제품을 오가려면 각각 설치하세요. 일반 Claude 웹 채팅이 아니라 Claude Code용입니다.
호스트에 로그인되어 있어야 하며, 설치·실행에는 저장소를 받을 Git과 Python 3.10 이상 또는 호스트가 제공하는 Python 런타임이 필요합니다. 에이전트가 환경을 점검하고 가능한 준비를 처리합니다. 문서·발표자료 제작과 렌더링에는 호스트에서 사용할 수 있는 별도 제작 도구가 필요합니다.
Codex
Codex에 다음과 같이 요청하면 설치 도구를 사용할 수 있는 환경에서 에이전트가 처리할 수 있습니다.
Agics-hsjeong/project-lifecycle-agent의 main 브랜치를 marketplace로 등록하고,
project-lifecycle-agent 플러그인을 설치해줘. 설치 상태와 실행 환경도 확인해줘.
직접 설치하는 경우 아래 두 줄을 터미널에 한 줄씩 입력합니다. Windows에서는 PowerShell, macOS/Linux에서는 해당 터미널을 사용할 수 있습니다. 이 명령은 최초 설치용입니다.
codex plugin marketplace add Agics-hsjeong/project-lifecycle-agent --ref main
codex plugin add project-lifecycle-agent@project-lifecycle-marketplace
설치 후 Codex 앱을 다시 열거나 새 채팅을 시작합니다. 앱의 플러그인 목록에서도 등록된 project-lifecycle-marketplace의 설치·활성화 상태를 확인할 수 있습니다. codex 명령을 찾지 못하면 위 자연어 요청으로 CLI 위치와 설치 가능한 경로를 먼저 확인하게 하세요.
Marketplace 등록 방식은 OpenAI 공식 플러그인 문서를 따릅니다. 이 저장소의 marketplace를 직접 추가하는 방식이며, 공식 공개 디렉터리에 기본 등록된 플러그인이라는 뜻은 아닙니다.
Claude Code
Claude Code 대화 입력창에서 아래 두 줄을 한 줄씩 실행합니다. PowerShell에 입력하는 명령이 아닙니다.
/plugin marketplace add Agics-hsjeong/project-lifecycle-agent
/plugin install project-lifecycle-agent@project-lifecycle-marketplace
설치 범위를 선택하는 화면이 나오면, 여러 프로젝트에서 개인적으로 쓰는 경우 사용자 범위(User)를 선택하세요. 설치 후 새 세션을 시작합니다. /plugin에서 설치·활성화 상태를 볼 수 있습니다. 자세한 설치 방식은 Claude Code 공식 문서를 참고하세요.
스킬을 명시적으로 불러오는 방법
설치 후 프로젝트 관련 요청으로 자동 선택되지 않을 때 사용합니다.
| 제품 | 대화 입력창에 입력 |
|---|---|
| Codex | $project-lifecycle |
| Claude Code | /project-lifecycle-agent:project-lifecycle |
스킬을 선택한 뒤 아래 단계의 요청문을 전달하세요. 제품이 요구하는 파일 접근·설치 권한은 해당 제품 화면에서 허용해야 합니다.
2. 작업 폴더를 열고 RFP로 시작하기
플러그인 설치 폴더와 별도로 업무용 폴더를 준비합니다. 예를 들어 내 프로젝트/를 Codex 또는 Claude Code에서 작업 폴더로 열고, RFP를 첨부하거나 읽을 수 있는 파일 경로를 알려주세요.
Project Lifecycle Agent로 A사 고객 포털 사업을 시작해줘.
현재 작업 폴더를 업무 공간으로 쓰고 프로젝트 식별자는 a-portal로 해줘.
외주/SI 사업이고, 제안요청서는 [실제 RFP 파일 경로]에 있어.
프로젝트와 참고 템플릿 폴더를 준비하고 RFP 원본을 등록해줘.
사업 검토 초안, 요구사항, 평가기준, 제출 조건, 고객에게 확인할 질문을 정리해줘.
미정인 예산·일정·실적은 가정 또는 확인 필요로 표시해줘.
환경 확인, 파일 생성과 기록 관리는 네가 처리해줘.
[실제 RFP 파일 경로]는 자기 파일 위치로 바꿉니다. 채팅 첨부를 사용하는 경우 “첨부한 RFP”라고 요청할 수 있습니다. 에이전트가 실제로 접근할 수 있는 파일인지 확인한 뒤 등록합니다.
에이전트는 projects/a-portal/을 만들고 원본을 보존합니다. 요구사항에는 원문 페이지·절과 수용 기준을 연결하고, 현재 단계와 다음 작업을 기록합니다. 동일한 이름의 기존 프로젝트를 덮어쓰지 않습니다.
자체 서비스라면
RFP 없이 아이디어로 시작할 수 있습니다.
Project Lifecycle Agent로 학원 상담·수강 신청 서비스를 시작해줘.
자체 서비스 프로젝트이고 식별자는 academy-service야.
대상은 소규모 학원이며 목표는 상담 누락과 신청 관리 시간을 줄이는 것이야.
사업 가설, 사용자 문제, MVP 범위, 성공 지표와 실행 계획을 작성해줘.
프로젝트 폴더 생성과 관리 기록도 처리해줘.
자체 서비스의 제안 단계는 사업 실행안과 내부·투자 발표로 조정합니다. 기본 개발방법론은 하이브리드이며, 필요하면 “2주 스프린트 중심으로 운영해줘”처럼 운영 방식을 함께 알려주세요.
3. 자기 정성제안서·발표 템플릿 넣기
프로젝트가 만들어지면 아래 두 폴더에 과거에 사용한 자료의 사본을 넣습니다. 사용자가 빈 양식을 새로 만들 필요는 없습니다.
내 프로젝트/
└── projects/
└── a-portal/
└── templates/
├── qualitative/
│ ├── 공공기관_정성제안서.docx
│ └── 플랫폼구축_정성제안서.pdf
└── presentation/
├── 플랫폼구축_제안발표.pptx
└── 간결한스타일_발표.pdf
파일을 옮기는 대신 기존 자료 폴더의 경로를 알려줘도 됩니다. 에이전트가 해당 자료를 등록하고 프로젝트 안에 버전별 원본 사본을 보존합니다.
| 자료 | 권장 원본 | 그 밖에 참고할 수 있는 형식 |
|---|---|---|
| 정성제안서 | DOCX | DOTX, PDF, HWP, HWPX, PNG/JPG/JPEG/WebP |
| 발표자료 | PPTX | POTX, PDF, PNG/JPG/JPEG/WebP |
DOCX/PPTX는 원본 구조를 유지한 작업 사본을 만드는 데 유리합니다. PDF·HWP·이미지 등은 호스트의 읽기·OCR·렌더링 도구로 분석하며, 편집 가능한 원본 디자인을 그대로 복원할 수 있다는 보장은 없습니다. DOTX/POTX 변환도 호스트 도구 지원에 따릅니다.
자료를 넣은 뒤 다음처럼 요청합니다.
a-portal의 templates 폴더에 예전 제안서와 발표자료를 넣었어.
원본을 등록하고 문서별 디자인과 작성 방식을 분석해줘.
정성제안서는 공공기관_정성제안서.docx,
발표자료는 플랫폼구축_제안발표.pptx를 대표 스타일로 사용해줘.
서체·색상·여백·표·도식뿐 아니라 목차 전개, 핵심 메시지,
근거 제시 방식과 페이지·슬라이드 구성 패턴도 정리해줘.
이전 고객명·가격·인력·실적은 새 사업의 사실로 사용하지 마.
대표 자료를 지정하지 않고 후보가 여러 개라면 에이전트가 차이를 정리하고 선택을 요청합니다. 정성제안서와 발표자료는 서로 다른 대표 스타일을 선택할 수 있습니다. 분석 결과는 해당 프로젝트에 저장되므로 같은 폴더에서 다음 세션에도 활용할 수 있습니다.
여러 프로젝트에 쓸 회사 공통 자료가 있다면 “작업 공간에 reference-templates/qualitative/와 reference-templates/presentation/를 준비해줘”라고 요청한 뒤 자료를 넣고 그 경로를 알려주세요. 필요한 자료만 각 프로젝트의 참고 원본으로 등록합니다. 고객 자료를 플러그인 설치 캐시나 blueprint/에 넣지 마세요. 자기 업무 저장소를 공개할 때도 고객 원본·참고 자료의 제외 처리를 에이전트에게 요청하세요.
4. 정성제안서와 발표자료 만들기
RFP의 지정 목차·평가기준·제출 형식을 우선하고, 선택한 과거 자료의 스타일과 작성 노하우를 적용하도록 요청합니다.
a-portal의 RFP와 선택한 템플릿 분석 결과로 제안 패키지를 만들어줘.
RFP 지정 목차와 평가기준을 우선하고 대표 자료의 디자인·작성 패턴을 적용해줘.
정성제안서, 공수·일정 산정서, 평가항목 대응표,
제안 발표자료, 발표 대본·예상 Q&A, 제출 점검표를 작성해줘.
발표 시간은 RFP 기준으로 확인하고, 규정이 없으면 15분 초안으로 표시해줘.
편집 가능한 DOCX·PPTX와 제출용 PDF를 가능한 도구로 제작해줘.
생성본의 모든 페이지·슬라이드를 렌더링해서 원본 스타일과 비교하고,
잘림·겹침·글자 크기·이전 고객 정보 잔존·내용 및 수치 불일치를 수정해줘.
평가항목별 제안서 절·슬라이드·증빙 연결도 검사해줘.
완료 파일 경로, 검수 결과와 아직 확인할 사업 결정을 알려줘.
| 결과물 | 쓰임 |
|---|---|
| 정성제안서 | 사업 이해, 수행 전략, 기술·관리·운영 제안 |
| 공수·일정 산정서 | 범위·인력·일정·산정 근거 정리 |
| 평가항목 대응표 | 평가기준과 제안서 절·슬라이드·증빙 연결 |
| 발표자료 | 발표 흐름과 실제 슬라이드 |
| 대본·예상 Q&A | 시간 배분, 발표 노트, 질의응답 준비 |
| 제출 점검표 | 필수 파일·형식·버전·누락 확인 |
에이전트가 실제 제작 파일과 검수 근거의 경로를 안내합니다. 작성 자료는 docs/, 제작·내보내기 파일은 생성 시 마련하는 exports/ 등에서 관리합니다. Markdown 구성안만 작성한 상태를 최종 제출본 완료로 보고하지 않습니다. 호스트가 지정 형식 제작이나 렌더링을 지원하지 않으면 가능한 초안을 작성하고 미완료 형식·원인을 명시합니다. HWP 제출이 필수라면 RFP의 조건을 먼저 확인하게 하세요.
사용자는 실제 예산·인력·실적·수행 범위를 확인하고 사업 결정을 전달합니다. 기능 테스트와 문서·슬라이드 비교 검수는 에이전트가 수행합니다. 승인된 문서가 수정되면 변경 영향을 기록하고 필요한 재검토를 진행합니다. 외부 제출은 사용자가 지정한 대상과 권한에 따라 별도로 수행합니다.
5. 수주 후 같은 프로젝트에서 개발·납품·유지보수하기
수주했다고 새 프로젝트를 다시 만들 필요는 없습니다. 최종 계약서·협상 결과·일정 등 추가 자료를 전달합니다.
a-portal 사업을 수주했어. 첨부한 최종 계약서와 협상 결과를 등록해줘.
제안 내용과 달라진 범위·일정·납품 조건을 비교해줘.
확정 근거가 있는 항목을 반영하고 착수 계획, 역할, 마일스톤,
요구사항 기준선과 검수 기준을 준비해줘.
필요한 검토와 미결정을 정리하고 현재 단계에서 가능한 작업을 진행해줘.
프로젝트는 다음 흐름으로 관리합니다. 단계 이동은 실제 검토·승인 근거와 완료 기준에 따라 기록합니다.
사업 검토 → 제안 → 착수 → 기획·설계 → 디자인 → 퍼블리싱 → 구현 → 검증 → 배포 → 납품 → 유지보수
| 단계 | 에이전트가 돕는 일 | 요청 예시 |
|---|---|---|
| 착수·기획·설계 | 범위·일정·역할, 요구사항, 화면·데이터·API 설계 | “확정 요구사항으로 화면 흐름과 데이터·API 설계를 작성해줘.” |
| 디자인·퍼블리싱 | 디자인 기준, 화면 구현, 반응형·접근성 검수 | “승인된 화면과 디자인 기준으로 UI를 구현하고 검수해줘.” |
| 구현·검증 | 기능 구현, 요구사항·코드·테스트 연결, 결함 관리 | “현재 우선순위 기능을 구현하고 관련 테스트와 작업 기록을 갱신해줘.” |
| 배포·납품 | 배포·복구 계획, 릴리스, 검수, 운영·사용자 문서 | “검증 결과로 배포 준비를 점검하고 납품 산출물 목록을 정리해줘.” |
| 유지보수 | 장애·변경 영향, 수정·회귀 검증, 운영·릴리스 기록 | “이 장애를 등록하고 원인 분석, 수정과 회귀 검증을 진행해줘.” |
GitHub 저장소·브랜치·커밋·버전 기록과 배포 대상은 실제로 연결된 도구와 부여된 권한 안에서 다룹니다. 고객의 변경 요청은 영향 분석과 변경 기록에 반영합니다. 기존 승인을 임의로 만들거나, 자료가 바뀌었는데 완료 상태만 유지하지 않습니다.
소규모 사업은 불필요한 산출물의 제외 사유를 기록해 조정할 수 있습니다. 승인·검수·운영 결정처럼 실제 책임자의 판단이 필요한 사항은 근거를 받아 반영합니다.
6. 다음 날 이어하기 · Codex와 Claude Code 오가기
새 채팅을 시작하거나 AI를 바꿀 때 같은 고객 프로젝트 폴더를 엽니다. 위 예시에서는 projects/a-portal/입니다. 다른 PC라면 필요한 프로젝트 파일과 자료를 먼저 안전하게 동기화해야 합니다.
Project Lifecycle Agent로 이 프로젝트를 이어서 진행해줘.
project.json, 지침, HANDOFF.md, 원장과 실제 산출물을 확인해줘.
현재 단계, 최근 변경, 미완료 작업과 검토할 사항을 정리한 뒤
현재 승인된 범위에서 다음 작업을 진행해줘.
에이전트는 다음 파일을 통해 진행 상태를 이어받습니다. 사용자가 관리 파일을 직접 편집할 필요는 없습니다.
| 위치 | 보관 내용 |
|---|---|
project.json | 사업 유형·방법론·현재 단계·기술 정보 |
AGENTS.md, CLAUDE.md, process/ | 프로젝트 지침과 단계별 규칙 |
HANDOFF.md | 실제 변경·검증·미결정·다음 작업 |
inputs/ | RFP·고객 답변 등 입력 원본과 출처·버전 |
templates/ | 참고 원본·스타일 분석·선택·비교 검수 기록 |
docs/, registers/ | 업무 문서, 요구사항·작업·산출물·리스크 등 원장 |
working/templates/, exports/ | 제작 시 만드는 작업 사본과 결과 파일 |
공유되는 것은 프로젝트 파일과 기록입니다. 두 제품의 대화 내용이 자동으로 동기화되지는 않습니다. 여러 프로젝트가 있는 상위 폴더에서 작업하면 “a-portal을 이어서 진행해줘”처럼 대상을 알려주세요.
업데이트와 문제 해결
업데이트도 에이전트에게 요청할 수 있습니다.
Project Lifecycle Agent의 설치 소스와 버전을 확인하고 최신 main으로 업데이트해줘.
기존 고객 프로젝트와 원본 자료는 보존하고,
프로젝트에 새 양식이 필요하면 적용 차이와 이행 방법을 먼저 정리해줘.
설치된 두 제품은 각각 업데이트해야 합니다. 업데이트 후 새 세션을 시작하세요. 직접 관리하는 경우의 명령과 버전 고정 주의사항은 설치·업데이트 상세 안내에 있습니다.
| 상황 | 이렇게 요청하세요 |
|---|---|
| 설치했는데 스킬이 안 보임 | “설치·활성화·실제로 로딩되는 버전을 확인해줘.” 새 세션에서 명시적 스킬 호출도 사용합니다. |
| 예전 버전만 보임 | “marketplace가 옛 태그에 고정되어 있는지 확인하고 main 기준으로 업데이트해줘.” |
| RFP·템플릿을 읽지 못함 | “파일 접근과 형식·OCR 도구를 진단하고 읽지 못한 부분을 알려줘.” |
| 스타일이 기대와 다름 | 대표 파일·페이지·슬라이드와 원하는 특징을 지정하고 “원본과 생성본을 다시 비교해 수정해줘.” |
| 작업 중 종료됐거나 단계 이동이 막힘 | “진행 상태와 미완료 검토·변경·복구 필요를 진단하고 자료를 보존하며 해결해줘.” |
설치 오류를 해결하려고 고객 프로젝트나 캐시를 임의로 삭제할 필요는 없습니다. 실제 오류와 작업 경로를 에이전트에게 알려 진단하게 하세요.
실행·데이터 범위
- 이 플러그인은 호스트 AI가 활성 세션에서 사용하는 스킬·도구·양식입니다. 별도 모델 서버나 상시 작업 스케줄러는 포함하지 않습니다.
- 고객 프로젝트와 참고 원본은 플러그인 코드와 분리합니다. 이 저장소의
projects/,reference-templates/,.test-output/의 자료는 Git 추적·공개 패키징에서 제외합니다. 사용자의 별도 저장소는 공개 전에 제외 설정을 확인해야 합니다. - 원본 분석 결과는 프로젝트 파일에 저장합니다. 이를 모델 자체에 학습시키는 기능은 없습니다. 자료가 호스트 모델에 전달되는 방식은 사용하는 제품의 데이터 정책과 설정을 따릅니다.
- 기존 고객 프로젝트를 새 기본형으로 통째로 덮어쓰지 않습니다. 적용 차이·범위·이행 방법을 기록하고 필요한 항목을 보존하며 추가합니다.
상세 문서와 개발자 안내
| 문서 | 내용 |
|---|---|
| 설치·업데이트 | 제품별 설치와 업데이트 명령 |
| 참고 템플릿 | 원본 등록·스타일 분석·비교 검수와 지원 범위 |
| 제안 패키지 | 정성제안서·발표·평가 대응·제출 관리 |
| 업무 예시 | 단계별 진행 예시 |
| 엔진 운영·기존 프로젝트 적용 | 기록·검토·복구·이행 규약 |
| 플러그인 구조 | 제품별 manifest와 확장 방식 |
| 기본형 관리 | 스타터팩 자체의 유지관리 |
| 검증 기록 · 변경 이력 | 실제 검증 범위와 버전별 변경 |
개발자는 공통 양식 blueprint/, 사용자 진입점 skills/project-lifecycle/, 실행 도구 tools/를 수정합니다. 아래 명령은 플러그인 개발·배포용이며 일반 사용자 업무 절차가 아닙니다.
python -X utf8 -m unittest discover -s tests -v
python -X utf8 tools/package_plugin.py
현재 기능을 설치하려면 위 GitHub main 설치 방법을 사용하세요. Releases의 태그·ZIP은 특정 시점의 배포본이므로 main보다 이전 버전일 수 있습니다.