작게 만들어 크게 배우기: 간단한 프로그램을 직접 만들고 테스트시키는 경험

작은 프로그램 하나가 태도를 바꾼다

Codex를 처음 쓸 때는 보통 이렇게 시작합니다. 문장을 다듬어 달라고 하고, 표를 정리해 달라고 하고, 파일을 읽어 달라고 합니다. 이 단계만으로도 이미 꽤 강력합니다. 하지만 여기서 한 걸음 더 나가면 완전히 다른 세계가 열립니다. 내가 직접 쓰는 작은 도구를 하나 만들어 보는 것입니다.

많은 비개발자는 "프로그램 만들기"라는 말을 듣는 순간 어깨에 힘이 들어갑니다. 뭔가 거대한 화면, 복잡한 명령어, 까만 창, 알 수 없는 오류가 떠오르기 때문입니다. 그런데 실제로는 그렇지 않습니다. 작은 프로그램은 거창한 서비스가 아닙니다. 반복되는 일을 한 번 정리해서, 나중에 다시 똑같이 쓰기 쉽게 만든 저장된 작업 방식에 가깝습니다.

예를 들어 이런 것들도 모두 작은 프로그램입니다.

• 폴더 안의 텍스트 파일을 읽어 불필요한 빈 줄을 정리하는 스크립트

• 여러 파일의 이름을 규칙에 맞게 바꾸는 도구

• CSV 파일을 합쳐서 하나의 보고서로 저장하는 간단한 유틸리티

• 이미지 목록을 읽고 파일명과 크기를 표로 정리하는 보조 스크립트

이 장의 핵심은 코딩 실력을 자랑하는 데 있지 않습니다. Codex와 함께 만들고, 실행하고, 틀리면 고치고, 다시 돌려보는 경험을 해보는 데 있습니다. 이 경험을 한 번 해두면, 이후에는 AI를 단순히 "질문에 답하는 도구"가 아니라 "작업 구조를 같이 만드는 파트너"로 보게 됩니다.

프로그램을 무섭게 보지 말고, 저장된 프롬프트로 보자

비개발자에게 가장 쉬운 비유는 이것입니다. 프로그램은 종종 저장된 프롬프트와 비슷합니다. 차이가 있다면, 매번 같은 작업을 더 안정적으로 반복할 수 있고, 파일을 직접 읽고 쓰며, 버튼 한 번이나 명령 한 번으로 다시 실행할 수 있다는 점입니다.

그동안은 이런 식으로 했을 수 있습니다.

"이 폴더의 txt 파일들 정리해줘."

다음 날에도 또 말합니다.

"어제처럼 다시 정리해줘."

그리고 일주일 뒤에는 말이 조금 바뀝니다.

"아, 이번에는 원본은 건드리지 말고 output 폴더에만 저장해줘."

이렇게 되면 같은 일을 반복할 때마다 설명이 흔들립니다. 반면 작은 프로그램을 만들어 두면 기준이 고정됩니다. 입력 폴더가 어디인지, 무엇을 바꾸는지, 결과를 어디에 저장하는지가 분명해집니다. 바로 이 지점에서 업무 자동화가 시작됩니다.

Codex는 프로젝트 폴더를 읽고, 파일을 수정하고, 필요한 명령을 실행하며 작업을 도와주는 코딩 에이전트입니다.¹² 비개발자에게 중요한 것은 "코드를 전부 이해해야 한다"가 아니라, 원하는 작업을 작은 단위로 분명하게 말할 수 있으면 된다는 점입니다.

첫 실습은 텍스트 정리 도구가 좋다

처음 만드는 프로그램으로는 너무 야심찬 것을 고르지 않는 편이 좋습니다. 로그인 기능이 있는 웹서비스나, 외부 사이트와 연결되는 복잡한 자동화는 지금 단계에선 과합니다. 대신 입력과 출력이 눈에 보이고, 원본을 망가뜨릴 위험이 낮은 도구가 좋습니다.

가장 추천하기 쉬운 첫 실습은 이런 종류입니다.

input 폴더의 .txt 파일을 읽어서 불필요한 공백과 빈 줄을 정리하고 결과를 output 폴더에 새 파일로 저장하는 도구

왜 이 예제가 좋을까요? 이유는 간단합니다. 파일이 눈에 보이고, 결과가 바로 비교되며, 잘못되어도 원본만 안 건드리면 부담이 적기 때문입니다. 게다가 나중에 이미지 정리, 브로슈어 자료 수집, 보고서 초안 만들기 같은 더 큰 자동화로 갈 때도 기본 구조가 비슷합니다.

