Codex의 가격이 인상되고 Codex 워크플로우에서 사용량 제한에 부딪힌 이후, 저는 코딩 작업의 더 많은 부분을 ChatGPT로 옮기게 되었습니다. 새로운 Codex 채팅을 시작할 때마다 프로젝트 제약 조건을 다시 설명하고, 이전의 근거를 복구하며, 실제 문제로 돌아가기 전에 디버깅 흔적을 다시 구축해야 했습니다.

과거의 결정, 현재의 실패, 그리고 재사용 가능한 지침들이 동일한 대화 속에 섞여 있으면 긴 코딩 작업을 제어하기가 어려워집니다. 저는 각 새로운 요청이 이를 제어하는 사실들에 기반하도록 유지하기 위해 네 가지 버킷(buckets)을 사용합니다.

이 버킷들은 프로젝트 컨텍스트 (context), 눈앞의 작업, 재사용 가능한 프롬프트 (prompts), 그리고 저장된 결과물들을 디버깅 시도, 붙여넣은 오류, 버려진 접근 방식들 사이에 묻혀 있는 대신 눈에 보이게 유지해 줍니다.

핵심 요약

• 프로젝트 컨텍스트 (context)를 현재 작업과 분리하여 유지하세요.
• 반복되는 지침은 이름이 지정된 변수와 명확한 출력 계약 (output contract)을 가진 템플릿으로 저장하세요.
• 시각적 정리 (visual decluttering)를 인터페이스 보조 도구로 취급하세요. 이는 모델의 컨텍스트 (context)를 변경하지 않습니다.
• 결정 사항, 명령, 그리고 최종 코드가 채팅 외부에서 유용해지면 내보내기 (export) 하세요.

프로젝트는 이력을 유지합니다. 작업 상태가 다음 작업을 안내합니다

현재 작업이 여전히 이전의 결정에 의존하고 있을 때는 긴 채팅을 유지합니다. 대화에는 저장 키를 변경할 수 없는 이유, 지름길을 배제하게 만든 실패한 접근 방식, 또는 다음 디버깅 단계에 필요한 오류 출력 등이 포함될 수 있습니다.

ChatGPT Projects는 관련 채팅, 파일, 지침을 함께 유지하며, ChatGPT memory는 채팅 전반에 걸쳐 유용한 컨텍스트 (context)를 전달할 수 있습니다. 저는 여전히 모델이 작업 상태 (working state)로 취급해야 할 목표, 제약 조건, 그리고 다음 행동을 직접 선택합니다. 네 가지 버킷은 제가 작업을 계속하기 전에 검토할 수 있는 압축된 기록을 제공합니다.

사용량 제한(Usage limits)은 불필요한 리셋을 피해야 하는 실질적인 이유를 제공합니다. 일부 도구와 관리형 워크스페이스(managed workspaces)는 적격한 코딩 활동에 대해 사용량 또는 지출 제어(spend controls)를 적용합니다. Codex에서는 이러한 제어가 플랜과 워크스페이스에 따라 달라지며, 컨텍스트를 재구축하는 것은 항상 더 많은 교환(exchanges)과 더 많은 용량을 요구합니다.

목표가 변경되거나, 이전 기록이 새로운 작업과 충돌하거나, 검토된 인수인계(handoff)를 통해 다음 세션에 더 작고 명확한 작업 세트(working set)를 제공할 수 있을 때는 새로운 채팅을 시작하세요. 결정 과정(decision trail)을 유지하는 것이 이를 유지하는 데 드는 비용보다 더 많은 작업을 절약해 줄 수 있다면 현재 채팅을 유지하세요.

왜 긴 ChatGPT 채팅은 여전히 사용하기 어려워지는가

긴 코딩 채팅은 서로 다른 속도로 변화하는 자료들을 혼합합니다. 아키텍처 제약 조건(architecture constraints)은 몇 달 동안 유효할 수 있고, 실패하는 테스트는 한 시간 동안 중요할 수 있으며, 풀 리퀘스트(pull request) 리뷰 템플릿은 매주 돌아올 수 있습니다. 이러한 자료들이 동일한 대화 스트림(conversational stream)을 점유하면, 사용자와 모델 모두 어떤 세부 사항이 현재 작업을 제어하는지 추론해야 합니다.

