AI 에이전트에게 '알아서 만들어줘'가 안 통하는 이유 — 구축 설계 스킬을 만들며 배운 4가지

AI에게 복잡한 일을 시킬 때, 프롬프트를 길게 쓰는 것보다 중요한 건 순서와 방어장치입니다.

이 글 3줄 요약

• AI에게 "알아서 만들어줘"라고 던지면 십중팔구 산으로 갑니다. 문제는 AI가 아니라 일을 시키는 방식입니다.
• 저는 클라이언트 구축 설계서를 한 번에 뽑는 스킬을 직접 만들었고, 그 과정에서 4가지 원칙을 얻었습니다.
• 질문을 3갈래로 쪼개고, 문서를 순서대로 쌓고, 안 하는 것도 이유를 남기고, 완성형만 받는다.

왜 이걸 만들었나

저는 외식 사장님들께 맞춤 시스템(발주 자동화, 급여 정산, 매출 대시보드 같은)을 만들어 드립니다. 의뢰를 받을 때마다 매번 설계 문서를 처음부터 새로 썼는데, 이게 반복 작업이었습니다.

한 번의 의뢰를 실제로 만들 수 있는 형태로 바꾸려면 문서가 한 장으로 끝나지 않습니다. 무엇을 만들지 정하는 기획서, 데이터를 어떻게 담을지 정하는 데이터 구조, 그 위에 돌아갈 로직과 화면, 그리고 "이게 1년 뒤에도 안 터지게" 붙잡아 줄 안전장치와 검증 계획, 마지막으로 사장님이 넘겨받아 굴릴 운영 인수 문서까지 — 이 묶음이 한 세트로 앞뒤가 맞아야 비로소 제작에 들어갈 수 있습니다. 이걸 의뢰가 들어올 때마다 매번 맨손으로 다시 쌓는 게 제 발목을 잡고 있었습니다.

그래서 "의뢰 한 줄 → 바로 제작에 들어갈 수 있는 설계서 세트" 를 뽑아주는 AI 스킬을 직접 만들었습니다. 처음엔 "프롬프트를 정교하게 쓰면 좋은 문서가 나오겠지"라고 생각했습니다. 그런데 아니었습니다. 프롬프트를 아무리 화려하게, 길게 써도 결과물은 여전히 산으로 갔습니다. 진짜 차이를 만든 건 문장이 아니라 일을 어떻게 쪼개서 시키느냐, 그 구조였습니다. 어떤 순서로 시키고, 무엇을 못 하게 막고, 어디서 사람에게 결정을 넘기는지 — 이 뼈대가 결과물의 질을 거의 다 결정했습니다. 아래 4가지가 그 핵심입니다.

원칙 1 — 질문을 3갈래로 쪼갠다

AI에게 다 물어봐도, 다 맡겨도 실패합니다. 다 물으면 사장님을 붙잡고 스무고개를 하게 됩니다. 회의가 끝나지 않고, 정작 중요한 결정은 질문 더미에 묻혀 흐려집니다. 반대로 다 맡기면 AI가 자기 편한 대로 가정을 세워 엉뚱한 방향으로 산을 넘어가 버립니다. 다 짓고 나서야 "어? 이거 우리 매장이랑 안 맞는데"가 나옵니다. 그래서 저는 결정권을 한 덩어리로 두지 않고 3층으로 나눴습니다.

맨 윗줄부터 봅시다. 매장이 몇 개인지, 급여는 시급인지 월급인지, 마감을 언제 어떻게 도는지는 아무리 똑똑한 AI라도 알 방법이 없습니다. 사장님 머릿속에만 있는 사실이니까요. 이건 무조건 물어야 합니다. 다만 8개 이내로 제한한 이유가 있습니다. 사장님은 새벽에 나오고 늦게 마감합니다. 질문이 한없이 늘어나면 그 순간 상담은 숙제가 되고, 답이 부실해집니다. 정말 물어야만 하는 것만 골라 8개 안에 담으면, 짧은 인터뷰 한 번으로 필요한 사실을 다 건집니다.

