2026년의 모든 제품 미팅은 동일한 중력의 영향을 받습니다. 누군가 "사용자들이 질문을 가지고 있다"라고 말하면, 40초 후에 화이트보드에는 _챗봇 (chatbot)_이라는 단어가 적혀 있습니다.

우리는 장애가 있는 아이를 둔 가족들을 위한 소프트웨어를 만듭니다. 부모님들은 "학교 측에서 제 아들이 IEP(개별화 교육 프로그램) 자격이 안 된다고 하는데, 이게 가능한가요"라거나 "보험사가 거절할 경우 ABA(응용 행동 분석) 비용이 실제로 얼마나 드나요"와 같은 질문을 가지고 찾아옵니다. 이것들은 챗봇이 유창하게 답변하기에 아주 적합한 질문들입니다.

하지만 우리는 대신 포럼 (forum)을 구축했습니다. 그 이유는 이것이 사람들이 예상하는 것보다 더 많은 영역에 일반화될 수 있다고 생각하기 때문입니다.

실패 모드는 틀리는 것이 아닙니다. 확신을 가지고 틀리는 것입니다.

답을 모르는 LLM (대규모 언어 모델)은 모르는 것처럼 행동하지 않습니다. 정답을 말할 때와 동일한 확신을 가지고 답변의 형태를 갖춘 무언가를 만들어냅니다.

대부분의 제품에서 이는 짜증스러운 일일 뿐입니다. 정규 표현식 (regex)을 요청했는데 잘못된 정규 표현식을 받으면, 테스트가 실패하기 때문에 10초 안에 이를 알아차립니다. 피드백 루프 (feedback loop)가 짧고, 틀린 답변의 비용은 낭비된 1분 정도입니다.

이제 도메인 (domain)을 바꿔봅시다. 한 부모가 교육구가 평가를 거부할 수 있는지 묻습니다. 모델은 그럴듯한 답변을 내놓습니다. 테스트 스위트 (test suite)는 없습니다. 부모는 질문을 했던 근본적인 이유인 바로 그 오류를 잡아낼 전문 지식이 없습니다. 그리고 피드백 루프는 10초가 아니라 한 학년의 길이이며, 그 시점에는 법적 마감 기한이 조용히 지나가 버린 상태가 됩니다.

중요한 변수는 정확도가 아닙니다. 그것은 틀린 답변의 비용에 오류를 감지하는 데 걸리는 시간을 곱한 값입니다. 제품의 규모가 커질 때, 생성된 확신 (generated confidence)은 모델이 아무리 훌륭하더라도 잘못된 인터페이스 (interface)가 됩니다.

챗봇이 구조적으로 가질 수 없는 포럼의 세 가지 요소

답변은 출처 (provenance)를 가집니다. 포럼에서는 답변을 통해 누가 말하고 있는지가 드러납니다. 적법 절차를 밟은 지 3년이 된 부모, 언어 치료사, 특수 교육 전문 변호사 등이 될 수 있습니다. 독자는 "내가 신청했을 때 일어난 일은 이렇다"라는 말과 "법령에 명시된 내용은 이렇다"라는 말을 다르게 평가하며, 마땅히 그래야 합니다. 챗봇은 모든 출처를 아무런 가중치를 둘 수 없는 하나의 익명화된 목소리로 평탄화 (flatten) 시켜버립니다.

의견 불일치가 가시적으로 유지됩니다. 특정 치료 접근법에 대해 물으면 서로 완전히 동의하지 않는 네 개의 답변을 받게 됩니다. 이것은 콘텐츠의 오류가 아니라 해당 분야의 실제 상태이며, 결정을 내려야 하는 부모는 그 상태를 볼 자격이 있습니다. 채팅 인터페이스 (chat interfaces)는 하나의 답변으로 수렴하도록 설계되었습니다. 정직한 답변이 "전문가들 사이에 의견 불일치가 있으며, 그 불일치의 양상은 이렇습니다"인 경우, 단일하게 합성된 (synthesized) 응답은 그 자리에서 가장 유용한 정보를 파괴해 버립니다.

시간이 흐를수록 정확도가 낮아지는 대신 높아집니다. 포럼의 잘못된 답변은 다음 사람에 의해 공개적으로, 그리고 원래 답변에 연결되어 수정됩니다. 챗봇의 잘못된 답변은 개인 세션에서 새로 생성되어 한 사람에게만 보여지고 아무런 흔적도 남기지 않습니다. 한 시스템은 지식을 축적하지만, 다른 시스템은 매번 처음부터 다시 생성하며 자신이 틀렸다는 사실을 결코 배우지 못합니다.

