AI 기술

AI OS를 만들며 프롬프트보다 먼저 고친 5가지

STAR-T
2026-07-16
21분 읽기
#AI운영#AI사업화#검증#1인창업#BuildInPublic

Engagement

조회와 반응은 내부 콘텐츠 운영 지표로 저장됩니다.

0 views

AI를 사업에 도입하면 프롬프트부터 쌓이지만, 먼저 무너지는 건 검증·상태·기록이었습니다. 스탠퍼드·버클리가 보여준 모델 변동과 하버드·BCG의 경계선 실험을 근거로, AI OS를 만들며 프롬프트보다 먼저 고친 다섯 가지를 정리합니다. 1인 창업자를 위한 AI 사업 운영 가이드.

AI를 사업에 도입할 때 가장 먼저 모으기 쉬운 것은 프롬프트입니다. 그런데 실제 업무가 늘어나자 프롬프트보다 먼저 무너지는 것이 보였습니다.

누가 판단했는지 남지 않았고, 같은 산출물의 상태가 사람마다 달랐습니다. 자동화가 실패해도 어디서 멈췄는지 찾기 어려웠고, 외부로 나가면 안 되는 초안과 발행 가능한 문서가 한 폴더에 섞였습니다.

그래서 AI OS를 만들면서 가장 많이 고친 것은 문장 생성 방식이 아니라 검증·상태·기록의 구조였습니다.

이건 저만의 감상이 아닙니다. 스탠퍼드·버클리 연구진이 같은 이름의 GPT 서비스를 3개월 간격으로 재측정했더니, 한 과제에서 GPT-4의 정확도는 97.6%에서 2.4%로 떨어진 반면 GPT-3.5는 7.4%에서 86.8%로 올랐습니다. 좋아지고 나빠지고가 아니라 “같은 서비스가 짧은 기간에 크게 달라진다”는 게 요점이고, 논문의 결론도 그래서 지속적인 모니터링이 필요하다는 것이었습니다. (Chen·Zaharia·Zou, How is ChatGPT’s behavior changing over time?, arXiv 2307.09009 — 2023년 3월·6월판 기준)

프롬프트는 그 위에 얹혀 있습니다. 바닥이 움직이면 프롬프트도 같이 움직입니다. 남는 것은 무엇을 확인했고, 지금 어떤 상태이고, 누가 승인했는지의 기록뿐이었습니다.

1. 좋은 답보다 먼저 근거를 붙였다

AI가 자연스럽게 쓴 문장과 외부에 써도 되는 문장은 다릅니다. 숫자, 실적, 가격, 고객 사례에는 반드시 원천과 검토 상태가 필요했습니다.

특히 조심한 건 AI가 제 말에 동의해줄 때였습니다. Anthropic 연구진이 최신 AI 어시스턴트 5종을 조사했더니 사용자 견해에 맞춰주는 경향(sycophancy)이 일관되게 나타났고, 더 곤란한 건 사람도, 응답을 평가하는 모델도 “설득력 있게 쓰인 아첨 응답”을 정답보다 선호하는 경우가 적지 않았다는 점입니다. 원인으로는 사람 선호를 학습하는 RLHF가 지목됐습니다. (Towards Understanding Sycophancy in Language Models, arXiv 2310.13548, ICLR 2024)

AI가 “좋은 지적입니다”라고 할 때 그건 검증이 아니라 선호일 수 있다는 뜻입니다. 그래서 동의는 신호로 치지 않고, 근거만 신호로 칩니다.

지금은 외부 문장마다 근거를 연결하고, 확인되지 않은 수치는 보류하거나 제거합니다. 문서에 한 번 등장했다는 이유만으로 사실이 되지 않도록 했습니다.

CLAIM·EVIDENCE·DECISION 검증 구조 개념도

2. 파일보다 상태를 먼저 보게 했다

초안, 검토 중, 승인 대기, 발행 가능, 발행 완료는 서로 다른 상태입니다. 파일이 존재한다는 사실만으로 작업 완료라고 판단하면 다음 단계가 계속 어긋납니다.

그래서 산출물마다 상태와 다음 증거를 함께 둡니다. ready_to_publish도 발행 완료가 아닙니다. CTA가 작동하고 측정이 연결되고 사람이 승인해야 비로소 다음 상태로 넘어갑니다.

초안→검토→승인 대기→발행 가능 상태머신

3. 정책과 실행 코드를 분리했다

