비개발자 AI 작업실 만들기 — 공용 폴더·계획 모드·파일 인계 규칙
비개발자가 여러 AI 도구와 파일을 연결할 때 공통 규칙과 6단계 작업 상태를 구분하고, 한 번에 한 명 작성 규칙·작업 티켓·계획 검토·충돌 복구를 적용하는 방법을 안내합니다.
승인한 최종본을 찾기 어렵거나 여러 AI 도구가 같은 파일을 고치고 있다면, 먼저 파일의 상태와 현재 작성자를 구분하세요. 어떤 파일이 요청이고 무엇이 작업 중인지, 어느 결과가 승인됐는지 알 수 있어야 다음 업무에 넘길 수 있습니다.
이 글은 하나의 작업 폴더에 에이전트 설정·회의 기록·결과 보고서·검수 문서를 두고, Claude와 Codex 같은 도구가 같은 자료를 기준으로 일하도록 구성하는 교육용 설계입니다. 제품별 설치 화면은 바뀔 수 있으므로 공용 폴더와 인계 원칙에 집중합니다.
작업실의 목적은 공유보다 상태 구분입니다
공용 폴더를 만든다고 모든 파일을 모든 에이전트에게 보여 줄 필요는 없습니다. 작업실의 첫 목적은 다음 질문에 답하는 것입니다.
- 새 요청은 어디에 들어오는가
- 현재 누가 작업 중인가
- 검토가 필요한 결과는 무엇인가
- 사람이 승인한 최종본은 무엇인가
- 게시된 결과와 보관할 기록은 무엇인가
하나의 폴더에 모든 문서를 쌓으면 검색은 가능해도 상태를 신뢰하기 어렵습니다. 파일 이동 또는 상태 필드를 사용해 업무 단계를 분리하세요.
비개발자용 최소 폴더 6개
다음 예시는 공통 규칙 폴더 하나와 요청·작업 중·검토·승인·게시·보관을 나누는 상태 폴더 여섯 개로 구성합니다. 코드 없이 파일 상태를 구분해 운영하는 구조입니다.
ai-company-workspace/
├── 00-company-rules/
├── 10-inbox/
├── 20-in-progress/
├── 30-review/
├── 40-approved/
├── 50-published/
└── 90-archive/
| 폴더 | 역할 | 넣으면 안 되는 것 |
|---|---|---|
00-company-rules |
문체·금지 작업·승인 원칙 | 개별 작업의 임시 메모 |
10-inbox |
새 요청과 입력 자료 | 수정 중인 결과물 |
20-in-progress |
현재 담당자가 작업 중인 파일 | 승인된 최종본 |
30-review |
검토 대상과 검토표 | 검토가 끝난 옛 버전 |
40-approved |
사람이 승인한 배포 대기본 | 미확인 초안 |
50-published |
실제 공개본과 게시 결과 | API 키·로그인 정보 |
90-archive |
종료 기록과 대체된 문서 | 현재 작업 입력으로 오해할 파일 |
폴더 번호는 탐색 순서를 고정하기 위한 예시입니다. 이미 조직의 저장 규칙이 있다면 이름을 바꾸되 상태 경계를 유지하세요.

