AI 제품은 검증·인용·출력 톤을 설계 요구사항으로 다뤄야 진짜 도구가 된다.

해커뉴스에 올라온 한 설계 비평 글이 현재 LLM 기반 제품들을 정면으로 문제 삼는다. 핵심 지적은 단순하다. 모든 제품이 사용자 인터페이스 어딘가에 "AI는 실수할 수 있다"고 적어 놓으면서도, 그 실수를 사용자가 실제로 걸러낼 수 있게 돕는 기능은 사실상 하나도 제공하지 않는다는 것이다. 저자는 이런 제품이 소프트웨어라기보다, 신뢰를 팔면서 책임은 전부 사용자에게 되돌리는 구조라고 표현한다.

첫 번째 요구는 '실수 확인'을 1급 기능으로 만들라는 것이다. Gemini는 응답을 두 번 확인하라고 안내하고, Claude와 ChatGPT도 각각 오류 가능성과 중요 정보 확인을 작은 회색 글씨로 덧붙인다. 문제는 이 문구가 도움말이 아니라 책임 회피용 법적 장치에 가깝다는 점, 그리고 정작 검증을 도와주는 도구는 없다는 점이다. 저자가 제안하는 형태는 출력물의 각 주장 옆에 체크박스를 붙이고, 사람이 어떤 근거로 그 주장을 확인했는지 적어 넣는 2열 워크시트다. 확인을 마친 항목에만 체크를 하게 만드는 것만으로도 검증이 워크플로의 일부가 된다.

코딩 보조 도구에도 같은 논리가 적용된다. 지금은 검증 부담이 코드 리뷰 단계로 밀려나 있는데, 이는 작성자가 스스로 확인하지 않은 채 리뷰어에게 책임을 넘기도록 유도하는 구조라는 지적이다. 여기에 더해 테스트를 돌리기 전에 diff를 먼저 검토할 수 있는 장치가 있으면 좋겠다는 제안도 나온다. 어차피 토큰을 태우는 비용 못지않게 테스트 컴퓨트도 소모되므로, 명백한 실수를 미리 걸러내는 편이 낫다는 계산이다.

두 번째 요구는 인용의 취급 방식이다. 챗봇은 인용보다 답변을 먼저 내놓는 경향이 있고, 출처 목록을 요구하면 목록 중간부터 슬그머니 인용을 빼먹기 일쑤다. 인용을 붙일 때도 검색 결과의 도메인 이름만, 그것도 거의 읽기 힘든 크기의 글씨와 16픽셀도 안 되는 아이콘으로 표시하는 수준에 그친다.

저자는 이 지점에서 기술적 전제를 분명히 한다. 주요 제공사가 환각을 줄이려고 grounding이나 RAG를 지원하고 그 작은 링크가 실제 검색 구조를 가리킨다 해도, LLM은 권위 있는 인용을 보장할 수 없다는 것이 기술의 근본 한계라는 것이다. RAG로 가져온 결과물조차 모델이 왜곡하거나 잘못 요약할 수 있다. 그래서 제안은 이렇다. 연구 성격의 질의에는 모든 결과를 인용 목록으로 제시하고, 각 인용을 출처·발행일·가능하면 저자까지 담은 독립된 객체로 크게 보여준다. 인용문은 LLM이 만든 요약이 아니라 일반 프로그램으로 추출한 원문 그대로를 가장 앞세우고, AI가 쓴 요약은 그 아래에 지금의 면책 문구만큼 작게 배치한다. 사용자가 해당 인용을 실제로 읽었는지 체크하는 항목까지 두자는 제안도 붙는다.

세 번째는 출력의 말투다. 개발·연구 도구가 자기 자신을 1인칭으로 서술할 이유가 없고, 정정할 때마다 사과문을 생성하는 것도 순수한 낭비라는 것이다. 사과를 만드는 데도, 읽는 데도, 다시 응답하는 데도 토큰과 시간이 든다. 저자는 제공사들이 이런 출력이 정신건강에 영향을 줄 수 있다는 걸 알면서도 실질적이지 않은 가드레일에 기대고 있다고 비판하며, 모델 자체를 훨씬 덜 장황하게 만들 수 있다고 본다. 네 번째 요구로 자연어가 아닌 사용자 인터페이스를 더 늘리자는 항목이 이어지지만, 원문은 이 대목에서 잘려 있다.

이 글은 특정 제품 발표나 릴리스 노트가 아니라 설계 비평이다. 저자는 프런티어 랩들이 가장 심한 사례라고 보면서도, 같은 비판이 Ollama 같은 로컬 모델 도구에도 똑같이 적용된다고 못 박는다. 오히려 사용 가능한 모델 품질이 더 낮은 만큼 이런 검증·인용 기능이 더 절실하다는 것이 그의 주장이다.

개발자 입장에서 이 글의 쓸모는 요구사항 목록에 있다. 에이전트를 만들든 사내에 도입하든, 출력에 대한 검증 절차를 UI에 심어 두었는지, 인용을 원문 중심으로 보여주는지, 불필요한 사과와 1인칭 서술을 걷어냈는지를 점검 항목으로 삼을 수 있다. 특히 코드 리뷰로 검증을 떠넘기는 관행은 도구 설계로 되돌릴 수 있는 문제라는 지적이 실무에 바로 와닿는다.

다만 이 글은 개인 의견이며, 제안된 기능의 구현 사례나 효과를 측정한 데이터는 없다. 원문 자체도 마지막 항목을 마무리하지 못한 채 끊겨 있어, 네 번째 제안의 구체적 내용은 확인할 수 없다.