4장. 역할 정의의 원리 — 슬롭과 네 칸

이 장이 끝나면: AI 결과물에서 나는 'AI가 만든 티'의 정체를 설명할 수 있고, 역할 하나를 네 칸(판단 기준·금지 목록·프로세스·도구 권한) 으로 정의할 수 있다. 그리고 온티켓 AI 개발팀의 편성표 — 열세 자리 중 우리가 실제로 앉힐 다섯 자리 — 가 결정되어 있다.

4.1 개념 — 'AI가 만든 티'의 정체는 결정의 부재다

어디서 본 듯한 결과물

AI에게 "잘 만들어줘"라고 하면 나오는 결과물에는 공통된 특징이 있다.

• 웹페이지를 시키면: 보라-파랑 그라데이션, 둥근 카드, 이모지 아이콘, 가운데 정렬 히어로
• 글을 시키면: "바야흐로 ~의 시대입니다"로 시작해 "~가 기대됩니다"로 끝나는 글
• 발표자료를 시키면: 파란 배경에 흰 글씨, 항목 세 개씩, 어디서 본 구성
• 테스트 코드를 시키면: 돌아가긴 하는데 정작 중요한 걸 검사하지 않는 빈 껍데기

이런 결과물을 슬롭(slop) 이라고 부른다. 틀린 건 아닌데 아무 맛이 없는, 'AI가 만든 티'가 나는 결과물.

'슬롭'이라는 단어를 한 번 짚어 두면 개념이 또렷해진다. slop은 원래 영어로 가축에게 주는 죽 같은 사료, 또는 아무렇게나 흘린 구정물을 가리키는 말이다. 영양은 있을지 몰라도 누구를 위해 정성껏 지은 음식은 아니다. 2020년대 중반, 생성형 AI가 뿜어내는 '양은 많지만 아무도 특별히 원하지 않은' 콘텐츠를 부르는 말로 이 단어가 자리 잡았다. 스팸(spam)이 '원치 않는 것이 밀려온다'에 방점이 있다면, 슬롭은 '틀리진 않았는데 아무 개성이 없다'에 방점이 있다. 우리가 이 장에서 잡으려는 것이 바로 이 후자의 감각이다.

여기서 한 가지 분명히 해 두자. 슬롭은 '품질이 낮다'와 다르다. 오히려 슬롭은 품질의 하한선은 넘긴 결과물일 때가 많다. 문법이 틀리지 않았고, 버튼이 눌리고, 테스트가 초록불이다. 그래서 얼핏 보면 합격처럼 보인다. 문제는 그것이 세상 누구에게 시켜도 나올 법한 결과라는 점이다. 밋밋해서 문제인 게 아니라, 대체 가능해서 문제다. 온티켓 소개 페이지가 다른 티켓 사이트 열 개와 구별되지 않는다면, 그 페이지는 우리 서비스의 얼굴 역할을 못 한다.

[짚고 가기] "슬롭을 실제로 본 적 있나?"라고 물으면 대개 웃음이 나온다. 누구나 겪어 봤기 때문이다. 여기서 웹 챗봇에 "회사 소개 페이지 만들어줘"를 직접 넣어 결과를 보면 감이 온다. 열에 아홉은 보라-파랑 그라데이션, 히어로 섹션, 이모지가 나온다. 이건 나쁜 지시를 한 게 아니라 아무 지시도 안 한 결과다 — 이 한 문장에 이 장 전체의 방향이 담겨 있다.

슬롭은 AI의 실력 문제가 아니다

여기서 흔한 오해가 생긴다 — "AI 감각이 아직 부족하네." 아니다. 슬롭의 원인은 AI가 아니라 지시에 있다. 정확히는 결정의 부재다.

AI는 학습한 수많은 사례의 경향을 따른다. 지시에 비어 있는 부분 — 어떤 색인지, 어떤 어조인지, 무엇을 검사해야 하는지 — 을 만나면, AI는 그 빈칸을 가장 흔한 값(중앙값) 으로 채운다. 수만 개의 웹사이트에서 가장 흔한 배색이 보라-파랑 그라데이션이라면, 결정 없는 지시의 결과는 보라-파랑 그라데이션이다.

'중앙값(median)'이라는 비유를 조금 더 풀어 두자. 통계에서 중앙값은 '한가운데 있는 값'이다. 어떤 반의 시험 점수를 한 줄로 세웠을 때 딱 가운데 사람의 점수다. AI가 빈칸을 채우는 방식이 이와 닮았다. 학습한 수많은 사례를 한 줄로 세워 놓고, 지시가 아무 방향도 주지 않으면 가장 무난한 한가운데를 고른다. 이것은 결함이 아니라 설계된 안전장치에 가깝다. 정보가 없을 때 튀는 답을 내는 것보다 평균적인 답을 내는 편이, 평균적으로 덜 틀리기 때문이다. 그러니 AI를 탓할 일이 아니다. 우리가 방향을 안 줬으니 AI가 한가운데를 골랐을 뿐이다. 방향을 주는 순간, AI는 한가운데를 떠나 우리가 가리킨 쪽으로 움직인다.

처음 배우는 사람에게는 이 점이 직관적으로 와닿지 않는다. "더 좋은(더 비싼) 모델을 쓰면 슬롭이 사라지지 않나요?"라는 질문이 반드시 나온다. 답은 '아니오'다. 모델이 똑똑해질수록 중앙값의 완성도가 올라갈 뿐, 결정이 비어 있으면 여전히 '더 잘 만든 남의 것'이 나온다. 실력이 는다고 취향이 생기지는 않는다. 취향은 지시하는 사람이 넣어 주는 것이다. 더 좋은 붓을 준다고 그림의 주제가 정해지지 않는 것과 같다.

그러니 슬롭을 보면 이렇게 읽어야 한다 — "여기, 내가 결정을 안 한 자리가 있구나."