핵심은 가운데 줄입니다. DB를 어떻게 짤지, 어디에 배포할지, 어떤 기술을 쓸지 같은 건 사장님이 굳이 알 필요 없는 영역입니다. 그런데 이걸 사람에게 일일이 물으면 결정이 느려지고, 그렇다고 대충 맡기면 방향이 틀어집니다. 그래서 "내가 정했다, 이유는 이거다, 아니면 말해달라" 로 처리합니다. AI가 먼저 정하고 근거까지 붙여 오면, 사장님은 그 결정을 처음부터 고민할 필요 없이 승인 아니면 거부, 둘 중 하나만 하면 됩니다. 결정을 0에서 만드는 것보다 남이 만들어 온 결정에 O/X를 치는 게 압도적으로 빠릅니다. 속도와 정확도를 동시에 잡는 지점이 바로 여깁니다.

맨 아랫줄은 태도의 문제입니다. "월 몇 건 처리하나요?" 같은 사소한 수치까지 다 물으면 앞의 8개 예산을 낭비합니다. 이런 건 그냥 상식적인 값으로 가정하고, 가정이라고 표시해 둡니다. 틀리면 나중에 숫자 하나 고치면 그만이니까요. 중요한 건 빈칸으로 비워두지 않는다는 것 — 이건 원칙 4로 이어집니다.

Before: 질문을 잔뜩 던지고 → 사장님 지쳐서 답 부실 → 부실한 답 위에 설계 → 다시 물어봄. After: 진짜 사람만 아는 것 8개만 묻고 → 나머지는 AI가 정하거나 가정 → 사장님은 O/X와 숫자 정정만.

원칙 2 — 문서를 순서대로 쌓는다 (병렬 금지)

AI에게 문서 여러 개를 한꺼번에 뽑으라고 하면 빠릅니다. 몇 초 만에 기획서도 나오고 화면 설계도 나옵니다. 그런데 서로 안 맞습니다. 데이터 구조를 정하지 않은 채 백엔드 로직을 짜면, 나중에 둘이 어긋나 처음부터 다시 만들어야 합니다. 화면부터 그려버리면 정작 데이터에는 없는 항목을 화면이 요구하는 모순이 생깁니다. 각자 따로 태어난 문서들이라, 붙여 놓으면 이가 안 맞는 거죠.

그래서 순서를 고정했습니다. 기획서 → 데이터 구조 → 백엔드 → 화면. 집을 짓는 순서와 똑같습니다. 기초 없이 벽을 세우지 않고, 뼈대 없이 인테리어를 하지 않습니다. 기초 → 뼈대 → 인테리어. 데이터 구조가 기초라면, 그 위에 로직이라는 뼈대가 서고, 마지막에 화면이라는 인테리어가 올라갑니다. 순서를 건너뛰면 반드시 어딘가가 무너집니다.

핵심 규칙 하나가 이 순서를 진짜로 작동하게 만듭니다: 각 단계는 앞 단계 문서를 반드시 읽고 시작합니다. 백엔드를 짜는 단계는 먼저 데이터 구조 문서를 읽고, 거기 정의된 항목 안에서만 로직을 만듭니다. 화면을 그리는 단계는 백엔드 문서를 읽고, 실제로 존재하는 기능만 화면에 겁니다. 즉 앞 문서가 뒤 문서의 제약이 되게 강제한 겁니다. 뒤 단계가 앞 단계를 무시하고 제멋대로 갈 수 없게 사슬로 묶은 거죠.

이러면 속도는 조금 느려집니다. 한꺼번에 뽑는 것보다 단계를 밟아야 하니까요. 하지만 서로 안 맞아서 통째로 뜯어고치는 일이 사라집니다. 뒤늦게 "이 화면이 요구하는 데이터가 애초에 설계에 없었네"를 발견하고 처음으로 돌아가는 것보다, 처음부터 앞뒤를 맞춰 쌓는 게 훨씬 쌉니다. 빨리 뽑는 것보다 앞뒤가 맞는 게 훨씬 쌉니다. 다시 만드는 비용이 세상에서 제일 비싼 비용이거든요.

Before: 기획·데이터·백엔드·화면을 동시에 생성 → 4장이 서로 다른 전제 위에 있음 → 조립 단계에서 충돌 → 재작업. After: 앞 문서를 제약으로 물려 순서대로 쌓기 → 조립 단계에서 충돌 0 → 한 번에 제작 착수.

