7. 비개발자를 위한 Codex 사용법 기초: 프로젝트, 스레드, 파일, 프롬프트

Codex는 말을 잘하는 도구가 아니라, 일을 잘 나누는 도구다

많은 사람이 AI를 잘 쓰는 비결을 프롬프트 길이에서 찾습니다. 뭔가 엄청 정교하고 길고 멋진 지시문을 써야 좋은 결과가 나온다고 생각하죠.

그런데 Codex에서는 조금 다른 감각이 더 중요합니다.

Codex를 잘 쓰는 사람은 긴 프롬프트를 쓰는 사람이 아니라, 일을 작은 단위로 정확히 나누는 사람입니다.

이 차이는 아주 큽니다. 긴 프롬프트는 한 번에 많은 것을 담을 수 있지만, 대신 일이 쉽게 섞입니다. 반대로 작은 단위로 나눈 지시는 지금 무엇을 읽고, 무엇을 만들고, 어디에 저장해야 하는지 분명하게 만듭니다. Codex가 프로젝트를 디스크의 폴더와 연결하고, 그 안에서 스레드를 개별 작업 단위로 다루는 구조를 갖는 이유도 바로 여기에 있습니다.¹

쉽게 말해 Codex는 "한 번에 다 해줘"보다 "1단계부터 차례대로 해줘"에 더 강합니다.

프로젝트는 업무의 집, 스레드는 한 건의 일이다

Codex를 처음 쓸 때 가장 중요한 감각은 이것입니다. 프로젝트와 스레드는 비슷해 보여도 역할이 다릅니다.

프로젝트는 업무의 집입니다. 특정 폴더와 연결되어 있고, 그 안에 관련 파일과 기록이 쌓입니다. 예를 들어 AR-glasses-brochure라는 프로젝트를 만들었다면, 그 프로젝트 안에는 제품 사진, 수치 정리 문서, 초안 카피, 결과물 파일이 함께 살 수 있습니다.

반면 스레드는 그 집 안에서 진행하는 한 건의 일입니다. 같은 프로젝트 안에서도 스레드는 따로따로 나뉘어야 합니다. 예를 들어 이런 식입니다.

• 제품 사양만 정리하는 스레드

• 브로슈어용 지시사항을 만드는 스레드

• 최종 브로슈어 초안을 만드는 스레드

• 수정 요청을 반영하는 스레드

이렇게 나누면 무엇이 좋아질까요. 우선 문맥이 덜 엉킵니다. 제품 수치를 뽑는 일과 카피 톤을 다듬는 일은 서로 다른 집중력이 필요합니다. 하나의 긴 대화방에 다 몰아넣으면 사람도 헷갈리고 Codex도 흔들립니다.

그래서 외우기 쉽게 정리하면 이렇습니다.

프로젝트는 업무 종류별로 나누고, 스레드는 결과물별로 나눈다.

새 스레드를 만들어야 하는 순간

초보자는 스레드를 너무 적게 만들거나, 반대로 너무 잘게 쪼개는 실수를 자주 합니다. 기준은 의외로 단순합니다. 아래 중 하나라도 바뀌면 새 스레드를 만드는 쪽이 대체로 낫습니다.

• 만들려는 결과물이 달라질 때

• 읽어야 할 참고 파일 묶음이 달라질 때

• 검토 기준이 달라질 때

• 톤이나 대상 독자가 달라질 때

예를 들어 "제품 수치를 정리해줘" 다음에 바로 "이제 이걸 바탕으로 투자자용 소개 자료를 써줘"로 넘어가면, 얼핏 같은 일처럼 보여도 사실은 목적이 바뀐 것입니다. 전자는 정리 작업이고, 후자는 설득용 문서 작업입니다. 이럴 때는 새 스레드가 더 깔끔합니다.

반대로 같은 결과물을 조금씩 다듬는 중이라면 굳이 새 스레드를 만들 필요가 없습니다. 같은 브로슈어 초안을 손보는 중이라면 같은 스레드 안에서 이어 가는 편이 문맥 유지에 유리합니다.

파일을 다루는 순간 Codex는 더 강해진다

일반적인 대화형 AI는 말은 잘해도, 파일과 폴더가 얽힌 실무에서 갑자기 약해지는 경우가 많습니다. Codex는 반대로 여기서 힘을 냅니다. 프로젝트 안의 로컬 파일을 읽고, 필요한 파일을 찾아보고, 새 파일을 만들고, 결과를 저장하는 흐름이 원래부터 중심이기 때문입니다.¹

이 말은 비개발자에게 아주 중요합니다. 실무는 결국 파일의 세계이기 때문입니다. PDF, 이미지, 스프레드시트, 메모 파일, 마크다운 문서, 텍스트 초안. 우리가 하는 일은 대부분 파일을 읽고 바꾸고 다시 저장하는 일입니다.

