AI와 함께 만드는 삶

지금까지 온 거리4월 16일 첫 커밋부터 지금까지 약 넉 달. 그 사이 있었던 일을 한 줄로 요약하면 이렇다.무료로 시작 → 무료를 유지할 방법을 밖에서 두 번 찾다 실패 → 원래 계획대로 직접 벌기로 함 → 벌기 시작하니 운영이라는 새로운 산이 나타남.기술적으로 남은 것도 정리하면: LLM 하나에 의존하지 않는 폴백 체인, 실제 법조문·판례를 인용하는 RAG 파이프라인, 긴 계약서도 끝까지 읽는 청킹 엔진, 한글 파일까지 읽는 파서, 버전 간 변경사항을 자동으로 비교하는 리드라인 엔진, 회사별 기준과 대조하는 플레이북 시스템. 그리고 그 사이사이 죽어있던 API, 깨졌던 로컬 환경, 지워야 했던 옛 호스팅의 흔적들.로드맵에 아직 안 지워진 줄 하나ROADMAP.md를 다시 열어보다가 재밌는 걸 발견했다..

앞의 일곱 장 동안 "왜 이렇게 만들었는지", "뭐가 잘못됐고 어떻게 고쳤는지"만 이야기했다. 이번엔 그래서 지금 뭐가 남았는지, 실제 화면으로 보여준다.카테고리 선택 — 일반과 기업은 처음부터 갈라진다들어오자마자 "일반 사용자"와 "기업"으로 갈라진다. 일반은 주거·근로·소상공인 같은 생활 밀착 카테고리, 기업은 B2B·인사노무·IP·투자·컴플라이언스 5개 카테고리로 나뉜다. 1장에서 "취약계층 대상"으로 시작한 서비스가, 5장을 거치며 기업형 유료 서비스까지 같이 갖추게 된 결과가 이 갈림길이다.AI 법률 상담 — 카테고리별로 다른 전문가가 답한다 노무 카테고리에서 물으면 노무사 톤으로, 이혼 카테고리에서 물으면 가사 전문 변호사 톤으로 답한다. 답변 아래엔 실제로 검색된 법조문·판례가 인용 카드 형..

누구나법률 7장(기업형 계약 분석 엔진 만들기)에서 나온 개념: 텍스트 청킹, 바이너리 파일 파싱, diff(비교) 알고리즘, 규칙 기반 판정.청킹(Chunking) — LLM에게 긴 문서를 나눠서 주는 기술모든 LLM은 한 번에 처리할 수 있는 텍스트 양(컨텍스트 길이)에 한계가 있다. 문서가 그 한계보다 길면, 통째로 넣을 수 없다. 청킹은 긴 문서를 의미 있는 단위로 쪼개서, 나눠서 처리한 뒤 결과를 다시 합치는 기법이다.여기서 실무적으로 중요한 건 "어디서 자르는가"다. 그냥 글자 수로 뚝뚝 자르면, 문장이나 조항 중간이 잘려서 문맥이 끊긴다. 그러면 LLM이 잘린 조각만 보고 엉뚱하게 판단할 수 있다. 그래서 이 프로젝트에서는 계약서의 자연스러운 구조 단위(제N조)를 기준으로 잘랐다. 문서 종류..

6,000자 컷 — 계약서 뒷부분이 통째로 안 읽히고 있었다계약서를 AI에게 분석시키는 코드를 열어보니, 이런 줄이 있었다. pythonprompt = f"""다음 계약서를 분석해주세요.계약서 전문:---{contract_text[:6000]}---"""[:6000] — 앞 6,000자만 잘라서 LLM에 넘기고 있었다. 짧은 근로계약서라면 문제없지만, 기업 간 용역계약서나 공급계약서는 보통 2만~4만 자다. 뒤쪽 70~80%, 그러니까 손해배상·관할법원·비밀유지 같은 정작 중요한 조항이 대부분 들어있는 구간이 아예 AI 눈에 안 들어가고 있었다. 그런데 화면엔 "분석 완료"라고만 뜬다. 사용자는 자기 계약서의 3/4가 검토조차 안 됐다는 걸 알 방법이 없었다.조항 경계로 자르고, 병렬로 분석하고, 다시 ..

누구나법률 6장(완성 그 이후)에서 나온 개념: 안 쓰이는 코드의 위험성, 버전 고정의 함정, 인코딩 문제."완성"의 함정 — 안 불러본 코드는 검증된 적이 없다서비스에 기능이 100개 있다고 해서, 그 100개가 다 검증됐다는 뜻은 아니다. 실제로 사용자가 눌러본 경로만 검증된 것이다. 6장의 /api/config/status 500 에러가 정확히 이 경우였다 — 코드는 있었지만, 아무도 그 엔드포인트를 실제로 호출하지 않았기 때문에 NameError(존재하지 않는 함수/변수를 부르는 오류)가 배포 이후 계속 방치돼 있었다.실무에서 이걸 막는 방법은 결국 두 가지다.모든 엔드포인트를 최소 한 번씩 직접 호출해보는 점검(smoke test) — 복잡한 테스트 코드가 아니어도, 배포 후 "이 API들 다 ..