이 관점의 전환이 중요한 이유가 있다. 원인이 AI 실력이라면 우리가 할 수 있는 게 없다. 원인이 결정의 부재라면, 처방은 명확하다 — 결정을 채워 넣으면 된다. 그리고 결정을 채워 넣는 체계적인 방법이 이 장의 주제, 역할 정의다.

한 가지 오해를 미리 풀어 두자. "결정을 채워 넣는다"는 것이 "AI를 못 믿으니 일일이 통제한다"는 뜻은 아니다. 오히려 반대다. 결정을 한 번 제대로 문장으로 명확히 적어 두면, 그다음부터는 AI가 그 결정을 알아서 반복 적용한다. 매번 참견하는 대신, 한 번 결정하고 여러 번 위임하는 것 — 이것이 이 장에서 배우는 역할 정의의 경제학이다. 통제가 아니라 위임을 위한 결정이다.

[짚고 가기] "중앙값"이 통계 용어라 낯설다면, "제일 무난한 답", "만인의 정답", "안전빵"으로 바꿔 읽으면 바로 통한다. 그리고 "더 좋은 AI를 쓰면 되지 않나?"라는 의문은 거의 누구나 품는데, 답은 이렇다 — 실력은 늘어도 내 취향은 안 생긴다. 취향은 지시에 넣는 것이다. 이 한마디를 붙잡으면 이 장을 읽는 눈이 달라진다.

4.2 처방 1 — 형용사를 고유명사로

빈칸을 채우는 첫 번째 기술. 기획에서 "형용사를 측정 가능한 기준으로" 바꿨던 것과 같은 원리인데, 적용 범위가 훨씬 넓다. 모든 형용사를, 손에 잡히는 고유명사로 바꾼다.

왜 하필 형용사가 문제인가? 형용사는 듣는 사람마다 다르게 번역되는 단어이기 때문이다. "모던하게"를 열 사람에게 물으면 열 개의 그림이 나온다. AI에게도 마찬가지다. AI는 "모던하게"를 자기가 학습한 수천 개의 '모던'의 평균으로 번역한다 — 그 평균이 바로 중앙값, 즉 슬롭이다. 반대로 "글꼴은 Pretendard, 포인트색은 오렌지 #FF5C33"은 누가 읽어도 같은 하나의 그림으로만 번역된다. 해석의 여지가 없으니 중앙값이 낄 틈도 없다. 정리하면 이렇다 — 형용사는 AI에게 '알아서 채우라'는 빈칸이고, 고유명사는 '이걸로 채우라'는 정답이다.

왼쪽 열로 지시하면 중앙값이 나온다. 오른쪽 열로 지시하면 내 것이 나온다. 오른쪽 열을 채우는 일은 귀찮다 — 그런데 그 귀찮은 결정이 바로, 지금까지 전문가들이 '감각'이라고 불러 온 것의 실체다. 결정을 언어로 바꿔 놓으면 AI가 그 감각을 실행해 준다.

이 지점을 조금 더 밀어붙여 보자. 우리는 흔히 "저 사람은 디자인 감각이 좋다"고 말한다. 그 감각이란 대체 무엇인가? 뜯어보면 그것은 수많은 작은 결정의 축적이다. 여백을 얼마나 둘지, 색을 몇 개까지 쓸지, 글자 크기 단계를 몇 개로 나눌지 — 좋은 디자이너는 이런 결정을 빠르고 일관되게 한다. 그 결정이 몸에 배어 있어서 본인은 '감으로 했다'고 느낄 뿐이다. 형용사를 고유명사로 바꾸는 작업은, 그 감을 꺼내서 언어로 적는 일이다. 일단 적어 두면 AI가 그 결정을 지치지 않고 반복 실행한다. 감각은 사람 안에 있으면 한 사람만 쓰지만, 언어로 나오면 AI가 나 대신 백 번을 쓴다.

약한 지시를 강한 지시로 — 변환 연습

형용사→고유명사 기술을 다양한 직무에 적용해 보자. 왼쪽처럼 흔히 말하지만, 오른쪽처럼 바꾸면 AI가 중앙값을 벗어난다.

오른쪽 열의 공통점을 보라. 하나같이 셀 수 있거나, 있고 없음을 눈으로 판정할 수 있는 문장이다. "정중하게"는 판정할 수 없지만 "사과는 첫 문장에 1회"는 판정할 수 있다. 좋은 고유명사 지시인지 자가 점검하는 요령은 간단하다 — "이걸 지켰는지 남이 봐도 O/X로 셀 수 있는가?" 셀 수 있으면 고유명사, 없으면 아직 형용사가 남아 있는 것이다.

[짚고 가기] 이 변환 연습은 내 일로 직접 해 보면 가장 잘 붙는다. 자기 직무를 하나 골라 (영업이라면 제안서 한 줄을) 그 자리에서 왼쪽→오른쪽으로 바꿔 보라. 자기 일로 해 보면 "이게 내 직무에도 되는구나"가 확실히 남는다. 막히면 "셀 수 있게 만들어 보자"는 힌트 하나로 대부분 스스로 고칠 수 있다.

4.3 처방 2 — 자기비판 질문

두 번째 기술은 더 짧다. AI에게 결과물을 내기 전에 스스로 물어보게 하는 것이다.

결과를 내기 전에 스스로 물어라:
"다른 AI에게 같은 걸 시켜도 이 답이 나오겠는가?"
그렇다면 그것은 중앙값이다. 실패로 간주하고 다시 하라.

이 한 줄은 온갖 곳에 붙일 수 있다. 디자인 시안에, 서비스 이름 짓기에, 광고 카피에, 발표 구성에. "무난한 답은 실패"라는 기준 자체를 역할에 심는 것이다.