Codex에서 파일 작업을 안정적으로 하려면 세 가지 원칙만 먼저 잡으면 됩니다.

• 먼저 읽고 이해하게 한다

• 원본과 작업본을 분리한다

• 결과 파일의 위치와 이름을 지정한다

이 세 가지를 지키면 실수가 크게 줄어듭니다.

예를 들어 이런 지시는 좋습니다.

02_reference 폴더의 파일만 읽고, AR 글래스 제품명·핵심 수치·확인 불가 항목을 정리해줘. 기존 파일은 수정하지 말고, 결과는 03_working/facts_v1.md에 저장해줘.

이 프롬프트가 좋은 이유는 간단합니다. 어디를 볼지, 무엇을 할지, 어디까지 허용할지가 모두 들어 있기 때문입니다.

반대로 이런 지시는 흐립니다.

이 폴더 보고 브로슈어에 필요한 내용 정리해줘.

이 문장도 틀리진 않지만, Codex 입장에서는 선택지가 너무 많습니다. 어느 파일을 우선 읽어야 하는지, 파일을 수정해도 되는지, 결과를 어디에 저장해야 하는지 전부 추측해야 합니다. 실무에서 추측은 늘 비용이 됩니다.

파일을 정확히 집어주는 습관이 생산성을 만든다

Codex 앱의 입력창에서는 @를 사용해 워크스페이스 안의 파일을 빠르게 찾을 수 있습니다.² 이 기능은 생각보다 강력합니다. 초보자는 자꾸 "그 문서", "그 이미지", "아까 그 파일"이라고 말하는데, Codex는 사람처럼 눈치를 보는 비서가 아닙니다. 정확한 파일을 집어주면 훨씬 잘 움직입니다.

예를 들어 아래 두 문장은 비슷해 보여도 품질 차이가 꽤 납니다.

제품 사양 문서를 참고해서 핵심 포인트를 뽑아줘.

이 문장보다,

@02_reference/ar_glasses_specs.pdf와 @02_reference/price-table.xlsx를 참고해서 핵심 포인트를 5개로 정리해줘.

이 문장이 훨씬 강합니다. 입력 재료가 분명해졌기 때문입니다.

비개발자 입장에서 이건 어렵게 느껴질 수 있지만, 사실 엑셀에서 셀 범위를 정확히 잡는 것과 비슷합니다. 범위를 흐리게 잡으면 결과가 흐려지고, 범위를 정확히 잡으면 결과가 또렷해집니다.

좋은 프롬프트는 길지 않고 선명하다

Codex 계열 모델은 장황한 설명을 잔뜩 붙이기보다, 핵심 제약을 짧고 분명하게 주는 편이 더 잘 맞는 경우가 많습니다.³ 그래서 좋은 프롬프트의 핵심은 문학성이 아니라 구조입니다.

가장 실무적인 기본 틀은 아래 네 가지입니다.

• 범위: 어디를 읽을지

• 작업: 무엇을 할지

• 제한: 무엇은 하지 말지

• 출력: 결과를 어떤 형식으로 어디에 둘지

이 틀만 익혀도 프롬프트 품질이 크게 올라갑니다.

예를 들어 로컬 이미지 정리 작업이라면 이렇게 쓸 수 있습니다.

01_inbox/images만 읽고 파일 목록을 표로 정리해줘. 아직 이미지 수정은 하지 말고, 배경 제거가 필요해 보이는 파일만 표시해줘. 결과는 04_output/image_inventory.md로 저장해줘.

브로슈어 준비 작업이라면 이렇게 쓸 수 있습니다.

02_reference의 제품 자료를 읽고, 브로슈어에 바로 쓸 수 있는 문장과 확인이 더 필요한 수치를 나눠서 정리해줘. 과장 표현은 넣지 말고, 결과는 03_working/brochure_notes_v1.md에 저장해줘.

여기서 중요한 것은 멋진 표현이 아닙니다. 경계가 선명한가입니다.

긴 프롬프트 한 번보다, 짧은 프롬프트 네 번이 더 낫다

비개발자가 Codex를 쓰다가 가장 크게 늘어나는 지점은 여기입니다. 처음에는 한 번에 다 시키려 합니다. 하지만 익숙해질수록 일을 나눠 맡깁니다.

예를 들어 AR 글래스 브로슈어를 만든다고 해봅시다. 한 번에 이렇게 시키면 어떨까요.

폴더 전체를 보고 제품 특징도 정리하고, 핵심 수치도 뽑고, 브로슈어 지시사항도 만들고, 최종 문안까지 작성해줘.

