DeepSeek V4 1M Token Context: 전체 코드베이스에 프롬프트하는 방법

제 친구들이 안녕하세요. 저는 도라입니다. 처음으로 전체 프로젝트를 DeepSeek V4의 1M 토큰 윈도우에 넣었을 때, 저는 강력함을 느끼지 못했습니다. 조심스러움을 느꼈습니다. 100만 개의 토큰은 끝없는 커피처럼 들리지만, 카페인 주입으로 몇 시간을 생각해본 사람이라면 누구나 경계가 흐려진다는 것을 알고 있습니다. 저는 이 새로운 컨텍스트 크기가 실제로 제 작업 방식을 바꿀지, 아니면 더 많이 붙여넣도록 격려할지 확인하고 싶었습니다.

저는 며칠(2026년 1월 27-30일) 동안 DeepSeek V4 1M 토큰을 자주 실행하는 세 가지 작업에 사용했습니다:

• 로컬로 설정하지 않고 중간 규모 모노레포 읽기,
• 과도하게 통신하는 서비스 간 버그 추적,
• 테스트를 망치지 않는 리팩토링 제안 요청.

제가 배운 것: 많은 것을 들어맞힐 수 있지만, 모델은 여전히 지도를 가리켜 줄 필요가 있습니다. 더 많은 파일을 집어넣는 것에서 나온 것이 아니라, 프롬프트를 어떻게 준비했고 모델에 어떻게 움직일지 요청했는지에서 나왔습니다.

1M 토큰이 실제로 의미하는 것

저는 숫자 자체에는 관심이 없습니다. 명확한 상태로 들어가는 것에 관심이 있습니다.

토큰은 단어가 아닙니다. 그것은 덩어리이며, 때로는 전체 단어, 때로는 단어의 일부, 때로는 구두점입니다. 영어 텍스트에서 저는 일반적으로 대략적인 계획을 위해 1 토큰을 약 0.75 단어로 취급합니다. 코드의 경우 토큰이 빠르게 나옵니다: 중괄호, 점, 메서드 이름, 모두 슬라이스됨. 100만 개의 토큰은 많은 영역이지만 무한한 주의력은 아닙니다.

이번 주 제게 바뀐 것: 더 공격적으로 제거하지 않았습니다. 128K 컨텍스트에서 저는 공격적으로 요약하고 핫 경로만 유지했을 것입니다. 1M으로 저는 핫 경로와 나중에 나를 놀라게 할 경향이 있는 “콜드” 파일(설정, 마이그레이션, 빌드 스크립트, 워크플로우 글루)을 유지할 수 있었습니다. 즉, 모든 것을 한 번에 버렸다면 답변이 모호해졌을 것입니다. 명확한 이정표가 있는 단계별로 모델에 공급했을 때, 출력이 기반 있게 느껴졌습니다.

코드 라인 동등성

작업하는 동안 사용한 대략적인 계산:

• 많은 리포지토리는 코드와 문서를 혼합합니다. 코드가 많은 폴더에서 저는 조밀한 언어에서 약 2-3 토큰/문자를 보았지만, 실용적인 지름길은: 간단한 라인의 경우 약 4 토큰/라인, 들여쓰기, 이름, 주석이 있는 실제 라인의 경우 8-12를 생각합니다.
• 그 속도로 1M 토큰은 스타일과 언어에 따라 약 80K-150K 라인의 코드를 보유합니다. 주석과 린트 친화적 이름 지정이 있는 TypeScript 서비스는 더 높은 쪽에 있습니다. 축소된 번들은 개수를 폭발시키고 포함할 가치가 없습니다.

실제로 제 “안전한 맞춤”은 약 60K 라인의 의미 있는 소스 + 대상 문서 및 테스트였습니다. 더 높게 갈 수 있지만 지연 시간이 증가했고 답변이 부드러워졌습니다. 귀하의 마일리지는 토큰화 규칙 및 언어 혼합에 따라 다를 수 있습니다.

현재 모델과 비교(128K)

128K에서 1M로 점프하는 것은 더 큰 배낭을 가져오는 것보다 롤링 카트를 가져오는 것처럼 느껴집니다. 더 많이 가져갈 수 있지만 빨리 달릴 수 없습니다.

제가 주목한 것:

• 지연 시간: 전체 컨텍스트 프롬프트는 눈에 띄게 더 오래 걸렸습니다. 세션을 청크했을 때(단계별), 지연 시간이 관리 가능해 보였습니다.
• 회상: 128K에서 모델은 주요 부분을 반복하지 않으면 이전 파일을 “잊는” 경우가 많았습니다. 1M에서는 잊지 않았지만 때로는 특정 내용을 인용하는 대신 일반화했습니다. 파일 경로와 라인 범위를 인용하도록 요청했을 때 더 나은 운이 있었습니다.
• 정밀도: 컨텍스트가 클수록 프롬프트에서 인덱싱 동작이 필요합니다. 그렇지 않으면 실제로 신경 쓰는 지저분한 경계 사례를 피하는 유능한 요약을 얻습니다.

1M 토큰이 “더 이상 프롬프트 엔지니어링이 없음”을 의미한다면 저는 그것에 의존하지 않을 것입니다. 그것은 당신이 하는 조향의 종류를 바꿉니다.

대규모 코드베이스에 대한 프롬프트 구조

저는 프롬프트를 메시지로 생각하는 것을 멈추고 그것을 읽기 계획으로 취급하기 시작했습니다. 모델은 많이 읽을 수 있지만 목차와 흔적의 이점을 누리고 있습니다.

저에게 가장 잘 작동하는 것은 이와 같았습니다: 짧은 시스템 프레이밍, 간결한 프로젝트 색인, 선언된 탐색 순서, 그 다음 구체적인 작업. 그리고 나는 하나의 거대한 프롬프트가 아니라 라운드 형태로 대화를 계속 진행했습니다.

파일 순서

파일을 먼저, 둘째, 셋째로 열도록 모델에 알렸을 때 더 신뢰할 수 있는 답변을 얻었습니다. 맨 위의 단일 목록이 정신적 스택을 만드는 데 도움이 되었습니다:

• 진입점(CLI, HTTP 핸들러, 작업)으로 시작합니다. 흐름을 고정합니다.
• 그 다음 구성 계층(DI 컨테이너, main.ts, app.py) 의존성이 연결되는 곳입니다.
• 다음으로, 핵심 도메인 모듈 및 그 인터페이스입니다.
• 마지막으로만: 헬퍼, 유틸리티 및 교차 절단 조각(로깅, 텔레메트리, 구성).
• 테스트는 마지막, 특정 실패를 디버깅하지 않는 한, 그 경우 실패한 스펙으로 시작하여 예상치를 설정합니다.

저는 또한 중요해 보이지만 실제로는 그렇지 않은 폴더에 대해 “읽지 말기” 주석을 포함했습니다: 생성된 코드, 컴파일된 자산, 스냅샷. 토큰을 절약했고 모델의 주의를 살아있는 코드로 유지했습니다.

작은 트릭: 저는 모델에 “활성 파일” 목록(경로 및 짧은 요약)을 유지하고 이동하면서 업데이트하도록 요청했습니다. 흔들렸을 때, 저는 그 목록으로 돌아가 “지금은 이 세트 안에 있어야 합니다”라고 말할 수 있었습니다. 그것은 답변을 구체적으로 유지했습니다.

의존성 매핑

가장 유용한 패스 중 하나는 다이어그램이 아니라 단순한 테이블의 가장자리: 모듈 A가 B를 가져오고, B가 C를 사용하고, C가 환경 변수를 친다는 등의 의존성 맵을 요청하는 것이었습니다. 저는 그것을 텍스트와 간결하게 유지했습니다.

실제로 이것이 한 일:

• 그것은 방황하는 의존성(폴더 간에 관심사를 흘러내리는 종류)을 노출했습니다.
• 그것은 리팩토링 전에 검토할 “압력 포인트”의 목록을 제공했습니다.
• 변경을 요청할 때 모델이 올바른 장소를 참조하는 데 도움이 되었습니다.

또한 모델 상태 가정, 이름, 주석, 또는 테스트에서 추론한 것을 만들었습니다. 가정이 벗어나면 한 번 수정했고 이후 단계는 더 깔끔해졌습니다.

한 가지 경고: 큰 리포지토리에서 한 번에 전체 의존성 맵을 요청하면 시간 초과 및 모호한 그래프가 발생했습니다. 저는 계층으로 범위를 지정한 결과(예: 데이터 액세스만, HTTP 핸들러만)가 더 좋았으고 그 다음 메모를 직접 병합했습니다. 추가로 10분이 걸렸지만 정확성으로 보상받았습니다.

필요할 때 청킹 전략

