진지한 AI 제품은 어떤 모습이어야 할까요?

AI 요약

글쓴이는 현재 AI 제품이 문제 해결 도구를 자처하면서도 결과를 믿을 수 없다는 한계를 실제 제품 설계에 반영하지 않는다고 주장합니다. “실수를 할 수 있으니 확인하라”는 안내만 작게 표시하고, 확인에 필요한 도구는 제공하지 않는다는 지적입니다. 이런 설계는 사용자가 결과를 대충 넘기도록 유도하며, 문제가 생기면 책임을 사용자에게 돌린다고 봅니다.

결과 검증을 제품의 기본 기능으로

글쓴이는 답변 속 주장마다 확인 상태를 기록하는 작업표를 제안합니다. 한쪽에는 AI가 만든 주장, 다른 쪽에는 사람이 확인한 근거와 메모를 놓고, 충분히 검토한 뒤 체크하도록 하자는 방식입니다. 코딩 보조 도구도 코드 리뷰에 검증을 떠넘기지 말고, 테스트 실행 전 diff를 확인하는 절차를 지원해야 한다고 말합니다. 테스트용 컴퓨팅 자원을 불필요하게 소모하지 않도록 미리 살펴보는 기능도 필요하다고 덧붙입니다.

인용과 데이터 출처를 눈에 띄게

연구용 AI는 답변보다 인용을 중심으로 결과를 보여줘야 한다고 주장합니다. 각 출처에 사이트뿐 아니라 게시 날짜와 저자를 표시하고, AI가 요약한 문장보다 원문에서 프로그램으로 추출한 수정되지 않은 인용문을 앞세우자는 제안입니다. AI의 해설은 사용자가 정확성을 확인하기 전까지 보조 정보로 낮춰 표시하고, 출처를 읽었는지 기록하는 기능도 고려할 수 있다고 합니다.

웹사이트, API, MCP 도구, 사용자의 입력에서 가져온 데이터도 출처별로 구분해야 합니다. 기계적으로 조회한 값과 모델이 만들어낸 내용을 같은 방식으로 대화창에 보여주면 신뢰도를 판단하기 어렵기 때문입니다. 표 형식 데이터는 일반적인 스프레드시트처럼 계산을 검증하고, 어떤 계산을 했는지 보여주는 기능이 필요하다고 제안합니다.

말투와 인터페이스를 작업에 맞추기

소프트웨어 개발이나 연구 도구가 자신을 1인칭으로 말하거나 사과를 반복할 이유가 없다고 말합니다. 이런 문구는 작업에 도움이 되지 않으므로 제품에서 줄여야 한다는 주장입니다. 자연어 대화만으로 작업을 지시하는 방식도 입력과 결과를 모호하고 반복적으로 만들 수 있다고 지적합니다. 보안 점검처럼 목표가 분명한 작업에는 전용 버튼과 기능을 제공하고, 해당 작업에 알맞은 작은 모델을 활용하는 편이 낫다고 제안합니다.

재현성을 위해 모델의 무작위성이나 작업 결과의 변동을 사용자가 살펴볼 수 있어야 한다고도 주장합니다. 단순히 temperature 설정을 노출하는 데 그치지 않고, 같은 작업을 다시 실행해 결과가 얼마나 달라지는지 확인하는 기능이 필요합니다. 대화 기록도 평평한 텍스트로만 남기지 말고, 이전에 만든 표나 도구 결과를 다시 불러와 일부 데이터만 갱신한 뒤 이어갈 수 있어야 한다고 설명합니다.

컨텍스트와 실행 안전성

에이전트 워크플로에서는 컨텍스트가 금방 차고, 긴 작업을 스킬·도구·하위 에이전트로 나눠도 한계가 남습니다. 그런데 제품은 현재 컨텍스트에 무엇이 들어 있는지, 요약 과정에서 어떤 정보가 빠졌는지 제대로 보여주지 않는다고 비판합니다. 사용자가 컨텍스트와 시스템이 만든 프롬프트를 확인하고, 작업을 재실행해 결과를 비교하도록 지원해야 한다고 합니다.

코딩 에이전트의 샌드박스도 기본값부터 안전해야 한다고 주장합니다. 사용자가 매번 승인 버튼을 누르다 경계심을 잃고 결국 전체 승인을 선택하는 방식은 충분한 보호책이 아닙니다. 제안된 안전장치는 파일 시스템 작업을 지정된 범위에 가두고, 저장소 상태를 매 작업마다 스냅샷으로 남기며, 위험한 전체 자동 실행 모드를 없애는 것입니다. 개별 작업을 계속 승인하게 하는 대신 계획을 묶어 검토하고 승인하게 하며, 실제 서비스 대신 모의 API에서 실행해 요청을 확인하는 기능도 제안합니다.

조직의 절차와 글쓴이의 결론

도입 기업도 세 가지 변화를 마련해야 한다고 말합니다. 첫째, AI 결과를 계속 검토하면서 생기는 경계심 저하를 막도록 정기적인 휴식을 보장해야 합니다. 둘째, AI 의존으로 약해질 수 있는 기술을 의도적으로 연습하도록 교육 예산과 시간을 늘려야 합니다. 셋째, AI 사용에 따른 정신건강 위험을 살피고 상담 자원과 누적 사용량을 확인할 방법을 제공해야 합니다.