증거를 포함하는 기록은 유지하되, 재사용할 사실들은 별도의 버킷(buckets)으로 이동시키세요. 검토된 노트(reviewed note)에는 지름길을 배제하는 결정 사항을 담아야 하며, 그 결정의 근거가 되는 증거를 다시 확인해야 할 때를 위해 트랜스크립트(transcript)는 계속 사용할 수 있도록 남겨두어야 합니다.

네 가지 버킷을 분리하여 유지하기

현재 작업이 변하는 동안 프로젝트 컨텍스트는 안정적으로 유지되므로, 유용한 프롬프트(prompt)에는 이 두 가지가 모두 정렬된 구조로 포함되어야 합니다. 가공되지 않은 사실(Raw facts), 예시, 그리고 오래된 요청들을 단순히 함께 붙여넣는다고 해서 유용한 컨텍스트가 되는 것은 아닙니다.

1단계: 프로젝트 컨텍스트를 하나의 문서에 유지하기

프로젝트 컨텍스트는 모델이 안전한 변경 사항을 제안하기 전에 새로운 작업에 필요한 사실들을 포함해야 하며, 동시에 검토할 수 있을 만큼 충분히 짧고 답변을 제한할 수 있을 만큼 충분히 구체적이어야 합니다.

다음과 같은 문서로 시작하세요:

# 안정적인 컨텍스트 (Stable context)

## 제품 (Product)
...

안정적인 컨텍스트 (Stable context)

제품 (Product)

전체 프로젝트 이력은 다른 곳에 보관하고, 이 문서는 자칫 합리적인 답변이 제품을 망가뜨리는 것을 방지하기 위한 규칙들을 위해 남겨두세요. "계정 업데이트 후 오래된 데이터 수정"과 같은 작업은 만료되겠지만, "기존 API 응답 필드 유지"와 같은 규칙은 향후 작업들을 위해 계속 유지되어야 합니다.

Step 2: 현재 작업 문서 작성 (Write a current task document)

현재 작업 문서는 목표, 증거, 검사할 파일, 그리고 완료 정의 (Definition of done)를 명시함으로써 ChatGPT에게 변화하는 사실들을 전달합니다.

# 현재 작업 (Current task)

## 목표 (Goal)
...

이 문서는 모델에게 어디를 살펴봐야 하는지, 그리고 당신이 결과를 어떻게 판단할 것인지를 알려주는 동시에, 휴식 후 돌아왔을 때 문제에 대한 압축된 기록을 제공합니다.

주의: 긴 프로젝트 컨텍스트와 긴 작업 문서는 동일한 사실을 반복할 수 있습니다. 지속적인 규칙은 프로젝트 컨텍스트에 유지하고, 작업별 증거는 작업 문서에 남겨두세요.

Step 3: 재사용 가능한 프롬프트 저장 (Save reusable prompts)

프롬프트의 추론 패턴, 구조 또는 출력 형식을 재사용할 것으로 예상된다면 저장된 템플릿(Template)으로 만들 가치가 있습니다. "이 에러를 설명해줘"는 라이브러리에 등록할 필요가 없습니다. 하지만 "호환성 및 회귀 위험(Regression risks)을 위해 이 계정 데이터 변경 사항을 검토해줘"는 아마도 등록이 필요할 것입니다.

각 재사용 가능한 프롬프트를 이름, 목적, 변수(Variables), 그리고 출력 계약 (Output contract)과 함께 저장하여, 두 개의 저장된 프롬프트가 동일한 문제를 해결하는지 여부를 판단할 수 있도록 하세요.

# 프롬프트: 위험한 계정 데이터 변경 검토 (Prompt: Review a risky account data change)

## 목적 (Purpose)
...

템플릿은 고정된 부분이 고정된 상태로 유지되고, 변화하는 사실들이 변수를 통해 전달될 때 가장 잘 작동합니다. 그러면 매번 주변의 작업 문서를 다시 작성하지 않고도 지시 사항을 개선할 수 있습니다.

Step 4: 컨텍스트 관리와 혼동하지 않고 시각적 노이즈 줄이기 (Reduce visual noise without confusing it with context management)

