☰ Categories

Categories

Plan how to split long material for a model

Splits where the content divides, not into equal parts, and says what cannot be answered piecewise.

CategoryUsing AI › Context management
TagsAnalyzingReformattingChecklist
Prompt
Plan how to feed this material to a model. ***Do not summarize it yet.***

1. **Judge whether it fits at once.** **If not, do not just cut it into equal pieces** — ***split it where the content actually divides***
2. **Order the pieces** — **what has to be read first for the rest to make sense**
3. **Write the carry-over line for each piece:** what the model must remember from the previous one. *Two or three lines, not a summary*
4. **Mark what can be dropped entirely** — boilerplate, repeated headers, appendices that nothing refers to
5. **Mark what must never be split** — ***a table, a clause, a code block. Half a table is worse than no table***
6. **Decide where the task instruction goes.** **Repeat it with every piece rather than giving it once at the start**

**Also:**
- ***What will be lost by splitting*** — cross-references, anything requiring the whole document at once. **Say which questions cannot be answered piecewise**
- **Whether the material contains anything that should be masked before sending** — personal data, keys, internal identifiers
- **Whether this should be split at all**, or whether the task should change instead
After pasting, fill in the fields at the bottom (The material · What I want done with it)

What this prompt does

Equal-sized chunks cut tables and clauses in half, and splitting silently kills any question that needs the whole document. This splits at real boundaries and reports what is lost.

Model comparison

ChatGPT is the most complete and grounded. Gemini offers a useful workflow but invents details, while [C] is missing.

ChatGPTTop overall
44/ 50

＋ It thoroughly covers splitting, preservation, and masking.

－ It gives carry-over templates by section, not per actual chunk.

Gemini
35/ 50

＋ It clearly proposes extraction followed by global comparison.

－ It invents domains, tables, fields, and token estimates.

CriterionChatGPTGeminiLeader
Instruction following98ChatGPT +13%
Accuracy95ChatGPT +80%
Specificity97ChatGPT +29%
Structure99Tie
Right length86ChatGPT +33%

Scored 1–10 by gpt-5.6-sol with model names hidden (2026-09-25). This is an AI review, not a measurement.

Read full answers

We gave three models the same input and copied their answers unedited. Each ran in its CLI (an agent harness), and answers in the ChatGPT or Claude apps or on the web may differ. Outputs are in Korean.

Input used
The material: 스타트업 '핀브릿지'의 결제 시스템 아키텍처 문서, PDF 68페이지. 1~10페이지는 배경과 요구사항, 11~40페이지는 API 명세(엔드포인트별 요청/응답 스키마), 41~55페이지는 DB 테이블 정의와 ERD, 56~68페이지는 장애 대응 런북과 부록(용어집, 변경 이력). 내부 승인번호나 담당자 사번이 일부 표에 섞여 있음.

What I want done with it: 전체 문서를 읽고 API 명세와 DB 스키마 간 불일치(필드명, 타입, nullable 여부)를 찾아 리스트업해줘.
gpt-5.6-luna (codex CLI · 에이전트 하네스) · Run on 2026-09-24

판단

68페이지 전체를 한 번에 넣는 것은 권하지 않습니다. API 명세와 DB 스키마의 교차 비교가 핵심이라, 의미 단위로 나누어 읽힌 뒤 마지막에 통합 비교해야 합니다.

단순 페이지 분할은 피하고, 다음처럼 구성합니다.

권장 순서와 분할

0. 공통 작업 지시

아래 지시를 모든 조각에 반복해서 붙입니다.

이 문서는 스타트업 ‘핀브릿지’의 결제 시스템 아키텍처 문서다. 전체 문서를 읽고 API 명세와 DB 스키마 사이의 불일치(필드명, 타입, nullable 여부)를 찾아 최종적으로 리스트업하라.
현재 조각에서는 내용을 요약하지 말고, 이후 비교에 필요한 사실·참조 관계·버전 정보를 보존하라. 불일치를 단정할 수 없으면 ‘확인 필요’로 표시하라.

1. 배경·요구사항: 1~10페이지

먼저 읽습니다. API와 DB의 설계 의도, 데이터 의미, 필수성 규칙, 버전 범위를 파악하는 데 필요합니다.

가능하면 다음 내용만 남깁니다.

  • 데이터 필수/선택 규칙
  • 결제 상태와 금액·식별자 관련 정의
  • API 또는 DB 설계를 제약하는 요구사항
  • 문서 버전, 적용 범위, 변경 기준

이어받을 문장

앞 조각에서 확인한 설계 범위와 필수성 규칙을 유지한다.
다음 조각부터는 각 API 필드를 원문 그대로 기록하고, 필드명·타입·nullable 여부를 비교 가능한 형태로 보존한다.

2. API 명세: 11~40페이지

엔드포인트 단위로 나눕니다. 한 조각에는 여러 엔드포인트가 들어갈 수 있지만, 다음 단위는 절대 분리하지 않습니다.

  • 엔드포인트의 HTTP 메서드와 경로
  • 요청 스키마 전체
  • 응답 스키마 전체
  • 중첩 객체와 배열 구조
  • 공통 헤더·에러 응답
  • 해당 엔드포인트에 붙은 설명, 제약조건, 예시

각 조각의 끝에는 모델이 다음 비교를 위해 내부적으로 다음 표준 기록을 유지하도록 합니다.

엔드포인트 → 요청/응답 → 필드 경로 → 필드명 → 타입 → nullable/required → 설명 → API 버전

이어받을 문장

앞 조각의 API 필드 목록과 버전 범위를 계속 누적한다.
이번 조각의 엔드포인트가 앞선 공통 객체나 다른 엔드포인트를 참조하면 참조 대상의 원래 정의와 연결해 보존한다.

