기획자를 위한 AI 설계 연재를 시작하며

한동안 AI를 활용해 일하는 방식, 즉 '기획 AX'에 대한 이야기를 나눠왔습니다. 이제 다시 우리가 매일 마주하는 진짜 숙제, "그래서 AI 서비스는 대체 어떻게, 뭘 기획해야 하지?"라는 기획자들의 현실적인 고민으로 돌아오려 합니다.

생성형 AI가 제품의 핵심 로직으로 들어오면 기획에서는 하지 않던 일들이 새로 추가됩니다. 화면이나 기능 명세서를 넘어서, AI를 제어하기 위해 추가로 정의하고 챙겨야 하는 스펙들이 더 늘어나는 거죠.

머릿속에 떠오르는 꼭지만 뽑아도 10가지가 넘지만, 지난 몇 년간 고민하며 정리해 보니 결국 아래의 4가지가 가장 결정적이자 필수적인 핵심이라는 생각이 들었습니다. 그 네 가지는 가드레일, Tool Use, HITL(Human-in-the-loop), 컨텍스트(Context)입니다. 

각각의 기획 업무에 대해 짧게 설명하면 아래와 같아요.

⚡️ AI 서비스 기획의 4대 핵심 요소

물론 평가(Eval), RAG, 레이턴시, 할루시네이션 등 챙길 것은 더 많지만 위 네 가지는 특히 빠질 수 없다고 봐요. 모델로 가드레일을 붙잡고, Tool로 모델에 손발을 붙여주고, HITL으로 사람과 연결하고,  컨텍스트로 상황을 이해시킬 때 비로소 제대로 된 AI 서비스가 태어납니다.

앞으로 4편에 걸친 4부작으로 이 네 가지를 다뤄보려 합니다. '가드레일' 이야기부터 시작해 봅니다.

가드레일이 무엇이에요?

가드레일은 한마디로 'AI가 하면 안 되는 걸 하지 못하도록 모델을 감싸는 안전장치'입니다.

AI 서비스를 '카페'라고 비유해볼게요. AI 모델은 '카페에서 주문을 처리하는 직원'입니다. 그런데 카페에는 종종 이상한 손님이 옵니다. 와서 욕설하는 손님, 커피에 수면제를 타서 달라는 둥 위험한 주문을 요구하는 손님도 있어요. 직원은 최대한 잘 대응하려 하지만, 당황해서 헛소리를 하거나 위험한 요구를 덜컥 들어줄 수도 있습니다.

그래서 카페는 안전장치를 세웁니다. 중요한 건 이 안전장치가 단 한 겹이 아니라 세 겹의 방어선으로 이루어져 있다는 점입니다.

많은 분들이 "가드레일? 그거 그냥 프롬프트에 '이건 하지 마, 저건 하지 마' 적어두는 거 아니야?" 하고 오해하시곤 합니다. 하지만 프롬프트는 세 겹 중 겨우 첫 번째 겹에 불과해요. 진짜 가드레일은 이렇게 세 개의 겹으로 완성됩니다.

1. 프롬프트 — 직원에게 응대 매뉴얼을 쥐여주는 것

"이런 주문은 정중히 거절하세요"라고 적힌 쪽지를 직원 손에 들려주는 거예요. 붙이기 쉽고 빠릅니다. 하지만 직원이 바쁘거나 손님이 말을 교묘하게 꼬면 쪽지를 놓칠 수 있어요. 가장 가볍지만, 그만큼 우회하기 쉬운 가장 약한 방어선입니다.

2. 모델 튜닝 — 직원 자체를 교육해서 몸에 배게 하는 것

쪽지 없이도 반사적으로 걸러내도록, 직원을 반복 훈련시키는 거예요. 매뉴얼을 안 봐도 "아, 이건 우리 카페에서 안 되는 주문이지" 하고 몸이 먼저 반응하게 만듭니다. 시간과 비용이 많이 들지만, 모델의 체질을 바꾸는 근본적인 방어선이 됩니다.

3. 가드레일 API — 직원과 별개로 세운 전담 '문지기'

직원이 아무리 잘 훈련돼도 실수는 나옵니다. 그래서 직원과 완전히 분리된 문지기를 둬요. 그것도 최소 두 명 — 들어오는 손님을 검사하는 입구 문지기(입력 검사) 한 명, 직원이 내놓은 답을 손님에게 건네기 전에 다시 보는 출구 문지기(출력 검사) 한 명씩요. 직원(메인 모델)이 놓치더라도 마지막 순간에 물리적으로 차단해 주는 독립된 방어선입니다.