입력 파일이 있고, 규칙이 있고, 결과 파일이 생깁니다.

사실 자동화의 뼈대는 늘 이 세 가지입니다.

작업 폴더는 작고 분명하게 만든다

처음부터 기존 업무 폴더를 바로 열지 않아도 됩니다. 오히려 작은 연습 폴더를 따로 만드는 편이 훨씬 좋습니다. 예를 들면 이런 구조입니다.

• mini-text-cleaner/

• mini-text-cleaner/input/

• mini-text-cleaner/output/

• mini-text-cleaner/README.md

그리고 input 폴더 안에 테스트용 텍스트 파일 두세 개를 넣어 둡니다. 일부러 지저분하게 만들어도 좋습니다. 앞뒤 공백이 들어간 줄, 빈 줄이 너무 많은 문장, 들쭉날쭉한 줄바꿈 같은 것들 말입니다.

Codex는 현재 열어 둔 프로젝트 폴더를 기준으로 맥락을 잡기 때문에, 작업 폴더가 분명할수록 결과도 안정적입니다.² 너무 넓은 폴더를 열어 두면 Codex도 "지금 뭘 기준으로 봐야 하지?" 하고 잠깐 헷갈리기 쉽습니다. 사람도 서랍 전체를 뒤지기보다 작은 박스 하나를 받는 편이 편하듯이 말입니다.

첫 지시는 작고 구체적으로 준다

Codex에게 처음부터 "텍스트 정리 프로그램 하나 만들어줘"라고만 말하면, 잘하는 날도 있지만 방향이 넓게 퍼질 수 있습니다. 작은 프로그램을 만들 때는 무엇을 입력받고, 무엇을 바꾸고, 어디에 저장하고, 무엇을 절대 하지 말아야 하는지를 함께 적는 편이 좋습니다.³

예를 들어 첫 지시는 이렇게 줄 수 있습니다.

이 폴더에 초보자용 Python 스크립트를 만들어줘. input 폴더 안의 .txt 파일만 읽어서 각 줄의 앞뒤 공백을 정리하고, 연속된 빈 줄은 한 줄만 남기고, 결과는 같은 파일명으로 output 폴더에 저장해줘. 원본 파일은 절대 수정하지 말아줘. 코드에는 어려운 문법을 피하고, 내가 읽을 수 있게 주석을 조금만 달아줘. 실행 방법은 README.md에도 적어줘.

이 프롬프트가 좋은 이유는 욕심이 적기 때문입니다. AI에게 "똑똑하게 다 알아서"를 기대하는 대신, 작업 범위를 좁게 잘라 주고 안전장치까지 같이 준 것입니다.

이때 핵심은 세 가지입니다.

• 입력 범위: input 폴더의 .txt 파일만

• 처리 규칙: 공백 정리, 빈 줄 줄이기

• 안전 규칙: 원본 수정 금지, output에만 저장

이 정도만 분명해도 첫 결과의 품질이 꽤 올라갑니다.

코드가 아니라 결과를 먼저 본다

Codex가 파일을 만들어 주면, 많은 사람이 곧장 코드부터 읽으려 합니다. 물론 읽을 수 있으면 좋습니다. 하지만 첫 실습에서는 코드보다 결과 구조를 먼저 보는 편이 훨씬 쉽습니다.

예를 들면 이런 질문을 하면 됩니다.

"어떤 파일을 만들었지?"

"실행은 무엇을 누르거나 입력하면 되지?"

"원본을 안 건드린다는 보장은 어디에 있지?"

"결과는 어느 폴더에 생기지?"

이 질문에 답할 수 있으면, 이미 절반은 이해한 것입니다. 비개발자에게 처음 필요한 것은 문법 지식보다 흐름 이해입니다.

Codex에게도 이렇게 되물으면 좋습니다.

방금 만든 파일들의 역할을 초보자 눈높이로 설명해줘. 특히 어떤 파일이 실제 실행 파일인지, 어떤 파일이 설명서인지 구분해서 말해줘.

이렇게 하면 코드를 전부 읽지 않아도 구조가 잡힙니다.

실행은 떨려도, 바로 해보는 편이 낫다

