13. 반복 가능한 시스템으로 확장하기: 템플릿, 자동화, 나만의 업무 루틴

한 번 잘한 일보다, 다음에도 잘되게 만드는 일이 더 중요하다

앞 장들에서는 분명한 성과를 만들었습니다. 로컬 이미지를 가공했고, AR 글래스 브로슈어를 위한 자료를 모았고, 그 자료를 바탕으로 실제 초안까지 만들었습니다. 여기까지 오면 많은 사람이 이렇게 생각합니다.

"좋다. 이제 필요할 때 또 하면 되겠네."

그런데 실무는 생각보다 냉정합니다. 한 번은 잘되는데, 두 번째부터 흔들리는 경우가 아주 많습니다. 지난번에는 파일이 어디 있었는지 기억나지 않고, 어떤 프롬프트를 썼는지 못 찾고, 결과물 이름이 제각각이라 비교가 어렵고, 검토 기준도 그때그때 달라집니다. 그러면 사람은 다시 처음부터 시작하게 됩니다.

이 장의 핵심은 바로 여기 있습니다.

업무 자동화에서 진짜 실력은 한 번 잘하는 것이 아니라, 다음에도 비슷한 품질로 반복되게 만드는 것입니다.

Codex를 잘 쓰는 비개발자는 마법 같은 프롬프트를 외우는 사람이 아닙니다. 대신 일을 반복 가능한 구조로 바꾸는 사람입니다. 즉, 기억에 의존하던 작업을 템플릿으로 바꾸고, 매번 손으로 하던 단계를 루틴으로 바꾸고, 결과 품질을 사람 기분이 아니라 체크 기준으로 관리하는 사람입니다.

자동화는 버튼 하나가 아니라 구조 하나다

자동화를 떠올리면 많은 사람이 "한 번 누르면 다 되는 것"을 상상합니다. 물론 그런 형태도 있습니다. 하지만 비개발자에게 더 현실적이고 더 강력한 자동화는 조금 다릅니다.

그것은 대개 이런 모습입니다.

• 입력 폴더가 정해져 있다.

• 출력 파일 이름 규칙이 정해져 있다.

• 프롬프트 템플릿이 준비되어 있다.

• 검토 체크리스트가 있다.

• 작업이 끝난 뒤 저장 위치가 고정되어 있다.

겉보기에는 단순해 보이지만, 바로 이 구조가 사람을 편하게 만듭니다. 매번 고민해야 할 것을 줄여 주기 때문입니다.

예를 들어 배경 제거 작업을 한다고 해봅시다. 이전에는 "어디에 원본을 넣지?", "출력 파일 이름은 어떻게 하지?", "투명 배경 PNG로 저장해 달라고 매번 말해야 하나?" 같은 작은 고민이 계속 생깁니다. 이런 고민은 하나하나 작아 보여도 반복되면 피로가 큽니다.

반면 시스템이 있으면 이렇게 바뀝니다.

원본은 01_inbox에 넣는다. 결과물은 02_output에 저장한다. 파일명은 원본 파일명 뒤에 _transparent를 붙인다. 검토가 끝난 파일만 03_final로 옮긴다.

이 정도만 정해도 일은 훨씬 덜 흔들립니다. 자동화는 대단한 기술이 아니라, 헷갈릴 지점을 미리 없애는 설계에 가깝습니다.

반복되는 업무는 대개 네 가지로 쪼갤 수 있다

업무를 시스템으로 만들려면 먼저 업무를 잘게 나눠 볼 필요가 있습니다. 비개발자에게 가장 쉬운 방법은 반복 작업을 네 덩어리로 보는 것입니다.

첫 번째는 입력입니다. 무엇이 들어오는가입니다. 이미지 파일, 회의 메모, 제품 스펙, 판매 CSV, 이메일 내용 같은 것들입니다.

두 번째는 처리입니다. 무엇을 하게 할 것인가입니다. 요약, 정리, 분류, 배경 제거, 초안 작성, 표 변환, 파일 이름 정리 같은 단계가 여기에 들어갑니다.

세 번째는 출력입니다. 결과를 어떤 형식으로 남길 것인가입니다. 마크다운 문서인지, CSV인지, PNG인지, 리뷰 메모인지가 이 단계에서 결정됩니다.