정리하면 가드레일은 직원에게 매뉴얼을 주고(프롬프트) → 직원을 훈련시키고(튜닝) → 그래도 못 믿어서 전담 문지기까지 세우는(API), 이 세 겹을 모두 합친 구조를 의미합니다.

비유는 알겠어요, 실제로 어떻게 적용한다는 건가요?

실제로 서비스를 구현할 때 이 세 겹을 어떻게 적용하는지 하나씩 풀어볼게요.

1. 프롬프트 가드레일을 적용한다는 건

비유하자면 직원에게 "이런 손님은 이렇게 대하세요"라고 적힌 쪽지를 쥐여주는 거라고 했는데요 실제로는 모델에게 주는 지시문인 '시스템 프롬프트' 에 응대 규칙을 글로 적어두는 겁니다.

예시

2. 모델을 튜닝한다는 건

비유하자면 직원을 반복 교육해서, 쪽지 없이도 몸에 배게 만드는 거라고 했는데요 실제로는 "이런 요청엔 이렇게 답하라"는 예시를 수천 개 모아서 모델을 다시 학습시키는 겁니다. 프롬프트에 일일이 적지 않아도 모델이 알아서 "그건 도와드릴 수 없어요"라고 반응하도록 훈련하는 거죠. 대표적으로 두 가지 방법이 있습니다.

첫번째는 모법답안을 그대로 따라하게 만드는 방식(=지도 파인튜닝 방식)입니다. 모범 답안지를 계속 보여주며 베끼게 하는 거죠. "이런 요청이 오면 → 이렇게 답하는 게 정답"인 대화 쌍을 수천 개 만들어서 모델에게 반복 학습시켜요.

두번째는 잘한 답에 상, 못한 답에 벌을 주는 선호학습 방식입니다. 같은 질문에 모델이 답을 여러 개 내놓게 한 뒤, 사람이 "이 답이 저 답보다 낫다"고 순위를 매기는거죠. 잘한 답에 상 주고 못한 답에 벌을 줘서 자연스럽게 습관이 들게 하는 방식이에요. 

3. 가드레일 API를 적용한다는 건

비유하자면 직원과 완전히 별개인 '전담 문지기'를 세우는 거라고 했는데요, 앞의 프롬프트와 모델 튜닝이 직원 자체를 손보는 거였다면, 가드레일 API는 직원과 완전히 분리된 검사 모델을 호출 흐름 앞뒤에 끼워넣는 방식이에요. 

여기서 핵심은 '언제 호출되느냐'입니다.

사용자 입력
  │
  ▼
[입력 검사]         ← 가드레일 API 호출 ①
  │                 위험하면 여기서 차단, 메인 모델은 부르지도 않음
  ▼
메인 모델(직원) 응답 생성
  │
  ▼
[출력 검사]         ← 가드레일 API 호출 ②
  │                 위험하면 답을 사용자에게 안 보내고 차단/교체
  ▼
사용자에게 전달

즉, 메인 모델을 부르기 전에 한 번(입력), 부르고 난 뒤에 한 번(출력), 총 두 번의 검사 API를 끼워넣는 거예요.

이때 검사를 전담하는 모델들은 메인 모델과 체급 및 목적이 아예 다른, 검사만 전문으로 하는 별도의 모델이에요. 대표적으로 다음과 같은 전문 API와 모델들이 활용됩니다.

주요 테크 기업의 가드레일 API & 모델

3개 다 적용해야 해요?

보통 3중으로 적용합니다. 프롬프트 + 모델 튜닝 + 가드레일 API 이렇게요. 세 겹이 각자 다른 실패를 막기 때문에 상호보완적이기 때문에 그렇습니다. 

왜 세 겹을 다 써야 할까? (3가지 가드레일 비교)

프롬프트가 놓친 걸 튜닝이 줄이고, 튜닝도 못 잡은 걸 가드레일이 최종 차단하는 구조라서, 진지한 프로덕션에선 삼중이 기본 지향점이 맞습니다.

다만 처음부터 셋 다 힘줄 필요는 없습니다. 비용과 속도 특성이 달라서 단계가 다릅니다. 

그럼 가드레일 적용할 때 기획자는 뭘 해요?

문지기 모델을 만드는 건 AI Safety 팀과 모델팀의 몫이에요. 하지만 앞에서 본 세 겹 전부에서, 기획자가 해줘야 하는 일이 따로 있습니다. 

1. 프롬프트 겹 — 기획자는 '응대 규칙과 문구'를 정의해줘야 해요.