아무도 경고하지 않는 부분

기술적인 구축은 어려운 부분이 아닙니다. 스레드 (threads), 카테고리 (categories), 인증 (auth), 중재 대기열 (moderation queue) 등은 이미 알려진 형태이며 빠르게 구축할 수 있습니다.

어려운 부분은 답변이 없는 포럼은 포럼이 없는 것보다 더 나쁘다는 점입니다. 챗봇은 첫날 첫 번째 사용자에게 바로 작동합니다. 하지만 포럼은 질문하는 사람들에게 유용해지기 전에 답변을 해줄 임계 질량 (critical mass)의 사람들이 필요하며, 초기 단계는 진정으로 화려하지 않습니다. 실제 질문들을 뿌려두어야 하고, 대가 없이 답변해 줄 전문가들을 찾아야 하며, 스스로 답변을 달아야 하고, 한동안은 비율이 나빠 보이는 것을 받아들여야 합니다.

그 콜드 스타트 (cold start) 문제가 팀들이 챗봇을 선택하는 진짜 이유입니다. 챗봇이 더 낫기 때문이 아닙니다. 챗봇은 즉각적이지만, 커뮤니티는 그렇지 않기 때문입니다.

생존을 가능하게 했던 몇 가지 요소들:

• 당신이 상상하는 질문이 아니라, 사람들이 실제로 던진 질문에서 씨앗(Seed)을 얻으세요. 고객 지원(Support) 편지함과 검색 로그에는 실제 사용자의 표현 방식이 가득하며, 그 실제 표현 방식이야말로 나중에 다른 부모들이 검색하게 될 용어입니다.
• 카테고리는 데이터를 저장하는 방식이 아니라, 사용자가 생각하는 방식과 일치해야 합니다. 부모들은 당신의 스키마(Schema) 방식으로 생각하지 않습니다. 그들은 "학교 관련 일"이나 "치료 관련 일"과 같이 생각합니다.
• 초기에는 답변의 품질보다 답변의 지연 시간(Latency)이 더 중요합니다. 한 시간 내에 이루어지는 괜찮은 답변은 커뮤니티를 형성하지만, 4일 뒤에 나오는 완벽한 답변은 그렇지 못합니다.
• 첫날부터 어조(Tone)에 대해 엄격하게 중재(Moderate)하세요. 취약한 분야(Niche)에서는 무시하는 듯한 답변 하나가 열 개의 도움이 되는 답변이 얻는 가치보다 더 큰 손실을 초래합니다. 첫 주에 허용하는 규범이 영원히 유지될 규범이 됩니다.

챗봇이 적절한 선택인 경우

저는 일반적인 반(反) LLM 주장을 하는 것이 아니며, 이 글의 솔직한 버전에는 반대편의 입장도 포함되어야 합니다.

답변이 결정론적(Deterministic)이고 확인 가능한 경우에는 모델을 사용하세요. "이 내용은 문서 어디에 있나요?", "이 에러는 무엇을 의미하나요?", "이 스레드를 요약해 주세요."와 같은 경우입니다. 저희도 내부적으로 정확히 그러한 용도로 LLM을 사용합니다.

제가 긋는 경계선은 다음과 같습니다: 만약 틀린 답변이 주는 비용이 올바른 답변이 아껴주는 비용보다 크다면, 답변을 생성하지 마세요. 사람에게 연결하거나, 출처를 인용하거나, 혹은 아무 말도 하지 마세요. 마감 기한을 놓치는 것이 아이의 1년을 앗아갈 수 있는 특수 교육 분야에서는, 이 경계선이 대부분의 소프트웨어 분야보다 훨씬 더 가깝게 위치합니다.

그 결과물은 Special Needs Forum입니다. 이곳에서 가족들은 IEP(개별화 교육 프로그램), ABA(응용 행동 분석) 치료, 학교 배치에 대해 질문하고, 이를 직접 경험해 본 사람들에게서 답변을 얻습니다. 이 포럼은 무료이며, 읽기 위해 계정이 필요하지 않습니다.

만약 이 작업의 덜 철학적인 측면에 관심이 있다면, 디렉토리 측면에서 우리에게 금전적 손실을 입혔던 스키마 실수에 대해서도 글을 썼는데, 이는 좀 더 전형적인 Postgres 관련 실전 경험담(War story)입니다.

저는 Special Needs Care Network에서 근무하며, 미국 내 가족들이 특수 교육 학교와 ABA (응용 행동 분석, ABA) 치료 제공자를 찾을 수 있도록 돕고 있습니다.