네 번째는 검토입니다. 결과가 괜찮은지 어떻게 확인할 것인가입니다. 숫자가 맞는지, 과장 표현이 없는지, 파일 누락이 없는지, 이미지가 깨지지 않았는지 확인하는 단계입니다.

이 네 가지를 종이에 적어 보면, 막연하던 업무가 꽤 또렷해집니다.

예를 들어 "매주 제품 소개 자료를 만든다"는 업무는 사실 이렇게 바뀔 수 있습니다.

입력은 제품 이미지와 스펙표입니다. 처리는 검증된 정보 추출, 문안 초안 작성, 이미지 후보 정리입니다. 출력은 브로슈어 초안과 이미지 배치 메모입니다. 검토는 숫자 확인, 톤 조정, 과장 문구 제거입니다.

이렇게 바꾸는 순간, 일은 더 이상 감각의 영역에만 있지 않습니다. 시스템으로 옮길 수 있는 형태가 됩니다.

템플릿은 매번 새로 생각하지 않게 해주는 장치다

사람들은 템플릿을 종종 "형식적인 것" 정도로 생각합니다. 하지만 실제 업무에서는 템플릿이 실력을 지켜 줍니다. 템플릿이 없으면 잘한 경험도 사라집니다. 지난번에 잘 쓴 프롬프트, 잘 먹힌 폴더 구조, 검토하면서 중요했던 질문이 머릿속에서 희미해지기 때문입니다.

템플릿은 쉽게 말해 성공한 방식을 파일로 고정한 것입니다.

가장 먼저 만들기 좋은 템플릿은 폴더 템플릿입니다. 예를 들어 브로슈어 업무를 반복한다면, 새로운 제품이 들어올 때마다 같은 구조를 복사해서 시작할 수 있습니다.

brochure-template/
├─ 01_inbox/
│  ├─ images/
│  ├─ specs/
│  └─ notes/
├─ 02_verified/
│  ├─ images/
│  ├─ specs/
│  └─ facts/
├─ 03_prompts/
│  ├─ instruction_template.md
│  ├─ review_template.md
│  └─ layout_request_template.md
├─ 04_output/
│  ├─ draft/
│  ├─ review/
│  └─ final/
└─ 05_archive/

이 구조의 장점은 아주 큽니다. 새 프로젝트를 시작할 때마다 "이번에는 폴더를 어떻게 나누지?"를 고민할 필요가 없습니다. 그리고 누가 봐도 지금 어느 단계까지 왔는지 이해하기 쉽습니다.

비개발자에게 특히 중요한 점은, 템플릿이 있어야 Codex에게 지시하기도 쉬워진다는 것입니다. 폴더 구조가 고정되면 프롬프트도 짧고 명확해집니다. "01_inbox/specs를 읽고 검증된 정보만 02_verified/facts에 정리해줘"처럼 말할 수 있기 때문입니다.

프롬프트도 템플릿이 될 수 있다

많은 사람이 템플릿이라고 하면 문서 양식만 떠올립니다. 하지만 Codex를 쓰는 사람에게는 프롬프트 템플릿도 매우 중요합니다. 같은 작업을 반복할 때 매번 처음부터 문장을 새로 짜는 것은 비효율적입니다.

오히려 좋은 방법은, 성공한 프롬프트를 조금 일반화해서 재사용 가능한 뼈대로 만드는 것입니다.

예를 들어 이런 기본 틀은 거의 모든 업무에 응용할 수 있습니다.

이 프로젝트에서 {입력 폴더}의 파일을 읽고 {목표}를 수행해줘.
결과는 {출력 폴더}에 {파일명 규칙}으로 저장해줘.
{금지 사항}을 지켜줘.
작업 후에는 읽은 파일, 생성한 파일, 확인이 필요한 항목을 짧게 정리해줘.

이 템플릿의 좋은 점은 단순하다는 것입니다. 멋진 문장을 쓰지 않아도 됩니다. 대신 중요한 항목이 빠지지 않습니다.

브로슈어 초안용으로 바꾸면 이렇게 됩니다.

02_verified/facts와 02_verified/images를 읽고 2페이지 브로슈어 초안을 작성해줘.
결과는 04_output/draft/brochure_draft_v1.md로 저장해줘.
검증되지 않은 정보는 사용하지 말고, 과장 표현은 줄여줘.
작업 후에는 사용한 자료와 추가 확인이 필요한 부분을 함께 정리해줘.