어떤 요청을 거절할지, 거절할 때 뭐라고 말할지("그건 도와드릴 수 없어요" vs "대신 이건 어떠세요?"), 서비스 톤은 어떻게 유지할지 — 이 규칙과 문구를 정해줘야 합니다.

프롬프트를 실제로 누가 문장으로 옮겨 쓰느냐는 회사마다 달라요. 기획자가 직접 쓰는 곳도 있고, 모델러가 주도적으로 쓰는 곳도 있어요. 다만 어느 쪽이든, 무엇을 거절하고 뭐라고 답할지라는 정책 기준은 기획자가 정의해줘야 프롬프트가 나옵니다.

2. 모델 튜닝 겹 — 기획자는 '학습 재료의 기준'을 정해줘야 해요.

모델을 재교육하는 건 모델팀이 하지만,무엇을 '올바른 정답'으로 가르칠지는 기획자가 정해줘야 합니다. "이런 요청엔 이렇게 답하는 게 옳다"는 정책 기준, 좋은 답/나쁜 답 예시, 거절 시 모범 문구 — 이런 걸 정의해서 넘겨주면 모델팀이 학습에 써요.

튜닝을 직접 돌리진 않아도, 무엇을 학습시킬지의 방향은 기획자가 잡아줘야 합니다.

3. 가드레일 API 겹 — 기획자는 '문지기 운영 규칙'을 설계해줘야 해요.

가드레일 API를 만드는건 AI Safety 팀이지만 여기서 기획자가 해야 할 일이 가장 많으며, 크게 3가지로 나뉩니다.

👉 OpenAI Moderation API로 보는 실전 예시

실제 많은 서비스들이 사용하는 OpenAI Moderation API를 예로 들어볼까요? 사용자 요청 발화를 API에 넣으면 "차단해/마라"를 알려주는 게 아니라 아래와 같은 점수판(JSON)을 돌려줍니다.

{
  "flagged": true,
  "categories": { "self-harm": true, "violence": false, "sexual": false },
  "category_scores": { "self-harm": 0.87, "violence": 0.02, "sexual": 0.11 }
}

여기서 핵심은 category_scores입니다. 폭력 0.02점, 자해 0.87점처럼 카테고리별 위험 확신도 점수(0~1 사이)를 돌려주는 것이죠.

category_scores    0 ────────────── 1
  자해(self-harm)    ██████████████░░  0.87  🔴 임계치(0.7) 넘음 → 차단
  폭력(violence)     █░░░░░░░░░░░░░░░  0.02  🟢 통과
  성적(sexual)       ██░░░░░░░░░░░░░░  0.11  🟢 통과
                                 ┊
                       기획자가 그은 선 ┈┈┈ 0.7

기획자는 flagged=true가 왔다고 해서 무조건 1차원적으로 차단하는 기획을 해서는 안 됩니다. 점수는 우리 판단의 입력값일 뿐 최종결정은 기획자가 내려요. 구체적으로 아래 3가지 측면에서 기준을 정해요.

첫째로 커트라인을 정합니다. 자해 점수 0.5부터 막을지, 0.9부터 막을지 — API가 안 정해줘요. 우리 서비스 성격에 맞게 우리가 정합니다. 이때 서비스의 성격을 고려해야해요. AI를 이용한 정신건강 상담 앱이면 자해 커트라인을 아주 예민하게, AI 게임 앱이면 폭력 커트라인을 좀 느슨하게 잡아야겠죠.

둘째로 카테고리마다 다른 대응 정책을 정해요. 같은 점수라도 카테고리별로 무게가 달라요. "성적/미성년(sexual/minors)"은 0.3만 나와도 즉시 차단, "폭력(violence)"은 0.8까지 봐줄 수도 있고 — 이 정책을 카테고리별로 기획자가 짭니다.

셋째로 막는것 말고 다른 선택지를 고민해요. 특히 점수가 애매한 회색지대의 사용자 요청인 경우 중요해요. 무조건 차단할 수도 있지만, 사람 담당자에게 검토 알림을 보내게 할 수도 있고 응답을 순화할 수도 있습니다. 즉 "차단 vs 통과" 이분법이 아니라 여러 대응을 점수 구간별로 설계하는 업무를 기획자가 해줘야합니다.

즉, 가드레일 API는 온도계예요. "38.5도"라고 숫자만 알려줄 뿐, 온도계가 "당장 입원해!"라고 명령하는 게 아니듯, 가드레일 API의 점수도 그 자체가 차단 명령이 아니라 우리가 해석할 재료(신호)로 간주해야 합니다.

직접 하진 않아도, 곁에서 받쳐줘야 하는 3가지