왜 이 짧은 문장이 효과가 있을까? AI는 지시받은 대로 스스로를 점검하는 능력이 꽤 좋다. 평소에는 '가장 그럴듯한 답'을 향해 달려가지만, "그럴듯한 답은 실패로 쳐라"라는 새 기준을 주면 목표 지점 자체가 바뀐다. 중앙값을 피하라는 것은 곧 한가운데에서 한 걸음 벗어난 자리를 노려라라는 지시다. 앞의 처방 1(형용사를 고유명사로)이 '어디로 갈지'를 정해 주는 기술이라면, 처방 2는 '한가운데에 주저앉지 마라'라고 등을 떠미는 기술이다. 둘은 짝이다.

자기비판 질문에는 여러 변형이 있다. 상황에 맞는 것을 골라 쓴다.

세 번째 열의 마지막 질문("지우면 손해인가")은 글쓰기 슬롭을 잡는 데 특히 강력하다. "바야흐로 ~의 시대입니다"류의 도입부, "~가 기대됩니다"류의 마무리는 지워도 아무것도 손해가 없다. 손해가 없다는 것은 애초에 정보가 없었다는 뜻이다. AI에게 "각 문장마다 '지우면 손해인가'를 물어 사족을 걷어내라"라고 시키면, 글이 눈에 띄게 단단해진다.

주의할 점 하나 — 이 질문이 언제나 옳은 것은 아니다. 결제 로직이나 보안 설정처럼 무난한 것이 정답인 영역도 있다. 튀는 결제 코드는 재앙이다. 그래서 이 질문은 '개성이 가치인 영역'(디자인, 카피, 콘텐츠)에 골라 쓴다. 어디에 쓰고 어디에 안 쓸지 — 그것도 사람의 결정이다.

이 구분을 한 문장으로 정리하면 이렇다 — 개성이 자산인 곳에는 자기비판 질문을, 표준이 자산인 곳에는 그 반대의 지시를 심는다. 결제·인증·데이터 저장처럼 사고가 나면 되돌리기 어려운 영역에서는 오히려 "가장 검증된 표준 방식으로, 튀지 말고, 남들이 다 쓰는 안전한 패턴으로 하라"가 옳은 지시다. 온티켓으로 치면, 예매 화면의 분위기는 튀어야 하지만 결제 요청을 보내는 코드는 토스페이먼츠 공식 예제와 똑같이 뻔해야 한다. 창의성을 어디에 배치하고 어디에서 금지할지를 정하는 것 자체가, 이 장에서 말하는 '결정'의 한 종류다.

[짚고 가기] 자기비판 질문을 배우면 모든 지시에 붙이고 싶어지기 쉽다. "결제 코드에도 붙이면 되나?" 싶겠지만, 튀는 결제 코드는 그대로 사고다. '개성이 가치인 영역 vs 표준이 가치인 영역'을 가르는 감각이 이 절의 진짜 핵심이다. 같은 카피를 자기비판 질문을 넣고/빼고 두 번 뽑아 비교해 보면 그 차이가 즉각 눈에 들어온다.

4.4 역할 정의의 네 칸

이제 결정들을 담는 그릇의 설계도를 보자. 좋은 역할 정의는 네 칸으로 이루어진다. 어떤 역할이든 — 개발자든 디자이너든 번역가든 — 이 네 칸을 채우면 역할이 선다.

네 칸을 먼저 한눈에 훑고 들어가자. 사람 조직에 빗대면 이렇다.

앞의 세 칸은 '말로 하는 부탁'이고 마지막 한 칸은 '구조로 만든 벽'이라는 점을 미리 기억해 두면, 뒤에서 왜 4칸이 특별한지가 자연스럽게 이해된다.

1칸. 판단 기준 — 역할에 '입장'을 준다

무엇을 좋다고 보고 무엇을 나쁘다고 보는지, 이 역할의 관점을 준다. "티켓 서비스 화면의 최우선은 신뢰감이다. 화려함이 신뢰감과 부딪히면 신뢰감이 이긴다" 처럼. 판단 기준이 없는 역할은 매 결정을 중앙값으로 한다.

판단 기준이 특별히 중요한 이유는, 역할이 일하다 보면 정의에 없는 상황을 반드시 만나기 때문이다. 아무리 금지 목록을 길게 적어도, 실무는 늘 예상 밖의 갈림길을 낸다. 그때 역할이 기댈 곳이 판단 기준이다. "화려함과 신뢰감이 부딪히면 신뢰감이 이긴다"는 한 줄은, 앞으로 나올 수백 개의 세부 결정에 미리 답을 준다. 버튼을 반짝이게 할까 말까, 애니메이션을 넣을까 말까 — 일일이 지시하지 않아도 이 한 줄이 방향을 정해 준다. 그래서 판단 기준은 우선순위를 담은 문장일 때 가장 강하다. "A도 좋고 B도 좋다"가 아니라 "A와 B가 부딪히면 A를 택한다"까지 적어야, 갈림길에서 역할이 헤매지 않는다.

개발 밖의 예를 들어 보자. 고객센터 응대 역할의 판단 기준은 "고객 만족보다 사실 정확성이 먼저다. 확실하지 않으면 확답하지 않고 확인 후 회신한다"일 수 있다. 편집자 역할의 판단 기준은 "재미보다 정확성이 먼저다. 단, 정확성을 해치지 않는 선에서는 최대한 쉽게"일 수 있다. 공통점은, 둘 다 두 가치가 충돌할 때 누가 이기는지를 못 박아 두었다는 것이다.

2칸. 금지 목록 — 하지 말 것을 고유명사로

"이 역할이 절대 하지 않는 것"의 목록이다. 형용사→고유명사 기술이 가장 힘을 발휘하는 칸이다. "촌스럽지 않게"(형용사) 대신 "보라-파랑 그라데이션 금지, 이모지 아이콘 금지"(고유명사 목록)로 적는다. 금지 목록은 경험에서 자란다 — 결과물에서 거슬리는 것을 발견할 때마다 한 줄씩 추가하면 된다.

