GPT dots - 100% 활용하는 세팅법

GPT dots, 그냥 쓰면 10%만 쓰는 겁니다
Codex에 하나하나 지시하지 말고, dots를 ‘총괄 비서’로 쓰는 방법

GPT dots를 사용하면서도 여전히 개발 작업이 생길 때마다 직접 Codex로 가서

“이 파일 확인해줘.”
“여기 수정해줘.”
“테스트 돌려줘.”
“오류 났으니까 다시 수정해줘.”
“지난번 작업 참고해서 이어서 해줘.”

이렇게 하나씩 프롬프트를 입력하고 있다면,

dots와 Codex의 역할부터 나눠보는 것을 추천합니다.

제가 추천하는 구조는 아주 단순합니다.

dots = 총괄 관리자
Codex = 개발 실행자
Codex를 안 쓰는 게 아닙니다.

오히려 Codex는 계속 사용합니다.

달라지는 것은 Codex를 직접 관리하는 사람이 나에서 dots로 바뀐다는 것입니다.

⸻

1. dots와 Codex의 역할부터 나누세요

먼저 공식적으로 dots는 목표를 받아 작업을 진행하고, 환경과 권한이 갖춰져 있다면 Work 또는 Codex 작업을 만들거나 위임할 수 있습니다.

그래서 개발 프로젝트에서는 다음과 같이 역할을 나누어 생각하면 이해하기 쉽습니다.

dots = 총괄

* 내가 원하는 최종 목표 파악
* 현재 작업 맥락 확인
* 필요한 자료와 도구 판단
* 작업 순서 연결
* 필요한 경우 Codex에 개발 작업 위임
* 결과 확인
* 다음 작업으로 연결

Codex = 개발 실행

* 코드 분석
* 코드 작성 및 수정
* 버그 해결
* 리팩토링
* 테스트
* 실제 개발 작업 수행

기존에는 사람이 중간 관리자 역할을 했습니다.

나 → Codex → 결과 확인 → 다음 프롬프트 → Codex → 결과 확인

이 과정을 계속 반복했죠.

dots를 활용하면 이 구조를 조금 다르게 만들 수 있습니다.

나 → dots → 필요한 작업 판단 → Codex 작업 → 결과 확인 → 다음 작업

즉,

나는 dots에게 목표를 주고, dots는 필요한 개발 작업을 Codex 같은 전문 에이전트에 연결하는 구조입니다.

이게 dots를 활용할 때 가장 먼저 이해하면 좋은 부분입니다.

⸻

2. dots에 ‘목표’를 주세요

예를 들어 기존에는 Codex에 이렇게 여러 번 지시했다고 해보겠습니다.

“현재 프로젝트 상태 확인해줘.”

“지난번 작업 찾아봐.”

“이 오류 수정해줘.”

“기존 기능 깨지지 않았는지 테스트해줘.”

“결과 정리해줘.”

dots를 총괄 역할로 사용한다면 조금 더 큰 단위로 요청할 수 있습니다.

예를 들면,

“지난번에 작업하던 프로젝트를 이어서 진행해줘. 현재 상태와 관련된 작업 기록을 확인하고, 기존에 검증된 방법을 재사용할 수 있다면 활용해. 개발 작업이 필요하면 Codex를 사용하고 수정 후 테스트까지 진행해줘.”

핵심은 세부 프롬프트를 하나하나 작성하는 것이 아니라,

내가 원하는 최종 상태를 전달하는 것입니다.

⸻

3. 그런데 과거 자료를 전부 읽게 하면 안 됩니다

여기서부터는 dots의 공식 기능 설명이라기보다, 제가 추천하는 운영 방법입니다.

프로젝트를 오래 운영하면 자료가 계속 쌓입니다.

AGENTS.md

과거 프롬프트

Skill

오류 기록

프로젝트 문서

체크포인트

ChatGPT 대화

Codex 작업 기록

자동화 스크립트

이런 것들이 계속 생깁니다.

그렇다고 매번 작업을 시작할 때 이 모든 것을 읽게 하는 것은 좋은 방법이 아닙니다.

