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

Codex를 잘 쓰는 사람은 말을 잘 시키는 사람이다

설치와 권한 설정이 끝났다면, 이제부터는 진짜 사용법의 영역으로 들어갑니다. 많은 사람이 이 단계에서 묻습니다.

"그래서 뭘 어떻게 말해야 잘 해주죠?"

정답은 의외로 단순합니다. Codex는 마음을 읽는 도구가 아니라, 맥락을 잘 받으면 잘 움직이는 도구입니다. 프로젝트를 어떻게 잡는지, 스레드를 어떻게 나누는지, 파일을 어떻게 지정하는지, 프롬프트를 얼마나 또렷하게 쓰는지에 따라 결과 차이가 꽤 크게 납니다.¹²

비개발자에게 이건 좋은 소식입니다. 코드를 잘 짜는 능력보다, 일을 정리해서 설명하는 능력이 더 중요하기 때문입니다. 다시 말해, Codex를 잘 쓰는 핵심은 프로그래밍 실력보다 업무 지시를 구조화하는 습관에 가깝습니다.

프로젝트는 책상이고, 스레드는 그 위의 일감이다

Codex 데스크톱은 보통 프로젝트를 중심으로 일합니다. 프로젝트는 어렵게 생각할 필요 없이, 하나의 작업 폴더이자 작업 공간이라고 보면 됩니다.¹²

예를 들어 AR-glass-brochure 폴더를 열었다면, 그 폴더 전체가 하나의 프로젝트입니다. 제품 사진, 수치표, 초안 문서, 결과물이 그 안에 들어 있습니다. 쉽게 말해 프로젝트는 "이번 일의 책상"입니다.

그 안에서 스레드는 각각의 작업 대화입니다.¹² 같은 프로젝트 안에서도 해야 할 일은 여러 갈래로 나뉩니다. 예를 들면 이런 식입니다.

• 제품 수치만 정리하는 스레드

• 브로슈어 문구를 쓰는 스레드

• 표지 문안을 여러 버전으로 뽑는 스레드

• 이미지 파일명을 정리하는 스레드

여기서 중요한 포인트가 하나 있습니다. 프로젝트는 넓고, 스레드는 좁아야 합니다.

프로젝트는 자료와 결과물이 모여 있는 큰 작업 공간입니다. 반면 스레드는 한 번에 해결할 작은 일이어야 합니다. 프로젝트까지는 넉넉하게, 스레드부터는 날카롭게 잡는다고 생각하면 좋습니다.

이 차이를 이해하면 작업이 갑자기 쉬워집니다. "브로슈어 프로젝트"는 하나지만, 그 안의 대화는 "수치 추출", "카피 초안", "페이지 구성 제안"처럼 따로 가야 덜 헷갈립니다.

스레드를 잘 나누면 결과가 덜 엉킨다

처음 쓰는 사람은 자주 이렇게 합니다.

"이 폴더를 읽고, 제품 수치를 정리하고, 브로슈어 문구도 만들고, 표지도 3안 만들고, 이미지 이름도 바꿔줘."

이렇게 한 번에 시키면 사람도 숨이 차고, Codex도 일의 우선순위를 흐리기 쉽습니다. 한 대화 안에서 너무 많은 목표가 섞이면 결과도 섞입니다.

더 좋은 방식은 일을 스레드 단위로 나누는 것입니다.

먼저 한 스레드에서는 이렇게 갑니다.

reference 폴더의 자료를 읽고 제품의 핵심 수치만 추려서 output/spec-summary.md에 정리해줘. 아직 브로슈어 문안은 쓰지 마.

다음 스레드에서는 이렇게 이어갑니다.

방금 정리된 output/spec-summary.md를 바탕으로 전시회용 브로슈어의 핵심 문구 5개를 제안해줘. 제품 수치는 새로 추정하지 말고 기존 정리본만 사용해줘.

이렇게 하면 스레드마다 책임이 분명해집니다. 하나는 숫자 정리, 하나는 문구 작성입니다. 일이 엉키지 않으니 검토도 쉬워집니다.

스레드를 나누는 기준도 어렵지 않습니다. 아래 셋 중 하나라도 달라지면 새 스레드를 고려하면 됩니다.

• 목표가 달라질 때

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

• 결과물 형식이 달라질 때

반대로 목표가 같고, 같은 결과물을 조금씩 다듬는 과정이라면 새 스레드를 만들지 말고 기존 스레드에서 이어가는 편이 좋습니다.

파일은 "알아서 찾겠지"보다 "이걸 봐"가 훨씬 낫다

Codex는 파일을 읽고 일하는 데 강하지만, 그렇다고 사용자가 아무 힌트도 안 줘도 된다는 뜻은 아닙니다. 오히려 반대입니다. 관련 파일을 분명하게 지정할수록 결과가 좋아집니다. OpenAI 문서도 프롬프트를 보낼 때 관련 파일과 이미지 같은 맥락을 함께 주라고 안내합니다.³

