AI 가이드

세션이 지나는 시간

1. 도구와 설정을 갖출 때

   팁 1

   • AGENTS.md는 짧고 정확하게 쓴다 — 프롬프트에 되풀이하던 규칙만 옮기고 막연한 규칙은 넣지 않는다.

     AGENTS.md는 실행할 때마다 자동으로 컨텍스트에 실리므로 같은 지침을 턴마다 다시 적을 필요가 없다. 대신 파일이 부풀면 그 비용도 매 턴 나간다. 규칙은 처음부터 다 적지 말고 같은 실수가 되풀이될 때 더하고, 커지면 본문은 간결하게 두고 계획·리뷰·아키텍처 같은 작업별 마크다운을 참조시킨다. 여러 파일을 합친 크기에도 상한이 있다. ChatGPT Learn — Best practices

2. 모델과 추론 강도를 고를 때

   팁 1

   • 추론 강도는 필요한 결과가 나오는 가장 낮은 단계에서 시작하고 모자랄 때만 올린다.

     강도를 올리면 복잡한 일에서 품질이 좋아질 수 있지만 시간이 더 걸리고 토큰을 더 쓴다. 단계별 기준은 Light(CLI는 Low)가 범위가 분명한 빠른 일, Medium이 계획이 더 필요한 일, High·Extra High가 단계·소스·트레이드오프가 많은 어려운 일이다. Max·Ultra는 대부분의 작업에 필요 없고, Ultra는 일을 의미 있는 조각으로 나눌 수 있을 때만 고른다. GPT-5.5의 강도와 GPT-5.6의 강도는 정확히 대응하지 않으므로 익숙한 일을 한 단 낮춰 보고 맞춘다. ChatGPT Learn — Models

3. 자료를 넣거나 일을 나눌 때

   팁 2

   • 서브에이전트는 토큰을 더 쓰므로 탐색·테스트·요약 같은 읽기 작업부터 병렬로 맡기고, 여럿이 동시에 코드를 고치게 하는 일은 조심한다.

     에이전트마다 제 모델·도구 호출을 따로 돌리므로 같은 일을 단일 에이전트로 할 때보다 토큰을 더 쓴다. 여럿이 동시에 코드를 고치면 서로 충돌하거나 조율 비용이 커질 수 있다. ChatGPT Learn — Subagents

   • 탐색 노트·테스트 로그·스택 트레이스 같은 중간 출력은 주 채팅에 쌓지 말고 서브에이전트에 맡겨 요약만 돌려받는다.

     요구사항·제약·결정을 정하는 주 채팅이 중간 산출물로 덮이면 쓸모 있는 정보가 묻히는 컨텍스트 오염과 컨텍스트 로트가 생겨 세션이 갈수록 부정확해진다. 컨텍스트 창이 커도 마찬가지다. 수백만 토큰짜리 문서 분석처럼 큰 일은 쪼개 돌리고 주 채팅에는 추려낸 결론만 올린다. ChatGPT Learn — Subagents

4. 대화가 길어지거나 일이 바뀔 때

   팁 1

   • 긴 실행 뒤 컨텍스트가 차오르면 /compact으로 앞 대화를 요약해 토큰을 비운다.

     /compact은 앞 턴들을 요약으로 갈아 끼워 핵심을 남긴 채 컨텍스트를 비운다. 비우기와 줄이기는 다른 동작이다 — /new는 같은 CLI 세션 안에서 컨텍스트만 새로 시작하고 /clear는 터미널 화면까지 함께 지우며, 둘 다 맥락을 통째로 버리므로 다시 설명해야 한다. Codex는 자동으로도 압축한다. ChatGPT Learn — Developer commands (CLI)

고치는 값이 커지는 순서

1. 일을 처음 넘길 때

   팁 3

   • 복잡하거나 말로 설명하기 어려운 일은 바로 시키지 말고 /plan으로 계획부터 세우게 한다.

     계획 모드에서 Codex가 맥락을 모으고 되물어 계획을 세운 뒤 구현에 들어간다(/plan 또는 Shift+Tab). 무엇을 만들지 흐릿할 때는 「나를 인터뷰하고 내 가정을 반박하라」고 시켜 요구를 구체화한 다음 코드를 쓰게 한다. 다단계·복잡한 작업에서 계획을 건너뛰는 것은 흔한 실수다. ChatGPT Learn — Best practices

   • 요청에는 목표·컨텍스트·제약과 함께 끝나는 조건(테스트 통과, 버그 재현 안 됨 등)을 적는다.

     여기서 컨텍스트는 어느 파일·폴더·문서·예시·에러가 이 일에 걸리는가다. 넷을 함께 적으면 Codex가 범위를 덜 벗어나고 가정을 덜 세우며 결과를 리뷰하기도 쉬워진다. 큰 저장소나 실수 비용이 큰 작업일수록 이 구조가 결과를 안정시킨다. ChatGPT Learn — Best practices

   • 버그는 증상을 풀어 쓰지 말고 재현 순서를 번호로 적고, 고친 뒤 그 순서를 다시 밟게 한다.

     버그를 고칠 때 재현 절차와 제약은 사용자가 주는 몫이고, 개괄적인 설명보다 중요하다. 재현 순서가 있으면 Codex가 먼저 로컬에서 버그를 되살린 뒤 패치를 내놓고, 고친 다음 같은 순서를 다시 밟아 스스로 확인할 수 있다. 명령 출력과 호출 지점, 스택 트레이스는 Codex 쪽이 알아서 모으는 몫이다. ChatGPT Learn — Prompting

2. 결과가 어긋났을 때

   팁 2

   • 같은 문제의 연속이면 대개 새 채팅을 열지 않고 이어 간다 — 채팅은 길이가 아니라 결과물 단위로 나눈다.

     같은 채팅에 머물면 추론 흐름이 그대로 남는다. 반대로 프로젝트 하나를 채팅 하나로 끌고 가는 것은 흔한 실수다 — 컨텍스트가 부풀고 시간이 갈수록 결과가 나빠진다. 일이 실제로 갈라질 때만 가지를 치고, CLI에서는 /fork가 원본 기록을 남긴 채 새 채팅을 만든다. ChatGPT Learn — Best practices

   • 프롬프트 탓으로 보기 전에 작업 디렉터리·쓰기 권한·기본 모델·도구와 커넥터 설정부터 본다.

     많은 품질 문제가 실은 설정 문제다 — 잘못된 작업 디렉터리, 없는 쓰기 권한, 어긋난 기본 모델, 안 붙은 도구·커넥터가 그렇다. CLI·IDE 확장·데스크톱 앱이 같은 설정 층을 쓴다. ChatGPT Learn — Best practices

3. 완료를 확인하게 할 때

   팁 1

   • 커밋하기 전에 /review로 작업 트리를 보게 하고, 고친 뒤 한 번 더 돌려 남은 것을 확인한다.

     로컬 코드 리뷰는 세 걸음이다 — /review로 작업 트리를 보게 하고, 「엣지 케이스와 보안 이슈 중심으로」처럼 초점을 붙일 수 있고, 지적받은 것을 고친 뒤 /review를 다시 돌려 해결됐는지 확인한다. 브랜치를 로컬로 받지 않고 보게 하려면 GitHub PR에 댓글로 @codex review를 부른다. ChatGPT Learn — Prompting