12 단계 SJ 메신저와 AI 비서 — 직원 모두의 창구

뒷이야기 · 12 / 17단계 · 2026-09-18 ~ 09-26 · 갈래 메신저
이전 단계: 11 밖에서 배워 넣기 — 계약 감사 · Hermes · 기록 재생 · 다음 단계: 13 플랫폼 지키기 — 한도 · 규칙 · 보안

핵심 요약

한 줄 요약 — 모델에게 부탁하지 말고 구조로 막았다. 센 수는 SQL 이, 금액·요일 셈은 코드가, 쓰기는 사람이 누른 카드가 맡고 AI 는 말만 한다.

12단계 · SJ 메신저와 AI 비서 — 직원 모두의 창구

목적

회사 AI 는 이 단계 한가운데인 9/23 에도 쓰는 사람이 만든 사람 한 명뿐이었다. 직원이 폰에서 말로 업무를 하게 하려면 AI 가 일하는 자리가 직원이 이미 매일 여는 곳이어야 했다. 카카오톡은 읽기 API 가 없고 비공식 봇은 규칙 위험이 커서 고르지 않았다. 메신저를 직접 갖는 진짜 이유는 AI 가 먼저 말을 거는 길을 우리가 쥐려는 것이었다. 이 단계는 그 창구를 열고, 열자마자 드러난 문제(지어내기·한도·권한)를 하나씩 막은 9일이다.

만든 순서

1 · 메신저 안에 AI 비서 방을 앉혔다 (9/18)

• 이날 아침 6시 27분에 메신저는 messenger.html 파일 하나(1,322줄)였다. 같은 날 PWA 껍데기(홈 화면에 설치되고 끊겨도 다시 열린다, 12:13) → 카톡+전화번호부 꼴 4탭 개편(16:06) → 연락처 맨 위 AI 비서 방(17:21) → 내 업무·일정까지 보고 답함(17:27) → 🤖 버튼이 메신저 창을 연다(17:54)까지 올렸다. 판 번호는 b27 에서 b38 이 됐다.
• 저장 위치가 핵심 결정이었다. 메신저는 전 직원이 최근 메시지 500건을 통째로 구독한다. AI 대화를 거기 넣으면 남의 개인 대화가 모든 폰에 내려가고, 긴 AI 답이 500칸을 밀어낸다. 그래서 AI 대화는 따로 t_aiChat 에 쌓고 규칙으로 본인(uid)만 읽고 쓰게 했다.
• 권한은 users.grade 로 갈랐다 — 대표·임원은 전사, 부서장은 자기 부서, 나머지는 본인 범위의 직원·프로젝트·내 업무·내 일정만 맥락으로 넣는다. 그리고 커밋에 솔직히 적었다: 1단계 AI 는 브라우저에서 돌므로 이것은 방어선이 아니라 보여 줄 범위일 뿐이고, 방어선은 규칙이다(서버 쪽 범위는 13단계 4번).
• 일부러 안 한 것: 글자가 흘러나오는 스트리밍(대신 점 세 개) · 함수 호출(대신 검색 결과와 범위 요약을 맥락으로 주입) · 첨부(저장소가 아직 없었다) · 모드 칩(권한이 따라가면 필요 없다).
• 첫 질문이 실패했다. 게이트웨이를 회사 토큰으로 직접 찔러 보니 모델 일곱 개(제공자로는 여섯 곳) 중 응답한 건 groq 모델 둘뿐이었고, 쓰던 모델은 폐기(404)였다. 살아 있는 둘을 앞에 놓았다. 답이 안 오면 모델 폐기부터 의심한다.
• 같은 날 게이트웨이가 한 경로(9Router) 말고는 로그인 검사를 안 한다는 것도 드러났다. 주소가 사이트 JS 안에 있어 사실상 공개이므로, 주소만 알면 회사 AI 키를 쓸 수 있는 상태였다. 모든 제공자에 회사 계정 확인을 걸어 23:54 에 배포했고 토큰 없이 401, 사내 로그인 200 을 확인했다.