가능은 하겠지만, 결과는 대개 섞입니다. 수치 확인과 문장 작성과 지시사항 설계가 한 냄비에 끓기기 때문입니다.

이럴 때는 아래처럼 나누는 편이 낫습니다.

먼저 첫 번째 프롬프트에서는 자료만 읽게 합니다.

02_reference만 읽고 제품명, 스펙, 가격, 확인 불가 항목을 표로 정리해줘.

두 번째 프롬프트에서는 정리된 사실만 다듬게 합니다.

방금 만든 표를 바탕으로 브로슈어에 넣어도 되는 확정 정보와, 사람이 다시 확인해야 할 정보를 분리해줘.

세 번째 프롬프트에서는 지시사항 문서를 만듭니다.

확정 정보만 사용해서 브로슈어 생성을 위한 지시사항 초안을 작성해줘. 숫자는 원문 그대로 유지해줘.

마지막 네 번째 프롬프트에서야 실제 초안을 만듭니다.

방금 만든 지시사항을 바탕으로 1페이지 브로슈어 초안을 작성해줘.

이 흐름이 좋은 이유는 단계별 검토가 가능하기 때문입니다. 2단계에서 숫자가 틀리면 3단계로 넘기지 않으면 됩니다. 큰 사고는 대개 잘못된 재료가 뒤 단계로 흘러들어갈 때 생깁니다.

스레드 안에서도 한 턴씩 조종할 수 있다

Codex는 한 번 던지고 끝나는 도구가 아닙니다. 작업 중에도 방향을 조정할 수 있습니다. 앱에서는 작업이 진행되는 동안 추가 지시를 넣을 수 있고, 다음 턴에 이어질 프롬프트를 미리 예약하는 방식도 지원합니다.²

이 기능은 비개발자에게 특히 유용합니다. 왜냐하면 실제 업무는 늘 중간 수정이 있기 때문입니다.

예를 들어 자료 정리 중에 이런 생각이 들 수 있습니다.

"아, 가격 정보는 빼고 치수만 먼저 정리해달라고 해야겠다."

"문구 톤이 너무 광고 같네. 좀 더 담백하게 바꿔야겠다."

"이건 한국어판 말고 영어판도 필요하겠다."

이런 순간마다 새로 처음부터 다시 시작할 필요는 없습니다. 같은 스레드 안에서 짧게 방향을 잡아주면 됩니다. 다만 여기서도 원칙은 같습니다. 긴 설명보다 짧고 정확한 수정 지시가 낫습니다.

예를 들면 이렇게 말하면 충분합니다.

가격 관련 문장은 제외하고, 제품 크기와 무게 정보만 남겨줘.

혹은 이렇게도 좋습니다.

같은 내용으로 영어 버전 초안을 추가해줘. 숫자와 고유명사는 그대로 유지해줘.

작업을 이어서 조정할 수 있다는 점은 Codex를 단순 생성기가 아니라 작업 파트너로 느끼게 만드는 지점입니다.

fast 모드는 짧은 왕복에, 일반 모드는 큰 덩어리에 강하다

Codex 앱, CLI, IDE 확장에서는 ChatGPT 계정으로 로그인했을 때 Fast mode를 사용할 수 있습니다. 반면 API 키 방식에서는 Fast mode 크레딧을 쓰지 않습니다.⁴

비개발자에게 중요한 것은 기술적 배경보다 언제 켜는 게 좋은가입니다.

쉽게 비유하면, Fast mode는 택시이고 일반 모드는 지하철 같습니다.

택시는 빠릅니다. 대신 짧고 자주 탈 때 효율이 좋습니다. 지하철은 순간 가속은 덜해도, 큰 이동을 안정적으로 처리하는 느낌이 있습니다. Codex도 비슷하게 생각하면 이해가 쉽습니다.

Fast mode가 잘 맞는 작업은 보통 이런 쪽입니다.

• 문구를 짧게 여러 번 고쳐야 할 때

• 표 형식을 조금씩 다듬을 때

• 파일명 규칙을 맞추는 식의 작은 수정이 이어질 때

• 결과를 보고 바로 다시 지시하는 왕복이 많을 때

반대로 일반 모드가 잘 맞는 작업은 이런 경우가 많습니다.

• 여러 문서를 읽고 구조를 잡아야 할 때

• 초안의 큰 틀을 처음부터 만들어야 할 때

• 정보 정리와 판단이 함께 필요한 작업일 때

• 한 번의 결과물이 비교적 길고 무거울 때

실전에서는 이렇게 쓰면 편합니다. 처음 큰 틀을 잡을 때는 일반 모드로 가고, 막판에 문구를 다듬거나 형식을 만질 때 Fast mode로 바꾸는 것입니다. 즉, 설계는 차분하게, 미세 조정은 빠르게 가는 전략입니다.