이미지 가공 업무용으로 바꾸면 이렇게 됩니다.

01_inbox/images의 파일을 읽고 배경을 투명하게 만든 PNG 결과물을 생성해줘.
결과는 02_output/transparent에 원본 파일명 뒤 _transparent를 붙여 저장해줘.
원본 파일은 수정하지 말고 삭제도 하지 말아줘.
작업 후에는 처리된 파일 수와 수동 검토가 필요한 파일을 알려줘.

즉, 프롬프트 템플릿이 있으면 일의 품질이 사람의 순간 집중력에 덜 좌우됩니다.

검토 기준도 함께 템플릿화해야 한다

자동화에서 가장 자주 빠지는 함정은 이것입니다. 만드는 과정은 자동화했는데, 검토 기준은 여전히 머릿속에만 있는 상태입니다. 그러면 결과가 들쑥날쑥해집니다.

예를 들어 브로슈어 초안을 만들었는데, 어떤 날은 문장 길이를 중요하게 보고, 어떤 날은 스펙 정확도만 보고, 어떤 날은 이미지 분위기만 봅니다. 기준이 계속 바뀌면 반복 가능한 시스템이 아닙니다.

그래서 검토도 템플릿으로 만들어 두는 편이 좋습니다.

예를 들면 이런 체크리스트가 가능합니다.

브로슈어 검토 체크리스트
- 모든 수치가 verified 자료와 일치하는가?
- 확인되지 않은 주장이 섞이지 않았는가?
- 첫 화면에서 핵심 메시지가 10초 안에 읽히는가?
- 이미지와 문장이 같은 맥락을 말하는가?
- 과장된 표현이 과도하지 않은가?
- 최종 파일명과 버전 표기가 맞는가?

배경 제거 작업이라면 기준이 달라질 수 있습니다.

이미지 가공 검토 체크리스트
- 배경이 깨끗하게 제거되었는가?
- 제품 가장자리가 부자연스럽지 않은가?
- 그림자나 반사 표현이 어색하지 않은가?
- 결과 파일 형식이 PNG로 맞는가?
- 파일명이 규칙대로 저장되었는가?

이 체크리스트는 사소해 보여도 매우 중요합니다. 사람은 피곤할 때 중요한 것을 놓치기 쉽지만, 체크리스트는 그런 날에도 기준을 붙잡아 줍니다.

좋은 시스템은 사람 기억이 아니라 파일 구조가 기억한다

업무가 안정적으로 반복되려면 "내가 알아서 기억하고 있지"라는 상태에서 벗어나야 합니다. 기억은 생각보다 잘 배신합니다. 지난달에는 잘했던 작업도, 바쁜 주에는 순서가 꼬이기 쉽습니다.

그래서 시스템은 가능한 한 파일이 기억하게 만들어야 합니다.

예를 들어 다음 요소들은 파일로 남겨 두는 것이 좋습니다.

• 폴더 구조

• 프롬프트 템플릿

• 검토 체크리스트

• 파일명 규칙

• 버전 규칙

• 작업 완료 기준

이런 것들이 정리되어 있으면, 다음 번의 나는 물론이고 다른 사람도 그 흐름을 따라갈 수 있습니다. 혼자 일하는 사람에게도 중요합니다. 왜냐하면 한 달 뒤의 나는 사실상 다른 사람처럼 느껴질 때가 많기 때문입니다.

'반자동 루틴'부터 만드는 것이 현실적이다

비개발자가 처음부터 완전 자동화를 목표로 삼으면 오히려 지치기 쉽습니다. 일정 시간마다 알아서 실행되고, 모든 파일을 자동 분류하고, 결과물까지 완성하는 시스템은 멋져 보이지만 처음부터 거기까지 갈 필요는 없습니다.

더 현실적인 출발점은 반자동 루틴입니다.

반자동 루틴이란, 시작 버튼은 사람이 누르지만 그 이후 흐름은 거의 같은 방식으로 굴러가는 형태입니다. 예를 들어 월요일 오전에 새 자료를 01_inbox에 넣고, 미리 준비된 프롬프트 파일을 열어 Codex에 실행시키고, 결과를 체크리스트로 검토한 뒤 final 폴더에 옮기는 식입니다.