금지 목록이 판단 기준과 다른 점은, 판단 기준이 '어디로 갈지'라면 금지 목록은 '어디로는 가지 마라'라는 것이다. 방향을 아무리 잘 줘도, 흔히 빠지는 함정을 미리 막아 두지 않으면 AI는 중앙값의 관성으로 그 함정에 빠진다. 이모지, 보라-파랑 그라데이션, "바야흐로"류 도입부는 AI가 특별히 좋아해서가 아니라 학습 데이터에 가장 흔해서 튀어나온다. 금지 목록은 그 관성을 끊는 브레이크다.

금지 목록을 잘 기르는 요령이 하나 있다. 결과물이 마음에 안 들 때 "더 잘해줘"라고 다시 시키지 말고, 거슬린 것 하나를 콕 집어 금지 항목으로 승격시키는 것이다. "이모지가 거슬리네" → 금지 목록에 "이모지 금지" 추가. 이렇게 하면 같은 지적을 두 번 하지 않게 되고, 금지 목록이 곧 우리 팀의 실수 기록장이 된다. 낡은 금지 목록이 없다면, 우리 팀은 같은 슬롭에 매번 새로 당하고 있다는 뜻이다.

개발 밖의 예: 사내 공지 작성 역할의 금지 목록은 "'많은 관심 부탁드립니다' 금지, 느낌표 2개 이상 금지, 근거 없는 '최고/최초/유일' 금지"일 수 있다. 번역 역할의 금지 목록은 "'~에 대하여' 금지, 이중 피동 금지"일 수 있다. 형용사가 하나도 없다는 점을 눈여겨보라 — 금지 목록은 반드시 눈으로 찾아낼 수 있는 것만 담는다. "성의 없게 하지 마라"는 금지 목록이 아니다. 성의는 셀 수 없기 때문이다.

3칸. 프로세스 — 일하는 순서를 정한다

특히 중요한 것이 바로 결과물부터 만들지 못하게 막는 것이다. "코드를 쓰기 전에 계획을 먼저 보여라", "시안 설명을 먼저 하고 승인받은 뒤 만들어라". 순서를 강제하면 사람이 중간에 개입할 지점이 생긴다.

왜 '순서'가 결정거리가 될까? AI는 놔두면 곧장 최종 결과물로 돌진하는 성향이 있다. 목표를 주면 계획을 건너뛰고 바로 완성본을 뱉는다. 이게 편할 때도 있지만, 방향이 어긋난 채로 완성본이 나오면 되돌리는 비용이 크다. 프로세스 칸은 그 돌진 사이에 정거장을 놓는 일이다. "계획 먼저, 승인 후 실행"이라는 순서를 심으면, 아직 수정 비용이 적게 드는 단계(계획)에서 방향을 고칠 수 있다. 완성본을 뜯어고치는 것보다 계획 한 줄을 고치는 데 드는 비용이 백 배 적다.

프로세스는 흔히 이런 형태의 문장으로 적힌다.

• "무엇을 할지 계획을 먼저 제시하고, 내 승인을 받은 뒤에 실행하라."
• "선택지를 3개 제시하고, 내가 고르면 그것만 진행하라."
• "변경 전에 무엇을 왜 바꾸는지 한 문단으로 먼저 설명하라."
• "다 만든 뒤, 스스로 완료 기준을 하나씩 대조해 통과 여부를 보고하라."

개발 밖의 예: 계약서 검토 역할의 프로세스는 "① 위험 조항을 먼저 목록으로 뽑고 → ② 사람이 우선순위를 정하면 → ③ 그 조항만 대안 문구를 제시"일 수 있다. 강의 슬라이드 제작 역할의 프로세스는 "① 목차와 슬라이드별 한 줄 메시지를 먼저 → ② 승인 → ③ 본문 작성"일 수 있다. 공통 구조는 '수정 비용이 적은 초안 → 사람의 개입 → 수정 비용이 큰 완성본'이다. 이 순서를 강제하는 것이 프로세스 칸의 본질이다.

다만 프로세스는 3칸까지의 다른 칸과 마찬가지로 말로 하는 부탁이라는 한계가 있다. "고치기 전에 물어봐"라고 적어도, AI가 그 순서를 건너뛰고 바로 고쳐 버릴 여지가 남는다. 말은 대체로 지켜지지만 항상 지켜지지는 않는다. 이 한계를 구조로 메우는 것이 다음 칸이다.

4칸. 도구 권한 — 권한이 곧 역할이다

이 역할이 쓸 수 있는 도구의 범위다. 검토 역할에게 편집 도구를 주지 않는 것, 운영 역할에게 처음엔 읽기 권한만 주는 것. 네 칸 중 유일하게 말이 아니라 구조로 작동하는 칸이다 — 그래서 가장 강력하다. "고치지 마라"(3칸의 부탁)와 "고칠 도구가 없다"(4칸의 구조)는 다르다.

이 차이를 실감하려면 사람 조직을 떠올리면 된다. "이 서류는 건드리지 마세요"라고 부탁하는 것과, 애초에 그 서류가 든 캐비닛 열쇠를 주지 않는 것은 안전성이 다르다. 부탁은 잊히거나 무시될 수 있지만, 열쇠가 없으면 열고 싶어도 못 연다. 도구 권한이 바로 그 열쇠다. 편집 도구가 손에 없는 리뷰어는 아무리 고치고 싶어도 물리적으로 고칠 수 없다. 그래서 4칸은 유혹 자체를 없앤다.

이 원리가 가장 빛나는 곳이 검증 역할이다. 코드를 만든 사람이 스스로를 검토하면, 자기 코드에 관대해지기 쉽다. 사람도 그렇고 AI도 그렇다. 만든 사람과 검토하는 사람에게 같은 편집 권한을 주면, 검토는 "고치면서 대충 넘어가기"가 되어 버린다. 그래서 검증 역할에게는 편집 도구를 아예 회수한다. 볼 수는 있지만 고칠 수는 없게. 그러면 리뷰어는 고치는 대신 문제를 지적할 수밖에 없고, 그 지적이 사람에게 올라온다. 검증이 형식적인 절차가 아니라 실제 관문이 되는 것이다. 이 원칙은 뒤의 편성표에서 "검증 역할은 반드시 Subagent"라는 결정으로 이어진다.