원칙 3 — "안 만드는 것"도 이유를 쓰게 한다

이게 4가지 중 가장 중요합니다. AI의 가장 위험한 습성은 안 한 걸 조용히 넘긴다는 겁니다. 백업 장치를 안 넣었으면, 문서에 "백업 없음"이라고 쓰는 게 아니라 그냥 백업 얘기가 통째로 빠진 채로 결과물이 나옵니다. 권한을 안 나눴으면 권한 얘기가 없고, 롤백을 안 만들었으면 롤백 얘기가 없습니다. 겉으로는 멀쩡해 보이지만, 실은 구멍이 뚫린 채 조용히 나온 문서입니다. 그리고 그 구멍은 몇 달 뒤 "이건 왜 안 했지?"라는 사고로 돌아옵니다.

침묵은 검토할 수가 없습니다. 없는 걸 어떻게 발견하겠습니까. 그래서 저는 시스템이 터지지 않게 막아주는 안전장치들을 목록으로 미리 만들어 두고, 프로젝트마다 그 목록을 한 항목씩 훑으며 '해당 / 비해당'을 판정하게 했습니다. 여기서 결정적인 규칙 하나 — "비해당"이라고 넘길 때도 반드시 사유를 쓰게 했습니다. 예를 들어 "이 프로젝트는 결제 기능이 없으니 정산 검증은 비해당"처럼요. 그냥 빼는 게 아니라, "이건 이러이러한 이유로 이 프로젝트엔 필요 없다"를 문장으로 남기는 겁니다.

이 작은 규칙이 결과를 완전히 바꿉니다. 침묵을 명시적인 판정으로 바꾸면, 빠뜨린 걸 놓치지 않습니다. 항목이 목록에 박혀 있으니 AI가 조용히 건너뛸 수가 없고, 반드시 해당/비해당 중 하나를 골라 이유를 달아야 하니까요. 나중에 문서를 검토할 때도 "아, 백업은 다른 방식으로 대신하니까 비해당이라고 판단했구나" 하고 그 판단 자체를 검증할 수 있습니다. 판단이 틀렸으면 그때 잡으면 됩니다. 하지만 판단이 아예 없으면 잡을 기회조차 없습니다.

이 스킬을 만들 때 제가 스스로에게 건 기준이 이거였습니다 — "만들 수 있냐가 아니라, 1년 뒤에도 안 터지냐." 데모는 금방 만듭니다. 어려운 건 데모가 아니라, 사장님이 매일 쓰는데 1년이 지나도 안 터지는 시스템입니다. 그 차이는 대부분 "눈에 안 보이는 안전장치를 챙겼느냐"에서 갈립니다. 그래서 안 만든 것에 이유를 붙이는 이 습관 하나가, 화려한 기능 여러 개보다 시스템을 오래 살립니다.

Before: AI가 안 한 항목을 침묵으로 넘김 → 문서엔 그 항목이 존재조차 안 함 → 몇 달 뒤 구멍으로 사고. After: 안전장치 목록을 항목마다 해당/비해당 판정 + 비해당도 사유 명시 → 빠뜨림이 눈에 보임 → 발행 전에 잡음.

원칙 4 — 완성형만 받는다

마지막은 결과물의 완성도를 대하는 태도의 문제입니다. AI가 "이 부분은 사장님이 채워 넣으세요" 하고 빈칸을 남기는 순간, 결국 사람이 그걸 다 하게 됩니다. 그럼 AI에게 시킨 의미가 없습니다. 빈칸 문서는 안 쓴 것과 같습니다. 받자마자 다음 단계로 넘어갈 수 없고, 사람이 다시 붙잡고 채워야 하는 문서는 절반만 완성된 셈이니까요.

그래서 규칙을 아예 박아 넣었습니다. 값을 모를 때 빈칸을 남기는 건 금지입니다. 대신 두 가지 길만 허용합니다.