2 · 말로 센다 — 데이터 에이전트 (9/21~9/22)

"작년 견적 재료비 총액"은 세는 질문이다. 벡터 검색은 비슷한 몇 줄만 가져오므로 97줄 중 30줄만 보고 "30개"라고 자신 있게 답한다 — 그럴듯하지만 틀린 수다. 플랫폼에는 NCR(부적합 보고서)이 22건뿐이고 회사의 진짜 숫자는 NAS 엑셀 69,040개에 있었다.

설계를 두 번 뒤집었다. 처음 안은 "각 표의 앞 5줄만 색인"이었는데 재 보니 전부 색인해도 25시간·7GB 라 비용이 이유가 아니었고, 진짜 이유는 벡터 검색으로는 못 센다는 것이었다. 다음은 "제각각이라 표로 못 만든다"였는데 표본 120개의 시트 490장에서 서로 다른 머리행이 147가지뿐이었고 3장 이상 같은 머리행을 쓰는 무리가 65%였다. 몇백 가지 양식을 되풀이해 쓴 것이었다.

9/21 하루에 표 훑기를 만들고(옛 .xls 13,267개가 안 읽히던 것 고침), 같은 양식끼리 묶어 SQLite(파일 하나로 된 작은 데이터베이스) 20개 표 3,254,940행으로 쌓았다. 이 과정에서 "조용히 0행"이 나왔다 — 머리 고르는 입력이 달라 20개 중 5개가 0행, 예상 328만 행 중 193만 행만 들어갔다(41% 손실).

9/22 03:18 메신저 b56 이 붙었다. 흐름은 이렇다. 세는 말이 든 질문일 때만(왕복 두 번에 모델 한 번이 더 들어 인사말에는 안 붙인다) 표 목록을 받고 → 무료 체인이 SQL(표에 묻는 질의문) 한 문장을 쓰고 → 맥이 돌려 센 줄을 주고 → 그 수를 맥락 맨 앞에 넣어 답한다. SQL 은 브라우저 쪽 무료 모델이 쓰게 했다. 맥에서 또 모델을 부르면 질문마다 요금이 붙기 때문이다. 맥은 돌리기만 한다.

이 판부터 b67 까지 64분(03:18~04:22)에 열두 판이 올라갔다(첫 판 하나와 수리 열하나). 단위시험으로 잡힌 건 하나도 없었다. 전부 실제 계정으로 물어 보다 찾았다.

• 맥락을 8,000자에서 자르는데 센 결과를 맨 끝에 붙여 앞의 문서 조각에 밀려 통째로 사라졌다. AI 는 "확인할 수 없다"고 답했다. 자르는 곳이 있으면 순서가 곧 우선순위다.
• 재질별 건수를 물었더니 모델이 받은 줄을 제 손으로 더해 61,317 을 47,539 라고 답했다. 부탁("더하지 마라")으로는 안 됐고, SQL 이 파일별로 쪼개 60줄을 내던 것을 "묻는 축 하나로만 묶는다"로 막으니 9줄이 되고 수가 맞았다.
• "해당 표 없음" 탈출구가 너무 쉬웠다 — 같은 질문 6번 중 4번이 "없음". 예시에 실제 열 이름을 쓰면 그 표로 끌려갔다. 표마다 덮는 기간이 달라(표14 2012~2018, 표04 2022~2026) 카탈로그에 기간을 달았다.
• 0줄이 나온 것도 답인데 말을 안 하니 AI 가 없는 메뉴를 지어냈다("왼쪽 메뉴 견적 → NAS 견적서 목록"). 못 센 것과 안 센 것도 갈랐다.

3 · 남이 쓴 SQL 을 받아도 되는 이유 — 권한자 (9/22)