반대 방향으로도 쓴다. 운영·배포 역할처럼 잘못 만지면 되돌리기 어려운 자리에는 처음부터 읽기 권한만 주고, 실제로 바꾸는 권한은 필요가 증명될 때 하나씩 연다. 파일을 지우거나 서버 설정을 바꾸는 도구는 손에 두지 않는 것만으로 사고의 상당수가 예방된다. 온티켓 인프라 담당의 파괴적 작업을 Hook으로 막는 것(뒤의 편성표 참고)도 같은 발상 — 말로 조심시키는 대신, 위험한 도구를 손에서 뺀다.

정리하면, 앞의 세 칸이 "이렇게 해 줘"라는 방향·울타리·순서라면, 4칸은 "그건 아예 못 해"라는 물리적 경계다. 다른 칸이 다 뚫려도 4칸은 남는다. 그래서 네 칸 중 가장 강력하다.

[짚고 가기] "말로 하는 3칸 vs 구조로 하는 1칸"의 대비가 이 절의 핵심이다. 인턴에게 "이 폴더는 건드리지 마"라고 말하는 것과, 아예 그 폴더 접근 권한을 안 주는 것 중 무엇이 더 확실한가를 떠올려 보면 바로 이해된다. 도구 권한은 뒤에서 Subagent와 Hook을 만드는 실습에서 실제 구조로 구현되니, 여기서는 '왜 권한이 곧 역할인가'라는 개념만 확실히 잡아 두면 충분하다.

네 칸으로 다른 역할도 정의해 보기

이 틀은 개발 밖에서도 그대로 쓰인다. 두 가지 예를 보자.

내 일 하나를 골라 네 칸을 채워 보라. 채워지면 그 일은 AI에게 맡길 준비가 된 것이고, 채워지지 않는 칸이 있다면 — 바로 그 칸이 지금까지 결과물이 마음에 안 들었던 이유다.

개발 밖 직무를 하나 더 펼쳐 보자. 온티켓 밖에서도 이 틀이 얼마나 넓게 쓰이는지 보이도록, 서로 다른 세 직무를 나란히 둔다.

세 직무 모두 판단 기준(입장) → 금지 목록(눈에 보이는 함정) → 프로세스(수정 비용이 적은 초안이 먼저) → 도구 권한(위험한 작업의 실행 권한은 제한) 라는 같은 골격으로 정의된다는 점을 보라. 직무가 무엇이든 네 칸은 그대로다. 이것이 이 틀이 개발 강의를 넘어 '일을 AI에게 맡기는 보편 문법'이 되는 이유다.

역할을 세우는 프롬프트 템플릿

네 칸을 실제 지시문으로 옮기면 이런 형태가 된다. 온티켓 UI 디자이너 역할을 예로 든다.

너는 온티켓의 UI 디자이너다.

[판단 기준]
- 티켓 서비스 화면의 최우선은 신뢰감이다.
- 화려함이 신뢰감과 부딪히면 신뢰감이 이긴다.

[금지 목록]
- 보라-파랑 그라데이션 금지
- 이모지 아이콘 금지
- 색은 배경/본문/포인트 3계열만. 포인트색(오렌지)은 화면당 한 곳만
- 디자인 토큰에 없는 색·글꼴 즉석 발명 금지

[프로세스]
- 시안을 만들기 전에, 무엇을 왜 그렇게 할지 설명을 먼저 제시한다.
- 내가 승인하면 그때 만든다.

[도구 권한]
- 디자인 토큰 문서를 읽는다. 코드를 직접 배포하지 않는다.

[기준 자료]
- 색·글꼴·간격의 유일한 기준은 디자인 토큰 문서다.
  값이 없으면 지어내지 말고 나에게 물어라.

결과를 내기 전에 스스로 물어라:
"다른 AI에게 같은 걸 시켜도 이 시안이 나오겠는가?"
그렇다면 중앙값이다. 실패로 간주하고 다시 하라.

이 템플릿에는 이 장의 모든 처방이 들어 있다 — 네 칸, 기준 자료(다음 절), 그리고 자기비판 질문까지. 직무만 바꿔 끼우면 어떤 역할에도 재사용된다. 뒤 장들에서 만들 Skill과 Subagent가 결국 이 템플릿을 각자의 그릇에 담은 것이라고 이해하면 된다.

[짚고 가기] 이 템플릿을 놓고 내 직무를 하나 끼워 넣어 완성해 보면 감이 잘 잡힌다. 단, 여기서 실제 파일을 만들 필요는 없다 — 이 장은 '어떻게 정의하는가'를 배우는 장이고, '어디에 담는가(Skill/Subagent/Hook)'는 뒷장의 몫이다. 템플릿은 개념을 확인하는 용도로만 보고, 손으로 쓰는 실습은 이 장 끝의 워크시트에서 한다.

4.5 기준 자료 — 없으면 AI는 매번 지어낸다

네 칸과 함께 다니는 개념이 하나 있다. 기준 자료(source of truth) — 그 주제에 관한 한 유일하게 믿을 수 있는 기준 문서다.

여기서 '기준 자료'는 영어 'single source of truth'를 가리킨다. 직역하면 '진실의 유일한 출처'다. 핵심은 '유일한'에 있다. 같은 정보가 여러 곳에 흩어져 있으면, 반드시 서로 달라지는 순간이 온다. 어제 문서에는 버튼색이 오렌지인데 오늘 코드에는 빨강이라면, 둘 중 무엇이 맞는가? 기준 자료는 이 질문에 미리 답을 정해 두는 것이다 — "다투면 이 문서가 이긴다." 그러면 나머지는 전부 이 하나를 따르면 된다. 사본이 아무리 많아도 기준이 되는 원본은 하나여야 한다는 오래된 원칙을, 소프트웨어에서는 이 이름으로 부른다.

