Keyword / 35 entries
이 키워드가 붙은 글입니다. 전체 글
OCR가 영수증 표를 읽으면 row가 그대로 나오지 않을 때가 있습니다. 사람 눈에는 다음처럼 보이는 표입니다. 그런데 OCR text는 column을 먼저 읽어 다음처럼 평평하게 만들 수 있습니다. 상품명과 금액이 여러 line 떨어졌습니다. 첫 번째 이름과 첫 번째 금액, 두 번째 이름과 두 번째 금액을 묶으면 원래 row를 복원할 수 있습니다. 하지만 모델이 다음처럼 짝을 바꿔도 각 조각은 모두 진짜입니다. 두 상품명은 영수증에 있습니다. 두 금액도 영수증에 있습니다. 합계도 여전히 3,600입니다. evidence 존재 검사도, value 존재 검사도,…
KO2026-08-26
evidence는 짧을수록 좋아 보입니다. 영수증에서 값을 읽었다면 그 값이 있는 한 줄만 인용하면 될 것 같습니다. 저도 처음에는 그렇게 만들었습니다. excerpt는 OCR page의 정확히 한 line 안에 있어야 했습니다. 규칙은 단순했고, 멀리 떨어진 label과 amount를 이어 붙이는 hallucination도 막았습니다. 그러다 실제 한국 영수증 capture가 들어왔습니다. 한 품목이 이런 모양으로 인식됐습니다. 첫 줄은 상품명입니다. 둘째 줄은 barcode입니다. 셋째 줄은 수량입니다. 넷째 줄은 금액입니다. 모델이 네 줄을 그대로 인용하고…
KO2026-08-25
영수증에서 purchaseDate: 1999-01-01을 추출했다고 해보겠습니다. 모델이 근거라고 내민 줄은 BLUE BOTTLE입니다. 날짜는 어디에도 없습니다. 이때 API가 할 수 있는 일은 대략 셋입니다. 첫 번째는 곤란합니다. 영수증에 없는 날짜를 사실처럼 내보내기 때문입니다. 두 번째는 깔끔해 보입니다. 하지만 사용자는 모델이 뭔가 읽었으나 검증에 실패했다는 사실조차 볼 수 없습니다. 제가 receipt-evidence에서 선택한 것은 세 번째였습니다. 응답의 unverified 배열에는 경로도 함께 남깁니다. 이 설계의 핵심은 “틀린 값을 친절하게…
영수증 OCR에서 total을 찾는 가장 단순한 방법은 무엇일까요? 가장 큰 숫자를 고르면 될 것 같습니다. 아니면 아래쪽에 있는 마지막 금액을 고르면 될 것 같습니다. 다음처럼 synthetic test input을 만들면 그 규칙의 빈틈이 드러납니다. 가장 마지막 숫자는 4,300입니다. 카드와 상품권 금액을 더하면 9,300이 됩니다. 그렇다면 total은 무엇일까요? 현재 parser contract가 고르는 정답은 명시적으로 적힌 합계 9,300입니다. 이 test에서 카드 4,300과 상품권 5,000은 total이 아니라 결제 기여분으로 취급됩니다.…
KO2026-08-24
Every guide to Anthropic prompt caching tells you the same debugging step, and it is a good one. If cache_read_input_tokens comes back zero across repeated requests with an identical prefix, something in that prefix is changing between calls. A timestamp in the system prompt. A UUID. A dict that serializes in a…
EN2026-08-18
코딩 AI에게 기능을 맡기기 전, “버튼 하나 추가해 줘”라고 바로 말하고 싶을 때가 있습니다. 문장도 짧고 결과도 빨리 보고 싶으니까요. 그런데 코드베이스는 빈 캔버스가 아닙니다. 이미 폴더의 역할, 상태를 다루는 방식, 데이터를 오가는 길, 그리고 지켜야 할 약속이 쌓여 있습니다. 그걸 찾지 않고 구현부터 시키면 AI는 열심히 일하면서도 엉뚱한 서랍에 양말을 넣을 수 있습니다 (정리한 사람만 더 피곤해지는 그 서랍 말입니다). AI가 코드를 잘 생성한다는 사실과, 이 저장소의 맥락을 이미 안다는 사실은 다릅니다. 요구사항은 “무엇을 만들지”를 알려 줍니다. 반면…
KO2026-08-13
프로젝트를 열었는데 루트에도 AGENTS.md가 있고, 작업할 폴더 안에도 또 AGENTS.md가 있다면 AI는 무엇을 읽어야 할까요? 둘 다 읽다가 갑자기 우왕좌왕하는 것 아닐까요? 사람도 규칙 문서 두 장만 만나면 표정이 복잡해지는데, AI라고 문서 더미 앞에서 초연할 리는 없습니다 (다만 표정 대신 다음 토큰을 낼 뿐입니다). 여기서 가장 흔한 오해는 가까운 문서 하나만 이긴다는 생각입니다. 하위 폴더의 지침이 있으니 루트 지침은 폐기되고, 두 문서가 경쟁하는 결승전처럼 보이는 것이죠. 하지만 유지보수하기 좋은 저장소 패턴에서는 조금 다르게 생각하는 편이…
CLAUDE.md도 있고 AGENTS.md도 있다면, 둘 다 길고 자세하게 쓰는 편이 친절할까요? 처음에는 그래 보입니다. 도구마다 알아듣기 쉬운 문서를 하나씩 주면 될 것 같으니까요. 그런데 두 문서가 같은 빌드 명령, 같은 작업 규칙, 같은 검증 절차를 반복하기 시작하면 친절은 금세 두 개의 정답 후보가 됩니다. 문서가 두 명의 교장 선생님처럼 서로 다른 말을 하기 시작하는 순간이죠 (둘 다 진지해서 더 곤란합니다). 이 문제를 피하는 한 가지 관리 패턴이 얇은 도구별 어댑터입니다. 여기서 어댑터란, 특정 AI 도구가 저장소의 운영 방식을 찾고 따르도록 연결해…
AI가 다음 행동을 정해야 하는 순간, 이런 질문을 받으면 어떨까요? “그래서 이제 무엇을 할까요?” 친절해 보입니다. 하지만 막상 답하려고 하면 생각이 길어집니다. 계획을 더 다듬을지, 작업을 시작할지, 잠깐 멈추고 정보를 더 줄지, 아니면 전혀 다른 방향을 말해야 할지 말이죠. 자유로운 질문 하나가 작은 빈칸 시험지가 되는 순간입니다. 이럴 때 메뉴형 질문은 질문을 없애지 않습니다. 대신 답의 모양을 정합니다. AI 도구의 AskUserQuestion 메뉴 패턴은 다음 단계의 선택지를 이름 붙은 항목으로 보여 주고, 사용자가 그중 하나를 고르게 하는 방식입니다.…
AI 코딩 도구에서 /무언가를 입력해 보신 적이 있다면, 어느 날 그 명령이 사라지고 “스킬을 호출하세요”라는 안내를 만났을 때 조금 당황했을 법합니다. 이름만 바꾼 것 같은데, 왜 굳이 명령어를 스킬로 옮길까요? 명령어가 잘못해서 벌을 받는 것도 아닌데 말입니다. 이 질문을 풀 때 가장 먼저 버려야 할 생각은 **“명령어와 스킬은 같은 버튼의 다른 라벨”**이라는 모델입니다. 사용자 입장에서는 둘 다 어떤 일을 시작하는 입구처럼 보입니다. 하지만 도구를 만들고 배포하는 쪽에서는 입구의 이름보다, 그 뒤에 무엇을 묶어 두고 여러 환경에 어떻게 전달할지가 더 큰…
한 프로젝트에서 잘 통했던 규칙을 다른 프로젝트에서도 바로 쓰면 더 똑똑해지는 걸까요? AI가 기억을 많이 할수록 편해 보이지만, 실제로는 기억의 범위가 넓어질수록 엉뚱한 전제가 따라올 위험도 커집니다. 어제의 정답이 오늘의 다른 저장소에서는 조용한 오답이 될 수 있으니까요. 여기서 필요한 것이 메모리 범위(scope) 입니다. 메모리 범위란 AI가 저장한 사실이나 규칙이 어느 맥락에서만 유효한지 표시하는 기준입니다. 이 기준은 기억을 많이 모으는 기술이 아니라, 기억을 어디까지 믿어도 되는지 정하는 규칙에 가깝습니다. 가장 위험한 마음속 공식은 이렇습니다. “A…
AI가 “예전에 이렇게 결정했어요”라고 알려주면, 왠지 지금 할 일도 이미 통과한 것처럼 느껴지지 않나요? 근거를 찾아 준 건 분명 반가운 일입니다. 하지만 그 문장을 곧바로 “그럼 진행해도 된다”로 번역하는 순간, 과거 사례와 현재 승인이 한 덩어리가 됩니다. 둘은 닮았지만 같은 물건이 아닙니다 (비슷하게 생긴 리모컨을 눌렀다가 TV가 아니라 에어컨이 켜지는 것처럼요). 흔한 오해는 이렇습니다. AI가 과거의 판단, 규칙, 또는 비슷한 선택을 찾아냈다면 현재 계획도 맞다고 인증한 셈이라는 생각입니다. 그래서 조회 결과를 승인 도장처럼 쓰고, 별도의 판단이나 확인을…
KO2026-08-26
KO2026-08-25
KO2026-08-25
KO2026-08-24
EN2026-08-18
KO2026-08-13
KO2026-08-13
KO2026-08-13
KO2026-08-13
KO2026-08-13
KO2026-08-13
KO2026-08-13