작은 프로그램을 만드는 경험에서 가장 중요한 순간은 사실 "생성"이 아니라 "실행"입니다. 직접 돌려봐야 비로소 내 도구가 됩니다.

Codex는 파일을 만들고, 필요하면 명령을 실행하고, 에러를 읽고, 다시 수정하는 흐름에 강합니다.¹² 그래서 처음 실행에서 문제가 생겨도 이상한 일이 아닙니다. 오히려 아주 정상입니다. AI와 함께 도구를 만드는 과정은 종종 만들기 → 실행 → 실패 → 수정 → 재실행의 반복으로 진행됩니다.

예를 들어 첫 실행에서 이런 일이 벌어질 수 있습니다.

• output 폴더가 없어서 저장 실패

• .txt가 아닌 파일까지 읽으려다 오류 발생

• 한글 인코딩 문제로 일부 파일이 깨짐

• 빈 줄을 너무 많이 지워서 문단이 답답해짐

이 순간에 "역시 나는 안 돼"라고 결론 내리면 아깝습니다. 이때 필요한 반응은 좌절이 아니라 보고입니다.

실행해보니 output 폴더가 없을 때 에러가 나. 폴더가 없으면 자동으로 만들게 고쳐줘.

결과를 보니 빈 줄을 너무 공격적으로 지웠어. 문단 구분용 빈 줄은 한 줄 남겨줘.

한글 파일에서도 잘 동작하는지 다시 확인해줘.

이런 식으로 짧고 정확하게 수정 요청을 주면 됩니다. 작은 프로그램을 배우는 진짜 포인트는 처음부터 완벽하게 만드는 것이 아니라, 어디가 어색한지 말하고 다듬는 법을 익히는 것입니다.

테스트는 거창한 검사가 아니라, 예상과 비교하는 습관이다

"테스트"라는 단어도 비개발자에게는 조금 위압적으로 들립니다. 하지만 실무에서 필요한 테스트의 핵심은 단순합니다. 내가 예상한 결과와 실제 결과를 비교하는 것입니다.

이를테면 input/sample1.txt가 아래처럼 생겼다고 해봅시다.

회의 제목    


오늘 논의할 안건은 세 가지입니다.    

- 일정 조정
- 브로슈어 수정

이 파일을 정리한 뒤에는 대략 이런 결과를 기대할 수 있습니다.

회의 제목

오늘 논의할 안건은 세 가지입니다.

- 일정 조정
- 브로슈어 수정

이 비교만으로도 테스트가 됩니다. 거대한 테스트 도구가 없어도 괜찮습니다. 처음에는 눈으로 확인해도 충분합니다.

그리고 테스트용 파일은 일부러 다양하게 넣는 편이 좋습니다.

• 빈 파일 하나

• 한 줄만 있는 파일 하나

• 한글과 영문이 섞인 파일 하나

• 공백이 심한 파일 하나

이런 작은 사례를 먼저 통과시키면, 나중에 실제 업무 폴더에 적용할 때 훨씬 덜 떨립니다.

잘 안 풀릴 때는 요구사항을 더 작게 쪼갠다

초보자가 Codex를 쓰며 가장 많이 하는 실수 중 하나는, 한 번에 너무 많은 기능을 얹는 것입니다.

예를 들어 이런 식입니다.

"텍스트 파일 정리도 하고, 제목도 뽑고, 요약도 만들고, 태그도 달고, 날짜도 추출하고, CSV로도 저장해줘."

물론 Codex는 꽤 많은 일을 해낼 수 있습니다. 하지만 처음 경험에서는 이 방식이 실패 확률을 높입니다. 작은 프로그램을 만들 때는 기능을 덩어리로 올리지 말고 계단처럼 올리는 편이 좋습니다.

먼저 1단계에서는 텍스트 정리만 합니다.

그다음 2단계에서는 처리한 파일 수를 세어 summary.md를 만듭니다.

그다음 3단계에서는 파일별 글자 수를 같이 적습니다.

이렇게 한 층씩 올리면, 어디서 틀어졌는지도 훨씬 쉽게 파악할 수 있습니다. 작은 성공을 여러 번 쌓는 방식이 결국 더 빠릅니다.

Codex를 덜 헤매게 하는 한 장의 메모, AGENTS.md

작은 도구를 한 번 만들고 끝내지 않고, 계속 수정하며 키워갈 생각이라면 프로젝트 루트에 간단한 AGENTS.md를 두는 것도 좋습니다. Codex는 이런 파일을 통해 프로젝트의 공통 지침을 읽고, 세션이 바뀌어도 같은 원칙을 유지하는 데 도움을 받을 수 있습니다.⁴

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