질의문을 쓰는 건 모델이고 그것이 브라우저에서 온다. WHERE 범위 IN (...) 으로 막는 건 약속이지 통제가 아니다. 모델이 한 번만 빠뜨리면 재무부 표가 생산부에게 간다. 정규식 검사도 우회를 다 못 막는다.

그래서 SQLite 권한자(authorizer)를 썼다. 질의를 준비하는 단계에서 SQLite 가 표·열 하나하나를 "읽어도 되나" 묻는다. 마지막 인자에 뷰 이름이 실리는 것이 열쇠였다 — 범위로 걸러 놓은 뷰를 거친 읽기만 허용하고, 진짜 표 직접 읽기·PRAGMA·ATTACH(DB 설정을 보거나 다른 DB 를 붙이는 명령)·쓰기는 전부 거부한다. 한 질의가 건드리는 표는 3개까지로 막았다(큰 표끼리 조인은 몇 분 걸리고 그동안 파이스가 멈춘다).

• 범위 판단은 새로 만들지 않고 검색과 같은 함수·어휘를 썼다. 두 벌을 두면 한쪽만 고쳐져 조용히 샌다.
• 셀프체크를 직접 돌리면 21개가 통과한다(범위별 합계 7 · 직접 읽기·하위질의·PRAGMA·ATTACH·쓰기·문장 두 개 거부 · 출처 열 등).
• 붙이고 나서야 드러난 것: 표 전체 행의 수정일이 전부 "만든 날"이었다(복사 함수가 시각을 안 옮겼다). "작년" 같은 시간 질문이 통째로 불가능했다. 또 표 3개 제한은 정규식 \b 가 한글에 안 걸려 한 번도 안 돌고 있었다. 둘 다 질의 계층을 붙여 실제로 물어 보기 전에는 아무도 몰랐다.

4 · 부탁 말고 구조로 — 지어내기와 싸운 날 (9/22)

"없는 버튼·클릭 차례를 지어낸다"를 고치려고 지침 문구를 다듬어 b69·b70·b71·b72 네 번 배포했고 네 번 다 졌다. 원인은 지침 안에 그걸 시키는 줄이 넷이나 있었기 때문이다(예: "어느 화면에서 무엇을 하면 되는지 짚어 준다"). 모델은 화면 이름만 알고 버튼과 차례는 모르는데 말하라고 시켰으니 지어낼 수밖에 없었다.

네 번 진 결론은 프롬프트로는 못 막는다였다. 구조를 바꿨다(b74). 부모 앱이 그 사람이 볼 수 있는 화면 목록을 권한까지 걸러 내놓고, AI 는 화면 이름 하나만 말하고, 진짜 「화면 열기」 버튼은 메신저가 그린다. 지어낼 자리가 없어졌다. 손으로 박아 둔 화면 목록 다섯 줄도 지웠다 — 이미 틀려 있었다(9/18 에 없앤 메뉴를 안내하고, 영업부 전용 화면을 아무에게나 안내했다). 실측: "영수증 처리는?" → 「업무관리」「결재」 두 버튼이 붙고 눌러서 열렸다.

같은 날 같은 방식으로 두 건을 더 풀었다. 세는 일은 모델이 아니라 Firestore(회사 플랫폼의 데이터베이스)가(b77): "부적합 몇 건"에 검색 조각 열 개를 세면 "열 건"이라고 답하므로, 컬렉션당 읽기 1회로 개수를 직접 세는 질의를 붙였다. 조용히 죽은 것도 찾았다: 게이트웨이가 맥이 대답하면 그 자리에서 돌려보내, 규격을 맥으로 옮긴 9/19 부터 나흘 동안 NCR·CAR 기록 색인(44조각)이 한 번도 안 읽히고 있었다. 사람 눈에는 "AI 가 멍청해졌다"로만 보였다. 맥과 기록 색인을 둘 다 보고 합치게 고쳤다. 막으면 옆으로 샌다는 것도 봤다 — 없는 화면을 막으니 없는 파일 경로를 지어냈다.