시간과 컨텍스트를 많이 사용하고,

더 큰 문제는 현재 작업과 관계없는 오래된 정보까지 판단에 영향을 줄 수 있다는 것입니다.

그래서 저는 다음 원칙을 추천합니다.

“모든 자료를 읽지 말고, 현재 작업에 필요한 자료부터 순서대로 확인한다.”

⸻

4. dots가 자료를 확인하는 순서를 정해주세요

예를 들어 개발 프로젝트라면 이런 순서로 운영할 수 있습니다.

현재 요청

↓

현재 프로젝트 상태

↓

현재 적용되는 핵심 규칙

↓

최근 관련 작업 기록 또는 체크포인트

↓

현재 작업과 관련된 기존 자산

↓

정보가 부족할 경우 추가 자료 탐색

처음부터 몇 달치 ChatGPT 대화와 Codex 작업을 전부 찾게 하는 것이 아닙니다.

먼저 현재 상태를 보고,

그다음 지금 작업과 관련된 기록만 좁게 찾아보는 것입니다.

그래도 정보가 부족할 때 추가 자료를 확인합니다.

핵심은

“많이 읽게 하는 것”이 아니라 “필요한 정보를 찾는 순서를 만들어주는 것”입니다.

⸻

5. AGENTS.md에는 핵심 규칙만 넣으세요

프로젝트를 AI와 함께 운영한다면 AGENTS.md 같은 프로젝트 지침 파일을 활용할 수 있습니다.

하지만 여기에 모든 지식을 넣을 필요는 없습니다.

예를 들어 이런 정도입니다.

기존 구조를 임의로 크게 변경하지 않는다.

작업 전 현재 상태를 먼저 확인한다.

관련된 기존 자산이 있다면 필요한 범위에서 확인한다.

수정 후 실제 테스트를 수행한다.

중요한 작업이 끝나면 작업 상태를 기록한다.

AGENTS.md는 거대한 지식 저장소보다는

“이 프로젝트에서 반드시 지켜야 하는 핵심 규칙과 필요한 자료로 가는 안내판”

정도로 사용하는 것이 좋습니다.

세부 내용이 많아지면 그때 별도 문서로 분리하면 됩니다.

⸻

6. 과거 작업은 ‘조건이 같을 때’ 재사용하세요

AI에게 과거 작업 기록을 제공하면 이런 규칙을 만들기 쉽습니다.

“이미 해결한 문제는 다시 분석하지 않는다.”

하지만 이 규칙은 위험합니다.

같은 오류처럼 보여도

버전이 달라졌을 수 있고,

실행 환경이 달라졌을 수 있고,

원인이 달라졌을 수도 있습니다.

따라서 저는 이렇게 설정하는 것을 추천합니다.

기존에 검증된 해결 방법이 있고 현재 버전·환경·증상 등의 조건이 충분히 동일하다면 우선 재사용한다. 조건이 달라졌거나 반대되는 새로운 증거가 있다면 기존 판단을 그대로 적용하지 않고 다시 검토한다.

즉,

과거 경험은 무조건 따라야 하는 정답이 아니라 판단 비용을 줄여주는 자산입니다.

⸻

7. 과거 기록을 현재의 ‘명령’으로 취급하지 마세요

이것도 중요합니다.

과거 ChatGPT 대화나 Codex 작업 기록에서

“앞으로 이 방법을 사용하자.”

라고 이야기했다고 해보겠습니다.

몇 달 뒤에는 상황이 달라졌을 수 있습니다.

코드가 바뀌었을 수도 있고,

라이브러리 버전이 달라졌을 수도 있고,

더 좋은 방법으로 교체됐을 수도 있습니다.

그래서 저는 판단 우선순위를 다음처럼 두는 것을 추천합니다.

현재 요청

↓

현재 실제 코드와 실행 상태

↓

현재 적용되는 프로젝트 지침

↓

최근 검증된 작업 기록

↓

과거 기록

과거 기록과 현재 실제 상태가 다르면 다시 확인합니다.

한마디로,

과거 기록은 명령이 아니라 판단을 위한 근거로 사용합니다.

⸻