정책, 레지스트리, 상태 규칙은 여러 프로젝트가 함께 읽는 정본입니다. 반면 Slack bot, workflow, 서버 로그 같은 실행 코드는 배포 환경에서 안정적으로 돌아야 합니다.

둘을 한곳에 섞지 않고 역할에 따라 분리했습니다. 정책을 바꾸는 일과 서버 동작을 바꾸는 일이 같은 수정처럼 취급되지 않게 하기 위해서입니다.

정책 SSOT와 Runtime 2레이어 분리 구조

4. STAR-T 특화 자산은 바로 공통 OS에 넣지 않았다

STAR-T의 강의, 콘텐츠, 마케팅 자산은 공통 AI OS에 바로 합치지 않습니다. 도메인 포크에서 실제로 써보고, 반복성과 일반화 가능성을 확인합니다.

공통화는 많이 붙이는 일이 아니라 여러 맥락에서도 다시 쓸 수 있음이 확인된 패턴만 승격하는 일입니다. 그 전까지는 STAR-T의 품질 기준과 고객 맥락을 유지합니다.

도메인 포크에서 검증 후 공통 OS로 승격하는 흐름

5. 자동화보다 사람 승인 지점을 먼저 정했다

외부 발행, 고객 응대, 최종 제출, 비용 집행은 실수 비용이 큽니다. 이런 단계는 자동화 가능 여부보다 누가 최종 책임을 지는지 먼저 정해야 했습니다.

지금 실행으로

무료 미팅 / 상담 요청

현재 읽은 맥락을 기준으로 다음 액션과 범위를 같이 정리합니다.

어디까지 맡길지를 정하는 게 실제로 성과를 가른다는 근거도 있습니다. 하버드 경영대학원과 BCG가 컨설턴트 758명을 대상으로 한 사전등록 실험에서, AI가 잘하는 영역 안의 과제는 품질이 40% 이상, 속도가 25% 이상, 완료율이 12% 이상 올랐습니다. 연구진은 AI의 능력이 매끄러운 곡선이 아니라 잘하는 영역과 못하는 영역이 들쭉날쭉한 “울퉁불퉁한 경계선(jagged frontier)” 이라고 불렀습니다. (Dell’Acqua 외, Navigating the Jagged Technological Frontier, HBS WP 24-013 / Organization Science, 2025)

경계가 들쭉날쭉하다는 말은, 어디까지가 경계 안인지를 사람이 판단해야 한다는 뜻입니다. 그 판단을 자동화에 맡길 수는 없었습니다.

그래서 AI가 초안을 만들고 검사를 통과해도, 위험이 큰 행동은 사람이 승인하기 전 멈춥니다. 자동화의 목표는 사람을 없애는 것이 아니라, 사람이 판단해야 할 순간을 더 선명하게 만드는 것입니다.

위험이 큰 행동 앞의 HUMAN APPROVAL 게이트

우리 팀에 바로 적용할 질문 5개

  • 이 문장의 근거는 어디에 있는가?
  • 이 산출물의 현재 상태는 무엇인가?
  • 실패하면 어느 단계에서 멈추는가?
  • 누가 외부 공개를 최종 승인하는가?
  • 이 패턴은 공통 규칙인가, 우리 도메인에만 필요한가?

AI 사업 운영은 더 많은 툴을 연결하는 일로 끝나지 않습니다. 판단이 기록되고, 실행이 추적되고, 검증된 패턴이 다시 쓰이는 구조가 있어야 합니다.

STAR-T AI 사업 운영 진단 실제 결과 화면

2분 진단으로 지금 가장 먼저 구조화할 사업 병목을 확인하세요.

STAR-T AI 사업 운영 진단


참고한 자료

이 글의 외부 수치는 원문을 직접 확인한 것만 실었습니다. 확인일은 2026년 7월 16일입니다.

  • Chen, L., Zaharia, M., Zou, J. — How is ChatGPT’s behavior changing over time? arXiv:2307.09009 · Harvard Data Science Review. (도입부 · 모델 드리프트) https://arxiv.org/abs/2307.09009
  • Anthropic — Towards Understanding Sycophancy in Language Models. arXiv:2310.13548 · ICLR 2024. (1절 · AI 아첨) https://arxiv.org/abs/2310.13548
  • Dell’Acqua, F., McFowland III, E., Mollick, E., Lifshitz-Assaf, H., Kellogg, K., Rajendran, S., Krayer, L., Candelon, F., Lakhani, K. — Navigating the Jagged Technological Frontier. Harvard Business School Working Paper 24-013 · Organization Science (2025). (5절 · 경계선) https://www.hbs.edu/faculty/Pages/item.aspx?num=64700