색과 글꼴의 기준 자료는 디자인 토큰 문서, API의 기준 자료는 API 명세, 용어의 기준 자료는 용어집. 기준 자료가 없으면 AI는 물어볼 곳이 없으므로 매번 새로 지어낸다. 오늘 만든 화면과 내일 만든 화면의 버튼 색이 다른 이유, 문서마다 같은 기능의 이름이 다른 이유가 이것이다.

여기서 이 장 첫머리의 논리가 다시 등장한다. AI는 빈칸을 중앙값으로 채운다고 했다. 기준 자료가 없다는 것은 곧 그 주제 전체가 빈칸이라는 뜻이다. 버튼색을 정한 문서가 없으면, AI는 매번 '가장 흔한 버튼색'을 새로 고른다. 그것도 물어볼 때마다 조금씩 다르게. 그래서 기준 자료의 부재는 슬롭을 낳을 뿐 아니라 일관성의 붕괴를 낳는다. 슬롭이 '개성 없음'의 문제라면, 기준 자료 부재는 '매번 달라짐'의 문제다. 둘 다 뿌리는 같다 — 결정이 한곳에 박혀 있지 않다는 것.

기준 자료와 네 칸의 관계도 짚어 두자. 기준 자료는 특히 금지 목록과 판단 기준의 바깥 저장소처럼 작동한다. 색을 매번 지시문에 나열하는 대신 "색은 디자인 토큰 문서를 따르라" 한 줄로 위임하면, 결정이 문서에 모이고 지시문은 가벼워진다. 결정이 바뀌면 문서 하나만 고치면 되고, 그 역할을 쓰는 모든 작업이 자동으로 새 결정을 따른다. 기준 자료는 말하자면 팀 전체가 공유하는 결정 저장고다.

그래서 역할을 세울 때는 항상 짝을 확인한다 — "이 역할의 기준 자료는 무엇인가?"

개발 밖으로도 그대로 확장된다. 아래를 보면 기준 자료가 '개발 문서'만을 뜻하는 게 아님을 알 수 있다 — 그 역할이 다툴 때 기대는 기준이 되는 원본 문서면 무엇이든 기준 자료다.

기준 자료를 다룰 때 반드시 함께 심어야 할 규칙이 하나 있다 — "기준 자료에 값이 없으면, 지어내지 말고 물어라." 이 한 줄이 없으면 AI는 문서에 없는 값을 만나는 순간 다시 중앙값으로 채운다. 기준 자료를 만든 의미가 사라지는 것이다. 그래서 역할 정의에는 거의 항상 이 문장이 붙는다. 앞의 온티켓 UI 디자이너 템플릿에서 기준 자료 항목에 "값이 없으면 지어내지 말고 나에게 물어라"가 들어 있던 이유가 이것이다.

[짚고 가기] "PRD가 왜 기준 자료인가?"라는 의문이 든다면 제대로 짚은 것이다. 무엇을 만들지 다투는 순간 우리는 PRD를 편다. PRD에 없으면 안 만든다 — 그게 기준 자료라는 뜻이다. "내 일의 기준 자료는 무엇인가?"를 스스로 물어보면, 대개 처음엔 답이 잘 안 나온다. 그 막막함이 바로 왜 그 일의 결과가 매번 들쭉날쭉했는지에 대한 답이다.

4.6 편성표 — 열세 자리 카탈로그에서 다섯 자리만

역할 카탈로그

소프트웨어를 만들어 출시하는 회사에는 대략 이런 자리들이 있다. 이것이 우리가 AI로 채울 수 있는 자리의 카탈로그다.

이 카탈로그를 네 직군(기획·제작·검증·운영)으로 나눠 놓은 것이 우연이 아니다. 소프트웨어를 만들어 내보내는 흐름 자체가 이 순서다 — 무엇을 만들지 정하고(기획), 만들고(제작), 제대로 됐는지 보고(검증), 내보내 굴린다(운영). 이 흐름은 이 과정 첫머리에서 본 '결정·승인·검증'이라는 사람의 일이 팀 단위로 펼쳐진 모습이기도 하다. 각 자리는 이 흐름의 한 구간을 맡는다. 그래서 어떤 자리를 앉힐지 정하는 것은, 결국 '이 흐름의 어느 구간을 AI에게 맡기고 어느 구간을 사람이 직접 쥘 것인가'를 정하는 일이다.

한 가지 눈여겨볼 것은 검증 직군이 네 자리나 된다는 점이다. 제작 직군에 맞먹는 두께다. 만드는 자리는 겸직으로 줄일 수 있어도, 보는 자리는 관점마다 따로 필요하기 때문이다. 코드가 맞는지 (리뷰어), 완료 기준을 채웠는지(QA), 위험하지 않은지(보안), 눈에 괜찮은지(디자인 리뷰어) — 이 네 관점은 서로 대신하지 못한다. 검증이 두껍다는 것은, 만드는 것보다 제대로 됐는지 보는 것이 자율 워크플로우에서 더 무거운 일이라는 뜻이다.

다 앉히고 싶은 유혹 — 역할 인플레이션

카탈로그를 보면 욕심이 난다. 열세 자리 전부 만들면 진짜 회사 같겠는데? 그러나 자리가 늘수록 관리가 일이 된다. 역할마다 네 칸을 채우고, 최신으로 유지하고, 서로 부딪히지 않게 조율해야 한다. 열세 자리를 만들어 놓고 방치하면 차라리 없느니만 못하다 — 낡은 역할 정의는 낡은 결정을 계속 실행하기 때문이다.