글쓴이는 측정 가능한 생산성 향상을 제시하는 사례를 듣지 못했다며, 현재로서는 AI 도구의 순효과가 없다는 가정을 출발점으로 삼겠다고 말합니다. 벤치마크 대신 사용자가 실제 맡은 작업에서 효율을 측정하는 기능이 있다면 제품의 실효성을 확인할 수 있다는 주장입니다. 다만 이는 글쓴이의 판단이며, 측정 결과가 이미 정해진 결론을 바꿀지에 대해서는 커뮤니티에서도 의문이 나옵니다.

Lobsters 반응

• @kaig — 이 글이 정말 마음에 듭니다. 특히 “소프트웨어 개발이나 연구 도구가 자신을 1인칭으로 말할 이유가 없습니다. 그렇게 해서는 안 됩니다. 오히려 금지해야 합니다”라는 대목이 아주 좋습니다. 더 건강한 세상이라면 이 내용을 법으로 만들었을 것입니다.
• @elliotmorris — 훌륭한 글입니다. 아이디어가 여러 편의 글을 쓸 만큼 많지만, 불평하는 것은 아닙니다. “당신이 제안한 방법론대로 측정해 봤더니…”라고 말하는 사람을 아직 한 명도 듣지 못했습니다. 저도 마찬가지입니다. 과학적 배경이 부족한 저라도 기업 환경에 충분할 만큼 괜찮은, 완벽하지는 않아도 합리적인 통제를 둔 실험을 할 수 있을 것 같습니다. 제가 아직 하지 않았다는 사실을 보면, 다른 사람들도 저처럼 이 분야에 몹시 지쳤거나 제가 생각하는 것보다 실험이 훨씬 어려운 모양입니다.
  • @bitshift — 피로감도 분명 한몫합니다. 이미 결론을 내린 사람도 많습니다. AI를 홍보하는 진심 어린 신봉자라고 해보죠. 돈을 받고 홍보하는 사람은 아닙니다. 그 사람 눈에는 지금까지 관찰한 결과가 이미 이렇게 보였을 테니, 과학적 엄밀성을 더하는 일이 무슨 소용이겠습니까? 기존 믿음을 확인하거나, 실험이 잘못됐다고 생각할 뿐입니다. 측정할 대상을 잘못 골랐거나 완벽하지 않은 통제가 실제로 중요했을 수도 있다고 말이죠. 하지만 기존 믿음은 바뀌지 않을 것입니다. 텍스트 편집기 비유로는, 키보드만 쓰는 것보다 키보드와 마우스를 함께 써서 글을 편집하는 편이 더 빠르다는 연구가 있었지만 체감상 더 느리게 느껴졌습니다. 다만 그 연구가 조작된 것이었다는 말도 있는 것 같습니다. 제가 아는 건 연구를 읽고 행동을 바꾼 사람을 한 명도 만나지 못했다는 점입니다. 예를 들어 모달 편집기로 바꾸거나 반대로 떠난 사람 말입니다. 과학 연구를 더 해야 한다고 생각하지만, 그 연구가 사람들의 생각을 바꿀지는 회의적입니다.
• @neilmadden — 좋은 글이지만, LLM에게 인용 목록을 내놓게 하는 것만으로는 부족합니다. 인용이 편향적으로 골라질 테니까요. 균형 잡힌 관점을 얻는 유일한 방법은 직접 조사하는 것이고, 그러면 LLM은 쓸모가 없어집니다.
  • @bitshift — 사람과 작업에 따라 다르겠지만, 허용 가능한 정확도가 어느 정도인지가 문제입니다. 정확도가 100%에 이르지는 않습니다. 순수한 의도를 가진 진짜 사람인 제가 조사를 맡아 인용 목록을 만들어도, 커피를 충분히 마시지 못했다면 제 생각을 온전히 뒷받침하지 않는 인용을 넣을 수 있습니다. 제가 완벽하더라도 출처가 틀릴 수 있습니다. 정확도를 엄격하게 높이는 방법으로는 현재 Lean 증명을 생성하는 LLM 같은 접근이 가장 가까워 보입니다. 물론 그 증명이 우리가 생각하는 내용을 증명하는지 수학자가 확인해야 합니다. 처음부터 증명을 직접 쓰는 것보다 사람이 증명을 읽는 편이 쉽다는 데 기대를 거는 셈입니다.
  • @neilmadden — 글의 주장은 LLM의 작업을 확인해야 한다는 것입니다. 제 지적은 LLM이 준 인용이 관련된 자료라고 가정해서는 그 작업을 확인할 수 없다는 점입니다. 사람의 작업을 확인할 때도 그 사람이 보여주는 자료가 전체라고 가정하지 않을 것입니다. 예를 들어 LLM에게 백신이 자폐증을 일으키는지 조사하라고 했는데, 그렇다고 주장하는 그럴듯한 논문을 잔뜩 인용한다고 해도 그대로 믿어서는 안 됩니다. 사람이 같은 자료를 줘도 마찬가지입니다. 체계적으로 출처를 찾아야 합니다. 제 생각에 LLM은 답을 자동으로 검증할 수 있는 좁은 분야, 예컨대 소프트웨어 공학이나 수학에서만 유용합니다. 그 밖의 분야에서는 확인하는 일이 결국 직접 조사하는 것만큼 듭니다.

원문: Glyph / 번역·요약: Trawling