이 방식의 장점은 큽니다. 사람은 통제권을 잃지 않으면서도 반복 피로를 크게 줄일 수 있습니다. 그리고 무엇보다, 오류가 났을 때 어디를 고쳐야 하는지 알기 쉽습니다.

완전 자동화보다 반자동 루틴이 먼저인 이유는 간단합니다. 반복 가능한 패턴이 먼저 있어야 진짜 자동화도 가능하기 때문입니다.

실전 예시 1: 로컬 이미지 가공을 루틴으로 바꾸기

10장에서 했던 이미지 가공 작업을 떠올려 봅시다. 그때는 한 번의 성공 경험이 중요했습니다. 이번에는 그 작업을 "매주 반복되는 시스템"으로 바꿔 보겠습니다.

가장 단순한 구조는 이렇습니다.

image-workflow/
├─ 01_inbox/
├─ 02_processed/
│  ├─ transparent/
│  └─ resized/
├─ 03_review/
├─ 04_final/
└─ prompt_templates/
   ├─ background_remove.md
   └─ resize_export.md

이제 업무 루틴도 정할 수 있습니다.

월요일 오전에는 새 제품 이미지를 01_inbox에 넣습니다. 그다음 background_remove.md 템플릿을 사용해 Codex에 배경 제거를 지시합니다. 결과물은 02_processed/transparent에 쌓입니다. 여기서 가장자리나 그림자가 어색한 파일만 03_review 메모에 기록합니다. 수정이 끝난 것만 04_final로 옮깁니다.

이 흐름의 장점은 단순합니다. 다음 주에도 똑같이 할 수 있다는 것입니다. 그리고 어떤 파일이 원본인지, 어떤 파일이 처리 중인지, 무엇이 최종본인지 헷갈리지 않습니다.

한 번 더 발전시키면 파일명 규칙도 붙일 수 있습니다.

원본은 product-001.jpg, 처리본은 product-001_transparent.png, 최종본은 product-001_transparent_final.png처럼 정하는 식입니다.

이쯤 되면 자동화는 이미 상당히 진행된 것입니다. 버튼 하나는 아니지만, 매번 새로 고민할 요소가 거의 없어졌기 때문입니다.

실전 예시 2: AR 글래스 브로슈어 작업을 시스템으로 바꾸기

11장과 12장에서 했던 브로슈어 작업은 특히 시스템화하기 좋은 업무입니다. 이유는 명확합니다. 입력 자료 종류가 비슷하고, 검토 기준도 반복되며, 결과물 형식도 자주 비슷하기 때문입니다.

예를 들어 신제품이 나올 때마다 아래 흐름으로 작업할 수 있습니다.

먼저 새 프로젝트 폴더를 템플릿에서 복사합니다. 그 안에 이미지, 스펙, 메모를 넣습니다. Codex에게 검증 단계용 프롬프트를 실행시켜 verified 자료를 분리합니다. 그다음 레이아웃 계획 템플릿으로 초안 구조를 만듭니다. 이어서 문안 작성 템플릿으로 브로슈어 초안을 생성합니다. 마지막으로 리뷰 템플릿을 사용해 과장 표현, 수치 정확성, 이미지 맥락을 점검합니다.

여기서 특히 중요한 것은 "이번 제품이 다르니 처음부터 다시 생각해야 한다"는 착각을 줄이는 것입니다. 물론 제품마다 내용은 다릅니다. 하지만 업무의 뼈대는 비슷한 경우가 많습니다.

예를 들어 제품명만 바뀌고, 입력 자료만 달라지고, 핵심 메시지만 조정되더라도 아래 항목은 거의 그대로 재사용할 수 있습니다.

• 프로젝트 폴더 구조

• 검증 단계 프롬프트

• 초안 작성 프롬프트

• 리뷰 체크리스트

• 파일명 규칙

이렇게 되면 브로슈어 제작은 더 이상 "그때그때 감으로 만드는 일"이 아니라 "정리된 생산 공정"에 가까워집니다.

나만의 업무 루틴은 주간 단위로 설계하면 가장 편하다