비개발자를 위한 가장 실용적인 프롬프트 공식

이제부터는 아주 실용적인 공식 하나만 기억하면 됩니다.

읽을 것 + 할 일 + 금지할 것 + 저장할 곳

예를 들어,

@02_reference/specs.md와 @02_reference/measurements.xlsx를 읽고, 브로슈어용 핵심 수치를 표로 정리해줘. 추측은 하지 말고, 확인 불가 항목은 별도 섹션으로 빼줘. 결과는 03_working/fact_sheet_v1.md에 저장해줘.

이 한 문장 안에 필요한 게 거의 다 들어 있습니다.

이 공식을 습관으로 만들면 프롬프트가 길어지지 않아도 됩니다. 오히려 짧아집니다. 왜냐하면 불필요한 예의, 배경설명, 감정 표현을 줄이고 작업 요소만 남기게 되기 때문입니다.

물론 "부탁해", "고마워" 같은 말이 나쁘다는 뜻은 아닙니다. 다만 실무 품질을 바꾸는 것은 친절함보다 구조라는 뜻입니다.

실전 예시: AR 글래스 브로슈어 작업을 어떻게 나눌까

이 책의 뒤쪽에서 자세히 다룰 AR 글래스 브로슈어 사례를 여기서 미리 아주 간단히 나눠보겠습니다.

프로젝트는 AR-glasses-brochure 하나로 둡니다. 이 안에서 스레드는 최소 세 개로 나누는 편이 좋습니다.

첫 번째 스레드는 자료 수집과 정리입니다. 여기서는 제품 사진, 스펙, 가격, 크기, 무게처럼 사실 정보를 정리합니다.

두 번째 스레드는 브로슈어 생성용 지시사항 만들기입니다. 여기서는 첫 번째 스레드에서 정리한 확정 정보만 사용해, 이미지 생성이나 문안 초안에 쓸 지시문을 만듭니다.

세 번째 스레드는 최종 브로슈어 초안 생성입니다. 여기서는 지시사항 문서를 입력으로 삼아, 실제 결과물을 만듭니다.

이렇게 나누면 좋은 점은 아주 분명합니다. 숫자가 틀렸는지 확인하는 일과, 보기 좋은 문장을 만드는 일을 분리할 수 있습니다. 사실 검증과 표현 작업을 분리하는 순간 품질이 올라갑니다.

반대로 이걸 한 스레드에서 한 번에 하면, 숫자가 바뀔 때마다 문안까지 다시 흔들리고, 지시사항도 다시 꼬이기 쉽습니다.

초보자가 자주 하는 실수

처음 Codex를 쓸 때 자주 나오는 실수도 미리 알고 가면 좋습니다.

• 프로젝트 하나에 너무 다른 성격의 일을 몰아넣는 것

• 스레드 하나에서 자료 수집, 초안 작성, 수정 반영을 전부 한꺼번에 처리하는 것

• 결과 파일 이름과 저장 위치를 지정하지 않는 것

• 한 번에 완성본을 얻으려다 검토 단계 없이 다음 작업으로 넘어가는 것

이 네 가지는 모두 같은 문제에서 나옵니다. 일을 덩어리로 본다는 점입니다.

Codex를 잘 쓰는 사람은 AI를 똑똑한 한 명으로 보지 않습니다. 여러 단계의 일을 맡길 수 있는 팀처럼 봅니다. 그러면 자연스럽게 "자료 담당", "초안 담당", "수정 담당"처럼 작업을 나누게 됩니다. 비개발자에게도 이 관점이 아주 잘 맞습니다.

기억해야 할 핵심은 하나다

프로젝트는 일의 집이고, 스레드는 한 건의 일입니다. 파일은 정확히 집어줘야 하고, 프롬프트는 길기보다 선명해야 합니다. Fast mode는 짧고 빠른 왕복에 쓰고, 일반 모드는 큰 덩어리를 차분하게 처리할 때 쓰면 됩니다.

그리고 무엇보다 중요합니다.

Codex를 잘 쓰는 사람은 프롬프트를 길게 쓰는 사람이 아니라, 일을 작은 단위로 정확히 나누는 사람입니다.

이 감각만 몸에 붙으면, 다음부터는 자동화가 갑자기 거창한 기술처럼 보이지 않습니다. 그냥 일을 더 잘게 나누고, 더 정확하게 맡기고, 더 편하게 검토하는 방법으로 보이기 시작합니다.

참고

¹Working with Codex - OpenAI

²Mastering the Codex Desktop App: Automations, Triggers and the Review Queue

³Complete Guide to GPT-5-Codex API and Prompting: System Prompt, Best Practices, and Coding Insights

⁴Speed - Codex | OpenAI Developers