1M 토큰 윈도우에도 불구하고 저는 여전히 청크했습니다. 들어맞지 않았기 때문이 아니라 제 생각이 단계별로 더 나았고, 모델이 필드를 좁혔을 때 더 정확하게 답변했기 때문입니다.

이번 주에 견뎌낸 몇 가지 패턴:

• 브리프를 스테이징합니다: 저는 작은 컨텍스트, 프로젝트 색인, 작업, 알려진 제약 조건으로 시작한 다음 읽기 및 확인 계획을 요청했습니다. 그 후에만 우리가 동의한 순서로 코드를 공급했습니다.
• 활성 세트를 제한합니다: 리팩토링의 경우 5-12개 파일을 재생 중인 상태로 유지하고 명시적 경로로 변경을 요청했습니다. 편집이 공유 유틸에 영향을 준 경우 다음 턴에 해당 파일을 추가했습니다. 모델은 더 팽팽해졌습니다.
• 모서리에서 요약합니다: 새 폴더로 이동하기 전에 배운 내용의 짧은 요약과 불확실성을 요청했습니다. 이 요약은 모든 파일을 다시 붙여넣지 않고 차례를 걸쳐 빵가루로 작용했습니다.
• 목적을 위해 검색을 사용합니다: 편안하게 들어맞지 않는 리포지토리의 경우, 임베딩을 사용하여 쿼리(“결제 ID 정규화”, “재시도 백오프”)로 파일을 호출했습니다. 저는 검색된 세트를 차례당 작게 유지했으며, 일반적으로 40K 토큰 미만이므로 답변이 흐려지지 않았습니다.
• 앞으로 확인하고 뒤로 확인하지 않습니다: “붙여넣은 모든 것을 사용했습니까?”를 묻는 대신 “제안이 의존하는 특정 함수 및 라인을 가리킵니다”라고 요청했습니다. 그것은 구체적인 참조를 강요했고 오류를 명백하게 만들었습니다.

나는 마찰:

• 매 차례마다 전체 컨텍스트 메시지를 보낼 때 지연 시간이 증가합니다. 스테이징은 평균 응답 시간을 같은 작업에서 70-90초에서 20-40초로 단축했습니다.
• 비용 문제. 큰 프롬프트가 합산됩니다. 저는 명백한 단어를 재개하는 주석을 자르고, 컴파일된 아티팩트를 제거하고, 공급업체 번들을 건너뛰어 토큰을 절약했습니다.
• 위치 효과는 실제입니다. 거대한 프롬프트의 맨 처음이나 끝에 있는 콘텐츠는 더 “사용 가능” 경향이 있습니다. 저는 매 차례마다 작은 중요한 제약 조건을 끝 근처에 반복하여 이에 대항했습니다.

1M 윈도우의 이점은 누가?

• 모노레포에서 살고, 감사를 처리하거나, 교차 절단 리팩토링을 수행하면, 더 적은 설정 단계와 더 적은 로컬 인덱싱 오버헤드를 구매합니다. 그것은 더 차분한 시작점입니다.
• 작업이 대부분 작은 서비스의 초점이 맞춰진 버그 수정이면 추가 용량은 도움이 되지 않습니다. 더 작은 컨텍스트와 타이트한 검색 파이프라인이 더 빠르게 느껴집니다.

신뢰에 대한 참고: 저는 위험한 변경(마이그레이션, 인증)에 대해 정확한 코드 라인을 인용하도록 모델에 요청했습니다. 주저하거나 바꿔 말할 때, 저는 범위를 좁히거나 특정 파일을 다시 붙여넣기의 신호로 취급했습니다. 그 작은 습관은 몇 가지 거의 실수를 방지했습니다.

모델 한계 또는 토큰화 동작의 공식적인 설명을 원하면 제공자의 문서를 확인하세요. 구체적인 내용이 필요할 때 공식 모델 카드와 컨텍스트 윈도우 메모로 돌아갔습니다. 그것은 제가 모델에 요청한 것에 대해 정직하게 유지했습니다.

이것은 마법이 아닙니다. 그것은 단지 더 큰 테이블입니다. 유용하고 의자를 배열하면.

저는 화요일부터 한 가지 작은 것에 대해 계속 생각하고 있습니다: 저는 수정을 요청했고 모델이 한눈에 보기에 옳은 것처럼 보이는 함수를 변경하도록 제안했습니다. 아니었습니다. 버그는 두 계층 아래의 헬퍼에 살고 있었습니다. 100만 토큰은 그것을 바꾸지 않았습니다. 제 메모가 했습니다.