비개발자에게는 거대한 자동화 시스템보다 주간 업무 루틴이 훨씬 실용적입니다. 특히 개인 업무를 관리할 때는 일 단위보다 주 단위가 안정적입니다. 갑작스러운 요청이 들어와도 조정하기 쉽기 때문입니다.

예를 들어 이런 식으로 루틴을 만들 수 있습니다.

월요일에는 자료 수집과 입력 정리를 합니다. 파일을 지정된 폴더에 넣고 누락이 없는지 봅니다.

화요일에는 Codex로 초안 생성 작업을 돌립니다. 요약, 이미지 처리, 초안 문안 작성 같은 생산 단계가 여기에 들어갑니다.

수요일에는 검토와 수정 요청을 합니다. 체크리스트를 기준으로 결과를 다듬습니다.

목요일에는 최종본 정리와 파일명 정비를 합니다. 공유용 파일과 보관용 파일을 구분합니다.

금요일에는 아카이브와 템플릿 개선을 합니다. 이번 주에 자주 고친 부분이 있었다면 프롬프트나 체크리스트를 업데이트합니다.

이 루틴이 좋은 이유는, 단순히 일을 끝내기 때문만이 아닙니다. 같은 실수를 다음 주에 덜 하게 만들기 때문입니다.

많은 사람이 여기서 놓치는 포인트가 하나 있습니다. 업무 루틴은 '일정을 정하는 것'에서 끝나지 않습니다. 그 루틴 안에서 무엇을 개선할지까지 포함해야 시스템이 자랍니다.

템플릿은 쓸수록 고쳐야 한다

처음 만든 템플릿이 완벽할 필요는 없습니다. 오히려 처음부터 완벽하려고 하면 시작이 늦어집니다. 중요한 것은 한 번 만들고 끝내는 것이 아니라, 쓸수록 더 좋아지게 만드는 것입니다.

예를 들어 이런 상황을 만났다고 해봅시다.

브로슈어 초안은 매번 잘 나오는데, 항상 마지막에 문장이 너무 길어집니다. 그렇다면 다음부터는 초안 프롬프트에 "각 문단은 3문장 이하로 유지" 같은 조건을 추가하면 됩니다.

배경 제거 작업은 잘되는데, 결과 파일명이 종종 들쭉날쭉합니다. 그렇다면 파일명 규칙을 별도 문서로 적어 두고 프롬프트에도 넣으면 됩니다.

검토할 때마다 숫자 확인에 시간이 많이 든다면, 검증 단계에서 아예 verified_facts.md를 자동으로 만들게 하면 됩니다.

이렇게 해야 시스템이 성장합니다. 일을 할 때마다 사람만 지치는 것이 아니라, 템플릿도 같이 똑똑해져야 합니다.

자동화를 망치는 가장 흔한 실수는 예외를 시스템 밖에 두는 것이다

실무에서는 언제나 예외가 생깁니다. 이미지 해상도가 이상할 수도 있고, 스펙 자료가 늦게 도착할 수도 있고, 파일명이 엉망일 수도 있습니다. 여기서 많은 사람이 실수합니다. 예외가 생길 때마다 그냥 손으로 조용히 처리하고 끝내는 것입니다.

그렇게 하면 당장은 빠릅니다. 하지만 같은 예외가 다음 달에 또 생깁니다.

예외가 반복된다면, 그것은 더 이상 예외가 아닙니다. 시스템이 받아들여야 할 패턴입니다.

예를 들어 제품 이미지 중 일부는 배경 제거가 잘 안 된다면, 검토 체크리스트에 "반투명 소재, 유리, 반사면 이미지는 수동 확인" 항목을 넣을 수 있습니다.

브로슈어 작업에서 항상 추가 확인이 필요한 수치가 있다면, 검증 단계 템플릿에 "확인 전까지 본문 사용 금지" 항목을 굵게 넣을 수 있습니다.

즉, 시스템을 잘 키운다는 것은 성공한 방법만 모으는 일이 아니라, 반복되는 실패를 미리 흡수하는 일이기도 합니다.

버전 관리가 있어야 '좋아진 것'이 보인다

반복 가능한 시스템을 만들 때 버전 표기는 생각보다 중요합니다. 왜냐하면 시스템은 개선되어야 하는데, 개선되려면 이전 상태와 비교할 수 있어야 하기 때문입니다.

