Enhanmcnet suggestion and analysis

아래 프롬프트를 새 AI 모델에 그대로 전달하고, 프로젝트 전체 코드 저장소에 접근할 수 있게 하세요. 이 프롬프트는 “무조건 다시 만들기”가 아니라, 실제 운영 가능성을 증거 기반으로 평가하고 우선순위별 개선 계획을 만들도록 설계했습니다.

당신은 다음 역할을 동시에 수행하는 수석 소프트웨어 아키텍트, Staff/Principal Engineer, 보안 엔지니어, SRE/DevOps 엔지니어, QA 리드, 데이터베이스 전문가, 제품 엔지니어입니다.

나는 소프트웨어 개발과 아키텍처를 전문적으로 알지 못하는 제품 소유자입니다. 이 프로젝트는 AI 또는 바이브 코딩 방식으로 개발되었을 수 있으므로, 코드가 동작하는 것처럼 보여도 구조적 결함, 숨은 버그, 보안 문제, 확장성 문제, 유지보수 문제, 운영 장애 가능성이 있을 수 있습니다.

당신의 목표는 프로젝트를 비판하거나 무조건 재작성하는 것이 아닙니다. 현재 상태를 객관적으로 조사하여 다음 질문에 답하는 것입니다.

1. 이 제품은 현재 운영 환경에 배포할 수 있는가?
2. 배포한다면 어떤 조건과 위험을 감수해야 하는가?
3. 어떤 문제는 반드시 배포 전에 해결해야 하는가?
4. 어떤 문제는 배포 후 개선해도 되는가?
5. 현재 아키텍처와 코드가 장기적으로 유지보수, 수정, 확장 가능한가?
6. 실제 사용자와 사업에 치명적인 위험은 무엇인가?
7. AI 에이전트나 전문 개발자가 어떤 순서로 무엇을 수정해야 하는가?

중요한 원칙:

- 코드를 충분히 조사하기 전에는 결론을 내리지 마십시오.
- 확인하지 못한 내용은 사실처럼 말하지 마십시오.
- 추측, 확인된 사실, 추가 조사가 필요한 사항을 명확히 구분하십시오.
- 단순히 “코드가 나쁘다”라고 말하지 말고 파일 경로, 함수명, 클래스명, 관련 코드 위치를 근거로 제시하십시오.
- 가능하면 줄 번호를 포함하십시오.
- 문제를 발견하면 심각도와 실제 영향을 설명하십시오.
- 전체 재작성은 최후의 수단으로만 제안하십시오.
- 기존 코드를 함부로 수정하지 마십시오. 먼저 분석 보고서를 완성하십시오.
- 실행 가능한 테스트, 정적 분석, 빌드, 린트, 타입 검사 명령을 찾아 실행하십시오.
- 실행한 명령과 결과를 보고서에 기록하십시오.
- 테스트가 없거나 신뢰할 수 없는 경우 그 사실을 명확히 표시하십시오.
- “문제 없음”이라고 판단할 때도 어떤 검사를 했는지 설명하십시오.
- 비밀번호, API 키, 개인정보, 실제 사용자 데이터 등 민감한 값을 보고서에 노출하지 마십시오.
- 프로젝트의 기존 변경사항이나 작업물을 임의로 삭제하지 마십시오.

다음 순서로 작업하십시오.

# 1. 프로젝트 구조 파악

먼저 다음을 조사하십시오.

- 사용 언어와 프레임워크
- 애플리케이션 유형
- 주요 진입점
- 프론트엔드와 백엔드 구조
- 데이터베이스와 데이터 모델
- 외부 API 및 외부 서비스
- 인증과 권한 관리
- 백그라운드 작업, 큐, 스케줄러
- 배포 방식과 인프라
- 환경 변수와 설정 관리
- 테스트, 린트, 타입 검사, CI/CD
- 문서와 운영 절차

프로젝트를 실제로 실행하거나 검사할 수 있다면 실행하십시오.

# 2. 기능 및 도메인 이해

코드를 읽고 제품의 핵심 기능과 주요 업무 규칙을 추론하십시오.

다음 내용을 작성하십시오.

- 사용자가 할 수 있는 주요 작업
- 주요 사용자 유형과 권한
- 중요한 업무 규칙
- 핵심 데이터 흐름
- 주요 상태 변화
- 결제, 정산, 재고, 예약, 승인, 알림 등 중요한 비즈니스 로직
- 데이터가 생성, 변경, 삭제되는 지점
- 외부 시스템과의 연동 방식

코드로 확인되지 않는 내용은 “확인할 수 없음”이라고 표시하십시오.

# 3. 아키텍처 평가

다음 항목을 평가하십시오.

- 모듈과 책임의 분리
- 의존성 방향
- 결합도와 응집도
- 도메인 로직과 UI/인프라 로직의 분리
- 데이터 접근 방식
- API 설계
- 오류 처리 구조
- 동기/비동기 처리
- 트랜잭션과 일관성
- 상태 관리
- 확장성과 병목 가능성
- 단일 장애 지점
- 중복 코드
- 순환 의존성
- 임시방편 코드와 기술 부채
- 향후 기능 추가의 난이도
- 기존 코드를 안전하게 수정할 수 있는 정도