8. 중요한 작업에는 ‘체크포인트’를 남기세요

여기서 굉장히 중요한 것이 하나 있습니다.

체크포인트입니다.

체크포인트는 dots의 모든 작업에 자동으로 적용되는 마법 같은 공식 기능을 말하는 것이 아닙니다.

제가 장기 프로젝트에서 추천하는 운영 방식입니다.

쉽게 말하면,

“다음 작업이 과거 대화를 전부 다시 읽지 않고도 바로 이어갈 수 있도록 현재 상태를 짧게 저장하는 것”

입니다.

예를 들어 중요한 작업이 끝났다면 다음 정도를 기록합니다.

* 현재 목표
* 어디까지 완료했는지
* 변경된 주요 파일
* 실제 테스트 결과
* 사용한 중요한 출처
* 코드 버전
* 아직 완료되지 않은 것
* 현재 막힌 부분
* 다음 행동

이렇게 해두면 다음 작업에서 수십 개의 과거 대화를 읽는 대신,

최근 관련 체크포인트부터 확인하고 작업을 이어갈 수 있습니다.

⸻

9. 모든 행동마다 체크포인트를 만들 필요는 없습니다

체크포인트를 너무 많이 만들어도 다시 읽어야 할 정보만 늘어납니다.

저는 다음 정도를 추천합니다.

작업 시작

이번 작업의 목표와 시작 상태

중요한 단계 완료

핵심 기능 구현이나 중요한 테스트가 끝난 시점

작업 중단

어디서 왜 멈췄는지

인계

다른 에이전트나 사람이 이어서 작업해야 하는 시점

작업 종료

최종 결과와 검증 상태

이 정도면 충분합니다.

⸻

10. ‘저장했습니다’와 ‘실제로 저장됨’은 구분하세요

AI 에이전트를 장기간 운영한다면 이것도 꽤 중요합니다.

예를 들어 로컬에는 체크포인트가 저장됐지만 외부 저장소에는 반영되지 않았을 수 있습니다.

코드는 수정됐지만 Git에는 아직 반영되지 않았을 수도 있습니다.

원격 저장소에는 올라갔지만 실제 운영 환경에는 배포되지 않았을 수도 있습니다.

그래서

로컬 수정 완료

테스트 완료

체크포인트 저장 완료

원격 반영 완료

운영 배포 완료

를 같은 의미로 사용하면 안 됩니다.

중요한 저장 작업은 가능하다면 다시 조회해서 실제 반영 여부까지 확인하게 하는 것이 좋습니다.

⸻

11. 한 번 성공한 방법을 바로 Skill로 만들지 마세요

AI를 사용하다 보면 좋은 방법을 발견했을 때 바로 Skill이나 공식 규칙으로 저장하고 싶어집니다.

그런데 한 번 성공한 것은 우연일 수도 있습니다.

특정 버전에서만 동작했을 수도 있고,

특정 프로젝트에서만 통하는 방법일 수도 있습니다.

그래서 저는 작업 방법을 네 단계로 관리하는 것을 추천합니다.

실험 → 후보 → 검증 → 표준

실험

처음 시도한 방법

후보

다시 사용할 가치가 있어 보이는 방법

검증

반복 사용하면서 성공 조건과 실패 조건을 확인한 방법

표준

앞으로 반복적으로 사용할 공식 작업 방식

가능하면 Skill이나 장기적인 프로젝트 규칙에는 검증된 절차를 넣는 것이 좋습니다.

⸻

12. 실패 기록도 중요한 자산입니다

성공한 방법만 남길 필요는 없습니다.

실패한 작업도 다음 작업의 시간을 크게 줄여줄 수 있습니다.

다만

“이 방법은 안 된다.”

라고 저장하는 것은 추천하지 않습니다.

대신

“버전 A / 환경 B / 조건 C에서 이 방법을 사용했을 때 오류 D가 발생했다.”

처럼 조건과 함께 기록합니다.

왜냐하면 환경이나 버전이 달라지면 과거에 실패했던 방법이 다시 유효할 수도 있기 때문입니다.

성공에도 조건이 있고 실패에도 조건이 있습니다.

