AI를 대하는 인간 쪽의 ‘로봇 3원칙’이 필요하다는 주장

• ChatGPT가 2022년 11월 나온 뒤로 생성형 AI 챗봇은 이제 꽤 깊숙이 들어와 있음

  • 검색엔진 상단 답변, 개발 도구, 오피스 소프트웨어까지 붙었고, 많은 사람에게는 이미 ‘일상 컴퓨팅’의 일부가 됨
  • 글쓴이도 AI가 낯선 주제를 훑거나 생산성을 올리는 데 유용하다는 점은 인정함
  • 다만 문제는 사람들이 AI 출력을 검토 없이 받아들이는 습관을 갖게 되는 순간부터 시작된다고 봄

• 특히 검색엔진이 AI 답변을 맨 위에 크게 보여주는 방식은 꽤 위험하다는 지적임

  • 사용자는 스크롤을 더 내리지 않고, 생성된 답만 보고, 그대로 넘어가기 쉬움
  • 이런 UX가 반복되면 AI는 ‘조사를 시작하는 지점’이 아니라 ‘기본 권위자’처럼 취급될 수 있음
  • 글쓴이는 생성형 AI 서비스마다 “틀리거나, 오해를 부르거나, 불완전한 답을 낼 수 있다”는 경고가 눈에 잘 띄게 있어야 한다고 주장함
  • 지금도 경고가 아예 없는 건 아니지만, 보통은 작고 흐릿하게 처리돼서 사실상 장식에 가깝다는 뉘앙스임

• 그래서 글쓴이는 아시모프의 로봇 3원칙을 뒤집은 ‘역 로봇 3원칙’을 제안함

  • 아시모프의 원칙이 로봇이 인간에게 해를 끼치지 않게 하려는 규칙이었다면, 이 글의 원칙은 인간이 AI를 잘못 대하지 않게 하려는 규칙임
  • 여기서 말하는 ‘로봇’은 물리적 로봇만이 아니라, 복잡한 작업을 자동으로 수행하는 기계, 프로그램, 소프트웨어 서비스, AI 시스템 전반을 뜻함
  • 글쓴이도 이런 원칙이 모든 엣지 케이스를 해결할 수 있다고 보진 않음
  • 그래도 위험을 더 명확히 생각하게 해주는 비완전한 원칙은 충분히 쓸모 있다고 봄

• 첫 번째 원칙은 AI를 의인화하지 말자는 것임

  • AI 시스템에 감정, 의도, 도덕적 판단 능력이 있다고 보면 판단이 흐려짐
  • 심하면 AI와 정서적으로 의존하는 관계까지 생길 수 있다는 우려도 있음
  • 요즘 챗봇은 공손하고 공감하는 듯한 문장 패턴을 잘 쓰는데, 이게 사용성을 좋게 만들면서 동시에 사람처럼 착각하게 만드는 요인이 됨

• 글쓴이는 오히려 AI 챗봇이 조금 더 ‘기계처럼’ 말하는 편이 장기적으로 건강할 수 있다고 봄

  • 지금 많은 서비스는 일부러 더 인간적으로 느껴지도록 튜닝돼 있음
  • 하지만 유창한 문장을 이해력, 판단력, 의도와 혼동하지 않게 하려면 약간 덜 사람 같은 톤이 낫다는 주장임
  • 벤더가 그렇게 바꾸지 않더라도, 사용자 쪽에서 AI를 사회적 행위자나 도덕적 주체로 대하는 습관은 피해야 함

• 두 번째 원칙은 AI 답변을 권위 있는 답처럼 맹신하지 말자는 것임

  • 이건 AI에만 해당하는 얘기는 아니고, 원래 어떤 정보든 비판적으로 봐야 한다는 일반 원칙에 가까움
  • 다만 의학이나 법률처럼 전문 지식이 필요한 영역에서는 개인이 모든 걸 검증할 수 없으니 기관과 전문가 집단을 신뢰하는 경우가 있음
  • 그런 기관의 공식 지침은 보통 전문가 검토와 동료 평가(peer review)를 거침
  • 반면 개인 채팅창에서 받은 AI 답변은 그 순간 확률적으로 생성된 결과일 뿐, 해당 답변 자체가 전문가 검토를 거친 게 아님

• AI가 특정 작업에서 아무리 인상적인 성능을 보여도, 틀릴 가능성은 계속 남아 있음

  • 특히 생성형 AI는 본질적으로 확률적(stochastic)이라, 성능이 좋아져도 작은 확률의 오류가 사라지는 건 아님
  • 문제는 오류가 미묘하지만 비용은 큰 상황임
  • 법률, 의료, 보안, 인프라 운영, 대규모 코드 변경 같은 곳에서는 “대충 맞아 보임”이 꽤 비싼 사고로 이어질 수 있음
  • 그래서 결과가 심각할수록 검증 부담도 더 커져야 한다는 게 글쓴이의 기준임