'인플레이션'이라는 말을 쓴 이유가 있다. 화폐가 흔해지면 가치가 떨어지듯, 역할도 흔해지면 값이 떨어진다. 자리가 열세 개면 그중 어느 것도 진지하게 관리되지 않는다. 게다가 역할 정의는 한 번 만들고 끝이 아니다. 서비스가 바뀌면 판단 기준도 금지 목록도 따라 바뀌어야 한다. 방치된 역할은 옛 결정을 붙든 채 계속 일하므로, 어느 순간 도움이 아니라 방해가 된다. "이 리뷰어는 왜 아직도 없어진 규칙으로 지적하지?" 같은 일이 생기는 것이다. 그래서 역할은 자산이자 동시에 부채다. 관리할 수 있는 만큼만 가진다.

원칙: 카탈로그는 카탈로그일 뿐, 편성은 지금 필요한 최소로. 자리는 필요가 증명될 때 늘린다. 같은 지적이 반복되면 그때 그 자리를 만드는 식으로.

'필요가 증명될 때'가 구체적으로 무슨 뜻인지 감을 주자. 예를 들어 코드 리뷰에서 "이 입력값 검증이 빠졌다"는 지적이 서너 번 반복되면, 그것은 보안 검토자 자리가 필요하다는 신호다. 화면 리뷰에서 "간격이 들쭉날쭉하다"가 반복되면 디자인 리뷰어 자리가 필요하다는 신호다. 이렇게 반복되는 지적이 자리를 부른다. 처음부터 열세 자리를 세워 두는 게 아니라, 아픈 곳이 생기면 그곳에 자리를 하나 놓는 것 — 이것이 관리 가능한 팀을 유지하는 방법이다.

온티켓 편성표 — 5자리 + 겸직

3일짜리 온티켓 프로젝트의 편성이다.

'그릇'이라는 낱말이 처음 나오니 짚어 두자. 같은 역할 정의라도 어디에 담느냐에 따라 작동 방식이 달라진다. 여기 쓰인 세 그릇의 성격만 미리 감으로 잡아 두면 표가 읽힌다 (각각을 실제로 만드는 방법은 뒷장에서 다룬다).

• Skill: 부르면 오는, 이름 붙은 역할이다. /pm처럼 호출해 쓴다. 판단 기준·금지 목록·프로세스가 문서로 저장되어 있어, 부를 때마다 같은 결정을 재현한다. PM·디자이너처럼 반복 호출하는 만드는 자리에 어울린다.
• Subagent: 본 대화와 분리된 별도의 일꾼이다. 대화 맥락도, 도구 권한도 따로 가진다. 그래서 편집 도구를 회수한 채 '보기만 하는' 역할을 만들기에 딱 맞다. 검증 자리가 여기에 담기는 이유다.
• Hook: 특정 순간에 자동으로 끼어드는 자동 장치다. 사람이 부르지 않아도 조건이 맞으면 발동한다. 위험한 명령이 실행되려 할 때 가로막는 식으로, 도구 권한 칸을 구조로 강제할 때 쓴다.

두 가지 결정을 눈여겨보자. 첫째, 백엔드와 프론트를 겸직시켰다 — 서비스가 작을 때는 나누는 비용이 더 크다. 둘째, 검증 자리(리뷰어+QA)는 겸직이더라도 반드시 Subagent다. 만드는 사람과 검토하는 사람이 같은 권한을 가지면 검증이 형식적인 절차가 된다는 원칙은 겸직 여부와 무관하게 지킨다.

이 두 번째 결정을 조금 더 풀어 두자. 왜 겸직은 허용하면서 'Subagent여야 한다'는 양보하지 않는가? 겸직은 일의 양 문제이고, Subagent 여부는 권한의 분리 문제이기 때문이다. 리뷰어와 QA를 한 자리로 묶은 것은 서비스가 작아 볼 것이 적어서다 — 나중에 커지면 나눈다. 하지만 그 자리가 만드는 사람과 같은 편집 권한을 갖느냐는 크기와 무관한 원칙이다. 만든 사람이 자기 것을 보면 관대해진다는 함정(도구 권한 칸에서 본 것)은 프로젝트가 작다고 사라지지 않는다. 그래서 '겸직해도 되지만, 편집 도구는 없는 별도 일꾼(Subagent)이어야 한다'는 두 조건이 함께 붙는다. 이것이 이 과정 전체에서 검증에 관한 한 타협하지 않는 단 하나의 규칙이다.

(보안 검토자와 디자인 리뷰어는 이 표에 없지만 프로젝트가 진행되며 필요가 증명되는 순간 추가된다 — 자리는 필요할 때 늘린다는 원칙 그대로다. 만드는 자리도 같다. 데이터를 설계할 때 DBA가, API 계약을 쓸 때 아키텍트가 그렇게 추가된다.)

바로 앞 절의 '필요가 증명될 때'와 연결해 보면, 이 두 자리가 빠진 게 실수가 아니라 결정임을 알 수 있다. 지금은 없다. 보안 지적이 반복되면 보안 검토자를, 화면 지적이 반복되면 디자인 리뷰어를 그때 앉힌다. 처음부터 열세 자리를 다 세우는 대신 다섯으로 시작하는 것 — 이 절제가 곧 이 장의 실천이다.

[짚고 가기] 이 표에서 가장 궁금해지는 대목은 "그릇이 왜 다 다른가"다. 지금은 그릇의 상세 구현까지 파고들 필요 없이 — 그건 뒷장 몫이다 — "만드는 자리는 Skill, 보는 자리는 Subagent, 막는 장치는 Hook"이라는 대응만 확실히 잡으면 된다. 특히 "검증은 반드시 Subagent"는 이 과정의 몇 안 되는 '절대 규칙'이니, 그 이유(만든 사람이 자기 것에 관대해진다)와 함께 기억해 두자. 오대표 세계관에 얹어 보면, 골목 라이브 초과 판매 사고처럼 만든 사람이 자기 코드를 스스로 통과시키면 그런 사고가 난다 — 이렇게 연결해 두면 잊히지 않는다.