5 · 말로 시키면 플랫폼이 바뀐다 — 행위 등록소 (9/23~9/25)

"OO 대단락 3번 Tank 제작 전체 완료 해줘" 같은 말을 알아듣는 것이 목표였다. 위 4번의 결론을 그대로 적용했다. AI 는 아무것도 쓰지 않는다. "어느 대상·무엇을·얼마로"를 답 끝의 실행 덩이로 말하는 것까지만 하고, 대상을 실제 자료에서 찾고·권한을 보고·무엇이 바뀌는지 세고·쓰는 것은 전부 부모 앱이 한다. 사람이 확인 카드에서 「실행」을 눌러야 쓰인다.

• 행위 한 개 = {설명, 인자, 쓸수있나, 풀기, 쓰기}. 등록소에 더하면 지침·카드·감사 기록이 저절로 따라온다. 5개(b84) → 업무 등록 6개(b85) → NCR·CAR 초안 8개(b88) → 문서 저장 9개(b90) → 캘린더 일정·부서 스케줄 11개(b101).
• 짓기 전에 있는지 봤다. 옛 AI 비서에 같은 기계(확인 카드·감사 기록)와 권한 시험 43항목이 이미 있었다. 새로 쓰지 않고 그것을 그대로 불러 썼다. 권한 규칙이 세 곳이 되는 게 제일 나쁘다.
• 「실행」을 누르면 풀기를 다시 돌려 권한과 자료가 그대로인지 본다. 카드를 만들 때의 지문(제목+카드줄)과 다르면 쓰지 않는다. 카드는 몇 분 전 것일 수 있다.
• NCR·CAR 은 초안만 만든다. 등급·위치·원인·조치는 판단이라 모델이 채우면 틀린 품질기록이 남는다 — 없는 것보다 나쁘다. 그 칸은 빈 채로 두고 "화면에서 채워 달라"고 적는다.
• 문서 저장은 모델이 본문을 다시 쓰지 않는다. 다시 쓰는 순간 사람이 읽은 글과 저장되는 글이 달라지므로, 답변 본문을 그대로 넘기고 시험이 글자 하나까지 같은지 본다.
• 부모 행에 진척률을 박으면 영원히 붙박이고, Number(null) 은 0 이라 값을 지우는 카드가 뜨고, 범위 밖 값을 100 으로 깎아 보여 주면 확인이 아니게 된다. 마지막은 깎지 않고 거절한다.
• 라이브에서 사람 손으로 처음 돌리니(9/24) 9개 중 7개 통과, 2개 실패. 단위시험(가짜 DB)은 전부 통과하던 것이었다. 직함 붙은 이름("홍길동 과장" 꼴)을 못 찾음, 실행 뒤 카드가 「실행 중…」에 멈춤, 문서 저장이 설계상 안 되는 흐름, NCR 번호가 새 계열을 열음, 스케줄 카드가 한 번도 안 뜸 같은 여섯을 b97 에, 문서 하나의 읽기가 영영 안 돌아와 AI 방이 「입력 중」에 멈춘 것(원인은 검증 브라우저의 로컬 캐시였지만 멈춤을 막으려 풀기 20초·실행 30초 시간 제한을 넣었다)과 모델이 목록에 있는 프로젝트를 먼저 거절하던 지침 한 줄을 b98 에서 고쳤다.

6 · 안내문에도 울타리가 있다 (9/25)

9/25 "작년 견적 재료비 총액"이 groq 413(한 요청 8,237 > 8,000)으로 통째 실패했다. 행위 둘을 더한 것만으로 선을 넘었다. 무료 모델은 입력과 답 몫(2,048)을 합쳐 8,000 을 못 넘는다.