긴 채팅은 두 가지 별개의 문제를 일으킵니다. 모델은 긴 히스토리 (history)를 받게 되고, 사용자는 그 히스토리를 시각적으로 훑어봐야 한다는 점입니다. 인터페이스는 두 번째 문제만을 해결할 수 있으므로, 지금 당장 읽을 필요가 없는 자료를 숨기거나 접어두는 시각적 모드 (visual mode)를 사용하세요. 이는 사용자가 스캔하는 페이지를 바꾸는 것이지, ChatGPT가 받는 대화 컨텍스트 (conversation context)나 모델의 생성 속도를 바꾸는 것이 아닙니다.

이러한 경계는 워크플로 (workflow)를 정직하게 유지해 줍니다. 시각적 정리 (visual decluttering)는 현재 요청, 필요한 답변, 그리고 다음 행동을 찾는 데 도움을 주는 반면, 컨텍스트 선택 (context selection)은 여전히 어떤 프로젝트와 작업 사실이 프롬프트 (prompt)에 포함되어야 하는지 사용자가 직접 결정해야 하기 때문입니다.

이 다이어그램은 워킹 셋 (working set)을 보여줍니다. 이전 대화 차례 (conversation turns)를 화면에서 숨기더라도 관련 입력값은 명시적으로 유지하세요.

5단계: 세션에서 유용한 결과물 저장하기

원문 기록 (Raw transcripts)은 히스토리를 보존하지만, 저장된 결과물 (saved outcomes)은 당신이 실행해야 할 결정 사항들을 보존합니다. 감사 추적 (audit trail)이나 나중에 요약할 때 사용할 소스 자료가 필요할 때는 기록을 내보내고(export), 문제를 해결한 명령어나 결정 사항과 그 근거, 코드 블록 (code block), 해결되지 않은 리스크, 또는 다음 작업이 필요할 때는 더 짧은 결과물을 저장하세요.

대화 중에 나중에 다시 필요할 수도 있는 작업물이 생성되었다면, 세션 종료 시 다음과 같은 프롬프트를 사용하세요:

나중에 작업을 이어갈 개발자를 위해 이 코딩 세션을 요약해 주세요.

다음 헤딩 (headings)을 사용하세요:
...

결과물을 저장하기 전에 반드시 검토하세요. 요약은 긴 히스토리를 압축하는 과정에서 원래 채팅에서 명확하게 언급되지 않았던 세부 사항을 누락할 수 있기 때문입니다. 이러한 검토 과정을 거쳐야 요약본이 그럴듯한 재구성 (plausible reconstruction)이 아닌, 실제 작업 노트 (working note)가 됩니다.

도구를 추가하기 전에 워크플로를 수동으로 사용해 보기

이 시스템은 어떤 ChatGPT 세션에서도 사용할 수 있습니다. 공유된 채팅, 파일, 지침(instructions)이 작업에 적합할 때 프로젝트(Project)로 시작한 다음, 검토할 수 있는 문서로서 짧은 프로젝트 컨텍스트(project context)와 현재 작업(current task)을 추가하세요.

1. 짧은 프로젝트 컨텍스트 문서를 유지합니다.
2. 각 코딩 작업은 현재 작업 문서와 함께 시작합니다.
3. 반복되는 작업을 설명하는 프롬프트(prompts)를 저장합니다.
4. 세션에서 결정 사항이나 수정 사항이 발생하면 개발자 노트(developer note)를 기록합니다.

짧은 프로젝트 컨텍스트 하나와 재사용 가능한 프롬프트 하나로 시작해 보세요. 동일한 유형의 작업을 반복하고 있다는 것을 깨달았을 때만 시스템에 추가하면 됩니다.

이 워크플로를 위해 내가 만든 작은 도구

긴 채팅에서 이 워크플로를 사용한 후, 필요한 자료를 대화 옆에 계속 유지할 수 있도록 ChatGPT용 Power Booster를 만들었습니다. 이 도구의 사이드 패널(Side Panel)은 프로젝트 컨텍스트(Project Context), 즐겨찾기 프롬프트(Prompt Favorites), TXT 내보내기(exports)를 손쉽게 사용할 수 있도록 유지해 줍니다. Pro 버전은 사용자 정의 변수가 포함된 동적 템플릿(Dynamic Templates), 개발 핸드오프(Dev Handoff), Markdown 내보내기 및 JSON 내보내기 기능을 제공합니다. 버전 0.4에서는 여전히 현재 작업과 결과 노트를 직접 관리해야 합니다.

