17줄짜리 요청서가 하루를 되돌려줬다
지난주 저는 작은 업무 자동화를 만들다가 같은 말을 네 번 반복했습니다. “이 표에서 날짜를 읽고, 중복을 지우고, 오늘 처리할 것만 남겨줘.” 말은 쉬운데 결과는 매번 조금씩 달랐습니다.
문제는 AI가 게을러서가 아니었습니다. 제가 일을 너무 흐리게 맡겼습니다.
제가 보기엔, 비개발자에게 필요한 AI 개발 감각은 코딩 실력보다 “일을 명세로 쪼개는 능력”에 더 가깝습니다. 이 주장에는 반대가 있을 수 있습니다. 그래도 저는 이쪽에 베팅하겠습니다.
지시문를 잘 쓰면 된다는 말은 절반만 맞다
요즘 많은 사람이 “지시문를 잘 써야 한다”고 말합니다. 틀린 말은 아닙니다. 다만 이 말만 들으면, 지시문를 문장력 문제로 착각하기 쉽습니다.
실제로는 문장력이 아니라 업무 지시력에 가깝습니다. 신입에게 일을 맡길 때 “깔끔하게 정리해줘”라고만 말하면 결과가 흔들립니다. 기준, 예외, 완료 조건을 줘야 합니다. AI에게도 같습니다.
저도 처음에는 Claude Code나 자동화 도구에 한 문장씩 던졌습니다. “이 기능 만들어줘.” “오류 고쳐줘.” “좀 더 보기 좋게 해줘.” 그렇게 하면 처음 10분은 빨라 보입니다. 그런데 40분 뒤에는 다시 설명하고, 다시 고치고, 어디서 망가졌는지 찾느라 시간을 씁니다.
그래서 “Get Shit Done”류의 가벼운 메타 지시문·명세 기반 개발 시스템이 흥미로운 겁니다. 거창한 개발 방법론이 아니라, 일을 시작하기 전에 작은 명세를 먼저 세우게 만드는 장치이기 때문입니다.
신입에게 일 주듯 AI에게 일 주는 사람이 결과를 가져간다
이번 주제의 출처 목록은 비어 있습니다. 그래서 특정 프로젝트의 공식 수치나 공개 저장소를 근거로 단정할 수는 없습니다. 여기서는 제목과 설명에 나온 범위, 즉 Claude Code 같은 코딩 에이전트에서 명세 기반 개발을 자동화하는 경량 시스템이라는 정보에 기대어 읽겠습니다.
핵심은 간단합니다. AI에게 “만들어줘”라고 말하기 전에, AI가 따라야 할 작업 문서를 먼저 만들게 하거나 사람이 직접 짧게 고정하는 방식입니다. 보통은 이런 식입니다.
| 흐린 요청 | 명세 기반 요청 |
|---|---|
| 고객 메모 정리 기능 만들어줘 | 입력은 CSV, 출력은 오늘 처리할 고객 20명 이하, 중복 전화번호 제거, 이름 없는 행은 제외 |
| 오류 안 나게 해줘 | 실패 조건 3개를 먼저 재현하고, 수정 뒤 같은 조건에서 통과 여부를 보여줘 |
| 보기 좋게 바꿔줘 | 모바일 390px 기준에서 버튼 2개가 한 줄에 겹치지 않게 하고, 색은 기존 팔레트만 써줘 |
| 자동화해줘 | 매일 오전 9시에 실행, 실패 시 로그 저장, 성공 시 결과 파일명에 날짜 포함 |
차이는 문장의 길이가 아닙니다. 완료 기준이 있느냐 없느냐입니다.
제가 직접 겪은 실패도 비슷했습니다. 엑셀에서 반복하던 분류 작업을 AI에게 맡기려 했는데, 처음에는 “카테고리별로 나눠줘”라고만 했습니다. 결과가 그럴듯해서 바로 쓸 뻔했지만, 83개 행 중 11개가 애매한 기준으로 섞여 있었습니다. 특히 “문의”와 “불만” 사이가 흔들렸습니다.
그다음에는 요청을 이렇게 바꿨습니다.
> 복붙용: “먼저 분류 기준을 5개 이하로 제안하고, 각 기준에 들어가지 않는 예외 3개를 따로 보여줘. 내가 승인하기 전에는 실제 분류를 시작하지 마.”
이 한 줄을 넣자 일이 바뀌었습니다. AI가 바로 결과물을 만들지 않고, 기준부터 제안했습니다. 저는 그 기준을 고쳤고, 그다음에야 실제 분류를 맡겼습니다. 속도는 처음보다 느려 보였지만 전체 시간은 줄었습니다. 다시 검토하는 시간이 줄었기 때문입니다.
명세 기반 개발이라는 말이 개발자 전용처럼 들릴 수 있습니다. 하지만 저는 오히려 비개발자에게 더 필요하다고 봅니다. 개발자는 코드를 읽고 이상한 부분을 추적할 수 있습니다. 비개발자는 결과물이 틀렸을 때 어디서 틀렸는지 찾기가 더 어렵습니다. 그래서 시작 전에 기준을 고정해야 합니다.
Get Shit Done이라는 이름은 거칠지만, 방향은 실용적입니다. 복잡한 작업 흐름를 세우는 대신 “요구사항 → 작업 목록 → 검증 조건”을 짧게 반복하게 만드는 방식이라면, 비개발자도 쓸 수 있습니다. 중요한 건 도구 이름이 아닙니다. 매번 즉흥 대화를 하지 않고, 작은 시스템을 남기는 습관입니다.
저는 이걸 “AI에게 일을 잘 시키는 최소 문서”라고 부릅니다. 문서는 길 필요가 없습니다. 오히려 길면 안 씁니다. 제가 지금 쓰는 최소 틀은 6줄입니다.
① 목표: 무엇을 끝내야 하나 ② 입력: 어떤 자료를 줄 것인가 ③ 출력: 어떤 모양으로 받아야 하나 ④ 제외: 하지 말아야 할 것은 무엇인가 ⑤ 검증: 맞았는지 어떻게 확인하나 ⑥ 중단: 애매하면 언제 멈추고 물어봐야 하나
여기서 특히 중요한 건 ④와 ⑥입니다. 사람들은 목표와 출력은 잘 씁니다. 하지만 하지 말아야 할 일과 멈춰야 할 조건은 잘 안 씁니다. AI는 빈칸을 채우려는 쪽으로 움직입니다. 그 빈칸이 업무에서는 위험이 됩니다.
예를 들어 고객 데이터 정리를 맡길 때 “빈 값은 추정하지 말고 빈 값으로 남겨라”라고 쓰지 않으면, AI가 그럴듯한 값을 채울 수 있습니다. 회의록 요약을 맡길 때 “결정되지 않은 일을 결정된 것처럼 쓰지 말라”고 하지 않으면, 말투만 단정한 가짜 결론이 생깁니다.
작은 명세는 자유를 줄입니다. 대신 다시 일할 시간을 줄여줍니다. 자동화가 시간을 되찾는 도구라면, 명세는 그 시간을 새지 않게 막는 뚜껑입니다.
모든 일을 명세로 만들 수는 없다
이 방식이 안 통하는 일도 있습니다. 아이디어를 넓게 찾는 단계, 감각적인 문체를 실험하는 단계, 아직 무엇을 원하는지 모르는 단계에서는 명세가 너무 빨리 굳어질 수 있습니다.
저도 글 제목을 뽑을 때 처음부터 조건을 촘촘히 걸면 결과가 뻣뻣해질 때가 많았습니다. 그럴 때는 일부러 느슨하게 던집니다. “직장인이 저장하고 싶을 만한 제목 20개”처럼 넓게 받고, 그다음에 기준을 좁힙니다.
또 하나의 한계가 있습니다. 명세를 만든다고 해서 AI 결과가 자동으로 맞아지는 건 아닙니다. 검증을 안 하면 명세는 장식입니다. 특히 돈, 법률, 의료, 고객 정보처럼 틀리면 손실이 나는 영역에서는 사람이 마지막 책임을 가져야 합니다.
그래서 저는 “명세 기반이면 믿어도 된다”가 아니라 “명세 기반이면 틀린 지점을 찾기 쉬워진다” 정도로 봅니다. 이 차이를 놓치면, 좋은 습관이 또 다른 자동화 착각으로 바뀝니다.
오늘 만들 것은 거창한 자동화가 아니라 6줄짜리 작업 지시서다
오늘 바로 할 일은 하나면 충분합니다. 자주 반복하는 업무 하나를 고르고, 위의 6줄 틀로 작업 지시서를 써보세요. 메일 분류, 회의록 정리, 엑셀 정리, 블로그 초안, 고객 문의 요약 중 하나면 됩니다.
처음부터 시스템을 크게 만들 필요는 없습니다. 작은 명세 하나가 남으면 다음번에 복사해서 고칠 수 있습니다. 그게 비개발자가 AI를 삶과 일에 붙이는 현실적인 방식입니다.
저는 앞으로의 업무 격차가 “AI를 쓰느냐 안 쓰느냐”보다 “AI에게 맡긴 일을 다시 쓸 수 있는 형태로 남기느냐”에서 갈린다고 봅니다.
다음 편에서는 이 6줄 작업 지시서를 실제로 “반복 가능한 개인 업무 자동화 템플릿”으로 바꾸는 방법을 다루겠습니다. 다음 글을 이어서 보려면 Noleji.ai 아카이브에서 AI 업무 자동화 편을 따라오시면 됩니다.
핵심 정리
- 지난주 저는 작은 업무 자동화를 만들다가 같은 말을 네 번 반복했습니다.
- 문제는 AI가 게을러서가 아니었습니다.
- 제가 보기엔, 비개발자에게 필요한 AI 개발 감각은 코딩 실력보다 “일을 명세로 쪼개는 능력”에 더 가깝습니다.
→ 영어판 보기