# 작업 원칙

- input 폴더의 원본 파일은 절대 수정하지 않는다.
- 모든 결과 파일은 output 폴더에만 저장한다.
- 가능하면 Python 표준 라이브러리만 사용한다.
- README.md에 실행 방법을 한국어로 유지한다.
- 코드가 바뀌면 무엇이 달라졌는지 짧게 설명한다.

이 파일은 일종의 작업장 벽에 붙여 둔 메모와 같습니다. 사람이 바뀌어도, 대화가 길어져도, 기본 규칙을 다시 상기시켜 줍니다. 특히 비개발자에게는 "내가 매번 같은 말을 반복하지 않아도 된다"는 점에서 꽤 유용합니다.

직접 만들어 보면 생기는 감각이 있다

작은 프로그램을 한 번 직접 만들어 보면, 머리로만 알 때와 전혀 다른 감각이 생깁니다.

첫째, AI에게 일을 맡길 때 좋은 지시는 작고 구체적이어야 한다는 것을 몸으로 알게 됩니다.³

둘째, 오류는 실패가 아니라 다음 지시를 더 정확하게 만드는 재료라는 것을 알게 됩니다.

셋째, 파일을 읽고 쓰는 흐름이 잡히면 "아, 이건 내 다른 업무에도 붙일 수 있겠다"는 생각이 자연스럽게 듭니다.

이 감각은 꽤 중요합니다. 왜냐하면 이후의 자동화는 대부분 여기서 출발하기 때문입니다. 이미지 배경을 정리하는 작업도, 브로슈어 자료를 수집하는 흐름도, 결국은 작은 규칙의 조합입니다. 처음부터 큰 사례로 들어가면 마법처럼 보이지만, 작은 프로그램을 먼저 만들어 보면 구조가 보입니다.

비개발자가 기억하면 좋은 실전 습관

작은 도구를 Codex와 함께 만들 때는 몇 가지 습관만 기억해도 훨씬 안정적입니다.

• 처음에는 원본을 건드리지 않는 방향으로 만든다.

• 입력 폴더와 출력 폴더를 분리한다.

• 기능은 한 번에 하나씩만 추가한다.

• 실행 후에는 결과 파일을 꼭 직접 열어 본다.

• 막히면 "왜 안 돼?"보다 "어디까지는 됐고, 어디서 틀렸어"라고 말한다.

이 다섯 가지만 지켜도, AI와 함께 만드는 흐름이 훨씬 덜 무섭습니다.

작은 도구를 만들 수 있으면, 이제 사용자에서 확장자로 넘어간다

Codex를 쓰는 사람은 크게 두 단계로 나뉩니다. 첫 번째는 잘 써주는 답을 받는 사용자입니다. 두 번째는 자기 업무에 맞는 흐름을 조금씩 확장해 가는 사용자입니다.

이 장의 목표는 두 번째 단계로 넘어가는 것입니다.

직접 작은 프로그램을 하나 만들어 보면, 이제 더 이상 "무엇을 물어볼까"만 고민하지 않게 됩니다. 대신 "이 일을 어떤 입력과 규칙으로 나눌까", "결과를 어떤 파일로 남길까", "수정은 어떻게 반복할까"를 생각하게 됩니다. 이 사고방식의 변화가 자동화의 진짜 시작입니다.

작은 도구 하나는 별것 아닌 것처럼 보일 수 있습니다. 하지만 그 경험은 큽니다. 한 번 해보면 알게 됩니다. AI는 완성품을 내려주는 마술사가 아니라, 함께 만들면서 점점 쓸모 있게 다듬어 가는 작업 파트너라는 사실을 말입니다.

다음 장들에서 다룰 더 실전적인 사례들도 결국 같은 원리 위에 서 있습니다. 폴더를 정하고, 파일을 읽고, 규칙을 주고, 결과를 확인하고, 필요하면 다시 수정합니다. 지금 이 작은 경험이, 뒤의 큰 자동화를 버티는 가장 좋은 발판이 됩니다.

참고

¹GitHub - openai/codex: Lightweight coding agent that runs in your terminal

²App - Codex app | OpenAI Developers

³Prompting - Codex | OpenAI Developers

⁴Custom instructions with AGENTS.md - Codex | OpenAI Developers