회사 규칙과 개별 작업 지시를 분리합니다
모든 작업에 반복되는 규칙은 00-company-rules에 둡니다.
[공통 규칙 예시]
- 한국어로 짧고 명확하게 작성한다.
- 숫자와 고유명사는 원본 위치를 표시한다.
- 개인정보와 비밀정보를 일반 문서에 기록하지 않는다.
- 외부 발송·게시·결제·삭제는 사람이 승인한다.
- 불명확한 요구는 임의로 결정하지 않고 질문한다.
반면 “이번 주 SNS 초안 세 개 만들기” 같은 요청은 작업별 파일로 둡니다. 공통 규칙에 특정 캠페인명이나 마감일을 계속 추가하면 오래된 조건이 다른 작업에 섞일 수 있습니다.
규칙을 바꿀 때는 변경 날짜와 적용 범위를 남깁니다. 모든 과거 결과를 새 규칙으로 다시 고칠지, 다음 작업부터 적용할지도 사람이 결정합니다.
작업 티켓 한 장으로 입력과 결과를 연결합니다
새 업무를 시작할 때 파일 하나를 만들고 아래 항목을 채웁니다.
[작업 티켓]
work_id=sns-brief-2026-09-01
요청=다음 주 SNS 게시물 초안 3개 작성
담당=콘텐츠 실행자
입력=/10-inbox/sns-brief-2026-09-01/
사용 가능 자료=product-approved.md, public-posts.csv
출력=/20-in-progress/sns-brief-2026-09-01/draft.md
완료 조건=문구·이미지 방향·근거·미확인 항목 포함
검토=브랜드 담당, 컴플라이언스 담당
승인=운영자
상태=assigned
파일명보다 work_id를 기준으로 연결하면 초안·검토표·승인본을 한 업무로 추적하기 쉽습니다. 결과물 안에도 같은 ID를 적어 다른 작업의 자료와 섞이지 않게 합니다.
여러 AI 도구에는 ‘한 번에 한 명 작성’ 규칙을 적용합니다
Claude Code와 Codex처럼 로컬 프로젝트 파일을 읽고 수정할 수 있는 도구를 함께 사용할 수 있습니다. 그러나 같은 파일을 동시에 고치면 마지막 저장이 앞선 변경을 덮거나, 두 도구가 서로의 임시 내용을 완성본으로 오해할 수 있습니다.
권장 규칙은 간단합니다.
- 작업 티켓에 현재 작성자를 기록합니다.
- 작성자는 자기 출력 파일만 수정합니다.
- 검토자는 원본을 직접 고치지 않고 별도 검토표를 만듭니다.
- 수정이 필요하면 작성자에게 검토표를 되돌립니다.
- 담당을 바꿀 때 상태와 마지막 변경 요약을 갱신합니다.
예를 들어 Claude를 구조 초안 작성에, Codex를 파일·코드 검증에 사용할 수 있지만 고정된 우열은 없습니다. 각 도구가 접근 가능한 파일과 명령, 승인 방식이 다를 수 있으므로 현재 공식 문서와 실제 환경을 확인해야 합니다.