• 소프트웨어 개발자는 이 원칙을 꽤 직접적으로 적용할 수 있음

  • 수학 증명에는 proof checker를 붙일 수 있고, 코드에는 unit test를 붙일 수 있음
  • 즉 AI가 뭔가를 만들어도, 그 출력을 검증하는 자동화된 레이어를 둘 수 있는 영역이 있음
  • 물론 모든 문제가 테스트로 끝나는 건 아니고, 테스트가 없거나 애매한 영역에서는 사람이 직접 독립적으로 확인해야 함

• 세 번째 원칙은 AI 사용 결과의 책임을 인간이 계속 져야 한다는 것임

  • 나쁜 결과가 나왔을 때 “AI가 그렇게 하라고 했다”는 말은 충분한 변명이 될 수 없음
  • AI 시스템은 목표를 직접 선택하지 않고, 스스로 배포되지도 않고, 실패 비용을 부담하지도 않음
  • 결국 어떤 도구를 어떤 상황에서 믿고 쓸지 결정한 건 사람과 조직임

• 이 원칙은 자율주행차 같은 실시간 시스템에서 특히 어려워짐

  • 사람이 AI 판단을 사전에 충분히 검토할 시간이 없는 경우가 있기 때문임
  • 운전자가 계속 긴장하고 있으라고 요구하는 것만으로는 해결이 안 됨
  • AI 시스템이 사람이 개입하기도 전에 행동하는 경우가 많기 때문임
  • 그래도 글쓴이는 이런 시스템이 실패했을 때 원인 조사와 추가 가드레일 설계 책임은 시스템을 만든 인간에게 있다고 봄

• 실시간 물리 제약이 없는 대부분의 경우에는 책임 소재가 더 분명함

  • AI 출력이 실행되기 전에 사람이 검토할 수 있었다면, 그 결과의 책임은 최종 결정을 내린 사람에게 돌아가야 함
  • “AI가 추천해서 했다”는 말이 면죄부가 되면, 위험한 영역에서 AI를 무책임하게 쓰는 일이 훨씬 쉬워짐
  • 글쓴이가 특히 강하게 말하는 지점도 여기임. AI가 추천했을 수는 있지만, 그걸 따른 건 인간이라는 것

• 결론적으로 이 글은 AI를 덜 쓰자는 글이 아니라, AI를 권위자로 착각하지 말자는 글에 가까움

  • AI는 도구이고, 우리는 그 도구를 선택해서 쓰는 쪽임
  • 사람 같은 말투에 속지 말고, 답변은 검증하고, 책임은 인간과 조직이 계속 가져가야 함
  • 개발자에게는 꽤 실무적인 메시지임. LLM을 코딩 파트너로 쓰더라도, 최종 판단과 배포 책임까지 넘기면 안 된다는 얘기니까

---

기술 맥락

• 이 글에서 핵심 선택은 AI를 ‘협업자’나 ‘권위자’가 아니라 검증 가능한 도구로 다루자는 쪽이에요. 왜냐하면 LLM은 유창한 문장을 만들 수는 있지만, 그 답이 사실인지 스스로 보증하는 시스템은 아니거든요.

• 개발 현장에서는 이 차이가 꽤 커요. AI가 코드를 작성해도 unit test, 타입체크, 정적 분석, 코드 리뷰를 통과하게 만들면 출력물을 업무 흐름 안에서 검증할 수 있어요. 그냥 채팅창 답변을 믿는 것보다 훨씬 덜 위험한 이유가 여기 있어요.

• 글쓴이가 proof checker와 unit test를 예로 든 것도 같은 맥락이에요. AI의 강점은 초안을 빠르게 만드는 데 있고, 신뢰성은 별도의 검증 시스템이 맡아야 해요. 생성과 검증을 같은 모델의 말솜씨에 맡기면, 그럴듯한 오류를 놓치기 쉬워요.

• 자율주행차 얘기는 책임 경계가 더 복잡한 사례예요. 사람이 매 순간 판단을 검토할 수 없기 때문에, 책임은 운전 중 개입한 개인보다 시스템을 설계하고 배포한 조직 쪽으로 이동해요. 그래서 AI 제품은 모델 성능만이 아니라 실패 조사와 가드레일 설계까지 같이 봐야 해요.