Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
생성형 AI 개발의 성공은 프롬프트 작성 능력보다 훨씬 복잡한 엔지니어링과 데이터 작업에 달려 있습니다. 지식 기반 정리, 평가 데이터셋 구축, 운영 환경에서의 신뢰성 확보가 핵심입니다. 이 80%의 노력이 실제 서비스 품질을 결정합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기지난 봄, 저는 주말 만에 작동하는 생성형 AI(generative AI) 기능을 구축했습니다. 고객의 질문을 읽고, 저희 도움말 문서에서 컨텍스트를 가져와 친절하고 정확한 답변을 작성해주는 지원 비서였습니다. 데모는 아주 성공적이었습니다. 모두 고개를 끄덕였죠.
하지만 실제로 배포하는 데는 세 달이라는 시간이 더 걸렸습니다.
그것은 프롬프트가 잘못되어서가 아니었습니다. 프롬프트 자체는 거의 변하지 않았습니다. 시간은 그 주변의 모든 것에 투입되었습니다: 지식 기반(knowledge base)을 정리하고, 평가 데이터셋(evaluation set)을 구축하며, 모델이 자신 있게 틀린 정보를 만들어내는 경우를 처리하고, 비용이 폭주하는 것을 막고, 그리고 LLM(대규모 언어 모델)에 대해 한 번도 들어본 적 없는 시스템들에 연결하는 작업들이었습니다.
저는 여러 팀이 같은 과정을 거치는 것을 지켜봤고, 대략적인 규칙을 확신하게 되었습니다. 생성형 AI 개발에서 프롬프팅은 약 20%를 차지합니다. 나머지 80%는 데모에서는 절대 보여지지 않는 엔지니어링, 데이터, 운영 작업입니다. 이 80%가 어떤 모습인지 알려드리겠습니다.
데모는 최상의 시나리오 경로입니다. 사용자가 입력값을 선택하고, 모델이 무엇을 잘 처리하는지 알고 있으며, 예상치 못한 질문은 아무도 하지 않습니다. 하지만 실제 운영 환경(Production)은 정반대입니다. 실제 사용자들은 문장 절반만 타이핑하거나, 전체 이메일을 붙여넣거나, 언어를 전환하며, 의도했든 안 했든 엣지 케이스(edge case)를 탐색합니다.
데모와 실제 운영 환경 사이의 격차는 프롬프트 품질의 격차가 아닙니다. 그것은 신뢰성(reliability)의 격차입니다. 10%의 오류가 고객 대면 워크플로우에서는 지원 티켓과 환불로 이어지는, 90%의 정확도를 가진 모델도 무대 위에서는 마법처럼 보이지만 용납할 수 없습니다. 이 격차를 줄이는 것이 과제이며, 그중 대부분은 프롬프팅이 아닙니다.
가장 유용한 생성형 AI 기능들은 사용자의 자체 데이터 위에 놓여 있습니다: 문서, 티켓, 제품 카탈로그, 정책 등. 저희의 경우, 도움말 문서에는 모순되는 기사들과 환불 정책의 세 가지 버전이 포함되어 있었습니다. 모델은 이 세 가지를 모두 기꺼이 검색하여 그 어느 것과도 일치하지 않는 답변을 조합해냈습니다.
그래서 실제 작업은 다음과 같은 모습이었습니다:
검색 품질은 답변 품질의 상한선을 결정합니다. 출력이 나쁘다면, 프롬프트에 손대기 전에 컨텍스트 창(context window)으로 무엇이 들어갔는지 확인하세요.
제가 작업 방식을 바꾼 가장 큰 변화는 평가를 최우선 산출물로 취급한 것입니다. 평가 세트(eval set)가 없다면, 모든 변경 사항은 감각적인 테스트에 불과합니다. 프롬프트를 조정하고, 예시 5개를 시도해보고 배포합니다. 그런데 2주 후에 개선된 부분이 질문의 전체 카테고리를 망가뜨렸다는 것을 발견할 수 있고, 언제 그랬는지 알 길이 없습니다.
기본적인 설정은 화려할 필요가 없습니다:
가능하다면 유효 JSON 형식, 필수 필드 존재 여부, 또는 인용 출처의 존재와 같은 자동화된 검사를 사용하고, 불가능할 경우 모델 기반 또는 인간 평가를 활용하세요. 모델 평가는 자체적인 편향을 가지고 있으므로, 인간의 판단과 비교하여 샘플 점검(spot-check)해야 합니다.
그 보상은 자신감입니다. 모델을 교체하거나 검색 전략을 변경해도 몇 분 안에 상황이 개선되었는지 악화되었는지를 알 수 있습니다.
모든 생성형 AI 시스템은 결국 잘못되거나, 브랜드와 맞지 않거나, 안전하지 않은 결과물을 만들어낼 것입니다. 중요한 것은 그 다음의 대응입니다. 여러 계층에서 실패에 대비해야 합니다.:
시스템이 모를 때 무엇을 하는지가 종종 가장 중요한 설계 결정입니다. 불확실성을 인정하는 기능이 유창하지만 잘못된 것보다 더 많은 신뢰를 얻습니다.
데모에서는 아무도 청구서를 확인하지 않습니다. 하지만 실제 운영 환경(production)에서는 토큰이 항목별 비용(line item)이며, 지연 시간은 사용자 경험(UX) 측정 기준입니다. 저희의 첫 달 API 사용료는 컨텍스트 윈도우가 과도하게 크고, 타임아웃 시 재시도를 하며, 작은 모델로 충분한 작업을 가장 큰 모델을 사용하여 처리했기 때문에 예상치보다 약 세 배나 높았습니다.
효율성을 개선한 요소:
정확하지만 운영 비용 때문에 실행할 수 없는 기능은 여전히 실패한 기능입니다.
전통적인 모니터링 시스템은 서비스가 작동하는지 여부만 알려줍니다. 답변이 좋은지는 알려주지 않습니다. 모든 요청에 대해 프롬프트, 검색된 컨텍스트, 출력, 모델 버전, 지연 시간 및 비용을 합리적인 개인 정보 보호 처리를 거쳐 기록해야 합니다. 또한 엄지손가락 위/아래 표시(thumbs up and down), 에스컬레이션(escalations), 그리고 첫 답변에서 놓친 부분을 시사하는 후속 질문과 같은 피드백 신호를 추가합니다.
매주 실제 대화 샘플을 읽어보세요. 이는 현재의 평가 세트(eval set)가 아직 다루지 못하는 실패 패턴을 찾는 가장 빠른 방법이며, 발견된 모든 사례는 다시 평가 세트에 반영되어야 합니다. 관찰(observe)하고, 평가 데이터에 추가하며(add to evals), 개선하고(improve), 재배포하는(redeploy) 이 순환 고리가 바로 품질의 진정한 엔진입니다.
모델 호출은 하나의 API 요청일 뿐입니다. 그 주변 시스템에는 인증(authentication), 권한(permissions), 속도 제한(rate limits), 큐(queues), 기존 데이터베이스, 그리고 규정 준수(compliance) 문제가 포함됩니다. 사소해 보이는 질문들이 몇 주일을 잡아먹을 수 있습니다. 모델은 어떤 사용자의 데이터를 볼 수 있습니까? 대화는 어디에 얼마나 오랫동안 저장됩니까? 제공업체 서비스 중단 시에는 무슨 일이 발생합니까?
이 지점에서 팀들은 모든 것을 직접 구축할지 아니면 전문가의 도움을 받을지를 결정합니다. 만약 워크플로우가 특이하거나, 데이터가 민감하거나, 기능이 여러 내부 시스템에 연결되어야 한다면, 맞춤형 생성형 AI 개발 서비스를 이용하는 것이 몇 달의 시간을 절약해 줄 수 있습니다. 이미 검색 파이프라인(retrieval pipelines), 평가 하네스(eval harnesses), 가드레일(guardrails)을 구축한 팀은 귀사의 예산으로 이러한 교훈들을 다시 배울 필요가 없기 때문입니다.
표준 사용 사례의 경우, 기성 도구만으로도 충분할 수 있습니다. 솔직히 말하자면, 요구사항이 얼마나 구체적인지 그리고 80% 중 어느 정도를 직접 소유하고 싶은지에 따라 달라집니다.
수정하는 데 가장 저렴한 실수는 종이에 그린 실수입니다. 많은 실패 프로젝트들이 공통된 근본 원인을 가지고 있습니다. 바로 '누구도 첫 줄의 코드를 작성하기 전에 성공을 정의하지 않았다'는 것입니다. 구축에 앞서 다음 질문들에 답하십시오:
이것이 바로 AI consulting의 가치가 제대로 발휘되는 지점입니다. 좋은 컨설턴트가 내놓는 가장 가치 있는 결과물은 때로는 더 작은 범위, 다른 접근 방식, 또는 명확한 '아직 아님(not yet)'일 수 있습니다. 외부 도움을 받든 내부적으로 진행하든, 누가 실행하는지보다 그 규율과 체계가 훨씬 중요합니다.
Prompting은 생성형 AI 개발의 눈에 보이는 부분이기 때문에 많은 주목을 받습니다. 하지만 신뢰할 수 있는 기능을 출시하는 팀들은 가장 기발한 프롬프트를 가진 팀이 거의 아닙니다. 그들은 모델을 데이터 품질, 테스트, 안전장치(safety nets), 비용 통제, 모니터링이 필요한 시스템의 하나의 구성 요소로 취급합니다.
좋은 소식은 이것이 익숙한 영역이라는 것입니다. 이는 확률적 구성 요소에 적용된 소프트웨어 엔지니어링입니다. 이전에 프로덕션 시스템을 출시해 본 경험이 있다면, 이미 대부분의 기술을 갖추고 있다는 의미입니다.
당신의 80%는 어떤 모습인가요? 팀에게 가장 놀라웠던 부분은 평가(evals), 데이터, 비용 중 어느 것이었나요? 제가 다루지 않은 다른 부분이 있었나요? 댓글로 알려주세요.
생성형 AI 개발은 AI 모델, 데이터, 통합(integrations), 그리고 평가 시스템을 사용하여 콘텐츠를 생성하고, 질문에 답하며, 작업을 수행하는 AI 애플리케이션을 구축하는 것을 의미합니다.
프롬프팅(Prompting)은 모델의 동작을 안내하지만, 상용화된 AI를 구현하기 위해서는 데이터 준비(data preparation), 평가(evaluation), 가드레일(guardrails), 비용 최적화(cost optimization), 모니터링(monitoring), 보안(security), 그리고 기존 시스템과의 통합(integration with existing systems)이 추가로 필요합니다.
소스 데이터를 정제하고, 강력한 검색 방법론(robust retrieval methods)을 사용하며, 견고한 평가 데이터셋(eval datasets)을 구축하고, 출력을 검증하며, 엣지 케이스(edge cases)를 테스트하고, 불확실한 응답은 사람에게 전달하는 방식으로 정확도를 개선할 수 있습니다.
주요 문제점으로는 신뢰할 수 없는 출력(unreliable outputs), 낮은 데이터 품질, 프롬프트 인젝션(prompt injection), 높은 API 비용, 느린 응답 시간, 개인 정보 보호 문제, 그리고 기존 비즈니스 시스템과의 통합 등이 있습니다.
기업들은 명확하고 측정 가능한 성공 기준(success criteria)을 정의하고, 모든 변경 사항을 평가 데이터셋에 대해 테스트하며, 가드레일과 폴백(fallbacks)을 구현하고, 실제 대화를 모니터링하며, 매우 구체적인 사용 사례부터 시작함으로써 신뢰도를 높일 수 있습니다.