1. 가정으로 채우고 표시한다. 모르는 값이라도 상식적인 가정으로 일단 채우고, "이건 가정입니다"라고 눈에 띄게 표시합니다. 그럼 문서는 완성된 채로 굴러가고, 사장님은 틀린 가정만 골라 숫자를 고치면 됩니다.
2. 못 정한 건 질문 리스트로 뺀다. 아직 사람에게 물어야만 정해지는 값은 본문에 빈칸으로 남기지 않고, "다음 미팅 때 물어볼 질문 리스트" 로 따로 모읍니다(이건 원칙 1의 '묻는 것' 갈래와 그대로 이어집니다). 본문은 완성되고, 미정 사항은 한 곳에 정리됩니다.

어느 쪽이든 문서 자체는 항상 완성된 형태로 나옵니다. "채워 넣으세요"가 없는 거죠.

여기에 하나 더 붙였습니다. 긴 작업은 중간에 끊길 수 있습니다. 그래서 진행 상태를 파일로 저장하게 했습니다. 지금까지 무엇을 했고, 무엇이 확정됐고, 다음에 뭘 할지를 파일에 적어 둡니다. 이러면 작업이 도중에 멈춰도, 처음부터 다시 하는 게 아니라 그 파일만 열어 마지막 지점부터 이어서 갑니다. 사람의 기억은 흐려지고 대화는 날아가지만, 파일에 적힌 결정은 사라지지 않습니다. 이 습관 하나가 긴 작업에서 방향을 잃지 않게 붙잡아 줍니다.

Before: "여기는 나중에 채우세요" 빈칸 문서 → 사람이 결국 다 채움 → 자동화의 의미 상실. After: 모르면 가정+표시 / 못 정하면 질문 리스트 분리 → 항상 완성형 → 받자마자 다음 단계.

네 가지 원칙이 서로 맞물리는 방식

따로 보면 네 개의 팁 같지만, 실제로는 하나의 흐름입니다. 원칙 1로 무엇을 묻고 무엇을 맡길지 나누면, 여기서 못 정한 것들이 원칙 4의 질문 리스트로 흘러갑니다. 원칙 2로 순서를 잡아 문서를 쌓으면, 각 단계마다 원칙 3의 안전장치 판정이 붙어 빠진 게 없는지 확인됩니다. 그리고 원칙 4가 그 모든 결과물을 빈칸 없는 완성형으로 마무리합니다. 한마디로 정리하면 이렇습니다.

이 표를 프롬프트를 쓰기 전 체크리스트로 삼으면 됩니다. AI에게 무언가를 시키기 전에, "이 네 줄을 지키게 시켰나?"를 스스로 물어보는 겁니다.

외식 SMB 인사이트

이 4가지는 거창한 개발 이론이 아니라 "AI한테 일 시키는 법" 입니다. 매장 사장님이 AI로 발주표 하나 만들 때도 똑같이 통합니다. ① 뭘 묻고 뭘 맡길지 나누고, ② 순서대로 시키고, ③ 빠진 게 없는지 확인하고, ④ "채워 넣으세요" 말고 완성본을 요구하세요. AI는 도구지만, 그 도구를 어떻게 쥐느냐에서 결과가 갈립니다.

조금 더 현장 언어로 옮기면 이렇습니다. 발주표를 만들 때 AI가 알 수 없는 것 — 우리 매장 공급사가 어디고 마감이 언제인지 — 은 먼저 정해서 알려주고(원칙 1), 표 양식부터 그리지 말고 무슨 데이터를 담을지부터 정하고(원칙 2), "재고가 0일 때 어떻게 표시할지" 같은 예외 상황을 그냥 넘기지 말고 챙기고(원칙 3), "여기 수량은 직접 넣으세요"가 아니라 예시 값이라도 채워진 완성본을 받으세요(원칙 4). 도구는 점점 좋아집니다. 하지만 좋은 도구도 대충 쥐면 대충 나오고, 이 네 가지를 지키면 같은 도구로도 훨씬 오래 가는 결과물이 나옵니다.

이런 시스템, 우리 매장에도 필요할까요?

발주·급여·매출처럼 매일 반복되는 일을 시스템으로 묶고 싶다면, 매장 상황을 먼저 보고 설계해 드립니다. "만들 수 있냐"가 아니라 "1년 뒤에도 안 터지냐"를 기준으로, 위 4가지 원칙 그대로 설계부터 잡습니다. 무료로 진단합니다.

무료 상담 신청하기 →