예를 들어 브로슈어 초안 파일이 늘 final.md 하나뿐이라면 문제가 생깁니다. 무엇이 어떻게 나아졌는지 알기 어렵습니다. 반면 draft_v1.md, draft_v2.md, draft_v3.md처럼 남기면 차이를 볼 수 있습니다.

프롬프트도 마찬가지입니다. 잘 먹히는 프롬프트가 생겼다면 instruction_template_v2.md처럼 관리해 둘 수 있습니다. 체크리스트도 review_checklist_v3.md처럼 바꿔 갈 수 있습니다.

이렇게 하면 좋은 점이 있습니다. 막연히 "요즘 좀 나아진 것 같은데?"가 아니라, 실제로 무엇을 바꿨고 결과가 어떻게 달라졌는지 추적할 수 있습니다.

자동화는 감각의 예술처럼 보일 때도 있지만, 오래 가는 시스템은 의외로 기록의 힘으로 굴러갑니다.

나만의 '업무 운영 체제'를 만든다고 생각하자

이쯤 오면 Codex는 단순한 도구가 아닙니다. 파일을 읽고, 정리하고, 초안을 만들고, 검토를 도와주는 작업 파트너가 됩니다. 그런데 진짜 변화는 Codex 자체보다, 그것을 둘러싼 내 업무 운영 체제를 만들었을 때 생깁니다.

업무 운영 체제라고 해서 거창한 것을 뜻하는 것은 아닙니다. 아주 간단하게 말하면 이것입니다.

어떤 일이 들어오면 어디에 넣고, 어떤 순서로 처리하고, 어떤 기준으로 검토하고, 어디에 보관하는지가 정해져 있는 상태.

이 상태가 되면 머리가 훨씬 가벼워집니다. "어떻게 하지?"보다 "정해진 흐름으로 시작하자"가 먼저 떠오르기 때문입니다.

그리고 놀랍게도, 바로 이때 창의성이 더 잘 나옵니다. 기본 구조를 고민하느라 에너지를 쓰지 않아도 되기 때문입니다. 브로슈어의 핵심 메시지를 더 잘 다듬거나, 이미지 활용 방식을 더 세련되게 바꾸는 데 집중할 수 있습니다.

즉, 시스템은 창의성을 막는 틀이 아니라, 창의성이 쓸데없는 반복 작업에 잡아먹히지 않게 해주는 틀입니다.

이번 주부터 바로 적용할 수 있는 가장 쉬운 시작법

너무 크게 시작할 필요는 없습니다. 이번 주에 바로 할 수 있는 가장 좋은 시작은 딱 세 가지입니다.

첫째, 자주 하는 업무 하나를 고릅니다. 이미지 정리든, 회의 요약이든, 브로슈어 초안이든 상관없습니다.

둘째, 그 업무의 폴더 구조를 고정합니다. 원본, 처리중, 최종본, 검토 메모 폴더만 있어도 충분합니다.

셋째, 프롬프트 템플릿 하나와 검토 체크리스트 하나를 파일로 만듭니다.

이 세 가지만 해도 다음번 작업은 훨씬 빨라집니다. 중요한 것은 거대한 자동화가 아니라, 다음에도 같은 방식으로 시작할 수 있는가입니다.

이 장에서 꼭 가져가야 할 한 가지 관점

이번 장의 메시지는 분명합니다.

좋은 자동화는 한 번의 멋진 결과가 아니라, 같은 품질의 결과를 다시 만들 수 있는 구조에서 나온다.

비개발자가 Codex를 업무에 제대로 쓰기 시작하는 지점도 바로 여기입니다. 대화 한 번 잘하는 사람에서 끝나지 않고, 업무를 템플릿화하고, 검토 기준을 고정하고, 반복 가능한 루틴으로 바꾸는 사람으로 넘어가는 순간입니다.

이제 Codex는 단순히 "잘 대답하는 AI"가 아닙니다. 내 업무 폴더 안에서, 내 기준에 맞춰, 반복 가능한 방식으로 함께 일하는 실무 도구가 됩니다.

다음 장에서는 이 흐름을 한 단계 더 확장해 보겠습니다. Codex를 단발성 작업 도구가 아니라, 일상적인 디지털 실무 파트너로 쓰는 방법을 살펴볼 차례입니다.