각 문제에 대해 다음 형식을 사용하십시오.

- 문제:
- 위치:
- 확인된 근거:
- 실제 영향:
- 심각도: Critical / High / Medium / Low
- 권장 조치:
- 수정하지 않았을 때의 위험:
- 수정 난이도:
- 확신도: High / Medium / Low

# 4. 코드 품질과 유지보수성 평가

다음 항목을 검사하십시오.

- 읽기 어려운 코드
- 지나치게 큰 파일이나 함수
- 잘못된 추상화
- 명확하지 않은 이름
- 중복 로직
- 숨은 전역 상태
- 매직 넘버와 하드코딩
- 예외를 무시하는 코드
- 잘못된 null/undefined 처리
- 타입 안정성
- 안전하지 않은 기본값
- 주석과 실제 코드의 불일치
- 사용되지 않는 코드
- 죽은 코드
- 일관성 없는 패턴
- AI 생성 코드로 의심되는 불필요한 복잡성
- 수정 시 다른 기능을 깨뜨릴 가능성

# 5. 정확성과 비즈니스 규칙 검사

특히 다음을 집중적으로 검사하십시오.

- 경계값
- 중복 요청
- 동시 요청
- 재시도
- 부분 실패
- 네트워크 오류
- 시간대와 날짜
- 통화와 소수점 계산
- 상태 전이
- 권한 우회
- 삭제 및 복구
- 데이터 중복
- 중복 결제 또는 중복 처리
- 멱등성
- 트랜잭션 처리
- 오래된 데이터와 누락된 데이터
- 잘못된 입력
- 비정상적인 사용자 흐름

업무 규칙이 코드에 명확히 표현되어 있지 않다면 그 위험을 설명하십시오.

# 6. 보안 및 개인정보 검사

다음 항목을 검사하십시오.

- 인증 우회
- 권한 상승
- IDOR 및 객체 접근 제어 문제
- SQL/NoSQL/명령어/템플릿 인젝션
- XSS
- CSRF
- SSRF
- 파일 업로드 취약점
- 안전하지 않은 직렬화
- 민감정보 노출
- 로그에 비밀번호나 토큰 기록
- 잘못된 CORS
- 보안 헤더
- 세션과 쿠키 설정
- 비밀번호 저장 방식
- API 키 관리
- 환경 변수 관리
- 의존성 취약점
- rate limiting
- brute-force 방어
- 개인정보 보존 및 삭제
- 관리자 기능 보호
- 웹훅 검증
- 외부 API 응답 신뢰 문제

실제 악용 가능성이 있는 문제는 예시 공격 시나리오와 방어 방법을 설명하십시오. 단, 실제 시스템을 공격하거나 데이터를 파괴하지 마십시오.

# 7. 테스트와 검증 가능성 평가

검사하십시오.

- 단위 테스트
- 통합 테스트
- API 테스트
- E2E 테스트
- 권한 테스트
- 실패 케이스 테스트
- 데이터베이스 테스트
- 회귀 테스트
- 테스트 데이터 품질
- 테스트의 신뢰성
- 테스트가 실제 핵심 기능을 보호하는지
- 테스트하기 어려운 구조

현재 부족한 테스트를 우선순위별로 제안하고, 각 테스트의 목적과 검증해야 할 시나리오를 작성하십시오.

# 8. 성능 및 확장성 평가

다음 항목을 조사하십시오.

- 느린 데이터베이스 쿼리
- N+1 쿼리
- 적절하지 않은 인덱스
- 대량 데이터 처리
- 메모리 누수
- 불필요한 네트워크 호출
- 캐시 사용
- 캐시 무효화
- 동시성
- 요청 시간 초과
- 재시도 폭주
- 작업 큐
- 파일 및 이미지 처리
- 프론트엔드 번들 크기
- 초기 로딩
- 페이지네이션
- 수평 확장 가능성
- 트래픽 증가 시 병목

측정하지 못한 것은 추측하지 말고 “측정 필요”로 표시하십시오.

# 9. 운영 및 배포 준비도 평가

다음 항목을 검사하십시오.

- 개발/테스트/스테이징/프로덕션 환경 분리
- 환경 변수 관리
- 배포 재현성
- 데이터베이스 마이그레이션
- 롤백 방법
- 백업 및 복구
- 로그
- 모니터링
- 알림
- 헬스 체크
- 장애 대응
- 감사 로그
- 배포 중 다운타임
- 비밀값 관리
- 의존 서비스 장애 처리
- 운영 문서
- 비용 위험
- 장애 발생 시 원인 분석 가능성

# 10. 제품 관점 평가

비기술적인 제품 소유자가 이해할 수 있도록 설명하십시오.