게이트웨이로 groq 에 직접 보내 사용량을 재서 어림식을 만들었다(안내문 5,059자 → 2,973토큰, 문서 6,000자 → 3,026, 표 40줄 → 1,760). 그 실측으로 한글은 글자당 0.65, 그 밖은 0.55 로 어림한다. 입력 한도는 처음 5,600 이었다가, 실제 질문에서 어림이 3% 작을 때가 있어 5,400 으로 내렸다.

맥락을 조각(글·급·무리)으로 만들어 넘치면 급이 낮은 것부터 빼고, 비면 높은 급부터 다시 채운다. 문서 질문은 목록보다 문서가, 세는 질문은 문서보다 목록이 앞선다. 시키는 말이 없으면 행위 목록(약 1,100토큰)을 아예 안 싣는다. 413 이 나면 보낸 크기의 75% 로 다시 맞춘다.

적대 검토(만든 쪽과 다른 눈으로 구멍을 찾는 검토)를 두 번 돌려 12건·13건을 확인하고 전부 고쳤다. 가장 큰 것: "뒤부터 자르기"는 틀렸다 — 문서 조각이 목록 뒤에 있어 문서 질문의 문서가 통째로 사라졌고, 출처 칩은 못 본 문서를 보였다. 셸로 정규식을 써 넣다 역슬래시가 빠진 것도 이때 잡혔다.

7 · 누가 얼마나 쓰나 — 장부와 개인 열쇠 (9/23~9/26)

직원에게 열기 전에 누가 얼마나 쓰는지부터 셌다. 게이트웨이는 누가 부르는지 이미 알면서 아무 데도 안 적고 있었다. 무료 열쇠라 돈이 아니라 한도가 나가고, 하루치를 한 사람이 다 쓸 수 있다. 짓기 전에 있는지 보니 aiUsage 장부가 있었으나 브라우저가 스스로 적는 것이라 메신저는 0건이고 안 적고 부를 수도 있었다. 세는 곳이 곧 막는 곳이어야 한다.

• 게이트웨이가 로그인 확인 바로 뒤에서 하루·한 사람당 한 줄에 더한다(쓰기 1회·읽기 0회). 하루 300번을 넘으면 제공자를 부르기 전에 429 로 막는다. 장부가 고장나도 AI 는 안 막는다. 장부 컬렉션은 아무도 못 쓰게 규칙을 닫았다 — 쓸 수 있으면 자기 횟수를 0 으로 되돌려 한도가 장식이 된다.
• 한도를 넘긴 직원에게 "내일 오세요" 말고 길을 줬다. 자기 API 열쇠를 맡기면 그 열쇠로 간다(회사 비용 0). 맡긴 열쇠를 돌려주는 길은 만들지 않았고, 야간 백업이 전 컬렉션을 R2(Cloudflare 파일 저장소)로 떠내므로 평문 대신 AES-GCM(표준 암호 방식)으로 잠가 두며, 등록할 때 한 번 진짜로 불러 본다. 9/23 에는 23분(15:33~15:56) 안에 b91 → b92 → 관문 v4.2 → b93 이 이어졌다.
• 라이브에서 「열쇠 처리 실패 … 429」 가 떴다. Firestore 하루 읽기 한도가 찬 날 읽기 오류를 그대로 500 으로 낸 것이다. 한도는 고장이 아니다. 하루 전 밤 채점에서 똑같은 것을 고쳤는데 새 자리에서 같은 실수를 했다. "없다"와 "못 읽었다"를 가르게 했다.
• 9/26 장부를 하나로 모았다(옛 장부 쓰기 삭제). 기능·제공자·모델·결과(ok·413·429)·토큰(회사 몫/개인 열쇠)을 같은 줄에 적는다. 기능 이름을 헤더로 보내는데 게이트웨이의 CORS 허용 목록(다른 주소에서 온 요청에 받아 줄 칸을 정한 목록)에 없으면 AI 호출이 전부 사전 점검에서 죽으므로 게이트웨이를 먼저 올리고 화면을 나중에 올렸다. 적대 검토에서 SSE 응답(답을 조금씩 흘려 보내는 방식) 끝을 읽다 무료 워커 CPU 한도에 걸려 답이 끊길 뻔한 것(341ms → 1.9ms)과 앞 쓰기가 던지면 AI 전체가 죽는 것을 고쳤다.
• 같은 날 저녁 관문 v5.4: 한도 429 에 limit 칸(사람별 하루 한도인지 회사 몫이 마른 것인지)을 달았다. 회사 몫이 마르면 6초 이하면 기다려 한 번, 등록된 개인 열쇠로 한 번 다시 시도한다.