비개발자 관점에서는 이 원칙만 기억하면 충분합니다.

말로 설명한 내용보다, 실제 파일이 더 정확하다.

예를 들어 "지난번 표 참고해서"라고 말하는 것보다 reference/specs.xlsx를 정확히 가리키는 편이 훨씬 낫습니다. "그 사진"이라고 하는 것보다 input/front-view.png와 input/side-view.png를 지정하는 편이 훨씬 안전합니다.

같은 지시라도 아래 둘의 차이는 큽니다.

좋지 않은 지시:

제품 정보 보고 브로슈어 써줘.

좋은 지시:

reference/specs.xlsx와 prompt/brand-tone.md를 참고해서 전시회용 브로슈어 문구 초안을 작성해줘. 결과는 output/brochure-copy-v1.md에 저장해줘.

두 번째 문장은 Codex가 훨씬 덜 헤맵니다. 참고 파일, 톤 가이드, 출력 위치가 모두 분명하기 때문입니다.

좋은 프롬프트는 길어서가 아니라 선명해서 좋다

좋은 프롬프트를 쓰려면 문장을 멋있게 쓸 필요는 없습니다. 대신 몇 가지 요소가 분명해야 합니다. OpenAI의 Codex 프롬프팅 가이드는 대체로 할 일, 범위, 제약, 검증 기준을 분명히 두는 방식을 권합니다.³⁴

비개발자용으로 가장 쉬운 프롬프트 구조는 다음과 같습니다.

• 무엇을 할지

• 무엇을 참고할지

• 어디까지 할지

• 무엇을 하지 말아야 하는지

• 결과를 어떤 형태로 낼지

이 다섯 가지만 들어가도 결과 품질이 눈에 띄게 좋아집니다.

예를 들어 아주 짧게 써도 충분합니다.

reference/specs.xlsx와 input/product-images를 참고해 AR 글래스 브로슈어 초안을 작성해줘. 대상은 전시회 방문객이고, 톤은 쉽고 미래지향적으로. 수치는 파일에 있는 값만 사용하고 추정하지 마. 결과는 output/brochure-draft.md에 저장해줘. 먼저 1페이지 구성안부터 제안해줘.

이 프롬프트가 좋은 이유는 명확합니다. 해야 할 일, 참고 자료, 독자, 톤, 금지 조건, 출력 파일, 진행 순서가 모두 들어 있기 때문입니다.

반대로 아래처럼 쓰면 Codex도 애매해집니다.

멋지게 만들어줘. 부족한 건 알아서 보완해줘.

사람끼리 일해도 이런 말은 위험합니다. Codex에게도 마찬가지입니다. "멋지게"는 기준이 없고, "알아서"는 범위가 없습니다.

프롬프트에서 특히 중요한 네 단어

비개발자가 Codex를 쓸 때 결과를 안정적으로 만드는 단어가 있습니다. 바로 참고, 제한, 출력, 검토입니다.

먼저 참고는 근거를 분명히 합니다. 어떤 파일과 어떤 정보를 기준으로 할지 밝혀 주는 말입니다.

그다음 제한은 사고를 줄여줍니다. 예를 들어 "추정하지 마", "원본은 수정하지 마", "output 폴더에만 저장해" 같은 말이 여기에 들어갑니다.

그리고 출력은 결과물을 분명히 합니다. 문단 초안인지, 표인지, Markdown 파일인지, 파일명은 무엇인지까지 지정하면 좋습니다.

마지막 검토는 중간 브레이크입니다. "바로 최종본 쓰지 말고 먼저 개요를 보여줘", "실행 전에 계획부터 말해줘", "수정 전 어떤 파일을 바꿀지 먼저 알려줘" 같은 식입니다.⁴

이 네 단어를 넣으면 프롬프트가 훨씬 실무적으로 변합니다. 감탄사는 줄고, 결과는 또렷해집니다.

같은 일은 같은 스레드에서 이어가야 한다

이 부분은 초보자가 가장 자주 놓치는 핵심입니다. 같은 작업을 계속 다듬는 중이라면, 새 스레드를 열기보다 같은 스레드에서 이어가는 편이 좋습니다.

이유는 간단합니다. 스레드는 그 작업의 맥락을 쌓아두는 자리이기 때문입니다.¹² 이미 어떤 파일을 봤는지, 어떤 버전을 만들었는지, 어떤 방향이 싫었는지, 무엇을 고치기로 했는지가 대화 안에 남아 있습니다. 같은 일인데 매번 새 스레드를 열면 그 맥락을 다시 설명해야 합니다.

예를 들어 브로슈어 문구 작업을 하고 있다면, 이런 흐름은 한 스레드에서 이어지는 게 좋습니다.

처음 요청:

spec-summary.md를 바탕으로 브로슈어 핵심 문구 5개를 제안해줘.