4.7 워크시트 — 손으로 쓰는 5분

이 장은 만들기보다 결정하기가 실습이다. 종이(또는 메모장)에 직접 쓴다. AI에게 시키지 않는 이유가 있다 — 이 결정들이 바로 AI가 못 하는, 사람의 일이기 때문이다.

한 번 더 못을 박아 두자. 만약 이 워크시트를 AI에게 시키면, AI는 무엇을 내놓을까? 당연히 중앙값이다. '가장 흔한 편성표', '가장 무난한 판단 기준'. 그런데 우리가 이 장에서 배운 것이, 바로 그 중앙값을 거부하고 내 결정으로 빈칸을 채우는 일이었다. 그러니 이 실습을 AI에게 넘기는 순간 이 장의 교훈을 정면으로 배신하는 셈이 된다. 손으로 쓰는 5분이 어색해도 그대로 하는 이유가 여기 있다 — 이건 AI가 대신할 수 없는, 정확히 사람 몫의 일이다.

활동 1 — 슬롭 판별 (2분)

다음 지시들에서 '결정이 비어 있는 자리'를 찾아 표시해 보라.

1. "회사 소개 페이지를 전문적인 느낌으로 만들어줘"
2. "고객 사과문을 진정성 있게 써줘"
3. "주문 취소 기능을 안전하게 구현해줘"

(1은 '전문적인 느낌' — 어떤 글꼴·색·구성? / 2는 '진정성 있게' — 사과 범위, 보상 언급 여부, 문장 길이? / 3은 '안전하게' — 취소 가능 조건, 환불 시점, 중복 취소 처리?)

세 지시 모두 밑줄 칠 단어가 형용사라는 점을 확인시키면 좋다 — '전문적인', '진정성 있는', '안전한'. 이 형용사들이 곧 처방 1에서 배운 '고유명사로 바꿔야 할 빈칸'이다. 그리고 세 번째 '안전하게'는 앞의 자기비판 질문에서 본 것처럼 자기비판 질문을 붙이면 안 되는 영역(표준이 정답인 영역)이라는 점까지 짚으면, 이 장의 처방 두 개가 활동 하나에 다 녹아든다. 여유가 있으면 학생에게 각 형용사를 고유명사 세 개로 즉석에서 바꿔 보게 한다.

활동 2 — 내 편성표 (3분)

온티켓 편성표를 참고해, 내 일 또는 내 프로젝트의 편성표를 3~5자리로 적어 보라. 자리마다 한 줄씩: 자리 이름 / 그릇(Skill·Subagent·Hook 중) / 기준 자료.

막히는 학생을 위해, 개발이 아닌 일로도 편성표가 나온다는 것을 예시로 보여 주면 좋다. 예컨대 '유튜브 채널 운영'이라면 이렇게 적힌다.

여기서도 검증 자리(사실 검토자)는 Subagent이고 편집 권한이 없다는 점, 되돌리기 어려운 일(게시)은 사람이 최종으로 쥔다는 점이 온티켓 편성표와 똑같이 반복된다. 학생이 자기 일로 이 패턴을 재현하면, 이 장을 제대로 소화한 것이다.

수업에서는 옆 사람과 편성표를 바꿔 보고 한 가지씩만 묻는다 — "이 검증 자리, 왜 Subagent가 아니에요?"

이 한 가지 질문만 서로 주고받아도 충분한 이유가 있다. 이 질문은 편성표에서 가장 자주 틀리는 지점을 정확히 찌른다. 사람들은 검증 자리를 무심코 '만드는 자리와 같은 대화'에 두는데, 그러면 만든 사람이 자기 것을 검사하는, 도구 권한 칸에서 본 함정에 빠진다. 짝에게 이 질문 하나를 받으면, 자기 편성표의 가장 약한 칸이 바로 드러난다.

완료 기준 체크리스트

• 슬롭을 "결정의 부재"라는 말로 설명할 수 있다
• 형용사 하나를 골라 고유명사 세 개로 바꿀 수 있다
• 네 칸(판단 기준·금지 목록·프로세스·도구 권한)을 외우고 있다
• 온티켓 편성표 5자리와, 검증 자리가 Subagent인 이유를 말할 수 있다
• 내 프로젝트의 편성표 초안이 손으로 적혀 있다

[짚고 가기] 이 워크시트는 5분이면 된다. 완벽한 편성표를 만드는 게 목표가 아니라, '내 일에도 이 틀이 적용된다'는 걸 체험하는 게 목표다. 다 못 채웠다면, 채워지지 않은 칸이 바로 지금까지 그 일의 결과가 마음에 안 들었던 이유다 — 본문의 이 문장을 자기 표에 그대로 대 보면 오히려 통찰이 된다. 자기 편성표에서 '검증 자리를 왜 그 그릇에 담았는지'만 스스로 설명해 봐도 이 장의 핵심은 확인된다.

4.8 정리

• 'AI가 만든 티'(슬롭)의 원인은 AI의 실력이 아니라 결정의 부재다. AI는 빈칸을 중앙값으로 채운다. 슬롭이 보이면 "내가 결정 안 한 자리"를 찾아라.
• 처방 둘: 형용사를 고유명사로 바꾼다. 개성이 가치인 영역에는 자기비판 질문 ("다른 AI도 같은 답을 낸다면 실패")을 심는다.
• 역할 정의의 네 칸 — 판단 기준(입장), 금지 목록(고유명사), 프로세스(순서 강제), 도구 권한(구조로 작동하는 유일한 칸). 번역가든 대본작가든 이 틀로 정의된다.
• 역할마다 기준 자료를 짝지어라. 없으면 AI는 매번 지어낸다. 값이 없으면 지어내지 말고 물으라는 규칙을 함께 심는다.
• 편성은 카탈로그의 최소만 — 온티켓은 5자리 + 겸직. 자리는 필요가 증명될 때 늘리고, 검증 자리는 겸직이어도 반드시 Subagent다.