8 · 영수증 — 맥이 읽고 코드가 검산한다 (9/22~9/23)

AI 방에 영수증 사진 한 장을 올리면 읽어서, 사람이 확인한 뒤 업무관리에 등록하게 했다(9/22, 이튿날 경비 내역서로 옮겼다). 영수증 읽기를 제미나이로 해야 하나 물어 실측했다. 맥에 기본 들어 있는 Vision OCR 로 한국 카드 영수증 한 장이 0.41초에 읽혔고 숫자 줄은 확신도 1.00 이었다. 설치도 요금도 한도도 없고 재무 자료가 밖으로 안 나간다.

금액은 모델에게 시키지 않는다. 로컬 모델(gemma4:12b)에게 "공급가액+부가세=합계가 안 맞으면 고쳐라"를 시켰더니 63,637+363=64,000 으로 틀린 쪽을 고쳐 통과시켰다(진짜는 63,637+6,363=70,000). 검산이 OK 인데 답이 틀린 제일 나쁜 꼴이다. 코드로 a+b=c 이고 부가세가 10% 꼴인 조합을 찾으니 후보 15개 중 하나만 남았다. 여러 개면 고르지 않고 사람에게 묻는다. 모델은 상호·카드사 같은 글자 칸만 맡고, OCR 원문에 없는 값(지어낸 사업자번호)은 버린다. 올라마(맥에서 로컬 모델을 돌리는 프로그램) 모델은 생각 모드를 끄지 않으면 "1+1은?"에 12,192자를 생각하며 100초를 썼다(끄면 1.8초).

흐름은 사진 → 맥 OCR → 코드 검산 → 모델이 글자 칸 → 사람이 확인 → 등록이다. 이 길이 끝까지 돈 이튿날(9/23 08:21) NAS 에 만들어 둔 「업무 경비 내역서」도 재무부 도구로 플랫폼에 옮겼고, 같은 날 직원은 메신저에 사진 한 장과 한 줄만 올리고 재무부가 경비 내역서에서 받도록 바로잡았다. 내역은 한 건에 문서 하나로 저장한다 — 한 문서에 모으면 직원이 올린 내역을 재무부 화면이 다음 저장에 조용히 지운다. 월 마감(결재 올린 달을 잠금)도 붙였다. iframe(화면 안에 끼운 다른 화면)에서 만든 객체를 Firebase 가 거부해 저장이 조용히 실패하던 것도 이때 겪었다(부모의 JSON.parse 로 다시 만들어 넘겨 해결).

9 · 직원 시범 전 대조 (9/26)

직원 2~3명이 한 주 쓰는 시범을 앞두고, 공지 초안의 문장 하나하나가 일반 직원 계정으로 끝까지 되는지 코드와 맥 로그로 대조했다. 그동안 만든 사람(최고 관리자) 계정으로만 시험해 와서 안 보이던 것들이다. 대조 여섯 갈래 + 반박 여섯 갈래 → 수리 다섯 갈래로 나눠 고쳤다.

