16.7.1 Level 1: 수동 검증(Manual Verification) 및 산발적 프롬프트 수정(Ad-hoc Prompting) 단계

16.7.1 Level 1: 수동 검증(Manual Verification) 및 산발적 프롬프트 수정(Ad-hoc Prompting) 단계

오라클 도입 성숙도 모델의 가장 기저이자 바닥에 위치한 **Level 1(무정형 단계, Ad-hoc Phase)**은, 생성형 AI(Generative AI)를 백엔드에 처음 도입하여 PoC(Proof of Concept)를 진행하는 거의 대부분의 비숙련 엔지니어링 조직이 반드시 한 번은 처절하게 겪고 마는 부끄러운 통과의례와도 같다.
이 원시적인 단계에서는 코드로 자동화된 ’결정론적 검증 오라클(Oracle)’이라는 구조적인 파이프라인 개념 자체가 조직 내에 아예 존재하지 않으며, 오직 피곤에 지친 인간 개발자의 주관적인 인지적 주의력(Cognitive Attention)만이 파이프라인의 유일한 품질 통제 수단이자 게이트웨이(Gateway)로 작동한다.

1. 눈대중(Eyeballing) 검증의 처참한 실태

Level 1 조직의 가장 큰 공학적 특징은, 시스템의 무결성을 수학적 테스트 코드가 아닌 인간의 **‘수동적 시각 검증(Manual Visual Inspection, Eyeballing)’**에 극단적이고 맹목적으로 의존한다는 점이다.

  • 개발자나 기획자는 자신이 작성한 프롬프트를 챗봇 웹 UI 프론트엔드나 Jupyter Notebook 환경에서 몇 번 실행해 본 뒤, 화면에 출력되는 자연어 답변을 직접 눈으로 쓱 읽어보고 대충 문맥이 그럴듯한지(Plausibility) 정성적으로 판단하고 릴리즈(Release) 버튼을 누른다.
  • “API가 백엔드에서 요구하는 JSON 형식으로 잘 파싱되어 떨어지는지”, *“교묘한 할루시네이션(Hallucination)이 응답 텍스트에 섞여 있지는 않은지”*를 엣지 케이스까지 검증하는 구체적인 기준 트리는 전혀 문서화되어 있지 않다. 철저히 테스트를 수행하는 당사자 개인의 도메인 지식 깊이와, 심지어 그날의 육체적 컨디션 피로도에 좌우된다.
  • 결과적으로 QA 검증의 기준 기저 시스템이 모델 본연의 비결정성(Nondeterminism)만큼이나 흔들리는 인간의 비결정성이라는 모래성 위에 위태롭게 지어져 있는 최악의 상태다.

2. ’프롬프트 주술(Prompt Voodoo)’의 만연과 기술 부채의 누적

이 1단계에서 운영 중 치명적인 오류(예: 런타임 JSON 파싱 불일치, 엉뚱한 포맷 반환)가 발생했을 때 조직이 그것을 해결하는 방식은 아키텍처적(Architectural) 접근이 아니라 비루한 **언어적 호소(Linguistic Appeal)**에 머문다.

  • 개발자는 시스템에 강제적인 Pydantic 파서(Parser)를 붙이거나 컴파일 수준의 스키마 상태 기계(State Machine)를 도입할 생각은 하지 못한다. 그 대신 프롬프트 문자열의 맨 끝에 “제발 반드시 JSON으로만 말해줘(Please, strictly output in JSON only)”, *“절대 다른 인사말 같은 잔소리는 덧붙이지 마(Do not add any conversational text)”*와 같은 산발적이고 감정적인 수식어(Modifier)를 무작위로 계속해서 덧붙이는 땜질 처방을 한다.
  • 업계에서는 이러한 비공학적 접근법을 조롱 섞어 ‘프롬프트 주술(Prompt Voodoo)’ 혹은 ’프롬프트 의존성(Prompt Dependency)’이라 부른다. 어떤 마법의 영어 단어가 출력 제어에 효과가 있었는지 추적할 에어테이블(Airtable)이나 Git 기반의 버전 관리 체계(Version Control)가 전무하므로, 조직 내의 프롬프트 엔지니어링은 재현 가능한 컴퓨터 과학(Computer Science)이 아니라 샤머니즘적인 미신적 의식(Superstitious Ritual)의 영역에 머물게 된다.

3. 치명적인 침묵의 실패(Silent Failures)와 운영의 위기

Level 1 단계의 위태로운 소프트웨어가 수십만 사용자가 대기하는 라이브 프로덕션 환경(Production)에 배포되는 순간, 조직은 가장 두려워해야 할 재앙적인 **‘침묵의 실패(Silent Failures)’**를 매일 밤 겪게 된다.

  • 전통적인 서버 버그처럼 코드가 다운되며 화려하게 알람을 울리는 명시적 에러(500 Internal Server Error)가 떨어지면 차라리 다행이다. 진짜 끔찍한 문제는, LLM이 은근슬쩍 가짜 환각 데이터를 섞어버리거나 JSON의 필수 키(Key) 값을 제멋대로 누락한 채로 서버에 200 OK 상태 코드를 뻔뻔하게 반환해버리는 경우다. 백엔드 비즈니스 로직은 이를 정상적인 페이로드 데이터로 착각하여 유저의 데이터베이스(DB)에 후속 트랜잭션(Transaction)을 무비판적으로 커밋(Commit)해버리고 데이터를 영구적으로 오염시킨다.
  • 사고가 터지고 고객 클레임이 들어온 뒤에야 엔지니어들이 허겁지겁 서버 로그를 뒤져 프롬프트를 한 줄 수정하는 사후약방문식 땜질 처방(Patchwork)만 무한 반복된다.

이 1단계 수준에 오랫동안 안주하여 머무는 엔지니어링 조직은 B2B AI 애플리케이션의 규모를 절대 확장(Scale-up)할 수 없다. 그들은 가중되는 프롬프트 기술 부채(Technical Debt)의 피로도와 파싱 에러의 무게에 짓눌려 결국 서비스의 아키텍처적 신뢰성(Reliability)을 완전히 상실하고 프로젝트를 폐기하게 된다.
우리가 논의하는 ’결정론적 오라클(Deterministic Oracle)’의 전면적인 파이프라인 도입은, 바로 이 Level 1의 야만적이고 피곤한 비결정성에서 당장 탈출하려는 절박한 공학적 각성(Awakening)에서부터 가장 먼저 출발해야만 한다.