얼마 전, 일종의 바이브 코딩을 사용한 데모를 할 일이 있었다. AI의 시대에 많은 것이 변했지만 그 중에 변하지 않는 몇 가지 것들이 있으니 그 중의 하나가 데모의 법칙이다. 역시 이번에도 집에서 테스트할 때는 뱉지 않던 새로운 오류를 뱉었다. 그래서 기존에 미리 준비해 온 화면을 띄웠지만, 애초에 UI부터 (지정하지 않은 부분은) 모두 다 달랐다. 물론 여러 번 사전 테스트를 거쳤고 LLM의 특성을 알고 있기 때문에 놀라운 일은 아니었으나, 이와 관련해서 여러 고민이 있을 수밖에 없다는 사실 역시 이미 알고 있었고, 이를 새삼 체감할 수 있었다.
생성형 AI를 활용해서 프로그래밍을 하는 것이 매우 용이해졌고, 이로 만든 결과물이 매우 훌륭할 때면 정말 이렇게 AI가 위대할 수 없다. 하지만 이를 활용하기 위해 며칠 뒤, 정확히 동일한 프롬프트를 다시 입력했을 때 돌아오는 것은 전혀 다른 결과물인 경우가 비일비재하다.
이 현상은 LLM의 가장 근본적인 특징인 비결정성(Non-determinism)에서 비롯된다. 즉, 동일한 입력에 대해서도 AI는 다른 출력을 생성할 수 있고, 많은 경우 그렇다. 이는 생성형 AI가 단순한 계산기가 아니라 확률에 기반한 결과를 내며, 이로 인해 LLM의 말이 좀 더 ‘사람같다’라고 느껴지는 데 한 몫 하기도 한다. 하지만 비즈니스 환경에서 어떤 결과물을 낼 때 이를 사용한다면 ‘일관성’과 ‘신뢰성’을 포기할 수는 없다.
따라서 생성형 AI를 업무에서 제대로 활용하기 위해서는 활용 방안에 대해서 좀 더 전략적으로 접근해야 한다. LLM은 기본적으로 프롬프트 기반으로 동작하므로, 이 프롬프트를 일회성으로 쓰고 버리는 질문지가 아니라, 버전 관리가 가능한 지속적인 전략적 자산으로 다루고 관리하는 것이 필요하다. 프롬프트를 새로운 시대의 일종의 기획서나 소프트웨어 설계 명세서로 활용하는 것이다. AI의 확률적 비결정성 세계에서 최대한 일관되고 높은 품질의 결과는 우리가 던지는 ‘질문’의 수준과 그것을 관리하는 ‘체계’의 엄격함에 달려 있다고 해도 과언이 아니다.
확률과 샘플링: 비결정성의 기본 기술
LLM은 규칙 기반의 결정론적 시스템이 아니라, 방대한 훈련 데이터에서 학습한 패턴을 바탕으로 다음에 올 가장 가능성 높은 토큰(단어 또는 단어의 일부)을 예측하는 확률 시스템입니다. 이 과정에서 주로 사용되는 기초 기술을 몇 개만 살펴보면 다음과 같다.
- 로짓(Logits): 모델이 특정 단어 다음에 올 수 있는 모든 후보 토큰에 대해 계산하는 원시 점수
- 소프트맥스(Softmax) 함수: 이 로짓 점수들을 합이 1이 되는 확률 분포로 변환하는 함수. 즉, 각 후보 토큰이 다음에 올 확률을 나타냄.
- 샘플링(Sampling): 변환된 확률 분포에 따라 다음 토큰을 ‘선택’하는 과정
- 온도(Temperature) 매개변tn: 이 샘플링 과정의 무작위성을 제어하는 장치. temperature를 0으로 설정하면 모델은 항상 가장 확률이 높은 토큰을 선택하게 되어(Greedy Sampling) 결정론에 가까운 결과를 내게 됨. 다만 병렬 처리, 다양한 모델 아키텍처 등으로 인해 완벽하게 결정론적인 결과를 내지 않으며, temperature를 높이면 모델은 더 낮은 확률의 토큰도 선택지에 포함시켜 더 창의적이고 다양한 결과를 생성함
이런 과정 등으로 발생하는 비결정성은 책임이 따르는 결과물을 만들어야 할 때는 여러 가지로 문제가 될 수 있다. 5개의 주요 LLM을 대상으로 한 연구에 따르면, 결정론적으로 가정된 설정 하에서도 동일한 프롬프트를 반복 실행했을 때 정확도가 최대 15%까지 차이가 나는 것으로 나타났다. 이는 시스템 신뢰성에 중대한 영향을 미칠 수 있다.
이는 결국 ‘재현성 위기(Reproducibility Crisis)’와 맞닿아 있다. 과학의 다른 분야와 마찬가지로 AI 연구에서도 다른 연구자가 발표한 결과를 동일하게 재현하기 어려운 문제가 심각하게 대두되고 있다. 결과의 재현 불가능성은 과학적 검증을 약화시키고, 관련된 정책이나 시스템을 만들기 어렵게 하며, 비즈니스 환경에서 AI를 핵심 기능에 활용할 때 여러가지 위험성이 나타날 수 있다.
우선적으로, LLM을 사용할 때 있어서 완벽한 결과 복제는 불가능에 가까울 수 있지만, 일관된 의도와 품질의 달성 정도는 고려해야 한다. 우리는 생성되는 토큰의 정확한 순서를 통제할 수는 없지만, 생성을 이끄는 논리적 과정과 제약 조건을 통제하기 위해 노력할 수는 있으며, LLM을 제대로 다양한 곳에 도입하기 위해서는 반드시 그렇게 해야 한다. 많은 AI 관련된 문제와 마찬가지로, 프롬프트와 결과물에 대한 비결정성 문제도, AI에서 나타나는 문제로 인해 기술적으로 좌절하거나 무조건적으로 이에 끼워맞추는 대신, 이를 극복할 수 있는 전략적이고 프로세스 지향적인 해결책을 세우는 것이 보다 실용적일 것이다.
비결정성이라는 LLM의 본질을 이해했다면, 이제 우리의 접근 방식을 근본적으로 바꿔야 한다. 일회성 질문을 던지고 결과를 가져오는 것을 넘어서서, 프롬프트를 ‘코드처럼(Prompt as Code)’ 혹은 ‘기획서처럼(Prompt as Proposal)’ 다루는 새로운 개념이 필요하다. 이는 단순히 프롬프트를 저장하는 것을 넘어, 프롬프트를 구조적으로 작성하고 이를 체계적인 프로세스로 관리하는 것을 말한다.
프롬프트를 코드처럼 (Prompt as Code)
이 관점에서는 프롬프트를 코드와 마찬가지로 진화하고 관리되어야 할 대상으로 다룬다. 이 접근 방식의 주요 개념은 다음과 같다.
버전 관리(Version Control): 모든 프롬프트는 Git과 같은 버전 관리 시스템이나 최소한 위키 등 버전 관리가 가능한 문서 시스템 등에 저장한다. “고객 상담 챗봇 v2.1”과 같이 명확한 버전 기록을 통해 어떤 변경이 있었고, 그 이유는 무엇이며, 성능에 어떤 영향을 미쳤는지 추적할 수 있도록 해야 한다. 문제가 발생했을 때 이전 버전으로 즉시 롤백할 수 있도록 하는 것이 필요하다.
문서화(Documentation): 각 버전의 프롬프트는 그 자체로 하나의 자산이다. 프롬프트의 목적, 관련 사용자, 기대하는 출력 형식, 그리고 관련 성능 지표(예: 응답 정확도, 사용자 만족도)가 명확하게 문서화될 수 있어야 한다. 프롬프트가 그저 일회성 텍스트 문자열이 아닌 재사용 가능하고 이해하기 쉬운 조직의 지식 자산이 되도록 해야 한다.
테스트와 검증(Testing and Validation): 프롬프트 변경이 그저 ‘기분’에 따라 이루어지면 안 된다. 코드 변경과 마찬가지로, 프롬프트 수정이 관련된 제품이나 기능의 품질, 지연 시간(latency), 비용에 미치는 영향을 검증하기 위한 체계적인 테스트 프로세스가 같이 고려되어야 한다. 단위 테스트, A/B 테스트 등의 결과를 통해 최적의 프롬프트를 선별하고 이의 구성 요소를 분석해야 한다.
프롬프트를 기획서처럼 (Prompt as Proposal)
이 관점에서는 프롬프트를 기술적 산출물이 아닌, 여러 이해관계자의 합의와 협업이 필요한 전략적 문서로 다룬다. 특히 사용자 대면 서비스나 브랜드의 목소리를 대변하는 AI에 적용될 때 도움이 될 방식으로, 주요 개념은 다음과 같다.
협업과 합의(Collaboration and Consensus): 모든 프롬프트는 개인이 단독으로 결정하는 것이 아니라, 기획, 마케팅, 법무, 브랜드 등 다양한 팀과의 협업을 통해 만들어진다. Git의 커밋 기록 뿐만이 아니라 워크숍, 공유 문서, 그리고 최종적인 이해 관계자들의 합의 내용 등이 해당 프롬프트에 포함된다. 이는 프롬프트가 기술적 최적화를 넘어 비즈니스 목표와 제품의 정체성을 최대한 반영할 수 있도록 한다.
제안서/기획서(The Proposal Document): 각 프롬프트는 그 목적과 배경을 담은 제안서/기획서 형태로 문서화된다. 이 문서에는 단순한 입출력 명세 외에 비즈니스 목표, 타겟 사용자 페르소나, AI의 어조와 매너(Tone and Manner), 브랜드 가이드라인 준수 여부, KPI (고객 만족도, 전환율) 등이 포함된다. 프롬프트를 조직의 전략적 의사결정 자산으로 관리하는 것이다.
가설 기반 정성적 평가(Hypothesis-Driven Qualitative Evaluation): 프롬프트 변경은 ‘성능 개선’을 넘어 ‘비즈니스 가설’을 검증하는 과정으로 간주된다. 프롬프트로 생성된 결과를 마케팅, 법무팀, UX 등 다양한 분야에서 각각의 방법론으로 적합도 평가를 한 후 정량적 척도와 정성적 척도를 병합적으로 활용하고 이를 프롬프트와 함께 기록할 수 있도록 한다.
이런 접근방식을 통해 단순히 LLM의 비결정성에 대응하는 것을 넘어, LLM을 업무에 적극적으로 활용할 때 발생할 수 있는 다양한 문제들의 해결책으로도 활용할 수 있다. 예를 들어, 간혹 모델에서 업데이트 되기 전의 라이브러리를 추천한다거나, 갑자기 전혀 다른 프레임워크를 코드에 적용하는 경우가 발생한다고 할 때, 잘 설계된 프롬프트에서는 이에 대한 제약조건을 명시하고 그 조건을 지속적으로 관리할 수 있다. 또한 다양한 직군이 AI의 결과물을 이해하고 이 과정에서 어떤 부분이 잘못되었는지를 다양한 관점에서 직관적으로 이해하고, 이를 수정하고 제품에 반영함에 있어서 도움이 될 수 있다. 또한 기본적으로 ‘블랙박스’를 통해 나온 AI의 결과물을 최대한 추적 가능한 문제로 전환할 수 있다.
생성형 AI의 비결정성은 그 자체로 고유의 특성이므로, 우리가 AI와 상호작용하는 방식을 기존의 명확한 입출력 방식에서 새롭게 재정의할 수 있어야 한다. 프롬프트를 일종의 ‘코드’처럼 다루어 기술적 견고함과 재현성을 확보하고, ‘기획서’처럼 고려하여 비즈니스 전략과 조직의 목소리를 일관되게 담아내는 접근 방식은 비결정성이 보여주는 불확실성을 보다 안정적으로 활용할 수 있게 해주는 방안이 될 것이다. AI가 수많은 일상과 업무에 성큼 다가온 오늘 에 있어 우리는 AI에게 일회성 정답을 구하는 사용자를 넘어, AI와의 지속적인 대화를 설계하고 그 결과의 품질을 책임질 줄 알아야 이를 지속적으로 더 폭 넓게 사용할 수 있다. 성공적인 AI 도입의 미래는 모델의 성능에만 달려 있는 것이 아니라, 이처럼 체계적이고 전략적인 프롬프트 관리 역량에 달려있을 것이다.
좀 더 구체적인 예제와 이럴 때 질문 자체를 어떻게 잘 작성하고 구조화해야 하는 지에 대해서는 다음 번에 이어서 이야기해 보도록 하겠습니다. (글이 길어져서…)
이 글은 연재글 다시 쓰기 프로젝트의 일환으로 쓰게 된 글로 이 글을 다시 쓰기 한 것이지만, 사실 요즘의 나의 학습 주제와도 맞닿아 있어서 글이 길어지게 되었다.
현재 개인적으로 프롬프트를 기업에서 적극적으로 활용하면서 LLM이나 AI를 어떤 식으로 잘 사용할 수 있을지와 어떤 부분에 있어서 우려되는 부분이 있는지, 기업의 데이터를 여기에 어떤 식으로 잘 적용해서 활용할 수 있는지에 대해서 다양한 고민을 하고 있고 최소한 간단한 백서 정도라도 만들어볼 계획이 있다. 이에 대해서 다양한 의견을 공유해주셔도 좋고, 관심 있으신 분들의 이야기도 기다리고 있습니다.