• 보안 넷이 나왔다. NAS 표 세기에 같은 부서 동료의 개인 자료 폴더 줄이 열려 있었다(20표 중 15표) · 경비 카드·내역을 사내 계정 누구나 읽고 고칠 수 있었다 · 파일 올리기가 아무 열쇠나 서명했다 · 자기 users 문서의 부서·등급·이름을 누구나 바꿀 수 있었다. 앞의 셋의 판정(개인 자료 주인은 이름, 경비는 재무부 소속, 범위는 부서·등급)이 전부 users 문서 위에 서 있어서 마지막 구멍 하나가 셋을 한꺼번에 뚫고 있었다. 전부 막았고 규칙 시험은 60 → 97개가 됐다(13단계 8번).
• 직원 쓰임 고장: 폰 앱·새 창(⧉)에서 기록 세기가 조용히 빈 값이 되어 모델이 검색 조각 수로 짐작했다 · 실패 말풍선에 영어 원문과 조직 id 가 떴다 · 하루 한도를 못 알아보고 네 번 재전송 · 맥이 꺼지면 "없다"고 답했다(실은 못 찾아본 것) · "내 업무 몇 건"이 NAS 표로 가 0줄 · 내 업무·일정이 문서 조각에 밀려 잘렸다 · 처음 쓰는 직원은 AI 방이 채팅 목록 맨 밑에 깔렸다.
• 그 자리에서 요일 셈도 틀렸다. 토요일에 "다음 주 화요일"을 모델이 9/30(수)로 셌다. 지침에 오늘 날짜와 요일이 있어도 셈은 틀렸다. 날짜말은 이제 코드가 풀어서 맥락에 박고, 모델은 옮겨 적기만 한다.
• groq 무료 용량도 실측했다. 호출 1번이 입력 약 3,600 + 답 약 290토큰이고, 공식 무료 한도(분당 8천 토큰 · 하루 20만 토큰, 모델별)로 보면 3명이 한 주 쓰는 데는 무료로 충분하다고 판단했다. 막히는 건 하루 합계가 아니라 분당이다.
• 이튿날(9/27) 결론을 모르는 검증자 셋에게 같은 계획을 다시 대조시켰다. 검교정 알림이 한 기구에 하루 14~15번 가던 것, 영수증을 한 줄 먼저 보내면 사용 내역이 안 붙던 것 등이 더 나왔다.

💡 설명

• 게이트웨이: 회사 AI 호출을 한곳에서 받아 로그인을 확인하고 모델 회사로 대신 보내는 중계소(Cloudflare Worker). 열쇠는 여기만 들고 있다.
• 벡터 검색: 뜻이 비슷한 글 조각을 찾는 검색. 비슷한 몇 개만 가져오므로 "몇 건인지 세기"에는 못 쓴다.
• SQLite 권한자(authorizer): SQL 을 실행하기 전에 "이 표를 읽어도 되나"를 하나씩 묻는 SQLite 의 검문소. 허용한 뷰를 거치지 않으면 거부한다.
• 뷰(view): 표를 범위로 미리 걸러 놓은 창. 이 창으로만 읽게 하면 범위 밖 줄은 아예 안 나온다.
• readers: 메시지 하나를 읽어도 되는 사람 목록. 이 목록에 든 사람만 그 메시지를 받는다.
• 토큰(AI): 모델이 글을 세는 단위. 무료 모델은 한 요청에 입력+답이 8,000토큰을 넘으면 413 으로 거절한다. (로그인 확인용 토큰과는 다른 말이다.)
• 413 · 429: 413 은 한 요청이 너무 크다는 뜻, 429 는 한도를 다 썼다는 뜻. 둘 다 고장이 아니라 한도 신호다.
• 행위 등록소: AI 가 부탁할 수 있는 일(일정 등록·업무 완료 등)을 한 곳에 모은 목록. 각 일마다 권한 확인과 쓰기 방법이 정해져 있다.
• 확인 카드 · 지문: AI 의 제안을 사람이 읽고 「실행」을 누르는 카드. 지문은 카드가 보여 준 내용의 사본으로, 실행 때 자료가 달라졌으면 막는다.
• PWA: 앱 설치 없이 홈 화면에 추가해 앱처럼 쓰는 웹 화면.
• OCR · 확신도: 사진 속 글자를 읽는 기술과 그 글자를 얼마나 확신하는지의 값. 1.00 이면 거의 틀리지 않는다.
• 적대 검토: 만든 쪽이 아닌 다른 눈이 일부러 구멍을 찾는 검토.

