전통적인 소프트웨어 개발 생명주기(SDLC)에서 검증(Validation)은 다른 누군가의 업무였으며 나중에 이루어졌습니다. QA 팀은 소프트웨어가 의도한 대로 작동하는지 확인했습니다. 동작은 재현 가능했기에, 결국 체크 과정을 자동화하고 다음 단계로 넘어갔습니다.

그래서 Slooster를 구축할 때, 저는 어려운 부분부터 먼저 수행했습니다:

• 프롬프트(Prompts)를 구축하고, 튜닝하며, 파라미터와 출력에 대한 스키마(Schemas)를 정의하는 일.
• 프롬프트별로 제공자(Provider), 모델(Model), 온도(Temperature) 및 기타 튜닝 설정(Tuning configs)을 선택하는 시스템을 구축하는 일.

로컬 환경에서는 모든 것이 잘 작동했기에, 저는 검증 레이어(Validation layer)는 나중에 해도 된다고 스스로에게 말했습니다.

불행히도, LLM(대규모 언어 모델)이 방정식에 들어오는 순간 전통적인 SDLC 모델은 무너집니다. LLM은 문맥을 바탕으로 추측하여 출력을 생성한다는 점을 기억하십시오. 의심할 여지 없이 점점 더 나아지고는 있지만, 여전히 추측을 하고 있습니다. 동일한 프롬프트라도 아무것도 바뀌지 않은 상태에서 다음에 다른 답변을 주거나, 심지어 틀린 답변을 줄 수도 있습니다. 따라서 검증은 소프트웨어 자체의 일부가 되어야 합니다.

모델이 루프(Loop) 안에 있을 때는, 첫날부터 아무런 문제 없이 예측 불가능성을 흡수할 수 있는 시스템을 구축해야 합니다.

(예측) 불가능 요소

Slooster Guide를 스테이징(Staging) 환경에 배포한 후, 공동 창업자들에게 데모를 보여주기 전에 한 번 점검했습니다.

몇 주 동안 실제 기준에 부합하는 업체들을 반환해 주었던 바로 그 프롬프트(그리고 모델, 설정들)가, 이번에는 마치 플레이스홀더(Placeholder) 데이터처럼 보이는 결과, 즉 말 그대로 Vendor A, Vendor B, Vendor C라는 단어를 출력했습니다. 다시 생성(Regenerating)하자 이번에는 Vendor D가 섞여 나왔습니다.

로컬에서 몇 주 동안 깨끗한 출력을 제공하던 모델이라도 실제 호출(Real call)에서는 쓰레기(Garbage)를 던져줄 수 있으며, 사전에 수행하는 그 어떤 테스트로도 이를 방지할 수 없습니다. 이것이 배포 전 한 번이 아니라, 모든 실제 출력에 대해 인라인(Inline)으로 검증을 수행해야 하는 이유입니다.

다음에 구축한 레이어

저는 재시도(Retries) 기능이 포함된 검증 레이어를 추가했습니다. 잘못된 출력이 감지되면 호출을 다시 실행합니다. 하지만 재시도는 시간을 소모하며, 사용자가 기다리는 동안 앱은 응답성을 유지해야 합니다.

따라서 검증 (Validation)은 공짜가 아니며, 모든 상황에 일률적으로 적용될 수도 없습니다. 검증을 어디에서 실행할지, 얼마나 강하게 재시도할지, 그리고 사람이 결과를 확인할지 여부는 모두 사용 사례 (Use case)에 따라 달라집니다.

모델이 모델을 검사하게 하기

결정론적 검사 (Deterministic checks)가 가장 먼저 수행됩니다. 스키마 검증기 (Schema validator)는 구조적으로 사양에 맞지 않는 모든 것을 거부합니다. 하지만 "Vendor A"와 같은 자리 표시자 (Placeholder)는 구조적으로는 유효합니다. 스키마 검사를 통과하지만, 여전히 유효한 출력은 아닙니다. 이것은 구조적 (Structural) 오류가 아니라 의미론적 (Semantic) 오류이며, 이를 위해서는 별도의 유형의 검사가 필요합니다.

따라서 마지막 관문은 모델이 모델을 검사하는 것입니다. 즉, 검증 프롬프트 (Validation prompt)가 첫 번째 프롬프트에 주어졌던 것과 동일한 기준을 바탕으로 출력을 판단하는 것입니다.

대략적인 AI 관문 (AI-gate) 프롬프트는 다음과 같습니다:

당신은 사용자가 확인하기 전에 다른 모델의 답변을 검사하고 있습니다.
주어진 작업: [원래의 요청 및 선택 기준].
해당 답변: [검사할 응답].
...

이 관문은 답변을 생성한 것과 동일한 모델에서 실행할 수도 있고, 독립적인 제2의 의견을 얻기 위해 완전히 다른 제공업체(Provider)와 모델에서 실행할 수도 있습니다. 튜닝을 위해 코드 변경이 필요하지 않도록 설정 (Config) 선택 사항으로 만드세요.

세 가지 중요한 핵심 요약:

• 모든 응답이 재시도 비용을 감수해야 하는 것은 아니지만, 그렇다고 모든 응답을 묵인하며 신뢰해서도 안 됩니다.
• 답변에 대한 확신도 (Confidence)를 드러내세요. 사용자가 이를 볼 수 있게 하세요.
• 시나리오에 따라, 사용자가 이의를 제기할 수 있는 명확한 방법을 통해 출력을 보여주고, 그 피드백을 시스템에 즉시 다시 전달하여 다음 시도 시 어떤 기준을 놓쳤는지 알 수 있게 하세요.

모델이 자신의 출력에 대해 마지막 말을 해서는 안 됩니다. 인간을 루프에 포함시키는 것 (Human in the loop)은 기능이지, 나중에 메워야 할 공백이 아닙니다.

같은 질문, 다른 답변

모델은 다음 호출 시 동일한 응답을 주지 않을 것이며, 이는 단순한 캐싱 (Caching)을 함정으로 만들고, 캐싱을 하지 않는 것을 비용이 많이 들게 만듭니다.

해답은 지능적으로 캐싱하는 것입니다:

• 합리적인 경우에 좋은 결과를 재사용하세요.
• 사용자가 새로고침을 원할 때 재생성할 수 있도록 명시적인 제어권을 부여하세요.

지능형 캐싱 (Intelligent caching)은 검증 (Validation) 비용을 상쇄해 주기도 합니다. 안정적인 부분이 캐싱되도록 프롬프트 (Prompt)를 구조화하면, 검증 계층 (Validation layer)에서 발생하는 추가 비용의 상당 부분을 상쇄할 수 있습니다.

모든 프롬프트가 동일하지는 않습니다

모든 프롬프트를 동일하게 취급하면, 결국 비용은 증가하고 성능은 기대에 미치지 못하게 됩니다.

대신, 각 프롬프트 유형에 적합한 제공자 (Provider) 및 모델 (Model)을 매칭하세요:

• 단순한 호출에는 저렴하고 빠른 모델을 사용합니다.
• 답변이 실제로 중요한 경우에는 더 강력한 모델을 사용합니다.
• 검증 게이트 (Validation gate)에는 적절하게 선택된 모델을 사용합니다.

프롬프트별 선택은 성급한 최적화 (Premature optimization)가 아닙니다. 이는 중요한 부분을 검증하면서도 전체 시스템의 응답성을 유지하는 방법입니다.

초석 (The cornerstone)

저는 MVP 이후에 검증을 추가할 계획이었습니다. 하지만 스테이징 (Staging) 단계에서의 충격으로 인해 계획을 앞당기게 되었고, 결과적으로 잘된 일이라고 생각합니다. 그렇지 않았다면 응답에 플레이스홀더 (Placeholder) 데이터가 포함되는 상황을 고려하지 못했을 가능성이 매우 높기 때문입니다.

검증 계층은 트랜스포머 (Transformers), 스키마 (Schemas), 명세 (Specs)와 함께 시스템의 필수적인 부분이며, 제가 다음에 구축할 시스템에서 가장 먼저 시작할 부분입니다.

모델이 작업을 수행할 때, 검증은 단순히 선택적으로 추가하는 계층이 되어서는 안 됩니다. 그것은 당신이 그 위에 구축해야 할 초석이어야 합니다.

다시 말씀드리지만, 여기에 모든 상황에 들어맞는 단 하나의 해결책은 없습니다. AI는 많은 작업을 수행함으로써 당신에게 레버리지 (Leverage)를 제공하지만, 당신은 여전히 주도권을 쥐고 있어야 하며, 미리 생각을 정리하는 것이 그 어느 때보다 중요합니다.

만약 당신이 AI 워크플로 (AI workflows)를 솔루션의 일부로 사용하여 소프트웨어를 구축하고 있으며, 동일한 예측 불가능성으로 고군분투하고 있다면, 기꺼이 저의 경험을 공유하고 당신의 경험에 대해 배우고 싶습니다.