- 사용자가 실패할 가능성이 높은 지점
- 데이터가 사라지거나 잘못될 가능성
- 신뢰를 잃을 수 있는 문제
- 고객 지원 비용을 증가시킬 문제
- 사업에 직접적인 손실을 줄 문제
- 규정 또는 계약상 위험
- 출시를 지연시킬 문제
- 지금 해결할 문제와 나중에 해결할 문제

# 11. 출시 판정

다음 중 하나로 판정하십시오.

- Production Ready
- Conditionally Ready
- Not Ready
- Do Not Deploy

판정에는 반드시 다음을 포함하십시오.

- 판정 이유
- 출시 전 필수 조건
- 조건부 출시가 가능한 경우의 제한사항
- 남아 있는 위험
- 출시 후 첫 30일 동안 관찰할 지표
- 긴급 롤백 기준

# 12. 우선순위별 실행 계획

문제를 다음 단계로 분류하십시오.

P0: 출시 전에 반드시 해결해야 하는 치명적 문제
P1: 빠른 시일 내 해결해야 하는 높은 위험
P2: 계획적으로 개선할 유지보수/확장성 문제
P3: 선택적 품질 개선

각 작업에 대해 다음을 작성하십시오.

- 작업 ID
- 제목
- 문제 설명
- 관련 파일과 위치
- 선행 작업
- 예상 영향
- 위험도
- 구현 방향
- 필요한 테스트
- 완료 조건
- 작업 후 검증 방법

작업 순서는 의존성을 고려하여 제안하십시오.

# 13. AI 에이전트용 기술 구현 지침

별도의 Markdown 문서에 다음 내용을 작성하십시오.

- 전체적인 권장 아키텍처 방향
- 유지해야 할 현재 구조
- 단계적으로 변경해야 할 구조
- 절대 먼저 하지 말아야 할 변경
- 리팩터링 순서
- 데이터베이스 변경 전략
- API 호환성 전략
- 테스트 추가 순서
- 보안 수정 순서
- 배포 및 롤백 전략
- 각 작업을 수행할 때 AI 에이전트가 따라야 할 규칙
- 작업 완료 후 실행할 검증 명령
- 완료로 인정할 수 있는 수용 기준
- 예상되는 추가 질문과 불확실성

AI 에이전트가 한 번에 대규모 재작성하지 않도록 하십시오. 작고 검증 가능한 단계로 나누십시오. 각 단계마다 테스트와 롤백 가능성을 포함하십시오.

# 최종 산출물

프로젝트 루트에 다음 두 파일을 생성하십시오.

1. `production-readiness-report.html`

요구사항:

- 제품 소유자도 이해할 수 있는 쉬운 표현
- 한눈에 보는 출시 판정
- 위험도별 요약
- P0/P1/P2/P3 문제 목록
- 아키텍처, 보안, 정확성, 테스트, 성능, 운영 섹션
- 각 문제의 실제 영향과 근거
- 파일 경로 및 코드 위치
- “확인된 사실”, “추정”, “추가 확인 필요” 구분
- 심각도 색상 표시
- 외부 라이브러리 없이 브라우저에서 바로 열 수 있는 단일 HTML 파일
- 표와 요약을 활용하되 과도하게 복잡하게 만들지 말 것

2. `technical-remediation-plan.md`

요구사항:

- 전문 개발자와 AI 코딩 에이전트가 실행할 수 있는 상세한 기술 계획
- 작업 ID와 우선순위
- 정확한 파일 위치
- 구현 방향
- 의존성
- 테스트 계획
- 수용 기준
- 배포 및 롤백 계획
- 불확실성과 추가 확인 사항
- 실행 명령
- 단계별 변경 전략

보고서 마지막에는 다음을 반드시 포함하십시오.

- 가장 위험한 문제 5개
- 출시 전에 반드시 해야 하는 작업
- 현재 상태에서 가장 현실적인 출시 전략
- 추가로 전문 엔지니어의 직접 검토가 필요한 영역
- 분석 과정에서 확인하지 못한 사항
- 분석에 사용한 명령과 그 결과
- 전체 분석의 신뢰도

분석이 끝난 뒤에는 파일을 생성했다는 사실만 말하지 말고, 최종 판정과 가장 중요한 위험 5개를 짧게 요약하십시오.

추가로, 이 프롬프트를 실행할 때 AI에게 다음 권한과 자료도 함께 제공하면 결과가 훨씬 좋아집니다.

• 실제 실행 가능한 개발 환경
• 데이터베이스 스키마 또는 테스트용 데이터
• 배포 설정
• 제품 요구사항 문서
• 사용자 역할과 권한 설명
• 핵심 업무 규칙
• 현재 알려진 버그 목록
• 테스트 계정
• CI/CD 설정

중요한 점은 이 보고서가 전문 엔지니어의 검토를 완전히 대체하지는 않는다는 것입니다. 다만 전문 엔지니어가 검토해야 할 영역과 우선순위를 크게 좁혀 주고, AI가 임의로 전체 코드를 재작성하는 일을 막는 실질적인 사전 점검 문서로 사용할 수 있습니다.