이 확장 프로그램은 작업 상태를 선택하거나 엔지니어링적 판단(engineering judgment)을 대체하지 않습니다. 코드를 검사하고, 변경 사항을 테스트하며, 생성된 답변이 제품 제약 조건(product constraints)에 부합하는지 결정하는 과정은 여전히 필요합니다. 직접 사용해 보고 싶다면, Power Booster for ChatGPT는 여기에서 이용 가능합니다.

염두에 두어야 할 한계점

프로젝트 컨텍스트는 관련성이 유지될 때만 도움이 됩니다. 오래된 제약 조건은 누락된 제약 조건만큼이나 모델을 잘못된 방향으로 인도할 수 있기 때문입니다. 아키텍처(architecture), 저장 스키마(storage schema), 제품 정책(product policy) 또는 출시 목표(release goal)가 변경될 때 이를 검토하세요. 프로젝트에 마이그레이션 레이어(migration layer), 라이선스 흐름(licensing flow) 또는 더 복잡한 테스트 스위트(test suite)가 추가되면 재사용 가능한 프롬프트를 다시 검토하십시오.

모든 ChatGPT 자동화는 사용자의 제어권을 보존해야 합니다. 구조화된 출력(Structured outputs)과 검토 단계는 예측 가능성과 신뢰성을 향상시키지만, 둘 중 어느 것도 모델의 답변을 기본적으로 정답으로 만들어주지는 않습니다.

언제 긴 채팅을 종료해야 하는지에 대한 명확한 규칙을 찾지는 못했습니다. 제어하기 어려워질 때까지 기다리시나요, 아니면 작업이 바뀌자마자 새로운 채팅을 시작하시나요?

FAQ

ChatGPT Projects가 이러한 문서들을 대체하나요?

Projects는 관련 채팅, 파일, 지침(instructions)을 하나로 묶어 관리합니다. 저는 프로젝트 컨텍스트(project context), 현재 작업, 그리고 저장된 결과 문서들을 활용하여 다음 코딩 결정을 안내할 세부 사항들을 선택합니다.

전체 리포지토리(repository)를 프로젝트 컨텍스트에 넣어야 하나요?

아키텍처(architecture), 주요 인터페이스(interfaces), 컨벤션(conventions), 호환성 규칙(compatibility rules) 등 현재 작업 범위를 제한하는 사실들을 추가하세요. 그런 다음 모든 프롬프트(prompt)에 전체 리포지토리를 붙여넣는 대신, 검토가 필요한 파일들을 ChatGPT가 참조하도록 안내하세요.

메시지를 숨기는 것이 ChatGPT의 답변 품질을 향상시키나요?

메시지를 숨기는 것은 사용자가 읽는 인터페이스를 변경할 뿐이며, 답변의 품질은 여전히 모델에 전달되는 지침(instructions)과 컨텍스트(context)에 달려 있습니다.

어떤 프롬프트를 저장해야 하나요?

안정적인 추론 패턴(reasoning pattern)이나 출력 형태(output shape)를 가진 채 반복적으로 사용하는 프롬프트를 저장하세요. 개별 질문들은 대화 속에 유지하되, 저장된 프롬프트에는 목적과 명명된 변수(named variables), 그리고 정의된 출력 형식(output format)을 부여하세요.

내보내기(exports)가 요약(summaries)과 같나요?

내보내기는 대화의 내용을 그대로 보존하는 반면, 요약은 해당 내용을 해석하며 세부 사항을 생략할 수 있습니다. 내보내기는 원본 자료로 사용하고, 검토된 요약본은 개발자 노트(developer notes)로 저장하세요.

작업 세트(working set)를 작고 명확하게 유지하세요

Project를 사용하여 관련 자료를 함께 묶어두고, 프로젝트 컨텍스트는 안정적으로 유지하며 현재 작업은 짧게 가져가세요. 재사용 가능한 프롬프트와 저장된 결과물은 작업 결과가 앞으로 가져갈 가치가 있을 때만 추가하세요. 이 워크플로(workflow)는 일반 텍스트 문서로 작동하며, 사이드 패널(Side Panel)을 사용하면 습관이 유용하다고 증명된 이후에는 반복 작업을 줄일 수 있습니다.