계획 모드에서는 기능보다 영향 범위를 읽습니다
비개발자가 계획서를 볼 때 모든 기술 용어를 이해할 필요는 없습니다. 다음 질문에 답이 있는지 확인하세요.
- 어떤 파일을 새로 만들고 어떤 파일을 수정하는가
- 외부 서비스 로그인이나 권한이 필요한가
- 실제 메시지·게시·결제가 발생하는가
- 결과물은 어느 폴더에 저장되는가
- 실패하면 어느 상태로 멈추는가
- 사람이 승인해야 다음 단계로 넘어가는 지점은 어디인가
- 원래 파일로 돌아갈 방법이 있는가
계획에 “적절히 처리”, “필요하면 게시”, “자동으로 정리”처럼 범위가 보이지 않는 표현이 있다면 실행 전에 구체화합니다. 이때 사용할 지시문은 다음과 같습니다.
내 목적과 핵심 의도는 유지하되 실행 단계를 파일 단위로 정리해 줘.
각 단계마다 읽는 파일, 만드는 파일, 외부로 바뀌는 상태,
사람 승인, 실패 시 중단 위치를 표시해 줘.
불명확한 부분은 임의로 결정하지 말고 질문해 줘.
설치·로그인·권한은 사람이 화면에서 확인합니다
AI 도구가 모든 준비 단계를 대신할 수 있는 것은 아닙니다. 다음 단계는 사용자가 직접 확인할 가능성이 높습니다.
- 앱 또는 도구 설치
- 계정 로그인과 인증 코드 입력
- 로컬 폴더 접근 허용
- 외부 서비스 OAuth 승인
- API 키 또는 비밀정보 저장
- 결제 정보 입력
화면에서 막히면 오류 문구와 현재 화면을 캡처해 보여 주되, 비밀번호·인증 코드·API 키·개인정보는 가립니다. 캡처 자체도 민감한 탭·알림·파일명이 보이지 않는지 확인하세요.
AI가 사용할 수 있는 파일 범위는 최소로 시작합니다. 전체 문서 폴더보다 이 작업실 폴더만 연결하고, 실제 고객 자료 대신 가짜 데이터로 먼저 시험하는 편이 안전합니다.
충돌이 생겼을 때 복구 순서
두 도구가 같은 파일을 수정했거나 결과가 섞였다면 계속 편집하지 말고 아래 순서로 멈춥니다.
- 현재 작성자 상태를
paused로 바꿉니다. - 충돌한 파일의 복사본을 별도 이름으로 보존합니다.
- 마지막 승인본 또는 변경 전 원본을 찾습니다.
- 각 버전에서 필요한 변경만 목록으로 비교합니다.
- 한 명의 작성자를 다시 지정해 새 파일에 반영합니다.
- 검토자가 완료 계약과 원본을 대조합니다.
- 승인된 뒤에만 기존 파일을 대체합니다.
버전을 정확히 비교할 수 있는 저장소라면 Git 같은 버전 관리를 사용할 수 있지만, 익숙하지 않다면 AI에게 삭제·초기화를 맡기지 말고 복사본과 변경 목록부터 확보하세요.
완료된 파일을 작업 입력에서 분리합니다
작업이 끝났다고 모든 파일을 같은 위치에 두면 다음 에이전트가 옛 초안을 다시 사용할 수 있습니다.
- 승인본은
40-approved로 이동합니다. - 실제 게시 결과는 URL·시간·콘텐츠 ID와 함께
50-published에 기록합니다. - 대체된 초안과 검토 기록은
90-archive로 이동합니다. - 임시 다운로드와 민감한 입력은 보관 정책에 따라 정리합니다.
- 공통 규칙으로 승격할 내용만
00-company-rules에 반영합니다.
파일을 옮기는 행위도 자동으로 실행하기보다 첫 운영에서는 사람이 확인하세요. 특히 원본 삭제와 최종본 덮어쓰기는 되돌릴 수 있는지 먼저 확인해야 합니다.
자주 묻는 질문
Q1. Claude와 Codex를 반드시 함께 써야 하나요?
아닙니다. 한 도구와 사람 검토로 시작할 수 있습니다. 두 도구는 역할과 검토 관점을 나누고 실제로 관리할 수 있을 때만 추가하세요.
Q2. 같은 폴더를 연결하면 두 도구가 자동으로 협업하나요?
아닙니다. 같은 파일을 볼 수 있을 뿐 담당·상태·인계 규칙은 별도로 정해야 합니다. 동시에 같은 파일을 수정하지 않도록 하세요.
Q3. 작업 티켓은 매번 새로 만들어야 하나요?
반복 업무라면 양식을 복사해 ID와 입력만 바꿀 수 있습니다. 다만 이전 수신자·날짜·승인 상태가 남지 않았는지 확인하세요.
Q4. 비개발자도 버전 관리를 사용할 수 있나요?
가능하지만 처음부터 복잡한 명령을 익힐 필요는 없습니다. 승인본과 작업본을 분리하고 복사본을 보존하는 습관부터 적용한 뒤 필요할 때 버전 관리 도구를 도입하세요.
Q5. 화면 캡처를 AI에게 보여 줘도 안전한가요?
캡처에 계정명·이메일·고객 데이터·API 키·인증 코드·브라우저 탭 정보가 포함될 수 있습니다. 필요한 영역만 자르고 민감정보를 가린 뒤 사용하세요.
마무리 — 파일을 공유하기 전에 상태를 공유하세요
새 요청이 어디에 있고 현재 누가 작성 중인지 작업 티켓에서 확인하세요. 요청, 작업 중, 검토, 승인, 게시, 보관의 상태를 나누고, 사람이 승인한 최종본을 다음 작업에 넘깁니다.
담당자를 바꿀 때는 티켓의 상태와 마지막 변경 요약도 갱신하세요. 다음 단계에서는 이 작업실에서 나온 결과를 외부 SNS에 게시하기 전에 승인과 중복 방지 흐름을 설계합니다.
공식 자료와 확인 기준일
- Anthropic — Set up Claude Code
- Anthropic — Claude Code CLI reference
- OpenAI Developers — Codex
- OpenAI Developers — Run long-horizon tasks with Codex
확인 기준일: 2026-09-25
함께 쓰는 업무 양식
멈출 조건까지 정하는 작업 지시서에서 준비 자료·복사용 지침과 프롬프트·검수표를 함께 확인할 수 있습니다. 독자 작성한 편집 예시이며, 실제 모델 실행 결과는 검증하지 않았습니다.