⸻

13. 모든 것을 Skill이나 MCP로 만들 필요도 없습니다

작업을 자산화한다고 해서 모든 것을 Skill로 만들 필요는 없습니다.

MCP도 마찬가지입니다.

예를 들어 어떤 API를 반복해서 사용한다고 바로 새로운 MCP부터 만드는 것보다,

기존 도구가 있는가?

↓

기존 스크립트로 해결 가능한가?

↓

단순한 API 호출이면 충분한가?

↓

반복성과 재사용성이 충분한가?

↓

그래도 필요하다면 MCP를 만들 것인가?

이 순서로 보는 것이 좋습니다.

가장 복잡한 방법부터 선택할 이유가 없습니다.

⸻

14. Skill은 ‘파일이 존재한다’와 ‘실제로 사용할 수 있다’가 다릅니다

Skill 역시 주의할 점이 있습니다.

어떤 폴더에 SKILL.md를 만들었다고 해서 모든 실행 환경에서 자동으로 인식되는 것은 아닙니다.

실제로는

* 현재 환경이 해당 Skill을 읽는지
* 올바른 위치에 있는지
* 요구되는 형식에 맞는지
* 실제 호출되는지
* 정상적으로 실행되는지

확인해야 합니다.

즉,

Skill 파일을 만들었다 = Skill이 실제로 작동한다

는 같은 말이 아닙니다.

⸻

15. 여러 에이전트를 동시에 사용한다면 충돌도 관리하세요

dots를 중심으로 여러 작업이나 에이전트를 동시에 돌리기 시작하면 새로운 문제가 생길 수 있습니다.

A가 어떤 파일을 수정하는 동안 B도 같은 파일을 수정할 수 있습니다.

A가 자료를 정리하고 있는데 B가 같은 자료를 다시 분석할 수도 있습니다.

따라서 여러 작업을 동시에 진행한다면 최소한

* 현재 진행 중인 작업
* 담당 범위
* 수정 중인 주요 파일
* 최근 체크포인트
* 최근 변경 이력

정도는 확인하는 것이 좋습니다.

에이전트 수가 늘어날수록 실행 능력뿐 아니라 충돌 관리도 중요해집니다.

⸻

16. 실시간 체크포인트와 정기 자동화의 역할을 나누세요

이미 몇 시간마다 돌아가는 정기 자동화가 있다면 같은 일을 하는 자동화를 계속 추가할 필요는 없습니다.

역할을 나누면 됩니다.

작업 중

바로 체크포인트를 남깁니다.

정기 자동화

쌓인 체크포인트를 모아서

* 중복 제거
* 오래된 정보 검토
* 반복되는 해결법 탐색
* 지식 정리
* Skill 후보 검토
* 검증된 방법의 승격 검토

등을 수행하게 할 수 있습니다.

쉽게 말하면,

체크포인트 = 작업 기억

정기 자동화 = 기억을 지식으로 정리하는 과정

이라고 보면 됩니다.

⸻

17. dots의 보고도 짧게 만들어두세요

dots에게 많은 일을 맡기기 시작하면 작업 보고가 지나치게 길어지는 것도 문제입니다.

모든 작업에서

어떤 도구를 사용했고,

어떤 생각을 했고,

다음에는 무엇을 추천하고….

이걸 전부 받을 필요는 없습니다.

평소에는 네 가지 정도면 충분합니다.

결과 / 변경 / 검증 / 남은 것

예를 들면,

결과: 로그인 오류 수정 완료
변경: 인증 관련 코드 수정
검증: 기존 로그인 및 하위호환 테스트 통과
남은 것: 운영 배포 필요

이 정도면 충분합니다.

단, 배포처럼 상태가 중요한 작업은

로컬 수정 완료 → 테스트 완료 → 운영 반영 대기

처럼 단계를 명확하게 구분하도록 합니다.

⸻

18. 운영 규칙과 권한은 별개입니다

마지막으로 반드시 구분해야 하는 부분입니다.

dots에게

“필요한 작업은 알아서 진행해.”

라는 운영 지침을 줬다고 해서 새로운 권한까지 자동으로 생기는 것은 아닙니다.