엔드포인트 하나의 요청 또는 응답 스키마가 조각 끝에서 끊기면 다음 조각으로 넘기되, 중복해서 다시 보내지 않습니다.

3. DB 테이블 정의와 ERD: 41~55페이지

테이블 단위로 나눕니다. 각 테이블은 다음을 포함한 완전한 단위로 보내야 합니다.

  • 테이블명
  • 모든 컬럼명
  • DB 타입
  • NULL 허용 여부
  • 기본값
  • PK/FK
  • 인덱스와 제약조건
  • 컬럼 설명
  • ERD의 관계와 카디널리티

이어받을 문장

앞 조각의 API 필드·공통 객체 기록을 유지한다.
이제 각 DB 컬럼을 API 필드 경로와 대응시키고, 필드명·타입·nullable 여부의 차이를 검출할 준비를 한다.

ERD는 관계선이나 연결된 테이블이 다른 조각에 걸치지 않도록 보내야 합니다. ERD와 관련된 테이블 정의도 서로 떨어뜨리지 않는 것이 좋습니다.

4. 변경 이력·용어집: 56~68페이지 중 필요한 부분

이 부분은 전부 보낼 필요가 없습니다.

보낼 것:

  • API 또는 DB 구조가 바뀌었다고 기록된 변경 이력
  • 버전별 필드명·타입·nullable 변경
  • API와 DB의 용어 대응을 정의한 용어집
  • 본문에서 참조하는 부록

이어받을 문장

지금까지 누적한 API·DB 대응 관계를 유지한다.
변경 이력이 있으면 현재 문서 기준과 과거 버전을 구분하여, 불일치인지 의도된 버전 차이인지 판정한다.

장애 대응 런북은 API 필드나 DB 컬럼을 직접 참조하는 부분만 보냅니다. 나머지는 이번 작업에서 제외할 수 있습니다.

완전히 제외 가능한 내용

다음은 API-DB 불일치 탐지와 직접 관련이 없으면 제외합니다.

  • 반복되는 문서 제목·페이지 머리말·꼬리말
  • 저작권·배포 안내
  • API나 DB를 참조하지 않는 일반적인 장애 대응 절차
  • 본문에서 참조되지 않는 용어집 항목
  • 구조 변경과 무관한 과거 변경 이력
  • 중복된 ERD 이미지나 동일 내용의 반복 표

다만 변경 이력에 현재 필드 구조의 근거가 있으면 제외하지 않습니다.

절대 나누면 안 되는 것

  • 하나의 API 엔드포인트
  • 요청 또는 응답 스키마
  • 중첩 객체·배열 정의
  • 하나의 DB 테이블 정의
  • PK/FK와 그 대상 테이블
  • ERD의 관계선과 관련 테이블
  • 하나의 표
  • 코드 블록 또는 JSON 예시
  • 특정 필드에 대한 제약조건 문장
  • 버전 변경 이력의 한 항목

PDF 표가 페이지 중간에서 끊기면 페이지 기준이 아니라 표 전체를 하나의 조각으로 재구성해야 합니다.

분할로 잃을 수 있는 것

다음은 조각별로 독립 처리하면 놓칠 수 있습니다.

  • API의 공통 객체와 DB 테이블의 대응 관계
  • 한 엔드포인트가 다른 엔드포인트의 스키마를 재사용하는 경우
  • ERD 관계를 통한 간접적인 필수성 판단
  • 같은 필드가 버전별로 이름이나 타입을 바꾼 경우
  • 본문과 부록 사이의 용어·참조 연결
  • 문서 전체에서만 판단 가능한 “의도된 차이”와 실제 불일치의 구분

따라서 다음 질문은 완전히 독립적인 조각 처리만으로 답하면 안 됩니다.

  • 모든 API 필드와 DB 컬럼의 전체 불일치 목록
  • 동일한 의미인데 이름이 다른 필드
  • API의 nullable/required와 DB의 NULL/NOT NULL이 충돌하는지
  • 버전 차이인지 설계 오류인지
  • 문서 전체 기준의 누락 필드와 미사용 컬럼

최종 단계에서는 모든 조각에서 누적한 구조화 기록을 함께 제공하고, “API 필드 ↔ DB 컬럼” 전역 대조를 수행해야 합니다.

마스킹

전송 전에 다음을 마스킹합니다.

  • 내부 승인번호
  • 담당자 사번
  • 사람 이름·연락처·이메일이 표에 포함된 경우
  • 실제 운영 시스템 식별자
  • API 키, 토큰, 비밀번호, 인증서, 연결 문자열
  • 내부 호스트명이나 계정명이 보안상 민감한 경우

필드 대응에 영향을 주지 않도록 다음처럼 일관된 대체값을 사용합니다.

  • APPROVAL-001
  • EMPLOYEE-001
  • INTERNAL-HOST-001

마스킹된 값이 필드명·타입·nullable 비교를 방해하지 않게 해야 합니다.

최종 권장 방식

각 조각을 순서대로 읽힌 뒤, 모델에 누적 비교표를 유지하게 합니다. 마지막에는 다음 열로 통합 결과를 요청합니다.

API 경로 | 요청/응답 | API 필드 경로 | DB 테이블.컬럼 | 불일치 유형 | API 정의 | DB 정의 | 판정 | 근거 페이지

즉, 이 자료는 분할하는 편이 낫지만, 단순히 나눠 각각 요약시키면 안 됩니다. API와 DB 정의를 각각 완전한 단위로 보존한 뒤 마지막에 전체 비교를 수행해야 합니다.

More in this category

Chat Summary and Export Instructions
Context Migration
Continue and Recap Assistant
Find instructions that contradict each other
Stop the output from mixing languages