사람 팀에서도 혼자 기획하고 혼자 만들고 혼자 검수하는 사람은 자기가 놓친 걸 끝까지 못 본다. AI도 똑같다.
이 글 3줄 요약
- 복잡한 개발·자동화를 AI 한 명에게 통째로 시키면 결과물이 클수록 품질이 흔들린다. 한쪽을 챙기다 다른 쪽을 놓친다.
- 총괄(팀장) 역할이 일을 쪼개 조사·기획·비판·개발·검수 역할로 나눠 맡기고, 결과를 다시 모아 교차 검증시키면 사람 팀처럼 굴러간다.
- 핵심은 '비판' 역할을 따로 두는 것. 만든 쪽과 깨려는 쪽을 분리해야 놓친 걸 잡는다. 이 방법론이 곧 매장 시스템 품질로 이어진다.
왜 한 명한테 다 시키면 흔들리나
작은 일이면 상관없다. 짧은 문서 요약, 문구 다듬기, 메뉴판 문구 몇 줄 고치기 정도는 AI 한 명한테 던져도 충분히 나온다. 시작과 끝이 한눈에 들어오는 일은 시야가 하나여도 놓칠 게 별로 없기 때문이다.
문제는 결과물이 커질 때다. 여기서 '커진다'는 건 단순히 글자 수가 많아진다는 뜻이 아니라, 챙겨야 할 조각이 여러 개로 늘고 그 조각들이 서로 얽힌다는 뜻이다. 여러 화면, 여러 데이터, 여러 예외 상황이 한꺼번에 물려 있는 걸 "알아서 다 만들어줘" 한 방에 시키면 이런 일이 벌어진다.
- 화면 디자인을 예쁘게 챙기다 그 뒤에서 데이터가 어떻게 저장되는지를 대충 넘긴다.
- 정상 흐름(손님이 순서대로 제대로 눌렀을 때)은 잘 짜놓고, 손님이 이상하게 눌렀을 때(엣지케이스)를 안 챙긴다. 여기서 엣지케이스란 '가장자리에서 벌어지는 드문 상황' — 뒤로가기를 두 번 누른다든지, 수량 칸에 숫자 대신 글자를 넣는다든지, 결제 도중 창을 닫는다든지 하는 것들이다. 평소엔 잘 안 일어나지만, 한 번 터지면 시스템이 통째로 꼬인다.
- 자기가 방금 만든 걸 자기가 검수하니, 자기가 놓친 구멍은 끝까지 못 본다.
세 번째가 특히 무섭다. 사람도 마찬가지다. 혼자 다 하는 직원은 실력이 없어서가 아니라, 시야가 하나라서 놓친다. 자기가 세운 가정은 자기 눈엔 당연해 보이기 때문에, 그 가정이 틀렸을 가능성 자체가 시야에 안 들어온다. 오탈자 가득한 글을 자기가 쓰고 자기가 읽으면 안 보이다가, 옆 사람이 5초 만에 잡아내는 것과 똑같다. 해결책은 실력을 키우는 게 아니라 시야를 여러 개로 늘리는 것이다.
AI를 '팀'으로 나누는 6개 역할
한 명에게 다 시키는 대신, 총괄 역할 AI가 일을 쪼개 전문 역할들에게 나눠 맡긴다. 각 역할은 딱 자기 임무에만 집중한다. 자기 임무에만 집중한다는 게 핵심이다. 개발 역할은 '잘 만드는 것'만 생각하고, 비판 역할은 '깨는 것'만 생각한다. 한 머리에 상반된 목표를 동시에 넣으면 둘 다 흐려지지만, 역할을 나누면 각자의 목표가 날카로워진다.
| 역할 | 하는 일 | 사람 팀으로 치면 |
|---|---|---|
| 총괄 | 일을 쪼개고 순서를 정하고 결과를 다시 모은다 | 팀장 |
| 조사 | 업종·자료·비슷한 사례를 먼저 파악한다 | 리서처 |
| 기획 | 무엇을 어떻게 만들지 요구사항과 설계를 짠다 | 기획자 |
| 비판 | 설계의 결함을 일부러 찾아 공격한다 | 깐깐한 검토위원 |
| 개발 | 실제로 코드를 만든다 | 개발자 |
| 검수 | 완성물을 QA하고 예외 상황을 찔러본다 | QA 담당 |
가장 위의 총괄이 사실상 이 팀의 뼈대다. 총괄은 직접 코드를 짜거나 설계를 그리지 않는다. 대신 큰 덩어리 하나를 "먼저 이걸 조사하고, 그 결과로 이걸 기획하고, 그다음 이걸 공격해봐라" 하는 작은 단위로 쪼개고, 누가 먼저이고 누가 나중인지 순서를 잡고, 각자가 내놓은 결과를 다시 하나로 모은다. 사람 팀에서 팀장이 직접 실무를 다 하는 게 아니라 일을 배분하고 취합하는 것과 똑같다. 여기서 QA란 'Quality Assurance', 즉 다 만든 물건을 사용자에게 넘기기 전에 일부러 이리저리 눌러보며 흠을 찾는 마지막 관문을 말한다.
이 흐름이 한 방향으로만 쭉 흐르는 게 아니라는 점이 중요하다. 비판과 검수 단계에서 문제가 나오면 다시 앞으로 돌아간다. 사람 팀에서 회의하고, 반려하고, 다시 고쳐 오는 것과 똑같다.
한 방향이 아니라 돌고 도는 흐름
초보가 흔히 오해하는 게, 이 분업을 '조사부터 검수까지 한 줄로 지나가면 끝'인 컨베이어 벨트로 생각하는 것이다. 실제로는 돌고 도는 흐름에 가깝다.
기획이 설계를 내놓으면 비판이 그걸 두들겨 본다. 비판이 구멍을 찾아내면 그 설계는 통과가 아니라 반려다. 다시 기획으로 돌아가 구멍을 메운 뒤에야 개발로 넘어간다. 개발이 끝나면 검수가 또 다른 눈으로 실제 물건을 찔러본다. 여기서 문제가 나오면 또 앞으로 돌아간다. 사람 팀이 한 번 회의로 끝내지 않고, 초안을 놓고 몇 번 반려와 수정을 거치는 것과 정확히 같다.
이 '돌아가기'가 귀찮아 보이지만, 바로 이게 품질의 원천이다. 앞 단계에서 한 번 걸러낸 문제는 뒤로 안 흘러간다. 반대로 앞에서 안 걸러진 문제는 뒤로 갈수록 고치기 비싸진다. 설계 단계의 구멍은 문장 하나 고치면 되지만, 다 만든 뒤에 같은 구멍을 발견하면 만든 걸 다시 뜯어야 한다. 그래서 이 팀은 최대한 앞단에서, 최대한 여러 번 돌린다.
가장 중요한 건 '비판' 역할을 따로 두는 것
여러 역할 중 하나만 기억하라면 이거다. 만드는 역할과 깨려는 역할을 분리하는 것.
만든 쪽은 자기 결과물에 애정이 있어서 약점을 잘 못 본다. 애정만 문제가 아니다. 만든 사람은 '이건 이렇게 쓰겠지'라는 가정 위에서 만들었기 때문에, 손님이 그 가정을 벗어나 쓰는 장면 자체가 상상이 안 된다. 그래서 '이건 왜 안 되는지 일부러 찾아라'는 임무만 가진 역할을 따로 세운다. 이 역할의 목적은 칭찬이 아니라 흠집 내기다. 잘 만들었다고 어깨를 두드려주는 게 아니라, 어떻게든 무너뜨릴 구석을 찾는 게 임무다.
- 기획이 설계를 내놓으면 → 비판이 "손님이 여기서 뒤로가기를 누르면?", "직원이 수량을 0으로 넣으면?", "같은 주문을 두 번 눌러 보내면?" 하고 공격한다.
- 설계가 그 공격을 견디고 나서야 → 개발이 코드를 만든다.
- 개발이 끝나면 → 검수가 또 다른 눈으로 예외 상황을 찔러본다.
비판이 설계를 두들기는 이 과정은, 실제 손님과 직원이 나중에 시스템을 험하게 쓰는 장면을 미리 당겨서 겪어보는 것과 같다. 진짜 현장에서 사고가 나기 전에, 안전한 설계 단계에서 먼저 터뜨려 보는 것이다. 설계가 이 공격을 견디고 나면, 실제 손님이나 직원이 예상 못 한 방식으로 써도 덜 터진다.
혼자 만들고 혼자 통과시키면 절대 안 나오는 구멍이, 이 분리 하나로 앞단에서 걸러진다. 여러 관점이 동시에 보면, 한 관점이 놓친 실패를 다른 관점이 잡는다. 이건 AI가 더 똑똑해서가 아니라, 구조가 시야를 늘려주기 때문이다.
Before / After — 같은 일을 시키는 두 방식
| 구분 | 한 명에게 다 시키기 (Before) | 팀처럼 나눠 시키기 (After) |
|---|---|---|
| 진행 | 통째로 한 번에 "다 만들어줘" | 조사 → 기획 → 비판 → 개발 → 검수 단계별로 |
| 검수 | 만든 AI가 자기 걸 스스로 통과 | 만든 쪽과 깨려는 쪽이 분리 |
| 놓침 | 엣지케이스·예외 상황을 자주 흘림 | 비판·검수가 앞단에서 걸러냄 |
| 되돌아가기 | 없음(한 번에 끝냈다고 여김) | 문제 나오면 앞 단계로 반려 |
| 처음 속도 | 빠름 | 조금 느림 |
| 나중 | 1년 뒤 예상 못 한 데서 터짐 | 미리 막아 덜 터짐 |
처음엔 나눠 하는 쪽이 조금 느리다. 조사하고, 비판받고, 반려당해 다시 고치는 단계가 끼기 때문이다. 하지만 나중에 터져서 다시 뜯어고치는 시간을 빼면, 전체로는 나눠 하는 쪽이 빠르고 싸다. 눈앞의 속도만 보면 한 방에 시키는 게 이겨 보이지만, 만들고 나서 운영하는 기간까지 통째로 계산하면 결과가 뒤집힌다.
한 방에 시키고 싶은 유혹이 들 때 스스로에게 던져볼 체크리스트는 간단하다.
- 이 일에 챙길 조각이 두세 개를 넘는가? (화면·데이터·예외처리가 다 얽히는가)
- 이게 한 번 쓰고 버리는 게 아니라, 매장에서 매일 돌아가야 하는가?
- 잘못 돌면 돈·재고·급여·손님 데이터가 걸리는가?
셋 중 하나라도 '그렇다'면, 한 명에게 통째로 맡길 일이 아니다.
사장님은 뭘 하면 되나
여기까지 읽으면 "그럼 나도 이 역할 구조를 직접 짜야 하나" 싶을 수 있는데, 그럴 필요 없다. 사장님이 이 여섯 역할을 손수 세팅하거나, 누가 먼저이고 누가 나중인지 순서를 짤 필요는 없다. 그건 만드는 쪽이 안에서 굴리는 구조다.
사장님이 쥐고 있어야 할 건 원칙 하나다. "한 방에 다 만들어 달라"고 던지지 않는 것. 대신 조사 → 설계 → 검증을 나눠 밟는 방식으로 진행되는지만 확인하면 된다. 조사 결과를 보고 "우리 매장은 이 부분이 좀 다르다" 방향을 잡아주고, 설계가 나오면 "이건 이렇게 쓰일 것 같은데" 현장 감각을 얹어주고, 검증에서 나온 문제 목록을 같이 보면 된다. 각 단계에서 나온 결과를 보고 방향만 잡아주는 자리다. 코드 한 줄 읽지 않아도, 이 리듬이 지켜지는지만 보면 결과물의 절반은 결정된다.
이게 왜 매장 시스템 품질로 이어지나
이건 개발자들끼리의 얘기가 아니다. 매장 시스템도 똑같은 원리로 굴러간다.
예약·주문·재고·정산이 얽힌 자동화를 "한 방에 뚝딱" 만들어 달라고 하면, 만들 때는 잘 돌아가는 것처럼 보인다. 데모는 늘 완벽하다. 손님 한 명이 순서대로 예약하고, 재고가 정상 범위에 있고, 정산 숫자가 딱 떨어지는 '착한 상황'만 보여주기 때문이다. 진짜 시험대는 그 착한 상황이 깨지는 1년 뒤다. 바쁜 저녁에 주문이 한꺼번에 몰릴 때, 직원이 급한 손으로 수량을 잘못 입력할 때, 예약이 겹쳐 들어올 때 — 그때 안 터져야 진짜다.
그래서 매장 시스템도 조사 → 설계 → 검증을 나눠 밟아야 한다. 우리 업종은 어떻게 돌아가는지, 바쁜 시간대엔 뭐가 몰리는지 먼저 조사하고, 그걸 바탕으로 어떻게 만들지 설계하고, 그 설계를 일부러 깨보는 검증을 거친다. 이 검증 단계가 앞에서 말한 '비판' 역할이 하는 일이다. 손님과 직원이 시스템을 험하게 쓰는 최악의 순간을, 사고가 나기 전에 안전한 자리에서 미리 겪어보는 것이다. 이 분업을 앞에서 제대로 밟은 시스템일수록 1년 뒤에도 조용히 잘 돌아간다. 반대로 한 방에 만든 시스템은, 조용히 잘 도는 것처럼 보이다가 가장 바쁜 날 가장 크게 터진다.
외식 SMB 인사이트
매장 시스템은 만들 때가 아니라 1년 뒤 바쁜 저녁에 진짜 시험을 본다. 그날 안 터지게 하려면, 만들기 전에 깨보는 사람이 따로 있어야 한다.
주방에서 새 직원이 들어오면 바쁜 저녁 피크에 바로 홀로 세우지 않는다. 한가한 시간에 미리 굴려보고, 일부러 몰아붙여 보고, 실수할 구석을 먼저 짚어준 뒤에야 피크에 세운다. AI 팀으로 만든 시스템도 똑같다. 만들면서 미리 깨보고, 일부러 험하게 써보고, 터질 구석을 앞에서 막아둔 시스템이라야 진짜 바쁜 날 홀로 세울 수 있다.
우리 매장엔 어느 쪽이 필요할까
단순 반복 하나만 자동화한다면 굳이 팀처럼 굴릴 필요는 없다. 메모 하나 자동으로 남기는 정도라면 한 명에게 시켜도 충분하다. 반대로 예약·주문·재고·정산처럼 여러 요소가 얽힌 시스템이라면, 조사·설계·검증을 나눠 밟는 방식이 1년 뒤 사고를 막아준다. 문제는 우리 매장에 필요한 게 어느 쪽인지부터 판단하는 것이다. 이건 자동화하려는 일 자체를 뜯어봐야 나오는 판단이라, 밖에서 이름만 듣고는 알기 어렵다.
그 판단, 혼자 고민하지 말고 같이 봐드리겠다. 우리 매장의 어떤 일을 자동화하면 좋을지, 그게 한 명에게 시킬 일인지 팀처럼 나눌 일인지, 무료 진단에서 정리해 드린다.