가드레일 시스템이 헛돌지 않도록 기획자가 함께 서포트해야 하는 실무 영역 3가지가 있습니다. 이건 원래 다른 팀이 오너인 일이지만, 기획자가 이 정도는 서포트해주면 훨씬 잘 굴러가요.

1. 과차단(over-refusal) 관리

문지기가 너무 빡세면 멀쩡한 손님도 쫓아냅니다. AI가 정상 질문에도 "죄송해요, 답변드릴 수 없어요"만 반복하면 서비스를 못 쓰게 되죠.

과차단율을 재고 목표치를 관리하는 건 보통 AI Safety 팀과 모델팀이지만, "우리 서비스에서 이 정도 거절은 과해요"라는 현장 감각은 기획자가 제일 잘 압니다. 그래서 기획자는 '위험한 걸 잘 막았나'뿐 아니라 '멀쩡한 걸 잘못 막았나'도 같이 보면서, 커트라인이 서비스 경험에 맞는지 피드백해주면 좋아요.

2. 레드티밍(red-teaming) 지원

일부러 작정하고 뚫으려 공격해보는 일이에요. "이렇게 물어보면 나쁜 답 나오지 않을까?" 하고 해커처럼 두들겨 약점을 찾죠.

실제 공격 시나리오를 설계하고 돌려보는 건 AI Safety 팀이 하지만, 기획자는 "우리 서비스에선 이런 요청이 실제로 들어온다"는 현실적인 공격 시나리오를 보태주면 훨씬 촘촘해져요. 안전팀은 일반적 위험을 잘 알고, 기획자는 우리 서비스 특유의 위험을 잘 아니까요.

3. 재학습 루프 지원

문지기도 직원도 한 번 세우고 끝이 아니에요. 운영하며 뚫린 사례를 모아 계속 다시 훈련시킵니다. "아, 이런 수법에 당했네" 데이터를 업데이트할 수록 더 똑똑해져요.

실제로 데이터를 모아 재학습을 돌리는 건 AI Safety 팀이지만, 기획자는 운영 중 발견한 "이건 꼭 고쳐야 할 사례"를 모아 전달하고, 무엇부터 고칠지 우선순위를 잡아주면 이 뺑뺑이(loop)가 헛돌지 않아요.

그래서, AI 서비스에서는 말리는 것도 기획입니다.

솔직히 골치 아파 보이기도 할 거예요. "안 되는 걸 막는다"는 한 줄이, 파보니 세 겹의 방어와 점수판 해석과 회색지대 정책으로 갈라지니까요.

그런데 이게 바로 AI 서비스 기획이 기존 기획과 갈라지는 지점이에요. 예전엔 '이 버튼을 누르면 이 화면이 뜬다'처럼 정해진 걸 설계했다면, 이제는 뭐든 말할 수 있는 직원(AI)이 선을 넘지 않도록 경계를 긋는 일이 새로 생긴 거죠. 카페로 치면, 메뉴판을 짜는 걸 넘어서 "이런 손님은 어떻게 돌려보낼지"까지 기획자가 정해야 하는 시대가 된 거예요.

때로는 이 일이 골치 아프기보다 재밌다고 생각합니다. 정답이 딱 떨어지지 않으니까요. 자해 커트라인 0.5와 0.9 사이 그 어딘가를 정하는 건, 결국 "우리 서비스가 사용자를 어떻게 대할 것인가"라는 질문에 답하는 일이거든요. 기술은 팀이 붙여주지만, 그 경계선을 어디에 그을지는 우리 서비스를 가장 잘 아는 기획자만 정할 수 있어요. 문지기 모델을 만드는 건 안전팀이어도, 문지기를 어디 세우고 얼마나 예민하게 할지 정하는 건 기획자인 것처럼요.

📮 다음 호 예고

[25호] 기획자를 위한 AI 설계 4부작 ② Tool Use — AI를 '실행'하게 만들기

이번 편에서 AI에 브레이크를 달았다면, 다음 편에선 AI에 손발을 붙여줍니다. 가드레일이 "안 되는 걸 안 하게" 막는 일이었다면, Tool Use는 반대예요. AI가 '말'에서 '실행'으로 넘어가게 만드는 일이거든요.

"내일 3시 회의 잡아줘" 한마디에 AI가 진짜로 캘린더에 일정을 넣으려면, 그 사이에 무슨 일이 벌어질까요? 그리고 그 실행을 설계할 때 기획자는 또 뭘 챙겨야 할까요?

✉️ 다음 호가 궁금하신 분들은 아래 [구독하기] 버튼을 눌러주세요.