운영 지침은 어떻게 일할지를 정하는 규칙입니다.

새로운 외부 서비스에 정보를 보내거나,

새로운 계정에 접근하거나,

새로운 환경에 배포하거나,

삭제·결제·권한 변경처럼 위험도가 달라지는 작업까지 자동으로 승인하는 것은 아닙니다.

따라서 저는 다음 원칙을 추천합니다.

이미 승인된 범위 안에서는 불필요하게 반복해서 묻지 않는다.

하지만

새로운 대상이나 새로운 위험이 생겼다면 별도로 확인한다.

이렇게 구분하면 됩니다.

⸻

결국 dots를 이렇게 쓰는 겁니다

전체 구조를 다시 정리해보겠습니다.

1. 사람은 dots에게 목표를 전달합니다.

↓

2. dots는 현재 상태를 확인합니다.

↓

3. 현재 작업과 관련된 핵심 규칙과 기록을 필요한 범위에서 확인합니다.

↓

4. 현재 조건에 맞는 검증된 기존 자산이 있는지 확인합니다.

↓

5. 조건이 같다면 재사용하고, 다르다면 다시 판단합니다.

↓

6. 개발 작업이 필요하면 Codex 같은 전문 에이전트에 작업을 연결합니다.

↓

7. 실행 결과를 테스트하고 검증합니다.

↓

8. 중요한 결과는 체크포인트로 남깁니다.

↓

9. 중요한 저장은 실제 반영됐는지 확인합니다.

↓

10. 반복해서 검증된 작업 방식만 Skill이나 공식 규칙으로 승격합니다.

이 구조가 핵심입니다.

⸻

dots에 넣어둘 핵심 운영 지시문

실제로 운영한다면 아래 정도를 기본 원칙으로 만들어둘 수 있습니다.

기존 방식을 무조건 반복하지 않는다. 현재 요청에 필요한 검증된 자산을 우선 재사용하고, 조건이 달라지면 재검토한다.

작업 시작 시 모든 과거 자료를 읽지 않는다. 현재 상태와 적용되는 핵심 지침을 먼저 확인하고, 관련 기록을 좁게 조회한 뒤 필요한 경우에만 탐색 범위를 확장한다.

과거 기록은 현재 명령이 아니라 판단 근거로 사용한다. 기록과 현재 실제 상태가 다르면 현재 상태를 다시 확인한다.

중요한 작업 결과는 검증 후 체크포인트로 남긴다. 중요한 저장 작업은 가능한 경우 다시 조회하여 실제 반영 여부까지 확인한다.

새로운 방법은 한 번 성공했다고 공식 규칙으로 만들지 않는다. 실험 → 후보 → 검증 → 표준 단계를 거쳐 반복성이 확인된 방법만 Skill이나 공식 작업 방식으로 승격한다.

⸻

GPT dots 100% 활용의 핵심

결국 dots를 제대로 활용한다는 것은

모든 것을 dots에게 기억시키는 것이 아닙니다.

필요한 순간에 필요한 정보를 찾게 하고,

검증된 과거 경험은 재사용하게 하고,

상황이 달라지면 다시 판단하게 하고,

개발이 필요하면 Codex 같은 전문 에이전트에 맡기고,

작업 결과는 다음 작업이 이어받을 수 있는 형태로 남기는 것입니다.

그래서 저는 역할을 이렇게 정리하는 것이 가장 이해하기 쉽다고 봅니다.

나는 목표와 우선순위를 결정한다.

dots는 전체 작업을 연결하고 관리한다.

Codex는 개발 작업을 실행한다.

이 구조가 제대로 잡히면 사람이 매번 Codex 앞에서 다음 프롬프트를 고민하며 작업을 관리하는 시간이 줄어듭니다.

그리고 프로젝트가 쌓일수록 과거 자료를 더 많이 읽어야 하는 것이 아니라,

오히려 덜 읽고, 덜 설명하고, 더 빠르게 이어서 일할 수 있는 구조를 만들 수 있습니다.

그게 제가 추천하는 GPT dots 100% 활용 방법입니다.