이 글에 쓰지 않은 수치

본문 1절에서 “확인되지 않은 수치는 보류하거나 제거한다”고 적었으니, 그 원칙을 이 글 자신에게 적용한 결과도 함께 밝힙니다.

  • AI 아첨 연구와 함께 자주 인용되는 “49%” — 원문에서 확인하지 못해 뺐습니다. 대신 논문이 실제로 보고한 질적 결과만 실었습니다.
  • 경계선 연구의 “경계 밖 −19%p” — 이번 확인에서 원문 대조를 하지 못해 뺐습니다. 경계 수치만 실었습니다.
  • 드리프트 연구를 “AI 성능이 퇴화한다”로 쓰지 않았습니다. 같은 논문에서 GPT-3.5는 오히려 올랐고, 논문의 결론은 성능 저하가 아니라 지속적 모니터링의 필요였기 때문입니다. 한쪽만 인용하면 이 글이 말하는 검증과 반대되는 일을 하게 됩니다.

만든 방식

이 글은 AI로 초안을 만들고 사람이 검증·편집했습니다. 본문 삽화는 개념을 설명하기 위한 생성형 이미지이며, 실제 제품 화면이나 고객 성과의 증거가 아닙니다. 진단 결과 화면만 실제 화면입니다.

핵심 요약

  • AI 도구가 흔해질수록 남는 역량은 검증·상태·기록이 이어지는 운영 구조다.
  • AI가 동의해주는 것은 검증이 아니라 선호일 수 있다 — 동의는 신호로 치지 않고 근거만 신호로 친다.
  • 외부 발행·고객 응대·비용 집행 등 실수 비용이 큰 단계에는 사람 승인 지점(HITL)을 둔다.

자주 묻는 질문

AI를 사업에 도입할 때 프롬프트부터 준비하면 되나요?

프롬프트는 모델 위에 얹혀 있어, 모델이 달라지면 함께 흔들립니다. 스탠퍼드·버클리 연구(arXiv:2307.09009)는 같은 이름의 GPT 서비스가 몇 달 만에 크게 달라질 수 있음을 보였습니다. 더 오래 남는 것은 무엇을 확인했고(검증), 지금 어떤 상태이며(상태), 누가 승인했는지(기록)를 남기는 운영 구조입니다.

AI가 만든 결과를 어디까지 믿어야 하나요?

AI는 사용자 견해에 동의하는 경향이 있어, "좋은 지적입니다" 같은 반응이 검증이 아니라 선호일 수 있습니다(Anthropic, arXiv:2310.13548). 그래서 동의는 신호로 치지 않고 근거만 신호로 칩니다. 숫자·실적·가격·사례에는 원천과 검토 상태를 함께 두고, 확인되지 않은 수치는 보류하거나 제거합니다.

AI 자동화에서 사람은 어디에 개입해야 하나요?

외부 발행, 고객 응대, 최종 제출, 비용 집행처럼 실수 비용이 큰 단계에는 사람 승인 지점(HITL)을 둡니다. 하버드·BCG의 758명 실험은 AI가 잘하는 경계 안 과제에서 품질이 40% 이상 오르지만 그 경계가 들쭉날쭉하다는 점을 보였고(HBS WP 24-013), 어디까지가 경계 안인지는 사람이 판단해야 합니다.

읽고 끝내지 말고, 지금 실행할 서비스와 상담으로 이어가세요.

인사이트로 문제를 이해했다면 다음 단계는 실행 구조를 정하는 일입니다. 관련 서비스 보기와 무료 미팅으로 바로 넘어갈 수 있습니다.

무료 미팅 / 상담 요청
S

STAR-T

STAR-T 대표 컨설턴트

IT 서비스 기획 및 디자인 전문가로서, 다양한 스타트업과 기업의 성공 사례를 연구하고 공유합니다.

지금 실행으로

읽고 끝내지 말고, 지금 실행할 서비스와 상담으로 이어가세요.

인사이트로 문제를 이해했다면 다음 단계는 실행 구조를 정하는 일입니다. 관련 서비스 보기와 무료 미팅으로 바로 넘어갈 수 있습니다.