함정과 배운 것

• 단위시험은 라이브에서 틀린 답을 못 잡는다. 이 단계의 고장은 거의 전부 실제 계정으로 물어 보다 찾았다. 모델 응답은 들쭉날쭉해서 한 번 돌려 보고 판단하지 말고 같은 질문을 5~8번 돌려 성공률을 센다. 요청을 가로채 모델에게 간 글을 보면 제일 빠르다.
• 프롬프트가 말을 안 들으면 덧붙이지 말고 모순되는 옛 줄을 지운다. 새 능력을 붙였으면 "우리는 이걸 못 한다"고 적힌 옛 줄을 같이 지운다. 규칙을 얹기 전에 모델이 실제로 받는 지침 전문을 찍어 눈으로 훑는다.
• 모르는 것을 말하라고 시키면 반드시 지어낸다. 모델이 모르는 것은 구조로 막는다(「화면 열기」 버튼, 센 수를 맥락 맨 앞에). 그리고 막으면 옆으로 샌다 — 화면을 막으니 파일 경로를 지어냈다.
• 셈은 코드가 한다. 금액 검산, 표 줄 합계, 요일 셈 셋 다 모델이 틀렸다. 모델은 옮겨 적기만 한다.
• 자르는 곳이 있으면 순서가 우선순위다. "뒤부터 자르기"는 문서 질문의 문서를 지웠다.
• 한도(429)는 고장이 아니다. "없다"와 "못 읽었다"를 섞으면 맡겼는데 "등록하세요"라고 말하게 된다.
• 짓기 전에 있는지부터 본다. 행위 등록소·장부·경비 도구 모두 비슷한 것이 이미 있었다. 새로 쓰면 규칙이 두 벌이 된다.
• 한 계정(최고 관리자)으로만 시험하면 권한 구멍이 안 보인다. 일반 직원 계정으로 공지 문장마다 대조한다.

출처

• 플랫폼 저장소(sejong-platform-v2) 커밋: aa1fcf2 · b4b1bfa · f472e6d · e069876 · 1ba17da · c38f29a · 5f1d8af · d49ed67 ~ 1cc29eb(b56~b67) · de67361 ~ 642c584(b68~b73) · 8283950 · 6ea39e8 · d3477c4 · 815548f · b8d07ff · fd1c5a0 · 50403b4 · 0ac1bdc · 283b2c8 · a7e78ca · 28fc8ea · 6379d1c · e1dc580 · 876a893 · fc8090f · cac87ad · c4fe6c1 · db55865 · cd9fb80 · 8a2a013 · d7e49e5 · 6a07ab2 · de59369 · b958141 · 0f890fa · 7c5371c · 66d8f48
• 파이스 저장소 커밋: 5ea0530 · 1985f54 · 4dcf81f · 1144daa · 5ad01d2 · 6572420 · aad4d53 · a4ee920 · 9d7725e
• 기억 노트: sj-messenger-plan · llm-sql-pipeline-traps · sqlite-authorizer-scope · prompt-budget-fence · ai-action-registry · gateway-usage-ledger · receipt-ocr-local · expense-tool · staff-trial-readiness
• 설계 문서: 플랫폼 SJ메신저/설계서.md · 청사진 모음

← 11 밖에서 배워 넣기 — 계약 감사 · Hermes · 기록 재생 · 13 플랫폼 지키기 — 한도 · 규칙 · 보안 →