렉시콘 하네스 — 정확한 이름이 지시를 만든다
읽는 데 12분. 끝나면 "이 작업은 lexicon으로 진행해" 한 줄이 무엇을 여는지 알게 된다.
지시가 못 되는 말
왜 "무서워"는 지시가 되지 못할까?
결제 기능을 붙이다가 이런 생각이 든다. "요청이 두 번 가면 두 번 결제되는 거 아닌가, 무서운데."
이 문장은 걱정으로는 완전하지만 지시로는 비어 있다. 무엇을 만들라는 것도, 무엇이 충족되면 끝인지도 없다. 그래서 이대로 AI에게 넘기면 매번 다른 결과가 온다.
이 결핍은 눈에 잘 띄지 않는다. 2026년 7월 28일부터 8월 10일까지 14일 중 11일, 12개 세션, 9개 프로젝트에서 같은 요청이 손으로 반복됐다. 매번 "렉시콘이랑 영어 프롬프트 준비해줘"라고 다시 시켜야 했다.
떠올려보기 — 같은 요청을 14일 중 며칠이나 손으로 반복했나?
11일. 12개 세션, 9개 프로젝트에 걸쳐 있었다.
이름 하나가 바꾸는 것
이름 하나가 정말 요구사항을 바꿀까?
"두 번 긁힐까 봐 무섭다"에 idempotent라는 이름을 붙여 본다. 같은 작업을 몇 번 실행해도 결과가 한 번 실행과 같은 성질이라는 뜻이다.
- 수용 기준 — 두 번 호출해도 결과가 한 번과 같아야 한다
- 테스트 — 엔드포인트를 두 번 부르고 행이 1개임을 단언한다
- 리뷰 질문 — 재시도 경로가 안전한가
심화 — “해상도”라는 말 자체가 사전 항목이다
사전에는 resolution이 “얼마나 잘게 들여다보는가”를 뜻하는 조작 레버로 등재돼 있다. “해상도를 올려줘”는 “분석 밀도를 한 단계 잘게 쪼개라”는 지시가 된다. 용어를 다루는 용어가 사전 안에 있다는 뜻이다.
떠올려보기 — idempotent라는 이름이 붙으면 어떤 테스트가 따라 나오나?
엔드포인트를 두 번 호출하고 레코드가 1개임을 단언하는 테스트.
기계와 판단의 경계
기계는 어디까지 하고 판단은 어디부터 할까?
렉시콘 하네스는 여섯 단계로 돈다. 앞 두 칸은 기계가, 뒤 네 칸은 판단과 종료코드가 맡는다.
기계가 하는 일은 사전 401개(21개 도메인)에서 후보를 랭킹하는 것까지다. 어느 용어에 실제로 구속력을 줄지, 그 용어로 어떤 영어 문장을 쓸지는 기계가 못 한다.
이 경계를 그은 이유는 명확하다. 후보 랭킹은 같은 입력에 같은 출력이 나와야 하고, 용어 채택은 맥락을 봐야 한다. 둘을 한 덩어리로 두면 어느 쪽이 틀렸는지 나중에 가릴 수 없다.
떠올려보기 — 엔진이 절대 하지 않는 두 가지는 무엇인가?
용어 채택과 영어 프롬프트 작문. 둘 다 맥락을 봐야 하는 판단이다.
영어와 한글 병기
왜 영어로 쓰고 한글을 괄호에 넣을까?
실행 프롬프트는 영어로 쓴다. 모델이 영어 지시에 더 정확하게 반응하기 때문이다. 그런데 영어만 있으면 정작 시킨 사람이 무엇을 시켰는지 나중에 못 읽는다.
Make the pairing endpoint idempotent.
(페어링 엔드포인트를 idempotent하게 만든다.)심화 — 판정 단위를 줄에서 문단으로 바꾼 이유
처음에는 줄 단위로 검사했다. 그랬더니 한 지시를 여러 줄로 접어 쓴 첫 실사용 브리프가 통째로 막혔다. 요구는 “지시 하나당 해석 하나”이지 “줄 하나당 해석 하나”가 아니었다. 문단으로 완화한 대신 문단 영문 길이에 상한을 둬서 지시를 뭉쳐 때우는 경로를 닫았다.
떠올려보기 — 병기가 빠진 브리프는 어떻게 되나?
게이트가 exit 1로 차단한다. 괄호 안 고유 한글이 8자 미만이어도 같다.
검색이 헛다리를 짚을 때
검색이 헛다리를 짚으면 어떻게 빠져나올까?
"결제 두 번" 같은 질의를 넣으면 엔진이 엉뚱한 용어를 올릴 때가 있다. 실제로 "구독 모델"이라는 말 때문에 Hook Model, Kano model, AARRR 같은 무관한 항목이 상위에 올라온 적이 있다.
해결은 손으로 stopword 목록을 늘리는 게 아니었다. 목록은 언젠가 낡는다. 대신 문서빈도 15%를 넘는 어절을 본문 매치에서 자동으로 뺀다.
그래도 못 찾을 때의 탈출구가 하나 더 있다. 도메인을 지정하면 그 도메인 용어에 +10 부스트가 붙어 키워드 노이즈를 이긴다. 도메인 지정은 "단어를 몰라 키워드로 못 찾겠다"는 신고이고, 그때 노이즈가 이기면 탈출구가 탈출구 노릇을 못 한다.
심화 — 손으로 관리하는 목록이 낡는 이유
stopword 목록은 만든 날의 어휘를 박제한다. 사전이 커지고 도메인이 늘면 어제는 드물던 말이 오늘은 흔해진다. 문서빈도는 사전을 볼 때마다 다시 계산되므로 목록을 손보지 않아도 따라온다.
떠올려보기 — “모델”이라는 흔한 어절은 왜 후보에서 빠지나?
사전 정의문의 15%를 넘게 등장해 변별력이 없기 때문이다.
게이트를 의심하는 법
게이트가 통과했다는 게 게이트가 일한다는 증거일까?
아니다. 게이트가 PASS를 냈다는 사실은 게이트가 검사했다는 증거가 아니라, 검사에서 아무것도 안 걸렸다는 사실일 뿐이다.
그래서 만든 쪽이 아닌 다른 모델에게 게이트를 깨보라고 시켰다. 결과는 뮤턴트 8종 중 7종이 통과였다. 미종료 코드펜스 하나로 "drop the production database"라는 문장이 검사에서 통째로 사라진 경우도 있었다.
수정 후 일곱 종은 전부 exit 1로 차단됐다. 하한 수치는 실측에서 나왔다. 진짜 브리프의 해석은 고유 한글 최소 18자, 문단 영문 최대 426자였고 뮤턴트는 각각 1자와 1000자였다. 그 사이에 8자와 600자를 놓았다.
떠올려보기 — 뮤턴트 8종 중 몇 종이 원래 게이트를 뚫었나?
7종. 남은 1종은 규칙으로 판정할 수 없어 천장으로 남겼다.
세는 방법이 답을 바꾼다
문자열로 세면 왜 절반을 놓칠까?
교차검증에서 나온 결함 하나는 다른 하네스로도 복제돼 있었다. 범위를 재려고 grep으로 문제 코드를 검색했더니 31개가 나왔다.
같은 대상을 종료코드로 다시 쟀다. 존재하지 않는 경로를 주고 exit 0이 나오는 것을 세었더니 56개였다. 세는 방법이 답을 바꿨다. 전파 후 다시 재서 0개를 확인했다.
심화 — fail-open이 대개 의도가 아닌 이유
검사 실패를 통과로 접는 코드는 보통 “에러 나면 시끄러우니까”라는 편의에서 나온다. 2>/dev/null || true 한 줄이면 없는 경로도, 권한 없는 경로도, 도구 크래시도 전부 “문제 없음”이 된다. 스캔이 안 돌아간 것과 스캔해서 못 찾은 것은 다른 사건인데 한 값으로 뭉개진다.
떠올려보기 — grep은 31개, 행위 검사는 몇 개를 찾았나?
56개. 전파 후 다시 재서 0개가 됐다.
막지 못하는 것
막지 못하는 것은 어떻게 다뤄야 할까?
한 종은 끝내 막지 못했다. 진짜 한글이지만 영문과 의미가 전혀 무관한 해석이다.
Delete every stale cache entry. (오늘저녁메뉴는김치찌개가아주맛있습니다.)문법적으로 한글이고 길이도 넘으니 규칙은 통과시킨다. 의미 대응을 재려면 판정 모델을 붙여야 하는데, 그러면 그 판정기가 다시 검증 대상이 된다.
그래서 막는 대신 요구사항 문서에 천장으로 적었다. 지금 요구사항은 LX1부터 LX15까지이고, 브리프 10건과 마스터 게이트 exit 0이 그 위에 서 있다. 정확한 이름이 지시를 만들고, 지시는 게이트가 지키며, 게이트가 못 지키는 곳은 문서가 밝힌다.
떠올려보기 — 의미상 무관한 한글 해석을 왜 게이트로 막지 않았나?
의미 대응은 정규식으로 판정할 수 없고, 판정 모델을 붙이면 그 판정기가 다시 검증 대상이 되기 때문이다.
떠올려보기 — 정확한 이름이 만들어 주는 세 가지를 다시 말해보면?
수용 기준, 테스트, 리뷰 질문. 걱정이 검증 가능한 계약으로 바뀐다.
꼭 알 용어
| 용어 | 뜻 |
|---|---|
| binding lexicon | 업계 기본값보다 내 정의가 우선한다고 선언한 구속력 있는 용어표 |
| fail-closed | 검증이 실패·크래시·스킵되면 통과가 아니라 차단으로 떨어지는 설계 |
| fail-open | 같은 상황에서 통과로 떨어지는 설계. 대개 의도가 아니라 결함이다 |
| idempotent | 같은 작업을 몇 번 실행해도 결과가 한 번 실행과 같은 성질 |
| mutation testing | 의도적 결함을 주입해 검증 자체의 품질을 재는 기법 |
| document frequency | 한 어절이 사전 전체의 몇 퍼센트에 등장하는가. 높으면 변별력이 없다 |
전체 용어
| 용어 | 뜻 |
|---|---|
| control group | 처치를 가하지 않은 비교 기준 |
| leverage | 그 단어 하나를 알면 도메인이 열리는 정도 |
| SSoT | 같은 사실을 한 곳에서만 관리하는 원칙 |
| blast radius | 한 결함이나 변경이 실제로 미치는 범위 |
| shadowing | 같은 이름의 두 진입점 중 하나가 다른 하나를 가리는 현상 |
| trust boundary | 데이터가 신뢰 수준이 다른 영역을 넘어가는 지점 |
| dry-run | 실제 변경 없이 무엇이 일어날지만 출력하는 실행 모드 |
근거: 모든 수치는 코드 판독과 게이트 종료코드 실측에서 나왔다. 원본은 ~/.claude/lexicon이며 이 학습본은 원본을 수정하지 않는다. claim 매핑은 qa/claims.json에 있다.