같은 프롬프트, 다른 윤리: 프레임워크 AI 모델이 윤리적 딜레마에서 어떻게 분화되는가

이 벤치마크는 100개의 일상적 윤리 시나리오(영업 데이터 오용, 종양학 프로토콜 위반 등)를 프론티어 LLM에 동일한 프롬프트로 입력하고, 각 모델이 어떤 판단·거부·우회 응답을 내놓는지 비교하는 방식으로 설계되었다. 기술적으로는 모델별 응답을 윤리적 기준(예: 의무론, 결과주의, 직업윤리 코드)에 따라 라벨링하고, 동의/거부/조건부 수용 등의 분포를 정량화한다. 모델 간 차이가 발생하는 핵심 원인은 RLHF(Reinforcement Learning from Human Feedback) 단계에서 사용된 휴먼 피드백 풀의 문화·직군 편향, Constitutional AI에 주입된 헌법 조항의 선택, 그리고 시스템 프롬프트와 안전 분류기(safety classifier)의 임계값 설정에 있다. 즉 같은 입력이라도 OpenAI, Anthropic, Google, Meta가 각기 다른 "도덕적 기본값(moral default)"을 모델 가중치와 가드레일에 새겨 넣었기 때문에, 동일 시나리오에서 한 모델은 거부하고 다른 모델은 수행하는 분기가 발생한다.

개발자 관점에서 이 결과는 단순한 학술적 호기심이 아니라 실무에 직접적인 리스크로 작용한다. 멀티 LLM 라우팅 아키텍처(예: 비용 절감을 위해 Haiku와 GPT-4o-mini를 병행 사용하는 구조)에서는 동일 사용자 요청이 라우팅된 모델에 따라 전혀 다른 응답을 반환할 수 있어, 의료·금융·법률 SaaS의 응답 일관성과 컴플라이언스가 무너질 수 있다. 또한 AI 에이전트가 도구 호출(tool calling)로 실제 액션을 수행하는 시점에서는 "거부했어야 할 작업을 수행한 모델"이 실제 데이터 삭제, 외부 API 호출, 결제 등 비가역적 부작용을 일으킬 수 있다. 한국 개발팀의 경우 개인정보보호법·의료법·금융업법상 책임 주체가 서비스 제공자에게 귀속되므로, "모델 벤더가 알아서 막아주겠지"라는 가정은 매우 위험하다.

대응 차원에서 개발자가 즉시 점검할 항목은 세 가지다. 첫째, 자사 프로덕트의 핵심 유스케이스 10~20개를 윤리 프롬프트 회귀 테스트(regression test)로 만들고, 모델 버전 업그레이드(예: Sonnet 4.6 → 4.7) 시마다 응답 분포 변화를 자동 검증하는 CI 파이프라인을 구축해야 한다. 둘째, 시스템 프롬프트와 별도로 도메인 윤리 정책(예: "환자 식별정보는 어떤 경우에도 외부로 전송 금지")을 명시한 Policy Layer를 LLM 응답 후단에 두고, 결정론적 룰 엔진 또는 별도 분류 모델로 출력을 한 번 더 검수하는 Defense in Depth 구조를 권장한다. 셋째, 멀티 모델 환경에서는 모델별 거부율·수용률을 메트릭으로 수집해 대시보드화하고, 특정 모델의 윤리적 분기 양상을 문서화해 PM·법무팀과 공유하는 거버넌스 프로세스가 필수다. 결국 "어떤 모델을 쓰는가"가 곧 "어떤 윤리를 외주화하는가"의 문제이며, 이 선택을 엔지니어가 의식적으로 설계해야 하는 시대로 진입하고 있다.