LLM

법률 AI 서비스를 만들다 보면 이런 순간이 온다. LLM이 자신감 있게 “민법 제103조의2에 따라…” 라고 답변을 줬는데, 확인해보니 제103조의2라는 조문은 존재하지 않는다. 본조인 제103조만 있고 가지조문은 만들어진 것이다. 이게 얼마나 심각한 일인지는 이미 유명한 사건이 증명했다. 2023년 미국 Mata v. Avianca 소송에서 뉴욕의 한 변호사가 ChatGPT가 생성한 판례를 법원 제출서류에 인용했다가 제재를 받았다. 판례가 전부 지어낸 것이었던 거다. 법률 도메인에서 AI 환각은 그냥 버그가 아니라 법률 책임 문제로 번진다. 이번 작업에서 내가 만든 서비스도 같은 위험에 노출돼 있었다. 사용자가 법령 개정 diff를 보면서 “이 개정이 우리 회사에 어떤 영향?” 같은 후속 질문을 하면, LLM이 답변을 돌려주면서 근거 조문을 인용한다. 그 인용이 진짜인지 아닌지를 사용자에게 떠넘길 수는 없었다. ...

들어가며 — “RAG면 충분하지 않냐?” 회사에서 AI 챗봇 도입 논의가 있었다. 누군가가 이렇게 말했다. “사이트맵 정도 수준에서 간단한 RAG는 충분히 가능하지 않냐, 비싼 돈 들이지 않고서.” 틀린 말은 아니다. FAQ 수준의 챗봇이라면 RAG(Retrieval Augmented Generation)로 충분하다. 하지만 내가 직접 MVP를 만들어보면서 깨달은 건, 복잡한 업무 문서를 다루는 챗봇에서는 RAG만으로 부족하다는 것이었다. 수백 페이지짜리 서류를 청킹하고, 임베딩하고, 벡터 DB에 넣고, 리랭킹까지 해봤다. 결과는? AI에게 책의 요약본을 주고 “전체 내용에 대해 완전하게 답해라"고 하는 것과 같았다. ...

LLM에게 “에스크로 결제 구현해줘"라고 하면 무슨 일이 일어나는가? 일단 뭔가 만들어 준다. 트랜잭션도 넣고, 잔액 체크도 하고, 에러 핸들링도 한다. 그런데 “우리 프로젝트에서 에스크로가 정확히 어떤 규칙으로 동작하는지"는 모른다. 추측이 섞인다. 내 프로젝트의 에스크로는 포인트 기반인데, 카드 결제를 가정한 코드가 나온다든가. CanonCode를 만들면서 예상치 못한 이점을 발견했다. .lex 명세를 LLM의 컨텍스트로 제공하면, 추측이 사라진다. 이 글에서는 3가지 케이스에서 “명세 없이” vs “명세 있이” 코드 생성 결과를 비교한다. 실험 설계 조건 모델: Claude (Sonnet) 프로젝트: LaunchCrew (Rails 8 + Inertia.js + Svelte 5) 비교 A: 자연어 프롬프트만 제공 비교 B: .lex 명세 + 자연어 프롬프트 제공 평가: 생성된 코드가 실제 프로젝트 요구사항과 얼마나 일치하는지 3가지 케이스: ...

AI가 글을 검수해주는 시스템을 Rails 8로 만들고 있다. 4개의 AI 에이전트가 각자 관점에서 원고를 분석하고, 스토리 데이터베이스와 연동해서 일관성까지 체크하는 구조. 만들면서 꽤 많이 삽질했는데, 기록 안 해두면 까먹을 것 같아서 정리해본다. 1. AI 에이전트의 “톤"이 이렇게 중요할 줄이야 처음엔 에이전트 프롬프트를 이렇게 썼다: 당신은 편집 보조자입니다. 원고를 분석하고 문제점을 지적하세요. 테스트 유저한테 피드백을 받았는데, **“이건 도움이 아니라 채점이다”**라는 반응이 돌아왔다. 창작하는 사람 입장에서 “지적” 톤은 부담스럽다는 거였다. 업계 리서치를 해보니까 Sudowrite, NovelAI 같은 도구들도 “동료” 톤이 압도적으로 선호된다고 한다. ...