두 번째 요청:

2번과 4번 문구 방향이 좋아. 더 짧고 강한 톤으로 다시 써줘.

세 번째 요청:

4번 문구를 제목으로 쓰고, 본문 3문단 초안까지 이어서 작성해줘.

이건 전부 같은 산출물을 키워 가는 과정입니다. 새 스레드를 파면 오히려 흐름이 끊깁니다.

반면 아래 경우라면 새 스레드가 더 낫습니다.

• 브로슈어 문구 작업에서 이미지 파일 정리 작업으로 넘어갈 때

• 초안 작성에서 배경 제거 자동화처럼 성격이 전혀 다른 일로 바뀔 때

• 같은 자료를 쓰더라도 전혀 다른 결과물을 만들 때

쉽게 말해, 같은 접시를 다듬는 중이면 같은 스레드, 새 요리를 시작하면 새 스레드입니다.

작업 중간에 말 걸어도 된다

Codex는 한 번 시켜 놓고 끝까지 침묵해야 하는 도구가 아닙니다. 작업 도중에도 방향을 바로잡을 수 있습니다.

이건 비개발자에게 아주 유용합니다. 처음부터 완벽한 지시를 쓰기 어렵기 때문입니다. 중요한 건 처음 문장을 완벽하게 만드는 게 아니라, 중간에 수정할 줄 아는 것입니다.

예를 들어 진행 중에 이런 식으로 바로잡을 수 있습니다.

숫자는 표 형식으로만 보여줘.

문체가 너무 광고 같아. 설명형으로 바꿔줘.

input 폴더는 건드리지 말고 output에 새 파일로 저장해줘.

이런 짧은 한마디가 결과를 꽤 크게 바꿉니다. 사람에게 일 맡길 때도 "아, 그 방향 말고 이쪽"이라고 하듯이, Codex에도 그렇게 해주면 됩니다.

반복되는 지시는 템플릿으로 만들어 두면 편하다

자주 쓰는 지시가 있다면 매번 처음부터 다시 쓸 필요는 없습니다. 같은 구조의 일을 반복할 때는 잘 통했던 프롬프트를 템플릿처럼 재사용하면 됩니다.

예를 들어 브로슈어 초안 생성, 제품 수치 정리, 파일명 규칙 변경처럼 반복되는 작업은 아예 템플릿 문장으로 만들어 두면 좋습니다. 이렇게 해두면 장점이 큽니다.

첫째, 매번 말투가 달라져서 결과가 흔들리는 일을 줄일 수 있습니다. 둘째, 어떤 지시가 잘 먹혔는지 스스로 학습하게 됩니다. 셋째, 나중에 업무 루틴을 자동화로 넘길 때도 기반이 됩니다.

비개발자에게 템플릿은 거창한 기능이 아니라, "잘 통하는 말버릇을 저장해두는 것"에 가깝습니다.

바로 써먹는 프롬프트 공식

처음에는 아래 공식만 기억해도 충분합니다.

[참고 파일]을 바탕으로 [해야 할 일]을 해줘. 범위는 [어디까지]이고, [하지 말아야 할 것]은 제외해줘. 결과는 [출력 형식/파일명]으로 만들어줘. 시작하기 전에 [검토 단계]부터 보여줘.

예를 들어 이렇게 바꿔 쓸 수 있습니다.

reference/specs.xlsx와 prompt/brand-tone.md를 바탕으로 AR 글래스 브로슈어 첫 페이지 초안을 작성해줘. 범위는 제목, 부제, 핵심 문장 3개까지이고, 수치는 파일에 없는 내용을 추정하지 마. 결과는 output/page1-draft.md로 만들어줘. 시작하기 전에 먼저 구성안을 보여줘.

이 정도면 이미 상당히 좋은 실무 프롬프트입니다.

기억해야 할 가장 중요한 습관

Codex를 잘 쓰는 사람은 대체로 같은 습관을 갖고 있습니다.

• 프로젝트는 넓게, 스레드는 좁게 잡습니다.

• 말보다 파일을 더 정확한 근거로 씁니다.

• 프롬프트에서 목표와 제한을 분명히 씁니다.

• 같은 결과물을 다듬는 동안에는 같은 스레드를 유지합니다.

• 중간에 방향이 어긋나면 짧게라도 바로 수정 지시를 넣습니다.

이 다섯 가지가 자리 잡으면, Codex는 "신기한 채팅창"에서 "일을 맡길 수 있는 작업 도구"로 바뀝니다.

결국 핵심은 하나입니다. 무엇을 시킬지보다, 무엇을 근거로 어디까지 시킬지를 분명히 하는 것. 바로 그 선명함이 결과 품질을 바꿉니다.

참고

¹Working with Codex - OpenAI

²App - Codex app | OpenAI Developers

³Prompting - Codex | OpenAI Developers

⁴Codex Prompting Guide - OpenAI Cookbook