Turning78 · AI 기획 · 딜리버리 에이전트
Super Senior
기획을 문서로 끝내지 않고, 개발팀이 그대로 받을 수 있는 상태로 끝냅니다.
제안서와 회의록, 기존 화면과 정책 문서를 읽어 요구사항을 정리하고, PRD와 화면 명세를 쓰고, 실제로 눌러지는 프로토타입까지 만듭니다. 그리고 아직 결정되지 않은 것을 숨기지 않고 질문으로 남겨 인계합니다.
결론 먼저
Super Senior는 SI 프로젝트의 기획·설계 구간을 대신 수행하는 에이전트입니다
자료를 넘기고 몇 가지 질문에 답하면, 요구사항 정리부터 PRD, 화면 명세, 클릭되는 프로토타입, UX/UI 검토, 개발 인계 문서까지 정해진 순서대로 만들어 냅니다.
명세와 함께 브라우저에서 실제로 눌러지는 프로토타입이 나옵니다. 기획 설명 자료는 PowerPoint에서 문구·표를 바로 고칠 수 있는 편집형까지 함께 만듭니다.
PRD가 확정되기 전에는 UI 단계로 넘어가지 않습니다. 앞 단계에서 정한 용어·상태·정책이 다음 단계의 입력으로 그대로 넘어갑니다.
근거가 없는 항목은 추측으로 메우지 않고 미결정 질문 산출물과 실행 경고로 분리해 남깁니다. 빈 항목이 남은 결과는 아예 적용되지 않고 반려됩니다.
- 흩어진 자료를 읽고 불일치·누락·확인 질문을 먼저 뽑아냅니다
- 범위·사용자·기능·정책·권한·수용 기준을 갖춘 PRD를 씁니다
- IA와 화면 목록, 화면별 상세 명세와 예외 메시지를 정의합니다
- 샘플 데이터가 들어간 클릭형 프로토타입을 만듭니다
- 그 프로토타입을 스스로 UX·UI 관점으로 감사하고 개선본을 다시 만듭니다
- 운영 정책·QA 체크리스트·미결정 질문을 묶어 개발 인계 문서를 냅니다
- · 백엔드 코드 생성 · 자동 테스트 · 배포 자동화
- · 완전 오프라인 처리 — 분석에 필요한 발췌는 클라우드 모델로 전달됩니다
- · 사람의 최종 판단 대체 — 단계마다 검토 지점이 남아 있습니다
근거 없는 기간 단축률이나 비용 절감률을 제시하지 않습니다. 확인은 PoC에서 같은 조건으로 비교하는 방식을 권합니다.
우리가 이 제품을 만든 이유
기획 산출물을 넘긴 자리에서, 개발팀은 거의 언제나 같은 질문 세 가지를 합니다
이 질문들은 문서가 부족해서 나오는 것이 아닙니다.
착수 자료는 대개 넘칩니다. 제안서가 있고, 회의록이 있고, 기존 시스템 화면이 있고, 정책 문서가 있습니다. 문제는 그 문서들이 서로 다른 시점에 서로 다른 사람이 서로 다른 기준으로 쓴 것이고, 어느 것이 최신 판단인지 문서 자체가 알려주지 않는다는 데 있습니다.
그래서 개발팀은 요구사항을 다시 해석합니다. 해석이 갈리면 재작업이 생기고, 재작업의 근거는 다시 어느 문서에도 남지 않습니다.
일반 기획 모드는 터닝78이 SI 프로젝트에서 반복해 온 분석·기획·검수·인계 절차를 그대로 제품 안에 옮긴 것입니다.
문제는 문서의 수가 아니라, 어느 문서가 기준인지 아무도 보증하지 않는다는 데 있습니다.
Super Senior의 정의
기획의 완성은 문서의 개수가 아니라,
개발팀이 되묻지 않아도 되는 상태입니다.
Super Senior는 이 상태를 만들기 위해 세 가지를 강제합니다. 첫째, 단계를 건너뛸 수 없게 합니다. 둘째, 화면을 눌러볼 수 있는 형태로 내놓습니다. 셋째, 결정되지 않은 것을 본문에서 꺼내 별도 목록으로 세웁니다.
작동 원리
앞 단계의 결론이 다음 단계의 입력이 되고, 순서를 건너뛰면 실행되지 않습니다
각 단계는 무엇을 받아 무엇을 내놓아야 하는지가 코드에 계약으로 정의되어 있습니다. 그래서 “PRD가 없는데 UI부터 만드는” 일이 구조적으로 발생하지 않습니다.
넘긴 문서를 읽고 무엇이 서로 어긋나는지, 무엇이 비어 있는지 먼저 정리합니다.
대상 사용자, 범위, 기능, 정책과 권한, 그리고 “무엇을 충족하면 완료인가”를 확정합니다.
PRD의 기능을 화면으로 배치하고, 눌러서 확인할 수 있는 프로토타입까지 만듭니다.
자기가 만든 프로토타입을 다시 감사해 개선 지점을 번호로 표시하고 보정본을 만듭니다.
운영 정책과 QA 기준을 정리하고, 끝내 결정되지 않은 것을 따로 세워 넘깁니다.
단계마다 결과를 열어 확인한 뒤 다음으로 넘어갈 수 있습니다. 기본은 단계별 검토입니다.
결과가 마음에 들지 않으면 그 문서만 골라 보강할 수 있습니다. 채택할지, 원본으로 되돌릴지는 사용자가 정합니다.
실행 시점의 입력 자료는 실행별 사본으로 고정됩니다. 원본 폴더가 나중에 바뀌어도 그때의 실행 근거는 그대로 남습니다.
단계 잠금은 제약처럼 보이지만, 전문 기획자가 실제로 지키는 순서를 제품이 대신 지켜 주는 장치입니다.
작업 범위
업무의 성격이 다르면 질문도 산출물 구조도 달라야 합니다
3개 작업 모드와 4개 실행 경로를 나눈 이유는 하나입니다. 서로 다른 문제에 같은 절차를 적용하면, 절차가 형식만 남기 때문입니다.
“무엇을 만들 것인가”가 아직 말로만 있는 상태에서 시작합니다. 첫 출시 범위를 1단계에서 못 박고, 그 밖의 요구는 미결정 목록으로 옮깁니다.
이미 돌아가는 시스템이 있습니다. 자료 진단과 전환 위험 판단이 제품 기준 앞에 두 단계로 들어가, AS-IS를 먼저 세운 뒤 TO-BE를 그립니다.
만들 것을 정하기 전에 “할 것인가”를 판단해야 할 때 씁니다. 결론만 주지 않고, 그 결론을 뒤집을 조건과 확인 방법을 함께 남깁니다.
같은 사업이라도 정부지원 심사, 투자 설명, 내부 승인은 요구하는 구조가 다릅니다. 초안을 쓰기 전에 심사자가 던질 질문부터 만듭니다.
경로를 고르는 순간, 어떤 질문을 받게 될지와 무엇이 나올지가 함께 결정됩니다.
품질 통제
모델이 만든 문서라도 기준을 통과하지 못하면 적용되지 않습니다
문서마다 갖춰야 할 항목과 최소 분량이 코드에 계약으로 정의되어 있습니다. 반환된 본문은 결과 폴더에 쓰이기 전에 이 계약을 통과해야 합니다.
아래 조건에 하나라도 걸리면 사유와 함께 거부되고, 기존 내용이 유지됩니다.
- · “답변 없음”, “작성 필요” 같은 미완성 표시가 남은 경우
- · 항목 이름 뒤가 비어 있는 판단 항목이 남은 경우
- · 제목만 있고 본문이 없는 섹션이 있는 경우
- · 표에 빈 칸이 남아 있는 경우
- · 문서별로 정한 최소 분량에 못 미치는 경우
- · “자료가 부족해 판단할 수 없다” 류의 회피성 답변으로 끝난 경우
채우지 못한 자리는 지우지도 숨기지도 않고, 읽는 사람이 볼 수 있는 곳으로 꺼냅니다.
- · 미결정 질문 산출물 — 끝내 정해지지 않은 것을 별도 문서로 세워 인계합니다
- · 실행 경고 기록 — 어떤 자료를 어디까지밖에 확인하지 못했는지 문장으로 남깁니다
- · 가정 표시 — 입력에 없던 내용을 추론으로 채운 자리는 가정으로 구분합니다
- · 성공 판정 기준 — 일부 실패나 무변경을 성공으로 숨기지 않습니다
이것이 “AI가 써 준 그럴듯한 문서”와 검토 가능한 산출물의 차이입니다.
실행 구조 · 보안
모델은 텍스트만 돌려줍니다. 파일을 만드는 것은 전용 엔진입니다
SI 자료는 양이 많고 민감합니다. 그래서 무엇을 읽고 무엇을 뺐는지 파일 단위로 보여 주고, 결과 파일은 사용자 PC 안에서 작성됩니다.
- · 모델 세션은 읽기 전용 · 일회성으로 실행됩니다
- · 웹·브라우저·네트워크 도구를 비활성화한 상태로 호출합니다
- · 실행이 끝나면 브리지와 토큰이 함께 폐기됩니다
- · 결과 파일은 사용자 PC 안에서 작성됩니다
- · 원본 폴더는 수정하지 않고 허용 파일만 사본으로 복사합니다
- · 결과 목록에는 상대 경로만 기록하고, 절대 경로를 노출하지 않습니다
파일을 웹 저장소에 올리지 않는 것과, 모델 추론이 완전한 오프라인이라는 것은 다른 이야기입니다. 분석에 필요한 발췌 내용은 클라우드 모델로 전달될 수 있습니다. 이 제품을 완전 오프라인·폐쇄망 제품으로 설명하지 않습니다.
폐쇄망 요건이 있는 사업에서는 이 경계를 먼저 확인한 뒤 적용 범위를 정하는 것을 권합니다.
다음 행동
한 개 업무에서 같은 조건으로 비교해 보시길 제안합니다
반복 산출물이 많고 기존 자료가 충분한 업무 하나를 골라, 기존 방식으로 만든 결과와 Super Senior 결과를 같은 입력으로 나란히 만듭니다. 평가 기준은 먼저 합의하고 실행합니다 — 결과를 보고 기준을 정하면 비교가 되지 않습니다.